| Message ID | 5341dfbb085d5647ebb6fe4390ca329b63e0e03d.1464148904.git.dalias@libc.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote: > Signed-off-by: Rich Felker <dalias@libc.org> > --- > .../devicetree/bindings/timer/jcore,pit.txt | 28 ++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt > > diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt b/Documentation/devicetree/bindings/timer/jcore,pit.txt > new file mode 100644 > index 0000000..96c6815 > --- /dev/null > +++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt > @@ -0,0 +1,28 @@ > +J-Core Programmable Interval Timer and Clocksource > + > +Required properties: > + > +- compatible: Must be "jcore,pit". > + > +- reg: Memory region for timer/clocksource registers. > + > +- interrupts: An interrupt to assign for the timer. The actual pit > + core is integrated with the aic and allows the timer interrupt > + assignment to be programmed by software, but this property is > + required in order to reserve an interrupt number that doesn't > + conflict with other devices. > + > +Optional properties: > + > +- cpu-offset: For SMP, the per-cpu offset to the local timer > + programming memory range. > + > + > +Example: > + > +timer@200 { > + compatible = "jcore,pit"; > + reg = < 0x200 0x30 >; > + cpu-offset = < 0x300 >; This is outside the reg range. Perhaps reg should include each range of per cpu registers. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 01, 2016 at 08:58:52AM -0500, Rob Herring wrote: > On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote: > > Signed-off-by: Rich Felker <dalias@libc.org> > > --- > > .../devicetree/bindings/timer/jcore,pit.txt | 28 ++++++++++++++++++++++ > > 1 file changed, 28 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt > > > > diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt b/Documentation/devicetree/bindings/timer/jcore,pit.txt > > new file mode 100644 > > index 0000000..96c6815 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt > > @@ -0,0 +1,28 @@ > > +J-Core Programmable Interval Timer and Clocksource > > + > > +Required properties: > > + > > +- compatible: Must be "jcore,pit". > > + > > +- reg: Memory region for timer/clocksource registers. > > + > > +- interrupts: An interrupt to assign for the timer. The actual pit > > + core is integrated with the aic and allows the timer interrupt > > + assignment to be programmed by software, but this property is > > + required in order to reserve an interrupt number that doesn't > > + conflict with other devices. > > + > > +Optional properties: > > + > > +- cpu-offset: For SMP, the per-cpu offset to the local timer > > + programming memory range. > > + > > + > > +Example: > > + > > +timer@200 { > > + compatible = "jcore,pit"; > > + reg = < 0x200 0x30 >; > > + cpu-offset = < 0x300 >; > > This is outside the reg range. Perhaps reg should include each range of > per cpu registers. In the hardware, each timer instance is mapped independently so there's no fundamental reason they need to be mapped sufficiently close that it would make sense for a single virtual mapping to cover them all. This doesn't matter for nommu but it would with mmu in the future. In the driver I've updated it to ioremap each percpu instance separately (as its own memory range) using the cpu-offset applied to the range obtained from "reg". Is this acceptable (in which case I suppose the binding needs to be documented that "reg" just covers the cpu0 instance's range)? Do you think it would be preferable to have multiple "reg" ranges indexed by cpu instead of cpu-offset? In theory it would even be possible to just require a DT node per cpulocal timer, but I didn't see a good way to make the bindings represent the relationship to cpus or to make the driver handle irqs correctly for such a setup, so I'd need a viable proposal for how that could be done to even consider such an approach. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 01, 2016 at 01:53:07PM -0400, Rich Felker wrote: > On Wed, Jun 01, 2016 at 08:58:52AM -0500, Rob Herring wrote: > > On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote: > > > Signed-off-by: Rich Felker <dalias@libc.org> > > > --- > > > .../devicetree/bindings/timer/jcore,pit.txt | 28 ++++++++++++++++++++++ > > > 1 file changed, 28 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt > > > > > > diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt b/Documentation/devicetree/bindings/timer/jcore,pit.txt > > > new file mode 100644 > > > index 0000000..96c6815 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt > > > @@ -0,0 +1,28 @@ > > > +J-Core Programmable Interval Timer and Clocksource > > > + > > > +Required properties: > > > + > > > +- compatible: Must be "jcore,pit". > > > + > > > +- reg: Memory region for timer/clocksource registers. > > > + > > > +- interrupts: An interrupt to assign for the timer. The actual pit > > > + core is integrated with the aic and allows the timer interrupt > > > + assignment to be programmed by software, but this property is > > > + required in order to reserve an interrupt number that doesn't > > > + conflict with other devices. > > > + > > > +Optional properties: > > > + > > > +- cpu-offset: For SMP, the per-cpu offset to the local timer > > > + programming memory range. > > > + > > > + > > > +Example: > > > + > > > +timer@200 { > > > + compatible = "jcore,pit"; > > > + reg = < 0x200 0x30 >; > > > + cpu-offset = < 0x300 >; > > > > This is outside the reg range. Perhaps reg should include each range of > > per cpu registers. > > In the hardware, each timer instance is mapped independently so > there's no fundamental reason they need to be mapped sufficiently > close that it would make sense for a single virtual mapping to cover > them all. This doesn't matter for nommu but it would with mmu in the > future. In the driver I've updated it to ioremap each percpu instance > separately (as its own memory range) using the cpu-offset applied to > the range obtained from "reg". Is this acceptable (in which case I > suppose the binding needs to be documented that "reg" just covers the > cpu0 instance's range)? Do you think it would be preferable to have > multiple "reg" ranges indexed by cpu instead of cpu-offset? > > In theory it would even be possible to just require a DT node per > cpulocal timer, but I didn't see a good way to make the bindings > represent the relationship to cpus or to make the driver handle irqs > correctly for such a setup, so I'd need a viable proposal for how that > could be done to even consider such an approach. As a bit more background: the current mappings at 0xabcd0200 and 0xabcd0500 seem to have been chosen to maintain address-level compatibility with existing non-smp builds (0xabcd0200) while avoiding stepping on unrelated nearby mmio ranges -- uarts 1 and 2 were at 0xabcd0300 and 0xabcd0400 on systems with multiple uarts. Eventually these can all be moved arbitrarily and put in a more logical arrangement once everything is using device tree, but for the time being, compatibility with non-DT kernels is still needed. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 1, 2016 at 12:53 PM, Rich Felker <dalias@libc.org> wrote: > On Wed, Jun 01, 2016 at 08:58:52AM -0500, Rob Herring wrote: >> On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote: >> > Signed-off-by: Rich Felker <dalias@libc.org> >> > --- >> > .../devicetree/bindings/timer/jcore,pit.txt | 28 ++++++++++++++++++++++ >> > 1 file changed, 28 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt >> > >> > diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt b/Documentation/devicetree/bindings/timer/jcore,pit.txt >> > new file mode 100644 >> > index 0000000..96c6815 >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt >> > @@ -0,0 +1,28 @@ >> > +J-Core Programmable Interval Timer and Clocksource >> > + >> > +Required properties: >> > + >> > +- compatible: Must be "jcore,pit". >> > + >> > +- reg: Memory region for timer/clocksource registers. >> > + >> > +- interrupts: An interrupt to assign for the timer. The actual pit >> > + core is integrated with the aic and allows the timer interrupt >> > + assignment to be programmed by software, but this property is >> > + required in order to reserve an interrupt number that doesn't >> > + conflict with other devices. >> > + >> > +Optional properties: >> > + >> > +- cpu-offset: For SMP, the per-cpu offset to the local timer >> > + programming memory range. >> > + >> > + >> > +Example: >> > + >> > +timer@200 { >> > + compatible = "jcore,pit"; >> > + reg = < 0x200 0x30 >; >> > + cpu-offset = < 0x300 >; >> >> This is outside the reg range. Perhaps reg should include each range of >> per cpu registers. > > In the hardware, each timer instance is mapped independently so > there's no fundamental reason they need to be mapped sufficiently > close that it would make sense for a single virtual mapping to cover > them all. This doesn't matter for nommu but it would with mmu in the > future. In the driver I've updated it to ioremap each percpu instance > separately (as its own memory range) using the cpu-offset applied to > the range obtained from "reg". Is this acceptable (in which case I > suppose the binding needs to be documented that "reg" just covers the > cpu0 instance's range)? Do you think it would be preferable to have > multiple "reg" ranges indexed by cpu instead of cpu-offset? Yes. Either reg should cover the full range of addresses or you should have multiple reg values with one for each cpu. I prefer the latter as it doesn't create a custom property for expressing register addresses. > In theory it would even be possible to just require a DT node per > cpulocal timer, but I didn't see a good way to make the bindings > represent the relationship to cpus or to make the driver handle irqs > correctly for such a setup, so I'd need a viable proposal for how that > could be done to even consider such an approach. Yeah, there's not really a standard way to map per cpu blocks to cpus. We could, but doesn't really seem necessary here. For the irqs, percpu irqs doesn't help you? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 01, 2016 at 05:36:19PM -0500, Rob Herring wrote: > On Wed, Jun 1, 2016 at 12:53 PM, Rich Felker <dalias@libc.org> wrote: > > On Wed, Jun 01, 2016 at 08:58:52AM -0500, Rob Herring wrote: > >> On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote: > >> > Signed-off-by: Rich Felker <dalias@libc.org> > >> > --- > >> > .../devicetree/bindings/timer/jcore,pit.txt | 28 ++++++++++++++++++++++ > >> > 1 file changed, 28 insertions(+) > >> > create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt > >> > > >> > diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt b/Documentation/devicetree/bindings/timer/jcore,pit.txt > >> > new file mode 100644 > >> > index 0000000..96c6815 > >> > --- /dev/null > >> > +++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt > >> > @@ -0,0 +1,28 @@ > >> > +J-Core Programmable Interval Timer and Clocksource > >> > + > >> > +Required properties: > >> > + > >> > +- compatible: Must be "jcore,pit". > >> > + > >> > +- reg: Memory region for timer/clocksource registers. > >> > + > >> > +- interrupts: An interrupt to assign for the timer. The actual pit > >> > + core is integrated with the aic and allows the timer interrupt > >> > + assignment to be programmed by software, but this property is > >> > + required in order to reserve an interrupt number that doesn't > >> > + conflict with other devices. > >> > + > >> > +Optional properties: > >> > + > >> > +- cpu-offset: For SMP, the per-cpu offset to the local timer > >> > + programming memory range. > >> > + > >> > + > >> > +Example: > >> > + > >> > +timer@200 { > >> > + compatible = "jcore,pit"; > >> > + reg = < 0x200 0x30 >; > >> > + cpu-offset = < 0x300 >; > >> > >> This is outside the reg range. Perhaps reg should include each range of > >> per cpu registers. > > > > In the hardware, each timer instance is mapped independently so > > there's no fundamental reason they need to be mapped sufficiently > > close that it would make sense for a single virtual mapping to cover > > them all. This doesn't matter for nommu but it would with mmu in the > > future. In the driver I've updated it to ioremap each percpu instance > > separately (as its own memory range) using the cpu-offset applied to > > the range obtained from "reg". Is this acceptable (in which case I > > suppose the binding needs to be documented that "reg" just covers the > > cpu0 instance's range)? Do you think it would be preferable to have > > multiple "reg" ranges indexed by cpu instead of cpu-offset? > > Yes. Either reg should cover the full range of addresses or you should > have multiple reg values with one for each cpu. I prefer the latter as > it doesn't create a custom property for expressing register addresses. OK, let's lean towards going with the latter then. It's more flexible and allows any placement of the maps; the offset per cpu does not have to be constant. It also makes the driver code simpler since of_iomap can be used directly rather than requiring of_address_to_resource, physical address arithmetic arithmetic, and ioremap on the results. Is there any precedent for using multiple reg ranges for percpu register instances like this? Anything else they've been used for? > > In theory it would even be possible to just require a DT node per > > cpulocal timer, but I didn't see a good way to make the bindings > > represent the relationship to cpus or to make the driver handle irqs > > correctly for such a setup, so I'd need a viable proposal for how that > > could be done to even consider such an approach. > > Yeah, there's not really a standard way to map per cpu blocks to cpus. > We could, but doesn't really seem necessary here. > > For the irqs, percpu irqs doesn't help you? What I mean is that, if there were a separate device node and driver instance per cpu, they'd all want to register the same irq just to handle it on their own cpu, so we'd have a lot of spurious handlers running. The right way to model this, I think, would be as a virtual irqchip that's the irq parent of all the timer nodes, and that multiplexes the real irq to one virq per cpu (where the current cpu id becomes the irq number in its irq domain). But that's a lot of virtual infrastructure just for the sake of modelling each percpu timer as its own DT node and I don't think it makes sense to do it that way. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 01, 2016 at 09:34:07PM -0400, Rich Felker wrote: > On Wed, Jun 01, 2016 at 05:36:19PM -0500, Rob Herring wrote: > > On Wed, Jun 1, 2016 at 12:53 PM, Rich Felker <dalias@libc.org> wrote: > > > On Wed, Jun 01, 2016 at 08:58:52AM -0500, Rob Herring wrote: > > >> On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote: > > >> > Signed-off-by: Rich Felker <dalias@libc.org> > > >> > --- > > >> > .../devicetree/bindings/timer/jcore,pit.txt | 28 ++++++++++++++++++++++ > > >> > 1 file changed, 28 insertions(+) > > >> > create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt > > >> > > > >> > diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt b/Documentation/devicetree/bindings/timer/jcore,pit.txt > > >> > new file mode 100644 > > >> > index 0000000..96c6815 > > >> > --- /dev/null > > >> > +++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt > > >> > @@ -0,0 +1,28 @@ > > >> > +J-Core Programmable Interval Timer and Clocksource > > >> > + > > >> > +Required properties: > > >> > + > > >> > +- compatible: Must be "jcore,pit". > > >> > + > > >> > +- reg: Memory region for timer/clocksource registers. > > >> > + > > >> > +- interrupts: An interrupt to assign for the timer. The actual pit > > >> > + core is integrated with the aic and allows the timer interrupt > > >> > + assignment to be programmed by software, but this property is > > >> > + required in order to reserve an interrupt number that doesn't > > >> > + conflict with other devices. > > >> > + > > >> > +Optional properties: > > >> > + > > >> > +- cpu-offset: For SMP, the per-cpu offset to the local timer > > >> > + programming memory range. > > >> > + > > >> > + > > >> > +Example: > > >> > + > > >> > +timer@200 { > > >> > + compatible = "jcore,pit"; > > >> > + reg = < 0x200 0x30 >; > > >> > + cpu-offset = < 0x300 >; > > >> > > >> This is outside the reg range. Perhaps reg should include each range of > > >> per cpu registers. > > > > > > In the hardware, each timer instance is mapped independently so > > > there's no fundamental reason they need to be mapped sufficiently > > > close that it would make sense for a single virtual mapping to cover > > > them all. This doesn't matter for nommu but it would with mmu in the > > > future. In the driver I've updated it to ioremap each percpu instance > > > separately (as its own memory range) using the cpu-offset applied to > > > the range obtained from "reg". Is this acceptable (in which case I > > > suppose the binding needs to be documented that "reg" just covers the > > > cpu0 instance's range)? Do you think it would be preferable to have > > > multiple "reg" ranges indexed by cpu instead of cpu-offset? > > > > Yes. Either reg should cover the full range of addresses or you should > > have multiple reg values with one for each cpu. I prefer the latter as > > it doesn't create a custom property for expressing register addresses. > > OK, let's lean towards going with the latter then. It's more flexible > and allows any placement of the maps; the offset per cpu does not have > to be constant. It also makes the driver code simpler since of_iomap > can be used directly rather than requiring of_address_to_resource, > physical address arithmetic arithmetic, and ioremap on the results. Is > there any precedent for using multiple reg ranges for percpu register > instances like this? Anything else they've been used for? Maybe the memory mapped ARM arch timer. I'm not too sure off hand. It is quite common for devices to have multiple reg addresses. > > > > In theory it would even be possible to just require a DT node per > > > cpulocal timer, but I didn't see a good way to make the bindings > > > represent the relationship to cpus or to make the driver handle irqs > > > correctly for such a setup, so I'd need a viable proposal for how that > > > could be done to even consider such an approach. > > > > Yeah, there's not really a standard way to map per cpu blocks to cpus. > > We could, but doesn't really seem necessary here. > > > > For the irqs, percpu irqs doesn't help you? > > What I mean is that, if there were a separate device node and driver > instance per cpu, they'd all want to register the same irq just to > handle it on their own cpu, so we'd have a lot of spurious handlers > running. The right way to model this, I think, would be as a virtual > irqchip that's the irq parent of all the timer nodes, and that > multiplexes the real irq to one virq per cpu (where the current cpu id > becomes the irq number in its irq domain). But that's a lot of virtual > infrastructure just for the sake of modelling each percpu timer as its > own DT node and I don't think it makes sense to do it that way. I would have thought your interrupt controller did all this. On the ARM GIC for example, you have the same irq number but there is a per cpu interface and really N (== # cpus) physical irq lines. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jun 02, 2016 at 05:44:25PM -0500, Rob Herring wrote: > > > > In theory it would even be possible to just require a DT node per > > > > cpulocal timer, but I didn't see a good way to make the bindings > > > > represent the relationship to cpus or to make the driver handle irqs > > > > correctly for such a setup, so I'd need a viable proposal for how that > > > > could be done to even consider such an approach. > > > > > > Yeah, there's not really a standard way to map per cpu blocks to cpus. > > > We could, but doesn't really seem necessary here. > > > > > > For the irqs, percpu irqs doesn't help you? > > > > What I mean is that, if there were a separate device node and driver > > instance per cpu, they'd all want to register the same irq just to > > handle it on their own cpu, so we'd have a lot of spurious handlers > > running. The right way to model this, I think, would be as a virtual > > irqchip that's the irq parent of all the timer nodes, and that > > multiplexes the real irq to one virq per cpu (where the current cpu id > > becomes the irq number in its irq domain). But that's a lot of virtual > > infrastructure just for the sake of modelling each percpu timer as its > > own DT node and I don't think it makes sense to do it that way. > > I would have thought your interrupt controller did all this. On the ARM > GIC for example, you have the same irq number but there is a per cpu > interface and really N (== # cpus) physical irq lines. I've looked at the ARM GIC code and bindings and I don't see where the per-cpu interrupt interfaces are modelled with multiple interrupt controller nodes or irq domains. It looks to me like it just uses a single interrupt controller/domain with percpu irq. Does that match your understanding? Rich -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jun 23, 2016 at 05:16:08PM -0400, Rich Felker wrote: > On Thu, Jun 02, 2016 at 05:44:25PM -0500, Rob Herring wrote: > > > > > In theory it would even be possible to just require a DT node per > > > > > cpulocal timer, but I didn't see a good way to make the bindings > > > > > represent the relationship to cpus or to make the driver handle irqs > > > > > correctly for such a setup, so I'd need a viable proposal for how that > > > > > could be done to even consider such an approach. > > > > > > > > Yeah, there's not really a standard way to map per cpu blocks to cpus. > > > > We could, but doesn't really seem necessary here. > > > > > > > > For the irqs, percpu irqs doesn't help you? > > > > > > What I mean is that, if there were a separate device node and driver > > > instance per cpu, they'd all want to register the same irq just to > > > handle it on their own cpu, so we'd have a lot of spurious handlers > > > running. The right way to model this, I think, would be as a virtual > > > irqchip that's the irq parent of all the timer nodes, and that > > > multiplexes the real irq to one virq per cpu (where the current cpu id > > > becomes the irq number in its irq domain). But that's a lot of virtual > > > infrastructure just for the sake of modelling each percpu timer as its > > > own DT node and I don't think it makes sense to do it that way. > > > > I would have thought your interrupt controller did all this. On the ARM > > GIC for example, you have the same irq number but there is a per cpu > > interface and really N (== # cpus) physical irq lines. > > I've looked at the ARM GIC code and bindings and I don't see where the > per-cpu interrupt interfaces are modelled with multiple interrupt > controller nodes or irq domains. It looks to me like it just uses a > single interrupt controller/domain with percpu irq. Does that match > your understanding? Ping. I want to submit this again for the upcoming merge window and need to know whether you still want me to pursue different approaches. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt b/Documentation/devicetree/bindings/timer/jcore,pit.txt new file mode 100644 index 0000000..96c6815 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt @@ -0,0 +1,28 @@ +J-Core Programmable Interval Timer and Clocksource + +Required properties: + +- compatible: Must be "jcore,pit". + +- reg: Memory region for timer/clocksource registers. + +- interrupts: An interrupt to assign for the timer. The actual pit + core is integrated with the aic and allows the timer interrupt + assignment to be programmed by software, but this property is + required in order to reserve an interrupt number that doesn't + conflict with other devices. + +Optional properties: + +- cpu-offset: For SMP, the per-cpu offset to the local timer + programming memory range. + + +Example: + +timer@200 { + compatible = "jcore,pit"; + reg = < 0x200 0x30 >; + cpu-offset = < 0x300 >; + interrupts = < 0x48 >; +};
Signed-off-by: Rich Felker <dalias@libc.org> --- .../devicetree/bindings/timer/jcore,pit.txt | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt