RE: [PATCHv4 1/5] misc: Driver for bh1770glc / sfh7770 ALS andproximity sensor

From: samu.p.onkalo
Date: Wed Oct 27 2010 - 03:42:42 EST


Hi

>-----Original Message-----
>From: linux-i2c-owner@xxxxxxxxxxxxxxx [mailto:linux-i2c-
>owner@xxxxxxxxxxxxxxx] On Behalf Of ext Linus Walleij
>Sent: 26 October, 2010 17:48
>To: Onkalo Samu.P (Nokia-MS/Tampere)
>Cc: akpm@xxxxxxxxxxxxxxxxxxxx; linux-i2c@xxxxxxxxxxxxxxx; linux-
>kernel@xxxxxxxxxxxxxxx; linux-input@xxxxxxxxxxxxxxx
>Subject: Re: [PATCHv4 1/5] misc: Driver for bh1770glc / sfh7770 ALS and
>proximity sensor
>
>010/10/19 Samu Onkalo <samu.p.onkalo@xxxxxxxxx>:
>
>> This is a driver for ROHM BH1770GLC and OSRAM SFH7770 combined
>> ALS and proximity sensor.
>>
>> Interface is sysfs based. The driver uses interrupts to provide new
>data.
>> The driver supports pm_runtime and regulator frameworks.
>> (...)
>> +static DEVICE_ATTR(prox0_raw_en, S_IRUGO | S_IWUSR,
>bh1770_prox_enable_show,
>> +
>bh1770_prox_enable_store);
>> +static DEVICE_ATTR(prox0_thresh_above1_value, S_IRUGO | S_IWUSR,
>> +
>bh1770_prox_abs_thres_show,
>> +
>bh1770_prox_abs_thres_store);
>> +static DEVICE_ATTR(prox0_thresh_above0_value, S_IRUGO | S_IWUSR,
>> +                                               bh1770_get_prox_thres,
>> +
>bh1770_set_prox_thres);
>> +static DEVICE_ATTR(prox0_raw, S_IRUGO, bh1770_prox_result_show,
>NULL);
>
>So you have sysfs entries for enabling, calibrating hysteris
>(above/below) and the reading the raw value which I assume
>will be 0 (if nothing is in proximity) or 1 (if it is in proximity).

Actually raw gives 0 or 1023 (==sensor_range) when
the reporting mode is "trigger"
or
0 threshold_abovevalue..1023 in periodic mode.

But for Boolean type behavior: 0 is no proximity and != 0 means
proximity

>
>These entries are pretty OK I think, but the transition from
>0 to 1 which I assume will generate an interrupt and generate
>a new value in this attribute.

It uses sysfs_notify to indicate userspace about the change

>
>But should it not hook into the input framework and generate
>a SW_FRONT_PROXIMITY event as well?
>
>I think this could be pretty helpful for generic userspace
>applications like X that want to use this event.
>
>Of course I can send a patch for this later, but I'd like
>to hear whether you agree on this or not.
>

I think that is makes sense to provide it.

-Samu




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/