- 27 Sep, 2023 40 commits
-
-
Marvin Lin authored
Add a control base for Nuvoton NPCM driver controls, and reserve 16 controls. Signed-off-by:
Marvin Lin <milkfafa@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
Marvin Lin authored
Add HEXTILE compressed format which is defined in Remote Framebuffer Protocol (RFC 6143, chapter 7.7.4 Hextile Encoding) and is used by Encoding Compression Engine (ECE) present on Nuvoton NPCM SoCs. Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
-
Marvin Lin authored
Add dt-bindings document for Graphics Core Information (GFXI) node. It is used by NPCM video driver to retrieve Graphics core information. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Marvin Lin authored
Add dt-bindings document for Video Capture/Differentiation Engine (VCD) and Encoding Compression Engine (ECE) present on Nuvoton NPCM SoCs. Signed-off-by:
-
Hans Verkuil authored
The last driver that still used this old framework has been converted to the videobuf2 framework. So it is now time to delete the old videobuf code. Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Hans Verkuil authored
This source still included the media/videobuf-vmalloc.h header, even though it is no longer used. Since the old videobuf framework is about to be removed, delete this include first. Signed-off-by:
-
Yue Haibing authored
These are never implemented, remove them. Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Signed-off-by:
-
Yu Liao authored
Prefer struct_size() over open-coded versions of idiom: sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count where count is the max number of items the flexible array is supposed to contain. Signed-off-by:
Yu Liao <liaoyu15@huawei.com> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Colin Ian King authored
There are a couple of spelling mistakes in pr_err error messages. Fix them. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Devicetree for the FIMC IS camera included duplicated PMU node as its child like: soc@0 { system-controller@10020000 { ... }; // Real PMU camera@11800000 { fimc-is@12000000 { // FIMC IS camera node pmu@10020000 { reg = <0x10020000 0x3000>; // Fake PMU node }; }; }; }; This is not a correct representation of the hardware. Mapping the PMU (Power Management Unit) IO memory should be via syscon-like phandle (samsung,pmu-syscon, already used for other drivers), not by duplicating "pmu" Devicetree node inside the FIMC IS. Backward compatibility is preserved. Signed-off-by: -
Krzysztof Kozlowski authored
The camera node's ranges property and unit addresses of its children were not correct. If camera is @11800000, then its fimc child is @0. Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The FIMC IS camera must access the PMU (Power Management Unit) IO memory to control camera power. This was achieved by duplicating the PMU node as its child like: soc@0 { system-controller@10020000 { ... }; // Real PMU camera@11800000 { fimc-is@12000000 { // FIMC IS camera node pmu@10020000 { reg = <0x10020000 0x3000>; // Fake PMU node }; }; }; }; This is not a correct representation of the hardware. Mapping the PMU (Power Management Unit) IO memory should be via syscon-like phandle (samsung,pmu-syscon, already used for other drivers), not by duplicating "pmu" Devicetree node inside the FIMC IS. Reviewed-by:Rob Herring <robh@kernel.org> Signed-off-by:
-
Ruan Jinjie authored
The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Li Zetao authored
Use the helper function devm_kmemdup() rather than duplicating its implementation, which helps to enhance code readability. Signed-off-by:
Li Zetao <lizetao1@huawei.com> Signed-off-by:
-
Hans Verkuil authored
Instead of creating a huge switch statement (that thoroughly confuses smatch), create a table of coefficients and use that. Signed-off-by: -
Wang Ming authored
It is possible that dma_request_chan will return EPROBE_DEFER, which means that dma->xdev->dev is not ready yet. In this case, dev_err(dma->xdev->dev), there will be no output. This patch fixes the bug. Signed-off-by:
Wang Ming <machel@vivo.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Colin Ian King authored
Don't populate the arrays on the stack, instead make them static const. Also add spaces between values to clean up checkpatch style warnings. Signed-off-by:
-
Juerg Haefliger authored
The module loads firmware so add a MODULE_FIRMWARE macro to provide that information via modinfo. Signed-off-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Signed-off-by:
-
Zheng Wang authored
There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug. This bug is found by static analysis, it may be false positive. Fix it by adding del_timer_sync invoking to the remove function. cpu0 cpu1 bttv_probe ->timer_setup ->bttv_set_dma ->mod_timer; bttv_remove ->kfree(btv); ->bttv_irq_timeout ->USE btv Fixes: 162e6376 ("media: pci: Convert timers to use timer_setup()") Signed-off-by:Zheng Wang <zyytlz.wz@163.com> Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
The sensor is guaranteed not to be streaming when the runtime PM resume handler is called, as the resume handler is only called from the .s_stream() operation when starting streaming. Similarly, the sensor has been stopped when the runtime PM suspend handler is called. There is thus no need for manual stream start/stop from the runtime PM handlers. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
Ricardo Ribalda <ribalda@chromium.org> Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. Now that the runtime PM operations are not called from the system PM handlers, the sensor is guaranteed not to be streaming when the runtime PM resume handler is called, and to have been stopped already when the runtime PM suspend handler is called. Drop the manual stream start/stop from the runtime PM handlers. Signed-off-by:
-
Laurent Pinchart authored
Stopping streaming on a camera pipeline at system suspend time, and restarting it at system resume time, requires coordinated action between the bridge driver and the camera sensor driver. This is handled by the bridge driver calling the sensor's .s_stream() handler at system suspend and resume time. There is thus no need for the sensor to independently implement system sleep PM operations. Drop them. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
