Re: [Qemu-devel] [PATCH v3 20/20] arm: add Faraday FTSPI020 SPI flash controller support

[Andreas Färber]

Am 07.02.2013 07:59, schrieb Kuo-Jung Su:
> 2013/2/7 Peter Crosthwaite <address@hidden>:
>> On Wed, Feb 6, 2013 at 7:45 PM, Kuo-Jung Su <address@hidden> wrote:
>>> diff --git a/hw/arm/ftspi020.h b/hw/arm/ftspi020.h
>>> new file mode 100644
>>> index 0000000..a8a0930
>>> --- /dev/null
>>> +++ b/hw/arm/ftspi020.h
>>> @@ -0,0 +1,50 @@
>>> +/*
>>> + * Faraday FTSPI020 Flash Controller
>>> + *
>>> + * Copyright (c) 2012 Faraday Technology
>>> + * Written by Dante Su <address@hidden>
>>> + *
>>> + * This code is licensed under GNU GPL v2+.
>>> + */
>>> +
>>> +#ifndef HW_ARM_FTSPI020_H
>>> +#define HW_ARM_FTSPI020_H
>>> +
>>
>> This device is not exporting any extensible APIs there is no need for
>> a header specific to this device.
>>
> 
> Got you, but does this applied to ftrtc011 ?
> I remember someone had made a request to me to create header files
> for registers. Or maybe it's just a mis-understanding.
> 
>>> +/******************************************************************************
>>> + * FTSPI020 registers
>>> + 
>>> *****************************************************************************/
>>> +#define REG_CMD0            0x00    /* Flash address */
>>> +#define REG_CMD1            0x04
>>> +#define REG_CMD2            0x08
>>> +#define REG_CMD3            0x0c
>>> +#define REG_CTRL            0x10    /* Control Register */
>>> +#define REG_ACT             0x14    /* AC Timing Register */
>>> +#define REG_STR             0x18    /* Status Register */
>>> +#define REG_ICR             0x20    /* Interrupt Control Register */
>>> +#define REG_ISR             0x24    /* Interrupt Status Register */
>>> +#define REG_RDST            0x28    /* Read Status Register */
>>> +#define REG_REV             0x50    /* Revision Register */
>>> +#define REG_FEA             0x54    /* Feature Register */
>>> +#define REG_DATA            0x100    /* Data Register */
>>> +
>>
>> These can just live in the C file - they are private to the implementation.

No. Having them in a header means they can be reused by qtests.

To embed the device into a SoC object, the state struct and TYPE_
constant should be in the header. That applies to each device part of
the SoC rather than on the board.

I did suggest splitting the header into <foo>_regs.h for qtest+softmmu
and <foo>.h for softmmu only though.

> BTW, tomorrow is the beginning of my Chinese New Year holidays, so
> please forgive me
> that I won't be able to make any response to the comments for 10 days.

v1.4.0 is going to be released Feb 15. Before that no new patches can be
applied anyway.
http://wiki.qemu.org/Planning/1.4

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg