All of lore.kernel.org
 help / color / mirror / Atom feed
From: adrian@humboldt.co.uk (Adrian Cox)
To: Michael Hunold <hunold@linuxtv.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	sensors@Stimpy.netroedge.com, Jon Smirl <jonsmirl@gmail.com>,
	Greg KH <greg@kroah.com>
Subject: [PATCH][2.6] Add command function to struct i2c_adapter
Date: Thu, 19 May 2005 06:25:17 +0000	[thread overview]
Message-ID: <1095970724.1683.232.camel@localhost> (raw)
In-Reply-To: <41527696.5060002@linuxtv.org>

On Thu, 2004-09-23 at 08:09, Michael Hunold wrote:
> We need to keep in mind, that the adapter interface must be a per-client 
> interface. On PCI devices it's simple: you have a i2c bus bound to a dvb 
> card and know which chipsets can be there. The bus is dvb specific.
> 
> On embedded platforms, however, you usually have one one i2c bus, where 
> everything is present: dvb frontends, audio/video multiplexers, 
> digital/analog audio converters, stuff like that.
> 
> So if you create *the* i2c bus and invite i2c client to participate at 
> the party, you need to provide different interfaces to the different 
> chipsets.

I may have to solve a similar problem when connecting an image sensor
directly to an embedded processor. My current idea looks a bit like
this:

1) The I2C bus is a platform device, created at boot time, independent
of my video capture module.
2) My module contains a dummy I2C driver, which exists solely to grab an
i2c_adapter pointer for the platform I2C device.

My underlying libraries don't have to worry whether the i2c_adapter came
from a parent PCI device or a platform device. My only worry is that
power management may still provide us with a headache, as we'll have to
cope with platform devices being suspended in any order.

- Adrian Cox
Humboldt Solutions Ltd.


WARNING: multiple messages have this Message-ID (diff)
From: Adrian Cox <adrian@humboldt.co.uk>
To: Michael Hunold <hunold@linuxtv.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	sensors@Stimpy.netroedge.com, Jon Smirl <jonsmirl@gmail.com>,
	Greg KH <greg@kroah.com>
Subject: Re: [PATCH][2.6] Add command function to struct i2c_adapter
Date: Thu, 23 Sep 2004 21:18:45 +0100	[thread overview]
Message-ID: <1095970724.1683.232.camel@localhost> (raw)
In-Reply-To: <41527696.5060002@linuxtv.org>

On Thu, 2004-09-23 at 08:09, Michael Hunold wrote:
> We need to keep in mind, that the adapter interface must be a per-client 
> interface. On PCI devices it's simple: you have a i2c bus bound to a dvb 
> card and know which chipsets can be there. The bus is dvb specific.
> 
> On embedded platforms, however, you usually have one one i2c bus, where 
> everything is present: dvb frontends, audio/video multiplexers, 
> digital/analog audio converters, stuff like that.
> 
> So if you create *the* i2c bus and invite i2c client to participate at 
> the party, you need to provide different interfaces to the different 
> chipsets.

I may have to solve a similar problem when connecting an image sensor
directly to an embedded processor. My current idea looks a bit like
this:

1) The I2C bus is a platform device, created at boot time, independent
of my video capture module.
2) My module contains a dummy I2C driver, which exists solely to grab an
i2c_adapter pointer for the platform I2C device.

My underlying libraries don't have to worry whether the i2c_adapter came
from a parent PCI device or a platform device. My only worry is that
power management may still provide us with a headache, as we'll have to
cope with platform devices being suspended in any order.

- Adrian Cox
Humboldt Solutions Ltd.



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

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-20 17:19 [PATCH][2.6] Add command function to struct i2c_adapter Michael Hunold
2004-09-21 15:41 ` Greg KH
2005-05-19  6:25   ` Greg KH
2004-09-21 17:10   ` Michael Hunold
2005-05-19  6:25     ` Michael Hunold
2004-09-21 17:39     ` Jon Smirl
2005-05-19  6:25       ` Jon Smirl
2004-09-21 18:05       ` Michael Hunold
2005-05-19  6:25         ` Michael Hunold
2004-09-22  8:56         ` Adrian Cox
2005-05-19  6:25           ` Adrian Cox
2004-09-22 12:08           ` Jean Delvare
2005-05-19  6:25             ` Jean Delvare
2004-09-22 11:54             ` Adrian Cox
2005-05-19  6:25               ` Adrian Cox
2004-09-22 13:38               ` Jean Delvare
2005-05-19  6:25                 ` Jean Delvare
2004-09-22 13:13                 ` Adrian Cox
2005-05-19  6:25                   ` Adrian Cox
2004-09-22 15:40                 ` Jon Smirl
2005-05-19  6:25                   ` Jon Smirl
2004-09-22 15:56                   ` Adrian Cox
2005-05-19  6:25                     ` Adrian Cox
2004-09-22 16:07                     ` Jon Smirl
2005-05-19  6:25                       ` Jon Smirl
2004-09-22 16:51                       ` Adrian Cox
2005-05-19  6:25                         ` Adrian Cox
2004-09-22 17:17                         ` Jon Smirl
2005-05-19  6:25                           ` Jon Smirl
2004-09-22 18:55                         ` Jean Delvare
2005-05-19  6:25                           ` Jean Delvare
2004-09-22 18:32                 ` Adrian Cox
2005-05-19  6:25                   ` Adrian Cox
2004-09-22 20:04                   ` Mark M. Hoffman
2005-05-19  6:25                     ` Mark M. Hoffman
2004-09-23  7:41                   ` Michael Hunold
2005-05-19  6:25                     ` Michael Hunold
2004-09-23  7:48                   ` Michael Hunold
2005-05-19  6:25                     ` Michael Hunold
2004-09-23  7:09               ` Michael Hunold
2005-05-19  6:25                 ` Michael Hunold
2004-09-23 20:18                 ` Adrian Cox [this message]
2005-05-19  6:25                   ` Adrian Cox
2004-09-21 20:33       ` Jean Delvare
2005-05-19  6:25         ` Jean Delvare
2004-09-21 21:02         ` Jon Smirl
2005-05-19  6:25           ` Jon Smirl
2004-09-24 17:06   ` Michael Hunold
2005-05-19  6:25     ` Michael Hunold
2004-09-24 18:05     ` Jean Delvare
2005-05-19  6:25       ` Jean Delvare
2004-09-24 20:21       ` Michael Hunold
2005-05-19  6:25         ` Michael Hunold
2004-10-01  6:52         ` Greg KH
2005-05-19  6:25           ` Greg KH
2004-10-01 12:22           ` Adrian Cox
2005-05-19  6:25             ` Adrian Cox
2004-10-01 13:57             ` Jean Delvare
2005-05-19  6:25               ` Jean Delvare
2004-10-01 23:41             ` Greg KH
2005-05-19  6:25               ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2005-05-19  6:25 [Fwd: [PATCH][2.6] Add command function to struct i2c_adapter] Michael Hunold
2004-09-21 13:28 ` [PATCH][2.6] Add command function to struct i2c_adapter Jean Delvare
2005-05-19  6:25   ` Jean Delvare
2004-09-21 14:38   ` Michael Hunold
2005-05-19  6:25     ` Michael Hunold

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=1095970724.1683.232.camel@localhost \
    --to=adrian@humboldt.co.uk \
    --cc=greg@kroah.com \
    --cc=hunold@linuxtv.org \
    --cc=jonsmirl@gmail.com \
    --cc=linux-kernel@vger.kernel.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.