I am developing an ox08b40 camera. The ox08b40 has uncompanded 24-bit, 20/16/14/12-bit (PWL) combined HDR features. So I referenced the imx185 camera with PWL WDR feature, but I have a few questions due to device tree creation issues, so I leave a question.
If PWL 12 is selected, the MIPI RAW image data type is RAW 12, so should the csi_pixel_bit_depth value be set to 12? And can the dynamic_pixel_bit_depth value be set to 24 because the uncompanded value is 24-bit?
When sending uncompanded 24-bit as it is, can I set the dynamic_pixel_bit_depth value to 24 and the csi_pixel_bit_depth value to match the MIPI RAW image data types? And in this case, can the control_point_x(or_y) values be deleted from the device tree?
If the control_point_x(or_y) values are incorrect, is the following message output? tracer.txt (110.8 KB)
The physical_w/physical_h values are described as Physical dimensions of sensor. What exactly do you mean? Are you talking about chip size? Or something else?
>> Q1, Q2
FYI, the maximum PWL-WDR supported is Raw 20-bits.
it’s ISP take maximum 16-bits input, PWL compressed/de-compress internally as 20-bit before processing.
please see-also developer guide, Sensor Software Driver Programming, you may check [Property-Value Pairs] and review those PWL-WDR specific device tree settings.
>> Q3
there’s CHANSEL_NOMATCH according to your tracing logs.
it usually caused by no match pixel types. please review your device tree configurations.
such as, mode_type, csi_pixel_bit_depth, and pixel_phase.
it’s pixel parser to check data type, and it used configuration from device tree.
you may probe the signal or review the register values to examine the incoming data.
however, may I know which JetPack release you’re using?
it actually a warning message.
this message indicate there’s capture failure, it’ll drop the capture buffer and re-queue the frames again.
is the VI tracing logs keep shown CHANSEL_NOMATCH tags?
please double check sensor register settings of embedded_metadata_height .
if you set embedded_metadata_height = 1 for sensors that does NOT really output embedded data, the capture will not works for Xavier series.
may I also know what’s the camera connections,
is it a bayer camera which connect to CSI connecter directly?
or, you’re having external physical device (such as, SerDes) between sensor module and CSI connector?
For the camera connection, it is connected like this: xavier - camera interposer module - camera. The clock was checked on xavier’s camera connector (J509).
Embedded_metadata_height is 2 top and 2 bottom enabled, so I tried setting it to 4, and the Statistics line was also enabled, so I set it to 6 as well.
In order to receive the compressed data because it said that it does not support decompressing additionally compressed 12-bit data to 24-bit. The
csi_pixel_bit_depth value was set to 12 and the mode_type was set to bayer.
oh… embedded metadata behind active region is not supported.
if you configure embedded_metadata_height as four, it’ll looking for 4-line ahead of active regions.
could you please configure sensor to disable bottom of embedded metadata, and update the DT settings.
don’t you works with PWL camera sensor? it should configure mode type as bayer_wdr_pwl.
if your settings is bayer, it determine the camera as Raw12 SDR.
You mentioned that the maximum supported bit for PWL-WDR is 20-bit, but it is because I am having a hard time changing from ncompaned 24-bit to uncompaned 20-bit.
In the case of compressed data, it is compressed as RAW 12, so even if the image is strange, I think it can be received if the data type is correct.
Line length is the value of the register’s horizontal total size, and pix_clk_hz is the value calculated using the D-phy clock. Can I input it like that?
pix_clk_hz is a value calculated using the D-phy clock, can I enter it like that?
Sorry for so many requests and greatly appreciate your support.
line_length
Pixel line width horizontal timing size for the sensor mode. Used to calibrate the features in the camera stack.
The value must be greater than or equal to active_w.
please see-also Sensor Pixel Clock session for the formula to calculate the correct sensor pixel clock rate.
there’re three different formulas, they might output a little different calculation results.
in generally, you may assign the biggest calculation results to pixel_clk_hz device tree settings.