Re: RFC: Introduction of M2M capability and buffer types
Any comments? On Tue, Sep 14, 2010 at 11:29 PM, Kamil Debski k.deb...@samsung.com wrote: Hello, Mem2mem devices currently use V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT capabilities. One might expect that a capture device is a camera and an output device can display images. If I remember correct our discussion during the Helsinki v4l2 summit, Hans de Goede has pointed that such devices are listed in applications and can confuse users. The user expects a camera and he has to choose from a long list of devices. The solution to this would be the introduction of two new capability V4L2_CAP_VIDEO_M2M. Such devices would not be listed when user is expected to choose which webcam or TV tuner device to use. Another thing about m2m devices is the naming of buffers: V4L2_BUF_TYPE_VIDEO_CAPTURE means the destination buffer and V4L2_BUF_TYPE_VIDEO_OUTPUT means source. This indeed is confusing, so I think the introduction of two new buffer types is justified. I would recommend V4L2_BUF_TYPE_M2M_SOURCE and V4L2_BUF_TYPE_M2M_DESTINATION to clearly state what is the buffer's purpose. I would be grateful for your comments to this RFC. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- 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: [RFC/PATCH 7/9] v4l: v4l2_subdev userspace format API
Hi Hans,
Thanks for the review.
On Sunday 26 September 2010 20:25:20 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:30 Laurent Pinchart wrote:
Add a userspace API to get, set and enumerate the media format on a
subdev pad.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
snip
diff --git a/Documentation/DocBook/v4l/dev-subdev.xml
b/Documentation/DocBook/v4l/dev-subdev.xml new file mode 100644
index 000..9a691f7
--- /dev/null
+++ b/Documentation/DocBook/v4l/dev-subdev.xml
[snip]
+on one (or several) V4L2 device nodes./para
+ /section
+
+ section id=pad-level-formats
+titlePad-level formats/title
+
+noteFor the purpose of this section, the term
+wordaswordformat/wordasword means the combination of media bus
data +format, frame width and frame height./note
+
+paraImage formats are typically negotiated on video capture and
output +devices using the link linkend=cropcropping and
scaling/link ioctls. +The driver is responsible for configuring
every block in the video pipeline +according to the requested format
at the pipeline input and/or +output./para
+
+paraFor complex devices, such as often found in embedded systems,
+identical image sizes at the output of a pipeline can be achieved
using +different hardware configurations. One such exemple is shown
on +xref linkend=pipeline-scaling xrefstyle=template: Figure %n
/, where +image scaling can be performed on both the video sensor
and the host image +processing hardware./para
I think that it should be made very, very clear that this section is only
applicable to very complex devices and that it is not meant for generic
V4L2 applications.
OK, I'll document that.
[snip]
+paraDrivers that implement the link
linkend=media-controller-intromedia +API/link can expose
pad-level image format configuration to applications. +When they do,
applications can use the VIDIOC-SUBDEV-G-FMT; and +
VIDIOC-SUBDEV-S-FMT; ioctls. to negotiate formats on a per-pad
basis./para
What has the Media API to do with this, other than that it is needed to
discover the subdev device nodes?
Nothing else. Drivers need to implement it, otherwise userspace won't be able
to get pad identifiers.
[snip]
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml
b/Documentation/DocBook/v4l/subdev-formats.xml new file mode 100644
index 000..fb3c8b1
--- /dev/null
+++ b/Documentation/DocBook/v4l/subdev-formats.xml
[snip]
I'd add an introductory paragraph explaining that these codes determine how
the pixels flow over a physical bus and have nothing to do with how they
are stored in memory. That is determined by the pixelformat in struct
v4l2_pix_format.
It's an important but non-intuitive difference.
OK, I'll add that.
[snip]
diff --git a/Documentation/DocBook/v4l/vidioc-streamon.xml
b/Documentation/DocBook/v4l/vidioc-streamon.xml index e42bff1..75ed39b
100644
--- a/Documentation/DocBook/v4l/vidioc-streamon.xml
+++ b/Documentation/DocBook/v4l/vidioc-streamon.xml
@@ -93,6 +93,15 @@ synchronize with other events./para
been allocated (memory mapping) or enqueued (output) yet./para
/listitem
/varlistentry
+ varlistentry
+ termerrorcodeEPIPE/errorcode/term
+ listitem
+ paraThe driver implements link
+ linkend=pad-level-formatspad-level format configuration/link and
+ the pipeline configuration is invalid.
This raises a question with me: how do I know that pad-level format
configuration is possible? Is there a capability or some test that I can
perform to check this?
What about VIDIOC_SUBDEV_G_FMT on a pad ?
[snip]
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
new file mode 100644
index 000..623d063
--- /dev/null
+++ b/include/linux/v4l2-subdev.h
[snip]
+/**
+ * struct v4l2_subdev_frame_size_enum - Media bus format enumeration
+ * @pad: pad number, as reported by the media API
+ * @index: format index during enumeration
+ * @code: format code (from enum v4l2_mbus_pixelcode)
+ */
+struct v4l2_subdev_frame_size_enum {
+ __u32 index;
+ __u32 pad;
+ __u32 code;
+ __u32 min_width;
+ __u32 max_width;
+ __u32 min_height;
+ __u32 max_height;
+ __u32 reserved[9];
+};
Is there a reason why struct v4l2_frmsize_discrete and
v4l2_frmsize_stepwise are not reused here? Given the absence of
step_width/height fields in the struct can I assume a step of 1?
+
+#define VIDIOC_SUBDEV_G_FMT_IOWR('V', 4, struct
v4l2_subdev_format)
+#define VIDIOC_SUBDEV_S_FMT_IOWR('V', 5, struct
v4l2_subdev_format)
+#define VIDIOC_SUBDEV_ENUM_MBUS_CODE \
+ _IOWR('V',
Re: [RFC/PATCH 7/9] v4l: v4l2_subdev userspace format API
Hi Hans,
Thanks for the review.
On Sunday 26 September 2010 20:25:20 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:30 Laurent Pinchart wrote:
snip
diff --git a/Documentation/DocBook/v4l/vidioc-streamon.xml
b/Documentation/DocBook/v4l/vidioc-streamon.xml index e42bff1..75ed39b
100644
--- a/Documentation/DocBook/v4l/vidioc-streamon.xml
+++ b/Documentation/DocBook/v4l/vidioc-streamon.xml
@@ -93,6 +93,15 @@ synchronize with other events./para
been allocated (memory mapping) or enqueued (output) yet./para
/listitem
/varlistentry
+ varlistentry
+ termerrorcodeEPIPE/errorcode/term
+ listitem
+paraThe driver implements link
+linkend=pad-level-formatspad-level format configuration/link
and
+the pipeline configuration is invalid.
This raises a question with me: how do I know that pad-level format
configuration is possible? Is there a capability or some test that I can
perform to check this?
What about VIDIOC_SUBDEV_G_FMT on a pad ?
That will work. Probably a good idea to document this.
[snip]
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
new file mode 100644
index 000..623d063
--- /dev/null
+++ b/include/linux/v4l2-subdev.h
[snip]
+/**
+ * struct v4l2_subdev_frame_size_enum - Media bus format enumeration
+ * @pad: pad number, as reported by the media API
+ * @index: format index during enumeration
+ * @code: format code (from enum v4l2_mbus_pixelcode)
+ */
+struct v4l2_subdev_frame_size_enum {
+ __u32 index;
+ __u32 pad;
+ __u32 code;
+ __u32 min_width;
+ __u32 max_width;
+ __u32 min_height;
+ __u32 max_height;
+ __u32 reserved[9];
+};
Is there a reason why struct v4l2_frmsize_discrete and
v4l2_frmsize_stepwise are not reused here? Given the absence of
step_width/height fields in the struct can I assume a step of 1?
Didn't see a comment from you on this one...
+
+#define VIDIOC_SUBDEV_G_FMT _IOWR('V', 4, struct
v4l2_subdev_format)
+#define VIDIOC_SUBDEV_S_FMT _IOWR('V', 5, struct
v4l2_subdev_format)
+#define VIDIOC_SUBDEV_ENUM_MBUS_CODE \
+ _IOWR('V', 2, struct v4l2_subdev_mbus_code_enum)
+#define VIDIOC_SUBDEV_ENUM_FRAME_SIZE \
+ _IOWR('V', 74, struct v4l2_subdev_frame_size_enum)
The ioctl numbering is a bit scary. We want to be able to reuse V4L2
ioctls
with subdevs where appropriate. But then we need to enumerate the subdev
ioctls using a different character to avoid potential conflicts. E.g.
'S'
instead of 'V'.
There's little chance the ioctl values will conflict, as they encode the
structure size. However, it could still happen. That's why I've reused the
VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_ENUM_FMT and VIDIOC_ENUM_FRAMESIZES
ioctl
numbers for those new ioctls, as they replace the V4L2 ioctls for
sub-devices.
We can also use another prefix, but there's a limited supply of them.
Hmm, perhaps we can use 'v'. That's currently in use by V4L1, but that's
on the way out. I'm not sure what is wisdom here. Mauro should take a look
at this, I think.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 7/9] v4l: v4l2_subdev userspace format API
Hi Hans,
On Tuesday 28 September 2010 14:11:28 Hans Verkuil wrote:
Hi Hans,
Thanks for the review.
On Sunday 26 September 2010 20:25:20 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:30 Laurent Pinchart wrote:
snip
diff --git a/Documentation/DocBook/v4l/vidioc-streamon.xml
b/Documentation/DocBook/v4l/vidioc-streamon.xml index e42bff1..75ed39b
100644
--- a/Documentation/DocBook/v4l/vidioc-streamon.xml
+++ b/Documentation/DocBook/v4l/vidioc-streamon.xml
@@ -93,6 +93,15 @@ synchronize with other events./para
been allocated (memory mapping) or enqueued (output) yet./para
/listitem
/varlistentry
+ varlistentry
+termerrorcodeEPIPE/errorcode/term
+listitem
+ paraThe driver implements link
+ linkend=pad-level-formatspad-level format
configuration/link
and
+ the pipeline configuration is invalid.
This raises a question with me: how do I know that pad-level format
configuration is possible? Is there a capability or some test that I can
perform to check this?
What about VIDIOC_SUBDEV_G_FMT on a pad ?
That will work. Probably a good idea to document this.
OK.
[snip]
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
new file mode 100644
index 000..623d063
--- /dev/null
+++ b/include/linux/v4l2-subdev.h
[snip]
+/**
+ * struct v4l2_subdev_frame_size_enum - Media bus format enumeration
+ * @pad: pad number, as reported by the media API
+ * @index: format index during enumeration
+ * @code: format code (from enum v4l2_mbus_pixelcode)
+ */
+struct v4l2_subdev_frame_size_enum {
+__u32 index;
+__u32 pad;
+__u32 code;
+__u32 min_width;
+__u32 max_width;
+__u32 min_height;
+__u32 max_height;
+__u32 reserved[9];
+};
Is there a reason why struct v4l2_frmsize_discrete and
v4l2_frmsize_stepwise are not reused here? Given the absence of
step_width/height fields in the struct can I assume a step of 1?
Didn't see a comment from you on this one...
Oops, sorry.
Having a discrete option was, I think, a mistake. That's why I've merged both
options into a single structure. Discrete frame sizes are still supported, as
explained in the documentation, by setting min and max to the same values.
Furthermore, step-wise enumeration isn't enough. The OMAP3 ISP resizer can
scale images by a ratio expressed as 256 / [64 - 1024 integer value]. For a
given input size the minimum and maximum output sizes are (more or less) 1/4x
and 4x of the input, but not all values in that range can be achieved. We thus
need to express a discontinuous range of values that are not separated by a
constant step. As this can't be achieved in a generic way, I think it's better
to let the driver return the minimum and maximum sizes, and then try a
specific size in that range using the try/active mechanism.
+#define VIDIOC_SUBDEV_G_FMT _IOWR('V', 4, struct
v4l2_subdev_format)
+#define VIDIOC_SUBDEV_S_FMT _IOWR('V', 5, struct
v4l2_subdev_format)
+#define VIDIOC_SUBDEV_ENUM_MBUS_CODE \
+_IOWR('V', 2, struct
v4l2_subdev_mbus_code_enum)
+#define VIDIOC_SUBDEV_ENUM_FRAME_SIZE \
+_IOWR('V', 74, struct
v4l2_subdev_frame_size_enum)
The ioctl numbering is a bit scary. We want to be able to reuse V4L2
ioctls
with subdevs where appropriate. But then we need to enumerate the subdev
ioctls using a different character to avoid potential conflicts. E.g.
'S'
instead of 'V'.
There's little chance the ioctl values will conflict, as they encode the
structure size. However, it could still happen. That's why I've reused
the VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_ENUM_FMT and
VIDIOC_ENUM_FRAMESIZES ioctl
numbers for those new ioctls, as they replace the V4L2 ioctls for
sub-devices.
We can also use another prefix, but there's a limited supply of them.
Hmm, perhaps we can use 'v'. That's currently in use by V4L1, but that's
on the way out. I'm not sure what is wisdom here. Mauro should take a look
at this, I think.
That could be a good option. I'll let Mauro comment on it.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 8/9] v4l: v4l2_subdev userspace frame interval API
Hi Hans, On Sunday 26 September 2010 20:31:58 Hans Verkuil wrote: On Sunday, September 26, 2010 18:13:31 Laurent Pinchart wrote: The three new ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, VIDIOC_SUBDEV_G_FRAME_INTERVAL and VIDIOC_SUBDEV_S_FRAME_INTERVAL can be used to enumerate and configure a subdev's frame rate from userspace. Two new video::g/s_frame_interval subdev operations are introduced to support those ioctls. The existing video::g/s_parm operations are deprecated and shouldn't be used anymore. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com [snip] diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml new file mode 100644 index 000..be73500 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml [snip] +paraThis ioctl lets applications enumerate available frame intervals on a +given sub-device pad. Frame intervals only makes sense for sub-devices that +can control the frame period on their own. This includes, for instance, +image sensors and TV tuners. Sub-devices that don't support frame intervals +must not implement this ioctl./para How do I know as application that frame intervals are not supported? Frankly, this applies to the normal V4L2 ioctl as well :-) Right. It could be said of every ioctl. I'll remove that sentence. [snip] +table pgwide=1 frame=none id=v4l2-subdev-frame-interval-enum + titlestruct structnamev4l2_subdev_frame_interval_enum/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldindex/structfield/entry + entryNumber of the format in the enumeration, set by the + application./entry + /row + row + entry__u32/entry + entrystructfieldpad/structfield/entry + entryPad number as reported by the media controller API./entry + /row + row + entry__u32/entry + entrystructfieldcode/structfield/entry + entryThe media bus format code, as defined in + xref linkend=v4l2-mbus-format /./entry + /row + row + entry__u32/entry + entrystructfieldwidth/structfield/entry + entryFrame width, in pixels./entry + /row + row + entry__u32/entry + entrystructfieldheight/structfield/entry + entryFrame height, in pixels./entry + /row + row + entryv4l2-fract;/entry + entrystructfieldinterval/structfield/entry + entryPeriod, in seconds, between consecutive video frames./entry + /row struct v4l2_frmivalenum is not needed for this? v4l2_frmivalenum uses V4L2 pixel formats instead of media bus pixel codes. [snip] diff --git a/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml b/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml new file mode 100644 index 000..1d0e0e1 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml [snip] +paraDrivers must not return an error solely because the requested interval +doesn't match the device capabilities. They must instead modify the interval +to match what the hardware can provide. The modified interval should be as +close as possible to the original request./para Perhaps this should be driver dependent? What is the rationale for requiring this behavior? Same as for the formats and sizes. If a driver supports a large range of intervals, but not every exact values, applications will ask for the frame interval they want and will receive the closest match. It will then be up to the application to accept it or fail. [snip] -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 7/9] v4l: v4l2_subdev userspace format API
Hi,
Hans Verkuil wrote:
+
+#define VIDIOC_SUBDEV_G_FMT _IOWR('V', 4, struct
v4l2_subdev_format)
+#define VIDIOC_SUBDEV_S_FMT _IOWR('V', 5, struct
v4l2_subdev_format)
+#define VIDIOC_SUBDEV_ENUM_MBUS_CODE \
+ _IOWR('V', 2, struct v4l2_subdev_mbus_code_enum)
+#define VIDIOC_SUBDEV_ENUM_FRAME_SIZE \
+ _IOWR('V', 74, struct v4l2_subdev_frame_size_enum)
The ioctl numbering is a bit scary. We want to be able to reuse V4L2
ioctls
with subdevs where appropriate. But then we need to enumerate the subdev
ioctls using a different character to avoid potential conflicts. E.g.
'S'
instead of 'V'.
There's little chance the ioctl values will conflict, as they encode the
structure size. However, it could still happen. That's why I've reused the
VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_ENUM_FMT and VIDIOC_ENUM_FRAMESIZES
ioctl
numbers for those new ioctls, as they replace the V4L2 ioctls for
sub-devices.
We can also use another prefix, but there's a limited supply of them.
Hmm, perhaps we can use 'v'. That's currently in use by V4L1, but that's
on the way out. I'm not sure what is wisdom here. Mauro should take a look
at this, I think.
Similar V4L2 ioctls exists but they still are part of a different API.
So I'd go with 'S' (or something else non-'V') unless the ioctl is
exactly the same as in V4L2. And allocate numbers starting from 0 if
possible.
But I agree, let's wait Mauro's opinion...
Regards,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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: updated make_kconfig.pl for Ubuntu
Douglas:
I have an updated make_kconfig.pl for Ububtu on:
http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2/file/cb34ee1c29fc/v4l/scripts/make_kconfig.pl
Could you test if make allyesconfig actually keeps FIREDTV enabled on a
non-Ubuntu system ?
If so, can you merge this version into the main stream ?
Mauro:
You are very right. I did not look far enough.
The expanded place where I expect the dma.h file would be (as I
/lib/modules/2.6.28-19-generic/build/include/config/ieee1394/dma.h
note that the letters el should be removed from your first expression
$dmahplace=$kernelsrc/include/config/ieee1394/dma.h;
needs to be:
$dmahplace=$kernsrc/include/config/ieee1394/dma.h;
Thanks a lot for helping !
As patch, relative to the diff you sent:
# HG changeset patch
# User Jan Hoogenraad jan-conceptro...@h-i-s.nl
# Date 1285695899 -7200
# Node ID 891128e7c3334e41f6c173ee5c01fddbce493b73
# Parent cb34ee1c29fc8891ad3792b3df76031a72e39b9d
Location fix
From: Jan Hoogenraad jan-conceptro...@h-i-s.nl
Location fix
Priority: normal
Signed-off-by: Jan Hoogenraad jan-conceptro...@h-i-s.nl
diff -r cb34ee1c29fc -r 891128e7c333 v4l/scripts/make_kconfig.pl
--- a/v4l/scripts/make_kconfig.pl Mon Sep 27 20:27:20 2010 +0200
+++ b/v4l/scripts/make_kconfig.pl Tue Sep 28 19:44:59 2010 +0200
@@ -688,10 +688,7 @@
# Check for full kernel sources and print a warning
sub dmahcheck()
{
- my $dmahplace= .$kernsrc;
- $dmahplace =~ s-^/lib/modules/--g;
- $dmahplace =~ s-/.*$--g;
-
$dmahplace=/usr/src/linux-headers-$dmahplace/include/config/ieee1394/dma.h;
+ my $dmahplace=$kernsrc/include/config/ieee1394/dma.h;
if (! -e $dmahplace) {
print EOF2;
Mauro Carvalho Chehab wrote:
Em 27-09-2010 17:45, Jan Hoogenraad escreveu:
Mauro:
On my system, the call to make_kconfig reads:
./scripts/make_kconfig.pl /lib/modules/2.6.28-19-generic/build
/lib/modules/2.6.28-19-generic/build 1
Using $kernelsrc yields the following error:
Global symbol $kernelsrc requires explicit package name at
./scripts/make_kconfig.pl line 694.
Using
$dmahplace=$kernsrc/include/config/ieee1394/dma.h;
yields the following INCORRECT expansion:
/lib/modules/2.6.28-19-generic/build/include/config/ieee1394/dma.h
this is the place where I am building into, which is different from the place
where Ubuntu places the include files from the package
Thus I built an expression to get:
/usr/src/linux-headers-2.6.28-19-generic/include/config/ieee1394/dma.h
as I described in the mail of yesterday.
Huh? Are you sure that Ubuntu doesn't have a symbolic link at
/lib/modules/2.6.28-19-generic/build pointing
to /usr/src/linux-headers-2.6.28-19-generic/?
If it doesn't have, then all compat checks done by make_config_compat.pl would
fail.
Now, I realize that the header files could ALSO be present in the build
directory, so there should be a check on that as well, as otherwise the FIREDTV
is incorrectly disabled on other distros, or source builds.
Yes, and I know all of this is ugly
It is not just ugly. It will break compilation on Ubuntu with:
$ make release DIR=some dir
Cheers,
Mauro
--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
--
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: updated make_kconfig.pl for Ubuntu
Em 28-09-2010 14:48, Jan Hoogenraad escreveu:
Douglas:
I have an updated make_kconfig.pl for Ububtu on:
http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2/file/cb34ee1c29fc/v4l/scripts/make_kconfig.pl
Could you test if make allyesconfig actually keeps FIREDTV enabled on a
non-Ubuntu system ?
If so, can you merge this version into the main stream ?
Mauro:
You are very right. I did not look far enough.
The expanded place where I expect the dma.h file would be (as I
/lib/modules/2.6.28-19-generic/build/include/config/ieee1394/dma.h
note that the letters el should be removed from your first expression
$dmahplace=$kernelsrc/include/config/ieee1394/dma.h;
needs to be:
$dmahplace=$kernsrc/include/config/ieee1394/dma.h;
Thanks a lot for helping !
As patch, relative to the diff you sent:
# HG changeset patch
# User Jan Hoogenraad jan-conceptro...@h-i-s.nl
# Date 1285695899 -7200
# Node ID 891128e7c3334e41f6c173ee5c01fddbce493b73
# Parent cb34ee1c29fc8891ad3792b3df76031a72e39b9d
Location fix
From: Jan Hoogenraad jan-conceptro...@h-i-s.nl
Location fix
Priority: normal
Signed-off-by: Jan Hoogenraad jan-conceptro...@h-i-s.nl
diff -r cb34ee1c29fc -r 891128e7c333 v4l/scripts/make_kconfig.pl
--- a/v4l/scripts/make_kconfig.plMon Sep 27 20:27:20 2010 +0200
+++ b/v4l/scripts/make_kconfig.plTue Sep 28 19:44:59 2010 +0200
@@ -688,10 +688,7 @@
# Check for full kernel sources and print a warning
sub dmahcheck()
{
-my $dmahplace= .$kernsrc;
-$dmahplace =~ s-^/lib/modules/--g;
-$dmahplace =~ s-/.*$--g;
-
$dmahplace=/usr/src/linux-headers-$dmahplace/include/config/ieee1394/dma.h;
+my $dmahplace=$kernsrc/include/config/ieee1394/dma.h;
if (! -e $dmahplace) {
print EOF2;
Ok, now it looks correct on my eyes, and it should not hurt compilation
with make release and with distros that do a good job with their kernel
packages.
I'll let Douglas review and test, as he is the maintainer.
It would be better if you could send him a diff. you may use hg diff to generate
it against an older version, in order to merge all your make_kconfig.pl patches,
or just create a new clone from master and apply it there.
A side question: when do you intend to send us the patches for the Realtek
rtl2831?
Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417
drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects
type ‘int’, but argument 3 has type ‘long unsigned int’
drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects
type ‘int’, but argument 3 has type ‘size_t’
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-417.c
b/drivers/media/video/cx231xx/cx231xx-417.c
index 402e109..ddaa437 100644
--- a/drivers/media/video/cx231xx/cx231xx-417.c
+++ b/drivers/media/video/cx231xx/cx231xx-417.c
@@ -1044,7 +1044,7 @@ static int cx231xx_load_firmware(struct cx231xx *dev)
/* transfer to the chip */
dprintk(2, Loading firmware to GPIO...\n);
p_fw_data = (u32 *)firmware-data;
- dprintk(2, firmware-size=%d\n, firmware-size);
+ dprintk(2, firmware-size=%zd\n, firmware-size);
for (transfer_size = 0; transfer_size firmware-size;
transfer_size += 4) {
fw_data = *p_fw_data;
diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c
b/drivers/media/video/cx231xx/cx231xx-avcore.c
index b4eda90..ab9fbf8 100644
--- a/drivers/media/video/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/video/cx231xx/cx231xx-avcore.c
@@ -1605,7 +1605,7 @@ void cx231xx_set_DIF_bandpass(struct cx231xx *dev, u32
if_freq,
if_freq = 1600;
}
-cx231xx_info(Enter IF=%d\n,
+cx231xx_info(Enter IF=%zd\n,
sizeof(Dif_set_array)/sizeof(struct dif_settings));
for (i = 0; i sizeof(Dif_set_array)/sizeof(struct dif_settings); i++) {
if (Dif_set_array[i].if_freq == if_freq) {
--
1.7.1
--
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 02/10] V4L/DVB: cx231xx: fix Kconfig dependencies
ERROR: cx2341x_mpeg_ctrls [drivers/media/video/cx231xx/cx231xx.ko] undefined! ERROR: cx2341x_fill_defaults [drivers/media/video/cx231xx/cx231xx.ko] undefined! ERROR: cx2341x_log_status [drivers/media/video/cx231xx/cx231xx.ko] undefined! ERROR: cx2341x_ctrl_get_menu [drivers/media/video/cx231xx/cx231xx.ko] undefined! ERROR: cx2341x_update [drivers/media/video/cx231xx/cx231xx.ko] undefined! ERROR: cx2341x_ctrl_query [drivers/media/video/cx231xx/cx231xx.ko] undefined! ERROR: cx2341x_ext_ctrls [drivers/media/video/cx231xx/cx231xx.ko] undefined! Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/cx231xx/Kconfig b/drivers/media/video/cx231xx/Kconfig index 5ac7ece..bb04914 100644 --- a/drivers/media/video/cx231xx/Kconfig +++ b/drivers/media/video/cx231xx/Kconfig @@ -6,6 +6,7 @@ config VIDEO_CX231XX depends on VIDEO_IR select VIDEOBUF_VMALLOC select VIDEO_CX25840 + select VIDEO_CX2341X ---help--- This is a video4linux driver for Conexant 231xx USB based TV cards. -- 1.7.1 -- 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 03/10] V4L/DVB: tda18271: Add some hint about what tda18217 reg ID returned
Instead of doing: [ 82.581639] tda18271 4-0060: creating new instance [ 82.588411] Unknown device detected @ 4-0060, device not supported. [ 82.594695] tda18271_attach: [4-0060|M] error -22 on line 1272 [ 82.600530] tda18271 4-0060: destroying instance Print: [ 468.740392] Unknown device (0) detected @ 4-0060, device not supported. for the error message, to help detecting what's going wrong with the device. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/common/tuners/tda18271-fe.c b/drivers/media/common/tuners/tda18271-fe.c index 7955e49..77e3642 100644 --- a/drivers/media/common/tuners/tda18271-fe.c +++ b/drivers/media/common/tuners/tda18271-fe.c @@ -1177,7 +1177,7 @@ static int tda18271_get_id(struct dvb_frontend *fe) break; } - tda_info(%s detected @ %d-%04x%s\n, name, + tda_info(%s (%i) detected @ %d-%04x%s\n, name, regs[R_ID] 0x7f, i2c_adapter_id(priv-i2c_props.adap), priv-i2c_props.addr, (0 == ret) ? : , device not supported.); -- 1.7.1 -- 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 04/10] V4L/DVB: cx231xx: properly implement URB control messages log
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-core.c
b/drivers/media/video/cx231xx/cx231xx-core.c
index 5406ff2..983b120 100644
--- a/drivers/media/video/cx231xx/cx231xx-core.c
+++ b/drivers/media/video/cx231xx/cx231xx-core.c
@@ -47,11 +47,6 @@ static unsigned int reg_debug;
module_param(reg_debug, int, 0644);
MODULE_PARM_DESC(reg_debug, enable debug messages [URB reg]);
-#define cx231xx_regdbg(fmt, arg...) do {\
- if (reg_debug) \
- printk(KERN_INFO %s %s :fmt, \
-dev-name, __func__ , ##arg); } while (0)
-
static int alt = CX231XX_PINOUT;
module_param(alt, int, 0644);
MODULE_PARM_DESC(alt, alternate setting to use for video endpoint);
@@ -240,6 +235,66 @@ int cx231xx_send_usb_command(struct cx231xx_i2c *i2c_bus,
EXPORT_SYMBOL_GPL(cx231xx_send_usb_command);
/*
+ * Sends/Receives URB control messages, assuring to use a kalloced buffer
+ * for all operations (dev-urb_buf), to avoid using stacked buffers, as
+ * they aren't safe for usage with USB, due to DMA restrictions.
+ * Also implements the debug code for control URB's.
+ */
+static int __usb_control_msg(struct cx231xx *dev, unsigned int pipe,
+ __u8 request, __u8 requesttype, __u16 value, __u16 index,
+ void *data, __u16 size, int timeout)
+{
+ int rc, i;
+
+ if (reg_debug) {
+ printk(KERN_DEBUG %s: (pipe 0x%08x):
+ %s: %02x %02x %02x %02x %02x %02x %02x %02x ,
+ dev-name,
+ pipe,
+ (requesttype USB_DIR_IN) ? IN : OUT,
+ requesttype,
+ request,
+ value 0xff, value 8,
+ index 0xff, index 8,
+ size 0xff, size 8);
+ if (!(requesttype USB_DIR_IN)) {
+ printk(KERN_CONT );
+ for (i = 0; i size; i++)
+ printk(KERN_CONT %02x,
+ ((unsigned char *)data)[i]);
+ }
+ }
+
+ /* Do the real call to usb_control_msg */
+ mutex_lock(dev-ctrl_urb_lock);
+ if (!(requesttype USB_DIR_IN) size)
+ memcpy(dev-urb_buf, data, size);
+ rc = usb_control_msg(dev-udev, pipe, request, requesttype, value,
+index, dev-urb_buf, size, timeout);
+ if ((requesttype USB_DIR_IN) size)
+ memcpy(data, dev-urb_buf, size);
+ mutex_unlock(dev-ctrl_urb_lock);
+
+ if (reg_debug) {
+ if (unlikely(rc 0)) {
+ printk(KERN_CONT FAILED!\n);
+ return rc;
+ }
+
+ if ((requesttype USB_DIR_IN)) {
+ printk(KERN_CONT );
+ for (i = 0; i size; i++)
+ printk(KERN_CONT %02x,
+ ((unsigned char *)data)[i]);
+ }
+ printk(KERN_CONT \n);
+ }
+
+ return rc;
+}
+
+
+/*
* cx231xx_read_ctrl_reg()
* reads data from the usb device specifying bRequest and wValue
*/
@@ -276,39 +331,9 @@ int cx231xx_read_ctrl_reg(struct cx231xx *dev, u8 req, u16
reg,
if (val == 0xFF)
return -EINVAL;
- if (reg_debug) {
- cx231xx_isocdbg((pipe 0x%08x):
- IN: %02x %02x %02x %02x %02x %02x %02x %02x ,
- pipe,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- req, 0, val,
- reg 0xff, reg 8, len 0xff, len 8);
- }
-
- mutex_lock(dev-ctrl_urb_lock);
- ret = usb_control_msg(dev-udev, pipe, req,
+ ret = __usb_control_msg(dev, pipe, req,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- val, reg, dev-urb_buf, len, HZ);
- if (ret 0) {
- cx231xx_isocdbg( failed!\n);
- mutex_unlock(dev-ctrl_urb_lock);
- return ret;
- }
-
- if (len)
- memcpy(buf, dev-urb_buf, len);
-
- mutex_unlock(dev-ctrl_urb_lock);
-
- if (reg_debug) {
- int byte;
-
- cx231xx_isocdbg();
- for (byte = 0; byte len; byte++)
- cx231xx_isocdbg( %02x, (unsigned char)buf[byte]);
- cx231xx_isocdbg(\n);
- }
-
+ val, reg, buf, len, HZ);
return ret;
}
@@ -331,28 +356,10 @@ int cx231xx_send_vendor_cmd(struct cx231xx *dev,
else
pipe = usb_sndctrlpipe(dev-udev, 0);
- if (reg_debug) {
- int byte;
-
- cx231xx_isocdbg((pipe 0x%08x):
-
[PATCH 05/10] V4L/DVB: cx231xx: properly use the right tuner i2c address
The driver has a field to indicate what bus is used by tuner and
by demod. However, this field were never used. On Pixelview,
it uses I2C 2 for tuner, instead of I2C 1.
drivers/media/video/cx231xx/cx231xx-cards.c
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index b516068..8e088db 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -569,7 +569,7 @@ void cx231xx_card_setup(struct cx231xx *dev)
/* Initialize the tuner */
if (dev-board.tuner_type != TUNER_ABSENT) {
dev-sd_tuner = v4l2_i2c_new_subdev(dev-v4l2_dev,
- dev-i2c_bus[1].i2c_adap,
+
dev-i2c_bus[dev-board.tuner_i2c_master].i2c_adap,
tuner, tuner,
dev-tuner_addr, NULL);
if (dev-sd_tuner == NULL)
diff --git a/drivers/media/video/cx231xx/cx231xx-dvb.c
b/drivers/media/video/cx231xx/cx231xx-dvb.c
index 879eacb..4efd3d3 100644
--- a/drivers/media/video/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/video/cx231xx/cx231xx-dvb.c
@@ -347,7 +347,7 @@ static int attach_xc5000(u8 addr, struct cx231xx *dev)
struct xc5000_config cfg;
memset(cfg, 0, sizeof(cfg));
- cfg.i2c_adap = dev-i2c_bus[1].i2c_adap;
+ cfg.i2c_adap = dev-i2c_bus[dev-board.tuner_i2c_master].i2c_adap;
cfg.i2c_addr = addr;
if (!dev-dvb-frontend) {
@@ -573,7 +573,7 @@ static int dvb_init(struct cx231xx *dev)
dev-dvb-frontend = dvb_attach(s5h1432_attach,
dvico_s5h1432_config,
- dev-i2c_bus[2].i2c_adap);
+
dev-i2c_bus[dev-board.demod_i2c_master].i2c_adap);
if (dev-dvb-frontend == NULL) {
printk(DRIVER_NAME
@@ -586,7 +586,7 @@ static int dvb_init(struct cx231xx *dev)
dvb-frontend-callback = cx231xx_tuner_callback;
if (!dvb_attach(xc5000_attach, dev-dvb-frontend,
- dev-i2c_bus[1].i2c_adap,
+
dev-i2c_bus[dev-board.tuner_i2c_master].i2c_adap,
cnxt_rde250_tunerconfig)) {
result = -EINVAL;
goto out_free;
@@ -598,7 +598,7 @@ static int dvb_init(struct cx231xx *dev)
dev-dvb-frontend = dvb_attach(s5h1411_attach,
xc5000_s5h1411_config,
- dev-i2c_bus[2].i2c_adap);
+
dev-i2c_bus[dev-board.demod_i2c_master].i2c_adap);
if (dev-dvb-frontend == NULL) {
printk(DRIVER_NAME
@@ -611,7 +611,7 @@ static int dvb_init(struct cx231xx *dev)
dvb-frontend-callback = cx231xx_tuner_callback;
if (!dvb_attach(xc5000_attach, dev-dvb-frontend,
- dev-i2c_bus[1].i2c_adap,
+
dev-i2c_bus[dev-board.tuner_i2c_master].i2c_adap,
cnxt_rdu250_tunerconfig)) {
result = -EINVAL;
goto out_free;
@@ -621,7 +621,7 @@ static int dvb_init(struct cx231xx *dev)
dev-dvb-frontend = dvb_attach(s5h1432_attach,
dvico_s5h1432_config,
- dev-i2c_bus[2].i2c_adap);
+
dev-i2c_bus[dev-board.demod_i2c_master].i2c_adap);
if (dev-dvb-frontend == NULL) {
printk(DRIVER_NAME
@@ -634,7 +634,7 @@ static int dvb_init(struct cx231xx *dev)
dvb-frontend-callback = cx231xx_tuner_callback;
if (!dvb_attach(tda18271_attach, dev-dvb-frontend,
- 0x60, dev-i2c_bus[1].i2c_adap,
+ 0x60,
dev-i2c_bus[dev-board.tuner_i2c_master].i2c_adap,
cnxt_rde253s_tunerconfig)) {
result = -EINVAL;
goto out_free;
@@ -644,7 +644,7 @@ static int dvb_init(struct cx231xx *dev)
dev-dvb-frontend = dvb_attach(s5h1411_attach,
tda18271_s5h1411_config,
- dev-i2c_bus[2].i2c_adap);
+
dev-i2c_bus[dev-board.demod_i2c_master].i2c_adap);
if (dev-dvb-frontend == NULL) {
printk(DRIVER_NAME
@@ -657,7 +657,7 @@ static int dvb_init(struct cx231xx *dev)
dvb-frontend-callback =
[PATCH 06/10] V4L/DVB: cx231xx: better handle the master port enable command
Improves the logic, for it to be clearer and to avoid having
board-dependent config there.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c
b/drivers/media/video/cx231xx/cx231xx-avcore.c
index ab9fbf8..2d773b3 100644
--- a/drivers/media/video/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/video/cx231xx/cx231xx-avcore.c
@@ -1268,36 +1268,39 @@ int cx231xx_set_agc_analog_digital_mux_select(struct
cx231xx *dev,
return status;
}
-int cx231xx_enable_i2c_for_tuner(struct cx231xx *dev, u8 I2CIndex)
+int cx231xx_enable_i2c_port_3(struct cx231xx *dev, bool is_port_3)
{
u8 value[4] = { 0, 0, 0, 0 };
int status = 0;
-
- cx231xx_info(Changing the i2c port for tuner to %d\n, I2CIndex);
+ bool current_is_port_3;
status = cx231xx_read_ctrl_reg(dev, VRT_GET_REGISTER,
PWR_CTL_EN, value, 4);
if (status 0)
return status;
- if (I2CIndex == I2C_1) {
- if (value[0] I2C_DEMOD_EN) {
- value[0] = ~I2C_DEMOD_EN;
- status = cx231xx_write_ctrl_reg(dev, VRT_SET_REGISTER,
- PWR_CTL_EN, value, 4);
- }
- } else {
- if (!(value[0] I2C_DEMOD_EN)) {
- value[0] |= I2C_DEMOD_EN;
- status = cx231xx_write_ctrl_reg(dev, VRT_SET_REGISTER,
- PWR_CTL_EN, value, 4);
- }
- }
+ current_is_port_3 = value[0] I2C_DEMOD_EN ? true : false;
+
+ /* Just return, if already using the right port */
+ if (current_is_port_3 == is_port_3)
+ return 0;
+
+ if (is_port_3)
+ value[0] |= I2C_DEMOD_EN;
+ else
+ value[0] = ~I2C_DEMOD_EN;
+
+ cx231xx_info(Changing the i2c master port to %d\n,
+is_port_3 ? 3 : 1);
+
+ status = cx231xx_write_ctrl_reg(dev, VRT_SET_REGISTER,
+ PWR_CTL_EN, value, 4);
return status;
}
-EXPORT_SYMBOL_GPL(cx231xx_enable_i2c_for_tuner);
+EXPORT_SYMBOL_GPL(cx231xx_enable_i2c_port_3);
+
void update_HH_register_after_set_DIF(struct cx231xx *dev)
{
/*
@@ -2324,26 +2327,16 @@ int cx231xx_set_power_mode(struct cx231xx *dev, enum
AV_MODE mode)
msleep(PWR_SLEEP_INTERVAL);
}
- if ((dev-model == CX231XX_BOARD_CNXT_CARRAERA) ||
- (dev-model == CX231XX_BOARD_CNXT_RDE_250) ||
- (dev-model == CX231XX_BOARD_CNXT_SHELBY) ||
- (dev-model == CX231XX_BOARD_CNXT_RDU_250)) {
- /* tuner path to channel 1 from port 3 */
- cx231xx_enable_i2c_for_tuner(dev, I2C_3);
+ if (dev-board.tuner_type != TUNER_ABSENT) {
+ /* Enable tuner */
+ cx231xx_enable_i2c_port_3(dev, true);
/* reset the Tuner */
- cx231xx_gpio_set(dev, dev-board.tuner_gpio);
+ if (dev-board.tuner_gpio)
+ cx231xx_gpio_set(dev, dev-board.tuner_gpio);
if (dev-cx231xx_reset_analog_tuner)
dev-cx231xx_reset_analog_tuner(dev);
- } else if ((dev-model == CX231XX_BOARD_CNXT_RDE_253S) ||
- (dev-model == CX231XX_BOARD_CNXT_VIDEO_GRABBER) ||
- (dev-model == CX231XX_BOARD_CNXT_RDU_253S) ||
- (dev-model == CX231XX_BOARD_HAUPPAUGE_EXETER)) {
- /* tuner path to channel 1 from port 3 */
- cx231xx_enable_i2c_for_tuner(dev, I2C_3);
- if (dev-cx231xx_reset_analog_tuner)
- dev-cx231xx_reset_analog_tuner(dev);
}
break;
@@ -2401,33 +2394,23 @@ int cx231xx_set_power_mode(struct cx231xx *dev, enum
AV_MODE mode)
msleep(PWR_SLEEP_INTERVAL);
}
- if ((dev-model == CX231XX_BOARD_CNXT_CARRAERA) ||
- (dev-model == CX231XX_BOARD_CNXT_RDE_250) ||
- (dev-model == CX231XX_BOARD_CNXT_SHELBY) ||
- (dev-model == CX231XX_BOARD_CNXT_RDU_250)) {
- /* tuner path to channel 1 from port 3 */
- cx231xx_enable_i2c_for_tuner(dev, I2C_3);
+ if (dev-board.tuner_type != TUNER_ABSENT) {
+ /*
+* Enable tuner
+* Hauppauge Exeter seems to need to do something
different!
+*/
+ if (dev-model == CX231XX_BOARD_HAUPPAUGE_EXETER)
+ cx231xx_enable_i2c_port_3(dev, false);
+
[PATCH 07/10] V4L/DVB: cx231xx: Only change gpio direction when needed
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 8e088db..28f77a7 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -495,10 +495,11 @@ void cx231xx_pre_card_setup(struct cx231xx *dev)
if (dev-board.tuner_gpio) {
cx231xx_set_gpio_direction(dev, dev-board.tuner_gpio-bit, 1);
cx231xx_set_gpio_value(dev, dev-board.tuner_gpio-bit, 1);
+ }
+ if (dev-board.tuner_sif_gpio = 0)
cx231xx_set_gpio_direction(dev, dev-board.tuner_sif_gpio, 1);
- /* request some modules if any required */
- }
+ /* request some modules if any required */
/* set the mode to Analog mode initially */
cx231xx_set_mode(dev, CX231XX_ANALOG_MODE);
diff --git a/drivers/media/video/cx231xx/cx231xx.h
b/drivers/media/video/cx231xx/cx231xx.h
index b4859a0..d079433 100644
--- a/drivers/media/video/cx231xx/cx231xx.h
+++ b/drivers/media/video/cx231xx/cx231xx.h
@@ -333,9 +333,10 @@ struct cx231xx_board {
struct cx231xx_reg_seq *dvb_gpio;
struct cx231xx_reg_seq *suspend_gpio;
struct cx231xx_reg_seq *tuner_gpio;
- u8 tuner_sif_gpio;
- u8 tuner_scl_gpio;
- u8 tuner_sda_gpio;
+ /* Negative means don't use it */
+ s8 tuner_sif_gpio;
+ s8 tuner_scl_gpio;
+ s8 tuner_sda_gpio;
/* PIN ctrl */
u32 ctl_pin_status_mask;
--
1.7.1
--
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 08/10] V4L/DVB: tda18271: allow restricting max out to 4 bytes
By default, tda18271 tries to optimize I2C bus by updating all registers
at the same time. Unfortunately, some devices doesn't support it.
The current logic has a problem when small_i2c is equal to 8, since there
are some transfers using 11 + 1 bytes.
Fix the problem by enforcing the max size at the right place, and allows
reducing it to max = 3 + 1.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/common/tuners/tda18271-common.c
b/drivers/media/common/tuners/tda18271-common.c
index e1f6782..195b30e 100644
--- a/drivers/media/common/tuners/tda18271-common.c
+++ b/drivers/media/common/tuners/tda18271-common.c
@@ -193,20 +193,46 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx,
int len)
unsigned char *regs = priv-tda18271_regs;
unsigned char buf[TDA18271_NUM_REGS + 1];
struct i2c_msg msg = { .addr = priv-i2c_props.addr, .flags = 0,
- .buf = buf, .len = len + 1 };
- int i, ret;
+ .buf = buf };
+ int i, ret = 1, max;
BUG_ON((len == 0) || (idx + len sizeof(buf)));
- buf[0] = idx;
- for (i = 1; i = len; i++)
- buf[i] = regs[idx - 1 + i];
+
+ switch (priv-small_i2c) {
+ case TDA18271_03_BYTE_CHUNK_INIT:
+ max = 3;
+ break;
+ case TDA18271_08_BYTE_CHUNK_INIT:
+ max = 8;
+ break;
+ case TDA18271_16_BYTE_CHUNK_INIT:
+ max = 16;
+ break;
+ case TDA18271_39_BYTE_CHUNK_INIT:
+ default:
+ max = 39;
+ }
tda18271_i2c_gate_ctrl(fe, 1);
+ while (len) {
+ if (max len)
+ max = len;
- /* write registers */
- ret = i2c_transfer(priv-i2c_props.adap, msg, 1);
+ buf[0] = idx;
+ for (i = 1; i = max; i++)
+ buf[i] = regs[idx - 1 + i];
+ msg.len = max + 1;
+
+ /* write registers */
+ ret = i2c_transfer(priv-i2c_props.adap, msg, 1);
+ if (ret != 1)
+ break;
+
+ idx += max;
+ len -= max;
+ }
tda18271_i2c_gate_ctrl(fe, 0);
if (ret != 1)
@@ -326,24 +352,7 @@ int tda18271_init_regs(struct dvb_frontend *fe)
regs[R_EB22] = 0x48;
regs[R_EB23] = 0xb0;
- switch (priv-small_i2c) {
- case TDA18271_08_BYTE_CHUNK_INIT:
- tda18271_write_regs(fe, 0x00, 0x08);
- tda18271_write_regs(fe, 0x08, 0x08);
- tda18271_write_regs(fe, 0x10, 0x08);
- tda18271_write_regs(fe, 0x18, 0x08);
- tda18271_write_regs(fe, 0x20, 0x07);
- break;
- case TDA18271_16_BYTE_CHUNK_INIT:
- tda18271_write_regs(fe, 0x00, 0x10);
- tda18271_write_regs(fe, 0x10, 0x10);
- tda18271_write_regs(fe, 0x20, 0x07);
- break;
- case TDA18271_39_BYTE_CHUNK_INIT:
- default:
- tda18271_write_regs(fe, 0x00, TDA18271_NUM_REGS);
- break;
- }
+ tda18271_write_regs(fe, 0x00, TDA18271_NUM_REGS);
/* setup agc1 gain */
regs[R_EB17] = 0x00;
diff --git a/drivers/media/common/tuners/tda18271.h
b/drivers/media/common/tuners/tda18271.h
index d7fcc36..3abb221 100644
--- a/drivers/media/common/tuners/tda18271.h
+++ b/drivers/media/common/tuners/tda18271.h
@@ -80,8 +80,9 @@ enum tda18271_output_options {
enum tda18271_small_i2c {
TDA18271_39_BYTE_CHUNK_INIT = 0,
- TDA18271_16_BYTE_CHUNK_INIT = 1,
- TDA18271_08_BYTE_CHUNK_INIT = 2,
+ TDA18271_16_BYTE_CHUNK_INIT = 16,
+ TDA18271_08_BYTE_CHUNK_INIT = 8,
+ TDA18271_03_BYTE_CHUNK_INIT = 3,
};
struct tda18271_config {
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index fa406b9..1a047c5 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -428,7 +428,7 @@ static void set_type(struct i2c_client *c, unsigned int
type,
{
struct tda18271_config cfg = {
.config = t-config,
- .small_i2c = TDA18271_08_BYTE_CHUNK_INIT,
+ .small_i2c = TDA18271_03_BYTE_CHUNK_INIT,
};
if (!dvb_attach(tda18271_attach, t-fe, t-i2c-addr,
--
1.7.1
--
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 09/10] V4L/DVB: tda18271: Add debug message with frequency divisor
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/common/tuners/tda18271-common.c
b/drivers/media/common/tuners/tda18271-common.c
index 195b30e..7ba3ba3 100644
--- a/drivers/media/common/tuners/tda18271-common.c
+++ b/drivers/media/common/tuners/tda18271-common.c
@@ -549,6 +549,13 @@ int tda18271_calc_main_pll(struct dvb_frontend *fe, u32
freq)
regs[R_MD1] = 0x7f (div 16);
regs[R_MD2] = 0xff (div 8);
regs[R_MD3] = 0xff div;
+
+ if (tda18271_debug DBG_REG) {
+ tda_reg(MAIN_DIV_BYTE_1= 0x%02x\n, 0xff regs[R_MD1]);
+ tda_reg(MAIN_DIV_BYTE_2= 0x%02x\n, 0xff regs[R_MD2]);
+ tda_reg(MAIN_DIV_BYTE_3= 0x%02x\n, 0xff regs[R_MD3]);
+ }
+
fail:
return ret;
}
--
1.7.1
--
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 10/10] V4L/DVB: cx231xx-audio: fix some locking issues
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/cx231xx/cx231xx-audio.c
b/drivers/media/video/cx231xx/cx231xx-audio.c
index 6ac418c..30d13c1 100644
--- a/drivers/media/video/cx231xx/cx231xx-audio.c
+++ b/drivers/media/video/cx231xx/cx231xx-audio.c
@@ -124,6 +124,9 @@ static void cx231xx_audio_isocirq(struct urb *urb)
break;
}
+ if (atomic_read(dev-stream_started) == 0)
+ return;
+
if (dev-adev.capture_pcm_substream) {
substream = dev-adev.capture_pcm_substream;
runtime = substream-runtime;
@@ -206,6 +209,9 @@ static void cx231xx_audio_bulkirq(struct urb *urb)
break;
}
+ if (atomic_read(dev-stream_started) == 0)
+ return;
+
if (dev-adev.capture_pcm_substream) {
substream = dev-adev.capture_pcm_substream;
runtime = substream-runtime;
@@ -370,35 +376,6 @@ static int cx231xx_init_audio_bulk(struct cx231xx *dev)
return errCode;
}
-
-static int cx231xx_cmd(struct cx231xx *dev, int cmd, int arg)
-{
- dprintk(%s transfer\n, (dev-adev.capture_stream == STREAM_ON) ?
- stop : start);
-
- switch (cmd) {
- case CX231XX_CAPTURE_STREAM_EN:
- if (dev-adev.capture_stream == STREAM_OFF arg == 1) {
- dev-adev.capture_stream = STREAM_ON;
- if (is_fw_load(dev) == 0)
- cx25840_call(dev, core, load_fw);
- if (dev-USE_ISO)
- cx231xx_init_audio_isoc(dev);
- else
- cx231xx_init_audio_bulk(dev);
- } else if (dev-adev.capture_stream == STREAM_ON arg == 0) {
- dev-adev.capture_stream = STREAM_OFF;
- cx231xx_isoc_audio_deinit(dev);
- } else {
- cx231xx_errdev(An underrun very likely occurred.
- Ignoring it.\n);
- }
- return 0;
- default:
- return -EINVAL;
- }
-}
-
static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs,
size_t size)
{
@@ -460,22 +437,24 @@ static int snd_cx231xx_capture_open(struct
snd_pcm_substream *substream)
/* set alternate setting for audio interface */
/* 1 - 48000 samples per sec */
+ mutex_lock(dev-lock);
if (dev-USE_ISO)
ret = cx231xx_set_alt_setting(dev, INDEX_AUDIO, 1);
else
ret = cx231xx_set_alt_setting(dev, INDEX_AUDIO, 0);
+ mutex_unlock(dev-lock);
if (ret 0) {
cx231xx_errdev(failed to set alternate setting !\n);
return ret;
}
- /* inform hardware to start streaming */
- ret = cx231xx_capture_start(dev, 1, Audio);
-
runtime-hw = snd_cx231xx_hw_capture;
mutex_lock(dev-lock);
+ /* inform hardware to start streaming */
+ ret = cx231xx_capture_start(dev, 1, Audio);
+
dev-adev.users++;
mutex_unlock(dev-lock);
@@ -493,7 +472,8 @@ static int snd_cx231xx_pcm_close(struct snd_pcm_substream
*substream)
dprintk(closing device\n);
- /* inform hardware to start streaming */
+ /* inform hardware to stop streaming */
+ mutex_lock(dev-lock);
ret = cx231xx_capture_start(dev, 0, Audio);
/* set alternate setting for audio interface */
@@ -502,11 +482,11 @@ static int snd_cx231xx_pcm_close(struct snd_pcm_substream
*substream)
if (ret 0) {
cx231xx_errdev(failed to set alternate setting !\n);
+ mutex_unlock(dev-lock);
return ret;
}
dev-mute = 1;
- mutex_lock(dev-lock);
dev-adev.users--;
mutex_unlock(dev-lock);
@@ -515,7 +495,10 @@ static int snd_cx231xx_pcm_close(struct snd_pcm_substream
*substream)
dprintk(disabling audio stream!\n);
dev-adev.shutdown = 0;
dprintk(released lock\n);
- cx231xx_cmd(dev, CX231XX_CAPTURE_STREAM_EN, 0);
+ if (atomic_read(dev-stream_started) 0) {
+ atomic_set(dev-stream_started, 0);
+ schedule_work(dev-wq_trigger);
+ }
}
return 0;
}
@@ -546,8 +529,10 @@ static int snd_cx231xx_hw_capture_free(struct
snd_pcm_substream *substream)
dprintk(Stop capture, if needed\n);
- if (dev-adev.capture_stream == STREAM_ON)
- cx231xx_cmd(dev, CX231XX_CAPTURE_STREAM_EN, CX231XX_STOP_AUDIO);
+ if (atomic_read(dev-stream_started) 0) {
+ atomic_set(dev-stream_started, 0);
+ schedule_work(dev-wq_trigger);
+ }
return 0;
}
@@ -562,32 +547,46 @@ static int
[PATCH 00/10] Several fixes for cx231xx
Those patches do several fixes needed on cx231xx for it to properly work with some new devices. They are meant to be applied after Devin's patches on his tree: https://www.kernellabs.com/hg/~dheitmueller/polaris4/ I've applied his patch (fixing some merge conflicts) on a temporary git tree at: http://git.linuxtv.org/mchehab/cx231xx.git I have a few more patches adding experimental support for PixelView SBTVD Hybrid, in analog mode, that needs a few more adjustments before pushing at my tree, and I should start working on a driver for digital mode soon. Mauro Carvalho Chehab (10): V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417 V4L/DVB: cx231xx: fix Kconfig dependencies V4L/DVB: tda18271: Add some hint about what tda18217 reg ID returned V4L/DVB: cx231xx: properly implement URB control messages log V4L/DVB: cx231xx: properly use the right tuner i2c address V4L/DVB: cx231xx: better handle the master port enable command V4L/DVB: cx231xx: Only change gpio direction when needed V4L/DVB: tda18271: allow restricting max out to 4 bytes V4L/DVB: tda18271: Add debug message with frequency divisor V4L/DVB: cx231xx-audio: fix some locking issues drivers/media/common/tuners/tda18271-common.c | 66 ++ drivers/media/common/tuners/tda18271-fe.c |2 +- drivers/media/common/tuners/tda18271.h|5 +- drivers/media/video/cx231xx/Kconfig |1 + drivers/media/video/cx231xx/cx231xx-417.c |2 +- drivers/media/video/cx231xx/cx231xx-audio.c | 95 ++-- drivers/media/video/cx231xx/cx231xx-avcore.c | 91 +--- drivers/media/video/cx231xx/cx231xx-cards.c |7 +- drivers/media/video/cx231xx/cx231xx-core.c| 192 +++-- drivers/media/video/cx231xx/cx231xx-dvb.c | 32 ++-- drivers/media/video/cx231xx/cx231xx.h | 17 ++- drivers/media/video/tuner-core.c |2 +- 12 files changed, 243 insertions(+), 269 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Sep 28 19:00:17 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15164:1da5fed5c8b2 git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: dace3857de7a16b83ae7d4e13c94de8e4b267d2a gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: updated make_kconfig.pl for Ubuntu
Douglas:
Can you push the updated make_kconfig.pl ?
It is in its own HG tree on:
http://linuxtv.org/hg/~jhoogenraad/ubuntu-firedtv/
Mauro Carvalho Chehab wrote:
Em 28-09-2010 14:48, Jan Hoogenraad escreveu:
Douglas:
I have an updated make_kconfig.pl for Ububtu on:
http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2/file/cb34ee1c29fc/v4l/scripts/make_kconfig.pl
Could you test if make allyesconfig actually keeps FIREDTV enabled on a
non-Ubuntu system ?
If so, can you merge this version into the main stream ?
Ok, now it looks correct on my eyes, and it should not hurt compilation
with make release and with distros that do a good job with their kernel
packages.
I'll let Douglas review and test, as he is the maintainer.
It would be better if you could send him a diff. you may use hg diff to generate
it against an older version, in order to merge all your make_kconfig.pl patches,
or just create a new clone from master and apply it there.
A side question: when do you intend to send us the patches for the Realtek
rtl2831?
Cheers,
Mauro.
--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
# HG changeset patch
# User Jan Hoogenraad jan-conceptro...@h-i-s.nl
# Date 1285703652 -7200
# Node ID c8e14191e48d98a19405c9f899abca30cd89bc18
# Parent 1da5fed5c8b2c626180b1a0983fe1c960b999525
Disable FIREDTV for debian/ubuntu distributions with bad header files
From: Jan Hoogenraad jan-conceptro...@h-i-s.nl
Disable FIREDTV for debian/ubuntu distributions with problems in header files
Priority: normal
Signed-off-by: Jan Hoogenraad jan-conceptro...@h-i-s.nl
diff -r 1da5fed5c8b2 -r c8e14191e48d v4l/scripts/make_kconfig.pl
--- a/v4l/scripts/make_kconfig.pl Sun Sep 19 02:23:09 2010 -0300
+++ b/v4l/scripts/make_kconfig.pl Tue Sep 28 21:54:12 2010 +0200
@@ -597,6 +597,9 @@
disable_config('STAGING_BROKEN');
$intopt { DVB_MAX_ADAPTERS } = 8;
+#check broken Ubuntu headers
+dmahcheck();
+
# Check dependencies
my %newconfig = checkdeps();
@@ -681,3 +684,24 @@
EOF3
sleep 5;
}
+
+# Check for full kernel sources and print a warning
+sub dmahcheck()
+{
+ my $dmahplace=$kernsrc/include/config/ieee1394/dma.h;
+ if (! -e $dmahplace) {
+ print EOF2;
+
+***WARNING:*** File $dmahplace not present.
+This problem is at least present on Ubuntu systems:
+https://bugs.launchpad.net/ubuntu/+source/linux-kernel-headers/+bug/134222
+
+Therefore disabling FIREDTV driver.
+
+EOF2
+
+ disable_config('DVB_FIREDTV');
+
+ }
+ sleep 5;
+}
[SOLVED] wnv_cs.c: i2c question
Hey, as I recently obtained such a PCMCIA card, I try to revive the wnv_cs driver for Winnov Videum Traveler video cards. First (non-working, but compiling and able to access the EEPROM and to detect the decoder) results may be found at http://git.kernel.org/?p=linux/kernel/git/brodo/pcmcia-2.6.git;a=shortlog;h=refs/heads/wnv Now, I got a bit stuck at the i2c level -- do the following access functions look familiar to one of the i2c experts? If so, which algo driver is to be used? Is this an i2c_smbus_, or some very custom interface not worth converting to use the i2c subsystem? Many thanks! inverting i2c_data and i2c_clock did the trick. Best, Dominik -- 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
