Han Wang wrote:
Hi,
I am testing the 2.6.35-rc1 pm branch code on Overo. The system
boots ok. (I can provide booting log if that is necessary) However,
when I use echo mem /sys/power/state to send overo to sleep and
wake it up by enter a key into serial console. I got garbage
characters in
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:10 PM
To: Varadarajan, Charulatha
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:53 PM
To: Varadarajan, Charulatha
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Varadarajan, Charulatha
Sent: Wednesday, June 16, 2010 12:25 PM
To: Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com;
* Felipe Contreras felipe.contre...@gmail.com [100611 19:03]:
On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
unless someone can convince him not to.
Huh? I thought he was
Mathieu Poirier mathieu.poir...@canonical.com wrote:
On Tue, 2010-06-15 at 20:58 +0530, Venkatraman S wrote:
Mathieu Poirier mathieu.poir...@canonical.com wrote:
HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
Driver: mmci-omap-hs
I am faced with an SDHC card
Hi,
On Wed, Jun 16, 2010 at 08:09, Michael Trimarchi
mich...@panicking.kicks-ass.org wrote:
Han Wang wrote:
Hi,
I am testing the 2.6.35-rc1 pm branch code on Overo. The system
boots ok. (I can provide booting log if that is necessary) However,
when I use echo mem /sys/power/state to send
-Original Message-
From: Shilimkar, Santosh
Sent: Wednesday, June 16, 2010 12:51 PM
To: Varadarajan, Charulatha; Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org; linux-omap@vger.kernel.org; p...@pwsan.com; Nayak, Rajendra;
On 6/16/2010 8:54 AM, Varadarajan, Charulatha wrote:
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:10 PM
Hi Charu,
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds gpio_dev_attr to OMAP4 gpio hwmod structure. This patch
also
On 6/16/2010 9:21 AM, Shilimkar, Santosh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Varadarajan, Charulatha
Sent: Wednesday, June 16, 2010 12:25 PM
To: Cousson, Benoit
Cc: davi...@pacbell.net;
From: ext Felipe Contreras felipe.contre...@gmail.com
Subject: [PATCH v4 00/14] omap: mailbox: bunch of cleanups
Date: Fri, 11 Jun 2010 17:51:35 +0200
From: Felipe Contreras --global
Hi,
These are hopefully non-functional changes. Just shuffling code around, and
removing unecessary stuff.
On Mon, 31 May 2010, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [100520 02:05]:
Hi,
On Wed, 19 May 2010, Santosh Shilimkar wrote:
This patch uses ENABLE_ON_INIT flag on the emif clock nodes
to avoid the emif clk getting cut as part of reset un-used clock
routine which
On 6/16/2010 10:46 AM, Varadarajan, Charulatha wrote:
-Original Message-
From: Shilimkar, Santosh
Sent: Wednesday, June 16, 2010 12:51 PM
To: Varadarajan, Charulatha; Cousson, Benoit
Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org;
Hi,
When I started with RFC patch DSS: Movement of base addr, silicon specific
data from driver to platform_device, I see a lot of encapsulation of OMAP
DSS IPs into the omapdss driver.
The previous RFC patch would only be good enough to handle base address and
IRQ for multi-omap. But it
On Wed, 2010-06-16 at 12:52 +0200, ext Guruswamy, Senthilvadivu wrote:
Hi,
When I started with RFC patch DSS: Movement of base addr, silicon specific
data from driver to platform_device, I see a lot of encapsulation of OMAP
DSS IPs into the omapdss driver.
The previous RFC patch would
The following set of patches applies on top of for-next branch.
And these are the patches required to enable nand (nor and onenand for sdp
only) for different platform.
v3: patch rebase on latest nand patch and depend on -
rename board-sdp-flash.c(board-flash.c) and board-sdp.h(board-flash.h) to
used by other board e.g. zoom
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/board-3430sdp.c| 16 ++-
update config file to support for NAND in zoom2.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/configs/omap_zoom2_defconfig | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
arch/arm/configs/omap_zoom2_defconfig
diff --git
patch adds NAND support to LDP board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-ldp.c | 35 +++
2 files changed, 36 insertions(+), 0
update config file to support for NAND on zoom3 board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/configs/omap_zoom3_defconfig | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
arch/arm/configs/omap_zoom3_defconfig
diff --git
update config file to support for NAND, OneNAND, NOR on omap 3630-sdp board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/configs/omap_3630sdp_defconfig | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git
add support for NAND, OneNAND, NOR on omap 3630-sdp board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-3630sdp.c | 120 +++
2 files changed, 121 insertions(+), 0 deletions(-)
diff
patch adds NAND support to zoom3 board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom3.c | 43 +
2 files changed, 44 insertions(+), 0
This patch adds NAND support to ZOOM2 board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom2.c | 43 +
Hi Linus,
Please pull these two fixes for the OMAP framebuffer driver.
Tomi
The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e:
Linus Torvalds (1):
Linux 2.6.35-rc1
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git
Changes from v1:
* Incorporated : OMAP clock: Add uart4_ick/fck definitions for 3630
* using omap_mux_request_signal to retreive padconf offset
as per Tony's comments.
http://marc.info/?l=linux-omapm=127609369220618w=2
This patch series as a dependecy on the patch
for
Add uart4 clock data.
This is only valid for omap 36xx family of chips.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 22 ++
1 files
To standarize among other uarts (1 to 3), we shall now:
- Enable uart4 autodile bit.
- Enable uart4 wakeup in PER.
- Allow uart4 to wakeup the MPU.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY on UART3.
- Muxmode usage needed for uart4 for 3630, for padconf
wakeup on uart4_rx line. uart4_rx signal is available
under mode-2 in gpmc_wait3. Thus have to ensure
Add prepare idle and resume idle call for uart4 used by 3630.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
Avoid using hwmod lookup using name string rather
retreive port info using the hwmod class interface.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 ++---
1 files changed,
From 53711271c3f22c8038f4961a9f9c2035b3e82d7f Mon Sep 17 00:00:00 2001
From: Sujeet Baranwal s-baran...@ti.com
Date: Tue, 1 Jun 2010 19:29:24 +0530
Subject: [PATCH] OMAP: DSS2: Switching GFX from LCD to TV
1. Added a sysfs entry for setting overlay input_size
in order to switch the GFX pipeline
Hi, Jean,
Yes I looked at the the OMAP_Power_management page, but the known
problem section doesn't seem to describe my problem.
What I am encountering is that the serial console does output
correctly after resume, but everything goes south after a few lines,
thus, the garbage strings...
Hello Paul,
I wanted to close on the introduction of two new OMAP device APIs
omap_device_enable_wakeup () omap_device_disable_wakeup() in omap_device
layer.
These APIs are potentially needed by the USB driver (via function pointers) to
work around some USB erratum.
Alternatively, can we
Hi, michael,
I have the no_console_suspend option in my boot command line, I am
not sure if that is the option you were trying to point me to in the
last email?
anyway, I added no_debug_console into my boot command arg, but that
doesn't seem to help with my problem.
any ideas?
Thanks,
Hi
Han Wang wrote:
Hi, michael,
I have the no_console_suspend option in my boot command line, I am
not sure if that is the option you were trying to point me to in the
last email?
I have said that i have no problem when I remove that option.
Can you try to echo 0 to timeout of the serial
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Basak, Partha
Sent: Wednesday, June 16, 2010 8:10 PM
To: p...@pwsan.com
Cc: khil...@deeprootsystems.com; Kalliguddi, Hema; Nayak, Rajendra; linux-
o...@vger.kernel.org
On 6/16/2010 8:54 AM, Varadarajan, Charulatha wrote:
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:10 PM
Hi Charu,
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds gpio_dev_attr to OMAP4 gpio hwmod structure. This
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access gpio
APIs.
Hence gpio_init is
Keyboard controller for OMAP4 includes
- built-in scanning algorithm
- debouncing feature
- handling mechanism up to 9 x 9 keys
- wake-up event generation
Tested using SDP4430 board in Kevin Hillman's tree,
pm-wip/hwmods-omap4 branch
---
v1
OMAP4 keyboard controller includes:
- built-in scanning algorithm
- debouncing feature
Driver implementation is based on matrix_keypac.c
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Abraham Arce x0066...@ti.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
Register keyboard device with hwmod framework
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/devices.c | 50 +
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c
* Paul Walmsley p...@pwsan.com [100616 12:16]:
On Mon, 31 May 2010, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [100520 02:05]:
Hi,
On Wed, 19 May 2010, Santosh Shilimkar wrote:
This patch uses ENABLE_ON_INIT flag on the emif clock nodes
to avoid the emif clk
Keyboard support for SDP OMAP4430
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 99 +++
1 files changed, 99 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
From: Syed Rafiuddin rafiuddin.s...@ti.com
Update OMAP4430 configuration to enable OMAP4 keyboard driver
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/configs/omap_4430sdp_defconfig |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
On Mon, May 17, 2010 at 1:02 PM, felipe.ba...@nokia.com wrote:
From: Felipe Balbi felipe.ba...@nokia.com
stop using the omap-specific implementations for gpio
debouncing now that gpiolib provides its own support.
hmm, this gives me:
[0.00] WARNING: at drivers/gpio/gpiolib.c:104
On 6/16/2010 5:41 PM, Varadarajan, Charulatha wrote:
On 6/16/2010 8:54 AM, Varadarajan, Charulatha wrote:
From: Cousson, Benoit
Sent: Tuesday, June 15, 2010 10:10 PM
Hi Charu,
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch adds
On 6/15/2010 5:05 PM, Varadarajan, Charulatha wrote:
From: Charulatha Vch...@ti.com
This patch implements GPIO as a platform device. Also it
implements OMAP2PLUS specific GPIO as HWMOD FW adapted device.
OMAP2PLUS GPIO uses runtime APIs.
GPIO APIs are used in machine_init functions. Hence it
You can do a telnet to the device... you should be able to work with it but
your serial session will show the garbage.
Regards,
Rene
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Michael Trimarchi
Sent: Wednesday,
On Mon, Jun 14, 2010 at 11:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote:
As pointed by Ben Ohand, the variable rq_full flag is a global
variable, so if there are multiple mailbox users there will be
conflics. Now there is a full flag per mailbox queue.
Reported-by: Ohad Ben-Cohen
The TRM and the OMAP FB driver have different ideas about the widths
of various bit fields in the DISPC_TIMING_{H,V} registers. This patch
is based on what the TRM (TI document SPRUF98G) says.
Note: this patch changes the meanings of the vertical timing values
by one scan line. It still works
On Wed, 2010-06-16 at 14:13 +0530, Venkatraman S wrote:
Mathieu Poirier mathieu.poir...@canonical.com wrote:
On Tue, 2010-06-15 at 20:58 +0530, Venkatraman S wrote:
Mathieu Poirier mathieu.poir...@canonical.com wrote:
HW: Beagleboard rev. C2 and C4
Processor: OMAP3
Kernel: 2.6.35-rc2
From: Ramirez Luna, Omar
driver version 0.3
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/rmgr/drv_interface.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Pushed to dspbridge.
- omar
--
To unsubscribe from this list: send the line unsubscribe
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Hi,
A few trivial patches. The important one is the fix to build when MCBSP is
disabled.
Felipe Contreras (4):
dspbridge: fix build when OMAP_MCBSP=n
dspbridge: dev: fix dev_create_device()
dspbridge: remove _tiomap_mmu.h
As per new naming convention for hwmods, remove the redundant _hwmod suffix
from all hwmod names.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +++---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +++---
Add a new hwmod class for DSP devices. To be used when hwmods
are created for DSP on OMAP3 (a.k.a. IVA2.)
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_common_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
2 files changed,
The current OPP layer is based on a unique identifier (OPP_MPU,
OPP_DSP, OPP_L3) which is not terribly portable or scalable for future
devices.
Since we'd also like to be able to manage OPPs for any device (as
recently agreed upon during an OMAP PM meeting in TI Bangalore[1]), this
patch changes
The omap_hwmod struct has a field to track the omap_device that is
attached to it, but it was not being assigned. Fix by assigning omap_device
pointer when omap_device is built.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/omap_device.c |8 ++--
1 files
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the omap_device and
hwmod level.
Because these omap_devices are based on platform_devices, they cannot
be created until the
FIXME: this should be fixed in the SR/voltage v4 series
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/voltage.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index
DROP ME: this should be fixed in SR/voltage v4 series
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/sr_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index
Update usage of OPP API to use new device-based API. This requires
getting the 'struct device' for the MPU and using that with the OPP
API.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/cpu-omap.c | 12
1 files changed, 8 insertions(+), 4
The current OPP layer is based on a unique identifier (OPP_MPU,
OPP_DSP, OPP_L3) which is not terribly portable or scalable for future
devices.
Since we'd also like to be able to manage OPPs for any device, this
patch changes the OPP API to be device-based instead of unique-ID
based.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/resource34xx.c | 95 ++-
1 files changed, 60 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/omap-pm-srf.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-pm-srf.c
index 5ebcda3..bf9163e 100644
---
Add hwmod data for DSP on OMAP3 (a.k.a. IVA2.)
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 41
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
The OPP API has changed to a device-based API. This patch updates
the usage of that API in the voltage layer.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/voltage.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git
Basak, Partha p-bas...@ti.com writes:
I wanted to close on the introduction of two new OMAP device APIs
omap_device_enable_wakeup () omap_device_disable_wakeup() in
omap_device layer.
These APIs are potentially needed by the USB driver (via function
pointers) to work around some USB
Kevin,
Kevin,
There is no errata in the USB which needs the Enable/Disable wakeup to be done
Seperately. If it can be handled with omap_devie_enable/idle Apis it is
sufficient.
But there is a need of setting the Auto idle bit seperately as for the USBOTG
there is a need to set the Autoidle
Hi,
On Wed, Jun 16, 2010 at 07:26:30PM +0200, ext Grazvydas Ignotas wrote:
hmm, this gives me:
yeah, funny thing is that this patch was cooking in the mailing list for
over a month since I said I didn't have the boards and they were
compile-tested only. Anyways,
[0.00] WARNING:
When switching between clocks, The new functional clock is
effective when the next vertical blanking interval occurs.
GOLCD bit has to be set for the new clock to take effect.
Signed-off-by: Kishore Y kishor...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Rajkumar N
71 matches
Mail list logo
