brain-hackers_pepepper-mirror
/
u-boot-brain
mirror of https://github.com/brain-hackers/u-boot-brain
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
u-boot-brain/include/dm/uclass-id.h

135 lines
5.2 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 06:58:06 +09:00
/* SPDX-License-Identifier: GPL-2.0+ */
dm: Add base driver model support Add driver model functionality for generic board. This includes data structures and base code for registering devices and uclasses (groups of devices with the same purpose, e.g. all I2C ports will be in the same uclass). The feature is enabled with CONFIG_DM. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
2014-02-27 07:59:18 +09:00
/*
* Copyright (c) 2013 Google, Inc
*
* (C) Copyright 2012
* Pavel Herrmann <morpheus.ibis@gmail.com>
*/
#ifndef _DM_UCLASS_ID_H
#define _DM_UCLASS_ID_H
/* TODO(sjg@chromium.org): this could be compile-time generated */
enum uclass_id {
/* These are used internally by driver model */
UCLASS_ROOT = 0,
UCLASS_DEMO,
UCLASS_TEST,
UCLASS_TEST_FDT,
dm: Provide a function to scan child FDT nodes At present only root nodes in the device tree are scanned for devices. But some devices can have children. For example a SPI bus may have several children for each of its chip selects. Add a function which scans subnodes and binds devices for each one. This can be used for the root node scan also, so change it. A device can call this function in its bind() or probe() methods to bind its children. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 21:55:18 +09:00
UCLASS_TEST_BUS,
dm: core: Test uclass_first/next_device() on probe failure Add some tests which check the behaviour of uclass_first_device() and uclass_next_device() when probing of a device fails. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-24 11:10:44 +09:00
UCLASS_TEST_PROBE,
core: ofnode: Fix translation for #size-cells == 0 Commit 286ede6 ("drivers: core: Add translation in live tree case") made dev_get_addr always use proper bus translations for addresses read from the device tree. But this leads to problems with certain busses, e.g. I2C busses, which run into an error during translation, and hence stop working. It turns out that of_translate_address() and fdt_translate_address() stop the address translation with an error when they're asked to translate addresses for busses where #size-cells == 0 (comment from drivers/core/of_addr.c): * Note: We consider that crossing any level with #size-cells == 0 to mean * that translation is impossible (that is we are not dealing with a value * that can be mapped to a cpu physical address). This is not really specified * that way, but this is traditionally the way IBM at least do things To fix this case, we check in both the live-tree and non-live tree-case, whether the bus of the device whose address is about to be translated has size-cell size zero. If this is the case, we just read the address as a plain integer and return it, and only apply bus translations if the size-cell size if greater than zero. Signed-off-by: Mario Six <mario.six@gdsys.cc> Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com> Reported-by: Martin Fuzzey <mfuzzey@parkeon.com> Fixes: 286ede6 ("drivers: core: Add translation in live tree case") Reviewed-by: Simon Glass <sjg@chromium.org>
2018-03-12 22:53:33 +09:00
UCLASS_TEST_DUMMY,
dm: test: Add a test driver for devres Add a driver which does devres allocations so that we can write tests for devres. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-12-30 13:19:25 +09:00
UCLASS_TEST_DEVRES,
acpi: Add a simple sandbox test 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>
2020-04-09 07:57:34 +09:00
UCLASS_TEST_ACPI,
dm: sandbox: Add a SPI emulation uclass U-Boot includes a SPI emulation driver already but it is not explicit, and is hidden in the SPI flash code. Conceptually with sandbox's SPI implementation we have a layer which creates SPI bus transitions and a layer which interprets them, currently only for SPI flash. The latter is actually an emulation, and it should be possible to add more than one emulation - not just SPI flash. Add a SPI emulation uclass so that other emulations can be plugged in to support different types of emulated devices on difference buses/chip selects. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
2014-10-14 14:41:53 +09:00
UCLASS_SPI_EMUL, /* sandbox SPI device emulator */
dm: i2c: Add I2C emulation driver for sandbox In order to test I2C we need some sort of emulation interface. Add hooks to allow a driver to emulate an I2C device for sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-12-11 00:55:49 +09:00
UCLASS_I2C_EMUL, /* sandbox I2C device emulator */
dm: sandbox: i2c: Add a new 'emulation parent' uclass 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>
2018-11-19 00:14:33 +09:00
UCLASS_I2C_EMUL_PARENT, /* parent for I2C device emulators */
dm: sandbox: pci: Add a PCI emulation uclass Since sandbox does not have real devices (unless it borrows those from the host) it must use emulations. Provide a uclass which permits PCI operations to be passed through to an emulation device. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-06 04:25:28 +09:00
UCLASS_PCI_EMUL, /* sandbox PCI device emulator */
pci: sandbox: Move the emulators into their own node 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>
2019-09-25 23:56:10 +09:00
UCLASS_PCI_EMUL_PARENT, /* parent for PCI device emulators */
dm: usb: sandbox: Add a uclass for USB device emulation With sandbox we want to be able to emulate USB devices so that we can test the USB stack. Add a uclass to support this. It implements the same operations as a normal USB device driver, but in this case passes them on to an emulation driver. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-26 03:22:37 +09:00
UCLASS_USB_EMUL, /* sandbox USB bus device emulator */
axi: Add AXI sandbox driver and simple emulator Add test infrastructure and tests for the AXI uclass. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-08-09 21:51:18 +09:00
UCLASS_AXI_EMUL, /* sandbox AXI bus device emulator */
dm: Add base driver model support Add driver model functionality for generic board. This includes data structures and base code for registering devices and uclasses (groups of devices with the same purpose, e.g. all I2C ports will be in the same uclass). The feature is enabled with CONFIG_DM. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
2014-02-27 07:59:18 +09:00
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
/* U-Boot uclasses start here - in alphabetical order */
x86: power: Add an ACPI PMC uclass 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>
2019-12-07 13:41:53 +09:00
UCLASS_ACPI_PMC, /* (x86) Power-management controller (PMC) */
dm: adc: add simple ADC uclass implementation This commit adds: - new uclass id: UCLASS_ADC - new uclass driver: drivers/adc/adc-uclass.c The new uclass's API allows for ADC operation on: * single-channel with channel selection by a number * multti-channel with channel selection by bit mask ADC uclass's functions: * single-channel: - adc_start_channel() - start channel conversion - adc_channel_data() - get conversion data - adc_channel_single_shot() - start/get conversion data * multi-channel: - adc_start_channels() - start selected channels conversion - adc_channels_data() - get conversion data - adc_channels_single_shot() - start/get conversion data for channels selected by bit mask * general: - adc_stop() - stop the conversion - adc_vdd_value() - positive reference Voltage value with polarity [uV] - adc_vss_value() - negative reference Voltage value with polarity [uV] - adc_data_mask() - conversion data bit mask The device tree can provide below constraints/properties: - vdd-polarity-negative: if true: Vdd = vdd-microvolts * (-1) - vss-polarity-negative: if true: Vss = vss-microvolts * (-1) - vdd-supply: phandle to Vdd regulator's node - vss-supply: phandle to Vss regulator's node And optional, checked only if the above corresponding, doesn't exist: - vdd-microvolts: positive reference Voltage [uV] - vss-microvolts: negative reference Voltage [uV] Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2015-10-27 21:08:00 +09:00
UCLASS_ADC, /* Analog-to-digital converter */
dm: Rename disk uclass to ahci This started as 'ahci' and was renamed to 'disk' during code review. But it seems that this is too generic. Now that we have a 'blk' uclass, we can use that as the generic piece, and revert to ahci for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-05-02 02:35:52 +09:00
UCLASS_AHCI, /* SATA disk controller */
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. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-12-11 02:37:33 +09:00
UCLASS_AUDIO_CODEC, /* Audio codec with control and data path */
dm: (re)sort uclass ids alphabetically 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>
2018-11-26 03:38:54 +09:00
UCLASS_AXI, /* AXI bus */
dm: blk: Add a block-device uclass Add a uclass for block devices. These provide block-oriented data access, supporting reading, writing and erasing of whole blocks. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com>
2016-03-01 07:25:55 +09:00
UCLASS_BLK, /* Block device */
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>
2018-11-28 07:00:18 +09:00
UCLASS_BOOTCOUNT, /* Bootcount backing store */
dm: button: add an uclass for button 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>
2020-07-25 01:19:45 +09:00
UCLASS_BUTTON, /* Button */
dm: cache: Create a uclass for cache 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>
2019-04-24 06:55:03 +09:00
UCLASS_CACHE, /* Cache controller */
dm: Add a clock uclass Clocks are an important feature of platforms and have become increasing complex with time. Most modern SoCs have multiple PLLs and dozens of clock dividers which distribute clocks to on-chip peripherals. Some SoC implementations have a clock API which is private to that SoC family, e.g. Tegra and Exynos. This is useful but it would be better to have a common API that can be understood and used throughout U-Boot. Add a simple clock API as a starting point. It supports querying and setting the rate of a clock. Each clock is a device. To reduce memory and processing overhead the concept of peripheral clocks is provided. These do not need to be explicit devices - it is possible to write a driver that can adjust the I2C clock (for example) without an explicit I2C clock device. This can dramatically reduce the number of devices (and associated overhead) in a complex SoC. Clocks are referenced by a number, and it is expected that SoCs will define that numbering themselves via an enum. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-24 06:39:15 +09:00
UCLASS_CLK, /* Clock source, e.g. used by peripherals */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_CPU, /* CPU, typically part of an SoC */
UCLASS_CROS_EC, /* Chrome OS EC */
dm: video: Repurpose the 'displayport' uclass to 'display' The current DisplayPort uclass is too specific. The operations it provides are shared with other types of output devices, such as HDMI and LVDS LCD displays. Generalise the uclass so that it can be used with these devices as well. Adjust the uclass to handle the EDID reading and conversion to display_timing internally. Also update nyan-big which is affected by this. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 11:45:00 +09:00
UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */
dm: Add a dsi host uclass 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>
2019-10-07 22:29:05 +09:00
UCLASS_DSI_HOST, /* Display Serial Interface host */
dm: implement a DMA uclass Implement a DMA uclass so that the devices like ethernet, spi, mmc etc can offload the data transfers from/to the device and memory. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagan Teki <jteki@openedev.com>
2016-02-15 19:01:37 +09:00
UCLASS_DMA, /* Direct Memory Access */
efi_driver: EFI block driver This patch provides * a uclass for EFI drivers * a EFI driver for block devices For each EFI driver the uclass * creates a handle * adds the driver binding protocol The uclass provides the bind, start, and stop entry points for the driver binding protocol. In bind() and stop() it checks if the controller implements the protocol supported by the EFI driver. In the start() function it calls the bind() function of the EFI driver. In the stop() function it destroys the child controllers. The EFI block driver binds to controllers implementing the block io protocol. When the bind function of the EFI block driver is called it creates a new U-Boot block device. It installs child handles for all partitions and installs the simple file protocol on these. The read and write functions of the EFI block driver delegate calls to the controller that it is bound to. A usage example is as following: U-Boot loads the iPXE snp.efi executable. iPXE connects an iSCSI drive and exposes a handle with the block IO protocol. It calls ConnectController. Now the EFI block driver installs the partitions with the simple file protocol. iPXE uses the simple file protocol to load Grub or the Linux Kernel. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: add comment on calloc len] Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-22 03:29:30 +09:00
UCLASS_EFI, /* EFI managed devices */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_ETH, /* Ethernet device */
net: Add eth phy generic driver for shared MDIO 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>
2020-05-03 23:41:14 +09:00
UCLASS_ETH_PHY, /* Ethernet PHY device */
dm: (re)sort uclass ids alphabetically 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>
2018-11-26 03:38:54 +09:00
UCLASS_FIRMWARE, /* Firmware */
common: Generic loader for file system 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>
2018-07-06 17:28:03 +09:00
UCLASS_FS_FIRMWARE_LOADER, /* Generic loader */
dm: Tidy up some header file comments Fix up the style of a few comments and add/clarify a few others. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 21:55:17 +09:00
UCLASS_GPIO, /* Bank of general-purpose I/O pins */
dm: Add Hardware Spinlock class 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>
2018-11-27 21:49:50 +09:00
UCLASS_HWSPINLOCK, /* Hardware semaphores */
dm: i2c: Add a uclass for I2C The uclass implements the same operations as the current I2C framework but makes some changes to make it fit driver model better: - Remove the chip address from API calls - Remove the address length from API calls - Remove concept of 'current' I2C bus - Drop all existing init functions Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Simon Glass <sjg@chromium.org>
2014-12-11 00:55:47 +09:00
UCLASS_I2C, /* I2C bus */
dm: Add a simple EEPROM driver There seem to be a few EEPROM drivers around - perhaps we should have a single standard one? This simple driver is used for sandbox testing, but could be pressed into more active service. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-12-11 00:55:54 +09:00
UCLASS_I2C_EEPROM, /* I2C EEPROM device */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_I2C_GENERIC, /* Generic I2C device */
dm: i2c: Add support for multiplexed I2C buses Add a new I2C_MUX uclass. Devices in this class can multiplex between several I2C buses, selecting them one at a time for use by the system. The multiplexing mechanism is left to the driver to decide - it may be controlled by GPIOs, for example. The uclass supports only two methods: select() and deselect(). The current mux state is expected to be stored in the mux itself since it is the only thing that knows how to make things work. The mux can record the current state and then avoid switching unless it is necessary. So select() can be skipped if the mux is already in the correct state. Also deselect() can be made a nop if required. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-03 23:19:21 +09:00
UCLASS_I2C_MUX, /* I2C multiplexer */
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. Add a uclass and a test for i2s. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-12-11 02:37:34 +09:00
UCLASS_I2S, /* I2S bus */
block: ide: Fix block read/write with driver model This converts the IDE driver to driver model so that block read and write are fully functional. Fixes: b7c6baef ("x86: Convert MMC to driver model") Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2017-09-10 21:12:51 +09:00
UCLASS_IDE, /* IDE device */
dm: x86: Create a driver for x86 interrupts It seems likely that at some point we will want a generic interrupt uclass. But this is a big undertaking as it involves unifying code across multiple architectures. As a first step, create a simple IRQ uclass and a driver for x86. This can be generalised later as required. Adjust pirq_init() to probe this driver, which has the effect of creating routing tables and setting up the interrupt routing. This is a start towards making interrupts fit better with driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-20 13:32:25 +09:00
UCLASS_IRQ, /* Interrupt controller */
dm: usb: Add support for USB keyboards with driver model Switch USB keyboards over to use driver model instead of scanning with the horrible usb_get_dev_index() function. This involves creating a new uclass for keyboards, although so far there is no API. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-09-09 02:15:11 +09:00
UCLASS_KEYBOARD, /* Keyboard input device */
dm: Add support for LEDs Add a simple uclass for LEDs, so that these can be controlled by the device tree and activated when needed. LEDs are referred to by their label. This implementation requires a driver for each type of LED (e.g GPIO, I2C). Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-24 06:38:45 +09:00
UCLASS_LED, /* Light-emitting diode (LED) */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_LPC, /* x86 'low pin count' interface */
Add a mailbox driver framework/uclass A mailbox is a hardware mechanism for transferring small message and/or notifications between the CPU on which U-Boot runs and some other device such as an auxilliary CPU running firmware or a hardware module. This patch defines a standard API that connects mailbox clients to mailbox providers (drivers). Initially, DT is the only supported method for connecting the two. The DT binding specification (mailbox.txt) was taken from Linux kernel v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-05-14 06:50:29 +09:00
UCLASS_MAILBOX, /* Mailbox controller */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_MASS_STORAGE, /* Mass storage device */
net: introduce MDIO DM class for MDIO devices 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>
2019-06-04 01:10:30 +09:00
UCLASS_MDIO, /* MDIO bus */
net: add MDIO_MUX DM class 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>
2019-07-12 16:13:50 +09:00
UCLASS_MDIO_MUX, /* MDIO MUX/switch */
dm: implement a Miscellaneous uclass Implement a Miscellaneous uclass with generic read or write operations. This class is used only for those do not fit other more general classes. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-07 21:20:51 +09:00
UCLASS_MISC, /* Miscellaneous device */
dm: mmc: Add an MMC uclass Add basic support for MMC, providing a uclass which can set up an MMC device. This allows MMC drivers to move to using driver model. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-24 06:38:48 +09:00
UCLASS_MMC, /* SD / MMC card or chip */
DM: crypto/rsa_mod_exp: Add rsa Modular Exponentiation DM driver Add a new rsa uclass for performing modular exponentiation and implement the software driver basing on this uclass. Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> CC: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
2015-01-23 19:31:52 +09:00
UCLASS_MOD_EXP, /* RSA Mod Exp device */
dm: implement a MTD uclass Implement a Memory Technology Device (MTD) uclass. It should include most flash drivers in the future. Though no uclass ops are defined yet, the MTD ops could be used. The NAND flash driver is based on MTD. The CFI flash and SPI flash support MTD, too. It should make sense to convert them to MTD uclass. Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
2015-11-07 15:20:31 +09:00
UCLASS_MTD, /* Memory Technology Device (MTD) device */
drivers: Add a new framework for multiplexer devices 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>
2020-10-16 19:46:30 +09:00
UCLASS_MUX, /* Multiplexer device */
dm: Add a No-op uclass 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>
2019-07-05 16:33:57 +09:00
UCLASS_NOP, /* No-op devices */
dm: x86: Add a northbridge uclass Add a uclass for the northbridge / SDRAM controller found on some older Intel chipsets. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-18 08:11:14 +09:00
UCLASS_NORTHBRIDGE, /* Intel Northbridge / SDRAM controller */
dm: blk: part: Add UCLASS_NVME and IF_TYPE_NVME This adds a new uclass id and block interface type for NVMe. Signed-off-by: Zhikang Zhang <zhikang.zhang@nxp.com> Signed-off-by: Wenbin Song <wenbin.song@nxp.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Jon Nettleton <jon@solid-run.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-08-03 18:30:56 +09:00
UCLASS_NVME, /* NVM Express device */
pci: Add support for p2sb uclass 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>
2019-12-07 13:41:55 +09:00
UCLASS_P2SB, /* (x86) Primary-to-Sideband Bus */
dm: panel: Add a panel uclass LCD panels can usefully be modelled as their own uclass. They can be probed (which powers them up ready for use). If they have a backlight, this can be enabled. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 11:44:58 +09:00
UCLASS_PANEL, /* Display panel, such as an LCD */
dm: backlight: Add a backlight uclass LCD panels normally have a backlight which can be controlled to illuminate the LCD contents. Add a uclass to support this. Initially it only has a method to enable the backlight. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 11:44:56 +09:00
UCLASS_PANEL_BACKLIGHT, /* Backlight controller for panel */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_PCH, /* x86 platform controller hub */
dm: pci: Add a uclass for PCI Add a uclass for PCI controllers and a generic one for PCI devices. Adjust the 'pci' command and the existing PCI support to work with this new uclass. Keep most of the compatibility code in a separate file so that it can be removed one day. TODO: Add more header file comments to the new parts of pci.h Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-06 04:25:25 +09:00
UCLASS_PCI, /* PCI bus */
drivers: pci_ep: Introduce UCLASS_PCI_EP uclass 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>
2019-04-27 17:15:21 +09:00
UCLASS_PCI_EP, /* PCI endpoint device */
dm: pci: Add a uclass for PCI Add a uclass for PCI controllers and a generic one for PCI devices. Adjust the 'pci' command and the existing PCI support to work with this new uclass. Keep most of the compatibility code in a separate file so that it can be removed one day. TODO: Add more header file comments to the new parts of pci.h Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-06 04:25:25 +09:00
UCLASS_PCI_GENERIC, /* Generic PCI bus device */
drivers: phy: add generic PHY framework The PHY framework provides a set of APIs to control a PHY. This API is derived from the linux version of the generic PHY framework. Currently the API supports init(), deinit(), power_on, power_off() and reset(). The framework provides a way to get a reference to a phy from the device-tree. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-04-24 18:51:27 +09:00
UCLASS_PHY, /* Physical Layer (PHY) device */
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 12:44:29 +09:00
UCLASS_PINCONFIG, /* Pin configuration node device */
dm: Sort the uclass id in alphabetical order Some uclass ids are out of order. Per the comments, sort them in alphabetical order. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-06-22 18:29:47 +09:00
UCLASS_PINCTRL, /* Pinctrl (pin muxing/configuration) device */
dm: Sort the uclass IDs after the tegra/PMIC addition Tidy up the sort order again. Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Joe Hershberger <joe.hershberger@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-23 06:42:14 +09:00
UCLASS_PMIC, /* PMIC I/O device */
Add a power domain framework/uclass Many SoCs allow power to be applied to or removed from portions of the SoC (power domains). This may be used to save power. This API provides the means to control such power management hardware. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-07-14 04:45:31 +09:00
UCLASS_POWER_DOMAIN, /* (SoC) Power domains */
dm: (re)sort uclass ids alphabetically 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>
2018-11-26 03:38:54 +09:00
UCLASS_PWM, /* Pulse-width modulator */
dm: Add a power sequencing uclass Some devices need special sequences to be used when starting up. Add a uclass for this. Drivers can be added to provide specific features as needed. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 11:43:31 +09:00
UCLASS_PWRSEQ, /* Power sequence device */
dm: Sort the uclass id in alphabetical order Some uclass ids are out of order. Per the comments, sort them in alphabetical order. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-06-22 18:29:47 +09:00
UCLASS_RAM, /* RAM controller */
dm: Sort the uclass IDs after the tegra/PMIC addition Tidy up the sort order again. Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Joe Hershberger <joe.hershberger@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-23 06:42:14 +09:00
UCLASS_REGULATOR, /* Regulator device */
drivers: Introduce a simplified remoteproc framework Many System on Chip(SoC) solutions are complex with multiple processors on the same die dedicated to either general purpose of specialized functions. Many examples do exist in today's SoCs from various vendors. Typical examples are micro controllers such as an ARM M3/M0 doing a offload of specific function such as event integration or power management or controlling camera etc. Traditionally, the responsibility of loading up such a processor with a firmware and communication has been with a High Level Operating System(HLOS) such as Linux. However, there exists classes of products where Linux would need to expect services from such a processor or the delay of Linux and operating system being able to load up such a firmware is unacceptable. To address these needs, we need some minimal capability to load such a system and ensure it is started prior to an Operating System(Linux or any other) is started up. NOTE: This is NOT meant to be a solve-all solution, instead, it tries to address certain class of SoCs and products that need such a solution. A very simple model is introduced here as part of the initial support that supports microcontrollers with internal memory (no MMU, no execution from external memory, or specific image format needs). This basic framework can then (hopefully) be extensible to other complex SoC processor support as need be. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-09-18 05:42:39 +09:00
UCLASS_REMOTEPROC, /* Remote Processor device */
Add a reset driver framework/uclass A reset controller is a hardware module that controls reset signals that affect other hardware modules or chips. This patch defines a standard API that connects reset clients (i.e. the drivers for devices affected by reset signals) to drivers for reset controllers/providers. Initially, DT is the only supported method for connecting the two. The DT binding specification (reset.txt) was taken from Linux kernel v4.5's Documentation/devicetree/bindings/reset/reset.txt. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-06-18 00:43:58 +09:00
UCLASS_RESET, /* Reset controller device */
dm: rng: Add random number generator(rng) uclass 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>
2019-12-29 03:28:27 +09:00
UCLASS_RNG, /* Random Number Generator */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_RTC, /* Real time clock device */
firmware: add SCMI agent uclass 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>
2020-09-10 01:44:00 +09:00
UCLASS_SCMI_AGENT, /* Interface with an SCMI server */
dm: Add support for scsi/sata based devices All sata based drivers are bind and corresponding block device is created. Based on this find_scsi_device() is able to get back block device based on scsi_curr_dev pointer. intr_scsi() is commented now but it can be replaced by calling find_scsi_device() and scsi_scan(). scsi_dev_desc[] is commented out but common/scsi.c heavily depends on it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol is reassigned to a block description allocated by uclass. There is only one block description by device now but it doesn't need to be correct when more devices are present. scsi_bind() ensures corresponding block device creation. uclass post_probe (scsi_post_probe()) is doing low level init. SCSI/SATA DM based drivers requires to have 64bit base address as the first entry in platform data structure to setup mmio_base. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-09-08 22:06:45 +09:00
UCLASS_SCSI, /* SCSI device */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_SERIAL, /* Serial UART */
dm: core: Put UCLASS_SIMPLE_BUS in order 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>
2018-11-19 00:14:32 +09:00
UCLASS_SIMPLE_BUS, /* Bus with child devices */
dm: SMEM (Shared memory) uclass This is a uclass for Shared memory manager drivers. A Shared Memory Manager driver implements an interface for allocating and accessing items in the memory area shared among all of the processors. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2018-07-02 08:57:55 +09:00
UCLASS_SMEM, /* Shared memory interface */
dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matching 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>
2020-07-16 13:39:57 +09:00
UCLASS_SOC, /* SOC Device */
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. Add a uclass and a test for sound. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-12-11 02:37:36 +09:00
UCLASS_SOUND, /* Playing simple sounds */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_SPI, /* SPI bus */
UCLASS_SPI_FLASH, /* SPI flash */
dm: Sort the uclass IDs after the tegra/PMIC addition Tidy up the sort order again. Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Joe Hershberger <joe.hershberger@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-23 06:42:14 +09:00
UCLASS_SPI_GENERIC, /* Generic SPI flash target */
dm: (re)sort uclass ids alphabetically 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>
2018-11-26 03:38:54 +09:00
UCLASS_SPMI, /* System Power Management Interface bus */
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-24 06:38:43 +09:00
UCLASS_SYSCON, /* System configuration device */
board: Rename uclass to sysinfo 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>
2020-11-05 22:32:05 +09:00
UCLASS_SYSINFO, /* Device information from hardware */
Rename reset to sysreset The current reset API implements a method to reset the entire system. In the near future, I'd like to introduce code that implements the device tree reset bindings; i.e. the equivalent of the Linux kernel's reset API. This controls resets to individual HW blocks or external chips with reset signals. It doesn't make sense to merge the two APIs into one since they have different semantic purposes. Resolve the naming conflict by renaming the existing reset API to sysreset instead, so the new reset API can be called just reset. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-05-13 03:03:35 +09:00
UCLASS_SYSRESET, /* System reset device */
Add UCLASS_TEE for Trusted Execution Environment 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>
2018-09-25 23:40:09 +09:00
UCLASS_TEE, /* Trusted Execution Environment device */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_THERMAL, /* Thermal sensor */
dm: implement a Timer uclass Implement a Timer uclass to work with lib/time.c. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-09 14:46:34 +09:00
UCLASS_TIMER, /* Timer device */
dm: tpm: Add a uclass for Trusted Platform Modules Add a new uclass for TPMs which uses almost the same TIS (TPM Interface Specification) as is currently implemented. Since init() is handled by the normal driver model probe() method, we don't need to implement that. Also rename the transfer method to xfer() which is a less clumbsy name. Once all drivers and users are converted to driver model we can remove the old code. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Christophe Ricard<christophe-h.ricard@st.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2015-08-23 09:31:31 +09:00
UCLASS_TPM, /* Trusted Platform Module TIS interface */
ufs: Add Initial Support for UFS subsystem 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>
2019-10-15 21:54:36 +09:00
UCLASS_UFS, /* Universal Flash Storage */
dm: usb: Add a uclass for USB controllers Add a uclass that can represent a USB controller. For now we do not create devices for things attached to the controller. This will be added later. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-26 03:21:59 +09:00
UCLASS_USB, /* USB bus */
dm: usb: Bind generic USB devices when there is no driver At present USB devices with no driver model driver cannot be seen in the device list, and we fail to set them up correctly. This means they cannot be used. While having real drivers that support driver model for all USB devices is the eventual goal, we are not there yet. As a stop-gap, add a generic USB driver which is bound when we do not have a real driver. This allows the device to be set up and shown on the bus. It also allows ad-hoc code (such as usb_ether) to find these devices and set them up. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-26 03:22:31 +09:00
UCLASS_USB_DEV_GENERIC, /* USB generic device */
dm: core: Sort the uclasses Sort uclasses into alphabetical order and tidy up the comments. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 12:03:19 +09:00
UCLASS_USB_HUB, /* USB hub */
dm: usb: create a new UCLASS ID for USB gadget devices 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>
2018-11-29 18:52:46 +09:00
UCLASS_USB_GADGET_GENERIC, /* USB generic device */
dm: video: Add a video uclass U-Boot has separate code for LCDs and 'video' devices. Both now use a very similar API thanks to earlier work by Nikita Kiryanov. With the driver- model conversion we should unify these into a single uclass. Unfortunately there are different features supported by each. This implementation provides for a common set of features which should serve most purposes. The intent is to support: - bitmap devices with 8, 16 and 32 bits per pixel - text console wih white on black or vice versa - rotated text console - bitmap display (BMP format) More can be added as additional boards are ported over to use driver model for video. The name 'video' is chosen for the uclass since it is more generic than LCD. Another option would be 'display' but that would introduce a third concept to U-Boot which seems like the wrong approach. The existing LCD and video init functions are not needed now, so this uclass makes no attempt to implement them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 11:52:15 +09:00
UCLASS_VIDEO, /* Video or LCD device */
dm: video: Add support for video bridges A video bridge typically converts video from one format to another, e.g. DisplayPort to LVDS. Add driver model support for these with a simple interface to control activation and backlight. The uclass supports GPIO control of power and reset lines. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-03 09:16:08 +09:00
UCLASS_VIDEO_BRIDGE, /* Video bridge, e.g. DisplayPort to LVDS */
dm: video: Add a uclass for the text console The existing LCD/video interface suffers from conflating the bitmap display with text output on that display. As a result the implementation is more complex than it needs to me. We can support multiple text console drivers. Create a separate uclass to support this, with its own API. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 11:52:17 +09:00
UCLASS_VIDEO_CONSOLE, /* Text console driver for video device */
drivers: Add OSD uclass 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>
2018-09-27 16:19:29 +09:00
UCLASS_VIDEO_OSD, /* On-screen display */
dm: Add a new uclass driver for VirtIO transport devices 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>
2018-10-15 18:21:00 +09:00
UCLASS_VIRTIO, /* VirtIO transport device */
w1: Add 1-Wire uclass 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>
2018-09-18 16:35:24 +09:00
UCLASS_W1, /* Dallas 1-Wire bus */
W1-EEPROM: Add an W1-EEPROM uclass for 1 wire EEPROMs 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>
2018-09-18 16:35:27 +09:00
UCLASS_W1_EEPROM, /* one-wire EEPROMs */
dm: Fix typo 'Watchdot' -> 'Watchdog' Signed-off-by: Chris Packham <judge.packham@gmail.com>
2019-02-18 04:48:04 +09:00
UCLASS_WDT, /* Watchdog Timer driver */
xen: pvblock: Add initial support for para-virtualized block driver 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>
2020-08-06 18:42:55 +09:00
UCLASS_PVBLOCK, /* Xen virtual block device */
dm: Add base driver model support Add driver model functionality for generic board. This includes data structures and base code for registering devices and uclasses (groups of devices with the same purpose, e.g. all I2C ports will be in the same uclass). The feature is enabled with CONFIG_DM. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
2014-02-27 07:59:18 +09:00
UCLASS_COUNT,
UCLASS_INVALID = -1,
};
#endif