diff mbox

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

Message ID 1385451313-1875-3-git-send-email-sourav.poddar@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Poddar, Sourav Nov. 26, 2013, 7:34 a.m. UTC
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.poddar@ti.com>
---
 include/linux/spi/spi.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

Comments

Mark Brown Nov. 26, 2013, 10:29 a.m. UTC | #1
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.
Poddar, Sourav Nov. 26, 2013, 11:21 a.m. UTC | #2
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown Nov. 26, 2013, 12:21 p.m. UTC | #3
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.
Poddar, Sourav Nov. 28, 2013, 4:47 a.m. UTC | #4
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown Nov. 28, 2013, 10:55 a.m. UTC | #5
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.
diff mbox

Patch

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;