menu "SPINOR Devices"

config DRIVERS_SPINOR
    bool "enable spinor driver"
        default y

config HAL_TEST_SPINOR
    bool "enable spinor hal APIs test command"
    depends on DRIVERS_SPINOR
        default n

config DRIVERS_SPINOR_FREQ
    int "spinor frequency (MHz)"
    depends on DRIVERS_SPINOR
    range 10 100
    default 50
    help
      The frequency for spi master.

config DRIVERS_SPINOR_4K_SECTORS
    bool "Use small 4096 B erase sectors"
    depends on DRIVERS_SPINOR
    default y
    help
      This only tells the upper layer that the block size is 4K and the upper
      layer can do 4K erase. In fact, the driver still supports 32K or 64K
      erase and it may try to do 64K or 32K erase as far as possible if you
      enable cache since it does really improve performance. Erasing should be
      mush faster when using 64K block instead of 16 * 4K.

      Why we should need this option? Even most filesystems save a file in
      unit block, which is equal to nor block size generally. The larger block
      is, the much space waste for a small file. Take an example, to save a 1K
      size file, the filesystem allocate a block for it and waste 3K size
      for 4K block size, even 63K size for 64K block size.

      To balance waste-space and performance, we really support to eanble
      4K block and nor cache to get more operations together.

      If unsure, please says Y.

config DRIVERS_SPINOR_CACHE
    bool "Enable spinor cache layer"
    depends on DRIVERS_SPINOR
    default n
    help
      To improve write performance by merging 4K page erase operation to
      32K/64K erase operation. This cache layer holds a 64K buffer. It just
      will cache sequential erase/write operation. There are three ways to
      flush cache.

      1. block buffer is fullly.
      2. operate over a block.
         Once operate over a 64K block, this layer will write-back directly
         avoiding lose data.
      3. upper layer call hal_spinor_sync()

      This cache layer with the littlefs turns out no loss of data, but the
      others need more tested. The upper layer (fs) should takes care of the
      following issues.

      1. after writing meta data, upper must call hal_spinor_sync() to flush
         cache. Also, you can flush cache for fatal data too. In a word,
         sync() is called only immediately after data that affects filesystem
         consistency is written. The littlefs is checked ok.
      2. contecting to sync()/fsync() for user in case of user codes writing
         fatal file.

      If unsure, please says N.

config DRIVERS_SPINOR_WRITE_LOCK
    bool "Use nor dynamic write limit if support"
    depends on DRIVERS_SPINOR
    default y
    help
      Some nor flash support write protection. This feature is much usefull
      for power lose case to avoid data corruption. Most of them support zone
      protection, which cost much for status register and to protect
      a continuous space from head or tail. That's NOT what we need. What this
      option used, is individual block protection. Before we do write/erase
      operation, we unlock (unprotect) the individual block we want and still
      protect other blocks. As you see, the unit to lock/unlock is a block.
      Beside, it just rewrite a volatile memory, not status register, which
      has less time and wear costs.

      In a word, It spends very little time to protect data if power lose.

      If unsure, please says Y.

endmenu