linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
To: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>,
	Jon Cormier <jcormier-wZX4cNJlHJ2sVWG7oymsAA@public.gmane.org>,
	Brian Niebuhr <BNiebuhr-0skhLfht8co@public.gmane.org>
Cc: "davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org"
	<davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>,
	Tim Iskander
	<tim.iskander-wZX4cNJlHJ2sVWG7oymsAA@public.gmane.org>,
	"linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> linux-i2c"
	<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: i2c-davinci.c: CPU FREQ causes lock up due to xfr_complete
Date: Wed, 30 Jul 2014 17:52:50 +0300	[thread overview]
Message-ID: <53D906C2.9080005@ti.com> (raw)
In-Reply-To: <53D88E4E.3030108-l0cyMroinI0@public.gmane.org>

On 07/30/2014 09:18 AM, Sekhar Nori wrote:
> On Tuesday 29 July 2014 11:00 PM, Grygorii Strashko wrote:
>> Hi Jon,
>>
>> On 07/29/2014 06:53 PM, Jon Cormier wrote:
>>> A slimmer patch suggested by Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
>>
>>
>> Ok. The problem seems to be deeper than at first look.
>> You have sequence (in Mainline kernel):
>> cpufreq:
>>   |- notify CPUFREQ_PRECHANGE
>>      |- i2c-davinci will lock & put I2C in reset
>>   |- cpufreq_driver->target_index
>>      |- davinci_target()
>>         |- pdata->set_voltage() - It will try to use I2C to set new voltage,
>>         while I2C is in reset or locked! Bug!
>>   |- notify CPUFREQ_POSTCHANGE
>>      |- i2c-davinci will re-enable I2C and adjust I2C clock
>
> Good find. I really wonder how this escaped so far. I can swear cpufreq
> transitions were tested multiple times. From the description it looks
> like this should hit every single time there is a voltage adjustment.
>
> On DA850 which is the only DaVinci implementing cpufreq, I2C0 input
> frequency will remain constant across cpufreq transitions since it
> derives from PLL0 AUXCLK which is used pre-multipler/divider. It remains
> fixed.
>
> The code seems to have been added for I2C1 which does have a fixed ratio
> with cpu clock.
>
> PMIC should usually be put on I2C0 to help prevent these kind of issues.
>
>> I see few possible ways to solve it:
>> 1) use CLK notifier instead of CPUfreq notifiers
>
> This will require common clock framework, right? We dont have that on
> mach-davinci.

:( I've forgotten about that.

>
>> 2) do smth similar to "61c7cff8 i2c: S3C24XX I2C frequency scaling support"
>>    + "9bcd04bf i2c: s3c2410: grab adapter lock while changing i2c clock"
>
> This looks promising. Although I wonder if delta_f will always remain
> zero in s3c24xx_i2c_cpufreq_transition() when the CPUFREQ_PRECHANGE call
> is made - because clock tree is not updated yet?

That's funny - seems PRE/POST notifiers are called twice for s3c24xx :)
First one from cpufreq core.
Second time from s3c_cpufreq_target() and, looks like, clock
freq will be updated at that time.


>
>> 3) update I2C clock in CPUFREQ_POSTCHANGE - may be unsafe
>
> Well, even now the I2C clock is only getting updated in POSTCHANGE,
> right? Also, resetting I2C in PRECHANGE seems excessive. It is only
> required when changing the prescalar. So you can do:
>
> 	} else if (val == CPUFREQ_POSTCHANGE) {
> 		davinci_i2c_reset_ctrl(dev, 0);
> 		i2c_davinci_calc_clk_dividers(dev);
> 		davinci_i2c_reset_ctrl(dev, 1);
> 	}
>
> So this along with the i2c_lock_adapter() a la
> s3c24xx_i2c_cpufreq_transition() should be the right fix, I guess.
>

Regards,
-grygorii

      parent reply	other threads:[~2014-07-30 14:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CADL8D3YchqfT+ikKTCkLNLmwm2HYKDzZy-g4T+mJLYBJ1rC72Q@mail.gmail.com>
     [not found] ` <2588C357BB271A4CA8E86BCFF043FA920C4ACE9D@EFJDFWMB01.EFJDFW.local>
     [not found]   ` <CADL8D3aQ4idMNYZn-sK=8x9+NrVj=4p58C+ir8ZAngDavGB3-A@mail.gmail.com>
     [not found]     ` <CADL8D3a2gjbGZibENYNfvWrvGun82ZDm7A+i8NJRBKdRvMvgdQ@mail.gmail.com>
     [not found]       ` <CADL8D3a2gjbGZibENYNfvWrvGun82ZDm7A+i8NJRBKdRvMvgdQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-29 17:30         ` i2c-davinci.c: CPU FREQ causes lock up due to xfr_complete Grygorii Strashko
     [not found]           ` <53D7DA44.2070108-l0cyMroinI0@public.gmane.org>
2014-07-29 18:13             ` Jon Cormier
2014-07-30  6:18             ` Sekhar Nori
     [not found]               ` <53D88E4E.3030108-l0cyMroinI0@public.gmane.org>
2014-07-30 14:52                 ` Grygorii Strashko [this message]

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=53D906C2.9080005@ti.com \
    --to=grygorii.strashko-l0cymroini0@public.gmane.org \
    --cc=BNiebuhr-0skhLfht8co@public.gmane.org \
    --cc=davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org \
    --cc=jcormier-wZX4cNJlHJ2sVWG7oymsAA@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nsekhar-l0cyMroinI0@public.gmane.org \
    --cc=tim.iskander-wZX4cNJlHJ2sVWG7oymsAA@public.gmane.org \
    /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).