diff options
author | Lothar Wassmann <LW@KARO-electronics.de> | 2005-12-12 16:44:05 +0000 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2005-12-12 16:44:05 +0000 |
commit | 1ee9530a71686436dbeb5f31dd5b925c39cf71d7 (patch) | |
tree | bd5ca62accb91f21f71edc5e456dcd070135a4e4 /drivers/isdn | |
parent | 22f975f4ffa707ea24507f6899bb9f5a1ff034bc (diff) |
[ARM] 3201/1: PXA27x: Prevent hangup during resume due to inadvertedly enabling MBREQ (replaces: 3198/1)
Patch from Lothar Wassmann
The patch makes sure, that the ouptut functions of pins are restored
before restoring the Alternat Function settings, preventing pins from
being intermediately configured for undefined or unwanted alternate
functions.
Here is the original comment:
I've got a PXA270 system that uses GPIO80 as nCS4. This system did
hang on resume. Digging into the problem I found that the processor
stalled immediately when restoring the GAFR2_U register which restored
the alternate function for GPIO80. Since the GPDR registers were
restored after the GAFR registers, the offending GPIO was configured
as input at this point.
Thus the alternate function that was in effect after restoring the
GAFR was in fact the input function "MBREQ" instead of the output
function "nCS4". The "PXA27x Processor Family Developer's Manual"
(Footnote in Table 6-1 on page 6-3) states that:
"The MBREQ alternate function must not be enabled until the PSSR[RDH]
bit field is cleared. For more details, see Table 3-15, "PSSR Bit
Definitions" on page 3-71."
There is another note in the Developer's Manual (chapter 24.4.2
"GPIO operation as Alternate Function" on page 24-4)
stating that:
"Configuring a GPIO for an alternate function that is not defined for
it causes unpredictable results."
Since some GPIOs have no input function defined, and to prevent
inadvertedly programming the MBREQ function on some pin, the GAFR
registers should be restored after the GPDR registers have been
restored.
Additional provisions have to be made when the MBREQ function is
actually required. The corresponding GAFR bits should not be restored
with the regular GAFR restore, but must be set only after the PSSR
bits have been cleared.
Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'drivers/isdn')
0 files changed, 0 insertions, 0 deletions