From: Mark Studebaker <mds4@verizon.net>
To: Corey Minyard <minyard@acm.org>
Cc: Sensors <sensors@Stimpy.netroedge.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Adding an async I2C interface
Date: Thu, 27 Jan 2005 19:18:28 -0500 [thread overview]
Message-ID: <41F984D4.5030306@verizon.net> (raw)
In-Reply-To: <41F50E9D.3050702@acm.org>
is there a way to do this solely in i2c-core without having to
add support to all the drivers?
Corey Minyard wrote:
> I have an IPMI interface driver that sits on top of the I2C code. I'd
> like to get it into the mainstream kernel, but I have a few problems
> to solve first before I can do that. The I2C code is synchronous and
> must run from a task context. The IPMI driver has certain
> operations that occur at panic time, including:
>
> * Storing panic information in IPMI's system event log
> * Extending the watchdog timer so it doesn't go off during panic
> operations (like kernel coredumps).
> * Powering the system off
>
> I can't really put the IPMI SMB interface into the kernel until I can
> do those operations. Also, I understand that some vendors put RTC
> chips onto the I2C bus and this must be accessed outside task context,
> too. I would really like add asynchronous interface to the I2C bus
> drivers. I propose:
>
> * Adding an async send interface to the busses that does a callback
> when the operation is complete.
> * Adding a poll interface to the busses. The I2C core code could
> call this if a synchronous call is made from task context (much
> like all the current drivers do right now). For asyncronous
> operation, the I2C core code would call it from a timer
> interrupt. If the driver supported interrupts, polling from the
> timer interrupt would not be necessary.
> * Add async operations for the user to call, including access to the
> polling code.
> * If the driver didn't support an async send, it would work as it
> does today and the async calls would return ENOSYS.
>
> This way, the bus drivers on I2C could be converted on a
> driver-by-driver basis. The IPMI code could query to see if the
> driver supported async operations. And the RTC code could use it,
> too.
>
> Is this ok with the I2C community? I would do the base work and
> convert over a few drivers.
>
> Thanks,
>
> -Corey
>
>
next prev parent reply other threads:[~2005-01-28 0:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-24 15:05 Adding an async I2C interface Corey Minyard
2005-01-28 0:18 ` Mark Studebaker [this message]
2005-01-28 4:43 ` Corey Minyard
[not found] ` <41F9E183.5A9B1BA2@gte.net>
2005-01-28 7:23 ` Bukie Mabayoje
2005-01-28 14:02 ` Corey Minyard
2005-01-28 15:08 ` [PATCH] Add a non-blocking " Corey Minyard
2005-01-28 15:11 ` [PATCH] Updates for the i801 driver to support the I2C non-blocking interface Corey Minyard
-- strict thread matches above, loose matches on Subject: below --
2005-01-24 16:36 Adding an async I2C interface David Brownell
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=41F984D4.5030306@verizon.net \
--to=mds4@verizon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=minyard@acm.org \
--cc=sensors@Stimpy.netroedge.com \
/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