2006-04-29 21:06:00 +02:00
|
|
|
/*
|
|
|
|
* Platform information definitions for the CPM Uart driver.
|
|
|
|
*
|
|
|
|
* 2006 (c) MontaVista Software, Inc.
|
|
|
|
* Vitaly Bordug <vbordug@ru.mvista.com>
|
|
|
|
*
|
|
|
|
* This file is licensed under the terms of the GNU General Public License
|
|
|
|
* version 2. This program is licensed "as is" without any warranty of any
|
|
|
|
* kind, whether express or implied.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef FS_UART_PD_H
|
|
|
|
#define FS_UART_PD_H
|
|
|
|
|
|
|
|
#include <linux/version.h>
|
|
|
|
#include <asm/types.h>
|
|
|
|
|
|
|
|
enum fs_uart_id {
|
|
|
|
fsid_smc1_uart,
|
|
|
|
fsid_smc2_uart,
|
|
|
|
fsid_scc1_uart,
|
|
|
|
fsid_scc2_uart,
|
|
|
|
fsid_scc3_uart,
|
|
|
|
fsid_scc4_uart,
|
|
|
|
fs_uart_nr,
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline int fs_uart_id_scc2fsid(int id)
|
|
|
|
{
|
|
|
|
return fsid_scc1_uart + id - 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int fs_uart_id_fsid2scc(int id)
|
|
|
|
{
|
|
|
|
return id - fsid_scc1_uart + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int fs_uart_id_smc2fsid(int id)
|
|
|
|
{
|
|
|
|
return fsid_smc1_uart + id - 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int fs_uart_id_fsid2smc(int id)
|
|
|
|
{
|
|
|
|
return id - fsid_smc1_uart + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct fs_uart_platform_info {
|
2006-09-21 20:38:05 +02:00
|
|
|
void(*init_ioports)(struct fs_uart_platform_info *);
|
2006-04-29 21:06:00 +02:00
|
|
|
/* device specific information */
|
|
|
|
int fs_no; /* controller index */
|
POWERPC: Bring the fs_no calculation to the relevant SoC enumeration
The fs_no mean used to be fs_enet driver driven, hence it was an
enumeration across all the possible fs_enet "users" in the SoC. Now, with
QE on the pipeline, and to make DTS descriptions more clear, fs_no features
relevant SoC part number, with additional field to describe the SoC type.
Another reason for that is now not only fs_enet is going to utilize those
stuff. There might be UART, HLDC, and even USB, so to prevent confusion and
be ready for upcoming OF_device transfer, fs_enet and cpm_uart drivers were
updated in that concern, as well as the relevant DTS.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
2006-09-21 20:38:05 +02:00
|
|
|
char fs_type[4]; /* controller type */
|
2006-04-29 21:06:00 +02:00
|
|
|
u32 uart_clk;
|
|
|
|
u8 tx_num_fifo;
|
|
|
|
u8 tx_buf_size;
|
|
|
|
u8 rx_num_fifo;
|
|
|
|
u8 rx_buf_size;
|
|
|
|
u8 brg;
|
2006-09-21 20:38:05 +02:00
|
|
|
u8 clk_rx;
|
|
|
|
u8 clk_tx;
|
2006-04-29 21:06:00 +02:00
|
|
|
};
|
|
|
|
|
POWERPC: Bring the fs_no calculation to the relevant SoC enumeration
The fs_no mean used to be fs_enet driver driven, hence it was an
enumeration across all the possible fs_enet "users" in the SoC. Now, with
QE on the pipeline, and to make DTS descriptions more clear, fs_no features
relevant SoC part number, with additional field to describe the SoC type.
Another reason for that is now not only fs_enet is going to utilize those
stuff. There might be UART, HLDC, and even USB, so to prevent confusion and
be ready for upcoming OF_device transfer, fs_enet and cpm_uart drivers were
updated in that concern, as well as the relevant DTS.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
2006-09-21 20:38:05 +02:00
|
|
|
static inline int fs_uart_get_id(struct fs_uart_platform_info *fpi)
|
|
|
|
{
|
|
|
|
if(strstr(fpi->fs_type, "SMC"))
|
|
|
|
return fs_uart_id_smc2fsid(fpi->fs_no);
|
|
|
|
if(strstr(fpi->fs_type, "SCC"))
|
|
|
|
return fs_uart_id_scc2fsid(fpi->fs_no);
|
|
|
|
return fpi->fs_no;
|
|
|
|
}
|
|
|
|
|
2006-04-29 21:06:00 +02:00
|
|
|
#endif
|