On 18.02.2014 02:02, Rafael J. Wysocki wrote:
On Monday, February 10, 2014 02:00:11 PM Tomasz Nowicki wrote:
Whenever we register ISA interrupt or not, we need to free the IRQ routing
table entry.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/pci_irq.c |1 +
1
On 18.02.2014 16:26, Rafael J. Wysocki wrote:
On Tuesday, February 18, 2014 11:21:39 AM Tomasz Nowicki wrote:
On 18.02.2014 02:02, Rafael J. Wysocki wrote:
On Monday, February 10, 2014 02:00:11 PM Tomasz Nowicki wrote:
Whenever we register ISA interrupt or not, we need to free the IRQ routing
On 15.02.2014 02:05, Rafael J. Wysocki wrote:
On Monday, February 10, 2014 02:00:10 PM Tomasz Nowicki wrote:
This commit enables ISA-specific code if and only if CONFIG_{E}ISA is set
in the kernel configuration so that we do not have to maintain
acpi_isa_irq_to_gsi() function
This commit moves ISA-specific code to separate function and makes that
function depend on CONFIG_{E}ISA so that we do not have to maintain
acpi_isa_irq_to_gsi() function for architectures which do not support ISA.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi
On 19.02.2014 17:11, Rafael J. Wysocki wrote:
On Wednesday, February 19, 2014 11:35:22 AM Tomasz Nowicki wrote:
This commit moves ISA-specific code to separate function and makes that
function depend on CONFIG_{E}ISA so that we do not have to maintain
acpi_isa_irq_to_gsi() function
This commit moves ISA-specific code to separate function and makes that
function depend on CONFIG_{E}ISA so that we do not have to maintain
acpi_isa_irq_to_gsi() function for architectures which do not support ISA.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi
This commit enables ISA-specific code if and only if CONFIG_{E}ISA is set
in the kernel configuration so that we do not have to maintain
acpi_isa_irq_to_gsi() function for architectures which do not support ISA.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/pci_irq.c
Whenever we register ISA interrupt or not, we need to free the IRQ routing
table entry.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/pci_irq.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index b0e31b6..6ec0f36
ACPI_APEI is already dependent on X86, hence, there is no need to
define such dependency for ACPI_APEI_GHES again.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/apei/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/apei
Hi,
I would like to kindly remind and request for comments on this patches.
Regards,
Tomasz
On 28.05.2014 09:39, Tomasz Nowicki wrote:
APEI is currently implemented so that it depends on x86 hardware.
The primary dependency is that GHES uses the x86 NMI for hardware
error notification and MCE
On 12.06.2014 12:23, Robert Richter wrote:
On 28.05.14 09:39:26, Tomasz Nowicki wrote:
This commit abstracts MCE calls and provides weak corresponding default
implementation for those architectures which do not need arch specific
actions. Each platform willing to do additional architectural
On 12.06.2014 12:32, Robert Richter wrote:
On 28.05.14 09:39:27, Tomasz Nowicki wrote:
+config ACPI_APEI_NMI
+ bool NMI error notification support
+ default y
+ depends on ACPI_APEI_GHES X86
+ help
+ Firmware first mode can use NMI notification mechanism
in ghes_notify_tab and call it with ghes argument.
This approach allows us to change address of a given error notification
init/deinit function call in ghes_notify_tab in runtime. In turn,
we will avoid #ifdef usage in common code for NMI which is currently
supported by x86.
Signed-off-by: Tomasz Nowicki
- address Robert's comment
- disable ACPI_APEI_NMI selection so that it is hard selected by arch Kconfig
- rename ACPI_APEI_NMI to ARCH_HAS_ACPI_APEI_NMI
Tomasz Nowicki (5):
apei, mce: Factor out APEI architecture specific MCE calls.
acpi, apei, ghes: Introduce ARCH_HAS_ACPI_APEI_NMI to make NMI error
context page is second. Then, use ARCH_HAS_ACPI_APEI_NMI to decide
at runtime how many pages are to be allocated. Finally, put in
sanity checks to avoid accessing unallocated memory.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/kernel/acpi/apei.c |6 ++
drivers/acpi
patches
for NMI related code isolation in ghes.c file. Only NMI error notification
feature depends on x86 so let it be hard selected for x86 arch.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/Kconfig |1 +
drivers/acpi/apei/Kconfig |8 +++-
2 files
Similar to MCE related patch, all NMI architectural calls are abstracted.
Also, we are providing corresponding X86 functions' content.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/kernel/acpi/apei.c | 25 +
drivers/acpi/apei/apei-base.c | 19
into #ifdef in generic code and prevent new platform from introducing
dummy stub function too.
Initially, there are two APEI arch-specific calls:
- apei_arch_enable_cmcff()
- apei_arch_report_mem_error()
Both interact with MCE driver for X86 architecture.
Signed-off-by: Tomasz Nowicki tomasz.nowi
On 13.05.2014 20:13, Borislav Petkov wrote:
On Wed, Apr 09, 2014 at 05:14:30PM +0200, Tomasz Nowicki wrote:
Init/deinit of GHES error notifications are moved to corresponding
functions e.g. for SCI ghes_notify_init_sci{sci} and ghes_notify_remove_{sci}
which in turn are gathered
On 13.05.2014 21:41, Borislav Petkov wrote:
On Wed, Apr 09, 2014 at 05:14:32PM +0200, Tomasz Nowicki wrote:
Use CONFIG_ACPI_APEI_NMI to isolate NMI error notification path. NMI related
data and functions are grouped so they can be wrapped inside one
I have missed end of sentence. I should goes
On 23.05.2014 18:48, Borislav Petkov wrote:
On Fri, May 23, 2014 at 02:06:47PM +0200, Tomasz Nowicki wrote:
I had that thoughts too. Looking at simple MCE calls, yes, it does
make sense to create corresponding arch-specific version and provide
logic as needed. I think that NMI is much more
On 26.05.2014 15:45, Borislav Petkov wrote:
On Mon, May 26, 2014 at 03:26:06PM +0200, Tomasz Nowicki wrote:
Now I do follow :) Nicely done, I have applied your patch and indeed
there are more arch dependencies for !X86.
Not nicely enough, I guess :-)
diff --git a/arch/x86/include/asm/nmi.h
into #ifdef in generic code and prevent new platform from introducing
dummy stub function too.
Initially, there are two APEI arch-specific calls:
- apei_arch_enable_cmcff()
- apei_arch_report_mem_error()
Both interact with MCE driver for X86 architecture.
Signed-off-by: Tomasz Nowicki tomasz.nowi
in ghes_notify_tab and call it with ghes argument.
This approach allows us to change address of a given error notification
init/deinit function call in ghes_notify_tab in runtime. In turn,
we will avoid #ifdef usage in common code for NMI which is currently
supported by x86.
Signed-off-by: Tomasz Nowicki
context page is second. Then, use CONFIG_ACPI_APEI_NMI to decide
at runtime how many pages are to be allocated. Finally, put in
sanity checks to avoid accessing unallocated memory.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/kernel/acpi/apei.c |6 ++
drivers/acpi
Similar to MCE related patch, all NMI architectural calls are abstracted.
Also, we are providing corresponding X86 functions' content.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/kernel/acpi/apei.c | 25 +
drivers/acpi/apei/apei-base.c | 19
to isolate
NMI related code in ghes.c file. Only NMI error notification feature
depends on x86 and it is selected by default for x86 arch.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/apei/Kconfig | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff
introduce no functional changes for x86. The NMI
notification
feature is selected for x86 by default. Architectures that want to use this
feature should also provide NMI code infrastructure.
V1-V2
- address Borislav comment
- abstract arch-specific calls instead of wrapping into the #ifdef
Tomasz
On 13.05.2014 22:11, Borislav Petkov wrote:
On Wed, Apr 09, 2014 at 05:14:34PM +0200, Tomasz Nowicki wrote:
Till now __flush_tlb_one was used for unmapping virtual memory which
is x86 specific function. Replace it with more generic
flush_tlb_kernel_range.
Signed-off-by: Tomasz Nowicki
On 14.05.2014 14:48, Will Deacon wrote:
On Wed, May 14, 2014 at 01:45:07PM +0100, Catalin Marinas wrote:
On Wed, May 14, 2014 at 01:35:42PM +0100, Will Deacon wrote:
On Wed, May 14, 2014 at 01:32:27PM +0100, Tomasz Nowicki wrote:
On 13.05.2014 22:11, Borislav Petkov wrote:
On Wed, Apr 09
Hi Lorenzo,
W dniu 22.01.2014 12:54, Lorenzo Pieralisi pisze:
On Fri, Jan 17, 2014 at 12:24:58PM +, Hanjun Guo wrote:
[...]
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index bd9bbd0..2210353 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@
Hi Lorenzo,
W dniu 24.01.2014 13:53, Lorenzo Pieralisi pisze:
Hi Hanjun,
On Fri, Jan 24, 2014 at 09:09:40AM +, Hanjun Guo wrote:
On 2014?01?23? 23:56, Tomasz Nowicki wrote:
Hi Lorenzo,
W dniu 22.01.2014 12:54, Lorenzo Pieralisi pisze:
On Fri, Jan 17, 2014 at 12:24:58PM +, Hanjun
On 01/17/14 15:15, Arnd Bergmann wrote:
On Friday 17 January 2014, Hanjun Guo wrote:
+/* Parked Address in ACPI GIC structure */
+static u64 parked_address[NR_CPUS];
Please use the per_cpu infrastructure rather than NR_CPUS long arrays.
Actually, per_cpu areas are initialized a bit later. If
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
Hi,
Currently APEI depends on x86 architecture. It is because of many x86
specific features like IA-32 Architecture Corrected Machine Check
error source or NMI hardware error notification. However, many other
features like PCI Express Device AER Structure or GHES via external
interrupt can
On 03/26/14 16:10, Mauro Carvalho Chehab wrote:
Em Wed, 26 Mar 2014 15:55:07 +0100
Rafael J. Wysocki r...@rjwysocki.net escreveu:
On Wednesday, March 26, 2014 01:08:10 PM Tomasz Nowicki wrote:
Hi,
Hi,
This is a question for Tony, Boris and Mauro (CCed now).
Currently APEI depends on x86
On 03/26/14 21:36, Borislav Petkov wrote:
On Wed, Mar 26, 2014 at 12:10:47PM -0300, Mauro Carvalho Chehab wrote:
Yet, it would be better if you could be a little more specific about
what are your plans and what are the common/not-common features that
you're mapping.
Well, I don't see anything
Hi,
I would like to kindly remind and request for some comments on this patches.
Regards,
Tomasz
On 09.04.2014 17:14, Tomasz Nowicki wrote:
APEI is currently implemented so that it depends on x86 hardware.
The primary dependency is that GHES uses the x86 NMI for hardware
error notification
On 05.05.2014 13:44, Borislav Petkov wrote:
On Wed, Apr 09, 2014 at 05:14:29PM +0200, Tomasz Nowicki wrote:
This commit is dealing with MCE code in:
- hest.c
Move acpi_disable_cmcff flag to hest_parse_cmc() and makes
that depend on CONFIG_X86_MCE so that we do not have to maintain
On 05.05.2014 16:53, Borislav Petkov wrote:
On Mon, May 05, 2014 at 04:34:41PM +0200, Tomasz Nowicki wrote:
acpi_disable_cmcff as global value can switch off/on MC entries
analysing via kernel args.
No, it switches off firmware first mode for correctable errors because
of buggy BIOSes
On 05.05.2014 17:33, Borislav Petkov wrote:
On Mon, May 05, 2014 at 05:32:07PM +0200, Tomasz Nowicki wrote:
You are right! I will fix that big misunderstanding from my side in
next patch version.
Ok, but pls wait with resubmitting until I take a look at the rest of
your patches.
Sure, I
Use CONFIG_ACPI_APEI_NMI to isolate NMI error notification path. NMI related
data and functions are grouped so they can be wrapped inside one
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/apei/ghes.c | 54 +-
1 file changed
Thanks to more generic way of init/deinit error notification, we can
register NMI related calls in runtime. It happens before walking through
GHES entries, so probe function will treat NMI as supported.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/apei/ghes.c | 21
Till now __flush_tlb_one was used for unmapping virtual memory which
is x86 specific function. Replace it with more generic
flush_tlb_kernel_range.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/apei/ghes.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions
context page is second. Then, use CONFIG_ACPI_APEI_NMI to decide
at runtime how many pages are to be allocated. Finally, put in
sanity checks to avoid accessing unallocated memory.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/apei/ghes.c | 14 --
1 file
in ghes_notify_tab and call it with ghes argument.
This approach allows us to change address of a given error notification
init/deinit function call in ghes_notify_tab in runtime. In turn,
we can avoid #ifdef usage in common code e.g. for NMI which is currently
supported by x86.
Signed-off-by: Tomasz
to isolate
NMI related code in ghes.c file. Only NMI error notification feature
depends on x86 and it is selected by default for x86 arch.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/apei/Kconfig | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff
infrastructure.
Tomasz Nowicki (7):
apei, mce: Call MCE-specific code only for X86 architecture.
acpi, apei, ghes: Introduce more generic mechanism to init/deinit
GHES error notifications.
ACPI, APEI, GHES: Introduce ACPI_NMI to make NMI error notification a
GHES feature.
acpi, apei
CONFIG_X86_MCE.
- ghes.c
Wrap architectural MCE header inside #ifdef CONFIG_X86_MCE similar to rest
of the MCE code in this file.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/apei/ghes.c |2 ++
drivers/acpi/apei/hest.c |8 ++--
2 files changed, 8 insertions(+), 2
On 19.06.2014 16:27, Borislav Petkov wrote:
On Fri, Jun 13, 2014 at 01:02:57PM +0200, Tomasz Nowicki wrote:
Currently APEI depends on x86 architecture. It is because of NMI hardware
error notification of GHES which is currently supported by x86 only.
However, many other APEI features can
On 19.06.2014 16:17, Borislav Petkov wrote:
On Fri, Jun 13, 2014 at 01:02:56PM +0200, Tomasz Nowicki wrote:
This commit abstracts MCE calls and provides weak corresponding default
implementation for those architectures which do not need arch specific
actions. Each platform willing to do
On 13.06.2014 15:10, Robert Richter wrote:
On 13.06.14 13:02:58, Tomasz Nowicki wrote:
@@ -811,6 +819,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs
*regs)
int sev, sev_global = -1;
int ret = NMI_DONE;
+ BUG_ON(!IS_ENABLED(ARCH_HAS_ACPI_APEI_NMI
into #ifdef in generic code and prevent new platform from introducing
dummy stub function too.
Initially, there are two APEI arch-specific calls:
- arch_apei_enable_cmcff()
- arch_apei_report_mem_error()
Both interact with MCE driver for X86 architecture.
Signed-off-by: Tomasz Nowicki tomasz.nowi
, and the optional
NMI context page is second. Then, use HAVE_ACPI_APEI_NMI to decide
how many pages are to be allocated.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/kernel/acpi/apei.c |6 ++
drivers/acpi/apei/ghes.c| 18 +++---
include/acpi/apei.h
- disable ACPI_APEI_NMI selection so that it is hard selected by arch Kconfig
- rename ACPI_APEI_NMI to ARCH_HAS_ACPI_APEI_NMI
V3-V4
- do not abstract NMI calls for archs which do not support it
- merge some of patches to make review process easier
Tomasz Nowicki (3):
apei, mce: Factor out APEI
to hard selected
HAVE_ACPI_APEI and HAVE_ACPI_APEI_NMI symbols.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/Kconfig |2 +
drivers/acpi/apei/Kconfig |8 ++-
drivers/acpi/apei/ghes.c | 149 +
include/linux/nmi.h
, and the optional
NMI context page is second. Then, use HAVE_ACPI_APEI_NMI to decide
how many pages are to be allocated.
Acked-by: Borislav Petkov b...@suse.de
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/kernel/acpi/apei.c | 6 ++
drivers/acpi/apei/ghes.c| 18
to hard selected
HAVE_ACPI_APEI and HAVE_ACPI_APEI_NMI symbols.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/Kconfig | 2 +
drivers/acpi/apei/Kconfig | 8 ++-
drivers/acpi/apei/ghes.c | 149 ++
include/linux/nmi.h
, #endif) around long code block
Tomasz Nowicki (3):
apei, mce: Factor out APEI architecture specific MCE calls.
acpi, apei, ghes: Make NMI error notification to be GHES architecture
extension.
acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI
context.
arch/x86
-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/kernel/acpi/Makefile | 1 +
arch/x86/kernel/acpi/apei.c | 56 +++
drivers/acpi/apei/apei-base.c | 13 ++
drivers/acpi/apei/ghes.c | 6 ++---
drivers/acpi/apei/hest.c | 29
Many thanks Tony! And thanks goes to Borislav and Robert too.
Regards,
Tomasz
On 22.07.2014 23:08, Tony Luck wrote:
On Tue, Jul 22, 2014 at 2:20 AM, Tomasz Nowicki
tomasz.nowi...@linaro.org wrote:
APEI is currently implemented so that it depends on x86 hardware.
The primary dependency
On 02.07.2014 14:16, Borislav Petkov wrote:
On Tue, Jun 24, 2014 at 01:41:34PM +0200, Tomasz Nowicki wrote:
Currently APEI depends on x86 architecture. It is because of NMI hardware
error notification of GHES which is currently supported by x86 only.
However, many other APEI features can
instance is still required in DSDT
table along with _AEI resources and event methods.
Please, see Kconfig help and driver head section for more details
regarding tool usage.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/Kconfig | 10 ++
drivers/acpi/Makefile
Hi Mika,
On 21.08.2014 12:45, Mika Westerberg wrote:
On Wed, Aug 20, 2014 at 04:58:20PM +0200, Tomasz Nowicki wrote:
GPIO-signaled events is quite new thing in Linux kernel.
There are not many board which can take advantage of it.
However, GPIO events are very useful feature during work
On 21.08.2014 16:54, Mika Westerberg wrote:
On Thu, Aug 21, 2014 at 04:39:46PM +0200, Tomasz Nowicki wrote:
+{
+ struct gpio_pin_data *pin_data, *temp;
+
+ list_for_each_entry_safe(pin_data, temp, pin_data_list, list)
+ kfree(pin_data);
I suppose you want to first
method corresponding to device pin number:
$ echo /__SB.GPI0 0x100 /sys/kernel/debug/acpi/gpio_event
Please, see Kconfig help and driver head section for more details
regarding tool usage.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
drivers/acpi/Kconfig| 11 +++
drivers
On 08.08.2014 14:36, Linus Walleij wrote:
On Thu, Jul 24, 2014 at 5:51 PM, Tomasz Nowicki
tomasz.nowi...@linaro.org wrote:
GPIO signaled events is quite new thing in Linux kernel.
AFAIK, there are not many board which can take advantage of it.
However, GPIO events are very useful feature
On 12.08.2014 12:01, Mika Westerberg wrote:
On Fri, Aug 08, 2014 at 02:36:02PM +0200, Linus Walleij wrote:
On Thu, Jul 24, 2014 at 5:51 PM, Tomasz Nowicki
tomasz.nowi...@linaro.org wrote:
GPIO signaled events is quite new thing in Linux kernel.
AFAIK, there are not many board which can take
On 12.08.2014 16:15, Alexandre Courbot wrote:
On Tue, Aug 12, 2014 at 3:01 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Fri, Aug 08, 2014 at 02:36:02PM +0200, Linus Walleij wrote:
On Thu, Jul 24, 2014 at 5:51 PM, Tomasz Nowicki
tomasz.nowi...@linaro.org wrote:
GPIO signaled
On 03.09.2014 16:57, Arnd Bergmann wrote:
On Wednesday 03 September 2014 11:26:14 Tomasz Nowicki wrote:
On 02.09.2014 15:02, Marc Zyngier wrote:
On 02/09/14 12:48, Tomasz Nowicki wrote:
On 01.09.2014 19:35, Marc Zyngier wrote:
@@ -78,6 +79,10 @@ void __init set_handle_irq(void (*handle_irq
On 05.09.2014 12:13, Arnd Bergmann wrote:
On Friday 05 September 2014 10:47:30 Marc Zyngier wrote:
I still prefer being explicit here for the same reason I mentioned earlier:
I want it to be very clear that we don't support arbitrary irqchips other
than the ones in the APCI specification.
On 05.09.2014 12:39, Marc Zyngier wrote:
On 05/09/14 11:13, Arnd Bergmann wrote:
On Friday 05 September 2014 10:47:30 Marc Zyngier wrote:
I still prefer being explicit here for the same reason I mentioned earlier:
I want it to be very clear that we don't support arbitrary irqchips other
On 26.08.2014 00:39, Rafael J. Wysocki wrote:
On Thursday, August 21, 2014 04:39:46 PM Tomasz Nowicki wrote:
Hi Mika,
On 21.08.2014 12:45, Mika Westerberg wrote:
On Wed, Aug 20, 2014 at 04:58:20PM +0200, Tomasz Nowicki wrote:
[cut]
+
+static int gpio_evt_trigger(void *data, u64 val
MMCFG table seems to be architecture independent and it makes sense
to share common code across all architectures. The ones that may need
architectural specific actions have default prototype (__weak).
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
Tested-by: Hanjun Guo hanjun
MMCFG ACPI table has no arch dependencies so it can be used across all
architectures. Currently MMCONFIG related code resides in arch/x86 directories.
This patch set is goint to isolate non-architecure specific code and make
it accessible from drivers/pci/ directory.
Tomasz Nowicki (6):
x86
Note that x86 32bits machines still have its own low-level direct
PCI config space accessors.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/pci/Makefile | 5 +-
arch/x86/pci/mmconfig_64.c | 152 -
drivers/acpi/mmconfig.c
-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
Tested-by: Hanjun Guo hanjun@linaro.org
---
arch/x86/include/asm/pci.h | 42 +
arch/x86/include/asm/pci_x86.h | 43 --
2 files changed, 42 insertions(+), 43
MMCFG can be used perfectly for all architectures which support ACPI.
ACPI mandates MMCFG to describe PCI config space ranges which means
we should use MMCONFIG accessors by default.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
Tested-by: Hanjun Guo hanjun@linaro.org
---
drivers
.
Move it to mmconfig_shared.c so it becomes common for both and
mmconfig_64.c turns out to be purely arch agnostic.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
Tested-by: Hanjun Guo hanjun@linaro.org
---
arch/x86/pci/mmconfig-shared.c | 10 --
arch/x86/pci/mmconfig_32.c
as the final stage in separate
function (candidate for further factoring)
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
Tested-by: Hanjun Guo hanjun@linaro.org
---
arch/x86/pci/mmconfig-shared.c | 100 ++---
1 file changed, 54 insertions(+), 46 deletions
On 19.11.2014 17:19, Arnd Bergmann wrote:
On Wednesday 19 November 2014 17:04:51 Tomasz Nowicki wrote:
+/*
+ * raw_pci_read/write - ACPI PCI config space accessors.
+ *
+ * ACPI spec defines MMCFG as the way we can access PCI config space,
+ * so let MMCFG be default (__weak
On 17.11.2014 15:13, Arnd Bergmann wrote:
On Monday 17 November 2014 18:21:34 Yijing Wang wrote:
This series is based Linux 3.18-rc1 and Lorenzo Pieralisi's
arm PCI domain cleanup patches, link:
https://patchwork.ozlabs.org/patch/407585/
Current pci scan interfaces like pci_scan_root_bus() and
On 18.11.2014 13:27, Arnd Bergmann wrote:
On Tuesday 18 November 2014 20:17:57 Yijing Wang wrote:
I hope platforms with ACPI or DT could both use pci_create_host_bridge().
Why we need to use two different ways to process it ?
These are completely different use cases:
a) For DT, we want
On 20.11.2014 13:08, Liviu Dudau wrote:
On Thu, Nov 20, 2014 at 12:54:48PM +0100, Tomasz Nowicki wrote:
On 17.11.2014 15:13, Arnd Bergmann wrote:
On Monday 17 November 2014 18:21:34 Yijing Wang wrote:
This series is based Linux 3.18-rc1 and Lorenzo Pieralisi's
arm PCI domain cleanup patches
On 01.09.2014 19:35, Marc Zyngier wrote:
On 01/09/14 15:57, Hanjun Guo wrote:
From: Tomasz Nowicki tomasz.nowi...@linaro.org
ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC related subtables, collect CPU interface and distributor
addresses and call driver
On 02.09.2014 15:02, Marc Zyngier wrote:
On 02/09/14 12:48, Tomasz Nowicki wrote:
On 01.09.2014 19:35, Marc Zyngier wrote:
On 01/09/14 15:57, Hanjun Guo wrote:
From: Tomasz Nowicki tomasz.nowi...@linaro.org
ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC
On 03.09.2014 20:42, Arnd Bergmann wrote:
On Monday 01 September 2014 22:57:51 Hanjun Guo wrote:
+ /* Collect CPU base addresses */
+ count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+ gic_acpi_parse_madt_cpu, table,
+
On 04.09.2014 12:14, Arnd Bergmann wrote:
On Thursday 04 September 2014 12:10:28 Tomasz Nowicki wrote:
On 03.09.2014 20:42, Arnd Bergmann wrote:
On Monday 01 September 2014 22:57:51 Hanjun Guo wrote:
+ /* Collect CPU base addresses */
+ count = acpi_parse_entries(sizeof(struct
On 24.11.2014 02:45, Rafael J. Wysocki wrote:
On Friday, October 17, 2014 09:36:59 PM Hanjun Guo wrote:
From: Tomasz Nowicki tomasz.nowi...@linaro.org
It is very useful to traverse all available table entries without max
number of expected entries type. Current acpi_parse_entries
On 24.11.2014 16:37, Rafael J. Wysocki wrote:
On Monday, November 24, 2014 04:01:24 PM Tomasz Nowicki wrote:
On 24.11.2014 16:16, Rafael J. Wysocki wrote:
On Monday, November 24, 2014 09:34:24 AM Tomasz Nowicki wrote:
On 24.11.2014 02:45, Rafael J. Wysocki wrote:
On Friday, October 17, 2014
On 24.11.2014 16:16, Rafael J. Wysocki wrote:
On Monday, November 24, 2014 09:34:24 AM Tomasz Nowicki wrote:
On 24.11.2014 02:45, Rafael J. Wysocki wrote:
On Friday, October 17, 2014 09:36:59 PM Hanjun Guo wrote:
From: Tomasz Nowicki tomasz.nowi...@linaro.org
It is very useful to traverse
On 15.09.2014 18:42, Catalin Marinas wrote:
On Mon, Sep 15, 2014 at 05:16:21PM +0100, Jon Masters wrote:
On 09/15/2014 11:01 AM, Catalin Marinas wrote:
On Fri, Sep 12, 2014 at 03:00:12PM +0100, Hanjun Guo wrote:
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index
W dniu 07.11.2014 o 15:55, Liviu Dudau pisze:
On Fri, Nov 07, 2014 at 01:27:56PM +, Tomasz Nowicki wrote:
Code inspired by arch/x86/pci/acpi.c and arch/ia64/pci/pci.c files.
The main reasons why we need this:
- parse and manage resources (BUS, IO and MEM)
- create pci root bus and enumerate
On 07.11.2014 15:24, Arnd Bergmann wrote:
On Friday 07 November 2014 14:27:56 Tomasz Nowicki wrote:
#ifdef CONFIG_PCI
+struct pci_controller {
+ struct acpi_device *companion;
+ int segment;
+ int node; /* nearest node with memory or NUMA_NO_NODE for
global
ARM64 core set:
http://www.serverphorums.com/read.php?12,997228
Tomasz Nowicki (4):
x86, acpi, pci: Move arch-agnostic MMCFG code out of arch/x86/
directory.
x86, acpi, pci: Isolate new PCI mmconfig entry insertion.
arm64, acpi, pci: Add arch specific functions for mmconfig driver.
arm64
Code inspired by arch/x86/pci/acpi.c and arch/ia64/pci/pci.c files.
The main reasons why we need this:
- parse and manage resources (BUS, IO and MEM)
- create pci root bus and enumerate its children
- provide PCI config space accessors (via MMCONFIG)
Signed-off-by: Tomasz Nowicki tomasz.nowi
Add special pci_mmcfg_insert_lock mutex since pci_mmcfg_lock was moved
to common file. No functional changes.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/x86/pci/mmconfig-shared.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/pci
These calls allow to map/unmap PCI config space ranges (which are specified in
MMCFG ACPI table).
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
---
arch/arm64/Kconfig | 3 ++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/mmconfig.c | 69
MMCFG table seems to be architecture independent and it makes sense
to share common code across all architectures. The ones that may need
architectural specific actions have default prototype (__weak).
Please note, there is not functional changes in this patch.
Signed-off-by: Tomasz Nowicki
On 07.11.2014 15:09, Arnd Bergmann wrote:
On Friday 07 November 2014 14:27:54 Tomasz Nowicki wrote:
Add special pci_mmcfg_insert_lock mutex since pci_mmcfg_lock was moved
to common file. No functional changes.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
What is the new lock
1 - 100 of 1330 matches
Mail list logo
