From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757206AbcDGR2h (ORCPT ); Thu, 7 Apr 2016 13:28:37 -0400 Received: from mga11.intel.com ([192.55.52.93]:14953 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757168AbcDGR2f (ORCPT ); Thu, 7 Apr 2016 13:28:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,449,1455004800"; d="scan'208";a="682525527" From: "De Marchi, Lucas" To: "christian.ruppert@alitech.com" , "linux-i2c@vger.kernel.org" CC: "wsa@the-dreams.de" , "linux-kernel@vger.kernel.org" , "mika.westerberg@linux.intel.com" , "jarkko.nikula@linux.intel.com" Subject: Re: [PATCH] i2c: designware: do not disable adapter after transfer Thread-Topic: [PATCH] i2c: designware: do not disable adapter after transfer Thread-Index: AQHRi8Dwe9F/2XTd3ECZLWop4Sjbip9/Av8AgABAowA= Date: Thu, 7 Apr 2016 17:28:28 +0000 Message-ID: <1460050108.5123.6.camel@intel.com> References: <1459478866-3896-1-git-send-email-lucas.de.marchi@gmail.com> <57066284.30403@alitech.com> In-Reply-To: <57066284.30403@alitech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.27.71] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u37HSfEN011099 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