Re: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Wed, Dec 11, 2013 at 11:44:22AM +0100, Marek Vasut wrote: > On Wednesday, December 11, 2013 at 05:18:45 AM, Sourav Poddar wrote: > > I did a quad mode support for m25p80 which easily got cloned into the > > new spi framework. > > Same can be done for the memory mapped support too > The quad mode didn't need any new hooks in the m25p80, did it ? That's the > difference here. It did, there's explicit code in the flash driver for it. However it's rather more generic than this. signature.asc Description: Digital signature
Re: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Wednesday, December 11, 2013 at 05:18:45 AM, Sourav Poddar wrote: > Hi Marek, > > On Tuesday 10 December 2013 06:19 PM, Marek Vasut wrote: > > On Friday, December 06, 2013 at 03:24:41 PM, Sourav Poddar wrote: > >> The patch series aims to add memory mapped support for TI qspi > >> contoller and also add support for the same in serial flash > >> driver(m25p80). > > > > My question is, shall we not wait for the new SPI NOR framework to be > > well fleshed out and only then implement this controller driver on top > > of it ? > > I think it will still take lot of time for spi framework to come to > alignment > and get merged in the mainline. Till then, m25p80 development should > go on independently. Once, the spi framework is ready, I can myself port > this into the new framework. Sure, but I also think Huang is coming close to the new framework. Have you seen his latest patchset ( Message-ID: <1386318764-15882-1-git-send-email- b32...@freescale.com> ) ? I think you two should really start working on the new framework instead of bending drivers all around. > > I have a feeling this patchset adds quite a lot of ad-hoc hacks into the > > m25p80 driver, which would become dead code once converted to the SPI > > NOR framework. > > I dont think that spi framework till now provides capabilities which can > be used > to handle memory mapped cases. Not yet, so please bring it up in the discussion there :) > I did a quad mode support for m25p80 which easily got cloned into the > new spi framework. > Same can be done for the memory mapped support too The quad mode didn't need any new hooks in the m25p80, did it ? That's the difference here. Best regards, Marek Vasut -- 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: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
Hi Mark,
On Tuesday 10 December 2013 11:59 PM, Mark Brown wrote:
On Tue, Dec 10, 2013 at 07:22:10PM +0100, Marek Vasut wrote:
On Tuesday, December 10, 2013 at 05:11:43 PM, Mark Brown wrote:
There is some stuff that pushes up into the controller in that while the
device is in memory mapped mode as far as I can tell it's not safe to do
other accesses so if someone's put more than one device on the SPI bus
we need to handle interactions there.
OK, so it's either-or . That seems OK, you might want to have two drivers for
this ip block, one to handle it as a SPI block and one to handle it as a SPI-NOR
block. ... that is of course, if these two modes can't work together.
Or the client disables the memory map when it's not actively being used
and the stops other transfers starting while the mapping is in place.
I'd expect we'll have to cope with shared use at some point, hardware
engineers will probably build such systems.
So, what I am doing here in my code is that whenever I desired to use a
mmap operations I do a
a. flash_lock()
b. wait till the previous erase/write is finished
c. 'get_buf' which in turn does
- get_sync
- enable memory mapped
d. memcpy
e. 'put_buf' which in turn does
- disable memory mapped
- put_sync
f. flash_unlock
Do you see any point missing here?
On your comment about disabling transfers while doing a mmap..
Are you suggesting on having a check in qspi transfer api something like
this..
transfer_one_message {
if (mmap)
return -EINPROGRESS;
}
Where mmap can be set/unset in get_buf/put_buf respectively.
--
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: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Tuesday 10 December 2013 11:52 PM, Marek Vasut wrote: On Tuesday, December 10, 2013 at 05:11:43 PM, Mark Brown wrote: On Tue, Dec 10, 2013 at 01:49:13PM +0100, Marek Vasut wrote: My question is, shall we not wait for the new SPI NOR framework to be well fleshed out and only then implement this controller driver on top of it ? I have a feeling this patchset adds quite a lot of ad-hoc hacks into the m25p80 driver, which would become dead code once converted to the SPI NOR framework. There is some stuff that pushes up into the controller in that while the device is in memory mapped mode as far as I can tell it's not safe to do other accesses so if someone's put more than one device on the SPI bus we need to handle interactions there. OK, so it's either-or . That seems OK, you might want to have two drivers for this ip block, one to handle it as a SPI block and one to handle it as a SPI-NOR block. ... that is of course, if these two modes can't work together. the two modes cant work together. Best regards, Marek Vasut -- 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 -- 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: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
Hi Marek, On Tuesday 10 December 2013 06:19 PM, Marek Vasut wrote: On Friday, December 06, 2013 at 03:24:41 PM, Sourav Poddar wrote: The patch series aims to add memory mapped support for TI qspi contoller and also add support for the same in serial flash driver(m25p80). My question is, shall we not wait for the new SPI NOR framework to be well fleshed out and only then implement this controller driver on top of it ? I think it will still take lot of time for spi framework to come to alignment and get merged in the mainline. Till then, m25p80 development should go on independently. Once, the spi framework is ready, I can myself port this into the new framework. I have a feeling this patchset adds quite a lot of ad-hoc hacks into the m25p80 driver, which would become dead code once converted to the SPI NOR framework. I dont think that spi framework till now provides capabilities which can be used to handle memory mapped cases. I did a quad mode support for m25p80 which easily got cloned into the new spi framework. Same can be done for the memory mapped support too Best regards, Marek Vasut -- 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: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Tuesday, December 10, 2013 at 07:29:04 PM, Mark Brown wrote: > On Tue, Dec 10, 2013 at 07:22:10PM +0100, Marek Vasut wrote: > > On Tuesday, December 10, 2013 at 05:11:43 PM, Mark Brown wrote: > > > There is some stuff that pushes up into the controller in that while > > > the device is in memory mapped mode as far as I can tell it's not safe > > > to do other accesses so if someone's put more than one device on the > > > SPI bus we need to handle interactions there. > > > > OK, so it's either-or . That seems OK, you might want to have two drivers > > for this ip block, one to handle it as a SPI block and one to handle it > > as a SPI-NOR block. ... that is of course, if these two modes can't work > > together. > > Or the client disables the memory map when it's not actively being used > and the stops other transfers starting while the mapping is in place. > I'd expect we'll have to cope with shared use at some point, hardware > engineers will probably build such systems. Aren't we fixing the problem at the wrong place ? Maybe it's about time to fix the engineers ;-) Best regards, Marek Vasut -- 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: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Tue, Dec 10, 2013 at 07:22:10PM +0100, Marek Vasut wrote: > On Tuesday, December 10, 2013 at 05:11:43 PM, Mark Brown wrote: > > There is some stuff that pushes up into the controller in that while the > > device is in memory mapped mode as far as I can tell it's not safe to do > > other accesses so if someone's put more than one device on the SPI bus > > we need to handle interactions there. > OK, so it's either-or . That seems OK, you might want to have two drivers for > this ip block, one to handle it as a SPI block and one to handle it as a > SPI-NOR > block. ... that is of course, if these two modes can't work together. Or the client disables the memory map when it's not actively being used and the stops other transfers starting while the mapping is in place. I'd expect we'll have to cope with shared use at some point, hardware engineers will probably build such systems. signature.asc Description: Digital signature
Re: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Tuesday, December 10, 2013 at 05:11:43 PM, Mark Brown wrote: > On Tue, Dec 10, 2013 at 01:49:13PM +0100, Marek Vasut wrote: > > My question is, shall we not wait for the new SPI NOR framework to be > > well fleshed out and only then implement this controller driver on top > > of it ? > > > > I have a feeling this patchset adds quite a lot of ad-hoc hacks into the > > m25p80 driver, which would become dead code once converted to the SPI > > NOR framework. > > There is some stuff that pushes up into the controller in that while the > device is in memory mapped mode as far as I can tell it's not safe to do > other accesses so if someone's put more than one device on the SPI bus > we need to handle interactions there. OK, so it's either-or . That seems OK, you might want to have two drivers for this ip block, one to handle it as a SPI block and one to handle it as a SPI-NOR block. ... that is of course, if these two modes can't work together. Best regards, Marek Vasut -- 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: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Tue, Dec 10, 2013 at 01:49:13PM +0100, Marek Vasut wrote: > My question is, shall we not wait for the new SPI NOR framework to be well > fleshed out and only then implement this controller driver on top of it ? > I have a feeling this patchset adds quite a lot of ad-hoc hacks into the > m25p80 > driver, which would become dead code once converted to the SPI NOR framework. There is some stuff that pushes up into the controller in that while the device is in memory mapped mode as far as I can tell it's not safe to do other accesses so if someone's put more than one device on the SPI bus we need to handle interactions there. signature.asc Description: Digital signature
Re: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Friday, December 06, 2013 at 03:24:41 PM, Sourav Poddar wrote: > The patch series aims to add memory mapped support for TI qspi > contoller and also add support for the same in serial flash driver(m25p80). My question is, shall we not wait for the new SPI NOR framework to be well fleshed out and only then implement this controller driver on top of it ? I have a feeling this patchset adds quite a lot of ad-hoc hacks into the m25p80 driver, which would become dead code once converted to the SPI NOR framework. Best regards, Marek Vasut -- 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
[PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
The patch series aims to add memory mapped support for TI qspi contoller and also add support for the same in serial flash driver(m25p80). These feature was added as a part of the series[1]: The series[1] add support for quad and memory mapped feature in spi and flash driver. Based on Brian Norris suggestion on splitting the quad and memory mapped feature, I had sent a seperate series for quad support which has beed accepted by Brian. The $subject patch series takes care of the memory mapped part. Overview of memory mapped support in qspi: TI qspi controller supports memory mapped read support, switching to which requires register modifications(qspi registers, control module register for DRA, qspi register for am43x). Once switched, the flash data can be available at a soc specific memory mapped address. For operations in normal mode, we need to keep memory mapped disable. Flow of the patch is to keep the memory mapped enable by default in the driver. Whenever Normal spi mode operations are desired, we switch to configuration mode and at the end of it memory mapped is again enabled. There are few function pointers added to fecilitate easy communication between the flash and spi controllers. Major changes in the $subject patch based on discussion in [1]: - Feature has been broken down into small meaningfl patches. - memcpy is done in flash driver and spi framework is bypassed. - configuration of memory mapped spi controller regsiters is done through function calls from flash side. [1]: http://lists.infradead.org/pipermail/linux-mtd/2013-October/049058.html v1->v2: Mentioned on individual patches. Overall change is the squashing of few patches. v1: https://patchwork.kernel.org/patch/3237091/ Tested on DRA7 board with spansion S25FL256S flash along with some internal irq crossbar patches. Tested on AM437x epos evm with macronix MX66l51235l flash. Testing done: -Erase the whole flash. -write to the flash -read back the flash - compare the data Sourav Poddar (10): spi/spi.h: Add get_buf/put_buf support in spi master.. spi/qspi: parse register by name. spi/qspi: Add support to switc to memory mapped operation. spi/qspi: configure set up register for memory map.. spi/qspi: Add api for get_buf/put_buf. drivers: mtd: m25p80: Add api to configure master register. drivers: mtd: m25p80: Adapt driver to support memory mapped read. Documentation: bindings: ti-qspi: update binding information. arm: dts: dra7: Add qspi device. arm: dts: am43x-epos: Add qspi device. Documentation/devicetree/bindings/spi/ti_qspi.txt |8 +- arch/arm/boot/dts/am4372.dtsi | 12 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 28 + arch/arm/boot/dts/dra7-evm.dts| 32 + arch/arm/boot/dts/dra7.dtsi | 13 ++ drivers/mtd/devices/m25p80.c | 38 ++ drivers/spi/spi-ti-qspi.c | 130 - include/linux/spi/spi.h | 22 8 files changed, 280 insertions(+), 3 deletions(-) -- 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
