On Thu, Mar 13, 2008 at 6:06 PM, Oliver Ford <oliford_at_oliford.co.uk> wrote:
> eric miao wrote:
> > On Wed, Mar 12, 2008 at 8:43 AM, Oliver Ford <oliford_at_oliford.co.uk> wrote:
>
> >> There is one small thing I still have no clue about, what are the
> >> "Alternate Function Selections" MFP_AF0 through MFP_AF7?
> >>
> > Represents a maximum of 8 possibilities of alternate function for
> > a MFP (Multi-Function Pin).
> >
>
> I'm following this much better now. Looking at the dump of the MFP
> config windows uses, a lot of things (like the LCD) have pins selected
> to the same AF as the Zylonite configuration does. Some others, like the
> FFUART, have different pins configured with an AF to do the job,
> consistent with alternate configurations you have defined in
> mfp-pxa300.h. However, other systems, like the AC97 and MMC2 look like
> windows doesn't use any of the configurations in mfp-pxa300.h. Is this a
> complete list? If not, is there any way I can get hold of a list of what
> the alternate functions do for each pin?
>
This is a quite complete list except for some devices we don't yet
have a driver for. MFP in win might have slightly different drive
strength but the alternate function should be at least same.
BTW: windows uses a different and much more complicated framework
than Linux does, so there is no strict one-to-one mapping relationship.
> The MFP configs windows uses often have bit 15 (MFPR_PULL_SEL) set but
> neither of bits 14 or 13 (MFPR_PULLUP_EN or MFPR_PULLDOWN_EN) set. What
> exactly does this mean, if anything, as mfp-pxa3xx.h doesn't list it as
> a possibility?
>
The purpose of setting PULL_SEL while leaving PULLUP_EN/PULLDOWN_EN
is to override the default pull settings and leave both pull up/down resistors
unconnected. I doubt this is necessary for the vast majority of the MFP, but
some pins may require such weird setting. A basic observation is that leaving
PULL_SEL as zero should work in most cases.
> The wireless/bluetooth LED, btw, was being switched off on the way into
> linux when the Zylonite config was reconfiguring GPIO3_2 for the keypad.
> Windows has GPIO3_2 config'ed to AF0 with DS04X (I'm guessing that most
> of the AF0's are 'direct to bit in GPIO registers' config) and GPIO3
> config'ed to AF4 (not sure where that goes). Clearing GPIO bit 3 in
> windows turns off the LED but doesn't effect the bluetooth link. I
> suspect, assuming that DS04X is just a slightly higher current
> availability pin (4mA by any chance?), that this is just wired to the
> LED. Either way, I now have complete control over 1 device... the LED.
>
Good news. The default of a GPIO drive strength is DS03X, which is
supposed to work in most cases. Driving a LED directly through a
GPIO doesn't look like a good idea, though the MFP can sometime
provide more current than what the doc said.
>
> Thanks for all the help,
>
> Oliver
>
-- Cheers - ericReceived on Thu Mar 13 2008 - 20:03:42 EST
This archive was generated by hypermail 2.2.0 : Fri Mar 14 2008 - 00:54:48 EST