Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OS
U-Boot.Mirror
提交
a09c6499
U
U-Boot.Mirror
项目概览
OS
/
U-Boot.Mirror
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
U
U-Boot.Mirror
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
a09c6499
编写于
8月 08, 2012
作者:
P
Pavel Herrmann
提交者:
Wolfgang Denk
9月 02, 2012
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
dm: add PCI design document
Signed-off-by:
N
Pavel Herrmann
<
morpheus.ibis@gmail.com
>
上级
f07563a7
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
265 addition
and
0 deletion
+265
-0
doc/driver-model/UDM-pci.txt
doc/driver-model/UDM-pci.txt
+265
-0
未找到文件。
doc/driver-model/UDM-pci.txt
0 → 100644
浏览文件 @
a09c6499
The U-Boot Driver Model Project
===============================
PCI subsystem analysis
======================
Pavel Herrmann <morpheus.ibis@gmail.com>
2012-03-17
I) Overview
-----------
U-Boot already supports multiple PCI busses, stored in a linked-list of
pci_controller structures. This structure contains generic driver data, bus
interface operations and private data for the driver.
Bus interface operations for PCI are (names are self-explanatory):
read_byte()
read_word()
read_dword()
write_byte()
write_word()
write_dword()
Each driver has to implement dword operations, and either implement word and
byte operations, or use shared $operation_config_$type_via_dword (eg.
read_config_byte_via_dword and similar) function. These functions are used
for config space I/O (read_config_dword and similar functions of the PCI
subsystem), which is used to configure the connected devices for standard MMIO
operations. All data transfers by respective device drivers are then done by
MMIO
Each driver also defines a separate init function, which has unique symbol
name, and thus more drivers can be compiled in without colliding. This init
function is typically called from pci_init_board(), different for each
particular board.
Some boards also define a function called fixup_irq, which gets called after
scanning the PCI bus for devices, and should dismiss any interrupts.
Several drivers are also located in arch/ and should be moved to drivers/pci.
II) Approach
------------
The pci_controller structure needs to be broken down to fit the new driver
model. Due to a large number of members, this will be done through three
distinct accessors, one for memory regions, one for config table and one for
everything else. That will make the pci_ops structure look like this:
struct pci_ops {
int (*read_byte)(struct instance *bus, pci_dev_t *dev, int addr,
u8 *buf);
int (*read_word)(struct instance *bus, pci_dev_t *dev, int addr,
u16 *buf);
int (*read_dword)(struct instance *bus, pci_dev_t *dev, int addr,
u32 *buf);
int (*write_byte)(struct instance *bus, pci_dev_t *dev, int addr,
u8 val);
int (*write_byte)(struct instance *bus, pci_dev_t *dev, int addr,
u8 val);
int (*write_dword)(struct instance *bus, pci_dev_t *dev, int addr,
u32 val);
void (*fixup_irq)(struct instance *bus, pci_dev_t *dev);
struct pci_region* (*get_region)(struct instance *, uint num);
struct pci_config_table* (*get_cfg_table)(struct instance *bus);
uint (*get_option)(struct instance * bus, enum pci_option_code op);
}
enum pci_option_code {
PCI_OPT_BUS_NUMBER=0,
PCI_OPT_REGION_COUNT,
PCI_OPT_INDIRECT_TYPE,
PCI_OPT_AUTO_MEM,
PCI_OPT_AUTO_IO,
PCI_OPT_AUTO_PREFETCH,
PCI_OPT_AUTO_FB,
PCI_OPT_CURRENT_BUS,
PCI_OPT_CFG_ADDR,
}
The return value for get_option will be an unsigned integer value for any
option code. If the option currently is a pointer to pci_region, it will
return an index for get_region function. Special case has to be made for
PCI_OPT_CFG_ADDR, which should be interpreted as a pointer, but it is only
used for equality in find_hose_by_cfg_addr, and thus can be returned as an
uint. Other function using cfg_addr value are read/write functions for
specific drivers (especially ops for indirect bridges), and thus have access
to private_data of the driver instance.
The config table accessor will return a pointer to a NULL-terminated array of
pci_config_table, which is supplied by the board in platform_data, or NULL if
the board didn't specify one. This table is used to override PnP
auto-initialization, or to specific initialization functions for non-PNP
devices.
Transparent PCI-PCI bridges will get their own driver, and will forward all
operations to operations of their parent bus. This however makes it
impossible to use instances to identify devices, as not all devices will be
directly visible to the respective bus driver.
Init functions of controller drivers will be moved to their respective
probe() functions, in accordance to the driver model.
The PCI core will handle all mapping functions currently found in pci.c, as
well as proxy functions for read/write operations of the drivers. The PCI
core will also handle bus scanning and device configuration.
The PnP helper functions currently in pci_auto.c will also be a part of PCI
core, but they will be exposed only to PCI controller drivers, not to other
device drivers.
The PCI API for device drivers will remain largely unchanged, most drivers
will require no changes at all, and all modifications will be limited to
changing the pci_controlle into instance*.
III) Analysis of in-tree drivers
--------------------------------
A) drivers in drivers/pci/
--------------------------
1) pci_indirect.c
-----------------
Shared driver for indirect PCI bridges, several CONFIG macros - will
require significant cleanup.
2) pci_ixp.c
------------
Standard driver, specifies all read/write functions separately.
3) pci_sh4.c
------------
Shared init function for SH4 drivers, uses dword for read/write ops.
4) pci_sh7751.c
---------------
Standard driver, uses SH4 shared init.
5) pci_sh7780.c
---------------
Standard driver, uses SH4 shared init.
6) tsi108_pci.c
---------------
Standard driver, uses dword for read/write ops.
7) fsl_pci_init.c
-----------------
Driver for PCI and PCI-e, uses indirect functions.
8) pci_ftpci100.c
-----------------
Standard driver, uses indirect functions, has separate scan/setup
functions.
B) driver in arch/
------------------
1) x86/lib/pci_type1.c
----------------------
Standard driver, specifies all read/write functions separately.
2) m68k/cpu/mcf5445x/pci.c
--------------------------
Standard driver, specifies all read/write functions separately.
3) m68k/cpu/mcf547x_8x/pci.c
----------------------------
Standard driver, specifies all read/write functions separately.
4) powerpc/cpu/mpc824x/pci.c
----------------------------
Standard driver, uses indirect functions, does not setup HW.
5) powerpc/cpu/mpc8260/pci.c
----------------------------
Standard driver, uses indirect functions.
6) powerpc/cpu/ppc4xx/4xx_pci.c
-------------------------------
Standard driver, uses indirect functions.
7) powerpc/cpu/ppc4xx/4xx_pcie.c
--------------------------------
PCI-e driver, specifies all read/write functions separately.
8) powerpc/cpu/mpc83xx/pci.c
----------------------------
Standard driver, uses indirect functions.
9) powerpc/cpu/mpc83xx/pcie.c
-----------------------------
PCI-e driver, specifies all read/write functions separately.
10) powerpc/cpu/mpc5xxx/pci_mpc5200.c
-------------------------------------
Standard driver, uses dword for read/write ops.
11) powerpc/cpu/mpc512x/pci.c
-----------------------------
Standard driver, uses indirect functions.
12) powerpc/cpu/mpc8220/pci.c
-----------------------------
Standard driver, specifies all read/write functions separately.
13) powerpc/cpu/mpc85xx/pci.c
-----------------------------
Standard driver, uses indirect functions, has two busses.
C) drivers in board/
--------------------
1) eltec/elppc/pci.c
--------------------
Standard driver, uses indirect functions.
2) amirix/ap1000/pci.c
----------------------
Standard driver, specifies all read/write functions separately.
3) prodrive/p3mx/pci.c
----------------------
Standard driver, uses dword for read/write ops, has two busses.
4) esd/cpci750/pci.c
--------------------
Standard driver, uses dword for read/write ops, has two busses.
5) esd/common/pci.c
-------------------
Standard driver, uses dword for read/write ops.
6) dave/common/pci.c
--------------------
Standard driver, uses dword for read/write ops.
7) ppmc7xx/pci.c
----------------
Standard driver, uses indirect functions.
8) pcippc2/cpc710_pci.c
-----------------------
Standard driver, uses indirect functions, has two busses.
9) Marvell/db64360/pci.c
------------------------
Standard driver, uses dword for read/write ops, has two busses.
10) Marvell/db64460/pci.c
-------------------------
Standard driver, uses dword for read/write ops, has two busses.
11) evb64260/pci.c
------------------
Standard driver, uses dword for read/write ops, has two busses.
12) armltd/integrator/pci.c
---------------------------
Standard driver, specifies all read/write functions separately.
All drivers will be moved to drivers/pci. Several drivers seem
similar/identical, especially those located under board, and may be merged
into one.
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录