Re: [RFC PATCH 0/5] vb2/cedrus: add cookie support
Hi Hans, On Fri, Nov 9, 2018 at 6:56 PM Hans Verkuil wrote: > > As was discussed here (among other places): > > https://lkml.org/lkml/2018/10/19/440 > > using capture queue buffer indices to refer to reference frames is > not a good idea. A better idea is to use 'cookies' (a better name is > welcome!) Maybe "tag" is more common for that kind of usage, but "cookie" is fine as well IMHO. I can only comment on patches 1-4, but so far it seems to me that this would work. I will use this to base the next stateless codec API RFC. Thanks! Alex.
Re: [RFC PATCH 1/5] videodev2.h: add cookie support
On Fri, Nov 9, 2018 at 6:56 PM Hans Verkuil wrote: > > From: Hans Verkuil > > Add support for 'cookies' to struct v4l2_buffer. These can be used to This "to" seems unneeded.
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: Mon Nov 12 05:00:10 CET 2018 media-tree git hash:fbe57dde7126d1b2712ab5ea93fb9d15f89de708 media_build git hash: a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1 v4l-utils git hash: dd3ff81f58c4e1e6f33765dc61ad33c48ae6bb07 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: WARNINGS linux-git-arm-stm32: WARNINGS linux-git-arm64: WARNINGS linux-git-i686: WARNINGS linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-sh: OK linux-git-x86_64: WARNINGS Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
On 11/09/2018 06:09 PM, Sakari Ailus wrote: > Hi Bing Bu, > > On Wed, Nov 07, 2018 at 12:16:47PM +0800, Bing Bu Cao wrote: >> On 11/01/2018 08:03 PM, Sakari Ailus wrote: >>> Hi Yong, >>> >>> Thanks for the update! >>> >>> On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote: Hi, This series adds support for the Intel IPU3 (Image Processing Unit) ImgU which is essentially a modern memory-to-memory ISP. It implements raw Bayer to YUV image format conversion as well as a large number of other pixel processing algorithms for improving the image quality. Meta data formats are defined for image statistics (3A, i.e. automatic white balance, exposure and focus, histogram and local area contrast enhancement) as well as for the pixel processing algorithm parameters. The documentation for these formats is currently not included in the patchset but will be added in a future version of this set. The algorithm parameters need to be considered specific to a given frame and typically a large number of these parameters change on frame to frame basis. Additionally, the parameters are highly structured (and not a flat space of independent configuration primitives). They also reflect the data structures used by the firmware and the hardware. On top of that, the algorithms require highly specialized user space to make meaningful use of them. For these reasons it has been chosen video buffers to pass the parameters to the device. On individual patches: The heart of ImgU is the CSS, or Camera Subsystem, which contains the image processors and HW accelerators. The 3A statistics and other firmware parameter computation related functions are implemented in patch 11. All IPU3 pipeline default settings can be found in patch 10. To access DDR via ImgU's own memory space, IPU3 is also equipped with its own MMU unit, the driver is implemented in patch 6. Patch 7 uses above driver for DMA mapping operation. The communication between IPU3 firmware and driver is implemented with circular queues in patch 8. Patch 9 provide some utility functions and manage IPU3 fw download and install. The firmware which is called ipu3-fw.bin can be downloaded from: git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git (commit 2c27b0cb02f18c022d8378e0e1abaf8b7ae8188f) Firmware ABI is defined in patches 4 and 5. Patches 12 and 13 are of the same file, the former contains all h/w programming related code, the latter implements interface functions for access fw & hw capabilities. Patch 14 has a dependency on Sakari's V4L2_BUF_TYPE_META_OUTPUT work: https://patchwork.kernel.org/patch/9976295/> >>> I've pushed the latest set here: >>> >>> https://git.linuxtv.org/sailus/media_tree.git/log/?h=meta-output> >>> >>> You can just say the entire set depends on those going forward; the >>> documentation is needed, too. >>> Patch 15 represents the top level that glues all of the other components together, passing arguments between the components. Patch 16 is a recent effort to extend v6 for advanced camera features like Continuous View Finder (CVF) and Snapshot During Video(SDV) support. Link to user space implementation: git clone https://chromium.googlesource.com/chromiumos/platform/arc-camera ImgU media topology print: # media-ctl -d /dev/media0 -p Media controller API version 4.19.0 Media device information driver ipu3-imgu model ipu3-imgu serial bus infoPCI::00:05.0 hw revision 0x80862015 driver version 4.19.0 Device topology - entity 1: ipu3-imgu 0 (5 pads, 5 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 pad0: Sink [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown >>> This doesn't seem right. Which formats can be enumerated from the pad? > Looking at the code, the OUTPUT video nodes have 10-bit GRBG (or a variant) > format whereas the CAPTURE video nodes always have NV12. Can you confirm? Hi, Sakari, Yes, I think the pad_fmt should also be changed. Yong, could you add some extra code for this and test? like: static int ipu3_v4l2_node_setup(struct imgu_device *imgu, unsigned int pipe, ... V4L2_PIX_FMT_NV12; node->vdev_fmt.fmt.pix_mp = def_pix_fmt; } + if (node->vdev_fmt.type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) + node->pad_fmt.code = MEDIA_BUS_FMT_SGRBG10_1X10; + > > If the OUTPUT video node format selection has no effect on the rest of the > pipeline (device capabilities,
Re: TechnoTrend CT2-4500 remote not working
On Sat, Nov 10, 2018 at 10:35:29PM +0100, martin.kono...@mknetz.de wrote: > Hi all, > > the remote on my TechnoTrend CT2-4500 is not working with kernel 4.18. > The TV-card itself works fine: > > cx25840 6-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) > cx23885: cx23885_dvb_register() allocating 1 frontend(s) > cx23885: cx23885[0]: cx23885 based dvb card > i2c i2c-5: Added multiplexed i2c bus 12 > si2168 5-0064: Silicon Labs Si2168-B40 successfully identified > si2168 5-0064: firmware version: B 4.0.2 > si2157 12-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached > dvbdev: DVB: registering new adapter (cx23885[0]) > cx23885 :17:00.0: DVB: registering adapter 0 frontend 0 (Silicon > Labs Si2168)... > sp2 4-0040: CIMaX SP2 successfully attached > cx23885: Technotrend TT-budget CT2-4500 CI MAC address: bc:ea:2b:45:05:68 > cx23885: cx23885_dev_checkrevision() Hardware revision = 0xa5 > cx23885: cx23885[0]/0: found at :17:00.0, rev: 4, irq: 31, latency: > 0, mmio: 0xfe00 > > > The remote is registered: > > Registered IR keymap rc-fusionhdtv-mce > rc rc0: FusionHDTV as > /devices/pci:00/:00:01.2/:15:00.2/:16:00.0/:17:00.0/i2c-4/4-006b/rc/rc0 > input: FusionHDTV as > /devices/pci:00/:00:01.2/:15:00.2/:16:00.0/:17:00.0/i2c-4/4-006b/rc/rc0/input18 > rc rc0: lirc_dev: driver ir_kbd_i2c registered at minor = 0, scancode > receiver, no transmitter > > ir-keytable reports: > > Found /sys/class/rc/rc0/ (/dev/input/event15) with: > Name: FusionHDTV > Driver: ir_kbd_i2c, table: rc-fusionhdtv-mce > lirc device: /dev/lirc0 > Supported protocols: unknown > Enabled protocols: unknown > bus: 24, vendor/product: :, version: 0x > Repeat delay = 500 ms, repeat period = 125 ms > > Apparently, no protocols are reported. It support a protocol, we don't know what it is, so it's called unknown. > evtest on /dev/input/event15 reports no events. That's a valid test. You can also use "ir-keytable -t". > The error was reported before: > > http://lirc.10951.n7.nabble.com/Problems-with-cx23885-IR-receiver-td10884.html > > The remote is working, I verified it with a camera. It would be interesting to see what the device is sending. Please can you turn on dynamic debug for ir-kbd-i2c.c: echo "file ir-kbd-i2.c +p" > /sys/kernel/debug/dynamic_debug/control Try the remote again and report what in the kernel messages. Sean
Re: [PATCH v5 0/5] Make sure .device_run is always called in non-atomic context
On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote: > This series goal is to avoid drivers from having ad-hoc code > to call .device_run in non-atomic context. Currently, .device_run > can be called via v4l2_m2m_job_finish(), not only running > in interrupt context, but also creating a nasty re-entrant > path into mem2mem drivers. > > The proposed solution is to add a per-device worker that is scheduled > by v4l2_m2m_job_finish, which replaces drivers having a threaded interrupt > or similar. > > This change allows v4l2_m2m_job_finish() to be called in interrupt > context, separating .device_run and v4l2_m2m_job_finish() contexts. > > It's worth mentioning that v4l2_m2m_cancel_job() doesn't need > to flush or cancel the new worker, because the job_spinlock > synchronizes both and also because the core prevents simultaneous > jobs. Either v4l2_m2m_cancel_job() will wait for the worker, or the > worker will be unable to run a new job. > > Patches apply on top of Request API and the Cedrus VPU > driver. > > Tested with cedrus driver using v4l2-request-test and > vicodec driver using gstreamer. > > Ezequiel Garcia (4): > mem2mem: Require capture and output mutexes to match > v4l2-ioctl.c: Simplify locking for m2m devices > v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish > media: cedrus: Get rid of interrupt bottom-half > > Sakari Ailus (1): > v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule > > drivers/media/v4l2-core/v4l2-ioctl.c | 47 + > drivers/media/v4l2-core/v4l2-mem2mem.c| 66 --- > .../staging/media/sunxi/cedrus/cedrus_hw.c| 26 ++-- > 3 files changed, 51 insertions(+), 88 deletions(-) > Hans, Maxime: Any feedback for this? Thanks, Eze
RE,
Hello, My Name is Juliet Muhammad from Turkey, I very happy to contact you because i want to be your friend and business partner hope you don't mind writing me back I came across your e-mail contact prior a private search while in need of your assistance.
