
/*****************************************************************************
* Copyright (c) 2004 Digi International Inc., All Rights Reserved
* 
* This software contains proprietary and confidential information of Digi
* International Inc.  By accepting transfer of this copy, Recipient agrees
* to retain this software in confidence, to prevent disclosure to others,
* and to make no use of this software other than that for which it was
* delivered.  This is an unpublished copyrighted work of Digi International
* Inc.  Except as permitted by federal law, 17 USC 117, copying is strictly
* prohibited.
* 
* Restricted Rights Legend
*
* Use, duplication, or disclosure by the Government is subject to
* restrictions set forth in sub-paragraph (c)(1)(ii) of The Rights in
* Technical Data and Computer Software clause at DFARS 252.227-7031 or
* subparagraphs (c)(1) and (2) of the Commercial Computer Software -
* Restricted Rights at 48 CFR 52.227-19, as applicable.
*
* Digi International Inc. 11001 Bren Road East, Minnetonka, MN 55343
*
*****************************************************************************/
/* GPIO for Amsterdam Platform. */
/*
 * $Log: gpioplatform.c,v $
 * Revision 1.1.2.2  2008/09/05 17:17:16  lzhen
 * fix CTS status read on ns9215/ns9210 serial driver
 *
 * Revision 1.3  2008/07/23 15:08:24  whagstro
 * Added the GPIO define for CTS on the n ns9210 and ns9215 based platforms.
 *
 * Revision 1.2  2008/02/12 21:20:03  lzhen
 * On NS9210 and NS9215, RTS in modem_ctrl register can't be controlled by
 *         software while CTS is used for HW flow control. To be able to use CTS to
 *         halt the transmitter, the HW requires the AFE bit in modem_ctrl register
 *         to be 1, but this requirement prohibits us writing to RTS directly.
 *         The work around of this problem is to use RTS pin as GPIO output 0/1 to control RTS.
 *         Refer to NS9215/NS9210 ASIC Errata on RTS.
 *
 * Revision 1.1  2007/07/18 21:16:41  cgordon
 * Renamed Camry-ME platform to connectme9210
 *
 * Revision 1.1  2007/04/11 14:14:20  cgordon
 * Added temporary platform for Connect-ME with Camry.
 *
 * Revision 1.1  2007/02/13 19:54:38  cgordon
 * Initial checkin of NS9210 on NS7520 board platform.
 *
 * Revision 1.3  2006/03/17 19:43:44  vshankar
 * Updated for powersave enhancement
 *
 * Revision 1.2  2005/09/22 22:40:00  lming
 * Changed all includes from " " to < >
 *
 * Revision 1.1  2005/04/28 13:37:41  jfu
 * Added new header file
 *
 * Revision 1.1.2.1  2005/04/27 23:14:36  jfu
 * Initial files for GPIO I2C expander
 *
 * Revision 1.1.2.3  2004/11/09 22:47:46  jamesp
 * Brought the "arch" specific code for ns9750 "up to date"
 * in the DigiXK_branch relative to the Amsterdam_branch.
 *
 * Revision 1.1.2.1.2.4  2004/07/09 17:36:13  jamesp
 * Retiring <include/types.h> and <bcomm/u32.h>.  The new file
 * <arch/include/fwtypes.h> takes its place.  <fwtypes.h> is
 * intended to be a global repository for types in the firmware.
 * It collects the stuff from <include/types.h>, <bcomm/u32.h>,
 * as well as from Npttypes.h.  This new <fwtypes.h> is then
 * shared between the boot and the eos via the "arch" tree.
 *
 * Revision 1.1.2.1.2.3  2004/06/28 20:00:47  markw
 * PCI_RST is now on the I2C GPIO pin previously used for MUX_EN, which has been
 * pulled down.
 *
 * Revision 1.1.2.1.2.2  2004/06/21 15:33:46  markw
 * Convert GPIO_INIT to GPIO_SOFTRESET to better describe its function.
 *
 * Revision 1.1.2.1.2.1  2004/06/16 16:15:53  markw
 * Changes to fix Gpio pins on amsterdam.
 *
 * Revision 1.1.2.1  2004/06/14 21:06:34  markw
 * Gpio abstraction for ns7520 products and Amsterdam products.  Now you request
 * gpio pin actions using a function name (e.g. GPIO_MFGO), and this is mapped
 * in a platform-specific way to a processor gpio pin, or an I2C pin, or ....
 *
 */


#include <assert.h>
#include <fwtypes.h>
#include <nagpio.h>
#include <gpioplatform.h>
#include <processorgpio.h>

/*   gpio_type			addr		gpio_pin */
const GpioPlatformTable_t GpioPlatformNone[] = {
    {GPIO_TYPE_PROCESSOR_PIN, 0,   14}, /* GPIO_ERROR_LED */
    {GPIO_TYPE_PROCESSOR_PIN, 0,   5},  /* GPIO_UARTA_RTS */
    {GPIO_TYPE_NONE, 0,   0}, 		/* GPIO_UARTB_RTS, this platform does not have PORTB */
    {GPIO_TYPE_NONE, 0,   0}, 		/* GPIO_UARTC_RTS, UARTC is only 2-wire, no RTS */
    {GPIO_TYPE_NONE, 0,   0}, 		/* GPIO_UARTD_RTS, this platform does not have PORTD */
    {GPIO_TYPE_PROCESSOR_PIN, 0,   1},  /* GPIO_UARTA_CTS */
    {GPIO_TYPE_NONE, 0,   0}, 		/* GPIO_UARTB_CTS, this platform does not have PORTB */
    {GPIO_TYPE_NONE, 0,   0}, 		/* GPIO_UARTC_CTS, UARTC is only 2-wire, no CTS */
    {GPIO_TYPE_NONE, 0,   0}, 		/* GPIO_UARTD_CTS, this platform does not have PORTD */
};

const GpioPlatformTable_t * const GpioPlatformTable[1] = {
    GpioPlatformNone,
};

const int GpioPlatformTableSize[1] = {
    sizeof(GpioPlatformNone)/sizeof(GpioPlatformNone[0]),
};

static int GpioPlatformMode(void)
{
    /* TO DO: If there are multiple modes in this platform, you should add
       codes here to either read from a static memory device or switch to
       decide which mode it is.

       For this platform, we only put in one mode.  One can update the table
       above and to add logic to find out what mode the hardware is set at.
       */
    return 0;
}

int GpioPlatformFunction(int function, unsigned long *gpio_type, unsigned long *addr, unsigned long *gpio_pin)
{
    int index = -1 - function;
    int mode = GpioPlatformMode();

    if (index < 0 || index >= GpioPlatformTableSize[mode])
        return FALSE;
    *gpio_type = GpioPlatformTable[mode][index].gpio_type;
    *addr	   = GpioPlatformTable[mode][index].addr;
    *gpio_pin  = GpioPlatformTable[mode][index].gpio_pin % 32;
    if (*gpio_type == GPIO_TYPE_NONE)
        return FALSE;
    return TRUE;
}

void GpioPlatform_epoch(void)
{
}
