gmane.linux.drivers.i2c

[PATCH v2 0/4] Kontron PLD drivers

Kevin Strasser — 2013-06-18T21:04:25

mfd changes since v1:
- Use a mutex instead of spinlock
- Poll for hardware mutex without timeout
- Restructure mfd cell structs, only call mfd_add_devices once
- Drop pointless BUG_ONs
- EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL
- kempld_*_mutex_set_index -> kempld_*_mutex
- Removed kempld_try_get_mutex
- Drop last_index
- Remove EFT code
- Drop unused includes
- Use devm_ioport_map
- Restructure to get rid of forward function prototypes
- Renamed module parameter force_ident -> force_device_id
- Dropped force_unlock module parameter
- Formatting fixes

i2c changes since v1:
- Always disable bus during suspend,
- Detect was_active in probe
- Remove i2c-kempld.h
- Clean up register definitions
- Use the correct device for printing
- Set default bus frequency to 100kHz
- Drop irq support
- Drop now1 driver
- Remove i2c-mux code
- Clean up includes
- Use devm_kzalloc
- Formatting fixes

gpio changes since v1:
- Change label from kempld-gpio -> gpio-kempld
- Drop unnecessary include seq_file.h
- Register and value par

Re: [PATCH v2] i2c-pxa: prepare clock before use

Wolfram Sang — 2013-06-18T16:12:49

Applied to for-next, thanks!

Re: [PATCH v2 0/2] Fix kernel panics with certain I2C tps6* chips

Wolfram Sang — 2013-06-18T15:59:04


Thanks for pointing out. I am going to revert the commit in hope for a
better solution.

So, this series is not needed.

Re: [PATCH 0/2] Fix kernel panics with certain I2C tps6* chips

Wolfram Sang — 2013-06-18T15:58:12

Thanks for pointing out. I am going to revert the commit in hope for a
better solution.

So, this series is not needed.

Regards,

   Wolfram

Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver

Wolfram Sang — 2013-06-18T15:55:31

I am going to revert that commit. I was thinking back and forth, even
playing with the idea to remove the id as a parameter to probe for i2c
drivers and let them request the id from the i2c core when needed. But
now I found more side-effects. E.g. run-time based instantiation for i2c
devices is depending on an id-table. So, for now I keep insisting that
an id-table must exist. Looks like DT-only drivers need more thinking
and this is too late for 3.11.

Regards,

   Wolfram

Re: [PATCH v2 2/2] i2c: imx: Add Vybrid VF610 I2C controller support

Sascha Hauer — 2013-06-20T08:04:06

...


Wow. The i2c unit remained unchanged since the i.MX21 days. Shuffling
some registers or divider values was long overdue...

Sascha

[PATCH 3/4] i2c-i801: SMBus patch for Intel Coleto Creek DeviceIDs

Seth Heasley — 2013-06-19T23:59:57

This patch adds the i801 SMBus Controller DeviceIDs for the Intel Coleto Creek PCH.

Signed-off-by: Seth Heasley <seth.heasley-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>
---
 Documentation/i2c/busses/i2c-i801 |    1 +
 drivers/i2c/busses/Kconfig        |    1 +
 drivers/i2c/busses/i2c-i801.c     |    3 +++
 3 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index d55b8ab..d29dea0 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
< at >< at > -24,6 +24,7 < at >< at > Supported adapters:
   * Intel Lynx Point-LP (PCH)
   * Intel Avoton (SOC)
   * Intel Wellsburg (PCH)
+  * Intel Coleto Creek (PCH)
    Datasheets: Publicly available at the Intel website
 
 On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 631736e..da3af83 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
< at >< at > -108,6 +108,7 < at >< at > con

[PATCH] i2c: mv64xxx: Fix transfer error code

Guenter Roeck — 2013-06-19T21:53:52

The driver returns -ENODEV as error code if it did not get an ACK
from the device. Per Documentation/i2c/fault-codes, it should
return -ENXIO.

Signed-off-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ< at >public.gmane.org>
---
 drivers/i2c/busses/i2c-mv64xxx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 1a3abd6..6972032 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
< at >< at > -227,7 +227,7 < at >< at > mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
 /* Doesn't seem to be a device at other end */
 drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
 drv_data->state = MV64XXX_I2C_STATE_IDLE;
-drv_data->rc = -ENODEV;
+drv_data->rc = -ENXIO;
 break;
 
 default:

Re: [PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle

Felipe Balbi — 2013-06-19T20:56:07

Hi,

On Wed, Jun 19, 2013 at 01:01:28PM -0700, Kevin Hilman wrote:

Indeed, just re-read the code.

Re: [PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle

Kevin Hilman — 2013-06-19T20:01:28

[...]


No. The driver's ->runtime_idle() will only be called when the usecount
goes to zero.

Kevin

Re: [PATCH 5/5] i2c: omap: remove omap_i2c_isr() hw irq handler

Felipe Balbi — 2013-06-19T19:44:46

then you don't need $SUBJECT.

Re: [PATCH 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle

Felipe Balbi — 2013-06-19T19:31:11

Hi,

On Wed, Jun 19, 2013 at 09:35:38PM +0300, Grygorii Strashko wrote:

this doesn't make sense... mark last busy is done after the I2C message
is actually complete, so is pm_runtime_put_autosuspend() which is done
following mark_last_busy. autosuspend timer shouldn't be firing since
put won't be called until we're dead sure I2C message (all of them, in
fact) are finalized.


IRQ subsystem makes sure to disable our IRQ line while our handler is
running and, because of IRQF_ONESHOT, IRQ will only be re-enabled after
thread has finished.


we don't even use runtime_idle() and your statement is wrong, btw. If
you have 200 pm_runtime_get() followed by 200 pm_runtime_put() (put
is called only after 200 gets, no put-get ping-pong), your
->runtime_resume() gets called once, your ->runtime_suspend() gets
called once but your ->runtime_idle() will get called 200 times.

assuming I2C transaction has finished is wrong here. What if we decide
to add pm_runtime_get() on hardirq handler and pm_runtime_put() to the
end of

Re: [RFC] i2c: add deprecation warning for class based instantiation

Grygorii Strashko — 2013-06-19T18:21:51

Hi Wolfram,

On 06/19/2013 01:15 PM, Wolfram Sang wrote:
Sorry, for delayed reply - I've had problems with my e-mail.

I've tested this patch on our TI K3.4 product kernel with additional 
change below:
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index c0330a4..442101d 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
< at >< at > -186,7 +186,7 < at >< at > static int __devinit i2c_gpio_probe(struct 
platform_device *pdev)
         adap->owner = THIS_MODULE;
         snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id);
         adap->algo_data = bit_data;
-       adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
+       adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD | 
I2C_CLASS_DEPRECATED;
         adap->dev.parent = &pdev->dev;
         adap->dev.of_node = pdev->dev.of_node;

It works fine, in general - see my minor comment inline.
[    0.662536] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 400 kHz
[    0.662567]  (null): This adapter will soon drop class based 
i

[PATCH v10] i2c: exynos5: add High Speed I2C controller driver

Naveen Krishna Chatradhi — 2013-06-19T10:48:25

Adds support for High Speed I2C driver found in Exynos5 and
later SoCs from Samsung.

Driver only supports Device Tree method.

Changes since v1:
1. Added FIFO functionality
2. Added High speed mode functionality
3. Remove SMBUS_QUICK
4. Remove the debugfs functionality
5. Use devm_* functions where ever possible
6. Driver is free from GPIO configs
7. Use OF data string "clock-frequency" to get the bus operating frequencies
8. Split the clock divisor calculation function
9. Add resets for the failed transacton cases
10. Removed retries as core does retries if -EAGAIN is returned
11. Removed mode from device tree info (use speed to distinguish
    the mode of operation)
12. Use wait_for_completion_timeout as the interruptible case is not tested well
13. few other bug fixes and cosmetic changes

Signed-off-by: Taekgyun Ko <taeggyun.ko-Sze3O3UU22JBDgjK7y7TUQ< at >public.gmane.org>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen-Sze3O3UU22JBDgjK7y7TUQ< at >public.gmane.org>
Reviewed-by: Simon Glass <sjg-hpIqsD4AKlfQT0d

Re: [PATCH v2 1/2] i2c-mv64xxx: Fix timing issue on Armada XP (errata FE-8471889)

Wolfram Sang — 2013-06-19T10:24:17

You are correct that this does not need a seperate property since this
is a flaw of this specific controller. So, it needs a new compatible
entry ('mv78230-i2c' for example) and this entry should then have the
workaround enabled.

Thanks,

   Wolfram

Re: [PATCH v2 2/2] i2c-mv64xxx: Abort the mv64xxx_of_config if clock-frequency is not provided

Wolfram Sang — 2013-06-19T10:19:40

What about setting it to 100kHz when not defined (and marking the
property optional in the docs)? That's convenient and common I'd say.

Re: [RFC] i2c: add deprecation warning for class based instantiation

Wolfram Sang — 2013-06-19T10:15:27

No reactions on this, pity. Deferring.

Re: i2c: introduce i2c helper i2c_find_client_by_name()

Wolfram Sang — 2013-06-19T10:13:49


I also wonder about the need to unregister. I have to admit I don't know
much about I2C handling in v4l2. But if it requires unregistering from
i2c core and registering to v4l2 core, then it sounds to me like we
could check if there is a more fundamential cleanup needed? Deferring
for now, looks like an issue worth looking at, yet there are other
things in the queue first.

Re: [PATCH v5] i2c: omap: correct usage of the interrupt enable register

Wolfram Sang — 2013-06-19T10:05:09

Last paragraph should be below "---".


Applied to for-next, thanks!

Re: [PATCH] i2c-piix4 - Add support for secondary SMBus on AMD SB800 and AMD FCH chipsets

Wolfram Sang — 2013-06-19T09:55:58

Hi Rudolf,

On Mon, Jun 17, 2013 at 11:37:08PM +0200, Rudolf Marek wrote:

Thanks for adding the docs, but please resend in canonical patch format.
See Documentation/SubmittingPatches, Chapter 15, to find out which
paragraph belongs where (or have a glimpse at other patches). I get so
many patches, it is too much of a burden to fix them all myself.

Regards,

   Wolfram

Re: [PATCH v2 2/2] i2c: imx: Add Vybrid VF610 I2C controller support

Shawn Guo — 2013-06-19T08:51:30

Tested-by: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A< at >public.gmane.org>