Re: [PATCH 02/17] spi/spi.h: Add configure from slave support.

2013-11-28 Thread Mark Brown
On Thu, Nov 28, 2013 at 10:17:38AM +0530, Sourav Poddar wrote:
 On Tuesday 26 November 2013 05:51 PM, Mark Brown wrote:

 The name isn't the issue, it's the fact that you're passing a completely
 unspecified blob of data.

 May be, what you are suggesting here is to we should define a flash
 information
 structure and should pass that structure here ?

Possibly, that's definitely moving towards adding more structure.


signature.asc
Description: Digital signature


Re: [PATCH 02/17] spi/spi.h: Add configure from slave support.

2013-11-27 Thread Sourav Poddar

On Tuesday 26 November 2013 05:51 PM, Mark Brown wrote:

On Tue, Nov 26, 2013 at 04:51:53PM +0530, Sourav Poddar wrote:

On Tuesday 26 November 2013 03:59 PM, Mark Brown wrote:

+   void(*configure_from_slave)(struct spi_device *spi, u8 *val);

Clearly this is far too unstructured to be useful, this is only ever
going to work with one specific combination of slave and master since
there's absolutely no semantics defined.

I thought val might be good enuf, and this can be filled with whatever
data that need to be used from slave into master(irrespective of
slave and master?).

The name isn't the issue, it's the fact that you're passing a completely
unspecified blob of data.
May be, what you are suggesting here is to we should define a flash 
information

structure and should pass that structure here ?

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 02/17] spi/spi.h: Add configure from slave support.

2013-11-26 Thread Mark Brown
On Tue, Nov 26, 2013 at 01:04:58PM +0530, Sourav Poddar wrote:

   void(*get_buf)(struct spi_master *master);
   void(*put_buf)(struct spi_master *master);
 + void(*configure_from_slave)(struct spi_device *spi, u8 *val);

Clearly this is far too unstructured to be useful, this is only ever
going to work with one specific combination of slave and master since
there's absolutely no semantics defined.


signature.asc
Description: Digital signature


Re: [PATCH 02/17] spi/spi.h: Add configure from slave support.

2013-11-26 Thread Sourav Poddar

On Tuesday 26 November 2013 03:59 PM, Mark Brown wrote:

On Tue, Nov 26, 2013 at 01:04:58PM +0530, Sourav Poddar wrote:


void(*get_buf)(struct spi_master *master);
void(*put_buf)(struct spi_master *master);
+   void(*configure_from_slave)(struct spi_device *spi, u8 *val);

Clearly this is far too unstructured to be useful, this is only ever
going to work with one specific combination of slave and master since
there's absolutely no semantics defined.

I thought val might be good enuf, and this can be filled with whatever
data that need to be used from slave into master(irrespective of slave 
and master?).


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 02/17] spi/spi.h: Add configure from slave support.

2013-11-26 Thread Mark Brown
On Tue, Nov 26, 2013 at 04:51:53PM +0530, Sourav Poddar wrote:
 On Tuesday 26 November 2013 03:59 PM, Mark Brown wrote:

 +   void(*configure_from_slave)(struct spi_device *spi, u8 *val);

 Clearly this is far too unstructured to be useful, this is only ever
 going to work with one specific combination of slave and master since
 there's absolutely no semantics defined.

 I thought val might be good enuf, and this can be filled with whatever
 data that need to be used from slave into master(irrespective of
 slave and master?).

The name isn't the issue, it's the fact that you're passing a completely
unspecified blob of data.


signature.asc
Description: Digital signature


[PATCH 02/17] spi/spi.h: Add configure from slave support.

2013-11-25 Thread Sourav Poddar
There are few use cases encountered where the master controller
depends on the slave parameters for some of its register
configure. Add an api in spi master which can be used to enable the
above feature.

Typical usecase encountered till now is
- ti qspi controller required flash opcodes to configure its set up
   register for memory mapped operations.

There was another discussion on some LUT registers for some other
qspi controller in mailing list, these feature can also be used for
that case also.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
 include/linux/spi/spi.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 3b3743d..4be969a 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -295,6 +295,9 @@ static inline void spi_unregister_driver(struct spi_driver 
*sdrv)
  *   know the address to be used for memcopy.
  * @put_buf: Used for memory mapped cases after get_buf, after the memcpy
  *   has finished.
+ * @configure_from_slave: Used when SPI controller has registers which need
+ *  to be configured from slave specifics information(typical use case for
+ *  SPI flash device).
  * Each SPI master controller can communicate with one or more @spi_device
  * children.  These make a small bus, sharing MOSI, MISO and SCK signals
  * but not chip select signals.  Each device may be configured to use a
@@ -427,6 +430,7 @@ struct spi_master {
 
void(*get_buf)(struct spi_master *master);
void(*put_buf)(struct spi_master *master);
+   void(*configure_from_slave)(struct spi_device *spi, u8 *val);
 
/* gpio chip select */
int *cs_gpios;
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html