On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > On 12/03/15 12:48, Daniel Baluta wrote: >> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: >>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>> >>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@xxxxxxxxx> >>>> wrote: >>>>> >>>>> >>>>> As written in Documentation/ABI/testing/sysfs-bus-iio the trigger >>>>> attribute for sampling frequency should be sampling_frequency. >>>>> >>>>> Fix this for iio-trig-periodic-rtc module in order to prepare it >>>>> for moving out of staging. >>>>> >>>>> Signed-off-by: Daniel Baluta <daniel.baluta@xxxxxxxxx> >>>>> --- >>>>> Jonathan, this module is very useful for devices that do not have >>>>> an interrupt pin. >>>>> >>>>> We are working on drivers for such devices and would be very nice to >>>>> move this driver in advance to the IIO non-staging location. >>>>> >>>>> What do you say? >>>>> >>>> >>>> Hmm, I wonder what are the advantages of using RTC timers. Couldn't we >>>> use a regular kernel timer instead? >>> >>> >>> The long term plan is to get rid of the RTC timer trigger due to its various >>> limitations (poor resolution, etc). >>> >>> There is the hrtimer trigger >>> (https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/staging/iio/trigger/iio-trig-hrtimer.c) >>> but we haven't agreed on a proper interface yet how to instantiate the >>> hrtimer trigger. >>> >>> Check the ml archive for the various discussions on it: >>> http://marc.info/?l=linux-iio&w=2&r=1&s=hrtimer&q=b >> >> >> Hi Lars, >> >> That was an interesting reading. There were people trying to push >> hrtimer based IIO trigger 4 years ago :). >> >> I think it's now the time to have this upstream. >> >> I will be back :) (as many others said before) with an RFC patch. >> >> I think we should keep the following requirements: >> >> 1) Create a common framework for software based triggers. >> 2) User space driven configuration for trigger instances, >> as opposed to platform device files used for RTC based trigger >> 3) Remove RTC interrupt source, use hrtimers instead >> >> Still not clear, but I will trying to figure it out during implementation: >> >> 4) configfs vs sysfs interface. >> >> At the first glance, I would say we should stay with sysfs interface in order >> to avoid another dependency. But let's see how it works. > This issue with the sysfs only approach (as originally raised by Lars) > is that it is actually very poorly suited to instantiating new elements of > the device model. Configfs was introduced in the first place exactly to > cover this area. We only ended up with the instantiation code in > the sysfs trigger via sysfs because at the time (a good long while ago!) > I wasn't aware of configfs. > > I have some initial work on the base elements on an iio configfs interface > somewhere that I can dig out if you like. I started working on it in a rare > quiet period about a year ago, but never got all that far. > > There aren't that many examples in tree of how to actually use configfs > so it's a bit more of a learning curve than sysfs! I use this: http://lxr.free-electrons.com/source/Documentation/filesystems/configfs/configfs_example_explicit.c as an example. But, sure if you find your work please share. I am not sure if we could use this approach for iio-trig-interrupt trigger? Daniel. -- 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