Re: [Qemu-devel] [PATCH V4 0/5] Ehnahced SSI bus support + M25P80 SPI flash + Xilinx SPI controller

[Paul Brook <paul@codesourcery.com>]

> > 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