On Thu, 2 May 2019 09:22:35 +0200 Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On Wed, 1 May 2019 at 13:25, Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com> wrote: > > > > Hi Ard, > > > > > -----Original Message----- > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > Sent: 01 May 2019 12:10 > > > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > > > Cc: QEMU Developers <qemu-devel@nongnu.org>; qemu-arm > > > <qemu-...@nongnu.org>; Auger Eric <eric.au...@redhat.com>; Igor > > > Mammedov <imamm...@redhat.com>; Peter Maydell > > > <peter.mayd...@linaro.org>; shannon.zha...@gmail.com; > > > sa...@linux.intel.com; sebastien.bo...@intel.com; xuwei (O) > > > <xuw...@huawei.com>; Laszlo Ersek <ler...@redhat.com>; Linuxarm > > > <linux...@huawei.com> > > > Subject: Re: [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support > > > > > > On Tue, 9 Apr 2019 at 12:31, Shameer Kolothum > > > <shameerali.kolothum.th...@huawei.com> wrote: > > > > > > > > From: Samuel Ortiz <sa...@linux.intel.com> > > > > > > > > The ACPI Generic Event Device (GED) is a hardware-reduced specific > > > > device[ACPI v6.1 Section 5.6.9] that handles all platform events, > > > > including the hotplug ones.This patch generates the AML code that > > > > defines GEDs. > > > > > > > > Platforms need to specify their own GedEvent array to describe what > > > > kind of events they want to support through GED. Also this uses a > > > > a single interrupt for the GED device, relying on IO memory region > > > > to communicate the type of device affected by the interrupt. This > > > > way, we can support up to 32 events with a unique interrupt. > > > > > > > > This supports only memory hotplug for now. > > > > > > > > Signed-off-by: Samuel Ortiz <sa...@linux.intel.com> > > > > Signed-off-by: Sebastien Boeuf <sebastien.bo...@intel.com> > > > > Signed-off-by: Shameer Kolothum <shameerali.kolothum.th...@huawei.com> > > > > > > Apologies if this question has been raised before, but do we really > > > need a separate device for this? We already handle the power button > > > via _AEI/_Exx on the GPIO device, and I think we should be able to add > > > additional events using that interface, rather than have two event > > > signalling methods/devices on the same platform. > > > > Right. The initial RFC was based on GPIO device[1] and later Igor commented > > here[2] that, > > > > " ARM boards were first to use ACPI hw-reduced profile so they picked up > > available back then GPIO based way to deliver hotplug event, later spec > > introduced Generic Event Device for that means to use with hw-reduced > > profile, which NEMU implemented[1], so I'd use that rather than ad-hoc > > GPIO mapping. I'd guess it will more compatible with various contemporary > > guests and we could reuse the same code for both x86/arm virt boards) " > > > > On mach-virt, we already use the GPIO controller for the ACPI event > involving the power button, so by aligning with virt-x86, we end up in > the opposite situation for mach-virt. > > The problem with the GED device is that it only supports GSI > interrupts, while the GPIO device supports arbitrary interrupts (such > as GPIO signalled ones). This means that mach-virt will be stuck with > having two different methods of signalling ACPI events, unless we > rewire the power button not to use a GPIO interrupt but use a GSI > directly. we can rewire power button then. > In general, I think the ACPI event delivery mechanism doesn't really > have to be aligned: the ACPI event is ultimately converted into a AML > notification to the right device, and how we end up there can remain > platform specific. Reasoning for using GED is to reduce code duplication with x86 and not creating zoo of different approached (if it could be avoided).
