From: Stanimir Varbanov <svarbanov@mm-sol.com>
To: linux-media@vger.kernel.org
Cc: laurent.pinchart@ideasonboard.com, g.liakhovetski@gmx.de,
saaguirre@ti.com, Stanimir Varbanov <svarbanov@mm-sol.com>
Subject: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
Date: Tue, 22 Feb 2011 12:31:52 +0200 [thread overview]
Message-ID: <cover.1298368924.git.svarbanov@mm-sol.com> (raw)
This RFC patch adds a new subdev sensor operation named g_interface_parms.
It is planned as a not mandatory operation and it is driver's developer
decision to use it or not.
Please share your opinions and ideas.
---
It tries to create a common API for getting the sensor interface type
- serial or parallel, modes and interface clocks. The interface clocks
then are used in the host side to calculate it's configuration, check
that the clocks are not beyond host limitations etc.
"phy_rate" in serial interface (CSI DDR clk) is used to calculate
the CSI2 PHY receiver timing parameters: ths_settle, ths_term,
clk_settle and clk_term.
As the "phy_rate" depends on current sensor mode (configuration of the
sensor's PLL and internal clock domains) it can be treated as dynamic
parameter and can vary (could be different for viewfinder and still
capture), in this context g_interface_parms should be called after
s_fmt.
"pix_clk" for parallel interface reflects the current sensor pixel
clock. With this clock the image data is clocked out of the sensor.
"pix_clk" for serial interface reflects the current sensor pixel
clock at which image date is read from sensor matrix.
"lanes" for serial interface reflects the number of PHY lanes used from
the sensor to output image data. This should be known from the host
side before the streaming is started. For some sensor modes it's
enough to use one lane, for bigger resolutions two lanes and more
are used.
"channel" for serial interface is also needed from host side to
configure it's PHY receiver at particular virtual channel.
---
Some background and inspiration.
- Currently in the OMAP3 ISP driver we use a set of platform data
callbacks to provide the above parameters and this comes to very
complicated platform code, driver implementation and unneeded
sensor driver <-> host driver dependences.
- In the present time we seeing growing count of sensor drivers and
host (bridge) drivers but without standard API's for communication.
Currently the subdev sensor operations have only one operation -
g_skip_top_lines.
Stanimir Varbanov (1):
v4l: Introduce sensor operation for getting interface configuration
include/media/v4l2-subdev.h | 42 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
next reply other threads:[~2011-02-22 10:39 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 10:31 Stanimir Varbanov [this message]
2011-02-22 10:31 ` [RFC/PATCH 1/1] v4l: Introduce sensor operation for getting interface configuration Stanimir Varbanov
2011-02-22 11:40 ` [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms Guennadi Liakhovetski
2011-02-22 13:32 ` Hans Verkuil
2011-02-22 14:01 ` Aguirre, Sergio
2011-02-22 14:34 ` Guennadi Liakhovetski
2011-02-23 11:15 ` Laurent Pinchart
2011-02-22 14:11 ` Guennadi Liakhovetski
2011-02-22 15:17 ` Hans Verkuil
2011-02-22 15:30 ` Guennadi Liakhovetski
2011-02-22 15:34 ` Stan
2011-02-22 16:27 ` Guennadi Liakhovetski
2011-02-22 17:00 ` Hans Verkuil
2011-02-22 17:08 ` Guennadi Liakhovetski
2011-02-23 11:34 ` Laurent Pinchart
2011-02-22 21:42 ` Sylwester Nawrocki
2011-02-23 8:10 ` Hans Verkuil
2011-02-23 9:31 ` Guennadi Liakhovetski
2011-02-23 14:06 ` Aguirre, Sergio
2011-02-23 14:17 ` Hans Verkuil
2011-02-23 14:46 ` Guennadi Liakhovetski
2011-02-23 15:30 ` Laurent Pinchart
2011-02-23 15:52 ` Guennadi Liakhovetski
2011-02-23 16:02 ` Hans Verkuil
2011-02-23 16:14 ` Laurent Pinchart
2011-02-23 16:20 ` Aguirre, Sergio
2011-02-23 16:46 ` Guennadi Liakhovetski
2011-02-23 17:45 ` Aguirre, Sergio
2011-02-24 9:45 ` Stanimir Varbanov
2011-02-23 16:28 ` Hans Verkuil
2011-02-23 16:35 ` Laurent Pinchart
2011-02-23 16:37 ` Laurent Pinchart
2011-02-23 16:40 ` Guennadi Liakhovetski
2011-02-25 18:23 ` Sakari Ailus
2011-02-26 12:50 ` Hans Verkuil
2011-02-26 13:14 ` Guennadi Liakhovetski
2011-02-26 13:39 ` Hans Verkuil
2011-02-26 14:03 ` Sylwester Nawrocki
2011-02-26 14:45 ` Laurent Pinchart
2011-02-23 9:31 ` Hans Verkuil
2011-02-23 15:06 ` Aguirre, Sergio
2011-02-23 11:04 ` Laurent Pinchart
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=cover.1298368924.git.svarbanov@mm-sol.com \
--to=svarbanov@mm-sol.com \
--cc=g.liakhovetski@gmx.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=saaguirre@ti.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