Jon Hunter | 29 Jun 11:17 2016

[PATCH V2 00/11] Add support for Tegra DPAUX pinctrl

The Display Port Auxiliary (DPAUX) channel pads can be shared with an
internal I2C controller. Add pinctrl support for these pads so that the
I2C controller can request and use these pads.

This series has been tested with Thierry's patches for correcting the
parent clock for the DPAUX devices [0].

Changes from V1:
- Updated dt node names to use '-' instead of '_' per Rob H's feedback.
- Updated commit message and dt-binding description for 'i2c-bus' node
  per Wolfram's feedback.
- Note the pinctrl patch to add a helper function for freeing mappings [1]
  is not included in this latest version of the series as this has already
  been picked up by Linus W.

Changes from initial RFC:
- Dropped patches for adding sor-safe clocks to DPAUX in favour of the
  patches from Thierry [0].
- Split the DPAUX function to enable the DPAUX pads into two functions:
  one for turning on and one for turning off the pads.
- Updated the description for the 'i2c-bus' node based upon Mark R's
  feedback.
- Dropped the second test if the i2c-core when checking for the presence
  of the 'i2c-bus' node based upon Thierry's feedback.
- Removed depedency on CONFIG_PINCTRL in the DPAUX driver in favour of
  using #ifdef's per Thierry's feedback (note by removing the dependency
  on CONFIG_PINCTRL I had to use #ifdefs as all the structures, function
  tables, and functions may not be defined).
- Updated SOR power partition device-tree node to include all clocks and
  resets as described in the Tegra210 TRM.
(Continue reading)

Gao Pan | 28 Jun 13:19 2016

[Patch v1] i2c: imx: add low power i2c bus driver

Add i.MX low power i2c bus driver which can continue operating
in stop modes provided an appropriate clock is available.

This driver has been verified to work well with gpio expander
PCA9557. The verification procedure is below:

echo 240 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio240/direction
echo 1/0 > /sys/class/gpio/gpio240/value

When value is set to be 1, port p0 of PCA9557 is driven high.
Otherwise, P0 is driven low.

Signed-off-by: Gao Pan <pandy.gao <at> nxp.com>
Reviewed-by: Fugang Duan <B38611 <at> freescale.com>
---
 .../devicetree/bindings/i2c/i2c-imx-lpi2c.txt      |  25 +
 drivers/i2c/busses/Kconfig                         |  10 +
 drivers/i2c/busses/Makefile                        |   1 +
 drivers/i2c/busses/i2c-imx-lpi2c.c                 | 646 +++++++++++++++++++++
 4 files changed, 682 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
new file mode 100644
index 0000000..1f10cbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
 <at>  <at>  -0,0 +1,25  <at>  <at> 
+* Freescale Low Power Inter IC (LPI2C) for i.MX
+
(Continue reading)

為溢(阿尼先生 | 28 Jun 01:41 2016
Picon

i2c-ismt: IRDPE error

Hi everyone,

I’m working on a board that using intel iSMT controller to communicate
with custom I2C slave device.
But sometimes I got IRDPE error while reading data from device.

And I got information that there is a Errata about this error and has
a workaround.
Does anyone know the detail about that Errata ?
And have this workaround already be implemented in the latest i2c-ismt driver ?

Thanks.

Best regards
Kenny Cheng.

=== IRDPE Error message ===
=== Kernel version 3.13.11 ===
[   96.776427] priv->dma_buffer (after completion) - 06 24 00 00  24
01 A1 FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF
FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF
FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  FF
[   96.799780] Processing completed descriptor
[   96.804464] Descriptor struct:  ffff8802739ae010
[   96.809631]  tgtaddr_rw=0xFE
[   96.812846]  wr_len_cmd=0x07
[   96.816059]  rd_len=    0x28
[   96.819280]  control=   0x68
[   96.822503]  status=    0x00
[   96.825727]  retry=     0x00
(Continue reading)

Amitoj Kaur Chawla | 27 Jun 16:47 2016
Picon
Gravatar

[PATCH] i2c: mv64xxx: Use clk_enable_prepare and clk_disable_unprepare

Replace clk_enable and clk_prepare with clk_enable_prepare and
clk_disable and clk_unprepare with clk_disable_unprepare.

The Coccinelle semantic patch used to make this change is as follows:
 <at>  <at> 
expression e;
 <at>  <at> 

- clk_prepare(e);
- clk_enable(e);
+ clk_prepare_enable(e);

 <at>  <at> 
expression e;
 <at>  <at> 

- clk_disable(e);
- clk_unprepare(e);
+ clk_disable_unprepare(e);

Signed-off-by: Amitoj Kaur Chawla <amitoj1606 <at> gmail.com>
---
 drivers/i2c/busses/i2c-mv64xxx.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 43207f5..79bae48 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
 <at>  <at>  -910,10 +910,8  <at>  <at>  mv64xxx_i2c_probe(struct platform_device *pd)
(Continue reading)

David Oberhollenzer | 27 Jun 13:39 2016
Picon

Sensor with 7 bit address above 0x77

Hi!

I have an issue with a recently purchased I2C sensor that (according to the manufacturer) responds
to bus address 0x78.

The i2c-tools program i2cdetect only displays addresses in the range 0x03 to 0x77 and i2cdump
complains that the address is out of range.

Since 0x77 seems pretty arbitrary and strange for a hardware limit (0 bit right in the center),
I assumed that the remaining 8 addresses above 0x77 might be reserved for some special use and
started digging around in the documentation.

Both programs mention the limitations in their manpages but give *no explanation* on why they
exist or where those special values came from. i2cdetect seems to have a switch to override
this behaviour, but i2cdump doesn't.

I found no mentioning of the magic limits in the uapi headers. In fact, a quick git grep revealed
that the i2c-tools are sprinkled with *hard-coded* address range checks.

I found no mentioning in the kernel documentation either. A quick git grep in the kernel source
lead me to i2c-core.c:897 (i2c_check_7bit_addr_validity_strict) where yet another hard-coded
address check is performed.

The comment above the line states that addresses 0x78-0x7b are used for 10-bit slave
addressing. The documentation on 10-bit slave addressing (Documentation/i2c/ten-bit-addresses)
says "...The leading 0xa (= 10) represents the 10 bit mode...". Wouldn't such an address
on the bus be quite problematic as 0xA has a leading 1 bit (read/write select?).

After a quick search on the mailing list, I found a number of messages regarding 10 bit addresses,
mentioning _completely_ different address ranges for mapping 10 bit addresses.
(Continue reading)

Lukasz Gemborowski | 27 Jun 11:21 2016
Picon

[PATCH] i2c: i2c-mux-reg: wrong condition checked for of_address_to_resource return value

of_address_to_resource return 0 on successful call but
devm_ioremap_resource is called only if it returns non-zero value

Signed-off-by: Lukasz Gemborowski <lukasz.gemborowski <at> nokia.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin <at> nokia.com>
---
 drivers/i2c/muxes/i2c-mux-reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/muxes/i2c-mux-reg.c b/drivers/i2c/muxes/i2c-mux-reg.c
index 26e7c51..012a7ab 100644
--- a/drivers/i2c/muxes/i2c-mux-reg.c
+++ b/drivers/i2c/muxes/i2c-mux-reg.c
 <at>  <at>  -145,7 +145,7  <at>  <at>  static int i2c_mux_reg_probe_dt(struct regmux *mux,
 		mux->data.idle_in_use = true;

 	/* map address from "reg" if exists */
-	if (of_address_to_resource(np, 0, &res)) {
+	if (!of_address_to_resource(np, 0, &res)) {
 		mux->data.reg_size = resource_size(&res);
 		mux->data.reg = devm_ioremap_resource(&pdev->dev, &res);
 		if (IS_ERR(mux->data.reg))
--

-- 
2.5.0

Stefan Agner | 26 Jun 11:34 2016
Picon

[PATCH 1/3] Documentation: dt: i2c: use correct STMicroelectronics vendor prefix

The documentation currently uses the non-standard vendor prefix stm
and st-micro for STMicroelectronics. The drivers do not specify the
vendor prefixes since the I2C Core strips them away from the DT
provided compatible string. Therefor, changing documentation and
existing device trees does not have any impact on device detection.

Signed-off-by: Stefan Agner <stefan <at> agner.ch>
---
Hi,

Mark mentioned that issue already once in the past, see:
http://lkml.iu.edu/hypermail/linux/kernel/1309.0/01686.html

Not sure through which trees this patches should flow, I guess
the first through Wolfram's tree, the ARM changes through Arnd
or Shawns tree (mostly Freescale boards are affected), not sure
about the PowerPC changes...

--
Stefan

 Documentation/devicetree/bindings/i2c/trivial-devices.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 53987449..8db3384 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
 <at>  <at>  -81,10 +81,10  <at>  <at>  samsung,24ad0xd1	S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
 sgx,vz89x		SGX Sensortech VZ89X Sensors
(Continue reading)

Stefan Roese | 24 Jun 13:57 2016
Picon
Picon

i2c-i801 / SMBus timeouts on BayTrail board (U-Boot)

Hi,

I'm currently trying to use the SMBus on a congatec BayTrail board.
This works just fine when booting via the original BIOS. But when I
boot into Linux using U-Boot as bootloader, I get the following
errors:

[   81.877121] i801_smbus 0000:00:1f.3: Transaction timeout
[   81.879228] i801_smbus 0000:00:1f.3: Failed terminating the transaction
[   81.879320] i801_smbus 0000:00:1f.3: SMBus is busy, can't use it!
[   81.879373] i801_smbus 0000:00:1f.3: SMBus is busy, can't use it!
[   81.879421] i801_smbus 0000:00:1f.3: SMBus is busy, can't use it!
[   81.879496] i801_smbus 0000:00:1f.3: SMBus is busy, can't use it!
...

I checked with an oscilloscope and the SMBus clock is not toggling
at all in this case. My feeling is, that some basic setup is missing
in this non-BIOS case. Like some clock enabling. Does anyone of you
have some idea here?

Thanks,
Stefan
Karl-Heinz Schneider | 22 Jun 21:07 2016
Picon

[PATCH 0/2] Add support for Smart Battery System Manager

This patch series adds support for Smart Battery System Manager.
A SBSM is a device listening at I2C/SMBus address 0x0a and is capable of
communicating up to four I2C smart battery devices. All smart battery
devices are listening at address 0x0b, so the SBSM muliplexes between
them. The driver makes use of the I2C-Mux framework to allow smart
batteries to be bound via device tree, i.e. the sbs-battery driver.

Via sysfs interface the online state and charge type are presented. If
the driver is bound as ltc1760 (a Dual Smart Battery System Manager)
the charge type can also be changed from trickle to fast.

Patch set generated against v4.7rc-4.

Karl-Heinz Schneider (2):
  Documentation: Add sbs-manager device tree node documentation
  power: Adds support for Smart Battery System Manager

 .../devicetree/bindings/power/sbs,sbs-manager.txt  |  57 ++++
 drivers/power/Kconfig                              |  13 +
 drivers/power/Makefile                             |   1 +
 drivers/power/sbs-manager.c                        | 346 +++++++++++++++++++++
 4 files changed, 417 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/sbs,sbs-manager.txt
 create mode 100644 drivers/power/sbs-manager.c

--
1.9.1
M'boumba Cedric Madianga | 21 Jun 09:59 2016
Picon

Question about I2C driver upstream from same SoC vendor

Hi Wolfram,

I am currently upstreaming a driver to support the I2C controller
embedded in STM32F4 SoC from ST.
In the meantime, I am thinking how to add the support of the I2C
controller embedded in STM32F7 SoC.
The I2C IP are very different between F4 and F7 SoC in term of IP
engine, registers and so on.
So, I have intended to develop 2 different drivers, the first one
called i2c-stm32f4.c and the second one called i2c-stm32f7.c.
I am wondering if it is the good way of working as I noticed that many
maintainers prefer to have one driver that support all IPs of the same
SoC vendor ?
In our case, I think it will be possible to support both I2C IPs in
one driver called i2c-stm32.c but the code will run of readability and
will be difficult to maintain...

Thanks in advance for your feedback.

BR,
Cedric
Andy Shevchenko | 20 Jun 10:58 2016
Picon
Gravatar

[PATCH v2 1/1] i2c: designware-pci: clarify a comment for Merrifield

There are more than 7 busses, but only 7 are user visible. Update comment
accordingly.

Acked-by: Jarkko Nikula <jarkko.nikula <at> linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko <at> linux.intel.com>
---
v2:
- fix typo
- add Ack
 drivers/i2c/busses/i2c-designware-pcidrv.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c b/drivers/i2c/busses/i2c-designware-pcidrv.c
index b66c31a..96f8230 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
 <at>  <at>  -125,10 +125,10  <at>  <at>  static int mfld_setup(struct pci_dev *pdev, struct dw_pci_controller *c)
 static int mrfld_setup(struct pci_dev *pdev, struct dw_pci_controller *c)
 {
 	/*
-	 * On Intel Merrifield the i2c busses are enumerated [1..7]. So, we add
-	 * 1 to shift the default range. Besides that the first PCI slot
-	 * provides 4 functions, that's why we have to add 0 to the head slot
-	 * and 4 to the tail one.
+	 * On Intel Merrifield the user visible i2c busses are enumerated
+	 * [1..7]. So, we add 1 to shift the default range. Besides that the
+	 * first PCI slot provides 4 functions, that's why we have to add 0 to
+	 * the first slot and 4 to the next one.
 	 */
 	switch (PCI_SLOT(pdev->devfn)) {
(Continue reading)


Gmane