Remove the no longer used bin_factor_x, bin_factor_y and bin_mode members
from the resolution info inside various atomisp camera sensor drivers.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The bin-factor-x and bin-factor-y ctrls are only used internally to
get a single value to pass to atomisp_css_input_set_binning_factor(),
which is supposed to tune the lens-shading correction for the binning
factor. But all sensor drivers return either 0 or 1 for this,
with 0 meaning unset and 1 meaning no-binning. Even though some modes
do actually do binning ...
Also note that the removed atomisp_get_sensor_bin_factor() would fall
back to 0 if either the x and y factor differ or if the ctrls are not
implemented (not all sensor drivers implement them).
Simply always pass 0 to atomisp_css_input_set_binning_factor().
This is part of a patch-series which tries to remove atomisp specific /
custom code from the sensor drivers, with as end goal to make the atomisp
drivers regular camera sensor drivers.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
This ioctl returns a number of fixed sensor parameters +
a number of mode-specific parameters.
With libcamera these fixed parameters are instead stored in a table
with sensor-name to parameters mappings (camera_sensor_properties.cpp);
and the variable parameters can be derived from the set fmt.
So this custom ioctl is not necessary; and it currently has no users.
Remove the ioctl and all the sensor drivers xxxx_get_intg_factor()
helpers which return this info.
This is part of a patch-series which tries to remove atomisp specific /
custom code from the sensor drivers, with as end goal to make the atomisp
drivers regular camera sensor drivers.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
This ioctl simply returns a couple of fixed sensor parameters.
With libcamera these fixed parameters are instead stored in a table
with sensor-name to parameters mappings (camera_sensor_properties.cpp),
so this custom ioctl is not necessary; and it currently has no users.
Remove the ioctl and also remove the custom v4l2-ctrls underpinning
the ioctl.
This is part of a patch-series which tries to remove atomisp specific /
custom code from the sensor drivers, with as end goal to make the atomisp
drivers regular camera sensor drivers.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
On BYT on poweron/runtime-resume the code is doing:
1. Do nothing
2. msleep(10)
3. Start actual poweron sequence
Since the runtime resume can happen at any moment, waiting 10ms
after it does not really make any sense.
According to both the comment and to:
https://github.com/intel/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/cam-0341-atomisp-WA-sleep-10ms-when-power-up-ISP-on-byt.patch
Which is the patch which originally added this this was added
as a workaround for a single test failing on a single model
tablet/laptop. So lets just drop this.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
punit_ddr_dvfs_enable() is only used on CHT devices and there dmesg
gets filled with: "DDR DVFS, door bell is not cleared within 3ms"
messages, so clearly the doorbell checking is not working.
This check was added by:
https://github.com/intel/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/cam-0340-atomisp-add-door-bell-for-ddr-dvfs-on-cht.patch
Which commit message says: "PUNIT interface added to check Req_ACK
of freq status". This suggests that the doorbell mechanism may only
be available with certain PUNIT fw versions and it seems that
many CHT devices do not have this fw version; that or the doorbell
mechanism is not working for other reasons.
Revert cam-0340-atomisp-add-door-bell-for-ddr-dvfs-on-cht.patch,
replacing the doorbell check with a msleep(20) this fixes dmesg
getting filled with error messages.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
These are clearly debug messages, printing these all the time is not
useful.
Silence these by simply removing them altogether.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The atomisp does not use standard PCI power-management through the
PCI config space. Instead this driver directly tells the P-Unit to
disable the ISP over the IOSF. The standard PCI subsystem pm_ops will
try to access the config space before (resume) / after (suspend) this
driver has turned the ISP on / off, resulting in the following errors:
Unable to change power state from D0 to D3hot, device inaccessible
Unable to change power state from D3cold to D0, device inaccessible
Getting logged into dmesg a whole bunch of time during boot as well as
every time the camera is used.
To avoid these errors use a custom pm_domain instead of standard driver
pm-callbacks so that all the PCI subsys suspend / resume handling is
skipped and call pci_save_state() / pci_restore_state() ourselves.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Remove the atomisp_sw_contex struct, it has only 1 member: running_freq,
instead store running_freq directly.
While at it also change running_freq from an int to an unsigned int,
all values stored in it are unsigned and it is compared to the also
unsigned new_freq variable.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The Crystal Cove PMIC used on some BYT/CHT devices has different revisions
when paired with Bay Trail (BYT) vs Cherry Trail (CHT) SoCs.
The current hardcoded values are only valid for CHT devices, change
the code so that it uses the correct register values on both BYT and CHT.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Check buffer index is in range inside atomisp_qbuf_wrapper() before
using it do index pipe->frame_request_config_id[].
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The videobuf2-core expects buffers to be put back in the queued state
when the vb2 start_streaming callback fails. But the atomisp
atomisp_flush_video_pipe() would unconditionally return them to the core
in an error state.
This triggers the following warning in the videobuf2-core:
drivers/media/common/videobuf2/videobuf2-core.c:1652:
/*
* If done_list is not empty, then start_streaming() didn't call
* vb2_buffer_done(vb, VB2_BUF_STATE_QUEUED) but STATE_ERROR or
* STATE_DONE.
*/
WARN_ON(!list_empty(&q->done_list));
Fix this by adding a state argument to atomisp_flush_video_pipe() and use
VB2_BUF_STATE_QUEUED as state when atomisp_start_streaming() fails.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Calling v4l2_ctrl_s_ctrl(asd->run_mode, pipe->default_run_mode) when
the stream is already active (through another /dev/video# node) causes
the stream to stop.
Move the call to set the default run-mode so that it is only done
on the first open of one of the 4 /dev/video# nodes of one of
the 2 streams (atomisp-sub-devices / asd-s).
Fixes: 2c45e343c5 ("media: atomisp: set per-device's default mode")
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Don't touch q->start_streaming_called directly, use the
vb2_start_streaming_called() function instead.
Link: https://lore.kernel.org/r/bc6c24ec-72ea-64a1-9061-311cc7339827@xs4all.nl
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The recent conversion missed the Kconfig bit, so it can now
end up in a link error on randconfig builds:
ld.lld: error: undefined symbol: vb2_vmalloc_memops
>>> referenced by atomisp_fops.c
>>> drivers/staging/media/atomisp/pci/atomisp_fops.o:(atomisp_open) in archive vmlinux.a
Link: https://lore.kernel.org/r/20230104082212.3770415-1-arnd@kernel.org
Fixes: cb48ae89be ("media: atomisp: Convert to videobuf2")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
When the ene device is detaching, function ene_remove() will
be called. But there is no function to cancel tx_sim_timer
in ene_remove(), the timer handler ene_tx_irqsim() could race
with ene_remove(). As a result, the UAF bugs could happen,
the process is shown below.
(cleanup routine) | (timer routine)
| mod_timer(&dev->tx_sim_timer, ..)
ene_remove() | (wait a time)
| ene_tx_irqsim()
| dev->hw_lock //USE
| ene_tx_sample(dev) //USE
Fix by adding del_timer_sync(&dev->tx_sim_timer) in ene_remove(),
The tx_sim_timer could stop before ene device is deallocated.
What's more, The rc_unregister_device() and del_timer_sync()
should be called first in ene_remove() and the deallocated
functions such as free_irq(), release_region() and so on
should be called behind them. Because the rc_unregister_device()
is well synchronized. Otherwise, race conditions may happen. The
situations that may lead to race conditions are shown below.
Firstly, the rx receiver is disabled with ene_rx_disable()
before rc_unregister_device() in ene_remove(), which means it
can be enabled again if a process opens /dev/lirc0 between
ene_rx_disable() and rc_unregister_device().
Secondly, the irqaction descriptor is freed by free_irq()
before the rc device is unregistered, which means irqaction
descriptor may be accessed again after it is deallocated.
Thirdly, the timer can call ene_tx_sample() that can write
to the io ports, which means the io ports could be accessed
again after they are deallocated by release_region().
Therefore, the rc_unregister_device() and del_timer_sync()
should be called first in ene_remove().
Suggested by: Sean Young <sean@mess.org>
Fixes: 9ea53b74df ("V4L/DVB: STAGING: remove lirc_ene0100 driver")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Reference common HDMI CEC adapter properties to simplify the binding and
have only one place of definition for common properties. The common CEC
binding expects also node name to be 'cec'.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Reference common HDMI CEC adapter properties to simplify the binding and
have only one place of definition for common properties.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Move st,stm32-cec.yaml bindings to cec subfolder and drop unneeded
"bindings" in the title.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Move amlogic,meson-gx-ao-cec.yaml bindings to cec subfolder and drop
unneeded quotes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
When the pointer variable is judged to be null, null is returned
directly.
[hverkuil: fix two checkpatch warnings]
Signed-off-by: Dong Chuanjian <chuanjian@nfschina.com>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Fixes: d3f756ad62 ("media: v4l2: Trace calculated p/b0/b1 initial reflist")
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The Hantro driver uses a hardcoded value for the bus_info field in the
media device and |struct v4l2_capability|. This worked well when there
was just one device. However with the iMX.8 series we are now seeing
two Hantro blocks on the same chip. The static bus_info is no longer
sufficient for differentiating devices.
Since commit f2d8b6917f ("media: v4l: ioctl: Set bus_info in
v4l_querycap()"), the V4L2 core provides a default value for the
bus_info field for platform and PCI devices. This value will match
the default value for media devices added by commit cef699749f
("media: mc: Set bus_info in media_device_init()"). These defaults
are stable and device-specific.
Drop the static bus_info values from the hantro driver and use the
defaults.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
pm_runtime_put will set RPM_ASYNC flag then queue an idle-notification
request again, won't return error immediately until current request is
scheduled.
But pm_runtime_put_sync run the ->runtime_idle() callback directly, return
error immediately no matter whether current request is scheduled.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
in the E.2.1 of Rec. ITU-T H.264 (06/2019),
0 of colour primaries is reserved, and 2 is unspecified.
driver can map V4L2_COLORSPACE_LAST to 0,
and map V4L2_COLORSPACE_DEFAULT to 2.
v4l2_xfer_func and v4l2_ycbcr_encoding are similar case.
Fixes: 3cd084519c ("media: amphion: add vpu v4l2 m2m support")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
using the api of clk_bulk can simplify the code.
and the clock of the jpeg codec may be changed,
the clk_bulk api can be compatible with the future change.
Fixes: 4c2e5156d9 ("media: imx-jpeg: Add pm-runtime support for imx-jpeg")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Don't populate the const arrays on the stack, instead make them
static. Also makes the object code smaller.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Don't populate the read-only const array DURATION on the stack but
instead make it static. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
At present, the function imx_media_fim_set_stream() always returns 0.
So, convert it to be a function returning void instead. Issue identified
using the returnvar.cocci Coccinelle semantic patch.
Signed-off-by: Deepak R Varma <drv@mailo.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Since 79c987de8b, enumerating framesize on format set with "MODE_NONE"
(any raw formats) is reporting an invalid frmsize.
Size: Stepwise 0x0 - 0x0 with step 0/0
Before this change, the driver would return EINVAL, which is also invalid
but worked in GStreamer. The original intent was not to implement it, hence
the -ENOTTY return in this change. While drivers should implement
ENUM_FRMSIZE for all formats and queues, this change is limited in scope to
fix the regression.
This fixes taking picture in Gnome Cheese software, or any software using
GSteamer to encode JPEG with hardware acceleration.
Fixes: 79c987de8b ("media: hantro: Use post processor scaling capacities")
Reported-by: Robert Mader <robert.mader@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Robert Mader <robert.mader@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The void * type pointer does not need to be cast.
Signed-off-by: Zhou jie <zhoujie@nfschina.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The legal identifier of APP14 is "Adobe\0",
but sometimes it may be
"This is an unknown APP marker . Compliant decoders must ignore it."
In this case, just ignore it.
It won't affect the decode result.
Fixes: b8035f7988 ("media: Add parsing for APP14 data segment in jpeg helpers")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The curr pointer has advanced 14 bytes in jpeg_parse_app14_data.
1. jpeg_get_word_be(stream), it goes forward 2 bytes.
2. jpeg_skip(stream, 11), it goes forward 11 bytes.
3. jpeg_get_byte(stream), it goes forward 1 bytes.
so the remain bytes of this segment should be (lp - 2 - 11 - 1),
but not (lp - 2 - 11).
if driver skip 1 extra bytes, the following parsing may go wrong.
Fixes: b8035f7988 ("media: Add parsing for APP14 data segment in jpeg helpers")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The new mdp3 driver uses 'select' to force-enable a couple of drivers
it depends on. This is error-prone and likely to cause dependency
loops as well as warnings like:
WARNING: unmet direct dependencies detected for VIDEO_MEDIATEK_VPU
Depends on [n]: MEDIA_SUPPORT [=m] && MEDIA_PLATFORM_SUPPORT [=y] && MEDIA_PLATFORM_DRIVERS [=y] && V4L_MEM2MEM_DRIVERS [=n] && VIDEO_DEV [=m] && (ARCH_MEDIATEK [=y] || COMPILE_TEST [=y])
Selected by [m]:
- VIDEO_MEDIATEK_MDP3 [=m] && MEDIA_SUPPORT [=m] && MEDIA_PLATFORM_SUPPORT [=y] && MEDIA_PLATFORM_DRIVERS [=y] && (MTK_IOMMU [=m] || COMPILE_TEST [=y]) && VIDEO_DEV [=m] && (ARCH_MEDIATEK [=y] || COMPILE_TEST [=y]) && HAS_DMA [=y] && REMOTEPROC [=y]
This specific warning was already addressed in a previous patch,
but there are similar unnecessary 'select' statements, so turn those
into 'depends on'. This also means the dependency on ARCH_MEDIATEK
is redundant and can be dropped.
Fixes: 61890ccaef ("media: platform: mtk-mdp3: add MediaTek MDP3 driver")
Fixes: 9195a860ef ("media: platform: mtk-mdp3: remove unused VIDEO_MEDIATEK_VPU config")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Marking a case of the switch statement as unreachable means the
compiler treats it as undefined behavior, which is then caught by
an objtool warning:
drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.o: warning: objtool: csiphy_lanes_enable() falls through to next function csiphy_lanes_disable()
Instead of simply continuing execution at a random place of the
driver, print a warning and return from to the caller, which
makes it possible to understand what happens and avoids the
warning.
Fixes: 53655d2a0f ("media: camss: csiphy-3ph: add support for SM8250 CSI DPHY")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
A remove callback just returning 0 is equivalent to no remove callback
at all. So drop the useless function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
A remove callback just returning 0 is equivalent to no remove callback
at all. So drop the useless function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Lad Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
A remove callback just returning 0 is equivalent to no remove callback
at all. So drop the useless function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Lad Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The streaming state is maintained by the vb2 core, so drivers
must never change it themselves.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Don't touch q->streaming directly, use the vb2_is_streaming()
function instead.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Don't touch q->streaming directly, use the vb2_is_streaming()
function instead.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use URL rather than plain text.
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use URL rather than plain text.
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
