All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vaibhav Hiremath <vaibhav.hiremath-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Subject: Re: [RFC]: Supporting PIO mode of operation in i2c_msg->flags
Date: Fri, 12 Jun 2015 01:20:33 +0530	[thread overview]
Message-ID: <5579E689.5000503@linaro.org> (raw)
In-Reply-To: <55671E44.5000704-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>



On Thursday 28 May 2015 07:25 PM, Vaibhav Hiremath wrote:
>
>
> 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
>

Wolfram,

Any comment on this RFC?

Thanks,
Vaibhav

WARNING: multiple messages have this Message-ID (diff)
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: Fri, 12 Jun 2015 01:20:33 +0530	[thread overview]
Message-ID: <5579E689.5000503@linaro.org> (raw)
In-Reply-To: <55671E44.5000704@linaro.org>



On Thursday 28 May 2015 07:25 PM, Vaibhav Hiremath wrote:
>
>
> 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
>

Wolfram,

Any comment on this RFC?

Thanks,
Vaibhav

  parent reply	other threads:[~2015-06-11 19:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-25  9:47 [RFC]: Supporting PIO mode of operation in i2c_msg->flags Vaibhav Hiremath
     [not found] ` <5562EF9D.1090403-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-05-28 13:55   ` Vaibhav Hiremath
2015-05-28 13:55     ` Vaibhav Hiremath
     [not found]     ` <55671E44.5000704-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-11 19:50       ` Vaibhav Hiremath [this message]
2015-06-11 19:50         ` Vaibhav Hiremath
2015-06-11 23:41   ` Wolfram Sang
2015-06-14 12:12     ` Vaibhav Hiremath
     [not found]       ` <557D6FAF.1050408-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-16  8:56         ` Vaibhav Hiremath
     [not found]           ` <557FE4A9.5030004-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-16  9:18             ` Wolfram Sang
2015-06-16 12:11               ` 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=5579E689.5000503@linaro.org \
    --to=vaibhav.hiremath-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.