RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wang Dongsheng-B40534
Sent: Monday, August 13, 2012 1:54 PM
To: Wood Scott-B07421
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, August 11, 2012 3:40 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/10/2012 12:54 AM, dongsheng.w...@freescale.com wrote:
+static const struct of_device_id mpic_timer_ids[] = {
+ { .compatible = open-pic,global-timer, },
+ { .compatible = fsl,global-timer, },
+ {},
+};
+
+static int __init mpic_timer_init(void) {
+ struct device_node *np = NULL;
+
+ for_each_node_by_type(np, open-pic)
+ if (of_match_node(mpic_timer_ids, np))
+ group_init(np);
+
+ if (list_empty(group_list))
+ return -ENODEV;
+
+ return 0;
+}
+arch_initcall(mpic_timer_init);
Oh, and don't probe by device_type.
Actually it does match the compatible. The device_type is just to speed up the
search. I don't think it's a problem unless the device type is not mandatory
any more for defined types.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, August 11, 2012 4:38 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/10/2012 12:54 AM, dongsheng.w...@freescale.com wrote:
+static int group_get_freq(struct group_priv *priv) {
+ if (priv-flags FSL_GLOBAL_TIMER) {
+ ccbfreq = fsl_get_sys_freq();
+ priv-timerfreq = ccbfreq;
+ } else {
+ priv-timerfreq = in_be32(priv-group_tfrr);
+ }
FSL MPICs have TFRR too. I'm not sure that the lack of fsl,mpic is a
good indication that TFRR is being set (e.g. we have old device trees for
FSL chips with U-Boot that are labelled as ordinary openpics).
[Wang Dongsheng] yes, we have. But we do not used it. The TFRR register value
is zero.
+
+ if (priv-timerfreq = 0)
+ return -EINVAL;
+
+ return 0;
+}
timerfreq is unsigned. It can never be 0.
[Wang Dongsheng] Yeah. Thanks.
+
+static int group_init_regmap(struct device_node *np, struct
+group_priv *priv) {
+ priv-group_tfrr = of_iomap(np, 0);
+ if (!priv-group_tfrr) {
+ pr_err(%s: cannot ioremap tfrr address.\n,
+ np-full_name);
+ return -EINVAL;
+ }
+
+ priv-regs = of_iomap(np, 1);
+ if (!priv-regs) {
+ pr_err(%s: cannot ioremap timer register address.\n,
+ np-full_name);
+ return -EINVAL;
+ }
+
+ if (!(priv-flags FSL_GLOBAL_TIMER))
+ return 0;
+
+ priv-group_tcr = of_iomap(np, 2);
+ if (!priv-group_tcr) {
+ pr_err(%s: cannot ioremap tcr address.\n, np-full_name);
+ return -EINVAL;
+ }
This is not compatible with existing mpic timer nodes.
[Wang Dongsheng] Yeah, next patch to support that.
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an accepted
binding and people could have partitioned setups already using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group)
in each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
if (p len % (2 * sizeof(u32)) != 0) {
pr_err(%s: malformed fsl,available-ranges property.\n,
np-full_name);
return -EINVAL;
}
You also have a mismatch between the property you check and the error
string.
[Wang Dongsheng] Yeah. :-(.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message- From: Tabi Timur-B04825 Sent: Saturday, August 11, 2012 9:10 PM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; pau...@samba.org; Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support On Fri, Aug 10, 2012 at 12:54 AM, dongsheng.w...@freescale.com wrote: From: Wang Dongsheng dongsheng.w...@freescale.com +EXPORT_SYMBOL_GPL(mpic_request_timer); Make these EXPORT_SYMBOL. No need for a GPL restriction. [Wang Dongsheng] Why? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+b40534=freescale@lists.ozlabs.org] On Behalf Of Wang Dongsheng-B40534 Sent: Monday, August 13, 2012 2:21 PM To: Tabi Timur-B04825 Cc: Gala Kumar-B11780; pau...@samba.org; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421 Subject: RE: [PATCH v2 2/2] powerpc/mpic: add global timer support -Original Message- From: Tabi Timur-B04825 Sent: Saturday, August 11, 2012 9:10 PM To: Wang Dongsheng-B40534 Cc: b...@kernel.crashing.org; pau...@samba.org; Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support On Fri, Aug 10, 2012 at 12:54 AM, dongsheng.w...@freescale.com wrote: From: Wang Dongsheng dongsheng.w...@freescale.com +EXPORT_SYMBOL_GPL(mpic_request_timer); Make these EXPORT_SYMBOL. No need for a GPL restriction. [Wang Dongsheng] Why? [Wang Dongsheng] Sorry, I just see the mail. Thanks. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/7] mv643xx.c: Add basic device tree support.
On 10/08/12 11:49, Arnd Bergmann wrote: On Thursday 09 August 2012, Ian Molton wrote: The driver already knows all those offsets and they are always the same for all variants of mv643xx, right? Yes, but its not clean. And no amount of refactoring is really going to make a nice driver that also fits the ancient (and badly thought out) OF bindings. In what way is it badly though out, or not clean? The use of underscores in the properties, and the way that the sram is configured is problematic, I agree. But The way that the three ports are addressed and how the PHY is found seems quite clever. It forces one to load the MDIO driver first, because it maps ALL the registers for both itself and all the ports, and the MDIO driver has no way of knowing how many ethernet blocks are present (I have a device here with two, and another with four). Thats anywhere from 1 to 12 ports, split across 1 to 4 address ranges, and theres a big gap in the address range between controllers 0,1 and 2,3. *ALL* the devices on the board are sharing ethernet block 0's MDIO bus. By pure luck it happens to work, because the blocks 2,3 have an alias of the MDIO registers from blocks 0,1. Having the MDIO driver map the ethernet drivers memory is a terrible solution, IMO. Ethernet drivers should map their own memory, and that introduces the n-ports-per-block problem, because their address ranges overlap. I think the best solution is to make each ethernet block register 3 ports. the PPC code can simply generate different fixups so that instead of creating 3 devices, it creates one, with three ports. If we have to break things, we can at least go for a nice clean design, surely? The ports arent really child devices of the MAC. The MAC just has 3 ports. I don't see the difference between those two things. The ports are at best 'pseudodevices'. Real devices have registers of their own. We're going to have to maintain a legacy platform_device - DT bindings hack somewhere anyway, at least until the remaining other users of the driver convert to D-T. I don't understand why you describe the method used in powerpc as a hack. It was the normal way to introduce DT support for platform devices back when it was implemented. Just because its normal doesn't mean its not a hack :) It also had the advantage of not requiring any modifications to the generic driver, because it was shared between one architecture using DT (powerpc) and one that didn't (ARM). It /did/ spawn a pretty hideous driver, though... -Ian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 4/6] x86: Add clear_page_nocache
On Thu, Aug 09, 2012 at 04:22:04PM +0100, Jan Beulich wrote:
On 09.08.12 at 17:03, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
...
---
arch/x86/include/asm/page.h |2 ++
arch/x86/include/asm/string_32.h |5 +
arch/x86/include/asm/string_64.h |5 +
arch/x86/lib/Makefile|1 +
arch/x86/lib/clear_page_nocache_32.S | 30 ++
arch/x86/lib/clear_page_nocache_64.S | 29 +
Couldn't this more reasonably go into clear_page_{32,64}.S?
We don't have clear_page_32.S.
+xorl %eax,%eax
+movl $4096/64,%ecx
+.p2align 4
+.Lloop:
+decl%ecx
+#define PUT(x) movnti %eax,x*8(%edi) ; movnti %eax,x*8+4(%edi)
Is doing twice as much unrolling as on 64-bit really worth it?
Moving 64 bytes per cycle is faster on Sandy Bridge, but slower on
Westmere. Any preference? ;)
Westmere:
Performance counter stats for './test_unroll32' (20 runs):
31498.420608 task-clock#0.998 CPUs utilized
( +- 0.25% )
40 context-switches #0.001 K/sec
( +- 1.40% )
0 CPU-migrations#0.000 K/sec
( +-100.00% )
89 page-faults #0.003 K/sec
( +- 0.13% )
74,728,231,935 cycles#2.372 GHz
( +- 0.25% ) [83.34%]
53,789,969,009 stalled-cycles-frontend # 71.98% frontend cycles idle
( +- 0.35% ) [83.33%]
41,681,014,054 stalled-cycles-backend# 55.78% backend cycles idle
( +- 0.43% ) [66.67%]
37,992,733,278 instructions #0.51 insns per cycle
#1.42 stalled cycles per insn
( +- 0.05% ) [83.33%]
3,561,376,245 branches # 113.065 M/sec
( +- 0.05% ) [83.33%]
27,182,795 branch-misses #0.76% of all branches
( +- 0.06% ) [83.33%]
31.558545812 seconds time elapsed
( +- 0.25% )
Performance counter stats for './test_unroll64' (20 runs):
31564.753623 task-clock#0.998 CPUs utilized
( +- 0.19% )
39 context-switches #0.001 K/sec
( +- 0.40% )
0 CPU-migrations#0.000 K/sec
90 page-faults #0.003 K/sec
( +- 0.12% )
74,886,045,192 cycles#2.372 GHz
( +- 0.19% ) [83.33%]
57,477,323,995 stalled-cycles-frontend # 76.75% frontend cycles idle
( +- 0.26% ) [83.34%]
44,548,142,150 stalled-cycles-backend# 59.49% backend cycles idle
( +- 0.31% ) [66.67%]
32,940,027,099 instructions #0.44 insns per cycle
#1.74 stalled cycles per insn
( +- 0.05% ) [83.34%]
1,884,944,093 branches # 59.717 M/sec
( +- 0.05% ) [83.32%]
1,027,135 branch-misses #0.05% of all branches
( +- 0.56% ) [83.34%]
31.621001407 seconds time elapsed
( +- 0.19% )
Sandy Bridge:
Performance counter stats for './test_unroll32' (20 runs):
8578.382891 task-clock#0.997 CPUs utilized
( +- 0.08% )
15 context-switches #0.000 M/sec
( +- 2.97% )
0 CPU-migrations#0.000 M/sec
84 page-faults #0.000 M/sec
( +- 0.13% )
29,154,476,597 cycles#3.399 GHz
( +- 0.08% ) [83.33%]
11,851,215,147 stalled-cycles-frontend # 40.65% frontend cycles idle
( +- 0.20% ) [83.33%]
1,530,172,593 stalled-cycles-backend#5.25% backend cycles idle
( +- 1.44% ) [66.67%]
37,915,778,094 instructions #1.30 insns per cycle
#0.31 stalled cycles per insn
( +- 0.00% ) [83.34%]
3,590,533,447 branches # 418.556 M/sec
( +- 0.01% ) [83.35%]
26,500,765 branch-misses #0.74% of all branches
( +- 0.01% ) [83.34%]
8.604638449 seconds time elapsed
( +- 0.08% )
Performance counter stats for './test_unroll64' (20 runs):
8463.789963 task-clock#0.997 CPUs utilized
( +- 0.07% )
14 context-switches #0.000 M/sec
( +- 1.70% )
0 CPU-migrations#0.000 M/sec
( +-100.00% )
Re: [PATCH v2 4/6] x86: Add clear_page_nocache
On 13.08.12 at 13:43, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
On Thu, Aug 09, 2012 at 04:22:04PM +0100, Jan Beulich wrote:
On 09.08.12 at 17:03, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
...
---
arch/x86/include/asm/page.h |2 ++
arch/x86/include/asm/string_32.h |5 +
arch/x86/include/asm/string_64.h |5 +
arch/x86/lib/Makefile|1 +
arch/x86/lib/clear_page_nocache_32.S | 30 ++
arch/x86/lib/clear_page_nocache_64.S | 29 +
Couldn't this more reasonably go into clear_page_{32,64}.S?
We don't have clear_page_32.S.
Sure, but you're introducing a file anyway. Fold the new code into
the existing file for 64-bit, and create a new, similarly named one
for 32-bit.
+ xorl %eax,%eax
+ movl $4096/64,%ecx
+ .p2align 4
+.Lloop:
+ decl%ecx
+#define PUT(x) movnti %eax,x*8(%edi) ; movnti %eax,x*8+4(%edi)
Is doing twice as much unrolling as on 64-bit really worth it?
Moving 64 bytes per cycle is faster on Sandy Bridge, but slower on
Westmere. Any preference? ;)
If it's not a clear win, I'd favor the 8-stores-per-cycle variant,
matching x86-64.
Jan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [RESEND] powerpc: fix personality handling in ppc64_personality()
Directly comparing current-personality against PER_LINUX32 doesn't work in cases when any of the personality flags stored in the top three bytes are used. Directly forcefully setting personality to PER_LINUX32 or PER_LINUX discards any flags stored in the top three bytes Use personality() macro to compare only PER_MASK bytes and make sure that we are setting only the bits that should be set, instead of overwriting the whole value. Signed-off-by: Jiri Kosina jkos...@suse.cz --- Resned of patch sent on Thu, 2 Aug 2012 09:10:03 +0200 (CEST) arch/powerpc/kernel/syscalls.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c index f2496f2..dc1558e 100644 --- a/arch/powerpc/kernel/syscalls.c +++ b/arch/powerpc/kernel/syscalls.c @@ -107,11 +107,11 @@ long ppc64_personality(unsigned long personality) long ret; if (personality(current-personality) == PER_LINUX32 -personality == PER_LINUX) - personality = PER_LINUX32; +personality(personality) == PER_LINUX) + personality = (personality ~PER_MASK) | PER_LINUX32; ret = sys_personality(personality); - if (ret == PER_LINUX32) - ret = PER_LINUX; + if (personality(ret) == PER_LINUX32) + ret = (ret ~PER_MASK) | PER_LINUX; return ret; } #endif -- Jiri Kosina SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 3/3] drivers/char/tpm: Add securityfs support for event log
Thank you so much for reviewing the code. Please see my reply below.
On Fri, 2012-08-10 at 17:23 +1000, Michael Ellerman wrote:
On Thu, 2012-08-09 at 18:13 -0500, Ashley Lai wrote:
This patch retrieves the event log data from the device tree
during file open. The event log data will then displayed through
securityfs.
Hi Ashley,
Comments inline ..
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index 547509d..b53da57 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -2,9 +2,15 @@
# Makefile for the kernel tpm device drivers.
#
obj-$(CONFIG_TCG_TPM) += tpm.o
+obj-$(CONFIG_TCG_TPM) += tpm_bios.o
ifdef CONFIG_ACPI
- obj-$(CONFIG_TCG_TPM) += tpm_bios.o
tpm_bios-objs += tpm_eventlog.o tpm_acpi.o
+else
+ifdef CONFIG_TCG_IBMVTPM
+ tpm_bios-objs += tpm_eventlog.o tpm_of.o
+else
+ tpm_bios-objs += tpm_eventlog.o tpm_noeventlog.o
What does it mean to build tpm_eventlog and tpm_noeventlog ?
This is the case where the event log is not available. I agree it does not
look clean. I'm thinking of moving tpm_noeventlog into header file to
eliminate this file.
diff --git a/drivers/char/tpm/tpm_eventlog.h
b/drivers/char/tpm/tpm_eventlog.h
index 8e23ccd..21ac6af 100644
--- a/drivers/char/tpm/tpm_eventlog.h
+++ b/drivers/char/tpm/tpm_eventlog.h
@@ -68,4 +68,18 @@ enum tcpa_pc_event_ids {
};
int read_log(struct tpm_bios_log *log);
+
+extern struct dentry **tpm_bios_log_setup(char *);
+extern void tpm_bios_log_teardown(struct dentry **);
+
+#ifdef CONFIG_PPC64
+#define TPM_NO_EVENT_LOG !of_find_node_by_name(NULL, ibm,vtpm)
+#else
+#ifdef CONFIG_ACPI
+#define TPM_NO_EVENT_LOG 0
+#else
+#define TPM_NO_EVENT_LOG 1
+#endif
+#endif
This should be a static inline, with the ifdefs inside.
I just realized that it does not need to call of_find_node_by_name()
here because if ibm,vtpm is not there it does not go to probe. Thanks
for pointing this out.
How often is this called? of_find_node_by_name() is not particularly
efficient. It might be better to search once and save a flag indicating
whether you found it.
This is called during load and unload of the driver. I'll remove the call to
of_find_node_by_name() in next version. See above.
Also you must call of_node_put() on the result of
of_find_node_by_name(), so at the least you must do:
Nice catch!!! I will fix other places in the code in the next
version.
struct device_node *np;
np = of_find_node_by_name(NULL, ibm,vtpm);
of_node_put(np);
return (np != NULL);
#endif
diff --git a/drivers/char/tpm/tpm_noeventlog.c
b/drivers/char/tpm/tpm_noeventlog.c
new file mode 100644
index 000..f30a2bf
--- /dev/null
+++ b/drivers/char/tpm/tpm_noeventlog.c
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2012 IBM Corporation
^^
Don't use (C)
Will remove it.
+ *
+ * Author: Ashley Lai ad...@us.ibm.com
+ *
+ * Maintained by: tpmdd-de...@lists.sourceforge.net
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include linux/slab.h
+#include tpm_eventlog.h
+
+int read_log(struct tpm_bios_log *log)
+{
+ return -EINVAL;
+}
Wouldn't it be simpler to put this in a header with the appropriate
ifdefs, and then you'd need less logic in the Makefile?
Will move this to header file. Thanks.
diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
new file mode 100644
index 000..6d44adb
--- /dev/null
+++ b/drivers/char/tpm/tpm_of.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright 2012 IBM Corporation
+ *
+ * Author: Ashley Lai ad...@us.ibm.com
+ *
+ * Maintained by: tpmdd-de...@lists.sourceforge.net
+ *
+ * Read the event log created by the firmware on PPC64
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include linux/slab.h
+#include linux/of.h
+
+#include tpm.h
+#include tpm_eventlog.h
+
+int read_log(struct tpm_bios_log *log)
+{
+ struct device_node *np;
+ const u32 *sizep;
+ const __be64 *basep;
+
+ if (log-bios_event_log != NULL) {
+ pr_err(%s: ERROR - Eventlog already initialized\n, __func__);
+ return -EFAULT;
+ }
+
+ np = of_find_node_by_name(NULL, ibm,vtpm);
+ if (!np) {
+ pr_err(%s: ERROR - IBMVTPM not supported\n, __func__);
+ return -ENODEV;
+ }
All your return paths below here must call of_node_put(np).
I'll fix it in next version. Thanks.
Re: [PATCH v2 4/6] x86: Add clear_page_nocache
Moving 64 bytes per cycle is faster on Sandy Bridge, but slower on Westmere. Any preference? ;) You have to be careful with these benchmarks. - You need to make sure the data is cache cold, cache hot is misleading. - The numbers can change if you have multiple CPUs doing this in parallel. -Andi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 12:53 AM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, August 11, 2012 3:40 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/10/2012 12:54 AM, dongsheng.w...@freescale.com wrote:
+static const struct of_device_id mpic_timer_ids[] = {
+ { .compatible = open-pic,global-timer, },
+ { .compatible = fsl,global-timer, },
+ {},
+};
+
+static int __init mpic_timer_init(void) {
+ struct device_node *np = NULL;
+
+ for_each_node_by_type(np, open-pic)
+ if (of_match_node(mpic_timer_ids, np))
+ group_init(np);
+
+ if (list_empty(group_list))
+ return -ENODEV;
+
+ return 0;
+}
+arch_initcall(mpic_timer_init);
Oh, and don't probe by device_type.
[Wang Dongsheng] fine. for_each_node_by_name.
No. Probe by compatible only.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:17 AM, Li Yang-R58472 wrote:
-Original Message-
From: Wang Dongsheng-B40534
Sent: Monday, August 13, 2012 1:54 PM
To: Wood Scott-B07421
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, August 11, 2012 3:40 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/10/2012 12:54 AM, dongsheng.w...@freescale.com wrote:
+static const struct of_device_id mpic_timer_ids[] = {
+ { .compatible = open-pic,global-timer, },
+ { .compatible = fsl,global-timer, },
+ {},
+};
+
+static int __init mpic_timer_init(void) {
+ struct device_node *np = NULL;
+
+ for_each_node_by_type(np, open-pic)
+ if (of_match_node(mpic_timer_ids, np))
+ group_init(np);
+
+ if (list_empty(group_list))
+ return -ENODEV;
+
+ return 0;
+}
+arch_initcall(mpic_timer_init);
Oh, and don't probe by device_type.
Actually it does match the compatible. The device_type is just to
speed up the search. I don't think it's a problem unless the device
type is not mandatory any more for defined types.
Doesn't matter (and I doubt it provides any significant speed up
compared to a search by compatible, and in any case this is not
performance critical). device_type is deprecated outside certain
specific legacy uses. Get rid of it.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 4/6] x86: Add clear_page_nocache
On Mon, Aug 13, 2012 at 02:43:34PM +0300, Kirill A. Shutemov wrote:
$ cat test.c
#include stdio.h
#include sys/mman.h
#define SIZE 1024*1024*1024
void clear_page_nocache_sse2(void *page) __attribute__((regparm(1)));
int main(int argc, char** argv)
{
char *p;
unsigned long i, j;
p = mmap(NULL, SIZE, PROT_WRITE|PROT_READ,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_POPULATE, -1, 0);
for(j = 0; j 100; j++) {
for(i = 0; i SIZE; i += 4096) {
clear_page_nocache_sse2(p + i);
}
}
return 0;
}
$ cat clear_page_nocache_unroll32.S
.globl clear_page_nocache_sse2
.align 4,0x90
clear_page_nocache_sse2:
.cfi_startproc
mov%eax,%edx
xorl %eax,%eax
movl $4096/32,%ecx
.p2align 4
.Lloop_sse2:
decl%ecx
#define PUT(x) movnti %eax,x*4(%edx)
PUT(0)
PUT(1)
PUT(2)
PUT(3)
PUT(4)
PUT(5)
PUT(6)
PUT(7)
#undef PUT
lea 32(%edx),%edx
jnz .Lloop_sse2
nop
ret
.cfi_endproc
.type clear_page_nocache_sse2, @function
.size clear_page_nocache_sse2, .-clear_page_nocache_sse2
$ cat clear_page_nocache_unroll64.S
.globl clear_page_nocache_sse2
.align 4,0x90
clear_page_nocache_sse2:
.cfi_startproc
mov%eax,%edx
This must still be the 32-bit version becaue it segfaults here. Here's
why:
mmap above gives a ptr which, on 64-bit, is larger than 32-bit, i.e. it
looks like 0x7fffx000, i.e. starting from top of userspace.
Now, the mov above truncates that ptr and the thing segfaults.
Doing s/edx/rdx/g fixes it though.
Thanks.
--
Regards/Gruss,
Boris.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/epapr: export epapr_hypercall_start
On 08/11/2012 08:07 AM, Tabi Timur-B04825 wrote: On Sat, Aug 11, 2012 at 2:01 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Sat, Aug 11, 2012 at 12:21 AM, Scott Wood scottw...@freescale.com wrote: +EXPORT_SYMBOL(epapr_hypercall_start); EXPORT_SYMBOL_GPL? We prefer EXPORT_SYMBOL. We don't want to restrict our customers from having to use GPL code. More specifically in this case, I don't see how use of this symbol in any way suggests that the code would be GPL-derivative. The API is documented in the ePAPR standard or other external sources -- not a kernel internal implementation issue. The contents of epapr_hypercall_start itself are not copyrightable (by default it's basically return -1, and is patched at runtime with a few instructions provided by the hypervisor). The header file with the inline accessors is dual licensed (and also unlikely to be copyrightable, in terms of what actually makes it into the output binary). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an accepted
binding and people could have partitioned setups already using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group)
in each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to check for
both -- but I think any further discussion of the details is premature
until we decide whether this is worthwhile to begin with (both the
support of non-FSL timers, and the creation of a new device tree binding
which will not be implemented by many of the machines that have non-FSL
openpic because they run real Open Firmware).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer document
On 08/13/2012 12:40 AM, Wang Dongsheng-B40534 wrote:
diff --git a/Documentation/devicetree/bindings/open-pic.txt
b/Documentation/devicetree/bindings/open-pic.txt
index 909a902..045c2e9 100644
--- a/Documentation/devicetree/bindings/open-pic.txt
+++ b/Documentation/devicetree/bindings/open-pic.txt
@@ -92,6 +92,52 @@ Example 2:
* References
+* Open PIC global timers
+
+Required properties:
+- compatible: open-pic,global-timer
open-pic isn't a vendor (or software project that acts like a
pseudo-vendor) -- I'd go with open-pic-global-timer.
[Wang Dongsheng] yes, open-pic-global-timer looks good.
+- reg : Contains two regions. The first is the timer frequency
+reporting
+ register for the group. The second is the main timer register bank
+ (GTCCR, GTBCR, GTVPR, GTDR).
Why not just put clock-frequency in the node, instead of describing TFRR?
I don't think U-Boot currently sets TFRR.
[Wang Dongsheng] If during startup U-Boot do not set TFRR that is
unreasonable.
Too bad, it's what happens and we're not going to force users to update
U-Boot because of this.
+Example 2:
+
+ timer: timer@010f0 {
+ compatible = open-pic,global-timer;
+ device_type = open-pic;
+ reg = 0x010f0 4 0x01100 0x100;
+ interrupts = 0 0 3 0
+ 1 0 3 0
+ 2 0 3 0
+ 3 0 3 0;
+ };
4-cell interrupt specifiers are specific to Freescale MPICs. This means
there's no way to describe the timer interrupt on a non-Freescale openpic.
Again, I suggest we not bother with this in the absence of an actual need
to support the timer on non-Freescale openpic in partitioned scenarios.
The existing openpic node is sufficient to describe the
hardware in the absence of partitioning. We could have an
openpic-no-timer property to indicate that we're describing it
separately, so that the absence of a timer node isn't ambiguous as to
whether it's an old tree or a partitioned scenario. An fsl,mpic
compatible would imply openpic-no-timer.
Note that I believe many of the non-Freescale openpic nodes are going to
be found on systems with real Open Firmware, so we can't go changing the
device tree for them.
[Wang Dongsheng] In the Open-PIC specification, there are four timer.
interrupts = 0 0 3 0
1 0 3 0
2 0 3 0
3 0 3 0;
The interrupts just let user know there are four timers. Usage based
interrupts
binding to change dts.
I can't understand the above or how it's a response to what I wrote.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 4/6] x86: Add clear_page_nocache
On Mon, Aug 13, 2012 at 07:04:02PM +0200, Borislav Petkov wrote:
On Mon, Aug 13, 2012 at 02:43:34PM +0300, Kirill A. Shutemov wrote:
$ cat test.c
#include stdio.h
#include sys/mman.h
#define SIZE 1024*1024*1024
void clear_page_nocache_sse2(void *page) __attribute__((regparm(1)));
int main(int argc, char** argv)
{
char *p;
unsigned long i, j;
p = mmap(NULL, SIZE, PROT_WRITE|PROT_READ,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_POPULATE, -1, 0);
for(j = 0; j 100; j++) {
for(i = 0; i SIZE; i += 4096) {
clear_page_nocache_sse2(p + i);
}
}
return 0;
}
$ cat clear_page_nocache_unroll32.S
.globl clear_page_nocache_sse2
.align 4,0x90
clear_page_nocache_sse2:
.cfi_startproc
mov%eax,%edx
xorl %eax,%eax
movl $4096/32,%ecx
.p2align 4
.Lloop_sse2:
decl%ecx
#define PUT(x) movnti %eax,x*4(%edx)
PUT(0)
PUT(1)
PUT(2)
PUT(3)
PUT(4)
PUT(5)
PUT(6)
PUT(7)
#undef PUT
lea 32(%edx),%edx
jnz .Lloop_sse2
nop
ret
.cfi_endproc
.type clear_page_nocache_sse2, @function
.size clear_page_nocache_sse2, .-clear_page_nocache_sse2
$ cat clear_page_nocache_unroll64.S
.globl clear_page_nocache_sse2
.align 4,0x90
clear_page_nocache_sse2:
.cfi_startproc
mov%eax,%edx
This must still be the 32-bit version becaue it segfaults here.
Yes, it's test for 32-bit version.
--
Kirill A. Shutemov
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an accepted
binding and people could have partitioned setups already using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group) in
each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to check for
both -- but I think any further discussion of the details is premature
until we decide whether this is worthwhile to begin with (both the
support of non-FSL timers, and the creation of a new device tree binding
which will not be implemented by many of the machines that have non-FSL
openpic because they run real Open Firmware).
[Wang Dongsheng]
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
this code be compatible with existing trees.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:00 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an accepted
binding and people could have partitioned setups already using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group) in
each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to check for
both -- but I think any further discussion of the details is premature
until we decide whether this is worthwhile to begin with (both the
support of non-FSL timers, and the creation of a new device tree binding
which will not be implemented by many of the machines that have non-FSL
openpic because they run real Open Firmware).
[Wang Dongsheng]
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
this code be compatible with existing trees.
Yes, that's what I meant by checking both.
I still think we need to discuss why we're doing this first. What
specific machines are going to have these new openpic timer nodes?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:05 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:00 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an
accepted binding and people could have partitioned setups already
using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group) in
each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to check
for both -- but I think any further discussion of the details is
premature until we decide whether this is worthwhile to begin with
(both the support of non-FSL timers, and the creation of a new device
tree binding which will not be implemented by many of the machines
that have non-FSL openpic because they run real Open Firmware).
[Wang Dongsheng]
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
this code be compatible with existing trees.
Yes, that's what I meant by checking both.
I still think we need to discuss why we're doing this first. What
specific machines are going to have these new openpic timer nodes?
[Wang Dongsheng] It's support to power management awakening. At present,
the power management more and more important. This way is important to wake
up machine. At least need support power management of machine still needs
such a driver.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:15 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:05 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:00 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an
accepted binding and people could have partitioned setups already
using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group) in
each group only four timer. This is unified. So i use a generic name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to check
for both -- but I think any further discussion of the details is
premature until we decide whether this is worthwhile to begin with
(both the support of non-FSL timers, and the creation of a new device
tree binding which will not be implemented by many of the machines
that have non-FSL openpic because they run real Open Firmware).
[Wang Dongsheng]
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
this code be compatible with existing trees.
Yes, that's what I meant by checking both.
I still think we need to discuss why we're doing this first. What
specific machines are going to have these new openpic timer nodes?
[Wang Dongsheng] It's support to power management awakening. At present,
the power management more and more important. This way is important to wake
up machine. At least need support power management of machine still needs
such a driver.
I mean specifically for the non-Freescale openpic nodes.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:19 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:15 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:05 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 09:00 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:
+ p = of_get_property(np, available-ranges, len);
+ if (p len % (2 * sizeof(u32)) != 0) {
+ pr_err(%s: malformed fsl,available-ranges property.\n,
+ np-full_name);
+ return -EINVAL;
+ }
You need to support fsl,available-ranges since that's in an
accepted binding and people could have partitioned setups already
using it.
[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group)
in each group only four timer. This is unified. So i use a generic
name.
I think there is not compatible with existing mpic timer nodes.
We need to be compatible with existing trees, so you'd need to
check for both -- but I think any further discussion of the details
is premature until we decide whether this is worthwhile to begin
with (both the support of non-FSL timers, and the creation of a new
device tree binding which will not be implemented by many of the
machines that have non-FSL openpic because they run real Open
Firmware).
[Wang Dongsheng]
p = of_get_property(np, available-ranges, len);
if (!p)
p = of_get_property(np, fsl,available-ranges, len);
this code be compatible with existing trees.
Yes, that's what I meant by checking both.
I still think we need to discuss why we're doing this first. What
specific machines are going to have these new openpic timer nodes?
[Wang Dongsheng] It's support to power management awakening. At
present, the power management more and more important. This way is
important to wake up machine. At least need support power management
of machine still needs such a driver.
I mean specifically for the non-Freescale openpic nodes.
[Wang Dongsheng] I think non-Freescale chips can also use this function
to wake up the machine. And There is also an important feature, It can
periodically generate an interrupt. For example, the network periodically
check the hardware device(link status).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer document
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:40 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; b...@kernel.crashing.org; pau...@samba.org;
linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org; Gala
Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 1/2] powerpc/mpic: Add Open-PIC global timer
document
On 08/13/2012 12:40 AM, Wang Dongsheng-B40534 wrote:
diff --git a/Documentation/devicetree/bindings/open-pic.txt
b/Documentation/devicetree/bindings/open-pic.txt
index 909a902..045c2e9 100644
--- a/Documentation/devicetree/bindings/open-pic.txt
+++ b/Documentation/devicetree/bindings/open-pic.txt
@@ -92,6 +92,52 @@ Example 2:
* References
+* Open PIC global timers
+
+Required properties:
+- compatible: open-pic,global-timer
open-pic isn't a vendor (or software project that acts like a
pseudo-vendor) -- I'd go with open-pic-global-timer.
[Wang Dongsheng] yes, open-pic-global-timer looks good.
+- reg : Contains two regions. The first is the timer frequency
+reporting
+ register for the group. The second is the main timer register
+bank
+ (GTCCR, GTBCR, GTVPR, GTDR).
Why not just put clock-frequency in the node, instead of describing
TFRR?
I don't think U-Boot currently sets TFRR.
[Wang Dongsheng] If during startup U-Boot do not set TFRR that is
unreasonable.
Too bad, it's what happens and we're not going to force users to update
U-Boot because of this.
+Example 2:
+
+ timer: timer@010f0 {
+ compatible = open-pic,global-timer;
+ device_type = open-pic;
+ reg = 0x010f0 4 0x01100 0x100;
+ interrupts = 0 0 3 0
+ 1 0 3 0
+ 2 0 3 0
+ 3 0 3 0;
+ };
4-cell interrupt specifiers are specific to Freescale MPICs. This
means there's no way to describe the timer interrupt on a non-
Freescale openpic.
Again, I suggest we not bother with this in the absence of an actual
need to support the timer on non-Freescale openpic in partitioned
scenarios.
The existing openpic node is sufficient to describe the
hardware in the absence of partitioning. We could have an
openpic-no-timer property to indicate that we're describing it
separately, so that the absence of a timer node isn't ambiguous as to
whether it's an old tree or a partitioned scenario. An fsl,mpic
compatible would imply openpic-no-timer.
Note that I believe many of the non-Freescale openpic nodes are going
to be found on systems with real Open Firmware, so we can't go
changing the device tree for them.
[Wang Dongsheng] In the Open-PIC specification, there are four timer.
interrupts = 0 0 3 0
1 0 3 0
2 0 3 0
3 0 3 0;
The interrupts just let user know there are four timers. Usage based
interrupts
binding to change dts.
I can't understand the above or how it's a response to what I wrote.
[Wang Dongsheng] I mean this just to tell how many timers to support in Open-PIC
specification. If someone needs to write interrupts into dts, this must comply
with the specification of the interrupt to write. this is based on the pic
driver
should be changed in different platforms.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
