| Message ID | 1385451313-1875-3-git-send-email-sourav.poddar@ti.com |
|---|---|
| State | Not Applicable |
| Headers | show |
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.
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?).
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.
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 ?
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 --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;
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(-)