From: florian.vaussard@epfl.ch (Florian Vaussard)
To: linux-arm-kernel@lists.infradead.org
Subject: TWL6040 fails to initialize
Date: Wed, 26 Feb 2014 10:53:02 +0100 [thread overview]
Message-ID: <530DB97E.80309@epfl.ch> (raw)
In-Reply-To: <530D972F.805@ti.com>
Hi,
First, thanks for your help.
On 02/26/2014 08:26 AM, Peter Ujfalusi wrote:
> On 02/25/2014 05:41 PM, Florian Vaussard wrote:
>> If the power was not enabled at all, I would be unable to read the
>> revision register, no? And delaying the probe by one millisecond would
>> be of no help in this case IMHO.
>
> One thing which might cause this is that if the audpwron GPIO is set high
> before the twl6040 module is probing. When I request the GPIO I ask it to be
> set to low. If the line was high before this means we initiate the power off
> sequence.
> Can you try something like this:
>
I statistically checked that the sleep should be placed after the GPIO
request, so indeed this seems to be the problem, and your explanation is
plausible. Can you send a proper patch?
Now, related to this, I managed to found a part of the datasheet on the
Great Internet. Looking at the "Power-Up Sequence" section, it is written:
- NRESPWRON goes high -> plug detect and GPO are available
- V2V1 goes high -> hook-detect available by I2C programming (sleep mode)
- AUDPWRON goes high && READYINT -> ready to communicate through I2C and PDM
So, although there seems to be some contradictions on when it is
possible to access the I2C, shouldn't we enable the AUDPWRON GPIO
_before_ making any I2C access?
For the twl6040_probe, the following path would seem more correct to me:
1) enable regulators
2) request AUDPWRON
3) twl6040_power(ON) && regcache_cache_only(false)
4) wait for READYINT (or sleep if deterministic)
5) perform all required I2C accesses (read revision, etc.)
6) twl6040_power(OFF) && regcache_cache_only(true)
What do you think?
Thanks,
Florian
> diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
> index 75316fb33448..d2a0bd1539ae 100644
> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -674,6 +674,9 @@ static int twl6040_probe(struct i2c_client *client,
> GPIOF_OUT_INIT_LOW, "audpwron");
> if (ret)
> goto gpio_err;
> +
> + /* power-down sequence latency */
> + usleep_range(500, 700);
> }
>
> ret = regmap_add_irq_chip(twl6040->regmap, twl6040->irq, IRQF_ONESHOT,
>
>
next prev parent reply other threads:[~2014-02-26 9:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 10:30 TWL6040 fails to initialize Florian Vaussard
2014-02-25 14:29 ` Peter Ujfalusi
2014-02-25 15:41 ` Florian Vaussard
2014-02-26 7:26 ` Peter Ujfalusi
2014-02-26 9:53 ` Florian Vaussard [this message]
2014-02-26 10:28 ` Peter Ujfalusi
2014-02-26 10:31 ` Florian Vaussard
2014-02-27 12:05 ` Peter Ujfalusi
2014-02-27 15:24 ` Florian Vaussard
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=530DB97E.80309@epfl.ch \
--to=florian.vaussard@epfl.ch \
--cc=linux-arm-kernel@lists.infradead.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).