On Mon, Aug 6, 2012 at 7:48 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 6 August 2012 03:16, Peter A. G. Crosthwaite > <peter.crosthwa...@petalogix.com> wrote: >> Added a FIFO API that can be used to create and operate byte FIFOs. > > I'm not asking for actual conversions, but it would be nice to see a > list of some devices that could in principle be moved to using this FIFO, > as an indication of its general utility. >
The two device models in this series. mcf_uart.c, strongarm.c (StrongARMUARTState), xilinx_uartlite, cadence_uart.c, sh_serial.c, tsc210x.c to name the ones Ive just had a brief look over. There are more. grep -i fifo hw | grep uint8_t gives you a short list of files to look for potential clients. Dominated by uarts as they are the ones that need 8-bit fifos. Usability is greatly expanded if the fifo can be an arbitrary data type (uint32_t, uint16_t, struct foo), but that is a much harder problem to solve that id like to say is out of scope of this series. I think this is what Igor is getting at RE his PL330 comments on his continuation of this thread. Can we get the ball rolling with uint8_t then talk about generalisation strategy? > Would it make sense for the FIFO to be a QOM object, or is that a > silly idea? There could be merit in making the data entries some form of QOM object. It would hurt performance, but could solve the arbitrary data problem. Regards, Peter > > -- PMM
