All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Josh Cartwright <joshc@codeaurora.org>
Cc: Kumar Gala <galak@codeaurora.org>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	linux-arm-msm@vger.kernel.org,
	Russell King <linux@arm.linux.org.uk>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] ARM: qcom: add description of KPSS WDT for IPQ8064
Date: Thu, 02 Oct 2014 12:08:38 -0700	[thread overview]
Message-ID: <542DA2B6.3020201@codeaurora.org> (raw)
In-Reply-To: <20141001181557.GQ868@joshc.qualcomm.com>

On 10/01/14 11:15, Josh Cartwright wrote:
> Yeah, the description of this thing is a bit awkward.

:-/ I tried to make the binding future proof.

>
> I'm not sure how I'd feel about just just adding "qcom,kpss-wdt" to the
> timer node compatible.  I'm wondering if the WDT(s) should be a
> subnode(s) of the timer node instead?

But then we don't make the timers subnodes? That seems odd. What's the
benefit of multiple sub-nodes for the watchdogs?

It would also be fine to use the current compatible string and just
append the extra two interrupts for the two watchdogs and then make an
optional clocks property and deprecate the clock-frequency property.

>
> The percpu-ness of the two WDTs makes configuration even more
> interesting, as it's possible you'd want to independently configure
> timeouts for CPU0_WDT0 and CPU1_WDT0, supporting this with a coalesced
> timer/wdt would be cumbersome.

We already do similar things for the timers on each cpu. It doesn't seem
that bad, but that's a matter of opinion.

>
> Something like this perhaps:
>
> 	timer@200a000 {
> 		compatible = "qcom,kpss-timer", "qcom,msm-timer";
> 		interrupts = <1 1 0x301>,
> 			     <1 2 0x301>,
> 			     <1 3 0x301>;
> 		reg = <0x0200a000 0x100>;
> 		clock-frequency = <25000000>,
> 				  <32768>;
> 		cpu-offset = <0x80000>;
>
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 		ranges;
>
> 		cpu0_wdt0: watchdog@208a038 {
> 			compatible = "qcom,kpss-wdt";
> 			reg = <0x208a038 0x40>;
> 			interrupts = <1 4 0x301>,
> 			clocks = <&sleep_clk>;
> 			timeout-sec = <10>;
> 			cpu = <&cpu0>;
> 		};
>
> 		cpu0_wdt1: watchdog@208a060 {
> 			compatible = "qcom,kpss-wdt";
> 			reg = <0x208a060 0x40>;
> 			interrupts = <1 5 0x301>,
> 			clocks = <&sleep_clk>;
> 			timeout-sec = <20>;
> 			cpu = <&cpu0>;
> 		};
>
> 		cpu1_wdt0: watchdog@209a038 {
> 			compatible = "qcom,kpss-wdt";
> 			reg = <0x209a038 0x40>;
> 			interrupts = <1 4 0x301>,
> 			clocks = <&sleep_clk>;
> 			timeout-sec = <8>;
> 			cpu = <&cpu1>;
> 		};
>
> 		cpu1_wdt1: watchdog@209a060 {
> 			compatible = "qcom,kpss-wdt";
> 			reg = <0x209a060 0x40>;
> 			interrupts = <1 5 0x301>,
> 			clocks = <&sleep_clk>;
> 			timeout-sec = <15>;
> 			cpu = <&cpu1>;
> 		};
> 	};
>
>

I'm thinking:

                timer@200a000 {
                        compatible = "qcom,kpss-timer", "qcom,msm-timer";
                        interrupts = <1 1 0x301>,
                                     <1 2 0x301>,
                                     <1 3 0x301>,
				     <1 4 0x301>,
				     <1 5 0x301>;
                        reg = <0x0200a000 0x100>;
                        clock-frequency = <27000000>,
                                          <32768>;
			clocks = <&cxo>, <&sleep_clk>;
			clock-names = "ref", "sleep";
                        cpu-offset = <0x80000>;
                };

Can you explain the need for the cpu handle? Luckily this device only
exists in configurations that have up to 4 CPUs and so mapping the
logical CPU number to the watchdog for that CPU is "easy" in that we can
convert the CPU from logical to physical and then do the math taking
into account the cpu-offset to figure out where the non-aliased
registers are. Once we get into pairs of watchdogs for different
clusters this isn't so easy and it's better to have the phandle
somewhere (either in the watchdog node or the cpu node) and then have
multiple nodes for the watchdog block per-cpu so that we can map the CPU
to the device. We realized this when making the saw binding.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] ARM: qcom: add description of KPSS WDT for IPQ8064
Date: Thu, 02 Oct 2014 12:08:38 -0700	[thread overview]
Message-ID: <542DA2B6.3020201@codeaurora.org> (raw)
In-Reply-To: <20141001181557.GQ868@joshc.qualcomm.com>

On 10/01/14 11:15, Josh Cartwright wrote:
> Yeah, the description of this thing is a bit awkward.

:-/ I tried to make the binding future proof.

>
> I'm not sure how I'd feel about just just adding "qcom,kpss-wdt" to the
> timer node compatible.  I'm wondering if the WDT(s) should be a
> subnode(s) of the timer node instead?

But then we don't make the timers subnodes? That seems odd. What's the
benefit of multiple sub-nodes for the watchdogs?

It would also be fine to use the current compatible string and just
append the extra two interrupts for the two watchdogs and then make an
optional clocks property and deprecate the clock-frequency property.

>
> The percpu-ness of the two WDTs makes configuration even more
> interesting, as it's possible you'd want to independently configure
> timeouts for CPU0_WDT0 and CPU1_WDT0, supporting this with a coalesced
> timer/wdt would be cumbersome.

We already do similar things for the timers on each cpu. It doesn't seem
that bad, but that's a matter of opinion.

>
> Something like this perhaps:
>
> 	timer at 200a000 {
> 		compatible = "qcom,kpss-timer", "qcom,msm-timer";
> 		interrupts = <1 1 0x301>,
> 			     <1 2 0x301>,
> 			     <1 3 0x301>;
> 		reg = <0x0200a000 0x100>;
> 		clock-frequency = <25000000>,
> 				  <32768>;
> 		cpu-offset = <0x80000>;
>
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 		ranges;
>
> 		cpu0_wdt0: watchdog at 208a038 {
> 			compatible = "qcom,kpss-wdt";
> 			reg = <0x208a038 0x40>;
> 			interrupts = <1 4 0x301>,
> 			clocks = <&sleep_clk>;
> 			timeout-sec = <10>;
> 			cpu = <&cpu0>;
> 		};
>
> 		cpu0_wdt1: watchdog at 208a060 {
> 			compatible = "qcom,kpss-wdt";
> 			reg = <0x208a060 0x40>;
> 			interrupts = <1 5 0x301>,
> 			clocks = <&sleep_clk>;
> 			timeout-sec = <20>;
> 			cpu = <&cpu0>;
> 		};
>
> 		cpu1_wdt0: watchdog at 209a038 {
> 			compatible = "qcom,kpss-wdt";
> 			reg = <0x209a038 0x40>;
> 			interrupts = <1 4 0x301>,
> 			clocks = <&sleep_clk>;
> 			timeout-sec = <8>;
> 			cpu = <&cpu1>;
> 		};
>
> 		cpu1_wdt1: watchdog at 209a060 {
> 			compatible = "qcom,kpss-wdt";
> 			reg = <0x209a060 0x40>;
> 			interrupts = <1 5 0x301>,
> 			clocks = <&sleep_clk>;
> 			timeout-sec = <15>;
> 			cpu = <&cpu1>;
> 		};
> 	};
>
>

I'm thinking:

                timer at 200a000 {
                        compatible = "qcom,kpss-timer", "qcom,msm-timer";
                        interrupts = <1 1 0x301>,
                                     <1 2 0x301>,
                                     <1 3 0x301>,
				     <1 4 0x301>,
				     <1 5 0x301>;
                        reg = <0x0200a000 0x100>;
                        clock-frequency = <27000000>,
                                          <32768>;
			clocks = <&cxo>, <&sleep_clk>;
			clock-names = "ref", "sleep";
                        cpu-offset = <0x80000>;
                };

Can you explain the need for the cpu handle? Luckily this device only
exists in configurations that have up to 4 CPUs and so mapping the
logical CPU number to the watchdog for that CPU is "easy" in that we can
convert the CPU from logical to physical and then do the math taking
into account the cpu-offset to figure out where the non-aliased
registers are. Once we get into pairs of watchdogs for different
clusters this isn't so easy and it's better to have the phandle
somewhere (either in the watchdog node or the cpu node) and then have
multiple nodes for the watchdog block per-cpu so that we can map the CPU
to the device. We realized this when making the saw binding.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-10-02 19:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-01 17:03 [PATCH 0/4] Add KPSS watchdog driver to relevant device trees Josh Cartwright
2014-10-01 17:03 ` Josh Cartwright
2014-10-01 17:03 ` [PATCH 1/4] ARM: qcom: add QCOM_WDT driver to qcom_defconfig Josh Cartwright
2014-10-01 17:03   ` Josh Cartwright
2014-10-01 17:03 ` [PATCH 2/4] ARM: qcom: add description of KPSS WDT for IPQ8064 Josh Cartwright
2014-10-01 17:03   ` Josh Cartwright
     [not found]   ` <50c0ec1514173ce07641a95839e939dcda41b110.1412182773.git.joshc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-10-01 17:28     ` Stephen Boyd
2014-10-01 17:28       ` Stephen Boyd
2014-10-01 17:28       ` Stephen Boyd
2014-10-01 18:15       ` Josh Cartwright
2014-10-01 18:15         ` Josh Cartwright
2014-10-02 19:08         ` Stephen Boyd [this message]
2014-10-02 19:08           ` Stephen Boyd
2014-10-07 22:10           ` Josh Cartwright
2014-10-07 22:10             ` Josh Cartwright
2014-10-07 23:07             ` Stephen Boyd
2014-10-07 23:07               ` Stephen Boyd
     [not found]               ` <5434723F.70800-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-10-08 16:06                 ` Josh Cartwright
2014-10-08 16:06                   ` Josh Cartwright
2014-10-08 16:06                   ` Josh Cartwright
2014-10-01 17:03 ` [PATCH 3/4] ARM: qcom: add description of KPSS WDT for APQ8064 Josh Cartwright
2014-10-01 17:03   ` Josh Cartwright
2014-10-01 17:03   ` Josh Cartwright
2014-10-01 17:03 ` [PATCH 4/4] ARM: qcom: add description of KPSS WDT for MSM8960 Josh Cartwright
2014-10-01 17:03   ` Josh Cartwright
2014-10-01 17:03   ` Josh Cartwright

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=542DA2B6.3020201@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=joshc@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    /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: link
Be 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.