cron job: media_tree daily build: ERRORS

2018-07-25 Thread 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:   Thu Jul 26 05:00:11 CEST 2018
media-tree git hash:7ba2eb72f843fb79de1857a39f9a7e8006f8133b
media_build git hash:   f3b64e45d2f2ef45cd4ae5b90a8f2a4fb284e43c
v4l-utils git hash: b42b70c98480a7070648fb711e22b30f6a444128
edid-decode git hash:   ab18befbcacd6cd4dff63faa82e32700369d6f25
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.16.0-1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.101-i686: ERRORS
linux-3.0.101-x86_64: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.102-i686: ERRORS
linux-3.2.102-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.113-i686: ERRORS
linux-3.4.113-x86_64: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.10-i686: ERRORS
linux-3.7.10-x86_64: ERRORS
linux-3.8.13-i686: ERRORS
linux-3.8.13-x86_64: ERRORS
linux-3.9.11-i686: ERRORS
linux-3.9.11-x86_64: ERRORS
linux-3.10.108-i686: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.115-i686: ERRORS
linux-3.18.115-x86_64: ERRORS
linux-3.19.8-i686: ERRORS
linux-3.19.8-x86_64: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.52-i686: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.140-i686: ERRORS
linux-4.4.140-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.112-i686: ERRORS
linux-4.9.112-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.55-i686: ERRORS
linux-4.14.55-x86_64: ERRORS
linux-4.15.18-i686: ERRORS
linux-4.15.18-x86_64: ERRORS
linux-4.16.18-i686: ERRORS
linux-4.16.18-x86_64: ERRORS
linux-4.17.6-i686: ERRORS
linux-4.17.6-x86_64: ERRORS
linux-4.18-rc4-i686: ERRORS
linux-4.18-rc4-x86_64: ERRORS
apps: OK
spec-git: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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


Re: [RFC] media: thermal I2C cameras metadata

2018-07-25 Thread Matt Ranostay
On Wed, Jul 25, 2018 at 2:09 AM, Sakari Ailus  wrote:
> On Tue, Jul 24, 2018 at 11:05:47PM -0700, Matt Ranostay wrote:
>> On Mon, Jul 23, 2018 at 4:35 AM, Sakari Ailus  wrote:
>> > Hi Matt,
>> >
>> > On Sun, Jul 15, 2018 at 11:05:42PM -0700, Matt Ranostay wrote:
>> >> Hello et all,
>> >>
>> >> So currently working with some thermal sensors that have coefficients
>> >> that needs to be passed back to userspace that aren't related to the
>> >> pixel data but are required to normalize to remove scan patterns and
>> >> temp gradients. Was wondering the best way to do this, and hope it
>> >> isn't some is kludge of the close captioning, or just passing raw data
>> >> as another column line.
>> >
>> > Are you referring to the EEPROM content or something else?
>> >
>> > For EEPROM, I could think of just exposing the EEPROM to the user space
>> > as-is using the NVMEM API. This information is very, very device specific
>> > and therefore using a generic interface to access individual values there
>> > isn't really useful.
>> >
>>
>> Actually that is okay for the EEPROM data that is per sensor, and
>> nvram does seem like it would work.
>> But there is per video frame data that is required along with the
>> static EEPROM data to calculate the actual end result.
>
> Could you point out what that might be on the datasheet?

Datasheet: 
https://www.melexis.com/-/media/files/documents/datasheets/mlx90640-datasheet-melexis.pdf

On page 18 it documents that 0x700-0x73f  are required for the various
userspace calculations along with the other static EEPROM data.

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


Re: Devices with a front and back webcam represented as a single UVC device

2018-07-25 Thread Laurent Pinchart
Hi Javier,

On Tuesday, 24 July 2018 15:35:17 EEST Javier Martinez Canillas wrote:
> On Thu, Jul 12, 2018 at 3:01 PM, Laurent Pinchart wrote:
> 
> [snip]
> 
> >> Laurent, thank you for your input on this. I thought it was a bit weird
> >> that the cam on my HP X2 only had what appears to be the debug controls,
> >> so I opened it up and as I suspect (after your analysis) it is using a
> >> USB module for the front camera, but the back camera is a sensor
> >> directly hooked with its CSI/MIPI bus to the PCB, so very likely it is
> >> using the ATOMISP stuff.
> >> 
> >> So I think that we can consider this "solved" for my 2-in-1.
> > 
> > Great, I'll add you to the list of potential testers for an ATOMISP
> > solution :-)
> 
> The ATOMISP driver was removed from staging by commit 51b8dc5163d
> ("media: staging: atomisp: Remove driver"). Do you mean that there's a
> plan to bring that driver back?

I don't think so, unless someone is willing to invest the time it would need 
to bring it back.

-- 
Regards,

Laurent Pinchart





[PATCH] rockchip/rga: Fix bad dma_free_attrs() parameter

2018-07-25 Thread Ezequiel Garcia
In rga_remove(), dma_free_attrs is being passed the wrong
cpu address, which triggers an exception if the driver is
removed. Fix it.

Tested on a RK3399 platform, with a bind/unbind cycle.

Signed-off-by: Ezequiel Garcia 
---
 drivers/media/platform/rockchip/rga/rga.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rga/rga.c 
b/drivers/media/platform/rockchip/rga/rga.c
index 8ace1873202a..850da4b34e12 100644
--- a/drivers/media/platform/rockchip/rga/rga.c
+++ b/drivers/media/platform/rockchip/rga/rga.c
@@ -931,7 +931,7 @@ static int rga_remove(struct platform_device *pdev)
 {
struct rockchip_rga *rga = platform_get_drvdata(pdev);
 
-   dma_free_attrs(rga->dev, RGA_CMDBUF_SIZE, >cmdbuf_virt,
+   dma_free_attrs(rga->dev, RGA_CMDBUF_SIZE, rga->cmdbuf_virt,
   rga->cmdbuf_phy, DMA_ATTR_WRITE_COMBINE);
 
free_pages((unsigned long)rga->src_mmu_pages, 3);
-- 
2.18.0



USB Drives - custom made with your logo

2018-07-25 Thread Vanessa

How are you?

I would like to speak with the person in charge of purchasing your branded
promotional products for your company?

We create custom LOGO USB flash drives for our clients throughout the US.
We can print your logo, and load your digital images, videos and files!
If you need marketing, advertising, gifts or incentives, USB flash drives
are the solution!

Here is what we include:
-All Memory Sizes from 64MB up to 128GB!
-Second Side Printing
-Low Minimum Quantities
-Rush Service Available
-Full color Printing

NEW:   We can make a custom shaped USB drive to look like your Logo or
product!
Send us your product image or logo files; we will create a design mock up
for you at no cost!
We are always running a new deals; email to get pricing!

Ask about the “Double Your Memory” upgrade promotion going on right
now!
Pricing is low right now, so let us know what you need and we will get you
a quick quote.

We will beat any competitors pricing, send us your last invoice and we will
beat it!

We always offer great rates for schools and nonprofits as well.
Regards,

Vanessa Kellen
Logo USB Account Manager




USB Drives - custom made with your logo

2018-07-25 Thread Vanessa

How are you?

I would like to speak with the person in charge of purchasing your branded
promotional products for your company?

We create custom LOGO USB flash drives for our clients throughout the US.
We can print your logo, and load your digital images, videos and files!
If you need marketing, advertising, gifts or incentives, USB flash drives
are the solution!

Here is what we include:
-All Memory Sizes from 64MB up to 128GB!
-Second Side Printing
-Low Minimum Quantities
-Rush Service Available
-Full color Printing

NEW:   We can make a custom shaped USB drive to look like your Logo or
product!
Send us your product image or logo files; we will create a design mock up
for you at no cost!
We are always running a new deals; email to get pricing!

Ask about the “Double Your Memory” upgrade promotion going on right
now!
Pricing is low right now, so let us know what you need and we will get you
a quick quote.

We will beat any competitors pricing, send us your last invoice and we will
beat it!

We always offer great rates for schools and nonprofits as well.
Regards,

Vanessa Kellen
Logo USB Account Manager




Re: Logspam with "two consecutive events of type space" on gpio-ir-recv and meson-ir

2018-07-25 Thread Sean Young
Hi Hias,

On Sat, Jul 21, 2018 at 09:04:21PM +0200, Matthias Reichl wrote:
> Hi Sean,
> 
> I noticed that on 4.18-rc5 I get dmesg logspam with
> "rc rc0: two consecutive events of type space" on gpio-ir-recv
> and meson-ir - mceusb seems to be fine (haven't tested with
> other IR receivers yet).
> 
> With the default, short IR timeout I get these messages on each
> IR message, which is rather spammy on longer button presses:
> 
> [ 1988.053215] rc rc0: two consecutive events of type space
> [ 1988.173189] rc rc0: two consecutive events of type space
> [ 1988.283188] rc rc0: two consecutive events of type space
> [ 1988.403185] rc rc0: two consecutive events of type space
> [ 1988.513193] rc rc0: two consecutive events of type space
> [ 1988.623190] rc rc0: two consecutive events of type space
> [ 1988.743190] rc rc0: two consecutive events of type space
> [ 1988.853193] rc rc0: two consecutive events of type space
> [ 1988.973193] rc rc0: two consecutive events of type space
> [ 1989.083193] rc rc0: two consecutive events of type space
> [ 1989.193196] rc rc0: two consecutive events of type space
> [ 1989.313216] rc rc0: two consecutive events of type space
> [ 1989.423197] rc rc0: two consecutive events of type space
> ...
> 
> With a longer timeout (eg 125ms and testing with a RC-5 remote) I get
> these messages once per button press.
> 
> Eg on 2 shorter button presses:
> # ir-keytable -t
> Testing events. Please, press CTRL-C to abort.
> 2045.990064: lirc protocol(rc5): scancode = 0x101b
> 2045.990123: event type EV_MSC(0x04): scancode = 0x101b
> 2045.990123: event type EV_SYN(0x00).
> 2046.100077: lirc protocol(rc5): scancode = 0x101b
> 2046.100126: event type EV_MSC(0x04): scancode = 0x101b
> 2046.100126: event type EV_SYN(0x00).
> 2046.230075: lirc protocol(rc5): scancode = 0x101b
> 2046.230118: event type EV_MSC(0x04): scancode = 0x101b
> 2046.230118: event type EV_SYN(0x00).
> 2050.970078: lirc protocol(rc5): scancode = 0x101b toggle=1
> 2050.970137: event type EV_MSC(0x04): scancode = 0x101b
> 2050.970137: event type EV_SYN(0x00).
> 2051.080071: lirc protocol(rc5): scancode = 0x101b toggle=1
> 2051.080119: event type EV_MSC(0x04): scancode = 0x101b
> 2051.080119: event type EV_SYN(0x00).
> 2051.210056: lirc protocol(rc5): scancode = 0x101b toggle=1
> 2051.210099: event type EV_MSC(0x04): scancode = 0x101b
> 2051.210099: event type EV_SYN(0x00).
> 
> I get this in dmesg:
> [ 2045.933635] rc rc0: two consecutive events of type space
> [ 2050.923689] rc rc0: two consecutive events of type space
> 
> So it looks like that might be a timeout-related issue with
> these 2 drivers.

This does not have a proper fix yet, however we have a workaround
here:

https://git.linuxtv.org/media_tree.git/commit/?h=fixes=0ca54b29054151b7a52cbb8904732280afe5a302


Sean


Re: [PATCH v8 2/3] uvcvideo: send a control event when a Control Change interrupt arrives

2018-07-25 Thread Laurent Pinchart
Hi Guennadi,

On Wednesday, 25 July 2018 20:21:54 EEST Guennadi Liakhovetski wrote:
> On Wed, 25 Jul 2018, Laurent Pinchart wrote:
> > On Wednesday, 18 July 2018 09:55:27 EEST Guennadi Liakhovetski wrote:
> >> On Wed, 18 Jul 2018, Laurent Pinchart wrote:
> >>> On Wednesday, 18 July 2018 00:30:45 EEST Guennadi Liakhovetski wrote:
>  On Tue, 17 Jul 2018, Laurent Pinchart wrote:
> > On Thursday, 12 July 2018 10:30:46 EEST Guennadi Liakhovetski wrote:
> >> On Thu, 12 Jul 2018, Laurent Pinchart wrote:
> >>> On Tuesday, 8 May 2018 18:07:43 EEST Guennadi Liakhovetski wrote:
>  UVC defines a method of handling asynchronous controls, which
>  sends a USB packet over the interrupt pipe. This patch implements
>  support for such packets by sending a control event to the user.
>  Since this can involve USB traffic and, therefore, scheduling, this
>  has to be done in a work queue.
>  
>  Signed-off-by: Guennadi Liakhovetski
>  
>  ---
>  
>  v8:
>  
>  * avoid losing events by delaying the status URB resubmission
>    until after completion of the current event
  * extract control value calculation into __uvc_ctrl_get_value()
>  * do not proactively return EBUSY if the previous control hasn't
>    completed yet, let the camera handle such cases
>  * multiple cosmetic changes
>  
>   drivers/media/usb/uvc/uvc_ctrl.c   | 166 +++--
>   drivers/media/usb/uvc/uvc_status.c | 112 ++---
>   drivers/media/usb/uvc/uvc_v4l2.c   |   4 +-
>   drivers/media/usb/uvc/uvcvideo.h   |  15 +++-
>   include/uapi/linux/uvcvideo.h  |   2 +
>   5 files changed, 255 insertions(+), 44 deletions(-)
>  
>  diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
>  b/drivers/media/usb/uvc/uvc_ctrl.c index 2a213c8..796f86a 100644
>  --- a/drivers/media/usb/uvc/uvc_ctrl.c
>  +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> >> 
> >> [snip]
> >> 
>  +static void uvc_ctrl_status_event_work(struct work_struct *work)
>  +{
>  +struct uvc_device *dev = container_of(work, struct uvc_device,
>  +  async_ctrl.work);
>  +struct uvc_ctrl_work *w = >async_ctrl;
>  +struct uvc_control_mapping *mapping;
>  +struct uvc_control *ctrl = w->ctrl;
>  +unsigned int i;
>  +int ret;
>  +
>  +mutex_lock(>chain->ctrl_mutex);
>  +
>  +list_for_each_entry(mapping, >info.mappings, list) {
>  +s32 value = __uvc_ctrl_get_value(mapping, w->data);
>  +
>  +/*
>  + * So far none of the auto-update controls in the 
>  uvc_ctrls[]
>  + * table is mapped to a V4L control with slaves in the
>  + * uvc_ctrl_mappings[] list, so slave controls so far 
>  never
>  have
>  + * handle == NULL, but this can change in the future
>  + */
>  +for (i = 0; i < ARRAY_SIZE(mapping->slave_ids); ++i) {
>  +if (!mapping->slave_ids[i])
>  +break;
>  +
>  +__uvc_ctrl_send_slave_event(ctrl->handle, 
>  w->chain,
>  +ctrl, 
>  mapping->slave_ids[i]);
>  +}
>  +
>  +uvc_ctrl_send_event(ctrl->handle, ctrl, mapping, value,
>  +V4L2_EVENT_CTRL_CH_VALUE);
>  +}
>  +
>  +mutex_unlock(>chain->ctrl_mutex);
>  +
>  +ctrl->handle = NULL;
> >>> 
> >>> Can't this race with a uvc_ctrl_set() call, resulting in
> >>> ctrl->handle being NULL after the control gets set ?
> >> 
> >> Right, it's better to set .handle to NULL before sending events.
> >> Something like
> >> 
> >> mutex_lock();
> >> 
> >> handle = ctrl->handle;
> >> ctrl->handle = NULL;
> >> 
> >> list_for_each_entry() {
> >> 
> >>...
> >>uvc_ctrl_send_event(handle,...);
> >> 
> >> }
> >> 
> >> mutex_unlock();
> >> 
> >> ?
> > 
> > I think you also have to take the same lock in the uvc_ctrl_set()
> > function to fix the problem, otherwise the ctrl->handle = NULL line
> > could still be executed after the ctrl->handle assignment in
> > uvc_ctrl_set(), resulting in ctrl->handle being NULL while the
> > control is being set.
>  
>  Doesn't this mean, that you're attempting to send a new instance of
>  the same control before the previous has completed? In which case also
> 

Re: [PATCH v8 2/3] uvcvideo: send a control event when a Control Change interrupt arrives

2018-07-25 Thread Laurent Pinchart
Hi Guennadi,

On Wednesday, 25 July 2018 20:25:16 EEST Laurent Pinchart wrote:
> On Tuesday, 8 May 2018 18:07:43 EEST Guennadi Liakhovetski wrote:
> > UVC defines a method of handling asynchronous controls, which sends a
> > USB packet over the interrupt pipe. This patch implements support for
> > such packets by sending a control event to the user. Since this can
> > involve USB traffic and, therefore, scheduling, this has to be done
> > in a work queue.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> > 
> > v8:
> > 
> > * avoid losing events by delaying the status URB resubmission until
> >   after completion of the current event
> > * extract control value calculation into __uvc_ctrl_get_value()
> > * do not proactively return EBUSY if the previous control hasn't
> >   completed yet, let the camera handle such cases
> > * multiple cosmetic changes
> > 
> >  drivers/media/usb/uvc/uvc_ctrl.c   | 166 ++--
> >  drivers/media/usb/uvc/uvc_status.c | 112 ++---
> >  drivers/media/usb/uvc/uvc_v4l2.c   |   4 +-
> >  drivers/media/usb/uvc/uvcvideo.h   |  15 +++-
> >  include/uapi/linux/uvcvideo.h  |   2 +
> >  5 files changed, 255 insertions(+), 44 deletions(-)
> 
> As mentioned in a previous e-mail, here's my review of small issues in the
> form of diff on top of this patch. I'll reply inline with comments.
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c index d57a176a03d5..04d779e3f039 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1225,38 +1225,41 @@ static void uvc_ctrl_fill_event(struct
> uvc_video_chain *chain, ev->u.ctrl.default_value = v4l2_ctrl.default_value;
>  }
> 
> -static void uvc_ctrl_send_event(struct uvc_fh *handle,
> - struct uvc_control *ctrl, struct uvc_control_mapping *mapping,
> - s32 value, u32 changes)
> +/*
> + * Send control change events to all subscribers for the @ctrl control. By
> + * default the subscriber that generated the event, as identified by
> @handle,
> + * is not notified unless it has set the
> V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK flag.
> + * @handle can be NULL for asynchronous events related to auto-update
> controls,
> + * in which case all subscribers are notified.
> + */

As the number of functions related to event handling grew larger, I felt that 
adding a bit of documentation became necessary to avoid getting lost.

> +static void uvc_ctrl_send_event(struct uvc_video_chain *chain,
> + struct uvc_fh *handle, struct uvc_control *ctrl,
> + struct uvc_control_mapping *mapping, s32 value, u32 changes)
>  {
> + struct v4l2_fh *originator = handle ? >vfh : NULL;
>   struct v4l2_subscribed_event *sev;
>   struct v4l2_event ev;
> - bool autoupdate;
> 
>   if (list_empty(>ev_subs))
>   return;
> 
> - if (!handle) {
> - autoupdate = true;
> - sev = list_first_entry(>ev_subs,
> -struct v4l2_subscribed_event, node);
> - handle = container_of(sev->fh, struct uvc_fh, vfh);
> - } else {
> - autoupdate = false;
> - }
> -

By adding the chain pointer as a function argument, which is always available 
to the caller, we can remove the small hack that looks up the chain in the 
first handle if the handle is NULL.

> - uvc_ctrl_fill_event(handle->chain, , ctrl, mapping, value, changes);
> + uvc_ctrl_fill_event(chain, , ctrl, mapping, value, changes);
> 
>   list_for_each_entry(sev, >ev_subs, node) {
> - if (sev->fh != >vfh ||
> + if (sev->fh != originator ||
>   (sev->flags & V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK) ||
> - (changes & V4L2_EVENT_CTRL_CH_FLAGS) || autoupdate)
> + (changes & V4L2_EVENT_CTRL_CH_FLAGS))
>   v4l2_event_queue_fh(sev->fh, );
>   }
>  }
> 
> -static void __uvc_ctrl_send_slave_event(struct uvc_fh *handle,
> - struct uvc_video_chain *chain, struct uvc_control *master, u32 slave_id)
> +/*
> + * Send control change events for the slave of the @master control
> identified
> + * by the V4L2 ID @slave_id. The @handle identifies the event subscriber
> that
> + * generated the event and may be NULL for auto-update
> events.
> + */
> +static void uvc_ctrl_send_slave_event(struct uvc_video_chain *chain,
> + struct uvc_fh *handle, struct uvc_control *master, u32 slave_id)

Passing the chain as the first argument matches the rest of the functions in 
this file (more or less). I also removed the starting double underscore, by 
removing the uvc_ctrl_send_slave_event() function below.

>  {
>   struct uvc_control_mapping *mapping = NULL;
>   struct uvc_control *ctrl = NULL;
> @@ -1267,11 +1270,10 @@ static void __uvc_ctrl_send_slave_event(struct
> uvc_fh *handle, if (ctrl == NULL)
>   return;
> 
> - if (__uvc_ctrl_get(handle ? handle->chain : chain, ctrl, mapping,

[PATCH] media: omap2: omapfb: fix bugon.cocci warnings

2018-07-25 Thread kbuild test robot
From: kbuild test robot 

drivers/video/fbdev/omap2/omapfb/dss/dss_features.c:895:2-5: WARNING: Use 
BUG_ON instead of if condition followed by BUG.
Please make sure the condition has no side effects (see conditional BUG_ON 
definition in include/asm-generic/bug.h)

 Use BUG_ON instead of a if condition followed by BUG.

Semantic patch information:
 This makes an effort to find cases where BUG() follows an if
 condition on an expression and replaces the if condition and BUG()
 with a BUG_ON having the conditional expression of the if statement
 as argument.

Generated by: scripts/coccinelle/misc/bugon.cocci

Fixes: 7378f1149884 ("media: omap2: omapfb: allow building it with 
COMPILE_TEST")
Signed-off-by: kbuild test robot 
---

Please take the patch only if it's a positive warning. Thanks!

 dss_features.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
@@ -891,8 +891,7 @@ bool dss_has_feature(enum dss_feat_id id
 
 void dss_feat_get_reg_field(enum dss_feat_reg_field id, u8 *start, u8 *end)
 {
-   if (id >= omap_current_dss_features->num_reg_fields)
-   BUG();
+   BUG_ON(id >= omap_current_dss_features->num_reg_fields);
 
*start = omap_current_dss_features->reg_fields[id].start;
*end = omap_current_dss_features->reg_fields[id].end;


[PATCH] media: omap2: omapfb: fix boolreturn.cocci warnings

2018-07-25 Thread kbuild test robot
From: kbuild test robot 

drivers/video/fbdev/omap2/omapfb/omapfb-main.c:290:9-10: WARNING: return of 0/1 
in function 'cmp_var_to_colormode' with return type bool

 Return statements in functions returning bool should use
 true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci

Fixes: 7378f1149884 ("media: omap2: omapfb: allow building it with 
COMPILE_TEST")
Signed-off-by: kbuild test robot 
---

 omapfb-main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -287,7 +287,7 @@ static bool cmp_var_to_colormode(struct
var->red.length == 0 ||
var->blue.length == 0 ||
var->green.length == 0)
-   return 0;
+   return false;
 
return var->bits_per_pixel == color->bits_per_pixel &&
cmp_component(>red, >red) &&


[PATCH] media: omap2: omapfb: fix ifnullfree.cocci warnings

2018-07-25 Thread kbuild test robot
From: kbuild test robot 

drivers/video/fbdev/omap2/omapfb/dss/core.c:141:2-26: WARNING: NULL check 
before some freeing functions is not needed.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

Fixes: 7378f1149884 ("media: omap2: omapfb: allow building it with 
COMPILE_TEST")
Signed-off-by: kbuild test robot 
---

Please take the patch only if it's a positive warning. Thanks!

 core.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/video/fbdev/omap2/omapfb/dss/core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c
@@ -137,8 +137,7 @@ static int dss_initialize_debugfs(void)
 
 static void dss_uninitialize_debugfs(void)
 {
-   if (dss_debugfs_dir)
-   debugfs_remove_recursive(dss_debugfs_dir);
+   debugfs_remove_recursive(dss_debugfs_dir);
 }
 
 int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))


drivers/video/fbdev/omap2/omapfb/omapfb-main.c:290:9-10: WARNING: return of 0/1 in function 'cmp_var_to_colormode' with return type bool

2018-07-25 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9981b4fb8684883dcc0daf088891ff32260b9794
commit: 7378f1149884b183631c6c16c0f1c62bcd7d759d media: omap2: omapfb: allow 
building it with COMPILE_TEST
date:   3 months ago


coccinelle warnings: (new ones prefixed by >>)

>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:290:9-10: WARNING: return of 
>> 0/1 in function 'cmp_var_to_colormode' with return type bool
--
>> drivers/video/fbdev/omap2/omapfb/dss/dss_features.c:895:2-5: WARNING: Use 
>> BUG_ON instead of if condition followed by BUG.
   Please make sure the condition has no side effects (see conditional BUG_ON 
definition in include/asm-generic/bug.h)
--
>> drivers/video/fbdev/omap2/omapfb/dss/core.c:141:2-26: WARNING: NULL check 
>> before some freeing functions is not needed.

Please review and possibly fold the followup patch.

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


Re: [PATCH v8 2/3] uvcvideo: send a control event when a Control Change interrupt arrives

2018-07-25 Thread Laurent Pinchart
Hi Guennadi,

On Tuesday, 8 May 2018 18:07:43 EEST Guennadi Liakhovetski wrote:
> UVC defines a method of handling asynchronous controls, which sends a
> USB packet over the interrupt pipe. This patch implements support for
> such packets by sending a control event to the user. Since this can
> involve USB traffic and, therefore, scheduling, this has to be done
> in a work queue.
> 
> Signed-off-by: Guennadi Liakhovetski 
> ---
> 
> v8:
> 
> * avoid losing events by delaying the status URB resubmission until
>   after completion of the current event
> * extract control value calculation into __uvc_ctrl_get_value()
> * do not proactively return EBUSY if the previous control hasn't
>   completed yet, let the camera handle such cases
> * multiple cosmetic changes
> 
>  drivers/media/usb/uvc/uvc_ctrl.c   | 166 --
>  drivers/media/usb/uvc/uvc_status.c | 112 ++---
>  drivers/media/usb/uvc/uvc_v4l2.c   |   4 +-
>  drivers/media/usb/uvc/uvcvideo.h   |  15 +++-
>  include/uapi/linux/uvcvideo.h  |   2 +
>  5 files changed, 255 insertions(+), 44 deletions(-)

As mentioned in a previous e-mail, here's my review of small issues in the
form of diff on top of this patch. I'll reply inline with comments.

diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index d57a176a03d5..04d779e3f039 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1225,38 +1225,41 @@ static void uvc_ctrl_fill_event(struct uvc_video_chain 
*chain,
ev->u.ctrl.default_value = v4l2_ctrl.default_value;
 }
 
-static void uvc_ctrl_send_event(struct uvc_fh *handle,
-   struct uvc_control *ctrl, struct uvc_control_mapping *mapping,
-   s32 value, u32 changes)
+/*
+ * Send control change events to all subscribers for the @ctrl control. By
+ * default the subscriber that generated the event, as identified by @handle,
+ * is not notified unless it has set the V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK flag.
+ * @handle can be NULL for asynchronous events related to auto-update controls,
+ * in which case all subscribers are notified.
+ */
+static void uvc_ctrl_send_event(struct uvc_video_chain *chain,
+   struct uvc_fh *handle, struct uvc_control *ctrl,
+   struct uvc_control_mapping *mapping, s32 value, u32 changes)
 {
+   struct v4l2_fh *originator = handle ? >vfh : NULL;
struct v4l2_subscribed_event *sev;
struct v4l2_event ev;
-   bool autoupdate;
 
if (list_empty(>ev_subs))
return;
 
-   if (!handle) {
-   autoupdate = true;
-   sev = list_first_entry(>ev_subs,
-  struct v4l2_subscribed_event, node);
-   handle = container_of(sev->fh, struct uvc_fh, vfh);
-   } else {
-   autoupdate = false;
-   }
-
-   uvc_ctrl_fill_event(handle->chain, , ctrl, mapping, value, changes);
+   uvc_ctrl_fill_event(chain, , ctrl, mapping, value, changes);
 
list_for_each_entry(sev, >ev_subs, node) {
-   if (sev->fh != >vfh ||
+   if (sev->fh != originator ||
(sev->flags & V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK) ||
-   (changes & V4L2_EVENT_CTRL_CH_FLAGS) || autoupdate)
+   (changes & V4L2_EVENT_CTRL_CH_FLAGS))
v4l2_event_queue_fh(sev->fh, );
}
 }
 
-static void __uvc_ctrl_send_slave_event(struct uvc_fh *handle,
-   struct uvc_video_chain *chain, struct uvc_control *master, u32 slave_id)
+/*
+ * Send control change events for the slave of the @master control identified
+ * by the V4L2 ID @slave_id. The @handle identifies the event subscriber that
+ * generated the event and may be NULL for auto-update events.
+ */
+static void uvc_ctrl_send_slave_event(struct uvc_video_chain *chain,
+   struct uvc_fh *handle, struct uvc_control *master, u32 slave_id)
 {
struct uvc_control_mapping *mapping = NULL;
struct uvc_control *ctrl = NULL;
@@ -1267,11 +1270,10 @@ static void __uvc_ctrl_send_slave_event(struct uvc_fh 
*handle,
if (ctrl == NULL)
return;
 
-   if (__uvc_ctrl_get(handle ? handle->chain : chain, ctrl, mapping,
-  ) == 0)
+   if (__uvc_ctrl_get(chain, ctrl, mapping, ) == 0)
changes |= V4L2_EVENT_CTRL_CH_VALUE;
 
-   uvc_ctrl_send_event(handle, ctrl, mapping, val, changes);
+   uvc_ctrl_send_event(chain, handle, ctrl, mapping, val, changes);
 }
 
 static void uvc_ctrl_status_event_work(struct work_struct *work)
@@ -1279,38 +1281,37 @@ static void uvc_ctrl_status_event_work(struct 
work_struct *work)
struct uvc_device *dev = container_of(work, struct uvc_device,
  async_ctrl.work);
struct uvc_ctrl_work *w = >async_ctrl;
+   struct uvc_video_chain *chain = w->chain;
struct uvc_control_mapping *mapping;

Re: [PATCH v8 2/3] uvcvideo: send a control event when a Control Change interrupt arrives

2018-07-25 Thread Guennadi Liakhovetski
On Wed, 25 Jul 2018, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Wednesday, 18 July 2018 09:55:27 EEST Guennadi Liakhovetski wrote:
> > On Wed, 18 Jul 2018, Laurent Pinchart wrote:
> > > On Wednesday, 18 July 2018 00:30:45 EEST Guennadi Liakhovetski wrote:
> > >> On Tue, 17 Jul 2018, Laurent Pinchart wrote:
> > >>> On Thursday, 12 July 2018 10:30:46 EEST Guennadi Liakhovetski wrote:
> >  On Thu, 12 Jul 2018, Laurent Pinchart wrote:
> > > On Tuesday, 8 May 2018 18:07:43 EEST Guennadi Liakhovetski wrote:
> > >> UVC defines a method of handling asynchronous controls, which sends
> > >> a USB packet over the interrupt pipe. This patch implements support
> > >> for such packets by sending a control event to the user. Since this
> > >> can involve USB traffic and, therefore, scheduling, this has to be
> > >> done in a work queue.
> > >> 
> > >> Signed-off-by: Guennadi Liakhovetski
> > >> 
> > >> ---
> > >> 
> > >> v8:
> > >> 
> > >> * avoid losing events by delaying the status URB resubmission until
> > >>   after completion of the current event
> > >> * extract control value calculation into __uvc_ctrl_get_value()
> > >> * do not proactively return EBUSY if the previous control hasn't
> > >>   completed yet, let the camera handle such cases
> > >> * multiple cosmetic changes
> > >> 
> > >>  drivers/media/usb/uvc/uvc_ctrl.c   | 166 --
> > >>  drivers/media/usb/uvc/uvc_status.c | 112 ++---
> > >>  drivers/media/usb/uvc/uvc_v4l2.c   |   4 +-
> > >>  drivers/media/usb/uvc/uvcvideo.h   |  15 +++-
> > >>  include/uapi/linux/uvcvideo.h  |   2 +
> > >>  5 files changed, 255 insertions(+), 44 deletions(-)
> > >> 
> > >> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> > >> b/drivers/media/usb/uvc/uvc_ctrl.c index 2a213c8..796f86a 100644
> > >> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> > >> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> >  
> >  [snip]
> >  
> > >> +static void uvc_ctrl_status_event_work(struct work_struct *work)
> > >> +{
> > >> +struct uvc_device *dev = container_of(work, struct uvc_device,
> > >> +  async_ctrl.work);
> > >> +struct uvc_ctrl_work *w = >async_ctrl;
> > >> +struct uvc_control_mapping *mapping;
> > >> +struct uvc_control *ctrl = w->ctrl;
> > >> +unsigned int i;
> > >> +int ret;
> > >> +
> > >> +mutex_lock(>chain->ctrl_mutex);
> > >> +
> > >> +list_for_each_entry(mapping, >info.mappings, list) {
> > >> +s32 value = __uvc_ctrl_get_value(mapping, w->data);
> > >> +
> > >> +/*
> > >> + * So far none of the auto-update controls in the 
> > >> uvc_ctrls[]
> > >> + * table is mapped to a V4L control with slaves in the
> > >> + * uvc_ctrl_mappings[] list, so slave controls so far 
> > >> never have
> > >> + * handle == NULL, but this can change in the future
> > >> + */
> > >> +for (i = 0; i < ARRAY_SIZE(mapping->slave_ids); ++i) {
> > >> +if (!mapping->slave_ids[i])
> > >> +break;
> > >> +
> > >> +__uvc_ctrl_send_slave_event(ctrl->handle, 
> > >> w->chain,
> > >> +ctrl, 
> > >> mapping->slave_ids[i]);
> > >> +}
> > >> +
> > >> +uvc_ctrl_send_event(ctrl->handle, ctrl, mapping, value,
> > >> +V4L2_EVENT_CTRL_CH_VALUE);
> > >> +}
> > >> +
> > >> +mutex_unlock(>chain->ctrl_mutex);
> > >> +
> > >> +ctrl->handle = NULL;
> > > 
> > > Can't this race with a uvc_ctrl_set() call, resulting in
> > > ctrl->handle being NULL after the control gets set ?
> >  
> >  Right, it's better to set .handle to NULL before sending events.
> >  Something like
> >  
> >  mutex_lock();
> >  
> >  handle = ctrl->handle;
> >  ctrl->handle = NULL;
> >  
> >  list_for_each_entry() {
> > ...
> > uvc_ctrl_send_event(handle,...);
> >  }
> >  
> >  mutex_unlock();
> >  
> >  ?
> > >>> 
> > >>> I think you also have to take the same lock in the uvc_ctrl_set()
> > >>> function to fix the problem, otherwise the ctrl->handle = NULL line
> > >>> could still be executed after the ctrl->handle assignment in
> > >>> uvc_ctrl_set(), resulting in ctrl->handle being NULL while the control
> > >>> is being set.
> > >> 
> > >> Doesn't this mean, that you're attempting to send a new instance of the
> > >> same control before the previous has completed? In which case also
> > >> taking the lock in uvc_ctrl_set() wouldn't help either, because you can
> > >> anyway do that 

[PATCH v2 4/5] v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish

2018-07-25 Thread Ezequiel Garcia
v4l2_m2m_job_finish() is typically called in interrupt context.

Some implementation of .device_run might sleep, and so it's
desirable to avoid calling it directly from
v4l2_m2m_job_finish(), thus avoiding .device_run from running
in interrupt context.

Implement a deferred context that calls v4l2_m2m_try_run,
and gets scheduled by v4l2_m2m_job_finish().

Signed-off-by: Ezequiel Garcia 
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 36 +++---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index a25b45d8abeb..fb876ddec8a2 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -56,6 +56,7 @@ module_param(debug, bool, 0644);
  * @curr_ctx:  currently running instance
  * @job_queue: instances queued to run
  * @job_spinlock:  protects job_queue
+ * @job_work:  worker to run queued jobs.
  * @m2m_ops:   driver callbacks
  */
 struct v4l2_m2m_dev {
@@ -63,6 +64,7 @@ struct v4l2_m2m_dev {
 
struct list_headjob_queue;
spinlock_t  job_spinlock;
+   struct work_struct  job_work;
 
const struct v4l2_m2m_ops *m2m_ops;
 };
@@ -184,10 +186,11 @@ EXPORT_SYMBOL(v4l2_m2m_get_curr_priv);
 /**
  * v4l2_m2m_try_run() - select next job to perform and run it if possible
  * @m2m_dev: per-device context
+ * @try_lock: indicates if the queue lock should be taken
  *
  * Get next transaction (if present) from the waiting jobs list and run it.
  */
-static void v4l2_m2m_try_run(struct v4l2_m2m_dev *m2m_dev)
+static void v4l2_m2m_try_run(struct v4l2_m2m_dev *m2m_dev, bool try_lock)
 {
unsigned long flags;
 
@@ -210,7 +213,20 @@ static void v4l2_m2m_try_run(struct v4l2_m2m_dev *m2m_dev)
spin_unlock_irqrestore(_dev->job_spinlock, flags);
 
dprintk("Running job on m2m_ctx: %p\n", m2m_dev->curr_ctx);
+
+   /*
+* A m2m context lock is taken only after a m2m context
+* is picked from the queue and marked as running.
+* The lock is only needed if v4l2_m2m_try_run is called
+* from the async worker.
+*/
+   if (try_lock && m2m_dev->curr_ctx->q_lock)
+   mutex_lock(m2m_dev->curr_ctx->q_lock);
+
m2m_dev->m2m_ops->device_run(m2m_dev->curr_ctx->priv);
+
+   if (try_lock && m2m_dev->curr_ctx->q_lock)
+   mutex_unlock(m2m_dev->curr_ctx->q_lock);
 }
 
 /*
@@ -299,10 +315,22 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
struct v4l2_m2m_dev *m2m_dev = m2m_ctx->m2m_dev;
 
__v4l2_m2m_try_queue(m2m_dev, m2m_ctx);
-   v4l2_m2m_try_run(m2m_dev);
+   v4l2_m2m_try_run(m2m_dev, false);
 }
 EXPORT_SYMBOL_GPL(v4l2_m2m_try_schedule);
 
+/**
+ * v4l2_m2m_device_run_work() - run pending jobs for the context
+ * @work: Work structure used for scheduling the execution of this function.
+ */
+static void v4l2_m2m_device_run_work(struct work_struct *work)
+{
+   struct v4l2_m2m_dev *m2m_dev =
+   container_of(work, struct v4l2_m2m_dev, job_work);
+
+   v4l2_m2m_try_run(m2m_dev, true);
+}
+
 /**
  * v4l2_m2m_cancel_job() - cancel pending jobs for the context
  * @m2m_ctx: m2m context with jobs to be canceled
@@ -361,7 +389,8 @@ void v4l2_m2m_job_finish(struct v4l2_m2m_dev *m2m_dev,
/* This instance might have more buffers ready, but since we do not
 * allow more than one job on the job_queue per instance, each has
 * to be scheduled separately after the previous one finishes. */
-   v4l2_m2m_try_schedule(m2m_ctx);
+   __v4l2_m2m_try_queue(m2m_dev, m2m_ctx);
+   schedule_work(_dev->job_work);
 }
 EXPORT_SYMBOL(v4l2_m2m_job_finish);
 
@@ -628,6 +657,7 @@ struct v4l2_m2m_dev *v4l2_m2m_init(const struct 
v4l2_m2m_ops *m2m_ops)
m2m_dev->m2m_ops = m2m_ops;
INIT_LIST_HEAD(_dev->job_queue);
spin_lock_init(_dev->job_spinlock);
+   INIT_WORK(_dev->job_work, v4l2_m2m_device_run_work);
 
return m2m_dev;
 }
-- 
2.18.0



[PATCH v2 5/5] selftests: media_tests: Add a memory-to-memory concurrent stress test

2018-07-25 Thread Ezequiel Garcia
Add a test for the memory-to-memory framework, to exercise the
scheduling of concurrent jobs, using multiple contexts.

This test needs to be run using the vim2m virtual driver,
and so needs no hardware.

Signed-off-by: Ezequiel Garcia 
---
 tools/testing/selftests/media_tests/Makefile  |   4 +-
 .../selftests/media_tests/m2m_job_test.c  | 283 ++
 2 files changed, 286 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/media_tests/m2m_job_test.c

diff --git a/tools/testing/selftests/media_tests/Makefile 
b/tools/testing/selftests/media_tests/Makefile
index 60826d7d37d4..d2e8a6b685fb 100644
--- a/tools/testing/selftests/media_tests/Makefile
+++ b/tools/testing/selftests/media_tests/Makefile
@@ -1,6 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 #
 CFLAGS += -I../ -I../../../../usr/include/
-TEST_GEN_PROGS := media_device_test media_device_open video_device_test
+TEST_GEN_PROGS := media_device_test media_device_open video_device_test 
m2m_job_test
 
 include ../lib.mk
+
+LDLIBS += -lpthread
diff --git a/tools/testing/selftests/media_tests/m2m_job_test.c 
b/tools/testing/selftests/media_tests/m2m_job_test.c
new file mode 100644
index ..673e7b5cea3a
--- /dev/null
+++ b/tools/testing/selftests/media_tests/m2m_job_test.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) Collabora, Ltd.
+
+/*
+ * This file adds a test for the memory-to-memory
+ * framework.
+ *
+ * This test opens a user specified video device and then
+ * queues concurrent jobs. The jobs are totally dummy,
+ * its purpose is only to verify that each of the queued
+ * jobs is run, and is run only once.
+ *
+ * The vim2m driver is needed in order to run the test.
+ *
+ * Usage:
+ *  ./m2m-job-test -d /dev/videoX
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define V4L2_CID_TRANS_TIME_MSEC(V4L2_CID_USER_BASE + 0x1000)
+#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1001)
+
+#define MAX_TRANS_TIME_MSEC 500
+#define MAX_COUNT 300
+#define MAX_BUFFERS 5
+#define W 100
+#define H 100
+
+#ifndef DEBUG
+#define dprintf(fmt, arg...)   \
+   do {\
+   } while (0)
+#else
+#define dprintf(fmt, arg...) printf(fmt, ## arg)
+#endif
+
+static char video_device[256];
+static int thread_count;
+
+struct context {
+   int vfd;
+   unsigned int width;
+   unsigned int height;
+   int buffers;
+};
+
+static int req_src_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   buf.memory  = V4L2_MEMORY_MMAP;
+   buf.index   = i;
+   ret = ioctl(ctx->vfd, VIDIOC_QUERYBUF, );
+   if (ret)
+   return ret;
+   buf.bytesused = W*H*2;
+   ret = ioctl(ctx->vfd, VIDIOC_QBUF, );
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int req_dst_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory  = V4L2_MEMORY_MMAP;
+   buf.index   = i;
+   ret = ioctl(ctx->vfd, VIDIOC_QUERYBUF, );
+   if (ret)
+   return ret;
+   ret = ioctl(ctx->vfd, VIDIOC_QBUF, );
+   if (ret)
+   return ret;
+   }
+   return 0;
+}
+
+static int streamon(struct context *ctx)
+{
+   enum v4l2_buf_type type;
+   int ret;
+
+   type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   ret = ioctl(ctx->vfd, VIDIOC_STREAMON, );
+   if (ret)
+   return ret;
+
+   type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   ret = ioctl(ctx->vfd, VIDIOC_STREAMON, );
+   if (ret)
+   return ret;
+
+   return ret;
+}
+
+static int dqbuf(struct context *ctx)
+{
+   struct v4l2_buffer buf;
+   struct pollfd fds[] = {
+   { .fd = ctx->vfd, 

[PATCH v2 3/5] v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule

2018-07-25 Thread Ezequiel Garcia
From: Sakari Ailus 

The __v4l2_m2m_try_schedule function acquires and releases multiple
spinlocks. Simplify unlocking the job lock by adding labels to unlock
the lock and exit the function.

Signed-off-by: Sakari Ailus 
Signed-off-by: Ezequiel Garcia 
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 29 --
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 69a91c0030be..a25b45d8abeb 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -238,51 +238,48 @@ static void __v4l2_m2m_try_queue(struct v4l2_m2m_dev 
*m2m_dev, struct v4l2_m2m_c
 
/* If the context is aborted then don't schedule it */
if (m2m_ctx->job_flags & TRANS_ABORT) {
-   spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("Aborted context\n");
-   return;
+   goto job_unlock;
}
 
if (m2m_ctx->job_flags & TRANS_QUEUED) {
-   spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("On job queue already\n");
-   return;
+   goto job_unlock;
}
 
spin_lock_irqsave(_ctx->out_q_ctx.rdy_spinlock, flags_out);
if (list_empty(_ctx->out_q_ctx.rdy_queue)
&& !m2m_ctx->out_q_ctx.buffered) {
-   spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock,
-   flags_out);
-   spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("No input buffers available\n");
-   return;
+   goto out_unlock;
}
spin_lock_irqsave(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
if (list_empty(_ctx->cap_q_ctx.rdy_queue)
&& !m2m_ctx->cap_q_ctx.buffered) {
-   spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock,
-   flags_cap);
-   spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock,
-   flags_out);
-   spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("No output buffers available\n");
-   return;
+   goto cap_unlock;
}
spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock, flags_out);
 
if (m2m_dev->m2m_ops->job_ready
&& (!m2m_dev->m2m_ops->job_ready(m2m_ctx->priv))) {
-   spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("Driver not ready\n");
-   return;
+   goto job_unlock;
}
 
list_add_tail(_ctx->queue, _dev->job_queue);
m2m_ctx->job_flags |= TRANS_QUEUED;
 
spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
+   return;
+
+cap_unlock:
+   spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
+out_unlock:
+   spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock, flags_out);
+job_unlock:
+   spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
 }
 
 /**
-- 
2.18.0



[PATCH v2 2/5] v4l2-mem2mem: Avoid v4l2_m2m_prepare_buf from scheduling a job

2018-07-25 Thread Ezequiel Garcia
There is no need for v4l2_m2m_prepare_buf to try to schedule a job,
as it only prepares a buffer, but does not queue or changes the
state of the queue.

Remove the call to v4l2_m2m_try_schedule from v4l2_m2m_prepare_buf.

Signed-off-by: Ezequiel Garcia 
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index dfd796621b06..69a91c0030be 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -439,14 +439,9 @@ int v4l2_m2m_prepare_buf(struct file *file, struct 
v4l2_m2m_ctx *m2m_ctx,
 struct v4l2_buffer *buf)
 {
struct vb2_queue *vq;
-   int ret;
 
vq = v4l2_m2m_get_vq(m2m_ctx, buf->type);
-   ret = vb2_prepare_buf(vq, buf);
-   if (!ret)
-   v4l2_m2m_try_schedule(m2m_ctx);
-
-   return ret;
+   return vb2_prepare_buf(vq, buf);
 }
 EXPORT_SYMBOL_GPL(v4l2_m2m_prepare_buf);
 
-- 
2.18.0



[PATCH v2 1/5] v4l2-mem2mem: Fix missing v4l2_m2m_try_run call

2018-07-25 Thread Ezequiel Garcia
Commit 34dbb848d5e4 ("media: mem2mem: Remove excessive try_run call")
removed a redundant call to v4l2_m2m_try_run but instead introduced
a bug. Consider the following case:

 1) Context A schedules, queues and runs job A.
 2) While the m2m device is running, context B schedules
and queues job B. Job B cannot run, because it has to
wait for job A.
 3) Job A completes, calls v4l2_m2m_job_finish, and tries
to queue a job for context A, but since the context is
empty it won't do anything.

In this scenario, queued job B will never run. Fix this by calling
v4l2_m2m_try_run from v4l2_m2m_try_schedule.

While here, add more documentation to these functions.

Fixes: 34dbb848d5e4 ("media: mem2mem: Remove excessive try_run call")
Signed-off-by: Ezequiel Garcia 
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 32 +++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 5f9cd5b74cda..dfd796621b06 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -209,15 +209,23 @@ static void v4l2_m2m_try_run(struct v4l2_m2m_dev *m2m_dev)
m2m_dev->curr_ctx->job_flags |= TRANS_RUNNING;
spin_unlock_irqrestore(_dev->job_spinlock, flags);
 
+   dprintk("Running job on m2m_ctx: %p\n", m2m_dev->curr_ctx);
m2m_dev->m2m_ops->device_run(m2m_dev->curr_ctx->priv);
 }
 
-void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
+/*
+ * __v4l2_m2m_try_queue() - queue a job
+ * @m2m_dev: m2m device
+ * @m2m_ctx: m2m context
+ *
+ * Check if this context is ready to queue a job.
+ *
+ * This function can run in interrupt context.
+ */
+static void __v4l2_m2m_try_queue(struct v4l2_m2m_dev *m2m_dev, struct 
v4l2_m2m_ctx *m2m_ctx)
 {
-   struct v4l2_m2m_dev *m2m_dev;
unsigned long flags_job, flags_out, flags_cap;
 
-   m2m_dev = m2m_ctx->m2m_dev;
dprintk("Trying to schedule a job for m2m_ctx: %p\n", m2m_ctx);
 
if (!m2m_ctx->out_q_ctx.q.streaming
@@ -275,7 +283,25 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
m2m_ctx->job_flags |= TRANS_QUEUED;
 
spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
+}
+
+/**
+ * v4l2_m2m_try_schedule() - schedule and possibly run a job for any context
+ * @m2m_ctx: m2m context
+ *
+ * Check if this context is ready to queue a job. If suitable,
+ * run the next queued job on the mem2mem device.
+ *
+ * This function shouldn't run in interrupt context.
+ *
+ * Note that v4l2_m2m_try_schedule() can schedule one job for this context,
+ * and then run another job for another context.
+ */
+void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
+{
+   struct v4l2_m2m_dev *m2m_dev = m2m_ctx->m2m_dev;
 
+   __v4l2_m2m_try_queue(m2m_dev, m2m_ctx);
v4l2_m2m_try_run(m2m_dev);
 }
 EXPORT_SYMBOL_GPL(v4l2_m2m_try_schedule);
-- 
2.18.0



[PATCH v2 0/5] Make sure .device_run is always called in non-atomic context

2018-07-25 Thread Ezequiel Garcia
This series goal is to avoid drivers from having ad-hoc code
to call .device_run in non-atomic context. Currently, .device_run
can be called via v4l2_m2m_job_finish(), potentially running
in interrupt context.

This series will be useful for the upcoming Request API, where drivers
typically require .device_run to be called in non-atomic context for
v4l2_ctrl_request_setup() calls.

The solution is to add a per-device worker that is scheduled
by v4l2_m2m_job_finish, which replaces drivers having a threaded interrupt
or similar.

This change allows v4l2_m2m_job_finish() to be called in interrupt
context, separating .device_run and v4l2_m2m_job_finish() contexts.

It's worth mentioning that v4l2_m2m_cancel_job() doesn't need
to flush or cancel the new worker, because the job_spinlock
synchronizes both and also because the core prevents simultaneous
jobs. Either v4l2_m2m_cancel_job() will wait for the worker, or the
worker will be unable to run a new job.

While working on this series, I found a bug recently introduced on
commit "media: mem2mem: Remove excessive try_run call". The first patch
fixes the bug.

In order to test the change, and make sure no regressions are
introduced, a kselftest test is added to stress the mem2mem framework.

Patches are based on v4.18-rc4 plus:

34dbb848d5e47 "media: mem2mem: Remove excessive try_run call"

Ezequiel Garcia (4):
  v4l2-mem2mem: Fix missing v4l2_m2m_try_run call
  v4l2-mem2mem: Avoid v4l2_m2m_prepare_buf from scheduling a job
  v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish
  selftests: media_tests: Add a memory-to-memory concurrent stress test

Sakari Ailus (1):
  v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule

 drivers/media/v4l2-core/v4l2-mem2mem.c| 104 +--
 tools/testing/selftests/media_tests/Makefile  |   4 +-
 .../selftests/media_tests/m2m_job_test.c  | 283 ++
 3 files changed, 362 insertions(+), 29 deletions(-)
 create mode 100644 tools/testing/selftests/media_tests/m2m_job_test.c

-- 
2.18.0



Re: [PATCH v8 2/3] uvcvideo: send a control event when a Control Change interrupt arrives

2018-07-25 Thread Laurent Pinchart
Hi Guennadi,

On Wednesday, 18 July 2018 09:55:27 EEST Guennadi Liakhovetski wrote:
> On Wed, 18 Jul 2018, Laurent Pinchart wrote:
> > On Wednesday, 18 July 2018 00:30:45 EEST Guennadi Liakhovetski wrote:
> >> On Tue, 17 Jul 2018, Laurent Pinchart wrote:
> >>> On Thursday, 12 July 2018 10:30:46 EEST Guennadi Liakhovetski wrote:
>  On Thu, 12 Jul 2018, Laurent Pinchart wrote:
> > On Tuesday, 8 May 2018 18:07:43 EEST Guennadi Liakhovetski wrote:
> >> UVC defines a method of handling asynchronous controls, which sends
> >> a USB packet over the interrupt pipe. This patch implements support
> >> for such packets by sending a control event to the user. Since this
> >> can involve USB traffic and, therefore, scheduling, this has to be
> >> done in a work queue.
> >> 
> >> Signed-off-by: Guennadi Liakhovetski
> >> 
> >> ---
> >> 
> >> v8:
> >> 
> >> * avoid losing events by delaying the status URB resubmission until
> >>   after completion of the current event
> >> * extract control value calculation into __uvc_ctrl_get_value()
> >> * do not proactively return EBUSY if the previous control hasn't
> >>   completed yet, let the camera handle such cases
> >> * multiple cosmetic changes
> >> 
> >>  drivers/media/usb/uvc/uvc_ctrl.c   | 166 --
> >>  drivers/media/usb/uvc/uvc_status.c | 112 ++---
> >>  drivers/media/usb/uvc/uvc_v4l2.c   |   4 +-
> >>  drivers/media/usb/uvc/uvcvideo.h   |  15 +++-
> >>  include/uapi/linux/uvcvideo.h  |   2 +
> >>  5 files changed, 255 insertions(+), 44 deletions(-)
> >> 
> >> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> >> b/drivers/media/usb/uvc/uvc_ctrl.c index 2a213c8..796f86a 100644
> >> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> >> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
>  
>  [snip]
>  
> >> +static void uvc_ctrl_status_event_work(struct work_struct *work)
> >> +{
> >> +  struct uvc_device *dev = container_of(work, struct uvc_device,
> >> +async_ctrl.work);
> >> +  struct uvc_ctrl_work *w = >async_ctrl;
> >> +  struct uvc_control_mapping *mapping;
> >> +  struct uvc_control *ctrl = w->ctrl;
> >> +  unsigned int i;
> >> +  int ret;
> >> +
> >> +  mutex_lock(>chain->ctrl_mutex);
> >> +
> >> +  list_for_each_entry(mapping, >info.mappings, list) {
> >> +  s32 value = __uvc_ctrl_get_value(mapping, w->data);
> >> +
> >> +  /*
> >> +   * So far none of the auto-update controls in the 
> >> uvc_ctrls[]
> >> +   * table is mapped to a V4L control with slaves in the
> >> +   * uvc_ctrl_mappings[] list, so slave controls so far 
> >> never have
> >> +   * handle == NULL, but this can change in the future
> >> +   */
> >> +  for (i = 0; i < ARRAY_SIZE(mapping->slave_ids); ++i) {
> >> +  if (!mapping->slave_ids[i])
> >> +  break;
> >> +
> >> +  __uvc_ctrl_send_slave_event(ctrl->handle, 
> >> w->chain,
> >> +  ctrl, 
> >> mapping->slave_ids[i]);
> >> +  }
> >> +
> >> +  uvc_ctrl_send_event(ctrl->handle, ctrl, mapping, value,
> >> +  V4L2_EVENT_CTRL_CH_VALUE);
> >> +  }
> >> +
> >> +  mutex_unlock(>chain->ctrl_mutex);
> >> +
> >> +  ctrl->handle = NULL;
> > 
> > Can't this race with a uvc_ctrl_set() call, resulting in
> > ctrl->handle being NULL after the control gets set ?
>  
>  Right, it's better to set .handle to NULL before sending events.
>  Something like
>  
>  mutex_lock();
>  
>  handle = ctrl->handle;
>  ctrl->handle = NULL;
>  
>  list_for_each_entry() {
>   ...
>   uvc_ctrl_send_event(handle,...);
>  }
>  
>  mutex_unlock();
>  
>  ?
> >>> 
> >>> I think you also have to take the same lock in the uvc_ctrl_set()
> >>> function to fix the problem, otherwise the ctrl->handle = NULL line
> >>> could still be executed after the ctrl->handle assignment in
> >>> uvc_ctrl_set(), resulting in ctrl->handle being NULL while the control
> >>> is being set.
> >> 
> >> Doesn't this mean, that you're attempting to send a new instance of the
> >> same control before the previous has completed? In which case also
> >> taking the lock in uvc_ctrl_set() wouldn't help either, because you can
> >> anyway do that immediately after the first instance, before the
> >> completion even has fired.
> > 
> > You're right that it won't solve the race completely, but wouldn't it at
> > least prevent ctrl->handle from being NULL ? We can't 

[PATCH v4 03/34] media: v4l: Add new 10-bit packed grayscale format

2018-07-25 Thread Todor Tomov
The new format will be called V4L2_PIX_FMT_Y10P.
It is similar to the V4L2_PIX_FMT_SBGGR10P family formats
but V4L2_PIX_FMT_Y10P is a grayscale format.

Signed-off-by: Todor Tomov 
---
 Documentation/media/uapi/v4l/pixfmt-y10p.rst | 33 
 Documentation/media/uapi/v4l/yuv-formats.rst |  1 +
 drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
 include/uapi/linux/videodev2.h   |  1 +
 4 files changed, 36 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-y10p.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-y10p.rst 
b/Documentation/media/uapi/v4l/pixfmt-y10p.rst
new file mode 100644
index 000..13b5713
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-y10p.rst
@@ -0,0 +1,33 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-Y10P:
+
+**
+V4L2_PIX_FMT_Y10P ('Y10P')
+**
+
+Grey-scale image as a MIPI RAW10 packed array
+
+
+Description
+===
+
+This is a packed grey-scale image format with a depth of 10 bits per
+pixel. Every four consecutive pixels are packed into 5 bytes. Each of
+the first 4 bytes contain the 8 high order bits of the pixels, and
+the 5th byte contains the 2 least significants bits of each pixel,
+in the same order.
+
+**Bit-packed representation.**
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths: 8 8 8 8 64
+
+* - Y'\ :sub:`00[9:2]`
+  - Y'\ :sub:`01[9:2]`
+  - Y'\ :sub:`02[9:2]`
+  - Y'\ :sub:`03[9:2]`
+  - Y'\ :sub:`03[1:0]`\ (bits 7--6) Y'\ :sub:`02[1:0]`\ (bits 5--4)
+   Y'\ :sub:`01[1:0]`\ (bits 3--2) Y'\ :sub:`00[1:0]`\ (bits 1--0)
diff --git a/Documentation/media/uapi/v4l/yuv-formats.rst 
b/Documentation/media/uapi/v4l/yuv-formats.rst
index 3334ea4..9ab0592 100644
--- a/Documentation/media/uapi/v4l/yuv-formats.rst
+++ b/Documentation/media/uapi/v4l/yuv-formats.rst
@@ -29,6 +29,7 @@ to brightness information.
 pixfmt-y10
 pixfmt-y12
 pixfmt-y10b
+pixfmt-y10p
 pixfmt-y16
 pixfmt-y16-be
 pixfmt-y8i
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 04e1231..e8f7c89 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1184,6 +1184,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_Y16:  descr = "16-bit Greyscale"; break;
case V4L2_PIX_FMT_Y16_BE:   descr = "16-bit Greyscale BE"; break;
case V4L2_PIX_FMT_Y10BPACK: descr = "10-bit Greyscale (Packed)"; 
break;
+   case V4L2_PIX_FMT_Y10P: descr = "10-bit Greyscale (MIPI 
Packed)"; break;
case V4L2_PIX_FMT_Y8I:  descr = "Interleaved 8-bit Greyscale"; 
break;
case V4L2_PIX_FMT_Y12I: descr = "Interleaved 12-bit Greyscale"; 
break;
case V4L2_PIX_FMT_Z16:  descr = "16-bit Depth"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index a15e03b..fc177d8 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -522,6 +522,7 @@ struct v4l2_pix_format {
 
 /* Grey bit-packed formats */
 #define V4L2_PIX_FMT_Y10BPACKv4l2_fourcc('Y', '1', '0', 'B') /* 10  
Greyscale bit-packed */
+#define V4L2_PIX_FMT_Y10Pv4l2_fourcc('Y', '1', '0', 'P') /* 10  Greyscale, 
MIPI RAW10 packed */
 
 /* Palette formats */
 #define V4L2_PIX_FMT_PAL8v4l2_fourcc('P', 'A', 'L', '8') /*  8  8-bit 
palette */
-- 
2.7.4



[PATCH v4 06/34] media: camss: Fix OF node usage

2018-07-25 Thread Todor Tomov
of_graph_get_next_endpoint increases the refcount of the returned
node and decreases the refcount of the passed node. Take this into
account and use of_node_put properly.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss.c 
b/drivers/media/platform/qcom/camss/camss.c
index 45285eb..abf6184 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -296,6 +296,7 @@ static int camss_of_parse_ports(struct device *dev,
if (of_device_is_available(node))
notifier->num_subdevs++;
 
+   of_node_put(node);
size = sizeof(*notifier->subdevs) * notifier->num_subdevs;
notifier->subdevs = devm_kzalloc(dev, size, GFP_KERNEL);
if (!notifier->subdevs) {
@@ -326,16 +327,16 @@ static int camss_of_parse_ports(struct device *dev,
}
 
remote = of_graph_get_remote_port_parent(node);
-   of_node_put(node);
-
if (!remote) {
dev_err(dev, "Cannot get remote parent\n");
+   of_node_put(node);
return -EINVAL;
}
 
csd->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
csd->asd.match.fwnode = of_fwnode_handle(remote);
}
+   of_node_put(node);
 
return notifier->num_subdevs;
 }
-- 
2.7.4



[PATCH v4 04/34] media: Rename CAMSS driver path

2018-07-25 Thread Todor Tomov
Support for camera subsystem on QComm MSM8996/APQ8096 is to be added
so remove hardware version from CAMSS driver's path.

Signed-off-by: Todor Tomov 
---
 MAINTAINERS  | 2 +-
 drivers/media/platform/Kconfig   | 2 +-
 drivers/media/platform/Makefile  | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/Makefile   | 0
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-csid.c   | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-csid.h   | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-csiphy.c | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-csiphy.h | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-ispif.c  | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-ispif.h  | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-vfe.c| 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-vfe.h| 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-video.c  | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss-video.h  | 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss.c| 2 +-
 drivers/media/platform/qcom/{camss-8x16 => camss}/camss.h| 2 +-
 16 files changed, 15 insertions(+), 15 deletions(-)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/Makefile (100%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-csid.c (99%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-csid.h (98%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-csiphy.c (99%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-csiphy.h (97%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-ispif.c (99%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-ispif.h (98%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-vfe.c (99%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-vfe.h (98%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-video.c (99%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss-video.h (98%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss.c (99%)
 rename drivers/media/platform/qcom/{camss-8x16 => camss}/camss.h (98%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 329d428..f8b3a1b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11918,7 +11918,7 @@ 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-8x16/
+F: drivers/media/platform/qcom/camss/
 
 QUALCOMM CPUFREQ DRIVER MSM8996/APQ8096
 M:  Ilia Lin 
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1cf4011..2bb88d3 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -90,7 +90,7 @@ config VIDEO_PXA27x
  This is a v4l2 driver for the PXA27x Quick Capture Interface
 
 config VIDEO_QCOM_CAMSS
-   tristate "Qualcomm 8x16 V4L2 Camera Subsystem driver"
+   tristate "Qualcomm V4L2 Camera Subsystem driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 890f919..fac3a89 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -88,7 +88,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)  += mtk-mdp/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
 
-obj-$(CONFIG_VIDEO_QCOM_CAMSS) += qcom/camss-8x16/
+obj-$(CONFIG_VIDEO_QCOM_CAMSS) += qcom/camss/
 
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
 
diff --git a/drivers/media/platform/qcom/camss-8x16/Makefile 
b/drivers/media/platform/qcom/camss/Makefile
similarity index 100%
rename from drivers/media/platform/qcom/camss-8x16/Makefile
rename to drivers/media/platform/qcom/camss/Makefile
diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
similarity index 99%
rename from drivers/media/platform/qcom/camss-8x16/camss-csid.c
rename to drivers/media/platform/qcom/camss/camss-csid.c
index 226f36e..39ea27b 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -4,7 +4,7 @@
  * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
  *
  * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
- * Copyright (C) 2015-2017 Linaro Ltd.
+ * Copyright (C) 2015-2018 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
diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csid.h 

[PATCH v4 09/34] media: camss: Unify the clock names

2018-07-25 Thread Todor Tomov
Use more logical clock names - similar to the names in documentation.
This will allow better handling of the clocks in the driver when support
for more hardware versions is added - equivalent clocks on different
hardware versions will have the same name.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss.c 
b/drivers/media/platform/qcom/camss/camss.c
index abf6184..0b663e0 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -32,8 +32,7 @@ static const struct resources csiphy_res[] = {
/* CSIPHY0 */
{
.regulator = { NULL },
-   .clock = { "camss_top_ahb", "ispif_ahb",
-  "camss_ahb", "csiphy0_timer" },
+   .clock = { "top_ahb", "ispif_ahb", "ahb", "csiphy0_timer" },
.clock_rate = { { 0 },
{ 0 },
{ 0 },
@@ -45,8 +44,7 @@ static const struct resources csiphy_res[] = {
/* CSIPHY1 */
{
.regulator = { NULL },
-   .clock = { "camss_top_ahb", "ispif_ahb",
-  "camss_ahb", "csiphy1_timer" },
+   .clock = { "top_ahb", "ispif_ahb", "ahb", "csiphy1_timer" },
.clock_rate = { { 0 },
{ 0 },
{ 0 },
@@ -60,8 +58,7 @@ static const struct resources csid_res[] = {
/* CSID0 */
{
.regulator = { "vdda" },
-   .clock = { "camss_top_ahb", "ispif_ahb",
-  "csi0_ahb", "camss_ahb",
+   .clock = { "top_ahb", "ispif_ahb", "csi0_ahb", "ahb",
   "csi0", "csi0_phy", "csi0_pix", "csi0_rdi" },
.clock_rate = { { 0 },
{ 0 },
@@ -78,8 +75,7 @@ static const struct resources csid_res[] = {
/* CSID1 */
{
.regulator = { "vdda" },
-   .clock = { "camss_top_ahb", "ispif_ahb",
-  "csi1_ahb", "camss_ahb",
+   .clock = { "top_ahb", "ispif_ahb", "csi1_ahb", "ahb",
   "csi1", "csi1_phy", "csi1_pix", "csi1_rdi" },
.clock_rate = { { 0 },
{ 0 },
@@ -96,10 +92,10 @@ static const struct resources csid_res[] = {
 
 static const struct resources_ispif ispif_res = {
/* ISPIF */
-   .clock = { "camss_top_ahb", "camss_ahb", "ispif_ahb",
+   .clock = { "top_ahb", "ahb", "ispif_ahb",
   "csi0", "csi0_pix", "csi0_rdi",
   "csi1", "csi1_pix", "csi1_rdi" },
-   .clock_for_reset = { "camss_vfe_vfe", "camss_csi_vfe" },
+   .clock_for_reset = { "vfe0", "csi_vfe0" },
.reg = { "ispif", "csi_clk_mux" },
.interrupt = "ispif"
 
@@ -108,8 +104,8 @@ static const struct resources_ispif ispif_res = {
 static const struct resources vfe_res = {
/* VFE0 */
.regulator = { NULL },
-   .clock = { "camss_top_ahb", "camss_vfe_vfe", "camss_csi_vfe",
-  "iface", "bus", "camss_ahb" },
+   .clock = { "top_ahb", "vfe0", "csi_vfe0",
+  "vfe_ahb", "vfe_axi", "ahb" },
.clock_rate = { { 0 },
{ 5000, 8000, 1, 16000,
  17778, 2, 26667, 32000,
-- 
2.7.4



[PATCH v4 07/34] media: camss: csiphy: Ensure clock mux config is done before the rest

2018-07-25 Thread Todor Tomov
Add a write memory barier after clock mux config and before the rest
of the csiphy config.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csiphy.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
b/drivers/media/platform/qcom/camss/camss-csiphy.c
index b37e691..2a9adcd 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -364,6 +364,7 @@ static int csiphy_stream_on(struct csiphy_device *csiphy)
val |= cfg->csid_id;
}
writel_relaxed(val, csiphy->base_clk_mux);
+   wmb();
 
writel_relaxed(0x1, csiphy->base +
   CAMSS_CSI_PHY_GLBL_T_INIT_CFG0);
-- 
2.7.4



[PATCH v4 10/34] media: camss: csiphy: Update settle count calculation

2018-07-25 Thread Todor Tomov
Update settle count calculation as per specification.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csiphy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 2a9adcd..6158ffd 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -329,7 +329,7 @@ static u8 csiphy_settle_cnt_calc(struct csiphy_device 
*csiphy)
t_hs_settle = (t_hs_prepare_max + t_hs_prepare_zero_min) / 2;
 
timer_period = div_u64(1LL, csiphy->timer_clk_rate);
-   settle_cnt = t_hs_settle / timer_period;
+   settle_cnt = t_hs_settle / timer_period - 1;
 
return settle_cnt;
 }
-- 
2.7.4



[PATCH v4 05/34] media: camss: Use SPDX license headers

2018-07-25 Thread Todor Tomov
Use SPDX license headers for all files of the Qualcomm CAMSS driver.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c   | 10 +-
 drivers/media/platform/qcom/camss/camss-csid.h   | 10 +-
 drivers/media/platform/qcom/camss/camss-csiphy.c | 10 +-
 drivers/media/platform/qcom/camss/camss-csiphy.h | 10 +-
 drivers/media/platform/qcom/camss/camss-ispif.c  | 10 +-
 drivers/media/platform/qcom/camss/camss-ispif.h  | 10 +-
 drivers/media/platform/qcom/camss/camss-vfe.c| 10 +-
 drivers/media/platform/qcom/camss/camss-vfe.h| 10 +-
 drivers/media/platform/qcom/camss/camss-video.c  | 10 +-
 drivers/media/platform/qcom/camss/camss-video.h  | 10 +-
 drivers/media/platform/qcom/camss/camss.c| 10 +-
 drivers/media/platform/qcom/camss/camss.h| 10 +-
 12 files changed, 12 insertions(+), 108 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index 39ea27b..c0fef17 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * camss-csid.c
  *
@@ -5,15 +6,6 @@
  *
  * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2018 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 
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h 
b/drivers/media/platform/qcom/camss/camss-csid.h
index 801..ae1d045 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * camss-csid.h
  *
@@ -5,15 +6,6 @@
  *
  * Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2018 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.
  */
 #ifndef QC_MSM_CAMSS_CSID_H
 #define QC_MSM_CAMSS_CSID_H
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 642de25..b37e691 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * camss-csiphy.c
  *
@@ -5,15 +6,6 @@
  *
  * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
  * Copyright (C) 2016-2018 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 
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h 
b/drivers/media/platform/qcom/camss/camss-csiphy.h
index 9a42209..76fa239 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.h
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * camss-csiphy.h
  *
@@ -5,15 +6,6 @@
  *
  * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
  * Copyright (C) 2016-2018 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.
  */
 #ifndef QC_MSM_CAMSS_CSIPHY_H
 #define QC_MSM_CAMSS_CSIPHY_H
diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c 
b/drivers/media/platform/qcom/camss/camss-ispif.c
index 636d5e7..5ad719d 100644

[PATCH v4 08/34] media: dt-bindings: media: qcom,camss: Unify the clock names

2018-07-25 Thread Todor Tomov
Use more logical clock names - similar to the names in documentation.
This will allow better handling of the clocks in the driver when support
for more hardware versions is added - equivalent clocks on different
hardware versions will have the same name.

CC: Rob Herring 
CC: Mark Rutland 
CC: devicet...@vger.kernel.org
Signed-off-by: Todor Tomov 
---
 .../devicetree/bindings/media/qcom,camss.txt   | 24 +++---
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt 
b/Documentation/devicetree/bindings/media/qcom,camss.txt
index cadeceb..032e8ed 100644
--- a/Documentation/devicetree/bindings/media/qcom,camss.txt
+++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
@@ -53,7 +53,7 @@ Qualcomm Camera Subsystem
Usage: required
Value type: 
Definition: Should contain the following entries:
-- "camss_top_ahb"
+- "top_ahb"
 - "ispif_ahb"
 - "csiphy0_timer"
 - "csiphy1_timer"
@@ -67,11 +67,11 @@ Qualcomm Camera Subsystem
 - "csi1_phy"
 - "csi1_pix"
 - "csi1_rdi"
-- "camss_ahb"
-- "camss_vfe_vfe"
-- "camss_csi_vfe"
-- "iface"
-- "bus"
+- "ahb"
+- "vfe0"
+- "csi_vfe0"
+- "vfe_ahb"
+- "vfe_axi"
 - vdda-supply:
Usage: required
Value type: 
@@ -161,7 +161,7 @@ Qualcomm Camera Subsystem
< GCC_CAMSS_CSI_VFE0_CLK>,
< GCC_CAMSS_VFE_AHB_CLK>,
< GCC_CAMSS_VFE_AXI_CLK>;
-clock-names = "camss_top_ahb",
+clock-names = "top_ahb",
 "ispif_ahb",
 "csiphy0_timer",
 "csiphy1_timer",
@@ -175,11 +175,11 @@ Qualcomm Camera Subsystem
 "csi1_phy",
 "csi1_pix",
 "csi1_rdi",
-"camss_ahb",
-"camss_vfe_vfe",
-"camss_csi_vfe",
-"iface",
-"bus";
+"ahb",
+"vfe0",
+"csi_vfe0",
+"vfe_ahb",
+"vfe_axi";
vdda-supply = <_l2>;
iommus = <_iommu 3>;
ports {
-- 
2.7.4



[PATCH v4 14/34] media: camss: vfe: Do not disable CAMIF when clearing its status

2018-07-25 Thread Todor Tomov
Use "no change" value when clearing CAMIF status and make sure
this is done before configuring the new command.

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

diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c 
b/drivers/media/platform/qcom/camss/camss-vfe.c
index 77167f1..15a1a01 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -156,6 +156,7 @@
 #define VFE_0_CAMIF_CMD0x2f4
 #define VFE_0_CAMIF_CMD_DISABLE_FRAME_BOUNDARY 0
 #define VFE_0_CAMIF_CMD_ENABLE_FRAME_BOUNDARY  1
+#define VFE_0_CAMIF_CMD_NO_CHANGE  3
 #define VFE_0_CAMIF_CMD_CLEAR_CAMIF_STATUS (1 << 2)
 #define VFE_0_CAMIF_CFG0x2f8
 #define VFE_0_CAMIF_CFG_VFE_OUTPUT_EN  (1 << 6)
@@ -1021,8 +1022,10 @@ static void vfe_set_camif_cfg(struct vfe_device *vfe, 
struct vfe_line *line)
 
 static void vfe_set_camif_cmd(struct vfe_device *vfe, u32 cmd)
 {
-   writel_relaxed(VFE_0_CAMIF_CMD_CLEAR_CAMIF_STATUS,
+   writel_relaxed(VFE_0_CAMIF_CMD_CLEAR_CAMIF_STATUS |
+  VFE_0_CAMIF_CMD_NO_CHANGE,
   vfe->base + VFE_0_CAMIF_CMD);
+   wmb();
 
writel_relaxed(cmd, vfe->base + VFE_0_CAMIF_CMD);
 }
-- 
2.7.4



[PATCH v4 12/34] media: camss: vfe: Fix to_vfe() macro member name

2018-07-25 Thread Todor Tomov
Use the member name which is "line" instead of the pointer argument.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-vfe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c 
b/drivers/media/platform/qcom/camss/camss-vfe.c
index 256dc2d..51ad3f8 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -30,7 +30,7 @@
((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)
+   container_of(vfe_line_array(ptr_line), struct vfe_device, line)
 
 #define VFE_0_HW_VERSION   0x000
 
-- 
2.7.4



[PATCH v4 16/34] media: dt-bindings: media: qcom,camss: Add 8996 bindings

2018-07-25 Thread Todor Tomov
Update binding document for MSM8996.

CC: Rob Herring 
CC: Mark Rutland 
CC: devicet...@vger.kernel.org
Signed-off-by: Todor Tomov 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/media/qcom,camss.txt   | 44 +++---
 1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt 
b/Documentation/devicetree/bindings/media/qcom,camss.txt
index e938eb0..09eb6ed 100644
--- a/Documentation/devicetree/bindings/media/qcom,camss.txt
+++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
@@ -5,8 +5,9 @@ Qualcomm Camera Subsystem
 - compatible:
Usage: required
Value type: 
-   Definition: Should contain:
+   Definition: Should contain one of:
- "qcom,msm8916-camss"
+   - "qcom,msm8996-camss"
 - reg:
Usage: required
Value type: 
@@ -19,11 +20,16 @@ Qualcomm Camera Subsystem
- "csiphy0_clk_mux"
- "csiphy1"
- "csiphy1_clk_mux"
+   - "csiphy2" (8996 only)
+   - "csiphy2_clk_mux" (8996 only)
- "csid0"
- "csid1"
+   - "csid2"   (8996 only)
+   - "csid3"   (8996 only)
- "ispif"
- "csi_clk_mux"
- "vfe0"
+   - "vfe1"(8996 only)
 - interrupts:
Usage: required
Value type: 
@@ -34,10 +40,14 @@ Qualcomm Camera Subsystem
Definition: Should contain the following entries:
- "csiphy0"
- "csiphy1"
+   - "csiphy2" (8996 only)
- "csid0"
- "csid1"
+   - "csid2"   (8996 only)
+   - "csid3"   (8996 only)
- "ispif"
- "vfe0"
+   - "vfe1"(8996 only)
 - power-domains:
Usage: required
Value type: 
@@ -57,6 +67,7 @@ Qualcomm Camera Subsystem
- "ispif_ahb"
- "csiphy0_timer"
- "csiphy1_timer"
+   - "csiphy2_timer"   (8996 only)
- "csi0_ahb"
- "csi0"
- "csi0_phy"
@@ -67,9 +78,25 @@ Qualcomm Camera Subsystem
- "csi1_phy"
- "csi1_pix"
- "csi1_rdi"
+   - "csi2_ahb"(8996 only)
+   - "csi2"(8996 only)
+   - "csi2_phy"(8996 only)
+   - "csi2_pix"(8996 only)
+   - "csi2_rdi"(8996 only)
+   - "csi3_ahb"(8996 only)
+   - "csi3"(8996 only)
+   - "csi3_phy"(8996 only)
+   - "csi3_pix"(8996 only)
+   - "csi3_rdi"(8996 only)
- "ahb"
- "vfe0"
- "csi_vfe0"
+   - "vfe0_ahb",   (8996 only)
+   - "vfe0_stream",(8996 only)
+   - "vfe1",   (8996 only)
+   - "csi_vfe1",   (8996 only)
+   - "vfe1_ahb",   (8996 only)
+   - "vfe1_stream",(8996 only)
- "vfe_ahb"
- "vfe_axi"
 - vdda-supply:
@@ -90,14 +117,18 @@ Qualcomm Camera Subsystem
- reg:
Usage: required
Value type: 
-   Definition: Selects CSI2 PHY interface - PHY0 or PHY1.
+   Definition: Selects CSI2 PHY interface - PHY0, PHY1
+   or PHY2 (8996 only)
Endpoint node properties:
- clock-lanes:
Usage: required
Value type: 
-   Definition: The physical clock lane index. The value
-   must always be <1> as the physical clock
-   lane is lane 1.
+   Definition: The physical clock lane index. On 8916
+   the value must always be <1> as the physical
+   clock lane is lane 1. On 8996 the value must
+   always be <7> as the hardware supports D-PHY
+   and C-PHY, indexes are in a common set and
+   D-PHY physical clock lane is labeled as 7.
- data-lanes:
Usage: required
Value type: 
@@ -105,7 +136,8 @@ Qualcomm Camera Subsystem
Position of an entry determines the logical
lane number, while the value of an entry
indicates physical lane index. Lane swapping
-

[PATCH v4 11/34] media: camss: csid: Configure data type and decode format properly

2018-07-25 Thread Todor Tomov
The CSID decodes the input data stream. When the input comes from
the Test Generator the format of the stream is set on the source
media pad. When the input comes from the CSIPHY the format is the
one on the sink media pad. Use the proper format for each case.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index c0fef17..3cde07e 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -384,9 +384,6 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
!media_entity_remote_pad(>pads[MSM_CSID_PAD_SINK]))
return -ENOLINK;
 
-   dt = csid_get_fmt_entry(csid->fmt[MSM_CSID_PAD_SRC].code)->
-   data_type;
-
if (tg->enabled) {
/* Config Test Generator */
struct v4l2_mbus_framefmt *f =
@@ -408,6 +405,9 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
writel_relaxed(val, csid->base +
   CAMSS_CSID_TG_DT_n_CGG_0(0));
 
+   dt = csid_get_fmt_entry(
+   csid->fmt[MSM_CSID_PAD_SRC].code)->data_type;
+
/* 5:0 data type */
val = dt;
writel_relaxed(val, csid->base +
@@ -417,6 +417,9 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
val = tg->payload_mode;
writel_relaxed(val, csid->base +
   CAMSS_CSID_TG_DT_n_CGG_2(0));
+
+   df = csid_get_fmt_entry(
+   
csid->fmt[MSM_CSID_PAD_SRC].code)->decode_format;
} else {
struct csid_phy_config *phy = >phy;
 
@@ -431,13 +434,16 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
 
writel_relaxed(val,
   csid->base + CAMSS_CSID_CORE_CTRL_1);
+
+   dt = csid_get_fmt_entry(
+   csid->fmt[MSM_CSID_PAD_SINK].code)->data_type;
+   df = csid_get_fmt_entry(
+   
csid->fmt[MSM_CSID_PAD_SINK].code)->decode_format;
}
 
/* Config LUT */
 
dt_shift = (cid % 4) * 8;
-   df = csid_get_fmt_entry(csid->fmt[MSM_CSID_PAD_SINK].code)->
-   decode_format;
 
val = readl_relaxed(csid->base + CAMSS_CSID_CID_LUT_VC_n(vc));
val &= ~(0xff << dt_shift);
-- 
2.7.4



[PATCH v4 00/34] Qualcomm Camera Subsystem driver - 8x96 support

2018-07-25 Thread Todor Tomov
Changelog v4:
- patch 17: use unsigned int for line_num;
- patch 18: fix error handling on s_power;
- patch 19, 21, 24, 25: fix extern usage (extern moved to header files);
- patch 34: add acked tag;
- patch 35: merge into patch 01.



This patchset adds support for the Qualcomm Camera Subsystem found
on Qualcomm MSM8996 and APQ8096 SoC to the existing driver which
used to support MSM8916 and APQ8016.

The camera subsystem hardware on 8x96 is similar to 8x16 but
supports more cameras and features. More details are added in the
driver document by the last patch.

The first 3 patches are dependencies which have already been on
the mainling list but I'm adding them here for completeness.

The following 12 patches add general updates and fixes to the driver.
Then the rest add the support for the new hardware.

The driver is tested on Dragonboard 410c (APQ8016) and Dragonboard 820c
(APQ8096) with OV5645 camera sensors. media-ctl [1], yavta [2] and
GStreamer were used for testing.

[1] https://git.linuxtv.org//v4l-utils.git
[2] http://git.ideasonboard.org/yavta.git



DB410c: v4l2-compliance -M /dev/media0 -v
v4l2-compliance SHA: 47593771ad61f52d3670ef35373f24f85d5da267, 64 bits

Compliance test for device /dev/media0:

Media Driver Info:
Driver name  : qcom-camss
Model: Qualcomm Camera Subsystem
Serial   : 
Bus info : 
Media version: 4.17.0
Hardware revision: 0x (0)
Driver version   : 4.17.0

Required ioctls:
test MEDIA_IOC_DEVICE_INFO: OK

Allow for multiple opens:
test second /dev/media0 open: OK
test MEDIA_IOC_DEVICE_INFO: OK
test for unlimited opens: OK

Media Controller ioctls:
Entity: 0x0001 (Name: 'msm_csiphy0', Function: V4L2 I/O)
Entity: 0x0004 (Name: 'msm_csiphy1', Function: V4L2 I/O)
Entity: 0x0007 (Name: 'msm_csid0', Function: V4L2 I/O)
Entity: 0x000a (Name: 'msm_csid1', Function: V4L2 I/O)
Entity: 0x000d (Name: 'msm_ispif0', Function: V4L2 I/O)
Entity: 0x0010 (Name: 'msm_ispif1', Function: V4L2 I/O)
Entity: 0x0013 (Name: 'msm_vfe0_rdi0', Function: Video 
Pixel Formatter)
Entity: 0x0016 (Name: 'msm_vfe0_video0', Function: V4L2 I/O)
Entity: 0x001c (Name: 'msm_vfe0_rdi1', Function: Video 
Pixel Formatter)
Entity: 0x001f (Name: 'msm_vfe0_video1', Function: V4L2 I/O)
Entity: 0x0025 (Name: 'msm_vfe0_rdi2', Function: Video 
Pixel Formatter)
Entity: 0x0028 (Name: 'msm_vfe0_video2', Function: V4L2 I/O)
Entity: 0x002e (Name: 'msm_vfe0_pix', Function: Video Pixel 
Formatter)
Entity: 0x0031 (Name: 'msm_vfe0_video3', Function: V4L2 I/O)
Entity: 0x0057 (Name: 'ov5645 4-003b', Function: Camera 
Sensor)
Interface: 0x0318 (Type: V4L Video, DevPath: /dev/video0)
Interface: 0x0321 (Type: V4L Video, DevPath: /dev/video1)
Interface: 0x032a (Type: V4L Video, DevPath: /dev/video2)
Interface: 0x0333 (Type: V4L Video, DevPath: /dev/video3)
Interface: 0x035b (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev0)
Interface: 0x035d (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev1)
Interface: 0x035f (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev2)
Interface: 0x0361 (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev3)
Interface: 0x0363 (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev4)
Interface: 0x0365 (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev5)
Interface: 0x0367 (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev6)
Interface: 0x0369 (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev7)
Interface: 0x036b (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev8)
Interface: 0x036d (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev9)
Interface: 0x036f (Type: V4L Sub-Device, DevPath: 
/dev/v4l-subdev10)
Pad: 0x0102 (msm_csiphy0, Sink)
Pad: 0x0103 (msm_csiphy0, Source)
Pad: 0x0105 (msm_csiphy1, Sink)
Pad: 0x0106 (msm_csiphy1, Source)
Pad: 0x0108 (msm_csid0, Sink)
Pad: 0x0109 (msm_csid0, Source)
Pad: 0x010b (msm_csid1, Sink)
Pad: 0x010c (msm_csid1, Source)
Pad: 0x010e (msm_ispif0, Sink)
Pad: 0x010f (msm_ispif0, Source)
Pad: 0x0111 (msm_ispif1, Sink)
   

[PATCH v4 23/34] media: camss: ispif: Add support for 8x96

2018-07-25 Thread Todor Tomov
ISPIF hardware modules on 8x16 and 8x96 are similar. However on
8x96 the ISPIF routes data to two VFE hardware modules. Add
separate interrupt handler for 8x96 to handle the additional
interrupts.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-ispif.c | 76 -
 1 file changed, 73 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c 
b/drivers/media/platform/qcom/camss/camss-ispif.c
index 2c6c0d2..ae80732 100644
--- a/drivers/media/platform/qcom/camss/camss-ispif.c
+++ b/drivers/media/platform/qcom/camss/camss-ispif.c
@@ -116,13 +116,77 @@ static const u32 ispif_formats[] = {
 };
 
 /*
- * ispif_isr - ISPIF module interrupt handler
+ * ispif_isr_8x96 - ISPIF module interrupt handler for 8x96
  * @irq: Interrupt line
  * @dev: ISPIF device
  *
  * Return IRQ_HANDLED on success
  */
-static irqreturn_t ispif_isr(int irq, void *dev)
+static irqreturn_t ispif_isr_8x96(int irq, void *dev)
+{
+   struct ispif_device *ispif = dev;
+   u32 value0, value1, value2, value3, value4, value5;
+
+   value0 = readl_relaxed(ispif->base + ISPIF_VFE_m_IRQ_STATUS_0(0));
+   value1 = readl_relaxed(ispif->base + ISPIF_VFE_m_IRQ_STATUS_1(0));
+   value2 = readl_relaxed(ispif->base + ISPIF_VFE_m_IRQ_STATUS_2(0));
+   value3 = readl_relaxed(ispif->base + ISPIF_VFE_m_IRQ_STATUS_0(1));
+   value4 = readl_relaxed(ispif->base + ISPIF_VFE_m_IRQ_STATUS_1(1));
+   value5 = readl_relaxed(ispif->base + ISPIF_VFE_m_IRQ_STATUS_2(1));
+
+   writel_relaxed(value0, ispif->base + ISPIF_VFE_m_IRQ_CLEAR_0(0));
+   writel_relaxed(value1, ispif->base + ISPIF_VFE_m_IRQ_CLEAR_1(0));
+   writel_relaxed(value2, ispif->base + ISPIF_VFE_m_IRQ_CLEAR_2(0));
+   writel_relaxed(value3, ispif->base + ISPIF_VFE_m_IRQ_CLEAR_0(1));
+   writel_relaxed(value4, ispif->base + ISPIF_VFE_m_IRQ_CLEAR_1(1));
+   writel_relaxed(value5, ispif->base + ISPIF_VFE_m_IRQ_CLEAR_2(1));
+
+   writel(0x1, ispif->base + ISPIF_IRQ_GLOBAL_CLEAR_CMD);
+
+   if ((value0 >> 27) & 0x1)
+   complete(>reset_complete);
+
+   if (unlikely(value0 & ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE0 pix0 overflow\n");
+
+   if (unlikely(value0 & ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE0 rdi0 overflow\n");
+
+   if (unlikely(value1 & ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE0 pix1 overflow\n");
+
+   if (unlikely(value1 & ISPIF_VFE_m_IRQ_STATUS_1_RDI1_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE0 rdi1 overflow\n");
+
+   if (unlikely(value2 & ISPIF_VFE_m_IRQ_STATUS_2_RDI2_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE0 rdi2 overflow\n");
+
+   if (unlikely(value3 & ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE1 pix0 overflow\n");
+
+   if (unlikely(value3 & ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE1 rdi0 overflow\n");
+
+   if (unlikely(value4 & ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE1 pix1 overflow\n");
+
+   if (unlikely(value4 & ISPIF_VFE_m_IRQ_STATUS_1_RDI1_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE1 rdi1 overflow\n");
+
+   if (unlikely(value5 & ISPIF_VFE_m_IRQ_STATUS_2_RDI2_OVERFLOW))
+   dev_err_ratelimited(to_device(ispif), "VFE1 rdi2 overflow\n");
+
+   return IRQ_HANDLED;
+}
+
+/*
+ * ispif_isr_8x16 - ISPIF module interrupt handler for 8x16
+ * @irq: Interrupt line
+ * @dev: ISPIF device
+ *
+ * Return IRQ_HANDLED on success
+ */
+static irqreturn_t ispif_isr_8x16(int irq, void *dev)
 {
struct ispif_device *ispif = dev;
u32 value0, value1, value2;
@@ -959,8 +1023,14 @@ int msm_ispif_subdev_init(struct ispif_device *ispif,
ispif->irq = r->start;
snprintf(ispif->irq_name, sizeof(ispif->irq_name), "%s_%s",
 dev_name(dev), MSM_ISPIF_NAME);
-   ret = devm_request_irq(dev, ispif->irq, ispif_isr,
+   if (to_camss(ispif)->version == CAMSS_8x16)
+   ret = devm_request_irq(dev, ispif->irq, ispif_isr_8x16,
   IRQF_TRIGGER_RISING, ispif->irq_name, ispif);
+   else if (to_camss(ispif)->version == CAMSS_8x96)
+   ret = devm_request_irq(dev, ispif->irq, ispif_isr_8x96,
+  IRQF_TRIGGER_RISING, ispif->irq_name, ispif);
+   else
+   ret = -EINVAL;
if (ret < 0) {
dev_err(dev, "request_irq failed: %d\n", ret);
return ret;
-- 
2.7.4



[PATCH v4 30/34] media: camss: csid: MIPI10 to Plain16 format conversion

2018-07-25 Thread Todor Tomov
Use the PRDI mode on 8x96 to allow to configure RAW MIPI10
to Plain16 format conversion.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c  | 33 -
 drivers/media/platform/qcom/camss/camss-ispif.c | 64 +
 drivers/media/platform/qcom/camss/camss-vfe.c   |  1 +
 drivers/media/platform/qcom/camss/camss-video.c |  2 +
 4 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index cf543fa..0715a8e 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -32,6 +32,15 @@
(((v) == CAMSS_8x16 ? 0x010 : 0x014) + 0x4 * (n))
 #define CAMSS_CSID_CID_n_CFG(v, n) \
(((v) == CAMSS_8x16 ? 0x020 : 0x024) + 0x4 * (n))
+#define CAMSS_CSID_CID_n_CFG_ISPIF_EN  BIT(0)
+#define CAMSS_CSID_CID_n_CFG_RDI_ENBIT(1)
+#define CAMSS_CSID_CID_n_CFG_DECODE_FORMAT_SHIFT   4
+#define CAMSS_CSID_CID_n_CFG_PLAIN_FORMAT_8(0 << 8)
+#define CAMSS_CSID_CID_n_CFG_PLAIN_FORMAT_16   (1 << 8)
+#define CAMSS_CSID_CID_n_CFG_PLAIN_ALIGNMENT_LSB   (0 << 9)
+#define CAMSS_CSID_CID_n_CFG_PLAIN_ALIGNMENT_MSB   (1 << 9)
+#define CAMSS_CSID_CID_n_CFG_RDI_MODE_RAW_DUMP (0 << 10)
+#define CAMSS_CSID_CID_n_CFG_RDI_MODE_PLAIN_PACKING(1 << 10)
 #define CAMSS_CSID_IRQ_CLEAR_CMD(v)((v) == CAMSS_8x16 ? 0x060 : 0x064)
 #define CAMSS_CSID_IRQ_MASK(v) ((v) == CAMSS_8x16 ? 0x064 : 0x068)
 #define CAMSS_CSID_IRQ_STATUS(v)   ((v) == CAMSS_8x16 ? 0x068 : 0x06c)
@@ -330,6 +339,16 @@ static u32 csid_src_pad_code(struct csid_device *csid, u32 
sink_code,
return sink_code;
} else if (csid->camss->version == CAMSS_8x96) {
switch (sink_code) {
+   case MEDIA_BUS_FMT_SBGGR10_1X10:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE,
+   };
+
+   return csid_find_code(src_code, ARRAY_SIZE(src_code),
+ index, src_req_code);
+   }
default:
if (index > 0)
return 0;
@@ -636,7 +655,19 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
writel_relaxed(val, csid->base +
   CAMSS_CSID_CID_LUT_VC_n(ver, vc));
 
-   val = (df << 4) | 0x3;
+   val = CAMSS_CSID_CID_n_CFG_ISPIF_EN;
+   val |= CAMSS_CSID_CID_n_CFG_RDI_EN;
+   val |= df << CAMSS_CSID_CID_n_CFG_DECODE_FORMAT_SHIFT;
+   val |= CAMSS_CSID_CID_n_CFG_RDI_MODE_RAW_DUMP;
+   if (csid->camss->version == CAMSS_8x96 &&
+   csid->fmt[MSM_CSID_PAD_SINK].code ==
+   MEDIA_BUS_FMT_SBGGR10_1X10 &&
+   csid->fmt[MSM_CSID_PAD_SRC].code ==
+   MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE) {
+   val |= CAMSS_CSID_CID_n_CFG_RDI_MODE_PLAIN_PACKING;
+   val |= CAMSS_CSID_CID_n_CFG_PLAIN_FORMAT_16;
+   val |= CAMSS_CSID_CID_n_CFG_PLAIN_ALIGNMENT_LSB;
+   }
writel_relaxed(val, csid->base +
   CAMSS_CSID_CID_n_CFG(ver, cid));
 
diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c 
b/drivers/media/platform/qcom/camss/camss-ispif.c
index 146d5d2..81d6351 100644
--- a/drivers/media/platform/qcom/camss/camss-ispif.c
+++ b/drivers/media/platform/qcom/camss/camss-ispif.c
@@ -76,6 +76,13 @@
(0x254 + 0x200 * (m) + 0x4 * (n))
 #define ISPIF_VFE_m_RDI_INTF_n_CID_MASK(m, n)  \
(0x264 + 0x200 * (m) + 0x4 * (n))
+/* PACK_CFG registers are 8x96 only */
+#define ISPIF_VFE_m_RDI_INTF_n_PACK_CFG_0(m, n)\
+   (0x270 + 0x200 * (m) + 0x4 * (n))
+#define ISPIF_VFE_m_RDI_INTF_n_PACK_CFG_1(m, n)\
+   (0x27c + 0x200 * (m) + 0x4 * (n))
+#define ISPIF_VFE_m_RDI_INTF_n_PACK_CFG_0_CID_c_PLAIN(c)   \
+   (1 << ((cid % 8) * 4))
 #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)\
@@ -128,6 +135,7 @@ static const u32 ispif_formats_8x96[] = {
MEDIA_BUS_FMT_SGBRG10_1X10,
MEDIA_BUS_FMT_SGRBG10_1X10,
MEDIA_BUS_FMT_SRGGB10_1X10,
+   MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE,
MEDIA_BUS_FMT_SBGGR12_1X12,
MEDIA_BUS_FMT_SGBRG12_1X12,
MEDIA_BUS_FMT_SGRBG12_1X12,
@@ -667,6 +675,54 @@ static 

[PATCH v4 20/34] media: camss: csiphy: Unify lane handling

2018-07-25 Thread Todor Tomov
Restructure lane configuration so it is simpler and will allow
similar (although not the same) handling for different hardware
versions.

Signed-off-by: Todor Tomov 
---
 .../platform/qcom/camss/camss-csiphy-2ph-1-0.c | 48 --
 drivers/media/platform/qcom/camss/camss-csiphy.c   |  4 +-
 drivers/media/platform/qcom/camss/camss-csiphy.h   |  3 +-
 3 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c 
b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
index 7325906..5f499be 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
@@ -86,7 +86,7 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
 {
struct csiphy_lanes_cfg *c = >csi2->lane_cfg;
u8 settle_cnt;
-   u8 val;
+   u8 val, l = 0;
int i = 0;
 
settle_cnt = csiphy_settle_cnt_calc(pixel_clock, bpp, c->num_data,
@@ -104,34 +104,38 @@ static void csiphy_lanes_enable(struct csiphy_device 
*csiphy,
val = cfg->combo_mode << 4;
writel_relaxed(val, csiphy->base + CAMSS_CSI_PHY_GLBL_RESET);
 
-   while (lane_mask) {
-   if (lane_mask & 0x1) {
-   writel_relaxed(0x10, csiphy->base +
-  CAMSS_CSI_PHY_LNn_CFG2(i));
-   writel_relaxed(settle_cnt, csiphy->base +
-  CAMSS_CSI_PHY_LNn_CFG3(i));
-   writel_relaxed(0x3f, csiphy->base +
-  CAMSS_CSI_PHY_INTERRUPT_MASKn(i));
-   writel_relaxed(0x3f, csiphy->base +
-  CAMSS_CSI_PHY_INTERRUPT_CLEARn(i));
-   }
-
-   lane_mask >>= 1;
-   i++;
+   for (i = 0; i <= c->num_data; i++) {
+   if (i == c->num_data)
+   l = c->clk.pos;
+   else
+   l = c->data[i].pos;
+
+   writel_relaxed(0x10, csiphy->base +
+  CAMSS_CSI_PHY_LNn_CFG2(l));
+   writel_relaxed(settle_cnt, csiphy->base +
+  CAMSS_CSI_PHY_LNn_CFG3(l));
+   writel_relaxed(0x3f, csiphy->base +
+  CAMSS_CSI_PHY_INTERRUPT_MASKn(l));
+   writel_relaxed(0x3f, csiphy->base +
+  CAMSS_CSI_PHY_INTERRUPT_CLEARn(l));
}
 }
 
-static void csiphy_lanes_disable(struct csiphy_device *csiphy, u8 lane_mask)
+static void csiphy_lanes_disable(struct csiphy_device *csiphy,
+struct csiphy_config *cfg)
 {
+   struct csiphy_lanes_cfg *c = >csi2->lane_cfg;
+   u8 l = 0;
int i = 0;
 
-   while (lane_mask) {
-   if (lane_mask & 0x1)
-   writel_relaxed(0x0, csiphy->base +
-  CAMSS_CSI_PHY_LNn_CFG2(i));
+   for (i = 0; i <= c->num_data; i++) {
+   if (i == c->num_data)
+   l = c->clk.pos;
+   else
+   l = c->data[i].pos;
 
-   lane_mask >>= 1;
-   i++;
+   writel_relaxed(0x0, csiphy->base +
+  CAMSS_CSI_PHY_LNn_CFG2(l));
}
 
writel_relaxed(0x0, csiphy->base + CAMSS_CSI_PHY_GLBL_PWR_CFG);
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 8d10e85..d35eea0 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -296,9 +296,7 @@ static int csiphy_stream_on(struct csiphy_device *csiphy)
  */
 static void csiphy_stream_off(struct csiphy_device *csiphy)
 {
-   u8 lane_mask = csiphy_get_lane_mask(>cfg.csi2->lane_cfg);
-
-   csiphy->ops->lanes_disable(csiphy, lane_mask);
+   csiphy->ops->lanes_disable(csiphy, >cfg);
 }
 
 
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h 
b/drivers/media/platform/qcom/camss/camss-csiphy.h
index edad941..e3dd257 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.h
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
@@ -51,7 +51,8 @@ struct csiphy_hw_ops {
void (*lanes_enable)(struct csiphy_device *csiphy,
 struct csiphy_config *cfg,
 u32 pixel_clock, u8 bpp, u8 lane_mask);
-   void (*lanes_disable)(struct csiphy_device *csiphy, u8 lane_mask);
+   void (*lanes_disable)(struct csiphy_device *csiphy,
+ struct csiphy_config *cfg);
irqreturn_t (*isr)(int irq, void *dev);
 };
 
-- 
2.7.4



[PATCH v4 29/34] media: camss: csid: Different format support on source pad

2018-07-25 Thread Todor Tomov
Usually the format on the source pad is the same as on the sink pad.
However the CSID is able to do some format conversions. To support
this make the format on the source pad selectable amongst a list
of formats. This list can be different for each sink pad format.
This is still not used but will be when the format conversions
are implemented.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c | 69 +-
 1 file changed, 56 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index db960da..cf543fa 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -300,6 +300,47 @@ static const struct csid_format csid_formats_8x96[] = {
}
 };
 
+static u32 csid_find_code(u32 *code, unsigned int n_code,
+ unsigned int index, u32 req_code)
+{
+   int i;
+
+   if (!req_code && (index >= n_code))
+   return 0;
+
+   for (i = 0; i < n_code; i++)
+   if (req_code) {
+   if (req_code == code[i])
+   return req_code;
+   } else {
+   if (i == index)
+   return code[i];
+   }
+
+   return code[0];
+}
+
+static u32 csid_src_pad_code(struct csid_device *csid, u32 sink_code,
+unsigned int index, u32 src_req_code)
+{
+   if (csid->camss->version == CAMSS_8x16) {
+   if (index > 0)
+   return 0;
+
+   return sink_code;
+   } else if (csid->camss->version == CAMSS_8x96) {
+   switch (sink_code) {
+   default:
+   if (index > 0)
+   return 0;
+
+   return sink_code;
+   }
+   } else {
+   return 0;
+   }
+}
+
 static const struct csid_format *csid_get_fmt_entry(
const struct csid_format *formats,
unsigned int nformat,
@@ -674,15 +715,15 @@ static void csid_try_format(struct csid_device *csid,
 
case MSM_CSID_PAD_SRC:
if (csid->testgen_mode->cur.val == 0) {
-   /* Test generator is disabled, keep pad formats */
-   /* in sync - set and return a format same as sink pad */
-   struct v4l2_mbus_framefmt format;
+   /* Test generator is disabled, */
+   /* keep pad formats in sync */
+   u32 code = fmt->code;
 
-   format = *__csid_get_format(csid, cfg,
-   MSM_CSID_PAD_SINK, which);
-   *fmt = format;
+   *fmt = *__csid_get_format(csid, cfg,
+ MSM_CSID_PAD_SINK, which);
+   fmt->code = csid_src_pad_code(csid, fmt->code, 0, code);
} else {
-   /* Test generator is enabled, set format on source*/
+   /* Test generator is enabled, set format on source */
/* pad to allow test generator usage */
 
for (i = 0; i < csid->nformats; i++)
@@ -716,7 +757,6 @@ static int csid_enum_mbus_code(struct v4l2_subdev *sd,
   struct v4l2_subdev_mbus_code_enum *code)
 {
struct csid_device *csid = v4l2_get_subdevdata(sd);
-   struct v4l2_mbus_framefmt *format;
 
if (code->pad == MSM_CSID_PAD_SINK) {
if (code->index >= csid->nformats)
@@ -725,13 +765,16 @@ static int csid_enum_mbus_code(struct v4l2_subdev *sd,
code->code = csid->formats[code->index].code;
} else {
if (csid->testgen_mode->cur.val == 0) {
-   if (code->index > 0)
-   return -EINVAL;
+   struct v4l2_mbus_framefmt *sink_fmt;
 
-   format = __csid_get_format(csid, cfg, MSM_CSID_PAD_SINK,
-  code->which);
+   sink_fmt = __csid_get_format(csid, cfg,
+MSM_CSID_PAD_SINK,
+code->which);
 
-   code->code = format->code;
+   code->code = csid_src_pad_code(csid, sink_fmt->code,
+  code->index, 0);
+   if (!code->code)
+   return -EINVAL;
} else {
if (code->index >= csid->nformats)
return -EINVAL;
-- 
2.7.4



[PATCH v4 15/34] media: dt-bindings: media: qcom,camss: Fix whitespaces

2018-07-25 Thread Todor Tomov
Use tabs.

CC: Rob Herring 
CC: Mark Rutland 
CC: devicet...@vger.kernel.org
Signed-off-by: Todor Tomov 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/media/qcom,camss.txt   | 92 +++---
 1 file changed, 46 insertions(+), 46 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt 
b/Documentation/devicetree/bindings/media/qcom,camss.txt
index 032e8ed..e938eb0 100644
--- a/Documentation/devicetree/bindings/media/qcom,camss.txt
+++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
@@ -53,25 +53,25 @@ Qualcomm Camera Subsystem
Usage: required
Value type: 
Definition: Should contain the following entries:
-- "top_ahb"
-- "ispif_ahb"
-- "csiphy0_timer"
-- "csiphy1_timer"
-- "csi0_ahb"
-- "csi0"
-- "csi0_phy"
-- "csi0_pix"
-- "csi0_rdi"
-- "csi1_ahb"
-- "csi1"
-- "csi1_phy"
-- "csi1_pix"
-- "csi1_rdi"
-- "ahb"
-- "vfe0"
-- "csi_vfe0"
-- "vfe_ahb"
-- "vfe_axi"
+   - "top_ahb"
+   - "ispif_ahb"
+   - "csiphy0_timer"
+   - "csiphy1_timer"
+   - "csi0_ahb"
+   - "csi0"
+   - "csi0_phy"
+   - "csi0_pix"
+   - "csi0_rdi"
+   - "csi1_ahb"
+   - "csi1"
+   - "csi1_phy"
+   - "csi1_pix"
+   - "csi1_rdi"
+   - "ahb"
+   - "vfe0"
+   - "csi_vfe0"
+   - "vfe_ahb"
+   - "vfe_axi"
 - vdda-supply:
Usage: required
Value type: 
@@ -95,17 +95,17 @@ Qualcomm Camera Subsystem
- clock-lanes:
Usage: required
Value type: 
-Definition: The physical clock lane index. The value
-must always be <1> as the physical clock
-lane is lane 1.
+   Definition: The physical clock lane index. The value
+   must always be <1> as the physical clock
+   lane is lane 1.
- data-lanes:
Usage: required
Value type: 
-Definition: An array of physical data lanes indexes.
-Position of an entry determines the logical
-lane number, while the value of an entry
-indicates physical lane index. Lane 
swapping
-is supported.
+   Definition: An array of physical data lanes indexes.
+   Position of an entry determines the logical
+   lane number, while the value of an entry
+   indicates physical lane index. Lane swapping
+   is supported.
 
 * An Example
 
@@ -161,25 +161,25 @@ Qualcomm Camera Subsystem
< GCC_CAMSS_CSI_VFE0_CLK>,
< GCC_CAMSS_VFE_AHB_CLK>,
< GCC_CAMSS_VFE_AXI_CLK>;
-clock-names = "top_ahb",
-"ispif_ahb",
-"csiphy0_timer",
-"csiphy1_timer",
-"csi0_ahb",
-"csi0",
-"csi0_phy",
-"csi0_pix",
-"csi0_rdi",
-"csi1_ahb",
-"csi1",
-"csi1_phy",
-"csi1_pix",
-"csi1_rdi",
-"ahb",
-"vfe0",
-"csi_vfe0",
-"vfe_ahb",
-"vfe_axi";
+   clock-names = "top_ahb",
+   "ispif_ahb",
+   "csiphy0_timer",
+   "csiphy1_timer",
+   "csi0_ahb",
+   "csi0",
+   "csi0_phy",
+   "csi0_pix",
+   "csi0_rdi",
+   "csi1_ahb",
+   "csi1",
+   "csi1_phy",
+   "csi1_pix",
+   "csi1_rdi",
+   "ahb",
+   "vfe0",
+   "csi_vfe0",
+   "vfe_ahb",
+   "vfe_axi";
vdda-supply = <_l2>;
iommus = <_iommu 3>;
ports {
-- 
2.7.4



[PATCH v4 32/34] media: camss: Add support for 10-bit grayscale formats

2018-07-25 Thread Todor Tomov
Add support for 10-bit packed V4L2_PIX_FMT_Y10P (on 8x16 and 8x96)
and unpacked V4L2_PIX_FMT_Y10 (on 8x96 only) pixel formats.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c   | 50 +++-
 drivers/media/platform/qcom/camss/camss-csiphy.c |  2 +
 drivers/media/platform/qcom/camss/camss-ispif.c  |  6 ++-
 drivers/media/platform/qcom/camss/camss-vfe.c|  3 ++
 drivers/media/platform/qcom/camss/camss-video.c  |  6 +++
 5 files changed, 56 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index 472884d..6e141af 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -193,7 +193,14 @@ static const struct csid_format csid_formats_8x16[] = {
DECODE_FORMAT_UNCOMPRESSED_12_BIT,
12,
1,
-   }
+   },
+   {
+   MEDIA_BUS_FMT_Y10_1X10,
+   DATA_TYPE_RAW_10BIT,
+   DECODE_FORMAT_UNCOMPRESSED_10_BIT,
+   10,
+   1,
+   },
 };
 
 static const struct csid_format csid_formats_8x96[] = {
@@ -336,7 +343,14 @@ static const struct csid_format csid_formats_8x96[] = {
DECODE_FORMAT_UNCOMPRESSED_14_BIT,
14,
1,
-   }
+   },
+   {
+   MEDIA_BUS_FMT_Y10_1X10,
+   DATA_TYPE_RAW_10BIT,
+   DECODE_FORMAT_UNCOMPRESSED_10_BIT,
+   10,
+   1,
+   },
 };
 
 static u32 csid_find_code(u32 *code, unsigned int n_code,
@@ -379,6 +393,16 @@ static u32 csid_src_pad_code(struct csid_device *csid, u32 
sink_code,
return csid_find_code(src_code, ARRAY_SIZE(src_code),
  index, src_req_code);
}
+   case MEDIA_BUS_FMT_Y10_1X10:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_Y10_1X10,
+   MEDIA_BUS_FMT_Y10_2X8_PADHI_LE,
+   };
+
+   return csid_find_code(src_code, ARRAY_SIZE(src_code),
+ index, src_req_code);
+   }
default:
if (index > 0)
return 0;
@@ -689,15 +713,21 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
val |= CAMSS_CSID_CID_n_CFG_RDI_EN;
val |= df << CAMSS_CSID_CID_n_CFG_DECODE_FORMAT_SHIFT;
val |= CAMSS_CSID_CID_n_CFG_RDI_MODE_RAW_DUMP;
-   if (csid->camss->version == CAMSS_8x96 &&
-   csid->fmt[MSM_CSID_PAD_SINK].code ==
-   MEDIA_BUS_FMT_SBGGR10_1X10 &&
-   csid->fmt[MSM_CSID_PAD_SRC].code ==
-   MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE) {
-   val |= CAMSS_CSID_CID_n_CFG_RDI_MODE_PLAIN_PACKING;
-   val |= CAMSS_CSID_CID_n_CFG_PLAIN_FORMAT_16;
-   val |= CAMSS_CSID_CID_n_CFG_PLAIN_ALIGNMENT_LSB;
+
+   if (csid->camss->version == CAMSS_8x96) {
+   u32 sink_code = csid->fmt[MSM_CSID_PAD_SINK].code;
+   u32 src_code = csid->fmt[MSM_CSID_PAD_SRC].code;
+
+   if ((sink_code == MEDIA_BUS_FMT_SBGGR10_1X10 &&
+src_code == MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE) ||
+   (sink_code == MEDIA_BUS_FMT_Y10_1X10 &&
+src_code == MEDIA_BUS_FMT_Y10_2X8_PADHI_LE)) {
+   val |= 
CAMSS_CSID_CID_n_CFG_RDI_MODE_PLAIN_PACKING;
+   val |= CAMSS_CSID_CID_n_CFG_PLAIN_FORMAT_16;
+   val |= CAMSS_CSID_CID_n_CFG_PLAIN_ALIGNMENT_LSB;
+   }
}
+
writel_relaxed(val, csid->base +
   CAMSS_CSID_CID_n_CFG(ver, cid));
 
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
b/drivers/media/platform/qcom/camss/camss-csiphy.c
index cae3e8b..4559f3b 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -45,6 +45,7 @@ static const struct csiphy_format csiphy_formats_8x16[] = {
{ MEDIA_BUS_FMT_SGBRG12_1X12, 12 },
{ MEDIA_BUS_FMT_SGRBG12_1X12, 12 },
{ MEDIA_BUS_FMT_SRGGB12_1X12, 12 },
+   { MEDIA_BUS_FMT_Y10_1X10, 10 },
 };
 
 static const struct csiphy_format csiphy_formats_8x96[] = {
@@ -68,6 +69,7 @@ static const struct csiphy_format csiphy_formats_8x96[] = {
{ MEDIA_BUS_FMT_SGBRG14_1X14, 14 },
{ MEDIA_BUS_FMT_SGRBG14_1X14, 14 },
{ MEDIA_BUS_FMT_SRGGB14_1X14, 14 },
+   { MEDIA_BUS_FMT_Y10_1X10, 10 },
 };
 
 /*
diff 

[PATCH v4 22/34] media: camss: csid: Add support for 8x96

2018-07-25 Thread Todor Tomov
CSID hardware modules on 8x16 and 8x96 are similar. There is no
need to duplicate the code by adding separate versions. Just
update the register macros to return the correct register
addresses.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c | 60 --
 1 file changed, 37 insertions(+), 23 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index 3ba087f..915835e 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -27,21 +27,26 @@
 #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_RST_CMD(v)  ((v) == CAMSS_8x16 ? 0x00c : 0x010)
+#define CAMSS_CSID_CID_LUT_VC_n(v, n)  \
+   (((v) == CAMSS_8x16 ? 0x010 : 0x014) + 0x4 * (n))
+#define CAMSS_CSID_CID_n_CFG(v, n) \
+   (((v) == CAMSS_8x16 ? 0x020 : 0x024) + 0x4 * (n))
+#define CAMSS_CSID_IRQ_CLEAR_CMD(v)((v) == CAMSS_8x16 ? 0x060 : 0x064)
+#define CAMSS_CSID_IRQ_MASK(v) ((v) == CAMSS_8x16 ? 0x064 : 0x068)
+#define CAMSS_CSID_IRQ_STATUS(v)   ((v) == CAMSS_8x16 ? 0x068 : 0x06c)
+#define CAMSS_CSID_TG_CTRL(v)  ((v) == CAMSS_8x16 ? 0x0a0 : 0x0a8)
 #define CAMSS_CSID_TG_CTRL_DISABLE 0xa06436
 #define CAMSS_CSID_TG_CTRL_ENABLE  0xa06437
-#define CAMSS_CSID_TG_VC_CFG   0x0a4
+#define CAMSS_CSID_TG_VC_CFG(v)((v) == CAMSS_8x16 ? 0x0a4 : 
0x0ac)
 #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 CAMSS_CSID_TG_DT_n_CGG_0(v, n) \
+   (((v) == CAMSS_8x16 ? 0x0ac : 0x0b4) + 0xc * (n))
+#define CAMSS_CSID_TG_DT_n_CGG_1(v, n) \
+   (((v) == CAMSS_8x16 ? 0x0b0 : 0x0b8) + 0xc * (n))
+#define CAMSS_CSID_TG_DT_n_CGG_2(v, n) \
+   (((v) == CAMSS_8x16 ? 0x0b4 : 0x0bc) + 0xc * (n))
 
 #define DATA_TYPE_EMBEDDED_DATA_8BIT   0x12
 #define DATA_TYPE_YUV422_8BIT  0x1e
@@ -203,10 +208,11 @@ static const struct csid_fmts *csid_get_fmt_entry(u32 
code)
 static irqreturn_t csid_isr(int irq, void *dev)
 {
struct csid_device *csid = dev;
+   enum camss_version ver = csid->camss->version;
u32 value;
 
-   value = readl_relaxed(csid->base + CAMSS_CSID_IRQ_STATUS);
-   writel_relaxed(value, csid->base + CAMSS_CSID_IRQ_CLEAR_CMD);
+   value = readl_relaxed(csid->base + CAMSS_CSID_IRQ_STATUS(ver));
+   writel_relaxed(value, csid->base + CAMSS_CSID_IRQ_CLEAR_CMD(ver));
 
if ((value >> 11) & 0x1)
complete(>reset_complete);
@@ -289,7 +295,8 @@ static int csid_reset(struct csid_device *csid)
 
reinit_completion(>reset_complete);
 
-   writel_relaxed(0x7fff, csid->base + CAMSS_CSID_RST_CMD);
+   writel_relaxed(0x7fff, csid->base +
+  CAMSS_CSID_RST_CMD(csid->camss->version));
 
time = wait_for_completion_timeout(>reset_complete,
msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
@@ -377,6 +384,7 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
 {
struct csid_device *csid = v4l2_get_subdevdata(sd);
struct csid_testgen_config *tg = >testgen;
+   enum camss_version ver = csid->camss->version;
u32 val;
 
if (enable) {
@@ -409,13 +417,14 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
/* 1:0 VC */
val = ((CAMSS_CSID_TG_VC_CFG_V_BLANKING & 0xff) << 24) |
  ((CAMSS_CSID_TG_VC_CFG_H_BLANKING & 0x7ff) << 13);
-   writel_relaxed(val, csid->base + CAMSS_CSID_TG_VC_CFG);
+   writel_relaxed(val, csid->base +
+  CAMSS_CSID_TG_VC_CFG(ver));
 
/* 28:16 bytes per lines, 12:0 num of lines */
val = ((num_bytes_per_line & 0x1fff) << 16) |
  (num_lines & 0x1fff);
writel_relaxed(val, csid->base +
-  CAMSS_CSID_TG_DT_n_CGG_0(0));
+  CAMSS_CSID_TG_DT_n_CGG_0(ver, 0));
 
dt = csid_get_fmt_entry(

[PATCH v4 27/34] media: camss: vfe: Different format support on source pad

2018-07-25 Thread Todor Tomov
Rework the format selection on the source pad. Make the format
on the source pad selectable amongst a list of formats. This
list can be different for each sink pad format.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-vfe.c | 172 --
 1 file changed, 135 insertions(+), 37 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c 
b/drivers/media/platform/qcom/camss/camss-vfe.c
index c27097c..dc353d6 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -124,6 +124,131 @@ static u8 vfe_get_bpp(const struct vfe_format *formats,
return formats[0].bpp;
 }
 
+static u32 vfe_find_code(u32 *code, unsigned int n_code,
+unsigned int index, u32 req_code)
+{
+   int i;
+
+   if (!req_code && (index >= n_code))
+   return 0;
+
+   for (i = 0; i < n_code; i++)
+   if (req_code) {
+   if (req_code == code[i])
+   return req_code;
+   } else {
+   if (i == index)
+   return code[i];
+   }
+
+   return code[0];
+}
+
+static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
+   unsigned int index, u32 src_req_code)
+{
+   struct vfe_device *vfe = to_vfe(line);
+
+   if (vfe->camss->version == CAMSS_8x16)
+   switch (sink_code) {
+   case MEDIA_BUS_FMT_YUYV8_2X8:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   MEDIA_BUS_FMT_YUYV8_1_5X8,
+   };
+
+   return vfe_find_code(src_code, ARRAY_SIZE(src_code),
+index, src_req_code);
+   }
+   case MEDIA_BUS_FMT_YVYU8_2X8:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   MEDIA_BUS_FMT_YVYU8_1_5X8,
+   };
+
+   return vfe_find_code(src_code, ARRAY_SIZE(src_code),
+index, src_req_code);
+   }
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_1_5X8,
+   };
+
+   return vfe_find_code(src_code, ARRAY_SIZE(src_code),
+index, src_req_code);
+   }
+   case MEDIA_BUS_FMT_VYUY8_2X8:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   MEDIA_BUS_FMT_VYUY8_1_5X8,
+   };
+
+   return vfe_find_code(src_code, ARRAY_SIZE(src_code),
+index, src_req_code);
+   }
+   default:
+   if (index > 0)
+   return 0;
+
+   return sink_code;
+   }
+   else if (vfe->camss->version == CAMSS_8x96)
+   switch (sink_code) {
+   case MEDIA_BUS_FMT_YUYV8_2X8:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   MEDIA_BUS_FMT_YUYV8_1_5X8,
+   };
+
+   return vfe_find_code(src_code, ARRAY_SIZE(src_code),
+index, src_req_code);
+   }
+   case MEDIA_BUS_FMT_YVYU8_2X8:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   MEDIA_BUS_FMT_YVYU8_1_5X8,
+   };
+
+   return vfe_find_code(src_code, ARRAY_SIZE(src_code),
+index, src_req_code);
+   }
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   MEDIA_BUS_FMT_UYVY8_1_5X8,
+   };
+
+   return vfe_find_code(src_code, ARRAY_SIZE(src_code),
+index, src_req_code);
+   }
+   case MEDIA_BUS_FMT_VYUY8_2X8:
+   {
+   u32 src_code[] = {
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   MEDIA_BUS_FMT_VYUY8_1_5X8,
+   };
+
+   return vfe_find_code(src_code, ARRAY_SIZE(src_code),
+ 

[PATCH v4 28/34] media: camss: vfe: Add support for UYVY output from VFE on 8x96

2018-07-25 Thread Todor Tomov
Add support to output UYVY formats from the VFE (via the PIX interface).
A configuration for the realign module in the VFE is added. As the
realign module is present on 8x96 but not on 8x16, this is supported
on 8x96 only.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-vfe-4-1.c |   6 +
 drivers/media/platform/qcom/camss/camss-vfe-4-7.c | 129 ++
 drivers/media/platform/qcom/camss/camss-vfe.c |  31 +-
 drivers/media/platform/qcom/camss/camss-vfe.h |   2 +
 drivers/media/platform/qcom/camss/camss-video.c   |   8 ++
 5 files changed, 152 insertions(+), 24 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c 
b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
index 41184dc..da3a9fe 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
@@ -542,6 +542,11 @@ static void vfe_set_xbar_cfg(struct vfe_device *vfe, 
struct vfe_output *output,
}
 }
 
+static void vfe_set_realign_cfg(struct vfe_device *vfe, struct vfe_line *line,
+   u8 enable)
+{
+   /* empty */
+}
 static void vfe_set_rdi_cid(struct vfe_device *vfe, enum vfe_line_id id, u8 
cid)
 {
vfe_reg_clr(vfe, VFE_0_RDI_CFG_x(id),
@@ -989,6 +994,7 @@ const struct vfe_hw_ops vfe_ops_4_1 = {
.wm_set_subsample = vfe_wm_set_subsample,
.bus_disconnect_wm_from_rdi = vfe_bus_disconnect_wm_from_rdi,
.set_xbar_cfg = vfe_set_xbar_cfg,
+   .set_realign_cfg = vfe_set_realign_cfg,
.set_rdi_cid = vfe_set_rdi_cid,
.reg_update = vfe_reg_update,
.reg_update_clear = vfe_reg_update_clear,
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c 
b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
index 45e6711..4c584bf 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
@@ -34,6 +34,7 @@
 #define VFE_0_MODULE_ZOOM_EN   0x04c
 #define VFE_0_MODULE_ZOOM_EN_SCALE_ENC BIT(1)
 #define VFE_0_MODULE_ZOOM_EN_CROP_ENC  BIT(2)
+#define VFE_0_MODULE_ZOOM_EN_REALIGN_BUF   BIT(9)
 
 #define VFE_0_CORE_CFG 0x050
 #define VFE_0_CORE_CFG_PIXEL_PATTERN_YCBYCR0x4
@@ -87,6 +88,9 @@
 
 #define VFE_0_BUS_XBAR_CFG_x(x)(0x90 + 0x4 * ((x) / 2))
 #define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN  BIT(2)
+#define VFE_0_BUS_XBAR_CFG_x_M_REALIGN_BUF_EN  BIT(3)
+#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTRA  (0x1 << 4)
+#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER  (0x2 << 4)
 #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  0x0
@@ -221,6 +225,11 @@
 #define VFE_0_CLAMP_ENC_MIN_CFG_CH1(0x0 << 8)
 #define VFE_0_CLAMP_ENC_MIN_CFG_CH2(0x0 << 16)
 
+#define VFE_0_REALIGN_BUF_CFG  0xaac
+#define VFE_0_REALIGN_BUF_CFG_CB_ODD_PIXEL BIT(2)
+#define VFE_0_REALIGN_BUF_CFG_CR_ODD_PIXEL BIT(3)
+#define VFE_0_REALIGN_BUF_CFG_HSUB_ENABLE  BIT(4)
+
 #define CAMIF_TIMEOUT_SLEEP_US 1000
 #define CAMIF_TIMEOUT_ALL_US 100
 
@@ -311,7 +320,7 @@ static void vfe_wm_frame_based(struct vfe_device *vfe, u8 
wm, u8 enable)
 
 #define CALC_WORD(width, M, N) (((width) * (M) + (N) - 1) / (N))
 
-static int vfe_word_per_line(u32 format, u32 pixel_per_line)
+static int vfe_word_per_line_by_pixel(u32 format, u32 pixel_per_line)
 {
int val = 0;
 
@@ -333,6 +342,11 @@ static int vfe_word_per_line(u32 format, u32 
pixel_per_line)
return val;
 }
 
+static int vfe_word_per_line_by_bytes(u32 bytes_per_line)
+{
+   return CALC_WORD(bytes_per_line, 1, 8);
+}
+
 static void vfe_get_wm_sizes(struct v4l2_pix_format_mplane *pix, u8 plane,
 u16 *width, u16 *height, u16 *bytesperline)
 {
@@ -351,6 +365,15 @@ static void vfe_get_wm_sizes(struct v4l2_pix_format_mplane 
*pix, u8 plane,
*height = pix->height;
*bytesperline = pix->plane_fmt[0].bytesperline;
break;
+   case V4L2_PIX_FMT_YUYV:
+   case V4L2_PIX_FMT_YVYU:
+   case V4L2_PIX_FMT_VYUY:
+   case V4L2_PIX_FMT_UYVY:
+   *width = pix->width;
+   *height = pix->height;
+   *bytesperline = pix->plane_fmt[plane].bytesperline;
+   break;
+
}
 }
 
@@ -365,7 +388,7 @@ static void vfe_wm_line_based(struct vfe_device *vfe, u32 
wm,
 
vfe_get_wm_sizes(pix, plane, , , );
 
-   wpl = vfe_word_per_line(pix->pixelformat, width);
+   wpl = vfe_word_per_line_by_pixel(pix->pixelformat, width);
 
reg = height - 1;
reg |= ((wpl + 3) / 4 - 1) << 16;
@@ -373,7 +396,7 @@ static void vfe_wm_line_based(struct vfe_device *vfe, u32 
wm,
  

[PATCH v4 21/34] media: camss: csiphy: Add support for 8x96

2018-07-25 Thread Todor Tomov
Add CSIPHY hardware dependent part for 8x96.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/Makefile |   1 +
 .../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 256 +
 drivers/media/platform/qcom/camss/camss-csiphy.c   |   2 +
 drivers/media/platform/qcom/camss/camss-csiphy.h   |   1 +
 4 files changed, 260 insertions(+)
 create mode 100644 drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c

diff --git a/drivers/media/platform/qcom/camss/Makefile 
b/drivers/media/platform/qcom/camss/Makefile
index 0446b24..36b9f7c 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -4,6 +4,7 @@ qcom-camss-objs += \
camss.o \
camss-csid.o \
camss-csiphy-2ph-1-0.o \
+   camss-csiphy-3ph-1-0.o \
camss-csiphy.o \
camss-ispif.o \
camss-vfe.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c 
b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
new file mode 100644
index 000..bcd0dfd
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csiphy-3ph-1-0.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSIPHY Module 3phase v1.0
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2016-2018 Linaro Ltd.
+ */
+
+#include "camss-csiphy.h"
+
+#include 
+#include 
+
+#define CSIPHY_3PH_LNn_CFG1(n) (0x000 + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG1_SWI_REC_DLY_PRG(BIT(7) | BIT(6))
+#define CSIPHY_3PH_LNn_CFG2(n) (0x004 + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG2_LP_REC_EN_INT  BIT(3)
+#define CSIPHY_3PH_LNn_CFG3(n) (0x008 + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG4(n) (0x00c + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG4_T_HS_CLK_MISS  0xa4
+#define CSIPHY_3PH_LNn_CFG5(n) (0x010 + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG5_T_HS_DTERM 0x02
+#define CSIPHY_3PH_LNn_CFG5_HS_REC_EQ_FQ_INT   0x50
+#define CSIPHY_3PH_LNn_TEST_IMP(n) (0x01c + 0x100 * (n))
+#define CSIPHY_3PH_LNn_TEST_IMP_HS_TERM_IMP0xa
+#define CSIPHY_3PH_LNn_MISC1(n)(0x028 + 0x100 * (n))
+#define CSIPHY_3PH_LNn_MISC1_IS_CLKLANEBIT(2)
+#define CSIPHY_3PH_LNn_CFG6(n) (0x02c + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG6_SWI_FORCE_INIT_EXITBIT(0)
+#define CSIPHY_3PH_LNn_CFG7(n) (0x030 + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG7_SWI_T_INIT 0x2
+#define CSIPHY_3PH_LNn_CFG8(n) (0x034 + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG8_SWI_SKIP_WAKEUPBIT(0)
+#define CSIPHY_3PH_LNn_CFG8_SKEW_FILTER_ENABLE BIT(1)
+#define CSIPHY_3PH_LNn_CFG9(n) (0x038 + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CFG9_SWI_T_WAKEUP   0x1
+#define CSIPHY_3PH_LNn_CSI_LANE_CTRL15(n)  (0x03c + 0x100 * (n))
+#define CSIPHY_3PH_LNn_CSI_LANE_CTRL15_SWI_SOT_SYMBOL  0xb8
+
+#define CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(n) (0x800 + 0x4 * (n))
+#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
+#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_IDBIT(1)
+#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(n)   (0x8b0 + 0x4 * (n))
+
+static void csiphy_hw_version_read(struct csiphy_device *csiphy,
+  struct device *dev)
+{
+   u32 hw_version;
+
+   writel(CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID,
+  csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(6));
+
+   hw_version = readl_relaxed(csiphy->base +
+  CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(12));
+   hw_version |= readl_relaxed(csiphy->base +
+  CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(13)) << 8;
+   hw_version |= readl_relaxed(csiphy->base +
+  CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(14)) << 16;
+   hw_version |= readl_relaxed(csiphy->base +
+  CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(15)) << 24;
+
+   dev_err(dev, "CSIPHY 3PH HW Version = 0x%08x\n", hw_version);
+}
+
+/*
+ * csiphy_reset - Perform software reset on CSIPHY module
+ * @csiphy: CSIPHY device
+ */
+static void csiphy_reset(struct csiphy_device *csiphy)
+{
+   writel_relaxed(0x1, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(0));
+   usleep_range(5000, 8000);
+   writel_relaxed(0x0, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(0));
+}
+
+static irqreturn_t csiphy_isr(int irq, void *dev)
+{
+   struct csiphy_device *csiphy = dev;
+   int i;
+
+   for (i = 0; i < 11; i++) {
+   int c = i + 22;
+   u8 val = readl_relaxed(csiphy->base +
+  CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(i));
+
+   writel_relaxed(val, csiphy->base +
+   

[PATCH v4 19/34] media: camss: csiphy: Split to hardware dependent and independent parts

2018-07-25 Thread Todor Tomov
This will allow to add support for different hardware.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/Makefile |   1 +
 .../platform/qcom/camss/camss-csiphy-2ph-1-0.c | 173 +
 drivers/media/platform/qcom/camss/camss-csiphy.c   | 171 +++-
 drivers/media/platform/qcom/camss/camss-csiphy.h   |  17 ++
 4 files changed, 214 insertions(+), 148 deletions(-)
 create mode 100644 drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c

diff --git a/drivers/media/platform/qcom/camss/Makefile 
b/drivers/media/platform/qcom/camss/Makefile
index 3c4024f..0446b24 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -3,6 +3,7 @@
 qcom-camss-objs += \
camss.o \
camss-csid.o \
+   camss-csiphy-2ph-1-0.o \
camss-csiphy.o \
camss-ispif.o \
camss-vfe.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c 
b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
new file mode 100644
index 000..7325906
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csiphy-2ph-1-0.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSIPHY Module 2phase v1.0
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2016-2018 Linaro Ltd.
+ */
+
+#include "camss-csiphy.h"
+
+#include 
+#include 
+
+#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 void csiphy_hw_version_read(struct csiphy_device *csiphy,
+  struct device *dev)
+{
+   u8 hw_version = readl_relaxed(csiphy->base +
+ CAMSS_CSI_PHY_HW_VERSION);
+
+   dev_dbg(dev, "CSIPHY HW Version = 0x%02x\n", hw_version);
+}
+
+/*
+ * 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_settle_cnt_calc - Calculate settle count value
+ *
+ * Helper function to calculate settle count value. This is
+ * based on the CSI2 T_hs_settle parameter which in turn
+ * is calculated based on the CSI2 transmitter pixel clock
+ * frequency.
+ *
+ * Return settle count value or 0 if the CSI2 pixel clock
+ * frequency is not available
+ */
+static u8 csiphy_settle_cnt_calc(u32 pixel_clock, u8 bpp, u8 num_lanes,
+u32 timer_clk_rate)
+{
+   u32 mipi_clock; /* Hz */
+   u32 ui; /* ps */
+   u32 timer_period; /* ps */
+   u32 t_hs_prepare_max; /* ps */
+   u32 t_hs_prepare_zero_min; /* ps */
+   u32 t_hs_settle; /* ps */
+   u8 settle_cnt;
+
+   mipi_clock = pixel_clock * bpp / (2 * num_lanes);
+   ui = div_u64(1LL, mipi_clock);
+   ui /= 2;
+   t_hs_prepare_max = 85000 + 6 * ui;
+   t_hs_prepare_zero_min = 145000 + 10 * ui;
+   t_hs_settle = (t_hs_prepare_max + t_hs_prepare_zero_min) / 2;
+
+   timer_period = div_u64(1LL, timer_clk_rate);
+   settle_cnt = t_hs_settle / timer_period - 1;
+
+   return settle_cnt;
+}
+
+static void csiphy_lanes_enable(struct csiphy_device *csiphy,
+   struct csiphy_config *cfg,
+   u32 pixel_clock, u8 bpp, u8 lane_mask)
+{
+   struct csiphy_lanes_cfg *c = >csi2->lane_cfg;
+   u8 settle_cnt;
+   u8 val;
+   int i = 0;
+
+   settle_cnt = csiphy_settle_cnt_calc(pixel_clock, bpp, c->num_data,
+   csiphy->timer_clk_rate);
+
+   writel_relaxed(0x1, csiphy->base +
+  CAMSS_CSI_PHY_GLBL_T_INIT_CFG0);
+   writel_relaxed(0x1, csiphy->base +
+  CAMSS_CSI_PHY_T_WAKEUP_CFG0);
+
+   val = 0x1;
+   val |= lane_mask << 1;
+   writel_relaxed(val, csiphy->base + CAMSS_CSI_PHY_GLBL_PWR_CFG);
+
+   val = cfg->combo_mode << 4;
+   writel_relaxed(val, csiphy->base + CAMSS_CSI_PHY_GLBL_RESET);
+
+   while (lane_mask) {
+   if (lane_mask & 0x1) {
+   

[PATCH v4 34/34] media: camss: csid: Add support for events triggered by user controls

2018-07-25 Thread Todor Tomov
Changing a user control value can trigger an event to other
users. Add support for that.

Signed-off-by: Todor Tomov 
Acked-by: Sakari Ailus 
---
 drivers/media/platform/qcom/camss/camss-csid.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index 6e141af..729b318 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "camss-csid.h"
@@ -1273,6 +1274,8 @@ static int csid_link_setup(struct media_entity *entity,
 
 static const struct v4l2_subdev_core_ops csid_core_ops = {
.s_power = csid_set_power,
+   .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
+   .unsubscribe_event = v4l2_event_subdev_unsubscribe,
 };
 
 static const struct v4l2_subdev_video_ops csid_video_ops = {
@@ -1318,7 +1321,8 @@ int msm_csid_register_entity(struct csid_device *csid,
 
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
-   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE |
+V4L2_SUBDEV_FL_HAS_EVENTS;
snprintf(sd->name, ARRAY_SIZE(sd->name), "%s%d",
 MSM_CSID_NAME, csid->id);
v4l2_set_subdevdata(sd, csid);
-- 
2.7.4



[PATCH v4 25/34] media: camss: vfe: Add support for 8x96

2018-07-25 Thread Todor Tomov
Add VFE hardware dependent part for 8x96.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/Makefile |   1 +
 drivers/media/platform/qcom/camss/camss-vfe-4-1.c  |   6 +
 .../camss/{camss-vfe-4-1.c => camss-vfe-4-7.c} | 347 -
 drivers/media/platform/qcom/camss/camss-vfe.c  |   4 +
 drivers/media/platform/qcom/camss/camss-vfe.h  |   2 +
 5 files changed, 209 insertions(+), 151 deletions(-)
 copy drivers/media/platform/qcom/camss/{camss-vfe-4-1.c => camss-vfe-4-7.c} 
(75%)

diff --git a/drivers/media/platform/qcom/camss/Makefile 
b/drivers/media/platform/qcom/camss/Makefile
index 38dc56e..f5e6e25 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -8,6 +8,7 @@ qcom-camss-objs += \
camss-csiphy.o \
camss-ispif.o \
camss-vfe-4-1.o \
+   camss-vfe-4-7.o \
camss-vfe.o \
camss-video.o \
 
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c 
b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
index 070c0c3..41184dc 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
@@ -789,6 +789,11 @@ static void vfe_set_qos(struct vfe_device *vfe)
writel_relaxed(val7, vfe->base + VFE_0_BUS_BDG_QOS_CFG_7);
 }
 
+static void vfe_set_ds(struct vfe_device *vfe)
+{
+   /* empty */
+}
+
 static void vfe_set_cgc_override(struct vfe_device *vfe, u8 wm, u8 enable)
 {
u32 val = VFE_0_CGC_OVERRIDE_1_IMAGE_Mx_CGC_OVERRIDE(wm);
@@ -995,6 +1000,7 @@ const struct vfe_hw_ops vfe_ops_4_1 = {
.set_crop_cfg = vfe_set_crop_cfg,
.set_clamp_cfg = vfe_set_clamp_cfg,
.set_qos = vfe_set_qos,
+   .set_ds = vfe_set_ds,
.set_cgc_override = vfe_set_cgc_override,
.set_camif_cfg = vfe_set_camif_cfg,
.set_camif_cmd = vfe_set_camif_cmd,
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c 
b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
similarity index 75%
copy from drivers/media/platform/qcom/camss/camss-vfe-4-1.c
copy to drivers/media/platform/qcom/camss/camss-vfe-4-7.c
index 070c0c3..45e6711 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
@@ -1,8 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * camss-vfe-4-1.c
+ * camss-vfe-4-7.c
  *
- * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v4.1
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v4.7
  *
  * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
  * Copyright (C) 2015-2018 Linaro Ltd.
@@ -15,33 +15,37 @@
 
 #define VFE_0_HW_VERSION   0x000
 
-#define VFE_0_GLOBAL_RESET_CMD 0x00c
+#define VFE_0_GLOBAL_RESET_CMD 0x018
 #define VFE_0_GLOBAL_RESET_CMD_COREBIT(0)
 #define VFE_0_GLOBAL_RESET_CMD_CAMIF   BIT(1)
 #define VFE_0_GLOBAL_RESET_CMD_BUS BIT(2)
 #define VFE_0_GLOBAL_RESET_CMD_BUS_BDG BIT(3)
 #define VFE_0_GLOBAL_RESET_CMD_REGISTERBIT(4)
-#define VFE_0_GLOBAL_RESET_CMD_TIMER   BIT(5)
-#define VFE_0_GLOBAL_RESET_CMD_PM  BIT(6)
-#define VFE_0_GLOBAL_RESET_CMD_BUS_MISRBIT(7)
-#define VFE_0_GLOBAL_RESET_CMD_TESTGEN BIT(8)
-
-#define VFE_0_MODULE_CFG   0x018
-#define VFE_0_MODULE_CFG_DEMUX BIT(2)
-#define VFE_0_MODULE_CFG_CHROMA_UPSAMPLE   BIT(3)
-#define VFE_0_MODULE_CFG_SCALE_ENC BIT(23)
-#define VFE_0_MODULE_CFG_CROP_ENC  BIT(27)
-
-#define VFE_0_CORE_CFG 0x01c
+#define VFE_0_GLOBAL_RESET_CMD_PM  BIT(5)
+#define VFE_0_GLOBAL_RESET_CMD_BUS_MISRBIT(6)
+#define VFE_0_GLOBAL_RESET_CMD_TESTGEN BIT(7)
+#define VFE_0_GLOBAL_RESET_CMD_DSP BIT(8)
+#define VFE_0_GLOBAL_RESET_CMD_IDLE_CGCBIT(9)
+
+#define VFE_0_MODULE_LENS_EN   0x040
+#define VFE_0_MODULE_LENS_EN_DEMUX BIT(2)
+#define VFE_0_MODULE_LENS_EN_CHROMA_UPSAMPLE   BIT(3)
+
+#define VFE_0_MODULE_ZOOM_EN   0x04c
+#define VFE_0_MODULE_ZOOM_EN_SCALE_ENC BIT(1)
+#define VFE_0_MODULE_ZOOM_EN_CROP_ENC  BIT(2)
+
+#define VFE_0_CORE_CFG 0x050
 #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_CORE_CFG_COMPOSITE_REG_UPDATE_EN BIT(4)
 
-#define VFE_0_IRQ_CMD  0x024
+#define VFE_0_IRQ_CMD  0x058
 #define VFE_0_IRQ_CMD_GLOBAL_CLEAR BIT(0)
 
-#define VFE_0_IRQ_MASK_0   0x028
+#define VFE_0_IRQ_MASK_0   0x05c
 #define VFE_0_IRQ_MASK_0_CAMIF_SOF BIT(0)
 #define VFE_0_IRQ_MASK_0_CAMIF_EOF BIT(1)
 #define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)BIT((n) + 5)
@@ -50,17 +54,17 @@
 #define 

[PATCH v4 26/34] media: camss: Format configuration per hardware version

2018-07-25 Thread Todor Tomov
As the 8x16 and 8x96 support different formats, separate the
arrays which contain the supported formats. For the VFE also
add separate arrays for RDI and PIX subdevices.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c   | 196 +++
 drivers/media/platform/qcom/camss/camss-csid.h   |   2 +
 drivers/media/platform/qcom/camss/camss-csiphy.c | 145 -
 drivers/media/platform/qcom/camss/camss-csiphy.h |   2 +
 drivers/media/platform/qcom/camss/camss-ispif.c  |  43 -
 drivers/media/platform/qcom/camss/camss-ispif.h  |   2 +
 drivers/media/platform/qcom/camss/camss-vfe.c| 189 --
 drivers/media/platform/qcom/camss/camss-vfe.h|   2 +
 drivers/media/platform/qcom/camss/camss-video.c  |  97 ++-
 9 files changed, 467 insertions(+), 211 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index 915835e..db960da 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -62,7 +62,7 @@
 
 #define CSID_RESET_TIMEOUT_MS 500
 
-struct csid_fmts {
+struct csid_format {
u32 code;
u8 data_type;
u8 decode_format;
@@ -70,7 +70,7 @@ struct csid_fmts {
u8 spp; /* bus samples per pixel */
 };
 
-static const struct csid_fmts csid_input_fmts[] = {
+static const struct csid_format csid_formats_8x16[] = {
{
MEDIA_BUS_FMT_UYVY8_2X8,
DATA_TYPE_YUV422_8BIT,
@@ -185,17 +185,135 @@ static const struct csid_fmts csid_input_fmts[] = {
}
 };
 
-static const struct csid_fmts *csid_get_fmt_entry(u32 code)
+static const struct csid_format csid_formats_8x96[] = {
+   {
+   MEDIA_BUS_FMT_UYVY8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8,
+   2,
+   },
+   {
+   MEDIA_BUS_FMT_VYUY8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8,
+   2,
+   },
+   {
+   MEDIA_BUS_FMT_YUYV8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8,
+   2,
+   },
+   {
+   MEDIA_BUS_FMT_YVYU8_2X8,
+   DATA_TYPE_YUV422_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8,
+   2,
+   },
+   {
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   DATA_TYPE_RAW_8BIT,
+   DECODE_FORMAT_UNCOMPRESSED_8_BIT,
+   8,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   DATA_TYPE_RAW_10BIT,
+   DECODE_FORMAT_UNCOMPRESSED_10_BIT,
+   10,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SGBRG10_1X10,
+   DATA_TYPE_RAW_10BIT,
+   DECODE_FORMAT_UNCOMPRESSED_10_BIT,
+   10,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SGRBG10_1X10,
+   DATA_TYPE_RAW_10BIT,
+   DECODE_FORMAT_UNCOMPRESSED_10_BIT,
+   10,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SRGGB10_1X10,
+   DATA_TYPE_RAW_10BIT,
+   DECODE_FORMAT_UNCOMPRESSED_10_BIT,
+   10,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SBGGR12_1X12,
+   DATA_TYPE_RAW_12BIT,
+   DECODE_FORMAT_UNCOMPRESSED_12_BIT,
+   12,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SGBRG12_1X12,
+   DATA_TYPE_RAW_12BIT,
+   DECODE_FORMAT_UNCOMPRESSED_12_BIT,
+   12,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SGRBG12_1X12,
+   DATA_TYPE_RAW_12BIT,
+   DECODE_FORMAT_UNCOMPRESSED_12_BIT,
+   12,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SRGGB12_1X12,
+   DATA_TYPE_RAW_12BIT,
+   DECODE_FORMAT_UNCOMPRESSED_12_BIT,
+   12,
+   1,
+   }
+};
+
+static const struct csid_format *csid_get_fmt_entry(
+   const struct csid_format *formats,
+   unsigned int nformat,
+  

[PATCH v4 31/34] media: camss: Add support for RAW MIPI14 on 8x96

2018-07-25 Thread Todor Tomov
Add support for RAW MIPI14 format for RDI mode on 8x96.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c   | 30 
 drivers/media/platform/qcom/camss/camss-csiphy.c |  4 
 drivers/media/platform/qcom/camss/camss-ispif.c  |  4 
 drivers/media/platform/qcom/camss/camss-vfe.c|  4 
 drivers/media/platform/qcom/camss/camss-video.c  |  8 +++
 5 files changed, 50 insertions(+)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index 0715a8e..472884d 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -63,11 +63,13 @@
 #define DATA_TYPE_RAW_8BIT 0x2a
 #define DATA_TYPE_RAW_10BIT0x2b
 #define DATA_TYPE_RAW_12BIT0x2c
+#define DATA_TYPE_RAW_14BIT0x2d
 
 #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 DECODE_FORMAT_UNCOMPRESSED_14_BIT  0x8
 
 #define CSID_RESET_TIMEOUT_MS 500
 
@@ -306,6 +308,34 @@ static const struct csid_format csid_formats_8x96[] = {
DECODE_FORMAT_UNCOMPRESSED_12_BIT,
12,
1,
+   },
+   {
+   MEDIA_BUS_FMT_SBGGR14_1X14,
+   DATA_TYPE_RAW_14BIT,
+   DECODE_FORMAT_UNCOMPRESSED_14_BIT,
+   14,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SGBRG14_1X14,
+   DATA_TYPE_RAW_14BIT,
+   DECODE_FORMAT_UNCOMPRESSED_14_BIT,
+   14,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SGRBG14_1X14,
+   DATA_TYPE_RAW_14BIT,
+   DECODE_FORMAT_UNCOMPRESSED_14_BIT,
+   14,
+   1,
+   },
+   {
+   MEDIA_BUS_FMT_SRGGB14_1X14,
+   DATA_TYPE_RAW_14BIT,
+   DECODE_FORMAT_UNCOMPRESSED_14_BIT,
+   14,
+   1,
}
 };
 
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 3cdab59..cae3e8b 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -64,6 +64,10 @@ static const struct csiphy_format csiphy_formats_8x96[] = {
{ MEDIA_BUS_FMT_SGBRG12_1X12, 12 },
{ MEDIA_BUS_FMT_SGRBG12_1X12, 12 },
{ MEDIA_BUS_FMT_SRGGB12_1X12, 12 },
+   { MEDIA_BUS_FMT_SBGGR14_1X14, 14 },
+   { MEDIA_BUS_FMT_SGBRG14_1X14, 14 },
+   { MEDIA_BUS_FMT_SGRBG14_1X14, 14 },
+   { MEDIA_BUS_FMT_SRGGB14_1X14, 14 },
 };
 
 /*
diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c 
b/drivers/media/platform/qcom/camss/camss-ispif.c
index 81d6351..3e2f341 100644
--- a/drivers/media/platform/qcom/camss/camss-ispif.c
+++ b/drivers/media/platform/qcom/camss/camss-ispif.c
@@ -140,6 +140,10 @@ static const u32 ispif_formats_8x96[] = {
MEDIA_BUS_FMT_SGBRG12_1X12,
MEDIA_BUS_FMT_SGRBG12_1X12,
MEDIA_BUS_FMT_SRGGB12_1X12,
+   MEDIA_BUS_FMT_SBGGR14_1X14,
+   MEDIA_BUS_FMT_SGBRG14_1X14,
+   MEDIA_BUS_FMT_SGRBG14_1X14,
+   MEDIA_BUS_FMT_SRGGB14_1X14,
 };
 
 /*
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c 
b/drivers/media/platform/qcom/camss/camss-vfe.c
index 11d37b7..9675309 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -94,6 +94,10 @@ static const struct vfe_format formats_rdi_8x96[] = {
{ MEDIA_BUS_FMT_SGBRG12_1X12, 12 },
{ MEDIA_BUS_FMT_SGRBG12_1X12, 12 },
{ MEDIA_BUS_FMT_SRGGB12_1X12, 12 },
+   { MEDIA_BUS_FMT_SBGGR14_1X14, 14 },
+   { MEDIA_BUS_FMT_SGBRG14_1X14, 14 },
+   { MEDIA_BUS_FMT_SGRBG14_1X14, 14 },
+   { MEDIA_BUS_FMT_SRGGB14_1X14, 14 },
 };
 
 static const struct vfe_format formats_pix_8x96[] = {
diff --git a/drivers/media/platform/qcom/camss/camss-video.c 
b/drivers/media/platform/qcom/camss/camss-video.c
index 28d53bf..2e19bc8 100644
--- a/drivers/media/platform/qcom/camss/camss-video.c
+++ b/drivers/media/platform/qcom/camss/camss-video.c
@@ -111,6 +111,14 @@ static const struct camss_format_info formats_rdi_8x96[] = 
{
  { { 1, 1 } }, { { 1, 1 } }, { 12 } },
{ MEDIA_BUS_FMT_SRGGB12_1X12, V4L2_PIX_FMT_SRGGB12P, 1,
  { { 1, 1 } }, { { 1, 1 } }, { 12 } },
+   { MEDIA_BUS_FMT_SBGGR14_1X14, V4L2_PIX_FMT_SBGGR14P, 1,
+ { { 1, 1 } }, { { 1, 1 } }, { 14 } },
+   { MEDIA_BUS_FMT_SGBRG14_1X14, V4L2_PIX_FMT_SGBRG14P, 1,
+ { { 1, 1 } }, { { 1, 1 } }, { 14 } },
+   { MEDIA_BUS_FMT_SGRBG14_1X14, V4L2_PIX_FMT_SGRBG14P, 1,
+ { { 1, 1 } }, { { 1, 1 } }, { 14 } },
+   { MEDIA_BUS_FMT_SRGGB14_1X14, V4L2_PIX_FMT_SRGGB14P, 1,
+ { { 1, 1 } }, { { 1, 1 } }, { 14 } },
 

[PATCH v4 17/34] media: camss: Add 8x96 resources

2018-07-25 Thread Todor Tomov
Add structs with 8x96 resources. As the number of CSIPHY, CSID
and VFE hardware modules is different on 8x16 and 8x96 select
the number at runtime and allocate needed structures
dynamically.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c   |  20 +-
 drivers/media/platform/qcom/camss/camss-csid.h   |   3 +-
 drivers/media/platform/qcom/camss/camss-csiphy.c |  19 +-
 drivers/media/platform/qcom/camss/camss-csiphy.h |   4 +-
 drivers/media/platform/qcom/camss/camss-ispif.c  |  35 ++-
 drivers/media/platform/qcom/camss/camss-ispif.h  |   9 +-
 drivers/media/platform/qcom/camss/camss-vfe.c|  61 ++--
 drivers/media/platform/qcom/camss/camss-vfe.h|   4 +-
 drivers/media/platform/qcom/camss/camss.c| 354 ++-
 drivers/media/platform/qcom/camss/camss.h|  20 +-
 10 files changed, 390 insertions(+), 139 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index 3cde07e..627ef44 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -219,7 +219,7 @@ static irqreturn_t csid_isr(int irq, void *dev)
  */
 static int csid_set_clock_rates(struct csid_device *csid)
 {
-   struct device *dev = to_device_index(csid, csid->id);
+   struct device *dev = csid->camss->dev;
u32 pixel_clock;
int i, j;
int ret;
@@ -232,7 +232,9 @@ static int csid_set_clock_rates(struct csid_device *csid)
struct camss_clock *clock = >clock[i];
 
if (!strcmp(clock->name, "csi0") ||
-   !strcmp(clock->name, "csi1")) {
+   !strcmp(clock->name, "csi1") ||
+   !strcmp(clock->name, "csi2") ||
+   !strcmp(clock->name, "csi3")) {
u8 bpp = csid_get_fmt_entry(
csid->fmt[MSM_CSIPHY_PAD_SINK].code)->bpp;
u8 num_lanes = csid->phy.lane_cnt;
@@ -291,8 +293,7 @@ static int csid_reset(struct csid_device *csid)
time = wait_for_completion_timeout(>reset_complete,
msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
if (!time) {
-   dev_err(to_device_index(csid, csid->id),
-   "CSID reset timeout\n");
+   dev_err(csid->camss->dev, "CSID reset timeout\n");
return -EIO;
}
 
@@ -309,7 +310,7 @@ static int csid_reset(struct csid_device *csid)
 static int csid_set_power(struct v4l2_subdev *sd, int on)
 {
struct csid_device *csid = v4l2_get_subdevdata(sd);
-   struct device *dev = to_device_index(csid, csid->id);
+   struct device *dev = csid->camss->dev;
int ret;
 
if (on) {
@@ -375,7 +376,7 @@ static int csid_set_stream(struct v4l2_subdev *sd, int 
enable)
 
ret = v4l2_ctrl_handler_setup(>ctrls);
if (ret < 0) {
-   dev_err(to_device_index(csid, csid->id),
+   dev_err(csid->camss->dev,
"could not sync v4l2 controls: %d\n", ret);
return ret;
}
@@ -796,15 +797,16 @@ static const struct v4l2_ctrl_ops csid_ctrl_ops = {
  *
  * Return 0 on success or a negative error code otherwise
  */
-int msm_csid_subdev_init(struct csid_device *csid,
+int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
 const struct resources *res, u8 id)
 {
-   struct device *dev = to_device_index(csid, id);
+   struct device *dev = camss->dev;
struct platform_device *pdev = to_platform_device(dev);
struct resource *r;
int i, j;
int ret;
 
+   csid->camss = camss;
csid->id = id;
 
/* Memory */
@@ -1018,7 +1020,7 @@ int msm_csid_register_entity(struct csid_device *csid,
 {
struct v4l2_subdev *sd = >subdev;
struct media_pad *pads = csid->pads;
-   struct device *dev = to_device_index(csid, csid->id);
+   struct device *dev = csid->camss->dev;
int ret;
 
v4l2_subdev_init(sd, _v4l2_ops);
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h 
b/drivers/media/platform/qcom/camss/camss-csid.h
index ae1d045..ed605fd 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -42,6 +42,7 @@ struct csid_phy_config {
 };
 
 struct csid_device {
+   struct camss *camss;
u8 id;
struct v4l2_subdev subdev;
struct media_pad pads[MSM_CSID_PADS_NUM];
@@ -61,7 +62,7 @@ struct csid_device {
 
 struct resources;
 
-int msm_csid_subdev_init(struct csid_device *csid,
+int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
 const struct resources *res, u8 id);
 
 int msm_csid_register_entity(struct csid_device *csid,
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 

[PATCH v4 13/34] media: camss: vfe: Get line pointer as container of video_out

2018-07-25 Thread Todor Tomov
Simplify getting of the line pointer by using the container_of
macro instead of traversing media controller links.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-vfe.c | 38 +++
 1 file changed, 4 insertions(+), 34 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c 
b/drivers/media/platform/qcom/camss/camss-vfe.c
index 51ad3f8..77167f1 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -2038,26 +2038,6 @@ static void vfe_put(struct vfe_device *vfe)
 }
 
 /*
- * vfe_video_pad_to_line - Get pointer to VFE line by media pad
- * @pad: Media pad
- *
- * Return pointer to vfe line structure
- */
-static struct vfe_line *vfe_video_pad_to_line(struct media_pad *pad)
-{
-   struct media_pad *vfe_pad;
-   struct v4l2_subdev *subdev;
-
-   vfe_pad = media_entity_remote_pad(pad);
-   if (vfe_pad == NULL)
-   return NULL;
-
-   subdev = media_entity_to_v4l2_subdev(vfe_pad->entity);
-
-   return container_of(subdev, struct vfe_line, subdev);
-}
-
-/*
  * vfe_queue_buffer - Add empty buffer
  * @vid: Video device structure
  * @buf: Buffer to be enqueued
@@ -2070,16 +2050,11 @@ static struct vfe_line *vfe_video_pad_to_line(struct 
media_pad *pad)
 static int vfe_queue_buffer(struct camss_video *vid,
struct camss_buffer *buf)
 {
-   struct vfe_device *vfe = >camss->vfe;
-   struct vfe_line *line;
+   struct vfe_line *line = container_of(vid, struct vfe_line, video_out);
+   struct vfe_device *vfe = to_vfe(line);
struct vfe_output *output;
unsigned long flags;
 
-   line = vfe_video_pad_to_line(>pad);
-   if (!line) {
-   dev_err(to_device(vfe), "Can not queue buffer\n");
-   return -1;
-   }
output = >output;
 
spin_lock_irqsave(>output_lock, flags);
@@ -2104,16 +2079,11 @@ static int vfe_queue_buffer(struct camss_video *vid,
 static int vfe_flush_buffers(struct camss_video *vid,
 enum vb2_buffer_state state)
 {
-   struct vfe_device *vfe = >camss->vfe;
-   struct vfe_line *line;
+   struct vfe_line *line = container_of(vid, struct vfe_line, video_out);
+   struct vfe_device *vfe = to_vfe(line);
struct vfe_output *output;
unsigned long flags;
 
-   line = vfe_video_pad_to_line(>pad);
-   if (!line) {
-   dev_err(to_device(vfe), "Can not flush buffers\n");
-   return -1;
-   }
output = >output;
 
spin_lock_irqsave(>output_lock, flags);
-- 
2.7.4



[PATCH v4 24/34] media: camss: vfe: Split to hardware dependent and independent parts

2018-07-25 Thread Todor Tomov
This will allow to add support for different hardware.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/Makefile|1 +
 drivers/media/platform/qcom/camss/camss-vfe-4-1.c | 1006 +++
 drivers/media/platform/qcom/camss/camss-vfe.c | 1074 ++---
 drivers/media/platform/qcom/camss/camss-vfe.h |   73 +-
 4 files changed, 1169 insertions(+), 985 deletions(-)
 create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-4-1.c

diff --git a/drivers/media/platform/qcom/camss/Makefile 
b/drivers/media/platform/qcom/camss/Makefile
index 36b9f7c..38dc56e 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -7,6 +7,7 @@ qcom-camss-objs += \
camss-csiphy-3ph-1-0.o \
camss-csiphy.o \
camss-ispif.o \
+   camss-vfe-4-1.o \
camss-vfe.o \
camss-video.o \
 
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c 
b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
new file mode 100644
index 000..070c0c3
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
@@ -0,0 +1,1006 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-4-1.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v4.1
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2018 Linaro Ltd.
+ */
+
+#include 
+#include 
+
+#include "camss-vfe.h"
+
+#define VFE_0_HW_VERSION   0x000
+
+#define VFE_0_GLOBAL_RESET_CMD 0x00c
+#define VFE_0_GLOBAL_RESET_CMD_COREBIT(0)
+#define VFE_0_GLOBAL_RESET_CMD_CAMIF   BIT(1)
+#define VFE_0_GLOBAL_RESET_CMD_BUS BIT(2)
+#define VFE_0_GLOBAL_RESET_CMD_BUS_BDG BIT(3)
+#define VFE_0_GLOBAL_RESET_CMD_REGISTERBIT(4)
+#define VFE_0_GLOBAL_RESET_CMD_TIMER   BIT(5)
+#define VFE_0_GLOBAL_RESET_CMD_PM  BIT(6)
+#define VFE_0_GLOBAL_RESET_CMD_BUS_MISRBIT(7)
+#define VFE_0_GLOBAL_RESET_CMD_TESTGEN BIT(8)
+
+#define VFE_0_MODULE_CFG   0x018
+#define VFE_0_MODULE_CFG_DEMUX BIT(2)
+#define VFE_0_MODULE_CFG_CHROMA_UPSAMPLE   BIT(3)
+#define VFE_0_MODULE_CFG_SCALE_ENC BIT(23)
+#define VFE_0_MODULE_CFG_CROP_ENC  BIT(27)
+
+#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 BIT(0)
+
+#define VFE_0_IRQ_MASK_0   0x028
+#define VFE_0_IRQ_MASK_0_CAMIF_SOF BIT(0)
+#define VFE_0_IRQ_MASK_0_CAMIF_EOF BIT(1)
+#define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)BIT((n) + 5)
+#define VFE_0_IRQ_MASK_0_line_n_REG_UPDATE(n)  \
+   ((n) == VFE_LINE_PIX ? BIT(4) : VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n))
+#define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n)   BIT((n) + 8)
+#define VFE_0_IRQ_MASK_0_IMAGE_COMPOSITE_DONE_n(n) BIT((n) + 25)
+#define VFE_0_IRQ_MASK_0_RESET_ACK BIT(31)
+#define VFE_0_IRQ_MASK_1   0x02c
+#define VFE_0_IRQ_MASK_1_CAMIF_ERROR   BIT(0)
+#define VFE_0_IRQ_MASK_1_VIOLATION BIT(7)
+#define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK  BIT(8)
+#define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n)BIT((n) + 9)
+#define VFE_0_IRQ_MASK_1_RDIn_SOF(n)   BIT((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   BIT(0)
+#define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)  BIT((n) + 5)
+#define VFE_0_IRQ_STATUS_0_line_n_REG_UPDATE(n)\
+   ((n) == VFE_LINE_PIX ? BIT(4) : VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n))
+#define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) BIT((n) + 8)
+#define VFE_0_IRQ_STATUS_0_IMAGE_COMPOSITE_DONE_n(n)   BIT((n) + 25)
+#define VFE_0_IRQ_STATUS_0_RESET_ACK   BIT(31)
+#define VFE_0_IRQ_STATUS_1 0x03c
+#define VFE_0_IRQ_STATUS_1_VIOLATION   BIT(7)
+#define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACKBIT(8)
+#define VFE_0_IRQ_STATUS_1_RDIn_SOF(n) BIT((n) + 29)
+
+#define VFE_0_IRQ_COMPOSITE_MASK_0 0x40
+#define VFE_0_VIOLATION_STATUS 0x48
+
+#define VFE_0_BUS_CMD  0x4c
+#define VFE_0_BUS_CMD_Mx_RLD_CMD(x)BIT(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_PAIR_STREAM_EN  BIT(1)
+#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA(0x3 << 4)
+#define 

[PATCH v4 33/34] media: doc: media/v4l-drivers: Update Qualcomm CAMSS driver document for 8x96

2018-07-25 Thread Todor Tomov
Update the document to describe the support of Camera Subsystem
on MSM8996/APQ8096.

Signed-off-by: Todor Tomov 
---
 Documentation/media/v4l-drivers/qcom_camss.rst |  93 +++---
 .../media/v4l-drivers/qcom_camss_8x96_graph.dot| 104 +
 2 files changed, 164 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/media/v4l-drivers/qcom_camss_8x96_graph.dot

diff --git a/Documentation/media/v4l-drivers/qcom_camss.rst 
b/Documentation/media/v4l-drivers/qcom_camss.rst
index 9e66b7b..f27c8df 100644
--- a/Documentation/media/v4l-drivers/qcom_camss.rst
+++ b/Documentation/media/v4l-drivers/qcom_camss.rst
@@ -7,34 +7,34 @@ Introduction
 
 
 This file documents the Qualcomm Camera Subsystem driver located under
-drivers/media/platform/qcom/camss-8x16.
+drivers/media/platform/qcom/camss.
 
 The current version of the driver supports the Camera Subsystem found on
-Qualcomm MSM8916 and APQ8016 processors.
+Qualcomm MSM8916/APQ8016 and MSM8996/APQ8096 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]_.
+driver for Android as found in Code Aurora [#f1]_ [#f2]_.
 
 
 Qualcomm Camera Subsystem hardware
 --
 
-The Camera Subsystem hardware found on 8x16 processors and supported by the
-driver consists of:
+The Camera Subsystem hardware found on 8x16 / 8x96 processors and supported by
+the driver consists of:
 
-- 2 CSIPHY modules. They handle the Physical layer of the CSI2 receivers.
+- 2 / 3 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
+- 2 / 4 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 (Pixel) input
+- 1 / 2 VFE (Video Front End) module(s). Contain a pipeline of image processing
+  hardware blocks. The VFE has different input interfaces. The PIX (Pixel) 
input
   interface feeds the input data to the image processing pipeline. The image
   processing pipeline contains also a scale and crop module at the end. Three
   RDI (Raw Dump Interface) input interfaces bypass the image processing
@@ -49,18 +49,33 @@ The current version of the driver supports:
 
 - 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.
+- RDI interface of VFE
 
-  Supported formats:
+  - Raw dump of the input data to memory.
 
-  - YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2 - V4L2_PIX_FMT_YUYV /
-V4L2_PIX_FMT_UYVY / V4L2_PIX_FMT_YVYU / V4L2_PIX_FMT_VYUY);
-  - MIPI RAW8 (8bit Bayer RAW - V4L2_PIX_FMT_SRGGB8 /
-V4L2_PIX_FMT_SGRBG8 / V4L2_PIX_FMT_SGBRG8 / V4L2_PIX_FMT_SBGGR8);
-  - MIPI RAW10 (10bit packed Bayer RAW - V4L2_PIX_FMT_SBGGR10P /
-V4L2_PIX_FMT_SGBRG10P / V4L2_PIX_FMT_SGRBG10P / V4L2_PIX_FMT_SRGGB10P);
-  - MIPI RAW12 (12bit packed Bayer RAW - V4L2_PIX_FMT_SRGGB12P /
-V4L2_PIX_FMT_SGBRG12P / V4L2_PIX_FMT_SGRBG12P / V4L2_PIX_FMT_SRGGB12P).
+Supported formats:
+
+- YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2 - V4L2_PIX_FMT_YUYV /
+  V4L2_PIX_FMT_UYVY / V4L2_PIX_FMT_YVYU / V4L2_PIX_FMT_VYUY);
+- MIPI RAW8 (8bit Bayer RAW - V4L2_PIX_FMT_SRGGB8 /
+  V4L2_PIX_FMT_SGRBG8 / V4L2_PIX_FMT_SGBRG8 / V4L2_PIX_FMT_SBGGR8);
+- MIPI RAW10 (10bit packed Bayer RAW - V4L2_PIX_FMT_SBGGR10P /
+  V4L2_PIX_FMT_SGBRG10P / V4L2_PIX_FMT_SGRBG10P / V4L2_PIX_FMT_SRGGB10P /
+  V4L2_PIX_FMT_Y10P);
+- MIPI RAW12 (12bit packed Bayer RAW - V4L2_PIX_FMT_SRGGB12P /
+  V4L2_PIX_FMT_SGBRG12P / V4L2_PIX_FMT_SGRBG12P / V4L2_PIX_FMT_SRGGB12P).
+- (8x96 only) MIPI RAW14 (14bit packed Bayer RAW - V4L2_PIX_FMT_SRGGB14P /
+  V4L2_PIX_FMT_SGBRG14P / V4L2_PIX_FMT_SGRBG14P / V4L2_PIX_FMT_SRGGB14P).
+
+  - (8x96 only) Format conversion of the input data.
+
+Supported input formats:
+
+- MIPI RAW10 (10bit packed Bayer RAW - V4L2_PIX_FMT_SBGGR10P / 
V4L2_PIX_FMT_Y10P).
+
+Supported output formats:
+
+- Plain16 RAW10 (10bit unpacked Bayer RAW - V4L2_PIX_FMT_SBGGR10 / 
V4L2_PIX_FMT_Y10).
 
 - 

[PATCH v4 18/34] media: camss: Add basic runtime PM support

2018-07-25 Thread Todor Tomov
There is a PM domain for each of the VFE hardware modules. Add
support for basic runtime PM support to be able to control the
PM domains. When a PM domain needs to be powered on - a device
link is created. When a PM domain needs to be powered off -
its device link is removed. This allows separate and
independent control of the PM domains.

Suspend/Resume is still not supported.

Signed-off-by: Todor Tomov 
---
 drivers/media/platform/qcom/camss/camss-csid.c   | 13 -
 drivers/media/platform/qcom/camss/camss-csiphy.c | 15 +-
 drivers/media/platform/qcom/camss/camss-ispif.c  | 26 --
 drivers/media/platform/qcom/camss/camss-vfe.c| 17 +++
 drivers/media/platform/qcom/camss/camss.c| 63 
 drivers/media/platform/qcom/camss/camss.h| 11 +
 6 files changed, 139 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
b/drivers/media/platform/qcom/camss/camss-csid.c
index 627ef44..3ba087f 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -316,19 +317,27 @@ static int csid_set_power(struct v4l2_subdev *sd, int on)
if (on) {
u32 hw_version;
 
-   ret = regulator_enable(csid->vdda);
+   ret = pm_runtime_get_sync(dev);
if (ret < 0)
return ret;
 
+   ret = regulator_enable(csid->vdda);
+   if (ret < 0) {
+   pm_runtime_put_sync(dev);
+   return ret;
+   }
+
ret = csid_set_clock_rates(csid);
if (ret < 0) {
regulator_disable(csid->vdda);
+   pm_runtime_put_sync(dev);
return ret;
}
 
ret = camss_enable_clocks(csid->nclocks, csid->clock, dev);
if (ret < 0) {
regulator_disable(csid->vdda);
+   pm_runtime_put_sync(dev);
return ret;
}
 
@@ -339,6 +348,7 @@ static int csid_set_power(struct v4l2_subdev *sd, int on)
disable_irq(csid->irq);
camss_disable_clocks(csid->nclocks, csid->clock);
regulator_disable(csid->vdda);
+   pm_runtime_put_sync(dev);
return ret;
}
 
@@ -348,6 +358,7 @@ static int csid_set_power(struct v4l2_subdev *sd, int on)
disable_irq(csid->irq);
camss_disable_clocks(csid->nclocks, csid->clock);
ret = regulator_disable(csid->vdda);
+   pm_runtime_put_sync(dev);
}
 
return ret;
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 0383e94..4aeaedb 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -240,13 +241,21 @@ static int csiphy_set_power(struct v4l2_subdev *sd, int 
on)
u8 hw_version;
int ret;
 
-   ret = csiphy_set_clock_rates(csiphy);
+   ret = pm_runtime_get_sync(dev);
if (ret < 0)
return ret;
 
+   ret = csiphy_set_clock_rates(csiphy);
+   if (ret < 0) {
+   pm_runtime_put_sync(dev);
+   return ret;
+   }
+
ret = camss_enable_clocks(csiphy->nclocks, csiphy->clock, dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_sync(dev);
return ret;
+   }
 
enable_irq(csiphy->irq);
 
@@ -259,6 +268,8 @@ static int csiphy_set_power(struct v4l2_subdev *sd, int on)
disable_irq(csiphy->irq);
 
camss_disable_clocks(csiphy->nclocks, csiphy->clock);
+
+   pm_runtime_put_sync(dev);
}
 
return 0;
diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c 
b/drivers/media/platform/qcom/camss/camss-ispif.c
index ed50cc5..2c6c0d2 100644
--- a/drivers/media/platform/qcom/camss/camss-ispif.c
+++ b/drivers/media/platform/qcom/camss/camss-ispif.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -169,6 +170,14 @@ static int ispif_reset(struct ispif_device *ispif)
u32 val;
int ret;
 
+   ret = camss_pm_domain_on(to_camss(ispif), PM_DOMAIN_VFE0);
+   if (ret < 0)
+   return ret;
+
+   ret = camss_pm_domain_on(to_camss(ispif), PM_DOMAIN_VFE1);
+   if (ret < 0)
+   return ret;
+
ret = 

[PATCH v4 01/34] doc-rst: Add packed Bayer raw14 pixel formats

2018-07-25 Thread Todor Tomov
From: Sakari Ailus 

These formats are compressed 14-bit raw bayer formats with four different
pixel orders. They are similar to 10-bit variants. The formats added by
this patch are

V4L2_PIX_FMT_SBGGR14P
V4L2_PIX_FMT_SGBRG14P
V4L2_PIX_FMT_SGRBG14P
V4L2_PIX_FMT_SRGGB14P

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
Signed-off-by: Todor Tomov 
---
 Documentation/media/uapi/v4l/pixfmt-rgb.rst  |   1 +
 Documentation/media/uapi/v4l/pixfmt-srggb14p.rst | 127 +++
 drivers/media/v4l2-core/v4l2-ioctl.c |   4 +
 include/uapi/linux/videodev2.h   |   5 +
 4 files changed, 137 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb14p.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst 
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index cf2ef7d..1f9a7e3 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -19,4 +19,5 @@ RGB Formats
 pixfmt-srggb10-ipu3
 pixfmt-srggb12
 pixfmt-srggb12p
+pixfmt-srggb14p
 pixfmt-srggb16
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst
new file mode 100644
index 000..88d20c0
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst
@@ -0,0 +1,127 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-SRGGB14P:
+.. _v4l2-pix-fmt-sbggr14p:
+.. _v4l2-pix-fmt-sgbrg14p:
+.. _v4l2-pix-fmt-sgrbg14p:
+
+***
+V4L2_PIX_FMT_SRGGB14P ('pRCC'), V4L2_PIX_FMT_SGRBG14P ('pgCC'), 
V4L2_PIX_FMT_SGBRG14P ('pGCC'), V4L2_PIX_FMT_SBGGR14P ('pBCC'),
+***
+
+*man V4L2_PIX_FMT_SRGGB14P(2)*
+
+V4L2_PIX_FMT_SGRBG14P
+V4L2_PIX_FMT_SGBRG14P
+V4L2_PIX_FMT_SBGGR14P
+14-bit packed Bayer formats
+
+
+Description
+===
+
+These four pixel formats are packed raw sRGB / Bayer formats with 14
+bits per colour. Every four consecutive samples are packed into seven
+bytes. Each of the first four bytes contain the eight high order bits
+of the pixels, and the three following bytes contains the six least
+significants bits of each pixel, in the same order.
+
+Each n-pixel row contains n/2 green samples and n/2 blue or red samples,
+with alternating green-red and green-blue rows. They are conventionally
+described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example
+of one of these formats:
+
+**Byte Order.**
+Each cell is one byte.
+
+
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   2 1 1 1 1 1 1 1
+
+
+-  .. row 1
+
+   -  start + 0:
+
+   -  B\ :sub:`00high`
+
+   -  G\ :sub:`01high`
+
+   -  B\ :sub:`02high`
+
+   -  G\ :sub:`03high`
+
+   -  G\ :sub:`01low bits 1--0`\ (bits 7--6)
+ B\ :sub:`00low bits 5--0`\ (bits 5--0)
+
+   -  R\ :sub:`02low bits 3--0`\ (bits 7--4)
+ G\ :sub:`01low bits 5--2`\ (bits 3--0)
+
+   -  G\ :sub:`03low bits 5--0`\ (bits 7--2)
+ R\ :sub:`02low bits 5--4`\ (bits 1--0)
+
+-  .. row 2
+
+   -  start + 7:
+
+   -  G\ :sub:`00high`
+
+   -  R\ :sub:`01high`
+
+   -  G\ :sub:`02high`
+
+   -  R\ :sub:`03high`
+
+   -  R\ :sub:`01low bits 1--0`\ (bits 7--6)
+ G\ :sub:`00low bits 5--0`\ (bits 5--0)
+
+   -  G\ :sub:`02low bits 3--0`\ (bits 7--4)
+ R\ :sub:`01low bits 5--2`\ (bits 3--0)
+
+   -  R\ :sub:`03low bits 5--0`\ (bits 7--2)
+ G\ :sub:`02low bits 5--4`\ (bits 1--0)
+
+-  .. row 3
+
+   -  start + 14
+
+   -  B\ :sub:`20high`
+
+   -  G\ :sub:`21high`
+
+   -  B\ :sub:`22high`
+
+   -  G\ :sub:`23high`
+
+   -  G\ :sub:`21low bits 1--0`\ (bits 7--6)
+ B\ :sub:`20low bits 5--0`\ (bits 5--0)
+
+   -  R\ :sub:`22low bits 3--0`\ (bits 7--4)
+ G\ :sub:`21low bits 5--2`\ (bits 3--0)
+
+   -  G\ :sub:`23low bits 5--0`\ (bits 7--2)
+ R\ :sub:`22low bits 5--4`\ (bits 1--0)
+
+-  .. row 4
+
+   -  start + 21
+
+   -  G\ :sub:`30high`
+
+   -  R\ :sub:`31high`
+
+   -  G\ :sub:`32high`
+
+   -  R\ :sub:`33high`
+
+   -  R\ :sub:`31low bits 1--0`\ (bits 7--6)
+ G\ :sub:`30low bits 5--0`\ (bits 5--0)
+
+   -  G\ :sub:`32low bits 3--0`\ (bits 7--4)
+ R\ :sub:`31low bits 5--2`\ (bits 3--0)
+
+   -  R\ :sub:`33low bits 5--0`\ (bits 7--2)
+ G\ :sub:`32low bits 5--4`\ (bits 1--0)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 0167056..04e1231 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1259,6 +1259,10 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_SGBRG12P: descr = 

[PATCH v4 02/34] media: v4l: Add new 2X8 10-bit grayscale media bus code

2018-07-25 Thread Todor Tomov
The code will be called MEDIA_BUS_FMT_Y10_2X8_PADHI_LE.
It is similar to MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE
but MEDIA_BUS_FMT_Y10_2X8_PADHI_LE describes grayscale
data.

Signed-off-by: Todor Tomov 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 72 +
 include/uapi/linux/media-bus-format.h   |  3 +-
 2 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index a4739f7..8e73fcf 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -4318,6 +4318,78 @@ the following codes.
   - y\ :sub:`2`
   - y\ :sub:`1`
   - y\ :sub:`0`
+* .. _MEDIA-BUS-FMT-Y10-2X8-PADHI_LE:
+
+  - MEDIA_BUS_FMT_Y10_2X8_PADHI_LE
+  - 0x202c
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  - y\ :sub:`7`
+  - y\ :sub:`6`
+  - y\ :sub:`5`
+  - y\ :sub:`4`
+  - y\ :sub:`3`
+  - y\ :sub:`2`
+  - y\ :sub:`1`
+  - y\ :sub:`0`
+* -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - y\ :sub:`9`
+  - y\ :sub:`8`
 * .. _MEDIA-BUS-FMT-UYVY10-2X10:
 
   - MEDIA_BUS_FMT_UYVY10_2X10
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 9e35117..d6a5a3b 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -62,7 +62,7 @@
 #define MEDIA_BUS_FMT_RGB121212_1X36   0x1019
 #define MEDIA_BUS_FMT_RGB161616_1X48   0x101a
 
-/* YUV (including grey) - next is  0x202c */
+/* YUV (including grey) - next is  0x202d */
 #define MEDIA_BUS_FMT_Y8_1X8   0x2001
 #define MEDIA_BUS_FMT_UV8_1X8  0x2015
 #define MEDIA_BUS_FMT_UYVY8_1_5X8  0x2002
@@ -74,6 +74,7 @@
 #define MEDIA_BUS_FMT_YUYV8_2X80x2008
 #define MEDIA_BUS_FMT_YVYU8_2X80x2009
 #define MEDIA_BUS_FMT_Y10_1X10 0x200a
+#define MEDIA_BUS_FMT_Y10_2X8_PADHI_LE 0x202c
 #define MEDIA_BUS_FMT_UYVY10_2X10  0x2018
 #define MEDIA_BUS_FMT_VYUY10_2X10  0x2019
 #define MEDIA_BUS_FMT_YUYV10_2X10  0x200b
-- 
2.7.4



[PATCH v6 2/2] media: imx274: add cropping support via SELECTION API

2018-07-25 Thread Luca Ceresoli
Currently this driver does not support cropping. The supported modes
are the following, all capturing the entire area:

 - 3840x2160, 1:1 binning (native sensor resolution)
 - 1920x1080, 2:1 binning
 - 1280x720,  3:1 binning

The VIDIOC_SUBDEV_S_FMT ioctl chooses among these 3 configurations the
one that matches the requested format.

Add cropping support via VIDIOC_SUBDEV_S_SELECTION: with target
V4L2_SEL_TGT_CROP to choose the captured area, with
V4L2_SEL_TGT_COMPOSE to choose the output resolution.

To maintain backward compatibility we also allow setting the compose
format via VIDIOC_SUBDEV_S_FMT. To obtain this, compose rect and
output format are computed in the common helper function
__imx274_change_compose(), which sets both to the same width/height
values.

Cropping also calls __imx274_change_compose() whenever cropping rect
size changes in order to reset the compose rect (and output format
size) for 1:1 binning.

Also rename enum imx274_mode to imx274_binning (and its values from
IMX274_MODE_BINNING_* to IMX274_BINNING_*). Without cropping, the two
naming are equivalent. With cropping, the resolution could be
different, e.g. using 2:1 binning mode to crop 1200x960 and output a
600x480 format. Using binning in the names avoids any
misunderstanding. For the same reason, replace the 'size' field in
struct imx274_frmfmt with 'bin_ratio'.

Signed-off-by: Luca Ceresoli 
Cc: Sakari Ailus 

---
Changed v5 -> v6:
 - simplify last call to imx274_write_mbreg() (Sakari)
 - fix typo in comment
 - remove unused variable

Changed v4 -> v5:
 - use imx274_write_mbreg, not prepare_reg (it doesn't exist in v5)
 - order #includes alphabetically (Sakari)
 - rename imx274_mode to imx274_binning and
   IMX274_MODE_BINNING_* to IMX274_BINNING_* (Sakari)
 - fix doc syntax (Sakari)
 - remove debug prints that should not be in individual drivers (Sakari)
 - honor the GE/LE selection flags (algorithm inspired to smiapp) (Sakari)
 - remove the compose rect from struct stimx274; it duplicates info
   that we already store in stimx274.format
 - minor cleanups

Changed v3 -> v4:
 - Set the binning via the SELECTION API (COMPOSE rect), but still
   allow using VIDIOC_SUBDEV_S_FMT for backward compatibility.
 - rename imx274_set_trimming -> imx274_apply_trimming for clarity

Changed v2 -> v3:
 - Remove hard-coded HMAX reg setting from all modes, not only the
   first one. HMAX is always computed and set in s_stream now.
 - Reword commit log message.

Changed v1 -> v2:
 - add "media: " prefix to commit message
---
 drivers/media/i2c/imx274.c | 464 +
 1 file changed, 373 insertions(+), 91 deletions(-)

diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index 093c4587832a..2d859f46ce13 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -5,6 +5,7 @@
  *
  * Leon Luo 
  * Edwin Zou 
+ * Luca Ceresoli 
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -74,7 +76,7 @@
  */
 #define IMX274_MIN_EXPOSURE_TIME   (4 * 260 / 72)
 
-#define IMX274_DEFAULT_MODEIMX274_MODE_3840X2160
+#define IMX274_DEFAULT_MODEIMX274_BINNING_OFF
 #define IMX274_MAX_WIDTH   (3840)
 #define IMX274_MAX_HEIGHT  (2160)
 #define IMX274_MAX_FRAME_RATE  (120)
@@ -111,6 +113,20 @@
 #define IMX274_SHR_REG_LSB 0x300C /* SHR */
 #define IMX274_SVR_REG_MSB 0x300F /* SVR */
 #define IMX274_SVR_REG_LSB 0x300E /* SVR */
+#define IMX274_HTRIM_EN_REG0x3037
+#define IMX274_HTRIM_START_REG_LSB 0x3038
+#define IMX274_HTRIM_START_REG_MSB 0x3039
+#define IMX274_HTRIM_END_REG_LSB   0x303A
+#define IMX274_HTRIM_END_REG_MSB   0x303B
+#define IMX274_VWIDCUTEN_REG   0x30DD
+#define IMX274_VWIDCUT_REG_LSB 0x30DE
+#define IMX274_VWIDCUT_REG_MSB 0x30DF
+#define IMX274_VWINPOS_REG_LSB 0x30E0
+#define IMX274_VWINPOS_REG_MSB 0x30E1
+#define IMX274_WRITE_VSIZE_REG_LSB 0x3130
+#define IMX274_WRITE_VSIZE_REG_MSB 0x3131
+#define IMX274_Y_OUT_SIZE_REG_LSB  0x3132
+#define IMX274_Y_OUT_SIZE_REG_MSB  0x3133
 #define IMX274_VMAX_REG_1  0x30FA /* VMAX, MSB */
 #define IMX274_VMAX_REG_2  0x30F9 /* VMAX */
 #define IMX274_VMAX_REG_3  0x30F8 /* VMAX, LSB */
@@ -140,10 +156,10 @@ static const struct regmap_config imx274_regmap_config = {
.cache_type = REGCACHE_RBTREE,
 };
 
-enum imx274_mode {
-   IMX274_MODE_3840X2160,
-   IMX274_MODE_1920X1080,
-   IMX274_MODE_1280X720,
+enum imx274_binning {
+   

[PATCH v6 1/2] media: imx274: use regmap_bulk_write to write multybyte registers

2018-07-25 Thread Luca Ceresoli
Currently 2-bytes and 3-bytes registers are set by very similar
functions doing the needed shift & mask manipulation, followed by very
similar for loops setting one byte at a time over I2C.

Replace all of this code by a unique helper function that calls
regmap_bulk_write(), which has two advantages:
 - sets all the bytes in a unique I2C transaction
 - removes lots of now unused code.

Signed-off-by: Luca Ceresoli 
Cc: Sakari Ailus 

---
Changed v5 -> v6:
 - fix warning on debug print on 32-bit machines (reported by the
   kbuild test robot)
 - fix line above 80 chars

Changed v4 -> v5:
 - completely replace the former patch adding prepare_regs() by
   directly calling regmap_bulk_write() (Sakari)

Changed v3 -> v4: nothing

Changed v2 -> v3:
 - minor reformatting in prepare_reg() documentation

Changed v1 -> v2:
 - add "media: " prefix to commit message
---
 drivers/media/i2c/imx274.c | 102 ++---
 1 file changed, 39 insertions(+), 63 deletions(-)

diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index edca63eaea9b..093c4587832a 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -690,6 +690,35 @@ static inline int imx274_write_reg(struct stimx274 *priv, 
u16 addr, u8 val)
return err;
 }
 
+/**
+ * Write a multibyte register.
+ *
+ * Uses a bulk write where possible.
+ *
+ * @priv: Pointer to device structure
+ * @addr: Address of the LSB register.  Other registers must be
+ *consecutive, least-to-most significant.
+ * @val: Value to be written to the register (cpu endianness)
+ * @nbytes: Number of bits to write (range: [1..3])
+ */
+static int imx274_write_mbreg(struct stimx274 *priv, u16 addr, u32 val,
+ size_t nbytes)
+{
+   __le32 val_le = cpu_to_le32(val);
+   int err;
+
+   err = regmap_bulk_write(priv->regmap, addr, _le, nbytes);
+   if (err)
+   dev_err(>client->dev,
+   "%s : i2c bulk write failed, %x = %x (%zu bytes)\n",
+   __func__, addr, val, nbytes);
+   else
+   dev_dbg(>client->dev,
+   "%s : addr 0x%x, val=0x%x (%zu bytes)\n",
+   __func__, addr, val, nbytes);
+   return err;
+}
+
 /*
  * Set mode registers to start stream.
  * @priv: Pointer to device structure
@@ -1163,15 +1192,6 @@ static int imx274_set_digital_gain(struct stimx274 
*priv, u32 dgain)
reg_val & IMX274_MASK_LSB_4_BITS);
 }
 
-static inline void imx274_calculate_gain_regs(struct reg_8 regs[2], u16 gain)
-{
-   regs->addr = IMX274_ANALOG_GAIN_ADDR_MSB;
-   regs->val = (gain >> IMX274_SHIFT_8_BITS) & IMX274_MASK_LSB_3_BITS;
-
-   (regs + 1)->addr = IMX274_ANALOG_GAIN_ADDR_LSB;
-   (regs + 1)->val = (gain) & IMX274_MASK_LSB_8_BITS;
-}
-
 /*
  * imx274_set_gain - Function called when setting gain
  * @priv: Pointer to device structure
@@ -1185,10 +1205,8 @@ static inline void imx274_calculate_gain_regs(struct 
reg_8 regs[2], u16 gain)
  */
 static int imx274_set_gain(struct stimx274 *priv, struct v4l2_ctrl *ctrl)
 {
-   struct reg_8 reg_list[2];
int err;
u32 gain, analog_gain, digital_gain, gain_reg;
-   int i;
 
gain = (u32)(ctrl->val);
 
@@ -1229,14 +1247,10 @@ static int imx274_set_gain(struct stimx274 *priv, 
struct v4l2_ctrl *ctrl)
if (gain_reg > IMX274_GAIN_REG_MAX)
gain_reg = IMX274_GAIN_REG_MAX;
 
-   imx274_calculate_gain_regs(reg_list, (u16)gain_reg);
-
-   for (i = 0; i < ARRAY_SIZE(reg_list); i++) {
-   err = imx274_write_reg(priv, reg_list[i].addr,
-  reg_list[i].val);
-   if (err)
-   goto fail;
-   }
+   err = imx274_write_mbreg(priv, IMX274_ANALOG_GAIN_ADDR_LSB, gain_reg,
+2);
+   if (err)
+   goto fail;
 
if (IMX274_GAIN_CONST - gain_reg == 0) {
err = -EINVAL;
@@ -1258,16 +1272,6 @@ static int imx274_set_gain(struct stimx274 *priv, struct 
v4l2_ctrl *ctrl)
return err;
 }
 
-static inline void imx274_calculate_coarse_time_regs(struct reg_8 regs[2],
-u32 coarse_time)
-{
-   regs->addr = IMX274_SHR_REG_MSB;
-   regs->val = (coarse_time >> IMX274_SHIFT_8_BITS)
-   & IMX274_MASK_LSB_8_BITS;
-   (regs + 1)->addr = IMX274_SHR_REG_LSB;
-   (regs + 1)->val = (coarse_time) & IMX274_MASK_LSB_8_BITS;
-}
-
 /*
  * imx274_set_coarse_time - Function called when setting SHR value
  * @priv: Pointer to device structure
@@ -1279,10 +1283,8 @@ static inline void 
imx274_calculate_coarse_time_regs(struct reg_8 regs[2],
  */
 static int imx274_set_coarse_time(struct stimx274 *priv, u32 *val)
 {
-   struct reg_8 reg_list[2];
int err;
u32 coarse_time, frame_length;
-   int i;
 
coarse_time = 

[PATCH v6 0/2] media: imx274: cleanups, improvements and SELECTION API support

2018-07-25 Thread Luca Ceresoli
Hi,

this patchset introduces cropping support for the Sony IMX274 sensor
using the SELECTION API.

Changes since v5 are only minor fixes and cleanups.

Patch 1 introduces a helper to greatly simplify the code to write a
multibyte register.

Patch 2 implements the set_selection pad operation for cropping
(V4L2_SEL_TGT_CROP) and binning (V4L2_SEL_TGT_COMPOSE).

Usage examples:

 * Capture the entire 4K area, downscaled to 1080p with 2:1 binning:
   media-ctl -V '"IMX274":0[crop:(0,0)/3840x2160]'
   media-ctl -V '"IMX274":0[compose:(0,0)/1920x1080]'

 * Capture the central 1080p area (no binning):
   media-ctl -V '"IMX274":0[crop:(960,540)/1920x1080]'
   (this also sets the compose and fmt rects to 1920x1080)

Regards,
Luca


Luca Ceresoli (2):
  media: imx274: use regmap_bulk_write to write multybyte registers
  media: imx274: add cropping support via SELECTION API

 drivers/media/i2c/imx274.c | 566 +++--
 1 file changed, 412 insertions(+), 154 deletions(-)

-- 
2.17.1



[ragnatech:media-tree] BUILD INCOMPLETE 231783073ebfc4acf02a45cb78a52ffa16e4e6d3

2018-07-25 Thread kbuild test robot
tree/branch: git://git.ragnatech.se/linux  media-tree
branch HEAD: 231783073ebfc4acf02a45cb78a52ffa16e4e6d3  media: v4l: rcar_fdp1: 
Enable compilation on Gen2 platforms

TIMEOUT after 600m


Sorry we cannot finish the testset for your branch within a reasonable time.
It's our fault -- either some build server is down or some build worker is busy
doing bisects for _other_ trees. The branch will get more complete coverage and
possible error reports when our build infrastructure is restored or catches up.
There will be no more build success notification for this branch head, but you
can expect reasonably good test coverage after waiting for 1 day.

configs tested: 50

i386   tinyconfig
i386   randconfig-x012-201829
i386   randconfig-x017-201829
i386   randconfig-x014-201829
i386   randconfig-x016-201829
i386   randconfig-x013-201829
i386   randconfig-x011-201829
i386   randconfig-x018-201829
i386   randconfig-x010-201829
i386   randconfig-x015-201829
i386   randconfig-x019-201829
x86_64 randconfig-x007-201829
x86_64 randconfig-x003-201829
x86_64 randconfig-x000-201829
x86_64 randconfig-x005-201829
x86_64 randconfig-x004-201829
x86_64 randconfig-x008-201829
x86_64 randconfig-x001-201829
x86_64 randconfig-x009-201829
x86_64 randconfig-x002-201829
x86_64 randconfig-x006-201829
x86_64 acpi-redef
x86_64   allyesdebian
x86_64nfsroot
x86_64 randconfig-x010-201829
x86_64 randconfig-x011-201829
x86_64 randconfig-x012-201829
x86_64 randconfig-x013-201829
x86_64 randconfig-x014-201829
x86_64 randconfig-x015-201829
x86_64 randconfig-x016-201829
x86_64 randconfig-x017-201829
x86_64 randconfig-x018-201829
x86_64 randconfig-x019-201829
ia64 alldefconfig
ia64  allnoconfig
ia64defconfig
openriscor1ksim_defconfig
um i386_defconfig
um   x86_64_defconfig
c6xevmc6678_defconfig
h8300h8300h-sim_defconfig
nios2 10m50_defconfig
xtensa   common_defconfig
xtensa  iss_defconfig
alpha   defconfig
pariscallnoconfig
parisc b180_defconfig
pariscc3000_defconfig
parisc  defconfig

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


Re: [PATCH v7 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

2018-07-25 Thread Sakari Ailus
On Tue, Jul 03, 2018 at 03:08:03PM +0100, Rui Miguel Silva wrote:
> This patch adds V4L2 sub-device driver for OV2680 image sensor.
> The OV2680 is a 1/5" CMOS color sensor from Omnivision.
> Supports output format: 10-bit Raw RGB.
> The OV2680 has a single lane MIPI interface.
> 
> The driver exposes following V4L2 controls:
> - auto/manual exposure,
> - exposure,
> - auto/manual gain,
> - gain,
> - horizontal/vertical flip,
> - test pattern menu.
> Supported resolution are only: QUXGA, 720P, UXGA.
> 
> Signed-off-by: Rui Miguel Silva 

Hi Rui,

Could you provide a MAINTAINERS entry patch for the driver as well as the
DT bindings? I'll squash that to the first one.

-- 
Regards,

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


Re: SFP Optical Module factory

2018-07-25 Thread Jacky

Dear Buyer,

 

We are the Optical Module manufacture for many years, If you need below fiber modules, please let us know.


SFP Module 155M, 1.25G, 2.5G


SFP+ 10G


QSFP 40G 100G

 

XFP


X2


XENPAK


PON

 etc

1.25G SFP, Bidi, Single Fiber 1310, 1550nm, 20km, with DDM, 

11.9USD/Pair(two pcs)


SFP+10G+LR  SFP+ 10G 1310nm  

16.9USD/PC


All the products offer 4years warranty, 

 

Our SFP could change the soft code, so that if you want compatible with Cisco, Finisar, HP, Mikrotik, Ericsson, Nortel Arista, Juniper, Extreme, Allied Telesis, Foundry, Force10, Alcatel-Lucent, only change the SFP code, it is ok. no need keep many stock

 

If you need catalog or pricelist, please let me know, I will send you web, catalog, pricelist 

 

Regards,  

Jacky

whatsapp:0086-13632959327
Skype:credjacky
Email: credja...@gmail.com



Re: [PATCH 2/2] media: docs-rst: Document memory-to-memory video encoder interface

2018-07-25 Thread Hans Verkuil
On 24/07/18 16:06, Tomasz Figa wrote:
> Due to complexity of the video encoding process, the V4L2 drivers of
> stateful encoder hardware require specific sequences of V4L2 API calls
> to be followed. These include capability enumeration, initialization,
> encoding, encode parameters change, drain and reset.
> 
> Specifics of the above have been discussed during Media Workshops at
> LinuxCon Europe 2012 in Barcelona and then later Embedded Linux
> Conference Europe 2014 in Düsseldorf. The de facto Codec API that
> originated at those events was later implemented by the drivers we already
> have merged in mainline, such as s5p-mfc or coda.
> 
> The only thing missing was the real specification included as a part of
> Linux Media documentation. Fix it now and document the encoder part of
> the Codec API.
> 
> Signed-off-by: Tomasz Figa 
> ---
>  Documentation/media/uapi/v4l/dev-encoder.rst | 550 +++
>  Documentation/media/uapi/v4l/devices.rst |   1 +
>  Documentation/media/uapi/v4l/v4l2.rst|   2 +
>  3 files changed, 553 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/dev-encoder.rst
> 
> diff --git a/Documentation/media/uapi/v4l/dev-encoder.rst 
> b/Documentation/media/uapi/v4l/dev-encoder.rst
> new file mode 100644
> index ..28be1698e99c
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/dev-encoder.rst
> @@ -0,0 +1,550 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _encoder:
> +
> +
> +Memory-to-memory Video Encoder Interface
> +
> +
> +Input data to a video encoder are raw video frames in display order
> +to be encoded into the output bitstream. Output data are complete chunks of
> +valid bitstream, including all metadata, headers, etc. The resulting stream
> +must not need any further post-processing by the client.

Due to the confusing use capture and output I wonder if it would be better to
rephrase this as follows:

"A video encoder takes raw video frames in display order and encodes them into
a bitstream. It generates complete chunks of the bitstream, including
all metadata, headers, etc. The resulting bitstream does not require any further
post-processing by the client."

Something similar should be done for the decoder documentation.

> +
> +Performing software stream processing, header generation etc. in the driver
> +in order to support this interface is strongly discouraged. In case such
> +operations are needed, use of Stateless Video Encoder Interface (in
> +development) is strongly advised.
> +
> +Conventions and notation used in this document
> +==
> +
> +1. The general V4L2 API rules apply if not specified in this document
> +   otherwise.
> +
> +2. The meaning of words “must”, “may”, “should”, etc. is as per RFC
> +   2119.
> +
> +3. All steps not marked “optional” are required.
> +
> +4. :c:func:`VIDIOC_G_EXT_CTRLS`, :c:func:`VIDIOC_S_EXT_CTRLS` may be used
> +   interchangeably with :c:func:`VIDIOC_G_CTRL`, :c:func:`VIDIOC_S_CTRL`,
> +   unless specified otherwise.
> +
> +5. Single-plane API (see spec) and applicable structures may be used
> +   interchangeably with Multi-plane API, unless specified otherwise,
> +   depending on driver capabilities and following the general V4L2
> +   guidelines.
> +
> +6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
> +   [0..2]: i = 0, 1, 2.
> +
> +7. For ``OUTPUT`` buffer A, A’ represents a buffer on the ``CAPTURE`` queue
> +   containing data (encoded frame/stream) that resulted from processing
> +   buffer A.
> +
> +Glossary
> +
> +
> +CAPTURE
> +   the destination buffer queue; the queue of buffers containing encoded
> +   bitstream; ``V4L2_BUF_TYPE_VIDEO_CAPTURE or
> +   ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``; data are captured from the
> +   hardware into ``CAPTURE`` buffers
> +
> +client
> +   application client communicating with the driver implementing this API
> +
> +coded format
> +   encoded/compressed video bitstream format (e.g. H.264, VP8, etc.);
> +   see also: raw format
> +
> +coded height
> +   height for given coded resolution
> +
> +coded resolution
> +   stream resolution in pixels aligned to codec and hardware requirements;
> +   typically visible resolution rounded up to full macroblocks; see also:
> +   visible resolution
> +
> +coded width
> +   width for given coded resolution
> +
> +decode order
> +   the order in which frames are decoded; may differ from display order if
> +   coded format includes a feature of frame reordering; ``CAPTURE`` buffers
> +   must be returned by the driver in decode order
> +
> +display order
> +   the order in which frames must be displayed; ``OUTPUT`` buffers must be
> +   queued by the client in display order
> +
> +IDR
> +   a type of a keyframe in H.264-encoded stream, which clears the list of
> +   earlier reference frames (DPBs)

Same problem as with the previous patch: 

Re: media: dvb-usb-v2/gl861: ensure USB message buffers DMA'able

2018-07-25 Thread Mauro Carvalho Chehab
Em Tue, 3 Jul 2018 21:07:07 +0900
Akihiro TSUKADA  escreveu:

> Hi,
> thanks for the report.
> 
> >  47buf = NULL;
> > 
> > Condition rlen > 0, taking false branch.
> > 
> >  48if (rlen > 0) {
> >  49buf = kmalloc(rlen, GFP_KERNEL);
> >  50if (!buf)
> >  51return -ENOMEM;
> >  52}
> > 
> >  53usleep_range(1000, 2000); /* avoid I2C errors */
> >  54
> >CID 1470241 (#1 of 1): Explicit null dereferenced (FORWARD_NULL).
> > var_deref_model: Passing null pointer buf to usb_control_msg, which
> > dereferences it.
> > 
> >  55ret = usb_control_msg(d->udev, usb_rcvctrlpipe(d->udev, 0),
> > req, type,
> >  56  value, index, buf, rlen, 2000);
> > 
> > 
> > The assignment of buf = NULL means a null buffer is passed down the usb
> > control message stack until it eventually gets dereferenced. This only
> > occurs when rlen <= 0.   I was unsure how to fix this for the case when
> > rlen <= 0, so I am flagging this up as an issue that needs fixing.
> >   
> 
> Since rlen is an u16, null pointer is passed only when rlen == 0,
> so I think it is not a problem,
> but I am OK to add a guard in order to make scan result clean.

There was another patch proposed to fix this issue with does the
right thing when rlen == 0. I rebased it on the top of the current
tree:

https://git.linuxtv.org/media_tree.git/commit/?id=0b666e1c8120c0b17a8a68aaed58e22011f06ab3

That should cover both cases.

Thanks,
Mauro


custom printed logo USB flash drives

2018-07-25 Thread Vanessa

How are you?

I would like to speak with the person in charge of purchasing your branded
promotional products for your company?

We create custom LOGO USB flash drives for our clients throughout the US.
We can print your logo, and load your digital images, videos and files!
If you need marketing, advertising, gifts or incentives, USB flash drives
are the solution!

Here is what we include:
-All Memory Sizes from 64MB up to 128GB!
-Second Side Printing
-Low Minimum Quantities
-Rush Service Available
-Full color Printing

NEW:   We can make a custom shaped USB drive to look like your Logo or
product!
Send us your product image or logo files; we will create a design mock up
for you at no cost!
We are always running a new deals; email to get pricing!

Ask about the “Double Your Memory” upgrade promotion going on right
now!
Pricing is low right now, so let us know what you need and we will get you
a quick quote.

We will beat any competitors pricing, send us your last invoice and we will
beat it!

We always offer great rates for schools and nonprofits as well.
Regards,

Vanessa Kellen
Logo USB Account Manager




Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer

2018-07-25 Thread Matwey V. Kornilov
2018-07-24 23:55 GMT+03:00 Alan Stern :
> On Tue, 24 Jul 2018, Matwey V. Kornilov wrote:
>
>> 2018-07-23 21:57 GMT+03:00 Alan Stern :
>> > On Mon, 23 Jul 2018, Matwey V. Kornilov wrote:
>> >
>> >> I've tried to strategies:
>> >>
>> >> 1) Use dma_unmap and dma_map inside the handler (I suppose this is
>> >> similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP)
>> >
>> > Yes.
>> >
>> >> 2) Use sync_cpu and sync_device inside the handler (and dma_map only
>> >> once at memory allocation)
>> >>
>> >> It is interesting that dma_unmap/dma_map pair leads to the lower
>> >> overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform.
>> >> At armv7l platform using dma_unmap/dma_map  leads to ~50 usec in the
>> >> handler, and sync_cpu/sync_device - ~65 usec.
>> >>
>> >> However, I am not sure is it mandatory to call
>> >> dma_sync_single_for_device for FROM_DEVICE direction?
>> >
>> > According to Documentation/DMA-API-HOWTO.txt, the CPU should not write
>> > to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is
>> > not needed.
>>
>> Well, I measured the following at armv7l. The handler execution time
>> (URB_NO_TRANSFER_DMA_MAP is used for all cases):
>>
>> 1) coherent DMA: ~3000 usec (pwc is not functional)
>> 2) explicit dma_unmap and dma_map in the handler: ~52 usec
>> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~56 usec
>>
>> So, I suppose that unfortunately Tomasz suggestion doesn't work. There
>> is no performance improvement when dma_sync_single is used.
>>
>> At x86_64 the following happens:
>>
>> 1) coherent DMA: ~2 usec
>> 2) explicit dma_unmap and dma_map in the handler: ~3.5 usec
>> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~4 usec
>>
>> So, whats to do next? Personally, I think that DMA streaming API
>> introduces not so great overhead.
>> Does anybody happy with turning to streaming DMA or I'll introduce
>> module-level switch as Ezequiel suggested?
>
> How about using the dma_unmap and dma_map calls in the USB core?  If
> they add the same overhead as putting them in the handler, I think it
> would be acceptable for x86_64.

Sure, that is the simplest way to implement streaming API.

>
> It certainly is odd that the dma_sync_single APIs take longer than
> simply mapping and unmapping.

Well. I am surprised too. Probably, it is related to that only 9560
bytes are used for each URB. It is only three memory pages.

>
> Alan Stern
>



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


[v2 0/2] media: i2c: mt9v111 sensor driver

2018-07-25 Thread Jacopo Mondi
Hello,
   this is a sensor level driver for Aptina MT9V111.

Compared to v1 the biggest difference is that now auto-exposure and
auto-white-balancing are exposed through the v4l2-ctrl framework, and can be
activated/deactivated by the user.

For this reason, while auto-exposure algorithm still controls the frame rate in
low light conditions, the driver now enables it by default and let the user
disable it to more precisely control the framerate.

(Most of the) comments from Sakari and Kieran have been addressed, see changelog
for a more precise list.

Tested VGA, QVGA QQVGA resolutions at 5, 10, 15 and 30 frame per second.

v4l2-compliance fails on some tests, and I've not been able to identify what's
wrong with the driver. Copy of the failures reported here below:

fail: v4l2-test-subdevs.cpp(69): doioctl(node, 
VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, ) != EINVAL
fail: v4l2-test-subdevs.cpp(180): ret && ret != ENOTTY
fail: v4l2-test-subdevs.cpp(248): ret && ret != ENOTTY
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL

I've found no mention of ENOTTY to be reported by enum_frame_interval in the
documentation, but apparently v4l2-compliance checks for that.

v1: https://lkml.org/lkml/2018/6/11/467

Thanks
   j

v1 -> v2:
- Addressed syntax mistakes pointed out by Kieran
- Drop spinlock around address space change
- Extend mutex to cover frame rate and format get/set operations
- Add controls for auto-exposure and auto-white-balancing
- Move MAINTAINERS modifications to bindings patch
- Fix resolution in bindings document
- Drop dependency on OF
- Drop subdev 'open' function in favour of pad operation init_cfg and use a
  default configuration to initialize the sensor
- Turn off power if sensor identification fails

Jacopo Mondi (2):
  dt-bindings: media: i2c: Document MT9V111 bindings
  media: i2c: Add driver for Aptina MT9V111

 .../bindings/media/i2c/aptina,mt9v111.txt  |   46 +
 MAINTAINERS|8 +
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/mt9v111.c| 1299 
 5 files changed, 1365 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
 create mode 100644 drivers/media/i2c/mt9v111.c

--
2.7.4



[v2 1/2] dt-bindings: media: i2c: Document MT9V111 bindings

2018-07-25 Thread Jacopo Mondi
From: Jacopo Mondi 

Add documentation for Aptina MT9V111 image sensor.

Reviewed-by: Rob Herring 
Signed-off-by: Jacopo Mondi 
---
 .../bindings/media/i2c/aptina,mt9v111.txt  | 46 ++
 MAINTAINERS|  8 
 2 files changed, 54 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt 
b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
new file mode 100644
index 000..bd896e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
@@ -0,0 +1,46 @@
+* Aptina MT9V111 CMOS sensor
+
+
+The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
+based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
+
+The sensor has an active pixel array of 640x480 pixels and can output a number
+of image resolution and formats controllable through a simple two-wires
+interface.
+
+Required properties:
+
+
+- compatible: shall be "aptina,mt9v111".
+- clocks: reference to the system clock input provider.
+
+Optional properties:
+
+
+- enable-gpios: output enable signal, pin name "OE#". Active low.
+- standby-gpios: low power state control signal, pin name "STANDBY".
+  Active high.
+- reset-gpios: chip reset signal, pin name "RESET#". Active low.
+
+The device node must contain one 'port' child node with one 'endpoint' child
+sub-node for its digital output video port, in accordance with the video
+interface bindings defined in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+
+ {
+camera@48 {
+compatible = "aptina,mt9v111";
+reg = <0x48>;
+
+clocks = <_clk>;
+
+port {
+mt9v111_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index bbd9b9b..4ab113c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9651,6 +9651,14 @@ F:   
Documentation/devicetree/bindings/media/i2c/mt9v032.txt
 F: drivers/media/i2c/mt9v032.c
 F: include/media/i2c/mt9v032.h

+MT9V111 APTINA CAMERA SENSOR
+M: Jacopo Mondi 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
+F: drivers/media/i2c/mt9v111.c
+
 MULTIFUNCTION DEVICES (MFD)
 M: Lee Jones 
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
--
2.7.4



[v2 2/2] media: i2c: Add driver for Aptina MT9V111

2018-07-25 Thread Jacopo Mondi
From: Jacopo Mondi 

Add V4L2 sensor driver for Aptina MT9V111 CMOS image sensor.

The MT9V111 is a 1/4-Inch CMOS image sensor based on MT9V011 with an
integrated Image Flow Processor.

Reviewed-by: Kieran Bingham 
Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig   |   11 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/mt9v111.c | 1298 +++
 3 files changed, 1310 insertions(+)
 create mode 100644 drivers/media/i2c/mt9v111.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 8669853..b6fea81 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -861,6 +861,17 @@ config VIDEO_MT9V032
  This is a Video4Linux2 sensor-level driver for the Micron
  MT9V032 752x480 CMOS sensor.
 
+config VIDEO_MT9V111
+   tristate "Aptina MT9V111 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   help
+ This is a Video4Linux2 sensor driver for the Aptina/Micron
+ MT9V111 sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mt9v111.
+
 config VIDEO_SR030PC30
tristate "Siliconfile SR030PC30 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 837c428..ba9a1e4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
 obj-$(CONFIG_VIDEO_MT9T112) += mt9t112.o
 obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
 obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
+obj-$(CONFIG_VIDEO_MT9V111) += mt9v111.o
 obj-$(CONFIG_VIDEO_SR030PC30)  += sr030pc30.o
 obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
 obj-$(CONFIG_VIDEO_RJ54N1) += rj54n1cb0c.o
diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c
new file mode 100644
index 000..da8f6ab
--- /dev/null
+++ b/drivers/media/i2c/mt9v111.c
@@ -0,0 +1,1298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * V4L2 sensor driver for Aptina MT9V111 image sensor
+ * Copyright (C) 2018 Jacopo Mondi 
+ *
+ * Based on mt9v032 driver
+ * Copyright (C) 2010, Laurent Pinchart 
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * Based on mt9v011 driver
+ * Copyright (c) 2009 Mauro Carvalho Chehab 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * MT9V111 is a 1/4-Inch CMOS digital image sensor with an integrated
+ * Image Flow Processing (IFP) engine and a sensor core loosely based on
+ * MT9V011.
+ *
+ * The IFP can produce several output image formats from the sensor core
+ * output. This driver currently supports only YUYV format permutations.
+ *
+ * The driver allows manual frame rate control through s_frame_interval subdev
+ * operation or V4L2_CID_V/HBLANK controls, but it is known that the
+ * auto-exposure algorithm might modify the programmed frame rate. While the
+ * driver initially programs the sensor with auto-exposure and
+ * auto-white-balancing enabled, it is possible to disable them and more
+ * precisely control the frame rate.
+ *
+ * While it seems possible to instruct the auto-exposure control algorithm to
+ * respect a programmed frame rate when adjusting the pixel integration time,
+ * registers controlling this feature are not documented in the public
+ * available sensor manual used to develop this driver (09005aef80e90084,
+ * MT9V111_1.fm - Rev. G 1/05 EN).
+ */
+
+#define MT9V111_CHIP_ID_HIGH   0x82
+#define MT9V111_CHIP_ID_LOW0x3a
+
+#define MT9V111_R01_ADDR_SPACE 0x01
+#define MT9V111_R01_IFP0x01
+#define MT9V111_R01_CORE   0x04
+
+#define MT9V111_IFP_R06_OPMODE_CTRL0x06
+#defineMT9V111_IFP_R06_OPMODE_CTRL_AWB_EN  BIT(1)
+#defineMT9V111_IFP_R06_OPMODE_CTRL_AE_EN   BIT(14)
+#define MT9V111_IFP_R07_IFP_RESET  0x07
+#defineMT9V111_IFP_R07_IFP_RESET_MASK  BIT(0)
+#define MT9V111_IFP_R08_OUTFMT_CTRL0x08
+#defineMT9V111_IFP_R08_OUTFMT_CTRL_FLICKER BIT(11)
+#defineMT9V111_IFP_R08_OUTFMT_CTRL_PCLKBIT(5)
+#define MT9V111_IFP_R3A_OUTFMT_CTRL2   0x3a
+#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_CBCR  BIT(0)
+#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_YCBIT(1)
+#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_MASK  GENMASK(2, 0)
+#define MT9V111_IFP_RA5_HPAN   0xa5
+#define MT9V111_IFP_RA6_HZOOM  0xa6
+#define MT9V111_IFP_RA7_HOUT   0xa7
+#define MT9V111_IFP_RA8_VPAN   0xa8
+#define MT9V111_IFP_RA9_VZOOM 

Re: [PATCH 2/2] media: docs-rst: Document memory-to-memory video encoder interface

2018-07-25 Thread Philipp Zabel
On Tue, 2018-07-24 at 23:06 +0900, Tomasz Figa wrote:
> Due to complexity of the video encoding process, the V4L2 drivers of
> stateful encoder hardware require specific sequences of V4L2 API calls
> to be followed. These include capability enumeration, initialization,
> encoding, encode parameters change, drain and reset.
> 
> Specifics of the above have been discussed during Media Workshops at
> LinuxCon Europe 2012 in Barcelona and then later Embedded Linux
> Conference Europe 2014 in Düsseldorf. The de facto Codec API that
> originated at those events was later implemented by the drivers we already
> have merged in mainline, such as s5p-mfc or coda.
> 
> The only thing missing was the real specification included as a part of
> Linux Media documentation. Fix it now and document the encoder part of
> the Codec API.
> 
> Signed-off-by: Tomasz Figa 

Thanks a lot for the update, 
> ---
>  Documentation/media/uapi/v4l/dev-encoder.rst | 550 +++
>  Documentation/media/uapi/v4l/devices.rst |   1 +
>  Documentation/media/uapi/v4l/v4l2.rst|   2 +
>  3 files changed, 553 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/dev-encoder.rst
> 
> diff --git a/Documentation/media/uapi/v4l/dev-encoder.rst 
> b/Documentation/media/uapi/v4l/dev-encoder.rst
> new file mode 100644
> index ..28be1698e99c
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/dev-encoder.rst
> @@ -0,0 +1,550 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _encoder:
> +
> +
> +Memory-to-memory Video Encoder Interface
> +
> +
> +Input data to a video encoder are raw video frames in display order
> +to be encoded into the output bitstream. Output data are complete chunks of
> +valid bitstream, including all metadata, headers, etc. The resulting stream
> +must not need any further post-processing by the client.
> +
> +Performing software stream processing, header generation etc. in the driver
> +in order to support this interface is strongly discouraged. In case such
> +operations are needed, use of Stateless Video Encoder Interface (in
> +development) is strongly advised.
> +
[...]
> +
> +Commit points
> +=
> +
> +Setting formats and allocating buffers triggers changes in the behavior
> +of the driver.
> +
> +1. Setting format on ``CAPTURE`` queue may change the set of formats
> +   supported/advertised on the ``OUTPUT`` queue. In particular, it also
> +   means that ``OUTPUT`` format may be reset and the client must not
> +   rely on the previously set format being preserved.

Since the only property of the CAPTURE format that can be set directly
via S_FMT is the pixelformat, should this be made explicit?

1. Setting pixelformat on ``CAPTURE`` queue may change the set of
   formats supported/advertised on the ``OUTPUT`` queue. In particular,
   it also means that ``OUTPUT`` format may be reset and the client
   must not rely on the previously set format being preserved.

?

> +2. Enumerating formats on ``OUTPUT`` queue must only return formats
> +   supported for the ``CAPTURE`` format currently set.

Same here, as it usually is the codec selected by CAPTURE pixelformat
that determines the supported OUTPUT pixelformats and resolutions.

2. Enumerating formats on ``OUTPUT`` queue must only return formats
   supported for the ``CAPTURE`` pixelformat currently set.

This could prevent the possible misconception that the CAPTURE
width/height might in any form limit the OUTPUT format, when in fact it
is determined by it.

> +3. Setting/changing format on ``OUTPUT`` queue does not change formats
> +   available on ``CAPTURE`` queue.

3. Setting/changing format on the ``OUTPUT`` queue does not change
   pixelformats available on the ``CAPTURE`` queue.

?

Because setting OUTPUT width/height or CROP SELECTION very much limits
the possible values of CAPTURE width/height.

Maybe 'available' in this context should be specified somewhere to mean
'returned by ENUM_FMT and allowed by S_FMT/TRY_FMT'.

> +   An attempt to set ``OUTPUT`` format that
> +   is not supported for the currently selected ``CAPTURE`` format must
> +   result in the driver adjusting the requested format to an acceptable
> +   one.

   An attempt to set ``OUTPUT`` format that is not supported for the
  
currently selected ``CAPTURE`` pixelformat must result in the driver
  
adjusting the requested format to an acceptable one.

> +4. Enumerating formats on ``CAPTURE`` queue always returns the full set of
> +   supported coded formats, irrespective of the current ``OUTPUT``
> +   format.
> +
> +5. After allocating buffers on the ``CAPTURE`` queue, it is not possible to
> +   change format on it.
> +
> +To summarize, setting formats and allocation must always start with the
> +``CAPTURE`` queue and the ``CAPTURE`` queue is the master that governs the
> +set of supported formats for the ``OUTPUT`` queue.

To summarize, setting formats and 

Re: [PATCH 0/2] Document memory-to-memory video codec interfaces

2018-07-25 Thread Tomasz Figa
Hi Philipp,

On Wed, Jul 25, 2018 at 10:28 PM Philipp Zabel  wrote:
>
> Hi Tomasz,
>
> On Tue, 2018-07-24 at 23:06 +0900, Tomasz Figa wrote:
> > This series attempts to add the documentation of what was discussed
> > during Media Workshops at LinuxCon Europe 2012 in Barcelona and then
> > later Embedded Linux Conference Europe 2014 in Düsseldorf and then
> > eventually written down by Pawel Osciak and tweaked a bit by Chrome OS
> > video team (but mostly in a cosmetic way or making the document more
> > precise), during the several years of Chrome OS using the APIs in
> > production.
> >
> > Note that most, if not all, of the API is already implemented in
> > existing mainline drivers, such as s5p-mfc or mtk-vcodec. Intention of
> > this series is just to formalize what we already have.
> >
> > It is an initial conversion from Google Docs to RST, so formatting is
> > likely to need some further polishing. It is also the first time for me
> > to create such long RST documention. I could not find any other instance
> > of similar userspace sequence specifications among our Media documents,
> > so I mostly followed what was there in the source. Feel free to suggest
> > a better format.
> >
> > Much of credits should go to Pawel Osciak, for writing most of the
> > original text of the initial RFC.
> >
> > Changes since RFC:
> > (https://lore.kernel.org/patchwork/project/lkml/list/?series=348588)
> >  - The number of changes is too big to list them all here. Thanks to
> >a huge number of very useful comments from everyone (Philipp, Hans,
> >Nicolas, Dave, Stanimir, Alexandre) we should have the interfaces much
> >more specified now. The issues collected since previous revisions and
> >answers leading to this revision are listed below.
>
> Thanks a lot for the update, and especially for the nice Q summary of
> the discussions so far.
>
> [...]
> > Decoder issues
> >
> [...]
> >   How should ENUM_FRAMESIZES be affected by profiles and levels?
> >
> >   Answer: Not in current specification - the logic is too complicated and
> >   it might make more sense to actually handle this in user space.  (In
> >   theory, level implies supported frame sizes + other factors.)
>
> For decoding I think it makes more sense to let the hardware decode them
> from the stream and present them as read-only controls, such as:
>
> 42a68012e67c ("media: coda: add read-only h.264 decoder profile/level
> controls")

To clarify, this point is only about the effect on ENUM_FRAMESIZES.
Profile and level controls are mentioned in capabilities enumeration,
but it may make sense to add optional steps of querying them in
Initialization sequence.

>
> if possible. For encoding, the coda firmware determines level from
> bitrate and coded resolution, itself, so I agree not making this part of
> the spec is a good idea for now.

Encoder controls are driver-specific in general, since the encoding
capabilities vary a lot, so I decided to just briefly mention the
general idea of encoding parameters in "Encoding parameter changes"
section. It could be a good idea to add a reference to the MPEG
control documentation there, though.

Best regards,
Tomasz


Re: [PATCH 0/2] Document memory-to-memory video codec interfaces

2018-07-25 Thread Philipp Zabel
Hi Tomasz,

On Tue, 2018-07-24 at 23:06 +0900, Tomasz Figa wrote:
> This series attempts to add the documentation of what was discussed
> during Media Workshops at LinuxCon Europe 2012 in Barcelona and then
> later Embedded Linux Conference Europe 2014 in Düsseldorf and then
> eventually written down by Pawel Osciak and tweaked a bit by Chrome OS
> video team (but mostly in a cosmetic way or making the document more
> precise), during the several years of Chrome OS using the APIs in
> production.
> 
> Note that most, if not all, of the API is already implemented in
> existing mainline drivers, such as s5p-mfc or mtk-vcodec. Intention of
> this series is just to formalize what we already have.
>
> It is an initial conversion from Google Docs to RST, so formatting is
> likely to need some further polishing. It is also the first time for me
> to create such long RST documention. I could not find any other instance
> of similar userspace sequence specifications among our Media documents,
> so I mostly followed what was there in the source. Feel free to suggest
> a better format.
> 
> Much of credits should go to Pawel Osciak, for writing most of the
> original text of the initial RFC.
> 
> Changes since RFC:
> (https://lore.kernel.org/patchwork/project/lkml/list/?series=348588)
>  - The number of changes is too big to list them all here. Thanks to
>a huge number of very useful comments from everyone (Philipp, Hans,
>Nicolas, Dave, Stanimir, Alexandre) we should have the interfaces much
>more specified now. The issues collected since previous revisions and
>answers leading to this revision are listed below.

Thanks a lot for the update, and especially for the nice Q summary of
the discussions so far.

[...]
> Decoder issues
> 
[...]
>   How should ENUM_FRAMESIZES be affected by profiles and levels?
> 
>   Answer: Not in current specification - the logic is too complicated and
>   it might make more sense to actually handle this in user space.  (In
>   theory, level implies supported frame sizes + other factors.)

For decoding I think it makes more sense to let the hardware decode them
from the stream and present them as read-only controls, such as:

42a68012e67c ("media: coda: add read-only h.264 decoder profile/level
controls")

if possible. For encoding, the coda firmware determines level from
bitrate and coded resolution, itself, so I agree not making this part of
the spec is a good idea for now.

regards
Philipp


[PATCH for v4.19] media-types.rst: codec entities can have more than one source pad

2018-07-25 Thread Hans Verkuil
Some decoders and encoders can potentially have more than one source pad,
so update the description to say 'at least one source pad'.

Signed-off-by: Hans Verkuil 
---
diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index 7b17acc049cf..0e9adc7869b8 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -192,12 +192,13 @@ Types and flags used to represent the media graph elements

 *  -  ``MEDIA_ENT_F_PROC_VIDEO_ENCODER``
-  Video (MPEG, HEVC, VPx, etc.) encoder. An entity capable of
-  compressing video frames. Must have one sink pad and one source pad.
+  compressing video frames. Must have one sink pad and at least
+ one source pad.

 *  -  ``MEDIA_ENT_F_PROC_VIDEO_DECODER``
-  Video (MPEG, HEVC, VPx, etc.) decoder. An entity capable of
   decompressing a compressed video stream into uncompressed video
- frames. Must have one sink pad and one source pad.
+ frames. Must have one sink pad and at least one source pad.

 *  -  ``MEDIA_ENT_F_VID_MUX``
- Video multiplexer. An entity capable of multiplexing must have at


Re: [PATCH] media.h: remove linux/version.h include

2018-07-25 Thread Sakari Ailus
On Wed, Jul 25, 2018 at 02:51:39PM +0200, Hans Verkuil wrote:
> The media.h public header is one of only three public headers that include
> linux/version.h. Drop it from media.h. It was only used for an obsolete
> define.
> 
> It has to be added to media-device.c, since that source relied on media.h
> to include it.
> 
> Signed-off-by: Hans Verkuil 

Acked-by: Sakari Ailus 

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


Re: [PATCH v3 35/35] media: v4l2-ioctl: Add format descriptions for packed Bayer raw14 pixel formats

2018-07-25 Thread Todor Tomov
Hi Sakari,

Thanks for review.

On 24.07.2018 15:52, Sakari Ailus wrote:
> Hi Todor,
> 
> On Mon, Jul 23, 2018 at 02:02:52PM +0300, Todor Tomov wrote:
>> This removes warning "Unknown pixelformat" for the following formats:
>> V4L2_PIX_FMT_SBGGR14P
>> V4L2_PIX_FMT_SGBRG14P
>> V4L2_PIX_FMT_SGRBG14P
>> V4L2_PIX_FMT_SRGGB14P
>>
>> CC: Sakari Ailus 
>> Signed-off-by: Todor Tomov 
>> ---
>>  drivers/media/v4l2-core/v4l2-ioctl.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index 2e3b1f0..e8f7c89 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -1260,6 +1260,10 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>>  case V4L2_PIX_FMT_SGBRG12P: descr = "12-bit Bayer GBGB/RGRG 
>> Packed"; break;
>>  case V4L2_PIX_FMT_SGRBG12P: descr = "12-bit Bayer GRGR/BGBG 
>> Packed"; break;
>>  case V4L2_PIX_FMT_SRGGB12P: descr = "12-bit Bayer RGRG/GBGB 
>> Packed"; break;
>> +case V4L2_PIX_FMT_SBGGR14P: descr = "14-bit Bayer BGBG/GRGR 
>> Packed"; break;
>> +case V4L2_PIX_FMT_SGBRG14P: descr = "14-bit Bayer GBGB/RGRG 
>> Packed"; break;
>> +case V4L2_PIX_FMT_SGRBG14P: descr = "14-bit Bayer GRGR/BGBG 
>> Packed"; break;
>> +case V4L2_PIX_FMT_SRGGB14P: descr = "14-bit Bayer RGRG/GBGB 
>> Packed"; break;
>>  case V4L2_PIX_FMT_SBGGR16:  descr = "16-bit Bayer BGBG/GRGR"; break;
>>  case V4L2_PIX_FMT_SGBRG16:  descr = "16-bit Bayer GBGB/RGRG"; break;
>>  case V4L2_PIX_FMT_SGRBG16:  descr = "16-bit Bayer GRGR/BGBG"; break;
> 
> You could merge this to the patch that adds the format definitions. Or:

Yes. I think we are going to have v4 so I will merge it with the patch which 
adds
the format definitions.

> 
> Acked-by: Sakari Ailus 
> 
> And preferrably move it to earlier in the patchset where new formats are
> added.
> 

-- 
Best regards,
Todor Tomov


Re: [PATCH v3 17/35] media: camss: Add 8x96 resources

2018-07-25 Thread Todor Tomov
On 24.07.2018 15:21, Sakari Ailus wrote:
> Hi Todor,
> 
> On Mon, Jul 23, 2018 at 02:02:34PM +0300, Todor Tomov wrote:
> ...
>> @@ -61,7 +59,8 @@ struct ispif_device {
>>  struct mutex power_lock;
>>  struct ispif_intf_cmd_reg intf_cmd[MSM_ISPIF_VFE_NUM];
>>  struct mutex config_lock;
>> -struct ispif_line line[MSM_ISPIF_LINE_NUM];
>> +int line_num;
> 
> unsigned int?

Yes, thanks :)

> 
> I guess if there are only such changes then a patch on top of the current
> set might be more practical than a new version of the entire set.
> 

-- 
Best regards,
Todor Tomov


[PATCH] media.h: remove linux/version.h include

2018-07-25 Thread Hans Verkuil
The media.h public header is one of only three public headers that include
linux/version.h. Drop it from media.h. It was only used for an obsolete
define.

It has to be added to media-device.c, since that source relied on media.h
to include it.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 14959b19a342..fcdf3d5dc4b6 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 82ec9f132a53..36f76e777ef9 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -25,7 +25,6 @@
 #endif
 #include 
 #include 
-#include 

 struct media_device_info {
char driver[16];
@@ -421,7 +420,7 @@ struct media_v2_topology {
 #define MEDIA_INTF_T_ALSA_TIMER(MEDIA_INTF_T_ALSA_BASE 
+ 7)

 /* Obsolete symbol for media_version, no longer used in the kernel */
-#define MEDIA_API_VERSION  KERNEL_VERSION(0, 1, 0)
+#define MEDIA_API_VERSION  ((0 << 16) | (1 << 8) | 0)

 #endif



[GIT PULL for 4.19] ov2680 driver and dw9807 driver rename

2018-07-25 Thread Sakari Ailus
Hi Mauro,

Here's a driver for the ov2680 sensor and a patch that renamed dw0807 as
dw9807-vcm for it's a driver for the VCM bit only. Rename it now to avoid
Kconfig option fuss for most people.

Please pull.


The following changes since commit 8601494e0ec0a7697230b2abca25d786b793341b:

  media: media-ioc-enum-entities.rst/-g-topology.rst: clarify ID/name usage 
(2018-07-25 08:05:06 -0400)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git for-4.19-4

for you to fetch changes up to 070438e314c5f7f8bbb6d7af9bfc4cf20f33a275:

  dw9807-vcm: Recognise this is just the VCM bit of the device (2018-07-25 
15:45:08 +0300)


Rui Miguel Silva (2):
  media: ov2680: dt: Add bindings for OV2680
  media: ov2680: Add Omnivision OV2680 sensor driver

Sakari Ailus (1):
  dw9807-vcm: Recognise this is just the VCM bit of the device

 .../devicetree/bindings/media/i2c/ov2680.txt   |   46 +
 drivers/media/i2c/Kconfig  |   14 +-
 drivers/media/i2c/Makefile |3 +-
 drivers/media/i2c/{dw9807.c => dw9807-vcm.c}   |0
 drivers/media/i2c/ov2680.c | 1186 
 5 files changed, 1247 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2680.txt
 rename drivers/media/i2c/{dw9807.c => dw9807-vcm.c} (100%)
 create mode 100644 drivers/media/i2c/ov2680.c

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


Re: [PATCH v3 18/35] media: camss: Add basic runtime PM support

2018-07-25 Thread Sakari Ailus
Hi Todor,

On Wed, Jul 25, 2018 at 01:01:31PM +0300, Todor Tomov wrote:
> Hi Sakari,
> 
> Thank you for review.
> 
> On 24.07.2018 15:49, Sakari Ailus wrote:
> > Hi Todor,
> > 
> > On Mon, Jul 23, 2018 at 02:02:35PM +0300, Todor Tomov wrote:
> >> There is a PM domain for each of the VFE hardware modules. Add
> >> support for basic runtime PM support to be able to control the
> >> PM domains. When a PM domain needs to be powered on - a device
> >> link is created. When a PM domain needs to be powered off -
> >> its device link is removed. This allows separate and
> >> independent control of the PM domains.
> >>
> >> Suspend/Resume is still not supported.
> >>
> >> Signed-off-by: Todor Tomov 
> >> ---
> >>  drivers/media/platform/qcom/camss/camss-csid.c   |  4 ++
> >>  drivers/media/platform/qcom/camss/camss-csiphy.c |  5 ++
> >>  drivers/media/platform/qcom/camss/camss-ispif.c  | 19 ++-
> >>  drivers/media/platform/qcom/camss/camss-vfe.c| 13 +
> >>  drivers/media/platform/qcom/camss/camss.c| 63 
> >> 
> >>  drivers/media/platform/qcom/camss/camss.h| 11 +
> >>  6 files changed, 113 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
> >> b/drivers/media/platform/qcom/camss/camss-csid.c
> >> index 627ef44..ea2b0ba 100644
> >> --- a/drivers/media/platform/qcom/camss/camss-csid.c
> >> +++ b/drivers/media/platform/qcom/camss/camss-csid.c
> >> @@ -13,6 +13,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -316,6 +317,8 @@ static int csid_set_power(struct v4l2_subdev *sd, int 
> >> on)
> >>if (on) {
> >>u32 hw_version;
> >>  
> >> +  pm_runtime_get_sync(dev);
> >> +
> >>ret = regulator_enable(csid->vdda);
> > 
> > Shouldn't the regulator be enabled in the runtime_resume callback instead?
> 
> Ideally - yes, but it becomes more complex (different pipelines are possible
> and we have only one callback) so (at least for now) I have left it as it is
> and stated in the commit message that suspend/resume is still not supported.

Ack.

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


Re: [PATCH 1/2] media: docs-rst: Document memory-to-memory video decoder interface

2018-07-25 Thread Hans Verkuil
Hi Tomasz,

Many, many thanks for working on this! It's a great document and when done
it will be very useful indeed.

Review comments follow...

On 24/07/18 16:06, Tomasz Figa wrote:
> Due to complexity of the video decoding process, the V4L2 drivers of
> stateful decoder hardware require specific sequences of V4L2 API calls
> to be followed. These include capability enumeration, initialization,
> decoding, seek, pause, dynamic resolution change, drain and end of
> stream.
> 
> Specifics of the above have been discussed during Media Workshops at
> LinuxCon Europe 2012 in Barcelona and then later Embedded Linux
> Conference Europe 2014 in Düsseldorf. The de facto Codec API that
> originated at those events was later implemented by the drivers we already
> have merged in mainline, such as s5p-mfc or coda.
> 
> The only thing missing was the real specification included as a part of
> Linux Media documentation. Fix it now and document the decoder part of
> the Codec API.
> 
> Signed-off-by: Tomasz Figa 
> ---
>  Documentation/media/uapi/v4l/dev-decoder.rst | 872 +++
>  Documentation/media/uapi/v4l/devices.rst |   1 +
>  Documentation/media/uapi/v4l/v4l2.rst|  10 +-
>  3 files changed, 882 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/media/uapi/v4l/dev-decoder.rst
> 
> diff --git a/Documentation/media/uapi/v4l/dev-decoder.rst 
> b/Documentation/media/uapi/v4l/dev-decoder.rst
> new file mode 100644
> index ..f55d34d2f860
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/dev-decoder.rst
> @@ -0,0 +1,872 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _decoder:
> +
> +
> +Memory-to-memory Video Decoder Interface
> +
> +
> +Input data to a video decoder are buffers containing unprocessed video
> +stream (e.g. Annex-B H.264/HEVC stream, raw VP8/9 stream). The driver is
> +expected not to require any additional information from the client to
> +process these buffers. Output data are raw video frames returned in display
> +order.
> +
> +Performing software parsing, processing etc. of the stream in the driver
> +in order to support this interface is strongly discouraged. In case such
> +operations are needed, use of Stateless Video Decoder Interface (in
> +development) is strongly advised.
> +
> +Conventions and notation used in this document
> +==
> +
> +1. The general V4L2 API rules apply if not specified in this document
> +   otherwise.
> +
> +2. The meaning of words “must”, “may”, “should”, etc. is as per RFC
> +   2119.
> +
> +3. All steps not marked “optional” are required.
> +
> +4. :c:func:`VIDIOC_G_EXT_CTRLS`, :c:func:`VIDIOC_S_EXT_CTRLS` may be used
> +   interchangeably with :c:func:`VIDIOC_G_CTRL`, :c:func:`VIDIOC_S_CTRL`,
> +   unless specified otherwise.
> +
> +5. Single-plane API (see spec) and applicable structures may be used
> +   interchangeably with Multi-plane API, unless specified otherwise,
> +   depending on driver capabilities and following the general V4L2
> +   guidelines.
> +
> +6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
> +   [0..2]: i = 0, 1, 2.
> +
> +7. For ``OUTPUT`` buffer A, A’ represents a buffer on the ``CAPTURE`` queue
> +   containing data (decoded frame/stream) that resulted from processing
> +   buffer A.
> +
> +Glossary
> +
> +
> +CAPTURE
> +   the destination buffer queue; the queue of buffers containing decoded
> +   frames; ``V4L2_BUF_TYPE_VIDEO_CAPTURE or
> +   ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``; data are captured from the
> +   hardware into ``CAPTURE`` buffers
> +
> +client
> +   application client communicating with the driver implementing this API
> +
> +coded format
> +   encoded/compressed video bitstream format (e.g. H.264, VP8, etc.); see
> +   also: raw format
> +
> +coded height
> +   height for given coded resolution
> +
> +coded resolution
> +   stream resolution in pixels aligned to codec and hardware requirements;
> +   typically visible resolution rounded up to full macroblocks;
> +   see also: visible resolution
> +
> +coded width
> +   width for given coded resolution
> +
> +decode order
> +   the order in which frames are decoded; may differ from display order if
> +   coded format includes a feature of frame reordering; ``OUTPUT`` buffers
> +   must be queued by the client in decode order
> +
> +destination
> +   data resulting from the decode process; ``CAPTURE``
> +
> +display order
> +   the order in which frames must be displayed; ``CAPTURE`` buffers must be
> +   returned by the driver in display order
> +
> +DPB
> +   Decoded Picture Buffer; a H.264 term for a buffer that stores a picture

a H.264 -> an H.264

> +   that is encoded or decoded and available for reference in further
> +   decode/encode steps.
> +
> +EOS
> +   end of stream
> +
> +IDR
> +   a type of a keyframe in H.264-encoded stream, which clears the 

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

2018-07-25 Thread Sakari Ailus
Hi Yong,

On Wed, Jul 25, 2018 at 06:42:24PM +0800, Yong wrote:
> Hi Sakari,
> 
> On Wed, 18 Jul 2018 12:55:14 +0300
> Sakari Ailus  wrote:
> 
> > Hi Yong,
> > 
> > On Thu, Jul 05, 2018 at 03:48:02PM +0800, Yong wrote:
> > > > > +
> > > > > +/* 
> > > > > -
> > > > > + * Media Operations
> > > > > + */
> > > > > +static int sun6i_video_formats_init(struct sun6i_video *video,
> > > > > + const struct media_pad *remote)
> > > > > +{
> > > > > + struct v4l2_subdev_mbus_code_enum mbus_code = { 0 };
> > > > > + struct sun6i_csi *csi = video->csi;
> > > > > + struct v4l2_format format;
> > > > > + struct v4l2_subdev *subdev;
> > > > > + u32 pad;
> > > > > + const u32 *pixformats;
> > > > > + int pixformat_count = 0;
> > > > > + u32 subdev_codes[32]; /* subdev format codes, 32 should be 
> > > > > enough */
> > > > > + int codes_count = 0;
> > > > > + int num_fmts = 0;
> > > > > + int i, j;
> > > > > +
> > > > > + pad = remote->index;
> > > > > + subdev = media_entity_to_v4l2_subdev(remote->entity);
> > > > > + if (subdev == NULL)
> > > > > + return -ENXIO;
> > > > > +
> > > > > + /* Get supported pixformats of CSI */
> > > > > + pixformat_count = sun6i_csi_get_supported_pixformats(csi, 
> > > > > );
> > > > > + if (pixformat_count <= 0)
> > > > > + return -ENXIO;
> > > > > +
> > > > > + /* Get subdev formats codes */
> > > > > + mbus_code.pad = pad;
> > > > > + mbus_code.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > > > > + while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL,
> > > > > +  _code)) {
> > > > 
> > > > The formats supported by the external sub-device may depend on 
> > > > horizontal
> > > > and vertical flipping. You shouldn't assume any particular configuration
> > > > here: instead, bridge drivers generally just need to make sure the 
> > > > formats
> > > > match in link validation when streaming is started. At least the CSI-2
> > > > receiver driver and the DMA engine driver (video device) should check 
> > > > the
> > > > configuration is valid. See e.g. the IPU3 driver:
> > > > drivers/media/pci/intel/ipu3/ipu3-cio2.c .
> > > 
> > > Can mbus_code be added dynamically ?
> > > The code here only enum the mbus code and get the possible supported
> > > pairs of pixformat and mbus by SoC. Not try to check if the formats
> > > (width height ...) is valid or not. The formats validation will be 
> > > in link validation when streaming is started as per your advise. 
> > 
> > The formats that can be enumerated from the sensor here are those settable
> > using SUBDEV_S_FMT. The enumeration will change on raw sensors if you use
> > the flipping controls. As the bridge driver implements MC as well as subdev
> > APIs, generally the sensor configuration is out of scope of this driver
> > since it's directly configured from the user space.
> > 
> > Just check that the pipeline is valid before starting streaming in your
> > driver.
> 
> Sorry. I am still confused.
> As the CSI driver does not enum the formats supported by sensor.
> How to get a valid format if I do not want to open the subdev? 

For MC-enabled drivers that expose the pipeline, the user is responsible
for configuring the pipeline.

There are bridge drivers that do not expose the pipeline but that will
exclude the use of e.g. some sensor drivers with those bridge drivers.

> Many applications still only open /dev/video*.

That's true, and this is indeed a known gap:

https://www.spinics.net/lists/linux-media/msg137668.html>

So in other words, there is no solution for that issue right now, but this
is in no way specific to your driver, and it is known that this needs to be
addressed.

-- 
Kind regards,

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


Re: [PATCHv2 1/5] media.h: add encoder/decoder functions for codecs

2018-07-25 Thread Hans Verkuil
On 25/07/18 13:39, Mauro Carvalho Chehab wrote:
> Em Fri, 20 Jul 2018 10:27:32 +0200
> Hans Verkuil  escreveu:
> 
>> From: Hans Verkuil 
>>
>> Add MEDIA_ENT_F_PROC_VIDEO_EN/DECODER to be used for the encoder
>> and decoder entities of codec hardware.
>>
>> Signed-off-by: Hans Verkuil 
>> Acked-by: Sakari Ailus 
>> ---
>>  Documentation/media/uapi/mediactl/media-types.rst | 11 +++
>>  include/uapi/linux/media.h|  2 ++
>>  2 files changed, 13 insertions(+)
>>
>> diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
>> b/Documentation/media/uapi/mediactl/media-types.rst
>> index 96910cf2eaaa..5bb933c42879 100644
>> --- a/Documentation/media/uapi/mediactl/media-types.rst
>> +++ b/Documentation/media/uapi/mediactl/media-types.rst
>> @@ -37,6 +37,8 @@ Types and flags used to represent the media graph elements
>>  .. _MEDIA-ENT-F-PROC-VIDEO-LUT:
>>  .. _MEDIA-ENT-F-PROC-VIDEO-SCALER:
>>  .. _MEDIA-ENT-F-PROC-VIDEO-STATISTICS:
>> +.. _MEDIA-ENT-F-PROC-VIDEO-ENCODER:
>> +.. _MEDIA-ENT-F-PROC-VIDEO-DECODER:
>>  .. _MEDIA-ENT-F-VID-MUX:
>>  .. _MEDIA-ENT-F-VID-IF-BRIDGE:
>>  .. _MEDIA-ENT-F-DTV-DECODER:
>> @@ -188,6 +190,15 @@ Types and flags used to represent the media graph 
>> elements
>>received on its sink pad and outputs the statistics data on
>>its source pad.
>>  
>> +*  -  ``MEDIA_ENT_F_PROC_VIDEO_ENCODER``
>> +   -  Video (MPEG, HEVC, VPx, etc.) encoder. An entity capable of
>> +  compressing video frames must have one sink pad and one source 
>> pad.
> 
> I guess a dot is missing here:
> 
>   compressing video frames. Must have one sink pad and one source pad.
> 
> 
>> +
>> +*  -  ``MEDIA_ENT_F_PROC_VIDEO_DECODER``
>> +   -  Video (MPEG, HEVC, VPx, etc.) decoder. An entity capable of
>> +  decompressing a compressed video stream into uncompressed video
>> +  frames must have one sink pad and one source pad.
> 
> Same here:
> frames. Must have one sink pad and one source pad.
> 
> 
> If you're ok with that, I can fix it when applying the patch.

Yes, I'm OK with that.

Thanks!

Hans

> 
>> +
>>  *  -  ``MEDIA_ENT_F_VID_MUX``
>> - Video multiplexer. An entity capable of multiplexing must have at
>>   least two sink pads and one source pad, and must pass the video
>> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
>> index 86c7dcc9cba3..9004d0c5560c 100644
>> --- a/include/uapi/linux/media.h
>> +++ b/include/uapi/linux/media.h
>> @@ -132,6 +132,8 @@ struct media_device_info {
>>  #define MEDIA_ENT_F_PROC_VIDEO_LUT  (MEDIA_ENT_F_BASE + 0x4004)
>>  #define MEDIA_ENT_F_PROC_VIDEO_SCALER   (MEDIA_ENT_F_BASE + 
>> 0x4005)
>>  #define MEDIA_ENT_F_PROC_VIDEO_STATISTICS   (MEDIA_ENT_F_BASE + 0x4006)
>> +#define MEDIA_ENT_F_PROC_VIDEO_ENCODER  (MEDIA_ENT_F_BASE + 
>> 0x4007)
>> +#define MEDIA_ENT_F_PROC_VIDEO_DECODER  (MEDIA_ENT_F_BASE + 
>> 0x4008)
>>  
>>  /*
>>   * Switch and bridge entity functions
> 
> 
> 
> Thanks,
> Mauro
> 



Re: [PATCHv2 1/5] media.h: add encoder/decoder functions for codecs

2018-07-25 Thread Mauro Carvalho Chehab
Em Fri, 20 Jul 2018 10:27:32 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Add MEDIA_ENT_F_PROC_VIDEO_EN/DECODER to be used for the encoder
> and decoder entities of codec hardware.
> 
> Signed-off-by: Hans Verkuil 
> Acked-by: Sakari Ailus 
> ---
>  Documentation/media/uapi/mediactl/media-types.rst | 11 +++
>  include/uapi/linux/media.h|  2 ++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
> b/Documentation/media/uapi/mediactl/media-types.rst
> index 96910cf2eaaa..5bb933c42879 100644
> --- a/Documentation/media/uapi/mediactl/media-types.rst
> +++ b/Documentation/media/uapi/mediactl/media-types.rst
> @@ -37,6 +37,8 @@ Types and flags used to represent the media graph elements
>  .. _MEDIA-ENT-F-PROC-VIDEO-LUT:
>  .. _MEDIA-ENT-F-PROC-VIDEO-SCALER:
>  .. _MEDIA-ENT-F-PROC-VIDEO-STATISTICS:
> +.. _MEDIA-ENT-F-PROC-VIDEO-ENCODER:
> +.. _MEDIA-ENT-F-PROC-VIDEO-DECODER:
>  .. _MEDIA-ENT-F-VID-MUX:
>  .. _MEDIA-ENT-F-VID-IF-BRIDGE:
>  .. _MEDIA-ENT-F-DTV-DECODER:
> @@ -188,6 +190,15 @@ Types and flags used to represent the media graph 
> elements
> received on its sink pad and outputs the statistics data on
> its source pad.
>  
> +*  -  ``MEDIA_ENT_F_PROC_VIDEO_ENCODER``
> +   -  Video (MPEG, HEVC, VPx, etc.) encoder. An entity capable of
> +  compressing video frames must have one sink pad and one source pad.

I guess a dot is missing here:

  compressing video frames. Must have one sink pad and one source pad.


> +
> +*  -  ``MEDIA_ENT_F_PROC_VIDEO_DECODER``
> +   -  Video (MPEG, HEVC, VPx, etc.) decoder. An entity capable of
> +  decompressing a compressed video stream into uncompressed video
> +   frames must have one sink pad and one source pad.

Same here:
  frames. Must have one sink pad and one source pad.


If you're ok with that, I can fix it when applying the patch.

> +
>  *  -  ``MEDIA_ENT_F_VID_MUX``
> - Video multiplexer. An entity capable of multiplexing must have at
>   least two sink pads and one source pad, and must pass the video
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 86c7dcc9cba3..9004d0c5560c 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -132,6 +132,8 @@ struct media_device_info {
>  #define MEDIA_ENT_F_PROC_VIDEO_LUT   (MEDIA_ENT_F_BASE + 0x4004)
>  #define MEDIA_ENT_F_PROC_VIDEO_SCALER(MEDIA_ENT_F_BASE + 
> 0x4005)
>  #define MEDIA_ENT_F_PROC_VIDEO_STATISTICS(MEDIA_ENT_F_BASE + 0x4006)
> +#define MEDIA_ENT_F_PROC_VIDEO_ENCODER   (MEDIA_ENT_F_BASE + 
> 0x4007)
> +#define MEDIA_ENT_F_PROC_VIDEO_DECODER   (MEDIA_ENT_F_BASE + 
> 0x4008)
>  
>  /*
>   * Switch and bridge entity functions



Thanks,
Mauro


Re: [PATCH v3 1/4] venus: firmware: add routine to reset ARM9

2018-07-25 Thread Stanimir Varbanov
Hi,

On 07/04/2018 10:06 PM, Vikash Garodia wrote:
> Add routine to reset the ARM9 and brings it out of reset. Also
> abstract the Venus CPU state handling with a new function. This
> is in preparation to add PIL functionality in venus driver.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/media/platform/qcom/venus/core.h |  1 +
>  drivers/media/platform/qcom/venus/firmware.c | 36 
> 
>  drivers/media/platform/qcom/venus/firmware.h |  1 +
>  drivers/media/platform/qcom/venus/hfi_venus.c| 13 +++--
>  drivers/media/platform/qcom/venus/hfi_venus_io.h |  5 
>  5 files changed, 47 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/core.h 
> b/drivers/media/platform/qcom/venus/core.h
> index 2f02365..eb5ee66 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -129,6 +129,7 @@ struct venus_core {
>   struct device *dev;
>   struct device *dev_dec;
>   struct device *dev_enc;
> + bool no_tz;
>   struct mutex lock;
>   struct list_head instances;
>   atomic_t insts_count;
> diff --git a/drivers/media/platform/qcom/venus/firmware.c 
> b/drivers/media/platform/qcom/venus/firmware.c
> index 521d4b3..3968553d 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -22,11 +22,47 @@
>  #include 
>  #include 
>  
> +#include "core.h"
>  #include "firmware.h"
> +#include "hfi_venus_io.h"
>  
>  #define VENUS_PAS_ID 9
>  #define VENUS_FW_MEM_SIZE(6 * SZ_1M)
>  
> +static void venus_reset_cpu(struct venus_core *core)
> +{
> + void __iomem *base = core->base;
> +
> + writel(0, base + WRAPPER_FW_START_ADDR);
> + writel(VENUS_FW_MEM_SIZE, base + WRAPPER_FW_END_ADDR);
> + writel(0, base + WRAPPER_CPA_START_ADDR);
> + writel(VENUS_FW_MEM_SIZE, base + WRAPPER_CPA_END_ADDR);
> + writel(0x0, base + WRAPPER_CPU_CGC_DIS);
> + writel(0x0, base + WRAPPER_CPU_CLOCK_CONFIG);
> +
> + /* Make sure all register writes are committed. */
> + mb();
> +
> + /* Bring ARM9 out of reset */
> + writel_relaxed(0, base + WRAPPER_A9SS_SW_RESET);
> +}
> +
> +int venus_set_hw_state(struct venus_core *core, bool resume)
> +{
> + void __iomem *base = core->base;
> +
> + if (!core->no_tz)
> + return qcom_scm_set_remote_state(resume, 0);
> +
> + if (resume)
> + venus_reset_cpu(core);
> + else
> + writel(1, base + WRAPPER_A9SS_SW_RESET);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(venus_set_hw_state);

This export_symbol shouldn't be needed

-- 
regards,
Stan


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

2018-07-25 Thread Yong
Hi Sakari,

On Wed, 18 Jul 2018 12:55:14 +0300
Sakari Ailus  wrote:

> Hi Yong,
> 
> On Thu, Jul 05, 2018 at 03:48:02PM +0800, Yong wrote:
> > > > +
> > > > +/* 
> > > > -
> > > > + * Media Operations
> > > > + */
> > > > +static int sun6i_video_formats_init(struct sun6i_video *video,
> > > > +   const struct media_pad *remote)
> > > > +{
> > > > +   struct v4l2_subdev_mbus_code_enum mbus_code = { 0 };
> > > > +   struct sun6i_csi *csi = video->csi;
> > > > +   struct v4l2_format format;
> > > > +   struct v4l2_subdev *subdev;
> > > > +   u32 pad;
> > > > +   const u32 *pixformats;
> > > > +   int pixformat_count = 0;
> > > > +   u32 subdev_codes[32]; /* subdev format codes, 32 should be 
> > > > enough */
> > > > +   int codes_count = 0;
> > > > +   int num_fmts = 0;
> > > > +   int i, j;
> > > > +
> > > > +   pad = remote->index;
> > > > +   subdev = media_entity_to_v4l2_subdev(remote->entity);
> > > > +   if (subdev == NULL)
> > > > +   return -ENXIO;
> > > > +
> > > > +   /* Get supported pixformats of CSI */
> > > > +   pixformat_count = sun6i_csi_get_supported_pixformats(csi, 
> > > > );
> > > > +   if (pixformat_count <= 0)
> > > > +   return -ENXIO;
> > > > +
> > > > +   /* Get subdev formats codes */
> > > > +   mbus_code.pad = pad;
> > > > +   mbus_code.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > > > +   while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL,
> > > > +_code)) {
> > > 
> > > The formats supported by the external sub-device may depend on horizontal
> > > and vertical flipping. You shouldn't assume any particular configuration
> > > here: instead, bridge drivers generally just need to make sure the formats
> > > match in link validation when streaming is started. At least the CSI-2
> > > receiver driver and the DMA engine driver (video device) should check the
> > > configuration is valid. See e.g. the IPU3 driver:
> > > drivers/media/pci/intel/ipu3/ipu3-cio2.c .
> > 
> > Can mbus_code be added dynamically ?
> > The code here only enum the mbus code and get the possible supported
> > pairs of pixformat and mbus by SoC. Not try to check if the formats
> > (width height ...) is valid or not. The formats validation will be 
> > in link validation when streaming is started as per your advise. 
> 
> The formats that can be enumerated from the sensor here are those settable
> using SUBDEV_S_FMT. The enumeration will change on raw sensors if you use
> the flipping controls. As the bridge driver implements MC as well as subdev
> APIs, generally the sensor configuration is out of scope of this driver
> since it's directly configured from the user space.
> 
> Just check that the pipeline is valid before starting streaming in your
> driver.

Sorry. I am still confused.
As the CSI driver does not enum the formats supported by sensor.
How to get a valid format if I do not want to open the subdev? 
Many applications still only open /dev/video*.

> 
> -- 
> Kind regards,
> 
> Sakari Ailus
> sakari.ai...@linux.intel.com


Thanks,
Yong


[PATCH v6 8/8] ARM: dts: sun8i-h3: Add Video Engine and reserved memory nodes

2018-07-25 Thread Paul Kocialkowski
This adds nodes for the Video Engine and the associated reserved memory
for the H3. Up to 96 MiB of memory are dedicated to the CMA pool.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index c93f6be40533..c1375e72bb12 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -110,6 +110,20 @@
 ;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   cma_pool: cma@4a00 {
+   compatible = "shared-dma-pool";
+   size = <0x600>;
+   alloc-ranges = <0x4a00 0x600>;
+   reusable;
+   linux,cma-default;
+   };
+   };
+
soc {
system-control@1c0 {
compatible = "allwinner,sun8i-h3-system-control",
@@ -134,6 +148,17 @@
};
};
 
+   video-codec@01c0e000 {
+   compatible = "allwinner,sun8i-h3-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   clocks = < CLK_BUS_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_BUS_VE>;
+   interrupts = ;
+   allwinner,sram = <_sram 1>;
+   };
+
mali: gpu@1c4 {
compatible = "allwinner,sun8i-h3-mali", "arm,mali-400";
reg = <0x01c4 0x1>;
-- 
2.18.0



[PATCH v6 7/8] ARM: dts: sun8i-a33: Add Video Engine and reserved memory nodes

2018-07-25 Thread Paul Kocialkowski
This adds nodes for the Video Engine and the associated reserved memory
for the A33. Up to 96 MiB of memory are dedicated to the CMA pool.

The VPU can only map the first 256 MiB of DRAM, so the reserved memory
pool has to be located in that area. Following Allwinner's decision in
downstream software, the last 96 MiB of the first 256 MiB of RAM are
reserved for this purpose.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 8d278ee001e9..a212fbee14bc 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -181,6 +181,21 @@
reg = <0x4000 0x8000>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   cma_pool: cma@4a00 {
+   compatible = "shared-dma-pool";
+   size = <0x600>;
+   alloc-ranges = <0x4a00 0x600>;
+   reusable;
+   linux,cma-default;
+   };
+   };
+
sound: sound {
compatible = "simple-audio-card";
simple-audio-card,name = "sun8i-a33-audio";
@@ -245,6 +260,17 @@
};
};
 
+   video-codec@01c0e000 {
+   compatible = "allwinner,sun8i-a33-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   clocks = < CLK_BUS_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_BUS_VE>;
+   interrupts = ;
+   allwinner,sram = <_sram 1>;
+   };
+
crypto: crypto-engine@1c15000 {
compatible = "allwinner,sun4i-a10-crypto";
reg = <0x01c15000 0x1000>;
-- 
2.18.0



[PATCH v6 3/8] dt-bindings: media: Document bindings for the Cedrus VPU driver

2018-07-25 Thread Paul Kocialkowski
This adds a device-tree binding document that specifies the properties
used by the Cedurs VPU driver, as well as examples.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/media/cedrus.txt  | 54 +++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cedrus.txt

diff --git a/Documentation/devicetree/bindings/media/cedrus.txt 
b/Documentation/devicetree/bindings/media/cedrus.txt
new file mode 100644
index ..a089a0c1ff05
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cedrus.txt
@@ -0,0 +1,54 @@
+Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
+Video Engine (VE) in Allwinner literature.
+
+The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped starting
+from the DRAM base. This requires specific memory allocation and handling.
+
+Required properties:
+- compatible   : must be one of the following compatibles:
+   - "allwinner,sun4i-a10-video-engine"
+   - "allwinner,sun5i-a13-video-engine"
+   - "allwinner,sun7i-a20-video-engine"
+   - "allwinner,sun8i-a33-video-engine"
+   - "allwinner,sun8i-h3-video-engine"
+- reg  : register base and length of VE;
+- clocks   : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names  : should contain "ahb", "mod" and "ram" entries;
+- resets   : phandle for reset;
+- interrupts   : VE interrupt number;
+- allwinner,sram   : SRAM region to use with the VE.
+
+Optional properties:
+- memory-region: CMA pool to use for buffers allocation 
instead of the
+ default CMA pool.
+
+Example:
+
+reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   cma_pool: cma@4a00 {
+   compatible = "shared-dma-pool";
+   size = <0x600>;
+   alloc-ranges = <0x4a00 0x600>;
+   reusable;
+   linux,cma-default;
+   };
+};
+
+video-codec@1c0e000 {
+   compatible = "allwinner,sun7i-a20-video-engine";
+   reg = <0x01c0e000 0x1000>;
+
+   clocks = < CLK_AHB_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+
+   resets = < RST_VE>;
+   interrupts = ;
+   allwinner,sram = <_sram 1>;
+};
-- 
2.18.0



[PATCH v6 6/8] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

2018-07-25 Thread Paul Kocialkowski
This adds nodes for the Video Engine and the associated reserved memory
for the A20. Up to 96 MiB of memory are dedicated to the CMA pool.

The VPU can only map the first 256 MiB of DRAM, so the reserved memory
pool has to be located in that area. Following Allwinner's decision in
downstream software, the last 96 MiB of the first 256 MiB of RAM are
reserved for this purpose.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 38999d791cb5..55517b068009 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -161,6 +161,21 @@
reg = <0x4000 0x8000>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   cma_pool: cma@4a00 {
+   compatible = "shared-dma-pool";
+   size = <0x600>;
+   alloc-ranges = <0x4a00 0x600>;
+   reusable;
+   linux,cma-default;
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -466,6 +481,17 @@
};
};
 
+   video-codec@1c0e000 {
+   compatible = "allwinner,sun7i-a20-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   clocks = < CLK_AHB_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_VE>;
+   interrupts = ;
+   allwinner,sram = <_sram 1>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.18.0



[PATCH v6 1/8] media: v4l: Add definitions for MPEG2 slice format and metadata

2018-07-25 Thread Paul Kocialkowski
Stateless video decoding engines require both the MPEG slices and
associated metadata from the video stream in order to decode frames.

This introduces definitions for a new pixel format, describing buffers
with MPEG2 slice data, as well as a control structure for passing the
frame metadata to drivers.

This is based on work from both Florent Revest and Hugues Fruchet.

Signed-off-by: Paul Kocialkowski 
---
 .../media/uapi/v4l/extended-controls.rst  | 122 ++
 .../media/uapi/v4l/pixfmt-compressed.rst  |   5 +
 drivers/media/v4l2-core/v4l2-ctrls.c  |  54 
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 include/media/v4l2-ctrls.h|  18 ++-
 include/uapi/linux/v4l2-controls.h|  43 ++
 include/uapi/linux/videodev2.h|   5 +
 7 files changed, 241 insertions(+), 7 deletions(-)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 9f7312bf3365..4a29d89fd9ac 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1497,6 +1497,128 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
 
 
 
+.. _v4l2-mpeg-mpeg2:
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (struct)``
+Specifies the slice parameters (also known as slice header) for the
+associated MPEG-2 slice data. This includes all the necessary
+parameters for configuring a hardware decoder pipeline for MPEG-2.
+
+.. tabularcolumns:: |p{2.0cm}|p{4.0cm}|p{11.0cm}|
+
+.. c:type:: v4l2_ctrl_mpeg2_slice_params
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_mpeg2_slice_params
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u32
+  - ``slice_len``
+  - Length (in bits) of the current slice data.
+* - __u32
+  - ``slice_pos``
+  - Position (in bits) of the current slice data, relative to the
+frame start.
+* - __u16
+  - ``width``
+  - Width of the corresponding output frame for the current slice.
+* - __u16
+  - ``height``
+  - Height of the corresponding output frame for the current slice.
+* - __u8
+  - ``slice_type``
+  - Picture coding type for the frame covered by the current slice
+(V4L2_MPEG2_SLICE_TYPE_I, V4L2_MPEG2_SLICE_TYPE_P or
+V4L2_MPEG2_SLICE_PCT_B).
+* - __u8
+  - ``f_code[2][2]``
+  - Motion vector codes.
+* - __u8
+  - ``intra_dc_precision``
+  - Precision of Discrete Cosine transform (0: 8 bits precision,
+1: 9 bits precision, 2: 10 bits precision, 11: 11 bits precision).
+* - __u8
+  - ``picture_structure``
+  - Picture structure (1: interlaced top field,
+2: interlaced bottom field, 3: progressive frame).
+* - __u8
+  - ``top_field_first``
+  - If set to 1 and interlaced stream, top field is output first.
+* - __u8
+  - ``frame_pred_frame_dct``
+  - If set to 1, only frame-DCT and frame prediction are used.
+* - __u8
+  - ``concealment_motion_vectors``
+  -  If set to 1, motion vectors are coded for intra macroblocks.
+* - __u8
+  - ``q_scale_type``
+  - This flag affects the inverse quantisation process.
+* - __u8
+  - ``intra_vlc_format``
+  - This flag affects the decoding of transform coefficient data.
+* - __u8
+  - ``alternate_scan``
+  - This flag affects the decoding of transform coefficient data.
+* - __u8
+  - ``backward_ref_index``
+  - Index for the V4L2 buffer to use as backward reference, used with
+B-coded and P-coded frames.
+* - __u8
+  - ``forward_ref_index``
+  - Index for the V4L2 buffer to use as forward reference, used with
+P-coded frames.
+* - :cspan:`2`
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION (struct)``
+Specifies quantization matrices for the associated MPEG-2 slice data.
+
+.. tabularcolumns:: |p{2.0cm}|p{4.0cm}|p{11.0cm}|
+
+.. c:type:: v4l2_ctrl_mpeg2_quantization
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_mpeg2_quantization
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``load_intra_quantiser_matrix``
+  - One bit to indicate whether to load the intra quantiser matrix.
+* - __u32
+  - ``load_non_intra_quantiser_matrix``
+  - One bit to indicate whether to load the non-intra quantiser matrix.
+* - __u32
+  - ``load_chroma_intra_quantiser_matrix``
+  - One bit to indicate whether to load the chroma intra quantiser matrix,
+only relevant for non-4:2:0 YUV formats.
+* - __u32
+  - ``load_chroma_non_intra_quantiser_matrix``
+  - One bit to indicate whether to load the non-chroma intra quantiser
+matrix, only relevant for non-4:2:0 YUV formats.
+* - __u32
+  - ``intra_quantiser_matrix[64]``
+  - The intra quantiser matrix coefficients, in zigzag 

[PATCH v6 4/8] media: platform: Add Cedrus VPU decoder driver

2018-07-25 Thread Paul Kocialkowski
This introduces the Cedrus VPU driver that supports the VPU found in
Allwinner SoCs, also known as Video Engine. It is implemented through
a v4l2 m2m decoder device and a media device (used for media requests).
So far, it only supports MPEG2 decoding.

Since this VPU is stateless, synchronization with media requests is
required in order to ensure consistency between frame headers that
contain metadata about the frame to process and the raw slice data that
is used to generate the frame.

This driver was made possible thanks to the long-standing effort
carried out by the linux-sunxi community in the interest of reverse
engineering, documenting and implementing support for Allwinner VPU.

Signed-off-by: Paul Kocialkowski 
---
 MAINTAINERS   |   7 +
 drivers/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/sunxi/Kconfig   |  15 +
 drivers/staging/media/sunxi/Makefile  |   1 +
 drivers/staging/media/sunxi/cedrus/Kconfig|  14 +
 drivers/staging/media/sunxi/cedrus/Makefile   |   3 +
 drivers/staging/media/sunxi/cedrus/cedrus.c   | 419 +
 drivers/staging/media/sunxi/cedrus/cedrus.h   | 166 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   | 114 
 .../staging/media/sunxi/cedrus/cedrus_dec.h   |  27 +
 .../staging/media/sunxi/cedrus/cedrus_hw.c| 319 ++
 .../staging/media/sunxi/cedrus/cedrus_hw.h|  29 +
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 240 
 .../staging/media/sunxi/cedrus/cedrus_regs.h  | 235 
 .../staging/media/sunxi/cedrus/cedrus_video.c | 566 ++
 .../staging/media/sunxi/cedrus/cedrus_video.h |  31 +
 17 files changed, 2189 insertions(+)
 create mode 100644 drivers/staging/media/sunxi/Kconfig
 create mode 100644 drivers/staging/media/sunxi/Makefile
 create mode 100644 drivers/staging/media/sunxi/cedrus/Kconfig
 create mode 100644 drivers/staging/media/sunxi/cedrus/Makefile
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus.h
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_dec.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_dec.h
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_hw.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_hw.h
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_regs.h
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_video.c
 create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_video.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 89853313c697..342504506a89 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -656,6 +656,13 @@ L: linux-cry...@vger.kernel.org
 S: Maintained
 F: drivers/crypto/sunxi-ss/
 
+ALLWINNER VPU DRIVER
+M: Maxime Ripard 
+M: Paul Kocialkowski 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/staging/media/sunxi/cedrus/
+
 ALPHA PORT
 M: Richard Henderson 
 M: Ivan Kokshaysky 
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index db5cf67047ad..b3620a8f2d9f 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig"
 
 source "drivers/staging/media/omap4iss/Kconfig"
 
+source "drivers/staging/media/sunxi/Kconfig"
+
 source "drivers/staging/media/tegra-vde/Kconfig"
 
 source "drivers/staging/media/zoran/Kconfig"
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index 503fbe47fa58..42948f805548 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -5,5 +5,6 @@ obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074/
 obj-$(CONFIG_SOC_CAMERA_MT9T031)   += mt9t031/
 obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/
 obj-$(CONFIG_VIDEO_OMAP4)  += omap4iss/
+obj-$(CONFIG_VIDEO_SUNXI)  += sunxi/
 obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
 obj-$(CONFIG_VIDEO_ZORAN)  += zoran/
diff --git a/drivers/staging/media/sunxi/Kconfig 
b/drivers/staging/media/sunxi/Kconfig
new file mode 100644
index ..c78d92240ceb
--- /dev/null
+++ b/drivers/staging/media/sunxi/Kconfig
@@ -0,0 +1,15 @@
+config VIDEO_SUNXI
+   bool "Allwinner sunXi family Video Devices"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   help
+ If you have an Allwinner SoC based on the sunXi family, say Y.
+
+ Note that this option doesn't include new drivers in the
+ kernel: saying N will just cause Kconfig to skip all the
+ questions about Allwinner media devices.
+
+if VIDEO_SUNXI
+
+source "drivers/staging/media/sunxi/cedrus/Kconfig"
+
+endif
diff --git a/drivers/staging/media/sunxi/Makefile 
b/drivers/staging/media/sunxi/Makefile
new file mode 100644
index ..cee2846c3ecf
--- /dev/null
+++ 

[PATCH v6 0/8] Cedrus driver for the Allwinner Video Engine, using media requests

2018-07-25 Thread Paul Kocialkowski
This is the sixth iteration of the updated Cedrus driver,
that supports the Video Engine found in most Allwinner SoCs, starting
with the A10. It was tested on the A13, A20, A33 and H3.

The initial version of this driver[0] was originally written and
submitted by Florent Revest using a previous version of the request API
that is necessary to provide coherency between controls and the buffers
they apply to.

The driver was adapted to use the latest version of the media request
API[1], as submitted by Hand Verkuil. Media request API support is a
hard requirement for the Cedrus driver.

The driver itself currently only supports MPEG2 and more codecs will be
added to the driver eventually. The output frames provided by the
Video Engine are in a multi-planar 32x32-tiled YUV format, with a plane
for luminance (Y) and a plane for chrominance (UV). A specific format is
introduced in the V4L2 API to describe it.

This implementation is based on the significant work that was conducted
by various members of the linux-sunxi community for understanding and
documenting the Video Engine's innards.

In addition to the media requests API, the following series are required
for Cedrus:
* vicodec: the Virtual Codec driver
* allwinner: a64: add SRAM controller / system control
* SRAM patches from the Cedrus VPU driver series version 5

Changes since v5:
* Added MPEG2 quantization matrices definitions and support;
* Cleaned up registers definitions;
* Moved the driver to staging as requested;
* Removed label and newline in device-tree sources;
* Made it possible to build the driver for COMPILE_TEST;
* Fixed various strict checkpatch warnings;
* Used v4l2_m2m_register_media_controller and MEDIA_ENT_F_PROC_VIDEO_DECODER;
* Moved capabilities to compatible-specific variants;
* Removed overkill buffer checks in device_run;
* Renamed from Sunxi-Cedrus to Cedrus.

Changes since v4:
* updated to version 16 of the media requests API;
* added support for VPU-based untiling (starting with the A33);
* added support for the H3, with SRAM support;
* reworked SRAM support and associated compatibles;
* improved failure paths;
* added some MPEG2 input data validation;
* reworked video/format functions to handle multiple formats;
* removed in-driver buffer queues;
* used a threaded irq instead of a workqueue;
* merged various improvements and cleanups from Maxime;
* renamed MPEG2_SLICE_HEADER to MPEG2_SLICE_PARAMS;
* added prefixes to MPEG2 picture coding types;
* used single-buffer allocations to ensure contiguous planes

Changes since v3:
* updated to version 15 of the media request API;
* got rid of untested MPEG1 support;
* added definitons for picture coding types;
* added documentation about MPEG2 slice header fields;
* added documentation about MPEG2 slice format;
* added documentation about the MB32 NV12 format;
* added MPEG2 slice header validation;
* removed the assigned-clocks property;
* reworked and fixed error paths;
* harmonized debug prints, with v4l2 helpers when applicable;
* checked the series through checkpatch;
* switched to SPDX license headers;
* renamed MPEG2 frame header to slice header for consistency and clarity;
* removed A20 SRAM compatible from the driver's list.

Changes since v2:
* updated to version 13 of the media request API;
* integrated various changes from Maxime Ripard;
* reworked memory reservation to use CMA, dynamic allocation and allow
  DMABUF;
* removed reserved memory binding since the CMA pool is the default one
  (and allow ENODEV in the driver, for that use case);
* added SRAM controller support for the SRAM region used by the VE;
* updated the device-tree bindings the for SRAM region;
* added per-platform bindings;
* added A13 support;
* renamed VE node name and label;
* fixed Florent's authorship for the MPEG2 headers;
* added a MAINTAINERS entry.

Changes since v1:
* use the latest version of the request API for Hans Verkuil;
* added media controller support and dependency
* renamed v4l2 format to the more explicit V4L2_PIX_FMT_MB32_NV12;
* reworked bindings documentation;
* moved driver to drivers/media/platforms/sunxi/cedrus to pair with
  incoming CSI support ;
* added a workqueue and lists to schedule buffer completion, since it
  cannot be done in interrupt context;
* split mpeg2 support into a setup and a trigger function to avoid race
  condition;
* split video-related ops to a dedicated sunxi_cedrus_video file;
* cleaned up the included headers for each file;
* used device PFN offset instead of subtracting PHYS_BASE;
* used reset_control_reset instead of assert+deassert;
* put the device in reset when removing driver;
* changed dt bindings to use the last 96 Mib of the first 256 MiB of
  DRAM;
* made it clear in the mpeg frame header structure that forward and
  backward indexes are used as reference frames for motion vectors;
* lots of small cosmetic and consistency changes, including naming
  harmonization and headers text rework.

Cheers!

[0]: 

[PATCH v6 2/8] media: v4l: Add definition for Allwinner's MB32-tiled NV12 format

2018-07-25 Thread Paul Kocialkowski
This introduces support for Allwinner's MB32-tiled NV12 format, where
each plane is divided into macroblocks of 32x32 pixels. Hence, the size
of each plane has to be aligned to 32 bytes. The pixels inside each
macroblock are coded as they would be if the macroblock was a single
plane, line after line.

The MB32-tiled NV12 format is used by the video engine on Allwinner
platforms: it is the default format for decoded frames (and the only one
available in the oldest supported platforms).

Signed-off-by: Paul Kocialkowski 
---
 Documentation/media/uapi/v4l/pixfmt-reserved.rst | 15 ++-
 drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
 include/uapi/linux/videodev2.h   |  1 +
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst 
b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
index 38af1472a4b4..9a68b6a787bf 100644
--- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
@@ -243,7 +243,20 @@ please make a proposal on the linux-media mailing list.
It is an opaque intermediate format and the MDP hardware must be
used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``,
``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``.
-
+* .. _V4L2-PIX-FMT-MB32-NV12:
+
+  - ``V4L2_PIX_FMT_MB32_NV12``
+  - 'MN12'
+  - Two-planar NV12-based format used by the Allwinner video engine
+hardware, with 32x32 tiles for the luminance plane and 32x64 tiles
+for the chrominance plane. Each tile is a linear pixel data
+representation within its own bounds. Each tile follows the previous
+one linearly (as in, from left to right, top to bottom).
+
+The frame dimensions are aligned to match an integer number of
+tiles, resulting in 32-aligned resolutions for the luminance plane
+and 16-aligned resolutions for the chrominance plane (with 2x2
+subsampling).
 
 .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
 
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 68e914b83a03..7e1c200de10d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1331,6 +1331,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_SE401:descr = "GSPCA SE401"; break;
case V4L2_PIX_FMT_S5C_UYVY_JPG: descr = "S5C73MX interleaved 
UYVY/JPEG"; break;
case V4L2_PIX_FMT_MT21C:descr = "Mediatek Compressed 
Format"; break;
+   case V4L2_PIX_FMT_MB32_NV12:descr = "Allwinner tiled NV12 
format"; break;
default:
WARN(1, "Unknown pixelformat 0x%08x\n", 
fmt->pixelformat);
if (fmt->description[0])
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index d171361ed9b3..453d27142e31 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -670,6 +670,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_Z16  v4l2_fourcc('Z', '1', '6', ' ') /* Depth data 
16-bit */
 #define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /* Mediatek 
compressed block mode  */
 #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar 
Greyscale 10-bit and Depth 16-bit */
+#define V4L2_PIX_FMT_MB32_NV12 v4l2_fourcc('M', 'N', '1', '2') /* Allwinner 
tiled NV12 format */
 
 /* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits 
unused */
 #define V4L2_PIX_FMT_IPU3_SBGGR10  v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 
packed 10-bit BGGR bayer */
-- 
2.18.0



[PATCH v6 5/8] ARM: dts: sun5i: Add Video Engine and reserved memory nodes

2018-07-25 Thread Paul Kocialkowski
This adds nodes for the Video Engine and the associated reserved memory
for sun5i-based platforms. Up to 96 MiB of memory are dedicated to the
CMA pool.

The VPU can only map the first 256 MiB of DRAM, so the reserved memory
pool has to be located in that area. Following Allwinner's decision in
downstream software, the last 96 MiB of the first 256 MiB of RAM are
reserved for this purpose.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun5i.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 51dcefc76c12..6a9d6d185ade 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -108,6 +108,21 @@
};
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   cma_pool: cma@4a00 {
+   compatible = "shared-dma-pool";
+   size = <0x600>;
+   alloc-ranges = <0x4a00 0x600>;
+   reusable;
+   linux,cma-default;
+   };
+   };
+
soc@1c0 {
compatible = "simple-bus";
#address-cells = <1>;
@@ -295,6 +310,17 @@
};
};
 
+   video-codec@1c0e000 {
+   compatible = "allwinner,sun5i-a13-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   clocks = < CLK_AHB_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_VE>;
+   interrupts = <53>;
+   allwinner,sram = <_sram 1>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun5i-a13-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.18.0



Re: [PATCH v3 18/35] media: camss: Add basic runtime PM support

2018-07-25 Thread Todor Tomov
Hi Sakari,

Thank you for review.

On 24.07.2018 15:49, Sakari Ailus wrote:
> Hi Todor,
> 
> On Mon, Jul 23, 2018 at 02:02:35PM +0300, Todor Tomov wrote:
>> There is a PM domain for each of the VFE hardware modules. Add
>> support for basic runtime PM support to be able to control the
>> PM domains. When a PM domain needs to be powered on - a device
>> link is created. When a PM domain needs to be powered off -
>> its device link is removed. This allows separate and
>> independent control of the PM domains.
>>
>> Suspend/Resume is still not supported.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  drivers/media/platform/qcom/camss/camss-csid.c   |  4 ++
>>  drivers/media/platform/qcom/camss/camss-csiphy.c |  5 ++
>>  drivers/media/platform/qcom/camss/camss-ispif.c  | 19 ++-
>>  drivers/media/platform/qcom/camss/camss-vfe.c| 13 +
>>  drivers/media/platform/qcom/camss/camss.c| 63 
>> 
>>  drivers/media/platform/qcom/camss/camss.h| 11 +
>>  6 files changed, 113 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
>> b/drivers/media/platform/qcom/camss/camss-csid.c
>> index 627ef44..ea2b0ba 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csid.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csid.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -316,6 +317,8 @@ static int csid_set_power(struct v4l2_subdev *sd, int on)
>>  if (on) {
>>  u32 hw_version;
>>  
>> +pm_runtime_get_sync(dev);
>> +
>>  ret = regulator_enable(csid->vdda);
> 
> Shouldn't the regulator be enabled in the runtime_resume callback instead?

Ideally - yes, but it becomes more complex (different pipelines are possible
and we have only one callback) so (at least for now) I have left it as it is
and stated in the commit message that suspend/resume is still not supported.

> 
>>  if (ret < 0)
>>  return ret;
> 
> Note that you'll need pm_runtime_put() in in error handling here. Perhaps
> elsewhere, too.

Yes, I'll add it here and on all other places.

> 
> Can powering on the device (i.e. pm_runtime_get_sync() call)  fail?

I'd really like to say that it cannot fail :) at least the callback is
empty for now and cannot fail, but the logic in pm_runtime_get_sync()
is not that simple and I'm really not sure. I'll add checks in the code
in case it fails.

> 
>> @@ -348,6 +351,7 @@ static int csid_set_power(struct v4l2_subdev *sd, int on)
>>  disable_irq(csid->irq);
>>  camss_disable_clocks(csid->nclocks, csid->clock);
>>  ret = regulator_disable(csid->vdda);
>> +pm_runtime_put_sync(dev);
>>  }
>>  
>>  return ret;
>> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
>> b/drivers/media/platform/qcom/camss/camss-csiphy.c
>> index 0383e94..2db78791 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csiphy.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -240,6 +241,8 @@ static int csiphy_set_power(struct v4l2_subdev *sd, int 
>> on)
>>  u8 hw_version;
>>  int ret;
>>  
>> +pm_runtime_get_sync(dev);
>> +
>>  ret = csiphy_set_clock_rates(csiphy);
>>  if (ret < 0)
>>  return ret;
> 
> Like here.

Yes, I'll add it here too.

-- 
Best regards,
Todor Tomov


Re: [GIT PULL FOR v4.19] Various fixes

2018-07-25 Thread Mauro Carvalho Chehab
Jacopo,

Please don't do top posting! I reordered the thread for it to be at
the way it should be.

Em Wed, 25 Jul 2018 09:18:53 +0200
jacopo mondi  escreveu:

> On Tue, Jul 24, 2018 at 07:04:13PM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 18 Jul 2018 12:38:58 +0200
> > Hans Verkuil  escreveu:
> >  
> > > Hi Mauro,
> > >
> > > Various fixes. Please note that I re-added the 'Add support for STD 
> > > ioctls on subdev nodes'
> > > patch. It really is needed.
> > >
> > > Regards,
> > >
> > >   Hans
> > >  
> >  
> > > Jacopo Mondi (9):
> > >   sh: defconfig: migor: Update defconfig
> > >   sh: defconfig: migor: Enable CEU and sensor drivers
> > >   sh: defconfig: ecovec: Update defconfig
> > >   sh: defconfig: ecovec: Enable CEU and video drivers
> > >   sh: defconfig: se7724: Update defconfig
> > >   sh: defconfig: se7724: Enable CEU and sensor driver
> > >   sh: defconfig: ap325rxa: Update defconfig
> > >   sh: defconfig: ap325rxa: Enable CEU and sensor driver  
> >
> > I didn't apply the above ones. I understand you want to enable
> > the sensor drivers there, but It should either go via SUPERH
> > tree or we would need his ack to merge on our tree.
> >  
> > >   sh: migor: Remove stale soc_camera include  
> >
> > It caused me lots of doubts if we should either apply this one
> > via the media tree or not. I ended by applying, as we're maintaining
> > the soc_camera stuff, with are being removed. So, it makes more sense
> > to merge it via our tree.
> >
> > Still, it would be nicer if we had the SUPERH maintainer's ack on
> > it.
> >
> >
> > Thanks,
> > Mauro  
>
>
> Mauro,
>I understand, and I failed to cc the SH people initially.
> 
> Roping in Sato-san, Rich and the SH list.
> Could you guys please have a look here? I've gone through the media
> tree as all these changes sparkled from soc_camera removal, and while
> I was there I updated the defconfigs before enabling CEU and disabling
> soc_camera.
> 
> How long before we miss v4.19 Mauro?

That depends on the policies SH people have. This is just build config
stuff, so I guess it could be applied anytime without much issues.

From my side, I'm planning to apply the latest patches for 4.19 along
this week, reserving the next week for bug fixes only and janitorial
work.

> 
> Thanks
>j
> 


Thanks,
Mauro


Re: [PATCH v3 3/4] venus: firmware: add no TZ boot and shutdown routine

2018-07-25 Thread Stanimir Varbanov
Hi Vikash,

On 07/04/2018 10:06 PM, Vikash Garodia wrote:
> Video hardware is mainly comprised of vcodec subsystem and video
> control subsystem. Video control has ARM9 which executes the video
> firmware instructions whereas vcodec does the video frame processing.
> This change adds support to load the video firmware and bring ARM9
> out of reset for platforms which does not have trustzone.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/media/platform/qcom/venus/core.c |  6 +-
>  drivers/media/platform/qcom/venus/core.h |  5 ++
>  drivers/media/platform/qcom/venus/firmware.c | 93 
> ++--
>  drivers/media/platform/qcom/venus/firmware.h |  2 +-
>  4 files changed, 98 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/core.c 
> b/drivers/media/platform/qcom/venus/core.c
> index 75b9785..393994e 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -76,7 +76,7 @@ static void venus_sys_error_handler(struct work_struct 
> *work)
>   hfi_core_deinit(core, true);
>   hfi_destroy(core);
>   mutex_lock(>lock);
> - venus_shutdown(core->dev);
> + venus_shutdown(core);
>  
>   pm_runtime_put_sync(core->dev);
>  
> @@ -323,7 +323,7 @@ static int venus_probe(struct platform_device *pdev)
>  err_core_deinit:
>   hfi_core_deinit(core, false);
>  err_venus_shutdown:
> - venus_shutdown(dev);
> + venus_shutdown(core);
>  err_runtime_disable:
>   pm_runtime_set_suspended(dev);
>   pm_runtime_disable(dev);
> @@ -344,7 +344,7 @@ static int venus_remove(struct platform_device *pdev)
>   WARN_ON(ret);
>  
>   hfi_destroy(core);
> - venus_shutdown(dev);
> + venus_shutdown(core);
>   of_platform_depopulate(dev);
>  
>   pm_runtime_put_sync(dev);
> diff --git a/drivers/media/platform/qcom/venus/core.h 
> b/drivers/media/platform/qcom/venus/core.h
> index eb5ee66..abe4ddf 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -81,6 +81,10 @@ struct venus_caps {
>   bool valid; /* used only for Venus v1xx */
>  };
>  
> +struct video_firmware {
> + struct device *dev;
> + struct iommu_domain *iommu_domain;
> +};

add an empty line here

>  /**
>   * struct venus_core - holds core parameters valid for all instances
>   *
> @@ -129,6 +133,7 @@ struct venus_core {
>   struct device *dev;
>   struct device *dev_dec;
>   struct device *dev_enc;
> + struct video_firmware fw;
>   bool no_tz;
>   struct mutex lock;
>   struct list_head instances;
> diff --git a/drivers/media/platform/qcom/venus/firmware.c 
> b/drivers/media/platform/qcom/venus/firmware.c
> index 6d6cca4..2a98d9e 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -12,8 +12,10 @@
>   *
>   */
>  
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -27,7 +29,8 @@
>  #include "hfi_venus_io.h"
>  
>  #define VENUS_PAS_ID 9
> -#define VENUS_FW_MEM_SIZE(6 * SZ_1M)
> +#define VENUS_FW_MEM_SIZE(5 * SZ_1M)

This change should be subject to a separate patch.

> +#define VENUS_FW_START_ADDR  0x0
>  
>  static void venus_reset_cpu(struct venus_core *core)
>  {
> @@ -121,6 +124,76 @@ static int venus_load_fw(struct venus_core *core, const 
> char *fwname,
>   return ret;
>  }
>  
> +int venus_boot_noTZ(struct venus_core *core, phys_addr_t mem_phys,
> + size_t mem_size)

please use lowercase for function names and correct the size_t mem_size
indentation.

> +{
> + struct iommu_domain *iommu;

s/iommu/iommu_dom ?

> + struct device *dev;
> + int ret;
> +
> + if (!core->fw.dev)
> + return -EPROBE_DEFER;
> +
> + dev = core->fw.dev;

you could make this initialization in declaration and check for !dev
above in the if statement.

> +
> + iommu = iommu_domain_alloc(_bus_type);
> + if (!iommu) {
> + dev_err(dev, "Failed to allocate iommu domain\n");
> + return -ENOMEM;
> + }
> +
> + ret = iommu_attach_device(iommu, dev);
> + if (ret) {
> + dev_err(dev, "could not attach device\n");
> + goto err_attach;
> + }
> +
> + ret = iommu_map(iommu, VENUS_FW_START_ADDR, mem_phys, mem_size,
> + IOMMU_READ|IOMMU_WRITE|IOMMU_PRIV);

spaces between IOMMU_xxx

> + if (ret) {
> + dev_err(dev, "could not map video firmware region\n");
> + goto err_map;
> + }

add blank line here

> + core->fw.iommu_domain = iommu;
> + venus_reset_cpu(core);
> +
> + return 0;
> +
> +err_map:
> + iommu_detach_device(iommu, dev);
> +err_attach:
> + iommu_domain_free(iommu);
> + return ret;
> +}
> +
> +int venus_shutdown_noTZ(struct venus_core *core)


Re: [PATCH v3 2/4] venus: firmware: move load firmware in a separate function

2018-07-25 Thread Stanimir Varbanov
Hi Vikash,

On 07/04/2018 10:06 PM, Vikash Garodia wrote:
> Separate firmware loading part into a new function.

I cannot apply this patch in order to test the series.

> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/media/platform/qcom/venus/core.c |  4 +-
>  drivers/media/platform/qcom/venus/firmware.c | 58 
> +---
>  drivers/media/platform/qcom/venus/firmware.h |  2 +-
>  3 files changed, 39 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/core.c 
> b/drivers/media/platform/qcom/venus/core.c
> index bb6add9..75b9785 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -84,7 +84,7 @@ static void venus_sys_error_handler(struct work_struct 
> *work)
>  
>   pm_runtime_get_sync(core->dev);
>  
> - ret |= venus_boot(core->dev, core->res->fwname);
> + ret |= venus_boot(core);
>  
>   ret |= hfi_core_resume(core, true);
>  
> @@ -284,7 +284,7 @@ static int venus_probe(struct platform_device *pdev)
>   if (ret < 0)
>   goto err_runtime_disable;
>  
> - ret = venus_boot(dev, core->res->fwname);
> + ret = venus_boot(core);
>   if (ret)
>   goto err_runtime_disable;
>  
> diff --git a/drivers/media/platform/qcom/venus/firmware.c 
> b/drivers/media/platform/qcom/venus/firmware.c
> index 3968553d..6d6cca4 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -63,40 +63,37 @@ int venus_set_hw_state(struct venus_core *core, bool 
> resume)
>  }
>  EXPORT_SYMBOL_GPL(venus_set_hw_state);
>  
> -int venus_boot(struct device *dev, const char *fwname)
> +static int venus_load_fw(struct venus_core *core, const char *fwname,
> + phys_addr_t *mem_phys, size_t *mem_size)

the next function argument on new line should be just below open brace

>  {
>   const struct firmware *mdt;
>   struct device_node *node;
> - phys_addr_t mem_phys;
> + struct device *dev;
>   struct resource r;
>   ssize_t fw_size;
> - size_t mem_size;
>   void *mem_va;
>   int ret;
>  
> - if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) || !qcom_scm_is_available())
> - return -EPROBE_DEFER;
> -
> + dev = core->dev;
>   node = of_parse_phandle(dev->of_node, "memory-region", 0);
>   if (!node) {
>   dev_err(dev, "no memory-region specified\n");
>   return -EINVAL;
>   }
> -

please don't delete above blank line

>   ret = of_address_to_resource(node, 0, );
>   if (ret)
>   return ret;
>  
> - mem_phys = r.start;
> - mem_size = resource_size();
> + *mem_phys = r.start;
> + *mem_size = resource_size();
>  
> - if (mem_size < VENUS_FW_MEM_SIZE)
> + if (*mem_size < VENUS_FW_MEM_SIZE)
>   return -EINVAL;
>  
> - mem_va = memremap(r.start, mem_size, MEMREMAP_WC);
> + mem_va = memremap(r.start, *mem_size, MEMREMAP_WC);
>   if (!mem_va) {
>   dev_err(dev, "unable to map memory region: %pa+%zx\n",
> - , mem_size);
> + , *mem_size);
>   return -ENOMEM;
>   }
>  
> @@ -110,24 +107,41 @@ int venus_boot(struct device *dev, const char *fwname)
>   release_firmware(mdt);
>   goto err_unmap;
>   }
> -
> - ret = qcom_mdt_load(dev, mdt, fwname, VENUS_PAS_ID, mem_va, mem_phys,
> - mem_size);
> + if (core->no_tz)
> + ret = qcom_mdt_load_no_init(dev, mdt, fwname, VENUS_PAS_ID,
> + mem_va, *mem_phys, *mem_size, NULL);

indentation is wrong see the original code

> + else
> + ret = qcom_mdt_load(dev, mdt, fwname, VENUS_PAS_ID, mem_va,
> + *mem_phys, *mem_size);

indentation again

>  
>   release_firmware(mdt);
>  
> - if (ret)
> - goto err_unmap;
> -
> - ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
> - if (ret)
> - goto err_unmap;
> -
>  err_unmap:
>   memunmap(mem_va);
>   return ret;
>  }
>  
> +int venus_boot(struct venus_core *core)
> +{
> + phys_addr_t mem_phys;
> + size_t mem_size;
> + int ret;
> + struct device *dev;

please order declarations from longer to shorter.

> +
> + if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER))
> + return -EPROBE_DEFER;

the original venus_boot was checking for || !qcom_scm_is_available() why
is that removed? It was done on purpose.

> +
> + dev = core->dev;

this could be done when dev is declared.

> +
> + ret = venus_load_fw(core, core->res->fwname, _phys, _size);
> + if (ret) {
> + dev_err(dev, "fail to load video firmware\n");
> + return -EINVAL;
> + }
> +
> + return qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
> +}
> +
>  int venus_shutdown(struct device *dev)
>  {
>   return 

Re: [PATCH v3 1/4] venus: firmware: add routine to reset ARM9

2018-07-25 Thread Stanimir Varbanov
Hi Vikash,

On 07/04/2018 10:06 PM, Vikash Garodia wrote:
> Add routine to reset the ARM9 and brings it out of reset. Also
> abstract the Venus CPU state handling with a new function. This
> is in preparation to add PIL functionality in venus driver.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/media/platform/qcom/venus/core.h |  1 +
>  drivers/media/platform/qcom/venus/firmware.c | 36 
> 
>  drivers/media/platform/qcom/venus/firmware.h |  1 +
>  drivers/media/platform/qcom/venus/hfi_venus.c| 13 +++--
>  drivers/media/platform/qcom/venus/hfi_venus_io.h |  5 
>  5 files changed, 47 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/core.h 
> b/drivers/media/platform/qcom/venus/core.h
> index 2f02365..eb5ee66 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -129,6 +129,7 @@ struct venus_core {
>   struct device *dev;
>   struct device *dev_dec;
>   struct device *dev_enc;
> + bool no_tz;
>   struct mutex lock;
>   struct list_head instances;
>   atomic_t insts_count;
> diff --git a/drivers/media/platform/qcom/venus/firmware.c 
> b/drivers/media/platform/qcom/venus/firmware.c
> index 521d4b3..3968553d 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -22,11 +22,47 @@
>  #include 
>  #include 
>  
> +#include "core.h"
>  #include "firmware.h"
> +#include "hfi_venus_io.h"
>  
>  #define VENUS_PAS_ID 9
>  #define VENUS_FW_MEM_SIZE(6 * SZ_1M)
>  
> +static void venus_reset_cpu(struct venus_core *core)
> +{
> + void __iomem *base = core->base;
> +
> + writel(0, base + WRAPPER_FW_START_ADDR);
> + writel(VENUS_FW_MEM_SIZE, base + WRAPPER_FW_END_ADDR);
> + writel(0, base + WRAPPER_CPA_START_ADDR);
> + writel(VENUS_FW_MEM_SIZE, base + WRAPPER_CPA_END_ADDR);
> + writel(0x0, base + WRAPPER_CPU_CGC_DIS);
> + writel(0x0, base + WRAPPER_CPU_CLOCK_CONFIG);
> +
> + /* Make sure all register writes are committed. */
> + mb();
> +
> + /* Bring ARM9 out of reset */
> + writel_relaxed(0, base + WRAPPER_A9SS_SW_RESET);

replace writel_relaxed with writel and drop above mb. The writel has wmb
just before writing so I think using writel here is better choice.

> +}
> +
> +int venus_set_hw_state(struct venus_core *core, bool resume)

s/resume/suspend as it is done in the function prototype in firmware.h.

> +{
> + void __iomem *base = core->base;
> +
> + if (!core->no_tz)
> + return qcom_scm_set_remote_state(resume, 0);
> +
> + if (resume)
> + venus_reset_cpu(core);
> + else
> + writel(1, base + WRAPPER_A9SS_SW_RESET);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(venus_set_hw_state);
> +
>  int venus_boot(struct device *dev, const char *fwname)
>  {
>   const struct firmware *mdt;
> diff --git a/drivers/media/platform/qcom/venus/firmware.h 
> b/drivers/media/platform/qcom/venus/firmware.h
> index 428efb5..ff2e70e 100644
> --- a/drivers/media/platform/qcom/venus/firmware.h
> +++ b/drivers/media/platform/qcom/venus/firmware.h
> @@ -18,5 +18,6 @@
>  
>  int venus_boot(struct device *dev, const char *fwname);
>  int venus_shutdown(struct device *dev);
> +int venus_set_hw_state(struct venus_core *core, bool suspend);

could you make two inline functions here, call them
venus_set_hw_state_suspend() and venus_set_hw_state_resume() which just
call venus_set_hw_state with the right state.

>  
>  #endif
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
> b/drivers/media/platform/qcom/venus/hfi_venus.c
> index 9366dae..5b56925 100644
> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include "core.h"
> @@ -27,6 +26,7 @@
>  #include "hfi_msgs.h"
>  #include "hfi_venus.h"
>  #include "hfi_venus_io.h"
> +#include "firmware.h"
>  
>  #define HFI_MASK_QHDR_TX_TYPE0xff00
>  #define HFI_MASK_QHDR_RX_TYPE0x00ff
> @@ -55,11 +55,6 @@
>  #define IFACEQ_VAR_LARGE_PKT_SIZE512
>  #define IFACEQ_VAR_HUGE_PKT_SIZE (1024 * 12)
>  
> -enum tzbsp_video_state {
> - TZBSP_VIDEO_STATE_SUSPEND = 0,
> - TZBSP_VIDEO_STATE_RESUME
> -};
> -
>  struct hfi_queue_table_header {
>   u32 version;
>   u32 size;
> @@ -575,7 +570,7 @@ static int venus_power_off(struct venus_hfi_device *hdev)
>   if (!hdev->power_enabled)
>   return 0;
>  
> - ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
> + ret = venus_set_hw_state(hdev->core, false);

... and use venus_set_hw_state_suspend()

>   if (ret)
>   return ret;
>  
> @@ -595,7 +590,7 @@ static int venus_power_on(struct venus_hfi_device *hdev)
>   if (hdev->power_enabled)
>  

  1   2   >