mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Rhyland Klein <rklein@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	linux-spi@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org, Simon Glass <sjg@chromium.org>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [Patch V2] spi/tegra114: Correct support for cs_change
Date: Fri, 27 Sep 2013 14:25:11 +0100	[thread overview]
Message-ID: <20130927132511.GD19304@sirena.org.uk> (raw)
In-Reply-To: <1380214904-12899-1-git-send-email-rklein@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

On Thu, Sep 26, 2013 at 01:01:43PM -0400, Rhyland Klein wrote:
> The tegra114 driver wasn't currently handling the cs_change
> functionality. cs_change is meant to invert the decisions of whether
> or not to deactivate CS after each transfer. Without cs_change, after
> every transfer (other than the last in the message) the normal behavior
> is to leave CS active. For the last transfer, normally CS is
> deactivated when the transfer is complete.

Applied, thanks.

One thing I've got planned is to build on the existing factoring out of
the queue code so that we have several operations decomposing the
message transfer, something like:

 - Set /CS
 - Map/unmap data to be transferred
 - Actually transfer data

partly to avoid issues such as the one you're seeing here with fiddly
stuff like /CS and partly because the mapping operations should be the
same for many devices, as should the /CS manipulation for devices using
GPIOs.

I've started working on this today.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2013-09-27 13:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26 17:01 Rhyland Klein
2013-09-27 13:25 ` Mark Brown [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=20130927132511.GD19304@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=ldewangan@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=rklein@nvidia.com \
    --cc=sjg@chromium.org \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®