LSP210DeviceDrivers
From Texas Instruments Embedded Processors Wiki
Translate this page to
NAND driver
- The NAND driver in LSP 2.10 has been updated to support NAND devices with a 4K page size.
- NAND driver in the kernel does not have support for NANDs with size greater than or equal to 4GB.
- The driver has also been updated to use the standard layout where pages of size 2K, 4K are handled as one chunk
of 2048 bytes of data + 64 bytes of OOB or 4096 bytes of data + 128 bytes of OOB.
- In previous releases the data and OOB are broken into chunks of 512 bytes of data + 16 bytes of OOB
- The entire LSP 2.10 release NAND components, i.e NAND programmer, UBL, U-Boot and kernel now support the new layout.
- The NANDs that have been tested as part of LSP 2.10 release include the 2GB SLC NAND from MICRON
with a page size of 2K and a 2GB SLC NAND from SAMSUNG with a page size of 4K
- The 4K NAND features are something which is not present event in the Linux Davinci GIT(linux 2.6.30) at this
point of time.
- NAND driver does not set any EMIF timings. This is done only in the UBL.
NAND driver - continued
- The old legacy layout is also supported though not recommended.
- There is a Kconfig option (DAVINCI_NAND_STD_LAYOUT) which enables the switch between the two layouts.
- This Kconfig option can be found at location /arch/arm/mach-davinci/Kconfig
- It is enabled by default for DM365.
- There is another Kconfig option at the same location which is used to switch between a block size of
128KB and 256KB. This option is DAVINCI_NAND_256KB_BLOCKS. This should be used if a NAND with
a block size of 256K is used.
- By default this option is disabled. This needs to be enabled for the SAMSUNG 4K NAND tested as part of the release.
- This option is used to calculate the size of the partitions as shown in the next slide.
#ifdef CONFIG_DAVINCI_NAND_256KB_BLOCKS
- define NAND_BLOCK_SIZE (SZ_256K)
- else
- define NAND_BLOCK_SIZE (SZ_128K)
- endif
static struct mtd_partition nand_partitions[] = {
/* bootloader (UBL, U-Boot, BBT) */
{
.name = "bootloader",
.offset = 0,
.size = 30 * NAND_BLOCK_SIZE,
.mask_flags = MTD_WRITEABLE, /* force read-only */
}
};
NAND driver - continued
- The partition sizes are for reference only and can be changed by customers.
- The first 2 partitions for the bootloader and params are treated as read only by the kernel as we don’t want to erase them accidentally
- 30 blocks have been assigned to the bootloader. This is because NAND writer writes UBL to block 1 and U-Boot to block 25. Due to the size of
the U-Boot binary, the NAND programmer writes U-Boot to blocks 25 and 26.
- We can avoid so much of lost space in between by modifying the NAND writer to write U-Boot to block 6 for example.
The reason why we write U-Boot to block 25 is because RBL searches for a valid UBL header in the first 24 blocks of NAND.
- A change in the kernel partition structure will require a change in the other NAND components as well if the partitions
for the bootloader components are modified.
MTD utilities for NAND
- As part of adding 4K support in the NAND driver the MTD utilities which are used to perform operations such as read/write/erase have been updated.
- MTD utilities that are part of the Montavista tool chain do not support NAND devices with a page size of above 2K.
- Version 1.1 of the MTD utilities was downloaded from http://git.infradead.org/mtd-utils.git and support for 4K page devices
was added as even open source does not have support for 4K devices.
- The tarball for these utilities can be found in the examples folder of the PSP package
- To build the utilities, untar and make sure the MV PRO 5.0 tools are in the $PATH
- The ‘makefile’ has already been modified to generate only 4 utilties , i.e nandwrite, nanddump, flash_erase and flash_eraseall
- To build the tools issue the command make CROSS = arm_v5t_le-
- The generated binaries will be found in the arm_v5t_le folder which gets generated during compilation
MTD utilities for NAND - Continued
- These utilities should be used along with NANDs of page size 4K and should be part of the filesystem when
trying to perform operations on the NAND.
- These utilities can be used instead of the MV PRO 5.0 MTD utilities for NANDs with page size of 2K and below as well
- Instructions to load yaffs2/jffs2 filesystem in the NAND are provided in the commands.txt that is part of the PSP package
EDMA driver
- EDMA on DM365 has 4 queues.
- It has 256 PARAMS and the first 64 PARAMs from 0 to 63 are reserved for the 64 channels. This ensures 1-1 mapping
- Q0 and Q1 have a larger FIFO size compared to Q2 and Q3
- To improve codec performance Q0, Q1 and Q2 are being reserved for the codecs.
- The LSP drivers will use only Q3 and will be given the highest priority.
- All LSP drivers that use EDMA now have the capability to change the queue that will be used for EDMA transfers
from the board specific code instead of modifying the driver.
EDMA – New API’s
- There is a new feature in the EDMA driver where we can request EDMA resources such that the channel no
is equal to the PARAM no and the TCC. With this we acquire a ‘symmetrical’ channel.
- To use this feature call the davinci_request_dma API along with dev_id as ‘EDMA_DMA_CHANNEL_ANY’ and
TCC as ‘EDMA_TCC_SYMM’. This finds the first instance where a channel # = PARAM # = TCC#. The API will not
acquire a channel that has been reserved for the LSP drivers
- The davinci_request_dma API can still be used with the ‘EDMA_TCC_ANY’ option along with dev_id as ‘EDMA_DMA_CHANNEL_ANY’.
- Two new APIs include davinci_get_tcc and davinci_get_param. Both these APIs take the channel number
as an argument and return either the tcc or the param associated with the channel.
EDMA API to request contiguous PARAMs
- LSP 2.10 has new EDMA API davinci_request_params to request a set of contiguous PARAMs
- The API takes three arguments
- dev_id which can EDMA_CONT_PARAMS_ANY or EDMA_CONT_PARAMS_FIXED_EXACT or EDMA_CONT_PARAMS_FIXED_NOT_EXACT
- num - number of contiguous PARAM's required
- param - is the start value of PARAM. The API starts checking from this PARAM no to find a set of contiguous PARAMs
- The API will return the starting point of a set of contiguous PARAM's that have been requested. Return value on failure will be -1
Davinci_request_params - variations
- If dev_id is ‘EDMA_CONT_PARAMS_ANY’ then the API will try to find a set of PARAMs starting at PARAM No 64.
- If dev_id is ‘EDMA_CONT_PARAMS_FIXED_EXACT ’ then the API will try to find a set of PARAMs starting at a PARAM No
that is passed as an argument to the API.
- So in the above case if we give num = 10 and param = 70,the API will try to find a set of 10 PARAMs starting at PARAM 70.
- If dev_id is ‘EDMA_CONT_PARAMS_FIXED_NOT_EXACT ’ then the API will first try to find a set of PARAMs
starting at a PARAM No that is passed as an argument to the API. If this fails then the API continues to scan
the remaining PARAMs to find a set of contiguous PARAMs
- For example if we take ask for 5 PARAMS starting at PARAM 80 by giving num = 5 and param = 80; the API will
first try to find a set of 5 PARAMS starting at PARAM 80. If this fails the API will continue to search the remaining PARAMs
to check whether it is possible to find 5 contiguous PARAMs
EDMA API to free contiguous PARAMs
- Application has to keep track of contiguous PARAMS acquired by ‘remembering’ the PARAM no at which a set
of contiguous PARAMs begins along with the number of PARAMs
- This information is then passed to the davinci_free_params API.
- So if there is a case where the davinci_request_params API is called, application must ensure that davinci_free_params
is also called to free resources.
- If this is not done then there is a chance that resources might get exhausted
SPI Driver
- drivers/spi/davinci_spi_master.c implements the core SPI master functionality.
This file is generic, should not need to modify this.
- board specific customizations should be done in arch/arm/mach-davinci/davinci_spi_platform.c
- Modify device array dm3xx_spi_board_info to change information on slaves connected to SPI0
- Each member is of type spi_board_info defined in include/linux/spi
- modalias used to match slave device to slave driver
- platform_data used by slave driver
- controller_data used by SPI master driver for slave specific information (of type davinci_spi_config_t)
- bus_num 0 for SPI0, 1 for SPI1
- chip_select chip select number for this SPI slave
- max_speed_hz SPI bus speed.
- Each member is of type spi_board_info defined in include/linux/spi
- Some of SPI chip selects can be driven by GPIOs. Define chip_sel array in platform data for SPI master. dm3xx_spi_pdata for SPI0
- If chip_sel[n] = DAVINCI_SPI_INTERN_CS, use IP chip select. If equal to GPIO num, use specified GPIO for chip select.
- GPIO num = (16 * bank number) + (gpio num)
- Ensure all pins required for SPI operation are muxed correctly (especially if using GPIO for CS)
MMC/SD
- MMC/SD driver has been updated so that it can be programmed to use any EDMA queue.
By default in LSP 2.10, DM355, DM357 and DM6446 will use Q0 and DM365 will use Q3.
The queue to be used can be changed in the board specific file in /arch/arm/mach-davinci folder.
For example
static struct resource mmc0_resources[] = {
/* this is a new option that can be passed to the driver */
[4] = { /* event queue */
.start = EVENTQ_3,
.end = EVENTQ_3,
.flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,,
},
};
Keypad Driver
- Due to PINMUX conflict, Keypad and NAND drives cannot operate at the same time.
- To use Keypad disable the NAND driver.
- NAND driver can be inserted as a module as well. So we can insert the keypad module, use it and then
remove the keypad module. We can then insert the NAND driver module if NAND driver is required
- The Keypad driver was tested using the open source test code "evtest". This was modified so that it reports
the correct key pressed on the DM365 EVM. The default mapping in the driver corresponds to a standard keyboard
- If any application needs to be designed along with keypad support then this test code should be referred to.
- The DM365 keypad driver is part of the linux input subsystem and uses the "evdev" (event device) driver.
Input Subsystem
</center>
Other Drivers
- There have not been any major/significant changes to the GPIO/PWM/UART/WDT/I2C drivers from previous releases.
- The kernel takes care of any minor differences between DM355 and DM365, for e.g. DM365 has 2 UARTS instead of 3 in DM355.
| For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article LSP210DeviceDrivers here. |
