Commit da50d57a authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab Committed by David S. Miller

docs: networking: convert caif files to ReST

There are two text files for caif, plus one already converted
file.

Convert the two remaining ones to ReST, create a new index.rst
file for CAIF, adding it to the main networking documentation
index.
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 790ab249
:orphan:
.. SPDX-License-Identifier: GPL-2.0 .. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt> .. include:: <isonum.txt>
......
.. SPDX-License-Identifier: GPL-2.0
CAIF
====
Contents:
.. toctree::
:maxdepth: 2
linux_caif
caif
spi_porting
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
==========
Linux CAIF Linux CAIF
=========== ==========
copyright (C) ST-Ericsson AB 2010
Author: Sjur Brendeland/ sjur.brandeland@stericsson.com Copyright |copy| ST-Ericsson AB 2010
License terms: GNU General Public License (GPL) version 2
:Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
:License terms: GNU General Public License (GPL) version 2
Introduction Introduction
------------ ============
CAIF is a MUX protocol used by ST-Ericsson cellular modems for CAIF is a MUX protocol used by ST-Ericsson cellular modems for
communication between Modem and host. The host processes can open virtual AT communication between Modem and host. The host processes can open virtual AT
channels, initiate GPRS Data connections, Video channels and Utility Channels. channels, initiate GPRS Data connections, Video channels and Utility Channels.
...@@ -16,13 +23,16 @@ ST-Ericsson modems support a number of transports between modem ...@@ -16,13 +23,16 @@ ST-Ericsson modems support a number of transports between modem
and host. Currently, UART and Loopback are available for Linux. and host. Currently, UART and Loopback are available for Linux.
Architecture: Architecture
------------ ============
The implementation of CAIF is divided into: The implementation of CAIF is divided into:
* CAIF Socket Layer and GPRS IP Interface. * CAIF Socket Layer and GPRS IP Interface.
* CAIF Core Protocol Implementation * CAIF Core Protocol Implementation
* CAIF Link Layer, implemented as NET devices. * CAIF Link Layer, implemented as NET devices.
::
RTNL RTNL
! !
...@@ -46,12 +56,12 @@ The implementation of CAIF is divided into: ...@@ -46,12 +56,12 @@ The implementation of CAIF is divided into:
I M P L E M E N T A T I O N Implementation
=========================== ==============
CAIF Core Protocol Layer CAIF Core Protocol Layer
========================================= ------------------------
CAIF Core layer implements the CAIF protocol as defined by ST-Ericsson. CAIF Core layer implements the CAIF protocol as defined by ST-Ericsson.
It implements the CAIF protocol stack in a layered approach, where It implements the CAIF protocol stack in a layered approach, where
...@@ -59,8 +69,11 @@ each layer described in the specification is implemented as a separate layer. ...@@ -59,8 +69,11 @@ each layer described in the specification is implemented as a separate layer.
The architecture is inspired by the design patterns "Protocol Layer" and The architecture is inspired by the design patterns "Protocol Layer" and
"Protocol Packet". "Protocol Packet".
== CAIF structure == CAIF structure
^^^^^^^^^^^^^^
The Core CAIF implementation contains: The Core CAIF implementation contains:
- Simple implementation of CAIF. - Simple implementation of CAIF.
- Layered architecture (a la Streams), each layer in the CAIF - Layered architecture (a la Streams), each layer in the CAIF
specification is implemented in a separate c-file. specification is implemented in a separate c-file.
...@@ -73,7 +86,8 @@ The Core CAIF implementation contains: ...@@ -73,7 +86,8 @@ The Core CAIF implementation contains:
to the called function (except for framing layers' receive function) to the called function (except for framing layers' receive function)
Layered Architecture Layered Architecture
-------------------- ====================
The CAIF protocol can be divided into two parts: Support functions and Protocol The CAIF protocol can be divided into two parts: Support functions and Protocol
Implementation. The support functions include: Implementation. The support functions include:
...@@ -112,7 +126,7 @@ The CAIF Protocol implementation contains: ...@@ -112,7 +126,7 @@ The CAIF Protocol implementation contains:
- CFSERL CAIF Serial layer. Handles concatenation/split of frames - CFSERL CAIF Serial layer. Handles concatenation/split of frames
into CAIF Frames with correct length. into CAIF Frames with correct length.
::
+---------+ +---------+
| Config | | Config |
...@@ -143,18 +157,24 @@ The CAIF Protocol implementation contains: ...@@ -143,18 +157,24 @@ The CAIF Protocol implementation contains:
In this layered approach the following "rules" apply. In this layered approach the following "rules" apply.
- All layers embed the same structure "struct cflayer" - All layers embed the same structure "struct cflayer"
- A layer does not depend on any other layer's private data. - A layer does not depend on any other layer's private data.
- Layers are stacked by setting the pointers - Layers are stacked by setting the pointers::
layer->up , layer->dn layer->up , layer->dn
- In order to send data upwards, each layer should do
- In order to send data upwards, each layer should do::
layer->up->receive(layer->up, packet); layer->up->receive(layer->up, packet);
- In order to send data downwards, each layer should do
- In order to send data downwards, each layer should do::
layer->dn->transmit(layer->dn, packet); layer->dn->transmit(layer->dn, packet);
CAIF Socket and IP interface CAIF Socket and IP interface
=========================== ============================
The IP interface and CAIF socket API are implemented on top of the The IP interface and CAIF socket API are implemented on top of the
CAIF Core protocol. The IP Interface and CAIF socket have an instance of CAIF Core protocol. The IP Interface and CAIF socket have an instance of
......
- CAIF SPI porting - .. SPDX-License-Identifier: GPL-2.0
- CAIF SPI basics: ================
CAIF SPI porting
================
CAIF SPI basics
===============
Running CAIF over SPI needs some extra setup, owing to the nature of SPI. Running CAIF over SPI needs some extra setup, owing to the nature of SPI.
Two extra GPIOs have been added in order to negotiate the transfers Two extra GPIOs have been added in order to negotiate the transfers
between the master and the slave. The minimum requirement for running between the master and the slave. The minimum requirement for running
CAIF over SPI is a SPI slave chip and two GPIOs (more details below). CAIF over SPI is a SPI slave chip and two GPIOs (more details below).
Please note that running as a slave implies that you need to keep up Please note that running as a slave implies that you need to keep up
with the master clock. An overrun or underrun event is fatal. with the master clock. An overrun or underrun event is fatal.
- CAIF SPI framework: CAIF SPI framework
==================
To make porting as easy as possible, the CAIF SPI has been divided in To make porting as easy as possible, the CAIF SPI has been divided in
two parts. The first part (called the interface part) deals with all two parts. The first part (called the interface part) deals with all
...@@ -27,7 +33,9 @@ the physical hardware, both with regard to SPI and to GPIOs. ...@@ -27,7 +33,9 @@ the physical hardware, both with regard to SPI and to GPIOs.
need to implement the following need to implement the following
functions: functions:
int (*init_xfer) (struct cfspi_xfer * xfer, struct cfspi_dev *dev): ::
int (*init_xfer) (struct cfspi_xfer * xfer, struct cfspi_dev *dev):
This function is called by the CAIF SPI interface to give This function is called by the CAIF SPI interface to give
you a chance to set up your hardware to be ready to receive you a chance to set up your hardware to be ready to receive
...@@ -36,7 +44,9 @@ the physical hardware, both with regard to SPI and to GPIOs. ...@@ -36,7 +44,9 @@ the physical hardware, both with regard to SPI and to GPIOs.
of the transfer in both directions.The dev parameter can be used of the transfer in both directions.The dev parameter can be used
to map to different CAIF SPI slave devices. to map to different CAIF SPI slave devices.
void (*sig_xfer) (bool xfer, struct cfspi_dev *dev): ::
void (*sig_xfer) (bool xfer, struct cfspi_dev *dev):
This function is called by the CAIF SPI interface when the output This function is called by the CAIF SPI interface when the output
(SPI_INT) GPIO needs to change state. The boolean value of the xfer (SPI_INT) GPIO needs to change state. The boolean value of the xfer
...@@ -46,7 +56,9 @@ the physical hardware, both with regard to SPI and to GPIOs. ...@@ -46,7 +56,9 @@ the physical hardware, both with regard to SPI and to GPIOs.
- Functionality provided by the CAIF SPI interface: - Functionality provided by the CAIF SPI interface:
void (*ss_cb) (bool assert, struct cfspi_ifc *ifc); ::
void (*ss_cb) (bool assert, struct cfspi_ifc *ifc);
This function is called by the CAIF SPI slave device in order to This function is called by the CAIF SPI slave device in order to
signal a change of state of the input GPIO (SS) to the interface. signal a change of state of the input GPIO (SS) to the interface.
...@@ -55,7 +67,9 @@ the physical hardware, both with regard to SPI and to GPIOs. ...@@ -55,7 +67,9 @@ the physical hardware, both with regard to SPI and to GPIOs.
not to introduce latency). The ifc parameter should be the pointer not to introduce latency). The ifc parameter should be the pointer
returned from the platform probe function in the SPI device structure. returned from the platform probe function in the SPI device structure.
void (*xfer_done_cb) (struct cfspi_ifc *ifc); ::
void (*xfer_done_cb) (struct cfspi_ifc *ifc);
This function is called by the CAIF SPI slave device in order to This function is called by the CAIF SPI slave device in order to
report that a transfer is completed. This function should only be report that a transfer is completed. This function should only be
...@@ -68,17 +82,24 @@ the physical hardware, both with regard to SPI and to GPIOs. ...@@ -68,17 +82,24 @@ the physical hardware, both with regard to SPI and to GPIOs.
- Filling in the SPI slave device structure: - Filling in the SPI slave device structure:
Connect the necessary callback functions. Connect the necessary callback functions.
Indicate clock speed (used to calculate toggle delays).
Chose a suitable name (helps debugging if you use several CAIF Indicate clock speed (used to calculate toggle delays).
SPI slave devices).
Assign your private data (can be used to map to your structure). Chose a suitable name (helps debugging if you use several CAIF
SPI slave devices).
Assign your private data (can be used to map to your
structure).
- Filling in the SPI slave platform device structure: - Filling in the SPI slave platform device structure:
Add name of driver to connect to ("cfspi_sspi").
Assign the SPI slave device structure as platform data.
- Padding: Add name of driver to connect to ("cfspi_sspi").
Assign the SPI slave device structure as platform data.
Padding
=======
In order to optimize throughput, a number of SPI padding options are provided. In order to optimize throughput, a number of SPI padding options are provided.
Padding can be enabled independently for uplink and downlink transfers. Padding can be enabled independently for uplink and downlink transfers.
...@@ -87,122 +108,122 @@ The padding needs to be correctly configured on both sides of the link. ...@@ -87,122 +108,122 @@ The padding needs to be correctly configured on both sides of the link.
The padding can be changed via module parameters in cfspi_sspi.c or via The padding can be changed via module parameters in cfspi_sspi.c or via
the sysfs directory of the cfspi_sspi driver (before device registration). the sysfs directory of the cfspi_sspi driver (before device registration).
- CAIF SPI device template: - CAIF SPI device template::
/* /*
* Copyright (C) ST-Ericsson AB 2010 * Copyright (C) ST-Ericsson AB 2010
* Author: Daniel Martensson / Daniel.Martensson@stericsson.com * Author: Daniel Martensson / Daniel.Martensson@stericsson.com
* License terms: GNU General Public License (GPL), version 2. * License terms: GNU General Public License (GPL), version 2.
* *
*/ */
#include <linux/init.h> #include <linux/init.h>
#include <linux/module.h> #include <linux/module.h>
#include <linux/device.h> #include <linux/device.h>
#include <linux/wait.h> #include <linux/wait.h>
#include <linux/interrupt.h> #include <linux/interrupt.h>
#include <linux/dma-mapping.h> #include <linux/dma-mapping.h>
#include <net/caif/caif_spi.h> #include <net/caif/caif_spi.h>
MODULE_LICENSE("GPL"); MODULE_LICENSE("GPL");
struct sspi_struct { struct sspi_struct {
struct cfspi_dev sdev; struct cfspi_dev sdev;
struct cfspi_xfer *xfer; struct cfspi_xfer *xfer;
}; };
static struct sspi_struct slave; static struct sspi_struct slave;
static struct platform_device slave_device; static struct platform_device slave_device;
static irqreturn_t sspi_irq(int irq, void *arg) static irqreturn_t sspi_irq(int irq, void *arg)
{ {
/* You only need to trigger on an edge to the active state of the /* You only need to trigger on an edge to the active state of the
* SS signal. Once a edge is detected, the ss_cb() function should be * SS signal. Once a edge is detected, the ss_cb() function should be
* called with the parameter assert set to true. It is OK * called with the parameter assert set to true. It is OK
* (and even advised) to call the ss_cb() function in IRQ context in * (and even advised) to call the ss_cb() function in IRQ context in
* order not to add any delay. */ * order not to add any delay. */
return IRQ_HANDLED; return IRQ_HANDLED;
} }
static void sspi_complete(void *context) static void sspi_complete(void *context)
{ {
/* Normally the DMA or the SPI framework will call you back /* Normally the DMA or the SPI framework will call you back
* in something similar to this. The only thing you need to * in something similar to this. The only thing you need to
* do is to call the xfer_done_cb() function, providing the pointer * do is to call the xfer_done_cb() function, providing the pointer
* to the CAIF SPI interface. It is OK to call this function * to the CAIF SPI interface. It is OK to call this function
* from IRQ context. */ * from IRQ context. */
} }
static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev) static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev)
{ {
/* Store transfer info. For a normal implementation you should /* Store transfer info. For a normal implementation you should
* set up your DMA here and make sure that you are ready to * set up your DMA here and make sure that you are ready to
* receive the data from the master SPI. */ * receive the data from the master SPI. */
struct sspi_struct *sspi = (struct sspi_struct *)dev->priv; struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
sspi->xfer = xfer; sspi->xfer = xfer;
return 0; return 0;
} }
void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev) void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
{ {
/* If xfer is true then you should assert the SPI_INT to indicate to /* If xfer is true then you should assert the SPI_INT to indicate to
* the master that you are ready to receive the data from the master * the master that you are ready to receive the data from the master
* SPI. If xfer is false then you should de-assert SPI_INT to indicate * SPI. If xfer is false then you should de-assert SPI_INT to indicate
* that the transfer is done. * that the transfer is done.
*/ */
struct sspi_struct *sspi = (struct sspi_struct *)dev->priv; struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
} }
static void sspi_release(struct device *dev) static void sspi_release(struct device *dev)
{ {
/* /*
* Here you should release your SPI device resources. * Here you should release your SPI device resources.
*/ */
} }
static int __init sspi_init(void) static int __init sspi_init(void)
{ {
/* Here you should initialize your SPI device by providing the /* Here you should initialize your SPI device by providing the
* necessary functions, clock speed, name and private data. Once * necessary functions, clock speed, name and private data. Once
* done, you can register your device with the * done, you can register your device with the
* platform_device_register() function. This function will return * platform_device_register() function. This function will return
* with the CAIF SPI interface initialized. This is probably also * with the CAIF SPI interface initialized. This is probably also
* the place where you should set up your GPIOs, interrupts and SPI * the place where you should set up your GPIOs, interrupts and SPI
* resources. */ * resources. */
int res = 0; int res = 0;
/* Initialize slave device. */ /* Initialize slave device. */
slave.sdev.init_xfer = sspi_init_xfer; slave.sdev.init_xfer = sspi_init_xfer;
slave.sdev.sig_xfer = sspi_sig_xfer; slave.sdev.sig_xfer = sspi_sig_xfer;
slave.sdev.clk_mhz = 13; slave.sdev.clk_mhz = 13;
slave.sdev.priv = &slave; slave.sdev.priv = &slave;
slave.sdev.name = "spi_sspi"; slave.sdev.name = "spi_sspi";
slave_device.dev.release = sspi_release; slave_device.dev.release = sspi_release;
/* Initialize platform device. */ /* Initialize platform device. */
slave_device.name = "cfspi_sspi"; slave_device.name = "cfspi_sspi";
slave_device.dev.platform_data = &slave.sdev; slave_device.dev.platform_data = &slave.sdev;
/* Register platform device. */ /* Register platform device. */
res = platform_device_register(&slave_device); res = platform_device_register(&slave_device);
if (res) { if (res) {
printk(KERN_WARNING "sspi_init: failed to register dev.\n"); printk(KERN_WARNING "sspi_init: failed to register dev.\n");
return -ENODEV; return -ENODEV;
} }
return res; return res;
} }
static void __exit sspi_exit(void) static void __exit sspi_exit(void)
{ {
platform_device_del(&slave_device); platform_device_del(&slave_device);
} }
module_init(sspi_init); module_init(sspi_init);
module_exit(sspi_exit); module_exit(sspi_exit);
...@@ -15,6 +15,7 @@ Contents: ...@@ -15,6 +15,7 @@ Contents:
device_drivers/index device_drivers/index
dsa/index dsa/index
devlink/index devlink/index
caif/index
ethtool-netlink ethtool-netlink
ieee802154 ieee802154
j1939 j1939
......
...@@ -28,7 +28,7 @@ config CAIF_SPI_SLAVE ...@@ -28,7 +28,7 @@ config CAIF_SPI_SLAVE
The CAIF Link layer SPI Protocol driver for Slave SPI interface. The CAIF Link layer SPI Protocol driver for Slave SPI interface.
This driver implements a platform driver to accommodate for a This driver implements a platform driver to accommodate for a
platform specific SPI device. A sample CAIF SPI Platform device is platform specific SPI device. A sample CAIF SPI Platform device is
provided in <file:Documentation/networking/caif/spi_porting.txt>. provided in <file:Documentation/networking/caif/spi_porting.rst>.
config CAIF_SPI_SYNC config CAIF_SPI_SYNC
bool "Next command and length in start of frame" bool "Next command and length in start of frame"
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment