From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPTw8-0003La-54 for qemu-devel@nongnu.org; Tue, 09 Apr 2013 04:29:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPTw6-0002xP-A8 for qemu-devel@nongnu.org; Tue, 09 Apr 2013 04:29:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPTw6-0002wx-2J for qemu-devel@nongnu.org; Tue, 09 Apr 2013 04:29:50 -0400 Message-ID: <5163D16F.2090209@redhat.com> Date: Tue, 09 Apr 2013 10:29:35 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1365136091-26148-1-git-send-email-lig.fnst@cn.fujitsu.com> <1365136091-26148-3-git-send-email-lig.fnst@cn.fujitsu.com> <1365151509.14731.7.camel@liguang.fnst.cn.fujitsu.com> <1365381168.5674.19.camel@liguang.fnst.cn.fujitsu.com> <1365495274.9553.53.camel@liguang.fnst.cn.fujitsu.com> In-Reply-To: <1365495274.9553.53.camel@liguang.fnst.cn.fujitsu.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH][RFC v2 2/7] hw/power: add main power chip implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: li guang Cc: stefanha@gmail.com, Peter Maydell , aliguori@us.ibm.com, qemu-devel@nongnu.org, afaerber@suse.de 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.