I'm working on a Linux kernel driver for the Texas Instruments tps92518-Q1 and tps92518HV-Q1. This device uses 16-bit SPI Frames (7-bit control, 9-bit data).
Command frame
1-bit command bit
5-bit Address
1-bit parity
9-bit data
Read response frame
1-bit SPI error
2-bit reserved
1-bit power cycle
1-bit LED2 BOOTUV ERROR
1-bit LED1 BOOTUV ERROR
1-bit THERMAL WARNING
9-bit data
Write response frame
1-bit SPI error
1-bit command
5-bit Address
9-bit data
The main problem here is the requirement for a parity bit on any write operation. So I need to be able to calculate the parity bit for any command frame
PARITY = XNOR(CMD, A4..A0, D8..D0)
I can define a regmap, e.g.
static struct regmap_config tps92518_regmap_config = {
.reg_bits = 6,
.pad_bits = 1, // parity bit
.val_bits = 9,
.max_register = tps92518_RESET,
};
From regmap.h it looks like I might be able to set ->reg_read() and ->reg_write() callbacks, but I don't know what I would actually have get those functions to do.
Is there another method of preprocessing any request/response?
The Linux kernel SPI documentation mentions the protocol drivers but can I see where I could specify a protocol format?
Related
On the device file tree listed here we can see an UART device:
uarta: serial#70006000 {
compatible = "nvidia,tegra210-uart", "nvidia,tegra20-uart";
reg = <0x0 0x70006000 0x0 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_UARTA>;
clock-names = "serial";
resets = <&tegra_car 6>;
reset-names = "serial";
dmas = <&apbdma 8>, <&apbdma 8>;
dma-names = "rx", "tx";
status = "disabled";
};
The tegra210-uart driver is declared here
Why does uarta needs the interrupts section? Does it produce or receive interrupts? My guess is that it produces software interrupts: when it writes something to the serial, it triggers an interrupt. But why must this interrupt be listed in the device tree? And where is the code for this interrupt?
The second line of the above code block (reg = <0x0 0x70006000 0x0 0x40>) refers to an uart address. What is this address exactly? If I understand correctly, this is the address for a 8250_UART device but I'd like to know which pieces of this address do what, and how the kernel talks with this chip.
Driver documentation is available at https://www.kernel.org/doc/Documentation/devicetree/bindings/serial/nvidia%2Ctegra20-hsuart.txt
According to this forum https://forums.developer.nvidia.com/t/enabling-interrupts-for-uart-xavier-agx/166269
interrupts are used to prevent regular polling on UART.
Registering handler on this interrupt allows to only run code when effective data are received and available in DMA buffer, or when the complete outgoing message provided in DMA has been sent. Such a DMA usage example is available at: UART Tx mode with DMA enabled
Memory address 0x70006000 is the base location for UARTA controller registers (there are 4 UART [A,B,C,D] in Tegra 2) where to write commands or read status. These documents may help to understand:
https://docs.freebsd.org/en/articles/serial-uart/index.html
https://www.lammertbies.nl/comm/info/serial-uart
For instance, the Scratch Register (SCR +0x07) can be used to write and read back any byte as a way to test UART is present and controller operates as expected.
I recommend you to download reference documentation, chapter 22 for UART, available from https://developer.nvidia.com/embedded/tegra-2-reference
I'm developing a RF modem based on a new protocol, which has a feature of streaming 96 Bytes in one frame - but they are sent on and on, before communication ends. I plan using two 96 Bytes buffers in STM32 - in next lines I will explain why.
I want to send first 96 Byte frames by the USB-CDC to STM32 - then external modem chip will generate a "9600bps" clock and STM will have to write Payload bits by bits on specified output pin(at the trailing edge of the each clock pulse).
When STM32 will notice that it had sent a half of 96 Byte frame - that it sent to PC notification to send more data - PC will refill second 96 Byte buffer by USB-CDC immediately. When STM32 will end sending first buffer - immediately starts sending second buffer content. When it will send half of second buffer - as previous will ask PC for another 96Byte frame.
And that way all the time, before PC will sent command to stop tx.
This transfer mode - a serial, with using a "trigger clock".
Is this possible using DMA, and how could I set it?
I want to use DMA to have ability to use USB while already streaming data to the radio modem chip. Is this the right approach?
I'm working in project building an opensource radiocommunication system project with both packet and stream capatibilities & digital voice. I'm designing and electronics for PC radiomodem. Project is called M17 and is maintained by Wojtek SP5WWP.
Re. general architecture. Serial communication over USB ACM does not have to use buffer of the same size and be synchronized with the downstream communication over SPI. You could use buffers as big as practically possible so PC can send data in advance. This will reduce the chance of buffer underflow if PC does not provide data fast enough. Use a circular buffer and fill it when a packet arrives from USB.
DMA is the right approach. Although people often say that DMA is only necessary for high bandwidth operations, it may be actually easier to work with DMA than handling interrupts per every byte, even when you only handle 9600 bits per second.
DMA controller in STM32F3 has a Half-Transfer Complete (HTIF in DMA_ISR) bit that you can poll or make it generate and interrupt. In conjunction with the Transfer Complete status (TCIF) and the Circular bit (CIRC in DMA_CCR) you can organize a double-buffered data pipe so that transfers can overlap with whatever else the MCU is doing. The application will reload the first half of the DMA buffer on the HTIF event. When the TCIF event happens, it reloads the second half. It has to be done quickly, before the other half is also completed. However, you need a double buffered pipeline only when you need to constantly stream data, i.e. overall amount is larger than can the size of the DMA buffer.
Stopping a circular DMA may be tricky. I suppose both the STM32 and external chip know how many bytes to send. In that case, after this amount is received, disable the DMA.
It seems you need a slave SPI in STM32 as the external chip generates SPI clock.
DMA is not difficult to set up, however, it needs multiple things to work properly. I assume register-level programming, if you use some kind of framework, you'll need to find out how it implements these features. Enable clocks for SPI, GPIO port for SPI pins, and DMA, configure the pins as AF. Find the right DMA channel for the SPI peripheral. In case of SPI DMA you usually need two channels: TX and RX, but with the slave SPI, you may get away with one. Configure SPI, pay attention to clock polarity and phase, and set it to generate a DMA request for each TX and/or RX. Set the DMA CPAR channel register pointing to the SPI DR register in channel(s) and program all other DMA channel registers appropriately. Enable the DMA channel(s). Enable SPI in slave mode. When the SPI master clocks data on the MOSI/SCK pins, the DMA controller will put them in memory. When the buffer is half-full and full-full, the channel will set the HTIF and TCIF bits and generate and interrupt, if you told it to. Use these events to implement flow control.
I want to create a RAM chip in verilog to learn how Verilog, modern chips like RAM and EEPROM allow reading and writing to the chip over a single address port and a single data port.(Data port being the input and output port)
I want to do the same thing in Verilog, and I think I need the inout type, but I don't know how it works.
I google it, but all RAM examples I can find have a separate data write and data read port.
Since the inout type requires both sides to be connected to a wire, I need to connect one wire from one side to a reg chosen by the address.(so no assign).But I don't know how to do that.
This is what I tried and doesn't work:
wire [7:0] a;
wire rw;// 0 if read, 1 if write
reg [7:0] mem [16];
initial begin
if (rw == 1) begin
#1 a = mem[0];// 0 would be the address wire, but excluding it for clarity
end
if (rw == 0) begin
#1 mem[0] = a;// 0 would be the address wire, but excluding it for clarity
end
end
Can anyone help?
Thanks
all RAM examples I can find have a separate data write and data read port.
The reason is a combination of two facts:
A true bi-directional data bus would requires tri-state drivers.
FPGA or ASIC chips no longer have on-chip tri-state drivers.
The only place where a bi-directional data is possible is at I/O where you have tri-state pads.
Thus internally everybody will use the two data buses as any real memory will have at its core a separate read-data and write-data bus. Then at the edge (at the pads) they will switch to bi-directional mode.
To write your own Verilog bi-directional bus you should use tri-state signal assignments. Something along the line of:
inout[7:0] data_bus,
// This assignment is inside the memory model:
// Driving the read data out of the memory device
assign data_bus = mem_read ? mem_read_data : 8'hzz;
// This assignment is outside the memory model
// Driving the write data into the memory device
assign data_bus = mem_read ? 8'hzz : external_driver;
As I understand the term "word length" (spi_bits_per_word) in spi, defines the CS (chip select) active time.
It therefore seems that linux driver will function correctly when dealing with simple spi protocols which keeps word size constant.
But, How can we deal with spi protocols which use different spi size as part of protocol.
for example cs need to be active for sending spi word - 9 bits, and then reading spi - 8 bits or 24 bits (the length of the register read is different each time, depends on register)
How can we implement that using spi_write_then_read ?
Do we need to set bits_per_word size for the sending and then another bits_per_word for the receiving ?
Regards,
Ran
"word length" means number of bits you can send in one transaction. It doesn't defines the CS (chip select) active time. You can keep it active for whatever time you want(least is for word-length).
SPI has got some format. You cannot randomly read-write whatever number of bits you want.Most of SPI supports 4-bit, 8-bit, 16-bit and 32-bit mode. If the given mode doesn't satisfy your requirement then you need to break your requirement. For eg:- To read 24-bit data, we need to use 8-bit word-length transfer for 3 times.
Generally SPI is fullduplex means it will read at same time it will write.
I'm going to launch a Linux on my development board, and i need a dts file (device tree file) to describe the whole hardware. But I only know very little about the syntax of this file which is not enough to run Linux properly on the board.
What i know now are only how to describe a unit's interrupt number, frequency, address, parent-unit and its compatible driver type (as described below):
ps7_scuwdt_0: ps7-scuwdt#f8f00620 {
compatible = "xlnx,ps7-scuwdt-1.00.a";
device_type = "watchdog";
interrupt-parent = <&ps7_scugic_0>;
interrupts = < 1 14 769 >;
reg = < 0xf8f00620 0xe0 >;
} ;
Other advanced usage or grammar is unfamiliar to me.
Take a look at the dts of the board which most closely resembles your dev-board. Use that as a reference and make changes to the dts according to the differences between the reference board and your dev-board.
Also checkout the following :
- Device-tree Documentation project at eLinux (has a vast collection of links to start reading).
- Series of articles on the basics of device tree.
- Walkthrough of migrating to device-tree.
Minimal reg + interrupt example with QEMU virtual device
Our example will add the following device tree node to the versatilepb device tree which QEMU will use due to -M versatilepb:
lkmc_platform_device#101e9000 {
compatible = "lkmc_platform_device";
reg = <0x101e9000 0x1000>;
interrupts = <18>;
interrupt-controller;
#interrupt-cells = <2>;
clocks = <&pclk>;
clock-names = "apb_pclk";
lkmc-asdf = <0x12345678>;
};
Then, by using a Linux kernel module to interact with the device, we will test the following DTS features:
registers addresses
IRQs
read custom properties from the driver
These are the main components of the example:
Linux versatile .dts patch on Linux fork
reg and interrupt match numbers hard-coded in the QEMU versatile machine (which represents the SoC)
compatible matches the platform_driver.name in the kernel module, and informs the kernel which module will handle this device
we also pass a custom property to the driver: lkmc-asdf = <0x12345678>;, which is read with of_property_read_u32
the device tree is passed to QEMU's firmware with the -dtb argument
QEMU fork:
device that reads a register and generates interrupts
insert device into -M versatilepb
kernel module Writes to memory on probe to test things out, which also generates an IRQ.
Device trees have many more features that we haven't covered, but this example should get you started, and easily allow you to play around with any new features that come up.
Further resources:
indispensable elinux tutorial: http://elinux.org/Device_Tree_Usage
play around with dtc for purely syntaxical questions. E.g., it shows how nodes are simply merged by path: https://unix.stackexchange.com/a/375923/32558
https://unix.stackexchange.com/questions/118683/what-is-a-device-tree-and-a-device-tree-blob
Lets take a example and I will explain each one of them as below
auart0: serial#8006a000 {
compatible = "fsl,imx28-auart", "fsl,imx23-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112>;
dmas = <&dma_apbx 8>, <&dma_apbx 9>;
dma-names = "rx", "tx";
};
Required properties:
- compatible : Should be "fsl,-auart". The supported SoCs include
imx23 and imx28.
- reg : Address and length of the register set for the device
- interrupts : Should contain the auart interrupt numbers
- dmas: DMA specifier, consisting of a phandle to DMA controller node
and AUART DMA channel ID.
- dma-names: "rx" for RX channel, "tx" for TX channel.
Note: Each auart port should have an alias correctly numbered in "aliases"
node.
For more advance properties, please go to this link, it is very useful
Device Tree Explanation
Hope it helps!
Complementary to the other answers:
Keep in mind, that there is also a section for devicetrees in the official kernel source under root/Documentation/devicetree(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree?h=v5.2-rc5).