cron job: media_tree daily build: ERRORS

2016-10-20 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Fri Oct 21 05:00:14 CEST 2016
media-tree git hash:43ea43b9d8b27b7acd443ec59319faa3cdb8a616
media_build git hash:   dac8db4dd7fa3cc87715cb19ace554e080690b39
v4l-utils git hash: 79186f9d3d9d3b6bee4a611bd92435d11807
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.7.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: WARNINGS
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: ERRORS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
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: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-rc1-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: ERRORS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: 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: OK
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-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
smatch: ERRORS
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


China Large Aluminum castings supplier.

2016-10-20 Thread Bob
Hello, 

Here is the experienced manufactuer of aluminum castings with advanced 
machining equipments.

To reduce cost, manufacturers in your market are buying casting parts and 
component from us. We can supply aluminum die alloy, gravity casting and sand 
casting to meet your different demand. All molds made by ourself to reduce your 
cost. 40% of our shipment are for your market, which are proving our 
competitive in pricing and quality. 

Shall you have any interest, pls contact for possible deal. 

b.rgds 
Bob Hu 
Ningbo Yinzhou Xusheng Machinery Factory 
Skype: bobhu1
Cell: 0086-1395832 7774 
Tel: 0086-574-88128603 
b...@xs-aluminumcasting.com 
www.xs-aluminumcasting.com

Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-20 Thread Michal Hocko
On Wed 19-10-16 10:23:55, Dave Hansen wrote:
> On 10/19/2016 10:01 AM, Michal Hocko wrote:
> > The question I had earlier was whether this has to be an explicit FOLL
> > flag used by g-u-p users or we can just use it internally when mm !=
> > current->mm
> 
> The reason I chose not to do that was that deferred work gets run under
> a basically random 'current'.  If we just use 'mm != current->mm', then
> the deferred work will sometimes have pkeys enforced and sometimes not,
> basically randomly.

OK, I see (async_pf_execute and ksm ). It makes more sense to me. Thanks
for the clarification.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 48/58] uvc: don't break long lines

2016-10-20 Thread Laurent Pinchart
Hi Mauro,

Thank you for the patch.

On Tuesday 18 Oct 2016 18:46:00 Mauro Carvalho Chehab wrote:
> Due to the 80-cols restrictions, and latter due to checkpatch
> warnings, several strings were broken into multiple lines. This
> is not considered a good practice anymore, as it makes harder
> to grep for strings at the source code.
> 
> As we're right now fixing other drivers due to KERN_CONT, we need
> to be able to identify what printk strings don't end with a "\n".
> It is a way easier to detect those if we don't break long lines.
> 
> So, join those continuation lines.
> 
> The patch was generated via the script below, and manually
> adjusted if needed.
> 
> 
> use Text::Tabs;
> while (<>) {
>   if ($next ne "") {
>   $c=$_;
>   if ($c =~ /^\s+\"(.*)/) {
>   $c2=$1;
>   $next =~ s/\"\n$//;
>   $n = expand($next);
>   $funpos = index($n, '(');
>   $pos = index($c2, '",');
>   if ($funpos && $pos > 0) {
>   $s1 = substr $c2, 0, $pos + 2;
>   $s2 = ' ' x ($funpos + 1) . substr $c2, 
$pos + 2;
>   $s2 =~ s/^\s+//;
> 
>   $s2 = ' ' x ($funpos + 1) . $s2 if ($s2 ne 
"");
> 
>   print unexpand("$next$s1\n");
>   print unexpand("$s2\n") if ($s2 ne "");
>   } else {
>   print "$next$c2\n";
>   }
>   $next="";
>   next;
>   } else {
>   print $next;
>   }
>   $next="";
>   } else {
>   if (m/\"$/) {
>   if (!m/\\n\"$/) {
>   $next=$_;
>   next;
>   }
>   }
>   }
>   print $_;
> }
> 
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c|  36 ++---
>  drivers/media/usb/uvc/uvc_debugfs.c |   5 +-
>  drivers/media/usb/uvc/uvc_driver.c  | 278 -
>  drivers/media/usb/uvc/uvc_entity.c  |  10 +-
>  drivers/media/usb/uvc/uvc_isight.c  |  12 +-
>  drivers/media/usb/uvc/uvc_status.c  |  23 +--
>  drivers/media/usb/uvc/uvc_v4l2.c|  11 +-
>  drivers/media/usb/uvc/uvc_video.c   | 103 ++---
>  8 files changed, 256 insertions(+), 222 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c index c2ee6e39fd0c..747415d4fa60 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c

[snip]

> @@ -1710,8 +1709,9 @@ static int uvc_ctrl_init_xu_ctrl(struct uvc_device
> *dev,
> 
>   ret = uvc_ctrl_add_info(dev, ctrl, );
>   if (ret < 0)
> - uvc_trace(UVC_TRACE_CONTROL, "Failed to initialize control "
> -   "%pUl/%u on device %s entity %u\n", info.entity,
> + uvc_trace(UVC_TRACE_CONTROL,
> +   "Failed to initialize control %pUl/%u on device 
%s entity %u\n",
> +   info.entity,
> info.selector, dev->udev->devpath, ctrl->entity-
>id);

The split looks weird, the following would be better.

  info.entity, info.selector, dev->udev->devpath,
  ctrl->entity->id);

> 
>   return ret;
> @@ -1904,8 +1904,9 @@ static int uvc_ctrl_add_info(struct uvc_device *dev,
> struct uvc_control *ctrl,
> 
>   ctrl->initialized = 1;
> 
> - uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s "
> - "entity %u\n", ctrl->info.entity, ctrl->info.selector,
> + uvc_trace(UVC_TRACE_CONTROL,
> +   "Added control %pUl/%u to device %s entity %u\n",
> +   ctrl->info.entity, ctrl->info.selector,
>   dev->udev->devpath, ctrl->entity->id);

The last line isn't indented correctly.

> 
>  done:
> @@ -1964,8 +1965,9 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
> *chain, int ret;
> 
>   if (mapping->id & ~V4L2_CTRL_ID_MASK) {
> - uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', 
control "
> - "id 0x%08x is invalid.\n", mapping->name,
> + uvc_trace(UVC_TRACE_CONTROL,
> +   "Can't add mapping '%s', control id 0x%08x is 
invalid.\n",
> +   mapping->name,
>   mapping->id);

The last two arguments can fit on a single line.

>   return -EINVAL;
>   }
> @@ -2004,8 +2006,8 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
> *chain,
> 
>   list_for_each_entry(map, >info.mappings, list) {
>   if (mapping->id == map->id) {
> - uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping 
'%s', "
> -  

Re: [PATCH v2 54/58] i2c: don't break long lines

2016-10-20 Thread Laurent Pinchart
Hi Mauro,

Thank you for the patch.

On Tuesday 18 Oct 2016 18:46:06 Mauro Carvalho Chehab wrote:
> Due to the 80-cols restrictions, and latter due to checkpatch
> warnings, several strings were broken into multiple lines. This
> is not considered a good practice anymore, as it makes harder
> to grep for strings at the source code.
> 
> As we're right now fixing other drivers due to KERN_CONT, we need
> to be able to identify what printk strings don't end with a "\n".
> It is a way easier to detect those if we don't break long lines.
> 
> So, join those continuation lines.
> 
> The patch was generated via the script below, and manually
> adjusted if needed.
> 
> 
> use Text::Tabs;
> while (<>) {
>   if ($next ne "") {
>   $c=$_;
>   if ($c =~ /^\s+\"(.*)/) {
>   $c2=$1;
>   $next =~ s/\"\n$//;
>   $n = expand($next);
>   $funpos = index($n, '(');
>   $pos = index($c2, '",');
>   if ($funpos && $pos > 0) {
>   $s1 = substr $c2, 0, $pos + 2;
>   $s2 = ' ' x ($funpos + 1) . substr $c2, 
$pos + 2;
>   $s2 =~ s/^\s+//;
> 
>   $s2 = ' ' x ($funpos + 1) . $s2 if ($s2 ne 
"");
> 
>   print unexpand("$next$s1\n");
>   print unexpand("$s2\n") if ($s2 ne "");
>   } else {
>   print "$next$c2\n";
>   }
>   $next="";
>   next;
>   } else {
>   print $next;
>   }
>   $next="";
>   } else {
>   if (m/\"$/) {
>   if (!m/\\n\"$/) {
>   $next=$_;
>   next;
>   }
>   }
>   }
>   print $_;
> }
> 
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/i2c/as3645a.c  | 13 +++--
>  drivers/media/i2c/msp3400-kthreads.c |  4 ++--
>  drivers/media/i2c/mt9m032.c  |  5 +++--
>  drivers/media/i2c/mt9p031.c  |  5 +++--
>  drivers/media/i2c/saa7115.c  | 18 +++---
>  drivers/media/i2c/saa717x.c  |  4 ++--
>  drivers/media/i2c/tvp5150.c  | 14 --
>  drivers/media/i2c/tvp7002.c  |  6 +++---
>  drivers/media/i2c/upd64083.c |  4 +---
>  9 files changed, 40 insertions(+), 33 deletions(-)

[snip]

> diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
> index 58062b41c923..3b341a9da004 100644
> --- a/drivers/media/i2c/saa7115.c
> +++ b/drivers/media/i2c/saa7115.c

[snip]


> @@ -1538,8 +1537,10 @@ static int saa711x_log_status(struct v4l2_subdev *sd)
> /* status for the saa7114 */
>   reg1f = saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC);
>   signalOk = (reg1f & 0xc1) == 0x81;
> - v4l2_info(sd, "Video signal:%s\n", signalOk ? "ok" : 
"bad");

No need to change this one, if fits on a single line.

> - v4l2_info(sd, "Frequency:   %s\n", (reg1f & 0x20) ? "60 
Hz" : "50
> Hz"); +   v4l2_info(sd, "Video signal:%s\n",
> +   signalOk ? "ok" : "bad");
> + v4l2_info(sd, "Frequency:   %s\n",
> +   (reg1f & 0x20) ? "60 Hz" : "50 Hz");
>   return 0;
>   }
> 

[snip]

> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 4740da39d698..b3a9580ef1e4 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -280,10 +280,10 @@ static inline void tvp5150_selmux(struct v4l2_subdev
> *sd) break;
>   }
> 
> - v4l2_dbg(1, debug, sd, "Selecting video route: route input=%i, 
output=%i "
> - "=> tvp5150 input=%i, opmode=%i\n",
> - decoder->input, decoder->output,
> - input, opmode);
> + v4l2_dbg(1, debug, sd,
> +  "Selecting video route: route input=%i, output=%i => 
tvp5150 input=%i, opmode=%i\n",
> +  decoder->input, decoder->output,
> +  input, opmode);

The three arguments can fit on a single line.

> 
>   tvp5150_write(sd, TVP5150_OP_MODE_CTL, opmode);
>   tvp5150_write(sd, TVP5150_VD_IN_SRC_SEL_1, input);
> @@ -649,7 +649,8 @@ static int tvp5150_set_vbi(struct v4l2_subdev *sd,
>   int pos=0;
> 
>   if (std == V4L2_STD_ALL) {
> - v4l2_err(sd, "VBI can't be configured without knowing number 
of
> lines\n");
> + v4l2_err(sd,
> +  "VBI can't be configured without knowing number of 
lines\n");

I'm quite doubtful that this particular change improves readability :-)

>   return 0;
>   } else if (std & V4L2_STD_625_50) {
>   /* Don't 

Re: [PATCH v2 0/3] r8a7793 Gose video input support

2016-10-20 Thread Simon Horman
Hi Ulrich,

On Tue, Oct 18, 2016 at 05:02:20PM +0200, Ulrich Hecht wrote:
> Hi!
> 
> This is a by-the-datasheet implementation of analog and digital video input
> on the Gose board.
> 
> I have tried to address all concerns raised by reviewers, with the exception
> of the composite input patch, which has been left as is for now.
> 
> CU
> Uli
> 
> 
> Changes since v1:
> - r8a7793.dtsi: added VIN2
> - modeled HDMI decoder input/output and connector
> - added "renesas,rcar-gen2-vin" compat strings
> - removed unnecessary "remote" node and aliases
> - set ADV7612 interrupt to GP4_2
> 
> 
> Ulrich Hecht (3):
>   ARM: dts: r8a7793: Enable VIN0-VIN2

I have queued up the above patch with Laurent and Geert's tags.

>   ARM: dts: gose: add HDMI input
>   ARM: dts: gose: add composite video input

Please address the review of the above two patches and repost.

Thanks!

> 
>  arch/arm/boot/dts/r8a7793-gose.dts | 100 
> +
>  arch/arm/boot/dts/r8a7793.dtsi |  27 ++
>  2 files changed, 127 insertions(+)
> 
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/2] ARM: dts: koelsch: add HDMI input

2016-10-20 Thread Simon Horman
On Wed, Oct 19, 2016 at 09:33:11AM +0200, Geert Uytterhoeven wrote:
> On Tue, Oct 18, 2016 at 5:01 PM, Ulrich Hecht
>  wrote:
> > From: Hans Verkuil 
> >
> > Add support in the dts for the HDMI input. Based on the Lager dts
> > patch from Ultich Hecht.
> 
> Ulrich ;-)

I have queued up this patch with Ulrich's name corrected.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/2] Renesas Lager/Koelsch HDMI input

2016-10-20 Thread Simon Horman
On Tue, Oct 18, 2016 at 06:17:25PM +0300, Laurent Pinchart wrote:
> Hi Ulrich,
> 
> Thank you for the patches.
> 
> For the whole series,
> 
> Reviewed-by: Laurent Pinchart 

Thanks, series applied with Laurent's tag.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] [media] vb2: Add support for capture_dma_bidirectional queue flag

2016-10-20 Thread Thierry Escande
From: Pawel Osciak 

When this flag is set for CAPTURE queues by the driver on calling
vb2_queue_init(), it forces the buffers on the queue to be
allocated/mapped with DMA_BIDIRECTIONAL direction flag instead of
DMA_FROM_DEVICE. This allows the device not only to write to the
buffers, but also read out from them. This may be useful e.g. for codec
hardware which may be using CAPTURE buffers as reference to decode
other buffers.

This flag is ignored for OUTPUT queues as we don't want to allow HW to
be able to write to OUTPUT buffers.

Signed-off-by: Pawel Osciak 
Tested-by: Pawel Osciak 
Signed-off-by: Thierry Escande 
---

Changes since v1:
- Renamed use_dma_bidirectional field as capture_dma_bidirectional
- Added a VB2_DMA_DIR() macro

Changes since v2:
- Get rid of dma_dir field and therefore squashed the previous patch

 drivers/media/v4l2-core/videobuf2-core.c |  9 +++--
 include/media/videobuf2-core.h   | 15 +++
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 21900202..22d6105 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -194,8 +194,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb);
 static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
-   enum dma_data_direction dma_dir =
-   q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+   enum dma_data_direction dma_dir = VB2_DMA_DIR(q);
void *mem_priv;
int plane;
int ret = -ENOMEM;
@@ -978,8 +977,7 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const void 
*pb)
void *mem_priv;
unsigned int plane;
int ret = 0;
-   enum dma_data_direction dma_dir =
-   q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+   enum dma_data_direction dma_dir = VB2_DMA_DIR(q);
bool reacquired = vb->planes[0].mem_priv == NULL;
 
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
@@ -1096,8 +1094,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
void *mem_priv;
unsigned int plane;
int ret = 0;
-   enum dma_data_direction dma_dir =
-   q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+   enum dma_data_direction dma_dir = VB2_DMA_DIR(q);
bool reacquired = vb->planes[0].mem_priv == NULL;
 
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index ac5898a..631f08b 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -433,6 +433,9 @@ struct vb2_buf_ops {
  * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when QBUF
  *  has not been called. This is a vb1 idiom that has been adopted
  *  also by vb2.
+ * @capture_dma_bidirectional: use DMA_BIDIRECTIONAL for CAPTURE buffers; this
+ * allows HW to read from the CAPTURE buffers in
+ * addition to writing; ignored for OUTPUT queues.
  * @lock:  pointer to a mutex that protects the vb2_queue struct. The
  * driver can set this to a mutex to let the v4l2 core serialize
  * the queuing ioctls. If the driver wants to handle locking
@@ -499,6 +502,7 @@ struct vb2_queue {
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;
unsigned   quirk_poll_must_check_waiting_for_buffers:1;
+   unsignedcapture_dma_bidirectional:1;
 
struct mutex*lock;
void*owner;
@@ -554,6 +558,17 @@ struct vb2_queue {
 #endif
 };
 
+/*
+ * Return the corresponding DMA direction given the vb2_queue type (capture or
+ * output). returns DMA_BIRECTIONAL for capture buffers if the vb2_queue field
+ * capture_dma_bidirectional is set by the driver.
+ */
+#define VB2_DMA_DIR(q) (V4L2_TYPE_IS_OUTPUT((q)->type)   \
+   ? DMA_TO_DEVICE  \
+   : (q)->capture_dma_bidirectional \
+ ? DMA_BIDIRECTIONAL\
+ : DMA_FROM_DEVICE)
+
 /**
  * vb2_plane_vaddr() - Return a kernel virtual address of a given plane
  * @vb:vb2_buffer to which the plane in question belongs to
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] [media] vb2: Store dma_dir in vb2_queue

2016-10-20 Thread Thierry Escande

Hi Sakari,

On 19/10/2016 23:29, Sakari Ailus wrote:

Hi Thierry,

On Wed, Oct 19, 2016 at 10:24:16AM +0200, Thierry Escande wrote:

From: Pawel Osciak 

Store dma_dir in struct vb2_queue and reuse it, instead of recalculating
it each time.

Signed-off-by: Pawel Osciak 
Tested-by: Pawel Osciak 
Reviewed-by: Tomasz Figa 
Reviewed-by: Owen Lin 
Signed-off-by: Thierry Escande 
---
 drivers/media/v4l2-core/videobuf2-core.c | 12 +++-
 drivers/media/v4l2-core/videobuf2-v4l2.c |  2 ++
 include/media/videobuf2-core.h   |  2 ++
 3 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 21900202..f12103c 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -194,8 +194,6 @@ static void __enqueue_in_driver(struct vb2_buffer *vb);
 static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
-   enum dma_data_direction dma_dir =
-   q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
void *mem_priv;
int plane;
int ret = -ENOMEM;
@@ -209,7 +207,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)

mem_priv = call_ptr_memop(vb, alloc,
q->alloc_devs[plane] ? : q->dev,
-   q->dma_attrs, size, dma_dir, q->gfp_flags);
+   q->dma_attrs, size, q->dma_dir, q->gfp_flags);


My bad, I guess I expressed myself unclearly.

Could you introduce the macro in this patch? You can then remove q->dma_dir
altogether.

My bad. Sorry for the confusion...

The v3 is on its way.

Regards,
 Thierry

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html