All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jagan Teki <jagan@amarulasolutions.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
Date: Sat, 15 Dec 2018 20:12:53 +0530	[thread overview]
Message-ID: <CAMty3ZAgfgBHuYpcw6NB_rQ5GSwp8sgjTGTQXo+10xwjfVauDA@mail.gmail.com> (raw)
In-Reply-To: <CAMty3ZDeyFXdaENn7T4Y_L_TtgVbEksKvudQixt-UDgJnmWdZQ@mail.gmail.com>

On Sat, Dec 15, 2018 at 7:29 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Fri, Dec 14, 2018 at 10:12 PM Vignesh R <vigneshr@ti.com> wrote:
> >
> > >>
> > >>     > 2) For BAR support, lets place it as it is and support via
> > > spi-nor
> > >>
> > >     >     Problem is, it not desirable to use BAR as default because its not
> > >     >     stateless and does not work with all flash parts. OTOH, it
> > >     seems like 4
> > >     >     byte addressing (stateless dedicated opcode or with enter/exit
> > >     4 byte
> > >     >     mode) seems to be standard.
> > >     >     Also, Linux doesn't support BAR and haven't seen any request
> > >     for BAR
> > >     >     support. Why support additional feature and burden of
> > >     maintaining when
> > >     >     it may not be needed.
> > >     >
> > >     >     But if you insist, I just have to add BAR support back.
> > >     >
> > >     >
> > >     > But if we do that, could we please have a config option so that I can
> > >     > somehow ensure only 4 byte opcoses are used that don't change some
> > >     state
> > >     > in the chip?
> > >     >
> > >
> > >     I am afraid BAR support would be the default as Jagan suggests not to
> > >     change existing behavior. You would have to disable SPI_FLASH_BAR to use
> > >     4 Byte addressing opcodes.
> > >
> > >
> > > Honestly, I don't like the idea of making BAR the default. Why can't we
> > > go the Linux way and enable BAR (maybe then as default) for boards that
> > > need it only?
> > >
> >
> > Jagan, would that be acceptable?
>
> Better way to have some controller flag to check we go with 3-byte or
> 4-byte addressing if flash > 16MiB. anyway let me give some time, will
> come back for the better to way to go this. ofcourse CONFIG would
> require if BAR handling code occupy more foot-print, but we have to
> enable based some controller indication.

another approach can be do some sanity transfer if the flash > 16MiB
with 4-byte addressing failure can lead to enable BAR.

  reply	other threads:[~2018-12-15 14:42 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 17:32 [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 01/16] spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 02/16] spi-mem: Claim SPI bus before spi mem access Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM Vignesh R
2018-12-12 20:25   ` Jagan Teki
2018-12-12 20:40     ` Boris Brezillon
2018-12-12 20:45       ` Jagan Teki
2018-12-12 21:02         ` Boris Brezillon
2018-12-12 21:07           ` Jagan Teki
2018-12-12 21:25             ` Boris Brezillon
2018-12-12 23:10               ` Jagan Teki
2018-12-12 23:20                 ` Tom Rini
2018-12-12 23:55                 ` Boris Brezillon
2018-12-14  9:59                   ` Jagan Teki
2019-01-04 21:28                     ` Simon Glass
2018-12-13  9:38               ` Vignesh R
2018-12-13  9:41                 ` Miquel Raynal
2018-12-13  8:50     ` Vignesh R
2018-12-14 10:02       ` Jagan Teki
2018-12-14 10:57         ` Vignesh R
2018-12-14 13:59           ` Jagan Teki
2019-01-28  6:57   ` Jagan Teki
2019-01-28  9:45     ` Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 04/16] sh: bitops: add hweight*() macros Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux Vignesh R
2018-12-12 20:31   ` Jagan Teki
2018-12-12 22:56     ` Tom Rini
2018-12-12 23:21       ` Jagan Teki
2018-12-13  3:01         ` Tom Rini
2018-12-13  7:47           ` Stefan Roese
2018-12-13 11:44           ` Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 06/16] mtd: spi: Switch to new SPI NOR framework Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 07/16] mtd: spi: Remove unused files Vignesh R
2018-12-12 20:38   ` Jagan Teki
2018-12-13  9:07     ` Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 08/16] mtd: spi: Add lightweight SPI flash stack for SPL Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 09/16] sf_mtd: Simply mtd operations Vignesh R
2018-12-12 20:31   ` Boris Brezillon
2018-12-13  2:11   ` Daniel Schwierzeck
2018-12-13  7:46   ` Stefan Roese
2018-12-13  8:24   ` Vignesh R
2018-12-13  9:40     ` Stefan Roese
2018-12-12 17:32 ` [U-Boot] [PATCH 10/16] configs: Get rid of SPI_FLASH_BAR Vignesh R
2018-12-12 20:41   ` Jagan Teki
2018-12-12 20:51     ` Boris Brezillon
2018-12-12 20:54     ` Simon Goldschmidt
2018-12-13 10:41     ` Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 11/16] configs: Remove SF_DUAL_FLASH Vignesh R
2018-12-12 20:50   ` Jagan Teki
2018-12-12 17:32 ` [U-Boot] [PATCH 12/16] axm_defconfig: Enable simple malloc in SPL Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 13/16] taurus_defconfig: " Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 14/16] da850_am18xxevm: Enable tiny printf Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 15/16] turris_omnia_defconfig: " Vignesh R
2018-12-12 17:32 ` [U-Boot] [PATCH 16/16] MAINTAINERS: Add an entry for SPI NOR Vignesh R
2018-12-12 21:01   ` Jagan Teki
2018-12-14  8:03     ` Vignesh R
2018-12-14 10:13 ` [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework Jagan Teki
2018-12-14 15:54   ` Vignesh R
2018-12-14 16:14     ` Simon Goldschmidt
2018-12-14 16:27       ` Vignesh R
2018-12-14 16:38         ` Simon Goldschmidt
2018-12-14 16:42           ` Vignesh R
2018-12-15 13:59             ` Jagan Teki
2018-12-15 14:42               ` Jagan Teki [this message]
2018-12-15  6:31         ` Stefan Roese
2018-12-15 13:54     ` Jagan Teki
2018-12-15 15:43       ` Vignesh R
2018-12-18 12:32         ` Jagan Teki
2018-12-18 17:19           ` Vignesh R
2018-12-21  8:55             ` Ashish Kumar
2018-12-15 15:43       ` Vignesh R

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=CAMty3ZAgfgBHuYpcw6NB_rQ5GSwp8sgjTGTQXo+10xwjfVauDA@mail.gmail.com \
    --to=jagan@amarulasolutions.com \
    --cc=u-boot@lists.denx.de \
    /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.