summaryrefslogtreecommitdiff
path: root/include/dm/uclass-id.h
Commit message (Collapse)AuthorAgeFilesLines
* dm: hash: Add new UCLASS_HASH supportChia-Wei Wang2021-09-011-0/+1
| | | | | | | | Add UCLASS_HASH for hash driver development. Thus the hash drivers (SW or HW-accelerated) can be developed in the DM-based fashion. Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
* dm: crypto: Define UCLASS API for ECDSA signature verificationAlexandru Gagniuc2021-08-161-0/+1
| | | | | | | | | | Define a UCLASS API for verifying ECDSA signatures. Unlike UCLASS_MOD_EXP, which focuses strictly on modular exponentiation, the ECDSA class focuses on verification. This is done so that it better aligns with mach-specific implementations, such as stm32mp. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* reboot-mode: add support for reboot mode controlNandor Han2021-07-231-0/+1
| | | | | | | | | | | | A new driver uclass is created to handle the reboot mode control. The new uclass driver is updating an environment variable with the configured reboot mode. The mode is extracted from a map provided at initialization time. The map contains a list of modes and associated ids. Signed-off-by: Nandor Han <nandor.han@vaisala.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: qemu: move QFW to its own uclassAsherah Connor2021-04-121-0/+1
| | | | | | | | | | | | | We move qfw into its own uclass and split the PIO functions into a specific driver for that uclass. The PIO driver is selected in the qemu-x86 board config (this covers x86 and x86_64). include/qfw.h is cleaned up and documentation added. Signed-off-by: Asherah Connor <ashe@kivikakk.ee> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* net: Introduce DSA class for Ethernet switchesClaudiu Manoil2021-02-161-0/+1
| | | | | | | | | | | | | | | DSA stands for Distributed Switch Architecture and it covers switches that are connected to the CPU through an Ethernet link and generally use frame tags to pass information about the source/destination ports to/from CPU. Front panel ports are presented as regular ethernet devices in U-Boot and they are expected to support the typical networking commands. DSA switches may be cascaded, DSA class code does not currently support this. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
* dm: test: Add a test for DM_UC_FLAG_NO_AUTO_SEQSimon Glass2020-12-181-0/+1
| | | | | | | Check that this flag operates as expected. This patch is not earlier in this series since is uses the new behaviour of dev_seq(). Signed-off-by: Simon Glass <sjg@chromium.org>
* board: Rename uclass to sysinfoSimon Glass2020-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This uclass is intended to provide a way to obtain information about a U-Boot board. But the concept of a U-Boot 'board' is the whole system, not just one circuit board, meaning that 'board' is something of a misnomer for this uclass. In addition, the name 'board' is a bit overused in U-Boot and we want to use the same uclass to provide SMBIOS information. The obvious name is 'system' but that is so vague as to be meaningless. Use 'sysinfo' instead, since this uclass is aimed at providing information on the system. Rename everything accordingly. Note: Due to the patch delta caused by the symbol renames, this patch shows some renamed files as being deleted in one place and created in another. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* drivers: Add a new framework for multiplexer devicesJean-Jacques Hiblot2020-10-281-0/+1
| | | | | | | | | | | | Add a new subsystem that handles multiplexer controllers. The API is the same as in Linux. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> [trini: Update some error calls to use different functions or pass correct arguments] Signed-off-by: Tom Rini <trini@konsulko.com>
* firmware: add SCMI agent uclassEtienne Carriere2020-09-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces SCMI agent uclass to interact with a firmware using the SCMI protocols [1]. SCMI agent uclass currently supports a single method to request processing of the SCMI message by an identified server. A SCMI message is made of a byte payload associated to a protocol ID and a message ID, all defined by the SCMI specification [1]. On return from process_msg() method, the caller gets the service response. SCMI agent uclass defines a post bind generic sequence for all devices. The sequence binds all the SCMI protocols listed in the FDT for that SCMI agent device. Currently none, but later change will introduce protocols. This change implements a simple sandbox device for the SCMI agent uclass. The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages. To prepare for further test support, the sandbox exposes a architecture function for test application to read the sandbox emulated devices state. Currently supports 2 SCMI agents, identified by an ID in the FDT device name. The simplistic DM test does nothing yet. SCMI agent uclass is designed for platforms that embed a SCMI server in a firmware hosted somewhere, for example in a companion co-processor or in the secure world of the executing processor. SCMI protocols allow an SCMI agent to discover and access external resources as clock, reset controllers and more. SCMI agent and server communicate following the SCMI specification [1]. This SCMI agent implementation complies with the DT bindings defined in the Linux kernel source tree regarding SCMI agent description since v5.8. Links: [1] https://developer.arm.com/architectures/system-architectures/software-standards/scmi Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* xen: pvblock: Add initial support for para-virtualized block driverAnastasiia Lukianenko2020-08-141-0/+1
| | | | | | | | | | | | | | | Add initial infrastructure for Xen para-virtualized block device. This includes compile-time configuration and the skeleton for the future driver implementation. Add new class UCLASS_PVBLOCK which is going to be a parent for virtual block devices. Add new interface type IF_TYPE_PVBLOCK. Implement basic driver setup by reading XenStore configuration. Signed-off-by: Andrii Anisov <andrii_anisov@epam.com> Signed-off-by: Anastasiia Lukianenko <anastasiia_lukianenko@epam.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
* dm: button: add an uclass for buttonPhilippe Reynes2020-07-281-0/+1
| | | | | | | | | Add a new uclass for button that implements two functions: - button_get_by_label - button_get_status Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
* dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matchingDave Gerlach2020-07-251-0/+1
| | | | | | | | | | | | | | Introduce UCLASS_SOC to be used for SOC identification and attribute matching based on the SoC ID info. This allows drivers to be provided for SoCs to retrieve SoC identifying information and also for matching device attributes for selecting SoC specific data. This is useful for other device drivers that may need different parameters or quirks enabled depending on the specific device variant in use. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
* Revert "Merge tag 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm"Tom Rini2020-07-241-1/+0
| | | | | | | | | | This reverts commit 5d3a21df6694ebd66d5c34c9d62a26edc7456fc7, reversing changes made to 56d37f1c564107e27d873181d838571b7d7860e7. Unfortunately this is causing CI failures: https://travis-ci.org/github/trini/u-boot/jobs/711313649 Signed-off-by: Tom Rini <trini@konsulko.com>
* dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matchingDave Gerlach2020-07-201-0/+1
| | | | | | | | | | | | | | Introduce UCLASS_SOC to be used for SOC identification and attribute matching based on the SoC ID info. This allows drivers to be provided for SoCs to retrieve SoC identifying information and also for matching device attributes for selecting SoC specific data. This is useful for other device drivers that may need different parameters or quirks enabled depending on the specific device variant in use. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
* net: Add eth phy generic driver for shared MDIOYe Li2020-05-101-0/+1
| | | | | | | | | | | | | | | | | | | For dual ethernet controllers, the HW design may connect ETH phys to one MDIO ports. So two different ethernet drivers have to share MDIO bus. Since two ethernet drivers are independent, we can't ensure their probe order. To resolve this problem, introduce an eth phy generic driver and uclass. After eth-uclass binds, we search the mdio node and binds the phy node with the eth-phy-generic driver. When one eth driver get its phy device, the parent of phy device will probe prior than phy device. So this ensure the eth driver ownes the MDIO bus will be probed before using its MDIO. Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
* acpi: Add a simple sandbox testSimon Glass2020-04-161-0/+1
| | | | | | | | Add a sandbox test for the basic ACPI functionality we have so far. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
* Merge tag 'dm-pull-8jan20' of git://git.denx.de/u-boot-dmWIP/09Jan2020Tom Rini2020-01-091-0/+1
|\ | | | | | | dm: Increased separation of ofdata_to_platdata() and probe methods
| * dm: test: Add a test driver for devresSimon Glass2020-01-071-0/+1
| | | | | | | | | | | | | | Add a driver which does devres allocations so that we can write tests for devres. Signed-off-by: Simon Glass <sjg@chromium.org>
* | dm: rng: Add random number generator(rng) uclassSughosh Ganu2020-01-071-0/+1
|/ | | | | | | | | | Add a uclass for reading a random number seed from a random number generator device. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* pci: Add support for p2sb uclassSimon Glass2019-12-151-0/+1
| | | | | | | | | | | | | The Primary-to-Sideband bus (P2SB) is used to access various peripherals through memory-mapped I/O in a large chunk of PCI space. The space is segmented into different channels and peripherals are accessed by device-specific means within those channels. Devices should be added in the device tree as subnodes of the p2sb. This adds a uclass and enables it for sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: power: Add an ACPI PMC uclassSimon Glass2019-12-151-0/+1
| | | | | | | | | Intel x86 SoCs have a power manager/controller which handles several power-related aspects of the platform. Add a uclass for this, with a few useful operations. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* ufs: Add Initial Support for UFS subsystemFaiz Abbas2019-10-231-0/+1
| | | | | | | | | | | | | | | | | | | | | Add Support for UFS Host Controller Interface (UFSHCI) for communicating with Universal Flash Storage (UFS) devices. The steps to initialize the host controller interface are the following: - Initiate the Host Controller Initialization process by writing to the Host controller enable register. - Configure the Host Controller base address registers by allocating a host memory space and related data structures. - Unipro link startup procedure - Check for connected device - Configure UFS host controller to process requests Also register this host controller as a SCSI host controller. Taken from Linux Kernel v5.2 (drivers/scsi/ufs/ufshcd.c) and ported to U-boot. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
* dm: Add a dsi host uclassYannick Fertré2019-10-131-0/+1
| | | | | | | | | Display Serial Interface (DSI) host can usefully be modelled as their own uclass. DSI defines a serial bus and a communication protocol between the host and the device (panel, bridge). Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
* pci: sandbox: Move the emulators into their own nodeSimon Glass2019-10-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sandbox pci works using emulation drivers which are currently children of the pci device: pci-controller { pci@1f,0 { compatible = "pci-generic"; reg = <0xf800 0 0 0 0>; emul@1f,0 { compatible = "sandbox,swap-case"; }; }; }; In this case the emulation device is attached to pci device on address f800 (device 1f, function 0) and provides the swap-case functionality. However this is not ideal, since every device on a PCI bus has a child device. This is only really the case for sandbox, but we want to avoid special-case code for sandbox. Worse, child devices cannot be probed before their parents. This forces us to use 'find' rather than 'get' to obtain the emulator device. In fact the emulator devices are never probed. There is code in sandbox_pci_emul_post_probe() which tries to track when emulators are active, but at present this does not work. A better approach seems to be to add a separate node elsewhere in the device tree, an 'emulation parent'. This could be given a bogus address (such as -1) to hide the emulators away from the 'pci' command, but it seems better to keep it at the root node to avoid such hacks. Then we can use a phandle to point from the device to the correct emulator, and only on sandbox. The code to find an emulator does not interfere with normal pci operation. Add a new UCLASS_PCI_EMUL_PARENT uclass which allows finding an emulator given a bus, and finding a bus given an emulator. Update the existing device trees and the code for finding an emulator. This brings PCI emulators more into line with I2C. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: fix 3 typos in the commit message; encode bus number in the labels of swap_case_emul nodes; mention commit 4345998ae9df in sandbox_pci_get_emul()] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* net: add MDIO_MUX DM classAlex Marginean2019-07-181-0/+1
| | | | | | | | | | | | | Adds a class for MDIO MUXes, which control access to a series of downstream child MDIOs. MDIO MUX drivers are required to implement a select function used to switch between child buses. MUX children are registered as MDIO buses and they can be used just like regular MDIOs. Signed-off-by: Alex Marginean <alexm.osslist@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
* net: introduce MDIO DM class for MDIO devicesAlex Marginean2019-07-151-0/+1
| | | | | | | | | | | Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as stand-alone devices. Useful in particular for systems that support DM_ETH and have a stand-alone MDIO hardware block shared by multiple Ethernet interfaces. Signed-off-by: Alex Marginean <alexm.osslist@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
* drivers: pci_ep: Introduce UCLASS_PCI_EP uclassRamon Fried2019-07-111-0/+1
| | | | | | | | | | | | | Introduce new UCLASS_PCI_EP class for handling PCI endpoint devices, allowing to set various attributes of the PCI endpoint device, such as: * configuration space header * BAR definitions * outband memory mapping * start/stop PCI link Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* dm: Add a No-op uclassJean-Jacques Hiblot2019-07-051-0/+1
| | | | | | | | | | | | This uclass is intended for devices that do not need any features from the uclass, including binding children. This will typically be used by devices that are used to bind child devices but do not use dm_scan_fdt_dev() to do it. That is for example the case of several USB wrappers that have 2 child devices (1 for device and 1 for host) but bind only one at a any given time. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* dm: cache: Create a uclass for cacheDinh Nguyen2019-05-051-0/+1
| | | | | | | | | | The cache UCLASS will be used for configure settings that can be found in a CPU's L2 cache controller. Add a uclass and a test for cache. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
* dm: Fix typo 'Watchdot' -> 'Watchdog'Chris Packham2019-02-191-1/+1
| | | | Signed-off-by: Chris Packham <judge.packham@gmail.com>
* dm: sound: Create a uclass for soundSimon Glass2018-12-131-0/+1
| | | | | | | | | | | 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. Add a uclass and a test for sound. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: sound: Create a uclass for i2sSimon Glass2018-12-131-0/+1
| | | | | | | | | | | 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. Add a uclass and a test for i2s. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: sound: Create a uclass for audio codecsSimon Glass2018-12-131-0/+1
| | | | | | | | 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. Signed-off-by: Simon Glass <sjg@chromium.org>
* Merge tag 'for-master-20181210' of git://git.denx.de/u-boot-rockchipTom Rini2018-12-101-0/+1
|\ | | | | | | | | | | | | | | 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
| * bootcount: add uclass for bootcountPhilipp Tomsich2018-12-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'master' of git://git.denx.de/u-boot-usbTom Rini2018-12-101-0/+1
|\ \ | |/ |/| | | - DWC3 and UDC cleanup
| * dm: usb: create a new UCLASS ID for USB gadget devicesJean-Jacques Hiblot2018-12-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | UCLASS_USB_DEV_GENERIC was meant for USB devices connected to host controllers, not gadget devices. Adding a new UCLASS for gadget devices alone. Also move the generic DM code for USB gadgets in a separate file for clarity. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
* | dm: Add Hardware Spinlock classBenjamin Gaignard2018-12-061-0/+1
|/ | | | | | | | | | This is uclass for Hardware Spinlocks. It implements two mandatory operations: lock and unlock and one optional relax operation. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
* dm: (re)sort uclass ids alphabeticallyPhilipp Tomsich2018-12-051-4/+4
| | | | | | | | | The comment in uclass-id.h states that "U-Boot uclasses start here - in alphabetical order" but the subsequent list is not sorted alphabetically. This reestablishes order. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
* dm: sandbox: i2c: Add a new 'emulation parent' uclassSimon Glass2018-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sandbox i2c works using emulation drivers which are currently children of the i2c device: rtc_0: rtc@43 { reg = <0x43>; compatible = "sandbox-rtc"; emul { compatible = "sandbox,i2c-rtc"; }; }; In this case the emulation device is attached to i2c bus on address 0x43 and provides the Real-Time-Clock (RTC) functionality. However this is not ideal, since every device on an I2C bus has a child device. This is only really the case for sandbox, but we want to avoid special-case code for sandbox. A better approach seems to be to add a separate node on the bus, an 'emulation parent'. This can be given a bogus address (such as 0xff) and hides all the emulators away. Then we can use a phandle to point from the device to the correct emualtor, and only on sandbox. The code to find an emulator does not interfere with normal i2c operation. Add a new UCLASS_I2C_EMUL_PARENT uclass which allows finding an emulator given a bus, and finding a bus given an emulator. This will be used in a follow-on patch. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: core: Put UCLASS_SIMPLE_BUS in orderSimon Glass2018-11-291-1/+1
| | | | | | | | This is currently at the top in the space for internal use. But this uclass is used outside driver model and test code. Move it into the correct alpha order. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add a new uclass driver for VirtIO transport devicesBin Meng2018-11-141-0/+1
| | | | | | | | | | | | | | | | 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>
* Add UCLASS_TEE for Trusted Execution EnvironmentJens Wiklander2018-10-071-0/+1
| | | | | | | | | | | | | | | | | | Adds a uclass to interface with a TEE (Trusted Execution Environment). A TEE driver is a driver that interfaces with a trusted OS running in some secure environment, for example, TrustZone on ARM cpus, or a separate secure co-processor etc. The TEE subsystem can serve a TEE driver for a Global Platform compliant TEE, but it's not limited to only Global Platform TEEs. The over all design is based on the TEE subsystem in the Linux kernel, tailored for U-Boot. Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
* Merge git://git.denx.de/u-boot-dmTom Rini2018-09-301-0/+1
|\
| * drivers: Add board uclassMario Six2018-09-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since there is no canonical "board device" that can be used in board files, it is difficult to use DM function for board initialization in these cases. Hence, add a uclass that implements a simple "board device", which can hold devices not suitable anywhere else in the device tree, and is also able to read encoded information, e.g. hard-wired GPIOs on a GPIO expander, read-only memory ICs, etc. that carry information about the hardware. The devices of this uclass expose methods to read generic data types (integers, strings, booleans) to encode the information provided by the hardware. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
* | Merge branch 'master' of git://git.denx.de/u-boot-videoTom Rini2018-09-291-0/+1
|\ \ | | | | | | | | | Signed-off-by: Tom Rini <trini@konsulko.com>
| * | drivers: Add OSD uclassMario Six2018-09-281-0/+1
| |/ | | | | | | | | | | | | | | | | | | Some devices offer a text-based OSD (on-screen display) that can be programmatically controlled (i.e. text displayed on). Add a uclass to support such devices. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
* | W1-EEPROM: Add an W1-EEPROM uclass for 1 wire EEPROMsMaxime Ripard2018-09-281-0/+1
| | | | | | | | | | | | | | | | | | We might want to access data stored onto one wire EEPROMs. Create a framework to provide a consistent API. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> [eugen.hristev@microchip.com: reworked patch] Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
* | w1: Add 1-Wire uclassMaxime Ripard2018-09-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | We might want to use 1-Wire devices connected on boards such as EEPROMs in U-Boot. Provide a framework to be able to do that. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> [eugen.hristev@microchip.com: reworked] Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
* | common: Generic loader for file systemTien Fong Chee2018-09-281-0/+1
|/ | | | | | | | | This is file system generic loader which can be used to load the file image from the storage into target such as memory. The consumer driver would then use this loader to program whatever, ie. the FPGA device. Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
View Lorry Controller Status