Re: [bug report] [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

[Andrzej Hajda]

On 25.01.2018 13:25, Dan Carpenter wrote:
> On Thu, Jan 25, 2018 at 10:58:45AM +0100, Andrzej Hajda wrote:
>> On 23.01.2018 09:32, Dan Carpenter wrote:
>>> Hello Andrzej Hajda,
>>>
>>> The patch 4d0b0ed63660: "[media] s5p-mfc: use MFC_BUF_FLAG_EOS to
>>> identify last buffers in decoder capture queue" from Oct 7, 2015,
>>> leads to the following static checker warning:
>>>
>>> drivers/media/platform/s5p-mfc/s5p_mfc_dec.c:658 vidioc_dqbuf()
>>> error: buffer overflow 'ctx->dst_bufs' 32 user_rl = '0-u32max'
>>>
>>> drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>>>635  /* Dequeue a buffer */
>>>636  static int vidioc_dqbuf(struct file *file, void *priv, struct 
>>> v4l2_buffer *buf)
>>>637  {
>>>638  const struct v4l2_event ev = {
>>>639  .type = V4L2_EVENT_EOS
>>>640  };
>>>641  struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
>>>642  int ret;
>>>643  
>>>644  if (ctx->state == MFCINST_ERROR) {
>>>645  mfc_err_limited("Call on DQBUF after unrecoverable 
>>> error\n");
>>>646  return -EIO;
>>>647  }
>>>648  
>>>649  switch (buf->type) {
>>>650  case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>>>651  return vb2_dqbuf(>vq_src, buf, file->f_flags & 
>>> O_NONBLOCK);
>>>652  case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>>>653  ret = vb2_dqbuf(>vq_dst, buf, file->f_flags & 
>>> O_NONBLOCK);
>>>654  if (ret)
>>>655  return ret;
>>>656  
>>>657  if (ctx->state == MFCINST_FINISHED &&
>>>658  (ctx->dst_bufs[buf->index].flags & 
>>> MFC_BUF_FLAG_EOS))
>>>^^
>>> Smatch is complaining that "buf->index" is not capped.  So far as I can
>>> see this is true.  I would have expected it to be checked in
>>> check_array_args() or video_usercopy() but I couldn't find the check.
>> I did not work in V4L2 area for long time, so I could be wrong, but I
>> hope the code is correct, below my explanation.
>> User provides only type, memory and reserved fields in buf, other fields
>> are filled by vb2_dqbuf (line 653) core function, ie index field is
>> copied from buffer which was queued by qbuf.
>> And vidioc_qbuf calls vb2_qbuf, which calls vb2_queue_or_prepare_buf,
>> which checks index bounds [1].
>>
>> So I suppose this code is correct.
>> Btw, I have also looked at other drivers and it looks omap driver
>> handles it incorrectly, ie it uses index field provided by user -
>> possible memory leak. CC Hans and Mauro, since there is no driver
>> maintainer of OMAP.
>>
>> Btw2, is it possible to check in smatch which fields of passed struct
>> given callback can read or fill ? For example here API restrict dqbuf
>> callback to read only three fields of buf, and fill the others.
>>
>> [1]:
>> http://elixir.free-electrons.com/linux/latest/source/drivers/media/v4l2-core/videobuf2-v4l2.c#L165
>> [2]:
>> http://elixir.free-electrons.com/linux/latest/source/drivers/media/platform/omap/omap_vout.c#L1520
>>
>> Regards
>> Andrzej
> Smatch does track the feilds...  Smatch sees that buf->index is capped
> in vidioc_qbuf() but it still complains that buf->index gets set by the
> user in the ioctl and not checked before we use it vb2_dqbuf().  The
> call tree looks like this:
>
> --> video_usercopy()
> Copies _IOC_SIZE(cmd) bytes to parg.  The _IOC_SIZE() is
> sizeof(struct v4l2_buffer) so all the feilds are reset.  Smatch
> doesn't track how many bytes the users controls, it just marks
> everything in *parg as tainted but it doesn't matter in this case
> since all the feilds are set.
> video_usercopy() calls err = func(file, cmd, parg);
>
> --> __video_do_ioctl()
> calls info->u.func(ops, file, fh, arg);
>
> --> v4l_dqbuf()
> calls ops->vidioc_dqbuf(file, fh, p);
>
> --> vidioc_dqbuf()

In our case s5p_mfc_dec.c:vidioc_dqbuf

> uses unchecked buf->index

No, it uses only buf->type (it is correct usage), then calls
vb2_dqbuf(which should fill index and other fields with proper values),
and then uses .index.

> Ah...  Hm.  Is it the call to vb2_core_dqbuf() which limits buf->index?

No, buf->index is bound checked at buffer queuing:
s5p_mfc_dec.c:vidioc_qbuf
    vb2_qbuf
        vb2_queue_or_prepare_buf

> I don't see a path from vb2_core_dqbuf() to vb2_qbuf() but I may have
> missed it.

It is reverse:
s5p_mfc_dec.c:vidioc_dqbuf
    vb2_dqbuf
        vb2_core_dqbuf

Regards
Andrzej

>
> regards,
> dan carpenter
>
>
>
>

Re: [bug report] [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

[Andrzej Hajda]

On 23.01.2018 09:32, Dan Carpenter wrote:
> Hello Andrzej Hajda,
>
> The patch 4d0b0ed63660: "[media] s5p-mfc: use MFC_BUF_FLAG_EOS to
> identify last buffers in decoder capture queue" from Oct 7, 2015,
> leads to the following static checker warning:
>
>   drivers/media/platform/s5p-mfc/s5p_mfc_dec.c:658 vidioc_dqbuf()
>   error: buffer overflow 'ctx->dst_bufs' 32 user_rl = '0-u32max'
>
> drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>635  /* Dequeue a buffer */
>636  static int vidioc_dqbuf(struct file *file, void *priv, struct 
> v4l2_buffer *buf)
>637  {
>638  const struct v4l2_event ev = {
>639  .type = V4L2_EVENT_EOS
>640  };
>641  struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
>642  int ret;
>643  
>644  if (ctx->state == MFCINST_ERROR) {
>645  mfc_err_limited("Call on DQBUF after unrecoverable 
> error\n");
>646  return -EIO;
>647  }
>648  
>649  switch (buf->type) {
>650  case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>651  return vb2_dqbuf(>vq_src, buf, file->f_flags & 
> O_NONBLOCK);
>652  case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>653  ret = vb2_dqbuf(>vq_dst, buf, file->f_flags & 
> O_NONBLOCK);
>654  if (ret)
>655  return ret;
>656  
>657  if (ctx->state == MFCINST_FINISHED &&
>658  (ctx->dst_bufs[buf->index].flags & 
> MFC_BUF_FLAG_EOS))
>^^
> Smatch is complaining that "buf->index" is not capped.  So far as I can
> see this is true.  I would have expected it to be checked in
> check_array_args() or video_usercopy() but I couldn't find the check.

I did not work in V4L2 area for long time, so I could be wrong, but I
hope the code is correct, below my explanation.
User provides only type, memory and reserved fields in buf, other fields
are filled by vb2_dqbuf (line 653) core function, ie index field is
copied from buffer which was queued by qbuf.
And vidioc_qbuf calls vb2_qbuf, which calls vb2_queue_or_prepare_buf,
which checks index bounds [1].

So I suppose this code is correct.
Btw, I have also looked at other drivers and it looks omap driver
handles it incorrectly, ie it uses index field provided by user -
possible memory leak. CC Hans and Mauro, since there is no driver
maintainer of OMAP.

Btw2, is it possible to check in smatch which fields of passed struct
given callback can read or fill ? For example here API restrict dqbuf
callback to read only three fields of buf, and fill the others.

[1]:
http://elixir.free-electrons.com/linux/latest/source/drivers/media/v4l2-core/videobuf2-v4l2.c#L165
[2]:
http://elixir.free-electrons.com/linux/latest/source/drivers/media/platform/omap/omap_vout.c#L1520

Regards
Andrzej
>
>659  v4l2_event_queue_fh(>fh, );
>660  return 0;
>661  default:
>662  return -EINVAL;
>663  }
>664  }
>
>
> regards,
> dan carpenter
>
>
>

Re: [PATCH 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state

[Andrzej Hajda]

On 06.10.2017 23:30, Shuah Khan wrote:
> Driver calls request_firmware() whenever the device is opened for the
> first time. As the device gets opened and closed, dev->num_inst == 1
> is true several times. This is not necessary since the firmware is saved
> in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by
> the request_firmware() to dev->fw_buf.
>
> fw_buf sticks around until it gets released from s5p_mfc_remove(), hence
> there is no need to keep requesting firmware and copying it to fw_buf.
>
> This might have been overlooked when changes are made to free fw_buf from
> the device release interface s5p_mfc_release().
>
> Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state.
> Change _probe() to load firmware once fw_buf has been allocated.
>
> s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init
> hardware which is the step where firmware is written to the device.
>
> This addresses the mfc_mutex contention due to repeated request_firmware()
> calls from open() in the following circular locking warning:
>
> [  552.194115] qtdemux0:sink/2710 is trying to acquire lock:
> [  552.199488]  (>mfc_mutex){+.+.}, at: [] 
> s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
> [  552.207459]
>but task is already holding lock:
> [  552.213264]  (>mmap_sem){}, at: [] 
> vm_mmap_pgoff+0x44/0xb8
> [  552.220284]
>which lock already depends on the new lock.
>
> [  552.228429]
>the existing dependency chain (in reverse order) is:
> [  552.235881]
>-> #2 (>mmap_sem){}:
> [  552.241259]__might_fault+0x80/0xb0
> [  552.245331]filldir64+0xc0/0x2f8
> [  552.249144]call_filldir+0xb0/0x14c
> [  552.253214]ext4_readdir+0x768/0x90c
> [  552.257374]iterate_dir+0x74/0x168
> [  552.261360]SyS_getdents64+0x7c/0x1a0
> [  552.265608]ret_fast_syscall+0x0/0x28
> [  552.269850]
>-> #1 (>i_mutex_dir_key#2){}:
> [  552.276180]down_read+0x48/0x90
> [  552.279904]lookup_slow+0x74/0x178
> [  552.283889]walk_component+0x1a4/0x2e4
> [  552.288222]link_path_walk+0x174/0x4a0
> [  552.292555]path_openat+0x68/0x944
> [  552.296541]do_filp_open+0x60/0xc4
> [  552.300528]file_open_name+0xe4/0x114
> [  552.304772]filp_open+0x28/0x48
> [  552.308499]kernel_read_file_from_path+0x30/0x78
> [  552.313700]_request_firmware+0x3ec/0x78c
> [  552.318291]request_firmware+0x3c/0x54
> [  552.322642]s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc]
> [  552.328358]s5p_mfc_open+0x4e4/0x550 [s5p_mfc]
> [  552.94]v4l2_open+0xa0/0x104 [videodev]
> [  552.338137]chrdev_open+0xa4/0x18c
> [  552.342121]do_dentry_open+0x208/0x310
> [  552.346454]path_openat+0x28c/0x944
> [  552.350526]do_filp_open+0x60/0xc4
> [  552.354512]do_sys_open+0x118/0x1c8
> [  552.358586]ret_fast_syscall+0x0/0x28
> [  552.362830]
>-> #0 (>mfc_mutex){+.+.}:
>-> #0 (>mfc_mutex){+.+.}:
> [  552.368379]lock_acquire+0x6c/0x88
> [  552.372364]__mutex_lock+0x68/0xa34
> [  552.376437]mutex_lock_interruptible_nested+0x1c/0x24
> [  552.382086]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
> [  552.386939]v4l2_mmap+0x54/0x88 [videodev]
> [  552.391601]mmap_region+0x3a8/0x638
> [  552.395673]do_mmap+0x330/0x3a4
> [  552.399400]vm_mmap_pgoff+0x90/0xb8
> [  552.403472]SyS_mmap_pgoff+0x90/0xc0
> [  552.407632]ret_fast_syscall+0x0/0x28
> [  552.411876]
>other info that might help us debug this:
>
> [  552.419848] Chain exists of:
>  >mfc_mutex --> >i_mutex_dir_key#2 --> 
> >mmap_sem
>
> [  552.431200]  Possible unsafe locking scenario:
>
> [  552.437092]CPU0CPU1
> [  552.441598]
> [  552.446104]   lock(>mmap_sem);
> [  552.449484]lock(>i_mutex_dir_key#2);
> [  552.456329]lock(>mmap_sem);
> [  552.46]   lock(>mfc_mutex);
> [  552.465775]
> *** DEADLOCK ***

I am not 100% but it looks like false positive. Could you describe
scenario when it deadlocks?

>
> Signed-off-by: Shuah Khan 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c| 4 
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 5 +
>  3 files changed, 12 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 1afde50..4c253fb 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1315,6 +1315,10 @@ static int s5p_mfc_probe(struct platform_device *pdev)
>   goto err_dma;
>   }
>  
> + ret = 

Re: [PATCH 1/2] media: s5p-mfc: check for firmware allocation before requesting firmware

[Andrzej Hajda]

Hi Shuah,

On 06.10.2017 23:30, Shuah Khan wrote:
> Check if firmware is allocated before requesting firmware instead of
> requesting firmware only to release it if firmware is not allocated.
>
> Signed-off-by: Shuah Khan 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> index 69ef9c2..f064a0d1 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> @@ -55,6 +55,11 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
>* into kernel. */
>   mfc_debug_enter();
>  
> + if (!dev->fw_buf.virt) {
> + mfc_err("MFC firmware is not allocated\n");
> + return -EINVAL;
> + }
> +
>   for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
>   if (!dev->variant->fw_name[i])
>   continue;
> @@ -75,11 +80,6 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
>   release_firmware(fw_blob);
>   return -ENOMEM;
>   }
> - if (!dev->fw_buf.virt) {
> - mfc_err("MFC firmware is not allocated\n");
> - release_firmware(fw_blob);
> - return -EINVAL;
> - }

Is there any scenario in which dev->fw_buf.virt is null and
s5p_mfc_load_firmware is called?
I suspect this check is not necessary at all.

Regards
Andrzej

>   memcpy(dev->fw_buf.virt, fw_blob->data, fw_blob->size);
>   wmb();
>   release_firmware(fw_blob);

Re: [PATCH v2 05/26] media: s5c73m3-core: fix logic on a timeout condition

[Andrzej Hajda]

On 01.11.2017 22:05, Mauro Carvalho Chehab wrote:
> As warned by smatch:
>   drivers/media/i2c/s5c73m3/s5c73m3-core.c:268 s5c73m3_check_status() 
> error: uninitialized symbol 'status'.
>
> if s5c73m3_check_status() is called too late, time_is_after_jiffies(end)
> will return 0, causing the while to abort before reading status.
>
> The current code will do the wrong thing here, as it will still
> check if status != value. The right fix here is to just change
> the initial state of ret to -ETIMEDOUT. This way, if the
> routine is called too late, it will skip the flawed check
> and return that a timeout happened.

First of all it is rather uncommon situation, scenario in which two
consecutive lines of simple code takes more than 2 seconds is rather rare.
Of course it is possible but in such case proposed solution does not
look like as a proper fix, it reports timeout on the sensor without even
touching it.
I think the right fix would be to re-factor the loop to read the status
first and check timeout later.

Regards
Andrzej

>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c 
> b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> index cdc4f2392ef9..45345f8b27a5 100644
> --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> @@ -248,7 +248,7 @@ static int s5c73m3_check_status(struct s5c73m3 *state, 
> unsigned int value)
>  {
>   unsigned long start = jiffies;
>   unsigned long end = start + msecs_to_jiffies(2000);
> - int ret = 0;
> + int ret = -ETIMEDOUT;
>   u16 status;
>   int count = 0;
>  

Re: [PATCH v4] drm/bridge/sii8620: add remote control support

[Andrzej Hajda]

On 09.10.2017 10:44, Sean Young wrote:
> Hi,
>
> On Thu, Sep 21, 2017 at 12:46:04PM +0100, Sean Young wrote:
>> On Mon, Sep 18, 2017 at 04:37:52PM +0200, Hans Verkuil wrote:
>>> On 09/18/2017 04:15 PM, Maciej Purski wrote:
 Hi Hans,
 some time ago in reply to your email I described what messages does
 the MHL driver receive and at what time intervals.
 Regarding that information, do you think that a similar solution as
 in [1] is required? Would it be OK, if I just set REP_DELAY and REP_PERIOD
 to values, which I presented in my last email?
>>> Based on the timings you measured I would say that there is a 99% chance 
>>> that MHL
>>> uses exactly the same "Press and Hold" mechanism as CEC. Since you already 
>>> specify
>>> RC_PROTO_BIT_CEC in the driver, it will set REP_DELAY and REP_PERIOD to the 
>>> right
>>> values automatically.
>>>
>>> You will have to implement the same code as in cec-adap.c for the key press 
>>> handling,
>>> though. It's a bit tricky to get it right.
>>>
>>> Since you will have to do the same thing as I do in CEC, I wonder if it 
>>> would make
>>> more sense to move this code to the RC core. Basically it ensures that 
>>> repeat mode
>>> doesn't turn on until you get two identical key presses 550ms or less 
>>> apart. This
>>> is independent of REP_DELAY which can be changed by userspace.
>>>
>>> Sean, what do you think?
>> Yes, this makes sense. In fact, since IR protocols have different repeat
>> times, I would like to make this protocol dependant anyway.
>>
>> To be honest I find REP_DELAY of 500ms too long and REP_PERIOD of 125ms
>> too short; IOW it takes too long for a key to start repeating, and once
>> it starts repeating it is very hard to control. If I try to increase the
>> volume with my remote it first hardly changes at all and then after 500ms
>> the volume shoots up far too quickly, same thing when navigating menus.
>>
>> CEC dictates a delay period of 550ms, which is not great for the user IMO.
>>
>> Anyway I'll have a look at this over the weekend.
> I have started on this, but I haven't gotten it in a state where I'm
> happy to submit it. I hope to have it ready for v4.15; in the mean time,
> there is no reason to block this patch on this.
>
>
> Sean
>
>
>

Queued to drm-misc-next.

Thanks
Andrzej

Re: [PATCH] drm/bridge/sii8620: add remote control support

[Andrzej Hajda]

On 03.08.2017 10:28, Hans Verkuil wrote:
> Hi Maciej,
>
> Unfortunately I do not have the MHL spec, but I was wondering what the
> relationship between RCP and CEC is. CEC has remote control support as
> well, so is RCP that subset of the CEC specification or is it completely
> separate?

We also do not have MHL specs. From my research it looks like MHL
consortium was mainly focused on supporting different input devices -
remote control, mice, keyboard, touchscreen, game controller, etc. In
public data sheets of some chips Lattice/Silicon Image (main MHL chip
producer) suggest they do not support CEC pass-through via MHL[1].
On the other side superMHL extends RCP with support for multiple devices
[2], so for me it looks like RCP wants to be an alternative to CEC.
But all this is just my interpretation of info found on the Net.

[1]:
http://www.latticesemi.com/~/media/LatticeSemi/Documents/DataSheets/ASSP/SiI-DS-1128_Public.pdf?document_id=51627
[2]: https://en.wikipedia.org/wiki/Mobile_High-Definition_Link#superMHL

Regards
Andrzej

>
> I'm CC-ing Sean Young and the linux-media mailinglist as well since Sean
> maintains the rc subsystem. Which you probably should use, but I'm not the
> expert on that.
>
> Regards,
>
>   Hans
>
> On 08/03/17 09:44, Maciej Purski wrote:
>> MHL specification defines Remote Control Protocol(RCP) to
>> send input events between MHL devices.
>> The driver now recognizes RCP messages and reacts to them
>> by reporting key events to input subsystem, allowing
>> a user to control a device using TV remote control.
>>
>> Signed-off-by: Maciej Purski 
>> ---
>>  drivers/gpu/drm/bridge/sil-sii8620.c | 188 
>> ++-
>>  include/drm/bridge/mhl.h |   4 +
>>  2 files changed, 187 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>> index 2d51a22..7e75f2f 100644
>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -58,6 +59,7 @@ enum sii8620_mt_state {
>>  struct sii8620 {
>>  struct drm_bridge bridge;
>>  struct device *dev;
>> +struct input_dev *rcp_input_dev;
>>  struct clk *clk_xtal;
>>  struct gpio_desc *gpio_reset;
>>  struct gpio_desc *gpio_int;
>> @@ -106,6 +108,82 @@ struct sii8620_mt_msg {
>>  sii8620_cb continuation;
>>  };
>>  
>> +static struct {
>> +u16 key;
>> +u16 extra_key;
>> +bool autorepeat;
>> +}  rcp_keymap[] = {
>> +[0x00] = { KEY_SELECT },
>> +[0x01] = { KEY_UP, 0, true },
>> +[0x02] = { KEY_DOWN, 0, true },
>> +[0x03] = { KEY_LEFT, 0, true },
>> +[0x04] = { KEY_RIGHT, 0, true },
>> +
>> +[0x05] = { KEY_RIGHT, KEY_UP, true },
>> +[0x06] = { KEY_RIGHT, KEY_DOWN, true },
>> +[0x07] = { KEY_LEFT,  KEY_UP, true },
>> +[0x08] = { KEY_LEFT,  KEY_DOWN, true },
>> +
>> +[0x09] = { KEY_MENU },
>> +[0x0A] = { KEY_UNKNOWN },
>> +[0x0B] = { KEY_UNKNOWN },
>> +[0x0C] = { KEY_BOOKMARKS },
>> +[0x0D] = { KEY_EXIT },
>> +
>> +[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 },
>> +
>> +[0x30] = { KEY_CHANNELUP, 0, true },
>> +[0x31] = { KEY_CHANNELDOWN, 0, true },
>> +
>> +[0x33] = { KEY_SOUND },
>> +[0x35] = { KEY_PROGRAM }, /* Show Information */
>> +
>> +[0x37] = { KEY_PAGEUP, 0, true },
>> +[0x38] = { KEY_PAGEDOWN, 0, true },
>> +
>> +[0x41] = { KEY_VOLUMEUP, 0, true },
>> +[0x42] = { KEY_VOLUMEDOWN, 0, true },
>> +[0x43] = { KEY_MUTE },
>> +[0x44] = { KEY_PLAY },
>> +[0x45] = { KEY_STOP },
>> +[0x46] = { KEY_PLAYPAUSE }, /* Pause */
>> +[0x47] = { KEY_RECORD },
>> +[0x48] = { KEY_REWIND, 0, true },
>> +[0x49] = { KEY_FASTFORWARD, 0, true },
>> +[0x4A] = { KEY_EJECTCD },
>> +[0x4B] = { KEY_NEXTSONG, 0, true }, /* Forward */
>> +[0x4C] = { KEY_PREVIOUSSONG, 0, true }, /* Backward */
>> +
>> +[0x60] = { KEY_PLAYPAUSE }, /* Play */
>> +[0x61] = { KEY_PLAYPAUSE }, /* Pause the Play */
>> +[0x62] = { KEY_RECORD },
>> +[0x63] = { KEY_PAUSE },
>> +[0x64] = { KEY_STOP },
>> +[0x65] = { KEY_MUTE },
>> +[0x66] = { KEY_MUTE }, /* Restore Mute */
>> +
>> +[0x71] = { KEY_F1 },
>> +[0x72] = { KEY_F2 },
>> +[0x73] = { KEY_F3 },
>> +[0x74] = { KEY_F4 },
>> +[0x75] = { KEY_F5 },
>> +
>> +[0x7E] = { KEY_VENDOR },
>> +};
>> +
>>  static const u8 sii8620_i2c_page[] = {
>>  

Re: [PATCH] s5k5baf: remove unnecessary static in s5k5baf_get_selection()

[Andrzej Hajda]

On 05.07.2017 20:07, Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variable rtype.
> Such variable is initialized before being used,
> on every execution path throughout the function.
> The static has no benefit and, removing it reduces
> the code size.
>
> This issue was detected using Coccinelle and the following semantic patch:
>
> @bad exists@
> position p;
> identifier x;
> type T;
> @@
>
> static T x@p;
> ...
> x = <+...x...+>
>
> @@
> identifier x;
> expression e;
> type T;
> position p != bad.p;
> @@
>
> -static
>  T x@p;
>  ... when != x
>  when strict
> ?x = e;
>
> In the following log you can see the difference in the code size. Also,
> there is a significant difference in the bss segment. This log is the
> output of the size command, before and after the code change:
>
> before:
>textdata bss dec hex filename
>   277655656 320   3374183cd drivers/media/i2c/s5k5baf.o
>
> after:
>textdata bss dec hex filename
>   277335600     256   335898335 drivers/media/i2c/s5k5baf.o
>
>
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>

Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

 --
Regards
Andrzej

> ---
>  drivers/media/i2c/s5k5baf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
> index 962051b..f01722d 100644
> --- a/drivers/media/i2c/s5k5baf.c
> +++ b/drivers/media/i2c/s5k5baf.c
> @@ -1374,7 +1374,7 @@ static int s5k5baf_get_selection(struct v4l2_subdev *sd,
>struct v4l2_subdev_pad_config *cfg,
>struct v4l2_subdev_selection *sel)
>  {
> - static enum selection_rect rtype;
> + enum selection_rect rtype;
>   struct s5k5baf *state = to_s5k5baf(sd);
>  
>   rtype = s5k5baf_get_sel_rect(sel->pad, sel->target);

Re: [ANN] HDMI CEC Status Update

[Andrzej Hajda]

On 30.05.2017 08:53, Hans Verkuil wrote:
> For those who are interested in HDMI CEC support I made a little status
> document that I intend to keep up to date:
>
> https://hverkuil.home.xs4all.nl/cec-status.txt
>
> My goal is to get CEC supported for any mainlined HDMI driver where the 
> hardware
> supports CEC.
>
> If anyone is working on a CEC driver that I don't know already about, just 
> drop
> me an email so I can update the status.

Sii8620 HDMI->MHL bridge is on my TODO list.
Regarding Exynos5 it is apparently the same IP as in Exynos4.

Regards
Andrzej

Re: [PATCHv6 03/10] exynos_hdmi: add CEC notifier support

[Andrzej Hajda]

On 31.03.2017 14:20, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verk...@cisco.com>
>
> Implement the CEC notifier support to allow CEC drivers to
> be informed when there is a new physical address.
>
> Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>
> Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> Acked-by: Krzysztof Kozlowski <k...@kernel.org>

Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

 --
Regards
Andrzej

> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 88ccc0469316..bc4c8d0a66f4 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -43,6 +43,8 @@
>  
>  #include 
>  
> +#include 
> +
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_crtc.h"
>  
> @@ -119,6 +121,7 @@ struct hdmi_context {
>   booldvi_mode;
>   struct delayed_work hotplug_work;
>   struct drm_display_mode current_mode;
> + struct cec_notifier *notifier;
>   const struct hdmi_driver_data   *drv_data;
>  
>   void __iomem*regs;
> @@ -822,6 +825,7 @@ static enum drm_connector_status hdmi_detect(struct 
> drm_connector *connector,
>   if (gpiod_get_value(hdata->hpd_gpio))
>   return connector_status_connected;
>  
> + cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
>   return connector_status_disconnected;
>  }
>  
> @@ -860,6 +864,7 @@ static int hdmi_get_modes(struct drm_connector *connector)
>   edid->width_cm, edid->height_cm);
>  
>   drm_mode_connector_update_edid_property(connector, edid);
> + cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid);
>  
>   ret = drm_add_edid_modes(connector, edid);
>  
> @@ -1503,6 +1508,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
>   if (funcs && funcs->disable)
>   (*funcs->disable)(crtc);
>  
> + cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
>   cancel_delayed_work(>hotplug_work);
>  
>   hdmiphy_disable(hdata);
> @@ -1878,15 +1884,22 @@ static int hdmi_probe(struct platform_device *pdev)
>   }
>   }
>  
> + hdata->notifier = cec_notifier_get(>dev);
> + if (hdata->notifier == NULL) {
> + ret = -ENOMEM;
> + goto err_hdmiphy;
> + }
> +
>   pm_runtime_enable(dev);
>  
>   ret = component_add(>dev, _component_ops);
>   if (ret)
> - goto err_disable_pm_runtime;
> + goto err_notifier_put;
>  
>   return ret;
>  
> -err_disable_pm_runtime:
> +err_notifier_put:
> + cec_notifier_put(hdata->notifier);
>   pm_runtime_disable(dev);
>  
>  err_hdmiphy:
> @@ -1905,9 +1918,11 @@ static int hdmi_remove(struct platform_device *pdev)
>   struct hdmi_context *hdata = platform_get_drvdata(pdev);
>  
>   cancel_delayed_work_sync(>hotplug_work);
> + cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
>  
>   component_del(>dev, _component_ops);
>  
> + cec_notifier_put(hdata->notifier);
>   pm_runtime_disable(>dev);
>  
>   if (!IS_ERR(hdata->reg_hdmi_en))

Re: [Patch v3 10/11] [media] s5p-mfc: Add support for HEVC encoder

[Andrzej Hajda]

On 31.03.2017 11:06, Smitha T Murthy wrote:
> Add HEVC encoder support and necessary registers, V4L2 CIDs,
> and hevc encoder parameters
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |  28 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|   1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |   3 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  57 ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 595 
> 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|   8 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 194 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |   8 +
>  8 files changed, 892 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index 6754477..7065b9d 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -20,13 +20,35 @@
>  #define S5P_FIMV_MFC_STATE_V10   0x7124
>  #define S5P_FIMV_D_STATIC_BUFFER_ADDR_V100xF570
>  #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V100xF574
> +#define S5P_FIMV_E_NUM_T_LAYER_V10   0xFBAC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V100xFBB0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V100xFBB4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V100xFBB8
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V100xFBBC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V100xFBC0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V100xFBC4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V100xFBC8
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V10  0xFD18
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V10  0xFD1C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V10  0xFD20
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V10  0xFD24
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V10  0xFD28
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V10  0xFD2C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V10  0xFD30
> +#define S5P_FIMV_E_HEVC_OPTIONS_V10  0xFDD4
> +#define S5P_FIMV_E_HEVC_REFRESH_PERIOD_V10   0xFDD8
> +#define S5P_FIMV_E_HEVC_CHROMA_QP_OFFSET_V10 0xFDDC
> +#define S5P_FIMV_E_HEVC_LF_BETA_OFFSET_DIV2_V10  0xFDE0
> +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V100xFDE4
> +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V10  0xFDE8
>  
>  /* MFCv10 Context buffer sizes */
>  #define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)
>  #define MFC_H264_DEC_CTX_BUF_SIZE_V10(2 * SZ_1M)
>  #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10   (20 * SZ_1K)
>  #define MFC_H264_ENC_CTX_BUF_SIZE_V10(100 * SZ_1K)
> -#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10   (15 * SZ_1K)
> +#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10(30 * SZ_1K)
> +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10  (15 * SZ_1K)
>  
>  /* MFCv10 variant defines */
>  #define MAX_FW_SIZE_V10  (SZ_1M)
> @@ -58,5 +80,9 @@
>  #define ENC_V100_VP8_ME_SIZE(x, y) \
>   ENC_V100_BASE_SIZE(x, y)
>  
> +#define ENC_V100_HEVC_ME_SIZE(x, y)  \
> + (((x + 3) * (y + 3) * 32)   \
> +  + ((y * 128) + 1280) * DIV_ROUND_UP(x, 4))
> +
>  #endif /*_REGS_MFC_V10_H*/
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 399c547..b3862d1 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1554,6 +1554,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
>   .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
>   .other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
>   .h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V10,
> + .hevc_enc_ctx   = MFC_HEVC_ENC_CTX_BUF_SIZE_V10,
>   .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
>  };
>  
> 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 102b47e..7521fce 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -122,6 +122,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_VP8_ENC:
>   codec_type = S5P_FIMV_CODEC_VP8_ENC_V7;
>   break;
> + case S5P_MFC_CODEC_HEVC_ENC:
> + codec_type = S5P_FIMV_CODEC_HEVC_ENC;
> + break;
>   default:
>   codec_type = S5P_FIMV_CODEC_NONE_V6;
>   }
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 4082079..ad06e45 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -68,7 +68,7 @@ static 

Re: [Patch v3 04/11] [media] s5p-mfc: Support MFCv10.10 buffer requirements

[Andrzej Hajda]

On 31.03.2017 11:06, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy <smith...@samsung.com>

Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
--
Regards
Andrzej

Re: [Patch v3 00/11] Add MFC v10.10 support

[Andrzej Hajda]

Hi Smitha,

On 31.03.2017 11:06, Smitha T Murthy wrote:
> This patch series adds MFC v10.10 support. MFC v10.10 is used in some
> of Exynos7 variants.

Patch does not apply, please rebase on top of:
   

git://linuxtv.org/snawrocki/samsung.git for-v4.12/media/next


Additionally quick test shows you do not handle 
V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_CH in s5p_mfc_enc_s_ctrl.

Regards
Andrzej

>
> This adds support for following:
>
> * Add support for HEVC encoder and decoder
> * Add support for VP9 decoder
> * Update Documentation for control id definitions
> * Update computation of min scratch buffer size requirement for V8 onwards
>
> Changes since v2:
>  - Addressed review comments by Andrzej Hajda.
>  - Rebased on latest krzk/for-next tree.
>  - This patches are tested on top of Marek's patch v2 [1]
>  - Applied acked-by and r-o-b from Andrzej on respective patches.
>  - Applied acked-by from Rob Herring on respective patch.
>
> [1]: http://www.mail-archive.com/linux-media@vger.kernel.org/msg108520.html
>
> Smitha T Murthy (11):
>   [media] s5p-mfc: Rename IS_MFCV8 macro
>   [media] s5p-mfc: Adding initial support for MFC v10.10
>   [media] s5p-mfc: Use min scratch buffer size as provided by F/W
>   [media] s5p-mfc: Support MFCv10.10 buffer requirements
>   [media] videodev2.h: Add v4l2 definition for HEVC
>   [media] s5p-mfc: Add support for HEVC decoder
>   Documentation: v4l: Documentation for HEVC v4l2 definition
>   [media] s5p-mfc: Add VP9 decoder support
>   [media] v4l2: Add v4l2 control IDs for HEVC encoder
>   [media] s5p-mfc: Add support for HEVC encoder
>   Documention: v4l: Documentation for HEVC CIDs
>
>  .../devicetree/bindings/media/s5p-mfc.txt  |   1 +
>  Documentation/media/uapi/v4l/extended-controls.rst | 355 
>  Documentation/media/uapi/v4l/pixfmt-013.rst|   5 +
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |  88 +++
>  drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc.c   |  33 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c|   9 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  71 ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |   6 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |  50 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   | 616 
> -
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h   |  14 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 410 --
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|  15 +
>  drivers/media/v4l2-core/v4l2-ctrls.c   | 103 
>  include/uapi/linux/v4l2-controls.h | 133 +
>  include/uapi/linux/videodev2.h |   1 +
>  17 files changed, 1835 insertions(+), 77 deletions(-)
>  create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>

Re: [Patch v2 10/11] s5p-mfc: Add support for HEVC encoder

[Andrzej Hajda]

Hi Smitha,

Sorry for late reply, it seems I have missed this email.


On 14.03.2017 12:41, Smitha T Murthy wrote:
> On Tue, 2017-03-07 at 12:33 +0100, Andrzej Hajda wrote: 
>> On 03.03.2017 10:07, Smitha T Murthy wrote:
>>> Add HEVC encoder support and necessary registers, V4L2 CIDs,
>>> and hevc encoder parameters
>>>
>>> Signed-off-by: Smitha T Murthy <smith...@samsung.com>
>>> ---
>>>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   28 +-
>>>  drivers/media/platform/s5p-mfc/s5p_mfc.c|1 +
>>>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +
>>>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |   55 ++-
>>>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  595 
>>> +++
>>>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|8 +
>>>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  200 
>>>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |8 +
>>>  8 files changed, 896 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
>>> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>>> index 846dcf5..caf02ff 100644
>>> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>>> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>>> @@ -20,13 +20,35 @@
>>>  #define S5P_FIMV_MFC_STATE_V10 0x7124
>>>  #define S5P_FIMV_D_STATIC_BUFFER_ADDR_V10  0xF570
>>>  #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V10  0xF574
>>> +#define S5P_FIMV_E_NUM_T_LAYER_V10 0xFBAC
>>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V10  0xFBB0
>>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V10  0xFBB4
>>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V10  0xFBB8
>>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V10  0xFBBC
>>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V10  0xFBC0
>>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V10  0xFBC4
>>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V10  0xFBC8
>>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V100xFD18
>>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V100xFD1C
>>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V100xFD20
>>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V100xFD24
>>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V100xFD28
>>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V100xFD2C
>>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V100xFD30
>>> +#define S5P_FIMV_E_HEVC_OPTIONS_V100xFDD4
>>> +#define S5P_FIMV_E_HEVC_REFRESH_PERIOD_V10 0xFDD8
>>> +#define S5P_FIMV_E_HEVC_CHROMA_QP_OFFSET_V10   0xFDDC
>>> +#define S5P_FIMV_E_HEVC_LF_BETA_OFFSET_DIV2_V100xFDE0
>>> +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V10  0xFDE4
>>> +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V100xFDE8
>>>  
>>>  /* MFCv10 Context buffer sizes */
>>>  #define MFC_CTX_BUF_SIZE_V10   (30 * SZ_1K)/* 30KB */
>>>  #define MFC_H264_DEC_CTX_BUF_SIZE_V10  (2 * SZ_1M) /* 2MB */
>>>  #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)/* 20KB */
>>>  #define MFC_H264_ENC_CTX_BUF_SIZE_V10  (100 * SZ_1K)   /* 100KB */
>>> -#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)/* 15KB */
>>> +#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10  (30 * SZ_1K)/* 30KB */
>>> +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10  (15 * SZ_1K)   /* 15KB */
>>>  
>>>  /* MFCv10 variant defines */
>>>  #define MAX_FW_SIZE_V10(SZ_1M) /* 1MB */
>>> @@ -58,5 +80,9 @@
>>>  #define ENC_V100_VP8_ME_SIZE(x, y) \
>>> ENC_V100_BASE_SIZE(x, y)
>>>  
>>> +#define ENC_V100_HEVC_ME_SIZE(x, y)\
>>> +   (((x + 3) * (y + 3) * 32)   \
>>> ++ ((y * 128) + 1280) * DIV_ROUND_UP(x, 4))
>>> +
>>>  #endif /*_REGS_MFC_V10_H*/
>>>  
>>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
>>> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> index b014038..b01c556 100644
>>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> @@ -1549,6 +1549,7 @@ static int s5p_mfc_resume(struct device *dev)
>>> .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
>>> .other_dec

Re: [PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Andrzej Hajda]

Hi Marian,

On 15.03.2017 12:36, Marian Mihailescu wrote:
> Hi,
> 
> After testing these patches, encoding using MFC fails when requesting
> buffers for capture (it works for output) with ENOMEM (it complains it
> cannot allocate memory on bank1).
> Did anyone else test encoding?

I have tested encoding and it works on my test target. Could you provide
more details of your setup:
- which kernel and patches,
- which hw,
- which test app.

Regards
Andrzej


> 
> Thanks,
> Marian
> 
> Either I've been missing something or nothing has been going on. (K. E. 
> Gordon)
> 

Re: [Patch v2 11/11] Documention: v4l: Documentation for HEVC CIDs

[Andrzej Hajda]

On 03.03.2017 10:07, Smitha T Murthy wrote:
> Added V4l2 controls for HEVC encoder

It should be rather "Document controls for HEVC encoder" or sth similar.

In general most of comments are in previous patch.
Few additional comments:
- please be careful about control names - they are exported to userspace
and becomes ABI, so it will be difficult to change them later (this
comment is rather to previous patch),
- please provide good documentation as for most users this documentation
will be the only available source of information,
- in short: bugs in the driver can be easily fixed(usually), wrong
control names will be hard to fix, weak documentation will prevent using it.

And regarding this patch:
- please expand all acronyms (pb, tmv, BIT,...),
- please consider using menu instead of numbers for profile, level,
tier, types, generally everywhere where control value enumerates
'things' and is not a pure number (coefficient, counter,...),
- if control is per-frame please drop it, V4L2 does not support it at
the moment ( I suppose ),

Regards
Andrzej

Re: [Patch v2 10/11] s5p-mfc: Add support for HEVC encoder

[Andrzej Hajda]

On 03.03.2017 10:07, Smitha T Murthy wrote:
> Add HEVC encoder support and necessary registers, V4L2 CIDs,
> and hevc encoder parameters
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   28 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |   55 ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  595 
> +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|8 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  200 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |8 +
>  8 files changed, 896 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index 846dcf5..caf02ff 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -20,13 +20,35 @@
>  #define S5P_FIMV_MFC_STATE_V10   0x7124
>  #define S5P_FIMV_D_STATIC_BUFFER_ADDR_V100xF570
>  #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V100xF574
> +#define S5P_FIMV_E_NUM_T_LAYER_V10   0xFBAC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V100xFBB0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V100xFBB4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V100xFBB8
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V100xFBBC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V100xFBC0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V100xFBC4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V100xFBC8
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V10  0xFD18
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V10  0xFD1C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V10  0xFD20
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V10  0xFD24
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V10  0xFD28
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V10  0xFD2C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V10  0xFD30
> +#define S5P_FIMV_E_HEVC_OPTIONS_V10  0xFDD4
> +#define S5P_FIMV_E_HEVC_REFRESH_PERIOD_V10   0xFDD8
> +#define S5P_FIMV_E_HEVC_CHROMA_QP_OFFSET_V10 0xFDDC
> +#define S5P_FIMV_E_HEVC_LF_BETA_OFFSET_DIV2_V10  0xFDE0
> +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V100xFDE4
> +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V10  0xFDE8
>  
>  /* MFCv10 Context buffer sizes */
>  #define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)/* 30KB */
>  #define MFC_H264_DEC_CTX_BUF_SIZE_V10(2 * SZ_1M) /* 2MB */
>  #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10   (20 * SZ_1K)/* 20KB */
>  #define MFC_H264_ENC_CTX_BUF_SIZE_V10(100 * SZ_1K)   /* 100KB */
> -#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10   (15 * SZ_1K)/* 15KB */
> +#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10(30 * SZ_1K)/* 30KB */
> +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10  (15 * SZ_1K) /* 15KB */
>  
>  /* MFCv10 variant defines */
>  #define MAX_FW_SIZE_V10  (SZ_1M) /* 1MB */
> @@ -58,5 +80,9 @@
>  #define ENC_V100_VP8_ME_SIZE(x, y) \
>   ENC_V100_BASE_SIZE(x, y)
>  
> +#define ENC_V100_HEVC_ME_SIZE(x, y)  \
> + (((x + 3) * (y + 3) * 32)   \
> +  + ((y * 128) + 1280) * DIV_ROUND_UP(x, 4))
> +
>  #endif /*_REGS_MFC_V10_H*/
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index b014038..b01c556 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1549,6 +1549,7 @@ static int s5p_mfc_resume(struct device *dev)
>   .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
>   .other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
>   .h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V10,
> + .hevc_enc_ctx   = MFC_HEVC_ENC_CTX_BUF_SIZE_V10,
>   .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
>  };
>  
> 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 102b47e..7521fce 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -122,6 +122,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_VP8_ENC:
>   codec_type = S5P_FIMV_CODEC_VP8_ENC_V7;
>   break;
> + case S5P_MFC_CODEC_HEVC_ENC:
> + codec_type = S5P_FIMV_CODEC_HEVC_ENC;
> + break;
>   default:
>   codec_type = S5P_FIMV_CODEC_NONE_V6;
>   }
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index e720ce6..c55fa6c 100644
> --- 

Re: [Patch v2 07/11] Documentation: v4l: Documentation for HEVC v4l2 definition

[Andrzej Hajda]

On 03.03.2017 10:07, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
> 
> Signed-off-by: Smitha T Murthy <smith...@samsung.com>

Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>



> ---
>  Documentation/media/uapi/v4l/pixfmt-013.rst |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/pixfmt-013.rst 
> b/Documentation/media/uapi/v4l/pixfmt-013.rst
> index 728d7ed..ff4cac2 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-013.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-013.rst
> @@ -90,3 +90,8 @@ Compressed Formats
>- ``V4L2_PIX_FMT_VP9``
>- 'VP90'
>- VP9 video elementary stream.
> +* .. _V4L2-PIX-FMT-HEVC:
> +
> +  - ``V4L2_PIX_FMT_HEVC``
> +  - 'HEVC'
> +  - HEVC video elementary stream.
> 

Re: [Patch v2 09/11] v4l2: Add v4l2 control IDs for HEVC encoder

[Andrzej Hajda]

cal Coding Layer BIT6";
> + case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_CH:return "HEVC 
> Hierarchical Coding Layer Change";
> + case V4L2_CID_MPEG_VIDEO_HEVC_SIGN_DATA_HIDING: return "HEVC 
> Sign data hiding";
> + case V4L2_CID_MPEG_VIDEO_HEVC_GENERAL_PB_ENABLE:return "HEVC 
> General pb enable";
> + case V4L2_CID_MPEG_VIDEO_HEVC_TEMPORAL_ID_ENABLE:   return "HEVC 
> Temporal id enable";
> + case V4L2_CID_MPEG_VIDEO_HEVC_STRONG_SMOTHING_FLAG: return "HEVC 
> Strong intra smoothing flag";
> + case V4L2_CID_MPEG_VIDEO_HEVC_DISABLE_INTRA_PU_SPLIT:   return "HEVC 
> Disable intra pu split";
> + case V4L2_CID_MPEG_VIDEO_HEVC_DISABLE_TMV_PREDICTION:   return "HEVC 
> Disable tmv prediction";
> + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_NUM_MERGE_MV_MINUS1:  return "HEVC 
> Max number of candidate MVs";
> + case V4L2_CID_MPEG_VIDEO_HEVC_WITHOUT_STARTCODE_ENABLE: return "HEVC 
> ENC without startcode enable";
> + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_PERIOD:   return "HEVC 
> Number of reference picture";
> + case V4L2_CID_MPEG_VIDEO_HEVC_LF_BETA_OFFSET_DIV2:  return "HEVC 
> Loop filter beta offset";
> + case V4L2_CID_MPEG_VIDEO_HEVC_LF_TC_OFFSET_DIV2:return "HEVC 
> Loop filter tc offset";
> + case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD: return "HEVC 
> Size of length field";
> + case V4L2_CID_MPEG_VIDEO_HEVC_USE_REF:  return "HEVC 
> User long term reference frame";

s/User/Use/

As I said previously I am not HEVC expert, it would be good if someone
with better skills look at it.
>From my side after fixing typo above you can add:
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

Regards
Andrzej

> + case V4L2_CID_MPEG_VIDEO_HEVC_STORE_REF:return "HEVC 
> Store long term reference frame";
> + case V4L2_CID_MPEG_VIDEO_HEVC_PREPEND_SPSPPS_TO_IDR:return "HEVC 
> Prepend SPS/PPS to every IDR";
> +
>   /* CAMERA controls */
>   /* Keep the order of the 'case's the same as in v4l2-controls.h! */
>   case V4L2_CID_CAMERA_CLASS: return "Camera Controls";
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index 0d2e1e0..11a13c3 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -579,6 +579,135 @@ enum v4l2_vp8_golden_frame_sel {
>  #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP   (V4L2_CID_MPEG_BASE+510)
>  #define V4L2_CID_MPEG_VIDEO_VPX_PROFILE  
> (V4L2_CID_MPEG_BASE+511)
>  
> +/* CIDs for HEVC encoding. Number gaps are for compatibility */
> +
> +#define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP \
> + (V4L2_CID_MPEG_BASE + 512)
> +#define V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP \
> + (V4L2_CID_MPEG_BASE + 513)
> +#define V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP \
> + (V4L2_CID_MPEG_BASE + 514)
> +#define V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP \
> + (V4L2_CID_MPEG_BASE + 515)
> +#define V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP \
> + (V4L2_CID_MPEG_BASE + 516)
> +#define V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_QP_ENABLE \
> + (V4L2_CID_MPEG_BASE + 517)
> +#define V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_TYPE   \
> + (V4L2_CID_MPEG_BASE + 518)
> +enum v4l2_mpeg_video_hevc_hier_coding_type {
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B  = 0,
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P  = 1,
> +};
> +#define V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER  \
> + (V4L2_CID_MPEG_BASE + 519)
> +enum v4l2_mpeg_video_hevc_hierarchial_coding_layer {
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHIAL_CODING_LAYER0  = 0,
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHIAL_CODING_LAYER1  = 1,
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHIAL_CODING_LAYER2  = 2,
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHIAL_CODING_LAYER3  = 3,
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHIAL_CODING_LAYER4  = 4,
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHIAL_CODING_LAYER5  = 5,
> + V4L2_MPEG_VIDEO_HEVC_HIERARCHIAL_CODING_LAYER6  = 6,
> +};
> +#define V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_QP   \
> + (V4L2_CID_MPEG_BASE + 520)
> +#define V4L

Re: [Patch v2 04/11] s5p-mfc: Support MFCv10.10 buffer requirements

[Andrzej Hajda]

On 03.03.2017 10:07, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   19 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   99 
> ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |2 +
>  3 files changed, 99 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index bd671a5..dafcf9d 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,5 +32,24 @@
>  #define MFC_VERSION_V10  0xA0
>  #define MFC_NUM_PORTS_V101
>  
> +/* MFCv10 codec defines*/
> +#define S5P_FIMV_CODEC_HEVC_ENC 26
> +
> +/* Encoder buffer size for MFC v10.0 */
> +#define ENC_V100_BASE_SIZE(x, y) \
> + (((x + 3) * (y + 3) * 8) \
> + +  ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))
> +
> +#define ENC_V100_H264_ME_SIZE(x, y) \
> + (ENC_V100_BASE_SIZE(x, y) \
> + + (DIV_ROUND_UP(x * y, 64) * 32))
> +
> +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> + (ENC_V100_BASE_SIZE(x, y) \
> + + (DIV_ROUND_UP(x * y, 128) * 16))
> +
> +#define ENC_V100_VP8_ME_SIZE(x, y) \
> + ENC_V100_BASE_SIZE(x, y)
> +
>  #endif /*_REGS_MFC_V10_H*/
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 5f0da0b..d4c75eb 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -45,6 +45,8 @@
>  
>  #define IS_MFCV6_V2(dev) (!IS_MFCV7_PLUS(dev) && dev->fw_ver == MFC_FW_V2)
>  
> +#define calc_param(value, align) (DIV_ROUND_UP(value, align) * align)

I think it is functionally the same as ALIGN, please drop it and use
ALIGN instead.

> +
>  /* Allocate temporary buffers for decoding */
>  static int s5p_mfc_alloc_dec_temp_buffers_v6(struct s5p_mfc_ctx *ctx)
>  {
> @@ -64,6 +66,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>  {
>   struct s5p_mfc_dev *dev = ctx->dev;
>   unsigned int mb_width, mb_height;
> + unsigned int lcu_width = 0, lcu_height = 0;
>   int ret;
>  
>   mb_width = MB_WIDTH(ctx->img_width);
> @@ -74,7 +77,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
> ctx->luma_size, ctx->chroma_size, ctx->mv_size);
>   mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
>   } else if (ctx->type == MFCINST_ENCODER) {
> - if (IS_MFCV8_PLUS(dev))
> + if (IS_MFCV10(dev)) {
> + ctx->tmv_buffer_size = 0;
> + } else if (IS_MFCV8_PLUS(dev))
>   ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
>   ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
>   S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> @@ -82,13 +87,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
>   ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
>   S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> -
> - ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> - ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> + if (IS_MFCV10(dev)) {
> + lcu_width = enc_lcu_width(ctx->img_width);
> + lcu_height = enc_lcu_height(ctx->img_height);
> + if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> + ctx->luma_dpb_size =
> + ALIGN(calc_param((mb_width * 16), 64)
> + * calc_param((mb_height * 16), 32)
> + + 64, 64);
ALIGN is not necessary here, as argument is already aligned.
> + ctx->chroma_dpb_size =
> + ALIGN(calc_param((mb_width * 16), 64)
> + * (mb_height * 8)
> + + 64, 64);

ditto

> + } else {
> + ctx->luma_dpb_size =
> + ALIGN(calc_param((lcu_width * 32), 64)
> + * calc_param((lcu_height * 32), 32)
> + + 64, 64);
ditto
> + ctx->chroma_dpb_size =
> +

Re: [Patch v2 05/11] videodev2.h: Add v4l2 definition for HEVC

[Andrzej Hajda]

On 03.03.2017 10:07, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
>
> Signed-off-by: Smitha T Murthy <smith...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
--
Regards
Andrzej
> ---
>  include/uapi/linux/videodev2.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 46e8a2e3..620e941 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -630,6 +630,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE 
> 421M Annex L compliant stream */
>  #define V4L2_PIX_FMT_VP8  v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
>  #define V4L2_PIX_FMT_VP9  v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> +#define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC */
>  
>  /*  Vendor-specific formats   */
>  #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */

Re: [Patch v2 03/11] s5p-mfc: Use min scratch buffer size as provided by F/W

[Andrzej Hajda]

On 03.03.2017 10:07, Smitha T Murthy wrote:
> After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
> size is required for decoder. If mfc f/w has the functionality,
> E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
> is required for encoder too.
>
> Signed-off-by: Smitha T Murthy <smith...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
--
Regards
Andrzej

Re: [Patch v2 02/11] s5p-mfc: Adding initial support for MFC v10.10

[Andrzej Hajda]

On 03.03.2017 10:07, Smitha T Murthy wrote:
> Adding the support for MFC v10.10, with new register file and
> necessary hw control, decoder, encoder and structural changes.
>
> Signed-off-by: Smitha T Murthy <smith...@samsung.com>
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

Few nitpicks below.

> CC: Rob Herring <robh...@kernel.org>
> CC: devicet...@vger.kernel.org
> ---
>  .../devicetree/bindings/media/s5p-mfc.txt  |1 +
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |   36 
>  drivers/media/platform/s5p-mfc/s5p_mfc.c   |   30 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|4 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |4 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |   44 
> +++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   |   21 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c|9 +++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|2 +
>  9 files changed, 118 insertions(+), 33 deletions(-)
>  create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> index 2c90128..b83727b 100644
> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> @@ -13,6 +13,7 @@ Required properties:
>   (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
>   (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
>   (e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
> + (f) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC
>  
>- reg : Physical base address of the IP registers and length of memory
> mapped region.
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> new file mode 100644
> index 000..bd671a5
> --- /dev/null
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -0,0 +1,36 @@
> +/*
> + * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
> + *
> + * Copyright (c) 2017 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _REGS_MFC_V10_H
> +#define _REGS_MFC_V10_H
> +
> +#include 
> +#include "regs-mfc-v8.h"
> +
> +/* MFCv10 register definitions*/
> +#define S5P_FIMV_MFC_CLOCK_OFF_V10   0x7120
> +#define S5P_FIMV_MFC_STATE_V10   0x7124
> +
> +/* MFCv10 Context buffer sizes */
> +#define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)/* 30KB */
> +#define MFC_H264_DEC_CTX_BUF_SIZE_V10(2 * SZ_1M) /* 2MB */
> +#define MFC_OTHER_DEC_CTX_BUF_SIZE_V10   (20 * SZ_1K)/* 20KB */
> +#define MFC_H264_ENC_CTX_BUF_SIZE_V10(100 * SZ_1K)   /* 100KB */
> +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10   (15 * SZ_1K)/* 15KB */
> +
> +/* MFCv10 variant defines */
> +#define MAX_FW_SIZE_V10  (SZ_1M) /* 1MB */
> +#define MAX_CPB_SIZE_V10 (3 * SZ_1M) /* 3MB */

These comments seems redundant, definition is clear enough, you could
remove them if there will be next iteration.

> +#define MFC_VERSION_V10  0xA0
> +#define MFC_NUM_PORTS_V101
> +
> +#endif /*_REGS_MFC_V10_H*/
> +
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index bb0a588..a043cce 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1542,6 +1542,33 @@ static int s5p_mfc_resume(struct device *dev)
>   .num_clocks = 3,
>  };
>  
> +static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
> + .dev_ctx= MFC_CTX_BUF_SIZE_V10,
> + .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
> + .other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
> + .h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V10,
> + .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
> +};
> +
> +static struct s5p_mfc_buf_size buf_size_v10 = {
> + .fw = MAX_FW_SIZE_V10,
> + .cpb= MAX_CPB_SIZE_V10,
> + .priv   = _buf_size_v10,
> +};
> +
> +static struct s5p_mfc_buf_align mfc_buf_align_v10 = {
> + .base = 0,
> +};
> +
> +static struct s5p_mfc_variant mfc_drvdata_v10 = {
> + .version= MFC_VERSION_V10,
> + .version

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

[Andrzej Hajda]

On 01.03.2017 16:21, Nicolas Dufresne wrote:
> Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :
>> - on output side you have encoded bytestream - you cannot say about
>> interlacing in such case, so the only valid value is NONE,
>> - on capture side you have decoded frames, and in this case it
>> depends
>> on the device and driver capabilities, if the driver/device does not
>> support (de-)interlacing (I suppose this is MFC case), interlace type
>> field should be filled according to decoded bytestream header (on
>> output
>> side), but no direct copying from output side!!!
> I think we need some nuance here for this to actually be usable. If the
> information is not provided by the driver (yes, hardware is limiting
> sometimes), it would make sense to copy over the information that
> userspace provided. Setting NONE is just the worst approximation in my
> opinion.

The whole point is that s_fmt on output side is to describe format of
the stream passed to the device, and in case of decoder it is just
mpeg/h.26x/... stream. It does not contain frames, fields, width, height
- it is just raw stream of bytes. We cannot say in such case about field
type, there is not such thing as interlaced byte stream.
Using s_fmt on output to describe things on capture side look for me
unnecessary and abuses V4L2 API IMO.

>
> About MFC, it will be worth trying to read the DISPLAY_STATUS after the
> headers has been processed. It's not clearly stated in the spec if this
> will be set or not.
>
Documentation for MFC6.5 states clearly:

> Note: On SEQ_DONE, INTERLACE_PICTURE will return the picture type to
> be decoded based on the
> sequence header information.

In case of MFC5.1 it is unclear, but I hope HW behaves the same way.

Anyway I agree it will be good to fix it at least for MFC6.5+, any
volunteer?


Regards

Andrzej

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

[Andrzej Hajda]

On 01.03.2017 12:51, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver, default to NONE in case any is provided, but we can basically
> accept any value provided by the userspace as we will anyway not
> be able to do any deinterlacing.
>
> In this patch we also make sure to pass the interlacing mode provided
> by userspace from the output to the capture side of the device so
> that the information is given back to userspace. This way it can
> handle it and potentially deinterlace afterward.

As I wrote previously:
- on output side you have encoded bytestream - you cannot say about
interlacing in such case, so the only valid value is NONE,
- on capture side you have decoded frames, and in this case it depends
on the device and driver capabilities, if the driver/device does not
support (de-)interlacing (I suppose this is MFC case), interlace type
field should be filled according to decoded bytestream header (on output
side), but no direct copying from output side!!!

Regards
Andrzej

>
> Signed-off-by: Thibault Saunier 
>
> ---
>
> Changes in v6:
> - Pass user output field value to the capture as the device is not
>   doing any deinterlacing and thus decoded content will still be
>   interlaced on the output.
>
> Changes in v5:
> - Just adapt the field and never error out.
>
> Changes in v4: None
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
>
> Changes in v2:
> - Fix a silly build error that slipped in while rebasing the patches
>
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 6 +-
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index ab23236aa942..3816a37de4bc 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -652,6 +652,8 @@ struct s5p_mfc_ctx {
>   size_t me_buffer_size;
>   size_t tmv_buffer_size;
>  
> + enum v4l2_field field;
> +
>   enum v4l2_mpeg_mfc51_video_force_frame_type force_frame_type;
>  
>   struct list_head ref_queue;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 367ef8e8dbf0..6e5ca86fb331 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -345,7 +345,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>  rectangle. */
>   pix_mp->width = ctx->buf_width;
>   pix_mp->height = ctx->buf_height;
> - pix_mp->field = V4L2_FIELD_NONE;
> + pix_mp->field = ctx->field;
>   pix_mp->num_planes = 2;
>   /* Set pixelformat to the format in which MFC
>  outputs the decoded frame */
> @@ -380,6 +380,9 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   struct s5p_mfc_dev *dev = video_drvdata(file);
>   struct s5p_mfc_fmt *fmt;
>  
> + if (f->fmt.pix.field == V4L2_FIELD_ANY)
> + f->fmt.pix.field = V4L2_FIELD_NONE;
> +
>   mfc_debug(2, "Type is %d\n", f->type);
>   if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
>   fmt = find_format(f, MFC_FMT_DEC);
> @@ -436,6 +439,7 @@ static int vidioc_s_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   goto out;
>   } else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
>   /* src_fmt is validated by call to vidioc_try_fmt */
> + ctx->field = f->fmt.pix.field;
>   ctx->src_fmt = find_format(f, MFC_FMT_DEC);
>   ctx->codec_mode = ctx->src_fmt->codec_mode;
>   mfc_debug(2, "The codec number is: %d\n", ctx->codec_mode);

Re: [PATCH v5 2/3] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT provided

[Andrzej Hajda]

On 21.02.2017 20:20, Thibault Saunier wrote:
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
> didn't set the colorimetry when userspace provided
> V4L2_COLORSPACE_DEFAULT.
>
> Use 576p display resolution as a threshold to set this as suggested by
> EIA CEA 861B.
>
> Signed-off-by: Thibault Saunier 
>
> ---
>
> Changes in v5: None
> Changes in v4:
> - Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
>   all other cases just use what userspace provided.
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
> - Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in
>
> Changes in v2: None
>
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 367ef8e8dbf0..0976c3e0a5ce 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -354,6 +354,11 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
>   pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
>   pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
> +
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;

Again, it seems much more complicated for decoder, I suppose colorspace
field should be filled according to decoded information from the header
of byte stream. It looks like MFC does not parse  stream header for such
info. So it should be done either by the driver, either by userspace, if
userspace is able to get such info. For example in H.264 this info is
encoded in VUI header [1], I do not know about other codecs. I guess the
best solution for now is to not touch this field unless you can retrieve
this info from MFC.

[1]:
https://github.com/copiousfreetime/mp4parser/blob/master/isoparser/src/main/java/com/googlecode/mp4parser/h264/model/SeqParameterSet.java#L227

Regards
Andrzej

>   } else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
>   /* This is run on OUTPUT
>  The buffer contains compressed image
> @@ -378,6 +383,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>  static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format 
> *f)
>  {
>   struct s5p_mfc_dev *dev = video_drvdata(file);
> + struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
>   struct s5p_mfc_fmt *fmt;
>  
>   mfc_debug(2, "Type is %d\n", f->type);
> @@ -405,6 +411,14 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   mfc_err("Unsupported format by this MFC version.\n");
>   return -EINVAL;
>   }
> +
> + if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
> + if (pix_mp->width > 720 &&
> + pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + }
>   }
>  
>   return 0;

Re: [PATCH v5 3/3] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Andrzej Hajda]

On 22.02.2017 14:10, Thibault Saunier wrote:
> Hello,
>
> On 02/22/2017 06:29 AM, Andrzej Hajda wrote:
>> On 21.02.2017 20:20, Thibault Saunier wrote:
>>> It is required by the standard that the field order is set by the
>>> driver.
>>>
>>> Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
>>>
>>> ---
>>>
>>> Changes in v5:
>>> - Just adapt the field and never error out.
>>>
>>> Changes in v4: None
>>> Changes in v3:
>>> - Do not check values in the g_fmt functions as Andrzej explained in 
>>> previous review
>>>
>>> Changes in v2:
>>> - Fix a silly build error that slipped in while rebasing the patches
>>>
>>>   drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
>>> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>>> index 0976c3e0a5ce..44ed2afe0780 100644
>>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>>> @@ -386,6 +386,9 @@ static int vidioc_try_fmt(struct file *file, void 
>>> *priv, struct v4l2_format *f)
>>> struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
>>> struct s5p_mfc_fmt *fmt;
>>>   
>>> +   if (f->fmt.pix.field == V4L2_FIELD_ANY)
>>> +   f->fmt.pix.field = V4L2_FIELD_NONE;
>>> +
>> In previous version the only supported field type was NONE, here you
>> support everything.
>> If the only supported format is none you should set 'field'
>> unconditionally to NONE, nothing more.
> Afaict we  support 2 things:
>
>1. NONE
>2. INTERLACE
>
> Until now we were not checking what was supported or not and basically 
> ignoring that info, this patch
> keeps the old behaviour making sure to be compliant.
>
> I had a doubt and was pondering doing:
>
> ``` diff
>
> + if (f->fmt.pix.field != V4L2_FIELD_INTERLACED)
> + f->fmt.pix.field = V4L2_FIELD_NONE;
> +
>
> ```
>
> instead, it is probably more correct, do you think it is what should be 
> done here?

I have realized I have forgot that it is not simple mem2mem device, it
is decoder. It is feed with compressed data which is just byte stream,
the only valid field value on output side is V4L2_FIELD_NONE.
About possible interlacing we could only say in case of capture side.
And in this case there are multiple questions:
- how MFC decodes stream with interlaced content?
- is it possible to convince it to decode it as user asks?
- does it perform (de-)interlacing?
- what is implemented in the driver?

After answering above questions we will be able to say how fmt.pix.field
should be treated on capture side.
And similar question we can pose in case of encoder.

So simple patch and so many doubts.

Regards
Andrzej

>
> Regards,
>
> Thibault
>
>> Regards
>> Andrzej
>>
>>> mfc_debug(2, "Type is %d\n", f->type);
>>> if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
>>> fmt = find_format(f, MFC_FMT_DEC);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> 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 3/3] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Andrzej Hajda]

On 21.02.2017 20:20, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver.
>
> Signed-off-by: Thibault Saunier 
>
> ---
>
> Changes in v5:
> - Just adapt the field and never error out.
>
> Changes in v4: None
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
>
> Changes in v2:
> - Fix a silly build error that slipped in while rebasing the patches
>
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 0976c3e0a5ce..44ed2afe0780 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -386,6 +386,9 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
>   struct s5p_mfc_fmt *fmt;
>  
> + if (f->fmt.pix.field == V4L2_FIELD_ANY)
> + f->fmt.pix.field = V4L2_FIELD_NONE;
> +

In previous version the only supported field type was NONE, here you
support everything.
If the only supported format is none you should set 'field'
unconditionally to NONE, nothing more.

Regards
Andrzej

>   mfc_debug(2, "Type is %d\n", f->type);
>   if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
>   fmt = find_format(f, MFC_FMT_DEC);

Re: [PATCH v2 01/15] media: s5p-mfc: Remove unused structures and dead code

[Andrzej Hajda]

On 20.02.2017 14:38, Marek Szyprowski wrote:
> Remove unused structures, definitions and functions that are no longer
> called from the driver code.
>
> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

For the whole patchset:

Acked-by: Andrzej Hajda <a.ha...@samsung.com>
--
Regards
Andrzej


> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c| 21 -
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 13 -
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h   |  1 -
>  3 files changed, 35 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 05fe82be6584..3e1f22eb4339 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1422,16 +1422,11 @@ static int s5p_mfc_resume(struct device *dev)
>   .priv   = _buf_size_v5,
>  };
>  
> -static struct s5p_mfc_buf_align mfc_buf_align_v5 = {
> - .base = MFC_BASE_ALIGN_ORDER,
> -};
> -
>  static struct s5p_mfc_variant mfc_drvdata_v5 = {
>   .version= MFC_VERSION,
>   .version_bit= MFC_V5_BIT,
>   .port_num   = MFC_NUM_PORTS,
>   .buf_size   = _size_v5,
> - .buf_align  = _buf_align_v5,
>   .fw_name[0] = "s5p-mfc.fw",
>   .clk_names  = {"mfc", "sclk_mfc"},
>   .num_clocks = 2,
> @@ -1452,16 +1447,11 @@ static int s5p_mfc_resume(struct device *dev)
>   .priv   = _buf_size_v6,
>  };
>  
> -static struct s5p_mfc_buf_align mfc_buf_align_v6 = {
> - .base = 0,
> -};
> -
>  static struct s5p_mfc_variant mfc_drvdata_v6 = {
>   .version= MFC_VERSION_V6,
>   .version_bit= MFC_V6_BIT,
>   .port_num   = MFC_NUM_PORTS_V6,
>   .buf_size   = _size_v6,
> - .buf_align  = _buf_align_v6,
>   .fw_name[0] = "s5p-mfc-v6.fw",
>   /*
>* v6-v2 firmware contains bug fixes and interface change
> @@ -1486,16 +1476,11 @@ static int s5p_mfc_resume(struct device *dev)
>   .priv   = _buf_size_v7,
>  };
>  
> -static struct s5p_mfc_buf_align mfc_buf_align_v7 = {
> - .base = 0,
> -};
> -
>  static struct s5p_mfc_variant mfc_drvdata_v7 = {
>   .version= MFC_VERSION_V7,
>   .version_bit= MFC_V7_BIT,
>   .port_num   = MFC_NUM_PORTS_V7,
>   .buf_size   = _size_v7,
> - .buf_align  = _buf_align_v7,
>   .fw_name[0] = "s5p-mfc-v7.fw",
>   .clk_names  = {"mfc", "sclk_mfc"},
>   .num_clocks = 2,
> @@ -1515,16 +1500,11 @@ static int s5p_mfc_resume(struct device *dev)
>   .priv   = _buf_size_v8,
>  };
>  
> -static struct s5p_mfc_buf_align mfc_buf_align_v8 = {
> - .base = 0,
> -};
> -
>  static struct s5p_mfc_variant mfc_drvdata_v8 = {
>   .version= MFC_VERSION_V8,
>   .version_bit= MFC_V8_BIT,
>   .port_num   = MFC_NUM_PORTS_V8,
>   .buf_size   = _size_v8,
> - .buf_align  = _buf_align_v8,
>   .fw_name[0] = "s5p-mfc-v8.fw",
>   .clk_names  = {"mfc"},
>   .num_clocks = 1,
> @@ -1535,7 +1515,6 @@ static int s5p_mfc_resume(struct device *dev)
>   .version_bit= MFC_V8_BIT,
>   .port_num   = MFC_NUM_PORTS_V8,
>   .buf_size   = _size_v8,
> - .buf_align  = _buf_align_v8,
>   .fw_name[0] = "s5p-mfc-v8.fw",
>   .clk_names  = {"pclk", "aclk", "aclk_xiu"},
>   .num_clocks = 3,
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index ab23236aa942..3e0e8eaf8bfe 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -44,14 +44,6 @@
>  
>  #include 
>  
> -static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void *b)
> -{
> - /* Same functionality as the vb2_dma_contig_plane_paddr */
> - dma_addr_t *paddr = vb2_dma_contig_memops.cookie(b);
> -
> - return *paddr;
> -}
> -
>  /* MFC definitions */
>  #define MFC_MAX_EXTRA_DPB   5
>  #define MFC_MAX_BUFFERS  32
> @@ -229,16 +221,11 @@ struct s5p_mfc_buf_size {
>   void *priv;
>  };
>  
> -struct s5p_mfc_buf_align {
> - unsigned int base;
> -};
> -
>  struct s5p_mfc_variant {
>   unsigned int version;
>   unsigned int port_num;
>  

Re: [PATCH v4 4/4] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver.
>
> Signed-off-by: Thibault Saunier 
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
>
> Changes in v2:
> - Fix a silly build error that slipped in while rebasing the patches
>
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 0976c3e0a5ce..c954b34cb988 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -385,6 +385,20 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   struct s5p_mfc_dev *dev = video_drvdata(file);
>   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
>   struct s5p_mfc_fmt *fmt;
> + enum v4l2_field field;
> +
> + field = f->fmt.pix.field;
> + if (field == V4L2_FIELD_ANY) {
> + field = V4L2_FIELD_NONE;
> + } else if (field != V4L2_FIELD_NONE) {
> + mfc_debug(2, "Not supported field order(%d)\n", pix_mp->field);
> + return -EINVAL;
> + }
> +
> + /* V4L2 specification suggests the driver corrects the format struct
> +  * if any of the dimensions is unsupported
> +  */
> + f->fmt.pix.field = field;

It looks like you missed my previous comment.
--
Regards
Andrzej

>  
>   mfc_debug(2, "Type is %d\n", f->type);
>   if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {

Re: [PATCH v4 2/4] [media] exynos-gsc: Respect userspace colorspace setting in try_fmt

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> User userspace provided by the user as we are only doing scaling and
> color encoding conversion, we won't be able to transform the colorspace
> itself and the colorspace won't mater in that operation.
>
> Also always use output colorspace on the capture side.
>
> Signed-off-by: Thibault Saunier 

This patch can be squashed with previous one as the only thing to do is
to set output colorspace the same as capture colorspace.

--
Regards
Andrzej

>
> ---
>
> Changes in v4:
> - Use any colorspace provided by the user as it won't affect the way we
>   handle our operations (guessing it if none is provided)
> - Always use output colorspace on the capture side
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
> - Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in
>
> Changes in v2: None
>
>  drivers/media/platform/exynos-gsc/gsc-core.c | 14 ++
>  drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index db7d9883861b..772599de8c13 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   } else {
>   min_w = variant->pix_min->target_rot_dis_w;
>   min_h = variant->pix_min->target_rot_dis_h;
> + pix_mp->colorspace = ctx->out_colorspace;
>   }
>  
>   pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
> @@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>  
>   pix_mp->num_planes = fmt->num_planes;
>  
> - if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> - pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> - else /* SD */
> - pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + }
> +
> + if (V4L2_TYPE_IS_OUTPUT(f->type))
> + ctx->out_colorspace = pix_mp->colorspace;
>  
>   for (i = 0; i < pix_mp->num_planes; ++i) {
>   struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h 
> b/drivers/media/platform/exynos-gsc/gsc-core.h
> index 696217e9af66..715d9c9d8d30 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.h
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.h
> @@ -376,6 +376,7 @@ struct gsc_ctx {
>   struct v4l2_ctrl_handler ctrl_handler;
>   struct gsc_ctrlsgsc_ctrls;
>   boolctrls_rdy;
> + enum v4l2_colorspace out_colorspace;
>  };
>  
>  void gsc_set_prefbuf(struct gsc_dev *gsc, struct gsc_frame *frm);

Re: [PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> From: Javier Martinez Canillas <jav...@osg.samsung.com>
>
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
> don't agree on the display resolution that should be used as a threshold.
>
> >From EIA CEA 861B about colorimetry for various resolutions:
>
>   - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
> The color space used by the 480-line, 576-line, 240-line, and 288-line
> formats will likely be based on SMPTE 170M [1].
>   - 5.2 1080i, 1080p, and 720p
> The color space used by the high definition formats will likely be
> based on ITU-R BT.709-4
>
> This indicates that in the case that userspace does not specify what
> colorspace should be used, we should use 576p  as a threshold to set
> V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is
> only 'likely' and not a requirement it is the best guess we can make.
>
> The stream should have been encoded with the information and userspace
> has to pass it to the driver if it is not the case, otherwise we won't be
> able to handle it properly anyhow.
>
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
>
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> Signed-off-by: Thibault Saunier <thibault.saun...@osg.samsung.com>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

Hi Thibault,

Have you analyzed Hans response for the previous patchset [1] ?
I am not an expert in the subject but it seems he is right. GSCALER
datasheet uses term 'color space conversion' to describe conversions
between RGB and YCbCr, not for describe colorspaces as in V4L2.
GSC_(IN|OUT)_RGB_(HD|SD)_(WIDE|NARROW) macros used to set IN_CON and
OUT_CON registers of GSCALER are probably used incorrectly, they should
not be set according to pix_mp->colorspace but rather according to
pix_mp->ycbcr_enc and pix_mp->quantization. pix_mp->colorspace should be
just copied from output to capture side.

Please fix the patch accordingly, and if you are interested you can
prepare another patch to fix register setting.

[1]: https://lkml.org/lkml/2017/2/10/473

Regards
Andrzej

>
> ---
>
> Changes in v4:
> - Reword commit message to better back our assumptions on specifications
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous 
> review
> - Added 'Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>'
>
> Changes in v2: None
>
>  drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 59a634201830..db7d9883861b 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>  
>   pix_mp->num_planes = fmt->num_planes;
>  
> - if (pix_mp->width >= 1280) /* HD */
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
>   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
>   else /* SD */
>   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> @@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   pix_mp->height  = frame->f_height;
>   pix_mp->field   = V4L2_FIELD_NONE;
>   pix_mp->pixelformat = frame->fmt->pixelformat;
> - pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
>   pix_mp->num_planes  = frame->fmt->num_planes;
>  
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +
>   for (i = 0; i < pix_mp->num_planes; ++i) {
>   pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
>   frame->fmt->depth[i]) / 8;

Re: [PATCH] media: fix s5p_mfc_set_dec_frame_buffer_v6() to print buf size in hex

[Andrzej Hajda]

On 09.02.2017 23:10, Shuah Khan wrote:
> Fix s5p_mfc_set_dec_frame_buffer_v6() to print buffer size in hex to be
> consistent with the rest of the messages in the routine.
>
> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>

As Nicolas said please fix the subject.

After this you can add my:
Acked-by: Andrzej Hajda <a.ha...@samsung.com>

--
Regards
Andrzej

> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index d6f207e..fc45980 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -497,7 +497,7 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct 
> s5p_mfc_ctx *ctx)
>   }
>   }
>  
> - mfc_debug(2, "Buf1: %zu, buf_size1: %d (frames %d)\n",
> + mfc_debug(2, "Buf1: %zx, buf_size1: %d (frames %d)\n",
>   buf_addr1, buf_size1, ctx->total_dpb_count);
>   if (buf_size1 < 0) {
>   mfc_debug(2, "Not enough memory has been allocated.\n");


--
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 - remove unneeded io_modes initialzation in s5p_mfc_open()

[Andrzej Hajda]

On 09.02.2017 23:11, Shuah Khan wrote:
> Remove unneeded io_modes initialzation in s5p_mfc_open(). It gets done
> right below in vdev == dev->vfd_dec conditional.
>
> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
Acked-by: Andrzej Hajda <a.ha...@samsung.com>
--
Regards
Andrzej
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index bb0a588..20beaa2 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -866,7 +866,6 @@ static int s5p_mfc_open(struct file *file)
>   /* Init videobuf2 queue for OUTPUT */
>   q = >vq_src;
>   q->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> - q->io_modes = VB2_MMAP;
>   q->drv_priv = >fh;
>   q->lock = >mfc_mutex;
>   if (vdev == dev->vfd_dec) {


--
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 4/4] [media] s5p-mfc: Always check and set 'v4l2_pix_format:field' field

[Andrzej Hajda]

On 09.02.2017 21:04, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver.
>
> Signed-off-by: Thibault Saunier 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 960d6c7052bd..309b0a1bbca5 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -345,7 +345,6 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>  rectangle. */
>   pix_mp->width = ctx->buf_width;
>   pix_mp->height = ctx->buf_height;
> - pix_mp->field = V4L2_FIELD_NONE;
>   pix_mp->num_planes = 2;
>   /* Set pixelformat to the format in which MFC
>  outputs the decoded frame */
> @@ -369,7 +368,6 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>  so width and height have no meaning */
>   pix_mp->width = 0;
>   pix_mp->height = 0;
> - pix_mp->field = V4L2_FIELD_NONE;
>   pix_mp->plane_fmt[0].bytesperline = ctx->dec_src_buf_size;
>   pix_mp->plane_fmt[0].sizeimage = ctx->dec_src_buf_size;
>   pix_mp->pixelformat = ctx->src_fmt->fourcc;
> @@ -379,6 +377,14 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   mfc_debug(2, "%s-- with error\n", __func__);
>   return -EINVAL;
>   }
> +
> + if (pix_mp->field == V4L2_FIELD_ANY) {
> + pix_mp->field = V4L2_FIELD_NONE;
> + } else if (pix_mp->field != V4L2_FIELD_NONE) {
> + mfc_err("Not supported field order(%d)\n", pix_mp->field);
> + return -EINVAL;
> + }
> +

Again in g_fmt you should not check current value of the field.

>   mfc_debug_leave();
>   return 0;
>  }
> @@ -389,6 +395,19 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   struct s5p_mfc_dev *dev = video_drvdata(file);
>   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
>   struct s5p_mfc_fmt *fmt;
> + enum v4l2_field field;
> +
> + field = f->fmt.pix.field;
> + if (field == V4L2_FIELD_ANY) {
> + field = V4L2_FIELD_NONE;
> + } else if (V4L2_FIELD_NONE != field) {
> + mfc_debug(2, "Not supported field order(%d)\n", pix_mp->field);
> + return -EINVAL;
> + }
> +
> + /* V4L2 specification suggests the driver corrects the format struct
> +  * if any of the dimensions is unsupported */
> + f->fmt.pix.field = field;

According to docs [1], you should just adjust the field.

[1]:
http://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-g-fmt.html?highlight=g_fmt#c.VIDIOC_G_FMT

Regards
Andrzej

>  
>   mfc_debug(2, "Type is %d\n", f->type);
>   if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {


--
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 3/4] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT

[Andrzej Hajda]

On 09.02.2017 21:04, Thibault Saunier wrote:
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
> didn't set the colorimetry, also respect usespace setting.
>
> Use 576p display resolution as a threshold to set this.
>
> Signed-off-by: Thibault Saunier 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 367ef8e8dbf0..960d6c7052bd 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -354,6 +354,15 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
>   pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
>   pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
> +
> + if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
> + pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
> + pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
> +   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> +   else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + }

Again, in g_fmt you should not check values of fields you have to fill.


Regards
Andrzej

>   } else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
>   /* This is run on OUTPUT
>  The buffer contains compressed image
> @@ -378,6 +387,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>  static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format 
> *f)
>  {
>   struct s5p_mfc_dev *dev = video_drvdata(file);
> + struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
>   struct s5p_mfc_fmt *fmt;
>  
>   mfc_debug(2, "Type is %d\n", f->type);
> @@ -405,6 +415,15 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
> struct v4l2_format *f)
>   mfc_err("Unsupported format by this MFC version.\n");
>   return -EINVAL;
>   }
> +
> + if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
> + pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
> + pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
> +   if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> +   else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + }
>   }
>  
>   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 v2 2/4] [media] exynos-gsc: Respect userspace colorspace setting

[Andrzej Hajda]

On 09.02.2017 21:04, Thibault Saunier wrote:
> If the colorspace is specified by userspace we should respect
> it and not reset it ourself if we can support it.
>
> Signed-off-by: Thibault Saunier 
> ---
>  drivers/media/platform/exynos-gsc/gsc-core.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 2beb43401987..63bb4577827d 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -445,10 +445,14 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>  
>   pix_mp->num_planes = fmt->num_planes;
>  
> - if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> - pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> - else /* SD */
> - pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> + if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
> + pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
> + pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> +   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> +   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +   }
>  
>   for (i = 0; i < pix_mp->num_planes; ++i) {
>   struct v4l2_plane_pix_format *plane_fmt = _mp->plane_fmt[i];
> @@ -492,12 +496,17 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   pix_mp->height  = frame->f_height;
>   pix_mp->field   = V4L2_FIELD_NONE;
>   pix_mp->pixelformat = frame->fmt->pixelformat;
> - if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> - pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> - else /* SD */
> - pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
>   pix_mp->num_planes  = frame->fmt->num_planes;
>  
> + if (pix_mp->colorspace != V4L2_COLORSPACE_REC709 &&
> + pix_mp->colorspace != V4L2_COLORSPACE_SMPTE170M &&
> + pix_mp->colorspace != V4L2_COLORSPACE_DEFAULT) {
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> +   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> +   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +   }
> +

This is g_fmt, so you set colorspace regardless of its current value, am
I right?

Regards
Andrzej

>   for (i = 0; i < pix_mp->num_planes; ++i) {
>   pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
>   frame->fmt->depth[i]) / 8;


--
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/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Andrzej Hajda]

On 09.02.2017 21:04, Thibault Saunier wrote:
> From: Javier Martinez Canillas <jav...@osg.samsung.com>
>
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
> don't agree on the display resolution that should be used as a threshold.
>
> Some drivers set V4L2_COLORSPACE_REC709 for 720p and higher while others
> set V4L2_COLORSPACE_REC709 for anything higher than 576p. Newers drivers
> use the latter and that also matches what user-space multimedia programs
> do (i.e: GStreamer), so change the driver logic to be aligned with this.
>
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
>
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

--
Regards
Andrzej
> ---
>  drivers/media/platform/exynos-gsc/gsc-core.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index cbb03768f5d7..2beb43401987 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -445,7 +445,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>  
>   pix_mp->num_planes = fmt->num_planes;
>  
> - if (pix_mp->width >= 1280) /* HD */
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
>   pix_mp->colorspace = V4L2_COLORSPACE_REC709;
>   else /* SD */
>   pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> @@ -492,7 +492,10 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   pix_mp->height  = frame->f_height;
>   pix_mp->field   = V4L2_FIELD_NONE;
>   pix_mp->pixelformat = frame->fmt->pixelformat;
> - pix_mp->colorspace  = V4L2_COLORSPACE_REC709;
> + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> + pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> + else /* SD */
> + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
>   pix_mp->num_planes  = frame->fmt->num_planes;
>  
>   for (i = 0; i < pix_mp->num_planes; ++i) {


--
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 initialization of internal structures

[Andrzej Hajda]

On 03.02.2017 15:05, Marek Szyprowski wrote:
> Initialize members of the internal device and context structures as early
> as possible to avoid access to uninitialized objects on initialization
> failures. If loading firmware or creating of the hardware instance fails,
> driver will access device or context queue in error handling path, which
> might not be initialized yet, what causes kernel panic. Fix this by moving
> initialization of all static members as early as possible.
>
> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>

Acked-by: Andrzej Hajda <a.ha...@samsung.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/11] [media] v4l2: Add v4l2 control IDs for HEVC encoder

[Andrzej Hajda]

Hi Smitha,

I have no big experience with HEVC, so it is hard to review it
appropriately but I will try do my best.
As these control names goes to user space you should be very careful
about it.
I guess it could be good to compare these controls with other HEVC
encoders including software ones (ffmpeg, intel, ...) to find some
similarities, common naming convention.


On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add v4l2 controls for HEVC encoder
>
> CC: Hans Verkuil 
> CC: Wu-Cheng Li 
> CC: Kieran Bingham 
> CC: Vladimir Zapolskiy 
> CC: Laurent Pinchart 
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/v4l2-core/v4l2-ctrls.c |   51 
>  include/uapi/linux/v4l2-controls.h   |  109 
> ++
>  2 files changed, 160 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 47001e2..387439d 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -775,6 +775,57 @@ static bool is_new_manual(const struct v4l2_ctrl *master)
>   case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
> P-Frame QP Value";
>   case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:   return "VPX 
> Profile";
>  
> + /* HEVC controls */
> + case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:   return "HEVC 
> Frame QP value";

Should be "HEVC I-Frame", it looks like the convention is to upper-case
first letter of all words,
and the convention is I-Frame, B-Frame, P-Frame, here and in the next
controls.
I would drop also the word "value", but it is already used in other
controls so I do not know :)

> + case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:   return "HEVC P 
> frame QP value";
> + case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP:   return "HEVC B 
> frame QP value";
> + case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP:   return "HEVC 
> Minimum QP value";
> + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP:   return "HEVC 
> Maximum QP value";
> + case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_DARK: return "HEVC 
> dark region adaptive";
> + case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_SMOOTH:   return "HEVC 
> smooth region adaptive";
> + case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_STATIC:   return "HEVC 
> static region adaptive";
> + case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_ACTIVITY: return "HEVC 
> activity adaptive";

Shouldn't it be "... Region Adaptive RC", or "... Region Adaptive Rate
Control" ?

> + case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:  return "HEVC 
> Profile";
> + case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC 
> level";
> + case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC 
> tier_flag default is Main";

I guess 0 - means main tier, 1 means high tier, am I right? In such case
it should be named "HEVC high tier" or sth similar.

> + case V4L2_CID_MPEG_VIDEO_HEVC_RC_FRAME_RATE:return "HEVC 
> Frame rate";
> + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH:  return "HEVC 
> Maximum coding unit depth";
> + case V4L2_CID_MPEG_VIDEO_HEVC_REF_NUMBER_FOR_PFRAMES:   return "HEVC 
> Number of reference picture";

What is purpose of this control? Macro name suggest sth different than
string.

> + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC 
> refresh type";

Could you enumerate these refresh types, in patch 9 and documentation,
maybe it would be worth to make it menu.

> + case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED_ENABLE:  return "HEVC 
> constant intra prediction enabled";
> + case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU_ENABLE:   return "HEVC 
> lossless encoding select";
> + case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT_ENABLE: return "HEVC 
> Wavefront enable";

I see: enable, enabled, select. Let it be consistent.

> + case V4L2_CID_MPEG_VIDEO_HEVC_LF_DISABLE:   return "HEVC 
> Filter disable";

There is LF in macro name.

> + case V4L2_CID_MPEG_VIDEO_HEVC_LF_SLICE_BOUNDARY:return "across 
> or not slice boundary";

What does it mean?

> + case V4L2_CID_MPEG_VIDEO_HEVC_LTR_ENABLE:   return "long 
> term reference enable";
> + case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_QP_ENABLE:   return "QP 
> values for temporal layer";
> + case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_TYPE: return 
> "Hierarchical Coding Type";

Please enumerate types.

> + case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER:return 
> "Hierarchical Coding Layer";

Please enumerate layers.

> + case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_QP:return 
> "Hierarchical Coding Layer QP";
> + case 

Re: [PATCHv4 1/9] video: add hotplug detect notifier support

[Andrzej Hajda]

On 06.02.2017 11:29, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verk...@cisco.com>
>
> Add support for video hotplug detect and EDID/ELD notifiers, which is used
> to convey information from video drivers to their CEC and audio counterparts.
>
> Based on an earlier version from Russell King:
>
> https://patchwork.kernel.org/patch/9277043/
>
> The hpd_notifier is a reference counted object containing the HPD/EDID/ELD 
> state
> of a video device.
>
> When a new notifier is registered the current state will be reported to
> that notifier at registration time.
>
> Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>
> Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>

For patches 1-6:
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
--
Regards
Andrzej


--
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 09/11] [media] s5p-mfc: Add support for HEVC encoder

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add HEVC encoder support and necessary registers, V4L2 CIDs,
> and hevc encoder parameters
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   28 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |   55 ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  595 
> +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|8 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  200 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |7 +
>  8 files changed, 895 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index 81a0a96..914ffec 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -20,13 +20,35 @@
>  #define S5P_FIMV_MFC_STATE_V10   0x7124
>  #define S5P_FIMV_D_STATIC_BUFFER_ADDR_V100xF570
>  #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V100xF574
> +#define S5P_FIMV_E_NUM_T_LAYER_V10   0xFBAC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V100xFBB0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V100xFBB4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V100xFBB8
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V100xFBBC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V100xFBC0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V100xFBC4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V100xFBC8
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V10  0xFD18
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V10  0xFD1C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V10  0xFD20
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V10  0xFD24
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V10  0xFD28
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V10  0xFD2C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V10  0xFD30
> +#define S5P_FIMV_E_HEVC_OPTIONS_V10  0xFDD4
> +#define S5P_FIMV_E_HEVC_REFRESH_PERIOD_V10   0xFDD8
> +#define S5P_FIMV_E_HEVC_CHROMA_QP_OFFSET_V10 0xFDDC
> +#define S5P_FIMV_E_HEVC_LF_BETA_OFFSET_DIV2_V10  0xFDE0
> +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V100xFDE4
> +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V10  0xFDE8
>  
>  /* MFCv10 Context buffer sizes */
>  #define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)/* 30KB */
>  #define MFC_H264_DEC_CTX_BUF_SIZE_V10(2 * SZ_1M) /* 2MB */
>  #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10   (20 * SZ_1K)/* 20KB */
>  #define MFC_H264_ENC_CTX_BUF_SIZE_V10(100 * SZ_1K)   /* 100KB */
> -#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10   (15 * SZ_1K)/* 15KB */
> +#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10(30 * SZ_1K)/* 30KB */
> +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10  (15 * SZ_1K) /* 15KB */
>  
>  /* MFCv10 variant defines */
>  #define MAX_FW_SIZE_V10  (SZ_1M) /* 1MB */
> @@ -37,6 +59,7 @@
>  /* MFCv10 codec defines*/
>  #define S5P_FIMV_CODEC_HEVC_DEC  17
>  #define S5P_FIMV_CODEC_VP9_DEC   18
> +#define S5P_FIMV_CODEC_HEVC_ENC 26
>  
>  /* Decoder buffer size for MFC v10 */
>  #define DEC_VP9_STATIC_BUFFER_SIZE   20480
> @@ -53,6 +76,9 @@
>  #define ENC_V100_VP8_ME_SIZE(x, y)   \
>   (((x + 3) * (y + 3) * 8)\
>+ (((y * 64) + 1280) * (x + 7) / 8))
> +#define ENC_V100_HEVC_ME_SIZE(x, y)  \
> + (((x + 3) * (y + 3) * 32)   \
> +  + (((y * 128) + 1280) * (x + 3) / 4))

Use DIV_ROUND_UP.

>  
>  #endif /*_REGS_MFC_V10_H*/
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index b014038..b01c556 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1549,6 +1549,7 @@ static int s5p_mfc_resume(struct device *dev)
>   .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
>   .other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
>   .h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V10,
> + .hevc_enc_ctx   = MFC_HEVC_ENC_CTX_BUF_SIZE_V10,
>   .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
>  };
>  
> 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 102b47e..7521fce 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -122,6 +122,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_VP8_ENC:
>   codec_type = S5P_FIMV_CODEC_VP8_ENC_V7;
>   break;
> + case 

Re: [PATCH 08/11] [media] s5p-mfc: Add VP9 decoder support

[Andrzej Hajda]

227,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>       ctx->scratch_buf_size +
>   (ctx->mv_count * ctx->mv_size);
>   break;
> + case S5P_MFC_CODEC_VP9_DEC:
> + mfc_debug(2, "Use min scratch buffer size\n");
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size, 256);

Again ALIGN and magic number.

Beside this:
Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>


> + ctx->bank1.size =
> + ctx->scratch_buf_size +
> + DEC_VP9_STATIC_BUFFER_SIZE;
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   if (IS_MFCV10(dev)) {
>   mfc_debug(2, "Use min scratch buffer size\n");
> @@ -338,6 +345,7 @@ static int s5p_mfc_alloc_instance_buffer_v6(struct 
> s5p_mfc_ctx *ctx)
>   case S5P_MFC_CODEC_VC1_DEC:
>   case S5P_MFC_CODEC_MPEG2_DEC:
>   case S5P_MFC_CODEC_VP8_DEC:
> + case S5P_MFC_CODEC_VP9_DEC:
>   ctx->ctx.size = buf_size->other_dec_ctx;
>   break;
>   case S5P_MFC_CODEC_H264_ENC:
> @@ -579,6 +587,14 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct 
> s5p_mfc_ctx *ctx)
>   }
>   }
>  
> + if (ctx->codec_mode == S5P_FIMV_CODEC_VP9_DEC) {
> + writel(buf_addr1, mfc_regs->d_static_buffer_addr);
> + writel(DEC_VP9_STATIC_BUFFER_SIZE,
> + mfc_regs->d_static_buffer_size);
> + buf_addr1 += DEC_VP9_STATIC_BUFFER_SIZE;
> + buf_size1 -= DEC_VP9_STATIC_BUFFER_SIZE;
> + }
> +
>   mfc_debug(2, "Buf1: %zu, buf_size1: %d (frames %d)\n",
>   buf_addr1, buf_size1, ctx->total_dpb_count);
>   if (buf_size1 < 0) {
> @@ -2286,6 +2302,18 @@ static unsigned int s5p_mfc_get_crop_info_v_v6(struct 
> s5p_mfc_ctx *ctx)
>   R(e_h264_options, S5P_FIMV_E_H264_OPTIONS_V8);
>   R(e_min_scratch_buffer_size, S5P_FIMV_E_MIN_SCRATCH_BUFFER_SIZE_V8);
>  
> + if (!IS_MFCV10(dev))
> + goto done;
> +
> + /* Initialize registers used in MFC v10 only.
> +  * Also, over-write the registers which have
> +  * a different offset for MFC v10.
> +  */
> +
> + /* decoder registers */
> + R(d_static_buffer_addr, S5P_FIMV_D_STATIC_BUFFER_ADDR_V10);
> + R(d_static_buffer_size, S5P_FIMV_D_STATIC_BUFFER_SIZE_V10);
> +
>  done:
>   return _regs;
>  #undef S5P_MFC_REG_ADDR


--
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 06/11] [media] videodev2.h: Add v4l2 definition for HEVC

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
>
> Signed-off-by: Smitha T Murthy <smith...@samsung.com>
Beside small nitpick.

Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

> ---
>  include/uapi/linux/videodev2.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 46e8a2e3..620e941 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -630,6 +630,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE 
> 421M Annex L compliant stream */
>  #define V4L2_PIX_FMT_VP8  v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
>  #define V4L2_PIX_FMT_VP9  v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> +#define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC */

I am not sure if it shouldn't be sorted alphabetically in compressed
formats stanza.

--
Regards
Andrzej


>  
>  /*  Vendor-specific formats   */
>  #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */


--
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 04/11] [media] s5p-mfc: Support MFCv10.10 buffer requirements

[Andrzej Hajda]

Hi Smitha,

Ups, I have missed this patch, I hope it wont influence the review :)


On 18.01.2017 11:02, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   13 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   97 
> ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |2 +
>  3 files changed, 91 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index bd671a5..153ee68 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,5 +32,18 @@
>  #define MFC_VERSION_V10  0xA0
>  #define MFC_NUM_PORTS_V101
>  
> +/* Encoder buffer size for MFC v10.0 */
> +#define ENC_V100_H264_ME_SIZE(x, y)  \
> + (((x + 3) * (y + 3) * 8)\
> +  + x * y) + 63) / 64) * 32) \
> +  + (((y * 64) + 1280) * (x + 7) / 8))
> +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> + (((x + 3) * (y + 3) * 8)\
> +  + x * y) + 127) / 128) * 16)   \
> +  + (((y * 64) + 1280) * (x + 7) / 8))
> +#define ENC_V100_VP8_ME_SIZE(x, y)   \
> + (((x + 3) * (y + 3) * 8)\
> +  + (((y * 64) + 1280) * (x + 7) / 8))
> +

Crazy, cryptic math here, I guess you can make it more readable by using
DIV_ROUND_UP macro and abstracting out common parts, for example:

#define ENC_V100_BASE_SIZE(x, y) \
(((x + 3) * (y + 3) * 8) \
+  ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))

#define ENC_V100_H264_ME_SIZE(x, y) \
(ENC_V100_BASE_SIZE(x, y)
+ DIV_ROUND_UP(x * y, 64) * 32)

#define ENC_V100_MPEG4_ME_SIZE(x, y) \
(ENC_V100_BASE_SIZE(x, y)
+ DIV_ROUND_UP(x * y, 128) * 16)

#define ENC_V100_VP8_ME_SIZE(x, y)  \
ENC_V100_BASE_SIZE(x, y)
 

>  #endif /*_REGS_MFC_V10_H*/
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index faceee6..369210a 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -64,6 +64,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>  {
>   struct s5p_mfc_dev *dev = ctx->dev;
>   unsigned int mb_width, mb_height;
> + unsigned int lcu_width = 0, lcu_height = 0;
>   int ret;
>  
>   mb_width = MB_WIDTH(ctx->img_width);
> @@ -74,7 +75,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
> ctx->luma_size, ctx->chroma_size, ctx->mv_size);
>   mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
>   } else if (ctx->type == MFCINST_ENCODER) {
> - if (IS_MFCV8_PLUS(dev))
> + if (IS_MFCV10(dev)) {
> + ctx->tmv_buffer_size = 0;
> + } else if (IS_MFCV8_PLUS(dev))
>   ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
>   ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
>   S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> @@ -82,13 +85,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
>   ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
>   S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> -
> - ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> - ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> + if (IS_MFCV10(dev)) {
> + lcu_width = enc_lcu_width(ctx->img_width);
> + lcu_height = enc_lcu_height(ctx->img_height);
> + if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> + ctx->luma_dpb_size =
> + ALIGNmb_width * 16) + 63) / 64)
> + * 64 * (((mb_height * 16) + 31)
> + / 32) * 32 + 64, 64);
> + ctx->chroma_dpb_size =
> + ALIGNmb_width * 16) + 63) / 64)
> + * 64 * (mb_height * 8)
> + + 64, 64);
> + } else {
> + ctx->luma_dpb_size =
> + ALIGNlcu_width * 32) + 63) / 64)
> + 

Re: [PATCH 05/11] [media] s5p-mfc: Add support for HEVC decoder

[Andrzej Hajda]

On 02.02.2017 08:58, Andrzej Hajda wrote:
> On 18.01.2017 11:02, Smitha T Murthy wrote:
>> Add support for codec definition and corresponding buffer
>> requirements for HEVC decoder.
>>
>> Signed-off-by: Smitha T Murthy <smith...@samsung.com>
>> ---
>>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |3 +++
>>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +++
>>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|8 
>>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   18 --
>>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |5 +
>>  6 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
>> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>> index 153ee68..a57009a 100644
>> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>> @@ -32,6 +32,9 @@
>>  #define MFC_VERSION_V10 0xA0
>>  #define MFC_NUM_PORTS_V10   1
>>  
>> +/* MFCv10 codec defines*/
>> +#define S5P_FIMV_CODEC_HEVC_DEC 17
>> +
>>  /* Encoder buffer size for MFC v10.0 */
>>  #define ENC_V100_H264_ME_SIZE(x, y) \
>>  (((x + 3) * (y + 3) * 8)\
>> 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 b1b1491..76eca67 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
>> @@ -101,6 +101,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
>> *ctx)
>>  case S5P_MFC_CODEC_VP8_DEC:
>>  codec_type = S5P_FIMV_CODEC_VP8_DEC_V6;
>>  break;
>> +case S5P_MFC_CODEC_HEVC_DEC:
>> +codec_type = S5P_FIMV_CODEC_HEVC_DEC;
>> +break;
>>  case S5P_MFC_CODEC_H264_ENC:
>>  codec_type = S5P_FIMV_CODEC_H264_ENC_V6;
>>  break;
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
>> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
>> index 998e24b..5c46060 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
>> @@ -79,6 +79,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void 
>> *b)
>>  #define S5P_MFC_CODEC_H263_DEC  5
>>  #define S5P_MFC_CODEC_VC1RCV_DEC6
>>  #define S5P_MFC_CODEC_VP8_DEC   7
>> +#define S5P_MFC_CODEC_HEVC_DEC  17
>>  
>>  #define S5P_MFC_CODEC_H264_ENC  20
>>  #define S5P_MFC_CODEC_H264_MVC_ENC  21
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
>> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>> index 784b28e..9f459b3 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>> @@ -156,6 +156,14 @@
>>  .versions   = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
>>  MFC_V10_BIT,
>>  },
>> +{
>> +.name   = "HEVC Encoded Stream",
>> +.fourcc = V4L2_PIX_FMT_HEVC,
>> +.codec_mode = S5P_FIMV_CODEC_HEVC_DEC,
>> +.type   = MFC_FMT_DEC,
>> +.num_planes = 1,
>> +.versions   = MFC_V10_BIT,
>> +},
>>  };
>>  
>>  #define NUM_FORMATS ARRAY_SIZE(formats)
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
>> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
>> index 369210a..b6cb280 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
>> @@ -220,6 +220,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
>> s5p_mfc_ctx *ctx)
>>  S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
>>  ctx->bank1.size = ctx->scratch_buf_size;
>>  break;
>> +case S5P_MFC_CODEC_HEVC_DEC:
>> +mfc_debug(2, "Use min scratch buffer size\n");
>> +ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size, 256);
> Again alignment of something which should be already aligned, and magic
> number instead of S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6.
>
>> +ctx->bank1.size =
>> +ctx->scratch_buf_size +
>> +(ctx->mv_cou

Re: [PATCH 05/11] [media] s5p-mfc: Add support for HEVC decoder

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add support for codec definition and corresponding buffer
> requirements for HEVC decoder.
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|8 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   18 --
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |5 +
>  6 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index 153ee68..a57009a 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,6 +32,9 @@
>  #define MFC_VERSION_V10  0xA0
>  #define MFC_NUM_PORTS_V101
>  
> +/* MFCv10 codec defines*/
> +#define S5P_FIMV_CODEC_HEVC_DEC  17
> +
>  /* Encoder buffer size for MFC v10.0 */
>  #define ENC_V100_H264_ME_SIZE(x, y)  \
>   (((x + 3) * (y + 3) * 8)\
> 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 b1b1491..76eca67 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -101,6 +101,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_VP8_DEC:
>   codec_type = S5P_FIMV_CODEC_VP8_DEC_V6;
>   break;
> + case S5P_MFC_CODEC_HEVC_DEC:
> + codec_type = S5P_FIMV_CODEC_HEVC_DEC;
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   codec_type = S5P_FIMV_CODEC_H264_ENC_V6;
>   break;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 998e24b..5c46060 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -79,6 +79,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void 
> *b)
>  #define S5P_MFC_CODEC_H263_DEC   5
>  #define S5P_MFC_CODEC_VC1RCV_DEC 6
>  #define S5P_MFC_CODEC_VP8_DEC7
> +#define S5P_MFC_CODEC_HEVC_DEC   17
>  
>  #define S5P_MFC_CODEC_H264_ENC   20
>  #define S5P_MFC_CODEC_H264_MVC_ENC   21
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 784b28e..9f459b3 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -156,6 +156,14 @@
>   .versions   = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
>   MFC_V10_BIT,
>   },
> + {
> + .name   = "HEVC Encoded Stream",
> + .fourcc = V4L2_PIX_FMT_HEVC,
> + .codec_mode = S5P_FIMV_CODEC_HEVC_DEC,
> + .type   = MFC_FMT_DEC,
> + .num_planes = 1,
> + .versions   = MFC_V10_BIT,
> + },
>  };
>  
>  #define NUM_FORMATS ARRAY_SIZE(formats)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 369210a..b6cb280 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -220,6 +220,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
>   ctx->bank1.size = ctx->scratch_buf_size;
>   break;
> + case S5P_MFC_CODEC_HEVC_DEC:
> + mfc_debug(2, "Use min scratch buffer size\n");
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size, 256);

Again alignment of something which should be already aligned, and magic
number instead of S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6.

> + ctx->bank1.size =
> + ctx->scratch_buf_size +
> + (ctx->mv_count * ctx->mv_size);
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   if (IS_MFCV10(dev)) {
>   mfc_debug(2, "Use min scratch buffer size\n");
> @@ -322,6 +329,7 @@ static int s5p_mfc_alloc_instance_buffer_v6(struct 
> s5p_mfc_ctx *ctx)
>   switch (ctx->codec_mode) {
>   case S5P_MFC_CODEC_H264_DEC:
>   case S5P_MFC_CODEC_H264_MVC_DEC:
> + case S5P_MFC_CODEC_HEVC_DEC:
>   ctx->ctx.size = buf_size->h264_dec_ctx;
>   break;
>   case S5P_MFC_CODEC_MPEG4_DEC:
> @@ -438,6 +446,10 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->img_height);
>   

Re: [PATCH 03/11] [media] s5p-mfc: Use min scratch buffer size

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
> size is required for decoder. If mfc f/w has the functionality,
> E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
> is required for encoder too.

Subject says "Use min scratch buffer size" but it is already used.
Maybe it should be changed to sth like:
Use min scratch buffer size provided by F/W

>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v8.h|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|7 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|4 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   68 
> +--
>  6 files changed, 67 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> index 4d1c375..2cd396b 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> @@ -17,6 +17,7 @@
>  
>  /* Additional registers for v8 */
>  #define S5P_FIMV_D_MVC_NUM_VIEWS_V8  0xf104
> +#define S5P_FIMV_D_MIN_SCRATCH_BUFFER_SIZE_V80xf108
>  #define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8   0xf144
>  #define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V8  0xf148
>  #define S5P_FIMV_D_MV_BUFFER_SIZE_V8 0xf150
> @@ -84,6 +85,7 @@
>  
>  #define S5P_FIMV_E_VBV_BUFFER_SIZE_V80xf78c
>  #define S5P_FIMV_E_VBV_INIT_DELAY_V8 0xf790
> +#define S5P_FIMV_E_MIN_SCRATCH_BUFFER_SIZE_V8   0xf894
>  
>  #define S5P_FIMV_E_ASPECT_RATIO_V8   0xfb4c
>  #define S5P_FIMV_E_EXTENDED_SAR_V8   0xfb50
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index a043cce..b014038 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -520,6 +520,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx 
> *ctx,
>   dev);
>   ctx->mv_count = s5p_mfc_hw_call(dev->mfc_ops, get_mv_count,
>   dev);
> + ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
> + get_min_scratch_buf_size, dev);
>   if (ctx->img_width == 0 || ctx->img_height == 0)
>   ctx->state = MFCINST_ERROR;
>   else
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 1941c63..998e24b 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -724,6 +724,7 @@ struct mfc_control {
>  #define IS_MFCV7_PLUS(dev)   (dev->variant->version >= 0x70 ? 1 : 0)
>  #define IS_MFCV8_PLUS(dev)   (dev->variant->version >= 0x80 ? 1 : 0)
>  #define IS_MFCV10(dev)   (dev->variant->version >= 0xA0 ? 1 : 0)
> +#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10(dev))
>  
>  #define MFC_V5_BIT   BIT(0)
>  #define MFC_V6_BIT   BIT(1)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 9042378..ef15831 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -818,6 +818,13 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
>   get_enc_dpb_count, dev);
>   if (ctx->pb_count < enc_pb_count)
>   ctx->pb_count = enc_pb_count;
> + if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
> + ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
> + get_e_min_scratch_buf_size, dev);
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size,
> + S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);

Do we really need to align it here? Does firmware return unaligned value?
Even then the alignment (if necessary) should be moved rather to
get_e_min_scratch_buf_size.

> + ctx->bank1.size += ctx->scratch_buf_size;
> + }
>   ctx->state = MFCINST_HEAD_PRODUCED;
>   }
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> index b6ac417..6478f70 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> @@ -169,6 +169,7 @@ struct s5p_mfc_regs {
>   void __iomem *d_decoded_third_addr;/* only v7 */
>   void __iomem *d_used_dpb_flag_upper;/* v7 and v8 */
>   void __iomem *d_used_dpb_flag_lower;/* v7 and v8 */
> + void __iomem *d_min_scratch_buffer_size; /* v10 */
>  
>   /* encoder registers */
>   

Re: [PATCH 02/11] [media] s5p-mfc: Adding initial support for MFC v10.10

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Adding the support for MFC v10.10, with new register file and
> necessary hw control, decoder, encoder and structural changes.
>
> CC: Rob Herring 
> CC: devicet...@vger.kernel.org 
> Signed-off-by: Smitha T Murthy 
> ---
>  .../devicetree/bindings/media/s5p-mfc.txt  |1 +
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |   36 
>  drivers/media/platform/s5p-mfc/s5p_mfc.c   |   30 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|4 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |4 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |   44 
> +++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   |   21 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c|9 +++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|2 +
>  9 files changed, 118 insertions(+), 33 deletions(-)
>  create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> index 2c90128..b70c613 100644
> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> @@ -13,6 +13,7 @@ Required properties:
>   (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
>   (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
>   (e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
> + (f) "samsung,mfc-v10" for MFC v10 present in a variant of Exynos7 SoC

Could you specify explicitly SoC version(s), Exynos7 is misleading.
Btw are there plans to upstream platforms using this MFC?

>  
>- reg : Physical base address of the IP registers and length of memory
> mapped region.
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> new file mode 100644
> index 000..bd671a5
> --- /dev/null
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -0,0 +1,36 @@
> +/*
> + * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
> + *
> + * Copyright (c) 2017 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _REGS_MFC_V10_H
> +#define _REGS_MFC_V10_H
> +
> +#include 
> +#include "regs-mfc-v8.h"
> +
> +/* MFCv10 register definitions*/
> +#define S5P_FIMV_MFC_CLOCK_OFF_V10   0x7120
> +#define S5P_FIMV_MFC_STATE_V10   0x7124
> +
> +/* MFCv10 Context buffer sizes */
> +#define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)/* 30KB */
> +#define MFC_H264_DEC_CTX_BUF_SIZE_V10(2 * SZ_1M) /* 2MB */
> +#define MFC_OTHER_DEC_CTX_BUF_SIZE_V10   (20 * SZ_1K)/* 20KB */
> +#define MFC_H264_ENC_CTX_BUF_SIZE_V10(100 * SZ_1K)   /* 100KB */
> +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10   (15 * SZ_1K)/* 15KB */
> +
> +/* MFCv10 variant defines */
> +#define MAX_FW_SIZE_V10  (SZ_1M) /* 1MB */
> +#define MAX_CPB_SIZE_V10 (3 * SZ_1M) /* 3MB */
> +#define MFC_VERSION_V10  0xA0
> +#define MFC_NUM_PORTS_V101
> +
> +#endif /*_REGS_MFC_V10_H*/
> +
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index bb0a588..a043cce 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1542,6 +1542,33 @@ static int s5p_mfc_resume(struct device *dev)
>   .num_clocks = 3,
>  };
>  
> +static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
> + .dev_ctx= MFC_CTX_BUF_SIZE_V10,
> + .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
> + .other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
> + .h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V10,
> + .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
> +};
> +
> +static struct s5p_mfc_buf_size buf_size_v10 = {
> + .fw = MAX_FW_SIZE_V10,
> + .cpb= MAX_CPB_SIZE_V10,
> + .priv   = _buf_size_v10,
> +};
> +
> +static struct s5p_mfc_buf_align mfc_buf_align_v10 = {
> + .base = 0,
> +};
> +
> +static struct s5p_mfc_variant mfc_drvdata_v10 = {
> + .version= MFC_VERSION_V10,
> + .version_bit= MFC_V10_BIT,
> + .port_num   = MFC_NUM_PORTS_V10,
> + .buf_size   = _size_v10,
> + .buf_align  = _buf_align_v10,
> + .fw_name[0] = "s5p-mfc-v10.fw",

Is firmware file publicly available? Sent to firmware repository?

> +};
> +
>  static const struct of_device_id exynos_mfc_match[] = {
>   {
>   .compatible = "samsung,mfc-v5",
> @@ -1558,6 +1585,9 @@ static int s5p_mfc_resume(struct device 

Re: [PATCH 01/11] [media] s5p-mfc: Rename IS_MFCV8 macro

[Andrzej Hajda]

On 18.01.2017 11:01, Smitha T Murthy wrote:
> This patch renames macro IS_MFCV8 to IS_MFCV8_PLUS so that the MFCv8
> code can be resued for MFCv10.10 support. Since the MFCv8 specific code
> holds good for MFC v10.10 also.
>
> Signed-off-by: Smitha T Murthy <smith...@samsung.com>

Acked-by: Andrzej Hajda <a.ha...@samsung.com>
--
Regards
Andrzej

> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |2 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|2 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   18 +-
>  4 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index ab23236..b45d18c 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -722,7 +722,7 @@ struct mfc_control {
>  #define IS_TWOPORT(dev)  (dev->variant->port_num == 2 ? 1 : 0)
>  #define IS_MFCV6_PLUS(dev)   (dev->variant->version >= 0x60 ? 1 : 0)
>  #define IS_MFCV7_PLUS(dev)   (dev->variant->version >= 0x70 ? 1 : 0)
> -#define IS_MFCV8(dev)(dev->variant->version >= 0x80 ? 1 : 0)
> +#define IS_MFCV8_PLUS(dev)   (dev->variant->version >= 0x80 ? 1 : 0)
>  
>  #define MFC_V5_BIT   BIT(0)
>  #define MFC_V6_BIT   BIT(1)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> index cc88871..484af6b 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> @@ -427,7 +427,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
>   s5p_mfc_clear_cmds(dev);
>   s5p_mfc_clean_dev_int_flags(dev);
>   /* 3. Send MFC wakeup command and wait for completion*/
> - if (IS_MFCV8(dev))
> + if (IS_MFCV8_PLUS(dev))
>   ret = s5p_mfc_v8_wait_wakeup(dev);
>   else
>   ret = s5p_mfc_wait_wakeup(dev);
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 367ef8e..0ec2928 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -1177,7 +1177,7 @@ void s5p_mfc_dec_init(struct s5p_mfc_ctx *ctx)
>   struct v4l2_format f;
>   f.fmt.pix_mp.pixelformat = V4L2_PIX_FMT_H264;
>   ctx->src_fmt = find_format(, MFC_FMT_DEC);
> - if (IS_MFCV8(ctx->dev))
> + if (IS_MFCV8_PLUS(ctx->dev))
>   f.fmt.pix_mp.pixelformat = V4L2_PIX_FMT_NV12M;
>   else if (IS_MFCV6_PLUS(ctx->dev))
>   f.fmt.pix_mp.pixelformat = V4L2_PIX_FMT_NV12MT_16X16;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 57da798..0572521 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -74,7 +74,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
> ctx->luma_size, ctx->chroma_size, ctx->mv_size);
>   mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
>   } else if (ctx->type == MFCINST_ENCODER) {
> - if (IS_MFCV8(dev))
> + if (IS_MFCV8_PLUS(dev))
>   ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
>   ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
>   S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> @@ -89,7 +89,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
>   S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
>   S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> - if (IS_MFCV8(dev))
> + if (IS_MFCV8_PLUS(dev))
>   ctx->me_buffer_size = ALIGN(S5P_FIMV_ME_BUFFER_SIZE_V8(
>   ctx->img_width, ctx->img_height,
>   mb_width, mb_height),
> @@ -110,7 +110,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   switch (ctx->codec_mode) {
>   case S5P_MFC_CODEC_H264_DEC:
>   case S5P_MFC_CODEC_H264_MVC_DEC:
> - if (IS_MFCV8(dev))
> + if (IS_MFCV8_PLUS(dev))
>   ctx->scratch_buf_size =
>   S5P_FIMV_SCRATCH_BUF_SIZE_H264_DEC_V8(
&g

Re: [PATCH] [media] s5p-mfc: Align stream buffer and CPB buffer to 512

[Andrzej Hajda]

Hi Smitha,

On 18.01.2017 10:37, Smitha T Murthy wrote:
> >From MFCv6 onwards encoder stream buffer and decoder CPB buffer

Unexpected char at the beginning.

> need to be aligned with 512.

Patch below adds checks only if buffer size is multiple of 512, am I right?
If yes, please precise the subject, for example "...CPB buffer size need
to be...".


>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |9 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |3 +++
>  2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index d6f207e..57da798 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -408,8 +408,15 @@ static int s5p_mfc_set_dec_stream_buffer_v6(struct 
> s5p_mfc_ctx *ctx,
>   struct s5p_mfc_dev *dev = ctx->dev;
>   const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
>   struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
> + size_t cpb_buf_size;
>  
>   mfc_debug_enter();
> + cpb_buf_size = ALIGN(buf_size->cpb, CPB_ALIGN);

Since buf_size->cpb is constant of know size there is no need to align
it here.

> + if (strm_size >= set_strm_size_max(cpb_buf_size)) {
> + mfc_debug(2, "Decrease strm_size : %u -> %zu, gap : %d\n",
> + strm_size, set_strm_size_max(cpb_buf_size), CPB_ALIGN);
> + strm_size = set_strm_size_max(cpb_buf_size);
> + }

As I understand strm_size here is a size of buffer to be decoded, why it
cannot be equal to buf_size->cpb? Commit message says nothing about it.

>   mfc_debug(2, "inst_no: %d, buf_addr: 0x%08x,\n"
>   "buf_size: 0x%08x (%d)\n",
>   ctx->inst_no, buf_addr, strm_size, strm_size);
> @@ -519,6 +526,8 @@ static int s5p_mfc_set_enc_stream_buffer_v6(struct 
> s5p_mfc_ctx *ctx,
>   struct s5p_mfc_dev *dev = ctx->dev;
>   const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
>  
> + size = ALIGN(size, 512);
> +

Shouldn't be CPB_ALIGN instead of 512? And more importantly size is a
length of buffer for encoded stream,
by up-aligning you tell MFC that it can write beyond the buffer, it
could potentially overwrite random memory? Am I right?


>   writel(addr, mfc_regs->e_stream_buffer_addr); /* 16B align */
>   writel(size, mfc_regs->e_stream_buffer_size);
>  
> 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 8055848..16a7b1d 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
> @@ -40,6 +40,9 @@
>  #define FRAME_DELTA_H264_H2631
>  #define TIGHT_CBR_MAX10
>  
> +#define CPB_ALIGN512
> +#define set_strm_size_max(cpb_max)   ((cpb_max) - CPB_ALIGN)

Name of the macro is misleading.

Regards
Andrzej

> +
>  struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v6(void);
>  const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev 
> *dev);
>  #endif /* S5P_MFC_OPR_V6_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

[PATCH] v4l: s5c73m3: fix negation operator

[Andrzej Hajda]

Bool values should be negated using logical operators. Using bitwise operators
results in unexpected and possibly incorrect results.

Reported-by: David Binderman <dcb...@hotmail.com>
Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c 
b/drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c
index 0a06033..2e71850 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c
@@ -211,7 +211,7 @@ static int s5c73m3_3a_lock(struct s5c73m3 *state, struct 
v4l2_ctrl *ctrl)
}
 
if ((ctrl->val ^ ctrl->cur.val) & V4L2_LOCK_FOCUS)
-   ret = s5c73m3_af_run(state, ~af_lock);
+   ret = s5c73m3_af_run(state, !af_lock);
 
return ret;
 }
-- 
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

Re: [PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging

[Andrzej Hajda]

On 03.01.2017 09:11, Hans Verkuil wrote:
> On 01/03/2017 09:00 AM, Andrzej Hajda wrote:
>> Is there a reason to split registration into two steps?
>> Wouldn't be better to integrate hpd_notifier_get into
>> cec_register_hpd_notifier.
> One problem is that hpd_notifier_get can fail, whereas 
> cec_register_hpd_notifier can't.
> And I rather not have to register a CEC device only to unregister it again if 
> the
> hpd_notifier_get would fail.

hpd_notifier_get can fail only due to lack of memory for about 150 bytes
so if it happens whole system will probably fail anyway :)


>
> Another reason is that this keeps the responsibility of the hpd_notifier 
> life-time
> handling in the driver instead of hiding it in the CEC framework, which is 
> IMHO
> unexpected.

Notifier is used only by CEC framework, so IMHO it would be desirable to
put CEC specific things into CEC framework.
Drivers duty is just to find notifier device.
Leaving it as is will just put little more burden on drivers, so this is
not big deal, do as you wish :)

Regards
Andrzej

>
> I think I want to keep this as-is, at least for now.
>
> Regards,
>
>   Hans
>
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging

[Andrzej Hajda]

On 02.01.2017 15:19, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> By using the HPD notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> this move as well.
>
> Update the bindings documenting the new hdmi phandle and
> update exynos4.dtsi accordingly.
>
> Tested with my Odroid U3.
>
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> ---
>  .../devicetree/bindings/media/s5p-cec.txt  |  2 ++
>  arch/arm/boot/dts/exynos4.dtsi |  1 +
>  drivers/media/platform/Kconfig | 18 +++
>  drivers/media/platform/Makefile|  1 +
>  .../media => media/platform}/s5p-cec/Makefile  |  0
>  .../platform}/s5p-cec/exynos_hdmi_cec.h|  0
>  .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|  0
>  .../media => media/platform}/s5p-cec/regs-cec.h|  0
>  .../media => media/platform}/s5p-cec/s5p_cec.c | 35 
> ++
>  .../media => media/platform}/s5p-cec/s5p_cec.h |  3 ++
>  drivers/staging/media/Kconfig  |  2 --
>  drivers/staging/media/Makefile |  1 -
>  drivers/staging/media/s5p-cec/Kconfig  |  9 --
>  drivers/staging/media/s5p-cec/TODO |  7 -
>  14 files changed, 55 insertions(+), 24 deletions(-)
>  rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h 
> (100%)
>  rename drivers/{staging/media => 
> media/platform}/s5p-cec/exynos_hdmi_cecctrl.c (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
>  delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
>  delete mode 100644 drivers/staging/media/s5p-cec/TODO
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
> b/Documentation/devicetree/bindings/media/s5p-cec.txt
> index 925ab4d..710fc00 100644
> --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
> @@ -15,6 +15,7 @@ Required properties:
>- 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
> +  - samsung,hdmi-phandle - phandle to the HDMI controller
>  
>  Example:
>  
> @@ -25,6 +26,7 @@ hdmicec: cec@100B {
>   clocks = < CLK_HDMI_CEC>;
>   clock-names = "hdmicec";
>   samsung,syscon-phandle = <_system_controller>;
> + samsung,hdmi-phandle = <>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_cec>;
>   status = "okay";
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index c64737b..51dfcbb 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -762,6 +762,7 @@
>   clocks = < CLK_HDMI_CEC>;
>   clock-names = "hdmicec";
>   samsung,syscon-phandle = <_system_controller>;
> + samsung,hdmi-phandle = <>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_cec>;
>   status = "disabled";
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index d944421..cab1637 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -392,6 +392,24 @@ config VIDEO_TI_SC
>  config VIDEO_TI_CSC
>   tristate
>  
> +menuconfig V4L_CEC_DRIVERS
> + bool "Platform HDMI CEC drivers"
> + depends on MEDIA_CEC_SUPPORT
> +
> +if V4L_CEC_DRIVERS
> +
> +config VIDEO_SAMSUNG_S5P_CEC
> +   tristate "Samsung S5P CEC driver"
> +   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS 
> || COMPILE_TEST)
> +   select HPD_NOTIFIERS
> +   ---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.
> +
> +endif #V4L_CEC_DRIVERS
> +
>  menuconfig V4L_TEST_DRIVERS
>   bool "Media test drivers"
>   depends on MEDIA_CAMERA_SUPPORT
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 5b3cb27..ad3bf22 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)+= s5p-jpeg/
>  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)  += s5p-mfc/
>  
>  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)  += s5p-g2d/
> +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)  += s5p-cec/
>  

Re: [PATCHv2 2/4] exynos_hdmi: add HPD notifier support

[Andrzej Hajda]

On 02.01.2017 15:19, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> Implement the HPD notifier support to allow CEC drivers to
> be informed when there is a new EDID and when a connect or
> disconnect happens.
>
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/Kconfig   |  1 +
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 24 +---
>  2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index d706ca4..80bfd1d 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -77,6 +77,7 @@ config DRM_EXYNOS_DP
>  config DRM_EXYNOS_HDMI
>   bool "HDMI"
>   depends on DRM_EXYNOS_MIXER || DRM_EXYNOS5433_DECON
> + select HPD_NOTIFIERS
>   help
> Choose this option if you want to use Exynos HDMI for DRM.
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 5ed8b1e..28bf609 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -118,6 +119,7 @@ struct hdmi_context {
>   booldvi_mode;
>   struct delayed_work hotplug_work;
>   struct drm_display_mode current_mode;
> + struct hpd_notifier *notifier;
>   const struct hdmi_driver_data   *drv_data;
>  
>   void __iomem*regs;
> @@ -807,9 +809,12 @@ static enum drm_connector_status hdmi_detect(struct 
> drm_connector *connector,
>  {
>   struct hdmi_context *hdata = connector_to_hdmi(connector);
>  
> - if (gpiod_get_value(hdata->hpd_gpio))
> + if (gpiod_get_value(hdata->hpd_gpio)) {
> + hpd_event_connect(hdata->notifier);
>   return connector_status_connected;
> + }
>  
> + hpd_event_disconnect(hdata->notifier);
>   return connector_status_disconnected;
>  }
>  
> @@ -848,6 +853,9 @@ static int hdmi_get_modes(struct drm_connector *connector)
>   edid->width_cm, edid->height_cm);
>  
>   drm_mode_connector_update_edid_property(connector, edid);
> + hpd_event_connect(hdata->notifier);

Is there a reason to call hpd_event_connect here? It was called already
from hdmi_detect.

Regards
Andrzej

> + hpd_event_new_edid(hdata->notifier, edid,
> + EDID_LENGTH * (1 + edid->extensions));
>  
>   ret = drm_add_edid_modes(connector, edid);
>  
> @@ -1483,6 +1491,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
>   if (funcs && funcs->disable)
>   (*funcs->disable)(crtc);
>  
> + hpd_event_disconnect(hdata->notifier);
>   cancel_delayed_work(>hotplug_work);
>  
>   hdmiphy_disable(hdata);
> @@ -1832,15 +1841,22 @@ static int hdmi_probe(struct platform_device *pdev)
>   }
>   }
>  
> + hdata->notifier = hpd_notifier_get(>dev);
> + if (hdata->notifier == NULL) {
> + ret = -ENOMEM;
> + goto err_hdmiphy;
> + }
> +
>   pm_runtime_enable(dev);
>  
>   ret = component_add(>dev, _component_ops);
>   if (ret)
> - goto err_disable_pm_runtime;
> + goto err_notifier_put;
>  
>   return ret;
>  
> -err_disable_pm_runtime:
> +err_notifier_put:
> + hpd_notifier_put(hdata->notifier);
>   pm_runtime_disable(dev);
>  
>  err_hdmiphy:
> @@ -1859,9 +1875,11 @@ static int hdmi_remove(struct platform_device *pdev)
>   struct hdmi_context *hdata = platform_get_drvdata(pdev);
>  
>   cancel_delayed_work_sync(>hotplug_work);
> + hpd_event_disconnect(hdata->notifier);
>  
>   component_del(>dev, _component_ops);
>  
> + hpd_notifier_put(hdata->notifier);
>   pm_runtime_disable(>dev);
>  
>   if (!IS_ERR(hdata->reg_hdmi_en))


--
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/4] video: add hotplug detect notifier support

[Andrzej Hajda]

Hi Hans,

On 02.01.2017 15:19, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> Add support for video hotplug detect and EDID/ELD notifiers, which is used
> to convey information from video drivers to their CEC and audio counterparts.
>
> Based on an earlier version from Russell King:
>
> https://patchwork.kernel.org/patch/9277043/
>
> The hpd_notifier is a reference counted object containing the HPD/EDID/ELD 
> state
> of a video device.
>
> When a new notifier is registered the current state will be reported to
> that notifier at registration time.
>
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> ---
>  drivers/video/Kconfig|   3 +
>  drivers/video/Makefile   |   1 +
>  drivers/video/hpd-notifier.c | 134 
> +++
>  include/linux/hpd-notifier.h | 109 +++
>  4 files changed, 247 insertions(+)
>  create mode 100644 drivers/video/hpd-notifier.c
>  create mode 100644 include/linux/hpd-notifier.h
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..cddc860 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
>  config HDMI
>   bool
>  
> +config HPD_NOTIFIERS
> + bool
> +
>  if VT
>   source "drivers/video/console/Kconfig"
>  endif
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 9ad3c17..424698b 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_VGASTATE)+= vgastate.o
>  obj-$(CONFIG_HDMI)+= hdmi.o
> +obj-$(CONFIG_HPD_NOTIFIERS)   += hpd-notifier.o
>  
>  obj-$(CONFIG_VT)   += console/
>  obj-$(CONFIG_LOGO) += logo/
> diff --git a/drivers/video/hpd-notifier.c b/drivers/video/hpd-notifier.c
> new file mode 100644
> index 000..54f7a6b
> --- /dev/null
> +++ b/drivers/video/hpd-notifier.c
> @@ -0,0 +1,134 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static LIST_HEAD(hpd_notifiers);
> +static DEFINE_MUTEX(hpd_notifiers_lock);
> +
> +struct hpd_notifier *hpd_notifier_get(struct device *dev)
> +{
> + struct hpd_notifier *n;
> +
> + mutex_lock(_notifiers_lock);
> + list_for_each_entry(n, _notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(_notifiers_lock);

I think this place is racy, we have pointer to unprotected area
(n->kref), so if concurrent thread calls hpd_notifier_put in this moment
>kref could be freed and kref_get in the next line will operate on
dangling pointer. Am I right?

Regards
Andrzej

> + kref_get(>kref);
> + return n;
> + }
> + }
> + n = kzalloc(sizeof(*n), GFP_KERNEL);
> + if (!n)
> + goto unlock;
> + n->dev = dev;
> + mutex_init(>lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(>notifiers);
> + kref_init(>kref);
> + list_add_tail(>head, _notifiers);
> +unlock:
> + mutex_unlock(_notifiers_lock);
> + return n;
> +}
> +EXPORT_SYMBOL_GPL(hpd_notifier_get);
> +
> +static void hpd_notifier_release(struct kref *kref)
> +{
> + struct hpd_notifier *n =
> + container_of(kref, struct hpd_notifier, kref);
> +
> + mutex_lock(_notifiers_lock);
> + list_del(>head);
> + mutex_unlock(_notifiers_lock);
> + kfree(n->edid);
> + kfree(n);
> +}
> +
> +void hpd_notifier_put(struct hpd_notifier *n)
> +{
> + kref_put(>kref, hpd_notifier_release);
> +}
> +EXPORT_SYMBOL_GPL(hpd_notifier_put);
> +
> +int hpd_notifier_register(struct hpd_notifier *n, struct notifier_block *nb)
> +{
> + int ret = blocking_notifier_chain_register(>notifiers, nb);
> +
> + if (ret)
> + return ret;
> + kref_get(>kref);
> + mutex_lock(>lock);
> + if (n->connected) {
> + blocking_notifier_call_chain(>notifiers, HPD_CONNECTED, n);
> + if (n->edid_size)
> + blocking_notifier_call_chain(>notifiers, 
> HPD_NEW_EDID, n);
> + if (n->has_eld)
> + blocking_notifier_call_chain(>notifiers, 
> HPD_NEW_ELD, n);
> + }
> + mutex_unlock(>lock);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(hpd_notifier_register);
> +
> +int hpd_notifier_unregister(struct hpd_notifier *n, struct notifier_block 
> *nb)
> +{
> + int ret = blocking_notifier_chain_unregister(>notifiers, nb);
> +
> + if (ret == 0)
> + hpd_notifier_put(n);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(hpd_notifier_unregister);
(...)

--
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: MFC: different h264 profile and level output the same size encoded result

[Andrzej Hajda]

Hi,

On 08/27/2016 11:55 AM, Randy Li wrote:
> Hi:
>
>I have been reported that the setting the profile, level and bitrate 
> through the v4l2 extra controls would not make the encoded result 
> different. I tried it recently, it is true. Although the h264 parser 
> would tell me the result have been applied as different h264 profile and 
> level, but size is the same.
>
> You may try this in Gstreamer.
>
> gst-launch-1.0 -v \
> videotestsrc num-buffers=500 ! video/x-raw, width=1920,height=1080 ! \
> videoconvert ! \
> v4l2video4h264enc 
> extra-controls="controls,h264_profile=1,video_bitrate=100;" ! \
> h264parse ! matroskamux ! filesink location=/tmp/1.mkv
>
> Is there any way to reduce the size of MFC encoded data?
>

There is control called rc_enable (rate control enable), it must be set
to one if you want to control bitrate.
This control confuses many users, I guess it cannot be removed as it
is already part of UAPI, but enabling it internally by the driver
if user sets bitrate, profille, etc, would make it more saner.

Regards
Andrzej

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] s5p-mfc: use one implementation of s5p_mfc_get_new_ctx

[Andrzej Hajda]

Both version of MFC driver uses functions with the same body and name.
The patch moves them to common location. It also simplifies it.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 20 
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 21 -
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 24 
 4 files changed, 21 insertions(+), 45 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3ffe2ec..8bae7df 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -85,6 +85,26 @@ void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx)
spin_unlock_irqrestore(>condlock, flags);
 }
 
+int s5p_mfc_get_new_ctx(struct s5p_mfc_dev *dev)
+{
+   unsigned long flags;
+   int ctx;
+
+   spin_lock_irqsave(>condlock, flags);
+   ctx = dev->curr_ctx;
+   do {
+   ctx = (ctx + 1) % MFC_NUM_CONTEXTS;
+   if (ctx == dev->curr_ctx) {
+   if (!test_bit(ctx, >ctx_work_bits))
+   ctx = -EAGAIN;
+   break;
+   }
+   } while (!test_bit(ctx, >ctx_work_bits));
+   spin_unlock_irqrestore(>condlock, flags);
+
+   return ctx;
+}
+
 /* Wake up context wait_queue */
 static void wake_up_ctx(struct s5p_mfc_ctx *ctx, unsigned int reason,
unsigned int err)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index d1a3f9b..0cdb37e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -710,6 +710,7 @@ void clear_work_bit(struct s5p_mfc_ctx *ctx);
 void set_work_bit(struct s5p_mfc_ctx *ctx);
 void clear_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
 void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
+int s5p_mfc_get_new_ctx(struct s5p_mfc_dev *dev);
 
 #define HAS_PORTNUM(dev)   (dev ? (dev->variant ? \
(dev->variant->port_num ? 1 : 0) : 0) : 0)
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 873c933..d9e5d68 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -1153,27 +1153,6 @@ static int s5p_mfc_encode_one_frame_v5(struct 
s5p_mfc_ctx *ctx)
return 0;
 }
 
-static int s5p_mfc_get_new_ctx(struct s5p_mfc_dev *dev)
-{
-   unsigned long flags;
-   int new_ctx;
-   int cnt;
-
-   spin_lock_irqsave(>condlock, flags);
-   new_ctx = (dev->curr_ctx + 1) % MFC_NUM_CONTEXTS;
-   cnt = 0;
-   while (!test_bit(new_ctx, >ctx_work_bits)) {
-   new_ctx = (new_ctx + 1) % MFC_NUM_CONTEXTS;
-   if (++cnt > MFC_NUM_CONTEXTS) {
-   /* No contexts to run */
-   spin_unlock_irqrestore(>condlock, flags);
-   return -EAGAIN;
-   }
-   }
-   spin_unlock_irqrestore(>condlock, flags);
-   return new_ctx;
-}
-
 static void s5p_mfc_run_res_change(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_dev *dev = ctx->dev;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index b958453..f68653f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1507,30 +1507,6 @@ static int s5p_mfc_encode_one_frame_v6(struct 
s5p_mfc_ctx *ctx)
return 0;
 }
 
-static inline int s5p_mfc_get_new_ctx(struct s5p_mfc_dev *dev)
-{
-   unsigned long flags;
-   int new_ctx;
-   int cnt;
-
-   spin_lock_irqsave(>condlock, flags);
-   mfc_debug(2, "Previous context: %d (bits %08lx)\n", dev->curr_ctx,
-   dev->ctx_work_bits);
-   new_ctx = (dev->curr_ctx + 1) % MFC_NUM_CONTEXTS;
-   cnt = 0;
-   while (!test_bit(new_ctx, >ctx_work_bits)) {
-   new_ctx = (new_ctx + 1) % MFC_NUM_CONTEXTS;
-   cnt++;
-   if (cnt > MFC_NUM_CONTEXTS) {
-   /* No contexts to run */
-   spin_unlock_irqrestore(>condlock, flags);
-   return -EAGAIN;
-   }
-   }
-   spin_unlock_irqrestore(>condlock, flags);
-   return new_ctx;
-}
-
 static inline void s5p_mfc_run_dec_last_frames(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_dev *dev = ctx->dev;
-- 
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

[PATCH 5/6] s5p-mfc: merge together s5p_mfc_hw_call and s5p_mfc_hw_call_void

[Andrzej Hajda]

Both macros can be merged into one.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 38 -
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  8 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 16 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 12 
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 20 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 16 +--
 6 files changed, 52 insertions(+), 58 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index c4d9e34..81ffb67 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -374,11 +374,11 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
if (res_change == S5P_FIMV_RES_INCREASE ||
res_change == S5P_FIMV_RES_DECREASE) {
ctx->state = MFCINST_RES_CHANGE_INIT;
-   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
s5p_mfc_clock_off();
-   s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
return;
}
if (ctx->dpb_flush_flag)
@@ -446,7 +446,7 @@ leave_handle_frame:
if ((ctx->src_queue_cnt == 0 && ctx->state != MFCINST_FINISHING)
|| ctx->dst_queue_cnt < ctx->pb_count)
clear_work_bit(ctx);
-   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
s5p_mfc_clock_off();
@@ -454,7 +454,7 @@ leave_handle_frame:
if (test_bit(0, >enter_suspend))
wake_up_dev(dev, reason, err);
else
-   s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 }
 
 /* Error handling for interrupt */
@@ -490,7 +490,7 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
}
}
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
-   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
s5p_mfc_clock_off();
wake_up_dev(dev, reason, err);
return;
@@ -514,7 +514,7 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
ctx->img_height = s5p_mfc_hw_call(dev->mfc_ops, get_img_height,
dev);
 
-   s5p_mfc_hw_call_void(dev->mfc_ops, dec_calc_dpb_size, ctx);
+   s5p_mfc_hw_call(dev->mfc_ops, dec_calc_dpb_size, ctx);
 
ctx->pb_count = s5p_mfc_hw_call(dev->mfc_ops, get_dpb_count,
dev);
@@ -541,11 +541,11 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx 
*ctx,
ctx->head_processed = 1;
}
}
-   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
clear_work_bit(ctx);
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
s5p_mfc_clock_off();
-   s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
wake_up_ctx(ctx, reason, err);
 }
 
@@ -559,7 +559,7 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx 
*ctx,
if (ctx == NULL)
return;
dev = ctx->dev;
-   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
ctx->int_type = reason;
ctx->int_err = err;
ctx->int_cond = 1;
@@ -583,7 +583,7 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx 
*ctx,
s5p_mfc_clock_off();
 
wake_up(>queue);
-   s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
} else {
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
 
@@ -617,7 +617,7 @@ static void s5p_mfc_handle_stream_complete(struct 
s5p_mfc_ctx *ctx)
 
s5p_mfc_clock_off();
wake_up(>queue);
-   s5p_mfc_hw_call_void(dev->mfc_ops, try_run, dev);
+   s5p_mfc_hw_call(dev->mfc_ops, try_run, dev);
 }
 
 /* Interrupt processing */
@@ -658,15 +658,15 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
 
if (ctx->state == MFCINST_FINISHING &

[PATCH 6/6] s5p-mfc: remove volatile attribute from MFC register addresses

[Andrzej Hajda]

MFC register addresses are used only by writel/readl macros which already
takes care of proper register accessing.

Signed-off-by: Andrzej Hajda <a.ha...@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 33dae96..b6ac417 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 __iomem *risc_on;
+   void __iomem *risc2host_int;
+   void __iomem *host2risc_int;
+   void __iomem *risc_base_address;
+   void __iomem *mfc_reset;
+   void __iomem *host2risc_command;
+   void __iomem *risc2host_command;
+   void __iomem *mfc_bus_reset_ctrl;
+   void __iomem *firmware_version;
+   void __iomem *instance_id;
+   void __iomem *codec_type;
+   void __iomem *context_mem_addr;
+   void __iomem *context_mem_size;
+   void __iomem *pixel_format;
+   void __iomem *metadata_enable;
+   void __iomem *mfc_version;
+   void __iomem *dbg_info_enable;
+   void __iomem *dbg_buffer_addr;
+   void __iomem *dbg_buffer_size;
+   void __iomem *hed_control;
+   void __iomem *mfc_timeout_value;
+   void __iomem *hed_shared_mem_addr;
+   void __iomem *dis_shared_mem_addr;/* only v7 */
+   void __iomem *ret_instance_id;
+   void __iomem *error_code;
+   void __iomem *dbg_buffer_output_size;
+   void __iomem *metadata_status;
+   void __iomem *metadata_addr_mb_info;
+   void __iomem *metadata_size_mb_info;
+   void __iomem *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 */
-   volatil

[PATCH 2/6] s5p-mfc: make queue cleanup code common

[Andrzej Hajda]

Code for queue cleanup has nothing specific to hardware version.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 26 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|  6 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  6 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|  2 --
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 16 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 16 ---
 7 files changed, 23 insertions(+), 50 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8bae7df..79f5c81 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -125,6 +125,20 @@ static void wake_up_dev(struct s5p_mfc_dev *dev, unsigned 
int reason,
wake_up(>queue);
 }
 
+void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq)
+{
+   struct s5p_mfc_buf *b;
+   int i;
+
+   while (!list_empty(lh)) {
+   b = list_entry(lh->next, struct s5p_mfc_buf, list);
+   for (i = 0; i < b->b->vb2_buf.num_planes; i++)
+   vb2_set_plane_payload(>b->vb2_buf, i, 0);
+   vb2_buffer_done(>b->vb2_buf, VB2_BUF_STATE_ERROR);
+   list_del(>list);
+   }
+}
+
 static void s5p_mfc_watchdog(unsigned long arg)
 {
struct s5p_mfc_dev *dev = (struct s5p_mfc_dev *)arg;
@@ -170,10 +184,8 @@ static void s5p_mfc_watchdog_worker(struct work_struct 
*work)
if (!ctx)
continue;
ctx->state = MFCINST_ERROR;
-   s5p_mfc_hw_call_void(dev->mfc_ops, cleanup_queue,
-   >dst_queue, >vq_dst);
-   s5p_mfc_hw_call_void(dev->mfc_ops, cleanup_queue,
-   >src_queue, >vq_src);
+   s5p_mfc_cleanup_queue(>dst_queue, >vq_dst);
+   s5p_mfc_cleanup_queue(>src_queue, >vq_src);
clear_work_bit(ctx);
wake_up_ctx(ctx, S5P_MFC_R2H_CMD_ERR_RET, 0);
}
@@ -471,11 +483,9 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
ctx->state = MFCINST_ERROR;
/* Mark all dst buffers as having an error */
spin_lock_irqsave(>irqlock, flags);
-   s5p_mfc_hw_call_void(dev->mfc_ops, cleanup_queue,
-   >dst_queue, >vq_dst);
+   s5p_mfc_cleanup_queue(>dst_queue, >vq_dst);
/* Mark all src buffers as having an error */
-   s5p_mfc_hw_call_void(dev->mfc_ops, cleanup_queue,
-   >src_queue, >vq_src);
+   s5p_mfc_cleanup_queue(>src_queue, >vq_src);
spin_unlock_irqrestore(>irqlock, flags);
wake_up_ctx(ctx, reason, err);
break;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 0cdb37e..f560240 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -711,6 +711,7 @@ void set_work_bit(struct s5p_mfc_ctx *ctx);
 void clear_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
 void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
 int s5p_mfc_get_new_ctx(struct s5p_mfc_dev *dev);
+void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
 
 #define HAS_PORTNUM(dev)   (dev ? (dev->variant ? \
(dev->variant->port_num ? 1 : 0) : 0) : 0)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 1c4998c..cbb 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -1033,8 +1033,7 @@ static void s5p_mfc_stop_streaming(struct vb2_queue *q)
}
if (q->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
spin_lock_irqsave(>irqlock, flags);
-   s5p_mfc_hw_call_void(dev->mfc_ops, cleanup_queue,
-   >dst_queue, >vq_dst);
+   s5p_mfc_cleanup_queue(>dst_queue, >vq_dst);
INIT_LIST_HEAD(>dst_queue);
ctx->dst_queue_cnt = 0;
ctx->dpb_flush_flag = 1;
@@ -1051,8 +1050,7 @@ static void s5p_mfc_stop_streaming(struct vb2_queue *q)
}
if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
spin_lock_irqsave(>irqlock, flags);
-   s5p_mfc_hw_call_void(dev

[PATCH 4/6] s5p-mfc: use spinlock to protect MFC context

[Andrzej Hajda]

MFC driver uses dev->irqlock spinlock to protect queues only, but many context
fields requires protection also - they can be accessed concurrently
from IOCTLs and IRQ handler. The patch increases protection range of irqlock
to those fields also.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 15 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 13 +++--
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 14 --
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 19 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 18 --
 6 files changed, 11 insertions(+), 70 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 79f5c81..c4d9e34 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -359,7 +359,6 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
unsigned int dst_frame_status;
unsigned int dec_frame_status;
struct s5p_mfc_buf *src_buf;
-   unsigned long flags;
unsigned int res_change;
 
dst_frame_status = s5p_mfc_hw_call(dev->mfc_ops, get_dspl_status, dev)
@@ -385,7 +384,6 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
if (ctx->dpb_flush_flag)
ctx->dpb_flush_flag = 0;
 
-   spin_lock_irqsave(>irqlock, flags);
/* All frames remaining in the buffer have been extracted  */
if (dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_EMPTY) {
if (ctx->state == MFCINST_RES_CHANGE_FLUSH) {
@@ -445,7 +443,6 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
}
}
 leave_handle_frame:
-   spin_unlock_irqrestore(>irqlock, flags);
if ((ctx->src_queue_cnt == 0 && ctx->state != MFCINST_FINISHING)
|| ctx->dst_queue_cnt < ctx->pb_count)
clear_work_bit(ctx);
@@ -464,8 +461,6 @@ leave_handle_frame:
 static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
struct s5p_mfc_ctx *ctx, unsigned int reason, unsigned int err)
 {
-   unsigned long flags;
-
mfc_err("Interrupt Error: %08x\n", err);
 
if (ctx != NULL) {
@@ -482,11 +477,9 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
clear_work_bit(ctx);
ctx->state = MFCINST_ERROR;
/* Mark all dst buffers as having an error */
-   spin_lock_irqsave(>irqlock, flags);
s5p_mfc_cleanup_queue(>dst_queue, >vq_dst);
/* Mark all src buffers as having an error */
s5p_mfc_cleanup_queue(>src_queue, >vq_src);
-   spin_unlock_irqrestore(>irqlock, flags);
wake_up_ctx(ctx, reason, err);
break;
default:
@@ -562,7 +555,6 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx 
*ctx,
 {
struct s5p_mfc_buf *src_buf;
struct s5p_mfc_dev *dev;
-   unsigned long flags;
 
if (ctx == NULL)
return;
@@ -575,7 +567,6 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx 
*ctx,
if (err == 0) {
ctx->state = MFCINST_RUNNING;
if (!ctx->dpb_flush_flag && ctx->head_processed) {
-   spin_lock_irqsave(>irqlock, flags);
if (!list_empty(>src_queue)) {
src_buf = list_entry(ctx->src_queue.next,
 struct s5p_mfc_buf, list);
@@ -584,7 +575,6 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx 
*ctx,
vb2_buffer_done(_buf->b->vb2_buf,
VB2_BUF_STATE_DONE);
}
-   spin_unlock_irqrestore(>irqlock, flags);
} else {
ctx->dpb_flush_flag = 0;
}
@@ -612,7 +602,6 @@ static void s5p_mfc_handle_stream_complete(struct 
s5p_mfc_ctx *ctx)
 
ctx->state = MFCINST_FINISHED;
 
-   spin_lock(>irqlock);
if (!list_empty(>dst_queue)) {
mb_entry = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf,
list);
@@ -621,7 +610,6 @@ static void s5p_mfc_handle_stream_complete(struct 
s5p_mfc_ctx *ctx)
vb2_set_plane_payload(_entry->b->vb2_buf, 0, 0);
vb2_buffer_done(_entry->b->vb2_buf, VB2_BUF_STATE_DONE);
}
-   spin_unlock(>irqlock);
 
clear_work_bi

[PATCH 0/6] MFC locking rework and code cleanup

[Andrzej Hajda]

Hi Kamil,

This patchset contains one patch which should fix races during accessing 
context fields.
As the patch significantly changes locking I have tested it in different 
different scenarios.
Other patches just clean up the code.

The patchset is based on the latest media-tree branch.

Regards
Andrzej


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

 drivers/media/platform/s5p-mfc/s5p_mfc.c|  99 +++--
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  12 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |  16 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|  31 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  40 +-
 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 +-
 8 files changed, 351 insertions(+), 569 deletions(-)

-- 
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 04/19] v4l: omap3isp: fix handling platform_get_irq result

[Andrzej Hajda]

On 11/10/2015 09:53 AM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Tuesday 10 November 2015 07:48:54 Andrzej Hajda wrote:
>> On 11/09/2015 09:16 PM, Laurent Pinchart wrote:
>>> On Thursday 24 September 2015 16:00:12 Andrzej Hajda wrote:
>>>> The function can return negative value.
>>>>
>>>> The problem has been detected using proposed semantic patch
>>>> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>>>>
>>>> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>>>>
>>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>>> ---
>>>> Hi,
>>>>
>>>> To avoid problems with too many mail recipients I have sent whole
>>>> patchset only to LKML. Anyway patches have no dependencies.
>>>>
>>>>  drivers/media/platform/omap3isp/isp.c | 5 +++--
>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/media/platform/omap3isp/isp.c
>>>> b/drivers/media/platform/omap3isp/isp.c index 56e683b..df9d2c2 100644
>>>> --- a/drivers/media/platform/omap3isp/isp.c
>>>> +++ b/drivers/media/platform/omap3isp/isp.c
>>>> @@ -2442,12 +2442,13 @@ static int isp_probe(struct platform_device
>>>> *pdev)
>>>>}
>>>>
>>>>/* Interrupt */
>>>> -  isp->irq_num = platform_get_irq(pdev, 0);
>>>> -  if (isp->irq_num <= 0) {
>>>> +  ret = platform_get_irq(pdev, 0);
>>>> +  if (ret <= 0) {
>>> Looking at platform_get_irq() all error values are negative. You could
>>> just test for ret < 0 here, and remove the ret = -ENODEV assignment below
>>> to keep the error code returned by platform_get_irq().
>>>
>>> If you're fine with that modification there's no need to resubmit, just
>>> let me know and I'll fix it when applying it to my tree.
>> I left it as before, as it was not related to the patch. Additionally I have
>> lurked little bit inside platform_get_irq and it looks little bit scary to
>> me: platform_get_irq returns value of of_irq_get if ret >= 0,
>> of_irq_get calls of_irq_parse_one which can return 0,
>> in such case irq_create_of_mapping value is returned which is unsigned int
>> and evaluates to 0 in case of failures.
>> I am not sure if above scenario can ever occur, but the code looks so messy
>> to me, that I gave up :)
>>
>> Anyway if you are sure about your change I am OK with it also :)
> You're right, that's indeed an issue. It looks like a 0 irq is valid or 
> invalid depending on who you ask. NO_IRQ is defined differently depending on 
> the architecture :-/ I'll thus keep your version of the patch.
>
> Nonetheless, the core issue should be fixed. Do you feel adventurous ? :-)

Currently I am busy with other tasks, so I will be happy if somebody will
take care of it :), if not I will return to it if time permits.

Regards
Andrzej

>
>>>>dev_err(isp->dev, "No IRQ resource\n");
>>>>ret = -ENODEV;
>>>>goto error_iommu;
>>>>
>>>>}
>>>>
>>>> +  isp->irq_num = ret;
>>>>
>>>>if (devm_request_irq(isp->dev, isp->irq_num, isp_isr, IRQF_SHARED,
>>>>
>>>> "OMAP3 ISP", isp)) {

--
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 04/19] v4l: omap3isp: fix handling platform_get_irq result

[Andrzej Hajda]

On 11/09/2015 09:16 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Thursday 24 September 2015 16:00:12 Andrzej Hajda wrote:
>> The function can return negative value.
>>
>> The problem has been detected using proposed semantic patch
>> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> Hi,
>>
>> To avoid problems with too many mail recipients I have sent whole
>> patchset only to LKML. Anyway patches have no dependencies.
>>
>> Regards
>> Andrzej
>> ---
>>  drivers/media/platform/omap3isp/isp.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/omap3isp/isp.c
>> b/drivers/media/platform/omap3isp/isp.c index 56e683b..df9d2c2 100644
>> --- a/drivers/media/platform/omap3isp/isp.c
>> +++ b/drivers/media/platform/omap3isp/isp.c
>> @@ -2442,12 +2442,13 @@ static int isp_probe(struct platform_device *pdev)
>>  }
>>
>>  /* Interrupt */
>> -isp->irq_num = platform_get_irq(pdev, 0);
>> -if (isp->irq_num <= 0) {
>> +ret = platform_get_irq(pdev, 0);
>> +if (ret <= 0) {
> Looking at platform_get_irq() all error values are negative. You could just 
> test for ret < 0 here, and remove the ret = -ENODEV assignment below to keep 
> the error code returned by platform_get_irq().
>
> If you're fine with that modification there's no need to resubmit, just let 
> me 
> know and I'll fix it when applying it to my tree.

I left it as before, as it was not related to the patch. Additionally I have
lurked little bit inside platform_get_irq and it looks little bit scary to me:
platform_get_irq returns value of of_irq_get if ret >= 0,
of_irq_get calls of_irq_parse_one which can return 0,
in such case irq_create_of_mapping value is returned which is unsigned int
and evaluates to 0 in case of failures.
I am not sure if above scenario can ever occur, but the code looks so messy to 
me,
that I gave up :)

Anyway if you are sure about your change I am OK with it also :)

Regards
Andrzej

>
>>  dev_err(isp->dev, "No IRQ resource\n");
>>  ret = -ENODEV;
>>  goto error_iommu;
>>  }
>> +isp->irq_num = ret;
>>
>>  if (devm_request_irq(isp->dev, isp->irq_num, isp_isr, IRQF_SHARED,
>>   "OMAP3 ISP", isp)) {

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

[Andrzej Hajda]

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.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
Hi Kamil,

Commit message fixed.

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

[PATCH v3 1/2] s5p-mfc: end-of-stream handling for newer encoders

[Andrzej Hajda]

MFC encoder supports end-of-stream handling for encoder
in version 5 of hardware. This patch adds it also for newer version.
It was successfully tested on MFC-v8.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
Hi Kamil,

Incorrect format fixed.

Regards
Andrzej
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 25 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  5 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 49 +
 3 files changed, 48 insertions(+), 31 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 7b646c2..05a31ee 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -181,13 +181,6 @@ unlock:
mutex_unlock(>mfc_mutex);
 }
 
-static void s5p_mfc_clear_int_flags(struct s5p_mfc_dev *dev)
-{
-   mfc_write(dev, 0, S5P_FIMV_RISC_HOST_INT);
-   mfc_write(dev, 0, S5P_FIMV_RISC2HOST_CMD);
-   mfc_write(dev, 0x, S5P_FIMV_SI_RTN_CHID);
-}
-
 static void s5p_mfc_handle_frame_all_extracted(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_buf *dst_buf;
@@ -579,17 +572,13 @@ static void s5p_mfc_handle_init_buffers(struct 
s5p_mfc_ctx *ctx,
}
 }
 
-static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx,
-unsigned int reason, unsigned int err)
+static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_dev *dev = ctx->dev;
struct s5p_mfc_buf *mb_entry;
 
mfc_debug(2, "Stream completed\n");
 
-   s5p_mfc_clear_int_flags(dev);
-   ctx->int_type = reason;
-   ctx->int_err = err;
ctx->state = MFCINST_FINISHED;
 
spin_lock(>irqlock);
@@ -646,6 +635,13 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
if (ctx->c_ops->post_frame_start) {
if (ctx->c_ops->post_frame_start(ctx))
mfc_err("post_frame_start() failed\n");
+
+   if (ctx->state == MFCINST_FINISHING &&
+   list_empty(>ref_queue)) {
+   s5p_mfc_hw_call_void(dev->mfc_ops, 
clear_int_flags, dev);
+   s5p_mfc_handle_stream_complete(ctx);
+   break;
+   }
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, 
dev);
wake_up_ctx(ctx, reason, err);
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
@@ -691,7 +687,10 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
break;
 
case S5P_MFC_R2H_CMD_COMPLETE_SEQ_RET:
-   s5p_mfc_handle_stream_complete(ctx, reason, err);
+   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   ctx->int_type = reason;
+   ctx->int_err = err;
+   s5p_mfc_handle_stream_complete(ctx);
break;
 
case S5P_MFC_R2H_CMD_DPB_FLUSH_RET:
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 94868f7..d082d47 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -907,9 +907,9 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
list_add_tail(_entry->list, >ref_queue);
ctx->ref_queue_cnt++;
}
-   mfc_debug(2, "enc src count: %d, enc ref count: %d\n",
- ctx->src_queue_cnt, ctx->ref_queue_cnt);
}
+   mfc_debug(2, "enc src count: %d, enc ref count: %d\n",
+ ctx->src_queue_cnt, ctx->ref_queue_cnt);
if ((ctx->dst_queue_cnt > 0) && (strm_size > 0)) {
mb_entry = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf,
list);
@@ -932,6 +932,7 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
spin_unlock_irqrestore(>irqlock, flags);
if ((ctx->src_queue_cnt == 0) || (ctx->dst_queue_cnt == 0))
clear_work_bit(ctx);
+
return 0;
 }
 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index e0924a52..b958453 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -554,7 +554,7 @@ static void s5p_mfc_get_enc_frame_buffer_v6(struct 
s5p_mfc_ctx *ctx,
enc_recon_y_addr = readl(mfc_regs->e_recon_luma_dpb_addr);
enc_recon_c_addr = readl(mfc_regs->e_recon_chroma_dpb_addr);
 
-   mfc_debug(2, "recon y addr: 0x%08lx\n", en

[PATCH v2 2/2] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

[Andrzej Hajda]

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.

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

[PATCH v2 1/2] s5p-mfc: end-of-stream handling for newer encoders

[Andrzej Hajda]

MFC encoder supports end-of-stream handling for encoder
in version 5 of hardware. This patch adds it also for newer version.
It was successfully tested on MFC-v8.

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| 25 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  5 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 51 -
 3 files changed, 49 insertions(+), 32 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 7b646c2..05a31ee 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -181,13 +181,6 @@ unlock:
mutex_unlock(>mfc_mutex);
 }
 
-static void s5p_mfc_clear_int_flags(struct s5p_mfc_dev *dev)
-{
-   mfc_write(dev, 0, S5P_FIMV_RISC_HOST_INT);
-   mfc_write(dev, 0, S5P_FIMV_RISC2HOST_CMD);
-   mfc_write(dev, 0x, S5P_FIMV_SI_RTN_CHID);
-}
-
 static void s5p_mfc_handle_frame_all_extracted(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_buf *dst_buf;
@@ -579,17 +572,13 @@ static void s5p_mfc_handle_init_buffers(struct 
s5p_mfc_ctx *ctx,
}
 }
 
-static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx,
-unsigned int reason, unsigned int err)
+static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_dev *dev = ctx->dev;
struct s5p_mfc_buf *mb_entry;
 
mfc_debug(2, "Stream completed\n");
 
-   s5p_mfc_clear_int_flags(dev);
-   ctx->int_type = reason;
-   ctx->int_err = err;
ctx->state = MFCINST_FINISHED;
 
spin_lock(>irqlock);
@@ -646,6 +635,13 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
if (ctx->c_ops->post_frame_start) {
if (ctx->c_ops->post_frame_start(ctx))
mfc_err("post_frame_start() failed\n");
+
+   if (ctx->state == MFCINST_FINISHING &&
+   list_empty(>ref_queue)) {
+   s5p_mfc_hw_call_void(dev->mfc_ops, 
clear_int_flags, dev);
+   s5p_mfc_handle_stream_complete(ctx);
+   break;
+   }
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, 
dev);
wake_up_ctx(ctx, reason, err);
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
@@ -691,7 +687,10 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
break;
 
case S5P_MFC_R2H_CMD_COMPLETE_SEQ_RET:
-   s5p_mfc_handle_stream_complete(ctx, reason, err);
+   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   ctx->int_type = reason;
+   ctx->int_err = err;
+   s5p_mfc_handle_stream_complete(ctx);
break;
 
case S5P_MFC_R2H_CMD_DPB_FLUSH_RET:
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 94868f7..d082d47 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -907,9 +907,9 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
list_add_tail(_entry->list, >ref_queue);
ctx->ref_queue_cnt++;
}
-   mfc_debug(2, "enc src count: %d, enc ref count: %d\n",
- ctx->src_queue_cnt, ctx->ref_queue_cnt);
}
+   mfc_debug(2, "enc src count: %d, enc ref count: %d\n",
+ ctx->src_queue_cnt, ctx->ref_queue_cnt);
if ((ctx->dst_queue_cnt > 0) && (strm_size > 0)) {
mb_entry = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf,
list);
@@ -932,6 +932,7 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
spin_unlock_irqrestore(>irqlock, flags);
if ((ctx->src_queue_cnt == 0) || (ctx->dst_queue_cnt == 0))
clear_work_bit(ctx);
+
return 0;
 }
 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index e0924a52..69a6880 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -522,7 +522,7 @@ static int s5p_mfc_set_enc_stream_buffer_v6(struct 
s5p_mfc_ctx *ctx,
writel(addr, mfc_regs->e_stream_buffer_addr); /* 16B align */
writel(size, mfc_regs->e_stream_buffer_size);
 
-   mfc_debug(2, "stream buf addr: 

[PATCH 2/2] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

[Andrzej Hajda]

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.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 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 21c424e..f1e537e 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(dst_buf->b, 0, 0);
vb2_set_plane_payload(dst_buf->b, 1, 0);
list_del(_buf->list);
+   dst_buf->flags |= MFC_BUF_FLAG_EOS;
ctx->dst_queue_cnt--;
dst_buf->b->v4l2_buf.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 aebe4fd..7866eda 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

[PATCH 1/2] s5p-mfc: end-of-stream handling for newer encoders

[Andrzej Hajda]

MFC encoder supports end-of-stream handling for encoder
in version 5 of hardware. This patch adds it also for newer version.
It was successfully tested on MFC-v8.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 25 
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  5 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 40 ++---
 3 files changed, 44 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8de61dc..21c424e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -181,13 +181,6 @@ unlock:
mutex_unlock(>mfc_mutex);
 }
 
-static void s5p_mfc_clear_int_flags(struct s5p_mfc_dev *dev)
-{
-   mfc_write(dev, 0, S5P_FIMV_RISC_HOST_INT);
-   mfc_write(dev, 0, S5P_FIMV_RISC2HOST_CMD);
-   mfc_write(dev, 0x, S5P_FIMV_SI_RTN_CHID);
-}
-
 static void s5p_mfc_handle_frame_all_extracted(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_buf *dst_buf;
@@ -573,17 +566,13 @@ static void s5p_mfc_handle_init_buffers(struct 
s5p_mfc_ctx *ctx,
}
 }
 
-static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx,
-unsigned int reason, unsigned int err)
+static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_dev *dev = ctx->dev;
struct s5p_mfc_buf *mb_entry;
 
mfc_debug(2, "Stream completed\n");
 
-   s5p_mfc_clear_int_flags(dev);
-   ctx->int_type = reason;
-   ctx->int_err = err;
ctx->state = MFCINST_FINISHED;
 
spin_lock(>irqlock);
@@ -640,6 +629,13 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
if (ctx->c_ops->post_frame_start) {
if (ctx->c_ops->post_frame_start(ctx))
mfc_err("post_frame_start() failed\n");
+
+   if (ctx->state == MFCINST_FINISHING &&
+   list_empty(>ref_queue)) {
+   s5p_mfc_hw_call_void(dev->mfc_ops, 
clear_int_flags, dev);
+   s5p_mfc_handle_stream_complete(ctx);
+   break;
+   }
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, 
dev);
wake_up_ctx(ctx, reason, err);
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
@@ -685,7 +681,10 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
break;
 
case S5P_MFC_R2H_CMD_COMPLETE_SEQ_RET:
-   s5p_mfc_handle_stream_complete(ctx, reason, err);
+   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   ctx->int_type = reason;
+   ctx->int_err = err;
+   s5p_mfc_handle_stream_complete(ctx);
break;
 
case S5P_MFC_R2H_CMD_DPB_FLUSH_RET:
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 2e57e9f..5280592 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -902,9 +902,9 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
list_add_tail(_entry->list, >ref_queue);
ctx->ref_queue_cnt++;
}
-   mfc_debug(2, "enc src count: %d, enc ref count: %d\n",
- ctx->src_queue_cnt, ctx->ref_queue_cnt);
}
+   mfc_debug(2, "enc src count: %d, enc ref count: %d\n",
+ ctx->src_queue_cnt, ctx->ref_queue_cnt);
if ((ctx->dst_queue_cnt > 0) && (strm_size > 0)) {
mb_entry = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf,
list);
@@ -927,6 +927,7 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
spin_unlock_irqrestore(>irqlock, flags);
if ((ctx->src_queue_cnt == 0) || (ctx->dst_queue_cnt == 0))
clear_work_bit(ctx);
+
return 0;
 }
 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index e5cb30e..af4b936 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -554,7 +554,7 @@ static void s5p_mfc_get_enc_frame_buffer_v6(struct 
s5p_mfc_ctx *ctx,
enc_recon_y_addr = readl(mfc_regs->e_recon_luma_dpb_addr);
enc_recon_c_addr = readl(mfc_regs->e_recon_chroma_dpb_addr);
 
-   mfc_debug(2, "recon y addr: 0x%08lx\n", enc_recon_y_addr);
+   mfc_debug(2, &q

[PATCH 06/19] staging: media: omap4iss: fix handling platform_get_irq result

[Andrzej Hajda]

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
Hi,

To avoid problems with too many mail recipients I have sent whole
patchset only to LKML. Anyway patches have no dependencies.

Regards
Andrzej
---
 drivers/staging/media/omap4iss/iss.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss.c 
b/drivers/staging/media/omap4iss/iss.c
index 9bfb725..0b03cb7 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -1440,12 +1440,13 @@ static int iss_probe(struct platform_device *pdev)
 iss_reg_read(iss, OMAP4_ISS_MEM_ISP_SYS1, ISP5_REVISION));
 
/* Interrupt */
-   iss->irq_num = platform_get_irq(pdev, 0);
-   if (iss->irq_num <= 0) {
+   ret = platform_get_irq(pdev, 0);
+   if (ret <= 0) {
dev_err(iss->dev, "No IRQ resource\n");
ret = -ENODEV;
goto error_iss;
}
+   iss->irq_num = ret;
 
if (devm_request_irq(iss->dev, iss->irq_num, iss_isr, IRQF_SHARED,
 "OMAP4 ISS", iss)) {
-- 
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

[PATCH 04/19] v4l: omap3isp: fix handling platform_get_irq result

[Andrzej Hajda]

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
Hi,

To avoid problems with too many mail recipients I have sent whole
patchset only to LKML. Anyway patches have no dependencies.

Regards
Andrzej
---
 drivers/media/platform/omap3isp/isp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 56e683b..df9d2c2 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2442,12 +2442,13 @@ static int isp_probe(struct platform_device *pdev)
}
 
/* Interrupt */
-   isp->irq_num = platform_get_irq(pdev, 0);
-   if (isp->irq_num <= 0) {
+   ret = platform_get_irq(pdev, 0);
+   if (ret <= 0) {
dev_err(isp->dev, "No IRQ resource\n");
ret = -ENODEV;
goto error_iommu;
}
+   isp->irq_num = ret;
 
if (devm_request_irq(isp->dev, isp->irq_num, isp_isr, IRQF_SHARED,
 "OMAP3 ISP", isp)) {
-- 
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

[PATCH 10/19] cx231xx: fix handling cx231xx_read_i2c_data result

[Andrzej Hajda]

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
Hi,

To avoid problems with too many mail recipients I have sent whole
patchset only to LKML. Anyway patches have no dependencies.

Regards
Andrzej
---
 drivers/media/usb/cx231xx/cx231xx-video.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c 
b/drivers/media/usb/cx231xx/cx231xx-video.c
index 9798160..d0d8f08 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -1114,7 +1114,8 @@ int cx231xx_enum_input(struct file *file, void *priv,
struct cx231xx_fh *fh = priv;
struct cx231xx *dev = fh->dev;
u32 gen_stat;
-   unsigned int ret, n;
+   unsigned int n;
+   int ret;
 
n = i->index;
if (n >= MAX_CX231XX_INPUT)
-- 
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

[PATCH 05/19] media: am437x-vpfe: fix handling platform_get_irq result

[Andrzej Hajda]

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
Hi,

To avoid problems with too many mail recipients I have sent whole
patchset only to LKML. Anyway patches have no dependencies.

Regards
Andrzej
---
 drivers/media/platform/am437x/am437x-vpfe.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/am437x/am437x-vpfe.c 
b/drivers/media/platform/am437x/am437x-vpfe.c
index c8447fa..c9cbb60 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -2546,11 +2546,12 @@ static int vpfe_probe(struct platform_device *pdev)
if (IS_ERR(ccdc->ccdc_cfg.base_addr))
return PTR_ERR(ccdc->ccdc_cfg.base_addr);
 
-   vpfe->irq = platform_get_irq(pdev, 0);
-   if (vpfe->irq <= 0) {
+   ret = platform_get_irq(pdev, 0);
+   if (ret <= 0) {
dev_err(>dev, "No IRQ resource\n");
return -ENODEV;
}
+   vpfe->irq = ret;
 
ret = devm_request_irq(vpfe->pdev, vpfe->irq, vpfe_isr, 0,
   "vpfe_capture0", vpfe);
-- 
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 00/38] Fixes related to incorrect usage of unsigned types

[Andrzej Hajda]

On 09/21/2015 03:42 PM, David Howells wrote:
> Andrzej Hajda <a.hajda-sze3o3uu22jbdgjk7y7...@public.gmane.org> wrote:
> 
>> Semantic patch finds comparisons of types:
>> unsigned < 0
>> unsigned >= 0
>> The former is always false, the latter is always true.
>> Such comparisons are useless, so theoretically they could be
>> safely removed, but their presence quite often indicates bugs.
> 
> Or someone has left them in because they don't matter and there's the
> possibility that the type being tested might be or become signed under some
> circumstances.  If the comparison is useless, I'd expect the compiler to just
> discard it - for such cases your patch is pointless.
> 
> If I have, for example:
> 
>   unsigned x;
> 
>   if (x == 0 || x > 27)
>   give_a_range_error();
> 
> I will write this as:
> 
>   unsigned x;
> 
>   if (x <= 0 || x > 27)
>   give_a_range_error();
> 
> because it that gives a way to handle x being changed to signed at some point
> in the future for no cost.  In which case, your changing the <= to an ==
> "because the < part of the case is useless" is arguably wrong.

This is why I have not checked for such cases - I have skipped checks of type
unsigned <= 0
exactly for the reasons above.

However I have left two other checks as they seems to me more suspicious - they
are always true or false. But as Dmitry and Andrew pointed out Linus have quite
strong opinion against removing range checks in such cases as he finds it
clearer. I think it applies to patches 29-36. I am not sure about patches 
26-28,37.

Regards
Andrzej

> 
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo-u79uwxl29ty76z2rm5m...@public.gmane.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

[PATCH 25/38] staging: media: davinci_vpfe: fix ipipe_mode type

[Andrzej Hajda]

The variable can take negative values.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
index 2a3a56b..b1d5e23 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
@@ -254,7 +254,7 @@ int config_ipipe_hw(struct vpfe_ipipe_device *ipipe)
void __iomem *ipipe_base = ipipe->base_addr;
struct v4l2_mbus_framefmt *outformat;
u32 color_pat;
-   u32 ipipe_mode;
+   int ipipe_mode;
u32 data_path;
 
/* enable clock to IPIPE */
-- 
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 08/18] [media] s5c73m3: Export OF module alias information

[Andrzej Hajda]

On 09/11/2015 03:19 AM, Javier Martinez Canillas wrote:
> Hello,
>
> On 08/20/2015 09:07 AM, Javier Martinez Canillas wrote:
>> The SPI core always reports the MODALIAS uevent as "spi:"
>> regardless of the mechanism that was used to register the device
>> (i.e: OF or board code) and the table that is used later to match
>> the driver with the device (i.e: SPI id table or OF match table).
>>
>> So drivers needs to export the SPI id table and this be built into
>> the module or udev won't have the necessary information to autoload
>> the needed driver module when the device is added.
>>
>> But this means that OF-only drivers needs to have both OF and SPI id
>> tables that have to be kept in sync and also the dev node compatible
>> manufacturer prefix is stripped when reporting the MODALIAS. Which can
>> lead to issues if two vendors use the same SPI device name for example.
>>
>> To avoid the above, the SPI core behavior may be changed in the future
>> to not require an SPI device table for OF-only drivers and report the
>> OF module alias. So, it's better to also export the OF table even when
>> is unused now to prevent breaking module loading when the core changes.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>
>>  drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c 
>> b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
>> index fa4a5ebda6b2..9983635ec253 100644
>> --- a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
>> +++ b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
>> @@ -31,6 +31,7 @@ static const struct of_device_id s5c73m3_spi_ids[] = {
>>  { .compatible = "samsung,s5c73m3" },
>>  { }
>>  };
>> +MODULE_DEVICE_TABLE(of, s5c73m3_spi_ids;);

Unnecessary semicolon inside parenthesis, I guess it wont compile :)

Regards
Andrzej

>>  
>>  enum spi_direction {
>>  SPI_DIR_RX,
>>
> Any comments about this patch?
>
> Best regards,

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/18] [media] s5c73m3: Export OF module alias information

[Andrzej Hajda]

On 09/11/2015 03:19 AM, Javier Martinez Canillas wrote:
> Hello,
>
> On 08/20/2015 09:07 AM, Javier Martinez Canillas wrote:
>> The SPI core always reports the MODALIAS uevent as "spi:"
>> regardless of the mechanism that was used to register the device
>> (i.e: OF or board code) and the table that is used later to match
>> the driver with the device (i.e: SPI id table or OF match table).
>>
>> So drivers needs to export the SPI id table and this be built into
>> the module or udev won't have the necessary information to autoload
>> the needed driver module when the device is added.
>>
>> But this means that OF-only drivers needs to have both OF and SPI id
>> tables that have to be kept in sync and also the dev node compatible
>> manufacturer prefix is stripped when reporting the MODALIAS. Which can
>> lead to issues if two vendors use the same SPI device name for example.
>>
>> To avoid the above, the SPI core behavior may be changed in the future
>> to not require an SPI device table for OF-only drivers and report the
>> OF module alias. So, it's better to also export the OF table even when
>> is unused now to prevent breaking module loading when the core changes.
>>
>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>> ---
>>
>>  drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c 
>> b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
>> index fa4a5ebda6b2..9983635ec253 100644
>> --- a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
>> +++ b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
>> @@ -31,6 +31,7 @@ static const struct of_device_id s5c73m3_spi_ids[] = {
>>  { .compatible = "samsung,s5c73m3" },
>>  { }
>>  };
>> +MODULE_DEVICE_TABLE(of, s5c73m3_spi_ids;);
>>  
>>  enum spi_direction {
>>  SPI_DIR_RX,
>>
> Any comments about this patch?
>
> Best regards,
Ups, forgot about it.

Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

Regards
Andrzej

--
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] v4l2-compat-ioctl32: fix alignment for ARM64

[Andrzej Hajda]

Alignment/padding rules on AMD64 and ARM64 differs. To allow properly match
compatible ioctls on ARM64 kernels without breaking AMD64 some fields
should be aligned using compat_s64 type and in one case struct should be
unpacked.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
Hi Hans,

I have tested following structures:
struct v4l2_format32
struct v4l2_buffer32
struct v4l2_framebuffer32
struct v4l2_standard32
struct v4l2_input32
struct v4l2_edid32
struct v4l2_ext_controls32
struct v4l2_ext_control32
struct v4l2_event32
struct v4l2_create_buffers32

Following structures should be fixed:
v4l2_standard32 - .id alignment
v4l2_input32 - whole struct padding
v4l2_event32 - .data alignment

I hope this patch does it correctly.

Regards
Andrzej
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index af63543..d309d270 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -266,7 +266,7 @@ static int put_v4l2_create32(struct v4l2_create_buffers 
*kp, struct v4l2_create_
 
 struct v4l2_standard32 {
__u32index;
-   __u32id[2]; /* __u64 would get the alignment wrong */
+   compat_u64   id;
__u8 name[24];
struct v4l2_fractframeperiod; /* Frames, not fields */
__u32framelines;
@@ -286,7 +286,7 @@ static int put_v4l2_standard32(struct v4l2_standard *kp, 
struct v4l2_standard32
 {
if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_standard32)) ||
put_user(kp->index, >index) ||
-   copy_to_user(up->id, >id, sizeof(__u64)) ||
+   put_user(kp->id, >id) ||
copy_to_user(up->name, kp->name, 24) ||
copy_to_user(>frameperiod, >frameperiod, 
sizeof(kp->frameperiod)) ||
put_user(kp->framelines, >framelines) ||
@@ -587,10 +587,10 @@ struct v4l2_input32 {
__u32type;  /*  Type of input */
__u32audioset;  /*  Associated audios (bitfield) */
__u32tuner; /*  Associated tuner */
-   v4l2_std_id  std;
+   compat_s64   std;
__u32status;
__u32reserved[4];
-} __attribute__ ((packed));
+};
 
 /* The 64-bit v4l2_input struct has extra padding at the end of the struct.
Otherwise it is identical to the 32-bit version. */
@@ -738,6 +738,7 @@ static int put_v4l2_ext_controls32(struct v4l2_ext_controls 
*kp, struct v4l2_ext
 struct v4l2_event32 {
__u32   type;
union {
+   compat_s64  value64;
__u8data[64];
} u;
__u32   pending;
-- 
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

[PATCH] v4l2-compat-ioctl32: fix struct v4l2_event32 alignment

[Andrzej Hajda]

Union v4l2_event::u is aligned to 8 bytes on arm32. On arm64 v4l2_event32::u
is aligned to 4 bytes. As a result structures v4l2_event and v4l2_event32 have
different sizes and VIDOC_DQEVENT ioctl does not work from arm32 apps running
on arm64 kernel. The patch fixes it. Using compat_s64 allows to retain 4 bytes
alignment on x86 architecture.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
Hi Hans,

Tested successfully on arm32 app / arm64 kernel.
Thanks for help.

Regards
Andrzej
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index af63543..52afffe 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -738,6 +738,7 @@ static int put_v4l2_ext_controls32(struct v4l2_ext_controls 
*kp, struct v4l2_ext
 struct v4l2_event32 {
__u32   type;
union {
+   compat_s64  value64;
__u8data[64];
} u;
__u32   pending;
-- 
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

[RFC PATCH] v4l2-compat-ioctl32: fix struct v4l2_event32 alignment

[Andrzej Hajda]

Union v4l2_event::u is aligned to 8 bytes on arm32. On arm64 v4l2_event32::u
is aligned to 4 bytes. As a result structures v4l2_event and v4l2_event32 have
different sizes and VIDOC_DQEVENT ioctl does not work from arm32 apps running
on arm64 kernel. The patch fixes it.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
Hi Hans,

It seems there is problem with VIDIOC_DQEVENT called from arm32 apps on arm64
kernel. After tracking down the issue it seems v4l2_event32 on arm64 have
different field alignment/size than v4l2_event on arm32. The patch fixes it.
But i guess it can break ABI on other architectures. Simple tests shows:

i386:
sizeof(struct v4l2_event)=0x78
offsetof(struct v4l2_event::u)=0x4

amd64:
sizeof(struct v4l2_event)=0x88
offsetof(struct v4l2_event::u)=0x8

arm:
sizeof(struct v4l2_event)=0x80
offsetof(struct v4l2_event::u)=0x8

arm64:
sizeof(struct v4l2_event)=0x88
offsetof(struct v4l2_event::u)=0x8

Any advices how to fix it in arch compatible way?

Regards
Andrzej
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index af63543..a4a1856 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -739,7 +739,7 @@ struct v4l2_event32 {
__u32   type;
union {
__u8data[64];
-   } u;
+   } u __attribute__((aligned(8)));
__u32   pending;
__u32   sequence;
struct compat_timespec  timestamp;
-- 
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

[Andrzej Hajda]

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

Regards
Andrzej


 ---
  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 6/6] [media] s5c73m3: Remove redundant spi driver bus initialization

[Andrzej Hajda]

On 06/23/2015 04:53 PM, Antonio Borneo wrote:
 In ancient times it was necessary to manually initialize the bus
 field of an spi_driver to spi_bus_type. These days this is done in
 spi_register_driver(), so we can drop the manual assignment.

 Signed-off-by: Antonio Borneo borneo.anto...@gmail.com
 To: Mauro Carvalho Chehab mche...@osg.samsung.com
 To: Kyungmin Park kyungmin.p...@samsung.com
 To: Andrzej Hajda a.ha...@samsung.com
 To: linux-media@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org

Reviewed-by: Andrzej Hajda a.ha...@samsung.com

Regards
Andrzej
 ---
  drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 1 -
  1 file changed, 1 deletion(-)

 diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c 
 b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
 index 63eb190..fa4a5eb 100644
 --- a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
 +++ b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
 @@ -149,7 +149,6 @@ int s5c73m3_register_spi_driver(struct s5c73m3 *state)
   spidrv-remove = s5c73m3_spi_remove;
   spidrv-probe = s5c73m3_spi_probe;
   spidrv-driver.name = S5C73M3_SPI_DRV_NAME;
 - spidrv-driver.bus = spi_bus_type;
   spidrv-driver.owner = THIS_MODULE;
   spidrv-driver.of_match_table = s5c73m3_spi_ids;
  

--
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] s5k5baf: Convert use of __constant_cpu_to_be16 to cpu_to_be16

[Andrzej Hajda]

On 06/06/2015 03:53 AM, Vaishali Thakkar wrote:
 In little endian cases, macro cpu_to_be16 unfolds to __swab16 which
 provides special case for constants. In big endian cases,
 __constant_cpu_to_be16 and cpu_to_be16 expand directly to the
 same expression. So, replace __constant_cpu_to_be16 with
 cpu_to_be16 with the goal of getting rid of the definition of
 __constant_cpu_to_be16 completely.

 The semantic patch that performs this transformation is as follows:

 @@expression x;@@

 - __constant_cpu_to_be16(x)
 + cpu_to_be16(x)

 Signed-off-by: Vaishali Thakkar vthakkar1...@gmail.com
Reviewed-by: Andrzej Hajda a.ha...@samsung.com

 ---
  drivers/media/i2c/s5k5baf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
 index 297ef04..7a43b55 100644
 --- a/drivers/media/i2c/s5k5baf.c
 +++ b/drivers/media/i2c/s5k5baf.c
 @@ -491,7 +491,7 @@ static void s5k5baf_write_arr_seq(struct s5k5baf *state, 
 u16 addr,
   v4l2_dbg(3, debug, c, i2c_write_seq(count=%d): %*ph\n, count,
min(2 * count, 64), seq);
  
 - buf[0] = __constant_cpu_to_be16(REG_CMD_BUF);
 + buf[0] = cpu_to_be16(REG_CMD_BUF);
  
   while (count  0) {
   int n = min_t(int, count, ARRAY_SIZE(buf) - 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 13/18] s5k5baf: fix subdev type

[Andrzej Hajda]

Hi Mauro,

On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
 This sensor driver is abusing MEDIA_ENT_T_V4L2_SUBDEV, creating
 some subdevs with a non-existing type.

 As this is a sensor driver, the proper type is likely
 MEDIA_ENT_T_CAM_SENSOR.

This driver exposes two media entities:
- pure camera sensor, it has type
MEDIA_ENT_T_V4L2_SUBDEV_SENSOR/MEDIA_ENT_T_CAM_SENSOR,
- image processing entity, I have assigned to it MEDIA_ENT_T_V4L2_SUBDEV
type,
as there were no better option.
Maybe it would be better to introduce another define for such entities,
for example MEDIA_ENT_T_CAM_ISP?
The same applies to s5c73m3 driver.

Anyway this patch breaks current code as type field is used internally
to distinguish both entities in subdev callbacks  -
s5k5baf_is_cis_subdev function.
Of course the function can be rewritten if necessary.

Regards
Andrzej


 Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

 diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
 index fadd48d35a55..8373552847ab 100644
 --- a/drivers/media/i2c/s5k5baf.c
 +++ b/drivers/media/i2c/s5k5baf.c
 @@ -1919,7 +1919,7 @@ static int s5k5baf_configure_subdevs(struct s5k5baf 
 *state,
  
   state-pads[PAD_CIS].flags = MEDIA_PAD_FL_SINK;
   state-pads[PAD_OUT].flags = MEDIA_PAD_FL_SOURCE;
 - sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV;
 + sd-entity.type = MEDIA_ENT_T_CAM_SENSOR;
   ret = media_entity_init(sd-entity, NUM_ISP_PADS, state-pads, 0);
  
   if (!ret)

--
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] s5k5baf: Add missing error check for devm_kzalloc

[Andrzej Hajda]

Hi Kiran,

Thanks for spotting it.

On 02/05/2015 11:09 AM, Kiran Padwal wrote:
 This patch add a missing a check on the return value of devm_kzalloc,
 which would cause a NULL pointer dereference in a OOM situation.

 Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
 ---
  drivers/media/i2c/s5k5baf.c |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
 index 60a74d8..156b975 100644
 --- a/drivers/media/i2c/s5k5baf.c
 +++ b/drivers/media/i2c/s5k5baf.c
 @@ -374,6 +374,8 @@ static int s5k5baf_fw_parse(struct device *dev, struct 
 s5k5baf_fw **fw,
   count -= S5K5BAG_FW_TAG_LEN;
  
   d = devm_kzalloc(dev, count * sizeof(u16), GFP_KERNEL);
 + if (!d)
 + return -ENOMEM;
  
   for (i = 0; i  count; ++i)
   d[i] = le16_to_cpu(data[i]);
Acked-by: Andrzej Hajda a.ha...@samsung.com

Regards
Andrzej
--
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 v6 3/3] of: Add of_graph_get_port_by_id function

[Andrzej Hajda]

Hi Philipp,

On 12/22/2014 04:11 PM, Philipp Zabel wrote:
 This patch adds a function to get a port device tree node by port id,
 or reg property value.
 
 Signed-off-by: Philipp Zabel p.za...@pengutronix.de
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/of/base.c| 26 ++
  include/linux/of_graph.h |  7 +++
  2 files changed, 33 insertions(+)
 
 diff --git a/drivers/of/base.c b/drivers/of/base.c
 index aac66df..c816299 100644
 --- a/drivers/of/base.c
 +++ b/drivers/of/base.c
 @@ -2080,6 +2080,32 @@ int of_graph_parse_endpoint(const struct device_node 
 *node,
  EXPORT_SYMBOL(of_graph_parse_endpoint);
  
  /**
 + * of_graph_get_port_by_id() - get the port matching a given id
 + * @parent: pointer to the parent device node

Here you have 'parent' and 'node' in the code.

 + * @id: id of the port
 + *
 + * Return: A 'port' node pointer with refcount incremented. The caller
 + * has to use of_node_put() on it when done.
 + */
 +struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id)
 +{
 + struct device_node *port;
 +
 + for_each_child_of_node(node, port) {
 + u32 port_id = 0;
 +
 + if (of_node_cmp(port-name, port) != 0)
 + continue;
 + of_property_read_u32(port, reg, port_id);
 + if (id == port_id)
 + return port;
 + }
 +
 + return NULL;
 +}


Maybe I miss something but it does not handle optional 'ports' node.

Regards
Andrzej


 +EXPORT_SYMBOL(of_graph_get_port_by_id);
 +
 +/**
   * of_graph_get_next_endpoint() - get next endpoint node
   * @parent: pointer to the parent device node
   * @prev: previous endpoint node, or NULL to get first
 diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
 index e43442e..3c1c95a 100644
 --- a/include/linux/of_graph.h
 +++ b/include/linux/of_graph.h
 @@ -40,6 +40,7 @@ struct of_endpoint {
  #ifdef CONFIG_OF
  int of_graph_parse_endpoint(const struct device_node *node,
   struct of_endpoint *endpoint);
 +struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 
 id);
  struct device_node *of_graph_get_next_endpoint(const struct device_node 
 *parent,
   struct device_node *previous);
  struct device_node *of_graph_get_remote_port_parent(
 @@ -53,6 +54,12 @@ static inline int of_graph_parse_endpoint(const struct 
 device_node *node,
   return -ENOSYS;
  }
  
 +static inline struct device_node *of_graph_get_port_by_id(
 + struct device_node *node, u32 id)
 +{
 + return NULL;
 +}
 +
  static inline struct device_node *of_graph_get_next_endpoint(
   const struct device_node *parent,
   struct device_node *previous)
 

--
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] gpio: gpiolib: set gpiochip_remove retval to void

[Andrzej Hajda]

On 06/09/2014 01:29 PM, Lars-Peter Clausen wrote:
 On 06/09/2014 01:18 AM, Ben Dooks wrote:
 On Fri, May 30, 2014 at 08:16:59PM +0200, Lars-Peter Clausen wrote:
 On 05/30/2014 07:33 PM, David Daney wrote:
 On 05/30/2014 04:39 AM, Geert Uytterhoeven wrote:
 On Fri, May 30, 2014 at 1:30 PM, abdoulaye berthe berthe...@gmail.com
 wrote:
 --- a/drivers/gpio/gpiolib.c
 +++ b/drivers/gpio/gpiolib.c
 @@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct
 gpio_chip *gpiochip);
*
* A gpio_chip with any GPIOs still requested may not be removed.
*/
 -int gpiochip_remove(struct gpio_chip *chip)
 +void gpiochip_remove(struct gpio_chip *chip)
   {
  unsigned long   flags;
 -   int status = 0;
  unsignedid;

  acpi_gpiochip_remove(chip);
 @@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
  of_gpiochip_remove(chip);

  for (id = 0; id  chip-ngpio; id++) {
 -   if (test_bit(FLAG_REQUESTED, chip-desc[id].flags)) {
 -   status = -EBUSY;
 -   break;
 -   }
 -   }
 -   if (status == 0) {
 -   for (id = 0; id  chip-ngpio; id++)
 -   chip-desc[id].chip = NULL;
 -
 -   list_del(chip-list);
 +   if (test_bit(FLAG_REQUESTED, chip-desc[id].flags))
 +   panic(gpio: removing gpiochip with gpios still
 requested\n);

 panic?

 NACK to the patch for this reason.  The strongest thing you should do here
 is WARN.

 That said, I am not sure why we need this whole patch set in the first 
 place.

 Well, what currently happens when you remove a device that is a
 provider of a gpio_chip which is still in use, is that the kernel
 crashes. Probably with a rather cryptic error message. So this patch
 doesn't really change the behavior, but makes it more explicit what
 is actually wrong. And even if you replace the panic() by a WARN()
 it will again just crash slightly later.

 This is a design flaw in the GPIO subsystem that needs to be fixed.

 Surely then the best way is to error out to the module unload and
 stop the driver being unloaded?

 
 You can't error out on module unload, although that's not really relevant 
 here. gpiochip_remove() is typically called when the device that registered 
 the GPIO chip is unbound. And despite some remove() callbacks having a 
 return type of int you can not abort the removal of a device.

It is a design flaw in many subsystems having providers and consumers,
not only GPIO. The same situation is with clock providers, regulators,
phys, drm_panels, ..., at least it was such last time I have tested it.

The problem is that many frameworks assumes that lifetime of provider is
always bigger than lifetime of its consumers, and this is wrong
assumption - usually it is not possible to prevent unbinding driver from
device, so if the device is a provider there is no way to inform
consumers about his removal.

Some solution for such problems is to use some kind of availability
callbacks for requesting resources (gpios, clocks, regulators,...)
instead of simple 'getters' (clk_get, gpiod_get). Callbacks should
guarantee that the resource is always valid between callback reporting
its availability and callback reporting its removal. Such approach seems
to be complicated at the first sight but it should allow to make the
code safe and as a bonus it will allow to avoid deferred probing.
Btw I have send already RFC for such framework [1].

[1]: https://lkml.org/lkml/2014/4/30/345

Regards
Andrzej


 
 - Lars
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Andrzej Hajda]

On 05/01/2014 11:11 AM, Russell King - ARM Linux wrote:
 On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote:
 2. You replace calls of component_add and component_del with calls
 to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT,  
 specific_component_ops),
 or interface_tracker_ifdown.
 Thats all for components.
 How does the master get to decide which components are for it?

This is not a part of the framework. The master can construct
the list of its components anyhow. Some examples:
1. List of device tree video interface port nodes pointed by
master's remote-endpoint phandles.
2. List of device nodes pointed by supernode phandles.
3. Nodes pointed by other phandles in master's node.
4. Devices compatible with the list of drivers.

This is for create list of objects. As interface type it should
use the types of interface it expects at given nodes and is able to handle.

Small issue:
If the master creates list of devices and for particular interface
type expects DT node as the object, translation is easy: dev-of_node.
But if the situation is reverse kernel does not provide generic helper
for translating of_node to device, however kernel have everything to
provide such function if necessary.
Other solution is to use only DT nodes for object identification,
it will narrow the framework usage to DT architectures, but seems to be
more flexible anyway - we can have more than one interface of given type per
device, we can distinguish them by port node.

   As
 I see it, all masters see all components of a particular type.
 What if you have a system with two masters each of which are bound
 to a set of unique components but some of the components are of a
 the same type?

The master receives notifications only about interfaces he has
registered callback for. For example:
interface_tracker_register(node, INTERFACE_TRACKER_TYPE_DRM_PANEL, cb);

means that 'cb' callback will be called only if panel identifed by node
is up or down.
If the driver expect that at the 'node' there could be also component it
can also
listen for components:
interface_tracker_register(node, INTERFACE_TRACKER_TYPE_COMPONENT, cb);

Now 'cb' will be called if component or panel appears/disappears at node
'node'.

so callback function can look like:

void cb_func(struct interface_tracker_block *itb, const void *object,
unsigned long type, bool on,
  void *data)
{
struct priv_struct *priv = container_of(itb, struct priv_struct, itb);
switch(type) {
case INTERFACE_TRACKER_TYPE_DRM_PANEL:
handle_drm_panel(priv, data, on);
break;
case INTERFACE_TRACKER_TYPE_DRM_COMPONENT:
handle_drm_component(priv, data, object, on);
break;
}
}

where handlers can look like:

void handle_drm_panel(struct priv_struct *priv, struct drm_panel *panel,
bool on);
void handle_drm_component(struct priv_struct *priv, struct component_ops
*ops, struct device *dev, bool on);


 How does the master know what type to use?


It should use type which it expects at the given node.

Regards
Andrzej

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Andrzej Hajda]

Russell King - ARM Linux wrote, On 01.05.2014 00:28:

On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:

The main problem with component framework is that componentization
significantly changes every driver and changes it in a way which is not
compatible with traditional drivers, so devices which are intended to
work with different DRM masters are hard to componentize if some of DRMs
are componentized and some not.

Many of the problems which the component helpers are designed to solve
are those where you need the drm_device structure (or snd_card, or whatever
subsystem specific card/device representation structure) pre-created in
order to initialise the components.

In the case of DRM, you can't initialise encoders or connectors without
their drm_device structure pre-existing - because these components are
attached to the drm_device.

Your solution to that is to delay those calls, but the DRM subsystem is
not designed to cope like that - it's designed such that when the
connector or encoder initialisation functions are called, it is assumed
that the driver is initialising its state. (I've raised this point before
but you've just fobbed it off in the past.)

Another issue here is that the order of initialisation matters greatly.
Take CRTCs for example.  In DRM, the order of attachment of CRTCs defines
their identity, changing the order changes their identity, and changes
how they are bound to their respective connectors.


The two problems you show here are not a real problems in this framework:
1. making real device initialization during drm initialization - 
decision is left

to driver developer what should be done in probe, what should be done in
'bind', I guess this is also true for components, at least the framework 
allows it.
2. initialization order - if you put initialization into components 
'bind' function,

master can choose any order of calls to 'bind'.

Anyway you can implement the same behaviour as components with
interface_tracker. Just simple proof of concept, how to convert 
componentized

drivers to interface_tracker:
Components:
1. you can reuse component_ops
2. You replace calls of component_add and component_del with calls
to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT, 
specific_component_ops),

or interface_tracker_ifdown.
Thats all for components.

Master:
1. you register callback for tracking all components.
2. in the callback you check if all components are up, if yes you do the
same as in component framework initialization, to simplify it
helper function can be added.

I guess it should work the same way, if there is interest in it I can 
develop the

helper next week, I hope.

What is the benefit of interface_tracker:
1. interface_tracker is more generic - it can track not only components.
2. you put component initialization code into helper function - sounds 
like mid-layer removal,

developer can choose different helper if it suits better.

So from component point of view interface_tracker can be treated as kind 
of extensions

of the component framework.

I hope I have answerer all your concerns.

I have holidays till Sunday and I am not sure if I will be able to 
answer next emails before

Monday.

Regards
Andrzej
--
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 PATCH 1/4] drivers/base: add interface tracker framework

[Andrzej Hajda]

interface_tracker is a generic framework which allows to track appearance
and disappearance of different interfaces provided by kernel/driver code inside
the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel...
Interface is specified by a pair of object pointer and interface type. Object
type depends on interface type, for example interface type drm_panel determines
that object is a device_node. Object pointer is used to distinguish different
interfaces of the same type and should identify object the interface is bound 
to.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
 drivers/base/Makefile |   2 +-
 drivers/base/interface_tracker.c  | 307 ++
 include/linux/interface_tracker.h |  27 
 3 files changed, 335 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/interface_tracker.c
 create mode 100644 include/linux/interface_tracker.h

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e..5a45c41 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,7 @@ obj-y   := component.o core.o bus.o dd.o 
syscore.o \
   driver.o class.o platform.o \
   cpu.o firmware.o init.o map.o devres.o \
   attribute_container.o transport_class.o \
-  topology.o container.o
+  topology.o container.o interface_tracker.o
 obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
diff --git a/drivers/base/interface_tracker.c b/drivers/base/interface_tracker.c
new file mode 100644
index 000..3d36cba
--- /dev/null
+++ b/drivers/base/interface_tracker.c
@@ -0,0 +1,307 @@
+/*
+ * Generic framework for tracking kernel interfaces
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Andrzej Hajda a.ha...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * interface_tracker is a generic framework which allows to track appearance
+ * and disappearance of different interfaces provided by kernel/driver code
+ * inside the kernel. Examples of such interfaces: clocks, phys, regulators,
+ * drm_panel...
+ * Interface is specified by a pair of object pointer and interface type. 
Object
+ * type depends on interface type, for example interface type drm_panel
+ * determines that object is a device_node. Object pointer is used
+ * to distinguish different interfaces of the same type and should identify
+ * object the interface is bound to. For example it could be DT node,
+ * struct device...
+ *
+ * The framework provides two functions for interface providers which should be
+ * called just after interface becomes available or just before interface
+ * removal. Interface consumers can register callback which will be called when
+ * the requested interface changes its state, if during callback registration
+ * the interface is already up, notification will be sent also.
+ *
+ * The framework allows nesting calls, for example it is possible to signal one
+ * interface in tracker callback of another interface. It is done by putting
+ * every request into the queue. If the queue is empty before adding
+ * the request, the queue will be processed after, if there is already another
+ * request in the queue it means the queue is already processed by different
+ * thread so no additional action is required. With this pattern only spinlock
+ * is necessary to protect the queue. However in case of removal of either
+ * callback or interface caller should be sure that his request has been
+ * processed so framework waits until the queue becomes empty, it is done using
+ * completion mechanism.
+ * The framework functions should not be called in atomic context. Callbacks
+ * should be aware that they can be called in any time between registration and
+ * unregistration, so they should use synchronization mechanisms carefully.
+ * Callbacks should also avoid to perform time consuming tasks, the framework
+ * serializes them, so it could stall other callbacks.
+ */
+
+#include linux/completion.h
+#include linux/interface_tracker.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/spinlock.h
+
+enum interface_tracker_task_id {
+   interface_tracker_task_register,
+   interface_tracker_task_unregister,
+   interface_tracker_task_ifup,
+   interface_tracker_task_ifdown,
+};
+
+struct interface_tracker_task {
+   struct list_head list;
+   enum interface_tracker_task_id task_id;
+
+   const void *object;
+   unsigned long type;
+   union {
+   struct interface_tracker_block *itb;
+   void *data;
+   };
+};
+
+struct interface_tracker_node {
+   struct list_head list;
+   struct list_head itb_head

[RFC PATCH 3/4] drm/exynos/dpi: add interface tracker support

[Andrzej Hajda]

exynos_dpi uses connector polling for tracking panel presence,
this solution introduces unnecessary 10s delay before panel activation.
Moreover it is unsafe, module unloading or driver unbinding can
cause system crash. interface_tracker support solves both problems.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 58 ++---
 1 file changed, 47 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 2b09c7c..4c6682f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -14,6 +14,7 @@
 #include drm/drm_crtc_helper.h
 #include drm/drm_panel.h
 
+#include linux/interface_tracker.h
 #include linux/regulator/consumer.h
 
 #include video/of_videomode.h
@@ -21,6 +22,8 @@
 
 #include exynos_drm_drv.h
 
+static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode);
+
 struct exynos_dpi {
struct device *dev;
struct device_node *panel_node;
@@ -28,6 +31,7 @@ struct exynos_dpi {
struct drm_panel *panel;
struct drm_connector connector;
struct drm_encoder *encoder;
+   struct interface_tracker_block itb;
 
struct videomode *vm;
int dpms_mode;
@@ -41,15 +45,9 @@ exynos_dpi_detect(struct drm_connector *connector, bool 
force)
struct exynos_dpi *ctx = connector_to_dpi(connector);
 
/* panels supported only by boot-loader are always connected */
-   if (!ctx-panel_node)
+   if (ctx-vm)
return connector_status_connected;
 
-   if (!ctx-panel) {
-   ctx-panel = of_drm_find_panel(ctx-panel_node);
-   if (ctx-panel)
-   drm_panel_attach(ctx-panel, ctx-connector);
-   }
-
if (ctx-panel)
return connector_status_connected;
 
@@ -114,6 +112,28 @@ static struct drm_connector_helper_funcs 
exynos_dpi_connector_helper_funcs = {
.best_encoder = exynos_dpi_best_encoder,
 };
 
+void exynos_dpi_notifier(struct interface_tracker_block *itb,
+const void *object, unsigned long type, bool on,
+void *data)
+{
+   struct exynos_dpi *ctx = container_of(itb, struct exynos_dpi, itb);
+
+   mutex_lock(ctx-connector.dev-mode_config.mutex);
+   if (on) {
+   ctx-panel = data;
+   drm_panel_attach(ctx-panel, ctx-connector);
+   } else {
+   struct exynos_drm_display *display;
+
+   display = platform_get_drvdata(to_platform_device(ctx-dev));
+   exynos_dpi_dpms(display, DRM_MODE_DPMS_OFF);
+   drm_panel_detach(ctx-panel);
+   ctx-panel = NULL;
+   }
+   mutex_unlock(ctx-connector.dev-mode_config.mutex);
+   drm_helper_hpd_irq_event(ctx-connector.dev);
+}
+
 static int exynos_dpi_create_connector(struct exynos_drm_display *display,
   struct drm_encoder *encoder)
 {
@@ -123,10 +143,7 @@ static int exynos_dpi_create_connector(struct 
exynos_drm_display *display,
 
ctx-encoder = encoder;
 
-   if (ctx-panel_node)
-   connector-polled = DRM_CONNECTOR_POLL_CONNECT;
-   else
-   connector-polled = DRM_CONNECTOR_POLL_HPD;
+   connector-polled = DRM_CONNECTOR_POLL_HPD;
 
ret = drm_connector_init(encoder-dev, connector,
 exynos_dpi_connector_funcs,
@@ -140,9 +157,27 @@ static int exynos_dpi_create_connector(struct 
exynos_drm_display *display,
drm_sysfs_connector_add(connector);
drm_mode_connector_attach_encoder(connector, encoder);
 
+   if (ctx-panel_node) {
+   ctx-itb.callback = exynos_dpi_notifier;
+   interface_tracker_register(ctx-panel_node,
+  INTERFACE_TRACKER_TYPE_DRM_PANEL,
+  ctx-itb);
+   }
+
return 0;
 }
 
+static void exynos_dpi_display_remove(struct exynos_drm_display *display)
+{
+   struct exynos_dpi *ctx = display-ctx;
+
+   if (ctx-panel_node) {
+   interface_tracker_unregister(ctx-panel_node,
+INTERFACE_TRACKER_TYPE_DRM_PANEL,
+ctx-itb);
+   }
+}
+
 static void exynos_dpi_poweron(struct exynos_dpi *ctx)
 {
if (ctx-panel)
@@ -178,6 +213,7 @@ static void exynos_dpi_dpms(struct exynos_drm_display 
*display, int mode)
 
 static struct exynos_drm_display_ops exynos_dpi_display_ops = {
.create_connector = exynos_dpi_create_connector,
+   .remove = exynos_dpi_display_remove,
.dpms = exynos_dpi_dpms
 };
 
-- 
1.8.3.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

[RFC PATCH 4/4] drm/panel/ld9040: do not power off panel on removal

[Andrzej Hajda]

Panel is powered off already by connector during drm_panel_remove call.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
 drivers/gpu/drm/panel/panel-ld9040.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-ld9040.c 
b/drivers/gpu/drm/panel/panel-ld9040.c
index 1f1f837..1def4b0 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -348,7 +348,6 @@ static int ld9040_remove(struct spi_device *spi)
 {
struct ld9040 *ctx = spi_get_drvdata(spi);
 
-   ld9040_power_off(ctx);
drm_panel_remove(ctx-panel);
 
return 0;
-- 
1.8.3.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

[RFC PATCH 2/4] drm/panel: add interface tracker support

[Andrzej Hajda]

drm_panel framework allows only query for presence of given panel.
It also does not protect panel module from unloading and does not
provide solution for driver unbinding. interface_tracker
should solve both issues.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
---
 drivers/gpu/drm/drm_panel.c   | 5 +
 include/linux/interface_tracker.h | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..72a3c5c 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -22,6 +22,7 @@
  */
 
 #include linux/err.h
+#include linux/interface_tracker.h
 #include linux/module.h
 
 #include drm/drm_crtc.h
@@ -41,6 +42,8 @@ int drm_panel_add(struct drm_panel *panel)
mutex_lock(panel_lock);
list_add_tail(panel-list, panel_list);
mutex_unlock(panel_lock);
+   interface_tracker_ifup(panel-dev-of_node,
+  INTERFACE_TRACKER_TYPE_DRM_PANEL, panel);
 
return 0;
 }
@@ -48,6 +51,8 @@ EXPORT_SYMBOL(drm_panel_add);
 
 void drm_panel_remove(struct drm_panel *panel)
 {
+   interface_tracker_ifdown(panel-dev-of_node,
+INTERFACE_TRACKER_TYPE_DRM_PANEL, panel);
mutex_lock(panel_lock);
list_del_init(panel-list);
mutex_unlock(panel_lock);
diff --git a/include/linux/interface_tracker.h 
b/include/linux/interface_tracker.h
index e1eff00..0a08cba 100644
--- a/include/linux/interface_tracker.h
+++ b/include/linux/interface_tracker.h
@@ -6,6 +6,8 @@
 struct list_head;
 struct interface_tracker_block;
 
+#define INTERFACE_TRACKER_TYPE_DRM_PANEL 1
+
 typedef void (*interface_tracker_fn_t)(struct interface_tracker_block *itb,
   const void *object, unsigned long type,
   bool on, void *data);
-- 
1.8.3.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: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Andrzej Hajda]

Hi Greg,

Thanks for comments. I CC Laurent, I hope it could be interesting for 
him also.


Greg Kroah-Hartman wrote, On 30.04.2014 17:49:

On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote:

Generic framework for tracking internal interfaces
==

Summary
---

interface_tracker is a generic framework which allows to track appearance
and disappearance of different interfaces provided by kernel/driver code inside
the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel...
Interface is specified by a pair of object pointer and interface type. Object
type depends on interface type, for example interface type drm_panel determines
that object is a device_node. Object pointer is used to distinguish different
interfaces of the same type and should identify object the interface is bound 
to.
For example it could be DT node, struct device,...

The framework provides two functions for interface providers which should be
called just after interface becomes available or just before interface
removal. Interface consumers can register callback which will be called
when requested interface changes its state, if during callback registration
the interface is already up, notification will be sent also.

The framework allows nesting calls, for example it is possible to signal one
interface in tracker callback of another interface. It is done by putting
every request into the queue. If the queue is empty before adding
the request, the queue will be processed after, if there is already another
request in the queue it means the queue is already processed by different
thread so no additional action is required. With this pattern only spinlock
is necessary to protect the queue. However in case of removal of either
callback or interface caller should be sure that his request has been
processed so framework waits until the queue becomes empty, it is done using
completion mechanism.

The framework functions should not be called in atomic context. Callbacks
should be aware that they can be called in any time between registration and
de-registration, so they should use synchronization mechanisms carefully.
Callbacks should also avoid to perform time consuming tasks, the framework
serializes them, so it could stall other callbacks.

Use cases
-

The interface is very generic, there are many situations it can be useful:

1. Replacement for subsystem specific methods of publishing/unpublishing
interfaces. Currently many frameworks allows only querying for presence of given
interface. In such cases client can defer probing or implement interface
polling, which is usually subobtimal. Additionally subsystems often do not
provide methods to signal to the consumers that they are about to be destroyed.

2. Monitoring for different interfaces provided by the same object. An example
should explain it better. Lets assume in device tree drm crtc device node have
video link to another node, so it knows only that there is something connected
to its RGB output. It can be a RGB panel (drm_panel framework), it can be an
image enhancer (SoC specific framework) or it can be some signal converter
(drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to
another node. Currently it is difficult to handle such situations in a generic
way. interface_tracker should make it simple: crtc should monitor all supported
interface types that appears at the device_node pointed by the phandle.

Potential use cases
---

Points mentioned above were the reasons for writing this framework. During
development I have realized that this framework can be also useful for other
tasks.

3. Replacement for deferred probing - if for some reason driver do not wants to
defer but it requires given resources it can use interface_tracker. It should be
possible to create an helper which will wait for appearance of all interfaces
from a given list, and 'continue' probe only when all resources becomes
available.

4. Replacement or helper for subsystem specific solutions:
- V4L2 subdev async registration,
- component framework.
Both frameworks solves a problem of tracking sub-components (un-)registration
by master device, it should be possible to do the same with interface_tracker
framework. Some additional helpers can be convienent to make the implementation
easier.

5. Cure the situation with sysfs 'unbind' property. Currently many drivers are
providers of different resources/interfaces: regulators, clocks, phys,
V4L2 subdevs, ... They are usually protected from module unloading by getting
module reference, but there is no protection from driver unbinding using sysfs
method: echo 'device' /sys/bus/.../drivers/.../unbind. After unbind consumer
stays with the pointer to non-existing object, next time it tries to use it
system usually crashes. interface_tracker do not add any protection, but it adds
a way to signal to the consumer that given resource will disappear

Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver

[Andrzej Hajda]

Hi Tomasz,

On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
 Add exynos-simple-phy driver to support a single register
 PHY interfaces present on Exynos4 SoC.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|   24 +++
  drivers/phy/Kconfig|5 +
  drivers/phy/Makefile   |1 +
  drivers/phy/exynos-simple-phy.c|  154 
 
  4 files changed, 184 insertions(+)
  create mode 100644 drivers/phy/exynos-simple-phy.c
 
 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index b422e38..f97c4c3 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -114,3 +114,27 @@ Example:
   compatible = samsung,exynos-sataphy-i2c;
   reg = 0x38;
   };
 +
 +Samsung S5P/EXYNOS SoC series SIMPLE PHY
 +-
 +
 +Required properties:
 +- compatible : should be one of the listed compatibles:
 + - samsung,exynos4210-simple-phy
 + - samsung,exynos4412-simple-phy
 +- reg : offset and length of the register set;
 +- #phy-cells : from the generic phy bindings, must be 1;
 +
 +For samsung,exynos4210-simple-phy compatible PHYs the second cell in
 +the PHY specifier identifies the PHY and its meaning is as follows:
 +  0 - HDMI PHY,
 +  1 - DAC PHY,
 +  2 - ADC PHY,
 +  3 - PCIE PHY.
 +  4 - SATA PHY.
 +
 +For samsung,exynos4412-simple-phy compatible PHYs the second cell in
 +the PHY specifier identifies the PHY and its meaning is as follows:
 +  0 - HDMI PHY,
 +  1 - ADC PHY,

What about using preprocessor macros?

 +
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 3bb05f1..65ab783 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -166,4 +166,9 @@ config PHY_XGENE
   help
 This option enables support for APM X-Gene SoC multi-purpose PHY.
  
 +config EXYNOS_SIMPLE_PHY
 + tristate Exynos Simple PHY driver
 + help
 +   Support for 1-bit PHY controllers on SoCs from Exynos family.
 +
  endmenu
 diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
 index 2faf78e..88c5b60 100644
 --- a/drivers/phy/Makefile
 +++ b/drivers/phy/Makefile
 @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2)   += phy-exynos4210-usb2.o
  obj-$(CONFIG_PHY_EXYNOS4X12_USB2)+= phy-exynos4x12-usb2.o
  obj-$(CONFIG_PHY_EXYNOS5250_USB2)+= phy-exynos5250-usb2.o
  obj-$(CONFIG_PHY_XGENE)  += phy-xgene.o
 +obj-$(CONFIG_EXYNOS_SIMPLE_PHY)  += exynos-simple-phy.o
 diff --git a/drivers/phy/exynos-simple-phy.c b/drivers/phy/exynos-simple-phy.c
 new file mode 100644
 index 000..57ad338
 --- /dev/null
 +++ b/drivers/phy/exynos-simple-phy.c
 @@ -0,0 +1,154 @@
 +/*
 + * Exynos Simple PHY driver
 + *
 + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
 + * Author: Tomasz Stanislawski t.stanisl...@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/io.h
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/of_address.h
 +#include linux/of_device.h
 +#include linux/phy/phy.h
 +
 +#define EXYNOS_PHY_ENABLE(1  0)
 +
 +static int exynos_phy_power_on(struct phy *phy)
 +{
 + void __iomem *reg = phy_get_drvdata(phy);
 + u32 val;
 +
 + val = readl(reg);
 + val |= EXYNOS_PHY_ENABLE;
 + writel(val, reg);
 +
 + return 0;
 +}
 +
 +static int exynos_phy_power_off(struct phy *phy)
 +{
 + void __iomem *reg = phy_get_drvdata(phy);
 + u32 val;
 +
 + val = readl(reg);
 + val = ~EXYNOS_PHY_ENABLE;
 + writel(val, reg);
 +
 + return 0;
 +}
 +
 +static struct phy_ops exynos_phy_ops = {
 + .power_on   = exynos_phy_power_on,
 + .power_off  = exynos_phy_power_off,
 + .owner  = THIS_MODULE,
 +};
 +
 +static const u32 exynos4210_offsets[] = {
 + 0x0700, /* HDMI_PHY */
 + 0x070C, /* DAC_PHY */
 + 0x0718, /* ADC_PHY */
 + 0x071C, /* PCIE_PHY */
 + 0x0720, /* SATA_PHY */
 + ~0, /* end mark */
 +};
 +
 +static const u32 exynos4412_offsets[] = {
 + 0x0700, /* HDMI_PHY */
 + 0x0718, /* ADC_PHY */
 + ~0, /* end mark */
 +};

Why have you selected only these registers?
According to specs Exynos 4210 has 9 and 4412 has 7 control registers
with 'phy-enable' functionality.
I guess MIPI would require little more work as it has also reset bits,
but it will be still better than separate driver.

 +
 +static const struct of_device_id exynos_phy_of_match[] = {
 + { .compatible = samsung,exynos4210-simple-phy,
 +   .data = exynos4210_offsets},
 + { .compatible = 

Re: [PATCHv2 2/3] drm: exynos: hdmi: use hdmiphy as PHY

[Andrzej Hajda]

Hi Tomasz,

On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
 The HDMIPHY (physical interface) is controlled by a single
 bit in a power controller's regiter. It was implemented
 as clock. It was a simple but effective hack.

This power controller register has also bits to control HDMI clock
divider ratio. I guess current drivers do not change it, but how do you
want to implement access to it if some HDMI driver in the future will
need to change ratio. I guess in case of clk it would be easier.

Regards
Andrzej


--
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 v12][ 07/12] drm: drm_display_mode: add signal polarity flags

[Andrzej Hajda]

Hi Denis,

On 04/07/2014 02:44 PM, Denis Carikli wrote:
 We need a way to pass signal polarity informations
   between DRM panels, and the display drivers.
 
 To do that, a pol_flags field was added to drm_display_mode.
 
 Signed-off-by: Denis Carikli de...@eukrea.com
 ---
 ChangeLog v11-v12:
 - Rebased: This patch now applies against drm_modes.h
 - Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
 
 ChangeLog v10-v11:
 - Since the imx-drm won't be able to retrive its regulators
   from the device tree when using display-timings nodes,
   and that I was told that the drm simple-panel driver 
   already supported that, I then, instead, added what was
   lacking to make the eukrea displays work with the
   drm-simple-panel driver.
 
   That required a way to get back the display polarity
   informations from the imx-drm driver without affecting
   userspace.
 ---
  include/drm/drm_modes.h |8 
  1 file changed, 8 insertions(+)
 
 diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
 index 2dbbf99..b3789e2 100644
 --- a/include/drm/drm_modes.h
 +++ b/include/drm/drm_modes.h
 @@ -93,6 +93,13 @@ enum drm_mode_status {
  
  #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
  
 +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
 +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
 +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE   BIT(3)

What is the purpose of DRM_MODE_FLAG_POL_PIXDATA_PRESERVE?
If 'preserve' means 'ignore' we can set to zero negedge and posedge bits
instead of adding new bit. If it is something different please describe it.

 +#define DRM_MODE_FLAG_POL_DE_LOW BIT(4)
 +#define DRM_MODE_FLAG_POL_DE_HIGHBIT(5)
 +#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
 +

The same comments here.

  struct drm_display_mode {
   /* Header */
   struct list_head head;
 @@ -144,6 +151,7 @@ struct drm_display_mode {
   int vrefresh;   /* in Hz */
   int hsync;  /* in kHz */
   enum hdmi_picture_aspect picture_aspect_ratio;
 + unsigned int pol_flags;

Adding field and macros description to the DocBook would be nice.

Regards
Andrzej

  };
  
  /* mode specified on the command line */
 

--
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 v12][ 07/12] drm: drm_display_mode: add signal polarity flags

[Andrzej Hajda]

On 04/08/2014 10:08 AM, Denis Carikli wrote:
 On 04/08/2014 08:36 AM, Andrzej Hajda wrote:

 Hi Denis,
 Hi,
 
 +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE  BIT(1)
 +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE  BIT(2)
 +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)

 What is the purpose of DRM_MODE_FLAG_POL_PIXDATA_PRESERVE?
 If 'preserve' means 'ignore' we can set to zero negedge and posedge bits
 instead of adding new bit. If it is something different please describe it.
 Yes, it meant 'ignore'.
 
 The goal was to be able to have a way to keep the old behavior while 
 still being able to set the flags.
 
 So, with the imx-drm driver, if none of the DRM_MODE_FLAG_POL_PIXDATA 
 were set(that is POSEDGE, NEGEDGE, PRESERVE), then in ipuv3-crtc.c, it 
 went using the old flags settings that were previously hardcoded.
 
 The same applied for DRM_MODE_FLAG_POL_DE.
 The patch using theses flags is the 08/12 of this same serie.

So as I understand you want to:
- do not change hw polarity settings by using preserve bit,
- keep the old behavior of the driver by setting all bits to zero.

I think this is the issue of the specific driver, and it should not
influence core structs.

I am not familiar with imx but I guess it should not be a problem
to solve the issue in the driver.

 
   struct drm_display_mode {
 [..]
 +   unsigned int pol_flags;

 Adding field and macros description to the DocBook would be nice.
 So I will have to describe it in the Connector Helper Operations 
 section of drm.tmpl, right before the mode_valid synopsis ?

Yes, I think so.

Andrzej

 
 Denis.
 

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