Re: [linux-dvb] Does skystar dvb usb2 card work in linux ?
Hi Dominik, On Tue, 31 Mar 2009, Dominik Sito wrote: Tuesday 31 March 2009 19:39:28 a dehqan napisa?(a): In The Name Of God I'll be thankfull if you guide ; Does skystar dvb usb2 card work in linux ?Does it have linux driver ? has anyone tested it ? regards dehqan I think it's still undone. I have not clear information, but there would be any information about that. I'm not sure, but flexcop-usb isn't supported by USB 2.0. If i'm wrong please enlight me. Regards As of today there is no support for the USB2 version of Technisat's device. Technisat is not planning to add support, maybe they can't due to NDA(s) with their USB-2-PCI-bridge provider. I don't know for sure whether support can be added to the flexcop-usb.c-driver or not, but I assume not, because it is using a different USB-2-PCI-bridge and I have doubt that the USB high level interface is similar to the one used in flexcop-usb. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
Resubmit after code clean up.
This patch contains the unified driver for Legend Silicon LGS8913 and
LGS8GL5. It should replace lgs8gl5.c in media/dvb/frontends in the future.
Signed-off-by: David T.L. Wong davidtlw...@gmail.com
On Fri, Mar 27, 2009 at 5:57 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
On Tue, 17 Mar 2009 23:55:05 +0800
David Wong davidtlw...@gmail.com wrote:
+#undef USE_FAKE_SIGNAL_STRENGTH
Hmm... why do you need this upstream? Is the signal strength working? If so,
just remove this test code.
+
+static void lgs8gxx_auto_lock(struct lgs8gxx_state *priv);
I don't see why do you need to prototype this function.
+
+static int debug = 0;
Don't initialize static vars to zero. Kernel already does this, and static
initialization requires eats some space.
+static int lgs8gxx_set_fe(struct dvb_frontend *fe,
+ struct dvb_frontend_parameters *fe_params)
+{
+ struct lgs8gxx_state *priv = fe-demodulator_priv;
+
+ dprintk(%s\n, __func__);
+
+ /* set frequency */
+ if (fe-ops.tuner_ops.set_params) {
+ fe-ops.tuner_ops.set_params(fe, fe_params);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+ }
+
+ /* Hardcoded to use auto as much as possible */
+ fe_params-u.ofdm.code_rate_HP = FEC_AUTO;
+ fe_params-u.ofdm.guard_interval = GUARD_INTERVAL_AUTO;
+ fe_params-u.ofdm.transmission_mode = TRANSMISSION_MODE_AUTO;
Hmm... this is weird.
That's said, maybe you may need some DVBS2 API additions for DMB. You should
propose some API additions and provide a patch for it.
+ /* FEC. No exact match for DMB-TH, pick approx. value */
+ switch(t LGS_FEC_MASK) {
+ case LGS_FEC_0_4: /* FEC 0.4 */
+ translated_fec = FEC_1_2;
+ break;
+ case LGS_FEC_0_6: /* FEC 0.6 */
+ translated_fec = FEC_2_3;
+ break;
+ case LGS_FEC_0_8: /* FEC 0.8 */
+ translated_fec = FEC_5_6;
+ break;
+ default:
+ translated_fec = FEC_1_2;
+ }
Same here: if there's no exact match, we should first patch the core files to
improve the API, and then use the correct values.
+ fe_params-u.ofdm.code_rate_HP =
+ fe_params-u.ofdm.code_rate_LP = translated_fec;
The above seems weird. It would be better to do:
+ fe_params-u.ofdm.code_rate_HP = translated_fec;
+ fe_params-u.ofdm.code_rate_LP = translated_fec;
The gcc optimizer will produce the same code, but this way would be cleaner
for
those who are reading the source code.
+static
+int lgs8gxx_get_tune_settings(struct dvb_frontend *fe,
+ struct dvb_frontend_tune_settings *fesettings)
+{
+ /* FIXME: copy from tda1004x.c */
It would be nice if you fix those FIXME's.
+ fesettings-min_delay_ms = 800;
+ /* Drift compensation makes no sense for DVB-T */
DVB-T???
+static int lgs8gxx_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+ struct lgs8gxx_state *priv = fe-demodulator_priv;
+ u8 t;
+ *snr = 0;
+
+ lgs8gxx_read_reg(priv, 0x95, t);
+ dprintk(AVG Noise=0x%02X\n, t);
+ *snr = 256 - t;
+ *snr = 8;
+ dprintk(snr=0x%x\n, *snr);
+
+ return 0;
+}
I dunno if you are following all those discussions about SNR. We're trying to
standardize the meaning for all those status reads (SNR, signal strength, etc.
Nothing were decided yet, but while we don't take a decision, the better is if
you provide some comments at the source code specifying what's the unit for
each of those status (dB? 0.1 dB steps? dB * 256 ?).
+static struct dvb_frontend_ops lgs8gxx_ops = {
+ .info = {
+ .name = Legend Silicon LGS8913/LGS8GXX DMB-TH,
+ .type = FE_OFDM,
+ .frequency_min = 47400,
+ .frequency_max = 85800,
+ .frequency_stepsize = 1,
+ .caps =
+ FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
+ FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
+ FE_CAN_QPSK |
+ FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
+ FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO
+ },
Also here we should reflect the proper DMB parameters, after the API
additions.
---
Before submitting patches, please check they with checkpatch.pl ( see
http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches for the submission
procedures).
Please fix the CodingStyle errors detected by the tool:
ERROR: do not initialise statics to 0 or NULL
#91: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:43:
+static int debug = 0;
WARNING: printk() should include KERN_ facility level
#145: FILE: linux/drivers/media/dvb/frontends/lgs8gxx.c:97:
+ printk(%s: reg=0x%02X, data=0x%02X\n, __func__, reg, b1[0]);
ERROR: do not use C99
Re: [PATCH] Drivers for Pinnacle pctv200e and pctv60e
Hi all, On Wed, 1 Apr 2009, Gabriele Dini Ciacci wrote: While there are indeed drivers based on the same FX2 chip in your device, it may be possible to reuse an existing driver, or you may need a whole new driver, depending on how much the firmware varies between your product versus the others. You may want to look at the pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what similarities exist in terms of the API and command set. If it is not similar to any of the others, then writing a new driver is probably the correct approach. Regards, Devin Fine perfect, thanks, I will have a look asap and report for judge. I think you can save the time... When I started on a driver for those two devices 4 years ago, I had almost everything finished, but at that time we hadn't had a mt2060 driver available. I think I still have that driver somewhere, I'll check that and will send it to the list if I can find it. (at least the I2C-part was a little bit cleaner, IIRC). Gabriele, btw. there is nothing wrong with the I2C-address in your driver. setting 0x3e to the demod-address-field in the config-struct is totally fine. OTOH, your problem of unterstanding is most likely the notation used for i2c-addresses in linux: In Linux's drivers you'll find the 7-bit notation of the chip's i2c-address where as outside Linux, IMO, usually the 8-bit (wrong) notation is used: In the i2c-protocol the first byte of communication is the address plus a bit (the LSB) which is indicating wheter it is a read or write access. ie: AAAD, where A is address-bits and D is direction. In Linux what you'll see is e.g 0x1f which is the 7 bit address of 0x3e. The same for the tuner 0xc0 or 0xc2 is in Linux 0x60 and 0x61. Or the eeprom 0xa0 - 0x50 On the various USB-2-I2C interfaces most of the time the 8 bit notation is used, that why you'll have to shift the address 1 before filling the buffer in the i2c_transfer function. HTH, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] Remove support for Genpix-CW3K (damages hardware)
Hi Alan, On Tue, 31 Mar 2009, Alan Nisota wrote: I have been informed by the manufacturer that the patch currently in the v4l tree to support the Genpix-CW3K version of the hardware will actually damage the firmware on recent units. As he seems to not want this hardware supported in Linux, and I do not know how to detect the difference between affected and not-affected units, I am requesting the immediate removal of support for this device. This patch removes a portion of the changeset dce7e08ed2b1 applied 2007-08-18 relating to this specific device. Signed off by: Alan Nisota anis...@gmail.com Don't you think it is enough to put a Kconfig option to activate the USB-IDs (by default: off) rather than throwing everything away? Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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
tm6010 development repository
Hi Mauro, I've started trying to understand the code in the following repository: http://www.linuxtv.org/hg/~mchehab/tm6010/ I have a few patches I would like to apply. How should I do this? * Should I e-mail patches to you? * Should I find somewhere to host my repository and get you to pull them? If I need to host my repository do you have any suggestions as to where? Kevin -- 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] saa7134: Add analog RF tuner support for Avermedia A700 DVB-S Hybrid+FM card
On Sonntag, 29. März 2009, Matthias Schwarzott wrote: Hi list! The attached patch enables the XC2028 analog tuner used on the Avermedia A700 DVB-S Hybrid+FM card. As I only have a A700 DVB-S Pro card without this analog RF tuner, I would like to get feedback from owners of Avermedia A700 DVB-S Hybrid+FM cards if tv and or radio works fine or not. Regards Matthias -- 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 5 of 8] pvrusb2: use usb_interface.dev for v4l2_device_register
On Tue, 31 Mar 2009 21:02:16 -0500 (CDT)
Mike Isely is...@isely.net wrote:
This patch will not at all impact the operation of the pvrusb2 driver,
and if associating with the USB interface's device node is preferred
then I'm fine with it.
Acked-by: Mike Isely is...@pobox.com
Mauro: Is this series going to be pulled into v4l-dvb or shall I just
bring this one specific change into my pvrusb2 repo? Is there any
reason not to pull it?
I'll take care on it on the next time I'll apply patchwork patches. I suspect
that Janne preferred to send via email for people to better analyse the impacts.
-Mike
On Sun, 29 Mar 2009, Janne Grunau wrote:
# HG changeset patch
# User Janne Grunau j...@jannau.net
# Date 1238338428 -7200
# Node ID 2d52ac089920f9ac36960c0245442fd89a06bb75
# Parent 01af508490af3bc9c939c36001d6989e2c147aa0
pvrusb2: use usb_interface.dev for v4l2_device_register
Priority: normal
Signed-off-by: Janne Grunau j...@jannau.net
diff -r 01af508490af -r 2d52ac089920
linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
--- a/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c Sun Mar 29
16:53:48 2009 +0200
+++ b/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c Sun Mar 29
16:53:48 2009 +0200
@@ -2591,7 +2591,7 @@
hdw-ctl_read_urb = usb_alloc_urb(0,GFP_KERNEL);
if (!hdw-ctl_read_urb) goto fail;
- if (v4l2_device_register(usb_dev-dev, hdw-v4l2_dev) != 0) {
+ if (v4l2_device_register(intf-dev, hdw-v4l2_dev) != 0) {
pvr2_trace(PVR2_TRACE_ERROR_LEGS,
Error registering with v4l core, giving up);
goto fail;
--
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
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: Questinons regarding soc_camera / pxa_camera
Guennadi Liakhovetski schrieb: (moving to the new v4l list) On Thu, 26 Mar 2009, Stefan Herbrechtsmeier wrote: --- a/linux/drivers/media/video/soc_camera.cSun Mar 22 08:53:36 2009 -0300 +++ b/linux/drivers/media/video/soc_camera.cThu Mar 26 15:35:43 2009 +0100 @@ -238,7 +238,7 @@ static int soc_camera_init_user_formats( icd-num_user_formats = fmts; fmts = 0; -dev_dbg(icd-dev, Found %d supported formats.\n, fmts); +dev_dbg(icd-dev, Found %d supported formats.\n, icd-num_user_formats); /* Second pass - actually fill data formats */ for (i = 0; i icd-num_formats; i++) I thing this was wrong or ' fmts = 0;' must be under the output. Right, I'd prefer the latter though - to move the fmts = 0; assignment down. Should I generate a PATCH or will you change it by our own? @@ -675,8 +675,8 @@ static int soc_camera_cropcap(struct fil a-bounds.height= icd-height_max; a-defrect.left= icd-x_min; a-defrect.top= icd-y_min; -a-defrect.width= DEFAULT_WIDTH; -a-defrect.height= DEFAULT_HEIGHT; +a-defrect.width= icd-width_max; +a-defrect.height= icd-height_max; a-pixelaspect.numerator= 1; a-pixelaspect.denominator= 1; What was the reason to use fix values? Because of the current implementation of crop, the default value can get bigger than the max value. Yes, you're right again, taking scaling into account. Although, setting default to maximum doesn't seem a very good idea to me either. Maybe we'd have to add an extra parameter to struct soc_camera_device, but I'm somewhat reluctant to change this now, because all those fields from the struct will have to disappear anyway with the v4l2-subdev transition, at which point, I think, all these requests will have to be passed down to drivers. OK, what is the timetable / plan for the soc_camera to v4l2-subdev transition? Is there some ongoing work regarding the crop implementation on soc_camera? If I understand the documentation [1] right, the crop vales should represent the area of the capture device before scaling. What was the reason for the current implementation combing crop and fmt values? See this discussion: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/68 besides, my idea was, that the user cannot be bothered with all scalings / croppings that take place in host and client devices (on camera controllers and / or sensors). My understanding was: the user uses S_FMT to request a window of a certain size, say 640x480, the drivers shall try to fit as much into it as possible using scaling. How many hardware pixels are now used to build this VGA window the user has no idea about. If we use the real pixels for CROP, the user can calculate the scale. (see 1.11.3 Examples for Image Cropping, Insertion and Scaling in the documentation) Then you can use S_CROP to select sub-windows from _that_ area. If you want a different resolution, you use S_FMT again (after stopping the running capture), etc. Do you mean you can use S_CROP during a running capture? What happen if you change the width or height of the sub-windows. This will change the resolution / size of the image. I only know the camera driver side of this functions and don't know how it is used, but I would used S_FMT do set the output format and S_CROP to select the real sensor size and position. For example S_FMT with 320x240 set the sensor area to 1280x960 (max). S_CROP with 600x400 set the sensor area to 640x480, because this is the next supported scale (1,2,4,8) for the fix output format. If I understand the documentation right, S_CROP would use the old scale (4) and change the format to 200x100 to get the requested sensor area. I think for now I take over your implementation of S_FMT and S_CROP. After the v4l2-subdev transition we can update the implementations. Regards Stefan -- 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 0/3] FM Transmitter driver
Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Eduardo Valentin (3): FMTx: si4713: Add files to handle si4713 device FMTx: si4713: Add files to add radio interface for si4713 FMTx: si4713: Add Kconfig and Makefile entries drivers/media/radio/Kconfig| 12 + drivers/media/radio/Makefile |2 + drivers/media/radio/radio-si4713.c | 834 ++ drivers/media/radio/radio-si4713.h | 32 + drivers/media/radio/si4713.c | 2238 drivers/media/radio/si4713.h | 294 + 6 files changed, 3412 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/radio-si4713.c create mode 100644 drivers/media/radio/radio-si4713.h create mode 100644 drivers/media/radio/si4713.c create mode 100644 drivers/media/radio/si4713.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
[PATCH 3/3] FMTx: si4713: Add Kconfig and Makefile entries
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- drivers/media/radio/Kconfig | 12 drivers/media/radio/Makefile |2 ++ 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 3315cac..b7f9ab9 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -339,6 +339,18 @@ config RADIO_ZOLTRIX_PORT help Enter the I/O port of your Zoltrix radio card. +config I2C_SI4713 + tristate Silicon Labs Si4713 FM Radio Transmitter support + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 FM Radio Transmitter. + This device can transmit audio through FM. It can transmit + EDS and EBDS signals as well. This device driver supports only + i2c bus. + + To compile this driver as a module, choose M here: the + module will be called fmtx-si4713. + config USB_DSBR tristate D-Link/GemTek USB FM radio support depends on USB VIDEO_V4L2 diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile index 0f2b35b..3b1a4ec 100644 --- a/drivers/media/radio/Makefile +++ b/drivers/media/radio/Makefile @@ -15,6 +15,8 @@ obj-$(CONFIG_RADIO_ZOLTRIX) += radio-zoltrix.o obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o obj-$(CONFIG_RADIO_GEMTEK_PCI) += radio-gemtek-pci.o obj-$(CONFIG_RADIO_TRUST) += radio-trust.o +obj-$(CONFIG_I2C_SI4713) += fmtx-si4713.o +fmtx-si4713-objs := radio-si4713.o si4713.o obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o obj-$(CONFIG_USB_DSBR) += dsbr100.o obj-$(CONFIG_USB_SI470X) += radio-si470x.o -- 1.6.2.GIT -- 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 2/3] FMTx: si4713: Add files to add radio interface for si4713
This patch adds files which creates the radio interface
for si4713 FM transmitter devices.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
drivers/media/radio/radio-si4713.c | 834
drivers/media/radio/radio-si4713.h | 32 ++
2 files changed, 866 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/radio-si4713.c
create mode 100644 drivers/media/radio/radio-si4713.h
diff --git a/drivers/media/radio/radio-si4713.c
b/drivers/media/radio/radio-si4713.c
new file mode 100644
index 000..0a887a3
--- /dev/null
+++ b/drivers/media/radio/radio-si4713.c
@@ -0,0 +1,834 @@
+/*
+ * drivers/media/radio/radio-si4713.c
+ *
+ * Driver for I2C Silicon Labs Si4713 FM Radio Transmitter:
+ *
+ * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
+ * Author: Eduardo Valentin eduardo.valen...@indt.org.br
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/* driver definitions */
+#define DRIVER_AUTHOR Eduardo Valentin eduardo.valen...@indt.org.br
+#define DRIVER_NAME SI4713_NAME
+#define DRIVER_VERSION KERNEL_VERSION(0, 0, 1)
+#define DRIVER_CARD Silicon Labs Si4713 FM Radio Transmitter
+#define DRIVER_DESC I2C driver for Si4713 FM Radio Transmitter
+
+/* frequency domain transformation (using times 10 to avoid floats) */
+#define FREQDEV_UNIT 10
+#define FREQV4L2_MULTI 625
+#define dev_to_v4l2(f) ((f * FREQDEV_UNIT) / FREQV4L2_MULTI)
+#define v4l2_to_dev(f) ((f * FREQV4L2_MULTI) / FREQDEV_UNIT)
+
+/* kernel includes */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/version.h
+#include linux/interrupt.h
+#include linux/sysfs.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+
+#include radio-si4713.h
+#include si4713.h
+
+/* module parameters */
+static int radio_nr = -1; /* radio device minor (-1 == auto assign) */
+
+/*
+ * Sysfs properties
+ * Read and write functions
+ */
+#define property_write(prop, type, mask, check)
\
+static ssize_t si4713_##prop##_write(struct device *dev, \
+ struct device_attribute *attr, \
+ const char *buf,\
+ size_t count) \
+{ \
+ struct si4713_device *sdev = dev_get_drvdata(dev); \
+ type value; \
+ int rval; \
+ \
+ if (!sdev) \
+ return -ENODEV; \
+ \
+ sscanf(buf, mask, value); \
+ \
+ if (check) \
+ return -EDOM; \
+ \
+ rval = si4713_set_##prop(sdev, value); \
+ \
+ return rval 0 ? rval : count; \
+}
+
+#define property_read(prop, size, mask)
\
+static ssize_t si4713_##prop##_read(struct device *dev,
\
+ struct device_attribute *attr, \
+ char *buf) \
+{ \
+ struct si4713_device *sdev = dev_get_drvdata(dev); \
+ size value; \
+ \
+ if (!sdev) \
+ return
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On Tue, 31 Mar 2009 23:10:45 +0300 Antti Palosaari cr...@iki.fi wrote: af9015: add support for AverMedia AVerTV Volar Black HD (A850) There were a small merge conflict on the last one, due to that patch you've sent me your ack: two #defines included at the same place. I solved it on the merge. Please check. 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/~dougsland/em28xx
On Tue, 31 Mar 2009 16:36:47 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Tue, Mar 31, 2009 at 4:24 PM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hello Mauro, Please pull from http://www.linuxtv.org/hg/~dougsland/em28xx for the following: - em28xx: convert to v4l2_subdev Thanks to Hans Verkuil hverk...@xs4all.nl for helping this conversion. Boards tested: - WinTV HVR-900 - PlayTV Box4 - SIIG AVTuner-PVR - Pixelview Prolink PlayTV USB 2.0 - Hauppauge WinTV HVR 850 - Pinnacle Dazzle DVC 90 - Pinnacle Dazzle DVC 101 - Pinnacle Dazzle DVC 107 - Gadmei UTV310 Changes: # linux/drivers/media/video/em28xx/em28xx-cards.c | 143 +++- # linux/drivers/media/video/em28xx/em28xx-core.c | 9 - # linux/drivers/media/video/em28xx/em28xx-i2c.c | 72 # linux/drivers/media/video/em28xx/em28xx-video.c | 78 ++--- # linux/drivers/media/video/em28xx/em28xx.h | 10 + Thanks, Douglas -- 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 Hello Douglas, This patch looks pretty good. My only comment is to ask that you please not mix large patches like this with whitespace changes in the same changeset. Yes, for large patches, it may valuable to split this into two patches. Every instance of code like the above requires me to look at it closely and make a determination whether the content *actually* changed. For such large patches, the better way for you to take a look is to patch your tree with the new patch, and call: hg extdiff -p kdiff3 Kdiff3 has some ways to not display whitespace/blank lines. It also works like a charm when a var is renamed. 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://linuxtv.org/hg/~anttip/af9015/
Mauro Carvalho Chehab wrote: On Tue, 31 Mar 2009 23:10:45 +0300 Antti Palosaari cr...@iki.fi wrote: af9015: add support for AverMedia AVerTV Volar Black HD (A850) There were a small merge conflict on the last one, due to that patch you've sent me your ack: two #defines included at the same place. I solved it on the merge. Please check. It is correct. Here is ack if needed. Acked-by: Antti Palosaari cr...@iki.fi regards Antti -- http://palosaari.fi/ -- 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 5 of 8] pvrusb2: use usb_interface.dev for v4l2_device_register
On Wed, Apr 01, 2009 at 06:37:18AM -0300, Mauro Carvalho Chehab wrote: On Tue, 31 Mar 2009 21:02:16 -0500 (CDT) Mike Isely is...@isely.net wrote: This patch will not at all impact the operation of the pvrusb2 driver, and if associating with the USB interface's device node is preferred then I'm fine with it. Acked-by: Mike Isely is...@pobox.com Thanks, added. Mauro: Is this series going to be pulled into v4l-dvb or shall I just bring this one specific change into my pvrusb2 repo? Is there any reason not to pull it? I'll take care on it on the next time I'll apply patchwork patches. You don't need to. My plan was to send a pull request once I have enough feedback. I should have said that in the intro mail. I suspect that Janne preferred to send via email for people to better analyse the impacts. Yes, exactly. Janne -- 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/~dougsland/em28xx
Hello Devin, On Tue, 31 Mar 2009 16:36:47 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: Hello Douglas, This patch looks pretty good. My only comment is to ask that you please not mix large patches like this with whitespace changes in the same changeset. It makes it much harder to review the patch when functional changes are accompanied by stuff like this: - *vfd = *template; - vfd-minor = -1; - vfd-parent = dev-udev-dev; - vfd-release = video_device_release; - vfd-debug = video_debug; + + *vfd = *template; + vfd-minor = -1; + vfd-v4l2_dev = dev-v4l2_dev; + vfd-release = video_device_release; + vfd-debug = video_debug; - -void em28xx_i2c_call_clients(struct em28xx *dev, unsigned int cmd, void *arg); void em28xx_do_i2c_scan(struct em28xx *dev); -int em28xx_i2c_register(struct em28xx *dev); -int em28xx_i2c_unregister(struct em28xx *dev); +int em28xx_i2c_register(struct em28xx *dev); +int em28xx_i2c_unregister(struct em28xx *dev); Every instance of code like the above requires me to look at it closely and make a determination whether the content *actually* changed. Ok, agreed. Thanks for reviewing! Cheers, Douglas -- 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
Where to get dvb-usb-dw2104.fw for TeVii S650
Hello list, where do I get the dvb-usb-dw2104.fw firmware-file for my TeVii S650? The driver-package downloadble from the manufacturer website ( http://tevii.com/support.html ) only contains dvb-fe-cx24116.fw, dvb-usb-s600.fw, and dvb-usb-s600.fw. The manufacturers driver is multiproto-based which is not what I want. The method described here: http://article.gmane.org/gmane.linux.drivers.dvb/44694 to get the firmware doesn't work anymore, the file has been removed. Any hints? Thanks in advance, Carsten -- 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://hg.jannau.net/v4l-dvb/
Mauro, Please pull from http://hg.jannau.net/v4l-dvb/ for the following 8 changesets: 01/08: v4l: use usb_interface for v4l2_device_register http://hg.jannau.net/v4l-dvbi?cmd=changeset;node=3d54e7da8077 02/08: cx231xx: use usb_interface.dev for v4l2_device_register http://hg.jannau.net/v4l-dvb?cmd=changeset;node=e474a093efdc 03/08: cx231xx: remove explicitly set v4l2_device.name http://hg.jannau.net/v4l-dvb?cmd=changeset;node=297b327d1f05 04/08: usbvision: use usb_interface.dev for v4l2_device_register http://hg.jannau.net/v4l-dvb?cmd=changeset;node=756481d43c2e 05/08: pvrusb2: use usb_interface.dev for v4l2_device_register http://hg.jannau.net/v4l-dvb?cmd=changeset;node=62b788811b17 06/08: au0828: use usb_interface.dev for v4l2_device_register http://hg.jannau.net/v4l-dvb?cmd=changeset;node=33810c734a0d 07/08: au0828: remove explicitly set v4l2_device.name and unused au0828_instance http://hg.jannau.net/v4l-dvb?cmd=changeset;node=12cad7ee9ede 08/08: w9968cf: use usb_interface.dev for v4l2_device_register http://hg.jannau.net/v4l-dvb?cmd=changeset;node=6872bf22ee49 Documentation/video4linux/v4l2-framework.txt|2 +- drivers/media/video/au0828/au0828-core.c|9 ++--- drivers/media/video/cx231xx/cx231xx-cards.c |4 +--- drivers/media/video/pvrusb2/pvrusb2-hdw.c |2 +- drivers/media/video/usbvision/usbvision-video.c |8 +--- drivers/media/video/w9968cf.c |2 +- 6 files changed, 11 insertions(+), 16 deletions(-) Thanks, Janne -- 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://linuxtv.org/hg/~anttip/af9015/
Antti Palosaari wrote: Hello Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: add new USB ID for KWorld DVB-T 395U af9015: fix second FE af9015: bug fix: stick does not work always when plugged Any news about the fate of mc44s803 support? Best regards. -- Roberto Ragusamail at robertoragusa.it -- 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: Where to get dvb-usb-dw2104.fw for TeVii S650
Am Wed, 1 Apr 2009 14:01:16 +0200 schrieb Carsten Meier c...@trexity.de: Hello list, where do I get the dvb-usb-dw2104.fw firmware-file for my TeVii S650? The driver-package downloadble from the manufacturer website ( http://tevii.com/support.html ) only contains dvb-fe-cx24116.fw, dvb-usb-s600.fw, and dvb-usb-s600.fw. The manufacturers driver is multiproto-based which is not what I want. The method described here: http://article.gmane.org/gmane.linux.drivers.dvb/44694 to get the firmware doesn't work anymore, the file has been removed. Any hints? Thanks in advance, Carsten -- 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 I actually meant: The driver-package downloadble from the manufacturer website ( http://tevii.com/support.html ) only contains dvb-fe-cx24116.fw, dvb-usb-s600.fw, and dvb-usb-s650.fw (650 not 600) I've found this thread: http://www.allrussian.info/thread.php?postid=1460227 Because I cannot speak any russian, I've auto-translated it with google. Am I right that it suggests to simply rename dvb-usb-s650.fw from the manufacturer to dvb-usb-dw2104.fw? Thanks, Carsten -- 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://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Hermann. On Thu, 12 Mar 2009 01:44:30 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi, Am Mittwoch, den 11.03.2009, 14:44 -0300 schrieb Douglas Schilling Landgraf: Hello, On Sun, 08 Mar 2009 01:45:36 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi! Am Samstag, den 07.03.2009, 19:19 -0500 schrieb Andy Walls: On Sat, 2009-03-07 at 19:06 -0500, Andy Walls wrote: On Sat, 2009-03-07 at 18:26 -0500, Devin Heitmueller wrote: On Sat, Mar 7, 2009 at 5:45 PM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - v4l2-apps/util: Add rewrite_eeprom tool Modules this script is known to work with: em28xx and saa7134 Thanks, Douglas -- Added to the same tree new version of script: - A few improvements to initial version of script - Added validations to avoid issues to users - Added a huge red warning message IMO, the current version will cover those suggestions. If not, please let me know. Thanks everyone, Douglas seems to be safe to me on the saa7134 driver, but those pointing to further risks are welcome. Good to know! The dual saa7134 PCI bridge devices in need of a correct eeprom are out of the game in the original dual/triple slots, even first and second bridge might be swapped compared to the m$ driver and so on. Those tools are around anyway, I remember the case of a manipulated eeprom we alredy had. (with one of Dmitry's devices, IIRC) On some mobo's with lots of saa713X devices the eeprom readout can be flaky sometimes. If it is only a single device likely the PSU is becoming faulty, just to remember to check against that too. If there is a known list of critical eeprom types and about cases we disabled the write protection, this would be good to know as well. Agreed. Thanks for your comments! Cheers, Douglas -- 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
soc_camera_open() not called
Hi, I'm trying to launch mx1_camera based on new v4l and soc-camera tree. After loading mx1_camera module, I see that .add callback is not called. In debug log I see that soc_camera_open() is not called too. What should call this function? Is this my driver problem? p.s. loading sensor driver does not change situation. -- 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: soc_camera_open() not called
Darius Augulis wrote: Hi, I'm trying to launch mx1_camera based on new v4l and soc-camera tree. After loading mx1_camera module, I see that .add callback is not called. In debug log I see that soc_camera_open() is not called too. What should call this function? Is this my driver problem? p.s. loading sensor driver does not change situation. -- 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 actually I thought about soc_camera_probe(), not soc_camera_open(). But the problem still the same. video_probe in my driver is not called. -- 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] Drivers for Pinnacle pctv200e and pctv60e
Hi,
On Wed, 1 Apr 2009, Gabriele Dini Ciacci wrote:
On Tue, 31 Mar 2009 17:51:23 -0400
Devin Heitmueller devin.heitmuel...@gmail.com wrote:
On Tue, Mar 31, 2009 at 5:35 PM, Gabriele Dini Ciacci
dark.schnei...@iol.it wrote:
I it's so, say me how to make or where to look to create a profile
for the existing driver.
I am willing to do the work.
(when I first wrote the driver to me it seemed that this was the
simplet way.
Meanwhile I will try to look at the Cypress FX2
As Michael Krufky pointed out to me off-list, I was not exactly
correct here.
While there are indeed drivers based on the same FX2 chip in your
device, it may be possible to reuse an existing driver, or you may
need a whole new driver, depending on how much the firmware varies
between your product versus the others. You may want to look at the
pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what
similarities exist in terms of the API and command set. If it is not
similar to any of the others, then writing a new driver is probably
the correct approach.
Regards,
Devin
Fine perfect, thanks,
Attached you can find my attempts from 2005. I2C should work, please
re-use this implementation as it nicely splits i2c_transfer from the rest
of the required functionality.
I think I still have the pctv 200e somewhere in a box... I may get it
back, undust it and try.
Patrick.
--
Mail: patrick.boettc...@desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch//* DVB USB compliant linux driver for the Pinnacle PCTV 200e DVB-T USB2.0
receiver.
*
* Copyright (C) 2005 Patrick Boettcher (patrick.boettc...@desy.de)
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the Free
* Software Foundation, version 2.
*
* see Documentation/dvb/README.dvb-usb for more information
*/
#ifndef _DVB_USB_PCTV_H_
#define _DVB_USB_PCTV_H_
#define DVB_USB_LOG_PREFIX pctv
#include dvb-usb.h
extern int dvb_usb_pctv_debug;
#define deb_info(args...) dprintk(dvb_usb_pctv_debug,0x01,args)
#define CMD_I2C_WRITE 0x01
/* out: addr 1 olen buf[olen]
* in: 0x00 */
#define CMD_I2C_READ 0x02
/* out: addr 1 olen ilen buf[olen]
* in: 0x00 buf[ilen] */
#define CMD_GPIO_TUNER 0x16
/* out: onoff
* in: 0x00 */
//#define CMD_STREAMING 0x18
/* out: onoff
* in: 0x00 */
#endif
/* DVB USB compliant linux driver for the Pinnacle PCTV 200e DVB-T USB2.0
receiver.
*
* Copyright (C) 2005 Patrick Boettcher (patrick.boettc...@desy.de)
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
Free
* Software Foundation, version 2.
*
* see Documentation/dvb/README.dvb-usb for more information
*/
#include pctv.h
#include mt352.h
/* debug */
int dvb_usb_pctv_debug;
module_param_named(debug,dvb_usb_pctv_debug, int, 0644);
MODULE_PARM_DESC(debug, set debugging level (1=debug (or-able)).
DVB_USB_DEBUG_STATUS);
static int pctv_msg(struct dvb_usb_device *d, u8 cmd,
u8 *wbuf, int wlen, u8 *rbuf, int rlen)
{
int ret;
u8 sndbuf[wlen+1],
rcvbuf[rlen+2];
memset(sndbuf,0,wlen+1);
sndbuf[0] = cmd;
memcpy(sndbuf[1],wbuf,wlen);
if ((ret = dvb_usb_generic_rw(d,sndbuf,wlen+1,rcvbuf,rlen+2,0)) 0)
return ret;
if (rcvbuf[0] != sndbuf[0] ||
rcvbuf[1] != 0x00)
err(probably a xfer error);
memcpy(rbuf,rcvbuf[2],rlen);
if (rlen 0)
deb_info(rbuf[0]: %x, rlen: %d\n,rbuf[0],rlen);
return 0;
}
static int pctv_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg msg[],int num)
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
static u8 obuf[255];
int i,read;;
if (down_interruptible(d-i2c_sem) 0)
return -EAGAIN;
if (num 2)
warn(more than 2 i2c messages at a time is not handled yet.
TODO.);
for (i = 0; i num; i++) {
read = i+1 num (msg[i+1].flags I2C_M_RD);
obuf[0] = msg[i].addr 1;
obuf[1] = msg[i].len;
/* read request */
if (read)
obuf[2] = msg[i+1].len;
memcpy(obuf[2+read],msg[i].buf,msg[i].len);
if (read)
pctv_msg(d,CMD_I2C_READ,obuf,msg[i].len+3,msg[i+1].buf,msg[i+1].len);
else
pctv_msg(d,CMD_I2C_WRITE,obuf,msg[i].len+2,NULL,0);
i += read;
}
up(d-i2c_sem);
return i;
}
static u32 pctv_i2c_func(struct i2c_adapter *adapter)
{
return I2C_FUNC_I2C;
}
static struct i2c_algorithm pctv_i2c_algo = {
.name = Pinnacle PCTV USB I2C algorithm,
.id= I2C_ALGO_BIT,
.master_xfer = pctv_i2c_xfer,
Driver for GL861+AF9003+MT2060]
Hello, I'm trying to write a linux driver for my A-Data DT1 USB2 DVB-T card. This card has the GL861+AF9003+MT2060 chips. I've the specification of AF9002/3/5 family, and there is a linux driver for AF9005 chip that is an USB back-end plus AF9003 front-end. There is already a front-end driver for AF9003 inside the AF9005 code (should be the file AF9005-fe.c in the linux kernel tree). The real problem is that i don't know how to perform the boot process because it is different from AF9005 and how to handle the chip GL861 +AF9003 together. I've seen the GL861 linux driver code. It is very simple and support only two commands_ C0 02 for reading 40 01 for writing Sniffing the USB data using windows driver I've discovered that the windows driver is using following commands: 40 01 40 03 40 05 c0 02 c0 08 I don't know what do they mean and how I should use it. Maybe with the GL861 specification I can understand. Sadly I've no specification for GL861. Also the commands '40 01' and 'c0 02' are used in a different way not foreseen from the GL861 driver (the GL861 driver support up to 2 bytes to write but I see more data to write). I'm trying to understand the USB data before to writing the GL861 code to handle the AF9003 front-end (demod). Could someone help me? Thanks Claudio -- 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: Driver for GL861+AF9003+MT2060]
C Khmer1 wrote: Hello, I'm trying to write a linux driver for my A-Data DT1 USB2 DVB-T card. This card has the GL861+AF9003+MT2060 chips. I've the specification of AF9002/3/5 family, and there is a linux driver for AF9005 chip that is an USB back-end plus AF9003 front-end. There is already a front-end driver for AF9003 inside the AF9005 code (should be the file AF9005-fe.c in the linux kernel tree). The real problem is that i don't know how to perform the boot process because it is different from AF9005 and how to handle the chip GL861 +AF9003 together. It is not mission impossible. Basically all chips are supported. The biggest you have to is split demodulator code to own module. Very similar situation is used by af9015+af9013. You can look example from there. I've seen the GL861 linux driver code. It is very simple and support only two commands_ C0 02 for reading 40 01 for writing Sniffing the USB data using windows driver I've discovered that the windows driver is using following commands: 40 01 40 03 40 05 c0 02 c0 08 4 x read and 2 x write. There is IR-table which can be uploaded to the gl861, since one or two commands are probably for that. Should be easy to detect, for example comparing IR-table from driver to data seen in sniffs. Other possibilities could be for example GPIO, streaming control, USB-controller register/memory read/write, eeprom... Look existing dvb-usb -drivers for some hints about used commands. I don't know what do they mean and how I should use it. First emulate as Windows driver does (seen from sniff). After you get picture you can test whether or not all commands are needed and what is effect of commands. For example remove one command and remote does not work = should be remote command. Maybe with the GL861 specification I can understand. Sadly I've no specification for GL861. DVB-USB -protocols are typically rather easy to reverse-engineer and guess. :) GL861 is one of the simplest ones. Also the commands '40 01' and 'c0 02' are used in a different way not foreseen from the GL861 driver (the GL861 driver support up to 2 bytes to write but I see more data to write). You should add multibyte i2c support then. Many existing drivers to see help. I'm trying to understand the USB data before to writing the GL861 code to handle the AF9003 front-end (demod). Could someone help me? There was someone else with similar device some months ago. Look ML archives and put your helping hands together. If you post one simple sniff to me I can try to look. regards Antti -- http://palosaari.fi/ -- 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: Questinons regarding soc_camera / pxa_camera
On Wed, 1 Apr 2009, Stefan Herbrechtsmeier wrote: Guennadi Liakhovetski schrieb: (moving to the new v4l list) On Thu, 26 Mar 2009, Stefan Herbrechtsmeier wrote: --- a/linux/drivers/media/video/soc_camera.cSun Mar 22 08:53:36 2009 -0300 +++ b/linux/drivers/media/video/soc_camera.cThu Mar 26 15:35:43 2009 +0100 @@ -238,7 +238,7 @@ static int soc_camera_init_user_formats( icd-num_user_formats = fmts; fmts = 0; -dev_dbg(icd-dev, Found %d supported formats.\n, fmts); +dev_dbg(icd-dev, Found %d supported formats.\n, icd-num_user_formats); /* Second pass - actually fill data formats */ for (i = 0; i icd-num_formats; i++) I thing this was wrong or ' fmts = 0;' must be under the output. Right, I'd prefer the latter though - to move the fmts = 0; assignment down. Should I generate a PATCH or will you change it by our own? Up to you. Patch is welcome. If you don't make one, I'll make it some time later with Reported-by: you. @@ -675,8 +675,8 @@ static int soc_camera_cropcap(struct fil a-bounds.height= icd-height_max; a-defrect.left= icd-x_min; a-defrect.top= icd-y_min; -a-defrect.width= DEFAULT_WIDTH; -a-defrect.height= DEFAULT_HEIGHT; +a-defrect.width= icd-width_max; +a-defrect.height= icd-height_max; a-pixelaspect.numerator= 1; a-pixelaspect.denominator= 1; What was the reason to use fix values? Because of the current implementation of crop, the default value can get bigger than the max value. Yes, you're right again, taking scaling into account. Although, setting default to maximum doesn't seem a very good idea to me either. Maybe we'd have to add an extra parameter to struct soc_camera_device, but I'm somewhat reluctant to change this now, because all those fields from the struct will have to disappear anyway with the v4l2-subdev transition, at which point, I think, all these requests will have to be passed down to drivers. OK, what is the timetable / plan for the soc_camera to v4l2-subdev transition? There's none. I have (almost) converted all currently in mainline drivers to the soc-camera as a platform device scheme, which is the first step of the conversion. I'll publish it then, so developers of other platforms and drivers could test it. Then I'll start the second step. Besides I'm constantly interrupted by other tasks, including the currently running merge window. So, on the one hand this work profits from me currently not having any paid job, on the other hand it suffers from me having to spend time looking for paid jobs:-) Is there some ongoing work regarding the crop implementation on soc_camera? If I understand the documentation [1] right, the crop vales should represent the area of the capture device before scaling. What was the reason for the current implementation combing crop and fmt values? See this discussion: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/68 besides, my idea was, that the user cannot be bothered with all scalings / croppings that take place in host and client devices (on camera controllers and / or sensors). My understanding was: the user uses S_FMT to request a window of a certain size, say 640x480, the drivers shall try to fit as much into it as possible using scaling. How many hardware pixels are now used to build this VGA window the user has no idea about. If we use the real pixels for CROP, the user can calculate the scale. (see 1.11.3 Examples for Image Cropping, Insertion and Scaling in the documentation) In the thread that I pointed you at there's a reply from Mauro, which, as far as we understood each other:-), confirms my understanding of format and cropping functionality. And to me it seems easier for the user to only work in one scale. But we can revisit this later, sure. Then you can use S_CROP to select sub-windows from _that_ area. If you want a different resolution, you use S_FMT again (after stopping the running capture), etc. Do you mean you can use S_CROP during a running capture? What happen if you change the width or height of the sub-windows. This will change the resolution / size of the image. I only know the camera driver side of this functions and don't know how it is used, but I would used S_FMT do set the output format and S_CROP to select the real sensor size and position. For example S_FMT with 320x240 set the sensor area to 1280x960 (max). Ok, you mean the user retrieves CROP capabilities, sees 1280x960 as max, selects scale 4 and hence an output window of 320x240: User requestSensor window Scale User window S_FMT(320x240) 1280x9604:1 320x240 S_CROP with 600x400 set the sensor
Re: soc_camera_open() not called
Darius Augulis augulis.dar...@gmail.com writes: Darius Augulis wrote: Hi, I'm trying to launch mx1_camera based on new v4l and soc-camera tree. After loading mx1_camera module, I see that .add callback is not called. In debug log I see that soc_camera_open() is not called too. What should call this function? Is this my driver problem? p.s. loading sensor driver does not change situation. Are you by any chance using last 2.6.29 kernel ? If so, would [1] be the answer to your question ? Cheers -- Robert [1] http://lkml.org/lkml/2009/3/24/625 -- 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: soc_camera_open() not called
Robert Jarzmik wrote: Darius Augulis augulis.dar...@gmail.com writes: Darius Augulis wrote: Hi, I'm trying to launch mx1_camera based on new v4l and soc-camera tree. After loading mx1_camera module, I see that .add callback is not called. In debug log I see that soc_camera_open() is not called too. What should call this function? Is this my driver problem? p.s. loading sensor driver does not change situation. Are you by any chance using last 2.6.29 kernel ? If so, would [1] be the answer to your question ? thanks. it means we should expect soc-camera fix for this? I'm using 2.6.29-git8, but seems it's not fixed yet. Cheers -- Robert [1] http://lkml.org/lkml/2009/3/24/625 -- 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: WARNINGS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Apr 1 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11341:4c7466ea8d64 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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 from this daily build 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
Re: [PATCH] Drivers for Pinnacle pctv200e and pctv60e
On Wed, 1 Apr 2009 17:27:04 +0200 (CEST) Patrick Boettcher patrick.boettc...@desy.de wrote: Hi, On Wed, 1 Apr 2009, Gabriele Dini Ciacci wrote: On Tue, 31 Mar 2009 17:51:23 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Tue, Mar 31, 2009 at 5:35 PM, Gabriele Dini Ciacci dark.schnei...@iol.it wrote: I it's so, say me how to make or where to look to create a profile for the existing driver. I am willing to do the work. (when I first wrote the driver to me it seemed that this was the simplet way. Meanwhile I will try to look at the Cypress FX2 As Michael Krufky pointed out to me off-list, I was not exactly correct here. While there are indeed drivers based on the same FX2 chip in your device, it may be possible to reuse an existing driver, or you may need a whole new driver, depending on how much the firmware varies between your product versus the others. You may want to look at the pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what similarities exist in terms of the API and command set. If it is not similar to any of the others, then writing a new driver is probably the correct approach. Regards, Devin Fine perfect, thanks, Attached you can find my attempts from 2005. I2C should work, please re-use this implementation as it nicely splits i2c_transfer from the rest of the required functionality. I think I still have the pctv 200e somewhere in a box... I may get it back, undust it and try. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ I had a quick look (1 min) and I think the interface is to port to the new style used. I can merge my version of the driver with your and get a final driver, indeed your i2c is much better, as I coded i2c as a i2c ignorant, so just copying from the other drivers. I will just take your implementation for that part. Thanks a lot for the i2c explanation, that explains! Now my view is much clearer. So what if I try to merge the two drivers to get a clean one, test them on pctv60e, you test them on pctv200e and... done! The cherry would be to spend some time on the IR also, but just wait to have a driver. Regards cheers, Gabriele -- 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://linuxtv.org/hg/~anttip/af9015/
On Wed, 01 Apr 2009 14:10:50 +0300 Antti Palosaari cr...@iki.fi wrote: Mauro Carvalho Chehab wrote: On Tue, 31 Mar 2009 23:10:45 +0300 Antti Palosaari cr...@iki.fi wrote: af9015: add support for AverMedia AVerTV Volar Black HD (A850) There were a small merge conflict on the last one, due to that patch you've sent me your ack: two #defines included at the same place. I solved it on the merge. Please check. It is correct. Here is ack if needed. Acked-by: Antti Palosaari cr...@iki.fi Thanks. In general, I just silently fix such commit troubles, but, as some dvb usb devices has a count number of items at their tables, it is better to double check, if we are not violating it. regards Antti 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: soc_camera_open() not called
Darius Augulis augulis.dar...@gmail.com writes: Darius Augulis wrote: Hi, I'm trying to launch mx1_camera based on new v4l and soc-camera tree. After loading mx1_camera module, I see that .add callback is not called. In debug log I see that soc_camera_open() is not called too. What should call this function? Is this my driver problem? p.s. loading sensor driver does not change situation. Are you by any chance using last 2.6.29 kernel ? If so, would [1] be the answer to your question ? [1] http://lkml.org/lkml/2009/3/24/625 thanks. it means we should expect soc-camera fix for this? I'm using 2.6.29-git8, but seems it's not fixed yet. No, I don't think so. The last time I checked there had to be an amendement to the patch which introduced the driver core regression, as it touches other areas as well (sound/soc and mtd from memory). I think Guennadi can confirm this, as he's the one who raised the issue in the first place. Cheers. -- Robert -- 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 review] radio-si470x: fix possible bug with freeing memory order
(add Mauro on c/c)
On Wed, Apr 1, 2009 at 9:36 PM, Tobias Lorenz tobias.lor...@gmx.net wrote:
Hi,
Hi :)
hey thanks. I appreciate and approve the patch.
Do I have to upload the patch and send Mauro a pull request or is this
already done?
Bye,
Toby
Well, as i understand that's to you or Mauro to decide.
On Wednesday 01 April 2009 02:01:04 Alexey Klimov wrote:
Hello, all
There is probably bug when cleanup occurs in si470x_usb_driver_probe.
We do kmalloc for radio-buffer and when it's fail we
kfree(radio-buffer). The same with si470x_get_all_registers() and
si470x_get_scratch_page_versions(). When this functions failed we go to
err_all and try to free radio-buffer before allocation memory for this.
--
Patch fixes cleanup procedure in si470x_usb_driver_probe. Add new label
err_video and change order of freeing memory.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
--
diff -r 5567e82c34a0 linux/drivers/media/radio/radio-si470x.c
--- a/linux/drivers/media/radio/radio-si470x.c Tue Mar 31 07:24:14 2009
-0300
+++ b/linux/drivers/media/radio/radio-si470x.c Wed Apr 01 03:48:31 2009
+0400
@@ -1687,7 +1687,7 @@
/* show some infos about the specific si470x device */
if (si470x_get_all_registers(radio) 0) {
retval = -EIO;
- goto err_all;
+ goto err_video;
}
printk(KERN_INFO DRIVER_NAME : DeviceID=0x%4.4hx ChipID=0x%4.4hx\n,
radio-registers[DEVICEID], radio-registers[CHIPID]);
@@ -1695,7 +1695,7 @@
/* get software and hardware versions */
if (si470x_get_scratch_page_versions(radio) 0) {
retval = -EIO;
- goto err_all;
+ goto err_video;
}
printk(KERN_INFO DRIVER_NAME
: software version %d, hardware version %d\n,
@@ -1728,7 +1728,7 @@
radio-buffer = kmalloc(radio-buf_size, GFP_KERNEL);
if (!radio-buffer) {
retval = -EIO;
- goto err_all;
+ goto err_video;
}
/* rds buffer configuration */
@@ -1750,8 +1750,9 @@
return 0;
err_all:
+ kfree(radio-buffer);
+err_video:
video_device_release(radio-videodev);
- kfree(radio-buffer);
err_radio:
kfree(radio);
err_initial:
--
Best regards, Klimov Alexey
--
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] Remove support for Genpix-CW3K (damages hardware)
Patrick Boettcher wrote: Hi Alan, Don't you think it is enough to put a Kconfig option to activate the USB-IDs (by default: off) rather than throwing everything away? We could, but honestly, there are likely few people using this device who don't have to patch their kernel anyway, and it is a trivial patch to apply. There have been 4 incarnations of the CW3K as the manufacturer has tried to actively make it not work in Linux (and users have found ways around that for each subsequent revision). When I created the patch, I was not aware that the developer would take this stance. Only the 1st batch of devices works with the existing code, and I'm not aware of any way to detect the device version. Given the manufacturer's stance and the potential to unknowingly damage the device (I've been informed that the manufacturer has stated that use of the Linux drivers with the CW3K will void any manufacturer's warranty), I would rather remove support for this piece of hardware outright. I believe the manufacturer still supports the 8PSK-USB and Skywalker1 versions of the hardware on Linux (plus a new Skywalker2 which requires a kernel patch to enable). -- 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] Revert V4L/DVB (10962): fired-avc: fix printk formatting warning.
Commit 34aecd2851bba5c2b7dae2f0dbe8e629b1c5e4ac was made obsolete and invalid by commit 40cf65d149053889c8876c6c2b4ce204fde55baa. Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de --- drivers/media/dvb/firewire/firedtv-avc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/firewire/firedtv-avc.c b/drivers/media/dvb/firewire/firedtv-avc.c index 12f7730..32526f1 100644 --- a/drivers/media/dvb/firewire/firedtv-avc.c +++ b/drivers/media/dvb/firewire/firedtv-avc.c @@ -151,7 +151,7 @@ static void debug_fcp(const u8 *data, int length) subunit_type = data[1] 3; subunit_id = data[1] 7; op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2]; - printk(KERN_INFO %ssu=%x.%x l=%zu: %-8s - %s\n, + printk(KERN_INFO %ssu=%x.%x l=%d: %-8s - %s\n, prefix, subunit_type, subunit_id, length, debug_fcp_ctype(data[0]), debug_fcp_opcode(op, data, length)); -- 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
[RFC] BKL in open functions in drivers
Hello, Few days ago Alessio Igor Boganiabog...@texware.it sent me patch that removes BKLs like lock/unlock_kernel() in open call and place mutex there in media/radio/radio-mr800.c. This patch broke the driver, so we figured out new approah. We added one more mutex lock that was used in open call. The patch is below: diff -r ffa5df73ebeb linux/drivers/media/radio/radio-mr800.c --- a/linux/drivers/media/radio/radio-mr800.c Fri Mar 13 00:43:34 2009 + +++ b/linux/drivers/media/radio/radio-mr800.c Thu Apr 02 00:40:56 2009 +0400 @@ -163,6 +163,7 @@ unsigned char *buffer; struct mutex lock; /* buffer locking */ + struct mutex open; int curfreq; int stereo; int users; @@ -570,7 +571,7 @@ struct amradio_device *radio = video_get_drvdata(video_devdata(file)); int retval; - lock_kernel(); + mutex_lock(radio-open); radio-users = 1; radio-muted = 1; @@ -580,7 +581,7 @@ amradio_dev_warn(radio-videodev-dev, radio did not start up properly\n); radio-users = 0; - unlock_kernel(); + mutex_unlock(radio-open); return -EIO; } @@ -594,7 +595,7 @@ amradio_dev_warn(radio-videodev-dev, set frequency failed\n); - unlock_kernel(); + mutex_unlock(radio-open); return 0; } @@ -735,6 +736,7 @@ radio-stereo = -1; mutex_init(radio-lock); + mutex_init(radio-open); video_set_drvdata(radio-videodev, radio); retval = video_register_device(radio-videodev, VFL_TYPE_RADIO, radio_nr); I tested such approach using stress tool that tries to open /dev/radio0 few hundred times. Looks fine. So, questions are: 1) What for is lock/unlock_kernel() used in open? 2) Can it be replaced by mutex, for example? Please, comments, exaplanations are more than welcome. Thanks, -- best regards, Klimov Alexey -- 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: soc_camera_open() not called
On Wed, 1 Apr 2009, Robert Jarzmik wrote: Darius Augulis augulis.dar...@gmail.com writes: Darius Augulis wrote: Hi, I'm trying to launch mx1_camera based on new v4l and soc-camera tree. After loading mx1_camera module, I see that .add callback is not called. In debug log I see that soc_camera_open() is not called too. What should call this function? Is this my driver problem? p.s. loading sensor driver does not change situation. Are you by any chance using last 2.6.29 kernel ? If so, would [1] be the answer to your question ? [1] http://lkml.org/lkml/2009/3/24/625 thanks. it means we should expect soc-camera fix for this? I'm using 2.6.29-git8, but seems it's not fixed yet. No, I don't think so. You're right. The last time I checked there had to be an amendement to the patch which introduced the driver core regression, as it touches other areas as well (sound/soc and mtd from memory). I think Guennadi can confirm this, as he's the one who raised the issue in the first place. If Darius had followed the thread you referred to he would have come down to this message http://lkml.org/lkml/2009/3/26/202 which provides a reply as to what should be fixed, and yes, Ming Lei has already provided a patch to fix this, it should hit mainstream... some time before -rc1. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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: About the radio-si470x driver for I2C interface
Hello On Tue, Mar 10, 2009 at 3:20 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Mon, 9 Mar 2009 23:33:38 +0100 Tobias Lorenz tobias.lor...@gmx.net wrote: Hi, The proper way is to break radio-si470x into two parts: - A i2c adapter driver (similar to what we have on cx88-i2c, for example, plus the radio part of cx88-video); - A radio driver (similar to tea5767.c). This way, the i2c driver can be used on designs that use a different i2c adapter. yes, this is why I already capsulated most of the USB functionality into own functions. I awaited that somewhen the si470x is used in the usual way by i2c. I'm not sure, if we should split the driver into three files (generic/common, usb, i2c) or just implement the new functionality within the same file using macros/defines. It is better to split. It will provide more flexibility. Tobias, Joonyoung Is there any success on this ? Hi, I have tried, but could not do it yet. Like radio-tea5764.c, radio-si470x driver for I2C interface also was implemented as the I2C driver, but it has many redundant functions with the existing radio-si470x for USB interface, so I tried to join two interfaces but it was a difficult work. I have never seen the linux device driver probing more than one interface optionally. -- Joonyoung Shim -- Best regards, Klimov Alexey -- 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
Broken ioctls for the mpeg encoder on the HVR-1800
Hello, With the cx23885 driver that shipped with 2.6.29, as well as the latest hg driver, the analog mpeg encoder device for the HVR-1800 does not respond to the VIDIOC_QUERYCAP ioctl, returning ENOTTY. This ioctl previously worked with the driver in 2.6.28. The preview device does respond to the ioctl properly, and I am able to tune and set the input via the preview device. I can also capture MPEG using a simple cat /dev/video1 out.mpg. Are the ioctls supposed to work on the mpeg device, or should it be tuned via the preview device only? Thanks, Joe Yasi -- 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
