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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox