linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "De Marchi, Lucas" <lucas.demarchi@intel.com>
To: "christian.ruppert@alitech.com" <christian.ruppert@alitech.com>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Cc: "wsa@the-dreams.de" <wsa@the-dreams.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mika.westerberg@linux.intel.com"
	<mika.westerberg@linux.intel.com>,
	"jarkko.nikula@linux.intel.com" <jarkko.nikula@linux.intel.com>
Subject: Re: [PATCH] i2c: designware: do not disable adapter after transfer
Date: Thu, 7 Apr 2016 17:28:28 +0000	[thread overview]
Message-ID: <1460050108.5123.6.camel@intel.com> (raw)
In-Reply-To: <57066284.30403@alitech.com>

Hi Christian,

On Thu, 2016-04-07 at 15:37 +0200, Christian Ruppert wrote:
> Dear Lucas,
> 
> Sorry for the late reply but I had to put our test environment back
> together to check this patch. I'll keep it around for a while in case
> you have further iterations to test.

np, I'll try to iterate faster on this patch now, too.

> On Linux-4.6.0-rc2 the behaviour is still the same: The kernel locks up
> in an irq loop at dwi2c driver probe time. If I don't apply the patch
> everything works fine and the system boots and talks normally on the i2c
> bus.

:(

I really hoped this would work in your case.

> One solution might be to add a device-tree (and acpi) flag to tell the
> driver that it does not need to expect any nastily behaved devices on
> the bus. If this flag is given, the driver could use the faster
> disable-interrupt strategy. Without the flag we need to fall back to the
> conservative disable-i2c-controller strategy.

I'd like to try some other approaches before that. What if we start with it
disabled and enable at first use? After that we keep the approach of just
disabling the interrupts.  I can prep a patch for that.


> I think such a flag should be OK because I2C buses are generally quite
> static and the list of devices should be known at system integration
> time. In the rare cases where this is not true, users could still go
> with the conservative approach. I know that the "cleaner" method would
> be to rather mark nasty devices, either in device tree or in the driver,
> but I guess the required changes in the I2C framework might be overkill
> for this dwi2c specific problem.

agreed

thanks
Lucas De Marchi

  reply	other threads:[~2016-04-07 17:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-01  2:47 [PATCH] i2c: designware: do not disable adapter after transfer Lucas De Marchi
2016-04-07 13:37 ` Christian Ruppert
2016-04-07 17:28   ` De Marchi, Lucas [this message]
2016-04-08 14:01     ` Christian Ruppert
2016-04-22 15:08       ` Lucas De Marchi
2016-04-22 15:19         ` Lucas De Marchi
2016-05-02 10:11           ` Christian Ruppert
2016-05-04 14:38             ` Lucas De Marchi
2016-05-09  8:50               ` Christian Ruppert
2016-04-25 11:51         ` Jarkko Nikula
2016-04-25 15:04           ` Lucas De Marchi
2016-04-27  7:47             ` Jarkko Nikula
2016-04-08 12:17 ` Jarkko Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1460050108.5123.6.camel@intel.com \
    --to=lucas.demarchi@intel.com \
    --cc=christian.ruppert@alitech.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).