On our custom carrier-board (based on the Ixora design) we want to implement powerdown functionality. We have everything in place, the kernel is configured correctly, and we see the GPIO that is supposed to trigger the LTC2954 kill signal getting pulled down after shutdown completes. However, this signal is being blocked by the NC7SZ126M5X buffer because the output enable signal, which is connected to the Apalis RESET_MOCI# signal, stays high.
When the exact same module is inserted into an off-the-shelf Ixora board, the board does power down completely, and we see the RESET_MOCI# signal getting pulled down.
Now, one thing we changed is that we attached the SGTL5000 audio codec to the 3V3 supply, as indicated by the Apalis datasheet, since we do not need audio functionality. Since both this codec and the PFO100 voltage regulator (which produces the RESET_MOCI#) are both on the on-module i2c2 bus, is there any chance the i2c2 bus is getting hung up during shutdown, causing some final communication with the voltage regulator from getting corrupted?
For my understanding, in a normal situation, what triggers the RESET_MOCI# signal to become low? Is this the result of an explicit command to the PFO100, or is this a result of the PFO100 powering down or is it something else?
Also, I see in the PFUZE100 driver there is a “shutdown” function which does some last-minute register updates on the i2c bus. What happens here? If this shutdown fails because the I2C bus is hung up, could that explain the RESET_MOCI# signal staying high? There is dev_err logging included in that driver. Is there an easy way to see if this logging indicates any errros?
Thanks in advance,
Jeroen