因为我是做单片机上来的,所以,在看代码的时候,总会去想,这个代码是怎么和硬件扯上关系的。比如,我现在用的CPU是 Atmel的9G20. 我想用的是它的SPI1。
这个SPI 对应的引脚分别是 :
PB0 -> SPI1_MISO
PB1 -> SPI1_MOSI
PB2 -> SPI1_SPCK
PB3 -> SPI1_NPCS0
不管什么系统,它在使用前一定会初始化硬件设备,所以我觉得先找到内核初始化板子的函数才有一点头绪。 后来到网上查询,知道与硬件相关的基本上都在 arch 目录下面。
因为我使用的是 sam9g20。 arm 架构。 所以我进入的目录 便是 arch/arm/mach-at91 .
进去之后发现有两个 c 文件是关于9g20的,因为在配置内核时,选择的是 mmc。 所以我们使用的应该是 Board-sam9g20ek-2slot-mmc.c这个文件。
于是打开它。在这个文件里面能看到很多被 ‘ __init ’ 修饰的函数,大概猜想他们就是初始化板子硬件的函数。在文件的后面有一段代码:
MACHINE_START(AT91SAM9G20EK_2MMC, "Atmel AT91SAM9G20-EK 2 MMC Slot Mod")
/* Maintainer: Rob Emanuele */
.phys_io = AT91_BASE_SYS,
.io_pg_offst = (AT91_VA_BASE_SYS >> 18) & 0xfffc,
.boot_params = AT91_SDRAM_BASE + 0x100,
.timer = &at91sam926x_timer,
.map_io = ek_map_io,
.init_irq = ek_init_irq,
.init_machine = ek_board_init,
MACHINE_END
于是我觉得这个文件就是初始化相关硬件/设备的。 随后找到 ek_board_init 函数。 在里面发现了 at91_add_device_spi(ek_spi_devices, ARRAY_SIZE(ek_spi_devices));
函数的调用。于是追踪这个函数,在目录下查找 at91_add_device_spi 字符:
发现与 9G20 相关的都是调用它,没有它的原型。于是打开Makefile, 看看,与9G20 相关的文件还有哪些:
从图中可以看到,与9G20相关的还有两个 9260的文件,他们公用一些代码。于是直接打开 xxx9260_devices.c. 果不其然,找到了at91_add_device_spi 函数的原型。
我截出一部分代码:
/* Configure SPI bus(es) */
if (enable_spi0) {
at91_set_A_periph(AT91_PIN_PA0, 0); /* SPI0_MISO */
at91_set_A_periph(AT91_PIN_PA1, 0); /* SPI0_MOSI */
at91_set_A_periph(AT91_PIN_PA2, 0); /* SPI1_SPCK */
at91_clock_associate("spi0_clk", &at91sam9260_spi0_device.dev, "spi_clk");
platform_device_register(&at91sam9260_spi0_device);
}
if (enable_spi1) {
at91_set_A_periph(AT91_PIN_PB0, 0); /* SPI1_MISO */
at91_set_A_periph(AT91_PIN_PB1, 0); /* SPI1_MOSI */
at91_set_A_periph(AT91_PIN_PB2, 0); /* SPI1_SPCK */
at91_clock_associate("spi1_clk", &at91sam9260_spi1_device.dev, "spi_clk");
platform_device_register(&at91sam9260_spi1_device);
}
看到这里,心里一阵高兴,终于看到这几个引脚了。 他们就是我上面列出来的几个与SPI1相关的引脚。 从代码上来看,要初始化SPI 是需要条件的。就是 enable_spi1 要不等于0. 再慢慢看代码,知道与传入这个函数的参数有关。于是再掉头回来看调用这个函数的地方。 返回到 Board-sam9g20ek-2slot-mmc.c , 发现传入的参数是 ek_spi_devices 和 ARRAY_SIZE(ek_spi_devices)。 从字面上看,后者应该表示前者的尺寸。 老办法,找到ek_spi_devices 数组就在本文件内。
/*
* SPI devices.
*/
static struct spi_board_info ek_spi_devices[] = {
#if !(defined(CONFIG_MMC_ATMELMCI) || defined(CONFIG_MMC_AT91))
{ /* DataFlash chip */
.modalias = "mtd_dataflash",
.chip_select = 1,
.max_speed_hz = 15 * 1000 * 1000,
.bus_num = 0,
},
#if defined(CONFIG_MTD_AT91_DATAFLASH_CARD)
{ /* DataFlash card */
.modalias = "mtd_dataflash",
.chip_select = 0,
.max_speed_hz = 15 * 1000 * 1000,
.bus_num = 0,
},
#endif
#endif
};
看起来还是很简单,后来网上查了一下,得出了进一步的信息:
struct spi_board_info { char modalias[SPI_NAME_SIZE]; const void * platform_data; void * controller_data; int irq; u32 max_speed_hz; u16 bus_num; u16 chip_select; u8 mode; };
Members
Initializes spi_device.modalias; identifies the driver.
platform_dataInitializes spi_device.platform_data; the particular data stored there is driver-specific.
controller_dataInitializes spi_device.controller_data; some controllers need hints about hardware setup, e.g. for DMA.
irqInitializes spi_device.irq; depends on how the board is wired.
max_speed_hzInitializes spi_device.max_speed_hz; based on limits from the chip datasheet and board-specific signal quality issues.
bus_numIdentifies which spi_master parents the spi_device; unused by spi_new_device, and otherwise depends on board wiring.
chip_selectInitializes spi_device.chip_select; depends on how the board is wired.
modeInitializes spi_device.mode; based on the chip datasheet, board wiring (some devices support both 3WIRE and standard modes), and possibly presence of an inverter in the chipselect path.
Description
When adding new SPI devices to the device tree, these structures serve as a partial device template. They hold information which can't always be determined by drivers. Information that probe can establish (such as the default transfer wordsize) is not included here.
These structures are used in two places. Their primary role is to be stored in tables of board-specific device descriptors, which are declared early in board initialization and then used (much later) to populate a controller's device tree after the that controller's driver initializes. A secondary (and atypical) role is as a parameter to spi_new_device call, which happens after those controller drivers are active in some dynamic board configuration models.
于是自己仿照着写了一个:
* SPI devices.
*/
static struct spi_board_info ek_spi_devices[] = {
{
.modalias = "HCMS-29xx",
.chip_select = 0, // choice PB3
.max_speed_hz = 1*1000*1000,
.bus_num = 1, // SPI1
},
};
后面要做的就是驱动了。这个网上有很多资料,大家看看就可以了,我主要说明一下,我们在SPI的驱动里需要自己实现probe函数。 因为在内核将我们的驱动和刚刚我们
申请的SPI 设备匹配成功后就需要调用这个函数。 写驱动时,大家要注意了,我们需要申明一个名为 spi_driver 的结构体。下面是我申请的结构体:
static struct spi_driver hcms29xx_spi_driver = {
.driver = {
.name = "HCMS-29xx",
.owner = THIS_MODULE,
},
.probe = hcms29xx_spi_probe,
.remove = hcms29xx_spi_remove
};
注意里面有一个 .name 的成员。 它是设备和驱动匹配的关键。 想想我们在前面初始化SPI设备后,它是怎么和我们写的驱动挂上勾的呢? 就是它! 这个结构体里面的.name.
就是靠他和前面设备里 那个 modalias 成员。 所以我们在给他们赋值时。他们的取值要相等,这样才能匹配成功。
剩下的就是写驱动和调试驱动了,这些就不必说了吧,会C语言的基本上都会,