Hello Lee,
Thanks a lot for your feedback.
On 08/21/2014 04:21 PM, Lee Jones wrote:
On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
From: Andrew Bresticker abres...@chromium.org
When an EC command returns EC_RES_IN_PROGRESS, we need to query
the state of the EC until it indicates
Hello Lee,
On 08/21/2014 04:25 PM, Lee Jones wrote:
static const struct mfd_cell cros_devs[] = {
-{
-.name = cros-ec-keyb,
-.id = 1,
-.of_compatible = google,cros-ec-keyb,
-},
-{
-.name = cros-ec-i2c-tunnel,
-.id
Hi!
Here's a patch to enable trickle charging; without it the clock stops
when power is removed - not very useful.
_But_ this should probably be enabled using device tree entry, right?
Unfortunately, the driver is i2c driver, not platform one, so I don't
see how to do that easily...
Or would
Hello.
Here's the set of 3 patches against Wolfram Sang's 'linux.git' repo's
'i2c/for-next' branch.
[1/3] i2c-rcar: simplify check for last message
[2/3] i2c-rcar: make rcar_i2c_prepare_msg() *void*
[3/3] i2c-rcar: make rcar_i2c_irq_recv() *void*
WBR, Sergei
--
To unsubscribe from this
rcar_i2c_master_xfer() needlessly compares the message pointers (using indirect
addressing) in order to detect the last I2C message, while it's enough to only
compare the message indexes.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
drivers/i2c/busses/i2c-rcar.c |2
rcar_i2c_prepare_msg() always returns 0, so we can make this function return
*void* and thus remove the result check in rcar_i2c_master_xfer().
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
drivers/i2c/busses/i2c-rcar.c |9 ++---
1 file changed, 2 insertions(+),
rcar_i2c_irq_recv() always returns 0, so we can make this function return
*void* and also remove rcar_i2c_flags_set() invocation in rcar_i2c_irq().
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
drivers/i2c/busses/i2c-rcar.c |8 +++-
1 file changed, 3
_But_ this should probably be enabled using device tree entry, right?
Unfortunately, the driver is i2c driver, not platform one, so I don't
see how to do that easily...
Trickle charging is usually depending on the hardware setup, so
devicetree is actually a good place to put it. We'd just
On Fri 2014-08-22 09:28:52, Wolfram Sang wrote:
_But_ this should probably be enabled using device tree entry, right?
Unfortunately, the driver is i2c driver, not platform one, so I don't
see how to do that easily...
Trickle charging is usually depending on the hardware setup, so
Hi Addy,
On Fri, Aug 22, 2014 at 09:13:11AM +0800, Addy Ke wrote:
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data
in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx
must be less than or equal 32 bytes at a time.
Tested on rk3288-pinky board,
Having a transfer more than 32 bits is not all that unlikely. Remove
the annotation.
The unlikely in the IRQ handler can't gain us much. It's not in a
loop, so at most it would save 1 instruction per IRQ, which isn't
much. In fact on the compiler I tested it produced the exact same
code.
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data
in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx
must be less than or equal 32 bytes at a time.
Tested on rk3288-pinky board, elan receive 158 bytes data.
Suggested-by: Dmitry Torokhov
Addy,
On Fri, Aug 22, 2014 at 11:00 AM, Addy Ke addy...@rock-chips.com wrote:
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data
in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx
must be less than or equal 32 bytes at a time.
Tested on
Addy,
On Fri, Aug 22, 2014 at 11:00 AM, Addy Ke addy...@rock-chips.com wrote:
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data
in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx
must be less than or equal 32 bytes at a time.
Tested on
I would like to implement bus recovery support for the at91 driver, but
there it is not clear how the core support is supposed to be used, and I
could not find an existing adapter implementation using it.
First off, reading the old mailing list discussion here:
Addy,
On Fri, Aug 22, 2014 at 11:47 AM, addy ke addy...@rock-chips.com wrote:
Addy,
On Fri, Aug 22, 2014 at 11:00 AM, Addy Ke addy...@rock-chips.com wrote:
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data
in one chunk, so the size of data to be write/read to/from
Hello.
On 05/28/2014 11:44 AM, Wolfram Sang wrote:
From: Wolfram Sang wsa+rene...@sang-engineering.com
The i2c core has per-adapter locks, so no need to protect again.
The core's lock is unable to protect from the IRQs. So I'm proposing to
revert this patch. It's a pity I hadn't
Prepare_recovery and unprepare_recovery are to configure the pad
multiplexer since thats platform specific. You don't care about the
adapter reference as you just need the scl_gpio and sda_gpio values to
know what pins to reconfigure.
In fact Atmel's pad mux functions look like this:
The i2c core has per-adapter locks, so no need to protect again.
The core's lock is unable to protect from the IRQs. So I'm proposing to
revert this patch. It's a pity I hadn't noticed this issue when the patch
was posted.
Yes, you are right. I noticed a while ago, too, but then got
Sure thing, yet I won't make it for 3.17, sadly :( It has high priority
for 3.18, though.
Do you want me to re-send now the -rc1 had been released?
I think this version will do for an initial review.
Thanks,
Wolfram
signature.asc
Description: Digital signature
20 matches
Mail list logo
