From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes
Date: Sat, 28 Nov 2015 12:36:16 +0100 [thread overview]
Message-ID: <565991B0.5030909@gmail.com> (raw)
In-Reply-To: <20151123125953.5c30a0ef@xhacker>
On 23.11.2015 05:59, Jisheng Zhang wrote:
> On Fri, 20 Nov 2015 21:19:46 +0100
> Sebastian Hesselbarth wrote:
>> On 20.11.2015 04:34, Jisheng Zhang wrote:
>>> On Thu, 19 Nov 2015 21:47:05 +0100
>>> Sebastian Hesselbarth wrote:
>>>> On 16.11.2015 12:09, Jisheng Zhang wrote:
>>>>> The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
>>>>> snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
>>>>> corresponding device tree nodes.
>>>>>
>>>>> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
>>>>> ---
[...]
>>>>> + wdt0: watchdog at 1000 {
>>>>> + compatible = "snps,dw-wdt";
>>>>> + reg = <0x1000 0x100>;
>>>>> + clocks = <&refclk>;
>>>>> + interrupts = <0>;
>>>>> + status = "disabled";
>>>>
>>>> as the watchdogs are internal and cannot be clock gated
>>>> at all, how about we remove the status = "disabled" and
>>>> make them always available?
>>>
>>> there are two issues here:
>>>
>>> 1. the dw-wdt can't support multiple variants now. I have rewrite the driver
>>> with watchdog core supplied framework, but the patch isn't sent out and
>>> may be need time to clean up and review.
>>
>> Ok.
>>
>>> 2. not all dw-wdt devices are available and functional. This depends on
>>> board design and configuration.
>>
>> I understand that "board design and configuration" may hinder the wdt
>> to issue a hard reset. But all others are able to issue a soft reset
>> or just an interrupt, right?
>>
>> So, I still don't see why we should disable wdt nodes by default
>> except for the driver issue above.
>>
>>> So IMHO status=disabled and patch5-8 is necessary, what do you think?
>>
>> No. I'd agree to enable wdt0 by default and leave wdt[1,2] disabled
>> because of the driver issue. Patches 5-8 only enable wdt0 anyway.
>
> That's fine.
Jisheng,
I amended your SoC dtsi watchdog patches accordingly. wdt0 is
now always enabled, while the others are disabled.
So, with the changes Patches 1-4 applied to berlin/dt and berlin64/dt
respectively. Patches 5-8 dropped.
>> As soon as the driver issue is resolved, we enable all wdt nodes
>> unconditionally.
>
> I will submit patch for the wdt driver and hope it will be merged
> in v4.5.
Ok. Feel free to add a patch that removes the status disabled properties
again if berlin[64]/dt has already hit mainline in the meantime.
If not, keep me posted on the DW wdt patch outcome.
Thanks,
Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Jisheng Zhang <jszhang-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes
Date: Sat, 28 Nov 2015 12:36:16 +0100 [thread overview]
Message-ID: <565991B0.5030909@gmail.com> (raw)
In-Reply-To: <20151123125953.5c30a0ef@xhacker>
On 23.11.2015 05:59, Jisheng Zhang wrote:
> On Fri, 20 Nov 2015 21:19:46 +0100
> Sebastian Hesselbarth wrote:
>> On 20.11.2015 04:34, Jisheng Zhang wrote:
>>> On Thu, 19 Nov 2015 21:47:05 +0100
>>> Sebastian Hesselbarth wrote:
>>>> On 16.11.2015 12:09, Jisheng Zhang wrote:
>>>>> The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
>>>>> snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
>>>>> corresponding device tree nodes.
>>>>>
>>>>> Signed-off-by: Jisheng Zhang <jszhang-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>>>>> ---
[...]
>>>>> + wdt0: watchdog@1000 {
>>>>> + compatible = "snps,dw-wdt";
>>>>> + reg = <0x1000 0x100>;
>>>>> + clocks = <&refclk>;
>>>>> + interrupts = <0>;
>>>>> + status = "disabled";
>>>>
>>>> as the watchdogs are internal and cannot be clock gated
>>>> at all, how about we remove the status = "disabled" and
>>>> make them always available?
>>>
>>> there are two issues here:
>>>
>>> 1. the dw-wdt can't support multiple variants now. I have rewrite the driver
>>> with watchdog core supplied framework, but the patch isn't sent out and
>>> may be need time to clean up and review.
>>
>> Ok.
>>
>>> 2. not all dw-wdt devices are available and functional. This depends on
>>> board design and configuration.
>>
>> I understand that "board design and configuration" may hinder the wdt
>> to issue a hard reset. But all others are able to issue a soft reset
>> or just an interrupt, right?
>>
>> So, I still don't see why we should disable wdt nodes by default
>> except for the driver issue above.
>>
>>> So IMHO status=disabled and patch5-8 is necessary, what do you think?
>>
>> No. I'd agree to enable wdt0 by default and leave wdt[1,2] disabled
>> because of the driver issue. Patches 5-8 only enable wdt0 anyway.
>
> That's fine.
Jisheng,
I amended your SoC dtsi watchdog patches accordingly. wdt0 is
now always enabled, while the others are disabled.
So, with the changes Patches 1-4 applied to berlin/dt and berlin64/dt
respectively. Patches 5-8 dropped.
>> As soon as the driver issue is resolved, we enable all wdt nodes
>> unconditionally.
>
> I will submit patch for the wdt driver and hope it will be merged
> in v4.5.
Ok. Feel free to add a patch that removes the status disabled properties
again if berlin[64]/dt has already hit mainline in the meantime.
If not, keep me posted on the DW wdt patch outcome.
Thanks,
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Jisheng Zhang <jszhang@marvell.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
linux@arm.linux.org.uk, catalin.marinas@arm.com,
will.deacon@arm.com, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes
Date: Sat, 28 Nov 2015 12:36:16 +0100 [thread overview]
Message-ID: <565991B0.5030909@gmail.com> (raw)
In-Reply-To: <20151123125953.5c30a0ef@xhacker>
On 23.11.2015 05:59, Jisheng Zhang wrote:
> On Fri, 20 Nov 2015 21:19:46 +0100
> Sebastian Hesselbarth wrote:
>> On 20.11.2015 04:34, Jisheng Zhang wrote:
>>> On Thu, 19 Nov 2015 21:47:05 +0100
>>> Sebastian Hesselbarth wrote:
>>>> On 16.11.2015 12:09, Jisheng Zhang wrote:
>>>>> The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
>>>>> snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
>>>>> corresponding device tree nodes.
>>>>>
>>>>> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
>>>>> ---
[...]
>>>>> + wdt0: watchdog@1000 {
>>>>> + compatible = "snps,dw-wdt";
>>>>> + reg = <0x1000 0x100>;
>>>>> + clocks = <&refclk>;
>>>>> + interrupts = <0>;
>>>>> + status = "disabled";
>>>>
>>>> as the watchdogs are internal and cannot be clock gated
>>>> at all, how about we remove the status = "disabled" and
>>>> make them always available?
>>>
>>> there are two issues here:
>>>
>>> 1. the dw-wdt can't support multiple variants now. I have rewrite the driver
>>> with watchdog core supplied framework, but the patch isn't sent out and
>>> may be need time to clean up and review.
>>
>> Ok.
>>
>>> 2. not all dw-wdt devices are available and functional. This depends on
>>> board design and configuration.
>>
>> I understand that "board design and configuration" may hinder the wdt
>> to issue a hard reset. But all others are able to issue a soft reset
>> or just an interrupt, right?
>>
>> So, I still don't see why we should disable wdt nodes by default
>> except for the driver issue above.
>>
>>> So IMHO status=disabled and patch5-8 is necessary, what do you think?
>>
>> No. I'd agree to enable wdt0 by default and leave wdt[1,2] disabled
>> because of the driver issue. Patches 5-8 only enable wdt0 anyway.
>
> That's fine.
Jisheng,
I amended your SoC dtsi watchdog patches accordingly. wdt0 is
now always enabled, while the others are disabled.
So, with the changes Patches 1-4 applied to berlin/dt and berlin64/dt
respectively. Patches 5-8 dropped.
>> As soon as the driver issue is resolved, we enable all wdt nodes
>> unconditionally.
>
> I will submit patch for the wdt driver and hope it will be merged
> in v4.5.
Ok. Feel free to add a patch that removes the status disabled properties
again if berlin[64]/dt has already hit mainline in the meantime.
If not, keep me posted on the DW wdt patch outcome.
Thanks,
Sebastian
next prev parent reply other threads:[~2015-11-28 11:36 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-16 11:09 [PATCH RESEND 0/8] {arm|arm64}: berlin: add watchdog support Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-19 20:47 ` Sebastian Hesselbarth
2015-11-19 20:47 ` Sebastian Hesselbarth
2015-11-19 20:47 ` Sebastian Hesselbarth
2015-11-20 3:34 ` Jisheng Zhang
2015-11-20 3:34 ` Jisheng Zhang
2015-11-20 3:34 ` Jisheng Zhang
2015-11-20 20:19 ` Sebastian Hesselbarth
2015-11-20 20:19 ` Sebastian Hesselbarth
2015-11-20 20:19 ` Sebastian Hesselbarth
2015-11-23 4:59 ` Jisheng Zhang
2015-11-23 4:59 ` Jisheng Zhang
2015-11-23 4:59 ` Jisheng Zhang
2015-11-28 11:36 ` Sebastian Hesselbarth [this message]
2015-11-28 11:36 ` Sebastian Hesselbarth
2015-11-28 11:36 ` Sebastian Hesselbarth
2015-11-30 12:59 ` Jisheng Zhang
2015-11-30 12:59 ` Jisheng Zhang
2015-11-30 12:59 ` Jisheng Zhang
2015-11-16 11:09 ` [PATCH RESEND 2/8] arm: dts: berlin2cd: " Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` [PATCH RESEND 3/8] arm: dts: berlin2: " Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` [PATCH RESEND 4/8] arm64: dts: berlin4ct: " Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` [PATCH RESEND 5/8] arm: dts: berlin: enable wdt0 on Sony NSZ-GS7 Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` [PATCH RESEND 6/8] ARM: dts: berlin: enable wdt0 on the Google Chromecast Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` [PATCH RESEND 7/8] arm: dts: berlin: enable wdt0 on the Marvell BG2Q DMP Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` [PATCH RESEND 8/8] arm64: dts: berlin: enable wdt0 on the Marvell BG4CT STB board Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
2015-11-16 11:09 ` Jisheng Zhang
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=565991B0.5030909@gmail.com \
--to=sebastian.hesselbarth@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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.