Hi Keerhty, On Tue, Jul 31, 2018 at 02:04:46PM +0530, Keerthy wrote: > Hi All, > > I am looking at the poweroff scenario. At least on ARM based SoCs i see > that machine_power_off first disables the local interrupts and then > shuts off the secondary cores with smp_send_stop. > > After this happens we try to shutdown the PMIC that interact over I2C. > I2C writes will need I2C interrupts to be enabled but in an interrupt > disabled context if shutting PMIC is the last thing in the sequence > which needs I2C writes is there an already existing solution to this > scenario? Any pointers would help. Just to add my two bits of information. I was facing the same problem two years ago and send a RFC patch set to this mailing list. For me it was the reboot, not the poweroff scenario, but that should be interchangeable. You can look up the thread here: https://www.spinics.net/lists/linux-i2c/msg25401.html There are two distinct problems: * Sending I2C messages in an atomic/irqless/sleep-free context * Blocking the I2C-adapter for other users before starting the sequence poweroff/reboot. For the first item: I had to patch the I2C core driver to use polling(=irqless) instead of interrupts. For the last item: When the poweroff/restart handler code is executed, the SoC I2C core must not be in use by another driver in the system. There must be no other bus communication going on, because the code cannot wait anymore for sending final I2C message to poweroff the system. As Wolfram said, a good solution should implement something like 'master_xfer_irqless' and add a new flag I2C_M_IRQLESS, not accessing the `i2c_algorithm` of the I2C core driver directly as my code did. Kind Regards, Stefan -- 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
