Message-ID: <ea141f1f-b0b0-4bcd-ac30-8ee533860f5d@gmail.com>
Date: Tue, 26 Nov 2024 16:40:32 +0800
From: Yasin Lee <yasin.lee.x@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, yasin.lee.x@...look.com, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: iio: tyhx,hx9023s: Add performance
 tuning configuration


On 11/23/24 21:21, Jonathan Cameron wrote:
> On Thu, 14 Nov 2024 23:16:51 +0800
> Yasin Lee <yasin.lee.x@...il.com> wrote:
>
>> On 10/20/24 21:06, Jonathan Cameron wrote:
>>> On Thu, 17 Oct 2024 18:36:44 +0800
>>> Yasin Lee <yasin.lee.x@...il.com> wrote:
>>>   
>>>> When hardware design introduces significant sensor data noise,
>>>> performance can be improved by adjusting register settings.
>>> Questions inline. Mostly around why these controls belong in DT.
>>> 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
>>>   
>> Hi 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.
> Whilst I agree that a typical user may well not modify these settings
> 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
>
Hi Jonathan,

Thank you for your detailed explanation and insights. I fully agree with 
your point that settings such as ODR, Average, OSR, and filter-related 
configurations, being policy-driven, should not be included in the 
Device Tree.

As you mentioned, the dither setting is typically left disabled in most 
cases. This device is indeed used for specific purposes in embedded 
platforms, and there is no requirement for runtime flexibility in 
adjusting these configurations.

Given this, I have decided to drop this submission. Moving forward, I 
plan to address varying hardware requirements by adapting these 
configurations using a firmware-based approach.

Thank you again for your guidance and support!

Best regards,
Yasin Lee
>
>> Thank you again for your valuable guidance, and I look forward to your
>> feedback.
>>
>> Best regards,
>> Yasin Lee
>>
>>

Powered by blists - more mailing lists