| Message ID | 20210628061410.8009-2-shruthi.sanil@intel.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | Add the driver for Intel Keem Bay SoC timer block | expand |
| Context | Check | Description |
|---|---|---|
| robh/dt-meta-schema | success | |
| robh/dtbs-check | success | |
| robh/checkpatch | success |
On Mon, Jun 28, 2021 at 11:44:09AM +0530, shruthi.sanil@intel.com wrote: > From: Shruthi Sanil <shruthi.sanil@intel.com> > > Add Device Tree bindings for the Timer IP, which can be used as > clocksource and clockevent device in the Intel Keem Bay SoC. > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> > Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> > --- > .../bindings/timer/intel,keembay-timer.yaml | 170 ++++++++++++++++++ > 1 file changed, 170 insertions(+) > create mode 100644 Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml > > diff --git a/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml b/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml > new file mode 100644 > index 000000000000..24c149a4d220 > --- /dev/null > +++ b/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml > @@ -0,0 +1,170 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/timer/intel,keembay-timer.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Intel Keem Bay SoC Timers > + > +maintainers: > + - Shruthi Sanil <shruthi.sanil@intel.com> > + > +description: | > + The Intel Keem Bay timer driver supports clocksource and clockevent > + features for the timer IP used in Intel Keembay SoC. > + The timer block supports 1 free running counter and 8 timers. > + The free running counter can be used as a clocksouce and > + the timers can be used as clockevent. Each timer is capable of > + generating inividual interrupt. clockevent and clocksource are Linuxisms. Don't use them in bindings. > + Both the features are enabled through the timer general config register. > + > + The parent node represents the common general configuration details and > + the child nodes represents the counter and timers. I don't think all the child nodes are necessary. Are the counters and timers configurable (say on another SoC)? If not, then a single node here would suffice. > + > +properties: > + reg: > + description: General configuration register address and length. > + maxItems: 1 > + > + ranges: true > + > + "#address-cells": > + const: 2 > + > + "#size-cells": > + const: 2 > + > +required: > + - reg > + - ranges > + - "#address-cells" > + - "#size-cells" > + > +patternProperties: > + "^counter@[0-9a-f]+$": > + type: object > + description: Properties for Intel Keem Bay counter > + > + properties: > + compatible: > + enum: > + - intel,keembay-counter > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + required: > + - compatible > + - reg > + - clocks > + > + "^timer@[0-9a-f]+$": > + type: object > + description: Properties for Intel Keem Bay timer > + > + properties: > + compatible: > + enum: > + - intel,keembay-timer > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + required: > + - compatible > + - reg > + - interrupts > + - clocks > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + #include <dt-bindings/interrupt-controller/irq.h> > + #define KEEM_BAY_A53_TIM > + > + soc { > + #address-cells = <0x2>; > + #size-cells = <0x2>; > + > + gpt@20331000 { > + reg = <0x0 0x20331000 0x0 0xc>; > + ranges = <0x0 0x0 0x20330000 0xF0>; > + #address-cells = <0x1>; > + #size-cells = <0x1>; > + > + counter@203300e8 { The unit address here is wrong. Should be 'e8'. > + compatible = "intel,keembay-counter"; > + reg = <0xe8 0x8>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + > + timer@20330010 { > + compatible = "intel,keembay-timer"; > + reg = <0x10 0xc>; > + interrupts = <GIC_SPI 0x3 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + > + timer@20330020 { > + compatible = "intel,keembay-timer"; > + reg = <0x20 0xc>; > + interrupts = <GIC_SPI 0x4 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + > + timer@20330030 { > + compatible = "intel,keembay-timer"; > + reg = <0x30 0xc>; > + interrupts = <GIC_SPI 0x5 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + > + timer@20330040 { > + compatible = "intel,keembay-timer"; > + reg = <0x40 0xc>; > + interrupts = <GIC_SPI 0x6 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + > + timer@20330050 { > + compatible = "intel,keembay-timer"; > + reg = <0x50 0xc>; > + interrupts = <GIC_SPI 0x7 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + > + timer@20330060 { > + compatible = "intel,keembay-timer"; > + reg = <0x60 0xc>; > + interrupts = <GIC_SPI 0x8 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + > + timer@20330070 { > + compatible = "intel,keembay-timer"; > + reg = <0x70 0xc>; > + interrupts = <GIC_SPI 0x9 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + > + timer@20330080 { > + compatible = "intel,keembay-timer"; > + reg = <0x80 0xc>; > + interrupts = <GIC_SPI 0xa IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; > + }; > + }; > + }; > + > +... > -- > 2.17.1 > >
On Tue, Jul 13, 2021 at 08:47:56PM -0600, Rob Herring wrote: > On Mon, Jun 28, 2021 at 11:44:09AM +0530, shruthi.sanil@intel.com wrote: > > + The parent node represents the common general configuration details and > > + the child nodes represents the counter and timers. > > I don't think all the child nodes are necessary. Are the counters and > timers configurable (say on another SoC)? If not, then a single node > here would suffice. If you may notice the children may have different properties that can't be known ahead, such as IRQ line. On some platforms it may be this mapping, on another it maybe different. With all respect for the simplification I think we can't do it here.
On Wed, Jul 14, 2021 at 3:04 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Tue, Jul 13, 2021 at 08:47:56PM -0600, Rob Herring wrote: > > On Mon, Jun 28, 2021 at 11:44:09AM +0530, shruthi.sanil@intel.com wrote: > > > > + The parent node represents the common general configuration details and > > > + the child nodes represents the counter and timers. > > > > I don't think all the child nodes are necessary. Are the counters and > > timers configurable (say on another SoC)? If not, then a single node > > here would suffice. > > If you may notice the children may have different properties that can't be > known ahead, such as IRQ line. On some platforms it may be this mapping, on > another it maybe different. What I noticed is it's all the same clock and 1 interrupt for each timer can be just a single 'interrupts' property with 8 entries. Is there a platform that's different or that's a hypothetical? Because hypothetically, every aspect of every IP could change. But we don't try to parameterize everything in DT. It's a judgement call between implying things from compatible and explicit DT properties. > With all respect for the simplification I think we can't do it here. You can. Any data in DT could be in the kernel. It's a question of balance, not can or can't. Rob
On Wed, Jul 14, 2021 at 08:07:44AM -0600, Rob Herring wrote: > On Wed, Jul 14, 2021 at 3:04 AM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Tue, Jul 13, 2021 at 08:47:56PM -0600, Rob Herring wrote: > > > On Mon, Jun 28, 2021 at 11:44:09AM +0530, shruthi.sanil@intel.com wrote: > > > > > > + The parent node represents the common general configuration details and > > > > + the child nodes represents the counter and timers. > > > > > > I don't think all the child nodes are necessary. Are the counters and > > > timers configurable (say on another SoC)? If not, then a single node > > > here would suffice. > > > > If you may notice the children may have different properties that can't be > > known ahead, such as IRQ line. On some platforms it may be this mapping, on > > another it maybe different. > > What I noticed is it's all the same clock and 1 interrupt for each > timer can be just a single 'interrupts' property with 8 entries. This may work. > Is there a platform that's different or that's a hypothetical? Because > hypothetically, every aspect of every IP could change. But we don't > try to parameterize everything in DT. It's a judgement call between > implying things from compatible and explicit DT properties. > > > With all respect for the simplification I think we can't do it here. > > You can. Any data in DT could be in the kernel. It's a question of > balance, not can or can't. Not only, it's also matters of what exactly hardware is: 8 timers or timer with 8 channels. If it's the former one, I prefer to have DT exactly like originally suggested, otherwise I will agree on your proposal.
> -----Original Message----- > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Sent: Wednesday, July 14, 2021 7:51 PM > To: Rob Herring <robh@kernel.org> > Cc: Sanil, Shruthi <shruthi.sanil@intel.com>; Daniel Lezcano > <daniel.lezcano@linaro.org>; Thomas Gleixner <tglx@linutronix.de>; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org; > kris.pan@linux.intel.com; Mark Gross <mgross@linux.intel.com>; Thokala, > Srikanth <srikanth.thokala@intel.com>; Raja Subramanian, Lakshmi Bai > <lakshmi.bai.raja.subramanian@intel.com>; Sangannavar, Mallikarjunappa > <mallikarjunappa.sangannavar@intel.com> > Subject: Re: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel Keem > Bay SoC Timer > > On Wed, Jul 14, 2021 at 08:07:44AM -0600, Rob Herring wrote: > > On Wed, Jul 14, 2021 at 3:04 AM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Tue, Jul 13, 2021 at 08:47:56PM -0600, Rob Herring wrote: > > > > On Mon, Jun 28, 2021 at 11:44:09AM +0530, shruthi.sanil@intel.com > wrote: > > > > > > > > + The parent node represents the common general configuration > > > > > + details and the child nodes represents the counter and timers. > > > > > > > > I don't think all the child nodes are necessary. Are the counters > > > > and timers configurable (say on another SoC)? If not, then a > > > > single node here would suffice. > > > > > > If you may notice the children may have different properties that > > > can't be known ahead, such as IRQ line. On some platforms it may be > > > this mapping, on another it maybe different. > > > > What I noticed is it's all the same clock and 1 interrupt for each > > timer can be just a single 'interrupts' property with 8 entries. > > This may work. > > > Is there a platform that's different or that's a hypothetical? Because > > hypothetically, every aspect of every IP could change. But we don't > > try to parameterize everything in DT. It's a judgement call between > > implying things from compatible and explicit DT properties. > > > > > With all respect for the simplification I think we can't do it here. > > > > You can. Any data in DT could be in the kernel. It's a question of > > balance, not can or can't. > > Not only, it's also matters of what exactly hardware is: 8 timers or timer with > 8 channels. If it's the former one, I prefer to have DT exactly like originally > suggested, otherwise I will agree on your proposal. Yes Andy, its correct, we have 8 timers in the hardware which are independent. Also the timer framework provides option to parse all the device tree details. In this case we would pass the timer node to the framework and get the base, IRQ and clock. If we go for a single node approach then all these need to be handled in the driver, hence making it complicated. Regards, Shruthi > > -- > With Best Regards, > Andy Shevchenko >
> -----Original Message----- > From: Sanil, Shruthi > Sent: Thursday, July 15, 2021 1:32 PM > To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Rob Herring > <robh@kernel.org> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org>; Thomas Gleixner > <tglx@linutronix.de>; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; kris.pan@linux.intel.com; Mark Gross > <mgross@linux.intel.com>; Thokala, Srikanth <Srikanth.Thokala@intel.com>; > Raja Subramanian, Lakshmi Bai <lakshmi.bai.raja.subramanian@intel.com>; > Sangannavar, Mallikarjunappa <mallikarjunappa.sangannavar@intel.com> > Subject: RE: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel Keem > Bay SoC Timer > > > -----Original Message----- > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Sent: Wednesday, July 14, 2021 7:51 PM > > To: Rob Herring <robh@kernel.org> > > Cc: Sanil, Shruthi <shruthi.sanil@intel.com>; Daniel Lezcano > > <daniel.lezcano@linaro.org>; Thomas Gleixner <tglx@linutronix.de>; > > linux- kernel@vger.kernel.org; devicetree@vger.kernel.org; > > kris.pan@linux.intel.com; Mark Gross <mgross@linux.intel.com>; > > Thokala, Srikanth <srikanth.thokala@intel.com>; Raja Subramanian, > > Lakshmi Bai <lakshmi.bai.raja.subramanian@intel.com>; Sangannavar, > > Mallikarjunappa <mallikarjunappa.sangannavar@intel.com> > > Subject: Re: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel > > Keem Bay SoC Timer > > > > On Wed, Jul 14, 2021 at 08:07:44AM -0600, Rob Herring wrote: > > > On Wed, Jul 14, 2021 at 3:04 AM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > On Tue, Jul 13, 2021 at 08:47:56PM -0600, Rob Herring wrote: > > > > > On Mon, Jun 28, 2021 at 11:44:09AM +0530, > > > > > shruthi.sanil@intel.com > > wrote: > > > > > > > > > > + The parent node represents the common general configuration > > > > > > + details and the child nodes represents the counter and timers. > > > > > > > > > > I don't think all the child nodes are necessary. Are the > > > > > counters and timers configurable (say on another SoC)? If not, > > > > > then a single node here would suffice. > > > > > > > > If you may notice the children may have different properties that > > > > can't be known ahead, such as IRQ line. On some platforms it may > > > > be this mapping, on another it maybe different. > > > > > > What I noticed is it's all the same clock and 1 interrupt for each > > > timer can be just a single 'interrupts' property with 8 entries. > > > > This may work. > > > > > Is there a platform that's different or that's a hypothetical? > > > Because hypothetically, every aspect of every IP could change. But > > > we don't try to parameterize everything in DT. It's a judgement call > > > between implying things from compatible and explicit DT properties. > > > > > > > With all respect for the simplification I think we can't do it here. > > > > > > You can. Any data in DT could be in the kernel. It's a question of > > > balance, not can or can't. > > > > Not only, it's also matters of what exactly hardware is: 8 timers or > > timer with > > 8 channels. If it's the former one, I prefer to have DT exactly like > > originally suggested, otherwise I will agree on your proposal. > > Yes Andy, its correct, we have 8 timers in the hardware which are > independent. > Also the timer framework provides option to parse all the device tree details. > In this case we would pass the timer node to the framework and get the > base, IRQ and clock. If we go for a single node approach then all these need > to be handled in the driver, hence making it complicated. > Hi Rob, Yes, the counter and timers are configurable on another SoC. Do you give a nod on the current design? Shall I proceed with submitting the next version addressing the other 2 comments of yours regarding the description and the unit address update? > Regards, > Shruthi > > > > > -- > > With Best Regards, > > Andy Shevchenko > >
diff --git a/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml b/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml new file mode 100644 index 000000000000..24c149a4d220 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/intel,keembay-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Keem Bay SoC Timers + +maintainers: + - Shruthi Sanil <shruthi.sanil@intel.com> + +description: | + The Intel Keem Bay timer driver supports clocksource and clockevent + features for the timer IP used in Intel Keembay SoC. + The timer block supports 1 free running counter and 8 timers. + The free running counter can be used as a clocksouce and + the timers can be used as clockevent. Each timer is capable of + generating inividual interrupt. + Both the features are enabled through the timer general config register. + + The parent node represents the common general configuration details and + the child nodes represents the counter and timers. + +properties: + reg: + description: General configuration register address and length. + maxItems: 1 + + ranges: true + + "#address-cells": + const: 2 + + "#size-cells": + const: 2 + +required: + - reg + - ranges + - "#address-cells" + - "#size-cells" + +patternProperties: + "^counter@[0-9a-f]+$": + type: object + description: Properties for Intel Keem Bay counter + + properties: + compatible: + enum: + - intel,keembay-counter + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + required: + - compatible + - reg + - clocks + + "^timer@[0-9a-f]+$": + type: object + description: Properties for Intel Keem Bay timer + + properties: + compatible: + enum: + - intel,keembay-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #define KEEM_BAY_A53_TIM + + soc { + #address-cells = <0x2>; + #size-cells = <0x2>; + + gpt@20331000 { + reg = <0x0 0x20331000 0x0 0xc>; + ranges = <0x0 0x0 0x20330000 0xF0>; + #address-cells = <0x1>; + #size-cells = <0x1>; + + counter@203300e8 { + compatible = "intel,keembay-counter"; + reg = <0xe8 0x8>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + + timer@20330010 { + compatible = "intel,keembay-timer"; + reg = <0x10 0xc>; + interrupts = <GIC_SPI 0x3 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + + timer@20330020 { + compatible = "intel,keembay-timer"; + reg = <0x20 0xc>; + interrupts = <GIC_SPI 0x4 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + + timer@20330030 { + compatible = "intel,keembay-timer"; + reg = <0x30 0xc>; + interrupts = <GIC_SPI 0x5 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + + timer@20330040 { + compatible = "intel,keembay-timer"; + reg = <0x40 0xc>; + interrupts = <GIC_SPI 0x6 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + + timer@20330050 { + compatible = "intel,keembay-timer"; + reg = <0x50 0xc>; + interrupts = <GIC_SPI 0x7 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + + timer@20330060 { + compatible = "intel,keembay-timer"; + reg = <0x60 0xc>; + interrupts = <GIC_SPI 0x8 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + + timer@20330070 { + compatible = "intel,keembay-timer"; + reg = <0x70 0xc>; + interrupts = <GIC_SPI 0x9 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + + timer@20330080 { + compatible = "intel,keembay-timer"; + reg = <0x80 0xc>; + interrupts = <GIC_SPI 0xa IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk KEEM_BAY_A53_TIM>; + }; + }; + }; + +...