* Re: Accelerometer drivers in drivers/hwmon
2010-10-04 18:03 ` Dmitry Torokhov
@ 2010-10-05 10:16 ` Jonathan Cameron
0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Cameron @ 2010-10-05 10:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jean Delvare, linux-input, LM Sensors, Takashi Iwai,
linux-iio@vger.kernel.org, Eric Piel, Frank Seidel
Hi all,
I've cc'd a few more relevant people and linux-iio as the below
attribute discussion may result in minor changes there.
> Hi Jean,
>
> On Sat, Sep 25, 2010 at 01:23:30PM +0200, Jean Delvare wrote:
>> Hi Dmitry,
>>
>> I would like to kick the following 5 drivers out of drivers/hwmon: ams,
>> hdaps, hp_accel, lis3lv02d and applesmc. These are primarily
>> accelerometer devices, so the drivers do not belong to hwmon.
>>
>> ams, hdaps, hp_accel and lis3lv02d don't even register a hwmon device.
>> They are pure accelerometer drivers as far as I can see. Would you take
>> them in drivers/input/misc?
>>
>> applesmc is more complex, it's a multifunction device. Maybe it would
>> better go to drivers/macintosh, where the other thermal management
>> drivers for mac machines live.
>>
>> If you don't want hdaps and hp_accel, they might also fit under
>> drivers/platform/x86. There are quite a few laptop-specific drivers
>> living there already.
>>
>> If nobody wants these drivers, drivers/misc is yet another option. I'm
>> open to suggestions. Virtually anything which moves these drivers
>> outside of drivers/hwmon will make me happy.
>>
>
> I looked over the drivers and none of them (with possible exception of
> lis3lv02d) are pure input devices either. I think the best course of
> action would be to move ams, applesmc, hdaps and hp_accel into
> drivers/*/platform (I'd say drivers/x86/platform except that I think
> apple one might not be x86 only).
>
> lis3lv02d could ether go into drivers/misc or stay where it is for the
> time being, pending resolution on overall IIO/Input/accelerometers
> decision. I'd take it in input/misc but accelerometer guys need to
> decide on common sysfs layout for such devices.
Actually not so much a problem for that driver seeing as it provides very
few sysfs interfaces... Lets take a quick look at what is there and see
if we can resolve this question nice and quickly.
selftest - device specific so consistency doesn't matter - and it's a perfectly
good name anyway!
position - (I suspect this is a somewhat misleading name)
I could be wrong but I doubt anyone is using this interface for
cases where they care if they get a consistent set of readings,
I'd advocate splitting that one up into three separate attributes.
Whilst a single attribute is just fine if you know exactly what the
device you are using is, it really doesn't generalize well to devices
that aren't 3d accelerometers or have addition sensor types.
We can quite happily maintain the 'position' interface as well though
for compatibility reasons. I'd just add, accel_x_input, accel_y_input
and accel_z_input.
rate - here we have a subtle and largerly irrelevant difference.
IIO uses sampling_frequency but rate is just as valid. We just came
from a more data capture terminology whereas I guess rate is more common
when considering data streams? If I'm playing devil's advocate I guess
rate might imply a data rate and hence people might interpret it as being
in bytes per second. Then again I'm sure sampling_frequency can also be
misinterpreted!
This is a large complex driver which is definitely in input in a sense (even if
it is located elsewhere in the tree). Until someone is using one of these parts
in a circumstance where they need the other bits of IIO it doesn't to my mind
make sense to do a complete rewrite. There are a lot of bells and whistles in
here that we would need to support that aren't even vaguely of interest for
things other than input usage. These are very much input oriented devices
(supporting things like 'click' detection. Hence I'd encourage you to pick
this one up for input. The misc option is fine with me as well.
Jonathan
^ permalink raw reply [flat|nested] 3+ messages in thread