Re: [PATCH] i2c: designware: use enable on resume instead initialization

Mika Westerberg
2015-06-10T07:09:41Z

On Tue, Jun 09, 2015 at 03:29:01PM -0300, Lucas De Marchi wrote:
> Hi Mika,
>
> On Tue, Jun 9, 2015 at 5:51 AM, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> > On Mon, Jun 08, 2015 at 02:50:28PM -0300, lucas.de.marchi@gmail.com wrote:
> >> From: Fabio Mello <fabio.mello@intel.com>
> >>
> >> According to documentation and tests, initialization is not
> >> necessary on module resume, since the controller keeps its state
> >> between disable/enable. Change the target address is also allowed.
> >>
> >> So, this patch replaces the initialization on module resume with a
> >> simple enable, and removes the (non required anymore) enables and
> >> disables.
> >>
> >> Signed-off-by: Fabio Mello <fabio.mello@intel.com>
> >> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> >> ---
> >>
> >> These pictures explain a little more the consequence of letting the
> >> enable+disable in the code:
> >>
> >> http://pub.politreco.com/paste/TEK0011-before.jpg
> >> http://pub.politreco.com/paste/TEK0007-after.jpg
> >>
> >> The yellow line is a GPIO toggle in userspace to mark when we start and finish
> >> the i2c transactions. The blue line is the SCL in that i2c bus. Take a look on
> >> the huge pauses we have between any 2 transactions. These pauses are removed
> >> with this patch and we are able to read our sensor's values in 950usec rather
> >> than 5.24msec we had before. We are testing this using a Minnowboard Max that
> >> has a designware i2c controller.
> >
> > Did you test this on any other platform than Intel Baytrail?
>
> No. The only soc we have here with this controller is the Baytrail.

My concern is that this patch might break some non-Intel platform. It
would be nice if someone (Christian?) could try this out.