On Wed, May 12, 2010 at 11:15:11AM +0530, Shilimkar, Santosh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Arce,
Abraham
Sent: Wednesday, May 12, 2010 11:10 AM
To: Dmitry Torokhov
Cc:
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, May 12, 2010 11:33 AM
To: Shilimkar, Santosh
Cc: Arce, Abraham; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
On
Sorry for jumping into the comments late. Thought this was sorted out. Key
scanning
and debounce timeouts etc still there. Having all these things in ISR itself
isn't good
idea.
Dmitry,
Don't you think its optimal to push the key-scanning and debounce timeout
code
part of bottom
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, May 11, 2010 8:27 PM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Agarwal, Preshit; Tony
Lindgren; Turquette, Mike; V, Hemanth
Subject: Re: [PATCH v3] OMAP3: Registering sgx
On Wed, May 12, 2010 at 11:49:45AM +0530, Shilimkar, Santosh wrote:
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, May 12, 2010 11:33 AM
To: Shilimkar, Santosh
Cc: Arce, Abraham; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, May 12, 2010 12:05 PM
To: Shilimkar, Santosh
Cc: Arce, Abraham; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
On
From ad2e1cd024ccf9144b6620cfe808893719db738f Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Wed, 14 Apr 2010 16:26:45 +0300
Subject: [PATCH] omap_hsmmc: improve interrupt synchronisation
The following changes were needed:
- do not use in_interrupt() because
On Wed, 5 May 2010 20:15:45 -0500
Jorge Eduardo Candelaria jorge.candela...@ti.com wrote:
In OMAP4, there is only one irq line for TX and RX paths. Use
the correct irq line to avoid errors at runtime.
Also, request irq line only once (instead of requesting for TX
and RX).
Signed-off-by:
On Wed, 5 May 2010 20:15:46 -0500
Jorge Eduardo Candelaria jorge.candela...@ti.com wrote:
McBSP module in OMAP4 needs to be able to set its tx/rx threshold
and enable the transmitter/receiver when starting an audio stream.
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Tony,
This series contains remaining patches from ealier series and
is is rebased against the current omap for-next branch
Balaji T K (2):
omap4: add i2c1 peripherals data
omap4: Enable RTC and regulator support
Santosh Shilimkar (1):
omap4: Add i2c board support on omap4430 sdp platform
From: Balaji T K balaj...@ti.com
This patch adds i2c1 peripherals data to
omap4430 sdp board file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 177 ++-
1 files changed, 176
From: Balaji T K balaj...@ti.com
This patch enables RTC and regulator support on omap4430 sdp
platform. Also sync up the defconfig with latest kernel
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/configs/omap_4430sdp_defconfig |
[Sukumar Ghorai wrote:
From: Sukumar Ghorai s-gho...@ti.com
Board file modified to pass the GMPC phys_base address to nand driver. This is
required to adopt the _prob function as in omap2.c
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 10
On Wed, May 12, 2010 at 11:39:26AM +0300, Peter Ujfalusi wrote:
Looks good with Jarkko's comment.
However, I'd like to ask Tony, Liam, Jarkko, and Mark the following:
Would it make sense to use the alsa tree for OMAP McBSP related patches,
while
keeping l-o in CC off course.
We've had to
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/sfh7741.c | 256 +
include/linux/input/sfh7741.h |
Adding board support for the proximity sensor.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 71 +++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
Hi,
On Mon, 2010-05-10 at 22:20 +0200, ext Tony Lindgren wrote:
* Stephen Rothwell s...@canb.auug.org.au [100506 22:05]:
Hi Tomi,
Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-rx51-peripherals.c between commit
On Wed, 2010-05-12 at 11:39 +0300, Peter Ujfalusi wrote:
Hi,
On Thursday 06 May 2010 04:15:44 ext Jorge Eduardo Candelaria wrote:
The following patches enable McBSP driver to be used along with the
audio driver in SDP4430 and other OMAP4 based boards.
Changes from v1:
- Changed to
GPMC register definition move to common place in gpmc.h.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 38 +--
arch/arm/plat-omap/include/plat/gpmc.h | 36 +++--
drivers/mtd/nand/omap2.c
Board file modified to pass the GMPC phys_base address to nand driver. This is
required to adopt the _prob function as in omap2.c
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 16 +---
arch/arm/mach-omap2/board-devkit8000.c |
The following set of patches applies on top of master branch.
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git
Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle board
And these are the patches required to address the following input -
1.
Necessary function added in GPMC module and used by nand driver. This is for
not to use GPMC address directly from nand driver. Also it was passing GPMC
base address from board files and that is removed.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c
Hello,
I have a bit of time to investigate more.
I have two boards with two different OneNAND chips populated.
The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
[ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[ 26.412170] OneNAND version = 0x0031
[ 26.415771] Chip
MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
simultaneously enabled which results in DMA lockup.
Use system DMA for all RX channels as a workaround of this issue as this
will have minimal throughput overhead based on the fact that Rx transfers
are done in DMA mode-0
Use optimal values of transfer element based on buffer address in system
DMA programming. This would improve the performance.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musbhsdma.c | 39 +--
1 files changed, 33 insertions(+), 6
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for unaligned buffers as a workaround of this issue.
Current patch supports
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, May 01, 2010 5:34 AM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
t...@atomide.com
Subject: Re: [PATCH 9/9] OMAP:GPIO: Implement GPIO as
Tony/Kevin,
+{
+ if (cpu_is_omap242x())
+ gpio_bank_count = 4;
+ else if (cpu_is_omap243x())
+ gpio_bank_count = 5;
+ else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+ gpio_bank_count = OMAP34XX_NR_GPIOS;
+
+ if (gpio_init())
+ return
Hello,
On Tue, May 11, 2010 at 06:58:46PM +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
Hello Nishanth,
On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote:
Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
From: Eduardo Valentin
Eduardo Valentin had written, on 05/12/2010 07:34 AM, the following:
Hello,
On Tue, May 11, 2010 at 06:58:46PM +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
Hello Nishanth,
On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote:
Eduardo Valentin had written, on 05/11/2010
I answer to myself.
DDP (dual die plane) not implies 'ONENAND_HAS_2PLANE'. A device with
a single die can also have '2 planes'. I'm right ?
Sorry for these newbie questions, I'm just introducing to OneNAND devices.
Cheers,
Enric
2010/5/12 Enric Balletbò i Serra eballe...@gmail.com:
Hello,
Hello.
Ajay Kumar Gupta wrote:
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for unaligned buffers as a workaround of this
very minor comments follow:
Datta, Shubhrajyoti had written, on 05/12/2010 03:52 AM, the following:
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
On Tue, 11-May-10 4:38 AM +0530, Rick Ball wrote:
I think I've found a small problem in the board-omap3evm.c file under
arch/arm/mach-omap2 (support for the TI/Mistral OMAP35x EVM board).
What I noticed is that the declaration for the array gpio_leds is initialized
with one element (at
Varadarajan, Charulatha ch...@ti.com writes:
Tony/Kevin,
+{
+if (cpu_is_omap242x())
+gpio_bank_count = 4;
+else if (cpu_is_omap243x())
+gpio_bank_count = 5;
+else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+
Hello.
Gupta, Ajay Kumar wrote:
Hi,
if (channel-status == MUSB_DMA_STATUS_BUSY) {
if (musb_channel-transmit) {
+ if (musb_channel-sysdma_channel != -1)
+ omap_stop_dma(musb_channel-sysdma_channel);
+
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/sfh7741.c | 256 +
include/linux/input/sfh7741.h |
Against for-next branch
---
Add __attribute__ ((unused))
arch/arm/mach-omap2/clockdomains.h:58
warning: 'gfx_sgx_wkdeps' defined but not used
arch/arm/mach-omap2/mux.c:52
warning: 'mux_phys' defined but not used
Initialize to 0
arch/arm/plat-omap/gpio.c
In
Hi,
Here is the OMAP4430 ES1.0 hwmod data serie v2.
It is based on the OMAP: HWMOD fixes and cleanup serie:
http://marc.info/?l=linux-omapm=127324706012621w=2
It was only tested on OMAP4430 ES1.0 GP device using PAB board for the moment.
Please note, that the two temporary fixes are pure
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/Makefile |3 ++-
arch/arm/mach-omap2/io.c |6 --
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
3 files
From: Rajendra Nayak rna...@ti.com
Do not disable any clocks yet since not all drivers are adapted
and rely on bootloader to enable clocks
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
From: Rajendra Nayak rna...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/Makefile
From: Rajendra Nayak rna...@ti.com
Dependency not supported yet, hence comment all dependency handling
code in hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 10
McBSP module in OMAP4 needs to be able to set its tx/rx threshold
and enable the transmitter/receiver when starting an audio stream.
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
arch/arm/plat-omap/mcbsp.c | 14
The following patches enable McBSP driver to be used along with the
audio driver in SDP4430 and other OMAP4 based boards.
Changes from v2:
- Fixed missing parentheses.
- Added Acked-by tag to patch #1.
- Sending to alsa-devel list also, as suggested by Peter Ujfalusi
and Liam Girdwood
Jorge
In OMAP4, there is only one irq line for TX and RX paths. Use
the correct irq line to avoid errors at runtime.
Also, request irq line only once (instead of requesting for TX
and RX).
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
---
On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote:
MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
simultaneously enabled which results in DMA lockup.
I've seen it on rtl1.8 also if I remember correctly.
Use system DMA for all RX channels as a
On Wed, May 12, 2010 at 05:19:37PM +0530, Ajay Kumar Gupta wrote:
Added is_inventra_dma_enabled() funtion which would be required
for adding workaround for Inventra DMA issues. It can also be
used at other places instead of #ifdefs.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
[..]
On Wed, May 12, 2010 at 05:19:38PM +0530, Ajay Kumar Gupta wrote:
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for
I have been having some issues with the A/D converter on the OMAP3530
platform, using the TWL4030. The hardware I am using is the Logic
OMAP3530 LV SOM Zoom2 Development Kit. I created a driver which uses
the twl4030-madc driver to obtain the A/D values for ADCIN3 and
ADCIN4. I am not getting
Felipe Balbi wrote:
On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote:
MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
simultaneously enabled which results in DMA lockup.
I've seen it on rtl1.8 also if I remember correctly.
I'm fairly certain
Hi,
I was wondering if you could provide a bit more detail on what this
driver is actually doing? My appologies if I have missed a
previous explanation. If so, please add a Documentation file
to explain what is going on.
The driver you have here does virtually nothing itself. It takes
both
On Wed, May 12, 2010 at 08:56:19PM +0530, Datta, Shubhrajyoti wrote:
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/sfh7741.c |
Hi,
I didn't touch this issue in the hopes that it would be fixed, but
seems it hasn't.
On Mon, Apr 19, 2010 at 9:25 PM, Guzman Lugo, Fernando x0095...@ti.com wrote:
To sum up:
- DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT is only
hidden the problem, we don't need
On Wed, 12 May 2010 10:50:45 +0300
Adrian Hunter adrian.hun...@nokia.com wrote:
From ad2e1cd024ccf9144b6620cfe808893719db738f Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Wed, 14 Apr 2010 16:26:45 +0300
Subject: [PATCH] omap_hsmmc: improve interrupt
On Wed, 2010-05-12 at 11:29 -0700, Dmitry Torokhov wrote:
On Wed, May 12, 2010 at 07:15:22PM +0100, Jonathan Cameron wrote:
Hi,
I was wondering if you could provide a bit more detail on what this
driver is actually doing? My appologies if I have missed a
previous explanation. If so,
Anand,
-Original Message-
From: Gadiyar, Anand
Sent: Friday, April 02, 2010 10:04 AM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: David Brownell; Gregory Clement; Felipe Balbi; Aguirre, Sergio;
Gadiyar, Anand
Subject: [PATCH RFC 4/5] omap: 3430sdp: add ohci
Hi,
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Wednesday, May 12, 2010 2:39 PM
To: Guzman Lugo, Fernando
Cc: Chitriki Rudramuni, Deepak; linux-omap; Ameya Palande; Felipe
Contreras; Hiroshi Doyu; Ramirez Luna, Omar; Menon, Nishanth
Hi Roger,
I just wanted to inform you that your Patch
OMAP: RX51: Add LCD Panel support (b499d77834ae292465f8d06bb0a88f1a647dfa1a)
introduces a build failure for the omap3_defconfig.
You can see the error message here:
http://kisskb.ellerman.id.au/kisskb/buildresult/2601981/
This is due to the
Unfortunately I can't get through the nokia mailfilter:
Message_contained_possible_malicious_content_and_will_not_be_accepted._If_you_consider_this_to_be_due_to_an_error_please_inform_the_intended_recipients_by_sending_a_simple_e-
mail_or_through_other_means/
I get this reply even with a simple
On Tue, 11 May 2010 17:15:28 +0300
Eduardo Valentin eduardo.valen...@nokia.com wrote:
Here is the version 5 of the change to export OMAP data to userspace
(name, revision, id code, production id and die id).
Basically, this version is still attempting to create a new file under /proc.
It is
On 05/11/2010 08:46 PM, Xianghua Xiao wrote:
On Sun, May 9, 2010 at 11:42 PM, Suresh Rajashekara
suresh.raj+linuxo...@gmail.com wrote:
Hi All,
I had a couple of application (with real time priority SCHED_FIFO)
which were working fine on 2.6.16. They have started behaving
differently on
On Wed, 12 May 2010 12:46:20 Xianghua Xiao wrote:
On Sun, May 9, 2010 at 11:42 PM, Suresh Rajashekara
suresh.raj+linuxo...@gmail.com wrote:
Hi All,
I had a couple of application (with real time priority SCHED_FIFO)
which were working fine on 2.6.16. They have started behaving
On Wed, May 12, 2010 at 9:49 PM, Con Kolivas ker...@kolivas.org wrote:
On Wed, 12 May 2010 12:46:20 Xianghua Xiao wrote:
On Sun, May 9, 2010 at 11:42 PM, Suresh Rajashekara
suresh.raj+linuxo...@gmail.com wrote:
Hi All,
I had a couple of application (with real time priority SCHED_FIFO)
Hello,
Some general comments on the suspend blockers/wakelock/opportunistic
suspend v6 patch series, posted here:
https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
The comments below are somewhat telegraphic in the interests of
readability - more specific
Hi,
On Wed, May 12, 2010 at 05:19:38PM +0530, Ajay Kumar Gupta wrote:
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA
Hi,
-Original Message-
From: Felipe Balbi [mailto:m...@felipebalbi.com]
Sent: Wednesday, May 12, 2010 11:26 PM
To: Sergei Shtylyov
Cc: Gupta, Ajay Kumar; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Subject: Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL
Hi,
Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on
RTL-1.4
Felipe Balbi wrote:
On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote:
MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels
are
simultaneously enabled which results
The SGX powervr_device is registered with it's platform specific
data to provide information about setting constraint through
omap_pm_set_min_bus_tput.
Signed-off-by: Preshit Agarwal preshit.agar...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin
- Update the omap3_defconfig to sync up with the generated .config
- Increase CONFIG_LOG_BUF_SHIFT to 16 to allow the entire
boot log to be captured
(useful when using boot time tracer, for example)
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/configs/omap3_defconfig | 116
Tony Lindgren wrote:
* Stanley.Miao stanley.m...@windriver.com [100419 23:20]:
There is two gpio for mmc use, one is for card detecting, another is
used for checking write protect. Intialize its pinmux in case the bootloader
doesn't set it.
Signed-off-by: Stanley.Miao
Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [100420 00:03]:
snip
There are three i2c buses on am3517, now rename these three boardinfo
structure name to am3517evm_i2c1_boardinfo, am3517evm_i2c2_boardinfo,
and am3517evm_i2c3_boardinfo, to make it more readable.
72 matches
Mail list logo
