[RFC] omap3isp: add support for CSI1 bus

[Pavel Machek]

omap3isp: add rest of CSI1 support

CSI1 needs one more bit to be set up. Do just that.

Signed-off-by: Pavel Machek 

---

Hmm. Looking at that... num_data_lanes probably should be modified in
local variable, not globally like this. Should I do that?

Anything else that needs fixing?

index 24a9fc5..6feba36 100644
--- a/drivers/media/platform/omap3isp/ispccp2.c
+++ b/drivers/media/platform/omap3isp/ispccp2.c
@@ -21,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "isp.h"
 #include "ispreg.h"
@@ -1149,6 +1152,7 @@ int omap3isp_ccp2_init(struct isp_device *isp)
"Could not get regulator vdds_csib\n");
ccp2->vdds_csib = NULL;
}
+   ccp2->phy = >isp_csiphy2;
} else if (isp->revision == ISP_REVISION_15_0) {
ccp2->phy = >isp_csiphy1;
}
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c 
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 50c0f64..cd6351b 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -197,9 +200,10 @@ static int omap3isp_csiphy_config(struct isp_csiphy *phy)
}
 
if (buscfg->interface == ISP_INTERFACE_CCP2B_PHY1
-   || buscfg->interface == ISP_INTERFACE_CCP2B_PHY2)
+   || buscfg->interface == ISP_INTERFACE_CCP2B_PHY2) {
lanes = >bus.ccp2.lanecfg;
-   else
+   phy->num_data_lanes = 1;
+   } else
lanes = >bus.csi2.lanecfg;
 
/* Clock and data lanes verification */
@@ -302,13 +306,16 @@ int omap3isp_csiphy_acquire(struct isp_csiphy *phy)
if (rval < 0)
goto done;
 
-   rval = csiphy_set_power(phy, ISPCSI2_PHY_CFG_PWR_CMD_ON);
-   if (rval) {
-   regulator_disable(phy->vdd);
-   goto done;
+   if (phy->isp->revision == ISP_REVISION_15_0) {
+   rval = csiphy_set_power(phy, ISPCSI2_PHY_CFG_PWR_CMD_ON);
+   if (rval) {
+   regulator_disable(phy->vdd);
+   goto done;
+   }
+   
+   csiphy_power_autoswitch_enable(phy, true);  
}
 
-   csiphy_power_autoswitch_enable(phy, true);
phy->phy_in_use = 1;
 
 done:

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


signature.asc
Description: Digital signature

[PATCH] v4l2-fwnode: Fix clock lane parsing

[Pavel Machek]

Fix clock lane parsing in v4l2-fwnode.

Signed-off-by: Pavel Machek 

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index dd3..44036b8 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -167,7 +167,7 @@ void v4l2_fwnode_endpoint_parse_csi1_bus(struct 
fwnode_handle *fwn,
bus->data_lane = v;
 
if (!fwnode_property_read_u32(fwn, "clock-lanes", ))
-   bus->data_lane = v;
+   bus->clock_lane = v;
 
if (bus_type == V4L2_FWNODE_BUS_TYPE_CCP2)
   vfwn->bus_type = V4L2_MBUS_CCP2;

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


signature.asc
Description: Digital signature

Re: [PATCH 1/4] v4l: vsp1: Implement partition algorithm restrictions

[Kuninori Morimoto]

Hi Laurent, Kieran

> > > Testing SRU-UDS scaling 768x576 - 768x576 - 640x480 in RGB24: fail
> > > Testing SRU-UDS scaling 768x576 - 768x576 - 768x576 in RGB24: pass
> > > Testing SRU-UDS scaling 768x576 - 768x576 - 1024x768 in RGB24: pass
> > > Testing SRU-UDS scaling 768x576 - 1536x1152 - 1280x960 in RGB24: pass
> > > Testing SRU-UDS scaling 768x576 - 1536x1152 - 1536x1152 in RGB24: pass
> > > Testing SRU-UDS scaling 768x576 - 1536x1152 - 2048x1536 in RGB24: pass
> > > Testing UDS-SRU scaling 768x576 - 640x480 - 640x480 in RGB24: pass
> > > Testing UDS-SRU scaling 768x576 - 640x480 - 1280x960 in RGB24: pass
> > > Testing UDS-SRU scaling 768x576 - 768x576 - 768x576 in RGB24: pass
> > > Testing UDS-SRU scaling 768x576 - 768x576 - 1536x1152 in RGB24: pass
> > > Testing UDS-SRU scaling 768x576 - 1024x768 - 1024x768 in RGB24: pass
> > > Testing UDS-SRU scaling 768x576 - 1024x768 - 2048x1536 in RGB24: pass
> > > Testing SRU-UDS scaling 768x576 - 768x576 - 640x480 in YUV444M: fail
> > > Testing SRU-UDS scaling 768x576 - 768x576 - 768x576 in YUV444M: pass
> > > Testing SRU-UDS scaling 768x576 - 768x576 - 1024x768 in YUV444M: pass
> > > Testing SRU-UDS scaling 768x576 - 1536x1152 - 1280x960 in YUV444M: pass
> > > Testing SRU-UDS scaling 768x576 - 1536x1152 - 1536x1152 in YUV444M: pass
> > > Testing SRU-UDS scaling 768x576 - 1536x1152 - 2048x1536 in YUV444M: hangs
> > > Testing UDS-SRU scaling 768x576 - 640x480 - 640x480 in YUV444M: pass
> > > Testing UDS-SRU scaling 768x576 - 640x480 - 1280x960 in YUV444M: fail
> > > Testing UDS-SRU scaling 768x576 - 768x576 - 768x576 in YUV444M: pass
> > > Testing UDS-SRU scaling 768x576 - 768x576 - 1536x1152 in YUV444M: pass
> > > Testing UDS-SRU scaling 768x576 - 1024x768 - 1024x768 in YUV444M: pass
> > > Testing UDS-SRU scaling 768x576 - 1024x768 - 2048x1536 in YUV444M: hangs
> > (snip)
> > > However, from the above tests it looks like the hardware can live with 
> > > more 
> > > relaxed restrictions than the ones implemented here. I haven't tested all 
> > > UDS 
> > > scaling ratios, and certainly not under all memory bus load conditions, I 
> > > might thus be too optimistic. Morimoto-san, would it be possible to get 
> > > more 
> > > information about this from the hardware team, to check whether the above 
> > > two 
> > > restrictions need to be honoured, or whether they come from an older 
> > > hardware 
> > > version ?
> > 
> > I asked it to HW team.
> > Please wait

I'm still waiting from HW team's response, but can you check
"32.3.7 Image partition for VSPI processing" on v0.53 datasheet ?
(v0.53 is for ES2.0, but this chapter should be same for ES1.x / ES2.0)
You may / may not find something from here

Best regards
---
Kuninori Morimoto

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Mon Mar  6 05:00:18 CET 2017
media-tree git hash:3dc2046ca78b3cac6c8c9098a4e3024cd91abdb4
media_build git hash:   9d6cebc34b27fea784dec19085970d9b4df9783e
v4l-utils git hash: 646bb9c368a8b65cdea6d934c9022067541d13a9
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: 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: ERRORS
linux-3.12.67-i686: ERRORS
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-i686: OK
linux-4.10-rc3-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: ERRORS
linux-3.12.67-x86_64: ERRORS
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: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[PATCH v2.1 3/3] v4l: vsp1: wpf: Implement rotation support

[Laurent Pinchart]

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

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Store controls in distinct fields instead of array.
---
 drivers/media/platform/vsp1/vsp1_rpf.c   |   2 +-
 drivers/media/platform/vsp1/vsp1_rwpf.c  |   5 +
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   7 +-
 drivers/media/platform/vsp1/vsp1_video.c |  12 +-
 drivers/media/platform/vsp1/vsp1_wpf.c   | 205 +++
 5 files changed, 177 insertions(+), 54 deletions(-)

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

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

[Russell King - ARM Linux]

On Sat, Mar 04, 2017 at 04:37:43PM -0800, Steve Longerbeam wrote:
> 
> 
> On 03/04/2017 02:56 AM, Sakari Ailus wrote:
> >That's a bit of a special situation --- still there are alike conditions on
> >existing hardware. You should return the buffers to the user with the ERROR
> >flag set --- or return -EIO from VIDIOC_DQBUF, if the condition will
> >persist:
> 
> On i.MX an EOF timeout is not recoverable without a stream restart, so
> I decided to call vb2_queue_error() when the timeout occurs (instead
> of sending an event). The user will then get -EIO when it attempts to
> queue or dequeue further buffers.

I'm not sure that statement is entirely accurate.  With the IMX219
camera, I _could_ (with previous iterations of the iMX capture code)
stop it streaming, wait a while, and restart it, and everything
continues to work.

Are you sure that the problem you have here is caused by the iMX6
rather than the ADV718x CVBS decoder (your initial description said
it was the decoder.)

If it _is_ the decoder that's going wrong, that doesn't justify
cripping the rest of the driver for one instance of broken hardware
that _might_ be attached to it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 2/3] v4l: vsp1: Extend VSP1 module API to allow DRM callbacks

[Kieran Bingham]

Hi Laurent,

On 05/03/17 21:58, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Sunday 05 Mar 2017 16:00:03 Kieran Bingham wrote:
>> To be able to perform page flips in DRM without flicker we need to be
>> able to notify the rcar-du module when the VSP has completed its
>> processing.
>>
>> We must not have bidirectional dependencies on the two components to
>> maintain support for loadable modules, thus we extend the API to allow
>> a callback to be registered within the VSP DRM interface.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_drm.c | 17 +
>>  drivers/media/platform/vsp1/vsp1_drm.h | 11 +++
>>  include/media/vsp1.h   | 13 +
>>  3 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
>> b/drivers/media/platform/vsp1/vsp1_drm.c index 4ee437c7ff0c..d93bf7d3a39e
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.c
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
>> @@ -37,6 +37,14 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
>>  vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
>>  }
>>
>> +static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
>> +{
>> +struct vsp1_drm *drm = to_vsp1_drm(pipe);
>> +
>> +if (drm->du_complete)
>> +drm->du_complete(drm->du_private);
>> +}
>> +
>>  /* 
>>   * DU Driver API
>>   */
>> @@ -96,6 +104,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct
>> vsp1_du_lif_config *cfg) }
>>
>>  pipe->num_inputs = 0;
>> +vsp1->drm->du_complete = NULL;
>>
>>  vsp1_dlm_reset(pipe->output->dlm);
>>  vsp1_device_put(vsp1);
>> @@ -200,6 +209,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct
>> vsp1_du_lif_config *cfg) if (ret < 0)
>>  return ret;
>>
>> +/*
>> + * Register a callback to allow us to notify the DRM framework of 
> frame
> 
> s/framework/driver/
> 
>> + * completion events.
>> + */
>> +vsp1->drm->du_complete = cfg->callback;
>> +vsp1->drm->du_private = cfg->callback_data;
>> +
>>  ret = media_pipeline_start(>output->entity.subdev.entity,
>>>pipe);
>>  if (ret < 0) {
>> @@ -607,6 +623,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
>>  pipe->lif = >lif->entity;
>>  pipe->output = vsp1->wpf[0];
>>  pipe->output->pipe = pipe;
>> +pipe->frame_end = vsp1_du_pipeline_frame_end;
>>
>>  return 0;
>>  }
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
>> b/drivers/media/platform/vsp1/vsp1_drm.h index c8d2f88fc483..3de2095cb0ce
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.h
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.h
>> @@ -23,6 +23,8 @@
>>   * @num_inputs: number of active pipeline inputs at the beginning of an
>> update
>>   * @inputs: source crop rectangle, destination compose rectangle and
>> z-order
>>   *  position for every input
>> + * @du_complete: frame completion callback for the DU driver (optional)
>> + * @du_private: data to be passed to the du_complete callback
>>   */
>>  struct vsp1_drm {
>>  struct vsp1_pipeline pipe;
>> @@ -33,8 +35,17 @@ struct vsp1_drm {
>>  struct v4l2_rect compose;
>>  unsigned int zpos;
>>  } inputs[VSP1_MAX_RPF];
>> +
>> +/* Frame syncronisation */
> 
> s/syncronisation/synchronisation/
> 
>> +void (*du_complete)(void *);
>> +void *du_private;
>>  };
>>
>> +static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
>> +{
>> +return container_of(pipe, struct vsp1_drm, pipe);
>> +}
>> +
>>  int vsp1_drm_init(struct vsp1_device *vsp1);
>>  void vsp1_drm_cleanup(struct vsp1_device *vsp1);
>>  int vsp1_drm_create_links(struct vsp1_device *vsp1);
>> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
>> index bfc701f04f3f..d59d0adf560d 100644
>> --- a/include/media/vsp1.h
>> +++ b/include/media/vsp1.h
>> @@ -20,9 +20,22 @@ struct device;
>>
>>  int vsp1_du_init(struct device *dev);
>>
>> +/**
>> + * struct vsp1_du_lif_config - VSP LIF configuration
>> + * @width: output frame width
>> + * @height: output frame height
>> + * @callback: frame completion callback function (optional)
>> + * @callback_data: data to be passed to the frame completion callback
>> + *
>> + * When the optional callback is provided to the VSP1, the VSP1 must
>> guarantee
>> + * that one completion callback is performed after every
>> vsp1_du_atomic_flush()
> 
> This paragraph should be part of the @callback documentation. I would phrase 
> it as
> 
>  * @callback: frame completion callback function (optional). When a callback
>  *  is provided, the VSP driver guarantees that it will be called
>  *  once and only once for each vsp1_du_atomic_flush() call.
> 
> With this fixed,
> 
> 

Re: [PATCH v3 3/3] drm: rcar-du: Register a completion callback with VSP1

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Sunday 05 Mar 2017 16:00:04 Kieran Bingham wrote:
> Currently we process page flip events on every display interrupt,
> however this does not take into consideration the processing time needed
> by the VSP1 utilised in the pipeline.
> 
> Register a callback with the VSP driver to obtain completion events, and
> track them so that we only perform page flips when the full display
> pipeline has completed for the frame.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  9 +
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 2aceb84fc15d..c1812e20
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -299,7 +299,7 @@ static void rcar_du_crtc_update_planes(struct
> rcar_du_crtc *rcrtc) * Page Flip
>   */
> 
> -static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
> +void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
>  {
>   struct drm_pending_vblank_event *event;
>   struct drm_device *dev = rcrtc->crtc.dev;
> @@ -571,6 +571,7 @@ static const struct drm_crtc_funcs crtc_funcs = {
>  static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
>  {
>   struct rcar_du_crtc *rcrtc = arg;
> + struct rcar_du_device *rcdu = rcrtc->group->dev;
>   irqreturn_t ret = IRQ_NONE;
>   u32 status;
> 
> @@ -579,7 +580,10 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
> 
>   if (status & DSSR_FRM) {
>   drm_crtc_handle_vblank(>crtc);
> - rcar_du_crtc_finish_page_flip(rcrtc);
> +
> + if (rcdu->info->gen < 3)
> + rcar_du_crtc_finish_page_flip(rcrtc);
> +
>   ret = IRQ_HANDLED;
>   }
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h index a7194812997e..ebdbff9d8e59
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -71,5 +71,6 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
> 
>  void rcar_du_crtc_route_output(struct drm_crtc *crtc,
>  enum rcar_du_output output);
> +void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
> 
>  #endif /* __RCAR_DU_CRTC_H__ */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index b0ff304ce3dc..cbb6f54c99ef
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -28,6 +28,13 @@
>  #include "rcar_du_kms.h"
>  #include "rcar_du_vsp.h"
> 
> +static void rcar_du_vsp_complete(void *private)
> +{
> + struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;

I'll remove the cast when applying, as pointed out by Sergei.

Reviewed-by: Laurent Pinchart 

> +
> + rcar_du_crtc_finish_page_flip(crtc);
> +}
> +
>  void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
>  {
>   const struct drm_display_mode *mode = >crtc.state-
>adjusted_mode;
> @@ -35,6 +42,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
>   struct vsp1_du_lif_config cfg = {
>   .width = mode->hdisplay,
>   .height = mode->vdisplay,
> + .callback = rcar_du_vsp_complete,
> + .callback_data = crtc,
>   };
>   struct rcar_du_plane_state state = {
>   .state = {

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 1/3] v4l: vsp1: Postpone frame end handling in event of display list race

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Sunday 05 Mar 2017 16:00:02 Kieran Bingham wrote:
> If we try to commit the display list while an update is pending, we have
> missed our opportunity. The display list manager will hold the commit
> until the next interrupt.
> 
> In this event, we skip the pipeline completion callback handler so that
> the pipeline will not mistakenly report frame completion to the user.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/vsp1/vsp1_dl.c   | 19 +--
>  drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
>  drivers/media/platform/vsp1/vsp1_pipe.c | 13 -
>  3 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index b9e5027778ff..f449ca689554
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -562,9 +562,19 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager
> *dlm) spin_unlock(>lock);
>  }
> 
> -void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
> +/**
> + * vsp1_dlm_irq_frame_end - Display list handler for the frame end
> interrupt + * @dlm: the display list manager
> + *
> + * Return true if the previous display list has completed at frame end, or
> false + * if it has been delayed by one frame because the display list
> commit raced + * with the frame end interrupt. The function always returns
> true in header mode + * as display list processing is then not continuous
> and races never occur. + */
> +bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
>  {
>   struct vsp1_device *vsp1 = dlm->vsp1;
> + bool completed = false;
> 
>   spin_lock(>lock);
> 
> @@ -576,8 +586,10 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager
> *dlm) * perform any operation as there can't be any new display list queued
> * in that case.
>*/
> - if (dlm->mode == VSP1_DL_MODE_HEADER)
> + if (dlm->mode == VSP1_DL_MODE_HEADER) {
> + completed = true;
>   goto done;
> + }
> 
>   /*
>* The UPD bit set indicates that the commit operation raced with the
> @@ -597,6 +609,7 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
> if (dlm->queued) {
>   dlm->active = dlm->queued;
>   dlm->queued = NULL;
> + completed = true;
>   }
> 
>   /*
> @@ -619,6 +632,8 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
> 
>  done:
>   spin_unlock(>lock);
> +
> + return completed;
>  }
> 
>  /* Hardware Setup */
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
> b/drivers/media/platform/vsp1/vsp1_dl.h index 7131aa3c5978..6ec1380a10af
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.h
> +++ b/drivers/media/platform/vsp1/vsp1_dl.h
> @@ -28,7 +28,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device
> *vsp1, void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
>  void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
>  void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
> -void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
> +bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
> 
>  struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
>  void vsp1_dl_list_put(struct vsp1_dl_list *dl);
> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
> b/drivers/media/platform/vsp1/vsp1_pipe.c index 35364f594e19..d15327701ad8
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> @@ -304,10 +304,21 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
> 
>  void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
>  {
> + bool completed;
> +
>   if (pipe == NULL)
>   return;
> 
> - vsp1_dlm_irq_frame_end(pipe->output->dlm);
> + completed = vsp1_dlm_irq_frame_end(pipe->output->dlm);
> + if (!completed) {
> + /*
> +  * If the DL commit raced with the frame end interrupt, the
> +  * commit ends up being postponed by one frame. Return
> +  * immediately without calling the pipeline's frame end 
handler
> +  * or incrementing the sequence number.
> +  */
> + return;
> + }
> 
>   if (pipe->frame_end)
>   pipe->frame_end(pipe);

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 2/3] v4l: vsp1: Extend VSP1 module API to allow DRM callbacks

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Sunday 05 Mar 2017 16:00:03 Kieran Bingham wrote:
> To be able to perform page flips in DRM without flicker we need to be
> able to notify the rcar-du module when the VSP has completed its
> processing.
> 
> We must not have bidirectional dependencies on the two components to
> maintain support for loadable modules, thus we extend the API to allow
> a callback to be registered within the VSP DRM interface.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 17 +
>  drivers/media/platform/vsp1/vsp1_drm.h | 11 +++
>  include/media/vsp1.h   | 13 +
>  3 files changed, 41 insertions(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c index 4ee437c7ff0c..d93bf7d3a39e
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -37,6 +37,14 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
>   vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
>  }
> 
> +static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
> +{
> + struct vsp1_drm *drm = to_vsp1_drm(pipe);
> +
> + if (drm->du_complete)
> + drm->du_complete(drm->du_private);
> +}
> +
>  /* 
>   * DU Driver API
>   */
> @@ -96,6 +104,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct
> vsp1_du_lif_config *cfg) }
> 
>   pipe->num_inputs = 0;
> + vsp1->drm->du_complete = NULL;
> 
>   vsp1_dlm_reset(pipe->output->dlm);
>   vsp1_device_put(vsp1);
> @@ -200,6 +209,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct
> vsp1_du_lif_config *cfg) if (ret < 0)
>   return ret;
> 
> + /*
> +  * Register a callback to allow us to notify the DRM framework of 
frame

s/framework/driver/

> +  * completion events.
> +  */
> + vsp1->drm->du_complete = cfg->callback;
> + vsp1->drm->du_private = cfg->callback_data;
> +
>   ret = media_pipeline_start(>output->entity.subdev.entity,
> >pipe);
>   if (ret < 0) {
> @@ -607,6 +623,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
>   pipe->lif = >lif->entity;
>   pipe->output = vsp1->wpf[0];
>   pipe->output->pipe = pipe;
> + pipe->frame_end = vsp1_du_pipeline_frame_end;
> 
>   return 0;
>  }
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
> b/drivers/media/platform/vsp1/vsp1_drm.h index c8d2f88fc483..3de2095cb0ce
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.h
> +++ b/drivers/media/platform/vsp1/vsp1_drm.h
> @@ -23,6 +23,8 @@
>   * @num_inputs: number of active pipeline inputs at the beginning of an
> update
>   * @inputs: source crop rectangle, destination compose rectangle and
> z-order
>   *   position for every input
> + * @du_complete: frame completion callback for the DU driver (optional)
> + * @du_private: data to be passed to the du_complete callback
>   */
>  struct vsp1_drm {
>   struct vsp1_pipeline pipe;
> @@ -33,8 +35,17 @@ struct vsp1_drm {
>   struct v4l2_rect compose;
>   unsigned int zpos;
>   } inputs[VSP1_MAX_RPF];
> +
> + /* Frame syncronisation */

s/syncronisation/synchronisation/

> + void (*du_complete)(void *);
> + void *du_private;
>  };
> 
> +static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
> +{
> + return container_of(pipe, struct vsp1_drm, pipe);
> +}
> +
>  int vsp1_drm_init(struct vsp1_device *vsp1);
>  void vsp1_drm_cleanup(struct vsp1_device *vsp1);
>  int vsp1_drm_create_links(struct vsp1_device *vsp1);
> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> index bfc701f04f3f..d59d0adf560d 100644
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -20,9 +20,22 @@ struct device;
> 
>  int vsp1_du_init(struct device *dev);
> 
> +/**
> + * struct vsp1_du_lif_config - VSP LIF configuration
> + * @width: output frame width
> + * @height: output frame height
> + * @callback: frame completion callback function (optional)
> + * @callback_data: data to be passed to the frame completion callback
> + *
> + * When the optional callback is provided to the VSP1, the VSP1 must
> guarantee
> + * that one completion callback is performed after every
> vsp1_du_atomic_flush()

This paragraph should be part of the @callback documentation. I would phrase 
it as

 * @callback: frame completion callback function (optional). When a callback
 *is provided, the VSP driver guarantees that it will be called
 *once and only once for each vsp1_du_atomic_flush() call.

With this fixed,

Reviewed-by: Laurent Pinchart 

If you're fine with the above changes there's no need to resubmit, I'll fix 
when applying the patch.

> + */
>  

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

[Sakari Ailus]

On Sat, Mar 04, 2017 at 04:37:43PM -0800, Steve Longerbeam wrote:
> 
> 
> On 03/04/2017 02:56 AM, Sakari Ailus wrote:
> >Hi Steve,
> >
> >On Fri, Mar 03, 2017 at 02:43:51PM -0800, Steve Longerbeam wrote:
> >>
> >>
> >>On 03/03/2017 03:45 AM, Sakari Ailus wrote:
> >>>On Thu, Mar 02, 2017 at 03:07:21PM -0800, Steve Longerbeam wrote:
> 
> 
> On 03/02/2017 07:53 AM, Sakari Ailus wrote:
> >Hi Steve,
> >
> >On Wed, Feb 15, 2017 at 06:19:15PM -0800, Steve Longerbeam wrote:
> >>Add a new FRAME_TIMEOUT event to signal that a video capture or
> >>output device has timed out waiting for reception or transmit
> >>completion of a video frame.
> >>
> >>Signed-off-by: Steve Longerbeam 
> >>---
> >>Documentation/media/uapi/v4l/vidioc-dqevent.rst | 5 +
> >>Documentation/media/videodev2.h.rst.exceptions  | 1 +
> >>include/uapi/linux/videodev2.h  | 1 +
> >>3 files changed, 7 insertions(+)
> >>
> >>diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
> >>b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> >>index 8d663a7..dd77d9b 100644
> >>--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> >>+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> >>@@ -197,6 +197,11 @@ call.
> >>the regions changes. This event has a struct
> >>:c:type:`v4l2_event_motion_det`
> >>associated with it.
> >>+* - ``V4L2_EVENT_FRAME_TIMEOUT``
> >>+  - 7
> >>+  - This event is triggered when the video capture or output device
> >>+   has timed out waiting for the reception or transmit completion 
> >>of
> >>+   a frame of video.
> >
> >As you're adding a new interface, I suppose you have an implementation
> >around. How do you determine what that timeout should be?
> 
> The imx-media driver sets the timeout to 1 second, or 30 frame
> periods at 30 fps.
> >>>
> >>>The frame rate is not necessarily constant during streaming. It may well
> >>>change as a result of lighting conditions.
> >>
> >>I think you mean that would be a _temporary_ change in frame rate, but
> >>yes I agree the data rate can temporarily fluctuate. Although I doubt
> >>lighting conditions would cause a sensor to pause data transmission
> >>for a full 1 second.
> >
> >Likely not, at least not in typical conditions. The exposure time is still
> >quite specific to applications: it could be minutes if you take photos e.g.
> >of the night sky.
> >
> >What I'm saying here is that any static value is likely not both reasonable
> >and workable in all potential situations all the time. Still there are cases
> >(as yours below) that may happen in relatively common cases on some hardware
> >(more common than taking long exposure photos of the night sky with the said
> >hardware :)).
> 
> I doubt night photography will ever be a use-case for i.MX. The most
> common use-case for this driver will be used in automotive applications
> such as rear-view or 360 degree view cameras.

Ack.

> 
> 
> >
> >>
> >>
> >>>I wouldn't add an event for this:
> >>>this is unreliable and 30 times the frame period is an arbitrary value
> >>>anyway. No other drivers do this either.
> >>
> >>If no other drivers do this I don't mind removing it. It is really meant
> >>to deal with the ADV718x CVBS decoder, which often simply stops sending
> >>data on the BT.656 bus if there is an interruption in the input analog
> >>signal. But I agree that user space could detect this timeout instead.
> >>Unless I hear from someone else that they would like to keep this
> >>feature I'll remove it in version 5.
> >
> >That's a bit of a special situation --- still there are alike conditions on
> >existing hardware. You should return the buffers to the user with the ERROR
> >flag set --- or return -EIO from VIDIOC_DQBUF, if the condition will
> >persist:
> 
> On i.MX an EOF timeout is not recoverable without a stream restart, so
> I decided to call vb2_queue_error() when the timeout occurs (instead
> of sending an event). The user will then get -EIO when it attempts to
> queue or dequeue further buffers.

It believe that's the correct thing to do.

> 
> 
> >
> >
> >
> >Do you already obtain the frame rate from the image source (e.g. tuner,
> >sensor, decoder) and multiply the frame time by some number in the current
> >implementation?
> 
> No the timeout is a constant value, regardless of the source frame
> rate. Should the timeout be based on a constant time, or based on a
> constant # of frames? I really don't think it matters much, what matters
> is that it be long enough to be reasonably sure no data is forthcoming,
> for most use-cases.

That should be fine. If there is a use case that requires something else,
then the implementation can be changed: it's not visible to the user space
anyway.

-- 

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

[Laurent Pinchart]

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

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

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

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

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

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

Signed-off-by: Laurent Pinchart 
Acked-by: Sakari Ailus 
---
Changes since v2.1:

- Fixed small issues in commit message
- Simplified wording of one sentence in the documentation

Changes since v2:

- Document the interaction with ioctls that can affect formats
  (VIDIOC_S_SELECTION, VIDIOC_S_INPUT, VIDIOC_S_OUTPUT, VIDIOC_S_STD and
  VIDIOC_S_DV_TIMINGS)
- Clarify the format/control change order
---
 Documentation/media/uapi/v4l/buffer.rst | 108 
 1 file changed, 108 insertions(+)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ac58966ccb9b..60d62a5824f8 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -34,6 +34,114 @@ flags are copied from the OUTPUT video buffer to the 
CAPTURE video
 buffer.
 
 
+Interactions between formats, controls and buffers
+==
+
+V4L2 exposes parameters that influence the buffer size, or the way data is
+laid out in the buffer. Those parameters are exposed through both formats and
+controls. One example of such a control is the ``V4L2_CID_ROTATE`` control
+that modifies the direction in which pixels are stored in the buffer, as well
+as the buffer size when the selected format includes padding at the end of
+lines.
+
+The set of information needed to interpret the content of a buffer (e.g. the
+pixel format, the line stride, the tiling orientation or the rotation) is
+collectively referred to in the rest of this section as the buffer layout.
+
+Modifying formats or controls that influence the buffer size or layout require
+the stream to be stopped. Any attempt at such a modification while the stream
+is active shall cause the ioctl setting the format or the control to return
+the ``EBUSY`` error code.
+
+Controls that only influence the buffer layout can be modified at any time
+when the stream is stopped. As they don't influence the buffer size, no
+special handling is needed to synchronize those controls with buffer
+allocation.
+
+Formats and controls that influence the buffer size interact with buffer
+allocation. As buffer allocation is an expensive operation, drivers should
+allow format or controls that influence the buffer size to be changed with
+buffers allocated. A typical ioctl sequence to modify format and controls is
+
+ #. VIDIOC_STREAMOFF
+ #. VIDIOC_S_EXT_CTRLS
+ #. VIDIOC_S_FMT
+ #. VIDIOC_QBUF
+ #. VIDIOC_STREAMON
+
+.. note::
+
+   The API doesn't mandate the above order for control (2.) and format (3.)
+   changes. Format and controls can be set in a different order, or even
+   interleaved, depending on the device and use case. For instance some
+   controls might behave differently for different pixel formats, in which
+   case the format might need to be set first.
+
+Queued buffers must be large enough for the new format or controls.
+
+Drivers shall return a ``ENOSPC`` error in response to format change

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

[Sakari Ailus]

Hi Laurent,

Thanks for the update.

On Sun, Mar 05, 2017 at 04:39:36PM +0200, Laurent Pinchart wrote:
> V4L2 exposes parameters that influence buffers sizes through the format
> ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly
> VIDIOC_G_SELECTION and VIDIOC_S_SELECTION). Other parameters not part of
> the format structure may also influence buffer sizes or buffer layout in
> general. One existing such parameter is rotation, which is implemented
> by the VIDIOC_ROTATE control and thus exposed through the V4L2 control

V4L2_CID_ROTATE

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

It's say it's a patch, and most kernel developers seem to agree:

$ git log v4.9..v4.10|grep -ci
'this patch'
1816
$ git log v4.9..v4.10|grep -ci
'this commit'
217

Up to you. :-)

> formats, selections, controls and buffers.
> 
> The preparatory discussions for the documentation change considered
> completely disallowing controls that change the buffer size or layout,
> in favour of extending the format API with a new ioctl that would bundle
> those controls with format information. The idea has been rejected, as
> this would essentially be a restricted version of the upcoming request
> API that wouldn't bring any additional value.
> 
> Another option we have considered was to mandate the use of the request
> API to modify controls that influence buffer size or layout. This has
> also been rejected on the grounds that requiring the request API to
> change rotation even when streaming is stopped would significantly
> complicate implementation of drivers and usage of the V4L2 API for
> applications.
> 
> Applications will however be required to use the upcoming request API to
> change at runtime formats or controls that influence the buffer size or
> layout, because of the need to synchronize buffers with the formats and
> controls. Otherwise there would be no way to interpret the content of a
> buffer correctly.
> 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v2:
> 
> - Document the interaction with ioctls that can affect formats
>   (VIDIOC_S_SELECTION, VIDIOC_S_INPUT, VIDIOC_S_OUTPUT, VIDIOC_S_STD and
>   VIDIOC_S_DV_TIMINGS)
> - Clarify the format/control change order
> ---
>  Documentation/media/uapi/v4l/buffer.rst | 108 
> 
>  1 file changed, 108 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index ac58966ccb9b..ce46908bedfb 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -34,6 +34,114 @@ flags are copied from the OUTPUT video buffer to the 
> CAPTURE video
>  buffer.
>  
>  
> +Interactions between formats, controls and buffers
> +==
> +
> +V4L2 exposes parameters that influence the buffer size, or the way data is
> +laid out in the buffer. Those parameters are exposed through both formats and
> +controls. One example of such a control is the ``V4L2_CID_ROTATE`` control
> +that modifies the direction in which pixels are stored in the buffer, as well
> +as the buffer size when the selected format includes padding at the end of
> +lines.
> +
> +The set of information needed to interpret the content of a buffer (e.g. the
> +pixel format, the line stride, the tiling orientation or the rotation) is
> +collectively referred to in the rest of this section as the buffer layout.
> +
> +Modifying formats or controls that influence the buffer size or layout 
> require
> +the stream to be stopped. Any attempt at such a modification while the stream
> +is active shall cause the format or control set ioctl to return the ``EBUSY``

How about:

s/the format or control set ioctl/the ioctl setting the format or the
control/

> +error code.
> +
> +Controls that only influence the buffer layout can be modified at any time
> +when the stream is stopped. As they don't influence the buffer size, no
> +special handling is needed to synchronize those controls with buffer
> +allocation.
> +
> +Formats and controls that influence the buffer size interact with buffer
> +allocation. As buffer allocation is an expensive operation, drivers should
> +allow format or controls that influence the buffer size to be changed with
> +buffers allocated. A typical ioctl sequence to modify format and controls is
> +
> + #. VIDIOC_STREAMOFF
> + #. VIDIOC_S_EXT_CTRLS
> + #. VIDIOC_S_FMT
> + #. VIDIOC_QBUF
> + #. VIDIOC_STREAMON
> +
> +.. note::
> +
> +   The API doesn't mandate the above order for control (2.) and format (3.)
> +   

Re: [Outreachy kernel] [PATCH] staging: media: Remove unnecessary function and its call

[Joe Perches]

On Sun, 2017-03-05 at 10:14 -0800, Alison Schofield wrote:
> On Sun, Mar 05, 2017 at 12:17:21PM +0530, simran singhal wrote:
> > The function atomisp_set_stop_timeout on being called, simply returns
> > back. The function hasn't been mentioned in the TODO and doesn't have
> > FIXME code around. Hence, atomisp_set_stop_timeout and its calls have been
> > removed.
> > 
> > Signed-off-by: simran singhal 
> > ---
> 
> Hi Simran,
> 
> It's helpful to state right in the subject line what you removed.
> ie.  remove unused function atomisp_set_stop_timeout()
> 
> If you do that, scan's or grep'ing the git log pretty oneline's can 
> easily see this without having to dig into the log.
> 
> (gitpretty='git log --pretty=oneline --abbrev-commit')
> 
> Can you share to Outreachy group how you found this?  By inspection
> or otherwise??

At least for the rtl8192u patch submitted:

It's also helpful to read the comment you remove
and determine if what you are doing is the correct
thing to do and explain why it's OK in the commit
message. (fractured english below notwithstanding)

 /* These function were added to load crypte module autoly */
-   ieee80211_tkip_null();
 

Re: [Outreachy kernel] [PATCH] staging: media: Remove unnecessary function and its call

[Alison Schofield]

On Sun, Mar 05, 2017 at 12:17:21PM +0530, simran singhal wrote:
> The function atomisp_set_stop_timeout on being called, simply returns
> back. The function hasn't been mentioned in the TODO and doesn't have
> FIXME code around. Hence, atomisp_set_stop_timeout and its calls have been
> removed.
> 
> Signed-off-by: simran singhal 
> ---

Hi Simran,

It's helpful to state right in the subject line what you removed.
ie.  remove unused function atomisp_set_stop_timeout()

If you do that, scan's or grep'ing the git log pretty oneline's can 
easily see this without having to dig into the log.

(gitpretty='git log --pretty=oneline --abbrev-commit')

Can you share to Outreachy group how you found this?  By inspection
or otherwise??

Thanks,
alisons


alisons


>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c  | 1 -
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h   | 1 -
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c | 5 -
>  3 files changed, 7 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> index e99f7b8..66299dd 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> @@ -1700,7 +1700,6 @@ void atomisp_wdt_work(struct work_struct *work)
>   }
>   }
>  #endif
> - atomisp_set_stop_timeout(ATOMISP_CSS_STOP_TIMEOUT_US);
>   dev_err(isp->dev, "timeout recovery handling done\n");
>   atomic_set(>wdt_work_queued, 0);
>  
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h 
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h
> index 5a404e4..0b9ced5 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h
> @@ -660,7 +660,6 @@ int atomisp_css_set_acc_parameters(struct atomisp_acc_fw 
> *acc_fw);
>  int atomisp_css_isr_thread(struct atomisp_device *isp,
>  bool *frame_done_found,
>  bool *css_pipe_done);
> -void atomisp_set_stop_timeout(unsigned int timeout);
>  
>  bool atomisp_css_valid_sof(struct atomisp_device *isp);
>  
> diff --git 
> a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
> index 6697d72..cfa0ad4 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
> @@ -4699,11 +4699,6 @@ int atomisp_css_isr_thread(struct atomisp_device *isp,
>   return 0;
>  }
>  
> -void atomisp_set_stop_timeout(unsigned int timeout)
> -{
> - return;
> -}
> -
>  bool atomisp_css_valid_sof(struct atomisp_device *isp)
>  {
>   unsigned int i, j;
> -- 
> 2.7.4
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170305064721.GA22548%40singhal-Inspiron-5558.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v3 3/3] drm: rcar-du: Register a completion callback with VSP1

[Sergei Shtylyov]

Hello!

On 03/05/2017 07:00 PM, Kieran Bingham wrote:


Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.

Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.

Signed-off-by: Kieran Bingham 

[...]

 #endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..cbb6f54c99ef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,13 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"

+static void rcar_du_vsp_complete(void *private)
+{
+   struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;


   No need for explicit cast.


+
+   rcar_du_crtc_finish_page_flip(crtc);
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;

[...]

MBR, Sergei

[PATCH v3 2/3] v4l: vsp1: Extend VSP1 module API to allow DRM callbacks

[Kieran Bingham]

To be able to perform page flips in DRM without flicker we need to be
able to notify the rcar-du module when the VSP has completed its
processing.

We must not have bidirectional dependencies on the two components to
maintain support for loadable modules, thus we extend the API to allow
a callback to be registered within the VSP DRM interface.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 17 +
 drivers/media/platform/vsp1/vsp1_drm.h | 11 +++
 include/media/vsp1.h   | 13 +
 3 files changed, 41 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 4ee437c7ff0c..d93bf7d3a39e 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -37,6 +37,14 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
 }
 
+static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm *drm = to_vsp1_drm(pipe);
+
+   if (drm->du_complete)
+   drm->du_complete(drm->du_private);
+}
+
 /* 
-
  * DU Driver API
  */
@@ -96,6 +104,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
}
 
pipe->num_inputs = 0;
+   vsp1->drm->du_complete = NULL;
 
vsp1_dlm_reset(pipe->output->dlm);
vsp1_device_put(vsp1);
@@ -200,6 +209,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
if (ret < 0)
return ret;
 
+   /*
+* Register a callback to allow us to notify the DRM framework of frame
+* completion events.
+*/
+   vsp1->drm->du_complete = cfg->callback;
+   vsp1->drm->du_private = cfg->callback_data;
+
ret = media_pipeline_start(>output->entity.subdev.entity,
  >pipe);
if (ret < 0) {
@@ -607,6 +623,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
pipe->lif = >lif->entity;
pipe->output = vsp1->wpf[0];
pipe->output->pipe = pipe;
+   pipe->frame_end = vsp1_du_pipeline_frame_end;
 
return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index c8d2f88fc483..3de2095cb0ce 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -23,6 +23,8 @@
  * @num_inputs: number of active pipeline inputs at the beginning of an update
  * @inputs: source crop rectangle, destination compose rectangle and z-order
  * position for every input
+ * @du_complete: frame completion callback for the DU driver (optional)
+ * @du_private: data to be passed to the du_complete callback
  */
 struct vsp1_drm {
struct vsp1_pipeline pipe;
@@ -33,8 +35,17 @@ struct vsp1_drm {
struct v4l2_rect compose;
unsigned int zpos;
} inputs[VSP1_MAX_RPF];
+
+   /* Frame syncronisation */
+   void (*du_complete)(void *);
+   void *du_private;
 };
 
+static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
+{
+   return container_of(pipe, struct vsp1_drm, pipe);
+}
+
 int vsp1_drm_init(struct vsp1_device *vsp1);
 void vsp1_drm_cleanup(struct vsp1_device *vsp1);
 int vsp1_drm_create_links(struct vsp1_device *vsp1);
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index bfc701f04f3f..d59d0adf560d 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -20,9 +20,22 @@ struct device;
 
 int vsp1_du_init(struct device *dev);
 
+/**
+ * struct vsp1_du_lif_config - VSP LIF configuration
+ * @width: output frame width
+ * @height: output frame height
+ * @callback: frame completion callback function (optional)
+ * @callback_data: data to be passed to the frame completion callback
+ *
+ * When the optional callback is provided to the VSP1, the VSP1 must guarantee
+ * that one completion callback is performed after every vsp1_du_atomic_flush()
+ */
 struct vsp1_du_lif_config {
unsigned int width;
unsigned int height;
+
+   void (*callback)(void *);
+   void *callback_data;
 };
 
 int vsp1_du_setup_lif(struct device *dev, const struct vsp1_du_lif_config 
*cfg);
-- 
git-series 0.9.1

[PATCH v3 0/3] RCAR-DU, VSP1: Prevent pre-emptive frame flips on VSP1-DRM pipelines

[Kieran Bingham]

The RCAR-DU utilises a running VSPD pipeline to perform processing for the
display pipeline. This presents the opportunity for some race conditions to
affect the quality of the display output.

To prevent reporting page flips early, we must track this timing through the
VSP1, and only allow the rcar-du object to report the page-flip completion
event after the VSP1 has processed.

This series ensures that tearing and flicker is prevented, without introducing 
the
performance impact mentioned in the previous series.

[PATCH 1/3] handles potential race conditions in vsp1_dlm_irq_frame_end() and
prevents signalling the frame end in this event.
[PATCH 2/3] extends the VSP1 to allow a callback to be registered giving the
VSP1 the ability to notify completion events.
[PATCH 3/3] utilises the callback extension to send page flips at the end of
VSP processing for Gen3 platforms.

These patches have been tested by introducing artificial delays in the commit
code paths and verifying that no visual tearing or flickering occurs.

Extensive testing around the race window has been performed by dynamically
adapting the artificial delay between 10, and 17 seconds in 100uS increments
for periods of 5 seconds on each delay test. These tests have successfully run
for 3 hours.

Manual start/stop testing has also been performed.

Kieran Bingham (3):
  v4l: vsp1: Postpone frame end handling in event of display list race
  v4l: vsp1: Extend VSP1 module API to allow DRM callbacks
  drm: rcar-du: Register a completion callback with VSP1

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  8 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  9 +
 drivers/media/platform/vsp1/vsp1_dl.c   | 19 +--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c  | 17 +
 drivers/media/platform/vsp1/vsp1_drm.h  | 11 +++
 drivers/media/platform/vsp1/vsp1_pipe.c | 13 -
 include/media/vsp1.h| 13 +
 9 files changed, 87 insertions(+), 6 deletions(-)

base-commit: cdb5795cbc4ddbe5082c25c52ebc1d811ac3849e
-- 
git-series 0.9.1

[PATCH v3 1/3] v4l: vsp1: Postpone frame end handling in event of display list race

[Kieran Bingham]

If we try to commit the display list while an update is pending, we have
missed our opportunity. The display list manager will hold the commit
until the next interrupt.

In this event, we skip the pipeline completion callback handler so that
the pipeline will not mistakenly report frame completion to the user.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c   | 19 +--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_pipe.c | 13 -
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index b9e5027778ff..f449ca689554 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -562,9 +562,19 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager 
*dlm)
spin_unlock(>lock);
 }
 
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+/**
+ * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
+ * @dlm: the display list manager
+ *
+ * Return true if the previous display list has completed at frame end, or 
false
+ * if it has been delayed by one frame because the display list commit raced
+ * with the frame end interrupt. The function always returns true in header 
mode
+ * as display list processing is then not continuous and races never occur.
+ */
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
struct vsp1_device *vsp1 = dlm->vsp1;
+   bool completed = false;
 
spin_lock(>lock);
 
@@ -576,8 +586,10 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 * perform any operation as there can't be any new display list queued
 * in that case.
 */
-   if (dlm->mode == VSP1_DL_MODE_HEADER)
+   if (dlm->mode == VSP1_DL_MODE_HEADER) {
+   completed = true;
goto done;
+   }
 
/*
 * The UPD bit set indicates that the commit operation raced with the
@@ -597,6 +609,7 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
if (dlm->queued) {
dlm->active = dlm->queued;
dlm->queued = NULL;
+   completed = true;
}
 
/*
@@ -619,6 +632,8 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 
 done:
spin_unlock(>lock);
+
+   return completed;
 }
 
 /* Hardware Setup */
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index 7131aa3c5978..6ec1380a10af 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -28,7 +28,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
 
 struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
 void vsp1_dl_list_put(struct vsp1_dl_list *dl);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 35364f594e19..d15327701ad8 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -304,10 +304,21 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
 
 void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
 {
+   bool completed;
+
if (pipe == NULL)
return;
 
-   vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   completed = vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   if (!completed) {
+   /*
+* If the DL commit raced with the frame end interrupt, the
+* commit ends up being postponed by one frame. Return
+* immediately without calling the pipeline's frame end handler
+* or incrementing the sequence number.
+*/
+   return;
+   }
 
if (pipe->frame_end)
pipe->frame_end(pipe);
-- 
git-series 0.9.1

[PATCH v3 3/3] drm: rcar-du: Register a completion callback with VSP1

[Kieran Bingham]

Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.

Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  9 +
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 2aceb84fc15d..c1812e20 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -299,7 +299,7 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
  * Page Flip
  */
 
-static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
 {
struct drm_pending_vblank_event *event;
struct drm_device *dev = rcrtc->crtc.dev;
@@ -571,6 +571,7 @@ static const struct drm_crtc_funcs crtc_funcs = {
 static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 {
struct rcar_du_crtc *rcrtc = arg;
+   struct rcar_du_device *rcdu = rcrtc->group->dev;
irqreturn_t ret = IRQ_NONE;
u32 status;
 
@@ -579,7 +580,10 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 
if (status & DSSR_FRM) {
drm_crtc_handle_vblank(>crtc);
-   rcar_du_crtc_finish_page_flip(rcrtc);
+
+   if (rcdu->info->gen < 3)
+   rcar_du_crtc_finish_page_flip(rcrtc);
+
ret = IRQ_HANDLED;
}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index a7194812997e..ebdbff9d8e59 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -71,5 +71,6 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
 
 void rcar_du_crtc_route_output(struct drm_crtc *crtc,
   enum rcar_du_output output);
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
 
 #endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..cbb6f54c99ef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,13 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
 
+static void rcar_du_vsp_complete(void *private)
+{
+   struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;
+
+   rcar_du_crtc_finish_page_flip(crtc);
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;
@@ -35,6 +42,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
struct vsp1_du_lif_config cfg = {
.width = mode->hdisplay,
.height = mode->vdisplay,
+   .callback = rcar_du_vsp_complete,
+   .callback_data = crtc,
};
struct rcar_du_plane_state state = {
.state = {
-- 
git-series 0.9.1

[PATCH] [dtv-scan-tables] [atsc] Add a new list for USA/CAN. Remove channels 52 thru 69 for those in the USA or Canada who may want to save a few clock cycles avoiding scanning through ch 52 to 69.

[Bill Murphy]

Signed-off-by: Bill Murphy 
---
 atsc/us-ATSC-center-frequencies-8VSB-062009 | 306 
 1 file changed, 306 insertions(+)
 create mode 100644 atsc/us-ATSC-center-frequencies-8VSB-062009

diff --git a/atsc/us-ATSC-center-frequencies-8VSB-062009 
b/atsc/us-ATSC-center-frequencies-8VSB-062009
new file mode 100644
index 000..3590860
--- /dev/null
+++ b/atsc/us-ATSC-center-frequencies-8VSB-062009
@@ -0,0 +1,306 @@
+# US ATSC center frequencies, ch 52 to 69 removed.
+# Use this if you wish to avoid scanning ch 52 to 69.
+# ch 52 thru 69 are unused for ATSC 
+# in the USA since June 2009
+# in Canada since September 2011
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 57028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 63028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 69028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 79028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 85028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 177028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 183028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 189028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 195028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 201028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 207028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 213028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 473028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 479028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 485028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 491028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 497028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 503028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 509028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 515028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 521028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 527028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 533028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 539028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 545028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 551028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 557028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 563028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 569028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 575028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 581028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 587028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 593028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+   FREQUENCY = 599028615
+   MODULATION = VSB/8
+   INVERSION = AUTO
+
+[CHANNEL]
+   DELIVERY_SYSTEM = ATSC
+ 

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

[Laurent Pinchart]

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

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

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

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

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

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

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Document the interaction with ioctls that can affect formats
  (VIDIOC_S_SELECTION, VIDIOC_S_INPUT, VIDIOC_S_OUTPUT, VIDIOC_S_STD and
  VIDIOC_S_DV_TIMINGS)
- Clarify the format/control change order
---
 Documentation/media/uapi/v4l/buffer.rst | 108 
 1 file changed, 108 insertions(+)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ac58966ccb9b..ce46908bedfb 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -34,6 +34,114 @@ flags are copied from the OUTPUT video buffer to the 
CAPTURE video
 buffer.
 
 
+Interactions between formats, controls and buffers
+==
+
+V4L2 exposes parameters that influence the buffer size, or the way data is
+laid out in the buffer. Those parameters are exposed through both formats and
+controls. One example of such a control is the ``V4L2_CID_ROTATE`` control
+that modifies the direction in which pixels are stored in the buffer, as well
+as the buffer size when the selected format includes padding at the end of
+lines.
+
+The set of information needed to interpret the content of a buffer (e.g. the
+pixel format, the line stride, the tiling orientation or the rotation) is
+collectively referred to in the rest of this section as the buffer layout.
+
+Modifying formats or controls that influence the buffer size or layout require
+the stream to be stopped. Any attempt at such a modification while the stream
+is active shall cause the format or control set ioctl to return the ``EBUSY``
+error code.
+
+Controls that only influence the buffer layout can be modified at any time
+when the stream is stopped. As they don't influence the buffer size, no
+special handling is needed to synchronize those controls with buffer
+allocation.
+
+Formats and controls that influence the buffer size interact with buffer
+allocation. As buffer allocation is an expensive operation, drivers should
+allow format or controls that influence the buffer size to be changed with
+buffers allocated. A typical ioctl sequence to modify format and controls is
+
+ #. VIDIOC_STREAMOFF
+ #. VIDIOC_S_EXT_CTRLS
+ #. VIDIOC_S_FMT
+ #. VIDIOC_QBUF
+ #. VIDIOC_STREAMON
+
+.. note::
+
+   The API doesn't mandate the above order for control (2.) and format (3.)
+   changes. Format and controls can be set in a different order, or even
+   interleaved, depending on the device and use case. For instance some
+   controls might behave differently for different pixel formats, in which
+   case the format might need to be set first.
+
+Queued buffers must be large enough for the new format or controls.
+
+Drivers shall return a ``ENOSPC`` error in response to format change
+(:c:func:`VIDIOC_S_FMT`) or control changes (:c:func:`VIDIOC_S_CTRL` or
+:c:func:`VIDIOC_S_EXT_CTRLS`) if buffers too small for the new format are
+currently queued. As a simplification, 

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

[Laurent Pinchart]

Hi Hans,

On Saturday 04 Mar 2017 11:53:45 Hans Verkuil wrote:
> On 28/02/17 16:03, Laurent Pinchart wrote:
> > V4L2 exposes parameters that influence buffers sizes through the format
> > ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT and VIDIO_S_FMT). Other parameters
> 
> S_SELECTION should be mentioned here as well (more about that later).

I'll update that according to the conversation we had on IRC about this topic.

> > not part of the format structure may also influence buffer sizes or
> > buffer layout in general. One existing such parameter is rotation, which
> > is implemented by the VIDIOC_ROTATE control and thus exposed through the
> > V4L2 control ioctls.
> > 
> > The interaction between those parameters and buffers is currently only
> > partially specified by the V4L2 API. In particular interactions between
> > controls and buffers isn't specified at all. The behaviour of the
> > VIDIOC_S_FMT ioctl when buffers are allocated is also not fully
> > specified.
> > 
> > This commit clearly defines and documents the interactions between
> > formats, controls and buffers.
> > 
> > The preparatory discussions for the documentation change considered
> > completely disallowing controls that change the buffer size or layout,
> > in favour of extending the format API with a new ioctl that would bundle
> > those controls with format information. The idea has been rejected, as
> > this would essentially be a restricted version of the upcoming request
> > API that wouldn't bring any additional value.
> > 
> > Another option we have considered was to mandate the use of the request
> > API to modify controls that influence buffer size or layout. This has
> > also been rejected on the grounds that requiring the request API to
> > change rotation even when streaming is stopped would significantly
> > complicate implementation of drivers and usage of the V4L2 API for
> > applications.
> > 
> > Applications will however be required to use the upcoming request API to
> > change at runtime formats or controls that influence the buffer size or
> > layout, because of the need to synchronize buffers with the formats and
> > controls. Otherwise there would be no way to interpret the content of a
> > buffer correctly.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  Documentation/media/uapi/v4l/buffer.rst | 88 
> >  1 file changed, 88 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/buffer.rst
> > b/Documentation/media/uapi/v4l/buffer.rst index
> > ac58966ccb9b..5c58db98ab7a 100644
> > --- a/Documentation/media/uapi/v4l/buffer.rst
> > +++ b/Documentation/media/uapi/v4l/buffer.rst
> > @@ -34,6 +34,94 @@ flags are copied from the OUTPUT video buffer to the
> > CAPTURE video> 
> >  buffer.
> > 
> > +Interactions between formats, controls and buffers
> > +==
> > +
> > +V4L2 exposes parameters that influence the buffer size, or the way data
> > is
> > +laid out in the buffer. Those parameters are exposed through both formats
> > and +controls. One example of such a control is the ``V4L2_CID_ROTATE``
> > control +that modifies the direction in which pixels are stored in the
> > buffer, as well +as the buffer size when the selected format includes
> > padding at the end of +lines.
> > +
> > +The set of information needed to interpret the content of a buffer (e.g.
> > the +pixel format, the line stride, the tiling orientation or the
> > rotation) is +collectively referred to in the rest of this section as the
> > buffer layout. +
> > +Modifying formats or controls that influence the buffer size or layout
> > require +the stream to be stopped. Any attempt at such a modification
> > while the stream +is active shall cause the format or control set ioctl
> > to return the ``EBUSY`` +error code.
> 
> This is not what happens today: it's not the streaming part that causes
> EBUSY to be returned but whether or not buffers are allocated.

Note that this patch documents the recommended behaviour we want to achieve. 
It can differ from the behaviour implemented today as long as today's 
behaviour (at least the behaviour of the drivers that we don't consider as 
non-compliant, which is the vast majority) is not contradicted by this patch. 
In other words, we can recommend here a more generic versatile and powerful 
behaviour as long as the more restricted behaviour implemented today is also 
allowed.

> Today we do not support changing buffer sizes on the fly, so any attempt to
> call an ioctl that would change the buffer size is blocked and EBUSY is
> returned. To be precise: drivers call vb2_is_busy() to determine this.
> 
> To my knowledge all vb2-using drivers behave like this. There may be old
> drivers that do not do this (and these have a high likelyhood of being
> wrong).

Please also note that the above description doesn't contradict the behaviour 
implemented today. It explains that 

Re: [PATCHv2] omap3isp: add support for CSI1 bus

[Pavel Machek]

Hi!

> > This will probably fail.
> > 
> > rval = omap3isp_csi2_reset(phy->csi2);
> > if (rval < 0)
> > goto done;
> 
> Could you try to two patches I've applied on the ccp2 branch (I'll remove
> them if there are issues).
> 
> That's compile tested for now only.

They help a lot. Now I can use similar code paths...

Not yet a mergeable patch, but already better than it was.

Thanks and best regards,
Pavel


diff --git a/drivers/media/platform/omap3isp/ispccp2.c 
b/drivers/media/platform/omap3isp/ispccp2.c
index 24a9fc5..79838bd 100644
--- a/drivers/media/platform/omap3isp/ispccp2.c
+++ b/drivers/media/platform/omap3isp/ispccp2.c
@@ -21,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "isp.h"
 #include "ispreg.h"
@@ -1149,6 +1170,7 @@ int omap3isp_ccp2_init(struct isp_device *isp)
"Could not get regulator vdds_csib\n");
ccp2->vdds_csib = NULL;
}
+   ccp2->phy = >isp_csiphy2;
} else if (isp->revision == ISP_REVISION_15_0) {
ccp2->phy = >isp_csiphy1;
}
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c 
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 50c0f64..94461df 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -68,8 +68,8 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy *phy,
regmap_write(phy->isp->syscon, phy->isp->syscon_offset, reg);
 }
 
-static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool on,
-   bool ccp2_strobe)
+void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool on,
+bool ccp2_strobe, bool strobe_clk_pol)
 {
u32 csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
| OMAP343X_CONTROL_CSIRXFE_RESET;
@@ -85,6 +85,9 @@ static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, 
u32 iface, bool on,
 
if (ccp2_strobe)
csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
+   
+   if (strobe_clk_pol)
+   csirxfe |= OMAP343X_CONTROL_CSIRXFE_CSIB_INV;
 
regmap_write(phy->isp->syscon, phy->isp->syscon_offset, csirxfe);
 }
@@ -108,7 +111,7 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
if (phy->isp->phy_type == ISP_PHY_TYPE_3630 && on)
return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
if (phy->isp->phy_type == ISP_PHY_TYPE_3430)
-   return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe);
+   return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe, 
false);
 }
 
 /*
@@ -197,27 +200,40 @@ static int omap3isp_csiphy_config(struct isp_csiphy *phy)
}
 
if (buscfg->interface == ISP_INTERFACE_CCP2B_PHY1
-   || buscfg->interface == ISP_INTERFACE_CCP2B_PHY2)
+   || buscfg->interface == ISP_INTERFACE_CCP2B_PHY2) {
lanes = >bus.ccp2.lanecfg;
-   else
+   phy->num_data_lanes = 1;
+   } else
lanes = >bus.csi2.lanecfg;
 
+   printk("lane verification... %d\n", phy->num_data_lanes);
+
/* Clock and data lanes verification */
for (i = 0; i < phy->num_data_lanes; i++) {
-   if (lanes->data[i].pol > 1 || lanes->data[i].pos > 3)
-   return -EINVAL;
+   if (lanes->data[i].pol > 1 || lanes->data[i].pos > 3) {
+   printk("Bad cfg\n");
+   //return -EINVAL;
+   }
 
-   if (used_lanes & (1 << lanes->data[i].pos))
-   return -EINVAL;
+   if (used_lanes & (1 << lanes->data[i].pos)) {
+   printk("Already used\n");
+   //return -EINVAL;
+   }
 
used_lanes |= 1 << lanes->data[i].pos;
}
 
-   if (lanes->clk.pol > 1 || lanes->clk.pos > 3)
-   return -EINVAL;
+   printk("used lanes... %d\n", used_lanes);   
 
-   if (lanes->clk.pos == 0 || used_lanes & (1 << lanes->clk.pos))
-   return -EINVAL;
+   if (lanes->clk.pol > 1 || lanes->clk.pos > 3) {
+   printk("Bad clock\n");
+   //return -EINVAL;
+   }
+
+   if (lanes->clk.pos == 0 || used_lanes & (1 << lanes->clk.pos)) {
+   printk("Reused clock\n");
+   //return -EINVAL;
+   }
 
/*
 * The PHY configuration is lost in off mode, that's not an
@@ -302,13 +318,16 @@ int omap3isp_csiphy_acquire(struct isp_csiphy *phy)
if (rval < 0)
goto done;
 
-   rval = csiphy_set_power(phy, ISPCSI2_PHY_CFG_PWR_CMD_ON);
-   if (rval) {
-   regulator_disable(phy->vdd);
-   goto done;
+   if (phy->isp->revision == ISP_REVISION_15_0) {
+  

[PATCH] [v4l-utils] dvb-sat: add support for North American Standard Ku LNB This is the standard LNB used in North America, it is designed with L.O. Freq of 10750 MHz. Intended for the North American

[Bill Murphy]

Signed-off-by: Bill Murphy 
---
 lib/libdvbv5/dvb-sat.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/lib/libdvbv5/dvb-sat.c b/lib/libdvbv5/dvb-sat.c
index 59cb7a6..22a45b1 100644
--- a/lib/libdvbv5/dvb-sat.c
+++ b/lib/libdvbv5/dvb-sat.c
@@ -126,6 +126,19 @@ static const struct dvb_sat_lnb_priv lnb[] = {
},
}, {
.desc = {
+   .name = N_("L10750"),
+   .alias = "L10750",
+   // Legacy fields - kept just to avoid API/ABI breakages
+   .lowfreq = 10750,
+   .freqrange = {
+   { 11700, 12200 }
+   },
+   },
+   .freqrange = {
+  { 11700, 12200, 10750, 0 }
+   },
+   }, {
+   .desc = {
.name = N_("L11300"),
.alias = "L11300",
// Legacy fields - kept just to avoid API/ABI breakages
-- 
2.7.4

TechnoTrend AG TT-connect CT-3650 CI - itself disconnecting and connecting back (upstream driver)

[Josef Schlehofer]

Hello,

With provided kernel image from Debian I had these two issues:
sysfs: cannot create duplicate filename '/class/dvb/dvb0.ca0
'sysfs group 'power' not found for kobject 'dvb0.ca0'
= It seems that this was fixed by upstream driver.

Now I have this issue:
My tuner itself is disconnecting and connecting back in this case
tvheadend doesn't seen it and I need to restart tvheadend.
I also noticed in dmesg that I have two different bug traces
1)

779.987906] [ cut here ]
[ 2779.987916] WARNING: CPU: 0 PID: 2372 at
/home/zumbi/linux-4.9.2/kernel/module.c:1108 module_put+0x8e/0xa0
[ 2779.987917] Modules linked in: binfmt_misc cpufreq_conservative
cpufreq_powersave cpufreq_userspace cfg80211 bonding mt2063(OE)
drxk(OE) rc_tt_1500(OE) tda10048(OE) tda827x(OE) tda10023(OE)
dvb_usb_az6007(OE) cypress_firmware(OE) dvb_usb_ttusb2(OE)
dvb_usb_v2(OE) dvb_usb(OE) dvb_core(OE) rc_core(OE) media(OE)
snd_hda_codec_hdmi nls_ascii nls_cp437 vfat fat snd_hda_codec_realtek
snd_hda_codec_generic zfs(POE) zunicode(POE) zavl(POE) zcommon(POE)
znvpair(POE) intel_rapl intel_soc_dts_iosf intel_powerclamp spl(OE)
coretemp iTCO_wdt iTCO_vendor_support kvm_intel ppdev kvm irqbypass
crct10dif_pclmul crc32_pclmul i915 efi_pstore ghash_clmulni_intel
cryptd intel_cstate serio_raw snd_intel_sst_acpi pcspkr efivars
snd_soc_rt5645 snd_intel_sst_core snd_hda_intel i2c_i801
drm_kms_helper snd_soc_sst_mfld_platform
[ 2779.987964]  i2c_smbus snd_soc_rt5640 lpc_ich snd_soc_sst_match
snd_soc_rl6231 snd_hda_codec mfd_core drm snd_soc_core evdev
snd_hda_core hci_uart snd_hwdep snd_compress btbcm btqca i2c_algo_bit
parport_pc snd_pcm shpchp battery parport btintel snd_timer bluetooth
snd video soundcore dw_dmac dw_dmac_core rfkill
i2c_designware_platform tpm_tis i2c_designware_core tpm_tis_core tpm
button fuse autofs4 ext4 crc16 jbd2 fscrypto mbcache btrfs xor
raid6_pq dm_mod md_mod sg uas usb_storage hid_generic usbhid sd_mod
xhci_pci xhci_hcd ahci libahci e1000e usbcore libata ptp crc32c_intel
pps_core usb_common scsi_mod psmouse thermal r8169 mii fan fjes
sdhci_acpi i2c_hid sdhci hid mmc_core
[ 2779.988022] CPU: 0 PID: 2372 Comm: tvheadend Tainted: P
OE   4.9.0-0.bpo.1-amd64 #1 Debian 4.9.2-2~bpo8+1
[ 2779.988023] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./Q1900-ITX, BIOS P1.80 11/08/2016
[ 2779.988027]   8972a1f5 

[ 2779.988031]  89477884 9f12b2dbaf00 9f126a17c100
9f12b535e648
[ 2779.988034]  9f12b656d960 9f12b48fee40 9f12b535e648
894fe3be
[ 2779.988038] Call Trace:
[ 2779.988044]  [] ? dump_stack+0x5c/0x77
[ 2779.988048]  [] ? __warn+0xc4/0xe0
[ 2779.988051]  [] ? module_put+0x8e/0xa0
[ 2779.988060]  [] ?
dvb_ca_en50221_io_release+0x4c/0x90 [dvb_core]
[ 2779.988064]  [] ? __fput+0xcd/0x1e0
[ 2779.988067]  [] ? task_work_run+0x72/0x90
[ 2779.988070]  [] ? do_exit+0x395/0xb50
[ 2779.988072]  [] ? do_group_exit+0x39/0xb0
[ 2779.988075]  [] ? SyS_exit_group+0x10/0x10
[ 2779.988079]  [] ? system_call_fast_compare_end+0xc/0x9b
[ 2779.988081] ---[ end trace c675cdf08c26442d ]---


2)

[ 1209.584994] INFO: task kworker/0:0:4 blocked for more than 120 seconds.
[ 1209.585005]   Tainted: P   OE   4.9.0-0.bpo.1-amd64 #1
[ 1209.585009] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 1209.585013] kworker/0:0 D0 4  2 0x
[ 1209.585047] Workqueue: usb_hub_wq hub_event [usbcore]
[ 1209.585052]  9f12a5070800 9f12b1c19800 9f12b1f88f40
9f12b6628080
[ 1209.585059]  9f12bfc187c0 b7e840c7bb58 899f536d
0286
[ 1209.585065]  7977594d b1e76938 b7e840c7bb78
9f12b6628080
[ 1209.585072] Call Trace:
[ 1209.585082]  [] ? __schedule+0x23d/0x6d0
[ 1209.585087]  [] ? schedule+0x32/0x80
[ 1209.585102]  [] ? dvb_dmxdev_release+0x4d/0x120 [dvb_core]
[ 1209.585108]  [] ? wake_up_atomic_t+0x30/0x30
[ 1209.585116]  [] ?
dvb_usb_adapter_dvb_exit+0x44/0x90 [dvb_usb]
[ 1209.585121]  [] ? dvb_usb_exit+0x49/0xe0 [dvb_usb]
[ 1209.585127]  [] ? dvb_usb_device_exit+0x3b/0x50 [dvb_usb]
[ 1209.585150]  [] ? usb_unbind_interface+0x71/0x270 [usbcore]
[ 1209.585156]  [] ? __device_release_driver+0x95/0x140
[ 1209.585160]  [] ? device_release_driver+0x1e/0x30
[ 1209.585165]  [] ? bus_remove_device+0xf5/0x170
[ 1209.585169]  [] ? device_del+0x127/0x260
[ 1209.585192]  [] ? usb_remove_ep_devs+0x1b/0x30 [usbcore]
[ 1209.585215]  [] ? usb_disable_device+0x93/0x260 [usbcore]
[ 1209.585237]  [] ? usb_disconnect+0x8a/0x260 [usbcore]
[ 1209.585259]  [] ? hub_event+0x7d0/0x1530 [usbcore]
[ 1209.585264]  [] ? process_one_work+0x14b/0x410
[ 1209.585269]  [] ? worker_thread+0x65/0x4a0
[ 1209.585273]  [] ? rescuer_thread+0x340/0x340
[ 1209.585277]  [] ? kthread+0xe0/0x100
[ 1209.585282]  [] ? __switch_to+0x2bb/0x700
[ 1209.585286]  [] ? kthread_park+0x60/0x60
[ 1209.585291]  [] ? ret_from_fork+0x25/0x30


Full log: pastebin.com/VWDQE8DC

I also 

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

[Laurent Pinchart]

Hi Sakari,

On Saturday 04 Mar 2017 15:48:54 Sakari Ailus wrote:
> On Sat, Mar 04, 2017 at 11:57:32AM +0100, Hans Verkuil wrote:
> ...
> 
> >>> +To simplify their implementation, drivers may also require buffers to
> >>> be +reallocated in order to change formats or controls that influence
> >>> the buffer +size. In that case, to perform such changes, userspace
> >>> applications shall +first stop the video stream with the
> >>> :c:func:`VIDIOC_STREAMOFF` ioctl if it +is running and free all buffers
> >>> with the :c:func:`VIDIOC_REQBUFS` ioctl if +they are allocated. The
> >>> format or controls can then be modified, and buffers +shall then be
> >>> reallocated and the stream restarted. A typical ioctl sequence +is
> >>> +
> >>> + #. VIDIOC_STREAMOFF
> >>> + #. VIDIOC_REQBUFS(0)
> >>> + #. VIDIOC_S_FMT
> >>> + #. VIDIOC_S_EXT_CTRLS
> >>
> >> Same here.
> >>
> >> Would it be safe to say that controls are changed first? I wonder if
> >> there could be special cases where this wouldn't apply though. It could
> >> ultimately come down to hardware features: rotation might be only
> >> available for certain formats so you'd need to change the format first
> >> to enable rotation.
> >>
> >> What you're documenting above is a typical sequence so it doesn't have to
> >> be applicable to all potential hardware. I might mention there could be
> >> such dependencies. I wonder if one exists at the moment. No?
> > 
> > The way V4L2 works is that the last ioctl called gets 'preference'. So the
> > driver should attempt to satisfy the ioctl, even if that means undoing
> > previous ioctls. In other words, V4L2 allows any order, but the
> > end-result might be different depending on the hardware capabilities.
> 
> Indeed. But the above sequence suggests that formats are set before
> controls. I suggested to clarify that part.

I agree with both of you. I'll clarify that this is just an example and that 
formats and controls can be set in a different order (or even interleaved).

-- 
Regards,

Laurent Pinchart

Re: [PATCH] media: platform: Renesas IMR driver

[Magnus Damm]

Hi Sergei,

Thanks for your efforts with this driver. Nice to see that V2 is
getting in better shape.

In the future, would it be possible for you to include the patch
version number in the [PATCH] tag somehow?

On Fri, Mar 3, 2017 at 9:03 PM, Sergei Shtylyov
 wrote:
> On 03/03/2017 02:58 PM, Geert Uytterhoeven wrote:
>
> +  - "renesas,imr-lx4-v3m" for R-Car V3M.



 "renesas,-EPROBE_DEFER-imr-lx4"
>>>
>>>
>>>
>>>Huh? :-)
>>
>>
>> Do you know the part number of V3M?
>
>
>No, but using the names from the manual I don't need it.

NAK, like Geert says, please follow the same style as other upstream
drivers. DT compat strings is not a place for random polices.

Thanks,

/ magnus

[PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats

[Randy Li]

The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format.

Also a variant of V4L2_PIX_FMT_P010M pixel format is added.
The V4L2_PIX_FMT_P010CM is a compat variant of the V4L2_PIX_FMT_P010,
which uses the unused 6 bits to store the next pixel. And with
the alignment requirement of the hardware, it usually would be
some extra space left at the end of a stride.

Signed-off-by: Randy Li 
---
 Documentation/media/uapi/v4l/pixfmt-p010.rst  | 126 
 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++
 Documentation/media/uapi/v4l/pixfmt-p016.rst  | 125 
 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
 Documentation/media/uapi/v4l/yuv-formats.rst  |   4 +
 include/uapi/linux/videodev2.h|   5 +
 6 files changed, 529 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst 
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..59ed118
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,126 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 16 bits per pixel, but only 10 bits are used with the
+rest 6 bits set to zero. For ``V4L2_PIX_FMT_P010``, a combined CbCr plane
+immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Byte Order.**
+Each cell is two bytes.
+
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - start + 0:
+  - Y'\ :sub:`00`
+  - Y'\ :sub:`01`
+  - Y'\ :sub:`02`
+  - Y'\ :sub:`03`
+* - start + 4:
+  - Y'\ :sub:`10`
+  - Y'\ :sub:`11`
+  - Y'\ :sub:`12`
+  - Y'\ :sub:`13`
+* - start + 8:
+  - Y'\ :sub:`20`
+  - Y'\ :sub:`21`
+  - Y'\ :sub:`22`
+  - Y'\ :sub:`23`
+* - start + 12:
+  - Y'\ :sub:`30`
+  - Y'\ :sub:`31`
+  - Y'\ :sub:`32`
+  - Y'\ :sub:`33`
+* - start + 16:
+  - Cb\ :sub:`00`
+  - Cr\ :sub:`00`
+  - Cb\ :sub:`01`
+  - Cr\ :sub:`01`
+* - start + 20:
+  - Cb\ :sub:`10`
+  - Cr\ :sub:`10`
+  - Cb\ :sub:`11`
+  - Cr\ :sub:`11`
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* -
+  - 0
+  -
+  - 1
+  - 2
+  -
+  - 3
+* - 0
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+  -
+  - C
+  -
+  -
+  - C
+  -
+* - 1
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+* - 2
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+  -
+  - C
+  -
+  -
+  - C
+  -
+* - 3
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst 
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 000..6697d15
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,135 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***
+V4L2_PIX_FMT_P010M ('PM10')
+***
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminance data

[PATCH v6 3/3] drm/rockchip: Support 10 bits yuv format in vop

[Randy Li]

The rockchip use a special pixel format for those yuv pixel
format with 10 bits color depth.

Signed-off-by: Randy Li 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  2 ++
 include/uapi/drm/drm_fourcc.h   | 11 ++
 5 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index c9ccdf8..250fd29 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -230,6 +230,7 @@ void rockchip_drm_mode_config_init(struct drm_device *dev)
 */
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
+   dev->mode_config.allow_fb_modifiers = true;
 
dev->mode_config.funcs = _drm_mode_config_funcs;
dev->mode_config.helper_private = _mode_config_helpers;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..45da270 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t 
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+   case DRM_FORMAT_P010:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,12 +250,28 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+   case DRM_FORMAT_P010:
return true;
default:
return false;
}
 }
 
+static bool is_support_fb(struct drm_framebuffer *fb)
+{
+   switch (fb->format->format) {
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV24:
+   return true;
+   case DRM_FORMAT_P010:
+   if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+   return true;
+   default:
+   return false;
+   }
+
+}
 static bool is_alpha_support(uint32_t format)
 {
switch (format) {
@@ -680,7 +697,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
 * Src.x1 can be odd when do clip, but yuv plane start point
 * need align with 2 pixel.
 */
-   if (is_yuv_support(fb->format->format) && ((state->src.x1 >> 16) % 2))
+   if (is_support_fb(fb) && ((state->src.x1 >> 16) % 2))
return -EINVAL;
 
return 0;
@@ -723,6 +740,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+   bool is_10_bits = false;
int format;
 
/*
@@ -739,6 +757,9 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
 
+   if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+   is_10_bits = true;
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
 
@@ -753,7 +774,10 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
 
-   offset = (src->x1 >> 16) * fb->format->cpp[0];
+   if (is_10_bits)
+   offset = (src->x1 >> 16) * 10 / 8;
+   else
+   offset = (src->x1 >> 16) * fb->format->cpp[0];
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
 
@@ -764,6 +788,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, fb->pitches[0] >> 2);
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+   VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub = 
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub = 
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -772,7 +797,10 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
 
-   offset = (src->x1 >> 16) * bpp / hsub;
+   if (is_10_bits)
+   offset = (src->x1 >> 16) * 10 / 8 / hsub;
+   else
+   offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
 
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 

[PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Randy Li]

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format.

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.

Cc: Daniel Stone 
Cc: Ville Syrjälä 

Signed-off-by: Randy Li 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_fourcc.c  |  3 +++
 include/uapi/drm/drm_fourcc.h | 21 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P012,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
 
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@ extern "C" {
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */
 
 /*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
  * index 1: Cb plane, [7:0] Cb
-- 
2.7.4

[PATCH v6 0/3] Add pixel format for 10 bits YUV video

[Randy Li]

Thanks to Clint's work, this version just correct some wrong info
in the comment.

I also offer a driver sample here, but it have been verified with
the 10 bits properly. I lacks of the userspace tool. And I am
not sure whether it is a properly way to support the pixel format
used in rockchip, although it is not common used pixel format,
but it could save lots of memory, it may be welcome by the
other vendor, also I think the 3GR serial from Intel would
use the same pixel format as the video IP comes from rockchip.

Randy Li (3):
  drm_fourcc: Add new P010, P016 video format
  v4l: Add 10/16-bits per channel YUV pixel formats
  drm/rockchip: Support 10 bits yuv format in vop

 Documentation/media/uapi/v4l/pixfmt-p010.rst  | 126 
 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++
 Documentation/media/uapi/v4l/pixfmt-p016.rst  | 125 
 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
 Documentation/media/uapi/v4l/yuv-formats.rst  |   4 +
 drivers/gpu/drm/drm_fourcc.c  |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  34 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |   1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c   |   2 +
 include/uapi/drm/drm_fourcc.h |  32 ++
 include/uapi/linux/videodev2.h|   5 +
 12 files changed, 599 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst

-- 
2.7.4