andrzej zaborowski wrote:
> On 22 February 2012 13:00, Peter Maydell wrote:
>> On 22 February 2012 11:36, andrzej zaborowski wrote:
>>> On 22 February 2012 11:15, Igor Mitsyanko wrote:
Convert three variables in DMAChannel state from type
target_phys_addr_t to uint32_t,
use VMSTA
On 02/22/2012 04:56 PM, andrzej zaborowski wrote:
On 22 February 2012 13:48, Peter Maydell wrote:
On 22 February 2012 12:13, andrzej zaborowski wrote:
On 22 February 2012 13:00, Peter Maydell wrote:
On 22 February 2012 11:36, andrzej zaborowski wrote:
On 22 February 2012 11:15, Igor Mit
On 02/22/2012 04:48 PM, andrzej zaborowski wrote:
On 22 February 2012 13:26, Mitsyanko Igor wrote:
On 02/22/2012 03:36 PM, andrzej zaborowski wrote:
Why's uint32_t more correct though? The purpose of using a named type
across qemu is to mark fields as memory addresses (similar to size_t
being
On 22 February 2012 13:48, Peter Maydell wrote:
> On 22 February 2012 12:13, andrzej zaborowski wrote:
>> On 22 February 2012 13:00, Peter Maydell wrote:
>>> On 22 February 2012 11:36, andrzej zaborowski wrote:
On 22 February 2012 11:15, Igor Mitsyanko wrote:
> Convert three variables
On 22 February 2012 13:26, Mitsyanko Igor wrote:
> On 02/22/2012 03:36 PM, andrzej zaborowski wrote:
>> Why's uint32_t more correct though? The purpose of using a named type
>> across qemu is to mark fields as memory addresses (similar to size_t
>> being used for sizes, etc.), uint32_t conveys le
On 22 February 2012 12:13, andrzej zaborowski wrote:
> On 22 February 2012 13:00, Peter Maydell wrote:
>> On 22 February 2012 11:36, andrzej zaborowski wrote:
>>> On 22 February 2012 11:15, Igor Mitsyanko wrote:
Convert three variables in DMAChannel state from type target_phys_addr_t
On 02/22/2012 03:36 PM, andrzej zaborowski wrote:
On 22 February 2012 11:15, Igor Mitsyanko wrote:
Convert three variables in DMAChannel state from type target_phys_addr_t to
uint32_t,
use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
We can do it safely because:
1) pxa2xx has
On 22 February 2012 13:00, Peter Maydell wrote:
> On 22 February 2012 11:36, andrzej zaborowski wrote:
>> On 22 February 2012 11:15, Igor Mitsyanko wrote:
>>> Convert three variables in DMAChannel state from type target_phys_addr_t to
>>> uint32_t,
>>> use VMSTATE_UINT32 instead of VMSTATE_UINT
On 22 February 2012 11:36, andrzej zaborowski wrote:
> On 22 February 2012 11:15, Igor Mitsyanko wrote:
>> Convert three variables in DMAChannel state from type target_phys_addr_t to
>> uint32_t,
>> use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
>> We can do it safely because:
On 22 February 2012 11:15, Igor Mitsyanko wrote:
> Convert three variables in DMAChannel state from type target_phys_addr_t to
> uint32_t,
> use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
> We can do it safely because:
> 1) pxa2xx has 32-bit physical address;
> 2) rest of the c
On 22 February 2012 10:15, Igor Mitsyanko wrote:
> Convert three variables in DMAChannel state from type target_phys_addr_t to
> uint32_t,
> use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
> We can do it safely because:
> 1) pxa2xx has 32-bit physical address;
> 2) rest of the c
Convert three variables in DMAChannel state from type target_phys_addr_t to
uint32_t,
use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
We can do it safely because:
1) pxa2xx has 32-bit physical address;
2) rest of the code in this file treats these variables as uint32_t;
3) we sho
12 matches
Mail list logo
