cron job: media_tree daily build: OK

2015-10-13 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Wed Oct 14 04:00:16 CEST 2015
git branch: test
git hash:   efe98010b80ec4516b2779e1b4e4a8ce16bf89fe
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:4.0.0-3.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-rc1-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

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

Re: coda: not generating EOS event

2015-10-13 Thread Jean-Michel Hautbois 
Hi all,

2015-01-22 15:58 GMT+01:00 Philipp Zabel :
> Hi,
>
> Am Donnerstag, den 11.12.2014, 15:47 +0100 schrieb Hans Verkuil:
>> Hi Pawel,
>>
>> On 12/11/14 15:42, Nicolas Dufresne wrote:
>> > Le jeudi 11 décembre 2014 à 11:00 -0200, Fabio Estevam a écrit :
>> >> Hi,
>> >>
>> >> I am running Gstreamer 1.4.4 with on a imx6q-sabresd board and I am
>> >> able to decode a video through the coda driver.
>> >>
>> >> The pipeline I use is:
>> >> gst-launch-1.0 filesrc
>> >> location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux !
>> >> h264parse ! v4l2video1dec ! videoconvert ! fbdevsink
>> >
>> > This is a known issue. The handling of EOS and draining is ill defined
>> > in V4L2 specification. We should be clarifying this soon. Currently
>> > GStreamer implements what was originally done in Exynos MFC driver. This
>> > consist of sending empty buffer to the V4L2 Output (the input), until we
>> > get an empty buffer (bytesused = 0) on the V4L2 Capture (output).
>> >
>> > The CODA driver uses the new method to initiate the drain, which is to
>> > send V4L2_DEC_CMD_STOP, this was not implemented by any driver when GST
>> > v4l2 support was added. This is the right thing to do. This is tracked
>> > at (contribution welcome of course):
>> >
>> > https://bugzilla.gnome.org/show_bug.cgi?id=733864
>> >
>> > Finally, CODA indicate that all buffer has been sent through an event,
>> > V4L2_EVENT_EOS. This event was designed for another use case, it should
>> > in fact be sent when the decoder is done with the encoded buffers,
>> > rather then when the last decoded buffer has been queued. When correctly
>> > implemented, this event cannot be used to figure-out when the last
>> > decoded buffer has been dequeued.
>> >
>> > During last workshop, it has been proposed to introduce a flag on the
>> > last decoded buffer, _LAST. This flag could also be put on an empty
>>
>> Are you planning to work on this? That was my assumption, but it's probably
>> a good idea to check in case we are waiting for one another :-)
>
> I had another look at the ELC-E 2014 V4L2 codec API document and have
> tried to implement the proposed decoder draining flow in an RFC:
> "Signalling last decoded frame by V4L2_BUF_FLAG_LAST and -EPIPE":
>
> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/87152
>
> Are you planning to pour the workshop's codec API document into a V4L2
> documentation patch?

I am now working on the encoder part (for coda) which should do the same.
But everything is documented from a decoder POV, not the encoder's...
Is the mecanism already there, and the only thing which should be
added is the ENC_CMD_STOP command ?

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

Re: [RFC PATCH v6 0/4] Refactoring Videobuf2 for common use

2015-10-13 Thread Hans Verkuil 
On 10/13/15 11:35, Junghak Sung wrote:
> 
> 
> On 10/12/2015 09:46 PM, Hans Verkuil wrote:
>> Hi Junghak,
>>
>> I've accepted this v6 series and made a pull request for Mauro.
>>
> 
> Hi Hans & Mauro,
> 
> First of all, thank you for your acceptance.
> But, I have received some build warning reports for this
> vb2-refactoring patch from kbuild robot. So, I'd like to fix them
> firstly with next patch (v7).

If this was a missing const in fimc-lite, then I fixed that myself in
your patch. If it was for other things as well, then let me know.

> Furthermore, I have tried to find out the way to move things related
> with vb2_thread to vb2-core. And then.. finally I can come close to
> resolve that.
> Please, wait for patch v7 if you don't mind.
> I will/can send it by this weekend.

OK. Please do this vb2_thread work as a patch on top of the existing series.
I would like to get what we have today merged asap (with warnings fixed) and
this vb2_thread work can always be added later.

Regards,

Hans

>> I am still not happy about the queue_setup patch, but that can be changed
>> later.
> 
> Yes, queue_setup issue needs to be dealt with regardless of
> this refactoring patch.
> 
> Best regards,
> Junghak
> 
>>
>> Regards,
>>
>> Hans
>>
>> On 10/06/2015 11:37 AM, Junghak Sung wrote:
>>> Hello everybody,
>>>
>>> This is the 6th round for refactoring Videobuf2(a.k.a VB2).
>>> The purpose of this patch series is to separate existing VB2 framework
>>> into core part and V4L2 specific part. So that not only V4L2 but also other
>>> frameworks can use them to manage buffer and utilize queue.
>>>
>>> Why do we try to make the VB2 framework to be common?
>>>
>>> As you may know, current DVB framework uses ringbuffer mechanism to demux
>>> MPEG-2 TS data and pass it to userspace. However, this mechanism requires
>>> extra memory copy because DVB framework provides only read() system call for
>>> application - read() system call copies the kernel data to user-space 
>>> buffer.
>>> So if we can use VB2 framework which supports streaming I/O and buffer
>>> sharing mechanism, then we could enhance existing DVB framework by removing
>>> the extra memory copy - with VB2 framework, application can access the 
>>> kernel
>>> data directly through mmap system call.
>>>
>>> We have a plan for this work as follows:
>>> 1. Separate existing VB2 framework into three parts - VB2 core, VB2 v4l2.
>>> Of course, this change will not affect other v4l2-based
>>> device drivers. This patch series corresponds to this step.
>>>
>>> 2. Add and implement new APIs for DVB streaming I/O.
>>> We can remove unnecessary memory copy between kernel-space and 
>>> user-space
>>> by using these new APIs. However, we leaves legacy interfaces as-is
>>> for backward compatibility.
>>>
>>> This patch series is the first step for it.
>>> The previous version of this patch series can be found at belows.
>>>
>>> [1] RFC PATCH v1 - http://www.spinics.net/lists/linux-media/msg90688.html
>>> [2] RFC PATCH v2 - http://www.spinics.net/lists/linux-media/msg92130.html
>>> [3] RFC PATCH v3 - http://www.spinics.net/lists/linux-media/msg92953.html
>>> [4] RFC PATCH v4 - http://www.spinics.net/lists/linux-media/msg93421.html
>>> [5] RFC PATCH v5 - http://www.spinics.net/lists/linux-media/msg93810.html
>>>
>>> Changes since v5
>>> 1. v5 is merged partially to media_tree
>>> 4 of 8 patches - restructuring vb2_buffer for common use - are merged to
>>> media_tree. So, v6 is rebased on later version than that.
>>>
>>> 2. vb2_format is reverted to void *
>>> vb2_format - which is newly defined for queue_setup() in v5 to deliver
>>> the format information from user-space to device driver - is reverted to
>>> void pointer. This change requires more discussion about the way to do
>>> the format validation and decide the image size.
>>> So, in this version, I would like to revert it to original version.
>>>
>>> 3. The change related with v4l2_buf_ops is moved
>>> The change related with v4l2_buf_ops seems to be a sort of functional 
>>> change.
>>> So, it was moved to patch 3/4 - which includes the most of functional 
>>> changes.
>>>
>>>
>>> Changes since v4
>>> 1. Rebase on 4.3-rc1
>>> Kernel 4.3-rc1 was released. So, this patch set is made based on
>>> that version.
>>>
>>> 2. Modify queue_setup() argument
>>> In previous patch set, struct v4l2_format, which is a parameter of
>>> queue_setup(), is abstracted by using void pointer. But, it is better way to
>>> pass the parameter with presise meaning than abstracting it.
>>> So, replace void * with struct vb2_format which is newly defined to contain
>>> the format information for common use.
>>>
>>> 3. Add a code to check if VB2_MAX_* match with VIDEO_MAX_*
>>> Add a check code to videobuf2-v4l2.c where the compiler compares 
>>> VIDEO_MAX_FRAME
>>> and VB2_MAX_FRAME (and ditto for MAX_PLANES) and throws an #error if they
>>> do not match.
>>>
>>> 4. Change the commit order
>>> For easier review,

Re: [RFC PATCH v6 0/4] Refactoring Videobuf2 for common use

2015-10-13 Thread Junghak Sung 



On 10/12/2015 09:46 PM, Hans Verkuil wrote:

Hi Junghak,

I've accepted this v6 series and made a pull request for Mauro.



Hi Hans & Mauro,

First of all, thank you for your acceptance.
But, I have received some build warning reports for this
vb2-refactoring patch from kbuild robot. So, I'd like to fix them
firstly with next patch (v7).
Furthermore, I have tried to find out the way to move things related
with vb2_thread to vb2-core. And then.. finally I can come close to
resolve that.
Please, wait for patch v7 if you don't mind.
I will/can send it by this weekend.


I am still not happy about the queue_setup patch, but that can be changed
later.


Yes, queue_setup issue needs to be dealt with regardless of
this refactoring patch.

Best regards,
Junghak



Regards,

Hans

On 10/06/2015 11:37 AM, Junghak Sung wrote:

Hello everybody,

This is the 6th round for refactoring Videobuf2(a.k.a VB2).
The purpose of this patch series is to separate existing VB2 framework
into core part and V4L2 specific part. So that not only V4L2 but also other
frameworks can use them to manage buffer and utilize queue.

Why do we try to make the VB2 framework to be common?

As you may know, current DVB framework uses ringbuffer mechanism to demux
MPEG-2 TS data and pass it to userspace. However, this mechanism requires
extra memory copy because DVB framework provides only read() system call for
application - read() system call copies the kernel data to user-space buffer.
So if we can use VB2 framework which supports streaming I/O and buffer
sharing mechanism, then we could enhance existing DVB framework by removing
the extra memory copy - with VB2 framework, application can access the kernel
data directly through mmap system call.

We have a plan for this work as follows:
1. Separate existing VB2 framework into three parts - VB2 core, VB2 v4l2.
Of course, this change will not affect other v4l2-based
device drivers. This patch series corresponds to this step.

2. Add and implement new APIs for DVB streaming I/O.
We can remove unnecessary memory copy between kernel-space and user-space
by using these new APIs. However, we leaves legacy interfaces as-is
for backward compatibility.

This patch series is the first step for it.
The previous version of this patch series can be found at belows.

[1] RFC PATCH v1 - http://www.spinics.net/lists/linux-media/msg90688.html
[2] RFC PATCH v2 - http://www.spinics.net/lists/linux-media/msg92130.html
[3] RFC PATCH v3 - http://www.spinics.net/lists/linux-media/msg92953.html
[4] RFC PATCH v4 - http://www.spinics.net/lists/linux-media/msg93421.html
[5] RFC PATCH v5 - http://www.spinics.net/lists/linux-media/msg93810.html

Changes since v5
1. v5 is merged partially to media_tree
4 of 8 patches - restructuring vb2_buffer for common use - are merged to
media_tree. So, v6 is rebased on later version than that.

2. vb2_format is reverted to void *
vb2_format - which is newly defined for queue_setup() in v5 to deliver
the format information from user-space to device driver - is reverted to
void pointer. This change requires more discussion about the way to do
the format validation and decide the image size.
So, in this version, I would like to revert it to original version.

3. The change related with v4l2_buf_ops is moved
The change related with v4l2_buf_ops seems to be a sort of functional change.
So, it was moved to patch 3/4 - which includes the most of functional changes.


Changes since v4
1. Rebase on 4.3-rc1
Kernel 4.3-rc1 was released. So, this patch set is made based on
that version.

2. Modify queue_setup() argument
In previous patch set, struct v4l2_format, which is a parameter of
queue_setup(), is abstracted by using void pointer. But, it is better way to
pass the parameter with presise meaning than abstracting it.
So, replace void * with struct vb2_format which is newly defined to contain
the format information for common use.

3. Add a code to check if VB2_MAX_* match with VIDEO_MAX_*
Add a check code to videobuf2-v4l2.c where the compiler compares VIDEO_MAX_FRAME
and VB2_MAX_FRAME (and ditto for MAX_PLANES) and throws an #error if they
do not match.

4. Change the commit order
For easier review, the patch that just move things around without doing any
functional change is moved to the last.

All ideas above are from Hans and it seems to be better and right way.


Changes since v3

1. Resolve build errors
In previous patch set, the build errors prevented reviewers from applying
the patch. So, in this patch, I tryed to fix the build errors but I hadn't
the build test on all architectures except for x86 and ARM.

2. Modify descriptions for DocBook
Descriptions not complying with the DocBook rule are modified,
which was pointed out by Mauro.

3. Initialize reserved fields explicitly
The reserved fields of v4l2_buffer are initialized by 0 explicitly
when the vb2_buffer information is returned to userspace,
which was pointed out by Hans.

4. Remove unnecessary

[RFC/PATCH] media: omap3isp: Set maximum DMA segment size

2015-10-13 Thread Laurent Pinchart 
The maximum DMA segment size controls the IOMMU mapping granularity. Its
default value is 64kB, resulting in potentially non-contiguous IOMMU
mappings. Configure it to 4GB to ensure that buffers get mapped
contiguously.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/isp.c | 4 
 drivers/media/platform/omap3isp/isp.h | 1 +
 2 files changed, 5 insertions(+)

I'm posting this as an RFC because I'm not happy with the patch, even if it
gets the job done.

On ARM the maximum DMA segment size is used when creating IOMMU mappings. As
a large number of devices require contiguous memory buffers (this is a very
common requirement for video-related embedded devices) the default 64kB value
doesn't work.

I haven't investigated the history behind this API in details but I have a
feeling something is not quite right. We force most drivers to explicitly set
the maximum segment size from a default that seems valid for specific use
cases only. Furthermore, as the DMA parameters are not stored directly in
struct device this require allocation of external memory for which we have no
proper management rule, making automatic handling of the DMA parameters in
frameworks or helper functions cumbersome (for a discussion on this topic see
http://www.spinics.net/lists/linux-media/msg92467.html and
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html).

Is it time to fix this mess ?

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 17430a6ed85a..ebf7dc76e94d 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2444,6 +2444,10 @@ static int isp_probe(struct platform_device *pdev)
if (ret)
goto error;
 
+   isp->dev->dma_parms = >dma_parms;
+   dma_set_max_seg_size(isp->dev, DMA_BIT_MASK(32));
+   dma_set_seg_boundary(isp->dev, 0x);
+
platform_set_drvdata(pdev, isp);
 
/* Regulators */
diff --git a/drivers/media/platform/omap3isp/isp.h 
b/drivers/media/platform/omap3isp/isp.h
index e579943175c4..4b2231cf01be 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -193,6 +193,7 @@ struct isp_device {
u32 syscon_offset;
u32 phy_type;
 
+   struct device_dma_parameters dma_parms;
struct dma_iommu_mapping *mapping;
 
/* ISP Obj */
-- 
Regards,

Laurent Pinchart

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

[PATCH] DocBook media: Fix a typo in encoder cmd

2015-10-13 Thread Jean-Michel Hautbois 
A copy-paste from DECODER_CMD : replace decoded by encoded.

Signed-off-by: Jean-Michel Hautbois 
---
 Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
index fc1d462..70a4a08 100644
--- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
@@ -130,7 +130,7 @@ encoding will continue until the end of the
current Group
 Of Pictures, otherwise encoding will stop immediately.
 When the encoder is already stopped, this command does
 nothing. mem2mem encoders will send a V4L2_EVENT_EOS event
-when the last frame has been decoded and all frames are ready to be
dequeued and
+when the last frame has been encoded and all frames are ready to be
dequeued and
 will set the V4L2_BUF_FLAG_LAST buffer flag on the last
 buffer of the capture queue to indicate there will be no new buffers
produced to
 dequeue. This buffer may be empty, indicated by the driver setting the
-- 
2.6.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: [RFC PATCH v6 0/4] Refactoring Videobuf2 for common use

2015-10-13 Thread Junghak Sung 



On 10/13/2015 07:40 PM, Hans Verkuil wrote:

On 10/13/15 11:35, Junghak Sung wrote:



On 10/12/2015 09:46 PM, Hans Verkuil wrote:

Hi Junghak,

I've accepted this v6 series and made a pull request for Mauro.



Hi Hans & Mauro,

First of all, thank you for your acceptance.
But, I have received some build warning reports for this
vb2-refactoring patch from kbuild robot. So, I'd like to fix them
firstly with next patch (v7).


If this was a missing const in fimc-lite, then I fixed that myself in
your patch. If it was for other things as well, then let me know.


There are two warnings reported from kbuild robot.
One is related with missing const as you mentioned, and the other is
format error on dprintk(). (refer to attached email)
But, I think that format error does not need to be dealt with,
because it was from original code.




Furthermore, I have tried to find out the way to move things related
with vb2_thread to vb2-core. And then.. finally I can come close to
resolve that.
Please, wait for patch v7 if you don't mind.
I will/can send it by this weekend.


OK. Please do this vb2_thread work as a patch on top of the existing series.
I would like to get what we have today merged asap (with warnings fixed) and
this vb2_thread work can always be added later.



OK. If so, I will prepare the next patch(v7) including vb2_thread work 
on v6.


Thank you.

Best regards,
Junghak



Regards,

Hans


I am still not happy about the queue_setup patch, but that can be changed
later.


Yes, queue_setup issue needs to be dealt with regardless of
this refactoring patch.

Best regards,
Junghak



Regards,

 Hans

On 10/06/2015 11:37 AM, Junghak Sung wrote:

Hello everybody,

This is the 6th round for refactoring Videobuf2(a.k.a VB2).
The purpose of this patch series is to separate existing VB2 framework
into core part and V4L2 specific part. So that not only V4L2 but also other
frameworks can use them to manage buffer and utilize queue.

Why do we try to make the VB2 framework to be common?

As you may know, current DVB framework uses ringbuffer mechanism to demux
MPEG-2 TS data and pass it to userspace. However, this mechanism requires
extra memory copy because DVB framework provides only read() system call for
application - read() system call copies the kernel data to user-space buffer.
So if we can use VB2 framework which supports streaming I/O and buffer
sharing mechanism, then we could enhance existing DVB framework by removing
the extra memory copy - with VB2 framework, application can access the kernel
data directly through mmap system call.

We have a plan for this work as follows:
1. Separate existing VB2 framework into three parts - VB2 core, VB2 v4l2.
 Of course, this change will not affect other v4l2-based
 device drivers. This patch series corresponds to this step.

2. Add and implement new APIs for DVB streaming I/O.
 We can remove unnecessary memory copy between kernel-space and user-space
 by using these new APIs. However, we leaves legacy interfaces as-is
 for backward compatibility.

This patch series is the first step for it.
The previous version of this patch series can be found at belows.

[1] RFC PATCH v1 - http://www.spinics.net/lists/linux-media/msg90688.html
[2] RFC PATCH v2 - http://www.spinics.net/lists/linux-media/msg92130.html
[3] RFC PATCH v3 - http://www.spinics.net/lists/linux-media/msg92953.html
[4] RFC PATCH v4 - http://www.spinics.net/lists/linux-media/msg93421.html
[5] RFC PATCH v5 - http://www.spinics.net/lists/linux-media/msg93810.html

Changes since v5
1. v5 is merged partially to media_tree
4 of 8 patches - restructuring vb2_buffer for common use - are merged to
media_tree. So, v6 is rebased on later version than that.

2. vb2_format is reverted to void *
vb2_format - which is newly defined for queue_setup() in v5 to deliver
the format information from user-space to device driver - is reverted to
void pointer. This change requires more discussion about the way to do
the format validation and decide the image size.
So, in this version, I would like to revert it to original version.

3. The change related with v4l2_buf_ops is moved
The change related with v4l2_buf_ops seems to be a sort of functional change.
So, it was moved to patch 3/4 - which includes the most of functional changes.


Changes since v4
1. Rebase on 4.3-rc1
Kernel 4.3-rc1 was released. So, this patch set is made based on
that version.

2. Modify queue_setup() argument
In previous patch set, struct v4l2_format, which is a parameter of
queue_setup(), is abstracted by using void pointer. But, it is better way to
pass the parameter with presise meaning than abstracting it.
So, replace void * with struct vb2_format which is newly defined to contain
the format information for common use.

3. Add a code to check if VB2_MAX_* match with VIDEO_MAX_*
Add a check code to videobuf2-v4l2.c where the compiler compares VIDEO_MAX_FRAME
and VB2_MAX_FRAME (and ditto for MAX_PLANES) and throws an

[Possible Bug] ddbridge: Do not release the acquired lock if dvb_attach fails

2015-10-13 Thread Ahmed Tamrawi 
Source file correspondence on the master branch:
https://github.com/torvalds/linux/blob/master/drivers/media/pci/ddbridge/ddbridge-core.c#L595

Summary:
The lock acquired on (port->i2c_gate_lock) is never released if
function (tuner_attach_tda18271) returns on line 605.

Details:
Function tuner_attach_tda18271 (line 595) acquires a lock on
port->i2c_gate_lock via the call to the function pointer
(input->fe->ops.i2c_gate_ctrl(input->fe, 1)) (line 601) which calls
function (drxk_gate_ctrl). However, when the call to function
(dvb_attach) on line 602 fails (returns NULL), the lock on
(port->i2c_gate_lock) is never released.

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

Re: [PATCHv9 07/15] cec: add HDMI CEC framework

2015-10-13 Thread Russell King - ARM Linux 
On Mon, Oct 12, 2015 at 01:35:54PM +0200, Hans Verkuil wrote:
> On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote:
> > Surely you aren't proposing that drivers should write directly to
> > adap->phys_addr without calling some notification function that the
> > physical address has changed?
> 
> Userspace is informed through CEC_EVENT_STATE_CHANGE when the adapter is
> enabled/disabled. When the adapter is enabled and CEC_CAP_PHYS_ADDR is
> not set (i.e. the kernel takes care of this), then calling 
> CEC_ADAP_G_PHYS_ADDR
> returns the new physical address.

Okay, so when I see the EDID arrive, I should be doing:

phys = parse_hdmi_addr(block->edid);
cec->adap->phys_addr = phys;
cec_enable(cec->adap, true);

IOW, you _are_ expecting adap->phys_addr to be written, but only while
the adapter is disabled?

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 06/15] rc: Add HDMI CEC protocol handling

2015-10-13 Thread Russell King - ARM Linux 
On Mon, Oct 12, 2015 at 01:50:47PM +0200, Hans Verkuil wrote:
> On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote:
> > On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
> >> From: Kamil Debski 
> >>
> >> Add handling of remote control events coming from the HDMI CEC bus.
> >> This patch includes a new keymap that maps values found in the CEC
> >> messages to the keys pressed and released. Also, a new protocol has
> >> been added to the core.
> >>
> >> Signed-off-by: Kamil Debski 
> >> Signed-off-by: Hans Verkuil 
> > 
> > (Added Mauro)
> > 
> > Hmm, how is rc-cec supposed to be loaded?
> 
> Is CONFIG_RC_MAP enabled in your config? Ran 'depmod -a'? (Sorry, I'm sure 
> you've done
> that, just checking...)

CONFIG_RC_MAP=m

and yes, if depmod hadn't have been run, modprobing rc-cec would not
have worked - modprobe always looks up in the depmod information to
find out where the module is located, and also to determine any
dependencies.

> It's optional as I understand it, since you could configure the keytable from
> userspace instead of using this module.
> 
> For the record (just tried it), it does load fine on my setup.

Immediately after boot, I have:

# lsmod
Module  Size  Used by
...
coda   54685  0
v4l2_mem2mem   14517  1 coda
videobuf2_dma_contig 9478  1 coda
videobuf2_vmalloc   5529  1 coda
videobuf2_memops1888  2 videobuf2_dma_contig,videobuf2_vmalloc
cecd_dw_hdmi3129  0
# modprobe rc-cec
# lsmod
Module  Size  Used by
rc_cec  1785  0
...
coda   54685  0
v4l2_mem2mem   14517  1 coda
videobuf2_dma_contig 9478  1 coda
videobuf2_vmalloc   5529  1 coda
videobuf2_memops1888  2 videobuf2_dma_contig,videobuf2_vmalloc
cecd_dw_hdmi3129  0

So, rc-cec is perfectly loadable, it just doesn't get loaded at boot.
Manually loading it like this is useless though - I have to unload
cecd_dw_hdmi and then re-load it after rc-cec is loaded for rc-cec to
be seen.  At that point, (and with the help of a userspace program)
things start working as expected.

> BTW, I am still on the fence whether using the kernel RC subsystem is
> the right thing to do. There are a number of CEC RC commands that use
> extra parameters that cannot be mapped to the RC API, so you still
> need to handle those manually.

Even though it is a remote control which is being forwarded for the
most part, but there are operation codes which aren't related to
key presses specified by the standard.  I don't think there's anything
wrong with having a RC interface present, but allowing other interfaces
as a possibility is a good thing too - it allows a certain amount of
flexibility.

For example, with rc-cec loaded and properly bound, I can control at
least rhythmbox within gnome using the TVs remote control with no
modifications - and that happens because the X server passes on the
events it receives via the event device.

Given the range of media applications, I think that's key - it needs
to at least have the capability to plug into the existing ways of doing
things, even if those ways are not perfect.

> Perhaps I should split it off into a separate patch and keep it out
> from the initial pull request once we're ready for that.

I'm biased because it is an enablement feature - it allows CEC to work
out of the box with at least some existing media apps. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-13 Thread Russell King - ARM Linux 
On Mon, Oct 12, 2015 at 02:39:42PM +0200, Hans Verkuil wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
> > The possible status values that are implemented in the CEC framework
> > are following:
> > 
> > +/* cec status field */
> > +#define CEC_TX_STATUS_OK   (0)
> > +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> > +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
> > +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
> > +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
> > +#define CEC_RX_STATUS_READY(0)
> > 
> > The only two ones I could match with the Exynos CEC module status bits are
> > CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
> > 
> > The status bits in Exynos HW are:
> > - Tx_Error
> > - Tx_Done
> > - Tx_Transferring
> > - Tx_Running
> > - Tx_Bytes_Transferred
> > 
> > - Tx_Wait
> > - Tx_Sending_Status_Bit
> > - Tx_Sending_Hdr_Blk
> > - Tx_Sending_Data_Blk
> > - Tx_Latest_Initiator
> > 
> > - Tx_Wait_SFT_Succ
> > - Tx_Wait_SFT_New
> > - Tx_Wait_SFT_Retran
> > - Tx_Retrans_Cnt
> > - Tx_ACK_Failed
> 
> So are these all intermediate states? And every transfer always ends with 
> Tx_Done or
> Tx_Error state?
> 
> It does look that way...

For the Synopsis DW CEC, I have:

Bit Field   Description
4   ERROR_INIT  An error is detected on cec line (for initiator only).
3   ARB_LOSTThe initiator losses the CEC line arbitration to a second
initiator. (specification CEC 9).
2   NACKA frame is not acknowledged in a directly addressed message.
Or a frame is negatively acknowledged in a broadcast message
(for initiator only).
0   DONEThe current transmission is successful (for initiator only).

That's about as much of a description that there is for this hardware.
Quite what comprises an "ERROR_INIT", I don't know.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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