jmondi: I applied the patch fixing the build, but I'm not happy with the usage of a "lib" module with part of the code at the camera modules
mchehab: thanks, I see
I'm pondering about the solution you presented ysterday, but I still have an hard time making it fit
also, and no offence with that as it is not expected that the maintainer looks at all the patches in flux, but this has been around since 2 years and a half now, I went to revision 10+ with the first camera module and something similar for the 21. Receiving a stop that late in the development it's a bit.. well, demotivating ?
jmondi: basically, it passed unoticed to my review... I only discovered the issue due the build warning... sometings things like that happen
mchehab: I understand, it's crazy to require a single person to review all the patches that are sent on the list
but I hope you understand the feeling at my side as well :)
yeah, sure
in any case, let's find a way to address it. The current way is too hacky
I don't want things like that to propagate at the subsystem. We should rely at the Linux bus support for things like that (either the I2C bus or a new bus specific for GMSL)
at least with regards to the control part, I think that it should be possible to extend I2C support to better support the I2C address dynamic changes
and multiple addresses per device
(btw, that's not the first time I see a single device with multiple I2C addresses)
there is a radio chipset that has 2 addresses - one for control and another one to receive radio broadcasts (texts)
I wrote once a driver for it, but the second interface weren't used on that time
oh, devices with multiple addresses are common I guess, the adv7482 registers like 10 of them iirc :)
mchehab: currently I'm trying to get the system I'm testing GMSL with to behave reliably, as during probe I still have sporadic failures due to the fact the chips are intended to be operated by interleved writes
once I get to the point I can upstream the dts integration for that board and have a 'stable' base, we can explore turning max9271 into a driver
hverkuil: I see something odd, if I load vivid (no parameter) then select input 3 (HDMI), I get no source-change when dv-timings are set (mode 4, + changing dv_timings)
but if I load the driver with  num_inputs=1 input_types=0x3
then it works
hverkuil: nevermind, got tricked by v4l2-ctl source_change=<value>
where v4l2-ctl document the value as a pad number, vivid codes an input number
and I haven't figure-out were in the doc that is documented
ah found it in the doc
so all good, sorry for the noise