All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: liyi 00215672 <phoenix.liyi@huawei.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Olof Johansson <olof@lixom.net>,
	Mark Rutland <mark.rutland@arm.com>,
	Grant Likely <grant.likely@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Graeme Gregory <graeme.gregory@linaro.org>,
	Sudeep Holla <Sudeep.Holla@arm.com>, Jon Masters <jcm@redhat.com>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
	Robert Richter <rric@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	"Charles.Garcia-Tobin@arm.com" <Charles.Garcia-Tobin@arm.com>,
	Timur Tabi <timur@codeaurora.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vg>
Subject: Re: 答复: [PATCH v6 17/17] Documentation: ACPI for ARM64
Date: Tue, 06 Jan 2015 21:49:21 +0100	[thread overview]
Message-ID: <9429675.LhiSR5rsOc@wuerfel> (raw)
In-Reply-To: <D0F5605BA99F0B4594FB1EEC24E785CC654879C3@SZXEMA510-MBX.china.huawei.com>

On Tuesday 06 January 2015 09:52:05 liyi 00215672 wrote:
> In traditional telecom market, what confused us(Huawei) was our software
> and hardware coupling together oftentimes. So if we change some hardware
> then we MUST modify our software, which was not our customer’s
> expectation. In x86 world, we have UEFI and ACPI technologies, they are
> suitable to solve this problem very well, we just upgrade our hardware
> and don’t need to upgrade their software, in the meantime ACPI provides
> many methods on power management.

Can you give an example of how ACPI solves the problem of supporting a
particular piece of new hardware?

I assume that for a completely new SoC, it won't help because you
still need device drivers for all the major parts of the hardware
that have changed, so this is about parts of the system that can
be abstracted in AML but not fully described in DT without the need
for new device drivers. Which are the main ones you are interested in
here?

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: liyi 00215672 <phoenix.liyi@huawei.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Olof Johansson <olof@lixom.net>,
	Mark Rutland <mark.rutland@arm.com>,
	Grant Likely <grant.likely@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Graeme Gregory <graeme.gregory@linaro.org>,
	Sudeep Holla <Sudeep.Holla@arm.com>, Jon Masters <jcm@redhat.com>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
	Robert Richter <rric@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	"Charles.Garcia-Tobin@arm.com" <Charles.Garcia-Tobin@arm.com>,
	Timur Tabi <timur@codeaurora.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	Al Stone <al.stone@linaro.org>
Subject: Re: 答复: [PATCH v6 17/17] Documentation: ACPI for ARM64
Date: Tue, 06 Jan 2015 21:49:21 +0100	[thread overview]
Message-ID: <9429675.LhiSR5rsOc@wuerfel> (raw)
In-Reply-To: <D0F5605BA99F0B4594FB1EEC24E785CC654879C3@SZXEMA510-MBX.china.huawei.com>

On Tuesday 06 January 2015 09:52:05 liyi 00215672 wrote:
> In traditional telecom market, what confused us(Huawei) was our software
> and hardware coupling together oftentimes. So if we change some hardware
> then we MUST modify our software, which was not our customer’s
> expectation. In x86 world, we have UEFI and ACPI technologies, they are
> suitable to solve this problem very well, we just upgrade our hardware
> and don’t need to upgrade their software, in the meantime ACPI provides
> many methods on power management.

Can you give an example of how ACPI solves the problem of supporting a
particular piece of new hardware?

I assume that for a completely new SoC, it won't help because you
still need device drivers for all the major parts of the hardware
that have changed, so this is about parts of the system that can
be abstracted in AML but not fully described in DT without the need
for new device drivers. Which are the main ones you are interested in
here?

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: 答复: [PATCH v6 17/17] Documentation: ACPI for ARM64
Date: Tue, 06 Jan 2015 21:49:21 +0100	[thread overview]
Message-ID: <9429675.LhiSR5rsOc@wuerfel> (raw)
In-Reply-To: <D0F5605BA99F0B4594FB1EEC24E785CC654879C3@SZXEMA510-MBX.china.huawei.com>

On Tuesday 06 January 2015 09:52:05 liyi 00215672 wrote:
> In traditional telecom market, what confused us(Huawei) was our software
> and hardware coupling together oftentimes. So if we change some hardware
> then we MUST modify our software, which was not our customer?s
> expectation. In x86 world, we have UEFI and ACPI technologies, they are
> suitable to solve this problem very well, we just upgrade our hardware
> and don?t need to upgrade their software, in the meantime ACPI provides
> many methods on power management.

Can you give an example of how ACPI solves the problem of supporting a
particular piece of new hardware?

I assume that for a completely new SoC, it won't help because you
still need device drivers for all the major parts of the hardware
that have changed, so this is about parts of the system that can
be abstracted in AML but not fully described in DT without the need
for new device drivers. Which are the main ones you are interested in
here?

	Arnd

  parent reply	other threads:[~2015-01-06 20:49 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-04 10:55 [PATCH v6 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2015-01-04 10:55 ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 01/17] ACPI / processor: Convert apic_id to phys_id to make it arch agnostic Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-07  1:50   ` Rafael J. Wysocki
2015-01-07  1:50     ` Rafael J. Wysocki
2015-01-07  1:50     ` Rafael J. Wysocki
2015-01-07  9:49     ` Hanjun Guo
2015-01-07  9:49       ` Hanjun Guo
2015-01-07  9:49       ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 02/17] ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu() Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 03/17] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 04/17] ARM64 / ACPI: Introduce sleep-arm.c Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 05/17] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 06/17] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 07/17] ARM64 / ACPI: Make PCI optional for ACPI on ARM64 Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 08/17] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-09 19:04   ` Lorenzo Pieralisi
2015-01-09 19:04     ` Lorenzo Pieralisi
2015-01-09 19:04     ` Lorenzo Pieralisi
2015-01-12  4:26     ` Hanjun Guo
2015-01-12  4:26       ` Hanjun Guo
2015-01-12  4:26       ` Hanjun Guo
2015-01-12 11:41       ` Lorenzo Pieralisi
2015-01-12 11:41         ` Lorenzo Pieralisi
2015-01-12 11:41         ` Lorenzo Pieralisi
2015-01-13  6:54         ` Hanjun Guo
2015-01-13  6:54           ` Hanjun Guo
2015-01-13  6:54           ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 09/17] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 10/17] ARM64 / ACPI: Parse MADT for SMP initialization Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 11/17] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 12/17] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 14/17] ARM64 / ACPI: Parse GTDT to initialize arch timer Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-05  7:55   ` Suthikulpanit, Suravee
2015-01-05  7:55     ` Suthikulpanit, Suravee
2015-01-05  7:55     ` Suthikulpanit, Suravee
2015-01-05  8:59     ` Hanjun Guo
2015-01-05  8:59       ` Hanjun Guo
2015-01-05  8:59       ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 15/17] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 16/17] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-04 10:55 ` [PATCH v6 17/17] Documentation: ACPI for ARM64 Hanjun Guo
2015-01-04 10:55   ` Hanjun Guo
2015-01-06  9:52   ` 答复: " liyi 00215672
2015-01-06  9:52     ` liyi 00215672
2015-01-06 11:21     ` Hanjun Guo
2015-01-06 11:21       ` Hanjun Guo
2015-01-06 11:21       ` Hanjun Guo
2015-01-06 20:49     ` Arnd Bergmann [this message]
2015-01-06 20:49       ` Arnd Bergmann
2015-01-06 20:49       ` Arnd Bergmann
2015-01-19 20:33   ` Christoffer Dall
2015-01-19 20:33     ` Christoffer Dall
2015-01-19 20:33     ` Christoffer Dall
2015-01-21 12:37     ` Hanjun Guo
2015-01-21 12:37       ` Hanjun Guo
2015-01-21 12:37       ` Hanjun Guo
2015-01-21 13:03       ` Stefano Stabellini
2015-01-21 13:03         ` Stefano Stabellini
2015-01-21 13:03         ` Stefano Stabellini
2015-01-21 16:04       ` Christoffer Dall
2015-01-21 16:04         ` Christoffer Dall
2015-01-21 16:04         ` Christoffer Dall
2015-01-06  7:05 ` [PATCH v6 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Yijing Wang
2015-01-06  7:05   ` Yijing Wang
2015-01-06  7:05   ` Yijing Wang
2015-01-06 11:17   ` Hanjun Guo
2015-01-06 11:17     ` Hanjun Guo
2015-01-06 11:17     ` Hanjun Guo

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=9429675.LhiSR5rsOc@wuerfel \
    --to=arnd@arndb.de \
    --cc=Charles.Garcia-Tobin@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Sudeep.Holla@arm.com \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=graeme.gregory@linaro.org \
    --cc=grant.likely@linaro.org \
    --cc=hanjun.guo@linaro.org \
    --cc=jason@lakedaemon.net \
    --cc=jcm@redhat.com \
    --cc=linux-acpi@vg \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=olof@lixom.net \
    --cc=phoenix.liyi@huawei.com \
    --cc=rdunlap@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=rric@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=timur@codeaurora.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.