Hi, On Tuesday 28 December 2010 19:35:05 Shuzhen Wang wrote: > > -----Original Message----- > > From: Mauro Carvalho Chehab [mailto:mchehab@xxxxxxxxxx] > > Sent: Monday, December 27, 2010 4:12 AM > > To: Hans Verkuil > > Cc: Shuzhen Wang; linux-media@xxxxxxxxxxxxxxx; hzhong@xxxxxxxxxxxxxx > > Subject: Re: RFC: V4L2 driver for Qualcomm MSM camera. > > > > Em 24-12-2010 09:19, Hans Verkuil escreveu: > > >> MSM_CAM_IOCTL_SENSOR_IO_CFG > > >> > > >> Get or set sensor configurations: fps, line_pf, pixels_pl, > > >> exposure and gain, etc. The setting is stored in > > > > sensor_cfg_data > > > > >> structure. > > > > This doesn't make much sense to me as-is. The V4L2 API can set fps, > > exposure, > > gain and other things. Please only use private ioctl's for those things > > that > > aren't provided elsewhere and can't be mapped into some CTRL. > > In our design, all these private ioctls are only called from the service > daemon, so they are transparent to the application. For example, when a > standard V4L2 API is called from the app to change fps, it gets translated > to MSM_CAM_IOCTL_SENSOR_IO_CFG in the daemon, and sent to the sensor > hardware. Please don't do that. The daemon should use the standard V4L2 API. Applications must be able to use those APIs directly if they wish to do so. Using the daemon must be completely optional for applications that don't want software-assisted algorithms such as 3A. > > >> MSM_CAM_IOCTL_CONFIG_VFE > > >> > > >> Change settings of different components of VFE hardware. > > > > Hard to analyze it, as you didn't provide any details ;) > > > > Maybe the media controller API will be the right place for it. As Hans > > pointed, > > the hardware should be able to work without private ioctl's and/or > > media > > controller stuff. > > Because all the private ioctl's are only called from daemon, they are not > very big concern here IMHO. The fact that a lot of stuff is done in daemon > does make it harder to decouple. > > MSM_CAM_IOCTL_CONFIG_VFE ioctl calls pass in a structure like this: > struct msm_vfe_cfg_cmd { > int cmd_type; > uint16_t length; > void *value; > }; > Where cmd_type indicates what component of the VFE pipeline to configure, > For example, enable/disable stats, VFE buffers configuration, demosaic, > color conversion/correction, etc. The value field will contain the > appropriate data for the said cmd_type. > > > >> MSM_CAM_IOCTL_CTRL_CMD_DONE > > >> > > >> Notify the driver that the ctrl command is finished. > > > > Just looking at the ioctl name, this doesn't make much sense. If you > > open a > > device on normal way, the ioctl it will block until the operation is > > completed. > > > > Could you please provide more details about it? > > The idea is that the kernel driver delegates the control command to the > service daemon ( by means of v4l2_event ). The V4L2 control command call > from the app is blocked until the service daemon is done with operation. -EINVAL. No, no and no again. That's a completely broken design. Go back to the black board and create a real Linux driver. If you want a daemon to isolate proprietary code, fine, but it must be totally optional. Make the application communicate with the daemon (through a libv4l plugin for instance), and have the daemon use the V4L2 API to communicate with the hardware. I will strongly NAK any implementation that requires a daemon. > For example, for a VIDIOC_S_CTRL, the driver wraps the v4l2_ctrl structure > in a v4l2_event, publishes it to the daemon, and blocks. The daemon then > calls either MSM_CAM_IOCTL_CONFIG_VFE or MSM_CAM_IOCTL_SENSOR_IO_CFG or > both to configure the hardware. Once thoese ioctls return, it then call > MSM_CAM_IOCTL_CTRL_CMD_DONE to notify the driver so that it can wake up > the application. > > > >> MSM_CAM_IOCTL_AXI_CONFIG > > >> > > >> Configure AXI bus parameters (frame buffer addresses, > > > > offsets) to > > > > >> the VFE hardware. > > > > Hard to analyze it, as you didn't provide any details ;) > > > > The same comments I did for MSM_CAM_IOCTL_CONFIG_VFE apply here. > > This registers buffers with VFE hardware. Like all other private ioctls, > It's called from the daemon. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
