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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Krzysztof,

On 11/19/2024 2:32 PM, Krzysztof Kozlowski wrote:
> On 13/11/2024 15:05, Jishnu Prakash wrote:
>> Hi Krzysztof,
>>
>> On 10/31/2024 4:28 PM, Krzysztof Kozlowski wrote:
>>> On 30/10/2024 19:58, 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@xxxxxxxxxxx>
>>>> Signed-off-by: Anjelique Melendez <quic_amelende@xxxxxxxxxxx>
>>>> Signed-off-by: Jishnu Prakash <quic_jprakash@xxxxxxxxxxx>
>>>> ---
>>>
>>> This has still test failures, so limited review follows.
>>>
>>>>  properties:
>>>>    compatible:
>>>> @@ -23,14 +27,20 @@ properties:
>>>>            - const: qcom,pms405-adc
>>>>            - const: qcom,spmi-adc-rev2
>>>>        - enum:
>>>> -          - qcom,spmi-vadc
>>>> -          - qcom,spmi-adc5
>>>>            - qcom,spmi-adc-rev2
>>>> +          - qcom,spmi-adc5
>>>> +          - qcom,spmi-adc5-gen3
>>>>            - qcom,spmi-adc7
>>>> +          - qcom,spmi-vadc
>>>>  
>>>>    reg:
>>>> -    description: VADC base address in the SPMI PMIC register map
>>>> -    maxItems: 1
>>>> +    description:
>>>> +      For compatible properties "qcom,spmi-vadc", "qcom,spmi-adc5", "qcom,spmi-adc-rev2"
>>>> +      and "qcom,spmi-adc7", reg is the VADC base address in the SPMI PMIC register map.
>>>> +      For compatible property "qcom,spmi-adc5-gen3", each reg corresponds to an SDAM
>>>> +      peripheral base address that is being used for ADC functionality.
>>>
>>> This description is not really needed. You need to provide constraints
>>> in schema.

...

>>>>        qcom,hw-settle-time:
>>>> @@ -135,9 +153,24 @@ patternProperties:
>>>>              from the ADC that is an average of multiple samples. The value
>>>>              selected is 2^(value).
>>>>  
>>>> +      qcom,adc-tm:
>>>> +        description:
>>>> +          Indicates if ADC_TM monitoring is done on this channel.
>>>
>>> What is "ADC_TM"? Why this would be property of a board? This does not
>>> look like suitable for DT, at least based on such very vague explanation.
>>>
>>>> +          Defined for compatible property "qcom,spmi-adc5-gen3".
>>>
>>> Drop redundant.
>>>
>>>> +          This is the same functionality as in the existing QCOM ADC_TM
>>>> +          device, documented at devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml.
>>>
>>> What does it mean? How property can represent functionality of entire
>>> binding?
>>>
>>> BTW, use full paths when refering to files.
>>>
>>
>> To address all your above questions for ADC_TM:
>>
>> The file "Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml" describes
>> the Qualcomm ADC thermal monitoring device, which existed as a separate device on older
>> PMIC generations. ADC_TM refers to this functionality.
>>
>> In ADC5 Gen3, ADC_TM functionality is combined with the existing ADC read functionality
>> described in this file, under a single device.
>>
>> In the earlier ADC_TM DT nodes, each child node would describe one of the IIO ADC channels being
>> monitored by ADC_TM HW. In this ADC5 Gen3 device, setting the property 'qcom,adc-tm' for a channel
>> node means that it will also be monitored in HW exactly like an ADC_TM channel.
>>
>> It can be considered a hardware property as the monitoring is done by a sequence under
>> PBS (Programmable Boot Sequence, can be considered firmware), which periodically gets the
>> channel reading and checks it against upper/lower thresholds set by clients of this driver, 
>> for threshold violations.
> 
> So you want to configure channels in different way? Then specify it
> precisely - what is the nature of this feature/configuration. I have no
> clue what is ADC TM and you keep using it over and over.
> 

Yes, it is a different channel configuration, I'll update the explanation in the next patch.

For now, to explain the ADC_TM functionality:

ADC_TM is a *threshold monitoring* feature in HW which can be enabled on *any* ADC channel, to trigger an IRQ for threshold violation.
It was implemented in a separate device earlier, for which we had a separate ADC_TM driver.

In Gen3, this feature can be enabled in the same ADC device for any channel and threshold monitoring/IRQ triggering is handled in FW (PBS)
instead of having another dedicated HW block (old design).


> I still wait for answer why this is a property of a board.
> 

Setting this property on a channel indicates that HW is capable of monitoring that channel and this monitoring requirement would be based on board design.

>>
>>
>>>> +        type: boolean
>>>> +
>>>>      required:
>>>>        - reg
>>>>  
>>>> +required:
>>>> +  - compatible
>>>> +  - reg
>>>> +  - '#address-cells'
>>>> +  - '#size-cells'
>>>> +  - '#io-channel-cells'
>>>> +

...

>>>> +
>>>> +  - if:
>>>> +      properties:
>>>> +        compatible:
>>>> +          contains:
>>>> +            const: qcom,spmi-adc5-gen3
>>>> +
>>>> +    then:
>>>> +      properties:
>>>> +        reg:
>>>> +          minItems: 1
>>>
>>> Why this is flexible?
>>
>> I'm assuming you are asking why it can be either 1 or 2 instead of exactly 2.
>> Both configurations can be supported in HW and it varies between boards. Some of them
>> have exactly one SDAM peripheral assigned for ADC usage and some may have two.
> 
> That's odd. How this can vary between boards with the same, exactly the
> same PMIC? Do you program entirely different FW for different boards
> with the same hardware (PMIC)?

That is actually true, the FW can be different per SOC.

The number of PMIC SDAM peripherals allocated for ADC is not correlated with the PMIC used, 
it is programmed in FW (PBS) and is fixed per SOC, based on the SOC requirements.

The number of ADC SDAMs used on a given SOC with a given PMIC (like PMK8550) will be fixed, but it is possible for
the same PMIC to have 1 of its SDAMs allocated for ADC when used on one SOC and 2 SDAMs allocated for ADC when the PMIC is used on another SOC.  

All boards using a particular (SOC + PMIC) combination will have the same number of ADC SDAMs supported on that PMIC.

Thanks,
Jishnu


> 
> This is programming model, so any differences here must be obvious.
> 
> Best regards,
> Krzysztof
> 





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux