Re: v4l-utils-0.8.3 and KVDR
KVDR has a number of different parameters including -xforce xv-mode on startup and disable overlay-mod -ddont switch modeline during xv with kernel 2.6.35 I run KVDR with -x as I have an NVIDIA graphics. Running on 2.6.38 KVDR -x doesn't produce any log. The display appears and immediately disappears although there is a process running. With KVDR -d I get a display window but no picture but the attached log is produced. I hope this helps Mike libv4l2: open: 4 request == VIDIOC_G_FMT pixelformat: BGR3 384x288 field: 0 bytesperline: 0 imagesize331776 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 0, description: RGB-8 (3-3-2) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB1 48x32 field: 3 bytesperline: 48 imagesize1536 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB1 768x288 field: 3 bytesperline: 768 imagesize221184 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 1, description: RGB-16 (5/B-6/G-5/R) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGBP 48x32 field: 3 bytesperline: 768 imagesize24576 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGBP 768x288 field: 3 bytesperline: 1536 imagesize442368 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 2, description: RGB-24 (B-G-R) result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR3 48x32 field: 3 bytesperline: 1536 imagesize49152 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR3 768x288 field: 3 bytesperline: 2304 imagesize663552 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 3, description: RGB-32 (B-G-R) result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR4 48x32 field: 3 bytesperline: 2304 imagesize73728 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR4 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 4, description: RGB-32 (R-G-B) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB4 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB4 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 5, description: Greyscale-8 result == 0 request == VIDIOC_TRY_FMT pixelformat: GREY 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: GREY 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 6, description: YUV 4:2:2 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: 422P 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: 422P 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 7, description: YVU 4:2:0 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: YV12 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: YV12 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 8, description: YUV 4:2:0 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: YU12 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: YU12 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 9, description: YUV 4:2:2 (U-Y-V-Y) result == 0 request == VIDIOC_TRY_FMT pixelformat: UYVY 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: UYVY 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 10, description: RGB3 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB3 48x32 field: 3 bytesperline: 144 imagesize4608 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB3 768x288 field: 3 bytesperline: 2304 imagesize663552 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 11, description: result == -1 (Invalid argument) request == VIDIOC_ENUMINPUT result == 0 request == VIDIOC_ENUMSTD result == 0 libv4l1: open: 4 request == VIDIOC_QUERYCAP result == 0 request == VIDIOC_G_FBUF result == 0 request == VIDIOC_S_FBUF result == 0 libv4l2: close: 4 libv4l1: close: 4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More
[PATCH 0/3] soc_camera_platform: dynamically manage device instances
This patch series switches soc_camera_platform users to manage their camera device instances dynamically instead of re-using static objects. Since I don't have any of affected platforms at hand, this is only compile-tested. Please, test! Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 1/1] v4l: Introduce sensor operation for getting interface configuration
Introduce g_interface_parms sensor operation for getting sensor
interface parameters. These parameters are needed from the host side
to determine it's own configuration.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
---
include/media/v4l2-subdev.h | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b0316a7..4186cad 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -322,15 +322,57 @@ struct v4l2_subdev_vbi_ops {
int (*s_sliced_fmt)(struct v4l2_subdev *sd, struct
v4l2_sliced_vbi_format *fmt);
};
+/* Which interface the sensor use to provide it's image data */
+enum v4l2_subdev_sensor_iface {
+ V4L2_SUBDEV_SENSOR_PARALLEL,
+ V4L2_SUBDEV_SENSOR_SERIAL,
+};
+
+/* Each interface could use the following modes */
+/* Image sensor provides horizontal and vertical sync signals */
+#define V4L2_SUBDEV_SENSOR_MODE_PARALLEL_SYNC 0
+/* BT.656 interface. Embedded sync */
+#define V4L2_SUBDEV_SENSOR_MODE_PARALLEL_ITU 1
+/* MIPI CSI1 */
+#define V4L2_SUBDEV_SENSOR_MODE_SERIAL_CSI12
+/* MIPI CSI2 */
+#define V4L2_SUBDEV_SENSOR_MODE_SERIAL_CSI23
+
+struct v4l2_subdev_sensor_serial_parms {
+ unsigned char lanes;/* number of lanes used */
+ unsigned char channel; /* virtual channel */
+ unsigned int phy_rate; /* output rate at CSI phy in bps */
+ unsigned int pix_clk; /* pixel clock in Hz */
+};
+
+struct v4l2_subdev_sensor_parallel_parms {
+ unsigned int pix_clk; /* pixel clock in Hz */
+};
+
+struct v4l2_subdev_sensor_interface_parms {
+ enum v4l2_subdev_sensor_iface if_type;
+ unsigned int if_mode;
+ union {
+ struct v4l2_subdev_sensor_serial_parms serial;
+ struct v4l2_subdev_sensor_parallel_parms parallel;
+ } parms;
+};
+
/**
* struct v4l2_subdev_sensor_ops - v4l2-subdev sensor operations
* @g_skip_top_lines: number of lines at the top of the image to be skipped.
* This is needed for some sensors, which always corrupt
* several top lines of the output image, or which send their
* metadata in them.
+ * @g_interface_parms: get sensor interface parameters. The sensor subdev
should
+ *fill this structure with current interface params. These
+ *interface parameters are needed on host side to configure
+ *it's own hardware receivers.
*/
struct v4l2_subdev_sensor_ops {
int (*g_skip_top_lines)(struct v4l2_subdev *sd, u32 *lines);
+ int (*g_interface_parms)(struct v4l2_subdev *sd,
+ struct v4l2_subdev_sensor_interface_parms *parms);
};
/*
--
1.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Some fixes for tuner, tvp5150 and em28xx
Em 22-02-2011 04:53, Hans Verkuil escreveu:
On Tuesday, February 22, 2011 03:52:11 Mauro Carvalho Chehab wrote:
Em 21-02-2011 23:17, Mauro Carvalho Chehab escreveu:
This series contain a minor cleanup for tuner and tvp5150, and two fixes
for em28xx controls. Before the em28xx patches, s_ctrl were failing on
qv4l2, because it were returning a positive value of 1 for some calls.
It also contains a fix for control get/set, as it will now check if the
control exists before actually calling subdev for get/set.
Mauro Carvalho Chehab (4):
...
[media] em28xx: Fix return value for s_ctrl
[media] em28xx: properly handle subdev controls
Hans,
I discovered the issue with em28xx that I commented you on IRC.
There were, in fact, 3 issues.
One is clearly a driver problem, corrected by em28xx: properly
handle subdev controls.
The second one being partially qv4l2 and partially driver issue,
fixed by em28xx: Fix return value for s_ctrl. Basically, V4L2
API and ioctl man page says that an error is indicated by -1 value,
being 0 or positive value a non-error. Well, qv4l2 understands a
positive value as -EBUSY. The driver were returning a non-standard
value of 1 for s_ctrl. I fixed the driver part.
The last issue is with v4l2-ctl and qv4l2. Also, the latest version
of xawtv had the same issue, probably due to some changes I did at
console/v4l-info.c.
What happens is that em28xx doesn't implement the control BASE+4,
due to one simple reason: it is not currently defined. The ctrl
loop were understanding the -EINVAL return of BASE+4 as the end of
the user controls. So, on xawtv, only the 3 image controls were
returned. I didn't dig into v4l2-ctl, but there, it doesn't show
the first 3 controls. It shows only the audio controls:
volume (int) : min=0 max=65535 step=655
default=58880 value=58880 flags=slider
balance (int) : min=0 max=65535 step=655
default=32768 value=32768 flags=slider
bass (int) : min=0 max=65535 step=655
default=32768 value=32768 flags=slider
treble (int) : min=0 max=65535 step=655
default=32768 value=32768 flags=slider
mute (bool) : default=0 value=0
loudness (bool) : default=0 value=0
The xawtv fix is at:
http://git.linuxtv.org/xawtv3.git?a=commitdiff;h=fda070af9cfd75b360db1339bde3c6d3c64ed627
A similar fix is needed for v4l2-ctl and qv4l2.
Actually, v4l2-ctrl and qv4l2 handle 'holes' correctly. I think this is a
different bug relating to the handling of V4L2_CTRL_FLAG_NEXT_CTRL. Can you
try this patch:
diff --git a/drivers/media/video/v4l2-ctrls.c
b/drivers/media/video/v4l2-ctrls.c
index ef66d2a..15eda86 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1364,6 +1364,8 @@ EXPORT_SYMBOL(v4l2_queryctrl);
int v4l2_subdev_queryctrl(struct v4l2_subdev *sd, struct v4l2_queryctrl *qc)
{
+ if (qc-id V4L2_CTRL_FLAG_NEXT_CTRL)
+ return -EINVAL;
return v4l2_queryctrl(sd-ctrl_handler, qc);
}
EXPORT_SYMBOL(v4l2_subdev_queryctrl);
v4l2-ctl and qv4l2 enumerate the controls using this flag, falling back to the
old method if the flag isn't supported. The v4l2_subdev_queryctrl function
will
currently handle that flag, but for the controls of the subdev only. This
isn't
right, it should refuse this flag. Without this fix v4l2-ctl will only see the
controls of the first subdev, which is exactly what you got. I never saw this
bug because the HVR900 has just a single subdev.
Ok, that makes sense. I'll test the patch and give you a feedback.
I also suspect that s_ctrl is wrong: can you test setting a video control? I
think that v4l2_device_call_until_err will always return an error. I'm not
sure
if there is an easy fix for this other than converting em28xx to the control
framework. I need to think about this.
I've changed it by two subdev calls. The first one queries for the control. If
control
type is zero, it returns an error, otherwise, it will call v4l2_device_all_all
(see
patch 4/4). This is sub-optimal, but should fix the bug, and can be sent to
-stable.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
On Tue, 22 Feb 2011, Stanimir Varbanov wrote: 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. Yes, I like the idea in principle (/me pulling his bullet-proof vest on), as some of you might guess, because I feel it's going away from the idea, that I've been hard pressed to accept of hard-coding the media-bus configuration and in the direction of direct communication of bus-parameters between the (sub-)devices, e.g., a camera host and a camera device in soc-camera terminology. But before reviewing the patch as such, I'd like to discuss the strategy, that we want to pursue here - what exactly do we want to hard-code and what we want to configure dynamically? As explained before, my preference would be to only specify the absolute minimum in the platform data, i.e., parameters that either are ambiguous or special for this platform. So, once again, my approach to configure interface parameters like signal polarities and edge sensitivity is: 1. if at least one side has a fixed value of the specific parameter, usually no need to specify it in platform data. Example: sensor only supports HSYNC active high, host supports both, normally high should be selected. 2. as above, but there's an inverter on the board in the signal path. The invert parameter must be specified in the platform data and the host will configure itself to low and send high confirmed to the sensor. 3. both are configurable. In this case the platform data has to specify, which polarity shall be used. This is simple, it is implemented, it has worked that way with no problem for several years now. The configuration procedure in this case looks like: 1. host requests supported interface configurations from the client (sensor) 2. host matches returned parameters against platform data and its own capabilities 3. if no suitable configuration possible - error out 4. the single possible configuration is identified and sent to the sensor back for its configuration This way we need one more method: s_interface_parms. Shortly talking to Laurent earlier today privately, he mentioned, that one of the reasons for this move is to support dynamic bus reconfiguration, e.g., the number of used CSI lanes. The same is useful for parallel interfaces. E.g., I had to hack the omap3spi driver to capture only 8 (parallel) data lanes from the sensor, connected with all its 10 lanes to get a format, easily supported by user-space applications. Ideally you don't want to change anything in the code for this. If the user is requesting the 10-bit format, all 10 lanes are used, if only 8 - the interface is reconfigured accordingly. Thanks Guennadi --- 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(-) --- Guennadi Liakhovetski,
Re: [PATCH 0/4] Some fixes for tuner, tvp5150 and em28xx
Em 22-02-2011 04:53, Hans Verkuil escreveu:
Actually, v4l2-ctrl and qv4l2 handle 'holes' correctly. I think this is a
different bug relating to the handling of V4L2_CTRL_FLAG_NEXT_CTRL. Can you
try this patch:
diff --git a/drivers/media/video/v4l2-ctrls.c
b/drivers/media/video/v4l2-ctrls.c
index ef66d2a..15eda86 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1364,6 +1364,8 @@ EXPORT_SYMBOL(v4l2_queryctrl);
int v4l2_subdev_queryctrl(struct v4l2_subdev *sd, struct v4l2_queryctrl *qc)
{
+ if (qc-id V4L2_CTRL_FLAG_NEXT_CTRL)
+ return -EINVAL;
return v4l2_queryctrl(sd-ctrl_handler, qc);
Ok, this fixed the issue:
brightness (int) : min=0 max=255 step=1 default=128
value=128
contrast (int) : min=0 max=255 step=1 default=128
value=128
saturation (int) : min=0 max=255 step=1 default=128
value=128
hue (int) : min=-128 max=127 step=1 default=0
value=0
volume (int) : min=0 max=65535 step=655 default=58880
value=65500 flags=slider
balance (int) : min=0 max=65535 step=655 default=32768
value=32750 flags=slider
bass (int) : min=0 max=65535 step=655 default=32768
value=32750 flags=slider
treble (int) : min=0 max=65535 step=655 default=32768
value=32750 flags=slider
mute (bool) : default=0 value=0
loudness (bool) : default=0 value=0
Also, v4l2-compliance is now complaining less about it.
Control ioctls:
fail: does not support V4L2_CTRL_FLAG_NEXT_CTRL
test VIDIOC_QUERYCTRL/MENU: FAIL
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: Not Supported
Standard Controls: 0 Private Controls: 0
(yet, it is showing standard controls = 0).
Could you provide your SOB to the above patch?
Thanks!
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Some fixes for tuner, tvp5150 and em28xx
On Tuesday, February 22, 2011 13:12:32 Mauro Carvalho Chehab wrote:
Em 22-02-2011 04:53, Hans Verkuil escreveu:
Actually, v4l2-ctrl and qv4l2 handle 'holes' correctly. I think this is a
different bug relating to the handling of V4L2_CTRL_FLAG_NEXT_CTRL. Can
you
try this patch:
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-
ctrls.c
index ef66d2a..15eda86 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1364,6 +1364,8 @@ EXPORT_SYMBOL(v4l2_queryctrl);
int v4l2_subdev_queryctrl(struct v4l2_subdev *sd, struct v4l2_queryctrl
*qc)
{
+ if (qc-id V4L2_CTRL_FLAG_NEXT_CTRL)
+ return -EINVAL;
return v4l2_queryctrl(sd-ctrl_handler, qc);
Ok, this fixed the issue:
brightness (int) : min=0 max=255 step=1 default=128
value=128
contrast (int) : min=0 max=255 step=1 default=128
value=128
saturation (int) : min=0 max=255 step=1 default=128
value=128
hue (int) : min=-128 max=127 step=1 default=0
value=0
volume (int) : min=0 max=65535 step=655
default=58880 value=65500 flags=slider
balance (int) : min=0 max=65535 step=655
default=32768 value=32750 flags=slider
bass (int) : min=0 max=65535 step=655
default=32768 value=32750 flags=slider
treble (int) : min=0 max=65535 step=655
default=32768 value=32750 flags=slider
mute (bool) : default=0 value=0
loudness (bool) : default=0 value=0
Also, v4l2-compliance is now complaining less about it.
Control ioctls:
fail: does not support V4L2_CTRL_FLAG_NEXT_CTRL
test VIDIOC_QUERYCTRL/MENU: FAIL
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: Not Supported
Standard Controls: 0 Private Controls: 0
(yet, it is showing standard controls = 0).
Could you provide your SOB to the above patch?
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Thanks!
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
On Tue, Feb 15, 2011 at 4:23 PM, Dennis Kurten dennis.kur...@gmail.com wrote: Hello Andy, I've tried some of your suggestions, but no luck so far. On Tue, Feb 15, 2011 at 4:09 AM, Andy Walls awa...@md.metrocast.net wrote: On Mon, 2011-02-14 at 13:35 +0200, Dennis Kurten wrote: Hello, This card (technisat cablestar hd 2 dvb-c) works fine when plugged into a native PCI slot. When I try it with a PCI-adapter I intend to use in mITX-builds there doesn't seem to be any data coming in through the tuner. The adapter is a transparent bridge (with a PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a 4-pin molex. [...] Kernel is 2.6.32 (+the compiled drivers) I have upgraded my system to 2.6.35 so now I'm using vanilla drivers but the problem remains: Works fine in PCI - doesn't in PCIE behind adapter. [...] Latency: 32 (2000ns min, 63750ns max) Interrupt: pin A routed to IRQ 16 Region 0: Memory at fdcff000 (32-bit, prefetchable) [size=4K] Heh, I always find it curious when I/O peripherials claim their register space is prefetchable (the CX23416 does this as well). If the chip is designed right, it is valid though AFAICT. And is there any point with prefetchable mechanisms if bus mastering is employed? This is what the adapter reports: I/O behind bridge: e000-efff Memory behind bridge: fdd0-fddf Prefetchable memory behind bridge: fdc0-fdcf I'd have thought that the memory behind the bridge would include any prefetchable segment. The tuner card happens to registers within that 0xfdc-segment too. [...] from /cat/interrupts: --- 16: 9751 0 IO-APIC-fasteoi ahci, nvidia, Mantis [...] The above shared interrupt assignment is the same for both cases. There is however a difference how the interrupt link is set up: Mantis :05:06.0: PCI INT A - Link[APC1] ... (-- without bridge) vs. Mantis :04:00.0: PCI INT A - Link[APC7] ... (-- with bridge) Don't know if the different APC# is of any significance here. Regards, Dennis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ISP lane shifter support
Hans, can you weigh in on this? I'm waiting to submit a patch to implement lane shifter support until I get a consensus what the best approach is. Laurent and Sakari favor having a different format on the sensor output than on the CCDC input to indicate a shift. If you agree that this is a sensible approach, I will go ahead and submit my patch soon. thanks, Michael On 02/11/2011 02:06 PM, Laurent Pinchart wrote: Hi Michael, On Friday 11 February 2011 13:07:33 Michael Jones wrote: On 01/27/2011 12:46 AM, Guennadi Liakhovetski wrote: Looking at the Data-Lane Shifter table (12.27 in my datasheet, in the Bridge-Lane Shifter chapter), I think, the first two columns are fixed by the board design, right? So, our freedom lies only in one line there and is a single parameter - the shift value. The output shifter (VPIN) is independent from this one, but not unrelated. It seems logical to me to relate the former one to CCDC's input pad, and the latter one to CCDC's output pad. AFAIU, Laurent, your implementation in what concerns pad configuration is: let the user configure all interfaces independently, and first when we have to actually activate the pipeline (start streaming or configure video buffers) we can verify, whether all parts fit together. I would like to add this lane shifter support. Would you like me to implement it as Guennadi suggested- letting the user set all 3 CCDC pad formats arbitrarily and postpone the consistency checks to streamon time? I've discussed this with Sakari Ailus, and we would implement it with different formats on the sensor output and the CCDC input. I'd like to get Hans Verkuil's opinion. MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
On Tuesday, February 22, 2011 12:40:32 Guennadi Liakhovetski wrote: On Tue, 22 Feb 2011, Stanimir Varbanov wrote: 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. Stanimir, thanks for the RFC. I think it is time that we create a good solution for this. This is currently the last remaining issue preventing soc- camera subdevs from being used generally. (Control handling is also still special, but this is being worked on.) Yes, I like the idea in principle (/me pulling his bullet-proof vest on), :-) as some of you might guess, because I feel it's going away from the idea, that I've been hard pressed to accept of hard-coding the media-bus configuration and in the direction of direct communication of bus-parameters between the (sub-)devices, e.g., a camera host and a camera device in soc-camera terminology. But before reviewing the patch as such, I'd like to discuss the strategy, that we want to pursue here - what exactly do we want to hard-code and what we want to configure dynamically? As explained before, my preference would be to only specify the absolute minimum in the platform data, i.e., parameters that either are ambiguous or special for this platform. So, once again, my approach to configure interface parameters like signal polarities and edge sensitivity is: 1. if at least one side has a fixed value of the specific parameter, usually no need to specify it in platform data. Example: sensor only supports HSYNC active high, host supports both, normally high should be selected. 2. as above, but there's an inverter on the board in the signal path. The invert parameter must be specified in the platform data and the host will configure itself to low and send high confirmed to the sensor. 3. both are configurable. In this case the platform data has to specify, which polarity shall be used. This is simple, it is implemented, it has worked that way with no problem for several years now. The configuration procedure in this case looks like: 1. host requests supported interface configurations from the client (sensor) 2. host matches returned parameters against platform data and its own capabilities 3. if no suitable configuration possible - error out 4. the single possible configuration is identified and sent to the sensor back for its configuration This way we need one more method: s_interface_parms. Shortly talking to Laurent earlier today privately, he mentioned, that one of the reasons for this move is to support dynamic bus reconfiguration, e.g., the number of used CSI lanes. The same is useful for parallel interfaces. E.g., I had to hack the omap3spi driver to capture only 8 (parallel) data lanes from the sensor, connected with all its 10 lanes to get a format, easily supported by user-space applications. Ideally you don't want to change anything in the code for this. If the user is requesting the 10-bit format, all 10 lanes are used, if only 8 - the interface is reconfigured accordingly. I have no problems with dynamic bus reconfiguration as such. So if the host driver wants to do lane reconfiguration, then that's fine by me. When it comes to signal integrity (polarity, rising/falling edge), then I remain convinced that this should be set via platform data. This is not something that should be negotiated since this depends not only on the sensor and host devices, but also on the routing of the lines between them on the actual board, how much noise there is on those lines, the quality of the clock signal, etc. Not really an issue with PAL/NTSC type signals, but when you get to 1080p60 and up, then such things become much more important. So these settings should not be negotiated, but set explicitly. It actually doesn't have to be done through platform data (although that makes the most sense), as long as it is explicitly set based on board-specific data. Regards, Hans Thanks Guennadi --- 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
RE: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
Hi, -Original Message- From: Hans Verkuil [mailto:hansv...@cisco.com] Sent: Tuesday, February 22, 2011 7:33 AM To: Guennadi Liakhovetski Cc: Stanimir Varbanov; linux-media@vger.kernel.org; laurent.pinch...@ideasonboard.com; Aguirre, Sergio Subject: Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms On Tuesday, February 22, 2011 12:40:32 Guennadi Liakhovetski wrote: On Tue, 22 Feb 2011, Stanimir Varbanov wrote: 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. Stanimir, thanks for the RFC. I think it is time that we create a good solution for this. This is currently the last remaining issue preventing soc- camera subdevs from being used generally. (Control handling is also still special, but this is being worked on.) Yes, I like the idea in principle (/me pulling his bullet-proof vest on), :-) as some of you might guess, because I feel it's going away from the idea, that I've been hard pressed to accept of hard-coding the media-bus configuration and in the direction of direct communication of bus-parameters between the (sub-)devices, e.g., a camera host and a camera device in soc-camera terminology. But before reviewing the patch as such, I'd like to discuss the strategy, that we want to pursue here - what exactly do we want to hard-code and what we want to configure dynamically? As explained before, my preference would be to only specify the absolute minimum in the platform data, i.e., parameters that either are ambiguous or special for this platform. So, once again, my approach to configure interface parameters like signal polarities and edge sensitivity is: 1. if at least one side has a fixed value of the specific parameter, usually no need to specify it in platform data. Example: sensor only supports HSYNC active high, host supports both, normally high should be selected. 2. as above, but there's an inverter on the board in the signal path. The invert parameter must be specified in the platform data and the host will configure itself to low and send high confirmed to the sensor. 3. both are configurable. In this case the platform data has to specify, which polarity shall be used. This is simple, it is implemented, it has worked that way with no problem for several years now. The configuration procedure in this case looks like: 1. host requests supported interface configurations from the client (sensor) 2. host matches returned parameters against platform data and its own capabilities 3. if no suitable configuration possible - error out 4. the single possible configuration is identified and sent to the sensor back for its configuration This way we need one more method: s_interface_parms. Shortly talking to Laurent earlier today privately, he mentioned, that one of the reasons for this move is to support dynamic bus reconfiguration, e.g., the number of used CSI lanes. The same is useful for parallel interfaces. E.g., I had to hack the omap3spi driver to capture only 8 (parallel) data lanes from the sensor, connected with all its 10 lanes to get a format, easily supported by user-space applications. Ideally you don't want to change anything in the code for this. If the user is requesting the 10-bit format, all 10 lanes are used, if only 8 - the interface is reconfigured accordingly. I have no problems with dynamic bus reconfiguration as such. So if the host driver wants to do lane reconfiguration, then that's fine by me. When it comes to signal integrity (polarity, rising/falling edge), then I remain convinced that this should be set via platform data. This is not something that should be negotiated since this depends not only on the sensor and host devices, but also on the routing of the lines between them on the actual board, how much noise there is on those lines, the quality of the clock signal, etc. Not really an issue with PAL/NTSC type signals, but when you get to 1080p60 and up, then such things become much more important. So these settings should not be negotiated, but set explicitly. It actually doesn't have to be done through platform data (although that makes the most sense), as long as it is explicitly set based on board-specific data. My 2 cents here is that I think this consists in 2 parts, and should be divided properly. 1. You know required # of lanes clockspeed after you had set the format. For example: - VGA @ 30fps DDR Clk: 330 MHz Number of Datalanes: 1 - VGA @ 60fps DDR Clk: 330 MHz Number of Datalanes: 2 - 12MPix @ 10fps DDR Clk: 480 MHz Number of Datalanes: 2 This usually is something you know from the sensor config selected based on your params. So, I think this is something that the host
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
On Tue, 22 Feb 2011, Hans Verkuil wrote: On Tuesday, February 22, 2011 12:40:32 Guennadi Liakhovetski wrote: On Tue, 22 Feb 2011, Stanimir Varbanov wrote: 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. Stanimir, thanks for the RFC. I think it is time that we create a good solution for this. This is currently the last remaining issue preventing soc- camera subdevs from being used generally. (Control handling is also still special, but this is being worked on.) Yes, I like the idea in principle (/me pulling his bullet-proof vest on), :-) as some of you might guess, because I feel it's going away from the idea, that I've been hard pressed to accept of hard-coding the media-bus configuration and in the direction of direct communication of bus-parameters between the (sub-)devices, e.g., a camera host and a camera device in soc-camera terminology. But before reviewing the patch as such, I'd like to discuss the strategy, that we want to pursue here - what exactly do we want to hard-code and what we want to configure dynamically? As explained before, my preference would be to only specify the absolute minimum in the platform data, i.e., parameters that either are ambiguous or special for this platform. So, once again, my approach to configure interface parameters like signal polarities and edge sensitivity is: 1. if at least one side has a fixed value of the specific parameter, usually no need to specify it in platform data. Example: sensor only supports HSYNC active high, host supports both, normally high should be selected. 2. as above, but there's an inverter on the board in the signal path. The invert parameter must be specified in the platform data and the host will configure itself to low and send high confirmed to the sensor. 3. both are configurable. In this case the platform data has to specify, which polarity shall be used. This is simple, it is implemented, it has worked that way with no problem for several years now. The configuration procedure in this case looks like: 1. host requests supported interface configurations from the client (sensor) 2. host matches returned parameters against platform data and its own capabilities 3. if no suitable configuration possible - error out 4. the single possible configuration is identified and sent to the sensor back for its configuration This way we need one more method: s_interface_parms. Shortly talking to Laurent earlier today privately, he mentioned, that one of the reasons for this move is to support dynamic bus reconfiguration, e.g., the number of used CSI lanes. The same is useful for parallel interfaces. E.g., I had to hack the omap3spi driver to capture only 8 (parallel) data lanes from the sensor, connected with all its 10 lanes to get a format, easily supported by user-space applications. Ideally you don't want to change anything in the code for this. If the user is requesting the 10-bit format, all 10 lanes are used, if only 8 - the interface is reconfigured accordingly. I have no problems with dynamic bus reconfiguration as such. So if the host driver wants to do lane reconfiguration, then that's fine by me. When it comes to signal integrity (polarity, rising/falling edge), then I remain convinced that this should be set via platform data. This is not something that should be negotiated since this depends not only on the sensor and host devices, but also on the routing of the lines between them on the actual board, how much noise there is on those lines, the quality of the clock signal, etc. Not really an issue with PAL/NTSC type signals, but when you get to 1080p60 and up, then such things become much more important. I understand this, but my point is: forcing this parameters in the platform data doesn't give you any _practical_ enhancements, only _psychological_, meaning, that you think, that if these parameters are compulsory, programmers, writing board integration code, will be forced to think, what values to configure. Whereas if this is not compulsory, programmers will hope on automagic and things will break. So, this is purely psychological. And that's the whole question - fo we trust programmers, that they will anyway take care to set correct parameters, or do we not trust them and therefore want to punish everyone because of them. Besides, I'm pretty convinced, that even if those parameters will be compulsory, most programmers will anyway just copy-paste them from similar set ups... Thanks Guennadi So these settings should not be negotiated, but set explicitly. It actually doesn't have to be done through platform data (although that makes the most
RE: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
On Tue, 22 Feb 2011, Aguirre, Sergio wrote: For example, at least OMAP3 4 has the following pin pairs: CSI2_DX0, CSI2_DY0 CSI2_DX1, CSI2_DY1 CSI2_DX2, CSI2_DY2 CSI2_DX3, CSI2_DY3 CSI2_DX4, CSI2_DY4 So, what you do is that, you can control where do you want the clock, where do you want each datalane pair, and also the pin polarity (X: +, Y: -, or viceversa). And this is something that is static. THIS I think should go in the host driver's platform data. I think, these are two different things: pin roles - yes, they are SoC-specific and, probably, hard-wired. But once you've assigned roles, you have to configure them - roles, functions, not pins. And that configuration is no longer SoC specific, at least some of the parameters are common to all such set ups - polarities and edges. So, you can use the same set of parameters for them on different platforms. And yes - you have to be able to configure them dynamically. Consider two sensors switching to the same host by means of some board logic. So, at least there have to be multiple parameter sets to use, depending on the connection topology. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Q] {enum,s,g}_input for subdev ops
Hi
Any thoughts about the subj? Hasn't anyone run into a need to select
inputs on subdevices until now? Something like
struct v4l2_subdev_video_ops {
...
int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *inp);
int (*g_input)(struct v4l2_subdev *sd, unsigned int *i);
int (*s_input)(struct v4l2_subdev *sd, unsigned int i);
For example, we discussed implementing sensor test patterns as separate
inputs.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
On Tue, 22 Feb 2011, Hans Verkuil wrote: Secondly, if we rely on negotiations, then someone at some time might change things and suddenly the negotiation gives different results which may not work on some boards. And such bugs can be extremely hard to track down. So that is Sorry, there's always a chance, that someone breaks something. Always when changing central algorithms you have to take care, that behaviour doesn't change on existing configurations. Nothing new there. why I don't want to rely on negotiations of these settings. People are free to copy and paste, though. I assume (and hope) that they will test before sending a patch, so if it works with the copy-and-pasted settings, then that's good enough for me. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
Hi, Guennadi Liakhovetski wrote: On Tue, 22 Feb 2011, Hans Verkuil wrote: On Tuesday, February 22, 2011 12:40:32 Guennadi Liakhovetski wrote: On Tue, 22 Feb 2011, Stanimir Varbanov wrote: 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. Stanimir, thanks for the RFC. I think it is time that we create a good solution for this. This is currently the last remaining issue preventing soc- camera subdevs from being used generally. (Control handling is also still special, but this is being worked on.) Yes, I like the idea in principle (/me pulling his bullet-proof vest on), :-) as some of you might guess, because I feel it's going away from the idea, that I've been hard pressed to accept of hard-coding the media-bus configuration and in the direction of direct communication of bus-parameters between the (sub-)devices, e.g., a camera host and a camera device in soc-camera terminology. But before reviewing the patch as such, I'd like to discuss the strategy, that we want to pursue here - what exactly do we want to hard-code and what we want to configure dynamically? As explained before, my preference would be to only specify the absolute minimum in the platform data, i.e., parameters that either are ambiguous or special for this platform. So, once again, my approach to configure interface parameters like signal polarities and edge sensitivity is: 1. if at least one side has a fixed value of the specific parameter, usually no need to specify it in platform data. Example: sensor only supports HSYNC active high, host supports both, normally high should be selected. 2. as above, but there's an inverter on the board in the signal path. The invert parameter must be specified in the platform data and the host will configure itself to low and send high confirmed to the sensor. 3. both are configurable. In this case the platform data has to specify, which polarity shall be used. This is simple, it is implemented, it has worked that way with no problem for several years now. The configuration procedure in this case looks like: 1. host requests supported interface configurations from the client (sensor) 2. host matches returned parameters against platform data and its own capabilities 3. if no suitable configuration possible - error out 4. the single possible configuration is identified and sent to the sensor back for its configuration This way we need one more method: s_interface_parms. Shortly talking to Laurent earlier today privately, he mentioned, that one of the reasons for this move is to support dynamic bus reconfiguration, e.g., the number of used CSI lanes. The same is useful for parallel interfaces. E.g., I had to hack the omap3spi driver to capture only 8 (parallel) data lanes from the sensor, connected with all its 10 lanes to get a format, easily supported by user-space applications. Ideally you don't want to change anything in the code for this. If the user is requesting the 10-bit format, all 10 lanes are used, if only 8 - the interface is reconfigured accordingly. I have no problems with dynamic bus reconfiguration as such. So if the host driver wants to do lane reconfiguration, then that's fine by me. When it comes to signal integrity (polarity, rising/falling edge), then I remain convinced that this should be set via platform data. This is not something that should be negotiated since this depends not only on the sensor and host devices, but also on the routing of the lines between them on the actual board, how much noise there is on those lines, the quality of the clock signal, etc. Not really an issue with PAL/NTSC type signals, but when you get to 1080p60 and up, then such things become much more important. I think this could be satisfied by Guennadi's approach because he use the platform data with preference. I understand this, but my point is: forcing this parameters in the platform data doesn't give you any _practical_ enhancements, only _psychological_, meaning, that you think, that if these parameters are compulsory, programmers, writing board integration code, will be forced to think, what values to configure. Whereas if this is not compulsory, programmers will hope on automagic and things will break. So, this is purely psychological. And that's the whole question - fo we trust programmers, that they will anyway take care to set correct parameters, or do we not trust them and therefore want to punish everyone because of them. Besides, I'm pretty convinced, that even if those parameters will be compulsory, most programmers will anyway just copy-paste them from similar set ups... Guennadi, IMO, to force peoples to __not__ thinking about the above parameter configurations you need to do
Re: [PATCH v2 1/1] headers: fix circular dependency between linux/sched.h and linux/wait.h
On Mon, Feb 21, 2011 at 7:27 PM, Oleg Nesterov o...@redhat.com wrote: On 02/21, Oleg Nesterov wrote: On 02/21, Peter Zijlstra wrote: afaict its needed because struct signal_struct and struct sighand_struct include a wait_queue_head_t. The inclusion seems to come through completion.h, but afaict we don't actually need to include completion.h because all we have is a pointer to a completion, which is perfectly fine with an incomplete type. This all would suggest we move the signal bits into their own header (include/linux/signal.h already exists and seems inviting). Agreed, sched.h contatins a lot of garbage, including the signal bits. As for signal_struct in particular I am not really sure, it is just misnamed. It is in fact struct process or struct thread_group. But dequeue_signal/etc should go into signal.h. The only problem, it is not clear how to test such a change. Ah. sched.h includes signal.h, the testing is not the problem. If sched.h includes signal.h and we move wait_queue_head_t users to signal.h, it means signal.h should include wait.h and then it is a problem to include sched.h in wait.h. So, we can (at least) safely move some declarations. Safely, yes, but it won't solve the issue for TASK_* in wait.h. Br, David Oleg. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote: On Tue, 22 Feb 2011, Stan wrote: In principle I agree with this bus negotiation. - So. let's start thinking how this could be fit to the subdev sensor operations. Well, I'm afraid not everyone is convinced yet, so, it is a bit early to start designing interfaces;) - howto isolate your current work into some common place and reuse it, even on platform part. - and is it possible. The discussion becomes very emotional and this is not a good adviser :) No, no emotions at least on this side:) But it's also not technical, unfortunately. I'm prepared to discuss technical benefits or drawbacks of each of these approaches, but these arguments - can we trust programmers or can we not? or will anyone at some time in the future break it or not? Sorry, I am not a psychologist:) Personally, I would _exclusively_ consider technical arguments. Of course, things like clean and simple APIs, proper separation / layering etc. are also important, but even they already can become difficult to discuss and are already on the border between technical issues and personal preferences... So, don't know, in the end, I think, it will just come down to who is making decisions and who is implementing them:) I just expressed my opinion, we don't have to agree, eventually, the maintainer will decide whether to apply patches or not:) In my view at least it *is* a technical argument. It makes perfect sense to me from a technical point of view to put static, board-specific configuration in platform_data. I don't think there would have been much, if any, discussion about this if it wasn't for the fact that soc-camera doesn't do this but instead negotiates it. Obviously, it isn't a pleasant prospect having to change all that. Normally this would be enough of an argument for me to just negotiate it. The reason that I don't want this in this particular case is that I know from personal experience that incorrect settings can be extremely hard to find. I also think that there is a reasonable chance that such bugs can happen. Take a scenario like this: someone writes a new host driver. Initially there is only support for positive polarity and detection on the rising edge, because that's what the current board on which the driver was developed supports. This is quite typical for an initial version of a driver. Later someone adds support for negative polarity and falling edge. Suddenly the polarity negotiation on the previous board results in negative instead of positive which was never tested. Now that board starts producing pixel errors every so often. And yes, this type of hardware problems do happen as I know from painful experience. Problems like this are next to impossible to debug without the aid of an oscilloscope, so this isn't like most other bugs that are relatively easy to debug. It is so much easier just to avoid this by putting it in platform data. It's simple, unambiguous and above all, unchanging. Regards, Hans Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Q] {enum,s,g}_input for subdev ops
On Tuesday, February 22, 2011 17:39:25 Guennadi Liakhovetski wrote:
On Tue, 22 Feb 2011, Hans Verkuil wrote:
Hi
Any thoughts about the subj? Hasn't anyone run into a need to select
inputs on subdevices until now? Something like
struct v4l2_subdev_video_ops {
...
int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *inp);
int (*g_input)(struct v4l2_subdev *sd, unsigned int *i);
int (*s_input)(struct v4l2_subdev *sd, unsigned int i);
That's done through s_routing. Subdevices know nothing about inputs as
shown to userspace.
If you want a test pattern, then the host driver needs to add a Test
Pattern input and call s_routing with the correct values (specific to
that subdev) to set it up.
Hm, maybe I misunderstood something, but if we understand host in the
same way, then this doesn't seem very useful to me. What shall the host
have to do with various sensor inputs? It cannot know, whether the sensor
has a test-pattern input and if yes - how many of them. Many sensors
have several such patterns, and, I think, some of them also have some
parameters, like colour values, etc., which we don't have anything to map
to. But even without that - some sensors have several test patterns, which
they well might want to be able to switch between by presenting not just
one but several test inputs. So, shouldn't we have some enum_routing or
something for them?
What you really want is to select a test pattern. A good solution would be
to create a sensor menu control with all the test patterns it supports.
Regards,
Hans
Feel free to re-add the ML to CC.
Thanks
Guennadi
The saa7127 subdev does something like this (see include/media/saa7127.h).
The ivtv host driver only selects this during firmware load, though. It's
not mapped to a user input.
Regards,
Hans
For example, we discussed implementing sensor test patterns as separate
inputs.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
On Tue, 22 Feb 2011, Hans Verkuil wrote: On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote: On Tue, 22 Feb 2011, Stan wrote: In principle I agree with this bus negotiation. - So. let's start thinking how this could be fit to the subdev sensor operations. Well, I'm afraid not everyone is convinced yet, so, it is a bit early to start designing interfaces;) - howto isolate your current work into some common place and reuse it, even on platform part. - and is it possible. The discussion becomes very emotional and this is not a good adviser :) No, no emotions at least on this side:) But it's also not technical, unfortunately. I'm prepared to discuss technical benefits or drawbacks of each of these approaches, but these arguments - can we trust programmers or can we not? or will anyone at some time in the future break it or not? Sorry, I am not a psychologist:) Personally, I would _exclusively_ consider technical arguments. Of course, things like clean and simple APIs, proper separation / layering etc. are also important, but even they already can become difficult to discuss and are already on the border between technical issues and personal preferences... So, don't know, in the end, I think, it will just come down to who is making decisions and who is implementing them:) I just expressed my opinion, we don't have to agree, eventually, the maintainer will decide whether to apply patches or not:) In my view at least it *is* a technical argument. It makes perfect sense to me from a technical point of view to put static, board-specific configuration in platform_data. I don't think there would have been much, if any, discussion about this if it wasn't for the fact that soc-camera doesn't do this but instead negotiates it. Obviously, it isn't a pleasant prospect having to change all that. Normally this would be enough of an argument for me to just negotiate it. The reason that I don't want this in this particular case is that I know from personal experience that incorrect settings can be extremely hard to find. I also think that there is a reasonable chance that such bugs can happen. Take a scenario like this: someone writes a new host driver. Initially there is only support for positive polarity and detection on the rising edge, because that's what the current board on which the driver was developed supports. This is quite typical for an initial version of a driver. Later someone adds support for negative polarity and falling edge. Suddenly the polarity negotiation on the previous board results in negative instead of positive which was never tested. Now that board starts producing pixel errors every so often. And yes, this type of hardware problems do happen as I know from painful experience. Problems like this are next to impossible to debug without the aid of an oscilloscope, so this isn't like most other bugs that are relatively easy to debug. Well, this is pretty simple to debug with the help of git bisect, as long as patches are sufficiently clean and properly broken down into single topics. It is so much easier just to avoid this by putting it in platform data. It's simple, unambiguous and above all, unchanging. As I said, this all boils down to who does patches and who accepts them for mainlibe. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Q] {enum,s,g}_input for subdev ops
On Tue, 22 Feb 2011, Hans Verkuil wrote:
On Tuesday, February 22, 2011 17:39:25 Guennadi Liakhovetski wrote:
On Tue, 22 Feb 2011, Hans Verkuil wrote:
Hi
Any thoughts about the subj? Hasn't anyone run into a need to select
inputs on subdevices until now? Something like
struct v4l2_subdev_video_ops {
...
int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input
*inp);
int (*g_input)(struct v4l2_subdev *sd, unsigned int *i);
int (*s_input)(struct v4l2_subdev *sd, unsigned int i);
That's done through s_routing. Subdevices know nothing about inputs as
shown to userspace.
If you want a test pattern, then the host driver needs to add a Test
Pattern input and call s_routing with the correct values (specific to
that subdev) to set it up.
Hm, maybe I misunderstood something, but if we understand host in the
same way, then this doesn't seem very useful to me. What shall the host
have to do with various sensor inputs? It cannot know, whether the sensor
has a test-pattern input and if yes - how many of them. Many sensors
have several such patterns, and, I think, some of them also have some
parameters, like colour values, etc., which we don't have anything to map
to. But even without that - some sensors have several test patterns, which
they well might want to be able to switch between by presenting not just
one but several test inputs. So, shouldn't we have some enum_routing or
something for them?
What you really want is to select a test pattern. A good solution would be
to create a sensor menu control with all the test patterns it supports.
Ok, so, we think using extra inputs for test patterns is not all that of a
good idea after all? Maybe you're right. A control menu seems a pretty
good option to me too.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Feb 22 19:00:36 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms
Hi everybody, On 02/22/2011 06:00 PM, Hans Verkuil wrote: On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote: On Tue, 22 Feb 2011, Stan wrote: In principle I agree with this bus negotiation. - So. let's start thinking how this could be fit to the subdev sensor operations. Well, I'm afraid not everyone is convinced yet, so, it is a bit early to start designing interfaces;) - howto isolate your current work into some common place and reuse it, even on platform part. - and is it possible. The discussion becomes very emotional and this is not a good adviser :) No, no emotions at least on this side:) But it's also not technical, unfortunately. I'm prepared to discuss technical benefits or drawbacks of each of these approaches, but these arguments - can we trust programmers or can we not? or will anyone at some time in the future break it or not? Sorry, I am not a psychologist:) Personally, I would _exclusively_ consider technical arguments. Of course, things like clean and simple APIs, proper separation / layering etc. are also important, but even they already can become difficult to discuss and are already on the border between technical issues and personal preferences... So, don't know, in the end, I think, it will just come down to who is making decisions and who is implementing them:) I just expressed my opinion, we don't have to agree, eventually, the maintainer will decide whether to apply patches or not:) In my view at least it *is* a technical argument. It makes perfect sense to me from a technical point of view to put static, board-specific configuration in platform_data. I don't think there would have been much, if any, discussion We should not be forgetting that there often will be two or more sets of platform_data. For sensor, MIPI interface, for the host interface driver.. By negotiating setups we could avoid situations when corresponding parameters are not matched. That is not so meaningful benefit though. Clock values are often being rounded at runtime and do not always reflect exactly the numbers fixed at compile time. And negotiation could help to obtain exact values at both sensor and host side. I personally like the Stanimir's proposal as the parameters to be negotiated are pretty dynamic. Only the number of lanes could be problematic as not all lanes might be routed across different boards. Perhaps we should consider specifying an AUTO value for some negotiated parameters. Such as in case of an attribute that need to be fixed on some boards or can be fully negotiated on others, a fixed value or auto could be respectively set up in the host's platform_data. This could be used to override some parameters in the host driver if needed. IMHO, as long as we negotiate only dynamic parameters there should be no special issues. Regards, Sylwester about this if it wasn't for the fact that soc-camera doesn't do this but instead negotiates it. Obviously, it isn't a pleasant prospect having to change all that. Normally this would be enough of an argument for me to just negotiate it. The reason that I don't want this in this particular case is that I know from personal experience that incorrect settings can be extremely hard to find. I also think that there is a reasonable chance that such bugs can happen. Take a scenario like this: someone writes a new host driver. Initially there is only support for positive polarity and detection on the rising edge, because that's what the current board on which the driver was developed supports. This is quite typical for an initial version of a driver. Later someone adds support for negative polarity and falling edge. Suddenly the polarity negotiation on the previous board results in negative instead of positive which was never tested. Now that board starts producing pixel errors every so often. And yes, this type of hardware problems do happen as I know from painful experience. Problems like this are next to impossible to debug without the aid of an oscilloscope, so this isn't like most other bugs that are relatively easy to debug. It is so much easier just to avoid this by putting it in platform data. It's simple, unambiguous and above all, unchanging. Regards, Hans Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
