Re: [PATCH V4 2/4] dt-bindings: iio: adc: Add support for QCOM PMIC5 Gen3 ADC

[Jishnu Prakash <quic_jprakash@quicinc.com>]

Hi Dmitry,

On 11/15/2024 10:14 PM, Dmitry Baryshkov wrote:
> On Wed, Nov 13, 2024 at 07:36:13PM +0530, Jishnu Prakash wrote:
>> Hi Dmitry,
>>
>> On 10/31/2024 11:27 PM, Dmitry Baryshkov wrote:
>>> On Thu, Oct 31, 2024 at 12:28:52AM +0530, Jishnu Prakash wrote:
>>>> For the PMIC5-Gen3 type PMICs, ADC peripheral is present in HW for the
>>>> following PMICs: PMK8550, PM8550, PM8550B and PM8550VX PMICs.
>>>>
>>>> It is similar to PMIC5-Gen2, with SW communication to ADCs on all PMICs
>>>> going through PBS(Programmable Boot Sequence) firmware through a single
>>>> register interface. This interface is implemented on an SDAM (Shared
>>>> Direct Access Memory) peripheral on the master PMIC PMK8550 rather
>>>> than a dedicated ADC peripheral.
>>>>
>>>> Add documentation for PMIC5 Gen3 ADC and macro definitions for ADC
>>>> channels and virtual channels (combination of ADC channel number and
>>>> PMIC SID number) per PMIC, to be used by clients of this device.
>>>>
>>>> Co-developed-by: Anjelique Melendez <quic_amelende@quicinc.com>
>>>> Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
>>>> Signed-off-by: Jishnu Prakash <quic_jprakash@quicinc.com>
>>>> ---
>>>> Changes since v3:
>>>> - Added ADC5 Gen3 documentation changes in existing qcom,spmi-vadc.yaml file
>>>>   instead of adding separate file and updated top-level constraints in documentation
>>>>   file based on discussion with reviewers.
>>>
>>> I think it has been better, when it was a separate file. Krzysztof asked
>>> for rationale, not for merging it back. Two different things.
>>
>> Actually I made that change in a separate file due to a misunderstanding at that time - 
>> I thought a separate file was the only way to accommodate a change in the top-level 'reg' and 'interrupts'
>> constraints, but I realized later that they could be updated.
>>
>> From our side, we would prefer to add ADC5 Gen3 documentation in the same file, as it is
>> mostly the same functionality which reuses all the existing properties present in this file.
> 
> Export the existing properties and reuse them in the new file. Gen3 (in
> my opinion) changed the hardware too much. Having all the differences
> via conditionals bloats the schema and makes it significantly unreadable
> in my opinion.

I can do something like this - Krzysztof mentioned in my V3 documentation change that I should put duplicated properties in a common schema, so
I'm thinking of adding a new file named “qcom,spmi-vadc-common.yaml”, which would hold the common properties. This can be used as
a reference in this existing file (qcom,spmi-vadc.yaml) as well as in the new file I will add for Gen3 ADC(qcom,spmi-adc5-gen3.yaml).


> 
> But please refer to DT maintainers (Rob/Krzysztof/Conor) for the final
> opinion.
> 

Rob/Krzysztof/Conor - please let me know if you have any objections to the change mentioned above.
If there's no issue, I'll do this in the next patch series.


Thanks,
Jishnu