Merge branch 'mauro' into docs-next
A big set of fixes and RST conversions from Mauro. He swears that this is the last RST conversion set, which is certainly cause for celebration.
This commit is contained in:
Jonathan Corbet
@@ -228,8 +228,6 @@ over management of devices from the bootloader, the usage of sync_state() is
|
||||
not restricted to that. Use it whenever it makes sense to take an action after
|
||||
all the consumers of a device have probed::
|
||||
|
||||
::
|
||||
|
||||
int (*remove) (struct device *dev);
|
||||
|
||||
remove is called to unbind a driver from a device. This may be
|
||||
|
||||
@@ -48,6 +48,7 @@ available subsections can be seen below.
|
||||
scsi
|
||||
libata
|
||||
target
|
||||
mailbox
|
||||
mtdnand
|
||||
miscellaneous
|
||||
mei/index
|
||||
|
||||
129
Documentation/driver-api/mailbox.rst
Normal file
129
Documentation/driver-api/mailbox.rst
Normal file
@@ -0,0 +1,129 @@
|
||||
============================
|
||||
The Common Mailbox Framework
|
||||
============================
|
||||
|
||||
:Author: Jassi Brar <jaswinder.singh@linaro.org>
|
||||
|
||||
This document aims to help developers write client and controller
|
||||
drivers for the API. But before we start, let us note that the
|
||||
client (especially) and controller drivers are likely going to be
|
||||
very platform specific because the remote firmware is likely to be
|
||||
proprietary and implement non-standard protocol. So even if two
|
||||
platforms employ, say, PL320 controller, the client drivers can't
|
||||
be shared across them. Even the PL320 driver might need to accommodate
|
||||
some platform specific quirks. So the API is meant mainly to avoid
|
||||
similar copies of code written for each platform. Having said that,
|
||||
nothing prevents the remote f/w to also be Linux based and use the
|
||||
same api there. However none of that helps us locally because we only
|
||||
ever deal at client's protocol level.
|
||||
|
||||
Some of the choices made during implementation are the result of this
|
||||
peculiarity of this "common" framework.
|
||||
|
||||
|
||||
|
||||
Controller Driver (See include/linux/mailbox_controller.h)
|
||||
==========================================================
|
||||
|
||||
|
||||
Allocate mbox_controller and the array of mbox_chan.
|
||||
Populate mbox_chan_ops, except peek_data() all are mandatory.
|
||||
The controller driver might know a message has been consumed
|
||||
by the remote by getting an IRQ or polling some hardware flag
|
||||
or it can never know (the client knows by way of the protocol).
|
||||
The method in order of preference is IRQ -> Poll -> None, which
|
||||
the controller driver should set via 'txdone_irq' or 'txdone_poll'
|
||||
or neither.
|
||||
|
||||
|
||||
Client Driver (See include/linux/mailbox_client.h)
|
||||
==================================================
|
||||
|
||||
|
||||
The client might want to operate in blocking mode (synchronously
|
||||
send a message through before returning) or non-blocking/async mode (submit
|
||||
a message and a callback function to the API and return immediately).
|
||||
|
||||
::
|
||||
|
||||
struct demo_client {
|
||||
struct mbox_client cl;
|
||||
struct mbox_chan *mbox;
|
||||
struct completion c;
|
||||
bool async;
|
||||
/* ... */
|
||||
};
|
||||
|
||||
/*
|
||||
* This is the handler for data received from remote. The behaviour is purely
|
||||
* dependent upon the protocol. This is just an example.
|
||||
*/
|
||||
static void message_from_remote(struct mbox_client *cl, void *mssg)
|
||||
{
|
||||
struct demo_client *dc = container_of(cl, struct demo_client, cl);
|
||||
if (dc->async) {
|
||||
if (is_an_ack(mssg)) {
|
||||
/* An ACK to our last sample sent */
|
||||
return; /* Or do something else here */
|
||||
} else { /* A new message from remote */
|
||||
queue_req(mssg);
|
||||
}
|
||||
} else {
|
||||
/* Remote f/w sends only ACK packets on this channel */
|
||||
return;
|
||||
}
|
||||
}
|
||||
|
||||
static void sample_sent(struct mbox_client *cl, void *mssg, int r)
|
||||
{
|
||||
struct demo_client *dc = container_of(cl, struct demo_client, cl);
|
||||
complete(&dc->c);
|
||||
}
|
||||
|
||||
static void client_demo(struct platform_device *pdev)
|
||||
{
|
||||
struct demo_client *dc_sync, *dc_async;
|
||||
/* The controller already knows async_pkt and sync_pkt */
|
||||
struct async_pkt ap;
|
||||
struct sync_pkt sp;
|
||||
|
||||
dc_sync = kzalloc(sizeof(*dc_sync), GFP_KERNEL);
|
||||
dc_async = kzalloc(sizeof(*dc_async), GFP_KERNEL);
|
||||
|
||||
/* Populate non-blocking mode client */
|
||||
dc_async->cl.dev = &pdev->dev;
|
||||
dc_async->cl.rx_callback = message_from_remote;
|
||||
dc_async->cl.tx_done = sample_sent;
|
||||
dc_async->cl.tx_block = false;
|
||||
dc_async->cl.tx_tout = 0; /* doesn't matter here */
|
||||
dc_async->cl.knows_txdone = false; /* depending upon protocol */
|
||||
dc_async->async = true;
|
||||
init_completion(&dc_async->c);
|
||||
|
||||
/* Populate blocking mode client */
|
||||
dc_sync->cl.dev = &pdev->dev;
|
||||
dc_sync->cl.rx_callback = message_from_remote;
|
||||
dc_sync->cl.tx_done = NULL; /* operate in blocking mode */
|
||||
dc_sync->cl.tx_block = true;
|
||||
dc_sync->cl.tx_tout = 500; /* by half a second */
|
||||
dc_sync->cl.knows_txdone = false; /* depending upon protocol */
|
||||
dc_sync->async = false;
|
||||
|
||||
/* ASync mailbox is listed second in 'mboxes' property */
|
||||
dc_async->mbox = mbox_request_channel(&dc_async->cl, 1);
|
||||
/* Populate data packet */
|
||||
/* ap.xxx = 123; etc */
|
||||
/* Send async message to remote */
|
||||
mbox_send_message(dc_async->mbox, &ap);
|
||||
|
||||
/* Sync mailbox is listed first in 'mboxes' property */
|
||||
dc_sync->mbox = mbox_request_channel(&dc_sync->cl, 0);
|
||||
/* Populate data packet */
|
||||
/* sp.abc = 123; etc */
|
||||
/* Send message to remote in blocking mode */
|
||||
mbox_send_message(dc_sync->mbox, &sp);
|
||||
/* At this point 'sp' has been sent */
|
||||
|
||||
/* Now wait for async chan to be done */
|
||||
wait_for_completion(&dc_async->c);
|
||||
}
|
||||
@@ -10,7 +10,7 @@ API overview
|
||||
|
||||
The big picture is that USB drivers can continue to ignore most DMA issues,
|
||||
though they still must provide DMA-ready buffers (see
|
||||
``Documentation/DMA-API-HOWTO.txt``). That's how they've worked through
|
||||
:doc:`/core-api/dma-api-howto`). That's how they've worked through
|
||||
the 2.4 (and earlier) kernels, or they can now be DMA-aware.
|
||||
|
||||
DMA-aware usb drivers:
|
||||
@@ -60,7 +60,7 @@ and effects like cache-trashing can impose subtle penalties.
|
||||
force a consistent memory access ordering by using memory barriers. It's
|
||||
not using a streaming DMA mapping, so it's good for small transfers on
|
||||
systems where the I/O would otherwise thrash an IOMMU mapping. (See
|
||||
``Documentation/DMA-API-HOWTO.txt`` for definitions of "coherent" and
|
||||
:doc:`/core-api/dma-api-howto` for definitions of "coherent" and
|
||||
"streaming" DMA mappings.)
|
||||
|
||||
Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
|
||||
@@ -91,7 +91,7 @@ Working with existing buffers
|
||||
Existing buffers aren't usable for DMA without first being mapped into the
|
||||
DMA address space of the device. However, most buffers passed to your
|
||||
driver can safely be used with such DMA mapping. (See the first section
|
||||
of Documentation/DMA-API-HOWTO.txt, titled "What memory is DMA-able?")
|
||||
of :doc:`/core-api/dma-api-howto`, titled "What memory is DMA-able?")
|
||||
|
||||
- When you're using scatterlists, you can map everything at once. On some
|
||||
systems, this kicks in an IOMMU and turns the scatterlists into single
|
||||
|
||||
Reference in New Issue
Block a user