Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

2015-12-22 Thread Hanjun Guo
On 2015/12/21 22:27, Will Deacon wrote: Mark, On Fri, Dec 18, 2015 at 06:03:47PM +, Mark Rutland wrote: On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote: Hi Mark, On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland wrote: +- distance-matrix + This property defines a matrix

Re: [PATCH v2] EDAC: Add ARM64 EDAC

2015-10-23 Thread Hanjun Guo
On 2015/10/24 1:58, Brijesh Singh wrote: >> So I checked the x86 code: the driver is always loaded as soon as the >> hardware is there (looking at PCI device IDs from the on-chip >> northbridge, for instance). The trick here is to have the Kconfig option >> defaulting to "=n", so a kernel builder w

Re: [PATCH v2] EDAC: Add ARM64 EDAC

2015-10-22 Thread Hanjun Guo
Hi Brijesh, On 2015/10/22 22:46, Brijesh Singh wrote: > Hi Andre, > > On 10/21/2015 06:52 PM, Andre Przywara wrote: >> On 21/10/15 21:41, Brijesh Singh wrote: >>> Add support for Cortex A57 and A53 EDAC driver. >> Hi Brijesh, >> >> thanks for the quick update! Some comments below. >> >>> Signed-of

Re: [PATCH] EDAC: Add AMD Seattle SoC EDAC

2015-10-22 Thread Hanjun Guo
On 2015/10/21 17:35, Borislav Petkov wrote: > On Wed, Oct 21, 2015 at 09:55:43AM +0800, Hanjun Guo wrote: >> So I think the meaning of those error register is the same, but the way >> of handle it may different from SoCs, for single bit error: >> >> - SoC may trigger

Re: [PATCH] EDAC: Add AMD Seattle SoC EDAC

2015-10-20 Thread Hanjun Guo
Hi Boris, Mark, On 2015/10/21 1:36, Borislav Petkov wrote: > On Tue, Oct 20, 2015 at 06:26:55PM +0100, Mark Rutland wrote: >>> Btw, how much of this is implementing generic A57 functionality? >> The driver is entirely A57 generic. >> >>> If a lot, can we make this a generic a57_edac driver so that

Re: [PATCH] EDAC: Add AMD Seattle SoC EDAC

2015-10-20 Thread Hanjun Guo
On 2015/10/21 1:25, Mark Rutland wrote: > On Tue, Oct 20, 2015 at 11:44:46AM -0500, Brijesh Singh wrote: >> Hi Mark, >> >> Thanks for review. >> >> -Brijesh >> >> On 10/19/2015 03:52 PM, Mark Rutland wrote: >>> Hi, >>> >>> Please Cc the devicetree list (devicetree@vger.kernel.org) when sending >>>

Re: [PATCH v5 2/4] Documentation: arm64/arm: dt bindings for numa.

2015-10-14 Thread Hanjun Guo
On 10/14/2015 12:47 AM, Mark Rutland wrote: Hi Mark, i am thinking, if we could not address(or becomes complex) these topologies using associativity, we should think of an alternate binding which suits existing and upcoming arm64 platforms. can we think of below numa binding which is inline wit

Re: [PATCH v5 2/4] Documentation: arm64/arm: dt bindings for numa.

2015-09-08 Thread Hanjun Guo
Hi Ganapatrao, On 08/29/2015 10:56 PM, Ganapatrao Kulkarni wrote: Hi Thunder, On Sat, Aug 29, 2015 at 3:16 PM, Leizhen (ThunderTown) wrote: On 2015/8/28 22:02, Rob Herring wrote: +benh On Fri, Aug 28, 2015 at 7:32 AM, Mark Rutland wrote: Hi, On Fri, Aug 14, 2015 at 05:39:32PM +0100, Ga

Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c

2015-08-27 Thread Hanjun Guo
On 08/27/2015 08:28 PM, Hanjun Guo wrote: On 08/27/2015 08:08 PM, Thomas Gleixner wrote: On Thu, 27 Aug 2015, Hanjun Guo wrote: On 08/26/2015 03:17 AM, Thomas Gleixner wrote: On Wed, 26 Aug 2015, Fu Wei wrote: /* Initialize per-processor generic timer */ -static int __init

Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c

2015-08-27 Thread Hanjun Guo
On 08/27/2015 08:08 PM, Thomas Gleixner wrote: On Thu, 27 Aug 2015, Hanjun Guo wrote: On 08/26/2015 03:17 AM, Thomas Gleixner wrote: On Wed, 26 Aug 2015, Fu Wei wrote: /* Initialize per-processor generic timer */ -static int __init arch_timer_acpi_init(struct acpi_table_header *table

Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c

2015-08-27 Thread Hanjun Guo
Hi Thomas, Thanks for the comments, I got some questions and reply below. On 08/26/2015 03:17 AM, Thomas Gleixner wrote: On Wed, 26 Aug 2015, Fu Wei wrote: /* Initialize per-processor generic timer */ -static int __init arch_timer_acpi_init(struct acpi_table_header *table) +void __init arch_

Re: [PATCH non-pretimeout 5/7] ACPI: add GTDT table parse driver into ACPI driver

2015-06-11 Thread Hanjun Guo
operating system to obtain device data from the resource of platform device. The platform device named "sbsa-gwdt" can be used by the ARM SBSA Generic Watchdog driver. Signed-off-by: Fu Wei Signed-off-by: Hanjun Guo --- drivers/acpi/Kconfig | 9 drivers/acpi/Makefile | 1 + dr

Re: [PATCH v3 6/6] ACPI: import watchdog info of GTDT into platform device

2015-05-26 Thread Hanjun Guo
On 2015年05月27日 00:35, Timur Tabi wrote: On 05/26/2015 03:28 AM, Hanjun Guo wrote: early_acpi_os_unmap_memory((char *)table, tbl_size); } please add #ifdef CONFIG_ARM_SBSA_WATCHDOG (acpi gtdt code) #endif I don't agree with this. The GTDT should be parsed even if there

Re: [PATCH v3 6/6] ACPI: import watchdog info of GTDT into platform device

2015-05-26 Thread Hanjun Guo
err = platform_device_add(pdev); ... + if (err) + goto err_free_res; + + return 0; How about if (!err) return 0; then no need for goto err_free_res and save two lines of codes. Other than that, Acked-by: Hanjun Guo Thanks Hanjun -- To unsubscribe fr

Re: [PATCH v2 7/7] ACPI: import watchdog info of GTDT into platform device

2015-05-22 Thread Hanjun Guo
+CC Catalin and Will On 2015年05月21日 16:32, fu@linaro.org wrote: From: Fu Wei Parse SBSA Generic Watchdog Structure in GTDT table of ACPI, and create a platform device with that information. This platform device can be used by the ARM SBSA Generic Watchdog driver. Signed-off-by: Fu Wei --

Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver

2015-05-22 Thread Hanjun Guo
On 2015年05月22日 23:01, Guenter Roeck wrote: On Fri, May 22, 2015 at 04:55:04PM +0200, Arnd Bergmann wrote: On Friday 22 May 2015 22:50:30 Hanjun Guo wrote: diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index e5e7c55..25a0df1 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers

Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver

2015-05-22 Thread Hanjun Guo
On 2015年05月21日 16:32, fu@linaro.org wrote: From: Fu Wei This driver bases on linux kernel watchdog framework, and use "pretimeout" in the framework. It supports getting timeout and pretimeout from parameter and FDT at the driver init stage. In first timeout(WS0), the interrupt routine run p

Re: [PATCH v2 1/7] clocksource: export "arch_timer_get_rate" for the other drivers

2015-05-22 Thread Hanjun Guo
needed. Signed-off-by: Fu Wei Other than that, Acked-by: Hanjun Guo --- drivers/clocksource/arm_arch_timer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 0aa135d..4327bf9 100644 --- a/drivers

Re: [RFC PATCH v4 4/4] arm64:numa: adding numa support for arm64 platforms.

2015-02-27 Thread Hanjun Guo
Hi Ganapatrao, On 2015年01月22日 19:05, Ganapatrao Kulkarni wrote: Adding numa support for arm64 based platforms. Adding dt node pasring for numa topology using property arm,associativity. Signed-off-by: Ganapatrao Kulkarni --- arch/arm64/Kconfig | 32 +++ arch/arm64/include/asm/

Re: [RFC PATCH v2 2/4] Documentation: arm64/arm: dt bindings for numa.

2014-12-14 Thread Hanjun Guo
On 2014年12月12日 22:20, Arnd Bergmann wrote: On Thursday 11 December 2014 17:16:35 Hanjun Guo wrote: On 2014年12月10日 18:57, Arnd Bergmann wrote: On Wednesday 26 November 2014 17:12:49 Hanjun Guo wrote: The above topology is not easy to represent, but I think it would work like this (ignoring the

Re: [RFC PATCH v2 2/4] Documentation: arm64/arm: dt bindings for numa.

2014-12-11 Thread Hanjun Guo
Hi Arnd, On 2014年12月10日 18:57, Arnd Bergmann wrote: On Wednesday 26 November 2014 17:12:49 Hanjun Guo wrote: Thanks for the detail information. I have the concerns about the distance for NUMA nodes, does the "ibm,associativity-reference-points" property can represent the distance be

Re: [RFC PATCH v2 2/4] Documentation: arm64/arm: dt bindings for numa.

2014-11-26 Thread Hanjun Guo
On 2014-11-26 3:00, Arnd Bergmann wrote: > On Tuesday 25 November 2014 08:15:47 Ganapatrao Kulkarni wrote: >>> No, don't hardcode ARM specifics into a common binding either. I've looked >>> at the ibm,associativity properties again, and I think we should just use >>> those, they can cover all cases

Re: [RFC PATCH v2 2/4] Documentation: arm64/arm: dt bindings for numa.

2014-11-25 Thread Hanjun Guo
Hi Arnd, On 2014年11月25日 19:02, Arnd Bergmann wrote: On Tuesday 25 November 2014 17:42:44 Hanjun Guo wrote: On 2014-11-25 11:55, Shannon Zhao wrote: Hi, On 2014/11/22 5:23, Ganapatrao Kulkarni wrote: [...] +== +4

Re: [RFC PATCH v2 2/4] Documentation: arm64/arm: dt bindings for numa.

2014-11-25 Thread Hanjun Guo
On 2014-11-25 11:55, Shannon Zhao wrote: > Hi, > > On 2014/11/22 5:23, Ganapatrao Kulkarni wrote: [...] >> +== >> +4 - Example dts >> +== >> + >>

Re: [RFC PATCH] dt:numa: adding numa node mapping for memory nodes.

2014-10-28 Thread Hanjun Guo
On 2014-9-18 5:48, Nathan Lynch wrote: > On 09/17/2014 03:56 AM, Ganapatrao Kulkarni wrote: >> From: Ganapatrao Kulkarni >> >> This patch adds property "nid" to memory node to provide the memory range to >> numa node id mapping. >> >> Signed-off-by: Ganapatrao Kulkarni >> >> --- >> Documentation

Re: [RFC PATCH] dt:numa: adding numa node mapping for memory nodes.

2014-10-28 Thread Hanjun Guo
On 2014-9-18 3:34, Mark Rutland wrote: > On Wed, Sep 17, 2014 at 04:37:30PM +0100, Kumar Gala wrote: >> >> On Sep 17, 2014, at 1:56 AM, Ganapatrao Kulkarni >> wrote: >> >>> From: Ganapatrao Kulkarni >>> >>> This patch adds property "nid" to memory node to provide the memory range to >>> numa nod

Re: [RFC PATCH 1/9] ACPI: Add support for device specific properties

2014-08-18 Thread Hanjun Guo
On 2014-8-18 16:27, Mika Westerberg wrote: > On Mon, Aug 18, 2014 at 04:13:29PM +0800, Hanjun Guo wrote: >> Hi, >> >> Some minor comments below. >> >> On 2014-8-17 14:04, Mika Westerberg wrote: >>> Device Tree is used in many embedded systems to describe

Re: [RFC PATCH 1/9] ACPI: Add support for device specific properties

2014-08-18 Thread Hanjun Guo
rties->package.elements[i]; > + /* > + * Only two elements allowed, the first one must be a string and > + * the second one has to satisfy certain conditions. > + */ > + if (property->package.count != 2 > + || property->package.elements[0].type != ACPI_TYPE_STRING > + || !acpi_property_value_ok(&property->package.elements[1])) > + return false; > + } > + return true; > +} > + > +void acpi_init_properties(struct acpi_device *adev) > +{ > + I think the above line is not needed. With that fixed, Reviewed-by: Hanjun Guo Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/8] arm64: kernel: refactor the CPU suspend API for retention states

2014-08-18 Thread Hanjun Guo
hrough __cpu_suspend() which carries out > state saving and suspend finisher dispatching to complete idle state entry. > > Signed-off-by: Lorenzo Pieralisi This patch is pretty fine to me, Reviewed-by: Hanjun Guo Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] ACPICA: Only include ACPI asm files if ACPI is enabled

2014-06-04 Thread Hanjun Guo
On 2014-6-5 9:14, Zheng, Lv wrote: > Hi, Lee > >> From: Lee Jones [mailto:lee.jo...@linaro.org] >> Sent: Wednesday, June 04, 2014 8:52 PM >> To: Rafael J. Wysocki >> >> On Wed, 04 Jun 2014, Rafael J. Wysocki wrote: >> >>> On Wednesday, June 04, 2014 01:09:50 PM Lee Jones wrote: Any drivers wh

Re: [PATCH 1/7] ACPICA: Only include ACPI asm files if ACPI is enabled

2014-06-04 Thread Hanjun Guo
Hi Lv, On 2014-6-5 8:56, Zheng, Lv wrote: > Hi, Lee > >> From: Lee Jones [mailto:lee.jo...@linaro.org] >> Sent: Wednesday, June 04, 2014 8:10 PM >> >> Any drivers which support ACPI and Device Tree probing need to include >> both respective header files. Without this patch, if a driver is being

Re: [PATCH v7 6/6] pci: Add support for creating a generic host_bridge from device tree

2014-04-08 Thread Hanjun Guo
Hi Liviu, On 2014-3-14 23:34, Liviu Dudau wrote: > Several platforms use a rather generic version of parsing > the device tree to find the host bridge ranges. Move the common code > into the generic PCI code and use it to create a pci_host_bridge > structure that can be used by arch code. > > Bas