Hi Sakari On Fri, 21 Sep 2018 at 13:03, Sakari Ailus <sakari.ailus@xxxxxx> wrote: > > Hi Laurent, > > On Fri, Sep 21, 2018 at 01:01:09PM +0300, Laurent Pinchart wrote: > ... > > > There is also the oddball one of the TC358743 which dynamically > > > switches the number of lanes in use based on the data rate required. > > > That's probably a separate discussion, but is currently dealt with via > > > g_mbus_config as amended back in Sept 2017 [1]. > > > > This falls into the case of dynamic configuration discovery and negotiation I > > mentioned above, and we clearly need to make sure the v4l2_subdev API supports > > this use case. > > This could be added to struct v4l2_mbus_frame_desc; Niklas has driver that > uses the framework support here, so this would likely end up merged soon: > > <URL:https://git.linuxtv.org/sailus/media_tree.git/tree/include/media/v4l2-subdev.h?h=vc&id=0cbd2b25b37ef5b2e6a14340dbca6d2d2d5af98e> > > The CSI-2 bus parameters are missing there currently but nothing prevents > adding them. The semantics of set_frame_desc() needs to be probably defined > better than it currently is. So which parameters are you thinking of putting in there? Just the number of lanes, or clocking modes and all other parameters for the CSI interface? It sounds like this should take over from the receiver's DT completely, other than for lane reordering. Of course the $1million question is rough timescales? The last commit on there appears to be March 2017. I've had to backburner my CSI2 receiver driver due to other time pressures, so it sounds like I may as well leave it there until this all settles down, or start looking at Niklas' driver and what changes infers. Thanks, Dave
