From: catalin.marinas@arm•com (Catalin Marinas)
To: linux-arm-kernel@lists•infradead.org
Subject: [Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64
Date: Mon, 9 Dec 2013 11:50:50 +0000 [thread overview]
Message-ID: <20131209115050.GA19163@arm.com> (raw)
In-Reply-To: <52A54328.3000709@linaro.org>
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
next prev parent reply other threads:[~2013-12-09 11:50 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 16:36 [RFC part1 PATCH 0/7] Make ACPI core running on ARM64 Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI " Hanjun Guo
2013-12-03 16:41 ` Matthew Garrett
2013-12-04 14:08 ` Hanjun Guo
2013-12-05 22:04 ` Arnd Bergmann
2013-12-06 15:04 ` [Linaro-acpi] " Tomasz Nowicki
2013-12-06 17:23 ` Arnd Bergmann
2013-12-09 4:12 ` Hanjun Guo
2013-12-09 11:50 ` Catalin Marinas [this message]
2013-12-09 13:05 ` Hanjun Guo
2013-12-09 16:35 ` Arnd Bergmann
2013-12-09 16:55 ` Catalin Marinas
2013-12-09 17:20 ` Arnd Bergmann
2013-12-09 18:01 ` Catalin Marinas
2013-12-16 20:51 ` Graeme Gregory
2013-12-17 11:29 ` Catalin Marinas
2013-12-19 11:30 ` Graeme Gregory
2013-12-19 14:01 ` Arnd Bergmann
2013-12-19 15:43 ` Catalin Marinas
2013-12-20 19:55 ` Mark Brown
2013-12-10 2:53 ` Hanjun Guo
2013-12-09 17:06 ` Matthew Garrett
2013-12-10 1:52 ` Hanjun Guo
2013-12-10 3:28 ` Arnd Bergmann
2013-12-10 19:22 ` Mark Brown
2013-12-10 20:00 ` Arnd Bergmann
2013-12-10 20:23 ` Mark Brown
2013-12-11 3:07 ` Arnd Bergmann
2013-12-11 11:02 ` Mark Brown
2013-12-10 9:56 ` Linus Walleij
2013-12-09 23:34 ` Rob Herring
2013-12-03 16:47 ` One Thousand Gnomes
2013-12-04 14:15 ` Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 2/7] ARM64 : Add dummy asm/cpu.h Hanjun Guo
2013-12-03 17:13 ` Mark Rutland
2013-12-04 15:00 ` Hanjun Guo
2013-12-03 17:59 ` Mark Brown
2013-12-03 16:36 ` [RFC part1 PATCH 3/7] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent Hanjun Guo
2013-12-03 16:46 ` Matthew Garrett
2013-12-04 14:11 ` Hanjun Guo
2013-12-03 16:51 ` One Thousand Gnomes
2013-12-03 17:02 ` Matthew Garrett
2013-12-04 14:16 ` Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 4/7] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64 Hanjun Guo
2013-12-03 16:53 ` One Thousand Gnomes
2013-12-04 14:17 ` Hanjun Guo
2013-12-03 17:12 ` Rob Herring
2013-12-04 14:30 ` Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 5/7] ARM64 / ACPI: Introduce arm_core.c and its related head file Hanjun Guo
2013-12-03 18:03 ` Mark Rutland
2013-12-04 15:48 ` Hanjun Guo
2013-12-04 5:46 ` Zheng, Lv
2013-12-04 15:53 ` Hanjun Guo
2013-12-04 19:47 ` Al Stone
2013-12-05 3:38 ` Arnd Bergmann
2013-12-05 13:51 ` Hanjun Guo
2013-12-05 20:40 ` Arnd Bergmann
2013-12-05 14:09 ` Rob Herring
2013-12-05 14:27 ` Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 6/7] ARM64 / ACPI: Introduce lowlevel suspend function Hanjun Guo
2013-12-03 16:36 ` [RFC part1 PATCH 7/7] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2013-12-04 10:10 ` Graeme Gregory
2013-12-04 15:55 ` Hanjun Guo
2013-12-05 22:25 ` [RFC part1 PATCH 0/7] Make ACPI core running on ARM64 Arnd Bergmann
2013-12-06 13:58 ` Mark Brown
2013-12-08 2:44 ` Arnd Bergmann
2013-12-08 19:40 ` Mark Brown
2013-12-10 9:45 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131209115050.GA19163@arm.com \
--to=catalin.marinas@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox