Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

Hi,

On Mon, Jan 29, 2018 at 03:34:02PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 29, 2018 at 10:25 AM, Linus Walleij
>  wrote:
> > On Mon, Jan 29, 2018 at 9:25 AM, Maxime Ripard
> >  wrote:
> >> On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote:
> >> However, in DT systems, that
> >> field is filled only with the parent's node dma-ranges property. In
> >> our case, and since the DT parenthood is based on the "control" bus,
> >> and not the "data" bus, our parent node would be the AXI bus, and not
> >> the memory bus that enforce those constraints.
> >>
> >> And other devices doing DMA through regular DMA accesses won't have
> >> that mapping, so we definitely shouldn't enforce it for all the
> >> devices there, but only the one connected to the separate memory bus.
> >>
> >> tl; dr: the DT is not really an option to store that info.
> >>
> >> I suggested setting dma_pfn_offset at probe, but Arnd didn't seem too
> >> fond of that approach either at the time.
> >>
> >> So, well, I guess we could do better. We just have no idea how :)
> >
> > Usually of Arnd cannot suggest something smart, neither can I :(
> >
> > If some aspect of the memory layout of the system *really* doesn't
> > fit into DT because of the assumptions that DT is doing about
> > how systems work, we have a problem.
> >
> > Is the problem that DT's model assumes that devices have one and
> > only one data port to the system memory, and that is how it
> > populates the Linux devices?
> >
> > I guess, if nothing else works, I would use auxdata in the board file.
> > It is our definitive last resort when DT doesn't hold.
> >
> > I.e. I would go into struct of_dev_auxdata
> > (from ) and add a
> > dma_pfn_offset field that gets set into the device's dma_pfn_offset
> > in drivers/of/platform.c overriding anything else and use that to hammer
> > it down in the boardfile.
> >
> > But I bet some DT people are going to have other ideas.
> 
> At one point we had discussed adding a 'dma-masters' property that
> lists all the buses on which a device can be a dma master, and
> the respective properties of those masters (iommu, coherency,
> offset, ...).
>
> IIRC at the time we decided that we could live without that complexity,
> but perhaps we cannot.

Are you talking about this ?
https://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/dma/dma.txt#L41

It doesn't seem to be related to that issue to me. And in our
particular cases, all the devices are DMA masters, the RAM is just
mapped to another address.

> Another local hack that we can do here is to have two separate
> device nodes and let the device driver bind to one device and then
> look up the other one through a phandle to look up a platform_device
> for it, which it can then use with the DMA mapping interface.

We have multiple devices doing that, a couple of them already merged
(mostly on the display side). I'd rather not do that.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 8/8] platform: vivid-cec: fix potential integer overflow in vivid_cec_pin_adap_events

[Hans Verkuil]

Hi Gustavo,

On 01/30/2018 01:33 AM, Gustavo A. R. Silva wrote:
> Cast len to const u64 in order to avoid a potential integer
> overflow. This variable is being used in a context that expects
> an expression of type const u64.
> 
> Addresses-Coverity-ID: 1454996 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/media/platform/vivid/vivid-cec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/vivid/vivid-cec.c 
> b/drivers/media/platform/vivid/vivid-cec.c
> index b55d278..30240ab 100644
> --- a/drivers/media/platform/vivid/vivid-cec.c
> +++ b/drivers/media/platform/vivid/vivid-cec.c
> @@ -83,7 +83,7 @@ static void vivid_cec_pin_adap_events(struct cec_adapter 
> *adap, ktime_t ts,
>   if (adap == NULL)
>   return;
>   ts = ktime_sub_us(ts, (CEC_TIM_START_BIT_TOTAL +
> -len * 10 * CEC_TIM_DATA_BIT_TOTAL));
> +(const u64)len * 10 * CEC_TIM_DATA_BIT_TOTAL));

This makes no sense. Certainly the const part is pointless. And given that
len is always <= 16 there definitely is no overflow.

I don't really want this cast in the code.

Sorry,

Hans

>   cec_queue_pin_cec_event(adap, false, ts);
>   ts = ktime_add_us(ts, CEC_TIM_START_BIT_LOW);
>   cec_queue_pin_cec_event(adap, true, ts);
> 

Re: [RFC PATCH 5/8] media: Document the media request API

[Alexandre Courbot]

On Tue, Jan 30, 2018 at 1:04 AM, Hans Verkuil  wrote:
> On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
>> From: Laurent Pinchart 
>>
>> The media request API is made of a new ioctl to implement request
>> management. Document it.
>>
>> Signed-off-by: Laurent Pinchart 
>> [acour...@chromium.org: adapt for newest API]
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  Documentation/media/uapi/mediactl/media-funcs.rst  |   1 +
>>  .../media/uapi/mediactl/media-ioc-request-cmd.rst  | 140 
>> +
>>  2 files changed, 141 insertions(+)
>>  create mode 100644 
>> Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst
>>
>> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst 
>> b/Documentation/media/uapi/mediactl/media-funcs.rst
>> index 076856501cdb..e3a45d82ffcb 100644
>> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
>> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
>> @@ -15,4 +15,5 @@ Function Reference
>>  media-ioc-g-topology
>>  media-ioc-enum-entities
>>  media-ioc-enum-links
>> +media-ioc-request-cmd
>>  media-ioc-setup-link
>> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst 
>> b/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst
>> new file mode 100644
>> index ..17223e8170e9
>> --- /dev/null
>> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst
>> @@ -0,0 +1,140 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _media_ioc_request_cmd:
>> +
>> +***
>> +ioctl MEDIA_IOC_REQUEST_CMD
>> +***
>> +
>> +Name
>> +
>> +
>> +MEDIA_IOC_REQUEST_CMD - Manage media device requests
>> +
>> +
>> +Synopsis
>> +
>> +
>> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_CMD, struct 
>> media_request_cmd *argp )
>> +:name: MEDIA_IOC_REQUEST_CMD
>> +
>> +
>> +Arguments
>> +=
>> +
>> +``fd``
>> +File descriptor returned by :ref:`open() `.
>> +
>> +``argp``
>> +
>> +
>> +Description
>> +===
>> +
>> +The MEDIA_IOC_REQUEST_CMD ioctl allow applications to manage media device
>> +requests. A request is an object that can group media device configuration
>> +parameters, including subsystem-specific parameters, in order to apply all 
>> the
>> +parameters atomically. Applications are responsible for allocating and
>> +deleting requests, filling them with configuration parameters submitting 
>> them.
>> +
>> +Request operations are performed by calling the MEDIA_IOC_REQUEST_CMD ioctl
>> +with a pointer to a struct :c:type:`media_request_cmd` with the cmd field 
>> set
>> +to the appropriate command. :ref:`media-request-command` lists the commands
>> +supported by the ioctl.
>> +
>> +The struct :c:type:`media_request_cmd` request field contains the file
>> +descriptorof the request on which the command operates. For the
>> +``MEDIA_REQ_CMD_ALLOC`` command the field is set to zero by applications and
>> +filled by the driver. For all other commands the field is set by 
>> applications
>> +and left untouched by the driver.
>> +
>> +To allocate a new request applications use the ``MEDIA_REQ_CMD_ALLOC``
>> +command. The driver will allocate a new request and return its ID in the
>
> ID -> FD

Indeed, this is a leftover from the original documentation.

>
>> +request field.
>> +
>> +Requests are reference-counted. A newly allocated request is referenced
>> +by the returned file descriptor, and can be later referenced by
>> +subsystem-specific operations. Requests will thus be automatically deleted
>> +when they're not longer used after the returned file descriptor is closed.
>> +
>> +If a request isn't needed applications can delete it by calling ``close()``
>> +on it. The driver will drop the file handle reference. The request will not
>> +be usable through the MEDIA_IOC_REQUEST_CMD ioctl anymore, but will only be
>> +deleted when the last reference is released. If no other reference exists 
>> when
>> +``close()`` is invoked the request will be deleted immediately.
>> +
>> +After creating a request applications should fill it with configuration
>> +parameters. This is performed through subsystem-specific request APIs 
>> outside
>> +the scope of the media controller API. See the appropriate subsystem APIs 
>> for
>> +more information, including how they interact with the MEDIA_IOC_REQUEST_CMD
>> +ioctl.
>> +
>> +Once a request contains all the desired configuration parameters it can be
>> +submitted using the ``MEDIA_REQ_CMD_SUBMIT`` command. This will let the
>> +buffers queued for the request be passed to their respective drivers, which
>> +will then apply the request's parameters before processing them.
>> +
>> +Once a request has been queued applications are not allowed to modify its
>> +configuration parameters until the request has been fully processed. Any
>> +attempt to do so 

Re: [RFC PATCH 0/8] [media] Request API, take three

[Alexandre Courbot]

Hi Hans,

On Mon, Jan 29, 2018 at 8:21 PM, Hans Verkuil  wrote:
> On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
>> Howdy. Here is your bi-weekly request API redesign! ;)
>>
>> Again, this is a simple version that only implements the flow of requests,
>> without applying controls. The intent is to get an agreement on a base to 
>> work
>> on, since the previous versions went straight back to the redesign board.
>>
>> Highlights of this version:
>>
>> * As requested by Hans, request-bound buffers are now passed earlier to 
>> drivers,
>> as early as the request itself is submitted. Doing it earlier is not be 
>> useful
>> since the driver would not know the state of the request, and thus cannot do
>> anything with the buffer. Drivers are now responsible for applying request
>> parameters themselves.
>>
>> * As a consequence, there is no such thing as a "request queue" anymore. The
>> flow of buffers decides the order in which requests are processed. Individual
>> devices of the same pipeline can implement synchronization if needed, but 
>> this
>> is beyond this first version.
>>
>> * VB2 code is still a bit shady. Some of it will interfere with the fences
>> series, so I am waiting for the latter to land to do it properly.
>>
>> * Requests that are not yet submitted effectively act as fences on the 
>> buffers
>> they own, resulting in the buffer queue being blocked until the request is
>> submitted. An alternate design would be to only block the
>> not-submitted-request's buffer and let further buffers pass before it, but 
>> since
>> buffer order is becoming increasingly important I have decided to just block 
>> the
>> queue. This is open to discussion though.
>
> I don't think we should mess with the order.

Agreed, let's keep it that way then.

>
>>
>> * Documentation! Also described usecases for codec and simple (i.e. not part 
>> of
>> a complex pipeline) capture device.
>
> I'll concentrate on reviewing that.
>
>>
>> Still remaining to do:
>>
>> * As pointed out by Hans on the previous revision, do not assume that drivers
>> using v4l2_fh have a per-handle state. I have not yet found a good way to
>> differenciate both usages.
>
> I suspect we need to add a flag or something for this.

I hope we don't need to, let's see if I can find a pattern...

>
>> * Integrate Hans' patchset for control handling: as said above, this is 
>> futile
>> unless we can agree on the basic design, which I hope we can do this time.
>> Chrome OS needs this really badly now and will have to move forward no matter
>> what, so I hope this will be considered good enough for a common base of 
>> work.
>
> I am not sure there is any reason to not move forward with the control 
> handling.
> You need this anyway IMHO, regardless of any public API considerations.

Only reasons are my lazyness and because I wanted to focus on the
request flow first. But you're right. I have a version with your
control framework changes integrated (they worked on the first attempt
btw! :)), let me create a clean patchset from this and send another
RFC.

>
>> A few thoughts/questions that emerged when writing this patchset:
>>
>> * Since requests are exposed as file descriptors, we could easily move the
>> MEDIA_REQ_CMD_SUBMIT and MEDIA_REQ_CMD_REININT commands as ioctls on the
>> requests themselves, instead of having to perform them on the media device 
>> that
>> provided the request in the first place. That would add a bit more 
>> flexibility
>> if/when passing requests around and means the media device only needs to 
>> handle
>> MEDIA_REQ_CMD_ALLOC. Conceptually speaking, this seems to make sense to me.
>> Any comment for/against that?
>
> Makes sense IMHO.

Glad to hear it, that was my preferred design. :)

>
>> * For the codec usecase, I have experimented a bit marking CAPTURE buffers 
>> with
>> the request FD that produced them (vim2m acts that way). This seems to work
>> well, however FDs are process-local and could be closed before the CAPTURE
>> buffer is dequeued, rendering that information less meaningful, if not
>> dangerous.
>
> I don't follow this. Once the fd is passed to the kernel its refcount should 
> be
> increased so the data it represents won't be released if userspace closes the 
> fd.

The refcount of the request is increased. The refcount of the FD is
not, since it is only a userspace reference to the request.

>
> Obviously if userspace closes the fd it cannot do anything with it anymore, 
> but
> it shouldn't be 'dangerous' AFAICT.

It userspace later gets that closed FD back from a DQBUF call, and
decides to use it again, then we would have a problem. I agree that it
is userspace responsibility to be careful here, but making things
foolproof never hurts.

>
>> Wouldn't it be better/safer to use a global request ID for
>> such information instead? That ID would be returned upon MEDIA_REQ_CMD_ALLOC 
>> so
>> user-space knows which request ID a FD refers to.
>
> I think it is not a good idea to 

Re: [RFC PATCH 6/8] v4l2: document the request API interface

[Alexandre Courbot]

On Tue, Jan 30, 2018 at 1:03 AM, Hans Verkuil  wrote:
> On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
>> Document how the request API can be used along with the existing V4L2
>> interface.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  Documentation/media/uapi/v4l/buffer.rst  |  10 +-
>>  Documentation/media/uapi/v4l/common.rst  |   1 +
>>  Documentation/media/uapi/v4l/request-api.rst | 194 
>> +++
>>  Documentation/media/uapi/v4l/vidioc-qbuf.rst |  21 +++
>>  4 files changed, 223 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/media/uapi/v4l/request-api.rst
>>
>> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
>> b/Documentation/media/uapi/v4l/buffer.rst
>> index ae6ee73f151c..9d082784081d 100644
>> --- a/Documentation/media/uapi/v4l/buffer.rst
>> +++ b/Documentation/media/uapi/v4l/buffer.rst
>> @@ -301,10 +301,14 @@ struct v4l2_buffer
>>   elements in the ``planes`` array. The driver will fill in the
>>   actual number of valid elements in that array.
>>  * - __u32
>> -  - ``reserved2``
>> +  - ``request_fd``
>>-
>> -  - A place holder for future extensions. Drivers and applications
>> - must set this to 0.
>> +  - The file descriptor of the request associated with this buffer.
>> + user-space can set this when calling :ref:`VIDIOC_QBUF`, and drivers
>> + will return the request used when processing a buffer (if any) upon
>> + :ref:`VIDIOC_DQBUF`.
>> +
>> + A value of 0 means the buffer is not associated with any request.
>>  * - __u32
>>- ``reserved``
>>-
>> diff --git a/Documentation/media/uapi/v4l/common.rst 
>> b/Documentation/media/uapi/v4l/common.rst
>> index 13f2ed3fc5a6..a4aa0059d45a 100644
>> --- a/Documentation/media/uapi/v4l/common.rst
>> +++ b/Documentation/media/uapi/v4l/common.rst
>> @@ -44,3 +44,4 @@ applicable to all devices.
>>  crop
>>  selection-api
>>  streaming-par
>> +request-api
>> diff --git a/Documentation/media/uapi/v4l/request-api.rst 
>> b/Documentation/media/uapi/v4l/request-api.rst
>> new file mode 100644
>> index ..a758a5fd3ca0
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/request-api.rst
>> @@ -0,0 +1,194 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _media-request-api:
>> +
>> +Request API
>> +===
>> +
>> +The Request API has been designed to allow V4L2 to deal with requirements of
>> +modern IPs (stateless codecs, MIPI cameras, ...) and APIs (Android Codec 
>> v2).
>> +One such requirement is the ability for devices belonging to the same 
>> pipeline
>> +to reconfigure and collaborate closely on a per-frame basis. Another is
>> +efficient support of stateless codecs, which need per-frame controls to be 
>> set
>> +asynchronously in order to be efficiently used.
>> +
>> +Supporting these features without the Request API is possible but terribly
>> +inefficient: user-space would have to flush all activity on the media 
>> pipeline,
>> +reconfigure it for the next frame, queue the buffers to be processed with 
>> that
>> +configuration, and wait until they are all available for dequeing before
>> +considering the next frame. This defeats the purpose of having buffer queues
>> +since in practice only one buffer would be queued at a time.
>> +
>> +The Request API allows a specific configuration of the pipeline (media
>> +controller topology + controls for each device) to be associated with 
>> specific
>> +buffers. The parameters are applied by each participating device as buffers
>> +associated to a request flow in. This allows user-space to schedule several
>> +tasks ("requests") with different parameters in advance, knowing that the
>> +parameters will be applied when needed to get the expected result. Controls
>> +values at the time of request completion are also available for reading.
>> +
>> +Usage
>> +=
>> +
>> +The Request API is used on top of standard media controller and V4L2 calls,
>> +which are augmented with an extra ``request_fd`` parameter. All operations 
>> on
>> +requests themselves are performed using the command parameter of the
>> +:c:func:`MEDIA_IOC_REQUEST_CMD` ioctl.
>> +
>> +Allocation
>> +--
>> +
>> +User-space allocates requests using the ``MEDIA_REQ_CMD_ALLOC`` command on
>> +an opened media device. This returns a file descriptor representing the
>> +request. Typically, several such requests will be allocated.
>> +
>> +Request Preparation
>> +---
>> +
>> +Standard V4L2 ioctls can then receive a request file descriptor to express 
>> the
>> +fact that the ioctl is part of said request, and is not to be applied
>> +immediately. V4L2 ioctls supporting this are :c:func:`VIDIOC_S_EXT_CTRLS` 
>> and
>> +:c:func:`VIDIOC_QBUF`. Controls set with a request parameter are stored 
>> instead
>> +of being immediately applied, and queued buffers will block the buffer queue
>> +until the request 

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 Jan 30 05:00:20 CET 2018
media-tree git hash:4852fdca8818972d0ea5b5ce7114da628f9954a4
media_build git hash:   d17383327f00d45e6c07161876fb4f3d9d9358e1
v4l-utils git hash: c2cc9e17b1411865d40a0e7d3ab027204fc0cf19
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3911-g6f737e1f
smatch version: v0.5.0-3911-g6f737e1f
host hardware:  x86_64
host os:4.14.0-364

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: 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: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: WARNINGS
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: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: 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.26-i686: ERRORS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12.1-i686: WARNINGS
linux-4.13-i686: WARNINGS
linux-4.14-i686: WARNINGS
linux-4.15-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: WARNINGS
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: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: 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.26-x86_64: ERRORS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: WARNINGS
linux-4.14-x86_64: WARNINGS
linux-4.15-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
smatch: OK

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

Re: [RFC PATCH 1/9] media: add request API core and UAPI

[Alexandre Courbot]

Hi Sakari, thanks for the review!

The version you reviewed is not the latest one, but I suppose most of
your comments still apply.

On Fri, Jan 26, 2018 at 5:39 PM, Sakari Ailus  wrote:
> Hi Alexandre,
>
> I remember it was discussed that the work after the V4L2 jobs API would
> continue from the existing request API patches. I see that at least the
> rather important support for events is missing in this version. Why was it
> left out?

Request completion is signaled by polling on the request FD, so we
don't need to rely on V4L2 events to signal this anymore. If we want
to signal different kinds of events on requests we could implement a
more sophisticated event system on top of that, but for our current
needs polling is sufficient.

What other kind of event besides completion could we want to deliver
to user-space from a request?

>
> I also see that variable size IOCTL argument support is no longer included.

Do we need this for the request API?

>
> On Fri, Dec 15, 2017 at 04:56:17PM +0900, Alexandre Courbot wrote:
>> The request API provides a way to group buffers and device parameters
>> into units of work to be queued and executed. This patch introduces the
>> UAPI and core framework.
>>
>> This patch is based on the previous work by Laurent Pinchart. The core
>> has changed considerably, but the UAPI is mostly untouched.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/media/Makefile   |   3 +-
>>  drivers/media/media-device.c |   6 +
>>  drivers/media/media-request.c| 390 
>> +++
>>  drivers/media/v4l2-core/v4l2-ioctl.c |   2 +-
>>  include/media/media-device.h |   3 +
>>  include/media/media-entity.h |   6 +
>>  include/media/media-request.h| 269 
>>  include/uapi/linux/media.h   |  11 +
>>  8 files changed, 688 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/media/media-request.c
>>  create mode 100644 include/media/media-request.h
>>
>> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
>> index 594b462ddf0e..985d35ec6b29 100644
>> --- a/drivers/media/Makefile
>> +++ b/drivers/media/Makefile
>> @@ -3,7 +3,8 @@
>>  # Makefile for the kernel multimedia device drivers.
>>  #
>>
>> -media-objs   := media-device.o media-devnode.o media-entity.o
>> +media-objs   := media-device.o media-devnode.o media-entity.o \
>> +media-request.o
>>
>>  #
>>  # I2C drivers should come before other drivers, otherwise they'll fail
>> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
>> index e79f72b8b858..045cec7d2de9 100644
>> --- a/drivers/media/media-device.c
>> +++ b/drivers/media/media-device.c
>> @@ -32,6 +32,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #ifdef CONFIG_MEDIA_CONTROLLER
>>
>> @@ -407,6 +408,7 @@ static const struct media_ioctl_info ioctl_info[] = {
>>   MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
>> MEDIA_IOC_FL_GRAPH_MUTEX),
>>   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
>> MEDIA_IOC_FL_GRAPH_MUTEX),
>>   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
>> MEDIA_IOC_FL_GRAPH_MUTEX),
>> + MEDIA_IOC(REQUEST_CMD, media_device_request_cmd, 0),
>>  };
>>
>>  static long media_device_ioctl(struct file *filp, unsigned int cmd,
>> @@ -688,6 +690,10 @@ EXPORT_SYMBOL_GPL(media_device_init);
>>
>>  void media_device_cleanup(struct media_device *mdev)
>>  {
>> + if (mdev->req_queue) {
>> + mdev->req_queue->ops->release(mdev->req_queue);
>> + mdev->req_queue = NULL;
>> + }
>>   ida_destroy(>entity_internal_idx);
>>   mdev->entity_internal_idx_max = 0;
>>   media_graph_walk_cleanup(>pm_count_walk);
>> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
>> new file mode 100644
>> index ..15dc65ddfe41
>> --- /dev/null
>> +++ b/drivers/media/media-request.c
>> @@ -0,0 +1,390 @@
>> +/*
>> + * Request and request queue base management
>> + *
>> + * Copyright (C) 2017, The Chromium OS Authors.  All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>
> Alphabetic order, please.

Fixed.

>
>> +
>> +const struct file_operations request_fops;
>> +
>> +void media_request_get(struct media_request *req)
>
> Please return the media request, too.

Fixed.

>
>> +{
>> + kref_get(>kref);
>> +}
>> 

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

[Yong]

Hi,

On Mon, 29 Jan 2018 13:49:14 -0800
Randy Dunlap  wrote:

> On 01/29/2018 01:21 AM, Yong Deng wrote:
> > Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> > interface and CSI1 is used for parallel interface. This is not
> > documented in datasheet but by test and guess.
> > 
> > This patch implement a v4l2 framework driver for it.
> > 
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> > 
> > Tested-by: Maxime Ripard 
> > Signed-off-by: Yong Deng 
> > ---
> 
> 
> A previous version (I think v6) had a build error with the use of
> PHYS_OFFSET, so Kconfig was modified to depend on ARM and ARCH_SUNXI
> (one of which seems to be overkill).  As is here, the COMPILE_TEST piece is
> meaningless for all arches except ARM.  If you care enough for COMPILE_TEST
> (and I would), then you could make COMPILE_TEST useful on any arch by
> removing the "depends on ARM" (the ARCH_SUNXI takes care of that) and by
> having an alternate value for PHYS_OFFSET, like so:
> 
> +#if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
> +#define PHYS_OFFSET  0
> +#endif
> 
> With those 2 changes, the driver builds for me on x86_64.

I have considered this method.
But it's so sick to put these code in dirver (for my own). I mean 
this is meaningless for the driver itself and make people confused.

I grepped the driver/ code and I found many drivers writing Kconfig
like this. For example:
ARM && COMPILE_TEST
MIPS && COMPILE_TEST
PPC64 && COMPILE_TEST

BTW, for my own, I do not care about COMPILE_TEST.

> 
> > diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
> > b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> > new file mode 100644
> > index 000..f80c965
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> > @@ -0,0 +1,10 @@
> > +config VIDEO_SUN6I_CSI
> > +   tristate "Allwinner V3s Camera Sensor Interface driver"
> > +   depends on ARM
> > +   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> > +   depends on ARCH_SUNXI || COMPILE_TEST
> > +   select VIDEOBUF2_DMA_CONTIG
> > +   select REGMAP_MMIO
> > +   select V4L2_FWNODE
> > +   ---help---
> > +  Support for the Allwinner Camera Sensor Interface Controller on V3s.
> 
> thanks,
> -- 
> ~Randy


Thanks,
Yong

Re: Regression in VB2 alloc prepare/finish balancing with em28xx/au0828

[Devin Heitmueller]

Hello Sakari,

Thanks for taking the time to investigate.  See comments inline.

On Sun, Jan 28, 2018 at 5:23 PM, Sakari Ailus
 wrote:
> Hi Devin,
>
> On Sun, Jan 28, 2018 at 09:12:44AM -0500, Devin Heitmueller wrote:
>> Hello all,
>>
>> I recently updated to the latest kernel, and I am seeing the following
>> dumped to dmesg with both au0828 and em28xx based devices whenever I
>> exit tvtime (my kernel is compiled with CONFIG_VIDEO_ADV_DEBUG=y by
>> default):
>
> Thanks for reporting this. Would you be able to provide the full dmesg,
> with VB2 debug parameter set to 2?

Output can be found at https://pastebin.com/nXS7MTJH

> I can't immediately see how you'd get this, well, without triggering a
> kernel warning or two. The code is pretty complex though.

If this is something I screwed up when I did the VB2 port for em28xx
several years ago, point me in the right direction and I'll see what I
can do.  However given we're seeing it with multiple drivers, this
feels like some subtle issue inside videobuf2.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

RE: [PATCH v4] media: dw9807: Add dw9807 vcm driver

[Yeh, Andy]

Please ignore this. This is the wrong patch which has been obsoleted. 

-Original Message-
From: Yeh, Andy 
Sent: Tuesday, January 30, 2018 12:35 AM
To: linux-media@vger.kernel.org
Cc: Yeh, Andy ; sakari.ai...@linux.intel.com; 
tf...@chromium.org; Chiang, AlanX 
Subject: [PATCH v4] media: dw9807: Add dw9807 vcm driver

From: Alan Chiang 

DW9807 is a 10 bit DAC from Dongwoon, designed for linear control of voice coil 
motor.

This driver creates a V4L2 subdevice and provides control to set the desired 
focus.

Signed-off-by: Andy Yeh 
---
since v1:
- changed author.
since v2:
- addressed outstanding comments.
- enabled sequential write to update 2 registers in a single transaction.
since v3:
- addressed comments for v3.
- Remove redundant codes and declar some variables as constant variable.
- separate DT binding to another patch 

 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 ++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 349 +
 4 files changed, 367 insertions(+)
 create mode 100644 drivers/media/i2c/dw9807.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..a339bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4385,6 +4385,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/dw9714.c
 
+DONGWOON DW9807 LENS VOICE COIL DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/dw9807.c
+
 DOUBLETALK DRIVER
 M: "James R. Van Zandt" 
 L: blinux-l...@redhat.com
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 
cb5d7ff..fd01842 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -325,6 +325,16 @@ config VIDEO_DW9714
  capability. This is designed for linear control of
  voice coil motors, controlled via I2C serial interface.
 
+config VIDEO_DW9807
+   tristate "DW9807 lens voice coil support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the DW9807 camera lens voice coil.
+ DW9807 is a 10 bit DAC with 100mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
 config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 
548a9ef..1b62639 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
 obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
 obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
 obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
+obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
 obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
 obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
 obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o diff --git 
a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c new file mode 100644 
index 000..4d243db
--- /dev/null
+++ b/drivers/media/i2c/dw9807.c
@@ -0,0 +1,349 @@
+// Copyright (C) 2018 Intel Corporation // SPDX-License-Identifier: 
+GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW9807_NAME"dw9807"
+#define DW9807_MAX_FOCUS_POS   1023
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position  */
+#define DW9807_FOCUS_STEPS 1
+/*
+ * This acts as the minimum granularity of lens movement.
+ * Keep this value power of 2, so the control steps can be
+ * uniformly adjusted for gradual lens movement, with desired
+ * number of control steps.
+ */
+#define DW9807_CTRL_STEPS  16
+#define DW9807_CTRL_DELAY_US   1000
+
+#define DW9807_CTL_ADDR0x02
+/*
+ * DW9807 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ */
+#define DW9807_MSB_ADDR0x03
+#define DW9807_LSB_ADDR0x04
+#define DW9807_STATUS_ADDR 0x05
+#define DW9807_MODE_ADDR   0x06
+#define DW9807_RESONANCE_ADDR  0x07
+
+#define MAX_RETRY  10
+
+struct dw9807_device {
+   struct i2c_client *client;
+   struct v4l2_ctrl_handler ctrls_vcm;
+   struct v4l2_subdev sd;
+   u16 current_val;
+};
+
+static inline struct dw9807_device *to_dw9807_vcm(struct v4l2_ctrl 
+*ctrl) {
+   return container_of(ctrl->handler, struct dw9807_device, ctrls_vcm); }
+
+static inline struct dw9807_device *sd_to_dw9807_vcm(struct v4l2_subdev 
+*subdev) {
+   return container_of(subdev, struct dw9807_device, sd); }
+
+static int dw9807_i2c_check(struct i2c_client 

RE: [PATCH v4] media: dw9807: Add dw9807 vcm driver

[Yeh, Andy]

This is the right one. Sorry for inconvenience.

-Original Message-
From: Yeh, Andy 
Sent: Tuesday, January 30, 2018 12:53 AM
To: linux-media@vger.kernel.org
Cc: Yeh, Andy ; sakari.ai...@linux.intel.com; 
tf...@chromium.org; Chiang, AlanX 
Subject: [PATCH v4] media: dw9807: Add dw9807 vcm driver

From: Alan Chiang 

DW9807 is a 10 bit DAC from Dongwoon, designed for linear control of voice coil 
motor.

This driver creates a V4L2 subdevice and provides control to set the desired 
focus.

Signed-off-by: Andy Yeh 
---
since v1:
- changed author.
since v2:
- addressed outstanding comments.
- enabled sequential write to update 2 registers in a single transaction.
since v3:
- addressed comments for v3.
- Remove redundant codes and declar some variables as constant variable.
- separate DT binding to another patch

 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 ++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 319 +
 4 files changed, 337 insertions(+)
 create mode 100644 drivers/media/i2c/dw9807.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..a339bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4385,6 +4385,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/dw9714.c
 
+DONGWOON DW9807 LENS VOICE COIL DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/dw9807.c
+
 DOUBLETALK DRIVER
 M: "James R. Van Zandt" 
 L: blinux-l...@redhat.com
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 
cb5d7ff..fd01842 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -325,6 +325,16 @@ config VIDEO_DW9714
  capability. This is designed for linear control of
  voice coil motors, controlled via I2C serial interface.
 
+config VIDEO_DW9807
+   tristate "DW9807 lens voice coil support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the DW9807 camera lens voice coil.
+ DW9807 is a 10 bit DAC with 100mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
 config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 
548a9ef..1b62639 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
 obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
 obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
 obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
+obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
 obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
 obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
 obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o diff --git 
a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c new file mode 100644 
index 000..607e3ac
--- /dev/null
+++ b/drivers/media/i2c/dw9807.c
@@ -0,0 +1,319 @@
+// Copyright (C) 2018 Intel Corporation // SPDX-License-Identifier: 
+GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW9807_NAME"dw9807"
+#define DW9807_MAX_FOCUS_POS   1023
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position  */
+#define DW9807_FOCUS_STEPS 1
+/*
+ * This acts as the minimum granularity of lens movement.
+ * Keep this value power of 2, so the control steps can be
+ * uniformly adjusted for gradual lens movement, with desired
+ * number of control steps.
+ */
+#define DW9807_CTRL_STEPS  16
+#define DW9807_CTRL_DELAY_US   1000
+
+#define DW9807_CTL_ADDR0x02
+/*
+ * DW9807 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ */
+#define DW9807_MSB_ADDR0x03
+#define DW9807_LSB_ADDR0x04
+#define DW9807_STATUS_ADDR 0x05
+#define DW9807_MODE_ADDR   0x06
+#define DW9807_RESONANCE_ADDR  0x07
+
+#define MAX_RETRY  10
+
+struct dw9807_device {
+   struct v4l2_ctrl_handler ctrls_vcm;
+   struct v4l2_subdev sd;
+   u16 current_val;
+};
+
+static inline struct dw9807_device *sd_to_dw9807_vcm(struct v4l2_subdev 
+*subdev) {
+   return container_of(subdev, struct dw9807_device, sd); }
+
+static int dw9807_i2c_check(struct i2c_client *client) {
+   const char status_addr = DW9807_STATUS_ADDR;
+   char status_result = 0x1;
+   int ret;
+
+   ret = i2c_master_send(client, (const char *)_addr, 
sizeof(status_addr));
+   if (ret != 

[PATCH 7/8] platform: sh_veu: fix potential integer overflow in sh_veu_colour_offset

[Gustavo A. R. Silva]

Cast left and top to dma_addr_t in order to avoid a potential integer
overflow. This variable is being used in a context that expects an
expression of type dma_addr_t (u64).

Addresses-Coverity-ID: 1056807 ("Unintentional integer overflow")
Addresses-Coverity-ID: 1056808 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/platform/sh_veu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c
index 976ea0b..e2795d0 100644
--- a/drivers/media/platform/sh_veu.c
+++ b/drivers/media/platform/sh_veu.c
@@ -520,8 +520,8 @@ static void sh_veu_colour_offset(struct sh_veu_dev *veu, 
struct sh_veu_vfmt *vfm
/* dst_left and dst_top validity will be verified in CROP / COMPOSE */
unsigned int left = vfmt->frame.left & ~0x03;
unsigned int top = vfmt->frame.top;
-   dma_addr_t offset = ((left * veu->vfmt_out.fmt->depth) >> 3) +
-   top * veu->vfmt_out.bytesperline;
+   dma_addr_t offset = (((dma_addr_t)left * veu->vfmt_out.fmt->depth) >> 
3) +
+   (dma_addr_t)top * veu->vfmt_out.bytesperline;
unsigned int y_line;
 
vfmt->offset_y = offset;
-- 
2.7.4

[PATCH 5/8] pci: cx88-input: fix potential integer overflow

[Gustavo A. R. Silva]

Cast ir->polling to ktime_t in order to avoid a potential integer
overflow. This variable is being used in a context that expects
an expression of type ktime_t (s64).

Addresses-Coverity-ID: 1392628 ("Unintentional integer overflow")
Addresses-Coverity-ID: 1392630 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/pci/cx88/cx88-input.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/cx88/cx88-input.c 
b/drivers/media/pci/cx88/cx88-input.c
index 4e9953e..096b350 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -180,7 +180,7 @@ static enum hrtimer_restart cx88_ir_work(struct hrtimer 
*timer)
struct cx88_IR *ir = container_of(timer, struct cx88_IR, timer);
 
cx88_ir_handle_key(ir);
-   missed = hrtimer_forward_now(>timer, ir->polling * 100);
+   missed = hrtimer_forward_now(>timer, (ktime_t)ir->polling * 
100);
if (missed > 1)
ir_dprintk("Missed ticks %ld\n", missed - 1);
 
@@ -200,7 +200,7 @@ static int __cx88_ir_start(void *priv)
if (ir->polling) {
hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
ir->timer.function = cx88_ir_work;
-   hrtimer_start(>timer, ir->polling * 100,
+   hrtimer_start(>timer, (ktime_t)ir->polling * 100,
  HRTIMER_MODE_REL);
}
if (ir->sampling) {
-- 
2.7.4

[PATCH 4/8] i2c: ov9650: fix potential integer overflow in __ov965x_set_frame_interval

[Gustavo A. R. Silva]

Cast fi->interval.numerator to u64 in order to avoid a potential integer
overflow. This variable is being used in a context that expects an
expression of type u64.

Addresses-Coverity-ID: 1324146 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/i2c/ov9650.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index e519f27..c674a49 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1130,7 +1130,7 @@ static int __ov965x_set_frame_interval(struct ov965x 
*ov965x,
if (fi->interval.denominator == 0)
return -EINVAL;
 
-   req_int = (u64)(fi->interval.numerator * 1) /
+   req_int = (u64)fi->interval.numerator * 1 /
fi->interval.denominator;
 
for (i = 0; i < ARRAY_SIZE(ov965x_intervals); i++) {
-- 
2.7.4

[PATCH 8/8] platform: vivid-cec: fix potential integer overflow in vivid_cec_pin_adap_events

[Gustavo A. R. Silva]

Cast len to const u64 in order to avoid a potential integer
overflow. This variable is being used in a context that expects
an expression of type const u64.

Addresses-Coverity-ID: 1454996 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/platform/vivid/vivid-cec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vivid/vivid-cec.c 
b/drivers/media/platform/vivid/vivid-cec.c
index b55d278..30240ab 100644
--- a/drivers/media/platform/vivid/vivid-cec.c
+++ b/drivers/media/platform/vivid/vivid-cec.c
@@ -83,7 +83,7 @@ static void vivid_cec_pin_adap_events(struct cec_adapter 
*adap, ktime_t ts,
if (adap == NULL)
return;
ts = ktime_sub_us(ts, (CEC_TIM_START_BIT_TOTAL +
-  len * 10 * CEC_TIM_DATA_BIT_TOTAL));
+  (const u64)len * 10 * CEC_TIM_DATA_BIT_TOTAL));
cec_queue_pin_cec_event(adap, false, ts);
ts = ktime_add_us(ts, CEC_TIM_START_BIT_LOW);
cec_queue_pin_cec_event(adap, true, ts);
-- 
2.7.4

[PATCH 1/8] rtl2832: fix potential integer overflow in rtl2832_set_frontend

[Gustavo A. R. Silva]

Cast dev->pdata->clk to u64 in order to avoid a potential integer
overflow. This variable is being used in a context that expects
an expression of type u64.

Addresses-Coverity-ID: 1271223 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/dvb-frontends/rtl2832.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 94bf5b7..eefc301 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -498,7 +498,7 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
* RSAMP_RATIO = floor(CrystalFreqHz * 7 * pow(2, 22)
*   / ConstWithBandwidthMode)
*/
-   num = dev->pdata->clk * 7;
+   num = (u64)dev->pdata->clk * 7;
num *= 0x40;
num = div_u64(num, bw_mode);
resamp_ratio =  num & 0x3ff;
@@ -511,7 +511,7 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
*   / (CrystalFreqHz * 7))
*/
num = bw_mode << 20;
-   num2 = dev->pdata->clk * 7;
+   num2 = (u64)dev->pdata->clk * 7;
num = div_u64(num, num2);
num = -num;
cfreq_off_ratio = num & 0xf;
-- 
2.7.4

[PATCH 0/8] fix potential integer overflows

[Gustavo A. R. Silva]

This patchset aims to fix potential integer overflows reported
by Coverity.

In all cases the potential overflowing expressions are evaluated
using 32-bit arithmetic before being used in contexts that expect
a 64-bit arithmetic. So a cast to the proper type was added to each
of those expressions in order to avoid any potential integer overflow.

This also gives the compiler complete information about the proper
arithmetic for each expression and improves code quality.

Addresses the following Coverity IDs reported as
"Unintentional integer overflow" issues:

200604, 1056807, 1056808, 1271223,
1324146, 1392628, 1392630, 1446589,
1454996, 1458347.

Thank you

Gustavo A. R. Silva (8):
  rtl2832: fix potential integer overflow
  dvb-frontends: ves1820: fix potential integer overflow
  i2c: max2175: fix potential integer overflow in max2175_set_nco_freq
  i2c: ov9650: fix potential integer overflow in
__ov965x_set_frame_interval
  pci: cx88-input: fix potential integer overflow
  rockchip/rga: fix potential integer overflow in rga_buf_map
  platform: sh_veu: fix potential integer overflow in
sh_veu_colour_offset
  platform: vivid-cec: fix potential integer overflow in
vivid_cec_pin_adap_events

 drivers/media/dvb-frontends/rtl2832.c | 4 ++--
 drivers/media/dvb-frontends/ves1820.c | 2 +-
 drivers/media/i2c/max2175.c   | 2 +-
 drivers/media/i2c/ov9650.c| 2 +-
 drivers/media/pci/cx88/cx88-input.c   | 4 ++--
 drivers/media/platform/rockchip/rga/rga-buf.c | 2 +-
 drivers/media/platform/sh_veu.c   | 4 ++--
 drivers/media/platform/vivid/vivid-cec.c  | 2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)

-- 
2.7.4

[PATCH 2/8] dvb-frontends: ves1820: fix potential integer overflow

[Gustavo A. R. Silva]

Cast state->config->xin to u64 in order to avoid a potential integer
overflow. This variable is being used in a context that expects an
expression of type u64.

Addresses-Coverity-ID: 200604 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/dvb-frontends/ves1820.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/ves1820.c 
b/drivers/media/dvb-frontends/ves1820.c
index 1d89792..9dbd582 100644
--- a/drivers/media/dvb-frontends/ves1820.c
+++ b/drivers/media/dvb-frontends/ves1820.c
@@ -137,7 +137,7 @@ static int ves1820_set_symbolrate(struct ves1820_state 
*state, u32 symbolrate)
NDEC = 3;
 
/* yeuch! */
-   fpxin = state->config->xin * 10;
+   fpxin = (u64)state->config->xin * 10;
fptmp = fpxin; do_div(fptmp, 123);
if (symbolrate < fptmp)
SFIL = 1;
-- 
2.7.4

[PATCH 6/8] rockchip/rga: fix potential integer overflow in rga_buf_map

[Gustavo A. R. Silva]

Cast p to dma_addr_t in order to avoid a potential integer overflow.
This variable is being used in a context that expects an expression
of type dma_addr_t (u64).

Addresses-Coverity-ID: 1458347 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/platform/rockchip/rga/rga-buf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c 
b/drivers/media/platform/rockchip/rga/rga-buf.c
index 49cacc7..3dd29b2 100644
--- a/drivers/media/platform/rockchip/rga/rga-buf.c
+++ b/drivers/media/platform/rockchip/rga/rga-buf.c
@@ -140,7 +140,7 @@ void rga_buf_map(struct vb2_buffer *vb)
address = sg_phys(sgl);
 
for (p = 0; p < len; p++) {
-   dma_addr_t phys = address + (p << PAGE_SHIFT);
+   dma_addr_t phys = address + ((dma_addr_t)p << 
PAGE_SHIFT);
 
pages[mapped_size + p] = phys;
}
-- 
2.7.4

[PATCH 3/8] i2c: max2175: fix potential integer overflow in max2175_set_nco_freq

[Gustavo A. R. Silva]

Cast expression (clock_rate - abs_nco_freq) to s64 in order to avoid
a potential integer overflow. This variable is being used in a
context that expects an expression of type s64.

Addresses-Coverity-ID: 1446589 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/i2c/max2175.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/max2175.c b/drivers/media/i2c/max2175.c
index 2f1966b..3401ae6 100644
--- a/drivers/media/i2c/max2175.c
+++ b/drivers/media/i2c/max2175.c
@@ -643,7 +643,7 @@ static int max2175_set_nco_freq(struct max2175 *ctx, s32 
nco_freq)
if (abs_nco_freq < clock_rate / 2) {
nco_val_desired = 2 * nco_freq;
} else {
-   nco_val_desired = 2 * (clock_rate - abs_nco_freq);
+   nco_val_desired = 2 * (s64)(clock_rate - abs_nco_freq);
if (nco_freq < 0)
nco_val_desired = -nco_val_desired;
}
-- 
2.7.4

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

[Arnd Bergmann]

On Mon, Jan 29, 2018 at 10:49 PM, Randy Dunlap  wrote:
> On 01/29/2018 01:21 AM, Yong Deng wrote:
>> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
>> interface and CSI1 is used for parallel interface. This is not
>> documented in datasheet but by test and guess.
>>
>> This patch implement a v4l2 framework driver for it.
>>
>> Currently, the driver only support the parallel interface. MIPI-CSI2,
>> ISP's support are not included in this patch.
>>
>> Tested-by: Maxime Ripard 
>> Signed-off-by: Yong Deng 
>> ---
>
>
> A previous version (I think v6) had a build error with the use of
> PHYS_OFFSET, so Kconfig was modified to depend on ARM and ARCH_SUNXI
> (one of which seems to be overkill).  As is here, the COMPILE_TEST piece is
> meaningless for all arches except ARM.  If you care enough for COMPILE_TEST
> (and I would), then you could make COMPILE_TEST useful on any arch by
> removing the "depends on ARM" (the ARCH_SUNXI takes care of that) and by
> having an alternate value for PHYS_OFFSET, like so:
>
> +#if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
> +#define PHYS_OFFSET0
> +#endif
>
> With those 2 changes, the driver builds for me on x86_64.

I think the PHYS_OFFSET really has to get removed from the driver, it's
wrong on ARM as well.

  Arnd

Re: [PATCH v1] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Sakari Ailus]

Hi Andy,

Please add a cover page and send the entire set together (v5).

On Tue, Jan 30, 2018 at 12:34:32AM +0800, Andy Yeh wrote:
> From: Alan Chiang 
> 
> Dongwoon DW9807 is a voice coil lens driver.
> 
> Also add a vendor prefix for Dongwoon for one did not exist previously.
> 
> Signed-off-by: Andy Yeh 
> ---
>  Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 9 +
>  1 file changed, 9 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt 
> b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> new file mode 100644
> index 000..0a1a860
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> @@ -0,0 +1,9 @@
> +Dongwoon Anatech DW9807 voice coil lens driver
> +
> +DW9807 is a 10-bit DAC with current sink capability. It is intended for
> +controlling voice coil lenses.
> +
> +Mandatory properties:
> +
> +- compatible: "dongwoon,dw9807"
> +- reg: I2C slave address

The DT binding patch needs to be cc'd to the devicetree list
, please also cc Rob Herring
.

-- 
Regards,

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

Re: [PATCH v4] media: dw9807: Add dw9807 vcm driver

[Sakari Ailus]

Hi Andy and Alan,

Thanks for the update.

A number of patches you've sent lately have arrived twice in slightly
different form. If that happens, could you reply and tell which one is the
right one, please?

Please see my comments below.

On Tue, Jan 30, 2018 at 12:52:59AM +0800, Andy Yeh wrote:
> From: Alan Chiang 
> 
> DW9807 is a 10 bit DAC from Dongwoon, designed for linear
> control of voice coil motor.
> 
> This driver creates a V4L2 subdevice and
> provides control to set the desired focus.
> 
> Signed-off-by: Andy Yeh 
> ---
> since v1:
> - changed author.
> since v2:
> - addressed outstanding comments.
> - enabled sequential write to update 2 registers in a single transaction.
> since v3:
> - addressed comments for v3.
> - Remove redundant codes and declar some variables as constant variable.
> - separate DT binding to another patch
> 
>  MAINTAINERS|   7 +
>  drivers/media/i2c/Kconfig  |  10 ++
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/dw9807.c | 319 
> +
>  4 files changed, 337 insertions(+)
>  create mode 100644 drivers/media/i2c/dw9807.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 845fc25..a339bb5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4385,6 +4385,13 @@ T: git git://linuxtv.org/media_tree.git
>  S:   Maintained
>  F:   drivers/media/i2c/dw9714.c
>  
> +DONGWOON DW9807 LENS VOICE COIL DRIVER
> +M:   Sakari Ailus 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/i2c/dw9807.c
> +
>  DOUBLETALK DRIVER
>  M:   "James R. Van Zandt" 
>  L:   blinux-l...@redhat.com
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cb5d7ff..fd01842 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -325,6 +325,16 @@ config VIDEO_DW9714
> capability. This is designed for linear control of
> voice coil motors, controlled via I2C serial interface.
>  
> +config VIDEO_DW9807
> + tristate "DW9807 lens voice coil support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a driver for the DW9807 camera lens voice coil.
> +   DW9807 is a 10 bit DAC with 100mA output current sink
> +   capability. This is designed for linear control of
> +   voice coil motors, controlled via I2C serial interface.
> +
>  config VIDEO_SAA7110
>   tristate "Philips SAA7110 video decoder"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 548a9ef..1b62639 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
>  obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
>  obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
>  obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
> +obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
>  obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
>  obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
>  obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
> diff --git a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c
> new file mode 100644
> index 000..607e3ac
> --- /dev/null
> +++ b/drivers/media/i2c/dw9807.c
> @@ -0,0 +1,319 @@
> +// Copyright (C) 2018 Intel Corporation
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DW9807_NAME  "dw9807"
> +#define DW9807_MAX_FOCUS_POS 1023
> +/*
> + * This sets the minimum granularity for the focus positions.
> + * A value of 1 gives maximum accuracy for a desired focus position
> + */
> +#define DW9807_FOCUS_STEPS   1
> +/*
> + * This acts as the minimum granularity of lens movement.
> + * Keep this value power of 2, so the control steps can be
> + * uniformly adjusted for gradual lens movement, with desired
> + * number of control steps.
> + */
> +#define DW9807_CTRL_STEPS16
> +#define DW9807_CTRL_DELAY_US 1000
> +
> +#define DW9807_CTL_ADDR  0x02
> +/*
> + * DW9807 separates two registers to control the VCM position.
> + * One for MSB value, another is LSB value.
> + */
> +#define DW9807_MSB_ADDR  0x03
> +#define DW9807_LSB_ADDR  0x04
> +#define DW9807_STATUS_ADDR   0x05
> +#define DW9807_MODE_ADDR 0x06
> +#define DW9807_RESONANCE_ADDR0x07
> +
> +#define MAX_RETRY10
> +
> +struct dw9807_device {
> + struct v4l2_ctrl_handler ctrls_vcm;
> + struct v4l2_subdev sd;
> + u16 current_val;
> +};
> +
> +static inline struct dw9807_device *sd_to_dw9807_vcm(struct v4l2_subdev 
> *subdev)
> +{
> + return container_of(subdev, struct dw9807_device, sd);
> +}
> +
> +static int dw9807_i2c_check(struct i2c_client *client)
> +{
> + const char status_addr = DW9807_STATUS_ADDR;
> +  

Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

[Randy Dunlap]

On 01/29/2018 01:21 AM, Yong Deng wrote:
> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> interface and CSI1 is used for parallel interface. This is not
> documented in datasheet but by test and guess.
> 
> This patch implement a v4l2 framework driver for it.
> 
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
> 
> Tested-by: Maxime Ripard 
> Signed-off-by: Yong Deng 
> ---


A previous version (I think v6) had a build error with the use of
PHYS_OFFSET, so Kconfig was modified to depend on ARM and ARCH_SUNXI
(one of which seems to be overkill).  As is here, the COMPILE_TEST piece is
meaningless for all arches except ARM.  If you care enough for COMPILE_TEST
(and I would), then you could make COMPILE_TEST useful on any arch by
removing the "depends on ARM" (the ARCH_SUNXI takes care of that) and by
having an alternate value for PHYS_OFFSET, like so:

+#if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
+#define PHYS_OFFSET0
+#endif

With those 2 changes, the driver builds for me on x86_64.

> diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
> b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> new file mode 100644
> index 000..f80c965
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> @@ -0,0 +1,10 @@
> +config VIDEO_SUN6I_CSI
> + tristate "Allwinner V3s Camera Sensor Interface driver"
> + depends on ARM
> + depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> + depends on ARCH_SUNXI || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select REGMAP_MMIO
> + select V4L2_FWNODE
> + ---help---
> +Support for the Allwinner Camera Sensor Interface Controller on V3s.

thanks,
-- 
~Randy

Re: [PATCH 12/12] v4l2-compat-ioctl32.c: refactor, fix security bug in compat ioctl32

[Sakari Ailus]

Hi Hans,

On Mon, Jan 29, 2018 at 06:41:20PM +0100, Hans Verkuil wrote:
> On 01/29/2018 06:06 PM, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > Thanks for your efforts on this patch and the patchset. Please see my 
> > comments below.
> > 
> > On Fri, Jan 26, 2018 at 01:43:27PM +0100, Hans Verkuil wrote:
> >> From: Daniel Mentz 
> >>
> >> The 32-bit compat v4l2 ioctl is implemented based on its 64-bit
> > 
> > s/v4l2 ioctl/V4L2 IOCTL handling/
> > 
> > ?
> > 
> >> equivalent. It converts 32-bit data structures into its 64-bit
> >> equivalents and needs to provide the data to the 64-bit ioctl in user
> >> space memory which is commonly allocated using
> >> compat_alloc_user_space(). However, due to how that function is
> >> implemented, it can only be called a single time for every syscall
> >> invocation.  Supposedly to avoid this limitation, the existing code uses
> >> a mix of memory from the kernel stack and memory allocated through
> >> compat_alloc_user_space(). Under normal circumstances, this would not
> >> work, because the 64-bit ioctl expects all pointers to point to user
> >> space memory. As a workaround, set_fs(KERNEL_DS) is called to
> >> temporarily disable this extra safety check and allow kernel pointers.
> >> However, this might introduce a security vulnerability: The
> >> result of the 32-bit to 64-bit conversion is writeable by user space
> >> because the output buffer has been allocated via
> >> compat_alloc_user_space(). A malicious user space process could then
> >> manipulate pointers inside this output buffer, and due to the previous
> >> set_fs(KERNEL_DS) call, functions like get_user() or put_user() no longer
> >> prevent kernel memory access.
> >>
> >> The new approach is to pre-calculate the total amount of user space
> >> memory that is needed, allocate it using compat_alloc_user_space() and
> >> then divide up the allocated memory to accommodate all data structures
> >> that need to be converted.
> >>
> >> An alternative approach would have been to retain the union type karg
> >> that they allocated on the kernel stack in do_video_ioctl(), copy all
> >> data from user space into karg and then back to user space. However,
> >> we decided against this approach because it does not align with other
> >> compat syscall implementations. Instead, we tried to replicate the
> >> get_user/put_user pairs as found in other places in the kernel:
> >>
> >> if (get_user(clipcount, >clipcount) ||
> >> put_user(clipcount, >clipcount)) return -EFAULT;
> >>
> >> Notes from hans.verk...@cisco.com:
> >>
> >> This patch was taken from
> >> https://github.com/LineageOS/android_kernel_samsung_apq8084/commit/97b733953c06e4f0398ade18850f0817778255f7
> >>
> >> Clearly nobody could be bothered to upstream this patch or at minimum
> >> tell us :-( We only heard about this a week ago.
> > 
> > This is very sad indeed. I would really hope that we'll never run into
> > something this again!
> > 
> >>
> >> This patch was rebased and cleaned up. Compared to the original I
> >> also swapped the order of the convert_in_user arguments so that they
> >> matched copy_in_user. It was hard to review otherwise. I also replaced
> >> the ALLOC_USER_SPACE/ALLOC_AND_GET by a normal function.
> > 
> > The result looks more complicated than it should be.
> > 
> > I wonder if the result could be made cleaner by separating the argument
> > checking and copying from / to user space in video_usercopy. That
> > separation almost completely exists already. Rather than mangling the
> > compat argument struct to look like a user-provided 64-bit argument struct,
> > copying the arguments from and to the user space would be separately done
> > to 32-bit compat IOCTL arguments.
> > 
> > I suppose that wouldn't be a trivial change either, so for now I'd maintain
> > the approach and later consider how to make this more maintainable in the
> > future. Still, that approach is quite different and it'd be easier to
> > switch from status quo rather than this last patch, suggesting to start
> > with a revert, should we embark into this direction.
> > 
> > What do you think?
> 
> To be honest, I don't really know. Things will get even more complicated
> once we have to deal with the year 2038 problem since that impacts this
> code as well. I'm waiting for the fence code and request API code to
> land before continuing working on that. Perhaps that might be a good
> time to take a step back and see if we can do something smarter.

Sounds good to me.

> 
> > 
> >>
> >> Signed-off-by: Daniel Mentz 
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 700 
> >> --
> >>  1 file changed, 448 insertions(+), 252 deletions(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> >> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> >> index 2aa9b43daf60..27a5a0961cbd 100644
> >> --- 

Re: [PATCH 1/2] media: adv7604: Add support for i2c_new_secondary_device

[Rob Herring]

On Mon, Jan 22, 2018 at 12:49:56PM +, Kieran Bingham wrote:
> From: Jean-Michel Hautbois 
> 
> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
> I²C ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
> 
> Allow a device tree node to override the default addresses so that
> address conflicts with other devices on the same bus may be resolved at
> the board description level.
> 
> Signed-off-by: Jean-Michel Hautbois 
> [Kieran: Re-adapted for mainline]
> Signed-off-by: Kieran Bingham 
> ---
> Based upon the original posting :
>   https://lkml.org/lkml/2014/10/22/469
> ---
>  .../devicetree/bindings/media/i2c/adv7604.txt  | 18 ++-

Reviewed-by: Rob Herring 

In the future, please split bindings to separate patch.

>  drivers/media/i2c/adv7604.c| 60 
> ++
>  2 files changed, 55 insertions(+), 23 deletions(-)

Re: [PATCH 11/12] v4l2-compat-ioctl32.c: don't copy back the result for certain errors

[Sakari Ailus]

On Mon, Jan 29, 2018 at 11:02:56AM +0100, Hans Verkuil wrote:
> On 01/29/2018 10:56 AM, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > On Fri, Jan 26, 2018 at 01:43:26PM +0100, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> Some ioctls need to copy back the result even if the ioctl returned
> >> an error. However, don't do this for the error codes -ENOTTY, -EFAULT
> >> and -ENOIOCTLCMD. It makes no sense in those cases.
> >>
> >> Signed-off-by: Hans Verkuil 
> > 
> > Acked-by: Sakari Ailus 
> > 
> > Shouldn't such a change be made to video_usercopy() as well? Doesn't need
> > to be in this set though.
> 
> Good point. I'll add that for v2. This is not actually a bug as such, but
> it's just weird to copy back results if the ioctl wasn't implemented at all.
> 
> I realize that I need to drop the -EFAULT check: if you call 
> VIDIOC_G_EXT_CTRLS
> with an incorrect userspace buffer for the payload, then the control framework
> will set error_idx to the index of the control with the wrong buffer. So you 
> do
> need to copy back the data in case of -EFAULT.
> 
> I can also drop -ENOIOCTLCMD since video_usercopy() converts that to -ENOTTY.

Agreed.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 09/12] v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32

[Sakari Ailus]

On Mon, Jan 29, 2018 at 12:13:14PM -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 29 Jan 2018 11:47:42 +0200
> Sakari Ailus  escreveu:
> 
> 
> > > + compat_caddr_t p;
> > > +
> > >   if (copy_to_user(>w, >w, sizeof(kp->w)) ||
> > >   put_user(kp->field, >field) ||
> > >   put_user(kp->chromakey, >chromakey) ||
> > >   put_user(kp->clipcount, >clipcount) ||
> > >   put_user(kp->global_alpha, >global_alpha))
> > >   return -EFAULT;  
> > 
> > One more newline here?
> 
> Why? A new line here would be weird.

There are two if clauses that are unrelated. I'd say it improves
readability to separate them. That said, this isn't an exact science, so I
leave this up to Hans to decide.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 02/12] v4l2-ioctl.c: use check_fmt for enum/g/s/try_fmt

[Sakari Ailus]

Hi Hans,

On Mon, Jan 29, 2018 at 11:09:32AM +0100, Hans Verkuil wrote:
> On 01/26/2018 03:41 PM, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > On Fri, Jan 26, 2018 at 01:43:17PM +0100, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> Don't duplicate the buffer type checks in enum/g/s/try_fmt.
> >> The check_fmt function does that already.
> >>
> >> It is hard to keep the checks in sync for all these functions and
> >> in fact the check for VBI was wrong in the _fmt functions as it
> >> allowed SDR types as well. This caused a v4l2-compliance failure
> >> for /dev/swradio0 using vivid.
> >>
> >> This simplifies the code and keeps the check in one place and
> >> fixes the SDR/VBI bug.
> >>
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >>  drivers/media/v4l2-core/v4l2-ioctl.c | 140 
> >> ++-
> >>  1 file changed, 54 insertions(+), 86 deletions(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> >> b/drivers/media/v4l2-core/v4l2-ioctl.c
> >> index 59d2100eeff6..c7f6b65d3ad7 100644
> >> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> >> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> >> @@ -1316,52 +1316,50 @@ static int v4l_enum_fmt(const struct 
> >> v4l2_ioctl_ops *ops,
> >>struct file *file, void *fh, void *arg)
> >>  {
> >>struct v4l2_fmtdesc *p = arg;
> >> -  struct video_device *vfd = video_devdata(file);
> >> -  bool is_vid = vfd->vfl_type == VFL_TYPE_GRABBER;
> >> -  bool is_sdr = vfd->vfl_type == VFL_TYPE_SDR;
> >> -  bool is_tch = vfd->vfl_type == VFL_TYPE_TOUCH;
> >> -  bool is_rx = vfd->vfl_dir != VFL_DIR_TX;
> >> -  bool is_tx = vfd->vfl_dir != VFL_DIR_RX;
> >> -  int ret = -EINVAL;
> >> +  int ret = check_fmt(file, p->type);
> > 
> > I'd separate this from the variable declaration. The function is doing more
> > than just fetch something to be used as a shorthand locally. I.e.
> > 
> > int ret;
> > 
> > ret = check_fmt(file, p->type);
> > 
> > Same elsewhere.
> 
> OK.

Ack.

With that,

Acked-by: Sakari Ailus 

> 
> > 
> > The patch appears to be making an assumption that get_fmt will be
> > universally supported on any buffer type, or that buffer type is not
> > supported at all. I don't see a problem with the approach, but it'd be nice
> > to document it, perhaps in struct v4l2_ioctl_ops KernelDoc documentation.
> > 
> > check_fmt() allows V4L2_BUF_TYPE_VBI_CAPTURE, V4L2_BUF_TYPE_VBI_OUTPUT,
> > V4L2_BUF_TYPE_SLICED_VBI_CAPTURE and V4L2_BUF_TYPE_SLICED_VBI_OUTPUT that
> > the original code did not for VIDIOC_ENUM_FMT. Is the change intentional?
> 
> ENUM_FMT isn't supported for VBI. So v4l_enum_fmt() in v4l2-ioctl.c will
> always return -EINVAL. So the extra check that check_fmt does is a bit
> overkill for this specific ioctl. But applications won't be able to use
> ENUM_FMT for VBI anyway, so that extra check is not a problem.
> 
> Regards,
> 
>   Hans
> 
> > 
> > Documentation should be updated regarding SDR and META formats (buffer
> > type) but that's out of scope of the patchset:
> > 
> > 
> > 
> >> +
> >> +  if (ret)
> >> +  return ret;
> >> +  ret = -EINVAL;
> >>  
> >>switch (p->type) {
> >>case V4L2_BUF_TYPE_VIDEO_CAPTURE:
> >> -  if (unlikely(!is_rx || (!is_vid && !is_tch) || 
> >> !ops->vidioc_enum_fmt_vid_cap))
> >> +  if (unlikely(!ops->vidioc_enum_fmt_vid_cap))
> >>break;
> >>ret = ops->vidioc_enum_fmt_vid_cap(file, fh, arg);
> >>break;
> >>case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> >> -  if (unlikely(!is_rx || !is_vid || 
> >> !ops->vidioc_enum_fmt_vid_cap_mplane))
> >> +  if (unlikely(!ops->vidioc_enum_fmt_vid_cap_mplane))
> >>break;
> >>ret = ops->vidioc_enum_fmt_vid_cap_mplane(file, fh, arg);
> >>break;
> >>case V4L2_BUF_TYPE_VIDEO_OVERLAY:
> >> -  if (unlikely(!is_rx || !is_vid || 
> >> !ops->vidioc_enum_fmt_vid_overlay))
> >> +  if (unlikely(!ops->vidioc_enum_fmt_vid_overlay))
> >>break;
> >>ret = ops->vidioc_enum_fmt_vid_overlay(file, fh, arg);
> >>break;
> >>case V4L2_BUF_TYPE_VIDEO_OUTPUT:
> >> -  if (unlikely(!is_tx || !is_vid || 
> >> !ops->vidioc_enum_fmt_vid_out))
> >> +  if (unlikely(!ops->vidioc_enum_fmt_vid_out))
> >>break;
> >>ret = ops->vidioc_enum_fmt_vid_out(file, fh, arg);
> >>break;
> >>case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> >> -  if (unlikely(!is_tx || !is_vid || 
> >> !ops->vidioc_enum_fmt_vid_out_mplane))
> >> +  if (unlikely(!ops->vidioc_enum_fmt_vid_out_mplane))
> >>break;
> >>ret = ops->vidioc_enum_fmt_vid_out_mplane(file, fh, arg);
> >>break;
> >>case V4L2_BUF_TYPE_SDR_CAPTURE:
> >> -   

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Rob Herring]

On Mon, Jan 22, 2018 at 12:50:01PM +, Kieran Bingham wrote:
> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
> 
> Allow a device tree node to override the default addresses so that
> address conflicts with other devices on the same bus may be resolved at
> the board description level.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  .../bindings/display/bridge/adi,adv7511.txt| 10 +-

Reviewed-by: Rob Herring 

>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 
> ++
>  3 files changed, 37 insertions(+), 13 deletions(-)

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Rob Herring]

On Mon, Jan 29, 2018 at 12:26:00PM +0200, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
> > The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> > ports. Each map has it own I²C address and acts as a standard slave
> > device on the I²C bus.
> > 
> > Allow a device tree node to override the default addresses so that
> > address conflicts with other devices on the same bus may be resolved at
> > the board description level.
> > 
> > Signed-off-by: Kieran Bingham 
> > ---
> >  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
> 
> I don't mind personally, but device tree maintainers usually ask for DT 
> bindings changes to be split to a separate patch.

Or perfect bindings, then I won't ask to split it just for that 
(usually).

> >  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
> >  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 ---
> >  3 files changed, 37 insertions(+), 13 deletions(-)

Re: [PATCH v2 2/2] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Benoit Parrot]

Maxime,

Thank you for the patch.

Maxime Ripard  wrote on Fri [2018-Jan-19 
09:15:47 +0100]:
> The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used
> as a bridge between pixel interfaces and a CSI-2 bus.
> 
> It supports operating with an internal or external D-PHY, with up to 4
> lanes, or without any D-PHY. The current code only supports the former
> case.
> 
> While the virtual channel input on the pixel interface can be directly
> mapped to CSI2, the datatype input is actually a selection signal (3-bits)
> mapping to a table of up to 8 preconfigured datatypes/formats (programmed
> at start-up)
> 
> The block supports up to 8 input datatypes.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/media/platform/cadence/Kconfig   |   6 +
>  drivers/media/platform/cadence/Makefile  |   1 +
>  drivers/media/platform/cadence/cdns-csi2tx.c | 586 
> +++
>  3 files changed, 593 insertions(+)
>  create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c
> 
> diff --git a/drivers/media/platform/cadence/Kconfig 
> b/drivers/media/platform/cadence/Kconfig
> index d1b6bbb6a0eb..db49328ee8b2 100644
> --- a/drivers/media/platform/cadence/Kconfig
> +++ b/drivers/media/platform/cadence/Kconfig
> @@ -9,4 +9,10 @@ config VIDEO_CADENCE_CSI2RX
>   depends on VIDEO_V4L2_SUBDEV_API
>   select V4L2_FWNODE
>  
> +config VIDEO_CADENCE_CSI2TX
> + tristate "Cadence MIPI-CSI2 TX Controller"
> + depends on MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> +
>  endif
> diff --git a/drivers/media/platform/cadence/Makefile 
> b/drivers/media/platform/cadence/Makefile
> index 99a4086b7448..7fe992273162 100644
> --- a/drivers/media/platform/cadence/Makefile
> +++ b/drivers/media/platform/cadence/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_VIDEO_CADENCE_CSI2RX)   += cdns-csi2rx.o
> +obj-$(CONFIG_VIDEO_CADENCE_CSI2TX)   += cdns-csi2tx.o
> diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c 
> b/drivers/media/platform/cadence/cdns-csi2tx.c
> new file mode 100644
> index ..850701020836
> --- /dev/null
> +++ b/drivers/media/platform/cadence/cdns-csi2tx.c
> @@ -0,0 +1,586 @@
> +/*
> + * Driver for Cadence MIPI-CSI2 TX Controller
> + *
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * 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.

Should use SPDX license tag line instead.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CSI2TX_DEVICE_CONFIG_REG 0x00
> +
> +#define CSI2TX_CONFIG_REG0x20
> +#define CSI2TX_CONFIG_CFG_REQBIT(2)
> +#define CSI2TX_CONFIG_SRST_REQ   BIT(1)
> +
> +#define CSI2TX_DPHY_CFG_REG  0x28
> +#define CSI2TX_DPHY_CFG_CLK_RESETBIT(16)
> +#define CSI2TX_DPHY_CFG_LANE_RESET(n)BIT((n) + 12)
> +#define CSI2TX_DPHY_CFG_MODE_MASKGENMASK(9, 8)
> +#define CSI2TX_DPHY_CFG_MODE_LPDT(2 << 8)
> +#define CSI2TX_DPHY_CFG_MODE_HS  (1 << 8)
> +#define CSI2TX_DPHY_CFG_MODE_ULPS(0 << 8)
> +#define CSI2TX_DPHY_CFG_CLK_ENABLE   BIT(4)
> +#define CSI2TX_DPHY_CFG_LANE_ENABLE(n)   BIT(n)
> +
> +#define CSI2TX_DPHY_CLK_WAKEUP_REG   0x2c
> +#define CSI2TX_DPHY_CLK_WAKEUP_ULPS_CYCLES(n)((n) & 0x)
> +
> +#define CSI2TX_DT_CFG_REG(n) (0x80 + (n) * 8)
> +#define CSI2TX_DT_CFG_DT(n)  (((n) & 0x3f) << 2)
> +
> +#define CSI2TX_DT_FORMAT_REG(n)  (0x84 + (n) * 8)
> +#define CSI2TX_DT_FORMAT_BYTES_PER_LINE(n)   (((n) & 0x) << 16)
> +#define CSI2TX_DT_FORMAT_MAX_LINE_NUM(n) ((n) & 0x)
> +
> +#define CSI2TX_STREAM_IF_CFG_REG(n)  (0x100 + (n) * 4)
> +#define CSI2TX_STREAM_IF_CFG_FILL_LEVEL(n)   ((n) & 0x1f)
> +
> +#define CSI2TX_STREAMS_MAX   4
> +
> +enum csi2tx_pads {
> + CSI2TX_PAD_SOURCE,
> + CSI2TX_PAD_SINK_STREAM0,
> + CSI2TX_PAD_SINK_STREAM1,
> + CSI2TX_PAD_SINK_STREAM2,
> + CSI2TX_PAD_SINK_STREAM3,
> + CSI2TX_PAD_MAX,
> +};
> +
> +struct csi2tx_fmt {
> + u32 mbus;
> + u32 dt;
> + u32 bpp;
> +};
> +
> +struct csi2tx_priv {
> + struct device   *dev;
> + atomic_tcount;
> +
> + void __iomem*base;
> +
> + struct clk  *esc_clk;
> + struct clk  *p_clk;
> + struct clk  *pixel_clk[CSI2TX_STREAMS_MAX];
> +
> + struct v4l2_subdev  subdev;
> + struct 

Re: [PATCH v5 2/2] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

[Benoit Parrot]

Maxime,

Thank you for the patch.

Maxime Ripard  wrote on Fri [2018-Jan-19 
09:13:57 +0100]:
> The Cadence CSI-2 RX Controller is an hardware block meant to be used as a
> bridge between a CSI-2 bus and pixel grabbers.
> 
> It supports operating with internal or external D-PHY, with up to 4 lanes,
> or without any D-PHY. The current code only supports the former case.
> 
> It also support dynamic mapping of the CSI-2 virtual channels to the
> associated pixel grabbers, but that isn't allowed at the moment either.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/media/platform/Kconfig   |   1 +
>  drivers/media/platform/Makefile  |   2 +
>  drivers/media/platform/cadence/Kconfig   |  12 +
>  drivers/media/platform/cadence/Makefile  |   1 +
>  drivers/media/platform/cadence/cdns-csi2rx.c | 463 
> +++
>  5 files changed, 479 insertions(+)
>  create mode 100644 drivers/media/platform/cadence/Kconfig
>  create mode 100644 drivers/media/platform/cadence/Makefile
>  create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index fd0c99859d6f..6e790a317fbc 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
>  #
>  # Platform multimedia device configuration
>  #
> +source "drivers/media/platform/cadence/Kconfig"
>  
>  source "drivers/media/platform/davinci/Kconfig"
>  
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 003b0bb2cddf..1cd2984c55d1 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -3,6 +3,8 @@
>  # Makefile for the video capture/playback device drivers.
>  #
>  
> +obj-$(CONFIG_VIDEO_CADENCE)  += cadence/
> +
>  obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
>  
>  obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
> diff --git a/drivers/media/platform/cadence/Kconfig 
> b/drivers/media/platform/cadence/Kconfig
> new file mode 100644
> index ..d1b6bbb6a0eb
> --- /dev/null
> +++ b/drivers/media/platform/cadence/Kconfig
> @@ -0,0 +1,12 @@
> +config VIDEO_CADENCE
> + bool "Cadence Video Devices"
> +
> +if VIDEO_CADENCE
> +
> +config VIDEO_CADENCE_CSI2RX
> + tristate "Cadence MIPI-CSI2 RX Controller v1.3"
> + depends on MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> +
> +endif
> diff --git a/drivers/media/platform/cadence/Makefile 
> b/drivers/media/platform/cadence/Makefile
> new file mode 100644
> index ..99a4086b7448
> --- /dev/null
> +++ b/drivers/media/platform/cadence/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CADENCE_CSI2RX)   += cdns-csi2rx.o
> diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
> b/drivers/media/platform/cadence/cdns-csi2rx.c
> new file mode 100644
> index ..ce042b9d403c
> --- /dev/null
> +++ b/drivers/media/platform/cadence/cdns-csi2rx.c
> @@ -0,0 +1,463 @@
> +/*
> + * Driver for Cadence MIPI-CSI2 RX Controller v1.3
> + *
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.

This being a new driver, it would probably make sense to replace the above
license text with the appropriate SPDX license tag line.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CSI2RX_DEVICE_CFG_REG0x000
> +
> +#define CSI2RX_SOFT_RESET_REG0x004
> +#define CSI2RX_SOFT_RESET_PROTOCOL   BIT(1)
> +#define CSI2RX_SOFT_RESET_FRONT  BIT(0)
> +
> +#define CSI2RX_STATIC_CFG_REG0x008
> +#define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane)((plane) << (16 + 
> (llane) * 4))
> +#define CSI2RX_STATIC_CFG_LANES_MASK GENMASK(11, 8)
> +
> +#define CSI2RX_STREAM_BASE(n)(((n) + 1) * 0x100)
> +
> +#define CSI2RX_STREAM_CTRL_REG(n)(CSI2RX_STREAM_BASE(n) + 0x000)
> +#define CSI2RX_STREAM_CTRL_START BIT(0)
> +
> +#define CSI2RX_STREAM_DATA_CFG_REG(n)(CSI2RX_STREAM_BASE(n) 
> + 0x008)
> +#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECT  BIT(31)
> +#define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n)  BIT((n) + 16)
> +
> +#define CSI2RX_STREAM_CFG_REG(n) (CSI2RX_STREAM_BASE(n) + 0x00c)
> +#define CSI2RX_STREAM_CFG_FIFO_MODE_LARGE_BUF(1 << 8)
> +
> +#define CSI2RX_LANES_MAX 4
> +#define 

Re: [PATCH 12/12] v4l2-compat-ioctl32.c: refactor, fix security bug in compat ioctl32

[Hans Verkuil]

On 01/29/2018 06:06 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> Thanks for your efforts on this patch and the patchset. Please see my 
> comments below.
> 
> On Fri, Jan 26, 2018 at 01:43:27PM +0100, Hans Verkuil wrote:
>> From: Daniel Mentz 
>>
>> The 32-bit compat v4l2 ioctl is implemented based on its 64-bit
> 
> s/v4l2 ioctl/V4L2 IOCTL handling/
> 
> ?
> 
>> equivalent. It converts 32-bit data structures into its 64-bit
>> equivalents and needs to provide the data to the 64-bit ioctl in user
>> space memory which is commonly allocated using
>> compat_alloc_user_space(). However, due to how that function is
>> implemented, it can only be called a single time for every syscall
>> invocation.  Supposedly to avoid this limitation, the existing code uses
>> a mix of memory from the kernel stack and memory allocated through
>> compat_alloc_user_space(). Under normal circumstances, this would not
>> work, because the 64-bit ioctl expects all pointers to point to user
>> space memory. As a workaround, set_fs(KERNEL_DS) is called to
>> temporarily disable this extra safety check and allow kernel pointers.
>> However, this might introduce a security vulnerability: The
>> result of the 32-bit to 64-bit conversion is writeable by user space
>> because the output buffer has been allocated via
>> compat_alloc_user_space(). A malicious user space process could then
>> manipulate pointers inside this output buffer, and due to the previous
>> set_fs(KERNEL_DS) call, functions like get_user() or put_user() no longer
>> prevent kernel memory access.
>>
>> The new approach is to pre-calculate the total amount of user space
>> memory that is needed, allocate it using compat_alloc_user_space() and
>> then divide up the allocated memory to accommodate all data structures
>> that need to be converted.
>>
>> An alternative approach would have been to retain the union type karg
>> that they allocated on the kernel stack in do_video_ioctl(), copy all
>> data from user space into karg and then back to user space. However,
>> we decided against this approach because it does not align with other
>> compat syscall implementations. Instead, we tried to replicate the
>> get_user/put_user pairs as found in other places in the kernel:
>>
>> if (get_user(clipcount, >clipcount) ||
>> put_user(clipcount, >clipcount)) return -EFAULT;
>>
>> Notes from hans.verk...@cisco.com:
>>
>> This patch was taken from
>> https://github.com/LineageOS/android_kernel_samsung_apq8084/commit/97b733953c06e4f0398ade18850f0817778255f7
>>
>> Clearly nobody could be bothered to upstream this patch or at minimum
>> tell us :-( We only heard about this a week ago.
> 
> This is very sad indeed. I would really hope that we'll never run into
> something this again!
> 
>>
>> This patch was rebased and cleaned up. Compared to the original I
>> also swapped the order of the convert_in_user arguments so that they
>> matched copy_in_user. It was hard to review otherwise. I also replaced
>> the ALLOC_USER_SPACE/ALLOC_AND_GET by a normal function.
> 
> The result looks more complicated than it should be.
> 
> I wonder if the result could be made cleaner by separating the argument
> checking and copying from / to user space in video_usercopy. That
> separation almost completely exists already. Rather than mangling the
> compat argument struct to look like a user-provided 64-bit argument struct,
> copying the arguments from and to the user space would be separately done
> to 32-bit compat IOCTL arguments.
> 
> I suppose that wouldn't be a trivial change either, so for now I'd maintain
> the approach and later consider how to make this more maintainable in the
> future. Still, that approach is quite different and it'd be easier to
> switch from status quo rather than this last patch, suggesting to start
> with a revert, should we embark into this direction.
> 
> What do you think?

To be honest, I don't really know. Things will get even more complicated
once we have to deal with the year 2038 problem since that impacts this
code as well. I'm waiting for the fence code and request API code to
land before continuing working on that. Perhaps that might be a good
time to take a step back and see if we can do something smarter.

> 
>>
>> Signed-off-by: Daniel Mentz 
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 700 
>> --
>>  1 file changed, 448 insertions(+), 252 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
>> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> index 2aa9b43daf60..27a5a0961cbd 100644
>> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> @@ -22,6 +22,14 @@
>>  #include 
>>  #include 
>>  
>> +/* Use the same argument order as copy_in_user */
>> +#define convert_in_user(to, from)   \
> 
> This doesn't really convert 

Re: [PATCH 12/12] v4l2-compat-ioctl32.c: refactor, fix security bug in compat ioctl32

[Sakari Ailus]

Hi Hans,

Thanks for your efforts on this patch and the patchset. Please see my comments 
below.

On Fri, Jan 26, 2018 at 01:43:27PM +0100, Hans Verkuil wrote:
> From: Daniel Mentz 
> 
> The 32-bit compat v4l2 ioctl is implemented based on its 64-bit

s/v4l2 ioctl/V4L2 IOCTL handling/

?

> equivalent. It converts 32-bit data structures into its 64-bit
> equivalents and needs to provide the data to the 64-bit ioctl in user
> space memory which is commonly allocated using
> compat_alloc_user_space(). However, due to how that function is
> implemented, it can only be called a single time for every syscall
> invocation.  Supposedly to avoid this limitation, the existing code uses
> a mix of memory from the kernel stack and memory allocated through
> compat_alloc_user_space(). Under normal circumstances, this would not
> work, because the 64-bit ioctl expects all pointers to point to user
> space memory. As a workaround, set_fs(KERNEL_DS) is called to
> temporarily disable this extra safety check and allow kernel pointers.
> However, this might introduce a security vulnerability: The
> result of the 32-bit to 64-bit conversion is writeable by user space
> because the output buffer has been allocated via
> compat_alloc_user_space(). A malicious user space process could then
> manipulate pointers inside this output buffer, and due to the previous
> set_fs(KERNEL_DS) call, functions like get_user() or put_user() no longer
> prevent kernel memory access.
> 
> The new approach is to pre-calculate the total amount of user space
> memory that is needed, allocate it using compat_alloc_user_space() and
> then divide up the allocated memory to accommodate all data structures
> that need to be converted.
> 
> An alternative approach would have been to retain the union type karg
> that they allocated on the kernel stack in do_video_ioctl(), copy all
> data from user space into karg and then back to user space. However,
> we decided against this approach because it does not align with other
> compat syscall implementations. Instead, we tried to replicate the
> get_user/put_user pairs as found in other places in the kernel:
> 
> if (get_user(clipcount, >clipcount) ||
> put_user(clipcount, >clipcount)) return -EFAULT;
> 
> Notes from hans.verk...@cisco.com:
> 
> This patch was taken from
> https://github.com/LineageOS/android_kernel_samsung_apq8084/commit/97b733953c06e4f0398ade18850f0817778255f7
> 
> Clearly nobody could be bothered to upstream this patch or at minimum
> tell us :-( We only heard about this a week ago.

This is very sad indeed. I would really hope that we'll never run into
something this again!

> 
> This patch was rebased and cleaned up. Compared to the original I
> also swapped the order of the convert_in_user arguments so that they
> matched copy_in_user. It was hard to review otherwise. I also replaced
> the ALLOC_USER_SPACE/ALLOC_AND_GET by a normal function.

The result looks more complicated than it should be.

I wonder if the result could be made cleaner by separating the argument
checking and copying from / to user space in video_usercopy. That
separation almost completely exists already. Rather than mangling the
compat argument struct to look like a user-provided 64-bit argument struct,
copying the arguments from and to the user space would be separately done
to 32-bit compat IOCTL arguments.

I suppose that wouldn't be a trivial change either, so for now I'd maintain
the approach and later consider how to make this more maintainable in the
future. Still, that approach is quite different and it'd be easier to
switch from status quo rather than this last patch, suggesting to start
with a revert, should we embark into this direction.

What do you think?

> 
> Signed-off-by: Daniel Mentz 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 700 
> --
>  1 file changed, 448 insertions(+), 252 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 2aa9b43daf60..27a5a0961cbd 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -22,6 +22,14 @@
>  #include 
>  #include 
>  
> +/* Use the same argument order as copy_in_user */
> +#define convert_in_user(to, from)\

This doesn't really convert anything. How about calling it assign_in_user,
for example?

> +({   \
> + typeof(*from) val;  \

"val" is very short, easily leading to hard-to-find namespace collisions.
At least the versions of GCC I've used happily get this wrong without a
warning.

How about __convert_in_user_tmp instead?

> + \
> + get_user(val, from) || put_user(val, to);   \
> +})
> +
>  static long 

[PATCH v4] media: dw9807: Add dw9807 vcm driver

[Andy Yeh]

From: Alan Chiang 

DW9807 is a 10 bit DAC from Dongwoon, designed for linear
control of voice coil motor.

This driver creates a V4L2 subdevice and
provides control to set the desired focus.

Signed-off-by: Andy Yeh 
---
since v1:
- changed author.
since v2:
- addressed outstanding comments.
- enabled sequential write to update 2 registers in a single transaction.
since v3:
- addressed comments for v3.
- Remove redundant codes and declar some variables as constant variable.
- separate DT binding to another patch

 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 ++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 319 +
 4 files changed, 337 insertions(+)
 create mode 100644 drivers/media/i2c/dw9807.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..a339bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4385,6 +4385,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/dw9714.c
 
+DONGWOON DW9807 LENS VOICE COIL DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/dw9807.c
+
 DOUBLETALK DRIVER
 M: "James R. Van Zandt" 
 L: blinux-l...@redhat.com
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..fd01842 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -325,6 +325,16 @@ config VIDEO_DW9714
  capability. This is designed for linear control of
  voice coil motors, controlled via I2C serial interface.
 
+config VIDEO_DW9807
+   tristate "DW9807 lens voice coil support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the DW9807 camera lens voice coil.
+ DW9807 is a 10 bit DAC with 100mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
 config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..1b62639 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
 obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
 obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
 obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
+obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
 obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
 obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
 obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
diff --git a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c
new file mode 100644
index 000..607e3ac
--- /dev/null
+++ b/drivers/media/i2c/dw9807.c
@@ -0,0 +1,319 @@
+// Copyright (C) 2018 Intel Corporation
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW9807_NAME"dw9807"
+#define DW9807_MAX_FOCUS_POS   1023
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position
+ */
+#define DW9807_FOCUS_STEPS 1
+/*
+ * This acts as the minimum granularity of lens movement.
+ * Keep this value power of 2, so the control steps can be
+ * uniformly adjusted for gradual lens movement, with desired
+ * number of control steps.
+ */
+#define DW9807_CTRL_STEPS  16
+#define DW9807_CTRL_DELAY_US   1000
+
+#define DW9807_CTL_ADDR0x02
+/*
+ * DW9807 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ */
+#define DW9807_MSB_ADDR0x03
+#define DW9807_LSB_ADDR0x04
+#define DW9807_STATUS_ADDR 0x05
+#define DW9807_MODE_ADDR   0x06
+#define DW9807_RESONANCE_ADDR  0x07
+
+#define MAX_RETRY  10
+
+struct dw9807_device {
+   struct v4l2_ctrl_handler ctrls_vcm;
+   struct v4l2_subdev sd;
+   u16 current_val;
+};
+
+static inline struct dw9807_device *sd_to_dw9807_vcm(struct v4l2_subdev 
*subdev)
+{
+   return container_of(subdev, struct dw9807_device, sd);
+}
+
+static int dw9807_i2c_check(struct i2c_client *client)
+{
+   const char status_addr = DW9807_STATUS_ADDR;
+   char status_result = 0x1;
+   int ret;
+
+   ret = i2c_master_send(client, (const char *)_addr, 
sizeof(status_addr));
+   if (ret != sizeof(status_addr)) {
+   dev_err(>dev, "I2C write STATUS address fail ret = 
%d\n",
+   ret);
+   return -EIO;
+   }
+
+   ret = i2c_master_recv(client, (char *)_result, 
sizeof(status_result));
+   if (ret != sizeof(status_result)) {
+   dev_err(>dev, "I2C read STATUS value fail 

[PATCH v10 12/30] rcar-vin: enable Gen3 hardware configuration

[Niklas Söderlund]

Add the register needed to work with Gen3 hardware. This patch adds
the logic for how to work with the Gen3 hardware. More work is required
to enable the subdevice structure needed to configure capturing.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 94 --
 drivers/media/platform/rcar-vin/rcar-vin.h |  1 +
 2 files changed, 64 insertions(+), 31 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 561500f65cfa2e74..2f9ad1bec1c8a92f 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -33,21 +33,23 @@
 #define VNELPRC_REG0x10/* Video n End Line Pre-Clip Register */
 #define VNSPPRC_REG0x14/* Video n Start Pixel Pre-Clip Register */
 #define VNEPPRC_REG0x18/* Video n End Pixel Pre-Clip Register */
-#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */
-#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */
-#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */
-#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */
 #define VNIS_REG   0x2C/* Video n Image Stride Register */
 #define VNMB_REG(m)(0x30 + ((m) << 2)) /* Video n Memory Base m Register */
 #define VNIE_REG   0x40/* Video n Interrupt Enable Register */
 #define VNINTS_REG 0x44/* Video n Interrupt Status Register */
 #define VNSI_REG   0x48/* Video n Scanline Interrupt Register */
 #define VNMTC_REG  0x4C/* Video n Memory Transfer Control Register */
-#define VNYS_REG   0x50/* Video n Y Scale Register */
-#define VNXS_REG   0x54/* Video n X Scale Register */
 #define VNDMR_REG  0x58/* Video n Data Mode Register */
 #define VNDMR2_REG 0x5C/* Video n Data Mode Register 2 */
 #define VNUVAOF_REG0x60/* Video n UV Address Offset Register */
+
+/* Register offsets specific for Gen2 */
+#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */
+#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */
+#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */
+#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */
+#define VNYS_REG   0x50/* Video n Y Scale Register */
+#define VNXS_REG   0x54/* Video n X Scale Register */
 #define VNC1A_REG  0x80/* Video n Coefficient Set C1A Register */
 #define VNC1B_REG  0x84/* Video n Coefficient Set C1B Register */
 #define VNC1C_REG  0x88/* Video n Coefficient Set C1C Register */
@@ -73,9 +75,13 @@
 #define VNC8B_REG  0xF4/* Video n Coefficient Set C8B Register */
 #define VNC8C_REG  0xF8/* Video n Coefficient Set C8C Register */
 
+/* Register offsets specific for Gen3 */
+#define VNCSI_IFMD_REG 0x20 /* Video n CSI2 Interface Mode Register */
 
 /* Register bit fields for R-Car VIN */
 /* Video n Main Control Register bits */
+#define VNMC_DPINE (1 << 27) /* Gen3 specific */
+#define VNMC_SCLE  (1 << 26) /* Gen3 specific */
 #define VNMC_FOC   (1 << 21)
 #define VNMC_YCAL  (1 << 19)
 #define VNMC_INF_YUV8_BT656(0 << 16)
@@ -119,6 +125,13 @@
 #define VNDMR2_FTEV(1 << 17)
 #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
 
+/* Video n CSI2 Interface Mode Register (Gen3) */
+#define VNCSI_IFMD_DES2(1 << 27)
+#define VNCSI_IFMD_DES1(1 << 26)
+#define VNCSI_IFMD_DES0(1 << 25)
+#define VNCSI_IFMD_CSI_CHSEL(n) (((n) & 0xf) << 0)
+#define VNCSI_IFMD_CSI_CHSEL_MASK 0xf
+
 struct rvin_buffer {
struct vb2_v4l2_buffer vb;
struct list_head list;
@@ -514,28 +527,10 @@ static void rvin_set_coeff(struct rvin_dev *vin, unsigned 
short xs)
rvin_write(vin, p_set->coeff_set[23], VNC8C_REG);
 }
 
-void rvin_crop_scale_comp(struct rvin_dev *vin)
+static void rvin_crop_scale_comp_gen2(struct rvin_dev *vin)
 {
u32 xs, ys;
 
-   /* Set Start/End Pixel/Line Pre-Clip */
-   rvin_write(vin, vin->crop.left, VNSPPRC_REG);
-   rvin_write(vin, vin->crop.left + vin->crop.width - 1, VNEPPRC_REG);
-   switch (vin->format.field) {
-   case V4L2_FIELD_INTERLACED:
-   case V4L2_FIELD_INTERLACED_TB:
-   case V4L2_FIELD_INTERLACED_BT:
-   rvin_write(vin, vin->crop.top / 2, VNSLPRC_REG);
-   rvin_write(vin, (vin->crop.top + vin->crop.height) / 2 - 1,
-  VNELPRC_REG);
-   break;
-   default:
-   rvin_write(vin, vin->crop.top, VNSLPRC_REG);
-   rvin_write(vin, vin->crop.top + vin->crop.height - 1,
-  VNELPRC_REG);
-   

[PATCH v10 07/30] rcar-vin: move functions regarding scaling

[Niklas Söderlund]

In preparation of refactoring the scaling code move the code regarding
scaling to to the top of the file to avoid the need to add forward
declarations. No code is changed in this commit only whole functions
moved inside the same file.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 602 +++--
 1 file changed, 303 insertions(+), 299 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index d701b52d198243b5..a7cda3922cb74baa 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -138,305 +138,6 @@ static u32 rvin_read(struct rvin_dev *vin, u32 offset)
return ioread32(vin->base + offset);
 }
 
-static int rvin_setup(struct rvin_dev *vin)
-{
-   u32 vnmc, dmr, dmr2, interrupts;
-   v4l2_std_id std;
-   bool progressive = false, output_is_yuv = false, input_is_yuv = false;
-
-   switch (vin->format.field) {
-   case V4L2_FIELD_TOP:
-   vnmc = VNMC_IM_ODD;
-   break;
-   case V4L2_FIELD_BOTTOM:
-   vnmc = VNMC_IM_EVEN;
-   break;
-   case V4L2_FIELD_INTERLACED:
-   /* Default to TB */
-   vnmc = VNMC_IM_FULL;
-   /* Use BT if video standard can be read and is 60 Hz format */
-   if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
-   if (std & V4L2_STD_525_60)
-   vnmc = VNMC_IM_FULL | VNMC_FOC;
-   }
-   break;
-   case V4L2_FIELD_INTERLACED_TB:
-   vnmc = VNMC_IM_FULL;
-   break;
-   case V4L2_FIELD_INTERLACED_BT:
-   vnmc = VNMC_IM_FULL | VNMC_FOC;
-   break;
-   case V4L2_FIELD_ALTERNATE:
-   case V4L2_FIELD_NONE:
-   if (vin->continuous) {
-   vnmc = VNMC_IM_ODD_EVEN;
-   progressive = true;
-   } else {
-   vnmc = VNMC_IM_ODD;
-   }
-   break;
-   default:
-   vnmc = VNMC_IM_ODD;
-   break;
-   }
-
-   /*
-* Input interface
-*/
-   switch (vin->digital->code) {
-   case MEDIA_BUS_FMT_YUYV8_1X16:
-   /* BT.601/BT.1358 16bit YCbCr422 */
-   vnmc |= VNMC_INF_YUV16;
-   input_is_yuv = true;
-   break;
-   case MEDIA_BUS_FMT_UYVY8_2X8:
-   /* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
-   vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
-   VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
-   input_is_yuv = true;
-   break;
-   case MEDIA_BUS_FMT_RGB888_1X24:
-   vnmc |= VNMC_INF_RGB888;
-   break;
-   case MEDIA_BUS_FMT_UYVY10_2X10:
-   /* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
-   vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
-   VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
-   input_is_yuv = true;
-   break;
-   default:
-   break;
-   }
-
-   /* Enable VSYNC Field Toogle mode after one VSYNC input */
-   dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
-
-   /* Hsync Signal Polarity Select */
-   if (!(vin->digital->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
-   dmr2 |= VNDMR2_HPS;
-
-   /* Vsync Signal Polarity Select */
-   if (!(vin->digital->mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
-   dmr2 |= VNDMR2_VPS;
-
-   /*
-* Output format
-*/
-   switch (vin->format.pixelformat) {
-   case V4L2_PIX_FMT_NV16:
-   rvin_write(vin,
-  ALIGN(vin->format.width * vin->format.height, 0x80),
-  VNUVAOF_REG);
-   dmr = VNDMR_DTMD_YCSEP;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_YUYV:
-   dmr = VNDMR_BPSM;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_UYVY:
-   dmr = 0;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_XRGB555:
-   dmr = VNDMR_DTMD_ARGB1555;
-   break;
-   case V4L2_PIX_FMT_RGB565:
-   dmr = 0;
-   break;
-   case V4L2_PIX_FMT_XBGR32:
-   /* Note: not supported on M1 */
-   dmr = VNDMR_EXRGB;
-   break;
-   default:
-   vin_err(vin, "Invalid pixelformat (0x%x)\n",
-   vin->format.pixelformat);
-   return -EINVAL;
-   }
-
-   /* Always update on 

[PATCH v10 14/30] rcar-vin: add flag to switch to media controller mode

[Niklas Söderlund]

On Gen3 a media controller API needs to be used to allow userspace to
configure the subdevices in the pipeline instead of directly controlling
a single source subdevice, which is and will continue to be the mode of
operation on Gen2.

Prepare for these two modes of operation by adding a flag to struct
rvin_info which will control which mode to use.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 6 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index ce1c90405c6002eb..64034c96f384b3ed 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -243,18 +243,21 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
 
 static const struct rvin_info rcar_info_h1 = {
.model = RCAR_H1,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_m1 = {
.model = RCAR_M1,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_gen2 = {
.model = RCAR_GEN2,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
@@ -349,7 +352,8 @@ static int rcar_vin_remove(struct platform_device *pdev)
v4l2_async_notifier_unregister(>notifier);
v4l2_async_notifier_cleanup(>notifier);
 
-   v4l2_ctrl_handler_free(>ctrl_handler);
+   if (!vin->info->use_mc)
+   v4l2_ctrl_handler_free(>ctrl_handler);
 
rvin_dma_unregister(vin);
 
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index a5dae5b5e9cb704b..64476bc5c8abc6d0 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -77,11 +77,13 @@ struct rvin_graph_entity {
 /**
  * struct rvin_info - Information about the particular VIN implementation
  * @model: VIN model
+ * @use_mc:use media controller instead of controlling subdevice
  * @max_width: max input width the VIN supports
  * @max_height:max input height the VIN supports
  */
 struct rvin_info {
enum model_id model;
+   bool use_mc;
 
unsigned int max_width;
unsigned int max_height;
-- 
2.16.1

[PATCH v10 19/30] rcar-vin: set a default field to fallback on

[Niklas Söderlund]

If the field is not supported by the driver it should not try to keep
the current field. Instead it should set it to a default fallback. Since
trying a format should always result in the same state regardless of the
current state of the device.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 6403650aff22a2ed..f69ae76b3fda50c7 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -23,6 +23,7 @@
 #include "rcar-vin.h"
 
 #define RVIN_DEFAULT_FORMATV4L2_PIX_FMT_YUYV
+#define RVIN_DEFAULT_FIELD V4L2_FIELD_NONE
 #define RVIN_DEFAULT_COLORSPACEV4L2_COLORSPACE_SRGB
 
 /* 
-
@@ -171,7 +172,7 @@ static int rvin_get_source_format(struct rvin_dev *vin,
fmt.format.height *= 2;
break;
default:
-   vin->format.field = V4L2_FIELD_NONE;
+   vin->format.field = RVIN_DEFAULT_FIELD;
break;
}
 
@@ -267,9 +268,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
 {
int ret;
 
-   /* Keep current field if no specific one is asked for */
if (pix->field == V4L2_FIELD_ANY)
-   pix->field = vin->format.field;
+   pix->field = RVIN_DEFAULT_FIELD;
 
/* Limit to source capabilities */
ret = __rvin_try_format_source(vin, which, pix);
-- 
2.16.1

[PATCH v10 21/30] rcar-vin: prepare for media controller mode initialization

[Niklas Söderlund]

Prepare for media controller by calling a different initialization then
for when running in device centric mode. Add trivial configuration of
the mbus and creation of the media pad for the video device entity.

While we are at it clearly mark the digital device centric notifier
functions with a comment.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 20 ++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |  4 
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 64034c96f384b3ed..0c6960756c33f86c 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -46,6 +46,10 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
direction)
return -EINVAL;
 }
 
+/* 
-
+ * Digital async notifier
+ */
+
 /* The vin lock shuld be held when calling the subdevice attach and detach */
 static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
 struct v4l2_subdev *subdev)
@@ -237,6 +241,16 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
return 0;
 }
 
+static int rvin_mc_init(struct rvin_dev *vin)
+{
+   /* All our sources are CSI-2 */
+   vin->mbus_cfg.type = V4L2_MBUS_CSI2;
+   vin->mbus_cfg.flags = 0;
+
+   vin->pad.flags = MEDIA_PAD_FL_SINK;
+   return media_entity_pads_init(>vdev.entity, 1, >pad);
+}
+
 /* 
-
  * Platform Device Driver
  */
@@ -325,8 +339,10 @@ static int rcar_vin_probe(struct platform_device *pdev)
return ret;
 
platform_set_drvdata(pdev, vin);
-
-   ret = rvin_digital_graph_init(vin);
+   if (vin->info->use_mc)
+   ret = rvin_mc_init(vin);
+   else
+   ret = rvin_digital_graph_init(vin);
if (ret < 0)
goto error;
 
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 64476bc5c8abc6d0..4caef7193db09c5b 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -101,6 +101,8 @@ struct rvin_info {
  * @notifier:  V4L2 asynchronous subdevs notifier
  * @digital:   entity in the DT for local digital subdevice
  *
+ * @pad:   media pad for the video device entity
+ *
  * @lock:  protects @queue
  * @queue: vb2 buffers queue
  *
@@ -130,6 +132,8 @@ struct rvin_dev {
struct v4l2_async_notifier notifier;
struct rvin_graph_entity *digital;
 
+   struct media_pad pad;
+
struct mutex lock;
struct vb2_queue queue;
 
-- 
2.16.1

[PATCH v10 18/30] rcar-vin: add check for colorspace

[Niklas Söderlund]

Add a check to ensure the colorspace from user-space is good. On Gen2 it
works without this change as the sensor sets the colorspace but on Gen3
this can fail if the colorspace provided by the user is not good. The
values to check for comes from v4l2-compliance sources which is the tool
that found this error. If this check is not preformed v4l2-compliance
fails when it tests colorspace.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 841d62ca27e026d7..6403650aff22a2ed 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -23,6 +23,7 @@
 #include "rcar-vin.h"
 
 #define RVIN_DEFAULT_FORMATV4L2_PIX_FMT_YUYV
+#define RVIN_DEFAULT_COLORSPACEV4L2_COLORSPACE_SRGB
 
 /* 
-
  * Format Conversions
@@ -115,6 +116,10 @@ static int rvin_format_align(struct rvin_dev *vin, struct 
v4l2_pix_format *pix)
break;
}
 
+   /* Check that colorspace is reasonable */
+   if (!pix->colorspace || pix->colorspace >= 0xff)
+   pix->colorspace = RVIN_DEFAULT_COLORSPACE;
+
/* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
 
-- 
2.16.1

[PATCH v10 16/30] rcar-vin: update bytesperline and sizeimage calculation

[Niklas Söderlund]

Remove over complicated logic to calculate the value for bytesperline
and sizeimage that was carried over from the soc_camera port. Update the
calculations to match how other drivers are doing it.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 1169e6a279ecfb55..bca6e204a574772f 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -118,10 +118,8 @@ static int rvin_format_align(struct rvin_dev *vin, struct 
v4l2_pix_format *pix)
v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
  >height, 4, vin->info->max_height, 2, 0);
 
-   pix->bytesperline = max_t(u32, pix->bytesperline,
- rvin_format_bytesperline(pix));
-   pix->sizeimage = max_t(u32, pix->sizeimage,
-  rvin_format_sizeimage(pix));
+   pix->bytesperline = rvin_format_bytesperline(pix);
+   pix->sizeimage = rvin_format_sizeimage(pix);
 
if (vin->info->model == RCAR_M1 &&
pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
@@ -270,11 +268,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
if (pix->field == V4L2_FIELD_ANY)
pix->field = vin->format.field;
 
-
-   /* Always recalculate */
-   pix->bytesperline = 0;
-   pix->sizeimage = 0;
-
/* Limit to source capabilities */
ret = __rvin_try_format_source(vin, which, pix);
if (ret)
-- 
2.16.1

[PATCH v10 23/30] rcar-vin: change name of video device

[Niklas Söderlund]

The rcar-vin driver needs to be part of a media controller to support
Gen3. Give each VIN instance a unique name so it can be referenced from
userspace.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 292e1f22a4be36c7..3ac6cdcb18ce4a21 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -1012,7 +1012,7 @@ int rvin_v4l2_register(struct rvin_dev *vin)
/* video node */
vdev->v4l2_dev = >v4l2_dev;
vdev->queue = >queue;
-   strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name));
+   snprintf(vdev->name, sizeof(vdev->name), "VIN%u output", vin->id);
vdev->release = video_device_release_empty;
vdev->lock = >lock;
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
-- 
2.16.1

[PATCH v10 28/30] rcar-vin: enable support for r8a7795

[Niklas Söderlund]

Add the SoC specific information for Renesas r8a7795 ES1.x and ES2.0.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/Kconfig |   2 +-
 drivers/media/platform/rcar-vin/rcar-core.c | 120 
 2 files changed, 121 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/Kconfig 
b/drivers/media/platform/rcar-vin/Kconfig
index af4c98b44d2e22cb..8fa7ee468c63afb9 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -6,7 +6,7 @@ config VIDEO_RCAR_VIN
select V4L2_FWNODE
---help---
  Support for Renesas R-Car Video Input (VIN) driver.
- Supports R-Car Gen2 SoCs.
+ Supports R-Car Gen2 and Gen3 SoCs.
 
  To compile this driver as a module, choose M here: the
  module will be called rcar-vin.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 7ceff0de40078580..43d2fa83875817f0 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -815,6 +816,104 @@ static const struct rvin_info rcar_info_gen2 = {
.max_height = 2048,
 };
 
+static const struct rvin_group_route rcar_info_r8a7795_routes[] = {
+   { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
+   { .vin = 0, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
+   { .vin = 0, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(2) },
+   { .vin = 1, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
+   { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(1) | BIT(3) },
+   { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
+   { .vin = 1, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
+   { .vin = 2, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(0) },
+   { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
+   { .vin = 2, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
+   { .vin = 2, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
+   { .vin = 2, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
+   { .vin = 3, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
+   { .vin = 3, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) | BIT(2) },
+   { .vin = 3, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
+   { .vin = 3, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
+   { .vin = 4, .csi = RVIN_CSI41, .chan = 0, .mask = BIT(0) | BIT(3) },
+   { .vin = 4, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
+   { .vin = 4, .csi = RVIN_CSI41, .chan = 1, .mask = BIT(2) },
+   { .vin = 5, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
+   { .vin = 5, .csi = RVIN_CSI41, .chan = 1, .mask = BIT(1) | BIT(3) },
+   { .vin = 5, .csi = RVIN_CSI41, .chan = 0, .mask = BIT(2) },
+   { .vin = 5, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
+   { .vin = 6, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(0) },
+   { .vin = 6, .csi = RVIN_CSI41, .chan = 0, .mask = BIT(1) },
+   { .vin = 6, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
+   { .vin = 6, .csi = RVIN_CSI41, .chan = 2, .mask = BIT(3) },
+   { .vin = 6, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
+   { .vin = 7, .csi = RVIN_CSI41, .chan = 1, .mask = BIT(0) },
+   { .vin = 7, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) | BIT(2) },
+   { .vin = 7, .csi = RVIN_CSI41, .chan = 3, .mask = BIT(3) },
+   { .vin = 7, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
+   { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a7795 = {
+   .model = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+   .routes = rcar_info_r8a7795_routes,
+};
+
+static const struct rvin_group_route rcar_info_r8a7795es1_routes[] = {
+   { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
+   { .vin = 0, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
+   { .vin = 0, .csi = RVIN_CSI21, .chan = 0, .mask = BIT(2) | BIT(5) },
+   { .vin = 1, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
+   { .vin = 1, .csi = RVIN_CSI21, .chan = 0, .mask = BIT(1) },
+   { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
+   { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
+   { .vin = 1, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
+   { .vin = 1, .csi = RVIN_CSI21, .chan = 1, .mask = BIT(5) },
+   { .vin = 2, .csi = RVIN_CSI21, .chan = 0, .mask = BIT(0) },
+   { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
+   { .vin = 2, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
+   { .vin = 2, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
+   { .vin = 2, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
+   { .vin = 2, .csi = RVIN_CSI21, 

[PATCH v10 30/30] rcar-vin: enable support for r8a77970

[Niklas Söderlund]

Add the SoC specific information for Renesas r8a77970.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 2305fedd293db241..496b7d2189d73d37 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -954,6 +954,25 @@ static const struct rvin_info rcar_info_r8a7796 = {
.routes = rcar_info_r8a7796_routes,
 };
 
+static const struct rvin_group_route _rcar_info_r8a77970_routes[] = {
+   { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
+   { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
+   { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
+   { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
+   { .vin = 2, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
+   { .vin = 3, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
+   { .vin = 3, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
+   { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a77970 = {
+   .model = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+   .routes = _rcar_info_r8a77970_routes,
+};
+
 static const struct of_device_id rvin_of_id_table[] = {
{
.compatible = "renesas,vin-r8a7778",
@@ -991,6 +1010,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,vin-r8a7796",
.data = _info_r8a7796,
},
+   {
+   .compatible = "renesas,vin-r8a77970",
+   .data = _info_r8a77970,
+   },
{ /* Sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);
-- 
2.16.1

[PATCH v10 29/30] rcar-vin: enable support for r8a7796

[Niklas Söderlund]

Add the SoC specific information for Renesas r8a7796.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 44 +
 1 file changed, 44 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 43d2fa83875817f0..2305fedd293db241 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -914,6 +914,46 @@ static const struct rvin_info rcar_info_r8a7795es1 = {
.routes = rcar_info_r8a7795es1_routes,
 };
 
+static const struct rvin_group_route rcar_info_r8a7796_routes[] = {
+   { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
+   { .vin = 0, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
+   { .vin = 1, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
+   { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
+   { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
+   { .vin = 1, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
+   { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
+   { .vin = 2, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
+   { .vin = 2, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
+   { .vin = 2, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
+   { .vin = 3, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
+   { .vin = 3, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) },
+   { .vin = 3, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
+   { .vin = 3, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
+   { .vin = 4, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
+   { .vin = 4, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
+   { .vin = 5, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
+   { .vin = 5, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
+   { .vin = 5, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
+   { .vin = 5, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
+   { .vin = 6, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
+   { .vin = 6, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
+   { .vin = 6, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
+   { .vin = 6, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
+   { .vin = 7, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
+   { .vin = 7, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) },
+   { .vin = 7, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
+   { .vin = 7, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
+   { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a7796 = {
+   .model = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+   .routes = rcar_info_r8a7796_routes,
+};
+
 static const struct of_device_id rvin_of_id_table[] = {
{
.compatible = "renesas,vin-r8a7778",
@@ -947,6 +987,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,vin-r8a7795",
.data = _info_r8a7795,
},
+   {
+   .compatible = "renesas,vin-r8a7796",
+   .data = _info_r8a7796,
+   },
{ /* Sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);
-- 
2.16.1

[PATCH v10 25/30] rcar-vin: parse Gen3 OF and setup media graph

[Niklas Söderlund]

The parsing and registering CSI-2 subdevices with the v4l2 async
framework is a collaborative effort shared between the VIN instances
which are part of the group. When the last VIN in the group is probed it
asks all other VINs to parse its share of OF and record the async
subdevices it finds in the notifier belonging to the last probed VIN.

Once all CSI-2 subdevices in this notifier are bound proceed to register
all VIN video devices of the group and crate media device links between
all CSI-2 and VIN entities according to the SoC specific routing
configuration.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 250 +++-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  12 +-
 2 files changed, 258 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 4a64df5019ce45f7..f08277a0dc11f477 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -27,6 +27,23 @@
 
 #include "rcar-vin.h"
 
+/*
+ * The companion CSI-2 receiver driver (rcar-csi2) is known
+ * and we know it have one source pad (pad 0) and four sink
+ * pads (pad 1-4). So to translate a pad on the remote
+ * CSI-2 receiver to/from the VIN internal channel number simply
+ * subtract/add or one from the pad/chan number.
+ */
+#define rvin_group_csi_pad_to_chan(pad) ((pad) - 1)
+#define rvin_group_csi_chan_to_pad(chan) ((chan) + 1)
+
+/*
+ * Not all VINs are created equal, master VINs control the
+ * routing for other VIN's. We can figure out which VIN is
+ * master by looking at a VINs id
+ */
+#define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
+
 /* 
-
  * Gen3 CSI2 Group Allocator
  */
@@ -77,6 +94,8 @@ static int rvin_group_init(struct rvin_group *group, struct 
rvin_dev *vin)
snprintf(mdev->bus_info, sizeof(mdev->bus_info), "platform:%s",
 dev_name(mdev->dev));
 
+   group->notifier = NULL;
+
media_device_init(mdev);
 
ret = media_device_register(>mdev);
@@ -406,6 +425,218 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
return 0;
 }
 
+/* 
-
+ * Group async notifier
+ */
+
+static int rvin_group_notify_complete(struct v4l2_async_notifier *notifier)
+{
+   struct rvin_dev *vin = notifier_to_vin(notifier);
+   const struct rvin_group_route *route;
+   unsigned int i;
+   int ret;
+
+   ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
+   if (ret) {
+   vin_err(vin, "Failed to register subdev nodes\n");
+   return ret;
+   }
+
+   /* Register all video nodes for the group */
+   for (i = 0; i < RCAR_VIN_NUM; i++) {
+   if (vin->group->vin[i]) {
+   ret = rvin_v4l2_register(vin->group->vin[i]);
+   if (ret)
+   return ret;
+   }
+   }
+
+   /* Create all media device links between VINs and CSI-2's */
+   mutex_lock(>group->lock);
+   for (route = vin->info->routes; route->mask; route++) {
+   struct media_pad *source_pad, *sink_pad;
+   struct media_entity *source, *sink;
+   unsigned int source_idx;
+
+   /* Check that VIN is part of the group */
+   if (!vin->group->vin[route->vin])
+   continue;
+
+   /* Check that VIN' master is part of the group */
+   if (!vin->group->vin[rvin_group_id_to_master(route->vin)])
+   continue;
+
+   /* Check that CSI-2 is part of the group */
+   if (!vin->group->csi[route->csi].subdev)
+   continue;
+
+   source = >group->csi[route->csi].subdev->entity;
+   source_idx = rvin_group_csi_chan_to_pad(route->chan);
+   source_pad = >pads[source_idx];
+
+   sink = >group->vin[route->vin]->vdev.entity;
+   sink_pad = >pads[0];
+
+   /* Skip if link already exists */
+   if (media_entity_find_link(source_pad, sink_pad))
+   continue;
+
+   ret = media_create_pad_link(source, source_idx, sink, 0, 0);
+   if (ret) {
+   vin_err(vin, "Error adding link from %s to %s\n",
+   source->name, sink->name);
+   break;
+   }
+   }
+   mutex_unlock(>group->lock);
+
+   return ret;
+}
+
+static void rvin_group_notify_unbind(struct v4l2_async_notifier *notifier,
+struct v4l2_subdev *subdev,
+struct v4l2_async_subdev *asd)
+{
+   struct rvin_dev *vin = 

[PATCH v10 27/30] rcar-vin: extend {start,stop}_streaming to work with media controller

[Niklas Söderlund]

The procedure to start or stop streaming using the non-MC single
subdevice and the MC graph and multiple subdevices are quite different.
Create a new function to abstract which method is used based on which
mode the driver is running in and add logic to start the MC graph.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 123 +++--
 1 file changed, 116 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 811d8f8638d21200..6784e7eb3d96e1c0 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1087,15 +1087,126 @@ static void rvin_buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(>qlock, flags);
 }
 
+static int rvin_set_stream(struct rvin_dev *vin, int on)
+{
+   struct v4l2_subdev_format fmt = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   struct media_pipeline *pipe;
+   struct media_device *mdev;
+   struct  v4l2_subdev *sd;
+   struct media_pad *pad;
+   int ret;
+
+   /* No media controller used, simply pass operation to subdevice */
+   if (!vin->info->use_mc) {
+   ret = v4l2_subdev_call(vin->digital->subdev, video, s_stream,
+  on);
+
+   return ret == -ENOIOCTLCMD ? 0 : ret;
+   }
+
+   pad = media_entity_remote_pad(>pad);
+   if (!pad)
+   return -EPIPE;
+
+   sd = media_entity_to_v4l2_subdev(pad->entity);
+
+   if (!on) {
+   media_pipeline_stop(>vdev.entity);
+   return v4l2_subdev_call(sd, video, s_stream, 0);
+   }
+
+   fmt.pad = pad->index;
+   if (v4l2_subdev_call(sd, pad, get_fmt, NULL, ))
+   return -EPIPE;
+
+   switch (fmt.format.code) {
+   case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY10_2X10:
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   vin->code = fmt.format.code;
+   break;
+   default:
+   return -EPIPE;
+   }
+
+   switch (fmt.format.field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_NONE:
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   case V4L2_FIELD_SEQ_TB:
+   case V4L2_FIELD_SEQ_BT:
+   /* Supported natively */
+   break;
+   case V4L2_FIELD_ALTERNATE:
+   switch (vin->format.field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_NONE:
+   break;
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   case V4L2_FIELD_SEQ_TB:
+   case V4L2_FIELD_SEQ_BT:
+   /* Use VIN hardware to combine the two fields */
+   fmt.format.height *= 2;
+   break;
+   default:
+   return -EPIPE;
+   }
+   break;
+   default:
+   return -EPIPE;
+   }
+
+   if (fmt.format.width != vin->format.width ||
+   fmt.format.height != vin->format.height ||
+   fmt.format.code != vin->code)
+   return -EPIPE;
+
+   mdev = vin->vdev.entity.graph_obj.mdev;
+
+   /*
+* The graph lock needs to be taken to protect concurrent
+* starts of multiple VIN instances as they might share
+* a common subdevice down the line and then should use
+* the same pipe.
+*/
+   mutex_lock(>graph_mutex);
+   pipe = sd->entity.pipe ? sd->entity.pipe : >vdev.pipe;
+   ret = __media_pipeline_start(>vdev.entity, pipe);
+   mutex_unlock(>graph_mutex);
+   if (ret)
+   return ret;
+
+   ret = v4l2_subdev_call(sd, video, s_stream, 1);
+   if (ret == -ENOIOCTLCMD)
+   ret = 0;
+   if (ret)
+   media_pipeline_stop(>vdev.entity);
+
+   return ret;
+}
+
 static int rvin_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct rvin_dev *vin = vb2_get_drv_priv(vq);
-   struct v4l2_subdev *sd;
unsigned long flags;
int ret;
 
-   sd = vin_to_source(vin);
-   v4l2_subdev_call(sd, video, s_stream, 1);
+   ret = rvin_set_stream(vin, 1);
+   if (ret) {
+   spin_lock_irqsave(>qlock, flags);
+   return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
+   spin_unlock_irqrestore(>qlock, flags);
+   return ret;
+   }
 
spin_lock_irqsave(>qlock, flags);
 
@@ -1104,7 +1215,7 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
unsigned int count)
ret = 

[PATCH v10 22/30] rcar-vin: add group allocator functions

[Niklas Söderlund]

In media controller mode all VIN instances needs to be part of the same
media graph. There is also a need for each VIN instance to know about
and in some cases be able to communicate with other VIN instances.

Add an allocator framework where the first VIN instance to be probed
creates a shared data structure and registers a media device.
Consecutive VINs insert themself into the global group.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 177 +++-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  31 +
 2 files changed, 206 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 0c6960756c33f86c..4a64df5019ce45f7 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -20,12 +20,177 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
 #include "rcar-vin.h"
 
+/* 
-
+ * Gen3 CSI2 Group Allocator
+ */
+
+/* FIXME:  This should if we find a system that supports more
+ * then one group for the whole system be replaced with a linked
+ * list of groups. And eventually all of this should be replaced
+ * with a global device allocator API.
+ *
+ * But for now this works as on all supported systems there will
+ * be only one group for all instances.
+ */
+
+static DEFINE_MUTEX(rvin_group_lock);
+static struct rvin_group *rvin_group_data;
+
+static void rvin_group_cleanup(struct rvin_group *group)
+{
+   media_device_unregister(>mdev);
+   media_device_cleanup(>mdev);
+   mutex_destroy(>lock);
+}
+
+static int rvin_group_init(struct rvin_group *group, struct rvin_dev *vin)
+{
+   struct media_device *mdev = >mdev;
+   const struct of_device_id *match;
+   struct device_node *np;
+   int ret;
+
+   mutex_init(>lock);
+
+   /* Count number of VINs in the system */
+   group->count = 0;
+   for_each_matching_node(np, vin->dev->driver->of_match_table)
+   if (of_device_is_available(np))
+   group->count++;
+
+   vin_dbg(vin, "found %u enabled VIN's in DT", group->count);
+
+   mdev->dev = vin->dev;
+
+   match = of_match_node(vin->dev->driver->of_match_table,
+ vin->dev->of_node);
+
+   strlcpy(mdev->driver_name, KBUILD_MODNAME, sizeof(mdev->driver_name));
+   strlcpy(mdev->model, match->compatible, sizeof(mdev->model));
+   snprintf(mdev->bus_info, sizeof(mdev->bus_info), "platform:%s",
+dev_name(mdev->dev));
+
+   media_device_init(mdev);
+
+   ret = media_device_register(>mdev);
+   if (ret)
+   rvin_group_cleanup(group);
+
+   return ret;
+}
+
+static void rvin_group_release(struct kref *kref)
+{
+   struct rvin_group *group =
+   container_of(kref, struct rvin_group, refcount);
+
+   mutex_lock(_group_lock);
+
+   rvin_group_data = NULL;
+
+   rvin_group_cleanup(group);
+
+   kfree(group);
+
+   mutex_unlock(_group_lock);
+}
+
+static int rvin_group_get(struct rvin_dev *vin)
+{
+   struct rvin_group *group;
+   u32 id;
+   int ret;
+
+   /* Make sure VIN id is present and sane */
+   ret = of_property_read_u32(vin->dev->of_node, "renesas,id", );
+   if (ret) {
+   vin_err(vin, "%pOF: No renesas,id property found\n",
+   vin->dev->of_node);
+   return -EINVAL;
+   }
+
+   if (id >= RCAR_VIN_NUM) {
+   vin_err(vin, "%pOF: Invalid renesas,id '%u'\n",
+   vin->dev->of_node, id);
+   return -EINVAL;
+   }
+
+   /* Join or create a VIN group */
+   mutex_lock(_group_lock);
+   if (rvin_group_data) {
+   group = rvin_group_data;
+   kref_get(>refcount);
+   } else {
+   group = kzalloc(sizeof(*group), GFP_KERNEL);
+   if (!group) {
+   ret = -ENOMEM;
+   goto err_group;
+   }
+
+   ret = rvin_group_init(group, vin);
+   if (ret) {
+   kfree(group);
+   vin_err(vin, "Failed to initialize group\n");
+   goto err_group;
+   }
+
+   kref_init(>refcount);
+
+   rvin_group_data = group;
+   }
+   mutex_unlock(_group_lock);
+
+   /* Add VIN to group */
+   mutex_lock(>lock);
+
+   if (group->vin[id]) {
+   vin_err(vin, "Duplicate renesas,id property value %u\n", id);
+   ret = -EINVAL;
+   goto err_vin;
+   }
+
+   group->vin[id] = vin;
+
+   vin->id = id;
+   vin->group = group;
+   vin->v4l2_dev.mdev = >mdev;
+
+   mutex_unlock(>lock);
+
+   return 0;

[PATCH v10 13/30] rcar-vin: add function to manipulate Gen3 chsel value

[Niklas Söderlund]

On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
feature of this register is that it's only present in the VIN0 and VIN4
instances. The register in VIN0 controls the routing for VIN0-3 and the
register in VIN4 controls routing for VIN4-7.

To be able to control routing from a media device this function is need
to control runtime PM for the subgroup master (VIN0 and VIN4). The
subgroup master must be switched on before the register is manipulated,
once the operation is complete it's safe to switch the master off and
the new routing will still be in effect.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 28 
 drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
 2 files changed, 30 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 2f9ad1bec1c8a92f..ae286742f15a3ab5 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -1228,3 +1229,30 @@ int rvin_dma_register(struct rvin_dev *vin, int irq)
 
return ret;
 }
+
+/* 
-
+ * Gen3 CHSEL manipulation
+ */
+
+void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
+{
+   u32 ifmd, vnmc;
+
+   pm_runtime_get_sync(vin->dev);
+
+   /* Make register writes take effect immediately */
+   vnmc = rvin_read(vin, VNMC_REG);
+   rvin_write(vin, vnmc & ~VNMC_VUP, VNMC_REG);
+
+   ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
+   VNCSI_IFMD_CSI_CHSEL(chsel);
+
+   rvin_write(vin, ifmd, VNCSI_IFMD_REG);
+
+   vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
+
+   /* Restore VNMC */
+   rvin_write(vin, vnmc, VNMC_REG);
+
+   pm_runtime_put(vin->dev);
+}
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 146683142e6533fa..a5dae5b5e9cb704b 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -165,4 +165,6 @@ const struct rvin_video_format *rvin_format_from_pixel(u32 
pixelformat);
 /* Cropping, composing and scaling */
 void rvin_crop_scale_comp(struct rvin_dev *vin);
 
+void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel);
+
 #endif
-- 
2.16.1

[PATCH v10 20/30] rcar-vin: use different v4l2 operations in media controller mode

[Niklas Söderlund]

When the driver runs in media controller mode it should not directly
control the subdevice instead userspace will be responsible for
configuring the pipeline. To be able to run in this mode a different set
of v4l2 operations needs to be used.

Add a new set of v4l2 operations to support operation without directly
interacting with the source subdevice.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  |   3 +-
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 155 +++-
 2 files changed, 154 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index ae286742f15a3ab5..811d8f8638d21200 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -628,7 +628,8 @@ static int rvin_setup(struct rvin_dev *vin)
/* Default to TB */
vnmc = VNMC_IM_FULL;
/* Use BT if video standard can be read and is 60 Hz format */
-   if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
+   if (!vin->info->use_mc &&
+   !v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
if (std & V4L2_STD_525_60)
vnmc = VNMC_IM_FULL | VNMC_FOC;
}
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index f69ae76b3fda50c7..292e1f22a4be36c7 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -18,11 +18,14 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "rcar-vin.h"
 
 #define RVIN_DEFAULT_FORMATV4L2_PIX_FMT_YUYV
+#define RVIN_DEFAULT_WIDTH 800
+#define RVIN_DEFAULT_HEIGHT600
 #define RVIN_DEFAULT_FIELD V4L2_FIELD_NONE
 #define RVIN_DEFAULT_COLORSPACEV4L2_COLORSPACE_SRGB
 
@@ -698,6 +701,83 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
.vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
 };
 
+/* 
-
+ * V4L2 Media Controller
+ */
+
+static int __rvin_mc_try_format(struct rvin_dev *vin,
+   struct v4l2_pix_format *pix)
+{
+   if (pix->field == V4L2_FIELD_ANY)
+   pix->field = RVIN_DEFAULT_FIELD;
+
+   return rvin_format_align(vin, pix);
+}
+
+static int rvin_mc_try_fmt_vid_cap(struct file *file, void *priv,
+  struct v4l2_format *f)
+{
+   struct rvin_dev *vin = video_drvdata(file);
+
+   return __rvin_mc_try_format(vin, >fmt.pix);
+}
+
+static int rvin_mc_s_fmt_vid_cap(struct file *file, void *priv,
+struct v4l2_format *f)
+{
+   struct rvin_dev *vin = video_drvdata(file);
+   int ret;
+
+   if (vb2_is_busy(>queue))
+   return -EBUSY;
+
+   ret = __rvin_mc_try_format(vin, >fmt.pix);
+   if (ret)
+   return ret;
+
+   vin->format = f->fmt.pix;
+
+   return 0;
+}
+
+static int rvin_mc_enum_input(struct file *file, void *priv,
+ struct v4l2_input *i)
+{
+   if (i->index != 0)
+   return -EINVAL;
+
+   i->type = V4L2_INPUT_TYPE_CAMERA;
+   strlcpy(i->name, "Camera", sizeof(i->name));
+
+   return 0;
+}
+
+static const struct v4l2_ioctl_ops rvin_mc_ioctl_ops = {
+   .vidioc_querycap= rvin_querycap,
+   .vidioc_try_fmt_vid_cap = rvin_mc_try_fmt_vid_cap,
+   .vidioc_g_fmt_vid_cap   = rvin_g_fmt_vid_cap,
+   .vidioc_s_fmt_vid_cap   = rvin_mc_s_fmt_vid_cap,
+   .vidioc_enum_fmt_vid_cap= rvin_enum_fmt_vid_cap,
+
+   .vidioc_enum_input  = rvin_mc_enum_input,
+   .vidioc_g_input = rvin_g_input,
+   .vidioc_s_input = rvin_s_input,
+
+   .vidioc_reqbufs = vb2_ioctl_reqbufs,
+   .vidioc_create_bufs = vb2_ioctl_create_bufs,
+   .vidioc_querybuf= vb2_ioctl_querybuf,
+   .vidioc_qbuf= vb2_ioctl_qbuf,
+   .vidioc_dqbuf   = vb2_ioctl_dqbuf,
+   .vidioc_expbuf  = vb2_ioctl_expbuf,
+   .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
+   .vidioc_streamon= vb2_ioctl_streamon,
+   .vidioc_streamoff   = vb2_ioctl_streamoff,
+
+   .vidioc_log_status  = v4l2_ctrl_log_status,
+   .vidioc_subscribe_event = rvin_subscribe_event,
+   .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
+};
+
 /* 
-
  * File Operations
  */
@@ -841,6 +921,60 @@ static const struct v4l2_file_operations 

[PATCH v10 17/30] rcar-vin: update pixelformat check for M1

[Niklas Söderlund]

If the pixelformat is not supported it should not fail but be set to
something that works. While we are at it move the check together with
other pixelformat checks of this function.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index bca6e204a574772f..841d62ca27e026d7 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -97,6 +97,10 @@ static int rvin_format_align(struct rvin_dev *vin, struct 
v4l2_pix_format *pix)
pix->pixelformat = RVIN_DEFAULT_FORMAT;
}
 
+   if (vin->info->model == RCAR_M1 &&
+   pix->pixelformat == V4L2_PIX_FMT_XBGR32)
+   pix->pixelformat = RVIN_DEFAULT_FORMAT;
+
/* Reject ALTERNATE  until support is added to the driver */
switch (pix->field) {
case V4L2_FIELD_TOP:
@@ -121,12 +125,6 @@ static int rvin_format_align(struct rvin_dev *vin, struct 
v4l2_pix_format *pix)
pix->bytesperline = rvin_format_bytesperline(pix);
pix->sizeimage = rvin_format_sizeimage(pix);
 
-   if (vin->info->model == RCAR_M1 &&
-   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
-   vin_err(vin, "pixel format XBGR32 not supported on M1\n");
-   return -EINVAL;
-   }
-
vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
pix->width, pix->height, pix->bytesperline, pix->sizeimage);
 
-- 
2.16.1

[PATCH v10 26/30] rcar-vin: add link notify for Gen3

[Niklas Söderlund]

Add the ability to process media device link change request. Link
enabling is a bit complicated on Gen3, whether or not it's possible to
enable a link depends on what other links already are enabled. On Gen3
the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
routing perspective these two groups are independent of each other.
Each subgroup's routing is controlled by the subgroup VIN master
instance (VIN0 and VIN4).

There are a limited number of possible route setups available for each
subgroup and the configuration of each setup is dictated by the
hardware. On H3 for example there are 6 possible route setups for each
subgroup to choose from.

This leads to the media device link notification code being rather large
since it will find the best routing configuration to try and accommodate
as many links as possible. When it's not possible to enable a new link
due to hardware constrains the link_notifier callback will return
-EMLINK.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 129 
 1 file changed, 129 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index f08277a0dc11f477..7ceff0de40078580 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 
 #include "rcar-vin.h"
 
@@ -44,6 +45,133 @@
  */
 #define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
 
+/* 
-
+ * Media Controller link notification
+ */
+
+/* group lock should be held when calling this function */
+static int rvin_group_entity_to_csi_id(struct rvin_group *group,
+   struct media_entity *entity)
+{
+   struct v4l2_subdev *sd;
+   int i;
+
+   if (!is_media_entity_v4l2_subdev(entity))
+   return -ENODEV;
+
+   sd = media_entity_to_v4l2_subdev(entity);
+
+   for (i = 0; i < RVIN_CSI_MAX; i++)
+   if (group->csi[i].subdev == sd)
+   return i;
+
+   return -ENODEV;
+}
+
+static unsigned int rvin_group_get_mask(struct rvin_dev *vin,
+   enum rvin_csi_id csi_id,
+   unsigned char chan)
+{
+   const struct rvin_group_route *route;
+   unsigned int mask = 0;
+
+   for (route = vin->info->routes; route->mask; route++) {
+   if (route->vin == vin->id &&
+   route->csi == csi_id &&
+   route->chan == chan) {
+   vin_dbg(vin, "Adding route: vin: %d csi: %d chan: %d\n",
+   route->vin, route->csi, route->chan);
+   mask |= route->mask;
+   }
+   }
+
+   return mask;
+}
+
+static int rvin_group_link_notify(struct media_link *link, u32 flags,
+ unsigned int notification)
+{
+   struct rvin_group *group = container_of(link->graph_obj.mdev,
+   struct rvin_group, mdev);
+   unsigned int i, master_id, chan, mask_new, mask = ~0;
+   struct media_entity *entity;
+   struct video_device *vdev;
+   struct media_pad *csi_pad;
+   struct rvin_dev *vin = NULL;
+   int csi_id, ret;
+
+   ret = v4l2_pipeline_link_notify(link, flags, notification);
+   if (ret)
+   return ret;
+
+   /* Only care about link enablement for VIN nodes */
+   if (!(flags & MEDIA_LNK_FL_ENABLED) ||
+   !is_media_entity_v4l2_video_device(link->sink->entity))
+   return 0;
+
+   /* If any entity are in use don't allow link changes */
+   media_device_for_each_entity(entity, >mdev)
+   if (entity->use_count)
+   return -EBUSY;
+
+   mutex_lock(>lock);
+
+   /* Find VIN and its master for which the link */
+   entity = link->sink->entity;
+   vdev = media_entity_to_video_device(entity);
+   for (i = 0; i < RCAR_VIN_NUM; i++) {
+   if (group->vin[i] && >vin[i]->vdev == vdev) {
+   vin = group->vin[i];
+   master_id = rvin_group_id_to_master(vin->id);
+   break;
+   }
+   }
+   if (WARN_ON(!vin || !group->vin[master_id])) {
+   ret = -ENODEV;
+   goto out;
+   }
+
+   /* Build a mask for already enabled links */
+   for (i = master_id; i < master_id + 4; i++) {
+   if (!group->vin[i])
+   continue;
+
+   /* Get remote CSI-2, if any */
+   csi_pad = media_entity_remote_pad(
+   >vin[i]->vdev.entity.pads[0]);
+   if (!csi_pad)
+   continue;
+
+   csi_id = 

[PATCH v10 24/30] rcar-vin: add chsel information to rvin_info

[Niklas Söderlund]

Each Gen3 SoC has a limited set of predefined routing possibilities for
which CSI-2 device and virtual channel can be routed to which VIN
instance. Prepare to store this information in the struct rvin_info.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-vin.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 903d8fb8426a7860..ca2c2a23cef8506c 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -43,6 +43,14 @@ enum model_id {
RCAR_GEN3,
 };
 
+enum rvin_csi_id {
+   RVIN_CSI20,
+   RVIN_CSI21,
+   RVIN_CSI40,
+   RVIN_CSI41,
+   RVIN_CSI_MAX,
+};
+
 /**
  * STOPPED  - No operation in progress
  * RUNNING  - Operation in progress have buffers
@@ -81,12 +89,33 @@ struct rvin_graph_entity {
unsigned int sink_pad;
 };
 
+/** struct rvin_group_route - Map a CSI-2 receiver and channel to a CHSEL
+ * @vin:   Which VIN the CSI-2 and VC describes
+ * @csi:   VIN internal number for CSI-2 device
+ * @chan:  Output channel of the CSI-2 receiver. Each R-Car CSI-2
+ * receiver has four output channels facing the VIN
+ * devices, each channel can carry one CSI-2 Virtual
+ * Channel (VC) and there are no correlation between
+ * output channel number and CSI-2 VC. It's up to the
+ * CSI-2 receiver driver to configure which VC is
+ * outputted on which channel, the VIN devices only
+ * cares about output channels.
+ * @mask:  Bitmask of chsel values which accommodates route
+ */
+struct rvin_group_route {
+   unsigned int vin;
+   enum rvin_csi_id csi;
+   unsigned char chan;
+   unsigned int mask;
+};
+
 /**
  * struct rvin_info - Information about the particular VIN implementation
  * @model: VIN model
  * @use_mc:use media controller instead of controlling subdevice
  * @max_width: max input width the VIN supports
  * @max_height:max input height the VIN supports
+ * @routes:routing table VIN <-> CSI-2 for the chsel values
  */
 struct rvin_info {
enum model_id model;
@@ -94,6 +123,7 @@ struct rvin_info {
 
unsigned int max_width;
unsigned int max_height;
+   const struct rvin_group_route *routes;
 };
 
 /**
-- 
2.16.1

[PATCH v10 11/30] rcar-vin: move media bus configuration to struct rvin_info

[Niklas Söderlund]

Bus configuration will once the driver is extended to support Gen3
contain information not specific to only the directly connected parallel
subdevice. Move it to struct rvin_dev to show it's not always coupled
to the parallel subdevice.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 18 +-
 drivers/media/platform/rcar-vin/rcar-dma.c  | 11 ++-
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  2 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  9 -
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index cc863e4ec9a4d4b3..ce1c90405c6002eb 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -65,10 +65,10 @@ static int rvin_digital_subdevice_attach(struct rvin_dev 
*vin,
vin->digital->sink_pad = ret < 0 ? 0 : ret;
 
/* Find compatible subdevices mbus format */
-   vin->digital->code = 0;
+   vin->code = 0;
code.index = 0;
code.pad = vin->digital->source_pad;
-   while (!vin->digital->code &&
+   while (!vin->code &&
   !v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
code.index++;
switch (code.code) {
@@ -76,16 +76,16 @@ static int rvin_digital_subdevice_attach(struct rvin_dev 
*vin,
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
-   vin->digital->code = code.code;
+   vin->code = code.code;
vin_dbg(vin, "Found media bus format for %s: %d\n",
-   subdev->name, vin->digital->code);
+   subdev->name, vin->code);
break;
default:
break;
}
}
 
-   if (!vin->digital->code) {
+   if (!vin->code) {
vin_err(vin, "Unsupported media bus format for %s\n",
subdev->name);
return -EINVAL;
@@ -190,16 +190,16 @@ static int rvin_digital_parse_v4l2(struct device *dev,
if (vep->base.port || vep->base.id)
return -ENOTCONN;
 
-   rvge->mbus_cfg.type = vep->bus_type;
+   vin->mbus_cfg.type = vep->bus_type;
 
-   switch (rvge->mbus_cfg.type) {
+   switch (vin->mbus_cfg.type) {
case V4L2_MBUS_PARALLEL:
vin_dbg(vin, "Found PARALLEL media bus\n");
-   rvge->mbus_cfg.flags = vep->bus.parallel.flags;
+   vin->mbus_cfg.flags = vep->bus.parallel.flags;
break;
case V4L2_MBUS_BT656:
vin_dbg(vin, "Found BT656 media bus\n");
-   rvge->mbus_cfg.flags = 0;
+   vin->mbus_cfg.flags = 0;
break;
default:
vin_err(vin, "Unknown media bus type\n");
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index c8831e189d362c8b..561500f65cfa2e74 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -633,7 +633,7 @@ static int rvin_setup(struct rvin_dev *vin)
/*
 * Input interface
 */
-   switch (vin->digital->code) {
+   switch (vin->code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
@@ -641,7 +641,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
-   vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
+   vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
input_is_yuv = true;
break;
@@ -650,7 +650,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
-   vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
+   vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
input_is_yuv = true;
break;
@@ -662,11 +662,11 @@ static int rvin_setup(struct rvin_dev *vin)
dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
 
/* Hsync Signal Polarity Select */
-   if (!(vin->digital->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
+   if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_HPS;
 
/* Vsync Signal Polarity Select */
-   if 

[PATCH v10 09/30] rcar-vin: read subdevice format for crop only when needed

[Niklas Söderlund]

Instead of caching the subdevice format each time the video device
format is set read it directly when it's needed. As it turns out the
format is only needed when figuring out the max rectangle for cropping.

This simplifies the code and makes it clearer what the source format is
used for.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 112 +++-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  12 ---
 2 files changed, 61 insertions(+), 63 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index c2265324c7c96308..4d5be2d0c79c9c9a 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -90,35 +90,54 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format 
*pix)
  * V4L2
  */
 
-static void rvin_reset_crop_compose(struct rvin_dev *vin)
+static int rvin_get_source_format(struct rvin_dev *vin,
+ struct v4l2_mbus_framefmt *mbus_fmt)
 {
+   struct v4l2_subdev_format fmt = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   .pad = vin->digital->source_pad,
+   };
+   int ret;
+
+   ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
+   if (ret)
+   return ret;
+
+   memcpy(mbus_fmt, , sizeof(*mbus_fmt));
+
+   return 0;
+}
+
+static int rvin_reset_crop_compose(struct rvin_dev *vin)
+{
+   struct v4l2_mbus_framefmt source_fmt;
+   int ret;
+
+   ret = rvin_get_source_format(vin, _fmt);
+   if (ret)
+   return ret;
+
vin->crop.top = vin->crop.left = 0;
-   vin->crop.width = vin->source.width;
-   vin->crop.height = vin->source.height;
+   vin->crop.width = source_fmt.width;
+   vin->crop.height = source_fmt.height;
 
vin->compose.top = vin->compose.left = 0;
vin->compose.width = vin->format.width;
vin->compose.height = vin->format.height;
+
+   return 0;
 }
 
 static int rvin_reset_format(struct rvin_dev *vin)
 {
-   struct v4l2_subdev_format fmt = {
-   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
-   };
-   struct v4l2_mbus_framefmt *mf = 
+   struct v4l2_mbus_framefmt source_fmt;
int ret;
 
-   fmt.pad = vin->digital->source_pad;
-
-   ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
+   ret = rvin_get_source_format(vin, _fmt);
if (ret)
return ret;
 
-   vin->format.width   = mf->width;
-   vin->format.height  = mf->height;
-   vin->format.colorspace  = mf->colorspace;
-   vin->format.field   = mf->field;
+   v4l2_fill_pix_format(>format, _fmt);
 
/*
 * If the subdevice uses ALTERNATE field mode and G_STD is
@@ -147,7 +166,9 @@ static int rvin_reset_format(struct rvin_dev *vin)
break;
}
 
-   rvin_reset_crop_compose(vin);
+   ret = rvin_reset_crop_compose(vin);
+   if (ret)
+   return ret;
 
vin->format.bytesperline = rvin_format_bytesperline(>format);
vin->format.sizeimage = rvin_format_sizeimage(>format);
@@ -156,9 +177,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
 }
 
 static int __rvin_try_format_source(struct rvin_dev *vin,
-   u32 which,
-   struct v4l2_pix_format *pix,
-   struct rvin_source_fmt *source)
+   u32 which, struct v4l2_pix_format *pix)
 {
struct v4l2_subdev *sd;
struct v4l2_subdev_pad_config *pad_cfg;
@@ -190,25 +209,16 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
 
v4l2_fill_pix_format(pix, );
 
-   source->width = pix->width;
-   source->height = pix->height;
-
pix->field = field;
pix->width = width;
pix->height = height;
-
-   vin_dbg(vin, "Source resolution: %ux%u\n", source->width,
-   source->height);
-
 done:
v4l2_subdev_free_pad_config(pad_cfg);
return ret;
 }
 
 static int __rvin_try_format(struct rvin_dev *vin,
-u32 which,
-struct v4l2_pix_format *pix,
-struct rvin_source_fmt *source)
+u32 which, struct v4l2_pix_format *pix)
 {
u32 walign;
int ret;
@@ -229,7 +239,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = 0;
 
/* Limit to source capabilities */
-   ret = __rvin_try_format_source(vin, which, pix, source);
+   ret = __rvin_try_format_source(vin, which, pix);
if (ret)
return ret;
 
@@ -238,7 +248,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
case V4L2_FIELD_BOTTOM:
case V4L2_FIELD_ALTERNATE:
pix->height /= 2;
-   

[PATCH v10 15/30] rcar-vin: break out format alignment and checking

[Niklas Söderlund]

Part of the format alignment and checking can be shared with the Gen3
format handling. Break that part out to a separate function.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 93 -
 1 file changed, 50 insertions(+), 43 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index c606942e59b5d934..1169e6a279ecfb55 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -86,6 +86,55 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format *pix)
return pix->bytesperline * pix->height;
 }
 
+static int rvin_format_align(struct rvin_dev *vin, struct v4l2_pix_format *pix)
+{
+   u32 walign;
+
+   /* If requested format is not supported fallback to the default */
+   if (!rvin_format_from_pixel(pix->pixelformat)) {
+   vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
+   pix->pixelformat, RVIN_DEFAULT_FORMAT);
+   pix->pixelformat = RVIN_DEFAULT_FORMAT;
+   }
+
+   /* Reject ALTERNATE  until support is added to the driver */
+   switch (pix->field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_NONE:
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   break;
+   default:
+   pix->field = V4L2_FIELD_NONE;
+   break;
+   }
+
+   /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
+   walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
+
+   /* Limit to VIN capabilities */
+   v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
+ >height, 4, vin->info->max_height, 2, 0);
+
+   pix->bytesperline = max_t(u32, pix->bytesperline,
+ rvin_format_bytesperline(pix));
+   pix->sizeimage = max_t(u32, pix->sizeimage,
+  rvin_format_sizeimage(pix));
+
+   if (vin->info->model == RCAR_M1 &&
+   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
+   vin_err(vin, "pixel format XBGR32 not supported on M1\n");
+   return -EINVAL;
+   }
+
+   vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
+   pix->width, pix->height, pix->bytesperline, pix->sizeimage);
+
+   return 0;
+}
+
 /* 
-
  * V4L2
  */
@@ -215,19 +264,12 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
 static int __rvin_try_format(struct rvin_dev *vin,
 u32 which, struct v4l2_pix_format *pix)
 {
-   u32 walign;
int ret;
 
/* Keep current field if no specific one is asked for */
if (pix->field == V4L2_FIELD_ANY)
pix->field = vin->format.field;
 
-   /* If requested format is not supported fallback to the default */
-   if (!rvin_format_from_pixel(pix->pixelformat)) {
-   vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
-   pix->pixelformat, RVIN_DEFAULT_FORMAT);
-   pix->pixelformat = RVIN_DEFAULT_FORMAT;
-   }
 
/* Always recalculate */
pix->bytesperline = 0;
@@ -238,42 +280,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
if (ret)
return ret;
 
-   /* Reject ALTERNATE  until support is added to the driver */
-   switch (pix->field) {
-   case V4L2_FIELD_TOP:
-   case V4L2_FIELD_BOTTOM:
-   case V4L2_FIELD_NONE:
-   case V4L2_FIELD_INTERLACED_TB:
-   case V4L2_FIELD_INTERLACED_BT:
-   case V4L2_FIELD_INTERLACED:
-   break;
-   default:
-   pix->field = V4L2_FIELD_NONE;
-   break;
-   }
-
-   /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
-   walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
-
-   /* Limit to VIN capabilities */
-   v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
- >height, 4, vin->info->max_height, 2, 0);
-
-   pix->bytesperline = max_t(u32, pix->bytesperline,
- rvin_format_bytesperline(pix));
-   pix->sizeimage = max_t(u32, pix->sizeimage,
-  rvin_format_sizeimage(pix));
-
-   if (vin->info->model == RCAR_M1 &&
-   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
-   vin_err(vin, "pixel format XBGR32 not supported on M1\n");
-   return -EINVAL;
-   }
-
-   vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
-   pix->width, pix->height, pix->bytesperline, pix->sizeimage);
-
-   return 0;
+   return rvin_format_align(vin, pix);
 }
 
 static int 

[PATCH v10 04/30] rcar-vin: move subdevice handling to async callbacks

[Niklas Söderlund]

In preparation for Gen3 support move the subdevice initialization and
clean up from rvin_v4l2_{register,unregister}() directly to the async
callbacks. This simplifies the addition of Gen3 support as the
rvin_v4l2_register() can be shared for both Gen2 and Gen3 while direct
subdevice control are only used on Gen2.

While moving this code drop a large comment which is copied from the
framework documentation and fold rvin_mbus_supported() into its only
caller. Also move the initialization and cleanup code to separate
functions to increase readability.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 108 +++-
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  35 -
 2 files changed, 74 insertions(+), 69 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 47f06acde2e698f2..663309ca9c04f208 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -46,46 +46,88 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
direction)
return -EINVAL;
 }
 
-static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
+/* The vin lock shuld be held when calling the subdevice attach and detach */
+static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
+struct v4l2_subdev *subdev)
 {
-   struct v4l2_subdev *sd = entity->subdev;
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
+   int ret;
 
+   /* Find source and sink pad of remote subdevice */
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
+   if (ret < 0)
+   return ret;
+   vin->digital->source_pad = ret;
+
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
+   vin->digital->sink_pad = ret < 0 ? 0 : ret;
+
+   /* Find compatible subdevices mbus format */
+   vin->digital->code = 0;
code.index = 0;
-   code.pad = entity->source_pad;
-   while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
+   code.pad = vin->digital->source_pad;
+   while (!vin->digital->code &&
+  !v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
code.index++;
switch (code.code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
-   entity->code = code.code;
-   return true;
+   vin->digital->code = code.code;
+   vin_dbg(vin, "Found media bus format for %s: %d\n",
+   subdev->name, vin->digital->code);
+   break;
default:
break;
}
}
 
-   return false;
-}
-
-static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
-{
-   struct rvin_dev *vin = notifier_to_vin(notifier);
-   int ret;
-
-   /* Verify subdevices mbus format */
-   if (!rvin_mbus_supported(vin->digital)) {
+   if (!vin->digital->code) {
vin_err(vin, "Unsupported media bus format for %s\n",
-   vin->digital->subdev->name);
+   subdev->name);
return -EINVAL;
}
 
-   vin_dbg(vin, "Found media bus format for %s: %d\n",
-   vin->digital->subdev->name, vin->digital->code);
+   /* Read tvnorms */
+   ret = v4l2_subdev_call(subdev, video, g_tvnorms, >vdev.tvnorms);
+   if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
+   return ret;
+
+   /* Add the controls */
+   ret = v4l2_ctrl_handler_init(>ctrl_handler, 16);
+   if (ret < 0)
+   return ret;
+
+   ret = v4l2_ctrl_add_handler(>ctrl_handler, subdev->ctrl_handler,
+   NULL);
+   if (ret < 0) {
+   v4l2_ctrl_handler_free(>ctrl_handler);
+   return ret;
+   }
+
+   vin->vdev.ctrl_handler = >ctrl_handler;
+
+   vin->digital->subdev = subdev;
+
+   return 0;
+}
+
+static void rvin_digital_subdevice_detach(struct rvin_dev *vin)
+{
+   rvin_v4l2_unregister(vin);
+   v4l2_ctrl_handler_free(>ctrl_handler);
+
+   vin->vdev.ctrl_handler = NULL;
+   vin->digital->subdev = NULL;
+}
+
+static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
+{
+   struct rvin_dev *vin = notifier_to_vin(notifier);
+   int ret;
 
ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
if (ret < 0) {
@@ -103,8 +145,10 @@ static void rvin_digital_notify_unbind(struct 
v4l2_async_notifier *notifier,
struct rvin_dev *vin = notifier_to_vin(notifier);
 
vin_dbg(vin, "unbind 

[PATCH v10 06/30] rcar-vin: move max width and height information to chip information

[Niklas Söderlund]

On Gen3 the max supported width and height will be different from Gen2.
Move the limits to the struct rvin_info to prepare for Gen3 support.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Kieran Bingham 
Reviewed-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-vin.h  | 5 +
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index d2b27ccff690cede..cc863e4ec9a4d4b3 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -243,14 +243,20 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
 
 static const struct rvin_info rcar_info_h1 = {
.model = RCAR_H1,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_m1 = {
.model = RCAR_M1,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_gen2 = {
.model = RCAR_GEN2,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct of_device_id rvin_of_id_table[] = {
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 0a035667c0b0e93f..8805d7911a761019 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -23,8 +23,6 @@
 #include "rcar-vin.h"
 
 #define RVIN_DEFAULT_FORMATV4L2_PIX_FMT_YUYV
-#define RVIN_MAX_WIDTH 2048
-#define RVIN_MAX_HEIGHT2048
 
 /* 
-
  * Format Conversions
@@ -258,8 +256,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
 
/* Limit to VIN capabilities */
-   v4l_bound_align_image(>width, 2, RVIN_MAX_WIDTH, walign,
- >height, 4, RVIN_MAX_HEIGHT, 2, 0);
+   v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
+ >height, 4, vin->info->max_height, 2, 0);
 
pix->bytesperline = max_t(u32, pix->bytesperline,
  rvin_format_bytesperline(pix));
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 3f49d2f2d6b88471..f195d174eeacda10 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -91,9 +91,14 @@ struct rvin_graph_entity {
 /**
  * struct rvin_info - Information about the particular VIN implementation
  * @model: VIN model
+ * @max_width: max input width the VIN supports
+ * @max_height:max input height the VIN supports
  */
 struct rvin_info {
enum model_id model;
+
+   unsigned int max_width;
+   unsigned int max_height;
 };
 
 /**
-- 
2.16.1

[PATCH v10 05/30] rcar-vin: move model information to own struct

[Niklas Söderlund]

When Gen3 support is added to the driver more than model ID will be
different for the different SoCs. To avoid a lot of if statements in the
code create a struct rvin_info to store this information.

While we are at it rename the poorly chosen enum which contains the
different model IDs from chip_id to model_id. Also sort the compatible
string entries and make use of of_device_get_match_data() which will
always work as the driver is DT only, so there's always a valid match.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Kieran Bingham 
Reviewed-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 56 +
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  3 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  | 14 ++--
 3 files changed, 55 insertions(+), 18 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 663309ca9c04f208..d2b27ccff690cede 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -241,21 +241,53 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
  * Platform Device Driver
  */
 
+static const struct rvin_info rcar_info_h1 = {
+   .model = RCAR_H1,
+};
+
+static const struct rvin_info rcar_info_m1 = {
+   .model = RCAR_M1,
+};
+
+static const struct rvin_info rcar_info_gen2 = {
+   .model = RCAR_GEN2,
+};
+
 static const struct of_device_id rvin_of_id_table[] = {
-   { .compatible = "renesas,vin-r8a7794", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7793", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7791", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
-   { .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
-   { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 },
-   { },
+   {
+   .compatible = "renesas,vin-r8a7778",
+   .data = _info_m1,
+   },
+   {
+   .compatible = "renesas,vin-r8a7779",
+   .data = _info_h1,
+   },
+   {
+   .compatible = "renesas,vin-r8a7790",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7791",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7793",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7794",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,rcar-gen2-vin",
+   .data = _info_gen2,
+   },
+   { /* Sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);
 
 static int rcar_vin_probe(struct platform_device *pdev)
 {
-   const struct of_device_id *match;
struct rvin_dev *vin;
struct resource *mem;
int irq, ret;
@@ -264,12 +296,8 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (!vin)
return -ENOMEM;
 
-   match = of_match_device(of_match_ptr(rvin_of_id_table), >dev);
-   if (!match)
-   return -ENODEV;
-
vin->dev = >dev;
-   vin->chip = (enum chip_id)match->data;
+   vin->info = of_device_get_match_data(>dev);
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (mem == NULL)
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 4a0610a6b4503501..0a035667c0b0e93f 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -266,7 +266,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = max_t(u32, pix->sizeimage,
   rvin_format_sizeimage(pix));
 
-   if (vin->chip == RCAR_M1 && pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
+   if (vin->info->model == RCAR_M1 &&
+   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
vin_err(vin, "pixel format XBGR32 not supported on M1\n");
return -EINVAL;
}
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 85cb7ec53d2b08b5..3f49d2f2d6b88471 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -29,7 +29,7 @@
 /* Address alignment mask for HW buffers */
 #define HW_BUFFER_MASK 0x7f
 
-enum chip_id {
+enum model_id {
RCAR_H1,
RCAR_M1,
RCAR_GEN2,
@@ -88,11 +88,19 @@ struct rvin_graph_entity {
unsigned int sink_pad;
 };
 
+/**
+ * struct rvin_info - Information about the particular 

[PATCH v10 10/30] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)

[Niklas Söderlund]

There was never proper support in the VIN driver to deliver ALTERNATING
field format to user-space, remove this field option. The problem is
that ALTERNATING filed order requires the sequence numbers of buffers
returned to userspace to reflect if fields where dropped or not,
something which is not possible with the VIN drivers capture logic.

The VIN driver can still capture from a video source which delivers
frames in ALTERNATING field order, but needs to combine them using the
VIN hardware into INTERLACED field order. Before this change if a source
was delivering fields using ALTERNATE the driver would default to
combining them using this hardware feature. Only if the user explicitly
requested ALTERNATE filed order would incorrect frames be delivered.

The height should not be cut in half for the format for TOP or BOTTOM
fields settings. This was a mistake and it was made visible by the
scaling refactoring. Correct behavior is that the user should request a
frame size that fits the half height frame reflected in the field
setting. If not the VIN will do its best to scale the top or bottom to
the requested format and cropping and scaling do not work as expected.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 53 +
 2 files changed, 24 insertions(+), 44 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index fd14be20a6604d7a..c8831e189d362c8b 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -617,7 +617,6 @@ static int rvin_setup(struct rvin_dev *vin)
case V4L2_FIELD_INTERLACED_BT:
vnmc = VNMC_IM_FULL | VNMC_FOC;
break;
-   case V4L2_FIELD_ALTERNATE:
case V4L2_FIELD_NONE:
if (vin->continuous) {
vnmc = VNMC_IM_ODD_EVEN;
@@ -757,18 +756,6 @@ static int rvin_get_active_slot(struct rvin_dev *vin, u32 
vnms)
return 0;
 }
 
-static enum v4l2_field rvin_get_active_field(struct rvin_dev *vin, u32 vnms)
-{
-   if (vin->format.field == V4L2_FIELD_ALTERNATE) {
-   /* If FS is set it's a Even field */
-   if (vnms & VNMS_FS)
-   return V4L2_FIELD_BOTTOM;
-   return V4L2_FIELD_TOP;
-   }
-
-   return vin->format.field;
-}
-
 static void rvin_set_slot_addr(struct rvin_dev *vin, int slot, dma_addr_t addr)
 {
const struct rvin_video_format *fmt;
@@ -941,7 +928,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
goto done;
 
/* Capture frame */
-   vin->queue_buf[slot]->field = rvin_get_active_field(vin, vnms);
+   vin->queue_buf[slot]->field = vin->format.field;
vin->queue_buf[slot]->sequence = sequence;
vin->queue_buf[slot]->vb2_buf.timestamp = ktime_get_ns();
vb2_buffer_done(>queue_buf[slot]->vb2_buf, VB2_BUF_STATE_DONE);
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 4d5be2d0c79c9c9a..9f7902d29c62e205 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -103,6 +103,28 @@ static int rvin_get_source_format(struct rvin_dev *vin,
if (ret)
return ret;
 
+   switch (fmt.format.field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_NONE:
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   break;
+   case V4L2_FIELD_ALTERNATE:
+   /*
+* Driver do not (yet) support outputting ALTERNATE to a
+* userspace. It dose support outputting INTERLACED so use
+* the VIN hardware to combine the two fields.
+*/
+   fmt.format.field = V4L2_FIELD_INTERLACED;
+   fmt.format.height *= 2;
+   break;
+   default:
+   vin->format.field = V4L2_FIELD_NONE;
+   break;
+   }
+
memcpy(mbus_fmt, , sizeof(*mbus_fmt));
 
return 0;
@@ -139,33 +161,6 @@ static int rvin_reset_format(struct rvin_dev *vin)
 
v4l2_fill_pix_format(>format, _fmt);
 
-   /*
-* If the subdevice uses ALTERNATE field mode and G_STD is
-* implemented use the VIN HW to combine the two fields to
-* one INTERLACED frame. The ALTERNATE field mode can still
-* be requested in S_FMT and be respected, this is just the
-* default which is applied at probing or when S_STD is called.
-*/
-   if (vin->format.field == V4L2_FIELD_ALTERNATE &&
-   v4l2_subdev_has_op(vin_to_source(vin), video, g_std))
-   vin->format.field = 

[PATCH v10 08/30] rcar-vin: all Gen2 boards can scale simplify logic

[Niklas Söderlund]

The logic to preserve the requested format width and height are too
complex and come from a premature optimization for Gen3. All Gen2 SoC
can scale and the Gen3 implementation will not use these functions at
all so simply preserve the width and height when interacting with the
subdevice much like the field is preserved simplifies the logic quite a
bit.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  |  8 
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 25 +++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |  2 --
 3 files changed, 11 insertions(+), 24 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index a7cda3922cb74baa..fd14be20a6604d7a 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -585,14 +585,6 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
0, 0);
 }
 
-void rvin_scale_try(struct rvin_dev *vin, struct v4l2_pix_format *pix,
-   u32 width, u32 height)
-{
-   /* All VIN channels on Gen2 have scalers */
-   pix->width = width;
-   pix->height = height;
-}
-
 /* 
-
  * Hardware setup
  */
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 8805d7911a761019..c2265324c7c96308 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -166,6 +166,7 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
.which = which,
};
enum v4l2_field field;
+   u32 width, height;
int ret;
 
sd = vin_to_source(vin);
@@ -178,7 +179,10 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
 
format.pad = vin->digital->source_pad;
 
+   /* Allow the video device to override field and to scale */
field = pix->field;
+   width = pix->width;
+   height = pix->height;
 
ret = v4l2_subdev_call(sd, pad, set_fmt, pad_cfg, );
if (ret < 0 && ret != -ENOIOCTLCMD)
@@ -186,11 +190,13 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
 
v4l2_fill_pix_format(pix, );
 
-   pix->field = field;
-
source->width = pix->width;
source->height = pix->height;
 
+   pix->field = field;
+   pix->width = width;
+   pix->height = height;
+
vin_dbg(vin, "Source resolution: %ux%u\n", source->width,
source->height);
 
@@ -204,13 +210,9 @@ static int __rvin_try_format(struct rvin_dev *vin,
 struct v4l2_pix_format *pix,
 struct rvin_source_fmt *source)
 {
-   u32 rwidth, rheight, walign;
+   u32 walign;
int ret;
 
-   /* Requested */
-   rwidth = pix->width;
-   rheight = pix->height;
-
/* Keep current field if no specific one is asked for */
if (pix->field == V4L2_FIELD_ANY)
pix->field = vin->format.field;
@@ -248,10 +250,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
break;
}
 
-   /* If source can't match format try if VIN can scale */
-   if (source->width != rwidth || source->height != rheight)
-   rvin_scale_try(vin, pix, rwidth, rheight);
-
/* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
 
@@ -270,9 +268,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
return -EINVAL;
}
 
-   vin_dbg(vin, "Requested %ux%u Got %ux%u bpl: %d size: %d\n",
-   rwidth, rheight, pix->width, pix->height,
-   pix->bytesperline, pix->sizeimage);
+   vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
+   pix->width, pix->height, pix->bytesperline, pix->sizeimage);
 
return 0;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index f195d174eeacda10..8daba9db0e927a49 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -175,8 +175,6 @@ void rvin_v4l2_unregister(struct rvin_dev *vin);
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 
 /* Cropping, composing and scaling */
-void rvin_scale_try(struct rvin_dev *vin, struct v4l2_pix_format *pix,
-   u32 width, u32 height);
 void rvin_crop_scale_comp(struct rvin_dev *vin);
 
 #endif
-- 
2.16.1

[PATCH v10 03/30] rcar-vin: unregister video device on driver removal

[Niklas Söderlund]

If the video device was registered by the complete() callback it should
be unregistered when a device is unbound from the driver. Protect from
printing an uninitialized video device node name by adding a check in
rvin_v4l2_unregister() to identify that the video device is registered.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Kieran Bingham 
Reviewed-by: Hans Verkuil 
Acked-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 2bedf20abcf3ca07..47f06acde2e698f2 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -272,6 +272,8 @@ static int rcar_vin_remove(struct platform_device *pdev)
 
pm_runtime_disable(>dev);
 
+   rvin_v4l2_unregister(vin);
+
v4l2_async_notifier_unregister(>notifier);
v4l2_async_notifier_cleanup(>notifier);
 
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 178aecc94962abe2..32a658214f48fa49 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -841,6 +841,9 @@ static const struct v4l2_file_operations rvin_fops = {
 
 void rvin_v4l2_unregister(struct rvin_dev *vin)
 {
+   if (!video_is_registered(>vdev))
+   return;
+
v4l2_info(>v4l2_dev, "Removing %s\n",
  video_device_node_name(>vdev));
 
-- 
2.16.1

[PATCH v10 01/30] rcar-vin: add Gen3 devicetree bindings documentation

[Niklas Söderlund]

Document the devicetree bindings for the CSI-2 inputs available on Gen3.

There is a need to add a custom property 'renesas,id' and to define
which CSI-2 input is described in which endpoint under the port@1 node.
This information is needed since there are a set of predefined routes
between each VIN and CSI-2 block. This routing table will be kept
inside the driver but in order for it to act on it it must know which
VIN and CSI-2 is which.

Signed-off-by: Niklas Söderlund 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/rcar_vin.txt | 118 ++---
 1 file changed, 106 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index c60e6b0a89b67a8c..90d92836284b7f68 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
 ---
 
 The rcar_vin device provides video input capabilities for the Renesas R-Car
-family of devices. The current blocks are always slaves and suppot one input
-channel which can be either RGB, YUYV or BT656.
+family of devices.
+
+Each VIN instance has a single parallel input that supports RGB and YUV video,
+with both external synchronization and BT.656 synchronization for the latter.
+Depending on the instance the VIN input is connected to external SoC pins, or
+on Gen3 platforms to a CSI-2 receiver.
 
  - compatible: Must be one or more of the following
- "renesas,vin-r8a7743" for the R8A7743 device
@@ -16,6 +20,8 @@ channel which can be either RGB, YUYV or BT656.
- "renesas,vin-r8a7793" for the R8A7793 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7795" for the R8A7795 device
+   - "renesas,vin-r8a7796" for the R8A7796 device
+   - "renesas,vin-r8a77970" for the R8A77970 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
  device.
- "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
@@ -31,21 +37,38 @@ channel which can be either RGB, YUYV or BT656.
 Additionally, an alias named vinX will need to be created to specify
 which video input device this is.
 
-The per-board settings:
+The per-board settings Gen2 platforms:
  - port sub-node describing a single endpoint connected to the vin
as described in video-interfaces.txt[1]. Only the first one will
be considered as each vin interface has one input port.
 
-   These settings are used to work out video input format and widths
-   into the system.
+The per-board settings Gen3 platforms:
 
+Gen3 platforms can support both a single connected parallel input source
+from external SoC pins (port0) and/or multiple parallel input sources
+from local SoC CSI-2 receivers (port1) depending on SoC.
 
-Device node example

+- renesas,id - ID number of the VIN, VINx in the documentation.
+- ports
+- port 0 - sub-node describing a single endpoint connected to the VIN
+  from external SoC pins described in video-interfaces.txt[1].
+  Describing more then one endpoint in port 0 is invalid. Only VIN
+  instances that are connected to external pins should have port 0.
+- port 1 - sub-nodes describing one or more endpoints connected to
+  the VIN from local SoC CSI-2 receivers. The endpoint numbers must
+  use the following schema.
 
-   aliases {
-  vin0 = 
-   };
+- Endpoint 0 - sub-node describing the endpoint connected to CSI20
+- Endpoint 1 - sub-node describing the endpoint connected to CSI21
+- Endpoint 2 - sub-node describing the endpoint connected to CSI40
+- Endpoint 3 - sub-node describing the endpoint connected to CSI41
+
+Device node example for Gen2 platforms
+--
+
+aliases {
+vin0 = 
+};
 
 vin0: vin@e6ef {
 compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
@@ -55,8 +78,8 @@ Device node example
 status = "disabled";
 };
 
-Board setup example (vin1 composite video input)
-
+Board setup example for Gen2 platforms (vin1 composite video input)
+---
 
{
 status = "ok";
@@ -95,6 +118,77 @@ Board setup example (vin1 composite video input)
 };
 };
 
+Device node example for Gen3 platforms
+--
 
+vin0: video@e6ef {
+compatible = "renesas,vin-r8a7795";
+reg = <0 0xe6ef 0 0x1000>;
+interrupts = ;
+clocks = < CPG_MOD 811>;
+power-domains = < R8A7795_PD_ALWAYS_ON>;
+resets = < 811>;
+

[PATCH v10 02/30] rcar-vin: rename poorly named initialize and cleanup functions

[Niklas Söderlund]

The functions to register and unregister the hardware and video device
where poorly named from the start. Rename them to better describe their
intended function.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Kieran Bingham 
Reviewed-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 10 +-
 drivers/media/platform/rcar-vin/rcar-dma.c  |  6 +++---
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  4 ++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |  8 
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index f1fc7978d6d1523d..2bedf20abcf3ca07 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -93,7 +93,7 @@ static int rvin_digital_notify_complete(struct 
v4l2_async_notifier *notifier)
return ret;
}
 
-   return rvin_v4l2_probe(vin);
+   return rvin_v4l2_register(vin);
 }
 
 static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
@@ -103,7 +103,7 @@ static void rvin_digital_notify_unbind(struct 
v4l2_async_notifier *notifier,
struct rvin_dev *vin = notifier_to_vin(notifier);
 
vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
-   rvin_v4l2_remove(vin);
+   rvin_v4l2_unregister(vin);
vin->digital->subdev = NULL;
 }
 
@@ -245,7 +245,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
 
-   ret = rvin_dma_probe(vin, irq);
+   ret = rvin_dma_register(vin, irq);
if (ret)
return ret;
 
@@ -260,7 +260,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
 
return 0;
 error:
-   rvin_dma_remove(vin);
+   rvin_dma_unregister(vin);
v4l2_async_notifier_cleanup(>notifier);
 
return ret;
@@ -275,7 +275,7 @@ static int rcar_vin_remove(struct platform_device *pdev)
v4l2_async_notifier_unregister(>notifier);
v4l2_async_notifier_cleanup(>notifier);
 
-   rvin_dma_remove(vin);
+   rvin_dma_unregister(vin);
 
return 0;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 23fdff7a7370842e..d701b52d198243b5 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1153,14 +1153,14 @@ static const struct vb2_ops rvin_qops = {
.wait_finish= vb2_ops_wait_finish,
 };
 
-void rvin_dma_remove(struct rvin_dev *vin)
+void rvin_dma_unregister(struct rvin_dev *vin)
 {
mutex_destroy(>lock);
 
v4l2_device_unregister(>v4l2_dev);
 }
 
-int rvin_dma_probe(struct rvin_dev *vin, int irq)
+int rvin_dma_register(struct rvin_dev *vin, int irq)
 {
struct vb2_queue *q = >queue;
int i, ret;
@@ -1208,7 +1208,7 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
 
return 0;
 error:
-   rvin_dma_remove(vin);
+   rvin_dma_unregister(vin);
 
return ret;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index b479b882da12f62d..178aecc94962abe2 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -839,7 +839,7 @@ static const struct v4l2_file_operations rvin_fops = {
.read   = vb2_fop_read,
 };
 
-void rvin_v4l2_remove(struct rvin_dev *vin)
+void rvin_v4l2_unregister(struct rvin_dev *vin)
 {
v4l2_info(>v4l2_dev, "Removing %s\n",
  video_device_node_name(>vdev));
@@ -866,7 +866,7 @@ static void rvin_notify(struct v4l2_subdev *sd,
}
 }
 
-int rvin_v4l2_probe(struct rvin_dev *vin)
+int rvin_v4l2_register(struct rvin_dev *vin)
 {
struct video_device *vdev = >vdev;
struct v4l2_subdev *sd = vin_to_source(vin);
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 5382078143fb3869..85cb7ec53d2b08b5 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -153,11 +153,11 @@ struct rvin_dev {
 #define vin_warn(d, fmt, arg...)   dev_warn(d->dev, fmt, ##arg)
 #define vin_err(d, fmt, arg...)dev_err(d->dev, fmt, ##arg)
 
-int rvin_dma_probe(struct rvin_dev *vin, int irq);
-void rvin_dma_remove(struct rvin_dev *vin);
+int rvin_dma_register(struct rvin_dev *vin, int irq);
+void rvin_dma_unregister(struct rvin_dev *vin);
 
-int rvin_v4l2_probe(struct rvin_dev *vin);
-void rvin_v4l2_remove(struct rvin_dev *vin);
+int rvin_v4l2_register(struct rvin_dev *vin);
+void rvin_v4l2_unregister(struct rvin_dev *vin);
 
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 

[PATCH v10 00/30] rcar-vin: Add Gen3 with media controller

[Niklas Söderlund]

Hi,

This series adds Gen3 VIN support to rcar-vin driver for Renesas r8a7795,
r8a7796 and r8a77970. It is based on the media-tree and depends on 
Fabrizio Castro patches as they touches the order of the compatible 
strings in the documentation to reduce merge conflicts. The dependencies 
are:

[PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list
[PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for 
r8a774[35]

The driver is tested on Renesas H3 (r8a7795, ES2.0),
M3-W (r8a7796) together with the rcar-csi2 driver (posted separately and
not yet upstream) and the Salvator-X onboard ADV7482. It is also tested 
on the V3M (r8a77970) on the Eagle board together with its expansion 
board with a ADV7482 and out of tree patches for GMSL capture using the 
max9286 and rdacm20 drivers.

It is possible to capture both CVBS and HDMI video streams,
v4l2-compliance passes with no errors and media-ctl can be used to
change the routing and formats for the different entities in the media
graph.

Gen2 compatibility is verified on Koelsch and no problems where found,
video can be captured just like before and v4l2-compliance passes
without errors or warnings just like before this series.

I have started on a very basic test suite for the VIN driver at:

  https://git.ragnatech.se/vin-tests

And as before the state of the driver and information about how to test
it can be found on the elinux wiki:

  http://elinux.org/R-Car/Tests:rcar-vin

* Changes since v9
- Fixed mistakes in the device tree description pointed out by  Laurent.
- GenX -> GenX platforms
- portX -> port X
- Explicitly state the on Gen3 platforms port 0 can only describe 
  one endpoint and that only VIN instances connected to external 
  pins should have a port 0 node.
- s/which is/connected to/ in he endpoint description for Gen3 
  platforms.
- Update some poorly written commit messages.
- Moved the digital subdevice attach and detach code to two separate 
  functions to increase readability.
- Rename the struct rvin_info member chip to model to better describe 
  its purpose.
- Change the video name from "rcar_vin e6ef.video" to "VINx output" 
  where x is the VIN id.
- Dropped patch 'rcar-vin: do not allow changing scaling and composing 
  while streaming' as it removed Gen2 functionality which is valid as 
  pointed out by Laurent.
- Rename rvin_get_sd_format() to rvin_get_source_format() and change its 
  parameter from struct v4l2_pix_format* to struct v4l2_mbus_framefmt*.
- Clarified commit message and add a few move comments to 'rcar-vin: fix 
  handling of single field frames (top, bottom and alternate fields'.
- Update documentation for struct rvin_dev fields mbus_cfg and code.
- Fix argument in VNCSI_IFMD_CSI_CHSEL macro.
- Renamed rvin_set_chsel() to rvin_set_channel_routing().
- Restore the VNMC register after changing CHSEL setting.
- Broke patch 'rcar-vin: break out format alignment and checking' into 
  three parts to ease review.
- Add new patch to introduce a default field.
- Only include media/v4l2-mc.h in the .c files that needs it and not in 
  rcar-vin.h.
- Rename rvin_group_allocate() rvin_group_get()
- Rename rvin_group_delete() rvin_group_put()
- Updated error message "VIN number %d already occupied\n" to "Duplicate 
  renesas,id property value %u\n".
- Removed dev_dbg messages which only where useful during development.
- Dropped patch '[PATCH v9 10/28] rcar-vin: do not reset crop and 
  compose when setting format' as it introduces a regression on Gen2.
- Inline rvin_group_read_id() and rvin_group_add_vin() into 
  rvin_group_get().
- Define static variables at the top of rcar-core.c.
- Fix potential deadlock in rvin_group_get().
- Set media device model name to the VIN module name.
- Set media device model to matched complicity string.
- Do not use a 2 dimensional sparse array for chsel values in struct 
  rvin_info, instead use a flat array and store VIN and CHSEL value 
  inside each array item.
- Reworked DT parsing code to make use of the new 
  v4l2_async_notifier_parse_fwnode_endpoints_by_port() helper removing a 
  lot of iffy custom parsing code.
- Rework how CHSEL value is calculated in the link notifier callback.
  Using a bitmap of possible values instead of looping over an array 
  turned out great reducing both LoC and increasing readability of the 
  code which was a bit difficult before. It also reduced to memory 
  needed to contain the static routing information.
- Verify the media bus pixel code when starting a stream.
- Take the media device graph lock when figuring out and starting a 
  stream so not to race between simultaneous stream start from multiple 
  rcar-vin instances as they might share common subdevices.
- Added review tags from Laurent.
- Dropped tags from patches that where changed more then just correcting 
  spelling or other gramma errors.

* Changes since v8
- Fixed issue in rvin_group_init() where 

[PATCH v4] media: dw9807: Add dw9807 vcm driver

[Andy Yeh]

From: Alan Chiang 

DW9807 is a 10 bit DAC from Dongwoon, designed for linear
control of voice coil motor.

This driver creates a V4L2 subdevice and
provides control to set the desired focus.

Signed-off-by: Andy Yeh 
---
since v1:
- changed author.
since v2:
- addressed outstanding comments.
- enabled sequential write to update 2 registers in a single transaction.
since v3:
- addressed comments for v3.
- Remove redundant codes and declar some variables as constant variable.
- separate DT binding to another patch 

 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 ++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 349 +
 4 files changed, 367 insertions(+)
 create mode 100644 drivers/media/i2c/dw9807.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..a339bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4385,6 +4385,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/dw9714.c
 
+DONGWOON DW9807 LENS VOICE COIL DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/dw9807.c
+
 DOUBLETALK DRIVER
 M: "James R. Van Zandt" 
 L: blinux-l...@redhat.com
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..fd01842 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -325,6 +325,16 @@ config VIDEO_DW9714
  capability. This is designed for linear control of
  voice coil motors, controlled via I2C serial interface.
 
+config VIDEO_DW9807
+   tristate "DW9807 lens voice coil support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the DW9807 camera lens voice coil.
+ DW9807 is a 10 bit DAC with 100mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
 config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..1b62639 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
 obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
 obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
 obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
+obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
 obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
 obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
 obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
diff --git a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c
new file mode 100644
index 000..4d243db
--- /dev/null
+++ b/drivers/media/i2c/dw9807.c
@@ -0,0 +1,349 @@
+// Copyright (C) 2018 Intel Corporation
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW9807_NAME"dw9807"
+#define DW9807_MAX_FOCUS_POS   1023
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position
+ */
+#define DW9807_FOCUS_STEPS 1
+/*
+ * This acts as the minimum granularity of lens movement.
+ * Keep this value power of 2, so the control steps can be
+ * uniformly adjusted for gradual lens movement, with desired
+ * number of control steps.
+ */
+#define DW9807_CTRL_STEPS  16
+#define DW9807_CTRL_DELAY_US   1000
+
+#define DW9807_CTL_ADDR0x02
+/*
+ * DW9807 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ */
+#define DW9807_MSB_ADDR0x03
+#define DW9807_LSB_ADDR0x04
+#define DW9807_STATUS_ADDR 0x05
+#define DW9807_MODE_ADDR   0x06
+#define DW9807_RESONANCE_ADDR  0x07
+
+#define MAX_RETRY  10
+
+struct dw9807_device {
+   struct i2c_client *client;
+   struct v4l2_ctrl_handler ctrls_vcm;
+   struct v4l2_subdev sd;
+   u16 current_val;
+};
+
+static inline struct dw9807_device *to_dw9807_vcm(struct v4l2_ctrl *ctrl)
+{
+   return container_of(ctrl->handler, struct dw9807_device, ctrls_vcm);
+}
+
+static inline struct dw9807_device *sd_to_dw9807_vcm(struct v4l2_subdev 
*subdev)
+{
+   return container_of(subdev, struct dw9807_device, sd);
+}
+
+static int dw9807_i2c_check(struct i2c_client *client)
+{
+   int ret;
+   int status_addr = DW9807_STATUS_ADDR;
+   u8 status_result = 0x1;
+
+   ret = i2c_master_send(client, (const char *)_addr, 
sizeof(status_addr));
+   if (ret != sizeof(status_addr)) {
+   dev_err(>dev, "I2C write STATUS address fail ret = 
%d\n",
+   ret);
+   return -EIO;
+   }
+
+  

[PATCH v1] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Andy Yeh]

From: Alan Chiang 

Dongwoon DW9807 is a voice coil lens driver.

Also add a vendor prefix for Dongwoon for one did not exist previously.

Signed-off-by: Andy Yeh 
---
 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt 
b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
new file mode 100644
index 000..0a1a860
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
@@ -0,0 +1,9 @@
+Dongwoon Anatech DW9807 voice coil lens driver
+
+DW9807 is a 10-bit DAC with current sink capability. It is intended for
+controlling voice coil lenses.
+
+Mandatory properties:
+
+- compatible: "dongwoon,dw9807"
+- reg: I2C slave address
-- 
2.7.4

Re: [RFC PATCH 5/8] media: Document the media request API

[Hans Verkuil]

On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
> From: Laurent Pinchart 
> 
> The media request API is made of a new ioctl to implement request
> management. Document it.
> 
> Signed-off-by: Laurent Pinchart 
> [acour...@chromium.org: adapt for newest API]
> Signed-off-by: Alexandre Courbot 
> ---
>  Documentation/media/uapi/mediactl/media-funcs.rst  |   1 +
>  .../media/uapi/mediactl/media-ioc-request-cmd.rst  | 140 
> +
>  2 files changed, 141 insertions(+)
>  create mode 100644 
> Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst
> 
> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst 
> b/Documentation/media/uapi/mediactl/media-funcs.rst
> index 076856501cdb..e3a45d82ffcb 100644
> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
> @@ -15,4 +15,5 @@ Function Reference
>  media-ioc-g-topology
>  media-ioc-enum-entities
>  media-ioc-enum-links
> +media-ioc-request-cmd
>  media-ioc-setup-link
> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst 
> b/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst
> new file mode 100644
> index ..17223e8170e9
> --- /dev/null
> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst
> @@ -0,0 +1,140 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _media_ioc_request_cmd:
> +
> +***
> +ioctl MEDIA_IOC_REQUEST_CMD
> +***
> +
> +Name
> +
> +
> +MEDIA_IOC_REQUEST_CMD - Manage media device requests
> +
> +
> +Synopsis
> +
> +
> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_CMD, struct 
> media_request_cmd *argp )
> +:name: MEDIA_IOC_REQUEST_CMD
> +
> +
> +Arguments
> +=
> +
> +``fd``
> +File descriptor returned by :ref:`open() `.
> +
> +``argp``
> +
> +
> +Description
> +===
> +
> +The MEDIA_IOC_REQUEST_CMD ioctl allow applications to manage media device
> +requests. A request is an object that can group media device configuration
> +parameters, including subsystem-specific parameters, in order to apply all 
> the
> +parameters atomically. Applications are responsible for allocating and
> +deleting requests, filling them with configuration parameters submitting 
> them.
> +
> +Request operations are performed by calling the MEDIA_IOC_REQUEST_CMD ioctl
> +with a pointer to a struct :c:type:`media_request_cmd` with the cmd field set
> +to the appropriate command. :ref:`media-request-command` lists the commands
> +supported by the ioctl.
> +
> +The struct :c:type:`media_request_cmd` request field contains the file
> +descriptorof the request on which the command operates. For the
> +``MEDIA_REQ_CMD_ALLOC`` command the field is set to zero by applications and
> +filled by the driver. For all other commands the field is set by applications
> +and left untouched by the driver.
> +
> +To allocate a new request applications use the ``MEDIA_REQ_CMD_ALLOC``
> +command. The driver will allocate a new request and return its ID in the

ID -> FD

> +request field.
> +
> +Requests are reference-counted. A newly allocated request is referenced
> +by the returned file descriptor, and can be later referenced by
> +subsystem-specific operations. Requests will thus be automatically deleted
> +when they're not longer used after the returned file descriptor is closed.
> +
> +If a request isn't needed applications can delete it by calling ``close()``
> +on it. The driver will drop the file handle reference. The request will not
> +be usable through the MEDIA_IOC_REQUEST_CMD ioctl anymore, but will only be
> +deleted when the last reference is released. If no other reference exists 
> when
> +``close()`` is invoked the request will be deleted immediately.
> +
> +After creating a request applications should fill it with configuration
> +parameters. This is performed through subsystem-specific request APIs outside
> +the scope of the media controller API. See the appropriate subsystem APIs for
> +more information, including how they interact with the MEDIA_IOC_REQUEST_CMD
> +ioctl.
> +
> +Once a request contains all the desired configuration parameters it can be
> +submitted using the ``MEDIA_REQ_CMD_SUBMIT`` command. This will let the
> +buffers queued for the request be passed to their respective drivers, which
> +will then apply the request's parameters before processing them.
> +
> +Once a request has been queued applications are not allowed to modify its
> +configuration parameters until the request has been fully processed. Any
> +attempt to do so will result in the related subsystem API returning an error.
> +The application that submitted the request can wait for its completion by
> +polling on the request's file descriptor.
> +
> +Once a request has completed, it can be reused. The ``MEDIA_REQ_CMD_REINIT``
> 

Re: [RFC PATCH 6/8] v4l2: document the request API interface

[Hans Verkuil]

On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
> Document how the request API can be used along with the existing V4L2
> interface.
> 
> Signed-off-by: Alexandre Courbot 
> ---
>  Documentation/media/uapi/v4l/buffer.rst  |  10 +-
>  Documentation/media/uapi/v4l/common.rst  |   1 +
>  Documentation/media/uapi/v4l/request-api.rst | 194 
> +++
>  Documentation/media/uapi/v4l/vidioc-qbuf.rst |  21 +++
>  4 files changed, 223 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/media/uapi/v4l/request-api.rst
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index ae6ee73f151c..9d082784081d 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -301,10 +301,14 @@ struct v4l2_buffer
>   elements in the ``planes`` array. The driver will fill in the
>   actual number of valid elements in that array.
>  * - __u32
> -  - ``reserved2``
> +  - ``request_fd``
>-
> -  - A place holder for future extensions. Drivers and applications
> - must set this to 0.
> +  - The file descriptor of the request associated with this buffer.
> + user-space can set this when calling :ref:`VIDIOC_QBUF`, and drivers
> + will return the request used when processing a buffer (if any) upon
> + :ref:`VIDIOC_DQBUF`.
> +
> + A value of 0 means the buffer is not associated with any request.
>  * - __u32
>- ``reserved``
>-
> diff --git a/Documentation/media/uapi/v4l/common.rst 
> b/Documentation/media/uapi/v4l/common.rst
> index 13f2ed3fc5a6..a4aa0059d45a 100644
> --- a/Documentation/media/uapi/v4l/common.rst
> +++ b/Documentation/media/uapi/v4l/common.rst
> @@ -44,3 +44,4 @@ applicable to all devices.
>  crop
>  selection-api
>  streaming-par
> +request-api
> diff --git a/Documentation/media/uapi/v4l/request-api.rst 
> b/Documentation/media/uapi/v4l/request-api.rst
> new file mode 100644
> index ..a758a5fd3ca0
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/request-api.rst
> @@ -0,0 +1,194 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _media-request-api:
> +
> +Request API
> +===
> +
> +The Request API has been designed to allow V4L2 to deal with requirements of
> +modern IPs (stateless codecs, MIPI cameras, ...) and APIs (Android Codec v2).
> +One such requirement is the ability for devices belonging to the same 
> pipeline
> +to reconfigure and collaborate closely on a per-frame basis. Another is
> +efficient support of stateless codecs, which need per-frame controls to be 
> set
> +asynchronously in order to be efficiently used.
> +
> +Supporting these features without the Request API is possible but terribly
> +inefficient: user-space would have to flush all activity on the media 
> pipeline,
> +reconfigure it for the next frame, queue the buffers to be processed with 
> that
> +configuration, and wait until they are all available for dequeing before
> +considering the next frame. This defeats the purpose of having buffer queues
> +since in practice only one buffer would be queued at a time.
> +
> +The Request API allows a specific configuration of the pipeline (media
> +controller topology + controls for each device) to be associated with 
> specific
> +buffers. The parameters are applied by each participating device as buffers
> +associated to a request flow in. This allows user-space to schedule several
> +tasks ("requests") with different parameters in advance, knowing that the
> +parameters will be applied when needed to get the expected result. Controls
> +values at the time of request completion are also available for reading.
> +
> +Usage
> +=
> +
> +The Request API is used on top of standard media controller and V4L2 calls,
> +which are augmented with an extra ``request_fd`` parameter. All operations on
> +requests themselves are performed using the command parameter of the
> +:c:func:`MEDIA_IOC_REQUEST_CMD` ioctl.
> +
> +Allocation
> +--
> +
> +User-space allocates requests using the ``MEDIA_REQ_CMD_ALLOC`` command on
> +an opened media device. This returns a file descriptor representing the
> +request. Typically, several such requests will be allocated.
> +
> +Request Preparation
> +---
> +
> +Standard V4L2 ioctls can then receive a request file descriptor to express 
> the
> +fact that the ioctl is part of said request, and is not to be applied
> +immediately. V4L2 ioctls supporting this are :c:func:`VIDIOC_S_EXT_CTRLS` and
> +:c:func:`VIDIOC_QBUF`. Controls set with a request parameter are stored 
> instead
> +of being immediately applied, and queued buffers will block the buffer queue
> +until the request becomes active.
> +
> +RFC Note: currently several buffers can be queued to the same queue with the
> +same request. The request parameters will be only be applied when processing
> +the first buffer. 

[PATCH v4 0/6] arm: sunxi: IR support for A83T

[Philipp Rossak]

This patch series adds support for the sunxi A83T ir module and enhances 
the sunxi-ir driver. Right now the base clock frequency for the ir driver
is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3 
the ir receiver needs, a 3 MHz base clock frequency to work without
problems with this driver.

This patch series adds support for an optinal property that makes it able
to override the default base clock frequency and enables the ir interface 
on the a83t and the Bananapi M3.

In general this is a resend of the v3 Patchseries, but with collected acked-by
and reviewed-by and some typos fixed.

changes since v3:
* collecting all acks & reviewd by
* fixed typos

changes since v2:
* reorder cir pin (alphabetical)
* fix typo in documentation

changes since v1:
* fix typos, reword Documentation
* initialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' & remove if statement
* change dev_info() to dev_dbg()
* change naming to cir* in dts/dtsi
* Added acked Ackedi-by to related patch
* use whole memory block instead of registers needed + fix for h3/h5

changes since rfc:
* The property is now optinal. If the property is not available in 
  the dtb the driver uses the default base clock frequency.
* the driver prints out the the selected base clock frequency.
* changed devicetree property from base-clk-frequency to clock-frequency

Regards,
Philipp


Philipp Rossak (6):
  media: rc: update sunxi-ir driver to get base clock frequency from
devicetree
  media: dt: bindings: Update binding documentation for sunxi IR
controller
  arm: dts: sun8i: a83t: Add the cir pin for the A83T
  arm: dts: sun8i: a83t: Add support for the cir interface
  arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
  arm: dts: sun8i: h3-h8: ir register size should be the whole memory
block

 Documentation/devicetree/bindings/media/sunxi-ir.txt |  3 +++
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts |  7 +++
 arch/arm/boot/dts/sun8i-a83t.dtsi| 15 +++
 arch/arm/boot/dts/sunxi-h3-h5.dtsi   |  2 +-
 drivers/media/rc/sunxi-cir.c | 19 +++
 5 files changed, 37 insertions(+), 9 deletions(-)

-- 
2.11.0

[PATCH v4 2/6] media: dt: bindings: Update binding documentation for sunxi IR controller

[Philipp Rossak]

This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new optional property for the base clock
frequency.

Signed-off-by: Philipp Rossak 
Acked-by: Maxime Ripard 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..278098987edb 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -11,6 +11,8 @@ Required properties:
 Optional properties:
 - linux,rc-map-name: see rc.txt file in the same directory.
 - resets : phandle + reset specifier pair
+- clock-frequency  : IR Receiver clock frequency, in Hertz. Defaults to 8 MHz
+if missing.
 
 Example:
 
@@ -18,6 +20,7 @@ ir0: ir@1c21800 {
compatible = "allwinner,sun4i-a10-ir";
clocks = <_gates 6>, <_clk>;
clock-names = "apb", "ir";
+   clock-frequency = <300>;
resets = <_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
-- 
2.11.0

[PATCH v4 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree

[Philipp Rossak]

This patch updates the sunxi-ir driver to set the base clock frequency from
devicetree.

This is necessary since there are different ir receivers on the
market, that operate with different frequencies. So this value could be
set if the attached ir receiver needs a different base clock frequency,
than the default 8 MHz.

Signed-off-by: Philipp Rossak 
Reviewed-by: Andi Shyti 
Acked-by: Sean Young 
---
 drivers/media/rc/sunxi-cir.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..f500cea228a9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,8 @@
 /* CIR_REG register idle threshold */
 #define REG_CIR_ITHR(val)(((val) << 8) & (GENMASK(15, 8)))
 
-/* Required frequency for IR0 or IR1 clock in CIR mode */
+/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
 #define SUNXI_IR_BASE_CLK 800
-/* Frequency after IR internal divider  */
-#define SUNXI_IR_CLK  (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE   (10ul / SUNXI_IR_CLK)
 /* Noise threshold in samples  */
 #define SUNXI_IR_RXNOISE  1
 /* Idle Threshold in samples */
@@ -122,7 +118,8 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
-   rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+   rawir.duration = ((dt & 0x7f) + 1) *
+ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, );
}
}
@@ -148,6 +145,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+   u32 b_clk_freq = SUNXI_IR_BASE_CLK;
 
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +170,9 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
 
+   /* Base clock frequency (optional) */
+   of_property_read_u32(dn, "clock-frequency", _clk_freq);
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,11 +181,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+   ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
}
+   dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
 
if (clk_prepare_enable(ir->apb_clk)) {
dev_err(dev, "try to enable apb_ir_clk failed\n");
@@ -225,7 +227,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
-   ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+   /* Frequency after IR internal divider with sample period in ns */
+   ir->rc->rx_resolution = (10ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
 
-- 
2.11.0

[PATCH v4 4/6] arm: dts: sun8i: a83t: Add support for the cir interface

[Philipp Rossak]

The cir interface is like on the H3 located at 0x01f02000 and is exactly
the same. This patch adds support for the ir interface on the A83T.

Signed-off-by: Philipp Rossak 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 06e96db7c41a..ddc0d592107f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -605,6 +605,16 @@
#reset-cells = <1>;
};
 
+   cir: cir@01f02000 {
+   compatible = "allwinner,sun5i-a13-ir";
+   clocks = <_ccu CLK_APB0_IR>, <_ccu CLK_IR>;
+   clock-names = "apb", "ir";
+   resets = <_ccu RST_APB0_IR>;
+   interrupts = ;
+   reg = <0x01f02000 0x400>;
+   status = "disabled";
+   };
+
r_pio: pinctrl@1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
-- 
2.11.0

[PATCH v4 3/6] arm: dts: sun8i: a83t: Add the cir pin for the A83T

[Philipp Rossak]

The CIR Pin of the A83T is located at PL12.

Signed-off-by: Philipp Rossak 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index de5119a2a91c..06e96db7c41a 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -617,6 +617,11 @@
interrupt-controller;
#interrupt-cells = <3>;
 
+   cir_pins: cir-pins@0 {
+   pins = "PL12";
+   function = "s_cir_rx";
+   };
+
r_rsb_pins: r-rsb-pins {
pins = "PL0", "PL1";
function = "s_rsb";
-- 
2.11.0

[PATCH v5 5/6] arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller

[Philipp Rossak]

The Bananapi M3 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Unlike the other IR receivers this one needs a base clock frequency
of 300 Hz (3 MHz), to be able to work.

Signed-off-by: Philipp Rossak 
Acked-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..ffc6445fd281 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -82,6 +82,13 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   clock-frequency = <300>;
+   status = "okay";
+};
+
  {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
-- 
2.11.0

[PATCH v4 6/6] arm: dts: sun8i: h3-h8: ir register size should be the whole memory block

[Philipp Rossak]

The size of the register should be the size of the whole memory block,
not just the registers, that are needed.

Signed-off-by: Philipp Rossak 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 8d40c00d64bb..a9caeda4a574 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -674,7 +674,7 @@
clock-names = "apb", "ir";
resets = <_ccu RST_APB0_IR>;
interrupts = ;
-   reg = <0x01f02000 0x40>;
+   reg = <0x01f02000 0x400>;
status = "disabled";
};
 
-- 
2.11.0

RE: [PATCH v3] media: dw9807: Add dw9807 vcm driver

[Yeh, Andy]

Hi Sakari,

All comments are all addressed, except below one. And will separate the DT 
binding.

> + while (dw9807_i2c_check(client) != 0) {
> + if (MAX_RETRY == ++retry) {
> + dev_err(>dev, "Cannot do the write operation 
> because VCM is busy\n");
> + return -EIO;
> + }
> + usleep_range(DW9807_CTRL_DELAY_US, DW9807_CTRL_DELAY_US + 10);

I wonder how common it is that you'll end up here. That'd likely be troublesome 
for the AF control. Ideally a read-only control would tell you this, but that 
could well be added later on.

Our comment:
(DW9807_STATUS_ADDR 0x05) is the read-only control. By referring to the 
datasheet as below. So Alan implemented this checking with a while loop until 
it read out 0.

"
VBUSY: VBUSY bit must be checked '0' before "VCM MSB and LSB" registers are 
written.
During ringing control mode operation, VBUSY bit keep '1'.
While VBUSY = '1', the I2C command for VCM is ignored.
"


Regards, Andy

-Original Message-
From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com] 
Sent: Friday, January 26, 2018 4:57 PM
To: Yeh, Andy 
Cc: linux-media@vger.kernel.org; tf...@chromium.org; Chiang, AlanX 

Subject: Re: [PATCH v3] media: dw9807: Add dw9807 vcm driver

Hi Andy,

There seem to be two different v3 versions of the dw9807 driver patch. I assume 
this is the right one.

A few more comments below.

On Fri, Jan 26, 2018 at 01:38:52AM +0800, Andy Yeh wrote:
> From: Alan Chiang 
> 
> DW9807 is a 10 bit DAC from Dongwoon, designed for linear control of 
> voice coil motor. This driver creates a V4L2 subdevice and provides 
> control to set the desired focus.
> 
> Signed-off-by: Andy Yeh 
> ---
> since v1:
> - changed author.
> since v2:
> - addressed outstanding comments.
> - enabled sequential write to update 2 registers in a single transaction.
> 
>  .../bindings/media/i2c/dongwoon,dw9807.txt |   9 +
>  MAINTAINERS|   7 +
>  drivers/media/i2c/Kconfig  |  10 +
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/dw9807.c | 349 
> +
>  5 files changed, 376 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
>  create mode 100644 drivers/media/i2c/dw9807.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt 
> b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> new file mode 100644
> index 000..0a1a860
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> @@ -0,0 +1,9 @@
> +Dongwoon Anatech DW9807 voice coil lens driver
> +
> +DW9807 is a 10-bit DAC with current sink capability. It is intended 
> +for controlling voice coil lenses.

Could you implement the changes proposed in the review, or if there are 
questions, answer to the comments, please?

In particular, the DT bindings should go to a separate patch.

> +
> +Mandatory properties:
> +
> +- compatible: "dongwoon,dw9807"
> +- reg: I2C slave address
> diff --git a/MAINTAINERS b/MAINTAINERS index 810d5d9..4f1704e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4385,6 +4385,13 @@ T: git git://linuxtv.org/media_tree.git
>  S:   Maintained
>  F:   drivers/media/i2c/dw9714.c
>  
> +DONGWOON DW9807 LENS VOICE COIL DRIVER
> +M:   Sakari Ailus 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/i2c/dw9807.c
> +
>  DOUBLETALK DRIVER
>  M:   "James R. Van Zandt" 
>  L:   blinux-l...@redhat.com
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig 
> index cb5d7ff..fd01842 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -325,6 +325,16 @@ config VIDEO_DW9714
> capability. This is designed for linear control of
> voice coil motors, controlled via I2C serial interface.
>  
> +config VIDEO_DW9807
> + tristate "DW9807 lens voice coil support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a driver for the DW9807 camera lens voice coil.
> +   DW9807 is a 10 bit DAC with 100mA output current sink
> +   capability. This is designed for linear control of
> +   voice coil motors, controlled via I2C serial interface.
> +
>  config VIDEO_SAA7110
>   tristate "Philips SAA7110 video decoder"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile 
> index 548a9ef..1b62639 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
>  obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
> 

Re: [PATCH 12/12] v4l2-compat-ioctl32.c: refactor, fix security bug in compat ioctl32

[Mauro Carvalho Chehab]

Em Fri, 26 Jan 2018 13:43:27 +0100
Hans Verkuil  escreveu:

> From: Daniel Mentz 
> 
> The 32-bit compat v4l2 ioctl is implemented based on its 64-bit
> equivalent. It converts 32-bit data structures into its 64-bit
> equivalents and needs to provide the data to the 64-bit ioctl in user
> space memory which is commonly allocated using
> compat_alloc_user_space(). However, due to how that function is
> implemented, it can only be called a single time for every syscall
> invocation.  Supposedly to avoid this limitation, the existing code uses
> a mix of memory from the kernel stack and memory allocated through
> compat_alloc_user_space(). Under normal circumstances, this would not
> work, because the 64-bit ioctl expects all pointers to point to user
> space memory. As a workaround, set_fs(KERNEL_DS) is called to
> temporarily disable this extra safety check and allow kernel pointers.
> However, this might introduce a security vulnerability: The
> result of the 32-bit to 64-bit conversion is writeable by user space
> because the output buffer has been allocated via
> compat_alloc_user_space(). A malicious user space process could then
> manipulate pointers inside this output buffer, and due to the previous
> set_fs(KERNEL_DS) call, functions like get_user() or put_user() no longer
> prevent kernel memory access.
> 
> The new approach is to pre-calculate the total amount of user space
> memory that is needed, allocate it using compat_alloc_user_space() and
> then divide up the allocated memory to accommodate all data structures
> that need to be converted.
> 
> An alternative approach would have been to retain the union type karg
> that they allocated on the kernel stack in do_video_ioctl(), copy all
> data from user space into karg and then back to user space. However,
> we decided against this approach because it does not align with other
> compat syscall implementations. Instead, we tried to replicate the
> get_user/put_user pairs as found in other places in the kernel:
> 
> if (get_user(clipcount, >clipcount) ||
> put_user(clipcount, >clipcount)) return -EFAULT;
> 
> Notes from hans.verk...@cisco.com:
> 
> This patch was taken from
> https://github.com/LineageOS/android_kernel_samsung_apq8084/commit/97b733953c06e4f0398ade18850f0817778255f7
> 
> Clearly nobody could be bothered to upstream this patch or at minimum
> tell us :-( We only heard about this a week ago.
> 
> This patch was rebased and cleaned up. Compared to the original I
> also swapped the order of the convert_in_user arguments so that they
> matched copy_in_user. It was hard to review otherwise. I also replaced
> the ALLOC_USER_SPACE/ALLOC_AND_GET by a normal function.
> 
> Signed-off-by: Daniel Mentz 
> Signed-off-by: Hans Verkuil 

I suspect you should add also a Co-Developed-by tag, as defined by
this changeset (at docs-next):


commit 8ee25f6fcfa967da26c5dfa43c731a61f84f7404
Author: Greg Kroah-Hartman 
Date:   Thu Nov 16 14:23:09 2017 +0100

Documentation/process: add Co-Developed-by: tag for patches with multiple 
authors

Sometimes a single patch is the result of multiple authors.  As git only
can have one "author" of a patch, it is still good to properly give
credit to the other developers of a commit.  To address this, document
the "Co-Developed-by:" tag which can be used to show other authors of
the patch.

Note, these other authors must also provide a Signed-off-by: tag as it
is their work that is being submitted here.

Reported-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 
Reviewed-by: Thomas Gleixner 
Acked-by: Borislav Petkov 
Signed-off-by: Jonathan Corbet 

diff --git a/Documentation/process/5.Posting.rst 
b/Documentation/process/5.Posting.rst
index 1b7728b19ea7..645fa9c7388a 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -213,6 +213,11 @@ The tags in common use are:
which can be found in Documentation/process/submitting-patches.rst.  Code 
without a
proper signoff cannot be merged into the mainline.
 
+ - Co-Developed-by: states that the patch was also created by another developer
+   along with the original author.  This is useful at times when multiple
+   people work on a single patch.  Note, this person also needs to have a
+   Signed-off-by: line in the patch as well.
+
  - Acked-by: indicates an agreement by another developer (often a
maintainer of the relevant code) that the patch is appropriate for
inclusion into the kernel.



> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 700 
> --
>  1 file changed, 448 insertions(+), 252 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> 

Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

[Arnd Bergmann]

On Mon, Jan 29, 2018 at 10:25 AM, Linus Walleij
 wrote:
> On Mon, Jan 29, 2018 at 9:25 AM, Maxime Ripard
>  wrote:
>> On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote:
>> However, in DT systems, that
>> field is filled only with the parent's node dma-ranges property. In
>> our case, and since the DT parenthood is based on the "control" bus,
>> and not the "data" bus, our parent node would be the AXI bus, and not
>> the memory bus that enforce those constraints.
>>
>> And other devices doing DMA through regular DMA accesses won't have
>> that mapping, so we definitely shouldn't enforce it for all the
>> devices there, but only the one connected to the separate memory bus.
>>
>> tl; dr: the DT is not really an option to store that info.
>>
>> I suggested setting dma_pfn_offset at probe, but Arnd didn't seem too
>> fond of that approach either at the time.
>>
>> So, well, I guess we could do better. We just have no idea how :)
>
> Usually of Arnd cannot suggest something smart, neither can I :(
>
> If some aspect of the memory layout of the system *really* doesn't
> fit into DT because of the assumptions that DT is doing about
> how systems work, we have a problem.
>
> Is the problem that DT's model assumes that devices have one and
> only one data port to the system memory, and that is how it
> populates the Linux devices?
>
> I guess, if nothing else works, I would use auxdata in the board file.
> It is our definitive last resort when DT doesn't hold.
>
> I.e. I would go into struct of_dev_auxdata
> (from ) and add a
> dma_pfn_offset field that gets set into the device's dma_pfn_offset
> in drivers/of/platform.c overriding anything else and use that to hammer
> it down in the boardfile.
>
> But I bet some DT people are going to have other ideas.

At one point we had discussed adding a 'dma-masters' property that
lists all the buses on which a device can be a dma master, and
the respective properties of those masters (iommu, coherency,
offset, ...).

IIRC at the time we decided that we could live without that complexity,
but perhaps we cannot.

Another local hack that we can do here is to have two separate
device nodes and let the device driver bind to one device and then
look up the other one through a phandle to look up a platform_device
for it, which it can then use with the DMA mapping interface.

  Arnd

Re: [PATCH 09/12] v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32

[Mauro Carvalho Chehab]

Em Mon, 29 Jan 2018 11:47:42 +0200
Sakari Ailus  escreveu:


> > +   compat_caddr_t p;
> > +
> > if (copy_to_user(>w, >w, sizeof(kp->w)) ||
> > put_user(kp->field, >field) ||
> > put_user(kp->chromakey, >chromakey) ||
> > put_user(kp->clipcount, >clipcount) ||
> > put_user(kp->global_alpha, >global_alpha))
> > return -EFAULT;  
> 
> One more newline here?

Why? A new line here would be weird.





Cheers,
Mauro

Re: [PATCH 08/12] v4l2-compat-ioctl32.c: fix ctrl_is_pointer

[Mauro Carvalho Chehab]

Em Sun, 28 Jan 2018 01:18:57 +0200
Sakari Ailus  escreveu:

> Hi Hans,
> 

...

> > +
> > +   if (ops->vidioc_query_ext_ctrl)
> > +   ret = ops->vidioc_query_ext_ctrl(file, fh, );  
> 
> Is there a need for this?
> 
> The only driver implementing vidioc_query_ext_ctrl op is the uvcvideo
> driver --- and it does not support string controls.

Well, one day, it could be added there, or some other driver may
need to implement it. So, better safe than sorry. I would keep it
(either as-is or with your suggestion)


Cheers,
Mauro

Re: dvb usb issues since kernel 4.9

[Mauro Carvalho Chehab]

Em Fri, 26 Jan 2018 17:37:39 -0200
Mauro Carvalho Chehab  escreveu:

> Em Fri, 26 Jan 2018 12:17:37 -0200
> Mauro Carvalho Chehab  escreveu:
> 
> > Hi Alan,
> > 
> > Em Mon, 8 Jan 2018 14:15:35 -0500 (EST)
> > Alan Stern  escreveu:
> >   
> > > On Mon, 8 Jan 2018, Linus Torvalds wrote:
> > > 
> > > > Can somebody tell which softirq it is that dvb/usb cares about?  
> > > 
> > > I don't know about the DVB part.  The USB part is a little difficult to
> > > analyze, mostly because the bug reports I've seen are mostly from
> > > people running non-vanilla kernels. 
> > 
> > I suspect that the main reason for people not using non-vanilla Kernels
> > is that, among other bugs, the dwc2 upstream driver has serious troubles
> > handling ISOCH traffic.
> > 
> > Using Kernel 4.15-rc7 from this git tree:
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=softirq_fixup
> > 
> > (e. g. with the softirq bug partially reverted with Linux patch, and
> >  the DWC2 deferred probe fixed)
> > 
> > With a PCTV 461e device, with uses em28xx driver + Montage frontend
> > (with is the same used on dvbsky hardware - except for em28xx).
> > 
> > This device doesn't support bulk for DVB, just ISOCH. The drivers work 
> > fine on x86.
> > 
> > Using a test signal at the bit rate of 56698,4 Kbits/s, that's what
> > happens, when capturing less than one second of data:
> > 
> > $ dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m 
> > -t2dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m -t2
> > Using LNBf UNIVERSAL
> > Universal, Europe
> > Freqs : 10800 to 11800 MHz, LO: 9750 MHz
> > Freqs : 11600 to 12700 MHz, LO: 10600 MHz
> > using demux 'dvb0.demux0'
> > reading channels from file '/home/mchehab/dvb_channel.conf'
> > tuning to 11468000 Hz
> >(0x00) Signal= -33.90dBm
> > Lock   (0x1f) Signal= -33.90dBm C/N= 30.28dB postBER= 2.33x10^-6
> > dvb_dev_set_bufsize: buffer set to 6160384
> >   dvb_set_pesfilter to 0x2000
> > 354.08s: Starting capture
> > 354.73s: only read 59220 bytes
> > 354.73s: Stopping capture
> > 
> > [  354.000827] dwc2 3f98.usb: DWC OTG HCD EP DISABLE: 
> > bEndpointAddress=0x84, ep->hcpriv=116f41b2
> > [  354.000859] dwc2 3f98.usb: DWC OTG HCD EP RESET: 
> > bEndpointAddress=0x84
> > [  354.010744] dwc2 3f98.usb: --Host Channel 5 Interrupt: Frame 
> > Overrun--
> > ... (hundreds of thousands of Frame Overrun messages)
> > [  354.660857] dwc2 3f98.usb: --Host Channel 5 Interrupt: Frame 
> > Overrun--
> > [  354.660935] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.660959] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.660966] dwc2 3f98.usb:   urb->status = 0
> > [  354.660992] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.661001] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.661008] dwc2 3f98.usb:   urb->status = 0
> > [  354.661054] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.661065] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.661072] dwc2 3f98.usb:   urb->status = 0
> > [  354.661107] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.661120] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.661127] dwc2 3f98.usb:   urb->status = 0
> > [  354.661146] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.661158] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.661165] dwc2 3f98.usb:   urb->status = 0  
> 
> Btw, 
> 
> Just in case, I also applied all recent pending dwc2 patches I found at
> linux-usb (even trivial unrelated ones) at:
> 
>   https://git.linuxtv.org/mchehab/experimental.git/log/?h=dwc2_patches
> 
> No differences. ISOCH is still broken.
> 
> If anyone wants to see the full logs, it is there:
>   https://pastebin.com/XJYyTwPv

Someone pointed me in priv that applying a change at DWC2 BRCM profile to
enable uframe_sched might help.

So, I wrote this patch:

https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2=19abf0026b7bf1bd44aa9d2add9f958935760ded

And applied on the top of this branch:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=v4.15%2bmedia%2bdwc2

It is based on Kernel 4.15 vanilla. I applied:
- all media -next patches that will be sent to Kernel 4.16-rc1;
- DWC2 patches submitted by Gregor at linux-usb ML;
- Linus softirq test patch:

https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2=ccf833fd4a5b99c3d3cf2c09c065670f74a230a7
- A DT patch that enables VCIQ (needed by some GPU drivers):

https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2=fd4e9ca6f41d35b6234c30fa29937141e0c09570
- a few debug patches like this one:

Re: [Patch v7 12/12] Documention: v4l: Documentation for HEVC CIDs

[Hans Verkuil]

On 01/29/2018 02:15 PM, Smitha T Murthy wrote:

>>> The values set in V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP and
>>> V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP will give the limits for the L0-L6 QP
>>> values that can be set.
>>
>> OK. If you can clarify this in the documentation, then I can Ack this.
>>
>> Note: if userspace changes MIN_QP or MAX_QP, then the driver should call
>> v4l2_ctrl_modify_range() to update the ranges of the controls that are
>> impacted by QP range changes. I'm not sure if that's done at the moment.
>>
>> Regards,
>>
>>  Hans
>>
>>
> I can mention for all these controls range as
> [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP].
> Will this be ok?

Yes, that sounds good.

Hans

Re: [Patch v7 12/12] Documention: v4l: Documentation for HEVC CIDs

[Smitha T Murthy]

On Mon, 2018-01-29 at 14:27 +0100, Hans Verkuil wrote:
> On 01/29/2018 01:42 PM, Smitha T Murthy wrote:
> > On Wed, 2018-01-24 at 15:16 +0100, Hans Verkuil wrote:
> >> On 24/01/18 11:59, Smitha T Murthy wrote:
> >>> Added V4l2 controls for HEVC encoder
> >>>
> >>> Signed-off-by: Smitha T Murthy 
> >>> ---
> >>>  Documentation/media/uapi/v4l/extended-controls.rst | 400 
> >>> +
> >>>  1 file changed, 400 insertions(+)
> >>>
> >>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> >>> b/Documentation/media/uapi/v4l/extended-controls.rst
> >>> index dfe49ae..46ee2bf 100644
> >>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> >>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> >>> @@ -1960,6 +1960,406 @@ enum v4l2_vp8_golden_frame_sel -
> >>>  1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> >>>  
> >>>  
> >>> +High Efficiency Video Coding (HEVC/H.265) Control Reference
> >>> +---
> >>> +
> >>> +The HEVC/H.265 controls include controls for encoding parameters of 
> >>> HEVC/H.265
> >>> +video codec.
> >>> +
> >>> +
> >>> +.. _hevc-control-id:
> >>> +
> >>> +HEVC/H.265 Control IDs
> >>> +^^
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)``
> >>> +Minimum quantization parameter for HEVC.
> >>> +Valid range: from 0 to 51.
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)``
> >>> +Maximum quantization parameter for HEVC.
> >>> +Valid range: from 0 to 51.
> >>
> >> You probably should mention the default values for MIN_QP and MAX_QP
> >> (I assume those are 0 and 51 and are not driver specific).
> >>
> > Yes these values are not driver specific.
> > I followed the way MAX_QP and MIN_QP are defined for other codecs like
> > H264, H263, MPEG4 where only valid range is mentioned.
> > 
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)``
> >>> +Quantization parameter for an I frame for HEVC.
> >>> +Valid range: from 0 to 51.
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (integer)``
> >>> +Quantization parameter for a P frame for HEVC.
> >>> +Valid range: from 0 to 51.
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (integer)``
> >>> +Quantization parameter for a B frame for HEVC.
> >>> +Valid range: from 0 to 51.
> >>
> >> Sorry, this still isn't clear to me.
> >>
> >> If I set V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP to 50, can I then still set
> >> V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP to 51? Or is 50 then the maximum?
> >>
> >> In other words, what is the relationship between these three controls
> >> and the MIN_QP/MAX_QP controls.
> >>
> > If we set V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP as 50 then
> > V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP or
> > 4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP or
> > V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP will have maximum as 50.
> > Similarly for minimum as well, the above three controls will adhere to
> > the V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP set.
> > These controls have similar in relation as seen with
> > V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP and V4L2_CID_MPEG_VIDEO_H264_MAX_QP 
> > 
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)``
> >>> +HIERARCHICAL_QP allows the host to specify the quantization parameter
> >>> +values for each temporal layer through HIERARCHICAL_QP_LAYER. This is
> >>> +valid only if HIERARCHICAL_CODING_LAYER is greater than 1. Setting 
> >>> the
> >>> +control value to 1 enables setting of the QP values for the layers.
> >>> +
> >>> +.. _v4l2-hevc-hier-coding-type:
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE``
> >>> +(enum)
> >>> +
> >>> +enum v4l2_mpeg_video_hevc_hier_coding_type -
> >>> +Selects the hierarchical coding type for encoding. Possible values 
> >>> are:
> >>> +
> >>> +.. raw:: latex
> >>> +
> >>> +\begin{adjustbox}{width=\columnwidth}
> >>> +
> >>> +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> >>> +
> >>> +.. flat-table::
> >>> +:header-rows:  0
> >>> +:stub-columns: 0
> >>> +
> >>> +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B``
> >>> +  - Use the B frame for hierarchical coding.
> >>> +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P``
> >>> +  - Use the P frame for hierarchical coding.
> >>> +
> >>> +.. raw:: latex
> >>> +
> >>> +\end{adjustbox}
> >>> +
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)``
> >>> +Selects the hierarchical coding layer. In normal encoding
> >>> +(non-hierarchial coding), it should be zero. Possible values are [0, 
> >>> 6].
> >>> +0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL 
> >>> CODING
> >>> +LAYER 1 and so on.
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP (integer)``
> >>> +Indicates quantization parameter for hierarchical coding layer 0.
> >>> +For HEVC it can have a value of 0-51.
> >>> +
> >>> 

Re: [Patch v7 12/12] Documention: v4l: Documentation for HEVC CIDs

[Smitha T Murthy]

On Mon, 2018-01-29 at 14:27 +0100, Hans Verkuil wrote:
> On 01/29/2018 01:42 PM, Smitha T Murthy wrote:
> > On Wed, 2018-01-24 at 15:16 +0100, Hans Verkuil wrote:
> >> On 24/01/18 11:59, Smitha T Murthy wrote:
> >>> Added V4l2 controls for HEVC encoder
> >>>
> >>> Signed-off-by: Smitha T Murthy 
> >>> ---
> >>>  Documentation/media/uapi/v4l/extended-controls.rst | 400 
> >>> +
> >>>  1 file changed, 400 insertions(+)
> >>>
> >>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> >>> b/Documentation/media/uapi/v4l/extended-controls.rst
> >>> index dfe49ae..46ee2bf 100644
> >>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> >>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> >>> @@ -1960,6 +1960,406 @@ enum v4l2_vp8_golden_frame_sel -
> >>>  1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> >>>  
> >>>  
> >>> +High Efficiency Video Coding (HEVC/H.265) Control Reference
> >>> +---
> >>> +
> >>> +The HEVC/H.265 controls include controls for encoding parameters of 
> >>> HEVC/H.265
> >>> +video codec.
> >>> +
> >>> +
> >>> +.. _hevc-control-id:
> >>> +
> >>> +HEVC/H.265 Control IDs
> >>> +^^
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)``
> >>> +Minimum quantization parameter for HEVC.
> >>> +Valid range: from 0 to 51.
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)``
> >>> +Maximum quantization parameter for HEVC.
> >>> +Valid range: from 0 to 51.
> >>
> >> You probably should mention the default values for MIN_QP and MAX_QP
> >> (I assume those are 0 and 51 and are not driver specific).
> >>
> > Yes these values are not driver specific.
> > I followed the way MAX_QP and MIN_QP are defined for other codecs like
> > H264, H263, MPEG4 where only valid range is mentioned.
> > 
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)``
> >>> +Quantization parameter for an I frame for HEVC.
> >>> +Valid range: from 0 to 51.
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (integer)``
> >>> +Quantization parameter for a P frame for HEVC.
> >>> +Valid range: from 0 to 51.
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (integer)``
> >>> +Quantization parameter for a B frame for HEVC.
> >>> +Valid range: from 0 to 51.
> >>
> >> Sorry, this still isn't clear to me.
> >>
> >> If I set V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP to 50, can I then still set
> >> V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP to 51? Or is 50 then the maximum?
> >>
> >> In other words, what is the relationship between these three controls
> >> and the MIN_QP/MAX_QP controls.
> >>
> > If we set V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP as 50 then
> > V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP or
> > 4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP or
> > V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP will have maximum as 50.
> > Similarly for minimum as well, the above three controls will adhere to
> > the V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP set.
> > These controls have similar in relation as seen with
> > V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP and V4L2_CID_MPEG_VIDEO_H264_MAX_QP 
> > 
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)``
> >>> +HIERARCHICAL_QP allows the host to specify the quantization parameter
> >>> +values for each temporal layer through HIERARCHICAL_QP_LAYER. This is
> >>> +valid only if HIERARCHICAL_CODING_LAYER is greater than 1. Setting 
> >>> the
> >>> +control value to 1 enables setting of the QP values for the layers.
> >>> +
> >>> +.. _v4l2-hevc-hier-coding-type:
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE``
> >>> +(enum)
> >>> +
> >>> +enum v4l2_mpeg_video_hevc_hier_coding_type -
> >>> +Selects the hierarchical coding type for encoding. Possible values 
> >>> are:
> >>> +
> >>> +.. raw:: latex
> >>> +
> >>> +\begin{adjustbox}{width=\columnwidth}
> >>> +
> >>> +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> >>> +
> >>> +.. flat-table::
> >>> +:header-rows:  0
> >>> +:stub-columns: 0
> >>> +
> >>> +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B``
> >>> +  - Use the B frame for hierarchical coding.
> >>> +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P``
> >>> +  - Use the P frame for hierarchical coding.
> >>> +
> >>> +.. raw:: latex
> >>> +
> >>> +\end{adjustbox}
> >>> +
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)``
> >>> +Selects the hierarchical coding layer. In normal encoding
> >>> +(non-hierarchial coding), it should be zero. Possible values are [0, 
> >>> 6].
> >>> +0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL 
> >>> CODING
> >>> +LAYER 1 and so on.
> >>> +
> >>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP (integer)``
> >>> +Indicates quantization parameter for hierarchical coding layer 0.
> >>> +For HEVC it can have a value of 0-51.
> >>> +
> >>> 

Re: [PATCH] staging: media: atomisp2: remove unused headers

[LABBE Corentin]

On Mon, Jan 29, 2018 at 03:22:33PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 29, 2018 at 3:11 PM, Corentin Labbe  wrote:
> > All thoses headers are not used by any source files.
> > Lets just remove them.
> 
> How did you test this?
> 
> P.S. I like the patch, but since driver in a state of coma vigil, I'm
> afraid you may do something which shouldn't be done for working
> driver.
> 

For testing I have:
- successfully compiling the driver
- for each file, grepping its name in tree to be sure that no one uses it.

Re: [Patch v7 12/12] Documention: v4l: Documentation for HEVC CIDs

[Hans Verkuil]

On 01/29/2018 01:42 PM, Smitha T Murthy wrote:
> On Wed, 2018-01-24 at 15:16 +0100, Hans Verkuil wrote:
>> On 24/01/18 11:59, Smitha T Murthy wrote:
>>> Added V4l2 controls for HEVC encoder
>>>
>>> Signed-off-by: Smitha T Murthy 
>>> ---
>>>  Documentation/media/uapi/v4l/extended-controls.rst | 400 
>>> +
>>>  1 file changed, 400 insertions(+)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
>>> b/Documentation/media/uapi/v4l/extended-controls.rst
>>> index dfe49ae..46ee2bf 100644
>>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>>> @@ -1960,6 +1960,406 @@ enum v4l2_vp8_golden_frame_sel -
>>>  1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
>>>  
>>>  
>>> +High Efficiency Video Coding (HEVC/H.265) Control Reference
>>> +---
>>> +
>>> +The HEVC/H.265 controls include controls for encoding parameters of 
>>> HEVC/H.265
>>> +video codec.
>>> +
>>> +
>>> +.. _hevc-control-id:
>>> +
>>> +HEVC/H.265 Control IDs
>>> +^^
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)``
>>> +Minimum quantization parameter for HEVC.
>>> +Valid range: from 0 to 51.
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)``
>>> +Maximum quantization parameter for HEVC.
>>> +Valid range: from 0 to 51.
>>
>> You probably should mention the default values for MIN_QP and MAX_QP
>> (I assume those are 0 and 51 and are not driver specific).
>>
> Yes these values are not driver specific.
> I followed the way MAX_QP and MIN_QP are defined for other codecs like
> H264, H263, MPEG4 where only valid range is mentioned.
> 
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)``
>>> +Quantization parameter for an I frame for HEVC.
>>> +Valid range: from 0 to 51.
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (integer)``
>>> +Quantization parameter for a P frame for HEVC.
>>> +Valid range: from 0 to 51.
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (integer)``
>>> +Quantization parameter for a B frame for HEVC.
>>> +Valid range: from 0 to 51.
>>
>> Sorry, this still isn't clear to me.
>>
>> If I set V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP to 50, can I then still set
>> V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP to 51? Or is 50 then the maximum?
>>
>> In other words, what is the relationship between these three controls
>> and the MIN_QP/MAX_QP controls.
>>
> If we set V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP as 50 then
> V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP or
> 4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP or
> V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP will have maximum as 50.
> Similarly for minimum as well, the above three controls will adhere to
> the V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP set.
> These controls have similar in relation as seen with
> V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP and V4L2_CID_MPEG_VIDEO_H264_MAX_QP 
> 
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)``
>>> +HIERARCHICAL_QP allows the host to specify the quantization parameter
>>> +values for each temporal layer through HIERARCHICAL_QP_LAYER. This is
>>> +valid only if HIERARCHICAL_CODING_LAYER is greater than 1. Setting the
>>> +control value to 1 enables setting of the QP values for the layers.
>>> +
>>> +.. _v4l2-hevc-hier-coding-type:
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE``
>>> +(enum)
>>> +
>>> +enum v4l2_mpeg_video_hevc_hier_coding_type -
>>> +Selects the hierarchical coding type for encoding. Possible values are:
>>> +
>>> +.. raw:: latex
>>> +
>>> +\begin{adjustbox}{width=\columnwidth}
>>> +
>>> +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
>>> +
>>> +.. flat-table::
>>> +:header-rows:  0
>>> +:stub-columns: 0
>>> +
>>> +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B``
>>> +  - Use the B frame for hierarchical coding.
>>> +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P``
>>> +  - Use the P frame for hierarchical coding.
>>> +
>>> +.. raw:: latex
>>> +
>>> +\end{adjustbox}
>>> +
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)``
>>> +Selects the hierarchical coding layer. In normal encoding
>>> +(non-hierarchial coding), it should be zero. Possible values are [0, 
>>> 6].
>>> +0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL 
>>> CODING
>>> +LAYER 1 and so on.
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP (integer)``
>>> +Indicates quantization parameter for hierarchical coding layer 0.
>>> +For HEVC it can have a value of 0-51.
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP (integer)``
>>> +Indicates quantization parameter for hierarchical coding layer 1.
>>> +For HEVC it can have a value of 0-51.
>>> +
>>> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP (integer)``
>>> +Indicates quantization parameter for hierarchical coding layer 2.
>>> +For HEVC it can have 

Re: [PATCH] staging: media: atomisp2: remove unused headers

[Andy Shevchenko]

On Mon, Jan 29, 2018 at 3:11 PM, Corentin Labbe  wrote:
> All thoses headers are not used by any source files.
> Lets just remove them.

How did you test this?

P.S. I like the patch, but since driver in a state of coma vigil, I'm
afraid you may do something which shouldn't be done for working
driver.

-- 
With Best Regards,
Andy Shevchenko

Re: [Patch v7 12/12] Documention: v4l: Documentation for HEVC CIDs

[Smitha T Murthy]

On Wed, 2018-01-24 at 15:16 +0100, Hans Verkuil wrote:
> On 24/01/18 11:59, Smitha T Murthy wrote:
> > Added V4l2 controls for HEVC encoder
> > 
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  Documentation/media/uapi/v4l/extended-controls.rst | 400 
> > +
> >  1 file changed, 400 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> > b/Documentation/media/uapi/v4l/extended-controls.rst
> > index dfe49ae..46ee2bf 100644
> > --- a/Documentation/media/uapi/v4l/extended-controls.rst
> > +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> > @@ -1960,6 +1960,406 @@ enum v4l2_vp8_golden_frame_sel -
> >  1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> >  
> >  
> > +High Efficiency Video Coding (HEVC/H.265) Control Reference
> > +---
> > +
> > +The HEVC/H.265 controls include controls for encoding parameters of 
> > HEVC/H.265
> > +video codec.
> > +
> > +
> > +.. _hevc-control-id:
> > +
> > +HEVC/H.265 Control IDs
> > +^^
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)``
> > +Minimum quantization parameter for HEVC.
> > +Valid range: from 0 to 51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)``
> > +Maximum quantization parameter for HEVC.
> > +Valid range: from 0 to 51.
> 
> You probably should mention the default values for MIN_QP and MAX_QP
> (I assume those are 0 and 51 and are not driver specific).
> 
Yes these values are not driver specific.
I followed the way MAX_QP and MIN_QP are defined for other codecs like
H264, H263, MPEG4 where only valid range is mentioned.

> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)``
> > +Quantization parameter for an I frame for HEVC.
> > +Valid range: from 0 to 51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (integer)``
> > +Quantization parameter for a P frame for HEVC.
> > +Valid range: from 0 to 51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (integer)``
> > +Quantization parameter for a B frame for HEVC.
> > +Valid range: from 0 to 51.
> 
> Sorry, this still isn't clear to me.
> 
> If I set V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP to 50, can I then still set
> V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP to 51? Or is 50 then the maximum?
> 
> In other words, what is the relationship between these three controls
> and the MIN_QP/MAX_QP controls.
> 
If we set V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP as 50 then
V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP or
4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP or
V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP will have maximum as 50.
Similarly for minimum as well, the above three controls will adhere to
the V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP set.
These controls have similar in relation as seen with
V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP and V4L2_CID_MPEG_VIDEO_H264_MAX_QP 

> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)``
> > +HIERARCHICAL_QP allows the host to specify the quantization parameter
> > +values for each temporal layer through HIERARCHICAL_QP_LAYER. This is
> > +valid only if HIERARCHICAL_CODING_LAYER is greater than 1. Setting the
> > +control value to 1 enables setting of the QP values for the layers.
> > +
> > +.. _v4l2-hevc-hier-coding-type:
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE``
> > +(enum)
> > +
> > +enum v4l2_mpeg_video_hevc_hier_coding_type -
> > +Selects the hierarchical coding type for encoding. Possible values are:
> > +
> > +.. raw:: latex
> > +
> > +\begin{adjustbox}{width=\columnwidth}
> > +
> > +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> > +
> > +.. flat-table::
> > +:header-rows:  0
> > +:stub-columns: 0
> > +
> > +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B``
> > +  - Use the B frame for hierarchical coding.
> > +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P``
> > +  - Use the P frame for hierarchical coding.
> > +
> > +.. raw:: latex
> > +
> > +\end{adjustbox}
> > +
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)``
> > +Selects the hierarchical coding layer. In normal encoding
> > +(non-hierarchial coding), it should be zero. Possible values are [0, 
> > 6].
> > +0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL 
> > CODING
> > +LAYER 1 and so on.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 0.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 1.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 2.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP 

[PATCH 2/2] media: dvb_demux: improve debug messages

[Mauro Carvalho Chehab]

From: Mauro Carvalho Chehab 

Do some cleanup of debug messages, making them cleaner and
easier to be used to analyze what's going on.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_demux.c | 43 +++---
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_demux.c 
b/drivers/media/dvb-core/dvb_demux.c
index 1a6e2e61952a..210eed0269b0 100644
--- a/drivers/media/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb-core/dvb_demux.c
@@ -119,7 +119,8 @@ static inline int dvb_dmx_swfilter_payload(struct 
dvb_demux_feed *feed,
ccok = ((feed->cc + 1) & 0x0f) == cc;
feed->cc = cc;
if (!ccok)
-   dprintk("missed packet!\n");
+   dprintk("missed packet: %d instead of %d!\n",
+   cc, (feed->cc + 1) & 0x0f);
 #endif
 
if (buf[1] & 0x40)  // PUSI ?
@@ -188,7 +189,7 @@ static void dvb_dmx_swfilter_section_new(struct 
dvb_demux_feed *feed)
 
 #ifdef CONFIG_DVB_DEMUX_SECTION_LOSS_LOG
if (sec->secbufp < sec->tsfeedp) {
-   int i, n = sec->tsfeedp - sec->secbufp;
+   int n = sec->tsfeedp - sec->secbufp;
 
/*
 * Section padding is done with 0xff bytes entirely.
@@ -196,12 +197,9 @@ static void dvb_dmx_swfilter_section_new(struct 
dvb_demux_feed *feed)
 * but just first and last.
 */
if (sec->secbuf[0] != 0xff || sec->secbuf[n - 1] != 0xff) {
-   dprintk("dvb_demux.c section ts padding loss: %d/%d\n",
+   dprintk("section ts padding loss: %d/%d\n",
   n, sec->tsfeedp);
-   dprintk("dvb_demux.c pad data:");
-   for (i = 0; i < n; i++)
-   pr_cont(" %02x", sec->secbuf[i]);
-   pr_cont("\n");
+   dprintk("pad data: %*ph\n", n, sec->secbuf);
}
}
 #endif
@@ -240,9 +238,9 @@ static int dvb_dmx_swfilter_section_copy_dump(struct 
dvb_demux_feed *feed,
 
if (sec->tsfeedp + len > DMX_MAX_SECFEED_SIZE) {
 #ifdef CONFIG_DVB_DEMUX_SECTION_LOSS_LOG
-   dprintk("dvb_demux.c section buffer full loss: %d/%d\n",
-  sec->tsfeedp + len - DMX_MAX_SECFEED_SIZE,
-  DMX_MAX_SECFEED_SIZE);
+   dprintk("section buffer full loss: %d/%d\n",
+   sec->tsfeedp + len - DMX_MAX_SECFEED_SIZE,
+   DMX_MAX_SECFEED_SIZE);
 #endif
len = DMX_MAX_SECFEED_SIZE - sec->tsfeedp;
}
@@ -275,7 +273,7 @@ static int dvb_dmx_swfilter_section_copy_dump(struct 
dvb_demux_feed *feed,
dvb_dmx_swfilter_section_feed(feed);
 #ifdef CONFIG_DVB_DEMUX_SECTION_LOSS_LOG
else
-   dprintk("dvb_demux.c pusi not seen, discarding section 
data\n");
+   dprintk("pusi not seen, discarding section data\n");
 #endif
sec->secbufp += seclen; /* secbufp and secbuf moving together 
is */
sec->secbuf += seclen;  /* redundant but saves pointer 
arithmetic */
@@ -310,9 +308,12 @@ static int dvb_dmx_swfilter_section_packet(struct 
dvb_demux_feed *feed,
 
if (!ccok || dc_i) {
 #ifdef CONFIG_DVB_DEMUX_SECTION_LOSS_LOG
-   dprintk("discontinuity %s: %d bytes lost\n",
-   !ccok ? "detected" : "indicated",
-   count + 4);
+   if (dc_i)
+   dprintk("%d frame with disconnect indicator\n",
+   cc);
+   else
+   dprintk("discontinuity: %d instead of %d. %d bytes 
lost\n",
+   cc, (feed->cc + 1) & 0x0f, count + 4);
/*
 * those bytes under sume circumstances will again be reported
 * in the following dvb_dmx_swfilter_section_new
@@ -347,8 +348,7 @@ static int dvb_dmx_swfilter_section_packet(struct 
dvb_demux_feed *feed,
}
 #ifdef CONFIG_DVB_DEMUX_SECTION_LOSS_LOG
else if (count > 0)
-   dprintk("dvb_demux.c PUSI=1 but %d bytes lost\n",
-   count);
+   dprintk("PUSI=1 but %d bytes lost\n", count);
 #endif
} else {
/* PUSI=0 (is not set), no section boundary */
@@ -418,9 +418,10 @@ static void dvb_dmx_swfilter_packet(struct dvb_demux 
*demux, const u8 *buf)
1024);
speed_timedelta = ktime_ms_delta(cur_time,
demux->speed_last_time);
-   dprintk("TS speed %llu Kbits/sec \n",
-   

[PATCH 1/2] media: dvb_demux: Better handle discontinuity errors

[Mauro Carvalho Chehab]

From: Mauro Carvalho Chehab 

When a packet discontinuity happens, it is not just the payload
that was lost. The headers are lost too. So, the max size is not
184 but, instead 188.

Also, while printing warnings, make a distinction between
MPEG-TS indicated discontinuity and detected one.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_demux.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_demux.c 
b/drivers/media/dvb-core/dvb_demux.c
index 5047a1f87050..1a6e2e61952a 100644
--- a/drivers/media/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb-core/dvb_demux.c
@@ -310,8 +310,9 @@ static int dvb_dmx_swfilter_section_packet(struct 
dvb_demux_feed *feed,
 
if (!ccok || dc_i) {
 #ifdef CONFIG_DVB_DEMUX_SECTION_LOSS_LOG
-   dprintk("dvb_demux.c discontinuity detected %d bytes lost\n",
-   count);
+   dprintk("discontinuity %s: %d bytes lost\n",
+   !ccok ? "detected" : "indicated",
+   count + 4);
/*
 * those bytes under sume circumstances will again be reported
 * in the following dvb_dmx_swfilter_section_new
@@ -320,6 +321,9 @@ static int dvb_dmx_swfilter_section_packet(struct 
dvb_demux_feed *feed,
/*
 * Discontinuity detected. Reset pusi_seen to
 * stop feeding of suspicious data until next PUSI=1 arrives
+*
+* FIXME: does it make sense if the MPEG-TS is the one
+*  reporting discontinuity?
 */
feed->pusi_seen = false;
dvb_dmx_swfilter_section_new(feed);
-- 
2.14.3

Re: [PATCH v2] staging: media: remove remains of VIDEO_ATOMISP_OV8858

[Andy Shevchenko]

On Mon, 2018-01-29 at 12:16 +, Corentin Labbe wrote:
> OV8858 files are left unusable since commit 3a81c7660f80 ("media:
> staging: atomisp: Remove IMX sensor support")
> They are uncompilable since they depends on dw9718.c and vcm.c which
> was removed.
> 
> Remove the OV8858 kconfig and files.

Fine with me. We can sort things out later (repository will have the
sources still in any case) when the driver itself shows signs of life.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v6 4/6] media: i2c: Add TDA1997x HDMI receiver driver

[Hans Verkuil]

On 01/25/2018 05:15 PM, Tim Harvey wrote:
> On Mon, Jan 15, 2018 at 4:56 AM, Hans Verkuil  wrote:
>> On 12/28/2017 09:09 PM, Tim Harvey wrote:
>>> Add support for the TDA1997x HDMI receivers.
>>>
>>
>> This looks good.
>>
>> But there is one corner case that isn't handled in this driver: what if there
>> is no AVI InfoFrame (e.g. you receive a DVI signal)?
>>
>> The CTA-861 spec says that in the absence of an AVI InfoFrame you should use
>> limited range for CE formats and full range for IT formats. However, without
>> an AVI InfoFrame it is hard to detect a CE format since there is no VIC code.
>> In addition, a real DVI source will always transmit full range.
>>
>> I would recommend that in the absence of an AVI InfoFrame you fall back to
>> sRGB with full range quantization. Not quite according to the spec but more
>> likely to work in practice.
>>
> 
> Hans,
> 
> Sounds like we are just talking about the default settings which would
> be used in the case of no infoframes. I'll default the struct
> v4l2_hdmi_colorimetry I store in the state struct as:
> 
> +   /*
> +* default to SRGB full range quantization
> +* (in case we don't get an infoframe such as DVI signal
> +*/
> +   state->colorimetry.colorspace = V4L2_COLORSPACE_SRGB;
> +   state->colorimetry.quantization = V4L2_QUANTIZATION_FULL_RANGE;
> +

I agree.

> 
> 
>>> 
>>> +static int tda1997x_enum_mbus_code(struct v4l2_subdev *sd,
>>> +   struct v4l2_subdev_pad_config *cfg,
>>> +   struct v4l2_subdev_mbus_code_enum *code)
>>> +{
>>> + struct tda1997x_state *state = to_state(sd);
>>> +
>>> + if (code->index > 0)
>>> + return -EINVAL;
>>> +
>>> + code->code = state->code;
>>
>> Hmm. This receiver supports multiple output formats, but you advertise only 
>> one.
>> That looks wrong. If nothing else, you should be able to switch between RGB 
>> and
>> YUV 4:4:4 since they use the same port config.
>>
>> It's a common use-case that you want to switch between RGB and YUV depending 
>> on
>> the source material (i.e. if you receive a desktop/graphics then RGB is 
>> best, if
>> you receive video then YUV 4:2:2 or 4:2:0 is best).
>>
>> Hardcoding just one format won't do.
>>
> 
> I've been thinking about this a bit. I had hard-coded a single format
> for now because I haven't had any good ideas on how to deal with the
> fact that the port mappings would need to differ if you change from
> the RGB888/YUV444 (I think these are referred to as 'planar' formats?)
> to YUV422 (semi-planar) and BT656 formats. It is true though that the
> 36bit (TDA19973) RGB888/YUV444 and 24bit (TDA19971/2) formats can both
> be supported with the same port mappings / pinout.

Regarding terminology:

RGB and YUV are typically interleaved, i.e. the color components are
(for two pixels) either RGBRGB for RGB888, YUVYUV for YUV444 or YUYV
for YUV422.

Planar formats are in practice only seen for YUV and will first output
all Y samples, and then the UV samples. This requires that the hardware
buffers the frame and that's not normally done by HDMI receivers.

The DMA engine, however, is often able to split up the interleaved YUV
samples that it receives and DMA them to separate buffers, thus turning
an interleaved media bus format to a planar memory format.

BT656 doesn't refer to how the samples are transferred, instead it
refers to how the hsync and vsync are reported. The enum v4l2_mbus_type
has various options, one of them being BT656.

Which mbus type is used is board specific (and should come from the
device tree). Whether to transmit RGB888, YUV444 or YUV422 (or possibly
even YUV420) is dynamic and is up to userspace since it is use-case
dependent.

So you'll never switch between BT656 and CSI, but you can switch between
BT656+RGB and BT656+YUV, or between CSI+RGB and CSI+YUV.

> 
> For example the GW5400 has a TDA19971 mapped to IMX6 CSI_DATA[19:4]
> (16bit) for YUV422. However if you want to use BT656 you have to shift
> the TDA19971 port mappings to get the YCbCr pins mapped to
> CSI_DATA[19:x] and those pin groups are at the bottom of the bus for
> the RGB888/YUV444 format.

As mentioned above, you wouldn't switch between mbus types.

> 
> I suppose however that perhaps for the example above if I have a 16bit
> width required to support YUV422 there would never be a useful case
> for supporting 8-bit/10-bit/12-bit BT656 on the same board?

You wouldn't switch between mbus types, but if the device tree configures
BT.656 with a bus width of 24 bits, then the application might very well
want to dynamically switch between 8, 10 and 12 bits per color component.

> 
> Maybe I can define an array of mbus_codes in the state structure then
> fill in the possible states per bit width during init like this:
> 
> switch (state->info->type) {
> case TDA19973:
> switch (pdata->vidout_bus_width) {
> case 

Re: [PATCH] sh: clk: Relax clk rate match test

[Laurent Pinchart]

Hi Jacopo,

On Friday, 26 January 2018 18:24:54 EET jacopo mondi wrote:
> On Thu, Jan 25, 2018 at 03:39:32PM +0100, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> 
> [snip]
> 
>  ---
>  
>   drivers/sh/clk/core.c | 9 ++---
>   1 file changed, 6 insertions(+), 3 deletions(-)
>  
>  diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
>  index 92863e3..d2cb94c 100644
>  --- a/drivers/sh/clk/core.c
>  +++ b/drivers/sh/clk/core.c
>  @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
>   {
>  struct cpufreq_frequency_table *pos;
>  
>  -   cpufreq_for_each_valid_entry(pos, freq_table)
>  -   if (pos->frequency == rate)
>  -   return pos - freq_table;
>  +   cpufreq_for_each_valid_entry(pos, freq_table) {
>  +   if (pos->frequency > rate)
>  +   continue;
> >>> 
> >>> This assumes all frequency tables are sorted.
> >>> 
> >>> Shouldn't you pick the closest frequency?
> >>> 
> >>> However, that's what clk_rate_table_round() does, which is called from
> >>> 
> >>> sh_clk_div_round_rate(), and thus already used as .round_rate:
> >>> 
> >>> static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
> >>> .recalc = sh_clk_div_recalc,
> >>> .set_rate   = sh_clk_div_set_rate,
> >>> .round_rate = sh_clk_div_round_rate,
> >>> .enable = sh_clk_div_enable,
> >>> .disable= sh_clk_div_disable,
> >>> 
> >>> };
> >> 
> >> Does this implies clock rates should be set using clk_round_rate() and
> >> not clk_set_rate() if I understand this right?
> > 
> > Not necessarily...
> > 
> > Note that both cpg_div6_clock_round_rate() and cpg_div6_clock_set_rate()
> > in the CCF implementation for DIV6 clocks use rounding.
> 
> Yeah but it doesn't seem to me that CCF implementation for DIV6 clocks does
> have to walk static tables like the old sh clock driver does. They
> perform rounding, but on the clock dividers given a requested rate
> and the respective parent clock, if I'm not wrong.

While clk_set_rate() doesn't explicitly document that the rate will be 
rounded, the clk_round_rate() documentation does:

/**
 * clk_round_rate - adjust a rate to the exact rate a clock can provide
 * @clk: clock source
 * @rate: desired clock rate in Hz
 *
 * This answers the question "if I were to pass @rate to clk_set_rate(),
 * what clock rate would I end up with?" without changing the hardware
 * in any way.  In other words:
 *
 *   rate = clk_round_rate(clk, r);
 *
 * and:
 *
 *   clk_set_rate(clk, r);
 *   rate = clk_get_rate(clk);
 *
 * are equivalent except the former does not modify the clock hardware
 * in any way.
 *
 * Returns rounded clock rate in Hz, or negative errno.
 */

So I think the SH implementation of clk_set_rate() should round rates.

(And feel free to send a patch for the clk_set_rate() documentation in 
include/linux/clk.h to state explicitly that the rate will be rounded).

> Anyway, in this case a much simpler:
> clk_set_rate(video_clk, clk_round_rate(video_clk, 1000));
> does the job for Migo-R.
> 
> I will include this in next CEU iterations, since I already have a
> small comment from you to fix there ;)

That should not be needed, but if the above code is in a board file, I can 
live with that until drivers/sh/clk/ gets fixed.

> >>> (clk_rate_table_find() is called from sh_clk_div_set_rate())
> >>> 
> >>> Or are you supposed to ask for the exact clock rate? Where does the 10
> >>> MHz come from?
> >> 
> >> From board initialization code, in order to provide a valid input
> >> clock to OV7720 sensor.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] media: rc: ir-spi: fix duty cycle

[Andi Shyti]

Hi Sean,

On Sat, Jan 27, 2018 at 02:05:37PM +, Sean Young wrote:
> Calculate the pulse rather than having a few preset values.
> 
> Cc: Andi Shyti 
> Signed-off-by: Sean Young 

Looks good to me.

Acked-by: Andi Shyti 

Thanks,
Andi

Re: [RFC PATCH] v4l2-event/dev: wakeup pending events when unregistering

[Hans Verkuil]

Hi Michael,

On 01/22/2018 02:52 PM, Michael Walz wrote:
> Hi Hans,
> 
> 
> On 18.01.2018 16:13, Hans Verkuil wrote:
>> Only apply the change to v4l2_dev.c, ignore the changes to
>> v4l2_event. I think it is sufficient to just apply that bit.
> 
> I tried both variants, with changes to v4l2_event and without. Both did
> not work out of the box. I think the problem is in the wake-up-condition in
> 
> ret = wait_event_interruptible(fh->wait, fh->navailable != 0);
> 
> As long as we will check only fh->navailable, the thread will continue
> to sleep. I inserted an abort-condition to the wait
> 
> !video_is_registered(fh->vdev)
> 
> and some printk messages. Is is a dirty hack, but now my VIDIOC_DQEVENT 
> ioctl returns. Instead I get a bunch of errors in dmesg. Can you have a 
> look, please?

This will take some time, I'm in the middle of something urgent and until
that's done this will be on hold. It's in my todo list, so I'll get to it
eventually (probably in 2-3 weeks).

Sorry about that.

Regards,

Hans

> 
> 
> diff -Naur drivers.orig/media/v4l2-core/v4l2-dev.c 
> drivers/media/v4l2-core/v4l2-dev.c
> --- drivers.orig/media/v4l2-core/v4l2-dev.c   2018-01-22 
> 13:22:47.881815404 +0100
> +++ drivers/media/v4l2-core/v4l2-dev.c2018-01-22 13:23:18.541315363 
> +0100
> @@ -1015,6 +1015,9 @@
>*/
>   void video_unregister_device(struct video_device *vdev)
>   {
> + unsigned long flags;
> + struct v4l2_fh *fh;
> +
>   /* Check if vdev was ever registered at all */
>   if (!vdev || !video_is_registered(vdev))
>   return;
> @@ -1025,7 +1028,15 @@
>*/
>   clear_bit(V4L2_FL_REGISTERED, >flags);
>   mutex_unlock(_lock);
> +
> + printk("MWALZ wake threads\n");
> +spin_lock_irqsave(>fh_lock, flags);
> + list_for_each_entry(fh, >fh_list, list)
> + wake_up_all(>wait);
> + spin_unlock_irqrestore(>fh_lock, flags);
> +
>   device_unregister(>dev);
> +printk("MWALZ unregistered devices\n");
>   }
>   EXPORT_SYMBOL(video_unregister_device);
> 
> diff -Naur drivers.orig/media/v4l2-core/v4l2-event.c 
> drivers/media/v4l2-core/v4l2-event.c
> --- drivers.orig/media/v4l2-core/v4l2-event.c 2018-01-22 
> 13:22:47.881815404 +0100
> +++ drivers/media/v4l2-core/v4l2-event.c  2018-01-22 13:23:14.301384509 
> +0100
> @@ -35,12 +35,18 @@
>   {
>   struct v4l2_kevent *kev;
>   unsigned long flags;
> + int ret = 0;
> 
>   spin_lock_irqsave(>vdev->fh_lock, flags);
> 
> + if (!video_is_registered(fh->vdev)) {
> +printk("MWALZ device not registered!\n");
> + ret = -ENODEV;
> + goto err;
> + }
>   if (list_empty(>available)) {
> - spin_unlock_irqrestore(>vdev->fh_lock, flags);
> - return -ENOENT;
> + ret = -ENOENT;
> + goto err;
>   }
> 
>   WARN_ON(fh->navailable == 0);
> @@ -53,10 +59,10 @@
>   *event = kev->event;
>   kev->sev->first = sev_pos(kev->sev, 1);
>   kev->sev->in_use--;
> -
> +err:
>   spin_unlock_irqrestore(>vdev->fh_lock, flags);
> 
> - return 0;
> + return ret;
>   }
> 
>   int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event,
> @@ -73,16 +79,20 @@
> 
>   do {
>   ret = wait_event_interruptible(fh->wait,
> -fh->navailable != 0);
> +(fh->navailable != 0) ||
> + (!video_is_registered(fh->vdev)));
> +printk("MWALZ woken up\n");
>   if (ret < 0)
>   break;
> 
>   ret = __v4l2_event_dequeue(fh, event);
>   } while (ret == -ENOENT);
> 
> +printk("Try to get the lock\n");
>   if (fh->vdev->lock)
>   mutex_lock(fh->vdev->lock);
> 
> +printk("MWALZ return event DQ\n");
>   return ret;
>   }
>   EXPORT_SYMBOL_GPL(v4l2_event_dequeue);
> 
> 
> 
> 
> 
> 
> [ 1566.982359] usb 2-2.1: USB disconnect, device number 7
> [ 1566.982827] MWALZ wake threads
> [ 1566.983411] MWALZ woken up
> [ 1566.983421] MWALZ device not registered!
> [ 1566.983426] Try to get the lock
> [ 1566.983430] MWALZ return event DQ
> [ 1566.993157] MWALZ unregistered devices
> [ 1569.227177] sysfs group 'power' not found for kobject 'event8'
> [ 1569.227201] [ cut here ]
> [ 1569.227214] WARNING: CPU: 1 PID: 2364 at 
> /kernel-source//fs/sysfs/group.c:237 sysfs_remove_group+0x46/0x7b
> [ 1569.227216] Modules linked in: bnep hid_sensor_gyro_3d 
> hid_sensor_accel_3d hid_sensor_trigger hid_sensor_iio_common 
> industrialio_triggered_buffer kfifo_buf hid_sensor_hub intel_ishtp_hid 
> hid_multitouch input_leds asus_nb_wmi asus_wmi gpio_keys 
> intel_powerclamp pcspkr btsdio brcmfmac brcmutil cfg80211 uvcvideo 
> videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 ax88179_178a 
> videobuf2_core usbnet videodev hid_generic mei_txe lpc_ich mei 
> 

Re: [RFC PATCH 0/8] [media] Request API, take three

[Hans Verkuil]

On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
> Howdy. Here is your bi-weekly request API redesign! ;)
> 
> Again, this is a simple version that only implements the flow of requests,
> without applying controls. The intent is to get an agreement on a base to work
> on, since the previous versions went straight back to the redesign board.
> 
> Highlights of this version:
> 
> * As requested by Hans, request-bound buffers are now passed earlier to 
> drivers,
> as early as the request itself is submitted. Doing it earlier is not be useful
> since the driver would not know the state of the request, and thus cannot do
> anything with the buffer. Drivers are now responsible for applying request
> parameters themselves.
> 
> * As a consequence, there is no such thing as a "request queue" anymore. The
> flow of buffers decides the order in which requests are processed. Individual
> devices of the same pipeline can implement synchronization if needed, but this
> is beyond this first version.
> 
> * VB2 code is still a bit shady. Some of it will interfere with the fences
> series, so I am waiting for the latter to land to do it properly.
> 
> * Requests that are not yet submitted effectively act as fences on the buffers
> they own, resulting in the buffer queue being blocked until the request is
> submitted. An alternate design would be to only block the
> not-submitted-request's buffer and let further buffers pass before it, but 
> since
> buffer order is becoming increasingly important I have decided to just block 
> the
> queue. This is open to discussion though.

I don't think we should mess with the order.

> 
> * Documentation! Also described usecases for codec and simple (i.e. not part 
> of
> a complex pipeline) capture device.

I'll concentrate on reviewing that.

> 
> Still remaining to do:
> 
> * As pointed out by Hans on the previous revision, do not assume that drivers
> using v4l2_fh have a per-handle state. I have not yet found a good way to
> differenciate both usages.

I suspect we need to add a flag or something for this.

> * Integrate Hans' patchset for control handling: as said above, this is futile
> unless we can agree on the basic design, which I hope we can do this time.
> Chrome OS needs this really badly now and will have to move forward no matter
> what, so I hope this will be considered good enough for a common base of work.

I am not sure there is any reason to not move forward with the control handling.
You need this anyway IMHO, regardless of any public API considerations.

> A few thoughts/questions that emerged when writing this patchset:
> 
> * Since requests are exposed as file descriptors, we could easily move the
> MEDIA_REQ_CMD_SUBMIT and MEDIA_REQ_CMD_REININT commands as ioctls on the
> requests themselves, instead of having to perform them on the media device 
> that
> provided the request in the first place. That would add a bit more flexibility
> if/when passing requests around and means the media device only needs to 
> handle
> MEDIA_REQ_CMD_ALLOC. Conceptually speaking, this seems to make sense to me.
> Any comment for/against that?

Makes sense IMHO.

> * For the codec usecase, I have experimented a bit marking CAPTURE buffers 
> with
> the request FD that produced them (vim2m acts that way). This seems to work
> well, however FDs are process-local and could be closed before the CAPTURE
> buffer is dequeued, rendering that information less meaningful, if not
> dangerous.

I don't follow this. Once the fd is passed to the kernel its refcount should be
increased so the data it represents won't be released if userspace closes the 
fd.

Obviously if userspace closes the fd it cannot do anything with it anymore, but
it shouldn't be 'dangerous' AFAICT.

> Wouldn't it be better/safer to use a global request ID for
> such information instead? That ID would be returned upon MEDIA_REQ_CMD_ALLOC 
> so
> user-space knows which request ID a FD refers to.

I think it is not a good idea to have both an fd and an ID to refer to the
same object. That's going to be very confusing I think.

> * Using the media node to provide requests makes absolute sense for complex
> camera devices, but is tedious for codec devices which work on one node and
> require to protect request/media related code with #ifdef
> CONFIG_MEDIA_CONTROLLER.

Why? They would now depend on MEDIA_CONTROLLER (i.e. they won't appear in the
menuconfig unless MEDIA_CONTROLLER is set). No need for an #ifdef.

 For these devices, the sole role of the media node is
> to produce the request, and that's it (since request submission could be moved
> to the request FD as explained above). That's a modest use that hardly 
> justifies
> bringing in the whole media framework IMHO. With a bit of extra abstraction, 
> it
> should be possible to decouple the base requests from the media controller
> altogether, and propose two kinds of requests implementations: one simpler
> implementation that works directly with a single V4L2 

Re: [PATCH v7 07/11] media: i2c: ov772x: Support frame interval handling

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Friday, 26 January 2018 15:55:26 EET Jacopo Mondi wrote:
> Add support to ov772x driver for frame intervals handling and enumeration.
> Tested with 10MHz and 24MHz input clock at VGA and QVGA resolutions for
> 10, 15 and 30 frame per second rates.
> 
> Signed-off-by: Jacopo Mondi 
> ---
> drivers/media/i2c/ov772x.c | 315 +-
> 1 file changed, 310 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 912b1b9..6d46748 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -250,6 +250,7 @@
>  #define AEC_1p2 0x10 /*  01: 1/2  window */
>  #define AEC_1p4 0x20 /*  10: 1/4  window */
>  #define AEC_2p3 0x30 /*  11: Low 2/3 window */
> +#define COM4_RESERVED   0x01 /* Reserved value */

I'd write "Reserved bits", "Reserved value" makes it sound like it's the value 
of the full register.

>  /* COM5 */
>  #define AFR_ON_OFF  0x80 /* Auto frame rate control ON/OFF selection 
*/
> @@ -267,6 +268,19 @@
>   /* AEC max step control */
>  #define AEC_NO_LIMIT0x01 /*   0 : AEC incease step has limit */
>   /*   1 : No limit to AEC increase step */
> +/* CLKRC */
> + /* Input clock divider register */
> +#define CLKRC_RESERVED  0x80 /* Reserved value */
> +#define CLKRC_BYPASS0x40 /* Bypass input clock divider */
> +#define CLKRC_DIV2  0x01 /* Divide input clock by 2 */
> +#define CLKRC_DIV3  0x02 /* Divide input clock by 3 */
> +#define CLKRC_DIV4  0x03 /* Divide input clock by 4 */
> +#define CLKRC_DIV5  0x04 /* Divide input clock by 5 */
> +#define CLKRC_DIV6  0x05 /* Divide input clock by 6 */
> +#define CLKRC_DIV8  0x07 /* Divide input clock by 8 */
> +#define CLKRC_DIV10 0x09 /* Divide input clock by 10 */
> +#define CLKRC_DIV16 0x0f /* Divide input clock by 16 */
> +#define CLKRC_DIV20 0x13 /* Divide input clock by 20 */

How about just

#define CLKRC_DIV(n)((n) - 1)

>  /* COM7 */
>   /* SCCB Register Reset */
> @@ -373,6 +387,12 @@
>  #define VERSION(pid, ver) ((pid<<8)|(ver&0xFF))
> 
>  /*
> + * Input clock frequencies
> + */
> +enum { OV772X_FIN_10MHz, OV772X_FIN_24MHz, OV772X_FIN_48MHz, OV772X_FIN_N,
> };
> +static unsigned int ov772x_fin_vals[] = { 1000, 2400, 4800
> };
> +
> +/*
>   * struct
>   */
> 
> @@ -391,6 +411,16 @@ struct ov772x_win_size {
>   struct v4l2_rect  rect;
>  };
> 
> +struct ov772x_pclk_config {
> + u8 com4;
> + u8 clkrc;
> +};
> +
> +struct ov772x_frame_rate {
> + unsigned int fps;
> + const struct ov772x_pclk_config pclk[OV772X_FIN_N];
> +};
> +
>  struct ov772x_priv {
>   struct v4l2_subdevsubdev;
>   struct v4l2_ctrl_handler  hdl;
> @@ -404,6 +434,7 @@ struct ov772x_priv {
>   unsigned shortflag_hflip:1;
>   /* band_filter = COM8[5] ? 256 - BDBASE : 0 */
>   unsigned shortband_filter;
> + unsigned int  fps;
>  };
> 
>  /*
> @@ -508,6 +539,154 @@ static const struct ov772x_win_size ov772x_win_sizes[]
> = { };
> 
>  /*
> + * frame rate settings lists
> + */
> +unsigned int ov772x_frame_intervals[] = {10, 15, 30, 60};
> +#define OV772X_N_FRAME_INTERVALS ARRAY_SIZE(ov772x_frame_intervals)
> +
> +static const struct ov772x_frame_rate vga_frame_rates[] = {
> + {   /* PCLK = 7,5 MHz */
> + .fps= 10,
> + .pclk = {
> + [OV772X_FIN_10MHz] = {
> + .com4   = PLL_6x | COM4_RESERVED,
> + .clkrc  = CLKRC_DIV8 | CLKRC_RESERVED,
> + },
> + [OV772X_FIN_24MHz] = {
> + .com4   = PLL_BYPASS | COM4_RESERVED,
> + .clkrc  = CLKRC_DIV3 | CLKRC_RESERVED,
> + },
> + [OV772X_FIN_48MHz] = {
> + .com4   = PLL_BYPASS | COM4_RESERVED,
> + .clkrc  = CLKRC_DIV6 | CLKRC_RESERVED,
> + },
> + },
> + },
> + {   /* PCLK = 12 MHz */
> + .fps= 15,
> + .pclk = {
> + [OV772X_FIN_10MHz]  = {
> + .com4   = PLL_4x | COM4_RESERVED,
> + .clkrc  = CLKRC_DIV3 | CLKRC_RESERVED,
> + },
> + [OV772X_FIN_24MHz]  = {
> + .com4   = PLL_BYPASS | COM4_RESERVED,
> + .clkrc  = CLKRC_DIV2 | CLKRC_RESERVED,
> + },
> + [OV772X_FIN_48MHz]  = {
> + .com4   = PLL_BYPASS | COM4_RESERVED,
> +