[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Register uhci_reset() callback.

From: Blue Swirl
Subject: Re: [Qemu-devel] Register uhci_reset() callback.
Date: Tue, 16 Jun 2009 22:10:59 +0300

On 6/16/09, Jamie Lokier <address@hidden> wrote:
> Jamie Lokier wrote:
> > Blue Swirl wrote:
>  > It's analogous to a distributed atomic transaction problem.

I did not wrote this, it was you.

>  >
>  > So you need two phases:
>  >
>  >     - Restoring: All devices states are restored, one by one including
>  >       output levels of interrupt lines and GPIOs, but nothing actually
>  >       _happens_ when those levels are set.
>  >
>  >     - Running: All devices start running at the same instant from
>  >       their restored state.  They don't need to reexamine input
>  >       levels, because their internal states are already consistent
>  >       with the input levels.
>  >
>  > In the restoring phase, you might still use the normal functions to
>  > set output levels, but they would be prevented from being passed as
>  > changes to other devices.
>  >
>  > Anything else might be made to work with particular PICs etc., but
>  > two-phase restore is what you need to work with any wiring (including
>  > cycles) of arbitrary devices with arbitrary states.
> I should say, the above applies to both restoring saved state, and
>  whole system resets.
>  That's why real hardware has a nice long reset pulse, during which
>  every input change is ignored until the reset pulse is removed.

qemu_irq does not have state. It's different from real HW IRQ, so QEMU
devices don't need to do anything. I also had this confused earlier.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]