<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
mchehab: pong
hverkuil: Quick question: you reviewed the media patches from this series: "[PATCH 000/141] Fix fall-through warnings for Clang"
<br> Are those patches intended to be merged by Gustavo, or can I merge them?
<br> I'm preparing a new PR with fixes, but I'm not sure what the intention was with those patches.
<br> <u>mchehab</u>: I've posted the PR: if you prefer to skip those fall-through warnings and let Gustavo handle them, then you can just drop those patches from the PR when you pull it.
mchehab: good question. Upstream didn't receive too well his patchset
<br> it sounds that some things will end being addressed at Clang itself, making itless pedantic
<br> I don't have any strong opinion on that
<br> as it is just 6 patches for media on your PR, I don't mind merging them
hverkuil: I agree. I think fall through is evil unless explicitly annotated, so I approve of this patches.
sailus: Heippa!
hverkuil: hi!
syoung: hello!
hverkuil: <u>mchehab</u>: ping
mchehab: hi all
hverkuil: Besides a few 5.12 PRs I have one 5.11 PR and a second 5.11 PR is expected tomorrow.
mchehab: ok. I'll likely handle the pending PRs today or tomorrow
sailus: <u>mchehab</u>: Would that include the IPU3 CIO2 bridge PR?
hverkuil: I think that's all from my side.
sailus: <u>here</u>: https://patchwork.linuxtv.org/project/linux-media/patch/20210114162122.GO850@valkosipuli.retiisi.org.uk/
mchehab: hmm... sounds promising!
<br> yeah, if everything is ok over there, I should handle it as well
sailus: Thanks!
mchehab: how can I test it? I have a notebook here that has an IPU3 camera... it would be worth trying it over there :-)
<br> (not sure if the sensor used on such notebook was merged, but I guess I did a port of a sensor driver for it somewhere)
sailus: Not a chromebook?
mchehab: no. a Dell one
sailus: I think more patches will be needed in any case.
<br> This set just adds the dependencies.
<br> It's the other set from Daniel that is needed for any functionality.
<br> Then (most?) systems without a camera PMIC should work.
mchehab: ok. I would love to test Daniel's patches on it once ready for testing
sailus: I tested them on IPU3 Chromebooks.
<br> I'll actually send a new version of the same pull request, to include a few more patches (and a tiny cleanup).
pinchartl: <u>mchehab</u>: you can't test that series in isolation, Daniel is working on another series for the PMIC
<br> and that one only supports a subset of devices
<br> (one step at a time...)
<br> it depends what PMIC your device is using
sailus: Nah, I'll send a new, separate pull request instead, keeping the old one.
<br> Sent.
mchehab: <u>pinchartl</u>: ok
<br> I don't remember if the sensor on this device uses pmic or regulator
pinchartl: there's a kernel module in the linux-surface project on github that gathers data from ACPI and prints it out to the kernel log, to help figuring out what sensors and PMICs/regulators are used
<br> I think it's https://github.com/kitakar5525/surface-ipu3-cameras/tree/master/misc/dump_intel_ipu_data
<br> not sure if it's the latest version
mchehab: the sensor it uses is ov8858
<br> ah, It uses PMIC_ACPI_TPS68470
<br> (just checked at the branch I was using to play with this board in the past)
<br> +#define PMIC_ACPI_TPS68470 "INT3472:06"
<br> + {"INT3477", "ov8858"},
pinchartl: <u>mchehab</u>: INT3472 doesn't necessarily mean TPS68470
<br> it's an "Intel camera power management device"
<br> which maps to one out of three possible hardware devices
<br> TPS68470, uP6641Q, or discrete power gates
<br> which one it maps to depends on the machine. for chrome os machines, it's always a TPS68470. for windows-based machine, which option it maps to is stored in a device-specific ACPI property
<br> depending on the machine, that custom property can be static (reading the disassembled DSDT is then enough to figure it out), or dynamic (assembled at runtime based on information provided by the BIOS), in which case we need runtime code to figure it out
<br> that's what https://github.com/kitakar5525/surface-ipu3-cameras/tree/master/misc/dump_intel_ipu_data does
mchehab: kern :info : [ 99.033053] ACPI device name: OVTI9234:00
<br> kern :info : [ 99.033055] i2c device name: i2c-OVTI9234:00
<br> kern :info : [ 99.042388] dump_intel_ipu_data: Found 3 supported sensor(s)
<br> kern :info : [ 99.042389] dump_intel_ipu_data: Found 2 supported PMIC(s)
<br> kern :warn : [ 99.025464] ACPI CLDB: PMIC type is 2: PMIC TPS68470
<br> kern :info : [ 211.158204] get_acpi_pmic_data(): ==================== INT3472:05 (PMIC) ====================
<br> kern :info : [ 211.158390] ACPI _DDN: PMIC-CRDG
<br> kern :warn : [ 211.158728] ACPI CLDB: PMIC type is 2: PMIC TPS68470
<br> kern :info : [ 211.158961] get_acpi_pmic_data(): ==================== INT3472:06 (PMIC) ====================
<br> kern :info : [ 211.159008] ACPI _DDN: PMIC-CRDG
<br> kern :warn : [ 211.159226] ACPI CLDB: PMIC type is 2: PMIC TPS68470
<br> kern :info : [ 211.179227] dump_intel_ipu_data: Found 2 supported PMIC(s)
<br> kern :info : [ 211.159445] get_acpi_sensor_data(): ==================== OVTI9734:00 (Sensor) ====================
<br> kern :info : [ 211.162754] get_acpi_sensor_data(): ==================== INT3477:00 (Sensor) ====================
<br> kern :info : [ 211.166044] get_acpi_sensor_data(): ==================== OVTI9234:00 (Sensor) ====================
<br> despite reporting 3 sensors, as far as I know, this specific device has just one wired
<br> <u>pinchartl</u>: sailus: ^
pinchartl: thanks
<br> so it seems to really be a TPS68470
<br> which isn't supported yet
<br> because we haven't figured out how to map the TPS68470 outputs to the supplies used by the sensor
<br> do you have the schematics for that device by any chance ?