Re: [PATCH] [media] media-ioc-g-topology.rst: fix typos

[Alexandre Courbot]

On Fri, Jun 9, 2017 at 2:51 AM, Mauro Carvalho Chehab
 wrote:
> Em Wed,  7 Jun 2017 18:33:02 +0900
> Alexandre Courbot  escreveu:
>
>> Fix what seems to be a few typos induced by copy/paste.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  Documentation/media/uapi/mediactl/media-ioc-g-topology.rst | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst 
>> b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
>> index 48c9531f4db0..5f2d82756033 100644
>> --- a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
>> +++ b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
>> @@ -241,7 +241,7 @@ desired arrays with the media graph elements.
>>
>>  .. c:type:: media_v2_intf_devnode
>>
>> -.. flat-table:: struct media_v2_interface
>> +.. flat-table:: struct media_v2_devnode
>>  :header-rows:  0
>>  :stub-columns: 0
>>  :widths: 1 2 8
>
> Actually the fix is wrong here :-)

Whoopsie. Apologies for not double-checking. >_<

>
> I'll just fold the following diff to your patch:
>
> diff --git a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst 
> b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> index 5f2d82756033..add8281494f8 100644
> --- a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> +++ b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> @@ -241,7 +241,7 @@ desired arrays with the media graph elements.
>
>  .. c:type:: media_v2_intf_devnode
>
> -.. flat-table:: struct media_v2_devnode
> +.. flat-table:: struct media_v2_intf_devnode
>  :header-rows:  0
>  :stub-columns: 0
>  :widths: 1 2 8

Looks perfect now. Thanks for catching this!

[patch] [media_build] make check_git() give more information in verbose mode (resend)

[Vincent McIntyre]

While debugging another issue I found this change helpful.
Original send Date: Thu, 1 Jun 2017 20:44:27 +1000



Make check_git() give more information in verbose mode.

Signed-off-by: Vincent McIntyre 
---
 build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build b/build
index d7f51c2..4457a73 100755
--- a/build
+++ b/build
@@ -303,12 +303,13 @@ sub check_git($$)
my $cmd = shift;
my $remote = shift;
 
-   print "\$ git --git-dir media/.git $cmd\n" if ($level);
+   print "\$ git --git-dir media/.git $cmd (checking for '$remote')\n" if 
($level);
open IN, "git --git-dir media/.git $cmd|" or die "can't run git 
--git-dir media/.git $cmd";
while () {
return 1 if (m/^[\*]*\s*($remote)\n$/);
}
close IN;
+   print "check failed\n" if ($level);
return 0;
 }
 
-- 
2.7.4


- End forwarded message -

[patch] [media_build] small cleanup of build script (resend)

[Vincent McIntyre]

Original send date: Thu, 1 Jun 2017 20:12:32 +1000

Introduce a function to help tracing of system() calls

While debugging a recent issue I wanted more complete information
about the sequencence of events in a series of calls like
  system("foo") or die("BAR")
Adding this helper did that and cleaned things up a little.

Signed-off-by: Vincent McIntyre 
---
 build | 81 +++
 1 file changed, 47 insertions(+), 34 deletions(-)

diff --git a/build b/build
index 4457a73..38ffd4f 100755
--- a/build
+++ b/build
@@ -342,6 +342,19 @@ sub which($)
return undef;
 }
 
+sub run($$)
+{
+   my $cmd = shift;
+   my $err = shift;
+   $err = '' unless defined($err);
+
+   my ($pkg,$filename,$line) = caller;
+
+   print "\$ $cmd\n" if ($level);
+   system($cmd) == 0
+   or die($err . " at $filename line $line\n");
+}
+
 ##
 # Main
 ##
@@ -406,11 +419,11 @@ if (@git == 2) {
if (!$local) {
print "Getting the latest Kernel tree. This will take 
some time\n";
if ($depth) {
-   system("git clone --origin '$rname/$git[1]' 
git://linuxtv.org/media_tree.git media $depth") == 0
-   or die "Can't clone from the upstream 
tree";
+   run("git clone --origin '$rname/$git[1]' 
git://linuxtv.org/media_tree.git media $depth",
+   "Can't clone from the upstream tree");
} else {
-   system("git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git media $depth") 
== 0
-   or die "Can't clone from the upstream 
tree";
+   run("git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git media $depth",
+   "Can't clone from the upstream tree");
}
system('git --git-dir media/.git config format.cc 
"Linux Media Mailing List "');
system('git --git-dir media/.git config format.signoff 
true');
@@ -419,56 +432,54 @@ if (@git == 2) {
} else {
if ($workdir ne "") {
print "Creating a new workdir from $git[0] at 
media\n";
-   system("git new-workdir $git[0] media") == 0
-   or die "Can't create a new workdir";
+   run("git new-workdir $git[0] media",
+   "Can't create a new workdir");
} else {
print "Creating a new clone\n";
-   system("git clone -l $git[0] media $depth") == 0
-   or die "Can't create a new clone";
+   run("git clone -l $git[0] media $depth",
+   "Can't create a new clone");
}
}
} elsif ($workdir eq "") {
if (check_git("remote", "$rname/$git[1]")) {
-   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
-   or die "Can't update from the upstream tree";
+   run("git --git-dir media/.git remote update 
'$rname/$git[1]'",
+   "Can't update from the upstream tree");
} else {
-   system("git --git-dir media/.git remote update origin") 
== 0
-   or die "Can't update from the upstream tree";
+   run("git --git-dir media/.git remote update origin",
+   "Can't update from the upstream tree");
}
}
 
if ($workdir eq "") {
if (!check_git("remote", "$name")) {
print "adding remote $name to track $git[0]\n";
-   printf "\$ git --git-dir media/.git remote add $name 
$git[0]\n" if ($level);
-   system ("git --git-dir media/.git remote add $name 
$git[0]") == 0
-   or die "Can't create remote $name";
+   run("git --git-dir media/.git remote add $name $git[0]",
+   "Can't create remote $name");
}
if (!$depth) {
print "updating remote $rname\n";
-   system ("git --git-dir media/.git remote update $name") 
== 0
-   or die "Can't update remote $name";
+   run("git --git-dir media/.git remote update $name",
+   "Can't update remote 

[patch] [media_build] Small fix to build script (resend)

[Vincent McIntyre]

This seems to have fallen on the floor...
Original send date: Thu, 1 Jun 2017 19:43:43 +1000

Avoid going splat if --depth is not given

Commit 6b4a9c5 indroduced the --depth parameter to limit the commit history
pulled by when cloning, giving a nice speedup. But in the process it broke
running without the --depth parameter. The first invocation of
'./build --main-git' works fine, but the second falls over like so:

  fatal: No such remote or remote group: media_tree/master
  Can't update from the upstream tree at ./build line 430.

The fix is to check whether that remote has been defined before trying
to update from it.

Signed-off-by: Vincent McIntyre 
---
 build | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/build b/build
index a4cd38e..d7f51c2 100755
--- a/build
+++ b/build
@@ -427,8 +427,13 @@ if (@git == 2) {
}
}
} elsif ($workdir eq "") {
-   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
-   or die "Can't update from the upstream tree";
+   if (check_git("remote", "$rname/$git[1]")) {
+   system("git --git-dir media/.git remote update 
'$rname/$git[1]'") == 0
+   or die "Can't update from the upstream tree";
+   } else {
+   system("git --git-dir media/.git remote update origin") 
== 0
+   or die "Can't update from the upstream tree";
+   }
}
 
if ($workdir eq "") {

Re: [PATCH v8 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

[Steve Longerbeam]

On 06/09/2017 04:23 PM, Pavel Machek wrote:

Hi!


Steve,

You need to remove the fim node now that you've moved this to V4L2 controls.



Yep, I caught this just after sending the v8 patchset. I'll send
a v9 of this patch.


This needs ack from devicetree people, then it can be merged. Can you
be a bit more forceful getting the ack?


OK, I need an Ack please, he said, in a forceful way. :)


I'd tune the force up a tiny bit more. This is not FreeBSD ;-). You
can read some emails from Linus for inspiration. Or drink few beers
and look at Al Viro's emails.


In fact Ack's are needed for all the changes to dts sources,
patches 4-14.


Actually, are they? Those should not need acks from device tree
people, just acks from ARM people, and those are easier to get... in
fact they should not need any acks, you should just send them to arm
people and get them merged.



Hans said he prefers to have the dts patches as part of the whole set
rather than submitted separately. But I did add --to's for the ARM
people for 4-14.




1-4 is just a documentation, and you have acks there. (Except 2?)
That's ready to be merged, probably via the media tree? Just make it
clear you want it merged.


Yes, 1-3 now have Acks (binding docs).



15,16 should be ready to. Media tree, too, I guess.


Yes, those have Acks (video-mux entity functions and subdev driver).



drivers/staging is greg. Advantage is these do _not_ need to go after
the dts changes. It is a driver. Actually I'd normally add dts support
after the driver. So you can push it now.


Right, Hans agrees, except that for staging drivers we don't really need
an Ack from Greg.





I don't think it makes sense to resubmit v9 before that. This is not a
rocket science.


I guess that makes sense, I'll wait for Ack's from all these patches
before submitting the entire patchset as v9.


You may want to split the series, according to mainainters, or just
ask the maintainers to merge the relevant parts. I believe most of it
can be pushed now.

Good luck,


Thanks!
Steve

Re: [PATCH v8 00/34] i.MX Media Driver

[Hans Verkuil]

On 10/06/17 01:16, Steve Longerbeam wrote:
> 
> 
> On 06/07/2017 12:02 PM, Hans Verkuil wrote:
>> We're still waiting for an Ack for patch 02/34, right?
>>
> 
> Hi Hans, Rub has provided an Ack for patch 2.
> 
>> Other than that everything is ready AFAICT.
>>
> 
> But as Pavel pointed out, in fact we are missing many
> Acks still, for all of the dts source changes (patches
> 4-14), as well as really everything else (imx-media staging
> driver patches).

No Acks needed for the staging part. It's staging, so not held
to the same standards as non-staging parts. That doesn't mean
Acks aren't welcome, of course.

You don't need Greg's Ack for staging/media either, patches there
go in via us (generally at least) and we handle those, not Greg.

Regards,

Hans

Re: [PATCH v8 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

[Pavel Machek]

Hi!

> >>>Steve,
> >>>
> >>>You need to remove the fim node now that you've moved this to V4L2 
> >>>controls.
> >>>
> >>
> >>Yep, I caught this just after sending the v8 patchset. I'll send
> >>a v9 of this patch.
> >
> >This needs ack from devicetree people, then it can be merged. Can you
> >be a bit more forceful getting the ack?
> 
> OK, I need an Ack please, he said, in a forceful way. :)

I'd tune the force up a tiny bit more. This is not FreeBSD ;-). You
can read some emails from Linus for inspiration. Or drink few beers
and look at Al Viro's emails.

> In fact Ack's are needed for all the changes to dts sources,
> patches 4-14.

Actually, are they? Those should not need acks from device tree
people, just acks from ARM people, and those are easier to get... in
fact they should not need any acks, you should just send them to arm
people and get them merged.

1-4 is just a documentation, and you have acks there. (Except 2?)
That's ready to be merged, probably via the media tree? Just make it
clear you want it merged.

15,16 should be ready to. Media tree, too, I guess.

drivers/staging is greg. Advantage is these do _not_ need to go after
the dts changes. It is a driver. Actually I'd normally add dts support
after the driver. So you can push it now.

> >I don't think it makes sense to resubmit v9 before that. This is not a
> >rocket science.
> 
> I guess that makes sense, I'll wait for Ack's from all these patches
> before submitting the entire patchset as v9.

You may want to split the series, according to mainainters, or just
ask the maintainers to merge the relevant parts. I believe most of it
can be pushed now. 

Good luck,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v8 00/34] i.MX Media Driver

[Steve Longerbeam]

On 06/09/2017 04:16 PM, Steve Longerbeam wrote:



On 06/07/2017 12:02 PM, Hans Verkuil wrote:

We're still waiting for an Ack for patch 02/34, right?



Hi Hans, Rub 


damn, I really need to proof-read before hitting send.
"Rob" (sorry Rob!).

Steve

Re: [PATCH v8 00/34] i.MX Media Driver

[Steve Longerbeam]

On 06/07/2017 12:02 PM, Hans Verkuil wrote:

We're still waiting for an Ack for patch 02/34, right?



Hi Hans, Rub has provided an Ack for patch 2.


Other than that everything is ready AFAICT.



But as Pavel pointed out, in fact we are missing many
Acks still, for all of the dts source changes (patches
4-14), as well as really everything else (imx-media staging
driver patches).

Steve

Re: [PATCH v8 19/34] media: Add i.MX media core driver

[Steve Longerbeam]

On 06/09/2017 06:15 AM, Philipp Zabel wrote:

On Wed, 2017-06-07 at 11:33 -0700, Steve Longerbeam wrote:

Add the core media driver for i.MX SOC.

Signed-off-by: Steve Longerbeam 

Switch from the v4l2_of_ APIs to the v4l2_fwnode_ APIs.

Signed-off-by: Philipp Zabel 

Add the bayer formats to imx-media's list of supported pixel and bus
formats.

Signed-off-by: Russell King 
---

[...]

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
new file mode 100644
index 000..da694f6
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -0,0 +1,666 @@

[...]

+/*
+ * adds given video device to given imx-media source pad vdev list.
+ * Continues upstream from the pad entity's sink pads.
+ */
+static int imx_media_add_vdev_to_pad(struct imx_media_dev *imxmd,
+struct imx_media_video_dev *vdev,
+struct media_pad *srcpad)
+{
+   struct media_entity *entity = srcpad->entity;
+   struct imx_media_subdev *imxsd;
+   struct imx_media_pad *imxpad;
+   struct media_link *link;
+   struct v4l2_subdev *sd;
+   int i, vdev_idx, ret;
+
+   if (!is_media_entity_v4l2_subdev(entity))
+   return -EINVAL;


Could we make this return 0, to just skip non-v4l2_subdev entities?
Currently, imx_media_probe_complete silently fails with this -EINVAL if
there is a tvp5150 connected due to the separate media entities that the
tvp5150 driver creates for the input connectors (Composite0, for
example).



Right, I've made that change.

Steve

Re: [PATCH v8 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

[Steve Longerbeam]

On 06/09/2017 02:38 PM, Pavel Machek wrote:

On Thu 2017-06-08 13:36:12, Steve Longerbeam wrote:



On 06/08/2017 01:25 PM, Tim Harvey wrote:



Steve,

You need to remove the fim node now that you've moved this to V4L2 controls.



Yep, I caught this just after sending the v8 patchset. I'll send
a v9 of this patch.


This needs ack from devicetree people, then it can be merged. Can you
be a bit more forceful getting the ack?


OK, I need an Ack please, he said, in a forceful way. :)

In fact Ack's are needed for all the changes to dts sources,
patches 4-14.




I don't think it makes sense to resubmit v9 before that. This is not a
rocket science.


I guess that makes sense, I'll wait for Ack's from all these patches
before submitting the entire patchset as v9.

Steve

Re: [PATCH v8 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

[Pavel Machek]

On Thu 2017-06-08 13:36:12, Steve Longerbeam wrote:
> 
> 
> On 06/08/2017 01:25 PM, Tim Harvey wrote:
> >
> >
> >Steve,
> >
> >You need to remove the fim node now that you've moved this to V4L2 controls.
> >
> 
> Yep, I caught this just after sending the v8 patchset. I'll send
> a v9 of this patch.

This needs ack from devicetree people, then it can be merged. Can you
be a bit more forceful getting the ack?

I don't think it makes sense to resubmit v9 before that. This is not a
rocket science.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] [media] davinci/dm644x: work around ccdc_update_raw_params trainwreck

[Arnd Bergmann]

Now that the davinci drivers can be enabled in compile tests on other
architectures, I ran into this warning on a 64-bit build:

drivers/media/platform/davinci/dm644x_ccdc.c: In function 
'ccdc_update_raw_params':
drivers/media/platform/davinci/dm644x_ccdc.c:279:7: error: cast to pointer from 
integer of different size [-Werror=int-to-pointer-cast]

While that looks fairly harmless (it would be fine on 32-bit), it was
just the tip of the iceberg:

- The function constantly mixes up pointers and phys_addr_t numbers
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
  described as an 'experimental ioctl that will change in future kernels',
  but if we have users that probably won't happen.
- The code to allocate the table never gets called after we copy_from_user
  the user input over the kernel settings, and then compare them
  for inequality.
- We then go on to use an address provided by user space as both the
  __user pointer for input and pass it through phys_to_virt to come up
  with a kernel pointer to copy the data to. This looks like a trivially
  exploitable root hole.

This patch disables all the obviously broken code, by zeroing out the
sensitive data provided by user space. I also fix the type confusion
here. If we think the ioctl has no stable users, we could consider
just removing it instead.

Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture 
driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/platform/davinci/dm644x_ccdc.c | 40 +---
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/davinci/dm644x_ccdc.c 
b/drivers/media/platform/davinci/dm644x_ccdc.c
index 740fbc7a8c14..1b42f50cad38 100644
--- a/drivers/media/platform/davinci/dm644x_ccdc.c
+++ b/drivers/media/platform/davinci/dm644x_ccdc.c
@@ -236,10 +236,22 @@ static int ccdc_update_raw_params(struct 
ccdc_config_params_raw *raw_params)
 {
struct ccdc_config_params_raw *config_params =
_cfg.bayer.config_params;
-   unsigned int *fpc_virtaddr = NULL;
-   unsigned int *fpc_physaddr = NULL;
+   unsigned int *fpc_virtaddr;
+   phys_addr_t fpc_physaddr;
 
memcpy(config_params, raw_params, sizeof(*raw_params));
+
+   /*
+* FIXME: the code to copy the fault_pxl settings was present
+*in the original version but clearly could never
+*work and will interpret user-provided data in
+*dangerous ways. Let's disable it completely to be
+*on the safe side.
+*/
+   config_params->fault_pxl.enable = 0;
+   config_params->fault_pxl.fp_num = 0;
+   config_params->fault_pxl.fpc_table_addr = 0;
+
/*
 * allocate memory for fault pixel table and copy the user
 * values to the table
@@ -247,16 +259,15 @@ static int ccdc_update_raw_params(struct 
ccdc_config_params_raw *raw_params)
if (!config_params->fault_pxl.enable)
return 0;
 
-   fpc_physaddr = (unsigned int *)config_params->fault_pxl.fpc_table_addr;
-   fpc_virtaddr = (unsigned int *)phys_to_virt(
-   (unsigned long)fpc_physaddr);
+   fpc_physaddr = config_params->fault_pxl.fpc_table_addr;
+   fpc_virtaddr = (unsigned int *)phys_to_virt(fpc_physaddr);
/*
 * Allocate memory for FPC table if current
 * FPC table buffer is not big enough to
 * accommodate FPC Number requested
 */
if (raw_params->fault_pxl.fp_num != config_params->fault_pxl.fp_num) {
-   if (fpc_physaddr != NULL) {
+   if (fpc_physaddr) {
free_pages((unsigned long)fpc_virtaddr,
   get_order
   (config_params->fault_pxl.fp_num *
@@ -270,13 +281,12 @@ static int ccdc_update_raw_params(struct 
ccdc_config_params_raw *raw_params)
 fault_pxl.fp_num *
 FP_NUM_BYTES));
 
-   if (fpc_virtaddr == NULL) {
+   if (fpc_virtaddr) {
dev_dbg(ccdc_cfg.dev,
"\nUnable to allocate memory for FPC");
return -EFAULT;
}
-   fpc_physaddr =
-   (unsigned int *)virt_to_phys((void *)fpc_virtaddr);
+   fpc_physaddr = virt_to_phys(fpc_virtaddr);
}
 
/* Copy number of fault pixels and FPC table */
@@ -287,7 +297,7 @@ static int ccdc_update_raw_params(struct 
ccdc_config_params_raw *raw_params)
dev_dbg(ccdc_cfg.dev, "\n copy_from_user failed");
return -EFAULT;
}
-   config_params->fault_pxl.fpc_table_addr = (unsigned long)fpc_physaddr;
+   config_params->fault_pxl.fpc_table_addr = fpc_physaddr;
return 0;
 

[PATCH] [media] tuner-core: Remove unused #define PREFIX

[Joe Perches]

Commit 680d87c0a9e3 ("[media] tuner-core: use pr_foo, instead of
internal printk macros") removed the use of PREFIX, remove the #define

Signed-off-by: Joe Perches 
---
 drivers/media/v4l2-core/tuner-core.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/v4l2-core/tuner-core.c 
b/drivers/media/v4l2-core/tuner-core.c
index e48b7c032c95..8db45dfc271b 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -43,8 +43,6 @@
 
 #define UNSET (-1U)
 
-#define PREFIX (t->i2c->dev.driver->name)
-
 /*
  * Driver modprobe parameters
  */
-- 
2.10.0.rc2.1.g053435c

[PATCH] stkwebcam: Use more common logging styles

[Joe Perches]

Convert STK_ to pr_ to use the typical kernel logging.
Add a define for pr_fmt.  No change in logging output.

Miscellanea:

o Remove now unused PREFIX and STK_ macros
o Realign arguments
o Use pr__ratelimited
o Add a few missing newlines to formats

Signed-off-by: Joe Perches 
---
 drivers/media/usb/stkwebcam/stk-sensor.c | 32 ---
 drivers/media/usb/stkwebcam/stk-webcam.c | 70 
 drivers/media/usb/stkwebcam/stk-webcam.h |  6 ---
 3 files changed, 52 insertions(+), 56 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-sensor.c 
b/drivers/media/usb/stkwebcam/stk-sensor.c
index 985af9933c7e..c1d4505f84ea 100644
--- a/drivers/media/usb/stkwebcam/stk-sensor.c
+++ b/drivers/media/usb/stkwebcam/stk-sensor.c
@@ -41,6 +41,8 @@
 
 /* It seems the i2c bus is controlled with these registers */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include "stk-webcam.h"
 
 #define STK_IIC_BASE   (0x0200)
@@ -239,8 +241,8 @@ static int stk_sensor_outb(struct stk_camera *dev, u8 reg, 
u8 val)
} while (tmpval == 0 && i < MAX_RETRIES);
if (tmpval != STK_IIC_STAT_TX_OK) {
if (tmpval)
-   STK_ERROR("stk_sensor_outb failed, status=0x%02x\n",
-   tmpval);
+   pr_err("stk_sensor_outb failed, status=0x%02x\n",
+  tmpval);
return 1;
} else
return 0;
@@ -262,8 +264,8 @@ static int stk_sensor_inb(struct stk_camera *dev, u8 reg, 
u8 *val)
} while (tmpval == 0 && i < MAX_RETRIES);
if (tmpval != STK_IIC_STAT_RX_OK) {
if (tmpval)
-   STK_ERROR("stk_sensor_inb failed, status=0x%02x\n",
-   tmpval);
+   pr_err("stk_sensor_inb failed, status=0x%02x\n",
+  tmpval);
return 1;
}
 
@@ -366,29 +368,29 @@ int stk_sensor_init(struct stk_camera *dev)
if (stk_camera_write_reg(dev, STK_IIC_ENABLE, STK_IIC_ENABLE_YES)
|| stk_camera_write_reg(dev, STK_IIC_ADDR, SENSOR_ADDRESS)
|| stk_sensor_outb(dev, REG_COM7, COM7_RESET)) {
-   STK_ERROR("Sensor resetting failed\n");
+   pr_err("Sensor resetting failed\n");
return -ENODEV;
}
msleep(10);
/* Read the manufacturer ID: ov = 0x7FA2 */
if (stk_sensor_inb(dev, REG_MIDH, )
|| stk_sensor_inb(dev, REG_MIDL, )) {
-   STK_ERROR("Strange error reading sensor ID\n");
+   pr_err("Strange error reading sensor ID\n");
return -ENODEV;
}
if (idh != 0x7f || idl != 0xa2) {
-   STK_ERROR("Huh? you don't have a sensor from ovt\n");
+   pr_err("Huh? you don't have a sensor from ovt\n");
return -ENODEV;
}
if (stk_sensor_inb(dev, REG_PID, )
|| stk_sensor_inb(dev, REG_VER, )) {
-   STK_ERROR("Could not read sensor model\n");
+   pr_err("Could not read sensor model\n");
return -ENODEV;
}
stk_sensor_write_regvals(dev, ov_initvals);
msleep(10);
-   STK_INFO("OmniVision sensor detected, id %02X%02X at address %x\n",
-idh, idl, SENSOR_ADDRESS);
+   pr_info("OmniVision sensor detected, id %02X%02X at address %x\n",
+   idh, idl, SENSOR_ADDRESS);
return 0;
 }
 
@@ -520,7 +522,8 @@ int stk_sensor_configure(struct stk_camera *dev)
case MODE_SXGA: com7 = COM7_FMT_SXGA;
dummylines = 0;
break;
-   default: STK_ERROR("Unsupported mode %d\n", dev->vsettings.mode);
+   default:
+   pr_err("Unsupported mode %d\n", dev->vsettings.mode);
return -EFAULT;
}
switch (dev->vsettings.palette) {
@@ -544,7 +547,8 @@ int stk_sensor_configure(struct stk_camera *dev)
com7 |= COM7_PBAYER;
rv = ov_fmt_bayer;
break;
-   default: STK_ERROR("Unsupported colorspace\n");
+   default:
+   pr_err("Unsupported colorspace\n");
return -EFAULT;
}
/*FIXME sometimes the sensor go to a bad state
@@ -564,7 +568,7 @@ int stk_sensor_configure(struct stk_camera *dev)
switch (dev->vsettings.mode) {
case MODE_VGA:
if (stk_sensor_set_hw(dev, 302, 1582, 6, 486))
-   STK_ERROR("stk_sensor_set_hw failed (VGA)\n");
+   pr_err("stk_sensor_set_hw failed (VGA)\n");
break;
case MODE_SXGA:
case MODE_CIF:
@@ -572,7 +576,7 @@ int stk_sensor_configure(struct stk_camera *dev)
case MODE_QCIF:
/*FIXME These settings seem ignored by the sensor
if (stk_sensor_set_hw(dev, 220, 1500, 10, 1034))
-   

[PATCH 1/2] dt-bindings: add media/cec.txt

[Hans Verkuil]

From: Hans Verkuil 

Document common HDMI CEC bindings. Add this to the MAINTAINERS file
as well.

Signed-off-by: Hans Verkuil 
Cc: Krzysztof Kozlowski 
Cc: Andrzej Hajda 
Cc: Benjamin Gaignard 
Cc: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/media/cec.txt | 8 
 MAINTAINERS | 1 +
 2 files changed, 9 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cec.txt

diff --git a/Documentation/devicetree/bindings/media/cec.txt 
b/Documentation/devicetree/bindings/media/cec.txt
new file mode 100644
index ..22d7aae3d3d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec.txt
@@ -0,0 +1,8 @@
+Common bindings for HDMI CEC adapters
+
+- hdmi-phandle: phandle to the HDMI controller.
+
+- needs-hpd: if present the CEC support is only available when the HPD
+  is high. Some boards only let the CEC pin through if the HPD is high,
+  for example if there is a level converter that uses the HPD to power
+  up or down.
diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bdd1fe5..4ac340d189a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3137,6 +3137,7 @@ F:include/media/cec.h
 F: include/media/cec-notifier.h
 F: include/uapi/linux/cec.h
 F: include/uapi/linux/cec-funcs.h
+F: Documentation/devicetree/bindings/media/cec.txt
 
 CELL BROADBAND ENGINE ARCHITECTURE
 M: Arnd Bergmann 
-- 
2.11.0

[PATCH 0/2] cec.txt: document common cec bindings

[Hans Verkuil]

From: Hans Verkuil 

As requested by Rob Herring.

Sits on top of the earlier "cec improvements" patch series:

http://www.spinics.net/lists/dri-devel/msg143377.html

Regards,

Hans

Hans Verkuil (2):
  dt-bindings: add media/cec.txt
  dt-bindings: media/s5p-cec.txt, media/stih-cec.txt: refer to cec.txt

 Documentation/devicetree/bindings/media/cec.txt  | 8 
 Documentation/devicetree/bindings/media/s5p-cec.txt  | 6 ++
 Documentation/devicetree/bindings/media/stih-cec.txt | 2 +-
 MAINTAINERS  | 1 +
 4 files changed, 12 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/cec.txt

-- 
2.11.0

[PATCH 2/2] dt-bindings: media/s5p-cec.txt, media/stih-cec.txt: refer to cec.txt

[Hans Verkuil]

From: Hans Verkuil 

Now that there is a cec.txt with common CEC bindings, update the two
driver-specific bindings to refer to cec.txt.

Signed-off-by: Hans Verkuil 
Cc: Krzysztof Kozlowski 
Cc: Andrzej Hajda 
Cc: Benjamin Gaignard 
Cc: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/media/s5p-cec.txt  | 6 ++
 Documentation/devicetree/bindings/media/stih-cec.txt | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
index 261af4d1a791..1b1a10ba48ce 100644
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -15,13 +15,11 @@ Required properties:
   - clock-names : from common clock binding: must contain "hdmicec",
  corresponding to entry in the clocks property.
   - samsung,syscon-phandle - phandle to the PMU system controller
-  - hdmi-phandle - phandle to the HDMI controller
+  - hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
 
 Optional:
   - needs-hpd : if present the CEC support is only available when the HPD
-is high. Some boards only let the CEC pin through if the HPD is high, for
-example if there is a level converter that uses the HPD to power up
-or down.
+   is high. See cec.txt for more details.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt 
b/Documentation/devicetree/bindings/media/stih-cec.txt
index 289a08b33651..8be2a040c6c6 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,7 +9,7 @@ Required properties:
  - pinctrl-names: Contains only one value - "default"
  - pinctrl-0: Specifies the pin control groups used for CEC hardware.
  - resets: Reference to a reset controller
- - hdmi-phandle: Phandle to the HDMI controller
+ - hdmi-phandle: Phandle to the HDMI controller, see also cec.txt.
 
 Example for STIH407:
 
-- 
2.11.0

[PATCH] dvb-usb-af9035: load HID table

[Jaroslav Škarvada]

Automatically load sniffed HID table from Windows driver if
USB_VID_ITETECH:USB_PID_ITETECH_IT9135_9006 device is present (e.g. Evolveo
Mars) or if module parameter force_hid_tab_load is set.

Signed-off-by: Jaroslav Škarvada 
---
 drivers/media/usb/dvb-usb-v2/af9035.c | 266 ++
 1 file changed, 266 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c 
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 4df9486..5bbcc1e 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -24,6 +24,10 @@
 /* Max transfer size done by I2C transfer functions */
 #define MAX_XFER_SIZE  64
 
+static bool force_hid_tab_load;
+module_param(force_hid_tab_load, bool, 0644);
+MODULE_PARM_DESC(force_hid_tab_load, "force HID table loading");
+
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 static u16 af9035_checksum(const u8 *buf, size_t len)
@@ -1693,6 +1697,263 @@ static int af9035_tuner_detach(struct dvb_usb_adapter 
*adap)
return 0;
 }
 
+static int ite9135_load_hid_tab(struct dvb_usb_device *d)
+{
+   struct usb_interface *intf = d->intf;
+   int ret, i;
+   struct reg_val hid_tab[] = {
+   { 0x4a97, 0x02 },
+   { 0x4a98, 0xbd },
+   { 0x4a99, 0x0c },
+   { 0x4a9a, 0xf3 },
+   { 0x4a9b, 0x3d },
+   { 0x4a9c, 0x00 },
+   { 0x4a9d, 0x00 },
+   { 0x4a9e, 0x02 },
+   { 0x4a9f, 0xbd },
+   { 0x4aa0, 0x00 },
+   { 0x4aa1, 0xff },
+   { 0x4aa2, 0x1e },
+   { 0x4aa3, 0x00 },
+   { 0x4aa4, 0x00 },
+   { 0x4aa5, 0x02 },
+   { 0x4aa6, 0xbd },
+   { 0x4aa7, 0x01 },
+   { 0x4aa8, 0xfe },
+   { 0x4aa9, 0x1f },
+   { 0x4aaa, 0x00 },
+   { 0x4aab, 0x00 },
+   { 0x4aac, 0x02 },
+   { 0x4aad, 0xbd },
+   { 0x4aae, 0x02 },
+   { 0x4aaf, 0xfd },
+   { 0x4ab0, 0x20 },
+   { 0x4ab1, 0x00 },
+   { 0x4ab2, 0x00 },
+   { 0x4ab3, 0x02 },
+   { 0x4ab4, 0xbd },
+   { 0x4ab5, 0x03 },
+   { 0x4ab6, 0xfc },
+   { 0x4ab7, 0x21 },
+   { 0x4ab8, 0x00 },
+   { 0x4ab9, 0x00 },
+   { 0x4aba, 0x02 },
+   { 0x4abb, 0xbd },
+   { 0x4abc, 0x04 },
+   { 0x4abd, 0xfb },
+   { 0x4abe, 0x22 },
+   { 0x4abf, 0x00 },
+   { 0x4ac0, 0x00 },
+   { 0x4ac1, 0x02 },
+   { 0x4ac2, 0xbd },
+   { 0x4ac3, 0x05 },
+   { 0x4ac4, 0xfa },
+   { 0x4ac5, 0x23 },
+   { 0x4ac6, 0x00 },
+   { 0x4ac7, 0x00 },
+   { 0x4ac8, 0x02 },
+   { 0x4ac9, 0xbd },
+   { 0x4aca, 0x06 },
+   { 0x4acb, 0xf9 },
+   { 0x4acc, 0x24 },
+   { 0x4acd, 0x00 },
+   { 0x4ace, 0x00 },
+   { 0x4acf, 0x02 },
+   { 0x4ad0, 0xbd },
+   { 0x4ad1, 0x07 },
+   { 0x4ad2, 0xf8 },
+   { 0x4ad3, 0x25 },
+   { 0x4ad4, 0x00 },
+   { 0x4ad5, 0x00 },
+   { 0x4ad6, 0x02 },
+   { 0x4ad7, 0xbd },
+   { 0x4ad8, 0x08 },
+   { 0x4ad9, 0xf7 },
+   { 0x4ada, 0x26 },
+   { 0x4adb, 0x00 },
+   { 0x4adc, 0x00 },
+   { 0x4add, 0x02 },
+   { 0x4ade, 0xbd },
+   { 0x4adf, 0x09 },
+   { 0x4ae0, 0xf6 },
+   { 0x4ae1, 0x27 },
+   { 0x4ae2, 0x00 },
+   { 0x4ae3, 0x00 },
+   { 0x4ae4, 0x02 },
+   { 0x4ae5, 0xbd },
+   { 0x4ae6, 0x0a },
+   { 0x4ae7, 0xf5 },
+   { 0x4ae8, 0x41 },
+   { 0x4ae9, 0x00 },
+   { 0x4aea, 0x00 },
+   { 0x4aeb, 0x02 },
+   { 0x4aec, 0xbd },
+   { 0x4aed, 0x1c },
+   { 0x4aee, 0xe3 },
+   { 0x4aef, 0x2a },
+   { 0x4af0, 0x00 },
+   { 0x4af1, 0x00 },
+   { 0x4af2, 0x02 },
+   { 0x4af3, 0xbd },
+   { 0x4af4, 0x1f },
+   { 0x4af5, 0xe0 },
+   { 0x4af6, 0x43 },
+   { 0x4af7, 0x00 },
+   { 0x4af8, 0x00 },
+   { 0x4af9, 0x02 },
+   { 0x4afa, 0xbd },
+   { 0x4afb, 0x12 },
+   { 0x4afc, 0xed },
+   { 0x4afd, 0x52 },
+   { 0x4afe, 0x00 },
+   { 0x4aff, 0x00 },
+   { 0x4b00, 0x02 },
+   { 0x4b01, 0xbd },
+   { 0x4b02, 0x11 },
+   { 0x4b03, 0xee },
+   { 0x4b04, 0x50 },
+   { 0x4b05, 0x00 },
+   { 

Re: [Patch v4 00/12] Add MFC v10.10 support

[Sylwester Nawrocki]

On 04/06/2017 08:11 AM, Smitha T Murthy wrote:

This patch series adds MFC v10.10 support. MFC v10.10 is used in some
of Exynos7 variants.

This adds support for following:

* Add support for HEVC encoder and decoder
* Add support for VP9 decoder
* Update Documentation for control id definitions
* Update computation of min scratch buffer size requirement for V8 onwards

Smitha, do you have any updates on this?  IIRC, there were few things
which needed corrections but we were rather close to the final version.

--
Thanks,
Sylwester

[PATCH] media: fdp1: Support ES2 platforms

[Kieran Bingham]

From: Kieran Bingham 

The new Renesas R-Car H3 ES2.0 platforms have an updated hw version register.
Update the driver accordingly.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/rcar_fdp1.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/rcar_fdp1.c 
b/drivers/media/platform/rcar_fdp1.c
index 42f25d241edd..50b59995b817 100644
--- a/drivers/media/platform/rcar_fdp1.c
+++ b/drivers/media/platform/rcar_fdp1.c
@@ -260,6 +260,7 @@ MODULE_PARM_DESC(debug, "activate debug info");
 #define FD1_IP_INTDATA 0x0800
 #define FD1_IP_H3  0x02010101
 #define FD1_IP_M3W 0x02010202
+#define FD1_IP_H3_ES2  0x02010203
 
 /* LUTs */
 #define FD1_LUT_DIF_ADJ0x1000
@@ -2365,6 +2366,9 @@ static int fdp1_probe(struct platform_device *pdev)
case FD1_IP_M3W:
dprintk(fdp1, "FDP1 Version R-Car M3-W\n");
break;
+   case FD1_IP_H3_ES2:
+   dprintk(fdp1, "FDP1 Version R-Car H3-ES2\n");
+   break;
default:
dev_err(fdp1->dev, "FDP1 Unidentifiable (0x%08x)\n",
hw_version);
-- 
2.7.4

Re: [PATCH 7/9] dt-bindings: media/s5p-cec.txt: document needs-hpd property

[Rob Herring]

On Fri, Jun 9, 2017 at 10:55 AM, Hans Verkuil  wrote:
> On 06/09/2017 05:31 PM, Rob Herring wrote:
>> On Fri, Jun 9, 2017 at 9:11 AM, Hans Verkuil  wrote:
>>> On 09/06/17 16:07, Rob Herring wrote:
 On Wed, Jun 07, 2017 at 04:46:14PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> Needed for boards that wire the CEC pin in such a way that it
> is unavailable when the HPD is low.
>
> Signed-off-by: Hans Verkuil 
> Cc: Krzysztof Kozlowski 
> Cc: Andrzej Hajda 
> Cc: devicet...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/media/s5p-cec.txt | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
> b/Documentation/devicetree/bindings/media/s5p-cec.txt
> index 4bb08d9d940b..261af4d1a791 100644
> --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
> @@ -17,6 +17,12 @@ Required properties:
>- samsung,syscon-phandle - phandle to the PMU system controller
>- hdmi-phandle - phandle to the HDMI controller
>
> +Optional:
> +  - needs-hpd : if present the CEC support is only available when the HPD
> +is high. Some boards only let the CEC pin through if the HPD is 
> high, for
> +example if there is a level converter that uses the HPD to power up
> +or down.

 Seems like something common. Can you document in a common location?
>>>
>>> Should we do the same with hdmi-phandle? It is also used by CEC drivers to 
>>> find
>>> the HDMI driver.
>>
>> Yes.
>>
>>> Currently only used by s5p-cec and stih-cec, but there will be more.
>>>
>>> I guess this would be a sensible place to document this:
>>>
>>> Documentation/devicetree/bindings/media/cec.txt
>>
>> Sounds good. You can do this as a follow-up to this patch if you want.
>> For this one:
>>
>> Acked-by: Rob Herring 
>>
>
> Sorry, I have what might be a stupid question: should I update the s5p-cec.txt
> to refer to the cec.txt bindings file for the hdmi-phandle and needs-hpd 
> instead
> of describing it here? It seems pointless to do that for the hdmi-phandle, but
> it might make more sense for the needs-hpd property.

Yes. Just make both say "see ./cec.txt". You're right it doesn't gain
much for hdmi-phandle, but at least indicates it is a standard
property.

Rob

[PATCH v2] [media] davinci: vpif: adaptions for DT support

[Kevin Hilman]

The davinci VPIF is a single hardware block, but the existing driver
is broken up into a common library (vpif.c), output (vpif_display.c) and
intput (vpif_capture.c).

When migrating to DT, to better model the hardware, and because
registers, interrupts, etc. are all common,it was decided to
have a single VPIF hardware node[1].

Because davinci uses legacy, non-DT boot on several SoCs still, the
platform_drivers need to remain.  But they are also needed in DT boot.
Since there are no DT nodes for the display/capture parts in DT
boot (there is a single node for the parent/common device) we need to
create platform_devices somewhere to instansiate the platform_drivers.

When VPIF display/capture are needed for a DT boot, the VPIF node
will have endpoints defined for its subdevs.  Therefore, vpif_probe()
checks for the presence of endpoints, and if detected manually creates
the platform_devices for the display and capture platform_drivers.

[1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt

Signed-off-by: Kevin Hilman 
---
Changes since v1:
- added proper error checking to kzalloc calls
- rebased onto media/master

 drivers/media/platform/davinci/vpif.c | 57 ++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/davinci/vpif.c 
b/drivers/media/platform/davinci/vpif.c
index 1b02a6363f77..c2d214dfaa3e 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vpif.h"
 
@@ -423,7 +424,9 @@ EXPORT_SYMBOL(vpif_channel_getfid);
 
 static int vpif_probe(struct platform_device *pdev)
 {
-   static struct resource  *res;
+   static struct resource  *res, *res_irq;
+   struct platform_device *pdev_capture, *pdev_display;
+   struct device_node *endpoint = NULL;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
vpif_base = devm_ioremap_resource(>dev, res);
@@ -435,6 +438,58 @@ static int vpif_probe(struct platform_device *pdev)
 
spin_lock_init(_lock);
dev_info(>dev, "vpif probe success\n");
+
+   /*
+* If VPIF Node has endpoints, assume "new" DT support,
+* where capture and display drivers don't have DT nodes
+* so their devices need to be registered manually here
+* for their legacy platform_drivers to work.
+*/
+   endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
+ endpoint);
+   if (!endpoint) 
+   return 0;
+
+   /*
+* For DT platforms, manually create platform_devices for
+* capture/display drivers.
+*/
+   res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   if (!res_irq) {
+   dev_warn(>dev, "Missing IRQ resource.\n");
+   return -EINVAL;
+   }
+
+   pdev_capture = devm_kzalloc(>dev, sizeof(*pdev_capture),
+   GFP_KERNEL);
+   if (pdev_capture) {
+   pdev_capture->name = "vpif_capture";
+   pdev_capture->id = -1;
+   pdev_capture->resource = res_irq;
+   pdev_capture->num_resources = 1;
+   pdev_capture->dev.dma_mask = pdev->dev.dma_mask;
+   pdev_capture->dev.coherent_dma_mask = 
pdev->dev.coherent_dma_mask;
+   pdev_capture->dev.parent = >dev;
+   platform_device_register(pdev_capture);
+   } else {
+   dev_warn(>dev, "Unable to allocate memory for 
pdev_capture.\n");
+   }
+
+   pdev_display = devm_kzalloc(>dev, sizeof(*pdev_display),
+   GFP_KERNEL);
+   if (pdev_display) {
+   pdev_display->name = "vpif_display";
+   pdev_display->id = -1;
+   pdev_display->resource = res_irq;
+   pdev_display->num_resources = 1;
+   pdev_display->dev.dma_mask = pdev->dev.dma_mask;
+   pdev_display->dev.coherent_dma_mask = 
pdev->dev.coherent_dma_mask;
+   pdev_display->dev.parent = >dev;
+   platform_device_register(pdev_display);
+   } else {
+   dev_warn(>dev, "Unable to allocate memory for 
pdev_display.\n");
+   }
+
return 0;
 }
 
-- 
2.9.3

Re: [RFC 00/10] V4L2 explicit synchronization support

[Shuah Khan]

On 06/09/2017 12:25 AM, Gustavo Padovan wrote:
> 2017-06-08 Shuah Khan :
> 
>> Hi Gustavo,
>>
>> On Thu, Jun 8, 2017 at 2:17 PM, Mauro Carvalho Chehab
>>  wrote:
>>> Hi Gustavo,
>>>
>>> Em Wed, 24 May 2017 21:31:01 -0300
>>> Gustavo Padovan  escreveu:
>>>
 Hi all,

 I've been working on the v2 of this series, but I think I hit a blocker
 when trying to cover the case where the driver asks to requeue the
 buffer. It is related to the out-fence side.

 In the current implementation we return on QBUF an out-fence fd that is not
 tied to any buffer, because we don't know the queueing order until the
 buffer is queued to the driver. Then when the buffer is queued we use
 the BUF_QUEUED event to notify userspace of the index of the buffer,
 so now userspace knows the buffer associated to the out-fence fd
 received earlier.

 Userspace goes ahead and send a DRM Atomic Request to the kernel to
 display that buffer on the screen once the fence signals. If it is
 a nonblocking request the fence waiting is past the check phase, thus
 it isn't allowed to fail anymore.

 But now, what happens if the V4L2 driver calls buffer_done() asking
 to requeue the buffer. That means the operation failed and can't
 signal the fence, starving the DRM side.

 We need to fix that. The only way I can see is to guarantee ordering of
 buffers when out-fences are used. Ordering is something that HAL3 needs
 to so maybe there is more than one reason to do it like this. I'm not
 a V4L2 expert, so I don't know all the consequences of such a change.

 Any other ideas?

 The current patchset is at:

 https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences
>>
>> Do you plan to send the v2 out? I did a quick review and have a few comments.
>>
>> [media] vb2: split out queueing from vb_core_qbuf()
>>
>> It changes the sequence a bit.
>>
>> /* Fill buffer information for the userspace */
>>   if (pb)
>>   call_void_bufop(q, fill_user_buffer, vb, pb);
>>
>> With the changes - user information is filled before __enqueue_in_driver(vb);
> 
> Without my changes it also fills it before __enqueue_in_driver() when
> start_streaming wasn't called yet. So I don't think it really matters.

Right, with this change, it fills the buffer before __enqueue_in_driver()
when start_streaming is called. Is that an issue, I don't know for sure.
It might not be necessary perhaps if buffer is filled in the path when
stream is already called.

> 
>>
>> Anyway, it might be a good idea to send the v2 out for review and we can 
>> review
>> patches in detail. I am hoping to test your patch series on odroid-xu4
>> next week.
>> Could you please add me to the thread as well as include me when you send
>> v2 and subsequent versions.
> 
> I will send a v2 as soon as I can, but from Thursday next week until
> the 25th I'll be on vacation.

okay sounds good.

thanks,
-- Shuah

Re: [PATCH 7/9] dt-bindings: media/s5p-cec.txt: document needs-hpd property

[Hans Verkuil]

On 06/09/2017 05:31 PM, Rob Herring wrote:
> On Fri, Jun 9, 2017 at 9:11 AM, Hans Verkuil  wrote:
>> On 09/06/17 16:07, Rob Herring wrote:
>>> On Wed, Jun 07, 2017 at 04:46:14PM +0200, Hans Verkuil wrote:
 From: Hans Verkuil 

 Needed for boards that wire the CEC pin in such a way that it
 is unavailable when the HPD is low.

 Signed-off-by: Hans Verkuil 
 Cc: Krzysztof Kozlowski 
 Cc: Andrzej Hajda 
 Cc: devicet...@vger.kernel.org
 ---
  Documentation/devicetree/bindings/media/s5p-cec.txt | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
 b/Documentation/devicetree/bindings/media/s5p-cec.txt
 index 4bb08d9d940b..261af4d1a791 100644
 --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
 +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
 @@ -17,6 +17,12 @@ Required properties:
- samsung,syscon-phandle - phandle to the PMU system controller
- hdmi-phandle - phandle to the HDMI controller

 +Optional:
 +  - needs-hpd : if present the CEC support is only available when the HPD
 +is high. Some boards only let the CEC pin through if the HPD is high, 
 for
 +example if there is a level converter that uses the HPD to power up
 +or down.
>>>
>>> Seems like something common. Can you document in a common location?
>>
>> Should we do the same with hdmi-phandle? It is also used by CEC drivers to 
>> find
>> the HDMI driver.
> 
> Yes.
> 
>> Currently only used by s5p-cec and stih-cec, but there will be more.
>>
>> I guess this would be a sensible place to document this:
>>
>> Documentation/devicetree/bindings/media/cec.txt
> 
> Sounds good. You can do this as a follow-up to this patch if you want.
> For this one:
> 
> Acked-by: Rob Herring 
> 

Sorry, I have what might be a stupid question: should I update the s5p-cec.txt
to refer to the cec.txt bindings file for the hdmi-phandle and needs-hpd instead
of describing it here? It seems pointless to do that for the hdmi-phandle, but
it might make more sense for the needs-hpd property.

E.g.:

  - needs-hpd: CEC support is only present if HPD is high. See cec.txt for more
details.


Proposed text for cec.txt:

-
Common bindings for HDMI CEC adapters

- hdmi-phandle: phandle to the HDMI controller.

- needs-hpd: if present the CEC support is only available when the HPD
  is high. Some boards only let the CEC pin through if the HPD is high, for
  example if there is a level converter that uses the HPD to power up
  or down.
-

Regards,

Hans

Re: [RFC 00/10] V4L2 explicit synchronization support

[Nicolas Dufresne]

Le lundi 03 avril 2017 à 15:46 -0400, Javier Martinez Canillas a
écrit :
> > The problem is that adding implicit fences changed the behavior of
> > the ioctls, causing gstreamer to wait forever for buffers to be ready.
> > 
> 
> The problem was related to trying to make user-space unaware of the implicit
> fences support, and so it tried to QBUF a buffer that had already a pending
> fence. A workaround was to block the second QBUF ioctl if the buffer had a
> pending fence, but this caused the mentioned deadlock since GStreamer wasn't
> expecting the QBUF ioctl to block.

That QBUF may block isn't a problem, but modern userspace application,
not just GStreamer, need "cancellable" operations. This is achieved by
avoiding blocking call that cannot be interrupted. What is usually
done, is that we poll the device FD to determine when it is safe to
call QBUF in a way that it will return in a finit amount of time. For
the implicit fence, it could not work, since the driver is not yet
aware of the fence, hence cannot use it to delay the poll operation.
Though, it's not clear why it couldn't wait asynchronously like this
RFC is doing with the explicit fences.

In the current RFC, the fences are signalled through a callback, and
QBUF is split in half. So waiting on the fence is done elsewhere, and
the qbuf operation completes on the fence callback thread.

Nicolas 

signature.asc
Description: This is a digitally signed message part

[GIT PULL] Samsung SoC updates for v4.13

[Sylwester Nawrocki]

Hi Mauro,

The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030:

  [media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update() 
(2017-05-19 07:12:05 -0300)

are available in the git repository at:

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

for you to fetch changes up to b84da96956f6cfea1b48e60be9e6a0d3ba66a6b0:

  s3c-camif: fix arguments position in a function call (2017-06-05 12:09:03 
+0200)


Alexandre Courbot (1):
  s5p-jpeg: fix recursive spinlock acquisition

Benjamin Gaignard (1):
  exynos4-is: use devm_of_platform_populate()

Colin Ian King (1):
  s5p-mfc: fix spelling mistake: "destionation" -> "destination"

Gustavo A. R. Silva (1):
  s3c-camif: fix arguments position in a function call

Nicholas Mc Guire (1):
  s5k6aa: set usleep_range() range greater than 0

Thibault Saunier (1):
  exynos-gsc: Use user configured colorspace if provided

 drivers/media/i2c/s5k6aa.c |  2 +-
 drivers/media/platform/exynos-gsc/gsc-core.c   |  9 -
 drivers/media/platform/exynos-gsc/gsc-core.h   |  1 +
 drivers/media/platform/exynos4-is/fimc-is.c|  7 ++-
 .../media/platform/s3c-camif/camif-capture.c   |  4 ++--
 drivers/media/platform/s5p-jpeg/jpeg-core.c| 12 +---
 .../media/platform/s5p-mfc/s5p_mfc_opr_v5.c|  2 +-
 .../media/platform/s5p-mfc/s5p_mfc_opr_v6.c|  2 +-
 8 files changed, 21 insertions(+), 18 deletions(-)

--
Thanks, 
Sylwester

Re: [PATCH 7/9] dt-bindings: media/s5p-cec.txt: document needs-hpd property

[Rob Herring]

On Fri, Jun 9, 2017 at 9:11 AM, Hans Verkuil  wrote:
> On 09/06/17 16:07, Rob Herring wrote:
>> On Wed, Jun 07, 2017 at 04:46:14PM +0200, Hans Verkuil wrote:
>>> From: Hans Verkuil 
>>>
>>> Needed for boards that wire the CEC pin in such a way that it
>>> is unavailable when the HPD is low.
>>>
>>> Signed-off-by: Hans Verkuil 
>>> Cc: Krzysztof Kozlowski 
>>> Cc: Andrzej Hajda 
>>> Cc: devicet...@vger.kernel.org
>>> ---
>>>  Documentation/devicetree/bindings/media/s5p-cec.txt | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
>>> b/Documentation/devicetree/bindings/media/s5p-cec.txt
>>> index 4bb08d9d940b..261af4d1a791 100644
>>> --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
>>> +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
>>> @@ -17,6 +17,12 @@ Required properties:
>>>- samsung,syscon-phandle - phandle to the PMU system controller
>>>- hdmi-phandle - phandle to the HDMI controller
>>>
>>> +Optional:
>>> +  - needs-hpd : if present the CEC support is only available when the HPD
>>> +is high. Some boards only let the CEC pin through if the HPD is high, 
>>> for
>>> +example if there is a level converter that uses the HPD to power up
>>> +or down.
>>
>> Seems like something common. Can you document in a common location?
>
> Should we do the same with hdmi-phandle? It is also used by CEC drivers to 
> find
> the HDMI driver.

Yes.

> Currently only used by s5p-cec and stih-cec, but there will be more.
>
> I guess this would be a sensible place to document this:
>
> Documentation/devicetree/bindings/media/cec.txt

Sounds good. You can do this as a follow-up to this patch if you want.
For this one:

Acked-by: Rob Herring 

[PATCH v7 7/7] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
device represents a channel and each channel can have one or two
sub-channels respectively depending on the target board.

DRIF supports only Rx functionality. It receives samples from a RF
frontend tuner chip it is interfaced with. The combination of DRIF and the
tuner device, which is registered as a sub-device, determines the receive
sample rate and format.

In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
the tuner device, which can be provided by a third party vendor. DRIF acts
as a slave device and the tuner device acts as a master transmitting the
samples. The driver allows asynchronous binding of a tuner device that
is registered as a v4l2 sub-device. The driver can learn about the tuner
it is interfaced with based on port endpoint properties of the device in
device tree. The V4L2 SDR device inherits the controls exposed by the
tuner device.

The device can also be configured to use either one or both of the data
pins at runtime based on the master (tuner) configuration.

Signed-off-by: Ramesh Shanmugasundaram 
---
v7:
 - Added COMPILE_TEST to rcar_drif (Hans added it in last pull request).
 
v6:
 - Used fwnode_ apis wherever applicable.
 - Cleaned up debug prints.
---
 drivers/media/platform/Kconfig |   25 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/rcar_drif.c | 1500 
 3 files changed, 1526 insertions(+)
 create mode 100644 drivers/media/platform/rcar_drif.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 288d3b0dc812..a2fc37d0d29e 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -538,3 +538,28 @@ config VIDEO_STI_HDMI_CEC
  between compatible devices.
 
 endif #CEC_PLATFORM_DRIVERS
+
+menuconfig SDR_PLATFORM_DRIVERS
+   bool "SDR platform devices"
+   depends on MEDIA_SDR_SUPPORT
+   default n
+   ---help---
+ Say Y here to enable support for platform-specific SDR Drivers.
+
+if SDR_PLATFORM_DRIVERS
+
+config VIDEO_RCAR_DRIF
+   tristate "Renesas Digitial Radio Interface (DRIF)"
+   depends on VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select VIDEOBUF2_VMALLOC
+   ---help---
+ Say Y if you want to enable R-Car Gen3 DRIF support. DRIF is Digital
+ Radio Interface that interfaces with an RF front end chip. It is a
+ receiver of digital data which uses DMA to transfer received data to
+ a configured location for an application to use.
+
+ To compile this driver as a module, choose M here; the module
+ will be called rcar_drif.
+
+endif # SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c3588d570f5d..4cfbb9d0c6cf 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
+obj-$(CONFIG_VIDEO_RCAR_DRIF)  += rcar_drif.o
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
diff --git a/drivers/media/platform/rcar_drif.c 
b/drivers/media/platform/rcar_drif.c
new file mode 100644
index ..1f00bbe501bf
--- /dev/null
+++ b/drivers/media/platform/rcar_drif.c
@@ -0,0 +1,1500 @@
+/*
+ * R-Car Gen3 Digital Radio Interface (DRIF) driver
+ *
+ * Copyright (C) 2017 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ */
+
+/*
+ * The R-Car DRIF is a receive only MSIOF like controller with an
+ * external master device driving the SCK. It receives data into a FIFO,
+ * then this driver uses the SYS-DMAC engine to move the data from
+ * the device to memory.
+ *
+ * Each DRIF channel DRIFx (as per datasheet) contains two internal
+ * channels DRIFx0 & DRIFx1 within itself with each having its own resources
+ * like module clk, register set, irq and dma. These internal channels share
+ * common CLK & SYNC from master. The two data pins D0 & D1 shall be
+ * considered to represent the two internal channels. This internal split
+ * is not visible to the master device.
+ *
+ * Depending on the master device, a DRIF channel can use
+ *  (1) 

[PATCH v7 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

[Ramesh Shanmugasundaram]

Add binding documentation for Renesas R-Car Digital Radio Interface
(DRIF) controller.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/renesas,drif.txt | 176 +
 1 file changed, 176 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt 
b/Documentation/devicetree/bindings/media/renesas,drif.txt
new file mode 100644
index ..39516b94c28f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
@@ -0,0 +1,176 @@
+Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
+
+
+R-Car Gen3 DRIF is a SPI like receive only slave device. A general
+representation of DRIF interfacing with a master device is shown below.
+
++-++-+
+| |-SCK--->|CLK  |
+|   Master|-SS>|SYNC  DRIFn (slave)  |
+| |-SD0--->|D0   |
+| |-SD1--->|D1   |
++-++-+
+
+As per datasheet, each DRIF channel (drifn) is made up of two internal
+channels (drifn0 & drifn1). These two internal channels share the common
+CLK & SYNC. Each internal channel has its own dedicated resources like
+irq, dma channels, address space & clock. This internal split is not
+visible to the external master device.
+
+The device tree model represents each internal channel as a separate node.
+The internal channels sharing the CLK & SYNC are tied together by their
+phandles using a property called "renesas,bonding". For the rest of
+the documentation, unless explicitly stated, the word channel implies an
+internal channel.
+
+When both internal channels are enabled they need to be managed together
+as one (i.e.) they cannot operate alone as independent devices. Out of the
+two, one of them needs to act as a primary device that accepts common
+properties of both the internal channels. This channel is identified by a
+property called "renesas,primary-bond".
+
+To summarize,
+   - When both the internal channels that are bonded together are enabled,
+ the zeroth channel is selected as primary-bond. This channels accepts
+ properties common to all the members of the bond.
+   - When only one of the bonded channels need to be enabled, the property
+ "renesas,bonding" or "renesas,primary-bond" will have no effect. That
+ enabled channel can act alone as any other independent device.
+
+Required properties of an internal channel:
+---
+- compatible:  "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 
SoC.
+   "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible 
device.
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
+- reg: offset and length of that channel.
+- interrupts: associated with that channel.
+- clocks: phandle and clock specifier of that channel.
+- clock-names: clock input name string: "fck".
+- dmas: phandles to the DMA channels.
+- dma-names: names of the DMA channel: "rx".
+- renesas,bonding: phandle to the other channel.
+
+Optional properties of an internal channel:
+---
+- power-domains: phandle to the respective power domain.
+
+Required properties of an internal channel when:
+   - It is the only enabled channel of the bond (or)
+   - If it acts as primary among enabled bonds
+
+- pinctrl-0: pin control group to be used for this channel.
+- pinctrl-names: must be "default".
+- renesas,primary-bond: empty property indicating the channel acts as primary
+   among the bonded channels.
+- port: child port node corresponding to the data input, in accordance with
+   the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The port
+   node must contain at least one endpoint.
+
+Optional endpoint property:
+---
+- sync-active: Indicates sync signal polarity, 0/1 for low/high respectively.
+  This property maps to SYNCAC bit in the hardware manual. The
+  default is 1 (active high).
+
+Example:
+
+
+(1) Both internal channels enabled:
+---
+
+When interfacing with a third party tuner device with two data pins as shown
+below.
+
++-++-+
+| |-SCK--->|CLK  |
+|   

[PATCH v7 4/7] media: Add new SDR formats PC16, PC18 & PC20

[Ramesh Shanmugasundaram]

This patch adds support for the three new SDR formats. These formats
were prefixed with "planar" indicating I & Q data are not interleaved
as in other formats. Here, I & Q data constitutes the top half and bottom
half of the received buffer respectively.

V4L2_SDR_FMT_PCU16BE - 14-bit complex (I & Q) unsigned big-endian sample
inside 16-bit. V4L2 FourCC: PC16

V4L2_SDR_FMT_PCU18BE - 16-bit complex (I & Q) unsigned big-endian sample
inside 18-bit. V4L2 FourCC: PC18

V4L2_SDR_FMT_PCU20BE - 18-bit complex (I & Q) unsigned big-endian sample
inside 20-bit. V4L2 FourCC: PC20

Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
 include/uapi/linux/videodev2.h   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 4f27cfa134a1..ce40183d9daa 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1229,6 +1229,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
+   case V4L2_SDR_FMT_PCU16BE:  descr = "Planar Complex U16BE"; break;
+   case V4L2_SDR_FMT_PCU18BE:  descr = "Planar Complex U18BE"; break;
+   case V4L2_SDR_FMT_PCU20BE:  descr = "Planar Complex U20BE"; break;
case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data"; 
break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2b8feb86d09e..45cf7359822c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -669,6 +669,9 @@ struct v4l2_pix_format {
 #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /* complex 
s8 */
 #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /* complex 
s14le */
 #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /* real 
u12le */
+#define V4L2_SDR_FMT_PCU16BE v4l2_fourcc('P', 'C', '1', '6') /* planar 
complex u16be */
+#define V4L2_SDR_FMT_PCU18BE v4l2_fourcc('P', 'C', '1', '8') /* planar 
complex u18be */
+#define V4L2_SDR_FMT_PCU20BE v4l2_fourcc('P', 'C', '2', '0') /* planar 
complex u20be */
 
 /* Touch formats - used for Touch devices */
 #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 
16-bit signed deltas */
-- 
2.12.2

[PATCH v7 5/7] doc_rst: media: New SDR formats PC16, PC18 & PC20

[Ramesh Shanmugasundaram]

This patch adds documentation for the three new SDR formats

V4L2_SDR_FMT_PCU16BE
V4L2_SDR_FMT_PCU18BE
V4L2_SDR_FMT_PCU20BE

Signed-off-by: Ramesh Shanmugasundaram 
---
 .../media/uapi/v4l/pixfmt-sdr-pcu16be.rst  | 55 ++
 .../media/uapi/v4l/pixfmt-sdr-pcu18be.rst  | 55 ++
 .../media/uapi/v4l/pixfmt-sdr-pcu20be.rst  | 54 +
 Documentation/media/uapi/v4l/sdr-formats.rst   |  3 ++
 4 files changed, 167 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
new file mode 100644
index ..2de1b1a0f517
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-PCU16BE:
+
+**
+V4L2_SDR_FMT_PCU16BE ('PC16')
+**
+
+Planar complex unsigned 16-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 16 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+  -  Byte B0
+  -  Byte B1
+  -  Byte B2
+  -  Byte B3
+* -  start + 0:
+  -  I'\ :sub:`0[13:6]`
+  -  I'\ :sub:`0[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* -  start + 4:
+  -  I'\ :sub:`1[13:6]`
+  -  I'\ :sub:`1[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* -  ...
+* - start + offset:
+  -  Q'\ :sub:`0[13:6]`
+  -  Q'\ :sub:`0[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* - start + offset + 4:
+  -  Q'\ :sub:`1[13:6]`
+  -  Q'\ :sub:`1[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
new file mode 100644
index ..da8b26bf6b95
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-PCU18BE:
+
+**
+V4L2_SDR_FMT_PCU18BE ('PC18')
+**
+
+Planar complex unsigned 18-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 18 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 18 bits, bit 17:2 (16 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+  -  Byte B0
+  -  Byte B1
+  -  Byte B2
+  -  Byte B3
+* -  start + 0:
+  -  I'\ :sub:`0[17:10]`
+  -  I'\ :sub:`0[9:2]`
+  -  I'\ :sub:`0[1:0]; B2[5:0]=pad`
+  -  pad
+* -  start + 4:
+  -  I'\ :sub:`1[17:10]`
+  -  I'\ :sub:`1[9:2]`
+  -  I'\ :sub:`1[1:0]; B2[5:0]=pad`
+  -  pad
+* -  ...
+* - start + offset:
+  -  Q'\ :sub:`0[17:10]`
+  -  Q'\ :sub:`0[9:2]`
+  -  Q'\ :sub:`0[1:0]; B2[5:0]=pad`
+  -  pad
+* - start + offset + 4:
+  -  Q'\ :sub:`1[17:10]`
+  -  Q'\ :sub:`1[9:2]`
+  -  Q'\ :sub:`1[1:0]; B2[5:0]=pad`
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
new file mode 100644
index ..5499eed39477
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
@@ -0,0 +1,54 @@
+.. -*- coding: utf-8; mode: rst -*-
+.. _V4L2-SDR-FMT-PCU20BE:
+
+**
+V4L2_SDR_FMT_PCU20BE ('PC20')
+**
+
+Planar complex unsigned 20-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 20 bit unsigned big endian number stored in
+32 

[PATCH v7 3/7] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

This patch adds driver support for the MAX2175 chip. This is Maxim
Integrated's RF to Bits tuner front end chip designed for software-defined
radio solutions. This driver exposes the tuner as a sub-device instance
with standard and custom controls to configure the device.

Signed-off-by: Ramesh Shanmugasundaram 
---
v7:
 - Made I2S enable/disable control as private (Mauro).
 
v6:
 - Addressed Sakari's comments. They are:
- Added uapi header file.
- Added newline at the end of the function before return.
- Cleaned up header file inclusion.
- Used fwnode_ apis whereever applicable.
- Cleaned up debug statements.
- Removed separate dir for max2175.
v5:
 - sck -> Sample clock is clarified in driver documentation (Hans)
 - "refout-load-pF" is renamed to "refout-load" as per updated bindings.
---
 Documentation/media/v4l-drivers/index.rst   |1 +
 Documentation/media/v4l-drivers/max2175.rst |   62 ++
 drivers/media/i2c/Kconfig   |   12 +
 drivers/media/i2c/Makefile  |2 +
 drivers/media/i2c/max2175.c | 1453 +++
 drivers/media/i2c/max2175.h |  109 ++
 include/uapi/linux/max2175.h|   28 +
 7 files changed, 1667 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/max2175.rst
 create mode 100644 drivers/media/i2c/max2175.c
 create mode 100644 drivers/media/i2c/max2175.h
 create mode 100644 include/uapi/linux/max2175.h

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 90fe22a6414a..2e24d6806052 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
davinci-vpbe
fimc
ivtv
+   max2175
meye
omap3isp
omap4_camera
diff --git a/Documentation/media/v4l-drivers/max2175.rst 
b/Documentation/media/v4l-drivers/max2175.rst
new file mode 100644
index ..04478c25d57a
--- /dev/null
+++ b/Documentation/media/v4l-drivers/max2175.rst
@@ -0,0 +1,62 @@
+Maxim Integrated MAX2175 RF to bits tuner driver
+
+
+The MAX2175 driver implements the following driver-specific controls:
+
+``V4L2_CID_MAX2175_I2S_ENABLE``
+---
+Enable/Disable I2S output of the tuner. This is a private control
+that can be accessed only using the subdev interface.
+Refer to Documentation/media/kapi/v4l2-controls for more details.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - I2S output is disabled.
+* - ``(1)``
+  - I2S output is enabled.
+
+``V4L2_CID_MAX2175_HSLS``
+-
+The high-side/low-side (HSLS) control of the tuner for a given band.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - The LO frequency position is below the desired frequency.
+* - ``(1)``
+  - The LO frequency position is above the desired frequency.
+
+``V4L2_CID_MAX2175_RX_MODE (menu)``
+---
+The Rx mode controls a number of preset parameters of the tuner like
+sample clock (sck), sampling rate etc. These multiple settings are
+provided under one single label called Rx mode in the datasheet. The
+list below shows the supported modes with a brief description.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``"Europe modes"``
+* - ``"FM 1.2" (0)``
+  - This configures FM band with a sample rate of 0.512 million
+samples/sec with a 10.24 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures VHF band with a sample rate of 2.048 million
+samples/sec with a 32.768 MHz sck.
+
+* - ``"North America modes"``
+* - ``"FM 1.0" (0)``
+  - This configures FM band with a sample rate of 0.7441875 million
+samples/sec with a 14.88375 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures FM band with a sample rate of 0.372 million
+samples/sec with a 7.441875 MHz sck.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e2475c82..c0e6e78883b0 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -796,6 +796,18 @@ config VIDEO_SAA6752HS
  To compile this driver as a module, choose M here: the
  module will be called saa6752hs.
 
+comment "SDR tuner chips"
+
+config SDR_MAX2175
+   tristate "Maxim 2175 RF to Bits tuner"
+   depends on VIDEO_V4L2 && MEDIA_SDR_SUPPORT && I2C
+   ---help---
+ Support for Maxim 2175 tuner. It is an advanced analog/digital
+ radio receiver with RF-to-Bits front-end designed for SDR solutions.
+
+ To 

[PATCH v7 1/7] media: v4l2-ctrls: Reserve controls for MAX217X

[Ramesh Shanmugasundaram]

Reserve controls for MAX217X RF to Bits tuner family. These hybrid
radio receiver chips are highly programmable and hence reserving 32
controls.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Laurent Pinchart 
---
 include/uapi/linux/v4l2-controls.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 0d2e1e01fbd5..83b28b41123f 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -180,6 +180,11 @@ enum v4l2_colorfx {
  * We reserve 16 controls for this driver. */
 #define V4L2_CID_USER_TC358743_BASE(V4L2_CID_USER_BASE + 0x1080)
 
+/* The base for the max217x driver controls.
+ * We reserve 32 controls for this driver
+ */
+#define V4L2_CID_USER_MAX217X_BASE (V4L2_CID_USER_BASE + 0x1090)
+
 /* MPEG-class control IDs */
 /* The MPEG controls are applicable to all codec controls
  * and the 'MPEG' part of the define is historical */
-- 
2.12.2

[PATCH v7 2/7] dt-bindings: media: Add MAX2175 binding description

[Ramesh Shanmugasundaram]

Add device tree binding documentation for MAX2175 RF to bits tuner
device.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/i2c/max2175.txt  | 59 ++
 .../devicetree/bindings/property-units.txt |  1 +
 2 files changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
b/Documentation/devicetree/bindings/media/i2c/max2175.txt
new file mode 100644
index ..02b4e9cd7b1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
@@ -0,0 +1,59 @@
+Maxim Integrated MAX2175 RF to Bits tuner
+-
+
+The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
+RF to Bits® front-end designed for software-defined radio solutions.
+
+Required properties:
+
+- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
+- clocks: clock specifier.
+- port: child port node corresponding to the I2S output, in accordance with
+   the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The port
+   node must contain at least one endpoint.
+
+Optional properties:
+
+- maxim,master   : phandle to the master tuner if it is a slave. This
+   is used to define two tuners in diversity mode
+   (1 master, 1 slave). By default each tuner is an
+   individual master.
+- maxim,refout-load   : load capacitance value (in picofarads) on reference
+   output drive level. The possible load values are:
+0 (default - refout disabled)
+   10
+   20
+   30
+   40
+   60
+   70
+- maxim,am-hiz-filter : empty property indicates the AM Hi-Z filter is used
+   in this hardware for AM antenna input.
+
+Example:
+
+
+Board specific DTS file
+
+/* Fixed XTAL clock node */
+maxim_xtal: clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <36864000>;
+};
+
+/* A tuner device instance under i2c bus */
+max2175_0: tuner@60 {
+   compatible = "maxim,max2175";
+   reg = <0x60>;
+   clocks = <_xtal>;
+   maxim,refout-load = <10>;
+
+   port {
+   max2175_0_ep: endpoint {
+   remote-endpoint = <_rx_device>;
+   };
+   };
+
+};
diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 12278d79f6c0..7c9f6ee918f1 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -28,6 +28,7 @@ Electricity
 -ohms  : Ohms
 -micro-ohms: micro Ohms
 -microvolt : micro volts
+-picofarads: picofarads
 
 Temperature
 
-- 
2.12.2

[PATCH v7 0/7] Add V4L2 SDR (DRIF & MAX2175) driver

[Ramesh Shanmugasundaram]

Hi Mauro, Hans,

This patch set contains two drivers
 - Renesas R-Car Digital Radio Interface (DRIF) driver
 - Maxim's MAX2175 RF to Bits tuner driver

These patches were based on top of media_tree.
commit: 47f910f0e0deb880c2114811f7ea1ec115a19ee4

These two drivers combined together expose a V4L2 SDR device that is compliant
with the V4L2 framework [1]. Agreed review comments are incorporated in this
series.

The rcar_drif device is modelled using "renesas,bonding" property. The
discussion on this property is available here [2].

Change history:

v6 -> v7:
 - MAX2175 I2S enable/disable control is made private (Mauro #v4l)
 - Added COMPILE_TEST to rcar_drif in Kconfig (Hans)

v5 -> v6:
 - Addressed Sakari's comments & rebased to his branch.
 - Used fwnode_ instead of of_ apis whereever applicable.

v4 -> v5:
 - Minor documentation changes. Refer individual patches.

v3 -> v4:
 - Added ACKs
rcar_drif:
 - Incorporated a number of review comments from Laurent on DRIF driver.
 - Addressed comments from Rob and Laurent on bindings.
max2175:
 - Minor changes addressing Hans and Laurent's comments

v2 -> v3:
rcar_drif:
 - Reduced DRIF DT properties to expose tested I2S mode only (Hans - discussion 
on #v4l)
 - Fixed error path clean up of ctrl_hdl on rcar_drif

v1 -> v2:
 - SDR formats renamed as "planar" instead of sliced (Hans)
 - Documentation formatting correction (Laurent)

 rcar_drif:
 - DT model using "bonding" property
 - Addressed Laurent's coments on bindings - DT optional parameters rename & 
rework
 - Addressed Han's comments on driver
 - Addressed Geert's comments on DT

 max2175:
 - Avoided scaling using method proposed by Antti. Thanks
 - Bindings is a separate patch (Rob)
 - Addressed Rob's comment on bindings
 - Added Custom controls documentation (Laurent)

[1] v4l2-compliance report:
root@salvator-x:~# v4l2-compliance -S /dev/swradio0
v4l2-compliance SHA   : d57bb8af0c71d82b702e35a7362aa077189dd593

Driver Info:
Driver name   : rcar_drif
Card type : R-Car DRIF
Bus info  : platform:R-Car DRIF
Driver version: 4.12.0
Capabilities  : 0x8531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/swradio0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second sdr 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
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK
test VIDIOC_G/S_FREQUENCY: OK
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: 1

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK
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: 2

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 (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test 

Re: [PATCH v8 02/34] [media] dt-bindings: Add bindings for i.MX media driver

[Rob Herring]

On Thu, Jun 08, 2017 at 10:08:35AM -0700, Steve Longerbeam wrote:
> 
> 
> On 06/08/2017 09:45 AM, Steve Longerbeam wrote:
> > Hi Rob, Mark,
> > 
> > Are there any remaining technical issues with this
> > binding doc? At this point an Ack from you is the only
> > thing holding up merge of the imx-media driver.
> > 
> > 
> 
> Note that the Synopsys core in the i.MX6 is a differently configured
> Synopsys core from the core as described in the bindings at [1].
> 
> Russell King provided more information on the differences between these
> cores at [2]. They are essentially different devices.
> 
> So perhaps the "snps,dw-mipi-csi2" compatibility needs to be removed
> from this binding, for now, until this driver is moved to drivers/media/
> and is made compatible with other MIPI CSI-2 Synopsys cores with
> different configurations.

Yes, it probably should be dropped. With that,

Acked-by: Rob Herring 

Re: [PATCH 7/9] dt-bindings: media/s5p-cec.txt: document needs-hpd property

[Hans Verkuil]

On 09/06/17 16:07, Rob Herring wrote:
> On Wed, Jun 07, 2017 at 04:46:14PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Needed for boards that wire the CEC pin in such a way that it
>> is unavailable when the HPD is low.
>>
>> Signed-off-by: Hans Verkuil 
>> Cc: Krzysztof Kozlowski 
>> Cc: Andrzej Hajda 
>> Cc: devicet...@vger.kernel.org
>> ---
>>  Documentation/devicetree/bindings/media/s5p-cec.txt | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
>> b/Documentation/devicetree/bindings/media/s5p-cec.txt
>> index 4bb08d9d940b..261af4d1a791 100644
>> --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
>> +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
>> @@ -17,6 +17,12 @@ Required properties:
>>- samsung,syscon-phandle - phandle to the PMU system controller
>>- hdmi-phandle - phandle to the HDMI controller
>>  
>> +Optional:
>> +  - needs-hpd : if present the CEC support is only available when the HPD
>> +is high. Some boards only let the CEC pin through if the HPD is high, 
>> for
>> +example if there is a level converter that uses the HPD to power up
>> +or down.
> 
> Seems like something common. Can you document in a common location?

Should we do the same with hdmi-phandle? It is also used by CEC drivers to find
the HDMI driver.

Currently only used by s5p-cec and stih-cec, but there will be more.

I guess this would be a sensible place to document this:

Documentation/devicetree/bindings/media/cec.txt

Regards,

Hans

> 
>> +
>>  Example:
>>  
>>  hdmicec: cec@100B {
>> -- 
>> 2.11.0
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/9] dt-bindings: media/s5p-cec.txt: document needs-hpd property

[Rob Herring]

On Wed, Jun 07, 2017 at 04:46:14PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Needed for boards that wire the CEC pin in such a way that it
> is unavailable when the HPD is low.
> 
> Signed-off-by: Hans Verkuil 
> Cc: Krzysztof Kozlowski 
> Cc: Andrzej Hajda 
> Cc: devicet...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/media/s5p-cec.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
> b/Documentation/devicetree/bindings/media/s5p-cec.txt
> index 4bb08d9d940b..261af4d1a791 100644
> --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
> @@ -17,6 +17,12 @@ Required properties:
>- samsung,syscon-phandle - phandle to the PMU system controller
>- hdmi-phandle - phandle to the HDMI controller
>  
> +Optional:
> +  - needs-hpd : if present the CEC support is only available when the HPD
> +is high. Some boards only let the CEC pin through if the HPD is high, for
> +example if there is a level converter that uses the HPD to power up
> +or down.

Seems like something common. Can you document in a common location?

> +
>  Example:
>  
>  hdmicec: cec@100B {
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] v4l: controls: Improve documentation for V4L2_CID_GAIN

[Sakari Ailus]

Elaborate the differences between V4L2_CID_GAIN and gain-type specific
V4L2_CID_DIGITAL_GAIN and V4L2_CID_ANALOGUE_GAIN.

Signed-off-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/control.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/media/uapi/v4l/control.rst 
b/Documentation/media/uapi/v4l/control.rst
index 51112ba..c1e6adb 100644
--- a/Documentation/media/uapi/v4l/control.rst
+++ b/Documentation/media/uapi/v4l/control.rst
@@ -137,6 +137,12 @@ Control IDs
 ``V4L2_CID_GAIN`` ``(integer)``
 Gain control.
 
+Primarily used to control gain on e.g. TV tuners but also on
+webcams. Most devices control only digital gain with this control
+but on some this could include analogue gain as well. Devices that
+recognise the difference between digital and analogue gain use
+controls ``V4L2_CID_DIGITAL_GAIN`` and ``V4L2_CID_ANALOGUE_GAIN``.
+
 ``V4L2_CID_HFLIP`` ``(boolean)``
 Mirror the picture horizontally.
 
-- 
2.7.4

[PATCH v2 1/2] v4l: ctrls: Add a control for digital gain

[Sakari Ailus]

Add V4L2_CID_DIGITAL_GAIN to control explicitly digital gain.

We already have analogue gain control which the digital gain control
complements. Typically higher quality images are obtained using analogue
gain only as the digital gain does not add information to the image
(rather it may remove it).

Signed-off-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 7 +++
 drivers/media/v4l2-core/v4l2-ctrls.c   | 1 +
 include/uapi/linux/v4l2-controls.h | 2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 76c5b1a..9acc9cad 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3021,6 +3021,13 @@ Image Process Control IDs
 The video deinterlacing mode (such as Bob, Weave, ...). The menu items are
 driver specific and are documented in :ref:`v4l-drivers`.
 
+``V4L2_CID_DIGITAL_GAIN (integer)``
+Digital gain is the value by which all colour components
+are multiplied by. Typically the digital gain applied is the
+control value divided by e.g. 0x100, meaning that to get no
+digital gain the control value needs to be 0x100. The no-gain
+configuration is also typically the default.
+
 
 .. _dv-controls:
 
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 5aed7bd..36eede3 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -886,6 +886,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PIXEL_RATE:   return "Pixel Rate";
case V4L2_CID_TEST_PATTERN: return "Test Pattern";
case V4L2_CID_DEINTERLACING_MODE:   return "Deinterlacing Mode";
+   case V4L2_CID_DIGITAL_GAIN: return "Digital Gain";
 
/* DV controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 0d2e1e0..0cdb8eb 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -893,7 +893,7 @@ enum v4l2_jpeg_chroma_subsampling {
 #define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 2)
 #define V4L2_CID_TEST_PATTERN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 3)
 #define V4L2_CID_DEINTERLACING_MODE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 4)
-
+#define V4L2_CID_DIGITAL_GAIN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 5)
 
 /*  DV-class control IDs defined by V4L2 */
 #define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
-- 
2.7.4

[PATCH v2 0/2] Add explicit digital gain control, document gain controls better

[Sakari Ailus]

Hi folks,

This set includes two patches: one that adds digital gain control and
another that better documents the relationship between the gain controls.

changes since v1:

- Say that the no-gain digital gain configuration is typically the
  default. This was slightly unclear in the previous version and could
  have been understood as the default being 0x100.

Sakari Ailus (2):
  v4l: ctrls: Add a control for digital gain
  v4l: controls: Improve documentation for V4L2_CID_GAIN

 Documentation/media/uapi/v4l/control.rst   | 6 ++
 Documentation/media/uapi/v4l/extended-controls.rst | 7 +++
 drivers/media/v4l2-core/v4l2-ctrls.c   | 1 +
 include/uapi/linux/v4l2-controls.h | 2 +-
 4 files changed, 15 insertions(+), 1 deletion(-)

-- 
2.7.4

Re: [PATCH v8 19/34] media: Add i.MX media core driver

[Philipp Zabel]

On Wed, 2017-06-07 at 11:33 -0700, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 
> 
> Switch from the v4l2_of_ APIs to the v4l2_fwnode_ APIs.
> 
> Signed-off-by: Philipp Zabel 
> 
> Add the bayer formats to imx-media's list of supported pixel and bus
> formats.
> 
> Signed-off-by: Russell King 
> ---
[...]
> diff --git a/drivers/staging/media/imx/imx-media-dev.c 
> b/drivers/staging/media/imx/imx-media-dev.c
> new file mode 100644
> index 000..da694f6
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-dev.c
> @@ -0,0 +1,666 @@
[...]
> +/*
> + * adds given video device to given imx-media source pad vdev list.
> + * Continues upstream from the pad entity's sink pads.
> + */
> +static int imx_media_add_vdev_to_pad(struct imx_media_dev *imxmd,
> +  struct imx_media_video_dev *vdev,
> +  struct media_pad *srcpad)
> +{
> + struct media_entity *entity = srcpad->entity;
> + struct imx_media_subdev *imxsd;
> + struct imx_media_pad *imxpad;
> + struct media_link *link;
> + struct v4l2_subdev *sd;
> + int i, vdev_idx, ret;
> +
> + if (!is_media_entity_v4l2_subdev(entity))
> + return -EINVAL;

Could we make this return 0, to just skip non-v4l2_subdev entities?
Currently, imx_media_probe_complete silently fails with this -EINVAL if
there is a tvp5150 connected due to the separate media entities that the
tvp5150 driver creates for the input connectors (Composite0, for
example).

regards
Philipp

[PATCH] rcar-vin: add support for V4L2_FIELD_SEQ_{TB,BT}

[Niklas Söderlund]

The hardware do not support capturing the field types V4L2_FIELD_SEQ_TB
and V4L2_FIELD_SEQ_BT. To capture in these formats the driver needs to
change what field (top or bottom) is to be captured next and for every
other capture adjust the offset of the capture buffer.

This patch adds support for these sequential fields with the limitation
that continues capture mode is not supported. This limitation have no
visibility for user-space and the driver can already be running in
single capture mode for all other field types if the driver is not feed
buffers quickly enough.

Signed-off-by: Niklas Söderlund 
---

Based on top of '[PATCH v4 00/27] rcar-vin: Add Gen3 with media 
controller support'. Tested on Gen2 M2 Koelsch and Gen3 Salvator-X H3 
and M3.

Test procedure documented on http://elinux.org/R-Car/Tests:rcar-vin

 drivers/media/platform/rcar-vin/rcar-dma.c  | 67 +++-
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 68 -
 2 files changed, 124 insertions(+), 11 deletions(-)


diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index a4764907d2bdbfbc..3a2eeaf120414069 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -96,6 +96,7 @@
 #define VNMC_IM_ODD_EVEN   (1 << 3)
 #define VNMC_IM_EVEN   (2 << 3)
 #define VNMC_IM_FULL   (3 << 3)
+#define VNMC_IM_MASK   0x18
 #define VNMC_BPS   (1 << 1)
 #define VNMC_ME(1 << 0)
 
@@ -640,6 +641,12 @@ static int rvin_setup(struct rvin_dev *vin)
case V4L2_FIELD_INTERLACED_BT:
vnmc = VNMC_IM_FULL | VNMC_FOC;
break;
+   case V4L2_FIELD_SEQ_TB:
+   vnmc = VNMC_IM_ODD;
+   break;
+   case V4L2_FIELD_SEQ_BT:
+   vnmc = VNMC_IM_EVEN;
+   break;
case V4L2_FIELD_ALTERNATE:
case V4L2_FIELD_NONE:
if (vin->continuous) {
@@ -895,6 +902,11 @@ static int rvin_capture_start(struct rvin_dev *vin)
/* Continuous capture requires more buffers then there are HW slots */
vin->continuous = bufs > HW_BUFFER_NUM;
 
+   /* We can't support continues mode for sequential field formats */
+   if (vin->format.field == V4L2_FIELD_SEQ_TB ||
+   vin->format.field == V4L2_FIELD_SEQ_BT)
+   vin->continuous = false;
+
if (!rvin_fill_hw(vin)) {
vin_err(vin, "HW not ready to start, not enough buffers 
available\n");
return -EINVAL;
@@ -930,6 +942,55 @@ static void rvin_capture_stop(struct rvin_dev *vin)
 #define RVIN_TIMEOUT_MS 100
 #define RVIN_RETRIES 10
 
+static bool rvin_seq_field_done(struct rvin_dev *vin)
+{
+   dma_addr_t phys_addr;
+   u32 vnmc, next;
+
+   /* Only handle sequential formats */
+   if (vin->format.field != V4L2_FIELD_SEQ_TB &&
+   vin->format.field != V4L2_FIELD_SEQ_BT)
+   return true;
+
+   /* Update field for next capture */
+   vnmc = rvin_read(vin, VNMC_REG);
+   next = (vnmc & VNMC_IM_MASK) == VNMC_IM_ODD ?
+   VNMC_IM_EVEN : VNMC_IM_ODD;
+
+   vin_dbg(vin, "SEQ Mode: %s Cap: %s Next: %s\n",
+   vin->format.field == V4L2_FIELD_SEQ_TB ? "TB" : "BT",
+   (vnmc & VNMC_IM_MASK) == VNMC_IM_ODD ? "T" : "B",
+   next == VNMC_IM_ODD ? "T" : "B");
+
+   vnmc = (vnmc & ~VNMC_IM_MASK) | next;
+   rvin_write(vin, vnmc, VNMC_REG);
+
+   /* If capture is second part of frame signal frame done */
+   if ((vin->format.field == V4L2_FIELD_SEQ_TB && next == VNMC_IM_ODD) ||
+   (vin->format.field == V4L2_FIELD_SEQ_BT && next == VNMC_IM_EVEN)) {
+   vin_dbg(vin, "SEQ frame done\n");
+   return true;
+   }
+
+   /*
+* Need to capture second half of the frame. Increment the
+* offset for the capture buffer so it appends to the already
+* captured first field. Start one new capture (in single mode)
+* and signal that frame is not complete.
+*/
+
+   vin_dbg(vin, "SEQ frame need to capture other half, frame not done\n");
+
+   phys_addr =
+   vb2_dma_contig_plane_dma_addr(>queue_buf[0]->vb2_buf, 0) +
+   vin->format.sizeimage / 2;
+   rvin_set_slot_addr(vin, 0, phys_addr);
+
+   rvin_capture_on(vin);
+
+   return false;
+}
+
 static irqreturn_t rvin_irq(int irq, void *data)
 {
struct rvin_dev *vin = data;
@@ -962,7 +1023,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
/* Prepare for capture and update state */
vnms = rvin_read(vin, VNMS_REG);
slot = rvin_get_active_slot(vin, vnms);
-   sequence = vin->sequence++;
+   sequence = vin->sequence;
 
vin_dbg(vin, "IRQ %02d: %d\tbuf0: %c buf1: %c buf2: %c\tmore: %d\n",
sequence, slot,
@@ 

Re: [PATCH 03/12] intel-ipu3: Add DMA API implementation

[Robin Murphy]

On 09/06/17 07:20, Tomasz Figa wrote:
> On Fri, Jun 9, 2017 at 3:07 AM, Robin Murphy  wrote:
>> On 08/06/17 15:35, Tomasz Figa wrote:
>>> On Thu, Jun 8, 2017 at 10:22 PM, Robin Murphy  wrote:
 On 07/06/17 10:47, Tomasz Figa wrote:
> Hi Yong,
>
> +Robin, Joerg, IOMMU ML
>
> Please see my comments inline.
>
> On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi  wrote:
>>> [snip]
>> +
>> +/* End of things adapted from arch/arm/mm/dma-mapping.c */
>> +static void ipu3_dmamap_sync_single_for_cpu(struct device *dev,
>> +   dma_addr_t dma_handle, 
>> size_t size,
>> +   enum dma_data_direction dir)
>> +{
>> +   struct ipu3_mmu *mmu = to_ipu3_mmu(dev);
>> +   dma_addr_t daddr = iommu_iova_to_phys(mmu->domain, dma_handle);
>> +
>> +   clflush_cache_range(phys_to_virt(daddr), size);
>
> You might need to consider another IOMMU on the way here. Generally,
> given that daddr is your MMU DMA address (not necessarily CPU physical
> address), you should be able to call
>
> dma_sync_single_for_cpu(, daddr, size, dir)

 I'd hope that this IPU complex is some kind of embedded endpoint thing
 that bypasses the VT-d IOMMU or is always using its own local RAM,
 because it would be pretty much unworkable otherwise.
>>>
>>> It uses system RAM and, as far as my understanding goes, by default it
>>> operates without the VT-d IOMMU and that's how it's used right now.
>>
>> OK, if it *is* behind a DMAR unit then booting with "iommu=force" (or
>> whatever the exact incantation for intel-iommu is) should be fun...
>>
>>> I'm suggesting VT-d IOMMU as a way to further strengthen the security
>>> and error resilience in future (due to the IPU complex being
>>> non-coherent and also running a closed source firmware).
>>
>> TBH, doing DMA remapping through *two* IOMMUS will add horrible hardware
>> overhead,
> 
> Not necessarily, if done right and with right hardware (I lack the
> details about Intel hardware unfortunately). One can for example
> notice the fact that the IOVA ranges from the parent IOMMU are going
> to be contiguous for the child IOMMU, so one could use huge pages in
> the child IOMMU and essentially make a selective 1:1 mapping.

Note that many IOMMUs don't actually implement TLBs for larger page
sizes, even if they support them. And that still doesn't really help the
main issue of the way in which nested table walks blow up exponentially:
For a n-level pagetable at the first level and an m-level table at the
second level, a single access by the device can become m * (n + 1)
memory accesses (and that's generously ignoring additional things like
source-ID-to-context lookups).

>> increase the scope for kernel-side bugs, and not much more. If
>> we don't trust this IOMMU to behave, why are we trying to drive it in
>> the first place? If we do, then a second IOMMU behind it won't protect
>> anything that the first one doesn't already.
> 
> That's a valid point, right. But on the other hand, I lack the
> hardware details on whether we can just disable the internal IOMMU and
> use DMAR alone instead.
> 
>>
 The whole
 infrastructure isn't really capable of dealing with nested IOMMUs, and
 nested DMA ops would be an equally horrible idea.
>>>
>>> Could you elaborate a bit more on this? I think we should be able to
>>> deal with this in a way I suggested before:
>>>
>>> a) the PCI device would use the system DMA ops,
>>> b) the PCI device would implement a secondary bus for which it would
>>> provide its own DMA and IOMMU ops.
>>> c) a secondary device would be registered on the secondary bus,
>>> d) all memory for the IPU would be managed on behalf of the secondary 
>>> device.
>>>
>>> In fact, the driver already is designed in a way that all the points
>>> above are true. If I'm not missing something, the only significant
>>> missing point is calling into system DMA ops from IPU DMA ops.
>>
>> I don't believe x86 has any non-coherent DMA ops, therefore the IPU DMA
>> ops would still probably have to do all their own cache maintenance.
> 
> I'd argue that it means that we need to add non-coherent DMA ops on
> x86, as we have on other archs, which can have both coherent and
> non-coherent devices in the same system.

I'd argue that that's what this patch *is* doing - x86 already has DMA
ops all over the place for special cases, and this is really just
another special case. I think trying to introduce some notion of
non-coherent devices to the arch code, plus some generic way to identify
them, plus some way to make sure everywhere else that overrides DMA ops
still does the right thing, would be a lot more work for very little gain.

>> Allocation/mapping, though, would have to be done with the parent DMA
>> ops first (in case DMA address != physical address), 

Re: [media-af9013] question about return value in function af9013_wr_regs()

[Antti Palosaari]

Gustavo A. R. Silva kirjoitti 2017-06-09 00:51:

Hello everybody,

While looking into Coverity ID 1227035 I ran into the following piece
of code at drivers/media/dvb-frontends/af9013.c:595:



The issue here is that the value stored in variable _ret_ at line 608,
 is not being evaluated as it happens at line 662, 667, 672 and 677.
Then after looking into function af9013_wr_regs(), I noticed that this
 function always returns zero, no matter what, as you can see below:

121static int af9013_wr_regs(struct af9013_state *priv, u16 reg, const  
u8 *val,

122int len)
123{
124int ret, i;
125u8 mbox = (0 << 7)|(0 << 6)|(1 << 1)|(1 << 0);
126
127if ((priv->config.ts_mode == AF9013_TS_USB) &&
128((reg & 0xff00) != 0xff00) && ((reg & 0xff00) != 
0xae00)) {

129mbox |= ((len - 1) << 2);
130ret = af9013_wr_regs_i2c(priv, mbox, reg, val, len);
131} else {
132for (i = 0; i < len; i++) {
133ret = af9013_wr_regs_i2c(priv, mbox, reg+i,
 val+i, 1);
134if (ret)
135goto err;
136}
137}
138
139err:
140return 0;
141}


That function should return error code on error case, not zero always.


regards
Antti




--
http://palosaari.fi/

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

[Tomasz Figa]

On Fri, Jun 9, 2017 at 5:26 PM, Tuukka Toivonen
 wrote:
> Hi Tomasz,
>
> Couple of small comments below.
>
> On Wednesday, June 07, 2017 17:35:13 Tomasz Figa wrote:
>> >> +static void ipu3_mmu_domain_free(struct iommu_domain *dom)
>> >> +{
>> >> +   struct ipu3_mmu_domain *mmu_dom =
>> >> +   container_of(dom, struct ipu3_mmu_domain, domain);
>> >> +   uint32_t l1_idx;
>> >> +
>> >> +   for (l1_idx = 0; l1_idx < IPU3_MMU_L1PT_PTES; l1_idx++)
>> >> +   if (mmu_dom->pgtbl[l1_idx] != mmu_dom-
>>dummy_l2_tbl)
>> >> +   free_page((unsigned long)
>> >> + TBL_VIRT_ADDR(mmu_dom-
>>pgtbl[l1_idx]));
>> >> +
>> >> +   free_page((unsigned long)TBL_VIRT_ADDR(mmu_dom-
>>dummy_page));
>> >> +   free_page((unsigned long)TBL_VIRT_ADDR(mmu_dom-
>>dummy_l2_tbl));
>>
>> I might be overly paranoid, but reading back kernel virtual pointers
>> from device accessible memory doesn't seem safe to me. Other drivers
>> keep kernel pointers of page tables in a dedicated array (it's only 8K
>> of memory, but much better safety).
>
> They are accessible only to the IPU3 IOMMU, which can access whole
> system memory anyway and always does a read-only access to the MMU
> tables. So, I wouldn't worry too much, although extra copy for safety
> wouldn't necessarily harm too much.

Fair enough. Thanks for explanation.

>
> <...>
>
>> >> +   ipu3_mmu_tlb_invalidate(mmu_dom->mmu->base);
>> >> +
>> >> +   return unmapped << IPU3_MMU_PAGE_SHIFT;
>> >> +}
>> >> +
>> >> +static phys_addr_t ipu3_mmu_iova_to_phys(struct iommu_domain
> *domain,
>> >> +dma_addr_t iova)
>> >> +{
>> >> +   struct ipu3_mmu_domain *d =
>> >> +   container_of(domain, struct ipu3_mmu_domain,
> domain);
>> >> +   uint32_t *l2_pt = TBL_VIRT_ADDR(d->pgtbl[iova >>
> IPU3_MMU_L1PT_SHIFT]);
>> >> +
>> >> +   return (phys_addr_t)l2_pt[(iova & IPU3_MMU_L2PT_MASK)
>> >> +   >> IPU3_MMU_L2PT_SHIFT] <<
> IPU3_MMU_PAGE_SHIFT;
>>
>> Could we avoid this TBL_VIRT_ADDR() here too? The memory cost to store
>> the page table CPU pointers is really small, but safety seems much
>> better. Moreover, it should make it possible to use the VT-d IOMMU to
>> further secure the system.
>
> IPU3 doesn't support VT-d and can't be enabled while VT-d is on.

Got it. Thanks.

Best regards,
Tomasz

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

[Tomasz Figa]

On Fri, Jun 9, 2017 at 8:16 PM, Sakari Ailus  wrote:
> Hi Tomasz,
>
> On Fri, Jun 09, 2017 at 02:59:10PM +0900, Tomasz Figa wrote:
>> On Fri, Jun 9, 2017 at 1:43 AM, Sakari Ailus  wrote:
>> >> >> +static void ipu3_mmu_domain_free(struct iommu_domain *dom)
>> >> >> +{
>> >> >> +   struct ipu3_mmu_domain *mmu_dom =
>> >> >> +   container_of(dom, struct ipu3_mmu_domain, domain);
>> >> >> +   uint32_t l1_idx;
>> >> >> +
>> >> >> +   for (l1_idx = 0; l1_idx < IPU3_MMU_L1PT_PTES; l1_idx++)
>> >> >> +   if (mmu_dom->pgtbl[l1_idx] != mmu_dom->dummy_l2_tbl)
>> >> >> +   free_page((unsigned long)
>> >> >> + 
>> >> >> TBL_VIRT_ADDR(mmu_dom->pgtbl[l1_idx]));
>> >> >> +
>> >> >> +   free_page((unsigned long)TBL_VIRT_ADDR(mmu_dom->dummy_page));
>> >> >> +   free_page((unsigned long)TBL_VIRT_ADDR(mmu_dom->dummy_l2_tbl));
>> >>
>> >> I might be overly paranoid, but reading back kernel virtual pointers
>> >> from device accessible memory doesn't seem safe to me. Other drivers
>> >> keep kernel pointers of page tables in a dedicated array (it's only 8K
>> >> of memory, but much better safety).
>> >
>> > Do you happen to have an example of that?
>>
>> Hmm, looks like I misread rockchip-iommu code. Let me quietly back off
>> from this claim, sorry.
>>
>> >
>> > All system memory typically is accessible for devices, I think you wanted 
>> > to
>> > say that the device is intended to access that memory. Albeit for reading
>> > only.
>>
>> Unless you activate DMAR and make only the memory you want to be
>> accessible to your devices. I know DMAR is a device too, but there is
>> a difference between a system level fixed function IOMMU and a PCI
>> device running a closed source firmware. Still, given Robin's reply,
>> current DMA and IOMMU frameworks might not be able to handle this
>> easily, so let's temporarily forget about this setup. We might revisit
>> it later, with incremental patches, anyway.
>
> I don't think it's needed because
>
> 1) The firmware running on the device only has access to memory mapped to it
> by the MMU and
>
> 2) the MMU L1 page table base address is not writable to the firmware.

If that's the case, then I guess it's fine indeed.

>> >> >> +static int ipu3_mmu_bus_remove(struct device *dev)
>> >> >> +{
>> >> >> +   struct ipu3_mmu *mmu = dev_get_drvdata(dev);
>> >> >> +
>> >> >> +   put_iova_domain(>iova_domain);
>> >> >> +   iova_cache_put();
>> >>
>> >> Don't we need to set the L1 table address to something invalid and
>> >> invalidate the TLB, so that the IOMMU doesn't reference the page freed
>> >> below anymore?
>> >
>> > I think the expectation is that if a device gets removed, its memory is
>> > unmapped by that time. Unmapping that memory will cause explicit TLB flush.
>>
>> Right, but that will only mark the L2 entries as invalid. The L1 table
>> will still point to the L2 tables installed earlier and the MMU page
>> directory register will still point to the L1 table, despite the call
>> below freeing all the associated memory.
>
> Ah. I think I misunderstood what I read the previous time.
>
> An alternative would be not to release the L1 page table and the dummy pages
> --- the MMU does not have a concept of an invalid page. Now that the domain
> is gone, you can't really use the MMU anyway, can you?

Yes, given the hardware design, that would make sense indeed.

Best regards,
Tomasz

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

[Sakari Ailus]

Hi Tomasz,

On Fri, Jun 09, 2017 at 02:59:10PM +0900, Tomasz Figa wrote:
> On Fri, Jun 9, 2017 at 1:43 AM, Sakari Ailus  wrote:
> >> >> +static void ipu3_mmu_domain_free(struct iommu_domain *dom)
> >> >> +{
> >> >> +   struct ipu3_mmu_domain *mmu_dom =
> >> >> +   container_of(dom, struct ipu3_mmu_domain, domain);
> >> >> +   uint32_t l1_idx;
> >> >> +
> >> >> +   for (l1_idx = 0; l1_idx < IPU3_MMU_L1PT_PTES; l1_idx++)
> >> >> +   if (mmu_dom->pgtbl[l1_idx] != mmu_dom->dummy_l2_tbl)
> >> >> +   free_page((unsigned long)
> >> >> + 
> >> >> TBL_VIRT_ADDR(mmu_dom->pgtbl[l1_idx]));
> >> >> +
> >> >> +   free_page((unsigned long)TBL_VIRT_ADDR(mmu_dom->dummy_page));
> >> >> +   free_page((unsigned long)TBL_VIRT_ADDR(mmu_dom->dummy_l2_tbl));
> >>
> >> I might be overly paranoid, but reading back kernel virtual pointers
> >> from device accessible memory doesn't seem safe to me. Other drivers
> >> keep kernel pointers of page tables in a dedicated array (it's only 8K
> >> of memory, but much better safety).
> >
> > Do you happen to have an example of that?
> 
> Hmm, looks like I misread rockchip-iommu code. Let me quietly back off
> from this claim, sorry.
> 
> >
> > All system memory typically is accessible for devices, I think you wanted to
> > say that the device is intended to access that memory. Albeit for reading
> > only.
> 
> Unless you activate DMAR and make only the memory you want to be
> accessible to your devices. I know DMAR is a device too, but there is
> a difference between a system level fixed function IOMMU and a PCI
> device running a closed source firmware. Still, given Robin's reply,
> current DMA and IOMMU frameworks might not be able to handle this
> easily, so let's temporarily forget about this setup. We might revisit
> it later, with incremental patches, anyway.

I don't think it's needed because

1) The firmware running on the device only has access to memory mapped to it
by the MMU and

2) the MMU L1 page table base address is not writable to the firmware.

> >> >> +static int ipu3_mmu_bus_remove(struct device *dev)
> >> >> +{
> >> >> +   struct ipu3_mmu *mmu = dev_get_drvdata(dev);
> >> >> +
> >> >> +   put_iova_domain(>iova_domain);
> >> >> +   iova_cache_put();
> >>
> >> Don't we need to set the L1 table address to something invalid and
> >> invalidate the TLB, so that the IOMMU doesn't reference the page freed
> >> below anymore?
> >
> > I think the expectation is that if a device gets removed, its memory is
> > unmapped by that time. Unmapping that memory will cause explicit TLB flush.
> 
> Right, but that will only mark the L2 entries as invalid. The L1 table
> will still point to the L2 tables installed earlier and the MMU page
> directory register will still point to the L1 table, despite the call
> below freeing all the associated memory.

Ah. I think I misunderstood what I read the previous time.

An alternative would be not to release the L1 page table and the dummy pages
--- the MMU does not have a concept of an invalid page. Now that the domain
is gone, you can't really use the MMU anyway, can you?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 01/12] videodev2.h, v4l2-ioctl: add IPU3 meta buffer format

[Sakari Ailus]

Hi Alan,

On Mon, Jun 05, 2017 at 09:43:27PM +0100, Alan Cox wrote:
> On Mon,  5 Jun 2017 15:39:06 -0500
> Yong Zhi  wrote:
> 
> > Add the IPU3 specific processing parameter format
> > V4L2_META_FMT_IPU3_PARAMS and metadata formats
> > for 3A and other statistics:
> > 
> >   V4L2_META_FMT_IPU3_PARAMS
> >   V4L2_META_FMT_IPU3_STAT_3A
> >   V4L2_META_FMT_IPU3_STAT_DVS
> >   V4L2_META_FMT_IPU3_STAT_LACE
> 
> Are these specific to IPU v3 or do they match other IPU versions ?

The parameters (V4L2_META_FMT_IPU3_PARAMS) are bound to be different (for
previous versions had a private IOCTL to pass them). There could be
similarities between different versions of the IPUs but they're still not
exactly the same. The hardware tends to change quite a bit between the
generations.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex

[Arnd Bergmann]

On Fri, Jun 9, 2017 at 6:37 AM, Binoy Jayan  wrote:
> On 8 June 2017 at 20:40, Arnd Bergmann  wrote:
>> On Thu, Jun 8, 2017 at 12:04 PM, Binoy Jayan  wrote:
>>> The semaphore 'cmd_mutex' is used as a simple mutex, so
>>> it should be written as one. Semaphores are going away in the future.
>>>
>>> Signed-off-by: Binoy Jayan 
>>> ---
>>
>>> @@ -1283,7 +1283,7 @@ static int ngene_load_firm(struct ngene *dev)
>>>
>>>  static void ngene_stop(struct ngene *dev)
>>>  {
>>> -   down(>cmd_mutex);
>>> +   mutex_lock(>cmd_mutex);
>>> i2c_del_adapter(&(dev->channel[0].i2c_adapter));
>>> i2c_del_adapter(&(dev->channel[1].i2c_adapter));
>>> ngwritel(0, NGENE_INT_ENABLE);
>>
>> Are you sure about this one? There is only one mutex_lock() and
>> then the structure gets freed without a corresponding mutex_unlock().
>>
>> I suspect this violates some rules of mutexes, either when compile
>> testing with "make C=1", or when running with lockdep enabled.
>>
>> Can we actually have a concurrently held mutex at the time we
>> get here? If not, using mutex_destroy() in place of the down()
>> may be the right answer.
>
> I noticed the missing 'up' here, but may be semaphores do not have
> to adhere to that rule?

The rules for semaphores are very lax, the up() and down() may
be in completely separate contexts, the up() can even happen from
an interrupt handler IIRC.

I read up on the sparse annotations now and found that it only
tracks spinlocks and rwlocks using the __acquires() annotation,
but not semaphores or mutexes.

I'm still not sure whether lockdep requires the mutex to be released
before it gets freed, the code may actually be fine, but it does
seem odd.

> Thank you for pointing out that. I'll check the
> concurrency part. By the way why do we need mutex_destoy?
> To debug an aberrate condition?

At first I suspected the down() here was added for the same
purpose as a mutex_destroy: to ensure that we are in a sane
state before we free the device structure, but the way they
achieve that is completely different.

However, if there is any way that a command may still be in
progress by the time we get to ngene_stop(), we may also
be lacking reference counting on the ngene structure here.
So far I haven't found any of those, and think the mutex_destroy()
is sufficient here as a debugging help.

   Arnd

Re: [PATCH v2 2/4] [media] davinci: vpif_capture: get subdevs from DT when available

[Sakari Ailus]

Hi Kevin,

On Thu, Jun 08, 2017 at 06:01:45PM -0700, Kevin Hilman wrote:
> On Wed, Jun 7, 2017 at 11:29 PM, Hans Verkuil  wrote:
> > On 07/06/17 01:37, Kevin Hilman wrote:
> >> Enable  getting of subdevs from DT ports and endpoints.
> >>
> >> The _get_pdata() function was larely inspired by (i.e. stolen from)
> >> am437x-vpfe.c
> >>
> >> Signed-off-by: Kevin Hilman 
> >> ---
> >>  drivers/media/platform/davinci/vpif_capture.c | 126 
> >> +-
> >>  drivers/media/platform/davinci/vpif_display.c |   5 +
> >>  include/media/davinci/vpif_types.h|   9 +-
> >>  3 files changed, 134 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c 
> >> b/drivers/media/platform/davinci/vpif_capture.c
> >> index fc5c7622660c..b9d927d1e5a8 100644
> >> --- a/drivers/media/platform/davinci/vpif_capture.c
> >> +++ b/drivers/media/platform/davinci/vpif_capture.c
> >> @@ -22,6 +22,8 @@
> >>  #include 
> >>
> >>  #include 
> >> +#include 
> >
> > v4l2-of.h no longer exists, so this v2 is wrong. Unfortunately this patch 
> > has
> > already been merged in our master. I'm not sure how this could have slipped 
> > past
> > both my and Mauro's patch testing (and yours, for that matter).
> 
> I have that file in the various trees I tested agains.
> 
> > Can you fix this and post a patch on top of the media master that makes this
> > compile again?
> 
> Sorry for the dumb question, but what tree are you referring to?  I
> tried the master branch of both [1] and [2] and both seem to have that
> include.

These patches are now merged as well as the changes requested:



-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v4] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

[Kieran Bingham]

Hi Sakari, Mauro,

On 08/06/17 21:10, Mauro Carvalho Chehab wrote:
> Em Thu, 8 Jun 2017 22:32:10 +0300
> Sakari Ailus  escreveu:
> 
>> Hi Mauro,
>>
>> On Thu, Jun 08, 2017 at 03:00:22PM -0300, Mauro Carvalho Chehab wrote:
>>> Em Wed,  7 Jun 2017 10:52:07 +0100
>>> Kieran Bingham  escreveu:
>>>   
 From: Kieran Bingham 

 Return NULL, if a null entity is parsed for it's v4l2_subdev

 Signed-off-by: Kieran Bingham   
>>>
>>> Could you please improve this patch description?
>>>
>>> I'm unsure if this is a bug fix, or some sort of feature...
>>>
>>> On what situations would a null entity be passed to this function? 

Sorry for not being clear enough there ...

>>
>> I actually proposed this patch. This change is simply for convenience ---
>> the caller doesn't need to make sure the subdev is non-NULL, possibly
>> obtained from e.g. media_entity_remote_pad() which returns NULL all links to
>> the pad are disabled. This is a recurring pattern, and making this change
>> avoids an additional check.
>>
>> Having something along these lines in the patch description wouldn't hurt.

Yes, the above looks good ...

> Patch added, with a description based on the above.

And thank you :)

Regards
--
Kieran

Re: [PATCH 05/12] intel-ipu3: css: tables

[Sakari Ailus]

On Thu, Jun 08, 2017 at 05:29:48PM +0900, Tomasz Figa wrote:
> Hi Yong,
> 
> On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi  wrote:
> > Coeff, config parameters etc const definitions for
> > IPU3 programming.
> >
> > Signed-off-by: Yong Zhi 
> > ---
> >  drivers/media/pci/intel/ipu3/ipu3-tables.c | 9621 
> > 
> >  drivers/media/pci/intel/ipu3/ipu3-tables.h |   82 +
> >  2 files changed, 9703 insertions(+)
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-tables.c
> >  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-tables.h
> 
> I wonder if this patch really reached the mailing list. It seems to
> not be present on patchwork.linuxtv.org. Possibly due to size
> restrictions.

Thanks for pointing this out.

I'm pushing the CIO2 and ImgU driver patches here:



It'll take some time still to get there...

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 11/12] intel-ipu3: Add imgu v4l2 driver

[Sakari Ailus]

Hi Hans,

On Tue, Jun 06, 2017 at 11:08:07AM +0200, Hans Verkuil wrote:
> > +   /* Initialize vdev */
> > +   strlcpy(vdev->name, node->name, sizeof(vdev->name));
> > +   vdev->release = video_device_release_empty;
> > +   vdev->fops = >v4l2_file_ops;
> > +   vdev->ioctl_ops = _v4l2_ioctl_ops;
> > +   vdev->lock = >lock;
> > +   vdev->v4l2_dev = >v4l2_dev;
> > +   vdev->queue = >vbq;
> > +   vdev->vfl_dir = node->output ? VFL_DIR_TX : VFL_DIR_RX;
> 
> Why have two video nodes (one tx, one rx) instead of a single m2m device
> node?
> 
> I'm not saying this is wrong, I just like to know the rationale for this
> design.

There are a bunch of outputs from the same input stream. Also the parameters
are needed to process the frame, I think there are two OUTPUT devices and
five CAPTURE devices.

Yong: could you send the media graph of the device, please?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[GIT PULL FOR v4.13] RC fixes

[Sean Young]

Hi Mauro,

Here is the fixed sir_ir mod param change and a change to remove an
unnecessary rc_dev member. This could not be merged earlier due to
conflicts with late v4.12 fixes.

Thanks
Sean

The following changes since commit 47f910f0e0deb880c2114811f7ea1ec115a19ee4:

  [media] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev (2017-06-08 
16:55:25 -0300)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.13c

for you to fetch changes up to 7d70c42f1d73c31594bb12b4df576858b5850b40:

  [media] rc-core: cleanup rc_register_device pt2 (2017-06-09 08:53:06 +0100)


David Härdeman (2):
  [media] rc-core: cleanup rc_register_device
  [media] rc-core: cleanup rc_register_device pt2

Sean Young (1):
  [media] sir_ir: annotate hardware config module parameters

 drivers/media/rc/rc-core-priv.h |   2 +
 drivers/media/rc/rc-ir-raw.c|  36 ++
 drivers/media/rc/rc-main.c  | 142 
 drivers/media/rc/sir_ir.c   |   4 +-
 include/media/rc-core.h |   2 -
 5 files changed, 86 insertions(+), 100 deletions(-)

[GIT PULL FOR v4.13] Add stm32-cec driver

[Hans Verkuil]

The following changes since commit 47f910f0e0deb880c2114811f7ea1ec115a19ee4:

  [media] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev (2017-06-08 
16:55:25 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git stm32-cec

for you to fetch changes up to bb4b9368c6836c21d76fa53aa425cd48ba0e94fb:

  cec: add STM32 cec driver (2017-06-09 10:35:50 +0200)


Benjamin Gaignard (2):
  dt-bindings: media: stm32 cec driver
  cec: add STM32 cec driver

 Documentation/devicetree/bindings/media/st,stm32-cec.txt |  19 +++
 drivers/media/platform/Kconfig   |  12 ++
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/stm32/Makefile|   1 +
 drivers/media/platform/stm32/stm32-cec.c | 362 
+
 5 files changed, 396 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32-cec.txt
 create mode 100644 drivers/media/platform/stm32/stm32-cec.c

[PATCH v9 0/1] [media] i2c: add support for OV13858 sensor

[Hyungwoo Yang]

I added HBLANK v4l2 control and marked it as read-only since VBLANK is enough
to control FPS.

Sensor also support digital gain so I added digital gain support by
using V4L2_CID_GAIN control.

Hyungwoo Yang (1):
  [media] i2c: add support for OV13858 sensor

 drivers/media/i2c/Kconfig   |8 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ov13858.c | 1811 +++
 3 files changed, 1820 insertions(+)
 create mode 100644 drivers/media/i2c/ov13858.c

-- 
1.9.1

[PATCH v9 1/1] [media] i2c: add support for OV13858 sensor

[Hyungwoo Yang]

This patch adds driver for Omnivision's ov13858
sensor, the driver supports following features:

- manual exposure/gain(analog and digital) control support
- two link frequencies
- VBLANK/HBLANK support
- test pattern support
- media controller support
- runtime pm support
- supported resolutions
  + 4224x3136 at 30FPS
  + 2112x1568 at 30FPS(default) and 60FPS
  + 2112x1188 at 30FPS(default) and 60FPS
  + 1056x784 at 30FPS(default) and 60FPS

Signed-off-by: Hyungwoo Yang 
---
 drivers/media/i2c/Kconfig   |8 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ov13858.c | 1811 +++
 3 files changed, 1820 insertions(+)
 create mode 100644 drivers/media/i2c/ov13858.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e24..26a9a3c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -600,6 +600,14 @@ config VIDEO_OV9650
  This is a V4L2 sensor-level driver for the Omnivision
  OV9650 and OV9652 camera sensors.
 
+config VIDEO_OV13858
+   tristate "OmniVision OV13858 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV13858 camera.
+
 config VIDEO_VS6624
tristate "ST VS6624 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..3f4dc02 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
+obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
new file mode 100644
index 000..03652c6
--- /dev/null
+++ b/drivers/media/i2c/ov13858.c
@@ -0,0 +1,1811 @@
+/*
+ * Copyright (c) 2017 Intel Corporation.
+ *
+ * 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 
+
+#define OV13858_REG_VALUE_08BIT1
+#define OV13858_REG_VALUE_16BIT2
+#define OV13858_REG_VALUE_24BIT3
+
+#define OV13858_REG_MODE_SELECT0x0100
+#define OV13858_MODE_STANDBY   0x00
+#define OV13858_MODE_STREAMING 0x01
+
+#define OV13858_REG_SOFTWARE_RST   0x0103
+#define OV13858_SOFTWARE_RST   0x01
+
+/* PLL1 generates PCLK and MIPI_PHY_CLK */
+#define OV13858_REG_PLL1_CTRL_00x0300
+#define OV13858_REG_PLL1_CTRL_10x0301
+#define OV13858_REG_PLL1_CTRL_20x0302
+#define OV13858_REG_PLL1_CTRL_30x0303
+#define OV13858_REG_PLL1_CTRL_40x0304
+#define OV13858_REG_PLL1_CTRL_50x0305
+
+/* PLL2 generates DAC_CLK, SCLK and SRAM_CLK */
+#define OV13858_REG_PLL2_CTRL_B0x030b
+#define OV13858_REG_PLL2_CTRL_C0x030c
+#define OV13858_REG_PLL2_CTRL_D0x030d
+#define OV13858_REG_PLL2_CTRL_E0x030e
+#define OV13858_REG_PLL2_CTRL_F0x030f
+#define OV13858_REG_PLL2_CTRL_12   0x0312
+#define OV13858_REG_MIPI_SC_CTRL0  0x3016
+#define OV13858_REG_MIPI_SC_CTRL1  0x3022
+
+/* Chip ID */
+#define OV13858_REG_CHIP_ID0x300a
+#define OV13858_CHIP_ID0x00d855
+
+/* V_TIMING internal */
+#define OV13858_REG_VTS0x380e
+#define OV13858_VTS_30FPS  0x0c8e /* 30 fps */
+#define OV13858_VTS_60FPS  0x0648 /* 60 fps */
+#define OV13858_VTS_MAX0x7fff
+#define OV13858_VBLANK_MIN 56
+
+/* HBLANK control - read only */
+#define OV13858_PPL_540MHZ 2244
+#define OV13858_PPL_1080MHZ4488
+
+/* Exposure control */
+#define OV13858_REG_EXPOSURE   0x3500
+#define OV13858_EXPOSURE_MIN   4
+#define OV13858_EXPOSURE_MAX   (OV13858_VTS_MAX - 8)
+#define OV13858_EXPOSURE_STEP  1
+#define OV13858_EXPOSURE_DEFAULT   0x640
+
+/* Analog gain control */
+#define OV13858_REG_ANALOG_GAIN0x3508
+#define OV13858_ANA_GAIN_MIN   0
+#define OV13858_ANA_GAIN_MAX   0x1fff
+#define OV13858_ANA_GAIN_STEP  1
+#define 

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

[Tuukka Toivonen]

Hi Tomasz,

Couple of small comments below.

On Wednesday, June 07, 2017 17:35:13 Tomasz Figa wrote:
> >> +static void ipu3_mmu_domain_free(struct iommu_domain *dom)
> >> +{
> >> +   struct ipu3_mmu_domain *mmu_dom =
> >> +   container_of(dom, struct ipu3_mmu_domain, domain);
> >> +   uint32_t l1_idx;
> >> +
> >> +   for (l1_idx = 0; l1_idx < IPU3_MMU_L1PT_PTES; l1_idx++)
> >> +   if (mmu_dom->pgtbl[l1_idx] != mmu_dom-
>dummy_l2_tbl)
> >> +   free_page((unsigned long)
> >> + TBL_VIRT_ADDR(mmu_dom-
>pgtbl[l1_idx]));
> >> +
> >> +   free_page((unsigned long)TBL_VIRT_ADDR(mmu_dom-
>dummy_page));
> >> +   free_page((unsigned long)TBL_VIRT_ADDR(mmu_dom-
>dummy_l2_tbl));
> 
> I might be overly paranoid, but reading back kernel virtual pointers
> from device accessible memory doesn't seem safe to me. Other drivers
> keep kernel pointers of page tables in a dedicated array (it's only 8K
> of memory, but much better safety).

They are accessible only to the IPU3 IOMMU, which can access whole 
system memory anyway and always does a read-only access to the MMU 
tables. So, I wouldn't worry too much, although extra copy for safety 
wouldn't necessarily harm too much.

<...>

> >> +   ipu3_mmu_tlb_invalidate(mmu_dom->mmu->base);
> >> +
> >> +   return unmapped << IPU3_MMU_PAGE_SHIFT;
> >> +}
> >> +
> >> +static phys_addr_t ipu3_mmu_iova_to_phys(struct iommu_domain 
*domain,
> >> +dma_addr_t iova)
> >> +{
> >> +   struct ipu3_mmu_domain *d =
> >> +   container_of(domain, struct ipu3_mmu_domain, 
domain);
> >> +   uint32_t *l2_pt = TBL_VIRT_ADDR(d->pgtbl[iova >> 
IPU3_MMU_L1PT_SHIFT]);
> >> +
> >> +   return (phys_addr_t)l2_pt[(iova & IPU3_MMU_L2PT_MASK)
> >> +   >> IPU3_MMU_L2PT_SHIFT] << 
IPU3_MMU_PAGE_SHIFT;
> 
> Could we avoid this TBL_VIRT_ADDR() here too? The memory cost to store
> the page table CPU pointers is really small, but safety seems much
> better. Moreover, it should make it possible to use the VT-d IOMMU to
> further secure the system.

IPU3 doesn't support VT-d and can't be enabled while VT-d is on.

Regards,
- Tuukka

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:   Fri Jun  9 05:00:26 CEST 2017
media-tree git hash:47f910f0e0deb880c2114811f7ea1ec115a19ee4
media_build git hash:   3b7b6c01713786a66f82ba2c3a5ea4e077d71c6f
v4l-utils git hash: ef074cf5500b7dd62e6eb3527ec47a914c7189ca
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-arm-stm32: 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: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
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: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
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: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH v2 2/4] [media] davinci: vpif_capture: get subdevs from DT when available

[Lad, Prabhakar]

Hi Kevin,

Thanks for the patch.

On Fri, Jun 9, 2017 at 2:01 AM, Kevin Hilman  wrote:
> On Wed, Jun 7, 2017 at 11:29 PM, Hans Verkuil  wrote:
>> On 07/06/17 01:37, Kevin Hilman wrote:
>>> Enable  getting of subdevs from DT ports and endpoints.
>>>
>>> The _get_pdata() function was larely inspired by (i.e. stolen from)
>>> am437x-vpfe.c
>>>
>>> Signed-off-by: Kevin Hilman 
>>> ---
>>>  drivers/media/platform/davinci/vpif_capture.c | 126 
>>> +-
>>>  drivers/media/platform/davinci/vpif_display.c |   5 +

Can you make this as a separate patch.

>>>  include/media/davinci/vpif_types.h|   9 +-
>>>  3 files changed, 134 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/davinci/vpif_capture.c 
>>> b/drivers/media/platform/davinci/vpif_capture.c
>>> index fc5c7622660c..b9d927d1e5a8 100644
>>> --- a/drivers/media/platform/davinci/vpif_capture.c
>>> +++ b/drivers/media/platform/davinci/vpif_capture.c
>>> @@ -22,6 +22,8 @@
>>>  #include 
>>>
>>>  #include 
>>> +#include 
>>
>> v4l2-of.h no longer exists, so this v2 is wrong. Unfortunately this patch has
>> already been merged in our master. I'm not sure how this could have slipped 
>> past
>> both my and Mauro's patch testing (and yours, for that matter).
>
> I have that file in the various trees I tested agains.
>
>> Can you fix this and post a patch on top of the media master that makes this
>> compile again?
>
> Sorry for the dumb question, but what tree are you referring to?  I
> tried the master branch of both [1] and [2] and both seem to have that
> include.
>
> Kevin
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git
> [2] git://linuxtv.org/mchehab/media-next.git

media master is https://git.linuxtv.org/media_tree.git/

Cheers,
--Prabhakar Lad

Re: [RFC 00/10] V4L2 explicit synchronization support

[Gustavo Padovan]

2017-06-08 Shuah Khan :

> Hi Gustavo,
> 
> On Thu, Jun 8, 2017 at 2:17 PM, Mauro Carvalho Chehab
>  wrote:
> > Hi Gustavo,
> >
> > Em Wed, 24 May 2017 21:31:01 -0300
> > Gustavo Padovan  escreveu:
> >
> >> Hi all,
> >>
> >> I've been working on the v2 of this series, but I think I hit a blocker
> >> when trying to cover the case where the driver asks to requeue the
> >> buffer. It is related to the out-fence side.
> >>
> >> In the current implementation we return on QBUF an out-fence fd that is not
> >> tied to any buffer, because we don't know the queueing order until the
> >> buffer is queued to the driver. Then when the buffer is queued we use
> >> the BUF_QUEUED event to notify userspace of the index of the buffer,
> >> so now userspace knows the buffer associated to the out-fence fd
> >> received earlier.
> >>
> >> Userspace goes ahead and send a DRM Atomic Request to the kernel to
> >> display that buffer on the screen once the fence signals. If it is
> >> a nonblocking request the fence waiting is past the check phase, thus
> >> it isn't allowed to fail anymore.
> >>
> >> But now, what happens if the V4L2 driver calls buffer_done() asking
> >> to requeue the buffer. That means the operation failed and can't
> >> signal the fence, starving the DRM side.
> >>
> >> We need to fix that. The only way I can see is to guarantee ordering of
> >> buffers when out-fences are used. Ordering is something that HAL3 needs
> >> to so maybe there is more than one reason to do it like this. I'm not
> >> a V4L2 expert, so I don't know all the consequences of such a change.
> >>
> >> Any other ideas?
> >>
> >> The current patchset is at:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences
> 
> Do you plan to send the v2 out? I did a quick review and have a few comments.
> 
> [media] vb2: split out queueing from vb_core_qbuf()
> 
> It changes the sequence a bit.
> 
> /* Fill buffer information for the userspace */
>   if (pb)
>   call_void_bufop(q, fill_user_buffer, vb, pb);
> 
> With the changes - user information is filled before __enqueue_in_driver(vb);

Without my changes it also fills it before __enqueue_in_driver() when
start_streaming wasn't called yet. So I don't think it really matters.

> 
> Anyway, it might be a good idea to send the v2 out for review and we can 
> review
> patches in detail. I am hoping to test your patch series on odroid-xu4
> next week.
> Could you please add me to the thread as well as include me when you send
> v2 and subsequent versions.

I will send a v2 as soon as I can, but from Thursday next week until
the 25th I'll be on vacation.

Gustavo

Re: [PATCH 03/12] intel-ipu3: Add DMA API implementation

[Tomasz Figa]

On Fri, Jun 9, 2017 at 3:07 AM, Robin Murphy  wrote:
> On 08/06/17 15:35, Tomasz Figa wrote:
>> On Thu, Jun 8, 2017 at 10:22 PM, Robin Murphy  wrote:
>>> On 07/06/17 10:47, Tomasz Figa wrote:
 Hi Yong,

 +Robin, Joerg, IOMMU ML

 Please see my comments inline.

 On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi  wrote:
>> [snip]
> +
> +/* End of things adapted from arch/arm/mm/dma-mapping.c */
> +static void ipu3_dmamap_sync_single_for_cpu(struct device *dev,
> +   dma_addr_t dma_handle, size_t 
> size,
> +   enum dma_data_direction dir)
> +{
> +   struct ipu3_mmu *mmu = to_ipu3_mmu(dev);
> +   dma_addr_t daddr = iommu_iova_to_phys(mmu->domain, dma_handle);
> +
> +   clflush_cache_range(phys_to_virt(daddr), size);

 You might need to consider another IOMMU on the way here. Generally,
 given that daddr is your MMU DMA address (not necessarily CPU physical
 address), you should be able to call

 dma_sync_single_for_cpu(, daddr, size, dir)
>>>
>>> I'd hope that this IPU complex is some kind of embedded endpoint thing
>>> that bypasses the VT-d IOMMU or is always using its own local RAM,
>>> because it would be pretty much unworkable otherwise.
>>
>> It uses system RAM and, as far as my understanding goes, by default it
>> operates without the VT-d IOMMU and that's how it's used right now.
>
> OK, if it *is* behind a DMAR unit then booting with "iommu=force" (or
> whatever the exact incantation for intel-iommu is) should be fun...
>
>> I'm suggesting VT-d IOMMU as a way to further strengthen the security
>> and error resilience in future (due to the IPU complex being
>> non-coherent and also running a closed source firmware).
>
> TBH, doing DMA remapping through *two* IOMMUS will add horrible hardware
> overhead,

Not necessarily, if done right and with right hardware (I lack the
details about Intel hardware unfortunately). One can for example
notice the fact that the IOVA ranges from the parent IOMMU are going
to be contiguous for the child IOMMU, so one could use huge pages in
the child IOMMU and essentially make a selective 1:1 mapping.

> increase the scope for kernel-side bugs, and not much more. If
> we don't trust this IOMMU to behave, why are we trying to drive it in
> the first place? If we do, then a second IOMMU behind it won't protect
> anything that the first one doesn't already.

That's a valid point, right. But on the other hand, I lack the
hardware details on whether we can just disable the internal IOMMU and
use DMAR alone instead.

>
>>> The whole
>>> infrastructure isn't really capable of dealing with nested IOMMUs, and
>>> nested DMA ops would be an equally horrible idea.
>>
>> Could you elaborate a bit more on this? I think we should be able to
>> deal with this in a way I suggested before:
>>
>> a) the PCI device would use the system DMA ops,
>> b) the PCI device would implement a secondary bus for which it would
>> provide its own DMA and IOMMU ops.
>> c) a secondary device would be registered on the secondary bus,
>> d) all memory for the IPU would be managed on behalf of the secondary device.
>>
>> In fact, the driver already is designed in a way that all the points
>> above are true. If I'm not missing something, the only significant
>> missing point is calling into system DMA ops from IPU DMA ops.
>
> I don't believe x86 has any non-coherent DMA ops, therefore the IPU DMA
> ops would still probably have to do all their own cache maintenance.

I'd argue that it means that we need to add non-coherent DMA ops on
x86, as we have on other archs, which can have both coherent and
non-coherent devices in the same system.

> Allocation/mapping, though, would have to be done with the parent DMA
> ops first (in case DMA address != physical address), *then* mapped at
> the IPU MMU, which is the real killer - if the PCI DMA ops are from
> intel-iommu, then there's little need for the IPU MMU mapping to be
> anything other than 1:1, so you may as well not bother.

Okay, I think I can agree with you on this. It indeed makes little
sense to use both MMUs at the same time, if there is a way to disable
one of them.

Let's just keep this unaware of DMAR at this point of time, as a
starter, and get back to it later whenever someone wants to use DMAR
instead. I guess the way to proceed then would be either disabling the
internal MMU, if possible, or making it use a 1:1 (huge page, if
possible) mapping, if not.

> If the PCI DMA
> ops are from SWIOTLB, then the constraints of having to go through that
> first eliminate all the scatter-gather benefit of the IPU MMU.

Does the SWIOTLB give you a physically contiguous memory? If not, you
still need the IPU MMU to actually be able to access the memory.

>
> The IOMMU API ops would have to be handled similarly, by 

Re: [RFC 00/10] V4L2 explicit synchronization support

[Gustavo Padovan]

Hi Mauro,

2017-06-08 Mauro Carvalho Chehab :

> Hi Gustavo,
> 
> Em Wed, 24 May 2017 21:31:01 -0300
> Gustavo Padovan  escreveu:
> 
> > Hi all,
> > 
> > I've been working on the v2 of this series, but I think I hit a blocker
> > when trying to cover the case where the driver asks to requeue the
> > buffer. It is related to the out-fence side.
> > 
> > In the current implementation we return on QBUF an out-fence fd that is not
> > tied to any buffer, because we don't know the queueing order until the
> > buffer is queued to the driver. Then when the buffer is queued we use
> > the BUF_QUEUED event to notify userspace of the index of the buffer,
> > so now userspace knows the buffer associated to the out-fence fd
> > received earlier.
> > 
> > Userspace goes ahead and send a DRM Atomic Request to the kernel to
> > display that buffer on the screen once the fence signals. If it is 
> > a nonblocking request the fence waiting is past the check phase, thus
> > it isn't allowed to fail anymore.
> > 
> > But now, what happens if the V4L2 driver calls buffer_done() asking
> > to requeue the buffer. That means the operation failed and can't
> > signal the fence, starving the DRM side.
> > 
> > We need to fix that. The only way I can see is to guarantee ordering of
> > buffers when out-fences are used. Ordering is something that HAL3 needs
> > to so maybe there is more than one reason to do it like this. I'm not
> > a V4L2 expert, so I don't know all the consequences of such a change.
> > 
> > Any other ideas?
> > 
> > The current patchset is at:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences
> 
> Currently, nothing warrants that buffers will be returned in order,
> but that should be the case of most drivers. I guess the main
> exception would be mem2mem codec drivers. On those, the driver
> or the hardware may opt to reorder the buffers.
> 
> If this is a mandatory requirement for explicit fences to work, then
> we'll need to be able to explicitly enable it, per driver, and
> clearly document that drivers using it *should* warrant that the
> dequeued buffer will follow the queued order.

It is mandatory in the sense it won't work properly and make DRM fail an
atomic commit if a buffer is requeued. So it is fair to ask drivers to
guarantee ordering is a good thing. Then later we can deal with the
drivers that can't. 

> 
> We may need to modify VB2 in order to enforce it or return an
> error if the order doesn't match.

Yeah, I'll look into how to do this.

Gustavo