From: David Brownell <david-b@pacbell.net>
To: Tony Lindgren <tony@atomide.com>
Cc: Felipe Balbi <me@felipebalbi.com>,
"Aguirre Rodriguez, Sergio Alberto" <saaguirre@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH] twl4030: Fix pwrirq by making sure the module is responding (Re: kernel oops for 3430sdp)
Date: Wed, 8 Oct 2008 12:36:48 -0700 [thread overview]
Message-ID: <200810081236.48940.david-b@pacbell.net> (raw)
In-Reply-To: <20081008183808.GA31385@atomide.com>
On Wednesday 08 October 2008, Tony Lindgren wrote:
> > > I suspect that twl is not yet initialized for pwrirq handling at this
> > > point. At least this patch seems to help,
> >
> > Did you verify that the value you read isn't 0xff? Or does the
> > issue seem to be the mere attempt to read a register?
>
> Yeah, it seems to be 0 first, then 0xf0, then 0xf7, then 0xff. It seems
> that at 0xf0 it still does not work. Values from memory, but something
> like that anyways.
Huh. Most bizarre. Oh wait ... that might be explained by
taking a ginormous amount of time to shift out of the 1.5 MHz
clock mode. See 3.4.12 of the manual:
When power is first applied to the device, it does not know
the external HF clock frequency (HFCLK_FREQ has not been set
by the host processor). To ensure that the power subchip
registers can be accessed, the default register access
frequency is 1.5 MHz (1⁄2 of 3 MHz).
Doesn't say how to tell that's happening, or how long it'd take
to change to 3 MHz. (Which only happens if HFCLK isn't 19.2 MHz.)
Maybe wait for BACKUP_MISC_CFG.PWR_CLK_FREQ to clear... it's
just controlling a simple divide-by-two, not a PLL, so it should
be pretty much immediate.
> > I have a hard time seeing the root cause be anything other than
> > problems in i2c-omap, since the timeouts appear at various other
> > places too.
>
> Well at least one twl bug was happening when the source clock was
> initialized incorrectly.. And that only happened with one of the twl
> modules.
The issue above? But we know that HFCLK_FREQ is getting set,
so that wouldn't explain i2c-omap timeouts that show up later.
Or maybe there's another clocking issue...
I hate to look at the i2c-omap, but it really seems like that's
got to be the root cause here. After all, the timeout message
appears way too quickly for it to be a *legitimate* timeout for
any I2C protocol action. (SMBus has timeouts. I2C doesn't...)
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-10-08 19:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-07 18:07 kernel oops for 3430sdp Aguirre Rodriguez, Sergio Alberto
2008-10-07 18:28 ` David Brownell
2008-10-07 19:29 ` Aguirre Rodriguez, Sergio Alberto
2008-10-07 20:09 ` Felipe Balbi
2008-10-08 14:55 ` [PATCH] twl4030: Fix pwrirq by making sure the module is responding (Re: kernel oops for 3430sdp) Tony Lindgren
2008-10-08 18:05 ` David Brownell
2008-10-08 18:38 ` Tony Lindgren
2008-10-08 19:19 ` David Brownell
2008-10-08 19:36 ` David Brownell [this message]
2008-10-08 21:36 ` [PATCH 2.6.27-rc9-omap] i2c-omap: timeouts begone David Brownell
2008-10-08 21:54 ` Felipe Balbi
2008-10-08 22:35 ` Woodruff, Richard
2008-10-10 11:36 ` Paul Walmsley
2008-10-08 23:38 ` Woodruff, Richard
2008-10-09 1:09 ` David Brownell
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=200810081236.48940.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-omap@vger.kernel.org \
--cc=me@felipebalbi.com \
--cc=saaguirre@ti.com \
--cc=tony@atomide.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.