Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1256883 > unrolled thread

[PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation fu.wei@linaro.org - 2015-10-27 17:10 +0100
    Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Mark Rutland <mark.rutland@arm.com> - 2015-10-27 17:30 +0100
      Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Fu Wei <fu.wei@linaro.org> - 2015-10-28 05:20 +0100
        Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Timur Tabi <timur@codeaurora.org> - 2015-10-30 18:50 +0100
          Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Fu Wei <fu.wei@linaro.org> - 2015-10-30 19:40 +0100
            Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Timur Tabi <timur@codeaurora.org> - 2015-10-30 20:00 +0100
              Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Mark Rutland <mark.rutland@arm.com> - 2015-10-30 20:10 +0100
                Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Timur Tabi <timur@codeaurora.org> - 2015-10-30 21:40 +0100
                  Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Fu Wei <fu.wei@linaro.org> - 2015-11-02 05:20 +0100
                Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Fu Wei <fu.wei@linaro.org> - 2015-11-02 05:10 +0100
                  Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Timur Tabi <timur@codeaurora.org> - 2015-11-02 05:10 +0100
                    Re: [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation Jon Masters <jcm@redhat.com> - 2015-11-02 05:30 +0100

#1256883 — [PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation

From: Fu Wei <fu.wei@linaro.org>

The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
introducing SBSA(Server Base System Architecture) Generic Watchdog
device node info into FDT.

Also add sbsa-gwdt introduction in watchdog-parameters.txt

Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Fu Wei <fu.wei@linaro.org>
---
 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     | 46 ++++++++++++++++++++++
 Documentation/watchdog/watchdog-parameters.txt     |  6 +++
 2 files changed, 52 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
new file mode 100644
index 0000000..ad8e99a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
@@ -0,0 +1,46 @@
+* SBSA (Server Base System Architecture) Generic Watchdog
+
+The SBSA Generic Watchdog Timer is used to force a reset of the system
+after two stages of timeout have elapsed.  A detailed definition of the
+watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
+Base System Architecture (SBSA)
+
+Required properties:
+- compatible: Should at least contain "arm,sbsa-gwdt".
+
+- reg: Each entry specifies the base physical 64-bit address of a register
+  frame and the 64-bit length of that frame; currently, two frames must be
+  defined, in this order:
+  1: Watchdog control frame
+  2: Refresh frame.
+
+- interrupts: At least one interrupt must be defined that will be used as
+  the WS0 interrupt.  A WS1 interrupt definition can be provided, but is
+  optional.  The interrupts must be defined in this order:
+  1: WS0 interrupt
+  2: WS1 interrupt
+
+Optional properties
+- timeout-sec: To use a timeout value that is different from the driver
+  default values, use this property.  If used, at least one timeout value
+  (in seconds) must be provided.  A second optional timeout value (in
+  seconds) may also be provided and will be used as the pre-timeout value,
+  if it is given.
+
+  There are two possible sources for driver default timeout values:
+  (1) the driver contains hard-coded default values, or
+  (2) module parameters can be given when the module is loaded
+
+  If timeout/pretimeout values are provided when the module loads, they
+  will take priority.  Second priority will be the timeout-sec from DTB,
+  and third the hard-coded driver values.
+
+Example for FVP Foundation Model v8:
+
+watchdog@2a440000 {
+	compatible = "arm,sbsa-gwdt";
+	reg = <0x0 0x2a440000 0 0x1000>,
+	      <0x0 0x2a450000 0 0x1000>;
+	interrupts = <0 27 4>;
+	timeout-sec = <60 30>;
+};
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 9f9ec9f..e62c8c4 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -284,6 +284,12 @@ sbc_fitpc2_wdt:
 margin: Watchdog margin in seconds (default 60s)
 nowayout: Watchdog cannot be stopped once started
 -------------------------------------------------
+sbsa_gwdt:
+timeout: Watchdog timeout in seconds. (default 60s)
+pretimeout: Watchdog pretimeout in seconds. (default 30s)
+nowayout: Watchdog cannot be stopped once started
+	(default=kernel config parameter)
+-------------------------------------------------
 sc1200wdt:
 isapnp: When set to 0 driver ISA PnP support will be disabled (default=1)
 io: io port
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1256914

On Wed, Oct 28, 2015 at 12:06:35AM +0800, fu.wei@linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
> 
> The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
> introducing SBSA(Server Base System Architecture) Generic Watchdog
> device node info into FDT.
> 
> Also add sbsa-gwdt introduction in watchdog-parameters.txt
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> ---
>  .../devicetree/bindings/watchdog/sbsa-gwdt.txt     | 46 ++++++++++++++++++++++
>  Documentation/watchdog/watchdog-parameters.txt     |  6 +++
>  2 files changed, 52 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
> new file mode 100644
> index 0000000..ad8e99a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
> @@ -0,0 +1,46 @@
> +* SBSA (Server Base System Architecture) Generic Watchdog
> +
> +The SBSA Generic Watchdog Timer is used to force a reset of the system
> +after two stages of timeout have elapsed.  A detailed definition of the
> +watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
> +Base System Architecture (SBSA)
> +
> +Required properties:
> +- compatible: Should at least contain "arm,sbsa-gwdt".
> +
> +- reg: Each entry specifies the base physical 64-bit address of a register
> +  frame and the 64-bit length of that frame; currently, two frames must be

Remove "64-bit" here. This depends on #address-cells and #size-cells, as
usual.

> +  defined, in this order:
> +  1: Watchdog control frame
> +  2: Refresh frame.
> +
> +- interrupts: At least one interrupt must be defined that will be used as
> +  the WS0 interrupt.  A WS1 interrupt definition can be provided, but is
> +  optional.  The interrupts must be defined in this order:
> +  1: WS0 interrupt
> +  2: WS1 interrupt

Why is WS1 optional?

> +Optional properties
> +- timeout-sec: To use a timeout value that is different from the driver
> +  default values, use this property. 

Either define a default value, or don't state anything about the
behaviour when this is not present.

>    If used, at least one timeout value
> +  (in seconds) must be provided.  A second optional timeout value (in
> +  seconds) may also be provided and will be used as the pre-timeout value,
> +  if it is given.
> +
> +  There are two possible sources for driver default timeout values:
> +  (1) the driver contains hard-coded default values, or
> +  (2) module parameters can be given when the module is loaded
> +
> +  If timeout/pretimeout values are provided when the module loads, they
> +  will take priority.  Second priority will be the timeout-sec from DTB,
> +  and third the hard-coded driver values.

The last two paragraphs should go. They describe Linux behaviour rather
than the binding.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1257649

Hi Mark

Thanks for your rapid feedback, I appreciate your help very much.


On 28 October 2015 at 00:22, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Oct 28, 2015 at 12:06:35AM +0800, fu.wei@linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
>> introducing SBSA(Server Base System Architecture) Generic Watchdog
>> device node info into FDT.
>>
>> Also add sbsa-gwdt introduction in watchdog-parameters.txt
>>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Fu Wei <fu.wei@linaro.org>
>> ---
>>  .../devicetree/bindings/watchdog/sbsa-gwdt.txt     | 46 ++++++++++++++++++++++
>>  Documentation/watchdog/watchdog-parameters.txt     |  6 +++
>>  2 files changed, 52 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
>> new file mode 100644
>> index 0000000..ad8e99a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
>> @@ -0,0 +1,46 @@
>> +* SBSA (Server Base System Architecture) Generic Watchdog
>> +
>> +The SBSA Generic Watchdog Timer is used to force a reset of the system
>> +after two stages of timeout have elapsed.  A detailed definition of the
>> +watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
>> +Base System Architecture (SBSA)
>> +
>> +Required properties:
>> +- compatible: Should at least contain "arm,sbsa-gwdt".
>> +
>> +- reg: Each entry specifies the base physical 64-bit address of a register
>> +  frame and the 64-bit length of that frame; currently, two frames must be
>
> Remove "64-bit" here. This depends on #address-cells and #size-cells, as
> usual.

Ah, right, Thanks , will do

>
>> +  defined, in this order:
>> +  1: Watchdog control frame
>> +  2: Refresh frame.
>> +
>> +- interrupts: At least one interrupt must be defined that will be used as
>> +  the WS0 interrupt.  A WS1 interrupt definition can be provided, but is
>> +  optional.  The interrupts must be defined in this order:
>> +  1: WS0 interrupt
>> +  2: WS1 interrupt
>
> Why is WS1 optional?

According to the description of WS1 in SBSA 2.3 (5.2 Watchdog Operation) page 21
-----------------
The signal is fed to a higher agent as an interrupt or reset for it to
take executive action.
----------------

So WS1 maybe a interrupt.

In a real Hardware,  WS1 hooks to a  reset signal pin of BMC, if this
pin is triggered, BMC will do a real warm reset.
In this case, WS1 is a reset, Linux doesn't need to deal with that.

For now , I haven't found a hardware use WS1 as  interrupt.
In <ARM v8-A Foundation Platform User Guide> 3.2 Interrupt maps  Page 22
Table 3-3 Shared peripheral interrupt assignments
IRQ ID       SPI offset      Device
60               28              EL2 Generic Watchdog WS1

But I don't have further info about it.

Anyway,  because this signal could be interrupt or reset, Linux don't
need know this signal sometimes.
So I think it should be optional in binding info.

Do I miss something? Any suggestion ? Please correct me, thanks.

>
>> +Optional properties
>> +- timeout-sec: To use a timeout value that is different from the driver
>> +  default values, use this property.
>
> Either define a default value, or don't state anything about the
> behaviour when this is not present.

OK, thanks :-)

>
>>    If used, at least one timeout value
>> +  (in seconds) must be provided.  A second optional timeout value (in
>> +  seconds) may also be provided and will be used as the pre-timeout value,
>> +  if it is given.
>> +
>> +  There are two possible sources for driver default timeout values:
>> +  (1) the driver contains hard-coded default values, or
>> +  (2) module parameters can be given when the module is loaded
>> +
>> +  If timeout/pretimeout values are provided when the module loads, they
>> +  will take priority.  Second priority will be the timeout-sec from DTB,
>> +  and third the hard-coded driver values.
>
> The last two paragraphs should go. They describe Linux behaviour rather
> than the binding.

yes, maybe that should be in the watchdog documentation?

>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1259672

On Tue, Oct 27, 2015 at 11:10 PM, Fu Wei <fu.wei@linaro.org> wrote:
>
>> Why is WS1 optional?
>
> According to the description of WS1 in SBSA 2.3 (5.2 Watchdog Operation) page 21
> -----------------
> The signal is fed to a higher agent as an interrupt or reset for it to
> take executive action.
> ----------------
>
> So WS1 maybe a interrupt.
>
> In a real Hardware,  WS1 hooks to a  reset signal pin of BMC, if this
> pin is triggered, BMC will do a real warm reset.
> In this case, WS1 is a reset, Linux doesn't need to deal with that.
>
> For now , I haven't found a hardware use WS1 as  interrupt.
> In <ARM v8-A Foundation Platform User Guide> 3.2 Interrupt maps  Page 22
> Table 3-3 Shared peripheral interrupt assignments
> IRQ ID       SPI offset      Device
> 60               28              EL2 Generic Watchdog WS1
>
> But I don't have further info about it.
>
> Anyway,  because this signal could be interrupt or reset, Linux don't
> need know this signal sometimes.
> So I think it should be optional in binding info.
>
> Do I miss something? Any suggestion ? Please correct me, thanks.

I think maybe Mark was asking why WS1 is optional, not the WS1
interrupt.  Maybe you can reword the documentation to make is clear
that only the *interrupt* for WS1 is optional.

However, the ACPI table only allows for one interrupt, and it's not
clear whether that's the WS0 or WS1 interrupt.  So if both WS0 and WS1
generate an interrupt, how does the driver handle that?

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1259707

Hi Timur

On 31 October 2015 at 01:46, Timur Tabi <timur@codeaurora.org> wrote:
> On Tue, Oct 27, 2015 at 11:10 PM, Fu Wei <fu.wei@linaro.org> wrote:
>>
>>> Why is WS1 optional?
>>
>> According to the description of WS1 in SBSA 2.3 (5.2 Watchdog Operation) page 21
>> -----------------
>> The signal is fed to a higher agent as an interrupt or reset for it to
>> take executive action.
>> ----------------
>>
>> So WS1 maybe a interrupt.
>>
>> In a real Hardware,  WS1 hooks to a  reset signal pin of BMC, if this
>> pin is triggered, BMC will do a real warm reset.
>> In this case, WS1 is a reset, Linux doesn't need to deal with that.
>>
>> For now , I haven't found a hardware use WS1 as  interrupt.
>> In <ARM v8-A Foundation Platform User Guide> 3.2 Interrupt maps  Page 22
>> Table 3-3 Shared peripheral interrupt assignments
>> IRQ ID       SPI offset      Device
>> 60               28              EL2 Generic Watchdog WS1
>>
>> But I don't have further info about it.
>>
>> Anyway,  because this signal could be interrupt or reset, Linux don't
>> need know this signal sometimes.
>> So I think it should be optional in binding info.
>>
>> Do I miss something? Any suggestion ? Please correct me, thanks.
>
> I think maybe Mark was asking why WS1 is optional, not the WS1

My answer is for "why WS1 is optional"!

> interrupt.  Maybe you can reword the documentation to make is clear
> that

I didn't say : "only the *interrupt* for WS1 is optional."

>
> However, the ACPI table only allows for one interrupt, and it's not
> clear whether that's the WS0 or WS1 interrupt.  So if both WS0 and WS1
> generate an interrupt, how does the driver handle that?

register a interrupt handle for both

>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1259719

On 10/30/2015 01:35 PM, Fu Wei wrote:
>> I think maybe Mark was asking why WS1 is optional, not the WS1
> My answer is for "why WS1 is optional"!
>
>> >interrupt.  Maybe you can reword the documentation to make is clear
>> >that
> I didn't say : "only the*interrupt*  for WS1 is optional."

WS1 itself is not optional.  The spec says that WS0 and WS1 are separate 
events, and doesn't saying anything about either being optional.  The 
*interrupt* for WS1, however, is optional.

Besides, what does the driver do with the WS1 interrupt?  If it's 
specified in the device tree, it appears to be ignored by the driver. 
And the ACPI table only allows for specifying ONE interrupt.  So how 
would the driver register a handler for WS1 on an ACPI system?

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1259730

On Fri, Oct 30, 2015 at 01:53:24PM -0500, Timur Tabi wrote:
> On 10/30/2015 01:35 PM, Fu Wei wrote:
> >>I think maybe Mark was asking why WS1 is optional, not the WS1
> >My answer is for "why WS1 is optional"!
> >
> >>>interrupt.  Maybe you can reword the documentation to make is clear
> >>>that
> >I didn't say : "only the*interrupt*  for WS1 is optional."
> 
> WS1 itself is not optional.  The spec says that WS0 and WS1 are
> separate events, and doesn't saying anything about either being
> optional.  The *interrupt* for WS1, however, is optional.

This is a moot point. The distintion between the signal and the
interrupt doens't matter here.

I was only asking why the interrupt was optional, and it seems per the
spec it's expected to be handed to an agent at a higher exception level.

That implies that the OS should only care about WS0, assuming that I've
understood correctly.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1259775

On 10/30/2015 02:05 PM, Mark Rutland wrote:
> I was only asking why the interrupt was optional, and it seems per the
> spec it's expected to be handed to an agent at a higher exception level.
>
> That implies that the OS should only care about WS0, assuming that I've
> understood correctly.

Yes, this my understand as well.  Apologies if I didn't get that across.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1260331

Hi Timur.

On 31 October 2015 at 04:37, Timur Tabi <timur@codeaurora.org> wrote:
> On 10/30/2015 02:05 PM, Mark Rutland wrote:
>>
>> I was only asking why the interrupt was optional, and it seems per the
>> spec it's expected to be handed to an agent at a higher exception level.
>>
>> That implies that the OS should only care about WS0, assuming that I've
>> understood correctly.
>
>
> Yes, this my understand as well.  Apologies if I didn't get that across.

Sorry for misunderstanding your meaning.
maybe Linux don't need to handle WS1, but I am not sure if there is a
hardware with WS1 interrupt we need to handle.

>
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1260328

Hi Mark,

Great thanks for your feedback.

On 31 October 2015 at 03:05, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Oct 30, 2015 at 01:53:24PM -0500, Timur Tabi wrote:
>> On 10/30/2015 01:35 PM, Fu Wei wrote:
>> >>I think maybe Mark was asking why WS1 is optional, not the WS1
>> >My answer is for "why WS1 is optional"!
>> >
>> >>>interrupt.  Maybe you can reword the documentation to make is clear
>> >>>that
>> >I didn't say : "only the*interrupt*  for WS1 is optional."
>>
>> WS1 itself is not optional.  The spec says that WS0 and WS1 are
>> separate events, and doesn't saying anything about either being
>> optional.  The *interrupt* for WS1, however, is optional.
>
> This is a moot point. The distintion between the signal and the
> interrupt doens't matter here.
>
> I was only asking why the interrupt was optional, and it seems per the
> spec it's expected to be handed to an agent at a higher exception level.

yes, that is the good point. Thanks
I have thought about it
My thought is :
In virtualization system, Linux kernel with KVM support as a
Hypervisor, and guest are using a one of SBSA watchdog.
WS0 is handled by guest OS, and WS1 will be handled by Hypervisor.

And in datasheet of Foundation model, we can see:
 IRQ ID       SPI offset      Device
 60               28              EL2 Generic Watchdog WS1

So maybe we need  WS1 interrupt info, Maybe not. So I say :  WS1 info
in FDT binding info is optional.

*BUT*,
(1) I don't see any hardware need to handle WS1 for now, because AMD
seattle is the only real hardware with SBSA watchdog I can test now.
(2) In GTDT, there is not data about WS1
(3) I don't handle WS1 in this driver.

>
> That implies that the OS should only care about WS0, assuming that I've
> understood correctly.

yes, after getting your and Timur's email.  I have thought about this
in the weekend,
Maybe we can forget about WS1 in the FDT binding info temporary until
we need to handle WS1 in Linux on any hardware(or model).

>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1260330

Fu Wei wrote:
> In virtualization system, Linux kernel with KVM support as a
> Hypervisor, and guest are using a one of SBSA watchdog.
> WS0 is handled by guest OS, and WS1 will be handled by Hypervisor.

I don't see how that would work, because the host kernel cannot 
reconfigure the behavior of WS1.

Besides, don't KVM guests use some kind of software and/or 
paravirtualized watchdog?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1260340

On 11/01/2015 11:06 PM, Timur Tabi wrote:
> Fu Wei wrote:
>> In virtualization system, Linux kernel with KVM support as a
>> Hypervisor, and guest are using a one of SBSA watchdog.
>> WS0 is handled by guest OS, and WS1 will be handled by Hypervisor.
> 
> I don't see how that would work, because the host kernel cannot 
> reconfigure the behavior of WS1.
> 
> Besides, don't KVM guests use some kind of software and/or 
> paravirtualized watchdog?

Indeed, this is my expectation. IIRC the hardware watchdog initially
defined in SBSA was intended for bare metal use to have something people
could start implementing while we worked on the future (the language
around register frames relates to secure/non-secure ELs in my
recollection). For now, I expect an emulated watchdog for VMs, which
ideally would be a software implementation of the same SBSA watchdog.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web