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
