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. -- Kind regards, Sakari Ailus
