Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Fri, 7 Dec 2012 12:41:41 +0900, Mark Brown wrote: > On Thu, Dec 06, 2012 at 02:04:27PM +, Grant Likely wrote: > > > Alright, applied. I've also merged in your spi-next tree. Let me know if > > that causes problems because it needs to be rebased. > > No problem - do you just want to take over the SPI tree again or should > I carry on applying things? Yes, please keep doing what you're doing! It's a huge help. Whenever I sit down to do patch maintenance, I'll pull in your tree first. As long as your tree doesn't get rebased then that should work well. I also promise to not rebase my tree without talking to you first so you can pull in mine before applying more patches on top. It's a huge help to be reading through the mailing list and be able to ignore any messages that I've seen you've already replied to or applied. g. -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Fri, 7 Dec 2012 12:41:41 +0900, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Dec 06, 2012 at 02:04:27PM +, Grant Likely wrote: Alright, applied. I've also merged in your spi-next tree. Let me know if that causes problems because it needs to be rebased. No problem - do you just want to take over the SPI tree again or should I carry on applying things? Yes, please keep doing what you're doing! It's a huge help. Whenever I sit down to do patch maintenance, I'll pull in your tree first. As long as your tree doesn't get rebased then that should work well. I also promise to not rebase my tree without talking to you first so you can pull in mine before applying more patches on top. It's a huge help to be reading through the mailing list and be able to ignore any messages that I've seen you've already replied to or applied. g. -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Thu, Dec 06, 2012 at 02:04:27PM +, Grant Likely wrote: > Alright, applied. I've also merged in your spi-next tree. Let me know if > that causes problems because it needs to be rebased. No problem - do you just want to take over the SPI tree again or should I carry on applying things? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Thu, 6 Dec 2012 14:37:33 +0900, Mark Brown wrote: > On Thu, Dec 06, 2012 at 12:00:26AM +, Grant Likely wrote: > > > Looks good to me. Probably 3.9 material though. > > > Acked-by: Grant Likely > > Hrm, I'd be inclined to apply it now - it's isolated enough that it can > be reverted if it explodes and we have the -rc cycle to notice any > problems. Alright, applied. I've also merged in your spi-next tree. Let me know if that causes problems because it needs to be rebased. g. -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Thu, 6 Dec 2012 14:37:33 +0900, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Dec 06, 2012 at 12:00:26AM +, Grant Likely wrote: Looks good to me. Probably 3.9 material though. Acked-by: Grant Likely grant.lik...@secretlab.ca Hrm, I'd be inclined to apply it now - it's isolated enough that it can be reverted if it explodes and we have the -rc cycle to notice any problems. Alright, applied. I've also merged in your spi-next tree. Let me know if that causes problems because it needs to be rebased. g. -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Thu, Dec 06, 2012 at 02:04:27PM +, Grant Likely wrote: Alright, applied. I've also merged in your spi-next tree. Let me know if that causes problems because it needs to be rebased. No problem - do you just want to take over the SPI tree again or should I carry on applying things? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Thu, Dec 06, 2012 at 12:00:26AM +, Grant Likely wrote: > Looks good to me. Probably 3.9 material though. > Acked-by: Grant Likely Hrm, I'd be inclined to apply it now - it's isolated enough that it can be reverted if it explodes and we have the -rc cycle to notice any problems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Sun, 2 Dec 2012 12:54:25 +0900, Mark Brown
wrote:
> In order to avoid constantly allocating and deallocating there is a fixed
> buffer which spi_write_then_read() uses for transfers, with an early error
> check to ensure that the transfer fits within the buffer. This limits the
> size of transfers to this size, currently max(32, SMP_CACHE_BYTES).
>
> Since we can dynamically allocate and in fact already have a fallback
> to do so when there is contention for the fixed buffer remove this
> restriction and instead dynamically allocate a suitably sized buffer if
> the transfer won't fit.
>
> Signed-off-by: Mark Brown
Looks good to me. Probably 3.9 material though.
Acked-by: Grant Likely
> ---
> drivers/spi/spi.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index c4f7d71..224b7bc 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1646,12 +1646,18 @@ int spi_write_then_read(struct spi_device *spi,
> struct spi_transfer x[2];
> u8 *local_buf;
>
> - /* Use preallocated DMA-safe buffer. We can't avoid copying here,
> - * (as a pure convenience thing), but we can keep heap costs
> - * out of the hot path ...
> + /* Use preallocated DMA-safe buffer if we can. We can't avoid
> + * copying here, (as a pure convenience thing), but we can
> + * keep heap costs out of the hot path unless someone else is
> + * using the pre-allocated buffer or the transfer is too large.
>*/
> - if ((n_tx + n_rx) > SPI_BUFSIZ)
> - return -EINVAL;
> + if ((n_tx + n_rx) > SPI_BUFSIZ || !mutex_trylock()) {
> + local_buf = kmalloc(max(SPI_BUFSIZ, n_tx + n_rx), GFP_KERNEL);
> + if (!local_buf)
> + return -ENOMEM;
> + } else {
> + local_buf = buf;
> + }
>
> spi_message_init();
> memset(x, 0, sizeof x);
> @@ -1664,14 +1670,6 @@ int spi_write_then_read(struct spi_device *spi,
> spi_message_add_tail([1], );
> }
>
> - /* ... unless someone else is using the pre-allocated buffer */
> - if (!mutex_trylock()) {
> - local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
> - if (!local_buf)
> - return -ENOMEM;
> - } else
> - local_buf = buf;
> -
> memcpy(local_buf, txbuf, n_tx);
> x[0].tx_buf = local_buf;
> x[1].rx_buf = local_buf + n_tx;
> --
> 1.7.10.4
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Sun, 2 Dec 2012 12:54:25 +0900, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
In order to avoid constantly allocating and deallocating there is a fixed
buffer which spi_write_then_read() uses for transfers, with an early error
check to ensure that the transfer fits within the buffer. This limits the
size of transfers to this size, currently max(32, SMP_CACHE_BYTES).
Since we can dynamically allocate and in fact already have a fallback
to do so when there is contention for the fixed buffer remove this
restriction and instead dynamically allocate a suitably sized buffer if
the transfer won't fit.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
Looks good to me. Probably 3.9 material though.
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/spi/spi.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index c4f7d71..224b7bc 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1646,12 +1646,18 @@ int spi_write_then_read(struct spi_device *spi,
struct spi_transfer x[2];
u8 *local_buf;
- /* Use preallocated DMA-safe buffer. We can't avoid copying here,
- * (as a pure convenience thing), but we can keep heap costs
- * out of the hot path ...
+ /* Use preallocated DMA-safe buffer if we can. We can't avoid
+ * copying here, (as a pure convenience thing), but we can
+ * keep heap costs out of the hot path unless someone else is
+ * using the pre-allocated buffer or the transfer is too large.
*/
- if ((n_tx + n_rx) SPI_BUFSIZ)
- return -EINVAL;
+ if ((n_tx + n_rx) SPI_BUFSIZ || !mutex_trylock(lock)) {
+ local_buf = kmalloc(max(SPI_BUFSIZ, n_tx + n_rx), GFP_KERNEL);
+ if (!local_buf)
+ return -ENOMEM;
+ } else {
+ local_buf = buf;
+ }
spi_message_init(message);
memset(x, 0, sizeof x);
@@ -1664,14 +1670,6 @@ int spi_write_then_read(struct spi_device *spi,
spi_message_add_tail(x[1], message);
}
- /* ... unless someone else is using the pre-allocated buffer */
- if (!mutex_trylock(lock)) {
- local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
- if (!local_buf)
- return -ENOMEM;
- } else
- local_buf = buf;
-
memcpy(local_buf, txbuf, n_tx);
x[0].tx_buf = local_buf;
x[1].rx_buf = local_buf + n_tx;
--
1.7.10.4
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
On Thu, Dec 06, 2012 at 12:00:26AM +, Grant Likely wrote: Looks good to me. Probably 3.9 material though. Acked-by: Grant Likely grant.lik...@secretlab.ca Hrm, I'd be inclined to apply it now - it's isolated enough that it can be reverted if it explodes and we have the -rc cycle to notice any problems. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
In order to avoid constantly allocating and deallocating there is a fixed
buffer which spi_write_then_read() uses for transfers, with an early error
check to ensure that the transfer fits within the buffer. This limits the
size of transfers to this size, currently max(32, SMP_CACHE_BYTES).
Since we can dynamically allocate and in fact already have a fallback
to do so when there is contention for the fixed buffer remove this
restriction and instead dynamically allocate a suitably sized buffer if
the transfer won't fit.
Signed-off-by: Mark Brown
---
drivers/spi/spi.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index c4f7d71..224b7bc 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1646,12 +1646,18 @@ int spi_write_then_read(struct spi_device *spi,
struct spi_transfer x[2];
u8 *local_buf;
- /* Use preallocated DMA-safe buffer. We can't avoid copying here,
-* (as a pure convenience thing), but we can keep heap costs
-* out of the hot path ...
+ /* Use preallocated DMA-safe buffer if we can. We can't avoid
+* copying here, (as a pure convenience thing), but we can
+* keep heap costs out of the hot path unless someone else is
+* using the pre-allocated buffer or the transfer is too large.
*/
- if ((n_tx + n_rx) > SPI_BUFSIZ)
- return -EINVAL;
+ if ((n_tx + n_rx) > SPI_BUFSIZ || !mutex_trylock()) {
+ local_buf = kmalloc(max(SPI_BUFSIZ, n_tx + n_rx), GFP_KERNEL);
+ if (!local_buf)
+ return -ENOMEM;
+ } else {
+ local_buf = buf;
+ }
spi_message_init();
memset(x, 0, sizeof x);
@@ -1664,14 +1670,6 @@ int spi_write_then_read(struct spi_device *spi,
spi_message_add_tail([1], );
}
- /* ... unless someone else is using the pre-allocated buffer */
- if (!mutex_trylock()) {
- local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
- if (!local_buf)
- return -ENOMEM;
- } else
- local_buf = buf;
-
memcpy(local_buf, txbuf, n_tx);
x[0].tx_buf = local_buf;
x[1].rx_buf = local_buf + n_tx;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()
In order to avoid constantly allocating and deallocating there is a fixed
buffer which spi_write_then_read() uses for transfers, with an early error
check to ensure that the transfer fits within the buffer. This limits the
size of transfers to this size, currently max(32, SMP_CACHE_BYTES).
Since we can dynamically allocate and in fact already have a fallback
to do so when there is contention for the fixed buffer remove this
restriction and instead dynamically allocate a suitably sized buffer if
the transfer won't fit.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/spi/spi.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index c4f7d71..224b7bc 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1646,12 +1646,18 @@ int spi_write_then_read(struct spi_device *spi,
struct spi_transfer x[2];
u8 *local_buf;
- /* Use preallocated DMA-safe buffer. We can't avoid copying here,
-* (as a pure convenience thing), but we can keep heap costs
-* out of the hot path ...
+ /* Use preallocated DMA-safe buffer if we can. We can't avoid
+* copying here, (as a pure convenience thing), but we can
+* keep heap costs out of the hot path unless someone else is
+* using the pre-allocated buffer or the transfer is too large.
*/
- if ((n_tx + n_rx) SPI_BUFSIZ)
- return -EINVAL;
+ if ((n_tx + n_rx) SPI_BUFSIZ || !mutex_trylock(lock)) {
+ local_buf = kmalloc(max(SPI_BUFSIZ, n_tx + n_rx), GFP_KERNEL);
+ if (!local_buf)
+ return -ENOMEM;
+ } else {
+ local_buf = buf;
+ }
spi_message_init(message);
memset(x, 0, sizeof x);
@@ -1664,14 +1670,6 @@ int spi_write_then_read(struct spi_device *spi,
spi_message_add_tail(x[1], message);
}
- /* ... unless someone else is using the pre-allocated buffer */
- if (!mutex_trylock(lock)) {
- local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
- if (!local_buf)
- return -ENOMEM;
- } else
- local_buf = buf;
-
memcpy(local_buf, txbuf, n_tx);
x[0].tx_buf = local_buf;
x[1].rx_buf = local_buf + n_tx;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
