From: Stefan Wahren <stefan.wahren@i2se.com>
To: Linus Walleij <linus.walleij@linaro.org>,
Mark Brown <broonie@kernel.org>,
linux-spi@vger.kernel.org
Cc: linux-gpio@vger.kernel.org,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Lukas Wunner <lukas@wunner.de>,
Martin Sperl <kernel@martin.sperl.org>,
Chris Boot <bootc@bootc.net>
Subject: Re: [PATCH v4] spi: bcm2835: Convert to use CS GPIO descriptors
Date: Tue, 13 Aug 2019 11:36:13 +0200 [thread overview]
Message-ID: <d4df1cdd-604b-89bd-27da-ed455f170b00@i2se.com> (raw)
In-Reply-To: <20190804003852.1312-1-linus.walleij@linaro.org>
Hi Linus,
On 04.08.19 02:38, Linus Walleij wrote:
> This converts the BCM2835 SPI master driver to use GPIO
> descriptors for chip select handling.
>
> The BCM2835 driver was relying on the core to drive the
> CS high/low so very small changes were needed for this
> part. If it managed to request the CS from the device tree
> node, all is pretty straight forward.
>
> However for native GPIOs this driver has a quite unorthodox
> loopback to request some GPIOs from the SoC GPIO chip by
> looking it up from the device tree using gpiochip_find()
> and then offseting hard into its numberspace. This has
> been augmented a bit by using gpiochip_request_own_desc()
> but this code really needs to be verified. If "native CS"
> is actually an SoC GPIO, why is it even done this way?
> Should this GPIO not just be defined in the device tree
> like any other CS GPIO? I'm confused.
>
> Cc: Lukas Wunner <lukas@wunner.de>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Martin Sperl <kernel@martin.sperl.org>
> Cc: Chris Boot <bootc@bootc.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v3->v4:
> - Fix the offset of the chipselect line to be 8 - CS
> as in the original code.
> - Use the modified gpiochip_request_own_desc() to set up
> line inversion semantics if need be. Look at the OF
> node of the SPI device for flags.
> ChangeLog v2->v3:
> - Fix unused variable "err" compile-time message.
> ChangeLog RFT->v2:
> - Rebased on v5.1-rc1
>
> I would very much appreciate if someone took this for
> a ride on top of linux-next (there are some fixes in
> the -rcs you need) and see if all still works as expected.
sorry for my late reply, but i was on vacation.
Thanks for your efforts on this, but currently i don't have a setup to
test this :-(
next prev parent reply other threads:[~2019-08-13 9:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-04 0:38 [PATCH v4] spi: bcm2835: Convert to use CS GPIO descriptors Linus Walleij
2019-08-13 9:36 ` Stefan Wahren [this message]
2019-08-28 13:13 ` Applied "spi: bcm2835: Convert to use CS GPIO descriptors" to the spi tree 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=d4df1cdd-604b-89bd-27da-ed455f170b00@i2se.com \
--to=stefan.wahren@i2se.com \
--cc=bgolaszewski@baylibre.com \
--cc=bootc@bootc.net \
--cc=broonie@kernel.org \
--cc=kernel@martin.sperl.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=lukas@wunner.de \
/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).