easy way to get/submit patches to linux-4.9 or linux-nvidia


which branch should I follow at git://nv-tegra.nvidia.com/linux-nvidia.git and git://nv-tegra.nvidia.com/linux-4.9.git if I want to get the latest committed patches on those trees,

and is there a mail address where patches can be proposed to linux-nvidia or linux-4.9 using ‘git send-email’ ?


Have a check with git tag -l tegra-l4t*, and if you have some patch would like to promote please just post here we can help on that.


Hello ShaneCCC,

here is one patch :

From e4d929213e06506ec6256817c28ef7f93d972742 Mon Sep 17 00:00:00 2001
From: Philippe De Muyter <phdm@macqel.be>
Date: Thu, 12 Dec 2019 08:56:05 +0100
Subject: [PATCH] drivers: camera: don't set 'is_streaming' when 's_stream'

In 'tegra_channel_set_stream', after a failure of
'v4l2_subdev_call(sd, video, s_stream, on)', 'chan->is_streaming' is
nevertheless wrongly set to 'on'. Fix that.

Signed-off-by: Philippe De Muyter <phdm@macqel.be>
 drivers/media/platform/tegra/camera/vi/channel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/tegra/camera/vi/channel.c b/drivers/media/platform/tegra/camera/vi/channel.c
index 6dcfda0..a4d11ad 100644
--- a/drivers/media/platform/tegra/camera/vi/channel.c
+++ b/drivers/media/platform/tegra/camera/vi/channel.c
@@ -896,7 +896,8 @@ int tegra_channel_set_stream(struct tegra_channel *chan, bool on)
                tegra_camera_update_clknbw(chan, false);

-       atomic_set(&chan->is_streaming, on);
+       if (!ret)
+               atomic_set(&chan->is_streaming, on);
        return ret;


Could you have description how to reproduce the problem?

Problem happens if s_stream(true) fails. In our case, we work with sensors that do not speak mipi-csi2, and therefore need a FPGA to convert their output to mipi-csi2. Starting the stream involves loading the firmware in the FPGA. That can fail sometimes because of transmission error or because we have forgotten to place the needed firmware file in the /lib/firmware directory.
When that happens, the stream is nevertheless started and user program is not warned, and gets blocked waiting for the frames, while the kernel spits ‘PXL_SOF’ messages. If you want to reproduce the problem you should add a way to make the *_s_stream function fail in the driver for your sensor.

You then can test with or without the patch with :

v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=256 --set-fmt-video=width=2464,height=2056,pixelformat=GREY

Best Regards