- 27 Sep, 2023 40 commits
-
-
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 <krzysztof.kozlowski@linaro.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
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:
Colin Ian King <colin.i.king@gmail.com> 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:
-
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:
Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by:
-
Laurent Pinchart authored
Camera sensor drivers are highly subject to cargo cult programming, with back practices being copied from old to new drivers. In particular, many drivers implement system and runtime PM incorrectly. As a first step towards fixing this situation, refactor and expand the power management documentation to detail correct usage of system and runtime PM. Signed-off-by:
-
Laurent Pinchart authored
Move the power management section up, just after clocks, as it relates to internal system resources and not features exposed to applications. The text itself is otherwise unchanged. Signed-off-by:
-
Laurent Pinchart authored
The Documentation/devicetree/bindings/clock/clock-bindings.txt file is deprecated and points to clock-bindings.yaml, which is not hosted in the kernel source tree. Use an HTTPS link to refer to the YAML binding document. While at it, drop "currently" from the paragraph, as the whole file refers to the current recommended practices except where explicitly noted. Signed-off-by:
-
Laurent Pinchart authored
Drop an unneeded double colon, and use 'shall' instead of 'must' for consistency with the rest of the file. Signed-off-by:
-
Laurent Pinchart authored
The subdev .s_stream() operation shall not be called to start streaming on an already started subdev, or stop streaming on a stopped subdev. Remove the check that guards against that condition. Signed-off-by:
-
Laurent Pinchart authored
The subdev .s_stream() operation shall not be called to start streaming on an already started subdev, or stop streaming on a stopped subdev. Remove the check that guards against that condition. The streaming field of the driver's private structure is now unused, drop it as well. Signed-off-by:
-
Laurent Pinchart authored
The subdev .s_stream() operation shall not be called to start streaming on an already started subdev, or stop streaming on a stopped subdev. Remove the check that guards against that condition. Signed-off-by:
-
