[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE9FiQU=HmRCy0nxLgi7oqnjbaW4DJ2ct1EE2pVP+=rac2D+wQ@mail.gmail.com>
Date: Sat, 4 Aug 2012 13:14:27 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: Jiang Liu <liuj97@...il.com>
Cc: Len Brown <lenb@...nel.org>, Tony Luck <tony.luch@...el.com>,
Bob Moore <robert.moore@...el.com>,
Huang Ying <ying.huang@...el.com>,
Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
Wen Congyang <wency@...fujitsu.com>,
Taku Izumi <izumi.taku@...fujitsu.com>,
Jiang Liu <jiang.liu@...wei.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Hanjun Guo <guohanjun@...wei.com>,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
linux-pci@...r.kernel.org, Gaohuai Han <hangaohuai@...wei.com>
Subject: Re: [RFC PATCH 2/3] ACPIHP: ACPI system device hotplug slot enumerator
On Sat, Jul 28, 2012 at 4:42 AM, Jiang Liu <liuj97@...il.com> wrote:
> The first is an ACPI hotplug slot enumerator, which enumerates ACPI hotplug
> slots on load and provides callbacks to manage those hotplug slots.
> An ACPI hotplug slot is an abstraction of receptacles, where a group of
> system devices could be connected to. This patch implements the skeleton for
> ACPI system device hotplug slot enumerator. On loading, the driver scans the
> whole ACPI namespace for hotplug slots and creates a device node for each
> hotplug slots. Every slot is associated with a device class named
> acpihp_slot_class and will be managed by ACPI hotplug drivers.
I was thinking:
We can have module in ACPI DSDT, and every module is coresponding
to SystemModule.
so it will be
\_SB.NOD1
CPU0
CPU1
CPU2
CPU3
MEM0
MEM1
MEM2
MEM3
PCI0
PCI1
PCI2
PCI3
NTFY
STAT
STOP
NTFY will be something like:
Notify(\_SB.NOD1.CPU0,....)
Notify(\_SB.NOD1.CPU1,....)
Notify(\_SB.NOD1.CPU2,....)
Notify(\_SB.NOD1.CPU3,....)
Notify(\_SB.NOD1.MEM0,....)
Notify(\_SB.NOD1.MEM1,....)
Notify(\_SB.NOD1.MEM2,....)
Notify(\_SB.NOD1.MEM3,....)
Notify(\_SB.NOD1.PCI0,....)
Notify(\_SB.NOD1.PCI1,....)
Notify(\_SB.NOD1.PCI2,....)
Notify(\_SB.NOD1.PCI3,....)
and will link GPE button for SystemModule to call NTFY.
STAT could be 32bit integer for final turn off the power.
every CPU, MEM, PCI will own one bit, it will clear that bit in this own
_EJ0.
Every _EJ0 will double check if all are cleared, then it call extra STOP
to power off the whole SystemModule.
if OS already have seperated handler for those type objects (CPU, MEM,
PCI), we may not need to change to much to os.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists