The new AMD IOMMU DMA implementation concatenates sglist entries under
certain conditions, and because saa7146 accessed the length member
directly, it did not support this scenario.
This fixes IO_PAGE_FAULTs by using the sg_dma_len macro.
Fixes: be62dbf554 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api")
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The new AMD IOMMU DMA implementation concatenates sglist entries under
certain conditions, and because saa7134 accessed the length member
directly, it did not support this scenario.
This fixes IO_PAGE_FAULTs and choppy DMA audio by using the
sg_dma_len macro.
Fixes: be62dbf554 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api")
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This patch fixes the following trivial warnings w.r.t. kernel-doc usage:
drivers/media/common/videobuf2/frame_vector.c:38: warning: Excess function parameter 'gup_flags' description in 'get_vaddr_frames'
drivers/media/dvb-core/dvb_ca_en50221.c:193: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1014: warning: expecting prototype for Wake up the DVB CA thread(). Prototype was for
dvb_ca_en50221_thread_wakeup() instead
drivers/media/dvb-core/dvb_ca_en50221.c:1023: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1081: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1112: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1327: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1411: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1426: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1582: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1693: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1743: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1772: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1830: warning: wrong kernel-doc identifier on line:
drivers/media/dvb-core/dvb_ca_en50221.c:1922: warning: wrong kernel-doc identifier on line:
drivers/media/rc/img-ir/img-ir-hw.c:628: warning: expecting prototype for img_ir_decoder_compatable(). Prototype was for
img_ir_decoder_compatible() instead
drivers/media/v4l2-core/v4l2-jpeg.c:461: warning: expecting prototype for jpeg_parse_header(). Prototype was for v4l2_jpeg_parse_header()
instead
drivers/media/platform/vsp1/vsp1_dl.c:166: warning: expecting prototype for struct vsp1_cmd_pool. Prototype was for struct vsp1_dl_cmd_pool
instead
drivers/media/platform/mtk-vpu/mtk_vpu.c:28: warning: expecting prototype for is a tiny processor controlling video hardware(). Prototype
was for INIT_TIMEOUT_MS() instead
drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c:73: warning: expecting prototype for struct vp9_fb_info. Prototype was for struct
vp9_ref_buf instead
drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c:85: warning: expecting prototype for struct vp9_fb_info. Prototype was for struct
vp9_sf_ref_fb instead
drivers/media/tuners/mt2063.c:1404: warning: expecting prototype for fLO_FractionalTerm(). Prototype was for MT2063_fLO_FractionalTerm() instead
drivers/media/tuners/mt2063.c:1465: warning: expecting prototype for CalcLO2Mult(). Prototype was for MT2063_CalcLO2Mult() instead
drivers/media/usb/pwc/pwc-dec23.c:640: warning: wrong kernel-doc identifier on line:
drivers/media/platform/exynos4-is/media-dev.c:820: warning: expecting prototype for __fimc_md_create_fimc_links(). Prototype was for
__fimc_md_create_fimc_sink_links() instead
drivers/media/i2c/s5k6aa.c:426: warning: expecting prototype for s5k6aa_configure_pixel_clock(). Prototype was for
s5k6aa_configure_pixel_clocks() instead
drivers/media/i2c/imx274.c:700: warning: wrong kernel-doc identifier on line:
drivers/media/i2c/imx274.c:735: warning: wrong kernel-doc identifier on line:
drivers/media/i2c/imx274.c:983: warning: wrong kernel-doc identifier on line:
Most are missing or mistyped function names.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently the chroma_flags and alpha_flags are being zero'd with a bit-wise
mask and the following statement should be bit-wise or'ing in the new flag
bits but instead is making a direct assignment. Fix this by using the |=
operator rather than an assignment.
Addresses-Coverity: ("Unused value")
Fixes: ef834f7836 ("[media] vivid: add the video capture and output parts")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix a typo in the text.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently the cec_notifier_parse_hdmi_phandle function can only be used
if the HDMI device associated with the CEC device is a platform device.
Extend the function to cover I2C devices as well, as there do exist
some I2C HDMI devices which don't handle CEC internally and need an
external CEC adapter.
[hverkuil: add missing linux/i2c.h header]
[hverkuil: only attempt to find the i2c device if CONFIG_I2C is set]
Signed-off-by: Johan Fjeldtvedt <johfjeld@cisco.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
syzbot reported memory leak in zr364xx_probe()[1].
The problem was in invalid error handling order.
All error conditions rigth after v4l2_ctrl_handler_init()
must call v4l2_ctrl_handler_free().
Reported-by: syzbot+efe9aefc31ae1e6f7675@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is a repeating code pattern:
if (a || b) {
if (a)
...
if (b)
...
}
In this pattern, the first 'if' is redundant.
The code can be replaced with:
if (a)
...
if (b)
...
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>
The mtk-smi driver can now be built as a loadable module, but
this leads to a build time regression when the drivers that
depend on it are built-in:
aarch64-linux-ld: drivers/media/platform/mtk-mdp/mtk_mdp_comp.o: in function `mtk_mdp_comp_clock_on':
mtk_mdp_comp.c:(.text.mtk_mdp_comp_clock_on+0x54): undefined reference to `mtk_smi_larb_get'
aarch64-linux-ld: drivers/media/platform/mtk-mdp/mtk_mdp_comp.o: in function `mtk_mdp_comp_clock_off':
mtk_mdp_comp.c:(.text.mtk_mdp_comp_clock_off+0x12c): undefined reference to `mtk_smi_larb_put'
Add a dependency on the interface, but keep allowing
compile-testing without that driver, as it was originally
intended.
Fixes: 50fc8d9232 ("memory: mtk-smi: Allow building as module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Remove superfluous "breaks", as there is a "return" before them.
Signed-off-by: dingsenjie <dingsenjie@yulong.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Remove superfluous "breaks", as there is a "return" before them.
Signed-off-by: dingsenjie <dingsenjie@yulong.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
fixed the following coccicheck:
./drivers/media/pci/solo6x10/solo6x10-core.c:371:60-61: WARNING
opportunity for kobj_to_dev()
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Because of u32 type being used to store pixel clock rate, expression used
to calculate pipeline clocks (pixel_clock * bpp) produces wrong value due
to integer overflow. This patch changes data type used to store, pass and
retrieve pixel_clock from u32 to u64 to make this mistake less likely to
be repeated in the future.
Signed-off-by: Vladimir Lypak <junak.pub@gmail.com>
Acked-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are places in the camss driver where camss_get_pixel_clock() is
called to get the pixel rate (using V4L2_CID_PIXEL_RATE control) and to
calculate the link frequency from it. There is a case when this would
not work: when V4L2_CID_PIXEL_RATE gets the rate at which the pixels are
read (sampled) from the sensor's pixel array, and this rate is different
from the pixel transmission rate over the CSI link, the link frequency
value can't be calculated from the pixel rate. One needs to use
V4L2_CID_LINK_FREQ to get the link frequency in this case.
Replace such calls to camss_get_pixel_clock() with calls to a wrapper
around v4l2_get_link_freq(). v4l2_get_link_freq() tries V4L2_CID_LINK_FREQ
first, and if it is not implemented by the camera sensor driver, falls
back to V4L2_CID_PIXEL_RATE to calculate the link frequency value from.
Calls to camss_get_pixel_clock() from vfe_[check,set]_clock_rates()
are left intact as it looks like this VFE clock does depend on the
rate the pixel samples comes out of the camera sensor, not on the
frequency at which the link between the sensor and the CSI receiver
operates.
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Acked-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Print a warning if V4L2_CID_LINK_FREQ control is not implemented.
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use getter and setter functions, for a variety of data types.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As some hardware have a knob to enable or disable emulation prevention
bytes removal, driver writers ended up wondering what exactly the
START_CODE_NONE modes meant in this regards. This patch clarify what is
expected with a reference to the specification.
Reported-by: John Cox <jc@kynesim.co.uk>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Constify two static structs which are never modified to allow the
compiler to put them in read-only memory.
The only usage of norm_params is only read from it in
usbtv_configure_for_norm(). Making it const shrinks the resulting
ko-file with 300 bytes (tested with gcc 10).
The only usage of usbtv_ioctl_ops is to put its address to the ioctl_ops
field in the video_device struct. Making it const moves ~1kb to
read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Don't populate the const arrays on the stack but instead it
static. Makes the object code smaller by 8 bytes:
Before:
text data bss dec hex filename
12504 4568 0 17072 42b0 media/platform/sti/hva/hva-h264.o
After:
text data bss dec hex filename
12272 4792 0 17064 42a8 media/platform/sti/hva/hva-h264.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
struct v4l2_ctrl_h264_pps members obviously match picture parameter syntax,
not sequence parameter syntax.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Captured using a raw IR receiver. Manual linked in the remote definition
itself.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
dvb_usb_device_init() copies the properties to the own data, so that
the callers can release the original properties later (as done in the
commit 299c7007e9 ("media: dw2102: Fix memleak on sequence of
probes")). However, it also stores dev->desc pointer that is a
reference to the original properties data. Since dev->desc is
referred later, it may result in use-after-free, in the worst case,
leading to a kernel Oops as reported.
This patch addresses the problem by allocating and copying the
properties at first, then get the desc from the copied properties.
Reported-and-tested-by: Stefan Seyfried <seife+kernel@b1-systems.com>
BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1181104
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
dvb_usb_device_init() allocates a dvb_usb_device object, but it
doesn't release the object by itself even at errors. The object is
released in the callee side (dvb_usb_init()) in some error cases via
dvb_usb_exit() call, but it also missed the object free in other error
paths. And, the caller (it's only dvb_usb_device_init()) doesn't seem
caring the resource management as well, hence those memories are
leaked.
This patch assures releasing the memory at the error path in
dvb_usb_device_init(). Now dvb_usb_init() frees the resources it
allocated but leaves the passed dvb_usb_device object intact. In
turn, the dvb_usb_device object is released in dvb_usb_device_init()
instead.
We could use dvb_usb_exit() function for releasing everything in the
callee (as it was used for some error cases in the original code), but
releasing the passed object in the callee is non-intuitive and
error-prone. So I took this approach (which is more standard in Linus
kernel code) although it ended with a bit more open codes.
Along with the change, the patch makes sure that USB intfdata is reset
and don't return the bogus pointer to the caller of
dvb_usb_device_init() at the error path, too.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Manufacturing has switched from ISOC to bulk transport,
the pid has accordingly changed to signify this.
0x2013:0x0461 is an ISOC 461e v2
0x2013:0x8461 is a bulk transport 461e v2
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Manufacturing has switched from ISOC to bulk transport,
the pid has accordingly changed to signify this.
0x2013:0x0258 is an ISOC 461e
0x2013:0x8258 is a bulk transport 461e
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a keymap and bindings for the simple IR (NEC) remote used with
Minix 'NEO' branded Android STB devices.
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>
The in_use variable is set to true when a lirc file is opened, and ir
transmit can only be done by writing to a lirc file descriptor. As a
result when in_use is read, it is always true, so we might as well remove
it.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The carrier, duty cycle etc are not device dependent, and they can be
changed at runtime. By moving them into the allocated struct, we can make
the device specific structures smaller, and we no longer need to copy
the struct.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The lirc ioctls should be used for this, not module parameters.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Remove lots of superfluous debug messages which just log the function
name. Also, there is no need to announce the various parameters of the
device. This can be discovered via lirc ioctl if needed.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This ensure that the rc device shows up correctly in sysfs.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It is redundant to do irqsave and irqrestore in hardIRQ context.
Signed-off-by: Daode Huang <huangdaode@huawei.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sphinx doesn't allow placing those cross-reference identifies
everywhere. Misplacing them cause those warnings:
Documentation/userspace-api/media/v4l/hist-v4l2.rst:818: WARNING: undefined label: control-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/hist-v4l2.rst:853: WARNING: undefined label: reserved-formats (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst:47: WARNING: undefined label: reserved-formats (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/subdev-formats.rst:39: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/subdev-formats.rst:53: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/subdev-formats.rst:67: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/subdev-formats.rst:83: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/subdev-formats.rst:97: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/subdev-formats.rst:140: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-decoder-cmd.rst:75: WARNING: undefined label: decoder-cmds (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-dqevent.rst:234: WARNING: undefined label: control-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-g-dv-timings.rst:156: WARNING: undefined label: dv-bt-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst:41: WARNING: undefined label: ctrl-class (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst:246: WARNING: undefined label: ctrl-class (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst:269: WARNING: undefined label: ctrl-class (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-g-modulator.rst💯 WARNING: undefined label: modulator-txsubchans (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-g-tuner.rst:119: WARNING: undefined label: tuner-rxsubchans (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst:167: WARNING: undefined label: control-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst:245: WARNING: undefined label: control-flags (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst:396: WARNING: undefined label: ctrl-class (if the link has no caption the label must precede a section header)
Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst:73: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header)
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It makes more sense to place the xvideo example at the body,
keeping the footnote only to justify the design decision.
While this makes the text better, it also fixes the PDF
output.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are lots of tables that are not properly displayed
in LaTeX/PDF.
Fix the tablecolumns, add longtable where needed and LaTeX
formatting macros, in order to address such issues.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add missing format macros for the tables there to be properly
output.
While here, also remove the empty ".. note::" markup.
It should be noticed that ".. [1]" markups will generate footnotes,
and not a note within the main text body.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The Picture Parameter Set Flags table for H-264 doesn't output
well on PDF. There are missing format instructions for LaTeX, and
the columns are too long.
Reduce the size of the second column, as 16 bits is more than enough
for the current flags usage, and add the needed bits for it to be
properly output in PDF format.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sphinx/LaTeX doesn't work well with literal blocks.
Due to that, V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF ends
being writing outside the table (and even outside the page).
We need to not only change the table size and font size, but
also to change the message, in order to avoid this bug.
So, improve the text a little bit, while ensuring that the
literal will be written at the beginning of the second line.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Qinglang Miao