summaryrefslogtreecommitdiff
path: root/include/dm
Commit message (Collapse)AuthorAgeLines
* dm: core: Add dev_get_addr_size_index() to retrieve addr and sizeStefan Roese2016-12-02-0/+16
| | | | | | | | | | | | The currently available functions accessing the 'reg' property of a device only retrieve the address. Sometimes its also necessary to retrieve the size described by the 'reg' property. This patch adds the new function dev_get_addr_size_index() which retrieves both, the address and the size described by the 'reg' property. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: Handle global_data moving in SPLSimon Glass2016-12-02-0/+10
| | | | | | | | | | | | | When CONFIG_SPL_STACK_R is enabled, and spl_init() is called before board_init_r(), spl_relocate_stack_gd() will move global_data to a new place in memory. This affects driver model since it uses a list for the uclasses. Unless this is updated the list will become invalid. When looking for a non-existent uclass, such as when adding a new one, the loop in uclass_find() may continue forever, thus causing a hang. Add a function to correct this rather obscure bug. Signed-off-by: Simon Glass <sjg@chromium.org>
* serial: pxa: integrate optional driver model handlingMarcel Ziswiler2016-11-23-0/+56
| | | | | | | Optional driver model handling integration. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Marek Vasut <marex@denx.de>
* dm: core: Add a function to get a uclass nameSimon Glass2016-10-11-0/+8
| | | | | | | | It is useful in debug() statements to display the name of the uclass for a device. Add a simple function to provide this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* serial: bcm283x_mu: Detect disabled serial deviceAlexander Graf2016-09-06-0/+1
| | | | | | | | | | | | | | | | | | | | On the raspberry pi, you can disable the serial port to gain dynamic frequency scaling which can get handy at times. However, in such a configuration the serial controller gets its rx queue filled up with zero bytes which then happily get transmitted on to whoever calls getc() today. This patch adds detection logic for that case by checking whether the RX pin is mapped to GPIO15 and disables the mini uart if it is not mapped properly. That way we can leave the driver enabled in the tree and can determine during runtime whether serial is usable or not, having a single binary that allows for uart and non-uart operation. Signed-off-by: Alexander Graf <agraf@suse.de> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* net/ethoc: support private memory configurationsMax Filippov2016-08-15-0/+1
| | | | | | | | | | | The ethoc device can be configured to have a private memory region instead of having access to the main memory. In that case egress packets must be copied into that memory for transmission and pointers to that memory need to be passed to net_process_received_packet or returned from the recv callback. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
* net/ethoc: add CONFIG_DM_ETH supportMax Filippov2016-08-15-0/+20
| | | | | | | | | | Extract reusable parts from ethoc_init, ethoc_set_mac_address, ethoc_send and ethoc_receive, move the rest under #ifdef CONFIG_DM_ETH. Add U_BOOT_DRIVER, eth_ops structure and implement required methods. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
* Merge branch 'master' of git://www.denx.de/git/u-boot-imxTom Rini2016-07-28-0/+1
|\
| * dm: imx: serial: Support DTE mode when using driver modelStefan Agner2016-07-19-0/+1
| | | | | | | | | | | | | | | | | | | | The MXC UART IP can be run in DTE or DCE mode. This depends on the board wiring and the pinmux used and hence is board specific. This extends platform data with a new field to choose wheather DTE mode shall be used. Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | 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: core: Add a function to bind child devicesSimon Glass2016-07-27-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use dm_scan_fdt_node() to bind devices. It is an internal function and it requires the caller to know whether we are pre- or post- relocation. This requirement has become quite common in drivers, so the current function is not ideal. Add a new function with fewer arguments, that does not require internal headers. This can be used directly as a post_bind() method if needed. Signed-off-by: Simon Glass <sjg@chromium.org>
* | dm: core: Add a way to find a device by its driverSimon Glass2016-07-25-0/+22
| | | | | | | | | | | | | | | | | | Some SoCs have a single clock device. Provide a way to find it given its driver name. This is handled by the linker so will fail if the name is not found, avoiding strange errors when names change and do not match. It is also faster than a string comparison. Signed-off-by: Simon Glass <sjg@chromium.org>
* | dm: core: Expand platdata for of-platdata devicesSimon Glass2016-07-14-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Devices which use of-platdata have their own platdata. However, in many cases the driver will have its own auto-alloced platdata, for use with the device tree. The ofdata_to_platdata() method converts the device tree settings to platdata. With of-platdata we would not normally allocate the platdata since it is provided by the U_BOOT_DEVICE() declaration. However this is inconvenient since the of-platdata struct is closely tied to the device tree properties. It is unlikely to exactly match the platdata needed by the driver. In fact a useful approach is to declare platdata in the driver like this: struct r3288_mmc_platdata { struct dtd_rockchip_rk3288_dw_mshc of_platdata; /* the 'normal' fields go here */ }; In this case we have dt_platadata available, but the normal fields are not present, since ofdata_to_platdata() is never called. In fact driver model doesn't allocate any space for the 'normal' fields, since it sees that there is already platform data attached to the device. To make this easier, adjust driver model to allocate the full size of the struct (i.e. platdata_auto_alloc_size from the driver) and copy in the of-platdata. This means that when the driver's bind() method is called, the of-platdata will be present, followed by zero bytes for the empty 'normal field' portion. A new DM_FLAG_OF_PLATDATA flag is available that indicates that the platdata came from of-platdata. When the allocation/copy happens, the DM_FLAG_ALLOC_PDATA flag will be set as well. The dtoc tool is updated to output the platdata_size field, since U-Boot has no other way of knowing the size of the of-platdata struct. Signed-off-by: Simon Glass <sjg@chromium.org>
* | dm: core: Rename DM_NAME_ALLOCED to DM_FLAG_NAME_ALLOCEDSimon Glass2016-07-14-2/+2
| | | | | | | | | | | | This is a flag. Adjust the name to be consistent with the other flags. Signed-off-by: Simon Glass <sjg@chromium.org>
* | Merge branch 'master' of git://git.denx.de/u-boot-spiTom Rini2016-07-11-0/+13
|\ \
| * | dm: core: implement dev_map_physmem()Vignesh R2016-07-09-0/+13
| |/ | | | | | | | | | | | | | | | | | | | | | | This API helps to map physical register addresss pace of device to virtual address space easily. Its just a wrapper around map_physmem() with MAP_NOCACHE flag. Signed-off-by: Vignesh R <vigneshr@ti.com> Suggested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagan Teki <jteki@openedev.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Jagan Teki <jteki@openedev.com>
* | 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: allow setting driver_data before/during bindStephen Warren2016-05-26-0/+24
| | | | | | | | | | | This will allow a driver's bind function to use the driver data. One example is the Tegra186 GPIO driver, which instantiates child devices for each of its GPIO ports, yet supports two different HW instances each with a different set of ports, and identified by the udevice_id .data field. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
* drivers: core: device: add support to check dt compatible for a device/machineMugunthan V N2016-05-24-0/+23
| | | | | | | | | | | Provide an api to check whether the given device or machine is compatible with the given compat string which helps in making decisions in drivers based on device or machine compatible. Idea taken from Linux. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
* dm: core: Allow device names to be freed automaticallySimon Glass2016-05-17-0/+16
| | | | | | | | | | Some devices have a name that is stored in allocated memory. At present there is no mechanism to free this memory when the device is unbound. Add a device flag to track whether a name is allocated and a function to add the flag. Free the memory when the device is unbound. Signed-off-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>
* m68k: add DM model serial driverangelo@sysam.it2016-05-17-0/+23
| | | | | | | | Boards can now use DM serial driver, or still legacy mcf uart driver version. Signed-off-by: Angelo Dureghello <angelo@sysam.it> Acked-by: Simon Glass <sjg@chromium.org>
* dm: core: Add dev_get_addr_ptr() to return a pointer to the reg addressStefan Roese2016-04-25-0/+10
| | | | | | | | | | | | | | | | | | On some platforms (e.g. x86), the return value of dev_get_addr() can't be assigned to a pointer type variable directly. As there might be a difference between the size of fdt_addr_t and the pointer type. On x86 for example, "fdt_addr_t" is 64bit but "void *" only 32bit. So assigning the register base directly in dev_get_addr() results in this compilation warning: warning: cast to pointer from integer of different size This patch introduces the new function dev_get_addr_ptr() that returns a pointer to the 'reg' address that can be used by drivers in this case. Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* fdt: implement dev_get_addr_name()Stephen Warren2016-04-15-0/+12
| | | | | | | | | This function parses the reg property based on an index found in the reg-names property. This is required for bindings that are written using reg-names rather than hard-coding indices in reg. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-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>
* serial: add BCM283x mini UART driverStephen Warren2016-03-27-0/+24
| | | | | | | | The RPi3 typically uses the regular UART for high-speed communication with the Bluetooth device, leaving us the mini UART to use for the serial console. Add support for this UART so we can use it. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* serial: pl01x: Add support for devices with the rate pre-configured.Eric Anholt2016-03-22-0/+3
| | | | | | | | | | | | | For Raspberry Pi, we had the input clock rate to the pl011 fixed in the rpi.c file, but it may be changed by firmware due to user changes to config.txt. Since the firmware always sets up the uart (default 115200 output unless the user changes it), we can just skip our own uart init to simplify the boot process and more reliably get serial output. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@wwwdotorg.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: core: Add uclass_first_device_err() to return a valid deviceSimon Glass2016-03-14-2/+13
| | | | | | | | A common pattern is to call uclass_first_device() and then check if it actually returns a device. Add a new function which does this, returning an error if there are no devices in that uclass. Signed-off-by: Simon Glass <sjg@chromium.org>
* stm32x7: add support for stm32x7 serial driverVikas Manocha2016-02-24-0/+17
| | | | | | | This patch adds support for stm32f7 family usart peripheral. Signed-off-by: Vikas Manocha <vikas.manocha@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* 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>
* video: sandbox: Allow selection of font size and console nameSimon Glass2016-01-30-0/+2
| | | | | | | | For testing it is useful to be able to select the font size and the console driver for sandbox. Add this information to platform data and copy it to the video device when needed. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Remove device_probe_child()Simon Glass2016-01-28-13/+0
| | | | | | | | | This function is not used as the use case for it did not eventuate. Remove it to avoid confusion. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.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: core: Export uclass_find_device_by_of_offset()Simon Glass2016-01-21-0/+16
| | | | | | | | It is sometimes useful to be able to find a device before probing it, perhaps to set up some platform data for it. Allow finding by of_offset also. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: pinctrl: Add a way for a GPIO driver to obtain a pin functionSimon Glass2016-01-21-0/+32
| | | | | | | | | | | | | GPIO drivers want to be able to show if a pin is enabled for input, output, or is being used by another function. Some drivers can easily find this and the code is included in the driver. For some SoCs this is more complex. Conceptually this should be handled by pinctrl rather than GPIO. Most pinctrl drivers will have this feature anyway. Add a method by which a GPIO driver can obtain the pin mux value given a GPIO reference. This avoids repeating the code in two places. 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: pinctrl: Add a function to parse PIN_CONFIG flagsSimon Glass2016-01-21-0/+13
| | | | | | | | Add a function which produces a flags word from a few common PIN_CONFIG settings. This is useful for simple pinctrl drivers that don't need to worry about drive strength, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: video: test: Add tests for the video uclassSimon Glass2016-01-20-0/+8
| | | | | | | | | Add tests that check that the video console is working correcty. Also check that text output produces the expected result. Test coverage includes character output, wrapping and scrolling. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
* 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>