Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-04 18:41:03 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/sandbox/dts/test.dts

1641 lines
31 KiB
Text
Raw Normal View History

sandbox: Add license headers to the dts files Many of these files are missing a header. Fix this. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-08-19 03:40:25 +00:00
// SPDX-License-Identifier: GPL-2.0+
/*
* Devicetree file for running sandbox tests
*
* This includes lots of extra devices used by various tests.
*
* Note that SPL use the main sandbox.dts file
*/
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
/dts-v1/;
gpio: sandbox: cleanup binding support Cleanup binding support, use the generic binding by default (test u-class gpio_xlate_offs_flags function) and add specific binding for added value. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:13 +00:00
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/gpio/sandbox-gpio.h>
test: add a simple test for the adc-keys button driver Add adc-keys device to the sandbox/test.dts and connect it to the channel #3 of the sandbox_adc driver. The default values sampled by sandbox_adc driver determines that button3 and button4 are released and button5 is pressed. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2021-02-18 10:33:18 +00:00
#include <dt-bindings/input/input.h>
test: pinmux: Add test for pin muxing This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:57 +00:00
#include <dt-bindings/pinctrl/sandbox-pinmux.h>
test: Add tests for the multiplexer framework Provide tests to check the behavior of the multiplexer framework. Two sets of tests are added. One is using an emulated multiplexer driver that can be used to test basic functionality like select, deselect, etc. The other is using the mmio mux which adds tests specific to it. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-16 10:46:34 +00:00
#include <dt-bindings/mux/mux.h>
gpio: sandbox: cleanup binding support Cleanup binding support, use the generic binding by default (test u-class gpio_xlate_offs_flags function) and add specific binding for added value. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:13 +00:00
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
/ {
model = "sandbox";
compatible = "sandbox";
#address-cells = <1>;
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
#size-cells = <1>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
dm: Allow drivers to be marked 'before relocation' Driver model currently only operates after relocation is complete. In this state U-Boot typically has a small amount of memory available. In adding support for driver model prior to relocation we must try to use as little memory as possible. In addition, on some machines the memory has not be inited and/or the CPU is not running at full speed or the data cache is off. These can reduce execution performance, so the less initialisation that is done before relocation the better. An immediately-obvious improvement is to only initialise drivers which are actually going to be used before relocation. On many boards the only such driver is a serial UART, so this provides a very large potential benefit. Allow drivers to mark themselves as 'pre-reloc' which means that they will be initialised prior to relocation. This can be done either with a driver flag or with a 'dm,pre-reloc' device tree property. To support this, the various dm scanning function now take a 'pre_reloc_only' parameter which indicates that only drivers marked pre-reloc should be bound. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 12:55:03 +00:00
aliases {
console = &uart0;
net: use the same alias stem for ethernet as linux Linux uses the prefix "ethernet" whereas u-boot uses "eth". This is from the linux tree: $ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l 0 $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l 633 In u-boot device trees both prefixes are used. Until recently the only user of the ethernet alias was the sandbox test device tree. This changed with commit fc054d563bfb ("net: Introduce DSA class for Ethernet switches"). There, the MAC addresses are inherited based on the devices sequence IDs which is in turn given by the device tree. Before there are more users in u-boot and both worlds will differ even more, rename the alias prefix to "ethernet" to match the linux ones. Also adapt the test cases and rename any old aliases in the u-boot device trees. Cc: David Wu <david.wu@rock-chips.com> Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-02-25 15:51:11 +00:00
ethernet0 = "/eth@10002000";
ethernet2 = &swp_0;
ethernet3 = &eth_3;
ethernet4 = &dsa_eth0;
ethernet5 = &eth_5;
sandbox: net: Add aliases for ethernet devices Commit f3dd213e15 ("net: introduce helpers to get PHY ofnode from MAC") changed the ethernet sequence assignment from uclass 36: ethernet 0 * eth@10002000 @ 05813460, seq 0 1 * eth@10003000 @ 05813550, seq 5 2 * sbe5 @ 05813640, seq 3 3 * eth@10004000 @ 05813730, seq 6 4 * dsa-test-eth @ 05813820, seq 4 5 * lan0 @ 05813a30, seq 2 6 * lan1 @ 05813b50, seq 7 to uclass 36: ethernet 0 * eth@10002000 @ 03813630, seq 0 1 * eth@10003000 @ 03813720, seq 5 2 * sbe5 @ 03813810, seq 3 3 * eth@10004000 @ 03813900, seq 6 4 phy-test-eth @ 038139f0, seq 7 5 * dsa-test-eth @ 03813ae0, seq 4 6 * lan0 @ 03813cf0, seq 2 7 * lan1 @ 03813e10, seq 8 This caused the mac address assignment to switch around. Avoid this in the future by assigning aliases for all ethernet devices. This reverts the sequence to what it was before the aformentioned commit (with phy-test-eth as seq 8). There is no ethernet1 for whatever reason. Signed-off-by: Sean Anderson <sean.anderson@seco.com>
2022-05-05 17:11:30 +00:00
ethernet6 = "/eth@10004000";
ethernet7 = &swp_1;
ethernet8 = &phy_eth0;
test: panel: Add a test for the panel uclass At present this uclass has no tests. Add a simple one which checks the PWM configuration, regulator and GPIO. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:40 +00:00
gpio1 = &gpio_a;
gpio2 = &gpio_b;
test: dm: update test for pins configuration in gpio Add tests for new API set_dir_flags and set_dir_flags and associated code in gpio uclass. Test support for new flags GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE GPIO_PULL_UP and GPIO_PULL_DOWN. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 10:35:14 +00:00
gpio3 = &gpio_c;
dm: core: Add a flag to control sequence numbering At present we try to use the 'reg' property and device tree aliases to give devices a sequence number. The 'reg' property is often actually a memory address, so the sequence numbers thus-obtained are not useful. It would be better if the devices were just sequentially numbered in that case. In fact neither I2C nor SPI use this feature, so drop it. Some devices need us to look up an alias to number them within the uclass. Add a flag to control this, so it is not done unless it is needed. Adjust the tests to test this new behaviour. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-01-25 15:27:05 +00:00
i2c0 = "/i2c@0";
dm: blk: Improve block device claiming The intention with block devices is that the device number (devnum field in its descriptor) matches the alias of its parent device. For example, with: aliases { mmc0 = "/sdhci@700b0600"; mmc1 = "/sdhci@700b0400"; } we expect that the block devices for mmc0 and mmc1 would have device numbers of 0 and 1 respectively. Unfortunately this does not currently always happen. If there is another MMC device earlier in the driver model data structures its block device will be created first. It will therefore get device number 0 and mmc0 will therefore miss out. In this case the MMC device will have sequence number 0 but its block device will not. To avoid this, allow a device to request a device number and bump any existing device number that is using it. This all happens during the binding phase so it is safe to change these numbers around. This allows device numbers to match the aliases in all circumstances. Add a test to verify the behaviour. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-24 02:02:07 +00:00
mmc0 = "/mmc0";
mmc1 = "/mmc1";
test: dm: pci: Test more than one PCI host controller So far there is only one PCI host controller in the sandbox test configuration. This is normally the case for x86, but it can be common on other architectures like ARM/PPC to have more than one PCI host controller in the system. This updates the case to cover such scenario. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:41 +00:00
pci0 = &pci0;
pci1 = &pci1;
test: dm: pci: Add tests for mixed static and dynamic devices on the same bus In the Sandbox test configuration, PCI bus#0 only has static devices while bus#1 only has dynamic devices. Create a bus#2 that has both types of devices and test such. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:50 +00:00
pci2 = &pci2;
dm: uclass: don't assign aliased seq numbers If there are aliases for an uclass, set the base for the "dynamically" allocated numbers next to the highest alias. Please note, that this might lead to holes in the sequences, depending on the device tree. For example if there is only an alias "ethernet1", the next device seq number would be 2. In particular this fixes a problem with boards which are using ethernet aliases but also might have network add-in cards like the E1000. If the board is started with the add-in card and depending on the order of the drivers, the E1000 might occupy the first ethernet device and mess up all the hardware addresses, because the devices are now shifted by one. Also adapt the test cases to the new handling and add test cases checking the holes in the seq numbers. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Alex Marginean <alexandru.marginean@nxp.com> Tested-by: Alex Marginean <alexandru.marginean@nxp.com> Acked-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Michal Simek <michal.simek@xilinx.com> [on zcu102-revA]
2020-06-01 23:47:09 +00:00
remoteproc0 = &rproc_1;
remoteproc1 = &rproc_2;
sandbox: dts: Add the real-time-clock test nodes back in These were lost when the PMIC series was applied. Add them back so that the tests pass again. Reported-by: Joe Hershberger <joe.hershberger@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:17 +00:00
rtc0 = &rtc_0;
rtc1 = &rtc_1;
sandbox: dts: Sort the test.dts file a little There are some core test nodes near the beginning of the file which should be grouped together. But for other nodes, let's sort them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:15 +00:00
spi0 = "/spi@0";
test: dm: test.dts - move to sandbox dts directory The file test.dts from driver model test directory, was compiled by call dtc in script: test/dm/test-dm.sh. This doesn't allow for including of dtsi files and using of C preprocessor routines in this dts file. Since the mentioned script builds U-Boot before tests, then moving the test.dts file into sandbox dts directory is reasonable. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on sandbox: Tested-by: Simon Glass <sjg@chromium.org>
2015-05-13 11:38:34 +00:00
testfdt6 = "/e-test";
dm: core: Add a flag to control sequence numbering At present we try to use the 'reg' property and device tree aliases to give devices a sequence number. The 'reg' property is often actually a memory address, so the sequence numbers thus-obtained are not useful. It would be better if the devices were just sequentially numbered in that case. In fact neither I2C nor SPI use this feature, so drop it. Some devices need us to look up an alias to number them within the uclass. Add a flag to control this, so it is not done unless it is needed. Adjust the tests to test this new behaviour. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-01-25 15:27:05 +00:00
testbus3 = "/some-bus";
testfdt0 = "/some-bus/c-test@0";
dm: Switch over to use new sequence number for dev_seq() Update this function to use the new sequence number and fix up the test that deals with this. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-17 04:20:26 +00:00
testfdt12 = "/some-bus/c-test@1";
dm: core: Add a flag to control sequence numbering At present we try to use the 'reg' property and device tree aliases to give devices a sequence number. The 'reg' property is often actually a memory address, so the sequence numbers thus-obtained are not useful. It would be better if the devices were just sequentially numbered in that case. In fact neither I2C nor SPI use this feature, so drop it. Some devices need us to look up an alias to number them within the uclass. Add a flag to control this, so it is not done unless it is needed. Adjust the tests to test this new behaviour. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-01-25 15:27:05 +00:00
testfdt3 = "/b-test";
testfdt5 = "/some-bus/c-test@5";
testfdt8 = "/a-test";
dm: test: Add a test for DM_UC_FLAG_NO_AUTO_SEQ Check that this flag operates as expected. This patch is not earlier in this series since is uses the new behaviour of dev_seq(). Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-17 04:20:27 +00:00
testfdtm1 = &testfdtm1;
test: dm: Fix wrong aliases property names After importing v4.17-rc1 Linux commit 9130ba884640 ("scripts/dtc: Update to upstream version v1.4.6-9-gaadd0b65c987"), sandbox build reports below warnings: arch/sandbox/dts/test.dtb: Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-' arch/sandbox/dts/test.dtb: Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-' arch/sandbox/dts/test.dtb: Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-' arch/sandbox/dts/test.dtb: Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-' Silent them by applying the 's/_/-/' substitution in the names of the 'fdt_dummy0', 'fdt_dummy1', 'fdt_dummy2', 'fdt_dummy3' properties. Similar DTC warnings have been recently fixed in Linux kernel, e.g. via v4.17-rc1 commit d366c30d19f4 ("ARM: dts: STi: Fix aliases property name for STi boards"). If done alone, the DTS update generates a failure of the `ut dm fdt_translation` unit test in sandbox environment as seen below: $ ./u-boot -d arch/sandbox/dts/test.dtb ---<-snip->--- => ut dm fdt_translation Test: dm_test_fdt_translation: test-fdt.c test/dm/test-fdt.c:444, dm_test_fdt_translation(): 0 == uclass_find_device_by_seq(UCLASS_TEST_DUMMY, 0, 1, &dev): Expected 0, got -19 Test: dm_test_fdt_translation: test-fdt.c (flat tree) test/dm/test-fdt.c:444, dm_test_fdt_translation(): 0 == uclass_find_device_by_seq(UCLASS_TEST_DUMMY, 0, 1, &dev): Expected 0, got -19 Failures: 2 ---<-snip->--- Fix this issue in place, by updating the "name" string in the UCLASS_DRIVER(fdt_dummy) definition, so that it matches the newly updated aliases properties. After that, the test passes: $ ./u-boot -d arch/sandbox/dts/test.dtb ---<-snip->--- => ut dm fdt_translation Test: dm_test_fdt_translation: test-fdt.c Test: dm_test_fdt_translation: test-fdt.c (flat tree) Failures: 0 ---<-snip->--- Fixes: e8d5291824e2 ("core: ofnode: Fix translation for #size-cells == 0") Reported-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-19 12:13:55 +00:00
fdt-dummy0 = "/translation-test@8000/dev@0,0";
fdt-dummy1 = "/translation-test@8000/dev@1,100";
fdt-dummy2 = "/translation-test@8000/dev@2,200";
fdt-dummy3 = "/translation-test@8000/noxlatebus@3,300/dev@42";
dm: usb: Add tests for the USB uclass This adds a simple test for probing and a functional test using the flash stick emulator, which tests a large chunk of the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-25 18:23:05 +00:00
usb0 = &usb_0;
usb1 = &usb_1;
usb2 = &usb_2;
sandbox: Add and build AXI bus and device Add test AXI drivers to the sandbox. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-08-09 12:51:19 +00:00
axi0 = &axi;
video_osd: Add osd sandbox driver and tests Add sandbox driver and tests for the new OSD uclass. Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-09-27 07:19:31 +00:00
osd0 = "/osd";
dm: Allow drivers to be marked 'before relocation' Driver model currently only operates after relocation is complete. In this state U-Boot typically has a small amount of memory available. In adding support for driver model prior to relocation we must try to use as little memory as possible. In addition, on some machines the memory has not be inited and/or the CPU is not running at full speed or the data cache is off. These can reduce execution performance, so the less initialisation that is done before relocation the better. An immediately-obvious improvement is to only initialise drivers which are actually going to be used before relocation. On many boards the only such driver is a serial UART, so this provides a very large potential benefit. Allow drivers to mark themselves as 'pre-reloc' which means that they will be initialised prior to relocation. This can be done either with a driver flag or with a 'dm,pre-reloc' device tree property. To support this, the various dm scanning function now take a 'pre_reloc_only' parameter which indicates that only drivers marked pre-reloc should be bound. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 12:55:03 +00:00
};
arch: Kconfig: imply BINMAN for SANDBOX To be able to use the tool binman on sandbox, the config SANDBOX should imply BINMAN. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
2022-03-28 20:56:53 +00:00
binman {
};
sandbox: add test of CONFIG_ENV_IMPORT_FDT Check that a variable defined in /config/environment is found in the run-time environment, and that clearing fdt_env_path from within that node works. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Acked-by: Joe Hershberger <joe.hershberger@ni.com> [trini: Conditionalize the test being linked in] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-04-21 09:06:55 +00:00
config {
treewide: fdt: Move fdt_get_config_... to ofnode_conf_read... The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-08-07 13:24:01 +00:00
testing-bool;
testing-int = <123>;
testing-str = "testing";
sandbox: add test of CONFIG_ENV_IMPORT_FDT Check that a variable defined in /config/environment is found in the run-time environment, and that clearing fdt_env_path from within that node works. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Acked-by: Joe Hershberger <joe.hershberger@ni.com> [trini: Conditionalize the test being linked in] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-04-21 09:06:55 +00:00
environment {
from_fdt = "yes";
fdt_env_path = "";
};
};
bootstd: Add tests for bootstd including all uclasses Add a set of combined tests for the bootdev, bootflow and bootmeth commands, along with associated functionality. Expand the sandbox console-recording limit so that these can work. These tests rely on a filesystem script which is not yet added to the Python tests. It is included here as a shell script. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-04-25 05:31:24 +00:00
bootstd {
compatible = "u-boot,boot-std";
filename-prefixes = "/", "/boot/";
bootdev-order = "mmc2", "mmc1";
syslinux {
compatible = "u-boot,distro-syslinux";
};
efi {
compatible = "u-boot,distro-efi";
};
};
reboot-mode: read the boot mode from GPIOs status A use case for controlling the boot mode is when the user wants to control the device boot by pushing a button without needing to go in user-space. Add a new backed for reboot mode where GPIOs are used to control the reboot-mode. The driver is able to scan a predefined list of GPIOs and return the magic value. Having the modes associated with the magic value generated based on the GPIO values, allows the reboot mode uclass to select the proper mode. Signed-off-by: Nandor Han <nandor.han@vaisala.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-06-10 13:56:44 +00:00
reboot-mode0 {
compatible = "reboot-mode-gpio";
gpios = <&gpio_c 0 GPIO_ACTIVE_HIGH>, <&gpio_c 1 GPIO_ACTIVE_HIGH>;
u-boot,env-variable = "bootstatus";
mode-test = <0x01>;
mode-download = <0x03>;
};
reboot-mode: read the boot mode from RTC memory RTC devices could provide battery-backed memory that can be used for storing the reboot mode magic value. Add a new reboot-mode back-end that uses RTC to store the reboot-mode magic value. The driver also supports both endianness modes. Signed-off-by: Nandor Han <nandor.han@vaisala.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-06-10 13:56:45 +00:00
reboot_mode1: reboot-mode@14 {
compatible = "reboot-mode-rtc";
rtc = <&rtc_0>;
reg = <0x30 4>;
u-boot,env-variable = "bootstatus";
big-endian;
mode-test = <0x21969147>;
mode-download = <0x51939147>;
};
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-10 17:37:33 +00:00
audio: audio-codec {
compatible = "sandbox,audio-codec";
#sound-dai-cells = <1>;
};
test/py: add tests for the button commands Adds tests for the button commands. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-07-24 16:19:51 +00:00
buttons {
compatible = "gpio-keys";
test: sharpen button label unit test Using different strings for the device tree node labels and the label property of buttons sharpens the button label unit test. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-09-14 10:50:54 +00:00
btn1 {
test/py: add tests for the button commands Adds tests for the button commands. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-07-24 16:19:51 +00:00
gpios = <&gpio_a 3 0>;
test: sharpen button label unit test Using different strings for the device tree node labels and the label property of buttons sharpens the button label unit test. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-09-14 10:50:54 +00:00
label = "button1";
test/py: add tests for the button commands Adds tests for the button commands. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-07-24 16:19:51 +00:00
};
test: sharpen button label unit test Using different strings for the device tree node labels and the label property of buttons sharpens the button label unit test. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-09-14 10:50:54 +00:00
btn2 {
test/py: add tests for the button commands Adds tests for the button commands. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-07-24 16:19:51 +00:00
gpios = <&gpio_a 4 0>;
test: sharpen button label unit test Using different strings for the device tree node labels and the label property of buttons sharpens the button label unit test. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-09-14 10:50:54 +00:00
label = "button2";
test/py: add tests for the button commands Adds tests for the button commands. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-07-24 16:19:51 +00:00
};
};
test: add a simple test for the adc-keys button driver Add adc-keys device to the sandbox/test.dts and connect it to the channel #3 of the sandbox_adc driver. The default values sampled by sandbox_adc driver determines that button3 and button4 are released and button5 is pressed. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2021-02-18 10:33:18 +00:00
buttons2 {
compatible = "adc-keys";
io-channels = <&adc 3>;
keyup-threshold-microvolt = <3000000>;
button-up {
label = "button3";
linux,code = <KEY_F3>;
press-threshold-microvolt = <1500000>;
};
button-down {
label = "button4";
linux,code = <KEY_F4>;
press-threshold-microvolt = <1000000>;
};
button-enter {
label = "button5";
linux,code = <KEY_F5>;
press-threshold-microvolt = <500000>;
};
};
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-10 17:37:34 +00:00
cros_ec: cros-ec {
dm: core: Update ofnode to read binman-style flash entry At present ofnode_read_fmap_entry() reads a flash map entry in a format which is not supported by binman. To allow use to use binman-format descriptions, update this function. Also add a simple test. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:08 +00:00
reg = <0 0>;
compatible = "google,cros-ec-sandbox";
/*
* This describes the flash memory within the EC. Note
* that the STM32L flash erases to 0, not 0xff.
*/
flash {
image-pos = <0x08000000>;
size = <0x20000>;
erase-value = <0>;
/* Information for sandbox */
ro {
image-pos = <0>;
size = <0xf000>;
};
wp-ro {
image-pos = <0xf000>;
size = <0x1000>;
dm: core: Update ofnode_read_fmap_entry() to read hashes At present this function uses the old format for reading hashes. Add support for the current format. Add a test while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-21 20:57:14 +00:00
used = <0x884>;
compress = "lz4";
uncomp-size = <0xcf8>;
hash {
algo = "sha256";
value = [00 01 02 03 04 05 06 07
08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17
18 19 1a 1b 1c 1d 1e 1f];
};
dm: core: Update ofnode to read binman-style flash entry At present ofnode_read_fmap_entry() reads a flash map entry in a format which is not supported by binman. To allow use to use binman-format descriptions, update this function. Also add a simple test. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:08 +00:00
};
rw {
image-pos = <0x10000>;
size = <0x10000>;
};
};
sandbox: cros-ec: Add tests for the Chromium OS EC PWM driver This patch adds a limited pulse-width modulator to sandbox's Chromium OS Embedded Controller emulation. The emulated PWM device supports multiple channels but can only set a duty cycle for each, as the actual EC doesn't expose any functionality or information other than that. Though the EC supports specifying the PWM channel by its type (e.g. display backlight, keyboard backlight), this is not implemented in the emulation as nothing in U-Boot uses this type specification. This emulated PWM device is then used to test the Chromium OS PWM driver in sandbox. Adding the required device node to the sandbox test device-tree unfortunately makes it the first PWM device, so this also touches some other tests to make sure they still use the sandbox PWM. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-05-19 16:33:31 +00:00
cros_ec_pwm: cros-ec-pwm {
compatible = "google,cros-ec-pwm";
#pwm-cells = <1>;
};
dm: core: Update ofnode to read binman-style flash entry At present ofnode_read_fmap_entry() reads a flash map entry in a format which is not supported by binman. To allow use to use binman-format descriptions, update this function. Also add a simple test. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:08 +00:00
};
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 13:29:05 +00:00
dsi_host: dsi_host {
compatible = "sandbox,dsi-host";
};
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
a-test {
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <0 1>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
compatible = "denx,u-boot-fdt-test";
dm: Use an explicit expect value in core tests Rather than reusing the 'reg' property, use an explicit property for the expected ping value used in testing. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 12:54:57 +00:00
ping-expect = <0>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
ping-add = <0>;
dm: Allow drivers to be marked 'before relocation' Driver model currently only operates after relocation is complete. In this state U-Boot typically has a small amount of memory available. In adding support for driver model prior to relocation we must try to use as little memory as possible. In addition, on some machines the memory has not be inited and/or the CPU is not running at full speed or the data cache is off. These can reduce execution performance, so the less initialisation that is done before relocation the better. An immediately-obvious improvement is to only initialise drivers which are actually going to be used before relocation. On many boards the only such driver is a serial UART, so this provides a very large potential benefit. Allow drivers to mark themselves as 'pre-reloc' which means that they will be initialised prior to relocation. This can be done either with a driver flag or with a 'dm,pre-reloc' device tree property. To support this, the various dm scanning function now take a 'pre_reloc_only' parameter which indicates that only drivers marked pre-reloc should be bound. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 12:55:03 +00:00
u-boot,dm-pre-reloc;
gpio: sandbox: cleanup binding support Cleanup binding support, use the generic binding by default (test u-class gpio_xlate_offs_flags function) and add specific binding for added value. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:13 +00:00
test-gpios = <&gpio_a 1>, <&gpio_a 4>,
<&gpio_b 5 GPIO_ACTIVE_HIGH 3 2 1>,
dm: gpio: Add better functions to request GPIOs At present U-Boot sort-of supports the standard way of reading GPIOs from device tree nodes, but the support is incomplete, a bit clunky and only works for GPIO bindings where #gpio-cells is 2. Add new functions to request GPIOs, taking full account of the device tree binding. These permit requesting a GPIO with a simple call like: gpio_request_by_name(dev, "cd-gpios", 0, &desc, GPIOD_IS_IN); This will request the GPIO, looking at the device's node which might be this, for example: cd-gpios = <&gpio TEGRA_GPIO(B, 3) GPIO_ACTIVE_LOW>; The GPIO will be set to input mode in this case and polarity will be honoured by the GPIO calls. It is also possible to request and free a list of GPIOs. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-06 03:05:29 +00:00
<0>, <&gpio_a 12>;
gpio: sandbox: cleanup binding support Cleanup binding support, use the generic binding by default (test u-class gpio_xlate_offs_flags function) and add specific binding for added value. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:13 +00:00
test2-gpios = <&gpio_a 1>, <&gpio_a 4>,
<&gpio_b 6 GPIO_ACTIVE_LOW 3 2 1>,
<&gpio_b 7 GPIO_IN 3 2 1>,
<&gpio_b 8 GPIO_OUT 3 2 1>,
<&gpio_b 9 (GPIO_OUT|GPIO_OUT_ACTIVE) 3 2 1>;
test: dm: update test for pins configuration in gpio Add tests for new API set_dir_flags and set_dir_flags and associated code in gpio uclass. Test support for new flags GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE GPIO_PULL_UP and GPIO_PULL_DOWN. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 10:35:14 +00:00
test3-gpios =
<&gpio_c 0 (GPIO_OUT|GPIO_OPEN_DRAIN)>,
<&gpio_c 1 (GPIO_OUT|GPIO_OPEN_SOURCE)>,
<&gpio_c 2 GPIO_OUT>,
<&gpio_c 3 (GPIO_IN|GPIO_PULL_UP)>,
<&gpio_c 4 (GPIO_IN|GPIO_PULL_DOWN)>,
test: dm: update test for open-drain/open-source emulation in gpio-uclass Add tests for testing open-drain/open-source emulation in gpio-uclass. It also adds two test3-gpios configured as GPIO_ACTIVE_LOW. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-05 08:43:18 +00:00
<&gpio_c 5 GPIO_IN>,
<&gpio_c 6 (GPIO_ACTIVE_LOW|GPIO_OUT|GPIO_OPEN_DRAIN)>,
<&gpio_c 7 (GPIO_ACTIVE_LOW|GPIO_OUT|GPIO_OPEN_SOURCE)>;
test: gpio: Add tests for the managed API Add a test to verify that GPIOs can be acquired/released using the managed API. Also check that the GPIOs are released when the consumer device is removed. 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>
2020-09-11 08:13:35 +00:00
test4-gpios = <&gpio_a 14>, <&gpio_b 4 1 3 2 1>;
test5-gpios = <&gpio_a 19>;
dm: core: Add tests for stringlist functions These functions currently lack tests so add some. The error handling differs betwee livetree and flattree at present, so only check the error codes with livetree. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-10-23 23:26:04 +00:00
bool-value;
dm: core: Add a function to read into a unsigned int The current dev_read...() functions use s32 and u32 which are convenient for device tree but not so useful for normal code, which often wants to use normal integers for values. Add a helper which supports returning an unsigned int. Also add signed versions of the unsigned readers. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-12-10 17:37:37 +00:00
int-value = <1234>;
uint-value = <(-1234)>;
dm: test: add test case for dev_read_u64 function Add test case to cover dev_read_u64 and dev_read_u64_default functions. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-03-29 16:04:40 +00:00
int64-value = /bits/ 64 <0x1111222233334444>;
dm: core: support reading a single indexed u32 value The patch adds helper functions to allow reading a single indexed u32 value from a device-tree property containing multiple u32 values, that is an array of integers. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-03-29 16:04:41 +00:00
int-array = <5678 9123 4567>;
acpi: Support copying properties from device tree to ACPI Some drivers in Linux support both device tree and ACPI. U-Boot itself uses Linux device-tree bindings for its own configuration but does not use ACPI. It is convenient to copy these values over to the ACPI DP table for passing to linux. Add some convenience functions to help with this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:11:58 +00:00
str-value = "test string";
dm: irq: Add support for requesting interrupts At present driver model supports the IRQ uclass but there is no way to request a particular interrupt for a driver. Add a mechanism, similar to clock and reset, to read the interrupts required by a device from the device tree and to request those interrupts. U-Boot itself does not have interrupt-driven handlers, so just provide a means to read and clear an interrupt. This can be useful to handle peripherals which must use an interrupt to determine when data is available, for example. Bring over the basic binding file as well, from Linux v5.4. Note that the older binding is not supported in U-Boot; the newer 'special form' must be used. Add a simple test of the new functionality. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-06 16:55:00 +00:00
interrupts-extended = <&irq 3 0>;
dm: acpi: Enhance acpi_get_name() For many device types it is possible to figure out the name just by looking at its uclass or parent. Add a function to handle this, since it allows us to cover the vast majority of cases automatically. However it is sometimes impossible to figure out an ACPI name for a device just by looking at its uclass. For example a touch device may have a vendor-specific name. Add a new "acpi,name" property to allow a custom name to be created. With this new feature we can drop the get_name() methods in the sandbox I2C and SPI drivers. They were only added for testing purposes. Update the tests to use the new values. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:12:11 +00:00
acpi,name = "GHIJ";
test: dm: add test for phandle access functions Add unitary test for phandle access functions - ofnode_count_phandle_with_args - ofnode_parse_phandle_with_args - dev_count_phandle_with_args - dev_read_phandle_with_args Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-25 07:41:16 +00:00
phandle-value = <&gpio_c 10>, <0xFFFFFFFF 20>, <&gpio_a 30>;
test: Add tests for the multiplexer framework Provide tests to check the behavior of the multiplexer framework. Two sets of tests are added. One is using an emulated multiplexer driver that can be used to test basic functionality like select, deselect, etc. The other is using the mmio mux which adds tests specific to it. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-16 10:46:34 +00:00
mux-controls = <&muxcontroller0 0>, <&muxcontroller0 1>,
<&muxcontroller0 2>, <&muxcontroller0 3>,
<&muxcontroller1>;
mux-control-names = "mux0", "mux1", "mux2", "mux3", "mux4";
mux-syscon = <&syscon3>;
dm: core: add a function to decode display timings The patch adds a function to get display timings from the device tree node attached to the device. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-29 23:16:26 +00:00
display-timings {
timing0: 240x320 {
clock-frequency = <6500000>;
hactive = <240>;
vactive = <320>;
hfront-porch = <6>;
hback-porch = <7>;
hsync-len = <1>;
vback-porch = <5>;
vfront-porch = <8>;
vsync-len = <2>;
hsync-active = <1>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <1>;
interlaced;
doublescan;
doubleclk;
};
timing1: 480x800 {
clock-frequency = <9000000>;
hactive = <480>;
vactive = <800>;
hfront-porch = <10>;
hback-porch = <59>;
hsync-len = <12>;
vback-porch = <15>;
vfront-porch = <17>;
vsync-len = <16>;
hsync-active = <0>;
vsync-active = <1>;
de-active = <0>;
pixelclk-active = <0>;
};
timing2: 800x480 {
clock-frequency = <33500000>;
hactive = <800>;
vactive = <480>;
hback-porch = <89>;
hfront-porch = <164>;
vback-porch = <23>;
vfront-porch = <10>;
hsync-len = <11>;
vsync-len = <13>;
};
};
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
};
junk {
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <1 1>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
compatible = "not,compatible";
};
no-compatible {
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <2 1>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
};
test: panel: Add a test for the panel uclass At present this uclass has no tests. Add a simple one which checks the PWM configuration, regulator and GPIO. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:40 +00:00
backlight: backlight {
compatible = "pwm-backlight";
enable-gpios = <&gpio_a 1>;
power-supply = <&ldo_1>;
pwms = <&pwm 0 1000>;
default-brightness-level = <5>;
brightness-levels = <0 16 32 64 128 170 202 234 255>;
};
cmd: Add bind/unbind commands to bind a device to a driver from the command line In some cases it can be useful to be able to bind a device to a driver from the command line. The obvious example is for versatile devices such as USB gadget. Another use case is when the devices are not yet ready at startup and require some setup before the drivers are bound (ex: FPGA which bitsream is fetched from a mass storage or ethernet) usage example: bind usb_dev_generic 0 usb_ether unbind usb_dev_generic 0 usb_ether or unbind eth 1 bind /ocp/omap_dwc3@48380000/usb@48390000 usb_ether unbind /ocp/omap_dwc3@48380000/usb@48390000 Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2018-08-09 14:17:46 +00:00
bind-test {
sandbox: dts: Add compatible string for bind-test node Usage of lists_bind_fdt() in bind command imposes to add a compatible string for bind-test node. Others impacts are: - bind-test node is binded at sandbox start, so no need to bind it in test_bind_unbind_with_node() test. - As explained just above, after sandbox start, now a phy exist. In test/dm/phy.c, it was verified that a third phy didn't exist, now we must verified that a fourth phy doesn't exist. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-28 07:13:33 +00:00
compatible = "simple-bus";
cmd: Add bind/unbind commands to bind a device to a driver from the command line In some cases it can be useful to be able to bind a device to a driver from the command line. The obvious example is for versatile devices such as USB gadget. Another use case is when the devices are not yet ready at startup and require some setup before the drivers are bound (ex: FPGA which bitsream is fetched from a mass storage or ethernet) usage example: bind usb_dev_generic 0 usb_ether unbind usb_dev_generic 0 usb_ether or unbind eth 1 bind /ocp/omap_dwc3@48380000/usb@48390000 usb_ether unbind /ocp/omap_dwc3@48380000/usb@48390000 Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2018-08-09 14:17:46 +00:00
bind-test-child1 {
compatible = "sandbox,phy";
#phy-cells = <1>;
};
bind-test-child2 {
compatible = "simple-bus";
};
};
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
b-test {
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <3 1>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
compatible = "denx,u-boot-fdt-test";
dm: Use an explicit expect value in core tests Rather than reusing the 'reg' property, use an explicit property for the expected ping value used in testing. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 12:54:57 +00:00
ping-expect = <3>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
ping-add = <3>;
test: Add tests for the multiplexer framework Provide tests to check the behavior of the multiplexer framework. Two sets of tests are added. One is using an emulated multiplexer driver that can be used to test basic functionality like select, deselect, etc. The other is using the mmio mux which adds tests specific to it. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-16 10:46:34 +00:00
mux-controls = <&muxcontroller0 0>;
mux-control-names = "mux0";
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
};
dm: test: Add tests for the generic PHY uclass Those tests check: - the ability for a phy-user to get a phy based on its name or its index - the ability of a phy device (provider) to manage multiple ports - the ability to perform operations on the phy (init,deinit,on,off) - the behavior of the uclass when optional operations are not implemented Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-04-24 09:51:28 +00:00
phy_provider0: gen_phy@0 {
compatible = "sandbox,phy";
#phy-cells = <1>;
};
phy_provider1: gen_phy@1 {
compatible = "sandbox,phy";
#phy-cells = <0>;
broken;
};
test: dm: phy: add a test item for the phy_bulk API Add a test item for the phy_bulk API Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: Weijie Gao <weijie.gao@mediatek.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-05-02 09:35:12 +00:00
phy_provider2: gen_phy@2 {
compatible = "sandbox,phy";
#phy-cells = <0>;
};
dm: test: Add tests for the generic PHY uclass Those tests check: - the ability for a phy-user to get a phy based on its name or its index - the ability of a phy device (provider) to manage multiple ports - the ability to perform operations on the phy (init,deinit,on,off) - the behavior of the uclass when optional operations are not implemented Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-04-24 09:51:28 +00:00
gen_phy_user: gen_phy_user {
compatible = "simple-bus";
phys = <&phy_provider0 0>, <&phy_provider0 1>, <&phy_provider1>;
phy-names = "phy1", "phy2", "phy3";
};
test: dm: phy: add a test item for the phy_bulk API Add a test item for the phy_bulk API Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: Weijie Gao <weijie.gao@mediatek.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-05-02 09:35:12 +00:00
gen_phy_user1: gen_phy_user1 {
compatible = "simple-bus";
phys = <&phy_provider0 0>, <&phy_provider2>;
phy-names = "phy1", "phy2";
};
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
some-bus {
#address-cells = <1>;
#size-cells = <0>;
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 12:55:18 +00:00
compatible = "denx,u-boot-test-bus";
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <3 1>;
dm: Use an explicit expect value in core tests Rather than reusing the 'reg' property, use an explicit property for the expected ping value used in testing. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 12:54:57 +00:00
ping-expect = <4>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
ping-add = <4>;
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 12:55:18 +00:00
c-test@5 {
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
compatible = "denx,u-boot-fdt-test";
reg = <5>;
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 12:55:18 +00:00
ping-expect = <5>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
ping-add = <5>;
};
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 12:55:18 +00:00
c-test@0 {
compatible = "denx,u-boot-fdt-test";
reg = <0>;
ping-expect = <6>;
ping-add = <6>;
};
c-test@1 {
compatible = "denx,u-boot-fdt-test";
reg = <1>;
ping-expect = <7>;
ping-add = <7>;
};
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
};
d-test {
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <3 1>;
dm: Introduce device sequence numbering In U-Boot it is pretty common to number devices from 0 and access them on the command line using this numbering. While it may come to pass that we will move away from this numbering, the possibility seems remote at present. Given that devices within a uclass will have an implied numbering, it makes sense to build this into driver model as a core feature. The cost is fairly small in terms of code and data space. With each uclass having numbered devices we can ask for SPI port 0 or serial port 1 and receive a single device. Devices typically request a sequence number using aliases in the device tree. These are resolved when the device is probed, to deal with conflicts. Sequence numbers need not be sequential and holes are permitted. At present there is no support for sequence numbers using static platform data. It could easily be added to 'struct driver_info' if needed, but it seems better to add features as we find a use for them, and the use of -1 to mean 'no sequence' makes the default value somewhat painful. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 12:55:12 +00:00
ping-expect = <6>;
ping-add = <6>;
compatible = "google,another-fdt-test";
};
e-test {
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <3 1>;
dm: Use an explicit expect value in core tests Rather than reusing the 'reg' property, use an explicit property for the expected ping value used in testing. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23 12:54:57 +00:00
ping-expect = <6>;
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
ping-add = <6>;
compatible = "google,another-fdt-test";
};
dm: core: Add a flag to control sequence numbering At present we try to use the 'reg' property and device tree aliases to give devices a sequence number. The 'reg' property is often actually a memory address, so the sequence numbers thus-obtained are not useful. It would be better if the devices were just sequentially numbered in that case. In fact neither I2C nor SPI use this feature, so drop it. Some devices need us to look up an alias to number them within the uclass. Add a flag to control this, so it is not done unless it is needed. Adjust the tests to test this new behaviour. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-01-25 15:27:05 +00:00
f-test {
compatible = "denx,u-boot-fdt-test";
};
g-test {
compatible = "denx,u-boot-fdt-test";
};
test: dm: core: Add a test case for driver marked with DM_FLAG_PRE_RELOC flag Now that we fixed the pre-relocation driver binding for driver marked with DM_FLAG_PRE_RELOC flag, add a test case to cover that scenario. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-11 05:07:01 +00:00
h-test {
compatible = "denx,u-boot-fdt-test1";
};
test: dm: add test item for ofnode_get_child_count() Add a test item for ofnode_get_child_count() Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Weijie Gao <weijie.gao@mediatek.com>
2020-05-02 09:35:10 +00:00
i-test {
compatible = "mediatek,u-boot-fdt-test";
#address-cells = <1>;
#size-cells = <0>;
subnode@0 {
reg = <0>;
};
subnode@1 {
reg = <1>;
};
subnode@2 {
reg = <2>;
};
};
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 04:19:25 +00:00
devres-test {
compatible = "denx,u-boot-devres-test";
};
test: gpio: Add tests for the managed API Add a test to verify that GPIOs can be acquired/released using the managed API. Also check that the GPIOs are released when the consumer device is removed. 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>
2020-09-11 08:13:35 +00:00
another-test {
reg = <0 2>;
compatible = "denx,u-boot-fdt-test";
test4-gpios = <&gpio_a 14>, <&gpio_b 4 1 3 2 1>;
test5-gpios = <&gpio_a 19>;
};
dm: test: Add test case for dev_get_dma_ranges() Introduce some new nodes in sandbox's test device-tree and dm tests in order to validate dev_get_dma_range(). Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2021-01-12 12:55:23 +00:00
mmio-bus@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "denx,u-boot-test-bus";
dma-ranges = <0x10000000 0x00000000 0x00040000>;
subnode@0 {
compatible = "denx,u-boot-fdt-test";
};
};
mmio-bus@1 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "denx,u-boot-test-bus";
dm: test: Add test case for dev->dma_offset Add test to validate dev->dma_offset is properly set on devices. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2021-01-12 12:55:25 +00:00
subnode@0 {
compatible = "denx,u-boot-fdt-test";
};
dm: test: Add test case for dev_get_dma_ranges() Introduce some new nodes in sandbox's test device-tree and dm tests in order to validate dev_get_dma_range(). Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2021-01-12 12:55:23 +00:00
};
acpi: Support ordering SSDT data by device Add a /chosen property to control the order in which the data appears in the SSDT. This allows matching up U-Boot's output from a dump of the known-good data obtained from within Linux. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:12:06 +00:00
acpi_test1: acpi-test {
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-08 22:57:34 +00:00
compatible = "denx,u-boot-acpi-test";
acpi: Add support for SSDT generation Some devices need to generate code for the Secondary System Descriptor Table (SSDT). Add a method to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:12:03 +00:00
acpi-ssdt-test-data = "ab";
acpi: Add support for DSDT generation Some devices need to inject extra code into the Differentiated System Descriptor Table (DSDT). Add a method to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: correct one typo in inject_dsdt() comments] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:12:08 +00:00
acpi-dsdt-test-data = "hi";
acpi: Add a function to get a device path and scope Add a function to build up the ACPI path for a device and another for its scope. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:11:39 +00:00
child {
compatible = "denx,u-boot-acpi-test";
};
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-08 22:57:34 +00:00
};
acpi: Support ordering SSDT data by device Add a /chosen property to control the order in which the data appears in the SSDT. This allows matching up U-Boot's output from a dump of the known-good data obtained from within Linux. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:12:06 +00:00
acpi_test2: acpi-test2 {
acpi: Add a method to write tables for a device A device may want to write out ACPI tables to describe itself to Linux. Add a method to permit this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
2020-04-26 15:19:46 +00:00
compatible = "denx,u-boot-acpi-test";
acpi: Add support for SSDT generation Some devices need to generate code for the Secondary System Descriptor Table (SSDT). Add a method to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:12:03 +00:00
acpi-ssdt-test-data = "cd";
acpi: Add support for DSDT generation Some devices need to inject extra code into the Differentiated System Descriptor Table (DSDT). Add a method to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: correct one typo in inject_dsdt() comments] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:12:08 +00:00
acpi-dsdt-test-data = "jk";
acpi: Add a method to write tables for a device A device may want to write out ACPI tables to describe itself to Linux. Add a method to permit this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
2020-04-26 15:19:46 +00:00
};
dm: test: replace dm_scan_dt() by of dm_extended_scan_fdt() in dm_do_test This allows to scan the DT including all "clocks" node's sub-nodes in which fixed-clock are defined. All fixed-clock should be defined inside a clocks node which collect all external oscillators. Until now, all clocks sub-nodes can't be binded except if the "simple-bus" compatible string is added which is a hack. Update test.dts by moving clk_fixed node inside clocks. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-09-04 12:55:57 +00:00
clocks {
clk_fixed: clk-fixed {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1234>;
};
clk: Add fixed-factor clock driver This patch adds fixed-factor clock driver which derives clock rate by dividing (div) and multiplying (mult) fixed factors to a parent clock. Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-02-25 08:14:55 +00:00
clk_fixed_factor: clk-fixed-factor {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <3>;
clock-mult = <2>;
clocks = <&clk_fixed>;
};
dts: sandbox: Add 'osc' clock for Common Clock Framework [CCF] testing This patch adds the 'osc' fixed clock to facilitate the CCF testing in the sandbox U-Boot. It is a starting point for building CCF hierarchy of clocks. Signed-off-by: Lukasz Majewski <lukma@denx.de>
2019-06-24 13:50:47 +00:00
osc {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <20000000>;
};
clk: convert API to match reset/mailbox style The following changes are made to the clock API: * The concept of "clocks" and "peripheral clocks" are unified; each clock provider now implements a single set of clocks. This provides a simpler conceptual interface to clients, and better aligns with device tree clock bindings. * Clocks are now identified with a single "struct clk", rather than requiring clients to store the clock provider device and clock identity values separately. For simple clock consumers, this isolates clients from internal details of the clock API. * clk.h is split so it only contains the client/consumer API, whereas clk-uclass.h contains the provider API. This aligns with the recently added reset and mailbox APIs. * clk_ops .of_xlate(), .request(), and .free() are added so providers can customize these operations if needed. This also aligns with the recently added reset and mailbox APIs. * clk_disable() is added. * All users of the current clock APIs are updated. * Sandbox clock tests are updated to exercise clock lookup via DT, and clock enable/disable. * rkclk_get_clk() is removed and replaced with standard APIs. Buildman shows no clock-related errors for any board for which buildman can download a toolchain. test/py passes for sandbox (which invokes the dm clk test amongst others). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-06-17 15:44:00 +00:00
};
clk_sandbox: clk-sbox {
dm: test: Add tests for the clk uclass Add tests of each API call using a sandbox clock device. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:24 +00:00
compatible = "sandbox,clk";
clk: convert API to match reset/mailbox style The following changes are made to the clock API: * The concept of "clocks" and "peripheral clocks" are unified; each clock provider now implements a single set of clocks. This provides a simpler conceptual interface to clients, and better aligns with device tree clock bindings. * Clocks are now identified with a single "struct clk", rather than requiring clients to store the clock provider device and clock identity values separately. For simple clock consumers, this isolates clients from internal details of the clock API. * clk.h is split so it only contains the client/consumer API, whereas clk-uclass.h contains the provider API. This aligns with the recently added reset and mailbox APIs. * clk_ops .of_xlate(), .request(), and .free() are added so providers can customize these operations if needed. This also aligns with the recently added reset and mailbox APIs. * clk_disable() is added. * All users of the current clock APIs are updated. * Sandbox clock tests are updated to exercise clock lookup via DT, and clock enable/disable. * rkclk_get_clk() is removed and replaced with standard APIs. Buildman shows no clock-related errors for any board for which buildman can download a toolchain. test/py passes for sandbox (which invokes the dm clk test amongst others). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-06-17 15:44:00 +00:00
#clock-cells = <1>;
test: clk: test clock self assignment Make sure that the clock self-assignment works by having a clock of clk-sbox be configured automatically when clk-sbox is probed. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2019-10-22 12:00:07 +00:00
assigned-clocks = <&clk_sandbox 3>;
assigned-clock-rates = <321>;
clk: convert API to match reset/mailbox style The following changes are made to the clock API: * The concept of "clocks" and "peripheral clocks" are unified; each clock provider now implements a single set of clocks. This provides a simpler conceptual interface to clients, and better aligns with device tree clock bindings. * Clocks are now identified with a single "struct clk", rather than requiring clients to store the clock provider device and clock identity values separately. For simple clock consumers, this isolates clients from internal details of the clock API. * clk.h is split so it only contains the client/consumer API, whereas clk-uclass.h contains the provider API. This aligns with the recently added reset and mailbox APIs. * clk_ops .of_xlate(), .request(), and .free() are added so providers can customize these operations if needed. This also aligns with the recently added reset and mailbox APIs. * clk_disable() is added. * All users of the current clock APIs are updated. * Sandbox clock tests are updated to exercise clock lookup via DT, and clock enable/disable. * rkclk_get_clk() is removed and replaced with standard APIs. Buildman shows no clock-related errors for any board for which buildman can download a toolchain. test/py passes for sandbox (which invokes the dm clk test amongst others). Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-06-17 15:44:00 +00:00
};
clk-test {
compatible = "sandbox,clk-test";
clocks = <&clk_fixed>,
<&clk_sandbox 1>,
test: clk: Update tests to also check the managed API Add a few more clocks the clk_sandbox clock provider and get them using the managed API. Make sure they are released when the device is removed. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2019-10-22 12:00:05 +00:00
<&clk_sandbox 0>,
<&clk_sandbox 3>,
<&clk_sandbox 2>;
clock-names = "fixed", "i2c", "spi", "uart2", "uart1";
dm: test: Add tests for the clk uclass Add tests of each API call using a sandbox clock device. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:24 +00:00
};
clk: sandbox: Add sandbox test code for Common Clock Framework [CCF] This patch provides code to implement the CCF clock tree in sandbox. It uses all the introduced primitives; some generic ones are reused, some sandbox specific were developed. In that way (after introducing the real CCF tree in sandbox) the recently added to clk-uclass.c: clk_get_by_id() and clk_get_parent_rate() are tested in their natural work environment. Usage (sandbox_defconfig and sandbox_flattree_defconfig): ./u-boot --fdt arch/sandbox/dts/test.dtb --command "ut dm clk_ccf" Signed-off-by: Lukasz Majewski <lukma@denx.de>
2019-06-24 13:50:50 +00:00
ccf: clk-ccf {
compatible = "sandbox,clk-ccf";
};
efi: Add uclass for devices provided by UEFI firmware UCLASS_EFI_LOADER is used for devices created by applications and drivers loaded by U-Boots UEFI implementation. This patch provides a new uclass (UCLASS_EFI_MEDIA) to be used for devices that provided by a UEFI firmware calling U-Boot as an EFI application. If the two uclasses can be unified, is left to future redesign. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-04 15:56:31 +00:00
efi-media {
compatible = "sandbox,efi-media";
};
sandbox: dts: Sort the test.dts file a little There are some core test nodes near the beginning of the file which should be grouped together. But for other nodes, let's sort them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:15 +00:00
eth@10002000 {
compatible = "sandbox,eth";
reg = <0x10002000 0x1000>;
};
eth_5: eth@10003000 {
compatible = "sandbox,eth";
reg = <0x10003000 0x1000>;
sandbox: Move some mac addresses to device tree This prevents some conflicts when running sandbox with -D, since the "rom" mac address will be random and won't match the environment. We still need to keep addresses for eth1 and eth6 in the environment, because dm_test_eth_rotate expects to be able to disable them by removing their envaddr variables. This can likely be fixed in a future series by adding a function to cause sandbox eth_opts callback for a particular mac to fail immediately. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-05-05 17:11:35 +00:00
mac-address = [ 02 00 11 22 33 46 ];
sandbox: dts: Sort the test.dts file a little There are some core test nodes near the beginning of the file which should be grouped together. But for other nodes, let's sort them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:15 +00:00
};
dm: test: Add a new test case for dm_test_eth_rotate Add one more ethernet device node in the sandbox test device tree, with name 'sbe5'. This is to support a new test case for testing network device rotation. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-08-28 05:25:53 +00:00
eth_3: sbe5 {
compatible = "sandbox,eth";
reg = <0x10005000 0x1000>;
sandbox: Move some mac addresses to device tree This prevents some conflicts when running sandbox with -D, since the "rom" mac address will be random and won't match the environment. We still need to keep addresses for eth1 and eth6 in the environment, because dm_test_eth_rotate expects to be able to disable them by removing their envaddr variables. This can likely be fixed in a future series by adding a function to cause sandbox eth_opts callback for a particular mac to fail immediately. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-05-05 17:11:35 +00:00
mac-address = [ 02 00 11 22 33 45 ];
dm: test: Add a new test case for dm_test_eth_rotate Add one more ethernet device node in the sandbox test device tree, with name 'sbe5'. This is to support a new test case for testing network device rotation. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-08-28 05:25:53 +00:00
};
sandbox: dts: Sort the test.dts file a little There are some core test nodes near the beginning of the file which should be grouped together. But for other nodes, let's sort them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:15 +00:00
eth@10004000 {
compatible = "sandbox,eth";
reg = <0x10004000 0x1000>;
};
net: introduce helpers to get PHY ofnode from MAC Add helpers ofnode_get_phy_node() and dev_get_phy_node() and use it in net/mdio-uclass.c function dm_eth_connect_phy_handle(). Also add corresponding UT test. This is useful because other part's of U-Boot may want to get PHY ofnode without connecting a PHY. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-04-06 22:32:57 +00:00
phy_eth0: phy-test-eth {
compatible = "sandbox,eth";
reg = <0x10007000 0x1000>;
sandbox: Move some mac addresses to device tree This prevents some conflicts when running sandbox with -D, since the "rom" mac address will be random and won't match the environment. We still need to keep addresses for eth1 and eth6 in the environment, because dm_test_eth_rotate expects to be able to disable them by removing their envaddr variables. This can likely be fixed in a future series by adding a function to cause sandbox eth_opts callback for a particular mac to fail immediately. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-05-05 17:11:35 +00:00
mac-address = [ 02 00 11 22 33 49 ];
net: introduce helpers to get PHY ofnode from MAC Add helpers ofnode_get_phy_node() and dev_get_phy_node() and use it in net/mdio-uclass.c function dm_eth_connect_phy_handle(). Also add corresponding UT test. This is useful because other part's of U-Boot may want to get PHY ofnode without connecting a PHY. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-04-06 22:32:57 +00:00
phy-handle = <&ethphy1>;
net: introduce helpers to get PHY interface mode from a device/ofnode Add helpers ofnode_read_phy_mode() and dev_read_phy_mode() to parse the "phy-mode" / "phy-connection-type" property. Add corresponding UT test. Use them treewide. This allows us to inline the phy_get_interface_by_name() into ofnode_read_phy_mode(), since the former is not used anymore. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
2022-04-06 22:33:01 +00:00
phy-mode = "2500base-x";
net: introduce helpers to get PHY ofnode from MAC Add helpers ofnode_get_phy_node() and dev_get_phy_node() and use it in net/mdio-uclass.c function dm_eth_connect_phy_handle(). Also add corresponding UT test. This is useful because other part's of U-Boot may want to get PHY ofnode without connecting a PHY. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-04-06 22:32:57 +00:00
};
sandbox: Add a DSA sandbox driver and unit test The DSA sandbox driver is used for unit testing the DSA class code. It implements a simple 2 port switch plus 1 CPU port, and uses a very simple tag to identify the ports. The DSA sandbox device is connected via CPU port to a regular Ethernet sandbox device, called 'dsa-test-eth, managed by the existing eth sandbox driver. The 'dsa-test-eth' is not intended for testing the eth class code however, but it is used to emulate traffic through the 'lan0' and 'lan1' front pannel switch ports. To achieve this the dsa sandbox driver registers a tx handler for the 'dsa-test-eth' device. The switch ports, labeled as 'lan0' and 'lan1', are also registered as eth devices by the dsa class code this time. So pinging through these switch ports is as easy as: => setenv ethact lan0 => ping 1.2.3.5 Unit tests for the dsa class code were also added. The 'dsa_probe' test exercises most API functions from dsa.h. The 'dsa' unit test simply exercises ARP/ICMP traffic through the two switch ports, including tag injection and extraction, with the help of the dsa sandbox driver. I took care to minimize the impact on the existing eth unit tests, though some adjustments needed to be made with the addition of extra eth interfaces used by the dsa unit tests. The additional eth interfaces also require MAC addresses, these have been added to the sandbox default environment. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Message-Id: <20210216224804.3355044-5-olteanv@gmail.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-03-14 12:14:57 +00:00
dsa_eth0: dsa-test-eth {
compatible = "sandbox,eth";
reg = <0x10006000 0x1000>;
sandbox: Move some mac addresses to device tree This prevents some conflicts when running sandbox with -D, since the "rom" mac address will be random and won't match the environment. We still need to keep addresses for eth1 and eth6 in the environment, because dm_test_eth_rotate expects to be able to disable them by removing their envaddr variables. This can likely be fixed in a future series by adding a function to cause sandbox eth_opts callback for a particular mac to fail immediately. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-05-05 17:11:35 +00:00
mac-address = [ 02 00 11 22 33 48 ];
sandbox: Add a DSA sandbox driver and unit test The DSA sandbox driver is used for unit testing the DSA class code. It implements a simple 2 port switch plus 1 CPU port, and uses a very simple tag to identify the ports. The DSA sandbox device is connected via CPU port to a regular Ethernet sandbox device, called 'dsa-test-eth, managed by the existing eth sandbox driver. The 'dsa-test-eth' is not intended for testing the eth class code however, but it is used to emulate traffic through the 'lan0' and 'lan1' front pannel switch ports. To achieve this the dsa sandbox driver registers a tx handler for the 'dsa-test-eth' device. The switch ports, labeled as 'lan0' and 'lan1', are also registered as eth devices by the dsa class code this time. So pinging through these switch ports is as easy as: => setenv ethact lan0 => ping 1.2.3.5 Unit tests for the dsa class code were also added. The 'dsa_probe' test exercises most API functions from dsa.h. The 'dsa' unit test simply exercises ARP/ICMP traffic through the two switch ports, including tag injection and extraction, with the help of the dsa sandbox driver. I took care to minimize the impact on the existing eth unit tests, though some adjustments needed to be made with the addition of extra eth interfaces used by the dsa unit tests. The additional eth interfaces also require MAC addresses, these have been added to the sandbox default environment. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Message-Id: <20210216224804.3355044-5-olteanv@gmail.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-03-14 12:14:57 +00:00
};
dsa-test {
compatible = "sandbox,dsa";
ports {
#address-cells = <1>;
#size-cells = <0>;
swp_0: port@0 {
reg = <0>;
label = "lan0";
phy-mode = "rgmii-rxid";
fixed-link {
speed = <100>;
full-duplex;
};
};
swp_1: port@1 {
reg = <1>;
label = "lan1";
phy-mode = "rgmii-txid";
test: dm: Add a case to test ofnode_phy_is_fixed_link() This adds a test case to test the new ofnode_phy_is_fixed_link() API. Both the new and old DT bindings are covered. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-03-14 12:14:58 +00:00
fixed-link = <0 1 100 0 0>;
sandbox: Add a DSA sandbox driver and unit test The DSA sandbox driver is used for unit testing the DSA class code. It implements a simple 2 port switch plus 1 CPU port, and uses a very simple tag to identify the ports. The DSA sandbox device is connected via CPU port to a regular Ethernet sandbox device, called 'dsa-test-eth, managed by the existing eth sandbox driver. The 'dsa-test-eth' is not intended for testing the eth class code however, but it is used to emulate traffic through the 'lan0' and 'lan1' front pannel switch ports. To achieve this the dsa sandbox driver registers a tx handler for the 'dsa-test-eth' device. The switch ports, labeled as 'lan0' and 'lan1', are also registered as eth devices by the dsa class code this time. So pinging through these switch ports is as easy as: => setenv ethact lan0 => ping 1.2.3.5 Unit tests for the dsa class code were also added. The 'dsa_probe' test exercises most API functions from dsa.h. The 'dsa' unit test simply exercises ARP/ICMP traffic through the two switch ports, including tag injection and extraction, with the help of the dsa sandbox driver. I took care to minimize the impact on the existing eth unit tests, though some adjustments needed to be made with the addition of extra eth interfaces used by the dsa unit tests. The additional eth interfaces also require MAC addresses, these have been added to the sandbox default environment. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Message-Id: <20210216224804.3355044-5-olteanv@gmail.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-03-14 12:14:57 +00:00
};
port@2 {
reg = <2>;
ethernet = <&dsa_eth0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
dm: test: Add "/firmware" node scan test Add a test which verifies that all subnodes under "/firmware" nodes are scanned. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Added 'imply FIRMWARE' to sandbox Kconfig to fix test failures, fixed ordering of lines in arch/sandbox/dts/test.dts and test/dm/Makefile, updated #if condition in drivers/firmware/firmware-uclass.c: Signed-off-by: Simon Glass <sjg@chromium.org>
2018-09-19 10:43:46 +00:00
firmware {
sandbox_firmware: sandbox-firmware {
compatible = "sandbox,firmware";
};
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-09 16:44:00 +00:00
sandbox: scmi: test against a single scmi agent As per DT bindings since Linux kernel v5.14, the device tree can define only 1 SCMI agent node that is named scmi [1]. As a consequence, change implementation of the SCMI driver test through sandbox architecture to reflect that. This change updates sandbox test DT and sandbox SCMI driver accordingly since all these are impacted. Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-02-21 08:22:39 +00:00
scmi {
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-09 16:44:00 +00:00
compatible = "sandbox,scmi-agent";
#address-cells = <1>;
#size-cells = <0>;
firmware: scmi: sandbox test for SCMI clocks Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c is used to get clock resources, allowing further clock manipulation. Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents. Add DM test scmi_clocks to test these 3 clocks. Update DM test sandbox_scmi_agent with load/remove test sequences factorized by {load|remove}_sandbox_scmi_test_devices() helper functions. 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-09 16:44:05 +00:00
sandbox: scmi: test against a single scmi agent As per DT bindings since Linux kernel v5.14, the device tree can define only 1 SCMI agent node that is named scmi [1]. As a consequence, change implementation of the SCMI driver test through sandbox architecture to reflect that. This change updates sandbox test DT and sandbox SCMI driver accordingly since all these are impacted. Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-02-21 08:22:39 +00:00
protocol@10 {
reg = <0x10>;
};
clk_scmi: protocol@14 {
firmware: scmi: sandbox test for SCMI clocks Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c is used to get clock resources, allowing further clock manipulation. Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents. Add DM test scmi_clocks to test these 3 clocks. Update DM test sandbox_scmi_agent with load/remove test sequences factorized by {load|remove}_sandbox_scmi_test_devices() helper functions. 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-09 16:44:05 +00:00
reg = <0x14>;
#clock-cells = <1>;
};
firmware: smci: sandbox test for SCMI reset controllers Add tests for SCMI reset controllers. A test device driver sandbox-scmi_devices.c is used to get reset resources, allowing further resets manipulation. Change sandbox-smci_agent to emulate 1 reset controller exposed through an agent. Add DM test scmi_resets to test this reset controller. 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-09 16:44:07 +00:00
sandbox: scmi: test against a single scmi agent As per DT bindings since Linux kernel v5.14, the device tree can define only 1 SCMI agent node that is named scmi [1]. As a consequence, change implementation of the SCMI driver test through sandbox architecture to reflect that. This change updates sandbox test DT and sandbox SCMI driver accordingly since all these are impacted. Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-02-21 08:22:39 +00:00
reset_scmi: protocol@16 {
firmware: smci: sandbox test for SCMI reset controllers Add tests for SCMI reset controllers. A test device driver sandbox-scmi_devices.c is used to get reset resources, allowing further resets manipulation. Change sandbox-smci_agent to emulate 1 reset controller exposed through an agent. Add DM test scmi_resets to test this reset controller. 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-09 16:44:07 +00:00
reg = <0x16>;
#reset-cells = <1>;
};
firmware: scmi: sandbox test for voltage regulator Implement sandbox regulator devices for SCMI voltage domains and test them in DM scmi tests. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-03-08 21:38:07 +00:00
protocol@17 {
reg = <0x17>;
regulators {
#address-cells = <1>;
#size-cells = <0>;
sandbox: scmi: test against a single scmi agent As per DT bindings since Linux kernel v5.14, the device tree can define only 1 SCMI agent node that is named scmi [1]. As a consequence, change implementation of the SCMI driver test through sandbox architecture to reflect that. This change updates sandbox test DT and sandbox SCMI driver accordingly since all these are impacted. Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-02-21 08:22:39 +00:00
regul0_scmi: reg@0 {
firmware: scmi: sandbox test for voltage regulator Implement sandbox regulator devices for SCMI voltage domains and test them in DM scmi tests. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-03-08 21:38:07 +00:00
reg = <0>;
regulator-name = "sandbox-voltd0";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <3300000>;
};
sandbox: scmi: test against a single scmi agent As per DT bindings since Linux kernel v5.14, the device tree can define only 1 SCMI agent node that is named scmi [1]. As a consequence, change implementation of the SCMI driver test through sandbox architecture to reflect that. This change updates sandbox test DT and sandbox SCMI driver accordingly since all these are impacted. Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-02-21 08:22:39 +00:00
regul1_scmi: reg@1 {
firmware: scmi: sandbox test for voltage regulator Implement sandbox regulator devices for SCMI voltage domains and test them in DM scmi tests. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-03-08 21:38:07 +00:00
reg = <0x1>;
regulator-name = "sandbox-voltd1";
regulator-min-microvolt = <1800000>;
};
};
};
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-09 16:44:00 +00:00
};
dm: test: Add "/firmware" node scan test Add a test which verifies that all subnodes under "/firmware" nodes are scanned. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Added 'imply FIRMWARE' to sandbox Kconfig to fix test failures, fixed ordering of lines in arch/sandbox/dts/test.dts and test/dm/Makefile, updated #if condition in drivers/firmware/firmware-uclass.c: Signed-off-by: Simon Glass <sjg@chromium.org>
2018-09-19 10:43:46 +00:00
};
test: pinmux: add pincontrol-gpio for pin configuration Add a simple pincontrol associated to the sandbox gpio driver, that allows to check pin configuration with the command pinmux. The pinmux test is also updated to test behavior with 2 pincontrols. Example to check LED pin configuration: => pinmux list | Device | Driver | Parent | pinctrl-gpio | sandbox_pinctrl_gpio | root_driver | pinctrl | sandbox_pinctrl | root_driver => pinmux dev pinctrl-gpio => pinmux status a0 : gpio input . a1 : gpio input . a2 : gpio input . a3 : gpio input . a4 : gpio input . a5 : gpio output . a6 : gpio output . ... Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 10:35:15 +00:00
pinctrl-gpio {
compatible = "sandbox,pinctrl-gpio";
gpio_a: base-gpios {
compatible = "sandbox,gpio";
gpio-controller;
#gpio-cells = <1>;
gpio-bank-name = "a";
sandbox,gpio-count = <20>;
sandbox, test: add test for GPIO_HOG function currently gpio hog function is not tested with "ut dm gpio" so add some basic tests for gpio hog functionality. For this enable GPIO_HOG in sandbox_defconfig, add in DTS some gpio hog entries, and add testcase in "ut dm gpio" command. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-22 09:08:58 +00:00
hog_input_active_low {
gpio-hog;
input;
sandbox, test: change hog gpio Since commit 9ba84329dc45 ("sandbox, test: add test for GPIO_HOG function"), the gpio_a 0,1,2 and 3 are used by hog in test.dts. But 2 leds 'sandbox:red' and 'sandbox:green' are using gpio_a 0 and 1. As hog always request his gpios, the led command on both led is broken: => led sandbox:red LED 'sandbox:red' not found (err=-16) The gpio is already requested by hog, so it can't be enabled for led 'sandbox:red'. This commit change the gpio used by hog to 10, 11, 12 and 13, so the led command could be used again with 'sandbox:red' and 'sandbox:green'. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-07-24 13:51:53 +00:00
gpios = <10 GPIO_ACTIVE_LOW>;
sandbox, test: add test for GPIO_HOG function currently gpio hog function is not tested with "ut dm gpio" so add some basic tests for gpio hog functionality. For this enable GPIO_HOG in sandbox_defconfig, add in DTS some gpio hog entries, and add testcase in "ut dm gpio" command. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-22 09:08:58 +00:00
};
hog_input_active_high {
gpio-hog;
input;
sandbox, test: change hog gpio Since commit 9ba84329dc45 ("sandbox, test: add test for GPIO_HOG function"), the gpio_a 0,1,2 and 3 are used by hog in test.dts. But 2 leds 'sandbox:red' and 'sandbox:green' are using gpio_a 0 and 1. As hog always request his gpios, the led command on both led is broken: => led sandbox:red LED 'sandbox:red' not found (err=-16) The gpio is already requested by hog, so it can't be enabled for led 'sandbox:red'. This commit change the gpio used by hog to 10, 11, 12 and 13, so the led command could be used again with 'sandbox:red' and 'sandbox:green'. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-07-24 13:51:53 +00:00
gpios = <11 GPIO_ACTIVE_HIGH>;
sandbox, test: add test for GPIO_HOG function currently gpio hog function is not tested with "ut dm gpio" so add some basic tests for gpio hog functionality. For this enable GPIO_HOG in sandbox_defconfig, add in DTS some gpio hog entries, and add testcase in "ut dm gpio" command. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-22 09:08:58 +00:00
};
hog_output_low {
gpio-hog;
output-low;
sandbox, test: change hog gpio Since commit 9ba84329dc45 ("sandbox, test: add test for GPIO_HOG function"), the gpio_a 0,1,2 and 3 are used by hog in test.dts. But 2 leds 'sandbox:red' and 'sandbox:green' are using gpio_a 0 and 1. As hog always request his gpios, the led command on both led is broken: => led sandbox:red LED 'sandbox:red' not found (err=-16) The gpio is already requested by hog, so it can't be enabled for led 'sandbox:red'. This commit change the gpio used by hog to 10, 11, 12 and 13, so the led command could be used again with 'sandbox:red' and 'sandbox:green'. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-07-24 13:51:53 +00:00
gpios = <12 GPIO_ACTIVE_HIGH>;
sandbox, test: add test for GPIO_HOG function currently gpio hog function is not tested with "ut dm gpio" so add some basic tests for gpio hog functionality. For this enable GPIO_HOG in sandbox_defconfig, add in DTS some gpio hog entries, and add testcase in "ut dm gpio" command. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-22 09:08:58 +00:00
};
hog_output_high {
gpio-hog;
output-high;
sandbox, test: change hog gpio Since commit 9ba84329dc45 ("sandbox, test: add test for GPIO_HOG function"), the gpio_a 0,1,2 and 3 are used by hog in test.dts. But 2 leds 'sandbox:red' and 'sandbox:green' are using gpio_a 0 and 1. As hog always request his gpios, the led command on both led is broken: => led sandbox:red LED 'sandbox:red' not found (err=-16) The gpio is already requested by hog, so it can't be enabled for led 'sandbox:red'. This commit change the gpio used by hog to 10, 11, 12 and 13, so the led command could be used again with 'sandbox:red' and 'sandbox:green'. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-07-24 13:51:53 +00:00
gpios = <13 GPIO_ACTIVE_HIGH>;
sandbox, test: add test for GPIO_HOG function currently gpio hog function is not tested with "ut dm gpio" so add some basic tests for gpio hog functionality. For this enable GPIO_HOG in sandbox_defconfig, add in DTS some gpio hog entries, and add testcase in "ut dm gpio" command. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-22 09:08:58 +00:00
};
test: pinmux: add pincontrol-gpio for pin configuration Add a simple pincontrol associated to the sandbox gpio driver, that allows to check pin configuration with the command pinmux. The pinmux test is also updated to test behavior with 2 pincontrols. Example to check LED pin configuration: => pinmux list | Device | Driver | Parent | pinctrl-gpio | sandbox_pinctrl_gpio | root_driver | pinctrl | sandbox_pinctrl | root_driver => pinmux dev pinctrl-gpio => pinmux status a0 : gpio input . a1 : gpio input . a2 : gpio input . a3 : gpio input . a4 : gpio input . a5 : gpio output . a6 : gpio output . ... Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 10:35:15 +00:00
};
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
test: pinmux: add pincontrol-gpio for pin configuration Add a simple pincontrol associated to the sandbox gpio driver, that allows to check pin configuration with the command pinmux. The pinmux test is also updated to test behavior with 2 pincontrols. Example to check LED pin configuration: => pinmux list | Device | Driver | Parent | pinctrl-gpio | sandbox_pinctrl_gpio | root_driver | pinctrl | sandbox_pinctrl | root_driver => pinmux dev pinctrl-gpio => pinmux status a0 : gpio input . a1 : gpio input . a2 : gpio input . a3 : gpio input . a4 : gpio input . a5 : gpio output . a6 : gpio output . ... Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 10:35:15 +00:00
gpio_b: extra-gpios {
compatible = "sandbox,gpio";
gpio-controller;
#gpio-cells = <5>;
gpio-bank-name = "b";
sandbox,gpio-count = <10>;
};
dm: sf: Add tests for SPI flash Add a simple test for SPI that uses SPI flash. It operates by creating a SPI flash file and using the 'sf test' command to test that all operations work correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
2014-10-14 05:42:11 +00:00
test: pinmux: add pincontrol-gpio for pin configuration Add a simple pincontrol associated to the sandbox gpio driver, that allows to check pin configuration with the command pinmux. The pinmux test is also updated to test behavior with 2 pincontrols. Example to check LED pin configuration: => pinmux list | Device | Driver | Parent | pinctrl-gpio | sandbox_pinctrl_gpio | root_driver | pinctrl | sandbox_pinctrl | root_driver => pinmux dev pinctrl-gpio => pinmux status a0 : gpio input . a1 : gpio input . a2 : gpio input . a3 : gpio input . a4 : gpio input . a5 : gpio output . a6 : gpio output . ... Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 10:35:15 +00:00
gpio_c: pinmux-gpios {
compatible = "sandbox,gpio";
gpio-controller;
#gpio-cells = <2>;
gpio-bank-name = "c";
sandbox,gpio-count = <10>;
};
test: dm: update test for pins configuration in gpio Add tests for new API set_dir_flags and set_dir_flags and associated code in gpio uclass. Test support for new flags GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE GPIO_PULL_UP and GPIO_PULL_DOWN. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 10:35:14 +00:00
};
dm: i2c: Add tests for I2C Add some basic tests to check that the system works as expected. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
2014-12-10 15:55:55 +00:00
i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <0 1>;
dm: i2c: Add tests for I2C Add some basic tests to check that the system works as expected. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
2014-12-10 15:55:55 +00:00
compatible = "sandbox,i2c";
clock-frequency = <100000>;
test: pinmux: add test for 'pinctrl-single' driver The test adds two pinmux nodes to the device tree, one to test when a register changes only one pin's mux (pinctrl-single,pins), and the other to test when more than one pin's mux is changed (pinctrl-single,bits). This required replacing the controller's register access functions when the driver is used on sandbox. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-11 07:39:50 +00:00
pinctrl-names = "default";
pinctrl-0 = <&pinmux_i2c0_pins>;
dm: i2c: Add tests for I2C Add some basic tests to check that the system works as expected. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
2014-12-10 15:55:55 +00:00
eeprom@2c {
reg = <0x2c>;
compatible = "i2c-eeprom";
dm: sandbox: i2c: Use new emulator parent uclass Update the device tree, sandbox i2c driver and tests to use the new emulation parent to hold emulators. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-11-18 15:14:34 +00:00
sandbox,emul = <&emul_eeprom>;
i2c: eeprom: Use reg property instead of offset and size Remove adhoc dt binding for fixed-partition definition for i2c eeprom. fixed-partition are using reg property instead of offset/size pair. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-28 09:48:55 +00:00
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
bootcount_i2c: bootcount@10 {
reg = <10 2>;
};
};
dm: i2c: Add tests for I2C Add some basic tests to check that the system works as expected. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
2014-12-10 15:55:55 +00:00
};
sandbox: dts: add sandbox_pmic.dtsi and include it to sandbox.dts and test.dts This commit adds dtsi file for Sandbox PMIC. It fully describes the PMIC by: - i2c emul node - with a default settings of 16 registers - 2x buck regulator nodes - 2x ldo regulator nodes The default register settings are set with preprocessor macros: - VAL2REG(min[uV/uA], step[uV/uA], val[uV/uA]) - VAL2OMREG(mode id) Both defined in file: - include/dt-bindings/pmic/sandbox_pmic.h The Voltage ranges of each regulator can be found in: - include/power/sandbox_pmic.h The new file is included into: - sandbox.dts - test.dts Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on sandbox: Tested-by: Simon Glass <sjg@chromium.org>
2015-05-13 11:38:35 +00:00
sandbox: dts: Add the real-time-clock test nodes back in These were lost when the PMIC series was applied. Add them back so that the tests pass again. Reported-by: Joe Hershberger <joe.hershberger@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:17 +00:00
rtc_0: rtc@43 {
reg = <0x43>;
compatible = "sandbox-rtc";
dm: sandbox: i2c: Use new emulator parent uclass Update the device tree, sandbox i2c driver and tests to use the new emulation parent to hold emulators. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-11-18 15:14:34 +00:00
sandbox,emul = <&emul0>;
sandbox: dts: Add the real-time-clock test nodes back in These were lost when the PMIC series was applied. Add them back so that the tests pass again. Reported-by: Joe Hershberger <joe.hershberger@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:17 +00:00
};
rtc_1: rtc@61 {
reg = <0x61>;
compatible = "sandbox-rtc";
dm: sandbox: i2c: Use new emulator parent uclass Update the device tree, sandbox i2c driver and tests to use the new emulation parent to hold emulators. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-11-18 15:14:34 +00:00
sandbox,emul = <&emul1>;
};
i2c_emul: emul {
reg = <0xff>;
compatible = "sandbox,i2c-emul-parent";
emul_eeprom: emul-eeprom {
compatible = "sandbox,i2c-eeprom";
sandbox,filename = "i2c.bin";
sandbox,size = <256>;
};
emul0: emul0 {
sandbox: i2c: Rename driver names to work with of-platdata Some of these do not follow the rules. Make sure the driver name matches the compatible string in all cases. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-02-03 13:01:17 +00:00
compatible = "sandbox,i2c-rtc-emul";
dm: sandbox: i2c: Use new emulator parent uclass Update the device tree, sandbox i2c driver and tests to use the new emulation parent to hold emulators. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-11-18 15:14:34 +00:00
};
emul1: emull {
sandbox: i2c: Rename driver names to work with of-platdata Some of these do not follow the rules. Make sure the driver name matches the compatible string in all cases. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-02-03 13:01:17 +00:00
compatible = "sandbox,i2c-rtc-emul";
sandbox: dts: Add the real-time-clock test nodes back in These were lost when the PMIC series was applied. Add them back so that the tests pass again. Reported-by: Joe Hershberger <joe.hershberger@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:17 +00:00
};
};
sandbox: dts: add sandbox_pmic.dtsi and include it to sandbox.dts and test.dts This commit adds dtsi file for Sandbox PMIC. It fully describes the PMIC by: - i2c emul node - with a default settings of 16 registers - 2x buck regulator nodes - 2x ldo regulator nodes The default register settings are set with preprocessor macros: - VAL2REG(min[uV/uA], step[uV/uA], val[uV/uA]) - VAL2OMREG(mode id) Both defined in file: - include/dt-bindings/pmic/sandbox_pmic.h The Voltage ranges of each regulator can be found in: - include/power/sandbox_pmic.h The new file is included into: - sandbox.dts - test.dts Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on sandbox: Tested-by: Simon Glass <sjg@chromium.org>
2015-05-13 11:38:35 +00:00
sandbox_pmic: sandbox_pmic {
reg = <0x40>;
dm: sandbox: i2c: Use new emulator parent uclass Update the device tree, sandbox i2c driver and tests to use the new emulation parent to hold emulators. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-11-18 15:14:34 +00:00
sandbox,emul = <&emul_pmic0>;
sandbox: dts: add sandbox_pmic.dtsi and include it to sandbox.dts and test.dts This commit adds dtsi file for Sandbox PMIC. It fully describes the PMIC by: - i2c emul node - with a default settings of 16 registers - 2x buck regulator nodes - 2x ldo regulator nodes The default register settings are set with preprocessor macros: - VAL2REG(min[uV/uA], step[uV/uA], val[uV/uA]) - VAL2OMREG(mode id) Both defined in file: - include/dt-bindings/pmic/sandbox_pmic.h The Voltage ranges of each regulator can be found in: - include/power/sandbox_pmic.h The new file is included into: - sandbox.dts - test.dts Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on sandbox: Tested-by: Simon Glass <sjg@chromium.org>
2015-05-13 11:38:35 +00:00
};
sandbox: Enable support for MC34708 PMIC in DTS This commit also provides the default values of the emulated MC34708 PMIC internal registers content. Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-15 14:26:40 +00:00
mc34708: pmic@41 {
reg = <0x41>;
dm: sandbox: i2c: Use new emulator parent uclass Update the device tree, sandbox i2c driver and tests to use the new emulation parent to hold emulators. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-11-18 15:14:34 +00:00
sandbox,emul = <&emul_pmic1>;
sandbox: Enable support for MC34708 PMIC in DTS This commit also provides the default values of the emulated MC34708 PMIC internal registers content. Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-05-15 14:26:40 +00:00
};
dm: i2c: Add tests for I2C Add some basic tests to check that the system works as expected. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
2014-12-10 15:55:55 +00:00
};
test: bootcount: add bootcount-uclass test Add a test for the bootcount uclass, which uses the RTC bootcount backend (i.e. drivers/bootcount/rtc.c is implictly also tested). Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-12-14 20:14:29 +00:00
bootcount@0 {
compatible = "u-boot,bootcount-rtc";
rtc = <&rtc_1>;
offset = <0x13>;
};
i2c: eeprom: Use reg property instead of offset and size Remove adhoc dt binding for fixed-partition definition for i2c eeprom. fixed-partition are using reg property instead of offset/size pair. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-28 09:48:55 +00:00
bootcount {
compatible = "u-boot,bootcount-i2c-eeprom";
i2c-eeprom = <&bootcount_i2c>;
};
bootcount: add a new driver with syscon as backend The driver will use a syscon regmap as backend and supports both 16 and 32 size value. The value will be stored in the CPU's endianness. Signed-off-by: Nandor Han <nandor.han@vaisala.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-06-10 12:40:38 +00:00
bootcount_4@0 {
compatible = "u-boot,bootcount-syscon";
syscon = <&syscon0>;
reg = <0x0 0x04>, <0x0 0x04>;
reg-names = "syscon_reg", "offset";
};
bootcount_2@0 {
compatible = "u-boot,bootcount-syscon";
syscon = <&syscon0>;
reg = <0x0 0x04>, <0x0 0x02> ;
reg-names = "syscon_reg", "offset";
};
test: add a simple test for the adc-keys button driver Add adc-keys device to the sandbox/test.dts and connect it to the channel #3 of the sandbox_adc driver. The default values sampled by sandbox_adc driver determines that button3 and button4 are released and button5 is pressed. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2021-02-18 10:33:18 +00:00
adc: adc@0 {
sandbox: add ADC driver This commit adds implementation of Sandbox ADC device emulation. The device provides: - single and multi-channel conversion - 4 channels with predefined conversion output data - 16-bit resolution 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 12:08:06 +00:00
compatible = "sandbox,adc";
test: add a simple test for the adc-keys button driver Add adc-keys device to the sandbox/test.dts and connect it to the channel #3 of the sandbox_adc driver. The default values sampled by sandbox_adc driver determines that button3 and button4 are released and button5 is pressed. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2021-02-18 10:33:18 +00:00
#io-channel-cells = <1>;
sandbox: add ADC driver This commit adds implementation of Sandbox ADC device emulation. The device provides: - single and multi-channel conversion - 4 channels with predefined conversion output data - 16-bit resolution 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 12:08:06 +00:00
vdd-supply = <&buck2>;
vss-microvolts = <0>;
};
test: Add tests for IOMMU uclass Add a set of tests for the IOMMU uclass. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-23 14:58:02 +00:00
iommu: iommu@0 {
compatible = "sandbox,iommu";
#iommu-cells = <0>;
};
dm: irq: Add support for requesting interrupts At present driver model supports the IRQ uclass but there is no way to request a particular interrupt for a driver. Add a mechanism, similar to clock and reset, to read the interrupts required by a device from the device tree and to request those interrupts. U-Boot itself does not have interrupt-driven handlers, so just provide a means to read and clear an interrupt. This can be useful to handle peripherals which must use an interrupt to determine when data is available, for example. Bring over the basic binding file as well, from Linux v5.4. Note that the older binding is not supported in U-Boot; the newer 'special form' must be used. Add a simple test of the new functionality. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-06 16:55:00 +00:00
irq: irq {
sandbox: Add a test for IRQ Add a simple sandbox test for this uclass. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:41:59 +00:00
compatible = "sandbox,irq";
dm: irq: Add support for requesting interrupts At present driver model supports the IRQ uclass but there is no way to request a particular interrupt for a driver. Add a mechanism, similar to clock and reset, to read the interrupts required by a device from the device tree and to request those interrupts. U-Boot itself does not have interrupt-driven handlers, so just provide a means to read and clear an interrupt. This can be useful to handle peripherals which must use an interrupt to determine when data is available, for example. Bring over the basic binding file as well, from Linux v5.4. Note that the older binding is not supported in U-Boot; the newer 'special form' must be used. Add a simple test of the new functionality. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-06 16:55:00 +00:00
interrupt-controller;
#interrupt-cells = <2>;
sandbox: Add a test for IRQ Add a simple sandbox test for this uclass. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:41:59 +00:00
};
dm: video: test: Add tests for the video uclass 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>
2016-01-19 02:52:26 +00:00
lcd {
u-boot,dm-pre-reloc;
compatible = "sandbox,lcd-sdl";
test: pinmux: add test for 'pinctrl-single' driver The test adds two pinmux nodes to the device tree, one to test when a register changes only one pin's mux (pinctrl-single,pins), and the other to test when more than one pin's mux is changed (pinctrl-single,bits). This required replacing the controller's register access functions when the driver is used on sandbox. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-11 07:39:50 +00:00
pinctrl-names = "default";
pinctrl-0 = <&pinmux_lcd_pins>;
dm: video: test: Add tests for the video uclass 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>
2016-01-19 02:52:26 +00:00
xres = <1366>;
yres = <768>;
};
dm: test: Add a test for the LED uclass Add a test to confirm that we can adjust LEDs using the led_gpio driver. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:34 +00:00
leds {
compatible = "gpio-leds";
iracibble {
gpios = <&gpio_a 1 0>;
label = "sandbox:red";
};
martinet {
gpios = <&gpio_a 2 0>;
label = "sandbox:green";
};
dm: led: add testcase for "default-state" property Add two more gpio-leds to sandbox test device tree with default-state property set to "on"/"off". Add dm_test_led_default_state() to check that these new LED's are set to LEDST_ON and LEDST_OFF. dm: led: add testcase for "default-state" property Add two more gpio-leds to sandbox test device tree with default-state property set to "on"/"off". Add dm_test_led_default_state() to check that these new LED's are set to LEDST_ON and LEDST_OFF. Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
2018-04-11 09:16:29 +00:00
default_on {
gpios = <&gpio_a 5 0>;
label = "sandbox:default_on";
default-state = "on";
};
default_off {
gpios = <&gpio_a 6 0>;
test: dm: Test for default led naming This modifies the existing led test to check for default led naming as added in the previous patch. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:02:03 +00:00
/* label intentionally omitted */
dm: led: add testcase for "default-state" property Add two more gpio-leds to sandbox test device tree with default-state property set to "on"/"off". Add dm_test_led_default_state() to check that these new LED's are set to LEDST_ON and LEDST_OFF. dm: led: add testcase for "default-state" property Add two more gpio-leds to sandbox test device tree with default-state property set to "on"/"off". Add dm_test_led_default_state() to check that these new LED's are set to LEDST_ON and LEDST_OFF. Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
2018-04-11 09:16:29 +00:00
default-state = "off";
};
dm: test: Add a test for the LED uclass Add a test to confirm that we can adjust LEDs using the led_gpio driver. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:34 +00:00
};
sandbox: add test of wdt_gpio driver It seems that no other test has claimed gpio_a:7 yet, so use that. The only small wrinkle is modifying the existing wdt test to use uclass_get_device_by_driver() since we now have two UCLASS_WDT instances in play, so it's a little more robust to fetch the device by driver and not merely uclass+index. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2021-08-19 09:57:05 +00:00
gpio-wdt {
gpios = <&gpio_a 7 0>;
compatible = "linux,wdt-gpio";
sandbox: add test of wdt-uclass' watchdog_reset() Check that the watchdog_reset() implementation in wdt-uclass behaves as expected: - resets all activated watchdog devices - leaves unactivated/stopped devices alone - that the rate-limiting works, with a per-device threshold Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2021-08-19 09:57:06 +00:00
hw_margin_ms = <100>;
sandbox: add test of wdt_gpio driver It seems that no other test has claimed gpio_a:7 yet, so use that. The only small wrinkle is modifying the existing wdt test to use uclass_get_device_by_driver() since we now have two UCLASS_WDT instances in play, so it's a little more robust to fetch the device by driver and not merely uclass+index. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2021-08-19 09:57:05 +00:00
always-running;
};
mailbox: implement a sandbox test This adds a sandbox mailbox implementation (provider), a test client device, instantiates them both from Sandbox's DT, and adds a DM test that excercises everything. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> # v1
2016-05-16 23:41:37 +00:00
mbox: mbox {
compatible = "sandbox,mbox";
#mbox-cells = <1>;
};
mbox-test {
compatible = "sandbox,mbox-test";
mboxes = <&mbox 100>, <&mbox 1>;
mbox-names = "other", "test";
};
sandbox: fix cpu property in test.dts for pytest When I tried to run some new efi tests with pytest, efi_smbios_register() triggered a segmentation fault. Here is the location where it happened: efi_init_obj_list() efi_smbios_register() write_smbios_table() smbios_write_type4() smbios_write_type4_dm() where dev_get_parent_platdata() should return a pointer to struct cpu_platdata, but it is actually NULL because any cpu device on sandbox is attached to "root_driver." With this patch, this issue will be fixed by moving all the definitions of cpus under "cpus" node so that they have a "cpu_bus" parent. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-08-27 08:17:03 +00:00
cpus {
sandbox: correct cpu nodes The cpu nodes in arch/sandbox/dts/test.dts should conform to the devicetree specification: * property device_type must be set to "cpu" * the reg property must be provided * the cpu nodes must have an address Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-08-28 09:42:08 +00:00
#address-cells = <1>;
#size-cells = <0>;
timer: Add a test for timer_timebase_fallback To test this function, sandbox CPU must set cpu_platdata.timebase_freq on bind. It also needs to expose a method to set the current cpu. I also make some most members of cpu_sandbox_ops static. On the timer side, the device tree property sandbox,timebase-frequency-fallback controls whether sandbox_timer_probe falls back to time_timebase_fallback or to SANDBOX_TIMER_RATE. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-28 14:52:23 +00:00
timebase-frequency = <2000000>;
sandbox: correct cpu nodes The cpu nodes in arch/sandbox/dts/test.dts should conform to the devicetree specification: * property device_type must be set to "cpu" * the reg property must be provided * the cpu nodes must have an address Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-08-28 09:42:08 +00:00
cpu1: cpu@1 {
device_type = "cpu";
reg = <0x1>;
timer: Add a test for timer_timebase_fallback To test this function, sandbox CPU must set cpu_platdata.timebase_freq on bind. It also needs to expose a method to set the current cpu. I also make some most members of cpu_sandbox_ops static. On the timer side, the device tree property sandbox,timebase-frequency-fallback controls whether sandbox_timer_probe falls back to time_timebase_fallback or to SANDBOX_TIMER_RATE. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-28 14:52:23 +00:00
timebase-frequency = <3000000>;
sandbox: fix cpu property in test.dts for pytest When I tried to run some new efi tests with pytest, efi_smbios_register() triggered a segmentation fault. Here is the location where it happened: efi_init_obj_list() efi_smbios_register() write_smbios_table() smbios_write_type4() smbios_write_type4_dm() where dev_get_parent_platdata() should return a pointer to struct cpu_platdata, but it is actually NULL because any cpu device on sandbox is attached to "root_driver." With this patch, this issue will be fixed by moving all the definitions of cpus under "cpus" node so that they have a "cpu_bus" parent. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-08-27 08:17:03 +00:00
compatible = "sandbox,cpu_sandbox";
u-boot,dm-pre-reloc;
};
test: Add tests for CPU uclass Add a sandbox CPU driver, and some tests for the CPU uclass. Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-08-06 08:23:44 +00:00
sandbox: correct cpu nodes The cpu nodes in arch/sandbox/dts/test.dts should conform to the devicetree specification: * property device_type must be set to "cpu" * the reg property must be provided * the cpu nodes must have an address Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-08-28 09:42:08 +00:00
cpu2: cpu@2 {
device_type = "cpu";
reg = <0x2>;
sandbox: fix cpu property in test.dts for pytest When I tried to run some new efi tests with pytest, efi_smbios_register() triggered a segmentation fault. Here is the location where it happened: efi_init_obj_list() efi_smbios_register() write_smbios_table() smbios_write_type4() smbios_write_type4_dm() where dev_get_parent_platdata() should return a pointer to struct cpu_platdata, but it is actually NULL because any cpu device on sandbox is attached to "root_driver." With this patch, this issue will be fixed by moving all the definitions of cpus under "cpus" node so that they have a "cpu_bus" parent. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-08-27 08:17:03 +00:00
compatible = "sandbox,cpu_sandbox";
u-boot,dm-pre-reloc;
};
test: Add tests for CPU uclass Add a sandbox CPU driver, and some tests for the CPU uclass. Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-08-06 08:23:44 +00:00
sandbox: correct cpu nodes The cpu nodes in arch/sandbox/dts/test.dts should conform to the devicetree specification: * property device_type must be set to "cpu" * the reg property must be provided * the cpu nodes must have an address Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-08-28 09:42:08 +00:00
cpu3: cpu@3 {
device_type = "cpu";
reg = <0x3>;
sandbox: fix cpu property in test.dts for pytest When I tried to run some new efi tests with pytest, efi_smbios_register() triggered a segmentation fault. Here is the location where it happened: efi_init_obj_list() efi_smbios_register() write_smbios_table() smbios_write_type4() smbios_write_type4_dm() where dev_get_parent_platdata() should return a pointer to struct cpu_platdata, but it is actually NULL because any cpu device on sandbox is attached to "root_driver." With this patch, this issue will be fixed by moving all the definitions of cpus under "cpus" node so that they have a "cpu_bus" parent. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-08-27 08:17:03 +00:00
compatible = "sandbox,cpu_sandbox";
u-boot,dm-pre-reloc;
};
test: Add tests for CPU uclass Add a sandbox CPU driver, and some tests for the CPU uclass. Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-08-06 08:23:44 +00:00
};
test: Add tests for SOC uclass Add a sandbox SOC driver, and some tests for the SOC uclass. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-07-16 04:39:58 +00:00
chipid: chipid {
compatible = "sandbox,soc";
};
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-10 17:37:34 +00:00
i2s: i2s {
compatible = "sandbox,i2s";
#sound-dai-cells = <1>;
sandbox: sound: Silence sound for testing When testing the sound system we don't need the hear the beeps. The testing works by checking the data that would be emitted. Add a device-tree property to silence the sound, and enable it for testing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-02-17 03:24:56 +00:00
sandbox,silent; /* Don't emit sounds while testing */
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-10 17:37:34 +00:00
};
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 07:33:57 +00:00
nop-test_0 {
compatible = "sandbox,nop_sandbox1";
nop-test_1 {
compatible = "sandbox,nop_sandbox2";
bind = "True";
};
nop-test_2 {
compatible = "sandbox,nop_sandbox2";
bind = "False";
};
};
test: Add tests for misc uclass Add a set of tests for the misc uclass. Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-07-31 12:24:14 +00:00
misc-test {
compatible = "sandbox,misc_sandbox";
};
dm: blk: Improve block device claiming The intention with block devices is that the device number (devnum field in its descriptor) matches the alias of its parent device. For example, with: aliases { mmc0 = "/sdhci@700b0600"; mmc1 = "/sdhci@700b0400"; } we expect that the block devices for mmc0 and mmc1 would have device numbers of 0 and 1 respectively. Unfortunately this does not currently always happen. If there is another MMC device earlier in the driver model data structures its block device will be created first. It will therefore get device number 0 and mmc0 will therefore miss out. In this case the MMC device will have sequence number 0 but its block device will not. To avoid this, allow a device to request a device number and bump any existing device number that is using it. This all happens during the binding phase so it is safe to change these numbers around. This allows device numbers to match the aliases in all circumstances. Add a test to verify the behaviour. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-24 02:02:07 +00:00
mmc2 {
compatible = "sandbox,mmc";
sandbox: mmc: Support fixed MMC devices Add support for reading devicetree flags for MMC devices. With this we can distinguish between fixed and removable drives. Note that this information is only available when the device is probed, not when it is bound, since it is read in the of_to_plat() method. This could be changed if needed later. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-07-05 22:32:58 +00:00
non-removable;
dm: blk: Improve block device claiming The intention with block devices is that the device number (devnum field in its descriptor) matches the alias of its parent device. For example, with: aliases { mmc0 = "/sdhci@700b0600"; mmc1 = "/sdhci@700b0400"; } we expect that the block devices for mmc0 and mmc1 would have device numbers of 0 and 1 respectively. Unfortunately this does not currently always happen. If there is another MMC device earlier in the driver model data structures its block device will be created first. It will therefore get device number 0 and mmc0 will therefore miss out. In this case the MMC device will have sequence number 0 but its block device will not. To avoid this, allow a device to request a device number and bump any existing device number that is using it. This all happens during the binding phase so it is safe to change these numbers around. This allows device numbers to match the aliases in all circumstances. Add a test to verify the behaviour. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-24 02:02:07 +00:00
};
bootstd: Add tests for bootstd including all uclasses Add a set of combined tests for the bootdev, bootflow and bootmeth commands, along with associated functionality. Expand the sandbox console-recording limit so that these can work. These tests rely on a filesystem script which is not yet added to the Python tests. It is included here as a shell script. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-04-25 05:31:24 +00:00
/* This is used for the bootdev tests */
dm: blk: Improve block device claiming The intention with block devices is that the device number (devnum field in its descriptor) matches the alias of its parent device. For example, with: aliases { mmc0 = "/sdhci@700b0600"; mmc1 = "/sdhci@700b0400"; } we expect that the block devices for mmc0 and mmc1 would have device numbers of 0 and 1 respectively. Unfortunately this does not currently always happen. If there is another MMC device earlier in the driver model data structures its block device will be created first. It will therefore get device number 0 and mmc0 will therefore miss out. In this case the MMC device will have sequence number 0 but its block device will not. To avoid this, allow a device to request a device number and bump any existing device number that is using it. This all happens during the binding phase so it is safe to change these numbers around. This allows device numbers to match the aliases in all circumstances. Add a test to verify the behaviour. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-24 02:02:07 +00:00
mmc1 {
compatible = "sandbox,mmc";
bootstd: Add tests for bootstd including all uclasses Add a set of combined tests for the bootdev, bootflow and bootmeth commands, along with associated functionality. Expand the sandbox console-recording limit so that these can work. These tests rely on a filesystem script which is not yet added to the Python tests. It is included here as a shell script. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-04-25 05:31:24 +00:00
filename = "mmc1.img";
dm: blk: Improve block device claiming The intention with block devices is that the device number (devnum field in its descriptor) matches the alias of its parent device. For example, with: aliases { mmc0 = "/sdhci@700b0600"; mmc1 = "/sdhci@700b0400"; } we expect that the block devices for mmc0 and mmc1 would have device numbers of 0 and 1 respectively. Unfortunately this does not currently always happen. If there is another MMC device earlier in the driver model data structures its block device will be created first. It will therefore get device number 0 and mmc0 will therefore miss out. In this case the MMC device will have sequence number 0 but its block device will not. To avoid this, allow a device to request a device number and bump any existing device number that is using it. This all happens during the binding phase so it is safe to change these numbers around. This allows device numbers to match the aliases in all circumstances. Add a test to verify the behaviour. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-24 02:02:07 +00:00
};
bootstd: Add tests for bootstd including all uclasses Add a set of combined tests for the bootdev, bootflow and bootmeth commands, along with associated functionality. Expand the sandbox console-recording limit so that these can work. These tests rely on a filesystem script which is not yet added to the Python tests. It is included here as a shell script. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-04-25 05:31:24 +00:00
/* This is used for the fastboot tests */
dm: blk: Improve block device claiming The intention with block devices is that the device number (devnum field in its descriptor) matches the alias of its parent device. For example, with: aliases { mmc0 = "/sdhci@700b0600"; mmc1 = "/sdhci@700b0400"; } we expect that the block devices for mmc0 and mmc1 would have device numbers of 0 and 1 respectively. Unfortunately this does not currently always happen. If there is another MMC device earlier in the driver model data structures its block device will be created first. It will therefore get device number 0 and mmc0 will therefore miss out. In this case the MMC device will have sequence number 0 but its block device will not. To avoid this, allow a device to request a device number and bump any existing device number that is using it. This all happens during the binding phase so it is safe to change these numbers around. This allows device numbers to match the aliases in all circumstances. Add a test to verify the behaviour. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-24 02:02:07 +00:00
mmc0 {
dm: test: Add a test for the mmc uclass Add a test to confirm that we can probe this device. Since there is no MMC stack support in sandbox at present, this is as far as the test goes. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:32 +00:00
compatible = "sandbox,mmc";
};
sandbox: pch: Add a test for the PCH uclass This uclass currently has no tests. Add a sandbox driver and some simple tests to provide basic coverage. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: Use "sandbox,pch" for the compatible string, for consistency] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2019-02-17 03:24:50 +00:00
pch {
compatible = "sandbox,pch";
};
sandbox: Update PCI nodes in dts files The way the PCI nodes are written today causes a number of warnings if we stop disabling some of the warnings we pass to DTC. As these warnings aren't disabled in current Linux Kernel builds, we should aim to not disable them here either, so rewrite these slightly. Update the driver model doc as well. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-02-11 17:41:23 +00:00
pci0: pci@0 {
dm: pci: Add driver model tests for PCI Add some basic tests to check that things work as expected with sandbox. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-05 19:25:34 +00:00
compatible = "sandbox,pci";
device_type = "pci";
sandbox: Update PCI nodes in dts files The way the PCI nodes are written today causes a number of warnings if we stop disabling some of the warnings we pass to DTC. As these warnings aren't disabled in current Linux Kernel builds, we should aim to not disable them here either, so rewrite these slightly. Update the driver model doc as well. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-02-11 17:41:23 +00:00
bus-range = <0x00 0xff>;
dm: pci: Add driver model tests for PCI Add some basic tests to check that things work as expected with sandbox. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-05 19:25:34 +00:00
#address-cells = <3>;
#size-cells = <2>;
sandbox: pci: Increase the memory space Increase the memory space so we can support the p2sb bus which needs multiples of 1MB. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:56:08 +00:00
ranges = <0x02000000 0 0x10000000 0x10000000 0 0x2000000
dm: pci: Add driver model tests for PCI Add some basic tests to check that things work as expected with sandbox. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-05 19:25:34 +00:00
0x01000000 0 0x20000000 0x20000000 0 0x2000>;
test: dm: pci: Test more than one device on the same bus It's quite common to have more than one device on the same PCI bus. This updates the test case to test such scenario. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:39 +00:00
pci@0,0 {
compatible = "pci-generic";
reg = <0x0000 0 0 0 0>;
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 14:56:10 +00:00
sandbox,emul = <&swap_case_emul0_0>;
test: dm: pci: Test more than one device on the same bus It's quite common to have more than one device on the same PCI bus. This updates the test case to test such scenario. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:39 +00:00
};
test: dm: Add a test for PCI Enhanced Allocation This test is built on top of the existing swap_case driver. It adds EA capability structure support to swap_case and uses that to map BARs. BAR1 works as it used to, swapping upper/lower case. BARs 2,4 map to a couple of magic values. Signed-off-by: Alex Marginean <alexm.osslist@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-06-07 08:24:24 +00:00
pci@1,0 {
compatible = "pci-generic";
dm: pci: Add a function to read a PCI BAR At present PCI address transaction is not supported so drivers must manually read the correct BAR after reading the device tree info. The ns16550 has a suitable implementation, so move this code into the core DM support. Note that there is no live-tree equivalent at present. 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: correct the unclear comments in test.dts] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-15 18:08:58 +00:00
/* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32 */
reg = <0x02000814 0 0 0 0
0x01000810 0 0 0 0>;
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 14:56:10 +00:00
sandbox,emul = <&swap_case_emul0_1>;
test: dm: Add a test for PCI Enhanced Allocation This test is built on top of the existing swap_case driver. It adds EA capability structure support to swap_case and uses that to map BARs. BAR1 works as it used to, swapping upper/lower case. BARs 2,4 map to a couple of magic values. Signed-off-by: Alex Marginean <alexm.osslist@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-06-07 08:24:24 +00:00
};
sandbox: Add PCI driver and test for p2sb Add a sandbox driver and PCI-device emulator for p2sb. Also add a test which uses a simple 'adder' driver to test the p2sb functionality. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:41:57 +00:00
p2sb-pci@2,0 {
compatible = "sandbox,p2sb";
reg = <0x02001010 0 0 0 0>;
sandbox,emul = <&p2sb_emul>;
adder {
intel,p2sb-port-id = <3>;
compatible = "sandbox,adder";
};
};
x86: sandbox: Add a PMC emulator and test Add a simple PMC for sandbox to permit tests to run. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:41:54 +00:00
pci@1e,0 {
compatible = "sandbox,pmc";
reg = <0xf000 0 0 0 0>;
sandbox,emul = <&pmc_emul1e>;
acpi-base = <0x400>;
gpe0-dwx-mask = <0xf>;
gpe0-dwx-shift-base = <4>;
gpe0-dw = <6 7 9>;
gpe0-sts = <0x20>;
gpe0-en = <0x30>;
};
dm: pci: Add driver model tests for PCI Add some basic tests to check that things work as expected with sandbox. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-05 19:25:34 +00:00
pci@1f,0 {
compatible = "pci-generic";
dm: pci: Add a function to read a PCI BAR At present PCI address transaction is not supported so drivers must manually read the correct BAR after reading the device tree info. The ns16550 has a suitable implementation, so move this code into the core DM support. Note that there is no live-tree equivalent at present. 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: correct the unclear comments in test.dts] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-15 18:08:58 +00:00
/* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
reg = <0x0100f810 0 0 0 0>;
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 14:56:10 +00:00
sandbox,emul = <&swap_case_emul0_1f>;
};
};
pci-emul0 {
compatible = "sandbox,pci-emul-parent";
swap_case_emul0_0: emul0@0,0 {
compatible = "sandbox,swap-case";
};
swap_case_emul0_1: emul0@1,0 {
compatible = "sandbox,swap-case";
use-ea;
};
swap_case_emul0_1f: emul0@1f,0 {
compatible = "sandbox,swap-case";
dm: pci: Add driver model tests for PCI Add some basic tests to check that things work as expected with sandbox. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-05 19:25:34 +00:00
};
sandbox: Add PCI driver and test for p2sb Add a sandbox driver and PCI-device emulator for p2sb. Also add a test which uses a simple 'adder' driver to test the p2sb functionality. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:41:57 +00:00
p2sb_emul: emul@2,0 {
compatible = "sandbox,p2sb-emul";
};
x86: sandbox: Add a PMC emulator and test Add a simple PMC for sandbox to permit tests to run. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:41:54 +00:00
pmc_emul1e: emul@1e,0 {
compatible = "sandbox,pmc-emul";
};
dm: pci: Add driver model tests for PCI Add some basic tests to check that things work as expected with sandbox. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-05 19:25:34 +00:00
};
sandbox: Update PCI nodes in dts files The way the PCI nodes are written today causes a number of warnings if we stop disabling some of the warnings we pass to DTC. As these warnings aren't disabled in current Linux Kernel builds, we should aim to not disable them here either, so rewrite these slightly. Update the driver model doc as well. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-02-11 17:41:23 +00:00
pci1: pci@1 {
test: dm: pci: Test more than one PCI host controller So far there is only one PCI host controller in the sandbox test configuration. This is normally the case for x86, but it can be common on other architectures like ARM/PPC to have more than one PCI host controller in the system. This updates the case to cover such scenario. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:41 +00:00
compatible = "sandbox,pci";
device_type = "pci";
sandbox: Update PCI nodes in dts files The way the PCI nodes are written today causes a number of warnings if we stop disabling some of the warnings we pass to DTC. As these warnings aren't disabled in current Linux Kernel builds, we should aim to not disable them here either, so rewrite these slightly. Update the driver model doc as well. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-02-11 17:41:23 +00:00
bus-range = <0x00 0xff>;
test: dm: pci: Test more than one PCI host controller So far there is only one PCI host controller in the sandbox test configuration. This is normally the case for x86, but it can be common on other architectures like ARM/PPC to have more than one PCI host controller in the system. This updates the case to cover such scenario. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:41 +00:00
#address-cells = <3>;
#size-cells = <2>;
pci: pci-uclass: Add multi entry support for memory regions Enable PCI memory regions in ranges property to be of multiple entry. This helps to add support for SoC's like OcteonTX/TX2 where every peripheral is on PCI bus. Signed-off-by: Suneel Garapati <sgarapati@marvell.com> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com>
2019-10-20 00:10:20 +00:00
ranges = <0x02000000 0 0x30000000 0x30000000 0 0x2000 // MEM0
test: pci: Test PCI address conversion functions Add tests for the functions dm_pci_bus_to_phys() and dm_pci_phys_to_bus() which convert between PCI bus addresses and physical addresses based on the ranges declared for the PCI controller. The ranges of bus#1 are used for the tests, adding a translation to one of the ranges to cover more cases. Signed-off-by: Andrew Scull <ascull@google.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2022-04-21 16:11:09 +00:00
0x02000000 0 0x31000000 0x3e000000 0 0x2000 // MEM1
pci: pci-uclass: Add multi entry support for memory regions Enable PCI memory regions in ranges property to be of multiple entry. This helps to add support for SoC's like OcteonTX/TX2 where every peripheral is on PCI bus. Signed-off-by: Suneel Garapati <sgarapati@marvell.com> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com>
2019-10-20 00:10:20 +00:00
0x01000000 0 0x40000000 0x40000000 0 0x2000>;
sandbox: Update test.dts for dynamic PCI device driver matching At present we have two PCI buses in the test configuration. Both buses have static device-tree config devices. Now we switch the 2nd bus to use dynamic PCI devices for testing. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:47 +00:00
sandbox,dev-info = <0x08 0x00 0x1234 0x5678
test: Add PCI device entry without compat string and with DT node Add PCI entry without compatible string and with a DT node only with reg = <...> property into the DT. This is needed for the tests to verify whether such a setup creates an U-Boot PCI device with the DT node associated with it in udevice.node. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-10-10 19:27:08 +00:00
0x0c 0x00 0x1234 0x5678
0x10 0x00 0x1234 0x5678>;
pci@10,0 {
reg = <0x8000 0 0 0 0>;
};
test: dm: pci: Test more than one PCI host controller So far there is only one PCI host controller in the sandbox test configuration. This is normally the case for x86, but it can be common on other architectures like ARM/PPC to have more than one PCI host controller in the system. This updates the case to cover such scenario. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:41 +00:00
};
sandbox: Update PCI nodes in dts files The way the PCI nodes are written today causes a number of warnings if we stop disabling some of the warnings we pass to DTC. As these warnings aren't disabled in current Linux Kernel builds, we should aim to not disable them here either, so rewrite these slightly. Update the driver model doc as well. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-02-11 17:41:23 +00:00
pci2: pci@2 {
test: dm: pci: Add tests for mixed static and dynamic devices on the same bus In the Sandbox test configuration, PCI bus#0 only has static devices while bus#1 only has dynamic devices. Create a bus#2 that has both types of devices and test such. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:50 +00:00
compatible = "sandbox,pci";
device_type = "pci";
sandbox: Update PCI nodes in dts files The way the PCI nodes are written today causes a number of warnings if we stop disabling some of the warnings we pass to DTC. As these warnings aren't disabled in current Linux Kernel builds, we should aim to not disable them here either, so rewrite these slightly. Update the driver model doc as well. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-02-11 17:41:23 +00:00
bus-range = <0x00 0xff>;
test: dm: pci: Add tests for mixed static and dynamic devices on the same bus In the Sandbox test configuration, PCI bus#0 only has static devices while bus#1 only has dynamic devices. Create a bus#2 that has both types of devices and test such. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:50 +00:00
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x02000000 0 0x50000000 0x50000000 0 0x2000
0x01000000 0 0x60000000 0x60000000 0 0x2000>;
sandbox,dev-info = <0x08 0x00 0x1234 0x5678>;
pci@1f,0 {
compatible = "pci-generic";
reg = <0xf800 0 0 0 0>;
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 14:56:10 +00:00
sandbox,emul = <&swap_case_emul2_1f>;
};
};
pci-emul2 {
compatible = "sandbox,pci-emul-parent";
swap_case_emul2_1f: emul2@1f,0 {
compatible = "sandbox,swap-case";
test: dm: pci: Add tests for mixed static and dynamic devices on the same bus In the Sandbox test configuration, PCI bus#0 only has static devices while bus#1 only has dynamic devices. Create a bus#2 that has both types of devices and test such. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-03 08:14:50 +00:00
};
};
pci_ep: add pci endpoint sandbox driver Add a dummy PCI endpoint for sandbox. Supporting only a single function, it allows setting and reading header configuration. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-04-27 08:15:23 +00:00
pci_ep: pci_ep {
compatible = "sandbox,pci_ep";
};
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 02:10:44 +00:00
probing {
compatible = "simple-bus";
test1 {
compatible = "denx,u-boot-probe-test";
};
test2 {
compatible = "denx,u-boot-probe-test";
};
test3 {
compatible = "denx,u-boot-probe-test";
};
test4 {
compatible = "denx,u-boot-probe-test";
syscon: dm: Add a new method to get a regmap from DTS syscon_regmap_lookup_by_phandle() can be used to get the regmap of a syscon device from a reference in the DTS. It operates similarly to the linux version of the namesake function. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-29 09:57:37 +00:00
first-syscon = <&syscon0>;
second-sys-ctrl = <&another_system_controller>;
syscon: update syscon_regmap_lookup_by_phandle Change the function syscon_regmap_lookup_by_phandle() introduced by commit 6c3af1f24e4b ("syscon: dm: Add a new method to get a regmap from DTS") to have Linux-compatible syscon API. Same modification than commit e151a1c288bd ("syscon: add Linux-compatible syscon API") solves issue when the node identified by the phandle has several compatibles and is already bound to a dedicated driver. See Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon interface from platform devices"). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-03-07 08:57:13 +00:00
third-syscon = <&syscon2>;
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 02:10:44 +00:00
};
};
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-13 19:45:31 +00:00
pwrdom: power-domain {
compatible = "sandbox,power-domain";
#power-domain-cells = <1>;
};
power-domain-test {
compatible = "sandbox,power-domain-test";
power-domains = <&pwrdom 2>;
};
test: panel: Add a test for the panel uclass At present this uclass has no tests. Add a simple one which checks the PWM configuration, regulator and GPIO. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:40 +00:00
pwm: pwm {
dm: sandbox: pwm: Add a basic pwm test Unfortunately a test for the PWM uclass was not included when it was submitted. This was noticed when trying to add more functionality: http://patchwork.ozlabs.org/patch/748172/ Add a simple test to get us started. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-17 03:01:11 +00:00
compatible = "sandbox,pwm";
test: panel: Add a test for the panel uclass At present this uclass has no tests. Add a simple one which checks the PWM configuration, regulator and GPIO. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:40 +00:00
#pwm-cells = <2>;
test: pinmux: add test for 'pinctrl-single' driver The test adds two pinmux nodes to the device tree, one to test when a register changes only one pin's mux (pinctrl-single,pins), and the other to test when more than one pin's mux is changed (pinctrl-single,bits). This required replacing the controller's register access functions when the driver is used on sandbox. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-11 07:39:50 +00:00
pinctrl-names = "default";
pinctrl-0 = <&pinmux_pwm_pins>;
dm: sandbox: pwm: Add a basic pwm test Unfortunately a test for the PWM uclass was not included when it was submitted. This was noticed when trying to add more functionality: http://patchwork.ozlabs.org/patch/748172/ Add a simple test to get us started. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-17 03:01:11 +00:00
};
pwm2 {
compatible = "sandbox,pwm";
test: panel: Add a test for the panel uclass At present this uclass has no tests. Add a simple one which checks the PWM configuration, regulator and GPIO. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:40 +00:00
#pwm-cells = <2>;
dm: sandbox: pwm: Add a basic pwm test Unfortunately a test for the PWM uclass was not included when it was submitted. This was noticed when trying to add more functionality: http://patchwork.ozlabs.org/patch/748172/ Add a simple test to get us started. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-17 03:01:11 +00:00
};
dm: test: Add a test for the ram uclass Add a test to confirm that we can probe this device and get information on the available RAM. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:31 +00:00
ram {
compatible = "sandbox,ram";
};
sandbox: Use the reset driver to handle reset Move sandbox over to use the reset uclass for reset, instead of a direct call to do_reset(). This allows us to add tests. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:29 +00:00
reset@0 {
compatible = "sandbox,warm-reset";
};
reset@1 {
compatible = "sandbox,reset";
};
reset: implement a reset test This adds a sandbox reset implementation (provider), a test client device, instantiates them both from Sandbox's DT, and adds a DM test that excercises everything. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-06-17 15:43:59 +00:00
resetc: reset-ctl {
compatible = "sandbox,reset-ctl";
#reset-cells = <1>;
};
reset-ctl-test {
compatible = "sandbox,reset-ctl-test";
test: reset: Extend base reset test to catch error With this extended test, we get the following failure : => ut dm reset_base Test: dm_test_reset_base: reset.c test/dm/reset.c:52, dm_test_reset_base(): reset_method3.id == reset_method3_1.id: Expected 0x14 (20), got 0x2 (2) Test: dm_test_reset_base: reset.c (flat tree) test/dm/reset.c:52, dm_test_reset_base(): reset_method3.id == reset_method3_1.id: Expected 0x14 (20), got 0x2 (2) Failures: 2 A fix is needed in reset_get_by_index_nodev() when introduced in [1]. [1] ea9dc35aab ("reset: Get the RESET by index without device") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2021-04-20 08:42:25 +00:00
resets = <&resetc 100>, <&resetc 2>, <&resetc 20>, <&resetc 40>;
reset-names = "other", "test", "test2", "test3";
reset: implement a reset test This adds a sandbox reset implementation (provider), a test client device, instantiates them both from Sandbox's DT, and adds a DM test that excercises everything. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-06-17 15:43:59 +00:00
};
sandbox: rng: Add a random number generator(rng) driver Add a sandbox driver for random number generation. Mostly aimed at providing a unit test for rng uclass. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-12-28 18:28:31 +00:00
rng {
compatible = "sandbox,sandbox-rng";
};
sandbox: Introduce dummy remoteproc nodes Introduce dummy devices for sandbox remoteproc device and enable it by default Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-09-17 20:42:41 +00:00
rproc_1: rproc@1 {
compatible = "sandbox,test-processor";
remoteproc-name = "remoteproc-test-dev1";
};
rproc_2: rproc@2 {
compatible = "sandbox,test-processor";
internal-memory-mapped;
remoteproc-name = "remoteproc-test-dev2";
};
test: panel: Add a test for the panel uclass At present this uclass has no tests. Add a simple one which checks the PWM configuration, regulator and GPIO. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:40 +00:00
panel {
compatible = "simple-panel";
backlight = <&backlight 0 100>;
};
drivers: smem: sandbox Add Sandbox driver for SMEM. mostly stub operations. Signed-off-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-07-01 23:57:59 +00:00
smem@0 {
compatible = "sandbox,smem";
};
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-10 17:37:36 +00:00
sound {
compatible = "sandbox,sound";
cpu {
sound-dai = <&i2s 0>;
};
codec {
sound-dai = <&audio 0>;
};
};
dm: sf: Add tests for SPI flash Add a simple test for SPI that uses SPI flash. It operates by creating a SPI flash file and using the 'sf test' command to test that all operations work correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
2014-10-14 05:42:11 +00:00
spi@0 {
#address-cells = <1>;
#size-cells = <0>;
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <0 1>;
dm: sf: Add tests for SPI flash Add a simple test for SPI that uses SPI flash. It operates by creating a SPI flash file and using the 'sf test' command to test that all operations work correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
2014-10-14 05:42:11 +00:00
compatible = "sandbox,spi";
sandbox: test: Add a second SPI slave on sandbox_spi bus Place a second spi slave on the sandbox_spi bus, to be used by the spi_claim_bus() testcase we are about to introduce. We need to make sure that jumping between slaves calling spi_claim_bus() sets the bus speed and mode appropriately. Use different max-hz and mode properties for this new slave. Also, update sandbox_spi cs_info call to allow activity on CS0/CS1 and adapt dm_test_spi_find() testcase for this new setup. Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-14 17:06:47 +00:00
cs-gpios = <0>, <0>, <&gpio_a 0>;
test: pinmux: add test for 'pinctrl-single' driver The test adds two pinmux nodes to the device tree, one to test when a register changes only one pin's mux (pinctrl-single,pins), and the other to test when more than one pin's mux is changed (pinctrl-single,bits). This required replacing the controller's register access functions when the driver is used on sandbox. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-11 07:39:50 +00:00
pinctrl-names = "default";
pinctrl-0 = <&pinmux_spi0_pins>;
dm: sf: Add tests for SPI flash Add a simple test for SPI that uses SPI flash. It operates by creating a SPI flash file and using the 'sf test' command to test that all operations work correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
2014-10-14 05:42:11 +00:00
spi.bin@0 {
reg = <0>;
dts: switch spi-flash to jedec, spi-nor compatible There is no reason not to use the Linux "jedec,spi-nor" binding in U-Boot dts files. This compatible has been added in sf_probe, let use it. This patch switches to jedec,spi-nor when spi-flash is used in the DTS and DTSI files, and removed spi-flash when jedec,spi-nor is already present. The x86 dts are switched in a separate commit since it depends on a change in fdtdec. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Reviewed-by: Evgeniy Paltsev <paltsev@synopsys.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Patrick Delaunay <Patrick.delaunay@st.com> Reviewed-by: Jagan Teki <jagan@openedev.com>
2019-02-10 10:16:20 +00:00
compatible = "spansion,m25p16", "jedec,spi-nor";
dm: sf: Add tests for SPI flash Add a simple test for SPI that uses SPI flash. It operates by creating a SPI flash file and using the 'sf test' command to test that all operations work correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
2014-10-14 05:42:11 +00:00
spi-max-frequency = <40000000>;
sandbox,filename = "spi.bin";
};
sandbox: test: Add a second SPI slave on sandbox_spi bus Place a second spi slave on the sandbox_spi bus, to be used by the spi_claim_bus() testcase we are about to introduce. We need to make sure that jumping between slaves calling spi_claim_bus() sets the bus speed and mode appropriately. Use different max-hz and mode properties for this new slave. Also, update sandbox_spi cs_info call to allow activity on CS0/CS1 and adapt dm_test_spi_find() testcase for this new setup. Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-14 17:06:47 +00:00
spi.bin@1 {
reg = <1>;
compatible = "spansion,m25p16", "jedec,spi-nor";
spi-max-frequency = <50000000>;
sandbox,filename = "spi.bin";
spi-cpol;
spi-cpha;
};
dm: sf: Add tests for SPI flash Add a simple test for SPI that uses SPI flash. It operates by creating a SPI flash file and using the 'sf test' command to test that all operations work correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
2014-10-14 05:42:11 +00:00
};
syscon: dm: Add a new method to get a regmap from DTS syscon_regmap_lookup_by_phandle() can be used to get the regmap of a syscon device from a reference in the DTS. It operates similarly to the linux version of the namesake function. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-29 09:57:37 +00:00
syscon0: syscon@0 {
dm: test: Add a test for the system controller uclass Add a test to confirm that we can access system controllers and find their driver data. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:35 +00:00
compatible = "sandbox,syscon0";
test: regmap: Increase size of syscon0 memory The upcoming changes to the regmap interface will contain a proper check for plausibility when reading/writing from/to a register map. To still have the current tests pass, increase the size of the memory region for the syscon0 device, since one of the tests reads and writes beyond this range. Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-10-04 07:00:40 +00:00
reg = <0x10 16>;
dm: test: Add a test for the system controller uclass Add a test to confirm that we can access system controllers and find their driver data. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:35 +00:00
};
syscon: dm: Add a new method to get a regmap from DTS syscon_regmap_lookup_by_phandle() can be used to get the regmap of a syscon device from a reference in the DTS. It operates similarly to the linux version of the namesake function. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-29 09:57:37 +00:00
another_system_controller: syscon@1 {
dm: test: Add a test for the system controller uclass Add a test to confirm that we can access system controllers and find their driver data. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:35 +00:00
compatible = "sandbox,syscon1";
dm: test: Add a size to each reg property Each sandbox peripheral should have a size as well as a base address. This is required for regmaps to work, so make this change for all nodes that have an address. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:36 +00:00
reg = <0x20 5
0x28 6
0x30 7
0x38 8>;
dm: test: Add a test for the system controller uclass Add a test to confirm that we can access system controllers and find their driver data. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-06 18:54:35 +00:00
};
syscon: update syscon_regmap_lookup_by_phandle Change the function syscon_regmap_lookup_by_phandle() introduced by commit 6c3af1f24e4b ("syscon: dm: Add a new method to get a regmap from DTS") to have Linux-compatible syscon API. Same modification than commit e151a1c288bd ("syscon: add Linux-compatible syscon API") solves issue when the node identified by the phandle has several compatibles and is already bound to a dedicated driver. See Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon interface from platform devices"). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-03-07 08:57:13 +00:00
syscon2: syscon@2 {
test: regmap: test Linux-compatible syscon_node_to_regmap() Like Linux, syscon_node_to_regmap() allows a node to work as a syscon provider without binding it to a syscon driver. Test this. Requested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-04-23 04:26:53 +00:00
compatible = "simple-mfd", "syscon";
reg = <0x40 5
0x48 6
0x50 7
0x58 8>;
};
test: Add tests for the multiplexer framework Provide tests to check the behavior of the multiplexer framework. Two sets of tests are added. One is using an emulated multiplexer driver that can be used to test basic functionality like select, deselect, etc. The other is using the mmio mux which adds tests specific to it. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-16 10:46:34 +00:00
syscon3: syscon@3 {
compatible = "simple-mfd", "syscon";
reg = <0x000100 0x10>;
muxcontroller0: a-mux-controller {
compatible = "mmio-mux";
#mux-control-cells = <1>;
mux-reg-masks = <0x0 0x30>, /* 0: reg 0x0, bits 5:4 */
<0xc 0x1E>, /* 1: reg 0xc, bits 4:1 */
<0x4 0xFF>; /* 2: reg 0x4, bits 7:0 */
idle-states = <MUX_IDLE_AS_IS>, <0x02>, <0x73>;
u-boot,mux-autoprobe;
};
};
muxcontroller1: emul-mux-controller {
compatible = "mux-emul";
#mux-control-cells = <0>;
u-boot,mux-autoprobe;
idle-state = <0xabcd>;
};
dm: test: Add a test for DM_UC_FLAG_NO_AUTO_SEQ Check that this flag operates as expected. This patch is not earlier in this series since is uses the new behaviour of dev_seq(). Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-17 04:20:27 +00:00
testfdtm0 {
compatible = "denx,u-boot-fdtm-test";
};
testfdtm1: testfdtm1 {
compatible = "denx,u-boot-fdtm-test";
};
testfdtm2 {
compatible = "denx,u-boot-fdtm-test";
};
timer: Add a test for timer_timebase_fallback To test this function, sandbox CPU must set cpu_platdata.timebase_freq on bind. It also needs to expose a method to set the current cpu. I also make some most members of cpu_sandbox_ops static. On the timer side, the device tree property sandbox,timebase-frequency-fallback controls whether sandbox_timer_probe falls back to time_timebase_fallback or to SANDBOX_TIMER_RATE. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-28 14:52:23 +00:00
timer@0 {
test: add sandbox timer to test.dts Add missing sandbox timer to test.dts, so that test-dm works. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2015-12-11 08:27:34 +00:00
compatible = "sandbox,timer";
clock-frequency = <1000000>;
};
timer: Add a test for timer_timebase_fallback To test this function, sandbox CPU must set cpu_platdata.timebase_freq on bind. It also needs to expose a method to set the current cpu. I also make some most members of cpu_sandbox_ops static. On the timer side, the device tree property sandbox,timebase-frequency-fallback controls whether sandbox_timer_probe falls back to time_timebase_fallback or to SANDBOX_TIMER_RATE. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-28 14:52:23 +00:00
timer@1 {
compatible = "sandbox,timer";
sandbox,timebase-frequency-fallback;
};
sandbox: dts: add Sandbox TPMv2.x node This node declares the presence of the Sandbox TPMv2.x emulated chip, available for testing. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2018-05-15 09:57:27 +00:00
tpm2 {
compatible = "sandbox,tpm2";
};
sandbox: dts: Sort the test.dts file a little There are some core test nodes near the beginning of the file which should be grouped together. But for other nodes, let's sort them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-05-22 21:42:15 +00:00
uart0: serial {
compatible = "sandbox,serial";
u-boot,dm-pre-reloc;
test: pinmux: add test for 'pinctrl-single' driver The test adds two pinmux nodes to the device tree, one to test when a register changes only one pin's mux (pinctrl-single,pins), and the other to test when more than one pin's mux is changed (pinctrl-single,bits). This required replacing the controller's register access functions when the driver is used on sandbox. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-11 07:39:50 +00:00
pinctrl-names = "default";
pinctrl-0 = <&pinmux_uart0_pins>;
test: dm: eth: Add tests for the eth dm implementation Add a test for the eth uclass using the sandbox eth driver. Verify basic functionality of the network stack / eth uclass by exercising the ping function. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2015-03-22 22:09:15 +00:00
};
dm: usb: Add tests for the USB uclass This adds a simple test for probing and a functional test using the flash stick emulator, which tests a large chunk of the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-25 18:23:05 +00:00
usb_0: usb@0 {
compatible = "sandbox,usb";
status = "disabled";
hub {
compatible = "sandbox,usb-hub";
#address-cells = <1>;
#size-cells = <0>;
flash-stick {
reg = <0>;
compatible = "sandbox,usb-flash";
};
};
};
usb_1: usb@1 {
compatible = "sandbox,usb";
test: Add tests for IOMMU uclass Add a set of tests for the IOMMU uclass. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-23 14:58:02 +00:00
iommus = <&iommu>;
dm: usb: Add tests for the USB uclass This adds a simple test for probing and a functional test using the flash stick emulator, which tests a large chunk of the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-25 18:23:05 +00:00
hub {
compatible = "usb-hub";
usb,device-class = <9>;
usb: provide a device tree node to USB devices It is possible to specify a device tree node for an USB device. This is useful if you have a static USB setup and want to use aliases which point to these nodes, like on the Raspberry Pi. The nodes are matched against their hub port number, the compatible strings are not matched for now. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-06-01 23:47:07 +00:00
#address-cells = <1>;
#size-cells = <0>;
dm: usb: Add tests for the USB uclass This adds a simple test for probing and a functional test using the flash stick emulator, which tests a large chunk of the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-25 18:23:05 +00:00
hub-emul {
compatible = "sandbox,usb-hub";
#address-cells = <1>;
#size-cells = <0>;
dm: test: usb: Add tests for the 'usb tree' command Add tests that this command produces the right output, even when a rescan results in a device disappearing from the bus. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-09 06:48:01 +00:00
flash-stick@0 {
dm: usb: Add tests for the USB uclass This adds a simple test for probing and a functional test using the flash stick emulator, which tests a large chunk of the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-25 18:23:05 +00:00
reg = <0>;
compatible = "sandbox,usb-flash";
sandbox,filepath = "testflash.bin";
};
dm: test: usb: Add tests for the 'usb tree' command Add tests that this command produces the right output, even when a rescan results in a device disappearing from the bus. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-09 06:48:01 +00:00
flash-stick@1 {
reg = <1>;
compatible = "sandbox,usb-flash";
sandbox,filepath = "testflash1.bin";
};
flash-stick@2 {
reg = <2>;
compatible = "sandbox,usb-flash";
sandbox,filepath = "testflash2.bin";
};
dm: test: usb: sandbox: Add keyboard tests for sandbox Add a test that verifies that USB keyboards work correctly on sandbox. This verifies some additional parts of the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-09 06:48:08 +00:00
keyb@3 {
reg = <3>;
compatible = "sandbox,usb-keyb";
};
dm: usb: Add tests for the USB uclass This adds a simple test for probing and a functional test using the flash stick emulator, which tests a large chunk of the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-25 18:23:05 +00:00
};
usb: provide a device tree node to USB devices It is possible to specify a device tree node for an USB device. This is useful if you have a static USB setup and want to use aliases which point to these nodes, like on the Raspberry Pi. The nodes are matched against their hub port number, the compatible strings are not matched for now. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-06-01 23:47:07 +00:00
usbstor@1 {
reg = <1>;
};
usbstor@3 {
reg = <3>;
};
dm: usb: Add tests for the USB uclass This adds a simple test for probing and a functional test using the flash stick emulator, which tests a large chunk of the USB stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-03-25 18:23:05 +00:00
};
};
usb_2: usb@2 {
compatible = "sandbox,usb";
status = "disabled";
};
spmi: Add sandbox test driver This patch adds emulated spmi bus controller with part of pm8916 pmic on it to sandbox and tests validating SPMI uclass. Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-03-31 21:12:28 +00:00
spmi: spmi@0 {
compatible = "sandbox,spmi";
#address-cells = <0x1>;
#size-cells = <0x1>;
sandbox: spmi: Add ranges property for address translation At present address translation does not work since there is no ranges property in the spmi nodes. Add empty ranges properties and a little more logging so that this shows the error: /tmp/b/sandbox/u-boot -d /tmp/b/sandbox/arch/sandbox/dts/test.dtb \ -c "ut dm spmi_access_peripheral" -L7 -v ... pm8916_gpio_probe() bad address: returning err=-22 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:55:59 +00:00
ranges;
spmi: Add sandbox test driver This patch adds emulated spmi bus controller with part of pm8916 pmic on it to sandbox and tests validating SPMI uclass. Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-03-31 21:12:28 +00:00
pm8916@0 {
compatible = "qcom,spmi-pmic";
reg = <0x0 0x1>;
#address-cells = <0x1>;
#size-cells = <0x1>;
sandbox: spmi: Add ranges property for address translation At present address translation does not work since there is no ranges property in the spmi nodes. Add empty ranges properties and a little more logging so that this shows the error: /tmp/b/sandbox/u-boot -d /tmp/b/sandbox/arch/sandbox/dts/test.dtb \ -c "ut dm spmi_access_peripheral" -L7 -v ... pm8916_gpio_probe() bad address: returning err=-22 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:55:59 +00:00
ranges;
spmi: Add sandbox test driver This patch adds emulated spmi bus controller with part of pm8916 pmic on it to sandbox and tests validating SPMI uclass. Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-03-31 21:12:28 +00:00
spmi_gpios: gpios@c000 {
compatible = "qcom,pm8916-gpio";
reg = <0xc000 0x400>;
gpio-controller;
gpio-count = <4>;
#gpio-cells = <2>;
gpio-bank-name="spmi";
};
};
};
dm: Simple Watchdog uclass This is a simple uclass for Watchdog Timers. It has four operations: start, restart, reset, stop. Drivers must implement start, restart and stop operations, while implementing reset is optional: It's default implementation expires watchdog timer in one clock tick. Signed-off-by: Maxim Sloyko <maxims@google.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-04-17 19:00:21 +00:00
wdt0: wdt@0 {
compatible = "sandbox,wdt";
sandbox: add test of wdt-uclass' watchdog_reset() Check that the watchdog_reset() implementation in wdt-uclass behaves as expected: - resets all activated watchdog devices - leaves unactivated/stopped devices alone - that the rate-limiting works, with a per-device threshold Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2021-08-19 09:57:06 +00:00
hw_margin_ms = <200>;
dm: Simple Watchdog uclass This is a simple uclass for Watchdog Timers. It has four operations: start, restart, reset, stop. Drivers must implement start, restart and stop operations, while implementing reset is optional: It's default implementation expires watchdog timer in one clock tick. Signed-off-by: Maxim Sloyko <maxims@google.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-04-17 19:00:21 +00:00
};
dm: core: parse chosen node This is the node that would contain, for example, the framebuffer setup by an earlier stage. Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-01-10 10:33:30 +00:00
sandbox: Add and build AXI bus and device Add test AXI drivers to the sandbox. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-08-09 12:51:19 +00:00
axi: axi@0 {
compatible = "sandbox,axi";
#address-cells = <0x1>;
#size-cells = <0x1>;
store@0 {
compatible = "sandbox,sandbox_store";
reg = <0x0 0x400>;
};
};
dm: core: parse chosen node This is the node that would contain, for example, the framebuffer setup by an earlier stage. Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-01-10 10:33:30 +00:00
chosen {
sandbox: Correct dtc warning in /chosen node At present dtc produces these warnings when compiling sandbox: arch/sandbox/dts/test.dtb: Warning (reg_format): "reg" property in /chosen/chosen-test has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1) arch/sandbox/dts/test.dtb: Warning (avoid_default_addr_size): Relying on default #address-cells value for /chosen/chosen-test arch/sandbox/dts/test.dtb: Warning (avoid_default_addr_size): Relying on default #size-cells value for /chosen/chosen-test Add the missing properties to avoid this. Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: f200680 (dm: core: parse chosen node)
2018-02-03 17:36:58 +00:00
#address-cells = <1>;
#size-cells = <1>;
dm: core: Rename ofnode_get_chosen_prop() This function is actually intended to read a string rather than a property. All of its current callers use it that way. Also there is no way to return the length of the property from this function. Rename it to better indicate its purpose, using ofnode_read as the prefix since this matches most other functions. Also add some tests which are missing for these functions. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-27 15:49:43 +00:00
setting = "sunrise ohoka";
other-node = "/some-bus/c-test@5";
dm: core: Add ofnode_get_chosen_prop() Add a function to read a property from the chosen node, providing access to its length. Update ofnode_get_chosen_string() to make use of it. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-27 15:49:46 +00:00
int-values = <0x1937 72993>;
acpi: Support ordering SSDT data by device Add a /chosen property to control the order in which the data appears in the SSDT. This allows matching up U-Boot's output from a dump of the known-good data obtained from within Linux. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-07 19:12:06 +00:00
u-boot,acpi-ssdt-order = <&acpi_test2 &acpi_test1>;
dm: core: parse chosen node This is the node that would contain, for example, the framebuffer setup by an earlier stage. Signed-off-by: Rob Clark <robdclark@gmail.com>
2018-01-10 10:33:30 +00:00
chosen-test {
compatible = "denx,u-boot-fdt-test";
reg = <9 1>;
};
};
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 13:53:33 +00:00
translation-test@8000 {
compatible = "simple-bus";
reg = <0x8000 0x4000>;
#address-cells = <0x2>;
#size-cells = <0x1>;
ranges = <0 0x0 0x8000 0x1000
1 0x100 0x9000 0x1000
2 0x200 0xA000 0x1000
3 0x300 0xB000 0x1000
>;
dm: core: Introduce xxx_translate_dma_address() Add the following functions to translate DMA address to CPU address: - dev_translate_dma_address() - ofnode_translate_dma_address() - of_translate_dma_address() - fdt_translate_dma_address() These functions work the same way as xxx_translate_address(), with the difference that the translation relies on the "dma-ranges" property instead of the "ranges" property. Add related test. Test report: => ut dm fdt_translation Test: dm_test_fdt_translation: test-fdt.c Test: dm_test_fdt_translation: test-fdt.c (flat tree) Failures: 0 Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-05-31 13:11:30 +00:00
dma-ranges = <0 0x000 0x10000000 0x1000
1 0x100 0x20000000 0x1000
>;
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 13:53:33 +00:00
dev@0,0 {
compatible = "denx,u-boot-fdt-dummy";
reg = <0 0x0 0x1000>;
dm: core: add functions to get/remap I/O addresses by name This functions allow us to get and remap I/O addresses by name, which is useful when there are multiple reg addresses indexed by reg-names property. This is needed in bmips dma/eth patch series, but can also be used on many other drivers. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-12-03 18:37:09 +00:00
reg-names = "sandbox-dummy-0";
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 13:53:33 +00:00
};
dev@1,100 {
compatible = "denx,u-boot-fdt-dummy";
reg = <1 0x100 0x1000>;
};
dev@2,200 {
compatible = "denx,u-boot-fdt-dummy";
reg = <2 0x200 0x1000>;
};
noxlatebus@3,300 {
compatible = "simple-bus";
reg = <3 0x300 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
dev@42 {
compatible = "denx,u-boot-fdt-dummy";
reg = <0x42>;
};
};
};
video_osd: Add osd sandbox driver and tests Add sandbox driver and tests for the new OSD uclass. Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-09-27 07:19:31 +00:00
osd {
compatible = "sandbox,sandbox_osd";
};
Merge git://git.denx.de/u-boot-dm
2018-09-30 22:16:51 +00:00
sandbox: dt: add sandbox_tee node Adds a sandbox_tee node to enable the sandbox tee driver in all the sandbox dts files. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2018-09-25 14:40:16 +00:00
sandbox_tee {
compatible = "sandbox,tee";
};
test: dm: virtio: Add test cases for virtio uclass Now that we have a sandbox virtio transport driver, add some test cases to test virtio uclass driver. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-15 09:21:26 +00:00
sandbox_virtio1 {
compatible = "sandbox,virtio1";
};
sandbox_virtio2 {
compatible = "sandbox,virtio2";
};
test/py: test pinmux command Add pinmux test which test the following commands: - pinmux list - pinmux dev - pinmux status Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Mark some tests as sandbox-centric] Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2018-10-24 12:10:23 +00:00
firmware: scmi: sandbox test for SCMI clocks Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c is used to get clock resources, allowing further clock manipulation. Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents. Add DM test scmi_clocks to test these 3 clocks. Update DM test sandbox_scmi_agent with load/remove test sequences factorized by {load|remove}_sandbox_scmi_test_devices() helper functions. 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-09 16:44:05 +00:00
sandbox_scmi {
compatible = "sandbox,scmi-devices";
firmware: scmi: fix sandbox and related tests for clock discovery Updates sandbox SCMI clock driver and tests since enabling CCF will mandate clock discovery that is all exposed SCMI clocks shall be discovered at initialization. For this reason, sandbox SCMI clock driver must emulate all clocks exposed by SCMI server, not only those effectively consumed by some other U-Boot devices. Therefore the sandbox SCMI test driver exposes 3 clocks (IDs 0, 1 and 2) and sandbox SCMI clock consumer driver gets 2 of them. Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-02-21 08:22:41 +00:00
clocks = <&clk_scmi 2>, <&clk_scmi 0>;
sandbox: scmi: test against a single scmi agent As per DT bindings since Linux kernel v5.14, the device tree can define only 1 SCMI agent node that is named scmi [1]. As a consequence, change implementation of the SCMI driver test through sandbox architecture to reflect that. This change updates sandbox test DT and sandbox SCMI driver accordingly since all these are impacted. Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2022-02-21 08:22:39 +00:00
resets = <&reset_scmi 3>;
regul0-supply = <&regul0_scmi>;
regul1-supply = <&regul1_scmi>;
firmware: scmi: sandbox test for SCMI clocks Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c is used to get clock resources, allowing further clock manipulation. Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents. Add DM test scmi_clocks to test these 3 clocks. Update DM test sandbox_scmi_agent with load/remove test sequences factorized by {load|remove}_sandbox_scmi_test_devices() helper functions. 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-09 16:44:05 +00:00
};
test/py: test pinmux command Add pinmux test which test the following commands: - pinmux list - pinmux dev - pinmux status Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Mark some tests as sandbox-centric] Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2018-10-24 12:10:23 +00:00
pinctrl {
compatible = "sandbox,pinctrl";
test: dm: update test for pins configuration in pinctrl node Add test for "pins" configuration in gpio uclass with set_state() ops and test for generic parsing of pinconf_param array). set_state() is called by: - pinctrl_generic_set_state |- pinctrl_generic_set_state_subnode Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:12 +00:00
test: pinmux: Add test for pin muxing This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:57 +00:00
pinctrl-names = "default", "alternate";
pinctrl-0 = <&pinctrl_gpios>, <&pinctrl_i2s>;
pinctrl-1 = <&pinctrl_spi>, <&pinctrl_i2c>;
test: dm: update test for pins configuration in pinctrl node Add test for "pins" configuration in gpio uclass with set_state() ops and test for generic parsing of pinconf_param array). set_state() is called by: - pinctrl_generic_set_state |- pinctrl_generic_set_state_subnode Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:12 +00:00
test: pinmux: Add test for pin muxing This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:57 +00:00
pinctrl_gpios: gpios {
test: dm: update test for pins configuration in pinctrl node Add test for "pins" configuration in gpio uclass with set_state() ops and test for generic parsing of pinconf_param array). set_state() is called by: - pinctrl_generic_set_state |- pinctrl_generic_set_state_subnode Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:12 +00:00
gpio0 {
test: pinmux: Add test for pin muxing This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:57 +00:00
pins = "P5";
function = "GPIO";
test: dm: update test for pins configuration in pinctrl node Add test for "pins" configuration in gpio uclass with set_state() ops and test for generic parsing of pinconf_param array). set_state() is called by: - pinctrl_generic_set_state |- pinctrl_generic_set_state_subnode Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:12 +00:00
bias-pull-up;
input-disable;
};
gpio1 {
test: pinmux: Add test for pin muxing This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:57 +00:00
pins = "P6";
function = "GPIO";
test: dm: update test for pins configuration in pinctrl node Add test for "pins" configuration in gpio uclass with set_state() ops and test for generic parsing of pinconf_param array). set_state() is called by: - pinctrl_generic_set_state |- pinctrl_generic_set_state_subnode Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:12 +00:00
output-high;
drive-open-drain;
};
gpio2 {
test: pinmux: Add test for pin muxing This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:57 +00:00
pinmux = <SANDBOX_PINMUX(7, SANDBOX_PINMUX_GPIO)>;
test: dm: update test for pins configuration in pinctrl node Add test for "pins" configuration in gpio uclass with set_state() ops and test for generic parsing of pinconf_param array). set_state() is called by: - pinctrl_generic_set_state |- pinctrl_generic_set_state_subnode Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:12 +00:00
bias-pull-down;
input-enable;
};
gpio3 {
test: pinmux: Add test for pin muxing This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:57 +00:00
pinmux = <SANDBOX_PINMUX(8, SANDBOX_PINMUX_GPIO)>;
test: dm: update test for pins configuration in pinctrl node Add test for "pins" configuration in gpio uclass with set_state() ops and test for generic parsing of pinconf_param array). set_state() is called by: - pinctrl_generic_set_state |- pinctrl_generic_set_state_subnode Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-01-13 10:35:12 +00:00
bias-disable;
};
};
test: pinmux: Add test for pin muxing This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py. The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:57 +00:00
pinctrl_i2c: i2c {
groups {
groups = "I2C_UART";
function = "I2C";
};
pins {
pins = "P0", "P1";
drive-open-drain;
};
};
pinctrl_i2s: i2s {
groups = "SPI_I2S";
function = "I2S";
};
pinctrl_spi: spi {
groups = "SPI_I2S";
function = "SPI";
cs {
pinmux = <SANDBOX_PINMUX(5, SANDBOX_PINMUX_CS)>,
<SANDBOX_PINMUX(6, SANDBOX_PINMUX_CS)>;
};
};
test/py: test pinmux command Add pinmux test which test the following commands: - pinmux list - pinmux dev - pinmux status Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Mark some tests as sandbox-centric] Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2018-10-24 12:10:23 +00:00
};
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 12:49:50 +00:00
test: pinmux: add test for 'pinctrl-single' driver The test adds two pinmux nodes to the device tree, one to test when a register changes only one pin's mux (pinctrl-single,pins), and the other to test when more than one pin's mux is changed (pinctrl-single,bits). This required replacing the controller's register access functions when the driver is used on sandbox. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-11 07:39:50 +00:00
pinctrl-single-no-width {
compatible = "pinctrl-single";
reg = <0x0000 0x238>;
#pinctrl-cells = <1>;
pinctrl-single,function-mask = <0x7f>;
};
pinctrl-single-pins {
compatible = "pinctrl-single";
reg = <0x0000 0x238>;
#pinctrl-cells = <1>;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x7f>;
pinmux_pwm_pins: pinmux_pwm_pins {
pinctrl-single,pins = < 0x48 0x06 >;
};
pinmux_spi0_pins: pinmux_spi0_pins {
pinctrl-single,pins = <
0x190 0x0c
0x194 0x0c
0x198 0x23
0x19c 0x0c
>;
};
pinmux_uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
0x70 0x30
0x74 0x00
>;
};
};
pinctrl-single-bits {
compatible = "pinctrl-single";
reg = <0x0000 0x50>;
#pinctrl-cells = <2>;
pinctrl-single,bit-per-mux;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0xf>;
pinmux_i2c0_pins: pinmux_i2c0_pins {
pinctrl-single,bits = <
0x10 0x00002200 0x0000ff00
>;
};
pinmux_lcd_pins: pinmux_lcd_pins {
pinctrl-single,bits = <
0x40 0x22222200 0xffffff00
0x44 0x22222222 0xffffffff
0x48 0x00000022 0x000000ff
0x48 0x02000000 0x0f000000
0x4c 0x02000022 0x0f0000ff
>;
};
};
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 12:49:50 +00:00
hwspinlock@0 {
compatible = "sandbox,hwspinlock";
};
test: dma: add dma-uclass test Add a sandbox DMA driver implementation (provider) and corresponding DM test. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Álvaro Fernández Rojas <noltari@gmail.com>
2018-11-28 18:17:51 +00:00
dma: dma {
compatible = "sandbox,dma";
#dma-cells = <1>;
dmas = <&dma 0>, <&dma 1>, <&dma 2>;
dma-names = "m2m", "tx0", "rx0";
};
test: dm: add MDIO test A very simple test for DM_MDIO, mimicks a register write/read through the sandbox bus to a dummy PHY. Signed-off-by: Alex Marginean <alexm.osslist@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2019-06-03 16:12:28 +00:00
test: dm: add a test for MDIO MUX DM uclass Adds a test using a makeshift MDIO MUX. The test is based on the existing MDIO test. It uses the last emulated PHY register to verify MUX selection. Signed-off-by: Alex Marginean <alexm.osslist@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-07-12 07:13:53 +00:00
/*
* keep mdio-mux ahead of mdio so that the mux is removed first at the
* end of the test. If parent mdio is removed first, clean-up of the
* mux will trigger a 2nd probe of parent-mdio, leaving parent-mdio
* active at the end of the test. That it turn doesn't allow the mdio
* class to be destroyed, triggering an error.
*/
mdio-mux-test {
compatible = "sandbox,mdio-mux";
#address-cells = <1>;
#size-cells = <0>;
mdio-parent-bus = <&mdio>;
mdio-ch-test@0 {
reg = <0>;
};
mdio-ch-test@1 {
reg = <1>;
};
};
mdio: mdio-test {
test: dm: add MDIO test A very simple test for DM_MDIO, mimicks a register write/read through the sandbox bus to a dummy PHY. Signed-off-by: Alex Marginean <alexm.osslist@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2019-06-03 16:12:28 +00:00
compatible = "sandbox,mdio";
net: introduce helpers to get PHY ofnode from MAC Add helpers ofnode_get_phy_node() and dev_get_phy_node() and use it in net/mdio-uclass.c function dm_eth_connect_phy_handle(). Also add corresponding UT test. This is useful because other part's of U-Boot may want to get PHY ofnode without connecting a PHY. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-04-06 22:32:57 +00:00
#address-cells = <1>;
#size-cells = <0>;
ethphy1: ethernet-phy@1 {
reg = <1>;
};
test: dm: add MDIO test A very simple test for DM_MDIO, mimicks a register write/read through the sandbox bus to a dummy PHY. Signed-off-by: Alex Marginean <alexm.osslist@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2019-06-03 16:12:28 +00:00
};
dm: Add support for simple-pm-bus This type of bus is used in Linux to designate buses which have power domains and/or clocks which need to be enabled before their child devices can be used. Because power domains are automatically enabled before probing in U-Boot, we just need to enable any clocks present. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-06-24 10:41:12 +00:00
pm-bus-test {
compatible = "simple-pm-bus";
clocks = <&clk_sandbox 4>;
power-domains = <&pwrdom 1>;
};
reset: Add generic reset driver This patch adds a generic reset driver. It is designed to be useful when one has a register in a regmap which contains bits that reset other devices. I thought this seemed like a very generic use, so here is a generic driver. The overall structure has been modeled on the syscon-reboot driver. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-06-24 10:41:14 +00:00
resetc2: syscon-reset {
compatible = "syscon-reset";
#reset-cells = <1>;
regmap = <&syscon0>;
offset = <1>;
mask = <0x27FFFFFF>;
assert-high = <0>;
};
syscon-reset-test {
compatible = "sandbox,misc_sandbox";
resets = <&resetc2 15>, <&resetc2 30>, <&resetc2 60>;
reset-names = "valid", "no_mask", "out_of_range";
};
test: dm: Add tests for regmap managed API and regmap fields The tests rely on a dummy driver to allocate and initialize the regmaps and the regmap fields using the managed API. The first test checks if the regmap config fields like width, reg_offset_shift, range specifiers, etc work. The second test checks if regmap fields behave properly (mask and shift are ok) by peeking into the regmap. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-24 04:34:18 +00:00
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 13:32:05 +00:00
sysinfo {
compatible = "sandbox,sysinfo-sandbox";
};
test: Add gpio-sysinfo test This adds a test for the gpio-sysinfo driver. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-20 14:50:58 +00:00
sysinfo-gpio {
compatible = "gpio-sysinfo";
gpios = <&gpio_a 15>, <&gpio_a 16>, <&gpio_a 17>;
revisions = <19>, <5>;
names = "rev_a", "foo";
};
test: dm: Add tests for regmap managed API and regmap fields The tests rely on a dummy driver to allocate and initialize the regmaps and the regmap fields using the managed API. The first test checks if the regmap config fields like width, reg_offset_shift, range specifiers, etc work. The second test checks if regmap fields behave properly (mask and shift are ok) by peeking into the regmap. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-24 04:34:18 +00:00
some_regmapped-bus {
#address-cells = <0x1>;
#size-cells = <0x1>;
ranges = <0x0 0x0 0x10>;
compatible = "simple-bus";
regmap-test_0 {
reg = <0 0x10>;
compatible = "sandbox,regmap_test";
};
};
dm: Add basic tests Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-02-26 22:59:21 +00:00
};
sandbox: dts: add sandbox_pmic.dtsi and include it to sandbox.dts and test.dts This commit adds dtsi file for Sandbox PMIC. It fully describes the PMIC by: - i2c emul node - with a default settings of 16 registers - 2x buck regulator nodes - 2x ldo regulator nodes The default register settings are set with preprocessor macros: - VAL2REG(min[uV/uA], step[uV/uA], val[uV/uA]) - VAL2OMREG(mode id) Both defined in file: - include/dt-bindings/pmic/sandbox_pmic.h The Voltage ranges of each regulator can be found in: - include/power/sandbox_pmic.h The new file is included into: - sandbox.dts - test.dts Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on sandbox: Tested-by: Simon Glass <sjg@chromium.org>
2015-05-13 11:38:35 +00:00
#include "sandbox_pmic.dtsi"
sandbox: enable cros-ec-keyb in test.dtb Currently keyboard input fails in the GUI window opened by ./u-boot -T -l Add the missing include to test.dts. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-02-18 12:01:35 +00:00
#include "cros-ec-keyboard.dtsi"
Reference in a new issue Copy permalink