From: Jassi Brar <jassisinghbrar@gmail.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kernel@stlinux.com, Devicetree List <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers
Date: Thu, 13 Aug 2015 16:40:42 +0530 [thread overview]
Message-ID: <CABb+yY34i=VUnswUE21vgeQYAGOS=7uwvdnTAFFgYkTV0CFk=w@mail.gmail.com> (raw)
In-Reply-To: <20150813110008.GD8782@x1>
On Thu, Aug 13, 2015 at 4:30 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 13 Aug 2015, Jassi Brar wrote:
>
>> On Thu, Aug 13, 2015 at 3:53 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Thu, 13 Aug 2015, Jassi Brar wrote:
>> >
>> >> On Thu, Aug 13, 2015 at 2:49 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> > On Thu, 13 Aug 2015, Jassi Brar wrote:
>> >>
>> >> >> >> > +
>> >> >> >> > +static void mbox_test_prepare_message(struct mbox_client *client, void *message)
>> >> >> >> > +{
>> >> >> >> > + struct mbox_test_device *tdev = dev_get_drvdata(client->dev);
>> >> >> >> > +
>> >> >> >> > + if (tdev->mmio)
>> >> >> >> > + memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
>> >> >> >> >
>> >> >> >> This is unlikely to work. Those platforms that need to send a 2 part
>> >> >> >> message, they do :
>> >> >> >> (a) Signal/Command/Target code via some controller register (via
>> >> >> >> mbox_send_message).
>> >> >> >> (b) Setup the payload in Shared-Memory (via tx_prepare).
>> >> >> >>
>> >> >> >> This test driver assumes both are the same. I think you have to
>> >> >> >> declare something like
>> >> >> >
>> >> >> > This driver assumes that the framework will call client->tx_prepare()
>> >> >> > first, which satisfies (b). It then assumes controller->send_data()
>> >> >> > will be invoked, which will send the platform specific
>> >> >> > signal/command/target code, which then satisfies (a).
>> >> >> >
>> >> >> Yeah, but what would be that code? Who provides that?
>> >> >>
>> >> >> > In what way does it assume they are the same?
>> >> >> >
>> >> >> notice the 'message' pointer in
>> >> >> mbox_send_message(tdev->tx_channel, message);
>> >> >> and
>> >> >> memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
>> >> >>
>> >> >> >> struct mbox_test_message { /* same for TX and RX */
>> >> >> >> unsigned sig_len;
>> >> >> >> void *signal; /* rx/tx via mailbox api */
>> >> >> >> unsigned pl_len;
>> >> >> >> void *payload; /* rx/tx via shared-memory */
>> >> >> >> };
>> >> >> >
>> >> >> > How do you think this should be set and use these?
>> >> >> >
>> >> >> The userspace would want to specify the command code (32bits or not)
>> >> >> that would be passed via the fifo/register of the controller. So we
>> >> >> need signal[]
>> >> >>
>> >> >> The data to be passed via share-memory could be provided by userspace
>> >> >> via the payload[] array.
>> >> >
>> >> > Okay, so would the solution be two userspace files 'signal' and
>> >> > 'message', so in the case of a client specified signal we can write it
>> >> > into there first.
>> >> >
>> >> > echo 255 > signal
>> >> > echo test > message
>> >> >
>> >> > ... or in the case where no signal is required, or the controller
>> >> > driver taking care of it, we just don't write anything to signal?
>> >> >
>> >> file_operations.write() should parse signal and message, coming from
>> >> userspace, into a local structure before routing them via
>> >> mbox_send_message and tx_prepare respectively.
>> >
>> > Okay. So before I code this up we should agree on syntax.
>> >
>> > How would you like to represent the break between signal and message?
>> > Obviously ' ' would be a bad idea, as some clients may want to send
>> > messages with white space contained. How about '\t' or '\n'?
>> >
>> Yeah, I am not a fan of markers and flags either.
>>
>> Maybe we should share with userspace
>> struct mbox_test_message { /* same for TX and RX */
>> unsigned sig_len;
>> void __user *signal; /* rx/tx via mailbox api */
>> unsigned pl_len;
>> void __user *payload; /* rx/tx via shared-memory */
>> };
>>
>> First copy_from_user the structure of length sizof(struct
>> mbox_test_message) and then copy_from_user length sig_len and pl_len
>> from signal[] and payload[] respectively (usually ioctls would carry
>> such data).
>
> Simplicity and ease of use should be the goals here. Testers should
> not have to write applications to use this driver. Can we come up
> with a simple/effective method that uses SYSFS/DEBUGFS please?
>
> The easiest way I can think of which avoids markers/separators AND the
> requirement for users to have to write applications is to have two
> files, 'signal' and 'message' as mentioned before. Once both are
> populated I can get this driver to draft the message appropriately and
> fire it off.
>
And then write to more files for RX data? ... which should also be in
the form of 'signal' and 'message'.
BTW like for spi there is a stock application in
Documentation/spi/spidev_test.c we could do the same?
next prev parent reply other threads:[~2015-08-13 11:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 9:44 [PATCH v2 0/6] Mailbox: Provide support STi based platforms Lee Jones
2015-07-27 9:44 ` [PATCH v2 1/6] mailbox: dt: Supply bindings for ST's Mailbox IP Lee Jones
2015-07-27 9:44 ` [PATCH v2 2/6] mailbox: dt-bindings: Add shared [driver <=> device tree] defines Lee Jones
2015-08-10 6:58 ` Jassi Brar
2015-08-10 8:24 ` Lee Jones
2015-08-10 8:47 ` Jassi Brar
2015-08-12 8:53 ` Lee Jones
2015-08-12 10:16 ` Jassi Brar
2015-08-12 10:43 ` Lee Jones
2015-07-27 9:44 ` [PATCH v2 3/6] mailbox: Add support for ST's Mailbox IP Lee Jones
2015-07-28 22:06 ` Paul Bolle
2015-07-30 11:45 ` Lee Jones
2015-07-30 12:48 ` Paul Bolle
2015-07-30 13:31 ` Lee Jones
2015-08-13 15:40 ` Jassi Brar
2015-08-14 6:33 ` Lee Jones
2015-08-14 7:39 ` Jassi Brar
2015-08-14 10:41 ` Lee Jones
2015-07-27 9:44 ` [PATCH v2 4/6] ARM: STi: stih407-family: Add nodes for Mailbox Lee Jones
2015-07-27 9:44 ` [PATCH v2 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers Lee Jones
2015-08-10 6:45 ` Jassi Brar
2015-08-12 10:23 ` Lee Jones
2015-08-13 8:51 ` Jassi Brar
2015-08-13 9:19 ` Lee Jones
2015-08-13 10:01 ` Jassi Brar
2015-08-13 10:23 ` Lee Jones
2015-08-13 10:41 ` Jassi Brar
2015-08-13 11:00 ` Lee Jones
2015-08-13 11:10 ` Jassi Brar [this message]
2015-08-13 11:40 ` Lee Jones
2015-08-13 12:47 ` Jassi Brar
2015-08-13 13:07 ` Lee Jones
2015-08-13 13:46 ` Jassi Brar
2015-08-13 14:26 ` Lee Jones
2015-07-27 9:44 ` [PATCH v2 6/6] ARM: STi: DT: STiH407: Enable Mailbox testing facility Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABb+yY34i=VUnswUE21vgeQYAGOS=7uwvdnTAFFgYkTV0CFk=w@mail.gmail.com' \
--to=jassisinghbrar@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@stlinux.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).