Message-ID: <f016d03c-54db-d983-1634-da9215db011f@microchip.com>
Date:   Fri, 13 May 2022 10:06:32 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <krzysztof.kozlowski@...aro.org>, <srinivas.kandagatla@...aro.org>,
        <robh+dt@...nel.org>, <krzk+dt@...nel.org>
CC:     <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

On 13.05.2022 10:49, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 12/05/2022 18:04, Claudiu.Beznea@...rochip.com wrote:
>> On 12.05.2022 18:35, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 12/05/2022 17:31, Claudiu.Beznea@...rochip.com wrote:
>>>
>>>>>
>>>>> Macro is a nice idea if it can be stable. I understood that length of
>>>>> packets depends on hardware, so this part could be stable. But what
>>>>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
>>>>
>>>> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
>>>> calibration packet. This length is fixed and will not be changed.
>>>>
>>>> After these 2 packets (provided by Microchip) user may further flash any
>>>> number of packets and use them as they wish.
>>>>
>>>> Driver is in charge of scanning the NVMEM for the available packets and
>>>> prepare a list with their IDs and their starting offsets in NVMEM memory
>>>> such that when it receives a read request it will be able to decode the
>>>> packet offset based on packet identifier.
>>>>
>>>> In case different number of packets are available in NVMEM for different
>>>> kind of setups (boards) these could also be referenced in board specific DT
>>>> using OTP_PKT() macro and with proper length (which will depend on what
>>>> user flashed).
>>>>
>>>>> You wrote "Boot configuration packet may vary in length", so it could be
>>>>> changed by Microchip?
>>>>
>>>> Yes, between chip revisions its length could be changed.
>>>
>>> Chip revisions like different board compatibles thus different
>>> bindings/macro values?
>>
>> Not necessarily. It may happen that only ROM code to be updated (1st stage
>> bootloader) end everything else on Linux side to be able to run as is. Or
>> to just fix some bugs in different IPs. Things that will not necessarily
>> need adding new compatibles for the new chip. And it may happen that new
>> chip revisions to be populated on previous board revisions.
>>
>>> Chip revisions like different board compatibles thus different
>>> *macro* values?
>>
>> If you're referring to the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN macro, this is
>> established that will remain fixed b/w revisions. This is the length of the
>> 2nd packet in NVMEM (that is of interest for thermal management).
>>
>> Only the length of the 1st packet may change. And addressing the NVMEM with
>> packet id based index should take care of temperature calibration NVMEM DT
>> binding to work all the time.
>>
>>> If not, then maybe better skip the length out of
>>> bindings and just provide the first macro.
>>
>> As far as I know the length is part of the way the NVMEM cells are
>> described in DT: it needs the offset in memory (for the data to be
>> retrieved) and its length.
> 
> In DT yes, but now you put the length in the bindings. It means DTS must
> have exactly that value and cannot use anything more. It's the same as
> hard-coding unit addresses in the bindings.

I see. I will provide only the OTP_PKT() macro in bindings as you suggested.

Thank you,
Claudiu Beznea

> 
> 
> Best regards,
> Krzysztof

Powered by blists - more mailing lists