From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751568AbbCNRWA (ORCPT ); Sat, 14 Mar 2015 13:22:00 -0400 Received: from saturn.retrosnub.co.uk ([178.18.118.26]:55733 "EHLO saturn.retrosnub.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbbCNRV5 (ORCPT ); Sat, 14 Mar 2015 13:21:57 -0400 Message-ID: <55046E31.3020404@kernel.org> Date: Sat, 14 Mar 2015 17:21:53 +0000 From: Jonathan Cameron User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Daniel Baluta , Lars-Peter Clausen CC: Octavian Purdila , Hartmut Knaack , Peter Meerwald , "linux-iio@vger.kernel.org" , lkml Subject: Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency References: <1426091777-30592-1-git-send-email-daniel.baluta@intel.com> <550150EC.5080100@metafoo.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/03/15 12:48, Daniel Baluta wrote: > On Thu, Mar 12, 2015 at 10:40 AM, 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 >>> 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 >>>> --- >>>> 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. >