Afzal Mohammed | 246da26 | 2012-08-02 20:02:10 +0530 | [diff] [blame] | 1 | GPMC (General Purpose Memory Controller): |
| 2 | ========================================= |
| 3 | |
| 4 | GPMC is an unified memory controller dedicated to interfacing external |
| 5 | memory devices like |
| 6 | * Asynchronous SRAM like memories and application specific integrated |
| 7 | circuit devices. |
| 8 | * Asynchronous, synchronous, and page mode burst NOR flash devices |
| 9 | NAND flash |
| 10 | * Pseudo-SRAM devices |
| 11 | |
| 12 | GPMC is found on Texas Instruments SoC's (OMAP based) |
| 13 | IP details: http://www.ti.com/lit/pdf/spruh73 section 7.1 |
| 14 | |
| 15 | |
| 16 | GPMC generic timing calculation: |
| 17 | ================================ |
| 18 | |
| 19 | GPMC has certain timings that has to be programmed for proper |
| 20 | functioning of the peripheral, while peripheral has another set of |
| 21 | timings. To have peripheral work with gpmc, peripheral timings has to |
| 22 | be translated to the form gpmc can understand. The way it has to be |
| 23 | translated depends on the connected peripheral. Also there is a |
| 24 | dependency for certain gpmc timings on gpmc clock frequency. Hence a |
| 25 | generic timing routine was developed to achieve above requirements. |
| 26 | |
| 27 | Generic routine provides a generic method to calculate gpmc timings |
| 28 | from gpmc peripheral timings. struct gpmc_device_timings fields has to |
| 29 | be updated with timings from the datasheet of the peripheral that is |
| 30 | connected to gpmc. A few of the peripheral timings can be fed either |
| 31 | in time or in cycles, provision to handle this scenario has been |
| 32 | provided (refer struct gpmc_device_timings definition). It may so |
| 33 | happen that timing as specified by peripheral datasheet is not present |
| 34 | in timing structure, in this scenario, try to correlate peripheral |
| 35 | timing to the one available. If that doesn't work, try to add a new |
| 36 | field as required by peripheral, educate generic timing routine to |
| 37 | handle it, make sure that it does not break any of the existing. |
| 38 | Then there may be cases where peripheral datasheet doesn't mention |
| 39 | certain fields of struct gpmc_device_timings, zero those entries. |
| 40 | |
| 41 | Generic timing routine has been verified to work properly on |
| 42 | multiple onenand's and tusb6010 peripherals. |
| 43 | |
| 44 | A word of caution: generic timing routine has been developed based |
| 45 | on understanding of gpmc timings, peripheral timings, available |
| 46 | custom timing routines, a kind of reverse engineering without |
| 47 | most of the datasheets & hardware (to be exact none of those supported |
| 48 | in mainline having custom timing routine) and by simulation. |
| 49 | |
| 50 | gpmc timing dependency on peripheral timings: |
| 51 | [<gpmc_timing>: <peripheral timing1>, <peripheral timing2> ...] |
| 52 | |
| 53 | 1. common |
| 54 | cs_on: t_ceasu |
| 55 | adv_on: t_avdasu, t_ceavd |
| 56 | |
| 57 | 2. sync common |
| 58 | sync_clk: clk |
| 59 | page_burst_access: t_bacc |
| 60 | clk_activation: t_ces, t_avds |
| 61 | |
| 62 | 3. read async muxed |
| 63 | adv_rd_off: t_avdp_r |
| 64 | oe_on: t_oeasu, t_aavdh |
| 65 | access: t_iaa, t_oe, t_ce, t_aa |
| 66 | rd_cycle: t_rd_cycle, t_cez_r, t_oez |
| 67 | |
| 68 | 4. read async non-muxed |
| 69 | adv_rd_off: t_avdp_r |
| 70 | oe_on: t_oeasu |
| 71 | access: t_iaa, t_oe, t_ce, t_aa |
| 72 | rd_cycle: t_rd_cycle, t_cez_r, t_oez |
| 73 | |
| 74 | 5. read sync muxed |
| 75 | adv_rd_off: t_avdp_r, t_avdh |
| 76 | oe_on: t_oeasu, t_ach, cyc_aavdh_oe |
| 77 | access: t_iaa, cyc_iaa, cyc_oe |
| 78 | rd_cycle: t_cez_r, t_oez, t_ce_rdyz |
| 79 | |
| 80 | 6. read sync non-muxed |
| 81 | adv_rd_off: t_avdp_r |
| 82 | oe_on: t_oeasu |
| 83 | access: t_iaa, cyc_iaa, cyc_oe |
| 84 | rd_cycle: t_cez_r, t_oez, t_ce_rdyz |
| 85 | |
| 86 | 7. write async muxed |
| 87 | adv_wr_off: t_avdp_w |
| 88 | we_on, wr_data_mux_bus: t_weasu, t_aavdh, cyc_aavhd_we |
| 89 | we_off: t_wpl |
| 90 | cs_wr_off: t_wph |
| 91 | wr_cycle: t_cez_w, t_wr_cycle |
| 92 | |
| 93 | 8. write async non-muxed |
| 94 | adv_wr_off: t_avdp_w |
| 95 | we_on, wr_data_mux_bus: t_weasu |
| 96 | we_off: t_wpl |
| 97 | cs_wr_off: t_wph |
| 98 | wr_cycle: t_cez_w, t_wr_cycle |
| 99 | |
| 100 | 9. write sync muxed |
| 101 | adv_wr_off: t_avdp_w, t_avdh |
| 102 | we_on, wr_data_mux_bus: t_weasu, t_rdyo, t_aavdh, cyc_aavhd_we |
| 103 | we_off: t_wpl, cyc_wpl |
| 104 | cs_wr_off: t_wph |
| 105 | wr_cycle: t_cez_w, t_ce_rdyz |
| 106 | |
| 107 | 10. write sync non-muxed |
| 108 | adv_wr_off: t_avdp_w |
| 109 | we_on, wr_data_mux_bus: t_weasu, t_rdyo |
| 110 | we_off: t_wpl, cyc_wpl |
| 111 | cs_wr_off: t_wph |
| 112 | wr_cycle: t_cez_w, t_ce_rdyz |
| 113 | |
| 114 | |
| 115 | Note: Many of gpmc timings are dependent on other gpmc timings (a few |
| 116 | gpmc timings purely dependent on other gpmc timings, a reason that |
| 117 | some of the gpmc timings are missing above), and it will result in |
| 118 | indirect dependency of peripheral timings to gpmc timings other than |
| 119 | mentioned above, refer timing routine for more details. To know what |
| 120 | these peripheral timings correspond to, please see explanations in |
| 121 | struct gpmc_device_timings definition. And for gpmc timings refer |
| 122 | IP details (link above). |