All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Christophe Kerello <christophe.kerello@st.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>, <richard@nod.at>,
	<dwmw2@infradead.org>, <computersforpeace@gmail.com>,
	<marek.vasut@gmail.com>, <robh+dt@kernel.org>,
	<mark.rutland@arm.com>, <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>
Subject: Re: [PATCH 1/3] dt-bindings: mtd: stm32_fmc2: add STM32 FMC2 NAND controller documentation
Date: Mon, 24 Sep 2018 19:17:25 +0200	[thread overview]
Message-ID: <20180924191725.2439fd10@bbrezillon> (raw)
In-Reply-To: <c9925c9c-af40-8044-8dbe-866fbe3a2f99@st.com>

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.

Regards,

Boris

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Christophe Kerello <christophe.kerello@st.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	richard@nod.at, dwmw2@infradead.org, computersforpeace@gmail.com,
	marek.vasut@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH 1/3] dt-bindings: mtd: stm32_fmc2: add STM32 FMC2 NAND controller documentation
Date: Mon, 24 Sep 2018 19:17:25 +0200	[thread overview]
Message-ID: <20180924191725.2439fd10@bbrezillon> (raw)
In-Reply-To: <c9925c9c-af40-8044-8dbe-866fbe3a2f99@st.com>

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.

Regards,

Boris

  reply	other threads:[~2018-09-24 17:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 15:47 [PATCH 0/3] mtd: rawnand: add STM32 FMC2 NAND flash controller driver christophe.kerello
2018-09-17 15:47 ` christophe.kerello
2018-09-17 15:47 ` [PATCH 1/3] dt-bindings: mtd: stm32_fmc2: add STM32 FMC2 NAND controller documentation christophe.kerello
2018-09-17 15:47   ` christophe.kerello
2018-09-22  8:34   ` Miquel Raynal
2018-09-22  8:34     ` Miquel Raynal
2018-09-24 16:36     ` Christophe Kerello
2018-09-24 16:36       ` Christophe Kerello
2018-09-24 17:17       ` Boris Brezillon [this message]
2018-09-24 17:17         ` Boris Brezillon
2018-09-25  9:14         ` Christophe Kerello
2018-09-25  9:14           ` Christophe Kerello
2018-09-17 15:47 ` [PATCH 2/3] mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver christophe.kerello
2018-09-17 15:47   ` christophe.kerello
2018-09-17 17:05   ` kbuild test robot
2018-09-17 17:05     ` kbuild test robot
2018-09-17 17:32   ` kbuild test robot
2018-09-17 17:32     ` kbuild test robot
2018-09-22 13:48   ` Miquel Raynal
2018-09-22 13:48     ` Miquel Raynal
2018-09-24 16:36     ` Christophe Kerello
2018-09-24 16:36       ` Christophe Kerello
2018-09-24 17:26       ` Boris Brezillon
2018-09-24 17:26         ` Boris Brezillon
2018-10-29  9:22       ` Miquel Raynal
2018-10-29  9:22         ` Miquel Raynal
2018-09-23 11:34   ` Miquel Raynal
2018-09-23 11:34     ` Miquel Raynal
2018-09-24 16:36     ` Christophe Kerello
2018-09-24 16:36       ` Christophe Kerello
2018-09-24 17:23   ` Boris Brezillon
2018-09-24 17:23     ` Boris Brezillon
2018-09-25  9:14     ` Christophe Kerello
2018-09-25  9:14       ` Christophe Kerello
2018-09-17 15:47 ` [PATCH 3/3] mtd: rawnand: stm32_fmc2: add manual mode christophe.kerello
2018-09-17 15:47   ` christophe.kerello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180924191725.2439fd10@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=christophe.kerello@st.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=marek.vasut@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.