On 30/10/2020 23:31, Sakari Ailus wrote: > Hi Hans, > > On Fri, Oct 30, 2020 at 11:06:18AM +0100, 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. > > If you have two sensors, yes, then it'll be two separate ports; one sensor > connected to each of them. The streams are usually separate, but other > kinds of implementations exist. Still, they generally have no effect on > CSI-2 bus configuration. > OK, then we go with increasing the number of data lanes to 8. Regards, Hans
