Re: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
On Mon, 30 Nov 2009, Devin Heitmueller wrote: On Mon, Nov 30, 2009 at 12:28 PM, Patrick Boettcher - Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs Patrick, You added the USB ID for the 74e? Is that the result of actually trying it with the hardware? As far as I know, the 74e is not a Dibcom design. At that time I believed that the design should be a dib7770-design based on the list you gave in this email, which looked like a copy-paste of a the .inf-file of their windows driver: http://osdir.com/ml/linux-media/2009-10/msg00598.html No re-reading the mail, I see that you're not sure. So another misunderstanding. I will fix again the hg. thanks for the feedback. -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [resend] radio-sf16fmi: fix mute, add SF16-FMP to texts
Ondrej Zary wrote:
Fix completely broken mute handling radio-sf16fmi.
The sound was muted immediately after tuning in KRadio.
Also fix typos and add SF16-FMP to the texts.
I do not have device anymore. Looks OK to me.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Acked-by: Petr Vandrovec p...@vandrovec.name
To whom should I forward this (and your second patch), I did not do any
SF16 work for 10 years (and no LKML for 3).
Thanks,
Petr
diff -urp linux-source-2.6.31-orig/drivers/media/radio/Kconfig
linux-source-2.6.31/drivers/media/radio/Kconfig
--- linux-source-2.6.31-orig/drivers/media/radio/Kconfig2009-09-10
00:13:59.0 +0200
+++ linux-source-2.6.31/drivers/media/radio/Kconfig 2009-11-28
11:51:42.0 +0100
@@ -196,7 +196,7 @@ config RADIO_MAESTRO
module will be called radio-maestro.
config RADIO_SF16FMI
- tristate SF16FMI Radio
+ tristate SF16-FMI/SF16-FMP Radio
depends on ISA VIDEO_V4L2
---help---
Choose Y here if you have one of these FM radio cards. If you
diff -urp linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c
--- linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
2009-09-10 00:13:59.0 +0200
+++ linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c 2009-11-28
11:39:35.0 +0100
@@ -1,4 +1,4 @@
-/* SF16FMI radio driver for Linux radio support
+/* SF16-FMI and SF16-FMP radio driver for Linux radio support
* heavily based on rtrack driver...
* (c) 1997 M. Kirkwood
* (c) 1998 Petr Vandrovec, vandr...@vc.cvut.cz
@@ -11,7 +11,7 @@
*
* Frequency control is done digitally -- ie out(port,encodefreq(95.8));
* No volume control - only mute/unmute - you have to use line volume
- * control on SB-part of SF16FMI
+ * control on SB-part of SF16-FMI/SF16-FMP
*
* Converted to V4L2 API by Mauro Carvalho Chehab mche...@infradead.org
*/
@@ -30,14 +30,14 @@
#include media/v4l2-ioctl.h
MODULE_AUTHOR(Petr Vandrovec, vandr...@vc.cvut.cz and M. Kirkwood);
-MODULE_DESCRIPTION(A driver for the SF16MI radio.);
+MODULE_DESCRIPTION(A driver for the SF16-FMI and SF16-FMP radio.);
MODULE_LICENSE(GPL);
static int io = -1;
static int radio_nr = -1;
module_param(io, int, 0);
-MODULE_PARM_DESC(io, I/O address of the SF16MI card (0x284 or 0x384));
+MODULE_PARM_DESC(io, I/O address of the SF16-FMI or SF16-FMP card (0x284 or
0x384));
module_param(radio_nr, int, 0);
#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
@@ -47,7 +47,7 @@ struct fmi
struct v4l2_device v4l2_dev;
struct video_device vdev;
int io;
- int curvol; /* 1 or 0 */
+ bool mute;
unsigned long curfreq; /* freq in kHz */
struct mutex lock;
};
@@ -105,7 +105,7 @@ static inline int fmi_setfreq(struct fmi
outbits(8, 0xC0, fmi-io);
msleep(143);/* was schedule_timeout(HZ/7) */
mutex_unlock(fmi-lock);
- if (fmi-curvol)
+ if (!fmi-mute)
fmi_unmute(fmi);
return 0;
}
@@ -116,7 +116,7 @@ static inline int fmi_getsigstr(struct f
int res;
mutex_lock(fmi-lock);
- val = fmi-curvol ? 0x08 : 0x00; /* unmute/mute */
+ val = fmi-mute ? 0x00 : 0x08; /* mute/unmute */
outb(val, fmi-io);
outb(val | 0x10, fmi-io);
msleep(143);/* was schedule_timeout(HZ/7) */
@@ -204,7 +204,7 @@ static int vidioc_g_ctrl(struct file *fi
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl-value = fmi-curvol;
+ ctrl-value = fmi-mute;
return 0;
}
return -EINVAL;
@@ -221,7 +221,7 @@ static int vidioc_s_ctrl(struct file *fi
fmi_mute(fmi);
else
fmi_unmute(fmi);
- fmi-curvol = ctrl-value;
+ fmi-mute = ctrl-value;
return 0;
}
return -EINVAL;
--
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 2/2 v2] soc-camera: convert to the new mediabus API
On Monday 30 November 2009 15:48:24 Guennadi Liakhovetski wrote:
On Mon, 30 Nov 2009, Hans Verkuil wrote:
On Fri, 27 Nov 2009, Guennadi Liakhovetski wrote:
On Fri, 27 Nov 2009, Hans Verkuil wrote:
Hi Guennadi,
Convert soc-camera core and all soc-camera drivers to the new
mediabus API. This also takes soc-camera client drivers one step
closer to also be
usable with generic v4l2-subdev host drivers.
Just a quick question:
@@ -323,28 +309,39 @@ static int mt9m001_s_fmt(struct v4l2_subdev
*sd, struct v4l2_format *f)
/* No support for scaling so far, just crop. TODO: use skipping
*/ ret = mt9m001_s_crop(sd, a);
if (!ret) {
- pix-width = mt9m001-rect.width;
- pix-height = mt9m001-rect.height;
- mt9m001-fourcc = pix-pixelformat;
+ mf-width = mt9m001-rect.width;
+ mf-height = mt9m001-rect.height;
+ mt9m001-fmt= soc_mbus_find_datafmt(mf-code,
+ mt9m001-fmts,
mt9m001-num_fmts);
+ mf-colorspace = mt9m001-fmt-colorspace;
}
return ret;
}
-static int mt9m001_try_fmt(struct v4l2_subdev *sd, struct
v4l2_format *f)
+static int mt9m001_try_fmt(struct v4l2_subdev *sd,
+struct v4l2_mbus_framefmt *mf)
{
struct i2c_client *client = sd-priv;
struct mt9m001 *mt9m001 = to_mt9m001(client);
- struct v4l2_pix_format *pix = f-fmt.pix;
+ const struct soc_mbus_datafmt *fmt;
- v4l_bound_align_image(pix-width, MT9M001_MIN_WIDTH,
+ v4l_bound_align_image(mf-width, MT9M001_MIN_WIDTH,
MT9M001_MAX_WIDTH, 1,
- pix-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
+ mf-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
MT9M001_MAX_HEIGHT + mt9m001-y_skip_top, 0, 0);
- if (pix-pixelformat == V4L2_PIX_FMT_SBGGR8 ||
- pix-pixelformat == V4L2_PIX_FMT_SBGGR16)
- pix-height = ALIGN(pix-height - 1, 2);
+ if (mt9m001-fmts == mt9m001_colour_fmts)
+ mf-height = ALIGN(mf-height - 1, 2);
+
+ fmt = soc_mbus_find_datafmt(mf-code, mt9m001-fmts,
+ mt9m001-num_fmts);
+ if (!fmt) {
+ fmt = mt9m001-fmt;
+ mf-code = fmt-code;
+ }
+
+ mf-colorspace = fmt-colorspace;
return 0;
}
Why do the sensor drivers use soc_mbus_find_datafmt? They only seem
to be interested in the colorspace field, but I don't see the reason
for that. Most if not all sensors have a fixed colorspace depending
on the pixelcode, so they can just ignore the colorspace that the
caller requested and replace it with their own.
Right, that's exactly what's done here. mt9m001 and mt9v022 drivers
support different formats, depending on the exact detected or specified
by the user model. That's why they have to search for the requested
format in supported list. and then - yes, they just put the found
format into user
request:
+ mf-colorspace = fmt-colorspace;
I didn't have time for a full review, so I might have missed
something.
I looked at this more closely and I realized that I did indeed miss that
soc_mbus_find_datafmt just searched in the pixelcode - colorspace
mapping array.
I also realized that there is no need for that data structure and
function to be soc-camera specific. I believe I said otherwise in an
earlier review. My apologies for that, all I can say is that I had very
little time to do the reviews...
No, you did not say otherwise about _these_ struct and function - they
only appeared in v2 of the mediabus API, after you'd suggested to move
colorspace into struct v4l2_mbus_framefmt.
That said, there is no need for both the soc_mbus_datafmt struct and the
soc_mbus_find_datafmt function. These can easily be replaced by something
like this as a local function in each subdev:
static enum v4l2_colorspace mt9m111_g_colorspace(enum v4l2_mbus_pixelcode
code)
{
switch (code) {
case V4L2_MBUS_FMT_YUYV:
case V4L2_MBUS_FMT_YVYU:
case V4L2_MBUS_FMT_UYVY:
case V4L2_MBUS_FMT_VYUY:
return V4L2_COLORSPACE_JPEG;
case V4L2_MBUS_FMT_RGB555:
case V4L2_MBUS_FMT_RGB565:
case V4L2_MBUS_FMT_SBGGR8:
case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE:
return V4L2_COLORSPACE_SRGB;
default:
return 0;
}
}
So if mt9m111_g_colorspace() returns 0, then the format wasn't found.
(Note that the compiler might give a warning for the return 0, so that
might need some editing)
Much simpler and much easier to understand.
Drivers are
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, The point is that for simple usage, like an user plugging his new USB stick he just bought, he should be able to use the shipped IR without needing to configure anything or manually calling any daemon. This currently works with the existing drivers and it is a feature that needs to be kept. Admittedly, LIRC is way behind when it comes to plug'n'play. Should not be that hard to fixup. When moving the keytable loading from kernel to userspace the kernel drivers have to inform userspace anyway what kind of hardware the IR device is, so udev can figure what keytable it should load. A sysfs attribute is the way to go here I think. lirc drivers can do the same, and lircd can startup with a reasonable (default) configuration. Of course evdev and lirc subsytems/drivers should agree on which attributes should be defined and how they are filled. cheers, Gerd -- 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 1/2 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
On Monday 30 November 2009 14:49:07 Guennadi Liakhovetski wrote: On Mon, 30 Nov 2009, Hans Verkuil wrote: On Thu, 26 Nov 2009, Guennadi Liakhovetski wrote: From 8b24c617e1ac4d324538a3eec476d48b85c2091f Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski g.liakhovet...@gmx.de Date: Thu, 26 Nov 2009 18:20:45 +0100 Subject: [PATCH] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats Video subdevices, like cameras, decoders, connect to video bridges over specialised busses. Data is being transferred over these busses in various formats, which only loosely correspond to fourcc codes, describing how video data is stored in RAM. This is not a one-to-one correspondence, therefore we cannot use fourcc codes to configure subdevice output data formats. This patch adds codes for several such on-the-bus formats and an API, similar to the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those codes. After all users of the old API in struct v4l2_subdev_video_ops are converted, it will be removed. Also add helper routines to support generic pass-through mode for the soc-camera framework. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v2 - v3: more comments: 1. moved enum v4l2_mbus_packing, enum v4l2_mbus_order, and struct v4l2_mbus_pixelfmt to soc-camera specific header, renamed them into soc-namespace. 2. commented enum v4l2_mbus_pixelcode and removed unused values. v1 - v2: addressed comments from Hans, namely: 1. renamed image bus to media bus, now using mbus as a shorthand in function and data type names. 2. made media-bus helper functions soc-camera local. 3. moved colorspace from struct v4l2_mbus_pixelfmt to struct v4l2_mbus_framefmt. 4. added documentation for data types and enums. 5. added V4L2_MBUS_FMT_FIXED = 1, format as the first in enum. soc-camera driver port will follow tomorrow. Thanks Guennadi drivers/media/video/Makefile |2 +- drivers/media/video/soc_mediabus.c | 157 include/media/soc_mediabus.h | 84 +++ include/media/v4l2-mediabus.h | 59 ++ include/media/v4l2-subdev.h| 19 - cut diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h new file mode 100644 index 000..359840c --- /dev/null +++ b/include/media/v4l2-mediabus.h @@ -0,0 +1,59 @@ +/* + * Media Bus API header + * + * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef V4L2_MEDIABUS_H +#define V4L2_MEDIABUS_H + +/* + * These pixel codes uniquely identify data formats on the media bus. Mostly + * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is + * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the + * data format is fixed. Additionally, 2X8 means that one pixel is transferred + * in two 8-bit samples, BE or LE specify in which order those samples + * should be stored in RAM, and PADHI and PADLO define which bits - low or + * high, in the incomplete high byte, are filled with padding bits. + */ Hi Guennadi, This still needs some improvement. There are two things that need to be changed here: 1) add the width of the data bus to the format name: so V4L2_MBUS_FMT_YUYV becomes _FMT_YUYV_8. This is required since I know several video receivers that can be programmed to use one of several data widths (8, 10, 12 bits per color component). Perhaps _1X8 is even better since that is nicely consistent with the 2X8 suffix that you already use. The PADHI and PADLO naming convention is fine and should be used whereever it is neeeded. Ditto for BE and LE. Ok, my first thought was no, there only very seldom will be a need for a different padding / order / bus-width, but the second thought was but if there ever will be one, you'll have to rename the original code too... 2) Rephrase 'BE or LE specify in which order those samples should be stored in RAM' to: 'BE or LE specify in which order those samples are transferred over the bus: BE means that the most significant bits are transferred first, LE means that the least significant bits are transferred first.' This also means that formats like RGB555 need to be renamed to RGB555_2X8_PADHI_LE. I think that this would make this list of pixelcodes unambiguous and understandable. Right, how about this: /* * These pixel codes uniquely identify data formats on the media bus. Mostly * they correspond to similarly
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, A current related problem is that i2c based devices can only be bound to only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time. Currently it is somewhat up to the bridge driver which binding is preferred. Discussion about this for the pvrusb2 module had the biggest email churn IIRC. Once lirc_dev is merged you can easily fix this: You'll have *one* driver which supports *both* evdev and lirc interfaces. If lircd opens the lirc interface raw data will be sent there, keystrokes come in via uinput. Otherwise keystrokes are send directly via evdev. Problem solved. cheers, Gerd PS: Not sure this actually makes sense for the i2c case, as far I know these do decoding in hardware and don't provide access to the raw samples, so killing the in-kernel IR limits to make ir-kbd-i2c being on par with lirc_i2c might be more useful in this case. -- 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 2/2 v2] soc-camera: convert to the new mediabus API
On Tue, 1 Dec 2009, Hans Verkuil wrote:
On Monday 30 November 2009 15:48:24 Guennadi Liakhovetski wrote:
On Mon, 30 Nov 2009, Hans Verkuil wrote:
On Fri, 27 Nov 2009, Guennadi Liakhovetski wrote:
On Fri, 27 Nov 2009, Hans Verkuil wrote:
Hi Guennadi,
Convert soc-camera core and all soc-camera drivers to the new
mediabus API. This also takes soc-camera client drivers one step
closer to also be
usable with generic v4l2-subdev host drivers.
Just a quick question:
@@ -323,28 +309,39 @@ static int mt9m001_s_fmt(struct v4l2_subdev
*sd, struct v4l2_format *f)
/* No support for scaling so far, just crop. TODO: use skipping
*/ ret = mt9m001_s_crop(sd, a);
if (!ret) {
- pix-width = mt9m001-rect.width;
- pix-height = mt9m001-rect.height;
- mt9m001-fourcc = pix-pixelformat;
+ mf-width = mt9m001-rect.width;
+ mf-height = mt9m001-rect.height;
+ mt9m001-fmt= soc_mbus_find_datafmt(mf-code,
+ mt9m001-fmts,
mt9m001-num_fmts);
+ mf-colorspace = mt9m001-fmt-colorspace;
}
return ret;
}
-static int mt9m001_try_fmt(struct v4l2_subdev *sd, struct
v4l2_format *f)
+static int mt9m001_try_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
{
struct i2c_client *client = sd-priv;
struct mt9m001 *mt9m001 = to_mt9m001(client);
- struct v4l2_pix_format *pix = f-fmt.pix;
+ const struct soc_mbus_datafmt *fmt;
- v4l_bound_align_image(pix-width, MT9M001_MIN_WIDTH,
+ v4l_bound_align_image(mf-width, MT9M001_MIN_WIDTH,
MT9M001_MAX_WIDTH, 1,
- pix-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
+ mf-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
MT9M001_MAX_HEIGHT + mt9m001-y_skip_top, 0, 0);
- if (pix-pixelformat == V4L2_PIX_FMT_SBGGR8 ||
- pix-pixelformat == V4L2_PIX_FMT_SBGGR16)
- pix-height = ALIGN(pix-height - 1, 2);
+ if (mt9m001-fmts == mt9m001_colour_fmts)
+ mf-height = ALIGN(mf-height - 1, 2);
+
+ fmt = soc_mbus_find_datafmt(mf-code, mt9m001-fmts,
+ mt9m001-num_fmts);
+ if (!fmt) {
+ fmt = mt9m001-fmt;
+ mf-code = fmt-code;
+ }
+
+ mf-colorspace = fmt-colorspace;
return 0;
}
Why do the sensor drivers use soc_mbus_find_datafmt? They only seem
to be interested in the colorspace field, but I don't see the reason
for that. Most if not all sensors have a fixed colorspace depending
on the pixelcode, so they can just ignore the colorspace that the
caller requested and replace it with their own.
Right, that's exactly what's done here. mt9m001 and mt9v022 drivers
support different formats, depending on the exact detected or specified
by the user model. That's why they have to search for the requested
format in supported list. and then - yes, they just put the found
format into user
request:
+ mf-colorspace = fmt-colorspace;
I didn't have time for a full review, so I might have missed
something.
I looked at this more closely and I realized that I did indeed miss that
soc_mbus_find_datafmt just searched in the pixelcode - colorspace
mapping array.
I also realized that there is no need for that data structure and
function to be soc-camera specific. I believe I said otherwise in an
earlier review. My apologies for that, all I can say is that I had very
little time to do the reviews...
No, you did not say otherwise about _these_ struct and function - they
only appeared in v2 of the mediabus API, after you'd suggested to move
colorspace into struct v4l2_mbus_framefmt.
That said, there is no need for both the soc_mbus_datafmt struct and the
soc_mbus_find_datafmt function. These can easily be replaced by something
like this as a local function in each subdev:
static enum v4l2_colorspace mt9m111_g_colorspace(enum v4l2_mbus_pixelcode
code)
{
switch (code) {
case V4L2_MBUS_FMT_YUYV:
case V4L2_MBUS_FMT_YVYU:
case V4L2_MBUS_FMT_UYVY:
case V4L2_MBUS_FMT_VYUY:
return V4L2_COLORSPACE_JPEG;
case V4L2_MBUS_FMT_RGB555:
case V4L2_MBUS_FMT_RGB565:
case V4L2_MBUS_FMT_SBGGR8:
case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE:
return V4L2_COLORSPACE_SRGB;
default:
return 0;
}
}
So if mt9m111_g_colorspace() returns 0, then the format wasn't found.
(Note that the compiler might give a warning for the return 0, so that
might need some
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, 2009-12-01 at 08:45 +0100, Christoph Bartelmus wrote: Hi Jon, on 30 Nov 09 at 16:35, Jon Smirl wrote: Currently I would tend to an approach like this: - raw interface to userspace using LIRC - fixed set of in-kernel decoders that can handle bundled remotes That would allow zero configuration for simple use cases and full flexibility for more advanced use cases. Christoph I'd also prefer that approach. That probably comes as no surprise, but I may not be able to keep following/kibitzing in this thread. Christoph's statement sums up my preference. 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: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hi Rob I missed your followup and tested the 'revert.diff' patch, attached for reference. I have been slow replying because I've been scratching my head over the results. I used 'signaltest.pl' to test[1], which uses tzap under the hood. Perhaps this is not the best choice, but I wanted something that I thought would allow objective comparisons. That's trickier than I thought... Unfortunately I only discovered last night how easy 'vlc ./channels.conf' makes doing quick visual checks. I didn't have enough time to re-patch and test again. My test procedure was: - get a baseline with tzap and signaltest.pl - patch, make, install. cold boot. - test with tzap and signaltest.pl - revert patch, for the moment. I tested two kernels, and both cards. I tested all the tuners but I'll spare you that for now. * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip) I got rather different baseline results. All channels had significantly higher BER than I'd noticed before. After patching, snr on some channels seemed a little higher and BER was lower. On ch9, I think snr was up and BER improved a little. here are the signaltest summary tables: without patch. usb device (dvb0) usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.0 % 322.6 672.4 Seven 191625000 76.0 % 320.2 1783.3 Nine 21950 76.8 % 329.8 2948.2 Ten 22650 76.9 % 296.6 4885.0 ABC 57150 77.0 % 542.0 7529.4 SBS 57850 77.1 % 539.5 10669.7 D44 with patch. usb device (dvb0) usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.6 % 2.3 0.0 191625000 77.0 % 235.583.3 21950 76.9 % 288.0 501.8 22650 76.9 % 295.1 1416.4 57150 77.0 % 523.4 3980.0 57850 77.1 % 549.9 7409.4 without patch. pcie device (dvb1) pciid db78:18ac Frequency Signal Ber Unc = 17750 71.2 % 3.1 0.0 191625000 21.7 % 645.4 246.4 21950 73.6 % 1.9 1632.0 22650 73.5 % 2.8 1632.0 57150 73.9 %13.6 2134.6 57850 72.7 %58.2 6393.4 with patch. pcie device (dvb1) pciid db78:18ac Frequency Signal Ber Unc = 17750 73.2 % 4.0 0.0 191625000 74.0 %37.0 0.0 21950 73.9 % 0.0 0.0 22650 73.0 % 4.6 0.0 57150 74.2 %76.7 193.6 57850 72.8 % 213.8 4480.3 * 2.6.31-14-generic + v4l (19c0469c02c3+ tip) Hard to say if I'm seeing an improvement. before patching - adapter0 usbid db78:0fe9 Frequency Signal Ber Unc = 17750 75.5 % 293.7 1926.4 191625000 75.9 % 363.2 2993.3 21950 76.7 % 304.5 4225.8 22650 76.9 % 223.8 6153.3 57150 77.0 % 491.7 8726.0 57850 77.1 % 558.9 11787.1 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..) Frequency Signal Ber Unc = 17750 75.9 % 327.9 13893.6 191625000 76.0 % 392.8 14939.0 21950 76.7 % 252.0 16052.0 22650 76.8 % 254.0 18063.1 57150 76.9 % 533.2 20644.1 57850 76.9 % 464.1 23836.8 after patching - adapter0 usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.3 % 2.5 0.0 191625000 76.8 % 227.6 119.0 21950 76.8 % 262.6 604.5 22650 76.8 % 282.7 1545.4 57150 77.0 % 486.8 3541.7 57850 77.1 % 521.5 6537.7 before patching - adapter1 pciid db78:18ac Frequency Signal
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, 2009-12-01 at 06:38 -0500, Andy Walls wrote: On Tue, 2009-12-01 at 08:45 +0100, Christoph Bartelmus wrote: Hi Jon, on 30 Nov 09 at 16:35, Jon Smirl wrote: Currently I would tend to an approach like this: - raw interface to userspace using LIRC - fixed set of in-kernel decoders that can handle bundled remotes That would allow zero configuration for simple use cases and full flexibility for more advanced use cases. Christoph I'd also prefer that approach. I also agree with this approach. This way, there will be no need for configfs hacks, but just static table for bundled remotes, and in fact this is very clean approach. Also, since bundled remotes use standard protocols, there will be no problem to add decoders for them. For the rest, the remotes that were never meant to be used with the computer, lircd will do just fine. So, it a deal? Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Gerd Hoffmann wrote: On 12/01/09 12:49, Andy Walls wrote: On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote: Once lirc_dev is merged you can easily fix this: You'll have *one* driver which supports *both* evdev and lirc interfaces. If lircd opens the lirc interface raw data will be sent there, keystrokes come in via uinput. Otherwise keystrokes are send directly via evdev. Problem solved. This will be kind of strange for lirc_zilog (aka lirc_pvr150). It supports IR transmit on the PVR-150, HVR-1600, and HD-PVR. I don't know if transmit is raw pulse timings, but I'm sure the unit provides codes on receive. Occasionally blocks of boot data need to be programmed into the transmitter side. I suspect lirc_zilog will likely need rework Well, for IR *output* it doesn't make sense to disable evdev. One more reason which indicates it probaably is better to introduce a ioctl to disable evdev reporting. lircd will probably turn it off, especially when sending data to uevent. debug tools might not, likewise apps sending IR. so killing the in-kernel IR limits to make ir-kbd-i2c ^^^ being on par with lirc_i2c might be more useful in this case. I didn't quite understand that. Can you provide a little more info? Such as throwing away the address part of rc5 codes ... This limit were already removed from the subsystem core by the patches I committed recently (still only at the devel tree - I should be adding those patches to my linux-next tree likely today). The remaining issue is that we'll need to re-scan the IR tables for every supported remote to be sure that we're getting the full RC5 code. It is not complex, but requires lots of work from people that actually have those IR's. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Dec 1, 2009, at 4:52 AM, Gerd Hoffmann wrote: On 11/30/09 13:34, Mauro Carvalho Chehab wrote: Christoph Bartelmus wrote: Hi Mauro, I just don't want to change a working interface just because it could be also implemented in a different way, but having no other visible advantage than using more recent kernel features. I agree. The main reasons to review the interface is: 1) to avoid any overlaps (if are there any) with the evdev interface; Use lirc for raw samples. Use evdev for decoded data. This is the approach I'm pretty well settled on wanting to take myself. Hardware/drivers which can handle both can support both interfaces. Exactly. IMHO it makes no sense at all to squeeze raw samples through the input layer. It looks more like a serial line than a input device. In fact you can homebrew a receiver and connect it to the serial port, which was quite common in pre-usb-ir-receiver times. 2) to have it stable enough to be used, without changes, for a long time. It isn't like lirc is a new interface. It has been used in practice for years. I don't think API stability is a problem here. Yeah, in the ~3 years I've been maintaining lirc patches for the Fedora kernels, only once has something happened where new userspace could no longer talk to old kernelspace. The majority of the work has been keeping things running as kernel interfaces change -- the 2.6.31 i2c changes are still biting us, as some capture card devices lagged behind a bit on converting to the new i2c scheme, making it impossible for lirc_i2c and/or lirc_zilog to bind (and ir-kbd-i2c, for that matter). True, but even if we want to merge lirc drivers as-is, the drivers will still need changes, due to kernel CodingStyle, due to the usage of some API's that may be deprecated, due to some breakage with non-Intel architectures, due to some bugs that kernel hackers may discover, etc. I assumed this did happen in already in preparation of this submission? Yes. There may still be a bit of work to do here, but there was a crew of us about a year, year and a half ago, that did a major sweep through all the lirc drivers, reformatting things so that we were at least mostly checkpatch-clean. The original lirc patches I put into the Fedora Core 6 kernel had several thousand lines of warnings and errors, while with the current lirc patches in Fedora 12, I get: total: 1 errors, 12 warnings, 15987 lines checked The error is new, hadn't seen that one before, going to fix it now... :) The warnings are almost all the same thing, WARNING: struct file_operations should normally be const, need to fix that too, though we actually do edit the lirc_fops on a per-device basis right now, so they can't be const... Okay, the error and one of the warnings are gone from my local tree, now its all just the above. But yeah, for the most part, I think the coding style and formatting of the lirc drivers *does* look like kernel code these days, minor fixages suggested in Mauro's review aside. I submitted only a 3-part series (lirc_dev, lirc_mceusb and lirc_imon) to keep from overwhelming anyone (myself included) with too much code at once, and went with the two device drivers that I've personally done the most work on and have several devices driven by (which includes the IR parts I've been using in my production MythTV setup for years now). -- Jarod Wilson ja...@wilsonet.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
[RFC v2] Another approach to IR
While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. Of course there are details involved in making this work. MythTV will have to have a config option to allow it to emulate several different DVR devices so that you can pick one that you don't own. It should also have choices for emulating the common devices defined for the remotes included with various Linux video board like the Hauppauge remote. For apps that haven't been modified you will have to run a daemon which will capture vendor/device/command evdev events and convert them into keystroke commands than work the menus. You'll need a config file for this and have to write scripts. Instead I'd just go modify the app the respond to the IR events, it is easy to do. Long run, we define a MythTV IR profile, mplayer profile, etc and get these into the IR database for universal remotes. Now MythTV can stop emulating another vendor's device. For the default MythTV case no external support will need to be installed if the protocol decode engines are in the kernel. The raw data will come in, run through the engines, and pop out as evdev messages with a vendor/device/command triplet. Devices that decode in hardware will just send vendor/device/command triplets. -- Jon Smirl jonsm...@gmail.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: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
Hi again, On Mon, 30 Nov 2009, Devin Heitmueller wrote: On Mon, Nov 30, 2009 at 12:28 PM, Patrick Boettcher - Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs Patrick, You added the USB ID for the 74e? Is that the result of actually trying it with the hardware? As far as I know, the 74e is not a Dibcom design. You are right, the device is an Abilis design, where, as far as I know, no Linux or GPL driver is yet written or available. Mauro: I added a patch which removes the USB IDs to my repository. The repo is now ready to be pulled. thanks, -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, The big issue here is: how do we document that EM28xxHVR950-00 is the Hauppauge Grey IR that is shipped with their newer devices. A third approach would be to identify, instead, the Remote Controller directly. So, we would add a sysfs field like ir_type. I'd pick a more descriptive name like 'bundled_remote'. Maybe an additional attribute could say which protocol the bundled remote speaks (rc5, ...), so userspace could do something sensible by default even if it has no data about the bundled remote. There are two issues here: 1) What's the name for this IR? We'll need to invent names for the existing IR's, as those devices don't have a known brand name; Name them by the hardware they are bundled with should work reasonable well. 2) there are cases where the same device is provided with two or more different IR types. If we identify the board type instead of the IR type, userspace can better handle it, by providing a list of the possibilities. We also could also provide a list of possible remotes directly via sysfs instead of expecting userspace know which remotes can come bundled with which board. No matter how we map, we'll still need to document it somehow to userspace. What would be the better? A header file? A set of keymaps from the default IR's that will be added on some directory at the Linux tree? A Documentation/IR ? I'd suggest tools/ir/ (map loader intended to be called by udev) and the maps being files in the linux source tree (next to the drivers?). The maps probably should be installed on some standard location (pretty much like firmware). Anyway, we shouldn't postpone lirc drivers addition due to that. There are still lots of work to do before we'll be able to split the tables from the kernel drivers. Indeed. The sysfs bits are future work for both lirc and evdev drivers. There is no reason to make the lirc merge wait for it. cheers, Gerd -- 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] bttv: fix MODULE_PARM_DESC for i2c_debug and i2c_hw
Currently, i2c_debug shows up w/o a desc in modinfo, and i2c_hw shows up with i2c_debug's desc. Fix that. Signed-off-by: Jarod Wilson ja...@redhat.com diff -r e0cd9a337600 linux/drivers/media/video/bt8xx/bttv-i2c.c --- a/linux/drivers/media/video/bt8xx/bttv-i2c.cSun Nov 29 12:08:02 2009 -0200 +++ b/linux/drivers/media/video/bt8xx/bttv-i2c.cTue Dec 01 10:23:54 2009 -0500 @@ -40,7 +40,7 @@ static int i2c_hw; static int i2c_scan; module_param(i2c_debug, int, 0644); -MODULE_PARM_DESC(i2c_hw,configure i2c debug level); +MODULE_PARM_DESC(i2c_debug,configure i2c debug level); module_param(i2c_hw,int, 0444); MODULE_PARM_DESC(i2c_hw,force use of hardware i2c support, instead of software bitbang); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address
From: Muralidharan Karicheri m-kariche...@ti.com If a USERPTR address that is not aligned to page boundary is passed to the videobuf_dma_contig_user_get() function, it saves a page aligned address to the dma_handle. This is not correct. This issue is observed when using USERPTR IO machism for buffer exchange. Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to V4L-DVB linux-next branch drivers/media/video/videobuf-dma-contig.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/videobuf-dma-contig.c b/drivers/media/video/videobuf-dma-contig.c index d25f284..928dfa1 100644 --- a/drivers/media/video/videobuf-dma-contig.c +++ b/drivers/media/video/videobuf-dma-contig.c @@ -166,7 +166,8 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem, break; if (pages_done == 0) - mem-dma_handle = this_pfn PAGE_SHIFT; + mem-dma_handle = (this_pfn PAGE_SHIFT) + + (vb-baddr ~PAGE_MASK); else if (this_pfn != (prev_pfn + 1)) ret = -EFAULT; -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gspca: implement vidioc_enum_frameintervals
Some drivers support multiple frameintervals (framerates), make gspca able to
enumerate them.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
Changes since the initial RFC version:
- 'i' is now a __u32 and the variable 'index' has been dropped.
- some more comments in gspca.h
Thanks to Hans de Goede for the review.
For now I am postponing the patch to ov534 which uses this one, because I am
verifying what the actual framerates supported by the subdriver are.
Thanks,
Antonio Ospite
diff -r 39c1be9a2ff8 -r ef8cca705478 linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Tue Dec 01 11:20:34 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Tue Dec 01 13:15:39 2009 +0100
@@ -998,6 +998,34 @@
return -EINVAL;
}
+static int vidioc_enum_frameintervals(struct file *filp, void *priv,
+ struct v4l2_frmivalenum *fival)
+{
+ struct gspca_dev *gspca_dev = priv;
+ int mode = wxh_to_mode(gspca_dev, fival-width, fival-height);
+ __u32 i;
+
+ if (gspca_dev-cam.mode_framerates == NULL ||
+ gspca_dev-cam.mode_framerates[mode].nrates == 0)
+ return -EINVAL;
+
+ if (fival-pixel_format !=
+ gspca_dev-cam.cam_mode[mode].pixelformat)
+ return -EINVAL;
+
+ for (i = 0; i gspca_dev-cam.mode_framerates[mode].nrates; i++) {
+ if (fival-index == i) {
+ fival-type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ fival-discrete.numerator = 1;
+ fival-discrete.denominator =
+ gspca_dev-cam.mode_framerates[mode].rates[i];
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
static void gspca_release(struct video_device *vfd)
{
struct gspca_dev *gspca_dev = container_of(vfd, struct gspca_dev, vdev);
@@ -1990,6 +2018,7 @@
.vidioc_g_parm = vidioc_g_parm,
.vidioc_s_parm = vidioc_s_parm,
.vidioc_enum_framesizes = vidioc_enum_framesizes,
+ .vidioc_enum_frameintervals = vidioc_enum_frameintervals,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register = vidioc_g_register,
.vidioc_s_register = vidioc_s_register,
diff -r 39c1be9a2ff8 -r ef8cca705478 linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h Tue Dec 01 11:20:34 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h Tue Dec 01 13:15:39 2009 +0100
@@ -45,11 +45,20 @@
/* image transfers */
#define MAX_NURBS 4/* max number of URBs */
+
+/* used to list framerates supported by a camera mode (resolution) */
+struct framerates {
+ int *rates;
+ int nrates;
+};
+
/* device information - set at probe time */
struct cam {
int bulk_size; /* buffer size when image transfer by bulk */
const struct v4l2_pix_format *cam_mode; /* size nmodes */
char nmodes;
+ const struct framerates *mode_framerates; /* must have size nmode,
+ * just like cam_mode */
__u8 bulk_nurbs;/* number of URBs in bulk mode
* - cannot be MAX_NURBS
* - when 0 and bulk_size != 0 means
--
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
architecture part of video driver patch
Kevin,
Following patch merged to v4l-dvb linux-next has an architectural
part as attached. If you have not merged it to your next branch
for linux-davinci tree, please do so at your earliest convenience
so that they are in sync.
Patch merged to linux-next is available at
http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=600cc66f7f3ec93ab4f09cf6b63980f4c5e8f8db
I will be pushing some more patches to upstream that are having
changes to arch part. I will notify once they are merged to linux-next.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
---BeginMessage---
From: Vaibhav Hiremath hvaib...@ti.com
The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.
So modified respective davinci board files.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-davinci/board-dm355-evm.c |1 +
arch/arm/mach-davinci/board-dm644x-evm.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index f683559..4a9252a 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -372,6 +372,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
static struct vpfe_config vpfe_cfg = {
.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 1,
.sub_devs = vpfe_sub_devs,
.card_name = DM355 EVM,
.ccdc = DM355 CCDC,
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index cfd9afa..fed64e2 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -257,6 +257,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
static struct vpfe_config vpfe_cfg = {
.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 1,
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
--
1.6.2.4
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
---End Message---
Re: Replace Mercurial with GIT as SCM
On Tue, Dec 01, 2009 at 03:59:20PM +0100, Patrick Boettcher wrote: Hi all, hi, I would like to start a discussion which ideally results in either changing the SCM of v4l-dvb to git _or_ leaving everything as it is today with mercurial. i should not be stopped by a tool i'm not familiar with (that is hg) but actually it is a barrier for me. i'd like to regularly follow v4l-dvb and surely with git i'd not waste the time as with hg. the result is that i have a separate git tree for my tw68xx driver and the integration with v4l-dvb and hg is not my topomost priority given also that everything needs to be ported back to git before kernel inclusion. while i accept that people doing real work should use the tool the prefer i consider this fracture with the kernel SCM a mistake. this is only my opinion, my intent is not to start any flamewar. regards, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. Of course there are details involved in making this work. MythTV will have to have a config option to allow it to emulate several different DVR devices so that you can pick one that you don't own. It should also have choices for emulating the common devices defined for the remotes included with various Linux video board like the Hauppauge remote. For apps that haven't been modified you will have to run a daemon which will capture vendor/device/command evdev events and convert them into keystroke commands than work the menus. You'll need a config file for this and have to write scripts. Instead I'd just go modify the app the respond to the IR events, it is easy to do. Long run, we define a MythTV IR profile, mplayer profile, etc and get these into the IR database for universal remotes. Now MythTV can stop emulating another vendor's device. For the default MythTV case no external support will need to be installed if the protocol decode engines are in the kernel. The raw data will come in, run through the engines, and pop out as evdev messages with a vendor/device/command triplet. Devices that decode in hardware will just send vendor/device/command triplets. -- 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: Replace Mercurial with GIT as SCM
On Tue, Dec 1, 2009 at 9:59 AM, Patrick Boettcher pboettc...@kernellabs.com wrote: Hi all, I would like to start a discussion which ideally results in either changing the SCM of v4l-dvb to git _or_ leaving everything as it is today with mercurial. To start right away: I'm in favour of using GIT because of difficulties I have with my daily work with v4l-dvb. It is in my nature do to mistakes, so I need a tool which assists me in fixing those, I have not found a simple way to do my stuff with HG. I'm helping out myself using a citation from which basically describes why GIT fits the/my needs better than HG (*): The culture of mercurial is one of immutability. This is quite a good thing, and it's one of my favorite aspects of gnu arch. If I commit something, I like to know that it's going to be there. Because of this, there are no tools to manipulate history by default. git is all about manipulating history. There's rebase, commit amend, reset, filter-branch, and probably other commands I'm not thinking of, many of which make it into day-to-day workflows. Then again, there's reflog, which adds a big safety net around this mutability. The first paragraph here describes exactly my problem and the second descibes how to solve it. My suggestion is not to have the full Linux Kernel source as a new base for v4l-dvb development, but only to replace the current v4l-dvb hg with a GIT one. Importing all the history and everything. Unfortunately it will change nothing for Mauro's job. I also understand that it does not give a lot to people who haven't used GIT until now other than a new SCM to learn. But believe me, once you've done a rebase when Mauro has asked you to rebuild your tree before he can merge it, you will see what I mean. I'm waiting for comments. I prefer git myself, but I'm not really actively working on v4l at the moment, so, I leave it up to the active devs. One nice thing about git is the ability to maintain patch authorship. Alex -- 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: Replace Mercurial with GIT as SCM
On 12/01/2009 04:59 PM, Patrick Boettcher wrote: I'm waiting for comments. GIT I have never used Git but as it is used by main Linux kernel devel tree I would prefer that too. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. So let's try and figure out a just works scheme for doing this. What I'm trying to do is to get everyone to step back and think about this problem instead of rushing head long into merging LIRC as is. irrecord is not something a non-technical user can easily handle. A basic scheme that can be used to eliminate configuration is to take well known IR device profiles and emulate them in Linux. So pick another well known device to emulate (call it A) and map it to mouse/keyboard events. Mapping vendor/device/command codes for a couple devices to mouse/keyboard events is a tiny amount of data and can be done in-kernel. This case could also be made to just work. Set your universal remote to device A. Commands from for device A will arrive and be mapped into generic keyboard/mouse commands. There are probably other solutions to making IR work without needing irrecord and configuration. What would be some other possibilities? Also consider the long term strategy of defining standard device profiles and getting them into the IR database. Make an IR profile for mouse/keyboard. After this gets into the database a universal remote can be set to this profile which will be a better match than emulating another device. Of course there are details involved in making this work. MythTV will have to have a config option to allow it to emulate several different DVR devices so that you can pick one that you don't own. It should also have choices for emulating the common devices defined for the remotes included with various Linux video board like the Hauppauge remote. For apps that haven't been modified you will have to run a daemon which will capture vendor/device/command evdev events and convert them into keystroke commands than work the menus. You'll need a config file for this and have to write scripts. Instead I'd just go modify the app the respond to the IR events, it is easy to do. Long run, we define a MythTV IR profile, mplayer profile, etc and get these into the IR database for universal remotes. Now MythTV can stop emulating another vendor's device. For the default MythTV case no external support will need to be installed if the protocol decode engines are in the kernel. The raw data will come in, run through the engines, and pop out as evdev messages with a vendor/device/command triplet. Devices that decode in hardware will just send vendor/device/command triplets. -- Jon Smirl jonsm...@gmail.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: [RFC v2] Another approach to IR
Hi Jon, Jon Smirl wrote: On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. So let's try and figure out a just works scheme for doing this. What I'm trying to do is to get everyone to step back and think about this problem instead of rushing head long into merging LIRC as is. irrecord is not something a non-technical user can easily handle. A basic scheme that can be used to eliminate configuration is to take well known IR device profiles and emulate them in Linux. So pick another well known device to emulate (call it A) and map it to mouse/keyboard events. Mapping vendor/device/command codes for a couple devices to mouse/keyboard events is a tiny amount of data and can be done in-kernel. This case could also be made to just work. Set your universal remote to device A. Commands from for device A will arrive and be mapped into generic keyboard/mouse commands. There are probably other solutions to making IR work without needing irrecord and configuration. What would be some other possibilities? Also consider the long term strategy of defining standard device profiles and getting them into the IR database. Make an IR profile for mouse/keyboard. After this gets into the database a universal remote can be set to this profile which will be a better match than emulating another device. This is basically the way the current in-kernel IR drivers work. The driver converts scancodes (device address/command sequence) into an evdev standard code. Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): # SCAN Key_code # 0xeb13 KEY_RIGHT 0x1e17 KEY_RIGHT 0x1d17 KEY_RIGHT 0x860f KEY_RIGHT 0xeb11 KEY_LEFT 0x1e16 KEY_LEFT 0x1d16 KEY_LEFT 0x860e KEY_LEFT 0x0703 KEY_VOLUMEUP 0xeb1c KEY_VOLUMEUP 0x1e10 KEY_VOLUMEUP 0x037d KEY_VOLUMEUP 0x1d10 KEY_VOLUMEUP 0x8610 KEY_VOLUMEUP 0x7a12 KEY_VOLUMEUP 0x0709 KEY_VOLUMEDOWN 0xeb1e KEY_VOLUMEDOWN 0x1e11 KEY_VOLUMEDOWN 0x017d KEY_VOLUMEDOWN 0x1d11 KEY_VOLUMEDOWN 0x860c KEY_VOLUMEDOWN 0x7a13 KEY_VOLUMEDOWN 0x0706 KEY_CHANNELUP 0xeb1b KEY_CHANNELUP 0x1e20 KEY_CHANNELUP 0x0242 KEY_CHANNELUP 0x1d20 KEY_CHANNELUP 0x860d KEY_CHANNELUP 0x7a10 KEY_CHANNELUP 0x070c KEY_CHANNELDOWN 0xeb1f KEY_CHANNELDOWN 0x1e21 KEY_CHANNELDOWN 0x007d KEY_CHANNELDOWN 0x1d21 KEY_CHANNELDOWN 0x8619 KEY_CHANNELDOWN 0x7a11 KEY_CHANNELDOWN It should be noticed, however, that some devices may be provided with a shipped IR with a different keytable where the keycodes may overlap with this table. So, what we can do is to have a default keycode table mapping several different IR's there to be used by drivers that are shipped with an IR that can be fully mapped by the default table. However, for devices with scancodes that overlaps with the default table, we'll need a separate table. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): Mauro, Just to be clear, the dib0700 does not actually support receiving RC5 or NEC codes at the same time. You have to tell the chip which mode to operate in, via a REQUEST_SET_RC to the firmware (see dib0700_core.c:405). The em28xx works the same way (you have to tell it what type of IR format to receive). The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
From: Muralidharan Karicheri m-kariche...@ti.com
v1 - updated based on comments from Vaibhav Hiremath.
On DM365 we use only vpss master clock, where as on DM355 and
DM6446, we use vpss master and slave clocks for vpfe capture and AM3517
we use internal clock and pixel clock. So this patch makes it configurable
on a per platform basis. This is needed for supporting DM365 for which patches
will be available soon.
Tested-by: Vaibhav Hiremath hvaib...@ti.com, Muralidharan Karicheri
m-kariche...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 98 +--
include/media/davinci/vpfe_capture.h | 11 ++-
2 files changed, 70 insertions(+), 39 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 12a1b3d..c3468ee 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1787,61 +1787,87 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+ int i;
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master slave clocks disabled\n);
+ for (i = 0; i vpfe_cfg-num_clocks; i++) {
+ clk_disable(vpfe_dev-clks[i]);
+ clk_put(vpfe_dev-clks[i]);
+ }
+ kfree(vpfe_dev-clks);
+ v4l2_info(vpfe_dev-pdev-driver, vpfe capture clocks disabled\n);
}
+/**
+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Enables clocks defined in vpfe configuration. The function
+ * assumes that at least one clock is to be defined which is
+ * true as of now. re-visit this if this assumption is not true
+ */
static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
+ int i;
- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-vpss_master\n);
- return ret;
- }
+ if (!vpfe_cfg-num_clocks)
+ return 0;
- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master clock enabled\n);
+ vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks *
+ sizeof(struct clock *), GFP_KERNEL);
- vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
- if (NULL == vpfe_cfg-slaveclk) {
- v4l2_err(vpfe_dev-pdev-driver,
- No clock defined for vpss slave\n);
- goto out;
+ if (NULL == vpfe_dev-clks) {
+ v4l2_err(vpfe_dev-pdev-driver, Memory allocation failed\n);
+ return -ENOMEM;
}
- if (clk_enable(vpfe_cfg-slaveclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss slave clock not enabled\n);
- goto out;
+ for (i = 0; i vpfe_cfg-num_clocks; i++) {
+ if (NULL == vpfe_cfg-clocks[i]) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ clock %s is not defined in vpfe config\n,
+ vpfe_cfg-clocks[i]);
+ goto out;
+ }
+
+ vpfe_dev-clks[i] = clk_get(vpfe_dev-pdev,
+ vpfe_cfg-clocks[i]);
+ if (NULL == vpfe_dev-clks[i]) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ Failed to get clock %s\n,
+ vpfe_cfg-clocks[i]);
+ goto out;
+ }
+
+ if (clk_enable(vpfe_dev-clks[i])) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ vpfe clock %s not enabled\n,
+ vpfe_cfg-clocks[i]);
+ goto out;
+ }
+
+ v4l2_info(vpfe_dev-pdev-driver, vpss clock %s enabled,
+ vpfe_cfg-clocks[i]);
}
- v4l2_info(vpfe_dev-pdev-driver, vpfe vpss slave clock enabled\n);
return 0;
out:
- if (vpfe_cfg-vpssclk)
-
Re: [RFC v2] Another approach to IR
Hi, On Tue, 1 Dec 2009, Devin Heitmueller wrote: On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): Mauro, Just to be clear, the dib0700 does not actually support receiving RC5 or NEC codes at the same time. You have to tell the chip which mode to operate in, via a REQUEST_SET_RC to the firmware (see dib0700_core.c:405). The em28xx works the same way (you have to tell it what type of IR format to receive). The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. I did not follow all the discussion, still I have a comment: I will soon work on a device where it is the driver who is doing the decoding of the IR-frames. It is (maybe, I'm still missing some pieces to be sure) possible to receive different protocols at the same time with this hardware. -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Maxim Levitsky wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are well known. Most devices profiles are in the published One-for-All database. These device profiles consist of vendor/device/command triplets. There is one triplet for each command like play, pause, 1, 2, 3, power, etc. The second observation is that universal remotes know how to generate commands for all of the common devices. Let's define evdev messages for IR than contain vendor/device/command triplets. I already posted code for doing that in my original patch set. These messages are generated from in-kernel code. Now add a small amount of code to MythTV, etc to act on these evdev messages. Default MythTV, etc to respond to the IR commands for a common DVR device. Program your universal remote to send the commands for this device. You're done. Everything will just work - no LIRC, no irrecord, no config files, no command mapping, etc. You are making one big wrong assumption that everyone that has a remote uses mythtv, and only it. Many users including me, use the remote just like a keyboard, or even like a mouse. +1. I also use the remote as a keyboard replacement. I used an IR like that for a long time while teaching, using a standard USB video board, as a way to remotely control my notebook. Well, now I have an USB IR for this usage, using HID, that emulates both keyboard and mouse. In fact, the application didn't change. I'm just using the standard USB class for HID, instead of using vendor class to generate the same kind of evdev events ;) Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
Patrick Boettcher wrote: The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. I did not follow all the discussion, still I have a comment: I will soon work on a device where it is the driver who is doing the decoding of the IR-frames. It is (maybe, I'm still missing some pieces to be sure) possible to receive different protocols at the same time with this hardware. That's good news! Needing to pass a modprobe parameter to select the protocol is not nice, and, while an ioctl will be needed to select IR protocols (as there are some hardwares where this is not possible at all), the better is to auto-detect the protocol. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DIY Satellite Web Radio
On Mon, Nov 30, 2009 at 11:13 PM, OrazioPirataDelloSpazio (Lorenzo) ziducai...@autistici.org wrote: Hi all, I'm not a DVB expert but I'm wondering if this idea is feasible: For an amateur web radio, for what I know, it is really hard to being listened in cars, like people do with commercial satellite radio [1] . Basically this is unaffortable for private user and this is probably the most relevant factor that penalize web radios againt terrestrial one. My question is: is there any way to use the current, cheap, satellite internet connections to stream some data above all the coverage of a geo satellite? and make the receiver handy (so without any dishes) ? FWIW, you wont need a satellite dish (some of them operate in the L Band), unless you are very much out of the footprint, with a weak signal. Nevertheless, a parabolic reflector will give you a higher gain, but again that's not the choice for a receiving aerial in a moving vehicle. Such use cases use in some cases a flat panel antenna or an antenna array. DVB-RCS wouldn't work as it needs to be really pointed to the satellite, nor any Ku or C band transponders. The lower you are in the spectrum, the more likely to have a better reception with a lower gain reflector. http://en.wikipedia.org/wiki/1worldspace http://www.worldspace.com/howitworks/receivers/AGFwssr.html http://www.worldspace.com/coveragemaps/antennaguide.html http://www.satdirectory.com/--worldspace.html 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
[PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers
From: Muralidharan Karicheri m-kariche...@ti.com
Current implementation defines ccdc memory map in vpfe capture platform
file and update the same in ccdc through a function call. This will not
scale well. For example for DM365 CCDC, there are are additional memory
map for Linear table. So it is cleaner to define memory map for ccdc
driver in the platform file and read it by the ccdc platform driver during
probe.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next tree
drivers/media/video/davinci/dm355_ccdc.c | 89
drivers/media/video/davinci/dm644x_ccdc.c | 78
drivers/media/video/davinci/vpfe_capture.c | 49 +--
3 files changed, 145 insertions(+), 71 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 56fbefe..aacb95f 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,6 +37,7 @@
#include linux/platform_device.h
#include linux/uaccess.h
#include linux/videodev2.h
+#include mach/mux.h
#include media/davinci/dm355_ccdc.h
#include media/davinci/vpss.h
#include dm355_ccdc_regs.h
@@ -105,7 +106,6 @@ static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
static enum vpfe_hw_if_type ccdc_if_type;
static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
/* Raw Bayer formats */
static u32 ccdc_raw_bayer_pix_formats[] =
@@ -126,12 +126,6 @@ static inline void regw(u32 val, u32 offset)
__raw_writel(val, ccdc_base_addr + offset);
}
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
- ccdc_base_addr = addr;
- ccdc_addr_size = size;
-}
-
static void ccdc_enable(int en)
{
unsigned int temp;
@@ -938,7 +932,6 @@ static struct ccdc_hw_device ccdc_hw_dev = {
.hw_ops = {
.open = ccdc_open,
.close = ccdc_close,
- .set_ccdc_base = ccdc_set_ccdc_base,
.enable = ccdc_enable,
.enable_out_to_sdram = ccdc_enable_output_to_sdram,
.set_hw_if_params = ccdc_set_hw_if_params,
@@ -959,19 +952,89 @@ static struct ccdc_hw_device ccdc_hw_dev = {
},
};
-static int __init dm355_ccdc_init(void)
+static int __init dm355_ccdc_probe(struct platform_device *pdev)
{
- printk(KERN_NOTICE dm355_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ static resource_size_t res_len;
+ struct resource *res;
+ int status = 0;
+
+ /**
+* first try to register with vpfe. If not correct platform, then we
+* don't have to iomap
+*/
+ status = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (status 0)
+ return status;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ status = -ENOENT;
+ goto fail_nores;
+ }
+ res_len = res-end - res-start + 1;
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res) {
+ status = -EBUSY;
+ goto fail_nores;
+ }
+
+ ccdc_base_addr = ioremap_nocache(res-start, res_len);
+ if (!ccdc_base_addr) {
+ status = -EBUSY;
+ goto fail;
+ }
+ /**
+* setup Mux configuration for vpfe input and register
+* vpfe capture platform device
+*/
+ davinci_cfg_reg(DM355_VIN_PCLK);
+ davinci_cfg_reg(DM355_VIN_CAM_WEN);
+ davinci_cfg_reg(DM355_VIN_CAM_VD);
+ davinci_cfg_reg(DM355_VIN_CAM_HD);
+ davinci_cfg_reg(DM355_VIN_YIN_EN);
+ davinci_cfg_reg(DM355_VIN_CINL_EN);
+ davinci_cfg_reg(DM355_VIN_CINH_EN);
+
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
+fail:
+ release_mem_region(res-start, res_len);
+fail_nores:
+ vpfe_unregister_ccdc_device(ccdc_hw_dev);
+ return status;
}
-static void __exit dm355_ccdc_exit(void)
+static int dm355_ccdc_remove(struct platform_device *pdev)
{
+ struct resource *res;
+
+ iounmap(ccdc_base_addr);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res)
+ release_mem_region(res-start, res-end - res-start + 1);
vpfe_unregister_ccdc_device(ccdc_hw_dev);
+ return 0;
+}
+
+static struct platform_driver dm355_ccdc_driver = {
+ .driver = {
+ .name = dm355_ccdc,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(dm355_ccdc_remove),
+ .probe = dm355_ccdc_probe,
+};
+
+static int __init dm355_ccdc_init(void)
+{
+ return platform_driver_register(dm355_ccdc_driver);
+}
+
+static void __exit dm355_ccdc_exit(void)
+{
+ platform_driver_unregister(dm355_ccdc_driver);
}
module_init(dm355_ccdc_init);
diff --git
[PATCH 2/2] DaVinci - vpfe capture - converting ccdc to platform driver
From: Muralidharan Karicheri m-kariche...@ti.com
This is the platform part for converting ccdc to platform driver.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-davinci tree
arch/arm/mach-davinci/dm355.c | 27 +++
arch/arm/mach-davinci/dm644x.c | 18 +-
2 files changed, 32 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index dedf4d4..045cb0d 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -701,6 +701,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +712,17 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+ .name = dm355_ccdc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+ .resource = dm355_ccdc_resource,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -860,17 +873,7 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(dm355_edma_device);
platform_device_register(dm355_vpss_device);
- /*
-* setup Mux configuration for vpfe input and register
-* vpfe capture platform device
-*/
- davinci_cfg_reg(DM355_VIN_PCLK);
- davinci_cfg_reg(DM355_VIN_CAM_WEN);
- davinci_cfg_reg(DM355_VIN_CAM_VD);
- davinci_cfg_reg(DM355_VIN_CAM_HD);
- davinci_cfg_reg(DM355_VIN_YIN_EN);
- davinci_cfg_reg(DM355_VIN_CINL_EN);
- davinci_cfg_reg(DM355_VIN_CINH_EN);
+ platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..982be1f 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+ /* CCDC Base address */
{
.start = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
},
};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+ .name = dm644x_ccdc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_ccdc_resource),
+ .resource = dm644x_ccdc_resource,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
platform_device_register(dm644x_edma_device);
platform_device_register(dm644x_emac_device);
platform_device_register(dm644x_vpss_device);
+ platform_device_register(dm644x_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] media/radio/miro: depends on SND
From: Randy Dunlap randy.dun...@oracle.com miropcm20 uses ALSA (snd_) interfaces from the SND_MIRO driver, so it should depend on SND. (selecting SND_MIRO when CONFIG_SND is not enabled is a problem.) drivers/built-in.o: In function `vidioc_s_ctrl': radio-miropcm20.c:(.text+0x227499): undefined reference to `snd_aci_cmd' drivers/built-in.o: In function `vidioc_s_frequency': radio-miropcm20.c:(.text+0x227574): undefined reference to `snd_aci_cmd' radio-miropcm20.c:(.text+0x227588): undefined reference to `snd_aci_cmd' drivers/built-in.o: In function `pcm20_init': radio-miropcm20.c:(.init.text+0x2a784): undefined reference to `snd_aci_get_aci' Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/radio/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20091201.orig/drivers/media/radio/Kconfig +++ linux-next-20091201/drivers/media/radio/Kconfig @@ -197,7 +197,7 @@ config RADIO_MAESTRO config RADIO_MIROPCM20 tristate miroSOUND PCM20 radio - depends on ISA VIDEO_V4L2 + depends on ISA VIDEO_V4L2 SND select SND_MIRO ---help--- Choose Y here if you have this FM radio card. You also need to enable -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DIY Satellite Web Radio
On Tue, Dec 1, 2009 at 12:42 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 30-11-2009 17:13, OrazioPirataDelloSpazio (Lorenzo) escreveu: Hi all, I'm not a DVB expert but I'm wondering if this idea is feasible: For an amateur web radio, for what I know, it is really hard to being listened in cars, like people do with commercial satellite radio [1] . Basically this is unaffortable for private user and this is probably the most relevant factor that penalize web radios againt terrestrial one. My question is: is there any way to use the current, cheap, satellite internet connections to stream some data above all the coverage of a geo satellite? and make the receiver handy (so without any dishes) ? Receiving sat signals without dishes? From some trials we had on a telco I used to work, You would need to use a network of low-orbit satellites, carefully choosing the better frequencies and it will provide you low bandwidth. This will likely cost a lot of money, if you find someone providing a service like that. One trial for such network were the Iridum project. AFAIK, the original company bankrupted due to the very high costs of launching and managing about a hundred satellite network. Low orbital satellites aren't geo-stationary. Technically speaking, a broadcaster would use only geo-stationary satellites for broadcast services. The basic reason: A broadcaster simply would have rented out a transponder on an existing satellite from a satellite operator, or still: if the broadcaster is a major player, they would have a few satellites of their own to provide coverage over multiple regions, but still: they are indeed geo-stationary satellites (you will need a very large number of satellites to provide services in a low orbital position, similar to the Iridium network, which is not practically feasible for a broadcaster. Even the Iridium network had a hard time taking off!) 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
Re: [GIT PULL for 2.6.32] V4L/DVB updates
Mike Isely wrote: On Mon, 30 Nov 2009, Mauro Carvalho Chehab wrote: Em Sat, 28 Nov 2009 14:33:30 -0600 (CST) Mike Isely is...@isely.net escreveu: Mauro: I had also posted up two high priority pvrusb2 patches that should really be cherry-picked for 2.6.32. You've already pulled them into v4l/dvb and I did mark them as high priority at the time. These patches enable use of FX2 microcontroller firmware that is 16KB in size. Hauppauge is no longer shipping 8KB firmware for HVR-1950 and HVR-1900 and without these changes then those devices won't work AT ALL in kernel 2.6.32. You can find these within the v4l-dvb Mercurial repository here: Changeset 13495:87c3853fe2b3 Subject: pvrusb2: Support 16KB FX2 firmware http://linuxtv.org/hg/v4l-dvb/rev/87c3853fe2b3 Changeset 13500:d4c418d4b25c Subject: pvrusb2: Fix lingering 16KB FX2 Firmware issues http://linuxtv.org/hg/v4l-dvb/rev/d4c418d4b25c I do not believe these patches have any ordering dependencies with other patches, though between the two the second one technically should come after the first. There are. Picking just those patches broke compilation. Mauro: Please forward to me the compilation errors. Right now I am just not seeing how a patch this trivial could have any compilation dependencies. And unfortunately I will not be able to reproduce your build setup until at least Tuesday night. I must be blind. Also, it seemed too late for adding support for newer boards/firmware when Linus is about to release a kernel. This is not a new feature. It's a bug fix due to something that Hauppauge recently did. Hauppauge is NO LONGER officially distributing FX2 firmware with their hardware which the driver can use. This simply prevents any new HVR-1950 / HVR-1900 users from working under Linux. This fixes breakage for previously working hardware. The root cause is simple - the firmware blob is just larger now - and the fix is trivial. It absolutely needs to go in. In fact, this should go back to a 2.6.31.x and a 2.6.27.x release as well, though in those cases I have to figure out if driver source code is still close enough for the same patches to still work. I am sorry this is showing up late for you. There are multiple reasons for this. However I did mark these patches as high priority, following your v4l-dvb changeset process. I did comment on the pull request that these were important but I guess I needed to also specifically call these out in the pull request text as well. If these don't get in now as part of the official 2.6.32 release, these absolutely need to be queued for 2.6.32.1. We are very late for 2.6.32. I'm not sure if are there still time for it. I'll seek for some time during this week to add those patches at the upstream tree and removing them from the development tree and see what compilation issues arise. Cheers, Mauro. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Due to the lack of an API for it, each driver has their own way to handle the protocols, but basically, on almost all drivers, even supporting different protocols, the driver limits the usage of just the protocol provided by the shipped remote. To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. evdev capabilities bits can support enumerating the supported protocols. I'm not sure if you can write those bits back into evdev to turn a feature off/on. If not its something that could be added to evdev. I agree that there is no consistency in the existing driver implementations. -- Jon Smirl jonsm...@gmail.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 v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 11:46 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath,
Vaibhav; Karicheri, Muralidharan
Subject: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to
platform drivers
From: Muralidharan Karicheri m-kariche...@ti.com
Current implementation defines ccdc memory map in vpfe capture
platform
file and update the same in ccdc through a function call. This will
not
scale well. For example for DM365 CCDC, there are are additional
memory
map for Linear table. So it is cleaner to define memory map for ccdc
driver in the platform file and read it by the ccdc platform driver
during
probe.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next tree
drivers/media/video/davinci/dm355_ccdc.c | 89
drivers/media/video/davinci/dm644x_ccdc.c | 78
drivers/media/video/davinci/vpfe_capture.c | 49 +--
3 files changed, 145 insertions(+), 71 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 56fbefe..aacb95f 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,6 +37,7 @@
#include linux/platform_device.h
#include linux/uaccess.h
#include linux/videodev2.h
+#include mach/mux.h
[Hiremath, Vaibhav] This should not be here, this should get handled in board
file. The driver should be generic.
#include media/davinci/dm355_ccdc.h
#include media/davinci/vpss.h
#include dm355_ccdc_regs.h
@@ -105,7 +106,6 @@ static struct ccdc_params_ycbcr
ccdc_hw_params_ycbcr = {
static enum vpfe_hw_if_type ccdc_if_type;
static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
/* Raw Bayer formats */
static u32 ccdc_raw_bayer_pix_formats[] =
@@ -126,12 +126,6 @@ static inline void regw(u32 val, u32 offset)
__raw_writel(val, ccdc_base_addr + offset);
}
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
- ccdc_base_addr = addr;
- ccdc_addr_size = size;
-}
-
static void ccdc_enable(int en)
{
unsigned int temp;
@@ -938,7 +932,6 @@ static struct ccdc_hw_device ccdc_hw_dev = {
.hw_ops = {
.open = ccdc_open,
.close = ccdc_close,
- .set_ccdc_base = ccdc_set_ccdc_base,
.enable = ccdc_enable,
.enable_out_to_sdram = ccdc_enable_output_to_sdram,
.set_hw_if_params = ccdc_set_hw_if_params,
@@ -959,19 +952,89 @@ static struct ccdc_hw_device ccdc_hw_dev = {
},
};
-static int __init dm355_ccdc_init(void)
+static int __init dm355_ccdc_probe(struct platform_device *pdev)
{
- printk(KERN_NOTICE dm355_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ static resource_size_t res_len;
+ struct resource *res;
+ int status = 0;
+
+ /**
+ * first try to register with vpfe. If not correct platform,
then we
+ * don't have to iomap
+ */
+ status = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (status 0)
+ return status;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ status = -ENOENT;
[Hiremath, Vaibhav] I think right return value is -ENODEV.
+ goto fail_nores;
+ }
+ res_len = res-end - res-start + 1;
+
+ res = request_mem_region(res-start, res_len, res-name);
[Hiremath, Vaibhav] You should use resource_size here for res_len here.
+ if (!res) {
+ status = -EBUSY;
+ goto fail_nores;
+ }
+
+ ccdc_base_addr = ioremap_nocache(res-start, res_len);
+ if (!ccdc_base_addr) {
+ status = -EBUSY;
[Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be -ENXIO
or -ENOMEM.
+ goto fail;
+ }
+ /**
+ * setup Mux configuration for vpfe input and register
+ * vpfe capture platform device
+ */
+ davinci_cfg_reg(DM355_VIN_PCLK);
+ davinci_cfg_reg(DM355_VIN_CAM_WEN);
+ davinci_cfg_reg(DM355_VIN_CAM_VD);
+ davinci_cfg_reg(DM355_VIN_CAM_HD);
+ davinci_cfg_reg(DM355_VIN_YIN_EN);
+ davinci_cfg_reg(DM355_VIN_CINL_EN);
+ davinci_cfg_reg(DM355_VIN_CINH_EN);
+
[Hiremath, Vaibhav] This should not be here, this code must be generic and
might get used in another SoC.
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
+fail:
+ release_mem_region(res-start, res_len);
+fail_nores:
+ vpfe_unregister_ccdc_device(ccdc_hw_dev);
+ return status;
}
-static void __exit dm355_ccdc_exit(void)
+static int dm355_ccdc_remove(struct platform_device *pdev)
{
RE: [PATCH 2/2] DaVinci - vpfe capture - converting ccdc to platform driver
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 11:46 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath,
Vaibhav; Karicheri, Muralidharan
Subject: [PATCH 2/2] DaVinci - vpfe capture - converting ccdc to
platform driver
From: Muralidharan Karicheri m-kariche...@ti.com
This is the platform part for converting ccdc to platform driver.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-davinci tree
arch/arm/mach-davinci/dm355.c | 27 +++
arch/arm/mach-davinci/dm644x.c | 18 +-
2 files changed, 32 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-
davinci/dm355.c
index dedf4d4..045cb0d 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -701,6 +701,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +712,17 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+ .name = dm355_ccdc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+ .resource = dm355_ccdc_resource,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -860,17 +873,7 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(dm355_edma_device);
platform_device_register(dm355_vpss_device);
- /*
- * setup Mux configuration for vpfe input and register
- * vpfe capture platform device
- */
- davinci_cfg_reg(DM355_VIN_PCLK);
- davinci_cfg_reg(DM355_VIN_CAM_WEN);
- davinci_cfg_reg(DM355_VIN_CAM_VD);
- davinci_cfg_reg(DM355_VIN_CAM_HD);
- davinci_cfg_reg(DM355_VIN_YIN_EN);
- davinci_cfg_reg(DM355_VIN_CINL_EN);
- davinci_cfg_reg(DM355_VIN_CINH_EN);
[Hiremath, Vaibhav] Why have you removed mux configuration from here and moved
to CCDC driver? Any specific reason?
+ platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
davinci/dm644x.c
index 2cd0081..982be1f 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+ /* CCDC Base address */
{
.start = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
},
};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+ .name = dm644x_ccdc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_ccdc_resource),
+ .resource = dm644x_ccdc_resource,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
platform_device_register(dm644x_edma_device);
platform_device_register(dm644x_emac_device);
platform_device_register(dm644x_vpss_device);
+ platform_device_register(dm644x_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Dec 1 19:00:02 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13538:e0cd9a337600 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc8-armv5: OK linux-2.6.32-rc8-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-rc8-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-rc8-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-rc8-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc8-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-rc8-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-rc8-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-rc8-x86_64: OK spec: OK sparse (linux-2.6.31): ERRORS sparse (linux-2.6.32-rc8): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace Mercurial with GIT as SCM
On Tue, 1 Dec 2009, Patrick Boettcher wrote: To start right away: I'm in favour of using GIT because of difficulties I have with my daily work with v4l-dvb. It is in my nature do to mistakes, so I need a tool which assists me in fixing those, I have not found a simple way to do my stuff with HG. Try the mq extension. It's included by default with mercurial, you just need to add: [extensions] hgext.mq= to your .hgrc file. It lets you maintain a stack of patches that you can freely push and pop. You can make changes and then commit them to one of the existing patches. Like git commit -amend, except you can amend any patch not just the last one. IMHO, it's better than stock git when you're trying to make a good patch series. There is something called stgit which is very much like mq and a little better I think. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] Another approach to IR
On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. Or, in certain cases, it can not. [... skipped rationale for adding a way to control protocol (with which I agree) ...] To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. -- Dmitry -- 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
af9015: tuner id:179 not supported, please report!
Hi, I just received a usb DVB-T card and have been trying to get it to work under Ubuntu 9.10, but to no avail. dmesg shows the following when plugging in the card: [ 35.280024] usb 2-1: new high speed USB device using ehci_hcd and address 4 [ 35.435978] usb 2-1: configuration #1 chosen from 1 choice [ 35.450176] af9015: tuner id:179 not supported, please report! [ 35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 - 7 [ 35.453097] input: Afatech DVB-T 2 as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8 [ 35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1 lsusb shows: Bus 002 Device 005: ID 15a4:9016 and finally lsmod | grep dvb dvb_usb_af9015 37152 0 dvb_usb22892 1 dvb_usb_af9015 dvb_core 109716 1 dvb_usb While googling for an answer to my troubles I came across http://ubuntuforums.org/showthread.php?t=606487page=5 which hints that the card may use the TDA18218HK tuner chip which does not seem to be supported currently. Does anyone have any experience regarding this chip and know what to do to get it working. Best regards, //Jan -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: WARNINGS
Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Dec 1 19:00:02 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13538:e0cd9a337600 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 [...] Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log linux-2.6.29.1-i686: WARNINGS /marune/build/v4l-dvb-master/v4l/firedtv-1394.c:264: warning: initialization discards qualifiers from pointer target type linux-2.6.29.1-x86_64: WARNINGS /marune/build/v4l-dvb-master/v4l/firedtv-1394.c:264: warning: initialization discards qualifiers from pointer target type I found about this two warnings that this module is not to be built with 2.6.29.1 according to the following lines from version.txt: [2.6.30] # Needs const id_table pointer in struct hpsb_protocol_driver DVB_FIREDTV_IEEE1394 I'm not sure whether the script v4l/scripts/make_kconfig.pl is working correctly or not. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5 - v0] V4L - vpfe capture enhancements to support DM365
From: Muralidharan Karicheri m-kariche...@ti.com
This patch adds support for handling CCDC configuration ioctl. A new
IOCTL added to support reading current configuration at CCDC.
NOTE: This is the initial version for review.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 74 +++-
include/media/davinci/vpfe_capture.h |5 ++-
2 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 35bbb08..ae8f993 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -759,12 +759,83 @@ static unsigned int vpfe_poll(struct file *file,
poll_table *wait)
return 0;
}
+static long vpfe_param_handler(struct file *file, void *priv,
+ int cmd, void *param)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ int ret = 0;
+
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
+
+ if (NULL == param) {
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ Invalid user ptr\n);
+ }
+
+ if (vpfe_dev-started) {
+ /* only allowed if streaming is not started */
+ v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
+ return -EBUSY;
+ }
+
+
+ switch (cmd) {
+ case VPFE_CMD_S_CCDC_RAW_PARAMS:
+ v4l2_warn(vpfe_dev-v4l2_dev,
+ VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
+ ret = mutex_lock_interruptible(vpfe_dev-lock);
+ if (ret)
+ return ret;
+ ret = ccdc_dev-hw_ops.set_params(param);
+ if (ret) {
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ Error in setting parameters in CCDC\n);
+ goto unlock_out;
+ }
+
+ if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt) 0) {
+ v4l2_err(vpfe_dev-v4l2_dev,
+ Invalid image format at CCDC\n);
+ ret = -EINVAL;
+ }
+unlock_out:
+ mutex_unlock(vpfe_dev-lock);
+ break;
+ case VPFE_CMD_G_CCDC_RAW_PARAMS:
+ v4l2_warn(vpfe_dev-v4l2_dev,
+ VPFE_CMD_G_CCDC_RAW_PARAMS: experimental ioctl\n);
+ if (!ccdc_dev-hw_ops.get_params) {
+ ret = -EINVAL;
+ break;
+ }
+ ret = ccdc_dev-hw_ops.get_params(param);
+ if (ret) {
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ Error in getting parameters from CCDC\n);
+ }
+ break;
+
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static long vpfe_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ if (cmd == VPFE_CMD_S_CCDC_RAW_PARAMS ||
+ cmd == VPFE_CMD_G_CCDC_RAW_PARAMS)
+ return vpfe_param_handler(file, file-private_data, cmd,
+(void *)arg);
+ return video_ioctl2(file, cmd, arg);
+}
+
/* vpfe capture driver file operations */
static const struct v4l2_file_operations vpfe_fops = {
.owner = THIS_MODULE,
.open = vpfe_open,
.release = vpfe_release,
- .unlocked_ioctl = video_ioctl2,
+ .unlocked_ioctl = vpfe_ioctl,
.mmap = vpfe_mmap,
.poll = vpfe_poll
};
@@ -1751,7 +1822,6 @@ static const struct v4l2_ioctl_ops vpfe_ioctl_ops = {
.vidioc_cropcap = vpfe_cropcap,
.vidioc_g_crop = vpfe_g_crop,
.vidioc_s_crop = vpfe_s_crop,
- .vidioc_default = vpfe_param_handler,
};
static struct vpfe_device *vpfe_initialize(void)
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index 7b62a5c..1e6817c 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -71,7 +71,7 @@ struct vpfe_subdev_info {
/* Sub dev routing information for each input */
struct vpfe_route *routes;
/* check if sub dev supports routing */
- int can_route;
+ int can_route:1;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
@@ -202,4 +202,7 @@ struct vpfe_config_params {
**/
#define VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
void *)
+#define VPFE_CMD_G_CCDC_RAW_PARAMS _IOR('V', BASE_VIDIOC_PRIVATE + 2, \
+ void *)
+
#endif /* _DAVINCI_VPFE_H */
--
1.6.0.4
--
To unsubscribe from this list: send the line
[PATCH 5/5 - v0] DaVinci - vpfe capture - platform changes for DM365 CCDC
From: Muralidharan Karicheri m-kariche...@ti.com
Adds platform and board specific changes to support YUV video capture on
DM365.
NOTE: This patch is for review purpose only
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
arch/arm/mach-davinci/board-dm365-evm.c| 74 +++
arch/arm/mach-davinci/dm365.c | 90 +++-
arch/arm/mach-davinci/include/mach/dm365.h |2 +
3 files changed, 165 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 8d23972..c9f09e5 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -24,6 +24,7 @@
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/input.h
+#include linux/videodev2.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -37,6 +38,9 @@
#include mach/nand.h
#include mach/keyscan.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
static inline int have_imager(void)
{
/* REVISIT when it's supported, trigger via Kconfig */
@@ -305,6 +309,74 @@ static void dm365evm_mmc_configure(void)
davinci_cfg_reg(DM365_SD1_DATA0);
}
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+{
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5d),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM365 EVM,
+ .ccdc = DM365 ISIF,
+ .num_clocks = 1,
+ .clocks = {vpss_master},
+};
+
static void __init evm_init_i2c(void)
{
davinci_init_i2c(i2c_pdata);
@@ -496,6 +568,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm365_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
}
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 2ec619e..d9718aa 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1009,6 +1009,87 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
}
+static struct resource dm365_vpss_resources[] = {
+ {
+ /* VPSS ISP5 Base address */
+ .name = vpss,
+ .start = 0x01c7,
+ .end= 0x01c7 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* VPSS CLK Base address */
+ .name = vpss,
+ .start = 0x01c70200,
+ .end= 0x01c70200 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm365_vpss_device = {
+ .name = vpss,
+ .id = -1,
+ .dev.platform_data = dm365_vpss,
+ .num_resources = ARRAY_SIZE(dm365_vpss_resources),
+ .resource = dm365_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+ {
+ .start = IRQ_VDINT0,
+ .end= IRQ_VDINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+
[PATCH 4/5 - v0] V4L - vpfe capture - build environment to support DM365 CCDC
From: Muralidharan Karicheri m-kariche...@ti.com Added support for building DM365 CCDC module. Also made VPSS module default configuration variable value to n. NOTE: This patch is for review purpose only Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- drivers/media/video/Kconfig | 15 ++- drivers/media/video/davinci/Makefile |1 + 2 files changed, 15 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9dc74c9..6d3ae06 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -552,7 +552,7 @@ config VIDEO_VPSS_SYSTEM depends on ARCH_DAVINCI help Support for vpss system module for video driver - default y + default n config VIDEO_VPFE_CAPTURE tristate VPFE Video Capture Driver @@ -596,6 +596,19 @@ config VIDEO_DM355_CCDC To compile this driver as a module, choose M here: the module will be called vpfe. +config VIDEO_DM365_ISIF + tristate DM365 CCDC/ISIF HW module + depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DM365 ISIF hw module. This is the hardware module for + configuring ISIF in VPFE to capture Raw Bayer RGB data from + a image sensor or YUV data from a YUV source. + + To compile this driver as a module, choose M here: the + module will be called vpfe. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index 1a8b8f3..3642d79 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -15,3 +15,4 @@ obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o +obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] V4L - vpfe-capture - updates to vpss module to support DM365
From: Muralidharan Karicheri m-kariche...@ti.com
This patch does following changes:-
1) Added support for ISP5 and VPSS modules configuration for DM365
2) renamed few variables to make it more generic
NOTE: This is the initial version for review.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpss.c | 290 +---
include/media/davinci/vpss.h | 41 +-
2 files changed, 277 insertions(+), 54 deletions(-)
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
index 6d709ca..3820e13 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -15,7 +15,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
- * common vpss driver for all video drivers.
+ * common vpss system module platform driver for all video drivers.
*/
#include linux/kernel.h
#include linux/sched.h
@@ -35,12 +35,52 @@ MODULE_AUTHOR(Texas Instruments);
/* DM644x defines */
#define DM644X_SBL_PCR_VPSS(4)
+#define DM355_VPSSBL_INTSEL0x10
+#define DM355_VPSSBL_EVTSEL0x14
/* vpss BL register offsets */
#define DM355_VPSSBL_CCDCMUX 0x1c
/* vpss CLK register offsets */
#define DM355_VPSSCLK_CLKCTRL 0x04
/* masks and shifts */
#define VPSS_HSSISEL_SHIFT 4
+/*
+ * VDINT0 - vpss_int0, VDINT1 - vpss_int1, H3A - vpss_int4,
+ * IPIPE_INT1_SDR - vpss_int5
+ */
+#define DM355_VPSSBL_INTSEL_DEFAULT0xff83ff10
+/* VENCINT - vpss_int8 */
+#define DM355_VPSSBL_EVTSEL_DEFAULT0x4
+
+#define DM365_ISP5_PCCR0x04
+#define DM365_ISP5_INTSEL1 0x10
+#define DM365_ISP5_INTSEL2 0x14
+#define DM365_ISP5_INTSEL3 0x18
+#define DM365_ISP5_CCDCMUX 0x20
+#define DM365_ISP5_PG_FRAME_SIZE 0x28
+#define DM365_VPBE_CLK_CTRL0x00
+/*
+ * vpss interrupts. VDINT0 - vpss_int0, VDINT1 - vpss_int1,
+ * AF - vpss_int3
+ */
+#define DM365_ISP5_INTSEL1_DEFAULT 0x0b1f0100
+/* AEW - vpss_int6, RSZ_INT_DMA - vpss_int5 */
+#define DM365_ISP5_INTSEL2_DEFAULT 0x1f0a0f1f
+/* VENC - vpss_int8 */
+#define DM365_ISP5_INTSEL3_DEFAULT 0x0015
+
+/* masks and shifts for DM365*/
+#define DM365_CCDC_PG_VD_POL_SHIFT 0
+#define DM365_CCDC_PG_HD_POL_SHIFT 1
+
+#define CCD_SRC_SEL_MASK (BIT_MASK(5) | BIT_MASK(4))
+#define CCD_SRC_SEL_SHIFT 4
+
+/* Different SoC platforms supported by this driver */
+enum vpss_platform_type {
+ DM644X,
+ DM355,
+ DM365,
+};
/*
* vpss operations. Depends on platform. Not all functions are available
@@ -59,13 +99,9 @@ struct vpss_hw_ops {
/* vpss configuration */
struct vpss_oper_config {
- __iomem void *vpss_bl_regs_base;
- __iomem void *vpss_regs_base;
- struct resource *r1;
- resource_size_t len1;
- struct resource *r2;
- resource_size_t len2;
- char vpss_name[32];
+ __iomem void *vpss_regs_base0;
+ __iomem void *vpss_regs_base1;
+ enum vpss_platform_type platform;
spinlock_t vpss_lock;
struct vpss_hw_ops hw_ops;
};
@@ -75,22 +111,46 @@ static struct vpss_oper_config oper_cfg;
/* register access routines */
static inline u32 bl_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
}
static inline void bl_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
}
static inline u32 vpss_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
}
static inline void vpss_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
+}
+
+/* For DM365 only */
+static inline u32 isp5_read(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+/* For DM365 only */
+static inline void isp5_write(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ u32 temp = isp5_read(DM365_ISP5_CCDCMUX) ~CCD_SRC_SEL_MASK;
+
+ /* if we are using pattern generator, enable it */
+ if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+ temp |= 0x08;
+
+ temp |= (src_sel CCD_SRC_SEL_SHIFT);
+ isp5_write(temp, DM365_ISP5_CCDCMUX);
}
static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -101,9 +161,9 @@ static void dm355_select_ccdc_source(enum
vpss_ccdc_source_sel src_sel)
int vpss_select_ccdc_source(enum
linux-media documentation fails to build
Hi, I had downloaded the v4l2-dvb tree few days back to create my video timings API documentation and it had compiled fine when I did, make media-spec I still can build using the old tar ball. But today, I downloaded v4l-dvb-e0cd9a337600.tar.gz, it fails immediately after running the make_myconfig.pl script with the error No rule to make target 'media-spec'. Stop Has something changed last few days that broke the build? I need to make updates to video timing API documentation based on Han's review comments and I am stuck at this issue now :( Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.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: linux-media documentation fails to build
Some body removed media-spec target from v4l/Makefile. I got it working with make spec. Why to change target name like this? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan Sent: Tuesday, December 01, 2009 5:28 PM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab; Hans Verkuil Subject: linux-media documentation fails to build Hi, I had downloaded the v4l2-dvb tree few days back to create my video timings API documentation and it had compiled fine when I did, make media-spec I still can build using the old tar ball. But today, I downloaded v4l-dvb- e0cd9a337600.tar.gz, it fails immediately after running the make_myconfig.pl script with the error No rule to make target 'media-spec'. Stop Has something changed last few days that broke the build? I need to make updates to video timing API documentation based on Han's review comments and I am stuck at this issue now :( Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.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 -- 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: Replace Mercurial with GIT as SCM
On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote: Hi all, I would like to start a discussion which ideally results in either changing the SCM of v4l-dvb to git _or_ leaving everything as it is today with mercurial. I'm waiting for comments. I only have one requirement: reduce bandwidth usage between the server and my home. The less I have to clone out 65 M of history to start a new series of patches the better. I suppose that would include a rebase... 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 2/3] radio-si470x: move some file operations to common file
Hi,
yes, good point.
Acked-by: Tobias Lorenz tobias.lor...@gmx.net
Bye,
Toby
Am Mittwoch 18 November 2009 07:21:30 schrieb Joonyoung Shim:
The read and poll file operations of the si470x usb driver can be used
also equally on the si470x i2c driver, so they go to the common file.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/media/radio/si470x/radio-si470x-common.c | 98
++
drivers/media/radio/si470x/radio-si470x-i2c.c| 15 +---
drivers/media/radio/si470x/radio-si470x-usb.c| 97
+-
drivers/media/radio/si470x/radio-si470x.h|3 +-
4 files changed, 104 insertions(+), 109 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 7296cf4..f4645d4 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -426,6 +426,104 @@ int si470x_rds_on(struct si470x_device *radio)
/**
+ * File Operations Interface
+ **/
+
+/*
+ * si470x_fops_read - read RDS data
+ */
+static ssize_t si470x_fops_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct si470x_device *radio = video_drvdata(file);
+ int retval = 0;
+ unsigned int block_count = 0;
+
+ /* switch on rds reception */
+ if ((radio-registers[SYSCONFIG1] SYSCONFIG1_RDS) == 0)
+ si470x_rds_on(radio);
+
+ /* block if no new data available */
+ while (radio-wr_index == radio-rd_index) {
+ if (file-f_flags O_NONBLOCK) {
+ retval = -EWOULDBLOCK;
+ goto done;
+ }
+ if (wait_event_interruptible(radio-read_queue,
+ radio-wr_index != radio-rd_index) 0) {
+ retval = -EINTR;
+ goto done;
+ }
+ }
+
+ /* calculate block count from byte count */
+ count /= 3;
+
+ /* copy RDS block out of internal buffer and to user buffer */
+ mutex_lock(radio-lock);
+ while (block_count count) {
+ if (radio-rd_index == radio-wr_index)
+ break;
+
+ /* always transfer rds complete blocks */
+ if (copy_to_user(buf, radio-buffer[radio-rd_index], 3))
+ /* retval = -EFAULT; */
+ break;
+
+ /* increment and wrap read pointer */
+ radio-rd_index += 3;
+ if (radio-rd_index = radio-buf_size)
+ radio-rd_index = 0;
+
+ /* increment counters */
+ block_count++;
+ buf += 3;
+ retval += 3;
+ }
+ mutex_unlock(radio-lock);
+
+done:
+ return retval;
+}
+
+
+/*
+ * si470x_fops_poll - poll RDS data
+ */
+static unsigned int si470x_fops_poll(struct file *file,
+ struct poll_table_struct *pts)
+{
+ struct si470x_device *radio = video_drvdata(file);
+ int retval = 0;
+
+ /* switch on rds reception */
+ if ((radio-registers[SYSCONFIG1] SYSCONFIG1_RDS) == 0)
+ si470x_rds_on(radio);
+
+ poll_wait(file, radio-read_queue, pts);
+
+ if (radio-rd_index != radio-wr_index)
+ retval = POLLIN | POLLRDNORM;
+
+ return retval;
+}
+
+
+/*
+ * si470x_fops - file operations interface
+ */
+static const struct v4l2_file_operations si470x_fops = {
+ .owner = THIS_MODULE,
+ .read = si470x_fops_read,
+ .poll = si470x_fops_poll,
+ .ioctl = video_ioctl2,
+ .open = si470x_fops_open,
+ .release= si470x_fops_release,
+};
+
+
+
+/**
* Video4Linux Interface
**/
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 2d53b6a..4816a6d 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -173,7 +173,7 @@ int si470x_disconnect_check(struct si470x_device *radio)
/*
* si470x_fops_open - file open
*/
-static int si470x_fops_open(struct file *file)
+int si470x_fops_open(struct file *file)
{
struct si470x_device *radio = video_drvdata(file);
int retval = 0;
@@ -194,7 +194,7 @@ static int si470x_fops_open(struct file *file)
/*
* si470x_fops_release - file release
*/
-static int si470x_fops_release(struct file *file)
+int si470x_fops_release(struct file *file)
{
struct si470x_device *radio =
Re: [PATCH 1/3] radio-si470x: fix SYSCONFIG1 register set on si470x_start()
Hi, Tobias. On 12/2/2009 8:39 AM, Tobias Lorenz wrote: Hi, what is the advantage in not setting SYSCONFIG1 into a known state? At patch 3/3, i am setting the SYSCONFIG1 register for RDS interrupt in i2c probe function, so i need this patch. Do you have other idea? Bye, Toby Am Mittwoch 18 November 2009 07:21:25 schrieb Joonyoung Shim: We should use the or operation to set value to the SYSCONFIG1 register on si470x_start(). Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- drivers/media/radio/si470x/radio-si470x-common.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/radio/si470x/radio-si470x-common.c b/drivers/media/radio/si470x/radio-si470x-common.c index f33315f..09f631a 100644 --- a/drivers/media/radio/si470x/radio-si470x-common.c +++ b/drivers/media/radio/si470x/radio-si470x-common.c @@ -357,7 +357,7 @@ int si470x_start(struct si470x_device *radio) goto done; /* sysconfig 1 */ -radio-registers[SYSCONFIG1] = SYSCONFIG1_DE; +radio-registers[SYSCONFIG1] |= SYSCONFIG1_DE; retval = si470x_set_register(radio, SYSCONFIG1); if (retval 0) goto done; -- 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: Replace Mercurial with GIT as SCM
On Tue, Dec 01, 2009 at 06:25:00PM -0500, Andy Walls wrote: On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote: Hi all, I would like to start a discussion which ideally results in either changing the SCM of v4l-dvb to git _or_ leaving everything as it is today with mercurial. I'm waiting for comments. I only have one requirement: reduce bandwidth usage between the server and my home. The less I have to clone out 65 M of history to start a new series of patches the better. I suppose that would include a rebase... no, it would not. in case you feel better to clone something before a rebase, you can clone it locally. rebasing is an easily abused practice which destroys the history of a branch and puts in trouble the followers of that branch. published branch which is often rebased is usually frown upon. git is a branch-merge-branch-throw-away-branch-branch-merge-... tool. commit massaging is another tempting practice, it's so easy to produce a cleaned up history of your branch. writing code in 2D is already pretty difficult, God save us from writing code in 3D. cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- 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: Compile error saa7134 - compro videomate S350
Hi, Am Montag, den 30.11.2009, 14:35 -0800 schrieb Dominic Fernandes: Hi Hermann, There is a sign of life coming from the card (I connected my SAT finder and got a loud tone from it). You might want to set dvb_powerdown_on_sleep=0 for dvb_core. How do you specify this and which file (saa7134-dvb.c or saa7134-core.c or some other file)? as said above, you set it for dvb_core. I tried Kaffeine, to scan Astra 19.2 but no luck, at first I can see the signal meters light up and then stop. The output from dmesg at this point shows: [ 72.944834] DVB: registering adapter 0 frontend 0 (Zarlink ZL10313 DVB-S)... [ 2183.208025] DVB: adapter 0 frontend 0 frequency 7401500 out of range (95..215) [ 2191.756534] DVB: adapter 0 frontend 0 frequency 7401500 out of range (95..215) [ 2195.908528] DVB: adapter 0 frontend 0 frequency 7401500 out of range (95..215) Not sure what this means. Nothing good at all. Likely there is some breakage in the maths across devices/modules, often caused by different xtals/oscillators not sufficiently covered yet. For sure enough to get you out of the game for now. If Richard's card still works with latest v4l-dvb and his patch, likely you have slightly different hardware covered by the same driver too, including to hit a freq calculation bug exclusively. Can't tell from your input. The eeproms of yours and Richard's card differ in byte 0x74 and 0x75. Don't know what that means. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] radio-si470x: fix SYSCONFIG1 register set on si470x_start()
On 12/2/2009 9:12 AM, Tobias Lorenz wrote: Hi, ok, understood this problem. So, why not set this in si470x_fops_open directly after the si470x_start? It seems more appropriate to enable the RDS interrupt after starting the radio. OK, it makes sense. I will move it in si470x_fops_open. Bye the way, you pointed me to a bug. Instead of always setting de-emphasis in si470x_start: radio-registers[SYSCONFIG1] = SYSCONFIG1_DE; This should only be done, if requested by module parameter: radio-registers[SYSCONFIG1] = (de 11) SYSCONFIG1_DE; /* DE */ Ah, That's right. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dvb_usb_dib0700 ( T14BR) not initializing on reboot
I have a DVB-T USB device ( T14BR), which seems to work fine when I plug in my Fedora 10 box but I if I reboot with device connected it regularity fails to initialise correctly and to correct I have to remove unplug-device remove the module and reload module to fix up and only after system has been fully booted eg modprobe -r dvb-usb-dib0700 then modprobe dvb-usb-dib0700 adapter_nr=2 and then plug device in. I get the following msgs when it seems to fail and the second set when it works kernel log (failed) Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 2 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 3 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 4 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 5 Nov 22 13:51:50 mythbox kernel: usb 2-8: new low speed USB device using ohci_hcd and address 6 Nov 22 13:51:50 mythbox kernel: usb 2-8: configuration #1 chosen from 1 choice Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device found, idVendor=413c, idProduct=3010 Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver hiddev Nov 22 13:51:50 mythbox kernel: input: HID 413c:3010 as /devices/pci:00/:00:02.0/usb2/2-8/2-8:1.0/input/input4 Nov 22 13:51:50 mythbox kernel: input,hidraw0: USB HID v1.00 Mouse [HID 413c:3010] on usb-:00:02.0-8 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver usbhid Nov 22 13:51:50 mythbox kernel: usbhid: v2.6:USB HID core driver http://www.artectv.com/ehtm/products/t14.htm kernel log (working) Nov 29 09:58:20 mythbox kernel: usb 1-8: new high speed USB device using ehci_hcd and address 3 Nov 29 09:58:20 mythbox kernel: usb 1-8: configuration #1 chosen from 1 choice Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device found, idVendor=05d8, idProduct=810f Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 29 09:58:20 mythbox kernel: usb 1-8: Product: ART7070 Nov 29 09:58:20 mythbox kernel: usb 1-8: Manufacturer: Ultima Nov 29 09:58:20 mythbox kernel: usb 1-8: SerialNumber: 001 Nov 29 09:58:20 mythbox kernel: dib0700: loaded with support for 7 different device-types Nov 29 09:58:20 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in cold state, will try to load a firmware Nov 29 09:58:20 mythbox kernel: firmware: requesting dvb-usb-dib0700-1.10.fw Nov 29 09:58:20 mythbox kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.10.fw' Nov 29 09:58:22 mythbox kernel: dib0700: firmware started successfully. Nov 29 09:58:23 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in warm state. Nov 29 09:58:23 mythbox kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Nov 29 09:58:23 mythbox kernel: DVB: registering new adapter (Artec T14BR DVB-T) Nov 29 09:58:23 mythbox kernel: DiB0070: successfully identified Nov 29 09:58:23 mythbox kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1 -8/input/input7 Nov 29 09:58:23 mythbox kernel: dvb-usb: schedule remote query interval to 150 msecs. Nov 29 09:58:23 mythbox kernel: dvb-usb: Artec T14BR DVB-T successfully initialized and connected. -- 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 PULL for 2.6.32] V4L/DVB updates
On Tue, 1 Dec 2009, Mauro Carvalho Chehab wrote: Mike Isely wrote: On Mon, 30 Nov 2009, Mauro Carvalho Chehab wrote: Em Sat, 28 Nov 2009 14:33:30 -0600 (CST) Mike Isely is...@isely.net escreveu: Mauro: I had also posted up two high priority pvrusb2 patches that should really be cherry-picked for 2.6.32. You've already pulled them into v4l/dvb and I did mark them as high priority at the time. These patches enable use of FX2 microcontroller firmware that is 16KB in size. Hauppauge is no longer shipping 8KB firmware for HVR-1950 and HVR-1900 and without these changes then those devices won't work AT ALL in kernel 2.6.32. You can find these within the v4l-dvb Mercurial repository here: Changeset 13495:87c3853fe2b3 Subject: pvrusb2: Support 16KB FX2 firmware http://linuxtv.org/hg/v4l-dvb/rev/87c3853fe2b3 Changeset 13500:d4c418d4b25c Subject: pvrusb2: Fix lingering 16KB FX2 Firmware issues http://linuxtv.org/hg/v4l-dvb/rev/d4c418d4b25c I do not believe these patches have any ordering dependencies with other patches, though between the two the second one technically should come after the first. There are. Picking just those patches broke compilation. Mauro: Please forward to me the compilation errors. Right now I am just not seeing how a patch this trivial could have any compilation dependencies. And unfortunately I will not be able to reproduce your build setup until at least Tuesday night. I must be blind. Also, it seemed too late for adding support for newer boards/firmware when Linus is about to release a kernel. This is not a new feature. It's a bug fix due to something that Hauppauge recently did. Hauppauge is NO LONGER officially distributing FX2 firmware with their hardware which the driver can use. This simply prevents any new HVR-1950 / HVR-1900 users from working under Linux. This fixes breakage for previously working hardware. The root cause is simple - the firmware blob is just larger now - and the fix is trivial. It absolutely needs to go in. In fact, this should go back to a 2.6.31.x and a 2.6.27.x release as well, though in those cases I have to figure out if driver source code is still close enough for the same patches to still work. I am sorry this is showing up late for you. There are multiple reasons for this. However I did mark these patches as high priority, following your v4l-dvb changeset process. I did comment on the pull request that these were important but I guess I needed to also specifically call these out in the pull request text as well. If these don't get in now as part of the official 2.6.32 release, these absolutely need to be queued for 2.6.32.1. We are very late for 2.6.32. I'm not sure if are there still time for it. I'll seek for some time during this week to add those patches at the upstream tree and removing them from the development tree and see what compilation issues arise. Mauro: Thanks. Guess I also really need to get up to speed on git, finally... -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] Multifrontend support for saa7134
Am Dienstag, den 24.11.2009, 02:08 +0100 schrieb hermann pitton:
Hi Mauro,
Am Montag, den 23.11.2009, 14:04 -0200 schrieb Mauro Carvalho Chehab:
Hi Lukáš/Hermann,
Any news about this patch? I'll mark it as RFC at the patchwork, since it
seems that this is not finished yet. Please let me know if you make some
progress.
@@ -1352,6 +1353,7 @@ struct saa7134_board saa7134_boards[] =
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
.mpeg = SAA7134_MPEG_DVB,
+ .num_frontends = 1,
.inputs = {{
.name = name_tv,
.vmux = 1,
Just one suggestion here: it is a way better to assume that an
uninitialized value (e. g. num_frontends = 0) for num_frontends to mean
that just one frontend exists. This saves space at the initialization
segment
of the module and avoids the risk of someone forget to add num_frontends=0.
cheers,
Mauro.
I currently don't have time to work on it and Lukáš' time is also
limited.
We stay in contact and I can provide a device not yet working for me to
him, if he wants. I'll keep you posted. You can have one too ;)
Currently the hardware reset in saa7134-dvb.c seems to break tda8275a
hybrid tuners on my saa7131e devices for DVB-T. This is not restricted
to the devices with multiple frontends, but also hits such with single
frontend only. The TRIO has two tda8275a, they are not in use as hybrid
tuners and don't need extra initialization again, that might be the
difference.
We should avoid such saa7133 hardware reset on those cards not needing
it in any case, means all with single frontend.
Or find a solution for this ridiculous frontend is superior over the
bridge going on since years against any common sense and claiming to
cover hybrid stuff too, imposing total nonsense on all such interested.
ON DVB-S is also a regression visible, in one of two cases needs a
second tuning attempt now and it also seems to be related to the
hardware reset, since without works fine like previously.
Patch is not ready yet for inclusion.
Getting hands dirty on what is around now on specs, that hardware reset
changes all gpios to be input on the bridge.
Of course nothing left after it for that five years work on such on that
dvb stuff. Mike proceed.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: WARNINGS
On Wednesday 02 December 2009 03:05:10 Németh Márton wrote: Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Dec 1 19:00:02 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13538:e0cd9a337600 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 [...] Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log linux-2.6.29.1-i686: WARNINGS /marune/build/v4l-dvb-master/v4l/firedtv-1394.c:264: warning: initialization discards qualifiers from pointer target type linux-2.6.29.1-x86_64: WARNINGS /marune/build/v4l-dvb-master/v4l/firedtv-1394.c:264: warning: initialization discards qualifiers from pointer target type I found about this two warnings that this module is not to be built with 2.6.29.1 according to the following lines from version.txt: [2.6.30] # Needs const id_table pointer in struct hpsb_protocol_driver DVB_FIREDTV_IEEE1394 I'm not sure whether the script v4l/scripts/make_kconfig.pl is working correctly or not. There are some weird conditions on that IEEE1394 config that seem to defeat the make_kconfig.pl script. I haven't had the time to look at it. It would be great if someone can take a look at it as I don't have the time. Regards, Hans Regards, Márton Németh -- 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] bttv: add i2c addr for old WinTV card to IR probe list
There are old bttv-driven Hauppauge WinTV series cards that have
their IR part at i2c addr 0x71, which doesn't get considered in the
new 2.6.31 i2c code.
From a 2.6.29 kernel:
lirc_i2c: chip 0x10005 found @ 0x71 (Hauppauge PVR150)
Minor cosmetic glitch, the card in question isn't actually a PVR-150, its:
03:06.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture
(rev 11)
Subsystem: Hauppauge computer works Inc. WinTV Series
Flags: bus master, medium devsel, latency 32, IRQ 19
Memory at f4ffe000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Kernel driver in use: bttv
Kernel modules: bttv
Device ID: 0x109e:0x036e, Sub-Device ID: 0x0070:0x13eb
This simply adds 0x71 to the list of addresses i2c_new_probed_device should
consider, which gets IR working on this card again.
Reported-by: Adam Williamson awill...@redhat.com
Signed-off-by: Jarod Wilson ja...@redhat.com
Tested-by: Adam Williamson awill...@redhat.com
---
diff -r e0cd9a337600 linux/drivers/media/video/bt8xx/bttv-i2c.c
--- a/linux/drivers/media/video/bt8xx/bttv-i2c.cSun Nov 29 12:08:02
2009 -0200
+++ b/linux/drivers/media/video/bt8xx/bttv-i2c.cTue Dec 01 11:23:17
2009 -0500
@@ -423,7 +423,7 @@
That's why we probe 0x1a (~0x34) first. CB
*/
const unsigned short addr_list[] = {
- 0x1a, 0x18, 0x4b, 0x64, 0x30,
+ 0x1a, 0x18, 0x4b, 0x64, 0x30, 0x71,
I2C_CLIENT_END
};
--
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: dvb_usb_dib0700 ( T14BR) not initializing on reboot
On 2/12/2009 12:35 PM, Paul wrote: I have a DVB-T USB device ( T14BR), which seems to work fine when I plug in my Fedora 10 box but I if I reboot with device connected it regularity fails to initialise correctly and to correct I have to remove unplug-device remove the module and reload module to fix up and only after system has been fully booted eg modprobe -r dvb-usb-dib0700 then modprobe dvb-usb-dib0700 adapter_nr=2 and then plug device in. I get the following msgs when it seems to fail and the second set when it works kernel log (failed) Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 2 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 3 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 4 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 5 Nov 22 13:51:50 mythbox kernel: usb 2-8: new low speed USB device using ohci_hcd and address 6 Nov 22 13:51:50 mythbox kernel: usb 2-8: configuration #1 chosen from 1 choice Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device found, idVendor=413c, idProduct=3010 Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver hiddev Nov 22 13:51:50 mythbox kernel: input: HID 413c:3010 as /devices/pci:00/:00:02.0/usb2/2-8/2-8:1.0/input/input4 Nov 22 13:51:50 mythbox kernel: input,hidraw0: USB HID v1.00 Mouse [HID 413c:3010] on usb-:00:02.0-8 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver usbhid Nov 22 13:51:50 mythbox kernel: usbhid: v2.6:USB HID core driver http://www.artectv.com/ehtm/products/t14.htm kernel log (working) Nov 29 09:58:20 mythbox kernel: usb 1-8: new high speed USB device using ehci_hcd and address 3 Nov 29 09:58:20 mythbox kernel: usb 1-8: configuration #1 chosen from 1 choice Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device found, idVendor=05d8, idProduct=810f Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 29 09:58:20 mythbox kernel: usb 1-8: Product: ART7070 Nov 29 09:58:20 mythbox kernel: usb 1-8: Manufacturer: Ultima Nov 29 09:58:20 mythbox kernel: usb 1-8: SerialNumber: 001 Nov 29 09:58:20 mythbox kernel: dib0700: loaded with support for 7 different device-types Nov 29 09:58:20 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in cold state, will try to load a firmware Nov 29 09:58:20 mythbox kernel: firmware: requesting dvb-usb-dib0700-1.10.fw Nov 29 09:58:20 mythbox kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.10.fw' Nov 29 09:58:22 mythbox kernel: dib0700: firmware started successfully. Nov 29 09:58:23 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in warm state. Nov 29 09:58:23 mythbox kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Nov 29 09:58:23 mythbox kernel: DVB: registering new adapter (Artec T14BR DVB-T) Nov 29 09:58:23 mythbox kernel: DiB0070: successfully identified Nov 29 09:58:23 mythbox kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1 -8/input/input7 Nov 29 09:58:23 mythbox kernel: dvb-usb: schedule remote query interval to 150 msecs. Nov 29 09:58:23 mythbox kernel: dvb-usb: Artec T14BR DVB-T successfully initialized and connected. Note I googled a few other people with the same issue: http://www.linuxtv.org/pipermail/linux-dvb/2007-November/022145.html http://ubuntuforums.org/archive/index.php/t-1233131.html so I'm assuming its a known issue, right? Paul -- 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: dvb_usb_dib0700 ( T14BR) not initializing on reboot
Are you sure that your usb is dib0700? if you look on the sources you wont see idVendor=413c, idProduct=3010 however there is os...@x-evian:/usr/src/linux-source-2.6.30/drivers/media/dvb/dvb-usb$ grep 05d8 * -iR Coincidencia en el fichero binario dvb-usb-dib0700.ko dvb-usb-dib0700.mod.c:MODULE_ALIAS(usb:v05D8p810Fd*dc*dsc*dp*ic*isc*ip*); in the file so try to recompile it with your device id, and pray for it :) On Wed, Dec 2, 2009 at 5:15 AM, Paul myli...@wilsononline.id.au wrote: On 2/12/2009 12:35 PM, Paul wrote: I have a DVB-T USB device ( T14BR), which seems to work fine when I plug in my Fedora 10 box but I if I reboot with device connected it regularity fails to initialise correctly and to correct I have to remove unplug-device remove the module and reload module to fix up and only after system has been fully booted eg modprobe -r dvb-usb-dib0700 then modprobe dvb-usb-dib0700 adapter_nr=2 and then plug device in. I get the following msgs when it seems to fail and the second set when it works kernel log (failed) Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 2 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 3 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 4 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using ohci_hcd and address 5 Nov 22 13:51:50 mythbox kernel: usb 2-8: new low speed USB device using ohci_hcd and address 6 Nov 22 13:51:50 mythbox kernel: usb 2-8: configuration #1 chosen from 1 choice Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device found, idVendor=413c, idProduct=3010 Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver hiddev Nov 22 13:51:50 mythbox kernel: input: HID 413c:3010 as /devices/pci:00/:00:02.0/usb2/2-8/2-8:1.0/input/input4 Nov 22 13:51:50 mythbox kernel: input,hidraw0: USB HID v1.00 Mouse [HID 413c:3010] on usb-:00:02.0-8 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver usbhid Nov 22 13:51:50 mythbox kernel: usbhid: v2.6:USB HID core driver http://www.artectv.com/ehtm/products/t14.htm kernel log (working) Nov 29 09:58:20 mythbox kernel: usb 1-8: new high speed USB device using ehci_hcd and address 3 Nov 29 09:58:20 mythbox kernel: usb 1-8: configuration #1 chosen from 1 choice Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device found, idVendor=05d8, idProduct=810f Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 29 09:58:20 mythbox kernel: usb 1-8: Product: ART7070 Nov 29 09:58:20 mythbox kernel: usb 1-8: Manufacturer: Ultima Nov 29 09:58:20 mythbox kernel: usb 1-8: SerialNumber: 001 Nov 29 09:58:20 mythbox kernel: dib0700: loaded with support for 7 different device-types Nov 29 09:58:20 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in cold state, will try to load a firmware Nov 29 09:58:20 mythbox kernel: firmware: requesting dvb-usb-dib0700-1.10.fw Nov 29 09:58:20 mythbox kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.10.fw' Nov 29 09:58:22 mythbox kernel: dib0700: firmware started successfully. Nov 29 09:58:23 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in warm state. Nov 29 09:58:23 mythbox kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Nov 29 09:58:23 mythbox kernel: DVB: registering new adapter (Artec T14BR DVB-T) Nov 29 09:58:23 mythbox kernel: DiB0070: successfully identified Nov 29 09:58:23 mythbox kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1 -8/input/input7 Nov 29 09:58:23 mythbox kernel: dvb-usb: schedule remote query interval to 150 msecs. Nov 29 09:58:23 mythbox kernel: dvb-usb: Artec T14BR DVB-T successfully initialized and connected. Note I googled a few other people with the same issue: http://www.linuxtv.org/pipermail/linux-dvb/2007-November/022145.html http://ubuntuforums.org/archive/index.php/t-1233131.html so I'm assuming its a known issue, right? Paul -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
