Hi Jagan,
On Thu, Sep 19, 2013 at 1:06 AM, Jagan Teki <jagannadh.t...@gmail.com>wrote:
> On Thu, Sep 19, 2013 at 11:46 AM, Simon Glass <s...@chromium.org> wrote:
> > Hi,
> >
> > On Sun, Sep 15, 2013 at 12:15 PM, Jagannadha Sutradharudu Teki <
> > jagannadha.sutradharudu-t...@xilinx.com> wrote:
> >
> >> Added new spi_flash_probe support, currently added N25Q*
> >> flash part attributes support.
> >>
> >> Updated the sector_size attributes as per the flash parts.
> >> Looks fine for with this sector_size for computing the size
> >> of flash.
> >>
> >> Defined CONFIG_SPI_FLASH_LEGACY for old probing style
> >> which is available on spi_flash_probe_legacy.c, this will
> >> removed soon once all flashes are supported in new spi_flash_probe.
> >>
> >> Signed-off-by: Jagannadha Sutradharudu Teki <jaga...@xilinx.com>
> >> ---
> >> Changes for v3:
> >> - Fix warning issue.
> >> Changes for v2:
> >> - Removed CONFIG_SPI_FLASH_NEW, add CONFIG_SPI_FLASH_LEGACY
> >> - Enable CONFIG_SPI_FLASH_STMICRO in spi_flash_params table
> >> - Updated few structure members
> >>
> >> drivers/mtd/spi/Makefile | 1 +
> >> drivers/mtd/spi/spi_flash_probe.c | 229
> ++++++++++++-------------
> >> drivers/mtd/spi/spi_flash_probe_legacy.c | 276
> >> +++++++++++++++++++++++++++++++
> >> 3 files changed, 385 insertions(+), 121 deletions(-)
> >> create mode 100644 drivers/mtd/spi/spi_flash_probe_legacy.c
> >>
> >>
> >> ...
> >
> >
> >> +/*
> >> + * The following table holds all device probe functions
> >> + *
> >> + * shift: number of continuation bytes before the ID
> >> + * idcode: the expected IDCODE or 0xff for non JEDEC devices
> >> + * probe: the function to call
> >> + *
> >> + * Non JEDEC devices should be ordered in the table such that
> >> + * the probe functions with best detection algorithms come first.
> >> + *
> >> + * Several matching entries are permitted, they will be tried
> >> + * in sequence until a probe function returns non NULL.
> >> + *
> >> + * IDCODE_CONT_LEN may be redefined if a device needs to declare a
> >> + * larger "shift" value. IDCODE_PART_LEN generally shouldn't be
> >> + * changed. This is the max number of bytes probe functions may
> >> + * examine when looking up part-specific identification info.
> >> + *
> >> + * Probe functions will be given the idcode buffer starting at their
> >> + * manu id byte (the "idcode" in the table below). In other words,
> >> + * all of the continuation bytes will be skipped (the "shift" below).
> >> + */
> >> +#define IDCODE_CONT_LEN 0
> >> +#define IDCODE_PART_LEN 5
> >> +static const struct {
> >> + const u8 shift;
> >> + const u8 idcode;
> >> + struct spi_flash *(*probe) (struct spi_slave *spi, u8 *idcode);
> >> +} flashes[] = {
> >> + /* Keep it sorted by define name */
> >> +#ifdef CONFIG_SPI_FLASH_ATMEL
> >> + { 0, 0x1f, spi_flash_probe_atmel, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_EON
> >> + { 0, 0x1c, spi_flash_probe_eon, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_GIGADEVICE
> >> + { 0, 0xc8, spi_flash_probe_gigadevice, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_MACRONIX
> >> + { 0, 0xc2, spi_flash_probe_macronix, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_SPANSION
> >> + { 0, 0x01, spi_flash_probe_spansion, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_SST
> >> + { 0, 0xbf, spi_flash_probe_sst, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_STMICRO
> >> + { 0, 0x20, spi_flash_probe_stmicro, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FLASH_WINBOND
> >> + { 0, 0xef, spi_flash_probe_winbond, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FRAM_RAMTRON
> >> + { 6, 0xc2, spi_fram_probe_ramtron, },
> >> +# undef IDCODE_CONT_LEN
> >> +# define IDCODE_CONT_LEN 6
> >> +#endif
> >> + /* Keep it sorted by best detection */
> >> +#ifdef CONFIG_SPI_FLASH_STMICRO
> >> + { 0, 0xff, spi_flash_probe_stmicro, },
> >> +#endif
> >> +#ifdef CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC
> >> + { 0, 0xff, spi_fram_probe_ramtron, },
> >> +#endif
> >>
> >
> > Do you think it is worth using a linker list for this?
>
> I didn't understand what do you means by this?
> Can you please elaborate.
>
I mean that you could use the features of linker_lists.h - for example to
define macros to declare each driver, and then have this file look through
the available drivers.
U_BOOT_CMD() does this - see do_help() for how the list is scanned.
It's just an idea, perhaps for the future.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
