* [PATCH] staging: iio: trigger: Use standard attr for sampling frequency @ 2015-03-11 16:36 Daniel Baluta 2015-03-12 8:16 ` Octavian Purdila 0 siblings, 1 reply; 14+ messages in thread From: Daniel Baluta @ 2015-03-11 16:36 UTC (permalink / raw) To: jic23; +Cc: knaack.h, lars, pmeerw, linux-iio, linux-kernel 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@intel.com> --- 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? drivers/staging/iio/trigger/iio-trig-periodic-rtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c index 89df1d3..f1cfe2d 100644 --- a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c +++ b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c @@ -87,12 +87,12 @@ error_ret: return ret; } -static DEVICE_ATTR(frequency, S_IRUGO | S_IWUSR, +static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR, iio_trig_periodic_read_freq, iio_trig_periodic_write_freq); static struct attribute *iio_trig_prtc_attrs[] = { - &dev_attr_frequency.attr, + &dev_attr_sampling_frequency.attr, NULL, }; -- 1.9.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-11 16:36 [PATCH] staging: iio: trigger: Use standard attr for sampling frequency Daniel Baluta @ 2015-03-12 8:16 ` Octavian Purdila 2015-03-12 8:40 ` Lars-Peter Clausen 0 siblings, 1 reply; 14+ messages in thread From: Octavian Purdila @ 2015-03-12 8:16 UTC (permalink / raw) To: Daniel Baluta Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald, linux-iio, lkml On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> 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@intel.com> > --- > 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? > drivers/staging/iio/trigger/iio-trig-periodic-rtc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c > index 89df1d3..f1cfe2d 100644 > --- a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c > +++ b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c > @@ -87,12 +87,12 @@ error_ret: > return ret; > } > > -static DEVICE_ATTR(frequency, S_IRUGO | S_IWUSR, > +static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR, > iio_trig_periodic_read_freq, > iio_trig_periodic_write_freq); > > static struct attribute *iio_trig_prtc_attrs[] = { > - &dev_attr_frequency.attr, > + &dev_attr_sampling_frequency.attr, > NULL, > }; > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-12 8:16 ` Octavian Purdila @ 2015-03-12 8:40 ` Lars-Peter Clausen 2015-03-12 12:48 ` Daniel Baluta 2015-03-14 17:26 ` Jonathan Cameron 0 siblings, 2 replies; 14+ messages in thread From: Lars-Peter Clausen @ 2015-03-12 8:40 UTC (permalink / raw) To: Octavian Purdila, Daniel Baluta Cc: Jonathan Cameron, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On 03/12/2015 09:16 AM, Octavian Purdila wrote: > On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> 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@intel.com> >> --- >> 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 - Lars ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-12 8:40 ` Lars-Peter Clausen @ 2015-03-12 12:48 ` Daniel Baluta 2015-03-14 17:21 ` Jonathan Cameron 2015-03-14 17:26 ` Jonathan Cameron 1 sibling, 1 reply; 14+ messages in thread From: Daniel Baluta @ 2015-03-12 12:48 UTC (permalink / raw) To: Lars-Peter Clausen Cc: Octavian Purdila, Daniel Baluta, Jonathan Cameron, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> wrote: > On 03/12/2015 09:16 AM, Octavian Purdila wrote: >> >> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> >> 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@intel.com> >>> --- >>> 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. thanks, Daniel. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-12 12:48 ` Daniel Baluta @ 2015-03-14 17:21 ` Jonathan Cameron 2015-03-15 20:34 ` Daniel Baluta 2015-03-18 15:04 ` Daniel Baluta 0 siblings, 2 replies; 14+ messages in thread From: Jonathan Cameron @ 2015-03-14 17:21 UTC (permalink / raw) To: Daniel Baluta, Lars-Peter Clausen Cc: Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On 12/03/15 12:48, Daniel Baluta wrote: > On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> wrote: >> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>> >>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> >>> 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@intel.com> >>>> --- >>>> 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! Jonathan > > thanks, > Daniel. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-14 17:21 ` Jonathan Cameron @ 2015-03-15 20:34 ` Daniel Baluta 2015-03-15 20:49 ` Jonathan Cameron 2015-03-18 15:04 ` Daniel Baluta 1 sibling, 1 reply; 14+ messages in thread From: Daniel Baluta @ 2015-03-15 20:34 UTC (permalink / raw) To: Jonathan Cameron Cc: Daniel Baluta, Lars-Peter Clausen, Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@kernel.org> wrote: > On 12/03/15 12:48, Daniel Baluta wrote: >> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>> >>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> >>>> 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@intel.com> >>>>> --- >>>>> 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-15 20:34 ` Daniel Baluta @ 2015-03-15 20:49 ` Jonathan Cameron 2015-03-15 20:52 ` Daniel Baluta 0 siblings, 1 reply; 14+ messages in thread From: Jonathan Cameron @ 2015-03-15 20:49 UTC (permalink / raw) To: Daniel Baluta Cc: Lars-Peter Clausen, Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On 15/03/15 20:34, Daniel Baluta wrote: > On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@kernel.org> wrote: >> On 12/03/15 12:48, Daniel Baluta wrote: >>> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>>> >>>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> >>>>> 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@intel.com> >>>>>> --- >>>>>> 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. Hmm I think the branch I just pushed to iio.git as configfstest might be the last code I had. Not sure I got much beyond trying to create the infrastructure for the subsystem to have quite a few different things under a semi unified location in configfs. Honestly can't really recall what this actually does! Jonathan > > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-15 20:49 ` Jonathan Cameron @ 2015-03-15 20:52 ` Daniel Baluta 0 siblings, 0 replies; 14+ messages in thread From: Daniel Baluta @ 2015-03-15 20:52 UTC (permalink / raw) To: Jonathan Cameron Cc: Daniel Baluta, Lars-Peter Clausen, Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On Sun, Mar 15, 2015 at 10:49 PM, Jonathan Cameron <jic23@kernel.org> wrote: > On 15/03/15 20:34, Daniel Baluta wrote: >> On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@kernel.org> wrote: >>> On 12/03/15 12:48, Daniel Baluta wrote: >>>> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>>>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>>>> >>>>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> >>>>>> 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@intel.com> >>>>>>> --- >>>>>>> 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. > Hmm I think the branch I just pushed to iio.git as configfstest might be > the last code I had. Not sure I got much beyond trying to create the infrastructure > for the subsystem to have quite a few different things under a semi unified location in > configfs. Honestly can't really recall what this actually does! All right, thanks a lot! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-14 17:21 ` Jonathan Cameron 2015-03-15 20:34 ` Daniel Baluta @ 2015-03-18 15:04 ` Daniel Baluta 2015-03-18 16:47 ` Lars-Peter Clausen 1 sibling, 1 reply; 14+ messages in thread From: Daniel Baluta @ 2015-03-18 15:04 UTC (permalink / raw) To: Jonathan Cameron Cc: Daniel Baluta, Lars-Peter Clausen, Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@kernel.org> wrote: > On 12/03/15 12:48, Daniel Baluta wrote: >> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>> >>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> >>>> 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@intel.com> >>>>> --- >>>>> 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! First notable problem with using configfs with IIO is boot time modules loading. Because, * configs uses module_init(configfs_init); * IIO uses subsys_initcall(iio_init); it is guaranteed that IIO will be loaded before configfs. Not fun! :) So for the moment I will not add configfs support directly into industrialiio-core but in a separate module. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-18 15:04 ` Daniel Baluta @ 2015-03-18 16:47 ` Lars-Peter Clausen 2015-03-18 17:21 ` Daniel Baluta 0 siblings, 1 reply; 14+ messages in thread From: Lars-Peter Clausen @ 2015-03-18 16:47 UTC (permalink / raw) To: Daniel Baluta, Jonathan Cameron Cc: Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On 03/18/2015 04:04 PM, Daniel Baluta wrote: > On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@kernel.org> wrote: >> On 12/03/15 12:48, Daniel Baluta wrote: >>> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>>> >>>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> >>>>> 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@intel.com> >>>>>> --- >>>>>> 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! > > First notable problem with using configfs with IIO is boot time modules > loading. > > Because, > > * configs uses module_init(configfs_init); > * IIO uses subsys_initcall(iio_init); > > it is guaranteed that IIO will be loaded before configfs. Not fun! :) > > So for the moment I will not add configfs support directly into > industrialiio-core but in a separate module. Just fix configfs, that should clearly not be at the module init level. But keeping it in a separate module doesn't hurt either way. - Lars ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-18 16:47 ` Lars-Peter Clausen @ 2015-03-18 17:21 ` Daniel Baluta 2015-03-18 17:25 ` Lars-Peter Clausen 0 siblings, 1 reply; 14+ messages in thread From: Daniel Baluta @ 2015-03-18 17:21 UTC (permalink / raw) To: Lars-Peter Clausen Cc: Daniel Baluta, Jonathan Cameron, Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On Wed, Mar 18, 2015 at 6:47 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: > On 03/18/2015 04:04 PM, Daniel Baluta wrote: >> >> On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@kernel.org> >> wrote: >>> >>> On 12/03/15 12:48, Daniel Baluta wrote: >>>> >>>> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> >>>> wrote: >>>>> >>>>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>>>> >>>>>> >>>>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta >>>>>> <daniel.baluta@intel.com> >>>>>> 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@intel.com> >>>>>>> --- >>>>>>> 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! >> >> >> First notable problem with using configfs with IIO is boot time modules >> loading. >> >> Because, >> >> * configs uses module_init(configfs_init); >> * IIO uses subsys_initcall(iio_init); >> >> it is guaranteed that IIO will be loaded before configfs. Not fun! :) >> >> So for the moment I will not add configfs support directly into >> industrialiio-core but in a separate module. > > > Just fix configfs, that should clearly not be at the module init level. > > But keeping it in a separate module doesn't hurt either way. Looking at drivers/fs all filesystems modules are at module init level. I'll drop an email to fs folks :). What if IIO core should be at module init core? Daniel. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-18 17:21 ` Daniel Baluta @ 2015-03-18 17:25 ` Lars-Peter Clausen 2015-03-21 11:44 ` Jonathan Cameron 0 siblings, 1 reply; 14+ messages in thread From: Lars-Peter Clausen @ 2015-03-18 17:25 UTC (permalink / raw) To: Daniel Baluta Cc: Jonathan Cameron, Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On 03/18/2015 06:21 PM, Daniel Baluta wrote: > On Wed, Mar 18, 2015 at 6:47 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >> On 03/18/2015 04:04 PM, Daniel Baluta wrote: >>> >>> On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@kernel.org> >>> wrote: >>>> >>>> On 12/03/15 12:48, Daniel Baluta wrote: >>>>> >>>>> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> >>>>> wrote: >>>>>> >>>>>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta >>>>>>> <daniel.baluta@intel.com> >>>>>>> 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@intel.com> >>>>>>>> --- >>>>>>>> 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! >>> >>> >>> First notable problem with using configfs with IIO is boot time modules >>> loading. >>> >>> Because, >>> >>> * configs uses module_init(configfs_init); >>> * IIO uses subsys_initcall(iio_init); >>> >>> it is guaranteed that IIO will be loaded before configfs. Not fun! :) >>> >>> So for the moment I will not add configfs support directly into >>> industrialiio-core but in a separate module. >> >> >> Just fix configfs, that should clearly not be at the module init level. >> >> But keeping it in a separate module doesn't hurt either way. > > Looking at drivers/fs all filesystems modules are at module init level. > I'll drop an email to fs folks :). debugfs is at core_initcall() and in my opinion configfs is on the same level from a infrastructure point of view. > > What if IIO core should be at module init core? It's a subsystem, it should be at subsys_initcall(). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-18 17:25 ` Lars-Peter Clausen @ 2015-03-21 11:44 ` Jonathan Cameron 0 siblings, 0 replies; 14+ messages in thread From: Jonathan Cameron @ 2015-03-21 11:44 UTC (permalink / raw) To: Lars-Peter Clausen, Daniel Baluta Cc: Octavian Purdila, Hartmut Knaack, Peter Meerwald, linux-iio, lkml On 18/03/15 17:25, Lars-Peter Clausen wrote: > On 03/18/2015 06:21 PM, Daniel Baluta wrote: >> On Wed, Mar 18, 2015 at 6:47 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>> On 03/18/2015 04:04 PM, Daniel Baluta wrote: >>>> >>>> On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@kernel.org> >>>> wrote: >>>>> >>>>> On 12/03/15 12:48, Daniel Baluta wrote: >>>>>> >>>>>> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@metafoo.de> >>>>>> wrote: >>>>>>> >>>>>>> On 03/12/2015 09:16 AM, Octavian Purdila wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta >>>>>>>> <daniel.baluta@intel.com> >>>>>>>> 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@intel.com> >>>>>>>>> --- >>>>>>>>> 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! >>>> >>>> >>>> First notable problem with using configfs with IIO is boot time modules >>>> loading. >>>> >>>> Because, >>>> >>>> * configs uses module_init(configfs_init); >>>> * IIO uses subsys_initcall(iio_init); >>>> >>>> it is guaranteed that IIO will be loaded before configfs. Not fun! :) >>>> >>>> So for the moment I will not add configfs support directly into >>>> industrialiio-core but in a separate module. >>> >>> >>> Just fix configfs, that should clearly not be at the module init level. >>> >>> But keeping it in a separate module doesn't hurt either way. >> >> Looking at drivers/fs all filesystems modules are at module init level. >> I'll drop an email to fs folks :). > > debugfs is at core_initcall() and in my opinion configfs is on the same level from a infrastructure point of view. Seems logical. As far as I could tell, last time I looked, configfs still had relatively few users and I guess most of the are individual drivers. It's a good idea, but we'll be breaking some new ground using it extensively in IIO. It did occur to me that we should be drawing up a list of what IIO elements it makes sense for. Quick thoughts from me on this would be 1) Software trigger creation / destruction 2) Mappings to 'soft' in kernel users such as iio_hwmon and iio_input. Doing these via the device tree has always been a somewhat 'interesting' corner and rather limiting. I have some thoughts on more advanced 'filter' drivers that do some of what the sensor hubs we are seeing are doing (step counting for example) but without needing an additional processor. Will be interesting to see if we save enough overhead to make this worthwhile, rather than blasting all data out to user space. 3) Perhaps iio on iio drivers (allows for complex data demux / mux operations) and also allows us to drive the separation between the IIO userspace interface and the backend. Something that has been on the wish list for a while. Quick win would be get (1) done, but we want to keep the layout etc flexible enough to allow for (2) at least. Jonathan > >> >> What if IIO core should be at module init core? > > It's a subsystem, it should be at subsys_initcall(). > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency 2015-03-12 8:40 ` Lars-Peter Clausen 2015-03-12 12:48 ` Daniel Baluta @ 2015-03-14 17:26 ` Jonathan Cameron 1 sibling, 0 replies; 14+ messages in thread From: Jonathan Cameron @ 2015-03-14 17:26 UTC (permalink / raw) To: Lars-Peter Clausen, Octavian Purdila, Daniel Baluta Cc: Hartmut Knaack, Peter Meerwald, linux-iio, lkml On 12/03/15 08:40, Lars-Peter Clausen wrote: > On 03/12/2015 09:16 AM, Octavian Purdila wrote: >> On Wed, Mar 11, 2015 at 6:36 PM, Daniel Baluta <daniel.baluta@intel.com> 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@intel.com> >>> --- >>> 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). Just to add to this, the rtc timer stuff was a nasty hack a long time ago to allow use of additional periodic timers available on the pxa72x. At one point I had a rtc driver that exposed these. There was discussion at the time about more generic 'additional timer' support in the kernel but no one ever took the job on. The blackfin timer driver was a later approach to handling the same sort of timers. In more recent times, the periodic timer element of the RTC framework has become entirely simulated anyway with no use made of true periodic interrupts any more. As such its a totally silly approach to getting us a periodic trigger. Perhaps we should just drop it now. Previously we have kept it around on the basis the hrt trigger was always on the way, but does anyone actively use it? Jonathan > > 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 > > - Lars ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-03-21 11:45 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-11 16:36 [PATCH] staging: iio: trigger: Use standard attr for sampling frequency Daniel Baluta 2015-03-12 8:16 ` Octavian Purdila 2015-03-12 8:40 ` Lars-Peter Clausen 2015-03-12 12:48 ` Daniel Baluta 2015-03-14 17:21 ` Jonathan Cameron 2015-03-15 20:34 ` Daniel Baluta 2015-03-15 20:49 ` Jonathan Cameron 2015-03-15 20:52 ` Daniel Baluta 2015-03-18 15:04 ` Daniel Baluta 2015-03-18 16:47 ` Lars-Peter Clausen 2015-03-18 17:21 ` Daniel Baluta 2015-03-18 17:25 ` Lars-Peter Clausen 2015-03-21 11:44 ` Jonathan Cameron 2015-03-14 17:26 ` Jonathan Cameron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).