From: vaibhav.hiremath@linaro.org (Vaibhav Hiremath)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC]: Supporting PIO mode of operation in i2c_msg->flags
Date: Thu, 28 May 2015 19:25:16 +0530 [thread overview]
Message-ID: <55671E44.5000704@linaro.org> (raw)
In-Reply-To: <5562EF9D.1090403@linaro.org>
On Monday 25 May 2015 03:17 PM, Vaibhav Hiremath wrote:
>
> Hi,
>
> This is rather an old issue, for which I have also done custom & hacky
> solution in the past.
>
> Please let me know if there is already an some other method or accepted
> workaround to this issue. Also, let me know if you have any suggestions
> on this patch, I would be happy to work on it.
>
>
> Problem Statement:
> ------------------
> In certain embedded platforms, the board power on/off is managed by
> PMIC IC, which in most of the cases is over I2C bus.
> So during shutdown/reboot you may have to do I2C transactions to access
> PMIC, which may sleep if I2C bus driver is not functioning in PIO by
> default.
>
> This is unexpected, to sleep after you disable the interrupts.
>
> For example,
>
> During reboot/shutdown, the execution call reaches to,
>
> void machine_power_off(void)
> {
> local_irq_disable();
> smp_send_stop();
> if (pm_power_off)
> pm_power_off();
> }
>
> pm_power_off will try to do I2C transaction to access PMIC, which may
> sleep/schedule.
>
>
> Current implementation:
> --------------------
>
> Everyone probably does have their own custom implementation for this.
> Or some other mechanism to achieve this (may be hardware support).
>
>
> Proposal:
> ---------
>
> If I am not missing any other way of handling this situation,
> below proposal should be clean and acceptable (I hope so :) )
>
>
> Add flags to choose PIO mode, for I2C transactions, and the default
> would be to non-PIO mode.
>
>
> struct i2c_msg flags :
>
> #define I2C_M_PIO 0x0800
>
>
> And also add respective functionality flags
>
> #define I2C_FUNC_PIO 0x10000000 /* Driver should support PIO mode*/
>
>
> In the bus driver,
>
> Inside master_xfer() callback we will check whether the intended i2c
> transaction is meant to be processed in PIO mode, if yes, then we will
> call PIO api, else as usual non-pio api should serve.
>
>
> static int xxx_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int
> num)
> {
> ...
>
>
> /* We can also check i2c_check_functionality(adap,I2C_FUNC_PIO) */
> if (msg->flags & I2C_M_PIO) {
> /* PIO mode operation */
> } else {
> /* non-pio mode of operation */
> }
>
>
> ...
>
>
> return ret;
> }
>
>
> Feedback/comments are always welcome.
>
> Thanks,
> Vaibhav
Any comments on the RFC?
Also,
+ linux-arm & Wolfram Sang
Thanks,
Vaibhav
next parent reply other threads:[~2015-05-28 13:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5562EF9D.1090403@linaro.org>
2015-05-28 13:55 ` Vaibhav Hiremath [this message]
2015-06-11 19:50 ` [RFC]: Supporting PIO mode of operation in i2c_msg->flags Vaibhav Hiremath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55671E44.5000704@linaro.org \
--to=vaibhav.hiremath@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).