All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel@martin.sperl.org
To: Mark Brown <broonie@kernel.org>, Eric Anholt <eric@anholt.net>,
	Stefan Wahren <stefan.wahren@i2se.com>,
	linux-spi@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Cc: Martin Sperl <kernel@martin.sperl.org>
Subject: [PATCH 0/5] allow to define cs deassert times in us, ns and SCK-len
Date: Sat, 23 Feb 2019 08:49:47 +0000	[thread overview]
Message-ID: <20190223084952.14758-1-kernel@martin.sperl.org> (raw)

From: Martin Sperl <kernel@martin.sperl.org>

Using spi_transfer.cs_change right now means that there is a hard-coded
10 us delay between deassert and re-assert of cs.

For some devices this is way too long and either wastes resources
unecessarily or the driver works arround this currently with multiple
spi messages.

So this patch set modifies the spie core and some drivers so that
in spi_transfer we now can now define the minimum delay in units of:
microseconds, nanoseconds or spi clock length.

But note that on lower specs machines those ns delays are not realistic.
Lower limits on the actual delay are put by the gpio framework latency
for setting gpio level.
On a Raspberry Pi 3 this overhead has been observed to be in the order
1.2us.

As an idea: the xfer->cs_change_delay_unit could become more generic
by renaming it to delay_unit and then also us it as a modifier when
using xfer->delay_usecs.

Martin Sperl (5):
  spi: core: allow defining time that cs is deasserted
  spi: core: allow reporting the effectivly used speed_hz for a transfer
  spi: core: allow defining time that cs is deasserted as a multiple of
    SCK
  spi: bcm2835: support effective_speed_hz
  spi: bcm2835aux: support effective_speed_hz

 drivers/spi/spi-bcm2835.c    |  5 ++--
 drivers/spi/spi-bcm2835aux.c |  5 ++--
 drivers/spi/spi.c            | 68 +++++++++++++++++++++++++++++++++++++-------
 include/linux/spi/spi.h      | 13 +++++++++
 4 files changed, 75 insertions(+), 16 deletions(-)

--
2.11.0

WARNING: multiple messages have this Message-ID (diff)
From: kernel@martin.sperl.org
To: Mark Brown <broonie@kernel.org>, Eric Anholt <eric@anholt.net>,
	Stefan Wahren <stefan.wahren@i2se.com>,
	linux-spi@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Cc: Martin Sperl <kernel@martin.sperl.org>
Subject: [PATCH 0/5] allow to define cs deassert times in us, ns and SCK-len
Date: Sat, 23 Feb 2019 08:49:47 +0000	[thread overview]
Message-ID: <20190223084952.14758-1-kernel@martin.sperl.org> (raw)

From: Martin Sperl <kernel@martin.sperl.org>

Using spi_transfer.cs_change right now means that there is a hard-coded
10 us delay between deassert and re-assert of cs.

For some devices this is way too long and either wastes resources
unecessarily or the driver works arround this currently with multiple
spi messages.

So this patch set modifies the spie core and some drivers so that
in spi_transfer we now can now define the minimum delay in units of:
microseconds, nanoseconds or spi clock length.

But note that on lower specs machines those ns delays are not realistic.
Lower limits on the actual delay are put by the gpio framework latency
for setting gpio level.
On a Raspberry Pi 3 this overhead has been observed to be in the order
1.2us.

As an idea: the xfer->cs_change_delay_unit could become more generic
by renaming it to delay_unit and then also us it as a modifier when
using xfer->delay_usecs.

Martin Sperl (5):
  spi: core: allow defining time that cs is deasserted
  spi: core: allow reporting the effectivly used speed_hz for a transfer
  spi: core: allow defining time that cs is deasserted as a multiple of
    SCK
  spi: bcm2835: support effective_speed_hz
  spi: bcm2835aux: support effective_speed_hz

 drivers/spi/spi-bcm2835.c    |  5 ++--
 drivers/spi/spi-bcm2835aux.c |  5 ++--
 drivers/spi/spi.c            | 68 +++++++++++++++++++++++++++++++++++++-------
 include/linux/spi/spi.h      | 13 +++++++++
 4 files changed, 75 insertions(+), 16 deletions(-)

--
2.11.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2019-02-23  8:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-23  8:49 kernel [this message]
2019-02-23  8:49 ` [PATCH 0/5] allow to define cs deassert times in us, ns and SCK-len kernel
2019-02-23  8:49 ` [PATCH 2/5] spi: core: allow reporting the effectivly used speed_hz for a transfer kernel
2019-02-23  8:49   ` kernel
2019-02-23  8:49 ` [PATCH 3/5] spi: core: allow defining time that cs is deasserted as a multiple of SCK kernel
2019-02-23  8:49   ` kernel
     [not found]   ` <20190223124010.y7lsncknnxoblvgz@wunner.de>
     [not found]     ` <20190223124010.y7lsncknnxoblvgz-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2019-02-23 13:15       ` kernel-TqfNSX0MhmxHKSADF0wUEw
2019-02-23 13:15         ` kernel
     [not found]         ` <20190224103913.bjw7g6ievr75iawz@wunner.de>
     [not found]           ` <20190224103913.bjw7g6ievr75iawz-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2019-02-24 11:03             ` kernel-TqfNSX0MhmxHKSADF0wUEw
2019-02-24 11:03               ` kernel
2019-02-26 11:37               ` Mark Brown
2019-05-07 10:07                 ` kernel
2019-05-07 10:07                   ` kernel
     [not found] ` <20190223084952.14758-1-kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
2019-02-23  8:49   ` [PATCH 1/5] spi: core: allow defining time that cs is deasserted kernel-TqfNSX0MhmxHKSADF0wUEw
2019-02-23  8:49     ` kernel
     [not found]     ` <20190223084952.14758-2-kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
2019-05-08  9:34       ` Applied "spi: core: allow defining time that cs is deasserted" to the spi tree Mark Brown
2019-05-08  9:34         ` Mark Brown
2019-02-23  8:49   ` [PATCH 4/5] spi: bcm2835: support effective_speed_hz kernel-TqfNSX0MhmxHKSADF0wUEw
2019-02-23  8:49     ` kernel
2019-05-13 15:14     ` Mark Brown

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=20190223084952.14758-1-kernel@martin.sperl.org \
    --to=kernel@martin.sperl.org \
    --cc=broonie@kernel.org \
    --cc=eric@anholt.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=stefan.wahren@i2se.com \
    /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.