Hi Dave, Apologies for the delay. On Fri, Sep 21, 2018 at 02:46:23PM +0100, Dave Stevenson wrote: > 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? I think it could be the number of active lanes, I don't think other parameters need to change. > It sounds like this should take over from the receiver's DT > completely, other than for lane reordering. Hmm. Right now I don't have an opinion either way. But I'd like to know what others think. The endpoint configuration is currently local to the endpoint only. On other busses than CSI-2 there are more parameters that may be different on each side of the endpoint. If the parameters are moved to the frame descriptor entirely, there's no way to e.g. validate them in probe. At least one would need to show that this is not an issue, or address it somehow. > > 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. Yes; if you write patches to this, please do that on top of Niklas' set. -- Regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx
