RE: [PATCH v5 00/14] GPMC driver conversion
Hi Tony, On Wed, Jun 13, 2012 at 18:03:05, Tony Lindgren wrote: Cool, yeah looks like the old interface almost works. I had to undo the new additions for tusb6010 DMA to work as below. Then Jon has some good comments. I also made few comments to the GPMC using driver changes. Thanks and sorry for the trouble it caused you I will post next version based on the comments In general, please keep in mind that eventually we want this to be a regular device driver that also works as a loadable module. Yes, that is my intention, at the end of driver conversion, it should be able to work as a module. And we need the device tree bindings for GPMC so we can start dropping board-*.c files as the GPMC seems to be last remaining blocker for making rarely used legacy boards DT only. So it might be worth playing with that so we don't again have to redo some parts. We would prefer to do it one step at a time, have driver conversion changes first in, and then work on DT migration. Once these changes are in we have a base to work on for further DT migration. Please let me know your opinion Regards Afzal -- 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 v5 00/14] GPMC driver conversion
* Mohammed, Afzal af...@ti.com [120615 04:00]: On Wed, Jun 13, 2012 at 18:03:05, Tony Lindgren wrote: And we need the device tree bindings for GPMC so we can start dropping board-*.c files as the GPMC seems to be last remaining blocker for making rarely used legacy boards DT only. So it might be worth playing with that so we don't again have to redo some parts. We would prefer to do it one step at a time, have driver conversion changes first in, and then work on DT migration. Once these changes are in we have a base to work on for further DT migration. Please let me know your opinion Sounds good to me. Tony -- 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 v5 00/14] GPMC driver conversion
* Mohammed, Afzal af...@ti.com [120612 03:44]:
Hi Tony,
On Mon, Jun 11, 2012 at 19:55:02, Mohammed, Afzal wrote:
Hi,
This series is based on 3.5-rc1, and is dependent on [1,2,3]
This series has been tested on omap3evm (smsc911x) rev G C and
beagle board(nand) using patch series which is going to be posted
shortly (this series only creates a driver out of GPMC code)
Also using private patches, nand onenand was tested on omap3evm,
rev G C respectively (as support for these were not in mainline)
Many of GPMC peripherals depend on bootloader for configuration.
This is going to be deprecated. feature-removal-schedule.txt will be
updated in one of the upcoming patch series regarding the same.
[PATCH 03/13] ARM: OMAP2+: gpmc: driver migration helper, is to be
reverted once all GPMC peripherals are migrated to use driver
interface.
Please let me know your comments on this series. I had tried to
go as per your requirements.
This series keeps old interface while providing a new driver interface.
Old interface will work (to the best of my knowledge; omap3evm
beagle are the ones available here to test) at each of the commits.
Cool, yeah looks like the old interface almost works. I had to undo the
new additions for tusb6010 DMA to work as below. Then Jon has some good
comments. I also made few comments to the GPMC using driver changes.
In general, please keep in mind that eventually we want this to be
a regular device driver that also works as a loadable module.
And we need the device tree bindings for GPMC so we can start dropping
board-*.c files as the GPMC seems to be last remaining blocker for
making rarely used legacy boards DT only. So it might be worth
playing with that so we don't again have to redo some parts.
Regards,
Tony
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -363,13 +363,13 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 16, 20, access);
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
-
+#if 0
GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
-
+#endif
if (cpu_is_omap34xx()) {
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
--
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 v5 00/14] GPMC driver conversion
Hi Tony, On Mon, Jun 11, 2012 at 19:55:02, Mohammed, Afzal wrote: Hi, This series is based on 3.5-rc1, and is dependent on [1,2,3] This series has been tested on omap3evm (smsc911x) rev G C and beagle board(nand) using patch series which is going to be posted shortly (this series only creates a driver out of GPMC code) Also using private patches, nand onenand was tested on omap3evm, rev G C respectively (as support for these were not in mainline) Many of GPMC peripherals depend on bootloader for configuration. This is going to be deprecated. feature-removal-schedule.txt will be updated in one of the upcoming patch series regarding the same. [PATCH 03/13] ARM: OMAP2+: gpmc: driver migration helper, is to be reverted once all GPMC peripherals are migrated to use driver interface. Please let me know your comments on this series. I had tried to go as per your requirements. This series keeps old interface while providing a new driver interface. Old interface will work (to the best of my knowledge; omap3evm beagle are the ones available here to test) at each of the commits. Regards Afzal -- 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
[PATCH v5 00/14] GPMC driver conversion
Hi, This series is based on 3.5-rc1, and is dependent on [1,2,3] This series has been tested on omap3evm (smsc911x) rev G C and beagle board(nand) using patch series which is going to be posted shortly (this series only creates a driver out of GPMC code) Also using private patches, nand onenand was tested on omap3evm, rev G C respectively (as support for these were not in mainline) Many of GPMC peripherals depend on bootloader for configuration. This is going to be deprecated. feature-removal-schedule.txt will be updated in one of the upcoming patch series regarding the same. [PATCH 03/13] ARM: OMAP2+: gpmc: driver migration helper, is to be reverted once all GPMC peripherals are migrated to use driver interface. GPMC (General Purpose Memory Controller) in brief: GPMC is an unified memory controller dedicated to interfacing external memory devices like Asynchronous SRAM like memories and application specific integrated circuit devices. Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash Pseudo-SRAM devices GPMC details can be referred in AM335X Technical Reference Manual @ http://www.ti.com/lit/pdf/spruh73 Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69891.html v5: Make this a purely driver conversion series, i.e. gpmc-mtd interactions has been made as a separate series, so is adding hwmod entry for OMAP2/3. And modifying gpmc peripheral platform initialization has been separated out of this series, so is migrating boards to use new driver interface. GPMC driver conversion which was done in a few patches in v4 has been tranformed to series of small patches. Also care has been taken care that old interface will not break with any of these patches, so both interfaces can coexist. This helps in converting boards one-by-one gradually. Acquiring CS has been thrown out. And conclusive comments on v4 has been addressed. v4: Handle wait pin (except for interrupts), enhance configuration timing interface of GPMC to take care of all boards. Dynamic allocation of interrupt instead of static. Convert remaining peripherals to work with GPMC driver. Handle acquiring NAND CS#, adapt to HWMOD, update HWMOD OMAP2/3 entries, other minor commenst on v3. v3: Single device structure passed from platform for peripherals using multiple CS instead of using multiple device structure having a few redundant data, handle interrupts, GPMC NAND handling by GPMC NAND driver instead of GPMC driver v2: Avoid code movement that kept similar code together (for easy review) Afzal Mohammed (14): ARM: OMAP2+: gpmc: platform definitions ARM: OMAP2+: gpmc: Adapt to HWMOD ARM: OMAP2+: gpmc: driver migration helper ARM: OMAP2+: gpmc: minimal driver support ARM: OMAP2+: gpmc: resource creation helpers ARM: OMAP2+: gpmc: CS configuration helper ARM: OMAP2+: gpmc: time setting (register#) helper ARM: OMAP2+: gpmc: bool type timing helper ARM: OMAP2+: gpmc: holler if no configuration ARM: OMAP2+: gpmc: waitpin helper ARM: OMAP2+: gpmc: handle connected peripherals ARM: OMAP2+: gpmc: cs reconfigure helper ARM: OMAP2+: gpmc: update nand register info ARM: OMAP2+: gpmc: writeprotect helper arch/arm/mach-omap2/gpmc.c | 817 ++-- arch/arm/plat-omap/include/plat/gpmc.h | 68 +++ 2 files changed, 842 insertions(+), 43 deletions(-) -- 1.7.10.2 -- 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
