| Message ID | 1385451313-1875-10-git-send-email-sourav.poddar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Nov 26, 2013 at 01:05:05PM +0530, Sourav Poddar wrote: > Add "mem" variable in spi_master, which can be used to hold on the > memory mapped address. Is this really generic enough to put here rather than in the driver data?
On Tuesday 26 November 2013 06:31 PM, Mark Brown wrote: > On Tue, Nov 26, 2013 at 01:05:05PM +0530, Sourav Poddar wrote: >> Add "mem" variable in spi_master, which can be used to hold on the >> memory mapped address. > Is this really generic enough to put here rather than in the driver > data? The thought behind this was that if a master controller supports memory mapped operation and slave wants to use memcpy in his driver(bypassing spi ), then we should have a mean to communicate between the master and the slave. So, 'spi_master' seems to be the place for me for this data, which could be parsed in the slave side also. -- 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
On Tue, Nov 26, 2013 at 06:35:35PM +0530, Sourav Poddar wrote: > On Tuesday 26 November 2013 06:31 PM, Mark Brown wrote: > >Is this really generic enough to put here rather than in the driver > >data? > The thought behind this was that if a master controller supports > memory mapped operation and slave wants to use memcpy in his > driver(bypassing spi ), then we should have a mean to communicate > between the > master and the slave. So, 'spi_master' seems to be the place for me > for this data, > which could be parsed in the slave side also. I would have expected that the address would be returned by the function that maps the buffer in rather than stored permanently in the master.
On Tuesday 26 November 2013 06:50 PM, Mark Brown wrote: > On Tue, Nov 26, 2013 at 06:35:35PM +0530, Sourav Poddar wrote: >> On Tuesday 26 November 2013 06:31 PM, Mark Brown wrote: >>> Is this really generic enough to put here rather than in the driver >>> data? >> The thought behind this was that if a master controller supports >> memory mapped operation and slave wants to use memcpy in his >> driver(bypassing spi ), then we should have a mean to communicate >> between the >> master and the slave. So, 'spi_master' seems to be the place for me >> for this data, >> which could be parsed in the slave side also. > I would have expected that the address would be returned by the function > that maps the buffer in rather than stored permanently in the master. Yes, it could be be done the above way. I will change. -- 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
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 4be969a..72565ff 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -298,6 +298,7 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) * @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). + * @mem: memory mapped address to be filled by master controller driver. * 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 @@ -432,6 +433,8 @@ struct spi_master { void (*put_buf)(struct spi_master *master); void (*configure_from_slave)(struct spi_device *spi, u8 *val); + void __iomem *mem; + /* gpio chip select */ int *cs_gpios; };
Add "mem" variable in spi_master, which can be used to hold on the memory mapped address. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> --- include/linux/spi/spi.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)