Re: OV7670 driver for Mini2440
Hi Sylwester, Can you guide me on how to write a patch to interface ov7670 with mini2440? Thnaks, Anvesh On 20-Mar-2013, at 1:57 AM, Sylwester Nawrocki wrote: > Hi Anvesh, > > On 03/19/2013 03:41 PM, Anvesh Manne wrote: >> Hello, > > Cc linux-media mailing list. > >> I am trying to get the OV7670 module to work with Mini2440. Despite my >> best efforts, i am ending with the following image. > > OK, what kernel version and drivers are you currently using. Is it some > custom BSP or the Pengutronix's one ? > > The image looks like there is a mismatch in configured pixel format at > the sensor and the s3c2440 CAMIF device. > >> Can you guide me on how to install your driver from >> (http://git.linuxtv.org/snawrocki/media.git/commit/caa3b9af18f344ef9b21377f7dc4631bd6a99d19) >> along with the driver from http://patchwork.linuxtv.org/patch/563/ ? > > There is already ov7670 sensor driver in the mainline kernel that > looks much better then the one from the link above. With a small > patch we should be able to use it with Mini2440. > > If possible, I suggest you to use latest kernel that can be found here: > http://git.linuxtv.org/media_tree.git > >> I have directly interfaced OV7670 to the Camera port of Mini2440. >> >> Thanks for you help. >> >> Anvesh > > -- > > 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: [GIT PULL FOR v3.11]
Hi Hans, On Thu, Jul 25, 2013 at 6:55 PM, Hans Verkuil wrote: > Hi Prabhakar, > > On Thu 11 July 2013 19:25:15 Prabhakar Lad wrote: >> Hi Hans, >> >> On Thu, Jun 27, 2013 at 12:25 PM, Hans Verkuil wrote: >> > (Same as my previous git pull message, but with more cleanup patches and >> [snip] >> > Lad, Prabhakar (9): >> > media: i2c: ths8200: support asynchronous probing >> > media: i2c: ths8200: add OF support >> > media: i2c: adv7343: add support for asynchronous probing >> > media: i2c: tvp7002: add support for asynchronous probing >> > media: i2c: tvp7002: remove manual setting of subdev name >> > media: i2c: tvp514x: remove manual setting of subdev name >> > media: i2c: tvp514x: add support for asynchronous probing >> > media: davinci: vpif: capture: add V4L2-async support >> > media: davinci: vpif: display: add V4L2-async support >> > >> I see last two patches missing in Mauro's pull request for v3.11 and >> v3.11-rc1. > > I had to split up my pull request into fixes for 3.11 and new stuff for 3.12 > since the merge window was about to open at the time. > Ok no problem. > Your 'missing' patches are here: > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/for-v3.12 > Yeah I saw it lately. > In the next few days I'll try to process all remaining patches delegated to > me. Ok > If you have patches not yet delegated to me, or that are not in my for-v3.12 > branch, then let me know. > There are few patches, whose state is new do you want me to point them ? Regards, --Prabhakar Lad -- 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: occasional problems with Technotrend TT-connect CT3650+CI - additional logs
Hi, I took some logs with debug flags enabled: options dvb-usb debug=81 options dvb-usb-ttusb2 debug=1 debug_ci=1 After the "DVB CAM link initialization failed" I won't get more logs for a few hours. At some time the TV card recovers without any intervention. Do you have any ideas what is wrong here? thanks, Martin On Sat, 2013-06-29 at 21:57 +0200, Martin Maurer wrote: > Hi all, > > I use the card CT3650 with the CI slot together with Mythtv (USB Card > with integrated CI slot). Mostly this works fine, but every few > recordings of encrypted programs fail. The logs hint that there is some > problem with the CI initialization. Mythtv apparently doesn't correctly > detect that the recording failed, as the recording remains marked as > "Still recording" in the web-interface. The file size is 0 bytes. > After such a recording fails it usually happens, that the next recording > is fine again without any intervention by me. > > I already replaced the USB cable by another one to rule this out. Don't > want to replace the card unless I am sure that it is faulty. > > Some data: > I am using Ubuntu 12.04.2 LTS > uname -a: Linux ashanta 3.5.0-26-generic #42~precise1-Ubuntu SMP Mon Mar > 11 22:19:42 UTC 2013 i686 i686 i386 GNU/Linux > > --- > Today a recording failed at 10:06 AM: > > Dmesg output: > [Sat Jun 29 09:56:50 2013] dvb_ca adapter 0: DVB CAM detected and > initialised successfully > [Sat Jun 29 10:02:15 2013] dvb_ca adapter 0: DVB CAM link initialisation > failed :( > [Sat Jun 29 10:56:47 2013] dvb_ca adapter 0: DVB CAM detected and > initialised successfully > > Mythtv output: > see attachment > > lsmod: > see attachment > --- > > Other interesting dmesg messages: > [Thu Jun 27 18:39:22 2013] dvb_ca adapter 0: CAM tried to send a buffer > larger than the link buffer size (49087 > 128)! > ... > [Fri Jun 28 02:44:48 2013] dvb_ca adapter 0: Invalid PC card inserted :( > ... > [Sat Jun 29 11:13:01 2013] dvb_ca adapter 0: DVB CAM link initialisation > failed :( > ... > > Anything I can do provide further data? > In my opinion it would be interesting to discover such situations and > automatically retry without the client programs (as mythtv) noticing it. > > thanks, > Martin [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00e6 -> 0 0x4f [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00e8 -> 0 0x44 [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00ea -> 0 0x55 [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00ec -> 0 0x4c [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00ee -> 0 0x45 [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00f0 -> 0 0x00 [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00f2 -> 0 0x14 [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00f4 -> 0 0x00 [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 00f6 -> 0 0xff [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_write_attribute_mem 0 0x01fe 0x0f [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_read_attribute_mem 01fe -> 0 0x0f [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_write_cam_control 0 0x01 0x08 [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_set_video_port 0 0 [Thu Jul 25 20:13:36 2013] ttusb2: tt3650_ci_slot_reset 0 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem -> 0 0x1d [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0002 -> 0 0x04 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0004 -> 0 0x00 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0006 -> 0 0xdb [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0008 -> 0 0x08 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 000a -> 0 0xff [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 000c -> 0 0x1c [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 000e -> 0 0x03 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0010 -> 0 0x00 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0012 -> 0 0x08 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0014 -> 0 0xff [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0016 -> 0 0x15 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0018 -> 0 0x15 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 001a -> 0 0x05 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 001c -> 0 0x00 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 001e -> 0 0x53 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0020 -> 0 0x43 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0022 -> 0 0x4d [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0024 -> 0 0x00 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0026 -> 0 0x44 [Thu Jul 25 20:13:38 2013] ttusb2: tt3650_ci_read_attribute_mem 0028 -> 0 0x56
[PATCH v9] V4L2: soc_camera: Renesas R-Car VIN driver
From: Vladimir Barinov Add Renesas R-Car VIN (Video In) V4L2 driver. Based on the patch by Phil Edworthy . Signed-off-by: Vladimir Barinov [Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum chip_id' values, reordered rcar_vin_id_table[] entries, removed senseless parens from to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to the *if* statement and used 'bool' values instead of 0/1 where necessary, removed unused macros, done some reformatting and clarified some comments.] Signed-off-by: Sergei Shtylyov --- This patch is against the 'media_tree.git' repo. Changes since version 8: - made rcar_vin_setup() return *int*, replaced BUG() by dev_warn() and *return* -EINVAL and added *return* 0 at end of the function; - moved rcar_vin_setup() call in the buf_queue() method and started handling error returned by it; - added comments to clock_{start|stop}() methods; - fixed 'bits_per_sample' field for V4L2_PIX_FMT_NV16 format; - fixed line longer than 80 characters; - fixed dev_dbg() message in the set_fmt() method. Changes since version 7: - remove 'icd' field from 'struct rcar_vin_priv' in accordance with the commit f7f6ce2d09c86bd80ee11bd654a1ac1e8f5dfe13 ([media] soc-camera: move common code to soc_camera.c); - added mandatory clock_{start|stop}() methods in accordance with the commit a78fcc11264b824d9651b55abfeedd16d5cd8415 ([media] soc-camera: make .clock_ {start,stop} compulsory, .add / .remove optional). Changes since version 6: - sorted #include's alphabetically once again; - BUG() on invalid format in rcar_vin_setup(); - used 'icd->sizeimage' instead of frame size calculation; - moved WARN_ON() into the *if* condition and removed setting 'vb' to NULL in rcar_vin_remove_device(); - fixed 'packing' and 'layout' field values for 'fourcc' V4L2_PIX_FMT_NV16 in rcar_vin_formats[]; - made result handling logic more accurate in case subdevice does not support cropping; - fixed scaling capability for pass-through pixel formats; - resolved reject in the Makefile, refreshed the patch. Changes since version 5: - handled subdevice's inability to support cropping; - set the field format depending on a video standard. Changes since version 4: - added "select SOC_CAMERA_SCALE_CROP" to Kconfig entry; - added #include "soc_scale_crop.h", made use of the functions declared there instead of the analogous functions originally copied from the SH-Mobile CEU driver now that they have been placed in a module of their own, removing now unused private functions. Changes since version 3: - removed the driver's dependency on R-Car M1A/H1 SoCs from Kconfig; - made the driver aware of the differences between R-Car E1/M1/H1 SoCs by having different platform device IDs for different SoCs, introcduced 'enum chips_id' to be used as the 'driver_data' field of 'struct platform_device_id' and then copied to the 'chip' field of 'struct rcar_vin_priv'; - sorted #include's alphabetically, added a number of #includes ; - removed the 'data_through' field of the 'struct rcar_vin_priv' and the pass- through logic from set_fmt() method; - simplified is_continuous_transfer(), used it where applicable; - removed senseless parens from to_buf_list() macro; - removed the 'code' field from the 'struct rcar_vin_cam'; - largely rewrote the queue_setup() method; - removed 'input_is_yuv' variable from rcar_vin_setup(), made 'progressive' and 'output_is_yuv' variables 'bool', and made setting VnDMR.EXRGB bit only happen on R-Car E1/H1 there; - made use of ALIGN() macro in rcar_vin_setup() and rcar_vin_set_rect(); - fixed missing {} on one branch of the *if* statement in several places, added {} to the *if* statement where necessary; - stopped saving/restoring flags when grabbing/dropping a spinlock in the buf_queue() and buf_cleanup() methods; - made 'dsize' variable calculation depend on R-Car E1 in rcar_vin_set_rect() - fix the continuous capturing to stop when there is no buffer to be set into the VnMBm registers in rcar_vin_irq(); - replaced BUG_ON() with WARN_ON() and *return* in the remove() method, also replaced pm_runtime_put_sync() with pm_runtime_put() there; - removed size_dst() and calc_scale() as the calls to calc_scale() were also removed from the set_fmt() method; - removed the VnMC register value check from capture_restore(); - removed 'cfg' variable initializers from set_bus_param() method and rcar_vin_try_bus_param(); - added bus width check to rcar_vin_try_bus_param(); - removed V4L2_PIX_FMT_YUYV format from rcar_vin_formats[], initialize 'layout' field of every element in this table; - changed dev_err() call and *return* -EINVAL to dev_warn() and *return* 0 in the get_formats() method, - added rcar_vin_packing_supported() and started handling pass-through mode in the get_formats() method; - constified the parameters of is_smaller() and is_inside(); - redid the scaling logic so that it can't scale RGB32 data on R-Car E1 in the set_
cron job: media_tree daily build: WARNINGS
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 Jul 25 19:00:20 CEST 2013 git branch: test git hash: c859e6ef33ac0c9a5e9e934fe11a2232752b4e96 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: 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.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS 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: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK 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-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS 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: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK 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 apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS 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/media.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] [media] bt8xx: info leak in ca_get_slot_info()
On Thu, Jul 25, 2013 at 07:29:09PM +0200, walter harms wrote: > > > Am 25.07.2013 18:46, schrieb Dan Carpenter: > > p_ca_slot_info was allocated with kmalloc() so we need to clear it > > before passing it to the user. > > > > Signed-off-by: Dan Carpenter > > > > diff --git a/drivers/media/pci/bt8xx/dst_ca.c > > b/drivers/media/pci/bt8xx/dst_ca.c > > index 0e788fc..6b9dc3f 100644 > > --- a/drivers/media/pci/bt8xx/dst_ca.c > > +++ b/drivers/media/pci/bt8xx/dst_ca.c > > @@ -302,8 +302,11 @@ static int ca_get_slot_info(struct dst_state *state, > > struct ca_slot_info *p_ca_s > > p_ca_slot_info->flags = CA_CI_MODULE_READY; > > p_ca_slot_info->num = 1; > > p_ca_slot_info->type = CA_CI; > > - } else > > + } else { > > p_ca_slot_info->flags = 0; > > + p_ca_slot_info->num = 0; > > + p_ca_slot_info->type = 0; > > + } > > > > if (copy_to_user(arg, p_ca_slot_info, sizeof (struct ca_slot_info))) > > return -EFAULT; > > note: i have no clue how p_ca_slot_info looks like, > but to avoid information leaks via compiler padding etc. i could be more wise > to do a memset(p_ca_slot_info,0,sizeof (struct ca_slot_info)) > and then set the There is no compiler padding. My static checker looks for that. regards, dan carpenter -- 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] bt8xx: info leak in ca_get_slot_info()
Am 25.07.2013 18:46, schrieb Dan Carpenter: > p_ca_slot_info was allocated with kmalloc() so we need to clear it > before passing it to the user. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/media/pci/bt8xx/dst_ca.c > b/drivers/media/pci/bt8xx/dst_ca.c > index 0e788fc..6b9dc3f 100644 > --- a/drivers/media/pci/bt8xx/dst_ca.c > +++ b/drivers/media/pci/bt8xx/dst_ca.c > @@ -302,8 +302,11 @@ static int ca_get_slot_info(struct dst_state *state, > struct ca_slot_info *p_ca_s > p_ca_slot_info->flags = CA_CI_MODULE_READY; > p_ca_slot_info->num = 1; > p_ca_slot_info->type = CA_CI; > - } else > + } else { > p_ca_slot_info->flags = 0; > + p_ca_slot_info->num = 0; > + p_ca_slot_info->type = 0; > + } > > if (copy_to_user(arg, p_ca_slot_info, sizeof (struct ca_slot_info))) > return -EFAULT; note: i have no clue how p_ca_slot_info looks like, but to avoid information leaks via compiler padding etc. i could be more wise to do a memset(p_ca_slot_info,0,sizeof (struct ca_slot_info)) and then set the p_ca_slot_info->flags = CA_CI_MODULE_READY; p_ca_slot_info->num = 1; p_ca_slot_info->type = CA_CI; just my 2 cents, re, wh -- 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] bt8xx: info leak in ca_get_slot_info()
p_ca_slot_info was allocated with kmalloc() so we need to clear it before passing it to the user. Signed-off-by: Dan Carpenter diff --git a/drivers/media/pci/bt8xx/dst_ca.c b/drivers/media/pci/bt8xx/dst_ca.c index 0e788fc..6b9dc3f 100644 --- a/drivers/media/pci/bt8xx/dst_ca.c +++ b/drivers/media/pci/bt8xx/dst_ca.c @@ -302,8 +302,11 @@ static int ca_get_slot_info(struct dst_state *state, struct ca_slot_info *p_ca_s p_ca_slot_info->flags = CA_CI_MODULE_READY; p_ca_slot_info->num = 1; p_ca_slot_info->type = CA_CI; - } else + } else { p_ca_slot_info->flags = 0; + p_ca_slot_info->num = 0; + p_ca_slot_info->type = 0; + } if (copy_to_user(arg, p_ca_slot_info, sizeof (struct ca_slot_info))) return -EFAULT; -- 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
Sat Multiswitch, AMP, Sat Finder---shdlink
Dear Sirs, Our factory SHDLink has release the newest satellite multiswitches series, AV sender, SMATV amplifiers, LNB, Sat Finder, AV to RF Modulator, disEqc switch etc. Come back for competitive price and more products information. Tks. Look forward to receiving your reply soon! Best regards. Wina Wu *** SHDLINK Electronics Technology Co.,LTD Mobile: (+86) 136 2296 2710 Attn: Wina Wu SKYPE: winawu1981
Re: [PATCH] V4L: Add driver for Samsung S5K5BAF camera sensor
Hi Hans, On 07/25/2013 04:42 PM, Hans Verkuil wrote: > > Would it be an idea to create a library with rectangle manipulation functions? > Looking at this driver and similar ones as well that I had to deal with that > support cropping/scaling/composing I see a lot of rectangle manipulation. > > Moving that into a separate source that can be shared should simplify > development. Yes, I talked before about this exactly with Andrzej. We will consider creating such a library, but I can't tell at the moment when we can start working on this. There is still a few basic unsupported features of those cameras to take care of. :) Thanks, 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] V4L: Add driver for Samsung S5K5BAF camera sensor
On Wed 24 July 2013 19:51:03 Sylwester Nawrocki wrote: > From: Andrzej Hajda > > This patch adds V4L2 subdev driver for Samsung S5K5BAF CMOS > image sensor with embedded SoC ISP. > > The driver exposes two V4L2 subdevices: > - S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format, > no controls. > - S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200, > pre/post ISP cropping, downscaling via selection API, controls. > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Andrzej Hajda > Signed-off-by: Kyungmin Park > --- > v4: > - endpoint node presence is now optional, > - added asynchronous subdev registration support and clock > handling, > - GPL changed to GPLv2, > - bitfields replaced by u8, > - corrected s_stream flow, > - gpio pins are no longer exported, > - added I2C addresses to subdev names, > - CIS subdev registration postponed after succesfull > HW initialization, > - added enums for pads, > - selections are initialized only during probe, > - default resolution changed to 1600x1200, > - state->error pattern removed from few other functions, > - entity link creation moved to registered callback, > - some cosmetic changes. > > v3: > - narrowed state->error usage to i2c and power errors, > - private gain controls replaced by red/blue balance user controls, > - added checks to devicetree gpio node parsing > > v2: > - lower-cased driver name, > - removed underscore from regulator names, > - removed platform data code, > - v4l controls grouped in anonymous structs, > - added s5k5baf_clear_error function, > - private controls definitions moved to uapi header file, > - added v4l2-controls.h reservation for private controls, > - corrected subdev registered/unregistered code, > - .log_status sudbev op set to v4l2 helper, > - moved entity link creation to probe routines, > - added cleanup on error to probe function. > --- > .../devicetree/bindings/media/samsung-s5k5baf.txt | 58 + > MAINTAINERS|7 + > drivers/media/i2c/Kconfig |7 + > drivers/media/i2c/Makefile |1 + > drivers/media/i2c/s5k5baf.c| 2048 > > 5 files changed, 2121 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/samsung-s5k5baf.txt > create mode 100644 drivers/media/i2c/s5k5baf.c > > + > +enum selection_rect { R_CIS, R_CROP_SINK, R_COMPOSE, R_CROP_SOURCE, > R_INVALID }; > + > +static enum selection_rect s5k5baf_get_sel_rect(u32 pad, u32 target) > +{ > + switch (target) { > + case V4L2_SEL_TGT_CROP_BOUNDS: > + return pad ? R_COMPOSE : R_CIS; > + case V4L2_SEL_TGT_CROP: > + return pad ? R_CROP_SOURCE : R_CROP_SINK; > + case V4L2_SEL_TGT_COMPOSE_BOUNDS: > + return pad ? R_INVALID : R_CROP_SINK; > + case V4L2_SEL_TGT_COMPOSE: > + return pad ? R_INVALID : R_COMPOSE; > + default: > + return R_INVALID; > + } > +} > + > +static int s5k5baf_is_bound_target(u32 target) > +{ > + return (target == V4L2_SEL_TGT_CROP_BOUNDS || > + target == V4L2_SEL_TGT_COMPOSE_BOUNDS); > +} > + > +static int s5k5baf_get_selection(struct v4l2_subdev *sd, > + struct v4l2_subdev_fh *fh, > + struct v4l2_subdev_selection *sel) > +{ > + static enum selection_rect rtype; > + struct s5k5baf *state = to_s5k5baf(sd); > + > + rtype = s5k5baf_get_sel_rect(sel->pad, sel->target); > + > + switch (rtype) { > + case R_INVALID: > + return -EINVAL; > + case R_CIS: > + sel->r = s5k5baf_cis_rect; > + return 0; > + default: > + break; > + } > + > + if (sel->which == V4L2_SUBDEV_FORMAT_TRY) { > + if (rtype == R_COMPOSE) > + sel->r = *v4l2_subdev_get_try_compose(fh, sel->pad); > + else > + sel->r = *v4l2_subdev_get_try_crop(fh, sel->pad); > + return 0; > + } > + > + mutex_lock(&state->lock); > + switch (rtype) { > + case R_CROP_SINK: > + sel->r = state->crop_sink; > + break; > + case R_COMPOSE: > + sel->r = state->compose; > + break; > + case R_CROP_SOURCE: > + sel->r = state->crop_source; > + break; > + default: > + break; > + } > + if (s5k5baf_is_bound_target(sel->target)) { > + sel->r.left = 0; > + sel->r.top = 0; > + } > + mutex_unlock(&state->lock); > + > + return 0; > +} > + > +/* bounds range [start, start+len) to [0, max) and aligns to 2 */ > +static void s5k5baf_bound_range(u32 *start, u32 *len, u32 max) > +{ > + if (*len > max) > + *len = max; > + if (*start + *len > max) > + *start = max - *len; > + *start &= ~1; > + *len &= ~1; > + if (*len < S5K5BAF_W
Re: [PATCH v3 1/5] media: Add support for circular graph traversal
Hi Laurent, On Thu, Jul 25, 2013 at 03:00:09PM +0200, Laurent Pinchart wrote: > From: Laurent Pinchart > > The graph traversal API (media_entity_graph_walk_*) doesn't support > cyclic graphs and will fail to correctly walk a graph when circular > links exist. Support circular graph traversal by checking whether an > entity has already been visited before pushing it to the stack. > > Signed-off-by: Laurent Pinchart > --- > drivers/media/media-entity.c | 14 +++--- > include/media/media-entity.h | 3 +++ > 2 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c > index cb30ffb..2c286c3 100644 > --- a/drivers/media/media-entity.c > +++ b/drivers/media/media-entity.c > @@ -20,6 +20,7 @@ > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > */ > > +#include > #include > #include > #include > @@ -121,7 +122,6 @@ static struct media_entity *stack_pop(struct > media_entity_graph *graph) > return entity; > } > > -#define stack_peek(en) ((en)->stack[(en)->top - 1].entity) > #define link_top(en) ((en)->stack[(en)->top].link) > #define stack_top(en)((en)->stack[(en)->top].entity) > > @@ -140,6 +140,12 @@ void media_entity_graph_walk_start(struct > media_entity_graph *graph, > { > graph->top = 0; > graph->stack[graph->top].entity = NULL; > + bitmap_zero(graph->entities, MEDIA_ENTITY_ENUM_MAX_ID); > + > + if (WARN_ON(entity->id >= MEDIA_ENTITY_ENUM_MAX_ID)) > + return; > + > + __set_bit(entity->id, graph->entities); > stack_push(graph, entity); > } > EXPORT_SYMBOL_GPL(media_entity_graph_walk_start); > @@ -180,9 +186,11 @@ media_entity_graph_walk_next(struct media_entity_graph > *graph) > > /* Get the entity in the other end of the link . */ > next = media_entity_other(entity, link); > + if (WARN_ON(next->id >= MEDIA_ENTITY_ENUM_MAX_ID)) > + return NULL; Walking the graph will take the mutex anyway, so I don't think this can happen. > > - /* Was it the entity we came here from? */ > - if (next == stack_peek(graph)) { > + /* Has the entity already been visited? */ > + if (__test_and_set_bit(next->id, graph->entities)) { > link_top(graph)++; > continue; > } > diff --git a/include/media/media-entity.h b/include/media/media-entity.h > index 06bacf9..0b39662 100644 > --- a/include/media/media-entity.h > +++ b/include/media/media-entity.h > @@ -23,6 +23,7 @@ > #ifndef _MEDIA_ENTITY_H > #define _MEDIA_ENTITY_H > > +#include > #include > #include > > @@ -113,12 +114,14 @@ static inline u32 media_entity_subtype(struct > media_entity *entity) > } > > #define MEDIA_ENTITY_ENUM_MAX_DEPTH 16 > +#define MEDIA_ENTITY_ENUM_MAX_ID 64 > > struct media_entity_graph { > struct { > struct media_entity *entity; > int link; > } stack[MEDIA_ENTITY_ENUM_MAX_DEPTH]; > + unsigned long entities[BITS_TO_LONGS(MEDIA_ENTITY_ENUM_MAX_ID)]; How about using DECLARE_BITMAP() instead? > int top; > }; > -- Cheers, 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
Re: [PATCH v2 5/5] v4l: Renesas R-Car VSP1 driver
Hi Laurent, On Thu, Jul 25, 2013 at 01:46:54PM +0200, Laurent Pinchart wrote: > > On Wed, Jul 17, 2013 at 04:54:42PM +0200, Laurent Pinchart wrote: > > ... > > > > > +static void vsp1_device_init(struct vsp1_device *vsp1) > > > +{ > > > + unsigned int i; > > > + u32 status; > > > + > > > + /* Reset any channel that might be running. */ > > > + status = vsp1_read(vsp1, VI6_STATUS); > > > + > > > + for (i = 0; i < VPS1_MAX_WPF; ++i) { > > > + unsigned int timeout; > > > + > > > + if (!(status & VI6_STATUS_SYS_ACT(i))) > > > + continue; > > > + > > > + vsp1_write(vsp1, VI6_SRESET, VI6_SRESET_SRTS(i)); > > > + for (timeout = 10; timeout > 0; --timeout) { > > > + status = vsp1_read(vsp1, VI6_STATUS); > > > + if (!(status & VI6_STATUS_SYS_ACT(i))) > > > + break; > > > + > > > + usleep_range(1000, 2000); > > > + } > > > + > > > + if (timeout) > > > + dev_err(vsp1->dev, "failed to reset wpf.%u\n", i); > > > > Have you seen this happening in practice? Do you expect the device to > > function if resetting it fails? > > I've seen this happening during development when I had messed up register > values, but not otherwise. I don't expect the deviec to still function if > resetting the WPF fails, but I need to make sure that the busy loop exits. Shouldn't you also return an error in this case? The function currently returns void. ... > > > + /* Follow links downstream for each input and make sure the graph > > > + * contains no loop and that all branches end at the output WPF. > > > + */ > > > > I wonder if checking for loops should be done already in pipeline validation > > done by the framework. That's fine to do later on IMHO, too. > > It would have to be performed by the core, as the callbacks are local to > links. That's feasible (but should be optional, as some devices might support > circular graphs), feel free to submit a patch :-) As a matter of fact I think I will. I'd like you to test it though since I have no hardware with such media graph. :-) But please don't expect to see that in time for your driver to get in. Let's think about that later on. -- Kind regards, 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
Re: [PATCH 3/4] rds-ctl: Always terminate strings properly
On Thu 25 July 2013 15:09:33 Gregor Jasny wrote: > Detected by Coverity. > > Signed-off-by: Gregor Jasny > CC: Hans Verkuil Reviewed-by: Hans Verkuil Thanks! Hans > --- > utils/rds-ctl/rds-ctl.cpp | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/utils/rds-ctl/rds-ctl.cpp b/utils/rds-ctl/rds-ctl.cpp > index a9fe2a8..74972eb 100644 > --- a/utils/rds-ctl/rds-ctl.cpp > +++ b/utils/rds-ctl/rds-ctl.cpp > @@ -762,13 +762,11 @@ static int parse_cl(int argc, char **argv) > params.options[(int)opt] = 1; > switch (opt) { > case OptSetDevice: > - strncpy(params.fd_name, optarg, 80); > + strncpy(params.fd_name, optarg, sizeof(params.fd_name)); > if (optarg[0] >= '0' && optarg[0] <= '9' && > strlen(optarg) <= 3) { > - static char newdev[20]; > - > - sprintf(newdev, "/dev/radio%s", optarg); > - strncpy(params.fd_name, newdev, 20); > + snprintf(params.fd_name, > sizeof(params.fd_name), "/dev/radio%s", optarg); > } > + params.fd_name[sizeof(params.fd_name) - 1] = '\0'; > break; > case OptSetFreq: > params.freq = strtod(optarg, NULL); > @@ -786,7 +784,8 @@ static int parse_cl(int argc, char **argv) > { > if (access(optarg, F_OK) != -1) { > params.filemode_active = true; > - strncpy(params.fd_name, optarg, 80); > + strncpy(params.fd_name, optarg, > sizeof(params.fd_name)); > + params.fd_name[sizeof(params.fd_name) - 1] = > '\0'; > } else { > fprintf(stderr, "Unable to open file: %s\n", > optarg); > return -1; > @@ -1006,7 +1005,8 @@ int main(int argc, char **argv) > fprintf(stderr, "No RDS-capable device found\n"); > exit(1); > } > - strncpy(params.fd_name, devices[0].c_str(), 80); > + strncpy(params.fd_name, devices[0].c_str(), > sizeof(params.fd_name)); > + params.fd_name[sizeof(params.fd_name) - 1] = '\0'; > printf("Using device: %s\n", params.fd_name); > } > if ((fd = test_open(params.fd_name, O_RDONLY | O_NONBLOCK)) < 0) { > -- 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
[PATCHv2 2/5] qv4l2: add hotkeys for common operations
CTRL + V : When main window is selected start capture. This gives an option other than the button to start recording, as this is a frequent operation when using the utility. CTRL + W : When CaptureWin is selected close capture window It makes it easier to deal with high resolutions video on small screen, especially when the window close button may be outside the monitor when repositioning the window. Signed-off-by: Bård Eirik Winther --- utils/qv4l2/capture-win.cpp | 8 utils/qv4l2/capture-win.h | 4 +++- utils/qv4l2/qv4l2.cpp | 1 + 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp index 6798252..a94c73d 100644 --- a/utils/qv4l2/capture-win.cpp +++ b/utils/qv4l2/capture-win.cpp @@ -35,6 +35,14 @@ CaptureWin::CaptureWin() vbox->addWidget(m_label); vbox->addWidget(m_msg); + + hotkeyClose = new QShortcut(Qt::CTRL+Qt::Key_W, this); + QObject::connect(hotkeyClose, SIGNAL(activated()), this, SLOT(close())); +} + +CaptureWin::~CaptureWin() +{ + delete hotkeyClose; } void CaptureWin::setImage(const QImage &image, const QString &status) diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h index e861b12..4115d56 100644 --- a/utils/qv4l2/capture-win.h +++ b/utils/qv4l2/capture-win.h @@ -21,6 +21,7 @@ #define CAPTURE_WIN_H #include +#include #include class QImage; @@ -32,7 +33,7 @@ class CaptureWin : public QWidget public: CaptureWin(); - virtual ~CaptureWin() {} + ~CaptureWin(); void setImage(const QImage &image, const QString &status); @@ -45,6 +46,7 @@ signals: private: QLabel *m_label; QLabel *m_msg; + QShortcut *hotkeyClose; }; #endif diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp index a8fcc65..bb1d84f 100644 --- a/utils/qv4l2/qv4l2.cpp +++ b/utils/qv4l2/qv4l2.cpp @@ -78,6 +78,7 @@ ApplicationWindow::ApplicationWindow() : m_capStartAct->setStatusTip("Start capturing"); m_capStartAct->setCheckable(true); m_capStartAct->setDisabled(true); + m_capStartAct->setShortcut(Qt::CTRL+Qt::Key_V); connect(m_capStartAct, SIGNAL(toggled(bool)), this, SLOT(capStart(bool))); m_snapshotAct = new QAction(QIcon(":/snapshot.png"), "&Make Snapshot", this); -- 1.8.3.2 -- 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
[PATCHv2 1/5] qv4l2: move function ctrlEvent
Moved the ctrlEvent() function in qv4l2.cpp to be grouped with GUI function and to group capFrame() and capVbiFrame() together. Signed-off-by: Bård Eirik Winther --- utils/qv4l2/qv4l2.cpp | 94 +-- 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp index de9b154..a8fcc65 100644 --- a/utils/qv4l2/qv4l2.cpp +++ b/utils/qv4l2/qv4l2.cpp @@ -202,6 +202,53 @@ void ApplicationWindow::openrawdev() setDevice(d.selectedFiles().first(), true); } +void ApplicationWindow::ctrlEvent() +{ + v4l2_event ev; + + while (dqevent(ev)) { + if (ev.type != V4L2_EVENT_CTRL) + continue; + m_ctrlMap[ev.id].flags = ev.u.ctrl.flags; + m_ctrlMap[ev.id].minimum = ev.u.ctrl.minimum; + m_ctrlMap[ev.id].maximum = ev.u.ctrl.maximum; + m_ctrlMap[ev.id].step = ev.u.ctrl.step; + m_ctrlMap[ev.id].default_value = ev.u.ctrl.default_value; + m_widgetMap[ev.id]->setDisabled(m_ctrlMap[ev.id].flags & CTRL_FLAG_DISABLED); + switch (m_ctrlMap[ev.id].type) { + case V4L2_CTRL_TYPE_INTEGER: + case V4L2_CTRL_TYPE_INTEGER_MENU: + case V4L2_CTRL_TYPE_MENU: + case V4L2_CTRL_TYPE_BOOLEAN: + case V4L2_CTRL_TYPE_BITMASK: + setVal(ev.id, ev.u.ctrl.value); + break; + case V4L2_CTRL_TYPE_INTEGER64: + setVal64(ev.id, ev.u.ctrl.value64); + break; + default: + break; + } + if (m_ctrlMap[ev.id].type != V4L2_CTRL_TYPE_STRING) + continue; + queryctrl(m_ctrlMap[ev.id]); + + struct v4l2_ext_control c; + struct v4l2_ext_controls ctrls; + + c.id = ev.id; + c.size = m_ctrlMap[ev.id].maximum + 1; + c.string = (char *)malloc(c.size); + memset(&ctrls, 0, sizeof(ctrls)); + ctrls.count = 1; + ctrls.ctrl_class = 0; + ctrls.controls = &c; + if (!ioctl(VIDIOC_G_EXT_CTRLS, &ctrls)) + setString(ev.id, c.string); + free(c.string); + } +} + void ApplicationWindow::capVbiFrame() { __u32 buftype = m_genTab->bufType(); @@ -305,53 +352,6 @@ void ApplicationWindow::capVbiFrame() refresh(); } -void ApplicationWindow::ctrlEvent() -{ - v4l2_event ev; - - while (dqevent(ev)) { - if (ev.type != V4L2_EVENT_CTRL) - continue; - m_ctrlMap[ev.id].flags = ev.u.ctrl.flags; - m_ctrlMap[ev.id].minimum = ev.u.ctrl.minimum; - m_ctrlMap[ev.id].maximum = ev.u.ctrl.maximum; - m_ctrlMap[ev.id].step = ev.u.ctrl.step; - m_ctrlMap[ev.id].default_value = ev.u.ctrl.default_value; - m_widgetMap[ev.id]->setDisabled(m_ctrlMap[ev.id].flags & CTRL_FLAG_DISABLED); - switch (m_ctrlMap[ev.id].type) { - case V4L2_CTRL_TYPE_INTEGER: - case V4L2_CTRL_TYPE_INTEGER_MENU: - case V4L2_CTRL_TYPE_MENU: - case V4L2_CTRL_TYPE_BOOLEAN: - case V4L2_CTRL_TYPE_BITMASK: - setVal(ev.id, ev.u.ctrl.value); - break; - case V4L2_CTRL_TYPE_INTEGER64: - setVal64(ev.id, ev.u.ctrl.value64); - break; - default: - break; - } - if (m_ctrlMap[ev.id].type != V4L2_CTRL_TYPE_STRING) - continue; - queryctrl(m_ctrlMap[ev.id]); - - struct v4l2_ext_control c; - struct v4l2_ext_controls ctrls; - - c.id = ev.id; - c.size = m_ctrlMap[ev.id].maximum + 1; - c.string = (char *)malloc(c.size); - memset(&ctrls, 0, sizeof(ctrls)); - ctrls.count = 1; - ctrls.ctrl_class = 0; - ctrls.controls = &c; - if (!ioctl(VIDIOC_G_EXT_CTRLS, &ctrls)) - setString(ev.id, c.string); - free(c.string); - } -} - void ApplicationWindow::capFrame() { __u32 buftype = m_genTab->bufType(); -- 1.8.3.2 -- 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
[PATCHv2 3/5] qv4l2: fix minimum size in capture win to frame size
CaptureWin's setMinimumSize() sets the minimum size for the video frame viewport and not for the window itself. If the minimum size is larger than the monitor resolution, it will reduce the minimum size to match this. Signed-off-by: Bård Eirik Winther --- utils/qv4l2/capture-win.cpp | 29 + utils/qv4l2/capture-win.h | 1 + 2 files changed, 30 insertions(+) diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp index a94c73d..68dc9ed 100644 --- a/utils/qv4l2/capture-win.cpp +++ b/utils/qv4l2/capture-win.cpp @@ -21,6 +21,8 @@ #include #include #include +#include +#include #include "qv4l2.h" #include "capture-win.h" @@ -45,6 +47,33 @@ CaptureWin::~CaptureWin() delete hotkeyClose; } +void CaptureWin::setMinimumSize(int minw, int minh) +{ + QDesktopWidget *screen = QApplication::desktop(); + QRect resolution = screen->screenGeometry(); + QSize maxSize = maximumSize(); + + int l, t, r, b; + layout()->getContentsMargins(&l, &t, &r, &b); + minw += l + r; + minh += t + b + m_msg->minimumSizeHint().height() + layout()->spacing(); + + if (minw > resolution.width()) + minw = resolution.width(); + if (minw < 150) + minw = 150; + + if (minh > resolution.height()) + minh = resolution.height(); + if (minh < 100) + minh = 100; + + QWidget::setMinimumSize(minw, minh); + QWidget::setMaximumSize(minw, minh); + updateGeometry(); + QWidget::setMaximumSize(maxSize.width(), maxSize.height()); +} + void CaptureWin::setImage(const QImage &image, const QString &status) { m_label->setPixmap(QPixmap::fromImage(image)); diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h index 4115d56..3925757 100644 --- a/utils/qv4l2/capture-win.h +++ b/utils/qv4l2/capture-win.h @@ -35,6 +35,7 @@ public: CaptureWin(); ~CaptureWin(); + void setMinimumSize(int minw, int minh); void setImage(const QImage &image, const QString &status); protected: -- 1.8.3.2 -- 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
[PATCHv2 4/5] qv4l2: new modular capture window design
The display of video has been divided into classes to easier implement other ways to render frames on screen. Signed-off-by: Bård Eirik Winther --- utils/qv4l2/Makefile.am| 4 +- utils/qv4l2/capture-win-qt.cpp | 89 utils/qv4l2/capture-win-qt.h | 48 utils/qv4l2/capture-win.cpp| 45 ++- utils/qv4l2/capture-win.h | 25 ++- utils/qv4l2/qv4l2.cpp | 100 - utils/qv4l2/qv4l2.h| 1 + 7 files changed, 226 insertions(+), 86 deletions(-) create mode 100644 utils/qv4l2/capture-win-qt.cpp create mode 100644 utils/qv4l2/capture-win-qt.h diff --git a/utils/qv4l2/Makefile.am b/utils/qv4l2/Makefile.am index 1f5a49f..9ef8149 100644 --- a/utils/qv4l2/Makefile.am +++ b/utils/qv4l2/Makefile.am @@ -1,6 +1,7 @@ bin_PROGRAMS = qv4l2 qv4l2_SOURCES = qv4l2.cpp general-tab.cpp ctrl-tab.cpp vbi-tab.cpp v4l2-api.cpp capture-win.cpp \ + capture-win-qt.cpp capture-win-qt.h \ raw2sliced.cpp qv4l2.h capture-win.h general-tab.h vbi-tab.h v4l2-api.h raw2sliced.h nodist_qv4l2_SOURCES = moc_qv4l2.cpp moc_general-tab.cpp moc_capture-win.cpp moc_vbi-tab.cpp qrc_qv4l2.cpp qv4l2_LDADD = ../../lib/libv4l2/libv4l2.la ../../lib/libv4lconvert/libv4lconvert.la ../libv4l2util/libv4l2util.la @@ -37,5 +38,4 @@ install-data-local: $(INSTALL_DATA) -D -p "$(srcdir)/qv4l2_24x24.png" "$(DESTDIR)$(datadir)/icons/hicolor/24x24/apps/qv4l2.png" $(INSTALL_DATA) -D -p "$(srcdir)/qv4l2_32x32.png" "$(DESTDIR)$(datadir)/icons/hicolor/32x32/apps/qv4l2.png" $(INSTALL_DATA) -D -p "$(srcdir)/qv4l2_64x64.png" "$(DESTDIR)$(datadir)/icons/hicolor/64x64/apps/qv4l2.png" - $(INSTALL_DATA) -D -p "$(srcdir)/qv4l2.svg" "$(DESTDIR)$(datadir)/icons/hicolor/scalable/apps/qv4l2.svg" - + $(INSTALL_DATA) -D -p "$(srcdir)/qv4l2.svg" "$(DESTDIR)$(datadir)/icons/hicolor/scalable/apps/qv4l2.svg" \ No newline at end of file diff --git a/utils/qv4l2/capture-win-qt.cpp b/utils/qv4l2/capture-win-qt.cpp new file mode 100644 index 000..63c77d5 --- /dev/null +++ b/utils/qv4l2/capture-win-qt.cpp @@ -0,0 +1,89 @@ +/* qv4l2: a control panel controlling v4l2 devices. + * + * Copyright (C) 2006 Hans Verkuil + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + */ + +#include "capture-win-qt.h" + +CaptureWinQt::CaptureWinQt() : + m_frame(new QImage(0, 0, QImage::Format_Invalid)) +{ + + CaptureWin::buildWindow(&m_videoSurface); +} + +CaptureWinQt::~CaptureWinQt() +{ + delete m_frame; +} + +void CaptureWinQt::setFrame(int width, int height, __u32 format, unsigned char *data, const QString &info) +{ + QImage::Format dstFmt; + bool supported = findNativeFormat(format, dstFmt); + if (!supported) + dstFmt = QImage::Format_RGB888; + + if (m_frame->width() != width || m_frame->height() != height || m_frame->format() != dstFmt) { + delete m_frame; + m_frame = new QImage(width, height, dstFmt); + } + + if (data == NULL || !supported) + m_frame->fill(0); + else + memcpy(m_frame->bits(), data, m_frame->numBytes()); + + m_information.setText(info); + m_videoSurface.setPixmap(QPixmap::fromImage(*m_frame)); +} + +bool CaptureWinQt::hasNativeFormat(__u32 format) +{ + QImage::Format fmt; + return findNativeFormat(format, fmt); +} + +bool CaptureWinQt::findNativeFormat(__u32 format, QImage::Format &dstFmt) +{ + static const struct { + __u32 v4l2_pixfmt; + QImage::Format qt_pixfmt; + } supported_fmts[] = { +#if Q_BYTE_ORDER == Q_BIG_ENDIAN + { V4L2_PIX_FMT_RGB32, QImage::Format_RGB32 }, + { V4L2_PIX_FMT_RGB24, QImage::Format_RGB888 }, + { V4L2_PIX_FMT_RGB565X, QImage::Format_RGB16 }, + { V4L2_PIX_FMT_RGB555X, QImage::Format_RGB555 }, +#else + { V4L2_PIX_FMT_BGR32, QImage::Format_RGB32 }, + { V4L2_PIX_FMT_RGB24, QImage::Format_RGB888 }, + { V4L2_PIX_FMT_RGB565, QImage::Format_RGB16 }, + { V4L2_PIX_FMT_RGB555, QImage::Format_RGB555 }, + { V4L2_PIX_FMT_RGB444, QImage::Format_RGB444 }, +#endif
[PATCHv2 5/5] qv4l2: add OpenGL video display and render
Adds OpenGL-accelerated display of video for the qv4l2 test utility. This allows for using the graphics card to render the video content to screen and to perform color space conversion. Signed-off-by: Bård Eirik Winther --- configure.ac | 8 +- utils/qv4l2/Makefile.am| 8 +- utils/qv4l2/capture-win-gl.cpp | 556 + utils/qv4l2/capture-win-gl.h | 103 utils/qv4l2/qv4l2.cpp | 52 +++- utils/qv4l2/qv4l2.h| 10 + 6 files changed, 733 insertions(+), 4 deletions(-) create mode 100644 utils/qv4l2/capture-win-gl.cpp create mode 100644 utils/qv4l2/capture-win-gl.h diff --git a/configure.ac b/configure.ac index e249546..d74da61 100644 --- a/configure.ac +++ b/configure.ac @@ -128,7 +128,12 @@ if test "x$qt_pkgconfig" = "xtrue"; then AC_SUBST(UIC) AC_SUBST(RCC) else - AC_MSG_WARN(Qt4 is not available) + AC_MSG_WARN(Qt4 or higher is not available) +fi + +PKG_CHECK_MODULES(QTGL, [QtOpenGL >= 4.4 gl], [qt_pkgconfig_gl=true], [qt_pkgconfig_gl=false]) +if test "x$qt_pkgconfig_gl" = "xfalse"; then + AC_MSG_WARN(Qt4 OpenGL or higher is not available) fi AC_SUBST([JPEG_LIBS]) @@ -237,6 +242,7 @@ AM_CONDITIONAL([WITH_LIBDVBV5], [test x$enable_libdvbv5 = xyes]) AM_CONDITIONAL([WITH_LIBV4L], [test x$enable_libv4l != xno]) AM_CONDITIONAL([WITH_V4LUTILS], [test x$enable_v4lutils != xno]) AM_CONDITIONAL([WITH_QV4L2], [test ${qt_pkgconfig} = true -a x$enable_qv4l2 != xno]) +AM_CONDITIONAL([WITH_QV4L2_GL], [test WITH_QV4L2 -a ${qt_pkgconfig_gl} = true]) AM_CONDITIONAL([WITH_V4L_PLUGINS], [test x$enable_libv4l != xno -a x$enable_shared != xno]) AM_CONDITIONAL([WITH_V4L_WRAPPERS], [test x$enable_libv4l != xno -a x$enable_shared != xno]) diff --git a/utils/qv4l2/Makefile.am b/utils/qv4l2/Makefile.am index 9ef8149..22d4c17 100644 --- a/utils/qv4l2/Makefile.am +++ b/utils/qv4l2/Makefile.am @@ -1,12 +1,18 @@ bin_PROGRAMS = qv4l2 qv4l2_SOURCES = qv4l2.cpp general-tab.cpp ctrl-tab.cpp vbi-tab.cpp v4l2-api.cpp capture-win.cpp \ - capture-win-qt.cpp capture-win-qt.h \ + capture-win-qt.cpp capture-win-qt.h capture-win-gl.cpp capture-win-gl.h \ raw2sliced.cpp qv4l2.h capture-win.h general-tab.h vbi-tab.h v4l2-api.h raw2sliced.h nodist_qv4l2_SOURCES = moc_qv4l2.cpp moc_general-tab.cpp moc_capture-win.cpp moc_vbi-tab.cpp qrc_qv4l2.cpp qv4l2_LDADD = ../../lib/libv4l2/libv4l2.la ../../lib/libv4lconvert/libv4lconvert.la ../libv4l2util/libv4l2util.la + +if WITH_QV4L2_GL +qv4l2_CPPFLAGS = $(QTGL_CFLAGS) -DENABLE_GL +qv4l2_LDFLAGS = $(QTGL_LIBS) +else qv4l2_CPPFLAGS = $(QT_CFLAGS) qv4l2_LDFLAGS = $(QT_LIBS) +endif EXTRA_DIST = exit.png fileopen.png qv4l2_24x24.png qv4l2_64x64.png qv4l2.png qv4l2.svg snapshot.png \ video-television.png fileclose.png qv4l2_16x16.png qv4l2_32x32.png qv4l2.desktop qv4l2.qrc record.png \ diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp new file mode 100644 index 000..d5c1d54 --- /dev/null +++ b/utils/qv4l2/capture-win-gl.cpp @@ -0,0 +1,556 @@ +/* + * The YUY2 shader code was copied and simplified from face-responder. The code is under public domain: + * https://bitbucket.org/nateharward/face-responder/src/0c3b4b957039d9f4bf1da09b9471371942de2601/yuv42201_laplace.frag?at=master + * + * Copyright (C) 2012 Nathan Harward + * + * All other OpenGL code: + * + * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + * + * This program is free software; you may redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + */ + +#include "capture-win-gl.h" + +#include + +CaptureWinGL::CaptureWinGL() +{ + CaptureWin::buildWindow(&m_videoSurface); + CaptureWin::setWindowTitle("V4L2 Capture (OpenGL)"); +} + +CaptureWinGL::~CaptureWinGL() +{ +} + +void CaptureWinGL::stop() +{ +#ifdef ENABLE_GL + m_videoSurface.stop(); +#endif +} + +void CaptureWinGL::setFrame(int width, int height, __u32 format, unsigned char *data, const QString &info) +{ +#ifdef ENABLE_GL + m_videoSurface.setFrame(width, height, format, data); +#endif + m_information.setText(info); +} + +bool CaptureWinGL::hasNativeFormat(__u32 format) +{ +#ifdef ENABLE_GL + return m_videoSurface.hasNativeFormat(format); +#else + return false; +#endif +} + +bool CaptureWinGL::isSupported() +{ +#ifdef ENABLE_GL + return true;
[PATCHv2 0/5] qv4l2: add OpenGL render and window fixes
The qv4l2 test utility now supports OpenGL-accelerated display of video. This allows for using the graphics card to render the video content to screen and to perform color space conversion. The OpenGL implementation requires OpenGL and QtOpenGL libraries as well as an OpenGL driver (typically from the graphics driver). If OpenGL support is not present, then the program will fall back to using the CPU to display. Changelog v2: - Cleaned up the capture win code and classes - CaptureWin is now a base class that can be used to implement different ways of displaying video. - setMinimumSize is now more reliable - Small code tweaks and improvements, including cleaner display flow - Changed the OpenGL abbreviation from OGL to GL Some of the changes/improvements: - Moved the ctrlEvent() function in qv4l2.cpp to be grouped with GUI function and to group capFrame() and capVbiFrame() together. - OpenGL acceleration for supported systems. - Option to change between GPU or CPU based rendering. - CaptureWin's setMinimumSize() sets the minimum size for the video frame viewport and not for the window itself. If the minimum size is larger than the monitor resolution, it will reduce the minimum size to match this. - Added a new menu option 'Preview' for controlling the CaptureWin's behavior. - Added a couple of hotkeys: CTRL + V : When main window is selected start capture. This gives an option other than the button to start recording, as this is a frequent operation when using the utility. CTRL + W : When CaptureWin is selected close capture window. It makes it easier to deal with high resolutions video on small screen, especially when the window close button may be outside the monitor when repositioning the window. Known issues: - Repositioning, scaling or switching windows while the capture is recording will reduce the framerate. This is a limitation of Qt and not OpenGL. - Using 4 streams of RGB3 1080p60 can at random times cease to render correctly and reduce the framerate to half. A restart solves this though. - OpenGL is limited to 60fps. Disabling V-sync might allow for faster framerates. - Resizing or scaling is not supported, mainly because the YUY2 shader renders the image incorrectly when the canvas size is not equal to the frame size. - Some of the supported OpenGL formats may use the CPU for colorspace conversion, but this is driver dependant. Supported formats for OpenGL render: - Native supported and accelerated: V4L2_PIX_FMT_RGB32 V4L2_PIX_FMT_BGR32 V4L2_PIX_FMT_RGB24 V4L2_PIX_FMT_BGR24 V4L2_PIX_FMT_RGB565 V4L2_PIX_FMT_RGB555 V4L2_PIX_FMT_YUYV V4L2_PIX_FMT_YVYU V4L2_PIX_FMT_UYVY V4L2_PIX_FMT_VYUY V4L2_PIX_FMT_YVU420 V4L2_PIX_FMT_YUV420 - All formats supported by V4L conversion library, but they will use the CPU to convert to RGB3 before being displayed with OpenGL. Performance: All tests are done on an Intel i7-2600S (with Turbo Boost disabled) using the integrated Intel HD 2000 graphics processor. The mothreboard is an ASUS P8H77-I with 2x2GB CL 9-9-9-24 DDR3 RAM. The capture card is a Cisco test card with 4 HDMI inputs connected using PCIe2.0x8. All video input streams used for testing are progressive HD (1920x1080) with 60fps. FPS for every input for a given number of streams: 1 STREAM 2 STREAMS 3 STREAMS 4 STREAMS RGB3 6060 60 60 BGR3 6060 60 50 YUYV 6060 60 48 YU12 6060 60 52 YV12 6060 60 52 -- 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 FOR v3.11]
Hi Prabhakar, On Thu 11 July 2013 19:25:15 Prabhakar Lad wrote: > Hi Hans, > > On Thu, Jun 27, 2013 at 12:25 PM, Hans Verkuil wrote: > > (Same as my previous git pull message, but with more cleanup patches and > [snip] > > Lad, Prabhakar (9): > > media: i2c: ths8200: support asynchronous probing > > media: i2c: ths8200: add OF support > > media: i2c: adv7343: add support for asynchronous probing > > media: i2c: tvp7002: add support for asynchronous probing > > media: i2c: tvp7002: remove manual setting of subdev name > > media: i2c: tvp514x: remove manual setting of subdev name > > media: i2c: tvp514x: add support for asynchronous probing > > media: davinci: vpif: capture: add V4L2-async support > > media: davinci: vpif: display: add V4L2-async support > > > I see last two patches missing in Mauro's pull request for v3.11 and > v3.11-rc1. I had to split up my pull request into fixes for 3.11 and new stuff for 3.12 since the merge window was about to open at the time. Your 'missing' patches are here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/for-v3.12 In the next few days I'll try to process all remaining patches delegated to me. If you have patches not yet delegated to me, or that are not in my for-v3.12 branch, then let me know. Regards, Hans -- 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: UVC and V4L2_CAP_AUDIO
Hi Devin, On Thursday 25 July 2013 09:11:31 Devin Heitmueller wrote: > On Thu, Jul 25, 2013 at 5:10 AM, Laurent Pinchart wrote: > > Not without dirty hacks. The UVC interfaces don't report whether the > > device has an audio function, the driver would need to look at all the > > interfaces of the parent USB device and find out whether they match one of > > the USB audio drivers. That's not something I would be inclined to merge > > in the uvcvideo driver. > > We need this functionality anyway for other snd-usb-audio based tuners > like em28xx and au0828, so I think some sort of solution is > unavoidable. I hacked something together for em28xx a few years ago > to do such an enumeration, but in reality we should probably have an > export in snd-usb-audio which would help figuring this out in a less > hacky way. > > >> If not, then it looks like the only way to find the associated alsa > >> device is to use libmedia_dev (or its replacement, although I wonder if > >> anyone is still working on that). > > Yup, it's 2013 and we still don't have a way for applications to ask the > kernel which ALSA device is tied to a given /dev/video node. Hans, remember > when I proposed adding a trivial ioctl() call back in 2009 that would allow > this, and you rejected it saying the media controller API was the answer? > It's hard not to feel like salt in the wound that it's four years later and > there *still* isn't a solution. It's partly my fault for not having found time to work on this. http://git.ideasonboard.org/media-ctl.git/shortlog/refs/heads/enum http://git.ideasonboard.org/media-enum.git Not completely there yet, but this already allows enumerating media devices (audio and video) in the system. A bit of code cleanup is still needed in the media-ctl enum branch. I'll try to find time for that next week and finally submit patches. -- Regards, Laurent Pinchart -- 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: UVC and V4L2_CAP_AUDIO
On Thu, Jul 25, 2013 at 5:10 AM, Laurent Pinchart wrote: > Not without dirty hacks. The UVC interfaces don't report whether the device > has an audio function, the driver would need to look at all the interfaces of > the parent USB device and find out whether they match one of the USB audio > drivers. That's not something I would be inclined to merge in the uvcvideo > driver. We need this functionality anyway for other snd-usb-audio based tuners like em28xx and au0828, so I think some sort of solution is unavoidable. I hacked something together for em28xx a few years ago to do such an enumeration, but in reality we should probably have an export in snd-usb-audio which would help figuring this out in a less hacky way. >> If not, then it looks like the only way to find the associated alsa device >> is to use libmedia_dev (or its replacement, although I wonder if anyone is >> still working on that). Yup, it's 2013 and we still don't have a way for applications to ask the kernel which ALSA device is tied to a given /dev/video node. Hans, remember when I proposed adding a trivial ioctl() call back in 2009 that would allow this, and you rejected it saying the media controller API was the answer? It's hard not to feel like salt in the wound that it's four years later and there *still* isn't a solution. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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] libdvbv5: Fix reallocation in parse_lcn
Detected by Coverity. Signed-off-by: Gregor Jasny CC: Mauro Carvalho Chehab --- lib/libdvbv5/descriptors.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/libdvbv5/descriptors.c b/lib/libdvbv5/descriptors.c index 73338d8..99d8fa3 100644 --- a/lib/libdvbv5/descriptors.c +++ b/lib/libdvbv5/descriptors.c @@ -758,7 +758,7 @@ static void parse_lcn(struct nit_table *nit_table, for (i = 0; i < dlen; i+= 4, p+= 4) { struct lcn_table **lcn = &nit_table->lcn; - *lcn = realloc(*lcn, (n + 1) * sizeof(*lcn)); + *lcn = realloc(*lcn, (n + 1) * sizeof(**lcn)); (*lcn)[n].service_id = p[0] << 8 | p[1]; (*lcn)[n].lcn = (p[2] << 8 | p[3]) & 0x3ff; nit_table->lcn_len++; -- 1.8.3.2 -- 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] libdvbv5: Fix copy and paste error in parse_service()
Detected by Coverity. Signed-off-by: Gregor Jasny CC: Mauro Carvalho Chehab CC: André Roth --- lib/libdvbv5/descriptors.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/libdvbv5/descriptors.c b/lib/libdvbv5/descriptors.c index 99d8fa3..9b6b050 100644 --- a/lib/libdvbv5/descriptors.c +++ b/lib/libdvbv5/descriptors.c @@ -787,9 +787,9 @@ static void parse_service(struct dvb_v5_fe_parms *parms, struct service_table *s if (verbose) { if (service_table->provider_name) printf("Provider %s", service_table->provider_name); - if (service_table->service_alias) + if (service_table->provider_alias) printf("(%s)", service_table->provider_alias); - if (service_table->provider_name || service_table->service_alias) + if (service_table->provider_name || service_table->provider_alias) printf("\n"); if (service_table->service_name) printf("Service %s", service_table->service_name); -- 1.8.3.2 -- 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] rds-ctl: Always terminate strings properly
Detected by Coverity. Signed-off-by: Gregor Jasny CC: Hans Verkuil --- utils/rds-ctl/rds-ctl.cpp | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/utils/rds-ctl/rds-ctl.cpp b/utils/rds-ctl/rds-ctl.cpp index a9fe2a8..74972eb 100644 --- a/utils/rds-ctl/rds-ctl.cpp +++ b/utils/rds-ctl/rds-ctl.cpp @@ -762,13 +762,11 @@ static int parse_cl(int argc, char **argv) params.options[(int)opt] = 1; switch (opt) { case OptSetDevice: - strncpy(params.fd_name, optarg, 80); + strncpy(params.fd_name, optarg, sizeof(params.fd_name)); if (optarg[0] >= '0' && optarg[0] <= '9' && strlen(optarg) <= 3) { - static char newdev[20]; - - sprintf(newdev, "/dev/radio%s", optarg); - strncpy(params.fd_name, newdev, 20); + snprintf(params.fd_name, sizeof(params.fd_name), "/dev/radio%s", optarg); } + params.fd_name[sizeof(params.fd_name) - 1] = '\0'; break; case OptSetFreq: params.freq = strtod(optarg, NULL); @@ -786,7 +784,8 @@ static int parse_cl(int argc, char **argv) { if (access(optarg, F_OK) != -1) { params.filemode_active = true; - strncpy(params.fd_name, optarg, 80); + strncpy(params.fd_name, optarg, sizeof(params.fd_name)); + params.fd_name[sizeof(params.fd_name) - 1] = '\0'; } else { fprintf(stderr, "Unable to open file: %s\n", optarg); return -1; @@ -1006,7 +1005,8 @@ int main(int argc, char **argv) fprintf(stderr, "No RDS-capable device found\n"); exit(1); } - strncpy(params.fd_name, devices[0].c_str(), 80); + strncpy(params.fd_name, devices[0].c_str(), sizeof(params.fd_name)); + params.fd_name[sizeof(params.fd_name) - 1] = '\0'; printf("Using device: %s\n", params.fd_name); } if ((fd = test_open(params.fd_name, O_RDONLY | O_NONBLOCK)) < 0) { -- 1.8.3.2 -- 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 0/4] v4l-utils: Some fixes for Coverity issues
Hello, the following patches fix issues that the Coverity static analyzer found in v4l-utils. Please review. Thanks, Gregor Gregor Jasny (4): xc3082: Fix use after free in free_firmware() libdvbv5: Fix reallocation in parse_lcn rds-ctl: Always terminate strings properly libdvbv5: Fix copy and paste error in parse_service() lib/libdvbv5/descriptors.c| 6 +++--- utils/rds-ctl/rds-ctl.cpp | 14 +++--- utils/xc3028-firmware/firmware-tool.c | 2 +- 3 files changed, 11 insertions(+), 11 deletions(-) -- 1.8.3.2 -- 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] xc3082: Fix use after free in free_firmware()
Detected by Coverity Scanner. CC: Mauro Carvalho Chehab Signed-off-by: Gregor Jasny --- utils/xc3028-firmware/firmware-tool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/xc3028-firmware/firmware-tool.c b/utils/xc3028-firmware/firmware-tool.c index b2e9de4..a7850df 100644 --- a/utils/xc3028-firmware/firmware-tool.c +++ b/utils/xc3028-firmware/firmware-tool.c @@ -86,13 +86,13 @@ static struct firmware* alloc_firmware(void) { static void free_firmware(struct firmware *f) { free(f->name); - free(f->desc); if(f->desc) { unsigned int i = 0; for(i = 0; i < f->nr_desc; ++ i) { free(f->desc[i].data); } } + free(f->desc); free(f); } -- 1.8.3.2 -- 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
[GIT PULL FOR v3.11] Various fixes for 3.11
Hi Mauro, Here is a list of fixes for 3.11. Regards, Hans The following changes since commit c859e6ef33ac0c9a5e9e934fe11a2232752b4e96: [media] dib0700: add support for PCTV 2002e & PCTV 2002e SE (2013-07-22 07:48:11 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.11 for you to fetch changes up to 9f750988a3a4e43b0262f792dc72fecd969dfeba: hdpvr: fix iteration over uninitialized lists in hdpvr_probe() (2013-07-25 14:42:45 +0200) Alexey Khoroshilov (1): hdpvr: fix iteration over uninitialized lists in hdpvr_probe() Andrzej Hajda (2): DocBook: upgrade media_api DocBook version to 4.2 v4l2: added missing mutex.h include to v4l2-ctrls.h Hans Verkuil (2): ml86v7667: fix compile warning: 'ret' set but not used usbtv: fix dependency Lubomir Rintel (2): usbtv: Fix deinterlacing usbtv: Throw corrupted frames away Documentation/DocBook/media_api.tmpl | 4 ++-- drivers/media/i2c/ml86v7667.c| 4 ++-- drivers/media/usb/hdpvr/hdpvr-core.c | 11 ++- drivers/media/usb/usbtv/Kconfig | 2 +- drivers/media/usb/usbtv/usbtv.c | 51 ++- include/media/v4l2-ctrls.h | 1 + 6 files changed, 50 insertions(+), 23 deletions(-) -- 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 1/5] media: Add support for circular graph traversal
From: Laurent Pinchart The graph traversal API (media_entity_graph_walk_*) doesn't support cyclic graphs and will fail to correctly walk a graph when circular links exist. Support circular graph traversal by checking whether an entity has already been visited before pushing it to the stack. Signed-off-by: Laurent Pinchart --- drivers/media/media-entity.c | 14 +++--- include/media/media-entity.h | 3 +++ 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c index cb30ffb..2c286c3 100644 --- a/drivers/media/media-entity.c +++ b/drivers/media/media-entity.c @@ -20,6 +20,7 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include #include #include #include @@ -121,7 +122,6 @@ static struct media_entity *stack_pop(struct media_entity_graph *graph) return entity; } -#define stack_peek(en) ((en)->stack[(en)->top - 1].entity) #define link_top(en) ((en)->stack[(en)->top].link) #define stack_top(en) ((en)->stack[(en)->top].entity) @@ -140,6 +140,12 @@ void media_entity_graph_walk_start(struct media_entity_graph *graph, { graph->top = 0; graph->stack[graph->top].entity = NULL; + bitmap_zero(graph->entities, MEDIA_ENTITY_ENUM_MAX_ID); + + if (WARN_ON(entity->id >= MEDIA_ENTITY_ENUM_MAX_ID)) + return; + + __set_bit(entity->id, graph->entities); stack_push(graph, entity); } EXPORT_SYMBOL_GPL(media_entity_graph_walk_start); @@ -180,9 +186,11 @@ media_entity_graph_walk_next(struct media_entity_graph *graph) /* Get the entity in the other end of the link . */ next = media_entity_other(entity, link); + if (WARN_ON(next->id >= MEDIA_ENTITY_ENUM_MAX_ID)) + return NULL; - /* Was it the entity we came here from? */ - if (next == stack_peek(graph)) { + /* Has the entity already been visited? */ + if (__test_and_set_bit(next->id, graph->entities)) { link_top(graph)++; continue; } diff --git a/include/media/media-entity.h b/include/media/media-entity.h index 06bacf9..0b39662 100644 --- a/include/media/media-entity.h +++ b/include/media/media-entity.h @@ -23,6 +23,7 @@ #ifndef _MEDIA_ENTITY_H #define _MEDIA_ENTITY_H +#include #include #include @@ -113,12 +114,14 @@ static inline u32 media_entity_subtype(struct media_entity *entity) } #define MEDIA_ENTITY_ENUM_MAX_DEPTH16 +#define MEDIA_ENTITY_ENUM_MAX_ID 64 struct media_entity_graph { struct { struct media_entity *entity; int link; } stack[MEDIA_ENTITY_ENUM_MAX_DEPTH]; + unsigned long entities[BITS_TO_LONGS(MEDIA_ENTITY_ENUM_MAX_ID)]; int top; }; -- 1.8.1.5 -- 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 4/5] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats
From: Laurent Pinchart NV16M and NV61M are planar YCbCr 4:2:2 and YCrCb 4:2:2 formats with a luma plane followed by an interleaved chroma plane. The planes are not required to be contiguous in memory, and the formats can only be used with the multi-planar formats API. Signed-off-by: Laurent Pinchart Reviewed-by: Sylwester Nawrocki --- Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 170 +++ Documentation/DocBook/media/v4l/pixfmt.xml | 1 + include/uapi/linux/videodev2.h | 2 + 3 files changed, 173 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml new file mode 100644 index 000..84a8bb3 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml @@ -0,0 +1,170 @@ + + + V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M ('NM61') + &manvol; + + + V4L2_PIX_FMT_NV16M + V4L2_PIX_FMT_NV61M + Variation of V4L2_PIX_FMT_NV16 and V4L2_PIX_FMT_NV61 with planes + non contiguous in memory. + + + Description + + This is a multi-planar, two-plane version of the YUV 4:2:0 format. +The three components are separated into two sub-images or planes. +V4L2_PIX_FMT_NV16M differs from V4L2_PIX_FMT_NV16 + in that the two planes are non-contiguous in memory, i.e. the chroma +plane do not necessarily immediately follows the luma plane. +The luminance data occupies the first plane. The Y plane has one byte per pixel. +In the second plane there is a chrominance data with alternating chroma samples. +The CbCr plane is the same width and height, in bytes, as the Y plane. +Each CbCr pair belongs to four pixels. For example, +Cb0/Cr0 belongs to +Y'00, Y'01, +Y'10, Y'11. +V4L2_PIX_FMT_NV61M is the same as V4L2_PIX_FMT_NV16M +except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte. + + V4L2_PIX_FMT_NV16M is intended to be +used only in drivers and applications that support the multi-planar API, +described in . + + + V4L2_PIX_FMT_NV16M 4 × 4 pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start0 + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start0 + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start0 + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start0 + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + + + start1 + 0: + Cb00 + Cr00 + Cb02 + Cr02 + + + start1 + 4: + Cb10 + Cr10 + Cb12 + Cr12 + + + start1 + 8: + Cb20 + Cr20 + Cb22 + Cr22 + + + start1 + 12: + Cb30 + Cr30 + Cb32 + Cr32 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + C + C + + + + + + 2 + YY + YY + + + + C + C + + + 3 +
[PATCH v3 0/5] Renesas VSP1 driver
Hello, Here's the third version of the VSP1 engine (a Video Signal Processor found in several Renesas R-Car SoCs) driver. I'd like to thank all the v1 and v2 reviewers. The VSP1 is a video processing engine that includes a blender, scalers, filters and statistics computation. Configurable data path routing logic allows ordering the internal blocks in a flexible way, making this driver a prime candidate for the media controller API. Due to the configurable nature of the pipeline the driver doesn't use the V4L2 mem-to-mem framework, even though the device usually operates in memory to memory mode. Only the read pixel formatters, up/down scalers, write pixel formatters and LCDC interface are supported at this stage. The patch series starts with a fix for the media controller graph traversal code, a documentation fix and new pixel format and media bus code definitions. The last patch finally adds the VSP1 driver. Changes since v1: - Updated to the v3.11 media controller API changes - Only add the LIF entity to the entities list when the LIF is present - Added a MODULE_ALIAS() - Fixed file descriptions in comment blocks - Removed function prototypes for the unimplemented destroy functions - Fixed a typo in the HST register name - Fixed format propagation for the UDS entities - Added v4l2_capability::device_caps support - Prefix the device name with "platform:" in bus_info - Zero the v4l2_pix_format priv field in the internal try format handler - Use vb2_is_busy() instead of vb2_is_streaming() when setting the format - Use the vb2_ioctl_* handlers where possible Changes since v2: - Use a bitmap to track visited entities during graph traversal - Fixed a typo in the V4L2_MBUS_FMT_ARGB888_1X32 documentation - Fix register macros that were missing a n argument - Mask unused bits when clearing the interrupt status register - Explain why stride alignment to 128 bytes is needed - Use the aligned stride value when computing the image size - Assorted cosmetic changes Laurent Pinchart (5): media: Add support for circular graph traversal v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value v4l: Add media format codes for ARGB and AYUV on 32-bit busses v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats v4l: Renesas R-Car VSP1 driver Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 170 +++ Documentation/DocBook/media/v4l/pixfmt.xml |1 + Documentation/DocBook/media/v4l/subdev-formats.xml | 611 +-- Documentation/DocBook/media_api.tmpl |6 + drivers/media/media-entity.c | 14 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|2 + drivers/media/platform/vsp1/Makefile |5 + drivers/media/platform/vsp1/vsp1.h | 73 ++ drivers/media/platform/vsp1/vsp1_drv.c | 488 + drivers/media/platform/vsp1/vsp1_entity.c | 181 drivers/media/platform/vsp1/vsp1_entity.h | 68 ++ drivers/media/platform/vsp1/vsp1_lif.c | 238 drivers/media/platform/vsp1/vsp1_lif.h | 37 + drivers/media/platform/vsp1/vsp1_regs.h| 581 ++ drivers/media/platform/vsp1/vsp1_rpf.c | 209 drivers/media/platform/vsp1/vsp1_rwpf.c| 124 +++ drivers/media/platform/vsp1/vsp1_rwpf.h| 53 + drivers/media/platform/vsp1/vsp1_uds.c | 346 ++ drivers/media/platform/vsp1/vsp1_uds.h | 40 + drivers/media/platform/vsp1/vsp1_video.c | 1135 drivers/media/platform/vsp1/vsp1_video.h | 144 +++ drivers/media/platform/vsp1/vsp1_wpf.c | 233 include/linux/platform_data/vsp1.h | 25 + include/media/media-entity.h |3 + include/uapi/linux/v4l2-mediabus.h |6 +- include/uapi/linux/videodev2.h |2 + 27 files changed, 4434 insertions(+), 371 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml create mode 100644 drivers/media/platform/vsp1/Makefile create mode 100644 drivers/media/platform/vsp1/vsp1.h create mode 100644 drivers/media/platform/vsp1/vsp1_drv.c create mode 100644 drivers/media/platform/vsp1/vsp1_entity.c create mode 100644 drivers/media/platform/vsp1/vsp1_entity.h create mode 100644 drivers/media/platform/vsp1/vsp1_lif.c create mode 100644 drivers/media/platform/vsp1/vsp1_lif.h create mode 100644 drivers/media/platform/vsp1/vsp1_regs.h create mode 100644 drivers/media/platform/vsp1/vsp1_rpf.c create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.c create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.h create mode 100644 drivers/media/platform/vsp1/vsp1_uds.c create mode 100644 drivers/media/platform/vsp1/vsp1_uds.h create mode 100644 drivers/media/platform/vsp1/vsp1_video.c create mode 100644 d
[PATCH v3 2/5] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value
From: Laurent Pinchart The V4L2_MBUS_FMT_YUV10_1X30 code is documented as being equal to 0x2014, while the v4l2-mediabus.h header defines it as 0x2016. Fix the documentation. Signed-off-by: Laurent Pinchart --- Documentation/DocBook/media/v4l/subdev-formats.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index adc6198..0c2b1f2 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2574,7 +2574,7 @@ V4L2_MBUS_FMT_YUV10_1X30 - 0x2014 + 0x2016 y9 y8 -- 1.8.1.5 -- 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 3/5] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses
From: Laurent Pinchart Signed-off-by: Laurent Pinchart Reviewed-by: Sylwester Nawrocki --- Documentation/DocBook/media/v4l/subdev-formats.xml | 609 + Documentation/DocBook/media_api.tmpl | 6 + include/uapi/linux/v4l2-mediabus.h | 6 +- 3 files changed, 254 insertions(+), 367 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 0c2b1f2..f72c1cc 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -97,31 +97,39 @@ - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier @@ -133,6 +141,14 @@ Bit + 31 + 30 + 29 + 28 + 27 + 26 + 25 + 24 23 22 21 @@ -164,7 +180,7 @@ V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE 0x1001 - &dash-ent-16; + &dash-ent-24; 0 0 0 @@ -178,7 +194,7 @@ - &dash-ent-16; + &dash-ent-24; g3 g2 g1 @@ -192,7 +208,7 @@ V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE 0x1002 - &dash-ent-16; + &dash-ent-24; g3 g2 g1 @@ -206,7 +222,7 @@ - &dash-ent-16; + &dash-ent-24; 0 0 0 @@ -220,7 +236,7 @@ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE 0x1003 - &dash-ent-16; + &dash-ent-24; 0 r4 r3 @@ -234,7 +250,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -248,7 +264,7 @@ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE 0x1004 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -262,7 +278,7 @@ - &dash-ent-16; + &dash-ent-24; 0 r4 r3 @@ -276,7 +292,7 @@ V4L2_MBUS_FMT_BGR565_2X8_BE 0x1005 - &dash-ent-16; + &dash-ent-24; b4 b3 b2 @@ -290,7 +306,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -304,7 +320,7 @@ V4L2_MBUS_FMT_BGR565_2X8_LE 0x1006 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -318,7 +334,7 @@ - &dash-ent-16; + &dash-ent-24; b4 b3 b2 @@ -332,7 +348,7 @@ V4L2_MBUS_FMT_RGB565_2X8_BE 0x1007 - &dash-ent-16; + &dash-ent-24; r4 r3 r2 @@ -346,7 +362,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -360,7 +376,7 @@ V4L2_MBUS_FMT_RGB565_2X8_LE 0x1008 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -374,7 +390,7 @@ - &dash-ent-16; + &dash-ent-24; r4 r3 r2 @@ -388,12 +404,7 @@ V4L2_MBUS_FMT_RGB666_1X18 0x1009 - - - - - - - - - - - - + &dash-ent-14; r5 r4 r3 @@ -417,6 +428,7 @@ V4L2_MBUS_FMT_RGB888_1X24 0x100a
Re: Doing a v4l-utils-1.0.0 release
Hi Gregor, On 2013-07-25 14:36, Gregor Jasny wrote: I saw your patches were merged to v4l-utils. Is there anything else you'd like to have included in a v4l-utils 1.0.0 release? Nope, that's all I wanted to have for this release. Next thing will be to work on better diseqc support but it can wait for another release. Guy -- 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] soc_camera: fix compiler warning
media_build/v4l/soc_camera.c: In function 'soc_camera_host_register': media_build/v4l/soc_camera.c:1513:10: warning: 'sasd' may be used uninitialized in this function [-Wmaybe-uninitialized] snprintf(clk_name, sizeof(clk_name), "%d-%04x", ^ media_build/v4l/soc_camera.c:1464:34: note: 'sasd' was declared here struct soc_camera_async_subdev *sasd; ^ By changing the type of 'i' to unsigned and changing a condition we finally convince the compiler that sasd is really initialized. Signed-off-by: Hans Verkuil --- drivers/media/platform/soc_camera/soc_camera.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index 2dd0e52..ed7a99f 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -1466,7 +1466,8 @@ static int scan_async_group(struct soc_camera_host *ici, struct soc_camera_device *icd; struct soc_camera_desc sdesc = {.host_desc.bus_id = ici->nr,}; char clk_name[V4L2_SUBDEV_NAME_SIZE]; - int ret, i; + unsigned int i; + int ret; /* First look for a sensor */ for (i = 0; i < size; i++) { @@ -1475,7 +1476,7 @@ static int scan_async_group(struct soc_camera_host *ici, break; } - if (i == size || asd[i]->bus_type != V4L2_ASYNC_BUS_I2C) { + if (i >= size || asd[i]->bus_type != V4L2_ASYNC_BUS_I2C) { /* All useless */ dev_err(ici->v4l2_dev.dev, "No I2C data source found!\n"); return -ENODEV; -- 1.8.3.2 -- 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: Doing a v4l-utils-1.0.0 release
Hello Guy, On 6/15/13 12:33 PM, Guy Martin wrote: Can we wait a little bit more like a week max ? I'd like to see the polarization stuff fixed because otherwise you can't use sat at all with libdvbv5. I'll work on the new patches this weekend. I'll hopefully have something today. I'll see what I can do wrt DiSEqC stuff but that can definitely wait a latter release. I saw your patches were merged to v4l-utils. Is there anything else you'd like to have included in a v4l-utils 1.0.0 release? Thanks, Gregor -- 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 01/15] drivers: phy: add generic PHY framework
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote: > I'm not saying that we can't support legacy board files with the common > PHY framework, but I'd expect things to be much easier if we focus on those > platforms that are actively being worked on for now, to bring an end to the > pointless API discussion. Well, it seemed like Greg's concerns had already been addressed anyway. signature.asc Description: Digital signature
Re: [PATCH v2 5/5] v4l: Renesas R-Car VSP1 driver
Hi Sakari, On Thursday 25 July 2013 01:48:58 Sakari Ailus wrote: > Hi Laurent, > > What a nice driver! A few minor comments below: Thank you :-) > On Wed, Jul 17, 2013 at 04:54:42PM +0200, Laurent Pinchart wrote: > ... > > > +static void vsp1_device_init(struct vsp1_device *vsp1) > > +{ > > + unsigned int i; > > + u32 status; > > + > > + /* Reset any channel that might be running. */ > > + status = vsp1_read(vsp1, VI6_STATUS); > > + > > + for (i = 0; i < VPS1_MAX_WPF; ++i) { > > + unsigned int timeout; > > + > > + if (!(status & VI6_STATUS_SYS_ACT(i))) > > + continue; > > + > > + vsp1_write(vsp1, VI6_SRESET, VI6_SRESET_SRTS(i)); > > + for (timeout = 10; timeout > 0; --timeout) { > > + status = vsp1_read(vsp1, VI6_STATUS); > > + if (!(status & VI6_STATUS_SYS_ACT(i))) > > + break; > > + > > + usleep_range(1000, 2000); > > + } > > + > > + if (timeout) > > + dev_err(vsp1->dev, "failed to reset wpf.%u\n", i); > > Have you seen this happening in practice? Do you expect the device to > function if resetting it fails? I've seen this happening during development when I had messed up register values, but not otherwise. I don't expect the deviec to still function if resetting the WPF fails, but I need to make sure that the busy loop exits. > > + } > > + > > + vsp1_write(vsp1, VI6_CLK_DCSWT, (8 << VI6_CLK_DCSWT_CSTPW_SHIFT) | > > + (8 << VI6_CLK_DCSWT_CSTRW_SHIFT)); > > + > > + for (i = 0; i < VPS1_MAX_RPF; ++i) > > + vsp1_write(vsp1, VI6_DPR_RPF_ROUTE(i), VI6_DPR_NODE_UNUSED); > > + > > + for (i = 0; i < VPS1_MAX_UDS; ++i) > > + vsp1_write(vsp1, VI6_DPR_UDS_ROUTE(i), VI6_DPR_NODE_UNUSED); > > + > > + vsp1_write(vsp1, VI6_DPR_SRU_ROUTE, VI6_DPR_NODE_UNUSED); > > + vsp1_write(vsp1, VI6_DPR_LUT_ROUTE, VI6_DPR_NODE_UNUSED); > > + vsp1_write(vsp1, VI6_DPR_CLU_ROUTE, VI6_DPR_NODE_UNUSED); > > + vsp1_write(vsp1, VI6_DPR_HST_ROUTE, VI6_DPR_NODE_UNUSED); > > + vsp1_write(vsp1, VI6_DPR_HSI_ROUTE, VI6_DPR_NODE_UNUSED); > > + vsp1_write(vsp1, VI6_DPR_BRU_ROUTE, VI6_DPR_NODE_UNUSED); > > + > > + vsp1_write(vsp1, VI6_DPR_HGO_SMPPT, (7 << VI6_DPR_SMPPT_TGW_SHIFT) | > > + (VI6_DPR_NODE_UNUSED << VI6_DPR_SMPPT_PT_SHIFT)); > > + vsp1_write(vsp1, VI6_DPR_HGT_SMPPT, (7 << VI6_DPR_SMPPT_TGW_SHIFT) | > > + (VI6_DPR_NODE_UNUSED << VI6_DPR_SMPPT_PT_SHIFT)); > > +} > > ... > > > +int vsp1_entity_init(struct vsp1_device *vsp1, struct vsp1_entity > > *entity, > > +unsigned int num_pads) > > +{ > > + static const struct { > > + unsigned int id; > > + unsigned int reg; > > + } routes[] = { > > + { VI6_DPR_NODE_LIF, 0 }, > > + { VI6_DPR_NODE_RPF(0), VI6_DPR_RPF_ROUTE(0) }, > > + { VI6_DPR_NODE_RPF(1), VI6_DPR_RPF_ROUTE(1) }, > > + { VI6_DPR_NODE_RPF(2), VI6_DPR_RPF_ROUTE(2) }, > > + { VI6_DPR_NODE_RPF(3), VI6_DPR_RPF_ROUTE(3) }, > > + { VI6_DPR_NODE_RPF(4), VI6_DPR_RPF_ROUTE(4) }, > > + { VI6_DPR_NODE_UDS(0), VI6_DPR_UDS_ROUTE(0) }, > > + { VI6_DPR_NODE_UDS(1), VI6_DPR_UDS_ROUTE(1) }, > > + { VI6_DPR_NODE_UDS(2), VI6_DPR_UDS_ROUTE(2) }, > > + { VI6_DPR_NODE_WPF(0), 0 }, > > + { VI6_DPR_NODE_WPF(1), 0 }, > > + { VI6_DPR_NODE_WPF(2), 0 }, > > + { VI6_DPR_NODE_WPF(3), 0 }, > > + }; > > + > > + unsigned int i; > > + int ret; > > + > > + for (i = 0; i < ARRAY_SIZE(routes); ++i) { > > + if (routes[i].id == entity->id) { > > + entity->route = routes[i].reg; > > + break; > > + } > > + } > > + > > + if (i == ARRAY_SIZE(routes)) > > + return -EINVAL; > > + > > + entity->vsp1 = vsp1; > > + entity->source_pad = num_pads - 1; > > + > > + /* Allocate formats and pads. */ > > + entity->formats = devm_kzalloc(vsp1->dev, > > + num_pads * sizeof(*entity->formats), > > + GFP_KERNEL); > > + if (entity->formats == NULL) > > + return -ENOMEM; > > + > > + entity->pads = devm_kzalloc(vsp1->dev, num_pads * sizeof(*entity- >pads), > > + GFP_KERNEL); > > + if (entity->pads == NULL) > > + return -ENOMEM; > > + > > + /* Initialize pads. */ > > + for (i = 0; i < num_pads - 1; ++i) > > + entity->pads[i].flags = MEDIA_PAD_FL_SINK; > > + > > + entity->pads[num_pads - 1].flags = MEDIA_PAD_FL_SOURCE; > > + > > + /* Initialize the media entity. */ > > + ret = media_entity_init(&entity->subdev.entity, num_pads, > > + entity->pads, 0); > > How about return media_entity_init(...) instead? Will do. > > + if (ret < 0) > > + return ret; > > + > > + return 0; > > +} > > ... > >
Re: [PATCH v2 3/5] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses
Hi Sylwester, On Wednesday 24 July 2013 23:26:32 Sylwester Nawrocki wrote: > On 07/17/2013 04:54 PM, Laurent Pinchart wrote: > > Signed-off-by: Laurent Pinchart > > > > --- > > > > Documentation/DocBook/media/v4l/subdev-formats.xml | 609 ++--- > > Documentation/DocBook/media_api.tmpl | 6 + > > include/uapi/linux/v4l2-mediabus.h | 6 +- > > 3 files changed, 254 insertions(+), 367 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index > > 0c2b1f2..9100674 100644 > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > @@ -97,31 +97,39 @@ > > [...] > > > + > > + V4L2_MBUS_FMT_ARGB888_1X24 > > This should be V4L2_MBUS_FMT_ARGB888_1X32, right ? Oops, indeed. > > Fix this correction feel free to add: > > Reviewed-by: Sylwester Nawrocki Thank you. > > + 0x100d > > + -- Regards, Laurent Pinchart -- 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 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Thursday 25 July 2013 13:00:49 Arnd Bergmann wrote: > On Thursday 25 July 2013, Laurent Pinchart wrote: > > On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: > > > On Tuesday 23 July 2013, Tomasz Figa wrote: > > > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > > > > > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > > > > Where would you want to have those phy_address arrays stored? > > > > > > There are no board files when booting with DT. Not even saying > > > > > > that you don't need to use any hacky schemes like this when you > > > > > > have DT that nicely specifies relations between devices. > > > > > > > > > > If everybody agrees DT has a nice scheme for specifying relations > > > > > between devices, why not use that same scheme in the PHY core? > > > > > > > > It is already used, for cases when consumer device has a DT node > > > > attached. In non-DT case this kind lookup translates loosely to > > > > something that is being done in regulator framework - you can't bind > > > > devices by pointers, because you don't have those pointers, so you > > > > need to use device names. > > > > > > Sorry for jumping in to the middle of the discussion, but why does a new > > > framework even bother defining an interface for board files? > > > > > > Can't we just drop any interfaces for platform data passing in the phy > > > framework and put the burden of adding those to anyone who actually > > > needs them? All the platforms we are concerned with here (exynos and > > > omap, plus new platforms) can be booted using DT anyway. > > > > What about non-DT architectures such as MIPS (still widely used in > > consumer networking equipments from what I've heard) ? > > * Vendors of such equipment have started moving on to ARM (e.g. Broadcom > bcm47xx) > * Some of the modern MIPS platforms are now using DT > * Legacy platforms probably won't migrate to either DT or the generic PHY > framework > > I'm not saying that we can't support legacy board files with the common PHY > framework, but I'd expect things to be much easier if we focus on those > platforms that are actively being worked on for now, to bring an end to the > pointless API discussion. Fair enough :-) -- Regards, Laurent Pinchart -- 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 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Laurent Pinchart wrote: > On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: > > On Tuesday 23 July 2013, Tomasz Figa wrote: > > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > > > > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > > > Where would you want to have those phy_address arrays stored? There > > > > > are no board files when booting with DT. Not even saying that you > > > > > don't need to use any hacky schemes like this when you have DT that > > > > > nicely specifies relations between devices. > > > > > > > > If everybody agrees DT has a nice scheme for specifying relations > > > > between devices, why not use that same scheme in the PHY core? > > > > > > It is already used, for cases when consumer device has a DT node attached. > > > In non-DT case this kind lookup translates loosely to something that is > > > being done in regulator framework - you can't bind devices by pointers, > > > because you don't have those pointers, so you need to use device names. > > > > Sorry for jumping in to the middle of the discussion, but why does a new > > framework even bother defining an interface for board files? > > > > Can't we just drop any interfaces for platform data passing in the phy > > framework and put the burden of adding those to anyone who actually needs > > them? All the platforms we are concerned with here (exynos and omap, plus > > new platforms) can be booted using DT anyway. > > What about non-DT architectures such as MIPS (still widely used in consumer > networking equipments from what I've heard) ? * Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx) * Some of the modern MIPS platforms are now using DT * Legacy platforms probably won't migrate to either DT or the generic PHY framework I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Arnd -- 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 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: > On Tuesday 23 July 2013, Tomasz Figa wrote: > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > > > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > > Where would you want to have those phy_address arrays stored? There > > > > are no board files when booting with DT. Not even saying that you > > > > don't need to use any hacky schemes like this when you have DT that > > > > nicely specifies relations between devices. > > > > > > If everybody agrees DT has a nice scheme for specifying relations > > > between devices, why not use that same scheme in the PHY core? > > > > It is already used, for cases when consumer device has a DT node attached. > > In non-DT case this kind lookup translates loosely to something that is > > being done in regulator framework - you can't bind devices by pointers, > > because you don't have those pointers, so you need to use device names. > > Sorry for jumping in to the middle of the discussion, but why does a *new* > framework even bother defining an interface for board files? > > Can't we just drop any interfaces for platform data passing in the phy > framework and put the burden of adding those to anyone who actually needs > them? All the platforms we are concerned with here (exynos and omap, plus > new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? -- Regards, Laurent Pinchart -- 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 RFC 0/5] v4l2-async DT support improvement and cleanups
Hi Guennadi, On 07/24/2013 01:36 PM, Guennadi Liakhovetski wrote: > On Mon, 22 Jul 2013, Sylwester Nawrocki wrote: >> Hello, >> >> This is a few patches for the v4l2-async API I wrote while adding >> the asynchronous subdev registration support to the exynos4-is >> driver. >> >> The most significant change is addition of V4L2_ASYNC_MATCH_OF >> subdev matching method, where host driver can pass a list of >> of_node pointers identifying its subdevs. >> >> I thought it's a reasonable and simple enough way to support device >> tree based systems. Comments/other ideas are of course welcome. > > Thanks for the patches. In principle I have nothing against them, OF > support looks good, integrating asdl into struct v4l2_subdev, dropping > redundant checks, renaming "bus" to "match look ok too. Plural vs. > singular seems to be a matter of taste to me :) But in general, provided > my single comment concerning struct forward-declaration is addressed Thanks for your review. I'm going to make that change locally, before sending a pull request with those patches. > Acked-by: Guennadi Liakhovetski -- 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 RFC 4/5] V4L2: Rename subdev field of struct v4l2_async_notifier
Hi Gueannadi, On 07/24/2013 01:26 PM, Guennadi Liakhovetski wrote: > On Mon, 22 Jul 2013, Sylwester Nawrocki wrote: > >> > This is a purely cosmetic change. Since the 'subdev' member >> > points to an array of subdevs it seems more intuitive to name >> > it in plural form. > > Well, I was aware of the fact, that "subdev" is an array and that the > plural form of "subdev" would be "subdevs" :-) It was kind of a conscious > choice. I think, both ways can be found in the kernel: using singulars and > plurals for array names. Whether one of them is better than the other - no > idea. My personal preference is somewhat with the singular form as in, say > "subdev array" instead of "subdevs array," i.e. as an adjective, but I > really don't care all that much :) Feel free to change if that's important > for you or for others on V4L :) Sorry, I expected this patch to be a bit controversial... :) I agree it might be a matter of taste, but subdev/num_subdevs pair bothered me quite a bit so I've decided to post the patch anyway. If you don't mind that much I'd like to keep that patch in this series. -- Thanks, 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 RFC 3/5] V4L2: Add V4L2_ASYNC_MATCH_OF subdev matching type
Hi Guennadi, On 07/24/2013 01:21 PM, Guennadi Liakhovetski wrote: > Hi Sylwester > > On Mon, 22 Jul 2013, Sylwester Nawrocki wrote: > >> Add support for matching by device_node pointer. This allows >> the notifier user to simply pass a list of device_node pointers >> corresponding to sub-devices. >> >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> drivers/media/v4l2-core/v4l2-async.c |9 + >> include/media/v4l2-async.h |5 + >> 2 files changed, 14 insertions(+) >> >> diff --git a/drivers/media/v4l2-core/v4l2-async.c >> b/drivers/media/v4l2-core/v4l2-async.c >> index 86934ca..9f91013 100644 >> --- a/drivers/media/v4l2-core/v4l2-async.c >> +++ b/drivers/media/v4l2-core/v4l2-async.c >> @@ -39,6 +39,11 @@ static bool match_devname(struct device *dev, struct >> v4l2_async_subdev *asd) >> return !strcmp(asd->match.device_name.name, dev_name(dev)); >> } >> >> +static bool match_of(struct device *dev, struct v4l2_async_subdev *asd) >> +{ >> +return dev->of_node == asd->match.of.node; >> +} >> + >> static LIST_HEAD(subdev_list); >> static LIST_HEAD(notifier_list); >> static DEFINE_MUTEX(list_lock); >> @@ -66,6 +71,9 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct >> v4l2_async_notifier * >> case V4L2_ASYNC_MATCH_I2C: >> match = match_i2c; >> break; >> +case V4L2_ASYNC_MATCH_OF: >> +match = match_of; >> +break; >> default: >> /* Cannot happen, unless someone breaks us */ >> WARN_ON(true); >> @@ -145,6 +153,7 @@ int v4l2_async_notifier_register(struct v4l2_device >> *v4l2_dev, >> case V4L2_ASYNC_MATCH_CUSTOM: >> case V4L2_ASYNC_MATCH_DEVNAME: >> case V4L2_ASYNC_MATCH_I2C: >> +case V4L2_ASYNC_MATCH_OF: >> break; >> default: >> dev_err(notifier->v4l2_dev ? notifier->v4l2_dev->dev : >> NULL, >> diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h >> index 33e3b2a..295782e 100644 >> --- a/include/media/v4l2-async.h >> +++ b/include/media/v4l2-async.h >> @@ -13,6 +13,7 @@ >> >> #include >> #include >> +#include >> >> struct device; >> struct v4l2_device; > > A nitpick: it is common to just forward-declare structs as above instead > of including a header if just a pointer to that struct is needed. I think > it would be more consistent to update it here. Sure, I will make this change before sending the pull request. I wasn't really sure which way is better. -- 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 RFC 0/5] v4l2-async DT support improvement and cleanups
On 07/24/2013 12:16 PM, Hans Verkuil wrote: > On Mon 22 July 2013 20:04:42 Sylwester Nawrocki wrote: >> Hello, >> >> This is a few patches for the v4l2-async API I wrote while adding >> the asynchronous subdev registration support to the exynos4-is >> driver. >> >> The most significant change is addition of V4L2_ASYNC_MATCH_OF >> subdev matching method, where host driver can pass a list of >> of_node pointers identifying its subdevs. >> >> I thought it's a reasonable and simple enough way to support device >> tree based systems. Comments/other ideas are of course welcome. > > Looks good! > > Acked-by: Hans Verkuil Thank you for the review, Hans. We can always be sure nothing miss your eye ;) -- 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 RFC 0/5] v4l2-async DT support improvement and cleanups
Hi Laurent, On 07/24/2013 12:06 PM, Laurent Pinchart wrote: > Hi Sylwester, > > Thanks for the patches. > > On Monday 22 July 2013 20:04:42 Sylwester Nawrocki wrote: >> Hello, >> >> This is a few patches for the v4l2-async API I wrote while adding >> the asynchronous subdev registration support to the exynos4-is >> driver. >> >> The most significant change is addition of V4L2_ASYNC_MATCH_OF >> subdev matching method, where host driver can pass a list of >> of_node pointers identifying its subdevs. >> >> I thought it's a reasonable and simple enough way to support device tree >> based systems. Comments/other ideas are of course welcome. > > I have similar patches in my tree that I haven't posted yet, so I like the > idea :-) For the whole series, Hm, what a coincidence :-) Thank you for the review. > Acked-by: Laurent Pinchart -- 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 01/15] drivers: phy: add generic PHY framework
On 07/24/2013 08:32 PM, Arnd Bergmann wrote: > On Tuesday 23 July 2013, Tomasz Figa wrote: >> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: >>> On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. >>> >>> If everybody agrees DT has a nice scheme for specifying relations >>> between devices, why not use that same scheme in the PHY core? >> >> It is already used, for cases when consumer device has a DT node attached. >> In non-DT case this kind lookup translates loosely to something that is >> being done in regulator framework - you can't bind devices by pointers, >> because you don't have those pointers, so you need to use device names. >> > > Sorry for jumping in to the middle of the discussion, but why does a *new* > framework even bother defining an interface for board files? > > Can't we just drop any interfaces for platform data passing in the phy > framework and put the burden of adding those to anyone who actually needs > them? All the platforms we are concerned with here (exynos and omap, > plus new platforms) can be booted using DT anyway. Indeed, I was also a bit surprised we still need non-dt support, since migration to this generic PHY framework in case of exynos was solely part of migration of the whole platform to DT. Two of the drivers that are being converted are also used on s5pv210, but there is currently no boards in mainline that would use devices covered by those drivers and s5pv210 will very likely get DT support in v3.13 anyway. But it seems omap still needs non-dt support in the PHY framework. --- Thanks, 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 01/15] drivers: phy: add generic PHY framework
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote: > Sorry for jumping in to the middle of the discussion, but why does a *new* > framework even bother defining an interface for board files? > Can't we just drop any interfaces for platform data passing in the phy > framework and put the burden of adding those to anyone who actually needs > them? All the platforms we are concerned with here (exynos and omap, > plus new platforms) can be booted using DT anyway. There's a bunch of non-DT architectures that are in active use (blackfin for example) and I'd really hope that this is useful for some of them. The pushback here was about the fact that the subsystem was doing odd things with selecting device names which is odd in itself, I don't know if that had bled over into the DT bindings but it sounded like it might've done so. signature.asc Description: Digital signature
Re: UVC and V4L2_CAP_AUDIO
Hi Hans, On Thursday 25 July 2013 11:03:13 Hans Verkuil wrote: > Hi Laurent, > > While working on adding alsa streaming support to qv4l2 we noticed that uvc > doesn't set this capability telling userspace that the webcam supports > audio. > > Is it possible at all in the uvc driver to determine whether or not a uvc > webcam has a microphone? Not without dirty hacks. The UVC interfaces don't report whether the device has an audio function, the driver would need to look at all the interfaces of the parent USB device and find out whether they match one of the USB audio drivers. That's not something I would be inclined to merge in the uvcvideo driver. > If not, then it looks like the only way to find the associated alsa device > is to use libmedia_dev (or its replacement, although I wonder if anyone is > still working on that). I need to post the code I have. I'll try to do that next week. > And in particular, the presence of CAP_AUDIO cannot be used to determine > whether the device has audio capabilities, it can only be used to determine > if the V4L2 audio ioctls are supported. That would have to be clarified in > the spec. The V4L2 audio ioctls are definitely not supported by the uvcvideo driver :-) -- Regards, Laurent Pinchart -- 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
UVC and V4L2_CAP_AUDIO
Hi Laurent, While working on adding alsa streaming support to qv4l2 we noticed that uvc doesn't set this capability telling userspace that the webcam supports audio. Is it possible at all in the uvc driver to determine whether or not a uvc webcam has a microphone? If not, then it looks like the only way to find the associated alsa device is to use libmedia_dev (or its replacement, although I wonder if anyone is still working on that). And in particular, the presence of CAP_AUDIO cannot be used to determine whether the device has audio capabilities, it can only be used to determine if the V4L2 audio ioctls are supported. That would have to be clarified in the spec. Regards, Hans -- 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 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Kishon Vijay Abraham I wrote: > On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote: > > On Tuesday 23 July 2013, Tomasz Figa wrote: > >> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > >>> On Tue, 23 Jul 2013, Tomasz Figa wrote: > Where would you want to have those phy_address arrays stored? There > are no board files when booting with DT. Not even saying that you > don't need to use any hacky schemes like this when you have DT that > nicely specifies relations between devices. > >>> > >>> If everybody agrees DT has a nice scheme for specifying relations > >>> between devices, why not use that same scheme in the PHY core? > >> > >> It is already used, for cases when consumer device has a DT node attached. > >> In non-DT case this kind lookup translates loosely to something that is > >> being done in regulator framework - you can't bind devices by pointers, > >> because you don't have those pointers, so you need to use device names. > >> > > > > Sorry for jumping in to the middle of the discussion, but why does a new > > framework even bother defining an interface for board files? > > > > Can't we just drop any interfaces for platform data passing in the phy > > framework and put the burden of adding those to anyone who actually needs > > them? All the platforms we are concerned with here (exynos and omap, > > plus new platforms) can be booted using DT anyway. > > The OMAP3 platforms still needs to be supported for non-dt :-s Can't you leave the existing PHY handling for legacy OMAP3 USB PHY until they are all converted? I don't expect that to take a long time now that the OMAP4 board files have been removed. Are there still drivers without DT bindings that hold up the removal of the OMAP3 board files? Otherwise I'd suggest delaying the phy subsystem by another merge window, until that is resolved. Arnd -- 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] smiapp: re-use clamp_t instead of min(..., max(...))
On Wed, Jul 24, 2013 at 6:55 PM, Sakari Ailus wrote: > On Wed, Jul 24, 2013 at 06:49:24PM +0300, Andy Shevchenko wrote: >> On Wed, Jul 24, 2013 at 6:45 PM, Sakari Ailus wrote: >> >> [] >> >> >> + max_m = clamp_t(u32, max_m, >> >> sensor->limits[SMIAPP_LIMIT_SCALER_M_MIN], >> >> + sensor->limits[SMIAPP_LIMIT_SCALER_M_MAX]); >> > >> > Do you need clamp_t()? Wouldn't plain clamp() do? >> >> The *_t variants are preferred due to they are faster (no type checking). >> >> > I can change it if you're ok with that. >> >> I don't know why you may choose clamp instead of clamp_t here. Are you >> going to change variable types? > > Probably not. But clamp() would serve as a sanity check vs. clamp_t() which > just does the thing. I'd prefer clamp() You may adjust original patch if you want. -- With Best Regards, Andy Shevchenko -- 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] ml86v7667: override default field interlace order
Hi Vladimir, From: Sergei Shtylyov Subject: [PATCH] ml86v7667: override default field interlace order Date: Mon, 15 Jul 2013 23:12:21 +0400 > From: Vladimir Barinov > > ML86V7667 always transmits top field first for both PAL and NTSC -- that > makes > application incorrectly treat interlaced fields when relying on the > standard. > Hence we must set V4L2_FIELD_INTERLACED_TB format explicitly. > > Reported-by: Katsuya MATSUBARA > Signed-off-by: Vladimir Barinov > [Sergei: added a comment.] > Signed-off-by: Sergei Shtylyov (snip) I made sure that it works well on the Renesas BOCK-W board. Tested-by: Katsuya MATSUBARA --- Katsuya Matsubara / IGEL Co., Ltd ma...@igel.co.jp -- 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 v8] V4L2: soc_camera: Renesas R-Car VIN driver
Hi Vladimir, From: Vladimir Barinov Date: Thu, 25 Jul 2013 10:55:51 +0400 > Hi Matsubara-san, > > On 07/25/2013 07:01 AM, Katsuya MATSUBARA wrote: >> Hi Vladimir, >> >> Thank you for the revised patch. >> >> From: Sergei Shtylyov >> Date: Sat, 20 Jul 2013 03:14:34 +0400 >> >>> From: Vladimir Barinov >>> >>> Add Renesas R-Car VIN (Video In) V4L2 driver. >>> >>> Based on the patch by Phil Edworthy. >>> >>> Signed-off-by: Vladimir Barinov >>> [Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed >>> 'enum chip_id' >>> values, reordered rcar_vin_id_table[] entries, removed senseless >>> parens from >>> to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} >>> to the >>> *if* statement and used 'bool' values instead of 0/1 where necessary, >>> *removed >>> unused macros, done some reformatting and clarified some comments.] >>> Signed-off-by: Sergei Shtylyov >>> >>> --- >>> This patch is against the 'media_tree.git' repo. >>> >>> Changes since version 7: >>> - remove 'icd' field from 'struct rcar_vin_priv' in accordance with the >>> - commit >>>f7f6ce2d09c86bd80ee11bd654a1ac1e8f5dfe13 ([media] soc-camera: move >>>common code >>>to soc_camera.c); >>> - added mandatory clock_{start|stop}() methods in accordance with the >>> - commit >>>a78fcc11264b824d9651b55abfeedd16d5cd8415 ([media] soc-camera: make >>>.clock_ >>>{start,stop} compulsory, .add / .remove optional). >> From: Vladimir Barinov >> Subject: Re: [PATCH v6] V4L2: soc_camera: Renesas R-Car VIN driver >> Date: Sat, 22 Jun 2013 15:45:10 +0400 >> But, captured images are still incorrect that means wrong order of fields desite '_BT' chosen for V4L2_STD_525_60. >>> I've ordered the NTSC camera. >>> I will return once I get it. >> Did you get an NTSC camera and see the field order issue >> occurs on your BOCK-W board? > Yes I did. >> You may want to consider adding a workaround into >> the VIN driver if the issue remains in the latest patch. > Have you seen this patch https://linuxtv.org/patch/19278/ ? Oh, I missed the mail. I tested it now and confirmed the issue has gone! Thank you for fixing it. --- Katsuya Matsubara / IGEL Co., Ltd ma...@igel.co.jp -- 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