On Wed, 10 Aug 2011, David Gibson wrote:
The difficulty with adding th enames to the DT itself is that it
exposes the essentially Linux-specific names in what's supposed to be
an OS neutral data structure.
The names are supposed to pertain to the hardware IP block, not the OS.
See for
On Wed, Aug 10, 2011 at 11:09 AM, Rajendra Nayak rna...@ti.com wrote:
On 8/10/2011 11:00 AM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayakrna...@ti.com wrote:
On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
This is in continuation of patch series posted
Hi
On Tue, 9 Aug 2011, Mohammed, Afzal wrote:
This is regarding board with multiple variations using an upcoming SoC from
TI.
Variation of the board is detected by reading EEPROM using I2C after
init_machine gets invoked. In one of the variation UART# used is different.
Because of this
On Tue, 9 Aug 2011, Paul Walmsley wrote:
On Tue, 9 Aug 2011, Tony Lindgren wrote:
Hmm, there are also these when CONFIG_ARCH_OMAP4 is not selected:
arch/arm/mach-omap2/built-in.o: In function `_enable_module':
arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to
Hi
On Tue, 09 Aug 2011 19:10:22 +0500
G, Manjunath Kondaiah manj...@ti.com wrote:
From: Kevin Hilman khil...@ti.com
For converting from struct device to platform_device, and from
platform_device to struct device, there are existing macros. Use
them instead of manual use of container_of().
On Wed, 10 Aug 2011, David Gibson wrote:
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order.
Most ARM SoC Linux ports aren't using DT now, so there isn't really an
older OS case here. Might as well try to get
On Tue, Aug 09, 2011 at 11:26:16PM -0600, Paul Walmsley wrote:
On Mon, 8 Aug 2011, Russell King - ARM Linux wrote:
On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
With CONFIG_ARCH_OMAP3=y and
2011/8/9 Russell King - ARM Linux li...@arm.linux.org.uk:
Consolidate 24 trivial gpiolib implementions out of mach/gpio.h
into asm/gpio.h. This is basically the include of asm-generic/gpio.h
and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep
as described in
* Paul Walmsley p...@pwsan.com [110809 20:01]:
On Tue, 9 Aug 2011, Tony Lindgren wrote:
Hmm, there are also these when CONFIG_ARCH_OMAP4 is not selected:
arch/arm/mach-omap2/built-in.o: In function `_enable_module':
arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to
* Peter Ujfalusi peter.ujfal...@ti.com [110809 05:31]:
Avoid compiling code for OMAP arch which is not selected by the
config.
Fixes issues like:
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to
* Russell King - ARM Linux li...@arm.linux.org.uk [110810 00:21]:
On Tue, Aug 09, 2011 at 11:26:16PM -0600, Paul Walmsley wrote:
On Mon, 8 Aug 2011, Russell King - ARM Linux wrote:
On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
On Monday 08 August 2011 04:30 PM, Russell King
* Paul Walmsley p...@pwsan.com [110809 23:51]:
On Tue, 9 Aug 2011, Paul Walmsley wrote:
On Tue, 9 Aug 2011, Tony Lindgren wrote:
Hmm, there are also these when CONFIG_ARCH_OMAP4 is not selected:
arch/arm/mach-omap2/built-in.o: In function `_enable_module':
On Wed, 10 Aug 2011, Tony Lindgren wrote:
Thanks yes that does the trick. I'd like to queue this immediately so we
have more time to look at the other fixes if you don't mind.
That's fine, feel free to send this first. Will try to have the rest of
my 3.1-rc fixes ready to go in a few days.
Manju,
On 8/10/2011 9:07 AM, Jarkko Nikula wrote:
Hi
On Tue, 09 Aug 2011 19:10:22 +0500
G, Manjunath Kondaiahmanj...@ti.com wrote:
From: Kevin Hilmankhil...@ti.com
For converting from struct device to platform_device, and from
platform_device to struct device, there are existing macros.
I would like to submit some patches to add support for a new OMAP board...
Is there a right or wrong time to post such patches to this list? How
does the kernel merge window effect what kind of patches are expected
here on the OMAP list?
What should I use as the base for my patches? At
* Michael Jones michael.jo...@matrix-vision.de [110810 03:14]:
I would like to submit some patches to add support for a new OMAP board...
Is there a right or wrong time to post such patches to this list? How
does the kernel merge window effect what kind of patches are expected
here on the
Am 04.08.2011 17:59, schrieb Abhilash K V:
This patch-set gets the kernel booting up on a AM3517 EVM.
The board is able to boot with ramdisk after this,but the MMC and Ethernet
drivers are not up yet. Lots of warnings remain which will be addressed in
subsequent patches.
Are there some more
* Tony Lindgren t...@atomide.com [110809 04:09]:
* Kevin Hilman khil...@ti.com [110804 08:38]:
Hi Tony,
Here's my current collection of PM-related fixes for the -rc cycle.
They are based on the next/board branch of Arnd's arm-soc tree (which
has already been merged by Linus) and are
ping.
On Mon, Aug 8, 2011 at 1:15 PM, Maxin B. John maxin.j...@gmail.com wrote:
The pointer va returned from phys_to_virt(pa) is never used in
sgtable_fill_kmalloc().So,it is safe to remove this set-but-unused variable.
Signed-off-by: Maxin B. John maxin.j...@gmail.com
---
diff --git
* Maxin B John maxin.j...@gmail.com [110810 04:06]:
ping.
Sorry I've been on vacation, applying to fixes.
Regards,
Tony
On Mon, Aug 8, 2011 at 1:15 PM, Maxin B. John maxin.j...@gmail.com wrote:
The pointer va returned from phys_to_virt(pa) is never used in
sgtable_fill_kmalloc().So,it
* Hemant Pedanekar hema...@ti.com [110809 20:46]:
If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource,
the
timer stops counting once overflow occurs as it was not set in autoreload
mode.
This results into timekeeping failure: for example, 'sleep 1' at the shell
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
The omap dt requires new omap hwmod api to be added for in order
to support omap dt.
Both the subject and the changelog are misleading. You are not doing any
hwmod stuff in it.
You are just passing an of_node pointer during
* Thomas Meyer tho...@m3y3r.de [110806 02:24]:
From: Thomas Meyer tho...@m3y3r.de
Use kstrdup rather than duplicating its implementation
Thanks applying to fixes.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
* Johan Hovold jhov...@gmail.com [110809 09:23]:
Since 7203f8a48bb63015ebe58a6f2a38aec1cb208b9d (arm: mach-omap2: remove
NULL board_mux from board files) NULL board_mux is defined in mux.h.
Thanks applying to fixes.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add pd_size in the AUXDATA structure so that device drivers which require
platform_data size can pass along with AUXDATA.
It is really needed by device driver? Or is it because omap_device_build
is using platform_device_add_data that is doing
* Kevin Hilman khil...@ti.com [110802 17:00]:
On 08/02/2011 04:14 PM, Kevin Hilman wrote:
[...]
Looks like I forgot the i2c driver changes that also should be
merged by us. Those are acked by Ben Dooks, Kevin's pull request
for that is at:
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space if
the temperature crosses user defined thresholds via kobject_uevent interface.
The user is allowed to configure the temperature thresholds vis sysfs
Tony Lindgren wrote on Wednesday, August 10, 2011 5:21 PM:
* Hemant Pedanekar hema...@ti.com [110809 20:46]:
If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as
clocksource, the timer stops counting once overflow occurs as it was not
set in autoreload mode. This results into
From: Benoit Cousson b-cous...@ti.com
OMAP4460 temperature sensor hwmod cannot be auto generated
since it is part of ctrl module. Hence populating the
necessary hwmod info manually.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
OMAP4460 specific temperature sensor register bit fields are added.
Signed-off-by: Keerthy j-keer...@ti.com
---
.../include/mach/ctrl_module_core_44xx.h | 70
1 files changed, 57 insertions(+), 13 deletions(-)
diff --git
Hello,
The rfc patch series for the on die temperature sensor driver. I need
feedback on the overall structure of the driver.
The rfc patch set has the device file, omap4 on die temperature sensor
hwmon driver. hwmod, clk support. The patch set compiles
on top of LO tree Master branch.
This
The device file adds the device support for OMAP4
on die temperature sensor.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/temp_sensor_device.c | 85 +++
arch/arm/plat-omap/Kconfig
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit
div_ts_ck feeds only the temperature sensor functional clock
and also has a clksel associated (for divider selection). Mapping this
as the functional clock for the temperature sensor in clkdev table,
so a clk_set_rate() in the driver would have the effect of changing the
temperature sensor clock
Hi,
(you should Cc Tony, as he's OMAP maintainer)
On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
The device file adds the device support for OMAP4
on die temperature sensor.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +-
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
---
arch/arm/boot/dts/omap3-soc.dtsi | 62 ++
1 files changed, 62
Hi,
On Wed, Aug 10, 2011 at 05:55:21PM +0530, Keerthy wrote:
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data
* Felipe Balbi ba...@ti.com [110810 05:31]:
On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
+
+int __init omap_devinit_temp_sensor(void)
+{
+ if (!cpu_is_omap446x())
+ return 0;
+
+ return omap_hwmod_for_each_by_class(temperature_sensor,
+
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Update omap3 beagle dts file with required clock frequencies for the i2c
client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can coexist with omap3
soc dts file.
Signed-off-by: G, Manjunath
Hi,
(why aren't below in Cc ?
HARDWARE MONITORING
M: Jean Delvare kh...@linux-fr.org
M: Guenter Roeck guenter.ro...@ericsson.com
L: lm-sens...@lm-sensors.org
W: http://www.lm-sensors.org/
T: quilt
kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-hwmon/
T:
Hi,
On Wed, Aug 10, 2011 at 05:41:02AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [110810 05:31]:
On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
+
+int __init omap_devinit_temp_sensor(void)
+{
+ if (!cpu_is_omap446x())
+ return 0;
+
+
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Adapt dt for omap i2c1 controller and remove legacy i2c
initilization in omap3 generic board file.
Tested on omap3 beagle board for dt and non-dt builds.
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
---
arch/arm/boot/dts/omap3-soc.dtsi
On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add pd_size in the AUXDATA structure so that device drivers which require
platform_data size can pass along with AUXDATA.
It is really needed by device driver? Or is it
If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource, the
timer stops counting once overflow occurs as it was not set in autoreload mode.
This results into timekeeping failure: for example, 'sleep 1' at the shell after
the timer counter overflow would hang.
This patch sets
This patchset fixes the occasional failure of CCDC capture during
suspend/resume.
Cc: Vaibhav Hiremath hvaib...@ti.com
Cc: Abhilash K V abhilash...@ti.com
---
Abhilash K V (2):
omap3: ISP: Fix the failure of CCDC capture during suspend/resume
omap3: ISP: Kernel crash when attempting suspend
From: Abhilash K V abhilash...@ti.com
While resuming from the suspended to memory state,
occasionally CCDC fails to get enabled and thus fails
to capture frames any more till the next suspend/resume
is issued.
This is a race condition which happens only when a CCDC
frame-completion ISR is pending
From: Abhilash K V abhilash...@ti.com
This patch fixes the kernel crash introduced by the previous
patch:
omap3: ISP: Fix the failure of CCDC capture during
suspend/resume.
This null pointer exception happens when attempting suspend
while the ISP driver is not being used. The
On Wed, 10 Aug 2011, Felipe Balbi wrote:
Hi,
On Tue, Aug 09, 2011 at 02:30:14PM -0400, Jason Kridner wrote:
On Tue, Aug 9, 2011 at 1:51 PM, Joel A Fernandes agnel.j...@gmail.com
wrote:
Anyone seen this before?
A lot of the kernel developers don't frequent the beagleboard list.
On 8/10/2011 2:48 PM, Balbi, Felipe wrote:
Hi,
On Wed, Aug 10, 2011 at 05:41:02AM -0700, Tony Lindgren wrote:
* Felipe Balbiba...@ti.com [110810 05:31]:
On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
+
+int __init omap_devinit_temp_sensor(void)
+{
+ if (!cpu_is_omap446x())
* Hemant Pedanekar hema...@ti.com [110810 06:14]:
If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource,
the
timer stops counting once overflow occurs as it was not set in autoreload
mode.
This results into timekeeping failure: for example, 'sleep 1' at the shell
On 8/10/2011 3:52 AM, David Gibson wrote:
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:49 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:17 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:08:09PM
On Wed, Aug 10, 2011 at 6:07 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Aug 10, 2011 at 05:55:21PM +0530, Keerthy wrote:
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver
On 08/09/2011 08:52 PM, David Gibson wrote:
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order. In which
case you could argue it's more sensible to just have a static place to
name mapping in the Linux driver.
I
On 8/10/2011 5:18 PM, Scott Wood wrote:
On 08/09/2011 08:52 PM, David Gibson wrote:
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order. In which
case you could argue it's more sensible to just have a static place to
On Wed, Aug 10, 2011 at 07:16:30AM -0600, Grant Likely wrote:
On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add pd_size in the AUXDATA structure so that device drivers which require
platform_data size can pass
On Wed, Aug 10, 2011 at 12:15:50PM +0200, Cousson, Benoit wrote:
Manju,
On 8/10/2011 9:07 AM, Jarkko Nikula wrote:
Hi
On Tue, 09 Aug 2011 19:10:22 +0500
G, Manjunath Kondaiahmanj...@ti.com wrote:
From: Kevin Hilmankhil...@ti.com
For converting from struct device to platform_device,
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
The omap dt requires new omap hwmod api to be added for in order
to support omap dt.
Both the subject and the changelog are misleading. You are not doing
any
On Tue, Aug 09, 2011 at 07:45:09PM +0530, Keshava Munegowda wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the intefrace and
typo: interface
fucntional clocks; These clocks are handled by hwmod and runtime pm,
typo: functional
hence
Hi,
-Original Message-
From: lm-sensors-boun...@lm-sensors.org [mailto:lm-sensors-bounces@lm-
sensors.org] On Behalf Of Keerthy
Sent: Wednesday, August 10, 2011 5:55 PM
To: lm-sens...@lm-sensors.org
Cc: vishwanath...@ti.com; linux-omap@vger.kernel.org; b-cous...@ti.com;
On Wed, Aug 10, 2011 at 02:42:56PM +0200, Cousson, Benoit wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Update omap3 beagle dts file with required clock frequencies for the i2c
client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can
On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
---
arch/arm/boot/dts/omap3-soc.dtsi
On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
The omap dt requires new omap hwmod api to be added for in order
to support omap dt.
Both the subject and the
+ Tony
On 8/10/2011 6:57 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath
On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
The omap dt requires new omap hwmod api
On 8/10/2011 8:03 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoitb-cous...@ti.com wrote:
On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath
Hi,
I am trying to use a more recent version of the tidspbridge code in
the Nokia N9, but I'm stuck with this warning that is caused by using
the dm timer framework.
[ 30.883636] BUG: sleeping function called from invalid context at
kernel/mutex.c:287
[ 30.885925] in_atomic(): 1,
On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote:
Please, stick with the established convention and explicitly order
'reg' and 'interrupts' properties. If there is a specific use case
where this doesn't work, then bring it up, but I haven't seen any yet.
The current users of
On Wed, Aug 10, 2011 at 1:57 PM, David Brown dav...@codeaurora.org wrote:
On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote:
Please, stick with the established convention and explicitly order
'reg' and 'interrupts' properties. If there is a specific use case
where this doesn't
Hi,
On Wed, Aug 10, 2011 at 10:11:48AM -0400, Alan Stern wrote:
On Wed, 10 Aug 2011, Felipe Balbi wrote:
Hi,
On Tue, Aug 09, 2011 at 02:30:14PM -0400, Jason Kridner wrote:
On Tue, Aug 9, 2011 at 1:51 PM, Joel A Fernandes agnel.j...@gmail.com
wrote:
Anyone seen this before?
Hi,
On Wed, Aug 10, 2011 at 04:17:05PM +0200, Cousson, Benoit wrote:
On 8/10/2011 2:48 PM, Balbi, Felipe wrote:
Hi,
On Wed, Aug 10, 2011 at 05:41:02AM -0700, Tony Lindgren wrote:
* Felipe Balbiba...@ti.com [110810 05:31]:
On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
+
+int
On Mon, 2011-06-27 at 18:45 +0200, Sebastian Reichel wrote:
On Tue, May 31, 2011 at 10:51:39AM +0200, Sebastian Reichel wrote:
The driver is accessing to i2c bus in interrupt handler.
Therefore, it should use threaded irq.
I think the patch should also remove the local_irq_enable() call
On Wed, Aug 10, 2011 at 9:42 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I am trying to use a more recent version of the tidspbridge code in
the Nokia N9, but I'm stuck with this warning that is caused by using
the dm timer framework.
Actually, the problem only happens on the
On Wed, Aug 10, 2011 at 6:06 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
(you should Cc Tony, as he's OMAP maintainer)
On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
The device file adds the device support for OMAP4
on die temperature sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Only register as an RTC device after the hardware has been
successfully initialized. The RTC class driver will call
back to this driver to read a pending alarm, and other
drivers watching for new devices on the RTC class may
read the RTC time upon registration. Such access might
occur while the
Signed-off-by: Kyle Manna k...@kylemanna.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 3ae16b4..a82d53b 100644
---
Worst case this fixes the following error:
[ 72.086212] (NULL device *): conversion timeout!
Best case it prevents a crash
Signed-off-by: Kyle Manna k...@kylemanna.com
---
drivers/mfd/twl4030-madc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
Without turning the MADC clock on, no MADC conversions occur.
$ cat /sys/class/hwmon/hwmon0/device/in8_input
[ 53.428436] twl4030_madc twl4030_madc: conversion timeout!
cat: read error: Resource temporarily unavailable
Signed-off-by: Kyle Manna k...@kylemanna.com
---
These patches add basic functionality to the twl4030-madc driver to make
it work on the BeagleBoard xM. These patches were also tested on a OMAP3EVM.
Kyle Manna (3):
twl4030-madc: copy the device pointer
twl4030-madc: turn on the MADC clock
BeagleBoard: add support for the twl4030-madc
On Wed, Aug 10, 2011 at 4:35 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Aug 10, 2011 at 10:11:48AM -0400, Alan Stern wrote:
On Wed, 10 Aug 2011, Felipe Balbi wrote:
Hi,
On Tue, Aug 09, 2011 at 02:30:14PM -0400, Jason Kridner wrote:
On Tue, Aug 9, 2011 at 1:51 PM, Joel A
79 matches
Mail list logo
