Re: [Patch v5 12/12] Documention: v4l: Documentation for HEVC CIDs

2017-06-28 Thread Kamil Debski
Hi,

Please find my comments inline.

On 19 June 2017 at 07:10, Smitha T Murthy  wrote:
> 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

2017-06-27 Thread Kamil Debski
   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

2016-07-01 Thread Kamil Debski
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()

2016-06-28 Thread Kamil Debski
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

2016-06-07 Thread Kamil Debski
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

2016-05-24 Thread Kamil Debski
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

2015-12-18 Thread Kamil Debski
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

2015-10-12 Thread Kamil Debski
Hi,

On 12 October 2015 at 12:50, Hans Verkuil  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

>
>>
>>> +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

2015-10-12 Thread Kamil Debski
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

2015-10-07 Thread Kamil Debski
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

2015-10-02 Thread Kamil Debski
 "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

2015-10-02 Thread Kamil Debski
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

2015-08-20 Thread Kamil Debski
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

2015-08-12 Thread Kamil Debski
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

2015-07-23 Thread Kamil Debski
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

2015-06-26 Thread Kamil Debski
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

2015-06-25 Thread Kamil Debski
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

2015-06-23 Thread Kamil Debski
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

2015-06-22 Thread Kamil Debski
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

2015-06-19 Thread Kamil Debski
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

2015-06-18 Thread Kamil Debski
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

2015-06-18 Thread Kamil Debski
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

2015-05-06 Thread Kamil Debski
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

2015-05-06 Thread Kamil Debski
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

2015-05-06 Thread Kamil Debski
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]

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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.

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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.

2015-05-04 Thread Kamil Debski
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

2015-05-04 Thread Kamil Debski
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

2015-04-30 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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.

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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

2015-04-29 Thread Kamil Debski
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.

2015-04-29 Thread Kamil Debski
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

2015-04-27 Thread Kamil Debski
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

2015-04-27 Thread Kamil Debski
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

2015-04-23 Thread Kamil Debski
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

2015-04-23 Thread Kamil Debski
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

2015-04-23 Thread Kamil Debski
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

2015-04-23 Thread Kamil Debski
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.

2015-04-23 Thread Kamil Debski
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

2015-04-23 Thread Kamil Debski
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

2015-04-23 Thread Kamil Debski
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

2015-04-23 Thread Kamil Debski
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

2015-04-23 Thread Kamil Debski
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.

2015-04-23 Thread Kamil Debski
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.

2015-04-20 Thread Kamil Debski
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

2015-04-20 Thread Kamil Debski
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

2015-04-16 Thread Kamil Debski
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.

2015-04-13 Thread Kamil Debski
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

2015-04-08 Thread Kamil Debski
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

2015-04-07 Thread Kamil Debski
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.

2015-03-20 Thread Kamil Debski
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

2015-03-20 Thread Kamil Debski
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.

2015-03-20 Thread Kamil Debski
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.

2015-03-20 Thread Kamil Debski
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

2015-03-20 Thread Kamil Debski
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.

2015-03-20 Thread Kamil Debski
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

2015-03-20 Thread Kamil Debski
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

2015-03-20 Thread Kamil Debski
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

2015-03-18 Thread Kamil Debski
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

2015-03-11 Thread Kamil Debski
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

2015-03-10 Thread Kamil Debski
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

2015-03-10 Thread Kamil Debski
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.

2015-03-09 Thread Kamil Debski
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

2015-03-09 Thread Kamil Debski
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.

2015-03-09 Thread Kamil Debski
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

2015-03-09 Thread Kamil Debski
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.

2015-03-06 Thread Kamil Debski
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

2015-03-05 Thread Kamil Debski
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

2015-03-05 Thread Kamil Debski
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

2015-03-03 Thread Kamil Debski
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

2015-03-03 Thread Kamil Debski
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

2015-02-23 Thread Kamil Debski
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

2015-02-23 Thread Kamil Debski
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

2015-02-23 Thread Kamil Debski
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

2015-02-23 Thread Kamil Debski
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

2015-02-23 Thread Kamil Debski
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

2015-02-20 Thread Kamil Debski
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

2015-02-20 Thread Kamil Debski
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

2015-02-20 Thread Kamil Debski
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


  1   2   3   4   5   6   >