On Thu, 16 May 2013 21:30:59 +0100
Russell King rmk+ker...@arm.linux.org.uk wrote:
Do not use interruptible waits in an I2C driver; if a process uses
signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can
cause the I2C driver to abort a transaction in progress by another
driver,
On Wed, May 08, 2013 at 02:34:36PM +0100, Josef Ahmad wrote:
From 8a4773d0c0df6fe2e816ad37fde30a2d90a1ad31 Mon Sep 17 00:00:00 2001
From: Josef Ahmad josef.ah...@linux.intel.com
Date: Fri, 19 Apr 2013 17:28:10 +0100
Subject: [PATCH] i2c-designware: fix RX FIFO overrun
i2c_dw_xfer_msg()
On Tue, May 14, 2013 at 02:07:45PM +0300, Mika Westerberg wrote:
On Tue, Apr 09, 2013 at 12:59:54PM +0200, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through device tree.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
Signed-off-by: Pierrick
On Mon, May 13, 2013 at 01:54:30PM +0300, Mika Westerberg wrote:
If the I2C bus is put to a low power state by an ACPI method it might pull
the SDA line low (as its power is removed). Once the bus is put to full
power state again, the SDA line is pulled back to high. This transition
looks like
On Mon, May 13, 2013 at 01:54:31PM +0300, Mika Westerberg wrote:
This is the same controller as on Intel Lynxpoint but the ACPI ID is
different (8086F41). Add support for this.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Applied to for-current, thanks!
--
To unsubscribe
Applied to for-current, thanks!
Added stable, too.
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 17, 2013 at 08:37:43AM +0200, Jean-Francois Moine wrote:
On Thu, 16 May 2013 21:30:59 +0100
Russell King rmk+ker...@arm.linux.org.uk wrote:
Do not use interruptible waits in an I2C driver; if a process uses
signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can
Hi Robert,
On Thu, 16 May 2013 13:44:55 +1000, Robert Norris wrote:
On Wed, May 15, 2013 at 09:49:23PM +0200, Jean Delvare wrote:
Interrupt: pin B routed to IRQ 0
Hmm, this IRQ 0 is quite odd. I'm wondering if this could be the
reason for this hang. Was it with the i2c-i801 driver
On Fri, May 17, 2013 at 10:29:28AM +0200, Wolfram Sang wrote:
On Tue, May 14, 2013 at 02:07:45PM +0300, Mika Westerberg wrote:
On Tue, Apr 09, 2013 at 12:59:54PM +0200, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through device tree.
Signed-off-by:
On Wed, May 15, 2013 at 02:44:10PM +0200, Jean Delvare wrote:
Duplicate the feature bits documentation in modinfo, as not every user
will read the driver's source code or documentation file.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Applied to for-current, thanks!
--
To unsubscribe
On Thu, 16 May 2013 13:44:55 +1000, Robert Norris wrote:
Then do a simple read from a random address
with:
# i2cget 4 0x50 0x00
(Adjust the bus number as needed.)
I am curious if this will hang as well or only when accessing the
clock chip at address 0x69.
Yep, that one
New bindings are complicated. I need to check if there is an
existing/similar one, check if it is generic enough for drivers still to
come, etc. I didn't have the time to do this for 3.10, so it is
3.11 material.
OK, thanks. I just wanted to be sure this patch wasn't forgotten as it is
Hi,
while you are chasing some problem with i2c_801 I would like to mention
that I never got an answer on the thread https://lkml.org/lkml/2013/1/23/405
about a kmemleak reported by kernel . Maybe this could give you a hint?
If these do not overlap I would be anyways glad to receive an answer
On Thu, 16 May 2013 21:33:09 +0100
Russell King rmk+ker...@arm.linux.org.uk wrote:
Eliminate reg_base_p and reg_size, mv64xxx_i2c_unmap_regs() and an
unchecked ioremap() return from this driver by using the devm_*
API for requesting and ioremapping resources.
Signed-off-by: Russell King
On Fri, May 17, 2013 at 11:23:16AM +0200, Jean-Francois Moine wrote:
On Thu, 16 May 2013 21:33:09 +0100
Russell King rmk+ker...@arm.linux.org.uk wrote:
Eliminate reg_base_p and reg_size, mv64xxx_i2c_unmap_regs() and an
unchecked ioremap() return from this driver by using the devm_*
API
On Thu, May 09, 2013 at 04:27:22PM +0800, Libo Chen wrote:
fix two wrong mem release
* Changelog from v1:
* exchange out_error_no_irq and out_error_pin_mux suggested by Sonic
sonic.zh...@analog.com
* add some new tag , make code cleanly
Thanks for the submission. I do think the
On Fri, 17 May 2013 11:22:17 +0200, Martin Mokrejs wrote:
Hi,
while you are chasing some problem with i2c_801 I would like to mention
that I never got an answer on the thread https://lkml.org/lkml/2013/1/23/405
about a kmemleak reported by kernel . Maybe this could give you a hint?
If these
@@ -271,12 +273,25 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
{
switch(drv_data-action) {
case MV64XXX_I2C_ACTION_SEND_RESTART:
+ /* We should only get here if we have further messages */
+ BUG_ON(drv_data-num_msgs == 0);
+
...
@@
The comment already got copypasted around and is not really useful.
Remove it.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/busses/i2c-davinci.c|1 -
drivers/i2c/busses/i2c-designware-platdrv.c |1 -
drivers/i2c/busses/i2c-omap.c |1 -
3
On Fri, May 17, 2013 at 4:36 PM, Jean Delvare kh...@linux-fr.org wrote:
Hi Robert,
On Thu, 16 May 2013 13:44:55 +1000, Robert Norris wrote:
On Wed, May 15, 2013 at 09:49:23PM +0200, Jean Delvare wrote:
Interrupt: pin B routed to IRQ 0
Hmm, this IRQ 0 is quite odd. I'm wondering if
On Fri, May 17, 2013 at 11:51:51AM +0200, Wolfram Sang wrote:
{
switch(drv_data-action) {
case MV64XXX_I2C_ACTION_SEND_RESTART:
+ /* We should only get here if we have further messages */
+ BUG_ON(drv_data-num_msgs == 0);
+
...
@@ -453,16 +463,20 @@
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
On Fri, May 17, 2013 at 10:36:22AM +0200, Jean Delvare wrote:
IPMI is still likely to access the SMBus controller. If there's a BMC
in the machine, it can also access the SMBus slave with its own
controller. It would be good to rule this out by disabling IPMI
completely, removing the BMC from
On Fri, May 17, 2013 at 05:54:33PM +0800, Daniel Kurtz wrote:
Was Robert able to get the system working without hangs by disabling
the IRQ feature of i2c-i801 module when it was builtin?
Yes. There are no hangs when interrupts are explicitly disabled with
disable_features=0x10 or when 6676a847
On Fri, May 17, 2013 at 10:49:28AM +0200, Jean Delvare wrote:
Hmm, can you please dump the PCI configuration space of the SMBus
controller?
# /sbin/lspci -s 00:1f.3 -xxx
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller
(rev 09)
00: 86 80 9b 26 41 05 80 02 09 00
On Fri, 17 May 2013 20:27:06 +1000, Robert Norris wrote:
On Fri, May 17, 2013 at 10:49:28AM +0200, Jean Delvare wrote:
Hmm, can you please dump the PCI configuration space of the SMBus
controller?
# /sbin/lspci -s 00:1f.3 -xxx
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100
Applied to for-current, thanks!
Added stable, too.
Thanks Wolfram.
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 17, 2013 at 11:00:16AM +0100, Russell King - ARM Linux wrote:
On Fri, May 17, 2013 at 11:51:51AM +0200, Wolfram Sang wrote:
{
switch(drv_data-action) {
case MV64XXX_I2C_ACTION_SEND_RESTART:
+ /* We should only get here if we have further messages */
+
On Thu, May 16, 2013 at 09:30:59PM +0100, Russell King wrote:
Do not use interruptible waits in an I2C driver; if a process uses
signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can
cause the I2C driver to abort a transaction in progress by another
driver, which can cause that
On Fri, May 17, 2013 at 10:36:22AM +0200, Jean Delvare wrote:
IPMI is still likely to access the SMBus controller. If there's a BMC
in the machine, it can also access the SMBus slave with its own
controller. It would be good to rule this out by disabling IPMI
completely, removing the BMC from
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via delete_device sysfs
attribute) which contains subdevices (e.g. i2c multiplexer):
On Fri, May 17, 2013 at 11:53:23AM +0200, Wolfram Sang wrote:
The comment already got copypasted around and is not really useful.
Remove it.
Signed-off-by: Wolfram Sang w...@the-dreams.de
FWIW on i2c-omap.c:
Acked-by: Felipe Balbi ba...@ti.com
--
balbi
signature.asc
Description: Digital
On Fri, 17 May 2013, Alexander Sverdlin wrote:
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via delete_device sysfs
attribute) which contains subdevices (e.g. i2c
Hi!
On 05/17/2013 04:42 PM, ext Alan Stern wrote:
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via delete_device sysfs
attribute) which contains subdevices (e.g. i2c
On Fri, 17 May 2013, Alexander Sverdlin wrote:
Hi!
On 05/17/2013 04:42 PM, ext Alan Stern wrote:
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via
Hi!
On 05/17/2013 05:31 PM, ext Alan Stern wrote:
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via delete_device sysfs
attribute) which contains subdevices (e.g. i2c
On Thu, May 16, 2013 at 09:30:59PM +0100, Russell King wrote:
Do not use interruptible waits in an I2C driver; if a process uses
signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can
cause the I2C driver to abort a transaction in progress by another
driver, which can cause that
On Fri, 17 May 2013, Alexander Sverdlin wrote:
Hi!
On 05/17/2013 05:31 PM, ext Alan Stern wrote:
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following
lockdep
warning is thrown in case i2c device is removed (via
On Fri, May 17, 2013 at 02:56:35PM +0200, Alexander Sverdlin wrote:
i2c: suppress lockdep warning on delete_device
Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via delete_device sysfs
attribute) which contains
Hello all,
Attached patch adds support for secondary SMBus of AMD SB800 and new AMD FCH
chipsets. The base address of secondary SMBus is different from SB700 and it is
stored on similar place as SB800 primary SMBus.
More verbose info:
Probing function was just modified to read the SMBus
40 matches
Mail list logo
