Re: [PATCH 0/3] media: rcar-{csi2,vin}: Move to full Virtual Channel routing per CSI-2 IP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Niklas,

On Wed, Oct 20, 2021 at 10:02:22PM +0200, Niklas Söderlund wrote:
> Hello,
> 
> This series attempts to increase the flexibility of the R-Car VIN 
> capture pipeline by allowing for free form Virtual Channel routing 
> within the same CSI-2 IP block.
> 
> When Gen3 support was first added to this R-Car VIN and CSI-2 driver the
> routing was centred around the CHSEL register which multiplex the
> different parallel buses that sits between the CSI-2 receivers source
> side and the VIN dma engines. This was a bad design as the multiplexing
> do allow for only a few combinations and do not play nice with many
> video streams in the system.
> 
> For example it's only possible for CSI-2 Virtual Channels 0 and 1 of any
> given CSI-2 receiver to be used together with the scaler.
> 
> Later datasheets have expanded the documentation and it is now possible
> to improve on this design by allowing any Virtual Channel to be routed
> to any R-Car VIN instance, provided that there exists a parallel bus
> between them. This increases the flexibility as all Virtual Channels can
> now be used together with the scaler for example.
> 
> The redesign is not however perfect. While the new design allows for
> many more routes, two constrains limit a small portion of routes that
> was possible in the old design but are no more.
> 
> - It is no longer possible to route the same CSI-2 and VC to more then
> one VIN at a time. This was theoretically possible before if the
> specific SoC allowed for the same CSI-2 and VC to be routed to two
> different VIN capture groups.

Does it mean we can't capture image data and embedded data from the same
camera sensor in separate buffers ?

> - It is no longer possible to simultaneously mix links from two CSI-2 IP
> blocks to the same VIN capture group.
> 
> For example if VIN2 is capturing from CSI40 then VIN{0,1,3} must also
> capture from CSI40. While VIN{4,5,6,7} is still free to capture from
> any other CSI-2 IP in the system. Once all VIN{0,1,2,3} links to CSI40
> are disabled that VIN capture group is free again to capture from any
> other CSI-2 IP it is connected to.

What practical limitation does this bring, does it forbid any useful use
case ?

> At the core of the redesign is greater cooperator of the R-Car VIN and
> CSI-2 drivers in configuring the routing. The VIN driver is after this
> change only responsible to configure the full VIN capture groups
> parallel buses to be to a particular CSI-2 IP. While the configuration
> of which CSI-2 Virtual Channel is outputted on which of the R-Car CSI-2
> IP output ports is handled by the CSI-2 driver.
> 
> Before this change the CSI-2 Virtual Channel to output port was static
> in the CSI-2 driver and the different links only manipulated the VIN
> capture groups CHSEL register. With this change both the CHSEl register
> and the CSI-2 routing VCDT registers are modified for greater
> flexibility.
> 
> Patch 1/3 and 2/3 are cleanup patches moving code around preparing for 
> the real work in 3/3. The work is based on the latest media-tree.
> 
> Kind Regards,
> Niklas Söderlund
> 
> Niklas Söderlund (3):
>   media: rcar-vin: Refactor link notify
>   media: rcar-vin: Breakout media link creation
>   media: rcar-{csi2,vin}: Move to full Virtual Channel routing per CSI-2
>     IP
> 
>  drivers/media/platform/rcar-vin/rcar-core.c | 379 ++++++--------------
>  drivers/media/platform/rcar-vin/rcar-csi2.c |  58 ++-
>  drivers/media/platform/rcar-vin/rcar-dma.c  |   2 +-
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  18 +-
>  4 files changed, 167 insertions(+), 290 deletions(-)

-- 
Regards,

Laurent Pinchart



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux