On Sun, 2010-10-31 at 15:25 +0100, ext Greg KH wrote:
> >
> > What I would like to do is:
> >
> > Control sensors operating mode and regulators based on the userspace
> > activity. If no-one is interested about the sensor, it can be turned
> > totally off including its operating power via regulator framework.
> >
> > So far the only accepted interface for the small sensor seems to be
> > sysfs. I tried use misc device but it was not accepted.
>
> Look at the drivers/staging/iio/ subsystem. It is working on a
> framework that you can use through a character device (I think) to
> properly manage your drivers in this manner.
>
> Try working with those developers as I think it is what you are looking
> for here.
>
I took a look to that. It seems that iio is more or less sysfs based.
There are ring buffers and event device which are chardev based
but still the data outside ring buffer and the control is sysfs based.
By getting open and close from sysfs would be nice from the driver
point of view. However, I understand that this is just overhead for
majority of the cases.
Regards,
Samu
> I took a look to that. It seems that iio is more or less sysfs based.
> There are ring buffers and event device which are chardev based
> but still the data outside ring buffer and the control is sysfs based.
IIO is sysfs dependant, heavyweight and makes no sense for some of the
sysfs based drivers. IIO is also staging based and Linus already threw
out the last attempt to unify these drivers sanely with an ALS layer -
which was smaller, cleaner and better !
> By getting open and close from sysfs would be nice from the driver
> point of view. However, I understand that this is just overhead for
> majority of the cases.
The alternative really is to end up with a parallel 'not quite sysfs'
which is sysfs + open/close. My feeling is its cleaner to have a hook
at the per device level (so we don't bloat the sysfs nodes at all) than
have two copies of sysfs.
Alan
On Mon, Nov 01, 2010 at 04:57:01PM +0000, Alan Cox wrote:
> > I took a look to that. It seems that iio is more or less sysfs based.
> > There are ring buffers and event device which are chardev based
> > but still the data outside ring buffer and the control is sysfs based.
>
> IIO is sysfs dependant, heavyweight and makes no sense for some of the
> sysfs based drivers. IIO is also staging based and Linus already threw
> out the last attempt to unify these drivers sanely with an ALS layer -
> which was smaller, cleaner and better !
I think we need to revisit this issue again, before iio is merged to the
main kernel tree. I've been totally ignoring the iio user/kernel api at
the moment, waiting for things to settle down there.
thanks,
greg k-h
On Mon, 1 Nov 2010 11:07:40 -0700
Greg KH <[email protected]> wrote:
> On Mon, Nov 01, 2010 at 04:57:01PM +0000, Alan Cox wrote:
> > > I took a look to that. It seems that iio is more or less sysfs
> > > based. There are ring buffers and event device which are chardev
> > > based but still the data outside ring buffer and the control is
> > > sysfs based.
> >
> > IIO is sysfs dependant, heavyweight and makes no sense for some of
> > the sysfs based drivers. IIO is also staging based and Linus
> > already threw out the last attempt to unify these drivers sanely
> > with an ALS layer - which was smaller, cleaner and better !
>
> I think we need to revisit this issue again, before iio is merged to
> the main kernel tree. I've been totally ignoring the iio user/kernel
> api at the moment, waiting for things to settle down there
Actually I think there is another way to do it cleanly
Keep a flag per device (or per runtime pm struct of device)
And on the open/close do
if (runtime_pm on device && device has SYSFS_PM set)
pm_runtime_foo
so that devices that need to be powered up to handle sysfs requests can
set a single flag and just work.
>-----Original Message-----
>From: ext Alan Cox [mailto:[email protected]]
>Sent: 03 November, 2010 11:45
>To: Greg KH
>Cc: Onkalo Samu.P (Nokia-MS/Tampere); ext Henrique de Moraes Holschuh;
>Alan Cox; [email protected]; [email protected]
>Subject: Re: sysfs and power management
>
>On Mon, 1 Nov 2010 11:07:40 -0700
>Greg KH <[email protected]> wrote:
>
>> On Mon, Nov 01, 2010 at 04:57:01PM +0000, Alan Cox wrote:
>> > > I took a look to that. It seems that iio is more or less sysfs
>> > > based. There are ring buffers and event device which are chardev
>> > > based but still the data outside ring buffer and the control is
>> > > sysfs based.
>> >
>> > IIO is sysfs dependant, heavyweight and makes no sense for some of
>> > the sysfs based drivers. IIO is also staging based and Linus
>> > already threw out the last attempt to unify these drivers sanely
>> > with an ALS layer - which was smaller, cleaner and better !
>>
>> I think we need to revisit this issue again, before iio is merged to
>> the main kernel tree. I've been totally ignoring the iio user/kernel
>> api at the moment, waiting for things to settle down there
>
>Actually I think there is another way to do it cleanly
>
>Keep a flag per device (or per runtime pm struct of device)
>
>And on the open/close do
>
> if (runtime_pm on device && device has SYSFS_PM set)
> pm_runtime_foo
>
>so that devices that need to be powered up to handle sysfs requests can
>set a single flag and just work.
That is one quite clean way.
sysfs_ops still needs function pointer to device core function which does pm_runtime
calls.
And there is one drawback. Driver doesn't know about new users after the first one.
It may want to refresh results whenever a new user appears. But that is probably not
a big issue.
-Samu
On Wed, Nov 03, 2010 at 09:44:52AM +0000, Alan Cox wrote:
> On Mon, 1 Nov 2010 11:07:40 -0700
> Greg KH <[email protected]> wrote:
>
> > On Mon, Nov 01, 2010 at 04:57:01PM +0000, Alan Cox wrote:
> > > > I took a look to that. It seems that iio is more or less sysfs
> > > > based. There are ring buffers and event device which are chardev
> > > > based but still the data outside ring buffer and the control is
> > > > sysfs based.
> > >
> > > IIO is sysfs dependant, heavyweight and makes no sense for some of
> > > the sysfs based drivers. IIO is also staging based and Linus
> > > already threw out the last attempt to unify these drivers sanely
> > > with an ALS layer - which was smaller, cleaner and better !
> >
> > I think we need to revisit this issue again, before iio is merged to
> > the main kernel tree. I've been totally ignoring the iio user/kernel
> > api at the moment, waiting for things to settle down there
>
> Actually I think there is another way to do it cleanly
>
> Keep a flag per device (or per runtime pm struct of device)
>
> And on the open/close do
>
> if (runtime_pm on device && device has SYSFS_PM set)
> pm_runtime_foo
>
> so that devices that need to be powered up to handle sysfs requests can
> set a single flag and just work.
That sounds like a reasonable idea.
thanks,
greg k-h
>-----Original Message-----
>From: ext Greg KH [mailto:[email protected]]
>Sent: 03 November, 2010 15:09
>To: Alan Cox
>Cc: Onkalo Samu.P (Nokia-MS/Tampere); ext Henrique de Moraes Holschuh;
>Alan Cox; [email protected]; [email protected]
>Subject: Re: sysfs and power management
>
>On Wed, Nov 03, 2010 at 09:44:52AM +0000, Alan Cox wrote:
>> On Mon, 1 Nov 2010 11:07:40 -0700
>> Greg KH <[email protected]> wrote:
>>
>> > On Mon, Nov 01, 2010 at 04:57:01PM +0000, Alan Cox wrote:
>> > > > I took a look to that. It seems that iio is more or less sysfs
>> > > > based. There are ring buffers and event device which are chardev
>> > > > based but still the data outside ring buffer and the control is
>> > > > sysfs based.
>> > >
>> > > IIO is sysfs dependant, heavyweight and makes no sense for some of
>> > > the sysfs based drivers. IIO is also staging based and Linus
>> > > already threw out the last attempt to unify these drivers sanely
>> > > with an ALS layer - which was smaller, cleaner and better !
>> >
>> > I think we need to revisit this issue again, before iio is merged to
>> > the main kernel tree. I've been totally ignoring the iio
>user/kernel
>> > api at the moment, waiting for things to settle down there
>>
>> Actually I think there is another way to do it cleanly
>>
>> Keep a flag per device (or per runtime pm struct of device)
>>
>> And on the open/close do
>>
>> if (runtime_pm on device && device has SYSFS_PM set)
>> pm_runtime_foo
>>
>> so that devices that need to be powered up to handle sysfs requests
>can
>> set a single flag and just work.
>
>That sounds like a reasonable idea.
>
I'm working with the implementation which adds possibility to add per attribute
open_close_notification method with minimal overhead to current system.
-Samu