From: Mark Rutland <mark.rutland@arm.com> To: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Rob Herring <robh@kernel.org>, Alexander Kochetkov <al.kochet@gmail.com>, Heiko Stuebner <heiko@sntech.de>, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, Thomas Gleixner <tglx@linutronix.de>, Russell King <linux@armlinux.org.uk>, Caesar Wang <wxt@rock-chips.com>, Huang Tao <huangtao@rock-chips.com> Subject: Re: [PATCH v7 1/7] clocksource/drivers/clksrc-evt-probe: Describe with the DT both the clocksource and the clockevent Date: Wed, 29 Mar 2017 13:57:14 +0100 [thread overview] Message-ID: <20170329125713.GH23442@leverpostej> (raw) In-Reply-To: <20170329123638.GI2123@mai> On Wed, Mar 29, 2017 at 02:36:38PM +0200, Daniel Lezcano wrote: > On Wed, Mar 29, 2017 at 11:49:11AM +0100, Mark Rutland wrote: > > On Wed, Mar 29, 2017 at 11:22:10AM +0200, Daniel Lezcano wrote: > > > On Tue, Mar 28, 2017 at 08:51:46PM -0500, Rob Herring wrote: > > > > On Wed, Mar 22, 2017 at 06:48:28PM +0300, Alexander Kochetkov wrote: > > You can have several timers on the system and may want to use the clockevents > from one IP block and the clocksource from another IP block. For example, in > the case of a bogus clocksource. I understand this. However, what I was trying to say is that *how* we use a particular device should be a software decision. I have a more concrete suggestion on that below. > Moreover there are some drivers with a node for a clocksource and > another one for the clockevent, and the driver is assuming the clockevent is > defined first and then the clocksource. > > eg. > > arch/arc/boot/dts/abilis_tb10x.dtsi: > > /* TIMER0 with interrupt for clockevent */ > timer0 { > compatible = "snps,arc-timer"; > interrupts = <3>; > interrupt-parent = <&intc>; > clocks = <&cpu_clk>; > }; > > /* TIMER1 for free running clocksource */ > timer1 { > compatible = "snps,arc-timer"; > clocks = <&cpu_clk>; > }; > > drivers/clocksource/arc_timer.c: > > static int __init arc_of_timer_init(struct device_node *np) > { > static int init_count = 0; > int ret; > > if (!init_count) { > init_count = 1; > ret = arc_clockevent_setup(np); > } else { > ret = arc_cs_setup_timer1(np); > } > > return ret; > } > > Even if that works, it is a fragile mechanism. > > So the purpose of these changes is to provide a stronger timer declaration in > order to clearly split in the kernel a clocksource and a clockevent > initialization. I agree that this pattern is not nice. However, I think that splitting devices as this level makes the problem *worse*. Users care that they have a clocksource and a clockevent device. They do not care *which* particular device is used as either. The comments in the DT above are at best misleading. What we need is for the kernel to understand that devices can be both clockevent and clocksource (perhaps mutually exclusively), such that the kernel can decide how to make use of devices. That way, for the above the kernel can figure out that timer0 could be used as clocksource or clockevent, while timer1 can only be used as a clocksource due to the lack of an interrupt. Thus, it can choose to use timer0 as a clockevent, and timer1 and a clocksource. > > > > > With this approach, we allow a mechanism to clearly define a clocksource or a > > > > > clockevent without aerobatics we can find around in some drivers: > > > > > timer-sp804.c, arc-timer.c, dw_apb_timer_of.c, mps2-timer.c, > > > > > renesas-ostm.c, time-efm32.c, time-lpc32xx.c. > > > > > > > > These all already have bindings and work. What problem are you trying to > > > > solve other than restructuring Linux? > > > > > > Yes, there is already the bindings, but that force to do some hackish > > > initialization. > > > > Here, you are forcing hackish DT changes that do not truly describe HW. > > How is that better? > > So if this is hackish DT changes, then the existing DTs should be fixed, no? Yes. For the above snippet, the only thing that needs to change is the comment. > > > I would like to give the opportunity to declare separately a clocksource and a > > > clockevent, in order to have full control of how this is initialized. > > > > To me it sounds like what we need is Linux infrastructure that allows > > one to register a device as having both clockevent/clocksource > > functionality. > > That was the idea. Create a macro CLOCKEVENT_OF and CLOCKSOURCE_OF both of them > calling their respective init routines. And in addition a TIMER_OF doing both > CLOCKEVENT_OF and CLOCKSOURCE_OF. > > It is the DT which does not allow to do this separation. > > Would be the following approach more acceptable ? > > 1. Replace all CLOCKSOURCE_OF by TIMER_OF (just renaming) I am fine with this renaming. > 2. A node can have a clockevent and|or a clocksource attributes As above, this should not be in the DT given it's describing a (Linux-specific) SW policy and not a HW detail. So I must disagree with this. > 3. The timer_probe pass a flag to the driver's init function, so this one knows > if it should invoke the clockevent/clocksource init functions. > No attribute defaults to clocksource|clockevent. > > That would be backward compatible and will let to create drivers with clutch > activated device via DT. Also, it will give the opportunity to the existing > drivers to change consolidate their initialization routines. I think that if anything, we need a combined clocksource+clockevent device that we register to the core code. That means all clocksource/clockevent drivers have a consolidated routine. Subsequently, core code should determine how specifically to use the device (e.g. based on what other devices are registered, and their capabilities). Thanks, Mark.
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v7 1/7] clocksource/drivers/clksrc-evt-probe: Describe with the DT both the clocksource and the clockevent Date: Wed, 29 Mar 2017 13:57:14 +0100 [thread overview] Message-ID: <20170329125713.GH23442@leverpostej> (raw) In-Reply-To: <20170329123638.GI2123@mai> On Wed, Mar 29, 2017 at 02:36:38PM +0200, Daniel Lezcano wrote: > On Wed, Mar 29, 2017 at 11:49:11AM +0100, Mark Rutland wrote: > > On Wed, Mar 29, 2017 at 11:22:10AM +0200, Daniel Lezcano wrote: > > > On Tue, Mar 28, 2017 at 08:51:46PM -0500, Rob Herring wrote: > > > > On Wed, Mar 22, 2017 at 06:48:28PM +0300, Alexander Kochetkov wrote: > > You can have several timers on the system and may want to use the clockevents > from one IP block and the clocksource from another IP block. For example, in > the case of a bogus clocksource. I understand this. However, what I was trying to say is that *how* we use a particular device should be a software decision. I have a more concrete suggestion on that below. > Moreover there are some drivers with a node for a clocksource and > another one for the clockevent, and the driver is assuming the clockevent is > defined first and then the clocksource. > > eg. > > arch/arc/boot/dts/abilis_tb10x.dtsi: > > /* TIMER0 with interrupt for clockevent */ > timer0 { > compatible = "snps,arc-timer"; > interrupts = <3>; > interrupt-parent = <&intc>; > clocks = <&cpu_clk>; > }; > > /* TIMER1 for free running clocksource */ > timer1 { > compatible = "snps,arc-timer"; > clocks = <&cpu_clk>; > }; > > drivers/clocksource/arc_timer.c: > > static int __init arc_of_timer_init(struct device_node *np) > { > static int init_count = 0; > int ret; > > if (!init_count) { > init_count = 1; > ret = arc_clockevent_setup(np); > } else { > ret = arc_cs_setup_timer1(np); > } > > return ret; > } > > Even if that works, it is a fragile mechanism. > > So the purpose of these changes is to provide a stronger timer declaration in > order to clearly split in the kernel a clocksource and a clockevent > initialization. I agree that this pattern is not nice. However, I think that splitting devices as this level makes the problem *worse*. Users care that they have a clocksource and a clockevent device. They do not care *which* particular device is used as either. The comments in the DT above are at best misleading. What we need is for the kernel to understand that devices can be both clockevent and clocksource (perhaps mutually exclusively), such that the kernel can decide how to make use of devices. That way, for the above the kernel can figure out that timer0 could be used as clocksource or clockevent, while timer1 can only be used as a clocksource due to the lack of an interrupt. Thus, it can choose to use timer0 as a clockevent, and timer1 and a clocksource. > > > > > With this approach, we allow a mechanism to clearly define a clocksource or a > > > > > clockevent without aerobatics we can find around in some drivers: > > > > > timer-sp804.c, arc-timer.c, dw_apb_timer_of.c, mps2-timer.c, > > > > > renesas-ostm.c, time-efm32.c, time-lpc32xx.c. > > > > > > > > These all already have bindings and work. What problem are you trying to > > > > solve other than restructuring Linux? > > > > > > Yes, there is already the bindings, but that force to do some hackish > > > initialization. > > > > Here, you are forcing hackish DT changes that do not truly describe HW. > > How is that better? > > So if this is hackish DT changes, then the existing DTs should be fixed, no? Yes. For the above snippet, the only thing that needs to change is the comment. > > > I would like to give the opportunity to declare separately a clocksource and a > > > clockevent, in order to have full control of how this is initialized. > > > > To me it sounds like what we need is Linux infrastructure that allows > > one to register a device as having both clockevent/clocksource > > functionality. > > That was the idea. Create a macro CLOCKEVENT_OF and CLOCKSOURCE_OF both of them > calling their respective init routines. And in addition a TIMER_OF doing both > CLOCKEVENT_OF and CLOCKSOURCE_OF. > > It is the DT which does not allow to do this separation. > > Would be the following approach more acceptable ? > > 1. Replace all CLOCKSOURCE_OF by TIMER_OF (just renaming) I am fine with this renaming. > 2. A node can have a clockevent and|or a clocksource attributes As above, this should not be in the DT given it's describing a (Linux-specific) SW policy and not a HW detail. So I must disagree with this. > 3. The timer_probe pass a flag to the driver's init function, so this one knows > if it should invoke the clockevent/clocksource init functions. > No attribute defaults to clocksource|clockevent. > > That would be backward compatible and will let to create drivers with clutch > activated device via DT. Also, it will give the opportunity to the existing > drivers to change consolidate their initialization routines. I think that if anything, we need a combined clocksource+clockevent device that we register to the core code. That means all clocksource/clockevent drivers have a consolidated routine. Subsequently, core code should determine how specifically to use the device (e.g. based on what other devices are registered, and their capabilities). Thanks, Mark.
next prev parent reply other threads:[~2017-03-29 12:57 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-22 15:48 [PATCH v7 0/7] Implement clocksource for rockchip SoC using rockchip timer Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` [PATCH v7 1/7] clocksource/drivers/clksrc-evt-probe: Describe with the DT both the clocksource and the clockevent Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-29 1:51 ` Rob Herring 2017-03-29 1:51 ` Rob Herring 2017-03-29 1:51 ` Rob Herring 2017-03-29 9:22 ` Daniel Lezcano 2017-03-29 9:22 ` Daniel Lezcano 2017-03-29 9:22 ` Daniel Lezcano 2017-03-29 10:49 ` Mark Rutland 2017-03-29 10:49 ` Mark Rutland 2017-03-29 10:49 ` Mark Rutland 2017-03-29 12:36 ` Daniel Lezcano 2017-03-29 12:36 ` Daniel Lezcano 2017-03-29 12:36 ` Daniel Lezcano 2017-03-29 12:57 ` Mark Rutland [this message] 2017-03-29 12:57 ` Mark Rutland 2017-03-29 13:41 ` Daniel Lezcano 2017-03-29 13:41 ` Daniel Lezcano 2017-03-29 13:41 ` Daniel Lezcano 2017-03-29 14:34 ` Mark Rutland 2017-03-29 14:34 ` Mark Rutland 2017-03-29 14:34 ` Mark Rutland 2017-03-22 15:48 ` [PATCH v7 2/7] dt-bindings: clarify compatible property for rockchip timers Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` [PATCH v7 3/7] ARM: dts: rockchip: update compatible property for rk322x timer Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` [PATCH v7 4/7] ARM: dts: rockchip: add clockevent attribute to rockchip timers Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` [PATCH v7 5/7] clocksource/drivers/rockchip_timer: implement clocksource timer Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-24 8:29 ` kbuild test robot 2017-03-24 8:29 ` kbuild test robot 2017-03-24 8:29 ` kbuild test robot 2017-03-24 8:41 ` Alexander Kochetkov 2017-03-24 8:41 ` Alexander Kochetkov 2017-03-24 8:41 ` Alexander Kochetkov 2017-03-24 8:55 ` Daniel Lezcano 2017-03-24 8:55 ` Daniel Lezcano 2017-03-24 8:55 ` Daniel Lezcano 2017-03-22 15:48 ` [PATCH v7 6/7] ARM: dts: rockchip: add timer entries to rk3188 SoC Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` [PATCH v7 7/7] ARM: dts: rockchip: disable arm-global-timer for rk3188 Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-22 15:48 ` Alexander Kochetkov 2017-03-29 13:22 ` [PATCH v7 0/7] Implement clocksource for rockchip SoC using rockchip timer Alexander Kochetkov 2017-03-29 13:22 ` Alexander Kochetkov 2017-03-30 9:26 ` Daniel Lezcano 2017-03-30 9:26 ` Daniel Lezcano 2017-03-30 9:26 ` Daniel Lezcano
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170329125713.GH23442@leverpostej \ --to=mark.rutland@arm.com \ --cc=al.kochet@gmail.com \ --cc=daniel.lezcano@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=heiko@sntech.de \ --cc=huangtao@rock-chips.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=linux@armlinux.org.uk \ --cc=robh@kernel.org \ --cc=tglx@linutronix.de \ --cc=wxt@rock-chips.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.