All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>,
	linux-kernel@vger.kernel.org, dianders@chromium.org,
	heiko@sntech.de, devicetree@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Will Deacon <will.deacon@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH v2 4/4] arm64: dts: rockchip: use cs-gpios for cros_ec_spi
Date: Tue, 13 Jun 2017 19:22:25 +0100	[thread overview]
Message-ID: <20170613182225.smahsf3jzvbc7w7z@sirena.org.uk> (raw)
In-Reply-To: <20170613175043.GC9026@google.com>

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

On Tue, Jun 13, 2017 at 10:50:44AM -0700, Brian Norris wrote:
> On Tue, Jun 13, 2017 at 01:25:43PM +0800, Jeffy Chen wrote:
> > The cros_ec requires CS line to be active after last message. But the CS
> > would be toggled when powering off/on rockchip spi, which breaks ec xfer.
> > Use GPIO CS to prevent that.

> I suppose this change is fine. (At least, I don't have a good reason not
> to do this.)

> But I still wonder whether this is something that the SPI core can be
> expected to handle. drivers/mfd/cros_ec_spi.c already sets the
> appropriate trans->cs_change bits, to ensure CS remains active in
> between certain messages (all under spi_bus_lock()). But you're
> suggesting that your bus controller may deassert CS if you runtime
> suspend the device (e.g., in between messages).

> So, is your controller just peculiar? Or should the SPI core avoid
> autosuspending the bus controller when it's been instructed to keep CS
> active? Any thoughts Mark?

This sounds like the controller being unusual - though frankly the
ChromeOS chip select usage is also odd so it's fairly rare for something
like this to come up.  I'd not expect a runtime suspend to loose the pin
state, though possibly through use of pinctrl rather than the
controller.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH v2 4/4] arm64: dts: rockchip: use cs-gpios for cros_ec_spi
Date: Tue, 13 Jun 2017 19:22:25 +0100	[thread overview]
Message-ID: <20170613182225.smahsf3jzvbc7w7z@sirena.org.uk> (raw)
In-Reply-To: <20170613175043.GC9026-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

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

On Tue, Jun 13, 2017 at 10:50:44AM -0700, Brian Norris wrote:
> On Tue, Jun 13, 2017 at 01:25:43PM +0800, Jeffy Chen wrote:
> > The cros_ec requires CS line to be active after last message. But the CS
> > would be toggled when powering off/on rockchip spi, which breaks ec xfer.
> > Use GPIO CS to prevent that.

> I suppose this change is fine. (At least, I don't have a good reason not
> to do this.)

> But I still wonder whether this is something that the SPI core can be
> expected to handle. drivers/mfd/cros_ec_spi.c already sets the
> appropriate trans->cs_change bits, to ensure CS remains active in
> between certain messages (all under spi_bus_lock()). But you're
> suggesting that your bus controller may deassert CS if you runtime
> suspend the device (e.g., in between messages).

> So, is your controller just peculiar? Or should the SPI core avoid
> autosuspending the bus controller when it's been instructed to keep CS
> active? Any thoughts Mark?

This sounds like the controller being unusual - though frankly the
ChromeOS chip select usage is also odd so it's fairly rare for something
like this to come up.  I'd not expect a runtime suspend to loose the pin
state, though possibly through use of pinctrl rather than the
controller.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/4] arm64: dts: rockchip: use cs-gpios for cros_ec_spi
Date: Tue, 13 Jun 2017 19:22:25 +0100	[thread overview]
Message-ID: <20170613182225.smahsf3jzvbc7w7z@sirena.org.uk> (raw)
In-Reply-To: <20170613175043.GC9026@google.com>

On Tue, Jun 13, 2017 at 10:50:44AM -0700, Brian Norris wrote:
> On Tue, Jun 13, 2017 at 01:25:43PM +0800, Jeffy Chen wrote:
> > The cros_ec requires CS line to be active after last message. But the CS
> > would be toggled when powering off/on rockchip spi, which breaks ec xfer.
> > Use GPIO CS to prevent that.

> I suppose this change is fine. (At least, I don't have a good reason not
> to do this.)

> But I still wonder whether this is something that the SPI core can be
> expected to handle. drivers/mfd/cros_ec_spi.c already sets the
> appropriate trans->cs_change bits, to ensure CS remains active in
> between certain messages (all under spi_bus_lock()). But you're
> suggesting that your bus controller may deassert CS if you runtime
> suspend the device (e.g., in between messages).

> So, is your controller just peculiar? Or should the SPI core avoid
> autosuspending the bus controller when it's been instructed to keep CS
> active? Any thoughts Mark?

This sounds like the controller being unusual - though frankly the
ChromeOS chip select usage is also odd so it's fairly rare for something
like this to come up.  I'd not expect a runtime suspend to loose the pin
state, though possibly through use of pinctrl rather than the
controller.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170613/da670236/attachment-0001.sig>

  reply	other threads:[~2017-06-13 18:22 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-13  5:25 [PATCH v2 1/4] spi: rockchip: fix error handling when probe Jeffy Chen
2017-06-13  5:25 ` Jeffy Chen
2017-06-13  5:25 ` Jeffy Chen
2017-06-13  5:25 ` [PATCH v2 2/4] spi: rockchip: add support for "cs-gpios" dts property Jeffy Chen
2017-06-13  5:25   ` Jeffy Chen
2017-06-13  5:25   ` Jeffy Chen
2017-06-13 17:24   ` kbuild test robot
2017-06-13 17:24     ` kbuild test robot
2017-06-13 17:24     ` kbuild test robot
2017-06-13 17:33   ` Brian Norris
2017-06-13 17:33     ` Brian Norris
2017-06-14  1:27     ` jeffy
2017-06-14  1:27       ` jeffy
2017-06-14  1:27       ` jeffy
2017-06-13  5:25 ` [PATCH v2 3/4] dt-bindings: spi/rockchip: add "cs-gpios" optional property Jeffy Chen
2017-06-13  5:25   ` Jeffy Chen
2017-06-13  5:25 ` [PATCH v2 4/4] arm64: dts: rockchip: use cs-gpios for cros_ec_spi Jeffy Chen
2017-06-13  5:25   ` Jeffy Chen
2017-06-13  5:25   ` Jeffy Chen
2017-06-13 17:50   ` Brian Norris
2017-06-13 17:50     ` Brian Norris
2017-06-13 17:50     ` Brian Norris
2017-06-13 18:22     ` Mark Brown [this message]
2017-06-13 18:22       ` Mark Brown
2017-06-13 18:22       ` Mark Brown
2017-06-20  0:47       ` Brian Norris
2017-06-20  0:47         ` Brian Norris
2017-06-20  0:47         ` Brian Norris
2017-06-22 22:47         ` Doug Anderson
2017-06-22 22:47           ` Doug Anderson
2017-06-22 22:47           ` Doug Anderson
2017-06-23  3:51           ` jeffy
2017-06-23  3:51             ` jeffy
2017-06-23  4:26             ` Doug Anderson
2017-06-23  4:26               ` Doug Anderson
     [not found]               ` <594D0723.7010108@rock-chips.com>
     [not found]                 ` <CAD=FV=XjW4a9mqH0UtUAmHkj-aAO75bpSXuyy__jBB7YC8PBVg@mail.gmail.com>
2017-06-26  3:26                   ` jeffy
2017-06-26  3:26                     ` jeffy
2017-06-26  3:26                     ` jeffy
2017-06-26  3:27                   ` jeffy
2017-06-26  3:27                     ` jeffy
2017-06-26  3:27                     ` jeffy
2017-06-13 17:29 ` [PATCH v2 1/4] spi: rockchip: fix error handling when probe Brian Norris
2017-06-13 17:29   ` Brian Norris

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=20170613182225.smahsf3jzvbc7w7z@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=briannorris@chromium.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=jeffy.chen@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=will.deacon@arm.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.