Re: TWL6040 fails to initialize

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/26/2014 12:31 PM, Florian Vaussard wrote:
>>> 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?
>>
>> Even when the AUDPWRON signal is low we can access to registers in VIO domain,
>> plug detect and GPO functions. So there's no need to power on the codec just
>> to power it down later.
>>
> 
> Ok, if it is safe to do so, I am fine with the current probe. I let you
> post a patch to add a delay after requesting the GPIO.


There's something else going on on your board.
I did some experiments on PandaBoards: in u-boot I set the GPIO127 (audpwron)
high and boot the kernel.
During the boot I see all sorts of errors, mcpdm fails to reset, i2c timeouts
towards twl6040.
For this the solution is to read the INTID register just after I request the
gpio - to clear any no longer valid interrupts before we request the IRQ. This
works fine on my boards.

The issue you have with your board is something totally different.
One thing might be that the i2c bus is set to 400KHz while the twl6040 by
default is set for normal mode (100KHz). On all of the boards I have access
this works fine but there might be some electrical issue on your board which
causes i2c to fail.

There's also another thing I just noticed: the regmap patch
regmap_register_patch() when it is applied will not update the regcache by
design. I do not like that too much. On the other hand it is handy to set the
ACCCTL register as early as possible.

So, I'm not sure about the delay and why it helps on your board.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux