get, prepare, enable a clock not in DT?

get, prepare, enable a clock not in DT?

[Alexander Dahl]

Hello everyone,

while further investigating timeout issues with the at91 otpc
controller on sam9x60 [1] I came to the conclusion the main RC
oscillator on that SoC must be enabled for that driver to work.
(Verified that by poking single bits in registers through devmem
already.)

Fortunately the necessary clk is already registered from the SoC code
in drivers/clk/at91/sam9x60.c [2] and I can see the clock in sysfs clk
summary:

    root@DistroKit:~ head -n4 /sys/kernel/debug/clk/clk_summary 
                                     enable  prepare  protect                                duty  hardware                            connection
       clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
    ---------------------------------------------------------------------------------------------------------------------------------------------
     main_rc_osc                         0       0        0        12000000    50000000   0     50000      Y   deviceless                      no_connection_id         

That clock has no parent and is not found anywhere in devicetree, nor
is it handled by the two clock-producers on that platform, so
from within mchp_otpc_probe() I just tried this:

    otpc->clk = devm_clk_get_enabled(&pdev->dev, "main_rc_osc");

However that returns with -ENOENT, so I assume I can not reference the
clock just by name?  Same result with this:

    otpc->clk = devm_clk_get_enabled(NULL, "main_rc_osc");

How do I get a pointer to that clk then to enable it?  Docs [3] where
not as useful as I hoped for, neither was clk.h header docs. :-/

From what I understood from header docs reading 'device for clock
"consumer"' I must pass the device from which I call that clk_get() as
first parameter, so this would be the otpc device then, right?  What's
that second parameter clock consumer id then?  Are these terms
explained somewhere?

Greets
Alex

[1] <20240813-payable-ecology-8a9e739704bb@thorsis.com>
[2] https://elixir.bootlin.com/linux/v6.10.4/source/drivers/clk/at91/sam9x60.c#L217
[3] https://kernel.org/doc/html/latest/driver-api/clk.html

Re: get, prepare, enable a clock not in DT?

[Alexander Dahl]

Hello everyone,

Am Fri, Aug 16, 2024 at 04:34:48PM +0200 schrieb Alexander Dahl:
> Hello everyone,
> 
> while further investigating timeout issues with the at91 otpc
> controller on sam9x60 [1] I came to the conclusion the main RC
> oscillator on that SoC must be enabled for that driver to work.
> (Verified that by poking single bits in registers through devmem
> already.)
> 
> Fortunately the necessary clk is already registered from the SoC code
> in drivers/clk/at91/sam9x60.c [2] and I can see the clock in sysfs clk
> summary:
> 
>     root@DistroKit:~ head -n4 /sys/kernel/debug/clk/clk_summary 
>                                      enable  prepare  protect                                duty  hardware                            connection
>        clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
>     ---------------------------------------------------------------------------------------------------------------------------------------------
>      main_rc_osc                         0       0        0        12000000    50000000   0     50000      Y   deviceless                      no_connection_id         
> 
> That clock has no parent and is not found anywhere in devicetree, nor
> is it handled by the two clock-producers on that platform, so
> from within mchp_otpc_probe() I just tried this:
> 
>     otpc->clk = devm_clk_get_enabled(&pdev->dev, "main_rc_osc");
> 
> However that returns with -ENOENT, so I assume I can not reference the
> clock just by name?  Same result with this:
> 
>     otpc->clk = devm_clk_get_enabled(NULL, "main_rc_osc");
> 
> How do I get a pointer to that clk then to enable it?  Docs [3] where
> not as useful as I hoped for, neither was clk.h header docs. :-/

Tried this today:

    otpc->clk = __clk_lookup("main_rc_osc");

However calling that from platform driver code smells suspicious and I
get a linker error when building anyways.

Found no other possibility to get a grip on that clock from driver
code.  Do we need to hook that main_rc_osc into dt somehow so it can be
enabled from driver code?

Adding Boris, Alexandre, and Nicolas to Cc, because they were involved
in the at91 clk drivers in the past.  O:-)

Greets
Alex

> From what I understood from header docs reading 'device for clock
> "consumer"' I must pass the device from which I call that clk_get() as
> first parameter, so this would be the otpc device then, right?  What's
> that second parameter clock consumer id then?  Are these terms
> explained somewhere?
> 
> Greets
> Alex
> 
> [1] <20240813-payable-ecology-8a9e739704bb@thorsis.com>
> [2] https://elixir.bootlin.com/linux/v6.10.4/source/drivers/clk/at91/sam9x60.c#L217
> [3] https://kernel.org/doc/html/latest/driver-api/clk.html
> 
> 

Re: get, prepare, enable a clock not in DT?

[claudiu beznea]

Hi, Alexander,

On 16.08.2024 17:34, Alexander Dahl wrote:
> Hello everyone,
> 
> while further investigating timeout issues with the at91 otpc
> controller on sam9x60 [1] I came to the conclusion the main RC
> oscillator on that SoC must be enabled for that driver to work.

Not sure how that works (unless undocumented) as figure Figure 28-1. Clock
Generator Block Diagram from [1] states that main_rc_osc feeds only the mainck.

Also, Table 9-1. Peripheral Identifiers from [1] say that there is no clock
control for OTCP on the PMC side.

[1]
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X60-Data-Sheet-DS60001579.pdf

> (Verified that by poking single bits in registers through devmem
> already.)
> 
> Fortunately the necessary clk is already registered from the SoC code
> in drivers/clk/at91/sam9x60.c [2] and I can see the clock in sysfs clk
> summary:
> 
>     root@DistroKit:~ head -n4 /sys/kernel/debug/clk/clk_summary 
>                                      enable  prepare  protect                                duty  hardware                            connection
>        clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
>     ---------------------------------------------------------------------------------------------------------------------------------------------
>      main_rc_osc                         0       0        0        12000000    50000000   0     50000      Y   deviceless                      no_connection_id         
> 
> That clock has no parent and is not found anywhere in devicetree, nor
> is it handled by the two clock-producers on that platform, so
> from within mchp_otpc_probe() I just tried this:
> 
>     otpc->clk = devm_clk_get_enabled(&pdev->dev, "main_rc_osc");

> 
> However that returns with -ENOENT, so I assume I can not reference the
> clock just by name?  Same result with this:
> 
>     otpc->clk = devm_clk_get_enabled(NULL, "main_rc_osc");
> 
> How do I get a pointer to that clk then to enable it?  Docs [3] where

To expose it though DT you may want to save its hw object to one array
entry in sam9x60_pmc, sam9x60_pmc->chws[] fits best for this atm.

Otherwise, you can try to register the main_rc_osc with CLK_IS_CRITICAL for
simple trials.

Thank you,
Claudiu Beznea

> not as useful as I hoped for, neither was clk.h header docs. :-/
> 
> From what I understood from header docs reading 'device for clock
> "consumer"' I must pass the device from which I call that clk_get() as
> first parameter, so this would be the otpc device then, right?  What's
> that second parameter clock consumer id then?  Are these terms
> explained somewhere?
> 
> Greets
> Alex
> 
> [1] <20240813-payable-ecology-8a9e739704bb@thorsis.com>
> [2] https://elixir.bootlin.com/linux/v6.10.4/source/drivers/clk/at91/sam9x60.c#L217
> [3] https://kernel.org/doc/html/latest/driver-api/clk.html
> 

Re: get, prepare, enable a clock not in DT?

[Alexander Dahl]

Hello Claudiu,

Am Tue, Aug 20, 2024 at 02:54:59PM +0300 schrieb claudiu beznea:
> Hi, Alexander,
> 
> On 16.08.2024 17:34, Alexander Dahl wrote:
> > Hello everyone,
> > 
> > while further investigating timeout issues with the at91 otpc
> > controller on sam9x60 [1] I came to the conclusion the main RC
> > oscillator on that SoC must be enabled for that driver to work.
> 
> Not sure how that works (unless undocumented) as figure Figure 28-1. Clock
> Generator Block Diagram from [1] states that main_rc_osc feeds only the mainck.

It can feed the main clock and you're right from Clock Generator POV.
However it is not completely undocumented.  Section "23.4 Product
Dependencies" of the SAM9X60 datasheet (DS60001579G) says:

    "The OTPC is clocked through the Power Management Controller (PMC).
    The user must power on the main RC oscillator and enable the
    peripheral clock of the OTPC prior to reading or writing the OTP
    memory."

Apparently this also applies to reading, at least according to my
tests on sam9x60-curiosity.

btw, the last public release of the atmel-software-package, source for
the sam-ba applets, also enables that clock, although the reasoning
was for writing. [1]

> Also, Table 9-1. Peripheral Identifiers from [1] say that there is no clock
> control for OTCP on the PMC side.
> 
> [1]
> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X60-Data-Sheet-DS60001579.pdf

You're right from the datasheet POV.  Not sure if the datasheet is
right here?  It's not complete in some register contents anyway, maybe
some things are kept confidential, and OTPC is part of that?

Maybe someone can confirm my findings on sam9x60-curiosity, e.g.
after I sent a patch series with what I consider fixes for this topic?

> > (Verified that by poking single bits in registers through devmem
> > already.)
> > 
> > Fortunately the necessary clk is already registered from the SoC code
> > in drivers/clk/at91/sam9x60.c [2] and I can see the clock in sysfs clk
> > summary:
> > 
> >     root@DistroKit:~ head -n4 /sys/kernel/debug/clk/clk_summary 
> >                                      enable  prepare  protect                                duty  hardware                            connection
> >        clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
> >     ---------------------------------------------------------------------------------------------------------------------------------------------
> >      main_rc_osc                         0       0        0        12000000    50000000   0     50000      Y   deviceless                      no_connection_id         
> > 
> > That clock has no parent and is not found anywhere in devicetree, nor
> > is it handled by the two clock-producers on that platform, so
> > from within mchp_otpc_probe() I just tried this:
> > 
> >     otpc->clk = devm_clk_get_enabled(&pdev->dev, "main_rc_osc");
> 
> > 
> > However that returns with -ENOENT, so I assume I can not reference the
> > clock just by name?  Same result with this:
> > 
> >     otpc->clk = devm_clk_get_enabled(NULL, "main_rc_osc");
> > 
> > How do I get a pointer to that clk then to enable it?  Docs [3] where
> 
> To expose it though DT you may want to save its hw object to one array
> entry in sam9x60_pmc, sam9x60_pmc->chws[] fits best for this atm.

Great to see I came to the same conclusion.  I have a proof-of-concept
working meanwhile, will send a patch series later this week I guess.

Thanks for your support.

> Otherwise, you can try to register the main_rc_osc with CLK_IS_CRITICAL for
> simple trials.

Don't think that is necessary anymore. :-)

By chance: I don't have a sama7g5 based board at hand for testing.
The datasheet says the same as for sam9x60.
Does the nvmem_microchip_otpc driver actually work without timeout on
sama7g5?

Greets
Alex

> 
> Thank you,
> Claudiu Beznea
> 
> > not as useful as I hoped for, neither was clk.h header docs. :-/
> > 
> > From what I understood from header docs reading 'device for clock
> > "consumer"' I must pass the device from which I call that clk_get() as
> > first parameter, so this would be the otpc device then, right?  What's
> > that second parameter clock consumer id then?  Are these terms
> > explained somewhere?
> > 
> > Greets
> > Alex
> > 
> > [1] <20240813-payable-ecology-8a9e739704bb@thorsis.com>
> > [2] https://elixir.bootlin.com/linux/v6.10.4/source/drivers/clk/at91/sam9x60.c#L217
> > [3] https://kernel.org/doc/html/latest/driver-api/clk.html
> > 
> 

Re: get, prepare, enable a clock not in DT?

[Alexander Dahl]

Hello,

Am Tue, Aug 20, 2024 at 02:17:58PM +0200 schrieb Alexander Dahl:
> Hello Claudiu,
> 
> Am Tue, Aug 20, 2024 at 02:54:59PM +0300 schrieb claudiu beznea:
> > Hi, Alexander,
> > 
> > On 16.08.2024 17:34, Alexander Dahl wrote:
> > > Hello everyone,
> > > 
> > > while further investigating timeout issues with the at91 otpc
> > > controller on sam9x60 [1] I came to the conclusion the main RC
> > > oscillator on that SoC must be enabled for that driver to work.
> > 
> > Not sure how that works (unless undocumented) as figure Figure 28-1. Clock
> > Generator Block Diagram from [1] states that main_rc_osc feeds only the mainck.
> 
> It can feed the main clock and you're right from Clock Generator POV.
> However it is not completely undocumented.  Section "23.4 Product
> Dependencies" of the SAM9X60 datasheet (DS60001579G) says:
> 
>     "The OTPC is clocked through the Power Management Controller (PMC).
>     The user must power on the main RC oscillator and enable the
>     peripheral clock of the OTPC prior to reading or writing the OTP
>     memory."
> 
> Apparently this also applies to reading, at least according to my
> tests on sam9x60-curiosity.
> 
> btw, the last public release of the atmel-software-package, source for
> the sam-ba applets, also enables that clock, although the reasoning
> was for writing. [1]

Sorry, forgot that reference, FWIW:

[1] https://github.com/atmelcorp/atmel-software-package/blob/master/drivers/nvm/otp/otpc.c#L99

Greets
Alex

> 
> > Also, Table 9-1. Peripheral Identifiers from [1] say that there is no clock
> > control for OTCP on the PMC side.
> > 
> > [1]
> > https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X60-Data-Sheet-DS60001579.pdf
> 
> You're right from the datasheet POV.  Not sure if the datasheet is
> right here?  It's not complete in some register contents anyway, maybe
> some things are kept confidential, and OTPC is part of that?
> 
> Maybe someone can confirm my findings on sam9x60-curiosity, e.g.
> after I sent a patch series with what I consider fixes for this topic?
> 
> > > (Verified that by poking single bits in registers through devmem
> > > already.)
> > > 
> > > Fortunately the necessary clk is already registered from the SoC code
> > > in drivers/clk/at91/sam9x60.c [2] and I can see the clock in sysfs clk
> > > summary:
> > > 
> > >     root@DistroKit:~ head -n4 /sys/kernel/debug/clk/clk_summary 
> > >                                      enable  prepare  protect                                duty  hardware                            connection
> > >        clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
> > >     ---------------------------------------------------------------------------------------------------------------------------------------------
> > >      main_rc_osc                         0       0        0        12000000    50000000   0     50000      Y   deviceless                      no_connection_id         
> > > 
> > > That clock has no parent and is not found anywhere in devicetree, nor
> > > is it handled by the two clock-producers on that platform, so
> > > from within mchp_otpc_probe() I just tried this:
> > > 
> > >     otpc->clk = devm_clk_get_enabled(&pdev->dev, "main_rc_osc");
> > 
> > > 
> > > However that returns with -ENOENT, so I assume I can not reference the
> > > clock just by name?  Same result with this:
> > > 
> > >     otpc->clk = devm_clk_get_enabled(NULL, "main_rc_osc");
> > > 
> > > How do I get a pointer to that clk then to enable it?  Docs [3] where
> > 
> > To expose it though DT you may want to save its hw object to one array
> > entry in sam9x60_pmc, sam9x60_pmc->chws[] fits best for this atm.
> 
> Great to see I came to the same conclusion.  I have a proof-of-concept
> working meanwhile, will send a patch series later this week I guess.
> 
> Thanks for your support.
> 
> > Otherwise, you can try to register the main_rc_osc with CLK_IS_CRITICAL for
> > simple trials.
> 
> Don't think that is necessary anymore. :-)
> 
> By chance: I don't have a sama7g5 based board at hand for testing.
> The datasheet says the same as for sam9x60.
> Does the nvmem_microchip_otpc driver actually work without timeout on
> sama7g5?
> 
> Greets
> Alex
> 
> > 
> > Thank you,
> > Claudiu Beznea
> > 
> > > not as useful as I hoped for, neither was clk.h header docs. :-/
> > > 
> > > From what I understood from header docs reading 'device for clock
> > > "consumer"' I must pass the device from which I call that clk_get() as
> > > first parameter, so this would be the otpc device then, right?  What's
> > > that second parameter clock consumer id then?  Are these terms
> > > explained somewhere?
> > > 
> > > Greets
> > > Alex
> > > 
> > > [1] <20240813-payable-ecology-8a9e739704bb@thorsis.com>
> > > [2] https://elixir.bootlin.com/linux/v6.10.4/source/drivers/clk/at91/sam9x60.c#L217
> > > [3] https://kernel.org/doc/html/latest/driver-api/clk.html
> > > 
> > 
> 

Re: get, prepare, enable a clock not in DT?

[claudiu beznea]

On 20.08.2024 15:17, Alexander Dahl wrote:
> Hello Claudiu,
> 
> Am Tue, Aug 20, 2024 at 02:54:59PM +0300 schrieb claudiu beznea:
>> Hi, Alexander,
>>
>> On 16.08.2024 17:34, Alexander Dahl wrote:
>>> Hello everyone,
>>>
>>> while further investigating timeout issues with the at91 otpc
>>> controller on sam9x60 [1] I came to the conclusion the main RC
>>> oscillator on that SoC must be enabled for that driver to work.
>>
>> Not sure how that works (unless undocumented) as figure Figure 28-1. Clock
>> Generator Block Diagram from [1] states that main_rc_osc feeds only the mainck.
> 
> It can feed the main clock and you're right from Clock Generator POV.
> However it is not completely undocumented.  Section "23.4 Product
> Dependencies" of the SAM9X60 datasheet (DS60001579G) says:
> 
>     "The OTPC is clocked through the Power Management Controller (PMC).
>     The user must power on the main RC oscillator and enable the
>     peripheral clock of the OTPC prior to reading or writing the OTP
>     memory."
> 
> Apparently this also applies to reading, at least according to my
> tests on sam9x60-curiosity.
> 
> btw, the last public release of the atmel-software-package, source for
> the sam-ba applets, also enables that clock, although the reasoning
> was for writing. [1]
> 
>> Also, Table 9-1. Peripheral Identifiers from [1] say that there is no clock
>> control for OTCP on the PMC side.
>>
>> [1]
>> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X60-Data-Sheet-DS60001579.pdf
> 
> You're right from the datasheet POV.  Not sure if the datasheet is
> right here?  It's not complete in some register contents anyway, maybe
> some things are kept confidential, and OTPC is part of that?
> 
> Maybe someone can confirm my findings on sam9x60-curiosity, e.g.
> after I sent a patch series with what I consider fixes for this topic?
> 
>>> (Verified that by poking single bits in registers through devmem
>>> already.)
>>>
>>> Fortunately the necessary clk is already registered from the SoC code
>>> in drivers/clk/at91/sam9x60.c [2] and I can see the clock in sysfs clk
>>> summary:
>>>
>>>     root@DistroKit:~ head -n4 /sys/kernel/debug/clk/clk_summary 
>>>                                      enable  prepare  protect                                duty  hardware                            connection
>>>        clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
>>>     ---------------------------------------------------------------------------------------------------------------------------------------------
>>>      main_rc_osc                         0       0        0        12000000    50000000   0     50000      Y   deviceless                      no_connection_id         
>>>
>>> That clock has no parent and is not found anywhere in devicetree, nor
>>> is it handled by the two clock-producers on that platform, so
>>> from within mchp_otpc_probe() I just tried this:
>>>
>>>     otpc->clk = devm_clk_get_enabled(&pdev->dev, "main_rc_osc");
>>
>>>
>>> However that returns with -ENOENT, so I assume I can not reference the
>>> clock just by name?  Same result with this:
>>>
>>>     otpc->clk = devm_clk_get_enabled(NULL, "main_rc_osc");
>>>
>>> How do I get a pointer to that clk then to enable it?  Docs [3] where
>>
>> To expose it though DT you may want to save its hw object to one array
>> entry in sam9x60_pmc, sam9x60_pmc->chws[] fits best for this atm.
> 
> Great to see I came to the same conclusion.  I have a proof-of-concept
> working meanwhile, will send a patch series later this week I guess.
> 
> Thanks for your support.
> 
>> Otherwise, you can try to register the main_rc_osc with CLK_IS_CRITICAL for
>> simple trials.
> 
> Don't think that is necessary anymore. :-)
> 
> By chance: I don't have a sama7g5 based board at hand for testing.
> The datasheet says the same as for sam9x60.
> Does the nvmem_microchip_otpc driver actually work without timeout on
> sama7g5?

Yes! This should be because system bus is clocked from MCK0 (as mentioned
in peripheral identifiers table) which is enabled by bootloader.

Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and
thermal calibration packets:
https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq

> 
> Greets
> Alex
> 
>>
>> Thank you,
>> Claudiu Beznea
>>
>>> not as useful as I hoped for, neither was clk.h header docs. :-/
>>>
>>> From what I understood from header docs reading 'device for clock
>>> "consumer"' I must pass the device from which I call that clk_get() as
>>> first parameter, so this would be the otpc device then, right?  What's
>>> that second parameter clock consumer id then?  Are these terms
>>> explained somewhere?
>>>
>>> Greets
>>> Alex
>>>
>>> [1] <20240813-payable-ecology-8a9e739704bb@thorsis.com>
>>> [2] https://elixir.bootlin.com/linux/v6.10.4/source/drivers/clk/at91/sam9x60.c#L217
>>> [3] https://kernel.org/doc/html/latest/driver-api/clk.html
>>>
>>

Re: get, prepare, enable a clock not in DT?

[Alexander Dahl]

Hello Claudiu,

Am Fri, Aug 23, 2024 at 05:29:44PM +0300 schrieb claudiu beznea:
> 
> 
> On 20.08.2024 15:17, Alexander Dahl wrote:
> > By chance: I don't have a sama7g5 based board at hand for testing.
> > The datasheet says the same as for sam9x60.
> > Does the nvmem_microchip_otpc driver actually work without timeout on
> > sama7g5?
> 
> Yes! This should be because system bus is clocked from MCK0 (as mentioned
> in peripheral identifiers table) which is enabled by bootloader.

Not sure I can follow.  Citing the SAMA7G5 datasheet section 30.4
(OTPC Product Dependencies):

    "The OTPC is clocked through the Power Management Controller
    (PMC). The user must power on the main RC oscillator and enable
    the peripheral clock of the OTPC prior to reading or writing the
    OTP memory."

Table from section 8.5 (Peripheral Clocks …) has no check mark at "PMC
clock control" but indeed lists MCK0 as main system bus clock.  If it
works on SAMA7G5 without explicitly enabling main RC oscillator, then
either that clock is on accidentally, or the datasheet is wrong in the
OTPC section.

Personally I find the "clocked through PMC" part in the OTPC
section suspicious, because in the peripheral identifiers table OTPC
has no "PMC Clock Control" mark.

Not sure what's the difference between SAM9X60 and SAMA7G5 internally,
though.  From a user's POV it's possible one of them requires the
main RC osc, and the other does not, but currently you can't tell from
the datasheets.

> Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and
> thermal calibration packets:
> https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq

Greets
Alex

Re: get, prepare, enable a clock not in DT?

[claudiu beznea]

Hi, Alexander,

On 28.08.2024 09:55, Alexander Dahl wrote:
> Hello Claudiu,
> 
> Am Fri, Aug 23, 2024 at 05:29:44PM +0300 schrieb claudiu beznea:
>>
>>
>> On 20.08.2024 15:17, Alexander Dahl wrote:
>>> By chance: I don't have a sama7g5 based board at hand for testing.
>>> The datasheet says the same as for sam9x60.
>>> Does the nvmem_microchip_otpc driver actually work without timeout on
>>> sama7g5?
>>
>> Yes! This should be because system bus is clocked from MCK0 (as mentioned
>> in peripheral identifiers table) which is enabled by bootloader.
> 
> Not sure I can follow.  Citing the SAMA7G5 datasheet section 30.4
> (OTPC Product Dependencies):
> 
>     "The OTPC is clocked through the Power Management Controller
>     (PMC). The user must power on the main RC oscillator and enable
>     the peripheral clock of the OTPC prior to reading or writing the
>     OTP memory."

I don't see this in [1]. Only:

"The OTPC is clocked through the Power Management Controller (PMC), so the
programmer must first to configure the PMC."

From this I got that it is about the MCK0 listed in table Table 8-11.
Peripheral Identifiers.

[1]
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765A.pdf

> 
> Table from section 8.5 (Peripheral Clocks …) has no check mark at "PMC
> clock control" but indeed lists MCK0 as main system bus clock.

This is what I was taking about.

>  If it
> works on SAMA7G5 without explicitly enabling main RC oscillator, then
> either that clock is on accidentally, or the datasheet is wrong in the
> OTPC section.

Might be.

Thank you,
Claudiu Beznea

> 
> Personally I find the "clocked through PMC" part in the OTPC
> section suspicious, because in the peripheral identifiers table OTPC
> has no "PMC Clock Control" mark.
> 
> Not sure what's the difference between SAM9X60 and SAMA7G5 internally,
> though.  From a user's POV it's possible one of them requires the
> main RC osc, and the other does not, but currently you can't tell from
> the datasheets.
> 
>> Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and
>> thermal calibration packets:
>> https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq
> 
> Greets
> Alex
> 

Re: get, prepare, enable a clock not in DT?

[Alexander Dahl]

Hello Claudiu,

Am Sat, Aug 31, 2024 at 06:49:59PM +0300 schrieb claudiu beznea:
> Hi, Alexander,
> 
> On 28.08.2024 09:55, Alexander Dahl wrote:
> > Hello Claudiu,
> > 
> > Am Fri, Aug 23, 2024 at 05:29:44PM +0300 schrieb claudiu beznea:
> >>
> >>
> >> On 20.08.2024 15:17, Alexander Dahl wrote:
> >>> By chance: I don't have a sama7g5 based board at hand for testing.
> >>> The datasheet says the same as for sam9x60.
> >>> Does the nvmem_microchip_otpc driver actually work without timeout on
> >>> sama7g5?
> >>
> >> Yes! This should be because system bus is clocked from MCK0 (as mentioned
> >> in peripheral identifiers table) which is enabled by bootloader.
> > 
> > Not sure I can follow.  Citing the SAMA7G5 datasheet section 30.4
> > (OTPC Product Dependencies):
> > 
> >     "The OTPC is clocked through the Power Management Controller
> >     (PMC). The user must power on the main RC oscillator and enable
> >     the peripheral clock of the OTPC prior to reading or writing the
> >     OTP memory."
> 
> I don't see this in [1]. Only:
> 
> "The OTPC is clocked through the Power Management Controller (PMC), so the
> programmer must first to configure the PMC."
> 
> From this I got that it is about the MCK0 listed in table Table 8-11.
> Peripheral Identifiers.
> 
> [1]
> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765A.pdf

Well, this seems to be an older version revision A from 03/2022.
I have DS60001765B (revision B) from 12/2023 and got this here (note
the missing 'A' in the filename):

https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf

Linked here:

https://www.microchip.com/en-us/product/sama7g54

The revision history is not very specific, it only says "Updated Power
Management".  Errata sheet has nothing interesting on that topic.

We both cited what we saw in the datasheets.  Revision A has the
section you cited, revision B has the section I cited.

> > Table from section 8.5 (Peripheral Clocks …) has no check mark at "PMC
> > clock control" but indeed lists MCK0 as main system bus clock.
> 
> This is what I was taking about.
> 
> >  If it
> > works on SAMA7G5 without explicitly enabling main RC oscillator, then
> > either that clock is on accidentally, or the datasheet is wrong in the
> > OTPC section.
> 
> Might be.

I don't have a SAMA7G5 at hand.  Someone who has could test if OTPC
works with/without MCK0, and with/without main RC osc, all possible
combinations would be most helpful: with none of those, with only one,
only the other, both.

Hope we get this clock stuff sorted out?!

Greets
Alex

> 
> Thank you,
> Claudiu Beznea
> 
> > 
> > Personally I find the "clocked through PMC" part in the OTPC
> > section suspicious, because in the peripheral identifiers table OTPC
> > has no "PMC Clock Control" mark.
> > 
> > Not sure what's the difference between SAM9X60 and SAMA7G5 internally,
> > though.  From a user's POV it's possible one of them requires the
> > main RC osc, and the other does not, but currently you can't tell from
> > the datasheets.
> > 
> >> Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and
> >> thermal calibration packets:
> >> https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq
> > 
> > Greets
> > Alex
> > 
> 

Re: get, prepare, enable a clock not in DT?

[claudiu beznea]

Hi, Alexander,

On 02.09.2024 11:24, Alexander Dahl wrote:
> Hello Claudiu,
> 
> Am Sat, Aug 31, 2024 at 06:49:59PM +0300 schrieb claudiu beznea:
>> Hi, Alexander,
>>
>> On 28.08.2024 09:55, Alexander Dahl wrote:
>>> Hello Claudiu,
>>>
>>> Am Fri, Aug 23, 2024 at 05:29:44PM +0300 schrieb claudiu beznea:
>>>>
>>>>
>>>> On 20.08.2024 15:17, Alexander Dahl wrote:
>>>>> By chance: I don't have a sama7g5 based board at hand for testing.
>>>>> The datasheet says the same as for sam9x60.
>>>>> Does the nvmem_microchip_otpc driver actually work without timeout on
>>>>> sama7g5?
>>>>
>>>> Yes! This should be because system bus is clocked from MCK0 (as mentioned
>>>> in peripheral identifiers table) which is enabled by bootloader.
>>>
>>> Not sure I can follow.  Citing the SAMA7G5 datasheet section 30.4
>>> (OTPC Product Dependencies):
>>>
>>>     "The OTPC is clocked through the Power Management Controller
>>>     (PMC). The user must power on the main RC oscillator and enable
>>>     the peripheral clock of the OTPC prior to reading or writing the
>>>     OTP memory."
>>
>> I don't see this in [1]. Only:
>>
>> "The OTPC is clocked through the Power Management Controller (PMC), so the
>> programmer must first to configure the PMC."
>>
>> From this I got that it is about the MCK0 listed in table Table 8-11.
>> Peripheral Identifiers.
>>
>> [1]
>> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765A.pdf
> 
> Well, this seems to be an older version revision A from 03/2022.
> I have DS60001765B (revision B) from 12/2023 and got this here (note
> the missing 'A' in the filename):
> 
> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf

This version clearly express your findings. The unknown now is the
"peripheral clock" that need to be enabled along with the
main_rc_oscillator. For that you may want to play around with PMC
Peripheral Control Register, PMC peripheral clock status register and see
if OTPC fails to work when disabling the peripheral clock with the OTPC ID
as there is no information about peripheral clock for OTPC in the
peripheral identifers table.

Hope this helps.

Thank you,
Claudiu Beznea

> 
> Linked here:
> 
> https://www.microchip.com/en-us/product/sama7g54
> 
> The revision history is not very specific, it only says "Updated Power
> Management".  Errata sheet has nothing interesting on that topic.
> 
> We both cited what we saw in the datasheets.  Revision A has the
> section you cited, revision B has the section I cited.
> 
>>> Table from section 8.5 (Peripheral Clocks …) has no check mark at "PMC
>>> clock control" but indeed lists MCK0 as main system bus clock.
>>
>> This is what I was taking about.
>>
>>>  If it
>>> works on SAMA7G5 without explicitly enabling main RC oscillator, then
>>> either that clock is on accidentally, or the datasheet is wrong in the
>>> OTPC section.
>>
>> Might be.
> 
> I don't have a SAMA7G5 at hand.  Someone who has could test if OTPC
> works with/without MCK0, and with/without main RC osc, all possible
> combinations would be most helpful: with none of those, with only one,
> only the other, both.
> 
> Hope we get this clock stuff sorted out?!
> 
> Greets
> Alex
> 
>>
>> Thank you,
>> Claudiu Beznea
>>
>>>
>>> Personally I find the "clocked through PMC" part in the OTPC
>>> section suspicious, because in the peripheral identifiers table OTPC
>>> has no "PMC Clock Control" mark.
>>>
>>> Not sure what's the difference between SAM9X60 and SAMA7G5 internally,
>>> though.  From a user's POV it's possible one of them requires the
>>> main RC osc, and the other does not, but currently you can't tell from
>>> the datasheets.
>>>
>>>> Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and
>>>> thermal calibration packets:
>>>> https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq
>>>
>>> Greets
>>> Alex
>>>
>>

Re: get, prepare, enable a clock not in DT?

[Nicolas Ferre]

On 04/09/2024 at 09:33, claudiu beznea wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi, Alexander,
> 
> On 02.09.2024 11:24, Alexander Dahl wrote:
>> Hello Claudiu,
>>
>> Am Sat, Aug 31, 2024 at 06:49:59PM +0300 schrieb claudiu beznea:
>>> Hi, Alexander,
>>>
>>> On 28.08.2024 09:55, Alexander Dahl wrote:
>>>> Hello Claudiu,
>>>>
>>>> Am Fri, Aug 23, 2024 at 05:29:44PM +0300 schrieb claudiu beznea:
>>>>>
>>>>>
>>>>> On 20.08.2024 15:17, Alexander Dahl wrote:
>>>>>> By chance: I don't have a sama7g5 based board at hand for testing.
>>>>>> The datasheet says the same as for sam9x60.
>>>>>> Does the nvmem_microchip_otpc driver actually work without timeout on
>>>>>> sama7g5?
>>>>>
>>>>> Yes! This should be because system bus is clocked from MCK0 (as mentioned
>>>>> in peripheral identifiers table) which is enabled by bootloader.
>>>>
>>>> Not sure I can follow.  Citing the SAMA7G5 datasheet section 30.4
>>>> (OTPC Product Dependencies):
>>>>
>>>>      "The OTPC is clocked through the Power Management Controller
>>>>      (PMC). The user must power on the main RC oscillator and enable
>>>>      the peripheral clock of the OTPC prior to reading or writing the
>>>>      OTP memory."
>>>
>>> I don't see this in [1]. Only:
>>>
>>> "The OTPC is clocked through the Power Management Controller (PMC), so the
>>> programmer must first to configure the PMC."
>>>
>>>  From this I got that it is about the MCK0 listed in table Table 8-11.
>>> Peripheral Identifiers.
>>>
>>> [1]
>>> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765A.pdf
>>
>> Well, this seems to be an older version revision A from 03/2022.
>> I have DS60001765B (revision B) from 12/2023 and got this here (note
>> the missing 'A' in the filename):
>>
>> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf
> 
> This version clearly express your findings. The unknown now is the
> "peripheral clock" that need to be enabled along with the
> main_rc_oscillator. For that you may want to play around with PMC
> Peripheral Control Register, PMC peripheral clock status register and see
> if OTPC fails to work when disabling the peripheral clock with the OTPC ID
> as there is no information about peripheral clock for OTPC in the
> peripheral identifers table.
> 
> Hope this helps.

FYI, I asked internally. I'll keep you posted.

Regards,
   Nicolas

>> Linked here:
>>
>> https://www.microchip.com/en-us/product/sama7g54
>>
>> The revision history is not very specific, it only says "Updated Power
>> Management".  Errata sheet has nothing interesting on that topic.
>>
>> We both cited what we saw in the datasheets.  Revision A has the
>> section you cited, revision B has the section I cited.
>>
>>>> Table from section 8.5 (Peripheral Clocks …) has no check mark at "PMC
>>>> clock control" but indeed lists MCK0 as main system bus clock.
>>>
>>> This is what I was taking about.
>>>
>>>>   If it
>>>> works on SAMA7G5 without explicitly enabling main RC oscillator, then
>>>> either that clock is on accidentally, or the datasheet is wrong in the
>>>> OTPC section.
>>>
>>> Might be.
>>
>> I don't have a SAMA7G5 at hand.  Someone who has could test if OTPC
>> works with/without MCK0, and with/without main RC osc, all possible
>> combinations would be most helpful: with none of those, with only one,
>> only the other, both.
>>
>> Hope we get this clock stuff sorted out?!
>>
>> Greets
>> Alex
>>
>>>
>>> Thank you,
>>> Claudiu Beznea
>>>
>>>>
>>>> Personally I find the "clocked through PMC" part in the OTPC
>>>> section suspicious, because in the peripheral identifiers table OTPC
>>>> has no "PMC Clock Control" mark.
>>>>
>>>> Not sure what's the difference between SAM9X60 and SAMA7G5 internally,
>>>> though.  From a user's POV it's possible one of them requires the
>>>> main RC osc, and the other does not, but currently you can't tell from
>>>> the datasheets.
>>>>
>>>>> Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and
>>>>> thermal calibration packets:
>>>>> https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq
>>>>
>>>> Greets
>>>> Alex
>>>>
>>>

Re: get, prepare, enable a clock not in DT?

[Alexander Dahl]

Hello Claudiu, Nicolas,

Am Wed, Sep 04, 2024 at 03:26:45PM +0200 schrieb Nicolas Ferre:
> On 04/09/2024 at 09:33, claudiu beznea wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > Hi, Alexander,
> > 
> > On 02.09.2024 11:24, Alexander Dahl wrote:
> > > Hello Claudiu,
> > > 
> > > Am Sat, Aug 31, 2024 at 06:49:59PM +0300 schrieb claudiu beznea:
> > > > Hi, Alexander,
> > > > 
> > > > On 28.08.2024 09:55, Alexander Dahl wrote:
> > > > > Hello Claudiu,
> > > > > 
> > > > > Am Fri, Aug 23, 2024 at 05:29:44PM +0300 schrieb claudiu beznea:
> > > > > > 
> > > > > > 
> > > > > > On 20.08.2024 15:17, Alexander Dahl wrote:
> > > > > > > By chance: I don't have a sama7g5 based board at hand for testing.
> > > > > > > The datasheet says the same as for sam9x60.
> > > > > > > Does the nvmem_microchip_otpc driver actually work without timeout on
> > > > > > > sama7g5?
> > > > > > 
> > > > > > Yes! This should be because system bus is clocked from MCK0 (as mentioned
> > > > > > in peripheral identifiers table) which is enabled by bootloader.
> > > > > 
> > > > > Not sure I can follow.  Citing the SAMA7G5 datasheet section 30.4
> > > > > (OTPC Product Dependencies):
> > > > > 
> > > > >      "The OTPC is clocked through the Power Management Controller
> > > > >      (PMC). The user must power on the main RC oscillator and enable
> > > > >      the peripheral clock of the OTPC prior to reading or writing the
> > > > >      OTP memory."
> > > > 
> > > > I don't see this in [1]. Only:
> > > > 
> > > > "The OTPC is clocked through the Power Management Controller (PMC), so the
> > > > programmer must first to configure the PMC."
> > > > 
> > > >  From this I got that it is about the MCK0 listed in table Table 8-11.
> > > > Peripheral Identifiers.
> > > > 
> > > > [1]
> > > > https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765A.pdf
> > > 
> > > Well, this seems to be an older version revision A from 03/2022.
> > > I have DS60001765B (revision B) from 12/2023 and got this here (note
> > > the missing 'A' in the filename):
> > > 
> > > https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf
> > 
> > This version clearly express your findings. The unknown now is the
> > "peripheral clock" that need to be enabled along with the
> > main_rc_oscillator. For that you may want to play around with PMC
> > Peripheral Control Register, PMC peripheral clock status register and see
> > if OTPC fails to work when disabling the peripheral clock with the OTPC ID
> > as there is no information about peripheral clock for OTPC in the
> > peripheral identifers table.

The SAM9X60 seems to be different here, than the SAMA7G5.

(I only have SAM9X60 here, I can not test on SAMA7G5.)

To make it work I did not enable or disable a certain PMC peripheral
clocks on SAM9X60.  The peripheral ID for OTPC is 46 on SAM9X60, and
in the Peripheral Identifiers table there's no checkmark under "PMC
Clock Control".  The ID is also not part of the sam9x60 clock drivers.
This tells me SAM9X60 does not need a PMC peripheral clock enabled for
the OTPC to work and my experiments confirm this.  Enabling the main
RC oscillator was sufficient.

> > Hope this helps.
> 
> FYI, I asked internally. I'll keep you posted.

Thanks Nicolas, I appreciate this.

Greets
Alex

> 
> Regards,
>   Nicolas
> 
> > > Linked here:
> > > 
> > > https://www.microchip.com/en-us/product/sama7g54
> > > 
> > > The revision history is not very specific, it only says "Updated Power
> > > Management".  Errata sheet has nothing interesting on that topic.
> > > 
> > > We both cited what we saw in the datasheets.  Revision A has the
> > > section you cited, revision B has the section I cited.
> > > 
> > > > > Table from section 8.5 (Peripheral Clocks …) has no check mark at "PMC
> > > > > clock control" but indeed lists MCK0 as main system bus clock.
> > > > 
> > > > This is what I was taking about.
> > > > 
> > > > >   If it
> > > > > works on SAMA7G5 without explicitly enabling main RC oscillator, then
> > > > > either that clock is on accidentally, or the datasheet is wrong in the
> > > > > OTPC section.
> > > > 
> > > > Might be.
> > > 
> > > I don't have a SAMA7G5 at hand.  Someone who has could test if OTPC
> > > works with/without MCK0, and with/without main RC osc, all possible
> > > combinations would be most helpful: with none of those, with only one,
> > > only the other, both.
> > > 
> > > Hope we get this clock stuff sorted out?!
> > > 
> > > Greets
> > > Alex
> > > 
> > > > 
> > > > Thank you,
> > > > Claudiu Beznea
> > > > 
> > > > > 
> > > > > Personally I find the "clocked through PMC" part in the OTPC
> > > > > section suspicious, because in the peripheral identifiers table OTPC
> > > > > has no "PMC Clock Control" mark.
> > > > > 
> > > > > Not sure what's the difference between SAM9X60 and SAMA7G5 internally,
> > > > > though.  From a user's POV it's possible one of them requires the
> > > > > main RC osc, and the other does not, but currently you can't tell from
> > > > > the datasheets.
> > > > > 
> > > > > > Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and
> > > > > > thermal calibration packets:
> > > > > > https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq
> > > > > 
> > > > > Greets
> > > > > Alex
> > > > > 
> > > > 
> 
> 

Re: get, prepare, enable a clock not in DT?

[Nicolas Ferre]

On 04/09/2024 at 16:43, Alexander Dahl wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hello Claudiu, Nicolas,
> 
> Am Wed, Sep 04, 2024 at 03:26:45PM +0200 schrieb Nicolas Ferre:
>> On 04/09/2024 at 09:33, claudiu beznea wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Hi, Alexander,
>>>
>>> On 02.09.2024 11:24, Alexander Dahl wrote:
>>>> Hello Claudiu,
>>>>
>>>> Am Sat, Aug 31, 2024 at 06:49:59PM +0300 schrieb claudiu beznea:
>>>>> Hi, Alexander,
>>>>>
>>>>> On 28.08.2024 09:55, Alexander Dahl wrote:
>>>>>> Hello Claudiu,
>>>>>>
>>>>>> Am Fri, Aug 23, 2024 at 05:29:44PM +0300 schrieb claudiu beznea:
>>>>>>>
>>>>>>>
>>>>>>> On 20.08.2024 15:17, Alexander Dahl wrote:
>>>>>>>> By chance: I don't have a sama7g5 based board at hand for testing.
>>>>>>>> The datasheet says the same as for sam9x60.
>>>>>>>> Does the nvmem_microchip_otpc driver actually work without timeout on
>>>>>>>> sama7g5?
>>>>>>>
>>>>>>> Yes! This should be because system bus is clocked from MCK0 (as mentioned
>>>>>>> in peripheral identifiers table) which is enabled by bootloader.
>>>>>>
>>>>>> Not sure I can follow.  Citing the SAMA7G5 datasheet section 30.4
>>>>>> (OTPC Product Dependencies):
>>>>>>
>>>>>>       "The OTPC is clocked through the Power Management Controller
>>>>>>       (PMC). The user must power on the main RC oscillator and enable
>>>>>>       the peripheral clock of the OTPC prior to reading or writing the
>>>>>>       OTP memory."
>>>>>
>>>>> I don't see this in [1]. Only:
>>>>>
>>>>> "The OTPC is clocked through the Power Management Controller (PMC), so the
>>>>> programmer must first to configure the PMC."
>>>>>
>>>>>   From this I got that it is about the MCK0 listed in table Table 8-11.
>>>>> Peripheral Identifiers.
>>>>>
>>>>> [1]
>>>>> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765A.pdf
>>>>
>>>> Well, this seems to be an older version revision A from 03/2022.
>>>> I have DS60001765B (revision B) from 12/2023 and got this here (note
>>>> the missing 'A' in the filename):
>>>>
>>>> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf
>>>
>>> This version clearly express your findings. The unknown now is the
>>> "peripheral clock" that need to be enabled along with the
>>> main_rc_oscillator. For that you may want to play around with PMC
>>> Peripheral Control Register, PMC peripheral clock status register and see
>>> if OTPC fails to work when disabling the peripheral clock with the OTPC ID
>>> as there is no information about peripheral clock for OTPC in the
>>> peripheral identifers table.
> 
> The SAM9X60 seems to be different here, than the SAMA7G5.
> 
> (I only have SAM9X60 here, I can not test on SAMA7G5.)
> 
> To make it work I did not enable or disable a certain PMC peripheral
> clocks on SAM9X60.  The peripheral ID for OTPC is 46 on SAM9X60, and
> in the Peripheral Identifiers table there's no checkmark under "PMC
> Clock Control".  The ID is also not part of the sam9x60 clock drivers.
> This tells me SAM9X60 does not need a PMC peripheral clock enabled for
> the OTPC to work and my experiments confirm this.  Enabling the main
> RC oscillator was sufficient.

The feedback that I have from our internal teams is that for all the 
products, the main RC oscillator, the OTPC peripheral clock and the MCKx 
clocks associated to OTP must be enabled.

I cannot tell why you don't experience this on your board. But probably 
reading from OTP and writing/updating/locking... operations could be 
fairly different in terms of clock requirements and (internal to OTPC + 
its associated memory) synchronisation between clock domains: so my 
advice is that, even though you can "use/read" OTP on sam9x60 without 
the other clocks, it's probably a bit fragile.

As a summary, in addition to RC oscillator, the peripheral identifier 
for OTP should be:
         SAM9X60 : 46
         SAM9X70 : 46
         SAMA7G54 : 67
         SAMA7D65 : 63
     and the associated MCK :
         SAM9X60 : MCK (needs a documentation update)
         SAM9X70 : MCK
         SAMA7G54 : MCK0
         SAMA7D65 : MCK0

Basically the datasheet for sam9x60 hasn't been updated too recently and 
the same sentence as the one you noticed hereunder, on latest versions 
of sama7g5/sam9x7 datasheet, applies as well: "The user must power on 
the main RC oscillator and enable the peripheral clock of the OTPC prior 
to reading or writing the OTP memory".
Note that internal documentation update request is entered in our system 
thanks to your feedback.

>>> Hope this helps.
>>
>> FYI, I asked internally. I'll keep you posted.
> 
> Thanks Nicolas, I appreciate this.

Thanks to you and Claudiu for digging into this.

Best regards,
   Nicolas

>>>> Linked here:
>>>>
>>>> https://www.microchip.com/en-us/product/sama7g54
>>>>
>>>> The revision history is not very specific, it only says "Updated Power
>>>> Management".  Errata sheet has nothing interesting on that topic.
>>>>
>>>> We both cited what we saw in the datasheets.  Revision A has the
>>>> section you cited, revision B has the section I cited.
>>>>
>>>>>> Table from section 8.5 (Peripheral Clocks …) has no check mark at "PMC
>>>>>> clock control" but indeed lists MCK0 as main system bus clock.
>>>>>
>>>>> This is what I was taking about.
>>>>>
>>>>>>    If it
>>>>>> works on SAMA7G5 without explicitly enabling main RC oscillator, then
>>>>>> either that clock is on accidentally, or the datasheet is wrong in the
>>>>>> OTPC section.
>>>>>
>>>>> Might be.
>>>>
>>>> I don't have a SAMA7G5 at hand.  Someone who has could test if OTPC
>>>> works with/without MCK0, and with/without main RC osc, all possible
>>>> combinations would be most helpful: with none of those, with only one,
>>>> only the other, both.
>>>>
>>>> Hope we get this clock stuff sorted out?!
>>>>
>>>> Greets
>>>> Alex
>>>>
>>>>>
>>>>> Thank you,
>>>>> Claudiu Beznea
>>>>>
>>>>>>
>>>>>> Personally I find the "clocked through PMC" part in the OTPC
>>>>>> section suspicious, because in the peripheral identifiers table OTPC
>>>>>> has no "PMC Clock Control" mark.
>>>>>>
>>>>>> Not sure what's the difference between SAM9X60 and SAMA7G5 internally,
>>>>>> though.  From a user's POV it's possible one of them requires the
>>>>>> main RC osc, and the other does not, but currently you can't tell from
>>>>>> the datasheets.
>>>>>>
>>>>>>> Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and
>>>>>>> thermal calibration packets:
>>>>>>> https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq
>>>>>>
>>>>>> Greets
>>>>>> Alex
>>>>>>
>>>>>
>>
>>