cron job: media_tree daily build: ERRORS

[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 Aug 31 04:00:17 CEST 2016
git branch: test
git hash:   fb6609280db902bd5d34445fba1c926e95e63914
gcc version:i686-linux-gcc (GCC) 5.4.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: 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: WARNINGS
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: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
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-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-i686: OK
linux-4.8-rc1-i686: 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: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
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-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-x86_64: OK
linux-4.8-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

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/index.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 0/3] Fix kernel-doc parser for typedef functions

[Mauro Carvalho Chehab]

The kernel-doc parser has two issues when handling typedef functions:

1) its parse is incomplete;
2) it causes warnings when a typedef is used as a function argument.

This series partially addresses (1), adding one extra syntax for the parser.
I'm pretty sure that the parser is still incomplete and that we'll get some 
other
places where it fails.

Jon,

My plan is to apply the last patch on my tree, together with a series of
patches that I'm writing to fix the warnings on nitpick mode.

The other two patches better fit on your tree, IMHO.

Mauro Carvalho Chehab (3):
  docs-rst: improve typedef parser
  docs-rst: kernel-doc: fix typedef output in RST format
  [media] v4l2-dv-timings.h: let kernel-doc parte the typedef argument

 include/media/v4l2-dv-timings.h |  4 ++--
 scripts/kernel-doc  | 36 ++--
 2 files changed, 28 insertions(+), 12 deletions(-)

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

[PATCH 3/3] [media] v4l2-dv-timings.h: let kernel-doc parte the typedef argument

[Mauro Carvalho Chehab]

Now that scripts/kernel-doc was fixed to parse the typedef
argument used here, let it produce documentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-dv-timings.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/media/v4l2-dv-timings.h b/include/media/v4l2-dv-timings.h
index 65caadf13eec..0a7d9e1fc8c8 100644
--- a/include/media/v4l2-dv-timings.h
+++ b/include/media/v4l2-dv-timings.h
@@ -28,8 +28,8 @@
  */
 extern const struct v4l2_dv_timings v4l2_dv_timings_presets[];
 
-/*
- * v4l2_check_dv_timings_fnc - timings check callback
+/**
+ * typedef v4l2_check_dv_timings_fnc - timings check callback
  *
  * @t: the v4l2_dv_timings struct.
  * @handle: a handle from the driver.
-- 
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

[PATCH 1/3] docs-rst: improve typedef parser

[Mauro Carvalho Chehab]

Improve the parser to handle typedefs like:

typedef bool v4l2_check_dv_timings_fnc(const struct v4l2_dv_timings *t, 
void *handle);

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kernel-doc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index bac0af4fc659..d94870270d8e 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2191,7 +2191,9 @@ sub dump_typedef($$) {
 $x =~ s@/\*.*?\*/@@gos;# strip comments.
 
 # Parse function prototypes
-if ($x =~ /typedef\s+(\w+)\s*\(\*\s*(\w\S+)\s*\)\s*\((.*)\);/) {
+if ($x =~ /typedef\s+(\w+)\s*\(\*\s*(\w\S+)\s*\)\s*\((.*)\);/ ||
+   $x =~ /typedef\s+(\w+)\s*(\w\S+)\s*\s*\((.*)\);/) {
+
# Function typedefs
$return_type = $1;
$declaration_name = $2;
-- 
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

[PATCH 2/3] docs-rst: kernel-doc: fix typedef output in RST format

[Mauro Carvalho Chehab]

When using a typedef function like this one:
typedef bool v4l2_check_dv_timings_fnc (const struct v4l2_dv_timings * 
t, void * handle);

The Sphinx C domain expects it to create a c:type: reference,
as that's the way it creates the type references when parsing
a c:function:: declaration.

So, a declaration like:

.. c:function:: bool v4l2_valid_dv_timings (const struct 
v4l2_dv_timings * t, const struct v4l2_dv_timings_cap * cap, 
v4l2_check_dv_timings_fnc fnc, void * fnc_handle)

Will create a cross reference for :c:type:`v4l2_check_dv_timings_fnc`.

So, when outputting such typedefs in RST format, we need to handle
this special case, as otherwise it will produce those warnings:

./include/media/v4l2-dv-timings.h:43: WARNING: c:type reference target 
not found: v4l2_check_dv_timings_fnc
./include/media/v4l2-dv-timings.h:60: WARNING: c:type reference target 
not found: v4l2_check_dv_timings_fnc
./include/media/v4l2-dv-timings.h:81: WARNING: c:type reference target 
not found: v4l2_check_dv_timings_fnc

So, change the kernel-doc script to produce a RST output for the
above typedef as:
.. c:type:: v4l2_check_dv_timings_fnc

   **Typedef**: timings check callback

**Syntax**

  ``bool v4l2_check_dv_timings_fnc (const struct v4l2_dv_timings * t, 
void * handle);``

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kernel-doc | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index d94870270d8e..091e49167b44 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1831,13 +1831,22 @@ sub output_function_rst(%) {
 my %args = %{$_[0]};
 my ($parameter, $section);
 my $oldprefix = $lineprefix;
-my $start;
+my $start = "";
 
-print ".. c:function:: ";
+if ($args{'typedef'}) {
+   print ".. c:type:: ". $args{'function'} . "\n\n";
+   print_lineno($declaration_start_line);
+   print "   **Typedef**: ";
+   $lineprefix = "";
+   output_highlight_rst($args{'purpose'});
+   $start = "\n\n**Syntax**\n\n  ``";
+} else {
+   print ".. c:function:: ";
+}
 if ($args{'functiontype'} ne "") {
-   $start = $args{'functiontype'} . " " . $args{'function'} . " (";
+   $start .= $args{'functiontype'} . " " . $args{'function'} . " (";
 } else {
-   $start = $args{'function'} . " (";
+   $start .= $args{'function'} . " (";
 }
 print $start;
 
@@ -1857,11 +1866,15 @@ sub output_function_rst(%) {
$count++;
}
 }
-print ")\n\n";
-print_lineno($declaration_start_line);
-$lineprefix = "   ";
-output_highlight_rst($args{'purpose'});
-print "\n";
+if ($args{'typedef'}) {
+   print ");``\n\n";
+} else {
+   print ")\n\n";
+   print_lineno($declaration_start_line);
+   $lineprefix = "   ";
+   output_highlight_rst($args{'purpose'});
+   print "\n";
+}
 
 print "**Parameters**\n\n";
 $lineprefix = "  ";
@@ -2204,6 +2217,7 @@ sub dump_typedef($$) {
output_declaration($declaration_name,
   'function',
   {'function' => $declaration_name,
+   'typedef' => 1,
'module' => $modulename,
'functiontype' => $return_type,
'parameterlist' => \@parameterlist,
-- 
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: [PATCH 1/2] [media] tw5864-core: remove double irq lock code

[Andrey Utkin]

Hi Mauro,
Have you received my letter which is cited below?
I also tried to get in touch with you on #linuxtv.

On Thu, Aug 25, 2016 at 05:46:06PM +0300, Andrey Utkin wrote:
> For some reason (maybe "unlisted recipients"?), my reply didn't get
> through to maillists. Resending my reply.
> 
> On Wed, Aug 24, 2016, at 19:30, Mauro Carvalho Chehab wrote:
> > As warned by smatch:
> > drivers/media/pci/tw5864/tw5864-core.c:160 tw5864_h264_isr() error: 
> > double lock 'irqsave:flags'
> > drivers/media/pci/tw5864/tw5864-core.c:174 tw5864_h264_isr() error: 
> > double unlock 'irqsave:flags'
> > 
> > Remove the IRQ duplicated lock.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/pci/tw5864/tw5864-core.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/media/pci/tw5864/tw5864-core.c
> > b/drivers/media/pci/tw5864/tw5864-core.c
> > index 440cd7bb8d04..e3d884e963c0 100644
> > --- a/drivers/media/pci/tw5864/tw5864-core.c
> > +++ b/drivers/media/pci/tw5864/tw5864-core.c
> > @@ -157,12 +157,10 @@ static void tw5864_h264_isr(struct tw5864_dev *dev)
> >  
> > cur_frame = next_frame;
> >  
> > -   spin_lock_irqsave(>slock, flags);
> > input->frame_seqno++;
> > input->frame_gop_seqno++;
> > if (input->frame_gop_seqno >= input->gop)
> > input->frame_gop_seqno = 0;
> > -   spin_unlock_irqrestore(>slock, flags);
> > } else {
> > dev_err(>pci->dev,
> > "Skipped frame on input %d because all buffers busy\n",
> 
> 
> Thank you very much for catching this issue, but NACK on the patch.
> 
> These two lock operations are on different spinlocks. One for device,
> another
> one for input (a subordinate entity of device). What is superfluous here
> is
> second _irqsave. Also "flags" variable reuse is wrong. So what would be
> right,
> in my opinion, is the following (going to submit this patch):
> 
> diff --git a/drivers/media/pci/tw5864/tw5864-core.c
> b/drivers/media/pci/tw5864/tw5864-core.c
> index 440cd7b..1d43b96 100644
> --- a/drivers/media/pci/tw5864/tw5864-core.c
> +++ b/drivers/media/pci/tw5864/tw5864-core.c
> @@ -157,12 +157,12 @@ static void tw5864_h264_isr(struct tw5864_dev
> *dev)
>  
>   cur_frame = next_frame;
>  
> -   spin_lock_irqsave(>slock, flags);
> +   spin_lock(>slock);
>   input->frame_seqno++;
>   input->frame_gop_seqno++;
>   if (input->frame_gop_seqno >= input->gop)
>   input->frame_gop_seqno = 0;
> -   spin_unlock_irqrestore(>slock, flags);
> +   spin_unlock(>slock);
>   } else {
>   dev_err(>pci->dev,
>   "Skipped frame on input %d because all buffers
>   busy\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
--
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: musb: isoc pkt loss with pwc

[Matwey V. Kornilov]

2016-08-30 21:30 GMT+03:00 Bin Liu :
> Hi,
>
> On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> Hello Bin,
>>
>> I would like to start new thread on my issue. Let me recall where the issue 
>> is:
>> There is 100% frame lost in pwc webcam driver due to lots of
>> zero-length packages coming from musb driver.
>
> What is the video resolution and fps?

640x480 YUV420 10 frames per second.
pwc uses proprietary compression during device-host transmission, but
I don't know how effective it is.

>
>> The issue is present in all kernels (including 4.8) starting from the commit:
>>
>> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
>> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")
>
> What is the behavior without this commit?

Without this commit all frames are being received correctly. Single
one issue is a number of zero byte package at the beginning of iso
stream (probably during camera internal sync, I have to check how the
stream is started on x86 later). But they are never repeated after
this.

>>
>> The issue is here both when DMA enabled and DMA disabled.
>>
>> Attached here is a plot. The vertical axis designates the value of
>> rx_count variable from function musb_host_packet_rx(). One may see
>> that there are only two possibilities: 0 bytes and 956 bytes.
>> The horizontal axis is the last three digits of the timestamp when
>> musb_host_packet_rx() invoked. I.e for [   38.115379] it is 379. Given
>> that my webcam is USB 1.1 and base time is 1 ms, then all frames
>> should be grouped close to some single value. (Repeating package
>> receive event every 1 ms won't change last tree digits considerably)
>> One may see that it is not true, in practice there are two groups. And
>> receive time strongly correlates with the package size. Packages
>> received near round ms are 956 bytes long, packages received near 400
>> us are 0 bytes long.
>
> When the host IN packet passed the deadline, the device drops the video
> data, so device only sends 0 byte packet (or 12 bytes which is only the
> uvc header without data payload).

Doesn't it mean that free part of the frame, i.e (1 msec - (t_IN -
t_SOF)) is not enough to transmit 956 bytes in device firmware
opinion?

>
>>
>> I don't know how exactly SOF and IN are synchronized in musb, could
>> someone give a hint? But from what I see the time difference between
>> subsequent IN package requests is sometimes more than 1 ms due to
>> heavy urb->complete() callback. After such events only zero length
>
> Why musb delayed the IN packets, it needs to be investigated.  I will
> start to look at this webcam issue with musb soon, after I cleaned up
> the musb patches queued recently. I will update once I have progress in
> my investigation.

The last package in URB has different code path.
IN after the last package of URB is not requested in musb_host_packet_rx().
Instead, IN request is performed in the end of musb_advance_schedule()
by musb_start_urb().
musb_advance_schedule() has the following code:

qh->is_ready = 0;
musb_giveback(musb, urb, status);
qh->is_ready = ready;

Which can be executed pretty long if urb->complete() handler is not
postphoned by HCD_BH.
In my case, it takes about 300 us for pwc urb->complete() to run.
Probably, the logic should be modified here, to run giveback on
current URB after the start of next URB.

>
>> packages are received. Surprisingly, that `synchronization' is
>> recovered sometimes in the middle of URB like the following:
>>
>> [  163.207363] musb int
>> [  163.207380] rx_count 0
>> [  163.207393] req pkt c9c76200 // Expected musb int at 163.208393
>> [  163.207403] int end
>> // No interrupt at 163.208393
>> [  163.209001] musb int
>> [  163.209017] rx_count 956
>> [  163.209108] req pkt c9c76200
>> [  163.209118] int end
>
> It looks like you used plain printk for these debug logs, which normally
> is not a good idea for this type of performance debugging. printk
> changes timing especially if the log is printed via uart console.
>

I think next time I will use tracepoints or something like that. Thank
you for pointing.

>> And then the series of 956 bytes long packages are received until URB
>> giveback will occasionally break it again.
>> Do I understand correctly, that SOF is generated every 1 ms by
>> hardware and should be followed by IN immediately?
>
> My understanding is that is does not have to be 'immediately', for
> example, in a few ns, it should be okay as long as the interval of IN
> packets is fixed, but I forgot what the tolerance is, I haven't read the
> related Specs for a long time.

But, If IN is postponed by 500 usec, then it means that half of frame
is wasted for isochronous transmission. Right?

>
>> If so, it is not clear to me how they should be aligned when the time
>> difference between to subsequent INs is greater than 1ms.
>
> It is up to the device firmware, which should have an internal clock to
> sync 

Re: musb: isoc pkt loss with pwc

[Bin Liu]

Hi,

On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
> Hello Bin,
> 
> I would like to start new thread on my issue. Let me recall where the issue 
> is:
> There is 100% frame lost in pwc webcam driver due to lots of
> zero-length packages coming from musb driver.

What is the video resolution and fps?

> The issue is present in all kernels (including 4.8) starting from the commit:
> 
> f551e13529833e052f75ec628a8af7b034af20f9 ("Revert "usb: musb:
> musb_host: Enable HCD_BH flag to handle urb return in bottom half"")

What is the behavior without this commit?
> 
> The issue is here both when DMA enabled and DMA disabled.
> 
> Attached here is a plot. The vertical axis designates the value of
> rx_count variable from function musb_host_packet_rx(). One may see
> that there are only two possibilities: 0 bytes and 956 bytes.
> The horizontal axis is the last three digits of the timestamp when
> musb_host_packet_rx() invoked. I.e for [   38.115379] it is 379. Given
> that my webcam is USB 1.1 and base time is 1 ms, then all frames
> should be grouped close to some single value. (Repeating package
> receive event every 1 ms won't change last tree digits considerably)
> One may see that it is not true, in practice there are two groups. And
> receive time strongly correlates with the package size. Packages
> received near round ms are 956 bytes long, packages received near 400
> us are 0 bytes long.

When the host IN packet passed the deadline, the device drops the video
data, so device only sends 0 byte packet (or 12 bytes which is only the
uvc header without data payload).

> 
> I don't know how exactly SOF and IN are synchronized in musb, could
> someone give a hint? But from what I see the time difference between
> subsequent IN package requests is sometimes more than 1 ms due to
> heavy urb->complete() callback. After such events only zero length

Why musb delayed the IN packets, it needs to be investigated.  I will
start to look at this webcam issue with musb soon, after I cleaned up
the musb patches queued recently. I will update once I have progress in
my investigation.

> packages are received. Surprisingly, that `synchronization' is
> recovered sometimes in the middle of URB like the following:
> 
> [  163.207363] musb int
> [  163.207380] rx_count 0
> [  163.207393] req pkt c9c76200 // Expected musb int at 163.208393
> [  163.207403] int end
> // No interrupt at 163.208393
> [  163.209001] musb int
> [  163.209017] rx_count 956
> [  163.209108] req pkt c9c76200
> [  163.209118] int end

It looks like you used plain printk for these debug logs, which normally
is not a good idea for this type of performance debugging. printk
changes timing especially if the log is printed via uart console.

> And then the series of 956 bytes long packages are received until URB
> giveback will occasionally break it again.
> Do I understand correctly, that SOF is generated every 1 ms by
> hardware and should be followed by IN immediately?

My understanding is that is does not have to be 'immediately', for
example, in a few ns, it should be okay as long as the interval of IN
packets is fixed, but I forgot what the tolerance is, I haven't read the
related Specs for a long time.

> If so, it is not clear to me how they should be aligned when the time
> difference between to subsequent INs is greater than 1ms.

It is up to the device firmware, which should have an internal clock to
sync the received IN packets, and adjust the data payload to be send.
This is the basics in video/audio applications.

Regards,
-Bin.

> 
> -- 
> With best regards,
> Matwey V. Kornilov.
> Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
> 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382


--
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/28] media: don't print error when allocating urb fails

[Greg KH]

On Thu, Aug 11, 2016 at 11:03:36PM +0200, Wolfram Sang wrote:
> This per-subsystem series is part of a tree wide cleanup. usb_alloc_urb() uses
> kmalloc which already prints enough information on failure. So, let's simply
> remove those "allocation failed" messages from drivers like we did already for
> other -ENOMEM cases. gkh acked this approach when we talked about it at LCJ in
> Tokyo a few weeks ago.

I've taken all of these through the usb tree given the delay in response
from the media developers :)

thanks,

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

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

[Rob Clark]

Tom,

hmm, I wonder if it was a bug/oversight for the YUV capabilities of
this extension to not depend on OES_EGL_image_external (which
unfortunately, doesn't seem to have a GL counterpart)?

I think this currently implies that you could sample from an imported
YUV eglimg using (for example) sampler2D in GL or GLES, which I think
was not the intention.

BR,
-R

On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  wrote:
> Hi All,
>
> The final spec has had enum values assigned and been published on Khronos:
>
> http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>
> Thanks to all who've provided input.
>
>
> Cheers,
>
> Tom
>
>
>
>> -Original Message-
>> From: mesa-dev-bounces+tom.cooksey=arm@lists.freedesktop.org 
>> [mailto:mesa-dev-
>> bounces+tom.cooksey=arm@lists.freedesktop.org] On Behalf Of Tom Cooksey
>> Sent: 04 October 2012 13:10
>> To: mesa-...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; dri-
>> de...@lists.freedesktop.org; linux-media@vger.kernel.org
>> Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft!
>>
>> Hi All,
>>
>> After receiving a fair bit of feedback (thanks!), I've updated the
>> EGL_EXT_image_dma_buf_import spec
>> and expanded it to resolve a number of the issues. Please find the latest 
>> draft below and let
>> me
>> know any additional feedback you might have, either on the lists or by 
>> private e-mail - I
>> don't mind
>> which.
>>
>> I think the only remaining issue now is if we need a mechanism whereby an 
>> application can
>> query
>> which drm_fourcc.h formats EGL supports or if just failing with 
>> EGL_BAD_MATCH when the
>> application
>> has use one EGL doesn't support is sufficient. Any thoughts?
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>> 8<
>>
>>
>> Name
>>
>> EXT_image_dma_buf_import
>>
>> Name Strings
>>
>> EGL_EXT_image_dma_buf_import
>>
>> Contributors
>>
>> Jesse Barker
>> Rob Clark
>> Tom Cooksey
>>
>> Contacts
>>
>> Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)
>> Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com)
>>
>> Status
>>
>> DRAFT
>>
>> Version
>>
>> Version 4, October 04, 2012
>>
>> Number
>>
>> EGL Extension ???
>>
>> Dependencies
>>
>> EGL 1.2 is required.
>>
>> EGL_KHR_image_base is required.
>>
>> The EGL implementation must be running on a Linux kernel supporting the
>> dma_buf buffer sharing mechanism.
>>
>> This extension is written against the wording of the EGL 1.2 
>> Specification.
>>
>> Overview
>>
>> This extension allows creating an EGLImage from a Linux dma_buf file
>> descriptor or multiple file descriptors in the case of multi-plane YUV
>> images.
>>
>> New Types
>>
>> None
>>
>> New Procedures and Functions
>>
>> None
>>
>> New Tokens
>>
>> Accepted by the  parameter of eglCreateImageKHR:
>>
>> EGL_LINUX_DMA_BUF_EXT
>>
>> Accepted as an attribute in the  parameter of
>> eglCreateImageKHR:
>>
>> EGL_LINUX_DRM_FOURCC_EXT
>> EGL_DMA_BUF_PLANE0_FD_EXT
>> EGL_DMA_BUF_PLANE0_OFFSET_EXT
>> EGL_DMA_BUF_PLANE0_PITCH_EXT
>> EGL_DMA_BUF_PLANE1_FD_EXT
>> EGL_DMA_BUF_PLANE1_OFFSET_EXT
>> EGL_DMA_BUF_PLANE1_PITCH_EXT
>> EGL_DMA_BUF_PLANE2_FD_EXT
>> EGL_DMA_BUF_PLANE2_OFFSET_EXT
>> EGL_DMA_BUF_PLANE2_PITCH_EXT
>> EGL_YUV_COLOR_SPACE_HINT_EXT
>> EGL_SAMPLE_RANGE_HINT_EXT
>> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
>>
>> Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute:
>>
>> EGL_ITU_REC601_EXT
>> EGL_ITU_REC709_EXT
>> EGL_ITU_REC2020_EXT
>>
>> Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute:
>>
>> EGL_YUV_FULL_RANGE_EXT
>> EGL_YUV_NARROW_RANGE_EXT
>>
>> Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT &
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes:
>>
>> EGL_YUV_CHROMA_SITING_0_EXT
>> EGL_YUV_CHROMA_SITING_0_5_EXT
>>
>>
>> Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation)
>>
>> Add to section 2.5.1 "EGLImage Specification" (as defined by the
>> EGL_KHR_image_base specification), in the description of
>> eglCreateImageKHR:
>>
>>"Values accepted for  are listed in Table aaa, below.
>>
>>   
>> +-++
>>   | |  Notes 
>> |
>>   
>> +-++
>>   |  EGL_LINUX_DMA_BUF_EXT  |   Used for EGLImages imported from Linux   
>> |
>>   | |   dma_buf file descriptors 
>> |
>>   
>> +-++
>> 

Re: [PATCH v5 01/13] media: mt9m111: make a standalone v4l2 subdevice

[Robert Jarzmik]

Guennadi Liakhovetski  writes:

> Hi Robert,
>
> On Mon, 29 Aug 2016, Robert Jarzmik wrote:
>
>> Remove the soc_camera adherence. Mostly the change removes the power
>> manipulation provided by soc_camera, and instead :
>>  - powers on the sensor when the s_power control is activated
>>  - powers on the sensor in initial probe
>>  - enables and disables the MCLK provided to it in power on/off
>
> Your patch also drops support for inverters on synchronisation and clock 
> lines, I guess, your board doesn't use any. I assume, if any board ever 
> needs such inverters, support for them can be added in the future.
Ah yeah, that would deserve a notice in the commit message.

It's a bit a pity to respin the whole serie for it, but you've got a fair
point. Maybe Hans would agree to apply 4/13 to 13/13 (if there is no comment
remaining), and let me respin the 3 patches around mtm9111.

> Also, as I mentioned in my reply to your other patch, maybe good to join this
> with #3. Otherwise and with that in mind
I'd like to keep the move separate from the remaining part. And yes, I should
have used the "-M" option ... I added it to my submission script so that I don't
forget it again :)

Thanks for the Ack, and cheers.

--
Robert
--
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: [STLinux Kernel] [PATCH v5 0/3] support of v4l2 encoder for STMicroelectronics SOC

[Jean Christophe TROTIN]

Hi Peter,

First of all, thanks for your answer.
Sorry for the mistake: I missed your first "acked-by" on the version 4 (it 
seems that I have to review the rules that classify my emails!).
I wait for some other comments about the version 5, and I will add your 
"acked-by" in the next version.

Regards,
JC.

Jean-Christophe TROTIN | TINA: 1667397 | Tel: +33 244027397 | Mobile: +33 
624726135

STMicroelectronics
9-11 rue Pierre-Félix Delarue | 72100 Le Mans | France
ST online: www.st.com


-Original Message-
From: Peter Griffin [mailto:peter.grif...@linaro.org] 
Sent: mardi 30 août 2016 12:24
To: Jean Christophe TROTIN 
Cc: linux-media@vger.kernel.org; Hans Verkuil ; Yannick 
FERTRE ; ker...@stlinux.com; Benjamin Gaignard 

Subject: Re: [STLinux Kernel] [PATCH v5 0/3] support of v4l2 encoder for 
STMicroelectronics SOC

Hi Jean-Christophe,

On Mon, 29 Aug 2016, Jean-Christophe Trotin wrote:

> version 5:
> - Compilation problem with 4.8-rc1 corrected: unsigned long used for dma_attrs
> - The video bitrate (V4L2_CID_MPEG_VIDEO_BITRATE) and the CPB size 
> (V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE) were respectively considered in kbps and 
> kb, while the V4L2 API specifies them in bps and kB. This is corrected and 
> the code is now aligned with the V4L2 specification
> - If the encoder close function (enc->close) has not been called through 
> hva_stop_streaming (e.g. application is killed), it's called at the encoder 
> instance release (hva_release)
> - hva-v4l2.c: DEFAULT_* renamed HVA_DEFAULT_*
> - hva-v4l2.c: few log messages modified
> - typos corrected
> - V4L2 compliance successfully passed with this version (see report below)
> 

Looks like you forgot to add my: -

 Acked-by: Peter Griffin 

regards,

Peter.
--
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 2/2] pulse8-cec: store logical address mask

[Johan Fjeldtvedt]

In addition to setting the ACK mask, also set the logical address mask
setting in the dongle. This is (and not the ACK mask) is persisted for
use in autonomous mode.

The logical address mask to use is deduced from the primary device type
in adap->log_addrs.

Signed-off-by: Johan Fjeldtvedt 
---
 drivers/staging/media/pulse8-cec/pulse8-cec.c | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/drivers/staging/media/pulse8-cec/pulse8-cec.c 
b/drivers/staging/media/pulse8-cec/pulse8-cec.c
index 1158ba9..ede285a 100644
--- a/drivers/staging/media/pulse8-cec/pulse8-cec.c
+++ b/drivers/staging/media/pulse8-cec/pulse8-cec.c
@@ -498,6 +498,40 @@ static int pulse8_cec_adap_log_addr(struct cec_adapter 
*adap, u8 log_addr)
if (err)
goto unlock;
 
+   switch (adap->log_addrs.primary_device_type[0]) {
+   case CEC_OP_PRIM_DEVTYPE_TV:
+   mask = 0;
+   break;
+   case CEC_OP_PRIM_DEVTYPE_RECORD:
+   mask = 0x206;
+   break;
+   case CEC_OP_PRIM_DEVTYPE_TUNER:
+   mask = 0x4C8;
+   break;
+   case CEC_OP_PRIM_DEVTYPE_PLAYBACK:
+   mask = 0x910;
+   break;
+   case CEC_OP_PRIM_DEVTYPE_AUDIOSYSTEM:
+   mask = 0x20;
+   break;
+   case CEC_OP_PRIM_DEVTYPE_SWITCH:
+   mask = 0x8000;
+   break;
+   case CEC_OP_PRIM_DEVTYPE_PROCESSOR:
+   mask = 0x4000;
+   break;
+   default:
+   mask = 0;
+   break;
+   }
+   cmd[0] = MSGCODE_SET_LOGICAL_ADDRESS_MASK;
+   cmd[1] = mask >> 8;
+   cmd[2] = mask & 0xff;
+   err = pulse8_send_and_wait(pulse8, cmd, 3,
+  MSGCODE_COMMAND_ACCEPTED, 0);
+   if (err)
+   goto unlock;
+
cmd[0] = MSGCODE_SET_DEFAULT_LOGICAL_ADDRESS;
cmd[1] = log_addr;
err = pulse8_send_and_wait(pulse8, cmd, 2,
-- 
2.9.3

--
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] pulse8-cec: fixes

[Johan Fjeldtvedt]

Fix some small things:
- clean up setup function
- use MSGEND instead of 0xfe
- don't assign "return value" from cec_phys_addr to err,
  it has return type void.

Signed-off-by: Johan Fjeldtvedt 
---
 drivers/staging/media/pulse8-cec/pulse8-cec.c | 33 ---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/media/pulse8-cec/pulse8-cec.c 
b/drivers/staging/media/pulse8-cec/pulse8-cec.c
index 193f4d1..1158ba9 100644
--- a/drivers/staging/media/pulse8-cec/pulse8-cec.c
+++ b/drivers/staging/media/pulse8-cec/pulse8-cec.c
@@ -266,7 +266,7 @@ static int pulse8_send(struct serio *serio, const u8 
*command, u8 cmd_len)
}
}
if (!err)
-   err = serio_write(serio, 0xfe);
+   err = serio_write(serio, MSGEND);
 
return err;
 }
@@ -331,40 +331,29 @@ static int pulse8_setup(struct pulse8 *pulse8, struct 
serio *serio,
u8 *data = pulse8->data + 1;
u8 cmd[2];
int err;
+   struct tm tm;
+   time_t date;
 
pulse8->vers = 0;
 
-   cmd[0] = MSGCODE_PING;
-   err = pulse8_send_and_wait(pulse8, cmd, 1,
-  MSGCODE_COMMAND_ACCEPTED, 0);
cmd[0] = MSGCODE_FIRMWARE_VERSION;
-   if (!err)
-   err = pulse8_send_and_wait(pulse8, cmd, 1, cmd[0], 2);
+   err = pulse8_send_and_wait(pulse8, cmd, 1, cmd[0], 2);
if (err)
return err;
-
pulse8->vers = (data[0] << 8) | data[1];
-
dev_info(pulse8->dev, "Firmware version %04x\n", pulse8->vers);
if (pulse8->vers < 2)
return 0;
 
cmd[0] = MSGCODE_GET_BUILDDATE;
-   if (!err)
-   err = pulse8_send_and_wait(pulse8, cmd, 1, cmd[0], 4);
-   if (!err) {
-   time_t date = (data[0] << 24) | (data[1] << 16) |
-   (data[2] << 8) | data[3];
-   struct tm tm;
-
-   time_to_tm(date, 0, );
-
-   dev_info(pulse8->dev, "Firmware build date %04ld.%02d.%02d 
%02d:%02d:%02d\n",
-tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
-tm.tm_hour, tm.tm_min, tm.tm_sec);
-   }
+   err = pulse8_send_and_wait(pulse8, cmd, 1, cmd[0], 4);
if (err)
return err;
+   date = (data[0] << 24) | (data[1] << 16) | (data[2] << 8) | data[3];
+   time_to_tm(date, 0, );
+   dev_info(pulse8->dev, "Firmware build date %04ld.%02d.%02d 
%02d:%02d:%02d\n",
+tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+tm.tm_hour, tm.tm_min, tm.tm_sec);
 
dev_dbg(pulse8->dev, "Persistent config:\n");
cmd[0] = MSGCODE_GET_AUTO_ENABLED;
@@ -456,8 +445,6 @@ static int pulse8_apply_persistent_config(struct pulse8 
*pulse8,
return err;
 
cec_s_phys_addr(pulse8->adap, pa, false);
-   if (err)
-   return err;
 
return 0;
 }
-- 
2.9.3

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

[PATCH v5 1/5] VPU: mediatek: Add mdp support

[Minghsiu Tsai]

VPU driver add mdp support

Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/mtk-vpu/mtk_vpu.h |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.h 
b/drivers/media/platform/mtk-vpu/mtk_vpu.h
index f457479..291ae46 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.h
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.h
@@ -53,6 +53,8 @@ typedef void (*ipi_handler_t) (void *data,
 handle H264 video encoder job, and vice versa.
  * @IPI_VENC_VP8:   The interrupt fro vpu is to notify kernel to
 handle VP8 video encoder job,, and vice versa.
+ * @IPI_MDP:The interrupt from vpu is to notify kernel to
+handle MDP (Media Data Path) job, and vice versa.
  * @IPI_MAX:The maximum IPI number
  */
 
@@ -63,6 +65,7 @@ enum ipi_id {
IPI_VDEC_VP9,
IPI_VENC_H264,
IPI_VENC_VP8,
+   IPI_MDP,
IPI_MAX,
 };
 
@@ -71,11 +74,13 @@ enum ipi_id {
  *
  * @VPU_RST_ENC: encoder reset id
  * @VPU_RST_DEC: decoder reset id
+ * @VPU_RST_MDP: MDP (Media Data Path) reset id
  * @VPU_RST_MAX: maximum reset id
  */
 enum rst_id {
VPU_RST_ENC,
VPU_RST_DEC,
+   VPU_RST_MDP,
VPU_RST_MAX,
 };
 
-- 
1.7.9.5

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

[PATCH v5 2/5] dt-bindings: Add a binding for Mediatek MDP

[Minghsiu Tsai]

Add a DT binding documentation of MDP for the MT8173 SoC
from Mediatek

Signed-off-by: Minghsiu Tsai 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/mediatek-mdp.txt |  109 
 1 file changed, 109 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
new file mode 100644
index 000..4182063
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -0,0 +1,109 @@
+* Mediatek Media Data Path
+
+Media Data Path is used for scaling and color space conversion.
+
+Required properties (controller (parent) node):
+- compatible: "mediatek,mt8173-mdp"
+- mediatek,vpu: the node of video processor unit, see
+  Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
+
+Required properties (all function blocks, child node):
+- compatible: Should be one of
+"mediatek,mt8173-mdp-rdma"  - read DMA
+"mediatek,mt8173-mdp-rsz"   - resizer
+"mediatek,mt8173-mdp-wdma"  - write DMA
+"mediatek,mt8173-mdp-wrot"  - write DMA with rotation
+- reg: Physical base address and length of the function block register space
+- clocks: device clocks, see
+  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- power-domains: a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+
+Required properties (DMA function blocks, child node):
+- compatible: Should be one of
+"mediatek,mt8173-mdp-rdma"
+"mediatek,mt8173-mdp-wdma"
+"mediatek,mt8173-mdp-wrot"
+- iommus: should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+- mediatek,larb: must contain the local arbiters in the current Socs, see
+  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+  for details.
+
+Example:
+mdp {
+   compatible = "mediatek,mt8173-mdp";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   mediatek,vpu = <>;
+
+   mdp_rdma0: rdma@14001000 {
+   compatible = "mediatek,mt8173-mdp-rdma";
+   reg = <0 0x14001000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RDMA0>,
+< CLK_MM_MUTEX_32K>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_RDMA0>;
+   mediatek,larb = <>;
+   };
+
+   mdp_rdma1: rdma@14002000 {
+   compatible = "mediatek,mt8173-mdp-rdma";
+   reg = <0 0x14002000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RDMA1>,
+< CLK_MM_MUTEX_32K>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_RDMA1>;
+   mediatek,larb = <>;
+   };
+
+   mdp_rsz0: rsz@14003000 {
+   compatible = "mediatek,mt8173-mdp-rsz";
+   reg = <0 0x14003000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RSZ0>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   };
+
+   mdp_rsz1: rsz@14004000 {
+   compatible = "mediatek,mt8173-mdp-rsz";
+   reg = <0 0x14004000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RSZ1>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   };
+
+   mdp_rsz2: rsz@14005000 {
+   compatible = "mediatek,mt8173-mdp-rsz";
+   reg = <0 0x14005000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RSZ2>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   };
+
+   mdp_wdma0: wdma@14006000 {
+   compatible = "mediatek,mt8173-mdp-wdma";
+   reg = <0 0x14006000 0 0x1000>;
+   clocks = < CLK_MM_MDP_WDMA>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_WDMA>;
+   mediatek,larb = <>;
+   };
+
+   mdp_wrot0: wrot@14007000 {
+   compatible = "mediatek,mt8173-mdp-wrot";
+   reg = <0 0x14007000 0 0x1000>;
+   clocks = < CLK_MM_MDP_WROT0>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_WROT0>;
+   mediatek,larb = <>;
+   };
+
+   mdp_wrot1: wrot@14008000 {
+   compatible = "mediatek,mt8173-mdp-wrot";
+   reg = <0 0x14008000 0 0x1000>;
+   clocks = < CLK_MM_MDP_WROT1>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_WROT1>;
+   mediatek,larb = <>;
+   };
+};
-- 
1.7.9.5

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

[PATCH v5 5/5] media: mtk-mdp: support pixelformat V4L2_PIX_FMT_MT21C

[Minghsiu Tsai]

Add V4L2_PIX_FMT_MT21C in format list.

Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  |8 
 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c |4 
 2 files changed, 12 insertions(+)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 927132a..0184dbe 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -54,6 +54,14 @@ static struct mtk_mdp_pix_align mtk_mdp_size_align = {
 
 static const struct mtk_mdp_fmt mtk_mdp_formats[] = {
{
+   .pixelformat= V4L2_PIX_FMT_MT21C,
+   .depth  = { 8, 4 },
+   .row_depth  = { 8, 8 },
+   .num_planes = 2,
+   .num_comp   = 2,
+   .align  = _mdp_size_align,
+   .flags  = MTK_MDP_FMT_FLAG_OUTPUT,
+   }, {
.pixelformat= V4L2_PIX_FMT_NV12M,
.depth  = { 8, 4 },
.row_depth  = { 8, 8 },
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_regs.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
index a5601e1..86d57f3 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
@@ -29,6 +29,8 @@ enum MDP_COLOR_ENUM {
MDP_COLOR_NV12 = MDP_COLORFMT_PACK(0, 2, 1, 1, 1, 8, 1, 0, 12),
MDP_COLOR_I420 = MDP_COLORFMT_PACK(0, 3, 0, 1, 1, 8, 1, 0, 8),
MDP_COLOR_YV12 = MDP_COLORFMT_PACK(0, 3, 0, 1, 1, 8, 1, 1, 8),
+   /* Mediatek proprietary format */
+   MDP_COLOR_420_MT21 = MDP_COLORFMT_PACK(5, 2, 1, 1, 1, 256, 1, 0, 12),
 };
 
 static int32_t mtk_mdp_map_color_format(int v4l2_format)
@@ -37,6 +39,8 @@ static int32_t mtk_mdp_map_color_format(int v4l2_format)
case V4L2_PIX_FMT_NV12M:
case V4L2_PIX_FMT_NV12:
return MDP_COLOR_NV12;
+   case V4L2_PIX_FMT_MT21C:
+   return MDP_COLOR_420_MT21;
case V4L2_PIX_FMT_YUV420M:
case V4L2_PIX_FMT_YUV420:
return MDP_COLOR_I420;
-- 
1.7.9.5

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

[PATCH v5 3/5] media: Add Mediatek MDP Driver

[Minghsiu Tsai]

Add MDP driver for MT8173

Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/Kconfig|   17 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/mtk-mdp/Makefile   |9 +
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c |  159 
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h |   72 ++
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c |  294 ++
 drivers/media/platform/mtk-mdp/mtk_mdp_core.h |  260 +
 drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h  |  126 +++
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  | 1270 +
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h  |   22 +
 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c |  152 +++
 drivers/media/platform/mtk-mdp/mtk_mdp_regs.h |   31 +
 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c  |  145 +++
 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h  |   41 +
 14 files changed, 2600 insertions(+)
 create mode 100644 drivers/media/platform/mtk-mdp/Makefile
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.c
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.h
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.h
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
 create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f25344b..0c88532 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -166,6 +166,23 @@ config VIDEO_MEDIATEK_VPU
To compile this driver as a module, choose M here: the
module will be called mtk-vpu.
 
+config VIDEO_MEDIATEK_MDP
+   tristate "Mediatek MDP driver"
+   depends on MTK_IOMMU || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   select VIDEO_MEDIATEK_VPU
+   default n
+   ---help---
+   It is a v4l2 driver and present in Mediatek MT8173 SoCs.
+   The driver supports for scaling and color space conversion.
+
+   To compile this driver as a module, choose M here: the
+   module will be called mtk-mdp.
+
 config VIDEO_MEDIATEK_VCODEC
tristate "Mediatek Video Codec driver"
depends on MTK_IOMMU || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 21771c1..221aace 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -63,3 +63,5 @@ ccflags-y += -I$(srctree)/drivers/media/i2c
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
diff --git a/drivers/media/platform/mtk-mdp/Makefile 
b/drivers/media/platform/mtk-mdp/Makefile
new file mode 100644
index 000..f802569
--- /dev/null
+++ b/drivers/media/platform/mtk-mdp/Makefile
@@ -0,0 +1,9 @@
+mtk-mdp-y += mtk_mdp_core.o
+mtk-mdp-y += mtk_mdp_comp.o
+mtk-mdp-y += mtk_mdp_m2m.o
+mtk-mdp-y += mtk_mdp_regs.o
+mtk-mdp-y += mtk_mdp_vpu.o
+
+obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp.o
+
+ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
new file mode 100644
index 000..aa8f9fd
--- /dev/null
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_mdp_comp.h"
+
+
+static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = {
+   "mdp_rdma",
+   "mdp_rsz",
+   "mdp_wdma",
+   "mdp_wrot",
+};
+
+struct mtk_mdp_comp_match {
+   enum mtk_mdp_comp_type type;
+   int alias_id;
+};
+
+static const struct mtk_mdp_comp_match mtk_mdp_matches[MTK_MDP_COMP_ID_MAX] = {
+   { MTK_MDP_RDMA, 0 },
+   { MTK_MDP_RDMA, 1 },
+   { 

[PATCH v5 0/5] Add MT8173 MDP Driver

[Minghsiu Tsai]

Changes in v5:
- Add ack in the comment of dts patch 
- Fix s/g_selection()
- Separate format V4L2_PIX_FMT_MT21C into new patch  

Changes in v4:
- Add "depends on HAS_DMA" in Kconfig.
- Fix s/g_selection()
- Replace struct v4l2_crop with u32 and struct v4l2_rect
- Remove VB2_USERPTR
- Move mutex lock after ctx allocation in mtk_mdp_m2m_open()
- Add new format V4L2_PIX_FMT_YVU420 to support software on Android platform.
- Only width/height of image in format V4L2_PIX_FMT_MT21 is aligned to 16/16,
  other ones are aligned to 2/2 by default

Changes in v3:
- Modify device ndoe as structured one.
- Fix conflict in dts on Linux 4.8-rc1

Changes in v2:
- Add section to describe blocks function in dts-bindings
- Remove the assignment of device_caps in querycap()
- Remove format's name assignment
- Copy colorspace-related parameters from OUTPUT to CAPTURE
- Use m2m helper functions
- Fix DMA allocation failure
- Initialize lazily vpu instance in streamon()

==
 Introduction
==

The purpose of this series is to add the driver for Media Data Path HW embedded 
in the Mediatek's MT8173 SoC.
MDP is used for scaling and color space conversion.

It could convert V4L2_PIX_FMT_MT21 to V4L2_PIX_FMT_NV12M or 
V4L2_PIX_FMT_YUV420M.

NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M

This patch series rely on MTK VPU driver in patch series "Add MT8173 Video 
Encoder Driver and VPU Driver"[1] and "Add MT8173 Video Decoder Driver"[2].
MDP driver rely on VPU driver to load, communicate with VPU.

Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both 
have been merged in v4.6-rc1.

[1]https://patchwork.kernel.org/patch/9002171/
[2]https://patchwork.kernel.org/patch/9141245/

==
 Device interface
==

In principle the driver bases on v4l2 memory-to-memory framework:
it provides a single video node and each opened file handle gets its own 
private context with separate buffer queues. Each context consist of 2 buffer 
queues: OUTPUT (for source buffers) and CAPTURE (for destination buffers).
OUTPUT and CAPTURE buffer could be MMAP or DMABUF memory type.

v4l2-compliance test output:
# v4l2-compliance -d /dev/image-proc0
v4l2-compliance SHA   : a737a6161485fffb70bf51e4fd7f6e2d910174c1

Driver Info:
Driver name   : mtk-mdp
Card type : soc:mdp
Bus info  : platform:mt8173
Driver version: 4.8.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/image-proc0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK

[PATCH v5 4/5] arm64: dts: mediatek: Add MDP for MT8173

[Minghsiu Tsai]

Add MDP node for MT8173

Signed-off-by: Minghsiu Tsai 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   84 ++
 1 file changed, 84 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 10f638f..cd93228 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -41,6 +41,14 @@
dpi0 = 
dsi0 = 
dsi1 = 
+   mdp_rdma0 = _rdma0;
+   mdp_rdma1 = _rdma1;
+   mdp_rsz0 = _rsz0;
+   mdp_rsz1 = _rsz1;
+   mdp_rsz2 = _rsz2;
+   mdp_wdma0 = _wdma0;
+   mdp_wrot0 = _wrot0;
+   mdp_wrot1 = _wrot1;
};
 
cpus {
@@ -716,6 +724,82 @@
#clock-cells = <1>;
};
 
+   mdp {
+   compatible = "mediatek,mt8173-mdp";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   mediatek,vpu = <>;
+
+   mdp_rdma0: rdma@14001000 {
+   compatible = "mediatek,mt8173-mdp-rdma";
+   reg = <0 0x14001000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RDMA0>,
+< CLK_MM_MUTEX_32K>;
+   power-domains = < 
MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_RDMA0>;
+   mediatek,larb = <>;
+   };
+
+   mdp_rdma1: rdma@14002000 {
+   compatible = "mediatek,mt8173-mdp-rdma";
+   reg = <0 0x14002000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RDMA1>,
+< CLK_MM_MUTEX_32K>;
+   power-domains = < 
MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_RDMA1>;
+   mediatek,larb = <>;
+   };
+
+   mdp_rsz0: rsz@14003000 {
+   compatible = "mediatek,mt8173-mdp-rsz";
+   reg = <0 0x14003000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RSZ0>;
+   power-domains = < 
MT8173_POWER_DOMAIN_MM>;
+   };
+
+   mdp_rsz1: rsz@14004000 {
+   compatible = "mediatek,mt8173-mdp-rsz";
+   reg = <0 0x14004000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RSZ1>;
+   power-domains = < 
MT8173_POWER_DOMAIN_MM>;
+   };
+
+   mdp_rsz2: rsz@14005000 {
+   compatible = "mediatek,mt8173-mdp-rsz";
+   reg = <0 0x14005000 0 0x1000>;
+   clocks = < CLK_MM_MDP_RSZ2>;
+   power-domains = < 
MT8173_POWER_DOMAIN_MM>;
+   };
+
+   mdp_wdma0: wdma@14006000 {
+   compatible = "mediatek,mt8173-mdp-wdma";
+   reg = <0 0x14006000 0 0x1000>;
+   clocks = < CLK_MM_MDP_WDMA>;
+   power-domains = < 
MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_WDMA>;
+   mediatek,larb = <>;
+   };
+
+   mdp_wrot0: wrot@14007000 {
+   compatible = "mediatek,mt8173-mdp-wrot";
+   reg = <0 0x14007000 0 0x1000>;
+   clocks = < CLK_MM_MDP_WROT0>;
+   power-domains = < 
MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_WROT0>;
+   mediatek,larb = <>;
+   };
+
+   mdp_wrot1: wrot@14008000 {
+   compatible = "mediatek,mt8173-mdp-wrot";
+   reg = <0 0x14008000 0 0x1000>;
+   clocks = < CLK_MM_MDP_WROT1>;
+   power-domains = < 
MT8173_POWER_DOMAIN_MM>;
+   iommus = < M4U_PORT_MDP_WROT1>;
+   mediatek,larb = <>;
+   };
+   };
+
ovl0: ovl@1400c000 {
compatible = "mediatek,mt8173-disp-ovl";
reg = <0 0x1400c000 0 0x1000>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org

Re: [STLinux Kernel] [PATCH v5 0/3] support of v4l2 encoder for STMicroelectronics SOC

[Peter Griffin]

Hi Jean-Christophe,

On Mon, 29 Aug 2016, Jean-Christophe Trotin wrote:

> version 5:
> - Compilation problem with 4.8-rc1 corrected: unsigned long used for dma_attrs
> - The video bitrate (V4L2_CID_MPEG_VIDEO_BITRATE) and the CPB size 
> (V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE) were respectively considered in kbps and 
> kb, while the V4L2 API specifies them in bps and kB. This is corrected and 
> the code is now aligned with the V4L2 specification
> - If the encoder close function (enc->close) has not been called through 
> hva_stop_streaming (e.g. application is killed), it's called at the encoder 
> instance release (hva_release)
> - hva-v4l2.c: DEFAULT_* renamed HVA_DEFAULT_*
> - hva-v4l2.c: few log messages modified
> - typos corrected
> - V4L2 compliance successfully passed with this version (see report below)
> 

Looks like you forgot to add my: -

 Acked-by: Peter Griffin 

regards,

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

Re: [PATCH v5 01/13] media: mt9m111: make a standalone v4l2 subdevice

[Guennadi Liakhovetski]

Hi Robert,

On Mon, 29 Aug 2016, Robert Jarzmik wrote:

> Remove the soc_camera adherence. Mostly the change removes the power
> manipulation provided by soc_camera, and instead :
>  - powers on the sensor when the s_power control is activated
>  - powers on the sensor in initial probe
>  - enables and disables the MCLK provided to it in power on/off

Your patch also drops support for inverters on synchronisation and clock 
lines, I guess, your board doesn't use any. I assume, if any board ever 
needs such inverters, support for them can be added in the future. Also, 
as I mentioned in my reply to your other patch, maybe good to join this 
with #3. Otherwise and with that in mind

> Signed-off-by: Robert Jarzmik 

Acked-by: Guennadi Liakhovetski 

Thanks
Guennadi

> ---
>  drivers/media/i2c/soc_camera/mt9m111.c | 51 
> ++
>  1 file changed, 15 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/media/i2c/soc_camera/mt9m111.c 
> b/drivers/media/i2c/soc_camera/mt9m111.c
> index 6dfaead6aaa8..a7efaa5964d1 100644
> --- a/drivers/media/i2c/soc_camera/mt9m111.c
> +++ b/drivers/media/i2c/soc_camera/mt9m111.c
> @@ -16,10 +16,11 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * MT9M111, MT9M112 and MT9M131:
> @@ -388,7 +389,7 @@ static int mt9m111_s_crop(struct v4l2_subdev *sd, const 
> struct v4l2_crop *a)
>   struct v4l2_rect rect = a->c;
>   struct mt9m111 *mt9m111 = container_of(sd, struct mt9m111, subdev);
>   int width, height;
> - int ret;
> + int ret, align = 0;
>  
>   if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>   return -EINVAL;
> @@ -396,17 +397,19 @@ static int mt9m111_s_crop(struct v4l2_subdev *sd, const 
> struct v4l2_crop *a)
>   if (mt9m111->fmt->code == MEDIA_BUS_FMT_SBGGR8_1X8 ||
>   mt9m111->fmt->code == MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE) {
>   /* Bayer format - even size lengths */
> - rect.width  = ALIGN(rect.width, 2);
> - rect.height = ALIGN(rect.height, 2);
> + align = 1;
>   /* Let the user play with the starting pixel */
>   }
>  
>   /* FIXME: the datasheet doesn't specify minimum sizes */
> - soc_camera_limit_side(, ,
> -  MT9M111_MIN_DARK_COLS, 2, MT9M111_MAX_WIDTH);
> -
> - soc_camera_limit_side(, ,
> -  MT9M111_MIN_DARK_ROWS, 2, MT9M111_MAX_HEIGHT);
> + v4l_bound_align_image(, 2, MT9M111_MAX_WIDTH, align,
> +   , 2, MT9M111_MAX_HEIGHT, align, 0);
> + rect.left = clamp(rect.left, MT9M111_MIN_DARK_COLS,
> +   MT9M111_MIN_DARK_COLS + MT9M111_MAX_WIDTH -
> +   (__s32)rect.width);
> + rect.top = clamp(rect.top, MT9M111_MIN_DARK_ROWS,
> +  MT9M111_MIN_DARK_ROWS + MT9M111_MAX_HEIGHT -
> +  (__s32)rect.height);
>  
>   width = min(mt9m111->width, rect.width);
>   height = min(mt9m111->height, rect.height);
> @@ -775,17 +778,16 @@ static int mt9m111_init(struct mt9m111 *mt9m111)
>  static int mt9m111_power_on(struct mt9m111 *mt9m111)
>  {
>   struct i2c_client *client = v4l2_get_subdevdata(>subdev);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
>   int ret;
>  
> - ret = soc_camera_power_on(>dev, ssdd, mt9m111->clk);
> + ret = v4l2_clk_enable(mt9m111->clk);
>   if (ret < 0)
>   return ret;
>  
>   ret = mt9m111_resume(mt9m111);
>   if (ret < 0) {
>   dev_err(>dev, "Failed to resume the sensor: %d\n", ret);
> - soc_camera_power_off(>dev, ssdd, mt9m111->clk);
> + v4l2_clk_disable(mt9m111->clk);
>   }
>  
>   return ret;
> @@ -793,11 +795,8 @@ static int mt9m111_power_on(struct mt9m111 *mt9m111)
>  
>  static void mt9m111_power_off(struct mt9m111 *mt9m111)
>  {
> - struct i2c_client *client = v4l2_get_subdevdata(>subdev);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> -
>   mt9m111_suspend(mt9m111);
> - soc_camera_power_off(>dev, ssdd, mt9m111->clk);
> + v4l2_clk_disable(mt9m111->clk);
>  }
>  
>  static int mt9m111_s_power(struct v4l2_subdev *sd, int on)
> @@ -854,14 +853,10 @@ static int mt9m111_enum_mbus_code(struct v4l2_subdev 
> *sd,
>  static int mt9m111_g_mbus_config(struct v4l2_subdev *sd,
>   struct v4l2_mbus_config *cfg)
>  {
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> -
>   cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
>   V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_HIGH |
>   V4L2_MBUS_DATA_ACTIVE_HIGH;
>   cfg->type = V4L2_MBUS_PARALLEL;
> - cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);

Re: [PATCH v5 03/13] media: mt9m111: move mt9m111 out of soc_camera

[Guennadi Liakhovetski]

Hi Robert,

You could use "git format-patch -M" to make this patch much smaller and to 
make it simple to verify, what actually changed in mt9m111.c, if anything. 
Actually it might even be good to merge this patch with patch #1.

Thanks
Guennadi

On Mon, 29 Aug 2016, Robert Jarzmik wrote:

> As the mt9m111 is now working as a standalone v4l2 subdevice sensor,
> move it out of soc_camera directory and severe its dependency on
> soc_camera.
> 
> Signed-off-by: Robert Jarzmik 
> ---
>  drivers/media/i2c/Kconfig  |7 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/mt9m111.c| 1033 
> 
>  drivers/media/i2c/soc_camera/Kconfig   |7 +-
>  drivers/media/i2c/soc_camera/Makefile  |1 -
>  drivers/media/i2c/soc_camera/mt9m111.c | 1033 
> 
>  6 files changed, 1046 insertions(+), 1036 deletions(-)
>  create mode 100644 drivers/media/i2c/mt9m111.c
>  delete mode 100644 drivers/media/i2c/soc_camera/mt9m111.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index ce9006e10a30..7f8790507660 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -571,6 +571,13 @@ config VIDEO_MT9M032
> This driver supports MT9M032 camera sensors from Aptina, monochrome
> models only.
>  
> +config VIDEO_MT9M111
> + tristate "mt9m111, mt9m112 and mt9m131 support"
> + depends on I2C && VIDEO_V4L2
> + help
> +   This driver supports MT9M111, MT9M112 and MT9M131 cameras from
> +   Micron/Aptina
> +
>  config VIDEO_MT9P031
>   tristate "Aptina MT9P031 support"
>   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 94f2c99e890d..a1a82331bebc 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -59,6 +59,7 @@ obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
>  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
> +obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
>  obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
>  obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
>  obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
> diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
> new file mode 100644
> index ..b7c4f371bae1
> --- /dev/null
> +++ b/drivers/media/i2c/mt9m111.c
> @@ -0,0 +1,1033 @@
> +/*
> + * Driver for MT9M111/MT9M112/MT9M131 CMOS Image Sensor from Micron/Aptina
> + *
> + * Copyright (C) 2008, Robert Jarzmik 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * MT9M111, MT9M112 and MT9M131:
> + * i2c address is 0x48 or 0x5d (depending on SADDR pin)
> + * The platform has to define struct i2c_board_info objects and link to them
> + * from struct soc_camera_host_desc
> + */
> +
> +/*
> + * Sensor core register addresses (0x000..0x0ff)
> + */
> +#define MT9M111_CHIP_VERSION 0x000
> +#define MT9M111_ROW_START0x001
> +#define MT9M111_COLUMN_START 0x002
> +#define MT9M111_WINDOW_HEIGHT0x003
> +#define MT9M111_WINDOW_WIDTH 0x004
> +#define MT9M111_HORIZONTAL_BLANKING_B0x005
> +#define MT9M111_VERTICAL_BLANKING_B  0x006
> +#define MT9M111_HORIZONTAL_BLANKING_A0x007
> +#define MT9M111_VERTICAL_BLANKING_A  0x008
> +#define MT9M111_SHUTTER_WIDTH0x009
> +#define MT9M111_ROW_SPEED0x00a
> +#define MT9M111_EXTRA_DELAY  0x00b
> +#define MT9M111_SHUTTER_DELAY0x00c
> +#define MT9M111_RESET0x00d
> +#define MT9M111_READ_MODE_B  0x020
> +#define MT9M111_READ_MODE_A  0x021
> +#define MT9M111_FLASH_CONTROL0x023
> +#define MT9M111_GREEN1_GAIN  0x02b
> +#define MT9M111_BLUE_GAIN0x02c
> +#define MT9M111_RED_GAIN 0x02d
> +#define MT9M111_GREEN2_GAIN  0x02e
> +#define MT9M111_GLOBAL_GAIN  0x02f
> +#define MT9M111_CONTEXT_CONTROL  0x0c8
> +#define MT9M111_PAGE_MAP 0x0f0
> +#define MT9M111_BYTE_WISE_ADDR   0x0f1
> +
> +#define MT9M111_RESET_SYNC_CHANGES   (1 << 15)
> +#define MT9M111_RESET_RESTART_BAD_FRAME  (1 << 9)
> +#define MT9M111_RESET_SHOW_BAD_FRAMES(1 << 8)
> +#define MT9M111_RESET_RESET_SOC  (1 << 5)
> +#define MT9M111_RESET_OUTPUT_DISABLE (1 << 4)
> +#define MT9M111_RESET_CHIP_ENABLE(1 << 3)
> +#define MT9M111_RESET_ANALOG_STANDBY (1 << 2)
> +#define MT9M111_RESET_RESTART_FRAME  (1 << 1)
> +#define