On 16/09/16 16:03, Armando Visconti wrote: > Hello Jonathan, > > Thx for the very long explanation. > > >> >> Anyhow, the philosophy was: >> >> preenable -> stuff related to getting ready for buffered operation. >> This might be as simple as turning off something else that prevents >> buffered operation. Often this is simply not provided as there >> is nothing useful to be done. >> >> update_scan_mode -> get the scan mode set up right for all the buffers >> being feed by the iio_push_to_buffers calls. >> >> postenable -> Actually start the flow of data now all the flags are >> lined up to say we are enabled. So in a typical triggered-buffer >> case call iio_trigger_attach_poll_func >> > > Usually our drivers use prenable() for starting the data flow > and postdisable() to stop it. > > Do you think it is a mistake? > Or acceptable? If you don't have a reason to use the update_scan_mode callback then it doesn't really matter. Conceptually I'd do it postenable and predisable, but I'm not that fussed! Jonathan > >> >> For the disable side: >> predisable unwinds postenable and postdisable typically unwinds >> preenable. >> > > Yes, that's clear. > > Regards, > Arm > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
