cron job: media_tree daily build: WARNINGS

[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 Nov 16 05:00:24 CET 2017
media-tree git hash:30b4e122d71cbec2944a5f8b558b88936ee42f10
media_build git hash:   097aaf3e4e4bfdeff130db9697dec1befeb3221b
v4l-utils git hash: 462792610598eb5402cb59692b172f43c555ad23
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: 0.5.1 (Debian: 0.5.1-2)
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.13.0-164

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

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

[PATCH] [media] winbond-cir: Fix pnp_irq's error checking for wbcir_probe

[Arvind Yadav]

The pnp_irq() function returns -1 if an error occurs.
pnp_irq() error checking for zero is not correct.

Signed-off-by: Arvind Yadav 
---
 drivers/media/rc/winbond-cir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 3ca7ab4..0adf099 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1044,7 +1044,7 @@ struct wbcir_data {
data->irq = pnp_irq(device, 0);
 
if (data->wbase == 0 || data->ebase == 0 ||
-   data->sbase == 0 || data->irq == 0) {
+   data->sbase == 0 || data->irq == -1) {
err = -ENODEV;
dev_err(dev, "Invalid resources\n");
goto exit_free_data;
-- 
1.9.1

Re: [GIT PULL for v4.15-rc1] media updates

[Linus Torvalds]

On Wed, Nov 15, 2017 at 4:28 PM, Mauro Carvalho Chehab
 wrote:
>
> PS.: This time, there is a merge from staging tree, from the same commit
>  you pulled on your tree, in order to solve a conflict at the
>  atomisp driver, as reported by Stephen Rothwell.

Please don't do that.

I got conflicts anyway, and I'd rather see them. Honestly, I want to
know, but I also am quite possibly better at resolving those conflicts
than most developers, because I do a *lot* of merges.

Why do I have to say this *every* single merge window?

Stop trying to hide your conflicts. Stop thinking that I prefer them
hidden over being there. Stop doing crazy merges from trees that
aren't yours and you were not asked to pull!

Really.

Linus

Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver

[Rob Herring]

On Wed, Nov 15, 2017 at 10:31:14AM -0800, Tim Harvey wrote:
> On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring  wrote:
> > On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
> >> Add support for the TDA1997x HDMI receivers.
> >>
> >> Cc: Hans Verkuil 
> >> Signed-off-by: Tim Harvey 
> >> ---
> >> v3:
> >>  - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
> >>  - fixed missing break
> >>  - use only hdmi_infoframe_log for infoframe logging
> >>  - simplify tda1997x_s_stream error handling
> >>  - add delayed work proc to handle hotplug enable/disable
> >>  - fix set_edid (disable HPD before writing, enable after)
> >>  - remove enabling edid by default
> >>  - initialize timings
> >>  - take quant range into account in colorspace conversion
> >>  - remove vendor/product tracking (we provide this in log_status via 
> >> infoframes)
> >>  - add v4l_controls
> >>  - add more detail to log_status
> >>  - calculate vhref generator timings
> >>  - timing detection fixes (rounding errors, hswidth errors)
> >>  - rename configure_input/configure_conv functions
> >>
> >> v2:
> >>  - implement dv timings enum/cap
> >>  - remove deprecated g_mbus_config op
> >>  - fix dv_query_timings
> >>  - add EDID get/set handling
> >>  - remove max-pixel-rate support
> >>  - add audio codec DAI support
> >>  - change audio bindings
> >> ---
> >>  drivers/media/i2c/Kconfig|9 +
> >>  drivers/media/i2c/Makefile   |1 +
> >>  drivers/media/i2c/tda1997x.c | 3485 
> >> ++
> >>  include/dt-bindings/media/tda1997x.h |   78 +
> >
> > This belongs with the binding documentation patch.
> >
> 
> Rob,
> 
> Thanks - missed that. I will move it for v4.
> 
> Regarding your previous comment to the v2 series:
> > The rest of the binding looks fine, but I have some reservations about
> > this. I think this should be common probably. There's been a few
> > bindings for display recently that deal with the interface format. Maybe
> > some vendor property is needed here to map a standard interface format
> > back to pin configuration.
> 
> I take it this is not an 'Ack' for the bindings?
> 
> Which did you feel should be made common? I admit I was surprised
> there wasn't a common binding for audio bus format (i2s|spdif) but if
> you were referring to the video data that would probably be much more
> complicated.

The video data. Either you have to try to come up with some way to map 
color components to signals/pins (and even cycles) or you just enumerate 
the formats and keep adding to them when new ones appear. There's h/w 
that allows the former, but in the end you have to interoperate, so 
enumerating the formats is probably enough.

> I was hoping one of the media/driver maintainers would respond to your
> comment with thoughts as I'm not familiar with a very wide variety of
> receivers.

I am hoping, too.

Rob

Re: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

[Takiguchi, Yasunari]

Hi, all

I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver 
version 4 on 13th/Oct.
Are there any comments, advices and review results for them?

I'd like to get better understanding of current review status for our codes.

Regards,
Takiguchi

[PATCH/RFC 0/2] V4L2: Handle the race condition between device access and unbind

[Laurent Pinchart]

Hello,

This small RFC is an attempt to handle the race condition that exists between
device access and device unbind.

Devices can be unbound from drivers in three different ways:

- When the driver module is unloaded, the driver is unregistered and unbound
  from all devices it was bound to. As module unloading can't happen as long
  as the module reference count is not zero, no concurrent access to the
  device from userspace access can be ongoing. This patch series isn't needed
  to address this case.

- When the device is removed either physically (for instance with USB or
  hotpluggable PCI) or logically (for instance by unloading a DT overlay), the
  device is unbound from its driver.

- When userspace initiates a manual unbind through the driver sysfs unbind
  file the device is also unbound from its driver.

The last two cases can occur at any time and are not synchronized with device
access from userspace through video device nodes. This is the race that the
patch series tries to address.

Drivers need to ensure that no access to internal resources can occur before
freeing those resources in the unbind handler. To do so, we need to both block
all new accesses to device resources, and wait for all ongoing accesses to
complete before freeing resources.

This series achieves this by marking code sections that access device
resources with the new video_device_enter() and video_device_exit() functions.
The function internally keep a count of the number of such sections currently
being executed in order to delay device unbind. Driver must call the
video_device_unplug() function in their unbind handler before cleaning up any
resource that can be accessed through the function marked with enter/exit. The
video_device_unplug() function marks the device is being unbound, preventing
subsequent calls to video_device_enter() from succeeding, and then waits for
all device access code sections to be exited before returning.

Several issues haven't been addressed yet, hence the RFC status of the series:

- Only the video_device ioctl handler is currently protected by
  video_device_enter() and video_device_exit(). This needs to be extended to
  other file operations.

- Blocking operations (such a VIDIOC_DQBUF for instance) need to be unblocked
  at unbind time. Whether this can be handled entirely inside
  video_device_unplug() needs to be researched.

- While the above mechanism should be usable for subdevs too as the
  v4l2_subdev structure contains a video_device structure, the subdev
  .release() file operation handler subdev_close() accesses the v4l2_subdev
  structure, which is currently freed by drivers at unbind time due to the
  lack of a structure release operation in the v4l2_subdev structure. Fixing
  this will likely require major refactoring of the subdev registration API,
  which might not be considered worth it as the long term goal is to replace
  subdev device nodes with the request API anyway.

I would like to receive feedback on this initial version, and will then work
on a second version that addresses at least the first two problems listed
above.

Laurent Pinchart (2):
  v4l: v4l2-dev: Add infrastructure to protect device unplug race
  v4l: rcar-vin: Wait for device access to complete before unplugging

 drivers/media/platform/rcar-vin/rcar-core.c |  1 +
 drivers/media/v4l2-core/v4l2-dev.c  | 57 +
 include/media/v4l2-dev.h| 47 
 3 files changed, 105 insertions(+)

-- 
Regards,

Laurent Pinchart

[PATCH/RFC 2/2] v4l: rcar-vin: Wait for device access to complete before unplugging

[Laurent Pinchart]

To avoid races between device access and unplug, call the
video_device_unplug() function in the platform driver remove handler.
This will unsure that all device access completes before the remove
handler proceeds to free resources.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index bd7976efa1fb..c5210f1d09ed 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1273,6 +1273,7 @@ static int rcar_vin_remove(struct platform_device *pdev)
 
pm_runtime_disable(>dev);
 
+   video_device_unplug(>vdev);
 
if (!vin->info->use_mc) {
v4l2_async_notifier_unregister(>notifier);
-- 
Regards,

Laurent Pinchart

[PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Laurent Pinchart]

Device unplug being asynchronous, it naturally races with operations
performed by userspace through ioctls or other file operations on video
device nodes.

This leads to potential access to freed memory or to other resources
during device access if unplug occurs during device access. To solve
this, we need to wait until all device access completes when unplugging
the device, and block all further access when the device is being
unplugged.

Three new functions are introduced. The video_device_enter() and
video_device_exit() functions must be used to mark entry and exit from
all code sections where the device can be accessed. The
video_device_unplug() function is then used in the unplug handler to
mark the device as being unplugged and wait for all access to complete.

As an example mark the ioctl handler as a device access section. Other
file operations need to be protected too, and blocking ioctls (such as
VIDIOC_DQBUF) need to be handled as well.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/v4l2-core/v4l2-dev.c | 57 ++
 include/media/v4l2-dev.h   | 47 +++
 2 files changed, 104 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index c647ba648805..c73c6d49e7cf 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device *vdev)
 }
 EXPORT_SYMBOL(video_device_release_empty);
 
+int video_device_enter(struct video_device *vdev)
+{
+   bool unplugged;
+
+   spin_lock(>unplug_lock);
+   unplugged = vdev->unplugged;
+   if (!unplugged)
+   vdev->access_refcount++;
+   spin_unlock(>unplug_lock);
+
+   return unplugged ? -ENODEV : 0;
+}
+EXPORT_SYMBOL_GPL(video_device_enter);
+
+void video_device_exit(struct video_device *vdev)
+{
+   bool wake_up;
+
+   spin_lock(>unplug_lock);
+   WARN_ON(--vdev->access_refcount < 0);
+   wake_up = vdev->access_refcount == 0;
+   spin_unlock(>unplug_lock);
+
+   if (wake_up)
+   wake_up(>unplug_wait);
+}
+EXPORT_SYMBOL_GPL(video_device_exit);
+
+void video_device_unplug(struct video_device *vdev)
+{
+   bool unplug_blocked;
+
+   spin_lock(>unplug_lock);
+   unplug_blocked = vdev->access_refcount > 0;
+   vdev->unplugged = true;
+   spin_unlock(>unplug_lock);
+
+   if (!unplug_blocked)
+   return;
+
+   if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
+   msecs_to_jiffies(15)))
+   WARN(1, "Timeout waiting for device access to complete\n");
+}
+EXPORT_SYMBOL_GPL(video_device_unplug);
+
 static inline void video_get(struct video_device *vdev)
 {
get_device(>dev);
@@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
struct video_device *vdev = video_devdata(filp);
int ret = -ENODEV;
 
+   ret = video_device_enter(vdev);
+   if (ret < 0)
+   return ret;
+
if (vdev->fops->unlocked_ioctl) {
struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
 
@@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
return -ERESTARTSYS;
if (video_is_registered(vdev))
ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
+   else
+   ret = -ENODEV;
if (lock)
mutex_unlock(lock);
} else
ret = -ENOTTY;
 
+   video_device_exit(vdev);
return ret;
 }
 
@@ -841,6 +894,10 @@ int __video_register_device(struct video_device *vdev, int 
type, int nr,
if (WARN_ON(!vdev->v4l2_dev))
return -EINVAL;
 
+   /* unplug support */
+   spin_lock_init(>unplug_lock);
+   init_waitqueue_head(>unplug_wait);
+
/* v4l2_fh support */
spin_lock_init(>fh_lock);
INIT_LIST_HEAD(>fh_list);
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index e657614521e3..365a94f91dc9 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -178,6 +179,12 @@ struct v4l2_file_operations {
  * @pipe:  media_pipeline
  * @fops: pointer to  v4l2_file_operations for the video device
  * @device_caps: device capabilities as used in v4l2_capabilities
+ * @unplugged: when set the device has been unplugged and no device access
+ * section can be entered
+ * @access_refcount: number of device access section currently running for the
+ * device
+ * @unplug_lock: protects unplugged and access_refcount
+ * @unplug_wait: wait queue to wait for device access sections to complete
  * @dev:  device for the video device
  * 

[GIT PULL for v4.15-rc1] media updates

[Mauro Carvalho Chehab]

Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.15-1


For:

- Documentation for digital TV (both kAPI and uAPI) are now in sync with
  the implementation (except for legacy/deprecated ioctls). This is a major
  step, as there were always a gap there;

- New sensor driver: imx274;
- New cec driver: cec-gpio;
- New platform driver for rockship rga and tegra CEC;
- New RC driver: tango-ir;
- Several cleanups at atomisp driver;
- Core improvements for RC, CEC, V4L2 async probing support and DVB;
- Lots of drivers cleanup, fixes and improvements.

PS.: This time, there is a merge from staging tree, from the same commit
 you pulled on your tree, in order to solve a conflict at the
 atomisp driver, as reported by Stephen Rothwell.

Regards,
Mauro

-


The following changes since commit c14dd9d5f8beda9d8c621683b4e7d6cb5cd3cda7:

  staging: lustre: add SPDX identifiers to all lustre files (2017-11-11 
14:46:21 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.15-1

for you to fetch changes up to f2ecc3d0787e05d9145722feed01d4a11ab6bec1:

  Merge tag 'staging-4.15-rc1' into v4l_for_linus (2017-11-14 10:47:01 -0500)


media updates for v4.15-rc1


Adam Sampson (1):
  media: usbtv: fix brightness and contrast controls

Aishwarya Pant (2):
  media: staging: atomisp2: cleanup null check on memory allocation
  media: staging: atomisp: cleanup out of memory messages

Akinobu Mita (5):
  media: adv7180: don't clear V4L2_SUBDEV_FL_IS_I2C
  media: max2175: don't clear V4L2_SUBDEV_FL_IS_I2C
  media: ov2640: don't clear V4L2_SUBDEV_FL_IS_I2C
  media: ov5640: don't clear V4L2_SUBDEV_FL_IS_I2C
  media: ov9650: remove unnecessary terminated entry in menu items array

Allen Pais (1):
  media: atomisp:use ARRAY_SIZE() instead of open coding

Andrey Konovalov (1):
  media: dib0700: fix invalid dvb_detach argument

Andy Shevchenko (21):
  media: staging: atomisp: Remove dead code for MID (#1)
  media: staging: atomisp: Don't override D3 delay settings here
  media: staging: atomisp: Remove dead code for MID (#2)
  media: staging: atomisp: Remove dead code for MID (#3)
  media: staging: atomisp: Move to upstream IOSF MBI API
  media: staging: atomisp: Remove dead code for MID (#4)
  media: staging: atomisp: Remove unneeded intel-mid.h inclusion
  media: staging: atomisp: Remove IMX sensor support
  media: staging: atomisp: Remove AP1302 sensor support
  media: staging: atomisp: Use module_i2c_driver() macro
  media: staging: atomisp: Switch i2c drivers to use ->probe_new()
  media: staging: atomisp: Do not set GPIO twice
  media: staging: atomisp: Remove unneeded gpio.h inclusion
  media: staging: atomisp: Remove ->gpio_ctrl() callback
  media: staging: atomisp: Remove ->power_ctrl() callback
  media: staging: atomisp: Remove duplicate declaration in header
  media: staging: atomisp: Remove unused members of 
camera_sensor_platform_data
  media: staging: atomisp: Remove Gmin dead code #1
  media: staging: atomisp: Remove Gmin dead code #2
  media: staging: atomisp: Remove FSF snail address
  media: v4l2-ctrls: Don't validate BITMASK twice

Arnd Bergmann (3):
  [media] rcar_drif: fix potential uninitialized variable use
  media: rockchip/rga: annotate PM functions as __maybe_unused
  media: av7110: avoid 2038 overflow in debug print

Arvind Yadav (4):
  media: Staging: atomisp: constify driver_attribute
  [media] media: rc: constify usb_device_id
  media: coda: Handle return value of kasprintf
  media: imon: Fix null-ptr-deref in imon_probe

Bhumika Goyal (12):
  media: usb: make i2c_client const
  media: pci: make i2c_client const
  [media] media: rc: make device_type const
  [media] saa7146: make saa7146_use_ops const
  media: bt8xx: make bttv_vbi_qops const
  media: zoran: make zoran_template const
  media: cx23885/saa7134: make vb2_ops const
  media: au0828/em28xx: make vb2_ops const
  media: cx231xx: make cx231xx_vbi_qops const
  media: radio-si470x: make si470x_viddev_template const
  media: davinci: make function arguments const
  media: davinci: make ccdc_hw_device structures const

Branislav Radocaj (1):
  media: Staging: atomisp: fix alloc_cast.cocci warnings

Chiranjeevi Rapolu (4):
  [media] media: ov5670: Use recommended black level and output bias
  [media] media: ov5670: Fix not streaming issue after resume
  [media] media: ov13858: Calculate pixel-rate at runtime, use mode
  [media] media: ov13858: Fix 4224x3136 video flickering at some vblanks

Christophe JAILLET (1):
  [media] media: v4l2-pci-skeleton: Fix error 

Re: [PATCH] v4l: rcar-vin: Implement V4L2 video node release handler

[Laurent Pinchart]

Hi Niklas,

On Thursday, 16 November 2017 01:34:33 EET Niklas Söderlund wrote:
> On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote:
> > The rvin_dev data structure contains driver private data for an instance
> > of the VIN. It is allocated dynamically at probe time, and must be freed
> > once all users are gone.
> > 
> > The structure is currently allocated with devm_kzalloc(), which results
> > in memory being freed when the device is unbound. If a userspace
> > application is currently performing an ioctl call, or just keeps the
> > device node open and closes it later, this will lead to accessing freed
> > memory.
> > 
> > Fix the problem by implementing a V4L2 release handler for the video
> > node associated with the VIN instance (called when the last user of the
> > video node releases it), and freeing memory explicitly from the release
> > handler.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> Acked-by: Niklas Söderlund 
> 
> This patch is based on-top of the VIN Gen3 enablement series not yet
> upstream. This is OK for me, just wanted to check that this was the
> intention as to minimize conflicts between the two.

Yes, that's my intention. The patch should be included, or possibly squashed 
in, your development branch.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] v4l: rcar-vin: Implement V4L2 video node release handler

[Niklas Söderlund]

Hi Laurent,

Thanks for your patch.

On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote:
> The rvin_dev data structure contains driver private data for an instance
> of the VIN. It is allocated dynamically at probe time, and must be freed
> once all users are gone.
> 
> The structure is currently allocated with devm_kzalloc(), which results
> in memory being freed when the device is unbound. If a userspace
> application is currently performing an ioctl call, or just keeps the
> device node open and closes it later, this will lead to accessing freed
> memory.
> 
> Fix the problem by implementing a V4L2 release handler for the video
> node associated with the VIN instance (called when the last user of the
> video node releases it), and freeing memory explicitly from the release
> handler.
> 
> Signed-off-by: Laurent Pinchart 

Acked-by: Niklas Söderlund 

This patch is based on-top of the VIN Gen3 enablement series not yet 
upstream. This is OK for me, just wanted to check that this was the 
intention as to minimize conflicts between the two.

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 29 
> +++--
>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  9 -
>  2 files changed, 27 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 495610949457..bd7976efa1fb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1208,7 +1208,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
>   struct resource *mem;
>   int irq, ret;
>  
> - vin = devm_kzalloc(>dev, sizeof(*vin), GFP_KERNEL);
> + vin = kzalloc(sizeof(*vin), GFP_KERNEL);
>   if (!vin)
>   return -ENOMEM;
>  
> @@ -1224,20 +1224,26 @@ static int rcar_vin_probe(struct platform_device 
> *pdev)
>   vin->info = attr->data;
>  
>   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (mem == NULL)
> - return -EINVAL;
> + if (mem == NULL) {
> + ret = -EINVAL;
> + goto error_free;
> + }
>  
>   vin->base = devm_ioremap_resource(vin->dev, mem);
> - if (IS_ERR(vin->base))
> - return PTR_ERR(vin->base);
> + if (IS_ERR(vin->base)) {
> + ret = PTR_ERR(vin->base);
> + goto error_free;
> + }
>  
>   irq = platform_get_irq(pdev, 0);
> - if (irq < 0)
> - return irq;
> + if (irq < 0) {
> + ret = irq;
> + goto error_free;
> + }
>  
>   ret = rvin_dma_probe(vin, irq);
>   if (ret)
> - return ret;
> + goto error_free;
>  
>   platform_set_drvdata(pdev, vin);
>   if (vin->info->use_mc)
> @@ -1245,15 +1251,18 @@ static int rcar_vin_probe(struct platform_device 
> *pdev)
>   else
>   ret = rvin_digital_graph_init(vin);
>   if (ret < 0)
> - goto error;
> + goto error_dma;
>  
>   pm_suspend_ignore_children(>dev, true);
>   pm_runtime_enable(>dev);
>  
>   return 0;
> -error:
> +
> +error_dma:
>   rvin_dma_remove(vin);
>   v4l2_async_notifier_cleanup(>notifier);
> +error_free:
> + kfree(vin);
>  
>   return ret;
>  }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index 2c14d44950b2..25f1d24c1d2d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -1026,6 +1026,13 @@ static void rvin_notify(struct v4l2_subdev *sd,
>   }
>  }
>  
> +static void rvin_v4l2_release(struct video_device *vdev)
> +{
> + struct rvin_dev *vin = container_of(vdev, struct rvin_dev, vdev);
> +
> + kfree(vin);
> +}
> +
>  int rvin_v4l2_register(struct rvin_dev *vin)
>  {
>   struct video_device *vdev = >vdev;
> @@ -1038,7 +1045,7 @@ int rvin_v4l2_register(struct rvin_dev *vin)
>   vdev->queue = >queue;
>   snprintf(vdev->name, sizeof(vdev->name), "%s %s", KBUILD_MODNAME,
>dev_name(vin->dev));
> - vdev->release = video_device_release_empty;
> + vdev->release = rvin_v4l2_release;
>   vdev->lock = >lock;
>   vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
>   V4L2_CAP_READWRITE;
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v11 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Niklas Söderlund]

Hi Rob,

Thanks for your feedback.

On 2017-11-15 13:59:36 -0600, Rob Herring wrote:
> On Sat, Nov 11, 2017 at 01:25:25AM +0100, Niklas Söderlund wrote:
> > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> > are located between the video sources (CSI-2 transmitters) and the video
> > grabbers (VIN) on Gen3 of Renesas R-Car SoC.
> > 
> > Each CSI-2 device is connected to more then one VIN device which
> > simultaneously can receive video from the same CSI-2 device. Each VIN
> > device can also be connected to more then one CSI-2 device. The routing
> > of which link are used are controlled by the VIN devices. There are only
> > a few possible routes which are set by hardware limitations, which are
> > different for each SoC in the Gen3 family.
> > 
> > To work with the limitations of routing possibilities it is necessary
> > for the DT bindings to describe which VIN device is connected to which
> > CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> > VIN device that be connected to it. To setup and to know which links are
> > valid for each SoC is the responsibility of the VIN driver since the
> > register to configure it belongs to the VIN hardware.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  .../bindings/media/renesas,rcar-csi2.txt   | 104 
> > +
> >  MAINTAINERS|   1 +
> >  2 files changed, 105 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt 
> > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > new file mode 100644
> > index ..24705d8997b14a10
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > @@ -0,0 +1,104 @@
> > +Renesas R-Car MIPI CSI-2
> > +
> > +
> > +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
> > +family of devices. It is to be used in conjunction with the R-Car VIN 
> > module,
> > +which provides the video capture capabilities.
> > +
> > +Mandatory properties
> > +
> > + - compatible: Must be one or more of the following
> > +   - "renesas,r8a7795-csi2" for the R8A7795 device.
> > +   - "renesas,r8a7796-csi2" for the R8A7796 device.
> > +
> > + - reg: the register base and size for the device registers
> > + - interrupts: the interrupt for the device
> > + - clocks: Reference to the parent clock
> > +
> > +The device node shall contain two 'port' child nodes according to the
> > +bindings defined in Documentation/devicetree/bindings/media/
> > +video-interfaces.txt. Port 0 shall connect the node that is the video
> > +source for to the CSI-2. Port 1 shall connect all the R-Car VIN
> > +modules, which can make use of the CSI-2 module.
> > +
> > +- Port 0 - Video source (Mandatory)
> > +   - Endpoint 0 - sub-node describing the endpoint that is the video source
> > +
> > +- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
> > +   - Endpoint 0 - sub-node describing the endpoint that is VIN0
> > +   - Endpoint 1 - sub-node describing the endpoint that is VIN1
> > +   - Endpoint 2 - sub-node describing the endpoint that is VIN2
> > +   - Endpoint 3 - sub-node describing the endpoint that is VIN3
> > +   - Endpoint 4 - sub-node describing the endpoint that is VIN4
> > +   - Endpoint 5 - sub-node describing the endpoint that is VIN5
> > +   - Endpoint 6 - sub-node describing the endpoint that is VIN6
> > +   - Endpoint 7 - sub-node describing the endpoint that is VIN7
> > +
> > +Example:
> > +
> > +   csi20: csi2@fea8 {
> > +   compatible = "renesas,r8a7796-csi2", "renesas,rcar-gen3-csi2";
> > +   reg = <0 0xfea8 0 0x1>;
> > +   interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> > +   clocks = < CPG_MOD 714>;
> > +   power-domains = < R8A7796_PD_ALWAYS_ON>;
> > +   resets = < 714>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   reg = <0>;
> > +
> > +   csi20_in: endpoint@0 {
> 
> unit-address without reg property is not valid.

Ops, my bad thanks for noticing.

> 
> Otherwise,
> 
> Acked-by: Rob Herring 

Thanks, will fix the above and re-send.

> 
> 
> > +   clock-lanes = <0>;
> > +   data-lanes = <1>;
> > +   remote-endpoint = <_txb>;
> > +   };
> > +   };
> > +
> > +   port@1 {
> > +   #address-cells = <1>;
> > + 

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[Niklas Söderlund]

Hi Rob,

Thanks for your feedback, much appreciated!

On 2017-11-15 14:02:26 -0600, Rob Herring wrote:
> On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
> > Document the devicetree bindings for the CSI-2 inputs available on Gen3.
> > 
> > There is a need to add a custom property 'renesas,id' and to define
> > which CSI-2 input is described in which endpoint under the port@1 node.
> > This information is needed since there are a set of predefined routes
> > between each VIN and CSI-2 block. This routing table will be kept
> > inside the driver but in order for it to act on it it must know which
> > VIN and CSI-2 is which.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  .../devicetree/bindings/media/rcar_vin.txt | 116 
> > ++---
> >  1 file changed, 104 insertions(+), 12 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> > b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
> >  ---
> >  
> >  The rcar_vin device provides video input capabilities for the Renesas R-Car
> > -family of devices. The current blocks are always slaves and suppot one 
> > input
> > -channel which can be either RGB, YUYV or BT656.
> > +family of devices.
> > +
> > +Each VIN instance has a single parallel input that supports RGB and YUV 
> > video,
> > +with both external synchronization and BT.656 synchronization for the 
> > latter.
> > +Depending on the instance the VIN input is connected to external SoC pins, 
> > or
> > +on Gen3 to a CSI-2 receiver.
> >  
> >   - compatible: Must be one or more of the following
> > - "renesas,vin-r8a7795" for the R8A7795 device
> > @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
> >  Additionally, an alias named vinX will need to be created to specify
> >  which video input device this is.
> >  
> > -The per-board settings:
> > +The per-board settings Gen2:
> >   - port sub-node describing a single endpoint connected to the vin
> > as described in video-interfaces.txt[1]. Only the first one will
> > be considered as each vin interface has one input port.
> >  
> > -   These settings are used to work out video input format and widths
> > -   into the system.
> > +The per-board settings Gen3:
> > +
> > +Gen3 can support both a single connected parallel input source from
> > +external SoC pins (port0) and/or multiple parallel input sources from
> > +local SoC CSI-2 receivers (port1) depending on SoC.
> >  
> > +- renesas,id - ID number of the VIN, VINx in the documentation.
> 
> Why is this needed? We try to avoid indexes unless that's the only way a 
> device is addressed (and then we use reg).

This is unfortunately needed (or something similar) as there is a 
register in one VIN instance which controls the routing of the incoming 
CSI-2 video streams, not only to itself, but also to other VIN instances 
inside the same SoC.

To be more specific I will try to clarify this using the R-Car H3 as an 
example. On the H3 there are 8 instances of the capture hardware (VIN0 - 
VIN7) and 3 instances off CSI-2 receivers (CSI20, CSI40 and CSI41) which 
receives CSI-2 streams, split the possible multiple virtual channels 
(VC) encoded in CSI-2 streams and forwards it to the VIN's.

The problem is that VIN0 and VIN4 are different from the other VIN's, 
they have one register (CHSEL) which controls the limited number of 
possible routes of video streams between a CSI-2 + VC to a specific VIN.  
The CHSEL register in VIN0 controls the routing for VIN0-3 and the one 
in VIN4 controls VIN4-7 (the two subgroups are similar so lets only 
consider VIN0-3).

There are only a handful of routes possible and the kicker is that 
changing the CHSEL value in VIN0, directly reflects all routes for 
VIN0-VIN3 per this table:

CHSEL reg in VIN0:  0 1 2 3 4
Video sent to VIN0: CSI40/VC0 CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI20/VC0
Video sent to VIN1: CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI40/VC1 CSI20/VC1
Video sent to VIN2: CSI20/VC1 CSI40/VC0 CSI20/VC0 CSI40/VC2 CSI20/VC2
Video sent to VIN3: CSI40/VC1 CSI20/VC1 CSI20/VC1 CSI40/VC3 CSI20/VC3

So if CHSEL in VIN0 is set to 2 the following routes are active: VIN0: 
CSI40/VC1, VIN1: CSI40/VC0, VIN2: CSI20/VC0, CSI20/VC1. These routing 
tables are different for most SoCs in the R-Car Gen3 family, and are 
kept inside the driver code.

So the renesas,id properly is used so that the rcar-vin driver knows 
which of the driver instances corresponds to a specific VINx number from 
the documentation so that using the media device API the correct links 
can be added and that the routing table is enforced so a user can't try 
to 

[PATCH] v4l: rcar-vin: Implement V4L2 video node release handler

[Laurent Pinchart]

The rvin_dev data structure contains driver private data for an instance
of the VIN. It is allocated dynamically at probe time, and must be freed
once all users are gone.

The structure is currently allocated with devm_kzalloc(), which results
in memory being freed when the device is unbound. If a userspace
application is currently performing an ioctl call, or just keeps the
device node open and closes it later, this will lead to accessing freed
memory.

Fix the problem by implementing a V4L2 release handler for the video
node associated with the VIN instance (called when the last user of the
video node releases it), and freeing memory explicitly from the release
handler.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 29 +++--
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  9 -
 2 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 495610949457..bd7976efa1fb 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1208,7 +1208,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
struct resource *mem;
int irq, ret;
 
-   vin = devm_kzalloc(>dev, sizeof(*vin), GFP_KERNEL);
+   vin = kzalloc(sizeof(*vin), GFP_KERNEL);
if (!vin)
return -ENOMEM;
 
@@ -1224,20 +1224,26 @@ static int rcar_vin_probe(struct platform_device *pdev)
vin->info = attr->data;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (mem == NULL)
-   return -EINVAL;
+   if (mem == NULL) {
+   ret = -EINVAL;
+   goto error_free;
+   }
 
vin->base = devm_ioremap_resource(vin->dev, mem);
-   if (IS_ERR(vin->base))
-   return PTR_ERR(vin->base);
+   if (IS_ERR(vin->base)) {
+   ret = PTR_ERR(vin->base);
+   goto error_free;
+   }
 
irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
-   return irq;
+   if (irq < 0) {
+   ret = irq;
+   goto error_free;
+   }
 
ret = rvin_dma_probe(vin, irq);
if (ret)
-   return ret;
+   goto error_free;
 
platform_set_drvdata(pdev, vin);
if (vin->info->use_mc)
@@ -1245,15 +1251,18 @@ static int rcar_vin_probe(struct platform_device *pdev)
else
ret = rvin_digital_graph_init(vin);
if (ret < 0)
-   goto error;
+   goto error_dma;
 
pm_suspend_ignore_children(>dev, true);
pm_runtime_enable(>dev);
 
return 0;
-error:
+
+error_dma:
rvin_dma_remove(vin);
v4l2_async_notifier_cleanup(>notifier);
+error_free:
+   kfree(vin);
 
return ret;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 2c14d44950b2..25f1d24c1d2d 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -1026,6 +1026,13 @@ static void rvin_notify(struct v4l2_subdev *sd,
}
 }
 
+static void rvin_v4l2_release(struct video_device *vdev)
+{
+   struct rvin_dev *vin = container_of(vdev, struct rvin_dev, vdev);
+
+   kfree(vin);
+}
+
 int rvin_v4l2_register(struct rvin_dev *vin)
 {
struct video_device *vdev = >vdev;
@@ -1038,7 +1045,7 @@ int rvin_v4l2_register(struct rvin_dev *vin)
vdev->queue = >queue;
snprintf(vdev->name, sizeof(vdev->name), "%s %s", KBUILD_MODNAME,
 dev_name(vin->dev));
-   vdev->release = video_device_release_empty;
+   vdev->release = rvin_v4l2_release;
vdev->lock = >lock;
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
-- 
Regards,

Laurent Pinchart

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[Rob Herring]

On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
> Document the devicetree bindings for the CSI-2 inputs available on Gen3.
> 
> There is a need to add a custom property 'renesas,id' and to define
> which CSI-2 input is described in which endpoint under the port@1 node.
> This information is needed since there are a set of predefined routes
> between each VIN and CSI-2 block. This routing table will be kept
> inside the driver but in order for it to act on it it must know which
> VIN and CSI-2 is which.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../devicetree/bindings/media/rcar_vin.txt | 116 
> ++---
>  1 file changed, 104 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>  ---
>  
>  The rcar_vin device provides video input capabilities for the Renesas R-Car
> -family of devices. The current blocks are always slaves and suppot one input
> -channel which can be either RGB, YUYV or BT656.
> +family of devices.
> +
> +Each VIN instance has a single parallel input that supports RGB and YUV 
> video,
> +with both external synchronization and BT.656 synchronization for the latter.
> +Depending on the instance the VIN input is connected to external SoC pins, or
> +on Gen3 to a CSI-2 receiver.
>  
>   - compatible: Must be one or more of the following
> - "renesas,vin-r8a7795" for the R8A7795 device
> @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
>  Additionally, an alias named vinX will need to be created to specify
>  which video input device this is.
>  
> -The per-board settings:
> +The per-board settings Gen2:
>   - port sub-node describing a single endpoint connected to the vin
> as described in video-interfaces.txt[1]. Only the first one will
> be considered as each vin interface has one input port.
>  
> -   These settings are used to work out video input format and widths
> -   into the system.
> +The per-board settings Gen3:
> +
> +Gen3 can support both a single connected parallel input source from
> +external SoC pins (port0) and/or multiple parallel input sources from
> +local SoC CSI-2 receivers (port1) depending on SoC.
>  
> +- renesas,id - ID number of the VIN, VINx in the documentation.

Why is this needed? We try to avoid indexes unless that's the only way a 
device is addressed (and then we use reg).

Re: [PATCH v11 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

[Rob Herring]

On Sat, Nov 11, 2017 at 01:25:25AM +0100, Niklas Söderlund wrote:
> Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> are located between the video sources (CSI-2 transmitters) and the video
> grabbers (VIN) on Gen3 of Renesas R-Car SoC.
> 
> Each CSI-2 device is connected to more then one VIN device which
> simultaneously can receive video from the same CSI-2 device. Each VIN
> device can also be connected to more then one CSI-2 device. The routing
> of which link are used are controlled by the VIN devices. There are only
> a few possible routes which are set by hardware limitations, which are
> different for each SoC in the Gen3 family.
> 
> To work with the limitations of routing possibilities it is necessary
> for the DT bindings to describe which VIN device is connected to which
> CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> VIN device that be connected to it. To setup and to know which links are
> valid for each SoC is the responsibility of the VIN driver since the
> register to configure it belongs to the VIN hardware.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../bindings/media/renesas,rcar-csi2.txt   | 104 
> +
>  MAINTAINERS|   1 +
>  2 files changed, 105 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt 
> b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> new file mode 100644
> index ..24705d8997b14a10
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> @@ -0,0 +1,104 @@
> +Renesas R-Car MIPI CSI-2
> +
> +
> +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
> +family of devices. It is to be used in conjunction with the R-Car VIN module,
> +which provides the video capture capabilities.
> +
> +Mandatory properties
> +
> + - compatible: Must be one or more of the following
> +   - "renesas,r8a7795-csi2" for the R8A7795 device.
> +   - "renesas,r8a7796-csi2" for the R8A7796 device.
> +
> + - reg: the register base and size for the device registers
> + - interrupts: the interrupt for the device
> + - clocks: Reference to the parent clock
> +
> +The device node shall contain two 'port' child nodes according to the
> +bindings defined in Documentation/devicetree/bindings/media/
> +video-interfaces.txt. Port 0 shall connect the node that is the video
> +source for to the CSI-2. Port 1 shall connect all the R-Car VIN
> +modules, which can make use of the CSI-2 module.
> +
> +- Port 0 - Video source (Mandatory)
> + - Endpoint 0 - sub-node describing the endpoint that is the video source
> +
> +- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
> + - Endpoint 0 - sub-node describing the endpoint that is VIN0
> + - Endpoint 1 - sub-node describing the endpoint that is VIN1
> + - Endpoint 2 - sub-node describing the endpoint that is VIN2
> + - Endpoint 3 - sub-node describing the endpoint that is VIN3
> + - Endpoint 4 - sub-node describing the endpoint that is VIN4
> + - Endpoint 5 - sub-node describing the endpoint that is VIN5
> + - Endpoint 6 - sub-node describing the endpoint that is VIN6
> + - Endpoint 7 - sub-node describing the endpoint that is VIN7
> +
> +Example:
> +
> + csi20: csi2@fea8 {
> + compatible = "renesas,r8a7796-csi2", "renesas,rcar-gen3-csi2";
> + reg = <0 0xfea8 0 0x1>;
> + interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < CPG_MOD 714>;
> + power-domains = < R8A7796_PD_ALWAYS_ON>;
> + resets = < 714>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0>;
> +
> + csi20_in: endpoint@0 {

unit-address without reg property is not valid.

Otherwise,

Acked-by: Rob Herring 


> + clock-lanes = <0>;
> + data-lanes = <1>;
> + remote-endpoint = <_txb>;
> + };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <1>;
> +
> + csi20vin0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <>;
> + };
> +  

Re: camss: camera controls missing on vfe interfaces

[Daniel Mack]

Todor et all,

Any hint on how to tackle this?

I can contribute patches, but I'd like to understand what the idea is.


Thanks,
Daniel


On Thursday, October 26, 2017 06:11 PM, Daniel Mack wrote:
> Hi Todor,
> 
> When using the camss driver trough one of its /dev/videoX device nodes,
> applications are currently unable to see the video controls the camera
> sensor exposes.
> 
> Same goes for other ioctls such as VIDIOC_ENUM_FMT, so the only valid
> resolution setting for applications to use is the one that was
> previously set through the media controller layer. Applications usually
> query the available formats and then pick one using the standard V4L2
> APIs, and many can't easily be forced to use a specific one.
> 
> If I'm getting this right, could you explain what's the rationale here?
> Is that simply a missing feature or was that approach chosen on purpose?
> 
> 
> Thanks,
> Daniel
> 

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Nov 15, 2017 at 7:15 PM, jacopo mondi  wrote:
> On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
>>  wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
>> > @@ -0,0 +1,87 @@
>> > +Renesas Capture Engine Unit (CEU)
>> > +--
>> > +
>> > +The Capture Engine Unit is the image capture interface found on Renesas
>> > +RZ chip series and on SH Mobile ones.
>> > +
>> > +The interface supports a single parallel input with up 8/16bits data bus 
>> > width.
>>
>> ... with data bus widths up to 8/16 bits?
>>
>> > +
>> > +Required properties:
>> > +- compatible
>> > +   Must be "renesas,renesas-ceu".
>>
>> The double "renesas" part looks odd to me. What about "renesas,ceu"?
>
> I'm totally open for better "compatible" strings here, so yeah, let's
> got for the shorter one you proposed...
>
>> Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu",
>> too?
>
> Well, I actually have no SoC-specific data in the driver, so I don't
> need SoC specific "compatible" values. But if it's a good practice
> to have them anyway, I will add those in next spin..

You don't necessarily need them in the driver, but in the bindings and DTS,
just in case a difference is discovered later.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring  wrote:
> On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.
>>
>> Cc: Hans Verkuil 
>> Signed-off-by: Tim Harvey 
>> ---
>> v3:
>>  - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
>>  - fixed missing break
>>  - use only hdmi_infoframe_log for infoframe logging
>>  - simplify tda1997x_s_stream error handling
>>  - add delayed work proc to handle hotplug enable/disable
>>  - fix set_edid (disable HPD before writing, enable after)
>>  - remove enabling edid by default
>>  - initialize timings
>>  - take quant range into account in colorspace conversion
>>  - remove vendor/product tracking (we provide this in log_status via 
>> infoframes)
>>  - add v4l_controls
>>  - add more detail to log_status
>>  - calculate vhref generator timings
>>  - timing detection fixes (rounding errors, hswidth errors)
>>  - rename configure_input/configure_conv functions
>>
>> v2:
>>  - implement dv timings enum/cap
>>  - remove deprecated g_mbus_config op
>>  - fix dv_query_timings
>>  - add EDID get/set handling
>>  - remove max-pixel-rate support
>>  - add audio codec DAI support
>>  - change audio bindings
>> ---
>>  drivers/media/i2c/Kconfig|9 +
>>  drivers/media/i2c/Makefile   |1 +
>>  drivers/media/i2c/tda1997x.c | 3485 
>> ++
>>  include/dt-bindings/media/tda1997x.h |   78 +
>
> This belongs with the binding documentation patch.
>

Rob,

Thanks - missed that. I will move it for v4.

Regarding your previous comment to the v2 series:
> The rest of the binding looks fine, but I have some reservations about
> this. I think this should be common probably. There's been a few
> bindings for display recently that deal with the interface format. Maybe
> some vendor property is needed here to map a standard interface format
> back to pin configuration.

I take it this is not an 'Ack' for the bindings?

Which did you feel should be made common? I admit I was surprised
there wasn't a common binding for audio bus format (i2s|spdif) but if
you were referring to the video data that would probably be much more
complicated.

I was hoping one of the media/driver maintainers would respond to your
comment with thoughts as I'm not familiar with a very wide variety of
receivers.

Best regards,

Tim

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

[jacopo mondi]

Hi Geert,

On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> CC devicetree folks

Yeah, sorry I forgot them. Sorry about this and thanks for adding the
address back!

>
> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
>  wrote:
> > Add bindings documentation for Renesas Capture Engine Unit (CEU).
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> > ++
> >  1 file changed, 87 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> > b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > new file mode 100644
> > index 000..a88e9cb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > @@ -0,0 +1,87 @@
> > +Renesas Capture Engine Unit (CEU)
> > +--
> > +
> > +The Capture Engine Unit is the image capture interface found on Renesas
> > +RZ chip series and on SH Mobile ones.
> > +
> > +The interface supports a single parallel input with up 8/16bits data bus 
> > width.
>
> ... with data bus widths up to 8/16 bits?
>
> > +
> > +Required properties:
> > +- compatible
> > +   Must be "renesas,renesas-ceu".
>
> The double "renesas" part looks odd to me. What about "renesas,ceu"?

I'm totally open for better "compatible" strings here, so yeah, let's
got for the shorter one you proposed...

> Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu",
> too?

Well, I actually have no SoC-specific data in the driver, so I don't
need SoC specific "compatible" values. But if it's a good practice
to have them anyway, I will add those in next spin..
>
> > +- reg
> > +   Physical address base and size.
> > +- interrupts
> > +   The interrupt line number.
>
> interrupt specifier

Yeah, it's not just the line number...

>

[snip]

> > +i2c1: i2c@fcfee400 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins>;
> > +
> > +   status = "okay";
> > +   clock-frequency = <10>;
> > +
> > +   ov7670: camera@21 {
> > +   compatible = "ovti,ov7670";
> > +   reg = <0x21>;
> > +
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins>;
> > +
> > +   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> > +   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> > +
> > +   clocks = <>;
> > +   clock-names = "xclk";
> > +
> > +   xclk: fixed_clk {
> > +   compatible = "fixed-clock";
> > +   #clock-cells = <0>;
> > +   clock-frequency = <2400>;
> > +   };

As Sakari pointed out in his review, this fixed clock is a detail
specific to the sensor used in the example (ov7670). For sake of
simplicity I can remove it.

Thanks
  j

[PATCH] v4l: sh_mobile_ceu: Return buffers on streamoff()

[Jacopo Mondi]

videobuf2 core reports an error when not all buffers have been returned
to the framework:

drivers/media/v4l2-core/videobuf2-core.c:1651
WARN_ON(atomic_read(>owned_by_drv_count))

Fix this returning all buffers currently in capture queue.

Signed-off-by: Jacopo Mondi 

---

I know I'm working to get rid of this driver, but while I was trying to have
it working again on mainline, I found this had to be fixed.

Thanks
  j

---
 drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c 
b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index 36762ec..9180a1d 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -451,13 +451,18 @@ static void sh_mobile_ceu_stop_streaming(struct vb2_queue 
*q)
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct sh_mobile_ceu_dev *pcdev = ici->priv;
struct list_head *buf_head, *tmp;
+   struct vb2_v4l2_buffer *vbuf;

spin_lock_irq(>lock);

pcdev->active = NULL;

-   list_for_each_safe(buf_head, tmp, >capture)
+   list_for_each_safe(buf_head, tmp, >capture) {
+   vbuf = _entry(buf_head, struct sh_mobile_ceu_buffer,
+  queue)->vb;
+   vb2_buffer_done(>vb2_buf, VB2_BUF_STATE_DONE);
list_del_init(buf_head);
+   }

spin_unlock_irq(>lock);

--
2.7.4

[RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

From: Gustavo Padovan 

Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers can't be queued to the
driver before its fences signal. And a buffer can't be queue to the driver
out of the order they were queued from userspace. That means that even if
it fence signal it must wait all other buffers, ahead of it in the queue,
to signal first.

To make that possible we use fence_array to keep that ordering. Basically
we create a fence_array that contains both the current fence and the fence
from the previous buffer (which might be a fence array as well). The base
fence class for the fence_array becomes the new buffer fence, waiting on
that one guarantees that it won't be queued out of order.

v6:
- With fences always keep the order userspace queues the buffers.
- Protect in_fence manipulation with a lock (Brian Starkey)
- check if fences have the same context before adding a fence array
- Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
- Clean up fence if __set_in_fence() fails (Brian Starkey)
- treat -EINVAL from dma_fence_add_callback() (Brian Starkey)

v5: - use fence_array to keep buffers ordered in vb2 core when
needed (Brian Starkey)
- keep backward compat on the reserved2 field (Brian Starkey)
- protect fence callback removal with lock (Brian Starkey)

v4:
- Add a comment about dma_fence_add_callback() not returning a
error (Hans)
- Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
- select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
- Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
- Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
-  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
vb2_start_streaming() (Hans)
- set IN_FENCE flags on __fill_v4l2_buffer (Hans)
- Queue buffers to the driver as soon as they are ready (Hans)
- call fill_user_buffer() after queuing the buffer (Hans)
- add err: label to clean up fence
- add dma_fence_wait() before calling vb2_start_streaming()

v3: - document fence parameter
- remove ternary if at vb2_qbuf() return (Mauro)
- do not change if conditions behaviour (Mauro)

v2:
- fix vb2_queue_or_prepare_buf() ret check
- remove check for VB2_MEMORY_DMABUF only (Javier)
- check num of ready buffers to start streaming
- when queueing, start from the first ready buffer
- handle queue cancel

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/Kconfig  |   1 +
 drivers/media/v4l2-core/videobuf2-core.c | 202 ---
 drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
 include/media/videobuf2-core.h   |  17 ++-
 4 files changed, 231 insertions(+), 18 deletions(-)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index a35c33686abf..3f988c407c80 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -83,6 +83,7 @@ config VIDEOBUF_DVB
 # Used by drivers that need Videobuf2 modules
 config VIDEOBUF2_CORE
select DMA_SHARED_BUFFER
+   select SYNC_FILE
tristate
 
 config VIDEOBUF2_MEMOPS
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 60f8b582396a..26de4c80717d 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -346,6 +347,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->index = q->num_buffers + buffer;
vb->type = q->type;
vb->memory = memory;
+   spin_lock_init(>fence_cb_lock);
for (plane = 0; plane < num_planes; ++plane) {
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
@@ -1222,6 +1224,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
 
+   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
+   return;
+
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(>owned_by_drv_count);
 
@@ -1273,6 +1278,23 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
return 0;
 }
 
+static int __get_num_ready_buffers(struct vb2_queue *q)
+{
+   struct vb2_buffer *vb;
+   int ready_count = 0;
+   unsigned long flags;
+
+   /* count num of buffers ready in front of the queued_list */
+   list_for_each_entry(vb, >queued_list, queued_entry) {
+   spin_lock_irqsave(>fence_cb_lock, flags);
+   if (!vb->in_fence || 

[RFC v5 04/11] [media] vivid: mark vivid queues as ordered_in_driver

[Gustavo Padovan]

From: Gustavo Padovan 

ordered_in_driver is used to optimize the use of explicit synchronization
when the driver guarantees ordering we can use the same fence context for
out-fences. In this case userspace will know that the buffers won't be
signaling out of order. vivid queues are already ordered by default so no
changes are needed.

v2: rename 'ordered' to 'ordered_in_driver' to avoid confusion.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/platform/vivid/vivid-core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index f19391fa2d6a..1b830ebe1cd8 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1068,6 +1068,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE 
:
V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vid_cap_qops;
@@ -1088,6 +1089,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE :
V4L2_BUF_TYPE_VIDEO_OUTPUT;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vid_out_qops;
@@ -1108,6 +1110,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->has_raw_vbi_cap ? V4L2_BUF_TYPE_VBI_CAPTURE :
  V4L2_BUF_TYPE_SLICED_VBI_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vbi_cap_qops;
@@ -1128,6 +1131,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->has_raw_vbi_out ? V4L2_BUF_TYPE_VBI_OUTPUT :
  V4L2_BUF_TYPE_SLICED_VBI_OUTPUT;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vbi_out_qops;
@@ -1147,6 +1151,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q = >vb_sdr_cap_q;
q->type = V4L2_BUF_TYPE_SDR_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered_in_driver = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _sdr_cap_qops;
-- 
2.13.6

[RFC v5 08/11] [media] vb2: add videobuf2 dma-buf fence helpers

[Gustavo Padovan]

From: Javier Martinez Canillas 

Add a videobuf2-fence.h header file that contains different helpers
for DMA buffer sharing explicit fence support in videobuf2.

v2: - use fence context provided by the caller in vb2_fence_alloc()

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Gustavo Padovan 
---
 include/media/videobuf2-fence.h | 48 +
 1 file changed, 48 insertions(+)
 create mode 100644 include/media/videobuf2-fence.h

diff --git a/include/media/videobuf2-fence.h b/include/media/videobuf2-fence.h
new file mode 100644
index ..b49cc1bf6bb4
--- /dev/null
+++ b/include/media/videobuf2-fence.h
@@ -0,0 +1,48 @@
+/*
+ * videobuf2-fence.h - DMA buffer sharing fence helpers for videobuf 2
+ *
+ * Copyright (C) 2016 Samsung Electronics
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+static DEFINE_SPINLOCK(vb2_fence_lock);
+
+static inline const char *vb2_fence_get_driver_name(struct dma_fence *fence)
+{
+   return "vb2_fence";
+}
+
+static inline const char *vb2_fence_get_timeline_name(struct dma_fence *fence)
+{
+   return "vb2_fence_timeline";
+}
+
+static inline bool vb2_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+static const struct dma_fence_ops vb2_fence_ops = {
+   .get_driver_name = vb2_fence_get_driver_name,
+   .get_timeline_name = vb2_fence_get_timeline_name,
+   .enable_signaling = vb2_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
+static inline struct dma_fence *vb2_fence_alloc(u64 context)
+{
+   struct dma_fence *vb2_fence = kzalloc(sizeof(*vb2_fence), GFP_KERNEL);
+
+   if (!vb2_fence)
+   return NULL;
+
+   dma_fence_init(vb2_fence, _fence_ops, _fence_lock, context, 1);
+
+   return vb2_fence;
+}
-- 
2.13.6

[RFC v5 09/11] [media] vb2: add infrastructure to support out-fences

[Gustavo Padovan]

From: Gustavo Padovan 

Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.

v3:
- Do not hold yet another ref to the out_fence (Brian Starkey)

v2: - change it to reflect fd_install at DQEVENT
- add fence context for out-fences

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/videobuf2-core.c | 28 
 include/media/videobuf2-core.h   | 20 
 2 files changed, 48 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 26de4c80717d..8b4f0e9bcb36 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -24,8 +24,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -1320,6 +1322,32 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned 
int index, void *pb)
 }
 EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
 
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
+{
+   struct vb2_buffer *vb;
+
+   vb = q->bufs[index];
+
+   vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+
+   vb->out_fence = vb2_fence_alloc(q->out_fence_context);
+   if (!vb->out_fence) {
+   put_unused_fd(vb->out_fence_fd);
+   return -ENOMEM;
+   }
+
+   vb->sync_file = sync_file_create(vb->out_fence);
+   if (!vb->sync_file) {
+   put_unused_fd(vb->out_fence_fd);
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_setup_out_fence);
+
 /**
  * vb2_start_streaming() - Attempt to start streaming.
  * @q: videobuf2 queue
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 5f48c7be7770..a9b0697bd782 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -259,6 +259,10 @@ struct vb2_buffer {
 *  using the buffer (queueing to the driver)
 * fence_cb:fence callback information
 * fence_cb_lock:   protect callback signal/remove
+* out_fence_fd:the out_fence_fd to be shared with userspace.
+* out_fence:   the out-fence associated with the buffer once
+*  it is queued to the driver.
+* sync_file:   the sync file to wrap the out fence
 */
enum vb2_buffer_state   state;
 
@@ -269,6 +273,10 @@ struct vb2_buffer {
struct dma_fence_cb fence_cb;
spinlock_t  fence_cb_lock;
 
+   int out_fence_fd;
+   struct dma_fence*out_fence;
+   struct sync_file*sync_file;
+
 #ifdef CONFIG_VIDEO_ADV_DEBUG
/*
 * Counters for how often these buffer-related ops are
@@ -514,6 +522,7 @@ struct vb2_buf_ops {
  * @last_buffer_dequeued: used in poll() and DQBUF to immediately return if the
  * last decoded buffer was already dequeued. Set for capture queues
  * when a buffer with the V4L2_BUF_FLAG_LAST is dequeued.
+ * @out_fence_context: the fence context for the out fences
  * @last_fence:last in-fence received. Used to keep ordering.
  * @fileio:file io emulator internal data, used only if emulator is active
  * @threadio:  thread io internal data, used only if thread is active
@@ -569,6 +578,7 @@ struct vb2_queue {
unsigned intcopy_timestamp:1;
unsigned intlast_buffer_dequeued:1;
 
+   u64 out_fence_context;
struct dma_fence*last_fence;
 
struct vb2_fileio_data  *fileio;
@@ -740,6 +750,16 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
vb2_memory memory,
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb);
 
 /**
+ * vb2_setup_out_fence() - setup new out-fence
+ * @q: The vb2_queue where to setup it
+ * @index: index of the buffer
+ *
+ * Setup the file descriptor, the fence and the sync_file for the next
+ * buffer to be queued and add everything to the tail of the q->out_fence_list.
+ */
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index);
+
+/**
  * vb2_core_qbuf() - Queue a buffer from userspace
  *
  * @q: videobuf2 queue
-- 
2.13.6

[RFC v5 11/11] [media] v4l: Document explicit synchronization behavior

[Gustavo Padovan]

From: Gustavo Padovan 

Add section to VIDIOC_QBUF about it

v4:
- Document ordering behavior for in-fences
- Document V4L2_CAP_ORDERED capability
- Remove doc about OUT_FENCE event
- Document immediate return of out-fence in QBUF

v3:
- make the out_fence refer to the current buffer (Hans)
- Note what happens when the IN_FENCE is not set (Hans)

v2:
- mention that fences are files (Hans)
- rework for the new API

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/vidioc-qbuf.rst | 42 +++-
 Documentation/media/uapi/v4l/vidioc-querybuf.rst |  9 -
 2 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
index 9e448a4aa3aa..040709256ab6 100644
--- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
@@ -54,7 +54,7 @@ When the buffer is intended for output (``type`` is
 or ``V4L2_BUF_TYPE_VBI_OUTPUT``) applications must also initialize the
 ``bytesused``, ``field`` and ``timestamp`` fields, see :ref:`buffer`
 for details. Applications must also set ``flags`` to 0. The
-``reserved2`` and ``reserved`` fields must be set to 0. When using the
+``reserved`` field must be set to 0. When using the
 :ref:`multi-planar API `, the ``m.planes`` field must
 contain a userspace pointer to a filled-in array of struct
 :c:type:`v4l2_plane` and the ``length`` field must be set
@@ -118,6 +118,46 @@ immediately with an ``EAGAIN`` error code when no buffer 
is available.
 The struct :c:type:`v4l2_buffer` structure is specified in
 :ref:`buffer`.
 
+Explicit Synchronization
+
+
+Explicit Synchronization allows us to control the synchronization of
+shared buffers from userspace by passing fences to the kernel and/or
+receiving them from it. Fences passed to the kernel are named in-fences and
+the kernel should wait on them to signal before using the buffer, i.e., 
queueing
+it to the driver. On the other side, the kernel can create out-fences for the
+buffers it queues to the drivers. Out-fences signal when the driver is
+finished with buffer, i.e., the buffer is ready. The fences are represented
+as a file and passed as a file descriptor to userspace.
+
+The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
+using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer flag and the `fence_fd` field. If
+an in-fence needs to be passed to the kernel, `fence_fd` should be set to the
+fence file descriptor number and the ``V4L2_BUF_FLAG_IN_FENCE`` should be set
+as well. Setting one but not the other will cause ``VIDIOC_QBUF`` to return
+with error. The fence_fd field will be ignored if the
+``V4L2_BUF_FLAG_IN_FENCE`` is not set.
+
+The videobuf2-core will guarantee that all buffers queued with in-fence will
+be queued to the drivers in the same order. Fence may signal out of order, so
+this guarantee at videobuf2 is necessary to not change ordering.
+
+To get an out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag should
+be set to ask for a fence to be attached to the buffer. The out-fence fd is
+sent to userspace as a ``VIDIOC_QBUF`` return argument on the `fence_fd` field.
+
+Note the the same `fence_fd` field is used for both sending the in-fence as
+input argument to receive the out-fence as a return argument.
+
+At streamoff the out-fences will either signal normally if the driver waits
+for the operations on the buffers to finish or signal with an error if the
+driver cancels the pending operations. Buffers with in-fences won't be queued
+to the driver if their fences signal. It will be cleaned up.
+
+A capability flag, ``V4L2_CAP_ORDERED``, tells userspace that the current
+buffer queues is able to keep the ordering of buffers, i.e., the dequeing of
+buffers will happen at the same order we queue them, with no reordering by
+the driver.
 
 Return Value
 
diff --git a/Documentation/media/uapi/v4l/vidioc-querybuf.rst 
b/Documentation/media/uapi/v4l/vidioc-querybuf.rst
index dd54747fabc9..df964c4d916b 100644
--- a/Documentation/media/uapi/v4l/vidioc-querybuf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querybuf.rst
@@ -44,7 +44,7 @@ and the ``index`` field. Valid index numbers range from zero 
to the
 number of buffers allocated with
 :ref:`VIDIOC_REQBUFS` (struct
 :c:type:`v4l2_requestbuffers` ``count``) minus
-one. The ``reserved`` and ``reserved2`` fields must be set to 0. When
+one. The ``reserved`` field must be set to 0. When
 using the :ref:`multi-planar API `, the ``m.planes``
 field must contain a userspace pointer to an array of struct
 :c:type:`v4l2_plane` and the ``length`` field has to be set
@@ -64,6 +64,13 @@ elements will be used instead and the ``length`` field of 
struct
 array elements. The driver may or may not set the remaining fields and
 flags, 

[RFC v5 01/11] [media] v4l: add V4L2_CAP_ORDERED to the uapi

[Gustavo Padovan]

From: Gustavo Padovan 

When using explicit synchronization userspace needs to know if
the queue can deliver everything back in the same order, so we added
a new capability that drivers can use to report that they are capable
of keeping ordering.

In videobuf2 core when using fences we also make sure to keep the ordering
of buffers, so if the driver guarantees it too the whole pipeline inside
V4L2 will be ordered and the V4L2_CAP_ORDERED should be used.

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 +++
 include/uapi/linux/videodev2.h   | 1 +
 2 files changed, 4 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 66fb1b3d6e6e..ed3daa814da9 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -254,6 +254,9 @@ specification the ioctl returns an ``EINVAL`` error code.
 * - ``V4L2_CAP_TOUCH``
   - 0x1000
   - This is a touch device.
+* - ``V4L2_CAP_ORDERED``
+  - 0x2000
+  - The device queue is ordered.
 * - ``V4L2_CAP_DEVICE_CAPS``
   - 0x8000
   - The driver fills the ``device_caps`` field. This capability can
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 185d6a0acc06..cd6fc1387f47 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -459,6 +459,7 @@ struct v4l2_capability {
 #define V4L2_CAP_STREAMING  0x0400  /* streaming I/O ioctls */
 
 #define V4L2_CAP_TOUCH  0x1000  /* Is a touch device */
+#define V4L2_CAP_ORDERED0x2000  /* Is the device queue 
ordered */
 
 #define V4L2_CAP_DEVICE_CAPS0x8000  /* sets device 
capabilities field */
 
-- 
2.13.6

[RFC v5 10/11] [media] vb2: add out-fence support to QBUF

[Gustavo Padovan]

From: Gustavo Padovan 

If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and send its fd to userspace on the fence_fd field as a
return arg for the QBUF call.

The fence is signaled on buffer_done(), when the job on the buffer is
finished.

With out-fences we do not allow drivers to requeue buffers through vb2,
instead we flag an error on the buffer, signals it fence with error and
return it to userspace.

v6
- get rid of the V4L2_EVENT_OUT_FENCE event. We always keep the
ordering in vb2 for queueing in the driver, so the event is not
necessary anymore and the out_fence_fd is sent back to userspace
on QBUF call return arg
- do not allow requeueing with out-fences, instead mark the buffer
with an error and wake up to userspace.
- send the out_fence_fd back to userspace on the fence_fd field

v5:
- delay fd_install to DQ_EVENT (Hans)
- if queue is fully ordered send OUT_FENCE event right away
(Brian)
- rename 'q->ordered' to 'q->ordered_in_driver'
- merge change to implement OUT_FENCE event here

v4:
- return the out_fence_fd in the BUF_QUEUED event(Hans)

v3: - add WARN_ON_ONCE(q->ordered) on requeueing (Hans)
- set the OUT_FENCE flag if there is a fence pending (Hans)
- call fd_install() after vb2_core_qbuf() (Hans)
- clean up fence if vb2_core_qbuf() fails (Hans)
- add list to store sync_file and fence for the next queued buffer

v2: check if the queue is ordered.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/videobuf2-core.c | 42 +---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 21 +++-
 2 files changed, 58 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 8b4f0e9bcb36..2eb5ffa8e028 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -354,6 +354,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
}
+   vb->out_fence_fd = -1;
q->bufs[vb->index] = vb;
 
/* Allocate video buffer memory for the MMAP type */
@@ -934,10 +935,26 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
case VB2_BUF_STATE_QUEUED:
return;
case VB2_BUF_STATE_REQUEUEING:
-   if (q->start_streaming_called)
-   __enqueue_in_driver(vb);
-   return;
+
+   if (!vb->out_fence) {
+   if (q->start_streaming_called)
+   __enqueue_in_driver(vb);
+   return;
+   }
+
+   /* Do not allow requeuing with explicit synchronization,
+* report it as an error to userspace */
+   state = VB2_BUF_STATE_ERROR;
+
+   /* fall through */
default:
+   if (state == VB2_BUF_STATE_ERROR)
+   dma_fence_set_error(vb->out_fence, -EFAULT);
+   dma_fence_signal(vb->out_fence);
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   vb->out_fence_fd = -1;
+
/* Inform any processes that may be waiting for buffers */
wake_up(>done_wq);
break;
@@ -1325,12 +1342,18 @@ EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
 int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
 {
struct vb2_buffer *vb;
+   u64 context;
 
vb = q->bufs[index];
 
vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
 
-   vb->out_fence = vb2_fence_alloc(q->out_fence_context);
+   if (q->ordered_in_driver)
+   context = q->out_fence_context;
+   else
+   context = dma_fence_context_alloc(1);
+
+   vb->out_fence = vb2_fence_alloc(context);
if (!vb->out_fence) {
put_unused_fd(vb->out_fence_fd);
return -ENOMEM;
@@ -1594,6 +1617,9 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb,
if (pb)
call_void_bufop(q, fill_user_buffer, vb, pb);
 
+   fd_install(vb->out_fence_fd, vb->sync_file->file);
+   vb->sync_file = NULL;
+
dprintk(2, "qbuf of buffer %d succeeded\n", vb->index);
return 0;
 
@@ -1860,6 +1886,12 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
}
 
/*
+* Renew out-fence context.
+*/
+   if (q->ordered_in_driver)
+   q->out_fence_context = dma_fence_context_alloc(1);
+
+   /*
 * Remove all buffers from videobuf's list...
 

[RFC v5 02/11] [media] vivid: add the V4L2_CAP_ORDERED capability

[Gustavo Padovan]

From: Gustavo Padovan 

vivid guarantees the ordering of buffer when processing then, so add the
V4L2_CAP_ORDERED capability to inform userspace of that.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/platform/vivid/vivid-core.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index 5f316a5e38db..f19391fa2d6a 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -801,7 +801,8 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
dev->vid_cap_caps = dev->multiplanar ?
V4L2_CAP_VIDEO_CAPTURE_MPLANE :
V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OVERLAY;
-   dev->vid_cap_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
+   dev->vid_cap_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE |
+V4L2_CAP_ORDERED;
if (dev->has_audio_inputs)
dev->vid_cap_caps |= V4L2_CAP_AUDIO;
if (in_type_counter[TV])
@@ -814,7 +815,8 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
V4L2_CAP_VIDEO_OUTPUT;
if (dev->has_fb)
dev->vid_out_caps |= V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
-   dev->vid_out_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
+   dev->vid_out_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE |
+V4L2_CAP_ORDERED;
if (dev->has_audio_outputs)
dev->vid_out_caps |= V4L2_CAP_AUDIO;
}
@@ -822,7 +824,8 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
/* set up the capabilities of the vbi capture device */
dev->vbi_cap_caps = (dev->has_raw_vbi_cap ? 
V4L2_CAP_VBI_CAPTURE : 0) |
(dev->has_sliced_vbi_cap ? 
V4L2_CAP_SLICED_VBI_CAPTURE : 0);
-   dev->vbi_cap_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
+   dev->vbi_cap_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE |
+V4L2_CAP_ORDERED;
if (dev->has_audio_inputs)
dev->vbi_cap_caps |= V4L2_CAP_AUDIO;
if (in_type_counter[TV])
@@ -832,24 +835,26 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
/* set up the capabilities of the vbi output device */
dev->vbi_out_caps = (dev->has_raw_vbi_out ? V4L2_CAP_VBI_OUTPUT 
: 0) |
(dev->has_sliced_vbi_out ? 
V4L2_CAP_SLICED_VBI_OUTPUT : 0);
-   dev->vbi_out_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
+   dev->vbi_out_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE |
+V4L2_CAP_ORDERED;
if (dev->has_audio_outputs)
dev->vbi_out_caps |= V4L2_CAP_AUDIO;
}
if (dev->has_sdr_cap) {
/* set up the capabilities of the sdr capture device */
dev->sdr_cap_caps = V4L2_CAP_SDR_CAPTURE | V4L2_CAP_TUNER;
-   dev->sdr_cap_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
+   dev->sdr_cap_caps |= V4L2_CAP_STREAMING | V4L2_CAP_READWRITE |
+V4L2_CAP_ORDERED;
}
/* set up the capabilities of the radio receiver device */
if (dev->has_radio_rx)
dev->radio_rx_caps = V4L2_CAP_RADIO | V4L2_CAP_RDS_CAPTURE |
 V4L2_CAP_HW_FREQ_SEEK | V4L2_CAP_TUNER |
-V4L2_CAP_READWRITE;
+V4L2_CAP_READWRITE | V4L2_CAP_ORDERED;
/* set up the capabilities of the radio transmitter device */
if (dev->has_radio_tx)
dev->radio_tx_caps = V4L2_CAP_RDS_OUTPUT | V4L2_CAP_MODULATOR |
-V4L2_CAP_READWRITE;
+V4L2_CAP_READWRITE | V4L2_CAP_ORDERED;
 
ret = -ENOMEM;
/* initialize the test pattern generator */
-- 
2.13.6

[RFC v5 05/11] [media] vb2: check earlier if stream can be started

[Gustavo Padovan]

From: Gustavo Padovan 

To support explicit synchronization we need to run all operations that can
fail before we queue the buffer to the driver. With fences the queueing
will be delayed if the fence is not signaled yet and it will be better if
such callback do not fail.

For that we move the vb2_start_streaming() before the queuing for the
buffer may happen.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/videobuf2-core.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index cb115ba6a1d2..60f8b582396a 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1399,29 +1399,27 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
trace_vb2_qbuf(q, vb);
 
/*
-* If already streaming, give the buffer to driver for processing.
-* If not, the buffer will be given to driver on next streamon.
-*/
-   if (q->start_streaming_called)
-   __enqueue_in_driver(vb);
-
-   /* Fill buffer information for the userspace */
-   if (pb)
-   call_void_bufop(q, fill_user_buffer, vb, pb);
-
-   /*
 * If streamon has been called, and we haven't yet called
 * start_streaming() since not enough buffers were queued, and
 * we now have reached the minimum number of queued buffers,
 * then we can finally call start_streaming().
+*
+* If already streaming, give the buffer to driver for processing.
+* If not, the buffer will be given to driver on next streamon.
 */
if (q->streaming && !q->start_streaming_called &&
q->queued_count >= q->min_buffers_needed) {
ret = vb2_start_streaming(q);
if (ret)
return ret;
+   } else if (q->start_streaming_called) {
+   __enqueue_in_driver(vb);
}
 
+   /* Fill buffer information for the userspace */
+   if (pb)
+   call_void_bufop(q, fill_user_buffer, vb, pb);
+
dprintk(2, "qbuf of buffer %d succeeded\n", vb->index);
return 0;
 }
-- 
2.13.6

[RFC v5 06/11] [media] vb2: add explicit fence user API

[Gustavo Padovan]

From: Gustavo Padovan 

Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel and return an out-fence from the kernel to
userspace.

Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending a fence to the kernel to be waited on, and
V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.

v4:
- make it a union with reserved2 and fence_fd (Hans Verkuil)

v3:
- make the out_fence refer to the current buffer (Hans Verkuil)

v2: add documentation

Signed-off-by: Gustavo Padovan 
---
 Documentation/media/uapi/v4l/buffer.rst   | 15 +++
 drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
 include/uapi/linux/videodev2.h|  7 ++-
 5 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ae6ee73f151c..eeefbd2547e7 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -648,6 +648,21 @@ Buffer Flags
   - Start Of Exposure. The buffer timestamp has been taken when the
exposure of the frame has begun. This is only valid for the
``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
+* .. _`V4L2-BUF-FLAG-IN-FENCE`:
+
+  - ``V4L2_BUF_FLAG_IN_FENCE``
+  - 0x0020
+  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
+   won't be queued to the driver until the fence signals.
+
+* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
+
+  - ``V4L2_BUF_FLAG_OUT_FENCE``
+  - 0x0040
+  - Request a fence to be attached to the buffer. The ``fence_fd``
+   field on
+   :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
+   fd to userspace.
 
 
 
diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
b/drivers/media/usb/cpia2/cpia2_v4l.c
index 3dedd83f0b19..6cde686bf44c 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct 
v4l2_buffer *buf)
buf->sequence = cam->buffers[buf->index].seq;
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
buf->length = cam->frame_size;
-   buf->reserved2 = 0;
+   buf->fence_fd = -1;
buf->reserved = 0;
memset(>timecode, 0, sizeof(buf->timecode));
 
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 821f2aa299ae..3a31d318df2a 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -370,7 +370,7 @@ struct v4l2_buffer32 {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -533,7 +533,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, struct 
v4l2_buffer32 __user
put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
copy_to_user(>timecode, >timecode, sizeof(struct 
v4l2_timecode)) ||
put_user(kp->sequence, >sequence) ||
-   put_user(kp->reserved2, >reserved2) ||
+   put_user(kp->fence_fd, >fence_fd) ||
put_user(kp->reserved, >reserved) ||
put_user(kp->length, >length))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 0c0669976bdc..110fb45fef6f 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->reserved2 = 0;
+   b->fence_fd = -1;
b->reserved = 0;
 
if (q->is_multiplanar) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index cd6fc1387f47..311c3a331eda 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -925,7 +925,10 @@ struct v4l2_buffer {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   union {
+   __s32   fence_fd;
+   __u32   reserved2;
+   };
__u32   reserved;
 };
 
@@ -962,6 +965,8 @@ struct v4l2_buffer {
 #define V4L2_BUF_FLAG_TSTAMP_SRC_SOE   0x0001
 /* mem2mem encoder/decoder */
 #define V4L2_BUF_FLAG_LAST 0x0010
+#define V4L2_BUF_FLAG_IN_FENCE 0x0020

[RFC v5 03/11] [media] vb2: add 'ordered_in_driver' property to queues

[Gustavo Padovan]

From: Gustavo Padovan 

We use ordered_in_driver property to optimize for the case where
the driver can deliver the buffers in an ordered fashion. When it
is ordered we can use the same fence context for all fences, but
when it is not we need to a new context for each out-fence.

So the ordered_in_driver flag will help us with identifying the queues
that can be optimized and use the same fence context.

v4: make the property a vector for optimization and not a mandatory thing
that drivers need to set if they want to use explicit synchronization.

v3: improve doc (Hans Verkuil)

v2: rename property to 'ordered_in_driver' to avoid confusion

Signed-off-by: Gustavo Padovan 
---
 include/media/videobuf2-core.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index ef9b64398c8c..38b9c8dd42c6 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -440,6 +440,12 @@ struct vb2_buf_ops {
  * @fileio_read_once:  report EOF after reading the first buffer
  * @fileio_write_immediately:  queue buffer after each write() call
  * @allow_zero_bytesused:  allow bytesused == 0 to be passed to the driver
+ * @ordered_in_driver: if the driver can guarantee that the queue will be
+ * ordered or not, i.e., the buffers are dequeued from the driver
+ * in the same order they are queued to the driver. The default
+ * is not ordered unless the driver sets this flag. Setting it
+ * when ordering can be guaranted helps to optimize explicit
+ * fences.
  * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when QBUF
  *  has not been called. This is a vb1 idiom that has been adopted
  *  also by vb2.
@@ -510,6 +516,7 @@ struct vb2_queue {
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;
+   unsignedordered_in_driver:1;
unsigned   quirk_poll_must_check_waiting_for_buffers:1;
 
struct mutex*lock;
-- 
2.13.6

[RFC v5 00/11] V4L2 Explicit Synchronization

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

After the comments received in the last patchset[1] and 
during the media summit [2] here is the new and improved version
of the patchset. The implementation is simpler, smaller and cover
a lot more cases.

If you look to the last patchset I got rid of a few things, the main
one is the OUT_FENCE event, one thing that we decided in Prague was
that, when using fences, we would keep ordering of all buffers queued
to vb2. That means they would be queued to the drivers in the same order
that the QBUF calls happen, just like it already happens when not using
fences. Fences can signal in whatever order, so we need this guarantee
here. Drivers can, however, not keep ordering when processing the
buffers.

But there is one conclusion of that that we didn't reached at the
summit, maybe because of the order we discussed things, and that is: we do
not need the OUT_FENCE event anymore, because now at the QBUF call time
we *always* know the order in which the buffers will be queued to the
v4l2 driver. So the out-fence fd is now returned using the fence_fd
field as a return argument, thus the event is not necessary anymore.

The fence_fd field is now used to comunicate both in-fences and
out-fences, just like we do for GPU drivers. We pass in-fences as input
arguments and get out-fences as return arguments on the QBUF call.
The approach is documented.

I also added a capability flag, V4L2_CAP_ORDERED, to tell userspace if
the v4l2 drivers keep the buffers ordered or not. 

We still have the 'ordered_in_driver' property for queues, but its
meaning has changed. When set videobuf2 will know that the driver can
keep the order of the buffers, thus videobuf2 can use the same fence
context for all out-fences. Fences inside the same context should signal
in order, so 'ordered_in_driver' is a optimization for that case.
When not set, a context for each out-fence is created.

So now explicit synchronization also works for drivers that do not keep
the ordering of buffers.

Another thing is that we do not allow videobuf2 to requeue buffers
internally when using fences, they have a fence associated to it and
we need to finish the job on them, i.e., signal the fence, even if an
error happened.

The rest of the changes are documented in each patch separated.

There a test app at:

https://gitlab.collabora.com/padovan/v4l2-fences-test

Among my next steps is to create a v4l2->drm test app using fences as a
PoC, and also look into how to support it in ChromeOS.

Open Questions
--

* Do drivers reorder buffers internally? How to handle that with fences?

* How to handle audio/video syncronization? Fences aren't enough, we  need 
  to know things like the start of capture timestamp.

Regards,

Gustavo
--

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1518928.html
[2] http://muistio.tieke.fi/p/media-summit-2017

Gustavo Padovan (10):
  [media] v4l: add V4L2_CAP_ORDERED to the uapi
  [media] vivid: add the V4L2_CAP_ORDERED capability
  [media] vb2: add 'ordered_in_driver' property to queues
  [media] vivid: mark vivid queues as ordered_in_driver
  [media] vb2: check earlier if stream can be started
  [media] vb2: add explicit fence user API
  [media] vb2: add in-fence support to QBUF
  [media] vb2: add infrastructure to support out-fences
  [media] vb2: add out-fence support to QBUF
  [media] v4l: Document explicit synchronization behavior

Javier Martinez Canillas (1):
  [media] vb2: add videobuf2 dma-buf fence helpers

 Documentation/media/uapi/v4l/buffer.rst  |  15 ++
 Documentation/media/uapi/v4l/vidioc-qbuf.rst |  42 +++-
 Documentation/media/uapi/v4l/vidioc-querybuf.rst |   9 +-
 Documentation/media/uapi/v4l/vidioc-querycap.rst |   3 +
 drivers/media/platform/vivid/vivid-core.c|  24 +-
 drivers/media/usb/cpia2/cpia2_v4l.c  |   2 +-
 drivers/media/v4l2-core/Kconfig  |   1 +
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c|   4 +-
 drivers/media/v4l2-core/videobuf2-core.c | 274 +--
 drivers/media/v4l2-core/videobuf2-v4l2.c |  48 +++-
 include/media/videobuf2-core.h   |  44 +++-
 include/media/videobuf2-fence.h  |  48 
 include/uapi/linux/videodev2.h   |   8 +-
 13 files changed, 485 insertions(+), 37 deletions(-)
 create mode 100644 include/media/videobuf2-fence.h

-- 
2.13.6

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

[Niklas Söderlund]

Hi,

I just noticed I made a small mistake in this patch, see bellow. I will 
send out a new version in a few days with this fix included but I don't 
want to spam the list too much so I give it a few more days if there is 
any other feedback.

On 2017-11-11 01:25:26 +0100, Niklas Söderlund wrote:
> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> hardware blocks are connected between the video sources and the video
> grabbers (VIN).
> 
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/Kconfig |  12 +
>  drivers/media/platform/rcar-vin/Makefile|   1 +
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 896 
> 
>  3 files changed, 909 insertions(+)
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> 
> diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> b/drivers/media/platform/rcar-vin/Kconfig
> index af4c98b44d2e22cb..6875f30c1ae42631 100644
> --- a/drivers/media/platform/rcar-vin/Kconfig
> +++ b/drivers/media/platform/rcar-vin/Kconfig
> @@ -1,3 +1,15 @@
> +config VIDEO_RCAR_CSI2
> + tristate "R-Car MIPI CSI-2 Receiver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> + depends on ARCH_RENESAS || COMPILE_TEST
> + select V4L2_FWNODE
> + ---help---
> +   Support for Renesas R-Car MIPI CSI-2 receiver.
> +   Supports R-Car Gen3 SoCs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called rcar-csi2.
> +
>  config VIDEO_RCAR_VIN
>   tristate "R-Car Video Input (VIN) Driver"
>   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> MEDIA_CONTROLLER
> diff --git a/drivers/media/platform/rcar-vin/Makefile 
> b/drivers/media/platform/rcar-vin/Makefile
> index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> --- a/drivers/media/platform/rcar-vin/Makefile
> +++ b/drivers/media/platform/rcar-vin/Makefile
> @@ -1,3 +1,4 @@
>  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
>  
> +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
>  obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> new file mode 100644
> index ..4202c60b4d0aa7f7
> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -0,0 +1,896 @@
> +/*
> + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> + *
> + * Copyright (C) 2017 Renesas Electronics Corp.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets and bits */
> +
> +/* Control Timing Select */
> +#define TREF_REG 0x00
> +#define TREF_TREFBIT(0)
> +
> +/* Software Reset */
> +#define SRST_REG 0x04
> +#define SRST_SRSTBIT(0)
> +
> +/* PHY Operation Control */
> +#define PHYCNT_REG   0x08
> +#define PHYCNT_SHUTDOWNZ BIT(17)
> +#define PHYCNT_RSTZ  BIT(16)
> +#define PHYCNT_ENABLECLK BIT(4)
> +#define PHYCNT_ENABLE_3  BIT(3)
> +#define PHYCNT_ENABLE_2  BIT(2)
> +#define PHYCNT_ENABLE_1  BIT(1)
> +#define PHYCNT_ENABLE_0  BIT(0)
> +
> +/* Checksum Control */
> +#define CHKSUM_REG   0x0c
> +#define CHKSUM_ECC_ENBIT(1)
> +#define CHKSUM_CRC_ENBIT(0)
> +
> +/*
> + * Channel Data Type Select
> + * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
> + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
> + */
> +#define VCDT_REG 0x10
> +#define VCDT2_REG0x14
> +#define VCDT_VCDTN_ENBIT(15)
> +#define VCDT_SEL_VC(n)   (((n) & 0x3) << 8)
> +#define VCDT_SEL_DTN_ON  BIT(6)
> +#define VCDT_SEL_DT(n)   (((n) & 0x3f) << 0)
> +
> +/* Frame Data Type Select */
> +#define FRDT_REG 0x18
> +
> +/* Field Detection Control */
> +#define FLD_REG  0x1c
> +#define FLD_FLD_NUM(n)   (((n) & 0xff) << 16)
> +#define FLD_FLD_EN4  BIT(3)
> +#define FLD_FLD_EN3  BIT(2)
> +#define FLD_FLD_EN2  BIT(1)
> +#define FLD_FLD_EN   BIT(0)
> +
> +/* Automatic Standby 

Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver

[Rob Herring]

On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote:
> Add support for the TDA1997x HDMI receivers.
> 
> Cc: Hans Verkuil 
> Signed-off-by: Tim Harvey 
> ---
> v3:
>  - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
>  - fixed missing break
>  - use only hdmi_infoframe_log for infoframe logging
>  - simplify tda1997x_s_stream error handling
>  - add delayed work proc to handle hotplug enable/disable
>  - fix set_edid (disable HPD before writing, enable after)
>  - remove enabling edid by default
>  - initialize timings
>  - take quant range into account in colorspace conversion
>  - remove vendor/product tracking (we provide this in log_status via 
> infoframes)
>  - add v4l_controls
>  - add more detail to log_status
>  - calculate vhref generator timings
>  - timing detection fixes (rounding errors, hswidth errors)
>  - rename configure_input/configure_conv functions
> 
> v2:
>  - implement dv timings enum/cap
>  - remove deprecated g_mbus_config op
>  - fix dv_query_timings
>  - add EDID get/set handling
>  - remove max-pixel-rate support
>  - add audio codec DAI support
>  - change audio bindings
> ---
>  drivers/media/i2c/Kconfig|9 +
>  drivers/media/i2c/Makefile   |1 +
>  drivers/media/i2c/tda1997x.c | 3485 
> ++
>  include/dt-bindings/media/tda1997x.h |   78 +

This belongs with the binding documentation patch.

>  include/media/i2c/tda1997x.h |   53 +
>  5 files changed, 3626 insertions(+)
>  create mode 100644 drivers/media/i2c/tda1997x.c
>  create mode 100644 include/dt-bindings/media/tda1997x.h
>  create mode 100644 include/media/i2c/tda1997x.h

[PATCH] v4l: async: use the v4l2_dev from the root notifier when matching sub-devices

[Niklas Söderlund]

When matching and registering a sub-device from a sub-notifier use the
v4l2_device from the root parent notifier. Using the v4l2_dev stored in
the sub-notifier itself is incorrect as it might not be set.

This can be demonstrated by unbinding and rebinding the adv748x driver
and observing that it fails to probe due to the check !v4l2_dev in
v4l2_device_register_subdev().

# echo 4-0070 > /sys/bus/i2c/drivers/adv748x/unbind
# echo 4-0070 > /sys/bus/i2c/drivers/adv748x/bind
adv748x 4-0070: chip found @ 0xe0 revision 2143
adv748x 4-0070: Failed to probe TXA
adv748x: probe of 4-0070 failed with error -22

Looking at the commit which adds sub-notifiers to V4L2 it looks like
this is the intended behavior of the original commit. Whit this fix the
adv748x can be re-bound and still function properly.

Fixes: 2cab00bb076b9f0e ("media: v4l: async: Allow binding notifiers to 
sub-devices")
Signed-off-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-async.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index a7c3464976f24361..e5acfab470a5ee6b 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -558,8 +558,7 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
if (!asd)
continue;
 
-   ret = v4l2_async_match_notify(notifier, notifier->v4l2_dev, sd,
- asd);
+   ret = v4l2_async_match_notify(notifier, v4l2_dev, sd, asd);
if (ret)
goto err_unbind;
 
-- 
2.15.0

Re: [RFC PATCH 0/5] Rockchip ISP1 Driver

[Jacob Chen]

Hi Tomasz,

2017-11-15 16:03 GMT+08:00 Tomasz Figa :
> Hi Jacob,
>
> Thanks for sending the series!
>
> On Wed, Nov 15, 2017 at 3:29 PM, Jacob Chen  wrote:
>> This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399 
>> SoC.
>>
>> TODO:
>>   - Thomas is rewriting the binding code between isp, phy, sensors, i hope 
>> we could get suggestions.
>> 
>> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/768633/2
>> rules:
>>   - There are many mipi interfaces("rx0", "dxrx0")(actually it also 
>> could be parallel interface) in SoC and isp can decide which one will be 
>> used.
>>   - Sometimes there will be more than one senor in a mipi phy, the 
>> sofrware should decide which one is used(media link).
>>   - rk3399 have two isp.
>
> Also the two ISP subsystems have their own, completely different, CSI2
> PHY blocks, so we need to make the ISP driver work with two different
> PHY drivers.
>
>>   - Add a dummy buffer(dma_alloc_coherent) so drvier won't hold buffer.
>>   - Finish all TODO comments(mostly about hardware) in driver.
>>
>> To help do a quick review, i have push source code to my Github.
>>   
>> https://github.com/wzyy2/linux/tree/rkisp1/drivers/media/platform/rockchip/isp1
>>
>> Below are some infomations about driver/hardware:
>>
>> Rockchip ISP1 have many Hardware Blocks(simplied):
>>
>>   MIPI  --> ISP --> DCrop(Mainpath) --> RSZ(Mainpath) --> DMA(Mainpath)
>>   DMA-Input --> --> DCrop(Selfpath) --> RSZ(Selfpath) --> DMA(Selfpath);)
>>
>> (Acutally the TRM(rk3288, isp) could be found online.. which contains a 
>> more detailed block diagrams ;-P)
>>
>> The funcitons of each hardware block:
>>
>>   Mainpath : up to 4k resolution, support raw/yuv format
>>   Selfpath : up tp 1080p, support rotate, support rgb/yuv format
>>   RSZ: scaling
>>   DCrop: crop
>>   ISP: 3A, Color processing, Crop
>>   MIPI: MIPI Camera interface
>>
>> Media pipelines:
>>
>>   Mainpath, Selfpath <-- ISP subdev <-- MIPI  <-- Sensor
>>   3A stats   <--<-- 3A parms
>>
>> Code struct:
>>
>>   capture.c : Mainpath, Selfpath, RSZ, DCROP : capture device.
>>   rkisp1.c : ISP : v4l2 sub-device.
>>   isp_params.c : 3A parms : output device.
>>   isp_stats.c : 3A stats : capture device.
>>   mipi_dphy_sy.c : MIPI : sperated v4l2 sub-device.
>>
>> Usage:
>>   ChromiumOS:
>> use below v4l2-ctl command to capture frames.
>>
>>   v4l2-ctl --verbose -d /dev/video4 --stream-mmap=2
>>   --stream-to=/tmp/stream.out --stream-count=60 --stream-poll
>>
>> use below command to playback the video on your PC.
>>
>>   mplayer /tmp/stream.out -loop 0 --demuxer=rawvideo
>>   --rawvideo=w=800:h=600:size=$((800*600*2)):format=yuy2
>> or
>>   mplayer ./stream.out -loop 0 -demuxer rawvideo -rawvideo
>>   w=800:h=600:size=$((800*600*2)):format=yuy2
>>
>>   Linux:
>> use rkcamsrc gstreamer plugin(just a modified v4l2src) to preview.
>>
>>   gst-launch-1.0 rkcamsrc device=/dev/video0 io-mode=4 disable-3A=true
>>   videoconvert ! video/x-raw,format=NV12,width=640,height=480 ! kmssink
>
> Is the rkcamsrc plugin source available somewhere to download?

It could be download, but it's rough and just be used by me to test
driver at present  since
Hal3 is not completed.

You can consider it as "media-ctl + gstreamer v4l2src"
https://github.com/GStreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2src.c


>
> Thanks,
> Tomasz

[PATCH v2] dvb_dev_get_fd(): return fd of local devices

[Rafaël Carré]

This makes it possible to poll a local device.
Getting the fd is preferrable to adding a dvb_dev_poll() function,
because we can poll several fds together in an event-based program.

This is not implemented for remote devices, as polling a remote fd
does not make sense.
We could instead return the socket to know when to expect messages
from the remote device, but the current implementation in
dvb-dev-remote.c already runs a thread to receive remote messages
as soon as possible.
---
v2: get the private dvb_device_priv correctly

 lib/include/libdvbv5/dvb-dev.h | 12 
 lib/libdvbv5/dvb-dev-local.c   |  6 ++
 lib/libdvbv5/dvb-dev-priv.h|  1 +
 lib/libdvbv5/dvb-dev.c | 11 +++
 4 files changed, 30 insertions(+)

diff --git a/lib/include/libdvbv5/dvb-dev.h b/lib/include/libdvbv5/dvb-dev.h
index 98bee5e7..55e0f065 100644
--- a/lib/include/libdvbv5/dvb-dev.h
+++ b/lib/include/libdvbv5/dvb-dev.h
@@ -289,6 +289,18 @@ struct dvb_open_descriptor *dvb_dev_open(struct dvb_device 
*dvb,
  */
 void dvb_dev_close(struct dvb_open_descriptor *open_dev);
 
+/**
+ * @brief returns fd from a local device
+ * This will not work for remote devices.
+ * @ingroup dvb_device
+ *
+ * @param open_dev Points to the struct dvb_open_descriptor
+ *
+ * @return On success, returns the fd.
+ * Returns -1 on error.
+ */
+int dvb_dev_get_fd(struct dvb_open_descriptor *open_dev);
+
 /**
  * @brief read from a dvb demux or dvr file
  * @ingroup dvb_device
diff --git a/lib/libdvbv5/dvb-dev-local.c b/lib/libdvbv5/dvb-dev-local.c
index b50b61b4..eb2f0775 100644
--- a/lib/libdvbv5/dvb-dev-local.c
+++ b/lib/libdvbv5/dvb-dev-local.c
@@ -775,6 +775,11 @@ static void dvb_dev_local_free(struct dvb_device_priv *dvb)
free(priv);
 }
 
+static int dvb_local_get_fd(struct dvb_open_descriptor *open_dev)
+{
+return open_dev->fd;
+}
+
 /* Initialize for local usage */
 void dvb_dev_local_init(struct dvb_device_priv *dvb)
 {
@@ -788,6 +793,7 @@ void dvb_dev_local_init(struct dvb_device_priv *dvb)
ops->stop_monitor = dvb_local_stop_monitor;
ops->open = dvb_local_open;
ops->close = dvb_local_close;
+   ops->get_fd = dvb_local_get_fd;
 
ops->dmx_stop = dvb_local_dmx_stop;
ops->set_bufsize = dvb_local_set_bufsize;
diff --git a/lib/libdvbv5/dvb-dev-priv.h b/lib/libdvbv5/dvb-dev-priv.h
index e05fcad2..2e69f766 100644
--- a/lib/libdvbv5/dvb-dev-priv.h
+++ b/lib/libdvbv5/dvb-dev-priv.h
@@ -72,6 +72,7 @@ struct dvb_dev_ops {
int (*fe_get_stats)(struct dvb_v5_fe_parms *p);
 
void (*free)(struct dvb_device_priv *dvb);
+   int (*get_fd)(struct dvb_open_descriptor *dvb);
 };
 
 struct dvb_device_priv {
diff --git a/lib/libdvbv5/dvb-dev.c b/lib/libdvbv5/dvb-dev.c
index 7e2da1fb..e6a8fc76 100644
--- a/lib/libdvbv5/dvb-dev.c
+++ b/lib/libdvbv5/dvb-dev.c
@@ -218,6 +218,17 @@ struct dvb_open_descriptor *dvb_dev_open(struct dvb_device 
*d,
return ops->open(dvb, sysname, flags);
 }
 
+int dvb_dev_get_fd(struct dvb_open_descriptor *open_dev)
+{
+   struct dvb_device_priv *dvb = open_dev->dvb;
+   struct dvb_dev_ops *ops = >ops;
+
+   if (!ops->get_fd)
+   return -1;
+
+   return ops->get_fd(open_dev);
+}
+
 void dvb_dev_close(struct dvb_open_descriptor *open_dev)
 {
struct dvb_device_priv *dvb = open_dev->dvb;
-- 
2.14.1

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[jacopo mondi]

Hi Sakari,
   thanks for review!

On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> Could you remove the original driver and send the patch using git
> send-email -C ? That way a single patch would address converting it to a
> proper V4L2 driver as well as move it to the correct location. The changes
> would be easier to review that way since then, well, it'd be easier to see
> the changes. :-)

Actually I prefer not to remove the existing driver at the moment. See
the cover letter for reasons why not to do so right now...

Also, there's not that much code from the old driver in here, surely
less than the default 50% -C and -M options of 'git format-patch' use
as a threshold for detecting copies iirc..

I would prefer this to be reviewed as new driver, I know it's a bit
more painful, but irq handler and a couple of other routines apart,
there's not that much code shared between the two...

>
> The same goes for the two V4L2 SoC camera sensor / video decoder drivers at
> the end of the set.
>

Also in this case I prefer not to remove existing code, as long as
there are platforms using it..

> On Wed, Nov 15, 2017 at 11:55:56AM +0100, Jacopo Mondi wrote:
> > Add driver for Renesas Capture Engine Unit (CEU).
> >
> > The CEU interface supports capturing 'data' (YUV422) and 'images'
> > (NV[12|21|16|61]).
> >
> > This driver aims to replace the soc_camera based sh_mobile_ceu one.
> >
> > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> > platform GR-Peach.
> >
> > Tested with ov7725 camera sensor on SH4 platform Migo-R.
>
> Nice!
>
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> > +#include 
>
> Do you need this header? There would seem some that I wouldn't expect to be
> needed below, such as linux/init.h.

It's probably a leftover, I'll remove it...

[snip]
>
> > +#if IS_ENABLED(CONFIG_OF)
> > +static const struct of_device_id ceu_of_match[] = {
> > +   { .compatible = "renesas,renesas-ceu" },
>
> Even if you add support for new hardware, shouldn't you maintain support
> for renesas,sh-mobile-ceu?
>

As you noticed already, the old driver did not support OF, so there
are no compatibility issues here

Thanks
   j

Re: [PATCH v1 06/10] sh: sh7722: Rename CEU clock

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
 wrote:
> Rename CEU clock to match the new platform driver name used in Migo-R.
>
> There are no other sh7722 based devices Migo-R apart, so we can safely
> rename this.
>
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c 
> b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> index 8f07a1a..d85091e 100644
> --- a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> +++ b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> @@ -223,7 +223,7 @@ static struct clk_lookup lookups[] = {
> CLKDEV_DEV_ID("sh-vou.0", _clks[HWBLK_VOU]),
> CLKDEV_CON_ID("jpu0", _clks[HWBLK_JPU]),
> CLKDEV_CON_ID("beu0", _clks[HWBLK_BEU]),
> -   CLKDEV_DEV_ID("sh_mobile_ceu.0", _clks[HWBLK_CEU]),
> +   CLKDEV_DEV_ID("renesas-ceu.0", _clks[HWBLK_CEU]),
> CLKDEV_CON_ID("veu0", _clks[HWBLK_VEU]),
> CLKDEV_CON_ID("vpu0", _clks[HWBLK_VPU]),
> CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", _clks[HWBLK_LCDC]),

Shouldn't this be merged with "[PATCH v1 05/10] arch: sh: migor: Use new
renesas-ceu camera driver", to avoid breaking bisection?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

[Geert Uytterhoeven]

Hi Jacopo,

CC devicetree folks

On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
 wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
>
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..a88e9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,87 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with up 8/16bits data bus 
> width.

... with data bus widths up to 8/16 bits?

> +
> +Required properties:
> +- compatible
> +   Must be "renesas,renesas-ceu".

The double "renesas" part looks odd to me. What about "renesas,ceu"?
Shouldn't you add SoC-specific compatible values like "renesas,r7s72100-ceu",
too?

> +- reg
> +   Physical address base and size.
> +- interrupts
> +   The interrupt line number.

interrupt specifier

> +- pinctrl-names, pinctrl-0
> +   phandle of pin controller sub-node configuring pins for CEU 
> operations.
> +
> +CEU supports a single parallel input and should contain a single 'port' 
> subnode
> +with a single 'endpoint'. Optional endpoint properties applicable to parallel
> +input bus are described in "video-interfaces.txt".
> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and a

... an

> +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> +
> +ceu: ceu@e821 {
> +   reg = <0xe821 0x209c>;
> +   compatible = "renesas,renesas-ceu";
> +   interrupts = ;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   status = "okay";
> +
> +   port {
> +   ceu_in: endpoint {
> +   remote-endpoint = <_out>;
> +
> +   bus-width = <8>;
> +   hsync-active = <1>;
> +   vsync-active = <1>;
> +   pclk-sample = <1>;
> +   data-active = <1>;
> +   };
> +   };
> +};
> +
> +i2c1: i2c@fcfee400 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   status = "okay";
> +   clock-frequency = <10>;
> +
> +   ov7670: camera@21 {
> +   compatible = "ovti,ov7670";
> +   reg = <0x21>;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +
> +   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> +   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> +   clocks = <>;
> +   clock-names = "xclk";
> +
> +   xclk: fixed_clk {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <2400>;
> +   };
> +
> +   port {
> +   ov7670_out: endpoint {
> +   remote-endpoint = <_in>;
> +
> +   bus-width = <8>;
> +   hsync-active = <1>;
> +   vsync-active = <1>;
> +   pclk-sample = <1>;
> +   data-active = <1>;
> +   };
> +   };
> +   };
> --
> 2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[Sakari Ailus]

Hi Jacopo,

Could you remove the original driver and send the patch using git
send-email -C ? That way a single patch would address converting it to a
proper V4L2 driver as well as move it to the correct location. The changes
would be easier to review that way since then, well, it'd be easier to see
the changes. :-)

The same goes for the two V4L2 SoC camera sensor / video decoder drivers at
the end of the set.

On Wed, Nov 15, 2017 at 11:55:56AM +0100, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
> 
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
> 
> This driver aims to replace the soc_camera based sh_mobile_ceu one.
> 
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
> 
> Tested with ov7725 camera sensor on SH4 platform Migo-R.

Nice!

> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/Kconfig   |9 +
>  drivers/media/platform/Makefile  |2 +
>  drivers/media/platform/renesas-ceu.c | 1768 
> ++
>  3 files changed, 1779 insertions(+)
>  create mode 100644 drivers/media/platform/renesas-ceu.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3c4f7fa..401caea 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
> To compile this driver as a module, choose M here: the module
> will be called stm32-dcmi.
> 
> +config VIDEO_RENESAS_CEU
> + tristate "Renesas Capture Engine Unit (CEU) driver"
> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_FWNODE
> + ---help---
> +   This is a v4l2 driver for the Renesas CEU Interface
> +
>  source "drivers/media/platform/soc_camera/Kconfig"
>  source "drivers/media/platform/exynos4-is/Kconfig"
>  source "drivers/media/platform/am437x/Kconfig"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 327f80a..0d1f02b 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA)+= coda/
> 
>  obj-$(CONFIG_VIDEO_SH_VEU)   += sh_veu.o
> 
> +obj-$(CONFIG_VIDEO_RENESAS_CEU)  += renesas-ceu.o
> +
>  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)  += m2m-deinterlace.o
> 
>  obj-$(CONFIG_VIDEO_MUX)  += video-mux.o
> diff --git a/drivers/media/platform/renesas-ceu.c 
> b/drivers/media/platform/renesas-ceu.c
> new file mode 100644
> index 000..aaba3cd
> --- /dev/null
> +++ b/drivers/media/platform/renesas-ceu.c
> @@ -0,0 +1,1768 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
> + *
> + * Copyright (C) 2017 Jacopo Mondi 
> + *
> + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
> + * Copyright (C) 2008 Magnus Damm
> + *
> + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
> + * Copyright (C) 2006, Sascha Hauer, Pengutronix
> + * Copyright (C) 2008, Guennadi Liakhovetski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 

Do you need this header? There would seem some that I wouldn't expect to be
needed below, such as linux/init.h.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define DRIVER_NAME  "renesas-ceu"
> +
> +/* 
> 
> + * CEU registers offsets and masks
> + */
> +#define CEU_CAPSR0x00 /* Capture start register  */
> +#define CEU_CAPCR0x04 /* Capture control register*/
> +#define CEU_CAMCR0x08 /* Capture interface control register  */
> +#define CEU_CAMOR0x10 /* Capture interface offset register   */
> +#define CEU_CAPWR0x14 /* Capture interface width register*/
> +#define CEU_CAIFR0x18 /* Capture interface input format register */
> +#define CEU_CRCNTR   0x28 /* CEU register control register   */
> +#define CEU_CRCMPR   0x2c /* CEU register forcible control register  */
> +#define CEU_CFLCR0x30 /* Capture filter control register */
> +#define CEU_CFSZR0x34 /* Capture filter size 

Re: [PATCH v1 02/10] include: media: Add Renesas CEU driver interface

[Sakari Ailus]

Hi Jacopo,

On Wed, Nov 15, 2017 at 11:55:55AM +0100, Jacopo Mondi wrote:
> Add renesas-ceu header file.
> 
> Do not remove the existing sh_mobile_ceu.h one as long as the original
> driver does not go away.

Hmm. This isn't really not about not removing a file but adding a new one.
Do you really need it outside the driver's own directory?

> 
> Signed-off-by: Jacopo Mondi 
> ---
>  include/media/drv-intf/renesas-ceu.h | 23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 include/media/drv-intf/renesas-ceu.h
> 
> diff --git a/include/media/drv-intf/renesas-ceu.h 
> b/include/media/drv-intf/renesas-ceu.h
> new file mode 100644
> index 000..f2da78c
> --- /dev/null
> +++ b/include/media/drv-intf/renesas-ceu.h
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +#ifndef __ASM_RENESAS_CEU_H__
> +#define __ASM_RENESAS_CEU_H__
> +
> +#include 
> +
> +#define CEU_FLAG_PRIMARY_SENSBIT(0)
> +#define CEU_MAX_SENS 2
> +
> +struct ceu_async_subdev {
> + unsigned long flags;
> + unsigned char bus_width;
> + unsigned char bus_shift;
> + unsigned int i2c_adapter_id;
> + unsigned int i2c_address;
> +};
> +
> +struct ceu_info {
> + unsigned int num_subdevs;
> + struct ceu_async_subdev subdevs[CEU_MAX_SENS];
> +};
> +
> +#endif /* __ASM_RENESAS_CEU_H__ */
> --
> 2.7.4
> 

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

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

[Sakari Ailus]

Hi Jacopo,

Thanks for the patchset. Please see my comments below.

On Wed, Nov 15, 2017 at 11:55:54AM +0100, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..a88e9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,87 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with up 8/16bits data bus 
> width.
> +
> +Required properties:
> +- compatible
> + Must be "renesas,renesas-ceu".
> +- reg
> + Physical address base and size.
> +- interrupts
> + The interrupt line number.
> +- pinctrl-names, pinctrl-0
> + phandle of pin controller sub-node configuring pins for CEU operations.
> +
> +CEU supports a single parallel input and should contain a single 'port' 
> subnode
> +with a single 'endpoint'. Optional endpoint properties applicable to parallel
> +input bus are described in "video-interfaces.txt".

Could you list which ones they are? For someone not familiar with the
parallel bus this might not be obvious; also not all hardware can make use
of every one of these properties.

> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and a
> +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,renesas-ceu";
> + interrupts = ;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <_out>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> + clocks = <>;
> + clock-names = "xclk";
> +
> + xclk: fixed_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2400>;
> + };

What's the purpose of the fixed_clk node here?

> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <_in>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> + };

-- 
Regards,

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

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

[Edgar Thier]

Hi Kieran,

> I think it's easier to see updated patches if they are posted as a new thread,
> with an increased version number. [PATCH v2], [PATCH v3] etc...
>
> Not a problem now - but might help your updated patches get seen next time.

I will keep that in mind for next time. :)

> Looks like my concerns were addressed, so that's a Reviewed-by: tag from me.

Thanks!

Regards,

Edgar

[PATCH] media: v4l2-fwnode: Check subdev count after checking port

[Tomasz Figa]

Current implementation of __v4l2_async_notifier_parse_fwnode_endpoints()
checks first whether subdev_count >= subdev_max and only then whether
the port being parsed matches the given port index. This triggers an
error in otherwise valid cases of skipping ports that do not match.

Fix this by moving the check below the port index check.

Fixes: 9ca465312132 ("media: v4l: fwnode: Support generic parsing of graph 
endpoints in a device")
Signed-off-by: Tomasz Figa 
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 681b192420d9..fb72c7ac04d4 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -458,11 +458,6 @@ static int __v4l2_async_notifier_parse_fwnode_endpoints(
if (!is_available)
continue;
 
-   if (WARN_ON(notifier->num_subdevs >= notifier->max_subdevs)) {
-   ret = -EINVAL;
-   break;
-   }
-
if (has_port) {
struct fwnode_endpoint ep;
 
@@ -474,6 +469,11 @@ static int __v4l2_async_notifier_parse_fwnode_endpoints(
continue;
}
 
+   if (WARN_ON(notifier->num_subdevs >= notifier->max_subdevs)) {
+   ret = -EINVAL;
+   break;
+   }
+
ret = v4l2_async_notifier_fwnode_parse_endpoint(
dev, notifier, fwnode, asd_struct_size, parse_endpoint);
if (ret < 0)
-- 
2.15.0.448.gf294e3d99a-goog

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

[Kieran Bingham]

Hi Edgar,

Thanks for addressing my concerns in this updated patch.

On 12/10/17 08:54, Edgar Thier wrote:
> 
> Use flags the device exposes for UVC controls.
> This allows the device to define which property flags are set.
> 
> Since some cameras offer auto-adjustments for properties (e.g. auto-gain),
> the values of other properties (e.g. gain) can change in the camera.
> Examining the flags ensures that the driver is aware of such properties.
> 
> Signed-off-by: Edgar Thier 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 64 
> ++--
>  1 file changed, 49 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 20397aba..8f902a41 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1629,6 +1629,40 @@ static void uvc_ctrl_fixup_xu_info(struct uvc_device 
> *dev,
>   }
>  }
> 
> +/*
> + * Retrieve flags for a given control
> + */
> +static int uvc_ctrl_get_flags(struct uvc_device *dev, const struct 
> uvc_control *ctrl,
> + const struct uvc_control_info *info)
> +{
> + u8 *data;
> + int ret = 0;
> + int flags = 0;
> +
> + data = kmalloc(2, GFP_KERNEL);
> + if (data == NULL)
> + return -ENOMEM;
> +
> + ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
> +  info->selector, data, 1);
> + if (ret < 0) {
> + uvc_trace(UVC_TRACE_CONTROL,
> +   "GET_INFO failed on control %pUl/%u (%d).\n",
> +   info->entity, info->selector, ret);
> + } else {
> + flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
> + | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
> + | (data[0] & UVC_CONTROL_CAP_GET ?
> +UVC_CTRL_FLAG_GET_CUR : 0)
> + | (data[0] & UVC_CONTROL_CAP_SET ?
> +UVC_CTRL_FLAG_SET_CUR : 0)
> + | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
> +UVC_CTRL_FLAG_AUTO_UPDATE : 0);
> + }
> + kfree(data);
> + return flags;
> +}
> +
>  /*
>   * Query control information (size and flags) for XU controls.
>   */
> @@ -1636,6 +1670,7 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
>   const struct uvc_control *ctrl, struct uvc_control_info *info)
>  {
>   u8 *data;
> + int flags;
>   int ret;
> 
>   data = kmalloc(2, GFP_KERNEL);
> @@ -1659,24 +1694,15 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device 
> *dev,
> 
>   info->size = le16_to_cpup((__le16 *)data);
> 
> - /* Query the control information (GET_INFO) */
> - ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
> -  info->selector, data, 1);
> - if (ret < 0) {
> + flags = uvc_ctrl_get_flags(dev, ctrl, info);
> +
> + if (flags < 0) {
>   uvc_trace(UVC_TRACE_CONTROL,
> -   "GET_INFO failed on control %pUl/%u (%d).\n",
> -   info->entity, info->selector, ret);
> +   "Failed to retrieve flags (%d).\n", ret);
> + ret = flags;
>   goto done;
>   }
> -
> - info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
> - | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
> - | (data[0] & UVC_CONTROL_CAP_GET ?
> -UVC_CTRL_FLAG_GET_CUR : 0)
> - | (data[0] & UVC_CONTROL_CAP_SET ?
> -UVC_CTRL_FLAG_SET_CUR : 0)
> - | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
> -UVC_CTRL_FLAG_AUTO_UPDATE : 0);
> + info->flags = flags;
> 
>   uvc_ctrl_fixup_xu_info(dev, ctrl, info);
> 
> @@ -1890,6 +1916,7 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
> struct uvc_control *ctrl,
>   const struct uvc_control_info *info)
>  {
>   int ret = 0;
> + int flags = 0;
> 
>   ctrl->info = *info;
>   INIT_LIST_HEAD(>info.mappings);
> @@ -1902,6 +1929,13 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
> struct uvc_control *ctrl,
>   goto done;
>   }
> 
> + flags = uvc_ctrl_get_flags(dev, ctrl, info);
> + if (flags < 0)
> + uvc_trace(UVC_TRACE_CONTROL,
> +   "Failed to retrieve flags (%d).\n", ret);
> + else
> + ctrl->info.flags = flags;
> +
>   ctrl->initialized = 1;
> 
>   uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s "
> 

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

[Kieran Bingham]

Hi Edgar,

On 15/11/17 08:11, Edgar Thier wrote:
> Hi,
> 
> I was wondering if there are any problems with my latest patch or if it 
> simply slipped through.

Slipped though in high mail volumes :)

I think it's easier to see updated patches if they are posted as a new thread,
with an increased version number. [PATCH v2], [PATCH v3] etc...

Not a problem now - but might help your updated patches get seen next time.

Looks like my concerns were addressed, so that's a Reviewed-by: tag from me.

--
Kieran

> 
> Regards,
> 
> Edgar
> 
> On 10/12/2017 09:54 AM, Edgar Thier wrote:
>>
>> Use flags the device exposes for UVC controls.
>> This allows the device to define which property flags are set.
>>
>> Since some cameras offer auto-adjustments for properties (e.g. auto-gain),
>> the values of other properties (e.g. gain) can change in the camera.
>> Examining the flags ensures that the driver is aware of such properties.
>>
>> Signed-off-by: Edgar Thier 
>> ---
>>  drivers/media/usb/uvc/uvc_ctrl.c | 64 
>> ++--
>>  1 file changed, 49 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
>> b/drivers/media/usb/uvc/uvc_ctrl.c
>> index 20397aba..8f902a41 100644
>> --- a/drivers/media/usb/uvc/uvc_ctrl.c
>> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
>> @@ -1629,6 +1629,40 @@ static void uvc_ctrl_fixup_xu_info(struct uvc_device 
>> *dev,
>>  }
>>  }
>>
>> +/*
>> + * Retrieve flags for a given control
>> + */
>> +static int uvc_ctrl_get_flags(struct uvc_device *dev, const struct 
>> uvc_control *ctrl,
>> +const struct uvc_control_info *info)
>> +{
>> +u8 *data;
>> +int ret = 0;
>> +int flags = 0;
>> +
>> +data = kmalloc(2, GFP_KERNEL);
>> +if (data == NULL)
>> +return -ENOMEM;
>> +
>> +ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
>> + info->selector, data, 1);
>> +if (ret < 0) {
>> +uvc_trace(UVC_TRACE_CONTROL,
>> +  "GET_INFO failed on control %pUl/%u (%d).\n",
>> +  info->entity, info->selector, ret);
>> +} else {
>> +flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
>> +| UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
>> +| (data[0] & UVC_CONTROL_CAP_GET ?
>> +   UVC_CTRL_FLAG_GET_CUR : 0)
>> +| (data[0] & UVC_CONTROL_CAP_SET ?
>> +   UVC_CTRL_FLAG_SET_CUR : 0)
>> +| (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
>> +   UVC_CTRL_FLAG_AUTO_UPDATE : 0);
>> +}
>> +kfree(data);
>> +return flags;
>> +}
>> +
>>  /*
>>   * Query control information (size and flags) for XU controls.
>>   */
>> @@ -1636,6 +1670,7 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device 
>> *dev,
>>  const struct uvc_control *ctrl, struct uvc_control_info *info)
>>  {
>>  u8 *data;
>> +int flags;
>>  int ret;
>>
>>  data = kmalloc(2, GFP_KERNEL);
>> @@ -1659,24 +1694,15 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device 
>> *dev,
>>
>>  info->size = le16_to_cpup((__le16 *)data);
>>
>> -/* Query the control information (GET_INFO) */
>> -ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
>> - info->selector, data, 1);
>> -if (ret < 0) {
>> +flags = uvc_ctrl_get_flags(dev, ctrl, info);
>> +
>> +if (flags < 0) {
>>  uvc_trace(UVC_TRACE_CONTROL,
>> -  "GET_INFO failed on control %pUl/%u (%d).\n",
>> -  info->entity, info->selector, ret);
>> +  "Failed to retrieve flags (%d).\n", ret);
>> +ret = flags;
>>  goto done;
>>  }
>> -
>> -info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
>> -| UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
>> -| (data[0] & UVC_CONTROL_CAP_GET ?
>> -   UVC_CTRL_FLAG_GET_CUR : 0)
>> -| (data[0] & UVC_CONTROL_CAP_SET ?
>> -   UVC_CTRL_FLAG_SET_CUR : 0)
>> -| (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
>> -   UVC_CTRL_FLAG_AUTO_UPDATE : 0);
>> +info->flags = flags;
>>
>>  uvc_ctrl_fixup_xu_info(dev, ctrl, info);
>>
>> @@ -1890,6 +1916,7 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
>> struct uvc_control *ctrl,
>>  const struct uvc_control_info *info)
>>  {
>>  int ret = 0;
>> +int flags = 0;
>>
>>  ctrl->info = *info;
>>  INIT_LIST_HEAD(>info.mappings);
>> @@ -1902,6 +1929,13 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
>> struct uvc_control *ctrl,
>>  goto done;
>>  }
>>
>> +flags = uvc_ctrl_get_flags(dev, ctrl, info);
>> +if (flags < 0)
>> +uvc_trace(UVC_TRACE_CONTROL,
>> +  "Failed to 

Hello Dear...

[M,Shakour Rosarita]

Hello Dear...

I know that this message will come to you as a surprise. I hoped that
you will not expose or betray this trust and confident that I am about
to repose on you, my name is M, Shakour Rosarita. I am 19 years old
Girl, female, from Tartu Syria, (never married) 61 kg, white in
complexion, and I am currently living in the refugee camp here in
Abidjan Ivory Coast, My late beloved father M,Shakour Hassin was a
renowned businessman and owner of Natour Petrol Station in Syria, he
was killed in a stampede riot in Tartu, Syria.
When I got the news about my parents. I fled to a nearby country
Jordan before I joined a ferry to Africa and came to Abidjan capital
city Ivory Coast West Africa find safety here.
I came in 2015 to Abidjan and I now live in refugee camps here as
refugees are allowed freely to enter here without, My late father
deposited (US$6.200.000.00m) My late father kept the money at the bank
of Africa, I want you to help me transfer the money to your hand so
that you will help me bring me into your country for my continue
education.

I sent my pictures here for you to see. Who I am seriously looking for
a good-person in my life, so I want to hear from you soon and learn
more about you.

I am an open-minded and friendly girl to share a good time with you
and have fun and enjoy on the go, bird watching, the rest of our
lives. My Hobbies, tourism books, dance, music, soccer, tennis,
swimming and cinema.
I would just think about you, including your dose and doesn’t .I
believe we will do well together, and live like one family.
Thank you and God bless you, for you in your promise to help me here,
looking forward to your reply by the grace of God and have a good day.
I hope you send me your photos as well? I await your next reply in
faith please reply through my private email at
(mshakourrosarit...@gmail.com):
Thanks.
Ms Rosarita

[PATCH 1/2] dvb_logfunc: add a user private parameter

[Rafaël Carré]

---
 lib/include/libdvbv5/dvb-dev.h |  3 ++-
 lib/include/libdvbv5/dvb-fe.h  |  9 +++--
 lib/include/libdvbv5/dvb-log.h | 33 +
 lib/libdvbv5/dvb-dev.c |  3 ++-
 lib/libdvbv5/dvb-fe.c  | 15 ---
 lib/libdvbv5/dvb-log.c |  3 ++-
 utils/dvb/dvb-fe-tool.c|  2 +-
 utils/dvb/dvbv5-daemon.c   |  9 +
 utils/dvb/dvbv5-scan.c |  2 +-
 utils/dvb/dvbv5-zap.c  |  2 +-
 10 files changed, 46 insertions(+), 35 deletions(-)

diff --git a/lib/include/libdvbv5/dvb-dev.h b/lib/include/libdvbv5/dvb-dev.h
index 55e0f065..396fcd07 100644
--- a/lib/include/libdvbv5/dvb-dev.h
+++ b/lib/include/libdvbv5/dvb-dev.h
@@ -243,6 +243,7 @@ void dvb_dev_stop_monitor(struct dvb_device *dvb);
  * @param logfunc  Callback function to be called when a log event
  * happens. Can either store the event into a file or
  * to print it at the TUI/GUI. Can be null.
+ * @param logpriv   Private data for log function
  *
  * @details Sets the function to report log errors and to set the verbosity
  * level of debug report messages. If not called, or if logfunc is
@@ -252,7 +253,7 @@ void dvb_dev_stop_monitor(struct dvb_device *dvb);
  */
 void dvb_dev_set_log(struct dvb_device *dvb,
 unsigned verbose,
-dvb_logfunc logfunc);
+dvb_logfunc logfunc, void *logpriv);
 
 /**
  * @brief Opens a dvb device
diff --git a/lib/include/libdvbv5/dvb-fe.h b/lib/include/libdvbv5/dvb-fe.h
index 1d3565ec..107cb03d 100644
--- a/lib/include/libdvbv5/dvb-fe.h
+++ b/lib/include/libdvbv5/dvb-fe.h
@@ -107,6 +107,7 @@
  * @param freq_bpf SCR/Unicable band-pass filter frequency to use, 
in kHz
  * @param verbose  Verbosity level of the library (RW)
  * @param dvb_logfunc  Function used to write log messages (RO)
+ * @param logpriv  Private data for logging function (RO)
  * @param default_charset  Name of the charset used by the DVB standard 
(RW)
  * @param output_charset   Name of the charset to output (system specific) 
(RW)
  *
@@ -140,7 +141,8 @@ struct dvb_v5_fe_parms {
 
/* Function to write DVB logs */
unsignedverbose;
-   dvb_logfunc logfunc;
+   dvb_logfunc logfunc;
+   void*logpriv;
 
/* Charsets to be used by the conversion utilities */
char*default_charset;
@@ -176,6 +178,7 @@ struct dvb_v5_fe_parms *dvb_fe_dummy(void);
  * happens. Can either store the event into a file
  * or to print it at the TUI/GUI. If NULL, the
  * library will use its internal handler.
+ * @param logpriv  Private data for dvb_logfunc
  * @param flagsFlags to be passed to open. Currently 
only two
  * flags are supported: O_RDONLY or O_RDWR.
  * Using O_NONBLOCK may hit unexpected issues.
@@ -195,6 +198,7 @@ struct dvb_v5_fe_parms *dvb_fe_open_flags(int adapter, int 
frontend,
  unsigned verbose,
  unsigned use_legacy_call,
  dvb_logfunc logfunc,
+ void *logpriv,
  int flags);
 
 /**
@@ -231,6 +235,7 @@ struct dvb_v5_fe_parms *dvb_fe_open(int adapter, int 
frontend,
  * @param logfunc  Callback function to be called when a log event
  * happens. Can either store the event into a file
  * or to print it at the TUI/GUI.
+ * @param logpriv  Private data for dvb_logfunc
  *
  * @details This function should be called before using any other function at
  * the frontend library (or the other alternatives: dvb_fe_open() or
@@ -240,7 +245,7 @@ struct dvb_v5_fe_parms *dvb_fe_open(int adapter, int 
frontend,
  */
 struct dvb_v5_fe_parms *dvb_fe_open2(int adapter, int frontend,
unsigned verbose, unsigned use_legacy_call,
-   dvb_logfunc logfunc);
+   dvb_logfunc logfunc, void *logpriv);
 
 /**
  * @brief Closes the frontend and frees allocated resources
diff --git a/lib/include/libdvbv5/dvb-log.h b/lib/include/libdvbv5/dvb-log.h
index 181a23c8..beba7aba 100644
--- a/lib/include/libdvbv5/dvb-log.h
+++ b/lib/include/libdvbv5/dvb-log.h
@@ -36,12 +36,12 @@
  */
 
 /**
- * @typedef void (*dvb_logfunc)(int level, const char *fmt, ...)
+ * @typedef void (*dvb_logfunc)(void *logpriv, int level, const char *fmt, ...)
  * @brief typedef used by dvb_fe_open2 for the log function
  * @ingroup ancillary
  */
 
-typedef void 

[PATCH 2/2] dvbv5-daemon: 0 is a valid fd

[Rafaël Carré]

---
 utils/dvb/dvbv5-daemon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/dvb/dvbv5-daemon.c b/utils/dvb/dvbv5-daemon.c
index 58485ac6..711694e0 100644
--- a/utils/dvb/dvbv5-daemon.c
+++ b/utils/dvb/dvbv5-daemon.c
@@ -570,7 +570,7 @@ void dvb_remote_log(void *priv, int level, const char *fmt, 
...)
 
va_end(ap);
 
-   if (fd > 0)
+   if (fd >= 0)
send_data(fd, "%i%s%i%s", 0, "log", level, buf);
else
local_log(level, buf);
-- 
2.14.1

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

[Kieran Bingham]

Hi Jacopo,

A couple of minor language fixups inline.

On 15/11/17 10:55, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/renesas,ceu.txt  | 87 
> ++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..a88e9cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,87 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found on Renesas
> +RZ chip series and on SH Mobile ones.
> +
> +The interface supports a single parallel input with up 8/16bits data bus 
> width.

s/with up 8/16bits/with either 8 or 16 bits/ ?

> +
> +Required properties:
> +- compatible
> + Must be "renesas,renesas-ceu".
> +- reg
> + Physical address base and size.
> +- interrupts
> + The interrupt line number.
> +- pinctrl-names, pinctrl-0
> + phandle of pin controller sub-node configuring pins for CEU operations.
> +
> +CEU supports a single parallel input and should contain a single 'port' 
> subnode
> +with a single 'endpoint'. Optional endpoint properties applicable to parallel
> +input bus are described in "video-interfaces.txt".
> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and a

s/and a/and an/

> +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,renesas-ceu";
> + interrupts = ;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <_out>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> + clocks = <>;
> + clock-names = "xclk";
> +
> + xclk: fixed_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2400>;
> + };
> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <_in>;
> +
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> + };
> 

[PATCH v1 10/10] media: i2c: tw9910: Remove soc_camera dependencies

[Jacopo Mondi]

Remove soc_camera framework dependencies from tw9910 sensor driver.
- Handle clock directly
- Register async subdevice
- Add platform specific enable/disable functions
- Adjust build system

This commit does not remove the original soc_camera based driver.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig  |  9 ++
 drivers/media/i2c/Makefile |  1 +
 drivers/media/i2c/tw9910.c | 80 ++
 include/media/i2c/tw9910.h |  6 
 4 files changed, 75 insertions(+), 21 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ff251ce..bbd77ee 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -415,6 +415,15 @@ config VIDEO_TW9906
  To compile this driver as a module, choose M here: the
  module will be called tw9906.

+config VIDEO_TW9910
+   tristate "Techwell TW9910 video decoder"
+   depends on VIDEO_V4L2 && I2C
+   ---help---
+ Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9910.
+
 config VIDEO_VPX3220
tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b2459a1..835784a 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
 obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
 obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
 obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
+obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
 obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
 obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
 obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
index bdb5e0a..f422da2 100644
--- a/drivers/media/i2c/tw9910.c
+++ b/drivers/media/i2c/tw9910.c
@@ -16,6 +16,7 @@
  * published by the Free Software Foundation.
  */

+#include 
 #include 
 #include 
 #include 
@@ -25,9 +26,7 @@
 #include 
 #include 

-#include 
 #include 
-#include 
 #include 

 #define GET_ID(val)  ((val & 0xF8) >> 3)
@@ -228,7 +227,7 @@ struct tw9910_scale_ctrl {

 struct tw9910_priv {
struct v4l2_subdev  subdev;
-   struct v4l2_clk *clk;
+   struct clk  *clk;
struct tw9910_video_info*info;
const struct tw9910_scale_ctrl  *scale;
v4l2_std_id norm;
@@ -582,13 +581,40 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
 }
 #endif

+static int tw9910_power_on(struct tw9910_priv *priv)
+{
+   int ret;
+
+   if (priv->info->platform_enable) {
+   ret = priv->info->platform_enable();
+   if (ret)
+   return ret;
+   }
+
+   if (priv->clk)
+   return clk_enable(priv->clk);
+
+   return 0;
+}
+
+static int tw9910_power_off(struct tw9910_priv *priv)
+{
+   if (priv->info->platform_enable)
+   priv->info->platform_disable();
+
+   if (priv->clk)
+   clk_disable(priv->clk);
+
+   return 0;
+}
+
 static int tw9910_s_power(struct v4l2_subdev *sd, int on)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct tw9910_priv *priv = to_tw9910(client);

-   return soc_camera_set_power(>dev, ssdd, priv->clk, on);
+   return on ? tw9910_power_on(priv) :
+   tw9910_power_off(priv);
 }

 static int tw9910_set_frame(struct v4l2_subdev *sd, u32 *width, u32 *height)
@@ -614,7 +640,7 @@ static int tw9910_set_frame(struct v4l2_subdev *sd, u32 
*width, u32 *height)
 * set bus width
 */
val = 0x00;
-   if (SOCAM_DATAWIDTH_16 == priv->info->buswidth)
+   if (priv->info->buswidth == TW9910_DATAWIDTH_16)
val = LEN;

ret = tw9910_mask_set(client, OPFORM, LEN, val);
@@ -799,8 +825,8 @@ static int tw9910_video_probe(struct i2c_client *client)
/*
 * tw9910 only use 8 or 16 bit bus width
 */
-   if (SOCAM_DATAWIDTH_16 != priv->info->buswidth &&
-   SOCAM_DATAWIDTH_8  != priv->info->buswidth) {
+   if (priv->info->buswidth != TW9910_DATAWIDTH_16 &&
+   priv->info->buswidth != TW9910_DATAWIDTH_8) {
dev_err(>dev, "bus width error\n");
return -ENODEV;
}
@@ -859,15 +885,11 @@ static int tw9910_enum_mbus_code(struct v4l2_subdev *sd,
 static int tw9910_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-
cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |

[PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[Jacopo Mondi]

Add driver for Renesas Capture Engine Unit (CEU).

The CEU interface supports capturing 'data' (YUV422) and 'images'
(NV[12|21|16|61]).

This driver aims to replace the soc_camera based sh_mobile_ceu one.

Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
platform GR-Peach.

Tested with ov7725 camera sensor on SH4 platform Migo-R.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/Kconfig   |9 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/renesas-ceu.c | 1768 ++
 3 files changed, 1779 insertions(+)
 create mode 100644 drivers/media/platform/renesas-ceu.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 3c4f7fa..401caea 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
  To compile this driver as a module, choose M here: the module
  will be called stm32-dcmi.

+config VIDEO_RENESAS_CEU
+   tristate "Renesas Capture Engine Unit (CEU) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
+   ---help---
+ This is a v4l2 driver for the Renesas CEU Interface
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 327f80a..0d1f02b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA)  += coda/

 obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o

+obj-$(CONFIG_VIDEO_RENESAS_CEU)+= renesas-ceu.o
+
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o

 obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
new file mode 100644
index 000..aaba3cd
--- /dev/null
+++ b/drivers/media/platform/renesas-ceu.c
@@ -0,0 +1,1768 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
+ *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
+ * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
+ * Copyright (C) 2008 Magnus Damm
+ *
+ * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"renesas-ceu"
+
+/* 
+ * CEU registers offsets and masks
+ */
+#define CEU_CAPSR  0x00 /* Capture start register  */
+#define CEU_CAPCR  0x04 /* Capture control register*/
+#define CEU_CAMCR  0x08 /* Capture interface control register  */
+#define CEU_CAMOR  0x10 /* Capture interface offset register   */
+#define CEU_CAPWR  0x14 /* Capture interface width register*/
+#define CEU_CAIFR  0x18 /* Capture interface input format register */
+#define CEU_CRCNTR 0x28 /* CEU register control register   */
+#define CEU_CRCMPR 0x2c /* CEU register forcible control register  */
+#define CEU_CFLCR  0x30 /* Capture filter control register */
+#define CEU_CFSZR  0x34 /* Capture filter size clip register   */
+#define CEU_CDWDR  0x38 /* Capture destination width register  */
+#define CEU_CDAYR  0x3c /* Capture data address Y register */
+#define CEU_CDACR  0x40 /* Capture data address C register */
+#define CEU_CFWCR  0x5c /* Firewall operation control register */
+#define CEU_CDOCR  0x64 /* Capture data output control register*/
+#define CEU_CEIER  0x70 /* Capture event interrupt enable register */
+#define CEU_CETCR  0x74 /* Capture event flag clear register   */
+#define CEU_CSTSR  0x7c /* Capture status register */
+#define CEU_CSRTR  0x80 /* Capture software reset register */
+
+/* Data synchronous fetch mode */
+#define CEU_CAMCR_JPEG BIT(4)
+
+/* Input components 

[PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

[Jacopo Mondi]

Add bindings documentation for Renesas Capture Engine Unit (CEU).

Signed-off-by: Jacopo Mondi 
---
 .../devicetree/bindings/media/renesas,ceu.txt  | 87 ++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
b/Documentation/devicetree/bindings/media/renesas,ceu.txt
new file mode 100644
index 000..a88e9cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
@@ -0,0 +1,87 @@
+Renesas Capture Engine Unit (CEU)
+--
+
+The Capture Engine Unit is the image capture interface found on Renesas
+RZ chip series and on SH Mobile ones.
+
+The interface supports a single parallel input with up 8/16bits data bus width.
+
+Required properties:
+- compatible
+   Must be "renesas,renesas-ceu".
+- reg
+   Physical address base and size.
+- interrupts
+   The interrupt line number.
+- pinctrl-names, pinctrl-0
+   phandle of pin controller sub-node configuring pins for CEU operations.
+
+CEU supports a single parallel input and should contain a single 'port' subnode
+with a single 'endpoint'. Optional endpoint properties applicable to parallel
+input bus are described in "video-interfaces.txt".
+
+Example:
+
+The example describes the connection between the Capture Engine Unit and a
+OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
+
+ceu: ceu@e821 {
+   reg = <0xe821 0x209c>;
+   compatible = "renesas,renesas-ceu";
+   interrupts = ;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   port {
+   ceu_in: endpoint {
+   remote-endpoint = <_out>;
+
+   bus-width = <8>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
+
+i2c1: i2c@fcfee400 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+   clock-frequency = <10>;
+
+   ov7670: camera@21 {
+   compatible = "ovti,ov7670";
+   reg = <0x21>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
+
+   clocks = <>;
+   clock-names = "xclk";
+
+   xclk: fixed_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+   };
+
+   port {
+   ov7670_out: endpoint {
+   remote-endpoint = <_in>;
+
+   bus-width = <8>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+   };
-- 
2.7.4

[PATCH v1 02/10] include: media: Add Renesas CEU driver interface

[Jacopo Mondi]

Add renesas-ceu header file.

Do not remove the existing sh_mobile_ceu.h one as long as the original
driver does not go away.

Signed-off-by: Jacopo Mondi 
---
 include/media/drv-intf/renesas-ceu.h | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 include/media/drv-intf/renesas-ceu.h

diff --git a/include/media/drv-intf/renesas-ceu.h 
b/include/media/drv-intf/renesas-ceu.h
new file mode 100644
index 000..f2da78c
--- /dev/null
+++ b/include/media/drv-intf/renesas-ceu.h
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+#ifndef __ASM_RENESAS_CEU_H__
+#define __ASM_RENESAS_CEU_H__
+
+#include 
+
+#define CEU_FLAG_PRIMARY_SENS  BIT(0)
+#define CEU_MAX_SENS   2
+
+struct ceu_async_subdev {
+   unsigned long flags;
+   unsigned char bus_width;
+   unsigned char bus_shift;
+   unsigned int i2c_adapter_id;
+   unsigned int i2c_address;
+};
+
+struct ceu_info {
+   unsigned int num_subdevs;
+   struct ceu_async_subdev subdevs[CEU_MAX_SENS];
+};
+
+#endif /* __ASM_RENESAS_CEU_H__ */
--
2.7.4

[PATCH v1 05/10] arch: sh: migor: Use new renesas-ceu camera driver

[Jacopo Mondi]

Migo-R platform uses sh_mobile_ceu camera driver, which is now being
replaced by a proper V4L2 camera driver named 'renesas-ceu'.

Move Migo-R platform to use the v4l2 renesas-ceu camera driver
interface and get rid of soc_camera defined components used to register
sensor drivers.

Also, memory for CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/boards/mach-migor/setup.c | 164 ++
 1 file changed, 76 insertions(+), 88 deletions(-)

diff --git a/arch/sh/boards/mach-migor/setup.c 
b/arch/sh/boards/mach-migor/setup.c
index 98aa094..10a9b3c 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -308,62 +308,80 @@ static struct platform_device migor_lcdc_device = {
 static struct clk *camera_clk;
 static DEFINE_MUTEX(camera_lock);

-static void camera_power_on(int is_tw)
+static void camera_vio_clk_on(void)
 {
-   mutex_lock(_lock);
-
/* Use 10 MHz VIO_CKO instead of 24 MHz to work
 * around signal quality issues on Panel Board V2.1.
 */
camera_clk = clk_get(NULL, "video_clk");
clk_set_rate(camera_clk, 1000);
clk_enable(camera_clk); /* start VIO_CKO */
-
-   /* use VIO_RST to take camera out of reset */
-   mdelay(10);
-   if (is_tw) {
-   gpio_set_value(GPIO_PTT2, 0);
-   gpio_set_value(GPIO_PTT0, 0);
-   } else {
-   gpio_set_value(GPIO_PTT0, 1);
-   }
-   gpio_set_value(GPIO_PTT3, 0);
-   mdelay(10);
-   gpio_set_value(GPIO_PTT3, 1);
-   mdelay(10); /* wait to let chip come out of reset */
 }

-static void camera_power_off(void)
+static void camera_disable(void)
 {
-   clk_disable(camera_clk); /* stop VIO_CKO */
+   /* stop VIO_CKO */
+   clk_disable(camera_clk);
clk_put(camera_clk);

+   gpio_set_value(GPIO_PTT0, 0);
+   gpio_set_value(GPIO_PTT2, 1);
gpio_set_value(GPIO_PTT3, 0);
+
mutex_unlock(_lock);
 }

-static int ov7725_power(struct device *dev, int mode)
+static void camera_reset(void)
 {
-   if (mode)
-   camera_power_on(0);
-   else
-   camera_power_off();
+   /* use VIO_RST to take camera out of reset */
+   gpio_set_value(GPIO_PTT3, 0);
+   mdelay(10);
+   gpio_set_value(GPIO_PTT3, 1);
+   mdelay(10);
+}
+
+static int ov7725_enable(void)
+{
+   mutex_lock(_lock);
+   camera_vio_clk_on();
+   mdelay(10);
+   gpio_set_value(GPIO_PTT0, 1);
+
+   camera_reset();

return 0;
 }

-static int tw9910_power(struct device *dev, int mode)
+static int tw9910_enable(void)
 {
-   if (mode)
-   camera_power_on(1);
-   else
-   camera_power_off();
+   mutex_lock(_lock);
+   camera_vio_clk_on();
+   mdelay(10);
+   gpio_set_value(GPIO_PTT2, 0);
+
+   camera_reset();

return 0;
 }

-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_info ceu_info = {
+   .num_subdevs= 2,
+   .subdevs = {
+   { /* [0] = ov772x */
+   .flags  = CEU_FLAG_PRIMARY_SENS,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x21,
+   },
+   { /* [1] = tw9910 */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x45,
+   },
+   },
 };

 static struct resource migor_ceu_resources[] = {
@@ -377,18 +395,15 @@ static struct resource migor_ceu_resources[] = {
.start  = evt2irq(0x880),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };

 static struct platform_device migor_ceu_device = {
-   .name   = "sh_mobile_ceu",
+   .name   = "renesas-ceu",
.id = 0, /* "ceu0" clock */
.num_resources  = ARRAY_SIZE(migor_ceu_resources),
.resource   = migor_ceu_resources,
.dev= {
-   .platform_data  = _mobile_ceu_info,
+   .platform_data  = _info,
},
 };

@@ -427,6 +442,19 @@ static struct platform_device sdhi_cn9_device = {
},
 };

+static struct ov772x_camera_info ov7725_info = {
+   .platform_enable = ov7725_enable,
+   .platform_disable = camera_disable,
+};
+
+static struct tw9910_video_info 

[PATCH v1 08/10] media: i2c: ov772x: Remove soc_camera dependencies

[Jacopo Mondi]

Remove soc_camera framework dependencies from ov772x sensor driver.
- Handle clock directly
- Register async subdevice
- Add platform specific enable/disable functions
- Adjust build system

This commit does not remove the original soc_camera based driver.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig  | 12 +++
 drivers/media/i2c/Makefile |  1 +
 drivers/media/i2c/ov772x.c | 88 +++---
 include/media/i2c/ov772x.h |  3 ++
 4 files changed, 76 insertions(+), 28 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9415389..ff251ce 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -629,6 +629,18 @@ config VIDEO_OV5670
  To compile this driver as a module, choose M here: the
  module will be called ov5670.

+config VIDEO_OV772X
+   tristate "OmniVision OV772x sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV772x camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov772x.
+
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f104650..b2459a1 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
+obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 8063835..9be7e4e 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -15,6 +15,7 @@
  * published by the Free Software Foundation.
  */

+#include 
 #include 
 #include 
 #include 
@@ -25,8 +26,8 @@
 #include 

 #include 
-#include 
-#include 
+
+#include 
 #include 
 #include 
 #include 
@@ -393,7 +394,7 @@ struct ov772x_win_size {
 struct ov772x_priv {
struct v4l2_subdevsubdev;
struct v4l2_ctrl_handler  hdl;
-   struct v4l2_clk  *clk;
+   struct clk   *clk;
struct ov772x_camera_info*info;
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
@@ -550,7 +551,7 @@ static int ov772x_reset(struct i2c_client *client)
 }

 /*
- * soc_camera_ops function
+ * subdev ops
  */

 static int ov772x_s_stream(struct v4l2_subdev *sd, int enable)
@@ -650,13 +651,36 @@ static int ov772x_s_register(struct v4l2_subdev *sd,
 }
 #endif

+static int ov772x_power_on(struct ov772x_priv *priv)
+{
+   int ret;
+
+   if (priv->info->platform_enable) {
+   ret = priv->info->platform_enable();
+   if (ret)
+   return ret;
+   }
+
+   /*  drivers/sh/clk/core.c returns -EINVAL if clk is NULL */
+   return clk_enable(priv->clk) <= 0 ? 0 : 1;
+}
+
+static int ov772x_power_off(struct ov772x_priv *priv)
+{
+   if (priv->info->platform_enable)
+   priv->info->platform_disable();
+
+   clk_disable(priv->clk);
+
+   return 0;
+}
+
 static int ov772x_s_power(struct v4l2_subdev *sd, int on)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov772x_priv *priv = to_ov772x(sd);

-   return soc_camera_set_power(>dev, ssdd, priv->clk, on);
+   return on ? ov772x_power_on(priv) :
+   ov772x_power_off(priv);
 }

 static const struct ov772x_win_size *ov772x_select_win(u32 width, u32 height)
@@ -1000,14 +1024,10 @@ static int ov772x_enum_mbus_code(struct v4l2_subdev *sd,
 static int ov772x_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
 {
-   struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-
cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
V4L2_MBUS_DATA_ACTIVE_HIGH;
cfg->type = V4L2_MBUS_PARALLEL;
-   cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);

return 0;
 }
@@ -1038,12 +1058,11 @@ static int ov772x_probe(struct i2c_client *client,
const struct i2c_device_id *did)
 {
struct ov772x_priv  *priv;
-   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
-   struct i2c_adapter  *adapter = to_i2c_adapter(client->dev.parent);
+   struct 

[PATCH v1 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Jacopo Mondi]

Add Capture Engine Unit (CEU) node to device tree.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r7s72100.dtsi | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 4ed12a4..683d459 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -136,8 +136,8 @@
compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
reg = <0xfcfe042c 4>;
clocks = <_clk>;
-   clock-indices = ;
-   clock-output-names = "rtc";
+   clock-indices = ;
+   clock-output-names = "rtc", "ceu";
};
 
mstp7_clks: mstp7_clks@fcfe0430 {
@@ -666,4 +666,12 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+   ceu: ceu@e821 {
+   reg = <0xe821 0x209c>;
+   compatible = "renesas,renesas-ceu";
+   interrupts = ;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
 };
-- 
2.7.4

[PATCH v1 07/10] v4l: i2c: Copy ov772x soc_camera sensor driver

[Jacopo Mondi]

Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/ov772x.c | 1124 
 1 file changed, 1124 insertions(+)
 create mode 100644 drivers/media/i2c/ov772x.c

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
new file mode 100644
index 000..8063835
--- /dev/null
+++ b/drivers/media/i2c/ov772x.c
@@ -0,0 +1,1124 @@
+/*
+ * ov772x Camera Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov7670 and soc_camera_platform driver,
+ *
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * register offset
+ */
+#define GAIN0x00 /* AGC - Gain control gain setting */
+#define BLUE0x01 /* AWB - Blue channel gain setting */
+#define RED 0x02 /* AWB - Red   channel gain setting */
+#define GREEN   0x03 /* AWB - Green channel gain setting */
+#define COM10x04 /* Common control 1 */
+#define BAVG0x05 /* U/B Average Level */
+#define GAVG0x06 /* Y/Gb Average Level */
+#define RAVG0x07 /* V/R Average Level */
+#define AECH0x08 /* Exposure Value - AEC MSBs */
+#define COM20x09 /* Common control 2 */
+#define PID 0x0A /* Product ID Number MSB */
+#define VER 0x0B /* Product ID Number LSB */
+#define COM30x0C /* Common control 3 */
+#define COM40x0D /* Common control 4 */
+#define COM50x0E /* Common control 5 */
+#define COM60x0F /* Common control 6 */
+#define AEC 0x10 /* Exposure Value */
+#define CLKRC   0x11 /* Internal clock */
+#define COM70x12 /* Common control 7 */
+#define COM80x13 /* Common control 8 */
+#define COM90x14 /* Common control 9 */
+#define COM10   0x15 /* Common control 10 */
+#define REG16   0x16 /* Register 16 */
+#define HSTART  0x17 /* Horizontal sensor size */
+#define HSIZE   0x18 /* Horizontal frame (HREF column) end high 8-bit */
+#define VSTART  0x19 /* Vertical frame (row) start high 8-bit */
+#define VSIZE   0x1A /* Vertical sensor size */
+#define PSHFT   0x1B /* Data format - pixel delay select */
+#define MIDH0x1C /* Manufacturer ID byte - high */
+#define MIDL0x1D /* Manufacturer ID byte - low  */
+#define LAEC0x1F /* Fine AEC value */
+#define COM11   0x20 /* Common control 11 */
+#define BDBASE  0x22 /* Banding filter Minimum AEC value */
+#define DBSTEP  0x23 /* Banding filter Maximum Setp */
+#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) */
+#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) */
+#define VPT 0x26 /* AGC/AEC Fast mode operating region */
+#define REG28   0x28 /* Register 28 */
+#define HOUTSIZE0x29 /* Horizontal data output size MSBs */
+#define EXHCH   0x2A /* Dummy pixel insert MSB */
+#define EXHCL   0x2B /* Dummy pixel insert LSB */
+#define VOUTSIZE0x2C /* Vertical data output size MSBs */
+#define ADVFL   0x2D /* LSB of insert dummy lines in Vertical direction */
+#define ADVFH   0x2E /* MSG of insert dummy lines in Vertical direction */
+#define YAVE0x2F /* Y/G Channel Average value */
+#define LUMHTH  0x30 /* Histogram AEC/AGC Luminance high level threshold */
+#define LUMLTH  0x31 /* Histogram AEC/AGC Luminance low  level threshold */
+#define HREF0x32 /* Image start and size control */
+#define DM_LNL  0x33 /* Dummy line low  8 bits */
+#define DM_LNH  0x34 /* Dummy line high 8 bits */
+#define ADOFF_B 0x35 /* AD offset compensation value for B  channel */
+#define ADOFF_R 0x36 /* AD offset compensation value for R  channel */
+#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */
+#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */
+#define OFF_B   0x39 /* Analog process B  channel offset value */
+#define OFF_R   0x3A /* Analog process R  channel offset value */
+#define OFF_GB  0x3B /* Analog process Gb channel offset value */
+#define OFF_GR  0x3C /* Analog process Gr channel offset value */
+#define COM12   0x3D /* Common control 12 */
+#define COM13   0x3E /* Common control 13 */
+#define COM14   0x3F /* Common control 14 */
+#define COM15   0x40 /* Common control 15*/
+#define 

[PATCH v1 00/10] Renesas Capture Engine Unit (CEU) V4L2 driver

[Jacopo Mondi]

Hello,
   this series implementes a modern V4L2 driver for Renesas Capture Engine
Unit (CEU). CEU is currently supported by the soc_camera based driver
drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c

The driver supports capturing images in planar formats (NV12/21 and NV16/61)
and non-planar YUYV422 format.

It had been tested with OV7670/OV7725 images sensor capturing images at
different resolutions (VGA and QVGA)

The series:
- Adds a new driver under drivers/media/platform/renesas-ceu.c and a new driver
  interface under include/media/drv-intf/renesas-ceu.h
- Adds device tree bindings for renesas-ceu
- Adds CEU to Renesas RZ/A1 dtsi
- Ports Migo-R SH4 based platform to make use of the new driver
- Ports image sensor drivers used by Migo-R (ov772x and tw9910) away from
  soc_camera

While this driver aims to replace the existing one, which is the last platform
driver making use of soc_camera framework, this series does not delete any of
the existing code, just because there are other SH4 users of the existing
soc_camera based driver: (mach-ap325rxa, mach-ecovec24, mach-kfr2r09 and
mach-se/7724)

As I only have access to Migo-R board, I have ported that one first, while all
other boards can be compile-ported later, once this new driver will eventually
be accepted mainline.

This series is based on v4.14-rc8 with a few patches applied on top:
https://www.spinics.net/lists/linux-sh/msg51739.html

These patches are required for mainline Migo-R board and sh_mobile_ceu_camera
driver to work properly with SH4 architecture on modern kernels, and I have
based my series on top of them.

A tag with those patches already applied on top of v4.14-rc8 is available at
git://jmondi.org/linux v4.14-rc8-migor-ceu-base

A note on testing:
The CEU IP block is found on both Renesas RZ series devices (single core ARM
platforms) and on older SH4 devices (such as Migo-R).
I have developed and tested the driver on RZ platforms, specifically on
GR-Peach with an OV7670 based camera module. More details on:
https://elinux.org/RZ-A/Boards/GR-PEACH-audiocamerashield

As we aim to replace the soc_camera based driver, I have also tested the
new one on Migo-R, capturing images from the OV7725 sensor installed on
that board (I've not been able to test TW9910 video decoder as the sensor does
not probe on the platform I have access to).
Hans, as you told me, you have a Migo-R and if you eventually would like to
give this series a spin on that platform feel free to ping me, as to run a
modern mainline kernel on SH4 you may need the above mentioned patches and some
attention to configuration option for SH4.

A note on sensor drivers:
As I need ov772x and tw9910 driver to be ported away from soc_camera for testing
on Migo-R, for each of them I have copied the driver first in
drivers/media/i2c/ from drivers/media/i2c/soc_camera without any modification
and then removed soc_camera dependencies in a separate commit to ease review.
As per the soc_camera based CEU platform driver, I have not removed the original
soc_camera based sensor drivers in this series.

Output of v4l2-compliance is available at:
https://paste.debian.net/995838/
I'm slightly confused about what the test application complains for
TRY_FMT/S_FMT but I judged this good enough for a first submission.

Thanks
  j

Jacopo Mondi (10):
  dt-bindings: media: Add Renesas CEU bindings
  include: media: Add Renesas CEU driver interface
  v4l: platform: Add Renesas CEU driver
  ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
  arch: sh: migor: Use new renesas-ceu camera driver
  sh: sh7722: Rename CEU clock
  v4l: i2c: Copy ov772x soc_camera sensor driver
  media: i2c: ov772x: Remove soc_camera dependencies
  v4l: i2c: Copy tw9910 soc_camera sensor driver
  media: i2c: tw9910: Remove soc_camera dependencies

 .../devicetree/bindings/media/renesas,ceu.txt  |   87 +
 arch/arm/boot/dts/r7s72100.dtsi|   12 +-
 arch/sh/boards/mach-migor/setup.c  |  164 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |2 +-
 drivers/media/i2c/Kconfig  |   21 +
 drivers/media/i2c/Makefile |2 +
 drivers/media/i2c/ov772x.c | 1156 +
 drivers/media/i2c/tw9910.c | 1037 
 drivers/media/platform/Kconfig |9 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/renesas-ceu.c   | 1766 
 include/media/drv-intf/renesas-ceu.h   |   23 +
 include/media/i2c/ov772x.h |3 +
 include/media/i2c/tw9910.h |6 +
 14 files changed, 4199 insertions(+), 91 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
 create mode 100644 drivers/media/i2c/ov772x.c
 create mode 100644 drivers/media/i2c/tw9910.c
 create mode 100644 drivers/media/platform/renesas-ceu.c
 create 

[PATCH v1 09/10] v4l: i2c: Copy tw9910 soc_camera sensor driver

[Jacopo Mondi]

Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/tw9910.c | 999 +
 1 file changed, 999 insertions(+)
 create mode 100644 drivers/media/i2c/tw9910.c

diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
new file mode 100644
index 000..bdb5e0a
--- /dev/null
+++ b/drivers/media/i2c/tw9910.c
@@ -0,0 +1,999 @@
+/*
+ * tw9910 Video Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov772x driver,
+ *
+ * Copyright (C) 2008 Kuninori Morimoto 
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define GET_ID(val)  ((val & 0xF8) >> 3)
+#define GET_REV(val) (val & 0x07)
+
+/*
+ * register offset
+ */
+#define ID 0x00 /* Product ID Code Register */
+#define STATUS10x01 /* Chip Status Register I */
+#define INFORM 0x02 /* Input Format */
+#define OPFORM 0x03 /* Output Format Control Register */
+#define DLYCTR 0x04 /* Hysteresis and HSYNC Delay Control */
+#define OUTCTR10x05 /* Output Control I */
+#define ACNTL1 0x06 /* Analog Control Register 1 */
+#define CROP_HI0x07 /* Cropping Register, High */
+#define VDELAY_LO  0x08 /* Vertical Delay Register, Low */
+#define VACTIVE_LO 0x09 /* Vertical Active Register, Low */
+#define HDELAY_LO  0x0A /* Horizontal Delay Register, Low */
+#define HACTIVE_LO 0x0B /* Horizontal Active Register, Low */
+#define CNTRL1 0x0C /* Control Register I */
+#define VSCALE_LO  0x0D /* Vertical Scaling Register, Low */
+#define SCALE_HI   0x0E /* Scaling Register, High */
+#define HSCALE_LO  0x0F /* Horizontal Scaling Register, Low */
+#define BRIGHT 0x10 /* BRIGHTNESS Control Register */
+#define CONTRAST   0x11 /* CONTRAST Control Register */
+#define SHARPNESS  0x12 /* SHARPNESS Control Register I */
+#define SAT_U  0x13 /* Chroma (U) Gain Register */
+#define SAT_V  0x14 /* Chroma (V) Gain Register */
+#define HUE0x15 /* Hue Control Register */
+#define CORING10x17
+#define CORING20x18 /* Coring and IF compensation */
+#define VBICNTL0x19 /* VBI Control Register */
+#define ACNTL2 0x1A /* Analog Control 2 */
+#define OUTCTR20x1B /* Output Control 2 */
+#define SDT0x1C /* Standard Selection */
+#define SDTR   0x1D /* Standard Recognition */
+#define TEST   0x1F /* Test Control Register */
+#define CLMPG  0x20 /* Clamping Gain */
+#define IAGC   0x21 /* Individual AGC Gain */
+#define AGCGAIN0x22 /* AGC Gain */
+#define PEAKWT 0x23 /* White Peak Threshold */
+#define CLMPL  0x24 /* Clamp level */
+#define SYNCT  0x25 /* Sync Amplitude */
+#define MISSCNT0x26 /* Sync Miss Count Register */
+#define PCLAMP 0x27 /* Clamp Position Register */
+#define VCNTL1 0x28 /* Vertical Control I */
+#define VCNTL2 0x29 /* Vertical Control II */
+#define CKILL  0x2A /* Color Killer Level Control */
+#define COMB   0x2B /* Comb Filter Control */
+#define LDLY   0x2C /* Luma Delay and H Filter Control */
+#define MISC1  0x2D /* Miscellaneous Control I */
+#define LOOP   0x2E /* LOOP Control Register */
+#define MISC2  0x2F /* Miscellaneous Control II */
+#define MVSN   0x30 /* Macrovision Detection */
+#define STATUS20x31 /* Chip STATUS II */
+#define HFREF  0x32 /* H monitor */
+#define CLMD   0x33 /* CLAMP MODE */
+#define IDCNTL 0x34 /* ID Detection Control */
+#define CLCNTL10x35 /* Clamp Control I */
+#define ANAPLLCTL  0x4C
+#define VBIMIN 0x4D
+#define HSLOWCTL   0x4E
+#define WSS3   0x4F
+#define FILLDATA   0x50
+#define SDID   0x51
+#define DID0x52
+#define WSS1   0x53
+#define WSS2   0x54
+#define VVBI   0x55
+#define LCTL6  0x56
+#define LCTL7  0x57
+#define LCTL8  0x58
+#define LCTL9  0x59
+#define LCTL10 0x5A
+#define LCTL11 0x5B
+#define LCTL12 0x5C
+#define LCTL13 0x5D
+#define LCTL14 0x5E
+#define LCTL15 

[PATCH v1 06/10] sh: sh7722: Rename CEU clock

[Jacopo Mondi]

Rename CEU clock to match the new platform driver name used in Migo-R.

There are no other sh7722 based devices Migo-R apart, so we can safely
rename this.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c 
b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
index 8f07a1a..d85091e 100644
--- a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
+++ b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
@@ -223,7 +223,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh-vou.0", _clks[HWBLK_VOU]),
CLKDEV_CON_ID("jpu0", _clks[HWBLK_JPU]),
CLKDEV_CON_ID("beu0", _clks[HWBLK_BEU]),
-   CLKDEV_DEV_ID("sh_mobile_ceu.0", _clks[HWBLK_CEU]),
+   CLKDEV_DEV_ID("renesas-ceu.0", _clks[HWBLK_CEU]),
CLKDEV_CON_ID("veu0", _clks[HWBLK_VEU]),
CLKDEV_CON_ID("vpu0", _clks[HWBLK_VPU]),
CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", _clks[HWBLK_LCDC]),
-- 
2.7.4

[PATCH] dvb_dev_get_fd(): return fd of local devices

[Rafaël Carré]

This makes it possible to poll a local device.
Getting the fd is preferrable to adding a dvb_dev_poll() function,
because we can poll several fds together in an event-based program.

This is not implemented for remote devices, as polling a remote fd
does not make sense.
We could instead return the socket to know when to expect messages
from the remote device, but the current implementation in
dvb-dev-remote.c already runs a thread to receive remote messages
as soon as possible.
---

Note, after reading README, I did not bump the library version.

Comments welcome

 lib/include/libdvbv5/dvb-dev.h | 12 
 lib/libdvbv5/dvb-dev-local.c   |  6 ++
 lib/libdvbv5/dvb-dev-priv.h|  1 +
 lib/libdvbv5/dvb-dev.c | 11 +++
 4 files changed, 30 insertions(+)

diff --git a/lib/include/libdvbv5/dvb-dev.h b/lib/include/libdvbv5/dvb-dev.h
index 98bee5e7..55e0f065 100644
--- a/lib/include/libdvbv5/dvb-dev.h
+++ b/lib/include/libdvbv5/dvb-dev.h
@@ -289,6 +289,18 @@ struct dvb_open_descriptor *dvb_dev_open(struct dvb_device 
*dvb,
  */
 void dvb_dev_close(struct dvb_open_descriptor *open_dev);
 
+/**
+ * @brief returns fd from a local device
+ * This will not work for remote devices.
+ * @ingroup dvb_device
+ *
+ * @param open_dev Points to the struct dvb_open_descriptor
+ *
+ * @return On success, returns the fd.
+ * Returns -1 on error.
+ */
+int dvb_dev_get_fd(struct dvb_open_descriptor *open_dev);
+
 /**
  * @brief read from a dvb demux or dvr file
  * @ingroup dvb_device
diff --git a/lib/libdvbv5/dvb-dev-local.c b/lib/libdvbv5/dvb-dev-local.c
index b50b61b4..eb2f0775 100644
--- a/lib/libdvbv5/dvb-dev-local.c
+++ b/lib/libdvbv5/dvb-dev-local.c
@@ -775,6 +775,11 @@ static void dvb_dev_local_free(struct dvb_device_priv *dvb)
free(priv);
 }
 
+static int dvb_local_get_fd(struct dvb_open_descriptor *open_dev)
+{
+return open_dev->fd;
+}
+
 /* Initialize for local usage */
 void dvb_dev_local_init(struct dvb_device_priv *dvb)
 {
@@ -788,6 +793,7 @@ void dvb_dev_local_init(struct dvb_device_priv *dvb)
ops->stop_monitor = dvb_local_stop_monitor;
ops->open = dvb_local_open;
ops->close = dvb_local_close;
+   ops->get_fd = dvb_local_get_fd;
 
ops->dmx_stop = dvb_local_dmx_stop;
ops->set_bufsize = dvb_local_set_bufsize;
diff --git a/lib/libdvbv5/dvb-dev-priv.h b/lib/libdvbv5/dvb-dev-priv.h
index e05fcad2..2e69f766 100644
--- a/lib/libdvbv5/dvb-dev-priv.h
+++ b/lib/libdvbv5/dvb-dev-priv.h
@@ -72,6 +72,7 @@ struct dvb_dev_ops {
int (*fe_get_stats)(struct dvb_v5_fe_parms *p);
 
void (*free)(struct dvb_device_priv *dvb);
+   int (*get_fd)(struct dvb_open_descriptor *dvb);
 };
 
 struct dvb_device_priv {
diff --git a/lib/libdvbv5/dvb-dev.c b/lib/libdvbv5/dvb-dev.c
index 7e2da1fb..447c9fd5 100644
--- a/lib/libdvbv5/dvb-dev.c
+++ b/lib/libdvbv5/dvb-dev.c
@@ -218,6 +218,17 @@ struct dvb_open_descriptor *dvb_dev_open(struct dvb_device 
*d,
return ops->open(dvb, sysname, flags);
 }
 
+int dvb_dev_get_fd(struct dvb_open_descriptor *open_dev)
+{
+   struct dvb_device_priv *dvb = (void *)open_dev;
+   struct dvb_dev_ops *ops = >ops;
+
+   if (!ops->get_fd)
+   return -1;
+
+   return ops->get_fd(open_dev);
+}
+
 void dvb_dev_close(struct dvb_open_descriptor *open_dev)
 {
struct dvb_device_priv *dvb = open_dev->dvb;
-- 
2.14.1

Re: [RFCv1 PATCH 0/6] v4l2-ctrls: implement requests

[Hans Verkuil]

Hi Alexandre,

On 15/11/17 10:38, Alexandre Courbot wrote:
> Hi Hans!
> 
> Thanks for the patchset! It looks quite good at first sight, a few comments 
> and
> questions follow though.
> 
> On Monday, November 13, 2017 11:34:02 PM JST, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Hi Alexandre,
>>
>> This is a first implementation of the request API in the
>> control framework. It is fairly simplistic at the moment in that
>> it just clones all the control values (so no refcounting yet for
>> values as Laurent proposed, I will work on that later). But this
>> should not be a problem for codecs since there aren't all that many
>> controls involved.
> 
> Regarding value refcounting, I think we can probably do without it if we parse
> the requests queue when looking values up. It may be more practical (having a
> kref for each v4l2_ctrl_ref in a request sounds overkill to me), and maybe 
> also
> more predictible since we would have less chance of having dangling old 
> values.
> 
>> The API is as follows:
>>
>> struct v4l2_ctrl_handler *v4l2_ctrl_request_alloc(void);
>>
>> This allocates a struct v4l2_ctrl_handler that is empty (i.e. has
>> no controls) but is refcounted and is marked as representing a
>> request.
>>
>> int v4l2_ctrl_request_clone(struct v4l2_ctrl_handler *hdl,
>> const struct v4l2_ctrl_handler *from,
>> bool (*filter)(const struct v4l2_ctrl *ctrl));
>>
>> Delete any existing controls in handler 'hdl', then clone the values
>> from an existing handler 'from' into 'hdl'. If 'from' == NULL, then
>> this just clears the handler. 'from' can either be another request
>> control handler or a regular control handler in which case the
>> current values are cloned. If 'filter' != NULL then you can
>> filter which controls you want to clone.
> 
> One thing that seems to be missing is, what happens if you try to set a 
> control
> on an empty request? IIUC this would currently fail because find_ref() would
> not be able to find the control. The value ref should probably be created in
> that case so we can create requests with a handful of controls.

Wasn't the intention that we never have an empty request but always clone?
I.e. in your code the _alloc call is always followed by a _clone call.

The reason I have a separate _alloc function is that you use that when you
want to create a new control handler ('new request'). If the user wants to 
reuse an
existing request, then _clone can be called directly on the existing handler.

> Also, if you clone a handler that is not a request, I understand that all
> controls will be deduplicated, creating a full-state copy? That could be 
> useful,
> but since this is the only way to make the current code work, I hope that the
> current impossibility to set a control on an empty request is a bug (or 
> misunderstanding from my part).

I think it is a misunderstanding. Seen from userspace you'll never have an empty
request.

> 
>>
>> void v4l2_ctrl_request_get(struct v4l2_ctrl_handler *hdl);
>>
>> Increase the refcount.
>>
>> void v4l2_ctrl_request_put(struct v4l2_ctrl_handler *hdl);
>>
>> Decrease the refcount and delete hdl if it reaches 0.
>>
>> void v4l2_ctrl_request_setup(struct v4l2_ctrl_handler *hdl);
>>
>> Apply the values from the handler (i.e. request object) to the
>> hardware.
>>
>> You will have to modify v4l_g/s/try_ext_ctrls in v4l2-ioctls.c to
>> obtain the request v4l2_ctrl_handler pointer based on the request
>> field in struct v4l2_ext_controls.
>>
>> The first patch in this series is necessary to avoid cloning
>> controls that belong to other devices (as opposed to the subdev
>> or bridge device for which you make a request). It can probably
>> be dropped for codecs, but it is needed for MC devices like
>> omap3isp.
>>
>> This series has only been compile tested! So if it crashes as
>> soon as you try to use it, then that's why :-)
>>
>> Note: I'm not sure if it makes sense to refcount the control
>> handler, you might prefer to have a refcount in a higher-level
>> request struct. If that's the case, then I can drop the _get
>> function and replace the _put function by a v4l2_ctrl_request_free()
>> function.
> 
> That's exactly what I thought when I saw the refcounting. This is probably a
> problem for later since we want to focus on codecs for now, but I think we 
> will
> ultimately want to manage refcounting outside of v4l2_ctrl_handler. Maybe a
> higher-level request class of which the current control-framework based design
> would be an implementation. I am thinking about IPs like the VSP1 which will
> probably want to model the controls either in a different way, or at least to
> add extra data beyond the controls.
> 
> All in all I think I can use this for codecs. I am still trying to shoehorn my
> first version into the media stuff, and to nobody's surprise this is not that
> easy. :P But the fact the control framework part is already mostly taken care
> 

Re: [RFCv1 PATCH 0/6] v4l2-ctrls: implement requests

[Alexandre Courbot]

Hi Hans!

Thanks for the patchset! It looks quite good at first sight, a few comments 
and

questions follow though.

On Monday, November 13, 2017 11:34:02 PM JST, Hans Verkuil wrote:

From: Hans Verkuil 

Hi Alexandre,

This is a first implementation of the request API in the
control framework. It is fairly simplistic at the moment in that
it just clones all the control values (so no refcounting yet for
values as Laurent proposed, I will work on that later). But this
should not be a problem for codecs since there aren't all that many
controls involved.


Regarding value refcounting, I think we can probably do without it if we 
parse
the requests queue when looking values up. It may be more practical (having 
a
kref for each v4l2_ctrl_ref in a request sounds overkill to me), and maybe 
also
more predictible since we would have less chance of having dangling old 
values.



The API is as follows:

struct v4l2_ctrl_handler *v4l2_ctrl_request_alloc(void);

This allocates a struct v4l2_ctrl_handler that is empty (i.e. has
no controls) but is refcounted and is marked as representing a
request.

int v4l2_ctrl_request_clone(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_handler *from,
bool (*filter)(const struct v4l2_ctrl *ctrl));

Delete any existing controls in handler 'hdl', then clone the values
from an existing handler 'from' into 'hdl'. If 'from' == NULL, then
this just clears the handler. 'from' can either be another request
control handler or a regular control handler in which case the
current values are cloned. If 'filter' != NULL then you can
filter which controls you want to clone.


One thing that seems to be missing is, what happens if you try to set a 
control
on an empty request? IIUC this would currently fail because find_ref() 
would
not be able to find the control. The value ref should probably be created 
in

that case so we can create requests with a handful of controls.

Also, if you clone a handler that is not a request, I understand that all
controls will be deduplicated, creating a full-state copy? That could be 
useful,
but since this is the only way to make the current code work, I hope that 
the
current impossibility to set a control on an empty request is a bug (or 
misunderstanding from my part).




void v4l2_ctrl_request_get(struct v4l2_ctrl_handler *hdl);

Increase the refcount.

void v4l2_ctrl_request_put(struct v4l2_ctrl_handler *hdl);

Decrease the refcount and delete hdl if it reaches 0.

void v4l2_ctrl_request_setup(struct v4l2_ctrl_handler *hdl);

Apply the values from the handler (i.e. request object) to the
hardware.

You will have to modify v4l_g/s/try_ext_ctrls in v4l2-ioctls.c to
obtain the request v4l2_ctrl_handler pointer based on the request
field in struct v4l2_ext_controls.

The first patch in this series is necessary to avoid cloning
controls that belong to other devices (as opposed to the subdev
or bridge device for which you make a request). It can probably
be dropped for codecs, but it is needed for MC devices like
omap3isp.

This series has only been compile tested! So if it crashes as
soon as you try to use it, then that's why :-)

Note: I'm not sure if it makes sense to refcount the control
handler, you might prefer to have a refcount in a higher-level
request struct. If that's the case, then I can drop the _get
function and replace the _put function by a v4l2_ctrl_request_free()
function.


That's exactly what I thought when I saw the refcounting. This is probably 
a
problem for later since we want to focus on codecs for now, but I think we 
will

ultimately want to manage refcounting outside of v4l2_ctrl_handler. Maybe a
higher-level request class of which the current control-framework based 
design
would be an implementation. I am thinking about IPs like the VSP1 which 
will
probably want to model the controls either in a different way, or at least 
to

add extra data beyond the controls.

All in all I think I can use this for codecs. I am still trying to shoehorn 
my
first version into the media stuff, and to nobody's surprise this is not 
that
easy. :P But the fact the control framework part is already mostly taken 
care

of greatly helps.

Thanks!
Alex.

Re: [RFC PATCH 0/5] Rockchip ISP1 Driver

[Tomasz Figa]

Hi Jacob,

Thanks for sending the series!

On Wed, Nov 15, 2017 at 3:29 PM, Jacob Chen  wrote:
> This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399 
> SoC.
>
> TODO:
>   - Thomas is rewriting the binding code between isp, phy, sensors, i hope we 
> could get suggestions.
> 
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/768633/2
> rules:
>   - There are many mipi interfaces("rx0", "dxrx0")(actually it also could 
> be parallel interface) in SoC and isp can decide which one will be used.
>   - Sometimes there will be more than one senor in a mipi phy, the 
> sofrware should decide which one is used(media link).
>   - rk3399 have two isp.

Also the two ISP subsystems have their own, completely different, CSI2
PHY blocks, so we need to make the ISP driver work with two different
PHY drivers.

>   - Add a dummy buffer(dma_alloc_coherent) so drvier won't hold buffer.
>   - Finish all TODO comments(mostly about hardware) in driver.
>
> To help do a quick review, i have push source code to my Github.
>   
> https://github.com/wzyy2/linux/tree/rkisp1/drivers/media/platform/rockchip/isp1
>
> Below are some infomations about driver/hardware:
>
> Rockchip ISP1 have many Hardware Blocks(simplied):
>
>   MIPI  --> ISP --> DCrop(Mainpath) --> RSZ(Mainpath) --> DMA(Mainpath)
>   DMA-Input --> --> DCrop(Selfpath) --> RSZ(Selfpath) --> DMA(Selfpath);)
>
> (Acutally the TRM(rk3288, isp) could be found online.. which contains a 
> more detailed block diagrams ;-P)
>
> The funcitons of each hardware block:
>
>   Mainpath : up to 4k resolution, support raw/yuv format
>   Selfpath : up tp 1080p, support rotate, support rgb/yuv format
>   RSZ: scaling
>   DCrop: crop
>   ISP: 3A, Color processing, Crop
>   MIPI: MIPI Camera interface
>
> Media pipelines:
>
>   Mainpath, Selfpath <-- ISP subdev <-- MIPI  <-- Sensor
>   3A stats   <--<-- 3A parms
>
> Code struct:
>
>   capture.c : Mainpath, Selfpath, RSZ, DCROP : capture device.
>   rkisp1.c : ISP : v4l2 sub-device.
>   isp_params.c : 3A parms : output device.
>   isp_stats.c : 3A stats : capture device.
>   mipi_dphy_sy.c : MIPI : sperated v4l2 sub-device.
>
> Usage:
>   ChromiumOS:
> use below v4l2-ctl command to capture frames.
>
>   v4l2-ctl --verbose -d /dev/video4 --stream-mmap=2
>   --stream-to=/tmp/stream.out --stream-count=60 --stream-poll
>
> use below command to playback the video on your PC.
>
>   mplayer /tmp/stream.out -loop 0 --demuxer=rawvideo
>   --rawvideo=w=800:h=600:size=$((800*600*2)):format=yuy2
> or
>   mplayer ./stream.out -loop 0 -demuxer rawvideo -rawvideo
>   w=800:h=600:size=$((800*600*2)):format=yuy2
>
>   Linux:
> use rkcamsrc gstreamer plugin(just a modified v4l2src) to preview.
>
>   gst-launch-1.0 rkcamsrc device=/dev/video0 io-mode=4 disable-3A=true
>   videoconvert ! video/x-raw,format=NV12,width=640,height=480 ! kmssink

Is the rkcamsrc plugin source available somewhere to download?

Thanks,
Tomasz

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

[Edgar Thier]

Hi,

I was wondering if there are any problems with my latest patch or if it simply 
slipped through.

Regards,

Edgar

On 10/12/2017 09:54 AM, Edgar Thier wrote:
> 
> Use flags the device exposes for UVC controls.
> This allows the device to define which property flags are set.
> 
> Since some cameras offer auto-adjustments for properties (e.g. auto-gain),
> the values of other properties (e.g. gain) can change in the camera.
> Examining the flags ensures that the driver is aware of such properties.
> 
> Signed-off-by: Edgar Thier 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 64 
> ++--
>  1 file changed, 49 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 20397aba..8f902a41 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1629,6 +1629,40 @@ static void uvc_ctrl_fixup_xu_info(struct uvc_device 
> *dev,
>   }
>  }
> 
> +/*
> + * Retrieve flags for a given control
> + */
> +static int uvc_ctrl_get_flags(struct uvc_device *dev, const struct 
> uvc_control *ctrl,
> + const struct uvc_control_info *info)
> +{
> + u8 *data;
> + int ret = 0;
> + int flags = 0;
> +
> + data = kmalloc(2, GFP_KERNEL);
> + if (data == NULL)
> + return -ENOMEM;
> +
> + ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
> +  info->selector, data, 1);
> + if (ret < 0) {
> + uvc_trace(UVC_TRACE_CONTROL,
> +   "GET_INFO failed on control %pUl/%u (%d).\n",
> +   info->entity, info->selector, ret);
> + } else {
> + flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
> + | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
> + | (data[0] & UVC_CONTROL_CAP_GET ?
> +UVC_CTRL_FLAG_GET_CUR : 0)
> + | (data[0] & UVC_CONTROL_CAP_SET ?
> +UVC_CTRL_FLAG_SET_CUR : 0)
> + | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
> +UVC_CTRL_FLAG_AUTO_UPDATE : 0);
> + }
> + kfree(data);
> + return flags;
> +}
> +
>  /*
>   * Query control information (size and flags) for XU controls.
>   */
> @@ -1636,6 +1670,7 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
>   const struct uvc_control *ctrl, struct uvc_control_info *info)
>  {
>   u8 *data;
> + int flags;
>   int ret;
> 
>   data = kmalloc(2, GFP_KERNEL);
> @@ -1659,24 +1694,15 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device 
> *dev,
> 
>   info->size = le16_to_cpup((__le16 *)data);
> 
> - /* Query the control information (GET_INFO) */
> - ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
> -  info->selector, data, 1);
> - if (ret < 0) {
> + flags = uvc_ctrl_get_flags(dev, ctrl, info);
> +
> + if (flags < 0) {
>   uvc_trace(UVC_TRACE_CONTROL,
> -   "GET_INFO failed on control %pUl/%u (%d).\n",
> -   info->entity, info->selector, ret);
> +   "Failed to retrieve flags (%d).\n", ret);
> + ret = flags;
>   goto done;
>   }
> -
> - info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX
> - | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF
> - | (data[0] & UVC_CONTROL_CAP_GET ?
> -UVC_CTRL_FLAG_GET_CUR : 0)
> - | (data[0] & UVC_CONTROL_CAP_SET ?
> -UVC_CTRL_FLAG_SET_CUR : 0)
> - | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ?
> -UVC_CTRL_FLAG_AUTO_UPDATE : 0);
> + info->flags = flags;
> 
>   uvc_ctrl_fixup_xu_info(dev, ctrl, info);
> 
> @@ -1890,6 +1916,7 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
> struct uvc_control *ctrl,
>   const struct uvc_control_info *info)
>  {
>   int ret = 0;
> + int flags = 0;
> 
>   ctrl->info = *info;
>   INIT_LIST_HEAD(>info.mappings);
> @@ -1902,6 +1929,13 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
> struct uvc_control *ctrl,
>   goto done;
>   }
> 
> + flags = uvc_ctrl_get_flags(dev, ctrl, info);
> + if (flags < 0)
> + uvc_trace(UVC_TRACE_CONTROL,
> +   "Failed to retrieve flags (%d).\n", ret);
> + else
> + ctrl->info.flags = flags;
> +
>   ctrl->initialized = 1;
> 
>   uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s "
>