All of lore.kernel.org
 help / color / mirror / Atom feed
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.

      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.