On 10/30/20 8:26 AM, Sowjanya Komatineni wrote:
On 10/30/20 3:06 AM, Hans Verkuil wrote:
On 30/10/2020 10:56, Sakari Ailus wrote:
Hi Hans,
On Fri, Oct 30, 2020 at 10:31:06AM +0100, Hans Verkuil wrote:
On 29/10/2020 18:07, Sowjanya Komatineni wrote:
On 10/29/20 9:52 AM, Sakari Ailus wrote:
On Thu, Oct 29, 2020 at 09:49:57AM -0700, Sowjanya Komatineni wrote:
On 10/29/20 8:36 AM, Sowjanya Komatineni wrote:
On 10/29/20 7:50 AM, Sakari Ailus wrote:
Hi Sowjanya,
On Wed, Oct 28, 2020 at 06:48:59PM -0700, Sowjanya Komatineni
wrote:
Hi Sakari,
Missed to add you to below patch series for HDMI2CSI bridge
support
https://patchwork.kernel.org/project/linux-media/cover/1603768763-25590-1-git-send-email-skomatineni@xxxxxxxxxx/
Patch-10 of this series is for x8 capture from HDMI2CSI bridge.
Would like to get your suggestion on x8 gang/combined ports
capture
implementation.
The majority of CSI-2 receiver devices support partitioning the
lanes among
different PHYs in various ways. They do support usually up to
four
lanes,
but adding four more lanes is not a reason for making the API
different.
So instead, you should implement this as a single port that
simply has 8
lanes.
Thanks Sakari for your reply.
current v2 series treats as 8 lanes. You mean to not expose 2nd
port in
device tree as VI/CSI side takes care of 2nd port as combined
to treat
as 8 lane?
Correct.
Although you can have the second port connected if fewer lanes
are assigned
to the first one.
How does it work for this device, are the lanes statically
allocated to
ports, apart from the special 8 lane mode?
Tegra CSI each port supports max 4 lanes. For x8, 2 x4 ports together
are programmed for simultaneous streaming during the same
video/subdev
stream ops.
Physically, CSI RX side 4 lanes goes to x4 port and other 4 lanes
goes
to another x4 port.
HDMI Bridge TX0 -> CSI RX0 (x4 port)
HDMI Bridge TX1 -> CSI RX1 (x4 port)
HDMI bridge side single image is split into 2 x4 ports and on RX side
image from both ports are captured simultaneously with buffer offsets
adjusted side-by-side to get combined image for same video buf of
video
device.
Both these 2 x4 ports together are used for streaming by Tegra VI and
buffer offsets are adjusted side by side for these ports and for
video
device node stream, its single buffer which contains combined
image from
capture.
AS csi2 bus type supports max 4 data lanes with endpoint parse API.
Currently with x8 as single port, I am using bus-width with bus
type as
parallel in device tree and when using x4 using data-lanes with
csi2 bus
type and driver gets lanes based on either of this from DT.
Instead should we update endpoint parse API for max up to 8
lanes for
data-lanes?
Yes, please. Could you send a patch?
The standard AFAIK supports up to four lanes but as we know,
hardware
sometimes has more than that.
Sure once Hans also agrees with this to have it as single x8 port
(just
like I have now in v2), will send v3 to update endpoint parse to
allow
upto max 8 data-lanes and will also update Tegra CSI driver
accordingly
to retrieve lanes using csi2 bus type.
Hans, Please confirm if you agree with this.
I'm not sure if I agree with this. Shouldn't a device tree reflect the
hardware? And how would you represent the use case where the ganging
mode stitches together two synced sensors (left and right) into a
single
3D side-by-side image? Then you would have:
Left Sensor TX -> CSI RX0 (x4 port)
Right Sensor TX -> CSI RX1 (x4 port)
And for the tc358840 something similar might be true: in the case
of the
Tegra you have this nice ganging mode available, but for other SoCs
each
half would have to go to a separate CSI port and captured via a
separate
video DMA channel, and software or a GPU is needed to combine the two
halves.
In both these examples it is my understanding that you have to
model this
in the DT as separate x4 ports.
Do note that a "port" as such is a logical concept. On modern
hardware, a
port consists of two or more lanes --- one clock, plus at least one
data
lane. Perhaps an example could be useful. For instance, if you have ten
lanes on a device, this could be split into following
configurations, based
on the board design:
configuration \ data lanes port 0 port 1 port 2 port 3
1: 4 4
2: 4 2 1
3: 2 2 2
4: 2 2 1 1
So if you add one more, say:
5: 8
So what we're discussing is just how the lanes are distributed
across the
ports.
There are usually hardware specific limitations how the lanes can be
distributed. The interface we have in DT (data-lanes + clock-lanes
properties) allows describing the hardware in general case, so what the
interface allows may not be possible in hardware, but what hardware
implements is supported by the interface.
So for this particular instance using a single logical 8-lane port would
make sense, but in the two other scenarios (left/right sensor or
supporting
tc358840 in a SoC that doesn't support ganging) I described you would
still
have to model it as two 4-lane ports.
Is that correct?
Regards,
Hans
Hi Hans,
As its a single image split here, even it comes from 2 TX ports it
goes through same video channel where we adjust video buffer offset to
align side-by-side for combined image.
So if any SoC does not support multiple independent ports (by HW or
logically), then like Sakari mentioned we expose both x4 ports but in
that case they both should be exposed to different video channel (DMA
Buffer allocations).
To be clear, I meant SoC that does not support multiple ports like gang
or HW native x8 port in the above point.
With this SW should manage to combine captures from these 2
independent ports and I am not sure if this is feasible or if we ever
had this case implemented by any SoC SW so far as SW overhead will
impact as well but this is different issue.
But isn't most SoC, CSI RX ports are similar instances allowing
parallel captures as any Receiver supporting multiple ports allows
multiple streaming right?
Cases we are discussing here are
1. SoC supporting Native x8 or gang ports on CSI RX: as its single
image they go thru same video channel
2. SoC does not support gang ports on CSI RX: In this case, different
video channel should be used
So probably, to cope this with both cases, such sensor/bridge drivers
should allow creating on CSI TX side both ports as separate (case-2) and
also as single port (case-1).
