All of lore.kernel.org
 help / color / mirror / Atom feed
From: bbrezillon@kernel.org (Boris Brezillon)
To: linux-i3c@lists.infradead.org
Subject: i3c_master_add_i3c_dev_locked() accept PID, BCR, DCR
Date: Tue, 11 Dec 2018 13:25:03 +0100	[thread overview]
Message-ID: <20181211132446.4d93fd10@bbrezillon> (raw)
In-Reply-To: <20181211132103.34ae80c8@bbrezillon>

On Tue, 11 Dec 2018 13:21:03 +0100
Boris Brezillon <bbrezillon@kernel.org> wrote:

> On Tue, 11 Dec 2018 12:07:16 +0000
> vitor <vitor.soares@synopsys.com> wrote:
> 
> > On 11/12/18 11:58, Boris Brezillon wrote:  
> > >> I just want to skip GETBCR/DCR/PID operations since those data are
> > >> already available in the controller. There's advantages but they
> > >> only have relevance depending of use case.    
> > > Can you detail those use cases please?    
> > 
> > If the bus has a lot of devices and you want to decrease the
> > initialization time this could be the first step.
> >   
> 
> Did you quantify the boot-time/perf improvement? The clk should be
> running at 12.5MHz, GETPID takes 9bytes and GETBCR/DCR take 4 bytes
> each. Let's add one byte per command to account for the start/stop
> bits. That makes a total of 20bytes per device, with a maximum of 11
> devices per bus:
> 
> max_time_to_query_pid_bcr_dcr_per_bus = 20 * 10 / 12500000 = 17.6 usec.

Sorry, small mistake, I counted bytes instead of bits.

max_time_to_query_pid_bcr_dcr_per_bus = 20 * 8 * 11 / 12500000 = 141usec.

> Let's assume we have a huge overhead caused by the OS (and all the
> scheduling involved), and make it 100usec.

And let's make it 500usec with the OS overhead, which is still not
particularly worrisome in term of boot-time.

  reply	other threads:[~2018-12-11 12:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 19:21 i3c_master_add_i3c_dev_locked() accept PID, BCR, DCR vitor
2018-12-10 19:43 ` Boris Brezillon
2018-12-10 20:14   ` Boris Brezillon
2018-12-11 11:54     ` vitor
2018-12-11 11:58       ` Boris Brezillon
2018-12-11 12:07         ` vitor
2018-12-11 12:21           ` Boris Brezillon
2018-12-11 12:25             ` Boris Brezillon [this message]
2018-12-11 15:47               ` vitor
2018-12-12  6:06                 ` Przemyslaw Gaj
2018-12-12  8:21                   ` Boris Brezillon
2018-12-12  8:37                     ` Przemyslaw Gaj
2018-12-12  8:52                       ` Boris Brezillon
2018-12-12  9:02                         ` Przemyslaw Gaj
2018-12-12  9:09                           ` Boris Brezillon

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=20181211132446.4d93fd10@bbrezillon \
    --to=bbrezillon@kernel.org \
    --cc=linux-i3c@lists.infradead.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 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.