Re: [PATCH 1/1] misc: bh1770glc: Driver for bh1770glc combined als and ps sensor

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Onkalo Samu
Date: Thursday, April 15, 2010 - 11:24 pm

Thanks for review and comments.

On Thu, 2010-04-15 at 14:14 +0200, ext Jonathan Cameron wrote:

I'm sorry, but I cannot promise data sheet right now.


I'll add some documentation under Documentation/misc-devices.
It makes sense to modify sysfs interface to one value per file.


Chip consist of two separate analog measurement paths. One for IR light
and one for clear light. IR part is driving up to 3 IR leds. IR
measurement part measures reflection from each of the IR led. IR leds 
are driver using short pulses and measurement is synchronized to the
pulses.

Both analog paths shares same digital control part. They share same
interrupt logic and I2C bus. Part of registers are common for both and
part of the registers are dedicated to PS or ALS.


mfd could make sense. I need to check this.


True


Chip operating state is controlled based on /dev/bh* device handle
state. If those are not open, chip is not running. I think that it is
not possible to get information when some sysfs entry is used.

Perhaps every read could start the chip and keeps it running for a
while. So, sysfs based use requires regular polling to keep chip
measuring. Or there should be a way to force chip on (perhaps via mode
entries).


Chip itself measures all the time when it is enabled. Setting of
thresholds to the same values trigs an interrupt after the next
measurement period. So, this doesn't really trig a measurement, but
requests chip to inform about the new result.


True. Code after the release_lock is added after the selection of the
label name and the label is little bit out of the date.


I will add to the documentation


of course :)


Interrupt control register is shared one. Als state is just read from 
status variables instead of I2C read-modify-write operation.


Proximity part can trig interrupt only when level is above treshold.
Interrupts are coming periodically as long as the level is high enough.
Work is trigged to happen little bit after the next measrement. Work is
simply cancelledin the interrupt handler. If the interrupt is not
trigged, driver knows that latest measurement was below threshold.
Driver infors userspace and restores chip to faster measurement mode.

Driver configures chip to use faster rate when there is no proximity
event active to allow faster reactions to the proximity event. When 
measurements are above threshold slower rate is configured to reduce 
interrupt load and unnecessary system wakeups. Both slow and fast rates 
can be controller via sysfs and they can be same. 


See explanation above. I'll document these and add separate sysfs
entries.

 hmm. perhaps some numbering would be needed


--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 1/1] misc: bh1770glc: Driver for bh1770glc comb ..., Onkalo Samu, (Thu Apr 15, 11:24 pm)