port-hp700/41448: harmony(4) is not understanding my hardware

[martin%duskware.de@localhost]

>Number:         41448
>Category:       port-hp700
>Synopsis:       harmony(4) is not understanding my hardware
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-hp700-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 17 11:35:00 +0000 2009
>Originator:     Martin Husemann
>Release:        NetBSD 5.99.11
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD moondance.duskware.de 5.99.11 NetBSD 5.99.11 (MOONDANCE) #16: 
Sat May 16 23:26:21 CEST 2009 
martin%night-porter.duskware.de@localhost:/usr/src/sys/arch/hp700/compile/MOONDANCE
 hp700
Architecture: hppa
Machine: hp700
>Description:

On a HP9000/715/50 (Scorpio) system, harmony(4) attaches like:

harmony0 at gsc0 hpa 0xf1000000 path 2/0/8 irq 13 ipl 6: rev 0
audio0 at harmony0: full duplex

The machine has problems rebooting, which nick tracked down to unbound
polling in harmon_commit_settings. Further investigation (where my hardware
seems to react differently to Nick's) shows that the chip never becomes
ready (clears CNTL_C) after writing to the control register.

Reset works, initializing the gain register too, but as soon as the chip
is configured by setting the control register, it needs a hard reset.

While investigating I noted there are three unbound loops in harmony(4):
one waiting for playback/recording to finish after disabling interrupts
before resetting the chip - this loop should never cause problems on
working systems (only a page full of samples to play/record), but in
my failure case runs infinite too. Maybe a uptime based timeout should
be used here?

The other two loops are waiting for the control bit to clear. The first
(right afer resetting the codec) always is imediately done (unless the
chip is in my special failure mode, in which case it never clears), the
second takes around 300 - 400 useconds (again, unless in my failure mode,
when it never terminates).

In passing I note there are comments like
/* XXX leave these bits alone or the chip will not come out of CNTL */
in harmony_set_gainctl, which might refer to something caused by the
same underlying problem - or not. Writing or not writing the gainctl
register does not make a difference in my case.

>How-To-Repeat:
Not sure what make my hardware special, maybe it is just broken?

>Fix:
n/a