Il 09/04/2013 10:14, li guang ha scritto: > The approach of power-control may be specific for architectures, > but, I think the thought beneath is common, e.g. for some ARM and MIPS > platforms, OS issue commands to a embedded controller's firmware, > then this firmware will help to do the real power-control job( > on/off, of course no suspend), and also, there are some platforms > directly generate power signals on some specific GPIOs then, > these signals via a power chip will affect other devices. > 1. 2. > ----- ----- > | OS | | OS | > --+-- ----- > |on/off |on/off > --------------------------------------------- > | -----+----- -----+----- | > | | firmware | | GPIO | | > | -----+----- -----+----- | > ---------+----------------- | | part 2 > |on/off | |on/off | > +------+------+ | ----+----- | > | | | | |power chip| | > ------ ----- ---- | ---------- | > | dev0 ||dev1 ||dev2| --------|on/off--- > ------ ----- ---- +------+------+ > | | | > ------ ----- ---- > | dev0 ||dev1 ||dev2| > ------ ----- ---- > so, in graph 1, firmware acts like the power chip and related gpios > in graph 2, then, I boldly assume a conceptual power chip exist, > it can either be part 2 of graph 1 or 2.
But QEMU doesn't treat conceptual things as devices. It models them as APIs, such as the memory API or the one that I pointed out in my previous message. Paolo > as you said, qemu should only model real hardware, > I am confused, can the demonstration above part 2 be consider a > real hardware? but it does not have vendor and dev-id ... > and it's not real hardware? but it dose work just same with > real hardware.
