Clock configuration for the SAMA5D2 NAND controller

Clock configuration for the SAMA5D2 NAND controller

[Romain Izard]

Hello,

While evaluating a new flash memory chip for my product based on a SAMA5D2
chip, I tried to update my software to use the latest device tree bindings.

Until now, I was using the legacy bindings for the NAND controller, that
preserved the timings configured by the bootloader in the EBI registers. The
bindings introduced in Linux 4.13 are used together with the NAND driver to
reconfigure the timings of the memory interface to match the speed profile
declared by some NAND components.

However, when comparing the timings in the registers, there was a large
difference between what I calculated by hand in the past and the values
configured by the drivers. The difference was in fact a 2 factor.

For me, the issue is due to the clock configuration declared in the SAMA5D2
device tree: The reference clock used by the nand-controller driver is the
clock for its parent node, which is directly the Master Clock. And on my
end, what I understood when writing the clock settings for my bootloader was
that the reference clock was the HSMC clock, which derives from the H32MX
clock, which runs at half the rate of the Master Clock.

The documentation for the SAMA5D2 is not very precise on this topic, so I
would like to have some feedback. Is the clock used as a reference for the
chip select configuration registers the Master Clock itself, or is it the
peripheral clock for the HSMC module ?


Best regards,
-- 
Romain Izard

Re: Clock configuration for the SAMA5D2 NAND controller

[Romain Izard]

+linux-mtd, linux-clk

Le mer. 10 oct. 2018 à 19:05, Romain Izard
<romain.izard.pro@gmail.com> a écrit :
>
> Hello,
>
> While evaluating a new flash memory chip for my product based on a SAMA5D2
> chip, I tried to update my software to use the latest device tree bindings.
>
> Until now, I was using the legacy bindings for the NAND controller, that
> preserved the timings configured by the bootloader in the EBI registers. The
> bindings introduced in Linux 4.13 are used together with the NAND driver to
> reconfigure the timings of the memory interface to match the speed profile
> declared by some NAND components.
>
> However, when comparing the timings in the registers, there was a large
> difference between what I calculated by hand in the past and the values
> configured by the drivers. The difference was in fact a 2 factor.
>
> For me, the issue is due to the clock configuration declared in the SAMA5D2
> device tree: The reference clock used by the nand-controller driver is the
> clock for its parent node, which is directly the Master Clock. And on my
> end, what I understood when writing the clock settings for my bootloader was
> that the reference clock was the HSMC clock, which derives from the H32MX
> clock, which runs at half the rate of the Master Clock.
>
> The documentation for the SAMA5D2 is not very precise on this topic, so I
> would like to have some feedback. Is the clock used as a reference for the
> chip select configuration registers the Master Clock itself, or is it the
> peripheral clock for the HSMC module ?
>
>
> Best regards,
> --
> Romain Izard

Clock configuration for the SAMA5D2 NAND controller

[Romain Izard]

+linux-mtd, linux-clk

Le mer. 10 oct. 2018 ? 19:05, Romain Izard
<romain.izard.pro@gmail.com> a ?crit :
>
> Hello,
>
> While evaluating a new flash memory chip for my product based on a SAMA5D2
> chip, I tried to update my software to use the latest device tree bindings.
>
> Until now, I was using the legacy bindings for the NAND controller, that
> preserved the timings configured by the bootloader in the EBI registers. The
> bindings introduced in Linux 4.13 are used together with the NAND driver to
> reconfigure the timings of the memory interface to match the speed profile
> declared by some NAND components.
>
> However, when comparing the timings in the registers, there was a large
> difference between what I calculated by hand in the past and the values
> configured by the drivers. The difference was in fact a 2 factor.
>
> For me, the issue is due to the clock configuration declared in the SAMA5D2
> device tree: The reference clock used by the nand-controller driver is the
> clock for its parent node, which is directly the Master Clock. And on my
> end, what I understood when writing the clock settings for my bootloader was
> that the reference clock was the HSMC clock, which derives from the H32MX
> clock, which runs at half the rate of the Master Clock.
>
> The documentation for the SAMA5D2 is not very precise on this topic, so I
> would like to have some feedback. Is the clock used as a reference for the
> chip select configuration registers the Master Clock itself, or is it the
> peripheral clock for the HSMC module ?
>
>
> Best regards,
> --
> Romain Izard

Clock configuration for the SAMA5D2 NAND controller

[Boris Brezillon]

Hi Romain,

On Wed, 10 Oct 2018 19:05:06 +0200
Romain Izard <romain.izard.pro@gmail.com> wrote:

> Hello,
> 
> While evaluating a new flash memory chip for my product based on a SAMA5D2
> chip, I tried to update my software to use the latest device tree bindings.
> 
> Until now, I was using the legacy bindings for the NAND controller, that
> preserved the timings configured by the bootloader in the EBI registers. The
> bindings introduced in Linux 4.13 are used together with the NAND driver to
> reconfigure the timings of the memory interface to match the speed profile
> declared by some NAND components.
> 
> However, when comparing the timings in the registers, there was a large
> difference between what I calculated by hand in the past and the values
> configured by the drivers. The difference was in fact a 2 factor.

Is it 2 times slower or 2 times faster with the new approach? Is the
new calculation providing a working solution, or do you have data
corruption because of that? Is your NAND ONFI compliant?

> 
> For me, the issue is due to the clock configuration declared in the SAMA5D2
> device tree: The reference clock used by the nand-controller driver is the
> clock for its parent node, which is directly the Master Clock. And on my
> end, what I understood when writing the clock settings for my bootloader was
> that the reference clock was the HSMC clock, which derives from the H32MX
> clock, which runs at half the rate of the Master Clock.

Hm, it's probably based on the clock driving the EBI/SMC logic.

> 
> The documentation for the SAMA5D2 is not very precise on this topic, so I
> would like to have some feedback. Is the clock used as a reference for the
> chip select configuration registers the Master Clock itself, or is it the
> peripheral clock for the HSMC module ?

I'd say the periph clock driving the HSMC module, but I'm not sure.

Nicolas, Tudor, can you help us with that?

Thanks,

Boris

Clock configuration for the SAMA5D2 NAND controller

[Romain Izard]

Le mer. 17 oct. 2018 ? 14:38, Boris Brezillon
<boris.brezillon@bootlin.com> a ?crit :
>
> Hi Romain,
>
> On Wed, 10 Oct 2018 19:05:06 +0200
> Romain Izard <romain.izard.pro@gmail.com> wrote:
>
> > Hello,
> >
> > While evaluating a new flash memory chip for my product based on a SAMA5D2
> > chip, I tried to update my software to use the latest device tree bindings.
> >
> > Until now, I was using the legacy bindings for the NAND controller, that
> > preserved the timings configured by the bootloader in the EBI registers. The
> > bindings introduced in Linux 4.13 are used together with the NAND driver to
> > reconfigure the timings of the memory interface to match the speed profile
> > declared by some NAND components.
> >
> > However, when comparing the timings in the registers, there was a large
> > difference between what I calculated by hand in the past and the values
> > configured by the drivers. The difference was in fact a 2 factor.
>
> Is it 2 times slower or 2 times faster with the new approach? Is the
> new calculation providing a working solution, or do you have data
> corruption because of that? Is your NAND ONFI compliant?
>
- The number of clock cycles for each configured timing is larger, so the
access times are slower.
- No obvious problem has been observed during my limited testing. It
is possible to read and write on the Flash.
- This is with an ONFI compilant flash, that claims to support timing
modes from 0 to 4.

> > For me, the issue is due to the clock configuration declared in the SAMA5D2
> > device tree: The reference clock used by the nand-controller driver is the
> > clock for its parent node, which is directly the Master Clock. And on my
> > end, what I understood when writing the clock settings for my bootloader was
> > that the reference clock was the HSMC clock, which derives from the H32MX
> > clock, which runs at half the rate of the Master Clock.
>
> Hm, it's probably based on the clock driving the EBI/SMC logic.
>
> >
> > The documentation for the SAMA5D2 is not very precise on this topic, so I
> > would like to have some feedback. Is the clock used as a reference for the
> > chip select configuration registers the Master Clock itself, or is it the
> > peripheral clock for the HSMC module ?
>
> I'd say the periph clock driving the HSMC module, but I'm not sure.
>
> Nicolas, Tudor, can you help us with that?

Best regards,
-- 
Romain Izard

Clock configuration for the SAMA5D2 NAND controller

[Boris Brezillon]

On Wed, 17 Oct 2018 14:49:27 +0200
Romain Izard <romain.izard.pro@gmail.com> wrote:

> Le mer. 17 oct. 2018 ? 14:38, Boris Brezillon
> <boris.brezillon@bootlin.com> a ?crit :
> >
> > Hi Romain,
> >
> > On Wed, 10 Oct 2018 19:05:06 +0200
> > Romain Izard <romain.izard.pro@gmail.com> wrote:
> >  
> > > Hello,
> > >
> > > While evaluating a new flash memory chip for my product based on a SAMA5D2
> > > chip, I tried to update my software to use the latest device tree bindings.
> > >
> > > Until now, I was using the legacy bindings for the NAND controller, that
> > > preserved the timings configured by the bootloader in the EBI registers. The
> > > bindings introduced in Linux 4.13 are used together with the NAND driver to
> > > reconfigure the timings of the memory interface to match the speed profile
> > > declared by some NAND components.
> > >
> > > However, when comparing the timings in the registers, there was a large
> > > difference between what I calculated by hand in the past and the values
> > > configured by the drivers. The difference was in fact a 2 factor.  
> >
> > Is it 2 times slower or 2 times faster with the new approach? Is the
> > new calculation providing a working solution, or do you have data
> > corruption because of that? Is your NAND ONFI compliant?
> >  
> - The number of clock cycles for each configured timing is larger, so the
> access times are slower.

Okay. When calculating the timings by hand, what was reference freq you
used? Did you compare it to the clk freq we have when the NAND
controller driver tweaks the timings?

> - No obvious problem has been observed during my limited testing. It
> is possible to read and write on the Flash.

That's not surprising if it's running slower than what can actually be
achieved.

> - This is with an ONFI compilant flash, that claims to support timing
> modes from 0 to 4.

Okay. We don't support EDO modes [1], so mode 4 should be rejected. Did
you base your hand-made calculation on mode 3 or 4?

[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/nand/raw/atmel/nand-controller.c#L1205

Clock configuration for the SAMA5D2 NAND controller

[Romain Izard]

Le mer. 17 oct. 2018 ? 15:03, Boris Brezillon <boris.brezillon@bootlin.com>
a ?crit :
>
> On Wed, 17 Oct 2018 14:49:27 +0200 Romain Izard
> <romain.izard.pro@gmail.com> wrote:
>
> > Le mer. 17 oct. 2018 ? 14:38, Boris Brezillon
> > <boris.brezillon@bootlin.com> a ?crit :
> > >
[...]
> > >
> > > Is it 2 times slower or 2 times faster with the new approach? Is the
> > > new calculation providing a working solution, or do you have data
> > > corruption because of that? Is your NAND ONFI compliant?
> > >
> > - The number of clock cycles for each configured timing is larger, so
> > the access times are slower.
>
> Okay. When calculating the timings by hand, what was reference freq you
> used? Did you compare it to the clk freq we have when the NAND controller
> driver tweaks the timings?
>
I know that I did the calculations with a 83 MHz clock, but that the kernel
code used a 166 MHz clock instead. The only question is to know whether it
is me or the existing code that is right.

> > - No obvious problem has been observed during my limited testing. It is
> > possible to read and write on the Flash.
>
> That's not surprising if it's running slower than what can actually be
> achieved.
>
> > - This is with an ONFI compilant flash, that claims to support timing
> > modes from 0 to 4.
>
> Okay. We don't support EDO modes [1], so mode 4 should be rejected. Did
> you base your hand-made calculation on mode 3 or 4?
>
> [1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/nand/raw/atmel/nand-controller.c#L1205

As I initially calculated the timings for a SDR toggle-mode NAND, there no
timing mode to use. And the datasheet for the ONFI chip used as a first
replacement was more permissive than the original model, so I continued with
the original timings.

In the end, I'm asking these questions because I cannot access the signals
for my memory chip. Otherwise, I would just verify the duration of the
pulses on the bus.

If I get a confirmation on the subject, I can then propose a patch to fix
the SAMA5D2 device tree to use the correct clock.

Best regards,
--
Romain Izard

Clock configuration for the SAMA5D2 NAND controller

[Boris Brezillon]

On Wed, 17 Oct 2018 15:36:17 +0200
Romain Izard <romain.izard.pro@gmail.com> wrote:

> Le mer. 17 oct. 2018 ? 15:03, Boris Brezillon <boris.brezillon@bootlin.com>
> a ?crit :
> >
> > On Wed, 17 Oct 2018 14:49:27 +0200 Romain Izard
> > <romain.izard.pro@gmail.com> wrote:
> >  
> > > Le mer. 17 oct. 2018 ? 14:38, Boris Brezillon
> > > <boris.brezillon@bootlin.com> a ?crit :  
> > > >  
> [...]
> > > >
> > > > Is it 2 times slower or 2 times faster with the new approach? Is the
> > > > new calculation providing a working solution, or do you have data
> > > > corruption because of that? Is your NAND ONFI compliant?
> > > >  
> > > - The number of clock cycles for each configured timing is larger, so
> > > the access times are slower.  
> >
> > Okay. When calculating the timings by hand, what was reference freq you
> > used? Did you compare it to the clk freq we have when the NAND controller
> > driver tweaks the timings?
> >  
> I know that I did the calculations with a 83 MHz clock, but that the kernel
> code used a 166 MHz clock instead. The only question is to know whether it
> is me or the existing code that is right.

Actually, if you have a test point on the RE pin, there's an easy way
to know who's right: check the freq on RE and compare it to what you
expect it to be.

Re: Clock configuration for the SAMA5D2 NAND controller

[Miquel Raynal]

Hi Romain,

Romain Izard <romain.izard.pro@gmail.com> wrote on Wed, 17 Oct 2018
12:42:28 +0200:

> +linux-mtd, linux-clk
> 
> Le mer. 10 oct. 2018 à 19:05, Romain Izard
> <romain.izard.pro@gmail.com> a écrit :
> >
> > Hello,
> >
> > While evaluating a new flash memory chip for my product based on a SAMA5D2
> > chip, I tried to update my software to use the latest device tree bindings.
> >
> > Until now, I was using the legacy bindings for the NAND controller, that
> > preserved the timings configured by the bootloader in the EBI registers. The
> > bindings introduced in Linux 4.13 are used together with the NAND driver to
> > reconfigure the timings of the memory interface to match the speed profile
> > declared by some NAND components.
> >
> > However, when comparing the timings in the registers, there was a large
> > difference between what I calculated by hand in the past and the values
> > configured by the drivers. The difference was in fact a 2 factor.
> >
> > For me, the issue is due to the clock configuration declared in the SAMA5D2
> > device tree: The reference clock used by the nand-controller driver is the
> > clock for its parent node, which is directly the Master Clock. And on my
> > end, what I understood when writing the clock settings for my bootloader was
> > that the reference clock was the HSMC clock, which derives from the H32MX
> > clock, which runs at half the rate of the Master Clock.
> >
> > The documentation for the SAMA5D2 is not very precise on this topic, so I
> > would like to have some feedback. Is the clock used as a reference for the
> > chip select configuration registers the Master Clock itself, or is it the
> > peripheral clock for the HSMC module ?
> >

FYI I had the same issue on the Marvell NAND controller: the actual
frequency of the controller clock was half of the "parent" clock
retrieved by clk_get_rate(), hence I needed to double the clock period
for the timings derivation in ->setup_data_interface().

If you can't get more feedback from SAMA5 people and if this works for
you, please send a patch with a nice comment.


Thanks,
Miquèl

Clock configuration for the SAMA5D2 NAND controller

[Miquel Raynal]

Hi Romain,

Romain Izard <romain.izard.pro@gmail.com> wrote on Wed, 17 Oct 2018
12:42:28 +0200:

> +linux-mtd, linux-clk
> 
> Le mer. 10 oct. 2018 ? 19:05, Romain Izard
> <romain.izard.pro@gmail.com> a ?crit :
> >
> > Hello,
> >
> > While evaluating a new flash memory chip for my product based on a SAMA5D2
> > chip, I tried to update my software to use the latest device tree bindings.
> >
> > Until now, I was using the legacy bindings for the NAND controller, that
> > preserved the timings configured by the bootloader in the EBI registers. The
> > bindings introduced in Linux 4.13 are used together with the NAND driver to
> > reconfigure the timings of the memory interface to match the speed profile
> > declared by some NAND components.
> >
> > However, when comparing the timings in the registers, there was a large
> > difference between what I calculated by hand in the past and the values
> > configured by the drivers. The difference was in fact a 2 factor.
> >
> > For me, the issue is due to the clock configuration declared in the SAMA5D2
> > device tree: The reference clock used by the nand-controller driver is the
> > clock for its parent node, which is directly the Master Clock. And on my
> > end, what I understood when writing the clock settings for my bootloader was
> > that the reference clock was the HSMC clock, which derives from the H32MX
> > clock, which runs at half the rate of the Master Clock.
> >
> > The documentation for the SAMA5D2 is not very precise on this topic, so I
> > would like to have some feedback. Is the clock used as a reference for the
> > chip select configuration registers the Master Clock itself, or is it the
> > peripheral clock for the HSMC module ?
> >

FYI I had the same issue on the Marvell NAND controller: the actual
frequency of the controller clock was half of the "parent" clock
retrieved by clk_get_rate(), hence I needed to double the clock period
for the timings derivation in ->setup_data_interface().

If you can't get more feedback from SAMA5 people and if this works for
you, please send a patch with a nice comment.


Thanks,
Miqu?l

Clock configuration for the SAMA5D2 NAND controller

[Tudor.Ambarus at microchip.com]

Hi, Romain,

On 10/10/2018 08:05 PM, Romain Izard wrote:
> Hello,
> 
> While evaluating a new flash memory chip for my product based on a SAMA5D2
> chip, I tried to update my software to use the latest device tree bindings.
> 
> Until now, I was using the legacy bindings for the NAND controller, that
> preserved the timings configured by the bootloader in the EBI registers. The
> bindings introduced in Linux 4.13 are used together with the NAND driver to
> reconfigure the timings of the memory interface to match the speed profile
> declared by some NAND components.
> 
> However, when comparing the timings in the registers, there was a large
> difference between what I calculated by hand in the past and the values
> configured by the drivers. The difference was in fact a 2 factor.
> 
> For me, the issue is due to the clock configuration declared in the SAMA5D2
> device tree: The reference clock used by the nand-controller driver is the
> clock for its parent node, which is directly the Master Clock. And on my
> end, what I understood when writing the clock settings for my bootloader was
> that the reference clock was the HSMC clock, which derives from the H32MX
> clock, which runs at half the rate of the Master Clock.
> 
> The documentation for the SAMA5D2 is not very precise on this topic, so I
> would like to have some feedback. Is the clock used as a reference for the
> chip select configuration registers the Master Clock itself, or is it the
> peripheral clock for the HSMC module ?
> 

I would say that it's the HSMC peripheral clock because it's the only clock that
we describe for HSMC. If this is the case, then we will need to know the
derivation formula used by the Peripheral Clock Controller to derive the MCK2
(AHB 32-bit MATRIX system) clock to Periph_clk[17] HCLOCK_LS (HSMC), in order to
correctly configure the timings to match flashes capabilities.

I asked the hardware team for a clarification, will get back to you soon.

Thanks for your patience,
ta

Clock configuration for the SAMA5D2 NAND controller

[Tudor.Ambarus at microchip.com]

Hi, Romain,

On 11/14/2018 03:45 PM, Tudor Ambarus wrote:
> Hi, Romain,
> 
> On 10/10/2018 08:05 PM, Romain Izard wrote:
>> Hello,
>>
>> While evaluating a new flash memory chip for my product based on a SAMA5D2
>> chip, I tried to update my software to use the latest device tree bindings.
>>
>> Until now, I was using the legacy bindings for the NAND controller, that
>> preserved the timings configured by the bootloader in the EBI registers. The
>> bindings introduced in Linux 4.13 are used together with the NAND driver to
>> reconfigure the timings of the memory interface to match the speed profile
>> declared by some NAND components.
>>
>> However, when comparing the timings in the registers, there was a large
>> difference between what I calculated by hand in the past and the values
>> configured by the drivers. The difference was in fact a 2 factor.
>>
>> For me, the issue is due to the clock configuration declared in the SAMA5D2
>> device tree: The reference clock used by the nand-controller driver is the
>> clock for its parent node, which is directly the Master Clock. And on my
>> end, what I understood when writing the clock settings for my bootloader was
>> that the reference clock was the HSMC clock, which derives from the H32MX
>> clock, which runs at half the rate of the Master Clock.
>>
>> The documentation for the SAMA5D2 is not very precise on this topic, so I
>> would like to have some feedback. Is the clock used as a reference for the
>> chip select configuration registers the Master Clock itself, or is it the
>> peripheral clock for the HSMC module ?
>>
> 
> I would say that it's the HSMC peripheral clock because it's the only clock that

The hardware team confirmed that the timings are based on MCK which is MCK/2.
The periph_clk is MCK/2 as well, but used to clock the logic of the IP.

The HSMC receives a AHB clock HCLOCK_LS (MCK/2) used to generate the timings and
a PCLOCK_LS used to clock the HSMC/NFC logic.


> we describe for HSMC. If this is the case, then we will need to know the
> derivation formula used by the Peripheral Clock Controller to derive the MCK2
> (AHB 32-bit MATRIX system) clock to Periph_clk[17] HCLOCK_LS (HSMC), in order to
> correctly configure the timings to match flashes capabilities.

I assumed that the on/off box from the Peripheral Clock Controller described at
33.3 Block Diagram implies some derivation formula. I was wrong, the on/off box
is there just to gate the clocks going to the peripherals.

Cheers,
ta

Clock configuration for the SAMA5D2 NAND controller

[Romain Izard]

Le mar. 20 nov. 2018 ? 12:28, <Tudor.Ambarus@microchip.com> a ?crit :
>
> Hi, Romain,
>
> On 11/14/2018 03:45 PM, Tudor Ambarus wrote:
> > Hi, Romain,
> >
> > On 10/10/2018 08:05 PM, Romain Izard wrote:
> >> Hello,
> >>
> >> While evaluating a new flash memory chip for my product based on a SAMA5D2
> >> chip, I tried to update my software to use the latest device tree bindings.
> >>
> >> Until now, I was using the legacy bindings for the NAND controller, that
> >> preserved the timings configured by the bootloader in the EBI registers. The
> >> bindings introduced in Linux 4.13 are used together with the NAND driver to
> >> reconfigure the timings of the memory interface to match the speed profile
> >> declared by some NAND components.
> >>
> >> However, when comparing the timings in the registers, there was a large
> >> difference between what I calculated by hand in the past and the values
> >> configured by the drivers. The difference was in fact a 2 factor.
> >>
> >> For me, the issue is due to the clock configuration declared in the SAMA5D2
> >> device tree: The reference clock used by the nand-controller driver is the
> >> clock for its parent node, which is directly the Master Clock. And on my
> >> end, what I understood when writing the clock settings for my bootloader was
> >> that the reference clock was the HSMC clock, which derives from the H32MX
> >> clock, which runs at half the rate of the Master Clock.
> >>
> >> The documentation for the SAMA5D2 is not very precise on this topic, so I
> >> would like to have some feedback. Is the clock used as a reference for the
> >> chip select configuration registers the Master Clock itself, or is it the
> >> peripheral clock for the HSMC module ?
> >>
> >
> > I would say that it's the HSMC peripheral clock because it's the only clock that
>
> The hardware team confirmed that the timings are based on MCK which is MCK/2.
> The periph_clk is MCK/2 as well, but used to clock the logic of the IP.
>
> The HSMC receives a AHB clock HCLOCK_LS (MCK/2) used to generate the timings and
> a PCLOCK_LS used to clock the HSMC/NFC logic.
>
>
> > we describe for HSMC. If this is the case, then we will need to know the
> > derivation formula used by the Peripheral Clock Controller to derive the MCK2
> > (AHB 32-bit MATRIX system) clock to Periph_clk[17] HCLOCK_LS (HSMC), in order to
> > correctly configure the timings to match flashes capabilities.
>
> I assumed that the on/off box from the Peripheral Clock Controller described at
> 33.3 Block Diagram implies some derivation formula. I was wrong, the on/off box
> is there just to gate the clocks going to the peripherals.

Ok, I will send a fix.

Best regards,
-- 
Romain Izard