From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Add a mailbox driver framework/uclass
Date: Fri, 13 May 2016 15:26:13 -0600 [thread overview]
Message-ID: <57364675.2090504@wwwdotorg.org> (raw)
In-Reply-To: <CAPnjgZ0aKfr7Xth2Ah=AzMeQW08Q3AatuRa3ekXtjKyna1yJ5w@mail.gmail.com>
On 05/13/2016 02:05 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 12 May 2016 at 16:27, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> A mailbox is a hardware mechanism for transferring small message and/or
>> notifications between the CPU on which U-Boot runs and some other device
>> such as an auxilliary CPU running firmware or a hardware module.
>>
>> This patch defines a standard API that connects mailbox clients to mailbox
>> providers (drivers). Initially, DT is the only supported method for
>> connecting the two.
>>
>> The DT binding specification (mailbox.txt) was taken from Linux kernel
>> v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> Also see the remoteproc uclass. I'd just like to make sure that these
> should not be combined.
I think that's quite a different API; more to do with loading
firmware(?)/booting/resetting remote processors than communicating with
them once they're booted. FWIW, the Linux kernel has separate mailbox
and remoteproc APIs too.
>> diff --git a/drivers/mailbox/mailbox-uclass.c b/drivers/mailbox/mailbox-uclass.c
>> +int mbox_send(struct mbox_chan *chan, const void *data)
>
> Is there no length on the data?
The length is implicit; each mailbox implementation defines (the HW)
defines the exact message size it transfers. Clients would always use
this exact size.
>> +int mbox_recv(struct mbox_chan *chan, void *data, ulong timeout_us)
>> + start_time = get_ticks();
>> + /*
>> + * Account for partial us ticks, but if timeout_us is 0, ensure we
>> + * still don't wait at all.
>> + */
>> + if (timeout_us)
>> + timeout_us++;
>
> This seems a bit picky - it is only a microsecond!
Is there anything wrong with being correct? Equally, "only a
microsecond" admittedly isn't relevant if timeout_us is 1000 * 1000, but
is a massive percentage of the delay if timeout_us is something tiny
like 1 or 2.
prev parent reply other threads:[~2016-05-13 21:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 22:27 [U-Boot] [PATCH] Add a mailbox driver framework/uclass Stephen Warren
2016-05-13 20:05 ` Simon Glass
2016-05-13 21:26 ` Stephen Warren [this message]
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=57364675.2090504@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.