Re: [Patch v5 12/12] Documention: v4l: Documentation for HEVC CIDs
Hi, Please find my comments inline. On 19 June 2017 at 07:10, Smitha T Murthywrote: > Added V4l2 controls for HEVC encoder > > Signed-off-by: Smitha T Murthy > --- > Documentation/media/uapi/v4l/extended-controls.rst | 364 > + > 1 file changed, 364 insertions(+) > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > b/Documentation/media/uapi/v4l/extended-controls.rst > index abb1057..7767c70 100644 > --- a/Documentation/media/uapi/v4l/extended-controls.rst > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > @@ -1960,6 +1960,370 @@ enum v4l2_vp8_golden_frame_sel - > 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3. > > [snip] > + > + > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)`` > +Selects the hierarchical coding layer. In normal encoding > +(non-hierarchial coding), it should be zero. Possible values are 0 ~ 6. > +0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL CODING > +LAYER 1 and so on. I would like the above to be more consistent. If HIER is in the name then HIER in the description should be used as well. Aside from that, I would recommend using full HIERARCHICAL instead of HIER in the name of the control. Why? Because it is HIERARCHICAL in controls already present in V4L2, such as V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP. [snip] > + > +``V4L2_CID_MPEG_VIDEO_HEVC_LF (boolean)`` > +Indicates loop filtering. Control value 1 indicates loop filtering > +is enabled and when set to 0 indicates loop filtering is disabled. > + > +``V4L2_CID_MPEG_VIDEO_HEVC_LF_SLICE_BOUNDARY (boolean)`` > +Selects whether to apply the loop filter across the slice boundary or > not. > +If the value is 0, loop filter will not be applied across the slice > boundary. > +If the value is 1, loop filter will be applied across the slice boundary. Just a thought. Pretty much the same fucntionality is achieved via the V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE control. It's an enum having three states: enabled, disabled and disabled at slice boundary. Maybe a single control could be introduced? With another legacy define for API compatibility. Also, I don't like that controls are not consistent between H264 and HEVC. I would opt for the enum option. > + > +``V4L2_CID_MPEG_VIDEO_HEVC_LF_BETA_OFFSET_DIV2 (integer)`` > +Selects HEVC loop filter beta offset. The valid range is [-6, +6]. > + > +``V4L2_CID_MPEG_VIDEO_HEVC_LF_TC_OFFSET_DIV2 (integer)`` > +Selects HEVC loop filter tc offset. The valid range is [-6, +6]. > + > +.. _v4l2-hevc-refresh-type: > + > +``V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE`` > +(enum) > + [snip] Best wishes, Kamil
Re: [Patch v5 04/12] [media] s5p-mfc: Support MFCv10.10 buffer requirements
for (i = 0; i < ctx->pb_count; i++) { > + writel(buf_addr1, mfc_regs->e_luma_dpb + (4 * i)); > + buf_addr1 += ctx->luma_dpb_size; > + buf_size1 -= ctx->luma_dpb_size; > + } > + for (i = 0; i < ctx->pb_count; i++) { > + writel(buf_addr1, mfc_regs->e_chroma_dpb + (4 * i)); > + buf_addr1 += ctx->chroma_dpb_size; > + buf_size1 -= ctx->chroma_dpb_size; > + } > + for (i = 0; i < ctx->pb_count; i++) { > + writel(buf_addr1, mfc_regs->e_me_buffer + (4 * i)); > + buf_addr1 += ctx->me_buffer_size; > + buf_size1 -= ctx->me_buffer_size; > + } > + } else { > + for (i = 0; i < ctx->pb_count; i++) { > + writel(buf_addr1, mfc_regs->e_luma_dpb + (4 * i)); > + buf_addr1 += ctx->luma_dpb_size; > + writel(buf_addr1, mfc_regs->e_chroma_dpb + (4 * i)); > + buf_addr1 += ctx->chroma_dpb_size; > + writel(buf_addr1, mfc_regs->e_me_buffer + (4 * i)); > + buf_addr1 += ctx->me_buffer_size; > + buf_size1 -= (ctx->luma_dpb_size + > ctx->chroma_dpb_size > + + ctx->me_buffer_size); > + } > } > > writel(buf_addr1, mfc_regs->e_scratch_buffer_addr); > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h > b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h > index 021b8db..975bbc5 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h > @@ -26,6 +26,8 @@ > (((MB_HEIGHT(y)+1)/2)*2) * 64 + 128) > #define S5P_MFC_DEC_MV_SIZE_V10(x, y) (MB_WIDTH(x) * \ > (((MB_HEIGHT(y)+1)/2)*2) * 64 + 512) > +#define enc_lcu_width(x_size) DIV_ROUND_UP(x_size, 32) > +#define enc_lcu_height(y_size) DIV_ROUND_UP(y_size, 32) Why is this in lower case? Maybe S5P_MFC_LCU_WIDTH/HEIGHT would be better? > > /* Definition */ > #define ENC_MULTI_SLICE_MB_MAX ((1 << 30) - 1) > -- > 2.7.4 > Apart from the above, it looks good to me. Acked-by: Kamil Debski <ka...@wypas.org> Best wishes, Kamil Debski
[GIT PULL] mem2mem changes
The following changes since commit 0db5c79989de2c68d5abb7ba891bfdb3cd3b7e05: [media] media-devnode.h: Fix documentation (2016-06-16 08:14:56 -0300) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git master-20160627 for you to fetch changes up to 54fd06bfa3aed1c14731a372be92c15d3cdd6998: exynos4-is: Fix buffer release issue on fimc m2m video nodes (2016-06-30 16:03:02 +0200) Javier Martinez Canillas (5): s5p-mfc: fix typo in s5p_mfc_dec function comment s5p-mfc: don't print errors on VIDIOC_REQBUFS unsupported mem type s5p-mfc: use vb2_is_streaming() to check vb2 queue status s5p-mfc: set capablity bus_info as required by VIDIOC_QUERYCAP s5p-mfc: improve v4l2_capability driver and card fields Marek Szyprowski (1): media: s5p-mfc: fix error path in driver probe Shuah Khan (3): media: s5p-mfc fix video device release double release in probe error path media: s5p-mfc fix memory leak in s5p_mfc_remove() media: s5p-mfc fix null pointer deference in clk_core_enable() Sylwester Nawrocki (1): exynos4-is: Fix buffer release issue on fimc m2m video nodes drivers/media/platform/exynos4-is/fimc-m2m.c| 24 ++-- drivers/media/platform/s5p-mfc/s5p_mfc.c| 19 +++ drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++ drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 15 --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 7 --- drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 12 +--- 6 files changed, 44 insertions(+), 35 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] media: s5p-mfc fix memory leak in s5p_mfc_remove()
HI Shuah, Which branch do you base your patches on? I have trouble applying this path (https://patchwork.linuxtv.org/patch/34577/) and "s5p-mfc fix null pointer deference in clk_core_enable()" (https://patchwork.linuxtv.org/patch/34751/) onto current linuxtv/master. The top commit of linuxtv/master is : "commit 0db5c79989de2c68d5abb7ba891bfdb3cd3b7e05 Author: Mauro Carvalho Chehab <mche...@s-opensource.com> Date: Thu Jun 16 08:04:40 2016 -0300 [media] media-devnode.h: Fix documentation" Could you please rebase the two patches mentioned above to the linuxtv/master? Best wishes, -- Kamil Debski Samsung R Institute Poland > -Original Message- > From: Shuah Khan [mailto:shua...@osg.samsung.com] > Sent: Monday, June 13, 2016 9:45 PM > To: kyungmin.p...@samsung.com; k.deb...@samsung.com; > jtp.p...@samsung.com; mche...@osg.samsung.com > Cc: Shuah Khan; linux-arm-ker...@lists.infradead.org; linux- > me...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: [PATCH] media: s5p-mfc fix memory leak in s5p_mfc_remove() > > s5p_mfc_remove() fails to release encoder and decoder video devices. > > Signed-off-by: Shuah Khan <shua...@osg.samsung.com> > Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com> > --- > > Changes since v1: > - Addressed comments from Javier Martinez Canillas and added > his reviewed by: > > drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c > b/drivers/media/platform/s5p-mfc/s5p_mfc.c > index 274b4f1..f537b74 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c > @@ -1318,6 +1318,8 @@ static int s5p_mfc_remove(struct platform_device > *pdev) > > video_unregister_device(dev->vfd_enc); > video_unregister_device(dev->vfd_dec); > + video_device_release(dev->vfd_enc); > + video_device_release(dev->vfd_dec); > v4l2_device_unregister(>v4l2_dev); > s5p_mfc_release_firmware(dev); > vb2_dma_contig_cleanup_ctx(dev->alloc_ctx[0]); > -- > 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] mem2mem changes
The following changes since commit 9bd5d8696fd50a10d830e2ad7f9d4e67e0bbbae2: [media] s5p-mfc: don't close instance after free OUTPUT buffers (2016-06-07 10:45:37 -0300) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git master-20160607 for you to fetch changes up to 8bc18e6d9b0b97ff32eab2563d94f9f758bc93d4: s5p-mfc: fix a typo in s5p_mfc_dec (2016-06-07 16:29:55 +0200) ayaka (3): s5p-mfc: Add handling of buffer freeing reqbufs request s5p-mfc: remove unnecessary check in try_fmt s5p-mfc: fix a typo in s5p_mfc_dec drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 12 +++- 2 files changed, 4 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] mem2mem fixes
The following changes since commit aff093d4bbca91f543e24cde2135f393b8130f4b: [media] exynos-gsc: avoid build warning without CONFIG_OF (2016-05-09 18:38:33 -0300) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git fixes-20160524 for you to fetch changes up to 8295280677afd409c32839e47b49de2f20ee459a: s5p-mfc: fix a typo in s5p_mfc_dec (2016-05-24 16:41:43 +0200) Javier Martinez Canillas (4): s5p-mfc: Don't try to put pm->clock if lookup failed s5p-mfc: Set device name for reserved memory region devs s5p-mfc: Add release callback for memory region devs s5p-mfc: Fix race between s5p_mfc_probe() and s5p_mfc_open() ayaka (4): s5p-mfc: don't close instance after free OUTPUT buffers s5p-mfc: Add handling of buffer freeing reqbufs request s5p-mfc: remove unnecessary check in try_fmt s5p-mfc: fix a typo in s5p_mfc_dec drivers/media/platform/s5p-mfc/s5p_mfc.c | 50 ++-- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 3 +- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 12 ++- drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 1 + 4 files changed, 37 insertions(+), 29 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] mem2mem changes
The following changes since commit ecc2fe20e63a21b7db23065ff061b66fbc08e08b: [media] cx23885: video instead of vbi register used (2015-12-18 13:37:12 -0200) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git for-4.5 for you to fetch changes up to 64d8dc83df6bbd58e1782670d6adaf2ff6be9141: coda: enable MPEG-2 ES decoding (2015-12-18 17:31:03 +0100) Andrzej Hajda (6): s5p-mfc: use one implementation of s5p_mfc_get_new_ctx s5p-mfc: make queue cleanup code common s5p-mfc: remove unnecessary callbacks s5p-mfc: use spinlock to protect MFC context s5p-mfc: merge together s5p_mfc_hw_call and s5p_mfc_hw_call_void s5p-mfc: remove volatile attribute from MFC register addresses Julia Lawall (1): s5p-mfc: constify s5p_mfc_codec_ops structures Philipp Zabel (5): coda: make to_coda_video_device static coda: relax coda_jpeg_check_buffer for trailing bytes coda: hook up vidioc_prepare_buf coda: don't start streaming without queued buffers coda: enable MPEG-2 ES decoding drivers/media/platform/coda/coda-bit.c | 2 +- drivers/media/platform/coda/coda-common.c | 21 +- drivers/media/platform/coda/coda-jpeg.c | 26 +- drivers/media/platform/coda/coda.h | 2 +- drivers/media/platform/s5p-mfc/s5p_mfc.c| 99 +++-- drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 14 +- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 16 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 35 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.h| 2 +- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 44 +- drivers/media/platform/s5p-mfc/s5p_mfc_enc.h| 2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.h| 507 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 94 - drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 121 +- 14 files changed, 390 insertions(+), 595 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
Hi, On 12 October 2015 at 12:50, Hans Verkuilwrote: > On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote: >> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote: >>> +if (status & CEC_STATUS_TX_DONE) { >>> +if (status & CEC_STATUS_TX_ERROR) { >>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n"); >>> +cec->tx = STATE_ERROR; >>> +} else { >>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n"); >>> +cec->tx = STATE_DONE; >>> +} >>> +s5p_clr_pending_tx(cec); >>> +} >> >> Your CEC implementation seems to be written around the idea that there >> are only two possible outcomes from a CEC message - "done" and "error", >> which get translated to: > > This code is for the Samsung exynos CEC implementation. Marek, is this all > that the exynos CEC hardware returns? The possible status values that are implemented in the CEC framework are following: +/* cec status field */ +#define CEC_TX_STATUS_OK (0) +#define CEC_TX_STATUS_ARB_LOST (1 << 0) +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1) +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2) +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3) +#define CEC_RX_STATUS_READY(0) The only two ones I could match with the Exynos CEC module status bits are CEC_TX_STATUS_OK and CEC_TX_STATUS_RETRY_TIMEOUT. The status bits in Exynos HW are: - Tx_Error - Tx_Done - Tx_Transferring - Tx_Running - Tx_Bytes_Transferred - Tx_Wait - Tx_Sending_Status_Bit - Tx_Sending_Hdr_Blk - Tx_Sending_Data_Blk - Tx_Latest_Initiator - Tx_Wait_SFT_Succ - Tx_Wait_SFT_New - Tx_Wait_SFT_Retran - Tx_Retrans_Cnt - Tx_ACK_Failed > >> >>> +case STATE_DONE: >>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK); >>> +cec->tx = STATE_IDLE; >>> +break; >>> +case STATE_ERROR: >>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT); >>> +cec->tx = STATE_IDLE; >> >> "okay" and "retry_timeout". So, if we have an adapter which can report >> (eg) a NACK, we have to report it as the obscure "retry timeout" status? >> Why this obscure naming - why can't we have something that uses the >> terminology in the spec? >> > > Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC > 7.1. > The assumption of the CEC framework is that this is done by the CEC adapter > driver, not by the framework. So if after repeated retransmissions there is > still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could > change this to _MAX_RETRIES_REACHED if you prefer. > > The CEC_TX_STATUS_ macros were based on what the adv drivers support (except > for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework). > > Regards, > > Hans Best wishes, Kamil -- 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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
Hi, On 12 October 2015 at 14:39, Hans Verkuil <hverk...@xs4all.nl> wrote: > On 10/12/2015 02:33 PM, Kamil Debski wrote: >> Hi, >> >> On 12 October 2015 at 12:50, Hans Verkuil <hverk...@xs4all.nl> wrote: >>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote: >>>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote: >>>>> +if (status & CEC_STATUS_TX_DONE) { >>>>> +if (status & CEC_STATUS_TX_ERROR) { >>>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n"); >>>>> +cec->tx = STATE_ERROR; >>>>> +} else { >>>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n"); >>>>> +cec->tx = STATE_DONE; >>>>> +} >>>>> +s5p_clr_pending_tx(cec); >>>>> +} >>>> >>>> Your CEC implementation seems to be written around the idea that there >>>> are only two possible outcomes from a CEC message - "done" and "error", >>>> which get translated to: >>> >>> This code is for the Samsung exynos CEC implementation. Marek, is this all >>> that the exynos CEC hardware returns? >> >> The possible status values that are implemented in the CEC framework >> are following: >> >> +/* cec status field */ >> +#define CEC_TX_STATUS_OK (0) >> +#define CEC_TX_STATUS_ARB_LOST (1 << 0) >> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1) >> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2) >> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3) >> +#define CEC_RX_STATUS_READY(0) >> >> The only two ones I could match with the Exynos CEC module status bits are >> CEC_TX_STATUS_OK and CEC_TX_STATUS_RETRY_TIMEOUT. >> >> The status bits in Exynos HW are: >> - Tx_Error >> - Tx_Done >> - Tx_Transferring >> - Tx_Running >> - Tx_Bytes_Transferred >> >> - Tx_Wait >> - Tx_Sending_Status_Bit >> - Tx_Sending_Hdr_Blk >> - Tx_Sending_Data_Blk >> - Tx_Latest_Initiator >> >> - Tx_Wait_SFT_Succ >> - Tx_Wait_SFT_New >> - Tx_Wait_SFT_Retran >> - Tx_Retrans_Cnt >> - Tx_ACK_Failed > > So are these all intermediate states? And every transfer always ends with > Tx_Done or > Tx_Error state? Yes, the Exynos CEC module has a pretty low level status indicator. > It does look that way... > > Regards, > > Hans > Best wishes, Kamil [snip] -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] mem2mem changes for 4.4
The following changes since commit efe98010b80ec4516b2779e1b4e4a8ce16bf89fe: [media] DocBook: Fix remaining issues with VB2 core documentation (2015-10-05 09:12:56 -0300) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git for-4.4 for you to fetch changes up to 86015d46839da68ac47c063410bdb5a085f750da: s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue (2015-10-07 13:14:38 +0200) Andrzej Hajda (2): s5p-mfc: end-of-stream handling for newer encoders s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue Ingi Kim (1): s5p-mfc: fix spelling errors drivers/media/platform/s5p-mfc/s5p_mfc.c| 26 ++--- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 21 +++ drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 13 --- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 49 + 4 files changed, 66 insertions(+), 43 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] s5p-mfc: end-of-stream handling for newer encoders
"enc src y addr: 0x%08lx\n", > src_y_addr); > + mfc_debug(2, "enc src c addr: 0x%08lx\n", > src_c_addr); > > - s5p_mfc_set_enc_frame_buffer_v6(ctx, src_y_addr, src_c_addr); > + s5p_mfc_set_enc_frame_buffer_v6(ctx, src_y_addr, > src_c_addr); > + if (src_mb->flags & MFC_BUF_FLAG_EOS) > + ctx->state = MFCINST_FINISHING; > + } > + } > > dst_mb = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf, list); > dst_mb->flags |= MFC_BUF_FLAG_USED; > @@ -1639,11 +1657,10 @@ static inline void s5p_mfc_run_init_dec(struct > s5p_mfc_ctx *ctx) > spin_lock_irqsave(>irqlock, flags); > mfc_debug(2, "Preparing to init decoding.\n"); > temp_vb = list_entry(ctx->src_queue.next, struct s5p_mfc_buf, list); > - mfc_debug(2, "Header size: %d\n", > - temp_vb->b->vb2_buf.planes[0].bytesused); > + mfc_debug(2, "Header size: %d\n", > +temp_vb->b->vb2_buf.planes[0].bytesused); > s5p_mfc_set_dec_stream_buffer_v6(ctx, > vb2_dma_contig_plane_dma_addr(_vb->b->vb2_buf, > 0), 0, > - temp_vb->b->vb2_buf.planes[0].bytesused); > + temp_vb->b->vb2_buf.planes[0].bytesused); > spin_unlock_irqrestore(>irqlock, flags); > dev->curr_ctx = ctx->num; > s5p_mfc_init_decode_v6(ctx); > -- > 1.9.1 Best wishes, -- Kamil Debski Samsung R Institute Poland -- 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 v2 2/2] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue
Hi Andrzej, > From: Andrzej Hajda [mailto:a.ha...@samsung.com] > Sent: Friday, October 02, 2015 2:10 PM > > MFC driver never delivered EOS event to apps feeding constantly its capture > buffer with fresh buffers. The patch fixes it by marking last buffers returned > by MFC with MFC_BUF_FLAG_EOS flag and firing EOS event on de-queuing > such buffers. Checkpatch complains that lines in the description are too long. WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) #23: Best wishes, -- Kamil Debski Samsung R Institute Poland > > Signed-off-by: Andrzej Hajda <a.ha...@samsung.com> > --- > Hi, > > This version is rebased on latest media_tree branch. > > Regards > Andrzej > --- > drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 + > drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 21 +--- > - > 2 files changed, 14 insertions(+), 8 deletions(-) > > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c > b/drivers/media/platform/s5p-mfc/s5p_mfc.c > index 05a31ee..3ffe2ec 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c > @@ -196,6 +196,7 @@ static void > s5p_mfc_handle_frame_all_extracted(struct s5p_mfc_ctx *ctx) > vb2_set_plane_payload(_buf->b->vb2_buf, 0, 0); > vb2_set_plane_payload(_buf->b->vb2_buf, 1, 0); > list_del(_buf->list); > + dst_buf->flags |= MFC_BUF_FLAG_EOS; > ctx->dst_queue_cnt--; > dst_buf->b->sequence = (ctx->sequence++); > > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c > b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c > index 1734775..8d3d40c 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c > @@ -645,17 +645,22 @@ static int vidioc_dqbuf(struct file *file, void *priv, > struct v4l2_buffer *buf) > mfc_err("Call on DQBUF after unrecoverable error\n"); > return -EIO; > } > - if (buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) > - ret = vb2_dqbuf(>vq_src, buf, file->f_flags & > O_NONBLOCK); > - else if (buf->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) { > + > + switch (buf->type) { > + case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE: > + return vb2_dqbuf(>vq_src, buf, file->f_flags & > O_NONBLOCK); > + case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE: > ret = vb2_dqbuf(>vq_dst, buf, file->f_flags & > O_NONBLOCK); > - if (ret == 0 && ctx->state == MFCINST_FINISHED && > - list_empty(>vq_dst.done_list)) > + if (ret) > + return ret; > + > + if (ctx->state == MFCINST_FINISHED && > + (ctx->dst_bufs[buf->index].flags & MFC_BUF_FLAG_EOS)) > v4l2_event_queue_fh(>fh, ); > - } else { > - ret = -EINVAL; > + return 0; > + default: > + return -EINVAL; > } > - return ret; > } > > /* Export DMA buffer */ > -- > 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] s5p-mfc: fix state check from encoder queue_setup
Hi, From: Andrzej Hajda [mailto:a.ha...@samsung.com] Sent: Tuesday, August 18, 2015 3:32 PM On 05/13/2015 09:25 AM, Seung-Woo Kim wrote: MFCINST_GOT_INST state is set to encoder context with set_format only for catpure buffer. In queue_setup of encoder called during reqbufs, it is checked MFCINST_GOT_INST state for both capture and output buffer. So this patch fixes to encoder to check MFCINST_GOT_INST state only for capture buffer from queue_setup. Signed-off-by: Seung-Woo Kim sw0312@samsung.com Looks OK. Reviewed-by: Andrzej Hajda a.ha...@samsung.com Acked-by: Kamil Debski k.deb...@samsung.com Regards Andrzej Best wishes, Kamil Debski --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c index e65993f..2e57e9f 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c @@ -1819,11 +1819,12 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq, struct s5p_mfc_ctx *ctx = fh_to_ctx(vq-drv_priv); struct s5p_mfc_dev *dev = ctx-dev; - if (ctx-state != MFCINST_GOT_INST) { - mfc_err(inavlid state: %d\n, ctx-state); - return -EINVAL; - } if (vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) { + if (ctx-state != MFCINST_GOT_INST) { + mfc_err(inavlid state: %d\n, ctx-state); + return -EINVAL; + } + if (ctx-dst_fmt) *plane_count = ctx-dst_fmt-num_planes; else -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] m2m: fix bad unlock balance
Hi, On 12 August 2015 at 13:42, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello Hans, I'm sorry for a delay. Once again I've been busy with some other internal stuff. On 2015-07-28 11:02, Hans Verkuil wrote: Kamil, Marek, Why does v4l2_m2m_poll unlock and lock in that function? I've checked the code and indeed the poll_wait() function doesn't do anything that should not be done with queue mutex being taken. I don't remember if it was always like that. You are right that the unlocklock code should be removed. Zahari is right that the locking is unbalanced, but I don't see the reason for the unlock/lock sequence in the first place. I'm wondering if that shouldn't just be removed. Am I missing something? Instead, I would expect to see a spin_lock_irqsave(src/dst_q-done_lock, flags) around the list_empty(src/dst_q-done_list) calls. Indeed, that's another thing that should be fixed in this function. I looks that commit c16218402a000bb25c1277c43ae98c11bcb59bd1 ([media] videobuf2: return -EPIPE from DQBUF after the last buffer) is the root cause of both issues (unballanced locking and lack of spinlock protection), while the unnecessary queue unlock/lock sequence was there from the beginning. I am all with Marek on this. Unlock/lock was there from the beginning, it is not necessary. I agree also that spin_lock/unlock should be added for the list_empty call. [snip] Best wishes, Kamil -- 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: [PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver
Hi, On 21 July 2015 at 15:03, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On 2015-07-16 15:09, Hans Verkuil wrote: Marek, Kamil, On 06/29/15 12:14, Hans Verkuil wrote: From: Kamil Debski ka...@wypas.org Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski ka...@wypas.org Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- snip diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c b/drivers/media/platform/s5p-cec/s5p_cec.c new file mode 100644 index 000..0f16d00 --- /dev/null +++ b/drivers/media/platform/s5p-cec/s5p_cec.c @@ -0,0 +1,283 @@ +/* drivers/media/platform/s5p-cec/s5p_cec.c + * + * Samsung S5P CEC driver + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This driver is based on the cec interface driver for exynos soc by + * SangPil Moon. + */ + +#include linux/clk.h +#include linux/interrupt.h +#include linux/kernel.h +#include linux/mfd/syscon.h +#include linux/module.h +#include linux/of.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/timer.h +#include linux/version.h +#include linux/workqueue.h +#include media/cec.h + +#include exynos_hdmi_cec.h +#include regs-cec.h +#include s5p_cec.h + +#define CEC_NAME s5p-cec + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, debug level (0-2)); + +static int s5p_cec_enable(struct cec_adapter *adap, bool enable) +{ + struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev, adap); + int ret; + + if (enable) { + ret = pm_runtime_get_sync(cec-dev); + + adap-phys_addr = 0x100b; This is a bogus physical address. The actual physical address has to be derived from the EDID that is read by the HDMI transmitter. I think in the case of this driver it will have to be userspace that assigns the physical address after reading the EDID from drm/kms? How did you test this, Kamil? If I remember correctly, physical address has been derived from EDID in the userspace (it is available in /sys/class/drm/*) and passed to s5p-cec driver by appropriate ioctl. I don't know what is the reason for the above 'adap-phys_addr = 0x100b' assignment. At some point there was an idea to read the address from the EDID in kernel. This static address was a hack until the code that reads the EDID is written. As you say, it is much better to leave the address to be set by the userspace. So this assignment serves no purpose anymore. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland Best wishes, Kamil -- 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 1/1] V4L2: platform: Renesas R-Car JPEG codec driver
Hi Mikhail, On 26 June 2015 at 12:34, Mikhail Ulyanov mikhail.ulya...@cogentembedded.com wrote: Hi, Thanks everybody for comments. 2015-06-22 17:54 GMT+03:00 Kamil Debski ka...@wypas.org: Hi, I am adding Jacek Anaszewski to CC loop. He was working with the s5p-jpeg driver some time ago. I've spoken with him about questions in this email recently. Jacek, thank you for your comments :) On 18 June 2015 at 20:48, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Mikhail, (CC'ing Kamil Debski) On Wednesday 06 May 2015 01:03:10 Mikhail Ulianov wrote: On Mon, 04 May 2015 02:32:05 +0300 Laurent Pinchart wrote: [snip] [snip] +/* + * + * Queue operations + * + */ +static int jpu_queue_setup(struct vb2_queue *vq, + const struct v4l2_format *fmt, + unsigned int *nbuffers, unsigned int *nplanes, + unsigned int sizes[], void *alloc_ctxs[]) +{ + struct jpu_ctx *ctx = vb2_get_drv_priv(vq); + struct jpu_q_data *q_data; + unsigned int count = *nbuffers; + unsigned int i; + + q_data = jpu_get_q_data(ctx, vq-type); + + *nplanes = q_data-format.num_planes; + + /* + * Header is parsed during decoding and parsed information stored + * in the context so we do not allow another buffer to overwrite it. + * For now it works this way, but planned for alternation. It shouldn't be difficult to create a jpu_buffer structure that inherits from vb2_buffer and store the information there instead of in the context. You are absolutely right. But for this version i want to keep it simple and also at this moment not everything clear for me with this format autodetection feature we want to have e.g. for decoder if user requested 2 output buffers and then queue first with some valid JPEG with format -1-(so we setup queues format here), after that another one with format -2-... should we discard second one or just change format of queues? what about same situation if user already requested capture buffers. I mean relations with buf_prepare and queue_setup. AFAIU format should remain the same for all requested buffers. I see only one solid solution here - get rid of autodetection feature and rely only on format setted by user, so in this case we can just discard queued buffers with inappropriate format(kind of format validation in kernel). This solution will also work well with NV61, NV21, and semiplanar formats we want to add in next version. *But* with this solution header parsing must be done twice(in user and kernel spaces). I'm a little bit frustrated here :) Yes, it's a bit frustrating indeed. I'm not sure what to advise, I'm not too familiar with the m2m API for JPEG. Kamil, do you have a comment on that ? I am not sure whether it is good to get rid of header parsing by the driver/hardware option. I agree that the buffers should have a consistent format and size. Maybe the way to go would be to allow header parsing by the hardware, but to stop processing when the format has changed? Other solution would be to use the V4L2_EVENT_SOURCE_CHANGE event to inform user space about the change. User space then could check whether the buffers are sufficient or reallocate them. Similar to what happens in MFC when format changes. For me implementing resolution change in JPEG seems like an overkill, but maybe you have a use case that would benefit from this. Initially the JPEG decoder was designed and written as a one shot device. Could you give an example of such use case? The possible use case I can imagine is having an M-JPEG stream where all JPEGs have the same dimensions and format. There I can see some benefits from having more than one buffer on the queues. Then there would be no change in the buffer parameters, so this should work. That's correct. It's exactly our use case, but we have few cameras. So we serialize buffers in user space and sometimes one(or more) cameras have different configuration. I think i should go with stop processing option. It could be possible to have frames from each camera decoded in different contexts. This way the configuration should be consistent for all frames in a context. It will require more memory (more buffers) though... [snip] [snip] Best wishes, Kamil Debski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] v4l2-mem2mem: set the queue owner field just as vb2_ioctl_reqbufs does
Hi Philipp, On 25 June 2015 at 11:01, Philipp Zabel p.za...@pengutronix.de wrote: Signed-off-by: Philipp Zabel p.za...@pengutronix.de Please add the patch description no matter how simple it is and how well the subject covers the content of the patch. Best wishes, Kamil --- drivers/media/v4l2-core/v4l2-mem2mem.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c index dc853e5..511caaa 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -357,9 +357,16 @@ int v4l2_m2m_reqbufs(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, struct v4l2_requestbuffers *reqbufs) { struct vb2_queue *vq; + int ret; vq = v4l2_m2m_get_vq(m2m_ctx, reqbufs-type); - return vb2_reqbufs(vq, reqbufs); + ret = vb2_reqbufs(vq, reqbufs); + /* If count == 0, then the owner has released all buffers and he + is no longer owner of the queue. Otherwise we have a new owner. */ + if (ret == 0) + vq-owner = reqbufs-count ? file-private_data : NULL; + + return ret; } EXPORT_SYMBOL_GPL(v4l2_m2m_reqbufs); -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [URGENT FOR v4.1] [PATCH v2] vb2: Don't WARN when v4l2_buffer.bytesused is 0 for multiplanar buffers
Hi, Just to let you know - the patch that is applied to media_tree/master [1] and media_tree/fixes [2] is v1 and not v2. I think it should be v2. Best wishes, Kamil Debski [1] http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=77a3c6fd90c94f635edb00d4a65f485687538791 [2] http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?h=fixesid=2c7e2e565651c930387effb16ecb8f2f4b42bd45 On 19 June 2015 at 13:05, Kamil Debski ka...@wypas.org wrote: Hi Laurent, First - thank you so much for the patch. I had a look into the code and it looks good. You have my Ack. Thank and best wishes, Kamil Debski On 19 June 2015 at 13:04, Hans Verkuil hverk...@xs4all.nl wrote: On 06/19/2015 02:02 PM, Laurent Pinchart wrote: Commit f61bf13b6a07 ([media] vb2: add allow_zero_bytesused flag to the vb2_queue struct) added a WARN_ONCE to catch usage of a deprecated API using a zero value for v4l2_buffer.bytesused. However, the condition is checked incorrectly, as the v4L2_buffer bytesused field is supposed to be ignored for multiplanar buffers. This results in spurious warnings when using the multiplanar API. Fix it by checking v4l2_buffer.bytesused for uniplanar buffers and v4l2_plane.bytesused for multiplanar buffers. Fixes: f61bf13b6a07 ([media] vb2: add allow_zero_bytesused flag to the vb2_queue struct) Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Kamil Debski ka...@wypas.org Thanks! Hans --- drivers/media/v4l2-core/videobuf2-core.c | 33 ++-- 1 file changed, 23 insertions(+), 10 deletions(-) Changes since v1: - Rename __check_once to check_once - Drop __read_mostly on check_once - Use pr_warn instead of pr_warn_once diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index d835814a24d4..4eaf2f4f0294 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -1242,6 +1242,23 @@ void vb2_discard_done(struct vb2_queue *q) } EXPORT_SYMBOL_GPL(vb2_discard_done); +static void vb2_warn_zero_bytesused(struct vb2_buffer *vb) +{ + static bool check_once; + + if (check_once) + return; + + check_once = true; + __WARN(); + + pr_warn(use of bytesused == 0 is deprecated and will be removed in the future,\n); + if (vb-vb2_queue-allow_zero_bytesused) + pr_warn(use VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n); + else + pr_warn(use the actual size instead.\n); +} + /** * __fill_vb2_buffer() - fill a vb2_buffer with information provided in a * v4l2_buffer by the userspace. The caller has already verified that struct @@ -1252,16 +1269,6 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b { unsigned int plane; - if (V4L2_TYPE_IS_OUTPUT(b-type)) { - if (WARN_ON_ONCE(b-bytesused == 0)) { - pr_warn_once(use of bytesused == 0 is deprecated and will be removed in the future,\n); - if (vb-vb2_queue-allow_zero_bytesused) - pr_warn_once(use VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n); - else - pr_warn_once(use the actual size instead.\n); - } - } - if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) { if (b-memory == V4L2_MEMORY_USERPTR) { for (plane = 0; plane vb-num_planes; ++plane) { @@ -1302,6 +1309,9 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b struct v4l2_plane *pdst = v4l2_planes[plane]; struct v4l2_plane *psrc = b-m.planes[plane]; + if (psrc-bytesused == 0) + vb2_warn_zero_bytesused(vb); + if (vb-vb2_queue-allow_zero_bytesused) pdst-bytesused = psrc-bytesused; else @@ -1336,6 +1346,9 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b } if (V4L2_TYPE_IS_OUTPUT(b-type)) { + if (b-bytesused == 0) + vb2_warn_zero_bytesused(vb); + if (vb-vb2_queue-allow_zero_bytesused) v4l2_planes[0].bytesused = b-bytesused; else -- 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 1/1] V4L2: platform: Renesas R-Car JPEG codec driver
Hi, I am adding Jacek Anaszewski to CC loop. He was working with the s5p-jpeg driver some time ago. I've spoken with him about questions in this email recently. Jacek, thank you for your comments :) On 18 June 2015 at 20:48, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Mikhail, (CC'ing Kamil Debski) On Wednesday 06 May 2015 01:03:10 Mikhail Ulianov wrote: On Mon, 04 May 2015 02:32:05 +0300 Laurent Pinchart wrote: [snip] [snip] +/* + * + * Queue operations + * + */ +static int jpu_queue_setup(struct vb2_queue *vq, + const struct v4l2_format *fmt, + unsigned int *nbuffers, unsigned int *nplanes, + unsigned int sizes[], void *alloc_ctxs[]) +{ + struct jpu_ctx *ctx = vb2_get_drv_priv(vq); + struct jpu_q_data *q_data; + unsigned int count = *nbuffers; + unsigned int i; + + q_data = jpu_get_q_data(ctx, vq-type); + + *nplanes = q_data-format.num_planes; + + /* + * Header is parsed during decoding and parsed information stored + * in the context so we do not allow another buffer to overwrite it. + * For now it works this way, but planned for alternation. It shouldn't be difficult to create a jpu_buffer structure that inherits from vb2_buffer and store the information there instead of in the context. You are absolutely right. But for this version i want to keep it simple and also at this moment not everything clear for me with this format autodetection feature we want to have e.g. for decoder if user requested 2 output buffers and then queue first with some valid JPEG with format -1-(so we setup queues format here), after that another one with format -2-... should we discard second one or just change format of queues? what about same situation if user already requested capture buffers. I mean relations with buf_prepare and queue_setup. AFAIU format should remain the same for all requested buffers. I see only one solid solution here - get rid of autodetection feature and rely only on format setted by user, so in this case we can just discard queued buffers with inappropriate format(kind of format validation in kernel). This solution will also work well with NV61, NV21, and semiplanar formats we want to add in next version. *But* with this solution header parsing must be done twice(in user and kernel spaces). I'm a little bit frustrated here :) Yes, it's a bit frustrating indeed. I'm not sure what to advise, I'm not too familiar with the m2m API for JPEG. Kamil, do you have a comment on that ? I am not sure whether it is good to get rid of header parsing by the driver/hardware option. I agree that the buffers should have a consistent format and size. Maybe the way to go would be to allow header parsing by the hardware, but to stop processing when the format has changed? Other solution would be to use the V4L2_EVENT_SOURCE_CHANGE event to inform user space about the change. User space then could check whether the buffers are sufficient or reallocate them. Similar to what happens in MFC when format changes. For me implementing resolution change in JPEG seems like an overkill, but maybe you have a use case that would benefit from this. Initially the JPEG decoder was designed and written as a one shot device. Could you give an example of such use case? The possible use case I can imagine is having an M-JPEG stream where all JPEGs have the same dimensions and format. There I can see some benefits from having more than one buffer on the queues. Then there would be no change in the buffer parameters, so this should work. [snip] [snip] Best wishes, Kamil Debski -- To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [URGENT FOR v4.1] [PATCH v2] vb2: Don't WARN when v4l2_buffer.bytesused is 0 for multiplanar buffers
Hi Laurent, First - thank you so much for the patch. I had a look into the code and it looks good. You have my Ack. Thank and best wishes, Kamil Debski On 19 June 2015 at 13:04, Hans Verkuil hverk...@xs4all.nl wrote: On 06/19/2015 02:02 PM, Laurent Pinchart wrote: Commit f61bf13b6a07 ([media] vb2: add allow_zero_bytesused flag to the vb2_queue struct) added a WARN_ONCE to catch usage of a deprecated API using a zero value for v4l2_buffer.bytesused. However, the condition is checked incorrectly, as the v4L2_buffer bytesused field is supposed to be ignored for multiplanar buffers. This results in spurious warnings when using the multiplanar API. Fix it by checking v4l2_buffer.bytesused for uniplanar buffers and v4l2_plane.bytesused for multiplanar buffers. Fixes: f61bf13b6a07 ([media] vb2: add allow_zero_bytesused flag to the vb2_queue struct) Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Kamil Debski ka...@wypas.org Thanks! Hans --- drivers/media/v4l2-core/videobuf2-core.c | 33 ++-- 1 file changed, 23 insertions(+), 10 deletions(-) Changes since v1: - Rename __check_once to check_once - Drop __read_mostly on check_once - Use pr_warn instead of pr_warn_once diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index d835814a24d4..4eaf2f4f0294 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -1242,6 +1242,23 @@ void vb2_discard_done(struct vb2_queue *q) } EXPORT_SYMBOL_GPL(vb2_discard_done); +static void vb2_warn_zero_bytesused(struct vb2_buffer *vb) +{ + static bool check_once; + + if (check_once) + return; + + check_once = true; + __WARN(); + + pr_warn(use of bytesused == 0 is deprecated and will be removed in the future,\n); + if (vb-vb2_queue-allow_zero_bytesused) + pr_warn(use VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n); + else + pr_warn(use the actual size instead.\n); +} + /** * __fill_vb2_buffer() - fill a vb2_buffer with information provided in a * v4l2_buffer by the userspace. The caller has already verified that struct @@ -1252,16 +1269,6 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b { unsigned int plane; - if (V4L2_TYPE_IS_OUTPUT(b-type)) { - if (WARN_ON_ONCE(b-bytesused == 0)) { - pr_warn_once(use of bytesused == 0 is deprecated and will be removed in the future,\n); - if (vb-vb2_queue-allow_zero_bytesused) - pr_warn_once(use VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n); - else - pr_warn_once(use the actual size instead.\n); - } - } - if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) { if (b-memory == V4L2_MEMORY_USERPTR) { for (plane = 0; plane vb-num_planes; ++plane) { @@ -1302,6 +1309,9 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b struct v4l2_plane *pdst = v4l2_planes[plane]; struct v4l2_plane *psrc = b-m.planes[plane]; + if (psrc-bytesused == 0) + vb2_warn_zero_bytesused(vb); + if (vb-vb2_queue-allow_zero_bytesused) pdst-bytesused = psrc-bytesused; else @@ -1336,6 +1346,9 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b } if (V4L2_TYPE_IS_OUTPUT(b-type)) { + if (b-bytesused == 0) + vb2_warn_zero_bytesused(vb); + if (vb-vb2_queue-allow_zero_bytesused) v4l2_planes[0].bytesused = b-bytesused; else -- To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [PATCH 2/2] media: s5p-mfc: add additional check for incorrect memory configuration
On 3 June 2015 at 11:36, Marek Szyprowski m.szyprow...@samsung.com wrote: MFC hardware is known to trash random memory if one tries to use a buffer buffer, which has lower DMA addresses than the configured DMA base address. This patch adds a check for this case and proper error handling. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Kamil Debski ka...@wypas.org --- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c| 11 +-- drivers/media/platform/s5p-mfc/s5p_mfc_opr.h| 2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 12 +++- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 8 +--- 4 files changed, 22 insertions(+), 11 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c index 00a1d8b..8d27f88 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c @@ -37,10 +37,9 @@ void s5p_mfc_init_regs(struct s5p_mfc_dev *dev) dev-mfc_regs = s5p_mfc_init_regs_v6_plus(dev); } -int s5p_mfc_alloc_priv_buf(struct device *dev, +int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t base, struct s5p_mfc_priv_buf *b) { - mfc_debug(3, Allocating priv: %zu\n, b-size); b-virt = dma_alloc_coherent(dev, b-size, b-dma, GFP_KERNEL); @@ -50,6 +49,14 @@ int s5p_mfc_alloc_priv_buf(struct device *dev, return -ENOMEM; } + if (b-dma base) { + mfc_err(Invaling memory configuration!\n); + mfc_err(Allocated buffer (%pad) is lower than memory base addres (%pad)\n, + b-dma, base); + dma_free_coherent(dev, b-size, b-virt, b-dma); + return -ENOMEM; + } + mfc_debug(3, Allocated addr %p %pad\n, b-virt, b-dma); return 0; } diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h index 22dfb3e..77a08b1 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h @@ -334,7 +334,7 @@ struct s5p_mfc_hw_ops { void s5p_mfc_init_hw_ops(struct s5p_mfc_dev *dev); void s5p_mfc_init_regs(struct s5p_mfc_dev *dev); -int s5p_mfc_alloc_priv_buf(struct device *dev, +int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t base, struct s5p_mfc_priv_buf *b); void s5p_mfc_release_priv_buf(struct device *dev, struct s5p_mfc_priv_buf *b); diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c index c7adc3d..b3f6700 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c @@ -41,7 +41,7 @@ static int s5p_mfc_alloc_dec_temp_buffers_v5(struct s5p_mfc_ctx *ctx) int ret; ctx-dsc.size = buf_size-dsc; - ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, ctx-dsc); + ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, dev-bank1, ctx-dsc); if (ret) { mfc_err(Failed to allocate temporary buffer\n); return ret; @@ -172,7 +172,8 @@ static int s5p_mfc_alloc_codec_buffers_v5(struct s5p_mfc_ctx *ctx) /* Allocate only if memory from bank 1 is necessary */ if (ctx-bank1.size 0) { - ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, ctx-bank1); + ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, dev-bank1, +ctx-bank1); if (ret) { mfc_err(Failed to allocate Bank1 temporary buffer\n); return ret; @@ -181,7 +182,8 @@ static int s5p_mfc_alloc_codec_buffers_v5(struct s5p_mfc_ctx *ctx) } /* Allocate only if memory from bank 2 is necessary */ if (ctx-bank2.size 0) { - ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_r, ctx-bank2); + ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_r, dev-bank2, +ctx-bank2); if (ret) { mfc_err(Failed to allocate Bank2 temporary buffer\n); s5p_mfc_release_priv_buf(ctx-dev-mem_dev_l, ctx-bank1); @@ -212,7 +214,7 @@ static int s5p_mfc_alloc_instance_buffer_v5(struct s5p_mfc_ctx *ctx) else ctx-ctx.size = buf_size-non_h264_ctx; - ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, ctx-ctx); + ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, dev-bank1, ctx-ctx); if (ret) { mfc_err(Failed to allocate instance buffer\n); return ret; @@ -225,7 +227,7 @@ static int s5p_mfc_alloc_instance_buffer_v5(struct s5p_mfc_ctx *ctx) /* Initialize shared memory */ ctx-shm.size
Re: [PATCH 1/2] media: s5p-mfc: add return value check in mfc_sys_init_cmd
On 3 June 2015 at 11:36, Marek Szyprowski m.szyprow...@samsung.com wrote: alloc_dev_context_buffer method might fail, so add proper return value check. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Kamil Debski ka...@wypas.org --- drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c index f176096..b1b1491 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c @@ -37,8 +37,12 @@ static int s5p_mfc_sys_init_cmd_v6(struct s5p_mfc_dev *dev) { struct s5p_mfc_cmd_args h2r_args; struct s5p_mfc_buf_size_v6 *buf_size = dev-variant-buf_size-priv; + int ret; + + ret = s5p_mfc_hw_call(dev-mfc_ops, alloc_dev_context_buffer, dev); + if (ret) + return ret; - s5p_mfc_hw_call(dev-mfc_ops, alloc_dev_context_buffer, dev); mfc_write(dev, dev-ctx_buf.dma, S5P_FIMV_CONTEXT_MEM_ADDR_V6); mfc_write(dev, buf_size-dev_ctx, S5P_FIMV_CONTEXT_MEM_SIZE_V6); return s5p_mfc_cmd_host2risc_v6(dev, S5P_FIMV_H2R_CMD_SYS_INIT_V6, -- 1.9.2 -- 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] libgencec: Add userspace library for the generic CEC kernel interface
Hi Emil, From: Emil Velikov [mailto:emil.l.veli...@gmail.com] Sent: Tuesday, May 05, 2015 5:03 PM Hi Kamil, It seems that you've only incorporated the libgencec.pc suggestion. Did you change your mind about the others, found out something funny with them (if so can you let me know what) or simply forgot about them ? I have to admit that I was sending the patchset in a hurry and I forgot to merge all the changes in the lib. I am sorry. I have prepared an updated version just now and I am going to send it soon. On 30 April 2015 at 11:25, Kamil Debski k.deb...@samsung.com wrote: Hi Emil, From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Emil Velikov Sent: Wednesday, April 29, 2015 5:00 PM Hi Kamil, Allow me to put a few suggestions: On 29 April 2015 at 11:02, Kamil Debski k.deb...@samsung.com wrote: diff --git a/m4/.gitkeep b/m4/.gitkeep new file mode 100644 index 000..e69de29 Haven't seen any projects doing this. Curious what the benefits of keeping and empty folder might be ? When I run autoreconf -i it complained about missing m4 folder, hence I added this filler file such that the folder is created. Any suggestion on how to do this better? Ahh yes - that lovely message. It turns out that older versions of automake will even error out [1], rather than just printing out a warning. A handy workaround would be to add a .gitignore (and a second one in the top folder) list. Plus it will slim down the untracked files list and let you clearly see when git add was missed :-) Adding .gitignore files is a good suggestion. Will do. Cheers Emil [1] https://bugzilla.redhat.com/show_bug.cgi?id=901333 Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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] libgencec: Add userspace library for the generic CEC kernel interface
Add the libGenCEC library. It was designed to act as an interface between the generic CEC kernel API and userspace applications. It provides a simple interface for applications and an example application that can be used to test the CEC functionality. Signed-off-by: Kamil Debski k.deb...@samsung.com --- Hi, This is the third version of the patch adding a simple library for using with the Kernel's Generic CEC Interface. Changes since v2 I have added the changes suggested by Emil Velikov that did not make it in the v2. - added .gitignore files (and removed m4/.gitkeep) - added AC_PREREQ and LT_PREREQ - added autogen.sh script - fixed examples/Makefile.am (use *_LDADD instead of AM_LDFLAGS - added -no-undefined to src/Makefile.am Changes since v1 - added libgencec.pc.in file Best wishes, Kamil Debski --- .gitignore | 26 +++ AUTHORS |1 + INSTALL |8 + LICENSE | 202 Makefile.am |4 + README | 22 ++ autogen.sh | 13 ++ configure.ac | 27 +++ doc/index.html | 345 +++ examples/Makefile.am |4 + examples/cectest.c | 631 ++ include/gencec.h | 255 libgencec.pc.in | 10 + m4/.gitignore|5 + src/Makefile.am |4 + src/gencec.c | 445 +++ 16 files changed, 2002 insertions(+) create mode 100644 .gitignore create mode 100644 AUTHORS create mode 100644 INSTALL create mode 100644 LICENSE create mode 100644 Makefile.am create mode 100644 README create mode 100755 autogen.sh create mode 100644 configure.ac create mode 100644 doc/index.html create mode 100644 examples/Makefile.am create mode 100644 examples/cectest.c create mode 100644 include/gencec.h create mode 100644 libgencec.pc.in create mode 100644 m4/.gitignore create mode 100644 src/Makefile.am create mode 100644 src/gencec.c diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..8ea993d --- /dev/null +++ b/.gitignore @@ -0,0 +1,26 @@ +*.la +*.lo +*.o + +/aclocal.m4 +/ar-lib +/autom4te.cache/* +/config.* +/configure +/depcomp +/examples/.deps/* +/examples/.libs/* +/examples/cectest +/install-sh + +libgencec.pc +libtool +ltmain.sh +Makefile +Makefile.in + +/missing +src/.deps/* +src/.libs/* + + diff --git a/AUTHORS b/AUTHORS new file mode 100644 index 000..e4b7117 --- /dev/null +++ b/AUTHORS @@ -0,0 +1 @@ +Kamil Debski k.deb...@samsung.com diff --git a/INSTALL b/INSTALL new file mode 100644 index 000..ae60a1f --- /dev/null +++ b/INSTALL @@ -0,0 +1,8 @@ +To install libgencec run following commands: + +./autogen.sh +make +make install + +A cross compilation example for ARM: +CFLAGS=-Ikernel headers ./autogen.sh --host=arm-linux-gnueabi --prefix=installation prefix diff --git a/LICENSE b/LICENSE new file mode 100644 index 000..d645695 --- /dev/null +++ b/LICENSE @@ -0,0 +1,202 @@ + + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + License shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + Licensor shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + Legal Entity shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + control means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + You (or Your) shall mean an individual or Legal Entity + exercising permissions granted by this License. + + Source form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + Object form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + Work shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + Derivative Works shall mean any work, whether in Source
[GIT PULL] mem2mem changes for v4.2
The following changes since commit 1555f3bf5cc172e7d23c2b8db10d656d15bec13e: [media] saa7164: fix compiler warning (2015-05-01 09:09:58 -0300) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git for-4.2 for you to fetch changes up to 4fd781a3dfeac6b98e8aabfbbab73627ea6c9958: s5p-mfc: Set last buffer flag (2015-05-06 17:22:51 +0200) Krzysztof Kozlowski (4): media: platform: exynos-gsc: Constify platform_device_id media: platform: exynos4-is: Constify platform_device_id media: platform: s3c-camif: Constify platform_device_id media: platform: s5p: Constify platform_device_id Peter Seiderer (1): videodev2: Add V4L2_BUF_FLAG_LAST Philipp Zabel (4): DocBook media: document codec draining flow videobuf2: return -EPIPE from DQBUF after the last buffer coda: Set last buffer flag and fix EOS event s5p-mfc: Set last buffer flag Documentation/DocBook/media/v4l/io.xml | 12 + .../DocBook/media/v4l/vidioc-decoder-cmd.xml | 12 - .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 10 +++- Documentation/DocBook/media/v4l/vidioc-qbuf.xml|8 ++ drivers/media/platform/coda/coda-bit.c |4 +-- drivers/media/platform/coda/coda-common.c | 27 drivers/media/platform/coda/coda.h |3 +++ drivers/media/platform/exynos-gsc/gsc-core.c |2 +- drivers/media/platform/exynos4-is/media-dev.c |2 +- drivers/media/platform/s3c-camif/camif-core.c |2 +- drivers/media/platform/s5p-g2d/g2d.c |2 +- drivers/media/platform/s5p-mfc/s5p_mfc.c |3 ++- drivers/media/platform/s5p-tv/hdmi_drv.c |2 +- drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +++- drivers/media/v4l2-core/videobuf2-core.c | 19 +- include/media/videobuf2-core.h | 13 ++ include/trace/events/v4l2.h|3 ++- include/uapi/linux/videodev2.h |2 ++ 18 files changed, 107 insertions(+), 29 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 00/11]
Hi, The sixth version of this patchset addresses recent comments on the mailing list. Please see the changelog below for details. Best wishes, Kamil Debski Changes since v5 - drop struct cec_timeval in favour of a __u64 that keeps the timestamp in ns - remove userspace documentation from Documentation/cec.txt as userspace API is described in the DocBook - add missing documentation for the passthrough mode to the DocBook - add information about the number of events that can be queued - fix misspelling of reply - fix behaviour of posting an event in cec_received_msg, such that the behaviour is consistent with the documentation Changes since v4 - add sequence numbering to transmitted messages - add sequence number handling to event hanlding - add passthrough mode - change reserved field sizes - fixed CEC version defines and addec CEC 2.0 commands - add DocBook documentation Changes since v3 - remove the promiscuous mode - rewrite the devicetree patches - fixes, expansion and partial rewrite of the documentation - reorder of API structures and addition of reserved fields - use own struct to report time (32/64 bit safe) - fix of handling events - add cec.h to include/uapi/linux/Kbuild - fixes in the adv76xx driver (add missing methods, change adv7604 to adv76xx) - cleanup of debug messages in s5p-cec driver - remove non necessary claiming of a gpio in the s5p-cec driver - cleanup headers of the s5p-cec driver Changes since v2 ===- - added promiscuous mode - added new key codes to the input framework - add vendor ID reporting - add the possibility to clear assigned logical addresses - cleanup of the rc cec map Changes since v1 - documentation edited and moved to the Documentation folder - added key up/down message handling - add missing CEC commands to the cec.h file Background == The work on a common CEC framework was started over three years ago by Hans Verkuil. Unfortunately the work has stalled. As I have received the task of creating a driver for the CEC interface module present on the Exynos range of SoCs, I got in touch with Hans. He replied that the work stalled due to his lack of time. Original RFC by Hans Verkuil/Martin Bugge = https://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html Hans Verkuil (5): cec: add HDMI CEC framework DocBook/media: add CEC documentation v4l2-subdev: add HDMI CEC ops cec: adv7604: add cec support. cec: adv7511: add cec support. Kamil Debski (6): dts: exynos4*: add HDMI CEC pin definition to pinctrl dts: exynos4: add node for the HDMI CEC device dts: exynos4412-odroid*: enable the HDMI CEC device HID: add HDMI CEC specific keycodes rc: Add HDMI CEC protoctol handling cec: s5p-cec: Add s5p-cec driver Documentation/DocBook/media/Makefile |4 +- Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 74 ++ Documentation/DocBook/media/v4l/cec-func-close.xml | 59 + Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 ++ Documentation/DocBook/media/v4l/cec-func-open.xml | 94 ++ Documentation/DocBook/media/v4l/cec-func-poll.xml | 89 ++ .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml | 275 + .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml | 78 ++ .../DocBook/media/v4l/cec-ioc-g-adap-state.xml | 87 ++ Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml | 173 +++ .../DocBook/media/v4l/cec-ioc-g-event.xml | 125 ++ .../DocBook/media/v4l/cec-ioc-g-passthrough.xml| 88 ++ .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml | 70 ++ .../DocBook/media/v4l/cec-ioc-receive.xml | 185 +++ Documentation/DocBook/media_api.tmpl |6 +- Documentation/cec.txt | 165 +++ .../devicetree/bindings/media/s5p-cec.txt | 33 + arch/arm/boot/dts/exynos4.dtsi | 12 + arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos4412-odroid-common.dtsi|4 + arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 + drivers/media/Kconfig |6 + drivers/media/Makefile |2 + drivers/media/cec.c| 1191 drivers/media/i2c/adv7511.c| 347 +- drivers/media/i2c/adv7604.c| 207 +++- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|1 + drivers/media/platform/s5p-cec/Makefile|4 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 37 + .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 drivers/media/platform/s5p-cec/regs-cec.h | 96 ++ drivers/media/platform/s5p-cec/s5p_cec.c | 283 + drivers
[PATCH v6 01/11] dts: exynos4*: add HDMI CEC pin definition to pinctrl
Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and Exynos4x12 SoCs. These are required by the HDMI CEC device. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 +++ arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 +++ 2 files changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi index a7c2128..9331c62 100644 --- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi @@ -820,6 +820,13 @@ samsung,pin-pud = 1; samsung,pin-drv = 0; }; + + hdmi_cec: hdmi-cec { + samsung,pins = gpx3-6; + samsung,pin-function = 3; + samsung,pin-pud = 0; + samsung,pin-drv = 0; + }; }; pinctrl@0386 { diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi index c141931..875464e 100644 --- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi @@ -885,6 +885,13 @@ samsung,pin-pud = 0; samsung,pin-drv = 0; }; + + hdmi_cec: hdmi-cec { + samsung,pins = gpx3-6; + samsung,pin-function = 3; + samsung,pin-pud = 0; + samsung,pin-drv = 0; + }; }; pinctrl@0386 { -- 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 v6 02/11] dts: exynos4: add node for the HDMI CEC device
This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index e20cdc2..8776db9 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -704,6 +704,18 @@ status = disabled; }; + hdmicec: cec@100B { + compatible = samsung,s5p-cec; + reg = 0x100B 0x200; + interrupts = 0 114 0; + clocks = clock CLK_HDMI_CEC; + clock-names = hdmicec; + samsung,syscon-phandle = pmu_system_controller; + pinctrl-names = default; + pinctrl-0 = hdmi_cec; + status = disabled; + }; + mixer: mixer@12C1 { compatible = samsung,exynos4210-mixer; interrupts = 0 91 0; -- 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 v6 04/11] HID: add HDMI CEC specific keycodes
Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski k.deb...@samsung.com --- include/uapi/linux/input.h | 12 1 file changed, 12 insertions(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 731417c..7430a3f 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -752,6 +752,18 @@ struct input_keymap_entry { #define KEY_KBDINPUTASSIST_ACCEPT 0x264 #define KEY_KBDINPUTASSIST_CANCEL 0x265 +#define KEY_RIGHT_UP 0x266 +#define KEY_RIGHT_DOWN 0x267 +#define KEY_LEFT_UP0x268 +#define KEY_LEFT_DOWN 0x269 + +#define KEY_NEXT_FAVORITE 0x270 +#define KEY_STOP_RECORD0x271 +#define KEY_PAUSE_RECORD 0x272 +#define KEY_VOD0x273 +#define KEY_UNMUTE 0x274 +#define KEY_DVB0x275 + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 -- 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 v6 03/11] dts: exynos4412-odroid*: enable the HDMI CEC device
Add a dts node entry and enable the HDMI CEC device present in the Exynos4 family of SoCs. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4412-odroid-common.dtsi |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi index 8de12af..e50862d 100644 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi @@ -469,6 +469,10 @@ status = okay; }; + cec@100B { + status = okay; + }; + hdmi_ddc: i2c@1388 { status = okay; pinctrl-names = default; -- 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 v6 05/11] rc: Add HDMI CEC protoctol handling
Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/rc/keymaps/Makefile |1 + drivers/media/rc/keymaps/rc-cec.c | 144 + drivers/media/rc/rc-main.c|1 + include/media/rc-core.h |1 + include/media/rc-map.h|5 +- 5 files changed, 151 insertions(+), 1 deletion(-) create mode 100644 drivers/media/rc/keymaps/rc-cec.c diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile index abf6079..56f10d6 100644 --- a/drivers/media/rc/keymaps/Makefile +++ b/drivers/media/rc/keymaps/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \ rc-behold.o \ rc-behold-columbus.o \ rc-budget-ci-old.o \ + rc-cec.o \ rc-cinergy-1400.o \ rc-cinergy.o \ rc-delock-61959.o \ diff --git a/drivers/media/rc/keymaps/rc-cec.c b/drivers/media/rc/keymaps/rc-cec.c new file mode 100644 index 000..cc5b318 --- /dev/null +++ b/drivers/media/rc/keymaps/rc-cec.c @@ -0,0 +1,144 @@ +/* Keytable for the CEC remote control + * + * Copyright (c) 2015 by Kamil Debski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include media/rc-map.h +#include linux/module.h + +/* CEC Spec High-Definition Multimedia Interface Specification can be obtained + * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf + * The list of control codes is listed in Table 27: User Control Codes p. 95 */ + +static struct rc_map_table cec[] = { + { 0x00, KEY_OK }, + { 0x01, KEY_UP }, + { 0x02, KEY_DOWN }, + { 0x03, KEY_LEFT }, + { 0x04, KEY_RIGHT }, + { 0x05, KEY_RIGHT_UP }, + { 0x06, KEY_RIGHT_DOWN }, + { 0x07, KEY_LEFT_UP }, + { 0x08, KEY_LEFT_DOWN }, + { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */ + /* Note 2: This is the initial display that a device shows. It is +* device-dependent and can be, for example, a contents menu, setup +* menu, favorite menu or other menu. The actual menu displayed +* may also depend on the device’s current state. */ + { 0x0a, KEY_SETUP }, + { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */ + { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */ + { 0x0d, KEY_EXIT }, + /* 0x0e-0x1f: Reserved */ + /* 0x20-0x29: Keys 0 to 9 */ + { 0x20, KEY_NUMERIC_0 }, + { 0x21, KEY_NUMERIC_1 }, + { 0x22, KEY_NUMERIC_2 }, + { 0x23, KEY_NUMERIC_3 }, + { 0x24, KEY_NUMERIC_4 }, + { 0x25, KEY_NUMERIC_5 }, + { 0x26, KEY_NUMERIC_6 }, + { 0x27, KEY_NUMERIC_7 }, + { 0x28, KEY_NUMERIC_8 }, + { 0x29, KEY_NUMERIC_9 }, + { 0x2a, KEY_DOT }, + { 0x2b, KEY_ENTER }, + { 0x2c, KEY_CLEAR }, + /* 0x2d-0x2e: Reserved */ + { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */ + { 0x30, KEY_CHANNELUP }, + { 0x31, KEY_CHANNELDOWN }, + { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */ + { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */ + { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */ + { 0x35, KEY_INFO }, /* CEC Spec: Display Information */ + { 0x36, KEY_HELP }, + { 0x37, KEY_PAGEUP }, + { 0x38, KEY_PAGEDOWN }, + /* 0x39-0x3f: Reserved */ + { 0x40, KEY_POWER }, + { 0x41, KEY_VOLUMEUP }, + { 0x42, KEY_VOLUMEDOWN }, + { 0x43, KEY_MUTE }, + { 0x44, KEY_PLAY }, + { 0x45, KEY_STOP }, + { 0x46, KEY_PAUSE }, + { 0x47, KEY_RECORD }, + { 0x48, KEY_REWIND }, + { 0x49, KEY_FASTFORWARD }, + { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */ + { 0x4b, KEY_FORWARD }, + { 0x4c, KEY_BACK }, + { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */ + { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */ + /* 0x4f: Reserved */ + { 0x50, KEY_ANGLE }, + { 0x51, KEY_TV2 }, + { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */ + { 0x53, KEY_EPG }, + { 0x54, KEY_TIME }, /* CEC Spec: Timer */ + { 0x55, KEY_CONFIG }, + /* 0x56-0x5f: Reserved */ + { 0x60, KEY_PLAY }, /* CEC Spec: Play Function */ + { 0x6024, KEY_PLAY }, + { 0x6020, KEY_PAUSE }, + { 0x61, KEY_PLAYPAUSE }, /* CEC Spec: Pause-Play Function */ + { 0x62, KEY_RECORD }, /* Spec: Record Function */ + { 0x63, KEY_PAUSE
[PATCH v6 06/11] cec: add HDMI CEC framework
From: Hans Verkuil hansv...@cisco.com The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup and fixes] [k.deb...@samsung.com: add missing CEC commands to match spec] [k.deb...@samsung.com: add RC framework support] [k.deb...@samsung.com: move and edit documentation] [k.deb...@samsung.com: add vendor id reporting] [k.deb...@samsung.com: add possibility to clear assigned logical addresses] [k.deb...@samsung.com: documentation fixes, clenaup and expansion] [k.deb...@samsung.com: reorder of API structs and add reserved fields] [k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec problem] [k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild] [k.deb...@samsung.com: add sequence number handling] [k.deb...@samsung.com: add passthrough mode] [k.deb...@samsung.com: fix CEC defines, add missing CEC 2.0 commands] [k.deb...@samsung.com: add DocBook documentation by Hans Verkuil, with minor additions] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/cec.txt | 165 +++ drivers/media/Kconfig |6 + drivers/media/Makefile|2 + drivers/media/cec.c | 1191 + include/media/cec.h | 142 ++ include/uapi/linux/Kbuild |1 + include/uapi/linux/cec.h | 332 + 7 files changed, 1839 insertions(+) create mode 100644 Documentation/cec.txt create mode 100644 drivers/media/cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..a52017c2 --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,165 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple variants of hardware. Adding to +the flexibility of the framework it enables to set which parts of the CEC +protocol processing is handled by the hardware, by the driver and by the +userspace application. + + +The CEC Protocol + + +The CEC protocol enables consumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physical address is determined by the physical +connection between devices. + +The protocol enables control of compatible devices with a single remote. +Synchronous power on/standby, instant playback with changing the content source +on the TV. + +The Kernel Interface + + +CEC Adapter +--- + +#define CEC_LOG_ADDR_INVALID 0xff + +/* The maximum number of logical addresses one device can be assigned to. + * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The + * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */ +#define CEC_MAX_LOG_ADDRS 4 + +/* The Primary Device Type */ +#define CEC_PRIM_DEVTYPE_TV0 +#define CEC_PRIM_DEVTYPE_RECORD1 +#define CEC_PRIM_DEVTYPE_TUNER 3 +#define CEC_PRIM_DEVTYPE_PLAYBACK 4 +#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5 +#define CEC_PRIM_DEVTYPE_SWITCH6 +#define CEC_PRIM_DEVTYPE_VIDEOPROC 7 + +/* The All Device Types flags (CEC 2.0) */ +#define CEC_FL_ALL_DEVTYPE_TV (1 7) +#define CEC_FL_ALL_DEVTYPE_RECORD (1 6) +#define CEC_FL_ALL_DEVTYPE_TUNER (1 5) +#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 4) +#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3) +#define CEC_FL_ALL_DEVTYPE_SWITCH (1 2) +/* And if you wondering what happened to VIDEOPROC devices: those should + * be mapped to a SWITCH. */ + +/* The logical address types that the CEC device wants to claim */ +#define CEC_LOG_ADDR_TYPE_TV 0 +#define CEC_LOG_ADDR_TYPE_RECORD 1 +#define CEC_LOG_ADDR_TYPE_TUNER2 +#define CEC_LOG_ADDR_TYPE_PLAYBACK 3 +#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4 +#define CEC_LOG_ADDR_TYPE_SPECIFIC 5 +#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6 +/* Switches should use UNREGISTERED. + * Video processors should use SPECIFIC. */ + +/* The CEC version */ +#define CEC_VERSION_1_4B 5 +#define CEC_VERSION_2_06 + +struct cec_adapter { + /* internal fields removed */ + + u16 phys_addr; + u32 capabilities; + u8 version; + u8 num_log_addrs; + u8 prim_device[CEC_MAX_LOG_ADDRS]; + u8 log_addr_type[CEC_MAX_LOG_ADDRS]; + u8 log_addr[CEC_MAX_LOG_ADDRS
[PATCH v6 08/11] v4l2-subdev: add HDMI CEC ops
From: Hans Verkuil hansv...@cisco.com Add callbacks to the v4l2_subdev_video_ops. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- include/media/v4l2-subdev.h |8 1 file changed, 8 insertions(+) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index 2f0a345..9323e10 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -40,6 +40,9 @@ #define V4L2_SUBDEV_IR_TX_NOTIFY _IOW('v', 1, u32) #define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001 +#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 2, u32) +#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 3, struct cec_msg) + struct v4l2_device; struct v4l2_ctrl_handler; struct v4l2_event_subscription; @@ -48,6 +51,7 @@ struct v4l2_subdev; struct v4l2_subdev_fh; struct tuner_setup; struct v4l2_mbus_frame_desc; +struct cec_msg; /* decode_vbi_line */ struct v4l2_decode_vbi_line { @@ -352,6 +356,10 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg); int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf, unsigned int *size); + int (*cec_enable)(struct v4l2_subdev *sd, bool enable); + int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr); + int (*cec_transmit)(struct v4l2_subdev *sd, struct cec_msg *msg); + void (*cec_transmit_timed_out)(struct v4l2_subdev *sd); }; /* -- 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 v6 07/11] DocBook/media: add CEC documentation
From: Hans Verkuil hverk...@xs4all.nl Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: add documentation for passthrough mode] [k.deb...@samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/DocBook/media/Makefile |4 +- Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 74 ++ Documentation/DocBook/media/v4l/cec-func-close.xml | 59 + Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 ++ Documentation/DocBook/media/v4l/cec-func-open.xml | 94 +++ Documentation/DocBook/media/v4l/cec-func-poll.xml | 89 +++ .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml | 275 .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml | 78 ++ .../DocBook/media/v4l/cec-ioc-g-adap-state.xml | 87 +++ Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml | 173 .../DocBook/media/v4l/cec-ioc-g-event.xml | 125 + .../DocBook/media/v4l/cec-ioc-g-passthrough.xml| 88 +++ .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml | 70 + .../DocBook/media/v4l/cec-ioc-receive.xml | 185 + Documentation/DocBook/media_api.tmpl |6 +- 16 files changed, 1487 insertions(+), 3 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-state.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-event.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-passthrough.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-vendor-id.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 8bf7c61..9650332 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -64,6 +64,7 @@ IOCTLS = \ $(shell perl -ne 'print $$1 if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print $$1 if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print $$1 if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print $$1 if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/cec.h) \ $(shell perl -ne 'print $$1 if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ VIDIOC_SUBDEV_G_FRAME_INTERVAL \ VIDIOC_SUBDEV_S_FRAME_INTERVAL \ @@ -98,6 +99,7 @@ STRUCTS = \ $(shell perl -ne 'print $$1 if (/^struct\s+([A-Z][^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print $$1 if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/cec.h) \ $(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ $(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) @@ -300,7 +302,7 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: $(MEDIA_OBJ_DIR)/v4l2.xml @( \ for ident in $(IOCTLS) ; do \ entity=`echo $$ident | tr _ -` ; \ - id=`grep refname$$ident $(MEDIA_OBJ_DIR)/vidioc-*.xml $(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,^.*/(.*).xml.*,\1,` ; \ + id=`grep refname$$ident $(MEDIA_OBJ_DIR)/vidioc-*.xml $(MEDIA_OBJ_DIR)/media-ioc-*.xml $(MEDIA_OBJ_DIR)/cec-ioc-*.xml | sed -r s,^.*/(.*).xml.*,\1,` ; \ echo !ENTITY $$entity \link \ linkend='$$id'constant$$ident/constant/link\ \ $@ ;\ diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index fdee6b3..bed940b 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation
[PATCH v6 09/11] cec: adv7604: add cec support.
From: Hans Verkuil hansv...@cisco.com Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: add missing methods cec/io_write_and_or] [k.deb...@samsung.com: change adv7604 to adv76xx in added functions] Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/i2c/adv7604.c | 207 ++- 1 file changed, 206 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 60ffcf0..4921276 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -38,6 +38,7 @@ #include linux/workqueue.h #include media/adv7604.h +#include media/cec.h #include media/v4l2-ctrls.h #include media/v4l2-device.h #include media/v4l2-dv-timings.h @@ -77,6 +78,8 @@ MODULE_LICENSE(GPL); #define ADV76XX_OP_SWAP_CB_CR (1 0) +#define ADV76XX_MAX_ADDRS (3) + enum adv76xx_type { ADV7604, ADV7611, @@ -159,6 +162,10 @@ struct adv76xx_state { u16 spa_port_a[2]; struct v4l2_fract aspect_ratio; u32 rgb_quantization_range; + u8 cec_addr[ADV76XX_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + struct workqueue_struct *work_queues; struct delayed_work delayed_work_enable_hotplug; bool restart_stdi_once; @@ -424,7 +431,15 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, u8 val) return adv_smbus_write_byte_data(state, ADV76XX_PAGE_IO, reg, val); } -static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) +static inline int io_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return io_write(sd, reg, (io_read(sd, reg) mask) | val); +} + + +static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) { return io_write(sd, reg, (io_read(sd, reg) ~mask) | val); } @@ -457,6 +472,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) return adv_smbus_write_byte_data(state, ADV76XX_PAGE_CEC, reg, val); } +static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) mask) | val); +} + static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg) { struct adv76xx_state *state = to_state(sd); @@ -1865,6 +1886,183 @@ static int adv76xx_set_format(struct v4l2_subdev *sd, return 0; } +static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status) +{ + if ((cec_read(sd, 0x11) 0x01) == 0) { + v4l2_dbg(1, debug, sd, %s: tx raw: tx disabled\n, __func__); + return; + } + + if (tx_raw_status 0x02) { + v4l2_dbg(1, debug, sd, %s: tx raw: arbitration lost\n, +__func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_ARB_LOST); + return; + } + if (tx_raw_status 0x04) { + v4l2_dbg(1, debug, sd, %s: tx raw: retry failed\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_RETRY_TIMEOUT); + return; + } + if (tx_raw_status 0x01) { + v4l2_dbg(1, debug, sd, %s: tx raw: ready ok\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_OK); + return; + } +} + +static void adv76xx_cec_isr(struct v4l2_subdev *sd, bool *handled) +{ + struct cec_msg msg; + u8 cec_irq; + + /* cec controller */ + cec_irq = io_read(sd, 0x4d) 0x0f; + if (!cec_irq) + return; + + v4l2_dbg(1, debug, sd, %s: cec: irq 0x%x\n, __func__, cec_irq); + adv76xx_cec_tx_raw_status(sd, cec_irq); + if (cec_irq 0x08) { + msg.len = cec_read(sd, 0x25) 0x1f; + if (msg.len 16) + msg.len = 16; + + if (msg.len) { + u8 i; + + for (i = 0; i msg.len; i++) + msg.msg[i] = cec_read(sd, i + 0x15); + cec_write(sd, 0x26, 0x01); /* re-enable rx */ + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, msg); + } + } + + /* note: the bit order is swapped between 0x4d and 0x4e */ + cec_irq = ((cec_irq 0x08) 3) | ((cec_irq 0x04) 1) | + ((cec_irq 0x02) 1) | ((cec_irq 0x01) 3); + io_write(sd, 0x4e, cec_irq); + + if (handled) + *handled = true; +} + +static int
RE: [PATCH v6 00/11] HDMI CEC framework
Hi, Sorry, I missed the subject for this cover-letter. Added it in this reply. Best wishes, -- Kamil Debski Samsung RD Institute Poland -Original Message- From: Kamil Debski [mailto:k.deb...@samsung.com] Sent: Monday, May 04, 2015 7:33 PM To: dri-de...@lists.freedesktop.org; linux-media@vger.kernel.org Cc: m.szyprow...@samsung.com; k.deb...@samsung.com; mche...@osg.samsung.com; hverk...@xs4all.nl; kyungmin.p...@samsung.com; tho...@tommie-lie.de; s...@mess.org; dmitry.torok...@gmail.com; linux- in...@vger.kernel.org; linux-samsung-...@vger.kernel.org; l...@opdenkamp.eu Subject: [PATCH v6 00/11] Hi, The sixth version of this patchset addresses recent comments on the mailing list. Please see the changelog below for details. Best wishes, Kamil Debski Changes since v5 - drop struct cec_timeval in favour of a __u64 that keeps the timestamp in ns - remove userspace documentation from Documentation/cec.txt as userspace API is described in the DocBook - add missing documentation for the passthrough mode to the DocBook - add information about the number of events that can be queued - fix misspelling of reply - fix behaviour of posting an event in cec_received_msg, such that the behaviour is consistent with the documentation Changes since v4 - add sequence numbering to transmitted messages - add sequence number handling to event hanlding - add passthrough mode - change reserved field sizes - fixed CEC version defines and addec CEC 2.0 commands - add DocBook documentation Changes since v3 - remove the promiscuous mode - rewrite the devicetree patches - fixes, expansion and partial rewrite of the documentation - reorder of API structures and addition of reserved fields - use own struct to report time (32/64 bit safe) - fix of handling events - add cec.h to include/uapi/linux/Kbuild - fixes in the adv76xx driver (add missing methods, change adv7604 to adv76xx) - cleanup of debug messages in s5p-cec driver - remove non necessary claiming of a gpio in the s5p-cec driver - cleanup headers of the s5p-cec driver Changes since v2 ===- - added promiscuous mode - added new key codes to the input framework - add vendor ID reporting - add the possibility to clear assigned logical addresses - cleanup of the rc cec map Changes since v1 - documentation edited and moved to the Documentation folder - added key up/down message handling - add missing CEC commands to the cec.h file Background == The work on a common CEC framework was started over three years ago by Hans Verkuil. Unfortunately the work has stalled. As I have received the task of creating a driver for the CEC interface module present on the Exynos range of SoCs, I got in touch with Hans. He replied that the work stalled due to his lack of time. Original RFC by Hans Verkuil/Martin Bugge = https://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html Hans Verkuil (5): cec: add HDMI CEC framework DocBook/media: add CEC documentation v4l2-subdev: add HDMI CEC ops cec: adv7604: add cec support. cec: adv7511: add cec support. Kamil Debski (6): dts: exynos4*: add HDMI CEC pin definition to pinctrl dts: exynos4: add node for the HDMI CEC device dts: exynos4412-odroid*: enable the HDMI CEC device HID: add HDMI CEC specific keycodes rc: Add HDMI CEC protoctol handling cec: s5p-cec: Add s5p-cec driver Documentation/DocBook/media/Makefile |4 +- Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 74 ++ Documentation/DocBook/media/v4l/cec-func-close.xml | 59 + Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 ++ Documentation/DocBook/media/v4l/cec-func-open.xml | 94 ++ Documentation/DocBook/media/v4l/cec-func-poll.xml | 89 ++ .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml | 275 + .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml | 78 ++ .../DocBook/media/v4l/cec-ioc-g-adap-state.xml | 87 ++ Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml | 173 +++ .../DocBook/media/v4l/cec-ioc-g-event.xml | 125 ++ .../DocBook/media/v4l/cec-ioc-g-passthrough.xml| 88 ++ .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml | 70 ++ .../DocBook/media/v4l/cec-ioc-receive.xml | 185 +++ Documentation/DocBook/media_api.tmpl |6 +- Documentation/cec.txt | 165 +++ .../devicetree/bindings/media/s5p-cec.txt | 33 + arch/arm/boot/dts/exynos4.dtsi | 12 + arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos4412-odroid-common.dtsi|4 + arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 + drivers/media/Kconfig
[PATCH v6 11/11] cec: s5p-cec: Add s5p-cec driver
Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski k.deb...@samsung.com --- .../devicetree/bindings/media/s5p-cec.txt | 33 +++ drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|1 + drivers/media/platform/s5p-cec/Makefile|4 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 37 +++ .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 ++ drivers/media/platform/s5p-cec/regs-cec.h | 96 +++ drivers/media/platform/s5p-cec/s5p_cec.c | 283 drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++ 9 files changed, 748 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt create mode 100644 drivers/media/platform/s5p-cec/Makefile create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt b/Documentation/devicetree/bindings/media/s5p-cec.txt new file mode 100644 index 000..97ca664 --- /dev/null +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt @@ -0,0 +1,33 @@ +* Samsung HDMI CEC driver + +The HDMI CEC module is present is Samsung SoCs and its purpose is to +handle communication between HDMI connected devices over the CEC bus. + +Required properties: + - compatible : value should be follwoing + samsung,s5p-cec + + - reg : Physical base address of the IP registers and length of memory + mapped region. + + - interrupts : HDMI CEC interrupt number to the CPU. + - clocks : from common clock binding: handle to HDMI CEC clock. + - clock-names : from common clock binding: must contain hdmicec, + corresponding to entry in the clocks property. + - samsung,syscon-phandle - phandle to the PMU system controller + +Example: + +hdmicec: cec@100B { + compatible = samsung,s5p-cec; + reg = 0x100B 0x200; + interrupts = 0 114 0; + clocks = clock CLK_HDMI_CEC; + clock-names = hdmicec; + samsung,syscon-phandle = pmu_system_controller; + pinctrl-names = default; + pinctrl-0 = hdmi_cec; + status = okay; +}; + + diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 421f531..203bc06 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -157,6 +157,16 @@ config VIDEO_MEM2MEM_DEINTERLACE help Generic deinterlacing V4L2 driver. +config VIDEO_SAMSUNG_S5P_CEC + tristate Samsung S5P CEC driver + depends on CEC VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) + default n + ---help--- + This is a driver for Samsung S5P HDMI CEC interface. It uses the + generic CEC framework interface. + CEC bus is present in the HDMI connector and enables communication + between compatible devices. + config VIDEO_SAMSUNG_S5P_G2D tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver depends on VIDEO_DEV VIDEO_V4L2 diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 8f85561..f96c9a3 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/ +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/ diff --git a/drivers/media/platform/s5p-cec/Makefile b/drivers/media/platform/s5p-cec/Makefile new file mode 100644 index 000..7f84226 --- /dev/null +++ b/drivers/media/platform/s5p-cec/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o +s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o + + diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h new file mode 100644 index 000..d008695 --- /dev/null +++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h @@ -0,0 +1,37 @@ +/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h + * + * Copyright (c) 2010, 2014 Samsung Electronics + * http://www.samsung.com/ + * + * Header file for interface of Samsung Exynos hdmi cec hardware + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2
[PATCH v6 10/11] cec: adv7511: add cec support.
From: Hans Verkuil hansv...@cisco.com Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/i2c/adv7511.c | 347 ++- include/media/adv7511.h |6 +- 2 files changed, 343 insertions(+), 10 deletions(-) diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 12d9320..d56e110 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -33,6 +33,7 @@ #include media/v4l2-ctrls.h #include media/v4l2-dv-timings.h #include media/adv7511.h +#include media/cec.h static int debug; module_param(debug, int, 0644); @@ -91,6 +92,12 @@ struct adv7511_state { int chip_revision; uint8_t i2c_edid_addr; uint8_t i2c_cec_addr; + + struct i2c_client *i2c_cec; + u8 cec_addr[3]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + /* Is the adv7511 powered on? */ bool power_on; /* Did we receive hotplug and rx-sense signals? */ @@ -222,7 +229,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client *client, return ret; } -static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) +static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) { struct adv7511_state *state = get_adv7511_state(sd); int i; @@ -237,6 +244,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t v4l2_err(sd, %s: i2c read error\n, __func__); } +static inline int cec_read(struct v4l2_subdev *sd, u8 reg) +{ + struct adv7511_state *state = get_adv7511_state(sd); + + return i2c_smbus_read_byte_data(state-i2c_cec, reg); +} + +static int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) +{ + struct adv7511_state *state = get_adv7511_state(sd); + int ret; + int i; + + for (i = 0; i 3; i++) { + ret = i2c_smbus_write_byte_data(state-i2c_cec, reg, val); + if (ret == 0) + return 0; + } + v4l2_err(sd, %s: I2C Write Problem\n, __func__); + return ret; +} + +static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) mask) | val); +} + static inline bool adv7511_have_hotplug(struct v4l2_subdev *sd) { return adv7511_rd(sd, 0x42) MASK_ADV7511_HPD_DETECT; @@ -381,16 +416,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = { #ifdef CONFIG_VIDEO_ADV_DEBUG static void adv7511_inv_register(struct v4l2_subdev *sd) { + struct adv7511_state *state = get_adv7511_state(sd); + v4l2_info(sd, 0x000-0x0ff: Main Map\n); + if (state-i2c_cec) + v4l2_info(sd, 0x100-0x1ff: CEC Map\n); } static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + reg-size = 1; switch (reg-reg 8) { case 0: reg-val = adv7511_rd(sd, reg-reg 0xff); break; + case 1: + if (state-i2c_cec) { + reg-val = cec_read(sd, reg-reg 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, Register %03llx not supported\n, reg-reg); adv7511_inv_register(sd); @@ -401,10 +448,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register * static int adv7511_s_register(struct v4l2_subdev *sd, const struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + switch (reg-reg 8) { case 0: adv7511_wr(sd, reg-reg 0xff, reg-val 0xff); break; + case 1: + if (state-i2c_cec) { + cec_write(sd, reg-reg 0xff, reg-val 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, Register %03llx not supported\n, reg-reg); adv7511_inv_register(sd); @@ -418,6 +473,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd) { struct adv7511_state *state = get_adv7511_state(sd); struct adv7511_state_edid *edid = state-edid; + int i; static const char * const states[] = { in reset, @@ -486,7 +542,21 @@ static int adv7511_log_status(struct v4l2_subdev *sd) else v4l2_info(sd, no timings set\n); v4l2_info(sd, i2c edid addr: 0x%x\n, state-i2c_edid_addr); + + if (state-i2c_cec == NULL) + return 0; + v4l2_info(sd, i2c cec addr: 0x%x\n, state-i2c_cec_addr
[PATCH v2] libgencec: Add userspace library for the generic CEC kernel interface
This is the first version of the libGenCEC library. It was designed to act as an interface between the generic CEC kernel API and userspace applications. It provides a simple interface for applications and an example application that can be used to test the CEC functionality. signed-off-by: Kamil Debski k.deb...@samsung.com --- AUTHORS |1 + INSTALL |9 + LICENSE | 202 Makefile.am |4 + README | 22 ++ configure.ac | 24 ++ doc/index.html | 345 +++ examples/Makefile.am |4 + examples/cectest.c | 631 ++ include/gencec.h | 255 libgencec.pc.in | 10 + src/Makefile.am |4 + src/gencec.c | 445 +++ 13 files changed, 1956 insertions(+) create mode 100644 AUTHORS create mode 100644 INSTALL create mode 100644 LICENSE create mode 100644 Makefile.am create mode 100644 README create mode 100644 configure.ac create mode 100644 doc/index.html create mode 100644 examples/Makefile.am create mode 100644 examples/cectest.c create mode 100644 include/gencec.h create mode 100644 libgencec.pc.in create mode 100644 src/Makefile.am create mode 100644 src/gencec.c diff --git a/AUTHORS b/AUTHORS new file mode 100644 index 000..e4b7117 --- /dev/null +++ b/AUTHORS @@ -0,0 +1 @@ +Kamil Debski k.deb...@samsung.com diff --git a/INSTALL b/INSTALL new file mode 100644 index 000..aac6101 --- /dev/null +++ b/INSTALL @@ -0,0 +1,9 @@ +To install libgencec run following commands: + +autoreconf -i +./configure +make +make install + +A cross compilation example for ARM: +CFLAGS=-Ikernel headers ./configure --host=arm-linux-gnueabi --prefix=installation prefix diff --git a/LICENSE b/LICENSE new file mode 100644 index 000..d645695 --- /dev/null +++ b/LICENSE @@ -0,0 +1,202 @@ + + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + License shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + Licensor shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + Legal Entity shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + control means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + You (or Your) shall mean an individual or Legal Entity + exercising permissions granted by this License. + + Source form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + Object form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + Work shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + Derivative Works shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + Contribution shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, submitted + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code
RE: [PATCH] libgencec: Add userspace library for the generic CEC kernel interface
Hi Emil, From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Emil Velikov Sent: Wednesday, April 29, 2015 5:00 PM Hi Kamil, Allow me to put a few suggestions: On 29 April 2015 at 11:02, Kamil Debski k.deb...@samsung.com wrote: This is the first version of the libGenCEC library. It was designed to act as an interface between the generic CEC kernel API and userspace applications. It provides a simple interface for applications and an example application that can be used to test the CEC functionality. signed-off-by: Kamil Debski k.deb...@samsung.com --- AUTHORS |1 + INSTALL |9 + LICENSE | 202 Makefile.am |4 + README | 22 ++ configure.ac | 24 ++ doc/index.html | 345 +++ examples/Makefile.am |4 + examples/cectest.c | 631 ++ include/gencec.h | 255 src/Makefile.am |4 + src/gencec.c | 445 +++ 12 files changed, 1946 insertions(+) create mode 100644 AUTHORS create mode 100644 INSTALL create mode 100644 LICENSE create mode 100644 Makefile.am create mode 100644 README create mode 100644 configure.ac create mode 100644 doc/index.html create mode 100644 examples/Makefile.am create mode 100644 examples/cectest.c create mode 100644 include/gencec.h create mode 100644 m4/.gitkeep create mode 100644 src/Makefile.am create mode 100644 src/gencec.c diff --git a/AUTHORS b/AUTHORS new file mode 100644 index 000..e4b7117 --- /dev/null +++ b/AUTHORS @@ -0,0 +1 @@ +Kamil Debski k.deb...@samsung.com diff --git a/INSTALL b/INSTALL new file mode 100644 index 000..aac6101 --- /dev/null +++ b/INSTALL @@ -0,0 +1,9 @@ +To install libgencec run following commands: + +autoreconf -i You might want add --force in here, otherwise the files will stay as-is if you update libtool and friends mid-flight. Many projects include autogen.sh like the following. Feel free to add it to libgencec. Thanks, I'll include this in the next version. $cat autogen.sh #! /bin/sh srcdir=`dirname $0` test -z $srcdir srcdir=. ORIGDIR=`pwd` cd $srcdir autoreconf --force --verbose --install || exit 1 cd $ORIGDIR || exit $? if test -z $NOCONFIGURE; then $srcdir/configure $@ fi --- /dev/null +++ b/configure.ac @@ -0,0 +1,24 @@ You can save yourself some headaches if you restrict old and/or buggy autoconf versions which don't work with the project. If I have to guess 2.60 should be ok. AC_PREREQ([XXX]) Good suggestion, thanks. +AC_INIT([libgencec], [0.1], [k.deb...@samsung.com]) +AM_INIT_AUTOMAKE([-Wall -Werror foreign]) + +AC_PROG_CC +AM_PROG_AR +AC_CONFIG_MACRO_DIR([m4]) +AC_DEFINE([_GNU_SOURCE], [], [Use GNU extensions]) + Same for libtool - 2.2 perhaps ? LT_PREREQ([XXX]) I agree. +LT_INIT + +# Checks for typedefs, structures, and compiler characteristics. +AC_C_INLINE +AC_TYPE_SIZE_T +AC_TYPE_UINT16_T +AC_TYPE_UINT32_T +AC_TYPE_UINT8_T + +#AC_CHECK_LIB([c], [malloc]) +# Checks for library functions. +#AC_FUNC_MALLOC +l +AC_CONFIG_FILES([Makefile src/Makefile examples/Makefile]) Would be nice if the library provides libgencec.pc file. This way any users can avoid the explicit header/library check, amongst other useful bits. Thanks for the suggestion, I'll look into this. --- /dev/null +++ b/examples/Makefile.am @@ -0,0 +1,4 @@ +bin_PROGRAMS = cectest +cectest_SOURCES = cectest.c +AM_CPPFLAGS=-I$(top_srcdir)/include/ +AM_LDFLAGS=-L../src/ -lgencec The following seems more common (in the projects I've seen at least) cectest_LDADD = $(top_builddir)/src/libgencec.la diff --git a/m4/.gitkeep b/m4/.gitkeep new file mode 100644 index 000..e69de29 Haven't seen any projects doing this. Curious what the benefits of keeping and empty folder might be ? When I run autoreconf -i it complained about missing m4 folder, hence I added this filler file such that the folder is created. Any suggestion on how to do this better? diff --git a/src/Makefile.am b/src/Makefile.am new file mode 100644 index 000..cb024f0 --- /dev/null +++ b/src/Makefile.am @@ -0,0 +1,4 @@ +lib_LTLIBRARIES = libgencec.la +libgencec_la_SOURCES = gencec.c +libgencec_la_LDFLAGS = -version-info 0:1:0 You might want to add -no-undefined in order to prevent having a library with unresolved symbols. Hope you find the above useful :-) Thank you so much for your review. It is my first real approach at autotools, so your comments are very much appreciated :) Cheers Emil -- Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-media
[PATCH] libgencec: Add userspace library for the generic CEC kernel interface
This is the first version of the libGenCEC library. It was designed to act as an interface between the generic CEC kernel API and userspace applications. It provides a simple interface for applications and an example application that can be used to test the CEC functionality. signed-off-by: Kamil Debski k.deb...@samsung.com --- AUTHORS |1 + INSTALL |9 + LICENSE | 202 Makefile.am |4 + README | 22 ++ configure.ac | 24 ++ doc/index.html | 345 +++ examples/Makefile.am |4 + examples/cectest.c | 631 ++ include/gencec.h | 255 src/Makefile.am |4 + src/gencec.c | 445 +++ 12 files changed, 1946 insertions(+) create mode 100644 AUTHORS create mode 100644 INSTALL create mode 100644 LICENSE create mode 100644 Makefile.am create mode 100644 README create mode 100644 configure.ac create mode 100644 doc/index.html create mode 100644 examples/Makefile.am create mode 100644 examples/cectest.c create mode 100644 include/gencec.h create mode 100644 m4/.gitkeep create mode 100644 src/Makefile.am create mode 100644 src/gencec.c diff --git a/AUTHORS b/AUTHORS new file mode 100644 index 000..e4b7117 --- /dev/null +++ b/AUTHORS @@ -0,0 +1 @@ +Kamil Debski k.deb...@samsung.com diff --git a/INSTALL b/INSTALL new file mode 100644 index 000..aac6101 --- /dev/null +++ b/INSTALL @@ -0,0 +1,9 @@ +To install libgencec run following commands: + +autoreconf -i +./configure +make +make install + +A cross compilation example for ARM: +CFLAGS=-Ikernel headers ./configure --host=arm-linux-gnueabi --prefix=installation prefix diff --git a/LICENSE b/LICENSE new file mode 100644 index 000..d645695 --- /dev/null +++ b/LICENSE @@ -0,0 +1,202 @@ + + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + License shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + Licensor shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + Legal Entity shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + control means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + You (or Your) shall mean an individual or Legal Entity + exercising permissions granted by this License. + + Source form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + Object form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + Work shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + Derivative Works shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + Contribution shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, submitted + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue
[PATCH v5 11/11] DocBook/media: add CEC documentation
From: Hans Verkuil hverk...@xs4all.nl Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: add documentation for passthrough mode] [k.deb...@samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/DocBook/media/Makefile |4 +- Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 74 ++ Documentation/DocBook/media/v4l/cec-func-close.xml | 59 + Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 ++ Documentation/DocBook/media/v4l/cec-func-open.xml | 94 +++ Documentation/DocBook/media/v4l/cec-func-poll.xml | 89 +++ .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml | 275 .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml | 78 ++ .../DocBook/media/v4l/cec-ioc-g-adap-state.xml | 87 +++ Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml | 167 .../DocBook/media/v4l/cec-ioc-g-event.xml | 142 ++ .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml | 70 + .../DocBook/media/v4l/cec-ioc-receive.xml | 185 + Documentation/DocBook/media_api.tmpl |6 +- 15 files changed, 1410 insertions(+), 3 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-state.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-event.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-vendor-id.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 8bf7c61..9650332 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -64,6 +64,7 @@ IOCTLS = \ $(shell perl -ne 'print $$1 if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print $$1 if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print $$1 if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print $$1 if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/cec.h) \ $(shell perl -ne 'print $$1 if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ VIDIOC_SUBDEV_G_FRAME_INTERVAL \ VIDIOC_SUBDEV_S_FRAME_INTERVAL \ @@ -98,6 +99,7 @@ STRUCTS = \ $(shell perl -ne 'print $$1 if (/^struct\s+([A-Z][^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print $$1 if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/cec.h) \ $(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ $(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) @@ -300,7 +302,7 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: $(MEDIA_OBJ_DIR)/v4l2.xml @( \ for ident in $(IOCTLS) ; do \ entity=`echo $$ident | tr _ -` ; \ - id=`grep refname$$ident $(MEDIA_OBJ_DIR)/vidioc-*.xml $(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,^.*/(.*).xml.*,\1,` ; \ + id=`grep refname$$ident $(MEDIA_OBJ_DIR)/vidioc-*.xml $(MEDIA_OBJ_DIR)/media-ioc-*.xml $(MEDIA_OBJ_DIR)/cec-ioc-*.xml | sed -r s,^.*/(.*).xml.*,\1,` ; \ echo !ENTITY $$entity \link \ linkend='$$id'constant$$ident/constant/link\ \ $@ ;\ diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index fdee6b3..bed940b 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -324,6 +324,16 @@ in the frequency range from 87,5 to 108,0 MHz/title subtitleSpecification Version 1.4a
[PATCH v5 09/11] cec: adv7511: add cec support.
From: Hans Verkuil hansv...@cisco.com Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/i2c/adv7511.c | 347 ++- include/media/adv7511.h |6 +- 2 files changed, 343 insertions(+), 10 deletions(-) diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 12d9320..d56e110 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -33,6 +33,7 @@ #include media/v4l2-ctrls.h #include media/v4l2-dv-timings.h #include media/adv7511.h +#include media/cec.h static int debug; module_param(debug, int, 0644); @@ -91,6 +92,12 @@ struct adv7511_state { int chip_revision; uint8_t i2c_edid_addr; uint8_t i2c_cec_addr; + + struct i2c_client *i2c_cec; + u8 cec_addr[3]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + /* Is the adv7511 powered on? */ bool power_on; /* Did we receive hotplug and rx-sense signals? */ @@ -222,7 +229,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client *client, return ret; } -static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) +static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) { struct adv7511_state *state = get_adv7511_state(sd); int i; @@ -237,6 +244,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t v4l2_err(sd, %s: i2c read error\n, __func__); } +static inline int cec_read(struct v4l2_subdev *sd, u8 reg) +{ + struct adv7511_state *state = get_adv7511_state(sd); + + return i2c_smbus_read_byte_data(state-i2c_cec, reg); +} + +static int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) +{ + struct adv7511_state *state = get_adv7511_state(sd); + int ret; + int i; + + for (i = 0; i 3; i++) { + ret = i2c_smbus_write_byte_data(state-i2c_cec, reg, val); + if (ret == 0) + return 0; + } + v4l2_err(sd, %s: I2C Write Problem\n, __func__); + return ret; +} + +static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) mask) | val); +} + static inline bool adv7511_have_hotplug(struct v4l2_subdev *sd) { return adv7511_rd(sd, 0x42) MASK_ADV7511_HPD_DETECT; @@ -381,16 +416,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = { #ifdef CONFIG_VIDEO_ADV_DEBUG static void adv7511_inv_register(struct v4l2_subdev *sd) { + struct adv7511_state *state = get_adv7511_state(sd); + v4l2_info(sd, 0x000-0x0ff: Main Map\n); + if (state-i2c_cec) + v4l2_info(sd, 0x100-0x1ff: CEC Map\n); } static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + reg-size = 1; switch (reg-reg 8) { case 0: reg-val = adv7511_rd(sd, reg-reg 0xff); break; + case 1: + if (state-i2c_cec) { + reg-val = cec_read(sd, reg-reg 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, Register %03llx not supported\n, reg-reg); adv7511_inv_register(sd); @@ -401,10 +448,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register * static int adv7511_s_register(struct v4l2_subdev *sd, const struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + switch (reg-reg 8) { case 0: adv7511_wr(sd, reg-reg 0xff, reg-val 0xff); break; + case 1: + if (state-i2c_cec) { + cec_write(sd, reg-reg 0xff, reg-val 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, Register %03llx not supported\n, reg-reg); adv7511_inv_register(sd); @@ -418,6 +473,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd) { struct adv7511_state *state = get_adv7511_state(sd); struct adv7511_state_edid *edid = state-edid; + int i; static const char * const states[] = { in reset, @@ -486,7 +542,21 @@ static int adv7511_log_status(struct v4l2_subdev *sd) else v4l2_info(sd, no timings set\n); v4l2_info(sd, i2c edid addr: 0x%x\n, state-i2c_edid_addr); + + if (state-i2c_cec == NULL) + return 0; + v4l2_info(sd, i2c cec addr: 0x%x\n, state-i2c_cec_addr
[PATCH v5 06/11] cec: add HDMI CEC framework
From: Hans Verkuil hansv...@cisco.com The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup and fixes] [k.deb...@samsung.com: add missing CEC commands to match spec] [k.deb...@samsung.com: add RC framework support] [k.deb...@samsung.com: move and edit documentation] [k.deb...@samsung.com: add vendor id reporting] [k.deb...@samsung.com: add possibility to clear assigned logical addresses] [k.deb...@samsung.com: documentation fixes, clenaup and expansion] [k.deb...@samsung.com: reorder of API structs and add reserved fields] [k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec problem] [k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild] [k.deb...@samsung.com: add sequence number handling] [k.deb...@samsung.com: add passthrough mode] [k.deb...@samsung.com: fix CEC defines, add missing CEC 2.0 commands] [k.deb...@samsung.com: add DocBook documentation by Hans Verkuil, with minor additions] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/cec.txt | 396 +++ drivers/media/Kconfig |6 + drivers/media/Makefile|2 + drivers/media/cec.c | 1200 + include/media/cec.h | 142 ++ include/uapi/linux/Kbuild |1 + include/uapi/linux/cec.h | 337 + 7 files changed, 2084 insertions(+) create mode 100644 Documentation/cec.txt create mode 100644 drivers/media/cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..2b6c08a --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,396 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple variants of hardware. Adding to +the flexibility of the framework it enables to set which parts of the CEC +protocol processing is handled by the hardware, by the driver and by the +userspace application. + + +The CEC Protocol + + +The CEC protocol enables consumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physical address is determined by the physical +connection between devices. + +The protocol enables control of compatible devices with a single remote. +Synchronous power on/standby, instant playback with changing the content source +on the TV. + +The Kernel Interface + + +CEC Adapter +--- + +#define CEC_LOG_ADDR_INVALID 0xff + +/* The maximum number of logical addresses one device can be assigned to. + * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The + * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */ +#define CEC_MAX_LOG_ADDRS 4 + +/* The Primary Device Type */ +#define CEC_PRIM_DEVTYPE_TV0 +#define CEC_PRIM_DEVTYPE_RECORD1 +#define CEC_PRIM_DEVTYPE_TUNER 3 +#define CEC_PRIM_DEVTYPE_PLAYBACK 4 +#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5 +#define CEC_PRIM_DEVTYPE_SWITCH6 +#define CEC_PRIM_DEVTYPE_VIDEOPROC 7 + +/* The All Device Types flags (CEC 2.0) */ +#define CEC_FL_ALL_DEVTYPE_TV (1 7) +#define CEC_FL_ALL_DEVTYPE_RECORD (1 6) +#define CEC_FL_ALL_DEVTYPE_TUNER (1 5) +#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 4) +#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3) +#define CEC_FL_ALL_DEVTYPE_SWITCH (1 2) +/* And if you wondering what happened to VIDEOPROC devices: those should + * be mapped to a SWITCH. */ + +/* The logical address types that the CEC device wants to claim */ +#define CEC_LOG_ADDR_TYPE_TV 0 +#define CEC_LOG_ADDR_TYPE_RECORD 1 +#define CEC_LOG_ADDR_TYPE_TUNER2 +#define CEC_LOG_ADDR_TYPE_PLAYBACK 3 +#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4 +#define CEC_LOG_ADDR_TYPE_SPECIFIC 5 +#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6 +/* Switches should use UNREGISTERED. + * Video processors should use SPECIFIC. */ + +/* The CEC version */ +#define CEC_VERSION_1_4B 5 +#define CEC_VERSION_2_06 + +struct cec_adapter { + /* internal fields removed */ + + u16 phys_addr; + u32 capabilities; + u8 version; + u8 num_log_addrs; + u8 prim_device[CEC_MAX_LOG_ADDRS]; + u8 log_addr_type[CEC_MAX_LOG_ADDRS]; + u8 log_addr
[PATCH v5 10/11] cec: s5p-cec: Add s5p-cec driver
Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski k.deb...@samsung.com --- .../devicetree/bindings/media/s5p-cec.txt | 33 +++ drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|1 + drivers/media/platform/s5p-cec/Makefile|4 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 37 +++ .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 ++ drivers/media/platform/s5p-cec/regs-cec.h | 96 +++ drivers/media/platform/s5p-cec/s5p_cec.c | 283 drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++ 9 files changed, 748 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt create mode 100644 drivers/media/platform/s5p-cec/Makefile create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt b/Documentation/devicetree/bindings/media/s5p-cec.txt new file mode 100644 index 000..97ca664 --- /dev/null +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt @@ -0,0 +1,33 @@ +* Samsung HDMI CEC driver + +The HDMI CEC module is present is Samsung SoCs and its purpose is to +handle communication between HDMI connected devices over the CEC bus. + +Required properties: + - compatible : value should be follwoing + samsung,s5p-cec + + - reg : Physical base address of the IP registers and length of memory + mapped region. + + - interrupts : HDMI CEC interrupt number to the CPU. + - clocks : from common clock binding: handle to HDMI CEC clock. + - clock-names : from common clock binding: must contain hdmicec, + corresponding to entry in the clocks property. + - samsung,syscon-phandle - phandle to the PMU system controller + +Example: + +hdmicec: cec@100B { + compatible = samsung,s5p-cec; + reg = 0x100B 0x200; + interrupts = 0 114 0; + clocks = clock CLK_HDMI_CEC; + clock-names = hdmicec; + samsung,syscon-phandle = pmu_system_controller; + pinctrl-names = default; + pinctrl-0 = hdmi_cec; + status = okay; +}; + + diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 421f531..203bc06 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -157,6 +157,16 @@ config VIDEO_MEM2MEM_DEINTERLACE help Generic deinterlacing V4L2 driver. +config VIDEO_SAMSUNG_S5P_CEC + tristate Samsung S5P CEC driver + depends on CEC VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) + default n + ---help--- + This is a driver for Samsung S5P HDMI CEC interface. It uses the + generic CEC framework interface. + CEC bus is present in the HDMI connector and enables communication + between compatible devices. + config VIDEO_SAMSUNG_S5P_G2D tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver depends on VIDEO_DEV VIDEO_V4L2 diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 8f85561..f96c9a3 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/ +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/ diff --git a/drivers/media/platform/s5p-cec/Makefile b/drivers/media/platform/s5p-cec/Makefile new file mode 100644 index 000..7f84226 --- /dev/null +++ b/drivers/media/platform/s5p-cec/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o +s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o + + diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h new file mode 100644 index 000..d008695 --- /dev/null +++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h @@ -0,0 +1,37 @@ +/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h + * + * Copyright (c) 2010, 2014 Samsung Electronics + * http://www.samsung.com/ + * + * Header file for interface of Samsung Exynos hdmi cec hardware + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2
[PATCH v5 03/11] dts: exynos4412-odroid*: enable the HDMI CEC device
Add a dts node entry and enable the HDMI CEC device present in the Exynos4 family of SoCs. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4412-odroid-common.dtsi |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi index 8de12af..e50862d 100644 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi @@ -469,6 +469,10 @@ status = okay; }; + cec@100B { + status = okay; + }; + hdmi_ddc: i2c@1388 { status = okay; pinctrl-names = default; -- 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 v5 01/11] dts: exynos4*: add HDMI CEC pin definition to pinctrl
Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and Exynos4x12 SoCs. These are required by the HDMI CEC device. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 +++ arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 +++ 2 files changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi index a7c2128..9331c62 100644 --- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi @@ -820,6 +820,13 @@ samsung,pin-pud = 1; samsung,pin-drv = 0; }; + + hdmi_cec: hdmi-cec { + samsung,pins = gpx3-6; + samsung,pin-function = 3; + samsung,pin-pud = 0; + samsung,pin-drv = 0; + }; }; pinctrl@0386 { diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi index c141931..875464e 100644 --- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi @@ -885,6 +885,13 @@ samsung,pin-pud = 0; samsung,pin-drv = 0; }; + + hdmi_cec: hdmi-cec { + samsung,pins = gpx3-6; + samsung,pin-function = 3; + samsung,pin-pud = 0; + samsung,pin-drv = 0; + }; }; pinctrl@0386 { -- 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 v5 02/11] dts: exynos4: add node for the HDMI CEC device
This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index e20cdc2..8776db9 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -704,6 +704,18 @@ status = disabled; }; + hdmicec: cec@100B { + compatible = samsung,s5p-cec; + reg = 0x100B 0x200; + interrupts = 0 114 0; + clocks = clock CLK_HDMI_CEC; + clock-names = hdmicec; + samsung,syscon-phandle = pmu_system_controller; + pinctrl-names = default; + pinctrl-0 = hdmi_cec; + status = disabled; + }; + mixer: mixer@12C1 { compatible = samsung,exynos4210-mixer; interrupts = 0 91 0; -- 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 v5 04/11] HID: add HDMI CEC specific keycodes
Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski k.deb...@samsung.com --- include/uapi/linux/input.h | 12 1 file changed, 12 insertions(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 731417c..7430a3f 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -752,6 +752,18 @@ struct input_keymap_entry { #define KEY_KBDINPUTASSIST_ACCEPT 0x264 #define KEY_KBDINPUTASSIST_CANCEL 0x265 +#define KEY_RIGHT_UP 0x266 +#define KEY_RIGHT_DOWN 0x267 +#define KEY_LEFT_UP0x268 +#define KEY_LEFT_DOWN 0x269 + +#define KEY_NEXT_FAVORITE 0x270 +#define KEY_STOP_RECORD0x271 +#define KEY_PAUSE_RECORD 0x272 +#define KEY_VOD0x273 +#define KEY_UNMUTE 0x274 +#define KEY_DVB0x275 + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 -- 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 v5 05/11] rc: Add HDMI CEC protoctol handling
Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/rc/keymaps/Makefile |1 + drivers/media/rc/keymaps/rc-cec.c | 144 + drivers/media/rc/rc-main.c|1 + include/media/rc-core.h |1 + include/media/rc-map.h|5 +- 5 files changed, 151 insertions(+), 1 deletion(-) create mode 100644 drivers/media/rc/keymaps/rc-cec.c diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile index abf6079..56f10d6 100644 --- a/drivers/media/rc/keymaps/Makefile +++ b/drivers/media/rc/keymaps/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \ rc-behold.o \ rc-behold-columbus.o \ rc-budget-ci-old.o \ + rc-cec.o \ rc-cinergy-1400.o \ rc-cinergy.o \ rc-delock-61959.o \ diff --git a/drivers/media/rc/keymaps/rc-cec.c b/drivers/media/rc/keymaps/rc-cec.c new file mode 100644 index 000..cc5b318 --- /dev/null +++ b/drivers/media/rc/keymaps/rc-cec.c @@ -0,0 +1,144 @@ +/* Keytable for the CEC remote control + * + * Copyright (c) 2015 by Kamil Debski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include media/rc-map.h +#include linux/module.h + +/* CEC Spec High-Definition Multimedia Interface Specification can be obtained + * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf + * The list of control codes is listed in Table 27: User Control Codes p. 95 */ + +static struct rc_map_table cec[] = { + { 0x00, KEY_OK }, + { 0x01, KEY_UP }, + { 0x02, KEY_DOWN }, + { 0x03, KEY_LEFT }, + { 0x04, KEY_RIGHT }, + { 0x05, KEY_RIGHT_UP }, + { 0x06, KEY_RIGHT_DOWN }, + { 0x07, KEY_LEFT_UP }, + { 0x08, KEY_LEFT_DOWN }, + { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */ + /* Note 2: This is the initial display that a device shows. It is +* device-dependent and can be, for example, a contents menu, setup +* menu, favorite menu or other menu. The actual menu displayed +* may also depend on the device’s current state. */ + { 0x0a, KEY_SETUP }, + { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */ + { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */ + { 0x0d, KEY_EXIT }, + /* 0x0e-0x1f: Reserved */ + /* 0x20-0x29: Keys 0 to 9 */ + { 0x20, KEY_NUMERIC_0 }, + { 0x21, KEY_NUMERIC_1 }, + { 0x22, KEY_NUMERIC_2 }, + { 0x23, KEY_NUMERIC_3 }, + { 0x24, KEY_NUMERIC_4 }, + { 0x25, KEY_NUMERIC_5 }, + { 0x26, KEY_NUMERIC_6 }, + { 0x27, KEY_NUMERIC_7 }, + { 0x28, KEY_NUMERIC_8 }, + { 0x29, KEY_NUMERIC_9 }, + { 0x2a, KEY_DOT }, + { 0x2b, KEY_ENTER }, + { 0x2c, KEY_CLEAR }, + /* 0x2d-0x2e: Reserved */ + { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */ + { 0x30, KEY_CHANNELUP }, + { 0x31, KEY_CHANNELDOWN }, + { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */ + { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */ + { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */ + { 0x35, KEY_INFO }, /* CEC Spec: Display Information */ + { 0x36, KEY_HELP }, + { 0x37, KEY_PAGEUP }, + { 0x38, KEY_PAGEDOWN }, + /* 0x39-0x3f: Reserved */ + { 0x40, KEY_POWER }, + { 0x41, KEY_VOLUMEUP }, + { 0x42, KEY_VOLUMEDOWN }, + { 0x43, KEY_MUTE }, + { 0x44, KEY_PLAY }, + { 0x45, KEY_STOP }, + { 0x46, KEY_PAUSE }, + { 0x47, KEY_RECORD }, + { 0x48, KEY_REWIND }, + { 0x49, KEY_FASTFORWARD }, + { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */ + { 0x4b, KEY_FORWARD }, + { 0x4c, KEY_BACK }, + { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */ + { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */ + /* 0x4f: Reserved */ + { 0x50, KEY_ANGLE }, + { 0x51, KEY_TV2 }, + { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */ + { 0x53, KEY_EPG }, + { 0x54, KEY_TIME }, /* CEC Spec: Timer */ + { 0x55, KEY_CONFIG }, + /* 0x56-0x5f: Reserved */ + { 0x60, KEY_PLAY }, /* CEC Spec: Play Function */ + { 0x6024, KEY_PLAY }, + { 0x6020, KEY_PAUSE }, + { 0x61, KEY_PLAYPAUSE }, /* CEC Spec: Pause-Play Function */ + { 0x62, KEY_RECORD }, /* Spec: Record Function */ + { 0x63, KEY_PAUSE
[PATCH v5 00/11] HDMI CEC framework
Hi, This is the fifth version of the HDMI CEC framework patches. All the previous version have spun many discussions and quite a few changes. Hopefully, in this version, the code of the framework matured and got closer to meeting our requirements. Again, thank you so much for all the discussion and comments. With your help the code of the framework improved. The major change is an introduction of a new special mode - the passthrough mode. It might look that it is similar to the long gone promiscuous mode, however its purpose is different. After the comment by Lars Op den Kamp, we decided that it is necessary to introduce the passthrough mode. In this mode the framework takes minimal part in handling CEC messages. Why this mode is necessary? It turns out that handling of CEC communication is very vendor specific. The libCEC library handles most of these vendor quirks however it requires low level access to the messages on the CEC bus. In the passthrough mode the messages are forwarded to the userspace with very little handling by the kernel CEC framework. Without passthrough enabled the kernel handles message replies etc. as defined in the spec. This should work well with well-mannered systems that follow the spec and have little vendor specific quirks. Comments are welcome. Best wishes, Kamil Debski Changes since v4 - add sequence numbering to transmitted messages - add sequence number handling to event hanlding - add passthrough mode - change reserved field sizes - fixed CEC version defines and addec CEC 2.0 commands - add DocBook documentation Changes since v3 - remove the promiscuous mode - rewrite the devicetree patches - fixes, expansion and partial rewrite of the documentation - reorder of API structures and addition of reserved fields - use own struct to report time (32/64 bit safe) - fix of handling events - add cec.h to include/uapi/linux/Kbuild - fixes in the adv76xx driver (add missing methods, change adv7604 to adv76xx) - cleanup of debug messages in s5p-cec driver - remove non necessary claiming of a gpio in the s5p-cec driver - cleanup headers of the s5p-cec driver Changes since v2 ===- - added promiscuous mode - added new key codes to the input framework - add vendor ID reporting - add the possibility to clear assigned logical addresses - cleanup of the rc cec map Changes since v1 - documentation edited and moved to the Documentation folder - added key up/down message handling - add missing CEC commands to the cec.h file Background == The work on a common CEC framework was started over three years ago by Hans Verkuil. Unfortunately the work has stalled. As I have received the task of creating a driver for the CEC interface module present on the Exynos range of SoCs, I got in touch with Hans. He replied that the work stalled due to his lack of time. Original RFC by Hans Verkuil/Martin Bugge = https://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html Hans Verkuil (5): cec: add HDMI CEC framework v4l2-subdev: add HDMI CEC ops cec: adv7604: add cec support. cec: adv7511: add cec support. DocBook/media: add CEC documentation Kamil Debski (6): dts: exynos4*: add HDMI CEC pin definition to pinctrl dts: exynos4: add node for the HDMI CEC device dts: exynos4412-odroid*: enable the HDMI CEC device HID: add HDMI CEC specific keycodes rc: Add HDMI CEC protoctol handling cec: s5p-cec: Add s5p-cec driver Documentation/DocBook/media/Makefile |4 +- Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 74 ++ Documentation/DocBook/media/v4l/cec-func-close.xml | 59 + Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 ++ Documentation/DocBook/media/v4l/cec-func-open.xml | 94 ++ Documentation/DocBook/media/v4l/cec-func-poll.xml | 89 ++ .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml | 275 + .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml | 78 ++ .../DocBook/media/v4l/cec-ioc-g-adap-state.xml | 87 ++ Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml | 167 +++ .../DocBook/media/v4l/cec-ioc-g-event.xml | 142 +++ .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml | 70 ++ .../DocBook/media/v4l/cec-ioc-receive.xml | 185 +++ Documentation/DocBook/media_api.tmpl |6 +- Documentation/cec.txt | 396 +++ .../devicetree/bindings/media/s5p-cec.txt | 33 + arch/arm/boot/dts/exynos4.dtsi | 12 + arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos4412-odroid-common.dtsi|4 + arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 + drivers/media/Kconfig |6 + drivers/media/Makefile |2 + drivers/media/cec.c
[PATCH v5 07/11] v4l2-subdev: add HDMI CEC ops
From: Hans Verkuil hansv...@cisco.com Add callbacks to the v4l2_subdev_video_ops. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- include/media/v4l2-subdev.h |8 1 file changed, 8 insertions(+) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index 2f0a345..9323e10 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -40,6 +40,9 @@ #define V4L2_SUBDEV_IR_TX_NOTIFY _IOW('v', 1, u32) #define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001 +#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 2, u32) +#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 3, struct cec_msg) + struct v4l2_device; struct v4l2_ctrl_handler; struct v4l2_event_subscription; @@ -48,6 +51,7 @@ struct v4l2_subdev; struct v4l2_subdev_fh; struct tuner_setup; struct v4l2_mbus_frame_desc; +struct cec_msg; /* decode_vbi_line */ struct v4l2_decode_vbi_line { @@ -352,6 +356,10 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg); int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf, unsigned int *size); + int (*cec_enable)(struct v4l2_subdev *sd, bool enable); + int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr); + int (*cec_transmit)(struct v4l2_subdev *sd, struct cec_msg *msg); + void (*cec_transmit_timed_out)(struct v4l2_subdev *sd); }; /* -- 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 v5 08/11] cec: adv7604: add cec support.
From: Hans Verkuil hansv...@cisco.com Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: add missing methods cec/io_write_and_or] [k.deb...@samsung.com: change adv7604 to adv76xx in added functions] Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/i2c/adv7604.c | 207 ++- 1 file changed, 206 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 60ffcf0..4921276 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -38,6 +38,7 @@ #include linux/workqueue.h #include media/adv7604.h +#include media/cec.h #include media/v4l2-ctrls.h #include media/v4l2-device.h #include media/v4l2-dv-timings.h @@ -77,6 +78,8 @@ MODULE_LICENSE(GPL); #define ADV76XX_OP_SWAP_CB_CR (1 0) +#define ADV76XX_MAX_ADDRS (3) + enum adv76xx_type { ADV7604, ADV7611, @@ -159,6 +162,10 @@ struct adv76xx_state { u16 spa_port_a[2]; struct v4l2_fract aspect_ratio; u32 rgb_quantization_range; + u8 cec_addr[ADV76XX_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + struct workqueue_struct *work_queues; struct delayed_work delayed_work_enable_hotplug; bool restart_stdi_once; @@ -424,7 +431,15 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, u8 val) return adv_smbus_write_byte_data(state, ADV76XX_PAGE_IO, reg, val); } -static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) +static inline int io_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return io_write(sd, reg, (io_read(sd, reg) mask) | val); +} + + +static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) { return io_write(sd, reg, (io_read(sd, reg) ~mask) | val); } @@ -457,6 +472,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) return adv_smbus_write_byte_data(state, ADV76XX_PAGE_CEC, reg, val); } +static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) mask) | val); +} + static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg) { struct adv76xx_state *state = to_state(sd); @@ -1865,6 +1886,183 @@ static int adv76xx_set_format(struct v4l2_subdev *sd, return 0; } +static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status) +{ + if ((cec_read(sd, 0x11) 0x01) == 0) { + v4l2_dbg(1, debug, sd, %s: tx raw: tx disabled\n, __func__); + return; + } + + if (tx_raw_status 0x02) { + v4l2_dbg(1, debug, sd, %s: tx raw: arbitration lost\n, +__func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_ARB_LOST); + return; + } + if (tx_raw_status 0x04) { + v4l2_dbg(1, debug, sd, %s: tx raw: retry failed\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_RETRY_TIMEOUT); + return; + } + if (tx_raw_status 0x01) { + v4l2_dbg(1, debug, sd, %s: tx raw: ready ok\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_OK); + return; + } +} + +static void adv76xx_cec_isr(struct v4l2_subdev *sd, bool *handled) +{ + struct cec_msg msg; + u8 cec_irq; + + /* cec controller */ + cec_irq = io_read(sd, 0x4d) 0x0f; + if (!cec_irq) + return; + + v4l2_dbg(1, debug, sd, %s: cec: irq 0x%x\n, __func__, cec_irq); + adv76xx_cec_tx_raw_status(sd, cec_irq); + if (cec_irq 0x08) { + msg.len = cec_read(sd, 0x25) 0x1f; + if (msg.len 16) + msg.len = 16; + + if (msg.len) { + u8 i; + + for (i = 0; i msg.len; i++) + msg.msg[i] = cec_read(sd, i + 0x15); + cec_write(sd, 0x26, 0x01); /* re-enable rx */ + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, msg); + } + } + + /* note: the bit order is swapped between 0x4d and 0x4e */ + cec_irq = ((cec_irq 0x08) 3) | ((cec_irq 0x04) 1) | + ((cec_irq 0x02) 1) | ((cec_irq 0x01) 3); + io_write(sd, 0x4e, cec_irq); + + if (handled) + *handled = true; +} + +static int
RE: [PATCH v4 06/10] cec: add HDMI CEC framework
Hi Lars, Thank you for your comments. From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Lars Op den Kamp Sent: Friday, April 24, 2015 12:04 PM Hi Kamil, Hans, I'm the main developer of libCEC (https://github.com/Pulse-Eight/libcec). Sorry for the late time to jump in here, but I wasn't signed up to this mailing list and someone pointed me to this discussion. Unfortunately this approach will not work with half the TVs that are out there. I'll explain why: * because of how some (common) brands implemented CEC in their TVs, this implementation will not work, as the TV will just reject it. In libCEC, we've created work arounds for brands like this. Without these work arounds, your in-kernel implementation will be very vendor specific. e.g. this implementation will work for Samsung's TVs, but not for the TVs made by another big TV brand. All commands, including CEC_OP_ABORT, should be passed to userspace to make it work with all brands. * it should be made possible to not have the kernel send any CEC message, try to process any received CEC message, or ack to any logical address at all, to allow libraries like libCEC to fully handle all CEC traffic. Some brands only enable routing of some CEC keys when a specific device type is used. libCEC will allocate a logical address of the correct type for the brand that's used. If another address is first allocated by the kernel, and the TV communicates with it to find out it's name and things like that, and libCEC allocates another address a bit later when initialised, then you'll end up with multiple entries in the device list on the TV, and only one of them will work. Adding a special mode in the CEC framework that disables parsing and processing seems like a good idea for me. This way libCEC could be completely in charge of how the communication is handled. I discussed this with Hans and he is for this solution. This way there would be two modes: - One with handling of CEC messages enabled in the kernel, in idea behind this is to have processing adhere to the CEC spec as closely as possible. It should work with equipment that also follows the spec and has little vendor specific quirks. - Second, the passthrough mode, in which the handling of CEC messages would be left to userspace application. Kernel would not be sending or receiving messages, unless specifically told to do so. Below you mentioned that allocating logical addresses and sending ACKs could be done in kernel. The way I see it is following: If allocation of a logical address is made then ACKs will be handled by the framework. If no allocation is made then the userspace can still send and receive messages. However no filtering is done based on the logical address - all received messages are sent to the userspace. * CEC is *very* vendor specific. The main reason is, in my opinion, the use of the word should instead of shall in the spec. It's addressed in the new version, but it'll take years before all the non 2.x devices are gone. What works for vendor A will simply not work for vendor B. libCEC aims to address this, in a library that can be used on all major platforms and by all major programming languages. You could duplicate the work done there in the kernel to make make the implementation work with all brands, but I think that this does simply not belong in the kernel when it can be handled in userspace perfectly. CEC being very vendor specific is a huge problem. I agree with you that there is no need to duplicate the effort to mitigate all the vendor quirks. Especially that a working implementation (libCEC) is already done. So I suggest that you limit the in-kernel implementation to handling raw traffic only, to have it do this (and nothing more): * allocate one or more logical addresses, and ack CEC traffic sent to those logical addresses * receive CEC traffic and forward it to userspace (traffic sent to all addresses is preferred, not just traffic sent to the logical address used by the device running this code) * transmit CEC traffic initiated by userspace As mentioned above, I propose a passthorugh mode in which handling of CEC messages by the kernel CEC framework will be very limited. I think that the three functions listed above should be enough. Any comments on this solution? thanks, Lars Op den Kamp Best wishes, -- Kamil Debski Samsung RD Institute Poland On 23-04-15 15:03, Kamil Debski wrote: From: Hans Verkuil hansv...@cisco.com The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup and fixes
RE: [PATCH v4 06/10] cec: add HDMI CEC framework
Hi Hans, Thank you so much for all today's comments. I will consider them when preparing the next version. From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Monday, April 27, 2015 1:27 PM On 04/27/2015 12:25 PM, Hans Verkuil wrote: On 04/23/2015 03:03 PM, Kamil Debski wrote: From: Hans Verkuil hansv...@cisco.com The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup and fixes] [k.deb...@samsung.com: add missing CEC commands to match spec] [k.deb...@samsung.com: add RC framework support] [k.deb...@samsung.com: move and edit documentation] [k.deb...@samsung.com: add vendor id reporting] [k.deb...@samsung.com: add possibility to clear assigned logical addresses] [k.deb...@samsung.com: documentation fixes, clenaup and expansion] [k.deb...@samsung.com: reorder of API structs and add reserved fields] [k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec problem] [k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/cec.txt | 396 drivers/media/Kconfig |6 + drivers/media/Makefile|2 + drivers/media/cec.c | 1161 + include/media/cec.h | 140 ++ include/uapi/linux/Kbuild |1 + include/uapi/linux/cec.h | 303 7 files changed, 2009 insertions(+) create mode 100644 Documentation/cec.txt create mode 100644 drivers/media/cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h + case CEC_S_ADAP_LOG_ADDRS: { + struct cec_log_addrs log_addrs; + + if (!(adap-capabilities CEC_CAP_LOG_ADDRS)) + return -ENOTTY; + if (copy_from_user(log_addrs, parg, sizeof(log_addrs))) + return -EFAULT; + err = cec_claim_log_addrs(adap, log_addrs, true); Currently CEC_S_ADAP_LOG_ADDRS is always blocking, but since we have CEC_EVENT_READY I think it makes sense to just return in non-blocking mode and have cec_claim_log_addrs generate CEC_EVENT_READY when done. Userspace can then call G_ADAP_LOG_ADDRS to discover the result. What do you think? I am looking into this now. If I see this correctly this involves: - adding cec_post_event(cla_int-adap, CEC_EVENT_READY); to cec_config_thread_func - adding O_NONBLOCK check in CEC_S_ADAP_LOG_ADDRS Right? On a related topic: non-blocking behavior for CEC_RECEIVE is well defined, but for CEC_TRA NSMIT it isn't. If reply == 0, then we need a way to inform userspace that the transmit finished (with a possible non-zero status code). An event would be suitable for that, but we would need a way to associate a transmit message with the event. One possibility might be to have the CEC framework assign a sequence number to a transmit message which is returned by CEC_TRANSMIT and used in the event. If reply != 0, then I think the received message should be queued up in the receive queue, but with a non-zero reply field and with the sequence number of the transmit message it is a reply of. A sequence number is a good solution, I believe. To recap: - a sequence number should be set by the framework and returned in the CEC_TRANSMIT ioctl - a new event should be added CEC_EVENT_TX_DONE and it should be posted on each transmission finish - event struct has to include a sequence field as well Is this ok? Regards, Hans Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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 v4 00/10] HDMI CEC framework
Hi, This is the fourth version of the HDMI CEC framework. I would like to thank for all the comments and suggestions to the previous versions of this patch. I believe that the code has matured enough to be tagged as PATCH and not RFC as in previous version. This patchset is base on the linux-next tree. I believe that there will be some comments to it and there will be some things to fix, hence I am sending this version now. The next version with appropriate fixes will be based on the next RC (which I guess will be released soon). The promiscuous mode included in the previous version caused some discussion and I decided to drop it. In my opinion it can be useful for debugging, but on the other hand I believe it can be easily added at a later time, if appropriate. Best wishes, Kamil Debski Changes since v3 - remove the promiscuous mode - rewrite the devicetree patches - fixes, expansion and partial rewrite of the documentation - reorder of API structures and addition of reserved fields - use own struct to report time (32/64 bit safe) - fix of handling events - add cec.h to include/uapi/linux/Kbuild - fixes in the adv76xx driver (add missing methods, change adv7604 to adv76xx) - cleanup of debug messages in s5p-cec driver - remove non necessary claiming of a gpio in the s5p-cec driver - cleanup headers of the s5p-cec driver Changes since v2 ===- - added promiscuous mode - added new key codes to the input framework - add vendor ID reporting - add the possibility to clear assigned logical addresses - cleanup of the rc cec map Changes since v1 - documentation edited and moved to the Documentation folder - added key up/down message handling - add missing CEC commands to the cec.h file Original cover letter = Hi, The work on a common CEC framework was started over three years ago by Hans Verkuil. Unfortunately the work has stalled. As I have received the task of creating a driver for the CEC interface module present on the Exynos range of SoCs, I got in touch with Hans. He replied that the work stalled due to his lack of time. The driver was done in the most part and there were only minor fixes that needed to be implemented. I would like to bring back the discussion on a common CEC interface framework. There are a few things that were still left as TODO, I think they might need some discussion - for instance the way how the remote controls should be handled. Best wishes, Kamil Debski Original RFC by Hans Verkuil/Martin Bugge = https://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html Hans Verkuil (4): cec: add HDMI CEC framework v4l2-subdev: add HDMI CEC ops cec: adv7604: add cec support. cec: adv7511: add cec support. Kamil Debski (6): dts: exynos4*: add HDMI CEC pin definition to pinctrl dts: exynos4: add node for the HDMI CEC device dts: exynos4412-odroid*: enable the HDMI CEC device HID: add HDMI CEC specific keycodes rc: Add HDMI CEC protoctol handling cec: s5p-cec: Add s5p-cec driver Documentation/cec.txt | 396 +++ .../devicetree/bindings/media/s5p-cec.txt | 33 + arch/arm/boot/dts/exynos4.dtsi | 12 + arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos4412-odroid-common.dtsi|4 + arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 + drivers/media/Kconfig |6 + drivers/media/Makefile |2 + drivers/media/cec.c| 1161 drivers/media/i2c/adv7511.c| 347 +- drivers/media/i2c/adv7604.c| 207 +++- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|1 + drivers/media/platform/s5p-cec/Makefile|4 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 37 + .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 drivers/media/platform/s5p-cec/regs-cec.h | 96 ++ drivers/media/platform/s5p-cec/s5p_cec.c | 283 + drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++ drivers/media/rc/keymaps/Makefile |1 + drivers/media/rc/keymaps/rc-cec.c | 144 +++ drivers/media/rc/rc-main.c |1 + include/media/adv7511.h|6 +- include/media/cec.h| 140 +++ include/media/rc-core.h|1 + include/media/rc-map.h |5 +- include/media/v4l2-subdev.h|8 + include/uapi/linux/Kbuild |1 + include/uapi/linux/cec.h | 303 + include/uapi/linux/input.h | 12 + 30 files changed, 3507
[PATCH v4 02/10] dts: exynos4: add node for the HDMI CEC device
This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index e20cdc2..8776db9 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -704,6 +704,18 @@ status = disabled; }; + hdmicec: cec@100B { + compatible = samsung,s5p-cec; + reg = 0x100B 0x200; + interrupts = 0 114 0; + clocks = clock CLK_HDMI_CEC; + clock-names = hdmicec; + samsung,syscon-phandle = pmu_system_controller; + pinctrl-names = default; + pinctrl-0 = hdmi_cec; + status = disabled; + }; + mixer: mixer@12C1 { compatible = samsung,exynos4210-mixer; interrupts = 0 91 0; -- 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 v4 01/10] dts: exynos4*: add HDMI CEC pin definition to pinctrl
Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and Exynos4x12 SoCs. These are required by the HDMI CEC device. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 +++ arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 +++ 2 files changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi index a7c2128..9331c62 100644 --- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi @@ -820,6 +820,13 @@ samsung,pin-pud = 1; samsung,pin-drv = 0; }; + + hdmi_cec: hdmi-cec { + samsung,pins = gpx3-6; + samsung,pin-function = 3; + samsung,pin-pud = 0; + samsung,pin-drv = 0; + }; }; pinctrl@0386 { diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi index c141931..875464e 100644 --- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi +++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi @@ -885,6 +885,13 @@ samsung,pin-pud = 0; samsung,pin-drv = 0; }; + + hdmi_cec: hdmi-cec { + samsung,pins = gpx3-6; + samsung,pin-function = 3; + samsung,pin-pud = 0; + samsung,pin-drv = 0; + }; }; pinctrl@0386 { -- 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 v4 03/10] dts: exynos4412-odroid*: enable the HDMI CEC device
Add a dts node entry and enable the HDMI CEC device present in the Exynos4 family of SoCs. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4412-odroid-common.dtsi |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi index 8de12af..e50862d 100644 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi @@ -469,6 +469,10 @@ status = okay; }; + cec@100B { + status = okay; + }; + hdmi_ddc: i2c@1388 { status = okay; pinctrl-names = default; -- 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 v4 09/10] cec: adv7511: add cec support.
From: Hans Verkuil hansv...@cisco.com Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/i2c/adv7511.c | 347 ++- include/media/adv7511.h |6 +- 2 files changed, 343 insertions(+), 10 deletions(-) diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 12d9320..d56e110 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -33,6 +33,7 @@ #include media/v4l2-ctrls.h #include media/v4l2-dv-timings.h #include media/adv7511.h +#include media/cec.h static int debug; module_param(debug, int, 0644); @@ -91,6 +92,12 @@ struct adv7511_state { int chip_revision; uint8_t i2c_edid_addr; uint8_t i2c_cec_addr; + + struct i2c_client *i2c_cec; + u8 cec_addr[3]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + /* Is the adv7511 powered on? */ bool power_on; /* Did we receive hotplug and rx-sense signals? */ @@ -222,7 +229,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client *client, return ret; } -static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) +static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) { struct adv7511_state *state = get_adv7511_state(sd); int i; @@ -237,6 +244,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t v4l2_err(sd, %s: i2c read error\n, __func__); } +static inline int cec_read(struct v4l2_subdev *sd, u8 reg) +{ + struct adv7511_state *state = get_adv7511_state(sd); + + return i2c_smbus_read_byte_data(state-i2c_cec, reg); +} + +static int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) +{ + struct adv7511_state *state = get_adv7511_state(sd); + int ret; + int i; + + for (i = 0; i 3; i++) { + ret = i2c_smbus_write_byte_data(state-i2c_cec, reg, val); + if (ret == 0) + return 0; + } + v4l2_err(sd, %s: I2C Write Problem\n, __func__); + return ret; +} + +static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) mask) | val); +} + static inline bool adv7511_have_hotplug(struct v4l2_subdev *sd) { return adv7511_rd(sd, 0x42) MASK_ADV7511_HPD_DETECT; @@ -381,16 +416,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = { #ifdef CONFIG_VIDEO_ADV_DEBUG static void adv7511_inv_register(struct v4l2_subdev *sd) { + struct adv7511_state *state = get_adv7511_state(sd); + v4l2_info(sd, 0x000-0x0ff: Main Map\n); + if (state-i2c_cec) + v4l2_info(sd, 0x100-0x1ff: CEC Map\n); } static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + reg-size = 1; switch (reg-reg 8) { case 0: reg-val = adv7511_rd(sd, reg-reg 0xff); break; + case 1: + if (state-i2c_cec) { + reg-val = cec_read(sd, reg-reg 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, Register %03llx not supported\n, reg-reg); adv7511_inv_register(sd); @@ -401,10 +448,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register * static int adv7511_s_register(struct v4l2_subdev *sd, const struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + switch (reg-reg 8) { case 0: adv7511_wr(sd, reg-reg 0xff, reg-val 0xff); break; + case 1: + if (state-i2c_cec) { + cec_write(sd, reg-reg 0xff, reg-val 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, Register %03llx not supported\n, reg-reg); adv7511_inv_register(sd); @@ -418,6 +473,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd) { struct adv7511_state *state = get_adv7511_state(sd); struct adv7511_state_edid *edid = state-edid; + int i; static const char * const states[] = { in reset, @@ -486,7 +542,21 @@ static int adv7511_log_status(struct v4l2_subdev *sd) else v4l2_info(sd, no timings set\n); v4l2_info(sd, i2c edid addr: 0x%x\n, state-i2c_edid_addr); + + if (state-i2c_cec == NULL) + return 0; + v4l2_info(sd, i2c cec addr: 0x%x\n, state-i2c_cec_addr
[PATCH v4 06/10] cec: add HDMI CEC framework
From: Hans Verkuil hansv...@cisco.com The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup and fixes] [k.deb...@samsung.com: add missing CEC commands to match spec] [k.deb...@samsung.com: add RC framework support] [k.deb...@samsung.com: move and edit documentation] [k.deb...@samsung.com: add vendor id reporting] [k.deb...@samsung.com: add possibility to clear assigned logical addresses] [k.deb...@samsung.com: documentation fixes, clenaup and expansion] [k.deb...@samsung.com: reorder of API structs and add reserved fields] [k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec problem] [k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/cec.txt | 396 drivers/media/Kconfig |6 + drivers/media/Makefile|2 + drivers/media/cec.c | 1161 + include/media/cec.h | 140 ++ include/uapi/linux/Kbuild |1 + include/uapi/linux/cec.h | 303 7 files changed, 2009 insertions(+) create mode 100644 Documentation/cec.txt create mode 100644 drivers/media/cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..2b6c08a --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,396 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple variants of hardware. Adding to +the flexibility of the framework it enables to set which parts of the CEC +protocol processing is handled by the hardware, by the driver and by the +userspace application. + + +The CEC Protocol + + +The CEC protocol enables consumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physical address is determined by the physical +connection between devices. + +The protocol enables control of compatible devices with a single remote. +Synchronous power on/standby, instant playback with changing the content source +on the TV. + +The Kernel Interface + + +CEC Adapter +--- + +#define CEC_LOG_ADDR_INVALID 0xff + +/* The maximum number of logical addresses one device can be assigned to. + * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The + * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */ +#define CEC_MAX_LOG_ADDRS 4 + +/* The Primary Device Type */ +#define CEC_PRIM_DEVTYPE_TV0 +#define CEC_PRIM_DEVTYPE_RECORD1 +#define CEC_PRIM_DEVTYPE_TUNER 3 +#define CEC_PRIM_DEVTYPE_PLAYBACK 4 +#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5 +#define CEC_PRIM_DEVTYPE_SWITCH6 +#define CEC_PRIM_DEVTYPE_VIDEOPROC 7 + +/* The All Device Types flags (CEC 2.0) */ +#define CEC_FL_ALL_DEVTYPE_TV (1 7) +#define CEC_FL_ALL_DEVTYPE_RECORD (1 6) +#define CEC_FL_ALL_DEVTYPE_TUNER (1 5) +#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 4) +#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3) +#define CEC_FL_ALL_DEVTYPE_SWITCH (1 2) +/* And if you wondering what happened to VIDEOPROC devices: those should + * be mapped to a SWITCH. */ + +/* The logical address types that the CEC device wants to claim */ +#define CEC_LOG_ADDR_TYPE_TV 0 +#define CEC_LOG_ADDR_TYPE_RECORD 1 +#define CEC_LOG_ADDR_TYPE_TUNER2 +#define CEC_LOG_ADDR_TYPE_PLAYBACK 3 +#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4 +#define CEC_LOG_ADDR_TYPE_SPECIFIC 5 +#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6 +/* Switches should use UNREGISTERED. + * Video processors should use SPECIFIC. */ + +/* The CEC version */ +#define CEC_VERSION_1_4B 5 +#define CEC_VERSION_2_06 + +struct cec_adapter { + /* internal fields removed */ + + u16 phys_addr; + u32 capabilities; + u8 version; + u8 num_log_addrs; + u8 prim_device[CEC_MAX_LOG_ADDRS]; + u8 log_addr_type[CEC_MAX_LOG_ADDRS]; + u8 log_addr[CEC_MAX_LOG_ADDRS]; + + int (*adap_enable)(struct cec_adapter *adap, bool enable); + int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); + int (*adap_transmit)(struct cec_adapter *adap, struct cec_msg *msg); + void
[PATCH v4 07/10] v4l2-subdev: add HDMI CEC ops
From: Hans Verkuil hansv...@cisco.com Add callbacks to the v4l2_subdev_video_ops. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- include/media/v4l2-subdev.h |8 1 file changed, 8 insertions(+) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index 2f0a345..9323e10 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -40,6 +40,9 @@ #define V4L2_SUBDEV_IR_TX_NOTIFY _IOW('v', 1, u32) #define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001 +#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 2, u32) +#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 3, struct cec_msg) + struct v4l2_device; struct v4l2_ctrl_handler; struct v4l2_event_subscription; @@ -48,6 +51,7 @@ struct v4l2_subdev; struct v4l2_subdev_fh; struct tuner_setup; struct v4l2_mbus_frame_desc; +struct cec_msg; /* decode_vbi_line */ struct v4l2_decode_vbi_line { @@ -352,6 +356,10 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg); int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf, unsigned int *size); + int (*cec_enable)(struct v4l2_subdev *sd, bool enable); + int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr); + int (*cec_transmit)(struct v4l2_subdev *sd, struct cec_msg *msg); + void (*cec_transmit_timed_out)(struct v4l2_subdev *sd); }; /* -- 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 v4 05/10] rc: Add HDMI CEC protoctol handling
Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/rc/keymaps/Makefile |1 + drivers/media/rc/keymaps/rc-cec.c | 144 + drivers/media/rc/rc-main.c|1 + include/media/rc-core.h |1 + include/media/rc-map.h|5 +- 5 files changed, 151 insertions(+), 1 deletion(-) create mode 100644 drivers/media/rc/keymaps/rc-cec.c diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile index abf6079..56f10d6 100644 --- a/drivers/media/rc/keymaps/Makefile +++ b/drivers/media/rc/keymaps/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \ rc-behold.o \ rc-behold-columbus.o \ rc-budget-ci-old.o \ + rc-cec.o \ rc-cinergy-1400.o \ rc-cinergy.o \ rc-delock-61959.o \ diff --git a/drivers/media/rc/keymaps/rc-cec.c b/drivers/media/rc/keymaps/rc-cec.c new file mode 100644 index 000..cc5b318 --- /dev/null +++ b/drivers/media/rc/keymaps/rc-cec.c @@ -0,0 +1,144 @@ +/* Keytable for the CEC remote control + * + * Copyright (c) 2015 by Kamil Debski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include media/rc-map.h +#include linux/module.h + +/* CEC Spec High-Definition Multimedia Interface Specification can be obtained + * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf + * The list of control codes is listed in Table 27: User Control Codes p. 95 */ + +static struct rc_map_table cec[] = { + { 0x00, KEY_OK }, + { 0x01, KEY_UP }, + { 0x02, KEY_DOWN }, + { 0x03, KEY_LEFT }, + { 0x04, KEY_RIGHT }, + { 0x05, KEY_RIGHT_UP }, + { 0x06, KEY_RIGHT_DOWN }, + { 0x07, KEY_LEFT_UP }, + { 0x08, KEY_LEFT_DOWN }, + { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */ + /* Note 2: This is the initial display that a device shows. It is +* device-dependent and can be, for example, a contents menu, setup +* menu, favorite menu or other menu. The actual menu displayed +* may also depend on the device’s current state. */ + { 0x0a, KEY_SETUP }, + { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */ + { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */ + { 0x0d, KEY_EXIT }, + /* 0x0e-0x1f: Reserved */ + /* 0x20-0x29: Keys 0 to 9 */ + { 0x20, KEY_NUMERIC_0 }, + { 0x21, KEY_NUMERIC_1 }, + { 0x22, KEY_NUMERIC_2 }, + { 0x23, KEY_NUMERIC_3 }, + { 0x24, KEY_NUMERIC_4 }, + { 0x25, KEY_NUMERIC_5 }, + { 0x26, KEY_NUMERIC_6 }, + { 0x27, KEY_NUMERIC_7 }, + { 0x28, KEY_NUMERIC_8 }, + { 0x29, KEY_NUMERIC_9 }, + { 0x2a, KEY_DOT }, + { 0x2b, KEY_ENTER }, + { 0x2c, KEY_CLEAR }, + /* 0x2d-0x2e: Reserved */ + { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */ + { 0x30, KEY_CHANNELUP }, + { 0x31, KEY_CHANNELDOWN }, + { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */ + { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */ + { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */ + { 0x35, KEY_INFO }, /* CEC Spec: Display Information */ + { 0x36, KEY_HELP }, + { 0x37, KEY_PAGEUP }, + { 0x38, KEY_PAGEDOWN }, + /* 0x39-0x3f: Reserved */ + { 0x40, KEY_POWER }, + { 0x41, KEY_VOLUMEUP }, + { 0x42, KEY_VOLUMEDOWN }, + { 0x43, KEY_MUTE }, + { 0x44, KEY_PLAY }, + { 0x45, KEY_STOP }, + { 0x46, KEY_PAUSE }, + { 0x47, KEY_RECORD }, + { 0x48, KEY_REWIND }, + { 0x49, KEY_FASTFORWARD }, + { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */ + { 0x4b, KEY_FORWARD }, + { 0x4c, KEY_BACK }, + { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */ + { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */ + /* 0x4f: Reserved */ + { 0x50, KEY_ANGLE }, + { 0x51, KEY_TV2 }, + { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */ + { 0x53, KEY_EPG }, + { 0x54, KEY_TIME }, /* CEC Spec: Timer */ + { 0x55, KEY_CONFIG }, + /* 0x56-0x5f: Reserved */ + { 0x60, KEY_PLAY }, /* CEC Spec: Play Function */ + { 0x6024, KEY_PLAY }, + { 0x6020, KEY_PAUSE }, + { 0x61, KEY_PLAYPAUSE }, /* CEC Spec: Pause-Play Function */ + { 0x62, KEY_RECORD }, /* Spec: Record Function */ + { 0x63, KEY_PAUSE
[PATCH v4 04/10] HID: add HDMI CEC specific keycodes
Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski k.deb...@samsung.com --- include/uapi/linux/input.h | 12 1 file changed, 12 insertions(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 731417c..7430a3f 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -752,6 +752,18 @@ struct input_keymap_entry { #define KEY_KBDINPUTASSIST_ACCEPT 0x264 #define KEY_KBDINPUTASSIST_CANCEL 0x265 +#define KEY_RIGHT_UP 0x266 +#define KEY_RIGHT_DOWN 0x267 +#define KEY_LEFT_UP0x268 +#define KEY_LEFT_DOWN 0x269 + +#define KEY_NEXT_FAVORITE 0x270 +#define KEY_STOP_RECORD0x271 +#define KEY_PAUSE_RECORD 0x272 +#define KEY_VOD0x273 +#define KEY_UNMUTE 0x274 +#define KEY_DVB0x275 + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 -- 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 v4 08/10] cec: adv7604: add cec support.
From: Hans Verkuil hansv...@cisco.com Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: add missing methods cec/io_write_and_or] [k.deb...@samsung.com: change adv7604 to adv76xx in added functions] Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/i2c/adv7604.c | 207 ++- 1 file changed, 206 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 60ffcf0..4921276 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -38,6 +38,7 @@ #include linux/workqueue.h #include media/adv7604.h +#include media/cec.h #include media/v4l2-ctrls.h #include media/v4l2-device.h #include media/v4l2-dv-timings.h @@ -77,6 +78,8 @@ MODULE_LICENSE(GPL); #define ADV76XX_OP_SWAP_CB_CR (1 0) +#define ADV76XX_MAX_ADDRS (3) + enum adv76xx_type { ADV7604, ADV7611, @@ -159,6 +162,10 @@ struct adv76xx_state { u16 spa_port_a[2]; struct v4l2_fract aspect_ratio; u32 rgb_quantization_range; + u8 cec_addr[ADV76XX_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + struct workqueue_struct *work_queues; struct delayed_work delayed_work_enable_hotplug; bool restart_stdi_once; @@ -424,7 +431,15 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, u8 val) return adv_smbus_write_byte_data(state, ADV76XX_PAGE_IO, reg, val); } -static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) +static inline int io_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return io_write(sd, reg, (io_read(sd, reg) mask) | val); +} + + +static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) { return io_write(sd, reg, (io_read(sd, reg) ~mask) | val); } @@ -457,6 +472,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) return adv_smbus_write_byte_data(state, ADV76XX_PAGE_CEC, reg, val); } +static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) mask) | val); +} + static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg) { struct adv76xx_state *state = to_state(sd); @@ -1865,6 +1886,183 @@ static int adv76xx_set_format(struct v4l2_subdev *sd, return 0; } +static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status) +{ + if ((cec_read(sd, 0x11) 0x01) == 0) { + v4l2_dbg(1, debug, sd, %s: tx raw: tx disabled\n, __func__); + return; + } + + if (tx_raw_status 0x02) { + v4l2_dbg(1, debug, sd, %s: tx raw: arbitration lost\n, +__func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_ARB_LOST); + return; + } + if (tx_raw_status 0x04) { + v4l2_dbg(1, debug, sd, %s: tx raw: retry failed\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_RETRY_TIMEOUT); + return; + } + if (tx_raw_status 0x01) { + v4l2_dbg(1, debug, sd, %s: tx raw: ready ok\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, + (void *)CEC_TX_STATUS_OK); + return; + } +} + +static void adv76xx_cec_isr(struct v4l2_subdev *sd, bool *handled) +{ + struct cec_msg msg; + u8 cec_irq; + + /* cec controller */ + cec_irq = io_read(sd, 0x4d) 0x0f; + if (!cec_irq) + return; + + v4l2_dbg(1, debug, sd, %s: cec: irq 0x%x\n, __func__, cec_irq); + adv76xx_cec_tx_raw_status(sd, cec_irq); + if (cec_irq 0x08) { + msg.len = cec_read(sd, 0x25) 0x1f; + if (msg.len 16) + msg.len = 16; + + if (msg.len) { + u8 i; + + for (i = 0; i msg.len; i++) + msg.msg[i] = cec_read(sd, i + 0x15); + cec_write(sd, 0x26, 0x01); /* re-enable rx */ + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, msg); + } + } + + /* note: the bit order is swapped between 0x4d and 0x4e */ + cec_irq = ((cec_irq 0x08) 3) | ((cec_irq 0x04) 1) | + ((cec_irq 0x02) 1) | ((cec_irq 0x01) 3); + io_write(sd, 0x4e, cec_irq); + + if (handled) + *handled = true; +} + +static int
RE: [RFC v3 5/9] cec: add new driver for cec support.
Hi Hans, From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Friday, April 17, 2015 2:17 PM On 04/13/2015 03:19 PM, Kamil Debski wrote: Hi Hans, Thank you so much for the review. From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Friday, March 20, 2015 7:08 PM snip +In order for a CEC adapter to be configured it needs a physical address. +This is normally assigned by the driver. It is either 0.0.0.0 for a TV (aka +video receiver) or it is derived from the EDID that the source received +from the sink. This is normally set by the driver before enabling the CEC +adapter, or it is set from userspace in the case of CEC USB dongles (although +embedded systems might also want to set this manually). I would actually expect that USB dongles read out the EDID from the source. I might be wrong, though. EDID is communicated to the device by the TV on a different bus than CEC, it is DDC. It is possible that the dongle also reads DDC messages. My initial understanding was that a CEC USB dongle handles only CEC messages and is passing through all other signals, such as DDC. I checked against the libcec code (see link here: http://libcec.pulse- eight.com/) for my usb-cec dongle and it turns out the library reads out the edid from the monitor using xrandr (I think, see src/libcec/platform/X11/randr-edid.cpp) in order to get the physical address. So it is not using the dongle itself for that. Makes sense. + +After enabling the CEC adapter it has to be configured. The CEC adapter has +to be informed for which CEC device types a logical address has to be found. I would say: 'a free (unused) logical address'. +The CEC framework will attempt to find such logical addresses. If none are And here: 'find and claim' +found, then it will fall back to logical address Unregistered (15). You probably need to add some documentation regarding cec_claim_log_addrs() and how drivers can use it. Also, while logical addresses are being claimed, are drivers or userspace allowed to transmit/receive other messages? Or just stall until this is finished? When sending a message the user space is free to set any source and destination address. Hence, I see no need to wait until the logical address is claimed. If the user space is not waiting until the address and is sending messages, then I guess it is done with full responsibility on the user space. Regarding receiving, I guess it should be possible to receive broadcast messages. What do you think? Fair enough, it just needs to be documented. Ok, will do. snip +Promiscuous mode + + +The promiscuous mode enables the userspace applications to read all +messages on the CEC bus. This is similar to the promiscuous mode in +network devices. In the normal mode messages not directed to the device +(differentiated by the logical address of the CEC device) are not +forwarded to the userspace. Same rule applies to the messages contailning +remote control key codes. When promiscuous mode is enabled all messages +can be read by userspace. Processing of the messages is still done, thus +key codes will be both interpreted by the framework and available +as an +input device, but also raw messages containing these codes are sent to +the userspace. Will messages that are processed by the driver or cec framework also be relayed to userspace in promiscuous mode? Will userspace be able to tell that it has been processed already? All messages will be relayed to the user space and no there is no possibility to check whether the message was processed by the kernel already. Should we add that? To be honest, I'm not sure about that myself. The promiscuous mode is useful mainly for debug reasons. I would leave it, however it is not a deal breaker for me. It could be added at a later time. Once thing I notice is that there are no reserved fields at the end of struct cec_msg. We should add that. Same with the other structs. It served us well with v4l2, and we should do the same with the cec API. This is indeed a good idea. Thanks :) Another upcoming problem is the use of struct timespec: this will have to change in the near future to one that is year 2038-safe. Unfortunately, there is no public 'struct timespec64' type yet. This mailinglist might provide answers w.r.t. the precise plans with timespec: http://lwn.net/Articles/640284/ Also, we don't have 32-bit compat code for CEC. I wonder if it is a good idea to improve the layout of the structs to minimize 64/32-bit layout differences. I never paid attention to that when I made these structs as I always planned to do that at the end. It's good that you mentioned this, will do. Regards
RE: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi, From: Philipp Zabel [mailto:p.za...@pengutronix.de] Sent: Monday, April 20, 2015 10:28 AM To: Kamil Debski Cc: 'Pawel Osciak'; 'LMML'; 'Hans Verkuil'; 'Laurent Pinchart'; 'Nicolas Dufresne'; 'Sakari Ailus'; ker...@pengutronix.de Subject: Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer Am Donnerstag, den 16.04.2015, 10:23 +0200 schrieb Kamil Debski: [...] But, in general, in what kind of scenario would the driver want to call this function, as opposed to vb2 clearing this flag by itself on STREAMOFF? There is VIDIOC_DECODER_CMD / V4L2_DEC_CMD_START. I'd expect this timeline for decoder draining and restart: - userspace calls VIDIOC_DECODER_CMD, cmd=V4L2_DEC_CMD_STOP after queueing the last output buffer to be decoded - the driver processes remaining output buffers into capture buffers and sets the V4L2_BUF_FLAG_LAST set on the last capture Buffet I would like to confirm that it will work with MFC. Am I right that the below will work? Did you take that into account? I see no reason why it wouldn't. The only difference is that userspace has to be able to handle the empty frame. I just checked the notes from the codec meeting in Dusseldorf. When we talked about the draining flow, we agreed to mention in the documentation that a buffer with the V4L2_BUF_FLAG_LAST can be empty. Thus the userspace applications should check the size of last frame. Could you please add that the last buffer can be empty (zero size) in the DocBook patch? So in MFC's case the V4L2_BUF_FLAG_LAST will be set on the one buffer after the last one and the bytesused of that buffer would be set to 0. The problem of MFC is that it will signal that the last frame was decoded after it was decoded. To particularize: - a frame is decoded, an irq is sent by MFC - we have a new decoded picture - next an irq is sent with an internal MFC flag that the buffer is empty (last picture was already decoded) Doesn't MFC userspace currently stop on the empty frame? That empty frame will still be dequeued as before, the only difference is the added V4L2_BUF_FLAG_LAST on it, and that subsequent calls to DQBUF would return -EPIPE. Ok, I see this. regards Philipp Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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 v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Hi, From: Philipp Zabel [mailto:p.za...@pengutronix.de] Sent: Monday, April 13, 2015 6:15 PM To: Pawel Osciak Cc: LMML; Hans Verkuil; Kamil Debski; Laurent Pinchart; Nicolas Dufresne; Sakari Ailus; ker...@pengutronix.de Subject: Re: [PATCH v4 2/4] [media] videobuf2: return -EPIPE from DQBUF after the last buffer Hi Pawel, thanks for the review! Am Montag, den 13.04.2015, 15:30 +0900 schrieb Pawel Osciak: Hi, On Wed, Mar 25, 2015 at 2:46 AM, Philipp Zabel p.za...@pengutronix.de wrote: If the last buffer was dequeued from a capture queue, let poll return immediately and let DQBUF return -EPIPE to signal there will no more buffers to dequeue until STREAMOFF. The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST. To reenable dequeuing on the capture queue, the driver must explicitly call vb2_clear_last_buffer_queued. The last buffer queued flag is cleared automatically during STREAMOFF. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- Changes since v3: - Added DocBook update mentioning DQBUF returning -EPIPE in the encoder/decoder stop command documentation. --- Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 4 +++- Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 4 +++- Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8 drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +- drivers/media/v4l2-core/videobuf2-core.c | 18 +- include/media/videobuf2-core.h | 10 ++ 6 files changed, 50 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml Would it make sense to perhaps split this patch into docbook and vb2 changes please? Alright, I'll split DocBook from vb2 changes, with the documentation patches first. diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c index 80c588f..1b5b432 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, if (list_empty(src_q-done_list)) poll_wait(file, src_q-done_wq, wait); - if (list_empty(dst_q-done_list)) + if (list_empty(dst_q-done_list)) { + /* +* If the last buffer was dequeued from the capture queue, +* return immediately. DQBUF will return -EPIPE. +*/ + if (dst_q-last_buffer_dequeued) + return rc | POLLIN | POLLRDNORM; These indicate there is data to be read. Is there something else we could return? Maybe POLLHUP? This is a good point, but I'm not sure. POLLHUP seems to mean a similar thing, yet not quite the same. The documentation explicitly mentions disconnected devices or FIFOs without writers, neither of which applies. Also a FIFO signals POLLHUP when the last writer leaves, so we would probably have to signal POLLHUP|POLLIN after the last buffer was decoded for consistency, and keep that until the last buffer is dequeued. Then we could signal POLLHUP alone here. I didn't want to risk redefining/misinterpreting any poll(2) behavior, so my interpretation was that POLLIN signals userspace to try a DQBUF, as usual. + poll_wait(file, dst_q-done_wq, wait); + } if (m2m_ctx-m2m_dev-m2m_ops-lock) m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv); diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index bc08a82..a0b9946 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2046,6 +2046,10 @@ static int vb2_internal_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool n struct vb2_buffer *vb = NULL; int ret; + if (q-last_buffer_dequeued) { + dprintk(3, last buffer dequeued already\n); + return -EPIPE; + } This should go after the check for queue type at least. However, best probably to __vb2_wait_for_done_vb(), where we already have the checks for q-streaming and q-error. Yes, that'll be better. if (b-type != q-type) { dprintk(1, invalid buffer type\n); return -EINVAL; [...] @@ -2628,8 +2636,16 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait) if (V4L2_TYPE_IS_OUTPUT(q-type) q-queued_count q- num_buffers) return res | POLLOUT | POLLWRNORM; - if (list_empty(q-done_list)) + if (list_empty(q-done_list
RE: [RFC v3 5/9] cec: add new driver for cec support.
Hi Hans, Thank you so much for the review. From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Friday, March 20, 2015 7:08 PM Hi Kamil, Once again thank you for continuing this work! I do have some comments, see below. On 03/20/2015 05:52 PM, Kamil Debski wrote: Add the CEC framework. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup and fixes] [k.deb...@samsung.com: add missing CEC commands to match spec] [k.deb...@samsung.com: add RC framework support] [k.deb...@samsung.com: move and edit documentation] [k.deb...@samsung.com: add vendor id reporting] [k.deb...@samsung.com: add promiscuous mode] [k.deb...@samsung.com: add possibility to clear assigned logical addresses] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/cec.txt| 321 + drivers/media/Kconfig|6 + drivers/media/Makefile |2 + drivers/media/cec.c | 1158 ++ include/media/cec.h | 137 ++ include/uapi/linux/cec.h | 283 +++ 6 files changed, 1907 insertions(+) create mode 100644 Documentation/cec.txt create mode 100644 drivers/media/cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..e96fcc0 --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,321 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple variants of hardware. Adding to +the flexibility of the framework it enables to set which parts of the CEC +protocol processing is handled by the hardware, by the driver and by the +userspace application. + + +The CEC Protocol + + +The CEC protocol enables cosumer electronic devices to communicate with each cosumer - consumer +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physicall addressis determined by physical connection 'physicall addressis' - 'physical address is' s/by/by the/ +between devices. + +The protocol enables control of compatible devices with a single remote. +Synchronous power on/standby, instant playback with changing the content source +on the TV. + +The Kernel Interface + + +CEC Adaptor s/Adaptor/Adapter/ +--- + +#define CEC_LOG_ADDR_INVALID 0xff + +/* The maximum number of logical addresses one device can be assigned to. + * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The + * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */ +#define CEC_MAX_LOG_ADDRS 4 + +/* The Primary Device Type */ +#define CEC_PRIM_DEVTYPE_TV0 +#define CEC_PRIM_DEVTYPE_RECORD1 +#define CEC_PRIM_DEVTYPE_TUNER 3 +#define CEC_PRIM_DEVTYPE_PLAYBACK 4 +#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5 +#define CEC_PRIM_DEVTYPE_SWITCH6 +#define CEC_PRIM_DEVTYPE_VIDEOPROC 7 + +/* The All Device Types flags (CEC 2.0) */ +#define CEC_FL_ALL_DEVTYPE_TV (1 7) +#define CEC_FL_ALL_DEVTYPE_RECORD (1 6) +#define CEC_FL_ALL_DEVTYPE_TUNER (1 5) +#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 4) +#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3) +#define CEC_FL_ALL_DEVTYPE_SWITCH (1 2) +/* And if you wondering what happened to VIDEOPROC devices: those should + * be mapped to a SWITCH. */ + +/* The logical address types that the CEC device wants to claim */ +#define CEC_LOG_ADDR_TYPE_TV 0 +#define CEC_LOG_ADDR_TYPE_RECORD 1 +#define CEC_LOG_ADDR_TYPE_TUNER2 +#define CEC_LOG_ADDR_TYPE_PLAYBACK 3 +#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4 +#define CEC_LOG_ADDR_TYPE_SPECIFIC 5 +#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6 +/* Switches should use UNREGISTERED. + * Video processors should use SPECIFIC. */ + +/* The CEC version */ +#define CEC_VERSION_1_4B 5 +#define CEC_VERSION_2_06 + +struct cec_adapter { + /* internal fields removed */ + + u16 phys_addr; + u32 capabilities; + u8 version; + u8 num_log_addrs; + u8 prim_device[CEC_MAX_LOG_ADDRS]; + u8 log_addr_type[CEC_MAX_LOG_ADDRS]; + u8 log_addr
[GIT PULL for 4.1] mem2mem changes for 4.1
The following changes since commit c8c7c44b7cf5ef7163e4bd6aedbdeb6f6031ee3e: [media] s5p-jpeg: Remove some unused functions (2015-04-07 08:15:15 -0300) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git for-4.1-v2 for you to fetch changes up to 8dae02ffa32db8193513ee0a3c6dcd277e653954: coda: Add tracing support (2015-04-08 11:54:12 +0200) Kamil Debski (4): vb2: split the io_flags member of vb2_queue into a bit field vb2: add allow_zero_bytesused flag to the vb2_queue struct coda: set allow_zero_bytesused flag for vb2_queue_init s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init Peter Seiderer (2): coda: check kasprintf return value in coda_open coda: fix double call to debugfs_remove Philipp Zabel (16): v4l2-mem2mem: no need to initialize b in v4l2_m2m_next_buf and v4l2_m2m_buf_remove gpu: ipu-v3: Add missing IDMAC channel names gpu: ipu-v3: Add mem2mem image conversion support to IC gpu: ipu-v3: Register scaler platform device coda: bitrate can only be set in kbps steps coda: bitstream payload is unsigned coda: use strlcpy instead of snprintf coda: allocate per-context buffers from REQBUFS coda: allocate bitstream buffer from REQBUFS, size depends on the format coda: move parameter buffer in together with context buffer allocation coda: remove duplicate error messages for buffer allocations coda: fail to start streaming if userspace set invalid formats coda: call SEQ_END when the first queue is stopped coda: fix fill bitstream errors in nonstreaming case coda: drop dma_sync_single_for_device in coda_bitstream_queue coda: Add tracing support Sascha Hauer (2): imx-ipu: Add ipu media common code imx-ipu: Add i.MX IPUv3 scaler driver drivers/gpu/ipu-v3/ipu-common.c |2 + drivers/gpu/ipu-v3/ipu-ic.c | 787 +++- drivers/media/platform/Kconfig |2 + drivers/media/platform/Makefile |1 + drivers/media/platform/coda/Makefile|2 + drivers/media/platform/coda/coda-bit.c | 205 +-- drivers/media/platform/coda/coda-common.c | 113 ++-- drivers/media/platform/coda/coda-jpeg.c |1 + drivers/media/platform/coda/coda.h | 18 +- drivers/media/platform/coda/trace.h | 203 +++ drivers/media/platform/imx/Kconfig | 11 + drivers/media/platform/imx/Makefile |2 + drivers/media/platform/imx/imx-ipu-scaler.c | 869 +++ drivers/media/platform/imx/imx-ipu.c| 313 ++ drivers/media/platform/imx/imx-ipu.h| 36 ++ drivers/media/platform/s5p-mfc/s5p_mfc.c|7 + drivers/media/v4l2-core/v4l2-mem2mem.c |4 +- drivers/media/v4l2-core/videobuf2-core.c| 56 +- include/media/videobuf2-core.h | 20 +- include/video/imx-ipu-v3.h | 49 +- 20 files changed, 2535 insertions(+), 166 deletions(-) create mode 100644 drivers/media/platform/coda/trace.h create mode 100644 drivers/media/platform/imx/Kconfig create mode 100644 drivers/media/platform/imx/Makefile create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c create mode 100644 drivers/media/platform/imx/imx-ipu.c create mode 100644 drivers/media/platform/imx/imx-ipu.h -- 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 0/5] Signalling last decoded frame by V4L2_BUF_FLAG_LAST and -EPIPE
Hi, From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, March 17, 2015 5:09 PM On 03/17/2015 11:46 AM, Philipp Zabel wrote: Hi, Am Freitag, den 06.03.2015, 11:18 +0100 schrieb Philipp Zabel: At the V4L2 codec API session during ELC-E 2014, we agreed that for the decoder draining flow, after a V4L2_DEC_CMD_STOP decoder command was issued, the last decoded buffer should get dequeued with a V4L2_BUF_FLAG_LAST set. After that, poll should immediately return and all following VIDIOC_DQBUF should return -EPIPE until the stream is stopped or decoding continued via V4L2_DEC_CMD_START. (or STREAMOFF/STREAMON). Changes since v2: - Made V4L2_BUF_FLAG_LAST known to trace events regards Philipp Peter Seiderer (1): [media] videodev2: Add V4L2_BUF_FLAG_LAST Philipp Zabel (4): [media] videobuf2: return -EPIPE from DQBUF after the last buffer [media] coda: Set last buffer flag and fix EOS event [media] s5p-mfc: Set last buffer flag [media] DocBooc: mention mem2mem codecs for encoder/decoder commands Documentation/DocBook/media/v4l/io.xml | 10 .../DocBook/media/v4l/vidioc-decoder-cmd.xml | 6 - .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 5 +++- Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8 +++ drivers/media/platform/coda/coda-bit.c | 4 ++-- drivers/media/platform/coda/coda-common.c | 27 +-- --- drivers/media/platform/coda/coda.h | 3 +++ drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 + drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +++- drivers/media/v4l2-core/videobuf2-core.c | 18 ++- include/media/videobuf2-core.h | 10 include/trace/events/v4l2.h| 3 ++- include/uapi/linux/videodev2.h | 2 ++ 13 files changed, 84 insertions(+), 23 deletions(-) are there any further changes that I should make to this series? I'd like to see some Acks, esp. from Kamil and Pawel. I'll take another look as well, probably on Friday. The patches look good to me, the 4th version is already queued in my tree. However I would like to see your opinion. Especially from you Pawel :) Best wishes, Kamil -- 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 v3 5/9] cec: add new driver for cec support.
Add the CEC framework. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup and fixes] [k.deb...@samsung.com: add missing CEC commands to match spec] [k.deb...@samsung.com: add RC framework support] [k.deb...@samsung.com: move and edit documentation] [k.deb...@samsung.com: add vendor id reporting] [k.deb...@samsung.com: add promiscuous mode] [k.deb...@samsung.com: add possibility to clear assigned logical addresses] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/cec.txt| 321 + drivers/media/Kconfig|6 + drivers/media/Makefile |2 + drivers/media/cec.c | 1158 ++ include/media/cec.h | 137 ++ include/uapi/linux/cec.h | 283 +++ 6 files changed, 1907 insertions(+) create mode 100644 Documentation/cec.txt create mode 100644 drivers/media/cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..e96fcc0 --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,321 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple variants of hardware. Adding to +the flexibility of the framework it enables to set which parts of the CEC +protocol processing is handled by the hardware, by the driver and by the +userspace application. + + +The CEC Protocol + + +The CEC protocol enables cosumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physicall addressis determined by physical connection +between devices. + +The protocol enables control of compatible devices with a single remote. +Synchronous power on/standby, instant playback with changing the content source +on the TV. + +The Kernel Interface + + +CEC Adaptor +--- + +#define CEC_LOG_ADDR_INVALID 0xff + +/* The maximum number of logical addresses one device can be assigned to. + * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The + * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */ +#define CEC_MAX_LOG_ADDRS 4 + +/* The Primary Device Type */ +#define CEC_PRIM_DEVTYPE_TV0 +#define CEC_PRIM_DEVTYPE_RECORD1 +#define CEC_PRIM_DEVTYPE_TUNER 3 +#define CEC_PRIM_DEVTYPE_PLAYBACK 4 +#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5 +#define CEC_PRIM_DEVTYPE_SWITCH6 +#define CEC_PRIM_DEVTYPE_VIDEOPROC 7 + +/* The All Device Types flags (CEC 2.0) */ +#define CEC_FL_ALL_DEVTYPE_TV (1 7) +#define CEC_FL_ALL_DEVTYPE_RECORD (1 6) +#define CEC_FL_ALL_DEVTYPE_TUNER (1 5) +#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 4) +#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3) +#define CEC_FL_ALL_DEVTYPE_SWITCH (1 2) +/* And if you wondering what happened to VIDEOPROC devices: those should + * be mapped to a SWITCH. */ + +/* The logical address types that the CEC device wants to claim */ +#define CEC_LOG_ADDR_TYPE_TV 0 +#define CEC_LOG_ADDR_TYPE_RECORD 1 +#define CEC_LOG_ADDR_TYPE_TUNER2 +#define CEC_LOG_ADDR_TYPE_PLAYBACK 3 +#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4 +#define CEC_LOG_ADDR_TYPE_SPECIFIC 5 +#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6 +/* Switches should use UNREGISTERED. + * Video processors should use SPECIFIC. */ + +/* The CEC version */ +#define CEC_VERSION_1_4B 5 +#define CEC_VERSION_2_06 + +struct cec_adapter { + /* internal fields removed */ + + u16 phys_addr; + u32 capabilities; + u8 version; + u8 num_log_addrs; + u8 prim_device[CEC_MAX_LOG_ADDRS]; + u8 log_addr_type[CEC_MAX_LOG_ADDRS]; + u8 log_addr[CEC_MAX_LOG_ADDRS]; + + int (*adap_enable)(struct cec_adapter *adap, bool enable); + int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); + int (*adap_transmit)(struct cec_adapter *adap, struct cec_msg *msg); + void (*adap_transmit_timed_out)(struct cec_adapter *adap); + + int (*received_tv)(struct cec_adapter *adap, struct cec_msg *msg); + int (*received_record)(struct cec_adapter *adap, struct cec_msg *msg); + int (*received_tuner)(struct cec_adapter *adap, struct cec_msg *msg); + int (*received_playback)(struct cec_adapter *adap, struct cec_msg *msg); + int (*received_audiosystem
[RFC v3 3/9] Input: add key codes specific to the HDMI CEC bus
The HDMI CEC bus allows device to communicate with one another. This includes sending remote control key codes. Some of key codes defined in the CEC standard are not defined in the input.h. This patch adds the key codes that are missing. Signed-off-by: Kamil Debski k.deb...@samsung.com --- include/uapi/linux/input.h | 12 1 file changed, 12 insertions(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index b0a8130..3fc6885 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -747,6 +747,18 @@ struct input_keymap_entry { #define KEY_KBDINPUTASSIST_ACCEPT 0x264 #define KEY_KBDINPUTASSIST_CANCEL 0x265 +#define KEY_RIGHT_UP 0x266 +#define KEY_RIGHT_DOWN 0x267 +#define KEY_LEFT_UP0x268 +#define KEY_LEFT_DOWN 0x269 + +#define KEY_NEXT_FAVORITE 0x270 +#define KEY_STOP_RECORD0x271 +#define KEY_PAUSE_RECORD 0x272 +#define KEY_VOD0x273 +#define KEY_UNMUTE 0x274 +#define KEY_DVB0x275 + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 -- 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
[RFC v3 6/9] v4l2-subdev: add cec ops.
From: Hans Verkuil hansv...@cisco.com Add callbacks to the v4l2_subdev_video_ops. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- include/media/v4l2-subdev.h |8 1 file changed, 8 insertions(+) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index 5beeb87..fdf620d 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -40,6 +40,9 @@ #define V4L2_SUBDEV_IR_TX_NOTIFY _IOW('v', 1, u32) #define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001 +#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 2, u32) +#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 3, struct cec_msg) + struct v4l2_device; struct v4l2_ctrl_handler; struct v4l2_event_subscription; @@ -48,6 +51,7 @@ struct v4l2_subdev; struct v4l2_subdev_fh; struct tuner_setup; struct v4l2_mbus_frame_desc; +struct cec_msg; /* decode_vbi_line */ struct v4l2_decode_vbi_line { @@ -354,6 +358,10 @@ struct v4l2_subdev_video_ops { const struct v4l2_mbus_config *cfg); int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf, unsigned int *size); + int (*cec_enable)(struct v4l2_subdev *sd, bool enable); + int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr); + int (*cec_transmit)(struct v4l2_subdev *sd, struct cec_msg *msg); + void (*cec_transmit_timed_out)(struct v4l2_subdev *sd); }; /* -- 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
[RFC v3 7/9] adv7604: add cec support.
From: Hans Verkuil hansv...@cisco.com Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/i2c/adv7604.c | 182 +++ 1 file changed, 182 insertions(+) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index aaab9c9..ce9d123 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -42,6 +42,7 @@ #include media/v4l2-device.h #include media/v4l2-dv-timings.h #include media/v4l2-of.h +#include media/cec.h static int debug; module_param(debug, int, 0644); @@ -159,6 +160,10 @@ struct adv76xx_state { u16 spa_port_a[2]; struct v4l2_fract aspect_ratio; u32 rgb_quantization_range; + u8 cec_addr[3]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + struct workqueue_struct *work_queues; struct delayed_work delayed_work_enable_hotplug; bool restart_stdi_once; @@ -1862,6 +1867,176 @@ static int adv76xx_set_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh, return 0; } +static void adv7604_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status) +{ + if ((cec_read(sd, 0x11) 0x01) == 0) { + v4l2_dbg(1, debug, sd, %s: tx raw: tx disabled\n, __func__); + return; + } + + if (tx_raw_status 0x02) { + v4l2_dbg(1, debug, sd, %s: tx raw: arbitration lost\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void *)CEC_TX_STATUS_ARB_LOST); + return; + } + if (tx_raw_status 0x04) { + v4l2_dbg(1, debug, sd, %s: tx raw: retry failed\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void *)CEC_TX_STATUS_RETRY_TIMEOUT); + return; + } + if (tx_raw_status 0x01) { + v4l2_dbg(1, debug, sd, %s: tx raw: ready ok\n, __func__); + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void *)CEC_TX_STATUS_OK); + return; + } +} + +static void adv7604_cec_isr(struct v4l2_subdev *sd, bool *handled) +{ + struct cec_msg msg; + u8 cec_irq; + + /* cec controller */ + cec_irq = io_read(sd, 0x4d) 0x0f; + if (!cec_irq) + return; + + v4l2_dbg(1, debug, sd, %s: cec: irq 0x%x\n, __func__, cec_irq); + adv7604_cec_tx_raw_status(sd, cec_irq); + if (cec_irq 0x08) { + msg.len = cec_read(sd, 0x25) 0x1f; + if (msg.len 16) + msg.len = 16; + + if (msg.len) { + u8 i; + + for (i = 0; i msg.len; i++) + msg.msg[i] = cec_read(sd, i + 0x15); + cec_write(sd, 0x26, 0x01); /* re-enable rx */ + v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, msg); + } + } + + /* note: the bit order is swapped between 0x4d and 0x4e */ + cec_irq = ((cec_irq 0x08) 3) | ((cec_irq 0x04) 1) | + ((cec_irq 0x02) 1) | ((cec_irq 0x01) 3); + io_write(sd, 0x4e, cec_irq); + + if (handled) + *handled = true; +} + +static int adv7604_cec_enable(struct v4l2_subdev *sd, bool enable) +{ + struct adv7604_state *state = to_state(sd); + + if (!state-cec_enabled_adap enable) { + cec_write_and_or(sd, 0x2a, 0xfe, 0x01); /* power up cec */ + cec_write(sd, 0x2c, 0x01); /* cec soft reset */ + cec_write_and_or(sd, 0x11, 0xfe, 0); /* initially disable tx */ + /* enabled irqs: */ + /* tx: ready */ + /* tx: arbitration lost */ + /* tx: retry timeout */ + /* rx: ready */ + io_write_and_or(sd, 0x50, 0xf0, 0x0f); + cec_write(sd, 0x26, 0x01);/* enable rx */ + } else if (state-cec_enabled_adap !enable) { + io_write_and_or(sd, 0x50, 0xf0, 0x00); /* disable cec interrupts */ + cec_write_and_or(sd, 0x27, 0x8f, 0x70); /* disable address mask 1-3 */ + cec_write_and_or(sd, 0x2a, 0xfe, 0x00); /* power down cec section */ + state-cec_valid_addrs = 0; + } + state-cec_enabled_adap = enable; + return 0; +} + +#define ADV7604_MAX_ADDRS (3) + +static int adv7604_cec_log_addr(struct v4l2_subdev *sd, u8 addr) +{ + struct adv7604_state *state = to_state(sd); + unsigned i, free_idx = ADV7604_MAX_ADDRS; + + if (!state-cec_enabled_adap) + return -EIO; + + for (i = 0; i ADV7604_MAX_ADDRS; i++) { + bool is_valid = state-cec_valid_addrs (1 i); + + if (free_idx == ADV7604_MAX_ADDRS !is_valid
[RFC v3 9/9] s5p-cec: Add s5p-cec driver
Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/Kconfig |7 + drivers/media/platform/Makefile|1 + drivers/media/platform/s5p-cec/Makefile|4 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 37 +++ .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 ++ drivers/media/platform/s5p-cec/regs-cec.h | 96 +++ drivers/media/platform/s5p-cec/s5p_cec.c | 290 drivers/media/platform/s5p-cec/s5p_cec.h | 113 8 files changed, 756 insertions(+) create mode 100644 drivers/media/platform/s5p-cec/Makefile create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 2e30be5..016ae9d 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -155,6 +155,13 @@ config VIDEO_MEM2MEM_DEINTERLACE help Generic deinterlacing V4L2 driver. +config VIDEO_SAMSUNG_S5P_CEC + tristate Samsung S5P CEC driver + depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) + default n + ---help--- + This is a v4l2 driver for Samsung S5P HDMI CEC interface. + config VIDEO_SAMSUNG_S5P_G2D tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver depends on VIDEO_DEV VIDEO_V4L2 diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 3ec1547..17be832 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/ +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/ diff --git a/drivers/media/platform/s5p-cec/Makefile b/drivers/media/platform/s5p-cec/Makefile new file mode 100644 index 000..7f84226 --- /dev/null +++ b/drivers/media/platform/s5p-cec/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o +s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o + + diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h new file mode 100644 index 000..d008695 --- /dev/null +++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h @@ -0,0 +1,37 @@ +/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h + * + * Copyright (c) 2010, 2014 Samsung Electronics + * http://www.samsung.com/ + * + * Header file for interface of Samsung Exynos hdmi cec hardware + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef _EXYNOS_HDMI_CEC_H_ +#define _EXYNOS_HDMI_CEC_H_ __FILE__ + +#include linux/regmap.h +#include linux/miscdevice.h +#include s5p_cec.h + +void s5p_cec_set_divider(struct s5p_cec_dev *cec); +void s5p_cec_enable_rx(struct s5p_cec_dev *cec); +void s5p_cec_mask_rx_interrupts(struct s5p_cec_dev *cec); +void s5p_cec_unmask_rx_interrupts(struct s5p_cec_dev *cec); +void s5p_cec_mask_tx_interrupts(struct s5p_cec_dev *cec); +void s5p_cec_unmask_tx_interrupts(struct s5p_cec_dev *cec); +void s5p_cec_reset(struct s5p_cec_dev *cec); +void s5p_cec_tx_reset(struct s5p_cec_dev *cec); +void s5p_cec_rx_reset(struct s5p_cec_dev *cec); +void s5p_cec_threshold(struct s5p_cec_dev *cec); +void s5p_cec_copy_packet(struct s5p_cec_dev *cec, char *data, size_t count); +void s5p_cec_set_addr(struct s5p_cec_dev *cec, u32 addr); +u32 s5p_cec_get_status(struct s5p_cec_dev *cec); +void s5p_clr_pending_tx(struct s5p_cec_dev *cec); +void s5p_clr_pending_rx(struct s5p_cec_dev *cec); +void s5p_cec_get_rx_buf(struct s5p_cec_dev *cec, u32 size, u8 *buffer); + +#endif /* _EXYNOS_HDMI_CEC_H_ */ diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c new file mode 100644 index 000..65fe55e --- /dev/null +++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c @@ -0,0 +1,208 @@ +/* drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c + * + * Copyright (c) 2009, 2014 Samsung Electronics + * http://www.samsung.com/ + * + * cec ftn file for Samsung TVOUT driver
[RFC v3 8/9] adv7511: add cec support.
From: Hans Verkuil hansv...@cisco.com Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/i2c/adv7511.c | 325 ++- include/media/adv7511.h |6 +- 2 files changed, 323 insertions(+), 8 deletions(-) diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 81736aa..63ec6c1 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -33,6 +33,7 @@ #include media/v4l2-ctrls.h #include media/v4l2-dv-timings.h #include media/adv7511.h +#include media/cec.h static int debug; module_param(debug, int, 0644); @@ -91,6 +92,12 @@ struct adv7511_state { int chip_revision; uint8_t i2c_edid_addr; uint8_t i2c_cec_addr; + + struct i2c_client *i2c_cec; + u8 cec_addr[3]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + /* Is the adv7511 powered on? */ bool power_on; /* Did we receive hotplug and rx-sense signals? */ @@ -222,7 +229,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client *client, return ret; } -static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) +static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) { struct adv7511_state *state = get_adv7511_state(sd); int i; @@ -237,6 +244,33 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t v4l2_err(sd, %s: i2c read error\n, __func__); } +static inline int cec_read(struct v4l2_subdev *sd, u8 reg) +{ + struct adv7511_state *state = get_adv7511_state(sd); + + return i2c_smbus_read_byte_data(state-i2c_cec, reg); +} + +static int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) +{ + struct adv7511_state *state = get_adv7511_state(sd); + int ret; + int i; + + for (i = 0; i 3; i++) { + ret = i2c_smbus_write_byte_data(state-i2c_cec, reg, val); + if (ret == 0) + return 0; + } + v4l2_err(sd, %s: I2C Write Problem\n, __func__); + return ret; +} + +static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) mask) | val); +} + static inline bool adv7511_have_hotplug(struct v4l2_subdev *sd) { return adv7511_rd(sd, 0x42) MASK_ADV7511_HPD_DETECT; @@ -381,16 +415,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = { #ifdef CONFIG_VIDEO_ADV_DEBUG static void adv7511_inv_register(struct v4l2_subdev *sd) { + struct adv7511_state *state = get_adv7511_state(sd); + v4l2_info(sd, 0x000-0x0ff: Main Map\n); + if (state-i2c_cec) + v4l2_info(sd, 0x100-0x1ff: CEC Map\n); } static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + reg-size = 1; switch (reg-reg 8) { case 0: reg-val = adv7511_rd(sd, reg-reg 0xff); break; + case 1: + if (state-i2c_cec) { + reg-val = cec_read(sd, reg-reg 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, Register %03llx not supported\n, reg-reg); adv7511_inv_register(sd); @@ -401,10 +447,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register * static int adv7511_s_register(struct v4l2_subdev *sd, const struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + switch (reg-reg 8) { case 0: adv7511_wr(sd, reg-reg 0xff, reg-val 0xff); break; + case 1: + if (state-i2c_cec) { + cec_write(sd, reg-reg 0xff, reg-val 0xff); + break; + } + /* fall through */ default: v4l2_info(sd, Register %03llx not supported\n, reg-reg); adv7511_inv_register(sd); @@ -418,6 +472,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd) { struct adv7511_state *state = get_adv7511_state(sd); struct adv7511_state_edid *edid = state-edid; + int i; static const char * const states[] = { in reset, @@ -486,7 +541,20 @@ static int adv7511_log_status(struct v4l2_subdev *sd) else v4l2_info(sd, no timings set\n); v4l2_info(sd, i2c edid addr: 0x%x\n, state-i2c_edid_addr); + + if (state-i2c_cec == NULL) + return 0; + v4l2_info(sd, i2c cec addr: 0x%x\n, state-i2c_cec_addr); + + if (cec_read(sd, 0x4e) 0x01
[RFC v3 0/9] HDMI CEC framework
Hi, First of all - thank you so much for your comments to the two previous versions of this RFC. This is the third version of the HDMI CEC framework patches. In this version I have introduced a promiscuous mode in which all messages are forwarded to the userspace. This is independent of parsing of the messages, thus the key codes will be interpreted and sent as input events. This mode can be used to eavesdrop on the messages transferred on the bus. This can be used for e.g. to debug or listen look how other hardware communicates over the bus. The original cover letter follows the changes summary. Changes since v2 ===- - added promiscuous mode - added new key codes to the input framework - add vendor ID reporting - add the possibility to clear assigned logical addresses - cleanup of the rc cec map Changes since v1 - documentation edited and moved to the Documentation folder - added key up/down message handling - add missing CEC commands to the cec.h file Original cover letter = Hi, The work on a common CEC framework was started over three years ago by Hans Verkuil. Unfortunately the work has stalled. As I have received the task of creating a driver for the CEC interface module present on the Exynos range of SoCs, I got in touch with Hans. He repied that the work stalled due to his lack of time. The driver was done in the most part and there were only minor fixes that needed to be implemented. I would like to bring back the discussion on a common CEC interface framework. There are a few things that were still left as TODO, I think they might need some discussion - for instance the way how the remote controls should be handled. Best wishes, Kamil Debski Original RFC by Hans Verkuil/Martin Bugge = https://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html Hans Verkuil (3): v4l2-subdev: add cec ops. adv7604: add cec support. adv7511: add cec support. Kamil Debski (6): dts: add hdmi-cec to to pinctrl definitions dts: add s5p-cec to exynos4412-odroidu3 Input: add key codes specific to the HDMI CEC bus rc: add a map for devices communicating over the HDMI CEC bus cec: add new driver for cec support. s5p-cec: Add s5p-cec driver Documentation/cec.txt | 321 ++ arch/arm/boot/dts/exynos4412-odroid-common.dtsi|7 + arch/arm/boot/dts/exynos4412-odroidu3.dts | 13 + drivers/media/Kconfig |6 + drivers/media/Makefile |2 + drivers/media/cec.c| 1158 drivers/media/i2c/adv7511.c| 325 +- drivers/media/i2c/adv7604.c| 182 +++ drivers/media/platform/Kconfig |7 + drivers/media/platform/Makefile|1 + drivers/media/platform/s5p-cec/Makefile|4 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 37 + .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 drivers/media/platform/s5p-cec/regs-cec.h | 96 ++ drivers/media/platform/s5p-cec/s5p_cec.c | 290 + drivers/media/platform/s5p-cec/s5p_cec.h | 113 ++ drivers/media/rc/keymaps/Makefile |1 + drivers/media/rc/keymaps/rc-cec.c | 144 +++ drivers/media/rc/rc-main.c |1 + include/media/adv7511.h|6 +- include/media/cec.h| 137 +++ include/media/rc-core.h|1 + include/media/rc-map.h |5 +- include/media/v4l2-subdev.h|8 + include/uapi/linux/cec.h | 283 + include/uapi/linux/input.h | 12 + 26 files changed, 3359 insertions(+), 9 deletions(-) create mode 100644 Documentation/cec.txt create mode 100644 drivers/media/cec.c create mode 100644 drivers/media/platform/s5p-cec/Makefile create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h create mode 100644 drivers/media/rc/keymaps/rc-cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h -- 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
[RFC v3 1/9] dts: add hdmi-cec to to pinctrl definitions
Add entry for hdmi-cec to the pinctrl_1. Signed-off-by: Kamil Debski k.deb...@samsung.com --- arch/arm/boot/dts/exynos4412-odroid-common.dtsi |7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi index de80b5b..ca9b858 100644 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi @@ -425,4 +425,11 @@ samsung,pin-pud = 0; samsung,pin-drv = 0; }; + + hdmi_cec: hdmi-cec { + samsung,pins = gpx3-6; + samsung,pin-function = 3; + samsung,pin-pud = 0; + samsung,pin-drv = 0; + }; }; -- 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
RE: [PATCH 10/12] [media] coda: fail to start streaming if userspace set invalid formats
Hi Philipp, From: Jean-Michel Hautbois [mailto:jhautb...@gmail.com] Sent: Friday, February 27, 2015 10:00 AM To: Philipp Zabel Cc: Kamil Debski; Peter Seiderer; Linux Media Mailing List; Sascha Hauer Subject: Re: [PATCH 10/12] [media] coda: fail to start streaming if userspace set invalid formats Hi Philipp, 2015-02-23 16:20 GMT+01:00 Philipp Zabel p.za...@pengutronix.de: Could you add a description to this patch? Also, please remember about this patch https://patchwork.linuxtv.org/patch/28016. It also needs a description. Best wishes, -- Kamil Debski Samsung RD Institute Poland Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/media/platform/coda/coda-common.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index b42ccfc..4441179 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1282,12 +1282,23 @@ static int coda_start_streaming(struct vb2_queue *q, unsigned int count) if (!(ctx-streamon_out ctx-streamon_cap)) return 0; + q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE); + if ((q_data_src-width != q_data_dst-width +round_up(q_data_src-width, 16) != q_data_dst-width) || + (q_data_src-height != q_data_dst-height +round_up(q_data_src-height, 16) != q_data_dst-height)) { + v4l2_err(v4l2_dev, can't convert %dx%d to %dx%d\n, +q_data_src-width, q_data_src-height, +q_data_dst-width, q_data_dst-height); + ret = -EINVAL; + goto err; + } + Shouldn't the driver check on queues related to encoding or decoding only ? We don't need to set correct width/height from userspace if we are encoding, or it should be done by s_fmt itself. Thanks, JM -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 2/7] media: rc: Add cec protocol handling
Hi Mauro, I have some more comments/questions below. From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/rc/keymaps/Makefile |1 + drivers/media/rc/keymaps/rc-cec.c | 133 + drivers/media/rc/rc-main.c|1 + include/media/rc-core.h |1 + include/media/rc-map.h|5 +- 5 files changed, 140 insertions(+), 1 deletion(-) create mode [snip] + { 0x60, KEY_PLAY }, /* XXX CEC Spec: Play Function */ + { 0x61, KEY_PLAYPAUSE }, /* XXX CEC Spec: Pause-Play Function */ + { 0x62, KEY_RECORD }, /* XXX CEC Spec: Record Function */ + { 0x63, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record Function */ + { 0x64, KEY_STOP }, /* XXX CEC Spec: Stop Function */ + { 0x65, KEY_MUTE }, /* XXX CEC Spec: Mute Function */ + /* 0x66: CEC Spec: Restore Volume Function */ + { 0x67, KEY_TUNER }, /* XXX CEC Spec: Tune Function */ + { 0x68, KEY_MEDIA }, /* CEC Spec: Select Media Function */ + { 0x69, KEY_SWITCHVIDEOMODE} /* XXX CEC Spec: Select A/V Input Function */, + { 0x6a, KEY_AUDIO} /* CEC Spec: Select Audio Input Function */, + { 0x6b, KEY_POWER} /* CEC Spec: Power Toggle Function */, + { 0x6c, KEY_SLEEP} /* XXX CEC Spec: Power Off Function */, + { 0x6d, KEY_WAKEUP} /* XXX CEC Spec: Power On Function */, Those function keycodes look weird. What's the difference between those and the pure non-function variants? The note 2 applies to most of these function buttons. It says: 2 During a recording or timed recording, a device may ask the user for confirmation of this action before executing it. The spec (CEC 13.13.3) says that: Unlike the other codes, which just pass remote control presses to the target (often with manufacturer-specific results), the Functions are deterministic, ie they specify exactly the state after executing these commands. Several of these also have further operands, specifying the function in more detail, immediately following the relevant [UI Command] operand. Some codes are actually compund ones. For example, 0x60 has a play mode operand. So, the actual mapping would be: 0x60 + 0x24 - play forward 0x61 + 0x20 - play reverse ... (see CEC17 for operand descriptions) So, IMHO, the mapping should be { 0x6024, KEY_PLAY }, { 0x6020, KEY_PLAY_REVERSE }, // to be created The note 1 says that they can be issued without the additional operand specified: 1 Functions with additional operands may also be used without the additional operand: in this case the behavior is manufacturer-specific. Will this do? { 0x60, KEY_PLAY }, { 0x6024, KEY_PLAY }, { 0x6020, KEY_PLAY_REVERSE }, // to be created Or will the framework get confused that an incomplete key code was received? Another question I have is about the following operations: 0x67 Tune Function 0x68 Select Media Function 0x69 Select A/V Input Function 0x6a Select Audio Input Function These operations take an additional operand that is large number. 1-255 for 0x68-0x6a or even a more complex operand such as the channel number for 0x67. Any suggestion on how to implement these correctly? ... + /* 0x6e-0x70: Reserved */ + { 0x71, KEY_BLUE }, /* XXX CEC Spec: F1 (Blue) */ + { 0x72, KEY_RED }, /* XXX CEC Spec: F2 (Red) */ + { 0x73, KEY_GREEN }, /* XXX CEC Spec: F3 (Green) */ + { 0x74, KEY_YELLOW }, /* XXX CEC Spec: F4 (Yellow) */ + { 0x75, KEY_F5 }, + { 0x76, KEY_CONNECT }, /* XXX CEC Spec: Data - see Note 3 */ + /* Note 3: This is used, for example, to enter or leave a digital TV +* data broadcast application. */ [snip] Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 2/7] media: rc: Add cec protocol handling
Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 2/7] media: rc: Add cec protocol handling
From: Bastien Nocera [mailto:had...@hadess.net] Sent: Tuesday, March 10, 2015 3:15 PM On Tue, 2015-03-10 at 13:02 +0100, Kamil Debski wrote: Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) I have 2 machines that this could work on, a Intel Baytrail tablet, and a laptop with Intel Haswell. Is that part going to be covered by your library, or will there be a drm API for that? Enabling CEC is done by the CEC framework. The idea is to have it independent of other frameworks (such as drm, or v4l2). - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) That's done through the CEC API as well? Yes. - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly That's easier to deal with :) Something like LIRC can be used in the short-term. How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Great. Do drop me a mail when you have something that I could test. Will do. Cheers Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 3/7] cec: add new framework for cec support.
Hi Mauro, Thank you for your comments. From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 4:42 PM Em Fri, 06 Mar 2015 17:14:50 +0100 Kamil Debski k.deb...@samsung.com escreveu: Hi Sean, Hans, I am sorry to reply so late, I was busy with other work. I am preparing the next version of the CEC framework and I would like to discuss your comment. I'll do a deeper review of this patch when I have some time. For now, let me add my comments about the pass-trough mode. See below. I think I might have confused you with the pass-through mode. I think it would be good if I explained it in detail. I guess my initial name choice wasn't fortunate. I prefer the name raw over pass through as it is closer to what I meant by adding this feature. Maybe even promiscuous could be better. The CEC framework does filtering on the messages it receives. It will filter messages not directed to the device (different logical address) and will do parsing of the keystrokes. The keystrokes are then reported by the input framework to the userspace and won't be read by the CEC_RECEIVE ioctl. In the raw/promiscuous the messages on the CEC bus would not be filtered and all of them should be passed to the userspace. This will include messages not intended for the particular device and keystroke messages. I think that this mode could be useful, e.g. for debugging and maybe for devices that act as switches. My original idea was that in the raw mode the CEC framework would stop passing the keycodes from the CEC bus to the input device. I see that this can be problematic, hence I think that suspending from passing the keycodes to the input framework is not necessary. I think that this solution would be acceptable for you guys. Mauro, Sean, Hans, tell me if I am wrong? To recap - the raw/promiscuous mode would only disable filtering of messages and had no effect on passing keycodes to the input device. From: Sean Young [mailto:s...@mess.org] Sent: Friday, January 23, 2015 12:08 PM On Thu, Jan 22, 2015 at 05:04:35PM +0100, Kamil Debski wrote: Add the CEC framework. -snip- +Remote control handling +--- + +The CEC framework provides two ways of handling the key messages +of remote control. In the first case, the CEC framework will +handle these messages and provide the keypressed via the RC +framework. In the second case the messages related to the key +down/up events are not parsed by the framework and are passed to +the userspace as raw messages. + +Switching between these modes is done with a special ioctl. + +#define CEC_G_KEY_PASSTHROUGH _IOR('a', 10, __u8) +#define CEC_S_KEY_PASSTHROUGH _IOW('a', 11, __u8) +#define CEC_KEY_PASSTHROUGH_DISABLE0 +#define CEC_KEY_PASSTHROUGH_ENABLE 1 This is ugly. This ioctl stops keypresses from going to rc-core. The cec device is still registered with rc-core but no keys will be passed to it. This could also be handled by loading an empty keymap; this way the input layer will still receive scancodes but no keypresses. I see here a few options that can be done: 1) Remove the past through option altogether I think I would opt for leaving it. There should be some mode that would enable raw access to the CEC bus. Maybe it should be something more like a promiscuous mode in Wi-Fi networks. What do you think? Sean, Hans? 2) Leave the pass through mode, but without disabling passing the keyup/down events to the RC framework. This way an application could capture all messages, but the input device would not be crippled in any way. The problem with this solution is that key presses could be accounted twice. 3) As you suggested - load an empty keymap whenever the pass through mode is enabled. I am not that familiar with the RC core. Is there a simple way to switch to an empty map from the kernel? There is the ir_setkeytable function, but it is static in rc-main.c, so it cannot be used in other kernel modules. Any hints, Sean? 4) Remove the input device whenever a pass through mode is enabled. This is an alternative to the solution number 3. I think it would not be great, because a /dev/input/event* that appears and disappears could be confusing. (4) doesn't seem nice. I don't think that the driver itself should cleanup the keymap. This is something that the userspace app(s) should explicitly request. I agree. With regards to the raw mode, the RC core currently has two ways to send/receive raw data: 1) Via LIRC. This needs to be extended to pass scancodes, as, currently, it sends/receive pulses. We need such extension for other usages, anyway, so adding it makes sense. That is another thing I need to implement - send keycodes to other devices. 2) The input layer actually provide several types of events on a key press. One of such events carry
RE: [RFC v2 2/7] media: rc: Add cec protocol handling
Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/rc/keymaps/Makefile |1 + drivers/media/rc/keymaps/rc-cec.c | 133 + drivers/media/rc/rc-main.c|1 + include/media/rc-core.h |1 + include/media/rc-map.h|5 +- 5 files changed, 140 insertions(+), 1 deletion(-) create mode 100644 drivers/media/rc/keymaps/rc-cec.c diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile index abf6079..56f10d6 100644 --- a/drivers/media/rc/keymaps/Makefile +++ b/drivers/media/rc/keymaps/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \ rc-behold.o \ rc-behold-columbus.o \ rc-budget-ci-old.o \ + rc-cec.o \ rc-cinergy-1400.o \ rc-cinergy.o \ rc-delock-61959.o \ diff --git a/drivers/media/rc/keymaps/rc-cec.c b/drivers/media/rc/keymaps/rc-cec.c new file mode 100644 index 000..f2826c5 --- /dev/null +++ b/drivers/media/rc/keymaps/rc-cec.c @@ -0,0 +1,133 @@ +/* Keytable for the CEC remote control + * + * Copyright (c) 2015 by Kamil Debski + * + * This program is free software; you can redistribute it and/or +modify + * it under the terms of the GNU General Public License as published +by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include media/rc-map.h +#include linux/module.h + +/* CEC Spec High-Definition Multimedia Interface Specification can +be obtained + * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf + * The list of control codes is listed in Table 27: User Control +Codes p. 95 */ + +static struct rc_map_table cec[] = { + { 0x00, KEY_SELECT }, /* XXX CEC Spec: Select, should it be +KEY_SELECT or KEY_OK? */ KEY_OK is better, IMHO. + { 0x01, KEY_UP }, + { 0x02, KEY_DOWN }, + { 0x03, KEY_LEFT }, + { 0x04, KEY_RIGHT }, + /* XXX 0x05-0x08 CEC Spec: Right-Up, Right-Down, Left-Up, Left- Down +*/ I think you need to send a patch to linux-input, in order to add those keycodes. + { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */ + /* Note 2: This is the initial display that a device shows. It is +* device-dependent and can be, for example, a contents menu, setup +* menu, favorite menu or other menu. The actual menu displayed +* may also depend on the device’s current state. */ + { 0x0a, KEY_SETUP }, + { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */ + { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */ + { 0x0d, KEY_EXIT }, + /* 0x0e-0x1f: Reserved */ + /* 0x20-0x29: Keys 0 to 9 */ + { 0x20, KEY_0 }, + { 0x21, KEY_1 }, + { 0x22, KEY_2 }, + { 0x23, KEY_3 }, + { 0x24, KEY_4 }, + { 0x25, KEY_5 }, + { 0x26, KEY_6 }, + { 0x27, KEY_7 }, + { 0x28, KEY_8 }, + { 0x29, KEY_9 }, Better to use KEY_NUMERIC_* here, as this is not affected by the shift state. + { 0x2a, KEY_DOT }, + { 0x2b, KEY_ENTER }, + { 0x2c, KEY_CLEAR }, + /* 0x2d-0x2e: Reserved */ + /* XXX 0x2f: CEC Spec: Next Favorite */ Again another addition to Linux keystroke codes. + { 0x30, KEY_CHANNELUP }, + { 0x31, KEY_CHANNELDOWN }, + { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */ + { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */ + /* XXX 0x34: CEC Spec: Input Select */ Another key to be added. Yet, other keymaps have a key to select the input source. Most use KEY_VIDEO, to select the video input source, and KEY_AUDIO, to select the audio input source. So, KEY_VIDEO is likely the best choice here. + { 0x35, KEY_INFO }, /* CEC Spec: Display Information */ + { 0x36, KEY_HELP }, + { 0x37, KEY_PAGEUP }, + { 0x38, KEY_PAGEDOWN }, + /* 0x39-0x3f: Reserved */ + { 0x40, KEY_POWER }, + { 0x41, KEY_VOLUMEUP }, + { 0x42, KEY_VOLUMEDOWN }, + { 0x43, KEY_MUTE }, + { 0x44, KEY_PLAY }, + { 0x45, KEY_STOP }, /* XXX CEC Spec: Stop, what about KEY_STOPCD? */ + { 0x46, KEY_PAUSE },/* XXX CEC Spec: Pause, what about KEY_PAUSECD? +*/ The CD variants are to control the CD player on multimedia keyboards I think. only two IR maps
RE: [RFC v2 3/7] cec: add new framework for cec support.
Hi Sean, From: Sean Young [mailto:s...@mess.org] Sent: Sunday, March 08, 2015 11:45 AM Hi Kamil, On Fri, Mar 06, 2015 at 05:14:50PM +0100, Kamil Debski wrote: 3) As you suggested - load an empty keymap whenever the pass through mode is enabled. I am not that familiar with the RC core. Is there a simple way to switch to an empty map from the kernel? There is the ir_setkeytable function, but it is static in rc-main.c, so it cannot be used in other kernel modules. Any hints, Sean? Why is it problematic if keypresses are passed to the input layer? I gave this a thought over the weekend and I think I agree that this shouldn't be much of a problem. I had doubts that there could be an application that could use both the input device and at the same time parse the raw messages to get keycodes. In reality this should not happen, as someone using the raw/promiscuous mode would be aware of how it works - that the keycodes are still passed to the input device. You can only set the default keymap for an rc-device from kernel space; from user space you can clear the table using input ioctl, see: http://git.linuxtv.org/cgit.cgi/v4l- utils.git/tree/utils/keytable/keytable.c#n1277 You can select MAP_EMPTY as the default keymap if that is appropriate; using ir-setkeytable(1) a different keymap can be selected. Sean Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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: [PATCHv2 1/2] ARM: dts: exynos5420: add nodes for jpeg codec
Hi Andrzej, From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Andrzej Pietrasiewicz Sent: Friday, March 06, 2015 11:33 AM Thank you for your patch. Regardless how simple the patch is, there should be some description. In the v2 of the patch set please add a description. One sentence should be enough. Best wishes, -- Kamil Debski Samsung RD Institute Poland Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com --- arch/arm/boot/dts/exynos5420.dtsi | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index 73c1851..f8f583c 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -775,6 +775,22 @@ iommus = sysmmu_gscl1; }; + jpeg_0: jpeg@11F5 { + compatible = samsung,exynos5420-jpeg; + reg = 0x11F5 0x1000; + interrupts = 0 89 0; + clock-names = jpeg; + clocks = clock CLK_JPEG; + }; + + jpeg_1: jpeg@11F6 { + compatible = samsung,exynos5420-jpeg; + reg = 0x11F6 0x1000; + interrupts = 0 168 0; + clock-names = jpeg; + clocks = clock CLK_JPEG2; + }; + pmu_system_controller: system-controller@1004 { compatible = samsung,exynos5420-pmu, syscon; reg = 0x1004 0x5000; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 3/7] cec: add new framework for cec support.
Hi Sean, Hans, I am sorry to reply so late, I was busy with other work. I am preparing the next version of the CEC framework and I would like to discuss your comment. From: Sean Young [mailto:s...@mess.org] Sent: Friday, January 23, 2015 12:08 PM On Thu, Jan 22, 2015 at 05:04:35PM +0100, Kamil Debski wrote: Add the CEC framework. -snip- +Remote control handling +--- + +The CEC framework provides two ways of handling the key messages of +remote control. In the first case, the CEC framework will handle +these messages and provide the keypressed via the RC framework. In +the second case the messages related to the key down/up events are +not parsed by the framework and are passed to the userspace as raw messages. + +Switching between these modes is done with a special ioctl. + +#define CEC_G_KEY_PASSTHROUGH _IOR('a', 10, __u8) +#define CEC_S_KEY_PASSTHROUGH _IOW('a', 11, __u8) +#define CEC_KEY_PASSTHROUGH_DISABLE0 +#define CEC_KEY_PASSTHROUGH_ENABLE 1 This is ugly. This ioctl stops keypresses from going to rc-core. The cec device is still registered with rc-core but no keys will be passed to it. This could also be handled by loading an empty keymap; this way the input layer will still receive scancodes but no keypresses. I see here a few options that can be done: 1) Remove the past through option altogether I think I would opt for leaving it. There should be some mode that would enable raw access to the CEC bus. Maybe it should be something more like a promiscuous mode in Wi-Fi networks. What do you think? Sean, Hans? 2) Leave the pass through mode, but without disabling passing the keyup/down events to the RC framework. This way an application could capture all messages, but the input device would not be crippled in any way. The problem with this solution is that key presses could be accounted twice. 3) As you suggested - load an empty keymap whenever the pass through mode is enabled. I am not that familiar with the RC core. Is there a simple way to switch to an empty map from the kernel? There is the ir_setkeytable function, but it is static in rc-main.c, so it cannot be used in other kernel modules. Any hints, Sean? 4) Remove the input device whenever a pass through mode is enabled. This is an alternative to the solution number 3. I think it would not be great, because a /dev/input/event* that appears and disappears could be confusing. +static ssize_t cec_read(struct file *filp, char __user *buf, + size_t sz, loff_t *off) +{ + struct cec_devnode *cecdev = cec_devnode_data(filp); + + if (!cec_devnode_is_registered(cecdev)) + return -EIO; + return 0; +} + +static ssize_t cec_write(struct file *filp, const char __user *buf, + size_t sz, loff_t *off) +{ + struct cec_devnode *cecdev = cec_devnode_data(filp); + + if (!cec_devnode_is_registered(cecdev)) + return -EIO; + return 0; +} Both read and write do nothing; they should either -ENOSYS or the fuctions should be removed. I agree, I removed this for the next version. Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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] s5p-mfc: remove non necessary volatile modifiers and __iomem annotations
This patch removes non necessary volatile modifiers and __iomem annotations from the s5p_mfc_regs structure. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 488 +- 1 file changed, 244 insertions(+), 244 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h index de2b8c6..7a7ad32 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h @@ -20,254 +20,254 @@ struct s5p_mfc_regs { /* codec common registers */ - volatile void __iomem *risc_on; - volatile void __iomem *risc2host_int; - volatile void __iomem *host2risc_int; - volatile void __iomem *risc_base_address; - volatile void __iomem *mfc_reset; - volatile void __iomem *host2risc_command; - volatile void __iomem *risc2host_command; - volatile void __iomem *mfc_bus_reset_ctrl; - volatile void __iomem *firmware_version; - volatile void __iomem *instance_id; - volatile void __iomem *codec_type; - volatile void __iomem *context_mem_addr; - volatile void __iomem *context_mem_size; - volatile void __iomem *pixel_format; - volatile void __iomem *metadata_enable; - volatile void __iomem *mfc_version; - volatile void __iomem *dbg_info_enable; - volatile void __iomem *dbg_buffer_addr; - volatile void __iomem *dbg_buffer_size; - volatile void __iomem *hed_control; - volatile void __iomem *mfc_timeout_value; - volatile void __iomem *hed_shared_mem_addr; - volatile void __iomem *dis_shared_mem_addr;/* only v7 */ - volatile void __iomem *ret_instance_id; - volatile void __iomem *error_code; - volatile void __iomem *dbg_buffer_output_size; - volatile void __iomem *metadata_status; - volatile void __iomem *metadata_addr_mb_info; - volatile void __iomem *metadata_size_mb_info; - volatile void __iomem *dbg_info_stage_counter; + void *risc_on; + void *risc2host_int; + void *host2risc_int; + void *risc_base_address; + void *mfc_reset; + void *host2risc_command; + void *risc2host_command; + void *mfc_bus_reset_ctrl; + void *firmware_version; + void *instance_id; + void *codec_type; + void *context_mem_addr; + void *context_mem_size; + void *pixel_format; + void *metadata_enable; + void *mfc_version; + void *dbg_info_enable; + void *dbg_buffer_addr; + void *dbg_buffer_size; + void *hed_control; + void *mfc_timeout_value; + void *hed_shared_mem_addr; + void *dis_shared_mem_addr;/* only v7 */ + void *ret_instance_id; + void *error_code; + void *dbg_buffer_output_size; + void *metadata_status; + void *metadata_addr_mb_info; + void *metadata_size_mb_info; + void *dbg_info_stage_counter; /* decoder registers */ - volatile void __iomem *d_crc_ctrl; - volatile void __iomem *d_dec_options; - volatile void __iomem *d_display_delay; - volatile void __iomem *d_set_frame_width; - volatile void __iomem *d_set_frame_height; - volatile void __iomem *d_sei_enable; - volatile void __iomem *d_min_num_dpb; - volatile void __iomem *d_min_first_plane_dpb_size; - volatile void __iomem *d_min_second_plane_dpb_size; - volatile void __iomem *d_min_third_plane_dpb_size;/* only v8 */ - volatile void __iomem *d_min_num_mv; - volatile void __iomem *d_mvc_num_views; - volatile void __iomem *d_min_num_dis;/* only v7 */ - volatile void __iomem *d_min_first_dis_size;/* only v7 */ - volatile void __iomem *d_min_second_dis_size;/* only v7 */ - volatile void __iomem *d_min_third_dis_size;/* only v7 */ - volatile void __iomem *d_post_filter_luma_dpb0;/* v7 and v8 */ - volatile void __iomem *d_post_filter_luma_dpb1;/* v7 and v8 */ - volatile void __iomem *d_post_filter_luma_dpb2;/* only v7 */ - volatile void __iomem *d_post_filter_chroma_dpb0;/* v7 and v8 */ - volatile void __iomem *d_post_filter_chroma_dpb1;/* v7 and v8 */ - volatile void __iomem *d_post_filter_chroma_dpb2;/* only v7 */ - volatile void __iomem *d_num_dpb; - volatile void __iomem *d_num_mv; - volatile void __iomem *d_init_buffer_options; - volatile void __iomem *d_first_plane_dpb_stride_size;/* only v8 */ - volatile void __iomem *d_second_plane_dpb_stride_size;/* only v8 */ - volatile void __iomem *d_third_plane_dpb_stride_size;/* only v8 */ - volatile void __iomem *d_first_plane_dpb_size; - volatile void __iomem *d_second_plane_dpb_size; - volatile void __iomem *d_third_plane_dpb_size;/* only v8 */ - volatile void __iomem *d_mv_buffer_size; - volatile void __iomem *d_first_plane_dpb
[GIT PULL] s5p-mfc fixes
Hi Mauro, Please pull the following fixes for the MFC driver. The following changes since commit 41f03a00536ebb3d72c051f9e7efe2d4ab76ebc8: [media] s5p-mfc: Fix NULL pointer dereference caused by not set q-lock (2015-03-04 08:59:58 -0300) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git v4.0-fixes for you to fetch changes up to af702f22d9879856ea936ac41a7baea0706fa56a: media: s5p-mfc: fix broken pointer cast on 64bit arch (2015-03-05 11:02:52 +0100) Marek Szyprowski (2): media: s5p-mfc: fix mmap support for 64bit arch media: s5p-mfc: fix broken pointer cast on 64bit arch drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |6 +++--- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 +++--- 4 files changed, 8 insertions(+), 8 deletions(-) Best wishes, Kamil Debski -- 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] s5p-mfc: Fix NULL pointer dereference caused by not set q-lock
The patch media: s5p-mfc: use vb2_ops_wait_prepare/finish helper (654a731be1a0b6f606f3f3d12b50db08f2ae3c3) introduced a kernel panic. The q-lock was set for just one queue, the other was not set thus causing a NULL pointer dereference. Reported-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 9fe4d90..8333fbc 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -833,6 +833,7 @@ static int s5p_mfc_open(struct file *file) q-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE; q-io_modes = VB2_MMAP; q-drv_priv = ctx-fh; + q-lock = dev-mfc_mutex; if (vdev == dev-vfd_dec) { q-io_modes = VB2_MMAP; q-ops = get_dec_queue_ops(); -- 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
RE: [PATCH] media: i2c: s5c73m3: make sure we destroy the mutex
From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, March 03, 2015 10:09 AM On 03/02/2015 04:00 PM, Lad Prabhakar wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com Make sure to call mutex_destroy() in case of probe failure or module unload. It's not actually necessary to destroy a mutex. Most drivers never do this. It only helps a bit in debugging. I'll delegate this patch to Kamil, and he can decide whether or not to apply this. I agree with Hans here, the patch is not necessary. Regards, Hans Best wishes, -- Kamil Debski Samsung RD Institute Poland Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c b/drivers/media/i2c/s5c73m3/s5c73m3-core.c index ee0f57e..da0b3a3 100644 --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c @@ -1658,7 +1658,6 @@ static int s5c73m3_probe(struct i2c_client *client, if (ret 0) return ret; - mutex_init(state-lock); sd = state-sensor_sd; oif_sd = state-oif_sd; @@ -1695,6 +1694,8 @@ static int s5c73m3_probe(struct i2c_client *client, if (ret 0) return ret; + mutex_init(state-lock); + ret = s5c73m3_configure_gpios(state); if (ret) goto out_err; @@ -1754,6 +1755,7 @@ out_err1: s5c73m3_unregister_spi_driver(state); out_err: media_entity_cleanup(sd-entity); + mutex_destroy(state-lock); return ret; } @@ -1772,6 +1774,7 @@ static int s5c73m3_remove(struct i2c_client *client) media_entity_cleanup(sensor_sd-entity); s5c73m3_unregister_spi_driver(state); + mutex_destroy(state-lock); return 0; } -- 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 v5 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
Hi, Thank you for the review :) From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Friday, February 20, 2015 5:52 PM Hi Kamil, One question and one typo below... On 02/20/2015 05:38 PM, Kamil Debski wrote: The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the size of the buffer. However, bytesused set to 0 is used by older codec drivers as as indication used to mark the end of stream. To keep backward compatibility, this patch adds a flag passed to the vb2_queue_init function - allow_zero_bytesused. If the flag is set upon initialization of the queue, the videobuf2 keeps the value of bytesused intact in the OUTPUT queue and passes it to the driver. Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/v4l2-core/videobuf2-core.c | 39 +- include/media/videobuf2-core.h |2 ++ 2 files changed, 35 insertions(+), 6 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 5cd60bf..5d77670 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b { unsigned int plane; + if (V4L2_TYPE_IS_OUTPUT(b-type)) { + if (WARN_ON_ONCE(b-bytesused == 0)) { + pr_warn_once(use of bytesused == 0 is deprecated and will be +removed in 2017,\n); I wonder if we should give a specific year, or just say 'in the future'. What do you think? I think I would prefer to use the phrase in the future. If you are ok with that I will post an updated patch set soon. + if (vb-vb2_queue-allow_zero_bytesused) + pr_warn_once(use VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n); + else + pr_warn_once(use the actual size instead.\n); + } + } + if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) { if (b-memory == V4L2_MEMORY_USERPTR) { for (plane = 0; plane vb-num_planes; ++plane) { @@ -1276,13 +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b * userspace clearly never bothered to set it and * it's a safe assumption that they really meant to * use the full plane sizes. +* +* Some drivers, e.g. old codec drivers, use bytesused +* == 0 as a way to indicate that streaming is finished. +* In that case, the driver should use the +* allow_zero_bytesused flag to keep old userspace +* applications working. */ for (plane = 0; plane vb-num_planes; ++plane) { struct v4l2_plane *pdst = v4l2_planes[plane]; struct v4l2_plane *psrc = b-m.planes[plane]; - pdst-bytesused = psrc-bytesused ? - psrc-bytesused : pdst-length; + if (vb-vb2_queue-allow_zero_bytesused) + pdst-bytesused = psrc-bytesused; + else + pdst-bytesused = psrc-bytesused ? + psrc-bytesused : pdst-length; pdst-data_offset = psrc-data_offset; } } @@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b * * If bytesused == 0 for the output buffer, then fall back * to the full buffer size as that's a sensible default. +* +* Some drivers, e.g. old codec drivers, use bytesused * == 0 as Small typo: s/bytesused * == 0/bytesused == 0/ +* a way to indicate that streaming is finished. In that case, +* the driver should use the allow_zero_bytesused flag to keep +* old userspace applications working. */ if (b-memory == V4L2_MEMORY_USERPTR) { v4l2_planes[0].m.userptr = b-m.userptr; @@ -1306,10 +1330,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b v4l2_planes[0].length = b-length; } - if (V4L2_TYPE_IS_OUTPUT(b-type)) - v4l2_planes[0].bytesused = b-bytesused ? - b-bytesused : v4l2_planes[0].length; - else
[PATCH v6 4/4] s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init
The s5p-mfc driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 8e44a59..9fe4d90 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -843,6 +843,13 @@ static int s5p_mfc_open(struct file *file) ret = -ENOENT; goto err_queue_init; } + /* One way to indicate end-of-stream for MFC is to set the +* bytesused == 0. However by default videobuf2 handles bytesused +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag so that videobuf2 +* will keep the value of bytesused intact. +*/ + q-allow_zero_bytesused = 1; q-mem_ops = vb2_dma_contig_memops; q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; ret = vb2_queue_init(q); -- 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 v6 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the size of the buffer. However, bytesused set to 0 is used by older codec drivers as as indication used to mark the end of stream. To keep backward compatibility, this patch adds a flag passed to the vb2_queue_init function - allow_zero_bytesused. If the flag is set upon initialization of the queue, the videobuf2 keeps the value of bytesused intact in the OUTPUT queue and passes it to the driver. Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/v4l2-core/videobuf2-core.c | 39 +- include/media/videobuf2-core.h |2 ++ 2 files changed, 35 insertions(+), 6 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 5cd60bf..33a5d93 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b { unsigned int plane; + if (V4L2_TYPE_IS_OUTPUT(b-type)) { + if (WARN_ON_ONCE(b-bytesused == 0)) { + pr_warn_once(use of bytesused == 0 is deprecated and will be removed in the future,\n); + if (vb-vb2_queue-allow_zero_bytesused) + pr_warn_once(use VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n); + else + pr_warn_once(use the actual size instead.\n); + } + } + if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) { if (b-memory == V4L2_MEMORY_USERPTR) { for (plane = 0; plane vb-num_planes; ++plane) { @@ -1276,13 +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b * userspace clearly never bothered to set it and * it's a safe assumption that they really meant to * use the full plane sizes. +* +* Some drivers, e.g. old codec drivers, use bytesused == 0 +* as a way to indicate that streaming is finished. +* In that case, the driver should use the +* allow_zero_bytesused flag to keep old userspace +* applications working. */ for (plane = 0; plane vb-num_planes; ++plane) { struct v4l2_plane *pdst = v4l2_planes[plane]; struct v4l2_plane *psrc = b-m.planes[plane]; - pdst-bytesused = psrc-bytesused ? - psrc-bytesused : pdst-length; + if (vb-vb2_queue-allow_zero_bytesused) + pdst-bytesused = psrc-bytesused; + else + pdst-bytesused = psrc-bytesused ? + psrc-bytesused : pdst-length; pdst-data_offset = psrc-data_offset; } } @@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b * * If bytesused == 0 for the output buffer, then fall back * to the full buffer size as that's a sensible default. +* +* Some drivers, e.g. old codec drivers, use bytesused == 0 as +* a way to indicate that streaming is finished. In that case, +* the driver should use the allow_zero_bytesused flag to keep +* old userspace applications working. */ if (b-memory == V4L2_MEMORY_USERPTR) { v4l2_planes[0].m.userptr = b-m.userptr; @@ -1306,10 +1330,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b v4l2_planes[0].length = b-length; } - if (V4L2_TYPE_IS_OUTPUT(b-type)) - v4l2_planes[0].bytesused = b-bytesused ? - b-bytesused : v4l2_planes[0].length; - else + if (V4L2_TYPE_IS_OUTPUT(b-type)) { + if (vb-vb2_queue-allow_zero_bytesused) + v4l2_planes[0].bytesused = b-bytesused; + else + v4l2_planes[0].bytesused = b-bytesused ? + b-bytesused : v4l2_planes[0].length; + } else v4l2_planes[0].bytesused = 0; } diff --git
[PATCH v6 3/4] coda: set allow_zero_bytesused flag for vb2_queue_init
The coda driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/coda/coda-common.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index 6f32e6d..329c2a4 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1541,6 +1541,13 @@ static int coda_queue_init(struct coda_ctx *ctx, struct vb2_queue *vq) vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); vq-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; vq-lock = ctx-dev-dev_mutex; + /* One way to indicate end-of-stream for coda is to set the +* bytesused == 0. However by default videobuf2 handles bytesused +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag, so +* that videobuf2 will keep the value of bytesused intact. +*/ + vq-allow_zero_bytesused = 1; return vb2_queue_init(vq); } -- 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 v6 1/4] vb2: split the io_flags member of vb2_queue into a bit field
This patch splits the io_flags member of vb2_queue into a bit field. Instead of an enum with flags separate bit fields were introduced. Signed-off-by: Kamil Debski k.deb...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/videobuf2-core.c | 17 + include/media/videobuf2-core.h | 18 +- 2 files changed, 14 insertions(+), 21 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index bc08a82..5cd60bf 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2760,7 +2760,8 @@ struct vb2_fileio_data { unsigned int initial_index; unsigned int q_count; unsigned int dq_count; - unsigned int flags; + unsigned read_once:1; + unsigned write_immediately:1; }; /** @@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue *q, int read) */ count = 1; - dprintk(3, setting up file io: mode %s, count %d, flags %08x\n, - (read) ? read : write, count, q-io_flags); + dprintk(3, setting up file io: mode %s, count %d, read_once %d, write_immediately %d\n, + (read) ? read : write, count, q-fileio_read_once, + q-fileio_write_immediately); fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL); if (fileio == NULL) return -ENOMEM; - fileio-flags = q-io_flags; + fileio-read_once = q-fileio_read_once; + fileio-write_immediately = q-fileio_write_immediately; /* * Request buffers and use MMAP type to force driver @@ -3028,13 +3031,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, char __user *data, size_ /* * Queue next buffer if required. */ - if (buf-pos == buf-size || - (!read (fileio-flags VB2_FILEIO_WRITE_IMMEDIATELY))) { + if (buf-pos == buf-size || (!read fileio-write_immediately)) { /* * Check if this is the last buffer to read. */ - if (read (fileio-flags VB2_FILEIO_READ_ONCE) - fileio-dq_count == 1) { + if (read fileio-read_once fileio-dq_count == 1) { dprintk(3, read limit reached\n); return __vb2_cleanup_fileio(q); } diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index bd2cec2..e49dc6b 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -134,17 +134,6 @@ enum vb2_io_modes { }; /** - * enum vb2_fileio_flags - flags for selecting a mode of the file io emulator, - * by default the 'streaming' style is used by the file io emulator - * @VB2_FILEIO_READ_ONCE: report EOF after reading the first buffer - * @VB2_FILEIO_WRITE_IMMEDIATELY: queue buffer after each write() call - */ -enum vb2_fileio_flags { - VB2_FILEIO_READ_ONCE= (1 0), - VB2_FILEIO_WRITE_IMMEDIATELY= (1 1), -}; - -/** * enum vb2_buffer_state - current video buffer state * @VB2_BUF_STATE_DEQUEUED:buffer under userspace control * @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf @@ -346,7 +335,8 @@ struct v4l2_fh; * * @type: queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h * @io_modes: supported io methods (see vb2_io_modes enum) - * @io_flags: additional io flags (see vb2_fileio_flags enum) + * @fileio_read_once: report EOF after reading the first buffer + * @fileio_write_immediately: queue buffer after each write() call * @lock: pointer to a mutex that protects the vb2_queue struct. The * driver can set this to a mutex to let the v4l2 core serialize * the queuing ioctls. If the driver wants to handle locking @@ -396,7 +386,9 @@ struct v4l2_fh; struct vb2_queue { enum v4l2_buf_type type; unsigned intio_modes; - unsigned intio_flags; + unsignedfileio_read_once:1; + unsignedfileio_write_immediately:1; + struct mutex*lock; struct v4l2_fh *owner; -- 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 v5 4/4] s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init
The s5p-mfc driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 8e44a59..6b08488 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -843,6 +843,13 @@ static int s5p_mfc_open(struct file *file) ret = -ENOENT; goto err_queue_init; } + /* One of means to indicate end-of-stream for MFC is to set the +* bytesused == 0. However by default videobuf2 handles videobuf +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag so that videobuf2 +* will keep the value of bytesused intact. +*/ + q-allow_zero_bytesused = 1; q-mem_ops = vb2_dma_contig_memops; q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; ret = vb2_queue_init(q); -- 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 v5 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the size of the buffer. However, bytesused set to 0 is used by older codec drivers as as indication used to mark the end of stream. To keep backward compatibility, this patch adds a flag passed to the vb2_queue_init function - allow_zero_bytesused. If the flag is set upon initialization of the queue, the videobuf2 keeps the value of bytesused intact in the OUTPUT queue and passes it to the driver. Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/v4l2-core/videobuf2-core.c | 39 +- include/media/videobuf2-core.h |2 ++ 2 files changed, 35 insertions(+), 6 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 5cd60bf..5d77670 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b { unsigned int plane; + if (V4L2_TYPE_IS_OUTPUT(b-type)) { + if (WARN_ON_ONCE(b-bytesused == 0)) { + pr_warn_once(use of bytesused == 0 is deprecated and will be removed in 2017,\n); + if (vb-vb2_queue-allow_zero_bytesused) + pr_warn_once(use VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n); + else + pr_warn_once(use the actual size instead.\n); + } + } + if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) { if (b-memory == V4L2_MEMORY_USERPTR) { for (plane = 0; plane vb-num_planes; ++plane) { @@ -1276,13 +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b * userspace clearly never bothered to set it and * it's a safe assumption that they really meant to * use the full plane sizes. +* +* Some drivers, e.g. old codec drivers, use bytesused +* == 0 as a way to indicate that streaming is finished. +* In that case, the driver should use the +* allow_zero_bytesused flag to keep old userspace +* applications working. */ for (plane = 0; plane vb-num_planes; ++plane) { struct v4l2_plane *pdst = v4l2_planes[plane]; struct v4l2_plane *psrc = b-m.planes[plane]; - pdst-bytesused = psrc-bytesused ? - psrc-bytesused : pdst-length; + if (vb-vb2_queue-allow_zero_bytesused) + pdst-bytesused = psrc-bytesused; + else + pdst-bytesused = psrc-bytesused ? + psrc-bytesused : pdst-length; pdst-data_offset = psrc-data_offset; } } @@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b * * If bytesused == 0 for the output buffer, then fall back * to the full buffer size as that's a sensible default. +* +* Some drivers, e.g. old codec drivers, use bytesused * == 0 as +* a way to indicate that streaming is finished. In that case, +* the driver should use the allow_zero_bytesused flag to keep +* old userspace applications working. */ if (b-memory == V4L2_MEMORY_USERPTR) { v4l2_planes[0].m.userptr = b-m.userptr; @@ -1306,10 +1330,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b v4l2_planes[0].length = b-length; } - if (V4L2_TYPE_IS_OUTPUT(b-type)) - v4l2_planes[0].bytesused = b-bytesused ? - b-bytesused : v4l2_planes[0].length; - else + if (V4L2_TYPE_IS_OUTPUT(b-type)) { + if (vb-vb2_queue-allow_zero_bytesused) + v4l2_planes[0].bytesused = b-bytesused; + else + v4l2_planes[0].bytesused = b-bytesused ? + b-bytesused : v4l2_planes[0].length; + } else v4l2_planes[0].bytesused = 0; } diff --git
[PATCH v5 1/4] vb2: split the io_flags member of vb2_queue into a bit field
This patch splits the io_flags member of vb2_queue into a bit field. Instead of an enum with flags separate bit fields were introduced. Signed-off-by: Kamil Debski k.deb...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/videobuf2-core.c | 17 + include/media/videobuf2-core.h | 18 +- 2 files changed, 14 insertions(+), 21 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index bc08a82..5cd60bf 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2760,7 +2760,8 @@ struct vb2_fileio_data { unsigned int initial_index; unsigned int q_count; unsigned int dq_count; - unsigned int flags; + unsigned read_once:1; + unsigned write_immediately:1; }; /** @@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue *q, int read) */ count = 1; - dprintk(3, setting up file io: mode %s, count %d, flags %08x\n, - (read) ? read : write, count, q-io_flags); + dprintk(3, setting up file io: mode %s, count %d, read_once %d, write_immediately %d\n, + (read) ? read : write, count, q-fileio_read_once, + q-fileio_write_immediately); fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL); if (fileio == NULL) return -ENOMEM; - fileio-flags = q-io_flags; + fileio-read_once = q-fileio_read_once; + fileio-write_immediately = q-fileio_write_immediately; /* * Request buffers and use MMAP type to force driver @@ -3028,13 +3031,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, char __user *data, size_ /* * Queue next buffer if required. */ - if (buf-pos == buf-size || - (!read (fileio-flags VB2_FILEIO_WRITE_IMMEDIATELY))) { + if (buf-pos == buf-size || (!read fileio-write_immediately)) { /* * Check if this is the last buffer to read. */ - if (read (fileio-flags VB2_FILEIO_READ_ONCE) - fileio-dq_count == 1) { + if (read fileio-read_once fileio-dq_count == 1) { dprintk(3, read limit reached\n); return __vb2_cleanup_fileio(q); } diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index bd2cec2..e49dc6b 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -134,17 +134,6 @@ enum vb2_io_modes { }; /** - * enum vb2_fileio_flags - flags for selecting a mode of the file io emulator, - * by default the 'streaming' style is used by the file io emulator - * @VB2_FILEIO_READ_ONCE: report EOF after reading the first buffer - * @VB2_FILEIO_WRITE_IMMEDIATELY: queue buffer after each write() call - */ -enum vb2_fileio_flags { - VB2_FILEIO_READ_ONCE= (1 0), - VB2_FILEIO_WRITE_IMMEDIATELY= (1 1), -}; - -/** * enum vb2_buffer_state - current video buffer state * @VB2_BUF_STATE_DEQUEUED:buffer under userspace control * @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf @@ -346,7 +335,8 @@ struct v4l2_fh; * * @type: queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h * @io_modes: supported io methods (see vb2_io_modes enum) - * @io_flags: additional io flags (see vb2_fileio_flags enum) + * @fileio_read_once: report EOF after reading the first buffer + * @fileio_write_immediately: queue buffer after each write() call * @lock: pointer to a mutex that protects the vb2_queue struct. The * driver can set this to a mutex to let the v4l2 core serialize * the queuing ioctls. If the driver wants to handle locking @@ -396,7 +386,9 @@ struct v4l2_fh; struct vb2_queue { enum v4l2_buf_type type; unsigned intio_modes; - unsigned intio_flags; + unsignedfileio_read_once:1; + unsignedfileio_write_immediately:1; + struct mutex*lock; struct v4l2_fh *owner; -- 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