On 27 June 2017 at 08:04, KONRAD Frederic wrote:
> Le 06/23/2017 à 03:58 PM, Peter Maydell a écrit :
>> The pointer is for your clock inputs -- when would you
>> want to start a refresh from that? I would expect
>> refreshes to only ever go downstream -- you update
>> the config of your clock outp
Le 06/23/2017 à 03:58 PM, Peter Maydell a écrit :
On 23 June 2017 at 14:07, KONRAD Frederic wrote:
Le 06/23/2017 à 02:47 PM, Peter Maydell a écrit :
Each device "owns" its output clock objects, but input
clocks are just pointers to the clock object owned by the
device at the other end. In th
On 23 June 2017 at 14:07, KONRAD Frederic wrote:
> Le 06/23/2017 à 02:47 PM, Peter Maydell a écrit :
>> Each device "owns" its output clock objects, but input
>> clocks are just pointers to the clock object owned by the
>> device at the other end. In the board you wire up CI1 to C1,
>> and CI2 to
Le 06/23/2017 à 02:47 PM, Peter Maydell a écrit :
On 23 June 2017 at 13:38, KONRAD Frederic wrote:
Le 06/23/2017 à 11:51 AM, Peter Maydell a écrit :
As an aside, I still find it very odd that you get a clock
object for both an input clock and an output clock. I feel
like we should have one e
On 23 June 2017 at 13:38, KONRAD Frederic wrote:
> Le 06/23/2017 à 11:51 AM, Peter Maydell a écrit :
>> As an aside, I still find it very odd that you get a clock
>> object for both an input clock and an output clock. I feel
>> like we should have one end owns the clock object and the
>> other jus
Le 06/23/2017 à 11:51 AM, Peter Maydell a écrit :
On 15 June 2017 at 16:15, Edgar E. Iglesias wrote:
On Thu, Jun 15, 2017 at 04:04:56PM +0100, Peter Maydell wrote:
The difference here is that the clock objects themselves have
internal state. That's not necessarily a bad idea, but it does
mea
On 15 June 2017 at 16:15, Edgar E. Iglesias wrote:
> On Thu, Jun 15, 2017 at 04:04:56PM +0100, Peter Maydell wrote:
>> The difference here is that the clock objects themselves have
>> internal state. That's not necessarily a bad idea, but it does
>> mean that something's got to migrate that state
Le 15/06/2017 à 17:15, Edgar E. Iglesias a écrit :
On Thu, Jun 15, 2017 at 04:04:56PM +0100, Peter Maydell wrote:
On 15 June 2017 at 15:57, Edgar E. Iglesias wrote:
On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote:
Unfortunately we make no guarantees at all about migration orde
On Thu, Jun 15, 2017 at 04:04:56PM +0100, Peter Maydell wrote:
> On 15 June 2017 at 15:57, Edgar E. Iglesias wrote:
> > On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote:
> >> Unfortunately we make no guarantees at all about migration order
> >> for devices as far as I'm aware, so devi
On 15 June 2017 at 15:57, Edgar E. Iglesias wrote:
> On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote:
>> Unfortunately we make no guarantees at all about migration order
>> for devices as far as I'm aware, so devices have to cope regardless.
>
>
> How does this work for interrupts/gp
On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote:
> On 14 June 2017 at 12:54, Paolo Bonzini wrote:
> > I think the various bindings and rates could be refreshed as devices are
> > migrated. This assumes that the device migration order is okay
> > according to the clock tree, that is
On 15/06/2017 16:40, Peter Maydell wrote:
> On 14 June 2017 at 12:54, Paolo Bonzini wrote:
>> I think the various bindings and rates could be refreshed as devices are
>> migrated. This assumes that the device migration order is okay
>> according to the clock tree
>
> Unfortunately we make no g
On 14 June 2017 at 12:54, Paolo Bonzini wrote:
> I think the various bindings and rates could be refreshed as devices are
> migrated. This assumes that the device migration order is okay
> according to the clock tree, that is if you have three devices X/Y/Z and
> five clocks a/b/c/d/e/f:
>
> fi
Le 14/06/2017 à 13:54, Paolo Bonzini a écrit :
On 13/06/2017 12:33, Peter Maydell wrote:
For the migration maybe we can refresh the whole clock tree at the end
of the migration. Is that a good idea?
That seems kind of awkward -- where would this code that did a
clock tree refresh be? Also you
On 13/06/2017 12:33, Peter Maydell wrote:
>> For the migration maybe we can refresh the whole clock tree at the end
>> of the migration. Is that a good idea?
> That seems kind of awkward -- where would this code that did a
> clock tree refresh be? Also you're then reliant on all the
> callback func
On 8 June 2017 at 08:54, KONRAD Frederic wrote:
> Le 06/06/2017 à 17:18, Peter Maydell a écrit :
>> Some top-level review:
>> * qemu_clk_device_add_clock() does a g_strdup, but when is this freed?
>> (consider devices which are hot-unpluggable)
>> * similarly, what if a device with a clock with
Le 06/06/2017 à 17:18, Peter Maydell a écrit :
On 24 May 2017 at 08:35, KONRAD Frederic wrote:
Le 28/02/2017 à 11:02, fred.kon...@greensocs.com a écrit :
This is the third version of the clock framework API it contains:
* The first 6 patches which introduce the framework.
* The 7th patc
On 24 May 2017 at 08:35, KONRAD Frederic wrote:
> Le 28/02/2017 à 11:02, fred.kon...@greensocs.com a écrit :
>> This is the third version of the clock framework API it contains:
>>
>> * The first 6 patches which introduce the framework.
>> * The 7th patch which introduces a fixed-clock model.
Ping.
Thanks,
Fred
Le 28/02/2017 à 11:02, fred.kon...@greensocs.com a écrit :
From: KONRAD Frederic
Hi,
This is the third version of the clock framework API it contains:
* The first 6 patches which introduce the framework.
* The 7th patch which introduces a fixed-clock model.
* The re
From: KONRAD Frederic
Hi,
This is the third version of the clock framework API it contains:
* The first 6 patches which introduce the framework.
* The 7th patch which introduces a fixed-clock model.
* The rest which gives an example how to model a PLL from the existing
zynqmp-crf extr
20 matches
Mail list logo
