From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScGQH-0002af-8x for qemu-devel@nongnu.org; Wed, 06 Jun 2012 09:37:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScGQC-0008Ou-8v for qemu-devel@nongnu.org; Wed, 06 Jun 2012 09:37:16 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:56982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScGQC-0008Oi-2z for qemu-devel@nongnu.org; Wed, 06 Jun 2012 09:37:12 -0400 From: Paul Brook Date: Wed, 6 Jun 2012 14:37:07 +0100 References: <201206050234.09903.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206061437.07528.paul@codesourcery.com> Subject: Re: [Qemu-devel] [PATCH V4 0/5] Ehnahced SSI bus support + M25P80 SPI flash + Xilinx SPI controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: stefanha@gmail.com, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, john.williams@petalogix.com, peter.maydell@linaro.org > > 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