kernel/linux.git/include/media, branch linux-4.20.y

media: cec: keep track of outstanding transmits

2019-01-09T16:46:01+00:00

commit 32804fcb612bf867034a093f459415e485cf044b upstream. I noticed that repeatedly running 'cec-ctl --playback' would occasionally select 'Playback Device 2' instead of 'Playback Device 1', even though there were no other Playback devices in the HDMI topology. This happened both with 'real' hardware and with the vivid CEC emulation, suggesting that this was an issue in the core code that claims a logical address. What 'cec-ctl --playback' does is to first clear all existing logical addresses, and immediately after that configure the new desired device type. The core code will poll the logical addresses trying to find a free address. When found it will issue a few standard messages as per the CEC spec and return. Those messages are queued up and will be transmitted asynchronously. What happens is that if you run two 'cec-ctl --playback' commands in quick succession, there is still a message of the first cec-ctl command being transmitted when you reconfigure the adapter again in the second cec-ctl command. When the logical addresses are cleared, then all information about outstanding transmits inside the CEC core is also cleared, and the core is no longer aware that there is still a transmit in flight. When the hardware finishes the transmit it calls transmit_done and the CEC core thinks it is actually in response of a POLL messages that is trying to find a free logical address. The result of all this is that the core thinks that the logical address for Playback Device 1 is in use, when it is really an earlier transmit that ended. The main transmit thread looks at adap->transmitting to check if a transmit is in progress, but that is set to NULL when the adapter is unconfigured. adap->transmitting represents the view of userspace, not that of the hardware. So when unconfiguring the adapter the message is marked aborted from the point of view of userspace, but seen from the PoV of the hardware it is still ongoing. So introduce a new bool transmit_in_progress that represents the hardware state and use that instead of adap->transmitting. Now the CEC core waits until the hardware finishes the transmit before starting a new transmit. Signed-off-by: Hans Verkuil Cc: # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: mpeg2-ctrls.h: move MPEG2 state controls to non-public header

2018-12-05T18:06:31+00:00

The MPEG2 state controls for the cedrus stateless MPEG2 driver are not yet stable. Move them out of the public headers into media/mpeg2-ctrls.h. Eventually, once this has stabilized, they will be moved back to the public headers. Unfortunately I had to cast the control type to a u32 in two switch statements to prevent a compiler warning about a control type define not being part of the enum. Signed-off-by: Hans Verkuil Reviewed-by: Paul Kocialkowski Signed-off-by: Mauro Carvalho Chehab

media: vb2: keep a reference to the request until dqbuf

2018-12-03T20:02:22+00:00

When vb2_buffer_done is called the buffer is unbound from the request and put. The media_request_object_put also 'put's the request reference. If the application has already closed the request fd, then that means that the request reference at that point goes to 0 and the whole request is released. This means that the control handler associated with the request is also freed and that causes this kernel oops: [174705.995401] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908 [174705.995411] in_atomic(): 1, irqs_disabled(): 1, pid: 28071, name: vivid-000-vid-o [174705.995416] 2 locks held by vivid-000-vid-o/28071: [174705.995420] #0: 000000001ea3a232 (&dev->mutex#3){....}, at: vivid_thread_vid_out+0x3f5/0x550 [vivid] [174705.995447] #1: 00000000e30a0d1e (&(&q->done_lock)->rlock){....}, at: vb2_buffer_done+0x92/0x1d0 [videobuf2_common] [174705.995460] Preemption disabled at: [174705.995461] [<0000000000000000>] (null) [174705.995472] CPU: 11 PID: 28071 Comm: vivid-000-vid-o Tainted: G W 4.20.0-rc1-test-no #88 [174705.995476] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 [174705.995481] Call Trace: [174705.995500] dump_stack+0x46/0x60 [174705.995512] ___might_sleep.cold.79+0xe1/0xf1 [174705.995523] __mutex_lock+0x50/0x8f0 [174705.995531] ? find_held_lock+0x2d/0x90 [174705.995536] ? find_held_lock+0x2d/0x90 [174705.995542] ? find_held_lock+0x2d/0x90 [174705.995564] ? v4l2_ctrl_handler_free.part.13+0x44/0x1d0 [videodev] [174705.995576] v4l2_ctrl_handler_free.part.13+0x44/0x1d0 [videodev] [174705.995590] v4l2_ctrl_request_release+0x1c/0x30 [videodev] [174705.995600] media_request_clean+0x64/0xe0 [media] [174705.995609] media_request_release+0x19/0x40 [media] [174705.995617] vb2_buffer_done+0xef/0x1d0 [videobuf2_common] [174705.995630] vivid_thread_vid_out+0x2c1/0x550 [vivid] [174705.995645] ? vivid_stop_generating_vid_cap+0x1c0/0x1c0 [vivid] [174705.995653] kthread+0x113/0x130 [174705.995659] ? kthread_park+0x80/0x80 [174705.995667] ret_from_fork+0x35/0x40 The vb2_buffer_done function can be called from interrupt context, so anything that sleeps is not allowed. The solution is to increment the request refcount when the buffer is queued and decrement it when the buffer is dequeued. Releasing the request is fine if that happens from VIDIOC_DQBUF. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: Use wait_queue_head_t for media_request

2018-11-20T17:53:23+00:00

The portable type for a wait queue is wait_queue_head_t. Signed-off-by: Jasmin Jessich Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: Rename vb2_m2m_request_queue -> v4l2_m2m_request_queue

2018-11-06T10:24:22+00:00

To be consistent with the rest of the mem2mem helpers, rename vb2_m2m_request_queue to v4l2_m2m_request_queue. This is just a cosmetic change. Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

Merge tag 'media/v4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2018-10-31T17:53:29+00:00

Pull new experimental media request API from Mauro Carvalho Chehab: "A new media request API This API is needed to support device drivers that can dynamically change their parameters for each new frame. The latest versions of Google camera and codec HAL depends on such feature. At this stage, it supports only stateless codecs. It has been discussed for a long time (at least over the last 3-4 years), and we finally reached to something that seem to work. This series contain both the API and core changes required to support it and a new m2m decoder driver (cedrus). As the current API is still experimental, the only real driver using it (cedrus) was added at staging[1]. We intend to keep it there for a while, in order to test the API. Only when we're sure that this API works for other cases (like encoders), we'll move this driver out of staging and set the API into a stone. [1] We added support for the vivid virtual driver (used only for testing) to it too, as it makes easier to test the API for the ones that don't have the cedrus hardware" * tag 'media/v4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (53 commits) media: dt-bindings: Document the Rockchip VPU bindings media: platform: Add Cedrus VPU decoder driver media: dt-bindings: media: Document bindings for the Cedrus VPU driver media: v4l: Add definition for the Sunxi tiled NV12 format media: v4l: Add definitions for MPEG-2 slice format and metadata media: videobuf2-core: Rework and rename helper for request buffer count media: v4l2-ctrls.c: initialize an error return code with zero media: v4l2-compat-ioctl32.c: add missing documentation for a field media: media-request: update documentation media: media-request: EPERM -> EACCES/EBUSY media: v4l2-ctrls: improve media_request_(un)lock_for_update media: v4l2-ctrls: use media_request_(un)lock_for_access media: media-request: add media_request_(un)lock_for_access media: vb2: set reqbufs/create_bufs capabilities media: videodev2.h: add new capabilities for buffer types media: buffer.rst: only set V4L2_BUF_FLAG_REQUEST_FD for QBUF media: v4l2-ctrls: return -EACCES if request wasn't completed media: media-request: return -EINVAL for invalid request_fds media: vivid: add request support media: vivid: add mc ...

Merge tag 'media/v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2018-10-29T21:29:58+00:00

Pull media updates from Mauro Carvalho Chehab: - new dvb frontend driver: lnbh29 - new sensor drivers: imx319 and imx 355 - some old soc_camera driver renames to avoid conflict with new drivers - new i.MX Pixel Pipeline (PXP) mem-to-mem platform driver - a new V4L2 frontend for the FWHT codec - several other improvements, bug fixes, code cleanups, etc * tag 'media/v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (289 commits) media: rename soc_camera I2C drivers media: cec: forgot to cancel delayed work media: vivid: Support 480p for webcam capture media: v4l2-tpg: fix kernel oops when enabling HFLIP and OSD media: vivid: Add 16-bit bayer to format list media: v4l2-tpg-core: Add 16-bit bayer media: pvrusb2: replace `printk` with `pr_*` media: venus: vdec: fix decoded data size media: cx231xx: fix potential sign-extension overflow on large shift media: dt-bindings: media: rcar_vin: add device tree support for r8a7744 media: isif: fix a NULL pointer dereference bug media: exynos4-is: make const array config_ids static media: cx23885: make const array addr_list static media: ivtv: make const array addr_list static media: bttv-input: make const array addr_list static media: cx18: Don't check for address of video_dev media: dw9807-vcm: Fix probe error handling media: dw9714: Remove useless error message media: dw9714: Fix error handling in probe function media: cec: name for RC passthrough device does not need 'RC for' ...

media: cec: name for RC passthrough device does not need 'RC for'

2018-10-05T15:28:13+00:00

An RC device is does not need to be called 'RC for'. Simply the name will suffice. Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: cec: fix the Signal Free Time calculation

2018-10-05T15:27:15+00:00

The calculation of the Signal Free Time in the framework was not correct. If a message was received, then the next transmit should be considered a New Initiator and use a shorter SFT value. This was not done with the result that if both sides where continually sending messages, they both could use the same SFT value and one side could deny the other side access to the bus. Note that this fix does not take the corner case into account where a receive is in progress when you call adap_transmit. Signed-off-by: Hans Verkuil Cc: # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab

media: v4l: ctrl: Provide unlocked variant of v4l2_ctrl_grab

2018-10-05T13:37:45+00:00

Sometimes it may be necessary to grab a control while holding the control handler's lock. Provide an unlocked variant of v4l2_ctrl_grab for the purpose --- it's called __v4l2_ctrl_grab. Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab