On 9/21/18 5:37 PM, Peter Maydell wrote:
> On 21 September 2018 at 06:39, Damien Hedde
> wrote:
>> On 09/19/2018 11:30 PM, Peter Maydell wrote:
>>> There are several possible approaches here I think:
>>>
>>> (1) the "clock" object holds no internal state; if a device on the
>>> destination en
On 21 September 2018 at 06:39, Damien Hedde wrote:
> On 09/19/2018 11:30 PM, Peter Maydell wrote:
>> There are several possible approaches here I think:
>>
>> (1) the "clock" object holds no internal state; if a device on the
>> destination end of a clock connection cares about clock state then
>
On 09/19/2018 11:30 PM, Peter Maydell wrote:
> On 17 September 2018 at 01:40, wrote:
>> Regarding the migration strategy, clocks do not hold the clock state
>> internally, so there is nothing to migrate there. The consequence is that
>> a device must update its output clocks in its post_load t
On 09/19/2018 11:30 PM, Peter Maydell wrote:
> On 17 September 2018 at 01:40, wrote:
>> Regarding the migration strategy, clocks do not hold the clock state
>> internally, so there is nothing to migrate there. The consequence is that
>> a device must update its output clocks in its post_load t
On 17 September 2018 at 01:40, wrote:
> Regarding the migration strategy, clocks do not hold the clock state
> internally, so there is nothing to migrate there. The consequence is that
> a device must update its output clocks in its post_load to propagate the
> migrated clock state. This allows m
From: Damien Hedde
This series corresponds to the v4 of "clock framework api" patches
which were discussed in 2017, here:
https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg07218.html
It is a big refactoring trying to respond to comments and to integrate the
clock gating cases I sent recen
