On Wed, 22 Oct 2008 23:50:54 -0700
"ext David Brownell" <[EMAIL PROTECTED]> wrote:
> Following this are four patches matching $SUBJECT:
>
> - remove omap_set_gpio_dataout() and omap_get_gpio_datain()
> ... same call syntax, different name, minor code shrink
> - use gpio_direction_input()
> - __raw_readsl(nand->IO_ADDR_R, buf, len / 2);
> + __raw_readsw(nand->IO_ADDR_R, buf, len / 2);
I would prefer len >> 1 rather len / 2.
---
vimal--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
On Thu, 23 Oct 2008 14:50:33 +0530
"ext naveen krishna ch" <[EMAIL PROTECTED]> wrote:
> > So to summarize:
> >
> > - 2.6.26 + backported drivers on OMAP3 EVM -> audio works
> > - 2.6.26 + backported drivers on custom board with NAND boot -> no audio
> > - 2.6.26 + backported drivers on custom boar
Tony,
How does this look?
If we set irq to NR_IRQS then arch/arm/kernel/irq.c will use
bad_irq_desc when it processes the interrupt. NOTE: I haven't tested
this yet.
Rick
--- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git
2008-10-22 20:01:33.0 -0700
+++ lin
On Thursday 23 October 2008, Juha Kuikka wrote:
> How does this look?
>
> Subject: [PATCH] OMAP2 NAND: Change __raw_readsl() to __raw_readsw()
Looks fine. Although I'm still wondering what happened to that
patch teaching it about the prefetch engine ... it'd be nice to
maximize throughput.
(And
Hello,
I'm not sure if this code ever get exercised, but I found a small
problem with the
dsp bridge driver code while debugging the kernel, and thought I'd bring
it to
someone's attention.
Thanks,
Dan Bright
diff --git a/drivers/dsp/bridge/services/mem.c
b/drivers/dsp/bridge/services/mem.c
in
On Wed, Oct 22, 2008 at 3:23 PM, Juha Kuikka <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 22, 2008 at 3:02 PM, David Brownell <[EMAIL PROTECTED]> wrote:
>> On Wednesday 22 October 2008, Juha Kuikka wrote:
>>> >> - __raw_readsl(nand->IO_ADDR_R, buf, len / 2);
>>> >> + __raw_readsl(nand->IO_A
Hi,
I was looking around to see if there is a DSP gateway/bridge driver
for the C64x DSP in the OMAP2430 chip.
So far it looks to me that the DSP bridge in the HEAD (3.3.1) only
supports OMAP2420 and hance only the C55x core that is in there.
DSP bridge available in http://www.openomap.org/pub/d
Hi,
We are planning to develop a camera flash driver for OMAP3430. I
briefly looked around and it appears there is none available for omap.
We would like to take an existing Camera flash driver if available
(any platform) and upgrade it for omap3. so, any pointers are highly
appreciated.
Thanks
h
* Rick Bronson <[EMAIL PROTECTED]> [081023 11:13]:
> Tony,
>
> > Well we should let the generic irq handler to do the logging.. But I
> > guess nothing will happen if adm_do_IRQ() does not get called.
> >
> > We could have a dummy handler for some invented higher number that would
> > capture the
Tony,
> Well we should let the generic irq handler to do the logging.. But I
> guess nothing will happen if adm_do_IRQ() does not get called.
>
> We could have a dummy handler for some invented higher number that would
> capture the spurious interrupts I guess.
>
> BTW, ideally we would do the l
Tony,
I checked out some other ARM spurious interrupt handling and it
seems that they ack the interrupt but left the macro with the Z bit
set which means that asm_do_IRQ() does not get called. Seems to me we
should do the same, see the patch below. Although, ideally, we should
be logging these
* Rick Bronson <[EMAIL PROTECTED]> [081023 10:41]:
> Tony,
>
> I checked out some other ARM spurious interrupt handling and it
> seems that they ack the interrupt but left the macro with the Z bit
> set which means that asm_do_IRQ() does not get called. Seems to me we
> should do the same, see
Tony,
I checked out some other ARM spurious interrupt handling and it
seems that they ack the interrupt but left the macro with the Z bit
set which means that asm_do_IRQ() does not get called. Seems to me we
should do the same, see the patch below. Although, ideally, we should
be logging these
* Peter Ujfalusi <[EMAIL PROTECTED]> [081022 22:56]:
>
> On Saturday 18 October 2008 01:02:19 ext Tony Lindgren wrote:
> > OK, I'll push these two to l-o tree, hopefully you're still planning
> > to send them to the mainline kernel?
> >
> > > Tony
>
> Sorry, it seams that I was sleeping...
> I h
* Rick Bronson <[EMAIL PROTECTED]> [081022 20:30]:
> Tony,
>
> Here is the patch against the latest git. I'm a little concerned
> about masking the interrupt number so that the spurious bit are
> ignored. Do you really want to turn a spurious interrupt into a
> normal (good) interrupt?
No, bu
> -Original Message-
> From: Ramón Finger Lilienthal [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 22, 2008 6:35 PM
> To: Premi, Sanjeev; linux_omap
> Subject: Re: Problems compiling kernel
>
> Dear Sanjeev,
>
> Thanks for your help.
>
> Now, I am building for omap5912osk, and we
> I got a message from someone on the beagleboard mailinglist that
> asound.conf was the culprit, no idea what the exact fix was.
I wonder if you could dig up this guy's contact info. I tried lots
of different asound.conf's but none of them did anything.
Here is what I get without a asound.c
Hi Rajendra,
Currently cpuidle is not taking enable_off_mode variable (from pm.c)
into account, it only controls suspend / dynamic idle behavior.
-Tero
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of ext
>Rajendra Nayak
>Sent: 08 October, 2008 15:0
On Saturday 18 October 2008, Paul Walmsley wrote:
> In the medium- to long-term, it may be best
> to use a generic device pointer so system devices can be linked also;
Best IMO to start phasing out system devices; they're
superfluous, given some power management changes from
late last year.
--
To
On Saturday 18 October 2008, Paul Walmsley wrote:
> --- a/arch/arm/mach-omap2/omapdev-common.h
> +++ b/arch/arm/mach-omap2/omapdev-common.h
> @@ -21,6 +21,87 @@
> #include "omapdev3xxx.h"
>
> static struct omapdev *omapdevs[] = {
> +
> +#ifdef CONFIG_ARCH_OMAP2420
> + &mpu_242x_omapdev,
>
From: David Brownell <[EMAIL PROTECTED]>
Have most uses of OMAP_GPIO_IRQ() use gpio_to_irq() instead.
Calls used for static initialization are left alone, at least
this time around.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
arch/arm/mach-omap1/board-osk.c| 11 ++-
a
From: David Brownell <[EMAIL PROTECTED]>
More conversion to the standard GPIO interfaces: stop using
omap_set_gpio_direction() entirely, and switch over completely
to the gpio_direction_output() call.
Note that because gpio_direction_output() includes the initial
value, this change isn't quite t
From: David Brownell <[EMAIL PROTECTED]>
This patch replaces some legacy OMAP GPIO calls with the "new" (not
really, any more!) calls that work on most platforms.
The calls addressed by this patch are the simple ones to get and set
values. Except for the declarations and definitions of those cal
From: David Brownell <[EMAIL PROTECTED]>
More switchover to the cross-platform GPIO interface:
use gpio_direction_input(), not an OMAP-specific call.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
arch/arm/mach-omap1/board-palmte.c |4 ++--
arch/arm/mach-omap1/board-palmz71.c|
Following this are four patches matching $SUBJECT:
- remove omap_set_gpio_dataout() and omap_get_gpio_datain()
... same call syntax, different name, minor code shrink
- use gpio_direction_input()
... minor call syntax change, otherwise not interesting
- use gpio_direction_output
26 matches
Mail list logo
