qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH arm-devs v1 06/15] xilinx_spips: Fix QSPI FIFO s


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH arm-devs v1 06/15] xilinx_spips: Fix QSPI FIFO size
Date: Mon, 8 Apr 2013 18:07:46 +1000

On Sat, Apr 6, 2013 at 4:50 AM, Peter Maydell <address@hidden> wrote:
> On 3 April 2013 05:32, Peter Crosthwaite <address@hidden> wrote:
>> QSPI has a bigger FIFO than the regular SPI controller. Differentiate
>> between the two with correct FIFO sizes for each.
>>
>> Signed-off-by: Peter Crosthwaite <address@hidden>
>> ---
>>
>>  hw/xilinx_spips.c |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/xilinx_spips.c b/hw/xilinx_spips.c
>> index 06c2ec5..78a3fec 100644
>> --- a/hw/xilinx_spips.c
>> +++ b/hw/xilinx_spips.c
>> @@ -106,6 +106,9 @@
>>  #define RXFF_A          32
>>  #define TXFF_A          32
>>
>> +#define RXFF_A_Q          (64 * 4)
>> +#define TXFF_A_Q          (64 * 4)
>> +
>>  /* 16MB per linear region */
>>  #define LQSPI_ADDRESS_BITS 24
>>  /* Bite off 4k chunks at a time */
>> @@ -575,6 +578,10 @@ static void xilinx_qspips_realize(DeviceState *dev, 
>> Error **errp)
>>      s->num_txrx_bytes = 4;
>>
>>      xilinx_spips_realize(dev, errp);
>> +    fifo8_destroy(&s->rx_fifo);
>> +    fifo8_destroy(&s->tx_fifo);
>> +    fifo8_create(&s->rx_fifo, RXFF_A_Q);
>> +    fifo8_create(&s->tx_fifo, TXFF_A_Q);
>>      memory_region_init_io(&s->mmlqspi, &lqspi_ops, s, "lqspi",
>>                            (1 << LQSPI_ADDRESS_BITS) * 2);
>>      sysbus_init_mmio(sbd, &s->mmlqspi);
>
> Destroying and recreating the fifos seems a bit odd -- can you
> structure this so the base class instance init just creates them
> at the right size? I guess the obvious way would be to have the
> class struct have a field for fifo size which the class init
> function sets appropriately, and then instance init creates
> a fifo of that size.

Done.

Regards,
Peter

>This is kind of like how target-arm/cpu.c
> handles ID register fields, but in the class rather than the
> instance struct.
>
> -- PMM
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]