mbox series

[RFC,0/2] Support for Avago APDS9306 Ambient Light Sensor

Message ID 20230411011203.5013-1-subhajit.ghosh@tweaklogic.com (mailing list archive)
Headers show
Series Support for Avago APDS9306 Ambient Light Sensor | expand

Message

Subhajit Ghosh April 11, 2023, 1:12 a.m. UTC
This series adds support for Avago (Broadcom) APDS9306 Ambient Light
Sensor.

Datasheet: https://docs.broadcom.com/doc/AV02-4755EN

Following features are supported:
- I2C interface
- 2 channels - als and clear
- Up to 20 bit resolution
- 20 bit data register for each channel
- Common Configurable items for both channels
    - Integration Time
    - Measurement Frequency
    - Scale
- High and Low threshold interrupts for each channel

- Selection of interrupt channel - als or clear
- Selection of interrupt mode - threshold or adaptive
- Level selection for adaptive threshold interrupts
- Persistence (Period) level selection for interrupts

Signed-off-by: Subhajit Ghosh <subhajit.ghosh@tweaklogic.com>

Subhajit Ghosh (2):
  dt-bindings: Document APDS9306 Light Sensor bindings
  iio: light: Add support for APDS9306 Light Sensor

 .../bindings/iio/light/avago,apds9306.yaml    |   47 +
 drivers/iio/light/Kconfig                     |   11 +
 drivers/iio/light/Makefile                    |    1 +
 drivers/iio/light/apds9306.c                  | 1146 +++++++++++++++++
 4 files changed, 1205 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/avago,apds9306.yaml
 create mode 100644 drivers/iio/light/apds9306.c


base-commit: 0d3eb744aed40ffce820cded61d7eac515199165

Comments

Jonathan Cameron April 11, 2023, 1:40 p.m. UTC | #1
On Tue, 11 Apr 2023 09:12:01 +0800
Subhajit Ghosh <subhajit.ghosh@tweaklogic.com> wrote:

> This series adds support for Avago (Broadcom) APDS9306 Ambient Light
> Sensor.
> 
> Datasheet: https://docs.broadcom.com/doc/AV02-4755EN
> 
> Following features are supported:
> - I2C interface
> - 2 channels - als and clear
> - Up to 20 bit resolution
> - 20 bit data register for each channel
> - Common Configurable items for both channels
>     - Integration Time
>     - Measurement Frequency
>     - Scale
> - High and Low threshold interrupts for each channel
> 
> - Selection of interrupt channel - als or clear
> - Selection of interrupt mode - threshold or adaptive
> - Level selection for adaptive threshold interrupts
> - Persistence (Period) level selection for interrupts
> 
> Signed-off-by: Subhajit Ghosh <subhajit.ghosh@tweaklogic.com>
Hi Subhajit,

No need to sign off a cover letter.  The content isn't captured in the
git tree anyway.

For an RFC, I'd expect to see a clear statement in the cover letter of
why it is an RFC rather than a formal patch submission.  What specifically
are you looking for comments on?

Point us in the right direction and we might answer the questions quicker.

Thanks,

Jonathan

> 
> Subhajit Ghosh (2):
>   dt-bindings: Document APDS9306 Light Sensor bindings
>   iio: light: Add support for APDS9306 Light Sensor
> 
>  .../bindings/iio/light/avago,apds9306.yaml    |   47 +
>  drivers/iio/light/Kconfig                     |   11 +
>  drivers/iio/light/Makefile                    |    1 +
>  drivers/iio/light/apds9306.c                  | 1146 +++++++++++++++++
>  4 files changed, 1205 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/avago,apds9306.yaml
>  create mode 100644 drivers/iio/light/apds9306.c
> 
> 
> base-commit: 0d3eb744aed40ffce820cded61d7eac515199165
Subhajit Ghosh April 12, 2023, 4:46 a.m. UTC | #2
Hi Jonathan,
Thank you for getting back.

> Hi Subhajit,
> 
> No need to sign off a cover letter.  The content isn't captured in the
> git tree anyway.
> 
> For an RFC, I'd expect to see a clear statement in the cover letter of
> why it is an RFC rather than a formal patch submission.  What specifically
> are you looking for comments on?
> 
> Point us in the right direction and we might answer the questions quicker.
> 
> Thanks,
> 
> Jonathan
Thank you for clearing it up.
Next version of RFC I will put specific reasons.
Before submitting a formal patch I wanted to check if my implementation of
single reads of ALS data raw values from userspace when interrupts are
enabled is the right thing to do or not. Also wanted to check if my event
related userspace ABI implementation is in line with IIO subsystem.
I will put it into better words in the next cover letter.

Can you also help me out with the git tree I should use to format the
patches? As per my understanding it is the subsystem maintainer tree
and the main branch but the macros and functions which you have suggested
in other reviews are available in Linux mainline.

Regards,
Subhajit Ghosh
Jonathan Cameron April 12, 2023, 8:44 p.m. UTC | #3
On Wed, 12 Apr 2023 12:46:49 +0800
Subhajit Ghosh <subhajit.ghosh@tweaklogic.com> wrote:

> Hi Jonathan,
> Thank you for getting back.
> 
> > Hi Subhajit,
> > 
> > No need to sign off a cover letter.  The content isn't captured in the
> > git tree anyway.
> > 
> > For an RFC, I'd expect to see a clear statement in the cover letter of
> > why it is an RFC rather than a formal patch submission.  What specifically
> > are you looking for comments on?
> > 
> > Point us in the right direction and we might answer the questions quicker.
> > 
> > Thanks,
> > 
> > Jonathan  
> Thank you for clearing it up.
> Next version of RFC I will put specific reasons.
> Before submitting a formal patch I wanted to check if my implementation of
> single reads of ALS data raw values from userspace when interrupts are
> enabled is the right thing to do or not. Also wanted to check if my event
> related userspace ABI implementation is in line with IIO subsystem.
> I will put it into better words in the next cover letter.
> 
> Can you also help me out with the git tree I should use to format the
> patches? As per my understanding it is the subsystem maintainer tree
> and the main branch but the macros and functions which you have suggested
> in other reviews are available in Linux mainline.

For a new driver it rarely matters and I'd advise simply using
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
which is the mainline tree.  Please base either on the previous
release (currently 6.2) or rc1 of the current release (v6.3-rc1)
if doing this.

If you need a feature that has only been applied in the same cycle, or
are building on recent work that has been applied to the iio tree then
for fixes you want:
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git fixes-togreg
for new stuff you want:
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg

The IIO tree routes through Greg KH's char-misc tree so will see the togreg
branch move forwards to be based on that as Greg takes pull requests from me.
Usually this happens once or twice a kernel cycle.  Don't worry too much about
this. If it should affect a patch because some changes crossed I'll generally
fix it up whilst applying whichever gets applied second and ask the
authors to check I didn't make a mistake.

Joanthan
> 
> Regards,
> Subhajit Ghosh
>
Subhajit Ghosh April 13, 2023, 3:14 a.m. UTC | #4
>> Can you also help me out with the git tree I should use to format the
>> patches? As per my understanding it is the subsystem maintainer tree
>> and the main branch but the macros and functions which you have suggested
>> in other reviews are available in Linux mainline.
> 
> For a new driver it rarely matters and I'd advise simply using
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> which is the mainline tree.  Please base either on the previous
> release (currently 6.2) or rc1 of the current release (v6.3-rc1)
> if doing this.
> 
> If you need a feature that has only been applied in the same cycle, or
> are building on recent work that has been applied to the iio tree then
> for fixes you want:
> https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git fixes-togreg
> for new stuff you want:
> https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
> 
> The IIO tree routes through Greg KH's char-misc tree so will see the togreg
> branch move forwards to be based on that as Greg takes pull requests from me.
> Usually this happens once or twice a kernel cycle.  Don't worry too much about
> this. If it should affect a patch because some changes crossed I'll generally
> fix it up whilst applying whichever gets applied second and ask the
> authors to check I didn't make a mistake.
> 
> Joanthan
>>
>> Regards,
>> Subhajit Ghosh
>>
> 
Thank you for the detailed information. Appreciate you help.

Regards,
Subhajit Ghosh