camxlib-hamoa: Update to the 1.0.25 revision

[gkhose-qipl]

add support to og0va1b sensor for Hamoa

[lumag]

add support to og0va1b sensor for Hamoa

Why is it being performed only for Hamoa? Can we have platform-independent sensors descriptions so that all platforms get updates at the same time? (okay, maybe all except Kodiak).

[vishverm-qli]

add support to og0va1b sensor for Hamoa

Why is it being performed only for Hamoa? Can we have platform-independent sensors descriptions so that all platforms get updates at the same time? (okay, maybe all except Kodiak).

The og0va1b sensor is applicable only to the Hamoa target, which is why this change is being made exclusively for the Hamoa target.

[lumag]

add support to og0va1b sensor for Hamoa

Why is it being performed only for Hamoa? Can we have platform-independent sensors descriptions so that all platforms get updates at the same time? (okay, maybe all except Kodiak).

The og0va1b sensor is applicable only to the Hamoa target, which is why this change is being made exclusively for the Hamoa target.

What prevents people using it with any other target?

[github-actions]

Test run workflow

Test jobs for commit d9dd83f

qcom-distro
Pass: 262 | Fail: 3 | Total: 296

nodistro
Pass: 9 | Fail: 0 | Total: 9

qcom-distro_linux-qcom-6.18
Pass: 6 | Fail: 1 | Total: 7

[test-reporting-app]

Test Results

  103 files  ± 0    633 suites  +1   6h 28m 8s ⏱️ + 1h 29m 58s
  128 tests ± 0    116 ✅ +14   0 💤 ±0  12 ❌  - 14 
6 026 runs  +18  5 957 ✅ +34  57 💤 +6  12 ❌  - 22 

For more details on these failures, see this check.

Results for commit d9dd83f. ± Comparison against base commit 5716703.

This pull request removes 3 and adds 3 tests. Note that renamed tests count towards both.

5_WiFi_Firmware_Driver ‑ WiFi_OnOff
lava ‑ auto-login-action
lava ‑ minimal-boot

14_Kubernetes_Kernel_Con[ ‑ Kubernetes_Kernel_Config
lava ‑ lava-test-retry
lava ‑ lava-test-shell

♻️ This comment has been updated with latest results.

[github-actions]

Test run workflow

Test jobs for commit d9dd83f

qcom-distro
Pass: 264 | Fail: 1 | Total: 296

nodistro
Pass: 9 | Fail: 0 | Total: 9

qcom-distro_linux-qcom-6.18
Pass: 212 | Fail: 6 | Total: 244

[vishverm-qli]

add support to og0va1b sensor for Hamoa

Why is it being performed only for Hamoa? Can we have platform-independent sensors descriptions so that all platforms get updates at the same time? (okay, maybe all except Kodiak).

The og0va1b sensor is applicable only to the Hamoa target, which is why this change is being made exclusively for the Hamoa target.

What prevents people using it with any other target?

The OG0VA1B sensor is currently supported only on the Hamoa EVK with a custom daughter card. While the driver can be retained for use across other targets, including it globally would add it to every target package, unnecessarily increasing the device footprint. Until the sensor is enabled through the kernel device tree for additional targets, it is preferable to keep the driver limited to the specific target to minimize the overall file count.

[lumag]

add support to og0va1b sensor for Hamoa

Why is it being performed only for Hamoa? Can we have platform-independent sensors descriptions so that all platforms get updates at the same time? (okay, maybe all except Kodiak).

The og0va1b sensor is applicable only to the Hamoa target, which is why this change is being made exclusively for the Hamoa target.

What prevents people using it with any other target?

The OG0VA1B sensor is currently supported only on the Hamoa EVK with a custom daughter card. While the driver can be retained for use across other targets, including it globally would add it to every target package, unnecessarily increasing the device footprint. Until the sensor is enabled through the kernel device tree for additional targets, it is preferable to keep the driver limited to the specific target to minimize the overall file count.

What prevents our customers from using the sensor with any other platform? You are just replying that there are no devboards using that sensor.

minimize the overall file count.

Why do we care about file count at all?

[vishverm-qli]

add support to og0va1b sensor for Hamoa

Why is it being performed only for Hamoa? Can we have platform-independent sensors descriptions so that all platforms get updates at the same time? (okay, maybe all except Kodiak).

The og0va1b sensor is applicable only to the Hamoa target, which is why this change is being made exclusively for the Hamoa target.

What prevents people using it with any other target?

The OG0VA1B sensor is currently supported only on the Hamoa EVK with a custom daughter card. While the driver can be retained for use across other targets, including it globally would add it to every target package, unnecessarily increasing the device footprint. Until the sensor is enabled through the kernel device tree for additional targets, it is preferable to keep the driver limited to the specific target to minimize the overall file count.

What prevents our customers from using the sensor with any other platform? You are just replying that there are no devboards using that sensor.

minimize the overall file count.

Why do we care about file count at all?

In addition to increasing the file count, other targets may have different hardware configurations such as sensor-to-PHY mapping, varying cell indices (slot IDs), and target-specific tuning binaries. As a result, this target-specific driver may not be compatible with other targets.

[lumag]

minimize the overall file count.

Why do we care about file count at all?

In addition to increasing the file count, other targets may have different hardware configurations such as sensor-to-PHY mapping, varying cell indices (slot IDs), and target-specific tuning binaries. As a result, this target-specific driver may not be compatible with other targets.

sensor-to-PHY mappings should depend on the board wiring. It is of no concern for the platform support.

Could you please point out the list of sensors / target combinations that are supported by CamX?

[vishverm-qli]

minimize the overall file count.

Why do we care about file count at all?

In addition to increasing the file count, other targets may have different hardware configurations such as sensor-to-PHY mapping, varying cell indices (slot IDs), and target-specific tuning binaries. As a result, this target-specific driver may not be compatible with other targets.

sensor-to-PHY mappings should depend on the board wiring. It is of no concern for the platform support.

Could you please point out the list of sensors / target combinations that are supported by CamX?

Target platforms and their supported sensors, along with unique Slot IDs, PHY laneconfig, and tuning settings:

Kodiak: IMX577, OV9282, IMX686, AR0231(GMSL)
LM: IMX577, OV9282, OX03F10(GMSL BAYER, YUV), 0x8D10(MIPI, GMSL)
Talos , IMX577_4Lane, IMX577_2Lane
Hamoa: OG0VA1B, IMX577

[lumag]

Is IMX577 4 lane, 2 lane or something else? Are those entries different anyhow?

[vishverm-qli]

Is IMX577 4 lane, 2 lane or something else? Are those entries different anyhow?

Yes. there are two CSI Ports having 2&4 lanes configuration respectively. IMX577 2L requires different mode setting as per the CSI lane count.

[lumag]

Is IMX577 4 lane, 2 lane or something else? Are those entries different anyhow?

Yes. there are two CSI Ports having 2&4 lanes configuration respectively. IMX577 2L requires different mode setting as per the CSI lane count.

Sorry, I was asking about the bare IMX577 config, does it support 2 lanes for 4 lanes? Why do we have two lanes config only for Talos?

[vishverm-qli]

Is IMX577 4 lane, 2 lane or something else? Are those entries different anyhow?

Yes. there are two CSI Ports having 2&4 lanes configuration respectively. IMX577 2L requires different mode setting as per the CSI lane count.

Sorry, I was asking about the bare IMX577 config, does it support 2 lanes for 4 lanes? Why do we have two lanes config only for Talos?

The IMX577 driver currently supports only 4L modes. The addition of 2L mode was requested specifically for Talos, as it is currently the only device with a 22-pin 2L CSI connector.

[lumag]

Is IMX577 4 lane, 2 lane or something else? Are those entries different anyhow?

Yes. there are two CSI Ports having 2&4 lanes configuration respectively. IMX577 2L requires different mode setting as per the CSI lane count.

Sorry, I was asking about the bare IMX577 config, does it support 2 lanes for 4 lanes? Why do we have two lanes config only for Talos?

The IMX577 driver currently supports only 4L modes. The addition of 2L mode was requested specifically for Talos, as it is currently the only device with a 22-pin 2L CSI connector.

Thanks. So what is the difference between IMX577 for Kodiak, Lemans, Talos and Hamoa?

Also, if the customer uses Hamoa SoM and wants to use a 2-lane connector for IMX577, does it require an update on the CamX side?

[vishverm-qli]

Is IMX577 4 lane, 2 lane or something else? Are those entries different anyhow?

Yes. there are two CSI Ports having 2&4 lanes configuration respectively. IMX577 2L requires different mode setting as per the CSI lane count.

Sorry, I was asking about the bare IMX577 config, does it support 2 lanes for 4 lanes? Why do we have two lanes config only for Talos?

The IMX577 driver currently supports only 4L modes. The addition of 2L mode was requested specifically for Talos, as it is currently the only device with a 22-pin 2L CSI connector.

Thanks. So what is the difference between IMX577 for Kodiak, Lemans, Talos and Hamoa?

Also, if the customer uses Hamoa SoM and wants to use a 2-lane connector for IMX577, does it require an update on the CamX side?

The IMX577 driver for Kodiak, Lemans, Talos, and Hamoa uses a separate Chromatix name for each target to load specific tuning, has individual slot-ids, and may be slightly tuned for each target.
For KLM, there is no 2L driver available. No code changes are needed but an update can be made through a sensor driver update.

[lumag]

The IMX577 driver for Kodiak, Lemans, Talos, and Hamoa uses a separate Chromatix name for each target to load specific tuning, has individual slot-ids, and may be slightly tuned for each target.

Why are there different names and different slots? It's the same sensor, being attached to a different base. Do we ISP-specific params or are we just adding the different name for the sake of keeping it different?

Why are the slot-ids different too?

For the tuning, is it 'might be' or 'is'? If it is just 'might be', we should drop that 'might', at least for the generic market / IoT.

[lumag]

The complexity of supporting diffferent sensors on different platforms doesn't seem (to me, sorry) to warrant possible gain.

[ricardosalveti]

Target platforms and their supported sensors, along with unique Slot IDs, PHY laneconfig, and tuning settings:

Kodiak: IMX577, OV9282, IMX686, AR0231(GMSL) LM: IMX577, OV9282, OX03F10(GMSL BAYER, YUV), 0x8D10(MIPI, GMSL) Talos , IMX577_4Lane, IMX577_2Lane Hamoa: OG0VA1B, IMX577

@gkhose-qipl please improve your git commit message saying that for now it is platform specific.

[gkhose-qipl]

Target platforms and their supported sensors, along with unique Slot IDs, PHY laneconfig, and tuning settings:
Kodiak: IMX577, OV9282, IMX686, AR0231(GMSL) LM: IMX577, OV9282, OX03F10(GMSL BAYER, YUV), 0x8D10(MIPI, GMSL) Talos , IMX577_4Lane, IMX577_2Lane Hamoa: OG0VA1B, IMX577

@gkhose-qipl please improve your git commit message saying that for now it is platform specific.

@ricardosalveti ,
below is commit msg. in commit i added sensor is for hamoa. do i need to modify it?
add support to og0va1b sensor for Hamoa

[ricardosalveti]

Target platforms and their supported sensors, along with unique Slot IDs, PHY laneconfig, and tuning settings:
Kodiak: IMX577, OV9282, IMX686, AR0231(GMSL) LM: IMX577, OV9282, OX03F10(GMSL BAYER, YUV), 0x8D10(MIPI, GMSL) Talos , IMX577_4Lane, IMX577_2Lane Hamoa: OG0VA1B, IMX577

@gkhose-qipl please improve your git commit message saying that for now it is platform specific.

@ricardosalveti , below is commit msg. in commit i added sensor is for hamoa. do i need to modify it? add support to og0va1b sensor for Hamoa

Quick example (AI-produced):

camxlib-hamoa: update to the 1.0.25 revision

Update camxlib-hamoa to revision 1.0.25, which adds support for the
OG0VA1B camera sensor.

This support is intentionally kept Hamoa-specific for now. The OG0VA1B
is currently only wired up on the Hamoa EVK via a custom daughter card,
and the sensor driver carries target-specific configuration (slot IDs,
PHY lane config and tuning binaries) that is not portable to other
targets as-is.

Anything better than just 'add support for foo on bar' would do it.