- Sep 09, 2023
-
-
In the current driver csid Test Pattern Generator (TPG) doesn't work. This change: - fixes writing frame width and height values into CSID_TPG_DT_n_CFG_0 - fixes the shift by one between test_pattern control value and the actual pattern. - drops fixed VC of 0x0a which testing showed prohibited some test patterns in the CSID to produce output. So that TPG starts working, but with the below limitations: - only test_pattern=9 works as it should - test_pattern=8 and test_pattern=7 produce black frame (all zeroes) - the rest of test_pattern's don't work (yavta doesn't get the data) - regardless of the CFA pattern set by 'media-ctl -V' the actual pixel order is always the same (RGGB for any RAW8 or RAW10P format in 4608x2592 resolution). Tested with: RAW10P format, VC0: media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4608x2592 field:none]' media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4608x2592 field:none]' media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]' v4l2-ctl -d /dev/v4l-subdev6 -c test_pattern=9 yavta -B capture-mplane --capture=3 -n 3 -f SRGGB10P -s 4608x2592 /dev/video0 RAW10P format, VC1: media-ctl -V '"msm_csid0":2[fmt:SRGGB10/4608x2592 field:none]' media-ctl -V '"msm_vfe0_rdi1":0[fmt:SRGGB10/4608x2592 field:none]' media-ctl -l '"msm_csid0":2->"msm_vfe0_rdi1":0[1]' v4l2-ctl -d /dev/v4l-subdev6 -c test_pattern=9 yavta -B capture-mplane --capture=3 -n 3 -f SRGGB10P -s 4608x2592 /dev/video1 RAW8 format, VC0: media-ctl --reset media-ctl -V '"msm_csid0":0[fmt:SRGGB8/4608x2592 field:none]' media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB8/4608x2592 field:none]' media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]' yavta -B capture-mplane --capture=3 -n 3 -f SRGGB8 -s 4608x2592 /dev/video0 Fixes: eebe6d00 ("media: camss: Add support for CSID hardware version Titan 170") Cc: stable@vger.kernel.org Signed-off-by:
Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Bryan O'Donoghue authoredVC_MODE = 0 implies a two bit VC address. VC_MODE = 1 is required for VCs with a larger address than two bits. Fixes: eebe6d00 ("media: camss: Add support for CSID hardware version Titan 170") Cc: stable@vger.kernel.org Signed-off-by:
-
Bryan O'Donoghue authored
define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7) disjunction for gen2 ? BIT(7) : is a nop we are setting the same bit either way. Fixes: 4abb2130 ("media: camss: csiphy: Move to hardcode CSI Clock Lane number") Cc: stable@vger.kernel.org Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
-
Bryan O'Donoghue authored
check_clock doesn't account for vfe_lite which means that vfe_lite will never get validated by this routine. Add the clock name to the expected set to remediate. Fixes: 7319cdf1 ("media: camss: Add support for VFE hardware version Titan 170") Cc: stable@vger.kernel.org Signed-off-by:
-
Bryan O'Donoghue authored
vfe-480 is copied from vfe-17x and has the same racy idle timeout bug as in 17x. Fix the vfe_disable_output() logic to no longer be racy and to conform to the 17x way of quiescing and then resetting the VFE. Fixes: 4edc8eae ("media: camss: Add initial support for VFE hardware version Titan 480") Cc: stable@vger.kernel.org Signed-off-by:
-
Bryan O'Donoghue authored
There are two problems with the current vfe_disable_output() routine. Firstly we rightly use a spinlock to protect output->gen2.active_num everywhere except for in the IDLE timeout path of vfe_disable_output(). Even if that is not racy "in practice" somehow it is by happenstance not by design. Secondly we do not get consistent behaviour from this routine. On sc8280xp 50% of the time I get "VFE idle timeout - resetting". In this case the subsequent capture will succeed. The other 50% of the time, we don't hit the idle timeout, never do the VFE reset and subsequent captures stall indefinitely. Rewrite the vfe_disable_output() routine to - Quiesce write masters with vfe_wm_stop() - Set active_num = 0 remembering to hold the spinlock when we do so followed by - Reset the VFE Testing on sc8280xp and sdm845 shows this to be a valid fix. Fixes: 7319cdf1 ("media: camss: Add support for VFE hardware version Titan 170") Cc: stable@vger.kernel.org Signed-off-by:
-
Bryan O'Donoghue authored
Right now it is possible to do a vfe_get() with the internal reference count at 1. If vfe_check_clock_rates() returns non-zero then we will leave the reference count as-is and run: - pm_runtime_put_sync() - vfe->ops->pm_domain_off() skip: - camss_disable_clocks() Subsequent vfe_put() calls will when the ref-count is non-zero unconditionally run: - pm_runtime_put_sync() - vfe->ops->pm_domain_off() - camss_disable_clocks() vfe_get() should not attempt to roll-back on error when the ref-count is non-zero as the upper layers will still do their own vfe_put() operations. vfe_put() will drop the reference count and do the necessary power domain release, the cleanup jumps in vfe_get() should only be run when the ref-count is zero. [ 50.095796] CPU: 7 PID: 3075 Comm: cam Not tainted 6.3.2+ #80 [ 50.095798] Hardware name: LENOVO 21BXCTO1WW/21BXCTO1WW, BIOS N3HET82W (1.54 ) 05/26/2023 [ 50.095799] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 50.095802] pc : refcount_warn_saturate+0xf4/0x148 [ 50.095804] lr : refcount_warn_saturate+0xf4/0x148 [ 50.095805] sp : ffff80000c7cb8b0 [ 50.095806] x29: ffff80000c7cb8b0 x28: ffff16ecc0e3fc10 x27: 0000000000000000 [ 50.095810] x26: 0000000000000000 x25: 0000000000020802 x24: 0000000000000000 [ 50.095813] x23: ffff16ecc7360640 x22: 00000000ffffffff x21: 0000000000000005 [ 50.095815] x20: ffff16ed175f4400 x19: ffffb4d9852942a8 x18: ffffffffffffffff [ 50.095818] x17: ffffb4d9852d4a48 x16: ffffb4d983da5db8 x15: ffff80000c7cb320 [ 50.095821] x14: 0000000000000001 x13: 2e656572662d7265 x12: 7466612d65737520 [ 50.095823] x11: 00000000ffffefff x10: ffffb4d9850cebf0 x9 : ffffb4d9835cf954 [ 50.095826] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000057fa8 [ 50.095829] x5 : ffff16f813fe3d08 x4 : 0000000000000000 x3 : ffff621e8f4d2000 [ 50.095832] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff16ed32119040 [ 50.095835] Call trace: [ 50.095836] refcount_warn_saturate+0xf4/0x148 [ 50.095838] device_link_put_kref+0x84/0xc8 [ 50.095843] device_link_del+0x38/0x58 [ 50.095846] vfe_pm_domain_off+0x3c/0x50 [qcom_camss] [ 50.095860] vfe_put+0x114/0x140 [qcom_camss] [ 50.095869] csid_set_power+0x2c8/0x408 [qcom_camss] [ 50.095878] pipeline_pm_power_one+0x164/0x170 [videodev] [ 50.095896] pipeline_pm_power+0xc4/0x110 [videodev] [ 50.095909] v4l2_pipeline_pm_use+0x5c/0xa0 [videodev] [ 50.095923] v4l2_pipeline_pm_get+0x1c/0x30 [videodev] [ 50.095937] video_open+0x7c/0x100 [qcom_camss] [ 50.095945] v4l2_open+0x84/0x130 [videodev] [ 50.095960] chrdev_open+0xc8/0x250 [ 50.095964] do_dentry_open+0x1bc/0x498 [ 50.095966] vfs_open+0x34/0x40 [ 50.095968] path_openat+0xb44/0xf20 [ 50.095971] do_filp_open+0xa4/0x160 [ 50.095974] do_sys_openat2+0xc8/0x188 [ 50.095975] __arm64_sys_openat+0x6c/0xb8 [ 50.095977] invoke_syscall+0x50/0x128 [ 50.095982] el0_svc_common.constprop.0+0x4c/0x100 [ 50.095985] do_el0_svc+0x40/0xa8 [ 50.095988] el0_svc+0x2c/0x88 [ 50.095991] el0t_64_sync_handler+0xf4/0x120 [ 50.095994] el0t_64_sync+0x190/0x198 [ 50.095996] ---[ end trace 0000000000000000 ]--- Fixes: 77909691 ("media: camss: vfe: Fix runtime PM imbalance on error") Cc: stable@vger.kernel.org Signed-off-by:
-
Bryan O'Donoghue authored
Right now we never release the power-domains properly on the error path. Add a routine to be reused for this purpose and appropriate jumps in probe() to run that routine where necessary. Fixes: 2f6f8af6 ("media: camss: Refactor VFE power domain toggling") Cc: stable@vger.kernel.org Signed-off-by:
-
Bryan O'Donoghue authored
Previously the jump label err_cleanup was used higher in the probe() function to release the async notifier however the async notifier registration was moved later in the code rendering the previous four jumps redundant. Rename the label from err_cleanup to err_v4l2_device_register to capture what the jump does. Fixes: 51397a4e ("media: qcom: Initialise V4L2 async notifier later") Signed-off-by:
-
Bryan O'Donoghue authored
We need to make sure camss_configure_pd() happens before camss_register_entities() as the vfe_get() path relies on the pointer provided by camss_configure_pd(). Fix the ordering sequence in probe to ensure the pointers vfe_get() demands are present by the time camss_register_entities() runs. In order to facilitate backporting to stable kernels I've moved the configure_pd() call pretty early on the probe() function so that irrespective of the existence of the old error handling jump labels this patch should still apply to -next circa Aug 2023 to v5.13 inclusive. Fixes: 2f6f8af6 ("media: camss: Refactor VFE power domain toggling") Cc: stable@vger.kernel.org Signed-off-by:
-
Platforms with qcom-camss use CSI-2, which means 1X16 is more correct than 2X8. The fact that qcom-camss supported only 2X8 meant it was incompatible with camera sensors it should have been compatible with. For example, the ov5645 driver (correctly) reports that its format is UYVY8_1X16 (after ba449bb5). Since qcom-camss only supports 2X8, the qcom-camss system is incompatible with the ov5645 driver, even though they should be compatible. This patch replaces all uses of UYVY8_2X8/VYUY8_2X8/YUYV8_2X8/YVYU8_2X8 with the equivalent 1X16 formats. Signed-off-by:
Martin Dørum <dorum@noisolation.com <mailto:dorum@noisolation.com>> Signed-off-by:
-
- Sep 08, 2023
-
-
Bryan O'Donoghue authored
Signed-off-by: -
Bryan O'Donoghue authored
Signed-off-by: -
Initialise V4L2 async notifier and parse DT for async sub-devices later, just before registering the notifier. This way the device can be made available to the V4L2 async framework from the notifier init time onwards. A subsequent patch will add struct v4l2_device as an argument to v4l2_async_nf_init(). Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> # imx6qp Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> # rcar + adv746x Tested-by: Aishwarya Kothari <aishwarya.kothari@toradex.com> # Apalis i.MX6Q with TC358743 Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # Renesas RZ/G2L SMARC Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
- Sep 05, 2023
-
-
Adrien Thierry authored
Currently, PCS_USB registers that have their initialization data in a pcs_usb_tbl table are never initialized. Fix that. Fixes: fc646236 ("phy: qcom-qmp-combo,usb: add support for separate PCS_USB region") Signed-off-by:
Adrien Thierry <athierry@redhat.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230828152353.16529-2-athierry@redhat.com
-
Konrad Dybcio authoredDisappointigly, the camera activity LED is implemented in software. Hook it up as a gpio-led and (until we have camera *and* a "camera on" LED trigger) configure it as a panic indicator. Signed-off-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Signed-off-by:
Andrei Coardos <aboutphysycs@gmail.com> Reviewed-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Link: https://lore.kernel.org/r/20230814181823.3662-1-aboutphysycs@gmail.com
-
Konrad Dybcio authored
Some TLMM pins are wakeup-capable. Describe the relationship between these two peripherals to enable this functionality. Signed-off-by:
-
Konrad Dybcio authored
Some TLMM pins are wakeup-capable. Describe the relationship between these two peripherals to enable this functionality. Signed-off-by:
-
Konrad Dybcio authored
Some TLMM pins are wakeup-capable. Describe the relationship between these two peripherals to enable this functionality. Signed-off-by:
-
Konrad Dybcio authored
Some TLMM pins are wakeup-capable. Describe the relationship between these two peripherals to enable this functionality. Signed-off-by:
-
Konrad Dybcio authored
Add support for the PDC to enable deep sleep wakeup from external sources. Signed-off-by:
-
Konrad Dybcio authored
Like all other RPMh-enabled SoCs, SDM670 includes a PDC. Document it. Signed-off-by:
-
Konrad Dybcio authored
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: f29dabda ("interconnect: qcom: Add SC8280XP interconnect provider") Signed-off-by:
-
Konrad Dybcio authored
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 9c8c6bac ("interconnect: qcom: Add SC8180x providers") Signed-off-by:
-
Konrad Dybcio authored
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 46bdcac5 ("interconnect: qcom: Add SC7280 interconnect provider driver") Signed-off-by:
-
Konrad Dybcio authored
ACV expects an enable_mask corresponding to the APPS RSC, fill it in. Fixes: 1f51339f ("interconnect: qcom: Add QDU1000/QRU1000 interconnect driver") Signed-off-by:
-
Konrad Dybcio authored
BCMs with an enable_mask expect to only have that specific value written to them. The current implementation only works by miracle for BCMs with enable mask == BIT(0), as the minimal vote we've been using so far just so happens to be equal to that. Use the correct value with keepalive voting. Fixes: d8630f05 ("interconnect: qcom: Add support for mask-based BCMs") Reported-by:
-
Konrad Dybcio authored
We don't need all the complex arithmetic for BCMs utilizing enable_mask, as all we need to do is to determine whether there's any user (or keepalive) asking for it to be on. Separate the logic for such BCMs for a small speed boost. Suggested-by:
-
Steev Klimaszewski authored
-
Mani Sadhasivam authored
ASPM is supported by Qcom host controllers/bridges on most of the recent platforms and so the devices tested so far. But for enabling ASPM by default (without Kconfig/cmdline/sysfs), BIOS has to enable ASPM on both host bridge and downstream devices during boot. Unfortunately, none of the BIOS available on Qcom platforms enables ASPM. Due to this, the platforms making use of Qcom SoCs draw high power during runtime. To fix this power issue, users/distros have to enable ASPM using configs such as (Kconfig/cmdline/sysfs) or the BIOS has to start enabling ASPM. The latter may happen in the future, but that won't address the issue on current platforms. Also, asking users/distros to enable a feature to get the power management right would provide an unpleasant out-of-the-box experience. So the apt solution is to enable ASPM in the controller driver itself. And this is being accomplished by calling pci_enable_link_state() in the newly introduced host_post_init() callback for all the devices connected to the bus. This function enables all supported link low power states for both host bridge and the downstream devices. Due to limited testing, ASPM is only enabled for platforms making use of ops_1_9_0 callbacks. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20230809081840.16034-3-manivannan.sadhasivam@linaro.org
-
Mani Sadhasivam authored
This callback can be used by the platform drivers to do configuration once all the devices are scanned. Like changing LNKCTL of all downstream devices to enable ASPM etc... Signed-off-by:
-
Konrad Dybcio authored
Pins 83-86 and 158-160 are NC, so there's no point in keeping them reserved. Take care of that. Fixes: 32c23138 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree") Signed-off-by:
-
Krzysztof authoredQualcomm Soundwire v2.0.0 controller comes with new interrupt bit for ignored commands. Add code to handle it in the interrupt service routine. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230728112848.67092-2-krzysztof.kozlowski@linaro.org
-
Krzysztof authored
Soundwire v2.0.0 comes with a new register LINK_STATUS for the FRAME_GEN_ENABLED field (bit indicating that an active frame is running). The old register COMP_STATUS is still there and still works, although the new one is preferred in downstream sources. Probably because it allows to choose Soundwire instance per CPU. Most of the code allowing to use new register for Soundwire v2.0.0 was already there as part of commit 312355a6 ("soundwire: qcom: add support for v2.0.0 controller"), so switch to it in swrm_wait_for_frame_gen_enabled() function. This should not have functional impact, because the old register still behaves correctly. Signed-off-by:
-
Konrad Dybcio authored
The DISP_CC GDSCs have not been instructed to use the ret registers. Fix that. Fixes: 4a66e76f ("clk: qcom: Add SC8280XP display clock controller") Signed-off-by:
-
Steev Klimaszewski authored
I don't like limiting the cpu so early, so let it get a bit warmer before doing so.
-
Konrad Dybcio authored
There are three categories of compatibles within the driver: 1. Ones which were introduced without a qcom,scm fallback 2. Ones which were introduced with a qcom,scm fallback 3. Ones which were defined but never used Keep 1 for backwards compatibility and axe 2 & 3. Signed-off-by:
-
Konrad Dybcio authored
If devm_clk_get_optional throws an error, something is really wrong. It may be a probe deferral, or it may be a problem with the clock provider. Regardless of what it may be, it should definitely not be ignored. Stop doing that. Signed-off-by:
-
Konrad Dybcio authored
The code for handling more than 1 clock is a bit messy and requires one to add new, SoC-specific compatibles if one wants to attach a clock. Switch devm_clk_get to devm_clk_get_optional to prevent throwing it from throwing errors when the clock is absent and defer checking the clock requirements to dt schema. This lets us get rid of compatibles that aren't necessary for backwards compatibility *and* will hopefully prevent the addition of meaningless new compatibles. Signed-off-by:
-
