On Tue, 1 Dec 2009 04:15:50 +0100
Janusz Krzysztofik wrote:
> #define MCBSP_WRITE(mcbsp, reg, val) \
> - omap_mcbsp_write(mcbsp->io_base, OMAP_MCBSP_REG_##reg, val)
> + omap_mcbsp_write(mcbsp->io_base, OMAP_MCBSP_REG_##reg, \
> + mcbsp->reg_cache[OMAP_MCBSP_RE
On Tue, 1 Dec 2009 04:10:07 +0100
Janusz Krzysztofik wrote:
> Change the way McBSP registers are maintained: store values written to the
> device in a cache in order to make use of those cached values when
> convenient.
>
> This could help for developing the McBSP context save/restore features,
On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote:
> * Grant Likely [091202 07:06]:
> > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren wrote:
> > > * Grant Likely [091130 09:01]:
>
>
>
> > >
> > > maybe you've already thought through all this.. But would it be
> > > possible
> > Signed-off-by: Romit Dasgupta
> > ---
> > diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-
> omap.c
> > index 449b6b6..f94df20 100644
> > --- a/arch/arm/plat-omap/cpu-omap.c
> > +++ b/arch/arm/plat-omap/cpu-omap.c
> > @@ -149,8 +149,6 @@ static int __init omap_cpu_init(st
Premi, Sanjeev said the following on 12/02/2009 04:23 PM:
>> -Original Message-
>> From: Sergey Lapin [mailto:slapi...@gmail.com]
>> Sent: Wednesday, December 02, 2009 7:04 PM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: SR1: VDD autocomp is not active
>>
>>
* Grant Likely [091202 07:06]:
> On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren wrote:
> > * Grant Likely [091130 09:01]:
> >
> > maybe you've already thought through all this.. But would it be
> > possible to do lightweight device tree that we just use to populate
> > the platform data?
>
* Grant Likely [091202 09:24]:
> On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson wrote:
> > On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote:
> >
> >> Ah, you're talking about pin muxing configuration, right? Yes, that
> >> GPIO binding deals with controllers, not pin mux. Pin mux is
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next
Initial commit ID (Likely to change): 9a01609e1885b827b979d6d9dd86f43208a9e5fc
PatchWorks
http://patchwork.kernel.org/patch/64031/
Git (Likely to change, and takes a while to get mirrored)
Add 36xx CBP package support
Cc: Benoit Cousson
Signed-off-by: Paul Walmsley
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Kconfig |5
arch/arm/mach-omap2/board-3630sdp.c |9 +
arch/arm/mach-omap2/board-zoom3.c | 10 +
arch/arm/mach-omap2/mux.h |1
ar
Remove old mux code for 34xx
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-3430sdp.c |1
arch/arm/mach-omap2/board-cm-t35.c |1
arch/arm/mach-omap2/board-igep0020.c |1
arch/arm/mach-omap2/board-omap3beagle.c |1
arch/arm/mach-omap2/board-omap3evm
Replace omap_cfg_reg() with new style signal or gpio functions
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-3430sdp.c |4 -
arch/arm/mach-omap2/board-3630sdp.c |5 +
arch/arm/mach-omap2/board-cm-t35.c |3
arch/arm/mach-omap2/board-omap3beagl
Otherwise we cannot limit new mux code to mach-omap2.
The same signal names should eventually work for other
omaps under mach-omap2.
Note that these pins don't need to be OMAP_PIN_INPUT_PULLUP,
just OMAP_PIN_INPUT is enough.
Cc: Jarkko Nikula
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap
Add debugfs support for new mux code
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux.c | 227 +
1 files changed, 227 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b082b50..d968433 1006
Add new style mux init functions to omap3 board-*.c files
So far Beagle has been confirmed to be a CBB package,
and CM-T35 a CUS package.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Kconfig | 10 ++
arch/arm/mach-omap2/board-3430sdp.c | 10 ++
arch
Initially only for 34xx. This code allows us to:
- Make the code more generic as the omap internal signal
names can stay the same across omap generations for some
devices
- Map mux registers to GPIO registers that is needed for
dynamic muxing of pins during off-idle
- Override bootloader m
Hi all,
I've updated this series to only map GPIO pins to mux registers
if CONFIG_OMAP_MUX is not set. Those are needed for dynamic muxing
for off-idle.
I've also added omap36xx support, which I have not been able to
test. People with 36xx boards, please give it a try.
Also fixed several checkpa
From: Mike Rapoport
intoduce omap_mux_{read,write}
Signed-off-by: Mike Rapoport
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux.c | 44 ++--
1 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/
On Thu, Dec 03, 2009 at 12:31:56AM +0200, Felipe Balbi wrote:
> Hi,
>
> On Wed, Dec 02, 2009 at 10:54:42PM +0100, ext Anton Vorontsov wrote:
> >As for the default USB VBUS current value, it could be Kconfig
> >option (something alike to USB_GADGET_VBUS_DRAW) and/or module
> >parameter, or hw defau
will look cleaner on modinfo.
Signed-off-by: Felipe Balbi
---
drivers/cbus/cbus.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index d73d0c9..145e760 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
@@ -291,4 +291
plenty of legacy code sitting there. Make it build
again. Later patches will come to clean that up.
Signed-off-by: Felipe Balbi
---
drivers/cbus/tahvo-usb.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cbus/tahvo-usb.c b/drivers/cbus/tahvo-usb.c
ind
Hello Paul!
Thank you for pointing this out.
I think we are missing a patch here which was actually sent for up-stream but
did not make through as I don't see it on my latest master branch.
http://patchwork.kernel.org/patch/49514/
Can you please apply this and see if it helps, I don't have an
also add the platform_data to the related
board files.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/board-nokia770.c | 10 ++
arch/arm/mach-omap2/board-n8x0.c | 10 ++
arch/arm/plat-omap/include/plat/cbus.h | 31 +++
drivers/cbus/c
also add the platform_device to 770 and n8x0 board files.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/board-nokia770.c |6 ++
arch/arm/mach-omap2/board-n8x0.c |8
drivers/cbus/cbus.c | 34 +-
3 files changed, 47
while there, also add a missing static to cbus_bus_init().
Signed-off-by: Felipe Balbi
---
drivers/cbus/cbus.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index 0bcc211..d73d0c9 100644
--- a/drivers/cbus/cbus.c
+++ b/
change kmalloc() + memset() to kzalloc(), no functional
changes.
Signed-off-by: Felipe Balbi
---
drivers/cbus/cbus.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index c80cede..0bcc211 100644
--- a/drivers/cbus/cbus.c
+++ b
add missing
Signed-off-by: Felipe Balbi
---
drivers/video/omap/hwa742.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c
index 170d171..0016f77 100644
--- a/drivers/video/omap/hwa742.c
+++ b/drivers/video/omap/hwa
add missing
Signed-off-by: Felipe Balbi
---
drivers/video/omap/sossi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap/sossi.c b/drivers/video/omap/sossi.c
index 354cbbb..8fb7c70 100644
--- a/drivers/video/omap/sossi.c
+++ b/drivers/video/omap/sossi.c
there's no it's now under
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/board-nokia770.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index af4d719..db9a1de 100644
--- a/arch/arm/mac
omap1_clk_functions was only used by
omap1_clk_init() which sits in __init
section, so make omap1_clock_functions
be __initdata to avoid the section mismatch.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/clock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arc
on the following we have section mismatch fixes,
compile fix to board-nokia770.c, compile fix to sossi.c,
compile fix to hwa742.c, compile fix to tahvo-usb.c
and a few cleanups to cbus driver.
It's compile tested only as I don't have 770s or n8x0 with
the development jig available right now, so pl
On Wed, Dec 02, 2009 at 11:28:22PM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote:
on the following we have section mismatch fixes,
compile fix to board-nokia770.c, compile fix to sossi.c,
compile fix to hwa742.c, compile fix to tahvo-usb.c
and a few cleanups to cbus driver.
It's compile tested on
Hi,
On Wed, Dec 02, 2009 at 10:54:42PM +0100, ext Anton Vorontsov wrote:
As for the default USB VBUS current value, it could be Kconfig
option (something alike to USB_GADGET_VBUS_DRAW) and/or module
parameter, or hw default, or hardcoded for now. Either will
work.
cannot be Kconfig, it's manda
will look cleaner on modinfo.
Signed-off-by: Felipe Balbi
---
drivers/cbus/cbus.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index d73d0c9..145e760 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
@@ -291,4 +291
while there, also add a missing static to cbus_bus_init().
Signed-off-by: Felipe Balbi
---
drivers/cbus/cbus.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index 0bcc211..d73d0c9 100644
--- a/drivers/cbus/cbus.c
+++ b/
also add the platform_data to the related
board files.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/board-nokia770.c | 10 ++
arch/arm/mach-omap2/board-n8x0.c | 10 ++
arch/arm/plat-omap/include/plat/cbus.h | 31 +++
drivers/cbus/c
also add the platform_device to 770 and n8x0 board files.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/board-nokia770.c |6 ++
arch/arm/mach-omap2/board-n8x0.c |7 +++
drivers/cbus/cbus.c | 34 +-
3 files changed, 46 i
change kmalloc() + memset() to kzalloc(), no functional
changes.
Signed-off-by: Felipe Balbi
---
drivers/cbus/cbus.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index c80cede..0bcc211 100644
--- a/drivers/cbus/cbus.c
+++ b
plenty of legacy code sitting there. Make it build
again. Later patches will come to clean that up.
Signed-off-by: Felipe Balbi
---
drivers/cbus/tahvo-usb.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cbus/tahvo-usb.c b/drivers/cbus/tahvo-usb.c
ind
omap1_clk_functions was only used by
omap1_clk_init() which sits in __init
section, so make omap1_clock_functions
be __initdata to avoid the section mismatch.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/clock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arc
there's no it's now under
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap1/board-nokia770.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index af4d719..db9a1de 100644
--- a/arch/arm/mac
add missing
Signed-off-by: Felipe Balbi
---
drivers/video/omap/hwa742.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c
index 170d171..0016f77 100644
--- a/drivers/video/omap/hwa742.c
+++ b/drivers/video/omap/hwa
add missing
Signed-off-by: Felipe Balbi
---
drivers/video/omap/sossi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap/sossi.c b/drivers/video/omap/sossi.c
index 354cbbb..8fb7c70 100644
--- a/drivers/video/omap/sossi.c
+++ b/drivers/video/omap/sossi.c
on the following we have section mismatch fixes,
compile fix to board-nokia770.c, compile fix to sossi.c,
compile fix to hwa742.c, compile fix to tahvo-usb.c
and a few cleanups to cbus driver.
It's compile tested only as I don't have 770s or n8x0 with
the development jig available right now, so pl
On 12/2/2009 12:52 PM, Koen Kooi wrote:
> Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven:
>
>
>>
>>
The xorg boot log appears reasonably sane until a crash - 640x480 is
what the xf86 omapfb driver picks up, so I assume something
else is the
pr
On Wed, Dec 02, 2009 at 11:29:10PM +0200, Grazvydas Ignotas wrote:
[...]
> From what I saw in other drivers they are setup to start charging
> automatically as soon as they see VBUS.
Yes. I see nothing wrong here.
> > How are you differing between those currently?
>
> Not handled at all at the m
On Wed, Dec 2, 2009 at 11:27 PM, Anton Vorontsov
wrote:
> On Wed, Dec 02, 2009 at 10:38:31PM +0200, Grazvydas Ignotas wrote:
>> On Mon, Nov 30, 2009 at 8:58 PM, Anton Vorontsov
>> wrote:
>> > On Mon, Nov 30, 2009 at 12:45:20PM -0600, Madhusudhan wrote:
>> > [...]
>> >> > + case POWER_SUPPLY_PRO
On Wed, Dec 2, 2009 at 10:49 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Dec 02, 2009 at 09:34:00PM +0100, ext Grazvydas Ignotas wrote:
+#define BCI_DELAY 100
>>>
>>> 100ms ??? that's too quick for battery monitoring. Imagine that you'll
>>> have
>>> 10 i2c transfers per-secon
On Wed, Dec 02, 2009 at 10:38:31PM +0200, Grazvydas Ignotas wrote:
> On Mon, Nov 30, 2009 at 8:58 PM, Anton Vorontsov
> wrote:
> > On Mon, Nov 30, 2009 at 12:45:20PM -0600, Madhusudhan wrote:
> > [...]
> >> > + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> >> > + /* charging must be active for
Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven:
>
>>> The xorg boot log appears reasonably sane until a crash - 640x480 is
>>> what the xf86 omapfb driver picks up, so I assume something
>>> else is the
>>> problem. I'll try to poke at the omapfb source some to see
>
Hi,
On Wed, Dec 02, 2009 at 09:34:00PM +0100, ext Grazvydas Ignotas wrote:
+#define BCI_DELAY 100
100ms ??? that's too quick for battery monitoring. Imagine that you'll have
10 i2c transfers per-second forever with this one. Don't you think you're
waking up omap for nothing ??
T
On Mon, Nov 30, 2009 at 8:58 PM, Anton Vorontsov
wrote:
> On Mon, Nov 30, 2009 at 12:45:20PM -0600, Madhusudhan wrote:
> [...]
>> > + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
>> > + /* charging must be active for meaningful result */
>> > + if (!is_charging) {
>>
>> How about putt
On Wed, Dec 2, 2009 at 7:33 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Nov 27, 2009 at 03:44:20PM +0100, ext Grazvydas Ignotas wrote:
>>
>> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
>> index b96f29d..9cea9b5 100644
>> --- a/drivers/power/Makefile
>> +++ b/drivers/power/Makefile
>
>> The xorg boot log appears reasonably sane until a crash - 640x480 is
>> what the xf86 omapfb driver picks up, so I assume something
>> else is the
>> problem. I'll try to poke at the omapfb source some to see
>> if something
>> is being passed around wrong - I'd appreciate any suggestions on
Hi,
On Fri, Nov 27, 2009 at 03:44:20PM +0100, ext Grazvydas Ignotas wrote:
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b96f29d..9cea9b5 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
obj
On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson wrote:
> On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote:
>
>> Ah, you're talking about pin muxing configuration, right? Yes, that
>> GPIO binding deals with controllers, not pin mux. Pin mux is very
>> much an SoC specific thing that i
> -Original Message-
> From: Grazvydas Ignotas [mailto:nota...@gmail.com]
> Sent: Monday, November 30, 2009 3:33 PM
> To: Madhusudhan
> Cc: linux-ker...@vger.kernel.org; Anton Vorontsov; linux-
> o...@vger.kernel.org
> Subject: Re: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI
Hello Olof, Nishanth,
thanks for the comments,
On Wed, 2 Dec 2009, Olof Johansson wrote:
> On Wed, Dec 02, 2009 at 08:12:34AM +0200, Menon, Nishanth wrote:
>
> > why not make this a #ifdef instead if we need it some other time, a #if
> > 0 and it's intention might not be readable without doing
On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote:
> Ah, you're talking about pin muxing configuration, right? Yes, that
> GPIO binding deals with controllers, not pin mux. Pin mux is very
> much an SoC specific thing that isn't mapped easily to a generic
> binding.
Yep.
> On the 52
On Wed, Dec 2, 2009 at 8:53 AM, Olof Johansson wrote:
> On Wed, Dec 02, 2009 at 08:07:21AM -0700, Grant Likely wrote:
>
>> Oh, and speaking of GPIOs, there is a binding for describing GPIO pin
>> connections in the device tree:
>> Documentation/powerpc/dts-bindings/gpio/gpio.txt
>
> That binding i
>From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
>
>On Mon, Nov 30, 2009 at 11:54 PM, Omar Ramirez Luna
>wrote:
>> Prior to any further modification set the driver version to be 0.1
>
>It should be the other way around; *after* the modifications have been
>merged,the version 0.1 would
On Wed, Dec 02, 2009 at 08:12:34AM +0200, Menon, Nishanth wrote:
> why not make this a #ifdef instead if we need it some other time, a #if
> 0 and it's intention might not be readable without doing a git annotate
> in a few months time..
Just remove the code. The old implementation is still there
On Wed, Dec 02, 2009 at 08:07:21AM -0700, Grant Likely wrote:
> Oh, and speaking of GPIOs, there is a binding for describing GPIO pin
> connections in the device tree:
> Documentation/powerpc/dts-bindings/gpio/gpio.txt
That binding is more about documenting a bank of GPIO pins, while
chips like O
On Wed, Dec 2, 2009 at 1:12 PM, Romit Dasgupta wrote:
>
> It is seen that the OMAP specific cpufreq initialization code tries to
> scale the MPU frequency to the highest possible without taking care of
> the voltage level. On power on reset the power IC does not provide the
> necessary voltage for
On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren wrote:
> * Grant Likely [091130 09:01]:
>> http://www.elinux.org/Device_Trees
>>
>> I expect to have my prototype ready for review mid-January, and most
>> of the common code should be either merged or queued up in linux-next
>> by that time.
>
> Wh
Amit Kucheria wrote:
> Infact, we can just return -1 so that caller knows for sure that all messages
> were not tranferred. Please consider fixed patch instead.
>
> We should be checking if all the messages were tranferred or not. And return
> -1 for failure. Currently we return success (0) even i
> -Original Message-
> From: Sergey Lapin [mailto:slapi...@gmail.com]
> Sent: Wednesday, December 02, 2009 7:04 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: SR1: VDD autocomp is not active
>
> >>
> >> [sp] The code will allow you to do so; but without right valu
>> >> From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001
>> >> From: Vimal Singh
>> >> Date: Thu, 19 Nov 2009 19:28:11 +0530
>> >>
>> >> This patch series adds flash support for NAND (in sdp, zoom and ldp),
>> >> OneNAND and NOR (in sdp)
>> >>
>> >> Tested on Zoom2 and 3430SDP
On Wed, Dec 2, 2009 at 4:33 PM, Sergey Lapin wrote:
>>>
>>> [sp] The code will allow you to do so; but without right values
>>> kernel execution can go haywire.
>>
>> Is it possible somehow to identify right silicon revision before ordering?
>> I mean by part number or something?
> Sorry for m
Infact, we can just return -1 so that caller knows for sure that all messages
were not tranferred. Please consider fixed patch instead.
We should be checking if all the messages were tranferred or not. And return
-1 for failure. Currently we return success (0) even if none of messages were
transfe
On Wed, Nov 25, 2009 at 12:18 AM, Kevin Hilman
wrote:
> "Govindraj.R" writes:
>
>> From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001
>> From: Govindraj R
>> Date: Fri, 13 Nov 2009 12:01:54 +0530
>> Subject: [PATCH] OMAP UART: Add omap-serial driver support.
>>
>> This patch
Hi,
On Wed, Dec 02, 2009 at 02:31:18PM +0100, ext Amit Kucheria wrote:
@@ -298,10 +298,12 @@ int twl4030_i2c_write(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl->client->adapter, twl->xfer_msg, 1);
mutex_unlock(&twl->xfer_lock);
- /* i2cTransfer
We should be checking if all the messages were tranferred or not. Currently we
return success even if none of messages were transferred successfully.
Signed-off-by: Amit Kucheria
---
drivers/mfd/twl4030-core.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff
>>
>> [sp] The code will allow you to do so; but without right values
>> kernel execution can go haywire.
>
> Is it possible somehow to identify right silicon revision before ordering?
> I mean by part number or something?
Sorry for my ignorance, I've found answer on first question (answer is
t
On Wed, Dec 2, 2009 at 3:19 PM, Premi, Sanjeev wrote:
>> -Original Message-
>> From: Sergey Lapin [mailto:slapi...@gmail.com]
>> Sent: Wednesday, December 02, 2009 5:35 PM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: SR1: VDD autocomp is not active
>>
>> Hi, all!
> -Original Message-
> From: Sergey Lapin [mailto:slapi...@gmail.com]
> Sent: Wednesday, December 02, 2009 5:35 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: SR1: VDD autocomp is not active
>
> Hi, all! It seems discussion went off-list somehow, so I won't delete
Hi, all! It seems discussion went off-list somehow, so I won't delete
some quoting.
On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev wrote:
>> -Original Message-
>> From: Sergey Lapin [mailto:slapi...@gmail.com]
>> Sent: Wednesday, December 02, 2009 1:54 AM
>> To: Premi, Sanjeev
>> Subject:
On Mon, Nov 30, 2009 at 11:54 PM, Omar Ramirez Luna wrote:
> Prior to any further modification set the driver version to be 0.1
It should be the other way around; *after* the modifications have been
merged, the version 0.1 would be released. Moreover, it would be nice
to get some acknowledgement
It is seen that the OMAP specific cpufreq initialization code tries to
scale the MPU frequency to the highest possible without taking care of
the voltage level. On power on reset the power IC does not provide the
necessary voltage for the highest available MPU frequency (that would
satisfy all Si
I'm not talking about full chip off in suspend ,,but I'm talking about
tern off some modules while they aren't in use however the cpu is
running in normal mode not in idle
On Wed, Dec 2, 2009 at 11:29 AM, tarek attia wrote:
> Hi All,
>
> I know that CPU have power management through CPUFREQ,,but
Hi All,
I know that CPU have power management through CPUFREQ,,but what about
the peripherals like (DVI-D) does it have a power management for it
as well??,,and the rest of peripherals also ?
Appreciate your response,
Best Regards,
tarek
--
To unsubscribe from this list: send the line "unsubs
On Wed, Dec 02, 2009 at 08:06:16 +0200, Menon, Nishanth wrote:
> Alexander Shishkin said the following on 12/01/2009 05:42 PM:
> > On Fri, Nov 20, 2009 at 02:09:01 -0600, Nishanth Menon wrote:
> >
> >> Aguirre, Sergio had written, on 11/20/2009 01:43 PM, the following:
> >>
> -Orig
81 matches
Mail list logo