[PATCH v3 0/4] VPE improvements
This patchset adds following improvements for the ti-vpe driver. * Support SEQ_TB format for interlaced buffers Some of the video decoders generate interlaced content in SEQ_TB format Y top, T bottom in one plane and UV top, UV bottom in another * Improve multi instance latency Improve m2m job scheduling in multi instance use cases Start processing even if all buffers aren't present * N frame de-interlace support For N input fields, generate N progressive frames Archit Taneja (1): media: ti-vpe: Use line average de-interlacing for first 2 frames Nikhil Devshatwar (3): media: ti-vpe: Use data offset for getting dma_addr for a plane media: ti-vpe: Do not perform job transaction atomically media: ti-vpe: Add support for SEQ_TB buffers drivers/media/platform/ti-vpe/vpe.c | 191 --- 1 file changed, 154 insertions(+), 37 deletions(-) -- 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
[PATCH v3 2/4] media: ti-vpe: Use line average de-interlacing for first 2 frames
From: Archit Taneja arc...@ti.com
For n input fields, the VPE de-interlacer creates n - 2 progressive frames.
To support this, we use line average mode of de-interlacer for the first 2
input fields to generate 2 progressive frames. We then revert back to the
preferred EDI method, and create n - 2 frames, creating a sum of n frames.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index ba26b83..26e44a1 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -807,6 +807,23 @@ static void set_dei_shadow_registers(struct vpe_ctx *ctx)
ctx-load_mmrs = true;
}
+static void config_edi_input_mode(struct vpe_ctx *ctx, int mode)
+{
+ struct vpe_mmr_adb *mmr_adb = ctx-mmr_adb.addr;
+ u32 *edi_config_reg = mmr_adb-dei_regs[3];
+
+ if (mode 0x2)
+ write_field(edi_config_reg, 1, 1, 2); /* EDI_ENABLE_3D */
+
+ if (mode 0x3)
+ write_field(edi_config_reg, 1, 1, 3); /* EDI_CHROMA_3D */
+
+ write_field(edi_config_reg, mode, VPE_EDI_INP_MODE_MASK,
+ VPE_EDI_INP_MODE_SHIFT);
+
+ ctx-load_mmrs = true;
+}
+
/*
* Set the shadow registers whose values are modified when either the
* source or destination format is changed.
@@ -1119,6 +1136,15 @@ static void device_run(void *priv)
ctx-dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
WARN_ON(ctx-dst_vb == NULL);
+ if (ctx-deinterlacing) {
+ /*
+* we have output the first 2 frames through line average, we
+* now switch to EDI de-interlacer
+*/
+ if (ctx-sequence == 2)
+ config_edi_input_mode(ctx, 0x3); /* EDI (Y + UV) */
+ }
+
/* config descriptors */
if (ctx-dev-loaded_mmrs != ctx-mmr_adb.dma_addr || ctx-load_mmrs) {
vpdma_map_desc_buf(ctx-dev-vpdma, ctx-mmr_adb);
@@ -1780,6 +1806,9 @@ static int vpe_streamon(struct file *file, void *priv,
enum v4l2_buf_type type)
{
struct vpe_ctx *ctx = file2ctx(file);
+ if (ctx-deinterlacing)
+ config_edi_input_mode(ctx, 0x0);
+
return v4l2_m2m_streamon(file, ctx-m2m_ctx, type);
}
--
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
[PATCH v3 1/4] media: ti-vpe: Use data offset for getting dma_addr for a plane
The data_offset in v4l2_planes structure will help us point to the start of
data content for that particular plane. This may be useful when a single
buffer contains the data for different planes e.g. Y planes of two fields in
the same buffer. With this, user space can pass queue top field and
bottom field with same dmafd and different data_offsets.
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
---
Changes from v2:
* Use data_offset only for OUTPUT stream buffers
drivers/media/platform/ti-vpe/vpe.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 9a081c2..ba26b83 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -496,6 +496,14 @@ struct vpe_mmr_adb {
#define VPE_SET_MMR_ADB_HDR(ctx, hdr, regs, offset_a) \
VPDMA_SET_MMR_ADB_HDR(ctx-mmr_adb, vpe_mmr_adb, hdr, regs, offset_a)
+
+static inline dma_addr_t vb2_dma_addr_plus_data_offset(struct vb2_buffer *vb,
+ unsigned int plane_no)
+{
+ return vb2_dma_contig_plane_dma_addr(vb, plane_no) +
+ vb-v4l2_planes[plane_no].data_offset;
+}
+
/*
* Set the headers for all of the address/data block structures.
*/
@@ -1043,7 +1051,7 @@ static void add_in_dtd(struct vpe_ctx *ctx, int port)
vpdma_fmt = fmt-vpdma_fmt[plane];
- dma_addr = vb2_dma_contig_plane_dma_addr(vb, plane);
+ dma_addr = vb2_dma_addr_plus_data_offset(vb, plane);
if (!dma_addr) {
vpe_err(ctx-dev,
acquiring input buffer(%d) dma_addr failed\n,
--
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
[PATCH v3 3/4] media: ti-vpe: Do not perform job transaction atomically
Current VPE driver does not start the job untill all the buffers for
a transaction are not queued. When running in multiple context, this might
increase the processing latency.
Alternate solution would be to try to continue the same context as long as
buffers for the transaction are ready; else switch the conext. This may
increase number of context switches but it reduces latency significantly.
In this approach, the job_ready always succeeds as long as there are buffers
on the CAPTURE and OUTPUT stream. Processing may start immediately as the
first 2 iterations don't need extra source buffers. Shift all the source buffers
after each iteration and remove the oldest buffer.
Also, with this removes the constraint of pre buffering 3 buffers before call
to STREAMON in case of deinterlacing.
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 26e44a1..6a96bbf 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -907,15 +907,14 @@ static struct vpe_ctx *file2ctx(struct file *file)
static int job_ready(void *priv)
{
struct vpe_ctx *ctx = priv;
- int needed = ctx-bufs_per_job;
- if (ctx-deinterlacing ctx-src_vbs[2] == NULL)
- needed += 2;/* need additional two most recent fields */
-
- if (v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx) needed)
- return 0;
-
- if (v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx) needed)
+ /*
+* This check is needed as this might be called directly from driver
+* When called by m2m framework, this will always satisy, but when
+* called from vpe_irq, this might fail. (src stream with zero buffers)
+*/
+ if (v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx) = 0 ||
+ v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx) = 0)
return 0;
return 1;
@@ -1124,19 +1123,20 @@ static void device_run(void *priv)
struct sc_data *sc = ctx-dev-sc;
struct vpe_q_data *d_q_data = ctx-q_data[Q_DATA_DST];
- if (ctx-deinterlacing ctx-src_vbs[2] == NULL) {
- ctx-src_vbs[2] = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
- WARN_ON(ctx-src_vbs[2] == NULL);
- ctx-src_vbs[1] = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
- WARN_ON(ctx-src_vbs[1] == NULL);
- }
-
ctx-src_vbs[0] = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
WARN_ON(ctx-src_vbs[0] == NULL);
ctx-dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
WARN_ON(ctx-dst_vb == NULL);
if (ctx-deinterlacing) {
+
+ if (ctx-src_vbs[2] == NULL) {
+ ctx-src_vbs[2] = ctx-src_vbs[0];
+ WARN_ON(ctx-src_vbs[2] == NULL);
+ ctx-src_vbs[1] = ctx-src_vbs[0];
+ WARN_ON(ctx-src_vbs[1] == NULL);
+ }
+
/*
* we have output the first 2 frames through line average, we
* now switch to EDI de-interlacer
@@ -1360,7 +1360,7 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
}
ctx-bufs_completed++;
- if (ctx-bufs_completed ctx-bufs_per_job) {
+ if (ctx-bufs_completed ctx-bufs_per_job job_ready(ctx)) {
device_run(ctx);
goto handled;
}
--
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
[PATCH v3 4/4] media: ti-vpe: Add support for SEQ_TB buffers
The video source can generate the data in the SEQ_TB buffer format.
In the case of TI SoC, the IVA_HD can generate the interlaced content in
the SEQ_TB buffer format. This is the format where the top and bottom field
data can be contained in a single buffer. For example, for NV12, interlaced
format, the data in Y buffer will be arranged as Y-top followed by Y-bottom.
And likewise for UV plane.
Also, queueing one buffer of SEQ_TB is euivalent to queueing two different
buffers for top and bottom fields. Driver needs to take care of this when
handling source buffer lists.
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
---
Changes from v1:
* Add check for valid field in qbuf ioctl
* Fix issue with swapped fields
drivers/media/platform/ti-vpe/vpe.c | 124 ---
1 file changed, 102 insertions(+), 22 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 6a96bbf..b53aea5 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -319,9 +319,13 @@ struct vpe_q_data {
};
/* vpe_q_data flag bits */
-#defineQ_DATA_FRAME_1D (1 0)
-#defineQ_DATA_MODE_TILED (1 1)
-#defineQ_DATA_INTERLACED (1 2)
+#defineQ_DATA_FRAME_1D (1 0)
+#defineQ_DATA_MODE_TILED (1 1)
+#defineQ_DATA_INTERLACED_ALTERNATE (1 2)
+#defineQ_DATA_INTERLACED_SEQ_TB(1 3)
+
+#define Q_IS_INTERLACED(Q_DATA_INTERLACED_ALTERNATE | \
+ Q_DATA_INTERLACED_SEQ_TB)
enum {
Q_DATA_SRC = 0,
@@ -647,7 +651,7 @@ static void set_us_coefficients(struct vpe_ctx *ctx)
cp = us_coeffs[0].anchor_fid0_c0;
- if (s_q_data-flags Q_DATA_INTERLACED)/* interlaced */
+ if (s_q_data-flags Q_IS_INTERLACED) /* interlaced */
cp += sizeof(us_coeffs[0]) / sizeof(*cp);
end_cp = cp + sizeof(us_coeffs[0]) / sizeof(*cp);
@@ -774,8 +778,7 @@ static void set_dei_regs(struct vpe_ctx *ctx)
* for both progressive and interlace content in interlace bypass mode.
* It has been recommended not to use progressive bypass mode.
*/
- if ((!ctx-deinterlacing (s_q_data-flags Q_DATA_INTERLACED)) ||
- !(s_q_data-flags Q_DATA_INTERLACED)) {
+ if (!(s_q_data-flags Q_IS_INTERLACED) || !ctx-deinterlacing) {
deinterlace = false;
val = VPE_DEI_INTERLACE_BYPASS;
}
@@ -843,8 +846,8 @@ static int set_srcdst_params(struct vpe_ctx *ctx)
ctx-sequence = 0;
ctx-field = V4L2_FIELD_TOP;
- if ((s_q_data-flags Q_DATA_INTERLACED)
- !(d_q_data-flags Q_DATA_INTERLACED)) {
+ if ((s_q_data-flags Q_IS_INTERLACED)
+ !(d_q_data-flags Q_IS_INTERLACED)) {
int bytes_per_line;
const struct vpdma_data_format *mv =
vpdma_misc_fmts[VPDMA_DATA_FMT_MV];
@@ -1068,6 +1071,27 @@ static void add_in_dtd(struct vpe_ctx *ctx, int port)
vpdma_fmt = fmt-vpdma_fmt[plane];
dma_addr = vb2_dma_addr_plus_data_offset(vb, plane);
+
+ if (q_data-flags Q_DATA_INTERLACED_SEQ_TB) {
+ /*
+* Use top or bottom field from same vb alternately
+* f,f-1,f-2 = TBT when seq is even
+* f,f-1,f-2 = BTB when seq is odd
+*/
+ field = (p_data-vb_index + (ctx-sequence % 2)) % 2;
+
+ if (field) {
+ /* bottom field of a SEQ_TB buffer
+* Skip the top field data by */
+ int height = q_data-height / 2;
+ int bpp = fmt-fourcc == V4L2_PIX_FMT_NV12 ?
+ 1 : (vpdma_fmt-depth 3);
+ if (plane)
+ height /= 2;
+ dma_addr += q_data-width * height * bpp;
+ }
+ }
+
if (!dma_addr) {
vpe_err(ctx-dev,
acquiring input buffer(%d) dma_addr failed\n,
@@ -1122,9 +1146,22 @@ static void device_run(void *priv)
struct vpe_ctx *ctx = priv;
struct sc_data *sc = ctx-dev-sc;
struct vpe_q_data *d_q_data = ctx-q_data[Q_DATA_DST];
+ struct vpe_q_data *s_q_data = ctx-q_data[Q_DATA_SRC];
+
+ if (ctx-deinterlacing s_q_data-flags Q_DATA_INTERLACED_SEQ_TB
+ ctx-sequence % 2 == 0) {
+ /* When using SEQ_TB buffers, When using it first time,
+* No need to remove the buffer as the next field is present
+* in the same buffer. (so that
[RFC] pms/bw-qcam/c-qcam/w9966: deprecate and remove
I propose that these four drivers are deprecated and moved to staging and that 1-2 kernel cycles later these drivers are removed. bw-qcam, c-qcam and w9966 are all parallel port webcams. The w9966 driver hasn't been tested in a very long time since nobody has hardware. I do have hardware for bw-qcam and c-qcam although the c-qcam never gave me a good picture. I don't know whether that's due to hardware problems or driver problems. The bw-qcam works for the most part but it can do weird things occasionally, especially if you fiddle around too much with the camera controls. All three webcam drivers are useless in practice since the quality and framerate is so poor. And vastly better cheap alternatives are available today. These drivers do use the latest frameworks, so from the point-of-view of kernel APIs they are OK. But it is extremely unlikely that anyone is still using such webcams and with easy availability of alternatives I think it is time to retire them. The pms driver is a video capture ISA card. I do have hardware, although the last time I tested it streaming didn't work anymore for no clear reason. While the code is OK it has the same issue as the parallel webcams: poor quality and frame rate, nobody uses it anymore and cheap and much better alternatives exist today. I believe it is time to retire these four drivers. 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
[RFC] tlg2300: deprecate and remove
I propose that this driver is deprecated and moved to staging and that 1-2 kernel cycles later this driver is removed. The reason for this is that hardware for this driver is impossible to find anymore. I had one USB stick but it broke and I have been unable to find another. The company behind the chip is gone for many years and cheap alternatives are easily available. This driver is still using vb1 and ioctl instead of unlocked_ioctl, and without hardware this will be difficult if not impossible to fix. I am not aware of any active users of this driver. In my view it is time to retire this driver. The lack of hardware and users and the fact that it uses deprecated APIs makes it a good candidate to removal. 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
Re: ISDB caption support
Em Fri, 28 Nov 2014 22:23:13 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: I realize captions is an application-layer function, and intend to work with the CCExtractor team. Do any other applications already have ISDB caption support? I never actually checked how CC works on ISDB-T. On the MPEG-TS tables I worked so far, ISDB-T is very close to DVB, so I would expect that CC would also be close to the DVB descriptors for it, but, as I said, I never actually read that part of the ARIB/ABNT specs. Based on a Google search, it looks like dvbviewer can decode them: http://www.dvbviewer.tv/forum/topic/41933-brazilian-terrestrial-isdb-tb-subtitles-closed-caption/ http://www.dvbviewer.com/en/index.php It's not open source, and it's not Linux, but at least it may give you something to compare against if you want to build the functionality yourself. For DVB and ATSC there's quite a bit of code written by several people for teletext and captions -- has anything at all been done for ISDB captions? Not to my knowledge. I've done a ton of work with CC decoding in VLC, but haven't poked around at the other formats. It's used in nearly all of Central and South America, plus the Philippines and of course Japan -- you would have thought someone has started on the task? From what I understand, most terrestrial TV in Japan is encrypted, so you're likely to not find many open source solutions which targeted at that market. Presumably there is less of that in Brazil (why else would Mauro be doing all that ISDB-T work if there was no way to watch the actual video?). We're looking for a good solution for capturing television in Brazil, when the signal is encrypted -- are there set-top boxes or tv capture cards that handle the decryption so that the decoded signal is passed on with the ISDB-Tb caption stream intact? I'm not aware of any device that handles encryption in Brazil. Cryptography is used only in Japan standard, as far as I know. All channels here are in clear, at least for video/audio streams, but, as I said, I never tried to work with CC for ISDB-T. Yet, I would find really weird if just CC is encrypted. This would be very unusual. Satellite captioning often has the same issues - the decoders only support overlaying the captions over the video and provide no means to access the underlying data. Devin -- 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/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
Hi! +Flash LED handling under Linux +== + +Some LED devices support two modes - torch and flash. The modes are +supported by the LED class (see Documentation/leds/leds-class.txt) +and LED Flash class respectively. + +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol +must be defined in the kernel config. A flash LED driver must register +in the LED subsystem with led_classdev_flash_register to gain flash +capabilities. + +Following sysfs attributes are exposed for controlling flash led devices: + + - flash_brightness - flash LED brightness in microamperes (RW) + - max_flash_brightness - maximum available flash LED brightness (RO) + - indicator_brightness - privacy LED brightness in microamperes (RW) + - max_indicator_brightness - maximum privacy LED brightness in + microamperes (RO) + - flash_timeout - flash strobe duration in microseconds (RW) + - max_flash_timeout - maximum available flash strobe duration (RO) + - flash_strobe - flash strobe state (RW) + - flash_sync_strobe - one flash device can control more than one + sub-led; when this atrribute is set to 1 + the flash led will be strobed synchronously + with the other ones controlled by the same + device (RW) This is not really clear. Does flash_timeout or flash_brightness need to be set, first? Do we really want to have separate indicator brightnesses in uA? Should we maybe reuse existing brightness parameter for torch and indication, maybe adding single (RO) indicator_brightness attribute? + - flash_fault - bitmask of flash faults that may have occurred, + possible flags are: + * 0x01 - flash controller voltage to the flash LED has exceeded + the limit specific to the flash controller + * 0x02 - the flash strobe was still on when the timeout set by + the user has expired; not all flash controllers may + set this in all such conditions + * 0x04 - the flash controller has overheated + * 0x08 - the short circuit protection of the flash controller + has been triggered + * 0x10 - current in the LED power supply has exceeded the limit + specific to the flash controller + * 0x40 - flash controller voltage to the flash LED has been + below the minimum limit specific to the flash + * 0x80 - the input voltage of the flash controller is below + the limit under which strobing the flash at full + current will not be possible. The condition persists + until this flag is no longer set + * 0x100 - the temperature of the LED has exceeded its allowed + upper limit How are faults cleared? Should it be list of strings, instead of bitmask? We may want to add new fault modes in future... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/RFC v8 04/14] v4l2-async: change custom.match callback argument type
On Fri 2014-11-28 10:17:56, Jacek Anaszewski wrote: It is useful to have an access to the async sub-device being matched, not only to the related struct device. Change match callback argument from struct device to struct v4l2_subdev. It will allow e.g. for matching a sub-device by its name property. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Hans Verkuil hans.verk...@cisco.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/RFC v8 07/14] exynos4-is: Add support for v4l2-flash subdevs
On Fri 2014-11-28 10:17:59, Jacek Anaszewski wrote: This patch adds suppport for external v4l2-flash devices. The support includes parsing flashes Device Tree property and asynchronous subdevice registration. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: ISDB caption support
I realize captions is an application-layer function, and intend to work with the CCExtractor team. Do any other applications already have ISDB caption support? there's a mplayer patch for subtitle support: https://github.com/0p1pp1/mplayer/commit/6debc831d34cad98d1b251920fbdb48f74a880df It translates subtitle stream PES to ASS, but is is for ISDB-T/Japan. Subtitling in ISDB-T depends heavily on the control sequences of the original character encoding (ARIB STD-B24), so I'm afraid that (at least) PES format is very different in ISDB-Tb. regards, akihiro -- 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/RFC v8 04/14] v4l2-async: change custom.match callback argument type
Hi Jacek,
Thank you for the patch.
On Friday 28 November 2014 10:17:56 Jacek Anaszewski wrote:
It is useful to have an access to the async sub-device
being matched, not only to the related struct device.
Change match callback argument from struct device
to struct v4l2_subdev. It will allow e.g. for matching
a sub-device by its name property.
In principle I agree. However, we will need to reimplement v4l2-async based on
the component (drivers/base/component.c) framework at some point. As the
component framework is based on struct device, will it still be possible to
match on subdev name in that case ? If not, we might need to try to find
another approach to the issue.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-async.c | 16
include/media/v4l2-async.h |2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c index 85a6a34..8140992 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -22,10 +22,10 @@
#include media/v4l2-device.h
#include media/v4l2-subdev.h
-static bool match_i2c(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev
*asd) {
#if IS_ENABLED(CONFIG_I2C)
- struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_client *client = i2c_verify_client(sd-dev);
return client
asd-match.i2c.adapter_id == client-adapter-nr
asd-match.i2c.address == client-addr;
@@ -34,14 +34,14 @@ static bool match_i2c(struct device *dev, struct
v4l2_async_subdev *asd) #endif
}
-static bool match_devname(struct device *dev, struct v4l2_async_subdev
*asd) +static bool match_devname(struct v4l2_subdev *sd, struct
v4l2_async_subdev *asd) {
- return !strcmp(asd-match.device_name.name, dev_name(dev));
+ return !strcmp(asd-match.device_name.name, dev_name(sd-dev));
}
-static bool match_of(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- return dev-of_node == asd-match.of.node;
+ return sd-dev-of_node == asd-match.of.node;
}
static LIST_HEAD(subdev_list);
@@ -52,7 +52,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier * struct v4l2_subdev *sd)
{
struct v4l2_async_subdev *asd;
- bool (*match)(struct device *, struct v4l2_async_subdev *);
+ bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
list_for_each_entry(asd, notifier-waiting, list) {
/* bus_type has been verified valid before */
@@ -79,7 +79,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier * }
/* match cannot be NULL here */
- if (match(sd-dev, asd))
+ if (match(sd, asd))
return asd;
}
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index 7683569..1c0b586 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -51,7 +51,7 @@ struct v4l2_async_subdev {
unsigned short address;
} i2c;
struct {
- bool (*match)(struct device *,
+ bool (*match)(struct v4l2_subdev *,
struct v4l2_async_subdev *);
void *priv;
} custom;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: usb: uvc: use vb2_ops_wait_prepare/finish helper
Hi Prabhakar, On Friday 28 November 2014 17:06:52 Prabhakar Lad wrote: On Thu, Nov 27, 2014 at 9:32 PM, Laurent Pinchart wrote: Hi Prabhakar, [Snip] + queue-queue.lock = queue-mutex; I'm a bit concerned that this would introduce future breakages. Setting the queue.lock pointer enables locking in all vb2_fop_* and vb2_ops_wait_* functions. The uvcvideo driver isn't ready for that, but doesn't use the vb2_fop_* functions yet, so that's not an issue. However, in the future, videobuf2 might use the lock in more places, including functions used by the uvcvideo driver. This could then cause breakages. Even if in future if videobuf2 uses this lock it would be in helpers mostly, so any way it doesn’t harm :) My concern is about vb2 starting using the lock in existing helpers used by the uvcvideo driver. I suppose we can deal with it later. It would be better to completely convert the uvcvideo driver to the vb2_fop_* functions if we want to use vb2_ops_*. I'm not sure how complex that would be though, and whether it would be possible while still keeping the fine-grained locking implemented by the uvcvideo driver. Do you think it should be attempted ? mmap poll should be fairly simple, looks like open release cannot be dropped as it does some usb_autopm_get/put_interface() calls which I am not aware of. I've looked at that, and there's a race condition in vb2_fop_poll() (for which I've already sent a patch) and possible in vb2_mmap() (raised the issue on #v4l today) as well that need to be fixed first. Anyway, for this patch Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Have you tested it by the way ? Should I take it in my tree or will you send a pull request for the whole series ? ret = vb2_queue_init(queue-queue); if (ret) return ret; -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: usb: uvc: use vb2_ops_wait_prepare/finish helper
Hi Laurent, On Sat, Nov 29, 2014 at 6:11 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Prabhakar, On Friday 28 November 2014 17:06:52 Prabhakar Lad wrote: On Thu, Nov 27, 2014 at 9:32 PM, Laurent Pinchart wrote: Hi Prabhakar, [Snip] + queue-queue.lock = queue-mutex; I'm a bit concerned that this would introduce future breakages. Setting the queue.lock pointer enables locking in all vb2_fop_* and vb2_ops_wait_* functions. The uvcvideo driver isn't ready for that, but doesn't use the vb2_fop_* functions yet, so that's not an issue. However, in the future, videobuf2 might use the lock in more places, including functions used by the uvcvideo driver. This could then cause breakages. Even if in future if videobuf2 uses this lock it would be in helpers mostly, so any way it doesn’t harm :) My concern is about vb2 starting using the lock in existing helpers used by the uvcvideo driver. I suppose we can deal with it later. It would be better to completely convert the uvcvideo driver to the vb2_fop_* functions if we want to use vb2_ops_*. I'm not sure how complex that would be though, and whether it would be possible while still keeping the fine-grained locking implemented by the uvcvideo driver. Do you think it should be attempted ? mmap poll should be fairly simple, looks like open release cannot be dropped as it does some usb_autopm_get/put_interface() calls which I am not aware of. I've looked at that, and there's a race condition in vb2_fop_poll() (for which I've already sent a patch) and possible in vb2_mmap() (raised the issue on #v4l today) as well that need to be fixed first. Anyway, for this patch Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Have you tested it by the way ? I have just compile tested it. Should I take it in my tree or will you send a pull request for the whole series ? Probably you can pick this up via your tree. Thanks, --Prabhakar Lad ret = vb2_queue_init(queue-queue); if (ret) return ret; -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()
Hi Laurent,
On Tue, Nov 18, 2014 at 6:07 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Hans and Prabhakar,
On Tue, Nov 18, 2014 at 10:39:24AM +0100, Hans Verkuil wrote:
On 11/17/14 11:41, Lad, Prabhakar wrote:
this patch removes the guard CONFIG_VIDEO_V4L2_SUBDEV_API
for v4l2_subdev_get_try_*() functions.
In cases where a subdev using v4l2_subdev_get_try_*() calls
internally and the bridge using subdev pad ops which is
not MC aware forces to select MEDIA_CONTROLLER, as
VIDEO_V4L2_SUBDEV_API is dependent on it.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
include/media/v4l2-subdev.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5860292..076ca11 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -642,7 +642,6 @@ struct v4l2_subdev_fh {
#define to_v4l2_subdev_fh(fh) \
container_of(fh, struct v4l2_subdev_fh, vfh)
-#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
#define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name)
\
static inline struct rtype *\
v4l2_subdev_get_try_##fun_name(struct v4l2_subdev_fh *fh, \
@@ -656,7 +655,6 @@ struct v4l2_subdev_fh {
__V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, format, try_fmt)
__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, crop, try_crop)
__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, compose, try_compose)
-#endif
extern const struct v4l2_file_operations v4l2_subdev_fops;
The problem is that v4l2_subdev_get_try_*() needs a v4l2_subdev_fh which
you don't have if CONFIG_VIDEO_V4L2_SUBDEV_API is not defined. So I don't
see how removing the guards help with that.
What can be done is that if CONFIG_VIDEO_V4L2_SUBDEV_API is not defined,
then these functions return NULL.
Sure. That's a better choice than removing the config option dependency of
the fields struct v4l2_subdev.
BTW, one patch I will very happily accept is one where the
__V4L2_SUBDEV_MK_GET_TRY
is removed and these three try functions are just written as proper
static inlines. I find it very obfuscated code.
I originally wrote them like that in order to avoid writing essentially the
same code three times over. If there will be more targets, the same repeats
further, should one write those functions open for all different macro
arguments. That's why it was a macro to begin with.
In addition, because it is a macro you won't find the function definitions
if you grep on the function name.
True as well. You could simply change the macro to include the full function
name. This was not suggested in review back then AFAIR.
But any functional changes here need to be Acked by Laurent first.
How do you want me to proceed on this ?
Thanks,
--Prabhakar Lad
--
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/RFC v8 12/14] leds: Add driver for AAT1290 current regulator
Hi!
@@ -0,0 +1,472 @@
+/*
+ * LED Flash class driver for the AAT1290
+ * 1.5A Step-Up Current Regulator for Flash LEDs
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski j.anaszew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#define AAT1290_MM_TO_FL_1_921
+#define AAT1290_MM_TO_FL_3_7 2
+#define AAT1290_MM_TO_FL_5_5 3
+#define AAT1290_MM_TO_FL_7_3 4
+#define AAT1290_MM_TO_FL_9 5
+#define AAT1290_MM_TO_FL_10_76
+#define AAT1290_MM_TO_FL_12_47
+#define AAT1290_MM_TO_FL_14 8
+#define AAT1290_MM_TO_FL_15_99
+#define AAT1290_MM_TO_FL_17_510
+#define AAT1290_MM_TO_FL_19_111
+#define AAT1290_MM_TO_FL_20_812
+#define AAT1290_MM_TO_FL_22_413
+#define AAT1290_MM_TO_FL_24 14
+#define AAT1290_MM_TO_FL_25_615
+#define AAT1290_MM_TO_FL_OFF 16
Only one of these defines is unused.
+static struct of_device_id aat1290_led_dt_match[] = {
+ {.compatible = skyworks,aat1290},
spaces after { and before } ?
Otherwise looks ok,
Signed-off-by: Pavel Machek pa...@ucw.cz
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()
Hi Prabhakar,
On Saturday 29 November 2014 18:30:09 Prabhakar Lad wrote:
On Tue, Nov 18, 2014 at 6:07 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
On Tue, Nov 18, 2014 at 10:39:24AM +0100, Hans Verkuil wrote:
On 11/17/14 11:41, Lad, Prabhakar wrote:
this patch removes the guard CONFIG_VIDEO_V4L2_SUBDEV_API
for v4l2_subdev_get_try_*() functions.
In cases where a subdev using v4l2_subdev_get_try_*() calls
internally and the bridge using subdev pad ops which is
not MC aware forces to select MEDIA_CONTROLLER, as
VIDEO_V4L2_SUBDEV_API is dependent on it.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
include/media/v4l2-subdev.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5860292..076ca11 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -642,7 +642,6 @@ struct v4l2_subdev_fh {
#define to_v4l2_subdev_fh(fh) \
container_of(fh, struct v4l2_subdev_fh, vfh)
-#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
#define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name)
\
static inline struct rtype *\
v4l2_subdev_get_try_##fun_name(struct v4l2_subdev_fh *fh, \
@@ -656,7 +655,6 @@ struct v4l2_subdev_fh {
__V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, format, try_fmt)
__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, crop, try_crop)
__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, compose, try_compose)
-#endif
extern const struct v4l2_file_operations v4l2_subdev_fops;
The problem is that v4l2_subdev_get_try_*() needs a v4l2_subdev_fh which
you don't have if CONFIG_VIDEO_V4L2_SUBDEV_API is not defined. So I don't
see how removing the guards help with that.
What can be done is that if CONFIG_VIDEO_V4L2_SUBDEV_API is not defined,
then these functions return NULL.
Sure. That's a better choice than removing the config option dependency of
the fields struct v4l2_subdev.
Decoupling CONFIG_VIDEO_V4L2_SUBDEV_API from the availability of the in-kernel
pad format and selection rectangles helpers is definitely a good idea. I was
thinking about decoupling the try format and rectangles from v4l2_subdev_fh by
creating a kind of configuration store structure to store them, and embedding
that structure in v4l2_subdev_fh. The pad-level operations would then take a
pointer to the configuration store instead of the v4l2_subdev_fh. Bridge
drivers that want to implement TRY_FMT based on pad-level operations would
create a configuration store, use the pad-level operations, and destroy the
configuration store. The userspace subdev API would use the configuration
store from the file handle.
BTW, one patch I will very happily accept is one where the
__V4L2_SUBDEV_MK_GET_TRY is removed and these three try functions are
just written as proper static inlines. I find it very obfuscated code.
I originally wrote them like that in order to avoid writing essentially
the same code three times over. If there will be more targets, the same
repeats further, should one write those functions open for all different
macro arguments. That's why it was a macro to begin with.
In addition, because it is a macro you won't find the function
definitions if you grep on the function name.
True as well. You could simply change the macro to include the full
function name. This was not suggested in review back then AFAIR.
But any functional changes here need to be Acked by Laurent first.
How do you want me to proceed on this ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693
Hi! diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 01e9f30..50a8dad 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -41,6 +41,62 @@ Optional properties: To get more informations, please refer to documentaion. [*] refer Documentation/devicetree/bindings/pwm/pwm.txt +- led-flash : the LED submodule device node + +There are two led outputs available - fled1 and fled2. Each of them can +control a separate led or they can be connected together to double +the maximum current for a single connected led. One led is represented +by one child node. + +Required properties: +- compatible : must be maxim,max77693-flash + +Optional properties: +- maxim,fleds : array of current outputs in order: fled1, fled2 + Note: both current outputs can be connected to a single led + Possible values: + 0 - the output is left disconnected, + 1 - a diode is connected to the output. Is this one needed? Just ommit child note if it is not there. +- maxim,trigger-type : Array of trigger types in order: flash, torch + Possible trigger types: + 0 - Rising edge of the signal triggers the flash/torch, + 1 - Signal level controls duration of the flash/torch. +- maxim,trigger : Array of flags indicating which trigger can activate given led + in order: fled1, fled2 + Possible flag values (can be combined): + 1 - FLASH pin of the chip, + 2 - TORCH pin of the chip, + 4 - software via I2C command. Is it good idea to have bitfields like this? Make these required properties of the subnode? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: ISDB caption support
HI David, Em Sat, 29 Nov 2014 08:17:30 -0800 David Liontooth lionte...@cogweb.net escreveu: Hi Mauro, Thank you; that's extremely helpful. We are looking into how much work it will be to write an ISDB-Tb captioning decoder for CCExtractor. Can we find a list of television capture hardware devices known to work in Brazil? Our friends in Rio are new to all this, and linux/Documentation/dvb# grep -i ISDB * finds nothing. I'm aware of Linux TV's list of ISDB resources, but they don't specify ISDB subtype (ISDB-Tb) -- are they interchangeable? Yes, the demod here is the same as the ones used in Japan. The only difference is that the devices sold in Japan has the additional crypto modules. There are drivers that supports ISDB-T: $ git grep -l SYS_ISDBT|grep -v tuners Documentation/DocBook/media/dvb/dvbproperty.xml drivers/media/common/siano/smsdvb-main.c drivers/media/dvb-core/dvb_frontend.c drivers/media/dvb-frontends/dib0070.c drivers/media/dvb-frontends/dib0090.c drivers/media/dvb-frontends/dib8000.c drivers/media/dvb-frontends/mb86a20s.c drivers/media/dvb-frontends/s921.c drivers/media/dvb-frontends/tc90522.c drivers/media/pci/pt1/va1j5jf8007t.c drivers/media/pci/pt3/pt3.c drivers/media/usb/dvb-usb/friio-fe.c include/uapi/linux/dvb/frontend.h I never found any PT1 or PT3 devices here. The friio is also sold only in Japan, afaikt. The devices based on s921 are really crap (and only 1seg). So, basically the devices supported are based on either one of those demods: Dibcom 80xx Toshiba mb86a20s Siano Rio I suspect that the easier ones to find nowadays are the PixelView ones that are based on cx231xx/mb86a20s: PixelView PlayTV USB 2.0 SBTVD Full-Seg - PV-D231U(RN)-F Not the best ISDB-T chip, but it works if they have a good antenna. There are other devices too, but the brand names change a lot, and, as I didn't buy or received any new isdb-t devices those days, I'm unsure what other devices have inside. If your friends want, they could ping me back and I can try to help them to find some devices. With regards to CC decoding, IMHO, the best would be to add a parser for ISDB CC at libdvbv5. Regards, -- 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/RFC v8 03/14] Documentation: leds: Add description of v4l2-flash sub-device
On Fri, Nov 28, 2014 at 10:17:55AM +0100, Jacek Anaszewski wrote: This patch extends LED Flash class documention by the description of interactions with v4l2-flash sub-device. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- 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
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: Sun Nov 30 04:00:15 CET 2014 git branch: test git hash: 504febc3f98c87a8bebd8f2f274f32c0724131e4 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-35-gc1c3f96 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-3.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK 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: WARNINGS linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK linux-3.18-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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
