Wait for one bus, then 6 come along at once

While updating the DCI4 slot location definitions recently, I had cause to consider the groupings of bus definitions in Hdr:HALDevice. It seems we’ve lost our way from what I think the original intent was.

If I roll back through CVS history the heirarchy of bus types is much more clear, there are

• Peripherals considered part of the processor core (ProBus), for example the timer registers that you can read via CP15 registers
• The next fastest/widest connection beyond the caches is the main system bus (SysBus), for example the AHB in the original AMBA specification
• Slightly slower/narrower is the on chip peripheral bus (PeriBus), for example the APB in the original AMBA specification
• Then the expansion buses wandering over the PCB (ExpBus) like PCI and the podule bus
• Lastly the narrowest/slowest serial family (SerBus) including IIC

This all seems pretty clear and logical when ordered in this way thinking about width and latency. There are some anomalies, and that’s what I’d like to tidy up as we inch towards a stable release.

The 5 that look out of place are

1. HALDeviceSysBus_OPEN – this could arguably be an expansion bus since that’s what the Risc PC uses it for, but since it is the untransformed raw ARM bus it probably is a SysBus it’s just unique in that it’s the only one that comes out on PCB tracks, which the more recent system buses can’t do because of their high speed
2. HALDevicePeriBus_GPMC – I’d group this one with the ExpBus ones, because it goes off chip having been translated by a general purpose memory controller, which is mostly “ISA-like” or “SRAM-like” much as an EASI bus podule is
3. HALDeviceInterconnectBus_L3 – for me this is in the class SysBus, if I get the PXA255 datasheet for the XScale and look at what a PXBus is, this is also the fastest and widest link from the core to the big data consumers like the on chip video controller
4. HALDeviceInterconnectBus_L4 – reading the AMBA spec I’d class this a PeriBus, since it’s had one level of bridging from the SysBus and is slower and narrower but still on chip
5. HALDeviceInterconnectBus_IMX6 – this one’s just made up! There’s no such thing as an IMX6 bus, and a peruse of Fig 1-2 in the iMx6 TRM shows it actually employs two perfectly standard bus types (AXI and AHB) so we just need a new definition for AXI from AMBA 2 since there’s already one for AHB in the SysBus section, plus the bits and bobs shown in Fig 14-1 on the APB which is already allocated

Having grep’d all the sources, fortunately nothing is actually relying on the HALDevice location field to latch onto devices (they all use the type/id), so this looks like a purely administrative job of changing the definitions and updating the OMAP3/4 HALs and dropping RComp an email to get them to change the work in progress iMx6 one.

Looks like a reasonable set of changes to me.

Perhaps add some comments to the header as well, to make it clearer what the intended hierarchy is meant to be?