The qdev_gpio conversion of 343ec8e caused come polarity mismatch of key
event pins and left an overly complex solution behind. Take this chance
and refactor the GPIO input system of the Musicpal, moving it closer to
reality:
- Instantiate all 32 GPIO input pins and do the routing only via
qdev_connect_gpio_out.
- Implement IMR and IER registers. They manage the GPIO pin IRQ. IMR
seems to enable IRQs on rising edges, IER on falling ones. At least
this matches what the Musicpal fireware require.
- Move key pin logic inversion from the GPIO layer to musicpal_key.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
They likely represent invalid queues that should be skipped. We already
do this for RX queues. Wish I had a spec...
Credits go to malc for analyzing the issue and suggesting this fix.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
mce_banks is always MCE_BANKS_DEF * 4 in size, value never change
CC: Huang Ying <ying.huang@intel.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Don't even ask, being able to load/save between 64<->80bit floats should be forbidden
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We save more that fpus on that 16 bits (fpstt), we need an additional field
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This makes the savevm code correct, and sign extensins gives us exactly
what we need (namely, sign extend to 64 bits when used with 64bit addresess.
Once there, change 0x100000 for 1 << 20, that maks all a20 use the same syntax.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
They were saved as uint8_t already. To make things simpler, I just
reg == -1 used to indicate an error, I create LM832x_GENERAL_ERROR
with vale 0xff to represet it
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Just don't look. struct tm members are ints' and they are sent as uint16_t.
VMState code complains as it should. Have to create hacky int32_as_uint16
type. Don't ever think about copying it
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
its value is always the level of an interrupt, 0 or 1
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
They were using only with very small integers, and they are sent/read as
bytes. They can't become negative as far as I can see
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This one is needed for changees happening on fdc. It allows you to send
arrays of structs whose size we want to send it is another field with type
uint8_t. (If you have been able to read the whole sentence without
stoping for breathing, you can use it.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Now that we have version_id on post_load() we don't need the old load
function
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In a later patch, we introduce pre_save() and post_save() functions.
The whole point of that operation is to change things in the state.
Without this patch, we have to remove the const qualifier in each
use with a cast
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
