Traditionally, you get hardware and then write a driver for it. As an SoC creator, however, the driver development is part of the development cycle, i.e. it is done before final hardware (or any hardware) is available.
The SoC design process consists of 6 stages in a (more or less) cycle. It starts with an idea (“what do we want to make”) – based on previous SoCs. This includes finding a fit with the market and community. That includes easy of use, which means software support. It also includes for IP blocks how open source friendly the vendor is.
In the design stage, the details of IP blocks are fleshed out. That includes how it will work with each Linux subsystem.
The validation stage includes writing the Verilog and to start software development on it. This uses VLAB, a kind of qemu for chips. It allows iterating on the software, e.g. early boot, without requiring hardware yet. It thus makes it possible to give feedback to the hardware team about which things aren’t working. Cycle-accurate FPGA emulation is also done here, but it can’t be done on a software developer’s desk. It does allows to understand performance number, run actual benchmarks e.g. cyclictest. This is e.g. important to evaluate DDR access latency. This is also a great time to find bugs, both in the hardware and in the drivers. However, anything with analog components can’t be handled here, e.g. PHYs. Another concern at this stage is that you’re not entirely sure if the emulation really reflects the actual hardware.
The tapeout stage is where the actual hardware is produced. Now is the time to design boards and other supporting components with the new SoC. This includes e.g. PMICs, which needs drivers as well.
The wakeup stage is where the software is really exercised. This is the stage where most patches are sent upstream, when they’ve been validated on the hardware. The development work itself is mostly documentation and device trees.
The support stage is when users start using the new SoC in unexpected ways. This exposes bugs but also documenting use cases. This feeds back into the ideas for the next SoC.
How did TI arrive in this upstream first model? TI made a lot of mistakes in the past about this. The big thing that changed is understanding the value for customers. Having continued support is important for TI’s customers, and this means that it has to be upstream.