tomba: just played quickly with DIR_REM_CC flag on a dual gmsl2 deserializer
tomba: seems to do the work enabling DIS_REM_CC cut the communication on a given link and clearing the bit restore the communication
tomba: if we can use it for the I2C mux it would be awesome :)
tomba: I mean without having to do a link reset
jmassot: ok. I don't have the hardware yet, so I can't do any testing. looks like there's a programming sequence to (try to) make sure the DIS_REM_CC is set from the power on, preventing any i2c communication until the driver would be ready for it.
The sequence is a "do this quickly enough and then it'll work" type, though =).
tomba: Yes I already had to do that on drm drivers
tomba: basically power on the device and reset the link as quickly as possible
right
tomba: on some devices I also saw that it's possible though the CFG pins
tomba: don't remember which ones
tomba: but it won't happened
jmassot: I hope to get the HW next week, I can then do some actual tests too. So far all my real experience is with fpd-link.
tomba: they shared the same concepts, but Maxim has some extra stuff such as stream id when used in pixel mode
e.g you can tag up to 4 streams with a stream id and then do routing based on the stream id
tomba: you can aslo route the video based on vc/dt
tomba: or decide to route all the streamid from one GMSL link to the same CSI ports
tomba: as I understood (from pinchartl) you plan to use a MAX9295a serializer
jmassot: MAX9295a, MAX9295d, MAX96712
tomba for this one I think you can just reuse the max96717 driver, it only has fewer possible clock frequency
jmassot: ok. I haven't looked at the actual register maps yet at all. it would be nice to extend the existing drivers, but let's see if the quad-deserializer brings in issues that require me to write new ones.
tomba: the register maps for quad devices is different
tomba: different enough to have their own drivers while the one port device have the same register mapping than the dual ones
Someone mentioned to me today that their imx219 doesn't work because imx219_common_regs uses the incorrect access routine (it should write 0x05 before 0x0c to 0x30eb). The datasheet appears to agree that the linux driver is wrong. How does that driver work on people's PIs?
conchuod: no idea. that sequence unlocks the MSRs, but what the MSRs that are later written do is undocumented
maybe it still works somehow without writing them ?
:q
oops
interestingly enough, in the original code from RPi that was merged upstream (commit 1283b3b8f82b9004fbb94398cade5c8e797a2c8d), the sequence was wrong for the 3280x2464 and 1640x1232 modes, but correct for the 1920x1080 modes
pinchartl: So something like the firmware etc on a pi has already touched the registers, so linux doesn't actually need to use the right command?
refactoring of the init sequence picked the wrong order in all cases
Hmm, I see.
I'll send a patch I guess. I can't test it on any platform though, I don't have one.
the RPi kernel also has the wrong sequence
can you CC me and Dave Stevenson ?
Sure
thanks
do you have access to documentation that explains what the MSRs written by the driver in the imx219_common_regs table do ?
Heh, no. I don't do anything with cameras. Last time we wanted to send some imx camera patches, we had to get legal involved though. 
I think in this case it's not even us that have the imx219, it could be a customer.
pinchartl: The one thing I wonder about is whether I'm only getting half of the information. I'm getting the info 3rd hand or w/e, I'm pretty sure they want to add some extra commands to the common_regs stuff. It might be that this fix was required to access those extra registers and is a NOP for the current driver.
the current driver writes 12 MSRs in the init sequence. it's hard to tell if that's required or not. clearly the sensor can work to some extent without those registers being written, as we don't unlock the MSRs space properly. but it may impact image quality
it would be very nice to know what those registers do
let's not involve the legal department though :-)
I made the legal part someone else's problem last time ;)