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:   Sat Oct 22 05:00:19 CEST 2016
media-tree git hash:bc9b91e6be38b54a7b245969d0a9247791705e6a
media_build git hash:   dac8db4dd7fa3cc87715cb19ace554e080690b39
v4l-utils git hash: 0bd4b277c452aa7cfd537799538b8e9b951c0d47
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: ERRORS
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: WARNINGS
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9-rc1-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
smatch: ERRORS
ABI WARNING: change for arm-at91
ABI WARNING: change for arm-pxa
ABI WARNING: change for i686
ABI WARNING: change for m32r
ABI WARNING: change for powerpc64
ABI WARNING: change for sh
ABI WARNING: change for x86_64
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Jonathan Corbet]

On Tue, 11 Oct 2016 09:26:48 +0200
Markus Heiser  wrote:

> If the kernel-cmd directive gets acked, I will add a description to
> kernel-documentation.rst and I request Mauro to document the parse-headers.pl
> also.
> 
> But, let's hear what Jon says.

Sigh.

I've been shunting this discussion aside while I dug out from other
things.  Now I've pushed through the whole thing; I'm still not sure what
I think is the best thing to do.

kernel-cmd scares me.  It looks like the ioctl() of documentation
building; people will be able to add all kinds of wild things and it will
take a lot of attention to catch them.  I think we could make things
pretty messy in a real hurry.  And yes, I do think we should consider the
security aspects of it; we're talking about adding another shell
code-execution context in the kernel build, and that can only make things
harder to audit.

OTOH, forcing things into dedicated Sphinx extensions doesn't necessarily
fix the problem.  We're adding system calls rather than ioctl() commands,
let's say, but we're still adding long-term maintenance complications.

How many special-case commands are we going to need to run?  Does it
really need to go beyond what parse-headers is doing now?  Let's really
think about what the other use cases might be and whether we can do
without them. I'm still thoroughly unconvinced about the utility of
incorporating, say, the MAINTAINERS file into the formatted docs, for
example, so I'm not yet convinced that making that easier to do is
something we need.

Not much clarity here, sorry.

jon
--
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] dvb-usb-cxusb: Geniatech T230 - resync TS FIFO after lock

[CrazyCat]

This patch fix streaming issue for Geniatech T230/PT360.

Signed-off-by: CrazyCat 
---
 drivers/media/usb/dvb-usb/cxusb.c | 26 ++
 drivers/media/usb/dvb-usb/cxusb.h |  5 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 3701f59..46b59c3 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -368,6 +368,26 @@ static int cxusb_aver_streaming_ctrl(struct 
dvb_usb_adapter *adap, int onoff)
return 0;
 }
 
+static int cxusb_read_status(struct dvb_frontend *fe,
+ enum fe_status *status)
+{
+   struct dvb_usb_adapter *adap = (struct dvb_usb_adapter *)fe->dvb->priv;
+   struct cxusb_state *state = (struct cxusb_state *)adap->dev->priv;
+   int ret;
+
+   ret = state->fe_read_status(fe, status);
+
+   /* it need resync slave fifo when signal change from unlock to lock.*/
+   if ((*status & FE_HAS_LOCK) && (!state->last_lock)) {
+   mutex_lock(>stream_mutex);
+   cxusb_streaming_ctrl(adap, 1);
+   mutex_unlock(>stream_mutex);
+   }
+
+   state->last_lock = (*status & FE_HAS_LOCK) ? 1 : 0;
+   return ret;
+}
+
 static void cxusb_d680_dmb_drain_message(struct dvb_usb_device *d)
 {
int   ep = d->props.generic_bulk_ctrl_endpoint;
@@ -1370,6 +1390,12 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
st->i2c_client_demod = client_demod;
st->i2c_client_tuner = client_tuner;
 
+   /* hook fe: need to resync the slave fifo when signal locks. */
+   mutex_init(>stream_mutex);
+   st->last_lock = 0;
+   st->fe_read_status = adap->fe_adap[0].fe->ops.read_status;
+   adap->fe_adap[0].fe->ops.read_status = cxusb_read_status;
+
return 0;
 }
 
diff --git a/drivers/media/usb/dvb-usb/cxusb.h 
b/drivers/media/usb/dvb-usb/cxusb.h
index 527ff79..22b3253 100644
--- a/drivers/media/usb/dvb-usb/cxusb.h
+++ b/drivers/media/usb/dvb-usb/cxusb.h
@@ -32,6 +32,11 @@ struct cxusb_state {
u8 gpio_write_state[3];
struct i2c_client *i2c_client_demod;
struct i2c_client *i2c_client_tuner;
+
+   struct mutex stream_mutex;
+   u8 last_lock;
+   int (*fe_read_status)(struct dvb_frontend *fe,
+   enum fe_status *status);
 };
 
 #endif
-- 
1.9.1


--
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: [GIT PULL STABLE 4.6] af9035 regression

[Mauro Carvalho Chehab]

Em Fri, 9 Sep 2016 18:04:07 +0300
Antti Palosaari  escreveu:

> On 09/09/2016 05:49 PM, Mauro Carvalho Chehab wrote:
> > Hi Antti,
> >
> > Em Sat, 3 Sep 2016 02:40:52 +0300
> > Antti Palosaari  escreveu:
> >  
> >> The following changes since commit 
> >> 2dcd0af568b0cf583645c8a317dd12e344b1c72a:
> >>
> >>Linux 4.6 (2016-05-15 15:43:13 -0700)  
> >
> > Is this patchset really meant to Kernel 4.6? if so, you should send
> > the path to sta...@vger.kernel.org, c/c the mailing list.
> >
> > It helps to point the original patch that fixed the issue upstream,
> > as they won't apply the fix if it was not fixed upstream yet.  
> 
> I think you already applied upstream patch, that one is just back-ported 
> to 4.6.

Ah!

> It is that patch:
> https://patchwork.linuxtv.org/patch/36795/
> 
> and it contains all the needed tags including Cc stable. Could you send 
> it to stable?

Just send the patch directly to sta...@vger.kernel.org. if you
C/C me, I'll add my acked-by.

> 
> Antti
> 
> >
> > Regards,
> > Mauro
> >  
> >>
> >> are available in the git repository at:
> >>
> >>git://linuxtv.org/anttip/media_tree.git af9035_fix
> >>
> >> for you to fetch changes up to 7bb87ff5255defe87916f32cd1fcef163a489339:
> >>
> >>af9035: fix dual tuner detection with PCTV 79e (2016-09-03 02:23:44
> >> +0300)
> >>
> >> 
> >> Stefan Pöschel (1):
> >>af9035: fix dual tuner detection with PCTV 79e
> >>
> >>   drivers/media/usb/dvb-usb-v2/af9035.c | 53
> >> +++--
> >>   drivers/media/usb/dvb-usb-v2/af9035.h |  2 +-
> >>   2 files changed, 36 insertions(+), 19 deletions(-)
> >>  
> >
> >
> >
> > Thanks,
> > Mauro
> >  
> 



Thanks,
Mauro
--
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: [Intel-gfx] [PATCH 4/5] drm/i915: Use __sg_alloc_table_from_pages for allocating object backing store

[Tvrtko Ursulin]

On 21/10/2016 15:27, Chris Wilson wrote:

On Fri, Oct 21, 2016 at 03:11:22PM +0100, Tvrtko Ursulin wrote:

@@ -2236,18 +2233,16 @@ i915_gem_object_get_pages_gtt(struct 
drm_i915_gem_object *obj)
BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);

-   max_segment = swiotlb_max_size();
-   if (!max_segment)
-   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
-
-   st = kmalloc(sizeof(*st), GFP_KERNEL);
-   if (st == NULL)
-   return -ENOMEM;
-
page_count = obj->base.size / PAGE_SIZE;
-   if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
-   kfree(st);
+   pages = drm_malloc_gfp(page_count, sizeof(struct page *),
+  GFP_TEMPORARY | __GFP_ZERO);
+   if (!pages)
return -ENOMEM;


Full circle! The whole reason this exists was to avoid that vmalloc. I
don't really want it back...


Yes, it is not ideal.

However all objects under 4 MiB should fall under the kmalloc fast path 
(8 KiB of struct page pointers, which should always be available), and 
possibly bigger ones as well if there is room.


It only fallbacks to vmalloc for objects larger than 4 MiB, when it also 
fails to get the page pointer array from the SLAB (GFP_TEMPORARY).


So perhaps SLAB would most of the time have some nice chunks for us to 
pretty much limit vmalloc apart for the huge objects? And then, is 
creation time for those so performance critical?


I came up with this because I started to dislike my previous 
sg_trim_table approach as too ugly. It had an advantage of simplicity 
after fixing the theoretical chunk overflow in sg_alloc_table_from_pages.


If we choose none of the two, only third option I can think of is to 
allocate the sg table as we add entries to it. I don't think it would be 
hard to do that.


Regards,

Tvrtko
--
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: [RFC 1/5] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

Hi Laurent,

Thank you for the review comments.

> On Wednesday 12 Oct 2016 15:10:25 Ramesh Shanmugasundaram wrote:
> > This patch adds driver support for MAX2175 chip. This is Maxim
> > Integrated's RF to Bits tuner front end chip designed for
> > software-defined radio solutions. This driver exposes the tuner as a
> > sub-device instance with standard and custom controls to configure the
> device.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> >  ---
> >  .../devicetree/bindings/media/i2c/max2175.txt  |   60 +
> >  drivers/media/i2c/Kconfig  |4 +
> >  drivers/media/i2c/Makefile |2 +
> >  drivers/media/i2c/max2175/Kconfig  |8 +
> >  drivers/media/i2c/max2175/Makefile |4 +
> >  drivers/media/i2c/max2175/max2175.c| 1624
> +
> >  drivers/media/i2c/max2175/max2175.h|  124 ++
> >  7 files changed, 1826 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/i2c/max2175.txt
> >  create mode 100644 drivers/media/i2c/max2175/Kconfig  create mode
> > 100644 drivers/media/i2c/max2175/Makefile
> >  create mode 100644 drivers/media/i2c/max2175/max2175.c
> >  create mode 100644 drivers/media/i2c/max2175/max2175.h
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt
> > b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file
> > mode
> > 100644
> > index 000..2250d5f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> > @@ -0,0 +1,60 @@
> > +Maxim Integrated MAX2175 RF to Bits tuner
> > +-
> > +
> > +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver
> > +with RF to Bits(r) front-end designed for software-defined radio
> solutions.
> > +
> > +Required properties:
> > +
> > +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> > +- clocks: phandle to the fixed xtal clock.
> > +- clock-names: name of the fixed xtal clock.
> > +- port: video interface child port node of a tuner that defines the
> > +local
> 
> As Rob pointed out in his review of patch 3/5, this isn't video.

Agreed & corrected.

> 
> > +  and remote endpoints. The remote endpoint is assumed to be an SDR
> > + device  that is capable of receiving the digital samples from the
> tuner.
> > +
> > +Optional properties:
> > +
> > +- maxim,slave : empty property indicates this is a slave of
> another
> > +master tuner. This is used to define two tuners in
> > +diversity mode (1 master, 1 slave). By default each
> > +tuner is an individual master.
> 
> Would it be useful to make that property a phandle to the master tuner, to
> give drivers a way to access the master ? I haven't checked whether there
> could be use cases for that.

As of now, I cannot find any use case for it from the datasheet. In future, we 
could add if such need arise.

> 
> > +- maxim,refout-load: load capacitance value (in pF) on reference output
> > +drive level. The mapping of these load values to
> > +respective bit values are given below.
> > +0 - Reference output disabled
> > +1 - 10pF load
> > +2 - 20pF load
> > +3 - 30pF load
> > +4 - 40pF load
> > +5 - 60pF load
> > +6 - 70pF load
> 
> As Geert pointed out, you can simply specify the value in pF.

Agreed & corrected.

> 
> > +
> > +Example:
> > +
> > +
> > +Board specific DTS file
> > +
> > +/* Fixed XTAL clock node */
> > +maxim_xtal: maximextal {
> > +   compatible = "fixed-clock";
> > +   #clock-cells = <0>;
> > +   clock-frequency = <36864000>;
> > +};
> > +
> > +/* A tuner device instance under i2c bus */
> > +max2175_0: tuner@60 {
> > +   #clock-cells = <0>;
> 
> Is the tuner a clock provider ? If it isn't you don't need this property.

Thanks. It's a copy/paste mistake :-(. Corrected.

> 
> > +   compatible = "maxim,max2175";
> > +   reg = <0x60>;
> > +   clocks = <_xtal>;
> > +   clock-names = "xtal";
> > +   maxim,refout-load = <10>;
> > +
> > +   port {
> > +   max2175_0_ep: endpoint {
> > +   remote-endpoint = <_rx_v4l2_sdr_device>;
> > +   };
> > +   };
> > +
> > +};
> 
> [snip]
> 
> > diff --git a/drivers/media/i2c/max2175/Makefile
> > b/drivers/media/i2c/max2175/Makefile new file mode 100644 index
> > 000..9bb46ac
> > --- /dev/null
> > +++ b/drivers/media/i2c/max2175/Makefile
> > @@ -0,0 +1,4 @@
> > +#
> > +# Makefile for Maxim RF to Bits tuner device #
> > +obj-$(CONFIG_SDR_MAX2175) += max2175.o
> 
> If there's a single source file you might want to move it to
> drivers/media/i2c/.

MAX2175 is huge with lot more modes and functionality. When more modes are 
added (it's pre-set hex values), 

Re: [PATCH v3 02/10] v4l: ctrls: Add deinterlacing mode control

[Hans Verkuil]

On 09/08/16 00:25, Laurent Pinchart wrote:

The menu control selects the operation mode of a video deinterlacer. The
menu entries are driver specific.

Signed-off-by: Laurent Pinchart 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 4 
 drivers/media/v4l2-core/v4l2-ctrls.c   | 2 ++
 include/uapi/linux/v4l2-controls.h | 1 +
 3 files changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 1f1518e4859d..8e6314e23cd3 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -4250,6 +4250,10 @@ Image Process Control IDs
 test pattern images. These hardware specific test patterns can be
 used to test if a device is working properly.

+``V4L2_CID_DEINTERLACING_MODE (menu)``
+The video deinterlacing mode (such as Bob, Weave, ...). The menu items are
+driver specific.
+


I'm fine with the patch but I wonder where these modes will be documented.
I know that some of those modes will be hard to document since the HW docs
might give little or no information, but even that is useful information to
have.

We now have driver-specific documentation as part of the kernel docs, so I
would suggest that that is a good place. If we do that, then this control
documentation should refer there.

For this patch:

Acked-by: Hans Verkuil 

BUT: it can't be merged without an actual driver that uses this, and as
I mentioned on irc I didn't see a patch for that yet.

Regards,

Hans



 .. _dv-controls:

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index adc2147fcff7..47001e25fd9e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -885,6 +885,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_LINK_FREQ:return "Link Frequency";
case V4L2_CID_PIXEL_RATE:   return "Pixel Rate";
case V4L2_CID_TEST_PATTERN: return "Test Pattern";
+   case V4L2_CID_DEINTERLACING_MODE:   return "Deinterlacing Mode";

/* DV controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1058,6 +1059,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_DV_RX_RGB_RANGE:
case V4L2_CID_DV_RX_IT_CONTENT_TYPE:
case V4L2_CID_TEST_PATTERN:
+   case V4L2_CID_DEINTERLACING_MODE:
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
case V4L2_CID_DETECT_MD_MODE:
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index b6a357a5f053..0d2e1e01fbd5 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -892,6 +892,7 @@ enum v4l2_jpeg_chroma_subsampling {
 #define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 1)
 #define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 2)
 #define V4L2_CID_TEST_PATTERN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 3)
+#define V4L2_CID_DEINTERLACING_MODE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 4)


 /*  DV-class control IDs defined by V4L2 */


--
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 4/5] drm/i915: Use __sg_alloc_table_from_pages for allocating object backing store

[Chris Wilson]

On Fri, Oct 21, 2016 at 03:11:22PM +0100, Tvrtko Ursulin wrote:
> @@ -2236,18 +2233,16 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>   BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
>   BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
>  
> - max_segment = swiotlb_max_size();
> - if (!max_segment)
> - max_segment = rounddown(UINT_MAX, PAGE_SIZE);
> -
> - st = kmalloc(sizeof(*st), GFP_KERNEL);
> - if (st == NULL)
> - return -ENOMEM;
> -
>   page_count = obj->base.size / PAGE_SIZE;
> - if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
> - kfree(st);
> + pages = drm_malloc_gfp(page_count, sizeof(struct page *),
> +GFP_TEMPORARY | __GFP_ZERO);
> + if (!pages)
>   return -ENOMEM;

Full circle! The whole reason this exists was to avoid that vmalloc. I
don't really want it back...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
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 3/5] lib/scatterlist: Introduce and export __sg_alloc_table_from_pages

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Drivers like i915 benefit from being able to control the maxium
size of the sg coallesced segment while building the scatter-
gather list.

Introduce and export the __sg_alloc_table_from_pages function
which will allow it that control.

Signed-off-by: Tvrtko Ursulin 
Cc: Masahiro Yamada 
Cc: linux-ker...@vger.kernel.org
---
 include/linux/scatterlist.h | 11 +
 lib/scatterlist.c   | 55 ++---
 2 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index c981bee1a3ae..29591dbb20fd 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -261,10 +261,13 @@ void sg_free_table(struct sg_table *);
 int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int,
 struct scatterlist *, gfp_t, sg_alloc_fn *);
 int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
-int sg_alloc_table_from_pages(struct sg_table *sgt,
-   struct page **pages, unsigned int n_pages,
-   unsigned int offset, unsigned long size,
-   gfp_t gfp_mask);
+int __sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+   unsigned int n_pages, unsigned int offset,
+   unsigned long size, gfp_t gfp_mask,
+   unsigned int max_segment);
+int sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+ unsigned int n_pages, unsigned int offset,
+ unsigned long size, gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
  size_t buflen, off_t skip, bool to_buffer);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index d928fa04aee3..0378c5fd7caa 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -370,14 +370,15 @@ int sg_alloc_table(struct sg_table *table, unsigned int 
nents, gfp_t gfp_mask)
 EXPORT_SYMBOL(sg_alloc_table);
 
 /**
- * sg_alloc_table_from_pages - Allocate and initialize an sg table from
- *an array of pages
- * @sgt:   The sg table header to use
- * @pages: Pointer to an array of page pointers
- * @n_pages:   Number of pages in the pages array
- * @offset: Offset from start of the first page to the start of a buffer
- * @size:   Number of valid bytes in the buffer (after offset)
- * @gfp_mask:  GFP allocation mask
+ * __sg_alloc_table_from_pages - Allocate and initialize an sg table from
+ *  an array of pages
+ * @sgt:The sg table header to use
+ * @pages:  Pointer to an array of page pointers
+ * @n_pages:Number of pages in the pages array
+ * @offset:  Offset from start of the first page to the start of a buffer
+ * @size:Number of valid bytes in the buffer (after offset)
+ * @gfp_mask:   GFP allocation mask
+ * @max_segment: Maximum size of a single scatterlist node in bytes
  *
  *  Description:
  *Allocate and initialize an sg table from a list of pages. Contiguous
@@ -389,12 +390,11 @@ EXPORT_SYMBOL(sg_alloc_table);
  * Returns:
  *   0 on success, negative error on failure
  */
-int sg_alloc_table_from_pages(struct sg_table *sgt,
-   struct page **pages, unsigned int n_pages,
-   unsigned int offset, unsigned long size,
-   gfp_t gfp_mask)
+int __sg_alloc_table_from_pages(struct sg_table *sgt, struct page **pages,
+   unsigned int n_pages, unsigned int offset,
+   unsigned long size, gfp_t gfp_mask,
+   unsigned int max_segment)
 {
-   const unsigned int max_segment = ~0;
unsigned int seg_len, chunks;
unsigned int i;
unsigned int cur_page;
@@ -444,6 +444,35 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
 
return 0;
 }
+EXPORT_SYMBOL(__sg_alloc_table_from_pages);
+
+/**
+ * sg_alloc_table_from_pages - Allocate and initialize an sg table from
+ *an array of pages
+ * @sgt:The sg table header to use
+ * @pages:  Pointer to an array of page pointers
+ * @n_pages:Number of pages in the pages array
+ * @offset:  Offset from start of the first page to the start of a buffer
+ * @size:Number of valid bytes in the buffer (after offset)
+ * @gfp_mask:   GFP allocation mask
+ *
+ *  Description:
+ *Allocate and initialize an sg table from a list of pages. Contiguous
+ *ranges of the pages are squashed into a single scatterlist node. A user
+ *may provide an offset at a start and a size of valid data in a buffer
+ *specified by the page array. The returned sg table is released by
+ *sg_free_table.
+ *
+ * Returns:
+ *   0 on success, negative error on failure
+ */
+int sg_alloc_table_from_pages(struct 

[PATCH 4/5] drm/i915: Use __sg_alloc_table_from_pages for allocating object backing store

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

With the current way of allocating backing store which over-estimates
the number of sg entries required we typically waste around 1-6 MiB of
memory on unused sg entries at runtime.

We can instead have the intermediate step of storing our pages in an
array and use __sg_alloc_table_from_pages which will create us the
most compact list possible.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 72 -
 1 file changed, 35 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ed8e24025ac..4bf675568a37 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2208,9 +2208,9 @@ i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
 static unsigned int swiotlb_max_size(void)
 {
 #if IS_ENABLED(CONFIG_SWIOTLB)
-   return rounddown(swiotlb_nr_tbl() << IO_TLB_SHIFT, PAGE_SIZE);
+   return swiotlb_nr_tbl() << IO_TLB_SHIFT;
 #else
-   return 0;
+   return UINT_MAX;
 #endif
 }
 
@@ -2221,11 +2221,8 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
int page_count, i;
struct address_space *mapping;
struct sg_table *st;
-   struct scatterlist *sg;
-   struct sgt_iter sgt_iter;
-   struct page *page;
-   unsigned long last_pfn = 0; /* suppress gcc warning */
-   unsigned int max_segment;
+   struct page *page, **pages;
+   unsigned int max_segment = swiotlb_max_size();
int ret;
gfp_t gfp;
 
@@ -2236,18 +2233,16 @@ i915_gem_object_get_pages_gtt(struct 
drm_i915_gem_object *obj)
BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
 
-   max_segment = swiotlb_max_size();
-   if (!max_segment)
-   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
-
-   st = kmalloc(sizeof(*st), GFP_KERNEL);
-   if (st == NULL)
-   return -ENOMEM;
-
page_count = obj->base.size / PAGE_SIZE;
-   if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
-   kfree(st);
+   pages = drm_malloc_gfp(page_count, sizeof(struct page *),
+  GFP_TEMPORARY | __GFP_ZERO);
+   if (!pages)
return -ENOMEM;
+
+   st = kmalloc(sizeof(*st), GFP_KERNEL);
+   if (st == NULL) {
+   ret = -ENOMEM;
+   goto err_st;
}
 
/* Get the list of pages out of our struct file.  They'll be pinned
@@ -2258,8 +2253,6 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
mapping = obj->base.filp->f_mapping;
gfp = mapping_gfp_constraint(mapping, ~(__GFP_IO | __GFP_RECLAIM));
gfp |= __GFP_NORETRY | __GFP_NOWARN;
-   sg = st->sgl;
-   st->nents = 0;
for (i = 0; i < page_count; i++) {
page = shmem_read_mapping_page_gfp(mapping, i, gfp);
if (IS_ERR(page)) {
@@ -2281,29 +2274,28 @@ i915_gem_object_get_pages_gtt(struct 
drm_i915_gem_object *obj)
goto err_pages;
}
}
-   if (!i ||
-   sg->length >= max_segment ||
-   page_to_pfn(page) != last_pfn + 1) {
-   if (i)
-   sg = sg_next(sg);
-   st->nents++;
-   sg_set_page(sg, page, PAGE_SIZE, 0);
-   } else {
-   sg->length += PAGE_SIZE;
-   }
-   last_pfn = page_to_pfn(page);
+
+   pages[i] = page;
 
/* Check that the i965g/gm workaround works. */
-   WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL));
+   WARN_ON((gfp & __GFP_DMA32) &&
+   (page_to_pfn(page) >= 0x0010UL));
}
-   if (sg) /* loop terminated early; short sg table */
-   sg_mark_end(sg);
+
+   ret = __sg_alloc_table_from_pages(st, pages, page_count, 0,
+ obj->base.size, GFP_KERNEL,
+ max_segment);
+   if (ret)
+   goto err_pages;
+
obj->pages = st;
 
ret = i915_gem_gtt_prepare_object(obj);
if (ret)
goto err_pages;
 
+   drm_free_large(pages);
+
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj);
 
@@ -2314,10 +2306,13 @@ i915_gem_object_get_pages_gtt(struct 
drm_i915_gem_object *obj)
return 0;
 
 err_pages:
-   sg_mark_end(sg);
-   for_each_sgt_page(page, sgt_iter, st)
-   put_page(page);
-   sg_free_table(st);
+   for (i = 0; i < page_count; i++) {
+   if (pages[i])
+   put_page(pages[i]);
+   else
+ 

[PATCH 0/5] Avoid pessimistic scatter-gather allocation

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We can decrease the i915 kernel memory usage by doing more sg list
coallescing and avoiding the pessimistic list allocation.

At the moment we got two places in our code, the main shmemfs backed
object allocator, and the userptr object allocator, which both can
allocate sg list size pessimistically, and in the latter case also do
not exploit entry coallescing when it is possible.

This results in between one to six megabytes of memory wasted on unused
sg list entries under some common workloads:

* Logging into KDE there is 1-2 MiB of unused sg entries.
* Running the T-Rex benchamrk aroun 3 Mib.
* Similarly for Manhattan 5-6 MiB.

To remove this wastage this series starts with some cleanups in the
sg_alloc_table_from_pages implementation and then adds and exports a new
__sg_alloc_table_from_pages function.

This then gets used by the i915 driver to achieve the described savings.

Tvrtko Ursulin (5):
  lib/scatterlist: Fix offset type in sg_alloc_table_from_pages
  lib/scatterlist: Avoid potential scatterlist entry overflow
  lib/scatterlist: Introduce and export __sg_alloc_table_from_pages
  drm/i915: Use __sg_alloc_table_from_pages for allocating object
backing store
  drm/i915: Use __sg_alloc_table_from_pages for userptr allocations

 drivers/gpu/drm/i915/i915_drv.h|  9 +++
 drivers/gpu/drm/i915/i915_gem.c| 77 +++--
 drivers/gpu/drm/i915/i915_gem_userptr.c| 29 +++---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 +-
 drivers/rapidio/devices/rio_mport_cdev.c   |  4 +-
 include/linux/scatterlist.h| 11 ++--
 lib/scatterlist.c  | 78 --
 7 files changed, 120 insertions(+), 92 deletions(-)

-- 
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

[PATCH 2/5] lib/scatterlist: Avoid potential scatterlist entry overflow

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Since the scatterlist length field is an unsigned int, make
sure that sg_alloc_table_from_pages does not overflow it while
coallescing pages to a single entry.

It is I think only a theoretical possibility at the moment,
but the ability to limit the coallesced size will have
another use in following patches.

Signed-off-by: Tvrtko Ursulin 
Cc: Masahiro Yamada 
Cc: linux-ker...@vger.kernel.org
---
 lib/scatterlist.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index e05e7fc98892..d928fa04aee3 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -394,7 +394,8 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
unsigned int offset, unsigned long size,
gfp_t gfp_mask)
 {
-   unsigned int chunks;
+   const unsigned int max_segment = ~0;
+   unsigned int seg_len, chunks;
unsigned int i;
unsigned int cur_page;
int ret;
@@ -402,9 +403,16 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
 
/* compute number of contiguous chunks */
chunks = 1;
-   for (i = 1; i < n_pages; ++i)
-   if (page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) + 1)
+   seg_len = PAGE_SIZE;
+   for (i = 1; i < n_pages; ++i) {
+   if (seg_len >= max_segment ||
+   page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) + 1) {
++chunks;
+   seg_len = PAGE_SIZE;
+   } else {
+   seg_len += PAGE_SIZE;
+   }
+   }
 
ret = sg_alloc_table(sgt, chunks, gfp_mask);
if (unlikely(ret))
@@ -413,17 +421,22 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
/* merging chunks and putting them into the scatterlist */
cur_page = 0;
for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
-   unsigned long chunk_size;
+   unsigned int chunk_size;
unsigned int j;
 
/* look for the end of the current chunk */
+   seg_len = PAGE_SIZE;
for (j = cur_page + 1; j < n_pages; ++j)
-   if (page_to_pfn(pages[j]) !=
+   if (seg_len >= max_segment ||
+   page_to_pfn(pages[j]) !=
page_to_pfn(pages[j - 1]) + 1)
break;
+   else
+   seg_len += PAGE_SIZE;
 
chunk_size = ((j - cur_page) << PAGE_SHIFT) - offset;
-   sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
+   sg_set_page(s, pages[cur_page],
+   min_t(unsigned long, size, chunk_size), offset);
size -= chunk_size;
offset = 0;
cur_page = j;
-- 
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

[PATCH 1/5] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Scatterlist entries have an unsigned int for the offset so
correct the sg_alloc_table_from_pages function accordingly.

Since these are offsets withing a page, unsigned int is
wide enough.

Also converts callers which were using unsigned long locally
with the lower_32_bits annotation to make it explicitly
clear what is happening.

Signed-off-by: Tvrtko Ursulin 
Cc: Masahiro Yamada 
Cc: Pawel Osciak 
Cc: Marek Szyprowski 
Cc: Kyungmin Park 
Cc: Tomasz Stanislawski 
Cc: Matt Porter 
Cc: Alexandre Bounine 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
 drivers/rapidio/devices/rio_mport_cdev.c   | 4 ++--
 include/linux/scatterlist.h| 2 +-
 lib/scatterlist.c  | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index fb6a177be461..a3aac7533241 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -478,7 +478,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
 {
struct vb2_dc_buf *buf;
struct frame_vector *vec;
-   unsigned long offset;
+   unsigned int offset;
int n_pages, i;
int ret = 0;
struct sg_table *sgt;
@@ -506,7 +506,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
buf->dev = dev;
buf->dma_dir = dma_dir;
 
-   offset = vaddr & ~PAGE_MASK;
+   offset = lower_32_bits(vaddr & ~PAGE_MASK);
vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
if (IS_ERR(vec)) {
ret = PTR_ERR(vec);
diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
b/drivers/rapidio/devices/rio_mport_cdev.c
index 436dfe871d32..f545cf20561f 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -876,10 +876,10 @@ rio_dma_transfer(struct file *filp, u32 transfer_mode,
 * offset within the internal buffer specified by handle parameter.
 */
if (xfer->loc_addr) {
-   unsigned long offset;
+   unsigned int offset;
long pinned;
 
-   offset = (unsigned long)(uintptr_t)xfer->loc_addr & ~PAGE_MASK;
+   offset = lower_32_bits(xfer->loc_addr & ~PAGE_MASK);
nr_pages = PAGE_ALIGN(xfer->length + offset) >> PAGE_SHIFT;
 
page_list = kmalloc_array(nr_pages,
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index cb3c8fe6acd7..c981bee1a3ae 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -263,7 +263,7 @@ int __sg_alloc_table(struct sg_table *, unsigned int, 
unsigned int,
 int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
 int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
-   unsigned long offset, unsigned long size,
+   unsigned int offset, unsigned long size,
gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 004fc70fc56a..e05e7fc98892 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -391,7 +391,7 @@ EXPORT_SYMBOL(sg_alloc_table);
  */
 int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
-   unsigned long offset, unsigned long size,
+   unsigned int offset, unsigned long size,
gfp_t gfp_mask)
 {
unsigned int chunks;
-- 
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

[PATCH 5/5] drm/i915: Use __sg_alloc_table_from_pages for userptr allocations

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

With the addition of __sg_alloc_table_from_pages we can control
the maximum coallescing size and eliminate a separate path for
allocating backing store here.

This also makes the tables as compact as possible in all cases.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  9 +
 drivers/gpu/drm/i915/i915_gem.c | 11 +--
 drivers/gpu/drm/i915/i915_gem_userptr.c | 29 +++--
 3 files changed, 17 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5b2b7f3c6e76..577a3a87f680 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4001,4 +4001,13 @@ int remap_io_mapping(struct vm_area_struct *vma,
__T;\
 })
 
+static inline unsigned int i915_swiotlb_max_size(void)
+{
+#if IS_ENABLED(CONFIG_SWIOTLB)
+   return swiotlb_nr_tbl() << IO_TLB_SHIFT;
+#else
+   return UINT_MAX;
+#endif
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4bf675568a37..18125d7279c6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2205,15 +2205,6 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
return 0;
 }
 
-static unsigned int swiotlb_max_size(void)
-{
-#if IS_ENABLED(CONFIG_SWIOTLB)
-   return swiotlb_nr_tbl() << IO_TLB_SHIFT;
-#else
-   return UINT_MAX;
-#endif
-}
-
 static int
 i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
 {
@@ -,7 +2213,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
struct address_space *mapping;
struct sg_table *st;
struct page *page, **pages;
-   unsigned int max_segment = swiotlb_max_size();
+   unsigned int max_segment = i915_swiotlb_max_size();
int ret;
gfp_t gfp;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index e537930c64b5..17dca225a3e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -397,36 +397,21 @@ struct get_pages_work {
struct task_struct *task;
 };
 
-#if IS_ENABLED(CONFIG_SWIOTLB)
-#define swiotlb_active() swiotlb_nr_tbl()
-#else
-#define swiotlb_active() 0
-#endif
-
 static int
 st_set_pages(struct sg_table **st, struct page **pvec, int num_pages)
 {
-   struct scatterlist *sg;
-   int ret, n;
+   unsigned int max_segment = i915_swiotlb_max_size();
+   int ret;
 
*st = kmalloc(sizeof(**st), GFP_KERNEL);
if (*st == NULL)
return -ENOMEM;
 
-   if (swiotlb_active()) {
-   ret = sg_alloc_table(*st, num_pages, GFP_KERNEL);
-   if (ret)
-   goto err;
-
-   for_each_sg((*st)->sgl, sg, num_pages, n)
-   sg_set_page(sg, pvec[n], PAGE_SIZE, 0);
-   } else {
-   ret = sg_alloc_table_from_pages(*st, pvec, num_pages,
-   0, num_pages << PAGE_SHIFT,
-   GFP_KERNEL);
-   if (ret)
-   goto err;
-   }
+   ret = __sg_alloc_table_from_pages(*st, pvec, num_pages, 0,
+ num_pages << PAGE_SHIFT,
+ GFP_KERNEL, max_segment);
+   if (ret)
+   goto err;
 
return 0;
 
-- 
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

[PATCH 3/4] mtk_mdp_m2m: remove an unused struct

[Mauro Carvalho Chehab]

drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:48:33: warning: 
‘mtk_mdp_size_align’ defined but not used [-Wunused-variable]
 static struct mtk_mdp_pix_align mtk_mdp_size_align = {
 ^~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 065502757133..33124a6c9951 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -45,13 +45,6 @@ struct mtk_mdp_pix_limit {
u16 target_rot_en_h;
 };
 
-static struct mtk_mdp_pix_align mtk_mdp_size_align = {
-   .org_w  = 16,
-   .org_h  = 16,
-   .target_w   = 2,
-   .target_h   = 2,
-};
-
 static const struct mtk_mdp_fmt mtk_mdp_formats[] = {
{
.pixelformat= V4L2_PIX_FMT_NV12M,
-- 
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

[PATCH] mtk-vcodec: fix some smatch warnings

[Mauro Carvalho Chehab]

Fix this bug:
drivers/media/platform/mtk-vcodec/vdec_drv_if.c:38 vdec_if_init() info: 
ignoring unreachable code.

With is indeed a real problem that prevents the driver to work!

While here, also remove an used var, as reported by smatch:

drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 
'mtk_vcodec_init_dec_pm':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:29:17: warning: 
variable 'dev' set but not used [-Wunused-but-set-variable]
  struct device *dev;
 ^~~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 2 --
 drivers/media/platform/mtk-vcodec/vdec_drv_if.c   | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 18182f5676d8..79ca03ac449c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -26,14 +26,12 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
 {
struct device_node *node;
struct platform_device *pdev;
-   struct device *dev;
struct mtk_vcodec_pm *pm;
int ret = 0;
 
pdev = mtkdev->plat_dev;
pm = >pm;
pm->mtkdev = mtkdev;
-   dev = >dev;
node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
if (!node) {
mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
diff --git a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
index 3cb04ef45144..9813b2ffd5fa 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
@@ -31,6 +31,7 @@ int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int 
fourcc)
switch (fourcc) {
case V4L2_PIX_FMT_H264:
case V4L2_PIX_FMT_VP8:
+   break;
default:
return -EINVAL;
}
-- 
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

[PATCH 4/4] mtk-mdp: fix compilation warnings if !DEBUG

[Mauro Carvalho Chehab]

The mtk_mdp_dbg() is empty if !DEBUG. This causes the following
warnings:

drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c: In function 
‘mtk_mdp_try_fmt_mplane’:
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:231:52: warning: suggest 
braces around empty body in an ‘if’ statement [-Wempty-body]
org_w, org_h, pix_mp->width, pix_mp->height);
^
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c: In function 
‘mtk_mdp_m2m_start_streaming’:
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:414:21: warning: suggest 
braces around empty body in an ‘if’ statement [-Wempty-body]
ctx->id, ret);
 ^

With could actually make the code to do something wrong. So,
add an empty block to make it be parsed ok.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h 
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
index 2e979f97d1df..848569d4ab90 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
@@ -250,7 +250,7 @@ extern int mtk_mdp_dbg_level;
 
 #else
 
-#define mtk_mdp_dbg(level, fmt, args...)
+#define mtk_mdp_dbg(level, fmt, args...) {}
 #define mtk_mdp_err(fmt, args...)
 #define mtk_mdp_dbg_enter()
 #define mtk_mdp_dbg_leave()
-- 
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

[PATCH 1/4] mtk_mdp_vpu: fix build with COMPILE_TEST for 32 bits

[Mauro Carvalho Chehab]

When building on i386 in 32 bits, several new warnings appear:

drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 
'mtk_mdp_vpu_handle_init_ack':
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:28:28: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
  struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
^
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 
'mtk_mdp_vpu_ipi_handler':
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:40:28: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
  struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
^
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 
'mtk_mdp_vpu_send_ap_ipi':
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:111:16: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
  msg.ap_inst = (uint64_t)vpu;
^
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_init':
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:129:16: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
  msg.ap_inst = (uint64_t)vpu;
^

That's because the driver assumes that it will be built only on
64 bits. As we don't want extra warnings when building with 32
bits, we need to double-cast.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
index fb07bf3dbd8b..b38d29e99f7a 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
@@ -25,7 +25,7 @@ static inline struct mtk_mdp_ctx *vpu_to_ctx(struct 
mtk_mdp_vpu *vpu)
 
 static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg)
 {
-   struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
+   struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)(long)msg->ap_inst;
 
/* mapping VPU address to kernel virtual address */
vpu->vsi = (struct mdp_process_vsi *)
@@ -37,7 +37,7 @@ static void mtk_mdp_vpu_ipi_handler(void *data, unsigned int 
len, void *priv)
 {
unsigned int msg_id = *(unsigned int *)data;
struct mdp_ipi_comm_ack *msg = (struct mdp_ipi_comm_ack *)data;
-   struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
+   struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)(long)msg->ap_inst;
struct mtk_mdp_ctx *ctx;
 
vpu->failure = msg->status;
@@ -108,7 +108,7 @@ static int mtk_mdp_vpu_send_ap_ipi(struct mtk_mdp_vpu *vpu, 
uint32_t msg_id)
msg.msg_id = msg_id;
msg.ipi_id = IPI_MDP;
msg.vpu_inst_addr = vpu->inst_addr;
-   msg.ap_inst = (uint64_t)vpu;
+   msg.ap_inst = (uint64_t)(long)vpu;
err = mtk_mdp_vpu_send_msg((void *), sizeof(msg), vpu, IPI_MDP);
if (!err && vpu->failure)
err = -EINVAL;
@@ -126,7 +126,7 @@ int mtk_mdp_vpu_init(struct mtk_mdp_vpu *vpu)
 
msg.msg_id = AP_MDP_INIT;
msg.ipi_id = IPI_MDP;
-   msg.ap_inst = (uint64_t)vpu;
+   msg.ap_inst = (uint64_t)(long)vpu;
err = mtk_mdp_vpu_send_msg((void *), sizeof(msg), vpu, IPI_MDP);
if (!err && vpu->failure)
err = -EINVAL;
-- 
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

[PATCH 2/4] mtk_mdp_vpu: remove a double unlock at the error path

[Mauro Carvalho Chehab]

As warned by smatch:
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:98 mtk_mdp_vpu_send_msg() 
error: double unlock 'mutex:>mdp_dev->vpulock'

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
index b38d29e99f7a..5c8caa864e32 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
@@ -91,7 +91,6 @@ static int mtk_mdp_vpu_send_msg(void *msg, int len, struct 
mtk_mdp_vpu *vpu,
mutex_lock(>mdp_dev->vpulock);
err = vpu_ipi_send(vpu->pdev, (enum ipi_id)id, msg, len);
if (err) {
-   mutex_unlock(>mdp_dev->vpulock);
dev_err(>mdp_dev->pdev->dev,
"vpu_ipi_send fail status %d\n", err);
}
-- 
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: [RFC 3/5] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

Hi Laurent,

Thank you for the review comments.

> On Tuesday 18 Oct 2016 16:29:24 Geert Uytterhoeven wrote:
> > On Wed, Oct 12, 2016 at 4:10 PM, Ramesh Shanmugasundaram wrote:
> > > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3
> SoCs.
> > > The driver exposes each instance of DRIF as a V4L2 SDR device. A
> > > DRIF device represents a channel and each channel can have one or
> > > two sub-channels respectively depending on the target board.
> > >
> > > DRIF supports only Rx functionality. It receives samples from a RF
> > > frontend tuner chip it is interfaced with. The combination of DRIF
> > > and the tuner device, which is registered as a sub-device,
> > > determines the receive sample rate and format.
> > >
> > > In order to be compliant as a V4L2 SDR device, DRIF needs to bind
> > > with the tuner device, which can be provided by a third party
> > > vendor. DRIF acts as a slave device and the tuner device acts as a
> > > master transmitting the samples. The driver allows asynchronous
> > > binding of a tuner device that is registered as a v4l2 sub-device.
> > > The driver can learn about the tuner it is interfaced with based on
> > > port endpoint properties of the device in device tree. The V4L2 SDR
> > > device inherits the controls exposed by the tuner device.
> > >
> > > The device can also be configured to use either one or both of the
> > > data pins at runtime based on the master (tuner) configuration.
> >
> > Thanks for your patch!
> >
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > > @@ -0,0 +1,109 @@
> > > +Renesas R-Car Gen3 DRIF controller (DRIF)
> > > +-
> > > +
> > > +Required properties:
> > > +
> > > +- compatible: "renesas,drif-r8a7795" if DRIF controller is a part
> > > +of
> > > R8A7795 SoC.
> >
> > "renesas,r8a7795-drif", as Rob already pointed out.
> >
> > > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3
> > > + compatible
> > > device.
> > > + When compatible with the generic version, nodes must
> > > + list
> > > the
> > > + SoC-specific version corresponding to the platform first
> > > + followed by the generic version.
> > > +
> > > +- reg: offset and length of each sub-channel.
> > > +- interrupts: associated with each sub-channel.
> > > +- clocks: phandles and clock specifiers for each sub-channel.
> > > +- clock-names: clock input name strings: "fck0", "fck1".
> > > +- pinctrl-0: pin control group to be used for this controller.
> > > +- pinctrl-names: must be "default".
> > > +- dmas: phandles to the DMA channels for each sub-channel.
> > > +- dma-names: names for the DMA channels: "rx0", "rx1".
> > > +
> > > +Required child nodes:
> > > +-
> > > +- Each DRIF channel can have one or both of the sub-channels
> > > +enabled in a
> > > +  setup. The sub-channels are represented as a child node. The name
> > > +of
> > > the
> > > +  child nodes are "sub-channel0" and "sub-channel1" respectively.
> > > + Each
> > > child
> > > +  node supports the "status" property only, which is used to
> > > enable/disable
> > > +  the respective sub-channel.
> > >
> > > +Example
> > > +
> > > +
> > > +SoC common dtsi file
> > > +
> > > +drif0: rif@e6f4 {
> > > +   compatible = "renesas,drif-r8a7795",
> > > +  "renesas,rcar-gen3-drif";
> > > +   reg = <0 0xe6f4 0 0x64>, <0 0xe6f5 0 0x64>;
> > > +   interrupts = ,
> > > +  ;
> > > +   clocks = < CPG_MOD 515>, < CPG_MOD 514>;
> > > +   clock-names = "fck0", "fck1";
> > > +   dmas = < 0x20>, < 0x22>;
> > > +   dma-names = "rx0", "rx1";
> >
> > I could not find the DMAC channels in the datasheet?
> > Most modules are either tied to dmac0, or two both dmac1 and dmac2.
> > In the latter case, you want to list two sets of dmas, one for each
> DMAC.
> >
> > > +   power-domains = < R8A7795_PD_ALWAYS_ON>;
> > > +   status = "disabled";
> > > +
> > > +   sub-channel0 {
> > > +   status = "disabled";
> > > +   };
> > > +
> > > +   sub-channel1 {
> > > +   status = "disabled";
> > > +   };
> > > +
> > > +};
> >
> > As you're modelling this in DT under a single device node, this means
> > you cannot use runtime PM to manage the module clocks of the
> > individual channels.
> >
> > An alternative could be to have two separate nodes for each channel,
> > and tie them together using a phandle.
> 
> A quick glance at the documentation shows no dependency between the two
> channels at a software level. They both share the same clock and
> synchronization input pins, but from a hardware point of view that seems
> to be it. It thus looks like we could indeed model the two channels as
> separate nodes, without tying them together.

Thanks & I agree with your suggestion to keep each DRIF sub-channels as 
separate node. However, I would 

RE: [RFC 3/5] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

Hi Geert,

Thank you for the review comments.

> On Wed, Oct 12, 2016 at 4:10 PM, Ramesh Shanmugasundaram
>  wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3
> SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and
> > the tuner device, which is registered as a sub-device, determines the
> > receive sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF
> > acts as a slave device and the tuner device acts as a master
> > transmitting the samples. The driver allows asynchronous binding of a
> > tuner device that is registered as a v4l2 sub-device. The driver can
> > learn about the tuner it is interfaced with based on port endpoint
> > properties of the device in device tree. The V4L2 SDR device inherits
> > the controls exposed by the tuner device.
> >
> > The device can also be configured to use either one or both of the
> > data pins at runtime based on the master (tuner) configuration.
> 
> Thanks for your patch!
> 
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,109 @@
> > +Renesas R-Car Gen3 DRIF controller (DRIF)
> > +-
> > +
> > +Required properties:
> > +
> > +- compatible: "renesas,drif-r8a7795" if DRIF controller is a part of
> R8A7795 SoC.
> 
> "renesas,r8a7795-drif", as Rob already pointed out.

Agreed.

> 
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3
> compatible device.
> > + When compatible with the generic version, nodes must list
> the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +
> > +- reg: offset and length of each sub-channel.
> > +- interrupts: associated with each sub-channel.
> > +- clocks: phandles and clock specifiers for each sub-channel.
> > +- clock-names: clock input name strings: "fck0", "fck1".
> > +- pinctrl-0: pin control group to be used for this controller.
> > +- pinctrl-names: must be "default".
> > +- dmas: phandles to the DMA channels for each sub-channel.
> > +- dma-names: names for the DMA channels: "rx0", "rx1".
> > +
> > +Required child nodes:
> > +-
> > +- Each DRIF channel can have one or both of the sub-channels enabled
> > +in a
> > +  setup. The sub-channels are represented as a child node. The name
> > +of the
> > +  child nodes are "sub-channel0" and "sub-channel1" respectively.
> > +Each child
> > +  node supports the "status" property only, which is used to
> > +enable/disable
> > +  the respective sub-channel.
> 
> > +Example
> > +
> > +
> > +SoC common dtsi file
> > +
> > +drif0: rif@e6f4 {
> > +   compatible = "renesas,drif-r8a7795",
> > +  "renesas,rcar-gen3-drif";
> > +   reg = <0 0xe6f4 0 0x64>, <0 0xe6f5 0 0x64>;
> > +   interrupts = ,
> > +  ;
> > +   clocks = < CPG_MOD 515>, < CPG_MOD 514>;
> > +   clock-names = "fck0", "fck1";
> > +   dmas = < 0x20>, < 0x22>;
> > +   dma-names = "rx0", "rx1";
> 
> I could not find the DMAC channels in the datasheet?

It is mentioned only in v0.5 h/w manual. v0.52 manual introduced DRIF chapter 
but then some of the old references were missing :-(. There are few more doc 
anomalies, which I shall document in the next version of the patch.

> Most modules are either tied to dmac0, or two both dmac1 and dmac2.
> In the latter case, you want to list two sets of dmas, one for each DMAC.

You are right. I have added both dmac1 & 2 now.

> 
> > +   power-domains = < R8A7795_PD_ALWAYS_ON>;
> > +   status = "disabled";
> > +
> > +   sub-channel0 {
> > +   status = "disabled";
> > +   };
> > +
> > +   sub-channel1 {
> > +   status = "disabled";
> > +   };
> > +
> > +};
> 
> As you're modelling this in DT under a single device node, this means you
> cannot use runtime PM to manage the module clocks of the individual
> channels.
> 
> An alternative could be to have two separate nodes for each channel, and
> tie them together using a phandle.

I agree & thanks for the suggestion. Is the below model looks anything closer? 
Appreciate your inputs.

dtsi
---

drif00: rif@e6f4 {
compatible = "renesas,r8a7795-drif",
 
"renesas,rcar-gen3-drif";
reg = <0 0xe6f4 0 0x64>;
interrupts = ;
   

lening bieden 3%

[UK CREDIT LTD LOAN]

--
Groeten heer / mevrouw:

 Ik ben Dr, Peter Ibrahim van particuliere lening bedrijf UK CREDIT LTD
lening, gevestigd in het Verenigd Koninkrijk.
Wij bieden alle soorten van leningen aan particulieren en bedrijven, 
Maak

jezelf financieel
stabiel door het verkrijgen van een lening van UK CREDIT LTD lening 3%
-tarief zo kort en
Langlopende leningen, zakelijke leningen, huiseigenaar leningen.
autoleningen enz.

 Vul hieronder als u geïnteresseerd bent in de lening van de lening
aanvraagformulier,

* Naam:
* Geslacht:
* Land / Adres:
* Bedrag dat nodig is:
* Maandinkomen Level
* Duur van de lening:
* Het doel van de lening:
* Telefoon:
* Geboortedatum

Neem contact met ons op via e-mail ukcreditltdlo...@gmail.com

Bedankt en vriendelijke groeten.

Dr, Peter Ibrahim.
--
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 v5 3/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

[Mauro Carvalho Chehab]

Em Fri, 21 Oct 2016 11:01:04 -0200
Mauro Carvalho Chehab  escreveu:

> Em Fri, 2 Sep 2016 20:19:54 +0800
> Tiffany Lin  escreveu:
> 
> > Add v4l2 layer decoder driver for MT8173
> > 
> > Signed-off-by: Tiffany Lin   
> 
> > +int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> > +{
> > +   int ret = 0;
> > +
> > +   switch (fourcc) {
> > +   case V4L2_PIX_FMT_H264:
> > +   case V4L2_PIX_FMT_VP8:
> > +   default:
> > +   return -EINVAL;
> > +   }  
> 
> Did you ever test this driver? The above code will *always* return
> -EINVAL, with will cause vidioc_vdec_s_fmt() to always fail!
> 
> I suspect that what you wanted to do, instead, is:
> 
>   switch (fourcc) {
>   case V4L2_PIX_FMT_H264:
>   case V4L2_PIX_FMT_VP8:
>   break;
>   default:
>   return -EINVAL;

Yeah, a latter patch in this series added a break there.

Thanks,
Mauro
--
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

lening bieden 3%

[UK CREDIT LTD LOAN]

--
Groeten heer / mevrouw:

 Ik ben Dr, Peter Ibrahim van particuliere lening bedrijf UK CREDIT LTD
lening, gevestigd in het Verenigd Koninkrijk.
Wij bieden alle soorten van leningen aan particulieren en bedrijven, 
Maak

jezelf financieel
stabiel door het verkrijgen van een lening van UK CREDIT LTD lening 3%
-tarief zo kort en
Langlopende leningen, zakelijke leningen, huiseigenaar leningen.
autoleningen enz.

 Vul hieronder als u geïnteresseerd bent in de lening van de lening
aanvraagformulier,

* Naam:
* Geslacht:
* Land / Adres:
* Bedrag dat nodig is:
* Maandinkomen Level
* Duur van de lening:
* Het doel van de lening:
* Telefoon:
* Geboortedatum

Neem contact met ons op via e-mail ukcreditltdlo...@gmail.com

Bedankt en vriendelijke groeten.

Dr, Peter Ibrahim.
--
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: [GIT PULL] Samsung fixes for 4.8

[Sylwester Nawrocki]

On 10/21/2016 02:26 PM, Mauro Carvalho Chehab wrote:
>> Sylwester Nawrocki (1):
>> >   exynos4-is: Clear I2C_ISP adapter's power.ignore_children flag
>
> This patch didn't apply fine. Could you please rebase it?
> 
> Applying patch 
> patches/0002-exynos4-is-Clear-I2C_ISP-adapter-s-power.ignore_chil.patch
> patching file drivers/media/platform/exynos4-is/fimc-is-i2c.c
> Hunk #1 NOT MERGED at 74-99, already applied at 101-104, already applied at 
> 111.

It seems no further actions are needed since the patch is somehow already 
applied in Linus' tree:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/media/platform/exynos4-is/fimc-is-i2c.c?id=056c61eb0da4d7181fc7072567dc1931cb0e1cbb

--
Regards, 
Sylwester
--
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 v5 3/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

[Mauro Carvalho Chehab]

Em Fri, 2 Sep 2016 20:19:54 +0800
Tiffany Lin  escreveu:

> Add v4l2 layer decoder driver for MT8173
> 
> Signed-off-by: Tiffany Lin 

> +int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> +{
> + int ret = 0;
> +
> + switch (fourcc) {
> + case V4L2_PIX_FMT_H264:
> + case V4L2_PIX_FMT_VP8:
> + default:
> + return -EINVAL;
> + }

Did you ever test this driver? The above code will *always* return
-EINVAL, with will cause vidioc_vdec_s_fmt() to always fail!

I suspect that what you wanted to do, instead, is:

switch (fourcc) {
case V4L2_PIX_FMT_H264:
case V4L2_PIX_FMT_VP8:
break;
default:
return -EINVAL;

Btw, this patch series has also several issues that were pointed by
checkpatch. Please *always* run checkpatch when submitting your work.

You should take a look at the Kernel documentation about how to
submit patches, at:
https://mchehab.fedorapeople.org/kernel_docs/process/index.html

PS.: this time, I fixed the checkpatch issues for you. So, let me know
if the patch below is OK, and I'll merge it at media upstream,
assuming that the other patches in this series are ok.

-- 
Thanks,
Mauro

[PATCH] mtk-vcodec: fix some smatch warnings

Fix this bug:
drivers/media/platform/mtk-vcodec/vdec_drv_if.c:38 vdec_if_init() info: 
ignoring unreachable code.

With is indeed a real problem that prevents the driver to work!

While here, also remove an used var, as reported by smatch:

drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 
'mtk_vcodec_init_dec_pm':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:29:17: warning: 
variable 'dev' set but not used [-Wunused-but-set-variable]
  struct device *dev;
 ^~~

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 18182f5676d8..79ca03ac449c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -26,14 +26,12 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
 {
struct device_node *node;
struct platform_device *pdev;
-   struct device *dev;
struct mtk_vcodec_pm *pm;
int ret = 0;
 
pdev = mtkdev->plat_dev;
pm = >pm;
pm->mtkdev = mtkdev;
-   dev = >dev;
node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
if (!node) {
mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
diff --git a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
index 3cb04ef45144..9813b2ffd5fa 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
@@ -31,6 +31,7 @@ int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int 
fourcc)
switch (fourcc) {
case V4L2_PIX_FMT_H264:
case V4L2_PIX_FMT_VP8:
+   break;
default:
return -EINVAL;
}


--
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: [GIT PULL] Samsung fixes for 4.8

[Mauro Carvalho Chehab]

Em Fri, 16 Sep 2016 15:33:33 +0200
Sylwester Nawrocki  escreveu:

> Hi Mauro,
> 
> The following changes since commit 7892a1f64a447b6f65fe288863b7c26d81d3:
> 
>   [media] rcar-fcp: Make sure rcar_fcp_enable() returns 0 on success 
> (2016-09-15 09:02:16 -0300)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/snawrocki/samsung.git for-v4.9/media/fixes
> 
> for you to fetch changes up to 8beaa9d0595aa2ae1f63be364c80189e53cbfe15:
> 
>   exynos4-is: Clear I2C_ISP adapter's power.ignore_children flag (2016-09-16 
> 15:25:55 +0200)
> 
> 
> Marek Szyprowski (1):
>   s5p-mfc: fix failure path of s5p_mfc_alloc_memdev()
> 
> Sylwester Nawrocki (1):
>   exynos4-is: Clear I2C_ISP adapter's power.ignore_children flag

This patch didn't apply fine. Could you please rebase it?

Applying patch 
patches/0002-exynos4-is-Clear-I2C_ISP-adapter-s-power.ignore_chil.patch
patching file drivers/media/platform/exynos4-is/fimc-is-i2c.c
Hunk #1 NOT MERGED at 74-99, already applied at 101-104, already applied at 111.
Applied patch 
patches/0002-exynos4-is-Clear-I2C_ISP-adapter-s-power.ignore_chil.patch 
(forced; needs refresh)

Thanks,
Mauro
--
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] [media] c8sectpfe: Remove clk_disable_unprepare hacks

[Patrice Chotard]

On 10/21/2016 10:55 AM, Peter Griffin wrote:
> Now that CLK_PROC_STFE is defined as a critical clock in
> DT, we can remove the commented clk_disable_unprepare from
> the c8sectpfe driver. This means we now have balanced
> clk*enable/disable calls in the driver, but on STiH407
> family the clock in reality will never actually be disabled.
> 
> This is due to a HW bug where once the IP has been configured
> and the SLIM core is running, disabling the clock causes a
> unrecoverable bus lockup.
> 
> Signed-off-by: Peter Griffin 
> ---
>  drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
> b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> index 30c148b..79d793b 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> @@ -888,8 +888,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
>   return 0;
>  
>  err_clk_disable:
> - /* TODO uncomment when upstream has taken a reference on this clk */
> - /*clk_disable_unprepare(fei->c8sectpfeclk);*/
> + clk_disable_unprepare(fei->c8sectpfeclk);
>   return ret;
>  }
>  
> @@ -924,11 +923,8 @@ static int c8sectpfe_remove(struct platform_device *pdev)
>   if (readl(fei->io + SYS_OTHER_CLKEN))
>   writel(0, fei->io + SYS_OTHER_CLKEN);
>  
> - /* TODO uncomment when upstream has taken a reference on this clk */
> - /*
>   if (fei->c8sectpfeclk)
>   clk_disable_unprepare(fei->c8sectpfeclk);
> - */
>  
>   return 0;
>  }
> 

Acked-by: Patrice Chotard 

--
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 11/25] [media] dvb-core: use pr_foo() instead of printk()

[Mauro Carvalho Chehab]

Em Fri, 14 Oct 2016 20:22:40 +0200
SF Markus Elfring  escreveu:

> > diff --git a/drivers/media/dvb-core/dmxdev.c 
> > b/drivers/media/dvb-core/dmxdev.c
> > index 7b67e1dd97fd..1e96a6f1b6f0 100644
> > --- a/drivers/media/dvb-core/dmxdev.c
> > +++ b/drivers/media/dvb-core/dmxdev.c
> > @@ -20,6 +20,8 @@
> >   *
> >   */
> >  
> > +#define pr_fmt(fmt) "dmxdev: " fmt
> > +
> >  #include 
> >  #include 
> >  #include   
> 
> How do you think to use an approach like the following there?
> 
> 
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> 
> 
>or eventually
> 
> 
> +#define MY_LOG_PREFIX KBUILD_MODNAME ": "
> +#define pr_fmt(fmt) MY_LOG_PREFIX fmt

we use a lot KBUILD_MODNAME on driver's pr_fmt() macros.

However, in this specific case, it is not a good idea, as this patch
is touching at the DVB core, with is composed by several different
and almost independent parts. So, we want to know what part
of the DVB core is producing such messages.

Regards,
Mauro
--
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 54/58] i2c: don't break long lines

[Mauro Carvalho Chehab]

Em Thu, 20 Oct 2016 13:46:08 +0300
Laurent Pinchart  escreveu:

> 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.

I know, but visually, it looked better to make the same indentation
as on the frequency print below.

> 
> > -   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) {
> > 

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

[Mauro Carvalho Chehab]

Em Thu, 20 Oct 2016 14:06:39 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.

Thanks for review.

> > +   uvc_warn_once(stream->dev, UVC_WARN_PROBE_DEF,
> > + "UVC non compliance - GET_DEF(PROBE) not   
> supported. Enabling
> > workaround.\n"); ret = -EIO;


Please fix your emailer, as it is word-wrapping long lines, making
really difficult to distinguish your comments from the patch itself.

It follows the patch with your comments addressed.

Thanks,
Mauro

-

[PATCH] uvc: don't break long lines

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 

diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index c2ee6e39fd0c..f3c7acfed635 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -960,8 +960,7 @@ static int uvc_ctrl_populate_cache(struct uvc_video_chain 
*chain,
 * resolution value to zero.
 */
uvc_warn_once(chain->dev, UVC_WARN_XU_GET_RES,
- "UVC non compliance - GET_RES failed on "
- "an XU control. Enabling workaround.\n");
+ "UVC non compliance - GET_RES failed on 
an XU control. Enabling workaround.\n");
memset(uvc_ctrl_data(ctrl, UVC_CTRL_DATA_RES), 0,
   ctrl->info.size);
}
@@ -1680,8 +1679,8 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
 
uvc_ctrl_fixup_xu_info(dev, ctrl, info);
 
-   uvc_trace(UVC_TRACE_CONTROL, "XU control %pUl/%u queried: len %u, "
- "flags { get %u set %u auto %u }.\n",
+   uvc_trace(UVC_TRACE_CONTROL,
+ "XU control %pUl/%u queried: len %u, flags { get %u set %u 
auto %u }.\n",
  info->entity, info->selector, info->size,
  (info->flags & UVC_CTRL_FLAG_GET_CUR) ? 1 : 0,
  (info->flags & UVC_CTRL_FLAG_SET_CUR) ? 1 : 0,
@@ -1710,9 +1709,10 @@ 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,
- info.selector, dev->udev->devpath, ctrl->entity->id);
+   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);
 
return ret;
 }
@@ -1904,9 +1904,10 @@ 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,
-   dev->udev->devpath, ctrl->entity->id);
+   

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

[Sakari Ailus]

Hi Thierry,

On Fri, Oct 21, 2016 at 10:53:22AM +0200, Thierry Escande wrote:
> #define VB2_DMA_DIR_CAPTURE(d) \
>   ((d) == DMA_FROM_DEVICE || (d) == DMA_BIDIRECTIONAL)

That looks good to me.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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] [media] c8sectpfe: Remove clk_disable_unprepare hacks

[Peter Griffin]

Now that CLK_PROC_STFE is defined as a critical clock in
DT, we can remove the commented clk_disable_unprepare from
the c8sectpfe driver. This means we now have balanced
clk*enable/disable calls in the driver, but on STiH407
family the clock in reality will never actually be disabled.

This is due to a HW bug where once the IP has been configured
and the SLIM core is running, disabling the clock causes a
unrecoverable bus lockup.

Signed-off-by: Peter Griffin 
---
 drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
index 30c148b..79d793b 100644
--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -888,8 +888,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
return 0;
 
 err_clk_disable:
-   /* TODO uncomment when upstream has taken a reference on this clk */
-   /*clk_disable_unprepare(fei->c8sectpfeclk);*/
+   clk_disable_unprepare(fei->c8sectpfeclk);
return ret;
 }
 
@@ -924,11 +923,8 @@ static int c8sectpfe_remove(struct platform_device *pdev)
if (readl(fei->io + SYS_OTHER_CLKEN))
writel(0, fei->io + SYS_OTHER_CLKEN);
 
-   /* TODO uncomment when upstream has taken a reference on this clk */
-   /*
if (fei->c8sectpfeclk)
clk_disable_unprepare(fei->c8sectpfeclk);
-   */
 
return 0;
 }
-- 
1.9.1

--
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 v3] [media] vb2: Add support for capture_dma_bidirectional queue flag

[Thierry Escande]

Hi Sakari,

On 21/10/2016 09:48, Sakari Ailus wrote:

Hi Thierry,

On Fri, Oct 21, 2016 at 09:25:05AM +0200, Thierry Escande wrote:

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 



Please also check where dma_dir is being used especially in memory type
implementation. There are several comparisons to DMA_FROM_DEVICE which will
have a different result if DMA_BIDIRECTIONAL is used instead.

Nice catch, thanks.

How about a macro like this:

#define VB2_DMA_DIR_CAPTURE(d) \
((d) == DMA_FROM_DEVICE || (d) == DMA_BIDIRECTIONAL)

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

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

[Sakari Ailus]

Hi Thierry,

On Fri, Oct 21, 2016 at 09:25:05AM +0200, Thierry Escande wrote:
> 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 
> 
> 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);

Please also check where dma_dir is being used especially in memory type
implementation. There are several comparisons to DMA_FROM_DEVICE which will
have a different result if DMA_BIDIRECTIONAL is used instead.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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

[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

Changes since v3:
- Fixed typos in include/media/videobuf2-core.h

 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..a6cfdfb 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
 };
 
+/*
+ * Returns the corresponding DMA direction given the vb2_queue type (capture or
+ * output). Returns DMA_BIDIRECTIONAL 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 v3] [media] vb2: Add support for capture_dma_bidirectional queue flag

[Sakari Ailus]

Hi Thierry,

On Thu, Oct 20, 2016 at 10:56:04AM +0200, Thierry Escande wrote:
> 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

DMA_BIDIRECTIONAL

With that fixed,

Acked-by: Sakari Ailus 

> + * 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

-- 
Sakari Ailus
e-mail: