Re: TWL6040 fails to initialize

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

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
--
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