We have successfully run all modes from the tc358743 that use 594Mhz clock per 2 lane configuration. This seems to be the most common working situation.
We want to run 1080p60 which uses 4 lanes of 594Mhz. The data rate is under 1.5Gbps so no deskew needed.
We have boosted the clocks.
We have made only 2 updates to the DTSI, we set the bus width to be 4 and we set the lanes to be (1 2 3 4).
When we run with this configuration, we get a timeout at 2500ms where the log tells us that VI didn’t receive any data.
Another user is seeing the exact same problem here with same basic configuration:
We’ve tried everything we could think of but we cannot get 4 lanes to work and we don’t know what else to check. Given the link above was for the imx568 instead of tc358743, I wanted to start an additional thread for this specific configuration.
We set the CIL time to 0 so it was auto calculated. Maybe those calculations are wrong?
This is the Orin dev board with a manufactured (not by us) board that we’ve tried multiple modules. Given we are not the only person seeing this problem with the tc358743, that leads me to believe that if we are seeing timing issues, it must be on the Orin side setup in the driver.
Given 1080p60 timing is identical to 720p60 in terms of bits per lane (since 2 lanes vs 4 lanes) and that we can read 720p60 without issue, I still contended this points to a setup problem.
Is the driver properly setting up the tc358743 for 4 lanes? Another person showed the output of all 4 lanes at the expected clock frequency in another posts
Is Orin setup properly to handle all 4 channels? I would think if it were still setup for 2, it would have collected something as it would still have received 2 valid lanes if the tc358743 was sending 4 lanes.
Is the timing setting up correctly for the 4-lane mode? Given Conner in the other thread talked about the PLL settings, I suspect maybe something is wrong with the configuration for 4 lanes with this driver.
I mean, I get that, but there is something inherently different in the latest firmware compared to the older firmware and seems to break the connection between tc358743 and the orin nano.
Before we were using the csi2_fops and a LOT of that was rewritten in csi5_fops (and the in-between versions). The driver that ships with the linux kernel does not work and everyone has been trying to piece together a driver that does. So far, every instance I have found is successful operation of 594M lane data rate for 2 lanes and that is it.
So, for 1 lane or 4 lanes, I have found ZERO successful cases with the Orin Nano. To me, that says something is still broken and since we cannot get the tc358743 TRM nor is there any documentation I have found for csi5 implementation, we are stuck trying to hack things to make them work.
We did trace through the driver and at least confirm that all the same I2C command were the same as what we saw in the previous versions of the driver that we had working. That said, what we did not do is confirm at each bit of that code gets executed the same way, which we should do.
We’ll add some debug statements in the portion that sets the lanes and make sure they are being sent. It looks like on reset that the tc358743 defaults to 4-lane and that any lesser lane settings trigger other commands to send that reduce the configuration. So we’ll verify the reset is happening as well.
The other things, is that I was looking at the nvcsi_cli settings (the struct) and I cannot find ANY documentation on what the MIPI clk speed is that is stored in that variable. In another thread, someone set it to the kHz of the pixel clock as it wasn’t being set properly and for 720p60 that worked. We tried to set to 2x that for 1080p60 since the pixel clock is EXACTLY 2x that value, but it didn’t work. We also noticed that the 2x value is greater than the max csi clk that gets set by default to csi_clk which looks really suspicious.
Is there ANYWHERE we can read some documentation on that struct of nvcsi_cil settings so we can try and decode what should be there.
NONE of that code is the same in csi2_fops so this is ALL new to us in how it works.
We see them in there, it’s just not clear to use what those values should be.
If it grabs it from the device tree, there isn’t anything indicating what the units are. When I see MIPI clock rate, I would have thought 297Mhz would be the MIPI clock rate since that is the ACTUAL clock coming in.
If it grabs the csi->clk_freq, we traced that value back to see it was set as a constant that was a much smaller value than what the max csi clock frequency could be relative to what the Orin TRM says.
Can you find out what that value actually represents? Like what it actually is used for?
Looking at the struct for nvcsi_cil_config, this really doesn’t give enough information for us to understand:
/** MIPI clock rate for D-Phy. Symbol rate for C-Phy [kHz] */
uint32_t mipi_clock_rate;
Hmmm, well here is the interesting thing. A different user figured out for 720p60 to work, he had to hardcode the value to:
74250000
Which is the pixel clock per frame. That has no inclusion of bit depth or lanes associated with it. (in other words, this is pix_clk_hz)
We tried using the same value (with the thought that maybe it had something to do with lanes) and then 2x that value for1080p60 (since 2x the value is the pix_clk_hz for 1080p60) but that didn’t work either.
I don’t believe setting it to pix_clk_hz*depth.lanes worked, as that would be the 594M value. (all numbers represented in kHz in the struct)
If you trace the code when we don’t make ANY changes to the driver (csi5), you see that mipi_clock_rate in the nvcsi_cil_config is set to:
which after dividing by 1000 = 102000 and what we see in dmesg originally before we got 70p60 working with hardcode.
How this value is a maximum makes no sense. It’s 102Mhz. This is why we don’t understand what the value is. It just seems like something is wrong here. 1080p60 should be no problem over MIPI 4 lanes as it’s only 594Mbps on each lane. This csi implementation supports WAY higher than that. (as per the TRM for the Orin).
We have looked at the registers with regards to CSI D/CLK lane setup and they all look correct. We went through calculations for tc358743 PLL settings and all values being sent are correct (which generates 297Mhz PLL clock)
All of the code pertaining to the tc358743 itself looks proper in terms of setting up the device to send on 4 lanes that I can see.
The only portion of the driver that I’ve seen different settings is:
We’ve tried different varieties here of what other people have used that claimed 1080p60 in previous core setups (ie, Xavier or Jetson Nano). But no change.
This still leads us back to the csi5 side which is the only part that is different now and is very rewritten. It doesn’t mean the code is wrong, it just means that the old interface doesn’t work and there is no documentation to make it clear what we should be setting.
Also note, because we are using 297Mhz clock for both 720p60 2-lane and 1080p60 4-lane, the hsclk in the TC358743 is the same. Therefore, from what I can tell in the documentation, all the above values should work identical since same clock rate.
As I suspected, this value is the culprit. I just captured a frame of 1080p60 for the first time.
That said, I need some help in understanding how to set the value without my hardcode :)
This value needs to equal the actual CSI clk / 1000. So in this case, 594Mbps/2000.
What I don’t see is how to get the bps_per_lane in the csi5_fops function where this is needed. I saw this where someone is calculating it with a to_state function that is not in csi5
Do you have any recommendations where we can grab that info so we can set the value properly?
just add a fixed value in the .c file , or add some property in you dt file. i need to modify the bps in realtime so i add some extra head file to obtain the lane bps from the tc358743’s private data, that’s where the to_state func comes from.