[PATCH] drivers/staging/media: atomisp: Removing redundant information from dev_err
Removing hardcoded function name as code is already using __func__ Signed-off-by: Pushkar Jambhlekar--- drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c index d1a609d2..a51a27b 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c @@ -64,7 +64,7 @@ struct hmm_buffer_object *__bo_alloc(struct kmem_cache *bo_cache) bo = kmem_cache_alloc(bo_cache, GFP_KERNEL); if (!bo) - dev_err(atomisp_dev, "%s: __bo_alloc failed!\n", __func__); + dev_err(atomisp_dev, "%s: failed!\n", __func__); return bo; } -- 2.7.4
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Mar 24 05:00:19 CET 2017 media-tree git hash:8bc4793bd083158bd266157e85ea4762577a5be6 media_build git hash: bc4c2a205c087c8deff3cd14ed663c4767dd2016 v4l-utils git hash: 5fe0692261996876dceedbd47f254691371d4c78 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-i686: OK linux-4.10.1-i686: OK linux-4.11-rc1-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9-x86_64: WARNINGS linux-4.10.1-x86_64: WARNINGS linux-4.11-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH v2] media: platform: rcar_imr: add IMR-LSX3 support
On Thu, Mar 16, 2017 at 09:59:50PM +0300, Sergei Shtylyov wrote: > Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found > only in the R-Car V2H (R8A7792) SoC. It differs from IMR-LX4 in that it > supports only planar video formats but can use the video capture data for > the textures. > > Signed-off-by: Sergei Shtylyov> > --- > This patch is against the 'media_tree.git' repo's 'master' branch plus the > latest version of the Renesas IMR driver... > > Changes in version 2: > - renamed *enum* 'imr_gen' to 'imr_type' and the *struct* field of this type > from 'gen' to 'type'; > - rename *struct* 'imr_type' to 'imr_info' and the fields/variables of this > type > from 'type' to 'info'; > - added comments to IMR-LX4 only CMRCR2 bits; > - added IMR type check to the WTS instruction writing to CMRCCR2. > > Documentation/devicetree/bindings/media/rcar_imr.txt | 11 + Acked-by: Rob Herring > drivers/media/platform/rcar_imr.c| 106 > +++ > 2 files changed, 97 insertions(+), 20 deletions(-)
JVC camera and Hauppauge PVR-150 framegrabber.
With a manual setting of the device path and ID, the V4L2 Test Bench produced this image from a JVC TK-1070U camera on a microscope. http://easthope.ca/JVCtoPVR150screen.jpg Setting the device in the Test Bench each time it is opened becomes tedious and no /etc/*v4l* exists. Can the default configuration be adjusted permanently without recompiling? How? Although too dark, the image from the microscope slide is faintly visible. The upper half of the image is on the bottom of the screen and the lower half is at the top. On a VCR I might try adjusting vertical sync. Is there an equivalent in the Test Bench? Thanks, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca
[PATCH] [media] vb2: Fix queue_setup() callback description
Correct meaning of the last sensence by swapping it with previous. Fix two small typos. Signed-off-by: Anton Leontiev--- include/media/videobuf2-core.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index ac5898a55fd9..cb97c224be73 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -305,16 +305,16 @@ struct vb2_buffer { * buffer in \*num_planes, the size of each plane should be * set in the sizes\[\] array and optional per-plane * allocator specific device in the alloc_devs\[\] array. - * When called from VIDIOC_REQBUFS,() \*num_planes == 0, + * When called from VIDIOC_REQBUFS(), \*num_planes == 0, * the driver has to use the currently configured format to * determine the plane sizes and \*num_buffers is the total * number of buffers that are being allocated. When called - * from VIDIOC_CREATE_BUFS,() \*num_planes != 0 and it + * from VIDIOC_CREATE_BUFS(), \*num_planes != 0 and it * describes the requested number of planes and sizes\[\] - * contains the requested plane sizes. If either - * \*num_planes or the requested sizes are invalid callback - * must return %-EINVAL. In this case \*num_buffers are - * being allocated additionally to q->num_buffers. + * contains the requested plane sizes. In this case + * \*num_buffers are being allocated additionally to + * q->num_buffers. If either \*num_planes or the requested + * sizes are invalid callback must return %-EINVAL. * @wait_prepare: release any locks taken while calling vb2 functions; * it is called before an ioctl needs to wait for a new * buffer to arrive; required to avoid a deadlock in -- 2.12.0
Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors
Am 23.03.2017 um 13:56 schrieb Mauro Carvalho Chehab: Em Thu, 23 Mar 2017 13:01:32 +0100 Frank Schäferescreveu: Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab: Em Sun, 19 Feb 2017 19:29:18 +0100 Frank Schäfer escreveu: Use i2c_smbus_read_word_data() instead of i2c_master_send() and i2c_master_recv() for reading the ID of Micorn sensors. Bytes need to be swapped afterwards, because i2c_smbus_read_word_data() assumes that the received bytes are little-endian byte order (as specified by smbus), while Micron sensors with 16 bit register width use big endian byte order. Signed-off-by: Frank Schäfer --- drivers/media/usb/em28xx/em28xx-camera.c | 28 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-camera.c b/drivers/media/usb/em28xx/em28xx-camera.c index 7b4129ab1cf9..4839479624e7 100644 --- a/drivers/media/usb/em28xx/em28xx-camera.c +++ b/drivers/media/usb/em28xx/em28xx-camera.c @@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev) { int ret, i; char *name; - u8 reg; - __be16 id_be; u16 id; struct i2c_client *client = >i2c_client[dev->def_i2c_bus]; @@ -115,10 +113,8 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev) dev->em28xx_sensor = EM28XX_NOSENSOR; for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) { client->addr = micron_sensor_addrs[i]; - /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */ /* Read chip ID from register 0x00 */ - reg = 0x00; - ret = i2c_master_send(client, , 1); + ret = i2c_smbus_read_word_data(client, 0x00); /* assumes LE */ if (ret < 0) { if (ret != -ENXIO) dev_err(>intf->dev, @@ -126,24 +122,9 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev) client->addr << 1, ret); continue; } - ret = i2c_master_recv(client, (u8 *)_be, 2); - if (ret < 0) { - dev_err(>intf->dev, - "couldn't read from i2c device 0x%02x: error %i\n", - client->addr << 1, ret); - continue; - } - id = be16_to_cpu(id_be); + id = swab16(ret); /* LE -> BE */ That's wrong! You can't assume that CPU is BE, as some archs use LE. You should, instead, call le16_to_cpu(), to be sure that it will be doing the right thing. Something like: id = le16_to_cpu((__le16)ret); SMBus read/write word transfers are always LE (see SMBus spec section 6.5.5), which is also what i2c_smbus_xfer_emulated() assumes: http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485 I got that part, but, if the CPU is also LE, doing swab16() is wrong. It should swap it *only* if the CPU is BE. No, it should always be swapped, because the bytes are always transfered in the wrong order. The cpu endianess doesn't matter, (0x12 << 8) | 0x34 is always 0x1234. Regards, Frank le16_to_cpu() should do the right thing, e. g. swap for BE CPUs or not swap otherwise. Thanks, Mauro
Re: [PATCH] staging: media: atomisp: fix build error
On Thu, 2017-03-23 at 21:12 +0800, Geliang Tang wrote: > Fix the following build error: > > CC drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o > drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: > error: excess elements in array initializer [-Werror] > "i", /* ion */ > ^~~ NAK I've sent a patch to sort this out properly we shouldn't be using string arrays for single char values to start with... Alan
Re: [PATCH] staging: media: atomisp: use kvmalloc and kvfree
On Thu, Mar 23, 2017 at 09:12:39PM +0800, Geliang Tang wrote: > Use kvmalloc() and kvfree() instead of open-coding. These functions are not in Linus's tree, so I can't apply this patch without breaking things :( thanks, greg k-h
Re: [PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int
On Wed, Mar 22, 2017 at 01:33:39PM +1100, Eddie Youseph wrote: > Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Signed-off-by: Eddie Youseph> --- > Changes in v2: > - Added changelog Did you actually build this change? Please do so... thanks, greg k-h
Re: Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check
Hi! > > Plus I have played with v4l-utils, and managed to implement autofocus > > and autoexposure -- it was easier than expected. I believe you > > mentioned you had some patches to automatically initialize the > > pipeline. Do you and can I have them? > > It was an early prototype and it wasn't really functional yet. > > Given a video node, it can find possible pipelines to the image sources with > common formats. I.e. the ccdc -> rsz path is not available for raw > cameras. > C (especially without helper libraries) wasn't particularly suitable for the > task, the data structures I had didn't end up too nice. What would also be > necessary is to associate library or application specific data to entities, > this could be as simple as key-value pairs with both key and value being > pointers. Could I get a copy, anyway? Need not be perfect, but starting point would be welcome. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH] staging: media: atomisp: use kvmalloc and kvfree
Use kvmalloc() and kvfree() instead of open-coding. Signed-off-by: Geliang Tang--- drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c index 94bc793..c7b9320 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c @@ -90,10 +90,7 @@ union host { void *atomisp_kernel_malloc(size_t bytes) { /* vmalloc() is preferable if allocating more than 1 page */ - if (bytes > PAGE_SIZE) - return vmalloc(bytes); - - return kmalloc(bytes, GFP_KERNEL); + return kvmalloc(bytes, GFP_KERNEL); } /* @@ -118,10 +115,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool zero_mem) void atomisp_kernel_free(void *ptr) { /* Verify if buffer was allocated by vmalloc() or kmalloc() */ - if (is_vmalloc_addr(ptr)) - vfree(ptr); - else - kfree(ptr); + kvfree(ptr); } /* -- 2.9.3
[PATCH] staging: media: atomisp: fix build error
Fix the following build error: CC drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: error: excess elements in array initializer [-Werror] "i", /* ion */ ^~~ drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: note: (near initialization for ‘hmm_bo_type_strings’) cc1: all warnings being treated as errors scripts/Makefile.build:294: recipe for target 'drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o' failed Signed-off-by: Geliang Tang--- drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c index a362b49..e78f02f 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c @@ -49,7 +49,9 @@ const char *hmm_bo_type_strings[HMM_BO_LAST] = { "p", /* private */ "s", /* shared */ "u", /* user */ +#ifdef CONFIG_ION "i", /* ion */ +#endif }; static ssize_t bo_show(struct device *dev, struct device_attribute *attr, -- 2.9.3
Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors
Em Thu, 23 Mar 2017 13:01:32 +0100 Frank Schäferescreveu: > Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab: > > Em Sun, 19 Feb 2017 19:29:18 +0100 > > Frank Schäfer escreveu: > > > >> Use i2c_smbus_read_word_data() instead of i2c_master_send() and > >> i2c_master_recv() for reading the ID of Micorn sensors. > >> Bytes need to be swapped afterwards, because i2c_smbus_read_word_data() > >> assumes that the received bytes are little-endian byte order (as specified > >> by smbus), while Micron sensors with 16 bit register width use big endian > >> byte order. > >> > >> Signed-off-by: Frank Schäfer > >> --- > >> drivers/media/usb/em28xx/em28xx-camera.c | 28 > >> > >> 1 file changed, 4 insertions(+), 24 deletions(-) > >> > >> diff --git a/drivers/media/usb/em28xx/em28xx-camera.c > >> b/drivers/media/usb/em28xx/em28xx-camera.c > >> index 7b4129ab1cf9..4839479624e7 100644 > >> --- a/drivers/media/usb/em28xx/em28xx-camera.c > >> +++ b/drivers/media/usb/em28xx/em28xx-camera.c > >> @@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct em28xx > >> *dev) > >> { > >>int ret, i; > >>char *name; > >> - u8 reg; > >> - __be16 id_be; > >>u16 id; > >> > >>struct i2c_client *client = >i2c_client[dev->def_i2c_bus]; > >> @@ -115,10 +113,8 @@ static int em28xx_probe_sensor_micron(struct em28xx > >> *dev) > >>dev->em28xx_sensor = EM28XX_NOSENSOR; > >>for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) { > >>client->addr = micron_sensor_addrs[i]; > >> - /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */ > >>/* Read chip ID from register 0x00 */ > >> - reg = 0x00; > >> - ret = i2c_master_send(client, , 1); > >> + ret = i2c_smbus_read_word_data(client, 0x00); /* assumes LE */ > >>if (ret < 0) { > >>if (ret != -ENXIO) > >>dev_err(>intf->dev, > >> @@ -126,24 +122,9 @@ static int em28xx_probe_sensor_micron(struct em28xx > >> *dev) > >> client->addr << 1, ret); > >>continue; > >>} > >> - ret = i2c_master_recv(client, (u8 *)_be, 2); > >> - if (ret < 0) { > >> - dev_err(>intf->dev, > >> - "couldn't read from i2c device 0x%02x: error > >> %i\n", > >> - client->addr << 1, ret); > >> - continue; > >> - } > >> - id = be16_to_cpu(id_be); > >> + id = swab16(ret); /* LE -> BE */ > > That's wrong! You can't assume that CPU is BE, as some archs use LE. > > > > You should, instead, call le16_to_cpu(), to be sure that it will be > > doing the right thing. > > > > Something like: > > > > id = le16_to_cpu((__le16)ret); > > SMBus read/write word transfers are always LE (see SMBus spec section > 6.5.5), > which is also what i2c_smbus_xfer_emulated() assumes: > http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485 I got that part, but, if the CPU is also LE, doing swab16() is wrong. It should swap it *only* if the CPU is BE. le16_to_cpu() should do the right thing, e. g. swap for BE CPUs or not swap otherwise. Thanks, Mauro
Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors
Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab: Em Sun, 19 Feb 2017 19:29:18 +0100 Frank Schäferescreveu: Use i2c_smbus_read_word_data() instead of i2c_master_send() and i2c_master_recv() for reading the ID of Micorn sensors. Bytes need to be swapped afterwards, because i2c_smbus_read_word_data() assumes that the received bytes are little-endian byte order (as specified by smbus), while Micron sensors with 16 bit register width use big endian byte order. Signed-off-by: Frank Schäfer --- drivers/media/usb/em28xx/em28xx-camera.c | 28 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-camera.c b/drivers/media/usb/em28xx/em28xx-camera.c index 7b4129ab1cf9..4839479624e7 100644 --- a/drivers/media/usb/em28xx/em28xx-camera.c +++ b/drivers/media/usb/em28xx/em28xx-camera.c @@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev) { int ret, i; char *name; - u8 reg; - __be16 id_be; u16 id; struct i2c_client *client = >i2c_client[dev->def_i2c_bus]; @@ -115,10 +113,8 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev) dev->em28xx_sensor = EM28XX_NOSENSOR; for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) { client->addr = micron_sensor_addrs[i]; - /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */ /* Read chip ID from register 0x00 */ - reg = 0x00; - ret = i2c_master_send(client, , 1); + ret = i2c_smbus_read_word_data(client, 0x00); /* assumes LE */ if (ret < 0) { if (ret != -ENXIO) dev_err(>intf->dev, @@ -126,24 +122,9 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev) client->addr << 1, ret); continue; } - ret = i2c_master_recv(client, (u8 *)_be, 2); - if (ret < 0) { - dev_err(>intf->dev, - "couldn't read from i2c device 0x%02x: error %i\n", - client->addr << 1, ret); - continue; - } - id = be16_to_cpu(id_be); + id = swab16(ret); /* LE -> BE */ That's wrong! You can't assume that CPU is BE, as some archs use LE. You should, instead, call le16_to_cpu(), to be sure that it will be doing the right thing. Something like: id = le16_to_cpu((__le16)ret); SMBus read/write word transfers are always LE (see SMBus spec section 6.5.5), which is also what i2c_smbus_xfer_emulated() assumes: http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485 Regards, Frank Regards, Thanks, Mauro
[PATCH] [media] coda: remove redundant call to v4l2_m2m_get_vq
From: Colin Ian KingThe call to v4ls_m2m_get_vq is only used to get the return value which is not being used, so it appears to be redundant and can be removed. Detected with CoverityScan, CID#1420674 ("Useless call") Signed-off-by: Colin Ian King --- drivers/media/platform/coda/coda-common.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index 800d2477f1a0..95e4648f18e6 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -817,8 +817,6 @@ static int coda_qbuf(struct file *file, void *priv, static bool coda_buf_is_end_of_stream(struct coda_ctx *ctx, struct vb2_v4l2_buffer *buf) { - v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT); - return ((ctx->bit_stream_param & CODA_BIT_STREAM_END_FLAG) && (buf->sequence == (ctx->qsequence - 1))); } -- 2.11.0
Re: [PATCH 0/3] staging: media: Replace a bit shift.
Hi, Le 22/03/2017 à 05:26, Arushi Singhal a écrit : Replace a bit shift by a use of BIT in media driver. Arushi Singhal (3): staging: media: Replace a bit shift by a use of BIT. staging: media: davinci_vpfe: Replace a bit shift by a use of BIT. staging: media: omap4iss: Replace a bit shift by a use of BIT. .../media/atomisp/pci/atomisp2/atomisp_cmd.c | 12 +- .../atomisp/pci/atomisp2/atomisp_compat_css20.c| 6 ++--- .../media/atomisp/pci/atomisp2/atomisp_drvfs.c | 6 ++--- .../media/atomisp/pci/atomisp2/atomisp_v4l2.c | 18 +++ .../media/atomisp/pci/atomisp2/hmm/hmm_bo.c| 2 +- drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 2 +- drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 2 +- drivers/staging/media/davinci_vpfe/dm365_isif.c| 26 +++--- drivers/staging/media/davinci_vpfe/dm365_resizer.c | 6 ++--- drivers/staging/media/omap4iss/iss_csi2.c | 2 +- drivers/staging/media/omap4iss/iss_ipipe.c | 2 +- drivers/staging/media/omap4iss/iss_ipipeif.c | 2 +- drivers/staging/media/omap4iss/iss_resizer.c | 2 +- 13 files changed, 44 insertions(+), 44 deletions(-) Most of these replacements add redundant parentheses around the BIT macro. IMHO this makes the code less readable. So I suggest (BIT(c)) -> BIT(c). Cheers, Chris
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Mar 23 05:00:15 CET 2017 media-tree git hash:db0f4691d9749d5dd758b8636290cec8fd88aa26 media_build git hash: bc4c2a205c087c8deff3cd14ed663c4767dd2016 v4l-utils git hash: 5fe0692261996876dceedbd47f254691371d4c78 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-i686: OK linux-4.10.1-i686: OK linux-4.11-rc1-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9-x86_64: WARNINGS linux-4.10.1-x86_64: WARNINGS linux-4.11-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check
Hi Pavel, On Thu, Mar 23, 2017 at 12:46:51AM +0100, Pavel Machek wrote: > On Tue 2017-02-28 16:16:21, Sakari Ailus wrote: > > On Tue, Feb 28, 2017 at 03:09:21PM +0100, Pavel Machek wrote: > > > Can I get you to apply this one? :-). > > > > Let me try to understand again what does that change actually do. I'll find > > the time during the rest of this week. > > > > I'm starting to think we need a test suite for the PLL calculator... > > Any update here or on the other patch? We are quite close to working > camera now... I've been working on PLL test cases. The PLL calculator really requires that to be able to test any changes made to it. > > Plus I have played with v4l-utils, and managed to implement autofocus > and autoexposure -- it was easier than expected. I believe you > mentioned you had some patches to automatically initialize the > pipeline. Do you and can I have them? It was an early prototype and it wasn't really functional yet. Given a video node, it can find possible pipelines to the image sources with common formats. I.e. the ccdc -> rsz path is not available for raw cameras. C (especially without helper libraries) wasn't particularly suitable for the task, the data structures I had didn't end up too nice. What would also be necessary is to associate library or application specific data to entities, this could be as simple as key-value pairs with both key and value being pointers. > > Last thing.. Is someone able to compute new modes for et8ek8? I > believe smaller than 640x480 mode would be useful for video streaming, > and I still can't get 5MPix mode to work; understanding what goes on > there would be useful. Unfortunately the et8ek8 does not conform to a standard such as SMIA. :-( I'm not sure the datasheet provides enough information to come up with new mode definitions. Perhaps with some experimentation it could be possible. There are a few additional embedded documents in it, those are worth checking out. LibreOffice can open them AFAIR. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk