On Thu, 14 Nov 2024 23:16:51 +0800Hi Jonathan,
Yasin Lee <yasin.lee.x@xxxxxxxxx> wrote:
On 10/20/24 21:06, Jonathan Cameron wrote:Whilst I agree that a typical user may well not modify these settings
On Thu, 17 Oct 2024 18:36:44 +0800Hi Jonathan,
Yasin Lee <yasin.lee.x@xxxxxxxxx> wrote:
When hardware design introduces significant sensor data noise,Questions inline. Mostly around why these controls belong in DT.
performance can be improved by adjusting register settings.
What do they have to do with hardware / wiring etc rather than being
appropriate for userspace controls.
So almost all are definite no to being suitable for device tree bindings.
Jonathan
Thank you for the suggestions in your recent email. Following your
advice, I discussed these configurations in detail with engineers from
the HX9023S supplier. Based on their feedback, these settings are not
intended to be exposed to end-users. Typically, these configurations are
adjusted during the DVT phase of the end product by the supplier to
optimize performance, after which they are finalized and not meant to be
modified dynamically at the user level.
Given this approach, it seems more appropriate to provide these settings
as part of a firmware file, allowing the configuration to be kept
internal and managed without user-level access. If this approach aligns
with your thoughts, I can prepare and submit a new patch focused on
firmware parsing and handling for these configurations.
that doesn't necessarily make them suitable for control from the
Device Tree. Some may be but settings like ODR are about use case
not physical hardware. Average and OSR are normally a question of
trading off noise against data rate - that's policy not a fundamental
characteristic of the hardware. Filter controls are similar.
For other such as Dither, there may hardware configurations where it
doesn't need to be turned, only but does it do any harm? I'd be
somewhat surprised if the right thing to do there isn't to just hard
code it to turned on.
The enabling of dataready interrupt is entirely down to how the
device is being used, not the platform.
If these devices are being used in embedded platforms for a specific
purpose, then a simple udev rule or similar can configure the
defaults whilst still allowing them to be easily tweaked.
If you are dealing with standardized software it will already understand
many of the userspace ABI calls and have appropriate configuration files.
That is the appropriate level for such control, not device
tree.
If you have a strong case why a setting is never a policy decision
but rather a hard characteristic of the system, then that one may
be appropriate for DT. Examples of this in the past have been things
like output voltage ranges for DACs because the hardware beyond
this device may only cope with some settings.
Jonathan
Thank you again for your valuable guidance, and I look forward to your
feedback.
Best regards,
Yasin Lee