omap 4430sdp board support for the proximity sensor via GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
- Making the default state of the sensor off at bootup
- The init is called before platform_add_devices
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 31, 2010 9:32 PM
To: Datta, Shubhrajyoti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap: 4430sdp board support for the the GPIO keys
Shubhrajyoti D shubhrajy...@ti.com
In omap_vout_calculate_offset(), cur_display is assigned ovl-manager-device,
but
isn't used for anything. The corresponding code is removed.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device
On Wed, 1 Sep 2010 01:12:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, August 31, 2010, Mark Brown wrote:
On Mon, Aug 30, 2010 at 11:43:23AM -0700, Kevin Hilman wrote:
Vishwanath BS vishwanath...@ti.com writes:
In current i2c core driver, pm_runtime_set_active call from
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 24, 2010 5:41 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha; Nayak,
Rajendra; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv2
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 24, 2010 5:49 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Basak, Partha; Shilimkar, Santosh;
Gopinath, Thara; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv2
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 24, 2010 5:52 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv2 0/13] OMAP: dmtimer: hwmod
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 24, 2010 5:37 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha; Nayak,
Rajendra; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv2
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 24, 2010 4:59 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha; Nayak,
Rajendra; Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv2
kishore kadiyala wrote:
OMAP4 not only have newly added hsmmc registers but also
have registers which were there in OMAP3 and which doesn't
have a common offset deviation compared to OMAP3.
For generic handling, OMAP3 and OMAP4 has different array's of
register offset maintained and right one
On Wed, Sep 1, 2010 at 5:56 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
kishore kadiyala wrote:
OMAP4 not only have newly added hsmmc registers but also
have registers which were there in OMAP3 and which doesn't
have a common offset deviation compared to OMAP3.
For generic handling,
Gopinath, Thara th...@ti.com writes:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Wednesday, September 01, 2010 5:33 AM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com
Subject: [PATCH 2/2] OMAP:
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
[...]
+static void omap2_dm_timer_enable(struct platform_device *pdev)
+{
+ if (!pdev) {
+ dev_err(pdev-dev, %s: invalid pdev\n, __func__);
+ return;
+ }
+ pm_runtime_get_sync(pdev-dev);
+}
+
+static
[removed non-OMAP folks]
Vishwanath BS vishwanath...@ti.com writes:
In current i2c core driver, pm_runtime_set_active call from
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from i2c_device_pm_suspend.
pm_runtime_set_active called from resume path will increase the
On Wed, 11 Aug 2010, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
Currently omap_hwmod_mutex is being used to protect both the list
access/modification and concurrent access to hwmod functions. This
patch separates these two types of locking.
First, omap_hwmod_mutex is used
From: Kevin Hilman khil...@ti.com
This reverts commit 0007122ad85cc36b1c18c0b59344093ca210d206.
The dereference method of checking for a valid omap_device when
wrapping a platform_device is rather unsafe and dangerous.
Instead, a better way of checking for a valid omap-device is
to use a common
From: Kevin Hilman khil...@ti.com
In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new omap_bus device.
Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.
Users of this feature
On Tue, Aug 31, 2010 at 09:59:44AM +0100, David Vrabel wrote:
On 27/08/2010 20:22, Chris Ball wrote:
Hi David,
On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote:
These patches add support for SDIO cards to the omap_hsmmc driver.
Power management changes to prevent SDIO cards
This patchset adds wl1271 support on ZOOM2/3 boards.
Only basic support is included; MMC power manipulation part is submitted
separately as Runtime PM migration.
Changes since v4:
- Introduce a simple (yet safe) mechanism to pass platform-specific data to the
driver, as suggested by Russell
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c |2 +-
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as bringing up
(and down) sdio functions.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271.h |2
Add a simple mechanism to pass platform data to the
SDIO instances of wl12xx.
This way there is no confusion over who owns the 'embedded data',
typechecking is preserved, and no possibility for the wrong driver to
pick up the data.
Originally proposed by Russell King.
Signed-off-by: Ohad
Remove the hard coded irq information, and instead take
the irq information from the board's platform data.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271_sdio.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git
The wl1271 device is using a reference clock that may change
between board to board.
Make the ref_clock parameter configurable by the board
files that set up the device, instead of having a hard coded
value in the driver source itself.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Add MMC3 support on ZOOM, which is hardwired to the wl1271 device.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git
On Mon, 23 Aug 2010, Cousson, Benoit wrote:
Here is a small patch that should fix that issue:
The approach is quite basic, I'm just enabling all the optional clocks if the
flag is set.
Could you give it a try?
This approach seems good. Maybe we should add a flags field in
struct
Thara Gopinath th...@ti.com writes:
This patch introduces a user list of devices associated with each
voltage domain instance. The user list is implemented using plist
structure with priority node populated with the voltage values.
This patch also adds an API which will take in a device and
Thara Gopinath th...@ti.com writes:
This patch adds an API in the opp layer that
can be used by the voltage layer to get a list of all the
scalable devices belonging to a particular voltage domain.
This API is to be typically called only once by the voltage
layer per voltage domain instance
This patch fixes a regression introduced by the OMAP: UART: drop
OMAP_TAG_UART, enable all UARTs, auto-disabled on idle patch.
Signed-off-by: David Barksdale amatus.amon...@gmail.com
---
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index
31 matches
Mail list logo
