Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

2012-12-07 Thread Grant Likely 
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.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

2012-12-06 Thread Grant Likely 
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.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

2012-12-06 Thread Mark Brown 
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?

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

2012-12-05 Thread Grant Likely 
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.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

2012-12-05 Thread Mark Brown 
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.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi: Remove SPI_BUFSIZ restriction on spi_write_then_read()

2012-12-01 Thread Mark Brown 
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


--
Keep yourself connected to Go Parallel: 
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general