Hi,
This series adds support for CSI2 capture on J721E. It includes some
fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
driver, and finally adds the TI CSI2RX wrapper driver.
This series used to include the DPHY and DMA engine patches as well, but
they have been split off to facilitate easier merging. Patch 3 is
build-dependent on the DPHY series [0].
The DMA engine patch [1] can go in any order since that is only a run
time dependency. Things probably won't work without it but it will still
build fine.
Tested on TI's J721E with OV5640 sensor.
[0] https://patchwork.kernel.org/project/linux-phy/list/?series=506663&state=%2A&archive=both
[1] https://patchwork.kernel.org/project/linux-dmaengine/patch/20210624182449.31164-1-p.yadav@ti.com/
Changes in v3:
- Clean up the logic in ov5640_s_stream() a bit.
- Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync().
- Rename the label error_pm to disable_pm.
- Use v4l2_get_link_freq() to calculate pixel clock.
- Move DMA related fields in struct ti_csi2rx_dma.
- Protect DMA buffer queue with a spinlock to make sure the queue buffer
and DMA callback don't race on it.
- Track the current DMA state. It might go idle because of a lack of
buffers. This state can be used to restart it if needed.
- Do not include the current buffer in the pending queue. It is slightly
better modelling than leaving it at the head of the pending queue.
- Use the buffer as the callback argument, and add a reference to csi in it.
- If queueing a buffer to DMA fails, the buffer gets leaked and DMA gets
stalled with. Instead, report the error to vb2 and queue the next
buffer in the pending queue.
- DMA gets stalled if we run out of buffers since the callback is the
only one that fires subsequent transfers and it is no longer being
called. Check for that when queueing buffers and restart DMA if
needed.
- Do not put of node until we are done using the fwnode.
- Set inital format to UYVY 640x480.
- Add compatible: contains: const: cdns,csi2rx to allow SoC specific
compatible.
- Add more constraints for data-lanes property.
Changes in v2:
- Use phy_pm_runtime_get_sync() and phy_pm_runtime_put() before making
calls to set PHY mode, etc. to make sure it is ready.
- Use dmaengine_get_dma_device() instead of directly accessing
dma->device->dev.
- Do not set dst_addr_width when configuring slave DMA.
- Move to a separate subdir and rename to j721e-csi2rx.c
- Convert compatible to ti,j721e-csi2rx.
- Move to use Media Controller centric APIs.
- Improve cleanup in probe when one of the steps fails.
- Add colorspace to formats database.
- Set hw_revision on media_device.
- Move video device initialization to probe time instead of register time.
- Rename to ti,j721e-csi2rx.yaml
- Add an entry in MAINTAINERS.
- Add a description for the binding.
- Change compatible to ti,j721e-csi2rx to make it SoC specific.
- Remove description from dmas, reg, power-domains.
- Remove a limit of 2 from #address-cells and #size-cells.
- Fix add ^ to csi-bridge subnode regex.
- Make ranges mandatory.
- Add unit address in example.
- Add a reference to cdns,csi2rx in csi-bridge subnode.
- Expand the example to include the csi-bridge subnode as well.
- Re-order subject prefixes.
- Convert OV5640 to use runtime PM and drop Cadence CSI2RX s_power patch.
- Drop subdev call wrappers from cdns-csi2rx.
- Move VPE and CAL to a separate subdir.
- Rename ti-csi2rx.c to j721e-csi2rx.c
Pratyush Yadav (11):
media: ov5640: Use runtime PM to control sensor power
media: cadence: csi2rx: Unregister v4l2 async notifier
media: cadence: csi2rx: Add external DPHY support
media: cadence: csi2rx: Soft reset the streams before starting capture
media: cadence: csi2rx: Set the STOP bit when stopping a stream
media: cadence: csi2rx: Fix stream data configuration
media: cadence: csi2rx: Populate subdev devnode
media: Re-structure TI platform drivers
media: ti: Add CSI2RX support for J721E
media: dt-bindings: Add DT bindings for TI J721E CSI2RX driver
media: dt-bindings: Convert Cadence CSI2RX binding to YAML
.../devicetree/bindings/media/cdns,csi2rx.txt | 100 --
.../bindings/media/cdns,csi2rx.yaml | 169 +++
.../bindings/media/ti,j721e-csi2rx.yaml | 101 ++
MAINTAINERS | 10 +-
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/ov5640.c | 127 ++-
drivers/media/platform/Kconfig | 12 +
drivers/media/platform/Makefile | 2 +-
drivers/media/platform/cadence/cdns-csi2rx.c | 189 +++-
drivers/media/platform/ti/Makefile | 4 +
drivers/media/platform/ti/cal/Makefile | 3 +
.../{ti-vpe => ti/cal}/cal-camerarx.c | 0
.../platform/{ti-vpe => ti/cal}/cal-video.c | 0
.../media/platform/{ti-vpe => ti/cal}/cal.c | 0
.../media/platform/{ti-vpe => ti/cal}/cal.h | 0
.../platform/{ti-vpe => ti/cal}/cal_regs.h | 0
.../media/platform/ti/j721e-csi2rx/Makefile | 2 +
.../platform/ti/j721e-csi2rx/j721e-csi2rx.c | 978 ++++++++++++++++++
.../platform/{ti-vpe => ti/vpe}/Makefile | 4 -
.../media/platform/{ti-vpe => ti/vpe}/csc.c | 0
.../media/platform/{ti-vpe => ti/vpe}/csc.h | 0
.../media/platform/{ti-vpe => ti/vpe}/sc.c | 0
.../media/platform/{ti-vpe => ti/vpe}/sc.h | 0
.../platform/{ti-vpe => ti/vpe}/sc_coeff.h | 0
.../media/platform/{ti-vpe => ti/vpe}/vpdma.c | 0
.../media/platform/{ti-vpe => ti/vpe}/vpdma.h | 0
.../platform/{ti-vpe => ti/vpe}/vpdma_priv.h | 0
.../media/platform/{ti-vpe => ti/vpe}/vpe.c | 0
.../platform/{ti-vpe => ti/vpe}/vpe_regs.h | 0
29 files changed, 1533 insertions(+), 170 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
create mode 100644 Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml
create mode 100644 drivers/media/platform/ti/Makefile
create mode 100644 drivers/media/platform/ti/cal/Makefile
rename drivers/media/platform/{ti-vpe => ti/cal}/cal-camerarx.c (100%)
rename drivers/media/platform/{ti-vpe => ti/cal}/cal-video.c (100%)
rename drivers/media/platform/{ti-vpe => ti/cal}/cal.c (100%)
rename drivers/media/platform/{ti-vpe => ti/cal}/cal.h (100%)
rename drivers/media/platform/{ti-vpe => ti/cal}/cal_regs.h (100%)
create mode 100644 drivers/media/platform/ti/j721e-csi2rx/Makefile
create mode 100644 drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c
rename drivers/media/platform/{ti-vpe => ti/vpe}/Makefile (78%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/csc.c (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/csc.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/sc.c (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/sc.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/sc_coeff.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpdma.c (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpdma.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpdma_priv.h (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpe.c (100%)
rename drivers/media/platform/{ti-vpe => ti/vpe}/vpe_regs.h (100%)
--
2.30.0
TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
capture over a CSI-2 bus. The TI CSI2RX platform driver glues all the
parts together.
Signed-off-by: Pratyush Yadav <redacted>
---
(no changes since v2)
Changes in v2:
- Rename to ti,j721e-csi2rx.yaml
- Add an entry in MAINTAINERS.
- Add a description for the binding.
- Change compatible to ti,j721e-csi2rx to make it SoC specific.
- Remove description from dmas, reg, power-domains.
- Remove a limit of 2 from #address-cells and #size-cells.
- Fix add ^ to csi-bridge subnode regex.
- Make ranges mandatory.
- Add unit address in example.
- Add a reference to cdns,csi2rx in csi-bridge subnode.
- Expand the example to include the csi-bridge subnode as well.
- Re-order subject prefixes.
.../bindings/media/ti,j721e-csi2rx.yaml | 101 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 102 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml
From: Rob Herring <robh@kernel.org> Date: 2021-07-01 14:02:52
On Fri, 25 Jun 2021 00:51:59 +0530, Pratyush Yadav wrote:
TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
capture over a CSI-2 bus. The TI CSI2RX platform driver glues all the
parts together.
Signed-off-by: Pratyush Yadav <redacted>
---
(no changes since v2)
Changes in v2:
- Rename to ti,j721e-csi2rx.yaml
- Add an entry in MAINTAINERS.
- Add a description for the binding.
- Change compatible to ti,j721e-csi2rx to make it SoC specific.
- Remove description from dmas, reg, power-domains.
- Remove a limit of 2 from #address-cells and #size-cells.
- Fix add ^ to csi-bridge subnode regex.
- Make ranges mandatory.
- Add unit address in example.
- Add a reference to cdns,csi2rx in csi-bridge subnode.
- Expand the example to include the csi-bridge subnode as well.
- Re-order subject prefixes.
.../bindings/media/ti,j721e-csi2rx.yaml | 101 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 102 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,j721e-csi2rx.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/media/cdns,csi2rx.yaml'
xargs: dt-doc-validate: exited with status 255; aborting
make[1]: *** Deleting file 'Documentation/devicetree/bindings/media/ti,j721e-csi2rx.example.dt.yaml'
Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/media/cdns,csi2rx.yaml'
make[1]: *** [scripts/Makefile.lib:380: Documentation/devicetree/bindings/media/ti,j721e-csi2rx.example.dt.yaml] Error 255
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1416: dt_binding_check] Error 2
\ndoc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1496774
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
@@ -1,100 +0,0 @@-Cadence MIPI-CSI2 RX controller-===============================--The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI-lanes in input, and 4 different pixel streams in output.--Required properties:- - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible- - reg: base address and size of the memory mapped region- - clocks: phandles to the clocks driving the controller- - clock-names: must contain:- * sys_clk: main clock- * p_clk: register bank clock- * pixel_if[0-3]_clk: pixel stream output clock, one for each stream- implemented in hardware, between 0 and 3--Optional properties:- - phys: phandle to the external D-PHY, phy-names must be provided- - phy-names: must contain "dphy", if the implementation uses an- external D-PHY--Required subnodes:- - ports: A ports node with one port child node per device input and output- port, in accordance with the video interface bindings defined in- Documentation/devicetree/bindings/media/video-interfaces.txt. The- port nodes are numbered as follows:-- Port Description- ------------------------------ 0 CSI-2 input- 1 Stream 0 output- 2 Stream 1 output- 3 Stream 2 output- 4 Stream 3 output-- The stream output port nodes are optional if they are not- connected to anything at the hardware level or implemented- in the design.Since there is only one endpoint per port,- the endpoints are not numbered.---Example:--csi2rx: csi-bridge@0d060000 {- compatible = "cdns,csi2rx";- reg = <0x0d060000 0x1000>;- clocks = <&byteclock>, <&byteclock>- <&coreclock>, <&coreclock>,- <&coreclock>, <&coreclock>;- clock-names = "sys_clk", "p_clk",- "pixel_if0_clk", "pixel_if1_clk",- "pixel_if2_clk", "pixel_if3_clk";-- ports {- #address-cells = <1>;- #size-cells = <0>;-- port@0 {- reg = <0>;-- csi2rx_in_sensor: endpoint {- remote-endpoint = <&sensor_out_csi2rx>;- clock-lanes = <0>;- data-lanes = <1 2>;- };- };-- port@1 {- reg = <1>;-- csi2rx_out_grabber0: endpoint {- remote-endpoint = <&grabber0_in_csi2rx>;- };- };-- port@2 {- reg = <2>;-- csi2rx_out_grabber1: endpoint {- remote-endpoint = <&grabber1_in_csi2rx>;- };- };-- port@3 {- reg = <3>;-- csi2rx_out_grabber2: endpoint {- remote-endpoint = <&grabber2_in_csi2rx>;- };- };-- port@4 {- reg = <4>;-- csi2rx_out_grabber3: endpoint {- remote-endpoint = <&grabber3_in_csi2rx>;- };- };- };-};
@@ -1,100 +0,0 @@-Cadence MIPI-CSI2 RX controller-===============================--The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI-lanes in input, and 4 different pixel streams in output.--Required properties:- - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible- - reg: base address and size of the memory mapped region- - clocks: phandles to the clocks driving the controller- - clock-names: must contain:- * sys_clk: main clock- * p_clk: register bank clock- * pixel_if[0-3]_clk: pixel stream output clock, one for each stream- implemented in hardware, between 0 and 3--Optional properties:- - phys: phandle to the external D-PHY, phy-names must be provided- - phy-names: must contain "dphy", if the implementation uses an- external D-PHY--Required subnodes:- - ports: A ports node with one port child node per device input and output- port, in accordance with the video interface bindings defined in- Documentation/devicetree/bindings/media/video-interfaces.txt. The- port nodes are numbered as follows:-- Port Description- ------------------------------ 0 CSI-2 input- 1 Stream 0 output- 2 Stream 1 output- 3 Stream 2 output- 4 Stream 3 output-- The stream output port nodes are optional if they are not- connected to anything at the hardware level or implemented- in the design.Since there is only one endpoint per port,- the endpoints are not numbered.---Example:--csi2rx: csi-bridge@0d060000 {- compatible = "cdns,csi2rx";- reg = <0x0d060000 0x1000>;- clocks = <&byteclock>, <&byteclock>- <&coreclock>, <&coreclock>,- <&coreclock>, <&coreclock>;- clock-names = "sys_clk", "p_clk",- "pixel_if0_clk", "pixel_if1_clk",- "pixel_if2_clk", "pixel_if3_clk";-- ports {- #address-cells = <1>;- #size-cells = <0>;-- port@0 {- reg = <0>;-- csi2rx_in_sensor: endpoint {- remote-endpoint = <&sensor_out_csi2rx>;- clock-lanes = <0>;- data-lanes = <1 2>;- };- };-- port@1 {- reg = <1>;-- csi2rx_out_grabber0: endpoint {- remote-endpoint = <&grabber0_in_csi2rx>;- };- };-- port@2 {- reg = <2>;-- csi2rx_out_grabber1: endpoint {- remote-endpoint = <&grabber1_in_csi2rx>;- };- };-- port@3 {- reg = <3>;-- csi2rx_out_grabber2: endpoint {- remote-endpoint = <&grabber2_in_csi2rx>;- };- };-- port@4 {- reg = <4>;-- csi2rx_out_grabber3: endpoint {- remote-endpoint = <&grabber3_in_csi2rx>;- };- };- };-};
@@ -0,0 +1,169 @@+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/media/cdns,csi2rx.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Cadence MIPI-CSI2 RX controller++description:|+The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI+lanes in input, and 4 different pixel streams in output.++maintainers:+-Pratyush Yadav <p.yadav@ti.com>++properties:+compatible:+contains:+const:cdns,csi2rx++reg:+maxItems:1++clocks:+minItems:3+maxItems:6++clock-names:+minItems:3+maxItems:6
maxItems can be dropped here. Implied by items length.
@@ -1,100 +0,0 @@-Cadence MIPI-CSI2 RX controller-===============================--The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI-lanes in input, and 4 different pixel streams in output.--Required properties:- - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible- - reg: base address and size of the memory mapped region- - clocks: phandles to the clocks driving the controller- - clock-names: must contain:- * sys_clk: main clock- * p_clk: register bank clock- * pixel_if[0-3]_clk: pixel stream output clock, one for each stream- implemented in hardware, between 0 and 3--Optional properties:- - phys: phandle to the external D-PHY, phy-names must be provided- - phy-names: must contain "dphy", if the implementation uses an- external D-PHY--Required subnodes:- - ports: A ports node with one port child node per device input and output- port, in accordance with the video interface bindings defined in- Documentation/devicetree/bindings/media/video-interfaces.txt. The- port nodes are numbered as follows:-- Port Description- ------------------------------ 0 CSI-2 input- 1 Stream 0 output- 2 Stream 1 output- 3 Stream 2 output- 4 Stream 3 output-- The stream output port nodes are optional if they are not- connected to anything at the hardware level or implemented- in the design.Since there is only one endpoint per port,- the endpoints are not numbered.---Example:--csi2rx: csi-bridge@0d060000 {- compatible = "cdns,csi2rx";- reg = <0x0d060000 0x1000>;- clocks = <&byteclock>, <&byteclock>- <&coreclock>, <&coreclock>,- <&coreclock>, <&coreclock>;- clock-names = "sys_clk", "p_clk",- "pixel_if0_clk", "pixel_if1_clk",- "pixel_if2_clk", "pixel_if3_clk";-- ports {- #address-cells = <1>;- #size-cells = <0>;-- port@0 {- reg = <0>;-- csi2rx_in_sensor: endpoint {- remote-endpoint = <&sensor_out_csi2rx>;- clock-lanes = <0>;- data-lanes = <1 2>;- };- };-- port@1 {- reg = <1>;-- csi2rx_out_grabber0: endpoint {- remote-endpoint = <&grabber0_in_csi2rx>;- };- };-- port@2 {- reg = <2>;-- csi2rx_out_grabber1: endpoint {- remote-endpoint = <&grabber1_in_csi2rx>;- };- };-- port@3 {- reg = <3>;-- csi2rx_out_grabber2: endpoint {- remote-endpoint = <&grabber2_in_csi2rx>;- };- };-- port@4 {- reg = <4>;-- csi2rx_out_grabber3: endpoint {- remote-endpoint = <&grabber3_in_csi2rx>;- };- };- };-};
@@ -0,0 +1,169 @@+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/media/cdns,csi2rx.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Cadence MIPI-CSI2 RX controller++description:|+The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI+lanes in input, and 4 different pixel streams in output.++maintainers:+-Pratyush Yadav <p.yadav@ti.com>++properties:+compatible:+contains:+const:cdns,csi2rx++reg:+maxItems:1++clocks:+minItems:3+maxItems:6++clock-names:+minItems:3+maxItems:6
maxItems can be dropped here. Implied by items length.
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Date: 2021-07-01 07:56:54
Hi Pratyush,
On 24/06/2021 22:21, Pratyush Yadav wrote:
Hi,
This series adds support for CSI2 capture on J721E. It includes some
fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
driver, and finally adds the TI CSI2RX wrapper driver.
This series used to include the DPHY and DMA engine patches as well, but
they have been split off to facilitate easier merging. Patch 3 is
build-dependent on the DPHY series [0].
The DMA engine patch [1] can go in any order since that is only a run
time dependency. Things probably won't work without it but it will still
build fine.
Tested on TI's J721E with OV5640 sensor.
Hi Tomi,
Thanks for looking into the patches.
On 01/07/21 10:56AM, Tomi Valkeinen wrote:
Hi Pratyush,
On 24/06/2021 22:21, Pratyush Yadav wrote:
quoted
Hi,
This series adds support for CSI2 capture on J721E. It includes some
fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
driver, and finally adds the TI CSI2RX wrapper driver.
This series used to include the DPHY and DMA engine patches as well, but
they have been split off to facilitate easier merging. Patch 3 is
build-dependent on the DPHY series [0].
The DMA engine patch [1] can go in any order since that is only a run
time dependency. Things probably won't work without it but it will still
build fine.
Tested on TI's J721E with OV5640 sensor.
I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
Here are some notes from quick tests:
Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
I see this as well. I figured this had something to do with the sensor.
Which clock could cause this? I don't think anything in Cadence CSI2RX
bridge is sensitive to frame rate.
When I load the modules, I get:
[ 237.322258] platform 4504000.csi-bridge: Fixing up cyclic dependency with 9-003c
Ok, I enabled lockdep configs and I see it too. Will look into it.
I don't get this warning. I remember you reported this last time as
well. I tried reproducing this but have not managed to do so. I have
CONFIG_DMA_API_DEBUG and CONFIG_DMA_API_DEBUG_SG enabled.
What application/command do you use to run into this? I use yavta and
don't see this.
I get a warning from media graph walk:
I don't see this one either.
[ 299.066357] WARNING: CPU: 1 PID: 605 at drivers/media/mc/mc-entity.c:343 media_graph_walk_next+0x268/0x2cc
Line 343 seems to be
lockdep_assert_held(&entity->graph_obj.mdev->graph_mutex);
I wonder why I don't hit this even with lockdep configs (CONFIG_LOCKDEP,
CONFIG_DEBUG_LOCKDEP).
I tested unloading and reloading modules and it worked fine for me.
Maybe this is dependent on the order in which modules are inserted or
removed? Can you please share the order in which you loaded and unloaded
them?
Hi Tomi, Pratyush,
On Thu, Jul 08, 2021 at 12:26:38AM +0530, Pratyush Yadav wrote:
Hi Tomi,
Thanks for looking into the patches.
On 01/07/21 10:56AM, Tomi Valkeinen wrote:
quoted
Hi Pratyush,
On 24/06/2021 22:21, Pratyush Yadav wrote:
quoted
Hi,
This series adds support for CSI2 capture on J721E. It includes some
fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
driver, and finally adds the TI CSI2RX wrapper driver.
This series used to include the DPHY and DMA engine patches as well, but
they have been split off to facilitate easier merging. Patch 3 is
build-dependent on the DPHY series [0].
The DMA engine patch [1] can go in any order since that is only a run
time dependency. Things probably won't work without it but it will still
build fine.
Tested on TI's J721E with OV5640 sensor.
I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
Here are some notes from quick tests:
Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
I see this as well. I figured this had something to do with the sensor.
Tomi you might remember your patch to change the h/vtot values which I
collected in a series which I never managed to bring to v1, as Hugues
reported it was broken for JPEG capture.
I'll leave it here just for reference, I admit I dropped the ball
rather quickly there:
https://patchwork.linuxtv.org/project/linux-media/cover/20201028225706.110078-1-jacopo+renesas@jmondi.org/
I wish I could re-test but seems I've lost the powering cable of the
device I used to test ov5640 :(
Which clock could cause this? I don't think anything in Cadence CSI2RX
bridge is sensitive to frame rate.
quoted
When I load the modules, I get:
[ 237.322258] platform 4504000.csi-bridge: Fixing up cyclic dependency with 9-003c
Ok, I enabled lockdep configs and I see it too. Will look into it.
I don't get this warning. I remember you reported this last time as
well. I tried reproducing this but have not managed to do so. I have
CONFIG_DMA_API_DEBUG and CONFIG_DMA_API_DEBUG_SG enabled.
What application/command do you use to run into this? I use yavta and
don't see this.
quoted
I get a warning from media graph walk:
I don't see this one either.
quoted
[ 299.066357] WARNING: CPU: 1 PID: 605 at drivers/media/mc/mc-entity.c:343 media_graph_walk_next+0x268/0x2cc
Line 343 seems to be
lockdep_assert_held(&entity->graph_obj.mdev->graph_mutex);
I wonder why I don't hit this even with lockdep configs (CONFIG_LOCKDEP,
CONFIG_DEBUG_LOCKDEP).
I tested unloading and reloading modules and it worked fine for me.
Maybe this is dependent on the order in which modules are inserted or
removed? Can you please share the order in which you loaded and unloaded
them?
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Date: 2021-07-08 08:43:33
On 08/07/2021 11:19, Jacopo Mondi wrote:
Hi Tomi, Pratyush,
On Thu, Jul 08, 2021 at 12:26:38AM +0530, Pratyush Yadav wrote:
quoted
Hi Tomi,
Thanks for looking into the patches.
On 01/07/21 10:56AM, Tomi Valkeinen wrote:
quoted
Hi Pratyush,
On 24/06/2021 22:21, Pratyush Yadav wrote:
quoted
Hi,
This series adds support for CSI2 capture on J721E. It includes some
fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
driver, and finally adds the TI CSI2RX wrapper driver.
This series used to include the DPHY and DMA engine patches as well, but
they have been split off to facilitate easier merging. Patch 3 is
build-dependent on the DPHY series [0].
The DMA engine patch [1] can go in any order since that is only a run
time dependency. Things probably won't work without it but it will still
build fine.
Tested on TI's J721E with OV5640 sensor.
I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
Here are some notes from quick tests:
Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
I see this as well. I figured this had something to do with the sensor.
Tomi you might remember your patch to change the h/vtot values which I
collected in a series which I never managed to bring to v1, as Hugues
reported it was broken for JPEG capture.
I'll leave it here just for reference, I admit I dropped the ball
rather quickly there:
https://patchwork.linuxtv.org/project/linux-media/cover/20201028225706.110078-1-jacopo+renesas@jmondi.org/
I wish I could re-test but seems I've lost the powering cable of the
device I used to test ov5640 :(
Yes, I'm still using my hack patch when working with OV5640. With that
hack, on TI platforms with CAL IP, I get ~30fps. With this series on J7,
I get the above mentioned 28.98.
It's possible my hack patch is wrong, and CAL driver is buggy, but
together they make things right. I guess I should also try J7 without my
hack patch.
If I recall right, I tested your changes but I couldn't get them to work
on my HW.
I haven't worked on that since then, as I decided that debugging blind
is pointless. We need someone to analyze the signals to see what OV5640
is sending. Or some new understanding about the OV5640 HW.
Tomi
Hi Tomi, Pratyush,
On Thu, Jul 08, 2021 at 12:26:38AM +0530, Pratyush Yadav wrote:
quoted
Hi Tomi,
Thanks for looking into the patches.
On 01/07/21 10:56AM, Tomi Valkeinen wrote:
quoted
Hi Pratyush,
On 24/06/2021 22:21, Pratyush Yadav wrote:
quoted
Hi,
This series adds support for CSI2 capture on J721E. It includes some
fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
driver, and finally adds the TI CSI2RX wrapper driver.
This series used to include the DPHY and DMA engine patches as well, but
they have been split off to facilitate easier merging. Patch 3 is
build-dependent on the DPHY series [0].
The DMA engine patch [1] can go in any order since that is only a run
time dependency. Things probably won't work without it but it will still
build fine.
Tested on TI's J721E with OV5640 sensor.
I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
Here are some notes from quick tests:
Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
I see this as well. I figured this had something to do with the sensor.
Tomi you might remember your patch to change the h/vtot values which I
collected in a series which I never managed to bring to v1, as Hugues
reported it was broken for JPEG capture.
I'll leave it here just for reference, I admit I dropped the ball
rather quickly there:
https://patchwork.linuxtv.org/project/linux-media/cover/20201028225706.110078-1-jacopo+renesas@jmondi.org/
I wish I could re-test but seems I've lost the powering cable of the
device I used to test ov5640 :(
Yes, I'm still using my hack patch when working with OV5640. With that hack,
on TI platforms with CAL IP, I get ~30fps. With this series on J7, I get the
above mentioned 28.98.
It's possible my hack patch is wrong, and CAL driver is buggy, but together
they make things right. I guess I should also try J7 without my hack patch.
I think this is a OV5640 related issue. On IMX219 I am seeing exactly 30
fps.
If I recall right, I tested your changes but I couldn't get them to work on
my HW.
I haven't worked on that since then, as I decided that debugging blind is
pointless. We need someone to analyze the signals to see what OV5640 is
sending. Or some new understanding about the OV5640 HW.
Tomi
Hi Tomi,
On 01/07/21 10:56AM, Tomi Valkeinen wrote:
Hi Pratyush,
On 24/06/2021 22:21, Pratyush Yadav wrote:
quoted
Hi,
This series adds support for CSI2 capture on J721E. It includes some
fixes to the Cadence CSI2RX driver, adds runtime PM support to OV5640
driver, and finally adds the TI CSI2RX wrapper driver.
This series used to include the DPHY and DMA engine patches as well, but
they have been split off to facilitate easier merging. Patch 3 is
build-dependent on the DPHY series [0].
The DMA engine patch [1] can go in any order since that is only a run
time dependency. Things probably won't work without it but it will still
build fine.
Tested on TI's J721E with OV5640 sensor.
I applied these (csi-2 rx, phy, dma-engine) to linux-media/master, and added dts changes to add the csi2-rx. When sending the series, can you also push the branch you use for testing, as the posted patches do not include everything needed?
Here are some notes from quick tests:
Capture works, but the fps is ~28.98. I would expect it to be closer to 30. Are the clocks configured correctly?
When I load the modules, I get:
[ 237.322258] platform 4504000.csi-bridge: Fixing up cyclic dependency with 9-003c
I see this with CAL's OV5640 overlay as well. I think this is caused by
the endpoint nodes on csi-bridge and sensor pointing to each other. I
can't quite understand any bad implications of this warning since
everything seems to work correctly.
Should we model the connections between the sensor and CSI bridge
differently to not cause a cycle in the graph? Or can we just ignore
this warning since things seem to work fine despite it?
I still can't reproduce this, and I think this might be why. I am saving
the stream to a file and then replaying on my PC. You seem to be sending
it to a display. The DMA warning looks to be coming from DRM side, not
CSI.
Anyway, I think this is not a big problem. The UDMA driver simply does
not populate max_segment_size, so dma_get_max_seg_size() returns 64 KiB
as default. The hardware can actually support virtually unlimited
segment size for TR mode and 2^27 bytes for packet mode. CSI uses TR
mode so it can certainly handle more than 64 KiB long segments. I am not
sure which mode DRM uses but 2^27 is still much bigger than 1900544.
Long story short, this warning has little to do with the CSI patches
here and can be safely ignored IMO.
[ 298.943185] __map_dma_buf+0x28/0x80
[ 298.946756] dma_buf_map_attachment+0xe4/0x220
[ 298.951191] vb2_dc_map_dmabuf+0x3c/0x150
[ 298.955194] __prepare_dmabuf+0x1dc/0x514
[ 298.959197] __buf_prepare+0x1a0/0x25c
[ 298.962938] vb2_core_qbuf+0x3d4/0x72c
[ 298.966679] vb2_qbuf+0x9c/0xf4
[ 298.969814] vb2_ioctl_qbuf+0x68/0x7c
[ 298.973468] v4l_qbuf+0x54/0x70
[ 298.976603] __video_do_ioctl+0x194/0x400
[ 298.980603] video_usercopy+0x374/0xa14
[ 298.984431] video_ioctl2+0x24/0x4c
[ 298.987912] v4l2_ioctl+0x4c/0x70
[ 298.991222] __arm64_sys_ioctl+0xb4/0xfc
[ 298.995138] invoke_syscall+0x50/0x120
[ 298.998885] el0_svc_common.constprop.0+0x68/0x104
[ 299.003667] do_el0_svc+0x30/0x9c
[ 299.006976] el0_svc+0x2c/0x54
[ 299.010025] el0_sync_handler+0x1a8/0x1ac
[ 299.014025] el0_sync+0x198/0x1c0
[ 299.017333] irq event stamp: 98582
[ 299.020727] hardirqs last enabled at (98581): [<ffff8000100ec2bc>] console_unlock+0x53c/0x6b4
[ 299.029325] hardirqs last disabled at (98582): [<ffff800010be4bd4>] el1_dbg+0x24/0xa0
[ 299.037144] softirqs last enabled at (98568): [<ffff800010010ba0>] __do_softirq+0x500/0x6bc
[ 299.045565] softirqs last disabled at (98413): [<ffff80001005d504>] __irq_exit_rcu+0x1d4/0x1e0
[ 299.054164] ---[ end trace bfe019acb2a9a04f ]---
I get a warning from media graph walk:
Fixed this one. It was caused by the graph_mutex not being held.
Fixed this too. Both cdns-csi2rx and j721e-csi2rx share the same power
domain, but only j721e-csi2rx contains the power-domains property. If
you load cdns-csi2rx before j721e-csi2rx then the PD is not active and
register access causes an abort. Fixed by adding power-domains to the
csi-bridge node.
ERROR: Unhandled External Abort received on 0x80000001 from S-EL1
ERROR: exception reason=0 syndrome=0xbf000000
Unhandled Exception from EL1
[...]
--
Regards,
Pratyush Yadav
Texas Instruments Inc.