Re: [RFC, PATCH 1/2] gspca: add input support for interrupt endpoints
Hi, On Fri, 20 Nov 2009 08:14:10 +0100 Németh Márton nm...@freemail.hu wrote: Hans de Goede wrote: On 11/19/2009 08:46 AM, Németh Márton wrote: Add helper functions for interrupt endpoint based input handling. First of all many many thanks for doing this! You are welcome :-) . My goal is to just make my webcam working properly... Many thanks from me too. This job will be useful for other webcams. [snip] I'm personally not a big fan of adding more configuration options, what should be done instead is make the compilation dependent on the CONFIG_INPUT kernel config option, I see no reason not to enable this when CONFIG_INPUT is enabled. I added dependency on CONFIG_INPUT. The option USB_GSPCA_SN9C20X_EVDEV should be removed too. Some other remarks, you are using: printk(KERN_DEBUG In various places, please use PDEBUG(D_FOO instead so that the output can be controlled using the gspca module's debug parameter. I created a PDEBUG_INPUT() for this otherwise there is a circular dependency between gspca_main and gspca_input because of the variable gspca_debug. That is because you created a separate module. And in gspca_input_connect() you are setting name to pac7302, this needs to be generalized somehow, I use now gspca_dev-sd_desc-name. OK for me. and also you are not setting the input device's parent there, I think we need to fix that too (although I'm not sure what it should be set to). I don't know what to use there, maybe somebody on the linux-input mailing list could tell. sn9c20x sets it to gspca_dev-dev-dev. Also, I am not sure about setting of input_dev-id.version. It seems it can be EV_VERSION only. Unfortunately I still get the following error when I start streaming, stop streaming or unplug the device: [ 6876.780726] uhci_hcd :00:10.1: dma_pool_free buffer-32, de0ad168/1e0ad168 (bad dma) As there is no 'break' in gspca_input_create_urb(), many URBs are created. Please find the new version of this patch later in this mail. Here are some other remarks: - As the input functions are called from the gspca main only, and as they cannot be used by other drivers, there is no need to have a separate module. - Almost all other webcams who have buttons ask for polling. So, the 'int_urb' should be pac7302 dependent (in 'struct sd' and not in 'struct gspca_dev'). Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: Details about DVB frontend API
On Tue, Nov 17, 2009 at 11:46 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Manu Abraham escreveu:
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org escreveu:
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
We all want to know about that ;)
Seriously, the lack of a description of the meaning of the ranges for those
read values were already widely discussed at LMML and at the legacy dvb ML.
We should return this discussion again and decide what would be the better
way to describe those values.
My suggestion is that someone summarize the proposals we had and give some
time
for people vote. After that, we just commit the most voted one, and commit
the
patches for it. A pending question that should also be discussed is what
we will
do with those dvb devices where we simply don't know what scale it uses.
There
are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale even those devices which have a weird scale or
none. Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
Regards,
Manu
Manu,
Sorry for not answering earlier. Due to my travels, I had a very big backlog
here
to handle.
I prefer a solution like you've proposed of creating a new set of API calls
for
it, instead of re-defining the current calls.
I have been unable to respond earlier on this, being out of station.
Sorry, my previous mail failed to reach the Mailing list due to HTML
part being existant. Hopefully it is fixed this time.
Yet, I have a few comments:
diff -r b5505a985f24 linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.h Sat Feb 21 01:12:09 2009 +0400
+++ b/linux/include/linux/dvb/frontend.h Tue Apr 07 18:19:22 2009 +0400
@@ -645,4 +645,118 @@
};
#define DVBFE_GET_EVENT _IOR('o', 86, struct
dvbfe_event)
+/* Frontend General Statistics
+ * General parameters
+ * FE_*_UNKNOWN:
+ * Parameter is unknown to the frontend and doesn't really
+ * make any sense for an application.
+ *
+ * FE_*_RELATIVE:
+ * Parameter is relative on the basis of a ceil - floor basis
+ * Format is based on empirical test to determine
+ * the floor and ceiling values. This format is exactly the
+ * same format as the existing statistics implementation.
+ */
+enum fecap_quality_params {
+ FE_QUALITY_UNKNOWN = 0,
+ FE_QUALITY_SNR = (1 0),
+ FE_QUALITY_CNR = (1 1),
+ FE_QUALITY_EsNo = (1 2),
+ FE_QUALITY_EbNo = (1 3),
+ FE_QUALITY_RELATIVE = (1 31),
+};
+
+enum fecap_scale_params {
+ FE_SCALE_UNKNOWN = 0,
+ FE_SCALE_dB = (1 0),
+ FE_SCALE_RELATIVE = (1 31),
+};
+
+enum fecap_error_params {
+ FE_ERROR_UNKNOWN = 0,
+ FE_ERROR_BER = (1 0),
+ FE_ERROR_PER = (1 1),
+ FE_ERROR_RELATIVE = (1 31),
+};
+
+enum fecap_unc_params {
+ FE_UNC_UNKNOWN = 0,
+ FE_UNC_RELATIVE = (1 31),
+};
+
+/* General parameters
+ * width:
+ * Specifies the width of the field
+ *
+ * exponent:
+ * Specifies the multiplier for the respective field
+ * MSB:1bit indicates the signdness of the parameter
+ */
+struct fecap_quality {
+ enum fecap_quality_params params;
+ enum fecap_scale_params scale;
+
+
Re: [PATCH] soc-camera: sh_mobile_ceu_camera: Add support sync polarity selection
On Fri, 20 Nov 2009, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/sh_mobile_ceu_camera.c | 25 +
include/media/sh_mobile_ceu.h |3 +++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 746aed0..e5cee0f 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -660,6 +660,31 @@ static int sh_mobile_ceu_set_bus_param(struct
soc_camera_device *icd,
if (!common_flags)
return -EINVAL;
+ /* Make choises, based on platform preferences */
+ if ((common_flags SOCAM_HSYNC_ACTIVE_HIGH)
+ (common_flags SOCAM_HSYNC_ACTIVE_LOW)) {
+ if (pcdev-pdata-flags SH_CEU_FLAG_HSP)
+ common_flags = ~SOCAM_HSYNC_ACTIVE_HIGH;
+ else
+ common_flags = ~SOCAM_HSYNC_ACTIVE_LOW;
+ }
Right, that's exactly what I mean, thanks! And, I presume, it fixes your
problem with tm9910, right? The only change to this patch: please, rename
macros. From the above it looks like if SH_CEU_FLAG_HSP is set platform
wanted HSYNC active low. In the PXA case HSP, VSP, and PCP are names for
respective fields in the datasheet, and, as I just notice the datasheet
has a bug describing them. In the descriptive part it says:
HSP: set = HSYNC active high, clear = HSYNC active low
VSP: set = VSYNC active low, clear = VSYNC active high
PCP: set = PIXCLK falling edge, clear = PIXCLK rising edge
But then in register field description it says both HSP and VSP if set are
active low... And this is also what the driver implements, and it seems to
work.
In any case, this confirms, how important good name choice is:-) Now, HSP,
etc. have nothing to do with SH, on CEU these fields are called HDPOL and
VDPOL. But I would suggest some descriptive names, like
SH_CEU_FLAG_HSYNC_HIGH or similar.
+
+ if ((common_flags SOCAM_VSYNC_ACTIVE_HIGH)
+ (common_flags SOCAM_VSYNC_ACTIVE_LOW)) {
+ if (pcdev-pdata-flags SH_CEU_FLAG_VSP)
+ common_flags = ~SOCAM_VSYNC_ACTIVE_HIGH;
+ else
+ common_flags = ~SOCAM_VSYNC_ACTIVE_LOW;
+ }
+
+ if ((common_flags SOCAM_PCLK_SAMPLE_RISING)
+ (common_flags SOCAM_PCLK_SAMPLE_FALLING)) {
+ if (pcdev-pdata-flags SH_CEU_FLAG_PCP)
+ common_flags = ~SOCAM_PCLK_SAMPLE_RISING;
+ else
+ common_flags = ~SOCAM_PCLK_SAMPLE_FALLING;
+ }
This is not needed, CEU only supports sampling on PCLK rising edge.
+
ret = icd-ops-set_bus_param(icd, common_flags);
if (ret 0)
return ret;
diff --git a/include/media/sh_mobile_ceu.h b/include/media/sh_mobile_ceu.h
index 0f3524c..3726daf 100644
--- a/include/media/sh_mobile_ceu.h
+++ b/include/media/sh_mobile_ceu.h
@@ -3,6 +3,9 @@
#define SH_CEU_FLAG_USE_8BIT_BUS (1 0) /* use 8bit bus width */
#define SH_CEU_FLAG_USE_16BIT_BUS(1 1) /* use 16bit bus width */
+#define SH_CEU_FLAG_PCP (1 2) /* Pixel clock
polarity */
ditto - this one is not needed.
+#define SH_CEU_FLAG_HSP (1 3) /* Horizontal sync
polarity */
+#define SH_CEU_FLAG_VSP (1 4) /* Vertical sync
polarity */
struct sh_mobile_ceu_info {
unsigned long flags;
--
1.6.3.3
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
[PATCH] v4l: vm_area_struct::vm_ops isn't const on pre-2.6.32
The vm_area_struct::vm_ops field became const on 2.6.32. All v4l drivers
have been changed to declare their vm_operations_struct as const, which
introduced warnings when compiling on pre-2.6.32 kernels.
Fix the warnings by not declaring the vm_operations_struct as const on
pre-2.6.32 kernels.
kernel-sync
Priority: normal
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
diff -r 7477df192a59 -r 36e9f5dfbfa5 linux/drivers/media/video/cafe_ccic.c
--- a/linux/drivers/media/video/cafe_ccic.c Wed Nov 18 05:12:04 2009 -0200
+++ b/linux/drivers/media/video/cafe_ccic.c Fri Nov 20 10:54:25 2009 +0100
@@ -1326,7 +1326,11 @@
mutex_unlock(sbuf-cam-s_mutex);
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 32)
+static struct vm_operations_struct cafe_v4l_vm_ops = {
+#else
static const struct vm_operations_struct cafe_v4l_vm_ops = {
+#endif
.open = cafe_v4l_vm_open,
.close = cafe_v4l_vm_close
};
diff -r 7477df192a59 -r 36e9f5dfbfa5
linux/drivers/media/video/et61x251/et61x251_core.c
--- a/linux/drivers/media/video/et61x251/et61x251_core.cWed Nov 18
05:12:04 2009 -0200
+++ b/linux/drivers/media/video/et61x251/et61x251_core.cFri Nov 20
10:54:25 2009 +0100
@@ -1500,7 +1500,11 @@
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 32)
+static struct vm_operations_struct et61x251_vm_ops = {
+#else
static const struct vm_operations_struct et61x251_vm_ops = {
+#endif
.open = et61x251_vm_open,
.close = et61x251_vm_close,
};
diff -r 7477df192a59 -r 36e9f5dfbfa5 linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Wed Nov 18 05:12:04 2009 -0200
+++ b/linux/drivers/media/video/gspca/gspca.c Fri Nov 20 10:54:25 2009 +0100
@@ -103,7 +103,11 @@
frame-v4l2_buf.flags = ~V4L2_BUF_FLAG_MAPPED;
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 32)
+static struct vm_operations_struct gspca_vm_ops = {
+#else
static const struct vm_operations_struct gspca_vm_ops = {
+#endif
.open = gspca_vm_open,
.close = gspca_vm_close,
};
diff -r 7477df192a59 -r 36e9f5dfbfa5
linux/drivers/media/video/sn9c102/sn9c102_core.c
--- a/linux/drivers/media/video/sn9c102/sn9c102_core.c Wed Nov 18 05:12:04
2009 -0200
+++ b/linux/drivers/media/video/sn9c102/sn9c102_core.c Fri Nov 20 10:54:25
2009 +0100
@@ -2081,7 +2081,11 @@
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 32)
+static struct vm_operations_struct sn9c102_vm_ops = {
+#else
static const struct vm_operations_struct sn9c102_vm_ops = {
+#endif
.open = sn9c102_vm_open,
.close = sn9c102_vm_close,
};
diff -r 7477df192a59 -r 36e9f5dfbfa5 linux/drivers/media/video/stk-webcam.c
--- a/linux/drivers/media/video/stk-webcam.cWed Nov 18 05:12:04 2009 -0200
+++ b/linux/drivers/media/video/stk-webcam.cFri Nov 20 10:54:25 2009 +0100
@@ -791,7 +791,11 @@
if (sbuf-mapcount == 0)
sbuf-v4lbuf.flags = ~V4L2_BUF_FLAG_MAPPED;
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 32)
+static struct vm_operations_struct stk_v4l_vm_ops = {
+#else
static const struct vm_operations_struct stk_v4l_vm_ops = {
+#endif
.open = stk_v4l_vm_open,
.close = stk_v4l_vm_close
};
diff -r 7477df192a59 -r 36e9f5dfbfa5 linux/drivers/media/video/uvc/uvc_v4l2.c
--- a/linux/drivers/media/video/uvc/uvc_v4l2.c Wed Nov 18 05:12:04 2009 -0200
+++ b/linux/drivers/media/video/uvc/uvc_v4l2.c Fri Nov 20 10:54:25 2009 +0100
@@ -1061,7 +1061,11 @@
buffer-vma_use_count--;
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 32)
+static struct vm_operations_struct uvc_vm_ops = {
+#else
static const struct vm_operations_struct uvc_vm_ops = {
+#endif
.open = uvc_vm_open,
.close = uvc_vm_close,
};
diff -r 7477df192a59 -r 36e9f5dfbfa5
linux/drivers/media/video/videobuf-dma-contig.c
--- a/linux/drivers/media/video/videobuf-dma-contig.c Wed Nov 18 05:12:04
2009 -0200
+++ b/linux/drivers/media/video/videobuf-dma-contig.c Fri Nov 20 10:54:25
2009 +0100
@@ -107,7 +107,11 @@
}
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 32)
+static struct vm_operations_struct videobuf_vm_ops = {
+#else
static const struct vm_operations_struct videobuf_vm_ops = {
+#endif
.open = videobuf_vm_open,
.close= videobuf_vm_close,
};
diff -r 7477df192a59 -r 36e9f5dfbfa5 linux/drivers/media/video/videobuf-dma-sg.c
--- a/linux/drivers/media/video/videobuf-dma-sg.c Wed Nov 18 05:12:04
2009 -0200
+++ b/linux/drivers/media/video/videobuf-dma-sg.c Fri Nov 20 10:54:25
2009 +0100
@@ -422,8 +422,11 @@
}
#endif
-static const struct vm_operations_struct videobuf_vm_ops =
-{
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 32)
+static struct vm_operations_struct videobuf_vm_ops = {
+#else
+static const struct vm_operations_struct videobuf_vm_ops = {
+#endif
.open = videobuf_vm_open,
.close= videobuf_vm_close,
#if
High prio fixes for 2.6.32: urgent!
Hi Mauro, Linus just released 2.6.32-rc8 and expects that to be the last rcX. However, I have still four urgent fixes pending: - radio-gemtek-pci fix - davinci patch (duplicate config pointer) - s2250 mutex patch - add the missing s2250-loader.h The first is already in v4l-dvb, but has not yet been pushed upstream, the others are still pending. The last concerns a file that is in our v4l-dvb repository, but is *not* in the 2.6.32-rc8 tree. So that needs to be pushed upstream. The other two patches are in two different pull requests from me, but I'll make another tree later today with just these two high-prio patches to make it easy for you to merge just those. I hope you can find some time to get these pushed to 2.6.32. Regards, Hans PS: I found another compiler error for a davinci-emac.c file in 2.6.32. I've notified the davinci mailinglist about this as well. -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] soc-camera: tw9910: Add sync polarity support
On Fri, 20 Nov 2009, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index a4ba720..243207d 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -166,7 +166,7 @@
#define VSSL_FIELD 0x20 /* 2 : FIELD */
#define VSSL_VVALID 0x30 /* 3 : VVALID */
#define VSSL_ZERO 0x70 /* 7 : 0 */
-#define HSP_LOW 0x00 /* 0 : HS pin output polarity is active low */
+#define HSP_LO 0x00 /* 0 : HS pin output polarity is active low */
I would remove field names with 0 values completely. Also see below
#define HSP_HI 0x08 /* 1 : HS pin output polarity is active high.*/
/* HS pin output control */
#define HSSL_HACT 0x00 /* 0 : HACT */
@@ -175,6 +175,11 @@
#define HSSL_HLOCK 0x03 /* 3 : HLOCK */
#define HSSL_ASYNCW 0x04 /* 4 : ASYNCW */
#define HSSL_ZERO 0x07 /* 7 : 0 */
+ /* xSSL_xVALID polarity */
+#define VSP_V_LOVSP_HI /* xSSL_xVALID case, polarity will be inverted */
+#define VSP_V_HIVSP_LO
+#define HSP_V_LOHSP_HI
+#define HSP_V_HIHSP_LO
I wouldn't add these - just add a comment below and use reverted
[HV]SP_{HI,LO} macros.
/* ACNTL1 */
#define SRESET 0x80 /* resets the device to its default state
@@ -513,12 +518,22 @@ static int tw9910_set_bus_param(struct
soc_camera_device *icd,
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct i2c_client *client = sd-priv;
+ u8 val = VSSL_VVALID | HSSL_DVALID;
/*
* set OUTCTR1
*/
- return i2c_smbus_write_byte_data(client, OUTCTR1,
- VSSL_VVALID | HSSL_DVALID);
+ if (flags SOCAM_HSYNC_ACTIVE_LOW)
+ val |= HSP_V_LO;
+ else
+ val |= HSP_V_HI;
I think, for single-bit fields we usually only do
if (must_set)
val |= field;
and leave the case
else
val |= 0;
away. So, I would completely remove those macros with 0 value and only
do the 1 case. Then you'd just have
+ /*
+* We use VVALID and DVALID signals to control VSYNC and HSYNC
+* outputs, in this mode their polarity is inverted.
+*/
+ if (flags SOCAM_HSYNC_ACTIVE_LOW)
+ val |= HSP_HI;
without any else, agree?
+
+ if (flags SOCAM_VSYNC_ACTIVE_LOW)
+ val |= VSP_V_LO;
+ else
+ val |= VSP_V_HI;
ditto.
+
+ return i2c_smbus_write_byte_data(client, OUTCTR1, val);
}
I think, I begin to understand what these *VALID signals are... Looks like
VVALID and DVALID are internal signals, which are not routed outside, but
you can select them as one of options to control HSYNC and VSYNC outputs.
static unsigned long tw9910_query_bus_param(struct soc_camera_device *icd)
@@ -528,6 +543,7 @@ static unsigned long tw9910_query_bus_param(struct
soc_camera_device *icd)
struct soc_camera_link *icl = to_soc_camera_link(icd);
unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
+ SOCAM_VSYNC_ACTIVE_LOW | SOCAM_HSYNC_ACTIVE_LOW |
SOCAM_DATA_ACTIVE_HIGH | priv-info-buswidth;
return soc_camera_apply_sensor_flags(icl, flags);
--
1.6.3.3
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: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
On Fri, Nov 20, 2009 at 2:45 AM, Patrick Boettcher pboettc...@kernellabs.com wrote: According to DiBcom's contact at Pinnacle, it was a mistake to add the Product IDs with Pinnacle's USB vendor ID and it needed to be replaced. I'd be not surprised if that is not correct and that you're right. I will fix it and will try to clarify the situation internally. Given the conflicting information, I have just sent an email to my PCTV contact asking for clarification. It's possible I somehow misinterpreted his previous response. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: Details about DVB frontend API
Am Freitag, 20. November 2009 10:29:34 schrieb Manu Abraham: Let me explain a bit. The current issue that persists as Devin explained in another email explains things to a certain extend, but still i think it might be better to detail further. Generally a request can be classified to 3 basic types. 1. Request to acquire, retrieve acquisition details 2. Get information (device state, device info) 3. Get information (channel statistics) The first one for example is a request to say tune to a channel, get tuned channel details, or even other frontend specific commands such as SEC operations. These operations are not very critical with regards on a time scale, just that things could be shifted all along on the time scale, the worser the implementation, the larger the time taken to carry around a larger set of information to handle the operation. Currently, the V3.x and the V5 implementation handles this. The V3 implementation is small and fast, while the V5 implementation is sluggish. The second one gets basic device information. The V3 implementation handled this to a certain extend, but the V5 implementation hardly handles this and the implementation is rather crude rather than being sophisticated. The third aspect which is basically needed in most cases for debugging the channel properties. If all things were ideal, one wouldn't need to know the details on what's going on inside. So being in the far from ideal thing, the requisite to know what happens internally is very much a need in all cases. Another point to be noted is that this category of information is very much critical on a timescale as these parameters are valid for a very certain instances of time only. The more this information gets out of sync, the more these values are meaningless. Also another point to be noted is that all these values when read back together at the very same instance only does make sense. It is indeed very hard to achieve this very short timespan between each of the values being monitored. The larger the bandwidth associated, the larger the error introduced in the readback of the values within the same timeframe in between the reads. So the timeframe has to be the very least possible in between this operation to the device driver internals too.. Although, i have pointed out with this patch what happens at the driver level and at the userspace level, There needs additions to the libdvb parts to handle whatever conversions from format x to y. This needs to be handled since it might not be very easy to be handled consistsently by all applications. So in this concept, the application can choose the format conversion from the library as well, such that the application can provide the statistics in either the the driver native format, or a unified format (conversion done by the library) if the user prefers it. We are already redefining some existing ioctls there, so it would be clearer for the userspace developers what would be the new way to retrieve frontend stats, as we can simply say that DVBS2API features superseeds the equivalent DVB v3 ioctls. As i have noted above, the statistics related calls have a meaning, if and only if it is hanled very fast and properly with no caching. Having a genarlized datastructure to handle this event, breaks up the whole meaning of having this call itself in this position. What an API generally does is to make things generalized. When one makes things the most generalized way an overhead is also associated with it in terms of performance. If things were possible, i would directly read from memory from an application from the hardware itself for processing data in such a scenario, rather than to make things very generalized. This is an area where concepts like data caching can be ruled out completely. We are already at a disadvantage with the kernel driver doing a copy_to_user itself. Ideally, a memory mapped to userspace would have been the ideal thing over here. It is just the question of having yet another set of statistics calls that handles the information properly or not. Hi Manu, thanks for the detailed explanation of your point. Actually I am not completely familiar with how the S2API calls are handled internally. Still are there any proven measurements about the timeframe the calls are being executed within? - I absolutely see that reading signal statistics is a time critical process, at least it is important to be able to assign the data to a specific moment so it can be interpreted in conjunction with the data which is being received in that moment. If this would be the only point where the delay is important one might be able to overcome this by adding timestamps into the retrieved data, although I am not sure if this would be feasible at all. Anyway having a very good and low- delay statistics approach would allow realtime applications like sat-finders to be
SV: [linux-dvb] NOVA-TD exeriences?
-Ursprungligt meddelande- Från: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] För Zdenek Kabelac Skickat: den 4 november 2009 12:34 Till: Soeren Moch Kopia: linux-media@vger.kernel.org Ämne: Re: [linux-dvb] NOVA-TD exeriences? 2009/11/4 Soeren Moch soeren.m...@stud.uni-hannover.de: Zdenek Kabelac wrote: 2009/11/3 Zdenek Kabelac zdenek.kabe...@gmail.com: 2009/11/2 Soeren Moch soeren.m...@stud.uni-hannover.de: Hi. I would be happy to hear if anyone has tried both the NOVA-TD and the NOVA-T. The NOVA-T has always worked perfectly here but I would like to know if the -TD will do the job of two NOVA-T's. And there also seems to be a new version out with two small antenna connectors instead of the previous configuration. Anyone tried it? Does it come with an antenna adaptor cable? http://www.hauppauge.de/de/pics/novatdstick_top.jpg Thankful for any info. Well I've this usb stick with these two small connectors - and it runs just fine. Though I think there is some problem with suspend/resume recently (2.6.32-rc5) and it needs some inspection. But it works just fine for dual dvb-t viewing. And yes - it contains two small antennas with small connectors and one adapter for normal antenna - i.e. 1 antenna input goes to 2 small antenna connectors. zdenek, your nova-td stick works just fine for dual dvb-t viewing? I always had this problem: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. see also: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html Can you please test this case on your nova-td stick? I'll recheck in the evening whether there are no regression, but I've been able to get 3 dvb-t independent (different mux) TV streams (with the usage of the second stick Aver Hybrid Volar HX proprietary Aver driver) with 2.6.29/30 vanilla kernels played at the same time on my C2D T61. Ok - I could confirm, I'm able to play two different muxes at the same time from this USB stick. And I do not experience any stream damage. I'm running Fedora Rawhide with vanilla kernel 2.6.32-rc5, kaffeine 0.8.7 for the first adapter and relatively fresh mplayer compilation for the second adapter Thought there are things to be reported and fixed (some USB regression I guess) - I'll handle this via lkml. Anyway here is dmesg USB stick identification (labeled WinTV Nova-TD) USB device found, idVendor=2040, idProduct=5200 USB device strings: Mfr=1, Product=2, SerialNumber=3 Product: NovaT 500Stick Regards Zdenek Very strange. Playing of two different muxes is also no problem for me, as long as no new stream is started (of course after switching off one of the streams before). In the start moment of the new the stream the already running stream is disturbed and I see a demaged group of pictures in the old stream. After these few pictures the stream is running fine again. I cannot imagine that this is a specific problem of my stick, however, thank you for testing! Hmm - well I haven't made a close inspection (frame by frame) of every frame during the startup of second player. Kaffaine seems to have blocked screen refresh because Xorg gets locked via starting mplayer. So there is definitely frame skipping viewing experience - but that's the flaw of Xorg - sound is played just fine. If I should check whether there are no TS stream errors only at the moment of startup, I'll need to grab both streams and make a better analysis. My current statement was purely based on the fact, that I could watch both channels without any picture artefacts or sound distorsion - but during startup there is surelly a period, when some frames are not even visibile, because kaffeine cannot even refresh playing window - but that's another story Zdenek Hi again. Just got my two new NOVA-TD's and at a first glance they seemed to perform well. Closer inspections however revealed that I see exactly the same issues as Soeren. Watching live TV with VDR on one adaptor while constantly retuning the other one using: while true;do tzap -x svt1;done gives a short glitch in the VDR stream on almost every tzap. Another €100 down the drain. I'll probably buy four NOVA-T's instead just like I planned to at first. /Magnus H -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio
Hi Mauro, As mentioned in my email High prio fixes for 2.6.32: urgent! I have made a tree with just the high-prio fixes: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio It contains these two fixes: - davinci: remove stray duplicate config pointer - s2250: Mutex function usage. As mentioned in the earlier email, the radio-gemtek-pci fix is already in our master repository and the missing s2250-loader.h is also in our repository and was for some reason never pulled into the mainline tree. Note that pulling from this high-prio tree should only be done if you are unable due to time constraints to pull from my v4l-dvb and v4l-dvb-staging trees which already include these patches and a lot more besides. Thanks, Hans diffstat: media/video/davinci/vpif_display.c |1 - staging/go7007/s2250-board.c |4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Help in adding documentation
On Thursday 19 November 2009 18:01:28 Karicheri, Muralidharan wrote: Hans, It is hard for me to get the v4l2-apps compile on my build environment. Unless someone can help me to resolve the build issue, I wouldn't be able to update the v4l2-apps or Alternately someone volunteer to add this support based on the API. OK, the correct procedure to build the apps is this: go to the top-level of your v4l-dvb repository and then run: make distclean (just to be sure we start from scratch) make apps Now, I do get a compile error for decode_tm6000.c (patch pending in one of my pull requests), but by then v4l2-ctl.cpp has already been built. I've also just discovered that the libv4l Makefiles are wrong: they contain a -I../../../include that should be a -I../../include. I think these sources have been moved up one level and the Makefiles were never updated. So if you don't have a recent videodev2.h in your /usr/include/linux directory, then you can get all sorts of compile errors. I've added a patch for this to my pending http://www.linuxtv.org/hg/~hverkuil/v4l-dvb tree. As a workaround while this patch is not merged yet you can copy v4l2-apps/include/linux/videodev2.h to /usr/include/linux/videodev2.h. If you still have problems compiling the v4l2-ctl.cpp tool, then you can also do it manually: g++ -O2 -I../include -D_GNU_SOURCE -lm v4l2-ctl.cpp -o v4l2-ctl Regards, Hans Thanks and regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan Sent: Thursday, November 19, 2009 11:26 AM To: Hans Verkuil; Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org Subject: RE: Help in adding documentation BTW, I don't know what is qt4/qt3 that you are referring to. I see qv4l2 in the directory v4l2-apps/qv4l2. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, November 18, 2009 2:33 AM To: Mauro Carvalho Chehab Cc: Karicheri, Muralidharan; linux-media@vger.kernel.org Subject: Re: Help in adding documentation On Wednesday 18 November 2009 08:24:13 Mauro Carvalho Chehab wrote: Hans Verkuil wrote: On Wednesday 18 November 2009 08:04:10 Mauro Carvalho Chehab wrote: Karicheri, Muralidharan escreveu: Mauro, Thanks to your help, I could finish my documentation today. But I have another issue with the v4l2-apps. When I do make apps, it doesn't seem to build. I get the following error logs... Is this broken? Well... no, it is not really broken, but the build system for v4l2- apps needs serious improvements. There are some know issues on it: - It doesn't check/warn if you don't have all the dependencies (qv4l2 and v4l2-sysfs-path require some development libraries that aren't available per default when gcc is installed - I think the other files there are ok); - make only works fine when calling on certain directories (it used to work fine if you call it from /v4l2-apps/*) - but, since some patch, it now requires that you call make from /v4l2-apps, in order to create v4l2- apps/include. After having it created, make can be called from a /v4l2-apps subdir; - for some places (libv4l - maybe there are other places?), you need to have the latest headers installed, as it doesn't use the one at the tree. - qv4l2 only compiles with qt3. I have a qt4 version available in my v4l-dvb-qv4l2 tree. Just no time to work on a series of patches to merge it in the main repo. And it is missing string control support. If anyone is interested, then feel free to do that work. This new qt4 version is much better than the qt3 version. IMO, the better is to have both versions on separate dirs, and let the building system to check if qt4 is available. If so, build the qt4 version instead of qt3 (a configure script, for example). Otherwise, warn users that it is compiling a legacy application, due to the lack of the proper dependencies. I'm not going to maintain the qt3 version. Personally I think it is pointless having two tools for this and it only creates confusion and unnecessary maintenance cost. Of course, all this is moot as long as the new version is still unmerged. BTW: everything inside v4l2-apps should use the generated headers inside v4l2-apps/include. These are generated from the headers in the tree and yes, it would be nice if v4l2-apps/Makefile would
Re: [PATCH v2] soc-camera: tw9910: modify V/H outpit pin setting to use VALID
On Fri, 13 Nov 2009, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
v1 - v2
o remove un-understandable explain.
- tw9910_query_bus_param need not modify now
o move OUTCTR1 setting to tw9910_set_bus_param
drivers/media/video/tw9910.c | 38 --
1 files changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 6d8dede..82135f2 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -239,18 +239,6 @@ struct tw9910_priv {
u32 revision;
};
-/*
- * register settings
- */
-
-#define ENDMARKER { 0xff, 0xff }
-
-static const struct regval_list tw9910_default_regs[] =
-{
- { OUTCTR1, VSP_LO | VSSL_VVALID | HSP_HI | HSSL_HSYNC },
- ENDMARKER,
-};
-
static const enum v4l2_imgbus_pixelcode tw9910_color_codes[] = {
V4L2_IMGBUS_FMT_VYUY,
};
@@ -463,20 +451,6 @@ static int tw9910_set_hsync(struct i2c_client *client,
return ret;
}
-static int tw9910_write_array(struct i2c_client *client,
- const struct regval_list *vals)
-{
- while (vals-reg_num != 0xff) {
- int ret = i2c_smbus_write_byte_data(client,
- vals-reg_num,
- vals-value);
- if (ret 0)
- return ret;
- vals++;
- }
- return 0;
-}
-
static void tw9910_reset(struct i2c_client *client)
{
tw9910_mask_set(client, ACNTL1, SRESET, SRESET);
@@ -578,7 +552,14 @@ static int tw9910_s_stream(struct v4l2_subdev *sd, int
enable)
static int tw9910_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
- return 0;
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct i2c_client *client = sd-priv;
+
+ /*
+ * set OUTCTR1
+ */
+ return i2c_smbus_write_byte_data(client, OUTCTR1,
+ VSSL_VVALID | HSSL_DVALID);
Hm, strange... This doesn't work at all for me. Getting only timeouts.
Have you tested this on Migo-R?
Thanks
Guennadi
}
static unsigned long tw9910_query_bus_param(struct soc_camera_device *icd)
@@ -681,9 +662,6 @@ static int tw9910_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
* reset hardware
*/
tw9910_reset(client);
- ret = tw9910_write_array(client, tw9910_default_regs);
- if (ret 0)
- goto tw9910_set_fmt_error;
/*
* set bus width
--
1.6.3.3
---
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: [PATCH] Adding helper function to get dv preset description
On Thursday 19 November 2009 17:09:47 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
This patch add a helper function to get description of a digital
video preset added by the video timing API. Hope this will be
usefull for drivers implementing the above API.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
NOTE: depends on the patch that adds video timing API.
This is very inefficient memory-wise. struct v4l2_dv_enum_preset takes 52
bytes and since I expect that we will see a lot of presets in the future,
this can add up very quickly.
IMHO it is better to make a separate struct:
struct v4l2_dv_preset_info {
u16 width;
u16 height;
const char *name;
};
static const struct v4l2_dv_preset_info dv_presets[] = {
{0,0, Invalid }, /* V4L2_DV_INVALID */
{ 720, 480, 4...@59.94 }, /* V4L2_DV_480P59_94 */
};
This is a lot more compact, especially with the strings.
---
Applies to V4L-DVB linux-next branch
drivers/media/video/v4l2-common.c | 135
+ include/media/v4l2-common.h |
1 +
2 files changed, 136 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c index f5a93ae..245e727 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -1015,3 +1015,138 @@ void v4l_bound_align_image(u32 *w, unsigned int
wmin, unsigned int wmax, }
}
EXPORT_SYMBOL_GPL(v4l_bound_align_image);
+
+/**
+ * v4l_fill_dv_preset_info - fill description of a digital video preset
+ * @preset - preset value
+ * @info - pointer to struct v4l2_dv_enum_preset
+ *
+ * drivers can use this helper function to fill description of dv preset
+ * in info.
+ */
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset
*info) +{
+ static const struct v4l2_dv_enum_preset dv_presets[] = {
+ {
+ .preset = V4L2_DV_480P59_94,
+ .name = 4...@59.94,
+ .width = 720,
+ .height = 480,
+ },
+ {
+ .preset = V4L2_DV_576P50,
+ .name = 5...@50,
+ .width = 720,
+ .height = 576,
+ },
+ {
+ .preset = V4L2_DV_720P24,
+ .name = 7...@24,
+ .width = 1280,
+ .height = 720,
+ },
+ {
+ .preset = V4L2_DV_720P25,
+ .name = 7...@25,
+ .width = 1280,
+ .height = 720,
+ },
+ {
+ .preset = V4L2_DV_720P30,
+ .name = 7...@30,
+ .width = 1280,
+ .height = 720,
+ },
+ {
+ .preset = V4L2_DV_720P50,
+ .name = 7...@50,
+ .width = 1280,
+ .height = 720,
+ },
+ {
+ .preset = V4L2_DV_720P59_94,
+ .name = 7...@59.94,
+ .width = 1280,
+ .height = 720,
+ },
+ {
+ .preset = V4L2_DV_720P60,
+ .name = 7...@60,
+ .width = 1280,
+ .height = 720,
+ },
+ {
+ .preset = V4L2_DV_1080I29_97,
+ .name = 10...@29.97,
+ .width = 1920,
+ .height = 1080,
+ },
+ {
+ .preset = V4L2_DV_1080I30,
+ .name = 10...@30,
+ .width = 1920,
+ .height = 1080,
+ },
+ {
+ .preset = V4L2_DV_1080I25,
+ .name = 10...@25,
+ .width = 1920,
+ .height = 1080,
+ },
+ {
+ .preset = V4L2_DV_1080I50,
+ .name = 10...@50,
+ .width = 1920,
+ .height = 1080,
+ },
+ {
+ .preset = V4L2_DV_1080I60,
+ .name = 10...@60,
+ .width = 1920,
+ .height = 1080,
+ },
+ {
+ .preset = V4L2_DV_1080P24,
+ .name = 10...@24,
+ .width = 1920,
+ .height = 1080,
+ },
+ {
+ .preset = V4L2_DV_1080P25,
+ .name = 10...@25,
+ .width = 1920,
+ .height = 1080,
+ },
+
Re: SV: [linux-dvb] NOVA-TD exeriences?
Very strange. Playing of two different muxes is also no problem
for me,
as
long
as no new stream is started (of course after switching off one of the
streams
before). In the start moment of the new the stream the already
running
stream
is disturbed and I see a demaged group of pictures in the old stream.
After
these few pictures the stream is running fine again.
I cannot imagine that this is a specific problem of my stick,
however,
thank you for testing!
Hmm - well I haven't made a close inspection (frame by frame) of every
frame during the startup of second player.
Kaffaine seems to have blocked screen refresh because Xorg gets locked
via starting mplayer.
So there is definitely frame skipping viewing experience - but that's
the flaw of Xorg - sound is played just fine.
If I should check whether there are no TS stream errors only at the
moment of startup, I'll need to grab both streams and make a better
analysis. My current statement was purely based on the fact, that I
could watch both channels without any picture artefacts or sound
distorsion - but during startup there is surelly a period, when some
frames are not even visibile, because kaffeine cannot even refresh
playing window - but that's another story
Zdenek
Hi again. Just got my two new NOVA-TD's and at a first glance they
seemed to
perform well. Closer inspections however revealed that I see exactly
the same
issues as Soeren. Watching live TV with VDR on one adaptor while
constantly
retuning the other one using:
while true;do tzap -x svt1;done
gives a short glitch in the VDR stream on almost every tzap. Another
100EUR down
the drain. I'll probably buy four NOVA-T's instead just like I
planned to at
first.
/Magnus H
Slowly, slowly. Magnus, you want to support dibcom with another 100EUR for
there poor performance in fixing the firmware?
Please test my patches, the nova-td is running fine with these patches,
at least for me.
Patrick, any progress here? Will dibcom fix the firmware, or will you
integrate the
patches? Or what can I do to go on?
Regards,
Soeren
--- drivers/media/common/tuners/mt2266.c.orig 2009-06-29 22:11:08.0 +0200
+++ drivers/media/common/tuners/mt2266.c 2009-06-29 22:21:01.0 +0200
@@ -137,7 +137,6 @@ static int mt2266_set_params(struct dvb_
freq = params-frequency / 1000; // Hz - kHz
if (freq 47 freq 23)
return -EINVAL; /* Gap between VHF and UHF bands */
- priv-bandwidth = (fe-ops.info.type == FE_OFDM) ? params-u.ofdm.bandwidth : 0;
priv-frequency = freq * 1000;
tune = 2 * freq * (8192/16) / (FREF/16);
@@ -145,21 +144,24 @@ static int mt2266_set_params(struct dvb_
if (band == MT2266_VHF)
tune *= 2;
- switch (params-u.ofdm.bandwidth) {
- case BANDWIDTH_6_MHZ:
- mt2266_writeregs(priv, mt2266_init_6mhz,
- sizeof(mt2266_init_6mhz));
- break;
- case BANDWIDTH_7_MHZ:
- mt2266_writeregs(priv, mt2266_init_7mhz,
- sizeof(mt2266_init_7mhz));
- break;
- case BANDWIDTH_8_MHZ:
- default:
- mt2266_writeregs(priv, mt2266_init_8mhz,
- sizeof(mt2266_init_8mhz));
- break;
- }
+if (priv-bandwidth != params-u.ofdm.bandwidth) {
+ priv-bandwidth = (fe-ops.info.type == FE_OFDM) ? params-u.ofdm.bandwidth : 0;
+ switch (params-u.ofdm.bandwidth) {
+ case BANDWIDTH_6_MHZ:
+mt2266_writeregs(priv, mt2266_init_6mhz,
+ sizeof(mt2266_init_6mhz));
+break;
+ case BANDWIDTH_7_MHZ:
+mt2266_writeregs(priv, mt2266_init_7mhz,
+ sizeof(mt2266_init_7mhz));
+break;
+ case BANDWIDTH_8_MHZ:
+ default:
+mt2266_writeregs(priv, mt2266_init_8mhz,
+ sizeof(mt2266_init_8mhz));
+break;
+ }
+}
if (band == MT2266_VHF priv-band == MT2266_UHF) {
dprintk(Switch from UHF to VHF);
@@ -327,6 +329,7 @@ struct dvb_frontend * mt2266_attach(stru
priv-cfg = cfg;
priv-i2c = i2c;
+ priv-bandwidth= BANDWIDTH_8_MHZ;
priv-band = MT2266_UHF;
if (mt2266_readreg(priv, 0, id)) {
--- drivers/media/dvb/dvb-usb/dib0700_devices.c.orig 2009-04-18 16:45:12.0 +0200
+++ drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-04-18 18:58:54.0 +0200
@@ -290,6 +290,9 @@ static int stk7700d_frontend_attach(stru
adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap,0x80+(adap-id 1),
stk7700d_dib7000p_mt2266_config[adap-id]);
+adap-props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap-fe == NULL ? -ENODEV : 0;
}
@@ -1414,7 +1417,7 @@ MODULE_DEVICE_TABLE(usb, dib0700_usb_id_
.streaming_ctrl = dib0700_streaming_ctrl, \
.stream = { \
.type = USB_BULK, \
- .count = 4, \
+ .count = 1, \
.endpoint = ep, \
.u = { \
.bulk = { \
[PATCH/RFC] sh_mobile_ceu_camera: fix pass-through geometry parameters and try_fmt reporting
Fix geometry parameter calculations for the pass-through mode, using the
imagebus API, Also fix try-fmt result reporting for natively supported by
the driver pixel formats.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Marked as RFC because this is based on my imagebus tree. Otherwise this is
nothing new, I've had this fix for a while in my tree, just forgot to post
together with the rest, when presenting my imagebus stack.
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 0114a2b..e7d6191 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -586,20 +586,30 @@ static void sh_mobile_ceu_set_rect(struct
soc_camera_device *icd,
in_width *= 2;
left_offset *= 2;
}
- width = cdwdr_width = out_width;
+ width = out_width;
+ cdwdr_width = out_width;
} else {
- unsigned int w_factor = (7 +
- icd-current_fmt-host_fmt-bits_per_sample) 3;
+ int bytes_per_line = v4l2_imgbus_bytes_per_line(out_width,
+ icd-current_fmt-host_fmt);
+ unsigned int w_factor;
- width = out_width * w_factor / 2;
+ width = out_width;
- if (!pcdev-is_16bit)
- w_factor *= 2;
+ switch (icd-current_fmt-host_fmt-packing) {
+ case V4L2_IMGBUS_PACKING_2X8_PADHI:
+ w_factor = 2;
+ break;
+ default:
+ w_factor = 1;
+ }
- in_width = rect-width * w_factor / 2;
- left_offset = left_offset * w_factor / 2;
+ in_width = rect-width * w_factor;
+ left_offset = left_offset * w_factor;
- cdwdr_width = width * 2;
+ if (bytes_per_line 0)
+ cdwdr_width = out_width;
+ else
+ cdwdr_width = bytes_per_line;
}
height = out_height;
@@ -1547,16 +1557,23 @@ static int sh_mobile_ceu_set_fmt(struct
soc_camera_device *icd,
if (pix-height ceu_rect.height)
pix-height = ceu_rect.height;
- /* Let's rock: scale pix-{width x height} down to width x height */
- scale_h = calc_scale(ceu_rect.width, pix-width);
- scale_v = calc_scale(ceu_rect.height, pix-height);
+ if (image_mode) {
+ /* Scale pix-{width x height} down to width x height */
+ scale_h = calc_scale(ceu_rect.width, pix-width);
+ scale_v = calc_scale(ceu_rect.height, pix-height);
+
+ pcdev-cflcr = scale_h | (scale_v 16);
+ } else {
+ pix-width = ceu_rect.width;
+ pix-height = ceu_rect.height;
+ scale_h = scale_v = 0;
+ pcdev-cflcr = 0;
+ }
dev_geo(dev, 10: W: %u : 0x%x = %u, H: %u : 0x%x = %u\n,
ceu_rect.width, scale_h, pix-width,
ceu_rect.height, scale_v, pix-height);
- pcdev-cflcr = scale_h | (scale_v 16);
-
cam-code = xlate-code;
cam-ceu_rect = ceu_rect;
icd-current_fmt= xlate;
@@ -1618,21 +1635,25 @@ static int sh_mobile_ceu_try_fmt(struct
soc_camera_device *icd,
/* FIXME: check against rect_max after converting soc-camera */
/* We can scale precisely, need a bigger image from camera */
if (pix-width width || pix-height height) {
- int tmp_w = pix-width, tmp_h = pix-height;
- pix-width = 2560;
- pix-height = 1920;
+ /*
+* We presume, the sensor behaves sanely, i.e., if
+* requested a bigger rectangle, it will not return a
+* smaller one.
+*/
+ imgf.width = 2560;
+ imgf.height = 1920;
ret = v4l2_subdev_call(sd, video, try_imgbus_fmt,
imgf);
if (ret 0) {
/* Shouldn't actually happen... */
dev_err(icd-dev.parent,
- FIXME: try_fmt() returned %d\n, ret);
- pix-width = tmp_w;
- pix-height = tmp_h;
+ FIXME: client try_fmt() = %d\n, ret);
+ return ret;
}
}
- if (pix-width width)
+ /* We will scale exactly */
+ if (imgf.width width)
pix-width = width;
- if (pix-height height)
+
SV: SV: [linux-dvb] NOVA-TD exeriences?
Hi again. Just got my two new NOVA-TD's and at a first glance they seemed to perform well. Closer inspections however revealed that I see exactly the same issues as Soeren. Watching live TV with VDR on one adaptor while constantly retuning the other one using: while true;do tzap -x svt1;done gives a short glitch in the VDR stream on almost every tzap. Another 100EUR down the drain. I'll probably buy four NOVA-T's instead just like I planned to at first. /Magnus H Slowly, slowly. Magnus, you want to support dibcom with another 100EUR for there poor performance in fixing the firmware? Please test my patches, the nova-td is running fine with these patches, at least for me. Patrick, any progress here? Will dibcom fix the firmware, or will you integrate the patches? Or what can I do to go on? Regards, Soeren Thanks Soeren, maybe I jumped to the wrong conclusions here. I actually thought this came down to bad hardware design instead of a driver/firmware issue. Unfortunately your patches made no difference here but I won't give up that easily. If they made your problems disapperar there should be hope for me too and I'll be glad to help in the development. I can live with the glitches in the mean time if there's hope for improvement since I mostly watch DVB-S these days. I'm running the stock Ubuntu Karmic 2.6.31 kernel and standard linuxtv drivers from hg. I also have four TT S2-1600 cards in there. /Magnus -- 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: SV: [linux-dvb] NOVA-TD exeriences?
Hi again. Just got my two new NOVA-TD's and at a first glance they seemed to perform well. Closer inspections however revealed that I see exactly the same issues as Soeren. Watching live TV with VDR on one adaptor while constantly retuning the other one using: while true;do tzap -x svt1;done gives a short glitch in the VDR stream on almost every tzap. Another 100EUR down the drain. I'll probably buy four NOVA-T's instead just like I planned to at first. /Magnus H Slowly, slowly. Magnus, you want to support dibcom with another 100EUR for there poor performance in fixing the firmware? Please test my patches, the nova-td is running fine with these patches, at least for me. Patrick, any progress here? Will dibcom fix the firmware, or will you integrate the patches? Or what can I do to go on? Regards, Soeren Thanks Soeren, maybe I jumped to the wrong conclusions here. I actually thought this came down to bad hardware design instead of a driver/firmware issue. Unfortunately your patches made no difference here but I won't give up that easily. If they made your problems disapperar there should be hope for me too and I'll be glad to help in the development. I can live with the glitches in the mean time if there's hope for improvement since I mostly watch DVB-S these days. I'm running the stock Ubuntu Karmic 2.6.31 kernel and standard linuxtv drivers from hg. I also have four TT S2-1600 cards in there. /Magnus Magnus, can you send the USB-IDs of your nova-td-sticks, please? Since I activated the workaround only for stk7700d_dib7000p_mt2266, there might be another funtion to fix your sticks. Soeren -- 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] V4L2: clear buf when vrfb buf not allocated
-Original Message-
From: Hiremath, Vaibhav
Sent: Wednesday, November 18, 2009 8:44 PM
To: Y, Kishore; linux-media@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Subject: RE: [PATCH] V4L2: clear buf when vrfb buf not allocated
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Y, Kishore
Sent: Wednesday, November 18, 2009 7:20 PM
To: linux-media@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Subject: [PATCH] V4L2: clear buf when vrfb buf not allocated
From 15246e4dfa6853d9aef48a4b8633f93efe40ed81 Mon Sep 17 00:00:00
2001
From: Kishore Y kishor...@ti.com
Date: Thu, 12 Nov 2009 20:47:58 +0530
Subject: [PATCH] V4L2: clear buf when vrfb buf not allocated
buffer memory is set to 0 only for the first time
before the vrfb buffer is allocated
Signed-off-by: Kishore Y kishor...@ti.com
---
This patch is dependent on the patch
[PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top
of DSS2
drivers/media/video/omap/omap_vout.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 7092ef2..0a9fdd7 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -223,9 +223,11 @@ static int
omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
unsigned int *count, int startindex)
{
int i, j;
+ int buffer_set;
for (i = 0; i *count; i++) {
- if (!vout-smsshado_virt_addr[i]) {
+ buffer_set = vout-smsshado_virt_addr[i];
+ if (!buffer_set) {
vout-smsshado_virt_addr[i] =
omap_vout_alloc_buffer(vout-smsshado_size,
vout-smsshado_phy_addr[i]);
@@ -247,8 +249,10 @@ static int
omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
*count = 0;
return -ENOMEM;
}
- memset((void *) vout-smsshado_virt_addr[i], 0,
- vout-smsshado_size);
+ if (!buffer_set) {
+ memset((void *) vout-smsshado_virt_addr[i], 0,
+ vout-smsshado_size);
+ }
}
[Hiremath, Vaibhav] Why do we need this? Anyway if I understand correctly
this function is getting called only once during REQBUF or probe, right?
If you are selecting static_vrfb_allocation through module_params, then
anyway REQBUF won't call this function again, since the buffers are
already allocated.
Thanks,
Vaibhav
[Kishore] omap_vout_vrfb_buffer_setup has been called from streamon to support
stop-restart use case without calling REQBUF again. Due to the clear buffer we
are unable to fill buffer in time before display and see green frame for the
first time when streaming video.
return 0;
}
--
1.5.4.3
Regards,
Kishore Y
Ph:- +918039813085
--
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: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
Hi,
I guess this is only one part of the required API support for setting
bus configuration for which I had sent an RFC some time back. I am sure
we need to set bus image/data format in vpfe/vpbe drivers of DMxxx.
I am starting to do more upstream work for vpfe capture display drivers and
would like to submit an updated RFC for bus configuration. I am not sure if
someone is already working on that RFC.
Looks like we need to have two APIs at sub-device level for handling this.
One for image data format (Which is addressed by this RFC) and other for
hardware signals like polarities, bus type etc. Any comments?
BTW, I didn't have a chance to go over Guennadi's RFC for bus image format
so far and hope to spend sometime on this next week.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Friday, November 20, 2009 7:29 AM
To: Guennadi Liakhovetski
Cc: Linux Media Mailing List; Laurent Pinchart; Sakari Ailus; Karicheri,
Muralidharan
Subject: Re: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring
v4l2 subdev pixel and frame formats
On Thursday 19 November 2009 23:33:22 Guennadi Liakhovetski wrote:
Hi Hans
On Sun, 15 Nov 2009, Hans Verkuil wrote:
[snip]
+s32 v4l2_imgbus_bytes_per_line(u32 width,
+ const struct v4l2_imgbus_pixelfmt *imgf)
+{
+switch (imgf-packing) {
+case V4L2_IMGBUS_PACKING_NONE:
+return width * imgf-bits_per_sample / 8;
+case V4L2_IMGBUS_PACKING_2X8_PADHI:
+case V4L2_IMGBUS_PACKING_2X8_PADLO:
+case V4L2_IMGBUS_PACKING_EXTEND16:
+return width * 2;
+}
+return -EINVAL;
+}
+EXPORT_SYMBOL(v4l2_imgbus_bytes_per_line);
As you know, I am not convinced that this code belongs in the core.
I do not think this translation from IMGBUS to PIXFMT is generic
enough. However, if you just make this part of soc-camera then I am
OK with this.
Are you referring to a specific function like
v4l2_imgbus_bytes_per_line or to the whole v4l2-imagebus.c?
I'm referring to the whole file.
The whole file and the
v4l2_imgbus_get_fmtdesc() function must be available to all drivers,
not just to soc-camera, if we want to use {enum,g,s,try}_imgbus_fmt
API in other drivers too, and we do want to use them, if we want to
re-use client drivers.
The sub-device drivers do not need this source. They just need to
report the supported image bus formats. And I am far from convinced
that other bridge drivers can actually reuse your v4l2-imagebus.c code.
You mean, all non-soc-camera bridge drivers only handle special client
formats, no generic pass-through?
That's correct. It's never been a problem until now. Usually the format is
fixed, so there is nothing to configure.
What about other SoC v4l host drivers,
not using soc-camera, and willing to switch to v4l2-subdev? Like OMAPs,
etc? I'm sure they would want to be able to use the pass-through mode
And if they can reuse your code, then we will rename it to v4l2-busimage.c
But I have my doubts about that. I don't like that code, but I also don't
have the time to think about a better alternative. As long as it is
soc-camera specific, then I don't mind. And if omap3 can reuse it, then I
clearly was wrong and we can rename it and make it part of the core
framework.
If they can, then we can always rename it from e.g. soc-imagebus.c to
v4l2-imagebus.c. Right now I prefer to keep it inside soc-camera where
is clearly does work and when other people start implementing imagebus
support, then we can refer them to the work you did in soc-camera and
we'll see what happens.
You know how it happens - some authors do not know about some hidden
code, during the review noone realises, that they are re-implementing
that... Eventually you end up with duplicated customised sub-optimal
code. Fresh example - the whole soc-camera framework:-) I only learned
about int-device after soc-camera has already been submitted in its
submission form. And I did ask on lists whether there was any code for
such systems:-)
All the relevant omap developers are CC-ed in this discussion, and I'm also
paying fairly close attention to anything SoC related.
I do not quite understand what disturbs you about making this API global.
It is a completely internal API - no exposure to user-space. We can
modify or remove it any time.
Then think about wider exposure, testing. If you like we can make it a
separate module and make soc-camera select it. And we can always degrade
it back to soc-camera-specific:-)
Making this API global means that it becomes part of the framework. And I
want to pay a lot more attention to that code than we did in the past. So I
have to be convinced that it is code that is really reusable
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio
Hans Verkuil wrote: Hi Mauro, As mentioned in my email High prio fixes for 2.6.32: urgent! I have made a tree with just the high-prio fixes: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio Ok, I merged from it. Please, be sure that you've removed those two patches from the other trees, otherwise hg will merge the patch again. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio
On Friday 20 November 2009 16:33:51 Mauro Carvalho Chehab wrote: Hans Verkuil wrote: Hi Mauro, As mentioned in my email High prio fixes for 2.6.32: urgent! I have made a tree with just the high-prio fixes: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio Ok, I merged from it. Please, be sure that you've removed those two patches from the other trees, otherwise hg will merge the patch again. I'll respin those trees and post new pull requests. Thanks for commiting these high-prio patches! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Details about DVB frontend API
On Fri, Nov 20, 2009 at 3:37 PM, Julian Scheel jul...@jusst.de wrote: Am Freitag, 20. November 2009 10:29:34 schrieb Manu Abraham: Let me explain a bit. The current issue that persists as Devin explained in another email explains things to a certain extend, but still i think it might be better to detail further. Generally a request can be classified to 3 basic types. 1. Request to acquire, retrieve acquisition details 2. Get information (device state, device info) 3. Get information (channel statistics) The first one for example is a request to say tune to a channel, get tuned channel details, or even other frontend specific commands such as SEC operations. These operations are not very critical with regards on a time scale, just that things could be shifted all along on the time scale, the worser the implementation, the larger the time taken to carry around a larger set of information to handle the operation. Currently, the V3.x and the V5 implementation handles this. The V3 implementation is small and fast, while the V5 implementation is sluggish. The second one gets basic device information. The V3 implementation handled this to a certain extend, but the V5 implementation hardly handles this and the implementation is rather crude rather than being sophisticated. The third aspect which is basically needed in most cases for debugging the channel properties. If all things were ideal, one wouldn't need to know the details on what's going on inside. So being in the far from ideal thing, the requisite to know what happens internally is very much a need in all cases. Another point to be noted is that this category of information is very much critical on a timescale as these parameters are valid for a very certain instances of time only. The more this information gets out of sync, the more these values are meaningless. Also another point to be noted is that all these values when read back together at the very same instance only does make sense. It is indeed very hard to achieve this very short timespan between each of the values being monitored. The larger the bandwidth associated, the larger the error introduced in the readback of the values within the same timeframe in between the reads. So the timeframe has to be the very least possible in between this operation to the device driver internals too.. Although, i have pointed out with this patch what happens at the driver level and at the userspace level, There needs additions to the libdvb parts to handle whatever conversions from format x to y. This needs to be handled since it might not be very easy to be handled consistsently by all applications. So in this concept, the application can choose the format conversion from the library as well, such that the application can provide the statistics in either the the driver native format, or a unified format (conversion done by the library) if the user prefers it. We are already redefining some existing ioctls there, so it would be clearer for the userspace developers what would be the new way to retrieve frontend stats, as we can simply say that DVBS2API features superseeds the equivalent DVB v3 ioctls. As i have noted above, the statistics related calls have a meaning, if and only if it is hanled very fast and properly with no caching. Having a genarlized datastructure to handle this event, breaks up the whole meaning of having this call itself in this position. What an API generally does is to make things generalized. When one makes things the most generalized way an overhead is also associated with it in terms of performance. If things were possible, i would directly read from memory from an application from the hardware itself for processing data in such a scenario, rather than to make things very generalized. This is an area where concepts like data caching can be ruled out completely. We are already at a disadvantage with the kernel driver doing a copy_to_user itself. Ideally, a memory mapped to userspace would have been the ideal thing over here. It is just the question of having yet another set of statistics calls that handles the information properly or not. Hi Manu, thanks for the detailed explanation of your point. Actually I am not completely familiar with how the S2API calls are handled internally. Still are there any proven measurements about the timeframe the calls are being executed within? - I absolutely see that reading signal statistics is a time critical process, at least it is important to be able to assign the data to a specific moment so it can be interpreted in conjunction with the data which is being received in that moment. Not only is it time critical, but it should also be atomic, ie it should be all in one go, ie one single snapshot of an event, not events bunched together serially. Things wont seem that atomic on a system with a large load. Latency will have a significant effect on
Help request: switching multiple TS stream audio PIDs on the fly with xine-ui and mplayer
Hi,
I'd be really very thankful for any contribution on the following issue:
1. My motivation:
I do not like: KDE 4, kaffeine, xawtv and vdr for reasons I do not want
to discuss here.
I prefer to watch DVB-S TV with xine-ui and / or gmplayer.
2. The current state of development:
Xine-lib supports multiple audio PIDs demuxing TS streams since version
1.1.5.
Mplayer only supports one audio PID (usually the first one that it
finds).
3. My intention:
Switching audio PIDs of DVB-S streams on the fly with the appropriate
GUIs xine-ui and gmplayer.
4. My contribution:
A patch for the scan utility (part of the DVB utils) that features all
available audio PIDs
producing a _non-vdr_ output format.
This patch is not only necessary for revealing multiple audio tracks of
a DVB TV channel in case
you're producing a non-vdr channels.conf.
It also keeps up compatibility with mplayer which cannot (yet) handle
channel lists in vdr format.
--- a/scan.patch
+++ b/scan.patch
@@ -0,0 +1,88 @@
--- a/util/scan/scan.c
+++ b/util/scan/scan.c
@@ -1260,7 +1260,7 @@
static LIST_HEAD(running_filters);
static LIST_HEAD(waiting_filters);
static int n_running;
-#define MAX_RUNNING 27
+#define MAX_RUNNING 10
static struct pollfd poll_fds[MAX_RUNNING];
static struct section_buf* poll_section_bufs[MAX_RUNNING];
@@ -2035,6 +2035,8 @@
sat_number(t),
s-video_pid,
s-audio_pid,
+ s-audio_lang,
+ s-audio_num,
s-service_id);
default:
break;
--- a/util/scan/dump-zap.c
+++ b/util/scan/dump-zap.c
@@ -75,7 +75,6 @@
fprintf (f, %c:, polarity);
fprintf (f, %d:, sat_number);
fprintf (f, %i, p-u.qpsk.symbol_rate / 1000); /*
channels.conf
wants kBaud */
- /*fprintf (f, %s, fec_name[p-u.qpsk.fec_inner]);*/
break;
case FE_QAM:
@@ -114,12 +113,27 @@
struct dvb_frontend_parameters *p,
char polarity,
int sat_number,
-uint16_t video_pid,
+int video_pid,
uint16_t *audio_pid,
-uint16_t service_id)
+char audio_lang[][4],
+int audio_num,
+int service_id)
{
+ int i;
+ if (video_pid || audio_pid[0]) {
fprintf (f, %s:, service_name);
zap_dump_dvb_parameters (f, type, p, polarity, sat_number);
+ fprintf (f, :%i:, video_pid);
+ fprintf (f, %i, audio_pid[0]);
+ if (audio_lang audio_lang[0][0])
+ fprintf (f, =%.4s, audio_lang[0]);
+ for (i = 1; i audio_num; i++)
+ {
+ fprintf (f, ,%i, audio_pid[i]);
+ if (audio_lang audio_lang[i][0])
+ fprintf (f, =%.4s, audio_lang[i]);
+ }
+ fprintf (f, :%d, service_id);
- fprintf (f, :%i:%i:%i, video_pid, audio_pid[0], service_id);
fprintf (f, \n);
}
+}
--- a/util/scan/dump-zap.h
+++ b/util/scan/dump-zap.h
@@ -1,19 +1,17 @@
#ifndef __DUMP_ZAP_H__
#define __DUMP_ZAP_H__
-
#include stdint.h
#include linux/dvb/frontend.h
-
extern void zap_dump_dvb_parameters (FILE *f, fe_type_t type,
struct dvb_frontend_parameters *t, char polarity, int sat);
-
extern void zap_dump_service_parameter_set (FILE *f,
const char *service_name,
fe_type_t type,
-struct dvb_frontend_parameters *t,
+struct dvb_frontend_parameters *p,
char polarity, int sat,
-uint16_t video_pid,
+int video_pid,
uint16_t *audio_pid,
-uint16_t service_id);
+char audio_lang[][4],
+int audio_num,
+int service_id);
-
#endif
5. Your contribution?
Who can give me hints about how and where patching xine-ui and gmplayer
appropriately so that multiple audio TS PIDS can be changed on the fly?
Who can offer appropriate patches?
Thanks
--
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: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
Patrick Boettcher wrote: PS: how do I do a 'git rebase -i' + 'git reset HEAD~1' with HG (without installing additional stuff by hand)? - Nevermind, I will redo all the commits by hand. For rebase: There are two ways for doing it by using hg extensions. You might try to use hg rebase extension, but I have to warn that this never worked fine for me and it seems that it created a database corruption at the time I used. The other way is to use hg mq extension. It is a quilt like implementation at hg. You'll need to convert the commits you've done into a qseries commit, with hg qimport -r revision After adding all patches to the qseries, you should do: hg qpop -a hg pull -u # To get a copy of upstream tree hg qpush for all patches at the tree up to the one you want to edit. At the patch you'll want to change, you can simply do the editions and do a hg qrefresh You may use -e flag to edit the comments. to commit the remaining patches, do: hg qpush -a For stripping the latest patch: hg strip -r revision of the oldest patch to be removed Mercurial saves a backup of the stripped info, but I have no idea on how to revert. Unfortunately, mercurial has nothing equivalent to git revlog, so, if you do something bad, you may not find a way to undo for more than one level. I hope it helps. 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
[PATCH] dvb: SMS_SIANO_MDTV should depend on HAS_DMA
When building for Sun 3:
drivers/built-in.o: In function `smscore_unregister_device':
drivers/media/dvb/siano/smscoreapi.c:723: undefined reference to
`dma_free_coherent'
drivers/built-in.o: In function `smscore_register_device':
drivers/media/dvb/siano/smscoreapi.c:365: undefined reference to
`dma_alloc_coherent'
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
drivers/media/dvb/siano/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/siano/Kconfig b/drivers/media/dvb/siano/Kconfig
index 8c1aed7..85a222c 100644
--- a/drivers/media/dvb/siano/Kconfig
+++ b/drivers/media/dvb/siano/Kconfig
@@ -4,7 +4,7 @@
config SMS_SIANO_MDTV
tristate Siano SMS1xxx based MDTV receiver
- depends on DVB_CORE INPUT
+ depends on DVB_CORE INPUT HAS_DMA
---help---
Choose Y or M here if you have MDTV receiver with a Siano chipset.
--
1.6.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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
Problem installing driver
Hello, I am Momcilo Medic from Serbia, and I was advised to write you mail with my problem. I am trying to install simple driver and it returns an error. In attachment is error message as well as driver I am trying to install. I am pretty much a newbie for Linux, so if I left something out please do tell and I will send as many info as you need. Thanks in advance, Momcilo. smartcam.c Description: Binary data [r...@devourer driver_src]# make -C /lib/modules/2.6.30.9-96.fc11.x86_64/build/ M=`pwd` make: Entering directory `/usr/src/kernels/2.6.30.9-96.fc11.x86_64' LD /usr/src/smartcam-1.4.0/driver_src/built-in.o CC [M] /usr/src/smartcam-1.4.0/driver_src/smartcam.o /usr/src/smartcam-1.4.0/driver_src/smartcam.c:563: warning: initialization from incompatible pointer type /usr/src/smartcam-1.4.0/driver_src/smartcam.c:599: error: âVID_TYPE_CAPTUREâ undeclared here (not in a function) /usr/src/smartcam-1.4.0/driver_src/smartcam.c:601: warning: initialization from incompatible pointer type make[1]: *** [/usr/src/smartcam-1.4.0/driver_src/smartcam.o] Error 1 make: *** [_module_/usr/src/smartcam-1.4.0/driver_src] Error 2 make: Leaving directory `/usr/src/kernels/2.6.30.9-96.fc11.x86_64'
CH???, Bandwidth 8MHz, Fec_Hi 1/2, Modulation QAM64, Mode 8K, Guard 1/4, fails to tune\demux
02:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget/Hauppauge WinTV-NOVA-T DVB card Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at e3001000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget dvb Kernel modules: budget -- 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 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Fri Nov 20 19:00:12 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13370:7477df192a59 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc8-armv5: OK linux-2.6.32-rc8-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc8-armv5-ixp: OK linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc8-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc8-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc8-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc8-mips: OK linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc8-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc8-x86_64: WARNINGS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc8): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. - decode_tm6000: fix compilation - davinci: add missing vpif_capture.c/h files - Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init - Davinci VPFE Capture: add i2c adapter id in platform data - Davinci VPFE Capture: Take i2c adapter id through platform data - Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev-ccdc_irq1 - V4L2: Added CID's V4L2_CID_ROTATE/BG_COLOR - v4l2 doc: Added ROTATE and BG_COLOR control documentation - Davinci VPFE Capture: Add support for Control ioctls - V4L2: Add Capability and Flag field for Chroma Key - v4l2 doc: Added FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY - v4l2-dbg: report fail reason to the user - libv4l: fix Makefile include dir references (Respun after one high-prio changeset from the original pull request was merged into the master repo) I discovered that for some reason the davinci/vpif_capture.c/h files were missing in the v4l-dvb master repo, so they are added back in the third patch (I copied them from 2.6.32-rc6). There is one arch patch involved here as well: http://patchwork.kernel.org/patch/53426/ This patch belongs after Davinci VPFE Capture: add i2c adapter id in platform data but before Take i2c adapter id through platform data. The new controls and chromakey cap/flag were originally discussed in January to April this year based on omap patches from Hardik Shah. I actually thought these patches were committed months ago, but they apparently fell on the floor. The original discussion is here: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg00624.html Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/vpif_capture.c | 2168 + b/linux/drivers/media/video/davinci/vpif_capture.h | 165 + linux/Documentation/DocBook/v4l/controls.xml | 20 linux/Documentation/DocBook/v4l/pixfmt.xml |5 linux/Documentation/DocBook/v4l/videodev2.h.xml| 1103 +- linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 linux/drivers/media/video/davinci/vpfe_capture.c | 45 linux/drivers/media/video/v4l2-common.c|9 linux/include/linux/videodev2.h|6 linux/include/media/davinci/vpfe_capture.h |2 v4l2-apps/libv4l/libv4l1/Makefile |2 v4l2-apps/libv4l/libv4l2/Makefile |2 v4l2-apps/libv4l/libv4lconvert/Makefile|2 v4l2-apps/util/Makefile|2 v4l2-apps/util/decode_tm6000.c |2 v4l2-apps/util/v4l2-dbg.cpp| 19 16 files changed, 2999 insertions(+), 570 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Problem installing driver
Hi Momcilo, That error means the code is unable to find the kernel sources containing all the definitions from v4l2. Within the driver directory, look for a file named Makefile or Rules.make or Makefile.rules. In one of those, there should be a variable pointing to the kernel sources in your Linux distribution (usually in /usr/src/linux, consult the particular documentation in case you need to install the package or download from www.kernel.org). Set the variable to your particular kernel and recompile. Regards, Mr Momcilo Medic wrote: Hello, I am Momcilo Medic from Serbia, and I was advised to write you mail with my problem. I am trying to install simple driver and it returns an error. In attachment is error message as well as driver I am trying to install. I am pretty much a newbie for Linux, so if I left something out please do tell and I will send as many info as you need. Thanks in advance, Momcilo. -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.com -- 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] Adding helper function to get dv preset description
Hans,
I feel the same way. I will send an updated patch.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Friday, November 20, 2009 7:41 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com
Subject: Re: [PATCH] Adding helper function to get dv preset description
On Thursday 19 November 2009 17:09:47 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
This patch add a helper function to get description of a digital
video preset added by the video timing API. Hope this will be
usefull for drivers implementing the above API.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
NOTE: depends on the patch that adds video timing API.
This is very inefficient memory-wise. struct v4l2_dv_enum_preset takes 52
bytes and since I expect that we will see a lot of presets in the future,
this can add up very quickly.
IMHO it is better to make a separate struct:
struct v4l2_dv_preset_info {
u16 width;
u16 height;
const char *name;
};
static const struct v4l2_dv_preset_info dv_presets[] = {
{0,0, Invalid }, /* V4L2_DV_INVALID */
{ 720, 480, 4...@59.94 }, /* V4L2_DV_480P59_94 */
};
This is a lot more compact, especially with the strings.
---
Applies to V4L-DVB linux-next branch
drivers/media/video/v4l2-common.c | 135
+ include/media/v4l2-common.h |
1 +
2 files changed, 136 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c index f5a93ae..245e727 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -1015,3 +1015,138 @@ void v4l_bound_align_image(u32 *w, unsigned int
wmin, unsigned int wmax, }
}
EXPORT_SYMBOL_GPL(v4l_bound_align_image);
+
+/**
+ * v4l_fill_dv_preset_info - fill description of a digital video preset
+ * @preset - preset value
+ * @info - pointer to struct v4l2_dv_enum_preset
+ *
+ * drivers can use this helper function to fill description of dv preset
+ * in info.
+ */
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset
*info) +{
+static const struct v4l2_dv_enum_preset dv_presets[] = {
+{
+.preset = V4L2_DV_480P59_94,
+.name = 4...@59.94,
+.width = 720,
+.height = 480,
+},
+{
+.preset = V4L2_DV_576P50,
+.name = 5...@50,
+.width = 720,
+.height = 576,
+},
+{
+.preset = V4L2_DV_720P24,
+.name = 7...@24,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P25,
+.name = 7...@25,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P30,
+.name = 7...@30,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P50,
+.name = 7...@50,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P59_94,
+.name = 7...@59.94,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P60,
+.name = 7...@60,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_1080I29_97,
+.name = 10...@29.97,
+.width = 1920,
+.height = 1080,
+},
+{
+.preset = V4L2_DV_1080I30,
+.name = 10...@30,
+.width = 1920,
+.height = 1080,
+},
+{
+.preset = V4L2_DV_1080I25,
+.name = 10...@25,
+.width = 1920,
+.height = 1080,
+},
+{
+.preset = V4L2_DV_1080I50,
+.name = 10...@50,
+.width = 1920,
+.height = 1080,
+},
+{
+.preset = V4L2_DV_1080I60,
+.name = 10...@60,
+.width = 1920,
+.height = 1080,
+},
+
[PATCH 2/2] DaVinci - vpfe capture - converting ccdc to platform driver
From: Muralidharan Karicheri m-kariche...@ti.com
This is the platform part for converting ccdc to platform driver.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-davinci tree
arch/arm/mach-davinci/dm355.c | 27 +++
arch/arm/mach-davinci/dm644x.c | 18 +-
2 files changed, 32 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index dedf4d4..045cb0d 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -701,6 +701,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +712,17 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+ .name = dm355_ccdc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+ .resource = dm355_ccdc_resource,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -860,17 +873,7 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(dm355_edma_device);
platform_device_register(dm355_vpss_device);
- /*
-* setup Mux configuration for vpfe input and register
-* vpfe capture platform device
-*/
- davinci_cfg_reg(DM355_VIN_PCLK);
- davinci_cfg_reg(DM355_VIN_CAM_WEN);
- davinci_cfg_reg(DM355_VIN_CAM_VD);
- davinci_cfg_reg(DM355_VIN_CAM_HD);
- davinci_cfg_reg(DM355_VIN_YIN_EN);
- davinci_cfg_reg(DM355_VIN_CINL_EN);
- davinci_cfg_reg(DM355_VIN_CINH_EN);
+ platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..982be1f 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+ /* CCDC Base address */
{
.start = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
},
};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+ .name = dm644x_ccdc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_ccdc_resource),
+ .resource = dm644x_ccdc_resource,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
platform_device_register(dm644x_edma_device);
platform_device_register(dm644x_emac_device);
platform_device_register(dm644x_vpss_device);
+ platform_device_register(dm644x_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
--
1.6.0.4
--
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
[PATCH 1/2] V4L - vpfe_capture - convert ccdc drivers to platform drivers
From: Muralidharan Karicheri m-kariche...@ti.com
Current implementation defines ccdc memory map in vpfe capture platform
file and update the same in ccdc through a function call. This will not
scale well. For example for DM365 CCDC, there are are additional memory
map for Linear table. So it is cleaner to define memory map for ccdc
driver in the platform file and read it by the ccdc platform driver during
probe.
This is only for review purpose only.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-davinci tree
drivers/media/video/davinci/dm355_ccdc.c | 90 +++
drivers/media/video/davinci/dm644x_ccdc.c | 78
drivers/media/video/davinci/vpfe_capture.c | 56 ++---
3 files changed, 148 insertions(+), 76 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 4629cab..ff81f07 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,6 +37,7 @@
#include linux/platform_device.h
#include linux/uaccess.h
#include linux/videodev2.h
+#include mach/mux.h
#include media/davinci/dm355_ccdc.h
#include media/davinci/vpss.h
#include dm355_ccdc_regs.h
@@ -64,7 +65,6 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
},
.config_params = {
.datasft = 2,
- .data_sz = CCDC_DATA_10BITS,
.mfilt1 = CCDC_NO_MEDIAN_FILTER1,
.mfilt2 = CCDC_NO_MEDIAN_FILTER2,
.alaw = {
@@ -105,7 +105,6 @@ static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
static enum vpfe_hw_if_type ccdc_if_type;
static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
/* Raw Bayer formats */
static u32 ccdc_raw_bayer_pix_formats[] =
@@ -126,12 +125,6 @@ static inline void regw(u32 val, u32 offset)
__raw_writel(val, ccdc_base_addr + offset);
}
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
- ccdc_base_addr = addr;
- ccdc_addr_size = size;
-}
-
static void ccdc_enable(int en)
{
unsigned int temp;
@@ -938,7 +931,6 @@ static struct ccdc_hw_device ccdc_hw_dev = {
.hw_ops = {
.open = ccdc_open,
.close = ccdc_close,
- .set_ccdc_base = ccdc_set_ccdc_base,
.enable = ccdc_enable,
.enable_out_to_sdram = ccdc_enable_output_to_sdram,
.set_hw_if_params = ccdc_set_hw_if_params,
@@ -959,19 +951,89 @@ static struct ccdc_hw_device ccdc_hw_dev = {
},
};
-static int dm355_ccdc_init(void)
+static int __init dm355_ccdc_probe(struct platform_device *pdev)
{
- printk(KERN_NOTICE dm355_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ static resource_size_t res_len;
+ struct resource *res;
+ int status = 0;
+
+ /**
+* first try to register with vpfe. If not correct platform, then we
+* don't have to iomap
+*/
+ status = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (status 0)
+ return status;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ status = -ENOENT;
+ goto fail_nores;
+ }
+ res_len = res-end - res-start + 1;
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res) {
+ status = -EBUSY;
+ goto fail_nores;
+ }
+
+ ccdc_base_addr = ioremap_nocache(res-start, res_len);
+ if (!ccdc_base_addr) {
+ status = -EBUSY;
+ goto fail;
+ }
+ /**
+* setup Mux configuration for vpfe input and register
+* vpfe capture platform device
+*/
+ davinci_cfg_reg(DM355_VIN_PCLK);
+ davinci_cfg_reg(DM355_VIN_CAM_WEN);
+ davinci_cfg_reg(DM355_VIN_CAM_VD);
+ davinci_cfg_reg(DM355_VIN_CAM_HD);
+ davinci_cfg_reg(DM355_VIN_YIN_EN);
+ davinci_cfg_reg(DM355_VIN_CINL_EN);
+ davinci_cfg_reg(DM355_VIN_CINH_EN);
+
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
+fail:
+ release_mem_region(res-start, res_len);
+fail_nores:
+ vpfe_unregister_ccdc_device(ccdc_hw_dev);
+ return status;
}
-static void dm355_ccdc_exit(void)
+static int dm355_ccdc_remove(struct platform_device *pdev)
{
+ struct resource *res;
+
+ iounmap(ccdc_base_addr);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res)
+ release_mem_region(res-start, res-end - res-start + 1);
vpfe_unregister_ccdc_device(ccdc_hw_dev);
+ return 0;
+}
+
+static struct platform_driver dm355_ccdc_driver = {
+ .driver = {
+ .name = dm355_ccdc,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(dm355_ccdc_remove),
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
On Fri, Nov 20, 2009 at 4:45 PM, Hans Verkuil hverk...@xs4all.nl wrote: If there are drivers in the staging tree that are so unreliable that they can break the hardware, then those should be explicitly disabled, rather than disabling all drivers in the staging tree. Or perhaps do not belong there at all, or belong under the CONFIG_STAGING_BROKEN option. A driver like the go7007 is under active development, and it does work. It only needs more cleanup before it can be moved to drivers/media/video, so there was no reason that it should be disabled. Mauro, what are the risks of always compiling the tm6000 and cx25821 drivers? Let me know if you think that either one or both should be disabled for now and I'll make a patch for it. I'm certainly much more worried about the tm6000 stuff than the cx25821, primarily because the cx25821 is pretty rare and the tm6000 is used by several fairly popular consumer products, but is completely broken. I agree that we should be periodically ensuring the modules still compile, but I think that by default they should need to be explicitly enabled by a developer who knows what he/she is doing and understands the ramifications/risks. By not compiling you run the very high risk of bit rot: code getting seriously out-of-sync with the rest of the tree. Possibly requiring a lot of work later. Our tree is primarily for developers, not for end-users. So we need to see any code breakages as early as possible. Sure, in a perfect world that would be true. In reality though, I'm confident that a *huge* percentage of people who compile the v4l-dvb code have absolutely no idea what the hell they are doing. They are end-users who just want to see their device work because the changes haven't made it into their distro yet. I can certainly appreciate the concerns about the bit-rot issue. I am just worried that perhaps we set the bar too low in terms of what got into staging if it's going to be compiled by default. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
[PATCH - v1]V4L - Adding helper function to get dv preset description
From: Muralidharan Karicheri m-kariche...@ti.com
Updated based on review comments
This patch adds a helper function to get description of a digital
video preset added by the video timing API. This will be usefull for drivers
implementing the above API.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
NOTE: depends on the patch that adds video timing API.
---
Applies to V4L-DVB linux-next branch
drivers/media/video/v4l2-common.c | 43 +
include/media/v4l2-common.h |7 ++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index f5a93ae..8b13d8e 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -1015,3 +1015,46 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin,
unsigned int wmax,
}
}
EXPORT_SYMBOL_GPL(v4l_bound_align_image);
+
+/**
+ * v4l_fill_dv_preset_info - fill description of a digital video preset
+ * @preset - preset value
+ * @info - pointer to struct v4l2_dv_enum_preset
+ *
+ * drivers can use this helper function to fill description of dv preset
+ * in info.
+ */
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset *info)
+{
+ static const struct v4l2_dv_preset_info dv_presets[] = {
+ {0, 0, Invalid},/* V4L2_DV_INVALID */
+ {720, 480, 4...@59.94},/* V4L2_DV_480P59_94 */
+ {720, 576, 5...@50},/* V4L2_DV_576P50 */
+ {1280, 720, 7...@24},/* V4L2_DV_720P24 */
+ {1280, 720, 7...@25},/* V4L2_DV_720P25 */
+ {1280, 720, 7...@30},/* V4L2_DV_720P30 */
+ {1280, 720, 7...@50},/* V4L2_DV_720P50 */
+ {1280, 720, 7...@59.94},/* V4L2_DV_720P59_94 */
+ {1280, 720, 7...@60},/* V4L2_DV_720P60 */
+ {1920, 1080, 10...@29.97},/* V4L2_DV_1080I29_97 */
+ {1920, 1080, 10...@30},/* V4L2_DV_1080I30 */
+ {1920, 1080, 10...@25},/* V4L2_DV_1080I25 */
+ {1920, 1080, 10...@50},/* V4L2_DV_1080I50 */
+ {1920, 1080, 10...@60},/* V4L2_DV_1080I60 */
+ {1920, 1080, 10...@24},/* V4L2_DV_1080P24 */
+ {1920, 1080, 10...@25},/* V4L2_DV_1080P25 */
+ {1920, 1080, 10...@30},/* V4L2_DV_1080P30 */
+ {1920, 1080, 10...@50},/* V4L2_DV_1080P50 */
+ {1920, 1080, 10...@60},/* V4L2_DV_1080P60 */
+ };
+
+ if (info == NULL || preset = ARRAY_SIZE(dv_presets))
+ return -EINVAL;
+
+ info-preset = preset;
+ info-width = dv_presets[preset].width;
+ info-height = dv_presets[preset].height;
+ strcpy(info-name, dv_presets[preset].name);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l_fill_dv_preset_info);
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 1c25b10..6ec9986 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -213,4 +213,11 @@ void v4l_bound_align_image(unsigned int *w, unsigned int
wmin,
unsigned int hmax, unsigned int halign,
unsigned int salign);
+struct v4l2_dv_preset_info {
+ u16 width;
+ u16 height;
+ const char *name;
+};
+
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset *info);
#endif /* V4L2_COMMON_H_ */
--
1.6.0.4
--
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: Details about DVB frontend API
Manu Abraham schrieb Not only is it time critical, but it should also be atomic, ie it should be all in one go, ie one single snapshot of an event, not events bunched together serially. Things wont seem that atomic on a system with a large load. Latency will have a significant effect on the statistics (values) read back, since it is again disjoint events. Right, the values should be treatened as a unique unit... Time stamping would be helpful, prior to any processing by the library such that the time overhead for the calculations is offset, but that can be really useful within the same library alone. I can't imagine how time stamping can be helpful to result a low latency. No, timestamping would of course not be helpful for reducing the latency, it would just allow to correctly interpret values if they are delayed. So that you won't assume the values you receive can be taken as proven for the current moment. If you don't have a low latency, Consider this (even when you are able to ignore the statistics for any general processing, on the thought that i can always live with those errors and i always had): The error fedback into the loop for a sat positioner/rotor. The final calculated position will never be the actual position that you wanted the antenna to be at a certain location. The problem would be made worser by the different rotor speeds as well, to add to the nightmare. With the V5 operation, you bunch operations together in a serial manner, it is atomic to the sense that it happens or doesn't happen, but it is not atomic to the sense of any particular time frame. You just keep your fingers crossed that the CPU executes the event in the shortest frame. This won't hold good in all cases when there is a high latency on the system when there is a significant load. eg: You can imagine an IPTV headend streaming data, with a small CPU with multiple tuners and trying to compensate the offset that's introduced. Still worser situation: imagine a gyro stabilized setup, where the base itself is not that stationary. Ok, thanks for the details about how V5 API deals with this. Indeed this is a major issue one has to think of when talking about signal statistics. Some other points to be considered: * As of now, the get/set interface is not used for any signal statistics * Even if one prefers to normalize all parameters into one single standard, even then you wouldn't land with a get/set interface. * The generic get/set interface is good when you have an unknown set of parameters, such that one can keep adding in parameters. Eg: most people favoured this approach when we had a larger set of modulations/ error correction and other parameters. For the case what we have currently, we do not have such a varied set of parameters to consider. Right, the situation about the parameters which will be requested in terms of signal statistics should not change for future frontend types, so it really should be a save approach to have a static API here. I have not yet done a very detailed look into your proposed patch, but I will do so tomorrow. I really would like to see a reliable statistics API in v4l-dvb soon. Regards, Julian -- 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: SV: [linux-dvb] NOVA-TD exeriences?
Soeren Moch schrieb:
Hi again. Just got my two new NOVA-TD's and at a first glance they
seemed to
perform well. Closer inspections however revealed that I see
exactly
the same
issues as Soeren. Watching live TV with VDR on one adaptor while
constantly
retuning the other one using:
while true;do tzap -x svt1;done
gives a short glitch in the VDR stream on almost every tzap.
Another
100EUR down
the drain. I'll probably buy four NOVA-T's instead just like I
planned to at
first.
/Magnus H
Slowly, slowly. Magnus, you want to support dibcom with another
100EUR for
there poor performance in fixing the firmware?
Please test my patches, the nova-td is running fine with these
patches,
at least for me.
Patrick, any progress here? Will dibcom fix the firmware, or will you
integrate the
patches? Or what can I do to go on?
Regards,
Soeren
Thanks Soeren, maybe I jumped to the wrong conclusions here. I actually
thought this came down to bad hardware design instead of a
driver/firmware
issue. Unfortunately your patches made no difference here but I won't
give
up that easily. If they made your problems disapperar there should be
hope
for me too and I'll be glad to help in the development. I can live
with the
glitches in the mean time if there's hope for improvement since I mostly
watch DVB-S these days. I'm running the stock Ubuntu Karmic 2.6.31
kernel
and standard linuxtv drivers from hg. I also have four TT S2-1600
cards in
there.
/Magnus
Magnus, can you send the USB-IDs of your nova-td-sticks, please?
Since I activated the workaround only for stk7700d_dib7000p_mt2266,
there might be another funtion to fix your sticks.
Soeren
OK, my nova-td device id is 2040:9580, for 2040:5200 the attached extended
patch version may help. (I have no access to such device.)
Please test.
Soeren
--- linux.orig/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-11-20 23:39:51.0 +0100
+++ linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-11-21 00:47:09.0 +0100
@@ -303,6 +303,9 @@ static int stk7700d_frontend_attach(stru
adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap,0x80+(adap-id 1),
stk7700d_dib7000p_mt2266_config[adap-id]);
+adap-props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap-fe == NULL ? -ENODEV : 0;
}
@@ -1710,12 +1713,20 @@ static int stk7070pd_frontend_attach0(st
}
adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap, 0x80, stk7070pd_dib7000p_config[0]);
+
+adap-props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap-fe == NULL ? -ENODEV : 0;
}
static int stk7070pd_frontend_attach1(struct dvb_usb_adapter *adap)
{
adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap, 0x82, stk7070pd_dib7000p_config[1]);
+
+adap-props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap-fe == NULL ? -ENODEV : 0;
}
@@ -1968,7 +1979,7 @@ MODULE_DEVICE_TABLE(usb, dib0700_usb_id_
.streaming_ctrl = dib0700_streaming_ctrl, \
.stream = { \
.type = USB_BULK, \
- .count = 4, \
+ .count = 1, \
.endpoint = ep, \
.u = { \
.bulk = { \
Re: [PATCH 0/6] DVB: firedtv: simplifications and a portability fix
On 18 Nov, Stefan Richter wrote: The following three patches are applicable after firedtv: port to new firewire core from 2009-11-08: ... The rest of this patch set additionally requires the latest firedtv as of 2.6.32-rc7: ... I updated the firedtv branch at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git firedtv now (based on v2.6.31 but having a merge from v2.6.32-rc8 in it due to above mentioned requirement). Mauro, please harvest the posted 4 + 6 patches from the mailing list, or pull or cherry-pick them from linux1394-2.6.git firedtv. Thanks. Stefan Richter (11): firedtv: move remote control workqueue handling into rc source file firedtv: reform lock transaction backend call firedtv: add missing include, rename a constant firedtv: port to new firewire core firedtv: shrink buffer pointer table firedtv: packet requeuing is likely to succeed firedtv: remove an unnecessary function argument Merge tag 'v2.6.32-rc8' into firedtv firedtv: do not DMA-map stack addresses firedtv: remove check for interrupting signal firedtv: reduce memset()s drivers/media/dvb/firewire/Kconfig|7 +- drivers/media/dvb/firewire/Makefile |1 + drivers/media/dvb/firewire/firedtv-1394.c | 42 +- drivers/media/dvb/firewire/firedtv-avc.c | 566 +++-- drivers/media/dvb/firewire/firedtv-dvb.c | 16 +- drivers/media/dvb/firewire/firedtv-fw.c | 376 ++ drivers/media/dvb/firewire/firedtv-rc.c |2 + drivers/media/dvb/firewire/firedtv.h | 23 +- 8 files changed, 746 insertions(+), 287 deletions(-) -- Stefan Richter -=-==--= =-== =-=-= http://arcgraph.de/sr/ -- 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] em28xx: fix for Leadtek winfast tv usbii deluxe
Hi Magnus,
Am Freitag, den 13.11.2009, 09:48 +0100 schrieb Magnus Alm:
em28xx: fix for Leadtek winfast tv usbii deluxe
From: Magnus Alm magnus@gmail.com
This patch adds working:
Video and Sound for Television, Svideo and Composite.
Radio.
Stereo.
Also ir-remote for kernel 2.6.30 and higher.
Priority: high
diff -r 19c0469c02c3 linux/drivers/media/common/ir-keymaps.c
--- a/linux/drivers/media/common/ir-keymaps.c Sat Nov 07 15:51:01 2009 -0200
+++ b/linux/drivers/media/common/ir-keymaps.c Fri Nov 13 09:40:40 2009 +0100
@@ -3303,3 +3303,51 @@
.size = ARRAY_SIZE(ir_codes_gadmei_rm008z),
};
EXPORT_SYMBOL_GPL(ir_codes_gadmei_rm008z_table);
+
+/* Leadtek Winfast TV USB II Deluxe remote
+ Magnus Alm magnus@gmail.com
+ */
+static struct ir_scancode ir_codes_winfast_usbii_deluxe[] = {
+ { 0x62, KEY_0},
+ { 0x75, KEY_1},
+ { 0x76, KEY_2},
+ { 0x77, KEY_3},
+ { 0x79, KEY_4},
+ { 0x7a, KEY_5},
+ { 0x7b, KEY_6},
+ { 0x7d, KEY_7},
+ { 0x7e, KEY_8},
+ { 0x7f, KEY_9},
+
+ { 0x38, KEY_CAMERA},/* SNAPSHOT */
+ { 0x37, KEY_RECORD},/* RECORD */
+ { 0x35, KEY_TIME}, /* TIMESHIFT */
+
+ { 0x74, KEY_VOLUMEUP}, /* VOLUMEUP */
+ { 0x78, KEY_VOLUMEDOWN},/* VOLUMEDOWN */
+ { 0x64, KEY_MUTE}, /* MUTE */
+
+ { 0x21, KEY_CHANNEL}, /* SURF */
+ { 0x7c, KEY_CHANNELUP}, /* CHANNELUP */
+ { 0x60, KEY_CHANNELDOWN}, /* CHANNELDOWN */
+ { 0x61, KEY_LAST}, /* LAST CHANNEL (RECALL) */
+
+ { 0x72, KEY_VIDEO}, /* INPUT MODES (TV/FM) */
+
+ { 0x70, KEY_POWER2},/* TV ON/OFF */
+
+ { 0x39, KEY_CYCLEWINDOWS}, /* MINIMIZE (BOSS) */
+ { 0x3a, KEY_NEW}, /* PIP */
+ { 0x73, KEY_ZOOM}, /* FULLSECREEN */
+
+ { 0x66, KEY_INFO}, /* OSD (DISPLAY) */
+
+ { 0x31, KEY_DOT}, /* '.' */
+ { 0x63, KEY_ENTER}, /* ENTER */
+
+};
+struct ir_scancode_table ir_codes_winfast_usbii_deluxe_table = {
+ .scan = ir_codes_winfast_usbii_deluxe,
+ .size = ARRAY_SIZE(ir_codes_winfast_usbii_deluxe),
+};
+EXPORT_SYMBOL_GPL(ir_codes_winfast_usbii_deluxe_table);
diff -r 19c0469c02c3 linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Nov 07
15:51:01 2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Fri Nov 13
09:40:40 2009 +0100
@@ -466,21 +466,30 @@
.name = Leadtek Winfast USB II Deluxe,
.valid= EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
- .tda9887_conf = TDA9887_PRESENT,
+ .has_ir_i2c = 1,
+ .tvaudio_addr = 0x58,
+ .tda9887_conf = TDA9887_PRESENT |
+ TDA9887_PORT2_ACTIVE |
+ TDA9887_QSS,
just on a first look, where you have this TDA9887_QSS from?
It should still be int and qss is default.
Also TDA9887_PORT2_ACTIVE is default on this tuner since some years.
Cheers,
Hermann
.decoder = EM28XX_SAA711X,
+ .adecoder = EM28XX_TVAUDIO,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
- .vmux = SAA7115_COMPOSITE2,
- .amux = EM28XX_AMUX_VIDEO,
+ .vmux = SAA7115_COMPOSITE4,
+ .amux = EM28XX_AMUX_AUX,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
- .vmux = SAA7115_COMPOSITE0,
+ .vmux = SAA7115_COMPOSITE5,
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_SVIDEO,
- .vmux = SAA7115_COMPOSITE0,
+ .vmux = SAA7115_SVIDEO3,
.amux = EM28XX_AMUX_LINE_IN,
} },
+ .radio= {
+ .type = EM28XX_RADIO,
+ .amux = EM28XX_AMUX_AUX,
+ }
},
[EM2820_BOARD_VIDEOLOGY_20K14XUSB] = {
.name = Videology 20K14XUSB USB2.0,
@@ -2309,9 +2318,12 @@
return;
}
#else
+ /* Leadtek winfast tv USBII deluxe can find a non working IR-device */
+ /* at address 0x18, so if that address is needed for another board in */
+ /* the future, please put it after 0x1f. */
struct i2c_board_info info;
const unsigned short addr_list[] = {
- 0x30, 0x47, I2C_CLIENT_END
+ 0x1f, 0x30, 0x47, I2C_CLIENT_END
};
if (disable_ir)
@@ -2361,6 +2373,18 @@
dev-init_data.name = i2c IR (EM2840 Hauppauge);
Re: [PATCH] em28xx: fix for Leadtek winfast tv usbii deluxe
[...] diff -r 19c0469c02c3 linux/drivers/media/video/em28xx/em28xx-cards.c --- a/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Nov 07 15:51:01 2009 -0200 +++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Fri Nov 13 09:40:40 2009 +0100 @@ -466,21 +466,30 @@ .name = Leadtek Winfast USB II Deluxe, .valid= EM28XX_BOARD_NOT_VALIDATED, .tuner_type = TUNER_PHILIPS_FM1216ME_MK3, - .tda9887_conf = TDA9887_PRESENT, + .has_ir_i2c = 1, + .tvaudio_addr = 0x58, + .tda9887_conf = TDA9887_PRESENT | + TDA9887_PORT2_ACTIVE | + TDA9887_QSS, just on a first look, where you have this TDA9887_QSS from? It should still be int and qss is default. Also TDA9887_PORT2_ACTIVE is default on this tuner since some years. On a second fly over, TDA9887_QSS is not that wrong, but there is still a plan to remove card specific tda9887 settings from the driver entries, IIRC, all such was once planned to be even moved into user space. So repeating tuner defaults in driver specific card entries is not recommended. We have some very few hardware specific cases on which we don't know how to avoid it. Maybe I did not follow close enough, then please excuse, but I can't see for what you need anything else as TDA9887_PRESENT ? Cheers, Hermann -- 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] V4L/DVB: Fix test in copy_reg_bits()
Ah! Nice catch. Thank you, Roel. Mauro / Andrew, can one of you
please merge this? The driver hasn't changed, so it should go to Linus'
current tree and also stable, although it isn't crucial.
Signed-off-by: Michael Krufky mkru...@linuxtv.org
Roel Kluin wrote:
The reg_pair2[j].reg was tested twice.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
drivers/media/common/tuners/mxl5007t.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
I think this was intended?
diff --git a/drivers/media/common/tuners/mxl5007t.c
b/drivers/media/common/tuners/mxl5007t.c
index 2d02698..7eb1bf7 100644
--- a/drivers/media/common/tuners/mxl5007t.c
+++ b/drivers/media/common/tuners/mxl5007t.c
@@ -196,7 +196,7 @@ static void copy_reg_bits(struct reg_pair_t *reg_pair1,
i = j = 0;
while (reg_pair1[i].reg || reg_pair1[i].val) {
- while (reg_pair2[j].reg || reg_pair2[j].reg) {
+ while (reg_pair2[j].reg || reg_pair2[j].val) {
if (reg_pair1[i].reg != reg_pair2[j].reg) {
j++;
continue;
--
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: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
Hi, Devin, Patrick. Am Freitag, den 20.11.2009, 06:31 -0500 schrieb Devin Heitmueller: On Fri, Nov 20, 2009 at 2:45 AM, Patrick Boettcher pboettc...@kernellabs.com wrote: According to DiBcom's contact at Pinnacle, it was a mistake to add the Product IDs with Pinnacle's USB vendor ID and it needed to be replaced. I'd be not surprised if that is not correct and that you're right. I will fix it and will try to clarify the situation internally. Given the conflicting information, I have just sent an email to my PCTV contact asking for clarification. It's possible I somehow misinterpreted his previous response. Devin If there is eventually some information in the eeprom (?) about 310i saa713x devices, with and without LNA, please ask to let us know such too. Pinnacle has always been very helpful in the past. Can be seen with Gerd, getting the first hybrid on the saa7134 up. Cheers, Hermann -- 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] AVerTV MCE 116 Plus radio
On Sun, 2009-10-11 at 04:01 +0300, Aleksandr V. Piskunov wrote:
On Tue, Oct 06, 2009 at 11:11:59AM +0300, Aleksandr V. Piskunov wrote:
On Tue, Oct 06, 2009 at 11:04:06AM +0300, Aleksandr V. Piskunov wrote:
Added FM radio support to Avermedia AVerTV MCE 116 Plus card
What leaves me puzzled, radio only works ok with ivtv newi2c=1
With default newi2c audio is tinny, metallic, with some strange static.
Similar problem with pvr-150 was reported years ago, guess issue is still
unresolved, perhaps something with cx25840..
This particular tinny audio problem is definitely I2C speed related, to be
more precise, audio only goes bad if i2c-algo-bit is being run with udelay
less than 15, i.e. i2c bus frequency is higher than 30 KHz.
So with default udelay=10 or udelay=5 (optimal for IR reciever on that board)
radio goes bad. Running with newi2c=1 is ok, but again it isn't optimal for IR
reciever on AVerTV M116.
I2C reads/writes to cx25840 themself are ok, verified using register readback
after each write/write4. Problem seems to be that with cx25840 register writes
coming too fast on higher i2c bus speed, switching register 0x808 _from_
TV standard autodetection mode (0xff) _to_ FM radio mode (0xf9) leaves chip
audio detection routine in inconsistent state.
The only solution I found is to do standard routine (assert_reset + write +
deassert_reset) followed by 50ms delay and another reset.
Following patch works_for_me, can be improved to only delay/doublereset when
really needed, etc. Andy, could you comment/review?
Aleksandr,
Could you provide your Signed-off-by for this patch? I'm going to
commit it as is.
Thanks,
Andy
diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c
b/linux/drivers/media/video/cx25840/cx25840-core.c
--- a/linux/drivers/media/video/cx25840/cx25840-core.c
+++ b/linux/drivers/media/video/cx25840/cx25840-core.c
@@ -626,7 +642,13 @@
if (state-radio) {
cx25840_write(client, 0x808, 0xf9);
cx25840_write(client, 0x80b, 0x00);
- }
+ /* Double reset cx2384x after setting FM radio mode, helps to
+avoid tinny audio when ivtv I2C bus is being run on
+frequency higher than 30 KHz */
+ cx25840_and_or(client, 0x810, ~0x01, 0);
+ msleep(50);
+ cx25840_and_or(client, 0x810, ~0x01, 1);
+ }
else if (std V4L2_STD_525_60) {
/* Certain Hauppauge PVR150 models have a hardware bug
that causes audio to drop out. For these models the
--
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
