Commit graph

37 commits

Author SHA1 Message Date
Tom Rini
8bef036836 Xilinx changes for v2022.01-rc1
zynq:
 - Enable capsule update for qspi and mmc
 - Update zed DT qspi compatible string
 
 zynqmp:
 - Add missing modeboot for EMMC
 - Add missing nand DT properties
 - List all eeproms for SC on vck190
 - Add vck190 SC psu_init
 
 clk:
 - Handle only GATE type clock for Versal
 
 watchdog:
 - Update versal driver to handle system reset
 -----BEGIN PGP SIGNATURE-----
 
 iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCYVWWZgAKCRDKSWXLKUoM
 IY3MAJ43Mlut5tK9gv45bp4HpyVOMuSvJwCfTiVr7ZxrBE8I8QC5+zHzBTmuM6g=
 =aQtT
 -----END PGP SIGNATURE-----

Merge tag 'xilinx-for-v2022.01-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next

Xilinx changes for v2022.01-rc1

zynq:
- Enable capsule update for qspi and mmc
- Update zed DT qspi compatible string

zynqmp:
- Add missing modeboot for EMMC
- Add missing nand DT properties
- List all eeproms for SC on vck190
- Add vck190 SC psu_init

clk:
- Handle only GATE type clock for Versal

watchdog:
- Update versal driver to handle system reset
2021-09-30 11:29:41 -04:00
Marek Vasut
b81ce79df0 mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0
Before e2e95e5e25 ("spi: Update speed/mode on change") most systems
silently defaulted to SF bus mode 0. Now the mode is always updated,
which causes breakage. It seems most SF which are used as boot media
operate in bus mode 0, so switch that as the default.

This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
as those might need mode 3.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Aleksandar Gerasimovski <aleksandar.gerasimovski@hitachi-powergrids.com>
Cc: Andreas Biessmann <andreas@biessmann.org>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Valentin Longchamp <valentin.longchamp@hitachi-powergrids.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
2021-09-28 12:03:21 -04:00
Michal Simek
b4c2c151b1 Kconfig: Remove all default n/no options
default n/no doesn't need to be specified. It is default option anyway.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-08-31 17:47:49 -04:00
Chris Morgan
674a948309 mtd: spi-nor-ids: Add XTX XT25F128B
Adds support for XT25F128B used on Odroid Go Advance. Unfortunately
this chip uses a continuation code which I cannot seem to parse, so
there are possibly going to be collisions with chips that use the same
manufacturer/ID.

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2021-08-12 09:34:11 +08:00
Pratyush Yadav
f6adec1af4 mtd: spi-nor-core: Allow using Micron mt35xu512aba in Octal DTR mode
Since this flash doesn't have a Profile 1.0 table, the Octal DTR
capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
fast read settings.

Enable Octal DTR mode with 20 dummy cycles to allow running at the
maximum supported frequency of 200Mhz.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2021-06-28 12:06:57 +05:30
Pratyush Yadav
ea9a22f7e7 mtd: spi-nor-core: Add support for Cypress Semper flash
The Cypress Semper flash is an xSPI compliant octal DTR flash. Add
support for using it in octal DTR mode.

The flash by default boots in a hybrid sector mode. Switch to uniform
sector mode on boot. Use the default 20 dummy cycles for a read fast
command.

The SFDP programming on some older versions of the flash was incorrect.
Fixes for that are included in the fixup hooks.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2021-06-28 12:06:43 +05:30
Pratyush Yadav
0be8ab1f16 mtd: spi-nor-core: Perform a Soft Reset on boot
When the flash is handed to us in a stateful mode like 8D-8D-8D, it is

difficult to detect the mode the flash is in. One option is to read SFDP
in all modes and see which one gives the correct "SFDP" signature, but
not all flashes support SFDP in 8D-8D-8D mode.

Further, even if you detect the mode of the flash via SFDP, you still
have the problem of actually reading the ID. The Read ID command is not
standardized across flash vendors. Flashes can have different dummy
cycles needed for reading the ID. Some flashes even expect a 4-byte
dummy address with the Read ID command. All this information cannot be
obtained from the SFDP table.

So, perform a Software Reset sequence before reading the ID and
initializing the flash. A Soft Reset will bring back the flash in its
default protocol mode assuming no non-volatile configuration was set.
This will let us detect the flash even if ROM hands it to us in Octal
DTR mode.

To accommodate cases where there is more than one flash on a board, and
only one of them needs a soft reset, failure to reset is not made fatal,
and we still try to read ID if possible.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2021-06-28 12:05:17 +05:30
Pratyush Yadav
575caf4500 mtd: spi-nor-core: Perform a Soft Reset on shutdown
On probe, the SPI NOR core will put a flash in 8D-8D-8D mode if it
supports it. But Linux as of now expects to get the flash in 1S-1S-1S
mode. Handing the flash to Linux in Octal DTR mode means the kernel will
fail to detect the flash.

So, we need to reset to Power-on-Reset (POR) state before handing off
the flash. A Software Reset command can be used to do this.

One limitation of the soft reset is that it will restore state from
non-volatile registers in some flashes. This means that if the flash was
set to 8D mode in a non-volatile configuration, a soft reset won't help.
This commit assumes that we don't set any non-volatile bits anywhere,
and the flash doesn't have any non-volatile Octal DTR mode
configuration.

Since spi-nor-tiny doesn't (and likely shouldn't) have
spi_nor_soft_reset(), add a dummy spi_nor_remove() for it that does
nothing.

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2021-06-28 12:04:53 +05:30
Pratyush Yadav
71025f013c mtd: spi-nor-core: Rework hwcaps selection
The spi-mem layer provides a spi_mem_supports_op() function to check
whether a specific operation is supported by the controller or not.
This is much more accurate than the hwcaps selection logic based on
SPI_{RX,TX}_ flags.

Rework the hwcaps selection logic to use spi_mem_supports_op().

To make sure the build doesn't break for boards not using CONFIG_DM_SPI,
add a simple SPI_{RX,TX}_ based hwcaps selection logic in spi-mem-nodm
similar to spi_mem_default_supports_op(). This change is only
compile-tested.

To avoid SPL size problems on the x530 board, the old hwcaps selection
is still kept around. Leaving the code in-place was getting difficult to
read and understand, so the code is restructured to have it all in one
isolated function. As a result of this, the parameter hwcaps to
spi_nor_setup() is no longer needed. Remove it.

Based on the Linux commit c76f5089796a (mtd: spi-nor: Rework hwcaps
selection for the spi-mem case, 2019-08-06)

Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2021-06-28 11:59:35 +05:30
Michael Walle
5d867bcc23 mtd: spi-nor: add unlock all config option
Provide an explicit configuration option to disable default "unlock all"
of any flash chip which supports locking. It doesn't make sense to
automatically unprotect the entire flash on each u-boot startup if the
block protection bits are actually used.

Traditionally, the unlock was there to be able to write to flash devices
which powered-up with the block protection bits set. Over time this
feature creeped into all flash devices which support locking.

For a more detailed description and discussion see:
https://lore.kernel.org/linux-mtd/20201203162959.29589-8-michael@walle.cc/

Keep things simple in u-boot and just provide a configration option to
disable this behavior which can be set per board.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-02-08 14:01:13 +05:30
Simon Glass
caa4daa2ae dm: treewide: Rename 'platdata' variables to just 'plat'
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).

Rename some of the latter variables to end with 'plat' for consistency.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-13 16:51:08 -07:00
Miquel Raynal
85f7e9d547 mtd: spi: SPI_FLASH_MTD depends on MTD
It is already the case that all defconfigs with SPI_FLASH_MTD also
declare using MTD, but let's make this consistent and enforce it in
Kconfig. Most of the time SPI_FLASH_MTD is used in conjunction with
UBI, which already depends on MTD.

Suggested-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-12-04 17:10:51 -05:00
Frieder Schrempf
64f736c901 mtd: spi: Add a new option SPL_SPI_FLASH_MTD to Kconfig
To allow SPI_FLASH_MTD being enabled separately in SPL we add a new
option. The only user currently is the stm32mp15_basic board.

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Acked-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2019-10-25 00:48:31 +05:30
Jagan Teki
77df1a9b66 mtd: spi: Kconfig: Imply SPI_FLASH if DM_SPI_FLASH
DM_SPI_FLASH should require spi flash interface code for dm
version, so imply SPI_FLASH core by default if any board
enabled DM_SPI_FLASH.

This overcome the explicit enablement of CONFIG_SPI_FLASH on
respective boards when DM_SPI_FLASH being used.

Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
2019-10-25 00:48:31 +05:30
Jagan Teki
989fd97fe5 mtd: spi: Kconfig: Update CONFIG_SPI_FLASH
1) CONFIG_SPI_FLASH is not just a legacy code, but it has common
   core code which handle both dm and non-dm spi flash code. So
   fix the info text to make it clear globally.

2) Since it's flash core it shouldn't depends on legacy SPI,
   so remove the 'depends on SPI'

Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
2019-10-25 00:42:57 +05:30
Patrick Delaunay
b0cc1b846f dm: spi: Read default speed and mode values from DT
This patch update the behavior introduced by
commit 96907c0fe5 ("dm: spi: Read default speed and mode values from DT")

In case of DT boot, don't read default speed and mode for SPI from
CONFIG_* but instead read from DT node. This will make sure that boards
with multiple SPI/QSPI controllers can be probed at different
bus frequencies and SPI modes.

Remove also use in boards of the value speed=0 (no more supported)
for ENV in SPI by using CONFIG_ENV_SPI_MAX_HZ=0.

DT values will be always used when available (full DM support of
SPI slave with available DT node) even if speed and mode are requested;
for example in splash screen support (in splash_sf_read_raw)
or in SPL boot (in spl_spi_load_image).
The caller of spi_get_bus_and_cs() no more need to force speed=0.

But the current behavior don't change if the SPI slave is not
present (device with generic driver is created automatically)
or if platdata is used (CONFIG_OF_PLATDATA).

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
2019-04-12 11:54:50 +05:30
Patrick Delaunay
14453fbfad Convert CONFIG_SF_DEFAULT_* to Kconfig
This converts the following to Kconfig:
  CONFIG_SF_DEFAULT_BUS
  CONFIG_SF_DEFAULT_CS
  CONFIG_SF_DEFAULT_MODE
  CONFIG_SF_DEFAULT_SPEED

I use moveconfig script and then manual check on generated u-boot.cfg
to solve the remaining issue.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-03-25 17:36:53 -04:00
Vignesh R
c4e8862308 mtd: spi: Switch to new SPI NOR framework
Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
use new interfaces/definitions

Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> #zynq-microzed
2019-02-07 15:33:21 +05:30
Vignesh R
0c6f187cdb mtd: spi: spi-nor-core: Add SFDP support
Sync Serial Flash Discoverable Parameters (SFDP) parsing support from
Linux. This allows auto detection and configuration of Flash parameters.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> #zynq-microzed
2019-02-07 15:33:21 +05:30
Stefan Roese
881e4fc206 sf: Add XMC xm25qh64a and xm25qh128a entries
This patch adds support for 2 new XMC (Wuhan Xinxin Semiconductor
Manufacturing Corp) SPI NOR chips.

This support can be enabled by selecting the SPI_FLASH_XMC Kconfig
option.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>
2018-10-04 18:21:23 +05:30
Michal Simek
13f451bf56 spi: Kconfig: Create ISSI Kconfig entry
Add ISSI to Kconfig to make it selectable via menuconfig.
Also convert all current platforms.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2018-08-06 08:44:35 +02:00
Jagan Teki
c2a7a7ef86 arm: sunxi: Move spl spi sunxi code to mach-sunxi
This SUNXI variant SPL SPI code doesn't use either SPI or
SPL_FLASG subsystems due to size constraints and also placing
this code in drivers/mtd/spi will unnecessary build SPI_FLASH
code(if defined) which never required, hence moved to arch area.

And also renamed the file according to kconfig which resembles
proper name.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
2018-03-13 19:50:10 +05:30
Andre Przywara
a722359de4 SPL: SPI: select SPL_SPI_FLASH_SUPPORT on SPL_SPI_SUNXI
The Allwinner SPI flash SPL boot support is guarded by the SPL_SPI_SUNXI
symbol. But despite its generic name, the actual only use case for this
is to provide SPI flash support to the SPL, which requires
CONFIG_SPL_SPI_FLASH_SUPPORT to be defined.
Select this symbol from the SPL_SPI_SUNXI Kconfig definition. This
avoids doing this explicitly in the defconfig, and fixes SPI booting on
the Pine64 SoPine (and -LTS version) and the OrangePi Win board (both with
SPI flash).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-10-25 10:05:05 +02:00
Mike Looijmans
988390b8e1 arm: zynq: Move CONFIG_SF_DUAL_FLASH to defconfig
Move the only use of CONFIG_SF_DUAL_FLASH to defconfig. This makes the
associated topic_miamiplus.h header obsolete, so remove that as well.

Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2017-06-20 16:42:13 +02:00
Andre Przywara
7b82a229e5 sunxi: prepare for sharing MACH_SUN8I_H3 config symbol
The Allwinner H5 is very close to the H3 SoC, but has ARMv8 cores.
To allow sharing the clocks, GPIO and driver code easily, create an
architecture agnostic MACH_SUNXI_H3_H5 Kconfig symbol.
Rename the existing symbol to MACH_SUNXI_H3_H5 where code is shared and
let it be selected by a new shared Kconfig option.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-04-05 15:03:17 +05:30
Siarhei Siamashka
19e99fb4ff sunxi: Support booting from SPI flash
Allwinner devices support SPI flash as one of the possible
bootable media type. The SPI flash chip needs to be connected
to SPI0 pins (port C) to make this work. More information is
available at:

    https://linux-sunxi.org/Bootable_SPI_flash

This patch adds the initial support for booting from SPI flash.
The existing SPI frameworks are not used in order to reduce the
SPL code size. Right now the SPL size grows by ~370 bytes when
CONFIG_SPL_SPI_SUNXI option is enabled.

While there are no popular Allwinner devices with SPI flash at
the moment, testing can be done using a SPI flash module (it
can be bought for ~2$ on ebay) and jumper wires with the boards,
which expose relevant pins on the expansion header. The SPI flash
chips themselves are very cheap (some prices are even listed as
low as 4 cents) and should not cost much if somebody decides to
design a development board with an SPI flash chip soldered on
the PCB.

Another nice feature of the SPI flash is that it can be safely
accessed in a device-independent way (since we know that the
boot ROM is already probing these pins during the boot time).
And if, for example, Olimex boards opted to use SPI flash instead
of EEPROM, then they would have been able to have U-Boot installed
in the SPI flash now and boot the rest of the system from the SATA
hard drive. Hopefully we may see new interesting Allwinner based
development boards in the future, now that the software support
for the SPI flash is in a better shape :-)

Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
in a board defconfig, then building U-Boot and finally flashing
the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
a help of the sunxi-fel tool:

   sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin

The device needs to be switched into FEL (USB recovery) mode first.
The most suitable boards for testing are Orange Pi PC and Pine64.
Because these boards are cheap, have no built-in NAND/eMMC and
expose SPI0 pins on the Raspberry Pi compatible expansion header.
The A13-OLinuXino-Micro board also can be used.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2016-07-15 08:34:34 +02:00
Marek Vasut
0a02655481 sf: Make 4K sector support configurable
Make the support for 4K subpage I/O on a SPI NOR flash configurable.
A board which requires the SPI NOR to be accessed in larger 32KiB
or 64KiB pages can disable the 4K subpage support, but by default,
the support for 4K subpage I/O is enabled. The functionality of this
option is the same as CONFIG_MTD_SPI_NOR_USE_4K_SECTORS in Linux.

This is extremely useful in case one uses UBI on a SPI NOR flash.
UBI needs at least 15k EBs and can not work on a flash which uses
4k ones, so disabling the support for 4k subpages lets UBI work on
such flash.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jteki@openedev.com>
2015-08-17 15:59:48 +05:30
Nikita Kiryanov
d5af92315b sf: kconfig: add kconfig options for spi flashes
Add kconfig options for various SPI flashes and use them in cm-fx6 defconfig.

Cc: Jagan Teki <jteki@openedev.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
2015-08-02 10:51:39 +02:00
Jagan Teki
84d31b3b8f sf: Kconfig: Add SPI_FLASH_BAR entry
Added SPI_FLASH_BAR entry on Kconfig with help description

Signed-off-by: Jagan Teki <jteki@openedev.com>
2015-07-01 21:39:06 +05:30
Jagan Teki
cd9accdcd9 sf: Kconfig: Add SPI_FLASH_DATAFLASH entry
Added SPI_FLASH_DATAFLASH entry on Kconfig with help description.

data flash driver comes with good decription, hence moved the
same on to kconfig help decription.

Signed-off-by: Jagan Teki <jteki@openedev.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Haikun Wang <haikun.wang@freescale.com>
2015-07-01 21:22:19 +05:30
Jagan Teki
7678dd93ec sf: Kconfig: Add SPI_FLASH_MTD entry
Added SPI_FLASH_MTD entry on Kconfig with help description.

Signed-off-by: Jagan Teki <jteki@openedev.com>
Acked-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
2015-07-01 21:15:04 +05:30
Jagan Teki
2ce7e2b6fc sf: Kconfig: Update SPI_FLASH entry
Updated SPI_FLASH entry on Kconfig with depends on
and along with config help description.

Signed-off-by: Jagan Teki <jteki@openedev.com>
2015-07-01 21:15:04 +05:30
Jagan Teki
810fd69672 sf: Add Kconfig menu entry
Added Kconfig menu ... endmenu enties for spi flash suppor

Signed-off-by: Jagan Teki <jteki@openedev.com>
2015-07-01 21:15:04 +05:30
Joe Hershberger
22e04faaab mtd: spi: Add the SPI_FLASH config to Kconfig
This config needs to be available in the Kconfig to allow it to be
removed from arch defaults.

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
2015-06-25 17:04:43 -04:00
Simon Glass
949dd81b43 sandbox: Move CONFIG_SPI_FLASH_SANDBOX to Kconfig
Move this over to Kconfig and tidy up.

Signed-off-by: Simon Glass <sjg@chromium.org>
2015-04-18 11:11:38 -06:00
Masahiro Yamada
b3d023b405 dm: spi_flash: fix wrong dependency
CONFIG_SPI does not exist in Kconfig in the first place, so the
dependency "depends on DM && SPI" is never met, i.e., DM_SPI_FLASH
can never be enabled (unless you ignore the dependency in an illegal
way.  See below.)

Actually, some defconfigs such as socfpga_*_defconfig define
CONFIG_DM_SPI_FLASH=y, but it never appears in the .config file
because of this wrong dependency.

On the other hand, all the Tegra boards enable DM_SPI_FLASH because

  config DM_SPI_FLASH
          default y

silently ignores the dependency.
Unfortunately, this style of CONFIG definition is abused everywhere
in U-Boot, so we easily miss such a wrong dependency.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-04-18 11:11:30 -06:00
Simon Glass
f94a1bed07 dm: Expand and complete Kconfig in drivers/
Expand the help messages for each driver. Add missing Kconfig for I2C,
SPI flash and thermal.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-12 10:35:33 -07:00