From: Al Stone
Set the defaults for the arm64 kernel so that the arch-specific _OSI
method and blacklist are always used for ACPI.
Signed-off-by: Al Stone
---
arch/arm64/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 915aa16
From: Al Stone
Having moved the _OSI callback function needed by ACPICA from
drivers/acpi/osl.c to drivers/acpi/osi.c, we now move all the
remaining _OSI support functions to osi.c.
This patch is much larger than I had wanted it to be; several of the
functions that implemented acpi_osi* command
From: Al Stone
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new architectures, the
consensus amongst those writing the ACPI specification and those using
it seems to be to ultimately deprecate the use of _OSI. A change
From: Al Stone
Now that all of the _OSI functionality has been separated out, we can
provide arch-specific functionality for it. This also allows us to do
the same for the acpi_blacklisted() function.
Whether arch-specific functions are used or not now depends on the config
options
From: Al Stone
ACPI_OS_NAME is globally defined as "Microsoft Windows NT" for now.
That doesn't make much sense in the ARM context, so set it to "Linux"
when CONFIG_ARM64.
If it is necessary to change the return value from \_OS_ (that is, return
some value other than the def
on to explain why we need ACPI in ARM64 servers
>>by Grant, and recommendations and prohibitions on the use of the numerous
>>ACPI tables and objects by Al Stone.
>>
>> - Add two patches which is need to map acpi tables after
>> acpi_gbl_permanent_mmap
>
by Grant, and recommendations and prohibitions on the use of the numerous
ACPI tables and objects by Al Stone.
- Add two patches which is need to map acpi tables after
acpi_gbl_permanent_mmap
is set
- Add another patch dt / chosen: Add linux,uefi-stub-generated-dtb
property
From: Al Stone al.st...@linaro.org
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
From: Al Stone al.st...@linaro.org
Set the defaults for the arm64 kernel so that the arch-specific _OSI
method and blacklist are always used for ACPI.
Signed-off-by: Al Stone al.st...@linaro.org
---
arch/arm64/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/Kconfig b
From: Al Stone al.st...@linaro.org
Having moved the _OSI callback function needed by ACPICA from
drivers/acpi/osl.c to drivers/acpi/osi.c, we now move all the
remaining _OSI support functions to osi.c.
This patch is much larger than I had wanted it to be; several of the
functions
Much removed to cut down the size on this and to highlight a couple of specific
sections pertinent to the ACPI on ARMv8 TODO List.
On 02/02/2015 05:45 AM, Hanjun Guo wrote:
From: Al Stone al.st...@linaro.org
Two more documentation files are also being added:
(1) A verbatim copy
From: Al Stone al.st...@linaro.org
Now that all of the _OSI functionality has been separated out, we can
provide arch-specific functionality for it. This also allows us to do
the same for the acpi_blacklisted() function.
Whether arch-specific functions are used or not now depends on the config
From: Al Stone al.st...@linaro.org
ACPI_OS_NAME is globally defined as Microsoft Windows NT for now.
That doesn't make much sense in the ARM context, so set it to Linux
when CONFIG_ARM64.
If it is necessary to change the return value from \_OS_ (that is, return
some value other than the default
From: Al Stone al.st...@linaro.org
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new architectures, the
consensus amongst those writing the ACPI specification and those using
it seems to be to ultimately deprecate the use
arious object caches */
>>
>> diff --git a/include/acpi/platform/aclinux.h
>> b/include/acpi/platform/aclinux.h
>> index 1ba7c19..a8a7ee3 100644
>> --- a/include/acpi/platform/aclinux.h
>> +++ b/include/acpi/platform/aclinux.h
>> @@ -69,6 +69,10 @@
>
On 01/23/2015 08:43 AM, Rafael J. Wysocki wrote:
> Hi Al,
>
> On Thursday, January 22, 2015 05:44:37 PM al.st...@linaro.org wrote:
>> From: Al Stone
>>
>> The use of the ACPI _OSI method in Linux has a long and sordid history.
>> Instead of perpetuating past c
it.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 01/23/2015 08:43 AM, Rafael J. Wysocki wrote:
Hi Al,
On Thursday, January 22, 2015 05:44:37 PM al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new
On 01/22/2015 05:44 PM, al.st...@linaro.org wrote:
> From: Al Stone
> [snip]
While I was assuming a couple more passes would be needed, I
didn't expect quite so soon. My apologies, I thought I had
corrected the From lines to say "Al Stone "
but I had not. That will be fix
From: Al Stone
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback for evaluating _OSI
From: Al Stone
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback for evaluating _OSI
From: Al Stone
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback for evaluating _OSI
From: Al Stone
Having moved the _OSI callback function needed by ACPICA from
drivers/acpi to arch-dependent locations, we now move all the
remaining _OSI support functions to arch-dependent files.
This patch is much larger than I had wanted it to be; several of the
functions that implemented
From: Hanjun Guo
ACPI_OS_NAME is globally defined as "Microsoft Windows NT" for now.
That doesn't make much sense in the ARM context, so set it to "Linux"
when CONFIG_ARM64.
If it is necessary to change the return value from \_OS_ (that is, return
some value other than the default in
From: Al Stone
In preparation for adding some additional arch-dependent ACPI files,
move the existing ones to a directory to try to keep clutter down in
the arch/arm64/kernel directory.
There is no functional change. This patch only moves source files.
Signed-off-by: Al Stone
---
arch/arm64
From: Al Stone
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new architectures, the
consensus amongst those writing the ACPI specification and those using
it seems to be to ultimately deprecate the use of _OSI. I plan
From: Al Stone
In preparation for adding some additional arch-dependent ACPI files,
move the existing ones to a directory to try to keep clutter down in
the arch/ia64/kernel directory.
There is no functional change. This patch only moves source files.
Signed-off-by: Al Stone
---
arch/ia64
From: Al Stone a...@redhat.com
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
From: Al Stone a...@redhat.com
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
On 01/22/2015 05:44 PM, al.st...@linaro.org wrote:
From: Al Stone a...@redhat.com
[snip]
While I was assuming a couple more passes would be needed, I
didn't expect quite so soon. My apologies, I thought I had
corrected the From lines to say Al Stone al.st...@linaro.org
but I had
From: Al Stone al.st...@linaro.org
The use of the ACPI _OSI method in Linux has a long and sordid history.
Instead of perpetuating past complications on new architectures, the
consensus amongst those writing the ACPI specification and those using
it seems to be to ultimately deprecate the use
From: Al Stone a...@redhat.com
In preparation for adding some additional arch-dependent ACPI files,
move the existing ones to a directory to try to keep clutter down in
the arch/ia64/kernel directory.
There is no functional change. This patch only moves source files.
Signed-off-by: Al Stone
From: Al Stone a...@redhat.com
In preparation for adding some additional arch-dependent ACPI files,
move the existing ones to a directory to try to keep clutter down in
the arch/arm64/kernel directory.
There is no functional change. This patch only moves source files.
Signed-off-by: Al Stone
From: Al Stone a...@redhat.com
Having moved the _OSI callback function needed by ACPICA from
drivers/acpi to arch-dependent locations, we now move all the
remaining _OSI support functions to arch-dependent files.
This patch is much larger than I had wanted it to be; several of the
functions
From: Al Stone a...@redhat.com
In order to deprecate the use of _OSI for arm64 or other new architectures,
we need to make the default handler something we can change for various
platforms. This patch moves the definition of acpi_osi_handler() -- the
function used by ACPICA as a callback
From: Hanjun Guo hanjun@linaro.org
ACPI_OS_NAME is globally defined as Microsoft Windows NT for now.
That doesn't make much sense in the ARM context, so set it to Linux
when CONFIG_ARM64.
If it is necessary to change the return value from \_OS_ (that is, return
some value other than the
On 01/16/2015 08:17 AM, Al Stone wrote:
> On 01/16/2015 03:20 AM, Catalin Marinas wrote:
>> On Thu, Jan 15, 2015 at 09:31:53PM +, Al Stone wrote:
>>> On 01/15/2015 11:23 AM, Catalin Marinas wrote:
>>>> On Thu, Jan 15, 2015 at 04:26:20PM +, Grant Likely wro
On 01/16/2015 03:20 AM, Catalin Marinas wrote:
> On Thu, Jan 15, 2015 at 09:31:53PM +0000, Al Stone wrote:
>> On 01/15/2015 11:23 AM, Catalin Marinas wrote:
>>> On Thu, Jan 15, 2015 at 04:26:20PM +, Grant Likely wrote:
>>>> On Wed, Jan 14, 2015
On 01/16/2015 03:20 AM, Catalin Marinas wrote:
On Thu, Jan 15, 2015 at 09:31:53PM +, Al Stone wrote:
On 01/15/2015 11:23 AM, Catalin Marinas wrote:
On Thu, Jan 15, 2015 at 04:26:20PM +, Grant Likely wrote:
On Wed, Jan 14, 2015 at 3:04 PM, Hanjun Guo hanjun@linaro.org wrote
On 01/16/2015 08:17 AM, Al Stone wrote:
On 01/16/2015 03:20 AM, Catalin Marinas wrote:
On Thu, Jan 15, 2015 at 09:31:53PM +, Al Stone wrote:
On 01/15/2015 11:23 AM, Catalin Marinas wrote:
On Thu, Jan 15, 2015 at 04:26:20PM +, Grant Likely wrote:
On Wed, Jan 14, 2015 at 3:04 PM, Hanjun
comments. One can
also see what these patches will probably look like via one of the
Fedora kernel trees [1].
[0] https://lkml.org/lkml/2014/9/15/1308
[1] https://git.fedorahosted.org/git/kernel-arm64 -- this is
what I run on an AMD Seattle daily driver, btw, and is used
in Fedora 21 as wel
I for my end-users, I have to
maintain both sets of firmware for some unknown time into the future.
Is that what was meant?
I'm not really trying to judge the position right this second, but I
am trying to make sure I understand it. English is not really the most
precise of languages and I wo
precise of languages and I would prefer not to misinterpret.
--
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
://lkml.org/lkml/2014/9/15/1308
[1] https://git.fedorahosted.org/git/kernel-arm64 -- this is
what I run on an AMD Seattle daily driver, btw, and is used
in Fedora 21 as well.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
ff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index fb7b722..f8cc7da 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device,
> int index);
> extern const __be32
(unsigned long pio);
extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
struct device_node *node);
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
the specs can be freely used. As
someone who is part of the ASWG, I'd personally be glad to help out
however I can in this regard.
I'm also curious as to what's being referred to as ACPI support
code for large x86 vendors which is not part of the spec; I *think*
I know what's being d
l the patch is updated, one can find
the specs at the oh so very cleverly named URL:
http://www.uefi.org/specifications
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send
/specifications
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
know what's being described but a specific example would really
help me understand better.
Thanks.
[0] http://www.uefi.org/join
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from
,
we can get ACPI tables from BIOS on ARM64 now.
Signed-off-by: Al Stone
Signed-off-by: Graeme Gregory
Signed-off-by: Hanjun Guo
---
arch/arm64/include/asm/acpi.h | 57 +++
arch/arm64/kernel/setup.c |8 ++
drivers/acpi/Makefile |2 +
drivers/acpi/plat/Makefile
,
we can get ACPI tables from BIOS on ARM64 now.
Signed-off-by: Al Stone al.st...@linaro.org
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
Signed-off-by: Hanjun Guo hanjun@linaro.org
---
arch/arm64/include/asm/acpi.h | 57 +++
arch/arm64/kernel/setup.c |8
501 - 552 of 552 matches
Mail list logo
