* [lm-sensors] w83792d watchdog
2006-03-29 22:38 [lm-sensors] w83792d watchdog Rudolf Marek
@ 2006-03-30 1:37 ` dezheng shen
2006-04-07 10:43 ` Rudolf Marek
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: dezheng shen @ 2006-03-30 1:37 UTC (permalink / raw)
To: lm-sensors
I will forward to the responsible engineer anyway but I have to consult
him if he is willing to communicate with you directly.
thanks,
dezheng
> Hello all,
>
> I begun to work on the watchdog support for w83792d. I have several
> questions about the watchdog device in w83792d. Please can
> yuou forward them to responsible person?
>
> I'm using ver 1.0 of datasheet
>
> There are 4 watchdog regs:
>
> CR01 handles the unlock codes
> CR02 "Watch Dog Enable" -> this should be more likely called "Watch
> Dog Enable Status" - because this regs are RO only
> CR03 is quite mystery for me
> the "WDT stage" is not described in datasheet at all, I assume
> this has someting to do with hard mode of watchdog
>
>
> the HARD_TO and SOFT_TO have following commnents:
>
> HARD_TO: 1: a hard timeout occurs. This bit will be cleared while
> reading.
>
> What I know:
>
> 1) this bit is not cleared on reading
> 2) I think the sentece should be: "a hard timeoud had occured"
> because this is set when there was a timeout/reset it seems
>
> This is so far to datasheet, now to real funcs:
>
> 1) What will happen if I enable hard and soft watchdog same time? (i'm
> disabling the hard watchdog timer in first place so
> it should not be an issue but you never know)
> 2) I tried many ways to reset the watchdog timer but only seems to
> work is to write 0xAA to CR1 and then 0x55 to re-enable it.
> This seems bit strange because the computer can fail just in
> between of this two writes Yes I know this is not probable, but
> the best method is just to re-write the timeout value or rewrite
> the enable (0x55) - as others might do. Were there
> some strange reason for this design?
>
> And last thing, It seems that the device registers survive system
> power cycle. Maybe I was just too fast and the caps powered
> the chip. I will investigate...
>
> I hope you can understand my thought because I'm quite tired now.
>
> regards
> Rudolf
>
>
>
>
>
>
>
>
>
>
=============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
^ permalink raw reply [flat|nested] 6+ messages in thread* [lm-sensors] w83792d watchdog
2006-03-29 22:38 [lm-sensors] w83792d watchdog Rudolf Marek
2006-03-30 1:37 ` dezheng shen
@ 2006-04-07 10:43 ` Rudolf Marek
2006-04-10 10:28 ` Ymu
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Rudolf Marek @ 2006-04-07 10:43 UTC (permalink / raw)
To: lm-sensors
dezheng shen wrote:
> I will forward to the responsible engineer anyway but I have to consult
> him if he is willing to communicate with you directly.
Hello again.
I have programed a new watchdog class to a kernel so now I'm able to connect
w83792d driver to the watchdog class... I think I will be able to test the stuff
next week or so. Any news on about the engineer?
Btw it is great that I have a computer I can test the whole thing!
Thanks,
Regards
Rudolf
^ permalink raw reply [flat|nested] 6+ messages in thread* [lm-sensors] w83792d watchdog
2006-03-29 22:38 [lm-sensors] w83792d watchdog Rudolf Marek
2006-03-30 1:37 ` dezheng shen
2006-04-07 10:43 ` Rudolf Marek
@ 2006-04-10 10:28 ` Ymu
2006-04-10 10:45 ` Rudolf Marek
2006-04-11 18:34 ` Rudolf Marek
4 siblings, 0 replies; 6+ messages in thread
From: Ymu @ 2006-04-10 10:28 UTC (permalink / raw)
To: lm-sensors
Hi Rudolf,
I have finished the w83793 driver, and i'm testing it.
So i can be the tester if you need testers on watchdog now,
And i have some questions about the watchdog, please see below.
>
> I begun to work on the watchdog support for w83792d. I have
> several questions about the watchdog device in w83792d. Please can
> yuou forward them to responsible person?
>
> I'm using ver 1.0 of datasheet
>
> There are 4 watchdog regs:
>
> CR01 handles the unlock codes
> CR02 "Watch Dog Enable" -> this should be more likely called
> "Watch Dog Enable Status" - because this regs are RO only
> CR03 is quite mystery for me
> the "WDT stage" is not described in datasheet at all, I
> assume this has someting to do with hard mode of watchdog
>
>
> the HARD_TO and SOFT_TO have following commnents:
>
> HARD_TO: 1: a hard timeout occurs. This bit will be cleared
> while reading.
>
> What I know:
>
> 1) this bit is not cleared on reading
> 2) I think the sentece should be: "a hard timeoud had occured"
> because this is set when there was a timeout/reset it seems
>
Hmm, you mean reading after reboot will not clear the bit?
Reading use i2cdump after reboot will clear the bit in my computer.
> This is so far to datasheet, now to real funcs:
>
> 1) What will happen if I enable hard and soft watchdog same
> time? (i'm disabling the hard watchdog timer in first place so
> it should not be an issue but you never know)
I tried write 0x33 and 0x55 to CR01, it seems only the last one is
enabled by reading CR02.
> 2) I tried many ways to reset the watchdog timer but only
> seems to work is to write 0xAA to CR1 and then 0x55 to re-enable it.
> This seems bit strange because the computer can fail
> just in between of this two writes Yes I know this is not
> probable, but
> the best method is just to re-write the timeout value or
> rewrite the enable (0x55) - as others might do. Were there
> some strange reason for this design?
>
I'm quite confusing about this.... Do you mean you can not set the
timeout value??
> And last thing, It seems that the device registers survive
> system power cycle. Maybe I was just too fast and the caps powered
> the chip. I will investigate...
>
> I hope you can understand my thought because I'm quite tired now.
Best Regards
Yuan Mu
=============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [lm-sensors] w83792d watchdog
2006-03-29 22:38 [lm-sensors] w83792d watchdog Rudolf Marek
` (2 preceding siblings ...)
2006-04-10 10:28 ` Ymu
@ 2006-04-10 10:45 ` Rudolf Marek
2006-04-11 18:34 ` Rudolf Marek
4 siblings, 0 replies; 6+ messages in thread
From: Rudolf Marek @ 2006-04-10 10:45 UTC (permalink / raw)
To: lm-sensors
Hi Yuan,
> I have finished the w83793 driver, and i'm testing it.
> So i can be the tester if you need testers on watchdog now,
Good.
>
> Hmm, you mean reading after reboot will not clear the bit?
> Reading use i2cdump after reboot will clear the bit in my computer.
I tried the SOFT watchdog and the bit seems sticky. I will test
this evening.
>>This is so far to datasheet, now to real funcs:
>>
>>1) What will happen if I enable hard and soft watchdog same
>>time? (i'm disabling the hard watchdog timer in first place so
>>it should not be an issue but you never know)
>
>
> I tried write 0x33 and 0x55 to CR01, it seems only the last one is
> enabled by reading CR02.
Ok I will try too.
>
>
>>2) I tried many ways to reset the watchdog timer but only
>>seems to work is to write 0xAA to CR1 and then 0x55 to re-enable it.
>> This seems bit strange because the computer can fail
>>just in between of this two writes Yes I know this is not
>>probable, but
>> the best method is just to re-write the timeout value or
>>rewrite the enable (0x55) - as others might do. Were there
>> some strange reason for this design?
>>
>
>
> I'm quite confusing about this.... Do you mean you can not set the
> timeout value??
I can but after for example one minute I need to refresh the watchdog
so it wont boot the computer. As I have written I tried several methods to
reset the counter back to count the the timeout value.
The only that worked so far is to disable/enable the watchdog which
is non-atomic operation. Other winbond watchdogs works different
way, sufficient is to rewrite the timeout for example.
Regards
Rudolf
^ permalink raw reply [flat|nested] 6+ messages in thread* [lm-sensors] w83792d watchdog
2006-03-29 22:38 [lm-sensors] w83792d watchdog Rudolf Marek
` (3 preceding siblings ...)
2006-04-10 10:45 ` Rudolf Marek
@ 2006-04-11 18:34 ` Rudolf Marek
4 siblings, 0 replies; 6+ messages in thread
From: Rudolf Marek @ 2006-04-11 18:34 UTC (permalink / raw)
To: lm-sensors
Hello again,
>>Hmm, you mean reading after reboot will not clear the bit?
>>Reading use i2cdump after reboot will clear the bit in my computer.
I found the reason. The chip is powered from VSB which means that the chip
configuration survives power on/off. (For example I enabled watchdog in CR40
halted the machine, boot and the enwdt bit watch still set - and the timeout flag
too) Only plug/unplug of cable worked - this was expected ;)
It clears after the reboot too but I was somehow confused.
>>I tried write 0x33 and 0x55 to CR01, it seems only the last one is
>>enabled by reading CR02.
Yes same here too. Last value seems to enable it.
>>>2) I tried many ways to reset the watchdog timer but only
>>>seems to work is to write 0xAA to CR1 and then 0x55 to re-enable it.
>>> This seems bit strange because the computer can fail
>>>just in between of this two writes Yes I know this is not
>>>probable, but
>>> the best method is just to re-write the timeout value or
>>>rewrite the enable (0x55) - as others might do. Were there
>>> some strange reason for this design?
>>>
>>
>>
>>I'm quite confusing about this.... Do you mean you can not set the
>>timeout value??
>
>
> I can but after for example one minute I need to refresh the watchdog
> so it wont boot the computer. As I have written I tried several methods to
> reset the counter back to count the the timeout value.
I tried again and just re-enabling the watchdog is not working, nor
writing new timeout value.
Moreover it seems that just enabling the watchdog without rewriting the timeout register first
will cause immediate reset.
Lets wait for FAE to answer, I will meanwhile test the class.
regards
Rudolf
^ permalink raw reply [flat|nested] 6+ messages in thread