All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Wolsieffer <ben.wolsieffer@hefring.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Alain Volmat <alain.volmat@foss.st.com>
Subject: Re: [PATCH] spi: stm32: enable controller before asserting CS
Date: Fri, 1 Dec 2023 18:11:36 -0500	[thread overview]
Message-ID: <ZWpoKEcM0ZeYAsBa@dell-precision-5540> (raw)
In-Reply-To: <b070eb2a-05d7-4e6a-8de9-15179045d192@sirena.org.uk>

On Fri, Dec 01, 2023 at 09:50:33PM +0000, Mark Brown wrote:
> On Fri, Dec 01, 2023 at 04:40:14PM -0500, Ben Wolsieffer wrote:
> 
> This feels like it'd be a good fit for moving to runtime PM - that way
> we avoid bouncing the controller on and off between messages which is
> probably better anyway.  The driver already does pinctrl management for
> the device there.

Yes, that probably makes sense. There are a few bits that can only be
configured while the controller is disabled, but it doesn't look like
that applies to any of the ones set in stm32_spi_prepare_msg().

I'm a little hesitant to make big changes to the driver since I can only
test them on an STM32F7 though.

> It also occurs to me that this isn't going to work for devices which
> chip select inverted - for them we can't stop driving chip select at all
> since they need it held high when idle.  There aren't that many such
> devices and it'd loose us the PM which is rather awkward...  I guess
> that's an incremental issue with a more invasive fix though.

The driver only supports GPIO chip select rather than native, so I don't
think this is a problem. Also, I don't think there's any difference
between inverted or uninverted here. They both either need to be driven
all the time or have pull-up/downs.

Ben

WARNING: multiple messages have this Message-ID (diff)
From: Ben Wolsieffer <ben.wolsieffer@hefring.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Alain Volmat <alain.volmat@foss.st.com>
Subject: Re: [PATCH] spi: stm32: enable controller before asserting CS
Date: Fri, 1 Dec 2023 18:11:36 -0500	[thread overview]
Message-ID: <ZWpoKEcM0ZeYAsBa@dell-precision-5540> (raw)
In-Reply-To: <b070eb2a-05d7-4e6a-8de9-15179045d192@sirena.org.uk>

On Fri, Dec 01, 2023 at 09:50:33PM +0000, Mark Brown wrote:
> On Fri, Dec 01, 2023 at 04:40:14PM -0500, Ben Wolsieffer wrote:
> 
> This feels like it'd be a good fit for moving to runtime PM - that way
> we avoid bouncing the controller on and off between messages which is
> probably better anyway.  The driver already does pinctrl management for
> the device there.

Yes, that probably makes sense. There are a few bits that can only be
configured while the controller is disabled, but it doesn't look like
that applies to any of the ones set in stm32_spi_prepare_msg().

I'm a little hesitant to make big changes to the driver since I can only
test them on an STM32F7 though.

> It also occurs to me that this isn't going to work for devices which
> chip select inverted - for them we can't stop driving chip select at all
> since they need it held high when idle.  There aren't that many such
> devices and it'd loose us the PM which is rather awkward...  I guess
> that's an incremental issue with a more invasive fix though.

The driver only supports GPIO chip select rather than native, so I don't
think this is a problem. Also, I don't think there's any difference
between inverted or uninverted here. They both either need to be driven
all the time or have pull-up/downs.

Ben

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

  reply	other threads:[~2023-12-01 23:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-01 21:40 [PATCH] spi: stm32: enable controller before asserting CS Ben Wolsieffer
2023-12-01 21:40 ` Ben Wolsieffer
2023-12-01 21:50 ` Mark Brown
2023-12-01 21:50   ` Mark Brown
2023-12-01 23:11   ` Ben Wolsieffer [this message]
2023-12-01 23:11     ` Ben Wolsieffer
2023-12-04 12:43     ` Mark Brown
2023-12-04 12:43       ` Mark Brown
2023-12-04 19:54       ` Ben Wolsieffer
2023-12-04 19:54         ` Ben Wolsieffer

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=ZWpoKEcM0ZeYAsBa@dell-precision-5540 \
    --to=ben.wolsieffer@hefring.com \
    --cc=alain.volmat@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@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 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.