[RFC part1 PATCH 0/7] Make ACPI core running on ARM64

[RFC part1 PATCH 0/7] Make ACPI core running on ARM64

[Hanjun Guo]

This is the first part of making ACPI core running on ARM.

PCI is optional on ARM64 but ACPI is dependent on PCI now, so
in the first patch we try to make ACPI can be running without
PCI.

_PDC is requred for ACPI processor_core.c, but its related code
is a little bit x86/ia64 dependent, so I rework _PDC related staff
to make it more arch independent, and then introduce the skeleton
of _PDC related for ARM64, it should be fully implemented after
ACPI spec is ready for processor idle control.

After that, arm-core.c is introduced so we can get ACPI table from
UEFI, then we can parsed for SMP initialisation, GIC initialisation
and for ACPI drivers.

This patch set is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git

origin/linux-next branch and plus Al Stone's v2 reduced hardware profile
patch.

Hanjun Guo (7):
  ACPI: Make ACPI core running without PCI on ARM64
  ARM64 : Add dummy asm/cpu.h
  ACPI / processor_core: Rework _PDC related stuff to make it more
    arch-independent
  ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64
  ARM64 / ACPI: Introduce arm_core.c and its related head file
  ARM64 / ACPI: Introduce lowlevel suspend function
  ARM64 / ACPI: Enable ARM64 in Kconfig

 arch/arm64/Kconfig                 |    2 +
 arch/arm64/include/asm/acpi.h      |   93 +++++++++++++++
 arch/arm64/include/asm/cpu.h       |   25 ++++
 arch/arm64/include/asm/processor.h |   11 ++
 arch/arm64/kernel/process.c        |    5 +
 arch/arm64/kernel/setup.c          |    8 ++
 drivers/acpi/Kconfig               |   12 +-
 drivers/acpi/Makefile              |    4 +-
 drivers/acpi/internal.h            |    5 +
 drivers/acpi/osl.c                 |   16 +++
 drivers/acpi/plat/Makefile         |    1 +
 drivers/acpi/plat/arm-core.c       |  226 ++++++++++++++++++++++++++++++++++++
 drivers/acpi/processor_core.c      |   27 ++---
 drivers/acpi/reboot.c              |   47 +++++---
 drivers/pnp/pnpacpi/rsparser.c     |    2 +
 15 files changed, 452 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm64/include/asm/acpi.h
 create mode 100644 arch/arm64/include/asm/cpu.h
 create mode 100644 drivers/acpi/plat/Makefile
 create mode 100644 drivers/acpi/plat/arm-core.c

-- 
1.7.9.5

[RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Hanjun Guo]

Not all the ARM64 targets that are using ACPI have PCI, so introduce
some stub functions to make ACPI core run without CONFIG_PCI on ARM64.

Since ACPI on X86 and IA64 depends on PCI, it will not break X86 and
IA64 with this patch.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 drivers/acpi/Makefile          |    2 +-
 drivers/acpi/internal.h        |    5 +++++
 drivers/acpi/osl.c             |   16 ++++++++++++++
 drivers/acpi/reboot.c          |   47 +++++++++++++++++++++++++++++-----------
 drivers/pnp/pnpacpi/rsparser.c |    2 ++
 5 files changed, 58 insertions(+), 14 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..d8cebe3 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -38,7 +38,7 @@ acpi-y				+= acpi_processor.o
 acpi-y				+= processor_core.o
 acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
-acpi-y				+= pci_root.o pci_link.o pci_irq.o
+acpi-$(CONFIG_PCI)		+= pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)	+= acpi_lpss.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= power.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index b125fdb..b1ef8fa 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -26,8 +26,13 @@
 acpi_status acpi_os_initialize1(void);
 int init_acpi_device_notify(void);
 int acpi_scan_init(void);
+#ifdef CONFIG_PCI
 void acpi_pci_root_init(void);
 void acpi_pci_link_init(void);
+#else
+static inline void acpi_pci_root_init(void) {}
+static inline void acpi_pci_link_init(void) {}
+#endif /* CONFIG_PCI */
 void acpi_processor_init(void);
 void acpi_platform_init(void);
 int acpi_sysfs_init(void);
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index c543626..6434045 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1016,6 +1016,7 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u64 value, u32 width)
 	return AE_OK;
 }
 
+#ifdef CONFIG_PCI
 acpi_status
 acpi_os_read_pci_configuration(struct acpi_pci_id * pci_id, u32 reg,
 			       u64 *value, u32 width)
@@ -1074,6 +1075,21 @@ acpi_os_write_pci_configuration(struct acpi_pci_id * pci_id, u32 reg,
 
 	return (result ? AE_ERROR : AE_OK);
 }
+#else
+acpi_status
+acpi_os_read_pci_configuration(struct acpi_pci_id *pci_id, u32 reg,
+				u64 *value, u32 width)
+{
+	return AE_ERROR;
+}
+
+acpi_status
+acpi_os_write_pci_configuration(struct acpi_pci_id *pci_id, u32 reg,
+				u64 value, u32 width)
+{
+	return AE_ERROR;
+}
+#endif /* CONFIG_PCI */
 
 static void acpi_os_execute_deferred(struct work_struct *work)
 {
diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
index a6c77e8b..89a181f 100644
--- a/drivers/acpi/reboot.c
+++ b/drivers/acpi/reboot.c
@@ -3,12 +3,43 @@
 #include <linux/acpi.h>
 #include <acpi/reboot.h>
 
+/*
+ * There are some rare cases in the ARM world with PCI is not one
+ * of the buses available to us, even though we use ACPI.
+ */
+#ifdef CONFIG_PCI
+static void acpi_reset_with_writing_pci_config(u64 address, u8 reset_value)
+{
+	struct pci_bus *bus0;
+	unsigned int devfn;
+
+	/* The reset register can only live on bus 0. */
+	bus0 = pci_find_bus(0, 0);
+	if (!bus0)
+		return;
+
+	/* Form PCI device/function pair. */
+	devfn = PCI_DEVFN((address >> 32) & 0xffff,
+			(address >> 16) & 0xffff);
+	pr_debug("Resetting with ACPI PCI RESET_REG.\n");
+	/* Write the value that resets us. */
+	pci_bus_write_config_byte(bus0, devfn,
+			(address & 0xffff), reset_value);
+
+	return;
+}
+#else
+static void acpi_reset_with_writing_pci_config(u64 address, u8 reset_value)
+{
+	pr_warn("Resetting with ACPI PCI RESET_REG failed, PCI is disabled\n");
+	return;
+}
+#endif
+
 void acpi_reboot(void)
 {
 	struct acpi_generic_address *rr;
-	struct pci_bus *bus0;
 	u8 reset_value;
-	unsigned int devfn;
 
 	if (acpi_disabled)
 		return;
@@ -32,17 +63,7 @@ void acpi_reboot(void)
 	 * on a device on bus 0. */
 	switch (rr->space_id) {
 	case ACPI_ADR_SPACE_PCI_CONFIG:
-		/* The reset register can only live on bus 0. */
-		bus0 = pci_find_bus(0, 0);
-		if (!bus0)
-			return;
-		/* Form PCI device/function pair. */
-		devfn = PCI_DEVFN((rr->address >> 32) & 0xffff,
-				  (rr->address >> 16) & 0xffff);
-		printk(KERN_DEBUG "Resetting with ACPI PCI RESET_REG.");
-		/* Write the value that resets us. */
-		pci_bus_write_config_byte(bus0, devfn,
-				(rr->address & 0xffff), reset_value);
+		acpi_reset_with_writing_pci_config(rr->address, reset_value);
 		break;
 
 	case ACPI_ADR_SPACE_SYSTEM_MEMORY:
diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
index 167f3d0..5804e77 100644
--- a/drivers/pnp/pnpacpi/rsparser.c
+++ b/drivers/pnp/pnpacpi/rsparser.c
@@ -113,8 +113,10 @@ static int dma_flags(struct pnp_dev *dev, int type, int bus_master,
 
 static void pnpacpi_add_irqresource(struct pnp_dev *dev, struct resource *r)
 {
+#ifdef CONFIG_PCI
 	if (!(r->flags & IORESOURCE_DISABLED))
 		pcibios_penalize_isa_irq(r->start, 1);
+#endif
 
 	pnp_add_resource(dev, r);
 }
-- 
1.7.9.5

[RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Matthew Garrett]

Given the number of #ifdefs you're adding, wouldn't it make more sense 
to just add stub functions to include/linux/pci.h?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Hanjun Guo]

On 2013?12?04? 00:41, Matthew Garrett wrote:
> Given the number of #ifdefs you're adding, wouldn't it make more sense
> to just add stub functions to include/linux/pci.h?

Thanks for the suggestion :)

I can add stub functions in include/linux/pci.h for raw_pci_read()/
raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration().

Thanks
Hanjun

>

[RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Arnd Bergmann]

On Wednesday 04 December 2013, Hanjun Guo wrote:
> On 2013?12?04? 00:41, Matthew Garrett wrote:
> > Given the number of #ifdefs you're adding, wouldn't it make more sense
> > to just add stub functions to include/linux/pci.h?
> 
> Thanks for the suggestion :)
> 
> I can add stub functions in include/linux/pci.h for raw_pci_read()/
> raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration().

Actually I wonder about the usefulness of this patch in either form: Since ACPI
on ARM64 is only for servers, I would very much expect them to always come with
PCI, either physical host bridges with attached devices, or logical PCI functions
used to describe the on-SoC I/O devices. Even in case of virtual machines, you'd
normally use PCI as the method to communicate data about the virtio channels.

Can you name a realistic use-case where you'd want ACPI but not PCI?

	Arnd

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Tomasz Nowicki]

On 05.12.2013 23:04, Arnd Bergmann wrote:
> On Wednesday 04 December 2013, Hanjun Guo wrote:
>> On 2013?12?04? 00:41, Matthew Garrett wrote:
>>> Given the number of #ifdefs you're adding, wouldn't it make more sense
>>> to just add stub functions to include/linux/pci.h?
>>
>> Thanks for the suggestion :)
>>
>> I can add stub functions in include/linux/pci.h for raw_pci_read()/
>> raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration().
>
> Actually I wonder about the usefulness of this patch in either form: Since ACPI
> on ARM64 is only for servers, I would very much expect them to always come with
> PCI, either physical host bridges with attached devices, or logical PCI functions
> used to describe the on-SoC I/O devices. Even in case of virtual machines, you'd
> normally use PCI as the method to communicate data about the virtio channels.
>
> Can you name a realistic use-case where you'd want ACPI but not PCI?

Yes you can describe SoC I/O devices using logical PCI functions only if 
they are on PCI, correct me if I am wrong. Also, devices can be placed 
only on IOMEM (like for ARM SoC) and it is hard to predict which way 
vendors chose. So way don't let it be configurable? ACPI spec says 
nothing like PCI is needed for ACPI, AFAIK.

Tomasz

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Arnd Bergmann]

On Friday 06 December 2013, Tomasz Nowicki wrote:
> On 05.12.2013 23:04, Arnd Bergmann wrote:
> > On Wednesday 04 December 2013, Hanjun Guo wrote:
> >> On 2013?12?04? 00:41, Matthew Garrett wrote:
> >>> Given the number of #ifdefs you're adding, wouldn't it make more sense
> >>> to just add stub functions to include/linux/pci.h?
> >>
> >> Thanks for the suggestion :)
> >>
> >> I can add stub functions in include/linux/pci.h for raw_pci_read()/
> >> raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration().
> >
> > Actually I wonder about the usefulness of this patch in either form: Since ACPI
> > on ARM64 is only for servers, I would very much expect them to always come with
> > PCI, either physical host bridges with attached devices, or logical PCI functions
> > used to describe the on-SoC I/O devices. Even in case of virtual machines, you'd
> > normally use PCI as the method to communicate data about the virtio channels.
> >
> > Can you name a realistic use-case where you'd want ACPI but not PCI?
> 
> Yes you can describe SoC I/O devices using logical PCI functions only if 
> they are on PCI, correct me if I am wrong. Also, devices can be placed 
> only on IOMEM (like for ARM SoC) and it is hard to predict which way 
> vendors chose. So way don't let it be configurable? ACPI spec says 
> nothing like PCI is needed for ACPI, AFAIK.

You are right that today's ARM SoCs basically never use PCI to describe
internal devices (IIRC VIA VT8500 is an exception, but their PCI was
just a software fabrication).

However, when we're talking about ACPI on ARM64, that is nothing like classic
ARM SoCs: As Jon Masters mentioned, this is about new server hardware following
a (still secret, but hopefully not much longer) hardware specification that is
explicitly designed to allow interoperability between vendors, so they
must have put some thought into how to make the hardware discoverable. It
seems that they are modeling things after how it's done on x86, and the
only sensible way to have discoverable hardware there is PCI. This is
also what all x86 SoCs do.

	Arnd

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Hanjun Guo]

On 2013-12-7 1:23, Arnd Bergmann wrote:
> On Friday 06 December 2013, Tomasz Nowicki wrote:
>> On 05.12.2013 23:04, Arnd Bergmann wrote:
>>> On Wednesday 04 December 2013, Hanjun Guo wrote:
>>>> On 2013?12?04? 00:41, Matthew Garrett wrote:
>>>>> Given the number of #ifdefs you're adding, wouldn't it make more sense
>>>>> to just add stub functions to include/linux/pci.h?
>>>>
>>>> Thanks for the suggestion :)
>>>>
>>>> I can add stub functions in include/linux/pci.h for raw_pci_read()/
>>>> raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration().
>>>
>>> Actually I wonder about the usefulness of this patch in either form: Since ACPI
>>> on ARM64 is only for servers, I would very much expect them to always come with
>>> PCI, either physical host bridges with attached devices, or logical PCI functions
>>> used to describe the on-SoC I/O devices. Even in case of virtual machines, you'd
>>> normally use PCI as the method to communicate data about the virtio channels.
>>>
>>> Can you name a realistic use-case where you'd want ACPI but not PCI?
>>
>> Yes you can describe SoC I/O devices using logical PCI functions only if 
>> they are on PCI, correct me if I am wrong. Also, devices can be placed 
>> only on IOMEM (like for ARM SoC) and it is hard to predict which way 
>> vendors chose. So way don't let it be configurable? ACPI spec says 
>> nothing like PCI is needed for ACPI, AFAIK.
> 
> You are right that today's ARM SoCs basically never use PCI to describe
> internal devices (IIRC VIA VT8500 is an exception, but their PCI was
> just a software fabrication).
> 
> However, when we're talking about ACPI on ARM64, that is nothing like classic
> ARM SoCs: As Jon Masters mentioned, this is about new server hardware following
> a (still secret, but hopefully not much longer) hardware specification that is
> explicitly designed to allow interoperability between vendors, so they
> must have put some thought into how to make the hardware discoverable. It
> seems that they are modeling things after how it's done on x86, and the
> only sensible way to have discoverable hardware there is PCI. This is
> also what all x86 SoCs do.

I think the concern here is that ACPI is only for server platform or not.

Since ACPI has lots of content related to power management, I think ACPI
can be used for mobile devices and other platform too, not only for ARM
servers, and with this patch, we can support both requirement.

Thanks
Hanjun

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Catalin Marinas]

On Mon, Dec 09, 2013 at 04:12:24AM +0000, Hanjun Guo wrote:
> On 2013-12-7 1:23, Arnd Bergmann wrote:
> > On Friday 06 December 2013, Tomasz Nowicki wrote:
> >> On 05.12.2013 23:04, Arnd Bergmann wrote:
> >>> On Wednesday 04 December 2013, Hanjun Guo wrote:
> >>>> On 2013?12?04? 00:41, Matthew Garrett wrote:
> >>>>> Given the number of #ifdefs you're adding, wouldn't it make more sense
> >>>>> to just add stub functions to include/linux/pci.h?
> >>>>
> >>>> Thanks for the suggestion :)
> >>>>
> >>>> I can add stub functions in include/linux/pci.h for raw_pci_read()/
> >>>> raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration().
> >>>
> >>> Actually I wonder about the usefulness of this patch in either form: Since ACPI
> >>> on ARM64 is only for servers, I would very much expect them to always come with
> >>> PCI, either physical host bridges with attached devices, or logical PCI functions
> >>> used to describe the on-SoC I/O devices. Even in case of virtual machines, you'd
> >>> normally use PCI as the method to communicate data about the virtio channels.
> >>>
> >>> Can you name a realistic use-case where you'd want ACPI but not PCI?
> >>
> >> Yes you can describe SoC I/O devices using logical PCI functions only if 
> >> they are on PCI, correct me if I am wrong. Also, devices can be placed 
> >> only on IOMEM (like for ARM SoC) and it is hard to predict which way 
> >> vendors chose. So way don't let it be configurable? ACPI spec says 
> >> nothing like PCI is needed for ACPI, AFAIK.
> > 
> > You are right that today's ARM SoCs basically never use PCI to describe
> > internal devices (IIRC VIA VT8500 is an exception, but their PCI was
> > just a software fabrication).
> > 
> > However, when we're talking about ACPI on ARM64, that is nothing like classic
> > ARM SoCs: As Jon Masters mentioned, this is about new server hardware following
> > a (still secret, but hopefully not much longer) hardware specification that is
> > explicitly designed to allow interoperability between vendors, so they
> > must have put some thought into how to make the hardware discoverable. It
> > seems that they are modeling things after how it's done on x86, and the
> > only sensible way to have discoverable hardware there is PCI. This is
> > also what all x86 SoCs do.
> 
> I think the concern here is that ACPI is only for server platform or not.
> 
> Since ACPI has lots of content related to power management, I think ACPI
> can be used for mobile devices and other platform too, not only for ARM
> servers, and with this patch, we can support both requirement.

'Can be used' is one thing, will it really be used is another? I don't
think so, it was (well, is) difficult enough to make the transition to
FDT, I don't see how ACPI would solve the current issues.

I see ACPI as a server distro requirement and there are indeed benefits
in abstracting the hardware behind standard description, AML. Of course,
this would work even better with probe-able buses like PCIe and I'm
pretty sure this would be the case on high-end servers. But even if a
server distro like RHEL supports a SoC without PCIe, I would expect them
to only provide a single binary Image with CONFIG_PCI enabled.

This patch is small enough and allows ACPI build with !CONFIG_PCI for
the time being but longer term I would expect such SoCs without PCI to
be able to run on a kernel with CONFIG_PCI enabled.

-- 
Catalin

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Hanjun Guo]

On 2013-12-9 19:50, Catalin Marinas wrote:
> On Mon, Dec 09, 2013 at 04:12:24AM +0000, Hanjun Guo wrote:
>> On 2013-12-7 1:23, Arnd Bergmann wrote:
>>> On Friday 06 December 2013, Tomasz Nowicki wrote:
>>>> On 05.12.2013 23:04, Arnd Bergmann wrote:
>>>>> On Wednesday 04 December 2013, Hanjun Guo wrote:
>>>>>> On 2013?12?04? 00:41, Matthew Garrett wrote:
>>>>>>> Given the number of #ifdefs you're adding, wouldn't it make more sense
>>>>>>> to just add stub functions to include/linux/pci.h?
>>>>>>
>>>>>> Thanks for the suggestion :)
>>>>>>
>>>>>> I can add stub functions in include/linux/pci.h for raw_pci_read()/
>>>>>> raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration().
>>>>>
>>>>> Actually I wonder about the usefulness of this patch in either form: Since ACPI
>>>>> on ARM64 is only for servers, I would very much expect them to always come with
>>>>> PCI, either physical host bridges with attached devices, or logical PCI functions
>>>>> used to describe the on-SoC I/O devices. Even in case of virtual machines, you'd
>>>>> normally use PCI as the method to communicate data about the virtio channels.
>>>>>
>>>>> Can you name a realistic use-case where you'd want ACPI but not PCI?
>>>>
>>>> Yes you can describe SoC I/O devices using logical PCI functions only if 
>>>> they are on PCI, correct me if I am wrong. Also, devices can be placed 
>>>> only on IOMEM (like for ARM SoC) and it is hard to predict which way 
>>>> vendors chose. So way don't let it be configurable? ACPI spec says 
>>>> nothing like PCI is needed for ACPI, AFAIK.
>>>
>>> You are right that today's ARM SoCs basically never use PCI to describe
>>> internal devices (IIRC VIA VT8500 is an exception, but their PCI was
>>> just a software fabrication).
>>>
>>> However, when we're talking about ACPI on ARM64, that is nothing like classic
>>> ARM SoCs: As Jon Masters mentioned, this is about new server hardware following
>>> a (still secret, but hopefully not much longer) hardware specification that is
>>> explicitly designed to allow interoperability between vendors, so they
>>> must have put some thought into how to make the hardware discoverable. It
>>> seems that they are modeling things after how it's done on x86, and the
>>> only sensible way to have discoverable hardware there is PCI. This is
>>> also what all x86 SoCs do.
>>
>> I think the concern here is that ACPI is only for server platform or not.
>>
>> Since ACPI has lots of content related to power management, I think ACPI
>> can be used for mobile devices and other platform too, not only for ARM
>> servers, and with this patch, we can support both requirement.
> 
> 'Can be used' is one thing, will it really be used is another? I don't
> think so, it was (well, is) difficult enough to make the transition to
> FDT, I don't see how ACPI would solve the current issues.
> 
> I see ACPI as a server distro requirement and there are indeed benefits
> in abstracting the hardware behind standard description, AML. Of course,
> this would work even better with probe-able buses like PCIe and I'm
> pretty sure this would be the case on high-end servers. But even if a
> server distro like RHEL supports a SoC without PCIe, I would expect them
> to only provide a single binary Image with CONFIG_PCI enabled.
> 
> This patch is small enough and allows ACPI build with !CONFIG_PCI for
> the time being but longer term I would expect such SoCs without PCI to
> be able to run on a kernel with CONFIG_PCI enabled.

Yes, we will support PCI in ACPI in the long run, and we just make PCI
optional for ACPI in this patch.

Actually, I had reworked this patch and make the code with minimal
changes to ACPI code:


Not all the ARM64 targets that are using ACPI have PCI, so introduce
some stub functions to make ACPI core run without CONFIG_PCI on ARM64.

pcibios_penalize_isa_irq() is arch dependent, introduce asm/pci.h to
include it.

Since ACPI on X86 and IA64 depends on PCI, it will not break X86 and
IA64 with this patch.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/pci.h |   13 +++++++++++++
 drivers/acpi/Makefile        |    2 +-
 drivers/acpi/internal.h      |    5 +++++
 include/linux/pci.h          |   32 +++++++++++++++++++++++---------
 4 files changed, 42 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm64/include/asm/pci.h

diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
new file mode 100644
index 0000000..e682c25
--- /dev/null
+++ b/arch/arm64/include/asm/pci.h
@@ -0,0 +1,13 @@
+#ifndef ASMARM_PCI_H
+#define ASMARM_PCI_H
+
+#ifdef __KERNEL__
+
+static inline void pcibios_penalize_isa_irq(int irq, int active)
+{
+	/* We don't do dynamic PCI IRQ allocation */
+}
+
+#endif /* __KERNEL__ */
+
+#endif
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..d8cebe3 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -38,7 +38,7 @@ acpi-y				+= acpi_processor.o
 acpi-y				+= processor_core.o
 acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
-acpi-y				+= pci_root.o pci_link.o pci_irq.o
+acpi-$(CONFIG_PCI)		+= pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)	+= acpi_lpss.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= power.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index b125fdb..b1ef8fa 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -26,8 +26,13 @@
 acpi_status acpi_os_initialize1(void);
 int init_acpi_device_notify(void);
 int acpi_scan_init(void);
+#ifdef CONFIG_PCI
 void acpi_pci_root_init(void);
 void acpi_pci_link_init(void);
+#else
+static inline void acpi_pci_root_init(void) {}
+static inline void acpi_pci_link_init(void) {}
+#endif /* CONFIG_PCI */
 void acpi_processor_init(void);
 void acpi_platform_init(void);
 int acpi_sysfs_init(void);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1084a15..28334dd 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -541,15 +541,6 @@ struct pci_ops {
 	int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
 };

-/*
- * ACPI needs to be able to access PCI config space before we've done a
- * PCI bus scan and created pci_bus structures.
- */
-int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
-		 int reg, int len, u32 *val);
-int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
-		  int reg, int len, u32 val);
-
 struct pci_bus_region {
 	resource_size_t start;
 	resource_size_t end;
@@ -1280,6 +1271,15 @@ typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
 		      unsigned int command_bits, u32 flags);
 void pci_register_set_vga_state(arch_set_vga_state_t func);

+/*
+ * ACPI needs to be able to access PCI config space before we've done a
+ * PCI bus scan and created pci_bus structures.
+ */
+int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
+		 int reg, int len, u32 *val);
+int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
+		  int reg, int len, u32 val);
+
 #else /* CONFIG_PCI is not enabled */

 /*
@@ -1476,6 +1476,20 @@ static inline int pci_domain_nr(struct pci_bus *bus)
 static inline struct pci_dev *pci_dev_get(struct pci_dev *dev)
 { return NULL; }

+static inline struct pci_bus *pci_find_bus(int domain, int busnr)
+{ return NULL; }
+
+static inline int pci_bus_write_config_byte(struct pci_bus *bus,
+			unsigned int devfn, int where, u8 val);
+{ return -ENODEV; }
+
+static inline int raw_pci_read(unsigned int domain, unsigned int bus,
+		unsigned int devfn, int reg, int len, u32 *val);
+{ return -EINVAL; }
+static inline int raw_pci_write(unsigned int domain, unsigned int bus,
+		unsigned int devfn, int reg, int len, u32 val);
+{return -EINVAL; }
+
 #define dev_is_pci(d) (false)
 #define dev_is_pf(d) (false)
 #define dev_num_vf(d) (0)

--
Hanjun

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Arnd Bergmann]

On Monday 09 December 2013, Hanjun Guo wrote:
> On 2013-12-9 19:50, Catalin Marinas wrote:
> > On Mon, Dec 09, 2013 at 04:12:24AM +0000, Hanjun Guo wrote:
> >>
> >> I think the concern here is that ACPI is only for server platform or not.
> >>
> >> Since ACPI has lots of content related to power management, I think ACPI
> >> can be used for mobile devices and other platform too, not only for ARM
> >> servers, and with this patch, we can support both requirement.
> > 
> > 'Can be used' is one thing, will it really be used is another? I don't
> > think so, it was (well, is) difficult enough to make the transition to
> > FDT, I don't see how ACPI would solve the current issues.

Exactly. In particular we don't want people to get the wrong idea about
where we are heading, so making it possible to use this code on embedded
systems for me is a reason *not* to take the patch.

> > I see ACPI as a server distro requirement and there are indeed benefits
> > in abstracting the hardware behind standard description, AML. Of course,
> > this would work even better with probe-able buses like PCIe and I'm
> > pretty sure this would be the case on high-end servers. But even if a
> > server distro like RHEL supports a SoC without PCIe, I would expect them
> > to only provide a single binary Image with CONFIG_PCI enabled.
> > 
> > This patch is small enough and allows ACPI build with !CONFIG_PCI for
> > the time being but longer term I would expect such SoCs without PCI to
> > be able to run on a kernel with CONFIG_PCI enabled.
> 
> Yes, we will support PCI in ACPI in the long run, and we just make PCI
> optional for ACPI in this patch.

Do you mean there is a problem running your code with PCI /enabled/ at the
moment? If so, I'd suggest fixing that instead since you will have to fix
it anyway.

	Arnd

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Catalin Marinas]

On Mon, Dec 09, 2013 at 04:35:04PM +0000, Arnd Bergmann wrote:
> On Monday 09 December 2013, Hanjun Guo wrote:
> > On 2013-12-9 19:50, Catalin Marinas wrote:
> > > On Mon, Dec 09, 2013 at 04:12:24AM +0000, Hanjun Guo wrote:
> > >>
> > >> I think the concern here is that ACPI is only for server platform or not.
> > >>
> > >> Since ACPI has lots of content related to power management, I think ACPI
> > >> can be used for mobile devices and other platform too, not only for ARM
> > >> servers, and with this patch, we can support both requirement.
> > > 
> > > 'Can be used' is one thing, will it really be used is another? I don't
> > > think so, it was (well, is) difficult enough to make the transition to
> > > FDT, I don't see how ACPI would solve the current issues.
> 
> Exactly. In particular we don't want people to get the wrong idea about
> where we are heading, so making it possible to use this code on embedded
> systems for me is a reason *not* to take the patch.

I agree.

> > > I see ACPI as a server distro requirement and there are indeed benefits
> > > in abstracting the hardware behind standard description, AML. Of course,
> > > this would work even better with probe-able buses like PCIe and I'm
> > > pretty sure this would be the case on high-end servers. But even if a
> > > server distro like RHEL supports a SoC without PCIe, I would expect them
> > > to only provide a single binary Image with CONFIG_PCI enabled.
> > > 
> > > This patch is small enough and allows ACPI build with !CONFIG_PCI for
> > > the time being but longer term I would expect such SoCs without PCI to
> > > be able to run on a kernel with CONFIG_PCI enabled.
> > 
> > Yes, we will support PCI in ACPI in the long run, and we just make PCI
> > optional for ACPI in this patch.
> 
> Do you mean there is a problem running your code with PCI /enabled/ at the
> moment? If so, I'd suggest fixing that instead since you will have to fix
> it anyway.

CONFIG_PCI does not exist on arm64 yet (we have some internal patches
but may not be ready to be posted before the holidays; they try to share
code with other archs, so more discussions before merging). We could add
CONFIG_PCI and some dummy functions on arm64 for development (not to be
upstreamed) or Hanjun could continue to use the current patch before we
get PCI working. In the order of priorities, we'll have to merge PCI
before ACPI anyway.

-- 
Catalin

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Arnd Bergmann]

On Monday 09 December 2013, Catalin Marinas wrote:
> CONFIG_PCI does not exist on arm64 yet (we have some internal patches
> but may not be ready to be posted before the holidays; they try to share
> code with other archs, so more discussions before merging). We could add
> CONFIG_PCI and some dummy functions on arm64 for development (not to be
> upstreamed) or Hanjun could continue to use the current patch before we
> get PCI working. In the order of priorities, we'll have to merge PCI
> before ACPI anyway.

Well, lack of PCI support on ARM64 is a much better reason for accepting
the patch than potential use on non-server platforms of course.

What is the status of the PCI work though? I suspect it won't be all
that hard to add minimal PCI support for a simple mmconfig plus
fixed I/O space based host of the kind that qemu can easily provide.

The hard part that we want to share code with other architectures is
supporting pluggable host controllers, and I think we can defer that
a bit.

	Arnd

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Catalin Marinas]

On Mon, Dec 09, 2013 at 05:20:22PM +0000, Arnd Bergmann wrote:
> On Monday 09 December 2013, Catalin Marinas wrote:
> > CONFIG_PCI does not exist on arm64 yet (we have some internal patches
> > but may not be ready to be posted before the holidays; they try to share
> > code with other archs, so more discussions before merging). We could add
> > CONFIG_PCI and some dummy functions on arm64 for development (not to be
> > upstreamed) or Hanjun could continue to use the current patch before we
> > get PCI working. In the order of priorities, we'll have to merge PCI
> > before ACPI anyway.
> 
> Well, lack of PCI support on ARM64 is a much better reason for accepting
> the patch than potential use on non-server platforms of course.

As I said above about priorities, we are not in a hurry to merge ACPI
for arm64 before PCI is supported.

> What is the status of the PCI work though? I suspect it won't be all
> that hard to add minimal PCI support for a simple mmconfig plus
> fixed I/O space based host of the kind that qemu can easily provide.

Liviu (ARM engineer) has been working on generalising the microblaze
code (which is very similar to powerpc) and enable it on arm64. The
patches will be posted soon (though may slip into the new year) but
there will be many discussions on how to do this best, so I don't expect
a quick merge.

In parallel, Will is looking at getting PCI to work with kvmtool and
that's something we could merge sooner (but again, in the new year).

> The hard part that we want to share code with other architectures is
> supporting pluggable host controllers, and I think we can defer that
> a bit.

Indeed, this would take time.

-- 
Catalin

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Graeme Gregory]

On Mon, Dec 09, 2013 at 06:01:55PM +0000, Catalin Marinas wrote:
> On Mon, Dec 09, 2013 at 05:20:22PM +0000, Arnd Bergmann wrote:
> > On Monday 09 December 2013, Catalin Marinas wrote:
> > > CONFIG_PCI does not exist on arm64 yet (we have some internal patches
> > > but may not be ready to be posted before the holidays; they try to share
> > > code with other archs, so more discussions before merging). We could add
> > > CONFIG_PCI and some dummy functions on arm64 for development (not to be
> > > upstreamed) or Hanjun could continue to use the current patch before we
> > > get PCI working. In the order of priorities, we'll have to merge PCI
> > > before ACPI anyway.
> > 
> > Well, lack of PCI support on ARM64 is a much better reason for accepting
> > the patch than potential use on non-server platforms of course.
> 
> As I said above about priorities, we are not in a hurry to merge ACPI
> for arm64 before PCI is supported.
> 
> > What is the status of the PCI work though? I suspect it won't be all
> > that hard to add minimal PCI support for a simple mmconfig plus
> > fixed I/O space based host of the kind that qemu can easily provide.
> 
> Liviu (ARM engineer) has been working on generalising the microblaze
> code (which is very similar to powerpc) and enable it on arm64. The
> patches will be posted soon (though may slip into the new year) but
> there will be many discussions on how to do this best, so I don't expect
> a quick merge.
> 
> In parallel, Will is looking at getting PCI to work with kvmtool and
> that's something we could merge sooner (but again, in the new year).
> 
> > The hard part that we want to share code with other architectures is
> > supporting pluggable host controllers, and I think we can defer that
> > a bit.
> 
> Indeed, this would take time.
> 
Hi Catalin,

So the real question now is how do we progress with these ACPI patches? After
repeated incorrect accusations of developing behind closed doors I am loath
to dissapear back into linaro with them for another few months.

Also as Mark Brown has already pointed out the bigger the patchset gets
while developed in Linaro trees the more strain it is going to put on
maintainers for review.

We have worked to try and keep the patchset as self contained as possible
and to affect arch/arm64 in a minimal way. It should not affect it at all
in the !CONFIG_ACPI case.

Currently Hanjun is busy preparing a v2 PATCH series which contains amendments
for all the technical issues found in review so far. Should we continue with
this process until all the neccessary Acks are in place?

Graeme

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Catalin Marinas]

Hi Graeme,

On Mon, Dec 16, 2013 at 08:51:33PM +0000, Graeme Gregory wrote:
> So the real question now is how do we progress with these ACPI patches? After
> repeated incorrect accusations of developing behind closed doors I am loath
> to dissapear back into linaro with them for another few months.

Well, just follow the Linux community process, no need to disappear
back. There was feedback that needs to be addressed, work on getting
acks from maintainers. The first version has only been posted two weeks
ago, I don't see any reason to panic ;).

> Also as Mark Brown has already pointed out the bigger the patchset gets
> while developed in Linaro trees the more strain it is going to put on
> maintainers for review.

Yes, that's correct, so just gather maintainer's acks in smaller steps.

> We have worked to try and keep the patchset as self contained as possible
> and to affect arch/arm64 in a minimal way. It should not affect it at all
> in the !CONFIG_ACPI case.

And this is great, I really don't have any complaints here.

> Currently Hanjun is busy preparing a v2 PATCH series which contains amendments
> for all the technical issues found in review so far. Should we continue with
> this process until all the neccessary Acks are in place?

Reviews/acks is the first step and you are on the right track here. The
following step would be upstreaming with good arguments on why and when
the code needs to be merged. Code quality on its own is not an argument
for merging. Backlog in Linaro's trees is not an argument either. You
could of course start upstreaming clean-up code that is necessary
whether you have ACPI on arm64 or not.

So while waiting to debate the good arguments for when to merge the code
(once reviewed), I have several concerns which I want addressed before
enabling ACPI for arm64:

- Does anyone have a wider view of how ACPI on ARM looks like? There is
  a lot of effort going into the next version of ACPI but for now I
  don't see how we can enable a feature and hope we sort it out later.
- Who is coordinating the non-standard ACPI descriptors being pushed to
  various drivers in the kernel? Do we trust the hw vendors to do the
  right thing (and also talk to each other)?
- What if two hw vendors have different descriptors for the same device?
- Have we agreed what we do about clocks, voltage regulators?
- Do we actually have a real platform which requires ACPI at this point?

Just to be clear, I'm not against ACPI for arm64 and I am aware of
hardware vendors requiring this. But I'm looking forward to them being
more open and explain what (rather than why) they need because I don't
think ACPI solves anything for the ARM kernel community. It's rather a
favour we do to them and OS distros.

-- 
Catalin

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Graeme Gregory]

On Tue, Dec 17, 2013 at 11:29:14AM +0000, Catalin Marinas wrote:
> Hi Graeme,
> 
> On Mon, Dec 16, 2013 at 08:51:33PM +0000, Graeme Gregory wrote:
> > So the real question now is how do we progress with these ACPI patches? After
> > repeated incorrect accusations of developing behind closed doors I am loath
> > to dissapear back into linaro with them for another few months.
> 
> Well, just follow the Linux community process, no need to disappear
> back. There was feedback that needs to be addressed, work on getting
> acks from maintainers. The first version has only been posted two weeks
> ago, I don't see any reason to panic ;).
> 

Ok, thanks for that, we will continue to work on v2, v3, ... as normal then

> Reviews/acks is the first step and you are on the right track here. The
> following step would be upstreaming with good arguments on why and when
> the code needs to be merged. Code quality on its own is not an argument
> for merging. Backlog in Linaro's trees is not an argument either. You
> could of course start upstreaming clean-up code that is necessary
> whether you have ACPI on arm64 or not.
>

Yes coming out of the reviews some of the patches which we initially thought
were ARM64 work turned out to be general cleanups and they will go via
the appropriate channel.

> So while waiting to debate the good arguments for when to merge the code
> (once reviewed), I have several concerns which I want addressed before
> enabling ACPI for arm64:
> 
> - Does anyone have a wider view of how ACPI on ARM looks like? There is
>   a lot of effort going into the next version of ACPI but for now I
>   don't see how we can enable a feature and hope we sort it out later.
> - Who is coordinating the non-standard ACPI descriptors being pushed to
>   various drivers in the kernel? Do we trust the hw vendors to do the
>   right thing (and also talk to each other)?
> - What if two hw vendors have different descriptors for the same device?
> - Have we agreed what we do about clocks, voltage regulators?
> - Do we actually have a real platform which requires ACPI at this point?
> 
> Just to be clear, I'm not against ACPI for arm64 and I am aware of
> hardware vendors requiring this. But I'm looking forward to them being
> more open and explain what (rather than why) they need because I don't
> think ACPI solves anything for the ARM kernel community. It's rather a
> favour we do to them and OS distros.
> 

You have some good points here, obviously we are currently working on
preperation work based on the RTSM/FVP (whatever they are called next week)
models which currently are not a good representation of an armv8 server.

Hopefully the documenation of what real armv8 server architecture will look
like will come in the new year. Things like regulators and clocks I do not
have answers to yet as obviously in Intel world these things are hidden
from view, I do not know what the plan is for armv8 silicon/motherboards.

On the multiple venders same hardware issue I guess Intel guys must have
already seen this happen. We shall have to ask them what their solution was?

Graeme

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Arnd Bergmann]

On Thursday 19 December 2013, Graeme Gregory wrote:
> Hopefully the documenation of what real armv8 server architecture will look
> like will come in the new year. Things like regulators and clocks I do not
> have answers to yet as obviously in Intel world these things are hidden
> from view, I do not know what the plan is for armv8 silicon/motherboards.

The clocks and regulators (and a handful of other subsystems) are
the key thing to work out IMHO. For all I know these are either completely
static (turned on by firmware at boot time) on current servers, or they
are done in a way that each device can manage itself using power states
in the PCI configuration space. If you have on-chip devices that do not
look like PCI devices to software, or that interact with other on-chip
controllers at run-time as on typical arm32 embedded SoCs, you are in
trouble to start with, and there are two possible ways to deal with this
in theory:

a) Hide all the register-level setup behind AML code and make Linux only
   aware of the possible device states that it can ask for, which would
   make this look similar to today's servers.

b) Model all the soc-internal registers as devices and write OS-specific
   SoC-specific device drivers for them, using yet-to-be-defined ACPI
   extensions to describe the interactions between devices. This would
   be modeled along the lines of what we do today with DT, and what Intel
   wants to do on their embedded SoCs with ACPI in the future.

I think anybody would agree that we should not try to mix the two models
in a single system, as that would create an endless source of bugs when
you have two drivers fighting over the same hardware. There is also a
rough consensus that we really only want a) and not b) on ARM, but there
have been indications that people are already working on b), which I
think is a bit worrying. I would argue that anyone who wants b) on 
ARM should not use ACPI at all but rather describe the hardware using
DT as we do today. This could possibly change if someone shows that a)
is actually not a realistic model at all, but I also think that doing b)
properly will depend on doing a major ACPI-6.0 or ACPI-7.0 release
to actually specify a standard model for the extra subsystems.

> On the multiple venders same hardware issue I guess Intel guys must have
> already seen this happen. We shall have to ask them what their solution was?

There is basically only one SoC vendor on x86, which makes this a lot
easier. Off-chip devices on the board are typically PCI based and
don't need any special treatment because the PCI vendor/device ID
pair is enought to identify the hardware. Anything that does not fall
into these categories (e.g. vendor specific laptop extensions) is
handled with drivers in drivers/platform/x86/. This works fine
because that code is only needed for _optional_ features such as
multimedia buttons or sensors, and the total amount of code for
all the platforms is fairly contained.

The main concern for ARM is that if we need to do the same, it ends up
as a direct replacement for the "board files" that we just spent years
on making obsolete. We can do this as a workaround for the oddball broken
firmware in shipping products, but we should not go back to having to
add platform-specific code that is only meant to interface with how
a random vendor decided to expose standard hardware in their ACPI BIOS.

	Arnd

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Catalin Marinas]

On Thu, Dec 19, 2013 at 02:01:26PM +0000, Arnd Bergmann wrote:
> On Thursday 19 December 2013, Graeme Gregory wrote:
> > Hopefully the documenation of what real armv8 server architecture will look
> > like will come in the new year. Things like regulators and clocks I do not
> > have answers to yet as obviously in Intel world these things are hidden
> > from view, I do not know what the plan is for armv8 silicon/motherboards.
> 
> The clocks and regulators (and a handful of other subsystems) are
> the key thing to work out IMHO. For all I know these are either completely
> static (turned on by firmware at boot time) on current servers, or they
> are done in a way that each device can manage itself using power states
> in the PCI configuration space. If you have on-chip devices that do not
> look like PCI devices to software, or that interact with other on-chip
> controllers at run-time as on typical arm32 embedded SoCs, you are in
> trouble to start with, and there are two possible ways to deal with this
> in theory:
> 
> a) Hide all the register-level setup behind AML code and make Linux only
>    aware of the possible device states that it can ask for, which would
>    make this look similar to today's servers.
> 
> b) Model all the soc-internal registers as devices and write OS-specific
>    SoC-specific device drivers for them, using yet-to-be-defined ACPI
>    extensions to describe the interactions between devices. This would
>    be modeled along the lines of what we do today with DT, and what Intel
>    wants to do on their embedded SoCs with ACPI in the future.
> 
> I think anybody would agree that we should not try to mix the two models
> in a single system, as that would create an endless source of bugs when
> you have two drivers fighting over the same hardware. There is also a
> rough consensus that we really only want a) and not b) on ARM, but there
> have been indications that people are already working on b), which I
> think is a bit worrying. I would argue that anyone who wants b) on 
> ARM should not use ACPI at all but rather describe the hardware using
> DT as we do today. This could possibly change if someone shows that a)
> is actually not a realistic model at all, but I also think that doing b)
> properly will depend on doing a major ACPI-6.0 or ACPI-7.0 release
> to actually specify a standard model for the extra subsystems.

I'm inclined to say that (ARM) Linux should only support stuff captured
in an ACPI spec but I'm not familiar enough with this to assess its
feasibility.

Choosing between a) and b) depends when where you place the maintenance
burden. Point a) pretty much leaves this with the hw vendors. They get a
distro with a kernel supporting ACPI-x and (PCI) device drivers they
need but other SoC specific is handled by firmware or AML. It is their
responsibility to work on firmware and AML until getting it right
without changing the kernel (well, unless they find genuine bugs with
the code).

Point b) is simpler for kernel developers as we know how to debug and
maintain kernel code but I agree with you that we should rather use FDT
here than duplicate the effort just for the sake of ACPI.

Waiting for OS distros and vendors to clarify but I think RH are mainly
looking at a). My (mis)understanding is based based on pro-ACPI
arguments I heard like being able to use newer hardware with older
kernels (and b) would always require new SoC drivers and bindings).

-- 
Catalin

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Mark Brown]

On Tue, Dec 17, 2013 at 11:29:14AM +0000, Catalin Marinas wrote:

> - What if two hw vendors have different descriptors for the same device?

This one at least is already handled - ACPI ID tables are lists of IDs
just the same as everything else so we can have as many different
bindings for the same device as the hardware vendors see fit to bless us
with.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/33d8ac0c/attachment.sig>

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Hanjun Guo]

On 2013-12-10 0:55, Catalin Marinas wrote:
> On Mon, Dec 09, 2013 at 04:35:04PM +0000, Arnd Bergmann wrote:
>> On Monday 09 December 2013, Hanjun Guo wrote:
>>> On 2013-12-9 19:50, Catalin Marinas wrote:
>>>> On Mon, Dec 09, 2013 at 04:12:24AM +0000, Hanjun Guo wrote:
>>>>>
>>>>> I think the concern here is that ACPI is only for server platform or not.
>>>>>
>>>>> Since ACPI has lots of content related to power management, I think ACPI
>>>>> can be used for mobile devices and other platform too, not only for ARM
>>>>> servers, and with this patch, we can support both requirement.
>>>>
>>>> 'Can be used' is one thing, will it really be used is another? I don't
>>>> think so, it was (well, is) difficult enough to make the transition to
>>>> FDT, I don't see how ACPI would solve the current issues.
>>
>> Exactly. In particular we don't want people to get the wrong idea about
>> where we are heading, so making it possible to use this code on embedded
>> systems for me is a reason *not* to take the patch.
> 
> I agree.
> 
>>>> I see ACPI as a server distro requirement and there are indeed benefits
>>>> in abstracting the hardware behind standard description, AML. Of course,
>>>> this would work even better with probe-able buses like PCIe and I'm
>>>> pretty sure this would be the case on high-end servers. But even if a
>>>> server distro like RHEL supports a SoC without PCIe, I would expect them
>>>> to only provide a single binary Image with CONFIG_PCI enabled.
>>>>
>>>> This patch is small enough and allows ACPI build with !CONFIG_PCI for
>>>> the time being but longer term I would expect such SoCs without PCI to
>>>> be able to run on a kernel with CONFIG_PCI enabled.
>>>
>>> Yes, we will support PCI in ACPI in the long run, and we just make PCI
>>> optional for ACPI in this patch.
>>
>> Do you mean there is a problem running your code with PCI /enabled/ at the
>> moment? If so, I'd suggest fixing that instead since you will have to fix
>> it anyway.
> 
> CONFIG_PCI does not exist on arm64 yet (we have some internal patches
> but may not be ready to be posted before the holidays; they try to share
> code with other archs, so more discussions before merging). We could add
> CONFIG_PCI and some dummy functions on arm64 for development (not to be
> upstreamed) or Hanjun could continue to use the current patch before we
> get PCI working. 

Thanks for the suggestion, I will continue to use the current patch, and
I will rework or rebase this one when PCI is working.

Hanjun

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Matthew Garrett]

On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:

> Exactly. In particular we don't want people to get the wrong idea about
> where we are heading, so making it possible to use this code on embedded
> systems for me is a reason *not* to take the patch.

People are trying to deploy ACPI-based embedded x86, and most of the 
ACPI/DT integration discussion seems to have been based on the idea that 
this is a worthwhile thing to support. If we're not interested in doing 
so then we should probably make that a whole kernel decision rather than 
a per architecture one.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Hanjun Guo]

On 2013-12-10 1:06, Matthew Garrett wrote:
> On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
> 
>> Exactly. In particular we don't want people to get the wrong idea about
>> where we are heading, so making it possible to use this code on embedded
>> systems for me is a reason *not* to take the patch.
> 
> People are trying to deploy ACPI-based embedded x86, and most of the 
> ACPI/DT integration discussion seems to have been based on the idea that 
> this is a worthwhile thing to support. If we're not interested in doing 
> so then we should probably make that a whole kernel decision rather than 
> a per architecture one.

I agree, thanks for this information.

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Arnd Bergmann]

On Monday 09 December 2013, Matthew Garrett wrote:
> 
> On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
> 
> > Exactly. In particular we don't want people to get the wrong idea about
> > where we are heading, so making it possible to use this code on embedded
> > systems for me is a reason not to take the patch.
> 
> People are trying to deploy ACPI-based embedded x86, and most of the 
> ACPI/DT integration discussion seems to have been based on the idea that 
> this is a worthwhile thing to support. If we're not interested in doing 
> so then we should probably make that a whole kernel decision rather than 
> a per architecture one.

Well, except it's not an architecture independent decision. An embedded
x86 SoC will still be very much like a PC, just with a few things added
in and some other bits left out, and you can already describe it mostly
with plain ACPI-5.0. Also, there are only a couple of different non-PC style
devices that Intel is integrating into their SoCs, so we're talking
about a few dozen device drivers here.

The embedded ARM SoCs we have are very much unlike a PC in lots of ways
and there are orders of magnitude more SoCs and on-chip devices that
are potentially impacted by this, so it's definitely not the same thing.

ARM developers are still licking the wounds from a painful migration
from board files to DT, and we will probably spend at least one or
two more years tying up the loose ends from that before we can actually
call that done. We are not ready to go through the same process (or worse)
again any time soon just because x86 does it, and the only reason we're
talking about this for servers is the promise that this is contained to
server-class systems with hardware and firmware people that know what
they are doing and that can make this work as easy as x86 servers
without adding a whole lot of complexity into the kernel.

	Arnd

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Mark Brown]

On Tue, Dec 10, 2013 at 04:28:52AM +0100, Arnd Bergmann wrote:
> On Monday 09 December 2013, Matthew Garrett wrote:

> > People are trying to deploy ACPI-based embedded x86, and most of the 
> > ACPI/DT integration discussion seems to have been based on the idea that 
> > this is a worthwhile thing to support. If we're not interested in doing 
> > so then we should probably make that a whole kernel decision rather than 
> > a per architecture one.

> Well, except it's not an architecture independent decision. An embedded
> x86 SoC will still be very much like a PC, just with a few things added
> in and some other bits left out, and you can already describe it mostly

It's not just the SoC, it's also the rest of the board.  The patches the
Intel guys are submitting at the minute are mainly for the off-SoC
devices at least as far as I noticed.  This'll impact anyone who ends up
using ACPI, we need to at least pay attention to what's going on there.

> with plain ACPI-5.0. Also, there are only a couple of different non-PC style
> devices that Intel is integrating into their SoCs, so we're talking
> about a few dozen device drivers here.

It's going to be way more than that for the whole system, and you can't
assume that all the system integrators are going to pay a blind bit of
notice to the reference designs.  Some will just clone them but others
will bin them and do their own thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131210/fc53cb0f/attachment.sig>

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Arnd Bergmann]

On Tuesday 10 December 2013, Mark Brown wrote:
> On Tue, Dec 10, 2013 at 04:28:52AM +0100, Arnd Bergmann wrote:
> > On Monday 09 December 2013, Matthew Garrett wrote:
> 
> > > People are trying to deploy ACPI-based embedded x86, and most of the 
> > > ACPI/DT integration discussion seems to have been based on the idea that 
> > > this is a worthwhile thing to support. If we're not interested in doing 
> > > so then we should probably make that a whole kernel decision rather than 
> > > a per architecture one.
> 
> > Well, except it's not an architecture independent decision. An embedded
> > x86 SoC will still be very much like a PC, just with a few things added
> > in and some other bits left out, and you can already describe it mostly
> 
> It's not just the SoC, it's also the rest of the board.  The patches the
> Intel guys are submitting at the minute are mainly for the off-SoC
> devices at least as far as I noticed.  This'll impact anyone who ends up
> using ACPI, we need to at least pay attention to what's going on there.

Yes, but I'm not that worried about off-soc stuff, which tends to be
off the much simpler variety: a few MMIO or PIO registers, IRQs,
GPIOs or (with ACPI-5.0) devices on i2c and spi buses.

> > with plain ACPI-5.0. Also, there are only a couple of different non-PC style
> > devices that Intel is integrating into their SoCs, so we're talking
> > about a few dozen device drivers here.
> 
> It's going to be way more than that for the whole system, and you can't
> assume that all the system integrators are going to pay a blind bit of
> notice to the reference designs.  Some will just clone them but others
> will bin them and do their own thing.

They won't be able to change the on-chip components for obvious reasons.

	Arnd

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Mark Brown]

On Tue, Dec 10, 2013 at 09:00:20PM +0100, Arnd Bergmann wrote:
> On Tuesday 10 December 2013, Mark Brown wrote:

> > It's not just the SoC, it's also the rest of the board.  The patches the
> > Intel guys are submitting at the minute are mainly for the off-SoC
> > devices at least as far as I noticed.  This'll impact anyone who ends up
> > using ACPI, we need to at least pay attention to what's going on there.

> Yes, but I'm not that worried about off-soc stuff, which tends to be
> off the much simpler variety: a few MMIO or PIO registers, IRQs,
> GPIOs or (with ACPI-5.0) devices on i2c and spi buses.

That's not my experience especially once you get into phone type
hardware - there's not much complexity difference when gluing things
into the system and the fact that it's connected by the board increases
the amount of flexibility that has to be coped with.  I don't see a
substantial difference between the two cases.  To be honest I'm a bit
concerned about what we're going to see given where ACPI's at as a spec.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131210/afc23f81/attachment.sig>

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Arnd Bergmann]

On Tuesday 10 December 2013, Mark Brown wrote:
> On Tue, Dec 10, 2013 at 09:00:20PM +0100, Arnd Bergmann wrote:
> > On Tuesday 10 December 2013, Mark Brown wrote:
> 
> > > It's not just the SoC, it's also the rest of the board.  The patches the
> > > Intel guys are submitting at the minute are mainly for the off-SoC
> > > devices at least as far as I noticed.  This'll impact anyone who ends up
> > > using ACPI, we need to at least pay attention to what's going on there.
> 
> > Yes, but I'm not that worried about off-soc stuff, which tends to be
> > off the much simpler variety: a few MMIO or PIO registers, IRQs,
> > GPIOs or (with ACPI-5.0) devices on i2c and spi buses.
> 
> That's not my experience especially once you get into phone type
> hardware - there's not much complexity difference when gluing things
> into the system and the fact that it's connected by the board increases
> the amount of flexibility that has to be coped with.

Yes, that is probably right. The only argument that one can make about
the mobile phone case is that these devices are so complex that nobody
even bothers any more running upstream kernels on them on any CPU
architecture. If the kernel code is kept out of the mainline tree,
it doesn't matter to us what they use, and the developers don't gain
much by following any of the available firmware models either.

	Arnd

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Mark Brown]

On Wed, Dec 11, 2013 at 04:07:27AM +0100, Arnd Bergmann wrote:
> On Tuesday 10 December 2013, Mark Brown wrote:

> > That's not my experience especially once you get into phone type
> > hardware - there's not much complexity difference when gluing things
> > into the system and the fact that it's connected by the board increases
> > the amount of flexibility that has to be coped with.

> Yes, that is probably right. The only argument that one can make about
> the mobile phone case is that these devices are so complex that nobody
> even bothers any more running upstream kernels on them on any CPU
> architecture. If the kernel code is kept out of the mainline tree,
> it doesn't matter to us what they use, and the developers don't gain
> much by following any of the available firmware models either.

It's more of a commercial thing than a complexity thing (complexity adds
a barrier but it's not fundamental) - the designs for phones aren't
meaningfully different to those for tablets, and looking at both things
like the ARM Chromeboos and what the low power Haswell stuff is doing
laptops are looking an awful lot like tablets these days.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131211/92133644/attachment.sig>

[Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Linus Walleij]

On Mon, Dec 9, 2013 at 6:06 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Mon, Dec 09, 2013 at 05:35:04PM +0100, Arnd Bergmann wrote:
>
>> Exactly. In particular we don't want people to get the wrong idea about
>> where we are heading, so making it possible to use this code on embedded
>> systems for me is a reason *not* to take the patch.
>
> People are trying to deploy ACPI-based embedded x86, and most of the
> ACPI/DT integration discussion seems to have been based on the idea that
> this is a worthwhile thing to support.

I have only seen Intel doing this, are there more people doing that?

As noted on patch [0/7] I still get patches for embedded x86 which
use ISA-style probing for embedded x86, e.g:
http://marc.info/?l=linux-gpio&m=138559852307673&w=2

At the same time some people are refining SFI (simple firmware
interface) support for GPIO, albeit I think that was for elder
embedded x86'es.

Yours,
Linus Walleij

[RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Rob Herring]

On Thu, Dec 5, 2013 at 4:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 04 December 2013, Hanjun Guo wrote:
>> On 2013?12?04? 00:41, Matthew Garrett wrote:
>> > Given the number of #ifdefs you're adding, wouldn't it make more sense
>> > to just add stub functions to include/linux/pci.h?
>>
>> Thanks for the suggestion :)
>>
>> I can add stub functions in include/linux/pci.h for raw_pci_read()/
>> raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration().
>
> Actually I wonder about the usefulness of this patch in either form: Since ACPI
> on ARM64 is only for servers, I would very much expect them to always come with
> PCI, either physical host bridges with attached devices, or logical PCI functions
> used to describe the on-SoC I/O devices. Even in case of virtual machines, you'd
> normally use PCI as the method to communicate data about the virtio channels.
>
> Can you name a realistic use-case where you'd want ACPI but not PCI?

Calxeda h/w. Yes, we do have PCI, but it is optional.

Rob

[RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[One Thousand Gnomes]

> diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
> index a6c77e8b..89a181f 100644
> --- a/drivers/acpi/reboot.c
> +++ b/drivers/acpi/reboot.c
> @@ -3,12 +3,43 @@
>  #include <linux/acpi.h>
>  #include <acpi/reboot.h>
>  
> +/*
> + * There are some rare cases in the ARM world with PCI is not one
> + * of the buses available to us, even though we use ACPI.

Can we have a comment that is easier to understand here and perhaps a
better function name ?

> + */
> +#ifdef CONFIG_PCI
> +static void acpi_reset_with_writing_pci_config(u64 address, u8 reset_value)
> +{
> +	struct pci_bus *bus0;
> +	unsigned int devfn;
> +
> +	/* The reset register can only live on bus 0. */
> +	bus0 = pci_find_bus(0, 0);
> +	if (!bus0)
> +		return;

So if you can't find the PCI eg because we have no PCI on the device you
return silently, but


> +static void acpi_reset_with_writing_pci_config(u64 address, u8 reset_value)
> +{
> +	pr_warn("Resetting with ACPI PCI RESET_REG failed, PCI is disabled\n");
> +	return;
> +}

the same system without CONFIG_PCI makes a noise.

What happens when you want to build a single kernel which works on both
PCI and non PCI systems. Surely the behaviour should be the same.

The other question I'd ask is given the nature of some of these bits
would it be better to have an acpi/pci.c which holds the PCI bits ?

> +		acpi_reset_with_writing_pci_config(rr->address, reset_value);
>  		break;
>  
>  	case ACPI_ADR_SPACE_SYSTEM_MEMORY:
> diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
> index 167f3d0..5804e77 100644
> --- a/drivers/pnp/pnpacpi/rsparser.c
> +++ b/drivers/pnp/pnpacpi/rsparser.c
> @@ -113,8 +113,10 @@ static int dma_flags(struct pnp_dev *dev, int type, int bus_master,
>  
>  static void pnpacpi_add_irqresource(struct pnp_dev *dev, struct resource *r)
>  {
> +#ifdef CONFIG_PCI
>  	if (!(r->flags & IORESOURCE_DISABLED))
>  		pcibios_penalize_isa_irq(r->start, 1);

Probably better avoid PCI ifdefs all over the place. Any reason the
includes for the PCI layer can't provide this as a dummy on a non-PCI
system ?

Alan

[RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64

[Hanjun Guo]

On 2013?12?04? 00:47, One Thousand Gnomes wrote:
>> diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
>> index a6c77e8b..89a181f 100644
>> --- a/drivers/acpi/reboot.c
>> +++ b/drivers/acpi/reboot.c
>> @@ -3,12 +3,43 @@
>>   #include <linux/acpi.h>
>>   #include <acpi/reboot.h>
>>   
>> +/*
>> + * There are some rare cases in the ARM world with PCI is not one
>> + * of the buses available to us, even though we use ACPI.
> Can we have a comment that is easier to understand here and perhaps a
> better function name ?

ok, how about "Not all the ARM/ARM64 platforms with CONFIG_PCI enabled, introduce
stub function here in case of !CONFIG_PCI when using ACPI" ?

I will discuss with Graeme for a better function name


>
>> + */
>> +#ifdef CONFIG_PCI
>> +static void acpi_reset_with_writing_pci_config(u64 address, u8 reset_value)
>> +{
>> +	struct pci_bus *bus0;
>> +	unsigned int devfn;
>> +
>> +	/* The reset register can only live on bus 0. */
>> +	bus0 = pci_find_bus(0, 0);
>> +	if (!bus0)
>> +		return;
> So if you can't find the PCI eg because we have no PCI on the device you
> return silently, but
>
>
>> +static void acpi_reset_with_writing_pci_config(u64 address, u8 reset_value)
>> +{
>> +	pr_warn("Resetting with ACPI PCI RESET_REG failed, PCI is disabled\n");
>> +	return;
>> +}
> the same system without CONFIG_PCI makes a noise.
>
> What happens when you want to build a single kernel which works on both
> PCI and non PCI systems. Surely the behaviour should be the same.

Good point, thanks for the guidance, will update in next version.


>
> The other question I'd ask is given the nature of some of these bits
> would it be better to have an acpi/pci.c which holds the PCI bits ?

Sorry, I'm confused here, which PCI bits?


>
>> +		acpi_reset_with_writing_pci_config(rr->address, reset_value);
>>   		break;
>>   
>>   	case ACPI_ADR_SPACE_SYSTEM_MEMORY:
>> diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
>> index 167f3d0..5804e77 100644
>> --- a/drivers/pnp/pnpacpi/rsparser.c
>> +++ b/drivers/pnp/pnpacpi/rsparser.c
>> @@ -113,8 +113,10 @@ static int dma_flags(struct pnp_dev *dev, int type, int bus_master,
>>   
>>   static void pnpacpi_add_irqresource(struct pnp_dev *dev, struct resource *r)
>>   {
>> +#ifdef CONFIG_PCI
>>   	if (!(r->flags & IORESOURCE_DISABLED))
>>   		pcibios_penalize_isa_irq(r->start, 1);
> Probably better avoid PCI ifdefs all over the place. Any reason the
> includes for the PCI layer can't provide this as a dummy on a non-PCI
> system ?

Agreed, I will introduce arch\arm64\include\asm\pci.h to cover pcibios_penalize_isa_irq()
as ARM did, then #ifdef here can be removed.

Thanks
Hanjun

[RFC part1 PATCH 2/7] ARM64 : Add dummy asm/cpu.h

[Hanjun Guo]

ACPI requires a cpu.h, add a dummy one copied from arm. This will need
updated or replaced as ACPI based cpu hotplug for armv8 is worked out.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/cpu.h |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 arch/arm64/include/asm/cpu.h

diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
new file mode 100644
index 0000000..dbeb98d
--- /dev/null
+++ b/arch/arm64/include/asm/cpu.h
@@ -0,0 +1,25 @@
+/*
+ *  Copyright (C) 2004-2005 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ASM_ARM_CPU_H
+#define __ASM_ARM_CPU_H
+
+#include <linux/percpu.h>
+#include <linux/cpu.h>
+#include <linux/topology.h>
+
+struct cpuinfo_arm {
+	struct cpu	cpu;
+	u32		cpuid;
+#ifdef CONFIG_SMP
+	unsigned int	loops_per_jiffy;
+#endif
+};
+
+DECLARE_PER_CPU(struct cpuinfo_arm, cpu_data);
+
+#endif
-- 
1.7.9.5

[RFC part1 PATCH 2/7] ARM64 : Add dummy asm/cpu.h

[Mark Rutland]

On Tue, Dec 03, 2013 at 04:36:46PM +0000, Hanjun Guo wrote:
> ACPI requires a cpu.h, add a dummy one copied from arm. This will need
> updated or replaced as ACPI based cpu hotplug for armv8 is worked out.

What exactly requires cpu.h, and why?

Why copy the file verbatim rather than factoring it out?

> 
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/cpu.h |   25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 arch/arm64/include/asm/cpu.h
> 
> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
> new file mode 100644
> index 0000000..dbeb98d
> --- /dev/null
> +++ b/arch/arm64/include/asm/cpu.h
> @@ -0,0 +1,25 @@
> +/*
> + *  Copyright (C) 2004-2005 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __ASM_ARM_CPU_H
> +#define __ASM_ARM_CPU_H
> +
> +#include <linux/percpu.h>
> +#include <linux/cpu.h>
> +#include <linux/topology.h>
> +
> +struct cpuinfo_arm {
> +	struct cpu	cpu;
> +	u32		cpuid;

We use a u64 elsewhere for the mpidr_el1 in arm64.

Thanks,
Mark.

[RFC part1 PATCH 2/7] ARM64 : Add dummy asm/cpu.h

[Hanjun Guo]

On 2013?12?04? 01:13, Mark Rutland wrote:
> On Tue, Dec 03, 2013 at 04:36:46PM +0000, Hanjun Guo wrote:
>> ACPI requires a cpu.h, add a dummy one copied from arm. This will need
>> updated or replaced as ACPI based cpu hotplug for armv8 is worked out.
> What exactly requires cpu.h, and why?

CPI core will include this file and can not be compiled without it.

ACPI based CPU hotplug needs some functions below:
#ifdef CONFIG_HOTPLUG_CPU
extern int arch_register_cpu(int num);
extern void arch_unregister_cpu(int);
#endif

>
> Why copy the file verbatim rather than factoring it out?

ACPI based cpu hotplug is not implemented in this patch
set and will send out as drivers, so will factoring it
out at that time.
  

>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/cpu.h |   25 +++++++++++++++++++++++++
>>   1 file changed, 25 insertions(+)
>>   create mode 100644 arch/arm64/include/asm/cpu.h
>>
>> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
>> new file mode 100644
>> index 0000000..dbeb98d
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/cpu.h
>> @@ -0,0 +1,25 @@
>> +/*
>> + *  Copyright (C) 2004-2005 ARM Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#ifndef __ASM_ARM_CPU_H
>> +#define __ASM_ARM_CPU_H
>> +
>> +#include <linux/percpu.h>
>> +#include <linux/cpu.h>
>> +#include <linux/topology.h>
>> +
>> +struct cpuinfo_arm {
>> +	struct cpu	cpu;
>> +	u32		cpuid;
> We use a u64 elsewhere for the mpidr_el1 in arm64.

Good catch, will fix it

Thanks
Hanjun

[RFC part1 PATCH 2/7] ARM64 : Add dummy asm/cpu.h

[Mark Brown]

On Wed, Dec 04, 2013 at 12:36:46AM +0800, Hanjun Guo wrote:
> ACPI requires a cpu.h, add a dummy one copied from arm. This will need
> updated or replaced as ACPI based cpu hotplug for armv8 is worked out.

We're going to need the same thing for CPU topology, I've got a similar
addition as part of a series to introduce that (which is going to want
an ACPI back end at some point I guess) at which point it'll stop being
a dummy.  I should be posting this week all being well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131203/456367d3/attachment.sig>

[RFC part1 PATCH 3/7] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent

[Hanjun Guo]

_PDC related stuff in processor_core.c is little bit X86/IA64 dependent,
rework the code to make it more arch-independent.

The return value of acpi_processor_eval_pdc() should be 'acpi_status' but
defined as 'int', fix it too.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
---
 drivers/acpi/processor_core.c |   27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 34e7b3c..9931435 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -273,8 +273,19 @@ static void acpi_set_pdc_bits(u32 *buf)
 	buf[0] = ACPI_PDC_REVISION_ID;
 	buf[1] = 1;
 
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
 	/* Enable coordination with firmware's _TSD info */
 	buf[2] = ACPI_PDC_SMP_T_SWCOORD;
+	if (boot_option_idle_override == IDLE_NOMWAIT) {
+		/*
+		 * If mwait is disabled for CPU C-states, the C2C3_FFH access
+		 * mode will be disabled in the parameter of _PDC object.
+		 * Of course C1_FFH access mode will also be disabled.
+		 */
+		buf[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
+
+	}
+#endif
 
 	/* Twiddle arch-specific bits needed for _PDC */
 	arch_acpi_set_pdc_bits(buf);
@@ -323,25 +334,11 @@ static struct acpi_object_list *acpi_processor_alloc_pdc(void)
  * _PDC is required for a BIOS-OS handshake for most of the newer
  * ACPI processor features.
  */
-static int
+static acpi_status
 acpi_processor_eval_pdc(acpi_handle handle, struct acpi_object_list *pdc_in)
 {
 	acpi_status status = AE_OK;
 
-	if (boot_option_idle_override == IDLE_NOMWAIT) {
-		/*
-		 * If mwait is disabled for CPU C-states, the C2C3_FFH access
-		 * mode will be disabled in the parameter of _PDC object.
-		 * Of course C1_FFH access mode will also be disabled.
-		 */
-		union acpi_object *obj;
-		u32 *buffer = NULL;
-
-		obj = pdc_in->pointer;
-		buffer = (u32 *)(obj->buffer.pointer);
-		buffer[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
-
-	}
 	status = acpi_evaluate_object(handle, "_PDC", pdc_in, NULL);
 
 	if (ACPI_FAILURE(status))
-- 
1.7.9.5

[RFC part1 PATCH 3/7] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent

[Matthew Garrett]

On Wed, Dec 04, 2013 at 12:36:47AM +0800, Hanjun Guo wrote:

> +#if defined(CONFIG_X86) || defined(CONFIG_IA64)
>  	/* Enable coordination with firmware's _TSD info */
>  	buf[2] = ACPI_PDC_SMP_T_SWCOORD;
> +	if (boot_option_idle_override == IDLE_NOMWAIT) {
> +		/*
> +		 * If mwait is disabled for CPU C-states, the C2C3_FFH access
> +		 * mode will be disabled in the parameter of _PDC object.
> +		 * Of course C1_FFH access mode will also be disabled.
> +		 */
> +		buf[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
> +
> +	}
> +#endif

This is (fairly) arch-specific, so why not move it to 
arch_acpi_set_pdc_bits()?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[RFC part1 PATCH 3/7] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent

[Hanjun Guo]

On 2013?12?04? 00:46, Matthew Garrett wrote:
> On Wed, Dec 04, 2013 at 12:36:47AM +0800, Hanjun Guo wrote:
>
>> +#if defined(CONFIG_X86) || defined(CONFIG_IA64)
>>   	/* Enable coordination with firmware's _TSD info */
>>   	buf[2] = ACPI_PDC_SMP_T_SWCOORD;
>> +	if (boot_option_idle_override == IDLE_NOMWAIT) {
>> +		/*
>> +		 * If mwait is disabled for CPU C-states, the C2C3_FFH access
>> +		 * mode will be disabled in the parameter of _PDC object.
>> +		 * Of course C1_FFH access mode will also be disabled.
>> +		 */
>> +		buf[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
>> +
>> +	}
>> +#endif
> This is (fairly) arch-specific, so why not move it to
> arch_acpi_set_pdc_bits()?

Ok, it will make the code much cleaner, will update in next version.

Thanks
Hanjun


>

[RFC part1 PATCH 3/7] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent

[One Thousand Gnomes]

On Wed,  4 Dec 2013 00:36:47 +0800
Hanjun Guo <hanjun.guo@linaro.org> wrote:

> _PDC related stuff in processor_core.c is little bit X86/IA64 dependent,
> rework the code to make it more arch-independent.
> 
> The return value of acpi_processor_eval_pdc() should be 'acpi_status' but
> defined as 'int', fix it too.

Why not just define boot_options_idle_override as well. Then you can
leave the code unchanged. Also more importantly you can have override
values for ARM when it turns out you need those too and the logic will be
the same for both processor families

Alan

[RFC part1 PATCH 3/7] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent

[Matthew Garrett]

On Tue, Dec 03, 2013 at 04:51:40PM +0000, One Thousand Gnomes wrote:
> On Wed,  4 Dec 2013 00:36:47 +0800
> Hanjun Guo <hanjun.guo@linaro.org> wrote:
> 
> > _PDC related stuff in processor_core.c is little bit X86/IA64 dependent,
> > rework the code to make it more arch-independent.
> > 
> > The return value of acpi_processor_eval_pdc() should be 'acpi_status' but
> > defined as 'int', fix it too.
> 
> Why not just define boot_options_idle_override as well. Then you can
> leave the code unchanged. Also more importantly you can have override
> values for ARM when it turns out you need those too and the logic will be
> the same for both processor families

The arguments to _PDC are architecture specific, so there do need to be 
code changes here.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[RFC part1 PATCH 3/7] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent

[Hanjun Guo]

On 2013?12?04? 00:51, One Thousand Gnomes wrote:
> On Wed,  4 Dec 2013 00:36:47 +0800
> Hanjun Guo <hanjun.guo@linaro.org> wrote:
>
>> _PDC related stuff in processor_core.c is little bit X86/IA64 dependent,
>> rework the code to make it more arch-independent.
>>
>> The return value of acpi_processor_eval_pdc() should be 'acpi_status' but
>> defined as 'int', fix it too.
> Why not just define boot_options_idle_override as well. Then you can
> leave the code unchanged. Also more importantly you can have override
> values for ARM when it turns out you need those too and the logic will be
> the same for both processor families

There is a platform dependent head file such as pdc_intel.h which contains
some macros, some of those macros are used in arch-independent file processor_core.c,
that's why I posted this patch.

Thanks
Hanjun

[RFC part1 PATCH 4/7] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64

[Hanjun Guo]

The _PDC (Processor Driver Capabilities) object provides OSPM a
mechanism to convey to the platform the capabilities supported
by OSPM for processor power management.

OSPM evaluates _PDC prior to evaluating any other processor
power management objects returning configuration information.

This patch introduces the skeleton of _PDC related file to make
ACPI core can be compiled on ARM64.

Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h      |   32 ++++++++++++++++++++++++++++++++
 arch/arm64/include/asm/processor.h |   11 +++++++++++
 arch/arm64/kernel/process.c        |    5 +++++
 3 files changed, 48 insertions(+)
 create mode 100644 arch/arm64/include/asm/acpi.h

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
new file mode 100644
index 0000000..c186f5b
--- /dev/null
+++ b/arch/arm64/include/asm/acpi.h
@@ -0,0 +1,32 @@
+/*
+ *  Copyright (C) 2013, Al Stone <al.stone@linaro.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#ifndef _ASM_ARM_ACPI_H
+#define _ASM_ARM_ACPI_H
+
+static inline bool arch_has_acpi_pdc(void)
+{
+	return false;	/* always false for now */
+}
+
+static inline void arch_acpi_set_pdc_bits(u32 *buf)
+{
+	return;
+}
+
+#endif /*_ASM_ARM_ACPI_H*/
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 45b20cd..73b1d3a 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -162,6 +162,17 @@ static inline void spin_lock_prefetch(const void *x)
 
 #define HAVE_ARCH_PICK_MMAP_LAYOUT
 
+#ifdef CONFIG_ACPI
+/*
+ * FIXME: there is no MWAIT on ARM, should be WFI or something else,
+ * and modify drivers/acpi/processor_core.c too.
+ */
+enum idle_boot_override { IDLE_NO_OVERRIDE = 0, IDLE_HALT, IDLE_NOMWAIT,
+			IDLE_POLL, IDLE_FORCE_MWAIT };
+
+extern unsigned long    boot_option_idle_override;
+#endif
+
 #endif
 
 #endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index de17c89..2cd4182 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -347,3 +347,8 @@ unsigned long randomize_et_dyn(unsigned long base)
 {
 	return randomize_base(base);
 }
+
+#ifdef CONFIG_ACPI
+unsigned long boot_option_idle_override = IDLE_NO_OVERRIDE;
+EXPORT_SYMBOL(boot_option_idle_override);
+#endif
-- 
1.7.9.5

[RFC part1 PATCH 4/7] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64

[One Thousand Gnomes]

O> +enum idle_boot_override { IDLE_NO_OVERRIDE = 0, IDLE_HALT, IDLE_NOMWAIT,
> +			IDLE_POLL, IDLE_FORCE_MWAIT };

This should probably move out of the arch directory to be a single enum
including both platforms values. That will make it rather easier to keep
sane and avoid ifdefs around which definitions are for which processor.

[RFC part1 PATCH 4/7] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64

[Hanjun Guo]

On 2013?12?04? 00:53, One Thousand Gnomes wrote:
> O> +enum idle_boot_override { IDLE_NO_OVERRIDE = 0, IDLE_HALT, IDLE_NOMWAIT,
>> +			IDLE_POLL, IDLE_FORCE_MWAIT };
> This should probably move out of the arch directory to be a single enum
> including both platforms values. That will make it rather easier to keep
> sane and avoid ifdefs around which definitions are for which processor.

Thank you very much for the suggestion, it makes sense to me, will figure
out how to implement it.

Thanks
Hanjun

[RFC part1 PATCH 4/7] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64

[Rob Herring]

On Tue, Dec 3, 2013 at 10:36 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> The _PDC (Processor Driver Capabilities) object provides OSPM a
> mechanism to convey to the platform the capabilities supported
> by OSPM for processor power management.
>
> OSPM evaluates _PDC prior to evaluating any other processor
> power management objects returning configuration information.
>
> This patch introduces the skeleton of _PDC related file to make
> ACPI core can be compiled on ARM64.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h      |   32 ++++++++++++++++++++++++++++++++
>  arch/arm64/include/asm/processor.h |   11 +++++++++++
>  arch/arm64/kernel/process.c        |    5 +++++
>  3 files changed, 48 insertions(+)
>  create mode 100644 arch/arm64/include/asm/acpi.h
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> new file mode 100644
> index 0000000..c186f5b
> --- /dev/null
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -0,0 +1,32 @@
> +/*
> + *  Copyright (C) 2013, Al Stone <al.stone@linaro.org>
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +
> +#ifndef _ASM_ARM_ACPI_H
> +#define _ASM_ARM_ACPI_H
> +
> +static inline bool arch_has_acpi_pdc(void)
> +{
> +       return false;   /* always false for now */
> +}
> +
> +static inline void arch_acpi_set_pdc_bits(u32 *buf)
> +{
> +       return;
> +}
> +
> +#endif /*_ASM_ARM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 45b20cd..73b1d3a 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -162,6 +162,17 @@ static inline void spin_lock_prefetch(const void *x)
>
>  #define HAVE_ARCH_PICK_MMAP_LAYOUT
>
> +#ifdef CONFIG_ACPI

The ifdef is not necessary.

> +/*
> + * FIXME: there is no MWAIT on ARM, should be WFI or something else,
> + * and modify drivers/acpi/processor_core.c too.
> + */
> +enum idle_boot_override { IDLE_NO_OVERRIDE = 0, IDLE_HALT, IDLE_NOMWAIT,
> +                       IDLE_POLL, IDLE_FORCE_MWAIT };
> +
> +extern unsigned long    boot_option_idle_override;
> +#endif

[RFC part1 PATCH 4/7] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64

[Hanjun Guo]

On 2013?12?04? 01:12, Rob Herring wrote:
> On Tue, Dec 3, 2013 at 10:36 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
[...]
> +#ifndef _ASM_ARM_ACPI_H
> +#define _ASM_ARM_ACPI_H
> +
> +static inline bool arch_has_acpi_pdc(void)
> +{
> +       return false;   /* always false for now */
> +}
> +
> +static inline void arch_acpi_set_pdc_bits(u32 *buf)
> +{
> +       return;
> +}
> +
> +#endif /*_ASM_ARM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 45b20cd..73b1d3a 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -162,6 +162,17 @@ static inline void spin_lock_prefetch(const void *x)
>
>   #define HAVE_ARCH_PICK_MMAP_LAYOUT
>
> +#ifdef CONFIG_ACPI
> The ifdef is not necessary.

Good catch, will fix it in next version.

Thanks for the comments.

Hanjun

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Hanjun Guo]

introduce arm_core.c and its related head file, after this patch,
we can get ACPI tables from BIOS on ARM64 now.

Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h |   57 +++++++++++
 arch/arm64/kernel/setup.c     |    8 ++
 drivers/acpi/Makefile         |    2 +
 drivers/acpi/plat/Makefile    |    1 +
 drivers/acpi/plat/arm-core.c  |  219 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 287 insertions(+)
 create mode 100644 drivers/acpi/plat/Makefile
 create mode 100644 drivers/acpi/plat/arm-core.c

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index c186f5b..e9444e4 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -19,6 +19,43 @@
 #ifndef _ASM_ARM_ACPI_H
 #define _ASM_ARM_ACPI_H
 
+#include <asm/cacheflush.h>
+
+#include <linux/init.h>
+
+#define COMPILER_DEPENDENT_INT64	long long
+#define COMPILER_DEPENDENT_UINT64	unsigned long long
+
+/*
+ * Calling conventions:
+ *
+ * ACPI_SYSTEM_XFACE        - Interfaces to host OS (handlers, threads)
+ * ACPI_EXTERNAL_XFACE      - External ACPI interfaces
+ * ACPI_INTERNAL_XFACE      - Internal ACPI interfaces
+ * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
+ */
+#define ACPI_SYSTEM_XFACE
+#define ACPI_EXTERNAL_XFACE
+#define ACPI_INTERNAL_XFACE
+#define ACPI_INTERNAL_VAR_XFACE
+
+/* Asm macros */
+#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
+
+/* Basic configuration for ACPI */
+#ifdef	CONFIG_ACPI
+extern int acpi_disabled;
+extern int acpi_noirq;
+extern int acpi_pci_disabled;
+extern int acpi_strict;
+
+static inline void disable_acpi(void)
+{
+	acpi_disabled = 1;
+	acpi_pci_disabled = 1;
+	acpi_noirq = 1;
+}
+
 static inline bool arch_has_acpi_pdc(void)
 {
 	return false;	/* always false for now */
@@ -29,4 +66,24 @@ static inline void arch_acpi_set_pdc_bits(u32 *buf)
 	return;
 }
 
+static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
+static inline void acpi_disable_pci(void)
+{
+	acpi_pci_disabled = 1;
+	acpi_noirq_set();
+}
+
+/* FIXME: this function should be moved to topology.h when it's ready */
+void arch_fix_phys_package_id(int num, u32 slot);
+
+/* temperally define -1 to make acpi core compilerable */
+#define cpu_physical_id(cpu) -1
+
+#else	/* !CONFIG_ACPI */
+#define acpi_disabled 1		/* ACPI sometimes enabled on ARM */
+#define acpi_noirq 1		/* ACPI sometimes enabled on ARM */
+#define acpi_pci_disabled 1	/* ACPI PCI sometimes enabled on ARM */
+#define acpi_strict 1		/* no ACPI spec workarounds on ARM */
+#endif
+
 #endif /*_ASM_ARM_ACPI_H*/
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index bd9bbd0..8199360 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -41,6 +41,7 @@
 #include <linux/memblock.h>
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
+#include <linux/acpi.h>
 
 #include <asm/cputype.h>
 #include <asm/elf.h>
@@ -225,6 +226,13 @@ void __init setup_arch(char **cmdline_p)
 
 	arm64_memblock_init();
 
+	/*
+	 * Parse the ACPI tables for possible boot-time configuration
+	 */
+	acpi_boot_table_init();
+	early_acpi_boot_init();
+	acpi_boot_init();
+
 	paging_init();
 	request_standard_resources();
 
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index d8cebe3..9fbba50 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -83,3 +83,5 @@ obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
 obj-$(CONFIG_ACPI_APEI)		+= apei/
 
 obj-$(CONFIG_ACPI_EXTLOG)	+= acpi_extlog.o
+
+obj-y				+= plat/
diff --git a/drivers/acpi/plat/Makefile b/drivers/acpi/plat/Makefile
new file mode 100644
index 0000000..46bc65e
--- /dev/null
+++ b/drivers/acpi/plat/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARM64)	+= arm-core.o
diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
new file mode 100644
index 0000000..7b8e64a
--- /dev/null
+++ b/drivers/acpi/plat/arm-core.c
@@ -0,0 +1,219 @@
+/*
+ *  ARM/ARM64 Specific Low-Level ACPI Boot Support
+ *
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
+ *  Copyright (C) 2001 Jun Nakajima <jun.nakajima@intel.com>
+ *  Copyright (C) 2013, Al Stone <al.stone@linaro.org> (ARM version)
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/init.h>
+#include <linux/acpi.h>
+#include <linux/acpi_pmtmr.h>
+#include <linux/efi.h>
+#include <linux/cpumask.h>
+#include <linux/memblock.h>
+#include <linux/module.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/slab.h>
+#include <linux/bootmem.h>
+#include <linux/ioport.h>
+#include <linux/pci.h>
+
+#include <asm/pgtable.h>
+#include <asm/io.h>
+#include <asm/smp.h>
+
+/*
+ * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
+ * variable is still required by the ACPI core
+ */
+u32 acpi_rsdt_forced;
+
+int acpi_noirq;			/* skip ACPI IRQ initialization */
+int acpi_strict;
+int acpi_disabled;
+EXPORT_SYMBOL(acpi_disabled);
+
+int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
+EXPORT_SYMBOL(acpi_pci_disabled);
+
+#define PREFIX			"ACPI: "
+
+/* FIXME: this function should be moved to topology.c when it is ready */
+void arch_fix_phys_package_id(int num, u32 slot)
+{
+	return;
+}
+EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
+
+/*
+ * Boot-time Configuration
+ */
+
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+
+static unsigned int gsi_to_irq(unsigned int gsi)
+{
+	int irq = irq_create_mapping(NULL, gsi);
+
+	return irq;
+}
+
+/*
+ * __acpi_map_table() will be called before page_init(), so early_ioremap()
+ * or early_memremap() should be called here.
+ *
+ * FIXME: early_io/memremap()/early_iounmap() are not upstream yet on ARM64,
+ * just wait for Mark Salter's patchset accepted by mainline
+ */
+char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+{
+	if (!phys || !size)
+		return NULL;
+
+	/*
+	 * temporarily use phys_to_virt(),
+	 * should be early_memremap(phys, size) here
+	 */
+	return phys_to_virt(phys);
+}
+
+void __init __acpi_unmap_table(char *map, unsigned long size)
+{
+	if (!map || !size)
+		return;
+
+	/* should be early_iounmap(map, size); */
+	return;
+}
+
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
+{
+	*irq = gsi_to_irq(gsi);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
+
+/*
+ * success: return IRQ number (>=0)
+ * failure: return < 0
+ */
+int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
+{
+	return -1;
+}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+
+static int __init acpi_parse_fadt(struct acpi_table_header *table)
+{
+	return 0;
+}
+
+static void __init early_acpi_process_madt(void)
+{
+	return;
+}
+
+static void __init acpi_process_madt(void)
+{
+	return;
+}
+
+/*
+ * acpi_boot_table_init() and acpi_boot_init()
+ *  called from setup_arch(), always.
+ *	1. checksums all tables
+ *	2. enumerates lapics
+ *	3. enumerates io-apics
+ *
+ * acpi_table_init() is separated to allow reading SRAT without
+ * other side effects.
+ */
+void __init acpi_boot_table_init(void)
+{
+	/*
+	 * If acpi_disabled, bail out
+	 */
+	if (acpi_disabled)
+		return;
+
+	/*
+	 * Initialize the ACPI boot-time table parser.
+	 */
+	if (acpi_table_init()) {
+		disable_acpi();
+		return;
+	}
+}
+
+int __init early_acpi_boot_init(void)
+{
+	/*
+	 * If acpi_disabled, bail out
+	 */
+	if (acpi_disabled)
+		return 1;
+
+	/*
+	 * Process the Multiple APIC Description Table (MADT), if present
+	 */
+	early_acpi_process_madt();
+
+	return 0;
+}
+
+int __init acpi_boot_init(void)
+{
+	/*
+	 * If acpi_disabled, bail out
+	 */
+	if (acpi_disabled)
+		return 1;
+
+	acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
+
+	/*
+	 * Process the Multiple APIC Description Table (MADT), if present
+	 */
+	acpi_process_madt();
+
+	return 0;
+}
+
+static int __init parse_acpi(char *arg)
+{
+	if (!arg)
+		return -EINVAL;
+
+	/* "acpi=off" disables both ACPI table parsing and interpreter */
+	if (strcmp(arg, "off") == 0) {
+		disable_acpi();
+	}
+	/* acpi=strict disables out-of-spec workarounds */
+	else if (strcmp(arg, "strict") == 0) {
+		acpi_strict = 1;
+	}
+	return 0;
+}
+early_param("acpi", parse_acpi);
-- 
1.7.9.5

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Mark Rutland]

On Tue, Dec 03, 2013 at 04:36:49PM +0000, Hanjun Guo wrote:
> introduce arm_core.c and its related head file, after this patch,
> we can get ACPI tables from BIOS on ARM64 now.
> 
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |   57 +++++++++++
>  arch/arm64/kernel/setup.c     |    8 ++
>  drivers/acpi/Makefile         |    2 +
>  drivers/acpi/plat/Makefile    |    1 +
>  drivers/acpi/plat/arm-core.c  |  219 +++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 287 insertions(+)
>  create mode 100644 drivers/acpi/plat/Makefile
>  create mode 100644 drivers/acpi/plat/arm-core.c
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index c186f5b..e9444e4 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -19,6 +19,43 @@
>  #ifndef _ASM_ARM_ACPI_H
>  #define _ASM_ARM_ACPI_H
>  
> +#include <asm/cacheflush.h>
> +
> +#include <linux/init.h>
> +
> +#define COMPILER_DEPENDENT_INT64	long long
> +#define COMPILER_DEPENDENT_UINT64	unsigned long long

Given we've already pulled in linux/init.h, which has pulled in
linux/types.h, is there any reason we can't use s64 and u64 here?

If we can, then why don't we unify this further up so each arch doesn't
have to define this redundantly?

> +
> +/*
> + * Calling conventions:
> + *
> + * ACPI_SYSTEM_XFACE        - Interfaces to host OS (handlers, threads)
> + * ACPI_EXTERNAL_XFACE      - External ACPI interfaces
> + * ACPI_INTERNAL_XFACE      - Internal ACPI interfaces
> + * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
> + */
> +#define ACPI_SYSTEM_XFACE
> +#define ACPI_EXTERNAL_XFACE
> +#define ACPI_INTERNAL_XFACE
> +#define ACPI_INTERNAL_VAR_XFACE
> +
> +/* Asm macros */
> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()

Can you elaborate on when ACPI needs to use this? 

Thanks,
Mark.

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Hanjun Guo]

+CC Lv Zheng

On 2013?12?04? 02:03, Mark Rutland wrote:
> On Tue, Dec 03, 2013 at 04:36:49PM +0000, Hanjun Guo wrote:
>> introduce arm_core.c and its related head file, after this patch,
>> we can get ACPI tables from BIOS on ARM64 now.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |   57 +++++++++++
>>   arch/arm64/kernel/setup.c     |    8 ++
>>   drivers/acpi/Makefile         |    2 +
>>   drivers/acpi/plat/Makefile    |    1 +
>>   drivers/acpi/plat/arm-core.c  |  219 +++++++++++++++++++++++++++++++++++++++++
>>   5 files changed, 287 insertions(+)
>>   create mode 100644 drivers/acpi/plat/Makefile
>>   create mode 100644 drivers/acpi/plat/arm-core.c
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index c186f5b..e9444e4 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -19,6 +19,43 @@
>>   #ifndef _ASM_ARM_ACPI_H
>>   #define _ASM_ARM_ACPI_H
>>   
>> +#include <asm/cacheflush.h>
>> +
>> +#include <linux/init.h>
>> +
>> +#define COMPILER_DEPENDENT_INT64	long long
>> +#define COMPILER_DEPENDENT_UINT64	unsigned long long
> Given we've already pulled in linux/init.h, which has pulled in
> linux/types.h, is there any reason we can't use s64 and u64 here?
>
> If we can, then why don't we unify this further up so each arch doesn't
> have to define this redundantly?

It make sense to me, I didn't notice that before, Lv, any comments about it?

>> +
>> +/*
>> + * Calling conventions:
>> + *
>> + * ACPI_SYSTEM_XFACE        - Interfaces to host OS (handlers, threads)
>> + * ACPI_EXTERNAL_XFACE      - External ACPI interfaces
>> + * ACPI_INTERNAL_XFACE      - Internal ACPI interfaces
>> + * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
>> + */
>> +#define ACPI_SYSTEM_XFACE
>> +#define ACPI_EXTERNAL_XFACE
>> +#define ACPI_INTERNAL_XFACE
>> +#define ACPI_INTERNAL_VAR_XFACE
>> +
>> +/* Asm macros */
>> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
> Can you elaborate on when ACPI needs to use this?

Mainly used in two cases:

1) system sleep, there are sleep states defined
in ACPI, such as S0, S1, S2, S3 and etc.
when system enter sleep states, flush cache is needed.

2) When CPU enter idle states deeper than C3.

Thanks
hanjun

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Zheng, Lv]

> From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-owner at vger.kernel.org] On Behalf Of Hanjun Guo
> Sent: Wednesday, December 04, 2013 12:37 AM
> 
> introduce arm_core.c and its related head file, after this patch,
> we can get ACPI tables from BIOS on ARM64 now.
> 
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |   57 +++++++++++
>  arch/arm64/kernel/setup.c     |    8 ++
>  drivers/acpi/Makefile         |    2 +
>  drivers/acpi/plat/Makefile    |    1 +
>  drivers/acpi/plat/arm-core.c  |  219 +++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 287 insertions(+)
>  create mode 100644 drivers/acpi/plat/Makefile
>  create mode 100644 drivers/acpi/plat/arm-core.c
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index c186f5b..e9444e4 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -19,6 +19,43 @@
>  #ifndef _ASM_ARM_ACPI_H
>  #define _ASM_ARM_ACPI_H
> 
> +#include <asm/cacheflush.h>
> +
> +#include <linux/init.h>
> +
> +#define COMPILER_DEPENDENT_INT64	long long
> +#define COMPILER_DEPENDENT_UINT64	unsigned long long
> +
> +/*
> + * Calling conventions:
> + *
> + * ACPI_SYSTEM_XFACE        - Interfaces to host OS (handlers, threads)
> + * ACPI_EXTERNAL_XFACE      - External ACPI interfaces
> + * ACPI_INTERNAL_XFACE      - Internal ACPI interfaces
> + * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
> + */
> +#define ACPI_SYSTEM_XFACE
> +#define ACPI_EXTERNAL_XFACE
> +#define ACPI_INTERNAL_XFACE
> +#define ACPI_INTERNAL_VAR_XFACE
> +
> +/* Asm macros */
> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()

Well, you may need to check the following environments defined in <acpi/platform/aclinux.h> is sufficient for ARM targets:
49 #define ACPI_USE_SYSTEM_CLIBRARY
50 #define ACPI_USE_DO_WHILE_0
51 #define ACPI_MUTEX_TYPE             ACPI_BINARY_SEMAPHORE

70 #define ACPI_MACHINE_WIDTH          BITS_PER_LONG
Will this zap IO addresses on ARM32 platforms?

And following default settings in <acpi/platform/acenv.h> and <acpi/acxxx.h> is sufficient for ARM targets:
179 #if defined (__IA64__) || defined (__ia64__)
180 #define ACPI_MISALIGNMENT_NOT_SUPPORTED
181 #endif
Will this cause any exceptions on ARM by executing ACPICA name functions?

444 #if ACPI_MACHINE_WIDTH == 64
445 #define ACPI_USE_NATIVE_DIVIDE  /* Use compiler native 64-bit divide */
446 #endif
I think you may see build breakage on ARM32 as you haven't implemented the following ACPICA macros for ARM:
67 #define ACPI_DIV_64_BY_32(n_hi, n_lo, d32, q32, r32)
74 #define ACPI_SHIFT_RIGHT_64(n_hi, n_lo)
Have you tested this yet?

I'm not sure if all global lock code blocks are not referenced by ACPI_REDUCED_HARDWARE and I'm not sure what mechanism is implemented on ARM ACPI platforms to offer the synchronization mechanism between firmware and OSPM.  So you may need to implement the following synchronization protocol in <asm/acpi.h>:
58 #define ACPI_ACQUIRE_GLOBAL_LOCK(facs, Acq)
61 #define ACPI_RELEASE_GLOBAL_LOCK(facs, Acq)

I only reviewed the ACPICA stuffs in <asm/acpi.h>, I didn't take a look at your Linux ACPI stuff in <asm/acpi.h>.  You may need more instructions on the porting issues from Linux ACPI guys.

Thanks and best regards
-Lv

> +
> +/* Basic configuration for ACPI */
> +#ifdef	CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;
> +
> +static inline void disable_acpi(void)
> +{
> +	acpi_disabled = 1;
> +	acpi_pci_disabled = 1;
> +	acpi_noirq = 1;
> +}
> +
>  static inline bool arch_has_acpi_pdc(void)
>  {
>  	return false;	/* always false for now */
> @@ -29,4 +66,24 @@ static inline void arch_acpi_set_pdc_bits(u32 *buf)
>  	return;
>  }
> 
> +static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
> +static inline void acpi_disable_pci(void)
> +{
> +	acpi_pci_disabled = 1;
> +	acpi_noirq_set();
> +}
> +
> +/* FIXME: this function should be moved to topology.h when it's ready */
> +void arch_fix_phys_package_id(int num, u32 slot);
> +
> +/* temperally define -1 to make acpi core compilerable */
> +#define cpu_physical_id(cpu) -1
> +
> +#else	/* !CONFIG_ACPI */
> +#define acpi_disabled 1		/* ACPI sometimes enabled on ARM */
> +#define acpi_noirq 1		/* ACPI sometimes enabled on ARM */
> +#define acpi_pci_disabled 1	/* ACPI PCI sometimes enabled on ARM */
> +#define acpi_strict 1		/* no ACPI spec workarounds on ARM */
> +#endif
> +
>  #endif /*_ASM_ARM_ACPI_H*/
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index bd9bbd0..8199360 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -41,6 +41,7 @@
>  #include <linux/memblock.h>
>  #include <linux/of_fdt.h>
>  #include <linux/of_platform.h>
> +#include <linux/acpi.h>
> 
>  #include <asm/cputype.h>
>  #include <asm/elf.h>
> @@ -225,6 +226,13 @@ void __init setup_arch(char **cmdline_p)
> 
>  	arm64_memblock_init();
> 
> +	/*
> +	 * Parse the ACPI tables for possible boot-time configuration
> +	 */
> +	acpi_boot_table_init();
> +	early_acpi_boot_init();
> +	acpi_boot_init();
> +
>  	paging_init();
>  	request_standard_resources();
> 
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index d8cebe3..9fbba50 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -83,3 +83,5 @@ obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
>  obj-$(CONFIG_ACPI_APEI)		+= apei/
> 
>  obj-$(CONFIG_ACPI_EXTLOG)	+= acpi_extlog.o
> +
> +obj-y				+= plat/
> diff --git a/drivers/acpi/plat/Makefile b/drivers/acpi/plat/Makefile
> new file mode 100644
> index 0000000..46bc65e
> --- /dev/null
> +++ b/drivers/acpi/plat/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ARM64)	+= arm-core.o
> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
> new file mode 100644
> index 0000000..7b8e64a
> --- /dev/null
> +++ b/drivers/acpi/plat/arm-core.c
> @@ -0,0 +1,219 @@
> +/*
> + *  ARM/ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
> + *  Copyright (C) 2001 Jun Nakajima <jun.nakajima@intel.com>
> + *  Copyright (C) 2013, Al Stone <al.stone@linaro.org> (ARM version)
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +
> +#include <linux/init.h>
> +#include <linux/acpi.h>
> +#include <linux/acpi_pmtmr.h>
> +#include <linux/efi.h>
> +#include <linux/cpumask.h>
> +#include <linux/memblock.h>
> +#include <linux/module.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/slab.h>
> +#include <linux/bootmem.h>
> +#include <linux/ioport.h>
> +#include <linux/pci.h>
> +
> +#include <asm/pgtable.h>
> +#include <asm/io.h>
> +#include <asm/smp.h>
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;
> +
> +int acpi_noirq;			/* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
> +
> +#define PREFIX			"ACPI: "
> +
> +/* FIXME: this function should be moved to topology.c when it is ready */
> +void arch_fix_phys_package_id(int num, u32 slot)
> +{
> +	return;
> +}
> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
> +
> +/*
> + * Boot-time Configuration
> + */
> +
> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
> +
> +static unsigned int gsi_to_irq(unsigned int gsi)
> +{
> +	int irq = irq_create_mapping(NULL, gsi);
> +
> +	return irq;
> +}
> +
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here.
> + *
> + * FIXME: early_io/memremap()/early_iounmap() are not upstream yet on ARM64,
> + * just wait for Mark Salter's patchset accepted by mainline
> + */
> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +{
> +	if (!phys || !size)
> +		return NULL;
> +
> +	/*
> +	 * temporarily use phys_to_virt(),
> +	 * should be early_memremap(phys, size) here
> +	 */
> +	return phys_to_virt(phys);
> +}
> +
> +void __init __acpi_unmap_table(char *map, unsigned long size)
> +{
> +	if (!map || !size)
> +		return;
> +
> +	/* should be early_iounmap(map, size); */
> +	return;
> +}
> +
> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> +{
> +	*irq = gsi_to_irq(gsi);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> +
> +/*
> + * success: return IRQ number (>=0)
> + * failure: return < 0
> + */
> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> +{
> +	return -1;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> +
> +void acpi_unregister_gsi(u32 gsi)
> +{
> +}
> +EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
> +
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +	return 0;
> +}
> +
> +static void __init early_acpi_process_madt(void)
> +{
> +	return;
> +}
> +
> +static void __init acpi_process_madt(void)
> +{
> +	return;
> +}
> +
> +/*
> + * acpi_boot_table_init() and acpi_boot_init()
> + *  called from setup_arch(), always.
> + *	1. checksums all tables
> + *	2. enumerates lapics
> + *	3. enumerates io-apics
> + *
> + * acpi_table_init() is separated to allow reading SRAT without
> + * other side effects.
> + */
> +void __init acpi_boot_table_init(void)
> +{
> +	/*
> +	 * If acpi_disabled, bail out
> +	 */
> +	if (acpi_disabled)
> +		return;
> +
> +	/*
> +	 * Initialize the ACPI boot-time table parser.
> +	 */
> +	if (acpi_table_init()) {
> +		disable_acpi();
> +		return;
> +	}
> +}
> +
> +int __init early_acpi_boot_init(void)
> +{
> +	/*
> +	 * If acpi_disabled, bail out
> +	 */
> +	if (acpi_disabled)
> +		return 1;
> +
> +	/*
> +	 * Process the Multiple APIC Description Table (MADT), if present
> +	 */
> +	early_acpi_process_madt();
> +
> +	return 0;
> +}
> +
> +int __init acpi_boot_init(void)
> +{
> +	/*
> +	 * If acpi_disabled, bail out
> +	 */
> +	if (acpi_disabled)
> +		return 1;
> +
> +	acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +
> +	/*
> +	 * Process the Multiple APIC Description Table (MADT), if present
> +	 */
> +	acpi_process_madt();
> +
> +	return 0;
> +}
> +
> +static int __init parse_acpi(char *arg)
> +{
> +	if (!arg)
> +		return -EINVAL;
> +
> +	/* "acpi=off" disables both ACPI table parsing and interpreter */
> +	if (strcmp(arg, "off") == 0) {
> +		disable_acpi();
> +	}
> +	/* acpi=strict disables out-of-spec workarounds */
> +	else if (strcmp(arg, "strict") == 0) {
> +		acpi_strict = 1;
> +	}
> +	return 0;
> +}
> +early_param("acpi", parse_acpi);
> --
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Hanjun Guo]

On 2013?12?04? 13:46, Zheng, Lv wrote:
>> From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-owner at vger.kernel.org] On Behalf Of Hanjun Guo
>> Sent: Wednesday, December 04, 2013 12:37 AM
>>
>> introduce arm_core.c and its related head file, after this patch,
>> we can get ACPI tables from BIOS on ARM64 now.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |   57 +++++++++++
>>   arch/arm64/kernel/setup.c     |    8 ++
>>   drivers/acpi/Makefile         |    2 +
>>   drivers/acpi/plat/Makefile    |    1 +
>>   drivers/acpi/plat/arm-core.c  |  219 +++++++++++++++++++++++++++++++++++++++++
>>   5 files changed, 287 insertions(+)
>>   create mode 100644 drivers/acpi/plat/Makefile
>>   create mode 100644 drivers/acpi/plat/arm-core.c
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index c186f5b..e9444e4 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -19,6 +19,43 @@
>>   #ifndef _ASM_ARM_ACPI_H
>>   #define _ASM_ARM_ACPI_H
>>
>> +#include <asm/cacheflush.h>
>> +
>> +#include <linux/init.h>
>> +
>> +#define COMPILER_DEPENDENT_INT64	long long
>> +#define COMPILER_DEPENDENT_UINT64	unsigned long long
>> +
>> +/*
>> + * Calling conventions:
>> + *
>> + * ACPI_SYSTEM_XFACE        - Interfaces to host OS (handlers, threads)
>> + * ACPI_EXTERNAL_XFACE      - External ACPI interfaces
>> + * ACPI_INTERNAL_XFACE      - Internal ACPI interfaces
>> + * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
>> + */
>> +#define ACPI_SYSTEM_XFACE
>> +#define ACPI_EXTERNAL_XFACE
>> +#define ACPI_INTERNAL_XFACE
>> +#define ACPI_INTERNAL_VAR_XFACE
>> +
>> +/* Asm macros */
>> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
> Well, you may need to check the following environments defined in <acpi/platform/aclinux.h> is sufficient for ARM targets:
> 49 #define ACPI_USE_SYSTEM_CLIBRARY
> 50 #define ACPI_USE_DO_WHILE_0
> 51 #define ACPI_MUTEX_TYPE             ACPI_BINARY_SEMAPHORE
>
> 70 #define ACPI_MACHINE_WIDTH          BITS_PER_LONG
> Will this zap IO addresses on ARM32 platforms?

In this patch set, we only implemented ACPI for ARM64, and ARM32 is
not included in this patch set.

My bad, sorry for the vague changelog.

> And following default settings in <acpi/platform/acenv.h> and <acpi/acxxx.h> is sufficient for ARM targets:
> 179 #if defined (__IA64__) || defined (__ia64__)
> 180 #define ACPI_MISALIGNMENT_NOT_SUPPORTED
> 181 #endif
> Will this cause any exceptions on ARM by executing ACPICA name functions?
>
> 444 #if ACPI_MACHINE_WIDTH == 64
> 445 #define ACPI_USE_NATIVE_DIVIDE  /* Use compiler native 64-bit divide */
> 446 #endif
> I think you may see build breakage on ARM32 as you haven't implemented the following ACPICA macros for ARM:
> 67 #define ACPI_DIV_64_BY_32(n_hi, n_lo, d32, q32, r32)
> 74 #define ACPI_SHIFT_RIGHT_64(n_hi, n_lo)
> Have you tested this yet?

Yes, we tested on ARM32 and it works fine on linaro-acpi, but patches
for ARM32 is not sent out for upstream yet, that's why you can't see
the code you needed.


>
> I'm not sure if all global lock code blocks are not referenced by ACPI_REDUCED_HARDWARE and I'm not sure what mechanism is implemented on ARM ACPI platforms to offer the synchronization mechanism between firmware and OSPM.  So you may need to implement the following synchronization protocol in <asm/acpi.h>:
> 58 #define ACPI_ACQUIRE_GLOBAL_LOCK(facs, Acq)
> 61 #define ACPI_RELEASE_GLOBAL_LOCK(facs, Acq)

In reduced hardware mode, No hardware resource sharing between
OSPM and other asynchronous operating environments, such as
UEFI Runtime Services or System Management Mode. (The Global Lock
is not supported)
  
please refer to chapter 3.11.1 of ACPI 5.0.


>
> I only reviewed the ACPICA stuffs in <asm/acpi.h>, I didn't take a look at your Linux ACPI stuff in <asm/acpi.h>.  You may need more instructions on the porting issues from Linux ACPI guys.

Yes, I will. Thank you for the review and guidance, and you are the expert
for ACPICA, we need your instructions too

Thanks
Hanjun

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Al Stone]

On 12/04/2013 08:53 AM, Hanjun Guo wrote:
> On 2013?12?04? 13:46, Zheng, Lv wrote:
>>> From: linux-acpi-owner at vger.kernel.org
>>> [mailto:linux-acpi-owner at vger.kernel.org] On Behalf Of Hanjun Guo
>>> Sent: Wednesday, December 04, 2013 12:37 AM
>>>
>>> introduce arm_core.c and its related head file, after this patch,
>>> we can get ACPI tables from BIOS on ARM64 now.
>>>
>>> Signed-off-by: Al Stone <al.stone@linaro.org>
>>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>>   arch/arm64/include/asm/acpi.h |   57 +++++++++++
>>>   arch/arm64/kernel/setup.c     |    8 ++
>>>   drivers/acpi/Makefile         |    2 +
>>>   drivers/acpi/plat/Makefile    |    1 +
>>>   drivers/acpi/plat/arm-core.c  |  219
>>> +++++++++++++++++++++++++++++++++++++++++
>>>   5 files changed, 287 insertions(+)
>>>   create mode 100644 drivers/acpi/plat/Makefile
>>>   create mode 100644 drivers/acpi/plat/arm-core.c
>>>

[...]

>>
>> I'm not sure if all global lock code blocks are not referenced by
>> ACPI_REDUCED_HARDWARE and I'm not sure what mechanism is implemented
>> on ARM ACPI platforms to offer the synchronization mechanism between
>> firmware and OSPM.  So you may need to implement the following
>> synchronization protocol in <asm/acpi.h>:
>> 58 #define ACPI_ACQUIRE_GLOBAL_LOCK(facs, Acq)
>> 61 #define ACPI_RELEASE_GLOBAL_LOCK(facs, Acq)
>
> In reduced hardware mode, No hardware resource sharing between
> OSPM and other asynchronous operating environments, such as
> UEFI Runtime Services or System Management Mode. (The Global Lock
> is not supported)
>
> please refer to chapter 3.11.1 of ACPI 5.0.

I agree with Hanjun; the spec clearly states that the ACPI global lock
is not supported in reduced HW mode.  The only similar lock I recall
from the spec is for ECs (Embedded Controllers, section 12) but is very
specific to controlling the interaction with the EC.

If the intent is to use SMI, again, in reduced HW mode, 3.11.1 does
not allow SMI_CMD, and 5.2.9 indicates SMI_CMD is to be ignored.


-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone at linaro.org
-----------------------------------

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Arnd Bergmann]

On Tuesday 03 December 2013, Hanjun Guo wrote:
> +static unsigned int gsi_to_irq(unsigned int gsi)
> +{
> +       int irq = irq_create_mapping(NULL, gsi);
> +
> +       return irq;
> +}

I think this could use a comment regarding your plans for IRQ domains.

Do you expect that all ACPI systems would have only a single GIC IRQ
controller and a single domain, or do you plan to add irqdomain code
later?

	Arnd

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Hanjun Guo]

On 2013?12?05? 11:38, Arnd Bergmann wrote:
> On Tuesday 03 December 2013, Hanjun Guo wrote:
>> +static unsigned int gsi_to_irq(unsigned int gsi)
>> +{
>> +       int irq = irq_create_mapping(NULL, gsi);
>> +
>> +       return irq;
>> +}
> I think this could use a comment regarding your plans for IRQ domains.
>
> Do you expect that all ACPI systems would have only a single GIC IRQ
> controller and a single domain, or do you plan to add irqdomain code
> later?

we added irqdomain code in the part2 patch set, is that the code ok
with you?

Thanks
Hanjun

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Arnd Bergmann]

On Thursday 05 December 2013, Hanjun Guo wrote:
> On 2013?12?05? 11:38, Arnd Bergmann wrote:
> > On Tuesday 03 December 2013, Hanjun Guo wrote:
> >> +static unsigned int gsi_to_irq(unsigned int gsi)
> >> +{
> >> +       int irq = irq_create_mapping(NULL, gsi);
> >> +
> >> +       return irq;
> >> +}
> > I think this could use a comment regarding your plans for IRQ domains.
> >
> > Do you expect that all ACPI systems would have only a single GIC IRQ
> > controller and a single domain, or do you plan to add irqdomain code
> > later?
> 
> we added irqdomain code in the part2 patch set, is that the code ok
> with you?

I don't see where it gets added. Do you mean "[RFC part2 PATCH 8/9] ACPI /
ARM64: Update acpi_register_gsi to register with the core IRQ subsystem"?
That still just uses a single domain.

When we talked about ACPI support at Linaro connect, someone mentioned
that the ACPI spec does have the concept of IRQ domains, but it seems
they are not implemented by Linux.

How do you get a mapping for an IRQ on a secondary irqchip such as
a GPIO extender?

	Arnd

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Rob Herring]

On Tue, Dec 3, 2013 at 10:36 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> introduce arm_core.c and its related head file, after this patch,
> we can get ACPI tables from BIOS on ARM64 now.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |   57 +++++++++++
>  arch/arm64/kernel/setup.c     |    8 ++
>  drivers/acpi/Makefile         |    2 +
>  drivers/acpi/plat/Makefile    |    1 +
>  drivers/acpi/plat/arm-core.c  |  219 +++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 287 insertions(+)
>  create mode 100644 drivers/acpi/plat/Makefile
>  create mode 100644 drivers/acpi/plat/arm-core.c
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index c186f5b..e9444e4 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -19,6 +19,43 @@
>  #ifndef _ASM_ARM_ACPI_H
>  #define _ASM_ARM_ACPI_H
>
> +#include <asm/cacheflush.h>
> +
> +#include <linux/init.h>
> +
> +#define COMPILER_DEPENDENT_INT64       long long
> +#define COMPILER_DEPENDENT_UINT64      unsigned long long
> +
> +/*
> + * Calling conventions:
> + *
> + * ACPI_SYSTEM_XFACE        - Interfaces to host OS (handlers, threads)
> + * ACPI_EXTERNAL_XFACE      - External ACPI interfaces
> + * ACPI_INTERNAL_XFACE      - Internal ACPI interfaces
> + * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
> + */
> +#define ACPI_SYSTEM_XFACE
> +#define ACPI_EXTERNAL_XFACE
> +#define ACPI_INTERNAL_XFACE
> +#define ACPI_INTERNAL_VAR_XFACE
> +
> +/* Asm macros */
> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;
> +
> +static inline void disable_acpi(void)
> +{
> +       acpi_disabled = 1;
> +       acpi_pci_disabled = 1;
> +       acpi_noirq = 1;
> +}
> +
>  static inline bool arch_has_acpi_pdc(void)
>  {
>         return false;   /* always false for now */
> @@ -29,4 +66,24 @@ static inline void arch_acpi_set_pdc_bits(u32 *buf)
>         return;
>  }
>
> +static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
> +static inline void acpi_disable_pci(void)
> +{
> +       acpi_pci_disabled = 1;
> +       acpi_noirq_set();
> +}
> +
> +/* FIXME: this function should be moved to topology.h when it's ready */
> +void arch_fix_phys_package_id(int num, u32 slot);
> +
> +/* temperally define -1 to make acpi core compilerable */
> +#define cpu_physical_id(cpu) -1
> +
> +#else  /* !CONFIG_ACPI */
> +#define acpi_disabled 1                /* ACPI sometimes enabled on ARM */
> +#define acpi_noirq 1           /* ACPI sometimes enabled on ARM */
> +#define acpi_pci_disabled 1    /* ACPI PCI sometimes enabled on ARM */
> +#define acpi_strict 1          /* no ACPI spec workarounds on ARM */
> +#endif
> +
>  #endif /*_ASM_ARM_ACPI_H*/
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index bd9bbd0..8199360 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -41,6 +41,7 @@
>  #include <linux/memblock.h>
>  #include <linux/of_fdt.h>
>  #include <linux/of_platform.h>
> +#include <linux/acpi.h>
>
>  #include <asm/cputype.h>
>  #include <asm/elf.h>
> @@ -225,6 +226,13 @@ void __init setup_arch(char **cmdline_p)
>
>         arm64_memblock_init();
>
> +       /*
> +        * Parse the ACPI tables for possible boot-time configuration
> +        */
> +       acpi_boot_table_init();
> +       early_acpi_boot_init();
> +       acpi_boot_init();
> +

How about a single function here. Perhaps called acpi_early_init. That
would save checking acpi_disabled 3 times.

>         paging_init();
>         request_standard_resources();
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index d8cebe3..9fbba50 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -83,3 +83,5 @@ obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
>  obj-$(CONFIG_ACPI_APEI)                += apei/
>
>  obj-$(CONFIG_ACPI_EXTLOG)      += acpi_extlog.o
> +
> +obj-y                          += plat/
> diff --git a/drivers/acpi/plat/Makefile b/drivers/acpi/plat/Makefile
> new file mode 100644
> index 0000000..46bc65e
> --- /dev/null
> +++ b/drivers/acpi/plat/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ARM64)    += arm-core.o
> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
> new file mode 100644
> index 0000000..7b8e64a
> --- /dev/null
> +++ b/drivers/acpi/plat/arm-core.c
> @@ -0,0 +1,219 @@
> +/*
> + *  ARM/ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
> + *  Copyright (C) 2001 Jun Nakajima <jun.nakajima@intel.com>
> + *  Copyright (C) 2013, Al Stone <al.stone@linaro.org> (ARM version)
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +
> +#include <linux/init.h>
> +#include <linux/acpi.h>
> +#include <linux/acpi_pmtmr.h>
> +#include <linux/efi.h>
> +#include <linux/cpumask.h>
> +#include <linux/memblock.h>
> +#include <linux/module.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/slab.h>
> +#include <linux/bootmem.h>
> +#include <linux/ioport.h>
> +#include <linux/pci.h>
> +
> +#include <asm/pgtable.h>
> +#include <asm/io.h>

linux/io.h although I can't see where it is even needed.

> +#include <asm/smp.h>

linux/smp.h ...

Seems like you have a lot of unnecessary headers here. efi.h, slab.h,
pci.h, etc.

> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;
> +
> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
> +
> +#define PREFIX                 "ACPI: "
> +
> +/* FIXME: this function should be moved to topology.c when it is ready */
> +void arch_fix_phys_package_id(int num, u32 slot)
> +{
> +       return;
> +}
> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
> +
> +/*
> + * Boot-time Configuration
> + */
> +

It is not really clear what this comment applies to.

> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
> +
> +static unsigned int gsi_to_irq(unsigned int gsi)
> +{
> +       int irq = irq_create_mapping(NULL, gsi);
> +
> +       return irq;
> +}
> +
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here.
> + *
> + * FIXME: early_io/memremap()/early_iounmap() are not upstream yet on ARM64,
> + * just wait for Mark Salter's patchset accepted by mainline
> + */
> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +{
> +       if (!phys || !size)
> +               return NULL;
> +
> +       /*
> +        * temporarily use phys_to_virt(),
> +        * should be early_memremap(phys, size) here
> +        */
> +       return phys_to_virt(phys);
> +}
> +
> +void __init __acpi_unmap_table(char *map, unsigned long size)
> +{
> +       if (!map || !size)
> +               return;
> +
> +       /* should be early_iounmap(map, size); */
> +       return;
> +}
> +
> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> +{
> +       *irq = gsi_to_irq(gsi);
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> +
> +/*
> + * success: return IRQ number (>=0)

'> 0' for interrupts is what normally means success in the kernel. 0
is for no irq.

> + * failure: return < 0
> + */
> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> +{
> +       return -1;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> +
> +void acpi_unregister_gsi(u32 gsi)
> +{
> +}
> +EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
> +
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +       return 0;
> +}
> +
> +static void __init early_acpi_process_madt(void)
> +{
> +       return;
> +}
> +
> +static void __init acpi_process_madt(void)
> +{
> +       return;
> +}
> +
> +/*
> + * acpi_boot_table_init() and acpi_boot_init()
> + *  called from setup_arch(), always.
> + *     1. checksums all tables
> + *     2. enumerates lapics
> + *     3. enumerates io-apics
> + *
> + * acpi_table_init() is separated to allow reading SRAT without
> + * other side effects.
> + */
> +void __init acpi_boot_table_init(void)
> +{
> +       /*
> +        * If acpi_disabled, bail out
> +        */
> +       if (acpi_disabled)
> +               return;
> +
> +       /*
> +        * Initialize the ACPI boot-time table parser.
> +        */
> +       if (acpi_table_init()) {
> +               disable_acpi();
> +               return;
> +       }
> +}
> +
> +int __init early_acpi_boot_init(void)
> +{
> +       /*
> +        * If acpi_disabled, bail out
> +        */
> +       if (acpi_disabled)
> +               return 1;
> +
> +       /*
> +        * Process the Multiple APIC Description Table (MADT), if present
> +        */
> +       early_acpi_process_madt();
> +
> +       return 0;
> +}
> +
> +int __init acpi_boot_init(void)
> +{
> +       /*
> +        * If acpi_disabled, bail out
> +        */
> +       if (acpi_disabled)
> +               return 1;
> +
> +       acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +
> +       /*
> +        * Process the Multiple APIC Description Table (MADT), if present
> +        */
> +       acpi_process_madt();
> +
> +       return 0;
> +}
> +
> +static int __init parse_acpi(char *arg)
> +{
> +       if (!arg)
> +               return -EINVAL;
> +
> +       /* "acpi=off" disables both ACPI table parsing and interpreter */
> +       if (strcmp(arg, "off") == 0) {
> +               disable_acpi();
> +       }
> +       /* acpi=strict disables out-of-spec workarounds */
> +       else if (strcmp(arg, "strict") == 0) {
> +               acpi_strict = 1;
> +       }
> +       return 0;
> +}
> +early_param("acpi", parse_acpi);

These aren't common options across architectures?

Rob

[RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file

[Hanjun Guo]

On 2013?12?05? 22:09, Rob Herring wrote:
> On Tue, Dec 3, 2013 at 10:36 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
[...]
>> +
>>   #endif /*_ASM_ARM_ACPI_H*/
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index bd9bbd0..8199360 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -41,6 +41,7 @@
>>   #include <linux/memblock.h>
>>   #include <linux/of_fdt.h>
>>   #include <linux/of_platform.h>
>> +#include <linux/acpi.h>
>>
>>   #include <asm/cputype.h>
>>   #include <asm/elf.h>
>> @@ -225,6 +226,13 @@ void __init setup_arch(char **cmdline_p)
>>
>>          arm64_memblock_init();
>>
>> +       /*
>> +        * Parse the ACPI tables for possible boot-time configuration
>> +        */
>> +       acpi_boot_table_init();
>> +       early_acpi_boot_init();
>> +       acpi_boot_init();
>> +
> How about a single function here. Perhaps called acpi_early_init. That
> would save checking acpi_disabled 3 times.

It is separated for some reasons on intel platforms, one of them
is ACPI based memory hot-plug, SRAT (NUMA related ACPI table)
and its related memory initialization should be finished between
early_acpi_boot_init() and acpi_boot_init().

I keep this code unchanged for future use (memory hotplug)
on ARM, is this make sense to you?

>>          paging_init();
>>          request_standard_resources();
>>
[...]
>> lic License for more details.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/acpi.h>
>> +#include <linux/acpi_pmtmr.h>
>> +#include <linux/efi.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/memblock.h>
>> +#include <linux/module.h>
>> +#include <linux/irq.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/slab.h>
>> +#include <linux/bootmem.h>
>> +#include <linux/ioport.h>
>> +#include <linux/pci.h>
>> +
>> +#include <asm/pgtable.h>
>> +#include <asm/io.h>
> linux/io.h although I can't see where it is even needed.
>
>> +#include <asm/smp.h>
> linux/smp.h ...
>
> Seems like you have a lot of unnecessary headers here. efi.h, slab.h,
> pci.h, etc.

Thanks for the reminding, will update and clean them up.

>> +
>> +/*
>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>> + * variable is still required by the ACPI core
>> + */
>> +u32 acpi_rsdt_forced;
>> +
>> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
>> +int acpi_strict;
>> +int acpi_disabled;
>> +EXPORT_SYMBOL(acpi_disabled);
>> +
>> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
>> +EXPORT_SYMBOL(acpi_pci_disabled);
>> +
>> +#define PREFIX                 "ACPI: "
>> +
>> +/* FIXME: this function should be moved to topology.c when it is ready */
>> +void arch_fix_phys_package_id(int num, u32 slot)
>> +{
>> +       return;
>> +}
>> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
>> +
>> +/*
>> + * Boot-time Configuration
>> + */
>> +
> It is not really clear what this comment applies to.

Yes, only leading some confusion, will remove it.

>> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
>> +
>> +static unsigned int gsi_to_irq(unsigned int gsi)
>> +{
>> +       int irq = irq_create_mapping(NULL, gsi);
>> +
>> +       return irq;
>> +}
>> +
>> +/*
>> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
>> + * or early_memremap() should be called here.
>> + *
>> + * FIXME: early_io/memremap()/early_iounmap() are not upstream yet on ARM64,
>> + * just wait for Mark Salter's patchset accepted by mainline
>> + */
>> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
>> +{
>> +       if (!phys || !size)
>> +               return NULL;
>> +
>> +       /*
>> +        * temporarily use phys_to_virt(),
>> +        * should be early_memremap(phys, size) here
>> +        */
>> +       return phys_to_virt(phys);
>> +}
>> +
>> +void __init __acpi_unmap_table(char *map, unsigned long size)
>> +{
>> +       if (!map || !size)
>> +               return;
>> +
>> +       /* should be early_iounmap(map, size); */
>> +       return;
>> +}
>> +
>> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
>> +{
>> +       *irq = gsi_to_irq(gsi);
>> +
>> +       return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
>> +
>> +/*
>> + * success: return IRQ number (>=0)
> '> 0' for interrupts is what normally means success in the kernel. 0
> is for no irq.

Will update :)

>> + * failure: return < 0
>> + */
>> +int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
>> +{
>> +       return -1;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
[...]
>> +
>> +static int __init parse_acpi(char *arg)
>> +{
>> +       if (!arg)
>> +               return -EINVAL;
>> +
>> +       /* "acpi=off" disables both ACPI table parsing and interpreter */
>> +       if (strcmp(arg, "off") == 0) {
>> +               disable_acpi();
>> +       }
>> +       /* acpi=strict disables out-of-spec workarounds */
>> +       else if (strcmp(arg, "strict") == 0) {
>> +               acpi_strict = 1;
>> +       }
>> +       return 0;
>> +}
>> +early_param("acpi", parse_acpi);
> These aren't common options across architectures?

Different architectures have different options,
such as x86, it has more options which ARM is not needed.

Thanks
Hanjun

[RFC part1 PATCH 6/7] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

lowlevel suspend function is needed for ACPI based suspend/resume,
introduce ARM related lowlevel function in this patch.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h |    4 ++++
 drivers/acpi/plat/arm-core.c  |    7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index e9444e4..c830adc 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -79,6 +79,10 @@ void arch_fix_phys_package_id(int num, u32 slot);
 /* temperally define -1 to make acpi core compilerable */
 #define cpu_physical_id(cpu) -1
 
+/* Low-level suspend routine. */
+extern int (*acpi_suspend_lowlevel)(void);
+#define acpi_wakeup_address (0)
+
 #else	/* !CONFIG_ACPI */
 #define acpi_disabled 1		/* ACPI sometimes enabled on ARM */
 #define acpi_noirq 1		/* ACPI sometimes enabled on ARM */
diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
index 7b8e64a..2b6df56 100644
--- a/drivers/acpi/plat/arm-core.c
+++ b/drivers/acpi/plat/arm-core.c
@@ -217,3 +217,10 @@ static int __init parse_acpi(char *arg)
 	return 0;
 }
 early_param("acpi", parse_acpi);
+
+/*
+ * acpi_suspend_lowlevel() - save kernel state and suspend.
+ *
+ * TBD when when ARM/ARM64 starts to support suspend...
+ */
+int (*acpi_suspend_lowlevel)(void);
-- 
1.7.9.5

[RFC part1 PATCH 7/7] ARM64 / ACPI: Enable ARM64 in Kconfig

[Hanjun Guo]

Add Kconfigs to build ACPI on ARM64, and make ACPI runable on ARM64.

acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
depends on X86 || IA64, and implement it on ARM in the furture.

In order to make arm-core.c can both run on ARM and ARM64, introduce
CONFIG_ACPI_ARM to support it.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/Kconfig         |    2 ++
 drivers/acpi/Kconfig       |   12 +++++++++---
 drivers/acpi/plat/Makefile |    2 +-
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 88c8b6c1..a37795f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -280,6 +280,8 @@ source "net/Kconfig"
 
 source "drivers/Kconfig"
 
+source "drivers/acpi/Kconfig"
+
 source "fs/Kconfig"
 
 source "arch/arm64/kvm/Kconfig"
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 53f0f16..f43485e 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -2,13 +2,17 @@
 # ACPI Configuration
 #
 
+config ACPI_ARM
+	bool
+	select ACPI_REDUCED_HARDWARE
+
 menuconfig ACPI
 	bool "ACPI (Advanced Configuration and Power Interface) Support"
 	depends on !IA64_HP_SIM
-	depends on IA64 || X86
-	depends on PCI
+	depends on ((IA64 || X86) && PCI) || ARM64
 	select PNP
-	default y
+	select ACPI_ARM if (ARM || ARM64)
+	default y if !(ARM || ARM64)
 	help
 	  Advanced Configuration and Power Interface (ACPI) support for 
 	  Linux requires an ACPI-compliant platform (hardware/firmware),
@@ -149,6 +153,7 @@ config ACPI_PROCESSOR
 	tristate "Processor"
 	select THERMAL
 	select CPU_IDLE
+	depends on X86 || IA64
 	default y
 	help
 	  This driver installs ACPI as the idle handler for Linux and uses
@@ -250,6 +255,7 @@ config ACPI_DEBUG
 config ACPI_PCI_SLOT
 	bool "PCI slot detection driver"
 	depends on SYSFS
+	depends on PCI
 	default n
 	help
 	  This driver creates entries in /sys/bus/pci/slots/ for all PCI
diff --git a/drivers/acpi/plat/Makefile b/drivers/acpi/plat/Makefile
index 46bc65e..3a61176 100644
--- a/drivers/acpi/plat/Makefile
+++ b/drivers/acpi/plat/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_ARM64)	+= arm-core.o
+obj-$(CONFIG_ACPI_ARM)	+= arm-core.o
-- 
1.7.9.5

[RFC part1 PATCH 7/7] ARM64 / ACPI: Enable ARM64 in Kconfig

[Graeme Gregory]

On Wed, Dec 04, 2013 at 12:36:51AM +0800, Hanjun Guo wrote:
> Add Kconfigs to build ACPI on ARM64, and make ACPI runable on ARM64.
> 
> acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
> depends on X86 || IA64, and implement it on ARM in the furture.
> 
> In order to make arm-core.c can both run on ARM and ARM64, introduce
> CONFIG_ACPI_ARM to support it.
> 
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/Kconfig         |    2 ++
>  drivers/acpi/Kconfig       |   12 +++++++++---
>  drivers/acpi/plat/Makefile |    2 +-
>  3 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 88c8b6c1..a37795f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -280,6 +280,8 @@ source "net/Kconfig"
>  
>  source "drivers/Kconfig"
>  
> +source "drivers/acpi/Kconfig"
> +
>  source "fs/Kconfig"
>  
>  source "arch/arm64/kvm/Kconfig"
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 53f0f16..f43485e 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -2,13 +2,17 @@
>  # ACPI Configuration
>  #
>  
> +config ACPI_ARM
> +	bool
> +	select ACPI_REDUCED_HARDWARE
> +
>  menuconfig ACPI
>  	bool "ACPI (Advanced Configuration and Power Interface) Support"
>  	depends on !IA64_HP_SIM
> -	depends on IA64 || X86
> -	depends on PCI
> +	depends on ((IA64 || X86) && PCI) || ARM64
>  	select PNP
> -	default y
> +	select ACPI_ARM if (ARM || ARM64)
> +	default y if !(ARM || ARM64)

Should only be ARM64 here with the current files in this series, I think
this is causing others confusion looking for arm 32bit support in patches
where there is none yet!

>  	help
>  	  Advanced Configuration and Power Interface (ACPI) support for 
>  	  Linux requires an ACPI-compliant platform (hardware/firmware),
> @@ -149,6 +153,7 @@ config ACPI_PROCESSOR
>  	tristate "Processor"
>  	select THERMAL
>  	select CPU_IDLE
> +	depends on X86 || IA64
>  	default y
>  	help
>  	  This driver installs ACPI as the idle handler for Linux and uses
> @@ -250,6 +255,7 @@ config ACPI_DEBUG
>  config ACPI_PCI_SLOT
>  	bool "PCI slot detection driver"
>  	depends on SYSFS
> +	depends on PCI
>  	default n
>  	help
>  	  This driver creates entries in /sys/bus/pci/slots/ for all PCI
> diff --git a/drivers/acpi/plat/Makefile b/drivers/acpi/plat/Makefile
> index 46bc65e..3a61176 100644
> --- a/drivers/acpi/plat/Makefile
> +++ b/drivers/acpi/plat/Makefile
> @@ -1 +1 @@
> -obj-$(CONFIG_ARM64)	+= arm-core.o
> +obj-$(CONFIG_ACPI_ARM)	+= arm-core.o
> -- 
> 1.7.9.5
> 

[RFC part1 PATCH 7/7] ARM64 / ACPI: Enable ARM64 in Kconfig

[Hanjun Guo]

On 2013?12?04? 18:10, Graeme Gregory wrote:
> On Wed, Dec 04, 2013 at 12:36:51AM +0800, Hanjun Guo wrote:
>> Add Kconfigs to build ACPI on ARM64, and make ACPI runable on ARM64.
>>
>> acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
>> depends on X86 || IA64, and implement it on ARM in the furture.
>>
>> In order to make arm-core.c can both run on ARM and ARM64, introduce
>> CONFIG_ACPI_ARM to support it.
>>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/Kconfig         |    2 ++
>>   drivers/acpi/Kconfig       |   12 +++++++++---
>>   drivers/acpi/plat/Makefile |    2 +-
>>   3 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 88c8b6c1..a37795f 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -280,6 +280,8 @@ source "net/Kconfig"
>>   
>>   source "drivers/Kconfig"
>>   
>> +source "drivers/acpi/Kconfig"
>> +
>>   source "fs/Kconfig"
>>   
>>   source "arch/arm64/kvm/Kconfig"
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 53f0f16..f43485e 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -2,13 +2,17 @@
>>   # ACPI Configuration
>>   #
>>   
>> +config ACPI_ARM
>> +	bool
>> +	select ACPI_REDUCED_HARDWARE
>> +
>>   menuconfig ACPI
>>   	bool "ACPI (Advanced Configuration and Power Interface) Support"
>>   	depends on !IA64_HP_SIM
>> -	depends on IA64 || X86
>> -	depends on PCI
>> +	depends on ((IA64 || X86) && PCI) || ARM64
>>   	select PNP
>> -	default y
>> +	select ACPI_ARM if (ARM || ARM64)
>> +	default y if !(ARM || ARM64)
> Should only be ARM64 here with the current files in this series, I think
> this is causing others confusion looking for arm 32bit support in patches
> where there is none yet!

ah, yes, my bad, will update it in next version.

Thanks
Hanjun

[RFC part1 PATCH 0/7] Make ACPI core running on ARM64

[Arnd Bergmann]

On Tuesday 03 December 2013, Hanjun Guo wrote:
> This is the first part of making ACPI core running on ARM.
> 
> PCI is optional on ARM64 but ACPI is dependent on PCI now, so
> in the first patch we try to make ACPI can be running without
> PCI.
> 
> _PDC is requred for ACPI processor_core.c, but its related code
> is a little bit x86/ia64 dependent, so I rework _PDC related staff
> to make it more arch independent, and then introduce the skeleton
> of _PDC related for ARM64, it should be fully implemented after
> ACPI spec is ready for processor idle control.
> 
> After that, arm-core.c is introduced so we can get ACPI table from
> UEFI, then we can parsed for SMP initialisation, GIC initialisation
> and for ACPI drivers.
> 
> This patch set is based on:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> 
> origin/linux-next branch and plus Al Stone's v2 reduced hardware profile
> patch.

As a meta-comment, I looked over all your patches and none of this looks
scary. It's definitely good that you're doing this work to put the patches
out here for discussion and to get the get the details of this sorted out.
It already looks much better than the earlier snapshots I had looked at
in git trees in the past.

However, as I mentioned before I am much more worried about the parts that
are not done (or not posted) yet and that will be required to actually
have working support for a real server system. Until we know more about
where this is heading, I think we should not merge any of the ARM specific
parts of your patches. Any patches that are reasonable cleanups and bug
fixes for the ACPI subsystem should of course get merged once they are
reviewed.

	Arnd

[RFC part1 PATCH 0/7] Make ACPI core running on ARM64

[Mark Brown]

On Thu, Dec 05, 2013 at 11:25:02PM +0100, Arnd Bergmann wrote:

> However, as I mentioned before I am much more worried about the parts that
> are not done (or not posted) yet and that will be required to actually
> have working support for a real server system. Until we know more about
> where this is heading, I think we should not merge any of the ARM specific
> parts of your patches. Any patches that are reasonable cleanups and bug
> fixes for the ACPI subsystem should of course get merged once they are
> reviewed.

OTOH if it's well encapsulated, is going to be required for any kind of
ACPI use and gets to the point where people are OK with it by itself
then I'm not sure what we'd gain by keeping it out of tree - it'd make
the real system patch sets bigger and harder to review.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131206/f0f0bbf6/attachment.sig>

[RFC part1 PATCH 0/7] Make ACPI core running on ARM64

[Arnd Bergmann]

On Friday 06 December 2013, Mark Brown wrote:
> On Thu, Dec 05, 2013 at 11:25:02PM +0100, Arnd Bergmann wrote:
> 
> > However, as I mentioned before I am much more worried about the parts that
> > are not done (or not posted) yet and that will be required to actually
> > have working support for a real server system. Until we know more about
> > where this is heading, I think we should not merge any of the ARM specific
> > parts of your patches. Any patches that are reasonable cleanups and bug
> > fixes for the ACPI subsystem should of course get merged once they are
> > reviewed.
> 
> OTOH if it's well encapsulated, is going to be required for any kind of
> ACPI use and gets to the point where people are OK with it by itself
> then I'm not sure what we'd gain by keeping it out of tree - it'd make
> the real system patch sets bigger and harder to review.

I'd agree as soon as someone can convince me that we actually want ACPI
support in the kernel for ARM64 servers. As far as I'm concerned it's quite
possible that the people who have worked on this for the past couple of
years behind closed doors know what they are doing and it will all be
good, but it's also possible that it turns into a huge trainwreck once
we see multiple implementations that have fundamentally incompatible
requirements regarding what they want from ACPI and we end up not doing
it at all. I just don't have enough information at this point to know which
of the two is true and I'd like to ensure that accepting the patches
that meet your criteria above would not be seen as an endorsement to do
crazy stuff later.

	Arnd

[RFC part1 PATCH 0/7] Make ACPI core running on ARM64

[Mark Brown]

On Sun, Dec 08, 2013 at 03:44:56AM +0100, Arnd Bergmann wrote:
> On Friday 06 December 2013, Mark Brown wrote:

> > OTOH if it's well encapsulated, is going to be required for any kind of
> > ACPI use and gets to the point where people are OK with it by itself
> > then I'm not sure what we'd gain by keeping it out of tree - it'd make
> > the real system patch sets bigger and harder to review.

> I'd agree as soon as someone can convince me that we actually want ACPI
> support in the kernel for ARM64 servers. As far as I'm concerned it's quite
> possible that the people who have worked on this for the past couple of
> years behind closed doors know what they are doing and it will all be
> good, but it's also possible that it turns into a huge trainwreck once
> we see multiple implementations that have fundamentally incompatible
> requirements regarding what they want from ACPI and we end up not doing
> it at all. I just don't have enough information at this point to know which
> of the two is true and I'd like to ensure that accepting the patches
> that meet your criteria above would not be seen as an endorsement to do
> crazy stuff later.

I do share all your concerns about the closed door stuff, and I'm also
not convinced that they'll be able to control the things people try to
do with it if it does become at all successful.  

That said I don't think anyone could be in any reasonable doubt as to
the concerns that people have at this point and I do worry that keeping
everything out of tree will both increase reviwer fatigue if it does end
up getting merged and increase the chances that we end up with a
deployed fiat accomplait being submitted.  We can always add dire
warnings and so on to the code and Kconfig to try to remind people but
so long as it's neither getting in the way of anything else nor making
any real decisions (as opposed to basics for the core spec) I'm not sure
how much we gain, if it never goes anywhere it can just sit and rot
quietly in a corner until it gets in the way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131208/81755432/attachment-0001.sig>

[RFC part1 PATCH 0/7] Make ACPI core running on ARM64

[Linus Walleij]

On Sun, Dec 8, 2013 at 3:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> I'd agree as soon as someone can convince me that we actually want ACPI
> support in the kernel for ARM64 servers. As far as I'm concerned it's quite
> possible that the people who have worked on this for the past couple of
> years behind closed doors know what they are doing and it will all be
> good, but it's also possible that it turns into a huge trainwreck once
> we see multiple implementations that have fundamentally incompatible
> requirements regarding what they want from ACPI and we end up not doing
> it at all.

Here is a piece I've noticed very clearly in the GPIO subsystem:

ACPI is persued for x86 servers, desktops by all vendors. For
embedded x86 it is persued by Intel *ONLY*. We still get several
embedded GPIO drivers for x86 that use ISA-style portmapped I/O
probing (!)

So, hehe, in init/Kconfig there is still the much-debated Kconfig
option "EMBEDDED"...

Should ACPI for ARM64 be depends on !EMBEDDED?

Yours,
Linus Walleij