linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org,
	linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] spi: rockchip: Keep master alive when CS asserted
Date: Mon, 26 Jun 2017 15:17:37 -0700	[thread overview]
Message-ID: <20170626221736.GA126468@google.com> (raw)
In-Reply-To: <1498446606-5529-1-git-send-email-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

Hi Jeffy,

On Mon, Jun 26, 2017 at 11:10:06AM +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.

I believe Doug's point was larger than just the CS line. He was
guessing that you're also stopping driving any of the other pins (e.g.,
CLK), which could cause more problems. Seems like it'd be good to note
that in the second sentence here.

> Keep spi alive after CS asserted to prevent that.
> 
> Suggested-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> 
> ---
> 
>  drivers/spi/spi-rockchip.c | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
> index acf31f3..df016a1 100644
> --- a/drivers/spi/spi-rockchip.c
> +++ b/drivers/spi/spi-rockchip.c
> @@ -264,7 +264,7 @@ static inline u32 rx_max(struct rockchip_spi *rs)
>  
>  static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
>  {
> -	u32 ser;
> +	u32 ser, new_ser;
>  	struct spi_master *master = spi->master;
>  	struct rockchip_spi *rs = spi_master_get_devdata(master);
>  
> @@ -288,13 +288,25 @@ static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
>  	 * Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
>  	 */
>  	if (!enable)
> -		ser |= 1 << spi->chip_select;
> +		new_ser = ser | BIT(spi->chip_select);
>  	else
> -		ser &= ~(1 << spi->chip_select);
> +		new_ser = ser & ~BIT(spi->chip_select);
>  
> -	writel_relaxed(ser, rs->regs + ROCKCHIP_SPI_SER);
> +	if (new_ser == ser)
> +		goto out;

Hmm, this doens't exactly feel like a situation for 'goto'. Personally,
an indented 'if' block would make this clearer:

	if (new_ser != ser) {
		... // all the stuff you do only on CS edges
	}

>  
> -	pm_runtime_put_sync(rs->dev);
> +	writel_relaxed(new_ser, rs->regs + ROCKCHIP_SPI_SER);
> +
> +	/*
> +	 * The rockchip spi would stop driving CS when power down.

Replace "CS" with "all pins"? And:
s/power/powered/

> +	 * So we need to keep it alive after CS asserted

To make this clearer, note that we're keeping an unbalanced runtime PM
reference on purpose. Like instead of "we need to keep it alive after CS
asserted", maybe "we hold a runtime PM reference as long as CS is
asserted."?

> +	 */
> +	if (!enable)
> +		return;
> +	pm_runtime_put(rs->dev);

I still had to read this through a few times to be sure it was right (I
think it's correct?). Maybe to make this extra clear, a comment like
"Drop reference from when we first asserted CS" could go above this?

> +
> +out:
> +	pm_runtime_put(rs->dev);

You've dropped the "_sync()" that used to be here. I think that's
probably fine, but I wanted to call it out.

Brian

>  
>  static int rockchip_spi_prepare_message(struct spi_master *master,
> -- 
> 2.1.4
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2017-06-26 22:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26  3:10 [PATCH] spi: rockchip: Keep master alive when CS asserted Jeffy Chen
     [not found] ` <1498446606-5529-1-git-send-email-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-06-26 22:17   ` Brian Norris [this message]
     [not found]     ` <20170626221736.GA126468-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-06-27  2:22       ` jeffy

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=20170626221736.GA126468@google.com \
    --to=briannorris-f7+t8e8rja9g9huczpvpmw@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
    --cc=jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.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).