> > I'm still not convinced modelling this as a multipoint bus is a good > > idea. If nothing else you've failed to model the case where multiple > > slaves are selected simultanously. > > The bus can easily be changed such that multiple devices are > selectable at once to get your desired multi device behaviour. AFAICT > though nothing in QEMU behaves like this ATM.
By my reading your xilinx device *should* behave like this. > > Given the chip selects are actual wires, not part of > > the bus itself, I think multiple point-point busses are a better fit. > > > > For the stellaris device we still have the synthetic mux device and > > intermediate bus. > > Yes, because in your stellaris architecture, the SSI controller > (pl022) is point to point so that exactly matches the hardware. > > In the microblaze controller in this series, the controller has > inbuilt muxing with one-hot CS behavior. To implement with point to > point, I would have to dynamically create a number of sub-busses > (driven by a qdev property). I would also have to have a device within > a device to model the internal mux which increases my code volume > significantly. Also you end up with this little piece of ugliness in > your machine model and device model: I don't see why would would need a separate mux device. One of my issues is that you've made this a device property. A SPI device has no concept of address. This really is a property of the controller. > The multi-slave bus is a direct superset on point-to-point. There is > nothing stopping anyone from using it as p2p. Its just things are very > ugly for SPI controllers with integrated muxes to treat everything as > point to point. IMHO the resulting tree device is better with multiple point-point links. I'm hoping the hardcoded board descriptions (i.e. everything using ssi_create_slave) will go away sooner rather than later. Having two m25p80 devices that are indistinguishable apart from one minor property seems undesirable. Paul
