Zvi Vered | 31 Jul 04:50 2014
Picon

i2c_smbus_write_block_data: send 2 bytes (command+size) before data

Hello,

From an Intel's ATOM I want to send an I2C message from SMBus controller to
a TI's microcontroller configured as an I2C slave.

I used the following code:

handle = fopen ("/dev/i2c-14",O_RDWR); //open SMBUs controller

ioctl (handle, I2C_SLAVE, 0x43);  //set I2C slave destination address

i2c_smbus_write_block_data (handle, 0x00, 16, buffer); //send 16 bytes
message, command = 0x00

The message I want to send is: 0xAD, 0x2D, 0xFE, 0xCA, ..... 0x00  (16
bytes)

I'm using I2C sniffer to see what I sent and what I see is:

0x00, 0x10, 0xAD, 0x2D, 0xFE, 0xCA, .....

It seems the register (command) and length are also sent.

The MCU expect pure data without the 2 bytes: 0x00, 0x10

The above code runs under vanilla linux 3.2.48

Can you help ?

Thanks,
(Continue reading)

Mrs Sandra | 30 Jul 09:54 2014
Picon

(unknown)

Do you need a loan?If yes contact us for more info thanks
Loan Amount Needed:
Loan Duration:
Country:
Phone Number:
Noemi Alvarez | 29 Jul 10:23 2014
Picon

Hello


I want to keep up with you with hope for friendship if you are interested.
If you don't mind i will like you to write me back. I am waiting to read
from you, because i have something important and urgent to discuss with
you. I will also send some of my beautiful photos to you.

Jean Delvare | 28 Jul 14:33 2014
Picon

[PATCH] i2c-gpio: Drop dead code in i2c_gpio_remove

Commit a0682a31 ("i2c: gpio: Use devm_gpio_request()") left unused
code behind, clean it up.

Fixes: a0682a315889 ("i2c: gpio: Use devm_gpio_request()")
Signed-off-by: Jean Delvare <jdelvare@...>
Cc: Jingoo Han <jg1.han@...>
Cc: Violeta Menendez <violeta.menendez@...>
Cc: Ian Molton <ian.molton@...>
Cc: Wolfram Sang <wsa@...>
---
 drivers/i2c/busses/i2c-gpio.c |    2 --
 1 file changed, 2 deletions(-)

--- linux-3.16-rc6.orig/drivers/i2c/busses/i2c-gpio.c	2014-06-16 05:45:28.000000000 +0200
+++ linux-3.16-rc6/drivers/i2c/busses/i2c-gpio.c	2014-07-28 14:26:07.821013275 +0200
 <at>  <at>  -238,12 +238,10  <at>  <at>  static int i2c_gpio_probe(struct platfor
 static int i2c_gpio_remove(struct platform_device *pdev)
 {
 	struct i2c_gpio_private_data *priv;
-	struct i2c_gpio_platform_data *pdata;
 	struct i2c_adapter *adap;

 	priv = platform_get_drvdata(pdev);
 	adap = &priv->adap;
-	pdata = &priv->pdata;

 	i2c_del_adapter(adap);

--

-- 
Jean Delvare
(Continue reading)

Javier Martinez Canillas | 28 Jul 14:19 2014
Picon

[PATCH 0/7] Second batch of cleanups for cros_ec

This is a second batch of cleanups patches for the mfd cros_ec
driver and its subdevices drivers. The first batch of cleanups
was posted by Doug Anderson [0] and have already been merged.
The patches were picked from the ChromeOS 3.8 kernel and after
these no cleanups patches for cros_ec are left, only commits
that add cros ec support not yet available in mainline.

There is almost no functionality added on this series but the
idea is to reduce the delta between the mainline drivers and
the ones in the downstream Chrome OS 3.8 kernel so the missing
functionality can be added on top once these cleanups patches
are merged. The missing functionlity currently in mainline is:

- Chrome OS Embedded Controller userspace device interface
- Chrome OS Embedded Controller Low Pin Count (LPC) inteface
- Access to vboot context stored on a block device
- Access to vboot context stored on EC's nvram

The patches in this series are authored by different people
(all on cc) and consist of the following:

Andrew Bresticker (3):
  mfd: cros_ec: stop calling ->cmd_xfer() directly
  mfd: cros_ec: move locking into cros_ec_cmd_xfer
  mfd: cros_ec: wait for completion of commands that return IN_PROGRESS

Derek Basehore (1):
  i2c: i2c-cros-ec-tunnel: Set retries to 3

Doug Anderson (1):
(Continue reading)

Jisheng Zhang | 25 Jul 13:57 2014

[PATCH v2] i2c: pca954x: put the mux to disconnected state after resume

pca954x may be power lost during suspend, so after resume we also suffer
the issue fixed by commit cd823db8b1161ef0d756514d280715a576d65cc3,

 "pca954x power-on default is channel 0 connected. If multiple pca954x
 muxes are connected to the same physical I2C bus, the parent bus will
 see channel 0 devices behind both muxes by default."

What's more, when resume bootloader may also operate the mux, so the
the channel connected after that may not be the one driver thought.

We fix this problem by putting the mux to disconnected state and
clearing last_chan in the resume hook.

Signed-off-by: Jisheng Zhang <jszhang@...>
---
 drivers/i2c/muxes/i2c-mux-pca954x.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 9bd4212..ec11b40 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
 <at>  <at>  -41,6 +41,7  <at>  <at> 
 #include <linux/i2c-mux.h>
 #include <linux/i2c/pca954x.h>
 #include <linux/module.h>
+#include <linux/pm.h>
 #include <linux/slab.h>

 #define PCA954X_MAX_NCHANS 8
(Continue reading)

Wolfram Sang | 24 Jul 12:38 2014
Picon

Vacation

Hi people,

I'll be mostly away from the net for a week or so. I might be able to 
read mails (no promises, though), yet I won't be able to review patches 
during that time.

Until then,

    Wolfram

Yao Yuan | 24 Jul 05:19 2014

RE: [PATCH v4 1/2] i2c: add DMA support for freescale i2c driver

On Fri, May 21, 2014 at 4:01 PM +0200, Wolfram Sang wrote:
> 
> Ping. Any updates? I think this was pretty close to inclusion?

Hi, Wolfram
	Thanks for your concern. Sorry for my reply so late. I had on a business trip for months.
At that time I have no device to debug it. Now, I'm come back and I will try my best to finish it.
I have sent the patch for V5. Thanks for your review.

Best regards,
Yuan Yao
Maxime COQUELIN | 23 Jul 17:44 2014

[PATCH v2] drivers: i2c: i2c-st: Update i2c timings

The i2c timing values specified in the driver are the minimun values defined
in the I2C specifications.
The I2C specification does not specify any default or maximum values.

Some I2C devices are out of spec, such as the HDMI link of the Toshiba 19AV600
TV, and might not work properly with minimum values.

This patch adds a 10% margin on all the timings in both Normal and Fast modes.

Trial and error method have been used to find the minimum margin necessary to
have the out-of-spec device working, and a security margin has been added.

Signed-off-by: Maxime Coquelin <maxime.coquelin@...>
---
 drivers/i2c/busses/i2c-st.c | 32 +++++++++++++++++++-------------
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/busses/i2c-st.c b/drivers/i2c/busses/i2c-st.c
index 95b94767..4ab14ad 100644
--- a/drivers/i2c/busses/i2c-st.c
+++ b/drivers/i2c/busses/i2c-st.c
 <at>  <at>  -206,25 +206,31  <at>  <at>  static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
 	writel_relaxed(readl_relaxed(reg) & ~mask, reg);
 }

-/* From I2C Specifications v0.5 */
+/*
+ * From I2C Specifications v0.5.
+ *
+ * All the values below have +10% margin added to be
(Continue reading)

Alan Cox | 23 Jul 14:06 2014
Picon

i2c,designware: add new bindings

This may appear as PCI or ACPI depending upon the firmware so we
have to list both. All share the same ACPI identifier but not
the same PCI identifier.

Signed-off-by: Alan Cox <alan@...>
---
 drivers/i2c/busses/i2c-designware-pcidrv.c  |    9 +++++++++
 drivers/i2c/busses/i2c-designware-platdrv.c |    1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 3356f7a..d31d313 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
 <at>  <at>  -188,6 +188,7  <at>  <at>  static struct  dw_pci_controller dw_pci_controllers[] = {
 		.scl_sda_cfg = &hsw_config,
 	},
 };
+
 static struct i2c_algorithm i2c_dw_algo = {
 	.master_xfer	= i2c_dw_xfer,
 	.functionality	= i2c_dw_func,
 <at>  <at>  -350,6 +351,14  <at>  <at>  static const struct pci_device_id i2_designware_pci_ids[] = {
 	/* Haswell */
 	{ PCI_VDEVICE(INTEL, 0x9c61), haswell },
 	{ PCI_VDEVICE(INTEL, 0x9c62), haswell },
+	/* Braswell / Cherrytrail */
+	{ PCI_VDEVICE(INTEL, 0x22C1), baytrail,},
+	{ PCI_VDEVICE(INTEL, 0x22C2), baytrail },
+	{ PCI_VDEVICE(INTEL, 0x22C3), baytrail },
(Continue reading)

Wolfram Sang | 18 Jul 14:35 2014
Picon

Re: I2C Slave monitor mode support


> Currently, one would have to put a loop on the address transfer waiting an ack
> is received in user space.

This is what most i2c master drivers would need to do anyhow. I have
never heard of hardware support for that. Do you know an IP core which
does that? And how are timeouts defined/handled?

> This helps the app or the user software to not busy wait considering the slow
> clk of i2c.

Currently, this is not supported in Linux I2C. It probably could be
using another I2C_M_* flag, but a number of details need to be designed
and implemented first. Would you be interested?

Kind regards,

   Wolfram


Gmane