Tags

media: qcom: camss: Fix two CAMSS bugs found by dogfooding with SoftISP

Dogfooding with SoftISP has uncovered two bugs in this series which I'm
posting fixes for.

- The first error:
  A simple race condition which to be honest I'm surprised I haven't found
  earlier nor has anybody else. Simply stated the order we typically
  end up loading CAMSS on boot has masked out the pm_runtime_enable() race
  condition that has been present in CAMSS for a long time.

  If you blacklist qcom-camss in modules.d and then modprobe after boot,
  the race condition shows up easily.

  Moving the pm_runtime_enable prior to subdevice registration fixes the
  problem.

The second error:
  Nomenclature:
    - CSIPHY: CSI Physical layer analogue to digital domain serialiser
    - CSID: CSI Decoder
    - VFE: Video Front End
    - RDI: Raw Data Interface
    - VC: Virtual Channel

  In order to support streaming multiple virtual-channels on the same RDI a
  V4L2 provided use_count variable is used to decide whether or not to actually
  terminate streaming and release buffers for 'msm_vfe_rdiX'.

  Unfortunately use_count indicates the number of times msm_vfe_rdiX has
  been opened by user-space not the number of concurrent streams on
  msm_vfe_rdiX.

  Simply stated use_count and stream_count are two different things.

  The silicon enabling code to select between VCs is valid but, a different
  solution needs to be found to support _concurrent_ VC streams.

  Right now the upstream use_count as-is is breaking the non concurrent VC
  case and I don't believe there are upstream users of concurrent VCs on
  CAMSS.

  This series implements a revert for the invalid use_count check,
  retaining the ability to select which VC is active on the RDI.

  Dogfooding with libcamera's SoftISP in Hangouts, Zoom and multiple runs
  of libcamera's "qcam" application is a very different test-case to the
  simple capture of frames we previously did when validating the
  'use_count' change.

  A partial revert in expectation of a renewed push to fixup that
  concurrent VC issue is included.

To: Robert Foss <rfoss@kernel.org>
To: Todor Tomov <todor.too@gmail.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Hans Verkuil <hansverk@cisco.com>
To: Hans Verkuil <hverkuil-cisco@xs4all.nl>
To: Milen Mitkov <quic_mmitkov@quicinc.com>
Cc: linux-media@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

---
Bryan O'Donoghue (2):
      media: qcom: camss: Remove use_count guard in stop_streaming
      media: qcom: camss: Fix ordering of pm_runtime_enable

 drivers/media/platform/qcom/camss/camss-video.c | 6 ------
 drivers/media/platform/qcom/camss/camss.c       | 5 +++--
 2 files changed, 3 insertions(+), 8 deletions(-)
---
base-commit: c6ce8f9ab92edc9726996a0130bfc1c408132d47
change-id: 20240713-linux-next-24-07-13-camss-fixes-fa98c0965a5d

Best regards,

Linux 6.10

media: ov5675: Fixup ov5675 reset failures

v3:
- Fixed my out-by-one 853 -> 85.3 us calc and the 900 us -> 90us calc as a
  result.
- Link to v2: https://lore.kernel.org/r/20240711-linux-next-ov5675-v2-1-d0ea6ac2e6e9@linaro.org

v2:
- Drop patch to read and act on reported XVCLK
- Use worst-case timings + a reasonable grace period in-lieu of previous
  xvclk calculations on power-on and power-off.
- Link to v1: https://lore.kernel.org/r/20240711-linux-next-ov5675-v1-0-69e9b6c62c16@linaro.org

v1:
One long running saga for me on the Lenovo X13s is the occasional failure
to either probe or subsequently bring-up the ov5675 main RGB sensor on the
laptop.

Initially I suspected the PMIC for this part as the PMIC is using a new
interface on an I2C bus instead of an SPMI bus. In particular I thought
perhaps the I2C write to PMIC had completed but the regulator output hadn't
become stable from the perspective of the SoC. This however doesn't appear
to be the case - I can introduce a delay of milliseconds on the PMIC path
without resolving the sensor reset problem.

Secondly I thought about reset pin polarity or drive-strength but, again
playing about with both didn't yield decent results.

I also played with the duration of reset to no avail.

The error manifested as an I2C write timeout to the sensor which indicated
that the chip likely hadn't come out reset. An intermittent fault appearing
in perhaps 1/10 or 1/20 reset cycles.

Looking at the expression of the reset we see that there is a minimum time
expressed in XVCLK cycles between reset completion and first I2C
transaction to the sensor. The specification calls out the minimum delay @
8192 XVCLK cycles and the ov5675 driver meets that timing almost exactly.

A little too exactly - testing finally showed that we were too racy with
respect to the minimum quiescence between reset completion and first
command to the chip.

Fixing this error I choose to base the fix again on the number of clocks
but to also support any clock rate the chip could support by moving away
from a define to reading and using the XVCLK.

True enough only 19.2 MHz is currently supported but for the hypothetical
case where some other frequency is supported in the future, I wanted the
fix introduced in this series to still hold.

Hence this series:

1. Allows for any clock rate to be used in the valid range for the reset.
2. Elongates the post-reset period based on clock cycles which can now
vary.

Patch #2 can still be backported to stable irrespective of patch #1.

To: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Quentin Schulz <quentin.schulz@theobroma-systems.com>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: Johan Hovold <johan@kernel.org>
Cc: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: dave.stevenson@raspberrypi.com
Cc: linux-media@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
Bryan O'Donoghue (1):
      media: ov5675: Fix power on/off delay timings

 drivers/media/i2c/ov5675.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
---
base-commit: 523b23f0bee3014a7a752c9bb9f5c54f0eddae88
change-id: 20240710-linux-next-ov5675-60b0e83c73f1

Best regards,

next-20240712

media: ov5675: Fixup ov5675 reset failures

v2:
- Drop patch to read and act on reported XVCLK
- Use worst-case timings + a reasonable grace period in-lieu of previous
  xvclk calculations on power-on and power-off.
- Link to v1: https://lore.kernel.org/r/20240711-linux-next-ov5675-v1-0-69e9b6c62c16@linaro.org

v1:
One long running saga for me on the Lenovo X13s is the occasional failure
to either probe or subsequently bring-up the ov5675 main RGB sensor on the
laptop.

Initially I suspected the PMIC for this part as the PMIC is using a new
interface on an I2C bus instead of an SPMI bus. In particular I thought
perhaps the I2C write to PMIC had completed but the regulator output hadn't
become stable from the perspective of the SoC. This however doesn't appear
to be the case - I can introduce a delay of milliseconds on the PMIC path
without resolving the sensor reset problem.

Secondly I thought about reset pin polarity or drive-strength but, again
playing about with both didn't yield decent results.

I also played with the duration of reset to no avail.

The error manifested as an I2C write timeout to the sensor which indicated
that the chip likely hadn't come out reset. An intermittent fault appearing
in perhaps 1/10 or 1/20 reset cycles.

Looking at the expression of the reset we see that there is a minimum time
expressed in XVCLK cycles between reset completion and first I2C
transaction to the sensor. The specification calls out the minimum delay @
8192 XVCLK cycles and the ov5675 driver meets that timing almost exactly.

A little too exactly - testing finally showed that we were too racy with
respect to the minimum quiescence between reset completion and first
command to the chip.

Fixing this error I choose to base the fix again on the number of clocks
but to also support any clock rate the chip could support by moving away
from a define to reading and using the XVCLK.

True enough only 19.2 MHz is currently supported but for the hypothetical
case where some other frequency is supported in the future, I wanted the
fix introduced in this series to still hold.

Hence this series:

1. Allows for any clock rate to be used in the valid range for the reset.
2. Elongates the post-reset period based on clock cycles which can now
vary.

Patch #2 can still be backported to stable irrespective of patch #1.

To: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Quentin Schulz <quentin.schulz@theobroma-systems.com>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: Johan Hovold <johan@kernel.org>
Cc: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: linux-media@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
Bryan O'Donoghue (1):
      media: ov5675: Fix power on/off delay timings

 drivers/media/i2c/ov5675.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
---
base-commit: 523b23f0bee3014a7a752c9bb9f5c54f0eddae88
change-id: 20240710-linux-next-ov5675-60b0e83c73f1

Best regards,

This is the 6.9.9 stable release

This is the 6.6.39 stable release

This is the 6.1.98 stable release

media: ov5675: Fixup ov5675 reset failures

One long running saga for me on the Lenovo X13s is the occasional failure
to either probe or subsequently bring-up the ov5675 main RGB sensor on the
laptop.

Initially I suspected the PMIC for this part as the PMIC is using a new
interface on an I2C bus instead of an SPMI bus. In particular I thought
perhaps the I2C write to PMIC had completed but the regulator output hadn't
become stable from the perspective of the SoC. This however doesn't appear
to be the case - I can introduce a delay of milliseconds on the PMIC path
without resolving the sensor reset problem.

Secondly I thought about reset pin polarity or drive-strength but, again
playing about with both didn't yield decent results.

I also played with the duration of reset to no avail.

The error manifested as an I2C write timeout to the sensor which indicated
that the chip likely hadn't come out reset. An intermittent fault appearing
in perhaps 1/10 or 1/20 reset cycles.

Looking at the expression of the reset we see that there is a minimum time
expressed in XVCLK cycles between reset completion and first I2C
transaction to the sensor. The specification calls out the minimum delay @
8192 XVCLK cycles and the ov5675 driver meets that timing almost exactly.

A little too exactly - testing finally showed that we were too racy with
respect to the minimum quiescence between reset completion and first
command to the chip.

Fixing this error I choose to base the fix again on the number of clocks
but to also support any clock rate the chip could support by moving away
from a define to reading and using the XVCLK.

True enough only 19.2 MHz is currently supported but for the hypothetical
case where some other frequency is supported in the future, I wanted the
fix introduced in this series to still hold.

Hence this series:

1. Allows for any clock rate to be used in the valid range for the reset.
2. Elongates the post-reset period based on clock cycles which can now
vary.

Patch #2 can still be backported to stable irrespective of patch #1.

To: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Quentin Schulz <quentin.schulz@theobroma-systems.com>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: Johan Hovold <johan@kernel.org>
Cc: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: linux-media@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

---
Bryan O'Donoghue (2):
      media: ov5675: Derive delay cycles from the clock rate reported
      media: ov5675: Elongate reset to first transaction minimum gap

 drivers/media/i2c/ov5675.c | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)
---
base-commit: 523b23f0bee3014a7a752c9bb9f5c54f0eddae88
change-id: 20240710-linux-next-ov5675-60b0e83c73f1

Best regards,

next-20240710

A few more Qualcomm clk updates for v6.11

This introduces helper logic to expose clock controllers as simple
interconnect providers, and used this on ipq9574 to add the the system's
interconnect providers.

CLK_SET_RATE_PARENT is added to the remaining USB pipe clocks on
X1Elite.

Error handling is improved in kpss-xcc, and lastly the SC8280XP LPASS
clock controller regmap_config is declared const.

A few more Arm64 DeviceTree updates for v6.11

This introduces support for Lenovo Thinkpad Yoga slim 7x, LG Leon LTE,
and LG K10 (K420n).

In addition to this, all Gen-1 platforms gets the DWC3 quirk to disable
"SuperSpeed in park mode", which resolves an instabliity issue seen in
host mode.

For Fairphone 4, PM6150L and PMK8003 thermal sensors are added and
thermal zones defined.

Two fastrpc contexts on SM6350 are marked as non-secure, to allow
non-secure usage.

The video clock controller on SM8150 is introduced. IPQ9574 GCC is
marked as a interconnect provider. The vibrator block in the PM6150 is
described.

On SC7280 the download mode register is defined for SCM, allowing it to
enable/disable the ramdump support during a system crash.

Lastly, add a mailmap entry for Luca Weiss.

One more Arm32 DeviceTree update for v6.11

This fixes the DeviceTree validation warning about MSM8960 /memory node
not having a unit address.

A few more Qualcomm driver updates for v6.11

This adds a quirk to skip using the newly introduced SHM Bridge
implementation while regressions are being investigated.

One occurance of return no_free_ptr() is replaced with return_ptr() to
make code easier to read. llcc, mdt_loader, ocmem, pdr, socinfo and
wcnss drivers gets simplified using cleanup.h.

This is the 6.6.38 stable release

Linux 6.10-rc7

Qualcomm clock updates for v6.11

This adds clock controllers for SM7150 camera, display and video,
QCM2290 GPU, QCS8386/QCS8084 NSS, SM8650 camera and video.

qcom_cc_really_probe() is transitioned to take a struct device, to allow
reuse in non-platform-drivers. Prepare-only branch clock ops are
introduced to support clocks on buses that takes locks.

The parent/child relationship for SC7280 camera GDSCs are added.

Support for the Huayra 2290 alpha PLL is added.

The highest SDCC clock frequency on IPQ6018 is adjusted to match the
HS200 support. For IPQ9574 missing PCIe PIPE clocks are added.

Various configuration and properties of the SA8775P, X1E80100 and SM7280
clocks and GDSCs are corrected. SM8350 GPU RCGs are made to park on XO
while disabled.

Unused CONFIG_QCOM_RPMCC Kconfig symbol is removed, and missing
MODULE_DESCRIPTIONs are added in a few drivers.

Qualcomm Arm64 DeviceTree updates for v6.11

This introduces 11 new boards, namely:
* ASUS Vivobook S 15
* Lenovo Smart Tab M10 DTS
* Motorola Moto E 2015 LTE (surnia)
* Motorola Moto G 2015 (osprey)
* Motorola Moto G4 Play (harpia)
* Qualcomm AIM300 AIoT development board
* Qualcomm SM8650 Hardware Development Kit (HDK)
* SHIFTphone 8
* Samsung Galaxy Z Fold5
* Schneider HMIBSC board DTS
* TP-Link Archer AX55 v1

Of particular interest here is the Asus Vivobook, the first supported X1
Elite consumer laptop.

For IPQ6018 an SDHCI controller is added and on IPQ9574 an MDIO bus is
described.

The improvements to MSM8916-based devices continues, with sound and
mdoem support added to Acer Iconia Talk S and GPLUS FL8005A, the latter
also gaining BMS support. Samsung Galaxy devices gains PMIC and charger
definitions, NFC support and MUIC. Accelerometer and magnetometer
support is added to the Samsung Galaxy Grand Prime devices.

On MSM8976 definitions for IOMMU, the display subsystem, wifi subsystem,
and Adreno GPU are added.

On MSM8996 UFS core clock frequencies are specified, FastRPC nodes are
added for the audio DSP, glink-edges are described where available, the
display subsystem reset is added.

Venus is introduced on MSM8998 and the "No MSA Ready" quirk is added to
allow ath10k to come up.

GPU support is added to QCM2290 and enabled on the RB1 development
board.
The I2C controller used for communicating with the LT9611UXC HDMI
bridge is temporarily replaced with i2c-gpio while issues with the
builtin controller is diagnosed. The same is done for RB2, on the
QRB4210 platform.
On RB2 TCPM max current draw is corrected and the vreg_l9a regulator is
marked as always on to match expectations.

On the QDU1000 platform, USB is added, secure QFPROM is introduced to
allow LLCC to access OTP data. USB is enabled on the two IDP boards.

SA8775p gains PCIe endpoint definitions, LLCCC support, IMEM and PIL
info regions. Nodes are marked as dma-coherent as needed, a dedicated
carveout for shared memory bridge allocations is introduced.
The SA8775P ride device is split in the two versions r2 and r3.

The SC7180 Trogdor clamshell/detachable fragments are refactored for
convenience, and pwmleds are disabled where unused.

On SC7280 the APR nodes for interfacing with the audio services in audio
DSP firmware are introduced. The Qualcomm SMMU TBUs are described, to
enable improved debug support. QoS clocks are added to interconnects, as
needed in order to operate the QoS settings on some buses.
SuperSpeed in park is disabled for the primary DWC3 instance to address
host controller issues under load.

The PM8008 (camera PMIC) is introduced in Fairphone 5, regulators are
named for better output, and firmware name for IPA is adjusted to the
preferred file format.
The HDMI bridge on Rb3gen2 is described, rtc, gpi-dma and qup nodes are
enabled.

The Type-C port manager found in PM7250b is enabled, for targets not
using pmic-glink firmware for Type-C management.

SC8180X gets a number of smaller corrections, and some cleanups -
related to both functional issues and DeviceTree validation.

The PSHOLD node is marked reserved, after reports that this causes
issues during shutdown. Description of the USB signals are updated to
match the signal path. The PM8008 camera PMIC is added to Lenovo
ThinkPad X13s.

The PM660 PMIC is extended with charger and rradc definitions, and the
SDM670 gains a SMEM region definition.

On SDM845 the Qualcomm SMMU TBU nodes are described, to enable improved
debug output during faults etc. The UFS PHY is associated with its GDSC,
and the DisplayPort controller is wired up to the QMP PHY.

The Lenovo Yoga C630 Embedded Controller is introduced, adding battery
and Type-C port management and altmode support. The C630 also gains WiFI
calibration variant information, to cause selection of the right data.
The missing IPA firmware path is corrected.

For the SDX75 platform, AOSS, IPCC, SDHCI, TCSR, modem SMP2P, I2C and
SPI nodes are introduced. SD-card support is added to the IDP board.

CPUfreq support is introduced for the SM4450 platform.

Missing reset is added to the SDHC controller of SM6115. The UFS PHY
is associated with its GDSC, so is the PHY on SM6350.

On Fairphone 4, the camera pmic (PM8008) is introduced, regulators are
named for more informative debug output, and USB role switching is
enabled.

On the Fairphone 3, vibrator support is added and enabled.

On SM8250, the USB signal paths are properly described in the OF graph,
the UFS PHY gains its required power-domains description.
Thanks to the introduction of PCI power sequence support, the QRB5165
RB5 WiFi chip can now be powered up, so this is added.

Touchscreen interrupt flags are corrected accross a number of Sony
Xperia devices, to remove the unexpected traces from downstream.

On SM8450 an OPP-table is introduced for the PCIe controllers, to
specify the bandwidth and performance state requirements for the
different genrations and link widths. For this the PCIe controllers also
gains interconnect path definitions. The LLCC register layout is
corrected, and the UFS PHY is associated with its GDSC.

On the SM8550 development boards speaker port mapping is added. WiFi
support is finally enabled on the QRD board.
The new AIM300 development platform/board is introduced.

For SM8650 video and camera clock controller are introduced. SCM node
gains details necessary to trigger USB ramdump (download mode) upon a
system crash.
WiFi support and speaker port mapping is added to the QRD and the newly
introduced HDK. On the MTP the USB Type-C connector is describe to be
routed to the PHY.
In addition to the base HDK, a Display Card overlay is also introduced.

For X1 Elite bwmon, fastrpc and GPU support, tsens, and the missing PCIe
6a instance are added. Thermal zones are described. Pmic-glink is
introduced for both CRD and QCP devices, and remaining PMICs are
described. Audio support is also added to the QCP.
An explicit, larger, chunk of CMA memory is added to the various
devices, in order to compensate for the lack of IOMMU for PCIe.

Across a wide range of platforms, the thermal zone polling delays are
removed as supplies are interrupt driven anyways. Also thermal related
is the introduction of GPU thermal throttling, across many SoCs.

The old SMSM implementation is finally transitioned to using the
mailbox-based description and implementation for invoking interrupts on
remote processors. As such interrupt-triggering is converted to use this
mechanism on related platforms.

The usb-role-switch property is removed for all USB instances hard coded
to either host or peripheral across a range of boards.

Qualcomm Arm64 defconfig updates for v6.11

This enables the newly introduce Shared Memory Bridge driver which
improves the mechansim with which buffers are shared with TrustZone.

It turns MSM8996, SM8150 and SM8350 interconnect providers to builtin,
as debug UART now depends on these.  The SM8350 GPU clock controller is
enabled.

The secure QFPROM driver is enabled, to provide access to OTP
configuration for the LLCC driver on the QDU1000 platform.

This is the 6.9.8 stable release