Re: problems on soc-camera subsystem
Dear Guennadi:
Thanks for you help,now I think I can send emails to
linux-media@vger.kernel.org .there is still one thing I can not
understand.The
question is in the end of this email.
(3) There is a host only, so I think if there are two camera
sensors,when one sensor is working,another sensor will be poweroff and
can not be actived.The method to switch between them I think is to close
the sensor which is not in use.
Can you tell me whether the CEU can connect multiple sensors or not,If
yes,are there some restrictions?
It should work, yes. Currently soc-camera handles client devices (e.g.,
sensors) in the following way: first during probing it attaches each such
client device to the host, performs probing _and_ detaches it immediately.
Then at open() the same happens - only the respective sensor is attached
to the host, so, the CEU driver only has to deal with one sensor at a
time. Just make sure to not try to open both nodes at the same time.
If it supports multiple sensors ,what should I do?
Just that - write two independent sensor drivers and two platform data
blocks for them in your board file. Then open and operate each sensor
independently. You also might want to provide platform struct
soc_camera_link::power() and / or reset() callbacks.
You say soc_camera will attach each sensor in the probing,but I think
each time there is
only one sensor can register to soc_camera subsystem.look at the following
code:
struct i2c_board_info ov9640_info1=
{
};
struct soc_camera_link ov9640_link1=
{
.board_info=ov9640_info1,
..
};
struct platform_device ov9640_device1=
{
.name = soc-camera-pdrv,
.dev=
{
.platform_data = ov9640_link1,
}
};
struct i2c_board_info ov9640_info2=
{
};
struct soc_camera_link ov9640_link2=
{
.board_info=ov9640_info2,
..
};
struct platform_device ov9640_device2=
{
.name = soc-camera-pdrv,//the name is same to the ov_9640_device1.
.dev=
{
.platform_data = ov9640_link2,
}
};
There are two sensors,now I want they all exist in /dev after
linux system is
boot.can I do this? if yes I want to use platform_device_register()
twice.but this action is forbindden,because they have the same
platform name,so only one sensor can registered successfully.
On the other hand if I use soc_camera subsystem to register a
video device to let
system create a node in /dev,like /dev/video0 or /dev/video1.I must
call soc_camera_device_register() to register a soc_camera_device to
soc_camera,
then if there is a camera host is registered to soc_camera,the host
will call scan_add_host() to probe and attach each sensor,if host can
handle the sensor,
device_register() will be called,finally the probe function of
soc_camera bus--soc_camera_probe() will be called,in this function
a video device will be register to the system,and a device node will
be create in /dev if all information of the sensor is ok.
So if you want to register a video device and create a device
node in /dev using soc_camera,soc_camera_device_register() must be
called.But now the only way to call soc_camera_device_register() is
to register a platform device whose name is soc-pdrv.
Is my analysis right ?
I do not want to use modle to load the driver,I want the two
sensors' device node can all exist in /dev directory after the system
is booted,what should I do.the kernel vesion I used is 2.6.36.Please
help me.
Thanks
LeMin.
--
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: problems on soc-camera subsystem
On Wed, 4 May 2011, ÀÖÃô wrote:
Dear Guennadi:
Thanks for you help,now I think I can send emails to
linux-media@vger.kernel.org .there is still one thing I can not
understand.The
question is in the end of this email.
(3) There is a host only, so I think if there are two camera
sensors,when one sensor is working,another sensor will be poweroff and
can not be actived.The method to switch between them I think is to close
the sensor which is not in use.
Can you tell me whether the CEU can connect multiple sensors or not,If
yes,are there some restrictions?
It should work, yes. Currently soc-camera handles client devices (e.g.,
sensors) in the following way: first during probing it attaches each such
client device to the host, performs probing _and_ detaches it immediately.
Then at open() the same happens - only the respective sensor is attached
to the host, so, the CEU driver only has to deal with one sensor at a
time. Just make sure to not try to open both nodes at the same time.
If it supports multiple sensors ,what should I do?
Just that - write two independent sensor drivers and two platform data
blocks for them in your board file. Then open and operate each sensor
independently. You also might want to provide platform struct
soc_camera_link::power() and / or reset() callbacks.
You say soc_camera will attach each sensor in the probing,but I think
each time there is
only one sensor can register to soc_camera subsystem.
Correct. During probing each client device will be attached to the host,
probed, and detached again.
look at the following
code:
struct i2c_board_info ov9640_info1=
{
};
struct soc_camera_link ov9640_link1=
{
.board_info=ov9640_info1,
..
};
struct platform_device ov9640_device1=
{
.name = soc-camera-pdrv,
.dev=
{
.platform_data = ov9640_link1,
}
};
struct i2c_board_info ov9640_info2=
{
};
struct soc_camera_link ov9640_link2=
{
.board_info=ov9640_info2,
..
};
struct platform_device ov9640_device2=
{
.name = soc-camera-pdrv,//the name is same to the
ov_9640_device1.
.dev=
{
.platform_data = ov9640_link2,
}
};
There are two sensors,now I want they all exist in /dev after
linux system is
boot.can I do this? if yes I want to use platform_device_register()
twice.but this action is forbindden,because they have the same
platform name,so only one sensor can registered successfully.
You should use different IDs. Look at arch/sh/boards/mach-migor/setup.c or
arch/arm/mach-mx3/mach-pcm037.c for examples.
On the other hand if I use soc_camera subsystem to register a
video device to let
system create a node in /dev,like /dev/video0 or /dev/video1.I must
call soc_camera_device_register() to register a soc_camera_device to
soc_camera,
then if there is a camera host is registered to soc_camera,the host
will call scan_add_host() to probe and attach each sensor,if host can
handle the sensor,
device_register() will be called,finally the probe function of
soc_camera bus--soc_camera_probe() will be called,in this function
a video device will be register to the system,and a device node will
be create in /dev if all information of the sensor is ok.
So if you want to register a video device and create a device
node in /dev using soc_camera,soc_camera_device_register() must be
called.But now the only way to call soc_camera_device_register() is
to register a platform device whose name is soc-pdrv.
Is my analysis right ?
I do not want to use modle to load the driver,I want the two
sensors' device node can all exist in /dev directory after the system
is booted,what should I do.the kernel vesion I used is 2.6.36.Please
help me.
Would also be good to use the current kernel version for any new
development. In my replies I'm targeting the newest kernel(s), and if you
encounter any problems / questions, specific to an older version, I am
afraid, I won't be able to help you. Also to mainline your work you'll
have to submit patches for the latest kernel.
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: [PATCH] Ngene cam device name
On 05/04/2011 01:11 AM, Mauro Carvalho Chehab wrote:
Em 24-04-2011 08:38, Issa Gorissen escreveu:
On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
Em 27-03-2011 21:44, Ralph Metzler escreveu:
Hi,
since I just saw cxd2099 appear in staging in the latest git kernel, a
simple question which has been pointed out to me before:
Why is cxd2099.c in staging regarding the device name question?
It has nothing to do with the naming.
It is not just because of naming. A NACK was given to it, as is, at:
http://www.spinics.net/lists/linux-media/msg28004.html
A previous discussion about this subject were started at:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
The point is that an interface meant to be used by satellite were
used as a ci interface, due to the lack of handling independent CA devices.
As there were no final decision about a proper way to address it, Oliver
decided to keep it as-is, and I decided to move it to staging while we
don't properly address the question, extending the DVB API in order to
support
independent CA devs.
Having the driver at staging allow us to rework at the API and change the
driver when API changes are done, without needing to pass through kernel
process of deprecating old API stuff.
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
Hello all,
Here is the patch for the NGene card family and the new caio device.
Can cxd2099 be removed from staging as this patch fixes the raised issue.
Signed-off-by: Issa Gorissen flo...@usa.net
---
drivers/media/dvb/dvb-core/dvbdev.c |2 +-
drivers/media/dvb/dvb-core/dvbdev.h |1 +
drivers/media/dvb/ngene/ngene-core.c |2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
b/drivers/media/dvb/dvb-core/dvbdev.c
index f732877..7a64b81 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
static const char * const dnames[] = {
video, audio, sec, frontend, demux, dvr, ca,
-net, osd
+net, osd, caio
};
There's no reason to keep sec.
#ifdef CONFIG_DVB_DYNAMIC_MINORS
diff --git a/drivers/media/dvb/dvb-core/dvbdev.h
b/drivers/media/dvb/dvb-core/dvbdev.h
index fcc6ae9..c63c70d 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -47,6 +47,7 @@
#define DVB_DEVICE_CA 6
#define DVB_DEVICE_NET7
#define DVB_DEVICE_OSD8
+#define DVB_DEVICE_CAIO 9
#define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
static short adapter_nr[] = \
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 175a0f6..17cdd38 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
set_transfer(chan-dev-channel[2], 1);
dvb_register_device(adapter, chan-ci_dev,
ngene_dvbdev_ci, (void *) chan,
-DVB_DEVICE_SEC);
+DVB_DEVICE_CAIO);
if (!chan-ci_dev)
goto err;
}
It is not that simple. The question is not just how to name the interface,
but that such interface will work on a different way than the current
ca interface.
In other words, the DVB API should clearly explain why this
interface is different, when it should be used and how.
Also, there's still no mapping between ca and caio devices. Imagine a
built-in descrambler ca0 and two CI slots ca1 and ca2.
ca0 won't get a caio device, at least for now.
ca1 and ca2 might or might not have a caio device.
If there is caio0, how am I supposed to know that it's related to ca1 or
ca2 (or ca0, if someone implements a caio device to bypass the software
demux to use a built-in descrambler)? You must not assume that there are
either none or two (or three) caio interfaces. You need to be able to
detect (or set up) the connection between the interfaces. Otherwise this
API will be a mess.
Regards,
Andreas
--
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
Current status report of mt9p031.
Hi,
for those interested on mt9p031 working on the Beagleboard xM. I
attach 2 patches here that must be applied to kernel-2.6.39-rc commit
e8dad69408a9812d6bb42d03e74d2c314534a4fa
These patches include a fix for the USB ethernet.
What currently works:
- Test suggested by Guennadi
(http://download.open-technology.de/BeagleBoard_xM-MT9P031/).
Known problems:
1. You might be required to create device node for the sensor manually:
mknod /dev/v4l-subdev8 c 81 15
chown root:video /dev/v4l-subdev8
2. Images captured seem to be too dull and dark. Values of pixels seem
always to low, it seems to me like MSB of each pixel were stuck at 0.
I hope someone can help here.
Thank you.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a45cd64..c437391 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -178,7 +178,7 @@ obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o
-obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \
+obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..eba2235 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -52,6 +52,7 @@
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include control.h
#define NAND_BLOCK_SIZE SZ_128K
@@ -273,6 +274,44 @@ static struct regulator_consumer_supply beagle_vsim_supply = {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +348,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +499,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -472,6 +522,7 @@ static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+// omap_register_i2c_bus(2, 100, NULL, 0);
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom));
@@ -598,6 +649,34 @@ static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+// #if 0
+ /* Camera - Parallel Data */
+ OMAP3_MUX(CAM_D0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D8, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D9, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D10,
Re: Current status report of mt9p031.
Hello Javier, 2011/5/4 javier Martin javier.mar...@vista-silicon.com: Hi, for those interested on mt9p031 working on the Beagleboard xM. I attach 2 patches here that must be applied to kernel-2.6.39-rc commit e8dad69408a9812d6bb42d03e74d2c314534a4fa These patches include a fix for the USB ethernet. What currently works: - Test suggested by Guennadi (http://download.open-technology.de/BeagleBoard_xM-MT9P031/). Known problems: 1. You might be required to create device node for the sensor manually: mknod /dev/v4l-subdev8 c 81 15 chown root:video /dev/v4l-subdev8 2. Images captured seem to be too dull and dark. Values of pixels seem always to low, it seems to me like MSB of each pixel were stuck at 0. I hope someone can help here. I once had a similar problem and found out that I had configured the shifter in the device-setup wrong. So 2 bits were shifted out and I had a dark image. best regards, Bastian Hecht Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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] mt9v022: fix pixel clock
Hi Teresa I'm adding Mauro to CC, because we were discussing adding these (this one and mt9m111) patches to .39. On Thu, 14 Apr 2011, Teresa Gámez wrote: The setup of the pixel clock is done wrong in the mt9v022 driver. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. This is not clearly described in the data sheet. I finally got round to test your patch on pcm037. But sorry, I cannot reproduce your success. What's even worth, your patch, if applied to the stock kernel, really messes up Bayer colours for me. With your patch alone I cannot select the Bayer filter starting pixel parameter to produce correct colours. Without your patch colours do not look very clean, that's true, but I always attributed it to some sensor fine-tuning issues. But at least they are correct. An easy way to test colours is to point the camera at the LED pair on the board - blinking red and constant green next to the ethernet port. You once mentioned, that in your BSP you have the SOCAM_SENSOR_INVERT_PCLK flag set in your platform data. Maybe you were testing with that one? Then yes, of course, you'd have to compensate it by inverting the bit in the sensor. In any case, your patch if applied alone, seems to break camera on pcm037. Am I missing something? Thanks Guennadi Tested on pcm037 and pcm027/pcm990. Signed-off-by: Teresa Gámez t.ga...@phytec.de --- drivers/media/video/mt9v022.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 6a784c8..dec2a69 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct soc_camera_device *icd, flags = soc_camera_apply_sensor_flags(icl, flags); - if (flags SOCAM_PCLK_SAMPLE_RISING) + if (flags SOCAM_PCLK_SAMPLE_FALLING) pixclk |= 0x10; if (!(flags SOCAM_HSYNC_ACTIVE_HIGH)) -- 1.7.0.4 --- 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] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org Also, there's still no mapping between ca and caio devices. Imagine a built-in descrambler ca0 and two CI slots ca1 and ca2. ca0 won't get a caio device, at least for now. ca1 and ca2 might or might not have a caio device. If there is caio0, how am I supposed to know that it's related to ca1 or ca2 (or ca0, if someone implements a caio device to bypass the software demux to use a built-in descrambler)? You must not assume that there are either none or two (or three) caio interfaces. You need to be able to detect (or set up) the connection between the interfaces. Otherwise this API will be a mess. Regards, Andreas To my understanding, in such a described case, - ca0 would be reached from /dev/dvb/adapter0/ca0 - ca[12], depending on if they are connected to the same physical adapter (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio devices. - If the 3 ca devices are on the same adapter, then the driver writer should take care of the order of the mapping so that ca1 always map caio1 and ca2/caio2, ...; and if this is not feasable, then the driver writer should span the ca/caio devices on different /dev/dvb/adapter folders. -- 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: cx88 sound does not always work (Re: [PATCH v2.6.38 resend 0/7] cx88 deadlock and data races)
Update: I noticed I was using the desktop kernel this time, and reinstalled the default kernel. The audio now works fine (once this patch is installed). Works every time. This rings a bell, like I've had to do this to a system in the past. I don't really understand what desktop vs default kernel would have an effect on the drivers - from what I can read there doesn't seem to be anything in there. On 02/05/11 19:40, linuxtv wrote: Card Hauppage HVR-1300 Does it show up - yes Does it work - yes. However when testing for audio, either via mythbackend or smplayer /dev/video1 I get no sound 75% of the time on a first run. Of that, 75% of the time if I run smplayer /dev/video1 a few times sound reappears and will stay there until a power off reboot. (Soft reboot will keep the sound on). 25% of the time I cannot get sound started at all. Either via smplayer, mplayer, mythbackend or v4lctl changes. Have I seen this reported ever? I saw something mentioned on a mailing list dated Aug 2010. But no resolution. Is it hardware ? I don't believe so, same hardware I have linux Suse 11.1 kernel 2.6.27 with custom built drivers from v4l (July 2009). This works 100%. Drivers I was using was the default from the kernel with 11.4 (below). I then switched to try the v4l media_build repository (plus your patch). Unfortunately I can't build the 2009 drivers to try that level out (too much has changed). Hope the information below is of use. Drivers used from the default SuSE build and also from the v4l media build. Linux pvr1 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 GNU/Linux (SuSE 11.4) 04:01.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (re$ Subsystem: Hauppauge computer works Inc. WinTV 88x Video [0070:9600] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at e400 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Unknown large resource type 04, will not decode more. Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx8800 04:01.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:88$ Subsystem: Hauppauge computer works Inc. WinTV 88x Audio [0070:9600] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1000ns min, 63750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at e500 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx88_audio 04:01.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:880$ Subsystem: Hauppauge computer works Inc. WinTV 88x MPEG Encoder [0070:9600] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1500ns min, 22000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at e600 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: cx88-mpeg driver manager dmesg extract [6.341606] tda9887 1-0043: creating new instance [6.341607] tda9887 1-0043: tda988[5/6/7] found [6.342842] tuner 1-0043: Tuner 74 found with type(s) Radio TV. [6.346330] tuner 1-0061: Tuner -1 found with type(s) Radio TV. [
Re: cx88 sound does not always work
(culling cc list) hubstar wrote: Update: I noticed I was using the desktop kernel this time, and reinstalled the default kernel. The audio now works fine (once this patch is installed). Works every time. This rings a bell, like I've had to do this to a system in the past. I don't really understand what desktop vs default kernel would have an effect on the drivers - from what I can read there doesn't seem to be anything in there. Alas, I don't even know who these desktop and default kernel fellows are. :) I'd suggest reporting to whoever supplied your kernel. Thanks for working to make Linux support hardware well. Regards, Jonathan -- 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] cx18: Clean up mmap() support for raw YUV
On Tuesday 3 May 2011, Andy Walls awa...@md.metrocast.net wrote: Simon, If these two changes are going in, please also bump the driver version to 1.5.0 in cx18-version.c. These changes are significant enough perturbation. End users are going to look to driver version 1.4.1 as the first version for proper analog tuner support of the HVR1600 model 74351. Mauro, Is cx18 v1.4.1 with HVR1600 model 74351 analog tuner support, without these mmap() changes going to be visible in kernel version .39 ? Mauro, If you're going to accept these two patches, would you mind bumping the version in cx18-version.c for me as you apply them, or would you prefer me to provide either an incremental patch or a new patch with the bump added? -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.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: cx88 sound does not always work
Will do , just for limited into Distro OpenSuSE though I think I've seen Ubuntu has it as well. desktop -- supposed to be more responsive to user (timer set to 1000hz + other tunings) default -- supposed to be better for server and others On 04/05/11 10:23, Jonathan Nieder wrote: (culling cc list) hubstar wrote: Update: I noticed I was using the desktop kernel this time, and reinstalled the default kernel. The audio now works fine (once this patch is installed). Works every time. This rings a bell, like I've had to do this to a system in the past. I don't really understand what desktop vs default kernel would have an effect on the drivers - from what I can read there doesn't seem to be anything in there. Alas, I don't even know who these desktop and default kernel fellows are. :) I'd suggest reporting to whoever supplied your kernel. Thanks for working to make Linux support hardware well. Regards, Jonathan -- 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] Ngene cam device name
On 05/04/2011 10:27 AM, Issa Gorissen wrote: From: Andreas Oberritter o...@linuxtv.org Also, there's still no mapping between ca and caio devices. Imagine a built-in descrambler ca0 and two CI slots ca1 and ca2. ca0 won't get a caio device, at least for now. ca1 and ca2 might or might not have a caio device. If there is caio0, how am I supposed to know that it's related to ca1 or ca2 (or ca0, if someone implements a caio device to bypass the software demux to use a built-in descrambler)? You must not assume that there are either none or two (or three) caio interfaces. You need to be able to detect (or set up) the connection between the interfaces. Otherwise this API will be a mess. Regards, Andreas To my understanding, in such a described case, - ca0 would be reached from /dev/dvb/adapter0/ca0 - ca[12], depending on if they are connected to the same physical adapter (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio devices. Of course I'm referring to devices connected to the same physical adapter. Otherwise they would all be called ca0. Device enumeration always starts at 0, for each adapter. What you're describing just doesn't make sense. - If the 3 ca devices are on the same adapter, then the driver writer should take care of the order of the mapping so that ca1 always map caio1 and ca2/caio2, ...; and if this is not feasable, then the driver writer should span the ca/caio devices on different /dev/dvb/adapter folders. You can't create caio1 without creating caio0 first. Of course, you could require driver writers to register those ca devices first that have caio devices. But that conflicts with other policies the driver author might already have chosen, e.g. to map the ca (descrambler) device numbers to demux and dvr numbers, which seems way more intuitive to me, because demux hardware usually comes with built-in descramblers. It's ugly to force random policies on drivers. Please create a proper interface instead! Last but not least, using a different adapter number wouldn't fit either, because a DVB adapter is supposed to - be one independent piece of hardware - provide at least a frontend and a demux device At least on embedded devices, it simply isn't feasible to copy a TS to userspace from a demux, just to copy it back to the kernel and again back to userspace through a caio device, when live streaming. But you may want to provide a way to use the caio device for offline-descrambling. Unless you want to force users to buy multiple modules and multiple subscriptions for a single receiver, which in turn would need multiple CI slots, you need a way to make sure caio can not be used during live streaming. If this dependency is between different adapters, then something is really, really wrong. Why don't you just create a new device, e.g. ciX, deprecate the use of caX for CI devices, inherit CI-related existing ioctls from the CA API, translate the existing read and write funtions to ioctls and then use read and write for TS I/O? IIRC, Ralph suggested something similar. I'm pretty sure this can be done without too much code and in a backwards compatible way. Regards, Andreas -- 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] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org Of course I'm referring to devices connected to the same physical adapter. Otherwise they would all be called ca0. Device enumeration always starts at 0, for each adapter. What you're describing just doesn't make sense. Yes indeed you're right, I answered too quickly. Last but not least, using a different adapter number wouldn't fit either, because a DVB adapter is supposed to - be one independent piece of hardware - provide at least a frontend and a demux device How would you support device like the Hauppauge WinTV-CI ? This one comes on a USB port and does not provide any frontend and demux device. At least on embedded devices, it simply isn't feasible to copy a TS to userspace from a demux, just to copy it back to the kernel and again back to userspace through a caio device, when live streaming. But you may want to provide a way to use the caio device for offline-descrambling. Unless you want to force users to buy multiple modules and multiple subscriptions for a single receiver, which in turn would need multiple CI slots, you need a way to make sure caio can not be used during live streaming. If this dependency is between different adapters, then something is really, really wrong. With the transmitted keys changed frequently (at least for viaccess), what's the point in supporting offline descrambling when it will not work reliably for all ? As for descrambling multiple tv channels from different transponders with only one cam, this is already possible. An example is what Digital Devices calls MTD (Multi Transponder Decrypting). But this is CAM dependent, some do not support it. Question is, where does this belong ? kernel or userspace ? Why don't you just create a new device, e.g. ciX, deprecate the use of caX for CI devices, inherit CI-related existing ioctls from the CA API, translate the existing read and write funtions to ioctls and then use read and write for TS I/O? IIRC, Ralph suggested something similar. I'm pretty sure this can be done without too much code and in a backwards compatible way. I'm open to this idea, but is there a consensus on this big API change ? (deprecating ca device) If yes, I will try to prepare something. -- 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] Ngene cam device name
From: Mauro Carvalho Chehab mche...@redhat.com It is not that simple. The question is not just how to name the interface, but that such interface will work on a different way than the current ca interface. In other words, the DVB API should clearly explain why this interface is different, when it should be used and how. Cheers, Mauro. Ok, please give me the location of the DVB API. Could not find it under the linux/Documentation folder. -- 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] stb0899: Fix not locking DVB-S transponder
stb0899: Fix not locking DVB-S transponder
When stb0899_check_data is entered, it could happen, that the data is
already locked and the data search looped. stb0899_check_data fails to
lock on a good frequency. stb0899_search_data uses an extrem big search
step and fails to lock.
The new code checks for lock before starting a new search.
The first read ignores the loop bit, for the case that the loop bit is
set during the search setup. I also added the msleep to reduce the
traffic on the i2c bus.
Resend, last version seems to be broken by email-client.
Johns
Signed-off-by: Lutz Sammer john...@gmx.net
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index 2da55ec..55f0c4e 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -338,36 +338,42 @@ static enum stb0899_status stb0899_check_data(struct
stb0899_state *state)
int lock = 0, index = 0, dataTime = 500, loop;
u8 reg;
- internal-status = NODATA;
+ reg = stb0899_read_reg(state, STB0899_VSTATUS);
+ lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
+ if ( !lock ) {
- /* RESET FEC*/
- reg = stb0899_read_reg(state, STB0899_TSTRES);
- STB0899_SETFIELD_VAL(FRESACS, reg, 1);
- stb0899_write_reg(state, STB0899_TSTRES, reg);
- msleep(1);
- reg = stb0899_read_reg(state, STB0899_TSTRES);
- STB0899_SETFIELD_VAL(FRESACS, reg, 0);
- stb0899_write_reg(state, STB0899_TSTRES, reg);
+ internal-status = NODATA;
- if (params-srate = 200)
- dataTime = 2000;
- else if (params-srate = 500)
- dataTime = 1500;
- else if (params-srate = 1500)
- dataTime = 1000;
- else
- dataTime = 500;
-
- stb0899_write_reg(state, STB0899_DSTATUS2, 0x00); /* force search loop
*/
- while (1) {
- /* WARNING! VIT LOCKED has to be tested before VIT_END_LOOOP
*/
- reg = stb0899_read_reg(state, STB0899_VSTATUS);
- lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
- loop = STB0899_GETFIELD(VSTATUS_END_LOOPVIT, reg);
+ /* RESET FEC*/
+ reg = stb0899_read_reg(state, STB0899_TSTRES);
+ STB0899_SETFIELD_VAL(FRESACS, reg, 1);
+ stb0899_write_reg(state, STB0899_TSTRES, reg);
+ msleep(1);
+ reg = stb0899_read_reg(state, STB0899_TSTRES);
+ STB0899_SETFIELD_VAL(FRESACS, reg, 0);
+ stb0899_write_reg(state, STB0899_TSTRES, reg);
- if (lock || loop || (index dataTime))
- break;
- index++;
+ if (params-srate = 200)
+ dataTime = 2000;
+ else if (params-srate = 500)
+ dataTime = 1500;
+ else if (params-srate = 1500)
+ dataTime = 1000;
+ else
+ dataTime = 500;
+
+ stb0899_write_reg(state, STB0899_DSTATUS2, 0x00); /* force
search loop */
+ while (1) {
+ /* WARNING! VIT LOCKED has to be tested before
VIT_END_LOOOP*/
+ reg = stb0899_read_reg(state, STB0899_VSTATUS);
+ lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
+ loop = STB0899_GETFIELD(VSTATUS_END_LOOPVIT, reg);
+
+ if (lock || (loop index) || (index dataTime))
+ break;
+ index++;
+ msleep(1);
+ }
}
if (lock) { /* DATA LOCK indicator */
Re: [PATCH] Ngene cam device name
Andreas Oberritter writes: - ca0 would be reached from /dev/dvb/adapter0/ca0 - ca[12], depending on if they are connected to the same physical adapter (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio devices. Of course I'm referring to devices connected to the same physical adapter. Otherwise they would all be called ca0. Device enumeration always starts at 0, for each adapter. What you're describing just doesn't make sense. Of course it does since it is not feasible to use the same adapter number even on the same card when it provides multi-standard frontends which share dvr and demux devices. E.g., frontend0 and frontend1 can belong to the same demod which can be DVB-C and -T (or other combinations, some demods can even do DVB-C/T/S2). frontend0 and frontend1 could then be DVB-C/T of demod 0 frontend2 and frontend3 would be DVB-C/T of demod 1. frontend4 might be a DVB-S frontend of demod 2, frontend5 DVB-S of demod 3. How do I know then which frontends belong to the 4 demux/dvr devices? Or is there a standard way this is supposed to be handled? There are no mechanism to connect a frontend with specific dvr or demux devices in the current API. But you demand it for the caio device. - If the 3 ca devices are on the same adapter, then the driver writer should take care of the order of the mapping so that ca1 always map caio1 and ca2/caio2, ...; and if this is not feasable, then the driver writer should span the ca/caio devices on different /dev/dvb/adapter folders. You can't create caio1 without creating caio0 first. Of course, you could require driver writers to register those ca devices first that have caio devices. But that conflicts with other policies the driver author might already have chosen, e.g. to map the ca (descrambler) device numbers to demux and dvr numbers, which seems way more intuitive to me, because demux hardware usually comes with built-in descramblers. A ca/caio pair is completely independent by design and should not get mixed with other devices. It's ugly to force random policies on drivers. Please create a proper interface instead! Then the whole API should first get proper interfaces. See above. Last but not least, using a different adapter number wouldn't fit either, because a DVB adapter is supposed to - be one independent piece of hardware - provide at least a frontend and a demux device If you only plug in CI adapter modules in the octopus cards there are no frontend and demux devices. So, should we invent frontend and demux devices so that we are allowed to use the DVB API? Or should we create a new independent API for this? Even if we copy 99% of the existing ca API? At least on embedded devices, it simply isn't feasible to copy a TS to userspace from a demux, just to copy it back to the kernel and again back to userspace through a caio device, when live streaming. Then do not use it on embedded devices. But this is how this hardware works and APIs will not change the hardware. But you may want to provide a way to use the caio device for offline-descrambling. Unless you want to force users to buy multiple modules and multiple subscriptions for a single receiver, which in turn would need multiple CI slots, you need a way to make sure caio can not be used during live streaming. If this dependency is between different adapters, then something is really, really wrong. What dependency are you talking about? Why don't you just create a new device, e.g. ciX, deprecate the use of caX for CI devices, inherit CI-related existing ioctls from the CA API, translate the existing read and write funtions to ioctls and then use read and write for TS I/O? IIRC, Ralph suggested something similar. I'm pretty sure this can be done without too much code and in a backwards compatible way. This would require changing all en50221 related user space code. I only mentioned it would have been nice to have it this way from the beginning. Now it would be too late since one usually gets loud screaming from everywhere if user space API changes (not extensions) are even thought about. -Ralph -- 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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
On 05/04/11 01:16, Mauro Carvalho Chehab wrote: Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flop.m@xxx wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. Can someone confirm that such patch would fix the issue? If so, please forward it in a way that it could be applied (patch is currently line-wrapped), and submit with some comments/description and your SOB. As the patch is currently broken, I'm just marking it as rejected at patchwork. Manu, Please take a look on this trouble report. Sorry, the things are mixed here. My patch (resend and hopefully this time not broken) handles only DVB-S transponders. The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz for me. But I have very weak receiption, Johns diff --git a/drivers/media/dvb/frontends/stb0899_drv.c b/drivers/media/dvb/frontends/stb0899_drv.c index 37a222d..7691282 100644 --- a/drivers/media/dvb/frontends/stb0899_drv.c +++ b/drivers/media/dvb/frontends/stb0899_drv.c @@ -1426,9 +1426,9 @@ static void stb0899_set_iterations(struct stb0899_state *state) if (iter_scale config-ldpc_max_iter) iter_scale = config-ldpc_max_iter; - reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); + reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); - stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); + stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); } static enum dvbfe_search stb0899_search(struct dvb_frontend *fe, struct dvb_frontend_parameters *p)
Re: [PATCH] cx18: Clean up mmap() support for raw YUV
Em 04-05-2011 06:32, Simon Farnsworth escreveu: On Tuesday 3 May 2011, Andy Walls awa...@md.metrocast.net wrote: Simon, If these two changes are going in, please also bump the driver version to 1.5.0 in cx18-version.c. These changes are significant enough perturbation. End users are going to look to driver version 1.4.1 as the first version for proper analog tuner support of the HVR1600 model 74351. Mauro, Is cx18 v1.4.1 with HVR1600 model 74351 analog tuner support, without these mmap() changes going to be visible in kernel version .39 ? Mauro, If you're going to accept these two patches, would you mind bumping the version in cx18-version.c for me as you apply them, or would you prefer me to provide either an incremental patch or a new patch with the bump added? Please, provide me a patch for it. I'm still stuck handling pending patches, as patchwork lost some stuff. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx18: Bump driver version to 1.5.0
To simplify maintainer support of this driver, bump the version to 1.5.0 - this will be the first version that is expected to support mmap() for raw video frames. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Mauro, This is an incremental patch to apply on top of my cleanup patch - if you would prefer a complete new patch with this squashed into the cleanup patch, just ask and it will be done. drivers/media/video/cx18/cx18-version.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/cx18/cx18-version.h b/drivers/media/video/cx18/cx18-version.h index 62c6ca2..cd189b6 100644 --- a/drivers/media/video/cx18/cx18-version.h +++ b/drivers/media/video/cx18/cx18-version.h @@ -24,8 +24,8 @@ #define CX18_DRIVER_NAME cx18 #define CX18_DRIVER_VERSION_MAJOR 1 -#define CX18_DRIVER_VERSION_MINOR 4 -#define CX18_DRIVER_VERSION_PATCHLEVEL 1 +#define CX18_DRIVER_VERSION_MINOR 5 +#define CX18_DRIVER_VERSION_PATCHLEVEL 0 #define CX18_VERSION __stringify(CX18_DRIVER_VERSION_MAJOR) . __stringify(CX18_DRIVER_VERSION_MINOR) . __stringify(CX18_DRIVER_VERSION_PATCHLEVEL) #define CX18_DRIVER_VERSION KERNEL_VERSION(CX18_DRIVER_VERSION_MAJOR, \ -- 1.7.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: [PATCH v4 3/3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
Hi Sylwester,
On Tuesday 03 May 2011 20:07:43 Sylwester Nawrocki wrote:
On 05/03/2011 11:16 AM, Laurent Pinchart wrote:
On Thursday 21 April 2011 17:21:04 Sylwester Nawrocki wrote:
[snip]
+ struct media_pad pads[CSIS_PADS_NUM];
+ struct v4l2_subdev sd;
+ struct platform_device *pdev;
+ struct resource *regs_res;
+ void __iomem *regs;
+ struct clk *clock[NUM_CSIS_CLOCKS];
+ int irq;
+ struct regulator *supply;
+ u32 flags;
+ /* Common format for the source and sink pad. */
+ const struct csis_pix_format *csis_fmt;
+ struct v4l2_mbus_framefmt mf[CSIS_NUM_FMTS];
As try formats are stored in the file handle, and as the formats on the
sink and source pads are identical, a single v4l2_mbus_framefmt will do
here.
Ok. How about a situation when the caller never provides a file handle?
Is it not supposed to happen?
Good question :-) The subdev pad-level operations have been designed with a
userspace interface in mind, so they require a file handle to store try the
formats (and crop rectangles).
For V4L2_SUBDEV_FORMAT_TRY, should set_fmt just abandon storing the format
and should get_fmt just return -EINVAL when passed fh == NULL ?
For such a simple subdev, that should work as a workaround, yes. You can use
it as a temporary solution at least.
Or should the host driver allocate the file handle just for the sake of
set_fmt/get_fmt calls (assuming that cropping ops are not supported
by the subdev) ?
That's another solution. We could also pass an internal structure that
contains formats and crop rectangles to the pad operations handlers, instead
of passing the whole file handle. Do you think that would be better ?
It's not my intention to create a broken implementation but it would
be nice to be able to drop functionality which would never be used.
As a note, I wanted to avoid bothering user space with setting up the MIPI
CSI receiver sub-device. There wouldn't be any gain from it, just more
things to care about for the applications.
Quoting one of your comments below,
x--- FIMC_0 (/dev/video1)
SENSOR - MIPI_CSIS --|
x--- FIMC_1 (/dev/video3)
How do you expect to configure the MIPI_CSIS block from the FIMC_0 and FIMC_1
blocks, without any help from userspace ? Conflicts will need to be handled,
and the best way to handle them is to have userspace configuring the MIPI_CSIS
explicitly.
Moreover I don't see a good usage for the stored TRY format (yet). So I
originally thought this subdev could be configurable by the host driver
which wouldn't provide a file handle.
[snip]
+#define csis_pad_valid(pad) (pad == CSIS_PAD_SOURCE || pad ==
CSIS_PAD_SINK) +
+static struct csis_state *sd_to_csis_state(struct v4l2_subdev *sdev)
+{
+ return container_of(sdev, struct csis_state, sd);
+}
+
+static const struct csis_pix_format *find_csis_format(
+ struct v4l2_mbus_framefmt *mf)
+{
+ int i = ARRAY_SIZE(s5pcsis_formats);
+
+ while (--i= 0)
I'm curious, why do you search backward instead of doing the usual
for (i = 0; i ARRAY_SIZE(s5pcsis_formats); ++i)
(in that case 'i' could be unsigned) ?
Perhaps doing it either way does not make any difference with the
toolchains we use, but the loops with test for 0 are supposed to be faster
on ARM.
I didn't know that. I wonder if it makes a real difference with gcc.
[snip]
+static void s5pcsis_try_format(struct v4l2_mbus_framefmt *mf)
+{
+ struct csis_pix_format const *csis_fmt;
+
+ csis_fmt = find_csis_format(mf);
+ if (csis_fmt == NULL)
+ csis_fmt =s5pcsis_formats[0];
+
+ mf-code = csis_fmt-code;
+ v4l_bound_align_image(mf-width, 1, CSIS_MAX_PIX_WIDTH,
+csis_fmt-pix_hor_align,
+ mf-height, 1, CSIS_MAX_PIX_HEIGHT, 1,
+0);
+}
+
+static int s5pcsis_set_fmt(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh, + struct v4l2_subdev_format
*fmt)
+{
+ struct csis_state *state = sd_to_csis_state(sd);
+ struct v4l2_mbus_framefmt *mf =fmt-format;
+ struct csis_pix_format const *csis_fmt = find_csis_format(mf);
+
+ v4l2_dbg(1, debug, sd, %s: %dx%d, code: %x, csis_fmt: %p\n,
+ __func__, mf-width, mf-height, mf-code, csis_fmt);
+
+ if (fmt-which == V4L2_SUBDEV_FORMAT_TRY) {
+ s5pcsis_try_format(mf);
You need to take the pad into account here. As you mention below, source
and sink formats are identical. When the user tries to set the source
format, the driver should just return the sink format without performing
any modification.
+ state-mf[CSIS_FMT_TRY] = *mf;
+ return 0;
+ }
+
+ /* Both source and sink pad have always same format. */
+ if (!csis_pad_valid(fmt-pad) ||
+ csis_fmt == NULL ||
+ mf-width CSIS_MAX_PIX_WIDTH ||
+ mf-height CSIS_MAX_PIX_HEIGHT ||
+
Re: [PATCH] cx18: Bump driver version to 1.5.0
Simon Farnsworth simon.farnswo...@onelan.co.uk wrote: To simplify maintainer support of this driver, bump the version to 1.5.0 - this will be the first version that is expected to support mmap() for raw video frames. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Mauro, This is an incremental patch to apply on top of my cleanup patch - if you would prefer a complete new patch with this squashed into the cleanup patch, just ask and it will be done. drivers/media/video/cx18/cx18-version.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/cx18/cx18-version.h b/drivers/media/video/cx18/cx18-version.h index 62c6ca2..cd189b6 100644 --- a/drivers/media/video/cx18/cx18-version.h +++ b/drivers/media/video/cx18/cx18-version.h @@ -24,8 +24,8 @@ #define CX18_DRIVER_NAME cx18 #define CX18_DRIVER_VERSION_MAJOR 1 -#define CX18_DRIVER_VERSION_MINOR 4 -#define CX18_DRIVER_VERSION_PATCHLEVEL 1 +#define CX18_DRIVER_VERSION_MINOR 5 +#define CX18_DRIVER_VERSION_PATCHLEVEL 0 #define CX18_VERSION __stringify(CX18_DRIVER_VERSION_MAJOR) . __stringify(CX18_DRIVER_VERSION_MINOR) . __stringify(CX18_DRIVER_VERSION_PATCHLEVEL) #define CX18_DRIVER_VERSION KERNEL_VERSION(CX18_DRIVER_VERSION_MAJOR, \ -- 1.7.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 Thanks Simon. Acked-by: Andy Walls awa...@md.metrocast.net Regards, Andy -- 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] Ngene cam device name
On 05/04/2011 01:20 PM, Ralph Metzler wrote: Andreas Oberritter writes: - ca0 would be reached from /dev/dvb/adapter0/ca0 - ca[12], depending on if they are connected to the same physical adapter (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio devices. Of course I'm referring to devices connected to the same physical adapter. Otherwise they would all be called ca0. Device enumeration always starts at 0, for each adapter. What you're describing just doesn't make sense. Of course it does since it is not feasible to use the same adapter number even on the same card when it provides multi-standard frontends which share dvr and demux devices. E.g., frontend0 and frontend1 can belong to the same demod which can be DVB-C and -T (or other combinations, some demods can even do DVB-C/T/S2). There's absolutely no need to have more than one frontend device per demod. Just add two commands, one to query the possible delivery systems and one to switch the system. Why would you need more than one device node at all, if you can only use one delivery system at a time? frontend0 and frontend1 could then be DVB-C/T of demod 0 frontend2 and frontend3 would be DVB-C/T of demod 1. frontend4 might be a DVB-S frontend of demod 2, frontend5 DVB-S of demod 3. How do I know then which frontends belong to the 4 demux/dvr devices? By configuration. Or is there a standard way this is supposed to be handled? Yes. Since ages. The ioctl is called DMX_SET_SOURCE. There are no mechanism to connect a frontend with specific dvr or demux devices in the current API. But you demand it for the caio device. See above. - If the 3 ca devices are on the same adapter, then the driver writer should take care of the order of the mapping so that ca1 always map caio1 and ca2/caio2, ...; and if this is not feasable, then the driver writer should span the ca/caio devices on different /dev/dvb/adapter folders. You can't create caio1 without creating caio0 first. Of course, you could require driver writers to register those ca devices first that have caio devices. But that conflicts with other policies the driver author might already have chosen, e.g. to map the ca (descrambler) device numbers to demux and dvr numbers, which seems way more intuitive to me, because demux hardware usually comes with built-in descramblers. A ca/caio pair is completely independent by design and should not get mixed with other devices. I guess you're right, but I'm questioning your design. It's ugly to force random policies on drivers. Please create a proper interface instead! Then the whole API should first get proper interfaces. See above. Already done. See above. Last but not least, using a different adapter number wouldn't fit either, because a DVB adapter is supposed to - be one independent piece of hardware - provide at least a frontend and a demux device If you only plug in CI adapter modules in the octopus cards there are no frontend and demux devices. So, should we invent frontend and demux devices so that we are allowed to use the DVB API? Of course, you shouldn't invent fake frontends. But, if you decide to plug a frontend into your octopus card later on, then the frontend device should appear under the same adapter number. Right? If the demux is hardware-based, then of course the device should be present, even if no frontend is connected. If it's software-based, it's probably a matter of choice. Or should we create a new independent API for this? Even if we copy 99% of the existing ca API? I already proposed an API that would integrate nicely into the status quo. At least on embedded devices, it simply isn't feasible to copy a TS to userspace from a demux, just to copy it back to the kernel and again back to userspace through a caio device, when live streaming. Then do not use it on embedded devices. But this is how this hardware works and APIs will not change the hardware. In a similar way, I could propose to not use vanilla kernels, if you don't want to come up with a good API. Anyway, my point was that there must be some kind of resource management between the data path used in live streaming applications (i.e. in kernel space) and the data path used for offline-descrambling (i.e. your caio device through userspace). How do you intend to implement resource management between multiple adapters? If a device appears to be independent of another device, because it has a different adapter number, then this device must not interfere with devices of other adapters. Maybe the Ngene CAM really is independent and can't be used without all the copying, but we're talking about the introduction of a new API here, and I hope that this API won't just work with this one device. But you may want to provide a
Re: [PATCH] Ngene cam device name
Andreas Oberritter writes: Of course it does since it is not feasible to use the same adapter number even on the same card when it provides multi-standard frontends which share dvr and demux devices. E.g., frontend0 and frontend1 can belong to the same demod which can be DVB-C and -T (or other combinations, some demods can even do DVB-C/T/S2). There's absolutely no need to have more than one frontend device per demod. Just add two commands, one to query the possible delivery systems and one to switch the system. Why would you need more than one device node at all, if you can only use one delivery system at a time? Maybe because there is no proper documentation for this. Or is there a standard way this is supposed to be handled? Yes. Since ages. The ioctl is called DMX_SET_SOURCE. This does make no sense regarding my question. There are no mechanism to connect a frontend with specific dvr or demux devices in the current API. But you demand it for the caio device. See above. Ok, wrong formulation. There is no API to indicate which can connect to which. A ca/caio pair is completely independent by design and should not get mixed with other devices. I guess you're right, but I'm questioning your design. How else can an independent CI interface be designed? And this is how the hardware is. I cannot change this in software. It's ugly to force random policies on drivers. Please create a proper interface instead! Then the whole API should first get proper interfaces. See above. Already done. See above. And no proper documentation. Of course, you shouldn't invent fake frontends. But, if you decide to plug a frontend into your octopus card later on, then the frontend device should appear under the same adapter number. Right? No, it does not right now. At least on embedded devices, it simply isn't feasible to copy a TS to userspace from a demux, just to copy it back to the kernel and again back to userspace through a caio device, when live streaming. Then do not use it on embedded devices. But this is how this hardware works and APIs will not change the hardware. In a similar way, I could propose to not use vanilla kernels, if you don't want to come up with a good API. Why? The driver works fine on top of vanilla kernels. I do not really care if the driver itself gets into the kernel anymore. -Ralph -- 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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
From: Lutz Sammer john...@gmx.net On 05/04/11 01:16, Mauro Carvalho Chehab wrote: Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flop.m@xxx wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. Can someone confirm that such patch would fix the issue? If so, please forward it in a way that it could be applied (patch is currently line-wrapped), and submit with some comments/description and your SOB. As the patch is currently broken, I'm just marking it as rejected at patchwork. Manu, Please take a look on this trouble report. Sorry, the things are mixed here. My patch (resend and hopefully this time not broken) handles only DVB-S transponders. The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz for me. But I have very weak receiption, Johns Thank you Johns, I got out of patience and reverted back to kernel 2.6.37. Added an amplifier on the line and repositionned my dish. It works now. But very difficult to get both Hotbird 6 and 9 sats! Maybe they transmit a weak signal ??? -- Issa -- 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] Ngene cam device name
Or is there a standard way this is supposed to be handled? Yes. Since ages. The ioctl is called DMX_SET_SOURCE. DMX_SET_SOURCE seems to not be implemented anywhere, all it does is return EINVAL. I also fail to find any useful documentation about what it is supposed to do. There are no mechanism to connect a frontend with specific dvr or demux devices in the current API. But you demand it for the caio device. I think there is currently no useful API to connect devices. Every few months there comes a new device which deprecates how I enumerate devices and determine types of FE's. The most useful way to query devices seems to be using HAL, and I think this is the correct way in Linux, but DVB-API may be lacking with providing the necessary information. Maybe this is the direction we should consider? Device names under /dev seem to be irrelevant nowadays. Best regards, Martin Vidovic -- 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] Ngene cam device name
On 05/04/2011 01:07 PM, Issa Gorissen wrote: From: Andreas Oberritter o...@linuxtv.org Of course I'm referring to devices connected to the same physical adapter. Otherwise they would all be called ca0. Device enumeration always starts at 0, for each adapter. What you're describing just doesn't make sense. Yes indeed you're right, I answered too quickly. Last but not least, using a different adapter number wouldn't fit either, because a DVB adapter is supposed to - be one independent piece of hardware - provide at least a frontend and a demux device How would you support device like the Hauppauge WinTV-CI ? This one comes on a USB port and does not provide any frontend and demux device. Yes, as an exception, this device indeed wouldn't have a frontend, because it doesn't exist physycally. It wouldn't have multiple adapters numbers either. At least on embedded devices, it simply isn't feasible to copy a TS to userspace from a demux, just to copy it back to the kernel and again back to userspace through a caio device, when live streaming. But you may want to provide a way to use the caio device for offline-descrambling. Unless you want to force users to buy multiple modules and multiple subscriptions for a single receiver, which in turn would need multiple CI slots, you need a way to make sure caio can not be used during live streaming. If this dependency is between different adapters, then something is really, really wrong. With the transmitted keys changed frequently (at least for viaccess), what's the point in supporting offline descrambling when it will not work reliably for all ? The reliability of offline descrambling depends on the network operators policy. So while it won't be useful for everybody in the world, it might well be useful to all customers of certain operators. As for descrambling multiple tv channels from different transponders with only one cam, this is already possible. An example is what Digital Devices calls MTD (Multi Transponder Decrypting). But this is CAM dependent, some do not support it. What's the point if it doesn't work reliably for everybody? ;-) Question is, where does this belong ? kernel or userspace ? I guess it depends on whether the remultiplexing takes place in hardware or software (remapping of PIDs and generation of the joined SI data). Why don't you just create a new device, e.g. ciX, deprecate the use of caX for CI devices, inherit CI-related existing ioctls from the CA API, translate the existing read and write funtions to ioctls and then use read and write for TS I/O? IIRC, Ralph suggested something similar. I'm pretty sure this can be done without too much code and in a backwards compatible way. I'm open to this idea, but is there a consensus on this big API change ? (deprecating ca device) If yes, I will try to prepare something. The existing API could be copied to linux/dvb/ci.h and then simplified and reviewed. - There's no need for a slot number. Just assign a device node to every CI slot. - CA_CI_PHYS is unused. - ci.h doesn't need CA_DESCR, CA_SC, ca_descr_info_t, ca_caps_t, ca_descr_t, ca_pid_t and accompanying ioctls. - ca_slot_info.type should be an enum instead of a bitmask. - ca_msg.index and ca_msg.type are probably unused - Instead of a fixed length array, ca_msg.msg might as well just be a pointer to a user allocated buffer - Then, CA_GET_MSG should use _IOWR, because the maximum length must be read inside the kernel. Btw., does the av7110 really support two distinct CI slots? Regards, Andreas -- 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] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org Last but not least, using a different adapter number wouldn't fit either, because a DVB adapter is supposed to - be one independent piece of hardware - provide at least a frontend and a demux device How would you support device like the Hauppauge WinTV-CI ? This one comes on a USB port and does not provide any frontend and demux device. Yes, as an exception, this device indeed wouldn't have a frontend, because it doesn't exist physycally. It wouldn't have multiple adapters numbers either. What do you mean by they shouldn't have mulitple adapters numbers ? Multiple WinTV-CI devices should have distinct node parents, ie /dev/dvb/adapter[01]/node With the transmitted keys changed frequently (at least for viaccess), what's the point in supporting offline descrambling when it will not work reliably for all ? The reliability of offline descrambling depends on the network operators policy. So while it won't be useful for everybody in the world, it might well be useful to all customers of certain operators. As for descrambling multiple tv channels from different transponders with only one cam, this is already possible. An example is what Digital Devices calls MTD (Multi Transponder Decrypting). But this is CAM dependent, some do not support it. What's the point if it doesn't work reliably for everybody? ;-) Well, isn't it easier to change a CAM than an operator ? For many of us in France/Belgium, you might even have no choice at all for the operator. Why don't you just create a new device, e.g. ciX, deprecate the use of caX for CI devices, inherit CI-related existing ioctls from the CA API, translate the existing read and write funtions to ioctls and then use read and write for TS I/O? IIRC, Ralph suggested something similar. I'm pretty sure this can be done without too much code and in a backwards compatible way. I'm open to this idea, but is there a consensus on this big API change ? (deprecating ca device) If yes, I will try to prepare something. The existing API could be copied to linux/dvb/ci.h and then simplified and reviewed. As I said, if you can create a consensus behind your idea, then I will try to prepare something. -- 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] Ngene cam device name
On 05/04/2011 04:05 PM, Issa Gorissen wrote: From: Andreas Oberritter o...@linuxtv.org It wouldn't have multiple adapters numbers either. What do you mean by they shouldn't have mulitple adapters numbers ? Multiple WinTV-CI devices should have distinct node parents, ie /dev/dvb/adapter[01]/node I wrote wouldn't, not shouldn't. I'm fine with it. With the transmitted keys changed frequently (at least for viaccess), what's the point in supporting offline descrambling when it will not work reliably for all ? The reliability of offline descrambling depends on the network operators policy. So while it won't be useful for everybody in the world, it might well be useful to all customers of certain operators. As for descrambling multiple tv channels from different transponders with only one cam, this is already possible. An example is what Digital Devices calls MTD (Multi Transponder Decrypting). But this is CAM dependent, some do not support it. What's the point if it doesn't work reliably for everybody? ;-) Well, isn't it easier to change a CAM than an operator ? For many of us in France/Belgium, you might even have no choice at all for the operator. Again it depends on the operator, whether getting a working CAM at all is possible, putting aside that there's no guarantee that it would work with MTD. But I really don't mind. See the smiley. I was just referring to your similar question. I wasn't going to tell that foo was better than or even related to bar, but just that foo is a good feature for many people. I also consider bar a good feature. Why don't you just create a new device, e.g. ciX, deprecate the use of caX for CI devices, inherit CI-related existing ioctls from the CA API, translate the existing read and write funtions to ioctls and then use read and write for TS I/O? IIRC, Ralph suggested something similar. I'm pretty sure this can be done without too much code and in a backwards compatible way. I'm open to this idea, but is there a consensus on this big API change ? (deprecating ca device) If yes, I will try to prepare something. The existing API could be copied to linux/dvb/ci.h and then simplified and reviewed. As I said, if you can create a consensus behind your idea, then I will try to prepare something. I don't think this is going to happen, as nobody really seems to care (me included). I was just pointing out ways that I consider more likely to succeed. Regards, Andreas -- 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] Ngene cam device name
On 05/04/2011 03:35 PM, Martin Vidovic wrote: Or is there a standard way this is supposed to be handled? Yes. Since ages. The ioctl is called DMX_SET_SOURCE. DMX_SET_SOURCE seems to not be implemented anywhere, all it does is return EINVAL. I also fail to find any useful documentation about what it is supposed to do. It is supposed to connect the TS output of frontend X to the TS input of demux Y. Whether you need to manually connect anything depends on your application and hardware environment. It's not required at all when using the software demux, which is what almost all in-tree drivers do. There are no mechanism to connect a frontend with specific dvr or demux devices in the current API. But you demand it for the caio device. I think there is currently no useful API to connect devices. Every few months there comes a new device which deprecates how I enumerate devices and determine types of FE's. Can you describe the most common problems? What do you mean by connecting? The most useful way to query devices seems to be using HAL, and I think this is the correct way in Linux, but DVB-API may be lacking with providing the necessary information. Maybe this is the direction we should consider? Device names under /dev seem to be irrelevant nowadays. I think in the long run we should look closely at how V4L2 is solving similar problems. Regards, Andreas -- 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] Ngene cam device name
From: Andreas Oberritter o...@linuxtv.org I don't think this is going to happen, as nobody really seems to care (me included). I was just pointing out ways that I consider more likely to succeed. Regards, Andreas If you don't care, why fueling all this fuss ??? -- 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 05/10] rc-core: add separate defines for protocol bitmaps and numbers
Em 28-04-2011 12:13, David Härdeman escreveu:
The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected. This patch tries
to separate the two in preparation for the following patches.
Signed-off-by: David Härdeman da...@hardeman.nu
Most of the patch is just renaming stuff. So, I'm commenting just the
rc-main.c/rc-map.h changes.
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 5b4422e..5a182b2 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -102,7 +102,7 @@ static struct rc_map_list empty_map = {
.map = {
.scan= empty,
.size= ARRAY_SIZE(empty),
- .rc_type = RC_TYPE_UNKNOWN, /* Legacy IR type */
+ .rc_type = RC_BIT_UNKNOWN, /* Legacy IR type */
.name= RC_MAP_EMPTY,
}
};
@@ -725,14 +725,17 @@ static struct {
u64 type;
char*name;
} proto_names[] = {
- { RC_TYPE_UNKNOWN, unknown },
- { RC_TYPE_RC5, rc-5 },
- { RC_TYPE_NEC, nec },
- { RC_TYPE_RC6, rc-6 },
- { RC_TYPE_JVC, jvc },
- { RC_TYPE_SONY, sony },
- { RC_TYPE_RC5_SZ, rc-5-sz },
- { RC_TYPE_LIRC, lirc },
+ { RC_BIT_OTHER, other },
+ { RC_BIT_RC5, rc-5 },
+ { RC_BIT_RC5X, rc-5-x},
+ { RC_BIT_RC5_SZ,rc-5-sz },
+ { RC_BIT_RC6, rc-6 },
+ { RC_BIT_JVC, jvc },
+ { RC_BIT_SONY12,sony12},
+ { RC_BIT_SONY15,sony15},
+ { RC_BIT_SONY20,sony20},
+ { RC_BIT_NEC, nec },
+ { RC_BIT_LIRC, lirc },
};
There are some API breakages on the above. We shouln't do it, except
if strictly required, and, if we'll do it, we need to do it via
Documentation/feature-removal-schedule.txt.
There are two types of breakages on the above:
1) the removal of unknown and sony types;
2) the behaviour change of rc-5 (that, currently, means
both rc-5 and rc-5x.
Also, while you've mapped rc5/sony variants, nec variants weren't mapped.
IMO, what we should do on the above is:
1) preserve the unknown;
2) use rc-5, sony, nec with the meaning that they will
enable all variants of those protocols;
3) add a new set of protocols to indicate subsets, like sony:20,
rc-5:normal, rc5:x, etc.
4) if you're changing the interface, please submit a patch also
to v4l-utils, adding a logic there to handle the changes.
#define PROTO_NONE none
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 9184751..2c68ca6 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -11,19 +11,36 @@
#include linux/input.h
-#define RC_TYPE_UNKNOWN 0
-#define RC_TYPE_RC5 (1 0) /* Philips RC5 protocol */
-#define RC_TYPE_NEC (1 1)
-#define RC_TYPE_RC6 (1 2) /* Philips RC6 protocol */
-#define RC_TYPE_JVC (1 3) /* JVC protocol */
-#define RC_TYPE_SONY (1 4) /* Sony12/15/20 protocol */
-#define RC_TYPE_RC5_SZ (1 5) /* RC5 variant used by
Streamzap */
-#define RC_TYPE_LIRC (1 30) /* Pass raw IR to lirc userspace */
-#define RC_TYPE_OTHER(1u 31)
+#define RC_TYPE_UNKNOWN 0 /* Protocol not known */
+#define RC_TYPE_OTHER0 /* Protocol known but
proprietary */
This change doesn't make sense: we should either remove other or use different
bits for different meanings. This is somewhat a mess currently, as there are, in
fact, 3 types of protocols:
1) reverse-engineered drivers, where developer didn't care to check
what was the used protocol. It is there due to legacy IR handlers,
added before rc-core. The better is to not accept this type anymore
for new devices;
2) Other protocols that don't match at the list of supported protocols.
Reserved for the cases were the developer took the care to check if
the protocol is not NEC/RC-5/... and didn't find any protocol that
matches;
3) Standard protocols with broken hardware. In general, keycode tables
with just 8 bits for RC-5 or NEC, because the hardware uses a cheap
uC (generally KS007 or similar) that only decodes the last 8 bits of
the protocol. As the developer didn't have a full IR decoder, he was
not able to fill the RC/NEC table with the IR address.
The problem with (2) is that it may reflect a temporary state where the protocol
is not yet known. After adding a protocol decoder for it, case (2) turns into
case (1).
So, maybe we can just merge (1) and
Re: [PATCH 00/10] rc-core: my current patchqueue
Em 29-04-2011 05:08, David Härdeman escreveu:
On Thu, 28 Apr 2011 21:13:22 +0100, Malcolm Priestley tvbox...@gmail.com
wrote:
On Thu, 2011-04-28 at 17:13 +0200, David Härdeman wrote:
The following series is what's in my current patch queue for rc-core.
It only been lightly tested so far and it's based on the for_v2.6.39
branch,
but I still wanted to send it to the list so that I can get some
feedback while
I refresh the patches to for_v2.6.40 and do more testing.
Patch [06/10] hasn't made it to gmane or spinics servers.
Looking through the postfix logs, vger.kernel.org did accept the mail. My
guess is that it wasn't distributed (or indexed) because of its size.
I've put patch 6/10 at http://david.hardeman.nu/rc-proto.patch for now,
and I've included the patch description inline below:
Big patches like that makes harder to comment. So, I'll just get one small
piece of the patch to add my comments.
Setting and getting keycodes in the input subsystem used to be done via
the EVIOC[GS]KEYCODE ioctl and unsigned int[2] (one int for scancode
and one for the keycode).
The interface has now been extended to use the EVIOC[GS]KEYCODE_V2 ioctl
which uses the following struct:
struct input_keymap_entry {
__u8 flags;
__u8 len;
__u16 index;
__u32 keycode;
__u8 scancode[32];
};
(scancode can of course be even bigger, thanks to the len member).
This patch changes how the input_keymap_entry struct is interpreted
by rc-core by casting it to rc_keymap_entry:
struct rc_scancode {
__u16 protocol;
__u16 reserved[3];
__u64 scancode;
}
struct rc_keymap_entry {
__u8 flags;
__u8 len;
__u16 index;
__u32 keycode;
union {
struct rc_scancode rc;
__u8 raw[32];
};
};
The u64 scancode member is large enough for all current protocols and it
would be possible to extend it in the future should it be necessary for
some exotic protocol.
The main advantage with this change is that the protocol is made explicit,
which means that we're not throwing away data (the protocol type) and that
it'll be easier to support multiple protocols with one decoder (think rc5
and rc5-streamzap).
Further down the road we should also have a way to report the protocol of
a received keypress to userspace.
Signed-off-by: David Härdeman da...@hardeman.nu
snip/
- rc_keydown(d-rc_dev, priv-rc_keycode, 0);
+ rc_keydown(d-rc_dev, RC_TYPE_NEC, priv-rc_keycode, 0);
I'm OK with a change like the above, as it allows having some sort of input raw
event
to describe the protocol type, helping, for example, to have an userspace
program that
will help people to create keytable maps.
snip/
diff --git a/drivers/media/rc/keymaps/rc-videomate-s350.c
b/drivers/media/rc/keymaps/rc-videomate-s350.c
index 26ca260..2f0ec1f 100644
--- a/drivers/media/rc/keymaps/rc-videomate-s350.c
+++ b/drivers/media/rc/keymaps/rc-videomate-s350.c
@@ -13,57 +13,56 @@
#include media/rc-map.h
static struct rc_map_table videomate_s350[] = {
- { 0x00, KEY_TV},
- { 0x01, KEY_DVD},
- { 0x04, KEY_RECORD},
- { 0x05, KEY_VIDEO}, /* TV/Video */
- { 0x07, KEY_STOP},
- { 0x08, KEY_PLAYPAUSE},
- { 0x0a, KEY_REWIND},
- { 0x0f, KEY_FASTFORWARD},
- { 0x10, KEY_CHANNELUP},
- { 0x12, KEY_VOLUMEUP},
- { 0x13, KEY_CHANNELDOWN},
- { 0x14, KEY_MUTE},
- { 0x15, KEY_VOLUMEDOWN},
- { 0x16, KEY_1},
- { 0x17, KEY_2},
- { 0x18, KEY_3},
- { 0x19, KEY_4},
- { 0x1a, KEY_5},
- { 0x1b, KEY_6},
- { 0x1c, KEY_7},
- { 0x1d, KEY_8},
- { 0x1e, KEY_9},
- { 0x1f, KEY_0},
- { 0x21, KEY_SLEEP},
- { 0x24, KEY_ZOOM},
- { 0x25, KEY_LAST}, /* Recall */
- { 0x26, KEY_SUBTITLE}, /* CC */
- { 0x27, KEY_LANGUAGE}, /* MTS */
- { 0x29, KEY_CHANNEL}, /* SURF */
- { 0x2b, KEY_A},
- { 0x2c, KEY_B},
- { 0x2f, KEY_CAMERA},/* Snapshot */
- { 0x23, KEY_RADIO},
- { 0x02, KEY_PREVIOUSSONG},
- { 0x06, KEY_NEXTSONG},
- { 0x03, KEY_EPG},
- { 0x09, KEY_SETUP},
- { 0x22, KEY_BACKSPACE},
- { 0x0c, KEY_UP},
- { 0x0e, KEY_DOWN},
- { 0x0b, KEY_LEFT},
- { 0x0d, KEY_RIGHT},
- { 0x11, KEY_ENTER},
- { 0x20, KEY_TEXT},
+ { RC_TYPE_UNKNOWN, RC_SCANCODE_UNKNOWN(0x00), KEY_TV},
+ { RC_TYPE_UNKNOWN, RC_SCANCODE_UNKNOWN(0x01), KEY_DVD},
+ { RC_TYPE_UNKNOWN, RC_SCANCODE_UNKNOWN(0x04), KEY_RECORD},
+ { RC_TYPE_UNKNOWN, RC_SCANCODE_UNKNOWN(0x05), KEY_VIDEO}, /*
TV/Video */
+ { RC_TYPE_UNKNOWN, RC_SCANCODE_UNKNOWN(0x07), KEY_STOP},
+ { RC_TYPE_UNKNOWN,
Re: [PATCH 07/10] rc-core: use the full 32 bits for NEC scancodes
Em 28-04-2011 12:13, David Härdeman escreveu:
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality.
This seems to be a good strategy. However, it breaks the existing NEC keymap
tables (/me is not considering patch 6/10 macros), and changes those keytables
on userspace. Not sure how to address this.
Comments?
Thanks,
Mauro.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/dvb/dvb-usb/af9015.c | 22 ++
drivers/media/rc/ir-nec-decoder.c | 28
include/media/rc-map.h | 11 +--
3 files changed, 19 insertions(+), 42 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 08975f3..4ee8bb7 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1034,7 +1034,8 @@ static int af9015_rc_query(struct dvb_usb_device *d)
if ((priv-rc_repeat != buf[6] || buf[0])
!memcmp(buf[12], priv-rc_last, 4)) {
deb_rc(%s: key repeated\n, __func__);
- rc_keydown(d-rc_dev, RC_TYPE_NEC, priv-rc_keycode, 0);
+ rc_keydown(d-rc_dev, RC_TYPE_NEC,
+RC_SCANCODE_NEC32(priv-rc_keycode), 0);
priv-rc_repeat = buf[6];
return ret;
}
@@ -1051,21 +1052,10 @@ static int af9015_rc_query(struct dvb_usb_device *d)
/* Remember this key */
memcpy(priv-rc_last, buf[12], 4);
- if (buf[14] == (u8) ~buf[15]) {
- if (buf[12] == (u8) ~buf[13]) {
- /* NEC */
- priv-rc_keycode = buf[12] 8 | buf[14];
- } else {
- /* NEC extended*/
- priv-rc_keycode = buf[12] 16 |
- buf[13] 8 | buf[14];
- }
- } else {
- /* 32 bit NEC */
- priv-rc_keycode = buf[12] 24 | buf[13] 16 |
- buf[14] 8 | buf[15];
- }
- rc_keydown(d-rc_dev, RC_TYPE_NEC, priv-rc_keycode, 0);
+ priv-rc_keycode = buf[12] 24 | buf[13] 16 |
+buf[14] 8 | buf[15];
+ rc_keydown(d-rc_dev, RC_TYPE_NEC,
+RC_SCANCODE_NEC32(priv-rc_keycode), 0);
} else {
deb_rc(%s: no key press\n, __func__);
/* Invalidate last keypress */
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index edd8543..0b1eef1 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -49,7 +49,6 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
struct nec_dec *data = dev-raw-nec;
u32 scancode;
u8 address, not_address, command, not_command;
- bool send_32bits = false;
if (!(dev-enabled_protocols RC_BIT_NEC))
return 0;
@@ -162,33 +161,14 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
command = bitrev8((data-bits 8) 0xff);
not_command = bitrev8((data-bits 0) 0xff);
- if ((command ^ not_command) != 0xff) {
- IR_dprintk(1, NEC checksum error: received 0x%08x\n,
-data-bits);
- send_32bits = true;
- }
-
- if (send_32bits) {
- /* NEC transport, but modified protocol, used by at
- * least Apple and TiVo remotes */
- scancode = data-bits;
- IR_dprintk(1, NEC (modified) scancode 0x%08x\n,
scancode);
- } else if ((address ^ not_address) != 0xff) {
- /* Extended NEC */
- scancode = address 16 |
-not_address 8 |
-command;
- IR_dprintk(1, NEC (Ext) scancode 0x%06x\n, scancode);
- } else {
- /* Normal NEC */
- scancode = address 8 | command;
- IR_dprintk(1, NEC scancode 0x%04x\n, scancode);
- }
+ scancode = address 24 | not_address 16 |
+command 8 | not_command;
+ IR_dprintk(1, NEC scancode 0x%08x\n, scancode);
if (data-is_nec_x)
data-necx_repeat = true;
- rc_keydown(dev, RC_TYPE_NEC, scancode, 0);
+ rc_keydown(dev, RC_TYPE_NEC, RC_SCANCODE_NEC32(scancode), 0);
data-state = STATE_INACTIVE;
return 0;
}
diff --git a/include/media/rc-map.h
Re: [PATCH 08/10] rc-core: merge rc5 and streamzap decoders
Em 28-04-2011 12:13, David Härdeman escreveu:
Now that the protocol is part of the scancode, it is pretty easy to merge
the rc5 and streamzap decoders. An additional advantage is that the decoder
is now stricter as it waits for the trailing silence before determining that
a command is a valid rc5/streamzap command (which avoids collisions that I've
seen with e.g. Sony protocols).
Makes sense for me.
(FYI, I probably won't be applying any patch after patch 6, due to dependency
issues).
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/Kconfig| 12 --
drivers/media/rc/Makefile |1
drivers/media/rc/ir-rc5-decoder.c | 51 ++
drivers/media/rc/ir-rc5-sz-decoder.c| 153
---
drivers/media/rc/keymaps/rc-streamzap.c |4 -
drivers/media/rc/rc-core-priv.h |8 --
drivers/media/rc/streamzap.c| 10 --
7 files changed, 31 insertions(+), 208 deletions(-)
delete mode 100644 drivers/media/rc/ir-rc5-sz-decoder.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 7f03142..7242b0d 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -75,18 +75,6 @@ config IR_SONY_DECODER
Enable this option if you have an infrared remote control which
uses the Sony protocol, and you need software decoding support.
-config IR_RC5_SZ_DECODER
- tristate Enable IR raw decoder for the RC-5 (streamzap) protocol
- depends on RC_CORE
- select BITREVERSE
- default y
-
- ---help---
-Enable this option if you have IR with RC-5 (streamzap) protocol,
-and if the IR is decoded in software. (The Streamzap PC Remote
-uses an IR protocol that is almost standard RC-5, but not quite,
-as it uses an additional bit).
-
config IR_LIRC_CODEC
tristate Enable IR to LIRC bridge
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index c6cfe70..2d9ddde 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o
obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
-obj-$(CONFIG_IR_RC5_SZ_DECODER) += ir-rc5-sz-decoder.o
obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
diff --git a/drivers/media/rc/ir-rc5-decoder.c
b/drivers/media/rc/ir-rc5-decoder.c
index ed726ca..159e57f 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -1,6 +1,7 @@
-/* ir-rc5-decoder.c - handle RC5(x) IR Pulse/Space protocol
+/* ir-rc5-decoder.c - decoder for RC5(x) and StreamZap protocols
*
* Copyright (C) 2010 by Mauro Carvalho Chehab mche...@redhat.com
+ * Copyright (C) 2010 by Jarod Wilson ja...@redhat.com
*
* 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
@@ -13,22 +14,21 @@
*/
/*
- * This code handles 14 bits RC5 protocols and 20 bits RC5x protocols.
- * There are other variants that use a different number of bits.
- * This is currently unsupported.
- * It considers a carrier of 36 kHz, with a total of 14/20 bits, where
- * the first two bits are start bits, and a third one is a filing bit
+ * This decoder handles the 14 bit RC5 protocol, 15 bit StreamZap protocol
+ * and 20 bit RC5x protocol.
*/
#include rc-core-priv.h
#define RC5_NBITS14
+#define RC5_SZ_NBITS 15
#define RC5X_NBITS 20
#define CHECK_RC5X_NBITS 8
#define RC5_UNIT 88 /* ns */
#define RC5_BIT_START(1 * RC5_UNIT)
#define RC5_BIT_END (1 * RC5_UNIT)
#define RC5X_SPACE (4 * RC5_UNIT)
+#define RC5_TRAILER (10 * RC5_UNIT) /* In reality, approx 100 */
enum rc5_state {
STATE_INACTIVE,
@@ -79,12 +79,15 @@ again:
data-state = STATE_BIT_START;
data-count = 1;
- /* We just need enough bits to get to STATE_CHECK_RC5X */
- data-wanted_bits = RC5X_NBITS;
decrease_duration(ev, RC5_BIT_START);
goto again;
case STATE_BIT_START:
+ if (!ev.pulse geq_margin(ev.duration, RC5_TRAILER, RC5_UNIT
/ 2)) {
+ data-state = STATE_FINISHED;
+ goto again;
+ }
+
if (!eq_margin(ev.duration, RC5_BIT_START, RC5_UNIT / 2))
break;
@@ -99,9 +102,7 @@ again:
if (!is_transition(ev, dev-raw-prev_ev))
break;
- if (data-count == data-wanted_bits)
- data-state = STATE_FINISHED;
- else if (data-count == CHECK_RC5X_NBITS)
Re: [PATCH 09/10] rc-core: lirc use unsigned int
Em 28-04-2011 12:13, David Härdeman escreveu:
Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.
Patch looked ok to me (except for one small issue - see bellow).
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/ene_ir.c|4 ++--
drivers/media/rc/ene_ir.h|2 +-
drivers/media/rc/ir-lirc-codec.c | 15 +--
drivers/media/rc/ite-cir.c |5 +
drivers/media/rc/mceusb.c| 10 --
drivers/media/rc/nuvoton-cir.c | 12 +++-
drivers/media/rc/rc-loopback.c | 13 +++--
drivers/media/rc/winbond-cir.c |6 +-
include/media/rc-core.h |2 +-
9 files changed, 25 insertions(+), 44 deletions(-)
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index 569b07b..2b1d2df 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -953,13 +953,13 @@ static void ene_set_idle(struct rc_dev *rdev, bool idle)
}
/* outside interface: transmit */
-static int ene_transmit(struct rc_dev *rdev, int *buf, u32 n)
+static int ene_transmit(struct rc_dev *rdev, unsigned *buf, unsigned n)
{
struct ene_device *dev = rdev-priv;
unsigned long flags;
dev-tx_buffer = buf;
- dev-tx_len = n / sizeof(int);
+ dev-tx_len = n;
That hunk seems wrong to me. Or is it a bug fix that you're solving?
dev-tx_pos = 0;
dev-tx_reg = 0;
dev-tx_done = 0;
diff --git a/drivers/media/rc/ene_ir.h b/drivers/media/rc/ene_ir.h
index 337a41d..017c209 100644
--- a/drivers/media/rc/ene_ir.h
+++ b/drivers/media/rc/ene_ir.h
@@ -235,7 +235,7 @@ struct ene_device {
bool tx_sample_pulse; /* current sample is pulse */
/* TX buffer */
- int *tx_buffer; /* input samples buffer*/
+ unsigned *tx_buffer;/* input samples buffer*/
int tx_pos; /* position in that bufer */
int tx_len; /* current len of tx buffer */
int tx_done;/* done transmitting */
diff --git a/drivers/media/rc/ir-lirc-codec.c
b/drivers/media/rc/ir-lirc-codec.c
index b4119f8..ac54139 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -103,19 +103,19 @@ static ssize_t ir_lirc_transmit_ir(struct file *file,
const char *buf,
{
struct lirc_codec *lirc;
struct rc_dev *dev;
- int *txbuf; /* buffer with values to transmit */
- int ret = 0;
+ unsigned int *txbuf; /* buffer with values to transmit */
+ ssize_t ret = 0;
size_t count;
lirc = lirc_get_pdata(file);
if (!lirc)
return -EFAULT;
- if (n % sizeof(int))
+ if (n sizeof(unsigned) || n % sizeof(unsigned))
return -EINVAL;
- count = n / sizeof(int);
- if (count LIRCBUF_SIZE || count % 2 == 0 || n % sizeof(int) != 0)
+ count = n / sizeof(unsigned);
+ if (count LIRCBUF_SIZE || count % 2 == 0)
return -EINVAL;
txbuf = memdup_user(buf, n);
@@ -129,7 +129,10 @@ static ssize_t ir_lirc_transmit_ir(struct file *file,
const char *buf,
}
if (dev-tx_ir)
- ret = dev-tx_ir(dev, txbuf, (u32)n);
+ ret = dev-tx_ir(dev, txbuf, count);
+
+ if (ret 0)
+ ret *= sizeof(unsigned);
out:
kfree(txbuf);
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index 3d13fcb..e8f7847 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -381,7 +381,7 @@ static int ite_set_tx_duty_cycle(struct rc_dev *rcdev,
u32 duty_cycle)
/* transmit out IR pulses; what you get here is a batch of alternating
* pulse/space/pulse/space lengths that we should write out completely
through
* the FIFO, blocking on a full FIFO */
-static int ite_tx_ir(struct rc_dev *rcdev, int *txbuf, u32 n)
+static int ite_tx_ir(struct rc_dev *rcdev, unsigned *txbuf, unsigned n)
{
unsigned long flags;
struct ite_dev *dev = rcdev-priv;
@@ -397,9 +397,6 @@ static int ite_tx_ir(struct rc_dev *rcdev, int *txbuf,
u32 n)
/* clear the array just in case */
memset(last_sent, 0, ARRAY_SIZE(last_sent));
- /* n comes in bytes; convert to ints */
- n /= sizeof(int);
-
spin_lock_irqsave(dev-lock, flags);
/* let everybody know we're now transmitting */
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index c51e7c2..c1cd00d 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -665,20 +665,18 @@ static void mce_sync_in(struct mceusb_dev *ir, unsigned
char *data, int size)
}
/* Send data out the IR blaster port(s) */
-static int
Re: [GIT PULL FOR 2.6.40] Anysee
Em 29-04-2011 14:05, Antti Palosaari escreveu: Moikka Mauro, PULL following patches for the 2.6.40. This basically adds support for two Anysee satellite models: 1. E30 S2 Plus 2. E7 S2 t. Antti The following changes since commit f5bc5d1d4730bce69fbfdc8949ff50b49c70d934: anysee: add more info about known board configs (2011-04-13 02:17:11 +0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (3): cx24116: add config option to split firmware download anysee: add support for Anysee E30 S2 Plus anysee: add support for Anysee E7 S2 As I said you on irc, at cx24116, please add a logic to explicitly check if I2C size is equal to zero. While your logic works, it is tricky, and having a more readable code at the expense of something like: if (i2c_max == 0) i2c_max = 65535; seems to be the right thing to do. Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] tm6000: rework standards
Dmitri, I have tested your patch, but is doesn't work (big crash - long, long, long beep). -- 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
HOW TO MAKE DVB STICK WORK
Hi, I'm trying to make a BEST BUY EASY TV USB HYBRID PRO work. When I do lsusb this is what I get: Bus 001 Device 006: ID eb1a:2881 eMPIA Technology, Inc. EM2881 Video Controller Could you help me with this? I attach the dmesg log [2.011536] powernow-k8:2 : fid 0x2 (1000 MHz), vid 0xa [2.011582] Using IPI No-Shortcut mode [2.011703] PM: Hibernation image not present or could not be loaded. [2.011720] registered taskstats version 1 [2.011924] Magic number: 11:608:86 [2.012076] rtc_cmos 00:02: setting system clock to 2011-05-04 17:03:42 UTC (1304528622) [2.012080] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [2.012082] EDD information not available. [2.012198] Freeing unused kernel memory: 700k freed [2.012851] Write protecting the kernel text: 5192k [2.012890] Write protecting the kernel read-only data: 2148k [2.044498] 30udev[59]: starting version 167 [2.196068] usb 1-5: new high speed USB device using ehci_hcd and address 5 [2.202817] sata_uli :00:0e.1: version 1.3 [2.202836] sata_uli :00:0e.1: PCI INT A - GSI 19 (level, low) - IRQ 19 [2.249591] uli526x: ULi M5261/M5263 net driver, version 0.9.3 (2005-7-29) [2.292561] scsi0 : sata_uli [2.298609] scsi1 : sata_uli [2.298706] ata1: SATA max UDMA/133 cmd 0xec00 ctl 0xe800 bmdma 0xdc00 irq 19 [2.298710] ata2: SATA max UDMA/133 cmd 0xe400 ctl 0xe000 bmdma 0xdc08 irq 19 [2.299615] uli526x :00:0d.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [2.327768] Floppy drive(s): fd0 is 1.44M [2.350029] FDC 0 is a post-1991 82077 [2.357790] net eth0: ULi M5263 at pci:00:0d.0, 00:0b:6a:93:6e:dd, irq 17 [2.357839] pata_ali :00:0e.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [2.358706] scsi2 : pata_ali [2.358840] scsi3 : pata_ali [2.360331] ata3: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14 [2.360334] ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15 [2.369614] usbcore: registered new interface driver uas [2.540249] ata3.00: ATAPI: HL-DT-STDVD-ROM GDR8162B, 0015, max UDMA/33 [2.540254] ata3.00: WARNING: ATAPI DMA disabled for reliability issues. It can be enabled [2.540257] ata3.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs node. [2.556130] ata3.00: configured for UDMA/33 [2.764029] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [2.772351] ata1.00: ATA-8: ST1000DL002-9TT153, CC32, max UDMA/133 [2.772354] ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) [2.788341] ata1.00: configured for UDMA/133 [2.788489] scsi 0:0:0:0: Direct-Access ATA ST1000DL002-9TT1 CC32 PQ: 0 ANSI: 5 [2.788707] sd 0:0:0:0: Attached scsi generic sg0 type 0 [2.788837] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [2.78] sd 0:0:0:0: [sda] Write Protect is off [2.788891] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [2.788914] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [2.827124] sda: sda1 sda2 sda5 sda6 [2.827492] sd 0:0:0:0: [sda] Attached SCSI disk [2.836017] usb 4-2: new low speed USB device using ohci_hcd and address 2 [3.074954] usbcore: registered new interface driver usbhid [3.074959] usbhid: USB HID core driver [3.112454] scsi 2:0:0:0: CD-ROMHL-DT-ST DVD-ROM GDR8162B 0015 PQ: 0 ANSI: 5 [3.120098] sr0: scsi3-mmc drive: 20x/48x cd/rw xa/form2 cdda tray [3.120101] cdrom: Uniform CD-ROM driver Revision: 3.20 [3.120257] sr 2:0:0:0: Attached scsi CD-ROM sr0 [3.120344] sr 2:0:0:0: Attached scsi generic sg1 type 5 [3.228011] usb 3-1: new full speed USB device using ohci_hcd and address 2 [3.301812] Initializing USB Mass Storage driver... [3.307732] scsi4 : usb-storage 1-5:1.0 [3.310107] usbcore: registered new interface driver usb-storage [3.310113] USB Mass Storage support registered. [3.313195] input: Logitech USB Receiver as /devices/pci:00/:00:0f.1/usb4/4-2/4-2:1.0/input/input2 [3.313453] logitech 0003:046D:C517.0001: input,hidraw0: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-:00:0f.1-2/input0 [3.321960] logitech 0003:046D:C517.0002: fixing up Logitech keyboard report descriptor [3.325013] input: Logitech USB Receiver as /devices/pci:00/:00:0f.1/usb4/4-2/4-2:1.1/input/input3 [3.325940] logitech 0003:046D:C517.0002: input,hiddev0,hidraw1: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:0f.1-2/input1 [3.608202] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [3.756057] usb 6-1: new full speed USB device using ohci_hcd and address 2 [4.148018] usb 7-1: new low speed USB device using ohci_hcd and address 2 [4.310657] scsi 4:0:0:0: Direct-Access Generic STORAGE DEVICE 0128 PQ: 0 ANSI: 0 [4.311640] scsi 4:0:0:1: Direct-Access Generic STORAGE DEVICE
[cron job] v4l-dvb daily build: 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:Wed May 4 19:01:27 CEST 2011 git hash:96ca8620ba574b9b74e04fda857b360edbfdd11b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS 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 V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v2.6.40] [media] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG
Hello, On Wed, Apr 13, 2011 at 02:56:54PM +0200, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG I don't understand why I get that mail now, the corresponding commit (122af366015abc) is already in Linux' tree?? Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.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
[GIT PULL for 2.6.39-rc7] V4L/DVB updates
Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus For one regression at v4l2 sub-devices, a few remote controler driver fixes, one Kconfig missing dependency and one regression at ngene driver. Thanks! Mauro. - The following changes since commit 0ee5623f9a6e52df90a78bd21179f8ab370e102e: Linux 2.6.39-rc6 (2011-05-03 19:59:13 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Herton Ronaldo Krzesinski (1): [media] v4l: make sure drivers supply a zeroed struct v4l2_subdev Hussam Al-Tayeb (1): [media] rc_core: avoid kernel oops when rmmod saa7134 Jarod Wilson (4): [media] mceusb: add Dell transceiver ID [media] ite-cir: modular build on ppc requires delay.h include [media] rc: show RC_TYPE_OTHER in sysfs [media] imon: add conditional locking in change_protocol Malcolm Priestley (1): [media] Missing frontend config for LME DM04/QQBOX Oliver Endriss (1): [media] ngene: Fix CI data transfer regression Fix CI data transfer regression introduced by previous cleanup. drivers/media/dvb/dvb-usb/Kconfig|2 ++ drivers/media/dvb/ngene/ngene-core.c |1 + drivers/media/radio/saa7706h.c |2 +- drivers/media/radio/tef6862.c|2 +- drivers/media/rc/imon.c | 31 +++ drivers/media/rc/ite-cir.c |1 + drivers/media/rc/mceusb.c|2 ++ drivers/media/rc/rc-main.c |4 +++- drivers/media/video/m52790.c |2 +- drivers/media/video/tda9840.c|2 +- drivers/media/video/tea6415c.c |2 +- drivers/media/video/tea6420.c|2 +- drivers/media/video/upd64031a.c |2 +- drivers/media/video/upd64083.c |2 +- 14 files changed, 44 insertions(+), 13 deletions(-) -- 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] Fix cx88 remote control input
Hi Lawerence,
Em 03-05-2011 14:19, Jarod Wilson escreveu:
On May 3, 2011, at 3:25 AM, Lawrence Rust wrote:
On Mon, 2011-05-02 at 15:50 -0300, Mauro Carvalho Chehab wrote:
Em 08-04-2011 09:50, Lawrence Rust escreveu:
This patch restores remote control input for cx2388x based boards on
Linux kernels = 2.6.38.
After upgrading from Linux 2.6.37 to 2.6.38 I found that the remote
control input of my Hauppauge Nova-S plus was no longer functioning.
I posted a question on this newsgroup and Mauro Carvalho Chehab gave
some helpful pointers as to the likely cause.
Turns out that there are 2 problems:
1. In the IR interrupt handler of cx88-input.c there's a 32-bit multiply
overflow which causes IR pulse durations to be incorrectly calculated.
I'm adding the patch for it today on my linux-next tree. I'll probably send
upstream on the next couple days.
2. The RC5 decoder appends the system code to the scancode and passes
the combination to rc_keydown(). Unfortunately, the combined value is
then forwarded to input_event() which then fails to recognise a valid
scancode and hence no input events are generated.
In this case, a patch should be sent to -stable in separate.
Greg,
On 2.6.38, there are two RC5 keytables for Hauppauge devices, one with
incomplete
scancodes (just 8 bits for each key) and the other one with 14 bits. One patch
changed the IR handling for cx88 to accept 14-bits for scancodes, but the change
didn't switch to the complete table.
For 2.6.39, all keytables for Hauppauge (4 different tables) were unified into
just one keytable. So, on 2.6.39-rc, the cx88 code already works fine for
64-bits
kernels, and the fix for 32-bits is undergoing.
In the case of 2.6.38 kernel, the Remote Controller is broken for both kernels.
The fix is as simple as:
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -283,7 +283,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev
*pci)
case CX88_BOARD_PCHDTV_HD3000:
case CX88_BOARD_PCHDTV_HD5500:
case CX88_BOARD_HAUPPAUGE_IRONLY:
- ir_codes = RC_MAP_HAUPPAUGE_NEW;
+ ir_codes = RC_MAP_RC5_HAUPPAUGE_NEW;
ir-sampling = 1;
break;
case CX88_BOARD_WINFAST_DTV2000H:
But this change diverges from upstream, due to the table unify. Would such patch
be acceptable for stable, even not having a corresponding upstream commit?
Thanks!
Mauro.
I note that in commit 2997137be8eba5bf9c07a24d5fda1f4225f9ca7d, which
introduced these changes, David Härdeman changed the IR sample frequency
to a supposed 4kHz. However, the registers dealing with IR input are
undocumented in the cx2388x datasheets and there's no publicly available
information on them. I have to ask the question why this change was
made as it is of no apparent benefit and could have unanticipated
consequences. IMHO that change should also be reverted unless there is
evidence to substantiate it.
Signed off by: Lawrence Rust lvr at softsystem dot co dot uk
diff --git a/drivers/media/rc/ir-rc5-decoder.c
b/drivers/media/rc/ir-rc5-decoder.c
index ebdba55..c4052da 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -144,10 +144,15 @@ again:
system = (data-bits 0x007C0) 6;
toggle = (data-bits 0x00800) ? 1 : 0;
command += (data-bits 0x01000) ? 0 : 0x40;
- scancode = system 8 | command;
-
- IR_dprintk(1, RC5 scancode 0x%04x (toggle: %u)\n,
- scancode, toggle);
+/* Notes
+ * 1. Should filter unknown systems e.g Hauppauge use 0x1e or
0x1f
+ * 2. Don't include system in the scancode otherwise
input_event()
+ *doesn't recognise the scancode
+ */
+ scancode = command;
+
+ IR_dprintk(1, RC5 scancode 0x%02x (system: 0x%02x
toggle: %u)\n,
+ scancode, system, toggle);
}
rc_keydown(dev, scancode, toggle);
I agree with Jarod: The above hunk shouldn't go upstream, or else it would
break _lots_ of
remotes.
diff --git a/drivers/media/video/cx88/cx88-input.c
b/drivers/media/video/cx88/cx88-input.c
index c820e2f..7281db4 100644
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -524,7 +524,7 @@ void cx88_ir_irq(struct cx88_core *core)
for (todo = 32; todo 0; todo -= bits) {
ev.pulse = samples 0x8000 ? false : true;
bits = min(todo, 32U - fls(ev.pulse ? samples : ~samples));
- ev.duration = (bits * NSEC_PER_SEC) / (1000 * ir_samplerate);
+ ev.duration = bits * (NSEC_PER_SEC / (1000 * ir_samplerate));
/* NB avoid 32-bit overflow */
ir_raw_event_store_with_filter(ir-dev, ev);
samples = bits;
}
This
Re: [GIT PULL FOR 2.6.40] Anysee
Updated PULL requested! Cc: Steven Toth as cx24116 driver author. On 05/04/2011 07:03 PM, Mauro Carvalho Chehab wrote: Em 29-04-2011 14:05, Antti Palosaari escreveu: Moikka Mauro, PULL following patches for the 2.6.40. This basically adds support for two Anysee satellite models: 1. E30 S2 Plus 2. E7 S2 t. Antti The following changes since commit f5bc5d1d4730bce69fbfdc8949ff50b49c70d934: anysee: add more info about known board configs (2011-04-13 02:17:11 +0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (3): cx24116: add config option to split firmware download anysee: add support for Anysee E30 S2 Plus anysee: add support for Anysee E7 S2 As I said you on irc, at cx24116, please add a logic to explicitly check if I2C size is equal to zero. While your logic works, it is tricky, and having a more readable code at the expense of something like: if (i2c_max == 0) i2c_max = 65535; seems to be the right thing to do. For some reason as I mentioned on IRC, this change increases binary size 52 bytes, whilst functionality remains same. Feel free to select this new or old patch. t. Antti The following changes since commit f5bc5d1d4730bce69fbfdc8949ff50b49c70d934: anysee: add more info about known board configs (2011-04-13 02:17:11 +0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (4): cx24116: add config option to split firmware download anysee: add support for Anysee E30 S2 Plus anysee: add support for Anysee E7 S2 cx24116: make FW DL split more readable drivers/media/dvb/dvb-usb/Kconfig |4 + drivers/media/dvb/dvb-usb/anysee.c| 103 + drivers/media/dvb/dvb-usb/anysee.h|1 + drivers/media/dvb/frontends/cx24116.c | 19 +- drivers/media/dvb/frontends/cx24116.h |3 + 5 files changed, 127 insertions(+), 3 deletions(-) -- 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] Fix cx88 remote control input
On Wed, May 04, 2011 at 05:16:29PM -0300, Mauro Carvalho Chehab wrote: Hi Lawerence, Em 03-05-2011 14:19, Jarod Wilson escreveu: On May 3, 2011, at 3:25 AM, Lawrence Rust wrote: On Mon, 2011-05-02 at 15:50 -0300, Mauro Carvalho Chehab wrote: Em 08-04-2011 09:50, Lawrence Rust escreveu: This patch restores remote control input for cx2388x based boards on Linux kernels = 2.6.38. After upgrading from Linux 2.6.37 to 2.6.38 I found that the remote control input of my Hauppauge Nova-S plus was no longer functioning. I posted a question on this newsgroup and Mauro Carvalho Chehab gave some helpful pointers as to the likely cause. Turns out that there are 2 problems: 1. In the IR interrupt handler of cx88-input.c there's a 32-bit multiply overflow which causes IR pulse durations to be incorrectly calculated. I'm adding the patch for it today on my linux-next tree. I'll probably send upstream on the next couple days. 2. The RC5 decoder appends the system code to the scancode and passes the combination to rc_keydown(). Unfortunately, the combined value is then forwarded to input_event() which then fails to recognise a valid scancode and hence no input events are generated. In this case, a patch should be sent to -stable in separate. Greg, On 2.6.38, there are two RC5 keytables for Hauppauge devices, one with incomplete scancodes (just 8 bits for each key) and the other one with 14 bits. One patch changed the IR handling for cx88 to accept 14-bits for scancodes, but the change didn't switch to the complete table. For 2.6.39, all keytables for Hauppauge (4 different tables) were unified into just one keytable. So, on 2.6.39-rc, the cx88 code already works fine for 64-bits kernels, and the fix for 32-bits is undergoing. In the case of 2.6.38 kernel, the Remote Controller is broken for both kernels. The fix is as simple as: --- a/drivers/media/video/cx88/cx88-input.c +++ b/drivers/media/video/cx88/cx88-input.c @@ -283,7 +283,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev *pci) case CX88_BOARD_PCHDTV_HD3000: case CX88_BOARD_PCHDTV_HD5500: case CX88_BOARD_HAUPPAUGE_IRONLY: - ir_codes = RC_MAP_HAUPPAUGE_NEW; + ir_codes = RC_MAP_RC5_HAUPPAUGE_NEW; ir-sampling = 1; break; case CX88_BOARD_WINFAST_DTV2000H: But this change diverges from upstream, due to the table unify. Would such patch be acceptable for stable, even not having a corresponding upstream commit? Yes, as long as .39 is working properly. We take patches in -stable for stuff like this at times, it just needs to be specified exactly like you did above. Want me to take this patch as-is for .38-stable? thanks, greg k-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
[GIT PULL FOR 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)
Moikka Mauro, PULL following patches for the 2.6.40. I want these master as soon as possible to get some test reports before Kernel 2.6.40 merge. This patch series add support PCTV nanoStick T2 290e stick, which is first DVB-T2 capable computer receiver. Main part of this patch series is new demod driver for Sony CXD2820R. Other big part is multi frontend (MFE) support for em28xx driver. I don't have any other MFE device, so I cannot say if it is implemented correctly or not. At least it seems to work. MFE locking is done in demod driver. If there is some problems let me know and I will try to fix those - I think there is no such big major problems still. I didn't implemented proper DVB-T2 support for DVB API, since it seems to be rather complex and needs some learning. Thus, I made it working automatically something like try DVB-T, if no lock, fall-back to DVB-T2. Error and trial. And some abuse :i Special thanks to Steve Kerrison for his help, testing, talking, reviewing code and improving driver! t. Antti The following changes since commit d9954d8547181f9a6a23f835cc1413732700b785: Merge branch 'linus' into staging/for_v2.6.40 (2011-04-04 16:04:30 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git pctv_290e_new Antti Palosaari (7): tda18271: add DVB-C support em28xx: Multi Frontend (MFE) support em28xx: add support for EM28174 chip Sony CXD2820R DVB-T/T2/C demodulator driver Add support for PCTV nanoStick T2 290e [2013:024f] cxd2820r: whitespace fix cxd2820r: switch automatically between DVB-T and DVB-T2 Steve Kerrison (2): cxd2820r: make C, T, T2 and core components as linked objects em28xx: Disable audio for EM28174 drivers/media/common/tuners/tda18271-fe.c |4 + drivers/media/dvb/frontends/Kconfig |7 + drivers/media/dvb/frontends/Makefile|3 + drivers/media/dvb/frontends/cxd2820r.h | 118 drivers/media/dvb/frontends/cxd2820r_c.c| 338 ++ drivers/media/dvb/frontends/cxd2820r_core.c | 914 +++ drivers/media/dvb/frontends/cxd2820r_priv.h | 178 ++ drivers/media/dvb/frontends/cxd2820r_t.c| 449 + drivers/media/dvb/frontends/cxd2820r_t2.c | 423 + drivers/media/video/em28xx/Kconfig |1 + drivers/media/video/em28xx/em28xx-cards.c | 28 + drivers/media/video/em28xx/em28xx-core.c|9 +- drivers/media/video/em28xx/em28xx-dvb.c | 140 +++- drivers/media/video/em28xx/em28xx-i2c.c |2 +- drivers/media/video/em28xx/em28xx-reg.h |1 + drivers/media/video/em28xx/em28xx.h |1 + 16 files changed, 2578 insertions(+), 38 deletions(-) create mode 100644 drivers/media/dvb/frontends/cxd2820r.h create mode 100644 drivers/media/dvb/frontends/cxd2820r_c.c create mode 100644 drivers/media/dvb/frontends/cxd2820r_core.c create mode 100644 drivers/media/dvb/frontends/cxd2820r_priv.h create mode 100644 drivers/media/dvb/frontends/cxd2820r_t.c create mode 100644 drivers/media/dvb/frontends/cxd2820r_t2.c -- 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] Fix cx88 remote control input
Em 04-05-2011 17:36, Greg KH escreveu: Yes, as long as .39 is working properly. We take patches in -stable for stuff like this at times, it just needs to be specified exactly like you did above. OK. Want me to take this patch as-is for .38-stable? Yes, please. I'm forwarding you bellow with the proper authorship/SOB/ack. This patch fixes RC for 64 bits kernels. The extra fix for 32 bits kernels, (solves a calculus overflow), were sent today to -next. I generally wait for a couple days before asking Linus to pull from it. - Subject: [media] cx88: Fix HVR4000 IR keymap From: Lawrence Rust l...@softsystem.dot.uk Fixes the RC key input for Nova-S plus, HVR1100, HVR3000 and HVR4000 in the 2.6.38 kernel. Signed-off-by: Lawrence Rust l...@softsystem.dot.uk Acked-by: Jarod Wilson ja...@wilsonet.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/cx88/cx88-input.c b/drivers/media/video/cx88/cx88-input.c index 06f7d1d..67a2b08 100644 --- a/drivers/media/video/cx88/cx88-input.c +++ b/drivers/media/video/cx88/cx88-input.c @@ -283,7 +283,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev *pci) case CX88_BOARD_PCHDTV_HD3000: case CX88_BOARD_PCHDTV_HD5500: case CX88_BOARD_HAUPPAUGE_IRONLY: - ir_codes = RC_MAP_HAUPPAUGE_NEW; + ir_codes = RC_MAP_RC5_HAUPPAUGE_NEW; ir-sampling = 1; break; case CX88_BOARD_WINFAST_DTV2000H: -- 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: problems on soc-camera subsystem
Dear Guennadi: You should use different IDs. Look at arch/sh/boards/mach-migor/setup.c or arch/arm/mach-mx3/mach-pcm037.c for examples. Thank you for your help,The above sentence gives me the answer.Today I studied the platform_device subsystem again,and understant that if you want to register platform devices who has the same name,you must give each of them a different ID.what a easy problem,but cost you so much time to interpret for me,I am so sorry. Thanks LeMin -- 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
Patches still pending at linux-media queue (18 patches)
I did a big effort those days to cleanup the patchwork queue. I'm still finishing to handle the git pull requests. As several noticed, we had a very bad time with patchwork on the last weeks, due to some troubles at patchwork.kernel.org. That included: - Patches that disappeared from patchwork; - Patches that lost email body/SOB/From/Ack/Nack fields; - Patches sent that weren't caught by patchwork; - Patchwork lack of availability; - sync troubles between the mysql instances used by patchwork. I've made a hard effort to recover those patches, and also did the kernel.org maintainer. John, thank you for your help. I also did an effort to cleanup most of the old stuff from patchwork. On several cases, the patch were already applied, or another approach was taken. I also fixed manually some trivial troubles I've detected. There are still 18 patches pending for merge, as described bellow. == New patches == Those require more tests and/or reviews to be applied, as they are new. There are two patches related to UVC, 2 patches related to stv0899, 2 patches for cx18 and one VB1 patch. The last one requires more care, as videobuf is used on lots of drivers, So, tests for it are welcome. Apr,29 2011: [1/2] V4L/DVB: v4l2-dev: revert commit c29fcff3daafbf46d64a543c1950bbd http://patchwork.kernel.org/patch/740691 Bob Liu lliu...@gmail.com Apr,29 2011: [2/2] media:uvc_driver: Add support for NOMMU arch http://patchwork.kernel.org/patch/740671 Bob Liu lliu...@gmail.com May, 4 2011: stb0899: Fix not locking DVB-S transponder http://patchwork.kernel.org/patch/753382 Lutz Sammer john...@gmx.net May, 4 2011: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder http://patchwork.kernel.org/patch/753392 Lutz Sammer john...@gmx.net May, 3 2011: cx18: Clean up mmap() support for raw YUV http://patchwork.kernel.org/patch/749832 Simon Farnsworth simon.farnswo...@onelan.co.uk May, 4 2011: cx18: Bump driver version to 1.5.0 http://patchwork.kernel.org/patch/753402 Simon Farnsworth simon.farnswo...@onelan.co.uk Apr,19 2011: videobuf_pages_to_sg: sglist[0] length problem http://patchwork.kernel.org/patch/718421 Newson Edouard newson...@gmail.com == mantis patches - Waiting for Manu Abraham abraham.m...@gmail.com == Manu, Can you please review those two patches? Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola marko.rist...@kolumbus.fi Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus http://patchwork.kernel.org/patch/105621 Florent AUDEBERT florent.audeb...@anevia.com == Waiting for Steven Stoth st...@kernellabs.com review == Steven, This patch is here for a long time. Could you please check what's the status of it? Nov,24 2010: [media] saa7164: poll mask set incorrectly http://patchwork.kernel.org/patch/351711 Dan Carpenter erro...@gmail.com == Waiting for Hans Verkuil hansv...@cisco.com review == Hans, I believe that want to replace this patch by something else, but better to keep it at the list while you don't send us a replacement. Mar,26 2011: [media] cpia2: fix typo in variable initialisation http://patchwork.kernel.org/patch/665951 Mariusz Kozlowski m...@lab.zgora.pl == Waiting for Igor M. Liplianin liplia...@me.by review == Igor, Please check this patch. I'm not sure how to proceed with this one. Oct,23 2010: DM1105: could not attach frontend 195d:1105 http://patchwork.kernel.org/patch/279091 Igor M. Liplianin liplia...@me.by == Waiting for it to be applied upstream == I understood that this patch will follow via Tejun's tree. I'm keeping it here just for my own control. It will probably be removed after the next merge window. Feb,15 2011: cx23885: restore flushes of cx23885_dev work items http://patchwork.kernel.org/patch/558301 Tejun Heo t...@kernel.org == waiting for Sakari Ailus sakari.ai...@maxwell.research.nokia.com submission == Sakari, I'm understanding that you'll be handling this one. Feb,19 2011: [RFC/PATCH,1/1] tcm825x: convert driver to V4L2 sub device interface http://patchwork.kernel.org/patch/574931 David Cohen daco...@gmail.com == Waiting for Jonathan Corbet cor...@lwn.net ack == Jon, One patch for your ack ;) Apr,29 2011: [media] via-camera: add MODULE_ALIAS http://patchwork.kernel.org/patch/742581 Daniel Drake d...@laptop.org == waiting for Hernán Ordiales h.ordia...@gmail.com to provide a
Re: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
On Wed, May 4, 2011 at 3:16 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flop.m@xxx wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. Can someone confirm that such patch would fix the issue? If so, please forward it in a way that it could be applied (patch is currently line-wrapped), and submit with some comments/description and your SOB. As the patch is currently broken, I'm just marking it as rejected at patchwork. Manu, Please take a look on this trouble report. Thanks! Mauro. I am out of station currently. I will take a deeper look at it during the weekend or next week. Best Regards, Manu -- 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
