Kever Yang [Fri, 14 Dec 2018 01:37:12 +0000 (09:37 +0800)]
rockchip: rk3288-evb: dts: remove 'vmmc' from emmc node
This is a sync with kernel mainline dts.
The U-Boot eMMC does not need to care about the power for Rockchip
SoCs, because if the board is using eMMC, the power will default on
(for bootrom), so the 'vmmc', 'vqmmc' is only useful for SD in U-Boot.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
vcc5v0_host and usbhub_enable share gpio4 RK_PA3,
which is a problem during probing (the second probe
will trigger a -EBUSY, when trying to get the gpio handle).
An analysis of the situation shows, that both regulators
are actually describing the same supply.
This patch removes the (currenlty not successful probing)
regulator vcc5v0_host from the DTS and adds the pinctrl-*
setting to usbhub_enable.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Phiilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Simon Glass [Mon, 10 Dec 2018 17:37:51 +0000 (10:37 -0700)]
dm: sound: Use the correct number of channels for sound
At present the 'beep' sound generates a waveform for only one channel even
if two are being used. This means that the beep is twice the frequency it
should be. Correct this by making it a parameter.
The fix in a previous commit was correct for sandbox but not for other
boards.
Fixes: 03f11e87a8 ("sound: Correct data output in sound_create_square_wave()") Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Mon, 10 Dec 2018 17:37:45 +0000 (10:37 -0700)]
dm: sandbox: sound: Convert to use driver model
Update sandbox's device tree and config to use driver model for sound. Use
the double buffer for sound output so that we don't need to wait for the
sound to complete before returning.
Simon Glass [Mon, 10 Dec 2018 17:37:44 +0000 (10:37 -0700)]
dm: exynos: sound: Convert to use driver model
Update snow's device tree and config to use driver model for sound. Also
update the others as best we can.
Spring does not appear to have audio support in the kernel. The smdk5250
and smdk5420 boards use a wolfson codec which I cannot test with. So the
only boards that is tested and known to work are snow, pit and pi.
Simon Glass [Mon, 10 Dec 2018 17:37:41 +0000 (10:37 -0700)]
exynos: Add support for exynos5420 i2s pinmux
Allow setting the i2s pinmux correctly on exyno5420 so that i2c can be
used on that SoC. Also rename EXYNOS_AUDSS to something consistent with
other naming.
Simon Glass [Mon, 10 Dec 2018 17:37:38 +0000 (10:37 -0700)]
dm: sound: Start i2c IDs from 0
The current ID enums start from 1 but there does not seem to be any reason
that they cannot start with 0. Adjust the code to avoid the +1 in
codec_init().
Simon Glass [Mon, 10 Dec 2018 17:37:37 +0000 (10:37 -0700)]
dm: core: Add a function to read into a unsigned int
The current dev_read...() functions use s32 and u32 which are convenient
for device tree but not so useful for normal code, which often wants to
use normal integers for values.
Add a helper which supports returning an unsigned int. Also add signed
versions of the unsigned readers.
Simon Glass [Mon, 10 Dec 2018 17:37:36 +0000 (10:37 -0700)]
dm: sound: Create a uclass for sound
The sound driver pulls together the audio codec and i2s drivers in order
to actually make sounds. It supports setup() and play() methods. The
sound_find_codec_i2s() function allows locating the linked codec and i2s
devices. They can be referred to from uclass-private data.
Simon Glass [Mon, 10 Dec 2018 17:37:35 +0000 (10:37 -0700)]
dm: sandbox: Update sound to use two buffers
At present we use a single buffer for sound which means we cannot be
playing one sound while queueing up the next. This wouldn't matter except
that a long sound (more than a second) has to be created as a single
buffer, thus using a lot of memory. To better mimic what real sound
drivers do, add support for double buffering in sandbox.
Simon Glass [Mon, 10 Dec 2018 17:37:34 +0000 (10:37 -0700)]
dm: sound: Create a uclass for i2s
The i2s bus is commonly used with audio codecs. It provides a way to
stream digital data sychronously in both directions. U-Boot only supports
audio output, so this uclass is very simple, with a single tx_data()
method.
Simon Glass [Mon, 10 Dec 2018 17:37:33 +0000 (10:37 -0700)]
dm: sound: Create a uclass for audio codecs
An audio codec provides a way to convert digital data to sound and vice
versa. Add a simple uclass which just supports setting the parameters for
the codec.
Simon Glass [Mon, 10 Dec 2018 17:37:32 +0000 (10:37 -0700)]
dm: sound: Rename samsung_i2s_priv to i2s_uc_priv
This structure contains information that is likely needed by any i2s
driver so it seems useful to attach it to the (forthcoming) i2c uclass.
For now, just rename it.
Simon Glass [Mon, 10 Dec 2018 17:37:31 +0000 (10:37 -0700)]
dm: sound: Create an option to use driver model for sound
The U-Boot sound system provides basic support for beeping. At present it
does not use driver model, but it needs to be converted. Add an option to
enable driver model for sound. For now it is not connected to anything.
Future work will add drivers which use this option. It will then be
removed once everything is converted.
Simon Glass [Mon, 10 Dec 2018 17:37:30 +0000 (10:37 -0700)]
dm: sound: exynos: Correct codec bus addresses
For snow the codec is at address 0x11 on the i2c bus, in 7-bit format.
The device tree and code are in 8-bit format (i.e. shifted left one bit).
Fix both. Fix pit in a similar way.
Simon Glass [Mon, 3 Dec 2018 11:37:26 +0000 (04:37 -0700)]
dm: sound: wm8994: Create a new common init function
With driver model we cannot pass in the global struct, but instead want
to pass in the driver-private data. Split some of the code out of
wm8994_init() to handle this.
Simon Glass [Mon, 3 Dec 2018 11:37:25 +0000 (04:37 -0700)]
dm: sound: max98095: Pass private data to internal functions
At present the driver-private data is global. To allow this code to be
used with driver model, change it to pass the data down to each function.
Use the name 'priv' consistently throughout.
Also rename max98095_update_bits() to max98095_bic_or() which is more
descriptive and shorter, thus breaking fewer lines with the parameter
addition.
Simon Glass [Mon, 3 Dec 2018 11:37:24 +0000 (04:37 -0700)]
dm: sound: wm8994: Pass private data to internal functions
At present the driver-private data is global. To allow this code to be
used with driver model, change it to pass the data down to each function.
Use the name 'priv' consistently throughout.
Also rename wm8994_update_bits() to wm8994_bic_or() which is more
descriptive and shorter, thus breaking fewer lines with the parameter
addition.
Sekhar Nori [Thu, 6 Dec 2018 10:10:08 +0000 (15:40 +0530)]
spl: fix build failure with !CONFIG_SPL_PCI_SUPPORT
Building U-Boot with CONFIG_PCI and CONFIG_DM_PCI enabled, but
CONFIG_SPL_PCI_SUPPORT disabled, results in following linker
error:
lib/built-in.o: In function `fdtdec_get_pci_bar32':
lib/fdtdec.c:305: undefined reference to `dm_pci_read_bar32'
fdtdec.c:305:(.text.fdtdec_get_pci_bar32+0x24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `dm_pci_read_bar32'
This is because reference to dm_pci_read_bar32() remains in lib/fdtdec.c
while SPL build does not descend into drivers/pci directory in
drivers/Makefile if CONFIG_SPL_PCI_SUPPORT is not enabled.
Fix this by applying appropriate #define guards in lib/fdtdec.c.
It looks like ns16550.c has the same problem, so fixed that too.
To simplify this, CONFIG_SPL_PCI_SUPPORT is renamed to CONFIG_SPL_PCI
(enables use of CONFIG_IS_ENABLED() macro).
Suggested-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 5 Dec 2018 13:23:38 +0000 (08:23 -0500)]
blk: Rework guard around part_init call
The function part_init() will only be built when we have both
CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set. Protect the call to
this function with both of these tests now.
Cc: Simon Glass <sjg@chromium.org> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: York Sun <york.sun@nxp.com> Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Cc: Mingkai Hu <mingkai.hu@nxp.com> Cc: Stefan Roese <sr@denx.de> Cc: Marek Behún <marek.behun@nic.cz> Cc: Vanessa Maegima <vanessa.maegima@nxp.com> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Adam Ford <aford173@gmail.com> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Tom Warren <twarren@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sumit Garg [Mon, 26 Nov 2018 11:20:17 +0000 (16:50 +0530)]
qemu-arm: Add persistent environment support
Currently on qemu-arm platforms environment is kept in RAM. Instead
use pflash device 1 to provide persistent environment support across
device reset.
Also (optionally) provide support for persistent environment across
qemu machine OFF/ON using following instructions:
- Create envstore.img using qemu-img:
qemu-img create -f raw envstore.img 64M
- Add a pflash drive parameter to the command line:
-drive if=pflash,format=raw,index=1,file=envstore.img
i2c: tegra: Fix regression by implementing a dummy probe_chip() callback
Commit f32a8007ef0f ("dm: i2c: Make i2c_get_chip_for_busnum() fail if the
chip is not detected") introduced a regression for the NVIDIA Jetson TX2.
For some reason the xfer callback of the tegra i2c driver doesn't support
probing the I2C devices with a 0-length message.
Fixing the regression by providing a dummy implementation of probe_chip()
that does nothing.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Tested-by: Stephen Warren <swarren@nvidia.com>
Adam Ford [Tue, 11 Dec 2018 13:41:03 +0000 (07:41 -0600)]
ARM: davinci: Orphan Spectrum Digital AM18xx EVM
I had requested the da850 boards because their previous maintainer
had an invalid e-mail address. I work at Logic PD who makes
the da850-evm kits, so I have access to various boards of theirs.
The Spectrum Digital AM18xx board is based on the Logic PD
da850 EVM, but it's not the same company. Since I don't have the
hardware to test/verify changes, I would prefer to not be
responsible for this board.
Tom Rini [Thu, 6 Dec 2018 21:39:43 +0000 (16:39 -0500)]
travis: Add check for configs without MAINTAINERS entries
The genboardscfg.py script will emit a WARNING message if we have new
defconfig files that are not listed in a MAINTAINERS file. Make new
cases of this a failure we catch in Travis-CI.
Tom Rini [Mon, 10 Dec 2018 22:12:28 +0000 (17:12 -0500)]
Merge tag 'mips-fixes-for-2019.01' of git://git.denx.de/u-boot-mips
- mips: bcm: disable CONFIG_SWAP_IO_SPACE to force native endianess in readl() & co.
this fixes 09ace9161b95ad3a04b33d1d6a65a929901d28c8
- mips: bcm6838: fix device tree warning
Tom Rini [Mon, 10 Dec 2018 15:19:09 +0000 (10:19 -0500)]
Merge tag 'for-master-20181210' of git://git.denx.de/u-boot-rockchip
Improvements:
- init DRAM for RK322x in SPL
- add FAN53555 PMIC/regulator driver
- update MicroCrystal RV3029 driver to Kconfig and sync from Linux
- add bootcount uclass and first DM-driver for bootcount
Tom Rini [Mon, 10 Dec 2018 12:14:48 +0000 (07:14 -0500)]
Merge git://git.denx.de/u-boot-x86
- Enable RTC for Intel Tangier
- Wrap the call to 8259 PIC with Kconfig options for old targets without
8259
- Warp the call to USB init with Kconfg options for coreboot & EFI
payload
Philipp Tomsich [Fri, 30 Nov 2018 19:00:10 +0000 (20:00 +0100)]
rockchip: rk3399-puma: enable fan53555 regulators in DTS
Now that we have FAN53555 support, we can enable the regulators in our
DTS. To make these easier to identify on the U-Boot commandline, we
rename them to the names of the voltage rails they control.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
With a driver for the FAN53555 regulator family available, let's
enable it for the RK3399-Q7 (which has two of these devices
on-module).
We enable this for the full U-Boot stage only, as these regulators
provide a suitable default voltage and supply non-critical (i.e.
for booting up) power rails only.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Philipp Tomsich [Fri, 30 Nov 2018 19:00:08 +0000 (20:00 +0100)]
power: add FAN53555 family support
This adds a driver for the FAN53555 family of regulators and wraps it
in a PMIC implementation.
While these devices support a 'normal' and 'suspend' mode (controlled
via an external pin) to switch between two programmable voltages, this
incarnation of the driver assumes that the device is always operating
in 'normal' mode.
Only setting/reading the programmed voltage is supported at this time
and the following device functionality remains unsupported:
- switching the selected voltage (via a GPIO)
- disabling the voltage output via software-control
This matches the functionality of the Linux driver.
Tested on a RK3399-Q7 (with 'option 5' devices): setting voltages from
the U-Boot shell and verifying output voltages on the board.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Philipp Tomsich [Tue, 27 Nov 2018 22:00:19 +0000 (23:00 +0100)]
bootcount: add a DM RTC backing store for bootcount
This implements a driver using a RTC-based backing store for the DM
bootcount implementation. The node configuring this feature will be
compatible with 'u-boot,bootcount-rtc' and the underlying RTC device
shall be reference through the property 'rtc'. An offset into the RTC
device's register space can be provided through the 'offset' property.
Tested on a RK3399-Q7 on a Flamingo carrier board using the SRAM area
of the carrier board's RV3029 RTC.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Philipp Tomsich [Tue, 27 Nov 2018 22:00:18 +0000 (23:00 +0100)]
bootcount: add uclass for bootcount
The original bootcount methods do not provide an interface to DM and
rely on a static configuration for I2C devices (e.g. bus, chip-addr,
etc. are configured through defines statically). On a modern system
that exposes multiple devices in a DTS-configurable way, this is less
than optimal and a interface to DM-based devices will be desirable.
This adds a simple driver that is DM-aware and configurable via DTS.
If ambiguous (i.e. multiple bootcount-devices are present) the
/chosen/u-boot,bootcount-device property can be used to select one
bootcount device.
Initially, this provides support for the following DM devices:
* RTC devices
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Kever Yang [Tue, 4 Dec 2018 09:49:58 +0000 (17:49 +0800)]
rockchip: rk322x: ram: enable DRAM init in SPL instead of TPL
Patch for rk322x TPL is not merged, and only SPL is available now,
enable the sdram driver in SPL first. We should update back to TPL
after TPL is enabled for rk322x.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
In case SYS_I2C or DM_I2C are defined, then the "i2c " prefix
of the "i2c crc32" command is missing.
This patch addresses this, so that users can't get confused
by the "crc32" command.
Without the patch we get
=> i2c help
i2c - I2C sub-system
Usage:
i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
i2c dev [dev] - show or set current I2C bus
[...]
With the patch we get
=> i2c help
i2c - I2C sub-system
Usage:
i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
i2c crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
i2c dev [dev] - show or set current I2C bus
...
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Heiko Schocher <hs@denx.de>
dra7: Allow selecting a new dtb after board detection.
The DRA7 platforms requires that the dtb used in the SPL really matches the
platform to have the best MMC performances.
To detect the board type/version an I2C EEPROM is read. This requires that
DM is initialized before the detection. As a consequence we must reset the
DM after the board detection is a new dtb would better match the platform.
drivers: core: nullify gd->dm_root after dm_uninit()
To reset the DM after a new dtb is loaded, we need to call dm_uninit()
and then dm_init(). This fails however because gd->dm_root is not nullified
by dm_uninit().
Fixing it by setting gd->dm_root in dm_uninit().
drivers: core: Add the option SPL_DM_DEVICE_REMOVE to the Kconfig
It is currently not possible to include the support to remove devices in
the SPL. This is however needed by platforms that re-select their dtb after
DM is initialized; they need to remove all the previously bound devices
before triggering a scan of the new DT.
Add a Kconfig option to be able to include the support for device removal
in the SPL.
lib: fdtdec: Add function re-setup the fdt more effeciently
In some cases it may be useful to be able to change the fdt we have been
using and use another one instead. For example, the TI platforms uses an
EEPROM to store board information and, based on the type of board,
different dtbs are used by the SPL. When DM_I2C is used, a first dtb must
be used before the I2C is initialized and only then the final dtb can be
selected.
To speed up the process and reduce memory usage, introduce a new function
fdtdec_setup_best_match() that re-use the DTBs loaded in memory by
fdtdec_setup() to select the best match.
configs: dra7xx-evm: increase the size of the malloc's pool before relocation
This is required to take advantage of MULTI_DTB_FIT before relocation.
If it is too low, DM will be initialized only after relocation has
taken place. That is too late for the DRA7 because I2C DM is used before
the relocation to setup the voltages required, among other things, to
properly initialize the DRAM.
ti: remove usage of DM_I2C_COMPAT and don't disable DM_I2C in SPL
DM_I2C_COMPAT is a compatibility layer that allows using the non-DM I2C
API when DM_I2C is used. The goal is to eventually remove DM_I2C_COMPAT
when all I2C "clients" have been migrated to use the DM API.
This a step in that direction for the TI based platforms.
Build tested with buildman:
buildman -dle am33xx ti omap3 omap4 omap5 davinci keystone
ti: common: board_detect: Allow DM I2C without CONFIG_DM_I2C_COMPAT
The EEPROM reading in the board detection code is done through legacy
I2C functions which on platforms using DM_I2C this functionality is
provided via the CONFIG_DM_I2C_COMPAT layer. To allow newer platforms
to use the board detection code without relying on CONFIG_DM_I2C_COMPAT
go ahead and add an I2C handling implementation that directly uses the
I2C DM functionality.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
power: make most tps drivers and the twl4030 driver compatible with DM_I2C
Those driver are not DM drivers per se (not using the PMIC/regulator
framework) and are using the legacy I2C API. Make them compatible with
the DM_I2C API.
This impacts the following drivers:
- palmas (used by am57xx/dra7xx evms)
- tps65218 (used by am43xx evms)
- tps65217 and tps65910 (used by am335x evms and am335x boneblack vboot)
- twl4030 (used by omap3_logicpd)
- tps65217 (used by brppt1)
- twl6030
i2c: omap24xx_i2c: Use platdata to probe the device
This allows the driver to be used without OF_CONTROL.
AM335x support DM_SPL but does not use SPL_OF_CONTROL. Enabling DM_I2C in
SPL thus requires that the omap I2C can be passed platdata.
Vignesh R [Fri, 7 Dec 2018 13:50:41 +0000 (14:50 +0100)]
i2c: omap24xx_i2c: Move away from SoC specific headers for reg offset
Move away from SoC specific headers to handle different register layout.
Instead use driver data to get appropriate register layouts like in the
kernel. While at it, perform some mostly cosmetic alignment/cleanup in
the functions being updated.
Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
Those platforms need CONFIG_SPL_DM_SEQ_ALIAS because they enable both
DM_I2C and SPL_DM. Without CONFIG_SPL_DM_SEQ_ALIAS, it is not possible to
get the I2C bus with i2c_get_chip_for_busnum().
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Felix Brack <fb@ltec.ch> Tested-by: Felix Brack <fb@ltec.ch> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
dm: device: Allow using uclass_find_device_by_seq() without OF_CONTROL
If OF_CONTROL is not enabled and DM_SEQ_ALIAS is enabled, we must
assign an alias (requested sequence number) to devices that belongs to a
class with the DM_UC_FLAG_SEQ_ALIAS flag. Otherwise
uclass_find_device_by_seq() cannot be used to get/probe a device. In
particular i2c_get_chip_for_busnum() cannot be used.
cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT
The implementation of the EEPROM commands does not support the DM I2C API.
Prevent compilation breakage by not enabling it if the non-DM API is not
available (if DM_I2C is used without DM_I2C_COMPAT)
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
Bin Meng [Fri, 30 Nov 2018 04:07:13 +0000 (20:07 -0800)]
efi: payload: only init usb if necessary
Up until now the call to initialize the USB subsystem was hardcoded
for U-Boot running as an EFI payload. This was used to enable the
use of a USB keyboard in the U-Boot shell. However not all boards
might need this functionality. As initializing the USB subsystem can
take a considerable amount of time (several seconds on some boards),
we now initialize the USB subsystem only if U-Boot is configured to
use USB keyboards.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Thomas RIENOESSL [Fri, 30 Nov 2018 04:07:12 +0000 (20:07 -0800)]
coreboot: only init usb if necessary
Up until now the call to initialize the USB subsystem was hardcoded
for U-Boot running as a coreboot payload. This was used to enable
the use of a USB keyboard in the U-Boot shell. However not all boards
might need this functionality. As initializing the USB subsystem can
take a considerable amount of time (several seconds on some boards),
we now initialize the USB subsystem only if U-Boot is configured to
use USB keyboards.
Signed-off-by: Thomas RIENOESSL <thomas.rienoessl@bachmann.info> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
projects / u-boot.git / log
