Is there a way to obtain more information about the reason for the CHANSEL_FAULT error, such as extended logs beyond what I’ve already provided in this thread?
Can NVCSI/VI be configured at the Linux kernel driver level to not reject frames with DataType 0x33? Or does this change require modifying the NVCSI firmware, which is not publicly accessible? I am asking to determine if we can resolve this issue on our own or if we require support from Nvidia or one of Nvidia’s trusted partners.
What does it mean - handling custom DataType is not supported for “normal frame capturing”. Is there another way to obtain camera frames in user space, or does this mean a different solution such as directly passing the frame to the ISP?
>>Q1
please refer to TRM, 7.2.2.2.2 CHANSEL.
there’re different kinds of notifications. some general faults detected by CHANSEL were also mentioned in the doc.
>>Q2
you meant the user datatype? i.e. NVCSI_DATATYPE_USER_4 (51)?
no… it’s not supported.
>>Q3
that normal frame capturing I meant the sensor output formats with bayer RAW, or YUV contents.
you meant the user datatype? i.e. NVCSI_DATATYPE_USER_4 (51)?
no… it’s not supported.
Yes, I meant exactly that one - NVCSI_DATATYPE_USER_4 (51).
In order to have NVCSI_DATATYPE_USER_4 supported, does the missing implementation:
have to be added on Linux4Tegra public source, we can resolve this on our own
or
have to be added to the Nvidia’s firmware or other non-public part of the software and we require support from Nvidia or one of Nvidia’s trusted partners
It is important for us to be able to receive frames with NVCSI_DATATYPE_USER_4. On which layer, support for NVCSI_DATATYPE_USER_4 needs to be added?
there is missing implementation in Nvidia’s firmware or other non-public part of the software?
We are determined to add support of NVCSI_DATATYPE_USER_4 (51), the question is, can be this done on L4T source level or we need support from Nvidia or Nvidia;s trusted partners.