Hi Jacopo, On Tue, Nov 10, 2020 at 06:40:36PM +0100, Jacopo Mondi wrote: > The bcm2835-unicam driver is currently in staging mainly for > two reasons: > - Handling of CSI-2 embedded data > - Usage of both media controller API and subdev kAPI > > Provide a more detailed description of the currently on-going design > discussions in the associated TODO file. > > Signed-off-by: Jacopo Mondi <jacopo@xxxxxxxxxx> > --- > drivers/staging/media/bcm2835-unicam/TODO | 37 +++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 drivers/staging/media/bcm2835-unicam/TODO > > diff --git a/drivers/staging/media/bcm2835-unicam/TODO b/drivers/staging/media/bcm2835-unicam/TODO > new file mode 100644 > index 0000000000000..c7840872eea4c > --- /dev/null > +++ b/drivers/staging/media/bcm2835-unicam/TODO > @@ -0,0 +1,37 @@ > +BCM2835 Unicam driver TODO list > +=============================== > + > +The unicam driver could be considered ready to be moved out of the staging > +directory in terms of code quality and expected functionalities. > + > +However there currently are two design issues that suggest the driver is > +better kept in staging for the time being. > + > +CSI-2 Embedded data support: > +---------------------------- > + > +The RaspberryPi camera stack and camera applications rely on the availability of > +the sensor produced CSI-2 embedded data, whose support is currently not > +finalized in mainline Linux. > + > +The driver conditionally registers an additional video device node > +'unicam-embedded' with a single sink pad which connects to the sensor > +sub-device source pad #1 to expose ancillary data. > + > +Currently none of the mainline sensor drivers register more than a single pad, > +and consequentially no embedded data from the sensor are exposed to userspace. > + > +The current implementation is then subject to changes depending on how support > +for CSI-2 embedded data gets finalized in Linux. Are you looking to use out-of-tree sensor drivers that have two pads? I'd rather see sensor drivers merged to mainline proper. But as noted in the other e-mail, we need VC / stream support so this needs to be addressed for reasons not related to Unicam. > + > +Media controller support: > +------------------------- > + > +Due to compatibility reasons with the existing RaspberryPi software ecosystem > +the unicam driver implements the media controller interface to allow the > +enumeration of the connected entities but handles the configuration of the > +sensor sub-device using the v4l2-subdev kAPI instead of delegating that to > +user-space. > + > +Discussions are on-going on how this should be better handled (driver option, > +KConfig option etc etc). That's a fair use case. There are two ways to handle it, either in the kernel where the choice affects how the user space looks like. You have an option of module parameter or Kconfig option there, and both are true annoyances. Another option is to work around it in the user space, wrapping the IOCTL calls. This way no kernel build or module load time parameters would be needed to switch between the two sets of user space programs. We probably can't decide it now, but could an MC-only driver + user space compatibility layer be an option here? -- Kind regards, Sakari Ailus
