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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx 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
