All of lore.kernel.org
 help / color / mirror / Atom feed
From: mds4@verizon.net (Mark Studebaker)
To: Corey Minyard <minyard@acm.org>
Cc: Sensors <sensors@Stimpy.netroedge.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Adding an async I2C interface
Date: Thu, 19 May 2005 06:25:33 +0000	[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
> 
> 

WARNING: multiple messages have this Message-ID (diff)
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
> 
> 


  reply	other threads:[~2005-05-19  6:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-24 15:05 Adding an async I2C interface Corey Minyard
2005-05-19  6:25 ` Corey Minyard
2005-01-28  0:18 ` Mark Studebaker [this message]
2005-05-19  6:25   ` Mark Studebaker
2005-01-28  4:43   ` Corey Minyard
2005-05-19  6:25     ` Corey Minyard
2005-05-19  6:25 ` Bukie Mabayoje
2005-01-28  7:23   ` Bukie Mabayoje
2005-01-28 14:02   ` Corey Minyard
2005-05-19  6:25     ` Corey Minyard
2005-01-28 15:08   ` [PATCH] Add a non-blocking " Corey Minyard
2005-05-19  6:25     ` Corey Minyard
2005-01-28 15:11   ` [PATCH] Updates for the i801 driver to support the I2C non-blocking interface Corey Minyard
2005-05-19  6:25     ` [PATCH] Updates for the i801 driver to support the I2C non-blocking 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 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.