SPI裝置端驅動編寫----基於linux4.9 driver核心層
【前序】
linux下寫驅動是站在巨人的肩膀上做開發,不用完全從頭做起,甚至你不需要懂SPI時序,照樣能寫出可用的驅動,原因是:控制器驅動一般晶片商早已寫好(linux4.9中針對xilinx zynqmp系列cpu是 drivers/spi/spi-cadence.c),怎麼發、怎麼操作CPU暫存器這些細節都是控制器驅動乾的事,裝置端驅動不需要關心。
我們所要做的便是用核心層提供的API註冊進去,呼叫核心層傳送函式,將資料發出去,收回來。linux4.9中核心層drivers/spi/spi.c。
一、重要的資料結構與核心層API
1. struct spi_transfer;
/*---------------------------------------------------------------------------*/
/*
* I/O INTERFACE between SPI controller and protocol drivers
*
* Protocol drivers use a queue of spi_messages, each transferring data
* between the controller and memory buffers.
*
* The spi_messages themselves consist of a series of read+write transfer
* segments. Those segments always read the same number of bits as they
* write; but one or the other is easily ignored by passing a null buffer
* pointer. (This is unlike most types of I/O API, because SPI hardware
* is full duplex.)
*
* NOTE: Allocation of spi_transfer and spi_message memory is entirely
* up to the protocol driver, which guarantees the integrity of both (as
* well as the data buffers) for as long as the message is queued.
*/
/**
* struct spi_transfer - a read/write buffer pair
* @tx_buf: data to be written (dma-safe memory), or NULL
* @rx_buf: data to be read (dma-safe memory), or NULL
* @tx_dma: DMA address of tx_buf, if @spi_message.is_dma_mapped
* @rx_dma: DMA address of rx_buf, if @spi_message.is_dma_mapped
* @tx_nbits: number of bits used for writing. If 0 the default
* (SPI_NBITS_SINGLE) is used.
* @rx_nbits: number of bits used for reading. If 0 the default
* (SPI_NBITS_SINGLE) is used.
* @len: size of rx and tx buffers (in bytes)
* @speed_hz: Select a speed other than the device default for this
* transfer. If 0 the default (from @spi_device) is used.
* @bits_per_word: select a bits_per_word other than the device default
* for this transfer. If 0 the default (from @spi_device) is used.
* @cs_change: affects chipselect after this transfer completes
* @delay_usecs: microseconds to delay after this transfer before
* (optionally) changing the chipselect status, then starting
* the next transfer or completing this @spi_message.
* @transfer_list: transfers are sequenced through @spi_message.transfers
* @tx_sg: Scatterlist for transmit, currently not for client use
* @rx_sg: Scatterlist for receive, currently not for client use
*
* SPI transfers always write the same number of bytes as they read.
* Protocol drivers should always provide @rx_buf and/or @tx_buf.
* In some cases, they may also want to provide DMA addresses for
* the data being transferred; that may reduce overhead, when the
* underlying driver uses dma.
*
* If the transmit buffer is null, zeroes will be shifted out
* while filling @rx_buf. If the receive buffer is null, the data
* shifted in will be discarded. Only "len" bytes shift out (or in).
* It's an error to try to shift out a partial word. (For example, by
* shifting out three bytes with word size of sixteen or twenty bits;
* the former uses two bytes per word, the latter uses four bytes.)
*
* In-memory data values are always in native CPU byte order, translated
* from the wire byte order (big-endian except with SPI_LSB_FIRST). So
* for example when bits_per_word is sixteen, buffers are 2N bytes long
* (@len = 2N) and hold N sixteen bit words in CPU byte order.
*
* When the word size of the SPI transfer is not a power-of-two multiple
* of eight bits, those in-memory words include extra bits. In-memory
* words are always seen by protocol drivers as right-justified, so the
* undefined (rx) or unused (tx) bits are always the most significant bits.
*
* All SPI transfers start with the relevant chipselect active. Normally
* it stays selected until after the last transfer in a message. Drivers
* can affect the chipselect signal using cs_change.
*
* (i) If the transfer isn't the last one in the message, this flag is
* used to make the chipselect briefly go inactive in the middle of the
* message. Toggling chipselect in this way may be needed to terminate
* a chip command, letting a single spi_message perform all of group of
* chip transactions together.
*
* (ii) When the transfer is the last one in the message, the chip may
* stay selected until the next transfer. On multi-device SPI busses
* with nothing blocking messages going to other devices, this is just
* a performance hint; starting a message to another device deselects
* this one. But in other cases, this can be used to ensure correctness.
* Some devices need protocol transactions to be built from a series of
* spi_message submissions, where the content of one message is determined
* by the results of previous messages and where the whole transaction
* ends when the chipselect goes intactive.
*
* When SPI can transfer in 1x,2x or 4x. It can get this transfer information
* from device through @tx_nbits and @rx_nbits. In Bi-direction, these
* two should both be set. User can set transfer mode with SPI_NBITS_SINGLE(1x)
* SPI_NBITS_DUAL(2x) and SPI_NBITS_QUAD(4x) to support these three transfer.
*
* The code that submits an spi_message (and its spi_transfers)
* to the lower layers is responsible for managing its memory.
* Zero-initialize every field you don't set up explicitly, to
* insulate against future API updates. After you submit a message
* and its transfers, ignore them until its completion callback.
*/
struct spi_transfer {
/* it's ok if tx_buf == rx_buf (right?)
* for MicroWire, one buffer must be null
* buffers must work with dma_*map_single() calls, unless
* spi_message.is_dma_mapped reports a pre-existing mapping
*/
const void *tx_buf;
void *rx_buf;
unsigned len;
dma_addr_t tx_dma;
dma_addr_t rx_dma;
struct sg_table tx_sg;
struct sg_table rx_sg;
unsigned cs_change:1;
unsigned tx_nbits:3;
unsigned rx_nbits:3;
#define SPI_NBITS_SINGLE 0x01 /* 1bit transfer */
#define SPI_NBITS_DUAL 0x02 /* 2bits transfer */
#define SPI_NBITS_QUAD 0x04 /* 4bits transfer */
u8 bits_per_word;
u16 delay_usecs;
u32 speed_hz;
u32 dummy;
struct list_head transfer_list;
};
2.struct spi_message;
/**
* struct spi_message - one multi-segment SPI transaction
* @transfers: list of transfer segments in this transaction
* @spi: SPI device to which the transaction is queued
* @is_dma_mapped: if true, the caller provided both dma and cpu virtual
* addresses for each transfer buffer
* @complete: called to report transaction completions
* @context: the argument to complete() when it's called
* @frame_length: the total number of bytes in the message
* @actual_length: the total number of bytes that were transferred in all
* successful segments
* @status: zero for success, else negative errno
* @queue: for use by whichever driver currently owns the message
* @state: for use by whichever driver currently owns the message
* @resources: for resource management when the spi message is processed
*
* A @spi_message is used to execute an atomic sequence of data transfers,
* each represented by a struct spi_transfer. The sequence is "atomic"
* in the sense that no other spi_message may use that SPI bus until that
* sequence completes. On some systems, many such sequences can execute as
* as single programmed DMA transfer. On all systems, these messages are
* queued, and might complete after transactions to other devices. Messages
* sent to a given spi_device are always executed in FIFO order.
*
* The code that submits an spi_message (and its spi_transfers)
* to the lower layers is responsible for managing its memory.
* Zero-initialize every field you don't set up explicitly, to
* insulate against future API updates. After you submit a message
* and its transfers, ignore them until its completion callback.
*/
struct spi_message {
struct list_head transfers;
struct spi_device *spi;
unsigned is_dma_mapped:1;
/* REVISIT: we might want a flag affecting the behavior of the
* last transfer ... allowing things like "read 16 bit length L"
* immediately followed by "read L bytes". Basically imposing
* a specific message scheduling algorithm.
*
* Some controller drivers (message-at-a-time queue processing)
* could provide that as their default scheduling algorithm. But
* others (with multi-message pipelines) could need a flag to
* tell them about such special cases.
*/
/* completion is reported through a callback */
void (*complete)(void *context);
void *context;
unsigned frame_length;
unsigned actual_length;
int status;
/* for optional use by whatever driver currently owns the
* spi_message ... between calls to spi_async and then later
* complete(), that's the spi_master controller driver.
*/
struct list_head queue;
void *state;
/* list of spi_res reources when the spi message is processed */
struct list_head resources;
};
3.struct spi_device;
/**
* struct spi_device - Master side proxy for an SPI slave device
* @dev: Driver model representation of the device.
* @master: SPI controller used with the device.
* @max_speed_hz: Maximum clock rate to be used with this chip
* (on this board); may be changed by the device's driver.
* The spi_transfer.speed_hz can override this for each transfer.
* @chip_select: Chipselect, distinguishing chips handled by @master.
* @mode: The spi mode defines how data is clocked out and in.
* This may be changed by the device's driver.
* The "active low" default for chipselect mode can be overridden
* (by specifying SPI_CS_HIGH) as can the "MSB first" default for
* each word in a transfer (by specifying SPI_LSB_FIRST).
* @bits_per_word: Data transfers involve one or more words; word sizes
* like eight or 12 bits are common. In-memory wordsizes are
* powers of two bytes (e.g. 20 bit samples use 32 bits).
* This may be changed by the device's driver, or left at the
* default (0) indicating protocol words are eight bit bytes.
* The spi_transfer.bits_per_word can override this for each transfer.
* @irq: Negative, or the number passed to request_irq() to receive
* interrupts from this device.
* @controller_state: Controller's runtime state
* @controller_data: Board-specific definitions for controller, such as
* FIFO initialization parameters; from board_info.controller_data
* @modalias: Name of the driver to use with this device, or an alias
* for that name. This appears in the sysfs "modalias" attribute
* for driver coldplugging, and in uevents used for hotplugging
* @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when
* when not using a GPIO line)
*
* @statistics: statistics for the spi_device
*
* A @spi_device is used to interchange data between an SPI slave
* (usually a discrete chip) and CPU memory.
*
* In @dev, the platform_data is used to hold information about this
* device that's meaningful to the device's protocol driver, but not
* to its controller. One example might be an identifier for a chip
* variant with slightly different functionality; another might be
* information about how this particular board wires the chip's pins.
*/
struct spi_device {
struct device dev;
struct spi_master *master;
u32 max_speed_hz;
u8 chip_select;
u8 bits_per_word;
u16 mode;
#define SPI_CPHA 0x01 /* clock phase */
#define SPI_CPOL 0x02 /* clock polarity */
#define SPI_MODE_0 (0|0) /* (original MicroWire) */
#define SPI_MODE_1 (0|SPI_CPHA)
#define SPI_MODE_2 (SPI_CPOL|0)
#define SPI_MODE_3 (SPI_CPOL|SPI_CPHA)
#define SPI_CS_HIGH 0x04 /* chipselect active high? */
#define SPI_LSB_FIRST 0x08 /* per-word bits-on-wire */
#define SPI_3WIRE 0x10 /* SI/SO signals shared */
#define SPI_LOOP 0x20 /* loopback mode */
#define SPI_NO_CS 0x40 /* 1 dev/bus, no chipselect */
#define SPI_READY 0x80 /* slave pulls low to pause */
#define SPI_TX_DUAL 0x100 /* transmit with 2 wires */
#define SPI_TX_QUAD 0x200 /* transmit with 4 wires */
#define SPI_RX_DUAL 0x400 /* receive with 2 wires */
#define SPI_RX_QUAD 0x800 /* receive with 4 wires */
int irq;
void *controller_state;
void *controller_data;
char modalias[SPI_NAME_SIZE];
int cs_gpio; /* chip select gpio */
/* the statistics */
struct spi_statistics statistics;
/*
* likely need more hooks for more protocol options affecting how
* the controller talks to each chip, like:
* - memory packing (12 bit samples into low bits, others zeroed)
* - priority
* - drop chipselect after each word
* - chipselect delays
* - ...
*/
};
4. 傳送接收函式:
/**
* spi_write_then_read - SPI synchronous write followed by read
* @spi: device with which data will be exchanged
* @txbuf: data to be written (need not be dma-safe)
* @n_tx: size of txbuf, in bytes
* @rxbuf: buffer into which data will be read (need not be dma-safe)
* @n_rx: size of rxbuf, in bytes
* Context: can sleep
*
* This performs a half duplex MicroWire style transaction with the
* device, sending txbuf and then reading rxbuf. The return value
* is zero for success, else a negative errno status code.
* This call may only be used from a context that may sleep.
*
* Parameters to this routine are always copied using a small buffer;
* portable code should never use this for more than 32 bytes.
* Performance-sensitive or bulk transfer code should instead use
* spi_{async,sync}() calls with dma-safe buffers.
*
* Return: zero on success, else a negative error code.
*/
int spi_write_then_read(struct spi_device *spi,
const void *txbuf, unsigned n_tx,
void *rxbuf, unsigned n_rx)
5.註冊:
/* 這是個巨集定義,是spi_register_driver() 與 spi_unrigerset_driver()的組合
#define module_driver(__driver, __register, __unregister, ...) \
static int __init __driver##_init(void) \
{ \
return __register(&(__driver) , ##__VA_ARGS__); \
} \
module_init(__driver##_init); \
static void __exit __driver##_exit(void) \
{ \
__unregister(&(__driver) , ##__VA_ARGS__); \
} \
module_exit(__driver##_exit);
*/
module_spi_driver(dac37j84_spi_driver);
二、在dts中對應的裝置樹節點:
1.管腳對映:
spi0的四根線可以根據板子硬體連線情況對映到不同的管腳上,針對ZYNQMP-zcu102這塊CPU來說,與spi控制器的連線有兩種方式:
<1> 使用PS域的MIO :mio[77:0]中某些引腳的複用功能是spi,但得成組配(裝置樹中pinctrl章節,有專用的格式);
<2> 使用PL,bit檔案中直接將某幾個PL域的引腳連到SPI控制器的輸出上。(我用的是這種方案,這樣就不要進行引腳複用功能設定了,裝置樹中亦可不必指定pinctrl)
引腳複用功能分組見drivers/pinctrl/pinctrl-zynqmp.c ; 裝置樹中與引腳相關的關鍵字解析以及定義見drivers/pinctrl/devicetree.c drivers/pinctrl/pinconf-generic.c;
&pinctrl0 {
status = "okay";
pinctrl_i2c1_default: i2c1-default {
mux {
groups = "i2c1_4_grp";
function = "i2c1";
};
conf {
groups = "i2c1_4_grp";
bias-pull-up;
slew-rate = <SLEW_RATE_SLOW>;
io-standard = <IO_STANDARD_LVCMOS18>;
};
};
pinctrl_i2c1_gpio: i2c1-gpio {
mux {
groups = "gpio0_16_grp", "gpio0_17_grp";
function = "gpio0";
};
conf {
groups = "gpio0_16_grp", "gpio0_17_grp";
slew-rate = <SLEW_RATE_SLOW>;
io-standard = <IO_STANDARD_LVCMOS18>;
};
};
pinctrl_uart0_default: uart0-default {
mux {
groups = "uart0_4_grp";
function = "uart0";
};
conf {
groups = "uart0_4_grp";
slew-rate = <SLEW_RATE_SLOW>;
io-standard = <IO_STANDARD_LVCMOS18>;
};
conf-rx {
pins = "MIO18";
bias-high-impedance;
};
conf-tx {
pins = "MIO19";
bias-disable;
};
};
pinctrl_spi0_default: spi0-default {
mux {
groups = "spi0_0_grp";//使用第幾組引腳,查pinctrl-zynqmp.c
function = "spi0";
};
conf {
groups = "spi0_0_grp";//對上面選中的那組管腳做電氣特性設定
bias-disable;
slew-rate = <SLEW_RATE_SLOW>;//速率
io-standard = <IO_STANDARD_LVCMOS18>;//電壓型別
};
mux-cs {
groups = "spi0_0_ss0_grp", "spi0_0_ss1_grp", "spi0_0_ss2_grp";//spi0_cs_x選哪幾個引腳用作spi0的cs
function = "spi0_ss";
};
conf-cs {
groups = "spi0_0_ss0_grp", "spi0_0_ss1_grp", "spi0_0_ss2_grp";
bias-disable;
};
};
};
amba: amba {
compatible = "simple-bus";
u-boot,dm-pre-reloc;
#address-cells = <2>;
#size-cells = <2>;
ranges;
此處省略n行...
spi0: [email protected] {
compatible = "cdns,spi-r1p6";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 19 4>;
reg = <0x0 0xff040000 0x0 0x1000>;
clock-names = "ref_clk", "pclk";
#address-cells = <1>;
#size-cells = <0>;
num-cs = <1>;
power-domains = <&pd_spi0>;
};
此處省略n行...
};
//繼承自上面
&spi0 {
status = "okay";
is-dual = <1>;
num-cs = <1>;
/* 用PS域引腳時得配複用功能,就得加這兩句
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_spi0_default>;
*/
[email protected]0 {
compatible = "lmk04828"; /* 32MB */
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0>;
pl-cs-addr = <0xA0000000>;
pl-cs-val = <0x00020000>;
#spi-cpha;
#spi-cpol;
spi-max-frequency = <8000000>; /* Based on DC1 spec */
};
};
三、例項:
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/spi/spi.h>
#include <linux/spi/spidev.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/acpi.h>
#include <linux/miscdevice.h>
#include <linux/cdev.h>
#include <linux/fs.h>
#include <linux/errno.h>
#include <asm/current.h>
#include <linux/sched.h>
#include <linux/uaccess.h>
#include <linux/device.h>
#include <linux/delay.h>
#define MASK_WRITE 0x80
#define MASK_READ 0x80
#define MASK_SEVE 0x60
#define MASK_ADDR_H 0x1F
#define SPI_SPEED_HZ 200000
#define LMK04828_MAGIC 'K'
#define GET_REG _IOR(LMK04828_MAGIC, 0,int)
#define SET_REG _IOW(LMK04828_MAGIC, 0, int)
struct lmk04828_t {
dev_t devt;
struct miscdevice misc_dev;
spinlock_t spi_lock;
struct spi_device *spi;
struct list_head device_entry;
/* TX/RX buffers are NULL unless this device is open (users > 0) */
struct mutex buf_lock;
unsigned users;
u8 *tx_buffer;
u8 *rx_buffer;
u32 speed_hz;
u32 cur_index; //record the register offset
void __iomem * pl_cs_addr;
u32 pl_cs_val;
};
static struct lmk04828_t *lmk04828;
void lmk04828spi_cs(void)
{
iowrite32( lmk04828->pl_cs_val, lmk04828->pl_cs_addr);
}
static ssize_t lmk04828spi_sync(struct lmk04828_t *spidev, struct spi_message *message)
{
DECLARE_COMPLETION_ONSTACK(done);
int status;
struct spi_device *spi;
spin_lock_irq(&spidev->spi_lock);
spi = spidev->spi;
spin_unlock_irq(&spidev->spi_lock);
lmk04828spi_cs();
if (spi == NULL)
status = -ESHUTDOWN;
else
status = spi_sync(spi, message);
if (status == 0)
status = message->actual_length;
return status;
}
static ssize_t lmk04828spi_sync_write(struct lmk04828_t *spidev, size_t len)
{
struct spi_transfer t = {
.tx_buf = spidev->tx_buffer,
.len = len,
.speed_hz = spidev->speed_hz,
};
struct spi_message m;
spi_message_init(&m);
spi_message_add_tail(&t, &m);
return lmk04828spi_sync(spidev, &m);
}
static ssize_t lmk04828spi_sync_read(struct lmk04828_t *spidev, size_t len)
{
struct spi_transfer t = {
.rx_buf = spidev->rx_buffer,
.len = len,
.speed_hz = spidev->speed_hz,
};
struct spi_message m;
spi_message_init(&m);
spi_message_add_tail(&t, &m);
return lmk04828spi_sync(spidev, &m);
}
int lmk04828_write_reg(int reg, unsigned char value)
{
unsigned char cmd[3]={0};
unsigned char addr_h = reg >> 8;
unsigned char addr_l = reg & 0xff;
cmd[0] = addr_h & MASK_ADDR_H;
cmd[0] &= ~ MASK_SEVE;
cmd[0] &= ~ MASK_WRITE;
cmd[1] = addr_l;
cmd[2] = value;
lmk04828->tx_buffer = cmd;
lmk04828->speed_hz = SPI_SPEED_HZ;
return lmk04828spi_sync_write(lmk04828, 3);
}
EXPORT_SYMBOL(lmk04828_write_reg);
int lmk04828_read_reg(int reg, unsigned char buff[1])
{
unsigned char cmd[3]={0};
unsigned char addr_h = reg >> 8;
unsigned char addr_l = reg & 0xff;
cmd[0] = addr_h & MASK_ADDR_H;
cmd[0] &= ~ MASK_SEVE;
cmd[0] |= MASK_READ;
cmd[1] = addr_l;
cmd[2] = 0;
lmk04828->tx_buffer = cmd;
lmk04828->rx_buffer = buff;
lmk04828->speed_hz = SPI_SPEED_HZ;
return spi_write_then_read(lmk04828->spi, cmd,2, buff, 1);
}
EXPORT_SYMBOL(lmk04828_read_reg);
int lmk04828_open(struct inode *node, struct file *pfile)
{
return 0;
}
int lmk04828_release(struct inode *node, struct file *pfile)
{
return 0;
}
loff_t lmk04828_llseek(struct file *pfile, loff_t off, int len)
{
lmk04828->cur_index = off;
return 0;
}
ssize_t lmk04828_read(struct file *pfile, char __user *buf, size_t size, loff_t *off)
{
unsigned char kbuf[1]={0};
mutex_lock(&lmk04828->buf_lock);
lmk04828_read_reg(lmk04828->cur_index, kbuf);
mutex_unlock(&lmk04828->buf_lock);
return copy_to_user(buf, kbuf, 1);
}
ssize_t lmk04828_write(struct file *pfile, const char __user *buf,
size_t size, loff_t *off)
{
unsigned char kbuf[1]={0};
int ret=0;
if ( 0 > copy_from_user(kbuf, buf, 1) ) {
printk(KERN_INFO "%s %s %d \n","copy to kbuf eer",__func__,__LINE__);
}
mutex_lock(&lmk04828->buf_lock);
ret = lmk04828_write_reg(lmk04828->cur_index,kbuf[0]);
mutex_unlock(&lmk04828->buf_lock);
return ret;
}
long lmk04828_ioctl(struct file *pfile, unsigned int cmd, unsigned long arg)
{
switch(cmd) {
case GET_REG:
break;
case SET_REG:
break;
default:
printk("invalid argument\n");
return -EINVAL;
}
return 0;
}
int lmk04828_reg_pll2_n(char enable, unsigned int val)
{
int ret1,ret2,ret3;
if (enable == 0) {
ret1 = lmk04828_write_reg(0x168, val & 0xff);
ret2 = lmk04828_write_reg(0x167, (val >> 8) & 0xff);
ret3 = lmk04828_write_reg(0x166, (val >> 16) & 0x03 );
} else {
ret1 = lmk04828_write_reg(0x168, val & 0xff);
ret2 = lmk04828_write_reg(0x167, (val >> 8) & 0xff);
ret3 = lmk04828_write_reg(0x166, ((val >> 16) & 0x03) | 0x04 );
}
if (ret1 >=0 && ret2 >=0 && ret3 >=0) {
return 0;
} else {
return -1;
}
}
int lmk04828_reg_init(void)
{
unsigned char regval =0;
if (0 > lmk04828_write_reg(0, 0x90) ) {
return -1;
}
if (0 > lmk04828_write_reg(0, 0x10) ) {
return -1;
}
//PIN MUX SET
if (0 > lmk04828_write_reg(0x14A, 0X33)) {
return -1;
}
if (0 > lmk04828_write_reg(0x145, 0x7F)) {
return -1;
}
if (0 > lmk04828_write_reg(0x171, 0xAA)) {
return -1;
}
if (0 > lmk04828_write_reg(0x172, 0x02)) {
return -1;
}
if (0 > lmk04828_write_reg(0x17C, 21)) {
return -1;
}
if (0 > lmk04828_write_reg(0x17D, 51)) {
return -1;
}
if (0 > lmk04828_reg_pll2_n(1,0x1fff)) {
return -1;
}
return 0;
}
static struct file_operations fops = {
.owner = THIS_MODULE,
.open = lmk04828_open,
.release = lmk04828_release,
.read = lmk04828_read,
.write = lmk04828_write,
.llseek = lmk04828_llseek,
.unlocked_ioctl = lmk04828_ioctl,
};
static int lmk04828_spi_probe(struct spi_device *spi)
{
struct lmk04828_t *lmk04828_data;
struct device_node *np;
u32 addrtmp;
printk("entre prine \n");
/* Allocate driver data */
lmk04828_data = kzalloc(sizeof(*lmk04828_data), GFP_KERNEL);
if (!lmk04828_data)
return -ENOMEM;
/* Initialize the driver data */
lmk04828_data->spi = spi;
lmk04828_data->speed_hz = SPI_SPEED_HZ;
spin_lock_init(&lmk04828_data->spi_lock);
mutex_init(&lmk04828_data->buf_lock);
INIT_LIST_HEAD(&lmk04828_data->device_entry);
lmk04828_data->misc_dev.fops = &fops;
lmk04828_data->misc_dev.name = "clk-lmk04828";
//主裝置號恆為10,自動分配次裝置號
lmk04828_data->misc_dev.minor = MISC_DYNAMIC_MINOR;
//3.註冊misc裝置
misc_register(&lmk04828_data->misc_dev);
np = of_find_node_by_name(NULL, "lmk04828");
if (NULL == np) {
printk("node lmk04828 not find \n");
return -1;
}
if(0 > of_property_read_u32_index(np, "pl-cs-addr" , 0, &addrtmp) ) {
printk("pl-cs-addr property not find \n");
}
if(0 > of_property_read_u32_index(np, "pl-cs-val" , 0, &lmk04828_data->pl_cs_val)) {
printk("pl-cs-val property not find \n");
}
lmk04828_data->pl_cs_addr = ioremap(addrtmp, 4);
printk("val= %x, addrtmp = %x, ioremap-address= %x \n", lmk04828_data->pl_cs_val,
addrtmp, lmk04828_data->pl_cs_addr);
iowrite32( lmk04828_data->pl_cs_val, lmk04828_data->pl_cs_addr);
lmk04828 = lmk04828_data;
spi_set_drvdata(spi, lmk04828_data);
//LMK04828 REGISTER INIT
lmk04828_reg_init();
return 0;
}
static int lmk04828_spi_remove(struct spi_device *spi)
{
struct lmk04828_t *lmk04828_data = spi_get_drvdata(spi);
//登出misc裝置
misc_deregister(&lmk04828_data->misc_dev);
//釋放
kfree(lmk04828_data);
return 0;
}
static const struct of_device_id lmk04828_dt_ids[] = {
{ .compatible = "lmk04828" },
{},
};
static const struct spi_device_id lmk04828_spi_id[] = {
{"lmk04828"},
{}
};
MODULE_DEVICE_TABLE(spi, lmk04828_spi_id);
static struct spi_driver lmk04828_spi_driver = {
.driver = {
.name = "lmk04828",
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(lmk04828_dt_ids),
},
.probe = lmk04828_spi_probe,
.remove = lmk04828_spi_remove,
.id_table = lmk04828_spi_id,
};
module_spi_driver(lmk04828_spi_driver);
MODULE_LICENSE("GPL");
MODULE_ALIAS("spi:04828");
相關推薦
SPI裝置端驅動編寫----基於linux4.9 driver核心層
【前序】 linux下寫驅動是站在巨人的肩膀上做開發,不用完全從頭做起,甚至你不需要懂SPI時序,照樣能寫出可用的驅動,原因是:控制器驅動一般晶片商早已寫好(linux4.9中針對xilinx zynqmp系列cpu是 drivers/spi/spi-cade
Linux下SPI和IIC驅動免在裝置樹上新增裝置資訊的編寫方法
編寫i2c或spi驅動時,一般需要往裝置樹上(或者板級檔案)新增節點資訊,這裡提供一種直接在驅動中新增裝置資訊的方法,使驅動更方便移植。 i2c的驅動模板如下 #include <linux/module.h> #include <linux
基於樹莓派Raspberry: 字元裝置核心驅動程式框架編寫
之前寫了一篇移植2.4寸TFT驅動到樹莓派的文章,那篇博文中的驅動程式碼是國外大牛寫的,看了一下,還是有很多地方沒理解,是得好好再學習一下核心驅動的編寫,這裡就從字元裝置驅動開始,採用最簡單的LED驅動來建立核心驅動移植的驅動框架. 個人原創,
i.mx6ul linux驅動開發—基於Device tree機制的驅動編寫
前言 Device Tree是一種用來描述硬體的資料結構,類似板級描述語言,起源於OpenFirmware(OF)。在目前廣泛使用的Linux kernel 2.6.x版本中,對於不同平臺、不同硬體,往往存在著大量的不同的、移植性差的板級描述程式碼,以達到對這些不同平臺和不同硬體特殊適配的需求
x4412 linux4.9.123的lcd驅動移植
本文分享一下如何移植x4412的lcd驅動程式。x4412預設使用的液晶屏型號VS070CXN,解析度: 1024X600。根據4412手冊, LCD 介面支援三種介面, RGB-interface indirect-i80 interface and YUV interfa
Linux I2C裝置驅動編寫(一)
在Linux驅動中I2C系統中主要包含以下幾個成員: I2C adapter 即I2C介面卡 I2C driver 某個I2C裝置的裝置驅動,可以以driver理解。 I2C client 某個I2C裝置的裝置宣告,可以以device理解。 I2C adapter 是
Linux系統I2C裝置驅動編寫方法
硬體平臺:飛思卡爾IMX6 核心版本:kernel3.0.35 Linux的I2C子系統分為三層,I2C核心層,I2C匯流排驅動層和I2C裝置驅動層。I2C核心層由核心開發者提供,I2C匯流排驅動層有晶片廠商提供,而I2C裝置驅動層由於裝置的差異性,就只能是具體的開發需求
利用Warensoft Stock Service編寫高頻交易軟體--客戶端驅動介面說明
Warensoft Stock Service Api客戶端介面說明 Warensoft Stock Service Api Client Reference 本專案客戶端驅動原始碼已經發布到GitHub上,地址如下: https://github.com/warensoft/s
第一課:裝置樹的引入與體驗(基於linux4.19核心版本)
本套視訊面向如下三類學員: 有Linux驅動開發基礎的人, 可以挑感興趣的章節觀看; 沒有Linux驅動開發基礎但是願意學習的人,請按順序全部觀看,我會以比較簡單的LED驅動為例講解; 完全沒有Linux驅動知識,又不想深入學習的人, 比如應用開發人員,不得
65 linux spi裝置驅動之spi LCD屏驅動
SPI的控制器驅動由平臺裝置與平臺驅動來實現. 驅動後用spi_master物件來描述.在裝置驅動中就可以通過函式spi_write, spi_read, spi_w8r16, spi_w8r8等函式來呼叫控制器. "include/linux/spi/s
68 linux framebuffer裝置驅動之spi lcd屏驅動
前面驅動的spi lcd僅僅是刷了一下圖而已, 如果要讓QT圖形程式在此lcd上顯示的話,還需要實現標準的framebuffer裝置驅動才可以. 實現一個fb裝置驅動好, QT程式就可以在視訊記憶體裡顯示出來。 只需要在裝置驅動把視訊記憶體的資料通過spi控制
基於Device tree機制的驅動編寫
前言 Device Tree是一種用來描述硬體的資料結構,類似板級描述語言,起源於OpenFirmware(OF)。在目前廣泛使用的Linux kernel 2.6.x版本中,對於不同平臺、不同硬體,往往存在著大量的不同的、移植性差的板級描述程式碼,以達到對這些不同平臺和不同硬體特殊適配的需求。但是
linux spi裝置驅動中probe函式何時被呼叫
這兩天被裝置檔案快搞瘋了,也怪自己學東西一知半解吧,弄了幾天總算能把設備註冊理清楚一點點了。就以spi子裝置的註冊為例總結一下,免得自己忘記。 首先以註冊一個spidev的裝置為例: static struct spi_board_info imx5_spi_printe
i2c 與 spi 裝置在新版核心中不採用DTS裝置樹形式 在驅動新增裝置資訊(board_info)的方法
本文唯一地址:http://blog.csdn.net/dearsq/article/details/51953610 歡迎轉載,轉載請著名,謝謝~ /* 廢話:在展訊平臺移植 spi 裝置的時候發現完成 dts 和 driver中的 of_match_
第一課:linux裝置樹的引入與體驗(基於linux4.19核心版本)
轉載請註明原文地址:http://wiki.100ask.org/Linux_devicetree 本套視訊面向如下三類學員: 有Linux驅動開發基礎的人, 可以挑感興趣的章節觀看; 沒有Linux驅動開發基礎但是願意學習的人,請按順序全部觀看,我會
【 專欄 】- 手把手教你從零實現Linux裝置驅動程式(基於友善之臂4412開發板)
手把手教你從零實現Linux裝置驅動程式(基於友善之臂4412開發板) ARM-tiny4412這款CPU是基於ARMv7架構的晶片,目前在網上開發現成資源較少,為了彌補這一缺陷,本人決定將我所學所用的這塊晶片的開發技巧和方法共享
字元裝置驅動編寫流程以及大概框架
Linux裝置驅動: Linux裝置驅動分為以下三類: (1)字元裝置:鍵盤,印表機 (2)塊裝置:硬碟,NAND (3)網路裝置:網絡卡 對於字元裝置是最基本,最常見的裝置: 對字元裝置的驅動主要完成以下動作: 1、定義一個結構體static struct file_o
基於stm32f429的uclinux-W5500網路裝置核心驅動
之前那篇寫w5500驅動只是單純的應用程式驅動,雖然可以實現一定的目的,但是沒有充分利用到linux的核心,在一些應用場合就顯得不合時宜,於是就進行w5500網路裝置核心驅動的學習,幸運的是w5500網路裝置驅動的檔案是在4.8版本的linux核心
Linux驅動編寫(塊裝置驅動程式碼)
【 宣告:版權所有,歡迎轉載,請勿用於商業用途。 聯絡信箱:feixiaoxing @163.com】 按照ldd的說法,linux的裝置驅動包括了char,block,net三種裝置。char裝置是比較簡單的,只要分配了major、minor號,就可以進行讀寫處理了
嵌入式Linux驅動初探 虛擬串列埠裝置驅動編寫
文章目錄 1.說明 所謂虛擬串列埠裝置意為這個串列埠是虛擬的,不能用來實現與下位機的串列埠收發。但是他可以將從使用者那兒收到的資料,原封不動的回傳給使用者。相當於一個迴環。 這一功能的實現主要是在驅動中實現一個FIFO。驅動接收到使用者資料後,先將之放入FIFO