Control Register device tree binding request for Opt3001

Control Register device tree binding request for Opt3001

[Ekin Böke]

Hi,

We are using Opt3001 for a day light control system and according to the data sheet it has 2 conversion time modes
that are 100 ms(CT=0) and 800 ms(CT=1) . Configuration register field CT controls the conversion time and we want to set the CT parameter at the initialization to 0 at all times. We could do it by using the in_illuminance_integration_time sysfs node at the runtime.

Should we add a parameter to the device tree bindings or is there another way to set the CT parameter at the initialization?


Best Regards

Ekin



Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence.

Re: Control Register device tree binding request for Opt3001

[Matt Ranostay]

On Wed, Feb 17, 2021 at 9:20 PM Ekin Böke <ekin_boke@arcelik.com> wrote:
>
> Hi,
>
> We are using Opt3001 for a day light control system and according to the data sheet it has 2 conversion time modes
> that are 100 ms(CT=0) and 800 ms(CT=1) . Configuration register field CT controls the conversion time and we want to set the CT parameter at the initialization to 0 at all times. We could do it by using the in_illuminance_integration_time sysfs node at the runtime.
>
> Should we add a parameter to the device tree bindings or is there another way to set the CT parameter at the initialization?
>

Yes, it would make sense to have that in the device tree if it isn't
going to be switched on runtime. However if it is supposed to be
configured at runtime you could have a) devicetree + sysfs
configuration b) or just sysfs if timing isn't important.

Although devicetree configuration if *optional* probably wouldn't
hurt. I'm sure Jonathan will have a comment either way :)

>
> Best Regards
>
> Ekin
>
>
>

Just a slight pedantic note that some people won't respond to some
emails on kernel mailing lists due to the following message (corporate
legal departments and such).

- Matt

> Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence.

Re: Control Register device tree binding request for Opt3001

[Alexandru Ardelean]

On Thu, Feb 18, 2021 at 7:27 AM Ekin Böke <ekin_boke@arcelik.com> wrote:
>
> Hi,
>
> We are using Opt3001 for a day light control system and according to the data sheet it has 2 conversion time modes
> that are 100 ms(CT=0) and 800 ms(CT=1) . Configuration register field CT controls the conversion time and we want to set the CT parameter at the initialization to 0 at all times. We could do it by using the in_illuminance_integration_time sysfs node at the runtime.
>
> Should we add a parameter to the device tree bindings or is there another way to set the CT parameter at the initialization?

It's usually a good idea to use the sysfs attribute, if it's already available.
Maybe during system boot-up, you can add some service init call to
initialize to 100 ms or right before starting to read data from the
sensor.

For kernel people, these initialization device-tree attributes seem convenient.
But in this case, CT is a parameter of the chip and not a hard-wired
configuration of the board [which needs to be described in DT].

>
>
> Best Regards
>
> Ekin
>
>
>
> Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence.

Re: Control Register device tree binding request for Opt3001

[Jonathan Cameron]

On Thu, 18 Feb 2021 10:35:27 +0200
Alexandru Ardelean <ardeleanalex@gmail.com> wrote:

> On Thu, Feb 18, 2021 at 7:27 AM Ekin Böke <ekin_boke@arcelik.com> wrote:
> >
> > Hi,
> >
> > We are using Opt3001 for a day light control system and according to the data sheet it has 2 conversion time modes
> > that are 100 ms(CT=0) and 800 ms(CT=1) . Configuration register field CT controls the conversion time and we want to set the CT parameter at the initialization to 0 at all times. We could do it by using the in_illuminance_integration_time sysfs node at the runtime.
> >
> > Should we add a parameter to the device tree bindings or is there another way to set the CT parameter at the initialization?  
> 
> It's usually a good idea to use the sysfs attribute, if it's already available.
> Maybe during system boot-up, you can add some service init call to
> initialize to 100 ms or right before starting to read data from the
> sensor.
> 
> For kernel people, these initialization device-tree attributes seem convenient.
> But in this case, CT is a parameter of the chip and not a hard-wired
> configuration of the board [which needs to be described in DT].

As described, what you want to control here is policy, not a characteristic
of the hardware.   Normally we don't use DT to make such decisions, as it should
be controlled at runtime.

So basically what Alex said :)

Jonathan

> 
> >
> >
> > Best Regards
> >
> > Ekin
> >
> >
> >
> > Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and fr
 om opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence.  

Re: Control Register device tree binding request for Opt3001

[Cengiz Can]

Hello Jonathan, Alexandru and Ekin

On 2021-02-18 15:15, Jonathan Cameron wrote:
> 
> As described, what you want to control here is policy, not a 
> characteristic
> of the hardware.   Normally we don't use DT to make such decisions, as 
> it should
> be controlled at runtime.

I'm by no means an expert on sensors and I don't fully understand the 
distinction
of policy vs characteristic in this context.

Can you clarify a bit?

For example, many TFT drivers allow maximum-minimum brightness values in 
devicetree
and even set a default brightness value. Totally within the specs of 
vendor of course.

Since this is just a hardware register that can be changed, and possibly 
never to be
modified (depending on the use case of course) during runtime, I would 
like to be able
to set it once during initialization and forget about it.

Currently I have a oneshot systemd unit that echo's my desired 
integration value and
I think that's a bit late for my application. (even with all the 
priority and orderings set).

> 
> So basically what Alex said :)
> 
> Jonathan
> 

Thank you

-- 
Cengiz Can
@cengiz_io

Re: Control Register device tree binding request for Opt3001

[Jonathan Cameron]

On Thu, 18 Feb 2021 15:38:15 +0300
Cengiz Can <cengiz@kernel.wtf> wrote:

> Hello Jonathan, Alexandru and Ekin
> 
> On 2021-02-18 15:15, Jonathan Cameron wrote:
> > 
> > As described, what you want to control here is policy, not a 
> > characteristic
> > of the hardware.   Normally we don't use DT to make such decisions, as 
> > it should
> > be controlled at runtime.  
> 
> I'm by no means an expert on sensors and I don't fully understand the 
> distinction
> of policy vs characteristic in this context.
> 
> Can you clarify a bit?

It's a slightly blurred boundary, but to give some examples:

Characterstics - dependent on device, not where the device is
being used and mostly even what it is being used for.
- Wiring things - power supplies etc.
- Voltage limits etc (stuff that can damage hardware).
- Calibration parameter reflecting thing like plastic on top of a sensor.
- Proximity limits on devices intended to detect if a person is
  near enough to a wifi antenna that we should reduce the power output.
  (this one is an edge condition as it is assuming a 'usecase' but it
   the value is based on the physical device).

Policy - stuff dependent on what sensor is being used for at a particular
point in time.
* Sensitivity levels / integration times etc - if you are in a dark environment
  then these would ideally be set different to an outdoor usecase. Same device
  may well move between these places.
* Thresholds that aren't a 'physical thing'.  So stuff you'd expect to have
  a userspace control for.

> 
> For example, many TFT drivers allow maximum-minimum brightness values in 
> devicetree
> and even set a default brightness value. Totally within the specs of 
> vendor of course.

I'd guess they would have some connection to what actually makes sense
for a given physical device incorporating the TFT?  Perhaps above the
max brightness screen always unreadable under all lighting conditions.

Also note that for DT bindings a lot of stuff was added back before there
was particularly good review or tight control of what was acceptable and
what was not.  As we have to support bindings that are already in
the field, we can't rip that stuff out.  We can avoid adding more though.

> 
> Since this is just a hardware register that can be changed, and possibly 
> never to be
> modified (depending on the use case of course) during runtime, I would 
> like to be able
> to set it once during initialization and forget about it.

It's that question of usecase.  There may well be devices that are only
ever used outside for example and hence need only one of the settings, but
it definitely isn't a common situation.

Whilst the amount of code needed to support this is small, there is
still a maintenance burden and a userspace script should be sufficient.

> 
> Currently I have a oneshot systemd unit that echo's my desired 
> integration value and
> I think that's a bit late for my application. (even with all the 
> priority and orderings set).

I'm not sure I understand how doing it in systemd is too late?
It should be possible to ensure that it happens early enough
to support any userspace application.

Jonathan

> 
> > 
> > So basically what Alex said :)
> > 
> > Jonathan
> >   
> 
> Thank you
>