Russell,
> 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
> --- a/drivers/mfd/twl4030-irq.c
> +++ b/driver
>-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
>befo
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 foll
Rajendra Nayak 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
Thanks, pushing to PM branch (and pm-2.6.29)
Kevin
> ---
> arch/arm/mach-oma
Rajendra Nayak 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 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
Than
"Nayak, Rajendra" writes:
>>"Nayak, Rajendra" writes:
>>
>>>From: Högander Jouni [mailto:jouni.hogan...@nokia.com]
ext Rajendra Nayak writes:
> There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF
> should not be set together. The PRCM FSM has been coded ass
"Hunter, Jon" 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 possible
Jon Hunter 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 condition c
On Mon, Jun 29, 2009 at 7:35 AM, Rajendra Nayak 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
> ---
I thin
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. Everythi
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 q
"Nayak, Rajendra" 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: Disab
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
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 in
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 tr
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 latest IRQ registers from a timer or a work
> > > queue b
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
Russell King - ARM Linux 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 lazy enable - i
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
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: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 p
"Shilimkar, Santosh" writes:
>> 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-i
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 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 unsua
"HU TAO-TGHK48" 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 bit is
> se
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 so
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
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 beca
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 on
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 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 i
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
> 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 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
pointer
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
---
arch/arm/mach-omap2/board-3430sdp.c | 22 ++-
arch/arm/mach-omap
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 possible
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 latencie
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 com
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, only
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 chi
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 see
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 N
>From: Kamat, Nishant
>
>Vikram,
>
>> From: linux-omap-ow...@vger.kernel.org
>>
>> 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 impac
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
Acked-by: Kevin Hilman
Acked-by: Tony Lindgren
Acked-
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
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,
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
---
drivers/usb/musb/musb_core.c |7 ++-
drivers/usb/musb/omap
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 I2Ci.I
On Mon, 29 Jun 2009 09:37:58 +0300
Peter Ujfalusi 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 both for playback an
50 matches
Mail list logo
