Add support for Talos EVK camera#193
Closed
wenmliu wants to merge 28 commits intoqualcomm-linux:qcom-6.18.yfrom
Closed
Add support for Talos EVK camera#193wenmliu wants to merge 28 commits intoqualcomm-linux:qcom-6.18.yfrom
wenmliu wants to merge 28 commits intoqualcomm-linux:qcom-6.18.yfrom
Conversation
6fd5fd7 to
010c9e5
Compare
…PPI partitions The ARM PMUs shares the same per-cpu (PPI) interrupt, so we need to switch to interrupt-cells = <4> in the GIC node to allow adding an interrupt partition map phandle as the 4th cell value for GIC_PPI interrupts. Link: https://lore.kernel.org/all/20260108092542.1371-2-yuanjie.yang@oss.qualcomm.com/ Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Add device tree bindings for Qualcomm SM8650 camera subsystem. Qualcomm SM8650 CAMSS IP contains the next subdevices: * 6 x CSIPHY, * 3 x CSID, 2 x CSID Lite, * 3 x IFE, 2 x IFE Lite. Link: https://lore.kernel.org/linux-media/20251017031131.2232687-2-vladimir.zapolskiy@linaro.org/ Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Add bindings for qcom,msm8939-camss in order to support the camera subsystem for MSM8939. Link: https://lore.kernel.org/all/20251030-camss-8x39-vbif-v8-1-754834937f5c@apitzsch.eu/ Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> [André: Make order of items the same as in 8916] Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: André Apitzsch <git@apitzsch.eu>
Add the msm8953 CCI device string compatible. Link: https://lore.kernel.org/all/20251028-msm8953-cci-v2-1-b5f9f7135326@lucaweiss.eu/ Signed-off-by: Luca Weiss <luca@lucaweiss.eu> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Add SM8750 compatible consistent with CAMSS CCI interfaces. Link: https://lore.kernel.org/r/20251126-add-support-for-camss-on-sm8750-v1-1-646fee2eb720@oss.qualcomm.com Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
…er count Replace the hardcoded buffer count value with a macro to enable operating on these buffers elsewhere in the CAMSS driver based on this count. Some of the hardware architectures require deferring the AUP and REG update until after the CSID configuration and this macro is expected to be useful in such scenarios. Link: https://lore.kernel.org/all/20251014-use-marco-to-denote-image-buffer-number-v1-1-f782e4cc622d@oss.qualcomm.com/ Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
…i clock On hardware architectures where a single CAMNOC module is split into two, one for each of the real time (RT) and non real time (NRT) modules within camera sub system, processing VFE output over the AXI bus requires enabling and setting the appropriate clock rate for the RT CAMNOC. This change lays the groundwork for supporting such configurations. Link: https://lore.kernel.org/all/20251014-add-new-clock-in-vfe-matching-list-v1-1-0d965ccc8a3a@oss.qualcomm.com/ Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add the basic support of CAMSS IP on Qualcomm SM8650 SoC powered boards. SM8650 CAMSS provides: - 6 x CSIPHY, - 3 x CSID, 2 x CSID Lite, - 3 x VFE, 2 x VFE Lite. Link: https://lore.kernel.org/all/20251017031131.2232687-3-vladimir.zapolskiy@linaro.org/ Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
… SM8650 Add a configuration for all CSI lanes into D-PHY bus mode on Qualcomm SM8650 CAMSS CSIPHY IPs. Link: https://lore.kernel.org/all/20251017031131.2232687-4-vladimir.zapolskiy@linaro.org/ Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Some devices need writing values to VFE VBIF registers. Add helper functions to do this. Link: https://lore.kernel.org/all/20251030-camss-8x39-vbif-v8-2-754834937f5c@apitzsch.eu/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: André Apitzsch <git@apitzsch.eu>
The camera subsystem for the MSM8939 is the same as MSM8916 except with
3 CSID instead of 2, and some higher clock rates.
As a quirk, this SoC needs writing values to 2 VFE VBIF registers
(see downstream msm8939-camera.dtsi vbif-{regs,settings} properties).
This fixes black stripes across sensor and garbage in CSID TPG outputs.
Add support for the MSM8939 camera subsystem.
Link: https://lore.kernel.org/all/20251030-camss-8x39-vbif-v8-3-754834937f5c@apitzsch.eu/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org>
Signed-off-by: André Apitzsch <git@apitzsch.eu>
The current value of '0xb0' that represents the offset to the status registers within the common registers of the CSIPHY has been changed on the newer SOCs and it requires generalizing the macro using a new variable 'common_status_offset'. This variable is initialized in the csiphy_init() function. Link: https://lore.kernel.org/all/20260112-camss-extended-csiphy-macro-v2-1-ee7342f2aaf5@oss.qualcomm.com/ Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
…n CSIPHY Some Qualcomm regulators are configured with initial mode as HPM (High Power Mode), which may lead to higher power consumption. To reduce power usage, it's preferable to set the initial mode to LPM (Low Power Mode). To ensure the regulator can switch from LPM to HPM when needed, this patch adds current load configuration for CAMSS CSIPHY. This allows the regulator framework to scale the mode dynamically based on the load requirement. The current default value for current is uninitialized or random. To address this, initial current values are added for the following platforms: MSM8916, MSM8939, MSM8953, MSM8996, QCM2290, SDM670, SM8250, SC7280, SM8550, SM8650, QCS8300, SA8775P and X1E80100. For SDM660, SDM845, SC8280XP the value is set to 0, indicating that no default current value is configured, the other values are derived from the power grid. Link: https://lore.kernel.org/all/20251114082649.4240-1-wenmeng.liu@oss.qualcomm.com/ Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
…8550 VFE lite The clock is needed to stream images over a full VFE IP on SM8550 CAMSS, and it should not be enabled, when an image stream is routed over any of two lite VFE IPs on the SoC. Link: https://lore.kernel.org/all/20251020140227.2264634-1-vladimir.zapolskiy@linaro.org/ Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Acked-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
The CSID driver has some unused variables and function parameters that are no longer needed (due to refactoring). Clean up those unused elements: - Remove the `vc` parameter from `__csid_configure_rx()`. - Drop the unused `lane_cnt` variable. - Adjust call to `__csid_configure_rx()` accordingly. Link: https://lore.kernel.org/all/20251211135939.1779544-1-loic.poulain@oss.qualcomm.com/ Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
…_reg_update()
vfe_isr() iterates using MSM_VFE_IMAGE_MASTERS_NUM(7) as the loop
bound and passes the index to vfe_isr_reg_update(). However,
vfe->line[] array is defined with VFE_LINE_NUM_MAX(4):
struct vfe_line line[VFE_LINE_NUM_MAX];
When index is 4, 5, 6, the access to vfe->line[line_id] exceeds
the array bounds and resulting in out-of-bounds memory access.
Fix this by using separate loops for output lines and write masters.
Fixes: 4edc8ea ("media: camss: Add initial support for VFE hardware version Titan 480")
Link: https://lore.kernel.org/all/20251229075217.24679-1-alperyasinak1@gmail.com/
Signed-off-by: Alper Ak <alperyasinak1@gmail.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
…fwnode handling Since a few called V4L2 functions operate with fwnode arguments the change from OF device nodes to fwnodes brings a simplification to the code. The camss_parse_endpoint_node() function is called once by camss_probe(), and there is no use of knowing a number of asynchronously registered remote devices, so it makes sense to remove the related computation from the function. Link: https://lore.kernel.org/all/20251120004604.2573803-2-vladimir.zapolskiy@linaro.org/ Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
…ote() function Another code simplification makes parsing of remote endpoints easy. Link: https://lore.kernel.org/all/20251120004604.2573803-3-vladimir.zapolskiy@linaro.org/ Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Add bindings for the Camera Subsystem on the SM6150 SoC The SM6150 platform provides: - 2 x VFE (version 170), each with 3 RDI - 1 x VFE Lite (version 170), each with 4 RDI - 2 x CSID (version 170) - 1 x CSID Lite (version 170) - 3 x CSIPHY (version 2.0.0) - 1 x BPS (Bayer Processing Segment) - 1 x ICP (Imaging Control Processor) - 1 x IPE (Image Postprocessing Engine) - 1 x JPEG Encoder/Decoder - 1 x LRME (Low Resolution Motion Estimation) Link: https://lore.kernel.org/all/20260112-sm6150-camss-v4-1-0cd576d627f7@oss.qualcomm.com/ Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
The camera subsystem for SM6150 which is based on Spectra 230. For SM6150: - VFE and CSID version: 170 (vfe170, csid170) - CSIPHY version: csiphy-v2.0.1 (14nm) Link: https://lore.kernel.org/all/20260112-sm6150-camss-v4-2-0cd576d627f7@oss.qualcomm.com/ Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Add node for the SM6150 camera subsystem. Link: https://lore.kernel.org/all/20260122-sm6150_evk-v5-1-039b170450a3@oss.qualcomm.com/ Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Add the sm6150 CCI device string compatible. Link: https://lore.kernel.org/all/20260122-sm6150_evk-v5-2-039b170450a3@oss.qualcomm.com/ Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Qualcomm Talos SoC contains single controller, containing 2 I2C hosts. Link: https://lore.kernel.org/all/20260122-sm6150_evk-v5-3-039b170450a3@oss.qualcomm.com/ Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Define pinctrl definitions to enable camera master clocks on Talos. Link: https://lore.kernel.org/all/20260122-sm6150_evk-v5-4-039b170450a3@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Enable IMX577 via CCI on Taloss EVK Core Kit. The Talos EVK board does not include a camera sensor by default, this DTSO has enabled the Arducam 12.3MP IMX577 Mini Camera Module on the CSI-1 interface. Link: https://lore.kernel.org/all/20260122-sm6150_evk-v5-5-039b170450a3@oss.qualcomm.com/ Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
The %pe format specifier is designed to print error pointers. It prints a symbolic error name (eg. -EINVAL) and it makes the code simpler by omitting PTR_ERR(). This patch fixes this cocci report: ./i2c/imx412.c:931:3-10: WARNING: Consider using %pe to print PTR_ERR() Link: https://lore.kernel.org/all/20251013-ptr_err-v1-11-2c5efbd82952@chromium.org/ Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Assert the reset GPIO before first power up. This avoids a mismatch where the first power up (when the reset GPIO defaults deasserted) differs from subsequent cycles. Link: https://lore.kernel.org/all/20260123-imx412-v7-1-e58303f2b76b@oss.qualcomm.com/ Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
The Arducam IMX577 module requires a longer reset time than the 1000µs configured in the current driver. Increase the wait time after power-on to ensure proper initialization. Link: https://lore.kernel.org/all/20260123-imx412-v7-2-e58303f2b76b@oss.qualcomm.com/ Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
sgaud-quic
pushed a commit
that referenced
this pull request
Mar 10, 2026
…ipv6-nexthop-and-add-selftest' Jiayuan Chen says: ==================== net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop and add selftest syzbot reported a kernel panic [1] when an IPv4 route references a loopback IPv6 nexthop object: BUG: unable to handle page fault for address: ffff8d069e7aa000 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 6aa01067 P4D 6aa01067 PUD 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 2 UID: 0 PID: 530 Comm: ping Not tainted 6.19.0+ #193 PREEMPT RIP: 0010:ip_route_output_key_hash_rcu+0x578/0x9e0 RSP: 0018:ffffd2ffc1573918 EFLAGS: 00010286 RAX: ffff8d069e7aa000 RBX: ffffd2ffc1573988 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffd2ffc1573978 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d060d496000 R13: 0000000000000000 R14: ffff8d060399a600 R15: ffff8d06019a6ab8 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8d069e7aa000 CR3: 0000000106eb0001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ip_route_output_key_hash+0x86/0x1a0 __ip4_datagram_connect+0x2b5/0x4e0 udp_connect+0x2c/0x60 inet_dgram_connect+0x88/0xd0 __sys_connect_file+0x56/0x90 __sys_connect+0xa8/0xe0 __x64_sys_connect+0x18/0x30 x64_sys_call+0xfb9/0x26e0 do_syscall_64+0xd3/0x1510 entry_SYSCALL_64_after_hwframe+0x76/0x7e Reproduction: ip -6 nexthop add id 100 dev lo ip route add 172.20.20.0/24 nhid 100 ping -c1 172.20.20.1 # kernel crash Problem Description When a standalone IPv6 nexthop object is created with a loopback device, fib6_nh_init() misclassifies it as a reject route. Nexthop objects have no destination prefix (fc_dst=::), so fib6_is_reject() always matches any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. When an IPv4 route later references this nexthop and triggers a route lookup, __mkroute_output() calls raw_cpu_ptr(nhc->nhc_pcpu_rth_output) on a NULL pointer, causing a page fault. The reject classification was designed for regular IPv6 routes to prevent kernel routing loops, but nexthop objects should not be subject to this check since they carry no destination information. Loop prevention is handled separately when the route itself is created. [1] https://syzkaller.appspot.com/bug?extid=334190e097a98a1b81bb ==================== Link: https://patch.msgid.link/20260304113817.294966-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Revert the cci dt-bindings code that conflicts with fromlist
Port the camss and cci dt-bindings code that has been applied
Add support for the Talos EVK camera, and then port the reverted cci dt-bindings code.
CRs-Fixed: 4416975