On 02/27/2014 01:05 PM, Peter Ujfalusi wrote: > 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. > As I said in the other thread, reading INTID is solving the issue, but it could be a side effect. > 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. > I should probe the I2C bus to dig the issue further, but I don't have access to the pins. So apart drilling into the PCB, this will remain a kind of mystery. Your patches are somehow solving this, so I will stop my investigations for now. > 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. > Not sure neither. Thanks for your help on this. Regards, Florian -- 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
