lkml.org 
[lkml]   [2018]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/3] dt-bindings: mtd: stm32_fmc2: add STM32 FMC2 NAND controller documentation
From
Date
Hi Boris,

On 09/24/2018 07:17 PM, Boris Brezillon wrote:
> Hi Christophe,
>
> On Mon, 24 Sep 2018 18:36:27 +0200
> Christophe Kerello <christophe.kerello@st.com> wrote:
>
>>>> +- st,fmc2_timings: array of 8 bytes for NAND timings. The meanings of
>>>> + these bytes are:
>>>> + byte 0 TCLR : CLE to RE delay in number of AHB clock cycles, only 4 bits
>>>> + are valid. Zero means one clock cycle, 15 means 16 clock
>>>> + cycles.
>>>> + byte 1 TAR : ALE to RE delay, 4 bits are valid. Same format as TCLR.
>>>> + byte 2 THIZ : number of HCLK clock cycles during which the data bus is
>>>> + kept in Hi-Z (tristate) after the start of a write access.
>>>> + Only valid for write transactions. Zero means 1 cycle,
>>>> + 255 means 256 cycles.
>>>> + byte 3 TWAIT : number of HCLK clock cycles to assert the command to the
>>>> + NAND flash in response to SMWAITn. Zero means 1 cycle,
>>>> + 255 means 256 cycles.
>>>> + byte 4 THOLD_MEM : common memory space timing
>>>> + number of HCLK clock cycles to hold the address (and data
>>>> + when writing) after the command deassertion. Zero means
>>>> + 1 cycle, 255 means 256 cycles.
>>>> + byte 5 TSET_MEM : common memory space timing
>>>> + number of HCLK clock cycles to assert the address before
>>>> + the command is asserted. Zero means 1 cycle, 255 means 256
>>>> + cycles.
>>>> + byte 6 THOLD_ATT : attribute memory space timing
>>>> + number of HCLK clock cycles to hold the address (and data
>>>> + when writing) after the command deassertion. Zero means
>>>> + 1 cycle, 255 means 256 cycles.
>>>> + byte 7 TSET_ATT : attribute memory space timing
>>>> + number of HCLK clock cycles to assert the address before
>>>> + the command is asserted. Zero means 1 cycle, 255 means 256
>>>> + cycles.
>>>
>>> Let me review the driver but this array of timings is really
>>> suspicious. I am pretty sure you don't need it in the DT.
>>
>> "st,fmc2-timings" is an optional property that allow the end user to
>> overwrite the timings calculated by setup_data_interface callback. By
>> setting this property in the NAND flash memory device tree node, the end
>> user could have a better throughput. For NON ONFI SLC NAND, timing mode
>> 0 is often used.
>
> Exactly the kind of tweaking I'd like to avoid. If the NAND is not ONFI,
> the vendor driver (nand_<manufacturer>.c) can overwrite
> chip->default_onfi_timing_mode, and if the ONFI timings modes are not
> exactly matching the NAND spec and you need the exact timings, then we
> should consider adding a manufacturer hook to let the manufacturer
> driver tweak the timings. In any case, I'm not willing to accept
> timings description in the DT.
>

Ok, I understand the way it should work. This property will be removed
from the device tree bindings and the timings will be only calculated by
calling setup_data_interface callback in the driver.

Regards,
Christophe Kerello.

> Regards,
>
> Boris
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>

\
 
 \ /
  Last update: 2018-09-25 11:15    [W:0.050 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site