g: fix rdd
g: fix rdd

This change fixes two issues. The first issue is that during rdd_init
debug_detect is set to the value of DEBUG_STATE_MAP. Debug_detect should
be the default map value of 0x420 which triggers an rdd interrupt when
cc1 and cc2 both have a value of 011 or 001. This will detect when a
debug cable is attached. ~debug_detect should detect when the cable is
detached.

The issue is after a soft reset DEBUG_STATE_MAP is not reset to the
default value so on the next rdd_init debug_detect was set to whatever
was DEBUG_STATE_MAP was last set to. If the debug cable is detected
before the soft reset then DEBUG_STATE_MAP will have a value of
~debug_detect and when rdd_init is called then debug_detect will be
initialized to that value of ~0x420. Now debug_detect does the opposite
of what we expect it to do. debug_detect detects when the cable is
detached and ~debug_detect detects when it is attached.

rdd_interrupt is called cr50 reads cc1 and cc2 and sees that a debug
accessory is attached so it sets DEBUG_STATE_MAP to ~debug_detect.
Because debug_detect does the opposite of what is expected then it will
trigger an interrupt when it detects a debug accessory. The debug
accessory is already attached so an interrupt is triggered. It reads cc1
and cc2 sees the debug_accessory attached resets the map to
~debug_detect. This cycle continues until the watchdog resets the
system. After this reset rdd_init reads the map to get debug_detect and
it is 0x420 because that is how it was last set and then rdd works
again.

This change fixes this issue by defining DEBUG_DETECT to be 0x420 and
not using the STATE_MAP value to do it.

It also looks like when the EC is off and we change the value of the
debug map, another RDD interrupt is triggered. Then it reads the debug
state and resets the map again another interrupt is triggered. It
continuously does this.

This change adds a check to see that the RDD was trying to detect the
state it currently senses before doing anything so the second interrupt
will be ignored.

BUG=chrome-os-partner:55793
BRANCH=none
TEST=manual
	plug in a reworked suzyq

	Flash the EC

	verify a bunch of RDD interrupts aren't triggered and the
	reworked suzyq can be used.

	plug it in and out a couple of times to make sure everything
	works.

Change-Id: I6f4e7b15cf9c53b965533df7fe23fae5b340f70d
Signed-off-by: Mary Ruthven <81380f3403fed74252e92df3ed012a1819ec6296@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364724
Commit-Ready: Vadim Bendebury <5515d6d2d0829cbe0dd0dcf2094aaded06d58514@chromium.org>
Reviewed-by: Vadim Bendebury <5515d6d2d0829cbe0dd0dcf2094aaded06d58514@chromium.org>

coreboot/chrome-ec,coreboot/chrome-ec,coreboot/chrome-ec,coreboot/chrome-ec,coreboot/chrome-ec,coreboot/chrome-ec