aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'pull-14nov18' of git://git.denx.de/u-boot-dmHEADupstream-mastermasterTom Rini2018-11-16107-220/+5169
|\ | | | | | | | | | | | | - virtio implementation and supporting patches - DM_FLAG_PRE_RELOC fixes - regmap improvements - minor buildman and sandbox things
| * watchdog: Remove DM_FLAG_PRE_RELOC flag in various driversBin Meng2018-11-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * video: simplefb: Remove DM_FLAG_PRE_RELOC flagBin Meng2018-11-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * sysreset: Remove DM_FLAG_PRE_RELOC flag in various driversBin Meng2018-11-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * serial: Remove DM_FLAG_PRE_RELOC flag in various driversBin Meng2018-11-1426-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * timer: Remove DM_FLAG_PRE_RELOC flag in various driversBin Meng2018-11-1414-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * ram: bmips: Remove DM_FLAG_PRE_RELOC flagBin Meng2018-11-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * pinctrl: Remove DM_FLAG_PRE_RELOC flag in various driversBin Meng2018-11-149-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * mmc: omap: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL checkBin Meng2018-11-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * i2c: omap24xx: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL checkBin Meng2018-11-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * gpio: Remove DM_FLAG_PRE_RELOC flag in various driversBin Meng2018-11-144-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
| * clk: Remove DM_FLAG_PRE_RELOC flag in various driversBin Meng2018-11-145-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * serial: ns16550: fix debug uart putc called before initSimon Goldschmidt2018-11-141-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If _debug_uart_putc() is called before _debug_uart_init(), the ns16550 debug uart driver hangs in a tight loop waiting for the tx FIFO to get empty. As this can happen via a printf sneaking in before the port calls debug_uart_init(), let's rather ignore characters before the debug uart is initialized. This is done by reading the baudrate divisor and aborting if is zero. Tested on socfpga_cyclone5_socrates. Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * uclass: Use uclass_foreach_dev() macro instead of open codingLiviu Dudau2018-11-142-10/+10
| | | | | | | | | | | | | | Use the uclass_foreach_dev() macro instead of the open coded version. Signed-off-by: Liviu Dudau <liviu.dudau@foss.arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * virtio: Add a Sandbox transport driverBin Meng2018-11-143-0/+242
| | | | | | | | | | | | | | | | | | | | | | This driver provides support for Sandbox implementation of virtio transport driver which is used for testing purpose only. Two drivers are provided. The 2nd one is a driver that lacks the 'notify' op. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * virtio: net: Support non-legacy deviceBin Meng2018-11-141-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | For v1.0 compliant device, it always assumes the member 'num_buffers' exists in the struct virtio_net_hdr while the legacy driver only presented 'num_buffers' when VIRTIO_NET_F_MRG_RXBUF was negotiated. Without that feature the structure was 2 bytes shorter. Update the driver to support the non-legacy device. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * virtio: pci: Support non-legacy PCI transport deviceBin Meng2018-11-143-4/+613
| | | | | | | | | | | | | | | | | | | | | | | | | | | | By default QEMU creates legacy PCI transport devices, but we can ask QEMU to create non-legacy one if we pass additional device property/value pairs in the command line: -device virtio-blk-pci,disable-legacy=true,disable-modern=false This adds a new driver driver to support non-legacy (modern) device mode. Previous driver/file name is changed accordingly. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * test: dm: pci: Add cases for finding next PCI capability APIsBin Meng2018-11-141-0/+9
| | | | | | | | | | | | | | | | Add test cases to cover the two newly added PCI APIs: dm_pci_find_next_capability() & dm_pci_find_next_ext_capability(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * dm: pci: Add APIs to find next capability and extended capabilityBin Meng2018-11-141-15/+36
| | | | | | | | | | | | | | | | | | | | This introduces two new APIs dm_pci_find_next_capability() and dm_pci_find_next_ext_capability() to get PCI capability address and PCI express extended capability address for a given PCI device starting from a given offset. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * virtio: Add virtio over pci transport driverBin Meng2018-11-144-0/+603
| | | | | | | | | | | | | | | | | | | | | | This adds a transport driver that implements UCLASS_VIRTIO for virtio over pci, which is commonly used on x86. It only supports the legacy interface of the pci transport, which is the default device that QEMU emulates. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * virtio: Add block driver supportTuomas Tynkkynen2018-11-144-0/+274
| | | | | | | | | | | | | | | | This adds virtio block device driver support. Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * blk: Introduce IF_TYPE_VIRTIOTuomas Tynkkynen2018-11-141-0/+2
| | | | | | | | | | | | | | | | This adds a new block interface type for VirtIO block devices. Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * blk: Make blk_next_free_devnum() publicBin Meng2018-11-141-1/+1
| | | | | | | | | | | | | | | | blk_next_free_devnum() can be helpful in some cases. Make it a public API. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * blk: Drop blk_prepare_device()Bin Meng2018-11-141-9/+0
| | | | | | | | | | | | | | With the post_probe() changes, this API is no longer needed. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * blk: Call part_init() in the post_probe() methodBin Meng2018-11-146-8/+13
| | | | | | | | | | | | | | | | | | | | | | part_init() is currently called in every DM BLK driver, either in its bind() or probe() method. However we can use the BLK uclass driver's post_probe() method to do it automatically. Update all DM BLK drivers to adopt this change. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * sandbox: blk: Switch to use platdata_auto_alloc_size for the driver dataBin Meng2018-11-141-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently the sandbox block driver uses priv_auto_alloc_size for the driver data, however that's only available after the device probe phase. In order to make it accessible in an earlier phase, switch to use platdata_auto_alloc_size instead. This patch is the prerequisite for the follow up patch of DM BLK driver changes to work with Sandbox. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * virtio: Add net driver supportTuomas Tynkkynen2018-11-144-0/+494
| | | | | | | | | | | | | | | | This adds virtio net device driver support. Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * virtio: Add virtio over mmio transport driverBin Meng2018-11-144-0/+550
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VirtIO can use various different buses and virtio devices are commonly implemented as PCI devices. But virtual environments without PCI support (a common situation in embedded devices models) might use simple memory mapped device (“virtio-mmio”) instead of the PCI device. This adds a transport driver that implements UCLASS_VIRTIO for virtio over mmio. Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * virtio: Add codes for virtual queue/ring managementTuomas Tynkkynen2018-11-142-1/+359
| | | | | | | | | | | | | | | | | | This adds support for managing virtual queue/ring, the channel for high performance I/O between host and guest. Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * dm: Add a new uclass driver for VirtIO transport devicesBin Meng2018-11-145-0/+403
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new virtio uclass driver for “virtio” [1] family of devices that are are found in virtual environments like QEMU, yet by design they look like physical devices to the guest. The uclass driver provides child_pre_probe() and child_post_probe() methods to do some common operations for virtio device drivers like device and driver supported feature negotiation, etc. [1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * dm: core: Allow uclass to set up a device's child after it is probedBin Meng2018-11-141-1/+12
| | | | | | | | | | | | | | | | | | | | | | Some buses need to set up their child devices after they are probed. Support a common child_post_probe() method for the uclass. With this change, the two APIs uclass_pre_probe_device() and uclass_post_probe_device() become symmetric. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * regmap: Add endianness supportMario Six2018-11-141-10/+124
| | | | | | | | | | | | | | | | | | | | | | | | Add support for switching the endianness of regmap accesses via the "little-endian", "big-endian", and "native-endian" boolean properties in the device tree. The default endianness is native endianness. Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
| * regmap: Support reading from specific rangeMario Six2018-11-141-5/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It is useful to be able to treat the different ranges of a regmap separately to be able to use distinct offset for them, but this is currently not implemented in the regmap API. To preserve backwards compatibility, add regmap_read_range and regmap_write_range functions that take an additional parameter 'range_num' that identifies the range to operate on. Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
| * regmap: Add raw read/write functionsMario Six2018-11-141-7/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The regmap functions currently assume that all register map accesses have a data width of 32 bits, but there are maps that have different widths. To rectify this, implement the regmap_raw_read and regmap_raw_write functions from the Linux kernel API that specify the width of a desired read or write operation on a regmap. Implement the regmap_read and regmap_write functions using these raw functions in a backwards-compatible manner. Reviewed-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Simon Glass <sjg@chromium.org>
| * regmap: Add error outputMario Six2018-11-141-2/+8
| | | | | | | | | | | | | | | | | | Add some debug output in cases where the initialization of a regmap fails. Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
| * regmap: Introduce init_rangeMario Six2018-11-141-12/+56
| | | | | | | | | | | | | | | | | | | | | | | | Both fdtdec_get_addr_size_fixed and of_address_to_resource can fail with an error, which is not currently checked during regmap initialization. Since the indentation depth is already quite deep, extract a new 'init_range' method to do the initialization. Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
| * core: ofnode: Fix mem leak in error pathMario Six2018-11-141-1/+3
| | | | | | | | | | | | | | | | | | | | A newly created property is currently not freed if a name could not be allocated. This patch fixes the resulting memory leak in the error patch. Reported-by: Coverity (CID: 184085) Fixes: e369e58df79c ("core: Add functions to set properties in live-tree") Signed-off-by: Mario Six <mario.six@gdsys.cc>
| * misc: Add IHS FPGA driverMario Six2018-11-144-0/+926
| | | | | | | | | | | | | | | | Add a driver for gdsys IHS (Integrated Hardware Systems) FPGAs, which supports initialization of the FPGA, as well as information gathering. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
| * misc: Add gdsys_soc driverMario Six2018-11-144-0/+106
| | | | | | | | | | | | | | This patch adds a driver for the bus associated with a IHS FPGA. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
| * misc: Sort Makefile entriesMario Six2018-11-141-30/+31
| | | | | | | | | | | | | | | | | | Makefile entries should be sorted. Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc> Signed-off-by: Anatolij Gustschin <agust@denx.de>
| * regmap: Improve error handlingMario Six2018-11-141-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | ofnode_read_simple_addr_cells may fail and return a negative error code. Check for this when initializing regmaps. Also check if both_len is zero, since this is perfectly possible, and would lead to a division-by-zero further down the line. Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
| * regmap: Add documentationMario Six2018-11-141-0/+6
| | | | | | | | | | | | | | | | Document the regmap_alloc() function. Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
| * timer: Sort Kconfig driver entriesBin Meng2018-11-141-55/+55
| | | | | | | | | | | | | | This is currently out of order. Sort it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * dm: core: Mirror the chosen node parse logic in the livetree scanningBin Meng2018-11-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f2006808f099: ("dm: core: parse chosen node") added a logic to parse the chosen node during dm_scan_fdt_node(), but unfortunately it missed adding the same logic in dm_scan_fdt_live(). This mirrors the logic in the livetree version. The weird thing is that commit f2006808f099 did update the test case to test such logic, but even if I reset to that commit, the test case still fails, and I have no idea how it could pass. With this fix, the following 2 test cases now pass: Test: dm_test_bus_children: bus.c test/dm/bus.c:112, dm_test_bus_children(): num_devices == list_count_items(&uc->dev_head): Expected 7, got 6 Test: dm_test_fdt: test-fdt.c test/dm/test-fdt.c:184, dm_test_fdt(): num_devices == list_count_items(&uc->dev_head): Expected 7, got 6 Fixes: f2006808f099 ("dm: core: parse chosen node") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()Bin Meng2018-11-146-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the comments of several APIs (eg: dm_init_and_scan()) say: @pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC flag. If false bind all drivers. The 'Pre-Relocation Support' chapter in doc/driver-model/README.txt documents the same that both device tree properties and driver flag are supported. However the implementation only checks these special device tree properties without checking the driver flag at all. This updates lists_bind_fdt() to consider both scenarios. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Squashed in http://patchwork.ozlabs.org/patch/996473/ : Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: util: Add a livetree equivalent API of dm_fdt_pre_reloc()Bin Meng2018-11-141-0/+25
| | | | | | | | | | | | | | | | This adds a new API dm_ofnode_pre_reloc(), a livetree equivalent API of dm_fdt_pre_reloc(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * cpu: mpc83xx: Remove unnecessary characters in the description stringBin Meng2018-11-141-1/+1
| | | | | | | | | | | | | | | | The description string should not contain unnecessary characters, like the ending '\n' or the leading 'CPU:'. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | Merge branch 'master' of git://git.denx.de/u-boot-sunxiTom Rini2018-11-143-14/+45
|\ \ | |/ |/|
| * sunxi: use 6MHz PLL_VIDEO step for DE2 for higher resolution LCDIcenowy Zheng2018-11-131-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | DE2 SoCs can support LCDs up to 1080p (e.g. A64), and 3MHz step won't let PLL_VIDEO be high enough for them. Use 6MHz step for PLL_VIDEO when using DE2, to satisfy 1080p LCD. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Jagan Teki <jagan@openedev.com>
| * dm: video: bridge: don't fail to activate bridge if reset or sleep GPIO is ↵Vasily Khoruzhick2018-11-131-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | missing Both GPIOs are optional, so we shouldn't fail if any is missing. Without this fix reset is not deasserted if sleep GPIO is missing. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Cc: Vagrant Cascadian <vagrant@debian.org>
generated by cgit v1.2.3 (git 2.39.2)