On Tue, Apr 02, 2024 at 09:00:43AM +0300, Tomi Valkeinen wrote: > On 01/04/2024 16:52, Laurent Pinchart wrote: > > On Wed, Mar 27, 2024 at 01:21:09PM +0200, Tomi Valkeinen wrote: > >> On 25/03/2024 00:08, Laurent Pinchart wrote: > >>> From: Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> > >>> > >>> Add a driver for the Unicam camera receiver block on BCM283x processors. > >>> It is represented as two video device nodes: unicam-image and > >>> unicam-embedded which are connected to an internal subdev (named > >>> unicam-subdev) in order to manage streams routing. > >> > >> Shouldn't this driver call get_frame_desc somewhere to get the VC and DT > >> for the streams? > > > > Generally speaking, yes. In practice, configuring the DT from the frame > > descriptor is probably not very useful, as CSI-2 sources that transmit > > image data using a DT that doesn't correspond to the media bus code are > > not very common and I don't expect this to be needed for unicam. > > Perhaps, but if the driver gets the DT from the frame descriptor, then > the driver doesn't need to have tables for the DTs. > > Although when I did this with the RPi CFE driver, I also implemented a > fallback mechanism for the cases when there is no get_frame_desc, and so > I still had to keep the DT tables... I did the same in v9. The DT value in the existing format info table also serves for CCP2 support, which isn't supported by .get_frame_desc(). Even if it was, CCP2 doesn't have an explicit DT concept (as far as I can tell), but the hardware requires the DT value to still be programmed. -- Regards, Laurent Pinchart
