pctv452e usb (Technotrend TT Connect S2-3600) & DM1105N
Hi guys, Since updating to 3.3.1 from 3.2.x my DVB-S2 tuner has stopped working and seems to block when accessed: [ 6182.111792] pctv452e: I2C error -110; AA 0F D0 03 00 -> AA 0F D0 03 00. [ 6182.419919] dvb-usb: error -110 while querying for an remote control event. [ 6182.989972] dvb-usb: error -110 while querying for an remote control event. [ 6184.170082] dvb-usb: bulk message failed: -110 (4/0) [ 6184.185065] dvb-usb: error -110 while querying for an remote control event. [ 6184.356753] dvb-usb: error -110 while querying for an remote control event. The I2C errors were logged under 3.2 also but the card still worked. Has anything substantanial changed? Can enable debug and/or ssh access if it would help diagnose the problem... I also have a DM1105 based card that doesn't attach: [ 1623.471563] DVB: registering new adapter (dm1105) [ 1623.721678] dm1105 :00:0b.0: MAC 00:00:00:00:00:00 [ 1645.919891] si21xx: si21xx_attach [ 1651.283255] si21xx: si21_readreg: readreg error (reg == 0x01, ret == -6) [ 1656.653869] si21xx: si21_writereg: writereg error (reg == 0x01, data == 0x40, ret == -6) [ 1662.223209] si21xx: si21_readreg: readreg error (reg == 0x00, ret == -6) [ 1662.223235] dm1105 :00:0b.0: could not attach frontend Any idea what I could do to find out whats wrong? Thanks, J -- 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: RTL28XX driver
On 12.04.2012 00:33, Oliver Schinagl wrote: On 04/11/12 21:12, Antti Palosaari wrote: I have some old stubbed drivers that just works for one frequency using combination of RTL2832U + FC2580. Also I have rather well commented USB sniff from that device. I can sent those if you wish. FC2580? Do you have anything for/from that driver? My USB stick as an AFA9035 based one, using that specific tuner. Nothing but stubbed driver that contains static register values taken from the sniff and it just tunes to one channel (IIRC 634 MHz / 8 MHz BW). Feel free to contribute new tuner driver in order to add support for your AF9035 device. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RTL28XX driver
On 04/11/12 21:12, Antti Palosaari wrote: On 09.04.2012 15:02, Thomas Mair wrote: thanks for your information. I did get in touch with Realtek and they provided me with the datasheet for the RTL2832U. So what I will try to do is write a demodulator driver for the RTL2832 demod chip following the information of the datasheet and the Realtek driver. I will follow Antti's RTL2830 driver structure. For now there is only one question left regarding the testing of the drivers. What is the best way to test and debug the drivers. Sould I compile the 3.4 kernel and use it, or is it safer to set up a structure like the one I already have to test the driver with a stable kernel? I vote for cloning Mauro's latest staging Kernel 3.5 and use it. http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5 I have some old stubbed drivers that just works for one frequency using combination of RTL2832U + FC2580. Also I have rather well commented USB sniff from that device. I can sent those if you wish. FC2580? Do you have anything for/from that driver? My USB stick as an AFA9035 based one, using that specific tuner. Oliver -- 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] v4l2: use unsigned rather than enums in ioctl() structs
Le mercredi 11 avril 2012 22:53:23 Mauro Carvalho Chehab, vous avez écrit : > > But you have been royally ignoring that rule when it > > comes to extending existing enumerations: > The existing enumerations can be extended, by adding new values for unused > values, otherwise API functionality can't be extended. Yes. That's why they should be some unsigned type. > Yet, except > for a gcc bug (or weird optimize option), I fail to see why this would > break the ABI. >From the perspective of the compiler, this is a feature not a bug. In C and C++, loading or storing a value in an enumerated variable whereby the value is not a member of the enumeration is undefined. In other words, the compiler can assume that this does not happen, and optimize it away. > If this is all about some gcc optimization with newer gcc versions, then > maybe the solution may be to add some pragmas at the code to disable such > optimization when compiling the structs with enum's at videodev2.h. Maybe the Linux kernel could be specifically compiled to prevent GCC from range-optimizing enumerations. But as -fno-jump-table only disables one of several potential range optimizations, I doubt this is even possible. Regardless, you cannot require all of Linux userspace to rely on an hypothetic non-standard GNU C extension. Thus extending enums remains a silent userspace ABI break in any case. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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] v4l2: use unsigned rather than enums in ioctl() structs
Em 11-04-2012 15:47, Rémi Denis-Courmont escreveu: > Hello, > > Le mercredi 11 avril 2012 20:02:00 Mauro Carvalho Chehab, vous avez écrit : >> Using unsigned instead of enum is not a good idea, from API POV, as >> unsigned has different sizes on 32 bits and 64 bits. > > Fair enough. But then we can do that instead: > typedef XXX __enum_t; > where XXX is the unsigned integer with the right number of bits. Since Linux > does not use short enums, this ought to work fine. I forgot to comment about that on the last e-mail. A solution close to the above one were already proposed: http://www.spinics.net/lists/vfl/msg25707.html There were also another proposal there that might solve: http://www.spinics.net/lists/vfl/msg25702.html Something like: #if sizeof(enum) == 1 typedef u8 __enum_t; #elif sizeof(enum) == 2 typedef u16 __enum_t; #elif sizeof(enum) == 4 typedef u32 __enum_t; #elif sizeof(enum) == 8 typedef u64 __enum_t; #else typedef enum __enum_t; #endif Can actually work. Not sure if I really like adding a typedef, but maybe this is the less dirty way to fix it. We'll need to properly test the v4l2-compat32 code, as it will need to handle a different enum size on userspace. So, there, we'll likely need to replace every enum with just "u32". Hmm... arm with 64 bits (if/when added) may be an additional issue for the compat stuff. Regards, 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] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs
Em 11-04-2012 15:47, Rémi Denis-Courmont escreveu:
> Hello,
>
> Le mercredi 11 avril 2012 20:02:00 Mauro Carvalho Chehab, vous avez écrit :
>> Using unsigned instead of enum is not a good idea, from API POV, as
>> unsigned has different sizes on 32 bits and 64 bits.
>
> Fair enough. But then we can do that instead:
> typedef XXX __enum_t;
> where XXX is the unsigned integer with the right number of bits. Since Linux
> does not use short enums, this ought to work fine.
>
>> Yet, using enum was really a very bad idea, and, on all new stuff,
>> we're not accepting any new enum field.
>
> That is unfortunately not true. You do follow that rule for new fields to
> existing V4L2 structure.
Yes, that's what I meant.
> But you have been royally ignoring that rule when it
> comes to extending existing enumerations:
The existing enumerations can be extended, by adding new values for unused
values, otherwise API functionality can't be extended. Yet, except
for a gcc bug (or weird optimize option), I fail to see why this would break
the ABI.
If this is all about some gcc optimization with newer gcc versions, then maybe
the solution may be to add some pragmas at the code to disable such optimization
when compiling the structs with enum's at videodev2.h.
> linux-media does regularly add new enum values to existing enums. That is new
> stuff too, and every single time you do that, you do BREAK THE USERSPACE ABI.
> This is entirely unacceptable and against established kernel development
> policies.
>
> For instance, in Linux 3.1, V4L2_CTRL_TYPE_BITMASK was added. This broke
> userspace.
The patch is:
commit fa4d7096d1fb7c012ebaacefee132007a21e0965
Author: Hans Verkuil
Date: Mon May 23 04:07:05 2011 -0300
[media] v4l2-ctrls: add new bitmask control type
Signed-off-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
Acked-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
...
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f002006..148d1a5 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1040,6 +1040,7 @@ enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_INTEGER64 = 5,
V4L2_CTRL_TYPE_CTRL_CLASS= 6,
V4L2_CTRL_TYPE_STRING= 7,
+ V4L2_CTRL_TYPE_BITMASK = 8,
};
/* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
This doesn't change the existing v4l2_ctrl_type codes. So, it shouldn't be
producing any harm at the existing code.
> And there are some pending patches adding more of the same thing...
> And V4L2_MEMORY_DMABUF will similarly break the user-to-kernel interface,
> which is yet worse.
>
>> That's said, a patch like that were proposed in the past. See:
>> http://www.spinics.net/lists/vfl/msg25686.html
>>
>> Alan said there [1] that:
>> "Its a fundamental change to a public structure from enum to u32. I
>> think
>> you are right but this change seems too late by several years."
>
> I cannot see how the kernel is protected against userspace injecting error
> values into enums. For all I know, depending how the kernel is compiled,
> userspace might be able to trigger "undefined" behavior in kernel space.
>
> Is it be several years too late to fix a bug?
No, but causing an ABI breakage like what it would happen by replacing
"enums" by u32 would break all binaries on x86_64 kernels (and vice-versa
if using u64, breaking all i386 binaries).
>From what I remember from the 2006 discussions, even using "unsigned" may
lead into breakages on some non-x86 architectures that use u16 for enums,
as, on those archs, unsigned is 32 bits.
>
> (...)
>> I don't think anything has changed since then that would make it easier
>> to apply a change like that.
>
> OK. But then you cannot update extend existing enums... No DMA buffers, no
> integer menu controls...
>
Regards,
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: RTL28XX driver
On 09.04.2012 15:02, Thomas Mair wrote: thanks for your information. I did get in touch with Realtek and they provided me with the datasheet for the RTL2832U. So what I will try to do is write a demodulator driver for the RTL2832 demod chip following the information of the datasheet and the Realtek driver. I will follow Antti's RTL2830 driver structure. For now there is only one question left regarding the testing of the drivers. What is the best way to test and debug the drivers. Sould I compile the 3.4 kernel and use it, or is it safer to set up a structure like the one I already have to test the driver with a stable kernel? I vote for cloning Mauro's latest staging Kernel 3.5 and use it. http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5 I have some old stubbed drivers that just works for one frequency using combination of RTL2832U + FC2580. Also I have rather well commented USB sniff from that device. I can sent those if you wish. As general instruction try following. It is what I usually do and I think many other Linux developers too. 1) take USB sniffs. SniffUSB 2.0. http://www.pcausa.com/Utilities/UsbSnoop/ 2) parse those sniffs using parser.pl script 3) log is still too big due to video stream, remove it sed -e 's/BULK\[00081\].*$/BULK\[00081\] MPEG2 TS packet data removed/g' log.org > log.new 4) now you should have small ~100kB sniff, open it in text editor 5) analyze sniff. find out tuner I2C messages, then demod messages, usb-controller messages, etc. 6) make python/perl script to generate C-code like write_regs(0xaa, 0x12); copy paste that code to driver skeleton until it starts working 7) implement all correctly callback per callback until you are fine with code. Most important demod callbacks are .set_frontend() and .read_status(). Others are not required, I mean .read_snr(), .read_ber(), .read_ucblocks() and .read_signal_strength(). IIRC RTL2830 .read_status() is similar as RTL2832 and it is already working. You can copy directly from RTL2830 driver these functions as those are similar: rtl2830_wr() rtl2830_rd() rtl2830_wr_regs() rtl2830_rd_regs() rtl2830_rd_regs() // oops wrong name rtl2830_rd_reg() rtl2830_wr_reg_mask() rtl2830_rd_reg_mask() Consider also making making routines for access those "virtual" registers as RTL2830/RTL2832 uses "virtual" bit based registers over real hardware registers. Some extra work but surely easy many things as you don't need to play with bits. Representation can be made like that or make your own model: #define REGISTER_NAME bit LSB> regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs
Hello, Le mercredi 11 avril 2012 20:02:00 Mauro Carvalho Chehab, vous avez écrit : > Using unsigned instead of enum is not a good idea, from API POV, as > unsigned has different sizes on 32 bits and 64 bits. Fair enough. But then we can do that instead: typedef XXX __enum_t; where XXX is the unsigned integer with the right number of bits. Since Linux does not use short enums, this ought to work fine. > Yet, using enum was really a very bad idea, and, on all new stuff, > we're not accepting any new enum field. That is unfortunately not true. You do follow that rule for new fields to existing V4L2 structure. But you have been royally ignoring that rule when it comes to extending existing enumerations: linux-media does regularly add new enum values to existing enums. That is new stuff too, and every single time you do that, you do BREAK THE USERSPACE ABI. This is entirely unacceptable and against established kernel development policies. For instance, in Linux 3.1, V4L2_CTRL_TYPE_BITMASK was added. This broke userspace. And there are some pending patches adding more of the same thing... And V4L2_MEMORY_DMABUF will similarly break the user-to-kernel interface, which is yet worse. > That's said, a patch like that were proposed in the past. See: > http://www.spinics.net/lists/vfl/msg25686.html > > Alan said there [1] that: > "Its a fundamental change to a public structure from enum to u32. I > think > you are right but this change seems too late by several years." I cannot see how the kernel is protected against userspace injecting error values into enums. For all I know, depending how the kernel is compiled, userspace might be able to trigger "undefined" behavior in kernel space. Is it be several years too late to fix a bug? (...) > I don't think anything has changed since then that would make it easier > to apply a change like that. OK. But then you cannot update extend existing enums... No DMA buffers, no integer menu controls... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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 Broken driver cx23885 mygica x8507
Hi all
I found that this is the patch that makes no sound and deformation image on
mygica x8507:
http://git.kernellabs.com/?p=stoth/cx23885-hvr1850-fixups.git;a=commit;h=e187d0d51bcd0659eeac1d608284644ec8404239
I will try to find that lines are responsible.
Please refer to the patch mentioned above.
lines that leave without sound to the card are these:
@@ -1086,6 +1232,23 @@ static int set_input(struct i2c_client *client,
enum cx25840_video_input vid_inp
cx25840_write4(client, 0x8d0, 0x1f063870);
}
+ if (is_cx2388x(state)) {
+ /* HVR1850 */
+ /* AUD_IO_CTRL - I2S Input, Parallel1*/
+ /* - Channel 1 src - Parallel1 (Merlin out) */
+ /* - Channel 2 src - Parallel2 (Merlin out) */
+ /* - Channel 3 src - Parallel3 (Merlin AC97 out) */
+ /* - I2S source and dir - Merlin, output */
+ cx25840_write4(client, 0x124, 0x100);
+
->+ if (!is_dif) {
->+ /* Stop microcontroller if we don't need it
->+* to avoid audio popping on svideo/compositeuse.
->+*/
->+ cx25840_and_or(client, 0x803, ~0x10, 0x00);
->+ }
+ }
+
return 0;
}
Without these lines, have sound.
And the following line produces a vertical green bar on the right and
the image is a bit narrow (maybe taken as an image of 702 pixel).
If I cancel that line, the image is colored with alternating bars and
color distorted.
@@ -631,6 +654,37 @@ static void cx23885_initialize(struct i2c_client
*client)
/* Disable and clear audio interrupts - we don't use them */
cx25840_write(client, CX25840_AUD_INT_CTRL_REG, 0xff);
cx25840_write(client, CX25840_AUD_INT_STAT_REG, 0xff);
+
+ /* CC raw enable */
+ /* - VIP 1.1 control codes - 10bit, blue field enable.
+* - enable raw data during vertical blanking.
+* - enable ancillary Data insertion for 656 or VIP.
+*/
->+ cx25840_write4(client, 0x404, 0x0010253e);
With kernel 3.0, 3.1 and 3.2 the card worked fine.
Thanks,
Alfredo
--
Dona tu voz
http://www.voxforge.org/es
--
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] v4l2: use unsigned rather than enums in ioctl() structs
Em 05-04-2012 14:52, Rémi Denis-Courmont escreveu:
> With an enumeration, the compiler assumes that the integer value is one
> allowed by the underlying enumeration type. With optimization enabled
> this can result in byte code that is unable to cope with other values.
> For instance, GCC can compile a switch() block using a "jump table" to
> avoid repetitive conditional branching.
>
> This can be a problem both from user to kernel and kernel to user.
>
> * Evil user space can pass error values to the kernel via system
> calls. There are no sane ways to protect the kernel: the compiler may
> optimize away range checks if it deems that all legitimate values are
> within the range.
>
> * The kernel can break the user space binary interface whenever a new
> value is added to an existing enumeration. A newer kernel can then
> return an enumerated value that was not allowed by older kernel headers
> against which the user program was compiled. In principles, V4L2 user
> space needs to be recompiled whenever videodev2.h has updated enums...
> (This an obvious problem with V4L2_QUERYCTRL.)
>
> Fortunately, the Linux ABI disables short-enums on all platforms. Even
> the Linux variant of the ARM AAPCS contradicts the standard ARM AAPCS
> in doing so.
Using unsigned instead of enum is not a good idea, from API POV, as unsigned
has different sizes on 32 bits and 64 bits. Yet, using enum was really a very
bad idea, and, on all new stuff, we're not accepting any new enum field.
That's said, a patch like that were proposed in the past. See:
http://www.spinics.net/lists/vfl/msg25686.html
Alan said there [1] that:
"Its a fundamental change to a public structure from enum to u32. I
think you
are right but this change seems too late by several years."
I also didn't like it, because of the same reasons.
[1] http://www.spinics.net/lists/vfl/msg25687.html
I don't think anything has changed since then that would make it easier
to apply a change like that.
Well, eventually, a compat code at the v4l2-ioctl.c might be written to
translate
a call if the enum size is different than the integer size.
Regards,
Mauro
>
> Signed-off-by: Rémi Denis-Courmont
> ---
> include/linux/videodev2.h | 42 +-
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index c9c9a46..df3b8f0 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -292,10 +292,10 @@ struct v4l2_pix_format {
> __u32 width;
> __u32 height;
> __u32 pixelformat;
> - enum v4l2_field field;
> + unsignedfield;
> __u32 bytesperline; /* for padding, zero if unused
> */
> __u32 sizeimage;
> - enum v4l2_colorspacecolorspace;
> + unsignedcolorspace;
> __u32 priv; /* private data, depends on
> pixelformat */
> };
>
> @@ -432,7 +432,7 @@ struct v4l2_pix_format {
> */
> struct v4l2_fmtdesc {
> __u32 index; /* Format number */
> - enum v4l2_buf_type type; /* buffer type*/
> + unsignedtype; /* buffer type*/
> __u32 flags;
> __u8description[32]; /* Description string */
> __u32 pixelformat; /* Format fourcc */
> @@ -573,8 +573,8 @@ struct v4l2_jpegcompression {
> */
> struct v4l2_requestbuffers {
> __u32 count;
> - enum v4l2_buf_type type;
> - enum v4l2_memorymemory;
> + unsignedtype;
> + unsignedmemory;
> __u32 reserved[2];
> };
>
> @@ -636,16 +636,16 @@ struct v4l2_plane {
> */
> struct v4l2_buffer {
> __u32 index;
> - enum v4l2_buf_type type;
> + unsignedtype;
> __u32 bytesused;
> __u32 flags;
> - enum v4l2_field field;
> + unsignedfield;
> struct timeval timestamp;
> struct v4l2_timecodetimecode;
> __u32 sequence;
>
> /* memory location */
> - enum v4l2_memorymemory;
> + unsignedmemory;
> union {
> __u32 offset;
> unsigned long userptr;
> @@ -708,7 +708,7 @@ struct v4l2_clip {
>
> struct v4l2_window {
> struct v4l2_rectw;
> - enum v4l2_field field;
> + unsignedfield;
> __u32 chromakey;
> struct v4l2_clip__user *clips;
> __u32 clipcount;
> @@ -745,14 +745,14 @@ struct v4l2_outputparm {
> * I N P U T I M A G E C R O P P I
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Apr 11 19:00:23 CEST 2012 git hash:976a87b9ce3172065e21f0d136353a01df06d0d6 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: 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-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: 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-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Updated DVB-T tuning file for uk-SuttonColdfield
Update as frequencies were changed in September 2011 during UK digital switchover. --- a/util/scan/dvb-t/uk-SuttonColdfieldTue Apr 10 16:44:06 2012 +0200 +++ b/util/scan/dvb-t/uk-SuttonColdfieldWed Apr 11 13:54:13 2012 +0100 @@ -1,10 +1,13 @@ -# UK, Sutton Coldfield -# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html -# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 634167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 658167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 682167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 714167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 722167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 74600 8MHz 3/4 NONE QAM16 2k 1/32 NONE +#-- +# location and provider: UK, Sutton Coldfield +# date (-mm-dd): 2012-04-11 +# provided by : Nick Morrott +# +# T[2] [# comment] +#-- +T 65000 8MHz 2/3 NONE QAM64 8k1/32 NONE # PSB1 BBCA +T 67400 8MHz 2/3 NONE QAM64 8k1/32 NONE # PSB2 D3+4 +T 64200 8MHz 2/3 NONE QAM64 8k1/32 NONE # COM4 SDN +T 618167000 8MHz 3/4 NONE QAM64 8k1/32 NONE # COM6 ArqB +T 66600 8MHz 2/3 NONE QAM64 8k1/32 NONE # COM5 ArqA +T2 626167000 8MHz 2/3 NONE QAM256 AUTO AUTO NONE # PSB3 BBCB (needs verifying) Cheers, Nick -- 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 11/11] v4l: vb2: Add dma-contig allocator as dma_buf user
Hi Laurent,
Thanks for review.
On 04/06/2012 05:12 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:08 Tomasz Stanislawski wrote:
>> From: Sumit Semwal
>>
>> This patch makes changes for adding dma-contig as a dma_buf user. It
>> provides function implementations for the {attach, detach, map,
>> unmap}_dmabuf() mem_ops of DMABUF memory type.
>>
>> Signed-off-by: Sumit Semwal
>> Signed-off-by: Sumit Semwal
>> [author of the original patch]
>> Signed-off-by: Tomasz Stanislawski
>> [integration with refactored dma-contig allocator]
>> ---
>> drivers/media/video/videobuf2-dma-contig.c | 117 +
>> 1 files changed, 117 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index 30f316588..6329483
>> 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
>> @@ -10,6 +10,7 @@
>> * the Free Software Foundation.
>> */
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -33,6 +34,9 @@ struct vb2_dc_buf {
>>
>> /* USERPTR related */
>> struct vm_area_struct *vma;
>> +
>> +/* DMABUF related */
>> +struct dma_buf_attachment *db_attach;
>> };
>>
>> /*/
>> @@ -425,6 +429,115 @@ fail_buf:
>> }
>>
>> /*/
>> +/* callbacks for DMABUF buffers*/
>> +/*/
>> +
>> +static int vb2_dc_map_dmabuf(void *mem_priv)
>> +{
>> +struct vb2_dc_buf *buf = mem_priv;
>> +struct sg_table *sgt;
>> +unsigned long contig_size;
>> +int ret = 0;
>> +
>> +if (WARN_ON(!buf->db_attach)) {
>> +printk(KERN_ERR "trying to pin a non attached buffer\n");
>> +return -EINVAL;
>> +}
>> +
>> +if (WARN_ON(buf->dma_sgt)) {
>> +printk(KERN_ERR "dmabuf buffer is already pinned\n");
>> +return 0;
>> +}
>> +
>> +/* get the associated scatterlist for this buffer */
>> +sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
>> +if (IS_ERR_OR_NULL(sgt)) {
>> +printk(KERN_ERR "Error getting dmabuf scatterlist\n");
>> +return -EINVAL;
>> +}
>> +
>> +/* checking if dmabuf is big enough to store contiguous chunk */
>> +contig_size = vb2_dc_get_contiguous_size(sgt);
>> +if (contig_size < buf->size) {
>> +printk(KERN_ERR "contiguous chunk of dmabuf is too small\n");
>> +ret = -EFAULT;
>> +goto fail_map;
>
> The fail_map label is only used here, you can move the
> dma_buf_unmap_attachment() call here and return -EFAULT directly.
>
Patch "[RFC 07/13] v4l: vb2-dma-contig: change map/unmap behaviour for
importers"
introduces other cleanup labels. Anyway I will remove this redundant label as
you proposed.
>> +}
>> +
>> +buf->dma_addr = sg_dma_address(sgt->sgl);
>> +buf->dma_sgt = sgt;
>> +
>> +return 0;
>> +
>> +fail_map:
>> +dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
>> +
>> +return ret;
>> +}
>> +
>> +static void vb2_dc_unmap_dmabuf(void *mem_priv)
>> +{
>> +struct vb2_dc_buf *buf = mem_priv;
>> +struct sg_table *sgt = buf->dma_sgt;
>> +
>> +if (WARN_ON(!buf->db_attach)) {
>> +printk(KERN_ERR "trying to unpin a not attached buffer\n");
>> +return;
>> +}
>> +
>> +if (WARN_ON(!sgt)) {
>> +printk(KERN_ERR "dmabuf buffer is already unpinned\n");
>> +return;
>> +}
>> +
>> +dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
>> +
>> +buf->dma_addr = 0;
>> +buf->dma_sgt = NULL;
>> +}
>> +
>> +static void vb2_dc_detach_dmabuf(void *mem_priv)
>> +{
>> +struct vb2_dc_buf *buf = mem_priv;
>> +
>> +if (buf->dma_addr)
>> +vb2_dc_unmap_dmabuf(buf);
>
> What would you think about calling vb2_dc_unmap_dmabuf() from vb2 core
> instead, to keep the map/unmap calls symmetrical (the second WARN_ON and the
> related printk in vb2_dc_unmap_dmabuf() might need to go then) ?
>
Detach without unmap may happen in a case of closing a video fd
without prior dequeuing of all buffers.
A call map_dmabuf should be moved to __enqueue_in_driver and add calling
unmap_dmabuf to vb2_buffer_done in order to keep map/unmap calls
symmetrical. I'll check if this could work.
Regards,
Tomasz Stanislawski
--
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 03/11] v4l: vb2: add support for shared buffer (dma_buf)
On 04/06/2012 03:29 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:00 Tomasz Stanislawski wrote:
>> From: Sumit Semwal
>>
>> This patch adds support for DMABUF memory type in videobuf2. It calls
>> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
>>
>> For this version, the support is for videobuf2 as a user of the shared
>> buffer; so the allocation of the buffer is done outside of V4L2. [A sample
>> allocator of dma-buf shared buffer is given at [1]]
>>
>> [1]: Rob Clark's DRM:
>>https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
>>
>> Signed-off-by: Tomasz Stanislawski
>>[original work in the PoC for buffer sharing]
>> Signed-off-by: Sumit Semwal
>> Signed-off-by: Sumit Semwal
>> ---
>> drivers/media/video/videobuf2-core.c | 184 ++-
>> include/media/videobuf2-core.h | 31 ++
>> 2 files changed, 214 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-core.c
>> b/drivers/media/video/videobuf2-core.c index 2e8f1df..b37feea 100644
>> --- a/drivers/media/video/videobuf2-core.c
>> +++ b/drivers/media/video/videobuf2-core.c
>
> [snip]
>
>> @@ -451,6 +482,21 @@ static int __verify_mmap_ops(struct vb2_queue *q)
>> }
>>
>> /**
>> + * __verify_dmabuf_ops() - verify that all memory operations required for
>> + * DMABUF queue type have been provided
>> + */
>> +static int __verify_dmabuf_ops(struct vb2_queue *q)
>> +{
>> +if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf
>> +|| !q->mem_ops->detach_dmabuf
>> +|| !q->mem_ops->map_dmabuf
>> +|| !q->mem_ops->unmap_dmabuf)
>
> That's pretty strange indentation. What about
>
> if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf ||
> !q->mem_ops->detach_dmabuf || !q->mem_ops->map_dmabuf ||
> !q->mem_ops->unmap_dmabuf)
>
ok
>> +return -EINVAL;
>> +
>> +return 0;
>> +}
>> +
>> +/**
>> * vb2_reqbufs() - Initiate streaming
>> * @q: videobuf2 queue
>> * @req:struct passed from userspace to vidioc_reqbufs handler in driver
>> @@ -484,6 +530,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct
>> v4l2_requestbuffers *req) }
>>
>> if (req->memory != V4L2_MEMORY_MMAP
>> +&& req->memory != V4L2_MEMORY_DMABUF
>> && req->memory != V4L2_MEMORY_USERPTR) {
>> dprintk(1, "reqbufs: unsupported memory type\n");
>> return -EINVAL;
>
> Ditto.
>
> [snip]
>
>> @@ -620,7 +672,8 @@ int vb2_create_bufs(struct vb2_queue *q, struct
>> v4l2_create_buffers *create) }
>>
>> if (create->memory != V4L2_MEMORY_MMAP
>> -&& create->memory != V4L2_MEMORY_USERPTR) {
>> +&& create->memory != V4L2_MEMORY_USERPTR
>> +&& create->memory != V4L2_MEMORY_DMABUF) {
>> dprintk(1, "%s(): unsupported memory type\n", __func__);
>> return -EINVAL;
>> }
>
> And here too.
>
> [snip]
>
>> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
>> index a15d1f1..665e846 100644
>> --- a/include/media/videobuf2-core.h
>> +++ b/include/media/videobuf2-core.h
>
> [snip]
>
>> @@ -65,6 +82,17 @@ struct vb2_mem_ops {
>> unsigned long size, int write);
>> void(*put_userptr)(void *buf_priv);
>>
>> +/*
>> + * Comment from Rob Clark: XXX: I think the attach / detach could be
>> + * handled in the vb2 core, and vb2_mem_ops really just need to get/put
>> + * the sglist (and make sure that the sglist fits it's needs..)
>> + */
>
> I think we should address this now. We've previously discussed the question,
> but haven't reached an agreement.
>
> Quoting my reply to "[RFCv2 PATCH 3/9] v4l: vb2: Add dma-contig allocator as
> dma_buf user" on 28/03/2012:
>
>>> Calling dma_buf_attach could be moved to vb2-core. But it gives little
>>> gain. First, the pointer of dma_buf_attachment would have to be added to
>>> struct vb2_plane. Second, the allocator would have to keep in the copy of
>>> this pointer in its context structure for use of vb2_dc_(un)map_dmabuf
>>> functions.
>>
>> Right. Would it make sense to pass the vb2_plane pointer, or possibly the
>> dma_buf_attachment pointer, to the mmap_dmabuf and unmap_dmabuf operations ?
>>
>>> Third, dma_buf_attach requires a pointer to 'struct device' which is not
>>> available in the vb2-core layer.
>>
>> OK, that's a problem.
>>
>>> Because of the mentioned reasons I decided to keep attach_dmabuf in
>>> allocator-specific code.
>>
>> Maybe it would make sense to create a vb2_mem_buf structure from which
>> vb2_dc_buf (and other allocator-specific buffer descriptors) would inherit ?
>> That structure would store the dma_buf_attach pointer, and common dma-buf
>> code could be put in videobuf2-memops.c and shared between allocat
Re: [PATCH] Add support for TechniSat SkyStar S2 / CX24120-13Z frontend
Hi Jannis, Em 04-04-2012 04:11, Jannis escreveu: > Hi all, > > some (longer) time ago, I posted to this list concerning the > CX24120-frontend > (http://www.spinics.net/lists/linux-media/msg33717.html). By now I > modified the patch to work with linux-3.4-r1 (after the DVB-interface > changes): > > [2.434181] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV > receiver chip loaded successfully > [2.434240] flexcop-pci: will use the HW PID filter. > [2.434242] flexcop-pci: card revision 2 > [2.438105] DVB: registering new adapter (FlexCop Digital TV device) > [2.440018] b2c2-flexcop: MAC address = 00:08:c9:e0:87:57 > [2.440024] CX24120: cx24120_attach: -> Conexant cx24120/cx24118 - > DVBS/S2 Satellite demod/tuner > [2.440025] CX24120: cx24120_attach: -> Driver version: 'SVT - 0.0.4a >03.04.2012' > [2.440149] CX24120: cx24120_attach: -> Demod CX24120 rev. 0x07 detected. > [2.440150] CX24120: cx24120_attach: -> Conexant cx24120/cx24118 - > DVBS/S2 Satellite demod/tuner ATTACHED. > [2.440440] b2c2-flexcop: ISL6421 successfully attached. > [2.440440] b2c2-flexcop: found 'Conexant CX24120/CX24118' . > [2.440442] DVB: registering adapter 0 frontend 0 (Conexant > CX24120/CX24118)... > [2.440648] b2c2-flexcop: initialization of 'Sky2PC/SkyStar S2 > DVB-S/S2 rev 3.3' at the 'PCI' bus controlled by a 'FlexCopIIb' complete > > As stated in the original message, the patch is not written by me, the > author is Sergey Tyurin, I just modified it so it keeps working with > current kernels. Since I don't know an appropiate location for > publishing this, I thought this is best sent upstream. If the patch was made by Sergey, you should add, at the beginning of the body of the email, a like like: From: Sergey Tyurin and add your comments like: [jannis-li...@kripserver.net: patch ported to the current DVB kernel ABI] You should also add your Signed-off-by:. It is also highly recommended that you would get Sergey's Signed-off-by on it. Please see LinuxTV developer wiki pages, in order to check the proper ways to submit the patch upstream. In particular, please check the patch using scripts/checkpatch.pl. This tool checks the patch CodingStyle. It also checks a few trivial mistakes. It currently doesn't like this code very much: ERROR: Missing Signed-off-by: line(s) total: 515 errors, 394 warnings, 1522 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile As you're not the author of the original driver, the better procedure is to submit Sergey's driver as-is (but without the Kconfig/Makefile changes, in order to avoid it to break compilation), then a patch fixing it to the current ABI from you, and patch/patch series from you fixing the CodingStyle issues. Btw, scripts/Lindent in general solves most of those issues (although it is not a perfect tool). > This patch was tested with some channels (SDTV, HDTV and audio only > (radio)) from Astra-19.2E in Europe. > > If you have any comments abouth things that stop the patch from going > upstream, please feel free to tell me and I'll see if I can change them. I just did a quick look on it, as it is harder to analyze a code with a different CodingStyle. There are too many EXPORT_SYMBOL() there, several of them for static functions. That's wrong. Only non-static functions used by other modules should use EXPORT_SYMBOL. Probably, the only function that requires it is cx24120_attach(). Anyway, I'll do a deeper review after you fix the pointed issues. > > Best regards, > Jannis Achstetter Regards, 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
[GIT PULL for v3.4-rc3] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus For some fixes for the media drivers: - dvb core: there is a regression found when used with xine. For whatever unknown reason, xine (and xine-lib clients) wants that the frontend to tell what frequency he is using even before the PLL lock (or at least, it expects a non-zero frequency). On DVB, the frequency is only actually known after a frequency zig-zag seek, done by the DVB core. Anyway, the fix was trivial. That solves Fedora BZ#808871. - ivtv: fix a regression when selecting the language channel; - uvc: fix a race-related crash; - it913x: fixes firmware loading; - two few trivial patches (a dependency issue at a radio driver at sound Kconfig, and a warning fix on dvb). Regards, Mauro - Latest commit at the branch: ed0ee0ce0a3224dab5caa088a5f8b6df25924276 [media] uvcvideo: Fix race-related crash in uvc_video_clock_update() The following changes since commit 7483d45f0aee3afc0646d185cabd4af9f6cab58c: Merge branch 'staging/for_v3.4' into v4l_for_linus (2012-03-23 08:06:43 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus Chris Rankin (1): [media] dvb_frontend: regression fix: userspace ABI broken for xine Hans Petter Selasky (1): [media] dvb_frontend: fix compiler warning Hans Verkuil (2): [media] ivtv: Fix AUDIO_(BILINGUAL_)CHANNEL_SELECT regression [media] Drivers/media/radio: Fix build error Laurent Pinchart (1): [media] uvcvideo: Fix race-related crash in uvc_video_clock_update() Malcolm Priestley (1): [media] it913x: fix firmware loading errors drivers/media/dvb/dvb-core/dvb_frontend.c | 12 ++- drivers/media/dvb/dvb-usb/it913x.c| 54 +--- drivers/media/video/ivtv/ivtv-ioctl.c |4 +- drivers/media/video/uvc/uvc_video.c | 50 +- sound/pci/Kconfig |4 +- 5 files changed, 87 insertions(+), 37 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
UVC frame interval inconsistency
Hello guys, I have been reworking the V4L2 input in VLC and I hit what looks like a weird bug in the UVC driver. I am using a Logitech HD Pro C920 webcam. By default, VLC tries to find the highest possible frame rate (actually smallest frame interval in V4L2), then the largest possible resolution at that frame rate. When enumerating the frame sizes and intervals on the device, the winner is 800x600 at 30 f/s. But when setting 30 f/s with VIDIOC_S_PARM, the system call returns 24 f/s. Does anyone know why it is so? Is this a firmware bug or what? -- Rémi Denis-Courmont Sent from my collocated server -- 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 08/11] v4l: vb2-dma-contig: add support for scatterlist in userptr mode
Hi Laurent,
Thank you for review. Your comments are very helpful :).
Take a look on the comments below.
On 04/06/2012 05:02 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 05 April 2012 16:00:05 Tomasz Stanislawski wrote:
>> From: Andrzej Pietrasiewicz
>>
>> This patch introduces usage of dma_map_sg to map memory behind
>> a userspace pointer to a device as dma-contiguous mapping.
>>
>> Signed-off-by: Andrzej Pietrasiewicz
>> Signed-off-by: Marek Szyprowski
>> [bugfixing]
>> Signed-off-by: Kamil Debski
>> [bugfixing]
>> Signed-off-by: Tomasz Stanislawski
>> [add sglist subroutines/code refactoring]
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/videobuf2-dma-contig.c | 282 +++--
>> 1 files changed, 265 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index 476e536..6ab3165 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
>
> [snip]
>
>> @@ -32,6 +36,98 @@ struct vb2_dc_buf {
>> };
>>
>> /*/
>> +/*scatterlist table functions*/
>> +/*/
>> +
>> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
>> +unsigned long n_pages, size_t offset, size_t offset2)
>
> "offset2" isn't very descriptive. I would replace it with the total size of
> the buffer instead (or, alternatively, rename offset to offset_start and
> offset2 to offset_end, but I like the first option better).
>
>> +{
>> +struct sg_table *sgt;
>> +int i, j; /* loop counters */
>
> I don't think the comment is needed.
>
ok
>> +int cur_page, chunks;
>
> i, j, cur_page and chunks can't be negative. Could you please make them
> unsigned int (and I would order them) ?
ok
>
> Also, Documentation/CodingStyle favors one variable declaration per line,
> without commas for multiple declarations.
does it include loop counters like i and j?
>
>> +int ret;
>> +struct scatterlist *s;
>> +
>> +sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
>> +if (!sgt)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +/* compute number of chunks */
>> +chunks = 1;
>> +for (i = 1; i < n_pages; ++i)
>> +if (pages[i] != pages[i - 1] + 1)
>> +++chunks;
>> +
>> +ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
>> +if (ret) {
>> +kfree(sgt);
>> +return ERR_PTR(-ENOMEM);
>> +}
>> +
>> +/* merging chunks and putting them into the scatterlist */
>> +cur_page = 0;
>> +for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
>> +size_t size = PAGE_SIZE;
>> +
>> +for (j = cur_page + 1; j < n_pages; ++j) {
>> +if (pages[j] != pages[j - 1] + 1)
>> +break;
>> +size += PAGE_SIZE;
>> +}
>> +
>> +/* cut offset if chunk starts at the first page */
>> +if (cur_page == 0)
>> +size -= offset;
>> +/* cut offset2 if chunk ends at the last page */
>> +if (j == n_pages)
>> +size -= offset2;
>> +
>> +sg_set_page(s, pages[cur_page], size, offset);
>> +offset = 0;
>> +cur_page = j;
>> +}
>> +
>> +return sgt;
>> +}
>> +
>> +static void vb2_dc_release_sgtable(struct sg_table *sgt)
>> +{
>> +sg_free_table(sgt);
>> +kfree(sgt);
>> +}
>> +
>> +static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
>> +void (*cb)(struct page *pg))
>> +{
>> +struct scatterlist *s;
>> +int i, j;
>> +
>> +for_each_sg(sgt->sgl, s, sgt->nents, i) {
>> +struct page *page = sg_page(s);
>> +int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
>> +
>> +for (j = 0; j < n_pages; ++j, ++page)
>> +cb(page);
>
> Same for i, j and n_pages here.
>
ok
>> +}
>> +}
>> +
>> +static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
>> +{
>> +struct scatterlist *s;
>> +dma_addr_t expected = sg_dma_address(sgt->sgl);
>> +int i;
>
> Same for i here.
>
>> +unsigned long size = 0;
>> +
>> +for_each_sg(sgt->sgl, s, sgt->nents, i) {
>> +if (sg_dma_address(s) != expected)
>> +break;
>> +expected = sg_dma_address(s) + sg_dma_len(s);
>> +size += sg_dma_len(s);
>> +}
>> +return size;
>> +}
>> +
>> +/*/
>> /* callbacks for all buffers */
>> /*/
>>
>> @@ -116,42 +212,194 @@ static int vb2_dc_mmap(void *buf_priv, struct
>> vm_area_struct *vma) /* callbacks for USERPTR buffers */
>> /*/
>>
>> +static inline int vma_is_io(str
Initial tuning file for Danish cable provider YouSee
Hi, I recently setup a tuning back-end, but unfortunately an initial, preliminary scan config was not available for my cable provider. My back end of choice was TV headend and the guys there let me know that they draw their data from the dvb-apps package and that the proper channel for inclusion would be to post it on this list. So attached is an initial scan file for the cable provider YouSee in the Copenhagen area. It is based on the best available data, as the provider doesn't provide a frequency list. It is identical to the frequencies that I can manually collect using the 'scan' tool. Let me know if I'm in the wrong place or need to clear something up. Br, Martin dk-YouSee-Copenhagen Description: Binary data
[PATCH] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
In PJPG blocks, a marker gives the quantization tables to use for image
decoding. This patch dynamically updates the luminance table when the
marker changes.
Note that the values of this table have been guessed from a small
number of images and that they may not work fine in some situations,
but, in most cases, the images are better rendered.
Signed-off-by: Jean-François Moine
diff --git a/lib/libv4lconvert/tinyjpeg-internal.h
b/lib/libv4lconvert/tinyjpeg-internal.h
index 702a2a2..4041251 100644
--- a/lib/libv4lconvert/tinyjpeg-internal.h
+++ b/lib/libv4lconvert/tinyjpeg-internal.h
@@ -103,6 +103,7 @@ struct jdec_private {
#if SANITY_CHECK
unsigned int current_cid; /* For planar JPEG */
#endif
+ unsigned char marker; /* for PJPG (Pixart JPEG) */
/* Temp space used after the IDCT to store each components */
uint8_t Y[64 * 4], Cr[64], Cb[64];
diff --git a/lib/libv4lconvert/tinyjpeg.c b/lib/libv4lconvert/tinyjpeg.c
index 2c2d4af..d986a45 100644
--- a/lib/libv4lconvert/tinyjpeg.c
+++ b/lib/libv4lconvert/tinyjpeg.c
@@ -1376,6 +1376,8 @@ static void decode_MCU_2x1_3planes(struct jdec_private
*priv)
IDCT(&priv->component_infos[cCr], priv->Cr, 8);
}
+static void build_quantization_table(float *qtable, const unsigned char
*ref_table);
+
static void pixart_decode_MCU_2x1_3planes(struct jdec_private *priv)
{
unsigned char marker;
@@ -1384,10 +1386,8 @@ static void pixart_decode_MCU_2x1_3planes(struct
jdec_private *priv)
/* I think the marker indicates which quantization table to use, iow
a Pixart JPEG may have a different quantization table per MCU, most
MCU's have 0x44 as marker for which our special Pixart quantization
- tables are correct. Unfortunately with a 7302 some blocks also have
0x48,
- and sometimes even other values. As 0x48 is quite common too, we
really
- need to find out the correct table for that, as currently the blocks
- with a 0x48 marker look wrong. During normal operation the marker
stays
+ tables are correct. [jfm: snip]
+ During normal operation the marker stays
within the range below, if it gets out of this range we're most
likely
decoding garbage */
if (marker < 0x20 || marker > 0x7f) {
@@ -1396,6 +1396,53 @@ static void pixart_decode_MCU_2x1_3planes(struct
jdec_private *priv)
(unsigned int)marker);
longjmp(priv->jump_state, -EIO);
}
+
+ /* rebuild the Y quantization table when the marker changes */
+ if (marker != priv->marker) {
+ unsigned char quant_new[64];
+ int i, j;
+ /*
+* table to rebuild the Y quantization table
+* index 1 = marker / 4
+* index 2 = 4 end indexes in the quantization table
+* values = 0x08, 0x10, 0x20, 0x40, 0x63
+* jfm: The values have been guessed from 4 images, so,
+* better values may be found...
+*/
+ static const unsigned char q_tb[12][4] = {
+ { 6, 28, 43, 64 }, /* 68 */
+ { 6, 24, 40, 60 },
+ { 4, 18, 30, 55 },
+ { 2, 10, 20, 50 }, /* 80 */
+ { 1, 6, 15, 46 },
+ { 1, 4, 15, 37 },
+ { 1, 3, 15, 30 },
+ { 1, 2, 15, 21 },
+ { 1, 1, 15, 18 }, /* 100 */
+ { 1, 1, 15, 16 },
+ { 1, 1, 15, 15 },
+ { 1, 1, 10, 10 },
+ };
+
+ priv->marker = marker;
+ j = marker - 68;
+ if (j < 0)
+ j = 0;
+ j >>= 2;
+ if (j > sizeof q_tb / sizeof q_tb[0])
+ j = sizeof q_tb / sizeof q_tb[0] - 1;
+ for (i = 0; i < q_tb[j][0]; i++)
+ quant_new[i] = 0x08;
+ for (; i < q_tb[j][1]; i++)
+ quant_new[i] = 0x10;
+ for (; i < q_tb[j][2]; i++)
+ quant_new[i] = 0x20;
+ for (; i < q_tb[j][3]; i++)
+ quant_new[i] = 0x40;
+ for (; i < 64; i++)
+ quant_new[i] = 0x63;
+ build_quantization_table(priv->Q_tables[0], quant_new);
+ }
skip_nbits(priv->reservoir, priv->nbits_in_reservoir, priv->stream, 8);
// Y
@@ -1948,6 +1995,7 @@ static int parse_JFIF(struct jdec_private *priv, const
unsigned char *stream)
if (!priv->default_huffman_table_initialized) {
build_quantization_table(priv->Q_tables[0],
pixart_quantization[0]);
build_quantization_table(priv->
[PATCH] [media] Convert I2C drivers to dev_pm_ops
The legacy I2C PM functions have been deprecated and warning on boot
for over a year, convert the drivers still using them to dev_pm_ops.
Signed-off-by: Mark Brown
---
drivers/media/video/msp3400-driver.c | 15 +++
drivers/media/video/tuner-core.c | 15 +++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/msp3400-driver.c
b/drivers/media/video/msp3400-driver.c
index 82ce507..aeb22be 100644
--- a/drivers/media/video/msp3400-driver.c
+++ b/drivers/media/video/msp3400-driver.c
@@ -597,19 +597,23 @@ static int msp_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int msp_suspend(struct i2c_client *client, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int msp_suspend(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, "suspend\n");
msp_reset(client);
return 0;
}
-static int msp_resume(struct i2c_client *client)
+static int msp_resume(struct device *dev)
{
+ struct i2c_client *client = to_i2c_client(dev);
v4l_dbg(1, msp_debug, client, "resume\n");
msp_wake_thread(client);
return 0;
}
+#endif
/* --- */
@@ -863,6 +867,10 @@ static int msp_remove(struct i2c_client *client)
/* --- */
+static const struct dev_pm_ops msp3400_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(msp_suspend, msp_resume)
+};
+
static const struct i2c_device_id msp_id[] = {
{ "msp3400", 0 },
{ }
@@ -873,11 +881,10 @@ static struct i2c_driver msp_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "msp3400",
+ .pm = &msp3400_pm_ops,
},
.probe = msp_probe,
.remove = msp_remove,
- .suspend= msp_suspend,
- .resume = msp_resume,
.id_table = msp_id,
};
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index a5c6397..3e050e1 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1241,8 +1241,10 @@ static int tuner_log_status(struct v4l2_subdev *sd)
return 0;
}
-static int tuner_suspend(struct i2c_client *c, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int tuner_suspend(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
struct analog_demod_ops *analog_ops = &t->fe.ops.analog_ops;
@@ -1254,8 +1256,9 @@ static int tuner_suspend(struct i2c_client *c,
pm_message_t state)
return 0;
}
-static int tuner_resume(struct i2c_client *c)
+static int tuner_resume(struct device *dev)
{
+ struct i2c_client *c = to_i2c_client(dev);
struct tuner *t = to_tuner(i2c_get_clientdata(c));
tuner_dbg("resume\n");
@@ -1266,6 +1269,7 @@ static int tuner_resume(struct i2c_client *c)
return 0;
}
+#endif
static int tuner_command(struct i2c_client *client, unsigned cmd, void *arg)
{
@@ -1310,6 +1314,10 @@ static const struct v4l2_subdev_ops tuner_ops = {
* I2C structs and module init functions
*/
+static const struct dev_pm_ops tuner_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tuner_suspend, tuner_resume)
+};
+
static const struct i2c_device_id tuner_id[] = {
{ "tuner", }, /* autodetect */
{ }
@@ -1320,12 +1328,11 @@ static struct i2c_driver tuner_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "tuner",
+ .pm = &tuner_pm_ops,
},
.probe = tuner_probe,
.remove = tuner_remove,
.command= tuner_command,
- .suspend= tuner_suspend,
- .resume = tuner_resume,
.id_table = tuner_id,
};
--
1.7.9.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] media_build: fix v2.6.32_kfifo backport patch
This patch:
http://patchwork.linuxtv.org/patch/10425/
collides with the v2.6.32_kfifo backport patch.
Fix it and rebase it on the new media_build tree.
Signed-off-by: Gianluca Gennari
---
backports/v2.6.32_kfifo.patch | 130 ++---
1 files changed, 70 insertions(+), 60 deletions(-)
diff --git a/backports/v2.6.32_kfifo.patch b/backports/v2.6.32_kfifo.patch
index 10075b9..21769a8 100644
--- a/backports/v2.6.32_kfifo.patch
+++ b/backports/v2.6.32_kfifo.patch
@@ -1,36 +1,34 @@
---
- drivers/media/rc/ir-raw.c| 14 +++
- drivers/media/rc/rc-core-priv.h |2 -
- drivers/media/video/cx23885/cx23888-ir.c | 33 ++---
+ drivers/media/rc/ir-raw.c| 16
+ drivers/media/rc/rc-core-priv.h |2 +-
+ drivers/media/video/cx23885/cx23888-ir.c | 33 ++--
drivers/media/video/cx25840/cx25840-ir.c | 28 +-
- drivers/media/video/meye.c | 60
++-
+ drivers/media/video/meye.c | 60 ++
drivers/media/video/meye.h |4 +-
include/media/lirc_dev.h | 50 +
- 7 files changed, 79 insertions(+), 112 deletions(-)
+ 7 files changed, 80 insertions(+), 113 deletions(-)
linux.orig/drivers/media/rc/rc-core-priv.h
-+++ linux/drivers/media/rc/rc-core-priv.h
-@@ -35,7 +35,7 @@ struct ir_raw_event_ctrl {
- struct list_headlist; /* to keep track of raw
clients */
- struct task_struct *thread;
- spinlock_t lock;
-- struct kfifokfifo; /* fifo for the
pulse/space durations */
-+ struct kfifo*kfifo; /* fifo for the
pulse/space durations */
- ktime_t last_event; /* when last event
occurred */
- enum raw_event_type last_type; /* last event type */
- struct rc_dev *dev; /* pointer to the
parent rc_dev */
linux.orig/drivers/media/rc/ir-raw.c
-+++ linux/drivers/media/rc/ir-raw.c
-@@ -44,7 +44,7 @@ static int ir_raw_event_thread(void *dat
+--- a/drivers/media/rc/ir-raw.c
b/drivers/media/rc/ir-raw.c
+@@ -45,7 +45,7 @@ static int ir_raw_event_thread(void *data)
while (!kthread_should_stop()) {
spin_lock_irq(&raw->lock);
+- retval = kfifo_len(&raw->kfifo);
++ retval = kfifo_len(raw->kfifo);
+
+ if (retval < sizeof(ev)) {
+ set_current_state(TASK_INTERRUPTIBLE);
+@@ -58,7 +58,7 @@ static int ir_raw_event_thread(void *data)
+ continue;
+ }
+
- retval = kfifo_out(&raw->kfifo, &ev, sizeof(ev));
+ retval = __kfifo_get(raw->kfifo, (void *)&ev, sizeof(ev));
+ spin_unlock_irq(&raw->lock);
- if (!retval) {
- set_current_state(TASK_INTERRUPTIBLE);
-@@ -90,7 +90,7 @@ int ir_raw_event_store(struct rc_dev *de
+ mutex_lock(&ir_raw_handler_lock);
+@@ -89,7 +89,7 @@ int ir_raw_event_store(struct rc_dev *dev, struct
ir_raw_event *ev)
IR_dprintk(2, "sample: (%05dus %s)\n",
TO_US(ev->duration), TO_STR(ev->pulse));
@@ -39,7 +37,7 @@
return -ENOMEM;
return 0;
-@@ -258,11 +258,11 @@ int ir_raw_event_register(struct rc_dev
+@@ -259,11 +259,11 @@ int ir_raw_event_register(struct rc_dev *dev)
dev->raw->dev = dev;
dev->raw->enabled_protocols = ~0;
@@ -55,7 +53,7 @@
spin_lock_init(&dev->raw->lock);
dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
-@@ -304,7 +304,7 @@ void ir_raw_event_unregister(struct rc_d
+@@ -305,7 +305,7 @@ void ir_raw_event_unregister(struct rc_dev *dev)
handler->raw_unregister(dev);
mutex_unlock(&ir_raw_handler_lock);
@@ -64,8 +62,19 @@
kfree(dev->raw);
dev->raw = NULL;
}
linux.orig/drivers/media/video/cx23885/cx23888-ir.c
-+++ linux/drivers/media/video/cx23885/cx23888-ir.c
+--- a/drivers/media/rc/rc-core-priv.h
b/drivers/media/rc/rc-core-priv.h
+@@ -35,7 +35,7 @@ struct ir_raw_event_ctrl {
+ struct list_headlist; /* to keep track of raw
clients */
+ struct task_struct *thread;
+ spinlock_t lock;
+- struct kfifokfifo; /* fifo for the
pulse/space durations */
++ struct kfifo*kfifo; /* fifo for the
pulse/space durations */
+ ktime_t last_event; /* when last event
occurred */
+ enum raw_event_type last_type; /* last event type */
+ struct rc_dev *dev; /* pointer to the
parent rc_dev */
+--- a/drivers/
[PATCH] media_build: fix v2.6.35_i2c_new_probed_device backport patch
This patch:
http://patchwork.linuxtv.org/patch/10486/
collides with the v2.6.35_i2c_new_probed_device backport patch.
Fix it and rebase it on the new media_build tree.
Signed-off-by: Gianluca Gennari
---
backports/v2.6.35_i2c_new_probed_device.patch | 46
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/backports/v2.6.35_i2c_new_probed_device.patch
b/backports/v2.6.35_i2c_new_probed_device.patch
index d998814..4026dc9 100644
--- a/backports/v2.6.35_i2c_new_probed_device.patch
+++ b/backports/v2.6.35_i2c_new_probed_device.patch
@@ -2,14 +2,14 @@
drivers/media/video/bt8xx/bttv-input.c|2 +-
drivers/media/video/cx18/cx18-i2c.c |2 +-
drivers/media/video/cx23885/cx23885-i2c.c |5 +++--
- drivers/media/video/em28xx/em28xx-cards.c |2 +-
+ drivers/media/video/em28xx/em28xx-input.c |2 +-
drivers/media/video/ivtv/ivtv-i2c.c |6 +++---
drivers/media/video/v4l2-common.c |3 +--
6 files changed, 10 insertions(+), 10 deletions(-)
linux.orig/drivers/media/video/bt8xx/bttv-input.c
-+++ linux/drivers/media/video/bt8xx/bttv-input.c
-@@ -399,7 +399,7 @@ void __devinit init_bttv_i2c_ir(struct b
+--- a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
+@@ -401,7 +401,7 @@ void __devinit init_bttv_i2c_ir(struct bttv *btv)
* That's why we probe 0x1a (~0x34) first. CB
*/
@@ -18,9 +18,9 @@
return;
}
linux.orig/drivers/media/video/cx18/cx18-i2c.c
-+++ linux/drivers/media/video/cx18/cx18-i2c.c
-@@ -104,7 +104,7 @@ static int cx18_i2c_new_ir(struct cx18 *
+--- a/drivers/media/video/cx18/cx18-i2c.c
b/drivers/media/video/cx18/cx18-i2c.c
+@@ -104,7 +104,7 @@ static int cx18_i2c_new_ir(struct cx18 *cx, struct
i2c_adapter *adap, u32 hw,
break;
}
@@ -29,9 +29,9 @@
-1 : 0;
}
linux.orig/drivers/media/video/cx23885/cx23885-i2c.c
-+++ linux/drivers/media/video/cx23885/cx23885-i2c.c
-@@ -344,7 +344,8 @@ int cx23885_i2c_register(struct cx23885_
+--- a/drivers/media/video/cx23885/cx23885-i2c.c
b/drivers/media/video/cx23885/cx23885-i2c.c
+@@ -345,7 +345,8 @@ int cx23885_i2c_register(struct cx23885_i2c *bus)
} else
printk(KERN_WARNING "%s: i2c bus %d register FAILED\n",
dev->name, bus->nr);
@@ -41,7 +41,7 @@
/* Instantiate the IR receiver device, if present */
if (0 == bus->i2c_rc) {
struct i2c_board_info info;
-@@ -359,7 +360,7 @@ int cx23885_i2c_register(struct cx23885_
+@@ -360,7 +361,7 @@ int cx23885_i2c_register(struct cx23885_i2c *bus)
i2c_new_probed_device(&bus->i2c_adap, &info, addr_list,
i2c_probe_func_quick_read);
}
@@ -50,9 +50,9 @@
return bus->i2c_rc;
}
linux.orig/drivers/media/video/em28xx/em28xx-cards.c
-+++ linux/drivers/media/video/em28xx/em28xx-cards.c
-@@ -2454,7 +2454,7 @@ void em28xx_register_i2c_ir(struct em28x
+--- a/drivers/media/video/em28xx/em28xx-input.c
b/drivers/media/video/em28xx/em28xx-input.c
+@@ -429,7 +429,7 @@ static void em28xx_register_i2c_ir(struct em28xx *dev)
if (dev->init_data.name)
info.platform_data = &dev->init_data;
@@ -60,10 +60,10 @@
+ i2c_new_probed_device(&dev->i2c_adap, &info, addr_list);
}
- void em28xx_card_setup(struct em28xx *dev)
linux.orig/drivers/media/video/ivtv/ivtv-i2c.c
-+++ linux/drivers/media/video/ivtv/ivtv-i2c.c
-@@ -186,7 +186,7 @@ static int ivtv_i2c_new_ir(struct ivtv *
+ /**
+--- a/drivers/media/video/ivtv/ivtv-i2c.c
b/drivers/media/video/ivtv/ivtv-i2c.c
+@@ -186,7 +186,7 @@ static int ivtv_i2c_new_ir(struct ivtv *itv, u32 hw, const
char *type, u8 addr)
return -1;
memset(&info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, type, I2C_NAME_SIZE);
@@ -72,7 +72,7 @@
== NULL ? -1 : 0;
}
-@@ -230,7 +230,7 @@ static int ivtv_i2c_new_ir(struct ivtv *
+@@ -230,7 +230,7 @@ static int ivtv_i2c_new_ir(struct ivtv *itv, u32 hw, const
char *type, u8 addr)
info.platform_data = init_data;
strlcpy(info.type, type, I2C_NAME_SIZE);
@@ -81,7 +81,7 @@
-1 : 0;
}
-@@ -257,7 +257,7 @@ struct i2c_client *ivtv_i2c_new_ir_legac
+@@ -257,7 +257,7 @@ struct i2c_client *ivtv_i2c_new_ir_legacy(struct ivtv *itv)
memset(&info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
@@ -90,9 +90,9 @@
}
int ivtv_i2c_register(struct ivtv *itv, unsigned idx)
linux.orig/drivers/media/video/v4l2-common.c
-+++ linux/drivers/media/video/v4l2-common.c
-@@ -316,8 +316,7 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_
+--- a/drivers/media/video/v4l2-common.c
+++
Re: Test application for DMABUF sharing between V4L2 and DRM
Hi Tomasz,
How about to add this program to tools directory? tools/drm or tools/media?
Thank you,
Kyungmin Park
On Wed, Apr 11, 2012 at 1:13 AM, Tomasz Stanislawski
wrote:
> Hi Everyone,
> This email contains a test application showing DMABUF sharing
> between DRM/KMS display and capture node including VIVI.
> It shows a simple preview on LCD display. The similar application
> was posted in thread:
> http://thread.gmane.org/gmane.comp.video.dri.devel/65997
>
> This version makes use of single-plane API for V4L2 capture instead
> of multiplanar. This change allows VIVI driver to be tested as
> DMABUF importer.
>
> The program is written in C99 and it was tested using Exynos/DRM
> and VIVI capture.
>
> This application shows how buffer sharing between V4L2/DRM may look like.
> Please let me know if/where I use DRM/V4L2 incorrectly.
>
> The application was tested against 3.4-rc1 kernel with patches:
>
> - Integration of videobuf2 with dmabuf
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/46586
>
> - Integration of vb2-vmalloc and VIVI with dmabuf
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/46713
>
> - Support for DRM prime for Exynos by Inki Dae
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/exynos-drm-prime
>
> - patch fixing kmap/vmap support for EXYNOS-DRM prime.
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/commit/3c483f24e418f342eac40dc5fb3991e058deb270
>
>
> The branch containing all mentioned patches (without platform code)
> rebased on 3.4-rc1 is available at link:
>
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/v3.4-rc1-v4l-drm-dmabuf-for-test
>
> Regards,
> Tomasz Stanislawski
>
> ---
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
> #include
> #include
>
> #define ERRSTR strerror(errno)
>
> #define BYE_ON(cond, ...) \
> do { \
> if (cond) { \
> int errsv = errno; \
> fprintf(stderr, "ERROR(%s:%d) : ", \
> __FILE__, __LINE__); \
> errno = errsv; \
> fprintf(stderr, __VA_ARGS__); \
> abort(); \
> } \
> } while(0)
>
> static inline int warn(const char *file, int line, const char *fmt, ...)
> {
> int errsv = errno;
> va_list va;
> va_start(va, fmt);
> fprintf(stderr, "WARN(%s:%d): ", file, line);
> vfprintf(stderr, fmt, va);
> va_end(va);
> errno = errsv;
> return 1;
> }
>
> #define WARN_ON(cond, ...) \
> ((cond) ? warn(__FILE__, __LINE__, __VA_ARGS__) : 0)
>
> struct setup {
> char module[32];
> uint32_t conId;
> uint32_t crtId;
> char modestr[32];
> char video[32];
> unsigned int w, h;
> unsigned int use_wh : 1;
> unsigned int in_fourcc;
> unsigned int out_fourcc;
> unsigned int buffer_count;
> unsigned int use_crop : 1;
> unsigned int use_compose : 1;
> struct v4l2_rect crop;
> struct v4l2_rect compose;
> };
>
> struct buffer {
> unsigned int bo_handle;
> unsigned int fb_handle;
> int dbuf_fd;
> };
>
> struct stream {
> int v4lfd;
> int current_buffer;
> int buffer_count;
> struct buffer *buffer;
> } stream;
>
> static void usage(char *name)
> {
> fprintf(stderr, "usage: %s [-Moisth]\n", name);
> fprintf(stderr, "\t-M \tset DRM module\n");
> fprintf(stderr, "\t-o ::\tset a mode\n");
> fprintf(stderr, "\t-i \tset video node like
> /dev/video*\n");
> fprintf(stderr, "\t-S \tset input resolution\n");
> fprintf(stderr, "\t-f \tset input format using 4cc\n");
> fprintf(stderr, "\t-F \tset output format using 4cc\n");
> fprintf(stderr, "\t-s @\tset crop area\n");
> fprintf(stderr, "\t-t @\tset compose area\n");
> fprintf(stderr, "\t-b buffer_count\tset number of buffers\n");
> fprintf(stderr, "\t-h\tshow this help\n");
> fprintf(stderr, "\n\tDefault is to dump all info.\n");
> }
>
> static inline int parse_rect(char *s, struct v4l2_rect *r)
> {
> return sscanf(s, "%d,%d@%d,%d", &r->width, &r->height,
> &r->top, &r->left) != 4;
> }
>
> static int parse_args(int argc, char *argv[], struct setup *s)
> {
> if (argc <= 1)
> usage(argv[0]);
>
> int c, ret;
> memset(s, 0, sizeof(*s));
>
> while ((c = getopt(argc, argv, "M:o:i:S:f:F:s:t:b:h")) != -1) {
> switch (c) {
> case 'M':
> strncpy(s->module, optarg, 31);
> break;
> case 'o':
> ret = sscanf(optarg, "%u:%u:%31s", &s->conId,
> &s->crtId,
> s->modestr);
> if (W
