summaryrefslogtreecommitdiff
path: root/include/media
AgeCommit message (Collapse)AuthorFilesLines
2021-01-07media: v4l: common: Fix naming of v4l2_get_link_rateSakari Ailus1-2/+2
Rename v4l2_get_link_rate() as v4l2_get_link_freq(). What the function returns is the frequency of the link; rename it to reflect the name of the control where the information is obtained. Fixes: 1b888b3cebef ("media: v4l: Add a helper for obtaining the link frequency") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: rc: add keymap for pine64 remoteJonas Karlman1-0/+1
Add a keymap for the pine64 IR remote [0]. The mouse key has been mapped to KEY_EPG to provide a more useful remote. [0] http://files.pine64.org/doc/Pine%20A64%20Schematic/remote-wit-logo.jpg Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-03media: vicodec: mark the stateless FWHT API as stableHans Verkuil2-32/+0
The FWHT stateless 'uAPI' was staging and marked explicitly in the V4L2 specification that it will change and is unstable. Note that these control IDs were never exported as a public API, they were only defined in kernel-local headers (fwht-ctrls.h). Now, the FWHT stateless controls is ready to be part of the stable uAPI. While not too late: - Rename V4L2_CID_MPEG_VIDEO_FWHT_PARAMS to V4L2_CID_STATELESS_FWHT_PARAMS. - Move the contents of fwht-ctrls.h to v4l2-controls.h. - Move the public parts of drivers/media/test-drivers/vicodec/codec-fwht.h to v4l2-controls.h. - Add V4L2_CTRL_TYPE_FWHT_PARAMS control initialization and validation. - Add p_fwht_params to struct v4l2_ext_control. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-03media: uapi: move H264 stateless controls out of stagingEzequiel Garcia2-405/+0
The H.264 stateless 'uAPI' was staging and marked explicitly in the V4L2 specification that it will change and is unstable. Note that these control IDs were never exported as a public API, they were only defined in kernel-local headers (h264-ctrls.h). Now, the H264 stateless controls is ready to be part of the stable uAPI. While not too late, let's rename them and re-number their control IDs, moving them to the newly created stateless control class, and updating all the drivers accordingly. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-03media: uapi: Move the H264 stateless control types out of stagingEzequiel Garcia1-8/+0
Move the H264 stateless control types out of staging, and re-number them to avoid any confusion. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-03media: uapi: Move parsed H264 pixel format out of stagingEzequiel Garcia1-3/+0
Since we are ready to stabilize the H264 stateless API, start by first moving the parsed H264 pixel format. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-03media: controls: Validate H264 stateless controlsEzequiel Garcia1-0/+9
Check that all the fields that correspond or are related to a H264 specification syntax element have legal values. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-03media: Clean stateless control includesEzequiel Garcia1-1/+1
Avoid including h264-ctrls.h, vp8-ctrls.h, etc, and instead just include v4l2-ctrls.h which does the right thing. This is in preparation for moving the stateless controls out of staging, which will mean removing some of these headers. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-03media: Rename stateful codec control macrosEzequiel Garcia5-17/+17
For historical reasons, stateful codec controls are named as {}_MPEG_{}. While we can't at this point sanely change all control IDs (such as V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER), we can least change the more meaningful macros such as classes macros. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-03media: uapi: Expose VP8 probability lengths as definesEmmanuel Gil Peyrot1-2/+4
These values will be used by various drivers implementing the VP8 stateless API. This had been suggested by Ezequiel Garcia for the Cedrus VP8 driver. Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-02media: v4l2-fwnode: Remove v4l2_async_notifier_parse_fwnode_endpoints_by_port()Niklas Söderlund1-53/+0
There are no users left of this helper and as it implements an undesirable and too simple behaviour that should instead be implemented directly by drivers remove it to prevent future uses of it. Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: rc: add keymap for KHAMSIN remoteChristian Hewitt1-0/+1
This remote ships with the Amlogic SML-5442TW IPTV/VOD Set-Top Box used by O2.cz. This keymap adds support for the default IR controls. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: fix kernel-doc markupsMauro Carvalho Chehab9-12/+12
Some identifiers have different names between their prototypes and the kernel-doc markup. Seome seems to be due to cut-and-paste related issues. Others need to be fixed, as kernel-doc markups should use this format: identifier - description Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> # IPU3 and V4L2 Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: v4l: Add a helper for obtaining the link frequencySakari Ailus1-0/+21
Add a helper for obtaining the link frequency from transmitter drivers. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: v4l2-fwnode: Say it's fine to use v4l2_fwnode_endpoint_parseSakari Ailus1-3/+3
Earlier it was expected that there would be more variable size endpoint properties and that most if not all drivers would need them. For that reason it was expected also that v4l2_fwnode_endpoint_parse would no longer be needed. What actually happened that not all drivers require "link-frequencies", the only variable size media endpoint property without a small upper limit. Therefore drivers that do not need that information are fine using v4l2_fwnode_endpoint_parse. So don't tell drivers to use v4l2_fwnode_endpoint_alloc_parse in all cases. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: v4l2-fwnode: Rework v4l2_fwnode_endpoint_parse documentationSakari Ailus1-22/+40
Rework the documentation of v4l2_fwnode_endpoint_parse for better readability, usefulness and correctness. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: v4l2-fwnode: v4l2_fwnode_endpoint_parse caller must init vep argumentSakari Ailus1-0/+6
Document that the caller of v4l2_fwnode_endpoint_parse() must init the fields of struct v4l2_fwnode_endpoint (vep argument) fields. It used to be that the fields were zeroed by v4l2_fwnode_endpoint_parse when bus type was set to V4L2_MBUS_UNKNOWN but with recent changes (Fixes: line below) that no longer makes sense. Fixes: bb4bba9232fc ("media: v4l2-fwnode: Make bus configuration a struct") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: v4l2-async: Fix trivial documentation typoKieran Bingham1-1/+1
Fix the incorrect spelling asyncrhronous as asynchronous, which is visible in the public documentation of enum v4l2_async_match_type. Fixes: ab4f5a4afc2d ("[media] v4l2-async: document the remaining stuff") Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: v4l2-fwnode: Return -EINVAL for invalid bus-typeLad Prabhakar1-0/+2
Return -EINVAL if invalid bus-type is detected while parsing endpoints. Fixes: 26c1126c9b56 ("media: v4l: fwnode: Use media bus type for bus parser selection") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: uapi: h264: Add documentation to the interface headerEzequiel Garcia1-10/+185
In preparation for making the interface public, document all the structures. Special care is taken to annotate those fields that depart from the H264 syntax. This commit only adds documentation and doesn't affect functionality in any way. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: v4l2: prepare compat-ioctl reworkArnd Bergmann1-0/+10
The v4l2-compat-ioctl32() currently takes an extra round trip through user space pointers when converting the data structure formats. In particular, this involves using the compat_alloc_user_space() and copy_in_user() helpers that often lead to worse compat handlers compared to using in_compat_syscall() checks when copying the data. The native implementation already gained a simpler method to deal with the conversion for the time32 conversion. Hook into the same places to provide a location for reading and writing user space data from inside of the generic video_usercopy() helper. Hans Verkuil rewrote the video_get_user() function here to simplify the zeroing of the extra input fields and fixed a couple of bugs in the original implementation. [hverkuil: fix: CHECK: Please don't use multiple blank lines] Co-developed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-10-24Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds1-4/+0
Pull ARM SoC platform updates from Olof Johansson: "SoC changes, a substantial part of this is cleanup of some of the older platforms that used to have a bunch of board files. In particular: - Remove non-DT i.MX platforms that haven't seen activity in years, it's time to remove them. - A bunch of cleanup and removal of platform data for TI/OMAP platforms, moving over to genpd for power/reset control (yay!) - Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them closer to multiplatform support (not quite there yet, but getting close). There are a few other changes too, smaller fixlets, etc. For new platform support, the primary ones are: - New SoC: Hisilicon SD5203, ARM926EJ-S platform. - Cpufreq support for i.MX7ULP" * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits) ARM: mstar: Select MStar intc ARM: stm32: Replace HTTP links with HTTPS ones ARM: debug: add UART early console support for SD5203 ARM: hisi: add support for SD5203 SoC ARM: omap3: enable off mode automatically clk: imx: imx35: Remove mx35_clocks_init() clk: imx: imx31: Remove mx31_clocks_init() clk: imx: imx27: Remove mx27_clocks_init() ARM: imx: Remove unused definitions ARM: imx35: Retrieve the IIM base address from devicetree ARM: imx3: Retrieve the AVIC base address from devicetree ARM: imx3: Retrieve the CCM base address from devicetree ARM: imx31: Retrieve the IIM base address from devicetree ARM: imx27: Retrieve the CCM base address from devicetree ARM: imx27: Retrieve the SYSCTRL base address from devicetree ARM: s3c64xx: bring back notes from removed debug-macro.S ARM: s3c24xx: fix Wunused-variable warning on !MMU ARM: samsung: fix PM debug build with DEBUG_LL but !MMU MAINTAINERS: mark linux-samsung-soc list non-moderated ARM: imx: Remove remnant board file support pieces ...
2020-10-04Merge tag 'v5.9-rc7' into patchworkMauro Carvalho Chehab1-5/+2
Linux 5.9-rc7 * tag 'v5.9-rc7': (683 commits) Linux 5.9-rc7 mm/thp: Split huge pmds/puds if they're pinned when fork() mm: Do early cow for pinned pages during fork() for ptes mm/fork: Pass new vma pointer into copy_page_range() mm: Introduce mm_struct.has_pinned mm: validate pmd after splitting mm: don't rely on system state to detect hot-plug operations mm: replace memmap_context by meminit_context arch/x86/lib/usercopy_64.c: fix __copy_user_flushcache() cache writeback lib/memregion.c: include memregion.h lib/string.c: implement stpcpy mm/migrate: correct thp migration stats mm/gup: fix gup_fast with dynamic page table folding mm: memcontrol: fix missing suffix of workingset_restore mm, THP, swap: fix allocating cluster for swapfile by mistake mm: slab: fix potential double free in ___cache_free Documentation/llvm: Fix clang target examples io_uring: ensure async buffered read-retry is setup properly KVM: SVM: Add a dedicated INVD intercept routine io_uring: don't unconditionally set plug->nowait = true ...
2020-09-30media: v4l2-subdev.h: fix a kernel-doc markupMauro Carvalho Chehab1-1/+1
As reported by Sphinx: ./Documentation/driver-api/media/v4l2-subdev:490: ./include/media/v4l2-subdev.h:384: WARNING: Unparseable C cross-reference: 'struct' Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] struct ------^ The markup there is wrong: &struct &v4l2_input -> &struct v4l2_input Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-26media: vivid: Add support to the CSC APIDafna Hirschfeld1-0/+29
The CSC API (Colorspace conversion) allows userspace to try to configure the colorspace, transfer function, Y'CbCr/HSV encoding and the quantization for capture devices. This patch adds support to the CSC API in vivid. Using the CSC API, userspace is allowed to do the following: - Set the colorspace. - Set the xfer_func. - Set the ycbcr_enc function for YUV formats. - Set the hsv_enc function for HSV formats - Set the quantization for YUV and RGB formats. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-14media: media/v4l2: remove V4L2_FLAG_MEMORY_NON_CONSISTENT flagSergey Senozhatsky1-5/+2
The patch partially reverts some of the UAPI bits of the buffer cache management hints. Namely, the queue consistency (memory coherency) user-space hint because, as it turned out, the kernel implementation of this feature was misusing DMA_ATTR_NON_CONSISTENT. The patch reverts both kernel and user space parts: removes the DMA consistency attr functions, rolls back changes to v4l2_requestbuffers, v4l2_create_buffers structures and corresponding UAPI functions (plus compat32 layer) and cleans up the documentation. [hverkuil: fixed a few typos in the commit log] [hverkuil: fixed vb2_core_reqbufs call in drivers/media/dvb-core/dvb_vb2.c] [mchehab: fixed a typo in the commit log: revers->reverts] Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: v4l2-fwnode: Document new usage patterns of v4l2_fwnode_endpoint_parseSakari Ailus1-10/+8
Document that it is possible to provide defaults for multiple bus types to v4l2_fwnode_endpoint_parse and v4l2_fwnode_endpoint_alloc_parse. Also underline the fact that detecting the bus type without bus-type property is only for the old drivers. Also correct capitalisation of BT.656. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: v4l2-fwnode: Make bus configuration a structSakari Ailus1-2/+2
The bus specific parameters were a union. This made providing bus specific defaults impossible as the memory used to store the defaults for multiple different busses was the same. Make it struct instead. It's not large so the size isn't really an issue. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: v4l2-fwnode: Make number of data lanes a characterSakari Ailus1-1/+1
The maximum is currently four (4). No short is needed. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: v4l2-async: Document asd allocation requirementsLaurent Pinchart1-2/+3
The v4l2_async_notifier_add_subdev() function requires the asd pointer it receives to be allocated dynamically, but doesn't explicitly say so. Only one driver out of 13 get its right (atmel-sama5d2-isc.c, but with memory leaks in the error paths), clearly showing we have an issue. Update the v4l2_async_notifier_add_subdev() documentation to clearly state the allocation requirement. Whether this will be enough to avoid new offending code isn't certain, but it's a good first step nonetheless. Fixes: 9ca465312132 ("media: v4l: fwnode: Support generic parsing of graph endpoints in a device") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: rc: harmonize infrared durations to microsecondsSean Young1-6/+5
rc-core kapi uses nanoseconds for infrared durations for receiving, and microseconds for sending. The uapi already uses microseconds for both, so this patch does not change the uapi. Infrared durations do not need nanosecond resolution. IR protocols do not have durations shorter than about 100 microseconds. Some IR hardware offers 250 microseconds resolution, which is sufficient for most protocols. Better hardware has 50 microsecond resolution and is enough for every protocol I am aware off. Unify on microseconds everywhere. This simplifies the code since less conversion between microseconds and nanoseconds needs to be done. This affects: - rx_resolution member of struct rc_dev - timeout member of struct rc_dev - duration member in struct ir_raw_event Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Patrick Lerda <patrick9876@free.fr> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: "David Härdeman" <david@hardeman.nu> Cc: Benjamin Valentin <benpicco@googlemail.com> Cc: Antti Palosaari <crope@iki.fi> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-03media: videobuf-dma-sg: number of pages should be unsigned longMauro Carvalho Chehab1-1/+1
As reported by smatch: drivers/media/v4l2-core/videobuf-dma-sg.c:245 videobuf_dma_init_kernel() warn: should 'nr_pages << 12' be a 64 bit type? The printk should not be using %d for the number of pages. After looking better, the real problem here is that the number of pages should be long int. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Rename and clarify PPS_FLAG_SCALING_MATRIX_PRESENTEzequiel Garcia1-1/+1
Applications are expected to fill V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX if a non-flat scaling matrix applies to the picture. This is the case if SPS scaling_matrix_present_flag or PPS pic_scaling_matrix_present_flag are set, and should be handled by applications. On one hand, the PPS bitstream syntax element signals the presence of a Picture scaling matrix modifying the Sequence (SPS) scaling matrix. On the other hand, our flag should indicate if the scaling matrix V4L2 control is applicable to this request. Rename the flag from PPS_FLAG_PIC_SCALING_MATRIX_PRESENT to PPS_FLAG_SCALING_MATRIX_PRESENT, to avoid mixing this flag with bitstream syntax element pic_scaling_matrix_present_flag, and clarify the meaning of our flag. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Clean slice invariants syntax elementsEzequiel Garcia2-20/+20
The H.264 specification requires in section 7.4.3 "Slice header semantics", that the following values shall be the same in all slice headers: pic_parameter_set_id frame_num field_pic_flag bottom_field_flag idr_pic_id pic_order_cnt_lsb delta_pic_order_cnt_bottom delta_pic_order_cnt[ 0 ] delta_pic_order_cnt[ 1 ] sp_for_switch_flag slice_group_change_cycle These bitstream fields are part of the slice header, and therefore passed redundantly on each slice. The purpose of the redundancy is to make the codec fault-tolerant in network scenarios. This is of course not needed to be reflected in the V4L2 controls, given the bitstream has already been parsed by applications. Therefore, move the redundant fields to the per-frame decode parameters control (DECODE_PARAMS). Field 'pic_parameter_set_id' is simply removed in this case, because the PPS control must currently contain the active PPS. Syntax elements dec_ref_pic_marking() and those related to pic order count, remain invariant as well, and therefore, the fields dec_ref_pic_marking_bit_size and pic_order_cnt_bit_size are also common to all slices. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Clarify SLICE_BASED modeEzequiel Garcia1-4/+0
Currently, the SLICE_BASED and FRAME_BASED modes documentation is misleading and not matching the intended use-cases. Drop non-required fields SLICE_PARAMS 'start_byte_offset' and DECODE_PARAMS 'num_slices' and clarify the decoding modes in the documentation. On SLICE_BASED mode, a single slice is expected per OUTPUT buffer, and therefore 'start_byte_offset' is not needed (since the offset to the slice is the start of the buffer). This mode requires the use of CAPTURE buffer holding, and so the number of slices shall not be required. On FRAME_BASED mode, the devices are expected to take care of slice parsing. Neither SLICE_PARAMS are required (and shouldn't be exposed by frame-based drivers), nor the number of slices. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Drop SLICE_PARAMS 'size' fieldEzequiel Garcia1-3/+0
The SLICE_PARAMS control is intended for slice-based devices. In this mode, the OUTPUT buffer contains a single slice, and so the buffer's plane payload size can be used to query the slice size. To reduce the API surface drop the size from the SLICE_PARAMS control. A follow-up change will remove other members in SLICE_PARAMS so we don't need to add padding fields here. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Increase size of DPB entry pic_numEzequiel Garcia2-2/+3
DPB entry PicNum maximum value is 2*MaxFrameNum for interlaced content (field_pic_flag=1). As specified, MaxFrameNum is 2^(log2_max_frame_num_minus4 + 4) and log2_max_frame_num_minus4 is in the range of 0 to 12, which means pic_num should be a 32-bit field. The v4l2_h264_dpb_entry struct needs to be padded to avoid a hole, which might be also useful to allow future uAPI extensions. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Clean DPB entry interfaceEzequiel Garcia1-1/+1
As discussed recently, the current interface for the Decoded Picture Buffer is not enough to properly support field coding. This commit introduces enough semantics to support frame and field coding, and to signal how DPB entries are "used for reference". Reserved fields will be added by a follow-up commit. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Increase size of 'first_mb_in_slice' fieldEzequiel Garcia1-1/+2
Slice header syntax element 'first_mb_in_slice' can point to the last macroblock, currently the field can only reference 65536 macroblocks which is insufficient for 8K videos. Although unlikely, a 8192x4320 video (where macroblocks are 16x16), would contain 138240 macroblocks on a frame. As per the H264 specification, 'first_mb_in_slice' can be up to PicSizeInMbs - 1, so increase the size of the field to 32-bits. Note that v4l2_ctrl_h264_slice_params struct will be modified in a follow-up commit, and so we defer its 64-bit padding. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Split prediction weight parametersEzequiel Garcia2-2/+12
The prediction weight parameters are only required under certain conditions, which depend on slice header parameters. As specified in section 7.3.3 Slice header syntax, the prediction weight table is present if: ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \ (weighted_bipred_idc == 1 && slice_type == B)) Given its size, it makes sense to move this table to its control, so applications can avoid passing it if the slice doesn't specify it. Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes. With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight is 772 bytes. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: uapi: h264: Update reference listsJernej Skrabec1-6/+15
When dealing with interlaced frames, reference lists must tell if each particular reference is meant for top or bottom field. This info is currently not provided at all in the H264 related controls. Change reference lists to hold a structure, which specifies an index into the DPB array and the field/frame specification for the picture. Currently the only user of these lists is Cedrus which is just compile fixed here. Actual usage of will come in a following commit. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: cec: no need to check return value of debugfs_create functionsGreg Kroah-Hartman1-2/+0
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-28media: v4l2-mem2mem: add v4l2_m2m_suspend, v4l2_m2m_resumePi-Hsun Shih1-0/+22
Add two functions that can be used to stop new jobs from being queued / continue running queued job. This can be used while a driver using m2m helper is going to suspend / wake up from resume, and can ensure that there's no job running in suspend process. Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by: Jerry-ch Chen <jerry-ch.chen@mediatek.corp-partner.google.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-28media: videobuf2-v4l2.c: add vb2_video_unregister_device helper functionHans Verkuil1-0/+17
If a driver calls (_)vb2_fop_release(), then such a driver should also call vb2_video_unregister_device() instead of video_unregister_device(). This helper will call vb2_queue_release() if a filehandle is marked as owner of the queue. This ensures that at unregister time any streaming is cancelled and all buffers are returned to userspace. This is very useful for complex drivers since this stops all streaming in all subdevs in the pipeline controlled by this video device. Otherwise this would be delayed until the owner filehandle is closed, which can be quite some time later. Bonus points for ordering the includes :-) Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-26media: v4l2-tpg: Clamp hue in tpg_s_hue()Peilin Ye1-0/+1
Setting `hue` by calling tpg_s_hue() directly is risky, since it does not perform range check. Clamp `hue` to the valid range in tpg_s_hue(). Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-19ARM: s3c24xx: drop s3c-camif setup platform codeKrzysztof Kozlowski1-4/+0
The s3c-camif driver setup platform code does not have any users so it can be safely removed. Along with the code W=1 compile warnings go away: arch/arm/mach-s3c24xx/setup-camif.c:28:5: warning: no previous prototype for 's3c_camif_gpio_get' [-Wmissing-prototypes] arch/arm/mach-s3c24xx/setup-camif.c:56:6: warning: no previous prototype for 's3c_camif_gpio_put' [-Wmissing-prototypes] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-08-18media: v4l2- mediabus: Add usage note for V4L2_MBUS_*Jacopo Mondi1-4/+29
With the removal of the legacy g_mbus_config and s_mbus_config video operations, the sole users of V4L2_MBUS_* flags are now the newly introduced get_mbus_config and set_mbus_config pad operations. As the semantic of the new operations differs from the semantic of the legacy ones, add a usage note in the v4l2-mediabus.h header to specify how to use the flags. Also add a TODO note to record that we intend to replace the existing flags with fields, to prevent users from mixing conflicting values in a single operation call. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-18media: v4l2-subdev: Remove [s|g]_mbus_config video opsJacopo Mondi1-10/+0
With all sensor and platform drivers now converted to use the new get_mbus_config and set_mbus_config pad operations, remove the deprecated video operations g_mbus_config and s_mbus_config. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-18media: v4l2-subdev: Introduce [get|set]_mbus_config pad opsJacopo Mondi1-0/+28
Introduce two new pad operations to allow retrieving and configuring the media bus parameters on a subdevice pad. The newly introduced operations aims to replace the s/g_mbus_config video operations, which have been on their way for deprecation since a long time. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-07Merge tag 'media/v5.9-1' of ↵Linus Torvalds14-548/+161
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media updates from Mauro Carvalho Chehab: - Legacy soc_camera driver was removed from staging - New I2C sensor related drivers: dw9768, ch7322, max9271, rdacm20 - TI vpe driver code was re-organized and had new features added - Added Xilinx MIPI CSI-2 Rx Subsystem driver - Added support for Infrared Toy and IR Droid devices - Lots of random driver fixes, new features and cleanups * tag 'media/v5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (318 commits) media: camss: fix memory leaks on error handling paths in probe media: davinci: vpif_capture: fix potential double free media: radio: remove redundant assignment to variable retval media: allegro: fix potential null dereference on header media: mtk-mdp: Fix a refcounting bug on error in init media: allegro: fix an error pointer vs NULL check media: meye: fix missing pm_mchip_mode field media: cafe-driver: use generic power management media: saa7164: use generic power management media: v4l2-dev/ioctl: Fix document for VIDIOC_QUERYCAP media: v4l2: Correct kernel-doc inconsistency media: v4l2: Correct kernel-doc inconsistency media: dvbdev.h: keep * together with the type media: v4l2-subdev.h: keep * together with the type media: videobuf2: Print videobuf2 buffer state by name media: colorspaces-details.rst: fix V4L2_COLORSPACE_JPEG description media: tw68: use generic power management media: meye: use generic power management media: cx88: use generic power management media: cx25821: use generic power management ...
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-15 21:44:24 +0300