From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Date: Tue, 26 Apr 2016 14:35:01 +0100 Message-ID: <20160426133500.GQ27312@arm.com> References: <1461116439-22991-1-git-send-email-ddaney.cavm@gmail.com> <20160425111338.GJ16065@arm.com> <571E4A2A.8070908@caviumnetworks.com> <571EFD1B.1070609@linaro.org> <20160426121547.GL27312@arm.com> <571F671D.70401@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from foss.arm.com ([217.140.101.70]:54600 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751965AbcDZNfH (ORCPT ); Tue, 26 Apr 2016 09:35:07 -0400 Content-Disposition: inline In-Reply-To: <571F671D.70401@linaro.org> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Hanjun Guo Cc: David Daney , David Daney , linux-arm-kernel@lists.infradead.org, Mark Rutland , Catalin Marinas , Tony Luck , Fenghua Yu , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, "Rafael J. Wysocki" , Len Brown , Rob Herring , Frank Rowand , Grant Likely , Robert Moore , Lv Zheng , Marc Zyngier , linux-ia64@vger.kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org, linux-kernel@vger.kernel.org, Robert Richter , David Daney On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote: > On 2016/4/26 20:15, Will Deacon wrote: > >On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote: > >>On 2016/4/26 0:47, David Daney wrote: > >>>On 04/25/2016 04:13 AM, Will Deacon wrote: > >>>>On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: > >>>>>From: David Daney > >>>>> > >>>>>Based on v16 of device-tree NUMA patch set for arm64 [1],this patch > >>>>>set introduce the ACPI based configuration to provide NUMA > >>>>>information. > >>>>> > >>>>>ACPI 5.1 already introduced NUMA support for ARM64, which can get the > >>>>>NUMA domain information from SRAT and SLIT table, so parse those two > >>>>>tables to get mappings from cpu/mem to numa node configuration and > >>>>>system locality. > >>>> > >>>>Whilst I've queued the main NUMA series for arm64, I'd really like to > >>>>see more movement on the generic header file cleanups that you posted > >>>>separately: > >>>> > >>>>http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com > >>>> > >>> > >>>FWIW: Those patches should still apply. I am carrying them in my > >>>development trees, and have not changed them in any way. > > > >What's your plan for getting them merged? > > This patch set touches lots of ACPI related file in arch/x86, > arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be > merged via ACPI tree by Rafael with your ack to ARM64 code, does > it make sense? It doesn't touch anything in drivers/acpi/... are you following the link above? > >>>>Given that this ACPI series already requires some significant cross-arch > >>>>interaction (which is actually good!), perhaps extending the clean-up > >>>>patches to encompass some of the ACPI bits might make sense, and we can > >>>>get that queued as a pre-requisite. > >>> > >>>The cleanup patches you mention above are really independent of the ACPI > >>>things. I have applied them both before and after the ACPI patches, and > >>>both seem to work. With a quick perusal of the ACPI patches nothing > >>>jumps out at me as being a candidate for inclusion in the header file > >>>cleanup series. > >> > >>I agree. My patch set is ACPI related enablement, cleanups and > >>consolidations, it would be good to merge as a single patch set > >>as it's self-contained. > > > >Up to you. I just thought you might want to avoid having two sets of > >cross-arch changes and the associated merging headaches that go with > >that. > > Good point, as I suggested above, it can go with ACPI tree if it's ok > to you and Rafael. The problem we have now is that dt based core NUMA > support for ARM64 is queued in your tree, that would be the headache. Sorry, but if you wanted me *not* to queue the patches, then you should have said so (similarly, if you wanted a stable branch). I'm not rebasing our for-next/core branch now. Will From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Date: Tue, 26 Apr 2016 13:35:01 +0000 Subject: Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Message-Id: <20160426133500.GQ27312@arm.com> List-Id: References: <1461116439-22991-1-git-send-email-ddaney.cavm@gmail.com> <20160425111338.GJ16065@arm.com> <571E4A2A.8070908@caviumnetworks.com> <571EFD1B.1070609@linaro.org> <20160426121547.GL27312@arm.com> <571F671D.70401@linaro.org> In-Reply-To: <571F671D.70401@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Hanjun Guo Cc: David Daney , David Daney , linux-arm-kernel@lists.infradead.org, Mark Rutland , Catalin Marinas , Tony Luck , Fenghua Yu , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, "Rafael J. Wysocki" , Len Brown , Rob Herring , Frank Rowand , Grant Likely , Robert Moore , Lv Zheng , Marc Zyngier , linux-ia64@vger.kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org, linux-kernel@vger.kernel.org, Robert Richter , David Daney On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote: > On 2016/4/26 20:15, Will Deacon wrote: > >On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote: > >>On 2016/4/26 0:47, David Daney wrote: > >>>On 04/25/2016 04:13 AM, Will Deacon wrote: > >>>>On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: > >>>>>From: David Daney > >>>>> > >>>>>Based on v16 of device-tree NUMA patch set for arm64 [1],this patch > >>>>>set introduce the ACPI based configuration to provide NUMA > >>>>>information. > >>>>> > >>>>>ACPI 5.1 already introduced NUMA support for ARM64, which can get the > >>>>>NUMA domain information from SRAT and SLIT table, so parse those two > >>>>>tables to get mappings from cpu/mem to numa node configuration and > >>>>>system locality. > >>>> > >>>>Whilst I've queued the main NUMA series for arm64, I'd really like to > >>>>see more movement on the generic header file cleanups that you posted > >>>>separately: > >>>> > >>>>http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com > >>>> > >>> > >>>FWIW: Those patches should still apply. I am carrying them in my > >>>development trees, and have not changed them in any way. > > > >What's your plan for getting them merged? > > This patch set touches lots of ACPI related file in arch/x86, > arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be > merged via ACPI tree by Rafael with your ack to ARM64 code, does > it make sense? It doesn't touch anything in drivers/acpi/... are you following the link above? > >>>>Given that this ACPI series already requires some significant cross-arch > >>>>interaction (which is actually good!), perhaps extending the clean-up > >>>>patches to encompass some of the ACPI bits might make sense, and we can > >>>>get that queued as a pre-requisite. > >>> > >>>The cleanup patches you mention above are really independent of the ACPI > >>>things. I have applied them both before and after the ACPI patches, and > >>>both seem to work. With a quick perusal of the ACPI patches nothing > >>>jumps out at me as being a candidate for inclusion in the header file > >>>cleanup series. > >> > >>I agree. My patch set is ACPI related enablement, cleanups and > >>consolidations, it would be good to merge as a single patch set > >>as it's self-contained. > > > >Up to you. I just thought you might want to avoid having two sets of > >cross-arch changes and the associated merging headaches that go with > >that. > > Good point, as I suggested above, it can go with ACPI tree if it's ok > to you and Rafael. The problem we have now is that dt based core NUMA > support for ARM64 is queued in your tree, that would be the headache. Sorry, but if you wanted me *not* to queue the patches, then you should have said so (similarly, if you wanted a stable branch). I'm not rebasing our for-next/core branch now. Will From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Tue, 26 Apr 2016 14:35:01 +0100 Subject: [PATCH v5 00/14] ACPI NUMA support for ARM64 In-Reply-To: <571F671D.70401@linaro.org> References: <1461116439-22991-1-git-send-email-ddaney.cavm@gmail.com> <20160425111338.GJ16065@arm.com> <571E4A2A.8070908@caviumnetworks.com> <571EFD1B.1070609@linaro.org> <20160426121547.GL27312@arm.com> <571F671D.70401@linaro.org> Message-ID: <20160426133500.GQ27312@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote: > On 2016/4/26 20:15, Will Deacon wrote: > >On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote: > >>On 2016/4/26 0:47, David Daney wrote: > >>>On 04/25/2016 04:13 AM, Will Deacon wrote: > >>>>On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: > >>>>>From: David Daney > >>>>> > >>>>>Based on v16 of device-tree NUMA patch set for arm64 [1],this patch > >>>>>set introduce the ACPI based configuration to provide NUMA > >>>>>information. > >>>>> > >>>>>ACPI 5.1 already introduced NUMA support for ARM64, which can get the > >>>>>NUMA domain information from SRAT and SLIT table, so parse those two > >>>>>tables to get mappings from cpu/mem to numa node configuration and > >>>>>system locality. > >>>> > >>>>Whilst I've queued the main NUMA series for arm64, I'd really like to > >>>>see more movement on the generic header file cleanups that you posted > >>>>separately: > >>>> > >>>>http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm at gmail.com > >>>> > >>> > >>>FWIW: Those patches should still apply. I am carrying them in my > >>>development trees, and have not changed them in any way. > > > >What's your plan for getting them merged? > > This patch set touches lots of ACPI related file in arch/x86, > arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be > merged via ACPI tree by Rafael with your ack to ARM64 code, does > it make sense? It doesn't touch anything in drivers/acpi/... are you following the link above? > >>>>Given that this ACPI series already requires some significant cross-arch > >>>>interaction (which is actually good!), perhaps extending the clean-up > >>>>patches to encompass some of the ACPI bits might make sense, and we can > >>>>get that queued as a pre-requisite. > >>> > >>>The cleanup patches you mention above are really independent of the ACPI > >>>things. I have applied them both before and after the ACPI patches, and > >>>both seem to work. With a quick perusal of the ACPI patches nothing > >>>jumps out at me as being a candidate for inclusion in the header file > >>>cleanup series. > >> > >>I agree. My patch set is ACPI related enablement, cleanups and > >>consolidations, it would be good to merge as a single patch set > >>as it's self-contained. > > > >Up to you. I just thought you might want to avoid having two sets of > >cross-arch changes and the associated merging headaches that go with > >that. > > Good point, as I suggested above, it can go with ACPI tree if it's ok > to you and Rafael. The problem we have now is that dt based core NUMA > support for ARM64 is queued in your tree, that would be the headache. Sorry, but if you wanted me *not* to queue the patches, then you should have said so (similarly, if you wanted a stable branch). I'm not rebasing our for-next/core branch now. Will