On 2/08/2018 03:26, Stefan Lengfeld wrote:
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.
This thread piqued my interest. I've got an ARM system that uses a gpio on an I2C chip
to power the system down. I've been using the gpio-poweroff driver to drive the line.
So far I haven't had any problems, but looking at the code I'm not sure how it's working now...
I guess this hw design would complicate things with regards get the gpio subsystem to do a
master_xfer_irqless to set the pin via the gpio subsystem
--
Regards
Phil Reid
--
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
