[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v7 02/13] ssi: Implemented CS behaviour
From: |
Peter Crosthwaite |
Subject: |
Re: [Qemu-devel] [PATCH v7 02/13] ssi: Implemented CS behaviour |
Date: |
Mon, 24 Sep 2012 20:56:12 +1000 |
On Mon, Sep 24, 2012 at 8:19 PM, Peter Crosthwaite
<address@hidden> wrote:
> On Mon, Sep 24, 2012 at 7:29 PM, Peter Maydell <address@hidden> wrote:
>> On 24 September 2012 10:18, Peter A. G. Crosthwaite
>> <address@hidden> wrote:
>>> @@ -296,10 +297,13 @@ static void ssd0323_save(QEMUFile *f, void *opaque)
>>> qemu_put_be32(f, s->remap);
>>> qemu_put_be32(f, s->mode);
>>> qemu_put_buffer(f, s->framebuffer, sizeof(s->framebuffer));
>>> +
>>> + qemu_put_be32(f, ss->cs);
>>> }
>>>
>>> static int ssd0323_load(QEMUFile *f, void *opaque, int version_id)
>>> {
>>> + SSISlave *ss = SSI_SLAVE(opaque);
>>> ssd0323_state *s = (ssd0323_state *)opaque;
>>> int i;
>>>
>>> @@ -321,6 +325,8 @@ static int ssd0323_load(QEMUFile *f, void *opaque, int
>>> version_id)
>>> s->mode = qemu_get_be32(f);
>>> qemu_get_buffer(f, s->framebuffer, sizeof(s->framebuffer));
>>>
>>> + ss->cs = qemu_get_be32(f);
>>> +
>>> return 0;
>>> }
>>
>> This looks odd. The cs field isn't part of the ssd0323_state,
>> so it shouldn't be ssd0303_save/load's job to save and restore
>> it. Contrast the way the vmstate-based devices don't directly
>> save/restore cs but defer to VMSTATE_SSI_SLAVE.
>>
>
> I took a "when in rome" philosophy here, and did it the way the device
> model already does VMSD. The rest of the device state is encapsulated
> using this mechanism. Im guessing this is an old way of doing VMSD
> with the whole register_savevm() thing. Is it possible to mix and
> match this old file-style VMSD with the newer struct approach? I cant
> see an easy way without completely rewriting the VMSD implementation
> of this device model.
>
Hi Juan,
We have another curly VMSD question on this series. The hw/ssd0323.c
uses the old school register_savevm() scheme for VMSD. With this
series, this device now inherits from another device (TYPE_SSI_SLAVE)
which has proper VMSD support. The question is can, we mix and match
the old and new VMSD to avoid having to rewrite this device models
VMSD? Can we leave this device model vmsd as is and add the vm_state
with the single SSI_SLAVE field? This vmsd would then save/load the
inherited state and co-exist with the register_savevm() implementation
for the non-inherited state.
Regards,
Peter
> Regards,
> Peter
>
>> -- PMM
- [Qemu-devel] [PATCH v7 00/13] Ehnahced SSI bus support + M25P80 SPI flash + Xilinx SPI controller, Peter A. G. Crosthwaite, 2012/09/24
- [Qemu-devel] [PATCH v7 03/13] ssi: Added create_slave_no_init(), Peter A. G. Crosthwaite, 2012/09/24
- [Qemu-devel] [PATCH v7 04/13] qdev: allow multiple qdev_init_gpio_in() calls, Peter A. G. Crosthwaite, 2012/09/24
- [Qemu-devel] [PATCH v7 05/13] hw/stellaris: Removed gpio_out init array., Peter A. G. Crosthwaite, 2012/09/24
- [Qemu-devel] [PATCH v7 06/13] stellaris: Removed SSI mux, Peter A. G. Crosthwaite, 2012/09/24
- [Qemu-devel] [PATCH v7 07/13] hw: Added generic FIFO API., Peter A. G. Crosthwaite, 2012/09/24
- [Qemu-devel] [PATCH v7 08/13] m25p80: Initial implementation of SPI flash device, Peter A. G. Crosthwaite, 2012/09/24
- [Qemu-devel] [PATCH v7 09/13] xilinx_spi: Initial impl. of Xilinx SPI controller, Peter A. G. Crosthwaite, 2012/09/24
- [Qemu-devel] [PATCH v7 10/13] petalogix-ml605: added SPI controller with n25q128, Peter A. G. Crosthwaite, 2012/09/24