Re: [PATCH] Add a driver to support InvenSense mpu3050 gyroscope chip.

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Wednesday, March 16, 2011, Dmitry Torokhov wrote:
> On Tue, Mar 15, 2011 at 12:58:46PM +0000, Alan Cox wrote:
> > > I'd be more happy if it was just an input device. If non-wired interrupt
> > > is a common case then we should probably add polled input device mode,
> > 
> > I can't really answer how common it is or would be - its a generic chip
> > that is used on all sorts of equipment
> > 
> > > but we certainly should not register completely non-functional input
> > > device as the driver does now.
> > 
> > Agreed
> > 
> > > We also have a way of retrieving current (or rather most recent)
> > > coordinates via EVIOCGABS so I am not sure why we want the sysfs way of
> > > retrieving coordinates as well.
> > 
> > The sysfs way comes about because the devices are very very power
> > oriented, waking up and polling regularly burns power, hence also the
> > power control side. Opening an input device would power it up for the
> > duration it was open and the polling would cause a lot of wakeups burning
> > power.
> > 
> > Doing open/EVIOCGABS/close to avoid that aspect of the input layer
> > won't ensure you get current data that I can see - because an IRQ may not
> > have occurred between the open and the EVIOCGABS so any data may be very
> > stale or non-existent.
> 
> I would be perfectly fine with a driver that does refresh it's state in
> dev->open() if we expect that data might be stale. We normally do not do
> that because old data is normally not interesting for touchpads, mice or
> keyboards and we not always have option of querying current hardware
> state.
> 
> > 
> > The polled case looks trivial to sort but for an IRQ driver driver it
> > looks like you would need a new "get co-ordinates right now" optional
> > method tht EVIOCGABS would use if available ?
> > 
> > > Regarding power mode - I really believe that this should be done on the
> > > driver core level instead of implementing "manual off" in every single
> > > driver out there.
> > 
> > Definitely - not sure what plans Rafael has there ?
> >
> 
> Last time we discussed this we were talking about sysfs entry at the
> driver core level allowing userspace to "expire" idle timer and force
> runtime PM action. Rafael, did I remember that right?

Well, I'm not exactly sure what the question is about. :-)

There's the family of pm_*_autosuspend() routines in the runtime PM
framework (recently introduced by Alan Stern) that allow you to use delay
timers and deal with them automatically (as described in
Documentation/power/runtime_pm.txt, Section 9).

Is that what you mean?

Rafael