I also want to join in Dougie's praise of Phil.
He has done an outstanding job in smoothing out the introduction of Device Tree.
It's a rare thing to see an engineer write so much documentation without being wipped. But it can also be because he's smart, who's going to answer all those DT questions
And why do need this Device Tree thing?
It's because the entire ARM world is moving towards it, and because it becomes difficult to add support for the increasing number of Pi add-on boards without it.
Many of these boards use I2C, SPI and/or gpio's. These busses doesn't have enumeration capabilities, so the kernel has to be told about a device's presence.
Device Tree is perfect for this.
And if we add the DT overlay parameters into this, we have a very powerful and simple way to tweak the device.
Previously such parameters would have to be added to the platform specific kernel code, which meant that only parameters needed by many people would be implemented.
And if the official DT overlay doesn't quite cut it, it's relatively easy to make one that fits. Previously such changes would require a kernel build.
It seems to me that the whole device tree idea has shifted the relative pain felt by kernel developers when dealing with different devices from themselves to the implementers and end users.
This is in part correct.
In the x86 world BIOS is very helpful in setting up devices and help with enumeration. In the ARM world there is no BIOS. All the non enumerable device information is kept in the platform or board file. This makes it almost impossible to make a kernel that will boot on several different platforms/boards.
Imagine having to install a specific kernel for the Toshiba laptop and another one for the Dell laptop? This is what's happening in the ARM world.
With Device Tree it's possible to build multi architecture kernels, and let the bootloader provide a Device Tree that matches the board.
A device maker in the pre-DT world still had to make a patch to implement their device in the platform code. Now they make a Device Tree overlay instead. I can't imagine anyone who has the responsibility to maintain device support for the Pi ever wanting to go back.
End users have to learn about DT overlays. And yes, I hate when things that worked before, suddenly stops working. But I would say that Phil's documentation is quite good, and finally getting some sticky posts in the forums have probably relieved the pain for many.
And the result is quite powerful on a development board like the Pi with it's myriad of add-on boards.
All kinds of drivers can now be enabled in the official kernel build, and it's easy to make use of them. No need to build a kernel just to get that driver almost no one uses with it's device adding code!
When HAT manufacturers start adding eeprom's with DT overlays on them, we really reap the benefit from this.
Just plug in the board with the default kernel and Everything just works!