On Sun, Jun 05, 2011 at 04:28:03PM +0300, Sakari Ailus wrote: > On Wed, Jun 01, 2011 at 10:41:21AM -0300, Mauro Carvalho Chehab wrote: > > > There are currently two use cases: Sakari's flash controller needs to > > > report errors which are a bitmask of possible error conditions. It is way > > > overkill to split that up in separate boolean controls, especially since > > > apps will also want to get an event whenever such an error is raised. > > > > Hmm... returning errors via V4L2 controls don't seem to be a good implementation. > > I need to review his RFC to better understand his idea. > > The "errors" are not errors in the traditional meaning --- they also are > called faults. They signal that there's either a temporary or a permanent > hardware problem with the flash controller. The user will be able to > mitigate with many of these. Also the faults do arrive asynchronously, > making traditional error handling unsuitable for them. For example, the LED > controller may overheat in some situations which cause immediate LED > shutdown, leading to only partially flash exposed frame. When this happens > the user has to be notified of the condition, and to avoid reading a large > set of controls, a single bitmask control telling directly the reason for > the trouble is ideal. > > The full RFC may be found here: > > <USR:http://www.spinics.net/lists/linux-media/msg32030.html> That was supposed to be <URL:http://www.spinics.net/lists/linux-media/msg32030.html> The adp1653 flash controller driver using the flash API. The patches have been acked by Laurent already. Regards, -- Sakari Ailus sakari.ailus@xxxxxx -- 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