TWL6040 fails to initialize
Peter Ujfalusi
peter.ujfalusi at ti.com
Tue Feb 25 09:29:46 EST 2014
Hi Florian,
On 02/25/2014 12:30 PM, Florian Vaussard wrote:
> Hi Peter,
>
> I got recently to work on the DT support for an OMAP4 board [1], and I
> encountered some troubles with the probe of the twl6040 audio codec on
> 3.14-rc kernels. On 3.13, things were working correctly. So I somewhat
> managed to bisect this down to [c7f9129 mfd: twl6040: reg_defaults
> support for regmap]. But looking more into it, things are less obvious.
Interesting. I just booted 3.14.0-rc4 with HEAD:
7472e009a3f1 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
on my PandaBoard-ES and audio comes up just fine (twl6040).
>
> When the init fails, here is what happens:
>
> [ 2.455749] twl6040 0-004b: Looking up vio-supply from device tree
> [ 2.456359] twl6040 0-004b: Looking up v2v1-supply from device tree
> [ 2.457061] twl6040 0-004b: Failed to set masks in 0x4: -121
> [ 2.463043] twl6040: probe of 0-004b failed with error -121
>
> logically resulting in
Do you have the regulators in your dts file? vio and v2v1 is needed by the
twl6040.
>
> [ 2.770050] omap-abe-twl6040 sound.4: ASoC: CODEC twl6040-codec not
> registered
> [ 2.777770] omap-abe-twl6040 sound.4: snd_soc_register_card() failed:
> -517
> [ 2.785095] platform sound.4: Driver omap-abe-twl6040 requests probe
> deferral
>
> We get a EREMOTEIO when calling regmap_add_irq_chip() from
> twl6040_probe(). regmap_add_irq_chip() will try to perform non-cached
> i2c writes, where the omap-i2c driver get a NACK from the remote chip.
> Strange enough, the non-cached read just before (i.e.
> twl6040_reg_read(twl6040, TWL6040_REG_ASICREV)) succeeds.
Power is not enabled? There might be missing 32K clock for twl6040, can you
check your board's schema against PandaBoard-ES?
>
> After some fiddling around, I could find that delaying the call to
> regmap_add_irq_chip(), let's say by msleep(1), will "solve" the problem.
>
> As the TRM for TWL6040 is not public, and I cannot physically access the
> i2c bus on the board, I ran out of hypothesis. I first suspected a
> concurrent access from the McPDM bus, but the mcpdm driver does not seem
> to perform command (write) access.
>
> As the regulators are enabled just before, could it be the twl6040 IP
> which is not yet initialized, and NACK'ing writes but not reads? The
> commit c7f9129 changed the regmap logic by reducing the number of
> non-cached accesses, and thus changed the access timings, so it may have
> trigged this behaviour. But this is pure supposition, as I cannot hack
> the i2c bus :( And adding any kind of tracing before
> regmap_add_irq_chip() usually delays enough to make the probe succeeds.
>
> Any ideas?
>
> Regards,
> Florian
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/110801
>
--
Péter
More information about the linux-arm-kernel
mailing list