linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: "Ji-Ze Hong (Peter Hong)" <hpeter@gmail.com>
Cc: Johan Hovold <johan@kernel.org>,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Ji-Ze Hong (Peter Hong)" <hpeter+linux_kernel@gmail.com>
Subject: Re: [PATCH V1 3/4] usb: serial: f81534: add output pin control
Date: Tue, 2 Jan 2018 10:27:45 +0100	[thread overview]
Message-ID: <20180102092745.GG16993@localhost> (raw)
In-Reply-To: <c933430c-1ea8-5dae-fe75-a0acc4592aae@gmail.com>

On Tue, Jan 02, 2018 at 11:24:26AM +0800, Ji-Ze Hong (Peter Hong) wrote:
> Hi Johan,
> 
> >> In this code, I'm only read/write 3 registers of 0x2ae8, 0x2a90, 0x2a80,
> >> but some register will read/write more than once. Should I change the
> >> code from port_probe() to attach() and re-write it as:
> >> 	1: read the 3 register
> >> 	2: change them will 12 pin desire value
> >> 	3: write it back
> >> Is it ok?
> > 
> > Do you expect these pins to ever be changed after probe? If not, then
> > perhaps it can be moved to attach(), but otherwise I guess they should
> > be set at port_probe(). By using shadow registers, you should be able to
> > reduce the number of device accesses, but perhaps it's not worth the
> > complexity.
> > 
> > Do you have a rough idea about how long these register updates take? I
> > was just worried that these changes will add up to really long probe
> > times.
> > 
> 
> I had measured the time of the loop in f81534_set_port_output_pin() via
> getnstimeofday() with 685.410 ~ 3681.682us per port, but normally with
> 600~800us per port. So I prefer remain the current method of
> f81534_set_port_output_pin(). Is it ok?

That should be fine. Thanks for verifying.

Johan

  reply	other threads:[~2018-01-02  9:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-16  7:46 [PATCH V1 1/4] usb: serial: f81534: add high baud rate support Ji-Ze Hong (Peter Hong)
2017-11-16  7:46 ` [PATCH V1 2/4] usb: serial: f81534: add auto RTS direction support Ji-Ze Hong (Peter Hong)
2017-12-18 15:18   ` Johan Hovold
2017-11-16  7:46 ` [PATCH V1 3/4] usb: serial: f81534: add output pin control Ji-Ze Hong (Peter Hong)
2017-12-18 16:06   ` Johan Hovold
2017-12-21  9:49     ` Ji-Ze Hong (Peter Hong)
2017-12-27 10:30       ` Johan Hovold
2018-01-02  3:24         ` Ji-Ze Hong (Peter Hong)
2018-01-02  9:27           ` Johan Hovold [this message]
2017-11-16  7:46 ` [PATCH V1 4/4] usb: serial: f81534: add H/W disable port support Ji-Ze Hong (Peter Hong)
2017-12-18 16:15   ` Johan Hovold
2017-12-18 15:14 ` [PATCH V1 1/4] usb: serial: f81534: add high baud rate support Johan Hovold

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=20180102092745.GG16993@localhost \
    --to=johan@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpeter+linux_kernel@gmail.com \
    --cc=hpeter@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@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).