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 Jun 20 05:00:15 CEST 2017
media-tree git hash:acec3630155763c170c7ae6508cf973355464508
media_build git hash:   a5ec7f00979b6c866911fb42507770727ff5afd4
v4l-utils git hash: ce237eefc1f6dafafc0e1fe3a5fd9f075d3fd066
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/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: Reply Urgent

[INFO]

Hello,

How are you doing? I have been sent to inform you that, We have an  
inheritance of a deceased client with your surname. Contact Mr Andrew  
Bailey Reply Email To: myinf...@gmail.com with your "Full Names" for  
more info.  Thanks for your understanding.


Reply ASAP thank you.

Melissa.
--
Correo Corporativo Hospital Universitario del Valle E.S.E
***

"Estamos re-dimensionandonos para crecer!"

**

Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors

[Adam Zegelin]

Hi Thomas,

I haven't had much time to investigate the issue -- I'm currently in
the process of moving country, which is a lot of work!

One thing I was able to determine is that it appears to be related to
Intel VT-d/VT-x or whatever Intel's IOMMU/x86 virtualisation tech
thing is called.

I tried the card in a different older Intel i7 board and it worked
flawlessly. I then started to wonder if it was some new
incompatibility introduced with Kaby Lake. I had tweaked the UEFI
settings on the new Kaby Lake board to enable VT-d/VT-x since I wanted
to run Linux as a host OS with Windows 10 running on top of qemu/KVM.
Upon resetting the UEFI settings to their defaults (VT-d/VT-x
disabled) the card worked without issue.

Maybe this will point you in the right direction, especially since you
mention that your using EXSi with PCIe passthrough, which requires the
use of VT-d/VT-x.

Whether the card itself has issues with VT-d/VT-x or it's a driver bug
I have yet to determine -- how I do that, no idea!

I've CC'd the list, which should include your reply too. See
http://vger.kernel.org/vger-lists.html#linux-media to subscribe to the
list.

Regards,
Adam

On Sun, Jun 18, 2017 at 6:45 PM, Thomas Kuehne  wrote:
> Hi Adam,
>
> interestingly, I have the same issue and you "fix" also works for me, at 
> least partly.
>
> I run the quad HD on a little 1RU server that has vmware's ESXi supervisor 
> installed, and the card is configured for PCI passthrough. The virtual 
> machine that makes use of this card runs tvheadend 4.2.2. Other than that, 
> the setup is similar to what you describe. (Ubuntu 16.04.2 LTS Kernel 4.8, 
> driver vb-demod-si2168-b40-01.fw version 4.0.11)
>
> Without the debug kernel option, I get the same load of errors, and the 
> tvheadend software is not able to tune.
> Adding debug level 5, I get a picture. So, I guess I am with you that the 
> additional latency induced by the debug option helped the driver to cope.
>
> Were you successful in solving the issue with your card? Any idea how we 
> might get this looked at? I haven't worked out how I can respond to your 
> thread on the mailing list (found it via a google search at the mail 
> archive). Maybe you can add my response to the thread?
>
> Best regards,
>
> Thomas

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Jasmin J.]

Hello !

On 06/19/2017 10:18 PM, Daniel Scheller wrote:
> Am Sun, 28 May 2017 23:45:37 +0200
> schrieb Daniel Scheller :
> 
>> Am Sun, 7 May 2017 17:42:12 +0200
>> schrieb Daniel Scheller :
>>
>>> Am Wed, 12 Apr 2017 21:23:27 +0200
>>> schrieb Daniel Scheller :
>>>   
 Am Wed, 29 Mar 2017 18:43:00 +0200
 schrieb Daniel Scheller :
 
> From: Daniel Scheller 
>
> Third iteration of the DD CineCTv6/FlexCT support patches with
> mostly all things cleaned up that popped up so far. Obsoletes V1
> and V2 series.
>
> These patches enhance the functionality of dvb-frontends/stv0367
> to work with Digital Devices hardware driven by the ST STV0367
> demodulator chip and adds probe & attach bits to ddbridge to
> make use of them, effectively enabling full support for
> CineCTv6 PCIe bridges and (older) DuoFlex CT addon
> modules.  

 Since V1 was sent over five weeks ago: Ping? Anyone? I'd really
 like to get this upstreamed.
>>>
>>> Don't want to sound impatient, but V1 nears nine weeks, so: Second
>>> Ping.  
>>
>> Friendly third time Ping on this - Really, I'd like to have this
>> merged so those quite aging (but still fine) DD CineCTv6 boards
>> finally are supported without having to install out-of-tree drivers
>> which even break the V4L-DVB subsystem...
> 
> Well. From how things look, these and the cxd2841er+C2T2 ddbridge
> support patches won't make it in time for the 4.13 merge window.
> Also, unfortunately, the original owners and/or maintainers of the
> affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
> either are MIA or not interested in reviewing or acking this.
> 
> I have plenty of more work (patches) done, all building upon this CT
> and C2T2 hardware support, which - together with the work Jasmin has
> done regarding the en50221 and cxd2099 support - would finally bring
> the in-tree ddbridge driver on par with the package Digital Devices'
> provides, having addressed most of the critics the previous attempts to
> bump the driver received (incremental changes which are more or less
> easy to review, from what can be done by tearing tarballs without
> proper changelogs apart).
> 
> The original series of this will be four(!) months old soon :/
> 
> Is there anything wrong with this? How to proceed with this?
> 
> (Cc Hans since you also seem to be reviewing patches)
> 
> That said, fourth ping.

May I add another aspect.
Daniel put a lot of effort into this and also other people in testing his
drivers. Daniel was highly motivated to bring this driver into the Kernel.

That sayd, waiting 4 months is pretty frustrating and might reduce the
motivation to continue.

There are 7 more patch series waiting to review and when each of then requires
4 or more months to get into the Kernel, the project is dead before it really
started!

The community using the DD cards is growing and it is often frustrating using
the drivers provided by DD, when you plan to use other cards too, because
the DD drivers are simply not compatible.
Daniel made them working within the current media tree and a lot of people
(including me) would be very happy to see the DD cards supported out of the
box by the Kernel. Hopefully before the Kernel 5.x development hast started.

I hope there will be soon a review of this series, so that we can move forward
with our work!

BR,
   Jasmin

Re: [PATCH v3 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Sylwester Nawrocki]

On 06/19/2017 11:33 AM, Jose Abreu wrote:
> On 18-06-2017 19:04, Sylwester Nawrocki wrote:
>> On 06/16/2017 06:38 PM, Jose Abreu wrote:
>>> This is an initial submission for the Synopsys Designware HDMI RX
>>> Controller Driver. This driver interacts with a phy driver so that
>>> a communication between them is created and a video pipeline is
>>> configured.
>>>
>>> The controller + phy pipeline can then be integrated into a fully
>>> featured system that can be able to receive video up to 4k@60Hz
>>> with deep color 48bit RGB, depending on the platform. Although,
>>> this initial version does not yet handle deep color modes.
>>> Signed-off-by: Jose Abreu 
>>>
>>> +static int dw_hdmi_phy_init(struct dw_hdmi_dev *dw_dev)
>>> +{

>>> +   request_module(pdevinfo.name);
>>> +
>>> +   dw_dev->phy_pdev = platform_device_register_full();
>>> +   if (IS_ERR(dw_dev->phy_pdev)) {
>>> +   dev_err(dw_dev->dev, "failed to register phy device\n");
>>> +   return PTR_ERR(dw_dev->phy_pdev);
>>> +   }
>>> +
>>> +   if (!dw_dev->phy_pdev->dev.driver) {
>>> +   dev_err(dw_dev->dev, "failed to initialize phy driver\n");
>>> +   goto err;
>>> +   }
>> I think this is not safe because there is nothing preventing unbinding
>> or unloading the driver at this point.
>>
>>> +   if (!try_module_get(dw_dev->phy_pdev->dev.driver->owner)) {
>> So dw_dev->phy_pdev->dev.driver may be already NULL here.
> 
> How can I make sure it wont be NULL? Because I've seen other
> media drivers do this and I don't think they do any kind of
> locking, but they do this mainly for I2C subdevs.

You could do device_lock(dev)/device_unlock(dev) to avoid possible races. 
And setting 'suppress_bind_attrs' field in the sub-device drivers would 
disable sysfs unbind attributes, so sub-device driver wouldn't get unbound
unexpectedly trough sysfs.
 
>>> +   dev_err(dw_dev->dev, "failed to get phy module\n");
>>> +   goto err;
>>> +   }
>>> +
>>> +   dw_dev->phy_sd = dev_get_drvdata(_dev->phy_pdev->dev);
>>> +   if (!dw_dev->phy_sd) {
>>> +   dev_err(dw_dev->dev, "failed to get phy subdev\n");
>>> +   goto err_put;
>>> +   }
>>> +
>>> +   if (v4l2_device_register_subdev(_dev->v4l2_dev, dw_dev->phy_sd)) {
>>> +   dev_err(dw_dev->dev, "failed to register phy subdev\n");
>>> +   goto err_put;
>>> +   }
>>
>> I'd suggest usign v4l2-async API, so we use a common pattern for sub-device
>> registration.  And with recent change [1] you could handle this PHY subdev
>> in a standard way.  That might be more complicated than it is now but should
>> make any future platform integration easier.

> So I will instantiate phy driver and then wait for phy driver to
> register into v4l2 core?

Yes, for instance the RX controller driver registers a notifier, instantiates
the child PHY device and then waits until the PHY driver completes 
initialization.

>>> +   module_put(dw_dev->phy_pdev->dev.driver->owner);
>>> +   return 0;
>>> +
>>> +err_put:
>>> +   module_put(dw_dev->phy_pdev->dev.driver->owner);
>>> +err:
>>> +   platform_device_unregister(dw_dev->phy_pdev);
>>> +   return -EINVAL;
>>> +}

>>> +static int dw_hdmi_power_on(struct dw_hdmi_dev *dw_dev, u32 input)
>>> +{
>>> +   struct dw_hdmi_work_data *data;
>>> +   unsigned long flags;
>>> +
>>> +   data = devm_kzalloc(dw_dev->dev, sizeof(*data), GFP_KERNEL);
>>
>> Why use devm_{kzalloc, kfree} when dw_hdmi_power_on() is not only called
>> in the device's probe() callback, but in other places, including interrupt
>> handler?  devm_* API is normally used when life time of a resource is more
>> or less equal to life time of struct device or its matched driver.  Were
>> there any specific reasons to not just use kzalloc()/kfree() ?
> 
> No specific reason, I just thought it would be safer because if I
> cancel a work before it started then memory will remain
> allocated. But I will change to kzalloc().

OK, I overlooked such situation. Since you allow one job queued maybe
just embed struct work_struct in struct dw_hdmi_dev and retrieve it with
container_of() macro in the work handler and use additional field in
struct dw_hdmi_dev protected with dw_dev->lock for passing the input 
index?

>>> +   if (!data)
>>> +   return -ENOMEM;
>>> +
>>> +   INIT_WORK(>work, dw_hdmi_work_handler);
>>> +   data->dw_dev = dw_dev;
>>> +   data->input = input;
>>> +
>>> +   spin_lock_irqsave(_dev->lock, flags);
>>> +   if (dw_dev->pending_config) {
>>> +   devm_kfree(dw_dev->dev, data);
>>> +   spin_unlock_irqrestore(_dev->lock, flags);
>>> +   return 0;
>>> +   }
>>> +
>>> +   queue_work(dw_dev->wq, >work);
>>> +   dw_dev->pending_config = true;
>>> +   spin_unlock_irqrestore(_dev->lock, flags);
>>> +   return 0;
>>> +}

>>> +struct dw_hdmi_rx_pdata {
>>> +   /* Controller configuration */

>>> +   struct dw_hdmi_hdcp14_key hdcp14_keys;
>>> +   /* 5V sense interface */
>>> +   bool (*dw_5v_status)(void __iomem 

Re: [media-build] Can't compile for Kernel 3.13 after recent changes

[Jasmin J.]

Hallo Hans!

> OK, so I felt a bit guilty and decided to take a quick look. I think it
> will now build again for 3.13.
Yes, It builds now perfectly.
Will test the driver tomorrow.

THANK YOU VERRY MUCH!

BR,
   Jasmin

Re: [media-build] Can't compile for Kernel 3.13 after recent changes

[Hans Verkuil]

On 06/19/2017 09:20 PM, Hans Verkuil wrote:

On 06/19/2017 08:43 PM, Jasmin J. wrote:

Hi!

After the recent changes, I can no longer compile for Kernel 3.13


I know. I haven't had time to look at this and fix it. It probably won't be 
until
early next week due to some travel.


OK, so I felt a bit guilty and decided to take a quick look. I think it
will now build again for 3.13.

Regards,

Hans



Regards,

Hans



BR,
 Jasmin

Here the build Log:

Kernel build directory is /lib/modules/3.13.0-117-generic/build
make -C ../linux apply_patches
make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
Patches for 3.13.0-117-generic already applied.
make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
make -C /lib/modules/3.13.0-117-generic/build 
SUBDIRS=/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l  modules
make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/linux-headers-3.13.0-117-generic'
CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o
CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o
CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
return dev->fwnode;
  ^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
return dev->fwnode;
  ^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o] Error 1
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
return dev->fwnode;
  ^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o] Error 1
Makefile:1279: recipe for target 
'_module_/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l' failed
make[2]: *** [_module_/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l] 
Error 2
make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/linux-headers-3.13.0-117-generic'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
Makefile:26: recipe for target 'all' failed

Re: [PATCH v3 4/4] dt-bindings: media: Document Synopsys Designware HDMI RX

[Sylwester Nawrocki]

On 06/19/2017 11:01 AM, Jose Abreu wrote:
> Using fixed-clock was already in my todo list. Regarding phy I
> need to pass pdata so that the callbacks between controller and
> phy are established. I also need to make sure that phy driver
> will be loaded by the controller driver. Hmm, and also address of
> the phy on th JTAG bus is fed to the controller driver not to the
> phy driver. Maybe leave the property as is (the
> "snps,hdmi-phy-jtag-addr") or parse it from the phy node?

I think the RX controller can parse it's child phy node to retrieve JTAG 
address from the reg property.  That seems better than creating custom 
property for device address on the bus.

Does the PHY support any other type of control bus, e.g. I2C or SPI?

> I also need to pass pdata to the controller driver (the callbacks
> for 5v handling) which are agnostic of the controller. These

Is this about detecting +5V coming from the HDMI connector? Or some
other voltage supply?

> reasons prevented me from adding compatible strings to both
> drivers and just use a wrapper driver instead. This way i do

If you add struct of_device_id instance to your module and define
MODULE_DEVICE_ALIAS(of, ...) there, it will allow the module to be loaded 
when device with matching compatible string is created in the kernel. 
User space is notified with uevent about device creation.

> "modprobe wrapper_driver" and I get all the drivers loaded via
> request_module(). Still, I like your approach much better. I saw
> that I can pass pdata using of_platform_populate, could you
> please confirm if I can still maintain this architecture (i.e.
> prevent modules from loading until I get all the chain setup)?

You could try to pass platform data this way, that should work. But 
I doubt it's the right directions, I would rather see things done 
in the V4L2 layer. 

> Following your approach I could get something like this:
> 
> hdmi_system@ {
>  compatible = "snps,dw-hdmi-rx-wrapper";

This would need to refer to some hardware block, we should avoid virtual 
device nodes in DT.

>  reg = <0x 0x>;
>  interrupts = <3>;
>  #address-cells = <1>;
>  #size-cells = <1>;

You would need also an (empty) 'ranges' property here.

>  hdmi_controller@0 {
>  compatible = "snps,dw-hdmi-rx-controller";
>  reg = <0x0 0x1>;
>  interrupts = <1>;
>  edid-phandle = <_system>;
>  clocks = <>;
>  clock-names = "ref-clk";
>  #address-cells = <1>;
>  #size-cells = <0>;
> 
>  hdmi_phy@f3 {
>  compatible = "snps,dw-hdmi-phy-e405";
>  reg = <0xf3>;
>  clocks = <>;
>  clock-names = "cfg-clk";
>  }
>  }
> };
> 
> And then snps,dw-hdmi-rx-wrapper would call of_platform_populate
> for controller which would instead call of_platform_populate for
> phy. Is this possible, and maintainable? Isn't the controller
> driver get auto loaded because of the compatible string match?

As I mentioned above, auto loading should work if you have instance 
of MODULE_DEVICE_TABLE() defined in the module, but the module might
not be available immediately after creating devices with 
of_platform_populate().  You may want to have a look at the v4l2-async 
API (drivers/media/v4l2-core/v4l2-async.c). It allows one driver
to register a notifier for its sub-devices. And the parent driver
can complete initialization when it gets all its v4l2 subdevs
registered.

But I'm not sure about calls from the PHY back to the RX controller, 
possibly v4l2_set_subdev_hostdata()/v4l2_get_subdev_hostdata() could 
be used for passing the ops.

> And one more thing: The reg address of the hdmi_controller: Isn't
> this relative to the parent node? I mean isn't this going to be
> 0x + 0x0? Because I don't want that :/

Address space of child nodes doesn't need to be relative to 'reg' range 
of parent node, these can be entirely distinct address ranges. See for 
example I2C bus controllers, the I2C addresses of slave devices are not 
much related to the memory mapped IO registers region of the bus controller.

--
Regards,
Sylwester

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Daniel Scheller]

Am Sun, 28 May 2017 23:45:37 +0200
schrieb Daniel Scheller :

> Am Sun, 7 May 2017 17:42:12 +0200
> schrieb Daniel Scheller :
> 
> > Am Wed, 12 Apr 2017 21:23:27 +0200
> > schrieb Daniel Scheller :
> >   
> > > Am Wed, 29 Mar 2017 18:43:00 +0200
> > > schrieb Daniel Scheller :
> > > 
> > > > From: Daniel Scheller 
> > > > 
> > > > Third iteration of the DD CineCTv6/FlexCT support patches with
> > > > mostly all things cleaned up that popped up so far. Obsoletes V1
> > > > and V2 series.
> > > > 
> > > > These patches enhance the functionality of dvb-frontends/stv0367
> > > > to work with Digital Devices hardware driven by the ST STV0367
> > > > demodulator chip and adds probe & attach bits to ddbridge to
> > > > make use of them, effectively enabling full support for
> > > > CineCTv6 PCIe bridges and (older) DuoFlex CT addon
> > > > modules.  
> > > 
> > > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really
> > > like to get this upstreamed.
> > 
> > Don't want to sound impatient, but V1 nears nine weeks, so: Second
> > Ping.  
> 
> Friendly third time Ping on this - Really, I'd like to have this
> merged so those quite aging (but still fine) DD CineCTv6 boards
> finally are supported without having to install out-of-tree drivers
> which even break the V4L-DVB subsystem...

Well. From how things look, these and the cxd2841er+C2T2 ddbridge
support patches won't make it in time for the 4.13 merge window.
Also, unfortunately, the original owners and/or maintainers of the
affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
either are MIA or not interested in reviewing or acking this.

I have plenty of more work (patches) done, all building upon this CT
and C2T2 hardware support, which - together with the work Jasmin has
done regarding the en50221 and cxd2099 support - would finally bring
the in-tree ddbridge driver on par with the package Digital Devices'
provides, having addressed most of the critics the previous attempts to
bump the driver received (incremental changes which are more or less
easy to review, from what can be done by tearing tarballs without
proper changelogs apart).

The original series of this will be four(!) months old soon :/

Is there anything wrong with this? How to proceed with this?

(Cc Hans since you also seem to be reviewing patches)

That said, fourth ping.

Best regards,
Daniel Scheller

Re: [media-build] Can't compile for Kernel 3.13 after recent changes

[Hans Verkuil]

On 06/19/2017 08:43 PM, Jasmin J. wrote:

Hi!

After the recent changes, I can no longer compile for Kernel 3.13


I know. I haven't had time to look at this and fix it. It probably won't be 
until
early next week due to some travel.

Regards,

Hans



BR,
Jasmin

Here the build Log:

Kernel build directory is /lib/modules/3.13.0-117-generic/build
make -C ../linux apply_patches
make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
Patches for 3.13.0-117-generic already applied.
make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
make -C /lib/modules/3.13.0-117-generic/build 
SUBDIRS=/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l  modules
make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/linux-headers-3.13.0-117-generic'
   CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o
   CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o
   CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
   return dev->fwnode;
 ^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
   return dev->fwnode;
 ^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o] Error 1
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
   return dev->fwnode;
 ^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o] Error 1
Makefile:1279: recipe for target 
'_module_/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l' failed
make[2]: *** [_module_/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l] 
Error 2
make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/linux-headers-3.13.0-117-generic'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
Makefile:26: recipe for target 'all' failed

[media-build] Can't compile for Kernel 3.13 after recent changes

[Jasmin J.]

Hi!

After the recent changes, I can no longer compile for Kernel 3.13

BR,
   Jasmin

Here the build Log:

Kernel build directory is /lib/modules/3.13.0-117-generic/build
make -C ../linux apply_patches
make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
Patches for 3.13.0-117-generic already applied.
make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
make -C /lib/modules/3.13.0-117-generic/build 
SUBDIRS=/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l  modules
make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/linux-headers-3.13.0-117-generic'
  CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o
  CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o
  CC [M]  /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
  return dev->fwnode;
^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-lpt.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
  return dev->fwnode;
^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-comp.o] Error 1
In file included from :0:0:
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h: In function 
'dev_fwnode':
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/compat.h:2017:12: error: 
'struct device' has no member named 'fwnode'
  return dev->fwnode;
^
/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.c: At top 
level:
cc1: warning: unrecognized command line option '-Wno-implicit-fallthrough'
cc1: warning: unrecognized command line option '-Wno-unused-const-variable'
scripts/Makefile.build:308: recipe for target 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o' failed
make[3]: *** 
[/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/altera-jtag.o] Error 1
Makefile:1279: recipe for target 
'_module_/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l' failed
make[2]: *** [_module_/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l] 
Error 2
make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/linux-headers-3.13.0-117-generic'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
Makefile:26: recipe for target 'all' failed

Re: [PATCH v2] [media] v4l2: add V4L2_CAP_IO_MC

[Helen Koike]

Hi Hans,

Thanks for reviewing this

On 2017-06-19 08:15 AM, Hans Verkuil wrote:

On 06/14/2017 06:50 AM, Helen Koike wrote:

Add V4L2_CAP_IO_MC to be used in struct v4l2_capability to indicate that
input and output are controlled by the Media Controller instead of V4L2
API.
When this flag is set, ioctls for get, set and enum input and outputs
are automatically enabled and programmed to call helper function.

Signed-off-by: Helen Koike 

---

Changes in v2::
- replace the type by capability
- erase V4L2_INPUT_TYPE_DEFAULT
- also consider output
- plug helpers in the ops automatically so drivers doesn't need
to set it by hand
- update docs
- commit message and title
---
  Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 +
  Documentation/media/videodev2.h.rst.exceptions   |  1 +
  drivers/media/v4l2-core/v4l2-dev.c   | 35 +++--
  drivers/media/v4l2-core/v4l2-ioctl.c | 91
++--
  include/uapi/linux/videodev2.h   |  2 +
  5 files changed, 120 insertions(+), 12 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 12e0d9a..2bd1223 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -252,6 +252,9 @@ specification the ioctl returns an ``EINVAL``
error code.
  * - ``V4L2_CAP_TOUCH``
- 0x1000
- This is a touch device.
+* - ``V4L2_CAP_IO_MC``
+  - 0x2000
+  - This device has its inputs and outputs controller by the
Media Controller


controller -> controlled


Sorry, I'll remember to use a spell checker next time



But I would rephrase this a bit:

- The inputs and/or outputs of this device are controlled by the
Media Controller
  (see: ).



Sure, much better.
In this document, almost all the flags start with "The device 
supports..." or "The device has...", I was thinking to do something similar.



  * - ``V4L2_CAP_DEVICE_CAPS``
- 0x8000
- The driver fills the ``device_caps`` field. This capability can
diff --git a/Documentation/media/videodev2.h.rst.exceptions
b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8..0b48cd0 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -159,6 +159,7 @@ replace define V4L2_CAP_ASYNCIO device-capabilities
  replace define V4L2_CAP_STREAMING device-capabilities
  replace define V4L2_CAP_DEVICE_CAPS device-capabilities
  replace define V4L2_CAP_TOUCH device-capabilities
+replace define V4L2_CAP_IO_MC device-capabilities
# V4L2 pix flags
  replace define V4L2_PIX_FMT_PRIV_MAGIC :c:type:`v4l2_pix_format`
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index c647ba6..0f272fe 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -688,22 +688,34 @@ static void determine_valid_ioctls(struct
video_device *vdev)
  SET_VALID_IOCTL(ops, VIDIOC_G_STD, vidioc_g_std);
  if (is_rx) {
  SET_VALID_IOCTL(ops, VIDIOC_QUERYSTD, vidioc_querystd);
-SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT, vidioc_enum_input);
-SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, vidioc_g_input);
-SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, vidioc_s_input);
  SET_VALID_IOCTL(ops, VIDIOC_ENUMAUDIO, vidioc_enumaudio);
  SET_VALID_IOCTL(ops, VIDIOC_G_AUDIO, vidioc_g_audio);
  SET_VALID_IOCTL(ops, VIDIOC_S_AUDIO, vidioc_s_audio);
  SET_VALID_IOCTL(ops, VIDIOC_QUERY_DV_TIMINGS,
vidioc_query_dv_timings);
  SET_VALID_IOCTL(ops, VIDIOC_S_EDID, vidioc_s_edid);
+if (vdev->device_caps & V4L2_CAP_IO_MC) {
+set_bit(_IOC_NR(VIDIOC_ENUMINPUT), valid_ioctls);
+set_bit(_IOC_NR(VIDIOC_G_INPUT), valid_ioctls);
+set_bit(_IOC_NR(VIDIOC_S_INPUT), valid_ioctls);
+} else {
+SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT,
vidioc_enum_input);
+SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, vidioc_g_input);
+SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, vidioc_s_input);
+}
  }
  if (is_tx) {
-SET_VALID_IOCTL(ops, VIDIOC_ENUMOUTPUT, vidioc_enum_output);
-SET_VALID_IOCTL(ops, VIDIOC_G_OUTPUT, vidioc_g_output);
-SET_VALID_IOCTL(ops, VIDIOC_S_OUTPUT, vidioc_s_output);
  SET_VALID_IOCTL(ops, VIDIOC_ENUMAUDOUT, vidioc_enumaudout);
  SET_VALID_IOCTL(ops, VIDIOC_G_AUDOUT, vidioc_g_audout);
  SET_VALID_IOCTL(ops, VIDIOC_S_AUDOUT, vidioc_s_audout);
+if (vdev->device_caps & V4L2_CAP_IO_MC) {
+set_bit(_IOC_NR(VIDIOC_ENUMOUTPUT), valid_ioctls);
+set_bit(_IOC_NR(VIDIOC_G_OUTPUT), valid_ioctls);
+

Re: LinuxTV V3 vs. V4 API doc inconsistency, V4 probably wrong

[Mauro Carvalho Chehab]

Em Mon, 19 Jun 2017 16:58:40 +0200
Thierry Lelegard  escreveu:

> Hi,

First of all, there's no Linux DVB API v4. It was skipped, because there
was a proposal for a v4, with was never adopted.

> 
> There is an ambiguity in the LinuxTV documentation about the following 
> ioctl's:
> 
> FE_SET_TONE, FE_SET_VOLTAGE, FE_DISEQC_SEND_BURST.
> 
> These ioctl's take an enum value as input. In the old V3 API, the 
> parameter
> is passed by value. In the S2API documentation, it is passed by 
> reference.
> Most sample programs (a bit old) use the "pass by value" method.
> 
> V3 documentation: https://www.linuxtv.org/docs/dvbapi/dvbapi.html
> int ioctl(int fd, int request = FE_SET_TONE, fe_sec_tone_mode_t 
> tone);
> int ioctl(int fd, int request = FE_SET_VOLTAGE, fe_sec_voltage_t 
> voltage);
> int ioctl(int fd, int request = FE_DISEQC_SEND_BURST, 
> fe_sec_mini_cmd_t burst);
> 
> S2API documentation: 
> https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/dvb/frontend_fcalls.html
> int ioctl(int fd, FE_SET_TONE, enum fe_sec_tone_mode *tone)
> int ioctl(int fd, FE_SET_VOLTAGE, enum fe_sec_voltage *voltage)
> int ioctl(int fd, FE_DISEQC_SEND_BURST, enum fe_sec_mini_cmd *tone)

Thanks for reviewing it! Yeah, the asterisks there are wrong.
The definitions should be, instead:

 int ioctl(int fd, FE_SET_TONE, enum fe_sec_tone_mode tone)
 int ioctl(int fd, FE_SET_VOLTAGE, enum fe_sec_voltage voltage)
 int ioctl(int fd, FE_DISEQC_SEND_BURST, enum fe_sec_mini_cmd tone)

As they're passing by value, not by reference[1].

Feel free to send us fix patches.

Thanks,
Mauro

[PATCH v5 04/12] [media] vimc: common: Add vimc_pipeline_s_stream helper

[Helen Koike]

Move the vimc_cap_pipeline_s_stream from the vimc-cap.c to vimc-common.c
as this core will be reused by other subdevices to activate the stream
in their directly connected nodes

Signed-off-by: Helen Koike 

---

Changes in v5: None
Changes in v4: None
Changes in v3:
[media] vimc: Add vimc_pipeline_s_stream in the core
- add it in vimc-common instead of vimc-core
- rename commit with "common" tag

Changes in v2:
[media] vimc: Add vimc_pipeline_s_stream in the core
- Use is_media_entity_v4l2_subdev instead of comparing with the old
entity->type
- Fix comments style
- add kernel-docs
- call s_stream across all sink pads


---
 drivers/media/platform/vimc/vimc-capture.c | 29 ++-
 drivers/media/platform/vimc/vimc-common.c  | 32 ++
 drivers/media/platform/vimc/vimc-common.h  | 11 ++
 3 files changed, 45 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 9adb06d..93f6a09 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -132,31 +132,6 @@ static void vimc_cap_return_all_buffers(struct 
vimc_cap_device *vcap,
spin_unlock(>qlock);
 }
 
-static int vimc_cap_pipeline_s_stream(struct vimc_cap_device *vcap, int enable)
-{
-   struct v4l2_subdev *sd;
-   struct media_pad *pad;
-   int ret;
-
-   /* Start the stream in the subdevice direct connected */
-   pad = media_entity_remote_pad(>vdev.entity.pads[0]);
-
-   /*
-* if it is a raw node from vimc-core, there is nothing to activate
-* TODO: remove this when there are no more raw nodes in the
-* core and return error instead
-*/
-   if (pad->entity->obj_type == MEDIA_ENTITY_TYPE_BASE)
-   return 0;
-
-   sd = media_entity_to_v4l2_subdev(pad->entity);
-   ret = v4l2_subdev_call(sd, video, s_stream, enable);
-   if (ret && ret != -ENOIOCTLCMD)
-   return ret;
-
-   return 0;
-}
-
 static int vimc_cap_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
@@ -173,7 +148,7 @@ static int vimc_cap_start_streaming(struct vb2_queue *vq, 
unsigned int count)
}
 
/* Enable streaming from the pipe */
-   ret = vimc_cap_pipeline_s_stream(vcap, 1);
+   ret = vimc_pipeline_s_stream(>vdev.entity, 1);
if (ret) {
media_pipeline_stop(entity);
vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
@@ -192,7 +167,7 @@ static void vimc_cap_stop_streaming(struct vb2_queue *vq)
struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
 
/* Disable streaming from the pipe */
-   vimc_cap_pipeline_s_stream(vcap, 0);
+   vimc_pipeline_s_stream(>vdev.entity, 0);
 
/* Stop the media pipeline */
media_pipeline_stop(>vdev.entity);
diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 3afbabd..f809a9d 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -220,6 +220,38 @@ struct media_pad *vimc_pads_init(u16 num_pads, const 
unsigned long *pads_flag)
return pads;
 }
 
+int vimc_pipeline_s_stream(struct media_entity *ent, int enable)
+{
+   struct v4l2_subdev *sd;
+   struct media_pad *pad;
+   unsigned int i;
+   int ret;
+
+   for (i = 0; i < ent->num_pads; i++) {
+   if (ent->pads[i].flags & MEDIA_PAD_FL_SOURCE)
+   continue;
+
+   /* Start the stream in the subdevice direct connected */
+   pad = media_entity_remote_pad(>pads[i]);
+
+   /*
+* if this is a raw node from vimc-core, then there is
+* nothing to activate
+* TODO: remove this when there are no more raw nodes in the
+* core and return error instead
+*/
+   if (pad->entity->obj_type == MEDIA_ENTITY_TYPE_BASE)
+   continue;
+
+   sd = media_entity_to_v4l2_subdev(pad->entity);
+   ret = v4l2_subdev_call(sd, video, s_stream, enable);
+   if (ret && ret != -ENOIOCTLCMD)
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct media_entity_operations vimc_ent_sd_mops = {
.link_validate = v4l2_subdev_link_validate,
 };
diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 9ec361c..73e7e94 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -97,6 +97,17 @@ static inline void vimc_pads_cleanup(struct media_pad *pads)
 }
 
 /**
+ * vimc_pipeline_s_stream - start stream through the pipeline
+ *
+ * @ent:  

[PATCH v5 07/12] [media] vimc: sen: Support several image formats

[Helen Koike]

Allow user space to change the image format as the frame size, the
media bus pixel format, colorspace, quantization, field YCbCr encoding
and the transfer function

Signed-off-by: Helen Koike 

---

Changes in v5: None
Changes in v4:
[media] vimc: sen: Support several image formats
- use vimc_colorimetry_clamp macro
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct

Changes in v3:
[media] vimc: sen: Support several image formats
- remove support for V4L2_FIELD_ALTERNATE (left as TODO for now)
- clamp image size to an even dimension for height and width
- set default values for colorimetry using _DEFAULT macro
- reset all values of colorimetry to _DEFAULT if user tries to
set an invalid colorspace

Changes in v2:
[media] vimc: sen: Support several image formats
- this is a new commit in the serie (the old one was splitted in two)
- add init_cfg to initialize try_fmt
- reorder code in vimc_sen_set_fmt
- allow user space to change all fields from struct v4l2_mbus_framefmt
  (e.g. colospace, quantization, field, xfer_func, ycbcr_enc)
- merge with patch for the enum_mbus_code and enum_frame_size
- change commit message
- add vimc_pix_map_by_index
- rename MIN/MAX macros
- check set_fmt default parameters for quantization, colorspace 
...media] vimc: sen: Support several image formats


---
 drivers/media/platform/vimc/vimc-common.c |   8 ++
 drivers/media/platform/vimc/vimc-common.h |  12 +++
 drivers/media/platform/vimc/vimc-sensor.c | 130 +++---
 3 files changed, 121 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 6ad77fd..b698055 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -144,6 +144,14 @@ static const struct vimc_pix_map vimc_pix_map_list[] = {
},
 };
 
+const struct vimc_pix_map *vimc_pix_map_by_index(unsigned int i)
+{
+   if (i >= ARRAY_SIZE(vimc_pix_map_list))
+   return NULL;
+
+   return _pix_map_list[i];
+}
+
 const struct vimc_pix_map *vimc_pix_map_by_code(u32 code)
 {
unsigned int i;
diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 43483ee..fb3463c 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -22,6 +22,11 @@
 #include 
 #include 
 
+#define VIMC_FRAME_MAX_WIDTH 4096
+#define VIMC_FRAME_MAX_HEIGHT 2160
+#define VIMC_FRAME_MIN_WIDTH 16
+#define VIMC_FRAME_MIN_HEIGHT 16
+
 /**
  * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
  *
@@ -139,6 +144,13 @@ static inline void vimc_pads_cleanup(struct media_pad 
*pads)
 int vimc_pipeline_s_stream(struct media_entity *ent, int enable);
 
 /**
+ * vimc_pix_map_by_index - get vimc_pix_map struct by its index
+ *
+ * @i: index of the vimc_pix_map struct in vimc_pix_map_list
+ */
+const struct vimc_pix_map *vimc_pix_map_by_index(unsigned int i);
+
+/**
  * vimc_pix_map_by_code - get vimc_pix_map struct by media bus code
  *
  * @code:  media bus format code defined by MEDIA_BUS_FMT_* macros
diff --git a/drivers/media/platform/vimc/vimc-sensor.c 
b/drivers/media/platform/vimc/vimc-sensor.c
index 6386ac1..d4f9705 100644
--- a/drivers/media/platform/vimc/vimc-sensor.c
+++ b/drivers/media/platform/vimc/vimc-sensor.c
@@ -24,8 +24,6 @@
 
 #include "vimc-sensor.h"
 
-#define VIMC_SEN_FRAME_MAX_WIDTH 4096
-
 struct vimc_sen_device {
struct vimc_ent_device ved;
struct v4l2_subdev sd;
@@ -36,18 +34,39 @@ struct vimc_sen_device {
struct v4l2_mbus_framefmt mbus_format;
 };
 
+static const struct v4l2_mbus_framefmt fmt_default = {
+   .width = 640,
+   .height = 480,
+   .code = MEDIA_BUS_FMT_RGB888_1X24,
+   .field = V4L2_FIELD_NONE,
+   .colorspace = V4L2_COLORSPACE_DEFAULT,
+};
+
+static int vimc_sen_init_cfg(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg)
+{
+   unsigned int i;
+
+   for (i = 0; i < sd->entity.num_pads; i++) {
+   struct v4l2_mbus_framefmt *mf;
+
+   mf = v4l2_subdev_get_try_format(sd, cfg, i);
+   *mf = fmt_default;
+   }
+
+   return 0;
+}
+
 static int vimc_sen_enum_mbus_code(struct v4l2_subdev *sd,
   struct v4l2_subdev_pad_config *cfg,
   struct v4l2_subdev_mbus_code_enum *code)
 {
-   struct vimc_sen_device *vsen =
-   container_of(sd, struct vimc_sen_device, sd);
+   const struct vimc_pix_map *vpix = vimc_pix_map_by_index(code->index);
 
-   /* TODO: Add support for other codes */
-   if (code->index)
+   if (!vpix)

[PATCH v5 06/12] [media] vimc: common: Add vimc_colorimetry_clamp

[Helen Koike]

Colorimetry value will always be checked in the same way. Adding a
helper macro for that

Signed-off-by: Helen Koike 

---

Changes in v5: None
Changes in v4:
[media] vimc: common: Add vimc_colorimetry_clamp
- this is a new patch in the series

Changes in v3: None
Changes in v2: None


---
 drivers/media/platform/vimc/vimc-common.h | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 60ebde2..43483ee 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -23,6 +23,32 @@
 #include 
 
 /**
+ * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
+ *
+ * @fmt:   the pointer to struct v4l2_pix_format or
+ * struct v4l2_mbus_framefmt
+ *
+ * Entities must check if colorimetry given by the userspace is valid, if not
+ * then set them as DEFAULT
+ */
+#define vimc_colorimetry_clamp(fmt)\
+do {   \
+   if ((fmt)->colorspace == V4L2_COLORSPACE_DEFAULT\
+   || (fmt)->colorspace > V4L2_COLORSPACE_DCI_P3) {\
+   (fmt)->colorspace = V4L2_COLORSPACE_DEFAULT;\
+   (fmt)->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;  \
+   (fmt)->quantization = V4L2_QUANTIZATION_DEFAULT;\
+   (fmt)->xfer_func = V4L2_XFER_FUNC_DEFAULT;  \
+   }   \
+   if ((fmt)->ycbcr_enc > V4L2_YCBCR_ENC_SMPTE240M)\
+   (fmt)->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;  \
+   if ((fmt)->quantization > V4L2_QUANTIZATION_LIM_RANGE)  \
+   (fmt)->quantization = V4L2_QUANTIZATION_DEFAULT;\
+   if ((fmt)->xfer_func > V4L2_XFER_FUNC_SMPTE2084)\
+   (fmt)->xfer_func = V4L2_XFER_FUNC_DEFAULT;  \
+} while (0)
+
+/**
  * struct vimc_pix_map - maps media bus code with v4l2 pixel format
  *
  * @code:  media bus format code defined by MEDIA_BUS_FMT_* macros
-- 
2.7.4

[PATCH v5 01/12] [media] vimc: sen: Integrate the tpg on the sensor

[Helen Koike]

Initialize the test pattern generator on the sensor
Generate a colored bar image instead of a grey one

Signed-off-by: Helen Koike 

---

Changes in v5: None
Changes in v4: None
Changes in v3:
[media] vimc: sen: Integrate the tpg on the sensor
- Declare frame_size as a local variable
- Set tpg frame format before starting kthread
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): return 0 if stream is already disabled
- s_stream: propagate error from kthread_stop
- coding style when calling tpg_s_bytesperline
- s/vimc_thread_sen/vimc_sen_tpg_thread
- fix multiline comment
- remove V4L2_FIELD_ALTERNATE from tpg_s_field
- remove V4L2_STD_PAL from tpg_fill_plane_buffer

Changes in v2:
[media] vimc: sen: Integrate the tpg on the sensor
- Fix include location
- Select V4L2_TPG in Kconfig
- configure tpg on streamon only
- rm BUG_ON
- coding style


---
 drivers/media/platform/vimc/Kconfig   |  1 +
 drivers/media/platform/vimc/vimc-sensor.c | 64 ---
 2 files changed, 52 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/vimc/Kconfig 
b/drivers/media/platform/vimc/Kconfig
index a18f635..71c9fe7 100644
--- a/drivers/media/platform/vimc/Kconfig
+++ b/drivers/media/platform/vimc/Kconfig
@@ -2,6 +2,7 @@ config VIDEO_VIMC
tristate "Virtual Media Controller Driver (VIMC)"
depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_VMALLOC
+   select VIDEO_V4L2_TPG
default n
---help---
  Skeleton driver for Virtual Media Controller
diff --git a/drivers/media/platform/vimc/vimc-sensor.c 
b/drivers/media/platform/vimc/vimc-sensor.c
index 591f6a4..2e83487 100644
--- a/drivers/media/platform/vimc/vimc-sensor.c
+++ b/drivers/media/platform/vimc/vimc-sensor.c
@@ -20,17 +20,20 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vimc-sensor.h"
 
+#define VIMC_SEN_FRAME_MAX_WIDTH 4096
+
 struct vimc_sen_device {
struct vimc_ent_device ved;
struct v4l2_subdev sd;
+   struct tpg_data tpg;
struct task_struct *kthread_sen;
u8 *frame;
/* The active format */
struct v4l2_mbus_framefmt mbus_format;
-   int frame_size;
 };
 
 static int vimc_sen_enum_mbus_code(struct v4l2_subdev *sd,
@@ -84,6 +87,24 @@ static int vimc_sen_get_fmt(struct v4l2_subdev *sd,
return 0;
 }
 
+static void vimc_sen_tpg_s_format(struct vimc_sen_device *vsen)
+{
+   const struct vimc_pix_map *vpix =
+   vimc_pix_map_by_code(vsen->mbus_format.code);
+
+   tpg_reset_source(>tpg, vsen->mbus_format.width,
+vsen->mbus_format.height, vsen->mbus_format.field);
+   tpg_s_bytesperline(>tpg, 0, vsen->mbus_format.width * vpix->bpp);
+   tpg_s_buf_height(>tpg, vsen->mbus_format.height);
+   tpg_s_fourcc(>tpg, vpix->pixelformat);
+   /* TODO: add support for V4L2_FIELD_ALTERNATE */
+   tpg_s_field(>tpg, vsen->mbus_format.field, false);
+   tpg_s_colorspace(>tpg, vsen->mbus_format.colorspace);
+   tpg_s_ycbcr_enc(>tpg, vsen->mbus_format.ycbcr_enc);
+   tpg_s_quantization(>tpg, vsen->mbus_format.quantization);
+   tpg_s_xfer_func(>tpg, vsen->mbus_format.xfer_func);
+}
+
 static const struct v4l2_subdev_pad_ops vimc_sen_pad_ops = {
.enum_mbus_code = vimc_sen_enum_mbus_code,
.enum_frame_size= vimc_sen_enum_frame_size,
@@ -97,7 +118,7 @@ static const struct media_entity_operations vimc_sen_mops = {
.link_validate = v4l2_subdev_link_validate,
 };
 
-static int vimc_thread_sen(void *data)
+static int vimc_sen_tpg_thread(void *data)
 {
struct vimc_sen_device *vsen = data;
unsigned int i;
@@ -110,7 +131,7 @@ static int vimc_thread_sen(void *data)
if (kthread_should_stop())
break;
 
-   memset(vsen->frame, 100, vsen->frame_size);
+   tpg_fill_plane_buffer(>tpg, 0, 0, vsen->frame);
 
/* Send the frame to all source pads */
for (i = 0; i < vsen->sd.entity.num_pads; i++)
@@ -132,26 +153,31 @@ static int vimc_sen_s_stream(struct v4l2_subdev *sd, int 
enable)
 
if (enable) {
const struct vimc_pix_map *vpix;
+   unsigned int frame_size;
 
if (vsen->kthread_sen)
-   return -EINVAL;
+   /* tpg is already executing */
+   return 0;
 
/* Calculate the frame size */
vpix = vimc_pix_map_by_code(vsen->mbus_format.code);
-   vsen->frame_size = vsen->mbus_format.width * vpix->bpp *
-  vsen->mbus_format.height;
+   frame_size = vsen->mbus_format.width * vpix->bpp *
+

[PATCH v5 08/12] [media] vimc: cap: Support several image formats

[Helen Koike]

Allow user space to change the image format as the frame size, the
pixel format, colorspace, quantization, field YCbCr encoding
and the transfer function

Signed-off-by: Helen Koike 

---

Changes in v5: None
Changes in v4:
[media] vimc: cap: Support several image formats
- add vimc_colorimetry_clamp macro
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct

Changes in v3:
[media] vimc: cap: Support several image formats
- use *_DEFAULT macros for colorimetry in the default format
- clamp height and width of the image by an even value
- is user try to set colorspace to an invalid format, set all
colorimetry parameters to _DEFAULT
- remove V4L2_FMT_FLAG_COMPRESSED from vimc_cap_enum_fmt_vid_cap
- remove V4L2_BUF_TYPE_VIDEO_CAPTURE from vimc_cap_enum_fmt_vid_cap
- increase step_width and step_height to 2 instead of 1
- remove link validate function, use the one in vimc-common.c

Changes in v2:
[media] vimc: cap: Support several image formats
- this is a new commit in the serie (the old one was splitted in two)
- allow user space to change all fields from struct v4l2_pix_format
  (e.g. colospace, quantization, field, xfer_func, ycbcr_enc)
- link_validate and try_fmt: also checks colospace, quantization, 
field, xfer_func, ycbcr_enc
- add struct v4l2_pix_format fmt_default
- add enum_framesizes
- enum_fmt_vid_cap: enumerate all formats from vimc_pix_map_table
- add mode dev_dbg


---
 drivers/media/platform/vimc/vimc-capture.c | 117 +
 1 file changed, 101 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 5bdecd1..359f59e 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -40,6 +40,14 @@ struct vimc_cap_device {
struct media_pipeline pipe;
 };
 
+static const struct v4l2_pix_format fmt_default = {
+   .width = 640,
+   .height = 480,
+   .pixelformat = V4L2_PIX_FMT_RGB24,
+   .field = V4L2_FIELD_NONE,
+   .colorspace = V4L2_COLORSPACE_DEFAULT,
+};
+
 struct vimc_cap_buffer {
/*
 * struct vb2_v4l2_buffer must be the first element
@@ -73,7 +81,7 @@ static void vimc_cap_get_format(struct vimc_ent_device *ved,
*fmt = vcap->format;
 }
 
-static int vimc_cap_fmt_vid_cap(struct file *file, void *priv,
+static int vimc_cap_g_fmt_vid_cap(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct vimc_cap_device *vcap = video_drvdata(file);
@@ -83,16 +91,98 @@ static int vimc_cap_fmt_vid_cap(struct file *file, void 
*priv,
return 0;
 }
 
+static int vimc_cap_try_fmt_vid_cap(struct file *file, void *priv,
+   struct v4l2_format *f)
+{
+   struct v4l2_pix_format *format = >fmt.pix;
+   const struct vimc_pix_map *vpix;
+
+   format->width = clamp_t(u32, format->width, VIMC_FRAME_MIN_WIDTH,
+   VIMC_FRAME_MAX_WIDTH) & ~1;
+   format->height = clamp_t(u32, format->height, VIMC_FRAME_MIN_HEIGHT,
+VIMC_FRAME_MAX_HEIGHT) & ~1;
+
+   /* Don't accept a pixelformat that is not on the table */
+   vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
+   if (!vpix) {
+   format->pixelformat = fmt_default.pixelformat;
+   vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
+   }
+   /* TODO: Add support for custom bytesperline values */
+   format->bytesperline = format->width * vpix->bpp;
+   format->sizeimage = format->bytesperline * format->height;
+
+   if (format->field == V4L2_FIELD_ANY)
+   format->field = fmt_default.field;
+
+   vimc_colorimetry_clamp(format);
+
+   return 0;
+}
+
+static int vimc_cap_s_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+   struct vimc_cap_device *vcap = video_drvdata(file);
+
+   /* Do not change the format while stream is on */
+   if (vb2_is_busy(>queue))
+   return -EBUSY;
+
+   vimc_cap_try_fmt_vid_cap(file, priv, f);
+
+   dev_dbg(vcap->vdev.v4l2_dev->dev, "%s: format update: "
+   "old:%dx%d (0x%x, %d, %d, %d, %d) "
+   "new:%dx%d (0x%x, %d, %d, %d, %d)\n", vcap->vdev.name,
+   /* old */
+   vcap->format.width, vcap->format.height,
+   vcap->format.pixelformat, vcap->format.colorspace,
+   vcap->format.quantization, vcap->format.xfer_func,
+   vcap->format.ycbcr_enc,
+   /* new */
+   f->fmt.pix.width, f->fmt.pix.height,
+   f->fmt.pix.pixelformat, f->fmt.pix.colorspace,
+   

[PATCH v5 02/12] [media] vimc: Move common code from the core

[Helen Koike]

Remove helper functions from vimc-core and add it in vimc-common to
clean up the core.

Signed-off-by: Helen Koike 

---

Changes in v5: None
Changes in v4: None
Changes in v3:
[media] vimc: Move common code from the core
- This is a new patch in the series

Changes in v2: None


---
 drivers/media/platform/vimc/Makefile   |   2 +-
 drivers/media/platform/vimc/vimc-capture.h |   2 +-
 drivers/media/platform/vimc/vimc-common.c  | 221 +
 .../platform/vimc/{vimc-core.h => vimc-common.h}   |   7 +-
 drivers/media/platform/vimc/vimc-core.c| 205 +--
 drivers/media/platform/vimc/vimc-sensor.h  |   2 +-
 6 files changed, 229 insertions(+), 210 deletions(-)
 create mode 100644 drivers/media/platform/vimc/vimc-common.c
 rename drivers/media/platform/vimc/{vimc-core.h => vimc-common.h} (96%)

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index c45195e..6b6ddf4 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -1,3 +1,3 @@
-vimc-objs := vimc-core.o vimc-capture.o vimc-sensor.o
+vimc-objs := vimc-core.o vimc-capture.o vimc-common.o vimc-sensor.o
 
 obj-$(CONFIG_VIDEO_VIMC) += vimc.o
diff --git a/drivers/media/platform/vimc/vimc-capture.h 
b/drivers/media/platform/vimc/vimc-capture.h
index 581a813..7e5c707 100644
--- a/drivers/media/platform/vimc/vimc-capture.h
+++ b/drivers/media/platform/vimc/vimc-capture.h
@@ -18,7 +18,7 @@
 #ifndef _VIMC_CAPTURE_H_
 #define _VIMC_CAPTURE_H_
 
-#include "vimc-core.h"
+#include "vimc-common.h"
 
 struct vimc_ent_device *vimc_cap_create(struct v4l2_device *v4l2_dev,
const char *const name,
diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
new file mode 100644
index 000..42f779a
--- /dev/null
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -0,0 +1,221 @@
+/*
+ * vimc-common.c Virtual Media Controller Driver
+ *
+ * Copyright (C) 2015-2017 Helen Koike 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include "vimc-common.h"
+
+static const struct vimc_pix_map vimc_pix_map_list[] = {
+   /* TODO: add all missing formats */
+
+   /* RGB formats */
+   {
+   .code = MEDIA_BUS_FMT_BGR888_1X24,
+   .pixelformat = V4L2_PIX_FMT_BGR24,
+   .bpp = 3,
+   },
+   {
+   .code = MEDIA_BUS_FMT_RGB888_1X24,
+   .pixelformat = V4L2_PIX_FMT_RGB24,
+   .bpp = 3,
+   },
+   {
+   .code = MEDIA_BUS_FMT_ARGB_1X32,
+   .pixelformat = V4L2_PIX_FMT_ARGB32,
+   .bpp = 4,
+   },
+
+   /* Bayer formats */
+   {
+   .code = MEDIA_BUS_FMT_SBGGR8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SBGGR8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGBRG8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SGBRG8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGRBG8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SGRBG8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SRGGB8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SRGGB8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SBGGR10_1X10,
+   .pixelformat = V4L2_PIX_FMT_SBGGR10,
+   .bpp = 2,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGBRG10_1X10,
+   .pixelformat = V4L2_PIX_FMT_SGBRG10,
+   .bpp = 2,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGRBG10_1X10,
+   .pixelformat = V4L2_PIX_FMT_SGRBG10,
+   .bpp = 2,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SRGGB10_1X10,
+   .pixelformat = V4L2_PIX_FMT_SRGGB10,
+   .bpp = 2,
+   },
+
+   /* 10bit raw bayer a-law compressed to 8 bits */
+   {
+   .code = MEDIA_BUS_FMT_SBGGR10_ALAW8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SBGGR10ALAW8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGBRG10_ALAW8_1X8,
+   .pixelformat = V4L2_PIX_FMT_SGBRG10ALAW8,
+   .bpp = 1,
+   },
+   {
+   .code = MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8,
+   .pixelformat = 

[PATCH v5 05/12] [media] vimc: common: Add vimc_link_validate

[Helen Koike]

All links will be checked in the same way. Adding a helper function for
that

Signed-off-by: Helen Koike 

---

Changes in v5: None
Changes in v4:
[media] vimc: common: Add vimc_link_validate
- remove vimc_fmt_pix_to_mbus(), replaced by
v4l2_fill_mbus_format()
- remove EXPORT_SYMBOL(vimc_link_validate), not necessary in
this patch, moved to submodules patch
- Fix multi-line comment style
- If colorspace is set to DEFAULT, then assume all the other
colorimetry parameters are also DEFAULT

Changes in v3:
[media] vimc: common: Add vimc_link_validate
- this is a new patch in the series

Changes in v2: None


---
 drivers/media/platform/vimc/vimc-capture.c |  78 +++
 drivers/media/platform/vimc/vimc-common.c  | 121 -
 drivers/media/platform/vimc/vimc-common.h  |  14 
 3 files changed, 145 insertions(+), 68 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 93f6a09..5bdecd1 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -64,6 +64,15 @@ static int vimc_cap_querycap(struct file *file, void *priv,
return 0;
 }
 
+static void vimc_cap_get_format(struct vimc_ent_device *ved,
+   struct v4l2_pix_format *fmt)
+{
+   struct vimc_cap_device *vcap = container_of(ved, struct vimc_cap_device,
+   ved);
+
+   *fmt = vcap->format;
+}
+
 static int vimc_cap_fmt_vid_cap(struct file *file, void *priv,
  struct v4l2_format *f)
 {
@@ -231,74 +240,8 @@ static const struct vb2_ops vimc_cap_qops = {
.wait_finish= vb2_ops_wait_finish,
 };
 
-/*
- * NOTE: this function is a copy of v4l2_subdev_link_validate_get_format
- * maybe the v4l2 function should be public
- */
-static int vimc_cap_v4l2_subdev_link_validate_get_format(struct media_pad *pad,
-   struct v4l2_subdev_format *fmt)
-{
-   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(pad->entity);
-
-   fmt->which = V4L2_SUBDEV_FORMAT_ACTIVE;
-   fmt->pad = pad->index;
-
-   return v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
-}
-
-static int vimc_cap_link_validate(struct media_link *link)
-{
-   struct v4l2_subdev_format source_fmt;
-   const struct vimc_pix_map *vpix;
-   struct vimc_cap_device *vcap = container_of(link->sink->entity,
-   struct vimc_cap_device,
-   vdev.entity);
-   struct v4l2_pix_format *sink_fmt = >format;
-   int ret;
-
-   /*
-* if it is a raw node from vimc-core, ignore the link for now
-* TODO: remove this when there are no more raw nodes in the
-* core and return error instead
-*/
-   if (link->source->entity->obj_type == MEDIA_ENTITY_TYPE_BASE)
-   return 0;
-
-   /* Get the the format of the subdev */
-   ret = vimc_cap_v4l2_subdev_link_validate_get_format(link->source,
-   _fmt);
-   if (ret)
-   return ret;
-
-   dev_dbg(vcap->vdev.v4l2_dev->dev,
-   "%s: link validate formats src:%dx%d %d sink:%dx%d %d\n",
-   vcap->vdev.name,
-   source_fmt.format.width, source_fmt.format.height,
-   source_fmt.format.code,
-   sink_fmt->width, sink_fmt->height,
-   sink_fmt->pixelformat);
-
-   /* The width, height and code must match. */
-   vpix = vimc_pix_map_by_pixelformat(sink_fmt->pixelformat);
-   if (source_fmt.format.width != sink_fmt->width
-   || source_fmt.format.height != sink_fmt->height
-   || vpix->code != source_fmt.format.code)
-   return -EPIPE;
-
-   /*
-* The field order must match, or the sink field order must be NONE
-* to support interlaced hardware connected to bridges that support
-* progressive formats only.
-*/
-   if (source_fmt.format.field != sink_fmt->field &&
-   sink_fmt->field != V4L2_FIELD_NONE)
-   return -EPIPE;
-
-   return 0;
-}
-
 static const struct media_entity_operations vimc_cap_mops = {
-   .link_validate  = vimc_cap_link_validate,
+   .link_validate  = vimc_link_validate,
 };
 
 static void vimc_cap_destroy(struct vimc_ent_device *ved)
@@ -434,6 +377,7 @@ struct vimc_ent_device *vimc_cap_create(struct v4l2_device 
*v4l2_dev,
vcap->ved.destroy = vimc_cap_destroy;
vcap->ved.ent = >vdev.entity;
vcap->ved.process_frame = vimc_cap_process_frame;
+   vcap->ved.vdev_get_format = vimc_cap_get_format;
 
/* Initialize the video_device struct */
vdev = >vdev;
diff --git 

[PATCH v5 09/12] [media] vimc: Subdevices as modules

[Helen Koike]

Change the core structure for adding subdevices in the topology.
Instead of calling the specific create function for each subdevice,
inject a child platform_device with the driver's name.
Each type of node in the topology (sensor, capture, debayer, scaler)
will register a platform_driver with the corresponding name through the
component subsystem.
Implementing a new subdevice type doesn't require vimc-core to be altered.

This facilitates future implementation of dynamic entities, where
hotpluging an entity in the topology is just a matter of
registering/unregistering a platform_device in the system.
It also facilitates other implementations of different nodes without
touching the core code and remove the need of a header file for each
type of node.

Signed-off-by: Helen Koike 

---

Changes in v5:
[media] vimc: Subdevices as modules
- Fix vimc_add_subdevs in rollback case. The loop variable can
be negative, remove 'unsigned' from the loop variable and fix
warning from smatch tool

Changes in v4:
[media] vimc: Subdevices as modules
- Rebase without [media] vimc: Optimize frame generation the through
pipe
- s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL
- add struct vimc_platform_data to pass the entity's name to the
sudmodule
- Fix comment about vimc-input (remove vimc-output comment)

Changes in v3:
[media] vimc: Subdevices as modules
- This is a new patch in the series

Changes in v2: None


---
 drivers/media/platform/vimc/Makefile   |   7 +-
 drivers/media/platform/vimc/vimc-capture.c |  99 ---
 drivers/media/platform/vimc/vimc-capture.h |  28 --
 drivers/media/platform/vimc/vimc-common.c  |  38 +--
 drivers/media/platform/vimc/vimc-common.h  |  29 ++-
 drivers/media/platform/vimc/vimc-core.c| 405 +++--
 drivers/media/platform/vimc/vimc-sensor.c  |  93 +--
 drivers/media/platform/vimc/vimc-sensor.h  |  28 --
 8 files changed, 339 insertions(+), 388 deletions(-)
 delete mode 100644 drivers/media/platform/vimc/vimc-capture.h
 delete mode 100644 drivers/media/platform/vimc/vimc-sensor.h

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index 6b6ddf4..0e5d5ce 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -1,3 +1,6 @@
-vimc-objs := vimc-core.o vimc-capture.o vimc-common.o vimc-sensor.o
+vimc-objs := vimc-core.o
+vimc_capture-objs := vimc-capture.o
+vimc_common-objs := vimc-common.o
+vimc_sensor-objs := vimc-sensor.o
 
-obj-$(CONFIG_VIDEO_VIMC) += vimc.o
+obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc_sensor.o
diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 359f59e..14cb32e 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -15,15 +15,21 @@
  *
  */
 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
-#include "vimc-capture.h"
+#include "vimc-common.h"
+
+#define VIMC_CAP_DRV_NAME "vimc-capture"
 
 struct vimc_cap_device {
struct vimc_ent_device ved;
struct video_device vdev;
+   struct device *dev;
struct v4l2_pix_format format;
struct vb2_queue queue;
struct list_head buf_list;
@@ -131,7 +137,7 @@ static int vimc_cap_s_fmt_vid_cap(struct file *file, void 
*priv,
 
vimc_cap_try_fmt_vid_cap(file, priv, f);
 
-   dev_dbg(vcap->vdev.v4l2_dev->dev, "%s: format update: "
+   dev_dbg(vcap->dev, "%s: format update: "
"old:%dx%d (0x%x, %d, %d, %d, %d) "
"new:%dx%d (0x%x, %d, %d, %d, %d)\n", vcap->vdev.name,
/* old */
@@ -309,8 +315,7 @@ static int vimc_cap_buffer_prepare(struct vb2_buffer *vb)
unsigned long size = vcap->format.sizeimage;
 
if (vb2_plane_size(vb, 0) < size) {
-   dev_err(vcap->vdev.v4l2_dev->dev,
-   "%s: buffer too small (%lu < %lu)\n",
+   dev_err(vcap->dev, "%s: buffer too small (%lu < %lu)\n",
vcap->vdev.name, vb2_plane_size(vb, 0), size);
return -EINVAL;
}
@@ -335,8 +340,10 @@ static const struct media_entity_operations vimc_cap_mops 
= {
.link_validate  = vimc_link_validate,
 };
 
-static void vimc_cap_destroy(struct vimc_ent_device *ved)
+static void vimc_cap_comp_unbind(struct device *comp, struct device *master,
+void *master_data)
 {
+   struct vimc_ent_device *ved = dev_get_drvdata(comp);
struct vimc_cap_device *vcap = container_of(ved, struct vimc_cap_device,
ved);
 
@@ -385,42 +392,35 @@ static void vimc_cap_process_frame(struct vimc_ent_device 
*ved,
vb2_buffer_done(_buf->vb2.vb2_buf, VB2_BUF_STATE_DONE);
 }
 
-struct vimc_ent_device *vimc_cap_create(struct v4l2_device *v4l2_dev,

[PATCH v5 10/12] [media] vimc: deb: Add debayer filter

[Helen Koike]

Implement the debayer filter and integrate it with the core

Signed-off-by: Helen Koike 

---

Changes in v5:
[media] vimc: deb: Add debayer filter
- delare vimc_deb_video_ops as static, remove sparse warning

Changes in v4:
[media] vimc: deb: Add debayer filter
- Rebase without [media] vimc: Optimize frame generation through
pipe
- use vimc_colorimetry_clamp
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
- use struct vimc_platform_data to retrieve the entity's name

Changes in v3:
[media] vimc: deb: Add debayer filter
- Declare frame_size as a local variable
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): return 0 if stream is already disabled
- s_stream: add ret variable to propagate return errors
- structure code to be a module, use platform_driver and component 
system
- fix multiline comment
- s/thought/through
- s/RGB/RGB888
- clamp height and width of the image by an even value
- if user try to set colorspace to an invalid format, set all
colorimetry parameters to _DEFAULT
- uset _DEFAULT for colorimetry in the default format

Changes in v2:
[media] vimc: deb: Add debayer filter
- Using MEDIA_ENT_F_ATV_DECODER in function
- remove v4l2_dev and dev from vimc_deb_device struct
- src fmt propagates from the sink
- coding style
- remove redundant else if statements
- check end of enum and remove BUG_ON
- enum frame size with min and max values
- set/try fmt
- remove unecessary include freezer.h
- check pad types on create
- return EBUSY when trying to set the format while stream is on
- remove vsd struct
- add IS_SRC and IS_SINK macros
- add deb_mean_win_size as a parameter of the module
- check set_fmt default parameters for quantization, colorspace ...
- add more dev_dbg


---
 drivers/media/platform/vimc/Makefile   |   4 +-
 drivers/media/platform/vimc/vimc-common.h  |   2 +
 drivers/media/platform/vimc/vimc-debayer.c | 601 +
 3 files changed, 606 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/vimc/vimc-debayer.c

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index 0e5d5ce..4fba8ef 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -1,6 +1,8 @@
 vimc-objs := vimc-core.o
 vimc_capture-objs := vimc-capture.o
 vimc_common-objs := vimc-common.o
+vimc_debayer-objs := vimc-debayer.o
 vimc_sensor-objs := vimc-sensor.o
 
-obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc_sensor.o
+obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc-debayer.o 
\
+   vimc_sensor.o
diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index a9c1cfd..25ba752 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -27,6 +27,8 @@
 #define VIMC_FRAME_MIN_WIDTH 16
 #define VIMC_FRAME_MIN_HEIGHT 16
 
+#define VIMC_FRAME_INDEX(lin, col, width, bpp) ((lin * width + col) * bpp)
+
 /**
  * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
  *
diff --git a/drivers/media/platform/vimc/vimc-debayer.c 
b/drivers/media/platform/vimc/vimc-debayer.c
new file mode 100644
index 000..35b15bd
--- /dev/null
+++ b/drivers/media/platform/vimc/vimc-debayer.c
@@ -0,0 +1,601 @@
+/*
+ * vimc-debayer.c Virtual Media Controller Driver
+ *
+ * Copyright (C) 2015-2017 Helen Koike 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vimc-common.h"
+
+#define VIMC_DEB_DRV_NAME "vimc-debayer"
+
+static unsigned int deb_mean_win_size = 3;
+module_param(deb_mean_win_size, uint, );
+MODULE_PARM_DESC(deb_mean_win_size, " the window size to calculate the mean.\n"
+   "NOTE: the window size need to be an odd number, as the main pixel "
+   "stays in the center of the window, otherwise the next odd number "
+   "is considered");
+
+#define IS_SINK(pad) (!pad)
+#define IS_SRC(pad)  (pad)
+
+enum vimc_deb_rgb_colors {
+   VIMC_DEB_RED = 0,
+   VIMC_DEB_GREEN = 1,
+   VIMC_DEB_BLUE = 2,

[PATCH v5 11/12] [media] vimc: sca: Add scaler

[Helen Koike]

Implement scaler and integrated with the core

Signed-off-by: Helen Koike 

---

Changes in v5:
[media] vimc: sca: Add scaler
- declare vimc_sca_video_ops as static, remove sparse warning

Changes in v4:
[media] vimc: sca: Add scaler
- use vimc_colorimetry_clamp
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
- use struct vimc_platform_data to retrieve the entity's name

Changes in v3:
[media] vimc: sca: Add scaler
- Declare frame_size as a local variable
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): return 0 if stream is already disabled
- s_stream: add ret variable to propagate return errors
- structure code to be a module, use platform_driver and component 
system
- s/thought/through
- clamp height and width of the image by an even value
- if user try to set colorspace to an invalid format, set all
colorimetry parameters to _DEFAULT
- uset _DEFAULT for colorimetry in the default format

Changes in v2:
[media] vimc: sca: Add scaler
- Add function MEDIA_ENT_F_IO_V4L
- remove v4l2_dev and dev
- s/sink_mbus_fmt/sink_fmt
- remove BUG_ON, remove redundant if else, rewrite TODO, check end of 
enum
- rm src_width/height, enum fsize with min and max values
- set/try fmt
- remove unecessary include freezer.h
- core: add bayer boolean in pixel table
- coding style
- fix bug in enum frame size
- check pad types on create
- return EBUSY when trying to set the format while stream is on
- remove vsd struct
- add IS_SRC and IS_SINK macros
- add sca_mult as a parameter of the module
- check set_fmt default parameters for quantization, colorspace ...
- add more dev_dbg


---
 drivers/media/platform/vimc/Makefile  |   3 +-
 drivers/media/platform/vimc/vimc-common.c |  27 ++
 drivers/media/platform/vimc/vimc-common.h |   1 +
 drivers/media/platform/vimc/vimc-scaler.c | 455 ++
 4 files changed, 485 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/vimc/vimc-scaler.c

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index 4fba8ef..68c5d98 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -2,7 +2,8 @@ vimc-objs := vimc-core.o
 vimc_capture-objs := vimc-capture.o
 vimc_common-objs := vimc-common.o
 vimc_debayer-objs := vimc-debayer.o
+vimc_scaler-objs := vimc-scaler.o
 vimc_sensor-objs := vimc-sensor.o
 
 obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc-debayer.o 
\
-   vimc_sensor.o
+   vimc_scaler.o vimc_sensor.o
diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index da7f2b7..9d63c84 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -20,6 +20,10 @@
 
 #include "vimc-common.h"
 
+/*
+ * NOTE: non-bayer formats need to come first (necessary for enum_mbus_code
+ * in the scaler)
+ */
 static const struct vimc_pix_map vimc_pix_map_list[] = {
/* TODO: add all missing formats */
 
@@ -28,16 +32,19 @@ static const struct vimc_pix_map vimc_pix_map_list[] = {
.code = MEDIA_BUS_FMT_BGR888_1X24,
.pixelformat = V4L2_PIX_FMT_BGR24,
.bpp = 3,
+   .bayer = false,
},
{
.code = MEDIA_BUS_FMT_RGB888_1X24,
.pixelformat = V4L2_PIX_FMT_RGB24,
.bpp = 3,
+   .bayer = false,
},
{
.code = MEDIA_BUS_FMT_ARGB_1X32,
.pixelformat = V4L2_PIX_FMT_ARGB32,
.bpp = 4,
+   .bayer = false,
},
 
/* Bayer formats */
@@ -45,41 +52,49 @@ static const struct vimc_pix_map vimc_pix_map_list[] = {
.code = MEDIA_BUS_FMT_SBGGR8_1X8,
.pixelformat = V4L2_PIX_FMT_SBGGR8,
.bpp = 1,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SGBRG8_1X8,
.pixelformat = V4L2_PIX_FMT_SGBRG8,
.bpp = 1,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SGRBG8_1X8,
.pixelformat = V4L2_PIX_FMT_SGRBG8,
.bpp = 1,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SRGGB8_1X8,
.pixelformat = V4L2_PIX_FMT_SRGGB8,
.bpp = 1,
+   .bayer = true,
},
{
.code = MEDIA_BUS_FMT_SBGGR10_1X10,
.pixelformat = V4L2_PIX_FMT_SBGGR10,
.bpp = 2,
+   .bayer = true,

[PATCH v5 12/12] [media] vimc: sen: Declare vimc_sen_video_ops as static

[Helen Koike]

Declare vimc_sen_video_ops as static, remove warning from sparse tool

Signed-off-by: Helen Koike 

---

Changes in v5:
[media] vimc: sen: Declare vimc_sen_video_ops as static
- This is a new patch in the series

Changes in v4: None
Changes in v3: None
Changes in v2: None


---
 drivers/media/platform/vimc/vimc-sensor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vimc/vimc-sensor.c 
b/drivers/media/platform/vimc/vimc-sensor.c
index 5ea7b08..ebdbbe8 100644
--- a/drivers/media/platform/vimc/vimc-sensor.c
+++ b/drivers/media/platform/vimc/vimc-sensor.c
@@ -282,7 +282,7 @@ static int vimc_sen_s_stream(struct v4l2_subdev *sd, int 
enable)
return 0;
 }
 
-struct v4l2_subdev_video_ops vimc_sen_video_ops = {
+static struct v4l2_subdev_video_ops vimc_sen_video_ops = {
.s_stream = vimc_sen_s_stream,
 };
 
-- 
2.7.4

[PATCH v5 03/12] [media] vimc: common: Add vimc_ent_sd_* helper

[Helen Koike]

As all the subdevices in the topology will be initialized in the same
way, to avoid code repetition the vimc_ent_sd_{register, unregister}
helper functions were created

Signed-off-by: Helen Koike 

---

Changes in v5: None
Changes in v4: None
Changes in v3:
[media] vimc: common: Add vimc_ent_sd_* helper
- add it in vimc-common.c instead in vimc-core.c
- fix vimc_ent_sd_register, use function parameter to assign
sd->entity.function instead of using a fixed value
- rename commit to add the "common" tag

Changes in v2:
[media] vimc: Add vimc_ent_sd_* helper functions
- Comments in vimc_ent_sd_init
- Update vimc_ent_sd_init with upstream code as media_entity_pads_init
(instead of media_entity_init), entity->function intead of entity->type
- Add missing vimc_pads_cleanup in vimc_ent_sd_cleanup
- remove subdevice v4l2_dev and dev fields
- change unregister order in vimc_ent_sd_cleanup
- rename vimc_ent_sd_{init,cleanup} to vimc_ent_sd_{register,unregister}
- remove struct vimc_ent_subdevice, use ved and sd directly
- don't impose struct vimc_sen_device to declare ved and sd struct first
- add kernel docs


---
 drivers/media/platform/vimc/vimc-common.c | 66 +++
 drivers/media/platform/vimc/vimc-common.h | 39 ++
 drivers/media/platform/vimc/vimc-sensor.c | 58 +--
 3 files changed, 114 insertions(+), 49 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 42f779a..3afbabd 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -219,3 +219,69 @@ struct media_pad *vimc_pads_init(u16 num_pads, const 
unsigned long *pads_flag)
 
return pads;
 }
+
+static const struct media_entity_operations vimc_ent_sd_mops = {
+   .link_validate = v4l2_subdev_link_validate,
+};
+
+int vimc_ent_sd_register(struct vimc_ent_device *ved,
+struct v4l2_subdev *sd,
+struct v4l2_device *v4l2_dev,
+const char *const name,
+u32 function,
+u16 num_pads,
+const unsigned long *pads_flag,
+const struct v4l2_subdev_ops *sd_ops,
+void (*sd_destroy)(struct vimc_ent_device *))
+{
+   int ret;
+
+   /* Allocate the pads */
+   ved->pads = vimc_pads_init(num_pads, pads_flag);
+   if (IS_ERR(ved->pads))
+   return PTR_ERR(ved->pads);
+
+   /* Fill the vimc_ent_device struct */
+   ved->destroy = sd_destroy;
+   ved->ent = >entity;
+
+   /* Initialize the subdev */
+   v4l2_subdev_init(sd, sd_ops);
+   sd->entity.function = function;
+   sd->entity.ops = _ent_sd_mops;
+   sd->owner = THIS_MODULE;
+   strlcpy(sd->name, name, sizeof(sd->name));
+   v4l2_set_subdevdata(sd, ved);
+
+   /* Expose this subdev to user space */
+   sd->flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+   /* Initialize the media entity */
+   ret = media_entity_pads_init(>entity, num_pads, ved->pads);
+   if (ret)
+   goto err_clean_pads;
+
+   /* Register the subdev with the v4l2 and the media framework */
+   ret = v4l2_device_register_subdev(v4l2_dev, sd);
+   if (ret) {
+   dev_err(v4l2_dev->dev,
+   "%s: subdev register failed (err=%d)\n",
+   name, ret);
+   goto err_clean_m_ent;
+   }
+
+   return 0;
+
+err_clean_m_ent:
+   media_entity_cleanup(>entity);
+err_clean_pads:
+   vimc_pads_cleanup(ved->pads);
+   return ret;
+}
+
+void vimc_ent_sd_unregister(struct vimc_ent_device *ved, struct v4l2_subdev 
*sd)
+{
+   v4l2_device_unregister_subdev(sd);
+   media_entity_cleanup(ved->ent);
+   vimc_pads_cleanup(ved->pads);
+}
diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 00d3da4..9ec361c 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -110,4 +110,43 @@ const struct vimc_pix_map *vimc_pix_map_by_code(u32 code);
  */
 const struct vimc_pix_map *vimc_pix_map_by_pixelformat(u32 pixelformat);
 
+/**
+ * vimc_ent_sd_register - initialize and register a subdev node
+ *
+ * @ved:   the vimc_ent_device struct to be initialize
+ * @sd:the v4l2_subdev struct to be initialize and registered
+ * @v4l2_dev:  the v4l2 device to register the v4l2_subdev
+ * @name:  name of the sub-device. Please notice that the name must be
+ * unique.
+ * @function:  media entity function defined by MEDIA_ENT_F_* macros
+ * @num_pads:  number of pads to initialize
+ * @pads_flag: flags to use in each pad
+ * @sd_ops:pointer to  v4l2_subdev_ops.

[PATCH v5 00/12] [media]: vimc: Virtual Media Control VPU's

[Helen Koike]

This patch series improves the current video processing units in vimc
(by adding more controls to the sensor and capture node, allowing the
user to configure different frame formats) and also adds a debayer
and a scaler node.
The debayer transforms the bayer format image received in its sink pad
to a bayer format by averaging the pixels within a mean window.
The scaler only scales up the image for now.

This patch series is based on media/master and it is available at:
https://github.com/helen-fornazier/opw-staging/tree/z/sent/vimc/vpu/v5

In this version the errors shown by the sparse tool are fixed

Changes in v5:
[media] vimc: Subdevices as modules
- Fix vimc_add_subdevs in rollback case. The loop variable can
be negative, remove 'unsigned' from the loop variable and fix
warning from smatch tool
[media] vimc: deb: Add debayer filter
- delare vimc_deb_video_ops as static, remove sparse warning
[media] vimc: sca: Add scaler
- declare vimc_sca_video_ops as static, remove sparse warning
[media] vimc: sen: Declare vimc_sen_video_ops as static
- This is a new patch in the series

Changes in v4:
[media] vimc: common: Add vimc_link_validate
- remove vimc_fmt_pix_to_mbus(), replaced by
v4l2_fill_mbus_format()
- remove EXPORT_SYMBOL(vimc_link_validate), not necessary in
this patch, moved to submodules patch
- Fix multi-line comment style
- If colorspace is set to DEFAULT, then assume all the other
colorimetry parameters are also DEFAULT
[media] vimc: common: Add vimc_colorimetry_clamp
- this is a new patch in the series
[media] vimc: sen: Support several image formats
- use vimc_colorimetry_clamp macro
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
[media] vimc: cap: Support several image formats
- add vimc_colorimetry_clamp macro
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
[media] vimc: Subdevices as modules
- Rebase without [media] vimc: Optimize frame generation the through
pipe
- s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL
- add struct vimc_platform_data to pass the entity's name to the
sudmodule
- Fix comment about vimc-input (remove vimc-output comment)
[media] vimc: deb: Add debayer filter
- Rebase without [media] vimc: Optimize frame generation through
pipe
- use vimc_colorimetry_clamp
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
- use struct vimc_platform_data to retrieve the entity's name
[media] vimc: sca: Add scaler
- use vimc_colorimetry_clamp
- replace V4L2_COLORSPACE_SRGB by V4L2_COLORSPACE_DEFAULT in the
default format struct
- use struct vimc_platform_data to retrieve the entity's name

Changes in v3:
[media] vimc: sen: Integrate the tpg on the sensor
- Declare frame_size as a local variable
- Set tpg frame format before starting kthread
- s_stream(sd, 1): return 0 if stream is already enabled
- s_stream(sd, 0): return 0 if stream is already disabled
- s_stream: propagate error from kthread_stop
- coding style when calling tpg_s_bytesperline
- s/vimc_thread_sen/vimc_sen_tpg_thread
- fix multiline comment
- remove V4L2_FIELD_ALTERNATE from tpg_s_field
- remove V4L2_STD_PAL from tpg_fill_plane_buffer
[media] vimc: Move common code from the core
- This is a new patch in the series
[media] vimc: common: Add vimc_ent_sd_* helper
- add it in vimc-common.c instead in vimc-core.c
- fix vimc_ent_sd_register, use function parameter to assign
sd->entity.function instead of using a fixed value
- rename commit to add the "common" tag
[media] vimc: Add vimc_pipeline_s_stream in the core
- add it in vimc-common instead of vimc-core
- rename commit with "common" tag
[media] vimc: common: Add vimc_link_validate
- this is a new patch in the series
[media] vimc: sen: Support several image formats
- remove support for V4L2_FIELD_ALTERNATE (left as TODO for now)
- clamp image size to an even dimension for height and width
- set default values for colorimetry using _DEFAULT macro
- reset all values of colorimetry to _DEFAULT if user tries to
set an invalid colorspace
[media] vimc: cap: Support several image formats
- use *_DEFAULT macros for colorimetry in the default format
- clamp height and width of the image by an even value
- is user try to set colorspace to an invalid format, set all
colorimetry parameters to _DEFAULT
- remove V4L2_FMT_FLAG_COMPRESSED from vimc_cap_enum_fmt_vid_cap
- remove V4L2_BUF_TYPE_VIDEO_CAPTURE from vimc_cap_enum_fmt_vid_cap
- increase step_width 

[PATCH v2 14/19] camss: vfe: Add interface for scaling

[Todor Tomov]

Add compose selection ioctls to handle scaling configuration.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/vfe.c | 189 ++-
 drivers/media/platform/qcom/camss-8x16/vfe.h |   1 +
 2 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/vfe.c 
b/drivers/media/platform/qcom/camss-8x16/vfe.c
index 433a54e..2d2bbcb 100644
--- a/drivers/media/platform/qcom/camss-8x16/vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/vfe.c
@@ -211,6 +211,8 @@
 #define CAMIF_TIMEOUT_SLEEP_US 1000
 #define CAMIF_TIMEOUT_ALL_US 100
 
+#define SCALER_RATIO_MAX 16
+
 static const u32 vfe_formats[] = {
MEDIA_BUS_FMT_UYVY8_2X8,
MEDIA_BUS_FMT_VYUY8_2X8,
@@ -1904,6 +1906,25 @@ static int vfe_set_stream(struct v4l2_subdev *sd, int 
enable)
return >fmt[pad];
 }
 
+/*
+ * __vfe_get_compose - Get pointer to compose selection structure
+ * @line: VFE line
+ * @cfg: V4L2 subdev pad configuration
+ * @which: TRY or ACTIVE format
+ *
+ * Return pointer to TRY or ACTIVE compose rectangle structure
+ */
+static struct v4l2_rect *
+__vfe_get_compose(struct vfe_line *line,
+ struct v4l2_subdev_pad_config *cfg,
+ enum v4l2_subdev_format_whence which)
+{
+   if (which == V4L2_SUBDEV_FORMAT_TRY)
+   return v4l2_subdev_get_try_compose(>subdev, cfg,
+  MSM_VFE_PAD_SINK);
+
+   return >compose;
+}
 
 /*
  * vfe_try_format - Handle try format by pad subdev method
@@ -1950,7 +1971,14 @@ static void vfe_try_format(struct vfe_line *line,
*fmt = *__vfe_get_format(line, cfg, MSM_VFE_PAD_SINK,
 which);
 
-   if (line->id == VFE_LINE_PIX)
+   if (line->id == VFE_LINE_PIX) {
+   struct v4l2_rect *rect;
+
+   rect = __vfe_get_compose(line, cfg, which);
+
+   fmt->width = rect->width;
+   fmt->height = rect->height;
+
switch (fmt->code) {
case MEDIA_BUS_FMT_YUYV8_2X8:
if (code == MEDIA_BUS_FMT_YUYV8_1_5X8)
@@ -1978,6 +2006,7 @@ static void vfe_try_format(struct vfe_line *line,
fmt->code = MEDIA_BUS_FMT_VYUY8_2X8;
break;
}
+   }
 
break;
}
@@ -1986,6 +2015,50 @@ static void vfe_try_format(struct vfe_line *line,
 }
 
 /*
+ * vfe_try_compose - Handle try compose selection by pad subdev method
+ * @line: VFE line
+ * @cfg: V4L2 subdev pad configuration
+ * @rect: pointer to v4l2 rect structure
+ * @which: wanted subdev format
+ */
+static void vfe_try_compose(struct vfe_line *line,
+   struct v4l2_subdev_pad_config *cfg,
+   struct v4l2_rect *rect,
+   enum v4l2_subdev_format_whence which)
+{
+   struct v4l2_mbus_framefmt *fmt;
+
+   rect->width = rect->width - rect->left;
+   rect->left = 0;
+   rect->height = rect->height - rect->top;
+   rect->top = 0;
+
+   fmt = __vfe_get_format(line, cfg, MSM_VFE_PAD_SINK, which);
+
+   if (rect->width > fmt->width)
+   rect->width = fmt->width;
+
+   if (rect->height > fmt->height)
+   rect->height = fmt->height;
+
+   if (fmt->width > rect->width * SCALER_RATIO_MAX)
+   rect->width = (fmt->width + SCALER_RATIO_MAX - 1) /
+   SCALER_RATIO_MAX;
+
+   rect->width &= ~0x1;
+
+   if (fmt->height > rect->height * SCALER_RATIO_MAX)
+   rect->height = (fmt->height + SCALER_RATIO_MAX - 1) /
+   SCALER_RATIO_MAX;
+
+   if (rect->width < 16)
+   rect->width = 16;
+
+   if (rect->height < 4)
+   rect->height = 4;
+}
+
+/*
  * vfe_enum_mbus_code - Handle pixel format enumeration
  * @sd: VFE V4L2 subdevice
  * @cfg: V4L2 subdev pad configuration
@@ -2080,6 +2153,10 @@ static int vfe_get_format(struct v4l2_subdev *sd,
return 0;
 }
 
+static int vfe_set_selection(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_selection *sel);
+
 /*
  * vfe_set_format - Handle set format by pads subdev method
  * @sd: VFE V4L2 subdevice
@@ -2102,20 +2179,126 @@ static int vfe_set_format(struct v4l2_subdev *sd,
vfe_try_format(line, cfg, fmt->pad, >format, fmt->which);
*format = fmt->format;
 
-   /* Propagate the format from sink to source */
if (fmt->pad == MSM_VFE_PAD_SINK) {
+   struct v4l2_subdev_selection sel = { 0 };
+   int ret;
+
+   /* Propagate the format from sink to source */
  

[PATCH v2 10/19] media: camss: Enable building

[Todor Tomov]

Add Makefile and update platform/Kconfig and platform/Makefile
to enable building of the QCom CAMSS driver.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/Kconfig  |  6 ++
 drivers/media/platform/Makefile |  2 ++
 drivers/media/platform/qcom/camss-8x16/Makefile | 11 +++
 3 files changed, 19 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/Makefile

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 041cb80..cf69c41 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -100,6 +100,12 @@ config VIDEO_PXA27x
---help---
  This is a v4l2 driver for the PXA27x Quick Capture Interface
 
+config VIDEO_QCOM_CAMSS
+   tristate "Qualcomm 8x16 V4L2 Camera Subsystem driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
+   select VIDEOBUF2_DMA_SG
+
 config VIDEO_S3C_CAMIF
tristate "Samsung S3C24XX/S3C64XX SoC Camera Interface driver"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d6..f083b8a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -77,3 +77,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)   += mtk-vcodec/
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
+
+obj-$(CONFIG_VIDEO_QCOM_CAMSS) += qcom/camss-8x16/
diff --git a/drivers/media/platform/qcom/camss-8x16/Makefile 
b/drivers/media/platform/qcom/camss-8x16/Makefile
new file mode 100644
index 000..4a6b08f
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/Makefile
@@ -0,0 +1,11 @@
+# Makefile for Qualcomm CAMSS driver
+
+qcom-camss-objs += \
+   camss.o \
+   csid.o \
+   csiphy.o \
+   ispif.o \
+   vfe.o \
+   video.o \
+
+obj-$(CONFIG_VIDEO_QCOM_CAMSS) += qcom-camss.o
-- 
1.9.1

[PATCH v2 12/19] doc: media/v4l-drivers: Qualcomm Camera Subsystem - PIX Interface

[Todor Tomov]

Update Qualcomm Camera Subsystem driver document for the PIX interface
and format conversion support.

Signed-off-by: Todor Tomov 
---
 Documentation/media/v4l-drivers/qcom_camss.rst | 41 +++---
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/Documentation/media/v4l-drivers/qcom_camss.rst 
b/Documentation/media/v4l-drivers/qcom_camss.rst
index 4707ea7..4df5655 100644
--- a/Documentation/media/v4l-drivers/qcom_camss.rst
+++ b/Documentation/media/v4l-drivers/qcom_camss.rst
@@ -45,12 +45,31 @@ Supported functionality
 
 The current version of the driver supports:
 
-- input from camera sensor via CSIPHY;
-- generation of test input data by the TG in CSID;
-- raw dump of the input data to memory. RDI interface of VFE is supported.
-  PIX interface (ISP processing, statistics engines, resize/crop, format
-  conversion) is not supported in the current version;
-- concurrent and independent usage of two data inputs - could be camera sensors
+- Input from camera sensor via CSIPHY;
+- Generation of test input data by the TG in CSID;
+- RDI interface of VFE - raw dump of the input data to memory.
+
+  Supported formats:
+
+  - YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2);
+  - MIPI RAW8 (8bit Bayer RAW);
+  - MIPI RAW10 (10bit packed Bayer RAW);
+  - MIPI RAW12 (12bit packed Bayer RAW).
+
+- PIX interface of VFE
+
+  - Format conversion of the input data.
+
+Supported input formats:
+
+- YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2).
+
+Supported output formats:
+
+- NV12/NV21 (two plane YUV 4:2:0);
+- NV16/NV61 (two plane YUV 4:2:2).
+
+- Concurrent and independent usage of two data inputs - could be camera sensors
   and/or TG.
 
 
@@ -65,15 +84,15 @@ interface, the driver is split into V4L2 sub-devices as 
follows:
 - 2 CSID sub-devices - each CSID is represented by a single sub-device;
 - 2 ISPIF sub-devices - ISPIF is represented by a number of sub-devices equal
   to the number of CSID sub-devices;
-- 3 VFE sub-devices - VFE is represented by a number of sub-devices equal to
-  the number of RDI input interfaces.
+- 4 VFE sub-devices - VFE is represented by a number of sub-devices equal to
+  the number of the input interfaces (3 RDI and 1 PIX).
 
 The considerations to split the driver in this particular way are as follows:
 
 - representing CSIPHY and CSID modules by a separate sub-device for each module
   allows to model the hardware links between these modules;
-- representing VFE by a separate sub-devices for each RDI input interface 
allows
-  to use the three RDI interfaces concurently and independently as this is
+- representing VFE by a separate sub-devices for each input interface allows
+  to use the input interfaces concurently and independently as this is
   supported by the hardware;
 - representing ISPIF by a number of sub-devices equal to the number of CSID
   sub-devices allows to create linear media controller pipelines when using two
@@ -99,6 +118,8 @@ nodes) is as follows:
 - msm_vfe0_video1
 - msm_vfe0_rdi2
 - msm_vfe0_video2
+- msm_vfe0_pix
+- msm_vfe0_video3
 
 
 Implementation
-- 
1.9.1

[PATCH v2 08/19] media: camss: Add files which handle the video device nodes

[Todor Tomov]

These files handle the video device nodes of the camss driver.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/video.c | 629 +
 drivers/media/platform/qcom/camss-8x16/video.h |  64 +++
 2 files changed, 693 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/video.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/video.h

diff --git a/drivers/media/platform/qcom/camss-8x16/video.c 
b/drivers/media/platform/qcom/camss-8x16/video.c
new file mode 100644
index 000..07175d3
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/video.c
@@ -0,0 +1,629 @@
+/*
+ * video.c
+ *
+ * Qualcomm MSM Camera Subsystem - V4L2 device node
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+
+#include "video.h"
+#include "camss.h"
+
+/*
+ * struct format_info - ISP media bus format information
+ * @code: V4L2 media bus format code
+ * @pixelformat: V4L2 pixel format FCC identifier
+ * @bpp: Bits per pixel when stored in memory
+ */
+static const struct format_info {
+   u32 code;
+   u32 pixelformat;
+   unsigned int bpp;
+} formats[] = {
+   { MEDIA_BUS_FMT_UYVY8_2X8, V4L2_PIX_FMT_UYVY, 16 },
+   { MEDIA_BUS_FMT_VYUY8_2X8, V4L2_PIX_FMT_VYUY, 16 },
+   { MEDIA_BUS_FMT_YUYV8_2X8, V4L2_PIX_FMT_YUYV, 16 },
+   { MEDIA_BUS_FMT_YVYU8_2X8, V4L2_PIX_FMT_YVYU, 16 },
+   { MEDIA_BUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8 },
+   { MEDIA_BUS_FMT_SGBRG8_1X8, V4L2_PIX_FMT_SGBRG8, 8 },
+   { MEDIA_BUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8 },
+   { MEDIA_BUS_FMT_SRGGB8_1X8, V4L2_PIX_FMT_SRGGB8, 8 },
+   { MEDIA_BUS_FMT_SBGGR10_1X10, V4L2_PIX_FMT_SBGGR10P, 10 },
+   { MEDIA_BUS_FMT_SGBRG10_1X10, V4L2_PIX_FMT_SGBRG10P, 10 },
+   { MEDIA_BUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10P, 10 },
+   { MEDIA_BUS_FMT_SRGGB10_1X10, V4L2_PIX_FMT_SRGGB10P, 10 },
+   { MEDIA_BUS_FMT_SBGGR12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 },
+   { MEDIA_BUS_FMT_SGBRG12_1X12, V4L2_PIX_FMT_SGBRG12P, 12 },
+   { MEDIA_BUS_FMT_SGRBG12_1X12, V4L2_PIX_FMT_SGRBG12P, 12 },
+   { MEDIA_BUS_FMT_SRGGB12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 }
+};
+
+/* 
-
+ * Helper functions
+ */
+
+/*
+ * video_mbus_to_pix_mp - Convert v4l2_mbus_framefmt to v4l2_pix_format_mplane
+ * @mbus: v4l2_mbus_framefmt format (input)
+ * @pix: v4l2_pix_format_mplane format (output)
+ *
+ * Fill the output pix structure with information from the input mbus format.
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static unsigned int video_mbus_to_pix_mp(const struct v4l2_mbus_framefmt *mbus,
+struct v4l2_pix_format_mplane *pix)
+{
+   unsigned int i;
+   u32 bytesperline;
+
+   memset(pix, 0, sizeof(*pix));
+   pix->width = mbus->width;
+   pix->height = mbus->height;
+
+   for (i = 0; i < ARRAY_SIZE(formats); ++i) {
+   if (formats[i].code == mbus->code)
+   break;
+   }
+
+   if (WARN_ON(i == ARRAY_SIZE(formats)))
+   return -EINVAL;
+
+   pix->pixelformat = formats[i].pixelformat;
+   pix->num_planes = 1;
+   bytesperline = pix->width * formats[i].bpp / 8;
+   bytesperline = ALIGN(bytesperline, 8);
+   pix->plane_fmt[0].bytesperline = bytesperline;
+   pix->plane_fmt[0].sizeimage = bytesperline * pix->height;
+   pix->colorspace = mbus->colorspace;
+   pix->field = mbus->field;
+
+   return 0;
+}
+
+static struct v4l2_subdev *video_remote_subdev(struct camss_video *video,
+  u32 *pad)
+{
+   struct media_pad *remote;
+
+   remote = media_entity_remote_pad(>pad);
+
+   if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
+   return NULL;
+
+   if (pad)
+   *pad = remote->index;
+
+   return media_entity_to_v4l2_subdev(remote->entity);
+}
+
+static int video_get_subdev_format(struct camss_video *video,
+  struct v4l2_format *format)
+{
+   struct v4l2_subdev_format fmt;
+   struct v4l2_subdev *subdev;
+   u32 pad;
+   int ret;
+
+   subdev = video_remote_subdev(video, );
+   if (subdev == NULL)
+   return 

[PATCH v2 04/19] media: camss: Add CSIPHY files

[Todor Tomov]

These files control the CSIPHY modules which are responsible for the physical
layer of the CSI2 receivers.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/csiphy.c | 686 
 drivers/media/platform/qcom/camss-8x16/csiphy.h |  77 +++
 2 files changed, 763 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/csiphy.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/csiphy.h

diff --git a/drivers/media/platform/qcom/camss-8x16/csiphy.c 
b/drivers/media/platform/qcom/camss-8x16/csiphy.c
new file mode 100644
index 000..b9d47ca
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/csiphy.c
@@ -0,0 +1,686 @@
+/*
+ * csiphy.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSIPHY Module
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+#include 
+
+#include "csiphy.h"
+#include "camss.h"
+
+#define MSM_CSIPHY_NAME "msm_csiphy"
+
+#define CAMSS_CSI_PHY_LNn_CFG2(n)  (0x004 + 0x40 * (n))
+#define CAMSS_CSI_PHY_LNn_CFG3(n)  (0x008 + 0x40 * (n))
+#define CAMSS_CSI_PHY_GLBL_RESET   0x140
+#define CAMSS_CSI_PHY_GLBL_PWR_CFG 0x144
+#define CAMSS_CSI_PHY_GLBL_IRQ_CMD 0x164
+#define CAMSS_CSI_PHY_HW_VERSION   0x188
+#define CAMSS_CSI_PHY_INTERRUPT_STATUSn(n) (0x18c + 0x4 * (n))
+#define CAMSS_CSI_PHY_INTERRUPT_MASKn(n)   (0x1ac + 0x4 * (n))
+#define CAMSS_CSI_PHY_INTERRUPT_CLEARn(n)  (0x1cc + 0x4 * (n))
+#define CAMSS_CSI_PHY_GLBL_T_INIT_CFG0 0x1ec
+#define CAMSS_CSI_PHY_T_WAKEUP_CFG00x1f4
+
+static const u32 csiphy_formats[] = {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SGBRG10_1X10,
+   MEDIA_BUS_FMT_SGRBG10_1X10,
+   MEDIA_BUS_FMT_SRGGB10_1X10,
+   MEDIA_BUS_FMT_SBGGR12_1X12,
+   MEDIA_BUS_FMT_SGBRG12_1X12,
+   MEDIA_BUS_FMT_SGRBG12_1X12,
+   MEDIA_BUS_FMT_SRGGB12_1X12,
+};
+
+/*
+ * csiphy_isr - CSIPHY module interrupt handler
+ * @irq: Interrupt line
+ * @dev: CSIPHY device
+ *
+ * Return IRQ_HANDLED on success
+ */
+static irqreturn_t csiphy_isr(int irq, void *dev)
+{
+   struct csiphy_device *csiphy = dev;
+   u8 i;
+
+   for (i = 0; i < 8; i++) {
+   u8 val = readl_relaxed(csiphy->base +
+  CAMSS_CSI_PHY_INTERRUPT_STATUSn(i));
+   writel_relaxed(val, csiphy->base +
+  CAMSS_CSI_PHY_INTERRUPT_CLEARn(i));
+   writel_relaxed(0x1, csiphy->base + CAMSS_CSI_PHY_GLBL_IRQ_CMD);
+   writel_relaxed(0x0, csiphy->base + CAMSS_CSI_PHY_GLBL_IRQ_CMD);
+   writel_relaxed(0x0, csiphy->base +
+  CAMSS_CSI_PHY_INTERRUPT_CLEARn(i));
+   }
+
+   return IRQ_HANDLED;
+}
+
+/*
+ * csiphy_reset - Perform software reset on CSIPHY module
+ * @csiphy: CSIPHY device
+ */
+static void csiphy_reset(struct csiphy_device *csiphy)
+{
+   writel_relaxed(0x1, csiphy->base + CAMSS_CSI_PHY_GLBL_RESET);
+   usleep_range(5000, 8000);
+   writel_relaxed(0x0, csiphy->base + CAMSS_CSI_PHY_GLBL_RESET);
+}
+
+/*
+ * csiphy_set_power - Power on/off CSIPHY module
+ * @sd: CSIPHY V4L2 subdevice
+ * @on: Requested power state
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int csiphy_set_power(struct v4l2_subdev *sd, int on)
+{
+   struct csiphy_device *csiphy = v4l2_get_subdevdata(sd);
+   struct device *dev = to_device_index(csiphy, csiphy->id);
+   int ret;
+
+   if (on) {
+   u8 hw_version;
+
+   ret = camss_enable_clocks(csiphy->nclocks, csiphy->clock, dev);
+   if (ret < 0)
+   return ret;
+
+   enable_irq(csiphy->irq);
+
+   csiphy_reset(csiphy);
+
+   hw_version = readl_relaxed(csiphy->base +
+  CAMSS_CSI_PHY_HW_VERSION);
+   dev_dbg(dev, "CSIPHY HW Version = 0x%02x\n", hw_version);
+   } else {
+   disable_irq(csiphy->irq);
+
+   

[PATCH v2 00/19] Qualcomm 8x16 Camera Subsystem driver

[Todor Tomov]

This patchset adds basic support for the Qualcomm Camera Subsystem found
on Qualcomm MSM8916 and APQ8016 processors.

The driver implements V4L2, Media controller and V4L2 subdev interfaces.
Camera sensor using V4L2 subdev interface in the kernel is supported.

The driver is implemented using as a reference the Qualcomm Camera
Subsystem driver for Android as found in Code Aurora [1].

The driver is tested on Dragonboard 410C (APQ8016) with one and two
OV5645 camera sensors. media-ctl [2] and yavta [3] applications were
used for testing. Also Gstreamer 1.10.4 with v4l2src plugin is supported.

More information is present in the document added by the third patch.

---

Patchset Changelog:

Version 2:
- patches 01-10 are updated from v1 following the review received and bugs
  and limitaitons found after v1 was posted. The updates include:
  - return buffers on unsuccessful stream on;
  - fill device capabilities in struct video_device;
  - simplify v4l2 file handle usage - no custom struct for file handle;
  - use vb2_fop_poll and vb2_fop_mmap v4l2 file operations;
  - add support for read/write I/O;
  - add support for DMABUF streaming I/O;
  - add support for EXPBUF and PREPARE_BUF ioctl;
  - avoid a race condition between device unbind and userspace access
to the video node;
  - use non-contiguous memory for video buffers;
  - switch to V4L2 multi-planar API;
  - add useful error messages in case of an overflow in ISPIF;
  - other small and style fixes.

- patches 11-19 are new (they were not ready/posted with v1). I'm including
  these in this patchset as they add valuable features and may be desired
  for a real world usage of the driver.

---

The patchset depends on:
v4l: Add packed Bayer raw12 pixel formats [4]

---

V4L2 compliance test result:

$ v4l2-compliance -s -d /dev/video0 
v4l2-compliance SHA   : ce237eefc1f6dafafc0e1fe3a5fd9f075d3fd066

Driver Info:
Driver name   : qcom-camss
Card type : Qualcomm Camera Subsystem
Bus info  : platform:1b0ac00.camss
Driver version: 4.9.27
Capabilities  : 0x85201000
Video Capture Multiplanar
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x05201000
Video Capture Multiplanar
Read/Write
Streaming
Extended Pix Format

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

Required ioctls:
test VIDIOC_QUERYCAP: OK

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

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

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

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

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

Test input 0:

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

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

[PATCH v2 06/19] media: camss: Add ISPIF files

[Todor Tomov]

These files control the ISPIF module which handles the routing of the data
streams from the CSIDs to the inputs of the VFE.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/ispif.c | 1126 
 drivers/media/platform/qcom/camss-8x16/ispif.h |   85 ++
 2 files changed, 1211 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/ispif.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/ispif.h

diff --git a/drivers/media/platform/qcom/camss-8x16/ispif.c 
b/drivers/media/platform/qcom/camss-8x16/ispif.c
new file mode 100644
index 000..c72d06c
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/ispif.c
@@ -0,0 +1,1126 @@
+/*
+ * ispif.c
+ *
+ * Qualcomm MSM Camera Subsystem - ISPIF Module
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+#include 
+#include 
+
+#include "ispif.h"
+#include "camss.h"
+
+#define MSM_ISPIF_NAME "msm_ispif"
+
+#define ispif_line_array(ptr_line) \
+   ((const struct ispif_line (*)[]) &(ptr_line[-(ptr_line->id)]))
+
+#define to_ispif(ptr_line) \
+   container_of(ispif_line_array(ptr_line), struct ispif_device, ptr_line)
+
+#define ISPIF_RST_CMD_00x008
+#define ISPIF_IRQ_GLOBAL_CLEAR_CMD 0x01c
+#define ISPIF_VFE_m_CTRL_0(m)  (0x200 + 0x200 * (m))
+#define ISPIF_VFE_m_CTRL_0_PIX0_LINE_BUF_EN(1 << 6)
+#define ISPIF_VFE_m_IRQ_MASK_0(m)  (0x208 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_MASK_0_PIX0_ENABLE 0x1249
+#define ISPIF_VFE_m_IRQ_MASK_0_PIX0_MASK   0x1fff
+#define ISPIF_VFE_m_IRQ_MASK_0_RDI0_ENABLE 0x02492000
+#define ISPIF_VFE_m_IRQ_MASK_0_RDI0_MASK   0x03ffe000
+#define ISPIF_VFE_m_IRQ_MASK_1(m)  (0x20c + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_MASK_1_PIX1_ENABLE 0x1249
+#define ISPIF_VFE_m_IRQ_MASK_1_PIX1_MASK   0x1fff
+#define ISPIF_VFE_m_IRQ_MASK_1_RDI1_ENABLE 0x02492000
+#define ISPIF_VFE_m_IRQ_MASK_1_RDI1_MASK   0x03ffe000
+#define ISPIF_VFE_m_IRQ_MASK_2(m)  (0x210 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_MASK_2_RDI2_ENABLE 0x1249
+#define ISPIF_VFE_m_IRQ_MASK_2_RDI2_MASK   0x1fff
+#define ISPIF_VFE_m_IRQ_STATUS_0(m)(0x21c + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW (1 << 12)
+#define ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW (1 << 25)
+#define ISPIF_VFE_m_IRQ_STATUS_1(m)(0x220 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW (1 << 12)
+#define ISPIF_VFE_m_IRQ_STATUS_1_RDI1_OVERFLOW (1 << 25)
+#define ISPIF_VFE_m_IRQ_STATUS_2(m)(0x224 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_STATUS_2_RDI2_OVERFLOW (1 << 12)
+#define ISPIF_VFE_m_IRQ_CLEAR_0(m) (0x230 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_CLEAR_1(m) (0x234 + 0x200 * (m))
+#define ISPIF_VFE_m_IRQ_CLEAR_2(m) (0x238 + 0x200 * (m))
+#define ISPIF_VFE_m_INTF_INPUT_SEL(m)  (0x244 + 0x200 * (m))
+#define ISPIF_VFE_m_INTF_CMD_0(m)  (0x248 + 0x200 * (m))
+#define ISPIF_VFE_m_INTF_CMD_1(m)  (0x24c + 0x200 * (m))
+#define ISPIF_VFE_m_PIX_INTF_n_CID_MASK(m, n)  \
+   (0x254 + 0x200 * (m) + 0x4 * (n))
+#define ISPIF_VFE_m_RDI_INTF_n_CID_MASK(m, n)  \
+   (0x264 + 0x200 * (m) + 0x4 * (n))
+#define ISPIF_VFE_m_PIX_INTF_n_STATUS(m, n)\
+   (0x2c0 + 0x200 * (m) + 0x4 * (n))
+#define ISPIF_VFE_m_RDI_INTF_n_STATUS(m, n)\
+   (0x2d0 + 0x200 * (m) + 0x4 * (n))
+
+#define CSI_PIX_CLK_MUX_SEL0x000
+#define CSI_RDI_CLK_MUX_SEL0x008
+
+#define ISPIF_TIMEOUT_SLEEP_US 1000
+#define ISPIF_TIMEOUT_ALL_US   100
+#define ISPIF_RESET_TIMEOUT_MS 500
+
+enum ispif_intf_cmd {
+   CMD_DISABLE_FRAME_BOUNDARY = 0x0,
+   CMD_ENABLE_FRAME_BOUNDARY = 0x1,
+   CMD_DISABLE_IMMEDIATELY = 0x2,
+   CMD_ALL_DISABLE_IMMEDIATELY = 0x,
+   CMD_ALL_NO_CHANGE = 0x,
+};
+
+static const u32 ispif_formats[] = {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   

[PATCH v2 18/19] doc: media/v4l-drivers: Qualcomm Camera Subsystem - Scale and crop

[Todor Tomov]

Update the Qualcomm Camera Subsystem driver document for VFE scale
and crop modules support.

Signed-off-by: Todor Tomov 
---
 Documentation/media/v4l-drivers/qcom_camss.rst | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/v4l-drivers/qcom_camss.rst 
b/Documentation/media/v4l-drivers/qcom_camss.rst
index 4df5655..7e4ab6e 100644
--- a/Documentation/media/v4l-drivers/qcom_camss.rst
+++ b/Documentation/media/v4l-drivers/qcom_camss.rst
@@ -35,7 +35,8 @@ driver consists of:
   the CSIDs to the inputs of the VFE;
 - VFE (Video Front End) module. Contains a pipeline of image processing 
hardware
   blocks. The VFE has different input interfaces. The PIX input interface feeds
-  the input data to the image processing pipeline. Three RDI input interfaces
+  the input data to the image processing pipeline. The image processing 
pipeline
+  contains also a scale and crop module at the end. Three RDI input interfaces
   bypass the image processing pipeline. The VFE also contains the AXI bus
   interface which writes the output data to memory.
 
@@ -69,6 +70,11 @@ The current version of the driver supports:
 - NV12/NV21 (two plane YUV 4:2:0);
 - NV16/NV61 (two plane YUV 4:2:2).
 
+  - Scaling support. Configuration of the VFE Encoder Scale module
+for downscalling with ratio up to 16x.
+
+  - Cropping support. Configuration of the VFE Encoder Crop module.
+
 - Concurrent and independent usage of two data inputs - could be camera sensors
   and/or TG.
 
@@ -130,6 +136,12 @@ not required to implement the currently supported 
functionality. The complete
 configuration on each hardware module is applied on STREAMON ioctl based on
 the current active media links, formats and controls set.
 
+The output size of the scaler module in the VFE is configured with the actual
+compose selection rectangle on the sink pad of the 'msm_vfe0_pix' entity.
+
+The crop output area of the crop module in the VFE is configured with the 
actual
+crop selection rectangle on the source pad of the 'msm_vfe0_pix' entity.
+
 
 Documentation
 -
-- 
1.9.1

[PATCH v2 03/19] doc: media/v4l-drivers: Add Qualcomm Camera Subsystem driver document

[Todor Tomov]

Add a document to describe Qualcomm Camera Subsystem driver.

Signed-off-by: Todor Tomov 
---
 Documentation/media/v4l-drivers/qcom_camss.rst | 124 +
 1 file changed, 124 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/qcom_camss.rst

diff --git a/Documentation/media/v4l-drivers/qcom_camss.rst 
b/Documentation/media/v4l-drivers/qcom_camss.rst
new file mode 100644
index 000..4707ea7
--- /dev/null
+++ b/Documentation/media/v4l-drivers/qcom_camss.rst
@@ -0,0 +1,124 @@
+.. include:: 
+
+Qualcomm Camera Subsystem driver
+
+
+Introduction
+
+
+This file documents the Qualcomm Camera Subsystem driver located under
+drivers/media/platform/qcom/camss-8x16.
+
+The current version of the driver supports the Camera Subsystem found on
+Qualcomm MSM8916 and APQ8016 processors.
+
+The driver implements V4L2, Media controller and V4L2 subdev interfaces.
+Camera sensor using V4L2 subdev interface in the kernel is supported.
+
+The driver is implemented using as a reference the Qualcomm Camera Subsystem
+driver for Android as found in Code Aurora [#f1]_.
+
+
+Qualcomm Camera Subsystem hardware
+--
+
+The Camera Subsystem hardware found on 8x16 processors and supported by the
+driver consists of:
+
+- 2 CSIPHY modules. They handle the Physical layer of the CSI2 receivers.
+  A separate camera sensor can be connected to each of the CSIPHY module;
+- 2 CSID (CSI Decoder) modules. They handle the Protocol and Application layer
+  of the CSI2 receivers. A CSID can decode data stream from any of the CSIPHY.
+  Each CSID also contains a TG (Test Generator) block which can generate
+  artificial input data for test purposes;
+- ISPIF (ISP Interface) module. Handles the routing of the data streams from
+  the CSIDs to the inputs of the VFE;
+- VFE (Video Front End) module. Contains a pipeline of image processing 
hardware
+  blocks. The VFE has different input interfaces. The PIX input interface feeds
+  the input data to the image processing pipeline. Three RDI input interfaces
+  bypass the image processing pipeline. The VFE also contains the AXI bus
+  interface which writes the output data to memory.
+
+
+Supported functionality
+---
+
+The current version of the driver supports:
+
+- input from camera sensor via CSIPHY;
+- generation of test input data by the TG in CSID;
+- raw dump of the input data to memory. RDI interface of VFE is supported.
+  PIX interface (ISP processing, statistics engines, resize/crop, format
+  conversion) is not supported in the current version;
+- concurrent and independent usage of two data inputs - could be camera sensors
+  and/or TG.
+
+
+Driver Architecture and Design
+--
+
+The driver implements the V4L2 subdev interface. With the goal to model the
+hardware links between the modules and to expose a clean, logical and usable
+interface, the driver is split into V4L2 sub-devices as follows:
+
+- 2 CSIPHY sub-devices - each CSIPHY is represented by a single sub-device;
+- 2 CSID sub-devices - each CSID is represented by a single sub-device;
+- 2 ISPIF sub-devices - ISPIF is represented by a number of sub-devices equal
+  to the number of CSID sub-devices;
+- 3 VFE sub-devices - VFE is represented by a number of sub-devices equal to
+  the number of RDI input interfaces.
+
+The considerations to split the driver in this particular way are as follows:
+
+- representing CSIPHY and CSID modules by a separate sub-device for each module
+  allows to model the hardware links between these modules;
+- representing VFE by a separate sub-devices for each RDI input interface 
allows
+  to use the three RDI interfaces concurently and independently as this is
+  supported by the hardware;
+- representing ISPIF by a number of sub-devices equal to the number of CSID
+  sub-devices allows to create linear media controller pipelines when using two
+  cameras simultaneously. This avoids branches in the pipelines which otherwise
+  will require a) userspace and b) media framework (e.g. power on/off
+  operations) to  make assumptions about the data flow from a sink pad to a
+  source pad on a single media entity.
+
+Each VFE sub-device is linked to a separate video device node.
+
+The complete list of the media entities (V4L2 sub-devices and video device
+nodes) is as follows:
+
+- msm_csiphy0
+- msm_csiphy1
+- msm_csid0
+- msm_csid1
+- msm_ispif0
+- msm_ispif1
+- msm_vfe0_rdi0
+- msm_vfe0_video0
+- msm_vfe0_rdi1
+- msm_vfe0_video1
+- msm_vfe0_rdi2
+- msm_vfe0_video2
+
+
+Implementation
+--
+
+Runtime configuration of the hardware (updating settings while streaming) is
+not required to implement the currently supported functionality. The complete
+configuration on each hardware module is applied on STREAMON ioctl based on
+the current active media links, formats and controls set.
+
+
+Documentation

[PATCH v2 17/19] camss: vfe: Configure crop module in VFE

[Todor Tomov]

Add crop module configuration support to be able to apply cropping.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/vfe.c | 41 +++-
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/vfe.c 
b/drivers/media/platform/qcom/camss-8x16/vfe.c
index b97aefa..0241faa 100644
--- a/drivers/media/platform/qcom/camss-8x16/vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/vfe.c
@@ -57,6 +57,7 @@
 #define VFE_0_MODULE_CFG_DEMUX (1 << 2)
 #define VFE_0_MODULE_CFG_CHROMA_UPSAMPLE   (1 << 3)
 #define VFE_0_MODULE_CFG_SCALE_ENC (1 << 23)
+#define VFE_0_MODULE_CFG_CROP_ENC  (1 << 27)
 
 #define VFE_0_CORE_CFG 0x01c
 #define VFE_0_CORE_CFG_PIXEL_PATTERN_YCBYCR0x4
@@ -194,6 +195,11 @@
 #define VFE_0_SCALE_ENC_CBCR_V_IMAGE_SIZE  0x790
 #define VFE_0_SCALE_ENC_CBCR_V_PHASE   0x794
 
+#define VFE_0_CROP_ENC_Y_WIDTH 0x854
+#define VFE_0_CROP_ENC_Y_HEIGHT0x858
+#define VFE_0_CROP_ENC_CBCR_WIDTH  0x85c
+#define VFE_0_CROP_ENC_CBCR_HEIGHT 0x860
+
 #define VFE_0_CLAMP_ENC_MAX_CFG0x874
 #define VFE_0_CLAMP_ENC_MIN_CFG0x878
 
@@ -716,6 +722,37 @@ static void vfe_set_scale_cfg(struct vfe_device *vfe, 
struct vfe_line *line)
writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_CBCR_V_PHASE);
 }
 
+static void vfe_set_crop_cfg(struct vfe_device *vfe, struct vfe_line *line)
+{
+   u32 p = line->video_out.active_fmt.fmt.pix_mp.pixelformat;
+   u32 reg;
+   u16 first, last;
+
+   first = line->crop.left;
+   last = line->crop.left + line->crop.width - 1;
+   reg = (first << 16) | last;
+   writel_relaxed(reg, vfe->base + VFE_0_CROP_ENC_Y_WIDTH);
+
+   first = line->crop.top;
+   last = line->crop.top + line->crop.height - 1;
+   reg = (first << 16) | last;
+   writel_relaxed(reg, vfe->base + VFE_0_CROP_ENC_Y_HEIGHT);
+
+   first = line->crop.left / 2;
+   last = line->crop.left / 2 + line->crop.width / 2 - 1;
+   reg = (first << 16) | last;
+   writel_relaxed(reg, vfe->base + VFE_0_CROP_ENC_CBCR_WIDTH);
+
+   first = line->crop.top;
+   last = line->crop.top + line->crop.height - 1;
+   if (p == V4L2_PIX_FMT_NV12 || p == V4L2_PIX_FMT_NV21) {
+   first = line->crop.top / 2;
+   last = line->crop.top / 2 + line->crop.height / 2 - 1;
+   }
+   reg = (first << 16) | last;
+   writel_relaxed(reg, vfe->base + VFE_0_CROP_ENC_CBCR_HEIGHT);
+}
+
 static void vfe_set_clamp_cfg(struct vfe_device *vfe)
 {
writel_relaxed(0x00ff, vfe->base + VFE_0_CLAMP_ENC_MAX_CFG);
@@ -828,7 +865,8 @@ static void vfe_set_module_cfg(struct vfe_device *vfe, u8 
enable)
 {
u32 val = VFE_0_MODULE_CFG_DEMUX |
  VFE_0_MODULE_CFG_CHROMA_UPSAMPLE |
- VFE_0_MODULE_CFG_SCALE_ENC;
+ VFE_0_MODULE_CFG_SCALE_ENC |
+ VFE_0_MODULE_CFG_CROP_ENC;
 
if (enable)
writel_relaxed(val, vfe->base + VFE_0_MODULE_CFG);
@@ -1303,6 +1341,7 @@ static int vfe_enable_output(struct vfe_line *line)
vfe_set_xbar_cfg(vfe, output, 1);
vfe_set_demux_cfg(vfe, line);
vfe_set_scale_cfg(vfe, line);
+   vfe_set_crop_cfg(vfe, line);
vfe_set_clamp_cfg(vfe);
vfe_set_camif_cmd(vfe, VFE_0_CAMIF_CMD_ENABLE_FRAME_BOUNDARY);
}
-- 
1.9.1

[PATCH v2 09/19] media: camms: Add core files

[Todor Tomov]

These files implement the platform driver code.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/camss.c | 630 +
 drivers/media/platform/qcom/camss-8x16/camss.h |  96 
 2 files changed, 726 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/camss.h

diff --git a/drivers/media/platform/qcom/camss-8x16/camss.c 
b/drivers/media/platform/qcom/camss-8x16/camss.c
new file mode 100644
index 000..a8798d1
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/camss.c
@@ -0,0 +1,630 @@
+/*
+ * camss.c
+ *
+ * Qualcomm MSM Camera Subsystem - Core
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+#include 
+#include 
+#include 
+
+#include "camss.h"
+
+static struct resources csiphy_res[] = {
+   /* CSIPHY0 */
+   {
+   .regulator = { NULL },
+   .clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
+  "camss_ahb_clk", "csiphy0_timer_clk" },
+   .clock_rate = { 0, 0, 0, 2 },
+   .reg = { "csiphy0", "csiphy0_clk_mux" },
+   .interrupt = { "csiphy0" }
+   },
+
+   /* CSIPHY1 */
+   {
+   .regulator = { NULL },
+   .clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
+  "camss_ahb_clk", "csiphy1_timer_clk" },
+   .clock_rate = { 0, 0, 0, 2 },
+   .reg = { "csiphy1", "csiphy1_clk_mux" },
+   .interrupt = { "csiphy1" }
+   }
+};
+
+static struct resources csid_res[] = {
+   /* CSID0 */
+   {
+   .regulator = { "vdda" },
+   .clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
+  "csi0_ahb_clk", "camss_ahb_clk",
+  "csi0_clk", "csi0_phy_clk",
+  "csi0_pix_clk", "csi0_rdi_clk" },
+   .clock_rate = { 0, 0, 0, 0, 2, 0, 0, 0 },
+   .reg = { "csid0" },
+   .interrupt = { "csid0" }
+   },
+
+   /* CSID1 */
+   {
+   .regulator = { "vdda" },
+   .clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
+  "csi1_ahb_clk", "camss_ahb_clk",
+  "csi1_clk", "csi1_phy_clk",
+  "csi1_pix_clk", "csi1_rdi_clk" },
+   .clock_rate = { 0, 0, 0, 0, 2, 0, 0, 0 },
+   .reg = { "csid1" },
+   .interrupt = { "csid1" }
+   },
+};
+
+static struct resources_ispif ispif_res = {
+   /* ISPIF */
+   .clock = { "camss_top_ahb_clk", "camss_ahb_clk", "ispif_ahb_clk",
+  "csi0_clk", "csi0_pix_clk", "csi0_rdi_clk",
+  "csi1_clk", "csi1_pix_clk", "csi1_rdi_clk" },
+   .clock_for_reset = { "camss_vfe_vfe_clk", "camss_csi_vfe_clk" },
+   .reg = { "ispif", "csi_clk_mux" },
+   .interrupt = "ispif"
+
+};
+
+static struct resources vfe_res = {
+   /* VFE0 */
+   .regulator = { NULL },
+   .clock = { "camss_top_ahb_clk", "camss_vfe_vfe_clk",
+  "camss_csi_vfe_clk", "iface_clk",
+  "bus_clk", "camss_ahb_clk" },
+   .clock_rate = { 0, 32000, 0, 0, 0, 0, 0, 0 },
+   .reg = { "vfe0" },
+   .interrupt = { "vfe0" }
+};
+
+/*
+ * camss_enable_clocks - Enable multiple clocks
+ * @nclocks: Number of clocks in clock array
+ * @clock: Clock array
+ * @dev: Device
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+int camss_enable_clocks(int nclocks, struct clk **clock, struct device *dev)
+{
+   int ret;
+   int i;
+
+   for (i = 0; i < nclocks; i++) {
+   ret = clk_prepare_enable(clock[i]);
+   if (ret) {
+   dev_err(dev, "clock enable failed\n");
+   goto error;
+   }
+   }
+
+   return 0;
+
+error:
+   for (i--; i >= 0; i--)
+   clk_disable_unprepare(clock[i]);
+
+   return ret;
+}
+
+/*
+ * camss_disable_clocks - Disable multiple clocks
+ * @nclocks: Number of clocks in clock array
+ * @clock: Clock array
+ */
+void camss_disable_clocks(int nclocks, struct clk **clock)
+{
+   int i;
+
+   for (i = nclocks - 1; i >= 0; i--)
+   

[PATCH v2 01/19] doc: DT: camss: Binding document for Qualcomm Camera subsystem driver

[Todor Tomov]

Add DT binding document for Qualcomm Camera subsystem driver.

CC: Rob Herring 
CC: devicet...@vger.kernel.org
Signed-off-by: Todor Tomov 
---
 .../devicetree/bindings/media/qcom,camss.txt   | 196 +
 1 file changed, 196 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt

diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt 
b/Documentation/devicetree/bindings/media/qcom,camss.txt
new file mode 100644
index 000..5213b03
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
@@ -0,0 +1,196 @@
+Qualcomm Camera Subsystem
+
+* Properties
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Should contain:
+   - "qcom,msm8916-camss"
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register ranges as listed in the reg-names property.
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries:
+   - "csiphy0"
+   - "csiphy0_clk_mux"
+   - "csiphy1"
+   - "csiphy1_clk_mux"
+   - "csid0"
+   - "csid1"
+   - "ispif"
+   - "csi_clk_mux"
+   - "vfe0"
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: Interrupts as listed in the interrupt-names property.
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries:
+   - "csiphy0"
+   - "csiphy1"
+   - "csid0"
+   - "csid1"
+   - "ispif"
+   - "vfe0"
+- power-domains:
+   Usage: required
+   Value type: 
+   Definition: A phandle and power domain specifier pairs to the
+   power domain which is responsible for collapsing
+   and restoring power to the peripheral.
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: A list of phandle and clock specifier pairs as listed
+   in clock-names property.
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries:
+   - "camss_top_ahb_clk"
+   - "ispif_ahb_clk"
+   - "csiphy0_timer_clk"
+   - "csiphy1_timer_clk"
+   - "csi0_ahb_clk"
+   - "csi0_clk"
+   - "csi0_phy_clk"
+   - "csi0_pix_clk"
+   - "csi0_rdi_clk"
+   - "csi1_ahb_clk"
+   - "csi1_clk"
+   - "csi1_phy_clk"
+   - "csi1_pix_clk"
+   - "csi1_rdi_clk"
+   - "camss_ahb_clk"
+   - "camss_vfe_vfe_clk"
+   - "camss_csi_vfe_clk"
+   - "iface_clk"
+   - "bus_clk"
+- vdda-supply:
+   Usage: required
+   Value type: 
+   Definition: A phandle to voltage supply for CSI2.
+- iommus:
+   Usage: required
+   Value type: 
+   Definition: A list of phandle and IOMMU specifier pairs.
+
+* Nodes
+
+- ports:
+   Usage: required
+   Definition: As described in video-interfaces.txt in same directory.
+   Properties:
+   - reg:
+   Usage: required
+   Value type: 
+   Definition: Selects CSI2 PHY interface - PHY0 or PHY1.
+   Endpoint node properties:
+   - clock-lanes:
+   Usage: required
+   Value type: 
+   Definition: The clock lane.
+   - data-lanes:
+   Usage: required
+   Value type: 
+   Definition: An array of data lanes.
+   - qcom,settle-cnt:
+   Usage: required
+   Value type: 
+   Definition: The settle count parameter for CSI PHY.
+
+* An Example
+
+   camss: camss@1b0 {
+   compatible = "qcom,msm8916-camss";
+   reg = <0x1b0ac00 0x200>,
+   <0x1b00030 0x4>,
+   <0x1b0b000 0x200>,
+   <0x1b00038 0x4>,
+   <0x1b08000 0x100>,
+   <0x1b08400 0x100>,
+   <0x1b0a000 0x500>,
+   <0x1b00020 0x10>,
+   <0x1b1 0x1000>;
+   reg-names = "csiphy0",
+   "csiphy0_clk_mux",
+   "csiphy1",
+   "csiphy1_clk_mux",
+   "csid0",
+   "csid1",
+   "ispif",
+   "csi_clk_mux",
+   "vfe0";
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+ 

[PATCH v2 05/19] media: camss: Add CSID files

[Todor Tomov]

These files control the CSID modules which handle the protocol and application
layer of the CSI2 receivers.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/csid.c | 1072 +
 drivers/media/platform/qcom/camss-8x16/csid.h |   82 ++
 2 files changed, 1154 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/csid.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/csid.h

diff --git a/drivers/media/platform/qcom/camss-8x16/csid.c 
b/drivers/media/platform/qcom/camss-8x16/csid.c
new file mode 100644
index 000..c637d78
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/csid.c
@@ -0,0 +1,1072 @@
+/*
+ * csid.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSID Module
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+#include 
+#include 
+
+#include "csid.h"
+#include "camss.h"
+
+#define MSM_CSID_NAME "msm_csid"
+
+#define CAMSS_CSID_HW_VERSION  0x0
+#define CAMSS_CSID_CORE_CTRL_0 0x004
+#define CAMSS_CSID_CORE_CTRL_1 0x008
+#define CAMSS_CSID_RST_CMD 0x00c
+#define CAMSS_CSID_CID_LUT_VC_n(n) (0x010 + 0x4 * (n))
+#define CAMSS_CSID_CID_n_CFG(n)(0x020 + 0x4 * (n))
+#define CAMSS_CSID_IRQ_CLEAR_CMD   0x060
+#define CAMSS_CSID_IRQ_MASK0x064
+#define CAMSS_CSID_IRQ_STATUS  0x068
+#define CAMSS_CSID_TG_CTRL 0x0a0
+#define CAMSS_CSID_TG_VC_CFG   0x0a4
+#define CAMSS_CSID_TG_VC_CFG_H_BLANKING0x3ff
+#define CAMSS_CSID_TG_VC_CFG_V_BLANKING0x7f
+#define CAMSS_CSID_TG_DT_n_CGG_0(n)(0x0ac + 0xc * (n))
+#define CAMSS_CSID_TG_DT_n_CGG_1(n)(0x0b0 + 0xc * (n))
+#define CAMSS_CSID_TG_DT_n_CGG_2(n)(0x0b4 + 0xc * (n))
+
+#define DATA_TYPE_EMBEDDED_DATA_8BIT   0x12
+#define DATA_TYPE_YUV422_8BIT  0x1e
+#define DATA_TYPE_RAW_6BIT 0x28
+#define DATA_TYPE_RAW_8BIT 0x2a
+#define DATA_TYPE_RAW_10BIT0x2b
+#define DATA_TYPE_RAW_12BIT0x2c
+
+#define DECODE_FORMAT_UNCOMPRESSED_6_BIT   0x0
+#define DECODE_FORMAT_UNCOMPRESSED_8_BIT   0x1
+#define DECODE_FORMAT_UNCOMPRESSED_10_BIT  0x2
+#define DECODE_FORMAT_UNCOMPRESSED_12_BIT  0x3
+
+#define CSID_RESET_TIMEOUT_MS 500
+
+static const struct {
+   u32 code;
+   u32 uncompressed;
+   u8 data_type;
+   u8 decode_format;
+   u8 uncompr_bpp;
+} csid_input_fmts[] = {
+   {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   16
+   },
+   {
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   16
+   },
+   {
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   16
+   },
+   {
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   16
+   },
+   {
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8
+   },
+   {
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8
+   },
+   {
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8
+   },
+   {
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8
+   },
+   {
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   DATA_TYPE_RAW_10BIT,
+   DECODE_FORMAT_UNCOMPRESSED_10_BIT,
+   10
+   },
+   {
+   

[PATCH v2 16/19] camss: vfe: Add interface for cropping

[Todor Tomov]

Extend selection ioctls to handle cropping configuration.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/vfe.c | 191 +--
 drivers/media/platform/qcom/camss-8x16/vfe.h |   1 +
 2 files changed, 150 insertions(+), 42 deletions(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/vfe.c 
b/drivers/media/platform/qcom/camss-8x16/vfe.c
index a64f158..b97aefa 100644
--- a/drivers/media/platform/qcom/camss-8x16/vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/vfe.c
@@ -1960,6 +1960,26 @@ static int vfe_set_stream(struct v4l2_subdev *sd, int 
enable)
 }
 
 /*
+ * __vfe_get_crop - Get pointer to crop selection structure
+ * @line: VFE line
+ * @cfg: V4L2 subdev pad configuration
+ * @which: TRY or ACTIVE format
+ *
+ * Return pointer to TRY or ACTIVE crop rectangle structure
+ */
+static struct v4l2_rect *
+__vfe_get_crop(struct vfe_line *line,
+  struct v4l2_subdev_pad_config *cfg,
+  enum v4l2_subdev_format_whence which)
+{
+   if (which == V4L2_SUBDEV_FORMAT_TRY)
+   return v4l2_subdev_get_try_crop(>subdev, cfg,
+   MSM_VFE_PAD_SRC);
+
+   return >crop;
+}
+
+/*
  * vfe_try_format - Handle try format by pad subdev method
  * @line: VFE line
  * @cfg: V4L2 subdev pad configuration
@@ -2007,7 +2027,7 @@ static void vfe_try_format(struct vfe_line *line,
if (line->id == VFE_LINE_PIX) {
struct v4l2_rect *rect;
 
-   rect = __vfe_get_compose(line, cfg, which);
+   rect = __vfe_get_crop(line, cfg, which);
 
fmt->width = rect->width;
fmt->height = rect->height;
@@ -2092,6 +2112,49 @@ static void vfe_try_compose(struct vfe_line *line,
 }
 
 /*
+ * vfe_try_crop - Handle try crop selection by pad subdev method
+ * @line: VFE line
+ * @cfg: V4L2 subdev pad configuration
+ * @rect: pointer to v4l2 rect structure
+ * @which: wanted subdev format
+ */
+static void vfe_try_crop(struct vfe_line *line,
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_rect *rect,
+enum v4l2_subdev_format_whence which)
+{
+   struct v4l2_rect *compose;
+
+   compose = __vfe_get_compose(line, cfg, which);
+
+   if (rect->width > compose->width)
+   rect->width = compose->width;
+
+   if (rect->width + rect->left > compose->width)
+   rect->left = compose->width - rect->width;
+
+   if (rect->height > compose->height)
+   rect->height = compose->height;
+
+   if (rect->height + rect->top > compose->height)
+   rect->top = compose->height - rect->height;
+
+   /* wm in line based mode writes multiple of 16 horizontally */
+   rect->left += (rect->width & 0xf) >> 1;
+   rect->width &= ~0xf;
+
+   if (rect->width < 16) {
+   rect->left = 0;
+   rect->width = 16;
+   }
+
+   if (rect->height < 4) {
+   rect->top = 0;
+   rect->height = 4;
+   }
+}
+
+/*
  * vfe_enum_mbus_code - Handle pixel format enumeration
  * @sd: VFE V4L2 subdevice
  * @cfg: V4L2 subdev pad configuration
@@ -2255,34 +2318,58 @@ static int vfe_get_selection(struct v4l2_subdev *sd,
 {
struct vfe_line *line = v4l2_get_subdevdata(sd);
struct v4l2_subdev_format fmt = { 0 };
-   struct v4l2_rect *compose;
+   struct v4l2_rect *rect;
int ret;
 
-   if (line->id != VFE_LINE_PIX || sel->pad != MSM_VFE_PAD_SINK)
+   if (line->id != VFE_LINE_PIX)
return -EINVAL;
 
-   switch (sel->target) {
-   case V4L2_SEL_TGT_COMPOSE_BOUNDS:
-   fmt.pad = sel->pad;
-   fmt.which = sel->which;
-   ret = vfe_get_format(sd, cfg, );
-   if (ret < 0)
-   return ret;
-   sel->r.left = 0;
-   sel->r.top = 0;
-   sel->r.width = fmt.format.width;
-   sel->r.height = fmt.format.height;
-   break;
-   case V4L2_SEL_TGT_COMPOSE:
-   compose = __vfe_get_compose(line, cfg, sel->which);
-   if (compose == NULL)
+   if (sel->pad == MSM_VFE_PAD_SINK)
+   switch (sel->target) {
+   case V4L2_SEL_TGT_COMPOSE_BOUNDS:
+   fmt.pad = sel->pad;
+   fmt.which = sel->which;
+   ret = vfe_get_format(sd, cfg, );
+   if (ret < 0)
+   return ret;
+
+   sel->r.left = 0;
+   sel->r.top = 0;
+   sel->r.width = fmt.format.width;
+   sel->r.height = fmt.format.height;
+   break;
+   case V4L2_SEL_TGT_COMPOSE:
+   rect = __vfe_get_compose(line, cfg, 

[PATCH v2 02/19] MAINTAINERS: Add Qualcomm Camera subsystem driver

[Todor Tomov]

Add an entry for Qualcomm Camera subsystem driver.

Signed-off-by: Todor Tomov 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 09b5ab6..524fe09 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10570,6 +10570,14 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
 S: Supported
 F: drivers/net/wireless/ath/ath10k/
 
+QUALCOMM CAMERA SUBSYSTEM DRIVER
+M: Todor Tomov 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/qcom,camss.txt
+F: Documentation/media/v4l-drivers/qcom_camss.rst
+F: drivers/media/platform/qcom/camss/
+
 QUALCOMM EMAC GIGABIT ETHERNET DRIVER
 M: Timur Tabi 
 L: net...@vger.kernel.org
-- 
1.9.1

[PATCH v2 13/19] camss: vfe: Support for frame padding

[Todor Tomov]

Add support for horizontal and vertical frame padding.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/vfe.c   | 86 --
 drivers/media/platform/qcom/camss-8x16/video.c | 66 +++-
 drivers/media/platform/qcom/camss-8x16/video.h |  2 +
 3 files changed, 118 insertions(+), 36 deletions(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/vfe.c 
b/drivers/media/platform/qcom/camss-8x16/vfe.c
index 0964e23..433a54e 100644
--- a/drivers/media/platform/qcom/camss-8x16/vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/vfe.c
@@ -279,21 +279,75 @@ static void vfe_wm_frame_based(struct vfe_device *vfe, u8 
wm, u8 enable)
1 << VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_FRM_BASED_SHIFT);
 }
 
+#define CALC_WORD(width, M, N) (((width) * (M) + (N) - 1) / (N))
+
+static int vfe_word_per_line(uint32_t format, uint32_t pixel_per_line)
+{
+   int val = 0;
+
+   switch (format) {
+   case V4L2_PIX_FMT_NV12:
+   case V4L2_PIX_FMT_NV21:
+   case V4L2_PIX_FMT_NV16:
+   case V4L2_PIX_FMT_NV61:
+   val = CALC_WORD(pixel_per_line, 1, 8);
+   break;
+   case V4L2_PIX_FMT_YUYV:
+   case V4L2_PIX_FMT_YVYU:
+   case V4L2_PIX_FMT_UYVY:
+   case V4L2_PIX_FMT_VYUY:
+   val = CALC_WORD(pixel_per_line, 2, 8);
+   break;
+   }
+
+   return val;
+}
+
+static void vfe_get_wm_sizes(struct v4l2_pix_format_mplane *pix, u8 plane,
+u16 *width, u16 *height, u16 *bytesperline)
+{
+   switch (pix->pixelformat) {
+   case V4L2_PIX_FMT_NV12:
+   case V4L2_PIX_FMT_NV21:
+   *width = pix->width;
+   *height = pix->height;
+   *bytesperline = pix->plane_fmt[0].bytesperline;
+   if (plane == 1)
+   *height /= 2;
+   break;
+   case V4L2_PIX_FMT_NV16:
+   case V4L2_PIX_FMT_NV61:
+   *width = pix->width;
+   *height = pix->height;
+   *bytesperline = pix->plane_fmt[0].bytesperline;
+   break;
+   }
+}
+
 static void vfe_wm_line_based(struct vfe_device *vfe, u32 wm,
- u16 width, u16 height, u32 enable)
+ struct v4l2_pix_format_mplane *pix,
+ u8 plane, u32 enable)
 {
u32 reg;
 
if (enable) {
+   u16 width = 0, height = 0, bytesperline = 0, wpl;
+
+   vfe_get_wm_sizes(pix, plane, , , );
+
+   wpl = vfe_word_per_line(pix->pixelformat, width);
+
reg = height - 1;
-   reg |= (width / 16 - 1) << 16;
+   reg |= ((wpl + 1) / 2 - 1) << 16;
 
writel_relaxed(reg, vfe->base +
   VFE_0_BUS_IMAGE_MASTER_n_WR_IMAGE_SIZE(wm));
 
+   wpl = vfe_word_per_line(pix->pixelformat, bytesperline);
+
reg = 0x3;
reg |= (height - 1) << 4;
-   reg |= (width / 8) << 16;
+   reg |= wpl << 16;
 
writel_relaxed(reg, vfe->base +
   VFE_0_BUS_IMAGE_MASTER_n_WR_BUFFER_CFG(wm));
@@ -1197,25 +1251,14 @@ static int vfe_enable_output(struct vfe_line *line)
} else {
ub_size /= output->wm_num;
for (i = 0; i < output->wm_num; i++) {
-   u32 p = 
line->video_out.active_fmt.fmt.pix_mp.pixelformat;
-
vfe_set_cgc_override(vfe, output->wm_idx[i], 1);
vfe_wm_set_subsample(vfe, output->wm_idx[i]);
vfe_wm_set_ub_cfg(vfe, output->wm_idx[i],
  (ub_size + 1) * output->wm_idx[i],
  ub_size);
-   if ((i == 1) && (p == V4L2_PIX_FMT_NV12 ||
-   p == V4L2_PIX_FMT_NV21))
-   vfe_wm_line_based(vfe, output->wm_idx[i],
- 
line->fmt[MSM_VFE_PAD_SRC].width,
- 
line->fmt[MSM_VFE_PAD_SRC].height / 2,
- 1);
-   else
-   vfe_wm_line_based(vfe, output->wm_idx[i],
- 
line->fmt[MSM_VFE_PAD_SRC].width,
- 
line->fmt[MSM_VFE_PAD_SRC].height,
- 1);
-
+   vfe_wm_line_based(vfe, output->wm_idx[i],
+   >video_out.active_fmt.fmt.pix_mp,
+   i, 1);
vfe_wm_enable(vfe, output->wm_idx[i], 1);
vfe_bus_reload_wm(vfe, output->wm_idx[i]);
}
@@ -1277,7 +1320,7 @@ 

LinuxTV V3 vs. V4 API doc inconsistency, V4 probably wrong

[Thierry Lelegard]

Hi,

There is an ambiguity in the LinuxTV documentation about the following 
ioctl's:


   FE_SET_TONE, FE_SET_VOLTAGE, FE_DISEQC_SEND_BURST.

These ioctl's take an enum value as input. In the old V3 API, the 
parameter
is passed by value. In the S2API documentation, it is passed by 
reference.

Most sample programs (a bit old) use the "pass by value" method.

V3 documentation: https://www.linuxtv.org/docs/dvbapi/dvbapi.html
   int ioctl(int fd, int request = FE_SET_TONE, fe_sec_tone_mode_t 
tone);
   int ioctl(int fd, int request = FE_SET_VOLTAGE, fe_sec_voltage_t 
voltage);
   int ioctl(int fd, int request = FE_DISEQC_SEND_BURST, 
fe_sec_mini_cmd_t burst);


S2API documentation: 
https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/dvb/frontend_fcalls.html

   int ioctl(int fd, FE_SET_TONE, enum fe_sec_tone_mode *tone)
   int ioctl(int fd, FE_SET_VOLTAGE, enum fe_sec_voltage *voltage)
   int ioctl(int fd, FE_DISEQC_SEND_BURST, enum fe_sec_mini_cmd *tone)

Also in: 
https://www.kernel.org/doc/html/v4.10/media/uapi/dvb/frontend_fcalls.html


Which one is correct? If both are correct and the API was changed (I 
doubt about it),

how can we know which one to use?

Normally, I would say that the most recent doc is right. However, all 
sample
codes use "by value". Moreover, if the most recent doc was right, then 
passing
by value should fail since the values are zero or close to zero and are 
not

valid addresses.

Thanks
-Thierry

[PATCH v2 07/19] media: camss: Add VFE files

[Todor Tomov]

These files control the VFE module. The VFE has different input interfaces.
The PIX input interface feeds the input data to an image processing pipeline.
Three RDI input interfaces bypass the image processing pipeline. The VFE also
contains the AXI bus interface which writes the output data to memory.

RDI interfaces are supported in this version. PIX interface is not supported.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/vfe.c | 1898 ++
 drivers/media/platform/qcom/camss-8x16/vfe.h |  114 ++
 2 files changed, 2012 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss-8x16/vfe.c
 create mode 100644 drivers/media/platform/qcom/camss-8x16/vfe.h

diff --git a/drivers/media/platform/qcom/camss-8x16/vfe.c 
b/drivers/media/platform/qcom/camss-8x16/vfe.c
new file mode 100644
index 000..00d4e5c
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/vfe.c
@@ -0,0 +1,1898 @@
+/*
+ * vfe.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE Module
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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 
+#include 
+#include 
+#include 
+#include 
+
+#include "vfe.h"
+#include "camss.h"
+
+#define MSM_VFE_NAME "msm_vfe"
+
+#define vfe_line_array(ptr_line)   \
+   ((const struct vfe_line (*)[]) &(ptr_line[-(ptr_line->id)]))
+
+#define to_vfe(ptr_line)   \
+   container_of(vfe_line_array(ptr_line), struct vfe_device, ptr_line)
+
+#define VFE_0_HW_VERSION   0x000
+
+#define VFE_0_GLOBAL_RESET_CMD 0x00c
+#define VFE_0_GLOBAL_RESET_CMD_CORE(1 << 0)
+#define VFE_0_GLOBAL_RESET_CMD_CAMIF   (1 << 1)
+#define VFE_0_GLOBAL_RESET_CMD_BUS (1 << 2)
+#define VFE_0_GLOBAL_RESET_CMD_BUS_BDG (1 << 3)
+#define VFE_0_GLOBAL_RESET_CMD_REGISTER(1 << 4)
+#define VFE_0_GLOBAL_RESET_CMD_TIMER   (1 << 5)
+#define VFE_0_GLOBAL_RESET_CMD_PM  (1 << 6)
+#define VFE_0_GLOBAL_RESET_CMD_BUS_MISR(1 << 7)
+#define VFE_0_GLOBAL_RESET_CMD_TESTGEN (1 << 8)
+
+#define VFE_0_IRQ_CMD  0x024
+#define VFE_0_IRQ_CMD_GLOBAL_CLEAR (1 << 0)
+
+#define VFE_0_IRQ_MASK_0   0x028
+#define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)(1 << ((n) + 5))
+#define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n)   (1 << ((n) + 8))
+#define VFE_0_IRQ_MASK_0_RESET_ACK (1 << 31)
+#define VFE_0_IRQ_MASK_1   0x02c
+#define VFE_0_IRQ_MASK_1_VIOLATION (1 << 7)
+#define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK  (1 << 8)
+#define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n)(1 << ((n) + 9))
+
+#define VFE_0_IRQ_CLEAR_0  0x030
+#define VFE_0_IRQ_CLEAR_1  0x034
+
+#define VFE_0_IRQ_STATUS_0 0x038
+#define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)  (1 << ((n) + 5))
+#define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8))
+#define VFE_0_IRQ_STATUS_0_RESET_ACK   (1 << 31)
+#define VFE_0_IRQ_STATUS_1 0x03c
+#define VFE_0_IRQ_STATUS_1_VIOLATION   (1 << 7)
+#define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACK(1 << 8)
+
+#define VFE_0_VIOLATION_STATUS 0x48
+
+#define VFE_0_BUS_CMD  0x4c
+#define VFE_0_BUS_CMD_Mx_RLD_CMD(x)(1 << (x))
+
+#define VFE_0_BUS_CFG  0x050
+
+#define VFE_0_BUS_XBAR_CFG_x(x)(0x58 + 0x4 * ((x) / 2))
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT 8
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI0  5
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI1  6
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI2  7
+
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG(n) (0x06c + 0x24 * (n))
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_WR_PATH_SHIFT  0
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_FRM_BASED_SHIFT1
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_PING_ADDR(n)   (0x070 + 0x24 * (n))
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_PONG_ADDR(n)   (0x074 + 0x24 * (n))
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG(n)(0x078 + 0x24 * 
(n))
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG_FRM_DROP_PER_SHIFT2
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG_FRM_DROP_PER_MASK (0x1F << 2)
+
+#define VFE_0_BUS_IMAGE_MASTER_n_WR_UB_CFG(n)  (0x07c + 0x24 * (n))
+#define 

[PATCH v2 11/19] camss: vfe: Format conversion support using PIX interface

[Todor Tomov]

Use VFE PIX input interface and do format conversion in VFE.

Supported input format is UYVY (single plane YUV 4:2:2) and
its different sample order variations.

Supported output formats are:
- NV12/NV21 (two plane YUV 4:2:0)
- NV16/NV61 (two plane YUV 4:2:2)

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/ispif.c |   2 +
 drivers/media/platform/qcom/camss-8x16/vfe.c   | 672 ++---
 drivers/media/platform/qcom/camss-8x16/vfe.h   |  13 +-
 drivers/media/platform/qcom/camss-8x16/video.c | 331 +---
 drivers/media/platform/qcom/camss-8x16/video.h |   8 +-
 5 files changed, 874 insertions(+), 152 deletions(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/ispif.c 
b/drivers/media/platform/qcom/camss-8x16/ispif.c
index c72d06c..4f3d8c3 100644
--- a/drivers/media/platform/qcom/camss-8x16/ispif.c
+++ b/drivers/media/platform/qcom/camss-8x16/ispif.c
@@ -968,6 +968,8 @@ static enum ispif_intf ispif_get_intf(enum vfe_line_id 
line_id)
return RDI1;
case (VFE_LINE_RDI2):
return RDI2;
+   case (VFE_LINE_PIX):
+   return PIX0;
default:
return RDI0;
}
diff --git a/drivers/media/platform/qcom/camss-8x16/vfe.c 
b/drivers/media/platform/qcom/camss-8x16/vfe.c
index 00d4e5c..0964e23 100644
--- a/drivers/media/platform/qcom/camss-8x16/vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/vfe.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -52,29 +53,53 @@
 #define VFE_0_GLOBAL_RESET_CMD_BUS_MISR(1 << 7)
 #define VFE_0_GLOBAL_RESET_CMD_TESTGEN (1 << 8)
 
+#define VFE_0_MODULE_CFG   0x018
+#define VFE_0_MODULE_CFG_DEMUX (1 << 2)
+#define VFE_0_MODULE_CFG_CHROMA_UPSAMPLE   (1 << 3)
+#define VFE_0_MODULE_CFG_SCALE_ENC (1 << 23)
+
+#define VFE_0_CORE_CFG 0x01c
+#define VFE_0_CORE_CFG_PIXEL_PATTERN_YCBYCR0x4
+#define VFE_0_CORE_CFG_PIXEL_PATTERN_YCRYCB0x5
+#define VFE_0_CORE_CFG_PIXEL_PATTERN_CBYCRY0x6
+#define VFE_0_CORE_CFG_PIXEL_PATTERN_CRYCBY0x7
+
 #define VFE_0_IRQ_CMD  0x024
 #define VFE_0_IRQ_CMD_GLOBAL_CLEAR (1 << 0)
 
 #define VFE_0_IRQ_MASK_0   0x028
+#define VFE_0_IRQ_MASK_0_CAMIF_SOF (1 << 0)
+#define VFE_0_IRQ_MASK_0_CAMIF_EOF (1 << 1)
 #define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)(1 << ((n) + 5))
+#define VFE_0_IRQ_MASK_0_line_n_REG_UPDATE(n)  \
+   ((n) == VFE_LINE_PIX ? (1 << 4) : VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n))
 #define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n)   (1 << ((n) + 8))
+#define VFE_0_IRQ_MASK_0_IMAGE_COMPOSITE_DONE_n(n) (1 << ((n) + 25))
 #define VFE_0_IRQ_MASK_0_RESET_ACK (1 << 31)
 #define VFE_0_IRQ_MASK_1   0x02c
+#define VFE_0_IRQ_MASK_1_CAMIF_ERROR   (1 << 0)
 #define VFE_0_IRQ_MASK_1_VIOLATION (1 << 7)
 #define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK  (1 << 8)
 #define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n)(1 << ((n) + 9))
+#define VFE_0_IRQ_MASK_1_RDIn_SOF(n)   (1 << ((n) + 29))
 
 #define VFE_0_IRQ_CLEAR_0  0x030
 #define VFE_0_IRQ_CLEAR_1  0x034
 
 #define VFE_0_IRQ_STATUS_0 0x038
+#define VFE_0_IRQ_STATUS_0_CAMIF_SOF   (1 << 0)
 #define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)  (1 << ((n) + 5))
+#define VFE_0_IRQ_STATUS_0_line_n_REG_UPDATE(n)\
+   ((n) == VFE_LINE_PIX ? (1 << 4) : VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n))
 #define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8))
+#define VFE_0_IRQ_STATUS_0_IMAGE_COMPOSITE_DONE_n(n)   (1 << ((n) + 25))
 #define VFE_0_IRQ_STATUS_0_RESET_ACK   (1 << 31)
 #define VFE_0_IRQ_STATUS_1 0x03c
 #define VFE_0_IRQ_STATUS_1_VIOLATION   (1 << 7)
 #define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACK(1 << 8)
+#define VFE_0_IRQ_STATUS_1_RDIn_SOF(n) (1 << ((n) + 29))
 
+#define VFE_0_IRQ_COMPOSITE_MASK_0 0x40
 #define VFE_0_VIOLATION_STATUS 0x48
 
 #define VFE_0_BUS_CMD  0x4c
@@ -83,7 +108,10 @@
 #define VFE_0_BUS_CFG  0x050
 
 #define VFE_0_BUS_XBAR_CFG_x(x)(0x58 + 0x4 * ((x) / 2))
+#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN  (1 << 1)
+#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA(0x3 << 4)
 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT 8
+#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_LUMA  0
 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI0  5
 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI1  6
 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI2  7
@@ -99,6 +127,8 @@
 
 #define VFE_0_BUS_IMAGE_MASTER_n_WR_UB_CFG(n)  (0x07c + 0x24 * (n))
 

[PATCH v2 19/19] camss: Use optimal clock frequency rates

[Todor Tomov]

Use standard V4L2 control to get pixel clock rate from a sensor
linked in the media controller pipeline. Then calculate clock
rates on CSIPHY, CSID and VFE to use the lowest possible.

If the currnet pixel clock rate of the sensor cannot be read then
use the highest possible. This case covers also the CSID test
generator usage.

If VFE is already powered on by another pipeline, check that the
current VFE clock rate is high enough for the new pipeline.
If not return busy error code as VFE clock rate cannot be changed
while VFE is running.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/camss.c  | 114 +-
 drivers/media/platform/qcom/camss-8x16/camss.h  |  15 +-
 drivers/media/platform/qcom/camss-8x16/csid.c   | 243 
 drivers/media/platform/qcom/camss-8x16/csid.h   |   2 +-
 drivers/media/platform/qcom/camss-8x16/csiphy.c | 211 ++
 drivers/media/platform/qcom/camss-8x16/csiphy.h |   2 +-
 drivers/media/platform/qcom/camss-8x16/ispif.c  |  23 +-
 drivers/media/platform/qcom/camss-8x16/ispif.h  |   4 +-
 drivers/media/platform/qcom/camss-8x16/vfe.c| 282 +---
 drivers/media/platform/qcom/camss-8x16/vfe.h|   2 +-
 10 files changed, 712 insertions(+), 186 deletions(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/camss.c 
b/drivers/media/platform/qcom/camss-8x16/camss.c
index a8798d1..8c7 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss.c
+++ b/drivers/media/platform/qcom/camss-8x16/camss.c
@@ -17,10 +17,12 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -36,7 +38,10 @@
.regulator = { NULL },
.clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
   "camss_ahb_clk", "csiphy0_timer_clk" },
-   .clock_rate = { 0, 0, 0, 2 },
+   .clock_rate = { { 0 },
+   { 0 },
+   { 0 },
+   { 1, 2 } },
.reg = { "csiphy0", "csiphy0_clk_mux" },
.interrupt = { "csiphy0" }
},
@@ -46,7 +51,10 @@
.regulator = { NULL },
.clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
   "camss_ahb_clk", "csiphy1_timer_clk" },
-   .clock_rate = { 0, 0, 0, 2 },
+   .clock_rate = { { 0 },
+   { 0 },
+   { 0 },
+   { 1, 2 } },
.reg = { "csiphy1", "csiphy1_clk_mux" },
.interrupt = { "csiphy1" }
}
@@ -60,7 +68,14 @@
   "csi0_ahb_clk", "camss_ahb_clk",
   "csi0_clk", "csi0_phy_clk",
   "csi0_pix_clk", "csi0_rdi_clk" },
-   .clock_rate = { 0, 0, 0, 0, 2, 0, 0, 0 },
+   .clock_rate = { { 0 },
+   { 0 },
+   { 0 },
+   { 0 },
+   { 1, 2 },
+   { 0 },
+   { 0 },
+   { 0 } },
.reg = { "csid0" },
.interrupt = { "csid0" }
},
@@ -72,7 +87,14 @@
   "csi1_ahb_clk", "camss_ahb_clk",
   "csi1_clk", "csi1_phy_clk",
   "csi1_pix_clk", "csi1_rdi_clk" },
-   .clock_rate = { 0, 0, 0, 0, 2, 0, 0, 0 },
+   .clock_rate = { { 0 },
+   { 0 },
+   { 0 },
+   { 0 },
+   { 1, 2 },
+   { 0 },
+   { 0 },
+   { 0 } },
.reg = { "csid1" },
.interrupt = { "csid1" }
},
@@ -95,7 +117,17 @@
.clock = { "camss_top_ahb_clk", "camss_vfe_vfe_clk",
   "camss_csi_vfe_clk", "iface_clk",
   "bus_clk", "camss_ahb_clk" },
-   .clock_rate = { 0, 32000, 0, 0, 0, 0, 0, 0 },
+   .clock_rate = { { 0 },
+   { 5000, 8000, 1, 16000,
+ 17778, 2, 26667, 32000,
+ 4, 46500 },
+   { 0 },
+   { 0 },
+   { 0 },
+   { 0 },
+   { 0 },
+   { 0 },
+   { 0 } },
.reg = { "vfe0" },
.interrupt = { "vfe0" }
 };
@@ -108,13 +140,14 @@
  *
  * Return 0 on success or a negative error code otherwise
  */
-int camss_enable_clocks(int nclocks, struct clk 

[PATCH v2 15/19] camss: vfe: Configure scaler module in VFE

[Todor Tomov]

Add scaler module configuration support to be able to apply scaling.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss-8x16/vfe.c | 59 ++--
 1 file changed, 46 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/qcom/camss-8x16/vfe.c 
b/drivers/media/platform/qcom/camss-8x16/vfe.c
index 2d2bbcb..a64f158 100644
--- a/drivers/media/platform/qcom/camss-8x16/vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/vfe.c
@@ -183,13 +183,16 @@
 #define VFE_0_DEMUX_EVEN_CFG   0x438
 #define VFE_0_DEMUX_ODD_CFG0x43c
 
+#define VFE_0_SCALE_ENC_Y_CFG  0x75c
+#define VFE_0_SCALE_ENC_Y_H_IMAGE_SIZE 0x760
+#define VFE_0_SCALE_ENC_Y_H_PHASE  0x764
+#define VFE_0_SCALE_ENC_Y_V_IMAGE_SIZE 0x76c
+#define VFE_0_SCALE_ENC_Y_V_PHASE  0x770
 #define VFE_0_SCALE_ENC_CBCR_CFG   0x778
 #define VFE_0_SCALE_ENC_CBCR_H_IMAGE_SIZE  0x77c
 #define VFE_0_SCALE_ENC_CBCR_H_PHASE   0x780
-#define VFE_0_SCALE_ENC_CBCR_H_PAD 0x78c
 #define VFE_0_SCALE_ENC_CBCR_V_IMAGE_SIZE  0x790
 #define VFE_0_SCALE_ENC_CBCR_V_PHASE   0x794
-#define VFE_0_SCALE_ENC_CBCR_V_PAD 0x7a0
 
 #define VFE_0_CLAMP_ENC_MAX_CFG0x874
 #define VFE_0_CLAMP_ENC_MIN_CFG0x878
@@ -644,6 +647,20 @@ static void vfe_set_demux_cfg(struct vfe_device *vfe, 
struct vfe_line *line)
writel_relaxed(odd_cfg, vfe->base + VFE_0_DEMUX_ODD_CFG);
 }
 
+static inline u8 vfe_calc_interp_reso(u16 input, u16 output)
+{
+   if (input / output >= 16)
+   return 0;
+
+   if (input / output >= 8)
+   return 1;
+
+   if (input / output >= 4)
+   return 2;
+
+   return 3;
+}
+
 static void vfe_set_scale_cfg(struct vfe_device *vfe, struct vfe_line *line)
 {
u32 p = line->video_out.active_fmt.fmt.pix_mp.pixelformat;
@@ -652,35 +669,51 @@ static void vfe_set_scale_cfg(struct vfe_device *vfe, 
struct vfe_line *line)
u8 interp_reso;
u32 phase_mult;
 
+   writel_relaxed(0x3, vfe->base + VFE_0_SCALE_ENC_Y_CFG);
+
+   input = line->fmt[MSM_VFE_PAD_SINK].width;
+   output = line->compose.width;
+   reg = (output << 16) | input;
+   writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_Y_H_IMAGE_SIZE);
+
+   interp_reso = vfe_calc_interp_reso(input, output);
+   phase_mult = input * (1 << (13 + interp_reso)) / output;
+   reg = (interp_reso << 20) | phase_mult;
+   writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_Y_H_PHASE);
+
+   input = line->fmt[MSM_VFE_PAD_SINK].height;
+   output = line->compose.height;
+   reg = (output << 16) | input;
+   writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_Y_V_IMAGE_SIZE);
+
+   interp_reso = vfe_calc_interp_reso(input, output);
+   phase_mult = input * (1 << (13 + interp_reso)) / output;
+   reg = (interp_reso << 20) | phase_mult;
+   writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_Y_V_PHASE);
+
writel_relaxed(0x3, vfe->base + VFE_0_SCALE_ENC_CBCR_CFG);
 
input = line->fmt[MSM_VFE_PAD_SINK].width;
-   output = line->fmt[MSM_VFE_PAD_SRC].width / 2;
+   output = line->compose.width / 2;
reg = (output << 16) | input;
writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_CBCR_H_IMAGE_SIZE);
 
-   interp_reso = 3;
+   interp_reso = vfe_calc_interp_reso(input, output);
phase_mult = input * (1 << (13 + interp_reso)) / output;
reg = (interp_reso << 20) | phase_mult;
writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_CBCR_H_PHASE);
 
-   reg = input;
-   writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_CBCR_H_PAD);
-
input = line->fmt[MSM_VFE_PAD_SINK].height;
-   output = line->fmt[MSM_VFE_PAD_SRC].height;
+   output = line->compose.height;
if (p == V4L2_PIX_FMT_NV12 || p == V4L2_PIX_FMT_NV21)
-   output = line->fmt[MSM_VFE_PAD_SRC].height / 2;
+   output = line->compose.height / 2;
reg = (output << 16) | input;
writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_CBCR_V_IMAGE_SIZE);
 
-   interp_reso = 3;
+   interp_reso = vfe_calc_interp_reso(input, output);
phase_mult = input * (1 << (13 + interp_reso)) / output;
reg = (interp_reso << 20) | phase_mult;
writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_CBCR_V_PHASE);
-
-   reg = input;
-   writel_relaxed(reg, vfe->base + VFE_0_SCALE_ENC_CBCR_V_PAD);
 }
 
 static void vfe_set_clamp_cfg(struct vfe_device *vfe)
-- 
1.9.1

Re: [PATCH 08/12] Add USB quirk for HVR-950q to avoid intermittent device resets

[Devin Heitmueller]

> I've accepted the other patches in this patch series for the media subsystem,
> but this patch should go through the USB subsystem. Cc-ed linux-usb.
>
> Acked-by: Hans Verkuil 



I'm not sure who on the linux-usb mailing list would need to deal with
this, but would be great if we could get this merged.

Thanks,

Devin

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

Re: [PATCH v2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect

[Daniel Axtens]

Hi Laurent,

Just checking if this was OK with you - I hadn't heard anything and I
noticed it's not in -next so I just wanted to check to see if there were
any changes you wanted.

Regards,
Daniel

Daniel Axtens  writes:

> Currently, disconnecting a USB webcam while it is in use prints out a
> number of warnings, such as:
>
> WARNING: CPU: 2 PID: 3118 at 
> /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237 
> sysfs_remove_group+0x8b/0x90
> sysfs group a7cd0780 not found for kobject 'event13'
>
> This has been noticed before. [0]
>
> This is because of the order in which things are torn down.
>
> If there are no streams active during a USB disconnect:
>
>  - uvc_disconnect() is invoked via device_del() through the bus
>notifier mechanism.
>
>  - this calls uvc_unregister_video().
>
>  - uvc_unregister_video() unregisters the video device for each
>stream,
>
>  - because there are no streams open, it calls uvc_delete()
>
>  - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
>input device.
>
>  - uvc_delete() calls media_device_unregister(), which cleans up the
>media device
>
>  - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
>return, and we end up back in device_del().
>
>  - device_del() then cleans up the sysfs folder for the camera with
>dpm_sysfs_remove(). Because uvc_status_cleanup() and
>media_device_unregister() have already been called, this all works
>nicely.
>
> If, on the other hand, there *are* streams active during a USB disconnect:
>
>  - uvc_disconnect() is invoked
>
>  - this calls uvc_unregister_video()
>
>  - uvc_unregister_video() unregisters the video device for each
>stream,
>
>  - uvc_unregister_video() and uvc_disconnect() return, and we end up
>back in device_del().
>
>  - device_del() then cleans up the sysfs folder for the camera with
>dpm_sysfs_remove(). Because the status input device and the media
>device are children of the USB device, this also deletes their
>sysfs folders.
>
>  - Sometime later, the final stream is closed, invoking uvc_release().
>
>  - uvc_release() calls uvc_delete()
>
>  - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
>input device. Because the sysfs directory has already been removed,
>this causes a WARNing.
>
>  - uvc_delete() calls media_device_unregister(), which cleans up the
>media device. Because the sysfs directory has already been removed,
>this causes another WARNing.
>
> To fix this, we need to make sure the devices are always unregistered
> before the end of uvc_disconnect(). To this, move the unregistration
> into the disconnect path:
>
>  - split uvc_status_cleanup() into two parts, one on disconnect that
>unregisters and one on delete that frees.
>
>  - move v4l2_device_unregister() and media_device_unregister() into
>the disconnect path.
>
> [0]: https://lkml.org/lkml/2016/12/8/657
>
> Cc: Laurent Pinchart 
> Cc: Dave Stevenson 
> Cc: Greg KH 
> Signed-off-by: Daniel Axtens 
>
> ---
>
> v2: Move v4l2_device_unregister() as well as media_device_unregister(),
> thanks Laurent.
>
> Tested with cheese and yavta.
>
> Laurent, I know you were concerned about race conditions so I plugged
> and unplugged the camera over a dozen times, with lots of debugging
> turned on.
>
> In particular:
>  - KASan was enabled and didn't trigger
>  - If I unplugged while yavta was running, and replugged *while yatva
>was still running*, the video camera came up as video2, not video1.
>This indicates that yatva was successfully holding a reference to
>video1 - as it should.
>  - No other debugging triggered any warning.
> ---
>  drivers/media/usb/uvc/uvc_driver.c | 12 
>  drivers/media/usb/uvc/uvc_status.c |  8 ++--
>  drivers/media/usb/uvc/uvcvideo.h   |  1 +
>  3 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c 
> b/drivers/media/usb/uvc/uvc_driver.c
> index 46d6be0bb316..0d0541054ce2 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1812,11 +1812,7 @@ static void uvc_delete(struct uvc_device *dev)
>   usb_put_intf(dev->intf);
>   usb_put_dev(dev->udev);
>  
> - if (dev->vdev.dev)
> - v4l2_device_unregister(>vdev);
>  #ifdef CONFIG_MEDIA_CONTROLLER
> - if (media_devnode_is_registered(dev->mdev.devnode))
> - media_device_unregister(>mdev);
>   media_device_cleanup(>mdev);
>  #endif
>  
> @@ -1884,6 +1880,14 @@ static void uvc_unregister_video(struct uvc_device 
> *dev)
>   uvc_debugfs_cleanup_stream(stream);
>   }
>  
> + uvc_status_unregister(dev);
> + if (dev->vdev.dev)
> + v4l2_device_unregister(>vdev);
> +#ifdef CONFIG_MEDIA_CONTROLLER
> + if 

Re: [PATCH v2 5/6] [media] s5p-jpeg: Add support for resolution change event

[Thierry Escande]

Hi Andrzej,

On 16/06/2017 17:38, Andrzej Pietrasiewicz wrote:

Hi Thierry,

Thank you for the patch.

Can you give a use case for resolution change event?
Unfortunately, the original commit does not mention any clear use case. 
I've asked to the patch author for more information.



Also plase see inline.

W dniu 12.06.2017 o 19:13, Thierry Escande pisze:

From: henryhsu 
@@ -1611,8 +1612,6 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx 
*ct, struct v4l2_format *f)

  FMT_TYPE_OUTPUT : FMT_TYPE_CAPTURE;
  q_data->fmt = s5p_jpeg_find_format(ct, pix->pixelformat, f_type);
-q_data->w = pix->width;
-q_data->h = pix->height;
  if (q_data->fmt->fourcc != V4L2_PIX_FMT_JPEG) {
  /*
   * During encoding Exynos4x12 SoCs access wider memory area
@@ -1620,6 +1619,8 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx 
*ct, struct v4l2_format *f)

   * the JPEG_IMAGE_SIZE register. In order to avoid sysmmu
   * page fault calculate proper buffer size in such a case.
   */
+q_data->w = pix->width;
+q_data->h = pix->height;


Is this change related to what the patch is supposed to be doing?

Yes actually. From the author comments to the same question:
"We want to send a resolution change in the first frame. Without this, 
q_data->w and h will be updated by s_fmt. Then we won't know the 
resolution is changed from (0, 0) to (w, h) in qbuf function."



  static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
  {
  struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
@@ -2499,9 +2545,20 @@ static void s5p_jpeg_buf_queue(struct 
vb2_buffer *vb)

  if (ctx->mode == S5P_JPEG_DECODE &&
  vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
-struct s5p_jpeg_q_data tmp, *q_data;
-
-ctx->hdr_parsed = s5p_jpeg_parse_hdr(,
+static const struct v4l2_event ev_src_ch = {
+.type = V4L2_EVENT_SOURCE_CHANGE,
+.u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
+};
+struct vb2_queue *dst_vq;
+u32 ori_w;
+u32 ori_h;
+
+dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx,
+ V4L2_BUF_TYPE_VIDEO_CAPTURE);
+ori_w = ctx->out_q.w;
+ori_h = ctx->out_q.h;
+
+ctx->hdr_parsed = s5p_jpeg_parse_hdr(>out_q,
   (unsigned long)vb2_plane_vaddr(vb, 0),
   min((unsigned long)ctx->out_q.size,
   vb2_get_plane_payload(vb, 0)), ctx);
@@ -2510,43 +2567,18 @@ static void s5p_jpeg_buf_queue(struct 
vb2_buffer *vb)

  return;
  }
-q_data = >out_q;
-q_data->w = tmp.w;
-q_data->h = tmp.h;
-q_data->sos = tmp.sos;
-memcpy(q_data->dht.marker, tmp.dht.marker,
-   sizeof(tmp.dht.marker));
-memcpy(q_data->dht.len, tmp.dht.len, sizeof(tmp.dht.len));
-q_data->dht.n = tmp.dht.n;
-memcpy(q_data->dqt.marker, tmp.dqt.marker,
-   sizeof(tmp.dqt.marker));
-memcpy(q_data->dqt.len, tmp.dqt.len, sizeof(tmp.dqt.len));
-q_data->dqt.n = tmp.dqt.n;
-q_data->sof = tmp.sof;
-q_data->sof_len = tmp.sof_len;
-
-q_data = >cap_q;
-q_data->w = tmp.w;
-q_data->h = tmp.h;



Why is this part removed?

This has not been removed.
The  s5p_jpeg_q_data struct was passed to s5p_jpeg_parse_hdr() and 
then copied field-by-field into ctx->out_q (through q_data pointer).
With this change ctx->out_q is passed to s5p_jpeg_parse_hdr() and this 
avoids the copy.
Then ctx->cap_q width & height copy is done in 
s5p_jpeg_set_capture_queue_data().


Regards,
 Thierry

[PATCH 2/2] media/uapi/v4l: clarify cropcap/crop/selection behavior

[Hans Verkuil]

From: Hans Verkuil 

Unfortunately the use of 'type' was inconsistent for multiplanar
buffer types. Starting with 4.14 both the normal and _MPLANE variants
are allowed, thus making it possible to write sensible code.

Yes, we messed up :-(

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/vidioc-cropcap.rst| 23 --
 Documentation/media/uapi/v4l/vidioc-g-crop.rst | 22 -
 .../media/uapi/v4l/vidioc-g-selection.rst  | 22 +++--
 3 files changed, 38 insertions(+), 29 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-cropcap.rst 
b/Documentation/media/uapi/v4l/vidioc-cropcap.rst
index f21a69b554e1..446984a7ed21 100644
--- a/Documentation/media/uapi/v4l/vidioc-cropcap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-cropcap.rst
@@ -39,17 +39,10 @@ structure. Drivers fill the rest of the structure. The 
results are
 constant except when switching the video standard. Remember this switch
 can occur implicit when switching the video input or output.
 
-Do not use the multiplanar buffer types. Use
-``V4L2_BUF_TYPE_VIDEO_CAPTURE`` instead of
-``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and use
-``V4L2_BUF_TYPE_VIDEO_OUTPUT`` instead of
-``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``.
-
 This ioctl must be implemented for video capture or output devices that
 support cropping and/or scaling and/or have non-square pixels, and for
 overlay devices.
 
-
 .. c:type:: v4l2_cropcap
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
@@ -62,9 +55,9 @@ overlay devices.
 * - __u32
   - ``type``
   - Type of the data stream, set by the application. Only these types
-   are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``,
-   ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` and
-   ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type`.
+   are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``, 
``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``,
+   ``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`` 
and
+   ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type` and the 
note above.
 * - struct :ref:`v4l2_rect `
   - ``bounds``
   - Defines the window within capturing or output is possible, this
@@ -90,6 +83,16 @@ overlay devices.
``pixelaspect`` to 1/1. Other common values are 54/59 for PAL and
SECAM, 11/10 for NTSC sampled according to [:ref:`itu601`].
 
+.. note::
+   Unfortunately in the case of multiplanar buffer types
+   (``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and 
``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``)
+   this API was messed up with regards to how the :c:type:`v4l2_cropcap` 
``type`` field
+   should be filled in. Some drivers only accepted the ``_MPLANE`` buffer type 
while
+   other drivers only accepted a non-multiplanar buffer type (i.e. without the
+   ``_MPLANE`` at the end).
+
+   Starting with kernel 4.14 both variations are allowed.
+
 
 
 .. _v4l2-rect-crop:
diff --git a/Documentation/media/uapi/v4l/vidioc-g-crop.rst 
b/Documentation/media/uapi/v4l/vidioc-g-crop.rst
index 56a36340f565..0db06acbb6ff 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-crop.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-crop.rst
@@ -45,12 +45,6 @@ and struct :c:type:`v4l2_rect` substructure named ``c`` of a
 v4l2_crop structure and call the :ref:`VIDIOC_S_CROP ` ioctl 
with a pointer
 to this structure.
 
-Do not use the multiplanar buffer types. Use
-``V4L2_BUF_TYPE_VIDEO_CAPTURE`` instead of
-``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and use
-``V4L2_BUF_TYPE_VIDEO_OUTPUT`` instead of
-``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``.
-
 The driver first adjusts the requested dimensions against hardware
 limits, i. e. the bounds given by the capture/output window, and it
 rounds to the closest possible values of horizontal and vertical offset,
@@ -87,14 +81,24 @@ When cropping is not supported then no parameters are 
changed and
 * - __u32
   - ``type``
   - Type of the data stream, set by the application. Only these types
-   are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``,
-   ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` and
-   ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type`.
+   are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``, 
``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``,
+   ``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`` 
and
+   ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type` and the 
note above.
 * - struct :c:type:`v4l2_rect`
   - ``c``
   - Cropping rectangle. The same co-ordinate system as for struct
:c:type:`v4l2_cropcap` ``bounds`` is used.
 
+.. note::
+   Unfortunately in the case of multiplanar buffer types
+   (``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and 
``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``)
+   this API was messed up with regards to how the :c:type:`v4l2_crop` ``type`` 
field
+   should be filled in. Some drivers only accepted the ``_MPLANE`` buffer type 

[PATCH 0/2] Fix G/S_SELECTION & CROPCAP/G/S_CROP buftype handling

[Hans Verkuil]

From: Hans Verkuil 

There is a lot of confusion about the correct buffer type to use
when calling the new selection and old crop APIs. Specifically whether
the _MPLANE variant of a buf type should be used or not if the device
is multi-planar. The spec said na, but that was unexpected to applications
and drivers actually did different things as well.

This patch series allows both to be used and updates the documentation
accordingly.

In the end, these APIs don't care whether it is a single or multiplanar
device, that information is irrelevant to these ioctls. So allowing
both is not unreasonable, especially given the mess we created.

The first patch is unchanged from the original RFC here:

https://patchwork.linuxtv.org/patch/41210/

The second patch was updated from this original RFC:

- the note was moved after the struct containing the 'type' field.
- kernel 4.12 was replaced with 4.14 (I'm assuming this will be too
  late for 4.13).
- The phrase 'The Samsung Exynos drivers' was replaced by 'Some drivers'.

Regards,

Hans

Hans Verkuil (2):
  v4l2-ioctl/exynos: fix G/S_SELECTION's type handling
  media/uapi/v4l: clarify cropcap/crop/selection behavior

 Documentation/media/uapi/v4l/vidioc-cropcap.rst| 23 ++
 Documentation/media/uapi/v4l/vidioc-g-crop.rst | 22 +
 .../media/uapi/v4l/vidioc-g-selection.rst  | 22 +
 drivers/media/platform/exynos-gsc/gsc-core.c   |  4 +-
 drivers/media/platform/exynos-gsc/gsc-m2m.c|  8 ++--
 drivers/media/platform/exynos4-is/fimc-capture.c   |  4 +-
 drivers/media/platform/exynos4-is/fimc-lite.c  |  4 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   | 53 +++---
 8 files changed, 95 insertions(+), 45 deletions(-)

-- 
2.11.0

[PATCH 1/2] v4l2-ioctl/exynos: fix G/S_SELECTION's type handling

[Hans Verkuil]

From: Hans Verkuil 

The type field in struct v4l2_selection is supposed to never use the
_MPLANE variants. E.g. if the driver supports 
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
then userspace should still pass V4L2_BUF_TYPE_VIDEO_CAPTURE.

The reasons for this are lost in the mists of time, but it is really
annoying. In addition, the exynos drivers didn't follow this rule and
instead expected the _MPLANE type.

To fix that code is added to the v4l2 core that maps the _MPLANE buffer
types to their regular equivalents before calling the driver.

Effectively this allows for userspace to use either _MPLANE or the regular
buffer type. This keeps backwards compatibility while making things easier
for userspace.

Since drivers now never see the _MPLANE buffer types the exynos drivers
had to be adapted as well.

Signed-off-by: Hans Verkuil 
Acked-by: Sakari Ailus 
---
 drivers/media/platform/exynos-gsc/gsc-core.c |  4 +-
 drivers/media/platform/exynos-gsc/gsc-m2m.c  |  8 ++--
 drivers/media/platform/exynos4-is/fimc-capture.c |  4 +-
 drivers/media/platform/exynos4-is/fimc-lite.c|  4 +-
 drivers/media/v4l2-core/v4l2-ioctl.c | 53 +---
 5 files changed, 57 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 0241168c85af..43801509dabb 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -568,9 +568,9 @@ int gsc_try_crop(struct gsc_ctx *ctx, struct v4l2_crop *cr)
}
pr_debug("user put w: %d, h: %d", cr->c.width, cr->c.height);
 
-   if (cr->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+   if (cr->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
f = >d_frame;
-   else if (cr->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+   else if (cr->type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
f = >s_frame;
else
return -EINVAL;
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c 
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 82505025d96c..33611a46ce35 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -460,8 +460,8 @@ static int gsc_m2m_g_selection(struct file *file, void *fh,
struct gsc_frame *frame;
struct gsc_ctx *ctx = fh_to_ctx(fh);
 
-   if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) &&
-   (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE))
+   if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) &&
+   (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
return -EINVAL;
 
frame = ctx_get_frame(ctx, s->type);
@@ -503,8 +503,8 @@ static int gsc_m2m_s_selection(struct file *file, void *fh,
cr.type = s->type;
cr.c = s->r;
 
-   if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) &&
-   (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE))
+   if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) &&
+   (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT))
return -EINVAL;
 
ret = gsc_try_crop(ctx, );
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
b/drivers/media/platform/exynos4-is/fimc-capture.c
index db60a63c0768..948fe01f6c96 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -1270,7 +1270,7 @@ static int fimc_cap_g_selection(struct file *file, void 
*fh,
struct fimc_ctx *ctx = fimc->vid_cap.ctx;
struct fimc_frame *f = >s_frame;
 
-   if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+   if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
 
switch (s->target) {
@@ -1322,7 +1322,7 @@ static int fimc_cap_s_selection(struct file *file, void 
*fh,
struct fimc_frame *f;
unsigned long flags;
 
-   if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+   if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
 
if (s->target == V4L2_SEL_TGT_COMPOSE)
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
b/drivers/media/platform/exynos4-is/fimc-lite.c
index b4c4a33784c4..7d3ec5cc6608 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -901,7 +901,7 @@ static int fimc_lite_g_selection(struct file *file, void 
*fh,
struct fimc_lite *fimc = video_drvdata(file);
struct flite_frame *f = >out_frame;
 
-   if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+   if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
 
switch (sel->target) {
@@ -929,7 +929,7 @@ static int fimc_lite_s_selection(struct file *file, void 
*fh,
struct v4l2_rect rect = sel->r;
unsigned long flags;
 
-   if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE ||
+   if 

[GIT PULL FOR v4.13] Various fixes/enhancements

[Hans Verkuil]

The following changes since commit acec3630155763c170c7ae6508cf973355464508:

  [media] s3c-camif: fix arguments position in a function call (2017-06-13 
14:21:24 -0300)

are available in the git repository at:

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

for you to fetch changes up to abb81a8cd3e779209887c5d757b104d0737be57b:

  s5p-cec: update MAINTAINERS entry (2017-06-19 14:21:04 +0200)


Kieran Bingham (1):
  media: fdp1: Support ES2 platforms

Marek Szyprowski (1):
  s5p-cec: update MAINTAINERS entry

Niklas Söderlund (3):
  v4l: async: check for v4l2_dev in v4l2_async_notifier_register()
  media: entity: Add get_fwnode_pad entity operation
  media: entity: Add media_entity_get_fwnode_pad() function

Tomasz Figa (1):
  v4l2-core: Use kvmalloc() for potentially big allocations

 MAINTAINERS|  7 ---
 drivers/media/media-entity.c   | 36 

 drivers/media/platform/rcar_fdp1.c | 10 +++---
 drivers/media/v4l2-core/v4l2-async.c   |  8 +---
 drivers/media/v4l2-core/v4l2-ctrls.c   | 26 ++
 drivers/media/v4l2-core/v4l2-event.c   |  8 +---
 drivers/media/v4l2-core/v4l2-ioctl.c   |  7 ---
 drivers/media/v4l2-core/v4l2-subdev.c  |  8 +---
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 
 include/media/media-entity.h   | 28 
 10 files changed, 112 insertions(+), 34 deletions(-)

[PATCH v2] s5p-cec: update MAINTAINERS entry

[Marek Szyprowski]

I would like to replace Kyungmin Park, who is no longer interested in
maintaining S5P-CEC driver. I have access to various Exynos boards. I also
already did some tests of this driver and helped enabling it on various
Exynos boards. The driver itself is no longer in staging, so lets fix the
path too and add DT bindings file pattern match. Also change the mailing
list from ARM generic to Samsung SoC specific to get more attention and
easier review in the future.

Signed-off-by: Marek Szyprowski 
Acked-by: Krzysztof Kozlowski 
---
v2:
- added DT bindings file as suggested by Krzysztof Kozlowski
---
 MAINTAINERS | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bdd1fe5..52e516376139 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1775,11 +1775,12 @@ F:  arch/arm/plat-samsung/s5p-dev-mfc.c
 F: drivers/media/platform/s5p-mfc/
 
 ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
-M: Kyungmin Park 
-L: linux-arm-ker...@lists.infradead.org
+M: Marek Szyprowski 
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 L: linux-media@vger.kernel.org
 S: Maintained
-F: drivers/staging/media/platform/s5p-cec/
+F: drivers/media/platform/s5p-cec/
+F: Documentation/devicetree/bindings/media/s5p-cec.txt
 
 ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
 M: Andrzej Pietrasiewicz 
-- 
1.9.1

[PATCH] s5p-cec: update MAINTAINERS entry

[Marek Szyprowski]

I would like to replace Kyungmin Park, who is no longer interested in
maintaining S5P-CEC driver. I have access to various Exynos boards. I also
already did some tests of this driver and helped enabling it on various
Exynos boards. The driver itself is no longer in staging, so lets fix the
path too. Also change the mailing list from ARM generic to Samsung SoC
specific to get more attention and easier review in the future.

Signed-off-by: Marek Szyprowski 
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bdd1fe5..fbfbc9866fa2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1775,11 +1775,11 @@ F:  arch/arm/plat-samsung/s5p-dev-mfc.c
 F: drivers/media/platform/s5p-mfc/
 
 ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
-M: Kyungmin Park 
-L: linux-arm-ker...@lists.infradead.org
+M: Marek Szyprowski 
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 L: linux-media@vger.kernel.org
 S: Maintained
-F: drivers/staging/media/platform/s5p-cec/
+F: drivers/media/platform/s5p-cec/
 
 ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
 M: Andrzej Pietrasiewicz 
-- 
1.9.1

Re: [PATCH 01/10] doc: DT: camss: Binding document for Qualcomm Camera subsystem driver

[Todor Tomov]

Hi Rob,

On 01/09/2017 04:33 PM, Todor Tomov wrote:
> Hi Rob,
> 
> Happy new year,
> And thank you for the review.
> 
> On 12/01/2016 12:03 AM, Rob Herring wrote:
>> On Fri, Nov 25, 2016 at 04:56:53PM +0200, Todor Tomov wrote:
>>> Add DT binding document for Qualcomm Camera subsystem driver.
>>>
>>> Signed-off-by: Todor Tomov 
>>> ---
>>>  .../devicetree/bindings/media/qcom,camss.txt   | 196 
>>> +
>>>  1 file changed, 196 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt 
>>> b/Documentation/devicetree/bindings/media/qcom,camss.txt
>>> new file mode 100644
>>> index 000..76ad89a
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
>>> @@ -0,0 +1,196 @@
>>> +Qualcomm Camera Subsystem
>>> +
>>> +* Properties
>>> +
>>> +- compatible:
>>> +   Usage: required
>>> +   Value type: 
>>> +   Definition: Should contain:
>>> +   - "qcom,8x16-camss"
>>
>> Don't use wildcards in compatible strings. One string per SoC.
> 
> Ok, I'll fix this.
> 
>>
>>> +- reg:
>>> +   Usage: required
>>> +   Value type: 
>>> +   Definition: Register ranges as listed in the reg-names property.
>>> +- reg-names:
>>> +   Usage: required
>>> +   Value type: 
>>> +   Definition: Should contain the following entries:
>>> +   - "csiphy0"
>>> +   - "csiphy0_clk_mux"
>>> +   - "csiphy1"
>>> +   - "csiphy1_clk_mux"
>>> +   - "csid0"
>>> +   - "csid1"
>>> +   - "ispif"
>>> +   - "csi_clk_mux"
>>> +   - "vfe0"
>>
>> Kind of looks like the phy's should be separate nodes since each phy has 
>> its own register range, irq, clocks, etc.
> 
> Yes, there are a lot of hardware resources here.
> I have decided to keep everything into a single platform device as this
> represents it better from system point of view.
> 

Following this patch,
- following the short discussion which we had on Linaro Connect,
- following some evaluation of the possibilities,
I'd like to try to keep it as a single node. Some of the resources are separate
and so appear to be the clocks too but actually there are dependencies across 
the
hardware modules for clocks of their adjacent modules. In addition there
are configuration dependencies across the hardware modules - e.g. on a CSID 
module
a CSIPHY module's id needs to be set (and vice-versa), on a CSID module the
csi lane positions need to be set and so on. So I think a single driver to
handle this (and thus a single dt node) makes more sense. I'm preparing a
v2 of the patch set and will send it shortly.

-- 
Best regards,
Todor Tomov

Re: [PATCH v7 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Hans Verkuil]

On 06/12/2017 04:48 PM, Niklas Söderlund wrote:

Hi Hans,

Thanks for your comments.

On 2017-05-29 13:16:23 +0200, Hans Verkuil wrote:

On 05/24/2017 02:13 AM, Niklas Söderlund wrote:

From: Niklas Söderlund 

A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
hardware blocks are connected between the video sources and the video
grabbers (VIN).

Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.

Signed-off-by: Niklas Söderlund 
---
   drivers/media/platform/rcar-vin/Kconfig |  12 +
   drivers/media/platform/rcar-vin/Makefile|   1 +
   drivers/media/platform/rcar-vin/rcar-csi2.c | 867 

   3 files changed, 880 insertions(+)
   create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c




+static int rcar_csi2_registered(struct v4l2_subdev *sd)
+{
+   struct rcar_csi2 *priv = container_of(sd, struct rcar_csi2, subdev);
+   struct v4l2_async_subdev **subdevs = NULL;
+   int ret;
+
+   subdevs = devm_kzalloc(priv->dev, sizeof(*subdevs), GFP_KERNEL);
+   if (subdevs == NULL)
+   return -ENOMEM;
+
+   subdevs[0] = >remote.asd;
+
+   priv->notifier.num_subdevs = 1;
+   priv->notifier.subdevs = subdevs;
+   priv->notifier.bound = rcar_csi2_notify_bound;
+   priv->notifier.unbind = rcar_csi2_notify_unbind;
+   priv->notifier.complete = rcar_csi2_notify_complete;
+
+   ret = v4l2_async_subnotifier_register(>subdev, >notifier);
+   if (ret < 0) {
+   dev_err(priv->dev, "Notifier registration failed\n");
+   return ret;
+   }
+
+   return 0;
+}


Hmm, I'm trying to understand this, and I got one question. There are at least
two complete callbacks: rcar_csi2_notify_complete and the bridge driver's
complete callback. Am I right that the bridge driver's complete callback is
called as soon as this function exists (assuming this is the only subdev)?


Yes (at least for the async case).

In v4l2_async_test_notify() calls v4l2_device_register_subdev() which in
turns calls this registered callback. v4l2_async_test_notify() then go
on and calls the notifiers complete callback.

In my case I have (in the simplified case) AD7482 -> CSI-2 -> VIN. Where
VIN is the video device and CSI-2 is the subdevice of VIN while the
ADV7482 is a subdevice to the CSI-2. In that case the call graph would
be:

v4l2_async_test_notify()(From VIN on the CSI-2 subdev)
   v4l2_device_register_subdev()
 sd->internal_ops->registered(sd);   (sd == CSI-2 subdev)
   v4l2_async_subnotifier_register() (CSI-2 notifier for the ADV7482 subdev)
 v4l2_async_test_notify()(From CSI-2 on the ADV7482) [1]
   notifier->complete(notifier); (on the notifier from VIN)



So the bridge driver thinks it is complete when in reality this subdev may
be waiting on newly registered subdevs?


Yes if the ADV7482 subdevice are not already registered in [1] above the
VIN complete callback would be called before the complete callback have
been called on the notifier register from the CSI-2 registered callback.
Instead that would be called once the ADV7482 calls
v4l2_async_register_subdev().



If I am right, then my question is if that is what we want. If I am wrong,
then what did I miss?


I think that is what we want?

 From the VIN point of view all the subdevices it registered in it's
notifier have been found and bound right so I think it's correct to call
the complete callback for that notifier at this point?  If it really
cared about that all devices be present before it calls it complete
callback should it not also add all devices to its own notifier list?

But I do see your point that the VIN really have no way of telling if
all devices are present and we are ready to start to stream. This
however will be found out with a -EPIPE error if a stream is tried to be
started since the CSI-2 driver will fail to verify the pipeline since it
have no subdevice attached to its source pad. What do you think?


I think this is a bad idea. From the point of view of the application you
expect that once the device nodes appear they will also *work*. In this
case it might not work because one piece is still missing. So applications
would have to know that if they get -EPIPE, then if they wait for a few
seconds it might suddenly work because the last component was finally
loaded. That's IMHO not acceptable and will drive application developers
crazy.

In the example above the CSI-2 subdev can't tell VIN that it is complete
when it is still waiting for the ADV7482. Because it *isn't* complete.

It is also unexpected: if A depends on B and B depends on C and D, then
you expect that B won't tell A that is it ready unless C and D are both
loaded.

I was planning to merge this patch today: 
https://patchwork.linuxtv.org/patch/41834/

But 

Re: [PATCH 1/6] v4l: vsp1: Remove WPF vertical flip support on VSP2-B[CD] and VSP2-D

[Hans Verkuil]

On 06/19/2017 01:16 PM, Laurent Pinchart wrote:

Hi Hans,

On Thursday 15 Jun 2017 10:53:33 Hans Verkuil wrote:

On 06/15/17 10:24, Laurent Pinchart wrote:

The WPF vertical flip is only supported on Gen3 SoCs on the VSP2-I.
Don't enable it on other VSP2 instances.

Signed-off-by: Laurent Pinchart



Should this go to older kernels as well? Or is that not needed?


Now that I have access to the hardware again, after further testing, it looks
like vertical flip is implemented in the VSP2-B[CD] and VSP2-D even though the
datasheet states otherwise. Let's ignore this patch for now, I'll try to
double-check with Renesas.


Patches 2-6 are OK, though? If they are, then I'll pick them up.

I've delegated this patch to you, just 'undelegate' it or reject it once you 
know
what should be done with this patch.

Regards,

Hans




---

  drivers/media/platform/vsp1/vsp1_drv.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c index 048446af5ae7..239996cf882e
100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -690,7 +690,7 @@ static const struct vsp1_device_info
vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPBD_GEN3,
.model = "VSP2-BD",
.gen = 3,
-   .features = VSP1_HAS_BRU | VSP1_HAS_WPF_VFLIP,
+   .features = VSP1_HAS_BRU,
.rpf_count = 5,
.wpf_count = 1,
.num_bru_inputs = 5,
@@ -700,7 +700,7 @@ static const struct vsp1_device_info
vsp1_device_infos[] = {
.model = "VSP2-BC",
.gen = 3,
.features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
- | VSP1_HAS_LUT | VSP1_HAS_WPF_VFLIP,
+ | VSP1_HAS_LUT,
.rpf_count = 5,
.wpf_count = 1,
.num_bru_inputs = 5,
@@ -709,7 +709,7 @@ static const struct vsp1_device_info
vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
.model = "VSP2-D",
.gen = 3,
-   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP,
+   .features = VSP1_HAS_BRU | VSP1_HAS_LIF,
.rpf_count = 5,
.wpf_count = 2,
.num_bru_inputs = 5,

Re: [PATCH 1/6] v4l: vsp1: Remove WPF vertical flip support on VSP2-B[CD] and VSP2-D

[Laurent Pinchart]

Hi Hans,

On Thursday 15 Jun 2017 10:53:33 Hans Verkuil wrote:
> On 06/15/17 10:24, Laurent Pinchart wrote:
> > The WPF vertical flip is only supported on Gen3 SoCs on the VSP2-I.
> > Don't enable it on other VSP2 instances.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> Should this go to older kernels as well? Or is that not needed?

Now that I have access to the hardware again, after further testing, it looks 
like vertical flip is implemented in the VSP2-B[CD] and VSP2-D even though the 
datasheet states otherwise. Let's ignore this patch for now, I'll try to 
double-check with Renesas.

> > ---
> > 
> >  drivers/media/platform/vsp1/vsp1_drv.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
> > b/drivers/media/platform/vsp1/vsp1_drv.c index 048446af5ae7..239996cf882e
> > 100644
> > --- a/drivers/media/platform/vsp1/vsp1_drv.c
> > +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> > @@ -690,7 +690,7 @@ static const struct vsp1_device_info
> > vsp1_device_infos[] = { 
> > .version = VI6_IP_VERSION_MODEL_VSPBD_GEN3,
> > .model = "VSP2-BD",
> > .gen = 3,
> > -   .features = VSP1_HAS_BRU | VSP1_HAS_WPF_VFLIP,
> > +   .features = VSP1_HAS_BRU,
> > .rpf_count = 5,
> > .wpf_count = 1,
> > .num_bru_inputs = 5,
> > @@ -700,7 +700,7 @@ static const struct vsp1_device_info
> > vsp1_device_infos[] = { 
> > .model = "VSP2-BC",
> > .gen = 3,
> > .features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO
> > - | VSP1_HAS_LUT | VSP1_HAS_WPF_VFLIP,
> > + | VSP1_HAS_LUT,
> > .rpf_count = 5,
> > .wpf_count = 1,
> > .num_bru_inputs = 5,
> > @@ -709,7 +709,7 @@ static const struct vsp1_device_info
> > vsp1_device_infos[] = { 
> > .version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
> > .model = "VSP2-D",
> > .gen = 3,
> > -   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP,
> > +   .features = VSP1_HAS_BRU | VSP1_HAS_LIF,
> > .rpf_count = 5,
> > .wpf_count = 2,
> > .num_bru_inputs = 5,

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2] [media] v4l2: add V4L2_CAP_IO_MC

[Hans Verkuil]

On 06/14/2017 06:50 AM, Helen Koike wrote:

Add V4L2_CAP_IO_MC to be used in struct v4l2_capability to indicate that
input and output are controlled by the Media Controller instead of V4L2
API.
When this flag is set, ioctls for get, set and enum input and outputs
are automatically enabled and programmed to call helper function.

Signed-off-by: Helen Koike 

---

Changes in v2::
- replace the type by capability
- erase V4L2_INPUT_TYPE_DEFAULT
- also consider output
- plug helpers in the ops automatically so drivers doesn't need
to set it by hand
- update docs
- commit message and title
---
  Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 +
  Documentation/media/videodev2.h.rst.exceptions   |  1 +
  drivers/media/v4l2-core/v4l2-dev.c   | 35 +++--
  drivers/media/v4l2-core/v4l2-ioctl.c | 91 ++--
  include/uapi/linux/videodev2.h   |  2 +
  5 files changed, 120 insertions(+), 12 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 12e0d9a..2bd1223 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -252,6 +252,9 @@ specification the ioctl returns an ``EINVAL`` error code.
  * - ``V4L2_CAP_TOUCH``
- 0x1000
- This is a touch device.
+* - ``V4L2_CAP_IO_MC``
+  - 0x2000
+  - This device has its inputs and outputs controller by the Media 
Controller


controller -> controlled

But I would rephrase this a bit:

- The inputs and/or outputs of this device are controlled by the Media 
Controller
  (see: ).


  * - ``V4L2_CAP_DEVICE_CAPS``
- 0x8000
- The driver fills the ``device_caps`` field. This capability can
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8..0b48cd0 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -159,6 +159,7 @@ replace define V4L2_CAP_ASYNCIO device-capabilities
  replace define V4L2_CAP_STREAMING device-capabilities
  replace define V4L2_CAP_DEVICE_CAPS device-capabilities
  replace define V4L2_CAP_TOUCH device-capabilities
+replace define V4L2_CAP_IO_MC device-capabilities
  
  # V4L2 pix flags

  replace define V4L2_PIX_FMT_PRIV_MAGIC :c:type:`v4l2_pix_format`
diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index c647ba6..0f272fe 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -688,22 +688,34 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_G_STD, vidioc_g_std);
if (is_rx) {
SET_VALID_IOCTL(ops, VIDIOC_QUERYSTD, vidioc_querystd);
-   SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT, 
vidioc_enum_input);
-   SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, vidioc_g_input);
-   SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, vidioc_s_input);
SET_VALID_IOCTL(ops, VIDIOC_ENUMAUDIO, 
vidioc_enumaudio);
SET_VALID_IOCTL(ops, VIDIOC_G_AUDIO, vidioc_g_audio);
SET_VALID_IOCTL(ops, VIDIOC_S_AUDIO, vidioc_s_audio);
SET_VALID_IOCTL(ops, VIDIOC_QUERY_DV_TIMINGS, 
vidioc_query_dv_timings);
SET_VALID_IOCTL(ops, VIDIOC_S_EDID, vidioc_s_edid);
+   if (vdev->device_caps & V4L2_CAP_IO_MC) {
+   set_bit(_IOC_NR(VIDIOC_ENUMINPUT), 
valid_ioctls);
+   set_bit(_IOC_NR(VIDIOC_G_INPUT), valid_ioctls);
+   set_bit(_IOC_NR(VIDIOC_S_INPUT), valid_ioctls);
+   } else {
+   SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT, 
vidioc_enum_input);
+   SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, 
vidioc_g_input);
+   SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, 
vidioc_s_input);
+   }
}
if (is_tx) {
-   SET_VALID_IOCTL(ops, VIDIOC_ENUMOUTPUT, 
vidioc_enum_output);
-   SET_VALID_IOCTL(ops, VIDIOC_G_OUTPUT, vidioc_g_output);
-   SET_VALID_IOCTL(ops, VIDIOC_S_OUTPUT, vidioc_s_output);
SET_VALID_IOCTL(ops, VIDIOC_ENUMAUDOUT, 
vidioc_enumaudout);
SET_VALID_IOCTL(ops, VIDIOC_G_AUDOUT, vidioc_g_audout);
SET_VALID_IOCTL(ops, VIDIOC_S_AUDOUT, vidioc_s_audout);
+   if (vdev->device_caps & V4L2_CAP_IO_MC) {
+   set_bit(_IOC_NR(VIDIOC_ENUMOUTPUT), 
valid_ioctls);
+   

Re: [PATCH] [media] ov2640: make GPIOLIB an optional dependency

[Pavel Machek]

Hi!

> I'm dropping this from patchwork since this no longer applies now that ov2640
> has been moved out of soc_camera.
> 
> If you still want this (it is a reasonable patch), then please
> respin.

If I'm not mistaken, equivalent fix is already in
drivers/media/i2c/ov2640.c .

Thanks,
Pavel

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


signature.asc
Description: Digital signature

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

[Tomasz Figa]

Hi Laurent,

Thanks for looking at this!

On Mon, Jun 19, 2017 at 6:17 PM, Laurent Pinchart
 wrote:
> Hi Tomasz,
>
> On Friday 16 Jun 2017 17:35:52 Tomasz Figa wrote:
>> On Fri, Jun 16, 2017 at 5:25 PM, Sakari Ailus wrote:
>> > On Fri, Jun 16, 2017 at 02:52:07PM +0900, Tomasz Figa wrote:
>> >> On Tue, Jun 6, 2017 at 7:09 PM, Tomasz Figa wrote:
>> >>> On Tue, Jun 6, 2017 at 5:04 PM, Hans Verkuil wrote:
>>  On 06/06/17 09:25, Sakari Ailus wrote:
>> > On Tue, Jun 06, 2017 at 01:30:41PM +0900, Tomasz Figa wrote:
>> >> On Tue, Jun 6, 2017 at 1:30 PM, Tomasz Figa wrote:
>> >>> On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote:
>>  Add the IPU3 specific processing parameter format
>>  V4L2_META_FMT_IPU3_PARAMS and metadata formats
>>  for 3A and other statistics:
>> >>>
>> >>> Please see my comments inline.
>> >>>
>>    V4L2_META_FMT_IPU3_PARAMS
>>    V4L2_META_FMT_IPU3_STAT_3A
>>    V4L2_META_FMT_IPU3_STAT_DVS
>>    V4L2_META_FMT_IPU3_STAT_LACE
>> 
>>  Signed-off-by: Yong Zhi 
>>  ---
>> 
>>   drivers/media/v4l2-core/v4l2-ioctl.c | 4 
>>   include/uapi/linux/videodev2.h   | 6 ++
>>   2 files changed, 10 insertions(+)
>> >>>
>> >>> [snip]
>> >>>
>>  +/* Vendor specific - used for IPU3 camera sub-system */
>>  +#define V4L2_META_FMT_IPU3_PARAMS  v4l2_fourcc('i', 'p', '3',
>>  'p') /* IPU3 params */
>>  +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3',
>>  's') /* IPU3 3A statistics */
>>  +#define V4L2_META_FMT_IPU3_STAT_DVSv4l2_fourcc('i', 'p', '3',
>>  'd') /* IPU3 DVS statistics */
>>  +#define V4L2_META_FMT_IPU3_STAT_LACE   v4l2_fourcc('i', 'p', '3',
>>  'l') /* IPU3 LACE statistics */
>
> This series is missing a documentation patch with a clear and detailed
> description of the buffer contents for each of these formats. I'm not very
> concerned about the three statistics formats (although that might change after
> reading the documentation), but the "IPU3 params" format makes me feel nervous
> already.

I guess this is a note addressed to patch authors. :)

>
>> >>> We had some discussion about this with Laurent and if I remember
>> >>> correctly, the conclusion was that it might make sense to define
>> >>> one FourCC for a vendor specific format, ('v', 'n', 'd', 'r') for
>> >>> example, and then have a V4L2-specific enum within the
>> >>> v4l2_pix_format(_mplane) struct that specifies the exact vendor data
>> >>> type.
>
> If I recall correctly, I mentioned that v4l2_format now has a struct
> v4l2_meta_format field that can be used to pass metadata-related parameters
> the same way that v4l2_pix_format passes image-related parameters. The only
> two metadata parameters currently defined are the data format (fourcc) and
> buffer size, and more can be added if needed. However, I don't think the
> v4l2_meta_format structure should be extended with vendor-specific fields.

Ah, then I got that wrong, sorry. But in general I believe we reached
exactly the same conclusion with Hans and Sakari after that.

Best regards,
Tomasz

Re: [PATCH v2] [media] mtk-mdp: Fix g_/s_selection capture/compose logic

[Hans Verkuil]

On 06/19/2017 12:03 PM, Minghsiu Tsai wrote:

Hi, Hans,

On Fri, 2017-06-16 at 12:42 +0200, Hans Verkuil wrote:

On 05/12/17 04:42, Minghsiu Tsai wrote:

From: Daniel Kurtz 

Experiments show that the:
  (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT


Please drop this, since this no longer applies to this patch.



I will remove it next version



  (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets


Are you really certain about this?

For m2m devices the output (i.e. memory to hardware) typically crops from memory
and the capture side (hardware to memory) composes into memory.

I.e.: for the output side you crop the part of the memory buffer that you want
to process and on the capture side you compose the result into a memory buffer:
i.e. the memory buffer might be 1920x1080, but you compose the decoder output
into a rectangle of 640x480 at offset 128x128 within that buffer (just an 
example).

CAPTURE using crop would be if, before the data is DMAed, the hardware decoder
output is cropped. E.g. if the stream fed to the decoder is 1920x1080, but you
want to only DMA a subselection of that, then that would be cropping, and it
would go to a memory buffer of the size of the crop selection.

OUTPUT using compose is highly unlikely: that means that the frame you give
is composed in a larger internal buffer with generated border data around it.
Very rare and really only something that a compositor of some sort would do.



That's strange. In v4l2-ioctl.c, v4l_g_crop()
OUTPUT is using COMPOSE
CAPTURE is using CROP


The old crop API can't be used with most (all?) codec drivers. Codec drivers do
exactly the opposite of what the old crop API did.

It is the reason the selection API was created.

The old crop API was written for SDTV receivers where the hardware would crop
the received video. For output (rarely used) the hardware would compose the
image into a larger (PAL or NTSC sizes) frame.

Applications have to use the selection API to work with codec drivers. Just
ignore the old crop ioctls, they are not suitable for such hardware.



static int v4l_g_crop(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
...
/* crop means compose for output devices */
if (V4L2_TYPE_IS_OUTPUT(p->type))
s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
else
s.target = V4L2_SEL_TGT_CROP_ACTIVE;

ret = ops->vidioc_g_selection(file, fh, );



What exactly does the hardware do? Both for the encoder and for the decoder
case. Perhaps if I knew exactly what that is, then I can advise.



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

The usage would be like this:
For decoder:
decoder -> MT21 -> MDP -> NV12M/YUV420M

For encoder:
NV12M/YUV420M -> MDP -> NV12M/YUV420M -> encoder


That doesn't help. Where in these two chains does the cropping (encoder) or
composing (decoder) take place? I assume it is the DMA engine that read from
a rectangle in the source buffer (encoder) or writes to a rectangle in the
destination buffer (decoder).

And in that case the current driver is correct.

I wonder if the g/s_crop description in the V4L2 Specification should get a
big fat warning that it doesn't apply to codec drivers and that the selection
API should be used instead. A patch for that is welcome!

Regards,

Hans

Re: [PATCH v2] [media] mtk-mdp: Fix g_/s_selection capture/compose logic

[Minghsiu Tsai]

Hi, Hans,

On Fri, 2017-06-16 at 12:42 +0200, Hans Verkuil wrote:
> On 05/12/17 04:42, Minghsiu Tsai wrote:
> > From: Daniel Kurtz 
> > 
> > Experiments show that the:
> >  (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
> 
> Please drop this, since this no longer applies to this patch.
> 

I will remove it next version


> >  (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
> 
> Are you really certain about this?
> 
> For m2m devices the output (i.e. memory to hardware) typically crops from 
> memory
> and the capture side (hardware to memory) composes into memory.
> 
> I.e.: for the output side you crop the part of the memory buffer that you want
> to process and on the capture side you compose the result into a memory 
> buffer:
> i.e. the memory buffer might be 1920x1080, but you compose the decoder output
> into a rectangle of 640x480 at offset 128x128 within that buffer (just an 
> example).
> 
> CAPTURE using crop would be if, before the data is DMAed, the hardware decoder
> output is cropped. E.g. if the stream fed to the decoder is 1920x1080, but you
> want to only DMA a subselection of that, then that would be cropping, and it
> would go to a memory buffer of the size of the crop selection.
> 
> OUTPUT using compose is highly unlikely: that means that the frame you give
> is composed in a larger internal buffer with generated border data around it.
> Very rare and really only something that a compositor of some sort would do.
> 

That's strange. In v4l2-ioctl.c, v4l_g_crop()
OUTPUT is using COMPOSE
CAPTURE is using CROP

static int v4l_g_crop(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
...
/* crop means compose for output devices */
if (V4L2_TYPE_IS_OUTPUT(p->type))
s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
else
s.target = V4L2_SEL_TGT_CROP_ACTIVE;

ret = ops->vidioc_g_selection(file, fh, );


> What exactly does the hardware do? Both for the encoder and for the decoder
> case. Perhaps if I knew exactly what that is, then I can advise.
> 

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

The usage would be like this:
For decoder:
decoder -> MT21 -> MDP -> NV12M/YUV420M

For encoder:
NV12M/YUV420M -> MDP -> NV12M/YUV420M -> encoder



> Regards,
> 
>   Hans
> 

Re: [PATCH] [media] ov2640: make GPIOLIB an optional dependency

[Hans Verkuil]

Hi Pavel,

I'm dropping this from patchwork since this no longer applies now that ov2640
has been moved out of soc_camera.

If you still want this (it is a reasonable patch), then please respin.

Regards,

Hans

On 04/21/2017 08:33 AM, Pavel Machek wrote:

Hi!


Better solution would be for VIDEO_EM28XX_V4L2 to depend on GPIOLIB,
too, no? If not, should there be BUG_ON(priv->pwdn_gpio);
BUG_ON(priv->resetb_gpio);?


Pavel,

The em28xx driver was added upstream several years the gpio driver.
It controls GPIO using a different logic. It makes no sense to make
it dependent on GPIOLIB, except if someone converts it to use it.


At least comment in the sourcecode...? Remove pwdn_gpio fields from
structure in !GPIOLIB case, because otherwise they are trap for the
programmer trying to understand what is going on?

Plus, something like this, because otherwise it is quite confusing?

Thanks,
Pavel

diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
b/drivers/media/i2c/soc_camera/ov2640.c
index 56de182..85620e1 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -1060,7 +1060,7 @@ static int ov2640_hw_reset(struct device *dev)
/* Active the resetb pin to perform a reset pulse */
gpiod_direction_output(priv->resetb_gpio, 1);
usleep_range(3000, 5000);
-   gpiod_direction_output(priv->resetb_gpio, 0);
+   gpiod_set_value(priv->resetb_gpio, 0);
}
  
  	return 0;

Re: [PATCH v2] media: fdp1: Support ES2 platforms

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Monday 12 Jun 2017 11:30:16 Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The new Renesas R-Car H3 ES2.0 platforms have a new hw version register.
> Update the driver accordingly, defaulting to the new hw revision, and
> differentiating the older revision as ES1
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar_fdp1.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar_fdp1.c
> b/drivers/media/platform/rcar_fdp1.c index 42f25d241edd..159786b052f3
> 100644
> --- a/drivers/media/platform/rcar_fdp1.c
> +++ b/drivers/media/platform/rcar_fdp1.c
> @@ -258,8 +258,9 @@ MODULE_PARM_DESC(debug, "activate debug info");
> 
>  /* Internal Data (HW Version) */
>  #define FD1_IP_INTDATA   0x0800
> -#define FD1_IP_H30x02010101
> +#define FD1_IP_H3_ES10x02010101
>  #define FD1_IP_M3W   0x02010202
> +#define FD1_IP_H30x02010203
> 
>  /* LUTs */
>  #define FD1_LUT_DIF_ADJ  0x1000
> @@ -2359,12 +2360,15 @@ static int fdp1_probe(struct platform_device *pdev)
> 
>   hw_version = fdp1_read(fdp1, FD1_IP_INTDATA);
>   switch (hw_version) {
> - case FD1_IP_H3:
> - dprintk(fdp1, "FDP1 Version R-Car H3\n");
> + case FD1_IP_H3_ES1:
> + dprintk(fdp1, "FDP1 Version R-Car H3 ES1\n");
>   break;
>   case FD1_IP_M3W:
>   dprintk(fdp1, "FDP1 Version R-Car M3-W\n");
>   break;
> + case FD1_IP_H3:
> + dprintk(fdp1, "FDP1 Version R-Car H3\n");
> + break;
>   default:
>   dev_err(fdp1->dev, "FDP1 Unidentifiable (0x%08x)\n",
>   hw_version);

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Jose Abreu]

Hi Sylwester,


Thanks again for the feedback!


On 18-06-2017 19:04, Sylwester Nawrocki wrote:
> On 06/16/2017 06:38 PM, Jose Abreu wrote:
>> This is an initial submission for the Synopsys Designware HDMI RX
>> Controller Driver. This driver interacts with a phy driver so that
>> a communication between them is created and a video pipeline is
>> configured.
>>
>> The controller + phy pipeline can then be integrated into a fully
>> featured system that can be able to receive video up to 4k@60Hz
>> with deep color 48bit RGB, depending on the platform. Although,
>> this initial version does not yet handle deep color modes.
>> Signed-off-by: Jose Abreu 
>> +static int dw_hdmi_phy_init(struct dw_hdmi_dev *dw_dev)
>> +{
>> +struct dw_phy_pdata *phy = _dev->phy_config;
>> +struct platform_device_info pdevinfo;
>> +
>> +memset(, 0, sizeof(pdevinfo));
>> +
>> +phy->funcs = _hdmi_phy_funcs;
>> +phy->funcs_arg = dw_dev;
>> +
>> +pdevinfo.parent = dw_dev->dev;
>> +pdevinfo.id = PLATFORM_DEVID_NONE;
>> +pdevinfo.name = dw_dev->phy_drv;
>> +pdevinfo.data = phy;
>> +pdevinfo.size_data = sizeof(*phy);
>> +pdevinfo.dma_mask = DMA_BIT_MASK(32);
>> +
>> +request_module(pdevinfo.name);
>> +
>> +dw_dev->phy_pdev = platform_device_register_full();
>> +if (IS_ERR(dw_dev->phy_pdev)) {
>> +dev_err(dw_dev->dev, "failed to register phy device\n");
>> +return PTR_ERR(dw_dev->phy_pdev);
>> +}
>> +
>> +if (!dw_dev->phy_pdev->dev.driver) {
>> +dev_err(dw_dev->dev, "failed to initialize phy driver\n");
>> +goto err;
>> +}
> I think this is not safe because there is nothing preventing unbinding 
> or unloading the driver at this point.
>
>> +if (!try_module_get(dw_dev->phy_pdev->dev.driver->owner)) {
> So dw_dev->phy_pdev->dev.driver may be already NULL here.

How can I make sure it wont be NULL? Because I've seen other
media drivers do this and I don't think they do any kind of
locking, but they do this mainly for I2C subdevs.

>
>> +dev_err(dw_dev->dev, "failed to get phy module\n");
>> +goto err;
>> +}
>> +
>> +dw_dev->phy_sd = dev_get_drvdata(_dev->phy_pdev->dev);
>> +if (!dw_dev->phy_sd) {
>> +dev_err(dw_dev->dev, "failed to get phy subdev\n");
>> +goto err_put;
>> +}
>> +
>> +if (v4l2_device_register_subdev(_dev->v4l2_dev, dw_dev->phy_sd)) {
>> +dev_err(dw_dev->dev, "failed to register phy subdev\n");
>> +goto err_put;
>> +}
> I'd suggest usign v4l2-async API, so we use a common pattern for sub-device
> registration.  And with recent change [1] you could handle this PHY subdev
> in a standard way.  That might be more complicated than it is now but should 
> make any future platform integration easier.
>
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.linuxtv.org_patch_41834=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=uHTyp6WsEj6vN19Zc09HqSNUhCx62OI8u-tAgi-EVts=WjyPjIwN1uGvPoV7ZlcmzOgdptakzluHywuKRA8ZG8M=
>  

So I will instantiate phy driver and then wait for phy driver to
register into v4l2 core?

>
>> +module_put(dw_dev->phy_pdev->dev.driver->owner);
>> +return 0;
>> +
>> +err_put:
>> +module_put(dw_dev->phy_pdev->dev.driver->owner);
>> +err:
>> +platform_device_unregister(dw_dev->phy_pdev);
>> +return -EINVAL;
>> +}
>> +
>> +static void dw_hdmi_phy_exit(struct dw_hdmi_dev *dw_dev)
>> +{
>> +if (!IS_ERR(dw_dev->phy_pdev))
>> +platform_device_unregister(dw_dev->phy_pdev);
>> +}
>> +static int dw_hdmi_config_hdcp(struct dw_hdmi_dev *dw_dev)
>> +{
>> +for (i = 0; i < DW_HDMI_HDCP14_KEYS_SIZE; i += 2) {
>> +for (j = 0; j < key_write_tries; j++) {
>> +if (is_hdcp14_key_write_allowed(dw_dev))
>> +break;
>> +mdelay(10);
> usleep_range()? I've seen more (busy waiting) mdelay() calls in this
> patch series.

I will change.

>
>
>> +static int __dw_hdmi_power_on(struct dw_hdmi_dev *dw_dev, u32 input)
>> +{
>> +unsigned long flags;
>> +int ret;
>> +
>> +ret = dw_hdmi_config(dw_dev, input);
>> +
>> +spin_lock_irqsave(_dev->lock, flags);
>> +dw_dev->pending_config = false;
>> +spin_unlock_irqrestore(_dev->lock, flags);
>> +
>> +return ret;
>> +}
>> +
>> +struct dw_hdmi_work_data {
>> +struct dw_hdmi_dev *dw_dev;
>> +struct work_struct work;
>> +u32 input;
>> +};
>> +
>> +static void dw_hdmi_work_handler(struct work_struct *work)
>> +{
>> +struct dw_hdmi_work_data *data = container_of(work,
>> +struct dw_hdmi_work_data, work);
>> +
>> +__dw_hdmi_power_on(data->dw_dev, data->input);
>> +devm_kfree(data->dw_dev->dev, data);
>> +}
>> +
>> +static int dw_hdmi_power_on(struct dw_hdmi_dev *dw_dev, u32 input)
>> +{
>> +struct dw_hdmi_work_data *data;
>> +unsigned 

Re: [RFC PATCH 2/2] media/uapi/v4l: clarify cropcap/crop/selection behavior

[Sylwester Nawrocki]

Hi Hans,

On 06/19/2017 09:35 AM, Hans Verkuil wrote:


diff --git a/Documentation/media/uapi/v4l/vidioc-cropcap.rst 
b/Documentation/media/uapi/v4l/vidioc-cropcap.rst
index f21a69b554e1..d354216846e6 100644
--- a/Documentation/media/uapi/v4l/vidioc-cropcap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-cropcap.rst
@@ -39,16 +39,19 @@ structure. Drivers fill the rest of the structure. The 
results are
   constant except when switching the video standard. Remember this switch
   can occur implicit when switching the video input or output.
   
-Do not use the multiplanar buffer types. Use

-``V4L2_BUF_TYPE_VIDEO_CAPTURE`` instead of
-``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and use
-``V4L2_BUF_TYPE_VIDEO_OUTPUT`` instead of
-``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``.
-
   This ioctl must be implemented for video capture or output devices that
   support cropping and/or scaling and/or have non-square pixels, and for
   overlay devices.
   
+.. note::

+   Unfortunately in the case of multiplanar buffer types
+   (``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and 
``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``)
+   this API was messed up with regards to how the :c:type:`v4l2_cropcap` 
``type`` field
+   should be filled in. The Samsung Exynos drivers only accepted the


I propose I change this to "Some drivers only..." here and at the other places I
refer to Exynos.

Do you agree?


Yes, perhaps we could move the note paragraphs on the G_CROP,
G_SELECTION pages after v4l2_crop, v4l2_selection tables?

--
Regards,
Sylwester

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

[Laurent Pinchart]

Hi Tomasz,

On Friday 16 Jun 2017 17:35:52 Tomasz Figa wrote:
> On Fri, Jun 16, 2017 at 5:25 PM, Sakari Ailus wrote:
> > On Fri, Jun 16, 2017 at 02:52:07PM +0900, Tomasz Figa wrote:
> >> On Tue, Jun 6, 2017 at 7:09 PM, Tomasz Figa wrote:
> >>> On Tue, Jun 6, 2017 at 5:04 PM, Hans Verkuil wrote:
>  On 06/06/17 09:25, Sakari Ailus wrote:
> > On Tue, Jun 06, 2017 at 01:30:41PM +0900, Tomasz Figa wrote:
> >> On Tue, Jun 6, 2017 at 1:30 PM, Tomasz Figa wrote:
> >>> On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote:
>  Add the IPU3 specific processing parameter format
>  V4L2_META_FMT_IPU3_PARAMS and metadata formats
>  for 3A and other statistics:
> >>>
> >>> Please see my comments inline.
> >>> 
>    V4L2_META_FMT_IPU3_PARAMS
>    V4L2_META_FMT_IPU3_STAT_3A
>    V4L2_META_FMT_IPU3_STAT_DVS
>    V4L2_META_FMT_IPU3_STAT_LACE
>  
>  Signed-off-by: Yong Zhi 
>  ---
>  
>   drivers/media/v4l2-core/v4l2-ioctl.c | 4 
>   include/uapi/linux/videodev2.h   | 6 ++
>   2 files changed, 10 insertions(+)
> >>> 
> >>> [snip]
> >>> 
>  +/* Vendor specific - used for IPU3 camera sub-system */
>  +#define V4L2_META_FMT_IPU3_PARAMS  v4l2_fourcc('i', 'p', '3',
>  'p') /* IPU3 params */
>  +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3',
>  's') /* IPU3 3A statistics */
>  +#define V4L2_META_FMT_IPU3_STAT_DVSv4l2_fourcc('i', 'p', '3',
>  'd') /* IPU3 DVS statistics */
>  +#define V4L2_META_FMT_IPU3_STAT_LACE   v4l2_fourcc('i', 'p', '3',
>  'l') /* IPU3 LACE statistics */

This series is missing a documentation patch with a clear and detailed 
description of the buffer contents for each of these formats. I'm not very 
concerned about the three statistics formats (although that might change after 
reading the documentation), but the "IPU3 params" format makes me feel nervous 
already.

> >>> We had some discussion about this with Laurent and if I remember
> >>> correctly, the conclusion was that it might make sense to define
> >>> one FourCC for a vendor specific format, ('v', 'n', 'd', 'r') for
> >>> example, and then have a V4L2-specific enum within the
> >>> v4l2_pix_format(_mplane) struct that specifies the exact vendor data
> >>> type.

If I recall correctly, I mentioned that v4l2_format now has a struct 
v4l2_meta_format field that can be used to pass metadata-related parameters 
the same way that v4l2_pix_format passes image-related parameters. The only 
two metadata parameters currently defined are the data format (fourcc) and 
buffer size, and more can be added if needed. However, I don't think the 
v4l2_meta_format structure should be extended with vendor-specific fields.

> >>> It seems saner than assigning a new FourCC whenever a new
> >>> hardware revision comes out, especially given that FourCCs tend to
> >>> be used outside of the V4L2 world as well and being kind of (de
> >>> facto) standardized (with existing exceptions, unfortunately).
>  
>  I can't remember that discussion
> >>> 
> >>> I think that was just a casual chat between Lauren, me and few more
> >>> guys.
> >>> 
>  although I've had other discussions with Laurent related to this on how
>  to handle formats that have many variations on a theme.
>  
>  But speaking for this specific case I see no reason to do something
>  special. There are only four new formats, which seems perfectly
>  reasonable to me.
>  
>  I don't see the advantage of adding another layer of pixel formats.
>  You still need to define something for this, one way or the other.
>  And this way doesn't require API changes.
>  
> > If we have four video nodes with different vendor specific formats,
> > how does the user tell the formats apart? I presume the user space
> > could use the entity names for instance, but that would essentially
> > make them device specific.
>  
>  Well, they are. There really is no way to avoid that.
>  
> > I'm not sure if there would be any harm from that in practice though:
> > the user will need to find the device nodes somehow and that will be
> > very likely based on e.g. entity names.
> > 
> > How should the documentation be arranged? The documentation is
> > arranged by fourccs currently; we'd probably need a separate section
> > for vendor specific formats. I think the device name should be listed
> > there as well.
>  
>  There already is a separate section for metadata formats:
>  
>  https://hverkuil.home.xs4all.nl/spec/uapi/v4l/meta-formats.html
>  
>  But perhaps that page should be organized by device. And with some
>  more detailed information on how to find the video node (i.e. entity
>  

Re: [PATCH v4 1/2] media: i2c: adv748x: add adv748x driver

[Hans Verkuil]

On 06/13/2017 02:35 AM, Kieran Bingham wrote:

From: Kieran Bingham 

Provide support for the ADV7481 and ADV7482.

The driver is modelled with 4 subdevices to allow simultaneous streaming
from the AFE (Analog front end) and HDMI inputs though two CSI TX
entities.

The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
to the TXB CSI bus.

The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
and an earlier rework by Niklas Söderlund.

Signed-off-by: Kieran Bingham 

---

v2:
  - Implement DT parsing
  - adv748x: Add CSI2 entity
  - adv748x: Rework pad allocations and fmts
  - Give AFE 8 input pads and move pad defines
  - Use the enums to ensure pads are referenced correctly.
  - adv748x: Rename AFE/HDMI entities
Now they are 'just afe' and 'just hdmi'
  - Reorder the entity enum and structures
  - Added pad-format for the CSI2 entities
  - CSI2 s_stream pass through
  - CSI2 control pass through (with link following)

v3:
  - dt: Extend DT documentation to specify interrupt mappings
  - simplify adv748x_parse_dt
  - core: Add banner to header file describing ADV748x variants
  - Use entity structure pointers rather than global state pointers where
possible
  - afe: Reduce indent on afe_status
  - hdmi: Add error checking to the bt->pixelclock values.
  - Remove all unnecessary pad checks: handled by core
  - Fix all probe cleanup paths
  - adv748x_csi2_probe() now fails if it has no endpoint
  - csi2: Fix small oneliners for is_txa and get_remote_sd()
  - csi2: Fix checkpatch warnings
  - csi2: Fix up s_stream pass-through
  - csi2: Fix up Pixel Rate passthrough
  - csi2: simplify adv748x_csi2_get_pad_format()
  - Remove 'async notifiers' from AFE/HDMI
Using async notifiers was overkill, when we have access to the
subdevices internally and can register them directly.
  - Use state lock in control handlers and clean up s_ctrls
  - remove _interruptible mutex locks

v4:
  - all: Convert hex 0xXX to lowercase
  - all: Use defines instead of hardcoded register values
  - all: Use regmap
  - afe, csi2, hdmi: _probe -> _init
  - afe, csi2, hdmi: _remove -> _cleanup
  - afe, hdmi: Convert pattern generator to a control
  - afe, hdmi: get/set-fmt refactor
  - afe, hdmi, csi2: Convert to internal calls for pixelrate
  - afe: Allow the AFE to configure the Input Select from DT
  - afe: Reduce indent on adv748x_afe_status switch
  - afe: Remove ununsed macro definitions AIN0-7
  - afe: Remove extraneous control checks handled by core
  - afe: Comment fixups
  - afe: Rename error label
  - afe: Correct control names on the SDP
  - afe: Use AIN0-7 rather than AIN1-8 to match ports and MC pads
  - core: adv748x_parse_dt references to nodes, and catch multiple
endpoints in a port.
  - core: adv748x_dt_cleanup to simplify releasing DT nodes
  - core: adv748x_print_info renamed to adv748x_identify_chip
  - core: reorganise ordering of probe sequence
  - core: No need for of_match_ptr
  - core: Fix up i2c read/writes (regmap still on todo list)
  - core: Set specific functions from the entities on subdev-init
  - core: Use kzalloc for state instead of devm
  - core: Improve probe error reporting
  - core: Track unknown BIT(6) in tx{a,b}_power
  - csi2: Improve adv748x_csi2_get_remote_sd as adv748x_csi2_get_source_sd
  - csi2: -EPIPE instead of -ENODEV
  - csi2: adv_dbg, instead of adv_info
  - csi2: adv748x_csi2_set_format fix
  - csi2: remove async notifier and sd member variables
  - csi2: register links from the CSI2
  - csi2: create virtual channel helper function
  - dt: Remove numbering from endpoints
  - dt: describe ports and interrupts as optional
  - dt: Re-tab
  - hdmi: adv748x_hdmi_have_signal -> adv748x_hdmi_has_signal
  - hdmi: fix adv748x_hdmi_read_pixelclock return checks
  - hdmi: improve adv748x_hdmi_set_video_timings
  - hdmi: Fix tmp variable as polarity
  - hdmi: Improve adv748x_hdmi_s_stream
  - hdmi: Clean up adv748x_hdmi_s_ctrl register definitions and usage
  - hdmi: Fix up adv748x_hdmi_s_dv_timings with macro names for register
  - hdmi: Add locking to adv748x_hdmi_g_dv_timings
writes and locking
  - hdmi: adv748x_hdmi_set_de_timings function added to clarify DE writes
  - hdmi: Use CP in control register naming to match component processor
  - hdmi: clean up adv748x_hdmi_query_dv_timings()
  - KConfig: Fix up dependency and capitalisation


  Documentation/devicetree/bindings/media/i2c/adv748x.txt |  96 +-


This should be a separate patch cross posted to the devicetree mailinglist.


  MAINTAINERS |   6 +-


This should also be a separate patch.


  drivers/media/i2c/Kconfig   |  11 +-
  drivers/media/i2c/Makefile  |   1 +-
  drivers/media/i2c/adv748x/Makefile  |   7 +-
  drivers/media/i2c/adv748x/adv748x-afe.c | 571 

Re: [PATCH v3 4/4] dt-bindings: media: Document Synopsys Designware HDMI RX

[Jose Abreu]

Hi Sylwester,


Thanks for the feedback!


On 18-06-2017 18:34, Sylwester Nawrocki wrote:
> Hi Jose,
>
> On 06/16/2017 06:38 PM, Jose Abreu wrote:
>> Document the bindings for the Synopsys Designware HDMI RX.
>>
>> Signed-off-by: Jose Abreu 
>> new file mode 100644
>> index 000..d30cc1e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
>> @@ -0,0 +1,45 @@
>> +Synopsys DesignWare HDMI RX Decoder
>> +===
>> +
>> +This document defines device tree properties for the Synopsys DesignWare 
>> HDMI
>> +RX Decoder (DWC HDMI RX). It doesn't constitute a device tree binding
>> +specification by itself but is meant to be referenced by platform-specific
>> +device tree bindings.
>> +
>> +When referenced from platform device tree bindings the properties defined in
>> +this document are defined as follows.
>> +
>> +- reg: Memory mapped base address and length of the DWC HDMI RX registers.
>> +
>> +- interrupts: Reference to the DWC HDMI RX interrupt and 5v sense interrupt.
>> +
>> +- snps,hdmi-phy-jtag-addr: JTAG address of the phy to be used.
>> +
>> +- snps,hdmi-phy-version: Version of the phy to be used.
>> +
>> +- snps,hdmi-phy-cfg-clk: Value of the cfg clk that is delivered to phy.
>> +
>> +- snps,hdmi-phy-driver: *Exact* name of the phy driver to be used.
> I don't think we can put Linux driver name in DT like this, devicetree 
> is supposed to be describing hardware in OS agnostic way.

Yeah, I was aware about that, its just that I have a few
limitations that I need to address. I will highlight them bellow
but I think that with your proposed DT bindings and using
of_platform_populate I can address them :)

>
>> +- snps,hdmi-ctl-cfg-clk: Value of the cfg clk that is delivered to the
>> +controller.
> How about creating a separate node for the PHY? The binding could then 
> be something like:
>
>
> /* Fixed clock needed only if respective clock is not already defined
>in the system */
>
> refclk: clock {
>   compatible = "fixed-clock";
>   #clock-cells = <0>;
>   clock-frequency = <2500>;
> };
>
> hdmi_phy: phy@f3 {
>   /* PHY version can be derived from the compatible string */
>   compatible = "snps,dw-hdmi-phy-e405";   
>   /* JTAG address of the PHY */
>   reg = <0xf3>
>
>   clocks = <>
>   clock-names = "cfg-clk";
> }
>
> hdmi-controller@0 {
>   compatible = "snps,dw-hdmi-rx-controller-vX.X";
>   reg = <0x0 0x1>;
>   interrupts = <1 3>; 
>   phys = <_phy>;
>
>   clocks = <>
>   clock-names = "cfg-clk";
> };
>
> Or it might be better to make the PHY node child node of the RX controller 
> node, since the RX controller could be considered a controller of the JTAG 
> bus IIUC:
>
> refclk: clock {
>   compatible = "fixed-clock";
>   #clock-cells = <0>;
>   clock-frequency = <2500>;
> };
>
> hdmi-controller@0 {
>   compatible = "snps,dw-hdmi-rx-controller-xxx";
>   reg = <0x0 0x1>;
>   interrupts = <1 3>; 
>   clocks = <>
>   clock-names = "cfg-clk";
>   #address-cells = <1>;
>   #size-cells = <0>;
>
>   phy@f3 {
>   /* PHY version can be derived from the compatible string */
>   compatible = "snps,dw-hdmi-phy-e405";
>   /* address of the PHY on the JTAG bus */
>   reg = <0xf3>
>
>   clocks = <>
>   clock-names = "cfg-clk";
>   }
> };
>
> Then rather than creating platform device in the RX controller driver 
> for the PHY just of_platform_populate() could be used.

Using fixed-clock was already in my todo list. Regarding phy I
need to pass pdata so that the callbacks between controller and
phy are established. I also need to make sure that phy driver
will be loaded by the controller driver. Hmm, and also address of
the phy on th JTAG bus is fed to the controller driver not to the
phy driver. Maybe leave the property as is (the
"snps,hdmi-phy-jtag-addr") or parse it from the phy node?

I also need to pass pdata to the controller driver (the callbacks
for 5v handling) which are agnostic of the controller. These
reasons prevented me from adding compatible strings to both
drivers and just use a wrapper driver instead. This way i do
"modprobe wrapper_driver" and I get all the drivers loaded via
request_module(). Still, I like your approach much better. I saw
that I can pass pdata using of_platform_populate, could you
please confirm if I can still maintain this architecture (i.e.
prevent modules from loading until I get all the chain setup)?

Following your approach I could get something like this:

hdmi_system@ {
compatible = "snps,dw-hdmi-rx-wrapper";
reg = <0x 0x>;
interrupts = <3>;
#address-cells = <1>;
#size-cells = <1>;

hdmi_controller@0 {
compatible = "snps,dw-hdmi-rx-controller";
reg = <0x0 0x1>;
interrupts = <1>;
edid-phandle = <_system>;
 

Re: [PATCH v2] [media] mtk-vcodec: Show mtk driver error without DEBUG definition

[Tiffany Lin]

On Tue, 2017-05-30 at 18:53 +0900, Hirokazu Honda wrote:
> A driver error message is shown without DEBUG definition
> to find an error and debug easily.
> 
> Signed-off-by: Hirokazu Honda 
Acked-by: Tiffany Lin 

> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> index 237e144c194f..06c254f5c171 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> @@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
>  extern bool mtk_vcodec_dbg;
>  
> 
> +#define mtk_v4l2_err(fmt, args...)\
> + pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
> +##args)
> +
> +#define mtk_vcodec_err(h, fmt, args...)  
> \
> + pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
> +((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
> +
> +
>  #if defined(DEBUG)
>  
>  #define mtk_v4l2_debug(level, fmt, args...)   \
> @@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
>   level, __func__, __LINE__, ##args);  \
>   } while (0)
>  
> -#define mtk_v4l2_err(fmt, args...)\
> - pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
> -##args)
> -
> -
>  #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
>  #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
>  
> @@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
>   __func__, ##args);  \
>   } while (0)
>  
> -#define mtk_vcodec_err(h, fmt, args...)  
> \
> - pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
> -((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
> -
>  #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
>  #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
>  
>  #else
>  
>  #define mtk_v4l2_debug(level, fmt, args...) {}
> -#define mtk_v4l2_err(fmt, args...) {}
>  #define mtk_v4l2_debug_enter() {}
>  #define mtk_v4l2_debug_leave() {}
>  
>  #define mtk_vcodec_debug(h, fmt, args...) {}
> -#define mtk_vcodec_err(h, fmt, args...) {}
>  #define mtk_vcodec_debug_enter(h) {}
>  #define mtk_vcodec_debug_leave(h) {}
>  

Re: [PATCH v2 08/15] [media] cxd2880: Add top level of the driver

[Takiguchi, Yasunari]

Thanks for your kindly reply.

We are think of how to change our driver to follow the comments now.
I reply one thing about reading BER measures at get_frontend() in this mail.

On 2017/06/13 22:30, Mauro Carvalho Chehab wrote:
> Em Fri, 14 Apr 2017 11:31:50 +0900
>  escreveu:
> 
>> From: Yasunari Takiguchi 
>>
>> This provides the main dvb frontend operation functions
>> for the Sony CXD2880 DVB-T2/T tuner + demodulator driver.
> 
> For now, I'll do only a quick review on patches 6-15, as there are several
> things to be ajusted on the code, from my past comments.
> 
> I'll do a better review on the next version. So, I'll focus only on
> a few random issues I see on the code below.
> 
>>
>> Signed-off-by: Yasunari Takiguchi 
>> Signed-off-by: Masayuki Yamamoto 
>> Signed-off-by: Hideki Nozawa 
>> Signed-off-by: Kota Yonezawa 
>> Signed-off-by: Toshihiko Matsumoto 
>> Signed-off-by: Satoshi Watanabe 
>> ---
>>  drivers/media/dvb-frontends/cxd2880/cxd2880_top.c | 1550 
>> +
>>  1 file changed, 1550 insertions(+)
>>  create mode 100644 drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
>>
>> diff --git a/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c 
>> b/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
>> new file mode 100644
>> index ..66d78fb93a13
>> --- /dev/null
>> +++ b/drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
>> @@ -0,0 +1,1550 @@
>> +/*
>> + * cxd2880_top.c
>> + * Sony CXD2880 DVB-T2/T tuner + demodulator driver
>> + *
>> + * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; version 2 of the License.
>> + *
>> + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
>> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
>> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
>> + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
>> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
>> + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>> + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
>> + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
>> + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> + *
>> + * You should have received a copy of the GNU General Public License along
>> + * with this program; if not, see .
>> + */
>> +
>> +#include 
>> +
>> +#include "dvb_frontend.h"
>> +
>> +#include "cxd2880.h"
>> +#include "cxd2880_tnrdmd_mon.h"
>> +#include "cxd2880_tnrdmd_dvbt2_mon.h"
>> +#include "cxd2880_tnrdmd_dvbt_mon.h"
>> +#include "cxd2880_integ_dvbt2.h"
>> +#include "cxd2880_integ_dvbt.h"
>> +#include "cxd2880_devio_spi.h"
>> +#include "cxd2880_spi_device.h"
>> +#include "cxd2880_tnrdmd_driver_version.h"
>> +
>> +struct cxd2880_priv {
>> +struct cxd2880_tnrdmd tnrdmd;
>> +struct spi_device *spi;
>> +struct cxd2880_io regio;
>> +struct cxd2880_spi_device spi_device;
>> +struct cxd2880_spi cxd2880_spi;
>> +struct cxd2880_dvbt_tune_param dvbt_tune_param;
>> +struct cxd2880_dvbt2_tune_param dvbt2_tune_param;
>> +struct mutex *spi_mutex; /* For SPI access exclusive control */
>> +};
>> +
>> +/*
>> + * return value conversion table
>> + */
>> +static int return_tbl[] = {
>> +0, /* CXD2880_RESULT_OK */
>> +-EINVAL,   /* CXD2880_RESULT_ERROR_ARG*/
>> +-EIO,  /* CXD2880_RESULT_ERROR_IO */
>> +-EPERM,/* CXD2880_RESULT_ERROR_SW_STATE */
>> +-EBUSY,/* CXD2880_RESULT_ERROR_HW_STATE */
>> +-ETIME,/* CXD2880_RESULT_ERROR_TIMEOUT */
>> +-EAGAIN,   /* CXD2880_RESULT_ERROR_UNLOCK */
>> +-ERANGE,   /* CXD2880_RESULT_ERROR_RANGE */
>> +-EOPNOTSUPP,   /* CXD2880_RESULT_ERROR_NOSUPPORT */
>> +-ECANCELED,/* CXD2880_RESULT_ERROR_CANCEL */
>> +-EPERM,/* CXD2880_RESULT_ERROR_OTHER */
>> +-EOVERFLOW,/* CXD2880_RESULT_ERROR_OVERFLOW */
>> +0, /* CXD2880_RESULT_OK_CONFIRM */
>> +};
> 
> Please, don't use a conversion table. That makes the driver more
> complex to be understood without any good reason. Instead, just 
> replace the values at the original enum.
> 
>> +
>> +static enum cxd2880_ret cxd2880_pre_bit_err_t(
>> +struct cxd2880_tnrdmd *tnrdmd, u32 *pre_bit_err,
>> +u32 *pre_bit_count)
>> +{
>> +u8 rdata[2];
>> +
>> +if ((!tnrdmd) || (!pre_bit_err) || 

Re: [PATCH v4 00/11] [media]: vimc: Virtual Media Control VPU's

[Hans Verkuil]

Hi Helen,

On 06/13/2017 09:35 PM, Helen Koike wrote:

This patch series improves the current video processing units in vimc
(by adding more controls to the sensor and capture node, allowing the
user to configure different frame formats) and also adds a debayer
and a scaler node.
The debayer transforms the bayer format image received in its sink pad
to a bayer format by averaging the pixels within a mean window.
The scaler only scales up the image for now.

This patch series is based on media/master and it is available at:
https://github.com/helen-fornazier/opw-staging/tree/z/sent/vimc/vpu/v4

In this version I removed the commit
[media] vimc: Optimize frame generation through the pipe
There was a bug when multiple links going to the same sink was enabled,
I'll rework on it and re-send it in a different patch series


I ran the v4 patch series through my sparse/smatch test and found a few 
warnings:

sparse:

drivers/media/platform/vimc/vimc-debayer.c:376:30: warning: symbol 
'vimc_deb_video_ops' was not declared. Should it be static?
drivers/media/platform/vimc/vimc-scaler.c:270:30: warning: symbol 
'vimc_sca_video_ops' was not declared. Should it be static?
drivers/media/platform/vimc/vimc-sensor.c:285:30: warning: symbol 
'vimc_sen_video_ops' was not declared. Should it be static?

smatch:

drivers/media/platform/vimc/vimc-core.c:271 vimc_add_subdevs() warn: always true 
condition '(--i >= 0) => (0-u32max >= 0)'
drivers/media/platform/vimc/vimc-core.c:271 vimc_add_subdevs() warn: always true 
condition '(--i >= 0) => (0-u32max >= 0)'

Can you take a look?

Regards,

Hans

Re: [RFC PATCH 2/2] media/uapi/v4l: clarify cropcap/crop/selection behavior

[Hans Verkuil]

Hi Sylwester,

On 05/08/2017 04:35 PM, Hans Verkuil wrote:

From: Hans Verkuil 

Unfortunately the use of 'type' was inconsistent for multiplanar
buffer types. Starting with 4.12 both the normal and _MPLANE variants
are allowed, thus making it possible to write sensible code.

Yes, we messed up :-(

Signed-off-by: Hans Verkuil 
---
  Documentation/media/uapi/v4l/vidioc-cropcap.rst| 21 -
  Documentation/media/uapi/v4l/vidioc-g-crop.rst | 22 +-
  .../media/uapi/v4l/vidioc-g-selection.rst  | 22 --
  3 files changed, 37 insertions(+), 28 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-cropcap.rst 
b/Documentation/media/uapi/v4l/vidioc-cropcap.rst
index f21a69b554e1..d354216846e6 100644
--- a/Documentation/media/uapi/v4l/vidioc-cropcap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-cropcap.rst
@@ -39,16 +39,19 @@ structure. Drivers fill the rest of the structure. The 
results are
  constant except when switching the video standard. Remember this switch
  can occur implicit when switching the video input or output.
  
-Do not use the multiplanar buffer types. Use

-``V4L2_BUF_TYPE_VIDEO_CAPTURE`` instead of
-``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and use
-``V4L2_BUF_TYPE_VIDEO_OUTPUT`` instead of
-``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``.
-
  This ioctl must be implemented for video capture or output devices that
  support cropping and/or scaling and/or have non-square pixels, and for
  overlay devices.
  
+.. note::

+   Unfortunately in the case of multiplanar buffer types
+   (``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and 
``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``)
+   this API was messed up with regards to how the :c:type:`v4l2_cropcap` 
``type`` field
+   should be filled in. The Samsung Exynos drivers only accepted the


I propose I change this to "Some drivers only..." here and at the other places I
refer to Exynos.

Do you agree?

Hans


+   ``_MPLANE`` buffer type while other drivers only accepted a non-multiplanar
+   buffer type (i.e. without the ``_MPLANE`` at the end).
+
+   Starting with kernel 4.12 both variations are allowed.
  
  .. c:type:: v4l2_cropcap
  
@@ -62,9 +65,9 @@ overlay devices.

  * - __u32
- ``type``
- Type of the data stream, set by the application. Only these types
-   are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``,
-   ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` and
-   ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type`.
+   are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``, 
``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``,
+   ``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE`` 
and
+   ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type` and the 
note above.
  * - struct :ref:`v4l2_rect `
- ``bounds``
- Defines the window within capturing or output is possible, this
diff --git a/Documentation/media/uapi/v4l/vidioc-g-crop.rst 
b/Documentation/media/uapi/v4l/vidioc-g-crop.rst
index 56a36340f565..8aabe33c8da7 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-crop.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-crop.rst
@@ -45,12 +45,6 @@ and struct :c:type:`v4l2_rect` substructure named ``c`` of a
  v4l2_crop structure and call the :ref:`VIDIOC_S_CROP ` ioctl 
with a pointer
  to this structure.
  
-Do not use the multiplanar buffer types. Use

-``V4L2_BUF_TYPE_VIDEO_CAPTURE`` instead of
-``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and use
-``V4L2_BUF_TYPE_VIDEO_OUTPUT`` instead of
-``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``.
-
  The driver first adjusts the requested dimensions against hardware
  limits, i. e. the bounds given by the capture/output window, and it
  rounds to the closest possible values of horizontal and vertical offset,
@@ -74,6 +68,16 @@ been negotiated.
  When cropping is not supported then no parameters are changed and
  :ref:`VIDIOC_S_CROP ` returns the ``EINVAL`` error code.
  
+.. note::

+   Unfortunately in the case of multiplanar buffer types
+   (``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and 
``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``)
+   this API was messed up with regards to how the :c:type:`v4l2_crop` ``type`` 
field
+   should be filled in. The Samsung Exynos drivers only accepted the
+   ``_MPLANE`` buffer type while other drivers only accepted a non-multiplanar
+   buffer type (i.e. without the ``_MPLANE`` at the end).
+
+   Starting with kernel 4.12 both variations are allowed.
+
  
  .. c:type:: v4l2_crop
  
@@ -87,9 +91,9 @@ When cropping is not supported then no parameters are changed and

  * - __u32
- ``type``
- Type of the data stream, set by the application. Only these types
-   are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``,
-   ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` and
-   ``V4L2_BUF_TYPE_VIDEO_OVERLAY``. See :c:type:`v4l2_buf_type`.
+   are valid here: ``V4L2_BUF_TYPE_VIDEO_CAPTURE``, 

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:   Mon Jun 19 05:00:21 CEST 2017
media-tree git hash:acec3630155763c170c7ae6508cf973355464508
media_build git hash:   dbdc2495ec17a3e71d2ec56778eed10081bb718f
v4l-utils git hash: ce237eefc1f6dafafc0e1fe3a5fd9f075d3fd066
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

[Marek Szyprowski]

Hi All,

I'm sorry for the late reply, I just got back from holidays.

On 2017-06-02 23:43, Jacek Anaszewski wrote:

Cc Marek Szyprowski.

Marek, could you share your opinion about this patch?

On 06/02/2017 06:02 PM, Thierry Escande wrote:

From: Tony K Nadackal 

This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU
and ARM DMA IOMMU configurations are supported. The address space is
created with size limited to 256M and base address set to 0x2000.


Could you clarify WHY this patch is needed? IOMMU core configures per-device
IO address space by default and AFAIR JPEG module doesn't have any specific
requirements for the IO address space layout (base or size), so it should
work fine (and works in my tests!) without this patch.

Please drop this patch for now.


Signed-off-by: Tony K Nadackal 
Signed-off-by: Thierry Escande 
---
  drivers/media/platform/s5p-jpeg/jpeg-core.c | 77 +
  1 file changed, 77 insertions(+)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 770a709..5569b99 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -28,6 +28,14 @@
  #include 
  #include 
  #include 
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
  
  #include "jpeg-core.h"

  #include "jpeg-hw-s5p.h"
@@ -35,6 +43,10 @@
  #include "jpeg-hw-exynos3250.h"
  #include "jpeg-regs.h"
  
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)

+static struct dma_iommu_mapping *mapping;
+#endif
+
  static struct s5p_jpeg_fmt sjpeg_formats[] = {
{
.name   = "JPEG JFIF",
@@ -956,6 +968,60 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx 
*ctx)
}
  }
  
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)

+static int jpeg_iommu_init(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   int err;
+
+   mapping = arm_iommu_create_mapping(_bus_type, 0x2000,
+  SZ_512M);
+   if (IS_ERR(mapping)) {
+   dev_err(dev, "IOMMU mapping failed\n");
+   return PTR_ERR(mapping);
+   }
+
+   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL);
+   if (!dev->dma_parms) {
+   err = -ENOMEM;
+   goto error_alloc;
+   }
+
+   err = dma_set_max_seg_size(dev, 0xu);
+   if (err)
+   goto error;
+
+   err = arm_iommu_attach_device(dev, mapping);
+   if (err)
+   goto error;
+
+   return 0;
+
+error:
+   devm_kfree(dev, dev->dma_parms);
+   dev->dma_parms = NULL;
+
+error_alloc:
+   arm_iommu_release_mapping(mapping);
+   mapping = NULL;
+
+   return err;
+}
+
+static void jpeg_iommu_deinit(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+
+   if (mapping) {
+   arm_iommu_detach_device(dev);
+   devm_kfree(dev, dev->dma_parms);
+   dev->dma_parms = NULL;
+   arm_iommu_release_mapping(mapping);
+   mapping = NULL;
+   }
+}
+#endif
+
  /*
   * 

   * Device file operations
@@ -2816,6 +2882,13 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
spin_lock_init(>slock);
jpeg->dev = >dev;
  
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)

+   ret = jpeg_iommu_init(pdev);
+   if (ret) {
+   dev_err(>dev, "IOMMU Initialization failed\n");
+   return ret;
+   }
+#endif
/* memory-mapped registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
  
@@ -2962,6 +3035,10 @@ static int s5p_jpeg_remove(struct platform_device *pdev)

clk_disable_unprepare(jpeg->clocks[i]);
}
  
+#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)

+   jpeg_iommu_deinit(pdev);
+#endif
+
return 0;
  }
  



Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland