2006-06-26 17:16:16 -06:00
|
|
|
/*
|
|
|
|
* General-Purpose Memory Controller for OMAP2
|
|
|
|
*
|
|
|
|
* Copyright (C) 2005-2006 Nokia Corporation
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __OMAP2_GPMC_H
|
|
|
|
#define __OMAP2_GPMC_H
|
|
|
|
|
2012-09-29 00:56:13 -06:00
|
|
|
#include <linux/platform_data/mtd-nand-omap2.h>
|
|
|
|
|
2008-10-06 06:49:17 -06:00
|
|
|
/* Maximum Number of Chip Selects */
|
|
|
|
#define GPMC_CS_NUM 8
|
|
|
|
|
2006-06-26 17:16:16 -06:00
|
|
|
#define GPMC_CS_CONFIG1 0x00
|
|
|
|
#define GPMC_CS_CONFIG2 0x04
|
|
|
|
#define GPMC_CS_CONFIG3 0x08
|
|
|
|
#define GPMC_CS_CONFIG4 0x0c
|
|
|
|
#define GPMC_CS_CONFIG5 0x10
|
|
|
|
#define GPMC_CS_CONFIG6 0x14
|
|
|
|
#define GPMC_CS_CONFIG7 0x18
|
|
|
|
#define GPMC_CS_NAND_COMMAND 0x1c
|
|
|
|
#define GPMC_CS_NAND_ADDRESS 0x20
|
|
|
|
#define GPMC_CS_NAND_DATA 0x24
|
|
|
|
|
2010-07-09 03:14:44 -06:00
|
|
|
/* Control Commands */
|
|
|
|
#define GPMC_CONFIG_RDY_BSY 0x00000001
|
|
|
|
#define GPMC_CONFIG_DEV_SIZE 0x00000002
|
|
|
|
#define GPMC_CONFIG_DEV_TYPE 0x00000003
|
|
|
|
#define GPMC_SET_IRQ_STATUS 0x00000004
|
|
|
|
#define GPMC_CONFIG_WP 0x00000005
|
|
|
|
|
2011-01-28 03:12:05 -07:00
|
|
|
#define GPMC_ENABLE_IRQ 0x0000000d
|
|
|
|
|
2010-07-09 03:14:44 -06:00
|
|
|
/* ECC commands */
|
|
|
|
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
|
|
|
|
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
|
|
|
|
#define GPMC_ECC_READSYN 2 /* Reset before syndrom is read back */
|
2008-10-06 06:49:36 -06:00
|
|
|
|
2006-06-26 17:16:16 -06:00
|
|
|
#define GPMC_CONFIG1_WRAPBURST_SUPP (1 << 31)
|
2006-12-06 18:13:55 -07:00
|
|
|
#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 << 30)
|
2006-06-26 17:16:16 -06:00
|
|
|
#define GPMC_CONFIG1_READTYPE_ASYNC (0 << 29)
|
|
|
|
#define GPMC_CONFIG1_READTYPE_SYNC (1 << 29)
|
2006-12-06 18:13:55 -07:00
|
|
|
#define GPMC_CONFIG1_WRITEMULTIPLE_SUPP (1 << 28)
|
2006-06-26 17:16:16 -06:00
|
|
|
#define GPMC_CONFIG1_WRITETYPE_ASYNC (0 << 27)
|
|
|
|
#define GPMC_CONFIG1_WRITETYPE_SYNC (1 << 27)
|
|
|
|
#define GPMC_CONFIG1_CLKACTIVATIONTIME(val) ((val & 3) << 25)
|
|
|
|
#define GPMC_CONFIG1_PAGE_LEN(val) ((val & 3) << 23)
|
|
|
|
#define GPMC_CONFIG1_WAIT_READ_MON (1 << 22)
|
|
|
|
#define GPMC_CONFIG1_WAIT_WRITE_MON (1 << 21)
|
|
|
|
#define GPMC_CONFIG1_WAIT_MON_IIME(val) ((val & 3) << 18)
|
|
|
|
#define GPMC_CONFIG1_WAIT_PIN_SEL(val) ((val & 3) << 16)
|
|
|
|
#define GPMC_CONFIG1_DEVICESIZE(val) ((val & 3) << 12)
|
|
|
|
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
|
|
|
|
#define GPMC_CONFIG1_DEVICETYPE(val) ((val & 3) << 10)
|
|
|
|
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
|
|
|
|
#define GPMC_CONFIG1_MUXADDDATA (1 << 9)
|
|
|
|
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 << 4)
|
|
|
|
#define GPMC_CONFIG1_FCLK_DIV(val) (val & 3)
|
|
|
|
#define GPMC_CONFIG1_FCLK_DIV2 (GPMC_CONFIG1_FCLK_DIV(1))
|
|
|
|
#define GPMC_CONFIG1_FCLK_DIV3 (GPMC_CONFIG1_FCLK_DIV(2))
|
|
|
|
#define GPMC_CONFIG1_FCLK_DIV4 (GPMC_CONFIG1_FCLK_DIV(3))
|
2008-09-26 06:17:33 -06:00
|
|
|
#define GPMC_CONFIG7_CSVALID (1 << 6)
|
2006-06-26 17:16:16 -06:00
|
|
|
|
2010-07-09 03:14:44 -06:00
|
|
|
#define GPMC_DEVICETYPE_NOR 0
|
|
|
|
#define GPMC_DEVICETYPE_NAND 2
|
|
|
|
#define GPMC_CONFIG_WRITEPROTECT 0x00000010
|
|
|
|
#define WR_RD_PIN_MONITORING 0x00600000
|
2011-01-28 03:12:05 -07:00
|
|
|
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
|
|
|
|
#define GPMC_IRQ_COUNT_EVENT 0x02
|
2010-07-09 03:14:44 -06:00
|
|
|
|
2011-01-28 03:12:07 -07:00
|
|
|
|
2012-05-28 06:21:37 -06:00
|
|
|
/* bool type time settings */
|
|
|
|
struct gpmc_bool_timings {
|
|
|
|
bool cycle2cyclediffcsen;
|
|
|
|
bool cycle2cyclesamecsen;
|
|
|
|
bool we_extra_delay;
|
|
|
|
bool oe_extra_delay;
|
|
|
|
bool adv_extra_delay;
|
|
|
|
bool cs_extra_delay;
|
|
|
|
bool time_para_granularity;
|
|
|
|
};
|
|
|
|
|
2006-06-26 17:16:16 -06:00
|
|
|
/*
|
2010-12-09 01:48:27 -07:00
|
|
|
* Note that all values in this struct are in nanoseconds except sync_clk
|
|
|
|
* (which is in picoseconds), while the register values are in gpmc_fck cycles.
|
2006-06-26 17:16:16 -06:00
|
|
|
*/
|
|
|
|
struct gpmc_timings {
|
2010-12-09 01:48:27 -07:00
|
|
|
/* Minimum clock period for synchronous mode (in picoseconds) */
|
|
|
|
u32 sync_clk;
|
2006-06-26 17:16:16 -06:00
|
|
|
|
|
|
|
/* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
u32 cs_on; /* Assertion time */
|
|
|
|
u32 cs_rd_off; /* Read deassertion time */
|
|
|
|
u32 cs_wr_off; /* Write deassertion time */
|
2006-06-26 17:16:16 -06:00
|
|
|
|
|
|
|
/* ADV signal timings corresponding to GPMC_CONFIG3 */
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
u32 adv_on; /* Assertion time */
|
|
|
|
u32 adv_rd_off; /* Read deassertion time */
|
|
|
|
u32 adv_wr_off; /* Write deassertion time */
|
2006-06-26 17:16:16 -06:00
|
|
|
|
|
|
|
/* WE signals timings corresponding to GPMC_CONFIG4 */
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
u32 we_on; /* WE assertion time */
|
|
|
|
u32 we_off; /* WE deassertion time */
|
2006-06-26 17:16:16 -06:00
|
|
|
|
|
|
|
/* OE signals timings corresponding to GPMC_CONFIG4 */
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
u32 oe_on; /* OE assertion time */
|
|
|
|
u32 oe_off; /* OE deassertion time */
|
2006-06-26 17:16:16 -06:00
|
|
|
|
|
|
|
/* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
u32 page_burst_access; /* Multiple access word delay */
|
|
|
|
u32 access; /* Start-cycle to first data valid delay */
|
|
|
|
u32 rd_cycle; /* Total read cycle time */
|
|
|
|
u32 wr_cycle; /* Total write cycle time */
|
2008-10-09 08:51:41 -06:00
|
|
|
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
u32 bus_turnaround;
|
|
|
|
u32 cycle2cycle_delay;
|
2012-05-28 06:21:37 -06:00
|
|
|
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
u32 wait_monitoring;
|
|
|
|
u32 clk_activation;
|
2012-05-28 06:21:37 -06:00
|
|
|
|
2008-10-09 08:51:41 -06:00
|
|
|
/* The following are only on OMAP3430 */
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
u32 wr_access; /* WRACCESSTIME */
|
|
|
|
u32 wr_data_mux_bus; /* WRDATAONADMUXBUS */
|
2012-05-28 06:21:37 -06:00
|
|
|
|
|
|
|
struct gpmc_bool_timings bool_timings;
|
2006-06-26 17:16:16 -06:00
|
|
|
};
|
|
|
|
|
ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
2012-08-02 08:32:10 -06:00
|
|
|
/* Device timings in picoseconds */
|
|
|
|
struct gpmc_device_timings {
|
|
|
|
u32 t_ceasu; /* address setup to CS valid */
|
|
|
|
u32 t_avdasu; /* address setup to ADV valid */
|
|
|
|
/* XXX: try to combine t_avdp_r & t_avdp_w. Issue is
|
|
|
|
* of tusb using these timings even for sync whilst
|
|
|
|
* ideally for adv_rd/(wr)_off it should have considered
|
|
|
|
* t_avdh instead. This indirectly necessitates r/w
|
|
|
|
* variations of t_avdp as it is possible to have one
|
|
|
|
* sync & other async
|
|
|
|
*/
|
|
|
|
u32 t_avdp_r; /* ADV low time (what about t_cer ?) */
|
|
|
|
u32 t_avdp_w;
|
|
|
|
u32 t_aavdh; /* address hold time */
|
|
|
|
u32 t_oeasu; /* address setup to OE valid */
|
|
|
|
u32 t_aa; /* access time from ADV assertion */
|
|
|
|
u32 t_iaa; /* initial access time */
|
|
|
|
u32 t_oe; /* access time from OE assertion */
|
|
|
|
u32 t_ce; /* access time from CS asertion */
|
|
|
|
u32 t_rd_cycle; /* read cycle time */
|
|
|
|
u32 t_cez_r; /* read CS deassertion to high Z */
|
|
|
|
u32 t_cez_w; /* write CS deassertion to high Z */
|
|
|
|
u32 t_oez; /* OE deassertion to high Z */
|
|
|
|
u32 t_weasu; /* address setup to WE valid */
|
|
|
|
u32 t_wpl; /* write assertion time */
|
|
|
|
u32 t_wph; /* write deassertion time */
|
|
|
|
u32 t_wr_cycle; /* write cycle time */
|
|
|
|
|
|
|
|
u32 clk;
|
|
|
|
u32 t_bacc; /* burst access valid clock to output delay */
|
|
|
|
u32 t_ces; /* CS setup time to clk */
|
|
|
|
u32 t_avds; /* ADV setup time to clk */
|
|
|
|
u32 t_avdh; /* ADV hold time from clk */
|
|
|
|
u32 t_ach; /* address hold time from clk */
|
|
|
|
u32 t_rdyo; /* clk to ready valid */
|
|
|
|
|
|
|
|
u32 t_ce_rdyz; /* XXX: description ?, or use t_cez instead */
|
|
|
|
u32 t_ce_avd; /* CS on to ADV on delay */
|
|
|
|
|
|
|
|
/* XXX: check the possibility of combining
|
|
|
|
* cyc_aavhd_oe & cyc_aavdh_we
|
|
|
|
*/
|
|
|
|
u8 cyc_aavdh_oe;/* read address hold time in cycles */
|
|
|
|
u8 cyc_aavdh_we;/* write address hold time in cycles */
|
|
|
|
u8 cyc_oe; /* access time from OE assertion in cycles */
|
|
|
|
u8 cyc_wpl; /* write deassertion time in cycles */
|
|
|
|
u32 cyc_iaa; /* initial access time in cycles */
|
|
|
|
|
|
|
|
bool mux; /* address & data muxed */
|
|
|
|
bool sync_write;/* synchronous write */
|
|
|
|
bool sync_read; /* synchronous read */
|
|
|
|
|
|
|
|
/* extra delays */
|
|
|
|
bool ce_xdelay;
|
|
|
|
bool avd_xdelay;
|
|
|
|
bool oe_xdelay;
|
|
|
|
bool we_xdelay;
|
|
|
|
};
|
|
|
|
|
|
|
|
extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
|
|
|
|
struct gpmc_device_timings *dev_t);
|
|
|
|
|
2012-08-30 13:53:22 -06:00
|
|
|
extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
|
2012-08-30 13:53:23 -06:00
|
|
|
extern int gpmc_get_client_irq(unsigned irq_config);
|
2012-08-30 13:53:22 -06:00
|
|
|
|
2006-06-26 17:16:16 -06:00
|
|
|
extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
|
2010-12-09 01:48:27 -07:00
|
|
|
extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
|
2008-10-06 06:49:17 -06:00
|
|
|
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
|
2007-01-26 13:29:40 -07:00
|
|
|
extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
|
|
|
|
extern unsigned long gpmc_get_fclk_period(void);
|
2006-06-26 17:16:16 -06:00
|
|
|
|
|
|
|
extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
|
|
|
|
extern u32 gpmc_cs_read_reg(int cs, int idx);
|
2012-08-19 06:59:45 -06:00
|
|
|
extern int gpmc_calc_divider(unsigned int sync_clk);
|
2006-06-26 17:16:16 -06:00
|
|
|
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
|
2006-09-25 03:41:33 -06:00
|
|
|
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
|
|
|
|
extern void gpmc_cs_free(int cs);
|
2006-12-13 00:02:43 -07:00
|
|
|
extern int gpmc_cs_set_reserved(int cs, int reserved);
|
2006-12-07 14:57:38 -07:00
|
|
|
extern int gpmc_cs_reserved(int cs);
|
2008-09-26 06:17:33 -06:00
|
|
|
extern void omap3_gpmc_save_context(void);
|
|
|
|
extern void omap3_gpmc_restore_context(void);
|
2010-07-09 03:14:44 -06:00
|
|
|
extern int gpmc_cs_configure(int cs, int cmd, int wval);
|
2012-04-26 06:17:49 -06:00
|
|
|
|
2006-06-26 17:16:16 -06:00
|
|
|
#endif
|