[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210214213404.8373-1-andrey.konovalov@linaro.org>
Date: Mon, 15 Feb 2021 00:34:02 +0300
From: Andrey Konovalov <andrey.konovalov@...aro.org>
To: junak.pub@...il.com, robert.foss@...aro.org,
sakari.ailus@...ux.intel.com
Cc: todor.too@...il.com, agross@...nel.org, bjorn.andersson@...aro.org,
mchehab@...nel.org, laurent.pinchart@...asonboard.com,
jacopo@...ndi.org, linux-media@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] media: qcom: camss: V4L2_CID_PIXEL_RATE/LINK_FREQ fixes
The first patch is the start of the work discussed in the "[RFC] Repurpose
V4L2_CID_PIXEL_RATE for the sampling rate in the pixel array" thread [1].
I plan to send a few other similar patches for other CSI receiver drivers,
and if the current patchset needs to wait for those before it can be merged,
that's fine for me.
The reason I decided to post the camss patch first is the patch [2] by
Vladimir Lypak. The second patch in this series is the Vladimir's patch
rebased onto the changes done by the first patch. By replacing getting
the pixel clock with v4l2_get_link_freq() my first patch also fixes the
integer overflow which Vladimir's patch addresses. So the second patch
only needs to fix drivers/media/platform/qcom/camss/camss-vfe.c which
the first patch doesn't touch.
The resulting patchset is free from the "undefined reference to `__udivdi3'"
issue [3] as the u64 value is only divided by a power of 2, which doesn't
need do_div().
Vladimir, please confirm if this patchset fixes the integer overflow
for you, and if you are OK with your patch going on top of mine like is
done in this patchset.
[1] https://www.spinics.net/lists/linux-media/msg183183.html
[2] https://www.spinics.net/lists/linux-media/msg186875.html
[3] https://www.spinics.net/lists/linux-media/msg186918.html
Powered by blists - more mailing lists