Oops my fault will correct it and repost ...
Regards,
Kishore
On Tue, Aug 31, 2010 at 11:25 AM, Matt Fleming m...@console-pimps.org wrote:
On Mon, Aug 30, 2010 at 11:18:23PM +0530, kishore kadiyala wrote:
Adding card detect callback function and card detect configuration
function for
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 5:40 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Cousson,
Benoit; Paul Walmsley
Subject:
On Tue, Aug 31, 2010 at 10:28 AM, Sripathy, Vishwanath
vishwanath...@ti.com wrote:
-Original Message-
From: Silesh C V [mailto:sailes...@gmail.com]
Sent: Tuesday, August 31, 2010 9:53 AM
To: Sripathy, Vishwanath
Cc: Kevin Hilman; vishwanath.sripa...@linaro.org;
On Thursday 26 August 2010 23:56:49 ext G, Manjunath Kondaiah wrote:
From: Manjunatha GK manj...@ti.com
Fixes sparse warning for the below error
drivers/mfd/twl4030-codec.c:118:5: error: symbol
'twl4030_codec_disable_resource' redeclared with different type
(originally declared at
Hi,
this is audio related file, so use the alsa-devel for this patch, and also CC
the maintainers (Jarkko, Liam, Mark, and me).
On Thursday 26 August 2010 23:56:44 ext G, Manjunath Kondaiah wrote:
From: Manjunatha GK manj...@ti.com
This patch fixes sparse warning due non declaration of
McBSP SRG (Sample Rate Generator) and FSG (Frame Sync
Generator) is only needed to be enabled, when McBSP
is master.
In McBSP slave mode, the SRG, and FSG can be kept disabled,
which might save some power at the end in this configuration.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
-Original Message-
From: Gopinath, Thara
Subject: RE: [PATCH v2] omap: 4430sdp board support for the the GPIO keys
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of
Shubhrajyoti D
Sent: Tuesday, August
Hi,
Does anyone want to comment on this?
Thanks,
Dmitry
On 20/08/10 16:44, Kasatkin Dmitry (Nokia-MS/Helsinki) wrote:
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
Hi,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 5:44 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Basak, Partha; Felipe Balbi; Tony Lindgren; Cousson, Benoit;
Paul Walmsley
Subject: Re:
Hi,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 5:12 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Basak, Partha; Felipe Balbi; Tony Lindgren; Cousson, Benoit;
Paul Walmsley
Subject:
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 from being turned off
and losing all state, and card interrupts.
-Original Message-
From: sailes...@gmail.com [mailto:sailes...@gmail.com] On Behalf Of C V,
Silesh
Sent: Tuesday, August 31, 2010 12:27 PM
To: Sripathy, Vishwanath
Cc: Kevin Hilman; vishwanath.sripa...@linaro.org; linux-omap@vger.kernel.org;
linaro-...@lists.linaro.org
Subject:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, August 25, 2010 2:01 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 02/20] Move DSS driver register from
board to
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, August 25, 2010 6:43 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 16/20] Get DISPC base addr with platform device
On
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, August 25, 2010 2:20 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 05/20] Move dss platform driver to dss.c
On Mon,
1. Input transport via evdev is very convenient
2. There is no other standard alternative
Once there is standard interface for such sensors they will happily use
it and will not look back.
I think the fact that most of the interest in IIO is how do we make an
IIO/Input bridge speaks
IIO which is currently in staging.
Except we had ALS before that as a layer and Linus vetoed it. So there is
zero faith in IIO ever going anywhere.
Instead we now have about ten different light sensor APIs to the point
developers are writing a toolkit userspace plugin for *each* sensor.
--
To
To this actually.
Thanks
On 20/08/10 16:44, Kasatkin Dmitry (Nokia-MS/Helsinki) wrote:
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
drivers/crypto/Kconfig|8 +
drivers/crypto/Makefile |1 +
drivers/crypto/omap-aes.c | 948
My hope is that we can make use of a well known and uniform
API for all input devices in a device, be it a keypad,
touchscreen, accelerometer, magnetometer, gyro, or whatever.
If only we could agree what input devices are...
Is that the right test for some of these devices.
Surely
Locked .ioctl is gone from struct file_operations by commit b19dd42
so these cbus drivers don't compile. Also it seems there is no need for BKL
anyway in these drivers.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Felipe Balbi m...@felipebalbi.com
---
drivers/cbus/retu-user.c |5
This 'legacy' OMAP2420 McBSP2 muxing code is currently broken after recent
conversion to new mux code. The omap_mcbsp_request calling this code is
usually called after booting whereas the omap_mux_init_signal is __init
marked so null pointer dereference would occur.
Fix this by removing the
On Tue, 31 Aug 2010 11:11:44 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
McBSP SRG (Sample Rate Generator) and FSG (Frame Sync
Generator) is only needed to be enabled, when McBSP
is master.
In McBSP slave mode, the SRG, and FSG can be kept disabled,
which might save some power at
On Tuesday 31 August 2010 13:12:56 ext Jarkko Nikula wrote:
This 'legacy' OMAP2420 McBSP2 muxing code is currently broken after recent
conversion to new mux code. The omap_mcbsp_request calling this code is
usually called after booting whereas the omap_mux_init_signal is __init
marked so null
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
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from i2c_device_pm_suspend.
pm_runtime_set_active
On Tue, 31 Aug 2010 13:09:11 +0300, Jarkko Nikula jhnik...@gmail.com
wrote:
Locked .ioctl is gone from struct file_operations by commit b19dd42
so these cbus drivers don't compile. Also it seems there is no need for
BKL
anyway in these drivers.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
On 08/31/10 10:44, Alan Cox wrote:
1. Input transport via evdev is very convenient
2. There is no other standard alternative
Once there is standard interface for such sensors they will happily use
it and will not look back.
I think the fact that most of the interest in IIO is how do we
On Tue, Aug 31, 2010 at 11:52:27AM +0300, Dmitry Kasatkin wrote:
Hi,
Does anyone want to comment on this?
Please be patient. Your patches are still in my queue. Resending
them is only going to slow them down.
Thanks,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page:
On 08/31/10 10:46, Alan Cox wrote:
IIO which is currently in staging.
Except we had ALS before that as a layer and Linus vetoed it. So there is
zero faith in IIO ever going anywhere.
I have more faith - those developing it have limited time, but we will get
there. (another plug for anyone
-Original Message-
From: Cousson, Benoit
Sent: Friday, August 27, 2010 7:25 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 10/20] Move rfbi init to rfbi probe
On 8/23/2010 5:57 PM,
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, August 24, 2010 3:13 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 15/20] Use platform device to get DSS base addr
On
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, August 24, 2010 3:10 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com; Hilman, Kevin
Subject: Re: [RFC PATCH 00/20] HWMOD Adaptation for DSS
On 8/23/2010 5:57 PM,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, August 27, 2010 5:22 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com
Subject: Re: [PATCH 04/20] Create platform_driver for each DSS
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, August 27, 2010 5:03 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com
Subject: Re: [PATCH 03/20] Build omap_device for each DSS HW IP
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, August 27, 2010 5:01 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com
Subject: Re: [PATCH 01/20] DSS HWMOD database generation for
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, August 27, 2010 5:28 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com
Subject: Re: [RFC PATCH 00/20] HWMOD Adaptation for DSS
On Tuesday 31 August 2010 01:43 PM, Felipe Balbi wrote:
On Tue, 31 Aug 2010 10:53:36 +0530, kishona0393...@ti.com wrote:
Though driver shouldn't be using hwmod directly, there is no
corresponding API in omap_device to do the same. So we are planning to
store the omap_hwmod
Kalliguddi, Hema hem...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 5:40 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren;
Kalliguddi, Hema hem...@ti.com writes:
static int musb_platform_resume(struct musb *musb)
{
u32 l;
+struct device *dev = musb-controller;
+struct musb_hdrc_platform_data *pdata = dev-platform_data;
+struct platform_device *pdev = to_platform_device(dev);
if
Guruswamy, Senthilvadivu svad...@ti.com writes:
[...]
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
It's not customary to create
Guruswamy, Senthilvadivu svad...@ti.com writes:
[...]
From: Senthilvadivu Guruswamy svad...@ti.com
Looks up the HWMOD database for each of the given DSS HW IP
and builds omap_device which inturn does the platform device
register for each of DSS HW IP
Signed-off-by: Senthilvadivu
omap 4430sdp board support for the 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
---
Shubhrajyoti D shubhrajy...@ti.com writes:
omap 4430sdp board support for the 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:
On 8/31/2010 4:41 PM, ABRAHAM, KISHON VIJAY wrote:
On Tuesday 31 August 2010 01:43 PM, Felipe Balbi wrote:
On Tue, 31 Aug 2010 10:53:36 +0530, kishona0393...@ti.com wrote:
Though driver shouldn't be using hwmod directly, there is no
corresponding API in omap_device to do the same.
On Tue, Aug 31, 2010 at 10:44:46AM +0100, Alan Cox wrote:
1. Input transport via evdev is very convenient
2. There is no other standard alternative
Once there is standard interface for such sensors they will happily use
it and will not look back.
I think the fact that most of the
On 8/31/2010 2:57 PM, Guruswamy, Senthilvadivu wrote:
-Original Message-
From: Cousson, Benoit
Sent: Friday, August 27, 2010 7:25 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 10/20] Move
If non-input uses later need non-input interfaces they can switch to that
with an input bridge when there is one and when it happens, which
probably won't.
Would there even be an argument which subsystem to use if IIO-input
bridge existed today? Because if the answer is no then push into
On Tue, Aug 31, 2010 at 05:59:37PM +0100, Alan Cox wrote:
If non-input uses later need non-input interfaces they can switch to that
with an input bridge when there is one and when it happens, which
probably won't.
Would there even be an argument which subsystem to use if IIO-input
IMHO I think sensors no more can be considered as non-input-devices.
Things changed too much in recent years. Input sources have now a
very different use as before (smartphones, Tablets and handheld
devices...)
They all have much inputs that come mostly from sensors.
So the definition of an input
linux-iio cc'd for comments on the code dump at end of email..
On 08/31/10 17:59, Alan Cox wrote:
If non-input uses later need non-input interfaces they can switch to that
with an input bridge when there is one and when it happens, which
probably won't.
Would there even be an argument which
On 08/31/10 18:24, Mohamed Ikbel Boulabiar wrote:
IMHO I think sensors no more can be considered as non-input-devices.
Things changed too much in recent years. Input sources have now a
very different use as before (smartphones, Tablets and handheld
devices...)
They all have much inputs that
On Mon, 30 Aug 2010, Linus Torvalds wrote:
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
But do you believe that input should be the primary residence for the
devices when they are only _sometimes_ used as input devices? Or it
would make sense to employ a
snip
Anyhow, here is a code dump of a very nasty proof of concept for an IIO
to input bridge in userspace. If I'd known it would be this easy I'd
have done this ages ago. I'm away for next couple of days, so a more
general version won't occur until next week unless someone else picks it
OK, so let's say we start moving some of the devices into input. Which
ones we consider suitable for input? I guess some 3-digit
accelerometers, what else? Also, what new event types would we need?
Let's take GPS - I do not think that ABS_X and ABS_Y are the best events
to be used for such
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
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call
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
-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: omap_device: make all devices a child of
57 matches
Mail list logo
