summaryrefslogtreecommitdiff
path: root/drivers/Kconfig
Commit message (Collapse)AuthorAgeLines
* drivers/sysreset: group sysreset driversMax Filippov2016-08-12-0/+2
| | | | | | | | Create drivers/sysreset and move sysreset-uclass and all sysreset drivers there. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* Add a reset driver framework/uclassStephen Warren2016-06-19-0/+2
| | | | | | | | | | | | | | | | 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/+2
| | | | | | | | | | | | | | | | 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>
* memory: Move TI_AEMIF config to KCONFIGLokesh Vutla2016-04-18-0/+2
| | | | | | | | | | Not all Keystone2 devices has AEMIF NAND controller. So adding Kconfig entry for CONFIG_TI_AEMIF and enabling it in respective defconfigs on platforms with AEMIF controller. Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* drivers: Add SPMI bus uclassMateusz Kulikowski2016-04-01-0/+2
| | | | | | | | | | | | 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: pwm: Add a PWM uclassSimon Glass2016-01-21-0/+2
| | | | | | | 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: adc: add simple ADC uclass implementationPrzemyslaw Marczak2015-11-02-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Timer uclassThomas Chou2015-10-23-0/+2
| | | | | | | 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/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drivers: kconfig: Sort driver menu in alphabetical orderBin Meng2015-08-31-24/+26
| | | | | | | Sort different types of drivers in alphabetical order. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* drivers: kconfig: Move PHYS_TO_BUS to "Device Drivers" menuBin Meng2015-08-31-2/+2
| | | | | | | Right now PHYS_TO_BUS shows in the Kconfig main menu, move it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* drivers: kconfig: Move "Generic Driver Options" menu to the topBin Meng2015-08-31-2/+2
| | | | | | | Make "Generic Driver Options" menu show on the top in the Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Add a clock uclassSimon Glass2015-07-21-0/+2
| | | | | | | | | | | | | | | | | | | | | | | 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 support for RAM driversSimon Glass2015-07-21-0/+2
| | | | | | | | 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: Add support for LEDsSimon Glass2015-07-21-0/+2
| | | | | | | | | 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>
* Move default y configs out of arch/board KconfigJoe Hershberger2015-06-25-1/+1
| | | | | | | | | | | | | | | | | | | Some archs/boards specify their own default by pre-defining the config which causes the Kconfig system to mix up the order of the configs in the defconfigs... This will cause merge pain if allowed to proliferate. Remove the configs that behave this way from the archs. A few configs still remain, but that is because they only exist as defaults and do not have a proper Kconfig entry. Those appear to be: SPIFLASH DISPLAY_BOARDINFO Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> [trini: rastaban, am43xx_evm_usbhost_boot, am43xx_evm_ethboot updates, drop DM_USB from MSI_Primo81 as USB_MUSB_SUNXI isn't converted yet to DM] Signed-off-by: Tom Rini <trini@konsulko.com>
* dm: Implement a CPU uclassSimon Glass2015-04-29-0/+2
| | | | | | | | | | 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>
* Create API to map between CPU physical and bus addressesStephen Warren2015-04-14-0/+8
| | | | | | | | | | | | | On some SoCs, DMA-capable peripherals see a different address space to the CPU's physical address space. Create an API to allow platform-agnostic drivers to convert between the two address spaces when programming DMA operations. This API will exist on all platforms, but will have a dummy implementation when this feature is not required. Other platforms will enable CONFIG_PHYS_TO_BUS and provide the required implementation. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* dm: Expand and complete Kconfig in drivers/Simon Glass2015-02-12-0/+2
| | | | | | | | Expand the help messages for each driver. Add missing Kconfig for I2C, SPI flash and thermal. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dm: Add Kconfig for driver/demoSimon Glass2015-02-12-0/+2
| | | | | | | Add a suitable Kconfig for this directory. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* kconfig: add blank Kconfig filesMasahiro Yamada2014-09-24-0/+51
This would be useful to start moving various config options. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>