From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Guennadi Liakhovetski <g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
Cc: "Charles D. Krebs"
<ckrebs-2y/nJPa2at/U1o9X0QyN+VaTQe2KTcn/@public.gmane.org>,
Linux Media Mailing List
<linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: soc_camera Client Driver with Multiple I2C Addresses
Date: Mon, 10 Jan 2011 15:31:38 +0100 [thread overview]
Message-ID: <20110110153138.7871b267@endymion.delvare> (raw)
In-Reply-To: <Pine.LNX.4.64.1012280810140.21647-0199iw4Nj15frtckUFj5Ag@public.gmane.org>
On Tue, 28 Dec 2010 08:55:41 +0100 (CET), Guennadi Liakhovetski wrote:
> Hi Charles
>
> (linux-i2c added to cc)
>
> On Mon, 27 Dec 2010, Charles D. Krebs wrote:
>
> > Guennadi,
> >
> > I'm developing a driver for a video receiver chip that has register
> > banks on multiple I2C addresses on the same bus. The data output is
> > parallel and I will be connecting it to the sh host interface.
> > Overall, the device appears to be suitable as a client driver to
> > soc_camera.
> >
> > I'm following the model for the MT9T112 driver, and this works just fine
> > for communicating to any one of the device's I2C addresses.
> >
> > How would you recommend registering more than one I2C address to an
> > soc_camera client driver?
>
> Honestly - don't know. The soc-camera model for now is pretty simple and
> in some senses restrictive. But in principle, it should be possible to
> code your case within its scope too. One of the possibilities would be to
> register your platform data with one "main" i2c unit / address, and then
> let the sensor register the rest in its probe. Is your chip configuration
> fixed? Always the same number of i2c units with the same addresses? Or can
> it vary? Maybe something like a multi-function device (drivers/mfd) would
> suit your purpose well?
>
> In fact, I think, it shouldn't be too complicated. As suggested above,
> provide (but don't register, just follow other soc-camera platforms) one
> main i2c device in the platform data, register the rest in your main
> probe(), which will call your further probe()s. The easiest would be to
> keep just one soc-camera instance and one v4l2-subdeice, but if you want,
> you can explore the possibility of creating several v4l2-subdevices.
If you simply need to handle a device which several I2C addresses, you
can consider one the main address, and register the secondary addresses
in your probe() function using i2c_new_dummy(). See
drivers/misc/eeprom/at24.c for an example of how this is done.
I'm not sure I understand the problem at hand exactly though, so my
advice might be inappropriate.
--
Jean Delvare
prev parent reply other threads:[~2011-01-10 14:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E58C9D0E73364C3EB14B6D0A0EBB5433@RSI50>
2010-12-28 7:55 ` soc_camera Client Driver with Multiple I2C Addresses Guennadi Liakhovetski
[not found] ` <Pine.LNX.4.64.1012280810140.21647-0199iw4Nj15frtckUFj5Ag@public.gmane.org>
2011-01-10 14:31 ` Jean Delvare [this message]
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=20110110153138.7871b267@endymion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=ckrebs-2y/nJPa2at/U1o9X0QyN+VaTQe2KTcn/@public.gmane.org \
--cc=g.liakhovetski-Mmb7MZpHnFY@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-media-u79uwXL29TY76Z2rM5mHXA@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).