How to make a change to the L4T source?

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
#1

Hey there,

I am working on a project where I am building a custom kernel because I am making a driver customization for the camera I am using. While doing this I have noticed a few small bugs in the JP 4.4.1 souce code that I would like to fix, so that they don’t reappear in the next JP release.

What is the cannonical way for doing that? Do I do a pull request? Do I send my changes somewhere via email for approval?

Thanks in advance!

#3

Hi,
Please make a post to describe the issue and attach the patch. We will pass it to our teams for review. Thanks.

#4

While working on the latest JP 4.4.1 I stumbled upon a few issues that I fixed, but I wanted to share with you guys, so maybe they can get integrated into the official L4T codebase.

Here are my patches:
tegra-l4t-r32.4.4_patches.zip (4.3 KB)
The changes I am suggesting are 4:

  1. The max9295.c serializer has a static member inside it :* static struct max9295 prim_priv__;
    Since there is no documentation of the sourcecode I hope I understood the logic correctly.
    This pointer is used to choose which serializer is the primary one (in case you have more than 1 connected to a deserializer). However in my case I have more than 1 deserializers, and each is connected to a unique serializer, so the prim_priv__ logic doesn’t really work and I have to disable it. Disabling it on the other hand makes the pointer NULL throughout the whole runtime and there is not a single check for nullptr right now.
    I have added all the required nullptr checks.
  2. To facilitate the sensor driver development process I wanted to build my sensor driver as a .ko file, but to do so, since it’s going through the max9295/max9296 ser/des boards it needs to be able to call some methods that are not exported right now.
    These are the max9296 power of/off and stream on/off so the patch exports them. This resolves the problem
  3. There seems to be a bug in max9296_sdev_unregister(). Near the end of the function there is logic that loops over all registered devices searching for the one we’re trying to remove and if found removes it.
    Then it checks whether the iterator i over which we count is equal to num_src (the upper boundary) and if it is that is considered that we looped over all the devices and didn’t find the one we’re looking for, so that triggers an error. However if the device we’re looking for is the last in the list, then we would find it and break the loop before it goes out of range, but we will also update num_src by subtracting one from it for the device we’re unregisterring, which will falsely trigger the condition that we didn’t find the device we were looking for (this is the bug). The patch provided fixes that.
  4. I have added support for RAW12 GBRG pixel format as it was missing

All the best!

#5

@DaneLLL is this the kind of post you meant?

#6

Hi,
The patches look specific to Maxim deserializer. Will let out teams review these. Thanks for the sharing.