From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Girish K S <girishks2000@gmail.com>
Cc: spi-devel-general@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, grant.likely@secretlab.ca,
t.figa@samsung.com
Subject: Re: [PATCH V3 2/5] spi: s3c64xx: added support for polling mode
Date: Mon, 1 Apr 2013 14:12:07 +0100 [thread overview]
Message-ID: <20130401131207.GI18636@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1363157014-9615-3-git-send-email-ks.giri@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]
On Wed, Mar 13, 2013 at 12:13:31PM +0530, Girish K S wrote:
> Some SoC's that adopt this controller might not have have dma
> interface. This patch adds support for complete polling mode
> and gives flexibity for the user to select poll/dma mode.
Ouch, that sounds like a regression.
> @@ -419,6 +422,27 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
>
> cs = spi->controller_data;
> gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
> +
> + /* Start the signals */
> + writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
> +}
> +
This looks odd and not obviously related to the rest of the change -
does it belong as part of some of your other commits adding support for
using the controller /CS functionality? In general it feels like this
ought to be broken down a bit - there's some refactoring as well as the
new functionality.
> +static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
> + int timeout_ms)
> +{
> + void __iomem *regs = sdd->regs;
> + unsigned long val;
> + u32 status;
> + /* max fifo depth available */
> + u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
> +
> + val = msecs_to_loops(timeout_ms);
> + do {
> + status = readl(regs + S3C64XX_SPI_STATUS);
> + } while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
> +
> + /* return the actual received data length */
> + return RX_FIFO_LVL(status, sdd);
This is really wait_for_fifo_empty_with_timeout() isn't it? It feels
like there ought to be at least a cpu_relax() in the busy wait too.
> + /*
> + * If the receive length is bigger than the controller fifo
> + * size, calculate the loops and read the fifo as many times.
> + * loops = length / max fifo size (calculated by using the
> + * fifo mask).
> + * For any size less than the fifo size the below code is
> + * executed atleast once.
> + */
> + loops = xfer->len / ((FIFO_LVL_MASK(sdd) >> 1) + 1);
> + buf = xfer->rx_buf;
> + do{
Coding style.
> - if (!sdd->pdev->dev.of_node) {
> + if (!sdd->pdev->dev.of_node && !is_polling(sdd)) {
> res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> if (!res) {
> dev_err(&pdev->dev, "Unable to get SPI tx dma "
It seems like it'd be sensible to also handle failure to get the DMA
resource by going into polling mode.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 2/5] spi: s3c64xx: added support for polling mode
Date: Mon, 1 Apr 2013 14:12:07 +0100 [thread overview]
Message-ID: <20130401131207.GI18636@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1363157014-9615-3-git-send-email-ks.giri@samsung.com>
On Wed, Mar 13, 2013 at 12:13:31PM +0530, Girish K S wrote:
> Some SoC's that adopt this controller might not have have dma
> interface. This patch adds support for complete polling mode
> and gives flexibity for the user to select poll/dma mode.
Ouch, that sounds like a regression.
> @@ -419,6 +422,27 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
>
> cs = spi->controller_data;
> gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
> +
> + /* Start the signals */
> + writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
> +}
> +
This looks odd and not obviously related to the rest of the change -
does it belong as part of some of your other commits adding support for
using the controller /CS functionality? In general it feels like this
ought to be broken down a bit - there's some refactoring as well as the
new functionality.
> +static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
> + int timeout_ms)
> +{
> + void __iomem *regs = sdd->regs;
> + unsigned long val;
> + u32 status;
> + /* max fifo depth available */
> + u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
> +
> + val = msecs_to_loops(timeout_ms);
> + do {
> + status = readl(regs + S3C64XX_SPI_STATUS);
> + } while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
> +
> + /* return the actual received data length */
> + return RX_FIFO_LVL(status, sdd);
This is really wait_for_fifo_empty_with_timeout() isn't it? It feels
like there ought to be at least a cpu_relax() in the busy wait too.
> + /*
> + * If the receive length is bigger than the controller fifo
> + * size, calculate the loops and read the fifo as many times.
> + * loops = length / max fifo size (calculated by using the
> + * fifo mask).
> + * For any size less than the fifo size the below code is
> + * executed atleast once.
> + */
> + loops = xfer->len / ((FIFO_LVL_MASK(sdd) >> 1) + 1);
> + buf = xfer->rx_buf;
> + do{
Coding style.
> - if (!sdd->pdev->dev.of_node) {
> + if (!sdd->pdev->dev.of_node && !is_polling(sdd)) {
> res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> if (!res) {
> dev_err(&pdev->dev, "Unable to get SPI tx dma "
It seems like it'd be sensible to also handle failure to get the DMA
resource by going into polling mode.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130401/ff4ab212/attachment.sig>
next prev parent reply other threads:[~2013-04-01 13:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 6:43 [PATCH V3 0/5] Add polling support for 64xx spi controller Girish K S
2013-03-13 6:43 ` Girish K S
2013-03-13 6:43 ` Girish K S
[not found] ` <1363157014-9615-1-git-send-email-ks.giri-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-03-13 6:43 ` [PATCH V3 1/5] spi: s3c64xx: modified error interrupt handling and init Girish K S
2013-03-13 6:43 ` Girish K S
2013-03-13 6:43 ` Girish K S
2013-04-01 13:03 ` Mark Brown
2013-04-01 13:03 ` Mark Brown
2013-03-13 6:43 ` [PATCH V3 2/5] spi: s3c64xx: added support for polling mode Girish K S
2013-03-13 6:43 ` Girish K S
2013-03-13 6:43 ` Girish K S
2013-04-01 13:12 ` Mark Brown [this message]
2013-04-01 13:12 ` Mark Brown
2013-04-03 11:30 ` Girish KS
2013-04-03 11:30 ` Girish KS
2013-04-03 11:49 ` Mark Brown
2013-04-03 11:49 ` Mark Brown
[not found] ` <20130403114935.GA11305-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2013-04-04 5:45 ` Girish KS
2013-04-04 5:45 ` Girish KS
2013-04-04 5:45 ` Girish KS
2013-03-13 6:43 ` [PATCH V3 3/5] spi: s3c64xx: Added provision for non-gpio i/o's Girish K S
2013-03-13 6:43 ` Girish K S
2013-03-13 6:43 ` Girish K S
2013-03-13 6:43 ` [PATCH V3 4/5] spi: s3c64xx: Added provision for dedicated cs pin Girish K S
2013-03-13 6:43 ` Girish K S
2013-03-13 6:43 ` Girish K S
2013-04-01 12:57 ` Mark Brown
2013-04-01 12:57 ` Mark Brown
2013-04-08 9:51 ` Girish KS
2013-04-08 9:51 ` Girish KS
2013-04-08 10:15 ` Mark Brown
2013-04-08 10:15 ` Mark Brown
2013-04-08 11:45 ` Girish KS
2013-04-08 11:45 ` Girish KS
2013-04-08 11:52 ` Girish KS
2013-04-08 11:52 ` Girish KS
2013-04-08 12:20 ` Mark Brown
2013-04-08 12:20 ` Mark Brown
2013-04-08 13:49 ` Girish KS
2013-04-08 13:49 ` Girish KS
2013-04-09 10:34 ` Mark Brown
2013-04-09 10:34 ` Mark Brown
2013-03-13 6:43 ` [PATCH V3 5/5] spi: s3c64xx: Added support for exynos5440 spi Girish K S
2013-03-13 6:43 ` Girish K S
2013-03-13 6:43 ` Girish K S
2013-03-25 3:27 ` [PATCH V3 0/5] Add polling support for 64xx spi controller Girish KS
2013-03-25 3:27 ` Girish KS
2013-03-25 3:27 ` Girish KS
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=20130401131207.GI18636@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=girishks2000@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=spi-devel-general@lists.sourceforge.net \
--cc=t.figa@samsung.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.