linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Mark Brown <broonie@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	linux-media@vger.kernel.org,
	Mike Turquette <mturquette@linaro.org>
Subject: Re: [GIT PULL FOR v3.10] Camera sensors patches
Date: Mon, 22 Apr 2013 09:46:48 -0300	[thread overview]
Message-ID: <51753138.1080106@redhat.com> (raw)
In-Reply-To: <20130422100320.GC30351@opensource.wolfsonmicro.com>

Em 22-04-2013 07:03, Mark Brown escreveu:
> On Mon, Apr 22, 2013 at 01:14:07AM +0200, Laurent Pinchart wrote:
>
>> I think that Mark's point was that the regulators should be provided by
>> platform code (in the generic sense, it could be DT on ARM, board code, or a
>> USB bridge driver for a webcam that uses the mt9p031 sensor) and used by the
>> sensor driver. That's exactly what my mt9p031 patch does.
>
> Yes, you understood me perfectly - to a good approximation the matching
> up should be done by whatever the chip is soldered down to.
>

That doesn't make any sense to me. I2C devices can be used anywere,
as they can be soldered either internally on an USB webcam without
any regulators or any other platform code on it or could be soldered
to some platform-specific bus.

Also, what best describes "soldered" here is the binding between
an I2C driver and the I2C adapter. The I2C adapter is a platform
driver on embedded devices, where, on an usual USB camera, it
is just a USB->I2C bridge.

Also, requiring that simple USB cameras to have regulators will
prevent its usual usage, as non-platform distros don't set config
REGULATOR (and they shouldn't, as that would just increase the
Kernel's footprint for a code that will never ever be needed there).

Regards,
Mauro

      parent reply	other threads:[~2013-04-22 12:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-12  9:13 [GIT PULL FOR v3.10] Camera sensors patches Laurent Pinchart
2013-04-14 19:59 ` Mauro Carvalho Chehab
2013-04-15 10:19   ` Laurent Pinchart
2013-04-15 12:42     ` Mauro Carvalho Chehab
2013-04-16 15:30       ` Laurent Pinchart
2013-04-16 17:36         ` Mauro Carvalho Chehab
2013-04-16 18:04           ` Sylwester Nawrocki
2013-04-17 13:55             ` Mark Brown
2013-04-17 14:36               ` Mauro Carvalho Chehab
2013-04-21 23:14                 ` Laurent Pinchart
2013-04-22 10:03                   ` Mark Brown
2013-04-22 12:46                     ` Mauro Carvalho Chehab
2013-04-22 12:56                       ` Mark Brown
2013-04-22 12:46                     ` Mauro Carvalho Chehab [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=51753138.1080106@redhat.com \
    --to=mchehab@redhat.com \
    --cc=broonie@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=s.nawrocki@samsung.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;
as well as URLs for NNTP newsgroup(s).