Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-16 01:38:22 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/sandbox/dts/test.dts

275 lines
4.7 KiB
Text
Raw Normal View History

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/;
/ {
model = "sandbox";
compatible = "sandbox";
#address-cells = <1>;
#size-cells = <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
aliases {
console = &uart0;
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
eth0 = "/eth@10002000";
eth5 = &eth_5;
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";
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
pci0 = &pci;
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";
testfdt1 = "/some-bus/c-test@1";
testfdt3 = "/b-test";
testfdt5 = "/some-bus/c-test@5";
testfdt8 = "/a-test";
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;
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
};
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 {
reg = <0>;
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;
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
test-gpios = <&gpio_a 1>, <&gpio_a 4>, <&gpio_b 5 0 3 2 1>,
<0>, <&gpio_a 12>;
test2-gpios = <&gpio_a 1>, <&gpio_a 4>, <&gpio_b 6 1 3 2 1>,
<&gpio_b 7 2 3 2 1>, <&gpio_b 8 4 3 2 1>,
<&gpio_b 9 0xc 3 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
};
junk {
reg = <1>;
compatible = "not,compatible";
};
no-compatible {
reg = <2>;
};
b-test {
reg = <3>;
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>;
};
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: 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
reg = <3>;
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: 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
reg = <3>;
ping-expect = <6>;
ping-add = <6>;
compatible = "google,another-fdt-test";
};
e-test {
reg = <3>;
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";
};
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@0 {
compatible = "sandbox,clk";
};
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>;
fake-host-hwaddr = <0x00 0x00 0x66 0x44 0x22 0x00>;
};
eth_5: eth@10003000 {
compatible = "sandbox,eth";
reg = <0x10003000 0x1000>;
fake-host-hwaddr = <0x00 0x00 0x66 0x44 0x22 0x11>;
};
eth@10004000 {
compatible = "sandbox,eth";
reg = <0x10004000 0x1000>;
fake-host-hwaddr = <0x00 0x00 0x66 0x44 0x22 0x22>;
};
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
gpio_a: base-gpios {
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 = "sandbox,gpio";
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
gpio-controller;
#gpio-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
gpio-bank-name = "a";
num-gpios = <20>;
};
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
gpio_b: extra-gpios {
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 = "sandbox,gpio";
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
gpio-controller;
#gpio-cells = <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
gpio-bank-name = "b";
num-gpios = <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
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>;
reg = <0>;
compatible = "sandbox,i2c";
clock-frequency = <100000>;
eeprom@2c {
reg = <0x2c>;
compatible = "i2c-eeprom";
emul {
compatible = "sandbox,i2c-eeprom";
sandbox,filename = "i2c.bin";
sandbox,size = <256>;
};
};
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";
emul {
compatible = "sandbox,i2c-rtc";
};
};
rtc_1: rtc@61 {
reg = <0x61>;
compatible = "sandbox-rtc";
emul {
compatible = "sandbox,i2c-rtc";
};
};
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: 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
};
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
mmc {
compatible = "sandbox,mmc";
};
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: pci-controller {
compatible = "sandbox,pci";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x02000000 0 0x10000000 0x10000000 0 0x2000
0x01000000 0 0x20000000 0x20000000 0 0x2000>;
pci@1f,0 {
compatible = "pci-generic";
reg = <0xf800 0 0 0 0>;
emul@1f,0 {
compatible = "sandbox,swap-case";
};
};
};
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";
};
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>;
reg = <0>;
compatible = "sandbox,spi";
cs-gpios = <0>, <&gpio_a 0>;
spi.bin@0 {
reg = <0>;
compatible = "spansion,m25p16", "spi-flash";
spi-max-frequency = <40000000>;
sandbox,filename = "spi.bin";
};
};
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: 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";
hub {
compatible = "usb-hub";
usb,device-class = <9>;
hub-emul {
compatible = "sandbox,usb-hub";
#address-cells = <1>;
#size-cells = <0>;
flash-stick {
reg = <0>;
compatible = "sandbox,usb-flash";
sandbox,filepath = "testflash.bin";
};
};
};
};
usb_2: usb@2 {
compatible = "sandbox,usb";
status = "disabled";
};
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"
Reference in a new issue Copy permalink