Re: [RFCv2,1/2] v4l2-controls.h: add addtional Flash fault bits
Hi Daniel, On Tue, Jan 28, 2014 at 03:55:57PM +0900, Daniel Jeong wrote: > Add additional FLASH Fault bits to dectect faults from chip. > Some Flash drivers support UVLO, IVFM, NTC Trip faults. > UVLO :Under Voltage Lock Out Threshold crossed > IVFM :IVFM block reported and/or adjusted LED current Input Voltage > Flash Monitor trip threshold > NTC :NTC Threshold crossed. Many Flash drivers have a pin and the > fault bit to > serves as a threshold detector for negative temperature coefficient (NTC) > thermistors. > > Signed-off-by: Daniel Jeong > --- > include/uapi/linux/v4l2-controls.h |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/uapi/linux/v4l2-controls.h > b/include/uapi/linux/v4l2-controls.h > index 1666aab..01d730c 100644 > --- a/include/uapi/linux/v4l2-controls.h > +++ b/include/uapi/linux/v4l2-controls.h > @@ -803,6 +803,9 @@ enum v4l2_flash_strobe_source { > #define V4L2_FLASH_FAULT_SHORT_CIRCUIT (1 << 3) > #define V4L2_FLASH_FAULT_OVER_CURRENT(1 << 4) > #define V4L2_FLASH_FAULT_INDICATOR (1 << 5) > +#define V4L2_FLASH_FAULT_UVLO(1 << 6) > +#define V4L2_FLASH_FAULT_IVFM(1 << 7) > +#define V4L2_FLASH_FAULT_NTC_TRIP(1 << 8) I object adding a new fault which is essentially the same as an existing fault, V4L2_FLASH_FAULT_OVER_TEMPERATURE. As the practice has been to use human-readable names for the faults, I'd also suggest using V4L2_FLASH_FAULT_UNDER_VOLTAGE instead of V4L2_FLASH_FAULT_UVLO. What's the IVFM block and what does it do? > #define V4L2_CID_FLASH_CHARGE > (V4L2_CID_FLASH_CLASS_BASE + 11) > #define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: [RFCv2,1/2] v4l2-controls.h: add addtional Flash fault bits
2014년 01월 28일 18:08, Sakari Ailus 쓴 글: Hi Daniel, On Tue, Jan 28, 2014 at 03:55:57PM +0900, Daniel Jeong wrote: Add additional FLASH Fault bits to dectect faults from chip. Some Flash drivers support UVLO, IVFM, NTC Trip faults. UVLO : Under Voltage Lock Out Threshold crossed IVFM : IVFM block reported and/or adjusted LED current Input Voltage Flash Monitor trip threshold NTC : NTC Threshold crossed. Many Flash drivers have a pin and the fault bit to serves as a threshold detector for negative temperature coefficient (NTC) thermistors. Signed-off-by: Daniel Jeong --- include/uapi/linux/v4l2-controls.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h index 1666aab..01d730c 100644 --- a/include/uapi/linux/v4l2-controls.h +++ b/include/uapi/linux/v4l2-controls.h @@ -803,6 +803,9 @@ enum v4l2_flash_strobe_source { #define V4L2_FLASH_FAULT_SHORT_CIRCUIT(1 << 3) #define V4L2_FLASH_FAULT_OVER_CURRENT (1 << 4) #define V4L2_FLASH_FAULT_INDICATOR(1 << 5) +#define V4L2_FLASH_FAULT_UVLO (1 << 6) +#define V4L2_FLASH_FAULT_IVFM (1 << 7) +#define V4L2_FLASH_FAULT_NTC_TRIP (1 << 8) I object adding a new fault which is essentially the same as an existing fault, V4L2_FLASH_FAULT_OVER_TEMPERATURE. I hope you consider it again. Usually, when the die temperature exceeds the specific temperature, ie 120 or 135 and fixed value, turn off PFET,NFET, current sources and set TEMP Fault bit. But in the NTC mode, the comparator is working and detect selected temperature through Vtrip value. It protects shutdown the chip due to high voltage and keep the device operation. Many flash chip support NTC and TEMP Fault both. For example, LM3554, LM3556, LM3559 LM3642, LM3646, LM3560, LM3561, LM3565 etc Two things should be tell apart. As the practice has been to use human-readable names for the faults, I'd also suggest using V4L2_FLASH_FAULT_UNDER_VOLTAGE instead of V4L2_FLASH_FAULT_UVLO. I agree with you. What's the IVFM block and what does it do? IVFM is Input Voltage Flash Monitor. If the flash chip has IVFM function the flash current can be adjusted based upon the voltage level of input. As ramping flash current, the input voltage goes down and IVFM block adjust current to prevent to shudown due to low voltage and keep the flash operation. So if the input voltage crossed the IVFM Threshold level chip set the fault bit. Many flash chip, for example LM3556, LM3646, LM3642 , support this fucntion. I think, V4L2_FLASH_FAULT_INPUT_VOLTAGE_MONITOR is better than V4L2_FLASH_FAULT_IVFM. #define V4L2_CID_FLASH_CHARGE (V4L2_CID_FLASH_CLASS_BASE + 11) #define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12) -- 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 1/4] synch videodev2.h headers with kernel SDR API
Signed-off-by: Antti Palosaari --- contrib/freebsd/include/linux/videodev2.h | 16 include/linux/videodev2.h | 16 2 files changed, 32 insertions(+) diff --git a/contrib/freebsd/include/linux/videodev2.h b/contrib/freebsd/include/linux/videodev2.h index 5c75762..6d49f97 100644 --- a/contrib/freebsd/include/linux/videodev2.h +++ b/contrib/freebsd/include/linux/videodev2.h @@ -173,6 +173,7 @@ enum v4l2_buf_type { #endif V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9, V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10, + V4L2_BUF_TYPE_SDR_CAPTURE = 11, /* Deprecated, do not use */ V4L2_BUF_TYPE_PRIVATE = 0x80, }; @@ -193,6 +194,8 @@ enum v4l2_tuner_type { V4L2_TUNER_RADIO = 1, V4L2_TUNER_ANALOG_TV = 2, V4L2_TUNER_DIGITAL_TV= 3, + V4L2_TUNER_ADC = 4, + V4L2_TUNER_RF= 5, }; enum v4l2_memory { @@ -298,6 +301,8 @@ struct v4l2_capability { #define V4L2_CAP_RADIO 0x0004 /* is a radio device */ #define V4L2_CAP_MODULATOR 0x0008 /* has a modulator */ +#define V4L2_CAP_SDR_CAPTURE 0x0010 /* Is a SDR capture device */ + #define V4L2_CAP_READWRITE 0x0100 /* read/write systemcalls */ #define V4L2_CAP_ASYNCIO0x0200 /* async I/O */ #define V4L2_CAP_STREAMING 0x0400 /* streaming I/O ioctls */ @@ -1373,6 +1378,7 @@ struct v4l2_modulator { #define V4L2_TUNER_CAP_RDS_CONTROLS0x0200 #define V4L2_TUNER_CAP_FREQ_BANDS 0x0400 #define V4L2_TUNER_CAP_HWSEEK_PROG_LIM 0x0800 +#define V4L2_TUNER_CAP_1HZ 0x1000 /* Flags for the 'rxsubchans' field */ #define V4L2_TUNER_SUB_MONO0x0001 @@ -1726,6 +1732,15 @@ struct v4l2_pix_format_mplane { } __attribute__ ((packed)); /** + * struct v4l2_format_sdr - SDR format definition + * @pixelformat: little endian four character code (fourcc) + */ +struct v4l2_format_sdr { + uint32_tpixelformat; + uint8_t reserved[28]; +} __attribute__ ((packed)); + +/** * struct v4l2_format - stream data format * @type: enum v4l2_buf_type; type of the data stream * @pix: definition of an image format @@ -1743,6 +1758,7 @@ struct v4l2_format { struct v4l2_window win; /* V4L2_BUF_TYPE_VIDEO_OVERLAY */ struct v4l2_vbi_format vbi; /* V4L2_BUF_TYPE_VBI_CAPTURE */ struct v4l2_sliced_vbi_format sliced; /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */ + struct v4l2_format_sdr sdr; /* V4L2_BUF_TYPE_SDR_CAPTURE */ uint8_t raw_data[200]; /* user-defined */ } fmt; }; diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 6ae7bbe..27fedfe 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -139,6 +139,7 @@ enum v4l2_buf_type { #endif V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9, V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10, + V4L2_BUF_TYPE_SDR_CAPTURE = 11, /* Deprecated, do not use */ V4L2_BUF_TYPE_PRIVATE = 0x80, }; @@ -159,6 +160,8 @@ enum v4l2_tuner_type { V4L2_TUNER_RADIO = 1, V4L2_TUNER_ANALOG_TV = 2, V4L2_TUNER_DIGITAL_TV= 3, + V4L2_TUNER_ADC = 4, + V4L2_TUNER_RF= 5, }; enum v4l2_memory { @@ -264,6 +267,8 @@ struct v4l2_capability { #define V4L2_CAP_RADIO 0x0004 /* is a radio device */ #define V4L2_CAP_MODULATOR 0x0008 /* has a modulator */ +#define V4L2_CAP_SDR_CAPTURE 0x0010 /* Is a SDR capture device */ + #define V4L2_CAP_READWRITE 0x0100 /* read/write systemcalls */ #define V4L2_CAP_ASYNCIO0x0200 /* async I/O */ #define V4L2_CAP_STREAMING 0x0400 /* streaming I/O ioctls */ @@ -1339,6 +1344,7 @@ struct v4l2_modulator { #define V4L2_TUNER_CAP_RDS_CONTROLS0x0200 #define V4L2_TUNER_CAP_FREQ_BANDS 0x0400 #define V4L2_TUNER_CAP_HWSEEK_PROG_LIM 0x0800 +#define V4L2_TUNER_CAP_1HZ 0x1000 /* Flags for the 'rxsubchans' field */ #define V4L2_TUNER_SUB_MONO0x0001 @@ -1692,6 +1698,15 @@ struct v4l2_pix_format_mplane { } __attribute__ ((packed)); /** + * struct v4l2_format_sdr - SDR format definition + * @pixelformat: little endian four character code (fourcc) + */ +struct v4l2_format_sdr { + __u32 pixelformat; + __u8reserved[28]; +} __attribute__ ((packed)); + +/** * struct v4l2_format - stream data format * @type: enum v4l2_buf_type; type of the data stream * @pix: definition of an image format @@ -1709,6 +1724,7 @@
[PATCH 2/4] v4l2-ctl: add tuner support for SDR tuners
Add initial SDR support for tuner related operations. Signed-off-by: Antti Palosaari --- utils/v4l2-ctl/v4l2-ctl-tuner.cpp | 53 +++ 1 file changed, 43 insertions(+), 10 deletions(-) diff --git a/utils/v4l2-ctl/v4l2-ctl-tuner.cpp b/utils/v4l2-ctl/v4l2-ctl-tuner.cpp index 16e1652..0fc2371 100644 --- a/utils/v4l2-ctl/v4l2-ctl-tuner.cpp +++ b/utils/v4l2-ctl/v4l2-ctl-tuner.cpp @@ -116,6 +116,8 @@ static std::string tcap2s(unsigned cap) if (cap & V4L2_TUNER_CAP_LOW) s += "62.5 Hz "; + else if (cap & V4L2_TUNER_CAP_1HZ) + s += "1 Hz "; else s += "62.5 kHz "; if (cap & V4L2_TUNER_CAP_NORM) @@ -264,12 +266,24 @@ void tuner_set(int fd) if (capabilities & V4L2_CAP_MODULATOR) { type = V4L2_TUNER_RADIO; modulator.index = tuner_index; - if (doioctl(fd, VIDIOC_G_MODULATOR, &modulator) == 0) - fac = (modulator.capability & V4L2_TUNER_CAP_LOW) ? 16000 : 16; + if (doioctl(fd, VIDIOC_G_MODULATOR, &modulator) == 0) { + if (modulator.capability & V4L2_TUNER_CAP_LOW) + fac = 16000; + else if (modulator.capability & V4L2_TUNER_CAP_1HZ) + fac = 100; + else + fac = 16; + } } else if (capabilities & V4L2_CAP_TUNER) { tuner.index = tuner_index; if (doioctl(fd, VIDIOC_G_TUNER, &tuner) == 0) { - fac = (tuner.capability & V4L2_TUNER_CAP_LOW) ? 16000 : 16; + if (tuner.capability & V4L2_TUNER_CAP_LOW) + fac = 16000; + else if (tuner.capability & V4L2_TUNER_CAP_1HZ) + fac = 100; + else + fac = 16; + type = tuner.type; } } @@ -310,6 +324,9 @@ void tuner_set(int fd) if (band.capability & V4L2_TUNER_CAP_LOW) printf("\tFrequency Range: %.3f MHz - %.3f MHz\n", band.rangelow / 16000.0, band.rangehigh / 16000.0); + else if (band.capability & V4L2_TUNER_CAP_1HZ) + printf("\tFrequency Range: %.6f MHz - %.6f MHz\n", +band.rangelow / 100.0, band.rangehigh / 100.0); else printf("\tFrequency Range: %.3f MHz - %.3f MHz\n", band.rangelow / 16.0, band.rangehigh / 16.0); @@ -345,13 +362,24 @@ void tuner_get(int fd) if (capabilities & V4L2_CAP_MODULATOR) { vf.type = V4L2_TUNER_RADIO; modulator.index = tuner_index; - if (doioctl(fd, VIDIOC_G_MODULATOR, &modulator) == 0) - fac = (modulator.capability & V4L2_TUNER_CAP_LOW) ? 16000 : 16; + if (doioctl(fd, VIDIOC_G_MODULATOR, &modulator) == 0) { + if (modulator.capability & V4L2_TUNER_CAP_LOW) + fac = 16000; + else if (modulator.capability & V4L2_TUNER_CAP_1HZ) + fac = 100; + else + fac = 16; + } } else { vf.type = V4L2_TUNER_ANALOG_TV; tuner.index = tuner_index; if (doioctl(fd, VIDIOC_G_TUNER, &tuner) == 0) { - fac = (tuner.capability & V4L2_TUNER_CAP_LOW) ? 16000 : 16; + if (tuner.capability & V4L2_TUNER_CAP_LOW) + fac = 16000; + else if (tuner.capability & V4L2_TUNER_CAP_1HZ) + fac = 100; + else + fac = 16; vf.type = tuner.type; } } @@ -373,13 +401,18 @@ void tuner_get(int fd) if (vt.capability & V4L2_TUNER_CAP_LOW) printf("\tFrequency range : %.3f MHz - %.3f MHz\n", vt.rangelow / 16000.0, vt.rangehigh / 16000.0); + else if (vt.capability & V4L2_TUNER_CAP_1HZ) + printf("\tFrequency range : %.6f MHz - %.6f MHz\n", +vt.rangelow / 100.0, vt.rangehigh / 100.0); else printf("\tFr
[PATCH 4/4] v4l2-ctl: implement list SDR buffers command
Signed-off-by: Antti Palosaari --- utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 6 ++ utils/v4l2-ctl/v4l2-ctl.cpp | 1 + utils/v4l2-ctl/v4l2-ctl.h | 1 + 3 files changed, 8 insertions(+) diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp index 13ee8ec..925d73d 100644 --- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp +++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp @@ -78,6 +78,8 @@ void streaming_usage(void) " list all sliced VBI buffers [VIDIOC_QUERYBUF]\n" " --list-buffers-sliced-vbi-out\n" " list all sliced VBI output buffers [VIDIOC_QUERYBUF]\n" + " --list-buffers-sdr\n" + " list all SDR RX buffers [VIDIOC_QUERYBUF]\n" ); } @@ -986,4 +988,8 @@ void streaming_list(int fd) if (options[OptListBuffersSlicedVbiOut]) { list_buffers(fd, V4L2_BUF_TYPE_SLICED_VBI_OUTPUT); } + + if (options[OptListBuffersSdr]) { + list_buffers(fd, V4L2_BUF_TYPE_SDR_CAPTURE); + } } diff --git a/utils/v4l2-ctl/v4l2-ctl.cpp b/utils/v4l2-ctl/v4l2-ctl.cpp index 855613c..a602366 100644 --- a/utils/v4l2-ctl/v4l2-ctl.cpp +++ b/utils/v4l2-ctl/v4l2-ctl.cpp @@ -198,6 +198,7 @@ static struct option long_options[] = { {"list-buffers-sliced-vbi", no_argument, 0, OptListBuffersSlicedVbi}, {"list-buffers-vbi-out", no_argument, 0, OptListBuffersVbiOut}, {"list-buffers-sliced-vbi-out", no_argument, 0, OptListBuffersSlicedVbiOut}, + {"list-buffers-sdr", no_argument, 0, OptListBuffersSdr}, {"stream-count", required_argument, 0, OptStreamCount}, {"stream-skip", required_argument, 0, OptStreamSkip}, {"stream-loop", no_argument, 0, OptStreamLoop}, diff --git a/utils/v4l2-ctl/v4l2-ctl.h b/utils/v4l2-ctl/v4l2-ctl.h index 108198d..1caac34 100644 --- a/utils/v4l2-ctl/v4l2-ctl.h +++ b/utils/v4l2-ctl/v4l2-ctl.h @@ -139,6 +139,7 @@ enum Option { OptListBuffersSlicedVbi, OptListBuffersVbiOut, OptListBuffersSlicedVbiOut, + OptListBuffersSdr, OptStreamCount, OptStreamSkip, OptStreamLoop, -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] v4l2-ctl: add support for SDR FMT
Add support for FMT IOCTL operations used for SDR receivers. Signed-off-by: Antti Palosaari --- utils/v4l2-ctl/Makefile.am | 2 +- utils/v4l2-ctl/v4l2-ctl-common.cpp | 1 + utils/v4l2-ctl/v4l2-ctl-sdr.cpp| 104 + utils/v4l2-ctl/v4l2-ctl.cpp| 22 utils/v4l2-ctl/v4l2-ctl.h | 12 + 5 files changed, 140 insertions(+), 1 deletion(-) create mode 100644 utils/v4l2-ctl/v4l2-ctl-sdr.cpp diff --git a/utils/v4l2-ctl/Makefile.am b/utils/v4l2-ctl/Makefile.am index b5744e7..becaa15 100644 --- a/utils/v4l2-ctl/Makefile.am +++ b/utils/v4l2-ctl/Makefile.am @@ -8,5 +8,5 @@ ivtv_ctl_LDFLAGS = -lm v4l2_ctl_SOURCES = v4l2-ctl.cpp v4l2-ctl.h v4l2-ctl-common.cpp v4l2-ctl-tuner.cpp \ v4l2-ctl-io.cpp v4l2-ctl-stds.cpp v4l2-ctl-vidcap.cpp v4l2-ctl-vidout.cpp \ v4l2-ctl-overlay.cpp v4l2-ctl-vbi.cpp v4l2-ctl-selection.cpp v4l2-ctl-misc.cpp \ - v4l2-ctl-streaming.cpp v4l2-ctl-test-patterns.cpp + v4l2-ctl-streaming.cpp v4l2-ctl-test-patterns.cpp v4l2-ctl-sdr.cpp v4l2_ctl_LDADD = ../../lib/libv4l2/libv4l2.la ../../lib/libv4lconvert/libv4lconvert.la diff --git a/utils/v4l2-ctl/v4l2-ctl-common.cpp b/utils/v4l2-ctl/v4l2-ctl-common.cpp index fe570b0..37099cd 100644 --- a/utils/v4l2-ctl/v4l2-ctl-common.cpp +++ b/utils/v4l2-ctl/v4l2-ctl-common.cpp @@ -64,6 +64,7 @@ void common_usage(void) " --help-io input/output options\n" " --help-miscmiscellaneous options\n" " --help-overlay overlay format options\n" + " --help-sdr SDR format options\n" " --help-selection crop/selection options\n" " --help-stdsstandards and other video timings options\n" " --help-streaming streaming options\n" diff --git a/utils/v4l2-ctl/v4l2-ctl-sdr.cpp b/utils/v4l2-ctl/v4l2-ctl-sdr.cpp new file mode 100644 index 000..9c9a6c4 --- /dev/null +++ b/utils/v4l2-ctl/v4l2-ctl-sdr.cpp @@ -0,0 +1,104 @@ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "v4l2-ctl.h" + +static struct v4l2_format vfmt;/* set_format/get_format */ + +void sdr_usage(void) +{ + printf("\nSDR Formats options:\n" + " --list-formats-sdr display supported SDR formats [VIDIOC_ENUM_FMT]\n" + " --get-fmt-sdr query the SDR capture format [VIDIOC_G_FMT]\n" + " --set-fmt-sdr= set the SDR capture format [VIDIOC_S_FMT]\n" + " parameter is either the format index as reported by\n" + " --list-formats-sdr, or the fourcc value as a string\n" + " --try-fmt-sdr= try the SDR capture format [VIDIOC_TRY_FMT]\n" + " parameter is either the format index as reported by\n" + " --list-formats-sdr, or the fourcc value as a string\n" + ); +} + +void sdr_cmd(int ch, char *optarg) +{ + switch (ch) { + case OptSetSdrFormat: + case OptTrySdrFormat: + if (strlen(optarg) == 0) { + sdr_usage(); + exit(1); + } else if (strlen(optarg) == 4) { + vfmt.fmt.sdr.pixelformat = v4l2_fourcc(optarg[0], + optarg[1], optarg[2], optarg[3]); + } else { + vfmt.fmt.sdr.pixelformat = strtol(optarg, 0L, 0); + } + break; + } +} + +void sdr_set(int fd) +{ + int ret; + + if (options[OptSetSdrFormat] || options[OptTrySdrFormat]) { + struct v4l2_format in_vfmt; + + in_vfmt.type = V4L2_BUF_TYPE_SDR_CAPTURE; + in_vfmt.fmt.sdr.pixelformat = vfmt.fmt.sdr.pixelformat; + + if (in_vfmt.fmt.sdr.pixelformat < 256) { + struct v4l2_fmtdesc fmt; + + fmt.index = in_vfmt.fmt.sdr.pixelformat; + fmt.type = V4L2_BUF_TYPE_SDR_CAPTURE; + + if (doioctl(fd, VIDIOC_ENUM_FMT, &fmt)) + fmt.pixelformat = 0; + + in_vfmt.fmt.sdr.pixelformat = fmt.pixelformat; + } + + if (options[OptSetSdrFormat]) + ret = doioctl(fd, VIDIOC_S_FMT, &in_vfmt); + else + ret = doioctl(fd, VIDIOC_TRY_FMT, &in_vfmt); + if (ret == 0 && (verbose || options[OptTrySdrFormat])) + printfmt(in_vfmt); + } +} + +void sdr_get(int fd) +{ + if (options[OptGetSdrFormat]) { + vfmt.type = V4L2_BUF_TYPE_SDR_CAPTURE; + if (doioctl(fd, VIDIOC_G_FMT, &vfmt) == 0) +
I HAVE A PROPOSAL FOR YOU!
Hello, The Project is about the exportation of 100,000 barrels of Light Crude Oil daily out from Iraq to Turkey through my client's company in Iraq at the rate of $92.00 a barrel. This amount to $9,200,000 daily. I ask for your support as a foreigner to handle this business project with my client and you are not expected to invest in Iraq If yes, let me know and we will discuss this project proper. yung kim. yung@qq.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] e4000: convert DVB tuner to I2C driver model
Hi Antti, > My biggest point was to criticize that general resistance of new design > models which has been DVB side, not only that simple change but many others > too. I am pretty sure the many "mistakes" are taken when there has not been > better alternative available at the time, and later was developed proper > solution, which is not still taken into use. Sometimes the simplest looking changes can introduce all sorts of regressions. Just look at the mess that was caused by Mauro's supposedly trivial "dynamic stack allocation" fixes as a prime example. In principle I don't have any objection to adopting common frameworks. That said, the changes you've proposed do deviate from how the framework currently works, and it might have been more constructive to post an RFC to the mailing list describing your proposed changes to the framework rather than just submitting a patch for a single tuner. In this particular case, your approach does give us some advantages in being able to leverage the I2C framework, but it has costs as well. Specifically my concerns are as follows: 1. Removing the abstraction layer that dvb_attach() provided will make it more difficult to add resource tracking code to handle tuner locking/sharing. To solve those problems would actually require us to later *reintroduce* a layer of abstraction between the bridge and tuner drivers if this patch were accepted as-is. Case in point - in the V4L2 layer, they actually went in the opposite direction - adding the V4L2 subdev framework in order to provide additional abstraction between the bridge and I2C devices. 2. Your approach now makes it the responsibility of the caller to explicitly call request_module(), something that is taken care of today by dvb_attach(). Right now you can't forget to include the dependency since it's taken care of for you - with your change the implementor *can* forget, and the result will be that it will fail *sometimes* based on whether the module happens to already be loaded. In theory your approach would give us a bit more flexibility to have drivers with fewer module dependencies if people are compiling the kernel from scratch for a single tuner, but that's hardly the common use case and it significantly increases the risk of new bugs in failing to specify dependencies. 3. Your change gives no consideration to analog or hybrid tuners. This isn't surprising since you've never worked in that area, but if the model you are proposing is to be applied to all tuners, then we need to fully understand the effects on tuner-core.ko. > I have also feeling that these wrong solutions and design models used are > one source of problems we have. All the chip I/Os should be modeled in a > standard manner to make sure it is possible to interconnect flexible. GPIOs > should be implemented as kernel GPIOs. I2C should be implemented as kernel > I2C. Clock should be implemented as a kernel clock. Chip power-management > should be implement as regulator (or what ever that is). TS interface also > should be modeled and implement in a standard manner. Implementing things > like that makes it possible to interconnect complex hardware without fearing > some small change will break functionality because of some home-brew > solution. Sure. Modular design practices are a good thing. Thanks for stating the obvious. Did they also teach you about how refactoring can introduce bugs, especially in instances where there are no unit tests and you cannot exercise all the possible code paths? :-) I am confident that after the above factors are considered/addressed that some variant of this patch can certainly be incorporated upstream, and I look forward to seeing the continued improvement of the codebase while not introducing new regressions. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hm, seems I got me a "msg08693 (2009)" situation, smelly (hot) dvb-t electronics
Hello, I'm trying to get a :zolid dvb-t stick to work but at this stage I got the alarming smell, "tuning failed" and "tuning status == 0x04" (500 to 1000 Khz beside the wanted frequency the tuning status shows: == 0x06) Debug zl10353 and tuner-xc2028 (using a scan) shows me no info which I could use to tackle this problem (see below) For sure I could use info about gpio settings (in respect to the hardware) what they control, the desired value and correct sequence Tips and/or directions how to tackle this problem are welcome Greatings, Marcel Stork (netherlands) Hardware: xc3028L, wjce6353, tvp5150 and em2882 dmesg: [ 463.120045] usb 1-3: new high speed USB device using ehci_hcd and address 3 [ 463.257112] usb 1-3: New USB device found, idVendor=eb1a, idProduct=2883 [ 463.257123] usb 1-3: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 463.257132] usb 1-3: Product: USB 2883 Device [ 463.257139] usb 1-3: SerialNumber: 200804 [ 463.258956] usb 1-3: configuration #1 chosen from 1 choice [ 463.259217] em28xx: New device USB 2883 Device @ 480 Mbps (eb1a:2883, interface 0, class 0) [ 463.259357] em28xx #0: chip ID is em2882/em2883 [ 463.412859] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 83 28 d0 12 65 00 6a 22 8c 10 [ 463.412893] em28xx #0: i2c eeprom 10: 00 00 24 57 4e 37 01 00 60 00 00 00 02 00 00 00 [ 463.412923] em28xx #0: i2c eeprom 20: 5e 00 01 00 f0 10 01 00 b8 00 00 00 5b 1e 00 00 [ 463.412953] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 04 20 01 01 00 00 00 00 00 00 [ 463.412983] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 d3 c4 00 00 [ 463.413013] em28xx #0: i2c eeprom 50: 00 a2 b2 87 81 80 00 00 00 00 00 00 00 00 00 00 [ 463.413043] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 463.413073] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 33 00 20 00 44 00 [ 463.413102] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 10 03 32 00 [ 463.413132] em28xx #0: i2c eeprom 90: 30 00 30 00 38 00 30 00 34 00 00 00 00 00 00 00 [ 463.413162] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 463.413192] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 463.413221] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 463.413250] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 463.413280] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 463.413309] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 463.413344] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x85dd871e [ 463.413352] em28xx #0: EEPROM info: [ 463.413357] em28xx #0: AC97 audio (5 sample rates) [ 463.413364] em28xx #0: 500mA max power [ 463.413371] em28xx #0: Table at 0x24, strings=0x226a, 0x108c, 0x [ 463.414106] em28xx #0: Identified as :ZOLID Hybrid TV Stick (card=74) [ 463.419807] tvp5150 3-005c: chip found @ 0xb8 (em28xx #0) [ 463.425429] tuner 3-0061: chip found @ 0xc2 (em28xx #0) [ 463.425708] xc2028: Xcv2028/3028 init called! [ 463.425717] xc2028 3-0061: creating new instance [ 463.425725] xc2028 3-0061: type set to XCeive xc2028/xc3028 tuner [ 463.425736] xc2028 3-0061: xc2028_set_config called [ 463.425747] xc2028 3-0061: xc2028_set_analog_freq called [ 463.425757] xc2028 3-0061: generic_set_freq called [ 463.425765] xc2028 3-0061: should set frequency 567250 kHz [ 463.425773] xc2028 3-0061: check_firmware called [ 463.425781] xc2028 3-0061: load_all_firmwares called [ 463.425789] xc2028 3-0061: Reading firmware xc3028L-v36.fw [ 463.425799] usb 1-3: firmware: requesting xc3028L-v36.fw [ 463.433292] xc2028 3-0061: Loading 81 firmware images from xc3028L-v36.fw, type: xc2028 firmware, ver 3.6 [ 463.433319] xc2028 3-0061: Reading firmware type BASE F8MHZ (3), id 0, size=9144. [ 463.433357] xc2028 3-0061: Reading firmware type BASE F8MHZ MTS (7), id 0, size=9030. [ 463.433395] xc2028 3-0061: Reading firmware type BASE FM (401), id 0, size=9054. [ 463.433433] xc2028 3-0061: Reading firmware type BASE FM INPUT1 (c01), id 0, size=9068. [ 463.433463] xc2028 3-0061: Reading firmware type BASE (1), id 0, size=9132. [ 463.433498] xc2028 3-0061: Reading firmware type BASE MTS (5), id 0, size=9006. [ 463.433517] xc2028 3-0061: Reading firmware type (0), id 7, size=161. [ 463.433530] xc2028 3-0061: Reading firmware type MTS (4), id 7, size=169. [ 463.433544] xc2028 3-0061: Reading firmware type (0), id 7, size=161. [ 463.433556] xc2028 3-0061: Reading firmware type MTS (4), id 7, size=169. [ 463.433569] xc2028 3-0061: Reading firmware type (0), id 7, size=161. [ 463.433581] xc2028 3-0061: Reading firmware type MTS (4), id 7, size=169. [ 463.433594] xc2028 3-0061: Reading firmware type (0), id 7, size=161. [ 463.433606] xc2028 3-0061: Reading firmware type MTS (4), id 7, size=169. [ 463.433619] xc2028 3-0061: Reading firmware type (0), id e0, size=161. [
new bug report on bugzilla "3.12.8 warning during resume from s3"
https://bugzilla.kernel.org/show_bug.cgi?id=69581 -- 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] omap4iss: Fix overlapping luma/chroma planes & correct end pointers
The chroma data base address for NV12 formatted data should begin offset rows*bytes_per_row from the base address for luminance data. We were OBO causing a stripe of green pixels at the bottom of the frame. The OMAP TRM indicates RZX_X_PTR_E should contain the maximum number lines written to the CBUFF, not the total lines - 1 as used in VSZ registers. Signed-off-by: Nate Weibley --- drivers/staging/media/omap4iss/iss_resizer.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/media/omap4iss/iss_resizer.c b/drivers/staging/media/omap4iss/iss_resizer.c index ae831b8..ffb4f0e 100644 --- a/drivers/staging/media/omap4iss/iss_resizer.c +++ b/drivers/staging/media/omap4iss/iss_resizer.c @@ -159,7 +159,7 @@ static void resizer_set_outaddr(struct iss_resizer_device *resizer, u32 addr) if ((informat->code == V4L2_MBUS_FMT_UYVY8_1X16) && (outformat->code == V4L2_MBUS_FMT_YUYV8_1_5X8)) { u32 c_addr = addr + (resizer->video_out.bpl_value * -(outformat->height - 1)); +(outformat->height)); /* Ensure Y_BAD_L[6:0] = C_BAD_L[6:0]*/ if ((c_addr ^ addr) & 0x7f) { @@ -218,7 +218,7 @@ static void resizer_configure(struct iss_resizer_device *resizer) iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RSZ_SRC_VPS, 0); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RSZ_SRC_HPS, 0); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RSZ_SRC_VSZ, - informat->height - 2); + informat->height - 1); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RSZ_SRC_HSZ, informat->width - 1); @@ -226,7 +226,7 @@ static void resizer_configure(struct iss_resizer_device *resizer) iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_I_HPS, 0); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_O_VSZ, - outformat->height - 2); + outformat->height - 1); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_O_HSZ, outformat->width - 1); @@ -236,7 +236,7 @@ static void resizer_configure(struct iss_resizer_device *resizer) /* Buffer output settings */ iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_SDR_Y_PTR_S, 0); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_SDR_Y_PTR_E, - outformat->height - 1); + outformat->height); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_SDR_Y_OFT, resizer->video_out.bpl_value); @@ -251,7 +251,7 @@ static void resizer_configure(struct iss_resizer_device *resizer) iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_SDR_C_PTR_S, 0); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_SDR_C_PTR_E, - outformat->height - 1); + outformat->height); iss_reg_write(iss, OMAP4_ISS_MEM_ISP_RESIZER, RZA_SDR_C_OFT, resizer->video_out.bpl_value); -- 1.7.9.5 -- 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
Achtung! E-Mail-Suspension
Sehr geehrter Nutzer Ihre beiden eingehenden E-Mails wurden am ungeklarten Status aufgrund der jungsten Upgrade auf unserer Datenbank gespeichert, Um erhalten die Nachrichten bestatigen Konto. Um neu bestatigen Ihre Mailbox, auf diese E-Mail antworten sofort. Durch das Ausfullen der unten Daten; E-Mail: E-Mail-Benutzername: E-Mail Passwort: Passwort bestatigen: Warnung! Kontoinhaber, die zu seinem / ihrem Konto nach 48 Stunden nach Erhalt dieser Warnung Update verweigert wird seinem Konto dauerhaft verlieren. Help Desk -- 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: [RFCv3 PATCH 00/22] Add support for complex controls
Hello Hans Congratulations for the set, I think it is a step in the right direction. I have some questions. I hope I havent entered the discussion too late. 1) One problem that I am facing now is how to give userland a list of "dead pixels". Could we also add a v4l2_prop_type_matrix_pixel? I believe it could be useful for more people. Or do we have another standard way to do it now? 2) Assuming selection is a property. id will tell if we are setting CAPTURE_CROP, CAPTURE_COMPOSE, OUTPUT_CROP or OUTPUT_COMPOSE and type will tell if it is an array or a single element? something like: type=V4L2_PROP_TYPE_MATRIX | V4L2_PROP_TYPE_SELECTION ? type= V4L2_PROP_TYPE_SELECTION ; On the patchset there is nothing about selections. Or I am missing something? Thanks! On Mon, Jan 27, 2014 at 3:34 PM, Hans Verkuil wrote: > This patch series adds support for complex controls (aka 'Properties') to > the control framework. It is the first part of a larger patch series that > adds support for configuration stores, motion detection matrix controls and > support for 'Multiple Selections'. > > This patch series is based on this RFC: > > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/71822 > > A more complete patch series (including configuration store support and the > motion detection work) can be found here: > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/propapi-doc > > This patch series is a revision of RFCv2: > > http://www.spinics.net/lists/linux-media/msg71828.html > > Changes since RFCv2 are: > > - incorporated Sylwester's comments > - split up patch [20/21] into two: one for the codingstyle fixes in the > example > code, one for the actual DocBook additions. > - fixed a bug in patch 6 that broke the old-style VIDIOC_QUERYCTRL. Also made > the code in v4l2_query_ext_ctrl() that sets the mask/match variables more > readable. If I had to think about my own code, then what are the chances > others > will understand it? :-) > - dropped the support for setting/getting partial matrices. That's too > ambiguous > at the moment, and we can always add that later if necessary. > > The API changes required to support complex controls are minimal: > > - A new V4L2_CTRL_FLAG_HIDDEN has been added: any control with this flag (and > complex controls will always have this flag) will never be shown by control > panel GUIs. The only way to discover them is to pass the new > _FLAG_NEXT_HIDDEN > flag to QUERYCTRL. > > - A new VIDIOC_QUERY_EXT_CTRL ioctl has been added: needed to get the number > of elements > stored in the control (rows by columns) and the size in byte of each > element. > As a bonus feature a unit string has also been added as this has been > requested > in the past. In addition min/max/step/def values are now 64-bit. > > - A new 'p' field is added to struct v4l2_ext_control to set/get complex > values. > > - A helper flag V4L2_CTRL_FLAG_IS_PTR has been added to tell apps whether the > 'value' or 'value64' fields of the v4l2_ext_control struct can be used (bit > is cleared) or if the 'p' pointer can be used (bit it set). > > Once everyone agrees with this API extension I will make a next version of > this > patch series that adds the Motion Detection support for the solo6x10 and > go7007 > drivers that can now use the new matrix controls. That way actual drivers will > start using this (and it will allow me to move those drivers out of staging). > > Regards, > > Hans > > > -- > 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 -- Ricardo Ribalda -- 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]: s2255drv: checkpatch fix: coding style fix
Fixes all style warnings from scripts/checkpatch -f Signed-off-by: Dean Anderson --- drivers/media/usb/s2255/s2255drv.c | 328 1 file changed, 147 insertions(+), 181 deletions(-) diff --git a/drivers/media/usb/s2255/s2255drv.c b/drivers/media/usb/s2255/s2255drv.c index 6bc9b8e..c938b02 100644 --- a/drivers/media/usb/s2255/s2255drv.c +++ b/drivers/media/usb/s2255/s2255drv.c @@ -259,7 +259,7 @@ struct s2255_channel { struct s2255_dev { struct s2255_channelchannel[MAX_CHANNELS]; - struct v4l2_device v4l2_dev; + struct v4l2_device v4l2_dev; atomic_tnum_channels; int frames; struct mutexlock; /* channels[].vdev.lock */ @@ -352,7 +352,6 @@ struct s2255_fh { static unsigned long G_chnmap[MAX_CHANNELS] = {3, 2, 1, 0}; static int debug; -static int *s2255_debug = &debug; static int s2255_start_readpipe(struct s2255_dev *dev); static void s2255_stop_readpipe(struct s2255_dev *dev); @@ -373,13 +372,8 @@ static long s2255_vendor_req(struct s2255_dev *dev, unsigned char req, #define s2255_dev_err(dev, fmt, arg...) \ dev_err(dev, S2255_DRIVER_NAME " - " fmt, ##arg) -#define dprintk(level, fmt, arg...)\ - do {\ - if (*s2255_debug >= (level)) { \ - printk(KERN_DEBUG S2255_DRIVER_NAME \ - ": " fmt, ##arg); \ - } \ - } while (0) +#define dprintk(dev, level, fmt, arg...) \ + v4l2_dbg(level, debug, &dev->v4l2_dev, fmt, ## arg) static struct usb_driver s2255_driver; @@ -498,7 +492,7 @@ static void planar422p_to_yuv_packed(const unsigned char *in, static void s2255_reset_dsppower(struct s2255_dev *dev) { s2255_vendor_req(dev, 0x40, 0x, 0x0001, NULL, 0, 1); - msleep(10); + msleep(20); s2255_vendor_req(dev, 0x50, 0x, 0x, NULL, 0, 1); msleep(600); s2255_vendor_req(dev, 0x10, 0x, 0x, NULL, 0, 1); @@ -510,9 +504,8 @@ static void s2255_reset_dsppower(struct s2255_dev *dev) static void s2255_timer(unsigned long user_data) { struct s2255_fw *data = (struct s2255_fw *)user_data; - dprintk(100, "%s\n", __func__); if (usb_submit_urb(data->fw_urb, GFP_ATOMIC) < 0) { - printk(KERN_ERR "s2255: can't submit urb\n"); + pr_err("s2255: can't submit urb\n"); atomic_set(&data->fw_state, S2255_FW_FAILED); /* wake up anything waiting for the firmware */ wake_up(&data->wait_fw); @@ -532,7 +525,6 @@ static void s2255_fwchunk_complete(struct urb *urb) struct s2255_fw *data = urb->context; struct usb_device *udev = urb->dev; int len; - dprintk(100, "%s: udev %p urb %p", __func__, udev, urb); if (urb->status) { dev_err(&udev->dev, "URB failed with status %d\n", urb->status); atomic_set(&data->fw_state, S2255_FW_FAILED); @@ -559,9 +551,6 @@ static void s2255_fwchunk_complete(struct urb *urb) if (len < CHUNK_SIZE) memset(data->pfw_data, 0, CHUNK_SIZE); - dprintk(100, "completed len %d, loaded %d \n", len, - data->fw_loaded); - memcpy(data->pfw_data, (char *) data->fw->data + data->fw_loaded, len); @@ -576,10 +565,8 @@ static void s2255_fwchunk_complete(struct urb *urb) return; } data->fw_loaded += len; - } else { + } else atomic_set(&data->fw_state, S2255_FW_LOADED_DSPWAIT); - dprintk(100, "%s: firmware upload complete\n", __func__); - } return; } @@ -593,7 +580,7 @@ static int s2255_got_frame(struct s2255_channel *channel, int jpgsize) int rc = 0; spin_lock_irqsave(&dev->slock, flags); if (list_empty(&dma_q->active)) { - dprintk(1, "No active queue to serve\n"); + dprintk(dev, 1, "No active queue to serve\n"); rc = -1; goto unlock; } @@ -603,7 +590,7 @@ static int s2255_got_frame(struct s2255_channel *channel, int jpgsize) v4l2_get_timestamp(&buf->vb.ts); s2255_fillbuff(channel, buf, jpgsize); wake_up(&buf->vb.done); - dprintk(2, "%s: [buf/i] [%p/%d]\n", __func__, buf, buf->vb.i); + dprintk(dev, 2, "%s: [buf/i] [%p/%d]\n", __func__, buf, buf->vb.i); unlock: spin_unlock_irqrestore(&dev->slock, flags); return rc; @@ -615,9 +602,9 @@ static const struct s2255_fmt *format_by_fourcc(int fourcc) for (i = 0; i < ARRA
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 Jan 29 04:00:26 CET 2014 git branch: test git hash: 587d1b06e07b4a079453c74ba9edf17d21931049 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-6.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK apps: OK spec-git: OK sparse version: 0.4.5-rc1 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 Media Infrastructure API 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: [PATCH]: s2255drv: checkpatch fix: coding style fix
Hi Dean, A few small nitpicks below... On 01/29/2014 12:31 AM, d...@sensoray.com wrote: > Fixes all style warnings from scripts/checkpatch -f > > Signed-off-by: Dean Anderson > --- > drivers/media/usb/s2255/s2255drv.c | 328 > > 1 file changed, 147 insertions(+), 181 deletions(-) > > diff --git a/drivers/media/usb/s2255/s2255drv.c > b/drivers/media/usb/s2255/s2255drv.c > index 6bc9b8e..c938b02 100644 > --- a/drivers/media/usb/s2255/s2255drv.c > +++ b/drivers/media/usb/s2255/s2255drv.c > @@ -259,7 +259,7 @@ struct s2255_channel { > > struct s2255_dev { > struct s2255_channelchannel[MAX_CHANNELS]; > - struct v4l2_device v4l2_dev; > + struct v4l2_device v4l2_dev; > atomic_tnum_channels; > int frames; > struct mutexlock; /* channels[].vdev.lock */ > @@ -352,7 +352,6 @@ struct s2255_fh { > static unsigned long G_chnmap[MAX_CHANNELS] = {3, 2, 1, 0}; > > static int debug; > -static int *s2255_debug = &debug; > > static int s2255_start_readpipe(struct s2255_dev *dev); > static void s2255_stop_readpipe(struct s2255_dev *dev); > @@ -373,13 +372,8 @@ static long s2255_vendor_req(struct s2255_dev > *dev, unsigned char req, > #define s2255_dev_err(dev, fmt, arg...) > \ > dev_err(dev, S2255_DRIVER_NAME " - " fmt, ##arg) > > -#define dprintk(level, fmt, arg...) \ > - do {\ > - if (*s2255_debug >= (level)) { \ > - printk(KERN_DEBUG S2255_DRIVER_NAME \ > - ": " fmt, ##arg); \ > - } \ > - } while (0) > +#define dprintk(dev, level, fmt, arg...) \ > + v4l2_dbg(level, debug, &dev->v4l2_dev, fmt, ## arg) > > static struct usb_driver s2255_driver; > > @@ -498,7 +492,7 @@ static void planar422p_to_yuv_packed(const unsigned > char *in, > static void s2255_reset_dsppower(struct s2255_dev *dev) > { > s2255_vendor_req(dev, 0x40, 0x, 0x0001, NULL, 0, 1); > - msleep(10); > + msleep(20); > s2255_vendor_req(dev, 0x50, 0x, 0x, NULL, 0, 1); > msleep(600); > s2255_vendor_req(dev, 0x10, 0x, 0x, NULL, 0, 1); > @@ -510,9 +504,8 @@ static void s2255_reset_dsppower(struct s2255_dev > *dev) > static void s2255_timer(unsigned long user_data) > { > struct s2255_fw *data = (struct s2255_fw *)user_data; > - dprintk(100, "%s\n", __func__); > if (usb_submit_urb(data->fw_urb, GFP_ATOMIC) < 0) { > - printk(KERN_ERR "s2255: can't submit urb\n"); > + pr_err("s2255: can't submit urb\n"); > atomic_set(&data->fw_state, S2255_FW_FAILED); > /* wake up anything waiting for the firmware */ > wake_up(&data->wait_fw); > @@ -532,7 +525,6 @@ static void s2255_fwchunk_complete(struct urb *urb) > struct s2255_fw *data = urb->context; > struct usb_device *udev = urb->dev; > int len; > - dprintk(100, "%s: udev %p urb %p", __func__, udev, urb); > if (urb->status) { > dev_err(&udev->dev, "URB failed with status %d\n", urb->status); > atomic_set(&data->fw_state, S2255_FW_FAILED); > @@ -559,9 +551,6 @@ static void s2255_fwchunk_complete(struct urb *urb) > if (len < CHUNK_SIZE) > memset(data->pfw_data, 0, CHUNK_SIZE); > > - dprintk(100, "completed len %d, loaded %d \n", len, > - data->fw_loaded); > - > memcpy(data->pfw_data, > (char *) data->fw->data + data->fw_loaded, len); > > @@ -576,10 +565,8 @@ static void s2255_fwchunk_complete(struct urb > *urb) > return; > } > data->fw_loaded += len; > - } else { > + } else > atomic_set(&data->fw_state, S2255_FW_LOADED_DSPWAIT); > - dprintk(100, "%s: firmware upload complete\n", __func__); > - } > return; > > } > @@ -593,7 +580,7 @@ static int s2255_got_frame(struct s2255_channel > *channel, int jpgsize) > int rc = 0; > spin_lock_irqsave(&dev->slock, flags); > if (list_empty(&dma_q->active)) { > - dprintk(1, "No active queue to serve\n"); > + dprintk(dev, 1, "No active queue to serve\n"); > rc = -1; > goto unlock; > } > @@ -603,7 +590,7 @@ static int s2255_got_frame(struct s2255_channel > *channel, int jpgsize) > v4l2_get_timestamp(&buf->vb.ts); > s2255_fillbuff(channel, buf, jpgsize); > wake_up(&buf->vb.done); > - dprintk(2, "%s: [buf/i] [%p/%d]\n", __func__, buf, buf->vb.i); > + dprintk(dev, 2, "%s: [buf/i] [%p/%d]\n", __func__, buf, buf->
Re: [RFCv3 PATCH 00/22] Add support for complex controls
Hi Ricardo! On 01/28/2014 06:18 PM, Ricardo Ribalda Delgado wrote: > Hello Hans > > Congratulations for the set, I think it is a step in the right direction. Good to hear! > I have some questions. I hope I havent entered the discussion too late. > > 1) One problem that I am facing now is how to give userland a list of > "dead pixels". Could we also add a v4l2_prop_type_matrix_pixel? I > believe it could be useful for more people. Or do we have another > standard way to do it now? Sure this would be possible. Add a struct v4l2_point { __u32 x, y; } and you can make a V4L2_CID_DEADPIXELS array control. I'm assuming the dead pixels list is determined during the probe() function? If so, then the driver can just create a control with the size of the number of dead pixels. If it is more dynamic, then that is a bit of a problem since the size of the control is fixed at creation. > > > 2) Assuming selection is a property. id will tell if we are setting > CAPTURE_CROP, CAPTURE_COMPOSE, OUTPUT_CROP or OUTPUT_COMPOSE and type > will tell if it is an array or a single element? Are you talking userspace or kernelspace? In the kernel there is a is_matrix field in v4l2_ctrl that tells whether the control is a matrix or not. In userspace you need to check the rows/cols fields from the new VIDIOC_QUERY_EXT_CTRL ioctl. The type field refers to the type of each element. Originally I had a 'MATRIX' flag in the type, but that proved too cumbersome. > > something like: > type=V4L2_PROP_TYPE_MATRIX | V4L2_PROP_TYPE_SELECTION ? > type= V4L2_PROP_TYPE_SELECTION ; > > On the patchset there is nothing about selections. Or I am missing something? Not this one, once this is merged I plan on adding the selection support. The RFCv1 code has (primitive) selection support, for more up to date code see also this tree: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/propapi-doc Regards, Hans > > > > Thanks! > > On Mon, Jan 27, 2014 at 3:34 PM, Hans Verkuil wrote: >> This patch series adds support for complex controls (aka 'Properties') to >> the control framework. It is the first part of a larger patch series that >> adds support for configuration stores, motion detection matrix controls and >> support for 'Multiple Selections'. >> >> This patch series is based on this RFC: >> >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/71822 >> >> A more complete patch series (including configuration store support and the >> motion detection work) can be found here: >> >> http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/propapi-doc >> >> This patch series is a revision of RFCv2: >> >> http://www.spinics.net/lists/linux-media/msg71828.html >> >> Changes since RFCv2 are: >> >> - incorporated Sylwester's comments >> - split up patch [20/21] into two: one for the codingstyle fixes in the >> example >> code, one for the actual DocBook additions. >> - fixed a bug in patch 6 that broke the old-style VIDIOC_QUERYCTRL. Also made >> the code in v4l2_query_ext_ctrl() that sets the mask/match variables more >> readable. If I had to think about my own code, then what are the chances >> others >> will understand it? :-) >> - dropped the support for setting/getting partial matrices. That's too >> ambiguous >> at the moment, and we can always add that later if necessary. >> >> The API changes required to support complex controls are minimal: >> >> - A new V4L2_CTRL_FLAG_HIDDEN has been added: any control with this flag (and >> complex controls will always have this flag) will never be shown by control >> panel GUIs. The only way to discover them is to pass the new >> _FLAG_NEXT_HIDDEN >> flag to QUERYCTRL. >> >> - A new VIDIOC_QUERY_EXT_CTRL ioctl has been added: needed to get the number >> of elements >> stored in the control (rows by columns) and the size in byte of each >> element. >> As a bonus feature a unit string has also been added as this has been >> requested >> in the past. In addition min/max/step/def values are now 64-bit. >> >> - A new 'p' field is added to struct v4l2_ext_control to set/get complex >> values. >> >> - A helper flag V4L2_CTRL_FLAG_IS_PTR has been added to tell apps whether the >> 'value' or 'value64' fields of the v4l2_ext_control struct can be used (bit >> is cleared) or if the 'p' pointer can be used (bit it set). >> >> Once everyone agrees with this API extension I will make a next version of >> this >> patch series that adds the Motion Detection support for the solo6x10 and >> go7007 >> drivers that can now use the new matrix controls. That way actual drivers >> will >> start using this (and it will allow me to move those drivers out of staging). >> >> Regards, >> >> Hans >> >> >> -- >> 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 > > >