summaryrefslogtreecommitdiff
path: root/include/dm/uclass-id.h
Commit message (Collapse)AuthorAgeLines
* Add a power domain framework/uclassStephen Warren2016-07-27-0/+1
| | | | | | | | | 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>
* dm: Sort the uclass id in alphabetical orderBin Meng2016-07-11-2/+2
| | | | | | | | 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>
* Add a reset driver framework/uclassStephen Warren2016-06-19-0/+1
| | | | | | | | | | | | | | | | 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>
* Add a mailbox driver framework/uclassStephen Warren2016-05-26-0/+1
| | | | | | | | | | | | | | | | 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>
* Rename reset to sysresetStephen Warren2016-05-26-1/+1
| | | | | | | | | | | | | | 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>
* dm: Rename disk uclass to ahciSimon Glass2016-05-17-1/+1
| | | | | | | | 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>
* drivers: Add SPMI bus uclassMateusz Kulikowski2016-04-01-0/+1
| | | | | | | | | | | | Qualcom processors use proprietary bus to talk with PMIC devices - SPMI (System Power Management Interface). On wiring level it is similar to I2C, but on protocol level, it's multi-master and has simple autodetection capabilities. This commit adds simple uclass that provides bus read/write interface. Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* dm: blk: Add a block-device uclassSimon Glass2016-03-14-0/+1
| | | | | | | | | 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>
* dm: implement a DMA uclassMugunthan V N2016-02-23-0/+1
| | | | | | | | | | 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>
* ahci: Add a disk-controller uclassSimon Glass2016-01-24-0/+1
| | | | | | | | | Add a uclass ID for a disk controller. This can be used by AHCI/SATA or other controller types. There are no operations and no interface so far, but it is possible to probe a SATA device. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: x86: Add a northbridge uclassSimon Glass2016-01-24-0/+1
| | | | | | | | 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>
* dm: x86: Create a driver for x86 interruptsSimon Glass2016-01-24-0/+1
| | | | | | | | | | | | | | | | 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>
* dm: video: Repurpose the 'displayport' uclass to 'display'Simon Glass2016-01-21-1/+1
| | | | | | | | | | | | | | 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>
* dm: panel: Add a panel uclassSimon Glass2016-01-21-0/+1
| | | | | | | | 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>
* dm: backlight: Add a backlight uclassSimon Glass2016-01-21-0/+1
| | | | | | | | 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>
* dm: pwm: Add a PWM uclassSimon Glass2016-01-21-0/+1
| | | | | | | Add a uclass that supports Pulse Width Modulation (PWM) devices. It provides methods to enable/disable and configure the device. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add a power sequencing uclassSimon Glass2016-01-21-0/+1
| | | | | | | | 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>
* dm: video: Add a uclass for the text consoleSimon Glass2016-01-20-0/+1
| | | | | | | | | | | | 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>
* dm: video: Add a video uclassSimon Glass2016-01-20-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* dm: usb: Add support for USB keyboards with driver modelSimon Glass2015-11-19-0/+1
| | | | | | | | 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>
* dm: implement a MTD uclassThomas Chou2015-11-12-0/+1
| | | | | | | | | | | | 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>
* dm: adc: add simple ADC uclass implementationPrzemyslaw Marczak2015-11-02-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* dm: implement a Miscellaneous uclassThomas Chou2015-10-23-0/+1
| | | | | | | | | 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>
* dm: implement a Timer uclassThomas Chou2015-10-23-0/+1
| | | | | | | 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>
* drivers: Introduce a simplified remoteproc frameworkNishanth Menon2015-10-22-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pinctrl: add pin control uclass supportMasahiro Yamada2015-08-31-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* dm: tpm: Add a uclass for Trusted Platform ModulesSimon Glass2015-08-31-0/+1
| | | | | | | | | | | | | | 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>
* dm: video: Add support for video bridgesSimon Glass2015-08-05-0/+1
| | | | | | | | | 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>
* dm: i2c: Add support for multiplexed I2C busesSimon Glass2015-08-05-0/+1
| | | | | | | | | | | | | | | | | 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>
* dm: Add a clock uclassSimon Glass2015-07-21-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* dm: Add a system reset uclassSimon Glass2015-07-21-0/+1
| | | | | | | | | | | | | | | | It is common for system reset to be available at multiple levels in modern hardware. For example, an SoC may provide a reset option, and a board may provide its own reset for reasons of security or thoroughness. It is useful to be able to model this hardware without hard-coding the behaviour in the SoC or board. Also there is a distinction sometimes between resetting just the CPU (leaving GPIO state alone) and resetting all the PMICs, just cutting power. To achieve this, add a simple system reset uclass. It allows multiple devices to provide reset functionality and provides a way to walk through them, requesting a particular reset type until is it provided. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Add support for RAM driversSimon Glass2015-07-21-0/+1
| | | | | | | | Add support for a driver which sets up DRAM and can return information about the amount of RAM available. This is a first step towards moving RAM init to driver model. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: mmc: Add an MMC uclassSimon Glass2015-07-21-0/+1
| | | | | | | 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>
* dm: Add support for LEDsSimon Glass2015-07-21-0/+1
| | | | | | | | | 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>
* dm: Add support for generic system controllers (syscon)Simon Glass2015-07-21-0/+1
| | | | | | | | | | | 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>
* dm: Sort the uclass IDs after the tegra/PMIC additionSimon Glass2015-06-04-5/+3
| | | | | | | | 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>
* dm: regulator: add implementation of driver model regulator uclassPrzemyslaw Marczak2015-05-14-0/+1
| | | | | | | | | | | | | | | | | | This commit introduces the implementation of dm regulator API. Device tree support allows for auto binding. And by the basic uclass operations, it allows to driving the devices in a common way. For detailed informations, please look into the header file. Core files: - drivers/power/regulator-uclass.c - provides regulator common functions api - include/power/regulator.h - define all structures required by the regulator Changes: - new uclass-id: UCLASS_REGULATOR - new config: CONFIG_DM_REGULATOR Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: pmic: add implementation of driver model pmic uclassPrzemyslaw Marczak2015-05-14-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | This commit introduces the PMIC uclass implementation. It allows providing the basic I/O interface for PMIC devices. For the multi-function PMIC devices, this can be used as I/O parent device, for each IC's interface. Then, each PMIC particular function can be provided by the child device's operations, and the child devices will use its parent for read/write by the common API. Core files: - 'include/power/pmic.h' - 'drivers/power/pmic/pmic-uclass.c' The old pmic framework is still kept and is independent. For more detailed informations, please look into the header file. Changes: - new uclass-id: UCLASS_PMIC - new config: CONFIG_DM_PMIC Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: video: Add a uclass for display portSimon Glass2015-05-13-0/+1
| | | | | | | | | eDP (Embedded DisplayPort) is a standard widely used in laptops to drive LCD panels. Add a uclass for this which supports a few simple operations. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
* dm: core: Sort the uclassesSimon Glass2015-05-13-16/+16
| | | | | | | 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>
* dm: rtc: Add a uclass for real-time clocksSimon Glass2015-05-05-0/+1
| | | | | | | | | Add a uclass for real-time clocks which support getting the current time, setting it and resetting the chip to a known-working state. Some RTCs have additional registers which can be used to store settings, so also provide an interface to these. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Implement a CPU uclassSimon Glass2015-04-29-0/+1
| | | | | | | | | | It is useful to be able to keep track of the available CPUs in a multi-CPU system. This uclass is mostly intended for use with SMP systems. The uclass provides methods for getting basic information about each CPU. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: usb: sandbox: Add an emulator for USB flash devicesSimon Glass2015-04-18-0/+1
| | | | | | | | | | This emulator supports USB enumeration and allows a local file to be provided as the contents of the emulated flash stick. U-Boot can then use the file as it would a normal device, with all access passing through the usb_stor layer and the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
* dm: usb: sandbox: Add a uclass for USB device emulationSimon Glass2015-04-18-0/+1
| | | | | | | | | | 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>
* dm: usb: Bind generic USB devices when there is no driverSimon Glass2015-04-18-0/+1
| | | | | | | | | | | | | | | | | 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>
* dm: usb: Add driver model support for hubsSimon Glass2015-04-18-0/+1
| | | | | | | | Adjust the existing hub code to support driver model, and add a USB driver for hubs. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
* dm: usb: Add a uclass for USB controllersSimon Glass2015-04-18-0/+1
| | | | | | | | 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>
* dm: x86: Add a uclass for an Low Pin Count (LPC) deviceSimon Glass2015-04-18-0/+1
| | | | | | | | | On x86 systems this device is commonly used to provide legacy port access. It is sort-of a replacement for the old ISA bus. Add a uclass for this, and allow it to have child devices. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: eth: Add basic driver model support to Ethernet stackJoe Hershberger2015-04-18-0/+1
| | | | | | | First just add support for MAC drivers. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* dm: x86: pci: Convert coreboot to use driver model for pciSimon Glass2015-04-18-0/+1
| | | | | | Move coreboot-x86 over to driver model for PCI. Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-11-02 03:24:07 +0000