From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Tomasz Figa <tomasz.figa@gmail.com>,
Arun Kumar K <arun.kk@samsung.com>,
linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
devicetree@vger.kernel.org, swarren@wwwdotorg.org,
mark.rutland@arm.com, Pawel.Moll@arm.com, galak@codeaurora.org,
a.hajda@samsung.com, sachin.kamat@linaro.org,
shaik.ameer@samsung.com, kilyeon.im@samsung.com,
arunkk.samsung@gmail.com
Subject: Re: [PATCH v7 13/13] V4L: Add driver for s5k4e5 image sensor
Date: Wed, 21 Aug 2013 11:13:33 +0200 [thread overview]
Message-ID: <521484BD.1070005@samsung.com> (raw)
In-Reply-To: <201308211024.58303.hverkuil@xs4all.nl>
On 08/21/2013 10:24 AM, Hans Verkuil wrote:
>>>> +static const char * const s5k4e5_supply_names[] = {
>>>> + "svdda",
>>>> + "svddio"
>>>> +};
>>>
>>> I'm no regulator expert, but shouldn't this list come from the DT or
>>> platform_data? Or are these names specific to this sensor?
>>
>> This is a list of regulator input (aka supply) names. In other words those
>> are usually names of pins of the consumer device (s5k4e5 chip in this
>> case) to which the regulators are connected. They are used as lookup keys
>> when looking up regulators, either from device tree or lookup tables.
>
> How does that work if you have two of these sensors? E.g. in a stereo-camera?
> Can the regulator subsystem map those pins to the correct regulators?
>
> Again, sorry for my ignorance in this area as I've never used it. I just
> want to make sure this information is stored in the right place.
The _voltage regulator supply names_ are fixed but _voltage regulator_
is matched with a consumer device based on the supply name and name of
the consumer device. See usage of struct regulator_consumer_supply, e.g.
in arch/arm/mach-s5pv210/mach-goni.c board file. This is an example of
non-dt system, and something that would presumably be created by a driver
like em28xx if it wanted to use that sensor. I.e. em28xx would first
need to create a voltage regulator device and then pass in a
struct regulator_init_data the list of voltage supply definitions for
the consumers to be able to use this regulator.
In case of device tree the voltage supplies are specified in
a DT node, which can be referenced by subsystems/drivers through
struct device::of_node.
reg_a: voltage-regulator-a {
compatible = "regulator-fixed";
regulator-name = "REG_5V_A";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
gpio = <...>;
...
};
reg_b: voltage-regulator-b {
compatible = "regulator-fixed";
regulator-name = "REG_3.3V_B";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
gpio = <...>;
...
};
s5k4e5@20 {
compatible = "samsung,s5k4e5";
reg = <0x20>;
...
svdda-supply = <®_a>;
svddio-supply = <®_b>;
...
};
The regulator supply names are part of name of the property defining
a voltage regulator for a device. Properties in form of
[supply_name]-supply are parsed by the regulator core when consumer
device driver calls regulator_get(). This way drivers don't need to
care whether the system is booted from Device Tree or not. They just
keep using the regulator API and the regulator supply lookup is done
the the core based on data in a board file or in device tree blob.
This is similar to the clock API operation, except that clkdev entries
are usually defined per SOC/MCU rather than per board.
I hope it helps. I looked yesterday at the em28xx driver. Do you happen
to know if there is a schematic for one of devices this driver supports ?
Sorry, I didn't dig to hard yet.
At first sight I thought it may look a bit problematic and require
significant amount of code to define regulators for the all supported
sensors by this driver, should it be made to work with sensors that
are currently known to be used only in embedded systems and use the
regulators API. However it should be as simple as defining at least one
regulator device and attaching regulator supply list definition for all
supported sensors. Thus not that scary at all. And the subdev drivers
can continue to use regulator API, without a need for any hacks making
it optional through e.g. platform_data flag. And IMO if the regulator
API is disabled currently by some x86 distros it should be enabled,
as long as some drivers need it.
--
Regards,
Sylwester
next prev parent reply other threads:[~2013-08-21 9:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 6:34 [PATCH v7 00/13] Exynos5 IS driver Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 01/13] [media] exynos5-is: Adding media device driver for exynos5 Arun Kumar K
2013-09-05 19:44 ` Sylwester Nawrocki
[not found] ` <1377066881-5423-2-git-send-email-arun.kk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-09-16 21:53 ` Sylwester Nawrocki
2013-09-16 21:53 ` Sylwester Nawrocki
2013-09-17 11:29 ` Arun Kumar K
2013-09-17 20:50 ` Sylwester Nawrocki
[not found] ` <5238C090.6090201-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-09-18 11:48 ` Arun Kumar K
2013-09-18 11:48 ` Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation Arun Kumar K
2013-09-05 19:40 ` Sylwester Nawrocki
2013-08-21 6:34 ` [PATCH v7 03/13] [media] exynos5-fimc-is: Add driver core files Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 04/13] [media] exynos5-fimc-is: Add common driver header files Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 05/13] [media] exynos5-fimc-is: Add register definition and context header Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 06/13] [media] exynos5-fimc-is: Add isp subdev Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 07/13] [media] exynos5-fimc-is: Add scaler subdev Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 08/13] [media] exynos5-fimc-is: Add sensor interface Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 09/13] [media] exynos5-fimc-is: Add the hardware pipeline control Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 10/13] [media] exynos5-fimc-is: Add the hardware interface module Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 11/13] [media] exynos5-is: Add Kconfig and Makefile Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 12/13] V4L: s5k6a3: Change sensor min/max resolutions Arun Kumar K
2013-08-21 6:34 ` [PATCH v7 13/13] V4L: Add driver for s5k4e5 image sensor Arun Kumar K
2013-08-21 6:53 ` Hans Verkuil
2013-08-21 7:58 ` Tomasz Figa
2013-08-21 8:24 ` Hans Verkuil
2013-08-21 9:04 ` Arun Kumar K
2013-08-21 9:13 ` Sylwester Nawrocki [this message]
2013-08-21 9:28 ` Sylwester Nawrocki
2013-08-21 9:28 ` Sylwester Nawrocki
2013-09-05 20:02 ` Sylwester Nawrocki
2013-09-06 4:33 ` Arun Kumar K
2013-09-11 5:10 ` Arun Kumar K
2013-09-11 10:16 ` Sylwester Nawrocki
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=521484BD.1070005@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=Pawel.Moll@arm.com \
--cc=a.hajda@samsung.com \
--cc=arun.kk@samsung.com \
--cc=arunkk.samsung@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=hverkuil@xs4all.nl \
--cc=kilyeon.im@samsung.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=sachin.kamat@linaro.org \
--cc=shaik.ameer@samsung.com \
--cc=swarren@wwwdotorg.org \
--cc=tomasz.figa@gmail.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.