From: Vaibhav Hiremath <vaibhav.hiremath-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC]: Supporting PIO mode of operation in i2c_msg->flags
Date: Sun, 14 Jun 2015 17:42:31 +0530 [thread overview]
Message-ID: <557D6FAF.1050408@linaro.org> (raw)
In-Reply-To: <20150611234118.GA1534@katana>
On Friday 12 June 2015 05:11 AM, Wolfram Sang wrote:
>> Current implementation:
>> --------------------
>>
>> Everyone probably does have their own custom implementation for this.
>> Or some other mechanism to achieve this (may be hardware support).
>
> Do you have examples? It is easier to look at code.
>
As I mentioned in the "Problem Statement",
I2C interface for PMIC may need to be used at the end of poweroff
sequence where you cannot afford to sleep/schedule, as interrupt has
been disabled.
Earlier I was working on OMAP platform, where I remember we had
implemented something for such requirement, but as I am not in TI
anymore, I can not access the internal code.
Let me check whether I can share the current marvell codebase
outside.
>> /* 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 */
>> }
>
> I'd rather let the core decide. Like introduce a master_xfer_nosleep
> callback and let the core use the standard or the nosleep one. We'd need
> the same for smbus as well.
>
> This leads to the question if we need a M_FLAG or expose the *_nosleep
> functions directly?
>
I thought of it, but did not convince myself after looking at the usage
of this. This function would be used only when interrupt is disabled.
> And I wonder about the demand for it. There are a number of SoCs with
> designated I2C cores for the PMIC which do automated transfers.
>
This is exactly the same reason I did not propose it as a core change.
as I feel that the use of this is very minimal and with M_FLAG driver
can very well handle it.
Thanks,
Vaibhav
next prev parent reply other threads:[~2015-06-14 12:12 UTC|newest]
Thread overview: 8+ 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
[not found] ` <55671E44.5000704-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-11 19:50 ` Vaibhav Hiremath
2015-06-11 23:41 ` Wolfram Sang
2015-06-14 12:12 ` Vaibhav Hiremath [this message]
[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=557D6FAF.1050408@linaro.org \
--to=vaibhav.hiremath-qsej5fyqhm4dnm+yrofe0a@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 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).