summaryrefslogtreecommitdiffstats
path: root/include
Commit message (Collapse)AuthorAgeFilesLines
...
| | * | sandbox: i2c: Support i2c emulation with of-platdataSimon Glass2021-03-261-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present the i2c emulators require access to the devicetree, which is not possible (by design) with of-platdata. Add a way for drivers to record the of-platdata index of their emulator, so that we can still find the emulator. This allows i2c emulation to work with of-platdata. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | dm: Rename device_get_by_driver_info_idx()Simon Glass2021-03-261-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function finds a device by its driver_info index. With of-platdata-inst we do not use driver_info, but instead instantiate udevice records at build-time. However the semantics of using the function are the same in each case: the caller provides an index and gets back a device. So rename the function to device_get_by_ofplat_idx(), so that it can be used for both situations. The caller does not really need to worry about the details. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | dm: core: Drop device_get_by_driver_info()Simon Glass2021-03-262-30/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function is now only used in a test. Drop it. Also drop DM_DRVINFO_GET() which was the only purpose for having the function. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | clk: fixed-rate: Export driver parts for OF_PLATDATA_INSTSimon Glass2021-03-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to allow SoCs to create their own drivers for this so that they can use their own of-platdata structs. To minimise code duplication, export the driver operations and the ofdata_to_plat() setup function. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | dm: core: Include dt-decl.h automaticallySimon Glass2021-03-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When dt-structs.h is used, include the dt-decl.h header as well, so that these declarations are available. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | dm: core: Adjust uclass setup with of-platdataSimon Glass2021-03-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When OF_PLATDATA_INST is enabled we don't need to create the uclass list. Instead we just need to point to the existing list. Update the code accordingly. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | dm: core: Add macros to access the new linker listsSimon Glass2021-03-225-2/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add macros which work with instantiated devices and uclasses, as created at build time by dtoc. Include variants that can be used in data structures. These are mostly used by dtoc but it is worth documenting them fully for the occasional case where they might come up in user code. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | linker_lists: Allow use in data structuresSimon Glass2021-03-221-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present linker lists are designed for use in code. They make use of statements within expressions ({...}), for example. It is possible to generate a reference to a linker_list entry that can be used in data structures, where such features are not permitted. It requires that the reference first be declared as extern. In other words the existing macro needs to be split into two parts. Add new macros to support this. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | dtoc: Generate uclass devicesSimon Glass2021-03-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for generating a file containing uclass instances. This avoids the need to create these at run time. Update a test uclass to include a 'priv_auto' member, to increase test coverage. Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | dtoc: Support headers needed for driversSimon Glass2021-03-221-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Typically dtoc can detect the header file needed for a driver by looking for the structs that it uses. For example, if a driver as a .priv_auto that uses 'struct serial_priv', then dtoc can search header files for the definition of that struct and use the file. In some cases, enums are used in drivers, typically with the .data field of struct udevice_id. Since dtoc does not support searching for these, add a way to tell dtoc which header to use. This works as a macro included in the driver definition. Signed-off-by: Simon Glass <sjg@chromium.org>
| | * | dtoc: Support tracking the phase of U-BootSimon Glass2021-03-221-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | U-Boot operates in several phases, typically TPL, SPL and U-Boot proper. The latter does not use dtoc. In some rare cases different drivers are used for two phases. For example, in TPL it may not be necessary to use the full PCI subsystem, so a simple driver can be used instead. This works in the build system simply by compiling in one driver or the other (e.g. PCI driver + uclass for SPL; simple_bus for TPL). But dtoc has no way of knowing which code is compiled in for which phase, since it does not inspect Makefiles or dependency graphs. So to make this work for dtoc, we need to be able to explicitly mark drivers with their phase. This is done by adding an empty macro to the driver. Add support for this in dtoc. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | efi_selfest: redefine enum efi_test_phaseHeinrich Schuchardt2021-03-251-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setup will always occur before ExitBootServices(). So eliminate EFI_SETUP_AFTER_BOOTTIME_EXIT. Put the SetVirtualAddressMap() test into a separate class so that we can execute it last. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| * | | efi: Add ESRT to the EFI system tableJose Marinho2021-03-252-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ESRT is initialised during efi_init_objlist after efi_initialize_system_table(). The ESRT is recreated from scratch at the following events: - successful UpdateCapsule; - FMP instance install. The code ensures that every ESRT entry has a unique fw_class value. Limitations: - The ESRT is not updated if an FMP instance is uninstalled; - the fields image_type and flags are in the current implementation left undefined. Setting these values will require a per-platform function that returns the image_type/flags as a function of the image fw_class. CC: Heinrich Schuchardt <xypron.glpk@gmx.de> CC: Sughosh Ganu <sughosh.ganu@linaro.org> CC: AKASHI Takahiro <takahiro.akashi@linaro.org> CC: Ilias Apalodimas <ilias.apalodimas@linaro.org> CC: Andre Przywara <andre.przywara@arm.com> CC: Alexander Graf <agraf@csgraf.de> CC: nd@arm.com Signed-off-by: Jose Marinho <jose.marinho@arm.com> Remove two EFI_CALL() indirections. Move ESRT GUID in efidebug's list of GUIDs. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| * | | efi_loader: Replace config option for initrd loadingIlias Apalodimas2021-03-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd unconditionally. Although we correctly return various EFI exit codes depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the kernel loader, only falls back to the cmdline interpreted initrd if the protocol is not installed. This creates a problem for EFI installers, since they won't be able to load their own initrd and continue the installation. It also makes the feature hard to use, since we can either have a single initrd or we have to recompile u-boot if the filename changes. So let's introduce a different logic that will decouple the initrd path from the config option we currently have. When defining a UEFI BootXXXX we can use the filepathlist and store a file path pointing to our initrd. Specifically the EFI spec describes: "The first element of the array is a device path that describes the device and location of the Image for this load option. Other device paths may optionally exist in the FilePathList, but their usage is OSV specific" When the EFI application is launched through the bootmgr, we'll try to interpret the extra device path. If that points to a file that exists on our disk, we'll now install the load_file2 and the efi-stub will be able to use it. This opens up another path using U-Boot and defines a new boot flow. A user will be able to control the kernel/initrd pairs without explicit cmdline args or GRUB. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| * | | efi_loader: Add helper functions for EFIIlias Apalodimas2021-03-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A following patch introduces a different logic for loading initrd's based on the EFI_LOAD_FILE2_PROTOCOL. Since similar logic can be applied in the future for other system files (i.e DTBs), let's add some helper functions which will retrieve and parse file paths stored in EFI variables. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
| * | | efi_loader: Add device path related functions for initrd via Boot####Ilias Apalodimas2021-03-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the following patches we allow for an initrd path to be stored in Boot#### variables. Specifically we encode in the FIlePathList[] of the EFI_LOAD_OPTIONS for each Boot#### variable. The FilePathList[] array looks like this: kernel - 0xff - VenMedia(initrd GUID) - initrd1 - 0x01 initrd2 - 0xff So let's add the relevant functions to concatenate and retrieve a device path based on a Vendor GUID. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reformat function descriptions. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| * | | efi_loader: Uart device pathHeinrich Schuchardt2021-03-251-0/+10
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | When uploading an EFI binary via the UART we need to assign a device path. * Provide devicepath node to text conversion for Uart() node. * Provide function to create Uart() device path. * Add UART support to efi_dp_from_name(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| * | board: Add MT8183 pumpkin board supportFabien Parent2021-03-201-0/+41
| | | | | | | | | | | | | | | | | | Add the MT8183 pumpkin board support. Signed-off-by: Fabien Parent <fparent@baylibre.com>
| * | configs: mt8516: use bootcmd from config_distro_bootcmd.hFabien Parent2021-03-201-16/+4
| | | | | | | | | | | | | | | | | | | | | Instead of redefining our own way to boot, let's just use config_distro_bootcmd.h. Signed-off-by: Fabien Parent <fparent@baylibre.com>
| * | board: mediatek: rename pumpkin board into mt8516Fabien Parent2021-03-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | More than one pumpkin board has been made with different MediaTek SoCs. Rename the pumpkin board to follow the naming convention of all other MediaTek boards and also to not be confusing when other pumpkin boards will be added in follow-up commits. Signed-off-by: Fabien Parent <fparent@baylibre.com>
| * | arm: rmobile: Add Silicon Linux EK874 board supportLad Prabhakar2021-03-162-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EK874 development kit from Silicon Linux is made of CAT874 (the main board) and CAT875 (the sub board that goes on top of CAT874). This patch adds the required board support to boot Si-Linux EK874 board based on R8A774C0 SoC. DTS files apart from r8a774c0-ek874-u-boot.dts and r8a774c0-u-boot.dtsi have been imported from Linux kernel 5.11 commit f40ddce88593 ("Linux 5.11"). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
| * | arm: rmobile: Add HopeRun HiHope RZ/G2M board supportBiju Das2021-03-161-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HiHope RZ/G2M board from HopeRun consists of main board (HopeRun HiHope RZ/G2M main board) and sub board(HopeRun HiHope RZ/G2M sub board). The HiHope RZ/G2M sub board sits below the HiHope RZ/G2M main board. This patch adds the required board support to boot HopeRun HiHope RZ/G2M board. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
| * | Merge tag 'v2021.04-rc4' into nextTom Rini2021-03-1527-103/+205
| |\ \ | | | | | | | | | | | | Prepare v2021.04-rc4
| * | | common: SCP03 control (enable and provision of keys)Jorge Ramirez-Ortiz2021-03-132-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This Trusted Application allows enabling SCP03 as well as provisioning the keys on TEE controlled secure element (ie, NXP SE050). All the information flowing on buses (ie I2C) between the processor and the secure element must be encrypted. Secure elements are pre-provisioned with a set of keys known to the user so that the secure channel protocol (encryption) can be enforced on the first boot. This situation is however unsafe since the keys are publically available. For example, in the case of the NXP SE050, these keys would be available in the OP-TEE source tree [2] and of course in the documentation corresponding to the part. To address that, users are required to rotate/provision those keys (ie, generate new keys and write them in the secure element's persistent memory). For information on SCP03, check the Global Platform HomePage and google for that term [1] [1] globalplatform.org [2] https://github.com/OP-TEE/optee_os/ check: core/drivers/crypto/se050/adaptors/utils/scp_config.c Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | | log: Add return-checking macros for 0 being successSimon Glass2021-03-121-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing log_ret() and log_msg_ret() macros consider an error to be less than zero. But some function may return a positive number to indicate a different kind of failure. Add macros to check for that also. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | log: Handle line continuationSimon Glass2021-03-122-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When multiple log() calls are used which don't end in newline, the log prefix is prepended multiple times in the same line. This makes the output look strange. Fix this by detecting when the previous log record did not end in newline. In that case, setting a flag. Drop the unused BUFFSIZE in the test while we are here. As an example implementation, update log_console to check the flag and produce the expected output. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | log: Set up a flag byte for log recordsSimon Glass2021-03-121-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present only a single flag (force_debug) is used in log records. Before adding more, convert this into a bitfield, so more can be added without using more space. To avoid expanding the log_record struct itself (which some drivers may wish to store in memory) reduce the line-number field to 16 bits. This provides for up to 64K lines which should be enough for anyone. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | spl: test: Add a test for spl_load_simple_fit()Simon Glass2021-03-121-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As an example of an SPL test, add a new test for loading a FIT within SPL. This runs on sandbox_spl. For this to work, the text base is adjusted so that there is plenty of space available. While we are here, document struct spl_load_info properly, since this is currently ambiguous. This test only verifies the logic path. It does not actually check that the image is loaded correctly. It is not possible for sandbox's SPL to actually run u-boot.img since it currently includes u-boot.bin rather than u-boot. Further work could expand the test in that direction. The need for this was noted at: http://patchwork.ozlabs.org/project/uboot/patch/20201216000944.2832585-3-mr.nuke.me@gmail.com/ Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | sandbox: Update os_find_u_boot() to find the .img fileSimon Glass2021-03-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present this function can only locate the u-boot ELF file. For SPL it is handy to be able to locate u-boot.img since this is what would normally be loaded by SPL. Add another argument to allow this to be selected. While we are here, update the function to load SPL when running in TPL, since that is the next stage. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Allow SPL to run any available testSimon Glass2021-03-121-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | At present SPL only runs driver model tests. Update it to run all available tests, i.e. in any test suite. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Rename all linker lists to have a ut_ prefixSimon Glass2021-03-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present each test suite has its own portion of the linker_list section of the image, but other lists are interspersed. This makes it hard to enumerate all the available tests without knowing the suites that each one is in. Place all tests together in a single contiguous list by giving them common prefix not used elsewhere in U-Boot. This makes it possible to find the start and end of all tests. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Add a macros for finding tests in linker_listsSimon Glass2021-03-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present we use the linker list directly. This is not very friendly, so add a helpful macro instead. This will also allow us to change the naming later without updating this code. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Run driver-model tests using ut_run_list()Simon Glass2021-03-121-42/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use this function instead of implementing it separately for driver model. Make ut_run_tests() private since it is only used in test-main.c Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Use a local variable for test stateSimon Glass2021-03-121-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present we use a global test state for all driver-model tests. Make use of a local struct like we do with the other tests. To make this work, add functions to get and set this state. When a test starts, the state is set (so it can be used in the test). When a test finishes, the state is unset, so it cannot be used by mistake. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Add ut_run_test_live_flat() to run tests twiceSimon Glass2021-03-121-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Driver model tests are generally run twice, once with livetree enable and again with it disabled. Add a function to handle this and call it from the driver model test runner. Make ut_run_test() private since it is not used outside test-main.c now. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Use ut_run_test() to run driver model testsSimon Glass2021-03-121-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of having a separate function for running driver model tests, use the common one. Make the pre/post-run functions private since we don't need these outside of test-main.c Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Move test running into a separate functionSimon Glass2021-03-121-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a function to handle the preparation for running a test and the post-test clean-up. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Move dm_test_init() into test-main.cSimon Glass2021-03-121-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Move this function into test-main so that all the init is in one place. Rename it so that its purpose is clearer. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Drop struct dm_test_stateSimon Glass2021-03-122-19/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Driver model is a core part of U-Boot. We don't really need to have a separate test structure for the driver model tests and it makes it harder to write a test if you have to think about which type of test it is. Subsume the fields from struct dm_test_state into struct unit_test_state and delete the former. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Handle driver model reinit in test_pre_run()Simon Glass2021-03-122-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For driver model tests we want to reinit the data structures so that everything is in a known state before the test runs. This avoids one test changing something that breaks a subsequent tests. Move the call for this into test_pre_run(). Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Move delay skipping to test_pre_run()Simon Glass2021-03-121-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows delays to be skipped in sandbox tests. Move it to the common pre-init function. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Call test_pre/post_run() from driver model testsSimon Glass2021-03-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ultimately we want to get rid of the special driver model test init and use test_pre_run() and test_post_run() for all tests. As a first step, use those function to handle console recording. For now we need a special case for setting uts->start, but that wil go away once all init is in one place. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Create pre/post-run functionsSimon Glass2021-03-121-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Split out the test preparation into a separation function before expanding it. Add a post-run function as well, currently empty. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Add an overall test runnerSimon Glass2021-03-121-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new test runner that will eventually be able to run any test. For now, have it run the 'command' unit tests, so that the functionality in cmd_ut_category() moves into it. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Rename test-main.c to test-dm.cSimon Glass2021-03-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the main test function for driver model but not for other tests. Rename the file and the function so this is clear. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | test: Mark all driver model tests with a flagSimon Glass2021-03-122-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a flag for driver model tests, so we can do special processing for them. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | Merge tag 'next-2021-03-04' of ↵Tom Rini2021-03-041-22/+1
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | https://gitlab.denx.de/u-boot/custodians/u-boot-video into next - convert sunxi_display to DM_VIDEO
| | * | | video: sunxi_display: Convert to DM_VIDEOJagan Teki2021-03-031-22/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DM_VIDEO migration deadline is already expired, but around 80 Allwinner boards are still using video in a legacy way: ===================== WARNING ====================== This board does not use CONFIG_DM_VIDEO Please update the board to use CONFIG_DM_VIDEO before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== Convert the legacy video driver over to the DM_VIDEO framework. This is a minimal conversion: it doesn't use the DT for finding its resources, nor does it use DM clocks or DM devices for the outputs (LCD, HDMI, CVBS). Tested in Bananapi M1+ Plus 1920x1200 HDMI out. (Jagan) Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> [Andre: rebase and smaller fixes] Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | | | gpio: Add a way to read 3-way strapping pinsSimon Glass2021-03-031-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the internal vs. external pull resistors it is possible to get 27 different combinations from 3 strapping pins. Add an implementation of this. This involves updating the sandbox GPIO driver to model external and (weaker) internal pull resistors. The get_value() method now takes account of what is driving a pin: sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the value outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the external state and we work the final state using those flags and the internal GPIOD_PULL_UP/DOWN flags Of course the outside source does not really exist in sandbox. We are just modelling it for test purpose. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | | gpio: Replace direction_input() and direction_output()Simon Glass2021-03-031-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new update_flags() method is more flexible since it allows the driver to see the full flags all at once. Use that in preference to these two functions. Add comments to that effect. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
generated by cgit (git 2.34.1) at 2026-04-16 06:24:39 +0000