[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEnQRZD=XcAjV0YNHVRn30oEtXa++e-vSb3y_oS9h3+A2LSH4Q@mail.gmail.com>
Date: Sun, 15 Mar 2015 22:34:21 +0200
From: Daniel Baluta <daniel.baluta@...el.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Daniel Baluta <daniel.baluta@...el.com>,
Lars-Peter Clausen <lars@...afoo.de>,
Octavian Purdila <octavian.purdila@...el.com>,
Hartmut Knaack <knaack.h@....de>,
Peter Meerwald <pmeerw@...erw.net>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] staging: iio: trigger: Use standard attr for sampling frequency
On Sat, Mar 14, 2015 at 7:21 PM, Jonathan Cameron <jic23@...nel.org> wrote:
> On 12/03/15 12:48, Daniel Baluta wrote:
>> On Thu, Mar 12, 2015 at 10:40 AM, Lars-Peter Clausen <lars@...afoo.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@...el.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@...el.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists