Device Tree and code size

Question

As per my understanding of device trees, one of main uses is to remove platform specific code from drivers to support multiple platforms. How does device tree handle multiple configuration for a single peripheral?

For example if I want to use LCD Panel A in Platform A and LCD Panel B in Platform B, do I need to keep both LCD Panel A and Panel B related code in the final binary? If that is the case and there are multiple peripherals with more than one option, it seems there will be huge additional code in the binary.

Answer 1

Suppose consider if you have 5 LCD panels and 5 platform(machines), keep 5 dtsi files each for each panel and have different dtsi files for each platform/machine.

For single configuration: Include particular dtsi panel file inside dtsi file of particular platform/machine of your interest. Outcome: - By this way you don't have to pass all the panel configurations and on-off LCD options in your board file. In simple you don't have to create separate board files for your new machine,instead have multiple device tree files and include any one of your interest during build.

For multiple configuration: you can add n panel dtsi files inside your machine dtsi file of interest. and by enabling/disabling particular lcd panel in defconfig file you can have any LCD panel driver enabled at run-time. Outcome: - By this way , you avoid 1000 panel configurations added in single board file(you know how messy it is), Instead have 1000 dtsi files and add 1000 dt header panel files inside machine dt file and raise particular panel flag in defconfig. this will ease the job. In simple- single board file and dtb containing all the files. reduces overall kernel size.

Answer 2

For example if I want to use LCD Panel A in Platform A and LCD Panel B in Platform B, So do I need to keep both LCD Panel A and Panel B related code in the final binary?

There are three cases for drivers.

1. Completely different chip and bus/sub-system.
2. Same bus/sub-system, but different chip set.
3. Same bus/sub-system, same chip set, different parameters.

From this you should understand the answer. For an LCD, the driver is usually hosted on the SOC and the panel just changes parameters such as display geometry (1/4 VGA versus 1/2 VGA), timing (50Hz versus 75HZ) and possibly control signals (OE active low/high, active/passive matrix, etc). This is actually handled exceptionally well by the device tree concept.

Prior to device tree, a machine file would pass platform data to the driver; this contains the parameters mentioned above. As the machine file is code, both versions must be contained in the kernel for panel A and panel B. This is not too bad, but for Ubuntu type releases with 1000s of panels, this can be an issue. Previously the boot loader passed a single machine id and this keyed which machine file to use. Now, the device tree is passed by the boot loader and the machine file is generally converted to a device tree structure.

Now, if the machine has different Ethernet controller chips, you can use both device trees and modules to keep the kernel size down. This is the 2^nd case mentioned above.

The 3^rd case can also be handled with modules. For instance, a wifi driver and an HSDPA modem may be communication mechanisms on different platforms. The 802.11 sub-system can be a module and can the n-gsm code. Further, the HSDPA modem may use USB or a UART, whereas the wifi may use SPI or SDIO. Some of this code may not be able to be convert modules as it may have some tight coupling with the network stack. Generally every effort is made to minimize this overhead.

So generally, the device tree concept is actually reducing code; at least in SDRAM which is a primary resource that is at a premium. NAND flash or other bulk storage may be bigger. You have the option to statically configure the device for a specific piece of hardware. If you intend to support both panels in one image, then device trees are better. In fact, they are better in almost all cases.