Linux/DRA76P: Usage of Mailbox Framework in own driver...

Marco Reppenhagen

Part Number: DRA76P
Other Parts Discussed in Thread: TDA2

Tool/software: Linux

Hello!

Today I've got a quite simple question, because I got a knowledge gap with the flattened device tree:

I would like to write a simple Linux driver, which handles the HW-Mailbox of the TDA2+ device.
(We are not able to use the TI-SDK and its "IPC" over RPMSG. So: NO sdk is used!)

We have to adapt in-house-software to this new SoC and I stuck on the following, may be very simple problem:

How to setup device tree to fulfill the needs of the omap-mbox and mailbox framework inside the linux?
I want to write a driver which handles Mailboxes - the mbox Framework on one side, a userland-API on the other.

Driver is setup as following:

probe....{
...
tdev->tx_channel = mbox_sms_request_channel(pdev, "tx");
tdev->rx_channel = mbox_sms_request_channel(pdev, "rx");
if (!tdev->tx_channel && !tdev->rx_channel)
return -EPROBE_DEFER;
tdev->dev = &pdev->dev;
platform_set_drvdata(pdev, tdev);

...

}

static const struct of_device_id mbox_sms_match[] = {
        { .compatible = "sms-icc-mbox" },
        {},
};

static struct platform_driver mbox_sms_driver = {
        .driver = {
                .name = "mailbox-sms-icc",
                .of_match_table = mbox_sms_match,
        },
        .probe  = mbox_sms_probe,
        .remove = mbox_sms_remove,
};

And in the DTS File (I do not change anything in the "dtsi")
I would like to use the "free" mailbox No. 10 of the TDAX and try to set it up like this:

Contend of the "mygadget.dts" (relating lines):

\{
...
 mailboxsms {
                compatible = "sms-icc-mbox";
                #mbox-cells = <1>;
                mboxes = <&mailbox10 &mbox_sms>;
                mbox-names = "rx", "tx";
                status = "okay";
        };
...
}

...
&mailbox10 {
        #mbox-cells = <1>;
        status = "okay";
        mbox_sms: mbox_sms {
                ti,mbox-tx = <10 0 0>;
                ti,mbox-rx = <10 1 0>;
                status = "okay";
        };
};

This do not work... the driver runs into the probing function (fine!), but is not able to request the channels. I got the following error message:

mbox_request_channel: can't parse "mboxes" property

after:

could not get #mbox-cells for /ocp/mailbox@48860000/mbox_sms

Please tell me how I have to set and bind:

mboxes

#mbox-cells

mbox-names

(something forgotten?)

The Documentation in the Kernel wasn't helpful for me and I didn't found any information about how to handle the mbox framework in the net.

Thank you for your help... Marco.

over 7 years ago

0 Suman Anna over 7 years ago

TI__Guru** 115935 points

Hi Marco,

There is a slight difference between Mailbox Controller and Consumer. The OMAP Mailbox driver is the controller (drivers/mailbox/omap-mailbox.c) and you (mailbox_sms_icc) are the mailbox client/consumer driver in this case. The API to use is provided by the mailbox core. See include/linux/mailbox_client.h for the API provided by the Mailbox core. The OMAP Mailbox usage details are explained in the OMAP Mailbox binding. Please look into your kernel's Documentation/devicetree/bindings/mailbox/omap-mailbox.txt file. The following is a quick reference to the binding on our 4.4 kernel feature branch.
git.ti.com/.../

Here are the issues with your code snippet,
1. You have the mbox_sms added in the right place, but you are using the same first-cell value of 10 in ti,mbox-rx and ti,mbox-tx properties. Unless this is a MPU loopback device, this is wrong. We expect the fifo ids to be different if you are talking between two different processors.
2. The #mbox-cells property needs to be added only in controller nodes. The mailboxsms is a client/user, so you shouldn't have the #mbox-cells.
3. You have two mbox-names while you only have one mbox device used in the mboxes property. The mbox_sms is a duplex communication device, so you only need to use one mbox-names value in your mailboxsms node.
4. Use the Mailbox framework provided API, mbox_request_channel() or mbox_request_channel_byname() instead of your mbox_sms_request_channel() API in your probe. You only need to use a single call. You can use the returned handle to send messages using mbox_send_message() API. Any messages you receive will be provided to you through the callback you supplied in mbox_request_channel()

Please look at the drivers/remoteproc/omap_remoteproc.c to see example usage of the OMAP Mailboxes. This is the kernel-side interface. Providing an interface to userspace has to be done within your driver. For your reference, there is an example test driver, drivers/mailbox/mailbox-test.c, in the kernel that uses simplex communication devices and debugfs interface to userspace for reading and writing to mailboxes, but this needs some changes to use with OMAP Mailboxes since all OMAP sub-mailboxes are duplex devices.

regards
Suman

0 Marco Reppenhagen over 7 years ago in reply to Suman Anna

Intellectual 790 points

Thank you for quick response.

Some question are open:
(1) Would you please explain, what is the meaning/functionality of the three values "ti,mbox-XX"? As far as I understood, the first value is the "mailbox" number, and our usecase is the following: We only use one mailbox for RX and TX. (Requirement is given...) And RX/TX will use two different channels of the mailbox. Communication will be between ARM and M4 Core.

(2) I will fix this and have a try again.

(3) I took the file "mailbox-test.c" out of the driver/mailbox directory as a skeleton of my own driver; mbox_request_channel_byname is called in mbox_sms_request_channel.... again some Questions:
(a) Easier to use mbox_request_channel_byname without the strings?
(b) In the example " drivers/mailbox/mailbox-test.c" There is a channel for rx, another for tx - Thre are two calls of mbox_request_channel_byname, you told me only to use one... What I thought: I need two channels - One for TX and another for RX... how this schould work calling a request_channel only once?

Thank you for your efforts...
Marco.

0 Suman Anna over 7 years ago in reply to Marco Reppenhagen

TI__Guru** 115935 points

Hi Marco,

Responses to your questions:
(1) I think there is some confusion on the terms. We refer to the term "mailbox" as the name for the IP instance. There are 12 instances on the DRA7x family. Each IP instance has a number (16 on most) of unidirectional hardware fifos. Each Mailbox IP has 4 interrupt outputs, with each interrupt output used by a processor core (called a User, partitioning defined through software, so totally flexible). For example, if you are communicating between ARM and DSP1 and using Mailbox 10 IP instance, you can assign ARM as User 0 and DSP1 and User 1. You could have communications to a DSP2 using User 2, and using different FIFO pairs between all three processors. Please look through the Mailbox chapter in the TRM for additional details.

The three cells are explained well in the binding - first cell is the FIFO number, second cell is index of the interrupt to be used by MPU (from the interrupts property, so this will typically be same between ti,mbox-rx and ti,mbox-tx) and the third cell is the User id (I expect second cell and third cells to typically match value as the interrupts are listed in the same order as the 4 User interrupt outputs). Note that these assignments only define the Rx and Tx from MPU perspective. The exceptions to the typical usage is if you assign multiple User interrupts towards MPU and separate them out between Rx and Tx.

(3).(a) I am not quite sure I understand your question. mbox_request_channel_byname() is designed to be able to request a mailbox channel when your client DTS node has multiple mboxes defined in the "mboxes" property. The name you pass in should match one of the names used in the "mbox-names" property. The other API is by index into your "mboxes" property. If you will only have one mbox channel in your client, you can simply drop the "mbox-names" property and just use mbox_request_channel with index 0.

(3).(b) The mbox_channel is the name used by mailbox core to represent a communication channel registered by mailbox controllers/providers with the mailbox core. Each such channel can be uni-directional (requiring you to request two channels - one for Rx or Tx), or simply a duplex channel (requiring you to request only one channel which includes both Rx and Tx). The OMAP Mailbox channels follow the latter convention, and the driver actually doesn't support defining simplex channels. Your mbox_sms node under mailbox10 defines a duplex channel. The "ti,mbox-rx" and the "ti,mbox-tx" dictate your Rx and Tx FIFOs respectively from Linux-side.

regards
Suman

0 Marco Reppenhagen over 7 years ago in reply to Suman Anna

Intellectual 790 points

Now I see much clearer!

I will try to get on and open another Thread if I have any further questions.
Thank you for explaining these "basics" and help me delve into the topic.

Marco.

Processors

Processors forum

Linux/DRA76P: Usage of Mailbox Framework in own driver...