[PATCH 0/5] media: rc: meson-ir: series with smaller improvements

[Heiner Kallweit]

This series includes smaller improvements for the meson-ir driver.
Tested on a Odroid C2.

Heiner Kallweit (5):
  media: rc: meson-ir: remove irq from struct meson_ir
  media: rc: meson-ir: make use of the bitfield macros
  media: rc: meson-ir: switch to managed rc device allocation / registration
  media: rc: meson-ir: use readl_relaxed in the interrupt handler
  media: rc: meson-ir: change irq name to to of node name

 drivers/media/rc/meson-ir.c | 64 ++---
 1 file changed, 26 insertions(+), 38 deletions(-)

-- 
2.12.2

Re: [PATCHv3 08/22] staging: android: ion: Remove crufty cache support

[Archit Taneja]

Hi,

On 04/04/2017 12:27 AM, Laura Abbott wrote:

Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.


We could get rid of the ION_FLAG_CACHED_NEEDS_SYNC flag in this patch
too.

Thanks,
Archit



Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/compat_ion.c|  1 -
 drivers/staging/android/ion/ion-ioctl.c |  6 
 drivers/staging/android/ion/ion.c   | 40 -
 drivers/staging/android/ion/ion_carveout_heap.c |  6 
 drivers/staging/android/ion/ion_chunk_heap.c|  6 
 drivers/staging/android/ion/ion_page_pool.c |  3 --
 drivers/staging/android/ion/ion_priv.h  | 13 
 drivers/staging/android/ion/ion_system_heap.c   |  5 
 drivers/staging/android/uapi/ion.h  | 10 ---
 9 files changed, 90 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 9a978d2..b892d3a 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -186,7 +186,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
-   case ION_IOC_SYNC:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 5b2e93f..e096bcd 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -51,7 +51,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_SYNC:
case ION_IOC_FREE:
case ION_IOC_CUSTOM:
return _IOC_WRITE;
@@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_SYNC:
-   {
-   ret = ion_sync_for_device(client, data.fd.fd);
-   break;
-   }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 226ea1f..8757164 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -863,22 +863,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
 }

-void ion_pages_sync_for_device(struct device *dev, struct page *page,
-  size_t size, enum dma_data_direction dir)
-{
-   struct scatterlist sg;
-
-   sg_init_table(, 1);
-   sg_set_page(, page, size, 0);
-   /*
-* This is not correct - sg_dma_address needs a dma_addr_t that is valid
-* for the targeted device, but this works on the currently targeted
-* hardware.
-*/
-   sg_dma_address() = page_to_phys(page);
-   dma_sync_sg_for_device(dev, , 1, dir);
-}
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -1097,30 +1081,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct 
ion_client *client, int fd)
 }
 EXPORT_SYMBOL(ion_import_dma_buf_fd);

-int ion_sync_for_device(struct ion_client *client, int fd)
-{
-   struct dma_buf *dmabuf;
-   struct ion_buffer *buffer;
-
-   dmabuf = dma_buf_get(fd);
-   if (IS_ERR(dmabuf))
-   return PTR_ERR(dmabuf);
-
-   /* if this memory came from ion */
-   if (dmabuf->ops != _buf_ops) {
-   pr_err("%s: can not sync dmabuf from another exporter\n",
-  __func__);
-   dma_buf_put(dmabuf);
-   return -EINVAL;
-   }
-   buffer = dmabuf->priv;
-
-   dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
-  buffer->sg_table->nents, DMA_BIDIRECTIONAL);
-   dma_buf_put(dmabuf);
-   return 0;
-}
-
 int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
 {
struct ion_device *dev = client->dev;
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index 9bf8e98..e0e360f 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer 
*buffer)

ion_heap_buffer_zero(buffer);

-   if (ion_buffer_cached(buffer))
-   dma_sync_sg_for_device(NULL, 

Re: [PATCH] Quirk for webcam in MacBook Pro 2016

[Laurent Pinchart]

Hi Daniel,

On Monday 10 Apr 2017 20:01:18 Daniel Roschka wrote:
> Hi Laurent,
> 
> I'm really sorry for all the wrong formatting. I already took measures so it
> won't happen again.

Don't worry, I've seen worse :-)

> > Your patch is now in my git tree, and I will push it upstream for v4.13
> > (v4.11 will be released very soon, and given the pending pull requests for
> > v4.12 in the Linux media tree I don't think I can add another one).
> 
> Thanks a lot. Highly appreciated.
> 
> > I collect USB descriptors for UVC devices. Could you please send me the
> > output of
> > 
> > lsusb -d 05ac:8600
> 
> I guess you want the verbose output of lsusb. You'll find it in the attached
> file. It might contain more than than you expect as the iBridge device is a
> custom ARM processor (probably very similar to the one in the Apple Watch),
> not just connecting the webcam to the rest of the system, but also the
> Touch Bar and the Touch ID sensor.

Thank you very much for the information.

-- 
Regards,

Laurent Pinchart

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:   Tue Apr 11 05:00:21 CEST 2017
media-tree git hash:4aed35ca73f6d9cfd5f7089ba5d04f5fb8623080
media_build git hash:   d49f7b2d9934c96a3d2c04021e4da1e12ec97995
v4l-utils git hash: 8356ccd427061e09e49d24bdcf74fa9c9b43080c
gcc version:i686-linux-gcc (GCC) 6.2.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: ERRORS
linux-git-arm-davinci: OK
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.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: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: WARNINGS
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: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-i686: ERRORS
linux-4.10.1-i686: ERRORS
linux-4.11-rc1-i686: ERRORS
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: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: WARNINGS
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: WARNINGS
linux-3.18.7-x86_64: WARNINGS
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: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-x86_64: ERRORS
linux-4.10.1-x86_64: ERRORS
linux-4.11-rc1-x86_64: ERRORS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[linux-stable-rc:linux-4.9.y 1742/1772] arch/arm/mach-omap2/pdata-quirks.c:537:49: error: 'rx51_ir_data' undeclared here (not in a function)

[kbuild test robot]

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
head:   7ee2dbbb610d590fcc19cd507e70fc17c0eb542c
commit: f2ea7a5c37300861913e0884fc846ade633b06f0 [1742/1772] rx51: broken build
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f2ea7a5c37300861913e0884fc846ade633b06f0
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from arch/arm/mach-omap2/pdata-quirks.c:15:0:
>> arch/arm/mach-omap2/pdata-quirks.c:537:49: error: 'rx51_ir_data' undeclared 
>> here (not in a function)
 OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),
^
   include/linux/of_platform.h:52:21: note: in definition of macro 
'OF_DEV_AUXDATA'
   .platform_data = _pdata }
^~

vim +/rx51_ir_data +537 arch/arm/mach-omap2/pdata-quirks.c

   531  #endif
   532  #ifdef CONFIG_ARCH_OMAP3
   533  OF_DEV_AUXDATA("ti,omap2-iommu", 0x5d00, "5d00.mmu",
   534 _iommu_pdata),
   535  OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x4809c000, "4809c000.mmc", 
_pdata[0]),
   536  OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x480b4000, "480b4000.mmc", 
_pdata[1]),
 > 537  OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", _ir_data),
   538  /* Only on am3517 */
   539  OF_DEV_AUXDATA("ti,davinci_mdio", 0x5c03, "davinci_mdio.0", 
NULL),
   540  OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[media] vimc: API proposal, configuring the topology from user space

[Helen Koike]

Hi,

Continuing the discussion about the API of the vimc driver, I made some 
changes
based on the previous comments, please see below and let me know your 
opinion about it.


Helen

/***
Configfs considerations:
/
Informal definitions:
subsystem: the root driver folder in user space (/configfs/vimc)
item: aka a folder in user space
attributes: aka files in the folder
group: aka a folder that can contain subfolders (parent and child 
relation)
	default group: aka a subfolder that is created automatically when the 
"parent" folder is created

it is not considered a child in terms of rmdir

* Performing rmdir in a group will fail if it contain children that are 
not default groups, i.e, if the
folder contain subfolders that are default group, then it can be removed 
with rmdir, if the

subfolders were created with mkdir, then rmdir in the parent will fail.

* Configfs has the notion of committable item but it is not implemented 
yet. A committable item is an item
that can be in one of two parent folders called: live and pending. The 
idea is to create and modify the item
in the pending directory and then to move the item through a rename to 
the live directory where
it can't be modified. This seems to be a nice feature for vimc, but as 
it is not available yet the

proposal below won't be based on this.

* Groups can be dynamically created/destroyed by the driver whenever it 
wants. Afaik attributes can only
be created when the group or item is created and symlinks can only be 
create from user space, i.e, the

driver don't know how to create/destroy attributes or symlinks in anytime.

/***
The API:
/

In short, a topology like this one: http://goo.gl/Y7eUfu
Would look like this filesystem tree: https://goo.gl/mEOmOf

v3 core changes:
- I removed the use of symlinks as I wans't able to see how to do it nicely.
- I use the names of the folders created by user space to retrieve 
information at mkdir time

- hotplug file in each entity
- hotplug file in each device
- reset file in each device

* The /configfs/vimc subsystem
empty when the driver is loaded

* Create a device
Userspace can create a new vimc device with:

$ mkdir /configfs/vimc/any_name
Example:
$ mkdir /configfs/vimc/vimc0
$ ls -l /configfs/vimc/vimc0
hotplug
reset
entities/
links/

entities/ and links/ folder are default groups, thus they don't prevent 
rmdir vimc0/, but

rmdir will fail if it has any child inside entities/ or links/.
hotplug is used to plug and unplug the device, it can read "plugged" or 
"unplugged" and user can

write "plug" or "unplug" to change its state.
Changing hotplug state will never fail as the configfs tree will always 
be in a valid state.
reset is used to easily destroy all the topology without the need to 
walk through all the children
to perform rmdir, writing 1 to reset file will set hotplug to 
"unplugged" and erase all folders

under entities/ and links/.

* Create an entity
Userspace can create a new entity with:

$ mkdir /configfs/vimc/vimc0/entities/:
Example:
$ mkdir /configfs/vimc/vimc0/entities/sensor:SensorA
$ ls -l /configfs/vimc/vimc0/entities/sensor:SensorA
hotplug
pad:source:0/

The name of the folder needs to be in the format : or it 
will be rejected, this allows the
creation of the right pads according to its role at mkdir time, 
eliminating the previously proposed role

and name files.
hotplug is used to plug and unplug the hw block, it can read "plugged" 
or "unplugged" and user can
write "plug" or "unplug" to change its state. As we don't support this 
yet in the media core, changing it

will only be allowed if /configfs/vimc/vimc0/hotplug is "unplugged".
hotplug file is "unplugged" by default.
Pads will be created as default groups with the name in the format 
pad:: and it

will be an empty folder.
If the hw block supports different number of pads, we could expose two 
files:

sinks
sources
where the user space can write the desired number of sink and source 
pads and the driver will dynamically

create the folders pad::

* Create a link
User space can create a link between two entities with:

	$ mkdir 
/configfs/vimc/vimc0/links/:->:

Example:
$ mkdir /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0
$ ls -l /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0
flags

mkdir will be rejected if folder is not on the format 
:->:.
mkdir will be rejected if either  or  
are not found in /configfs/vimc/vimc0/entities/

The link will only be created if both entities are in "plugged" state.
When an entity is removed from /configfs/vimc/vimc0/entities/ with 
rmdir, its corresponding link folders at

/configfs/vimc/vimc0/links will be automatically removed.
If one of the entities changes from "plugged" to "unplugged", the link 

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Shuah Khan]

On 04/06/2017 06:01 AM, Marek Szyprowski wrote:
> Hi Shuah,
> 
> On 2017-04-05 18:02, Shuah Khan wrote:
>> When coherent DMA memory without struct page is shared, importer
>> fails to find the page and runs into kernel page fault when it
>> tries to dmabuf_ops_attach/map_sg/map_page the invalid page found
>> in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html
>> for more information on this problem.
>>
>> This solution allows coherent DMA memory without struct page to be
>> shared by providing a way for the exporter to tag the DMA buffer as
>> a special buffer without struct page association and passing the
>> information in sg_table to the importer. This information is used
>> in attach/map_sg to avoid cleaning D-cache and mapping.
>>
>> The details of the change are:
>>
>> Framework:
>> - Add a new dma_attrs field to struct scatterlist.
>> - Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify
>>Coherent memory without struct page.
>> - Add a new dma_check_dev_coherent() interface to check if memory is
>>the device coherent area. There is no way to tell where the memory
>>returned by dma_alloc_attrs() came from.
>>
>> Exporter logic:
>> - Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set
>>DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is
>>done in the exporter context.
>> - Add logic to arm_dma_get_sgtable() to identify memory without struct
>>page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is
>>set, arm_dma_get_sgtable() will set page as the cpu_addr and update
>>dma_address and dma_attrs fields in struct scatterlist for this sgl.
>>This is done in exporter context when buffer is exported. With this
>>Note: This change is made on top of Russell King's patch that added
>>!pfn_valid(pfn) check to arm_dma_get_sgtable() to error out on invalid
>>pages. Coherent memory without struct page will trigger this error.
>>
>> Importer logic:
>> - Add logic to vb2_dc_dmabuf_ops_attach() to identify memory without
>>struct page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute when it copies
>>the sg_table from the exporter. It will copy dma_attrs and dma_address
>>fields. With this logic, dmabuf_ops_attach will no longer trip on an
>>invalid page.
>> - Add logic to arm_dma_map_sg() to avoid mapping the page when sg_table
>>has DMA_ATTR_DEV_COHERENT_NOPAGE buffer.
>> - Add logic to arm_dma_unmap_sg() to do nothing for sg entries with
>>DMA_ATTR_DEV_COHERENT_NOPAGE attribute.
>>
>> Without this change the following use-case that runs into kernel
>> pagefault when importer tries to attach the exported buffer.
>>
>> With this change it works: (what a relief after watching pagefaults for
>> weeks!!)
>>
>> gst-launch-1.0 filesrc location=~/GH3_MOV_HD.mp4 ! qtdemux ! h264parse ! 
>> v4l2video4dec capture-io-mode=dmabuf ! v4l2video7convert 
>> output-io-mode=dmabuf-import ! kmssink force-modesetting=true
>>
>> I am sending RFC patch to get feedback on the approach and see if I missed
>> anything.
> 
> Frankly, once You decided to hack around dma-buf and issues with coherent,
> carved out memory, it might be a bit better to find the ultimate solution
> instead of the another hack. Please note that it will still not allow to
> share a buffer allocated from carved-out memory and a device, which is
> behind IOMMU.

With your patch s5p-mfc patch series does address the problem for this
use-case for 4.12 onwards. However I am still concerned about prior
release and this pagefault is bad.

Invalid page test partially solves the problem. Would it helpful to
at least prevent the pagfault with a definitive test. Please see my
response to Russell. Let me know your thoughts on that.

> 
> I thought a bit about this and the current shape of dma-buf code.
> 
> IMHO the proper way of solving all those issues would be to replace
> dma-buf internal representation of the memory from struct scatter_list
> to pfn array. This would really solve the problem of buffers which
> cannot be properly represented by scatter lists/struct pages and would
> even allow sharing buffers between all kinds of devices. Scatter-lists
> are also quite over-engineered structures to represent a single buffer
> (pfn array is a bit more compact representation). Also there is a lots
> of buggy code which use scatter-list in a bit creative way (like
> assuming that each page maps to a single scatter list entry for
> example). The only missing piece, required for such change would be
> extending DMA-mapping with dma_map_pfn() interface.

I agree with you on scatterlists being clumsy. Changing over to pfn array
could simplify things. I am exploring a slightly different option that
might not require too many changes. I will respond with concrete ideas
later on this week.

> 
> This would be however quite large task, especially taking into account
> all current users of DMA-buf framework...

Yeah it will be a large 

Looking for device driver advice

[Patrick Doyle]

I am looking for advice regarding the construction of a device driver
for a MIPI CSI2 imager (a Sony IMX241) that is connected to a
MIPI<->Parallel converter (Toshiba TC358748) wired into a parallel
interface on a Soc (a Microchip/Atmel SAMAD2x device.)

The Sony imager is controlled and configured via I2C, as is the
Toshiba converter.  I could write a single driver that configures both
devices and treats them as a single device that just happens to use 2
i2c addresses.  I could use the i2c_new_dummy() API to construct the
device abstraction for the second physical device at probe time for
the first physical device.

Or I could do something smarter (or at least different), specifying
the two devices independently via my device tree file, perhaps linking
them together via "port" nodes.  Currently, I use the "port" node
concept to link an i2c imager to the Image System Controller (isc)
node in the SAMA5 device.  Perhaps that generalizes to a chain of
nodes linked together... I don't know.

I'm also not sure how these two devices might play into V4L2's
"subdev" concept.  Are they separate, independent sub devices of the
ISC, or are they a single sub device.

Any thoughts, intuition, pointers to existing code that addresses
questions such as these, would be welcome.

Thanks.

--wpd

Re: [PATCH 0/3] support for Logilink VG0022a DVB-T2 stick

[Andreas Kemnade]

ping

On Wed, 15 Mar 2017 23:22:07 +0100
Andreas Kemnade  wrote:

> Hi all,
> here are some patches needed for supporting the
> Logilink VG0022A DVB-T2 stick.
> As the combination of chips in that stick is not
> uncommon, the first two patches might also fix problems
> for similar hardware.
> 
> Andreas Kemnade (3):
>   [media] si2157: get chip id during probing
>   [media] af9035: init i2c already in it930x_frontend_attach
>   [media] af9035: add Logilink vg0022a to device id table
> 
>  drivers/media/tuners/si2157.c | 54 
> +--
>  drivers/media/tuners/si2157_priv.h|  7 +
>  drivers/media/usb/dvb-usb-v2/af9035.c | 45 -
>  3 files changed, 83 insertions(+), 23 deletions(-)
> 



pgpWXfZ3ZwVSm.pgp
Description: OpenPGP digital signature

[PATCHv4 11/15] vidioc-queryctrl.rst: document V4L2_CTRL_FLAG_MODIFY_LAYOUT

[Hans Verkuil]

From: Hans Verkuil 

Document this new control flag.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 13 +
 Documentation/media/videodev2.h.rst.exceptions|  1 +
 2 files changed, 14 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst 
b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
index 82769de801b1..1ffdc3f3c614 100644
--- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
+++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
@@ -507,6 +507,19 @@ See also the examples in :ref:`control`.
represents an action on the hardware. For example: clearing an
error flag or triggering the flash. All the controls of the type
``V4L2_CTRL_TYPE_BUTTON`` have this flag set.
+* .. _FLAG_MODIFY_LAYOUT:
+
+  - ``V4L2_CTRL_FLAG_MODIFY_LAYOUT``
+  - 0x0400
+  - Changing this control value may modify the layout of the
+buffer (for video devices) or the media bus format (for sub-devices).
+
+   A typical example would be the ``V4L2_CID_ROTATE`` control.
+
+   Note that typically controls with this flag will also set the
+   ``V4L2_CTRL_FLAG_GRABBED`` flag when buffers are allocated or
+   streaming is in progress since most drivers do not support changing
+   the format in that case.
 
 
 Return Value
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index c9c611b18ba1..a5cb0a8686ac 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -341,6 +341,7 @@ replace define V4L2_CTRL_FLAG_WRITE_ONLY control-flags
 replace define V4L2_CTRL_FLAG_VOLATILE control-flags
 replace define V4L2_CTRL_FLAG_HAS_PAYLOAD control-flags
 replace define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE control-flags
+replace define V4L2_CTRL_FLAG_MODIFY_LAYOUT control-flags
 
 replace define V4L2_CTRL_FLAG_NEXT_CTRL control
 replace define V4L2_CTRL_FLAG_NEXT_COMPOUND control
-- 
2.11.0

[PATCHv4 09/15] v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine

[Hans Verkuil]

From: Niklas Söderlund 

The format is used on the R-Car VSP1 video queues that carry
2-D histogram statistics data.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 Documentation/media/uapi/v4l/meta-formats.rst  |   1 +
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 120 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
 include/uapi/linux/videodev2.h |   3 +-
 4 files changed, 124 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst

diff --git a/Documentation/media/uapi/v4l/meta-formats.rst 
b/Documentation/media/uapi/v4l/meta-formats.rst
index 05ab91e12f10..01e24e3df571 100644
--- a/Documentation/media/uapi/v4l/meta-formats.rst
+++ b/Documentation/media/uapi/v4l/meta-formats.rst
@@ -13,3 +13,4 @@ These formats are used for the :ref:`metadata` interface only.
 :maxdepth: 1
 
 pixfmt-meta-vsp1-hgo
+pixfmt-meta-vsp1-hgt
diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst 
b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
new file mode 100644
index ..fb9f79466319
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
@@ -0,0 +1,120 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _v4l2-meta-fmt-vsp1-hgt:
+
+***
+V4L2_META_FMT_VSP1_HGT ('VSPT')
+***
+
+Renesas R-Car VSP1 2-D Histogram Data
+
+
+Description
+===
+
+This format describes histogram data generated by the Renesas R-Car VSP1
+2-D Histogram (HGT) engine.
+
+The VSP1 HGT is a histogram computation engine that operates on HSV
+data. It operates on a possibly cropped and subsampled input image and
+computes the sum, maximum and minimum of the S component as well as a
+weighted frequency histogram based on the H and S components.
+
+The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in
+total. Each HSV value is added to one or more buckets with a weight
+between 1 and 16 depending on the Hue areas configuration. Finding the
+corresponding buckets is done by inspecting the H and S value independently.
+
+The Saturation position **n** (0 - 31) of the bucket in the matrix is
+found by the expression:
+
+n = S / 8
+
+The Hue position **m** (0 - 5) of the bucket in the matrix depends on
+how the HGT Hue areas are configured. There are 6 user configurable Hue
+Areas which can be configured to cover overlapping Hue values:
+
+::
+
+ Area 0   Area 1   Area 2   Area 3   Area 4   Area 
5
+     

+   \   /|  |\   /|  |\   /|  |\   /|  |\   /|  |\   /| 
 |\   /
+\ / |  | \ / |  | \ / |  | \ / |  | \ / |  | \ / | 
 | \ /
+ X  |  |  X  |  |  X  |  |  X  |  |  X  |  |  X  | 
 |  X
+/ \ |  | / \ |  | / \ |  | / \ |  | / \ |  | / \ | 
 | / \
+   /   \|  |/   \|  |/   \|  |/   \|  |/   \|  |/   \| 
 |/   \
+  5U   0L  0U   1L  1U   2L  2U   3L  3U   4L  4U   5L 
 5U   0L
+<0..Hue 
Value255>
+
+When two consecutive areas don't overlap (n+1L is equal to nU) the boundary
+value is considered as part of the lower area.
+
+Pixels with a hue value included in the centre of an area (between nL and nU
+included) are attributed to that single area and given a weight of 16. Pixels
+with a hue value included in the overlapping region between two areas (between
+n+1L and nU excluded) are attributed to both areas and given a weight for each
+of these areas proportional to their position along the diagonal lines
+(rounded down).
+
+The Hue area setup must match one of the following constrains:
+
+::
+
+0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U
+
+::
+
+0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L
+
+**Byte Order.**
+All data is stored in memory in little endian format. Each cell in the tables
+contains one byte.
+
+.. flat-table:: VSP1 HGT Data - (776 bytes)
+:header-rows:  2
+:stub-columns: 0
+
+* - Offset
+  - :cspan:`4` Memory
+* -
+  - [31:24]
+  - [23:16]
+  - [15:8]
+  - [7:0]
+* - 0
+  - -
+  - S max [7:0]
+  - -
+  - S min [7:0]
+* - 4
+  - :cspan:`4` S sum [31:0]
+* - 8
+  - :cspan:`4` Histogram bucket (m=0, n=0) [31:0]
+* - 12
+  - :cspan:`4` Histogram bucket (m=0, n=1) [31:0]
+* -
+  - :cspan:`4` ...
+* - 132
+  - :cspan:`4` Histogram bucket (m=0, n=31) [31:0]
+* - 136
+  - :cspan:`4` Histogram bucket (m=1, n=0) [31:0]
+* -

[PATCHv4 10/15] v4l: vsp1: Add HGT support

[Hans Verkuil]

From: Niklas Söderlund 

The HGT is a Histogram Generator Two-Dimensions. It computes a weighted
frequency histograms for hue and saturation areas over a configurable
region of the image with optional subsampling.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/Makefile  |   2 +-
 drivers/media/platform/vsp1/vsp1.h|   3 +
 drivers/media/platform/vsp1/vsp1_drv.c|  32 -
 drivers/media/platform/vsp1/vsp1_entity.c |  14 ++
 drivers/media/platform/vsp1/vsp1_hgt.c| 222 ++
 drivers/media/platform/vsp1/vsp1_hgt.h|  42 ++
 drivers/media/platform/vsp1/vsp1_pipe.c   |  16 +++
 drivers/media/platform/vsp1/vsp1_pipe.h   |   2 +
 drivers/media/platform/vsp1/vsp1_regs.h   |   9 ++
 drivers/media/platform/vsp1/vsp1_video.c  |   6 +
 10 files changed, 343 insertions(+), 5 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h

diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index 8ab6a063569e..a33afc385a48 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -3,7 +3,7 @@ vsp1-y  += vsp1_dl.o vsp1_drm.o 
vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
 vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
-vsp1-y += vsp1_hgo.o vsp1_histo.o
+vsp1-y += vsp1_hgo.o vsp1_hgt.o vsp1_histo.o
 vsp1-y += vsp1_lif.o
 
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1.o
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 0ba7521c01b4..85387a64179a 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -33,6 +33,7 @@ struct vsp1_platform_data;
 struct vsp1_bru;
 struct vsp1_clu;
 struct vsp1_hgo;
+struct vsp1_hgt;
 struct vsp1_hsit;
 struct vsp1_lif;
 struct vsp1_lut;
@@ -52,6 +53,7 @@ struct vsp1_uds;
 #define VSP1_HAS_WPF_VFLIP (1 << 5)
 #define VSP1_HAS_WPF_HFLIP (1 << 6)
 #define VSP1_HAS_HGO   (1 << 7)
+#define VSP1_HAS_HGT   (1 << 8)
 
 struct vsp1_device_info {
u32 version;
@@ -76,6 +78,7 @@ struct vsp1_device {
struct vsp1_bru *bru;
struct vsp1_clu *clu;
struct vsp1_hgo *hgo;
+   struct vsp1_hgt *hgt;
struct vsp1_hsit *hsi;
struct vsp1_hsit *hst;
struct vsp1_lif *lif;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 0acc8ed6ac59..048446af5ae7 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -31,6 +31,7 @@
 #include "vsp1_dl.h"
 #include "vsp1_drm.h"
 #include "vsp1_hgo.h"
+#include "vsp1_hgt.h"
 #include "vsp1_hsit.h"
 #include "vsp1_lif.h"
 #include "vsp1_lut.h"
@@ -161,6 +162,16 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1)
return ret;
}
 
+   if (vsp1->hgt) {
+   ret = 
media_create_pad_link(>hgt->histo.entity.subdev.entity,
+   HISTO_PAD_SOURCE,
+   >hgt->histo.video.entity, 0,
+   MEDIA_LNK_FL_ENABLED |
+   MEDIA_LNK_FL_IMMUTABLE);
+   if (ret < 0)
+   return ret;
+   }
+
if (vsp1->lif) {
ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
RWPF_PAD_SOURCE,
@@ -305,6 +316,17 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
  >entities);
}
 
+   if (vsp1->info->features & VSP1_HAS_HGT && vsp1->info->uapi) {
+   vsp1->hgt = vsp1_hgt_create(vsp1);
+   if (IS_ERR(vsp1->hgt)) {
+   ret = PTR_ERR(vsp1->hgt);
+   goto done;
+   }
+
+   list_add_tail(>hgt->histo.entity.list_dev,
+ >entities);
+   }
+
/*
 * The LIF is only supported when used in conjunction with the DU, in
 * which case the userspace API is disabled. If the userspace API is
@@ -591,7 +613,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.model = "VSP1-S",
.gen = 2,
.features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
- | VSP1_HAS_LUT | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
+  

[PATCHv4 14/15] buffer.rst: clarify how V4L2_CTRL_FLAG_MODIFY_LAYOUT/GRABBER are used

[Hans Verkuil]

From: Hans Verkuil 

Explain when the V4L2_CTRL_FLAG_MODIFY_LAYOUT and
V4L2_CTRL_FLAG_MODIFY_GRABBER flags should be used.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/buffer.rst | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index 64613d935edd..ae6ee73f151c 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -48,10 +48,16 @@ The set of information needed to interpret the content of a 
buffer (e.g. the
 pixel format, the line stride, the tiling orientation or the rotation) is
 collectively referred to in the rest of this section as the buffer layout.
 
+Controls that can modify the buffer layout shall set the
+``V4L2_CTRL_FLAG_MODIFY_LAYOUT`` flag.
+
 Modifying formats or controls that influence the buffer size or layout require
 the stream to be stopped. Any attempt at such a modification while the stream
 is active shall cause the ioctl setting the format or the control to return
-the ``EBUSY`` error code.
+the ``EBUSY`` error code. In that case drivers shall also set the
+``V4L2_CTRL_FLAG_GRABBED`` flag when calling
+:c:func:`VIDIOC_QUERYCTRL` or :c:func:`VIDIOC_QUERY_EXT_CTRL` for such a
+control while the stream is active.
 
 .. note::
 
@@ -67,7 +73,8 @@ the ``EBUSY`` error code.
 Controls that only influence the buffer layout can be modified at any time
 when the stream is stopped. As they don't influence the buffer size, no
 special handling is needed to synchronize those controls with buffer
-allocation.
+allocation and the ``V4L2_CTRL_FLAG_GRABBED`` flag is cleared once the
+stream is stopped.
 
 Formats and controls that influence the buffer size interact with buffer
 allocation. The simplest way to handle this is for drivers to always require
@@ -75,8 +82,10 @@ buffers to be reallocated in order to change those formats 
or controls. In
 that case, to perform such changes, userspace applications shall first stop
 the video stream with the :c:func:`VIDIOC_STREAMOFF` ioctl if it is running
 and free all buffers with the :c:func:`VIDIOC_REQBUFS` ioctl if they are
-allocated. The format or controls can then be modified, and buffers shall then
-be reallocated and the stream restarted. A typical ioctl sequence is
+allocated. After freeing all buffers the ``V4L2_CTRL_FLAG_GRABBED`` flag
+for controls is cleared. The format or controls can then be modified, and
+buffers shall then be reallocated and the stream restarted. A typical ioctl
+sequence is
 
  #. VIDIOC_STREAMOFF
  #. VIDIOC_REQBUFS(0)
-- 
2.11.0

[PATCHv4 15/15] vsp1: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for histogram controls

[Hans Verkuil]

From: Hans Verkuil 

The two histogram controls will modify the layout of the
metadata, so this flag should be set.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vsp1/vsp1_hgo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_hgo.c 
b/drivers/media/platform/vsp1/vsp1_hgo.c
index a138c6b7fb05..50309c053b78 100644
--- a/drivers/media/platform/vsp1/vsp1_hgo.c
+++ b/drivers/media/platform/vsp1/vsp1_hgo.c
@@ -111,6 +111,7 @@ static const struct v4l2_ctrl_config hgo_max_rgb_control = {
.max = 1,
.def = 0,
.step = 1,
+   .flags = V4L2_CTRL_FLAG_MODIFY_LAYOUT,
 };
 
 static const s64 hgo_num_bins[] = {
@@ -125,6 +126,7 @@ static const struct v4l2_ctrl_config hgo_num_bins_control = 
{
.max = 1,
.def = 0,
.qmenu_int = hgo_num_bins,
+   .flags = V4L2_CTRL_FLAG_MODIFY_LAYOUT,
 };
 
 /* 
-
-- 
2.11.0

[PATCHv4 01/15] v4l: Clearly document interactions between formats, controls and buffers

[Hans Verkuil]

From: Laurent Pinchart 

V4L2 exposes parameters that influence buffers sizes through the format
ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly
VIDIOC_G_SELECTION and VIDIOC_S_SELECTION). Other parameters not part of
the format structure may also influence buffer sizes or buffer layout in
general. One existing such parameter is rotation, which is implemented
by the V4L2_CID_ROTATE control and thus exposed through the V4L2 control
ioctls.

The interaction between those parameters and buffers is currently only
partially specified by the V4L2 API. In particular interactions between
controls and buffers isn't specified at all. The behaviour of the
VIDIOC_S_FMT and VIDIOC_S_SELECTION ioctls when buffers are allocated is
also not fully specified.

This patch clearly defines and documents the interactions between
formats, selections, controls and buffers.

The preparatory discussions for the documentation change considered
completely disallowing controls that change the buffer size or layout,
in favour of extending the format API with a new ioctl that would bundle
those controls with format information. The idea has been rejected, as
this would essentially be a restricted version of the upcoming request
API that wouldn't bring any additional value.

Another option we have considered was to mandate the use of the request
API to modify controls that influence buffer size or layout. This has
also been rejected on the grounds that requiring the request API to
change rotation even when streaming is stopped would significantly
complicate implementation of drivers and usage of the V4L2 API for
applications.

Applications will however be required to use the upcoming request API to
change at runtime formats or controls that influence the buffer size or
layout, because of the need to synchronize buffers with the formats and
controls. Otherwise there would be no way to interpret the content of a
buffer correctly.

Signed-off-by: Laurent Pinchart 
Acked-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/buffer.rst | 110 
 1 file changed, 110 insertions(+)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ac58966ccb9b..d1e0d55dc219 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -34,6 +34,116 @@ flags are copied from the OUTPUT video buffer to the 
CAPTURE video
 buffer.
 
 
+Interactions between formats, controls and buffers
+==
+
+V4L2 exposes parameters that influence the buffer size, or the way data is
+laid out in the buffer. Those parameters are exposed through both formats and
+controls. One example of such a control is the ``V4L2_CID_ROTATE`` control
+that modifies the direction in which pixels are stored in the buffer, as well
+as the buffer size when the selected format includes padding at the end of
+lines.
+
+The set of information needed to interpret the content of a buffer (e.g. the
+pixel format, the line stride, the tiling orientation or the rotation) is
+collectively referred to in the rest of this section as the buffer layout.
+
+Modifying formats or controls that influence the buffer size or layout require
+the stream to be stopped. Any attempt at such a modification while the stream
+is active shall cause the ioctl setting the format or the control to return
+the ``EBUSY`` error code.
+
+.. note::
+
+   The :c:func:`VIDIOC_S_SELECTION` ioctl can, depending on the hardware (for
+   instance if the device doesn't include a scaler), modify the format in
+   addition to the selection rectangle. Similarly, the
+   :c:func:`VIDIOC_S_INPUT`, :c:func:`VIDIOC_S_OUTPUT`, :c:func:`VIDIOC_S_STD`
+   and :c:func:`VIDIOC_S_DV_TIMINGS` ioctls can also modify the format and
+   selection rectangles. When those ioctls result in a buffer size or layout
+   change, drivers shall handle that condition as they would handle it in the
+   :c:func:`VIDIOC_S_FMT` ioctl in all cases described in this section.
+
+Controls that only influence the buffer layout can be modified at any time
+when the stream is stopped. As they don't influence the buffer size, no
+special handling is needed to synchronize those controls with buffer
+allocation.
+
+Formats and controls that influence the buffer size interact with buffer
+allocation. The simplest way to handle this is for drivers to always require
+buffers to be reallocated in order to change those formats or controls. In
+that case, to perform such changes, userspace applications shall first stop
+the video stream with the :c:func:`VIDIOC_STREAMOFF` ioctl if it is running
+and free all buffers with the :c:func:`VIDIOC_REQBUFS` ioctl if they are
+allocated. The format or controls can then be modified, and buffers shall then

[PATCHv4 05/15] v4l: vsp1: Support histogram generators in pipeline configuration

[Hans Verkuil]

From: Laurent Pinchart 

Histogram generators are single-pad entities that branch as leaf nodes
at any point in the pipeline. Make sure that pipeline traversal and
routing configuration support them correctly.

Support for the actual HGO and HGT operation will come later.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c|   2 +-
 drivers/media/platform/vsp1/vsp1_drv.c|   4 +-
 drivers/media/platform/vsp1/vsp1_entity.c | 124 ++
 drivers/media/platform/vsp1/vsp1_entity.h |   8 +-
 drivers/media/platform/vsp1/vsp1_pipe.c   |   6 +-
 drivers/media/platform/vsp1/vsp1_video.c  |  18 ++---
 6 files changed, 134 insertions(+), 28 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 1f88d8473b71..9d235e830f5a 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -496,7 +496,7 @@ void vsp1_du_atomic_flush(struct device *dev)
}
}
 
-   vsp1_entity_route_setup(entity, dl);
+   vsp1_entity_route_setup(entity, pipe, dl);
 
if (entity->ops->configure) {
entity->ops->configure(entity, pipe, dl,
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 8d1e61b353bb..83a6669a6328 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -105,7 +105,9 @@ static int vsp1_create_sink_links(struct vsp1_device *vsp1,
if (source->type == sink->type)
continue;
 
-   if (source->type == VSP1_ENTITY_LIF ||
+   if (source->type == VSP1_ENTITY_HGO ||
+   source->type == VSP1_ENTITY_HGT ||
+   source->type == VSP1_ENTITY_LIF ||
source->type == VSP1_ENTITY_WPF)
continue;
 
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c 
b/drivers/media/platform/vsp1/vsp1_entity.c
index 12eca5660d6e..88a2aae182ba 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -21,6 +21,8 @@
 #include "vsp1.h"
 #include "vsp1_dl.h"
 #include "vsp1_entity.h"
+#include "vsp1_pipe.h"
+#include "vsp1_rwpf.h"
 
 static inline struct vsp1_entity *
 media_entity_to_vsp1_entity(struct media_entity *entity)
@@ -28,11 +30,14 @@ media_entity_to_vsp1_entity(struct media_entity *entity)
return container_of(entity, struct vsp1_entity, subdev.entity);
 }
 
-void vsp1_entity_route_setup(struct vsp1_entity *source,
+void vsp1_entity_route_setup(struct vsp1_entity *entity,
+struct vsp1_pipeline *pipe,
 struct vsp1_dl_list *dl)
 {
+   struct vsp1_entity *source;
struct vsp1_entity *sink;
 
+   source = entity;
if (source->route->reg == 0)
return;
 
@@ -283,25 +288,32 @@ int vsp1_subdev_enum_frame_size(struct v4l2_subdev 
*subdev,
  * Media Operations
  */
 
-int vsp1_entity_link_setup(struct media_entity *entity,
-  const struct media_pad *local,
-  const struct media_pad *remote, u32 flags)
+static int vsp1_entity_link_setup_source(const struct media_pad *source_pad,
+const struct media_pad *sink_pad,
+u32 flags)
 {
struct vsp1_entity *source;
 
-   if (!(local->flags & MEDIA_PAD_FL_SOURCE))
-   return 0;
-
-   source = media_entity_to_vsp1_entity(local->entity);
+   source = media_entity_to_vsp1_entity(source_pad->entity);
 
if (!source->route)
return 0;
 
if (flags & MEDIA_LNK_FL_ENABLED) {
-   if (source->sink)
-   return -EBUSY;
-   source->sink = remote->entity;
-   source->sink_pad = remote->index;
+   struct vsp1_entity *sink
+   = media_entity_to_vsp1_entity(sink_pad->entity);
+
+   /*
+* Fan-out is limited to one for the normal data path plus
+* optional HGO and HGT. We ignore the HGO and HGT here.
+*/
+   if (sink->type != VSP1_ENTITY_HGO &&
+   sink->type != VSP1_ENTITY_HGT) {
+   if (source->sink)
+   return -EBUSY;
+   source->sink = sink_pad->entity;
+   source->sink_pad = sink_pad->index;
+   }
} else {
source->sink = NULL;
source->sink_pad = 0;
@@ -310,6 +322,85 @@ int vsp1_entity_link_setup(struct media_entity *entity,
return 0;
 }
 
+static int vsp1_entity_link_setup_sink(const struct media_pad *source_pad,
+

[PATCHv4 08/15] v4l: vsp1: Add HGO support

[Hans Verkuil]

From: Laurent Pinchart 

The HGO is a Histogram Generator One-Dimension. It computes per-channel
histograms over a configurable region of the image with optional
subsampling.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/Makefile  |   2 +-
 drivers/media/platform/vsp1/vsp1.h|   3 +
 drivers/media/platform/vsp1/vsp1_drv.c|  42 --
 drivers/media/platform/vsp1/vsp1_entity.c |  16 +++
 drivers/media/platform/vsp1/vsp1_hgo.c| 228 ++
 drivers/media/platform/vsp1/vsp1_hgo.h|  45 ++
 drivers/media/platform/vsp1/vsp1_pipe.c   |  16 +++
 drivers/media/platform/vsp1/vsp1_pipe.h   |   2 +
 drivers/media/platform/vsp1/vsp1_regs.h   |  20 ++-
 drivers/media/platform/vsp1/vsp1_video.c  |   6 +
 10 files changed, 367 insertions(+), 13 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.h

diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index c559536f7867..8ab6a063569e 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -3,7 +3,7 @@ vsp1-y  += vsp1_dl.o vsp1_drm.o 
vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
 vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
-vsp1-y += vsp1_histo.o
+vsp1-y += vsp1_hgo.o vsp1_histo.o
 vsp1-y += vsp1_lif.o
 
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1.o
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index b23fa879a9aa..0ba7521c01b4 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -32,6 +32,7 @@ struct vsp1_entity;
 struct vsp1_platform_data;
 struct vsp1_bru;
 struct vsp1_clu;
+struct vsp1_hgo;
 struct vsp1_hsit;
 struct vsp1_lif;
 struct vsp1_lut;
@@ -50,6 +51,7 @@ struct vsp1_uds;
 #define VSP1_HAS_CLU   (1 << 4)
 #define VSP1_HAS_WPF_VFLIP (1 << 5)
 #define VSP1_HAS_WPF_HFLIP (1 << 6)
+#define VSP1_HAS_HGO   (1 << 7)
 
 struct vsp1_device_info {
u32 version;
@@ -73,6 +75,7 @@ struct vsp1_device {
 
struct vsp1_bru *bru;
struct vsp1_clu *clu;
+   struct vsp1_hgo *hgo;
struct vsp1_hsit *hsi;
struct vsp1_hsit *hst;
struct vsp1_lif *lif;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 83a6669a6328..0acc8ed6ac59 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -30,6 +30,7 @@
 #include "vsp1_clu.h"
 #include "vsp1_dl.h"
 #include "vsp1_drm.h"
+#include "vsp1_hgo.h"
 #include "vsp1_hsit.h"
 #include "vsp1_lif.h"
 #include "vsp1_lut.h"
@@ -150,6 +151,16 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1)
return ret;
}
 
+   if (vsp1->hgo) {
+   ret = 
media_create_pad_link(>hgo->histo.entity.subdev.entity,
+   HISTO_PAD_SOURCE,
+   >hgo->histo.video.entity, 0,
+   MEDIA_LNK_FL_ENABLED |
+   MEDIA_LNK_FL_IMMUTABLE);
+   if (ret < 0)
+   return ret;
+   }
+
if (vsp1->lif) {
ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
RWPF_PAD_SOURCE,
@@ -283,6 +294,17 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
 
list_add_tail(>hst->entity.list_dev, >entities);
 
+   if (vsp1->info->features & VSP1_HAS_HGO && vsp1->info->uapi) {
+   vsp1->hgo = vsp1_hgo_create(vsp1);
+   if (IS_ERR(vsp1->hgo)) {
+   ret = PTR_ERR(vsp1->hgo);
+   goto done;
+   }
+
+   list_add_tail(>hgo->histo.entity.list_dev,
+ >entities);
+   }
+
/*
 * The LIF is only supported when used in conjunction with the DU, in
 * which case the userspace API is disabled. If the userspace API is
@@ -568,8 +590,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPS_H2,
.model = "VSP1-S",
.gen = 2,
-   .features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_LUT
- | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
+   .features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
+ | VSP1_HAS_LUT | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
.rpf_count = 5,
 

[PATCHv4 13/15] v4l2-ctrls.c: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for ROTATE

[Hans Verkuil]

From: Hans Verkuil 

The rotate control will modify the layout by definition. Always
set this flag.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b4b364f68695..ec42872d11cf 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -997,6 +997,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
*min = 0;
*max = *step = 1;
break;
+   case V4L2_CID_ROTATE:
+   *type = V4L2_CTRL_TYPE_INTEGER;
+   *flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
+   break;
case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
*type = V4L2_CTRL_TYPE_INTEGER;
-- 
2.11.0

[PATCHv4 12/15] videodev.h: add V4L2_CTRL_FLAG_MODIFY_LAYOUT

[Hans Verkuil]

From: Hans Verkuil 

Add new flag to indicate that changing this control will change the
buffer/mediabus layout as well.

Signed-off-by: Hans Verkuil 
---
 include/uapi/linux/videodev2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 75f032448ae5..2b8feb86d09e 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1659,6 +1659,7 @@ struct v4l2_querymenu {
 #define V4L2_CTRL_FLAG_VOLATILE0x0080
 #define V4L2_CTRL_FLAG_HAS_PAYLOAD 0x0100
 #define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE0x0200
+#define V4L2_CTRL_FLAG_MODIFY_LAYOUT   0x0400
 
 /*  Query flags, to be ORed with the control ID */
 #define V4L2_CTRL_FLAG_NEXT_CTRL   0x8000
-- 
2.11.0

[PATCHv4 00/15] R-Car VSP1 Histogram Support

[Hans Verkuil]

From: Hans Verkuil 

This patch series is the rebased version of this pull request:

https://www.mail-archive.com/linux-media@vger.kernel.org/msg111025.html

It slightly modifies 'Add metadata buffer type and format' (remove
experimental note and add newline after label) and it adds support
for V4L2_CTRL_FLAG_MODIFY_LAYOUT, as requested by Mauro.

No other changes were made.

Regards,

Hans

Hans Verkuil (5):
  vidioc-queryctrl.rst: document V4L2_CTRL_FLAG_MODIFY_LAYOUT
  videodev.h: add V4L2_CTRL_FLAG_MODIFY_LAYOUT
  v4l2-ctrls.c: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for ROTATE
  buffer.rst: clarify how V4L2_CTRL_FLAG_MODIFY_LAYOUT/GRABBER are used
  vsp1: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for histogram controls

Laurent Pinchart (8):
  v4l: Clearly document interactions between formats, controls and
buffers
  v4l: vsp1: wpf: Implement rotation support
  v4l: Add metadata buffer type and format
  v4l: vsp1: Add histogram support
  v4l: vsp1: Support histogram generators in pipeline configuration
  v4l: vsp1: Fix HGO and HGT routing register addresses
  v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine
  v4l: vsp1: Add HGO support

Niklas Söderlund (2):
  v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine
  v4l: vsp1: Add HGT support

 Documentation/media/uapi/v4l/buffer.rst| 122 
 Documentation/media/uapi/v4l/dev-meta.rst  |  58 ++
 Documentation/media/uapi/v4l/devices.rst   |   1 +
 Documentation/media/uapi/v4l/meta-formats.rst  |  16 +
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst| 168 ++
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 120 
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 Documentation/media/uapi/v4l/vidioc-querycap.rst   |   3 +
 Documentation/media/uapi/v4l/vidioc-queryctrl.rst  |  13 +
 Documentation/media/videodev2.h.rst.exceptions |   3 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/vsp1/Makefile   |   1 +
 drivers/media/platform/vsp1/vsp1.h |   6 +
 drivers/media/platform/vsp1/vsp1_drm.c |   2 +-
 drivers/media/platform/vsp1/vsp1_drv.c |  70 ++-
 drivers/media/platform/vsp1/vsp1_entity.c  | 154 -
 drivers/media/platform/vsp1/vsp1_entity.h  |   8 +-
 drivers/media/platform/vsp1/vsp1_hgo.c | 230 
 drivers/media/platform/vsp1/vsp1_hgo.h |  45 ++
 drivers/media/platform/vsp1/vsp1_hgt.c | 222 +++
 drivers/media/platform/vsp1/vsp1_hgt.h |  42 ++
 drivers/media/platform/vsp1/vsp1_histo.c   | 646 +
 drivers/media/platform/vsp1/vsp1_histo.h   |  84 +++
 drivers/media/platform/vsp1/vsp1_pipe.c|  38 +-
 drivers/media/platform/vsp1/vsp1_pipe.h|   4 +
 drivers/media/platform/vsp1/vsp1_regs.h|  33 +-
 drivers/media/platform/vsp1/vsp1_rpf.c |   2 +-
 drivers/media/platform/vsp1/vsp1_rwpf.c|   5 +
 drivers/media/platform/vsp1/vsp1_rwpf.h|   7 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  42 +-
 drivers/media/platform/vsp1/vsp1_wpf.c | 205 +--
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c  |  19 +
 drivers/media/v4l2-core/v4l2-ctrls.c   |   4 +
 drivers/media/v4l2-core/v4l2-dev.c |  16 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |  36 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c   |   3 +
 include/media/v4l2-ioctl.h |  17 +
 include/trace/events/v4l2.h|   1 +
 include/uapi/linux/videodev2.h |  18 +
 39 files changed, 2364 insertions(+), 102 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst
 create mode 100644 Documentation/media/uapi/v4l/meta-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.h
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h
 create mode 100644 drivers/media/platform/vsp1/vsp1_histo.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_histo.h

-- 
2.11.0

[PATCHv4 07/15] v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine

[Hans Verkuil]

From: Laurent Pinchart 

The format is used on the R-Car VSP1 video queues that carry
1-D histogram statistics data.

Signed-off-by: Laurent Pinchart 
Acked-by: Sakari Ailus 
---
 Documentation/media/uapi/v4l/meta-formats.rst  |  15 ++
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst| 168 +
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
 include/uapi/linux/videodev2.h |   3 +
 5 files changed, 188 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/meta-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst

diff --git a/Documentation/media/uapi/v4l/meta-formats.rst 
b/Documentation/media/uapi/v4l/meta-formats.rst
new file mode 100644
index ..05ab91e12f10
--- /dev/null
+++ b/Documentation/media/uapi/v4l/meta-formats.rst
@@ -0,0 +1,15 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _meta-formats:
+
+
+Metadata Formats
+
+
+These formats are used for the :ref:`metadata` interface only.
+
+
+.. toctree::
+:maxdepth: 1
+
+pixfmt-meta-vsp1-hgo
diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst 
b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
new file mode 100644
index ..8d37bb313493
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
@@ -0,0 +1,168 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _v4l2-meta-fmt-vsp1-hgo:
+
+***
+V4L2_META_FMT_VSP1_HGO ('VSPH')
+***
+
+Renesas R-Car VSP1 1-D Histogram Data
+
+
+Description
+===
+
+This format describes histogram data generated by the Renesas R-Car VSP1 1-D
+Histogram (HGO) engine.
+
+The VSP1 HGO is a histogram computation engine that can operate on RGB, YCrCb
+or HSV data. It operates on a possibly cropped and subsampled input image and
+computes the minimum, maximum and sum of all pixels as well as per-channel
+histograms.
+
+The HGO can compute histograms independently per channel, on the maximum of the
+three channels (RGB data only) or on the Y channel only (YCbCr only). It can
+additionally output the histogram with 64 or 256 bins, resulting in four
+possible modes of operation.
+
+- In *64 bins normal mode*, the HGO operates on the three channels 
independently
+  to compute three 64-bins histograms. RGB, YCbCr and HSV image formats are
+  supported.
+- In *64 bins maximum mode*, the HGO operates on the maximum of the (R, G, B)
+  channels to compute a single 64-bins histogram. Only the RGB image format is
+  supported.
+- In *256 bins normal mode*, the HGO operates on the Y channel to compute a
+  single 256-bins histogram. Only the YCbCr image format is supported.
+- In *256 bins maximum mode*, the HGO operates on the maximum of the (R, G, B)
+  channels to compute a single 256-bins histogram. Only the RGB image format is
+  supported.
+
+**Byte Order.**
+All data is stored in memory in little endian format. Each cell in the tables
+contains one byte.
+
+.. flat-table:: VSP1 HGO Data - 64 Bins, Normal Mode (792 bytes)
+:header-rows:  2
+:stub-columns: 0
+
+* - Offset
+  - :cspan:`4` Memory
+* -
+  - [31:24]
+  - [23:16]
+  - [15:8]
+  - [7:0]
+* - 0
+  - -
+  - R/Cr/H max [7:0]
+  - -
+  - R/Cr/H min [7:0]
+* - 4
+  - -
+  - G/Y/S max [7:0]
+  - -
+  - G/Y/S min [7:0]
+* - 8
+  - -
+  - B/Cb/V max [7:0]
+  - -
+  - B/Cb/V min [7:0]
+* - 12
+  - :cspan:`4` R/Cr/H sum [31:0]
+* - 16
+  - :cspan:`4` G/Y/S sum [31:0]
+* - 20
+  - :cspan:`4` B/Cb/V sum [31:0]
+* - 24
+  - :cspan:`4` R/Cr/H bin 0 [31:0]
+* -
+  - :cspan:`4` ...
+* - 276
+  - :cspan:`4` R/Cr/H bin 63 [31:0]
+* - 280
+  - :cspan:`4` G/Y/S bin 0 [31:0]
+* -
+  - :cspan:`4` ...
+* - 532
+  - :cspan:`4` G/Y/S bin 63 [31:0]
+* - 536
+  - :cspan:`4` B/Cb/V bin 0 [31:0]
+* -
+  - :cspan:`4` ...
+* - 788
+  - :cspan:`4` B/Cb/V bin 63 [31:0]
+
+.. flat-table:: VSP1 HGO Data - 64 Bins, Max Mode (264 bytes)
+:header-rows:  2
+:stub-columns: 0
+
+* - Offset
+  - :cspan:`4` Memory
+* -
+  - [31:24]
+  - [23:16]
+  - [15:8]
+  - [7:0]
+* - 0
+  - -
+  - max(R,G,B) max [7:0]
+  - -
+  - max(R,G,B) min [7:0]
+* - 4
+  - :cspan:`4` max(R,G,B) sum [31:0]
+* - 8
+  - :cspan:`4` max(R,G,B) bin 0 [31:0]
+* -
+  - :cspan:`4` ...
+* - 260
+  - :cspan:`4` max(R,G,B) bin 63 [31:0]
+
+.. flat-table:: VSP1 HGO Data - 256 Bins, Normal Mode (1032 bytes)
+:header-rows:  2
+:stub-columns: 0
+
+* - Offset
+  - :cspan:`4` Memory
+* -
+  - [31:24]
+  - [23:16]
+  - [15:8]
+  - 

[PATCHv4 06/15] v4l: vsp1: Fix HGO and HGT routing register addresses

[Hans Verkuil]

From: Laurent Pinchart 

The addresses are incorrect, fix them.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_regs.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
b/drivers/media/platform/vsp1/vsp1_regs.h
index 47b1dee044fb..61369e267667 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -328,8 +328,8 @@
 #define VI6_DPR_ROUTE_RT_MASK  (0x3f << 0)
 #define VI6_DPR_ROUTE_RT_SHIFT 0
 
-#define VI6_DPR_HGO_SMPPT  0x2050
-#define VI6_DPR_HGT_SMPPT  0x2054
+#define VI6_DPR_HGO_SMPPT  0x2054
+#define VI6_DPR_HGT_SMPPT  0x2058
 #define VI6_DPR_SMPPT_TGW_MASK (7 << 8)
 #define VI6_DPR_SMPPT_TGW_SHIFT8
 #define VI6_DPR_SMPPT_PT_MASK  (0x3f << 0)
-- 
2.11.0

[PATCHv4 03/15] v4l: Add metadata buffer type and format

[Hans Verkuil]

From: Laurent Pinchart 

The metadata buffer type is used to transfer metadata between userspace
and kernelspace through a V4L2 buffers queue. It comes with a new
metadata capture capability and format description.

Signed-off-by: Laurent Pinchart 
Tested-by: Guennadi Liakhovetski 
Acked-by: Sakari Ailus 
Acked-by: Hans Verkuil 
[hans.verk...@cisco.com: removed left-over 'experimental' note]
[hans.verk...@cisco.com: add newline after _v4l2-meta-format label]
---
 Documentation/media/uapi/v4l/buffer.rst  |  3 ++
 Documentation/media/uapi/v4l/dev-meta.rst| 58 
 Documentation/media/uapi/v4l/devices.rst |  1 +
 Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 ++
 Documentation/media/videodev2.h.rst.exceptions   |  2 +
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 
 drivers/media/v4l2-core/v4l2-dev.c   | 16 ---
 drivers/media/v4l2-core/v4l2-ioctl.c | 34 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c |  3 ++
 include/media/v4l2-ioctl.h   | 17 +++
 include/trace/events/v4l2.h  |  1 +
 include/uapi/linux/videodev2.h   | 13 ++
 12 files changed, 164 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index d1e0d55dc219..64613d935edd 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -440,6 +440,9 @@ enum v4l2_buf_type
   - 12
   - Buffer for Software Defined Radio (SDR) output stream, see
:ref:`sdr`.
+* - ``V4L2_BUF_TYPE_META_CAPTURE``
+  - 13
+  - Buffer for metadata capture, see :ref:`metadata`.
 
 
 
diff --git a/Documentation/media/uapi/v4l/dev-meta.rst 
b/Documentation/media/uapi/v4l/dev-meta.rst
new file mode 100644
index ..62518adfe37b
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-meta.rst
@@ -0,0 +1,58 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _metadata:
+
+**
+Metadata Interface
+**
+
+Metadata refers to any non-image data that supplements video frames with
+additional information. This may include statistics computed over the image
+or frame capture parameters supplied by the image source. This interface is
+intended for transfer of metadata to userspace and control of that operation.
+
+The metadata interface is implemented on video capture device nodes. The device
+can be dedicated to metadata or can implement both video and metadata capture
+as specified in its reported capabilities.
+
+Querying Capabilities
+=
+
+Device nodes supporting the metadata interface set the 
``V4L2_CAP_META_CAPTURE``
+flag in the ``device_caps`` field of the
+:c:type:`v4l2_capability` structure returned by the :c:func:`VIDIOC_QUERYCAP`
+ioctl. That flag means the device can capture metadata to memory.
+
+At least one of the read/write or streaming I/O methods must be supported.
+
+
+Data Format Negotiation
+===
+
+The metadata device uses the :ref:`format` ioctls to select the capture format.
+The metadata buffer content format is bound to that selected format. In 
addition
+to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl must be
+supported as well.
+
+To use the :ref:`format` ioctls applications set the ``type`` field of the
+:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use the
+:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed per
+the desired operation. Both drivers and applications must set the remainder of
+the :c:type:`v4l2_format` structure to 0.
+
+.. _v4l2-meta-format:
+
+.. flat-table:: struct v4l2_meta_format
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u32
+  - ``dataformat``
+  - The data format, set by the application. This is a little endian
+:ref:`four character code `. V4L2 defines metadata formats
+in :ref:`meta-formats`.
+* - __u32
+  - ``buffersize``
+  - Maximum buffer size in bytes required for data. The value is set by the
+driver.
diff --git a/Documentation/media/uapi/v4l/devices.rst 
b/Documentation/media/uapi/v4l/devices.rst
index 5c3d6c29e12c..fb7f8c26cf09 100644
--- a/Documentation/media/uapi/v4l/devices.rst
+++ b/Documentation/media/uapi/v4l/devices.rst
@@ -25,3 +25,4 @@ Interfaces
 dev-touch
 dev-event
 dev-subdev
+dev-meta
diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 165d8314327e..12e0d9a63cd8 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ 

[PATCHv4 02/15] v4l: vsp1: wpf: Implement rotation support

[Hans Verkuil]

From: Laurent Pinchart 

Some WPF instances, on Gen3 devices, can perform 90° rotation when
writing frames to memory. Implement support for this using the
V4L2_CID_ROTATE control.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_rpf.c   |   2 +-
 drivers/media/platform/vsp1/vsp1_rwpf.c  |   5 +
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   7 +-
 drivers/media/platform/vsp1/vsp1_video.c |  12 +-
 drivers/media/platform/vsp1/vsp1_wpf.c   | 205 +++
 5 files changed, 177 insertions(+), 54 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index f5a9a4c8c74d..8feddd59cf8d 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -106,7 +106,7 @@ static void rpf_configure(struct vsp1_entity *entity,
 * of the pipeline.
 */
output = vsp1_entity_get_pad_format(wpf, wpf->config,
-   RWPF_PAD_SOURCE);
+   RWPF_PAD_SINK);
 
crop.width = pipe->partition.width * input_width
   / output->width;
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c 
b/drivers/media/platform/vsp1/vsp1_rwpf.c
index 7d52c88a583e..cfd8f1904fa6 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
@@ -121,6 +121,11 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
RWPF_PAD_SOURCE);
*format = fmt->format;
 
+   if (rwpf->flip.rotate) {
+   format->width = fmt->format.height;
+   format->height = fmt->format.width;
+   }
+
 done:
mutex_unlock(>entity.lock);
return ret;
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h 
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index 1c98aff3da5d..58215a7ab631 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -56,9 +56,14 @@ struct vsp1_rwpf {
 
struct {
spinlock_t lock;
-   struct v4l2_ctrl *ctrls[2];
+   struct {
+   struct v4l2_ctrl *vflip;
+   struct v4l2_ctrl *hflip;
+   struct v4l2_ctrl *rotate;
+   } ctrls;
unsigned int pending;
unsigned int active;
+   bool rotate;
} flip;
 
struct vsp1_rwpf_memory mem;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 5239e08fabc3..795a3ca9ca03 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -187,9 +187,13 @@ static void vsp1_video_pipeline_setup_partitions(struct 
vsp1_pipeline *pipe)
struct vsp1_entity *entity;
unsigned int div_size;
 
+   /*
+* Partitions are computed on the size before rotation, use the format
+* at the WPF sink.
+*/
format = vsp1_entity_get_pad_format(>output->entity,
pipe->output->entity.config,
-   RWPF_PAD_SOURCE);
+   RWPF_PAD_SINK);
div_size = format->width;
 
/* Gen2 hardware doesn't require image partitioning. */
@@ -229,9 +233,13 @@ static struct v4l2_rect vsp1_video_partition(struct 
vsp1_pipeline *pipe,
struct v4l2_rect partition;
unsigned int modulus;
 
+   /*
+* Partitions are computed on the size before rotation, use the format
+* at the WPF sink.
+*/
format = vsp1_entity_get_pad_format(>output->entity,
pipe->output->entity.config,
-   RWPF_PAD_SOURCE);
+   RWPF_PAD_SINK);
 
/* A single partition simply processes the output size in full. */
if (pipe->partitions <= 1) {
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 25a2ed6e2e18..32df109b119f 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -43,32 +43,90 @@ static inline void vsp1_wpf_write(struct vsp1_rwpf *wpf,
 enum wpf_flip_ctrl {
WPF_CTRL_VFLIP = 0,
WPF_CTRL_HFLIP = 1,
-   WPF_CTRL_MAX,
 };
 
+static int vsp1_wpf_set_rotation(struct vsp1_rwpf *wpf, unsigned int rotation)
+{
+   struct vsp1_video *video = wpf->video;
+   struct v4l2_mbus_framefmt *sink_format;
+   struct v4l2_mbus_framefmt *source_format;
+   bool rotate;
+   int ret = 0;
+
+   /*
+* Only consider the 0°/180° from/to 90°/270° 

[PATCHv4 04/15] v4l: vsp1: Add histogram support

[Hans Verkuil]

From: Laurent Pinchart 

The histogram common code will be used to implement support for both the
HGO and HGT histogram computation engines.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/vsp1/Makefile |   1 +
 drivers/media/platform/vsp1/vsp1_histo.c | 646 +++
 drivers/media/platform/vsp1/vsp1_histo.h |  84 
 4 files changed, 732 insertions(+)
 create mode 100644 drivers/media/platform/vsp1/vsp1_histo.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_histo.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7321f6123659..552e7f2df6fd 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -420,6 +420,7 @@ config VIDEO_RENESAS_VSP1
depends on (ARCH_RENESAS && OF) || COMPILE_TEST
depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
select VIDEOBUF2_DMA_CONTIG
+   select VIDEOBUF2_VMALLOC
---help---
  This is a V4L2 driver for the Renesas VSP1 video processing engine.
 
diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index 1328e1bd2143..c559536f7867 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -3,6 +3,7 @@ vsp1-y  += vsp1_dl.o vsp1_drm.o 
vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
 vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
+vsp1-y += vsp1_histo.o
 vsp1-y += vsp1_lif.o
 
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1.o
diff --git a/drivers/media/platform/vsp1/vsp1_histo.c 
b/drivers/media/platform/vsp1/vsp1_histo.c
new file mode 100644
index ..afab77cf4fa5
--- /dev/null
+++ b/drivers/media/platform/vsp1/vsp1_histo.c
@@ -0,0 +1,646 @@
+/*
+ * vsp1_histo.c  --  R-Car VSP1 Histogram API
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2016 Laurent Pinchart
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "vsp1.h"
+#include "vsp1_histo.h"
+#include "vsp1_pipe.h"
+
+#define HISTO_MIN_SIZE 4U
+#define HISTO_MAX_SIZE 8192U
+
+/* 
-
+ * Buffer Operations
+ */
+
+static inline struct vsp1_histogram_buffer *
+to_vsp1_histogram_buffer(struct vb2_v4l2_buffer *vbuf)
+{
+   return container_of(vbuf, struct vsp1_histogram_buffer, buf);
+}
+
+struct vsp1_histogram_buffer *
+vsp1_histogram_buffer_get(struct vsp1_histogram *histo)
+{
+   struct vsp1_histogram_buffer *buf = NULL;
+   unsigned long flags;
+
+   spin_lock_irqsave(>irqlock, flags);
+
+   if (list_empty(>irqqueue))
+   goto done;
+
+   buf = list_first_entry(>irqqueue, struct vsp1_histogram_buffer,
+  queue);
+   list_del(>queue);
+   histo->readout = true;
+
+done:
+   spin_unlock_irqrestore(>irqlock, flags);
+   return buf;
+}
+
+void vsp1_histogram_buffer_complete(struct vsp1_histogram *histo,
+   struct vsp1_histogram_buffer *buf,
+   size_t size)
+{
+   struct vsp1_pipeline *pipe = histo->pipe;
+   unsigned long flags;
+
+   /*
+* The pipeline pointer is guaranteed to be valid as this function is
+* called from the frame completion interrupt handler, which can only
+* occur when video streaming is active.
+*/
+   buf->buf.sequence = pipe->sequence;
+   buf->buf.vb2_buf.timestamp = ktime_get_ns();
+   vb2_set_plane_payload(>buf.vb2_buf, 0, size);
+   vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
+
+   spin_lock_irqsave(>irqlock, flags);
+   histo->readout = false;
+   wake_up(>wait_queue);
+   spin_unlock_irqrestore(>irqlock, flags);
+}
+
+/* 
-
+ * videobuf2 Queue Operations
+ */
+
+static int histo_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
+unsigned int *nplanes, unsigned int sizes[],
+struct device *alloc_devs[])
+{
+   struct vsp1_histogram *histo = vb2_get_drv_priv(vq);
+
+   if (*nplanes) {
+   if (*nplanes != 1)
+  

Re: [PATCH 1/5] dt-bindings: media: Add document file for CXD2880 SPI I/F

[Rob Herring]

On Thu, Apr 06, 2017 at 04:54:33PM +0900, yasunari.takigu...@sony.com wrote:
> From: Yasunari Takiguchi 
> 
> This is the document file for Sony CXD2880 DVB-T2/T tuner + demodulator.
> It contains the description of the SPI adapter binding.
> 
> Signed-off-by: Yasunari Takiguchi 
> Signed-off-by: Masayuki Yamamoto 
> Signed-off-by: Hideki Nozawa 
> Signed-off-by: Kota Yonezawa 
> Signed-off-by: Toshihiko Matsumoto 
> Signed-off-by: Satoshi Watanabe 
> ---
>  .../devicetree/bindings/media/spi/sony-cxd2880.txt |   14 ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt

Acked-by: Rob Herring 

Re: [PATCH v3 1/8] v4l: Add metadata buffer type and format

[Mauro Carvalho Chehab]

Em Mon, 10 Apr 2017 19:58:46 +0200
Hans Verkuil  escreveu:

> On 04/10/2017 07:23 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Feb 2017 17:56:41 +0200
> > Laurent Pinchart  escreveu:
> >   
> >> The metadata buffer type is used to transfer metadata between userspace
> >> and kernelspace through a V4L2 buffers queue. It comes with a new
> >> metadata capture capability and format description.
> >>
> >> Signed-off-by: Laurent Pinchart 
> >> Tested-by: Guennadi Liakhovetski 
> >> Acked-by: Sakari Ailus 
> >> Acked-by: Hans Verkuil 
> >> ---
> >>  Documentation/media/uapi/v4l/buffer.rst  |  3 ++
> >>  Documentation/media/uapi/v4l/dev-meta.rst| 62 
> >> 
> >>  Documentation/media/uapi/v4l/devices.rst |  1 +
> >>  Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 ++
> >>  Documentation/media/videodev2.h.rst.exceptions   |  2 +
> >>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 
> >>  drivers/media/v4l2-core/v4l2-dev.c   | 16 +++---
> >>  drivers/media/v4l2-core/v4l2-ioctl.c | 34 +
> >>  drivers/media/v4l2-core/videobuf2-v4l2.c |  3 ++
> >>  include/media/v4l2-ioctl.h   | 17 +++
> >>  include/trace/events/v4l2.h  |  1 +
> >>  include/uapi/linux/videodev2.h   | 13 +
> >>  12 files changed, 168 insertions(+), 6 deletions(-)
> >>  create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst
> >>
> >> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> >> b/Documentation/media/uapi/v4l/buffer.rst
> >> index 5c58db98ab7a..02834ce7fa4d 100644
> >> --- a/Documentation/media/uapi/v4l/buffer.rst
> >> +++ b/Documentation/media/uapi/v4l/buffer.rst
> >> @@ -418,6 +418,9 @@ enum v4l2_buf_type
> >>- 12
> >>- Buffer for Software Defined Radio (SDR) output stream, see
> >>:ref:`sdr`.
> >> +* - ``V4L2_BUF_TYPE_META_CAPTURE``
> >> +  - 13
> >> +  - Buffer for metadata capture, see :ref:`metadata`.
> >>  
> >>  
> >>  
> >> diff --git a/Documentation/media/uapi/v4l/dev-meta.rst 
> >> b/Documentation/media/uapi/v4l/dev-meta.rst
> >> new file mode 100644
> >> index ..b6044c54082a
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/v4l/dev-meta.rst
> >> @@ -0,0 +1,62 @@
> >> +.. -*- coding: utf-8; mode: rst -*-
> >> +
> >> +.. _metadata:
> >> +
> >> +**
> >> +Metadata Interface
> >> +**
> >> +
> >> +Metadata refers to any non-image data that supplements video frames with
> >> +additional information. This may include statistics computed over the 
> >> image
> >> +or frame capture parameters supplied by the image source. This interface 
> >> is
> >> +intended for transfer of metadata to userspace and control of that 
> >> operation.
> >> +
> >> +The metadata interface is implemented on video capture device nodes. The 
> >> device
> >> +can be dedicated to metadata or can implement both video and metadata 
> >> capture
> >> +as specified in its reported capabilities.
> >> +
> >> +.. note::
> >> +
> >> +This is an :ref:`experimental` interface and may
> >> +change in the future.  
> > 
> > While I'm ok with this comment, in practice, this comment is bogus. Once we
> > merge it, it is unlikely that we'll be able to change it.
> > 
> > That would just add a task on our TODO list that we'll need to remove this
> > comment some day.  
> 
> I'll remove this. These notes were all removed some time ago. This patch was 
> most
> likely made when these notes were still in use.
> 
> >   
> >> +
> >> +Querying Capabilities
> >> +=
> >> +
> >> +Device nodes supporting the metadata interface set the 
> >> ``V4L2_CAP_META_CAPTURE``
> >> +flag in the ``device_caps`` field of the
> >> +:c:type:`v4l2_capability` structure returned by the 
> >> :c:func:`VIDIOC_QUERYCAP`
> >> +ioctl. That flag means the device can capture metadata to memory.
> >> +
> >> +At least one of the read/write or streaming I/O methods must be supported.
> >> +
> >> +
> >> +Data Format Negotiation
> >> +===
> >> +
> >> +The metadata device uses the :ref:`format` ioctls to select the capture 
> >> format.
> >> +The metadata buffer content format is bound to that selected format. In 
> >> addition
> >> +to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl 
> >> must be
> >> +supported as well.
> >> +
> >> +To use the :ref:`format` ioctls applications set the ``type`` field of the
> >> +:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use 
> >> the
> >> +:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed 
> >> per
> >> +the desired operation. Both drivers and applications must set the 
> >> remainder of
> >> +the 

[GIT PULL FOR v4.12] ov2640 & soc_camera sensor cleanups

[Hans Verkuil]

These are old patches (2015!) that have been lying around in my todo list
ever since. Since I plan to work a bit on soc-camera sensors (at least
those that I have) and since ov2640 was just moved out of soc-camera, it is
time I kick these out.

Regards,

Hans

The following changes since commit a9b99bbedae6f861de3be635bdc9382e1e29a4f9:

  [media] em28xx: drop last soc_camera link (2017-04-10 14:28:39 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.12g

for you to fetch changes up to 738777dd732e97ac664fe5152660d6e9ce6c033c:

  ov2640: avoid calling ov2640_select_win() twice (2017-04-10 20:02:17 +0200)


Hans Verkuil (8):
  imx074: avoid calling imx074_find_datafmt() twice
  mt9m001: avoid calling mt9m001_find_datafmt() twice
  mt9v022: avoid calling mt9v022_find_datafmt() twice
  ov5642: avoid calling ov5642_find_datafmt() twice
  ov772x: avoid calling ov772x_select_params() twice
  ov9640: avoid calling ov9640_res_roundup() twice
  ov9740: avoid calling ov9740_res_roundup() twice
  ov2640: avoid calling ov2640_select_win() twice

 drivers/media/i2c/ov2640.c | 18 +++---
 drivers/media/i2c/soc_camera/imx074.c  |  2 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  8 
 drivers/media/i2c/soc_camera/mt9v022.c |  8 
 drivers/media/i2c/soc_camera/ov5642.c  |  2 +-
 drivers/media/i2c/soc_camera/ov772x.c  | 41 
+
 drivers/media/i2c/soc_camera/ov9640.c  | 24 +++-
 drivers/media/i2c/soc_camera/ov9740.c  | 18 +-
 8 files changed, 34 insertions(+), 87 deletions(-)

Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors

[Frank Schäfer]

Am 26.03.2017 um 16:24 schrieb Frank Schäfer:
>
>
> Am 24.03.2017 um 20:16 schrieb Mauro Carvalho Chehab:
>> Em Thu, 23 Mar 2017 19:03:20 +0100
>> Frank Schäfer  escreveu:
>>
>>> Am 23.03.2017 um 13:56 schrieb Mauro Carvalho Chehab:
 Em Thu, 23 Mar 2017 13:01:32 +0100
 Frank Schäfer  escreveu:
  
> Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab:
>> Em Sun, 19 Feb 2017 19:29:18 +0100
>> Frank Schäfer  escreveu:
>> 
>>> Use i2c_smbus_read_word_data() instead of i2c_master_send() and
>>> i2c_master_recv() for reading the ID of Micorn sensors.
>>> Bytes need to be swapped afterwards, because
>>> i2c_smbus_read_word_data()
>>> assumes that the received bytes are little-endian byte order (as
>>> specified
>>> by smbus), while Micron sensors with 16 bit register width use
>>> big endian
>>> byte order.
>>>
>>> Signed-off-by: Frank Schäfer 
>>> ---
>>> drivers/media/usb/em28xx/em28xx-camera.c | 28
>>> 
>>> 1 file changed, 4 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/drivers/media/usb/em28xx/em28xx-camera.c
>>> b/drivers/media/usb/em28xx/em28xx-camera.c
>>> index 7b4129ab1cf9..4839479624e7 100644
>>> --- a/drivers/media/usb/em28xx/em28xx-camera.c
>>> +++ b/drivers/media/usb/em28xx/em28xx-camera.c
>>> @@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct
>>> em28xx *dev)
>>> {
>>> int ret, i;
>>> char *name;
>>> -u8 reg;
>>> -__be16 id_be;
>>> u16 id;
>>> struct i2c_client *client =
>>> >i2c_client[dev->def_i2c_bus];
>>> @@ -115,10 +113,8 @@ static int
>>> em28xx_probe_sensor_micron(struct em28xx *dev)
>>> dev->em28xx_sensor = EM28XX_NOSENSOR;
>>> for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END;
>>> i++) {
>>> client->addr = micron_sensor_addrs[i];
>>> -/* NOTE: i2c_smbus_read_word_data() doesn't work with
>>> BE data */
>>> /* Read chip ID from register 0x00 */
>>> -reg = 0x00;
>>> -ret = i2c_master_send(client, , 1);
>>> +ret = i2c_smbus_read_word_data(client, 0x00); /*
>>> assumes LE */
>>> if (ret < 0) {
>>> if (ret != -ENXIO)
>>> dev_err(>intf->dev,
>>> @@ -126,24 +122,9 @@ static int
>>> em28xx_probe_sensor_micron(struct em28xx *dev)
>>>client->addr << 1, ret);
>>> continue;
>>> }
>>> -ret = i2c_master_recv(client, (u8 *)_be, 2);
>>> -if (ret < 0) {
>>> -dev_err(>intf->dev,
>>> -"couldn't read from i2c device 0x%02x: error
>>> %i\n",
>>> -client->addr << 1, ret);
>>> -continue;
>>> -}
>>> -id = be16_to_cpu(id_be);
>>> +id = swab16(ret); /* LE -> BE */
>> That's wrong! You can't assume that CPU is BE, as some archs use LE.
>>
>> You should, instead, call le16_to_cpu(), to be sure that it will be
>> doing the right thing.
>>
>> Something like:
>>
>> id = le16_to_cpu((__le16)ret);
> SMBus read/write word transfers are always LE (see SMBus spec section
> 6.5.5),
> which is also what i2c_smbus_xfer_emulated() assumes:
> http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485
 I got that part, but, if the CPU is also LE, doing swab16() is
 wrong. It should swap it *only* if the CPU is BE.
>>> No, it should always be swapped, because the bytes are always
>>> transfered
>>> in the wrong order.
>>> The cpu endianess doesn't matter, (0x12 << 8) | 0x34 is always 0x1234.
>> You still didn't get it.
>>
>> Let's assume that the ID is 0x148c (MT9M112).
>>
>> This value, represented in low endian, is stored in memory as:
>>
>> unsigned char __id[2] = { 0x8c, 0x14 };
>>
>> If we do:
>> u16 ret = *(u16 *)__id;
>>
>> What's stored at "ret" will depend if the sistem is LE or BE:
>>
>> on LE, ret == 0x148c
>> on BE, ret == 0x8c14
>>
>> If you do:
>> u16 id = swapb16(val)
>>
>> you'll get:
>>
>> on LE, id == 0x8c14
>> on BE, id == 0x148c
>>
>> So, the value will be *wrong* at LE.
>>
>> However, if you do:
>> id = le16_to_cpu((__le16)ret);
>>
>> On LE, this will evaluate to id = ret, and on BE, to id = swab16(ret).
>> So, on both, you'll have:
>> id = 0x148c.
>
> Can you please show me the code line(s) that make the value of the
> word returned by i2c_smbus_read_word_data() cpu endianess dependent ? :)
>
Ping !?

Cheers,
Frank

Re: [PATCH] Quirk for webcam in MacBook Pro 2016

[Daniel Roschka]

Hi Laurent,

I'm really sorry for all the wrong formatting. I already took measures so it 
won't happen again.

> Your patch is now in my git tree, and I will push it upstream for v4.13
> (v4.11 will be released very soon, and given the pending pull requests for
> v4.12 in the Linux media tree I don't think I can add another one).

Thanks a lot. Highly appreciated.

> I collect USB descriptors for UVC devices. Could you please send me the
> output of
> 
> lsusb -d 05ac:8600

I guess you want the verbose output of lsusb. You'll find it in the attached 
file. It might contain more than than you expect as the iBridge device is a 
custom ARM processor (probably very similar to the one in the Apple Watch), 
not just connecting the webcam to the rest of the system, but also the Touch 
Bar and the Touch ID sensor.

Regards,
DanielBus 001 Device 002: ID 05ac:8600 Apple, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x05ac Apple, Inc.
  idProduct  0x8600 
  bcdDevice1.01
  iManufacturer   1 Apple Inc.
  iProduct2 iBridge
  iSerial 3 nomac?123456
  bNumConfigurations  3
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  469
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  5 Default iBridge Interfaces
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass 14 Video
  bFunctionSubClass   1 Video Control
  bFunctionProtocol   0 
  iFunction   6 FaceTime HD Camera (Build-in)
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass14 Video
  bInterfaceSubClass  1 Video Control
  bInterfaceProtocol  0 
  iInterface 15 FaceTime HD Camera (Build-in, 
SN:CC264856L1KGJJM11)
  VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdUVC   1.50
wTotalLength   54
dwClockFrequency1.00MHz
bInCollection   1
baInterfaceNr( 0)   1
  VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0201 Camera Sensor
bAssocTerminal  0
iTerminal   0 
wObjectiveFocalLengthMin  0
wObjectiveFocalLengthMax  0
wOcularFocalLength0
bControlSize  3
bmControls   0x
  VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bSourceID   1
iTerminal   0 
  VideoControl Interface Descriptor:
bLength14
bDescriptorType36
bDescriptorSubtype  5 (PROCESSING_UNIT)
bUnitID 3
bSourceID   1
wMaxMultiplier  0
bControlSize4
bmControls 0x
iProcessing 0 
bmVideoStandards 0x 0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass14 Video
  bInterfaceSubClass  2 Video Streaming
  bInterfaceProtocol  0 
  iInterface  0 
  VideoStreaming Interface Descriptor:
bLength14
bDescriptorType36
bDescriptorSubtype  1 (INPUT_HEADER)
bNumFormats 1
wTotalLength  323
bEndPointAddress  129
bmInfo  0
bTerminalLink   2
bStillCaptureMethod 0
bTriggerSupport 0
bTriggerUsage   0
bControlSize1
bmaControls( 

Re: [PATCH v3 1/8] v4l: Add metadata buffer type and format

[Hans Verkuil]

On 04/10/2017 07:23 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Feb 2017 17:56:41 +0200
> Laurent Pinchart  escreveu:
> 
>> The metadata buffer type is used to transfer metadata between userspace
>> and kernelspace through a V4L2 buffers queue. It comes with a new
>> metadata capture capability and format description.
>>
>> Signed-off-by: Laurent Pinchart 
>> Tested-by: Guennadi Liakhovetski 
>> Acked-by: Sakari Ailus 
>> Acked-by: Hans Verkuil 
>> ---
>>  Documentation/media/uapi/v4l/buffer.rst  |  3 ++
>>  Documentation/media/uapi/v4l/dev-meta.rst| 62 
>> 
>>  Documentation/media/uapi/v4l/devices.rst |  1 +
>>  Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 ++
>>  Documentation/media/videodev2.h.rst.exceptions   |  2 +
>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 
>>  drivers/media/v4l2-core/v4l2-dev.c   | 16 +++---
>>  drivers/media/v4l2-core/v4l2-ioctl.c | 34 +
>>  drivers/media/v4l2-core/videobuf2-v4l2.c |  3 ++
>>  include/media/v4l2-ioctl.h   | 17 +++
>>  include/trace/events/v4l2.h  |  1 +
>>  include/uapi/linux/videodev2.h   | 13 +
>>  12 files changed, 168 insertions(+), 6 deletions(-)
>>  create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst
>>
>> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
>> b/Documentation/media/uapi/v4l/buffer.rst
>> index 5c58db98ab7a..02834ce7fa4d 100644
>> --- a/Documentation/media/uapi/v4l/buffer.rst
>> +++ b/Documentation/media/uapi/v4l/buffer.rst
>> @@ -418,6 +418,9 @@ enum v4l2_buf_type
>>- 12
>>- Buffer for Software Defined Radio (SDR) output stream, see
>>  :ref:`sdr`.
>> +* - ``V4L2_BUF_TYPE_META_CAPTURE``
>> +  - 13
>> +  - Buffer for metadata capture, see :ref:`metadata`.
>>  
>>  
>>  
>> diff --git a/Documentation/media/uapi/v4l/dev-meta.rst 
>> b/Documentation/media/uapi/v4l/dev-meta.rst
>> new file mode 100644
>> index ..b6044c54082a
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/dev-meta.rst
>> @@ -0,0 +1,62 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _metadata:
>> +
>> +**
>> +Metadata Interface
>> +**
>> +
>> +Metadata refers to any non-image data that supplements video frames with
>> +additional information. This may include statistics computed over the image
>> +or frame capture parameters supplied by the image source. This interface is
>> +intended for transfer of metadata to userspace and control of that 
>> operation.
>> +
>> +The metadata interface is implemented on video capture device nodes. The 
>> device
>> +can be dedicated to metadata or can implement both video and metadata 
>> capture
>> +as specified in its reported capabilities.
>> +
>> +.. note::
>> +
>> +This is an :ref:`experimental` interface and may
>> +change in the future.
> 
> While I'm ok with this comment, in practice, this comment is bogus. Once we
> merge it, it is unlikely that we'll be able to change it.
> 
> That would just add a task on our TODO list that we'll need to remove this
> comment some day.

I'll remove this. These notes were all removed some time ago. This patch was 
most
likely made when these notes were still in use.

> 
>> +
>> +Querying Capabilities
>> +=
>> +
>> +Device nodes supporting the metadata interface set the 
>> ``V4L2_CAP_META_CAPTURE``
>> +flag in the ``device_caps`` field of the
>> +:c:type:`v4l2_capability` structure returned by the 
>> :c:func:`VIDIOC_QUERYCAP`
>> +ioctl. That flag means the device can capture metadata to memory.
>> +
>> +At least one of the read/write or streaming I/O methods must be supported.
>> +
>> +
>> +Data Format Negotiation
>> +===
>> +
>> +The metadata device uses the :ref:`format` ioctls to select the capture 
>> format.
>> +The metadata buffer content format is bound to that selected format. In 
>> addition
>> +to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl must 
>> be
>> +supported as well.
>> +
>> +To use the :ref:`format` ioctls applications set the ``type`` field of the
>> +:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use 
>> the
>> +:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed 
>> per
>> +the desired operation. Both drivers and applications must set the remainder 
>> of
>> +the :c:type:`v4l2_format` structure to 0.
>> +
>> +.. _v4l2-meta-format:
> 
> Better to add an space after the label. My experience with random versions
> of Sphinx is that it doesn't like to have different types of paragraph
> without at least one blank line between them.

You mean 'Better to add a newline after the label'? It's a bit confusing.

Regards,

Re: [PATCH v3 1/8] v4l: Add metadata buffer type and format

[Mauro Carvalho Chehab]

Em Tue, 28 Feb 2017 17:56:41 +0200
Laurent Pinchart  escreveu:

> The metadata buffer type is used to transfer metadata between userspace
> and kernelspace through a V4L2 buffers queue. It comes with a new
> metadata capture capability and format description.
> 
> Signed-off-by: Laurent Pinchart 
> Tested-by: Guennadi Liakhovetski 
> Acked-by: Sakari Ailus 
> Acked-by: Hans Verkuil 
> ---
>  Documentation/media/uapi/v4l/buffer.rst  |  3 ++
>  Documentation/media/uapi/v4l/dev-meta.rst| 62 
> 
>  Documentation/media/uapi/v4l/devices.rst |  1 +
>  Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 ++
>  Documentation/media/videodev2.h.rst.exceptions   |  2 +
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 
>  drivers/media/v4l2-core/v4l2-dev.c   | 16 +++---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 34 +
>  drivers/media/v4l2-core/videobuf2-v4l2.c |  3 ++
>  include/media/v4l2-ioctl.h   | 17 +++
>  include/trace/events/v4l2.h  |  1 +
>  include/uapi/linux/videodev2.h   | 13 +
>  12 files changed, 168 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index 5c58db98ab7a..02834ce7fa4d 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -418,6 +418,9 @@ enum v4l2_buf_type
>- 12
>- Buffer for Software Defined Radio (SDR) output stream, see
>   :ref:`sdr`.
> +* - ``V4L2_BUF_TYPE_META_CAPTURE``
> +  - 13
> +  - Buffer for metadata capture, see :ref:`metadata`.
>  
>  
>  
> diff --git a/Documentation/media/uapi/v4l/dev-meta.rst 
> b/Documentation/media/uapi/v4l/dev-meta.rst
> new file mode 100644
> index ..b6044c54082a
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/dev-meta.rst
> @@ -0,0 +1,62 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _metadata:
> +
> +**
> +Metadata Interface
> +**
> +
> +Metadata refers to any non-image data that supplements video frames with
> +additional information. This may include statistics computed over the image
> +or frame capture parameters supplied by the image source. This interface is
> +intended for transfer of metadata to userspace and control of that operation.
> +
> +The metadata interface is implemented on video capture device nodes. The 
> device
> +can be dedicated to metadata or can implement both video and metadata capture
> +as specified in its reported capabilities.
> +
> +.. note::
> +
> +This is an :ref:`experimental` interface and may
> +change in the future.

While I'm ok with this comment, in practice, this comment is bogus. Once we
merge it, it is unlikely that we'll be able to change it.

That would just add a task on our TODO list that we'll need to remove this
comment some day.

> +
> +Querying Capabilities
> +=
> +
> +Device nodes supporting the metadata interface set the 
> ``V4L2_CAP_META_CAPTURE``
> +flag in the ``device_caps`` field of the
> +:c:type:`v4l2_capability` structure returned by the :c:func:`VIDIOC_QUERYCAP`
> +ioctl. That flag means the device can capture metadata to memory.
> +
> +At least one of the read/write or streaming I/O methods must be supported.
> +
> +
> +Data Format Negotiation
> +===
> +
> +The metadata device uses the :ref:`format` ioctls to select the capture 
> format.
> +The metadata buffer content format is bound to that selected format. In 
> addition
> +to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl must 
> be
> +supported as well.
> +
> +To use the :ref:`format` ioctls applications set the ``type`` field of the
> +:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use the
> +:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed per
> +the desired operation. Both drivers and applications must set the remainder 
> of
> +the :c:type:`v4l2_format` structure to 0.
> +
> +.. _v4l2-meta-format:

Better to add an space after the label. My experience with random versions
of Sphinx is that it doesn't like to have different types of paragraph
without at least one blank line between them.

> +.. flat-table:: struct v4l2_meta_format
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - __u32
> +  - ``dataformat``
> +  - The data format, set by the application. This is a little endian
> +:ref:`four character code `. V4L2 defines metadata 
> formats
> +in :ref:`meta-formats`.
> +* - __u32
> +  - ``buffersize``
> +  - Maximum 

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Laura Abbott]

On 04/10/2017 09:25 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote:
>> On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
>>> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
 Hi,

 This is v3 of the series to do some serious Ion cleanup in preparation for
 moving out of staging. I didn't hear much on v2 so I'm going to assume
 people are okay with the series as is. I know there were still some open
 questions about moving away from /dev/ion but in the interest of small
 steps I'd like to go ahead and merge this series assuming there are no more
 major objections. More work can happen on top of this.
>>>
>>> I've applied patches 3-11 as those were independant of the CMA changes.
>>> I'd like to take the rest, including the CMA changes, but I need an ack
>>> from someone dealing with the -mm tree before I can do that.
>>>
>>> Or, if they just keep ignoring it, I guess I can take them :)
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
>> any, I'll resend the rest of the series after the 4.12 merge window.
> 
> Why so long?  This series has been sent a bunch, if no one responds in a
> week, I'll be glad to take them all in my tree :)
> 
> thanks,
> 
> greg k-h
> 

Ideally I'd like some confirmation that at least someone other than
myself thinks it's a good idea but I know mm review bandwidth has
been a topic of discussion so maybe silence is the best I can get.
If you pick it up and nobody objects, I guess I won't object either :)

Thanks,
Laura

[GIT PULL 4.12] si2157: Si2141 tuner support

[Antti Palosaari]

That patch set replaces existing si2146 support with new one, that looks 
more correct for my eyes.


Antti

The following changes since commit 7ca0ef3da09888b303991edb80cd0283ee641c9e:

  Merge tag 'v4.11-rc5' into patchwork (2017-04-04 11:11:43 -0300)

are available in the git repository at:

  git://linuxtv.org/anttip/media_tree.git si2168

for you to fetch changes up to c9110a61811b9349ac64c3e50fd927c580e2eacd:

  si2157: Add support for Si2141-A10 (2017-04-06 16:48:52 +0300)


Antti Palosaari (1):
  si2157: revert si2157: Si2141/2151 tuner support

Stefan Brüns (1):
  si2157: Add support for Si2141-A10

 drivers/media/tuners/si2157.c | 85 
+++--

 1 file changed, 23 insertions(+), 62 deletions(-)

--
http://palosaari.fi/

[RFC PATCH] Document new V4L2_CTRL_FLAG_MODIFY_LAYOUT flag

[Hans Verkuil]

This RFC patch adds documentation for the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag and
how this and the GRABBED flag should be used.

When approved I'll post a proper patch series introducing this flag.

This patch sits on top of Laurent's vsp1/next branch.

Also available here:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=vsp1

Regards,

Hans

Signed-off-by: Hans Verkuil 
---
diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index 64613d935edd..ae6ee73f151c 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -48,10 +48,16 @@ The set of information needed to interpret the content of a 
buffer (e.g. the
 pixel format, the line stride, the tiling orientation or the rotation) is
 collectively referred to in the rest of this section as the buffer layout.

+Controls that can modify the buffer layout shall set the
+``V4L2_CTRL_FLAG_MODIFY_LAYOUT`` flag.
+
 Modifying formats or controls that influence the buffer size or layout require
 the stream to be stopped. Any attempt at such a modification while the stream
 is active shall cause the ioctl setting the format or the control to return
-the ``EBUSY`` error code.
+the ``EBUSY`` error code. In that case drivers shall also set the
+``V4L2_CTRL_FLAG_GRABBED`` flag when calling
+:c:func:`VIDIOC_QUERYCTRL` or :c:func:`VIDIOC_QUERY_EXT_CTRL` for such a
+control while the stream is active.

 .. note::

@@ -67,7 +73,8 @@ the ``EBUSY`` error code.
 Controls that only influence the buffer layout can be modified at any time
 when the stream is stopped. As they don't influence the buffer size, no
 special handling is needed to synchronize those controls with buffer
-allocation.
+allocation and the ``V4L2_CTRL_FLAG_GRABBED`` flag is cleared once the
+stream is stopped.

 Formats and controls that influence the buffer size interact with buffer
 allocation. The simplest way to handle this is for drivers to always require
@@ -75,8 +82,10 @@ buffers to be reallocated in order to change those formats 
or controls. In
 that case, to perform such changes, userspace applications shall first stop
 the video stream with the :c:func:`VIDIOC_STREAMOFF` ioctl if it is running
 and free all buffers with the :c:func:`VIDIOC_REQBUFS` ioctl if they are
-allocated. The format or controls can then be modified, and buffers shall then
-be reallocated and the stream restarted. A typical ioctl sequence is
+allocated. After freeing all buffers the ``V4L2_CTRL_FLAG_GRABBED`` flag
+for controls is cleared. The format or controls can then be modified, and
+buffers shall then be reallocated and the stream restarted. A typical ioctl
+sequence is

  #. VIDIOC_STREAMOFF
  #. VIDIOC_REQBUFS(0)
diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst 
b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
index 82769de801b1..1ffdc3f3c614 100644
--- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
+++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
@@ -507,6 +507,19 @@ See also the examples in :ref:`control`.
represents an action on the hardware. For example: clearing an
error flag or triggering the flash. All the controls of the type
``V4L2_CTRL_TYPE_BUTTON`` have this flag set.
+* .. _FLAG_MODIFY_LAYOUT:
+
+  - ``V4L2_CTRL_FLAG_MODIFY_LAYOUT``
+  - 0x0400
+  - Changing this control value may modify the layout of the
+buffer (for video devices) or the media bus format (for sub-devices).
+
+   A typical example would be the ``V4L2_CID_ROTATE`` control.
+
+   Note that typically controls with this flag will also set the
+   ``V4L2_CTRL_FLAG_GRABBED`` flag when buffers are allocated or
+   streaming is in progress since most drivers do not support changing
+   the format in that case.


 Return Value
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index c9c611b18ba1..a5cb0a8686ac 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -341,6 +341,7 @@ replace define V4L2_CTRL_FLAG_WRITE_ONLY control-flags
 replace define V4L2_CTRL_FLAG_VOLATILE control-flags
 replace define V4L2_CTRL_FLAG_HAS_PAYLOAD control-flags
 replace define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE control-flags
+replace define V4L2_CTRL_FLAG_MODIFY_LAYOUT control-flags

 replace define V4L2_CTRL_FLAG_NEXT_CTRL control
 replace define V4L2_CTRL_FLAG_NEXT_COMPOUND control

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote:
> On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
> > On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
> >> Hi,
> >>
> >> This is v3 of the series to do some serious Ion cleanup in preparation for
> >> moving out of staging. I didn't hear much on v2 so I'm going to assume
> >> people are okay with the series as is. I know there were still some open
> >> questions about moving away from /dev/ion but in the interest of small
> >> steps I'd like to go ahead and merge this series assuming there are no more
> >> major objections. More work can happen on top of this.
> > 
> > I've applied patches 3-11 as those were independant of the CMA changes.
> > I'd like to take the rest, including the CMA changes, but I need an ack
> > from someone dealing with the -mm tree before I can do that.
> > 
> > Or, if they just keep ignoring it, I guess I can take them :)
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
> any, I'll resend the rest of the series after the 4.12 merge window.

Why so long?  This series has been sent a bunch, if no one responds in a
week, I'll be glad to take them all in my tree :)

thanks,

greg k-h

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Laura Abbott]

On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
>> Hi,
>>
>> This is v3 of the series to do some serious Ion cleanup in preparation for
>> moving out of staging. I didn't hear much on v2 so I'm going to assume
>> people are okay with the series as is. I know there were still some open
>> questions about moving away from /dev/ion but in the interest of small
>> steps I'd like to go ahead and merge this series assuming there are no more
>> major objections. More work can happen on top of this.
> 
> I've applied patches 3-11 as those were independant of the CMA changes.
> I'd like to take the rest, including the CMA changes, but I need an ack
> from someone dealing with the -mm tree before I can do that.
> 
> Or, if they just keep ignoring it, I guess I can take them :)
> 
> thanks,
> 
> greg k-h
> 

Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
any, I'll resend the rest of the series after the 4.12 merge window.

Thanks,
Laura

Re: [PATCH v3 1/8] dt-bindings: Document STM32 DCMI bindings

[Rob Herring]

On Tue, Apr 04, 2017 at 05:44:31PM +0200, Hugues Fruchet wrote:
> This adds documentation of device tree bindings for the STM32 DCMI
> (Digital Camera Memory Interface).
> 
> Signed-off-by: Hugues Fruchet 
> ---
>  .../devicetree/bindings/media/st,stm32-dcmi.txt| 46 
> ++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt

One nit below, otherwise:

Acked-by: Rob Herring 

> 
> diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt 
> b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
> new file mode 100644
> index 000..c0f6f4b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
> @@ -0,0 +1,46 @@
> +STMicroelectronics STM32 Digital Camera Memory Interface (DCMI)
> +
> +Required properties:
> +- compatible: "st,stm32-dcmi"
> +- reg: physical base address and length of the registers set for the device
> +- interrupts: should contain IRQ line for the DCMI
> +- resets: reference to a reset controller,
> +  see Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
> +- clocks: list of clock specifiers, corresponding to entries in
> +  the clock-names property
> +- clock-names: must contain "mclk", which is the DCMI peripherial clock
> +- pinctrl: the pincontrol settings to configure muxing properly
> +   for pins that connect to DCMI device.
> +   See 
> Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt.
> +- dmas: phandle to DMA controller node,
> +see Documentation/devicetree/bindings/dma/stm32-dma.txt
> +- dma-names: must contain "tx", which is the transmit channel from DCMI to 
> DMA
> +
> +DCMI supports a single port node with parallel bus. It should contain one
> +'port' child node with child 'endpoint' node. Please refer to the bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> + dcmi: dcmi@5005 {
> + compatible = "st,stm32-dcmi";
> + reg = <0x5005 0x400>;
> + interrupts = <78>;
> + resets = < STM32F4_AHB2_RESET(DCMI)>;
> + clocks = < 0 STM32F4_AHB2_CLOCK(DCMI)>;
> + clock-names = "mclk";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + dmas = < 1 1 0x414 0x3>;
> + dma-names = "tx";
> + port {
> + dcmi_0: endpoint@0 {

Unit address in not valid without a reg prop, so drop it.

> + remote-endpoint = <...>;
> + bus-width = <8>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + pclk-sample = <1>;
> + };
> + };
> + };
> +
> -- 
> 1.9.1
> 

Re: [PATCHv3 17/22] staging: android: ion: Collapse internal header files

[Laura Abbott]

On 04/08/2017 11:12 AM, Emil Velikov wrote:
> Hi Laura,
> 
> Couple of trivial nitpicks below.
> 
> On 3 April 2017 at 19:57, Laura Abbott  wrote:
> 
>> --- a/drivers/staging/android/ion/ion.h
>> +++ b/drivers/staging/android/ion/ion.h
>> @@ -1,5 +1,5 @@
>>  /*
>> - * drivers/staging/android/ion/ion.h
>> + * drivers/staging/android/ion/ion_priv.h
> Does not match the actual filename.
> 
>>   *
>>   * Copyright (C) 2011 Google, Inc.
>>   *
>> @@ -14,24 +14,26 @@
>>   *
>>   */
>>
>> -#ifndef _LINUX_ION_H
>> -#define _LINUX_ION_H
>> +#ifndef _ION_PRIV_H
>> +#define _ION_PRIV_H
>>
> Ditto.
> 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>  #include 
>> +#include 
>>
>>  #include "../uapi/ion.h"
>>
> You don't want to use "../" in includes. Perhaps address with another
> patch, if you haven't already ?
> 

There isn't a better option until this driver moves out of staging.
Once it moves out it can be fixed up.

Thanks,
Laura

> Regards,
> Emil
> 

Re: [PATCH v8 1/2] media: i2c/ov5645: add the device tree binding document

[Rob Herring]

On Mon, Apr 03, 2017 at 05:02:28PM +0300, Todor Tomov wrote:
> Add the document for ov5645 device tree binding.
> 
> Signed-off-by: Todor Tomov 
> Reviewed-by: Laurent Pinchart 
> ---
>  .../devicetree/bindings/media/i2c/ov5645.txt   | 54 
> ++
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt

Acked-by: Rob Herring 

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Shuah Khan]

On 04/05/2017 05:14 PM, Russell King - ARM Linux wrote:
> On Wed, Apr 05, 2017 at 10:02:42AM -0600, Shuah Khan wrote:
>> When coherent DMA memory without struct page is shared, importer
>> fails to find the page and runs into kernel page fault when it
>> tries to dmabuf_ops_attach/map_sg/map_page the invalid page found
>> in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html
>> for more information on this problem.
>>
>> This solution allows coherent DMA memory without struct page to be
>> shared by providing a way for the exporter to tag the DMA buffer as
>> a special buffer without struct page association and passing the
>> information in sg_table to the importer. This information is used
>> in attach/map_sg to avoid cleaning D-cache and mapping.
>>
>> The details of the change are:
>>
>> Framework:
>> - Add a new dma_attrs field to struct scatterlist.
>> - Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify
>>   Coherent memory without struct page.
>> - Add a new dma_check_dev_coherent() interface to check if memory is
>>   the device coherent area. There is no way to tell where the memory
>>   returned by dma_alloc_attrs() came from.
>>
>> Exporter logic:
>> - Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set
>>   DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is
>>   done in the exporter context.
>> - Add logic to arm_dma_get_sgtable() to identify memory without struct
>>   page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is
>>   set, arm_dma_get_sgtable() will set page as the cpu_addr and update
>>   dma_address and dma_attrs fields in struct scatterlist for this sgl.
>>   This is done in exporter context when buffer is exported. With this
> 
> This sentence appears to just end...
> 
> I'm not convinced that coherent allocations should be setting the "page"
> of a scatterlist to anything that isn't a real struct page or NULL.  It
> is, after all, an error to look up the virtual address etc of the
> scatterlist entry or kmap it when it isn't backed by a struct page.
> 
> I'm actually already passing non-page backed memory through the DMA API
> in armada-drm, although not entirely correctly, and etnaviv handles it
> fine:
> 
> } else if (dobj->linear) {
> /* Single contiguous physical region - no struct page */
> if (sg_alloc_table(sgt, 1, GFP_KERNEL))
> goto free_sgt;
> sg_dma_address(sgt->sgl) = dobj->dev_addr;
> sg_dma_len(sgt->sgl) = dobj->obj.size;
> 
> This is not quite correct, as it assumes (which is safe for it currently)
> that the DMA address is the same on all devices.  On Dove, which is where
> this is used, that is the case, but it's not true elsewhere.  Also note
> that I'm avoid calling dma_map_sg() and dma_unmap_sg() - there's no iommus
> to be considered.

I see. That is not the case for the drivers involved in my use-case. exynos
has iommu and this s5p-mfc exporting buffers to exynos-gsc use-case does
work when iommu is enabled.

> 
> I'd suggest that this follows the same pattern - setting the DMA address
> (more appropriately for generic code) and the DMA length, while leaving
> the virtual address members NULL/0.  However, there's also the
> complication of setting up any IOMMUs that would be necessary.  I haven't
> looked at that, or how it could work.
> 
> I also think this should be documented in the dmabuf API that it can
> pass such scatterlists that are DMA-parameter only.
> 
> Lastly, I'd recommend that anything using this does _not_ provide
> functional kmap/kmap_atomic support for these - kmap and kmap_atomic
> are both out because there's no struct page anyway (and their use would
> probably oops the kernel in this scenario.)  I avoided mmap support in
> armada drm, but if there's a pressing reason and real use case for the
> importer to mmap() the buffers in userspace, it's something I could be
> convinced of.
> 
> What I'm quite certain of is that we do _not_ want to be passing
> coherent memory allocations into the streaming DMA API, not even with
> a special attribute.  The DMA API is about gaining coherent memory
> (shared ownership of the buffer), or mapping system memory to a
> specified device (which can imply unique ownership.)  Trying to mix
> the two together muddies the separation that we have there, and makes
> it harder to explain.  As can be seen from this patch, we'd end up
> needing to add this special DMA_ATTR_DEV_COHERENT_NOPAGE everywhere,
> which is added complexity on top of stuff that is not required for
> this circumstance.

The ownership can be tricky as you mentioned. In this particular use-case,
there is a clear ownership definition because of the way v4l2 export/import
works and also the qbuf/dqbuf rules. However, there might be other use-cases
ownership isn't clearly established.

> 
> I can see why you're doing it, to avoid having to duplicate more of
> the 

[PATCH v3 2/7] v4l: async: Add fwnode match support

[Sakari Ailus]

Add fwnode matching to complement OF node matching. And fwnode may also be
an OF node.

Do not enable fwnode matching yet. It will replace OF matching soon.

Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/v4l2-async.c | 15 +++
 include/media/v4l2-async.h   |  5 +
 include/media/v4l2-subdev.h  |  3 +++
 3 files changed, 23 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 96cc733..ff32f95 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -46,6 +47,16 @@ static bool match_of(struct v4l2_subdev *sd, struct 
v4l2_async_subdev *asd)
of_node_full_name(asd->match.of.node));
 }
 
+static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
+{
+   if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
+   return sd->fwnode == asd->match.fwnode.fwnode;
+
+   return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
+   of_node_full_name(
+   to_of_node(asd->match.fwnode.fwnode)));
+}
+
 static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
 {
if (!asd->match.custom.match)
@@ -80,6 +91,9 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct 
v4l2_async_notifier *
case V4L2_ASYNC_MATCH_OF:
match = match_of;
break;
+   case V4L2_ASYNC_MATCH_FWNODE:
+   match = match_fwnode;
+   break;
default:
/* Cannot happen, unless someone breaks us */
WARN_ON(true);
@@ -158,6 +172,7 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
case V4L2_ASYNC_MATCH_DEVNAME:
case V4L2_ASYNC_MATCH_I2C:
case V4L2_ASYNC_MATCH_OF:
+   case V4L2_ASYNC_MATCH_FWNODE:
break;
default:
dev_err(notifier->v4l2_dev ? notifier->v4l2_dev->dev : 
NULL,
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index 8e2a236..c3695fa 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -32,6 +32,7 @@ struct v4l2_async_notifier;
  * @V4L2_ASYNC_MATCH_DEVNAME: Match will use the device name
  * @V4L2_ASYNC_MATCH_I2C: Match will check for I2C adapter ID and address
  * @V4L2_ASYNC_MATCH_OF: Match will use OF node
+ * @V4L2_ASYNC_MATCH_FWNODE: Match will use firmware node
  *
  * This enum is used by the asyncrhronous sub-device logic to define the
  * algorithm that will be used to match an asynchronous device.
@@ -41,6 +42,7 @@ enum v4l2_async_match_type {
V4L2_ASYNC_MATCH_DEVNAME,
V4L2_ASYNC_MATCH_I2C,
V4L2_ASYNC_MATCH_OF,
+   V4L2_ASYNC_MATCH_FWNODE,
 };
 
 /**
@@ -58,6 +60,9 @@ struct v4l2_async_subdev {
const struct device_node *node;
} of;
struct {
+   struct fwnode_handle *fwnode;
+   } fwnode;
+   struct {
const char *name;
} device_name;
struct {
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 0ab1c5d..5f1669c 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -788,6 +788,8 @@ struct v4l2_subdev_platform_data {
  * @devnode: subdev device node
  * @dev: pointer to the physical device, if any
  * @of_node: The device_node of the subdev, usually the same as dev->of_node.
+ * @fwnode: The fwnode_handle of the subdev, usually the same as
+ * either dev->of_node->fwnode or dev->fwnode (whichever is non-NULL).
  * @async_list: Links this subdev to a global subdev_list or @notifier->done
  * list.
  * @asd: Pointer to respective  v4l2_async_subdev.
@@ -819,6 +821,7 @@ struct v4l2_subdev {
struct video_device *devnode;
struct device *dev;
struct device_node *of_node;
+   struct fwnode_handle *fwnode;
struct list_head async_list;
struct v4l2_async_subdev *asd;
struct v4l2_async_notifier *notifier;
-- 
2.7.4

[PATCH v3 6/7] docs-rst: media: Switch documentation to V4L2 fwnode API

[Sakari Ailus]

Instead of including the V4L2 OF header in ReST documentation, use the
V4L2 fwnode header instead.

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
---
 Documentation/media/kapi/v4l2-core.rst   | 2 +-
 Documentation/media/kapi/v4l2-fwnode.rst | 3 +++
 Documentation/media/kapi/v4l2-of.rst | 3 ---
 3 files changed, 4 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/media/kapi/v4l2-fwnode.rst
 delete mode 100644 Documentation/media/kapi/v4l2-of.rst

diff --git a/Documentation/media/kapi/v4l2-core.rst 
b/Documentation/media/kapi/v4l2-core.rst
index 2fbf532..11c3eca 100644
--- a/Documentation/media/kapi/v4l2-core.rst
+++ b/Documentation/media/kapi/v4l2-core.rst
@@ -13,11 +13,11 @@ Video4Linux devices
 v4l2-event
 v4l2-fh
 v4l2-flash-led-class
+v4l2-fwnode
 v4l2-intro
 v4l2-mc
 v4l2-mediabus
 v4l2-mem2mem
-v4l2-of
 v4l2-rect
 v4l2-subdev
 v4l2-tuner
diff --git a/Documentation/media/kapi/v4l2-fwnode.rst 
b/Documentation/media/kapi/v4l2-fwnode.rst
new file mode 100644
index 000..6c8bccd
--- /dev/null
+++ b/Documentation/media/kapi/v4l2-fwnode.rst
@@ -0,0 +1,3 @@
+V4L2 fwnode kAPI
+
+.. kernel-doc:: include/media/v4l2-fwnode.h
diff --git a/Documentation/media/kapi/v4l2-of.rst 
b/Documentation/media/kapi/v4l2-of.rst
deleted file mode 100644
index 1ddf76b..000
--- a/Documentation/media/kapi/v4l2-of.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-V4L2 Open Firmware kAPI
-^^^
-.. kernel-doc:: include/media/v4l2-of.h
-- 
2.7.4

[PATCH v3 0/7] V4L2 fwnode support

[Sakari Ailus]

Hello everyone,

This patchset adds support for fwnode to V4L2. Besides OF, also ACPI based
systems can be supported this way. By using V4L2 fwnode, the individual
drivers do not need to be aware of the underlying firmware implementation.
The patchset also removes specific V4L2 OF support and converts the
affected drivers to use V4L2 fwnode.

The patchset depends on another patchset here:

 

A git tree with the dependencies can be found here:



v1 of the set can be found here:

 

and v2 here:



changes since v2:

- Use EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL().

- Alphabetically order the topics under V4L2 core kAPI documentation.

- Prefer "fwnode" variable name for struct fwnode_handle pointers instead
  of "fwn". Similarly, use "vep" for struct v4l2_fwnode_endpoint instead
  of "vfwn".

- Convert existing users of OF matching to fwnode matching.

- Remove OF matching support as well as compatibility between OF and
  fwnode matching.

- Use of_node_cmp() to determine whether two nodes match in case both of
  them are OF nodes. There is thus no functional difference between
  existing OF matching in v1.

- Continue to use struct device_node.full_name on fwnodes that are known
  to be OF nodes instead of omitting such debug information. Drivers that
  can actually use fwnode need a new interface to provide this in fwnode
  framework. This is out of scope of the patchset.

- Remove linux/of.h header inclusion in
  drivers/media/v4l2-core/v4l2-flash-led-class.c.

- Improved line wrapping primarily in
  drivers/media/v4l2-core/v4l2-fwnode.c.

- Rewrap KernelDoc documentation for V4L2 fwnode API up to 80 characters
  per line (new patch).

- Fix KernelDoc documentation, there were a few locations where the
  argument had been changed but the documentation was not updated
  accordingly. 

- Fix punctuation and wording in V4L2 fwnode documentation.

- Drop patch "v4l: media/drv-intf/soc_mediabus.h: include dependent header
  file". It is no longer needed.

- Fix obtaining port parent in v4l2_fwnode_parse_link() on ACPI.

- Include newly OF-supported atmel-isi to V4L2 OF -> fwnode conversion.

- Add that the v4l2-fwnode.c has origins in v4l2-of.c to the commit
  message and the file header.

changes since v1:

- Use existing dev_fwnode() instead of device_fwnode_handle() added by the
  ACPI graph patchset,

- Fix too long line of ^'s in ReST documentation and

- Drop the patch rearranging the header files. It'd better go in
  separately, if at all.

Sakari Ailus (7):
  v4l: fwnode: Support generic fwnode for parsing standardised
properties
  v4l: async: Add fwnode match support
  v4l: flash led class: Use fwnode_handle instead of device_node in init
  v4l: Switch from V4L2 OF not V4L2 fwnode API
  docs-rst: media: Sort topic list alphabetically
  docs-rst: media: Switch documentation to V4L2 fwnode API
  v4l: Remove V4L2 OF framework in favour of V4L2 fwnode framework

 Documentation/media/kapi/v4l2-core.rst |  20 +-
 Documentation/media/kapi/v4l2-fwnode.rst   |   3 +
 Documentation/media/kapi/v4l2-of.rst   |   3 -
 drivers/leds/leds-aat1290.c|   5 +-
 drivers/leds/leds-max77693.c   |   5 +-
 drivers/media/i2c/Kconfig  |   9 +
 drivers/media/i2c/adv7604.c|   7 +-
 drivers/media/i2c/mt9v032.c|   7 +-
 drivers/media/i2c/ov2659.c |   8 +-
 drivers/media/i2c/s5c73m3/s5c73m3-core.c   |   7 +-
 drivers/media/i2c/s5k5baf.c|   6 +-
 drivers/media/i2c/smiapp/Kconfig   |   1 +
 drivers/media/i2c/smiapp/smiapp-core.c |  29 ++-
 drivers/media/i2c/tc358743.c   |  11 +-
 drivers/media/i2c/tvp514x.c|   6 +-
 drivers/media/i2c/tvp5150.c|   7 +-
 drivers/media/i2c/tvp7002.c|   6 +-
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/am437x/Kconfig  |   1 +
 drivers/media/platform/am437x/am437x-vpfe.c|  15 +-
 drivers/media/platform/atmel/Kconfig   |   1 +
 drivers/media/platform/atmel/atmel-isc.c   |  13 +-
 drivers/media/platform/exynos4-is/Kconfig  |   2 +
 drivers/media/platform/exynos4-is/media-dev.c  |  13 +-
 drivers/media/platform/exynos4-is/mipi-csis.c  |   6 +-
 drivers/media/platform/omap3isp/isp.c  |  49 ++--
 drivers/media/platform/pxa_camera.c|  11 +-
 drivers/media/platform/rcar-vin/Kconfig|   1 +
 drivers/media/platform/rcar-vin/rcar-core.c|  23 +-
 drivers/media/platform/soc_camera/Kconfig  |   1 +
 drivers/media/platform/soc_camera/atmel-isi.c  |   7 +-
 drivers/media/platform/soc_camera/soc_camera.c |   7 

[PATCH v3 4/7] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Sakari Ailus]

Switch users of the v4l2_of_ APIs to the more generic v4l2_fwnode_ APIs.
Async OF matching is replaced by fwnode matching and OF matching support
is removed.

Signed-off-by: Sakari Ailus 
Acked-by: Benoit Parrot  # i2c/ov2569.c, am437x/am437x-vpfe.c 
and ti-vpe/cal.c
---
 drivers/media/i2c/Kconfig  |  9 
 drivers/media/i2c/adv7604.c|  7 +--
 drivers/media/i2c/mt9v032.c|  7 +--
 drivers/media/i2c/ov2659.c |  8 ++--
 drivers/media/i2c/s5c73m3/s5c73m3-core.c   |  7 +--
 drivers/media/i2c/s5k5baf.c|  6 +--
 drivers/media/i2c/smiapp/Kconfig   |  1 +
 drivers/media/i2c/smiapp/smiapp-core.c | 29 ++--
 drivers/media/i2c/tc358743.c   | 11 +++--
 drivers/media/i2c/tvp514x.c|  6 +--
 drivers/media/i2c/tvp5150.c|  7 +--
 drivers/media/i2c/tvp7002.c|  6 +--
 drivers/media/platform/Kconfig |  3 ++
 drivers/media/platform/am437x/Kconfig  |  1 +
 drivers/media/platform/am437x/am437x-vpfe.c| 15 +++---
 drivers/media/platform/atmel/Kconfig   |  2 +
 drivers/media/platform/atmel/atmel-isc.c   | 13 --
 drivers/media/platform/atmel/atmel-isi.c   | 11 +++--
 drivers/media/platform/exynos4-is/Kconfig  |  2 +
 drivers/media/platform/exynos4-is/media-dev.c  | 13 +++---
 drivers/media/platform/exynos4-is/mipi-csis.c  |  6 +--
 drivers/media/platform/omap3isp/isp.c  | 49 ++--
 drivers/media/platform/pxa_camera.c| 11 +++--
 drivers/media/platform/rcar-vin/Kconfig|  1 +
 drivers/media/platform/rcar-vin/rcar-core.c| 19 
 drivers/media/platform/soc_camera/soc_camera.c |  7 +--
 drivers/media/platform/ti-vpe/cal.c| 15 +++---
 drivers/media/platform/xilinx/Kconfig  |  1 +
 drivers/media/platform/xilinx/xilinx-vipp.c| 63 ++
 drivers/media/v4l2-core/v4l2-async.c   | 14 +-
 include/media/v4l2-async.h |  5 --
 31 files changed, 194 insertions(+), 161 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cee1dae..6b2423a 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -210,6 +210,7 @@ config VIDEO_ADV7604
depends on GPIOLIB || COMPILE_TEST
select HDMI
select MEDIA_CEC_EDID
+   select V4L2_FWNODE
---help---
  Support for the Analog Devices ADV7604 video decoder.
 
@@ -324,6 +325,7 @@ config VIDEO_TC358743
tristate "Toshiba TC358743 decoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
select HDMI
+   select V4L2_FWNODE
---help---
  Support for the Toshiba TC358743 HDMI to MIPI CSI-2 bridge.
 
@@ -333,6 +335,7 @@ config VIDEO_TC358743
 config VIDEO_TVP514X
tristate "Texas Instruments TVP514x video decoder"
depends on VIDEO_V4L2 && I2C
+   select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the TI TVP5146/47
  decoder. It is currently working with the TI OMAP3 camera
@@ -344,6 +347,7 @@ config VIDEO_TVP514X
 config VIDEO_TVP5150
tristate "Texas Instruments TVP5150 video decoder"
depends on VIDEO_V4L2 && I2C
+   select V4L2_FWNODE
---help---
  Support for the Texas Instruments TVP5150 video decoder.
 
@@ -353,6 +357,7 @@ config VIDEO_TVP5150
 config VIDEO_TVP7002
tristate "Texas Instruments TVP7002 video decoder"
depends on VIDEO_V4L2 && I2C
+   select V4L2_FWNODE
---help---
  Support for the Texas Instruments TVP7002 video decoder.
 
@@ -524,6 +529,7 @@ config VIDEO_OV2659
tristate "OmniVision OV2659 sensor support"
depends on VIDEO_V4L2 && I2C
depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision
  OV2659 camera.
@@ -616,6 +622,7 @@ config VIDEO_MT9V032
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
select REGMAP_I2C
+   select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the Micron
  MT9V032 752x480 CMOS sensor.
@@ -663,6 +670,7 @@ config VIDEO_S5K4ECGX
 config VIDEO_S5K5BAF
tristate "Samsung S5K5BAF sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
---help---
  This is a V4L2 sensor-level driver for Samsung S5K5BAF 2M
  camera sensor with an embedded SoC image signal processor.
@@ -673,6 +681,7 @@ source "drivers/media/i2c/et8ek8/Kconfig"
 config VIDEO_S5C73M3
tristate "Samsung S5C73M3 sensor support"
depends on I2C && SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   

[PATCH v3 5/7] docs-rst: media: Sort topic list alphabetically

[Sakari Ailus]

Bring some order by alphabetically ordering the list of topics.

Signed-off-by: Sakari Ailus 
---
 Documentation/media/kapi/v4l2-core.rst | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/media/kapi/v4l2-core.rst 
b/Documentation/media/kapi/v4l2-core.rst
index d8f6c46..2fbf532 100644
--- a/Documentation/media/kapi/v4l2-core.rst
+++ b/Documentation/media/kapi/v4l2-core.rst
@@ -4,23 +4,23 @@ Video4Linux devices
 .. toctree::
 :maxdepth: 1
 
-v4l2-intro
+v4l2-clocks
+v4l2-common
+v4l2-controls
 v4l2-dev
 v4l2-device
-v4l2-fh
-v4l2-subdev
-v4l2-event
-v4l2-controls
-v4l2-videobuf
-v4l2-videobuf2
-v4l2-clocks
 v4l2-dv-timings
+v4l2-event
+v4l2-fh
 v4l2-flash-led-class
+v4l2-intro
 v4l2-mc
 v4l2-mediabus
 v4l2-mem2mem
 v4l2-of
 v4l2-rect
+v4l2-subdev
 v4l2-tuner
-v4l2-common
 v4l2-tveeprom
+v4l2-videobuf
+v4l2-videobuf2
-- 
2.7.4

[PATCH v3 1/7] v4l: fwnode: Support generic fwnode for parsing standardised properties

[Sakari Ailus]

The fwnode_handle is a more generic way than OF device_node to describe
firmware nodes. Instead of the OF API, use more generic fwnode API to
obtain the same information.

As the V4L2 fwnode support will be required by a small minority of e.g.
ACPI based systems (the same might actually go for OF), make this a module
instead of embedding it in the videodev module.

The origins of the V4L2 fwnode framework is in the V4L2 OF framework.

Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/Kconfig   |   3 +
 drivers/media/v4l2-core/Makefile  |   1 +
 drivers/media/v4l2-core/v4l2-fwnode.c | 345 ++
 include/media/v4l2-fwnode.h   | 104 ++
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/media/v4l2-core/v4l2-fwnode.c
 create mode 100644 include/media/v4l2-fwnode.h

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 6b1b78f..a35c336 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -55,6 +55,9 @@ config V4L2_FLASH_LED_CLASS
 
  When in doubt, say N.
 
+config V4L2_FWNODE
+   tristate
+
 # Used by drivers that need Videobuf modules
 config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 795a535..cf77a63 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -13,6 +13,7 @@ endif
 ifeq ($(CONFIG_OF),y)
   videodev-objs += v4l2-of.o
 endif
+obj-$(CONFIG_V4L2_FWNODE) += v4l2-fwnode.o
 ifeq ($(CONFIG_TRACEPOINTS),y)
   videodev-objs += vb2-trace.o v4l2-trace.o
 endif
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
new file mode 100644
index 000..153c53c
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -0,0 +1,345 @@
+/*
+ * V4L2 fwnode binding parsing library
+ *
+ * The origins of the V4L2 fwnode library are in V4L2 OF library that
+ * formerly was located in v4l2-of.c.
+ *
+ * Copyright (c) 2016 Intel Corporation.
+ * Author: Sakari Ailus 
+ *
+ * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki 
+ *
+ * Copyright (C) 2012 Renesas Electronics Corp.
+ * Author: Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static int v4l2_fwnode_endpoint_parse_csi_bus(struct fwnode_handle *fwnode,
+ struct v4l2_fwnode_endpoint *vep)
+{
+   struct v4l2_fwnode_bus_mipi_csi2 *bus = >bus.mipi_csi2;
+   bool have_clk_lane = false;
+   unsigned int flags = 0, lanes_used = 0;
+   unsigned int i;
+   u32 v;
+   int rval;
+
+   rval = fwnode_property_read_u32_array(fwnode, "data-lanes", NULL, 0);
+   if (rval > 0) {
+   u32 array[ARRAY_SIZE(bus->data_lanes)];
+
+   bus->num_data_lanes =
+   min_t(int, ARRAY_SIZE(bus->data_lanes), rval);
+
+   fwnode_property_read_u32_array(fwnode, "data-lanes", array,
+  bus->num_data_lanes);
+
+   for (i = 0; i < bus->num_data_lanes; i++) {
+   if (lanes_used & BIT(array[i]))
+   pr_warn("duplicated lane %u in data-lanes\n",
+   array[i]);
+   lanes_used |= BIT(array[i]);
+
+   bus->data_lanes[i] = array[i];
+   }
+   }
+
+   rval = fwnode_property_read_u32_array(fwnode, "lane-polarities", NULL,
+ 0);
+   if (rval > 0) {
+   u32 array[ARRAY_SIZE(bus->lane_polarities)];
+
+   if (rval < 1 + bus->num_data_lanes /* clock + data */) {
+   pr_warn("too few lane-polarities entries (need %u, got 
%u)\n",
+   1 + bus->num_data_lanes, rval);
+   return -EINVAL;
+   }
+
+   fwnode_property_read_u32_array(fwnode, "lane-polarities", array,
+  1 + bus->num_data_lanes);
+
+   for (i = 0; i < 1 + bus->num_data_lanes; i++)
+   bus->lane_polarities[i] = array[i];
+   }
+
+   if (!fwnode_property_read_u32(fwnode, "clock-lanes", )) {
+   if (lanes_used & BIT(v))
+   pr_warn("duplicated lane %u in clock-lanes\n", v);
+   lanes_used |= BIT(v);
+
+   bus->clock_lane = v;
+   have_clk_lane = true;
+   }
+
+   if (fwnode_property_present(fwnode, 

[PATCH v3 3/7] v4l: flash led class: Use fwnode_handle instead of device_node in init

[Sakari Ailus]

Pass the more generic fwnode_handle to the init function than the
device_node.

Signed-off-by: Sakari Ailus 
---
 drivers/leds/leds-aat1290.c|  5 +++--
 drivers/leds/leds-max77693.c   |  5 +++--
 drivers/media/v4l2-core/v4l2-flash-led-class.c | 12 ++--
 include/media/v4l2-flash-led-class.h   |  4 ++--
 4 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index def3cf9..a21e192 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -503,8 +503,9 @@ static int aat1290_led_probe(struct platform_device *pdev)
aat1290_init_v4l2_flash_config(led, _cfg, _sd_cfg);
 
/* Create V4L2 Flash subdev. */
-   led->v4l2_flash = v4l2_flash_init(dev, sub_node, fled_cdev, NULL,
- _flash_ops, _sd_cfg);
+   led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
+ fled_cdev, NULL, _flash_ops,
+ _sd_cfg);
if (IS_ERR(led->v4l2_flash)) {
ret = PTR_ERR(led->v4l2_flash);
goto error_v4l2_flash_init;
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
index 1eb58ef..2d3062d 100644
--- a/drivers/leds/leds-max77693.c
+++ b/drivers/leds/leds-max77693.c
@@ -930,8 +930,9 @@ static int max77693_register_led(struct max77693_sub_led 
*sub_led,
max77693_init_v4l2_flash_config(sub_led, led_cfg, _sd_cfg);
 
/* Register in the V4L2 subsystem. */
-   sub_led->v4l2_flash = v4l2_flash_init(dev, sub_node, fled_cdev, NULL,
- _flash_ops, _sd_cfg);
+   sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
+ fled_cdev, NULL, _flash_ops,
+ _sd_cfg);
if (IS_ERR(sub_led->v4l2_flash)) {
ret = PTR_ERR(sub_led->v4l2_flash);
goto err_v4l2_flash_init;
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c 
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 794e563..7b82881 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -612,7 +612,7 @@ static const struct v4l2_subdev_internal_ops 
v4l2_flash_subdev_internal_ops = {
 static const struct v4l2_subdev_ops v4l2_flash_subdev_ops;
 
 struct v4l2_flash *v4l2_flash_init(
-   struct device *dev, struct device_node *of_node,
+   struct device *dev, struct fwnode_handle *fwn,
struct led_classdev_flash *fled_cdev,
struct led_classdev_flash *iled_cdev,
const struct v4l2_flash_ops *ops,
@@ -638,7 +638,7 @@ struct v4l2_flash *v4l2_flash_init(
v4l2_flash->iled_cdev = iled_cdev;
v4l2_flash->ops = ops;
sd->dev = dev;
-   sd->of_node = of_node ? of_node : led_cdev->dev->of_node;
+   sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
v4l2_subdev_init(sd, _flash_subdev_ops);
sd->internal_ops = _flash_subdev_internal_ops;
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
@@ -654,7 +654,7 @@ struct v4l2_flash *v4l2_flash_init(
if (ret < 0)
goto err_init_controls;
 
-   of_node_get(sd->of_node);
+   fwnode_handle_get(sd->fwnode);
 
ret = v4l2_async_register_subdev(sd);
if (ret < 0)
@@ -663,7 +663,7 @@ struct v4l2_flash *v4l2_flash_init(
return v4l2_flash;
 
 err_async_register_sd:
-   of_node_put(sd->of_node);
+   fwnode_handle_put(sd->fwnode);
v4l2_ctrl_handler_free(sd->ctrl_handler);
 err_init_controls:
media_entity_cleanup(>entity);
@@ -683,7 +683,7 @@ void v4l2_flash_release(struct v4l2_flash *v4l2_flash)
 
v4l2_async_unregister_subdev(sd);
 
-   of_node_put(sd->of_node);
+   fwnode_handle_put(sd->fwnode);
 
v4l2_ctrl_handler_free(sd->ctrl_handler);
media_entity_cleanup(>entity);
diff --git a/include/media/v4l2-flash-led-class.h 
b/include/media/v4l2-flash-led-class.h
index b0fe4d6..5695853 100644
--- a/include/media/v4l2-flash-led-class.h
+++ b/include/media/v4l2-flash-led-class.h
@@ -108,7 +108,7 @@ static inline struct v4l2_flash 
*v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c)
 /**
  * v4l2_flash_init - initialize V4L2 flash led sub-device
  * @dev:   flash device, e.g. an I2C device
- * @of_node:   of_node of the LED, may be NULL if the same as device's
+ * @fwn:   fwnode_handle of the LED, may be NULL if the same as device's
  * @fled_cdev: LED flash class device to wrap
  * @iled_cdev: LED flash class device representing indicator LED associated
  * with fled_cdev, may be NULL
@@ -122,7 +122,7 @@ static inline struct v4l2_flash 

[PATCH v3 7/7] v4l: Remove V4L2 OF framework in favour of V4L2 fwnode framework

[Sakari Ailus]

All drivers have been converted from V4L2 OF to V4L2 fwnode. The V4L2 OF
framework is now unused. Remove it.

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/v4l2-core/Makefile  |   3 -
 drivers/media/v4l2-core/v4l2-of.c | 327 --
 include/media/v4l2-of.h   | 128 ---
 3 files changed, 458 deletions(-)
 delete mode 100644 drivers/media/v4l2-core/v4l2-of.c
 delete mode 100644 include/media/v4l2-of.h

diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index cf77a63..098ad5f 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -10,9 +10,6 @@ videodev-objs :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o 
v4l2-fh.o \
 ifeq ($(CONFIG_COMPAT),y)
   videodev-objs += v4l2-compat-ioctl32.o
 endif
-ifeq ($(CONFIG_OF),y)
-  videodev-objs += v4l2-of.o
-endif
 obj-$(CONFIG_V4L2_FWNODE) += v4l2-fwnode.o
 ifeq ($(CONFIG_TRACEPOINTS),y)
   videodev-objs += vb2-trace.o v4l2-trace.o
diff --git a/drivers/media/v4l2-core/v4l2-of.c 
b/drivers/media/v4l2-core/v4l2-of.c
deleted file mode 100644
index 4f59f44..000
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ /dev/null
@@ -1,327 +0,0 @@
-/*
- * V4L2 OF binding parsing library
- *
- * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
- * Author: Sylwester Nawrocki 
- *
- * Copyright (C) 2012 Renesas Electronics Corp.
- * Author: Guennadi Liakhovetski 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of version 2 of the GNU General Public License as
- * published by the Free Software Foundation.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-static int v4l2_of_parse_csi_bus(const struct device_node *node,
-struct v4l2_of_endpoint *endpoint)
-{
-   struct v4l2_of_bus_mipi_csi2 *bus = >bus.mipi_csi2;
-   struct property *prop;
-   bool have_clk_lane = false;
-   unsigned int flags = 0, lanes_used = 0;
-   u32 v;
-
-   prop = of_find_property(node, "data-lanes", NULL);
-   if (prop) {
-   const __be32 *lane = NULL;
-   unsigned int i;
-
-   for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
-   lane = of_prop_next_u32(prop, lane, );
-   if (!lane)
-   break;
-
-   if (lanes_used & BIT(v))
-   pr_warn("%s: duplicated lane %u in 
data-lanes\n",
-   node->full_name, v);
-   lanes_used |= BIT(v);
-
-   bus->data_lanes[i] = v;
-   }
-   bus->num_data_lanes = i;
-   }
-
-   prop = of_find_property(node, "lane-polarities", NULL);
-   if (prop) {
-   const __be32 *polarity = NULL;
-   unsigned int i;
-
-   for (i = 0; i < ARRAY_SIZE(bus->lane_polarities); i++) {
-   polarity = of_prop_next_u32(prop, polarity, );
-   if (!polarity)
-   break;
-   bus->lane_polarities[i] = v;
-   }
-
-   if (i < 1 + bus->num_data_lanes /* clock + data */) {
-   pr_warn("%s: too few lane-polarities entries (need %u, 
got %u)\n",
-   node->full_name, 1 + bus->num_data_lanes, i);
-   return -EINVAL;
-   }
-   }
-
-   if (!of_property_read_u32(node, "clock-lanes", )) {
-   if (lanes_used & BIT(v))
-   pr_warn("%s: duplicated lane %u in clock-lanes\n",
-   node->full_name, v);
-   lanes_used |= BIT(v);
-
-   bus->clock_lane = v;
-   have_clk_lane = true;
-   }
-
-   if (of_get_property(node, "clock-noncontinuous", ))
-   flags |= V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK;
-   else if (have_clk_lane || bus->num_data_lanes > 0)
-   flags |= V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
-
-   bus->flags = flags;
-   endpoint->bus_type = V4L2_MBUS_CSI2;
-
-   return 0;
-}
-
-static void v4l2_of_parse_parallel_bus(const struct device_node *node,
-  struct v4l2_of_endpoint *endpoint)
-{
-   struct v4l2_of_bus_parallel *bus = >bus.parallel;
-   unsigned int flags = 0;
-   u32 v;
-
-   if (!of_property_read_u32(node, "hsync-active", ))
-   flags |= v ? V4L2_MBUS_HSYNC_ACTIVE_HIGH :
-   V4L2_MBUS_HSYNC_ACTIVE_LOW;
-
-   if (!of_property_read_u32(node, "vsync-active", ))
-   flags |= v ? V4L2_MBUS_VSYNC_ACTIVE_HIGH :
-   V4L2_MBUS_VSYNC_ACTIVE_LOW;
-
-   if 

Re: [PATCH v2.3] v4l: Clearly document interactions between formats, controls and buffers

[Mauro Carvalho Chehab]

Em Mon,  6 Mar 2017 16:14:41 +0200
Laurent Pinchart  escreveu:

> V4L2 exposes parameters that influence buffers sizes through the format
> ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly
> VIDIOC_G_SELECTION and VIDIOC_S_SELECTION). Other parameters not part of
> the format structure may also influence buffer sizes or buffer layout in
> general. One existing such parameter is rotation, which is implemented
> by the V4L2_CID_ROTATE control and thus exposed through the V4L2 control
> ioctls.
> 
> The interaction between those parameters and buffers is currently only
> partially specified by the V4L2 API. In particular interactions between
> controls and buffers isn't specified at all. The behaviour of the
> VIDIOC_S_FMT and VIDIOC_S_SELECTION ioctls when buffers are allocated is
> also not fully specified.
> 
> This patch clearly defines and documents the interactions between
> formats, selections, controls and buffers.
> 
> The preparatory discussions for the documentation change considered
> completely disallowing controls that change the buffer size or layout,
> in favour of extending the format API with a new ioctl that would bundle
> those controls with format information. The idea has been rejected, as
> this would essentially be a restricted version of the upcoming request
> API that wouldn't bring any additional value.
> 
> Another option we have considered was to mandate the use of the request
> API to modify controls that influence buffer size or layout. This has
> also been rejected on the grounds that requiring the request API to
> change rotation even when streaming is stopped would significantly
> complicate implementation of drivers and usage of the V4L2 API for
> applications.
> 
> Applications will however be required to use the upcoming request API to
> change at runtime formats or controls that influence the buffer size or
> layout, because of the need to synchronize buffers with the formats and
> controls. Otherwise there would be no way to interpret the content of a
> buffer correctly.
> 
> Signed-off-by: Laurent Pinchart 
> Acked-by: Sakari Ailus 
> ---
> Changes since v2.2:
> 
> - Describe the simple option first
> - Fix error codes
> 
> Changes since v2.1:
> 
> - Fixed small issues in commit message
> - Simplified wording of one sentence in the documentation
> 
> Changes since v2:
> 
> - Document the interaction with ioctls that can affect formats
>   (VIDIOC_S_SELECTION, VIDIOC_S_INPUT, VIDIOC_S_OUTPUT, VIDIOC_S_STD and
>   VIDIOC_S_DV_TIMINGS)
> - Clarify the format/control change order
> ---
>  Documentation/media/uapi/v4l/buffer.rst | 110 
> 
>  1 file changed, 110 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index ac58966ccb9b..d1e0d55dc219 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst

...

> +.. note::
> +
> +   The API doesn't mandate the above order for control (3.) and format (4.)
> +   changes. Format and controls can be set in a different order, or even
> +   interleaved, depending on the device and use case. For instance some
> +   controls might behave differently for different pixel formats, in which
> +   case the format might need to be set first.
> +
> +When reallocation is required, any attempt to modify format or controls that
> +influences the buffer size while buffers are allocated shall cause the format
> +or control set ioctl to return the ``EBUSY`` error. Any attempt to queue a
> +buffer too small for the current format or controls shall cause the
> +:c:func:`VIDIOC_QBUF` ioctl to return a ``EINVAL`` error.

This can be problematic. As I just implemented support for controls
this weekend at Zbar, I'm now talking as an userspace app developer's
hat.

The real problem here is that applications must be aware of what
controls change the buffer layout. Blindly changing controls without
such check would cause the stream to fail with -EINVAL errors at
QBUF.

So, applications will need to to have a "black list" of controls that may
influence the buffer size  (like V4L2_CID_ROTATE), in order to know
if, for such particular control, the stream should be stopped, in
order to reallocate buffers.

If such "black list" is not updated as newer controls are added, the
final result is that, if the user changes such control, the 
application will receive EINVAL, causing it to fail streaming.

Instead of that, the best is to add control flag to be returned via
VIDIOC_QUERY_CTRL/VIDIOC_QUERY_EXT_CTRL indicating when a control modifies 
the buffer layout, e. g., something like:

#define V4L2_CTRL_FLAG_MODIFY_BUF_LAYOUT0x0400

Such flag shall be set for V4L2_CID_ROTATE (and other controls) if,
for a particular driver, the buffer layout is modified.

This way, userspace can 

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

[Tomi Valkeinen]

On 08/04/17 13:11, Hans Verkuil wrote:

> So, this is a bit of a blast from the past since the omap4 CEC development
> has been on hold for almost a year. But I am about to resume my work on this
> now that the CEC framework was merged.
> 
> The latest code is here, if you are interested:
> 
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=panda-cec
> 
> It's pretty much unchanged from the version I posted a year ago, just rebased.
> 
> But before I continue with this I have one question for you. First some
> background:
> 
> There is a special corner case (and I wasn't aware of that a year ago!) where
> it is allowed to send a CEC message when there is *no HPD*.
> 
> The reason is that some displays turn off the hotplug detect pin when they go
> into standby or when another input is active. The only way to communicate with
> such displays is via CEC.
> 
> The problem is that without a HPD there is no EDID and basically no way for an
> HDMI transmitter to detect that something is connected at all, unless you are
> using CEC.
> 
> What this means is that if we want to implement this on the omap4 the CEC 
> support
> has to be on all the time.
> 
> We have seen modern displays that behave like this, so this is a real issue. 
> And
> this corner case is specifically allowed by the CEC specification: the Poll,
> Image/Text View On and the Active Source messages can be sent to a TV even 
> when
> there is no HPD in order to turn on the display if it was in standby and to 
> make
> us the active input.
> 
> The CEC framework in the kernel supports this starting with 4.12 (this code is
> in the panda-cec branch above).
> 
> If this *can't* be supported by the omap4, then I will likely have to add a 
> CEC
> capability to signal to the application that this specific corner case is not
> supported.
> 
> I just did some tests with omap4 and I my impression is that this can't be
> supported: when the HPD goes away it seems like most/all of the HDMI blocks 
> are
> all powered off and any attempt to even access the CEC registers will fail.
> 
> Changing this looks to be non-trivial if not impossible.
> 
> Can you confirm that that isn't possible? If you think this can be done, then
> I'd appreciate if you can give me a few pointers.

HPD doesn't control the HW, it's all in the SW. So while I don't know
much at all about CEC and haven't looked at this particular use case, I
believe it's doable. HPD going off will make the DRM connector to be in
"disconnected" state, which on omapdrm will cause everything about HDMI
to be turned off.

Does it work on some other DRM driver? I'm wondering if there's
something in the DRM framework side that also has to be changed, in
addition to omapdrm changes.

It could require larger SW redesigns, though... Which makes me think
that the work shouldn't be done until we have changed the omapdrm's
driver model to DRM's common bridge driver model, and then all this
could possibly be done in a more generic manner.

Well, then again, I think the hdmi driver's internal power state
handling could be improved even before that. Currently it's not very
versatile. We should have ways to partially enable the IP for just the
required parts.

 Tomi



signature.asc
Description: OpenPGP digital signature

[GIT PULL FOR v4.12] Various fixes

[Hans Verkuil]

Various fixes for 4.12.

Regards,

Hans

The following changes since commit 0538bee6fdec9b79910c1c9835e79be75d0e1bdf:

  [media] MAINTAINERS: update atmel-isi.c path (2017-04-10 08:13:08 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.12f

for you to fetch changes up to 2c3d089c30302bf17953176e37ccfb344b53186e:

  v4l2-tpg: don't clamp XV601/709 to lim range (2017-04-10 13:32:32 +0200)


Alexey Khoroshilov (1):
  m2m-deinterlace: don't return zero on failure paths in deinterlace_probe()

Colin Ian King (1):
  coda: remove redundant call to v4l2_m2m_get_vq

Geliang Tang (11):
  saa7134: use setup_timer
  saa7146: use setup_timer
  bt8xx: use setup_timer
  cx18: use setup_timer
  ivtv: use setup_timer
  netup_unidvb: use setup_timer
  av7110: use setup_timer
  fsl-viu: use setup_timer
  c8sectpfe: use setup_timer
  wl128x: use setup_timer
  imon: use setup_timer

Hans Verkuil (2):
  videodev2.h: fix outdated comment
  v4l2-tpg: don't clamp XV601/709 to lim range

Nikola Jelic (1):
  media: bcm2048: fix several macros

Philipp Zabel (3):
  tvp5150: allow get/set_fmt on the video source pad
  tvp5150: fix pad format frame height
  coda: do not enumerate YUYV if VDOA is not available

 drivers/media/common/saa7146/saa7146_vbi.c|  5 ++---
 drivers/media/common/saa7146/saa7146_video.c  |  5 ++---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c |  9 -
 drivers/media/i2c/tvp5150.c   |  4 ++--
 drivers/media/pci/bt8xx/bttv-driver.c |  4 +---
 drivers/media/pci/cx18/cx18-streams.c |  4 +---
 drivers/media/pci/ivtv/ivtv-driver.c  |  5 ++---
 drivers/media/pci/netup_unidvb/netup_unidvb_core.c|  5 ++---
 drivers/media/pci/saa7134/saa7134-ts.c|  5 ++---
 drivers/media/pci/saa7134/saa7134-vbi.c   |  5 ++---
 drivers/media/pci/saa7134/saa7134-video.c |  5 ++---
 drivers/media/pci/ttpci/av7110_ir.c   |  5 ++---
 drivers/media/platform/coda/coda-common.c |  8 ++--
 drivers/media/platform/fsl-viu.c  |  5 ++---
 drivers/media/platform/m2m-deinterlace.c  |  1 +
 drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c |  5 ++---
 drivers/media/radio/wl128x/fmdrv_common.c |  5 ++---
 drivers/media/rc/imon.c   |  5 ++---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++--
 include/uapi/linux/videodev2.h|  3 +--
 20 files changed, 50 insertions(+), 55 deletions(-)

Re: [PATCH v2 4/8] v4l: async: Provide interoperability between OF and fwnode matching

[Sakari Ailus]

Hi Laurent,

On Sat, Apr 08, 2017 at 01:10:47AM +0300, Sakari Ailus wrote:
> Hi Laurent,
> 
> On Fri, Apr 07, 2017 at 01:07:48PM +0300, Laurent Pinchart wrote:
> > Hi Sakari,
> > 
> > Thank you for the patch.
> > 
> > On Thursday 06 Apr 2017 16:12:06 Sakari Ailus wrote:
> > > OF and fwnode support are separated in V4L2 and individual drivers may
> > > implement one of them. Sub-devices do not match with a notifier
> > > expecting sub-devices with fwnodes, nor the other way around.
> > 
> > Shouldn't we instead convert all drivers to fwnode matching ? What's 
> > missing 
> > after the mass conversion in patch 5/8 ?
> 
> A lot of drivers use the OF frame work and thus do not deal with fwnodes
> directly. I haven't entirely converted them to use the fwnode API since
> making additional, unnecessary changes increases the likelihood of errors.

Doing the rest of the conversion was less work than I originally had
anticipated. The changes are obvious and very similar from driver to driver,
perhaps unsurprisingly. Nevertheless, additional testing coverage certainly
wouldn't hurt.

-- 
Regards,

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

[GIT PULL FOR v4.12] ov2640: move out of soc-camera (rebased)

[Hans Verkuil]

Hi Mauro,

Here is the remainder of my "atmel-isi/ov7670/ov2640: convert to standalone 
drivers"
pull request, rebased to the latest master. This should now merge fine.

Regards,

Hans

The following changes since commit 0538bee6fdec9b79910c1c9835e79be75d0e1bdf:

  [media] MAINTAINERS: update atmel-isi.c path (2017-04-10 08:13:08 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git sama5d3

for you to fetch changes up to 9ef9f8fec3c8283f2186d4dd609e31914202809a:

  em28xx: drop last soc_camera link (2017-04-10 13:23:28 +0200)


Hans Verkuil (4):
  ov2640: convert from soc-camera to a standard subdev sensor driver.
  ov2640: use standard clk and enable it.
  ov2640: add MC support
  em28xx: drop last soc_camera link

 drivers/media/i2c/Kconfig   |  11 +
 drivers/media/i2c/Makefile  |   1 +
 drivers/media/i2c/{soc_camera => }/ov2640.c | 130 
+++-
 drivers/media/i2c/soc_camera/Kconfig|   6 ---
 drivers/media/i2c/soc_camera/Makefile   |   1 -
 drivers/media/usb/em28xx/em28xx-camera.c|   9 
 6 files changed, 55 insertions(+), 103 deletions(-)
 rename drivers/media/i2c/{soc_camera => }/ov2640.c (93%)

Re: [GIT PULL FOR v4.12] atmel-isi/ov7670/ov2640: convert to standalone drivers

[Mauro Carvalho Chehab]

Em Tue, 4 Apr 2017 14:46:25 +0200
Hans Verkuil  escreveu:

> Converts atmel-isi to a regular v4l2 driver instead of relying on soc-camera.
> 
> The ov2640 and ov7670 drivers are also converted to normal i2c drivers.
> 
> Tested with my sama5d3-Xplained board, the ov2640 sensor and two ov7670
> sensors: one with and one without reset/pwdn pins. Also tested with my
> em28xx-based webcam.
> 
> See here for the patch series' cover letter:
> 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg110532.html
> 
> The only change since this patch series was posted is that last patch updating
> the atmel-isi path in MAINTAINERS.

I applied this patch too. Next time, please change MAINTAINERS
on the same patch you're moving the file, as it avoid the
risk of forgetting to apply, if something fails in de middle of
a patch series.

> After this patch series the only platform driver still using soc-camera is the
> sh_mobile_ceu_camera driver.
> 
> The (tentative) plan is to merge soc-camera into that sh driver, ensuring it
> is no longer available as a stand-alone framework.
> 
> Regarding the other soc-camera i2c drivers: the following drivers are used
> by sh board files: ov772x, tw9910, mt9t112, rj54n1cb0c.
> 
> All others are never used by a soc-camera in-tree device.
> 
> I am considering to make those four drivers depend on the sh_mobile_ceu_camera
> driver.

Sounds like a plan.

> The other soc_camera i2c drivers can be moved to staging/media and
> marked as BROKEN.

If they aren't used, I guess we could just drop them. If anyone needs
in the future, it should be easy to revert the change and add a patch
converting them.

> Are there any i2c soc_camera drivers that are also used by non-soc-camera
> drivers? I'm not aware of that.
> 
> I have some of the i2c soc_camera sensors, so when time permits I'll try to
> convert them over as standalone sensor drivers.
> 
> Regards,
> 
>   Hans
> 
> The following changes since commit 700ea5e0e0dd70420a04e703ff264cc133834cba:
> 
>   Merge tag 'v4.11-rc1' into patchwork (2017-03-06 06:49:34 -0300)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git sama5d3
> 
> for you to fetch changes up to 11498c0d43013f51e1041a6dcf8934d62df6f41b:
> 
>   MAINTAINERS: update atmel-isi.c path (2017-04-03 16:50:53 +0200)
> 
> 
> Hans Verkuil (15):
>   ov7670: document device tree bindings
>   ov7670: call v4l2_async_register_subdev
>   ov7670: fix g/s_parm
>   ov7670: get xclk
>   ov7670: add devicetree support
>   atmel-isi: update device tree bindings documentation
>   atmel-isi: remove dependency of the soc-camera framework
>   atmel-isi: move out of soc_camera to atmel
>   ov2640: fix colorspace handling
>   ov2640: update bindings
>   ov2640: convert from soc-camera to a standard subdev sensor driver.
>   ov2640: use standard clk and enable it.
>   ov2640: add MC support
>   em28xx: drop last soc_camera link
>   MAINTAINERS: update atmel-isi.c path
> 
>  Documentation/devicetree/bindings/media/atmel-isi.txt|   91 ---
>  Documentation/devicetree/bindings/media/i2c/ov2640.txt   |   23 +-
>  Documentation/devicetree/bindings/media/i2c/ov7670.txt   |   43 +++
>  MAINTAINERS  |3 +-
>  drivers/media/i2c/Kconfig|   11 +
>  drivers/media/i2c/Makefile   |1 +
>  drivers/media/i2c/{soc_camera => }/ov2640.c  |  153 ---
>  drivers/media/i2c/ov7670.c   |   75 +-
>  drivers/media/i2c/soc_camera/Kconfig |6 -
>  drivers/media/i2c/soc_camera/Makefile|1 -
>  drivers/media/platform/Makefile  |1 +
>  drivers/media/platform/atmel/Kconfig |   11 +-
>  drivers/media/platform/atmel/Makefile|1 +
>  drivers/media/platform/atmel/atmel-isi.c | 1368
> ++
>  drivers/media/platform/{soc_camera => atmel}/atmel-isi.h |0
>  drivers/media/platform/soc_camera/Kconfig|   11 -
>  drivers/media/platform/soc_camera/Makefile   |1 -
>  drivers/media/platform/soc_camera/atmel-isi.c| 1167
> 
>  drivers/media/usb/em28xx/em28xx-camera.c |9 -
>  19 files changed, 1615 insertions(+), 1361 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7670.txt
>  rename drivers/media/i2c/{soc_camera => }/ov2640.c (92%)
>  create mode 100644 drivers/media/platform/atmel/atmel-isi.c
>  rename drivers/media/platform/{soc_camera => atmel}/atmel-isi.h (100%)
>  delete mode 100644 

Re: [GIT PULL FOR v4.12] atmel-isi/ov7670/ov2640: convert to standalone drivers

[Mauro Carvalho Chehab]

Em Tue, 4 Apr 2017 14:46:25 +0200
Hans Verkuil  escreveu:

> Converts atmel-isi to a regular v4l2 driver instead of relying on soc-camera.
> 
> The ov2640 and ov7670 drivers are also converted to normal i2c drivers.
> 
> Tested with my sama5d3-Xplained board, the ov2640 sensor and two ov7670
> sensors: one with and one without reset/pwdn pins. Also tested with my
> em28xx-based webcam.
> 
> See here for the patch series' cover letter:
> 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg110532.html
> 
> The only change since this patch series was posted is that last patch updating
> the atmel-isi path in MAINTAINERS.
> 
> After this patch series the only platform driver still using soc-camera is the
> sh_mobile_ceu_camera driver.
> 
> The (tentative) plan is to merge soc-camera into that sh driver, ensuring it
> is no longer available as a stand-alone framework.
> 
> Regarding the other soc-camera i2c drivers: the following drivers are used
> by sh board files: ov772x, tw9910, mt9t112, rj54n1cb0c.
> 
> All others are never used by a soc-camera in-tree device.
> 
> I am considering to make those four drivers depend on the sh_mobile_ceu_camera
> driver. The other soc_camera i2c drivers can be moved to staging/media and
> marked as BROKEN.
> 
> Are there any i2c soc_camera drivers that are also used by non-soc-camera
> drivers? I'm not aware of that.
> 
> I have some of the i2c soc_camera sensors, so when time permits I'll try to
> convert them over as standalone sensor drivers.
> 
> Regards,
> 
>   Hans
> 
> The following changes since commit 700ea5e0e0dd70420a04e703ff264cc133834cba:
> 
>   Merge tag 'v4.11-rc1' into patchwork (2017-03-06 06:49:34 -0300)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git sama5d3
> 
> for you to fetch changes up to 11498c0d43013f51e1041a6dcf8934d62df6f41b:
> 
>   MAINTAINERS: update atmel-isi.c path (2017-04-03 16:50:53 +0200)
> 
> 
> Hans Verkuil (15):
>   ov7670: document device tree bindings
>   ov7670: call v4l2_async_register_subdev
>   ov7670: fix g/s_parm
>   ov7670: get xclk
>   ov7670: add devicetree support
>   atmel-isi: update device tree bindings documentation
>   atmel-isi: remove dependency of the soc-camera framework
>   atmel-isi: move out of soc_camera to atmel
>   ov2640: fix colorspace handling
>   ov2640: update bindings
>   ov2640: convert from soc-camera to a standard subdev sensor driver.

This patch has a non-trivial conflict with upstream. I tried to solve it,
but it caused a compilation breakage:

drivers/media/i2c/ov2640.c: In function 'ov2640_g_mbus_config':
drivers/media/i2c/ov2640.c:1001:40: error: implicit declaration of function 
'soc_camera_i2c_to_desc' [-Werror=implicit-function-declaration]
  struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
^~
drivers/media/i2c/ov2640.c:1001:40: warning: initialization makes pointer from 
integer without a cast [-Wint-conversion]
drivers/media/i2c/ov2640.c:1007:15: error: implicit declaration of function 
'soc_camera_apply_board_flags' [-Werror=implicit-function-declaration]
  cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
   ^~~~
drivers/media/i2c/ov2640.c: At top level:
drivers/media/i2c/ov2640.c:1013:14: error: 'ov2640_s_stream' undeclared here 
(not in a function)
  .s_stream = ov2640_s_stream,
  ^~~
drivers/media/i2c/ov2640.c:1012:43: warning: 'ov2640_subdev_video_ops' defined 
but not used [-Wunused-const-variable=]
 static const struct v4l2_subdev_video_ops ov2640_subdev_video_ops = {
   ^~~
Please rebase.

I applied already the patches 1 to 10 from this pull request.

Regards,
Mauro

Thanks,
Mauro

Re: [PATCH] Quirk for webcam in MacBook Pro 2016

[Laurent Pinchart]

Hi Daniel,

On Sunday 09 Apr 2017 19:43:22 Daniel Roschka wrote:
> Hi Laurent,
> 
> I don't want to sound impatient, but I as I don't know what your usual
> reaction times to patches are and already waited three weeks without any
> reaction, I kindly want to ask, if you already had a chance to look into
> this patch and consider it for inclusion into your tree?

Thank you for pinging me, the patch was indeed buried under a pile of other e-
mails :-)

Your mail client (or server, I don't know) mangled the patch by replacing tabs 
with spaces. As the patch is short I've fixed this manually, but next time 
please try to fix the issue on your side.

Another small issue is that the commit message should be wrapped at 72 
columns. Depending on the text editor you use, git commit usually does that 
automatically for you.

I've also added a "uvcvideo: " prefix to the subject line, otherwise short git 
logs wouldn't be very clear. As a rule of thumb, your subject line should 
contain enough information to understand which driver the patch relates to, 
and what it does.

Your patch is now in my git tree, and I will push it upstream for v4.13 (v4.11 
will be released very soon, and given the pending pull requests for v4.12 in 
the Linux media tree I don't think I can add another one).

I collect USB descriptors for UVC devices. Could you please send me the output 
of

lsusb -d 05ac:8600

if possible running as root ?

Thank you for your contribution !

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dev-capture.rst/dev-output.rst: video standards ioctls are optional

[Hans Verkuil]

On 04/10/2017 12:36 PM, Hans Verkuil wrote:
> On 04/10/2017 12:21 PM, Mauro Carvalho Chehab wrote:
>> Em Wed, 29 Mar 2017 09:56:47 +0200
>> Hans Verkuil  escreveu:
>>
>>> The documentation for video capture and output devices claims that the 
>>> video standard
>>> ioctls are required. This is not the case, they are only required for 
>>> PAL/NTSC/SECAM
>>> type inputs and outputs. Sensors do not implement this at all and e.g. HDMI 
>>> inputs
>>> implement the DV Timings ioctls.
>>>
>>> Just drop the mention of 'video standard' ioctls.
>>>
>>> Signed-off-by: Hans Verkuil 
>>
>> This is an API change that has the potential of breaking userspace.
>>
>> In the past, several applications were failing if VIDIOC_ENUMSTD ioctl is
>> not implemented. So, I remember we had this discussion before, but I don't
>> remember the dirty details anymore.
>>
>> Yet, looking at the code, it seems that we ended by making VIDIOC_ENUMSTD
>> mandatory and implemented at the core. So, V4L2 core will make this
>> ioctl available for all drivers. The core implementattion will, however, 
>> return -ENODATA  if the driver doesn't set video_device.tvnorms, indicating
>> that standard video timings are not supported.
>>
>> So, instead of the enclosed patch, the documentation should mention the
>> standard ioctls, saying that G_STD/S_STD are optional, and ENUMSTD is
>> mandatory. 
> 
> I don't think so. In v4l2-dev.c ENUMSTD is only enabled if the driver supports
> the s_std ioctl:
> 
> if (is_vid || is_vbi || is_tch) {
> /* ioctls valid for video or vbi */
> if (ops->vidioc_s_std)
> set_bit(_IOC_NR(VIDIOC_ENUMSTD), valid_ioctls);
> 
> And in case you are wondering: if you have two inputs, one SDTV and one HDTV, 
> then
> you have both s_std and s_dv_timings ioctls and if you switch to the HDTV 
> input,
> then tvnorms is set to 0, causing ENUMSTD to return -ENODATA. If you switch 
> back,
> then the driver will fill in tvnorms to something non-0.

Note that v4l2-compliance will verify that you can't enumerate standards if the
input/output doesn't indicate STD support. So this patch is really correct.

Regards,

Hans

> 
> Regards,
> 
>   Hans
> 
>>
>> We could include a note about it may return -ENODATA, although the ENUMSTD
>> documentation already states that it returns -ENODATA:
>>  
>> https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-enumstd.html
>>
>> Regards,
>> Mauro
>>
>>> ---
>>> diff --git a/Documentation/media/uapi/v4l/dev-capture.rst 
>>> b/Documentation/media/uapi/v4l/dev-capture.rst
>>> index 32b32055d070..4218742ab5d9 100644
>>> --- a/Documentation/media/uapi/v4l/dev-capture.rst
>>> +++ b/Documentation/media/uapi/v4l/dev-capture.rst
>>> @@ -42,8 +42,8 @@ Video capture devices shall support :ref:`audio input 
>>> `,
>>>  :ref:`tuner`, :ref:`controls `,
>>>  :ref:`cropping and scaling ` and
>>>  :ref:`streaming parameter ` ioctls as needed. The
>>> -:ref:`video input ` and :ref:`video standard `
>>> -ioctls must be supported by all video capture devices.
>>> +:ref:`video input ` ioctls must be supported by all video
>>> +capture devices.
>>>
>>>
>>>  Image Format Negotiation
>>> diff --git a/Documentation/media/uapi/v4l/dev-output.rst 
>>> b/Documentation/media/uapi/v4l/dev-output.rst
>>> index 25ae8ec96fdf..342eb4931f5c 100644
>>> --- a/Documentation/media/uapi/v4l/dev-output.rst
>>> +++ b/Documentation/media/uapi/v4l/dev-output.rst
>>> @@ -40,8 +40,8 @@ Video output devices shall support :ref:`audio output 
>>> `,
>>>  :ref:`modulator `, :ref:`controls `,
>>>  :ref:`cropping and scaling ` and
>>>  :ref:`streaming parameter ` ioctls as needed. The
>>> -:ref:`video output ` and :ref:`video standard `
>>> -ioctls must be supported by all video output devices.
>>> +:ref:`video output ` ioctls must be supported by all video
>>> +output devices.
>>>
>>>
>>>  Image Format Negotiation
>>
>>
>>
>> Thanks,
>> Mauro
>>
> 

Re: [PATCH] dev-capture.rst/dev-output.rst: video standards ioctls are optional

[Hans Verkuil]

On 04/10/2017 12:21 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Mar 2017 09:56:47 +0200
> Hans Verkuil  escreveu:
> 
>> The documentation for video capture and output devices claims that the video 
>> standard
>> ioctls are required. This is not the case, they are only required for 
>> PAL/NTSC/SECAM
>> type inputs and outputs. Sensors do not implement this at all and e.g. HDMI 
>> inputs
>> implement the DV Timings ioctls.
>>
>> Just drop the mention of 'video standard' ioctls.
>>
>> Signed-off-by: Hans Verkuil 
> 
> This is an API change that has the potential of breaking userspace.
> 
> In the past, several applications were failing if VIDIOC_ENUMSTD ioctl is
> not implemented. So, I remember we had this discussion before, but I don't
> remember the dirty details anymore.
> 
> Yet, looking at the code, it seems that we ended by making VIDIOC_ENUMSTD
> mandatory and implemented at the core. So, V4L2 core will make this
> ioctl available for all drivers. The core implementattion will, however, 
> return -ENODATA  if the driver doesn't set video_device.tvnorms, indicating
> that standard video timings are not supported.
> 
> So, instead of the enclosed patch, the documentation should mention the
> standard ioctls, saying that G_STD/S_STD are optional, and ENUMSTD is
> mandatory. 

I don't think so. In v4l2-dev.c ENUMSTD is only enabled if the driver supports
the s_std ioctl:

if (is_vid || is_vbi || is_tch) {
/* ioctls valid for video or vbi */
if (ops->vidioc_s_std)
set_bit(_IOC_NR(VIDIOC_ENUMSTD), valid_ioctls);

And in case you are wondering: if you have two inputs, one SDTV and one HDTV, 
then
you have both s_std and s_dv_timings ioctls and if you switch to the HDTV input,
then tvnorms is set to 0, causing ENUMSTD to return -ENODATA. If you switch 
back,
then the driver will fill in tvnorms to something non-0.

Regards,

Hans

> 
> We could include a note about it may return -ENODATA, although the ENUMSTD
> documentation already states that it returns -ENODATA:
>   
> https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-enumstd.html
> 
> Regards,
> Mauro
> 
>> ---
>> diff --git a/Documentation/media/uapi/v4l/dev-capture.rst 
>> b/Documentation/media/uapi/v4l/dev-capture.rst
>> index 32b32055d070..4218742ab5d9 100644
>> --- a/Documentation/media/uapi/v4l/dev-capture.rst
>> +++ b/Documentation/media/uapi/v4l/dev-capture.rst
>> @@ -42,8 +42,8 @@ Video capture devices shall support :ref:`audio input 
>> `,
>>  :ref:`tuner`, :ref:`controls `,
>>  :ref:`cropping and scaling ` and
>>  :ref:`streaming parameter ` ioctls as needed. The
>> -:ref:`video input ` and :ref:`video standard `
>> -ioctls must be supported by all video capture devices.
>> +:ref:`video input ` ioctls must be supported by all video
>> +capture devices.
>>
>>
>>  Image Format Negotiation
>> diff --git a/Documentation/media/uapi/v4l/dev-output.rst 
>> b/Documentation/media/uapi/v4l/dev-output.rst
>> index 25ae8ec96fdf..342eb4931f5c 100644
>> --- a/Documentation/media/uapi/v4l/dev-output.rst
>> +++ b/Documentation/media/uapi/v4l/dev-output.rst
>> @@ -40,8 +40,8 @@ Video output devices shall support :ref:`audio output 
>> `,
>>  :ref:`modulator `, :ref:`controls `,
>>  :ref:`cropping and scaling ` and
>>  :ref:`streaming parameter ` ioctls as needed. The
>> -:ref:`video output ` and :ref:`video standard `
>> -ioctls must be supported by all video output devices.
>> +:ref:`video output ` ioctls must be supported by all video
>> +output devices.
>>
>>
>>  Image Format Negotiation
> 
> 
> 
> Thanks,
> Mauro
> 

Re: [PATCH] dev-capture.rst/dev-output.rst: video standards ioctls are optional

[Mauro Carvalho Chehab]

Em Wed, 29 Mar 2017 09:56:47 +0200
Hans Verkuil  escreveu:

> The documentation for video capture and output devices claims that the video 
> standard
> ioctls are required. This is not the case, they are only required for 
> PAL/NTSC/SECAM
> type inputs and outputs. Sensors do not implement this at all and e.g. HDMI 
> inputs
> implement the DV Timings ioctls.
> 
> Just drop the mention of 'video standard' ioctls.
> 
> Signed-off-by: Hans Verkuil 

This is an API change that has the potential of breaking userspace.

In the past, several applications were failing if VIDIOC_ENUMSTD ioctl is
not implemented. So, I remember we had this discussion before, but I don't
remember the dirty details anymore.

Yet, looking at the code, it seems that we ended by making VIDIOC_ENUMSTD
mandatory and implemented at the core. So, V4L2 core will make this
ioctl available for all drivers. The core implementattion will, however, 
return -ENODATA  if the driver doesn't set video_device.tvnorms, indicating
that standard video timings are not supported.

So, instead of the enclosed patch, the documentation should mention the
standard ioctls, saying that G_STD/S_STD are optional, and ENUMSTD is
mandatory. 

We could include a note about it may return -ENODATA, although the ENUMSTD
documentation already states that it returns -ENODATA:

https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-enumstd.html

Regards,
Mauro

> ---
> diff --git a/Documentation/media/uapi/v4l/dev-capture.rst 
> b/Documentation/media/uapi/v4l/dev-capture.rst
> index 32b32055d070..4218742ab5d9 100644
> --- a/Documentation/media/uapi/v4l/dev-capture.rst
> +++ b/Documentation/media/uapi/v4l/dev-capture.rst
> @@ -42,8 +42,8 @@ Video capture devices shall support :ref:`audio input 
> `,
>  :ref:`tuner`, :ref:`controls `,
>  :ref:`cropping and scaling ` and
>  :ref:`streaming parameter ` ioctls as needed. The
> -:ref:`video input ` and :ref:`video standard `
> -ioctls must be supported by all video capture devices.
> +:ref:`video input ` ioctls must be supported by all video
> +capture devices.
> 
> 
>  Image Format Negotiation
> diff --git a/Documentation/media/uapi/v4l/dev-output.rst 
> b/Documentation/media/uapi/v4l/dev-output.rst
> index 25ae8ec96fdf..342eb4931f5c 100644
> --- a/Documentation/media/uapi/v4l/dev-output.rst
> +++ b/Documentation/media/uapi/v4l/dev-output.rst
> @@ -40,8 +40,8 @@ Video output devices shall support :ref:`audio output 
> `,
>  :ref:`modulator `, :ref:`controls `,
>  :ref:`cropping and scaling ` and
>  :ref:`streaming parameter ` ioctls as needed. The
> -:ref:`video output ` and :ref:`video standard `
> -ioctls must be supported by all video output devices.
> +:ref:`video output ` ioctls must be supported by all video
> +output devices.
> 
> 
>  Image Format Negotiation



Thanks,
Mauro

Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Sakari Ailus]

Moi,

On 04/10/17 13:11, Mika Westerberg wrote:
> On Mon, Apr 10, 2017 at 12:59:36PM +0300, Sakari Ailus wrote:
>> Hi Mika and Laurent,
>>
>> On 04/10/17 12:21, Mika Westerberg wrote:
>>> On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote:
> My ACPI knowledge is limited, but don't ACPI nodes have 4 character names 
> that 
> can be combined in a string to create a full path ?

 There is something, yes, but the ACPI framework currently has no such
 functionality. I believe it could be implemented though. Cc Mika.
>>>
>>> All ACPI node names are 32-bit integers and those are combined to form a
>>> path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be
>>> larger than 4 chars, though.
>>
>> On OF, each node has a full_node string attached to it. You could
>> produce a similar string on ACPI, it is not currently done. Adding such
>> a string to each fwnode would require some extra memory as well. I
>> wonder if that could be a Kconfig option.
>>
>> It would help debugging though.
>>
>> Providing this information to the user space has been proposed as well:
>> Devicetree spec defines the syntax for such strings. The user can use
>> that information for recognising a particular device in the system.
>>
>> The ACPI spec does, too, but it is limited to ACPI nodes and does not
>> address hierarchical data extensions. We'd define the syntax for those
>> ourselves.
>>
>> Mika: what do you think?
> 
> There is a function acpi_get_name() which you can use to extract the
> full name of the node. Why not investigate how to use that instead of
> duplicating the name in an ACPI node.
> 

acpi_get_name() would obviously be needed to produce such a string in
the first place.

acpi_get_name() puts the string to an existing buffer so it cannot be
used as such to return a pointer to a string (e.g. to be used for
snprintf()). Also, it only contains the device path of the device. The
data extension path matters here, too.

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Mika Westerberg]

On Mon, Apr 10, 2017 at 12:59:36PM +0300, Sakari Ailus wrote:
> Hi Mika and Laurent,
> 
> On 04/10/17 12:21, Mika Westerberg wrote:
> > On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote:
> >>> My ACPI knowledge is limited, but don't ACPI nodes have 4 character names 
> >>> that 
> >>> can be combined in a string to create a full path ?
> >>
> >> There is something, yes, but the ACPI framework currently has no such
> >> functionality. I believe it could be implemented though. Cc Mika.
> > 
> > All ACPI node names are 32-bit integers and those are combined to form a
> > path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be
> > larger than 4 chars, though.
> 
> On OF, each node has a full_node string attached to it. You could
> produce a similar string on ACPI, it is not currently done. Adding such
> a string to each fwnode would require some extra memory as well. I
> wonder if that could be a Kconfig option.
> 
> It would help debugging though.
> 
> Providing this information to the user space has been proposed as well:
> Devicetree spec defines the syntax for such strings. The user can use
> that information for recognising a particular device in the system.
> 
> The ACPI spec does, too, but it is limited to ACPI nodes and does not
> address hierarchical data extensions. We'd define the syntax for those
> ourselves.
> 
> Mika: what do you think?

There is a function acpi_get_name() which you can use to extract the
full name of the node. Why not investigate how to use that instead of
duplicating the name in an ACPI node.

Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Sakari Ailus]

Hi Mika and Laurent,

On 04/10/17 12:21, Mika Westerberg wrote:
> On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote:
>>> My ACPI knowledge is limited, but don't ACPI nodes have 4 character names 
>>> that 
>>> can be combined in a string to create a full path ?
>>
>> There is something, yes, but the ACPI framework currently has no such
>> functionality. I believe it could be implemented though. Cc Mika.
> 
> All ACPI node names are 32-bit integers and those are combined to form a
> path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be
> larger than 4 chars, though.

On OF, each node has a full_node string attached to it. You could
produce a similar string on ACPI, it is not currently done. Adding such
a string to each fwnode would require some extra memory as well. I
wonder if that could be a Kconfig option.

It would help debugging though.

Providing this information to the user space has been proposed as well:
Devicetree spec defines the syntax for such strings. The user can use
that information for recognising a particular device in the system.

The ACPI spec does, too, but it is limited to ACPI nodes and does not
address hierarchical data extensions. We'd define the syntax for those
ourselves.

Mika: what do you think?

On omap3isp and other drivers --- I think the solution for now should be
to assume OF instead. These drivers will be used on OF platforms only
anyway.

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Mika Westerberg]

On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote:
> > My ACPI knowledge is limited, but don't ACPI nodes have 4 character names 
> > that 
> > can be combined in a string to create a full path ?
> 
> There is something, yes, but the ACPI framework currently has no such
> functionality. I believe it could be implemented though. Cc Mika.

All ACPI node names are 32-bit integers and those are combined to form a
path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be
larger than 4 chars, though.

Re: [PATCH v3 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series

[Hans Verkuil]

On 04/04/2017 05:44 PM, Hugues Fruchet wrote:
> This patchset introduces a basic support for Digital Camera Memory Interface
> (DCMI) of STMicroelectronics STM32 SoC series.
> 
> This first basic support implements RGB565 & YUV frame grabbing.
> Cropping and JPEG support will be added later on.
> 
> This has been tested on STM324x9I-EVAL evaluation board embedding
> an OV2640 camera sensor.
> 
> This driver depends on:
>   - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers 
> http://www.spinics.net/lists/linux-media/msg113480.html
> 
> ===
> = history =
> ===
> version 3:
>   - stm32-dcmi: Add "Reviewed-by: Hans Verkuil "
>   - dt-bindings: Fix remarks from Rob Herring:
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg110956.html
> 
> version 2:
>   - Fix a Kbuild warning in probe:
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg110678.html
>   - Fix a warning in dcmi_queue_setup()
>   - dt-bindings: warn on sensor signals level inversion in board example
>   - Typos fixing
> 
> version 1:
>   - Initial submission
> 
> ===
> = v4l2-compliance =
> ===
> Below is the v4l2-compliance report for this current version of the DCMI 
> camera interface.
> v4l2-compliance has been built from v4l-utils-1.12.3.

Please test with 'v4l2-compliance -s -f' as well and mail me the output of
that test.

Once you have the Acks for the DT/bindings patches just let me know and I'll
make a pull request.

Regards,

Hans

> 
> v4l2-compliance SHA   : f5f45e17ee98a0ebad7836ade2b34ceec909d751
> 
> Driver Info:
> Driver name   : stm32-dcmi
> Card type : STM32 Digital Camera Memory Int
> Bus info  : platform:dcmi
> Driver version: 4.11.0
> Capabilities  : 0x8521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video0 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> 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: 3 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK (Not Supported)
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK
> 
> 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 VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> test VIDIOC_EXPBUF: OK
> 
> Test input 0:
> 
> Streaming ioctls:
> test 

Re: [git:media_tree/master] [media] gspca: konica: add missing endpoint sanity check

[Hans Verkuil]

On 04/10/2017 10:18 AM, Johan Hovold wrote:
> On Wed, Apr 05, 2017 at 06:07:31PM +, Mauro Carvalho Chehab wrote:
>> This is an automatic generated email to let you know that the
>> following patch were queued:
>>
>> Subject: [media] gspca: konica: add missing endpoint sanity check
>> Author:  Johan Hovold 
>> Date:Mon Mar 13 09:53:59 2017 -0300
> 
> This was the sixth and final patch in a series; are you picking up the
> first five as well?

Yes. Those are in another pull request that hasn't been merged yet.

I've no idea why this patch ended up in a different pull request from the
others.

Regards,

Hans

Re: [PATCH 09/12] [media] s5p-mfc: use setup_timer

[Sylwester Nawrocki]

On 04/09/2017 03:34 AM, Geliang Tang wrote:

Use setup_timer() instead of init_timer() to simplify the code.

Signed-off-by: Geliang Tang 


Applied, thanks.

Re: [git:media_tree/master] [media] gspca: konica: add missing endpoint sanity check

[Johan Hovold]

On Wed, Apr 05, 2017 at 06:07:31PM +, Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the
> following patch were queued:
> 
> Subject: [media] gspca: konica: add missing endpoint sanity check
> Author:  Johan Hovold 
> Date:Mon Mar 13 09:53:59 2017 -0300

This was the sixth and final patch in a series; are you picking up the
first five as well?

Thanks,
Johan

[PATCH for v4.12] v4l2-tpg: don't clamp XV601/709 to lim range

[Hans Verkuil]

The XV601/709 encodings are special: they signal limited range, but use the 
full range
to encode a larger gamut with R', G' and B' values outside the [0-1] range.

So don't clamp to limited range for these two encodings.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index e47b46e2d26c..3dd22da7e17d 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -927,7 +927,14 @@ static void precalculate_color(struct tpg_data *tpg, int k)
y >>= 4;
cb >>= 4;
cr >>= 4;
-   if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
+   /*
+* XV601/709 use the header/footer margins to encode R', G'
+* and B' values outside the range [0-1]. So do not clamp
+* XV601/709 values.
+*/
+   if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE &&
+   tpg->real_ycbcr_enc != V4L2_YCBCR_ENC_XV601 &&
+   tpg->real_ycbcr_enc != V4L2_YCBCR_ENC_XV709) {
y = clamp(y, 16, 235);
cb = clamp(cb, 16, 240);
cr = clamp(cr, 16, 240);

[PATCH for v4.12] videodev2.h: fix outdated comment

[Hans Verkuil]

The XV601/709 Y'CbCr encoding was changed to limited range, but the comment
still indicates full range.

Signed-off-by: Hans Verkuil 
---
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 316be62f3a45..5d842a61d94a 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -362,8 +362,7 @@ enum v4l2_quantization {
/*
 * The default for R'G'B' quantization is always full range, except
 * for the BT2020 colorspace. For Y'CbCr the quantization is always
-* limited range, except for COLORSPACE_JPEG, XV601 or XV709: those
-* are full range.
+* limited range, except for COLORSPACE_JPEG: this is full range.
 */
V4L2_QUANTIZATION_DEFAULT = 0,
V4L2_QUANTIZATION_FULL_RANGE  = 1,