Tejun Heo <tj@kernel.org> wrote:
quoted text
> Hello, Shem Multinymous.
>
> Shem Multinymous wrote:
[...]
quoted text
>>> 2. If we're gonna unify interface, how much can we unify the backend?
>>>   Some devices are based on polling, others interrupt.  For polling,
>>>   is it better to delegate the whole polling to userland or is it
>>>   better to do some of it in kernel (tp_smapi seems to be doing
>>>   this)?
>> 
>> The ThinkPad accelerometer needs to be polled at very regular
>> intervals (max jitter on the order of 10ms), which sounds like a job
>> for the kernel.
>
> Yes, I agree.
>
>> This is because in ThinkPads we actually have a 4-level pile:
>> [hdapsd userspace] -> [hdaps kernel] -> [embedded controller] ->
>> [accelerometer A2D]
>> What the kernel polls is actually is the H8S embedded controller (EC)
>> chip, which in turn does its own polling of the accelerometer A2D.
>> Now, the EC has a tiny buffer and strange buffering semantics, and it
>> has its own internal clock, so the software->EC polling should be very
>> regular to minmize EC buffer overflows/underruns.
>
> So, I think the whole polling should be implemented inside the kernel
> and the kernel should notify userland when new data is available,
> which is about what the current joystick implementation does and can
> be achieved using sysfs_notify_event().

Short of a satisfying proposition regarding the questions raised, I just
want to add two things that would be nice to solve in the future one way
or another and should perhaps be taken into consideration from the
beginning:

1. Disable polling completely when it isn't required: once the hd has
   spun down, there is no need to keep polling the sensors at all. Only
   when the first request requiring the hd to spin up arrives, the
   kernel needs to hold back for a short while to gather enough data
   from the sensors, so shock protection is up and running again.
2. Make shock protection interact nicely with suspend operations:
   currently, we are out of luck if anything should happen after
   processes have been frozen. This is particularly unfortunatel in the
   case of s2disk.

As far as 1. is concerned, I'm not quite sure yet how to determine when
the disk has spun down since this may have happened according to vendor
specific timing rules. Once we have established that the disk is
sleeping safe and sound, sensor drivers can be notified to stop polling
the hardware and possibly notify clients (like hdapsd) about that fact.

Something along the lines of the disk_shock module approach suggested by
Bart in [1] sounds promising, but it still needs some careful thinking
when designing the interfaces to all components involved. As for the
suspend problem, we could either put some simplified logic into
disk_shock so it can take over once hdapsd has been frozen, or we can
find a way to keep hdapsd unfrozen until the hd has been put to sleep.
Of course, we'd have to think about resume as well, although it'll be
impossible to protect right from the start in the s2disk case.

Regards,

Elias

[1] http://marc.info/?l=linux-kernel&m=122021163324843&w=2
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/