From grant.likely at secretlab.ca  Sun Aug  1 00:12:22 2010
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 31 Jul 2010 23:12:22 -0600
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <1280355490-11878-2-git-send-email-bniebuhr@efjohnson.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com> 
	<1280355490-11878-2-git-send-email-bniebuhr@efjohnson.com>
Message-ID: <AANLkTimu+G-5wTrdQ6YiWi60i+5uN9sydfsZKMKQX7_f@mail.gmail.com>

On Wed, Jul 28, 2010 at 4:18 PM, Brian Niebuhr <bniebuhr3 at gmail.com> wrote:
> INTRODUCTION
>
> I have been working on a custom OMAP-L138 board that has multiple spi
> devices (seven) on one controller. ?These devices have a wide range of
> transfer parameters (speed, phase, polarity, internal and gpio chip
> selects). ?During my testing I found multiple errors in the davinci spi
> driver as a result of this complex setup. ?The primary issues were:
>
> 1. There is a race condition due to the SPIBUF read busy-waits for slow
> ? ? ? ?devices
> 2. I found some DMA transfer length errors under some conditions
> 3. The chip select code caused extra byte transfers (with no chip
> ? ? ? ?select active) due to writes to SPIDAT1
> 4. Several issues prevented using multiple SPI devices, especially
> ? ? ? ?the DMA code, as disucussed previously on the davinci list.
>
> The fixes to these problems were not simple. ?I ended up making fairly
> large changes to the driver, and those changes are contained in these
> patches. ?The full list of changes follows.
>
> CHANGE LIST
>
> 1. davinci_spi_chipelect() now performs both activation and deactivation
> ? ? ? ?of chip selects. ?This lets spi_bitbang fully control chip
> ? ? ? ?select activation, as intended by the SPI API.
> 2. Chip select activation does not cause extra writes to the SPI bus
> 3. Chip select activation does not use SPIDEF for control. ?This change
> ? ? ? ?will also allow for implementation of inverted (active high)
> ? ? ? ?chip selects in the future.
> 4. Added back gpio chip select capability from the old driver
> 5. Fixed prescale calculation for non-integer fractions of spi clock
> 6. Allow specification of SPI transfer parameters on a per-device
> ? ? ? ?(instead of per-controller) basis
> 7. Allow specification of polled, interrupt-based, or DMA operation on
> ? ? ? ?a per-device basis
> 8. Allow DMA with when more than one device is connected
> 9. Combined pio and dma txrx_bufs functions into one since they share
> ? ? ? ?large parts of their functionality, and to simplify item (8).
> 10. Use only SPIFMT0 to allow more than 4 devices
>
> TESTING
>
> I have tested the driver using a custom SPI stress test on my
> OMAP-L138-based board with three devices connected. ?I have tested
> configurations with all three devices polled, all three interrupt-based,
> all three DMA, and a mixture.
>
> I have compiled with the davinci_all_defconfig, but I don't have EVMs
> for the other davinci platforms to test with.
>
> Signed-off-by: Brian Niebuhr <bniebuhr at efjohnson.com>

Hi Brian,

I'm getting a little frustrated, and I wouldn't be surprised if you're
getting a little frustrated too, but I cannot merge this as is.  It is
just too big to be able to review sanely, when I know there are
bite-size chunks that can be factored out into separate patches and
can be merged independently.

At a *bare minimum* I would need acks from several davinci users that
it is tested and working before I'd merge something like this, but
even then I'm not sure I would.  It certainly will not make me happy.
It also means that when someone does have problems with the new driver
over the old that they won't have a hope of bisecting it to figure out
which change broken their system.  There will be less pain all around
if you split it up instead.

...

In fact, after taking another look at it, I insist.  I can tell that
while major changes have been made, it is *still* the same driver with
changes that can be logically identified.  Split it up.

I'm more than happy to help you with the tools and techniques for
splitting a single monolithic patch into logical changes if you've not
done that before.  Send me a private email if you prefer.

Comments below:

> ---
> ?arch/arm/mach-davinci/board-dm355-evm.c ? ? | ? 10 +
> ?arch/arm/mach-davinci/board-dm355-leopard.c | ? 10 +
> ?arch/arm/mach-davinci/board-dm365-evm.c ? ? | ? 10 +
> ?arch/arm/mach-davinci/dm355.c ? ? ? ? ? ? ? | ? ?8 +-
> ?arch/arm/mach-davinci/dm365.c ? ? ? ? ? ? ? | ? ?6 -
> ?arch/arm/mach-davinci/include/mach/spi.h ? ?| ? 35 +-
> ?drivers/spi/davinci_spi.c ? ? ? ? ? ? ? ? ? | 1098 ++++++++++++---------------
> ?7 files changed, 521 insertions(+), 656 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
> index a319101..ad8779b 100644
> --- a/arch/arm/mach-davinci/board-dm355-evm.c
> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> @@ -32,6 +32,7 @@
> ?#include <mach/nand.h>
> ?#include <mach/mmc.h>
> ?#include <mach/usb.h>
> +#include <mach/spi.h>
>
> ?/* NOTE: ?this is geared for the standard config, with a socketed
> ?* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. ?If you
> @@ -300,10 +301,19 @@ static struct spi_eeprom at25640a = {
> ? ? ? ?.flags ? ? ? ? ?= EE_ADDR2,
> ?};
>
> +static struct davinci_spi_config at25640a_spi_cfg = {
> + ? ? ? .parity_enable ?= false,
> + ? ? ? .intr_level ? ? = 0,
> + ? ? ? .io_type ? ? ? ?= SPI_IO_TYPE_DMA,
> + ? ? ? .wdelay ? ? ? ? = 0,
> + ? ? ? .timer_disable ?= true,
> +};
> +
> ?static struct spi_board_info dm355_evm_spi_info[] __initconst = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.modalias ? ? ? = "at25",
> ? ? ? ? ? ? ? ?.platform_data ?= &at25640a,
> + ? ? ? ? ? ? ? .controller_data = &at25640a_spi_cfg,
> ? ? ? ? ? ? ? ?.max_speed_hz ? = 10 * 1000 * 1000, ? ? /* at 3v3 */
> ? ? ? ? ? ? ? ?.bus_num ? ? ? ?= 0,
> ? ? ? ? ? ? ? ?.chip_select ? ?= 0,
> diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
> index f1d8132..b2d8d48 100644
> --- a/arch/arm/mach-davinci/board-dm355-leopard.c
> +++ b/arch/arm/mach-davinci/board-dm355-leopard.c
> @@ -29,6 +29,7 @@
> ?#include <mach/nand.h>
> ?#include <mach/mmc.h>
> ?#include <mach/usb.h>
> +#include <mach/spi.h>
>
> ?/* NOTE: ?this is geared for the standard config, with a socketed
> ?* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. ?If you
> @@ -222,10 +223,19 @@ static struct spi_eeprom at25640a = {
> ? ? ? ?.flags ? ? ? ? ?= EE_ADDR2,
> ?};
>
> +static struct davinci_spi_config at25640a_spi_cfg = {
> + ? ? ? .parity_enable ?= false,
> + ? ? ? .intr_level ? ? = 0,
> + ? ? ? .io_type ? ? ? ?= SPI_IO_TYPE_DMA,
> + ? ? ? .wdelay ? ? ? ? = 0,
> + ? ? ? .timer_disable ?= true,
> +};
> +
> ?static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.modalias ? ? ? = "at25",
> ? ? ? ? ? ? ? ?.platform_data ?= &at25640a,
> + ? ? ? ? ? ? ? .controller_data = &at25640a_spi_cfg,
> ? ? ? ? ? ? ? ?.max_speed_hz ? = 10 * 1000 * 1000, ? ? /* at 3v3 */
> ? ? ? ? ? ? ? ?.bus_num ? ? ? ?= 0,
> ? ? ? ? ? ? ? ?.chip_select ? ?= 0,
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index 5bb86b2..db85372 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -39,6 +39,7 @@
> ?#include <mach/mmc.h>
> ?#include <mach/nand.h>
> ?#include <mach/keyscan.h>
> +#include <mach/spi.h>
>
> ?#include <media/tvp514x.h>
>
> @@ -579,10 +580,19 @@ static struct spi_eeprom at25640 = {
> ? ? ? ?.flags ? ? ? ? ?= EE_ADDR2,
> ?};
>
> +static struct davinci_spi_config at25640_spi_cfg = {
> + ? ? ? .parity_enable ?= false,
> + ? ? ? .intr_level ? ? = 0,
> + ? ? ? .io_type ? ? ? ?= SPI_IO_TYPE_DMA,
> + ? ? ? .wdelay ? ? ? ? = 0,
> + ? ? ? .timer_disable ?= true,
> +};
> +
> ?static struct spi_board_info dm365_evm_spi_info[] __initconst = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.modalias ? ? ? = "at25",
> ? ? ? ? ? ? ? ?.platform_data ?= &at25640,
> + ? ? ? ? ? ? ? .controller_data = &at25640_spi_cfg,
> ? ? ? ? ? ? ? ?.max_speed_hz ? = 10 * 1000 * 1000,
> ? ? ? ? ? ? ? ?.bus_num ? ? ? ?= 0,
> ? ? ? ? ? ? ? ?.chip_select ? ?= 0,
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index 3834781..b79b798 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -410,14 +410,8 @@ static struct resource dm355_spi0_resources[] = {
> ?};
>
> ?static struct davinci_spi_platform_data dm355_spi0_pdata = {
> - ? ? ? .version ? ? ? ?= SPI_VERSION_1,
> + ? ? ? .version ? ? ? ?= SPI_VERSION_0,
> ? ? ? ?.num_chipselect = 2,
> - ? ? ? .clk_internal ? = 1,
> - ? ? ? .cs_hold ? ? ? ?= 1,
> - ? ? ? .intr_level ? ? = 0,
> - ? ? ? .poll_mode ? ? ?= 1, ? ?/* 0 -> interrupt mode 1-> polling mode */
> - ? ? ? .c2tdelay ? ? ? = 0,
> - ? ? ? .t2cdelay ? ? ? = 0,
> ?};
> ?static struct platform_device dm355_spi0_device = {
> ? ? ? ?.name = "spi_davinci",
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 652f4b6..4aea346 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -625,12 +625,6 @@ static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
> ?static struct davinci_spi_platform_data dm365_spi0_pdata = {
> ? ? ? ?.version ? ? ? ?= SPI_VERSION_1,
> ? ? ? ?.num_chipselect = 2,
> - ? ? ? .clk_internal ? = 1,
> - ? ? ? .cs_hold ? ? ? ?= 1,
> - ? ? ? .intr_level ? ? = 0,
> - ? ? ? .poll_mode ? ? ?= 1, ? ?/* 0 -> interrupt mode 1-> polling mode */
> - ? ? ? .c2tdelay ? ? ? = 0,
> - ? ? ? .t2cdelay ? ? ? = 0,
> ?};
>
> ?static struct resource dm365_spi0_resources[] = {
> diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
> index 910efbf..3f77dab 100644
> --- a/arch/arm/mach-davinci/include/mach/spi.h
> +++ b/arch/arm/mach-davinci/include/mach/spi.h
> @@ -19,26 +19,35 @@
> ?#ifndef __ARCH_ARM_DAVINCI_SPI_H
> ?#define __ARCH_ARM_DAVINCI_SPI_H
>
> +#define SPI_INTERN_CS ?0xFF
> +
> ?enum {
> - ? ? ? SPI_VERSION_1, /* For DM355/DM365/DM6467 */
> + ? ? ? SPI_VERSION_0, /* For DM355 (reduced features, no Tx interrupt) */
> + ? ? ? SPI_VERSION_1, /* For DM365/DM6467 (reduced features) */
> ? ? ? ?SPI_VERSION_2, /* For DA8xx */
> ?};
>
> ?struct davinci_spi_platform_data {
> ? ? ? ?u8 ? ? ?version;
> - ? ? ? u8 ? ? ?num_chipselect;
> - ? ? ? u8 ? ? ?wdelay;
> - ? ? ? u8 ? ? ?odd_parity;
> - ? ? ? u8 ? ? ?parity_enable;
> - ? ? ? u8 ? ? ?wait_enable;
> - ? ? ? u8 ? ? ?timer_disable;
> - ? ? ? u8 ? ? ?clk_internal;
> - ? ? ? u8 ? ? ?cs_hold;
> + ? ? ? u16 ? ? num_chipselect;
> + ? ? ? u8 ? ? ?*chip_sel;
> +};
> +
> +struct davinci_spi_config {
> + ? ? ? bool ? ?odd_parity;
> + ? ? ? bool ? ?parity_enable;
> ? ? ? ?u8 ? ? ?intr_level;
> - ? ? ? u8 ? ? ?poll_mode;
> - ? ? ? u8 ? ? ?use_dma;
> - ? ? ? u8 ? ? ?c2tdelay;
> - ? ? ? u8 ? ? ?t2cdelay;
> + ? ? ? u8 ? ? ?io_type;
> +#define SPI_IO_TYPE_INTR ? ?0
> +#define SPI_IO_TYPE_POLL ? ?1
> +#define SPI_IO_TYPE_DMA ? ? 2
> + ? ? ? u8 ? ? ?bytes_per_word;
> + ? ? ? u8 ? ? ?wdelay;
> + ? ? ? bool ? ?timer_disable;
> + ? ? ? u8 ? ? ?c2t_delay;
> + ? ? ? u8 ? ? ?t2c_delay;
> + ? ? ? u8 ? ? ?t2e_delay;
> + ? ? ? u8 ? ? ?c2e_delay;
> ?};
>
> ?#endif /* __ARCH_ARM_DAVINCI_SPI_H */
> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
> index b85090c..5c9e9ce 100644
> --- a/drivers/spi/davinci_spi.c
> +++ b/drivers/spi/davinci_spi.c
> @@ -1,5 +1,6 @@
> ?/*
> ?* Copyright (C) 2009 Texas Instruments.
> + * Copyright (C) 2010 EF Johnson Technologies
> ?*
> ?* This program is free software; you can redistribute it and/or modify
> ?* it under the terms of the GNU General Public License as published by
> @@ -27,21 +28,19 @@
> ?#include <linux/dma-mapping.h>
> ?#include <linux/spi/spi.h>
> ?#include <linux/spi/spi_bitbang.h>
> -#include <linux/slab.h>
>
> ?#include <mach/spi.h>
> ?#include <mach/edma.h>
>
> ?#define SPI_NO_RESOURCE ? ? ? ? ? ? ? ?((resource_size_t)-1)
>
> -#define SPI_MAX_CHIPSELECT ? ? 2
> -
> ?#define CS_DEFAULT ? ? 0xFF
>
> ?#define SPI_BUFSIZ ? ? (SMP_CACHE_BYTES + 1)
> -#define DAVINCI_DMA_DATA_TYPE_S8 ? ? ? 0x01
> -#define DAVINCI_DMA_DATA_TYPE_S16 ? ? ?0x02
> -#define DAVINCI_DMA_DATA_TYPE_S32 ? ? ?0x04
> +
> +#define RX_DMA_INDEX ? ? ? ? ? 0
> +#define TX_DMA_INDEX ? ? ? ? ? 1
> +#define EVENTQ_DMA_INDEX ? ? ? 2
>
> ?#define SPIFMT_PHASE_MASK ? ? ?BIT(16)
> ?#define SPIFMT_POLARITY_MASK ? BIT(17)
> @@ -53,9 +52,11 @@
> ?#define SPIFMT_WDELAY_MASK ? ? 0x3f000000u
> ?#define SPIFMT_WDELAY_SHIFT ? ?24
> ?#define SPIFMT_CHARLEN_MASK ? ?0x0000001Fu
> +#define SPIFMT_PRESCALE_SHIFT ?8
>
> ?/* SPIGCR1 */
> -#define SPIGCR1_SPIENA_MASK ? ?0x01000000u
> +#define SPIGCR1_SPIENA_MASK ? ?BIT(24)
> +#define SPIGCR1_POWERDOWN_MASK BIT(8)
>
> ?/* SPIPC0 */
> ?#define SPIPC0_DIFUN_MASK ? ? ?BIT(11) ? ? ? ? /* MISO */
> @@ -66,20 +67,38 @@
> ?#define SPIPC0_EN0FUN_MASK ? ? BIT(0)
>
> ?#define SPIINT_MASKALL ? ? ? ? 0x0101035F
> +#define SPIINT_MASKINT ? ? ? ? 0x0000035F
> ?#define SPI_INTLVL_1 ? ? ? ? ? 0x000001FFu
> ?#define SPI_INTLVL_0 ? ? ? ? ? 0x00000000u
>
> ?/* SPIDAT1 */
> +#define SPIDAT1_CSHOLD_MASK ? ?BIT(28)
> ?#define SPIDAT1_CSHOLD_SHIFT ? 28
> +#define SPIDAT1_WDEL_MASK ? ? ?BIT(26)
> +#define SPIDAT1_CSNR_MASK ? ? ?0x00FF0000u
> ?#define SPIDAT1_CSNR_SHIFT ? ? 16
> +#define SPIDAT1_DFSEL_MASK ? ? (BIT(24 | BIT(25))
> ?#define SPIGCR1_CLKMOD_MASK ? ?BIT(1)
> -#define SPIGCR1_MASTER_MASK ? ? BIT(0)
> +#define SPIGCR1_MASTER_MASK ? ?BIT(0)
> ?#define SPIGCR1_LOOPBACK_MASK ?BIT(16)
>
> ?/* SPIBUF */
> ?#define SPIBUF_TXFULL_MASK ? ? BIT(29)
> ?#define SPIBUF_RXEMPTY_MASK ? ?BIT(31)
>
> +/* SPIDELAY */
> +#define SPIDELAY_C2TDELAY_MASK ?0xFF000000u
> +#define SPIDELAY_C2TDELAY_SHIFT 24
> +#define SPIDELAY_T2CDELAY_MASK ?0x00FF0000u
> +#define SPIDELAY_T2CDELAY_SHIFT 16
> +#define SPIDELAY_T2EDELAY_MASK ?0x0000FF00u
> +#define SPIDELAY_T2EDELAY_SHIFT 8
> +#define SPIDELAY_C2EDELAY_MASK ?0x000000FFu
> +#define SPIDELAY_C2EDELAY_SHIFT 0
> +
> +/* SPIDEF */
> +#define SPIDEF_CSDEF_MASK ? ? ? 0x000000FFu
> +
> ?/* Error Masks */
> ?#define SPIFLG_DLEN_ERR_MASK ? ? ? ? ? BIT(0)
> ?#define SPIFLG_TIMEOUT_MASK ? ? ? ? ? ?BIT(1)
> @@ -90,11 +109,12 @@
> ?#define SPIFLG_RX_INTR_MASK ? ? ? ? ? ?BIT(8)
> ?#define SPIFLG_TX_INTR_MASK ? ? ? ? ? ?BIT(9)
> ?#define SPIFLG_BUF_INIT_ACTIVE_MASK ? ?BIT(24)
> -#define SPIFLG_MASK ? ? ? ? ? ? ? ? ? ?(SPIFLG_DLEN_ERR_MASK \
> +#define SPIFLG_ERROR_MASK ? ? ? ? ? ? ?(SPIFLG_DLEN_ERR_MASK \
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SPIFLG_TIMEOUT_MASK | SPIFLG_PARERR_MASK \
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SPIFLG_DESYNC_MASK | SPIFLG_BITERR_MASK \
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIFLG_OVRRUN_MASK | SPIFLG_RX_INTR_MASK \
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIFLG_TX_INTR_MASK \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIFLG_OVRRUN_MASK)
> +#define SPIFLG_MASK ? ? ? ? ? ? ? ? ? ?(SPIFLG_ERROR_MASK \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIFLG_RX_INTR_MASK | SPIFLG_TX_INTR_MASK \
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SPIFLG_BUF_INIT_ACTIVE_MASK)
>
> ?#define SPIINT_DLEN_ERR_INTR ? BIT(0)
> @@ -139,11 +159,10 @@
> ?#define TGINTVEC0 ? ? ?0x60
> ?#define TGINTVEC1 ? ? ?0x64
>
> -struct davinci_spi_slave {
> - ? ? ? u32 ? ? cmd_to_write;
> - ? ? ? u32 ? ? clk_ctrl_to_write;
> - ? ? ? u32 ? ? bytes_per_word;
> - ? ? ? u8 ? ? ?active_cs;
> +const char * const io_type_names[] = {
> + ? ? ? [SPI_IO_TYPE_INTR] = "Interrupt",
> + ? ? ? [SPI_IO_TYPE_POLL] = "Polled",
> + ? ? ? [SPI_IO_TYPE_DMA] = "DMA",
> ?};
>
> ?/* We have 2 DMA channels per CS, one for RX and one for TX */
> @@ -152,10 +171,8 @@ struct davinci_spi_dma {
> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? dma_rx_channel;
> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? dma_tx_sync_dev;
> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? dma_rx_sync_dev;
> + ? ? ? int ? ? ? ? ? ? ? ? ? ? dummy_param_slot;
> ? ? ? ?enum dma_event_q ? ? ? ?eventq;
> -
> - ? ? ? struct completion ? ? ? dma_tx_completion;
> - ? ? ? struct completion ? ? ? dma_rx_completion;
> ?};
>
> ?/* SPI Controller driver's private data. */
> @@ -173,51 +190,53 @@ struct davinci_spi {
> ? ? ? ?const void ? ? ? ? ? ? ?*tx;
> ? ? ? ?void ? ? ? ? ? ? ? ? ? ?*rx;
> ? ? ? ?u8 ? ? ? ? ? ? ? ? ? ? ?*tmp_buf;
> - ? ? ? int ? ? ? ? ? ? ? ? ? ? count;
> - ? ? ? struct davinci_spi_dma ?*dma_channels;
> - ? ? ? struct ? ? ? ? ? ? ? ? ?davinci_spi_platform_data *pdata;
> + ? ? ? int ? ? ? ? ? ? ? ? ? ? rcount;
> + ? ? ? int ? ? ? ? ? ? ? ? ? ? wcount;
> + ? ? ? u32 ? ? ? ? ? ? ? ? ? ? errors;
> + ? ? ? struct davinci_spi_dma ?dma_channels;
> + ? ? ? struct davinci_spi_platform_data *pdata;
>
> ? ? ? ?void ? ? ? ? ? ? ? ? ? ?(*get_rx)(u32 rx_data, struct davinci_spi *);
> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? (*get_tx)(struct davinci_spi *);
> -
> - ? ? ? struct davinci_spi_slave slave[SPI_MAX_CHIPSELECT];
> ?};
>
> -static unsigned use_dma;
> -
> ?static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
> ?{
> - ? ? ? u8 *rx = davinci_spi->rx;
> -
> - ? ? ? *rx++ = (u8)data;
> - ? ? ? davinci_spi->rx = rx;
> + ? ? ? if (davinci_spi->rx) {
> + ? ? ? ? ? ? ? u8 *rx = davinci_spi->rx;
> + ? ? ? ? ? ? ? *rx++ = (u8)data;
> + ? ? ? ? ? ? ? davinci_spi->rx = rx;
> + ? ? ? }
> ?}
>
> ?static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
> ?{
> - ? ? ? u16 *rx = davinci_spi->rx;
> -
> - ? ? ? *rx++ = (u16)data;
> - ? ? ? davinci_spi->rx = rx;
> + ? ? ? if (davinci_spi->rx) {
> + ? ? ? ? ? ? ? u16 *rx = davinci_spi->rx;
> + ? ? ? ? ? ? ? *rx++ = (u16)data;
> + ? ? ? ? ? ? ? davinci_spi->rx = rx;
> + ? ? ? }
> ?}
>
> ?static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
> ?{
> - ? ? ? u32 data;
> - ? ? ? const u8 *tx = davinci_spi->tx;
> -
> - ? ? ? data = *tx++;
> - ? ? ? davinci_spi->tx = tx;
> + ? ? ? u32 data = 0;
> + ? ? ? if (davinci_spi->tx) {
> + ? ? ? ? ? ? ? const u8 *tx = davinci_spi->tx;
> + ? ? ? ? ? ? ? data = *tx++;
> + ? ? ? ? ? ? ? davinci_spi->tx = tx;
> + ? ? ? }
> ? ? ? ?return data;
> ?}

Here's an excellent candidate for a separate patch.  Validation of the
rx/tx buffer before transfering data to/from it.

>
> ?static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
> ?{
> - ? ? ? u32 data;
> - ? ? ? const u16 *tx = davinci_spi->tx;
> -
> - ? ? ? data = *tx++;
> - ? ? ? davinci_spi->tx = tx;
> + ? ? ? u32 data = 0;
> + ? ? ? if (davinci_spi->tx) {
> + ? ? ? ? ? ? ? const u16 *tx = davinci_spi->tx;
> + ? ? ? ? ? ? ? data = *tx++;
> + ? ? ? ? ? ? ? davinci_spi->tx = tx;
> + ? ? ? }
> ? ? ? ?return data;
> ?}
>
> @@ -237,26 +256,6 @@ static inline void clear_io_bits(void __iomem *addr, u32 bits)
> ? ? ? ?iowrite32(v, addr);
> ?}
>
> -static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
> -{
> - ? ? ? set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
> -}
> -
> -static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
> -{
> - ? ? ? clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
> -}
> -
> -static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable)
> -{
> - ? ? ? struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master);
> -
> - ? ? ? if (enable)
> - ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN);
> - ? ? ? else
> - ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN);
> -}
> -
> ?/*
> ?* Interface to control the chip select signal
> ?*/
> @@ -264,25 +263,54 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value)
> ?{
> ? ? ? ?struct davinci_spi *davinci_spi;
> ? ? ? ?struct davinci_spi_platform_data *pdata;
> - ? ? ? u32 data1_reg_val = 0;
> + ? ? ? u8 i, chip_sel = spi->chip_select;
> + ? ? ? u32 spidat1;
> + ? ? ? u16 spidat1_cfg;
>
> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
> ? ? ? ?pdata = davinci_spi->pdata;
>
> - ? ? ? /*
> - ? ? ? ?* Board specific chip select logic decides the polarity and cs
> - ? ? ? ?* line for the controller
> - ? ? ? ?*/
> - ? ? ? if (value == BITBANG_CS_INACTIVE) {
> - ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIDEF, CS_DEFAULT);
> -
> - ? ? ? ? ? ? ? data1_reg_val |= CS_DEFAULT << SPIDAT1_CSNR_SHIFT;
> - ? ? ? ? ? ? ? iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1);
> + ? ? ? spidat1 = SPIDAT1_CSNR_MASK;
> + ? ? ? if (value == BITBANG_CS_ACTIVE)
> + ? ? ? ? ? ? ? spidat1 |= SPIDAT1_CSHOLD_MASK;
> + ? ? ? else
> + ? ? ? ? ? ? ? spidat1 |= SPIDAT1_WDEL_MASK;
>
> - ? ? ? ? ? ? ? while ((ioread32(davinci_spi->base + SPIBUF)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_RXEMPTY_MASK) == 0)
> - ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
> + ? ? ? if (pdata->chip_sel == NULL) {
> + ? ? ? ? ? ? ? if (value == BITBANG_CS_ACTIVE)
> + ? ? ? ? ? ? ? ? ? ? ? spidat1 &= ~((0x1 << chip_sel) << SPIDAT1_CSNR_SHIFT);
> + ? ? ? } else {
> + ? ? ? ? ? ? ? for (i = 0; i < pdata->num_chipselect; i++) {
> + ? ? ? ? ? ? ? ? ? ? ? if (pdata->chip_sel[i] == SPI_INTERN_CS) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if ((i == chip_sel) &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (value == BITBANG_CS_ACTIVE)) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spidat1 &= ~((0x1 << chip_sel)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDAT1_CSNR_SHIFT);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? ? ? ? ? } else {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (value == BITBANG_CS_INACTIVE)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? gpio_set_value(pdata->chip_sel[i], 1);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? else if (i == chip_sel)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? gpio_set_value(pdata->chip_sel[i], 0);
> + ? ? ? ? ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? }
> ? ? ? ?}
> +
> + ? ? ? spidat1_cfg = spidat1 >> SPIDAT1_CSNR_SHIFT;
> + ? ? ? iowrite16(spidat1_cfg, davinci_spi->base + SPIDAT1 + 2);
> +}
> +
> +/**
> + * davinci_spi_get_prescale - Calculates the correct prescale value
> + * @max_speed_hz: the maximum rate the SPI clock can run at
> + *
> + * This function calculates the prescale value that generates a clock rate
> + * less than or equal to the specified maximum
> + */
> +static inline u32 davinci_spi_get_prescale(struct davinci_spi *davinci_spi,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u32 max_speed_hz)
> +{
> + ? ? ? return ((clk_get_rate(davinci_spi->clk) - 1) / max_speed_hz) & 0xff;
> ?}
>
> ?/**
> @@ -297,14 +325,15 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value)
> ?static int davinci_spi_setup_transfer(struct spi_device *spi,
> ? ? ? ? ? ? ? ?struct spi_transfer *t)
> ?{
> -
> ? ? ? ?struct davinci_spi *davinci_spi;
> ? ? ? ?struct davinci_spi_platform_data *pdata;
> + ? ? ? struct davinci_spi_config *spi_cfg;
> ? ? ? ?u8 bits_per_word = 0;
> - ? ? ? u32 hz = 0, prescale = 0, clkspeed;
> + ? ? ? u32 hz = 0, spifmt = 0, prescale, delay = 0;
>
> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
> ? ? ? ?pdata = davinci_spi->pdata;
> + ? ? ? spi_cfg = spi->controller_data;
>
> ? ? ? ?if (t) {
> ? ? ? ? ? ? ? ?bits_per_word = t->bits_per_word;
> @@ -322,76 +351,112 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
> ? ? ? ?if (bits_per_word <= 8 && bits_per_word >= 2) {
> ? ? ? ? ? ? ? ?davinci_spi->get_rx = davinci_spi_rx_buf_u8;
> ? ? ? ? ? ? ? ?davinci_spi->get_tx = davinci_spi_tx_buf_u8;
> - ? ? ? ? ? ? ? davinci_spi->slave[spi->chip_select].bytes_per_word = 1;
> + ? ? ? ? ? ? ? spi_cfg->bytes_per_word = 1;
> ? ? ? ?} else if (bits_per_word <= 16 && bits_per_word >= 2) {
> ? ? ? ? ? ? ? ?davinci_spi->get_rx = davinci_spi_rx_buf_u16;
> ? ? ? ? ? ? ? ?davinci_spi->get_tx = davinci_spi_tx_buf_u16;
> - ? ? ? ? ? ? ? davinci_spi->slave[spi->chip_select].bytes_per_word = 2;
> + ? ? ? ? ? ? ? spi_cfg->bytes_per_word = 2;
> ? ? ? ?} else
> ? ? ? ? ? ? ? ?return -EINVAL;
>
> ? ? ? ?if (!hz)
> ? ? ? ? ? ? ? ?hz = spi->max_speed_hz;
>
> - ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_CHARLEN_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? set_fmt_bits(davinci_spi->base, bits_per_word & 0x1f,
> - ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> + ? ? ? prescale = davinci_spi_get_prescale(davinci_spi, hz);
> + ? ? ? spifmt |= (prescale << SPIFMT_PRESCALE_SHIFT);
> +
> + ? ? ? spifmt |= (bits_per_word & 0x1f);
> +
> + ? ? ? if (spi->mode & SPI_LSB_FIRST)
> + ? ? ? ? ? ? ? spifmt |= SPIFMT_SHIFTDIR_MASK;
> +
> + ? ? ? if (spi->mode & SPI_CPOL)
> + ? ? ? ? ? ? ? spifmt |= SPIFMT_POLARITY_MASK;
> +
> + ? ? ? if (!(spi->mode & SPI_CPHA))
> + ? ? ? ? ? ? ? spifmt |= SPIFMT_PHASE_MASK;
> +
> + ? ? ? if (davinci_spi->version == SPI_VERSION_2) {
> + ? ? ? ? ? ? ? spifmt |= ((spi_cfg->wdelay << SPIFMT_WDELAY_SHIFT)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIFMT_WDELAY_MASK);
> +
> + ? ? ? ? ? ? ? if (spi_cfg->odd_parity)
> + ? ? ? ? ? ? ? ? ? ? ? spifmt |= SPIFMT_ODD_PARITY_MASK;
> +
> + ? ? ? ? ? ? ? if (spi_cfg->parity_enable)
> + ? ? ? ? ? ? ? ? ? ? ? spifmt |= SPIFMT_PARITYENA_MASK;
> +
> + ? ? ? ? ? ? ? if (spi->mode & SPI_READY) {
> + ? ? ? ? ? ? ? ? ? ? ? spifmt |= SPIFMT_WAITENA_MASK;
> + ? ? ? ? ? ? ? ? ? ? ? delay |= (spi_cfg->t2e_delay
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDELAY_T2EDELAY_SHIFT)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIDELAY_T2EDELAY_MASK;
> + ? ? ? ? ? ? ? ? ? ? ? delay |= (spi_cfg->c2e_delay
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDELAY_C2EDELAY_SHIFT)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIDELAY_C2EDELAY_MASK;
> + ? ? ? ? ? ? ? }
> +
> + ? ? ? ? ? ? ? if (spi_cfg->timer_disable) {
> + ? ? ? ? ? ? ? ? ? ? ? spifmt |= SPIFMT_DISTIMER_MASK;
> + ? ? ? ? ? ? ? } else {
> + ? ? ? ? ? ? ? ? ? ? ? delay |= (spi_cfg->c2t_delay
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDELAY_C2TDELAY_SHIFT)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIDELAY_C2TDELAY_MASK;
> + ? ? ? ? ? ? ? ? ? ? ? delay |= (spi_cfg->t2c_delay
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDELAY_T2CDELAY_SHIFT)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIDELAY_T2CDELAY_MASK;
> + ? ? ? ? ? ? ? }
>
> - ? ? ? clkspeed = clk_get_rate(davinci_spi->clk);
> - ? ? ? if (hz > clkspeed / 2)
> - ? ? ? ? ? ? ? prescale = 1 << 8;
> - ? ? ? if (hz < clkspeed / 256)
> - ? ? ? ? ? ? ? prescale = 255 << 8;
> - ? ? ? if (!prescale)
> - ? ? ? ? ? ? ? prescale = ((clkspeed / hz - 1) << 8) & 0x0000ff00;
> + ? ? ? ? ? ? ? iowrite32(delay, davinci_spi->base + SPIDELAY);
> + ? ? ? }
> +
> + ? ? ? iowrite32(spifmt, davinci_spi->base + SPIFMT0);
>
> - ? ? ? clear_fmt_bits(davinci_spi->base, 0x0000ff00, spi->chip_select);
> - ? ? ? set_fmt_bits(davinci_spi->base, prescale, spi->chip_select);
> + ? ? ? if (spi_cfg->intr_level)
> + ? ? ? ? ? ? ? iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL);
> + ? ? ? else
> + ? ? ? ? ? ? ? iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL);
> +
> + ? ? ? if (spi->mode & SPI_LOOP)
> + ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIGCR1,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_LOOPBACK_MASK);
> + ? ? ? else
> + ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_LOOPBACK_MASK);
>
> ? ? ? ?return 0;
> ?}
>
> ?static void davinci_spi_dma_rx_callback(unsigned lch, u16 ch_status, void *data)
> ?{
> - ? ? ? struct spi_device *spi = (struct spi_device *)data;
> - ? ? ? struct davinci_spi *davinci_spi;
> + ? ? ? struct davinci_spi *davinci_spi = data;
> ? ? ? ?struct davinci_spi_dma *davinci_spi_dma;
> ? ? ? ?struct davinci_spi_platform_data *pdata;
>
> - ? ? ? davinci_spi = spi_master_get_devdata(spi->master);
> - ? ? ? davinci_spi_dma = &(davinci_spi->dma_channels[spi->chip_select]);
> + ? ? ? davinci_spi_dma = &(davinci_spi->dma_channels);
> ? ? ? ?pdata = davinci_spi->pdata;
>
> + ? ? ? edma_stop(davinci_spi_dma->dma_rx_channel);
> +
> ? ? ? ?if (ch_status == DMA_COMPLETE)
> - ? ? ? ? ? ? ? edma_stop(davinci_spi_dma->dma_rx_channel);
> - ? ? ? else
> - ? ? ? ? ? ? ? edma_clean_channel(davinci_spi_dma->dma_rx_channel);
> + ? ? ? ? ? ? ? davinci_spi->rcount = 0;
>
> - ? ? ? complete(&davinci_spi_dma->dma_rx_completion);
> - ? ? ? /* We must disable the DMA RX request */
> - ? ? ? davinci_spi_set_dma_req(spi, 0);
> + ? ? ? complete(&davinci_spi->done);
> ?}
>
> ?static void davinci_spi_dma_tx_callback(unsigned lch, u16 ch_status, void *data)
> ?{
> - ? ? ? struct spi_device *spi = (struct spi_device *)data;
> - ? ? ? struct davinci_spi *davinci_spi;
> + ? ? ? struct davinci_spi *davinci_spi = data;
> ? ? ? ?struct davinci_spi_dma *davinci_spi_dma;
> ? ? ? ?struct davinci_spi_platform_data *pdata;
>
> - ? ? ? davinci_spi = spi_master_get_devdata(spi->master);
> - ? ? ? davinci_spi_dma = &(davinci_spi->dma_channels[spi->chip_select]);
> + ? ? ? davinci_spi_dma = &(davinci_spi->dma_channels);
> ? ? ? ?pdata = davinci_spi->pdata;
>
> - ? ? ? if (ch_status == DMA_COMPLETE)
> - ? ? ? ? ? ? ? edma_stop(davinci_spi_dma->dma_tx_channel);
> - ? ? ? else
> - ? ? ? ? ? ? ? edma_clean_channel(davinci_spi_dma->dma_tx_channel);
> + ? ? ? edma_stop(davinci_spi_dma->dma_tx_channel);
>
> - ? ? ? complete(&davinci_spi_dma->dma_tx_completion);
> - ? ? ? /* We must disable the DMA TX request */
> - ? ? ? davinci_spi_set_dma_req(spi, 0);
> + ? ? ? if (ch_status == DMA_COMPLETE)
> + ? ? ? ? ? ? ? davinci_spi->wcount = 0;
> ?}
>
> ?static int davinci_spi_request_dma(struct spi_device *spi)
> @@ -403,30 +468,51 @@ static int davinci_spi_request_dma(struct spi_device *spi)
> ? ? ? ?int r;
>
> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
> - ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
> + ? ? ? davinci_spi_dma = &davinci_spi->dma_channels;
> ? ? ? ?pdata = davinci_spi->pdata;
> ? ? ? ?sdev = davinci_spi->bitbang.master->dev.parent;
>
> ? ? ? ?r = edma_alloc_channel(davinci_spi_dma->dma_rx_sync_dev,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi_dma_rx_callback, spi,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi_dma_rx_callback, davinci_spi,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?davinci_spi_dma->eventq);
> ? ? ? ?if (r < 0) {
> - ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request DMA channel for SPI RX\n");
> - ? ? ? ? ? ? ? return -EAGAIN;
> + ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request DMA channel for MibSPI RX\n");
> + ? ? ? ? ? ? ? r = ?-EAGAIN;
> + ? ? ? ? ? ? ? goto rx_dma_failed;
> ? ? ? ?}
> ? ? ? ?davinci_spi_dma->dma_rx_channel = r;
> +
> ? ? ? ?r = edma_alloc_channel(davinci_spi_dma->dma_tx_sync_dev,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi_dma_tx_callback, spi,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi_dma_tx_callback, davinci_spi,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?davinci_spi_dma->eventq);
> ? ? ? ?if (r < 0) {
> - ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_rx_channel);
> - ? ? ? ? ? ? ? davinci_spi_dma->dma_rx_channel = -1;
> - ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request DMA channel for SPI TX\n");
> - ? ? ? ? ? ? ? return -EAGAIN;
> + ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request DMA channel for MibSPI TX\n");
> + ? ? ? ? ? ? ? r = -EAGAIN;
> + ? ? ? ? ? ? ? goto tx_dma_failed;
> ? ? ? ?}
> ? ? ? ?davinci_spi_dma->dma_tx_channel = r;
>
> + ? ? ? r = edma_alloc_slot(EDMA_CTLR(davinci_spi_dma->dma_tx_sync_dev),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? EDMA_SLOT_ANY);
> + ? ? ? if (r < 0) {
> + ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request SPI DMA param slot\n");
> + ? ? ? ? ? ? ? r = -EAGAIN;
> + ? ? ? ? ? ? ? goto param_failed;
> + ? ? ? }
> + ? ? ? davinci_spi_dma->dummy_param_slot = r;
> + ? ? ? edma_link(davinci_spi_dma->dummy_param_slot,
> + ? ? ? ? ? ? ? ? davinci_spi_dma->dummy_param_slot);
> +
> ? ? ? ?return 0;
> +
> +param_failed:
> + ? ? ? edma_free_channel(davinci_spi_dma->dma_tx_channel);
> + ? ? ? davinci_spi_dma->dma_tx_channel = -1;
> +tx_dma_failed:
> + ? ? ? edma_free_channel(davinci_spi_dma->dma_rx_channel);
> + ? ? ? davinci_spi_dma->dma_rx_channel = -1;
> +rx_dma_failed:
> + ? ? ? return r;
> ?}
>
> ?/**
> @@ -438,129 +524,54 @@ static int davinci_spi_request_dma(struct spi_device *spi)
>
> ?static int davinci_spi_setup(struct spi_device *spi)
> ?{
> - ? ? ? int retval;
> + ? ? ? int retval = 0;
> ? ? ? ?struct davinci_spi *davinci_spi;
> - ? ? ? struct davinci_spi_dma *davinci_spi_dma;
> - ? ? ? struct device *sdev;
> + ? ? ? struct davinci_spi_dma *davinci_dma;
> + ? ? ? struct davinci_spi_platform_data *pdata;
> + ? ? ? struct davinci_spi_config *spi_cfg;
> + ? ? ? u32 prescale;
>
> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
> - ? ? ? sdev = davinci_spi->bitbang.master->dev.parent;
> + ? ? ? pdata = davinci_spi->pdata;
> + ? ? ? spi_cfg = (struct davinci_spi_config *)spi->controller_data;
> + ? ? ? davinci_dma = &(davinci_spi->dma_channels);
>
> ? ? ? ?/* if bits per word length is zero then set it default 8 */
> ? ? ? ?if (!spi->bits_per_word)
> ? ? ? ? ? ? ? ?spi->bits_per_word = 8;
>
> - ? ? ? davinci_spi->slave[spi->chip_select].cmd_to_write = 0;
> + ? ? ? if (!(spi->mode & SPI_NO_CS)) {
> + ? ? ? ? ? ? ? if ((pdata->chip_sel == NULL) ||
> + ? ? ? ? ? ? ? ? ? (pdata->chip_sel[spi->chip_select] == SPI_INTERN_CS))
> + ? ? ? ? ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIPC0,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 << spi->chip_select);
>
> - ? ? ? if (use_dma && davinci_spi->dma_channels) {
> - ? ? ? ? ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
> -
> - ? ? ? ? ? ? ? if ((davinci_spi_dma->dma_rx_channel == -1)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || (davinci_spi_dma->dma_tx_channel == -1)) {
> - ? ? ? ? ? ? ? ? ? ? ? retval = davinci_spi_request_dma(spi);
> - ? ? ? ? ? ? ? ? ? ? ? if (retval < 0)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return retval;
> - ? ? ? ? ? ? ? }
> - ? ? ? }
> -
> - ? ? ? /*
> - ? ? ? ?* SPI in DaVinci and DA8xx operate between
> - ? ? ? ?* 600 KHz and 50 MHz
> - ? ? ? ?*/
> - ? ? ? if (spi->max_speed_hz < 600000 || spi->max_speed_hz > 50000000) {
> - ? ? ? ? ? ? ? dev_dbg(sdev, "Operating frequency is not in acceptable "
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "range\n");
> - ? ? ? ? ? ? ? return -EINVAL;
> ? ? ? ?}
>
> - ? ? ? /*
> - ? ? ? ?* Set up SPIFMTn register, unique to this chipselect.
> - ? ? ? ?*
> - ? ? ? ?* NOTE: we could do all of these with one write. ?Also, some
> - ? ? ? ?* of the "version 2" features are found in chips that don't
> - ? ? ? ?* support all of them...
> - ? ? ? ?*/
> - ? ? ? if (spi->mode & SPI_LSB_FIRST)
> - ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base, SPIFMT_SHIFTDIR_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? else
> - ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_SHIFTDIR_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> + ? ? ? if (spi->mode & SPI_READY)
> + ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIPC0, SPIPC0_SPIENA_MASK);
>
> - ? ? ? if (spi->mode & SPI_CPOL)
> - ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base, SPIFMT_POLARITY_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? else
> - ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_POLARITY_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> + ? ? ? if (spi_cfg->io_type == SPI_IO_TYPE_DMA) {
> + ? ? ? ? ? ? ? davinci_dma = &(davinci_spi->dma_channels);
>
> - ? ? ? if (!(spi->mode & SPI_CPHA))
> - ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base, SPIFMT_PHASE_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? else
> - ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_PHASE_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> + ? ? ? ? ? ? ? if ((davinci_dma->dma_tx_sync_dev == SPI_NO_RESOURCE) ||
> + ? ? ? ? ? ? ? ? ? (davinci_dma->dma_rx_sync_dev == SPI_NO_RESOURCE) ||
> + ? ? ? ? ? ? ? ? ? (davinci_dma->eventq == SPI_NO_RESOURCE))
> + ? ? ? ? ? ? ? ? ? ? ? spi_cfg->io_type = SPI_IO_TYPE_INTR;
> + ? ? ? ? ? ? ? else if ((davinci_dma->dma_rx_channel == -1) ||
> + ? ? ? ? ? ? ? ? ? ? ? ?(davinci_dma->dma_tx_channel == -1))
> + ? ? ? ? ? ? ? ? ? ? ? retval = davinci_spi_request_dma(spi);
> + ? ? ? }
>
> ? ? ? ?/*
> - ? ? ? ?* Version 1 hardware supports two basic SPI modes:
> - ? ? ? ?* ?- Standard SPI mode uses 4 pins, with chipselect
> - ? ? ? ?* ?- 3 pin SPI is a 4 pin variant without CS (SPI_NO_CS)
> - ? ? ? ?* ? ? ?(distinct from SPI_3WIRE, with just one data wire;
> - ? ? ? ?* ? ? ?or similar variants without MOSI or without MISO)
> - ? ? ? ?*
> - ? ? ? ?* Version 2 hardware supports an optional handshaking signal,
> - ? ? ? ?* so it can support two more modes:
> - ? ? ? ?* ?- 5 pin SPI variant is standard SPI plus SPI_READY
> - ? ? ? ?* ?- 4 pin with enable is (SPI_READY | SPI_NO_CS)
> + ? ? ? ?* Validate desired clock rate
> ? ? ? ? */
> + ? ? ? prescale = davinci_spi_get_prescale(davinci_spi, spi->max_speed_hz);
> + ? ? ? if ((prescale < 2) || (prescale > 255))
> + ? ? ? ? ? ? ? return -EINVAL;
>
> - ? ? ? if (davinci_spi->version == SPI_VERSION_2) {
> - ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_WDELAY_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (davinci_spi->pdata->wdelay
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIFMT_WDELAY_SHIFT)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIFMT_WDELAY_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> -
> - ? ? ? ? ? ? ? if (davinci_spi->pdata->odd_parity)
> - ? ? ? ? ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_ODD_PARITY_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? ? ? ? ? else
> - ? ? ? ? ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_ODD_PARITY_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> -
> - ? ? ? ? ? ? ? if (davinci_spi->pdata->parity_enable)
> - ? ? ? ? ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_PARITYENA_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? ? ? ? ? else
> - ? ? ? ? ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_PARITYENA_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> -
> - ? ? ? ? ? ? ? if (davinci_spi->pdata->wait_enable)
> - ? ? ? ? ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_WAITENA_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? ? ? ? ? else
> - ? ? ? ? ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_WAITENA_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> -
> - ? ? ? ? ? ? ? if (davinci_spi->pdata->timer_disable)
> - ? ? ? ? ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_DISTIMER_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? ? ? ? ? else
> - ? ? ? ? ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_DISTIMER_MASK,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
> - ? ? ? }
> -
> - ? ? ? retval = davinci_spi_setup_transfer(spi, NULL);
> + ? ? ? dev_info(&spi->dev, "DaVinci SPI driver in %s mode\n",
> + ? ? ? ? ? ? ? ? ? ? ? io_type_names[spi_cfg->io_type]);
>
> ? ? ? ?return retval;
> ?}
> @@ -569,50 +580,19 @@ static void davinci_spi_cleanup(struct spi_device *spi)
> ?{
> ? ? ? ?struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master);
> ? ? ? ?struct davinci_spi_dma *davinci_spi_dma;
> + ? ? ? struct davinci_spi_platform_data *pdata;
>
> - ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
> -
> - ? ? ? if (use_dma && davinci_spi->dma_channels) {
> - ? ? ? ? ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
> -
> - ? ? ? ? ? ? ? if ((davinci_spi_dma->dma_rx_channel != -1)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? && (davinci_spi_dma->dma_tx_channel != -1)) {
> - ? ? ? ? ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_tx_channel);
> - ? ? ? ? ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_rx_channel);
> - ? ? ? ? ? ? ? }
> - ? ? ? }
> -}
> -
> -static int davinci_spi_bufs_prep(struct spi_device *spi,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct davinci_spi *davinci_spi)
> -{
> - ? ? ? int op_mode = 0;
> -
> - ? ? ? /*
> - ? ? ? ?* REVISIT ?unless devices disagree about SPI_LOOP or
> - ? ? ? ?* SPI_READY (SPI_NO_CS only allows one device!), this
> - ? ? ? ?* should not need to be done before each message...
> - ? ? ? ?* optimize for both flags staying cleared.
> - ? ? ? ?*/
> -
> - ? ? ? op_mode = SPIPC0_DIFUN_MASK
> - ? ? ? ? ? ? ? | SPIPC0_DOFUN_MASK
> - ? ? ? ? ? ? ? | SPIPC0_CLKFUN_MASK;
> - ? ? ? if (!(spi->mode & SPI_NO_CS))
> - ? ? ? ? ? ? ? op_mode |= 1 << spi->chip_select;
> - ? ? ? if (spi->mode & SPI_READY)
> - ? ? ? ? ? ? ? op_mode |= SPIPC0_SPIENA_MASK;
> + ? ? ? davinci_spi_dma = &davinci_spi->dma_channels;
> + ? ? ? pdata = davinci_spi->pdata;
>
> - ? ? ? iowrite32(op_mode, davinci_spi->base + SPIPC0);
> + ? ? ? if (davinci_spi_dma->dma_rx_channel != -1)
> + ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_rx_channel);
>
> - ? ? ? if (spi->mode & SPI_LOOP)
> - ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIGCR1,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_LOOPBACK_MASK);
> - ? ? ? else
> - ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_LOOPBACK_MASK);
> + ? ? ? if (davinci_spi_dma->dma_tx_channel != -1)
> + ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_tx_channel);
>
> - ? ? ? return 0;
> + ? ? ? if (davinci_spi_dma->dummy_param_slot != -1)
> + ? ? ? ? ? ? ? edma_free_slot(davinci_spi_dma->dummy_param_slot);
> ?}
>
> ?static int davinci_spi_check_error(struct davinci_spi *davinci_spi,
> @@ -660,355 +640,242 @@ static int davinci_spi_check_error(struct davinci_spi *davinci_spi,
> ?}
>
> ?/**
> - * davinci_spi_bufs - functions which will handle transfer data
> - * @spi: spi device on which data transfer to be done
> - * @t: spi transfer in which transfer info is filled
> + * davinci_spi_process_events - check for and handle any SPI controller events
> + * @davinci_spi: the controller data
> ?*
> - * This function will put data to be transferred into data register
> - * of SPI controller and then wait until the completion will be marked
> - * by the IRQ Handler.
> + * This function will check the SPIFLG register and handle any events that are
> + * detected there
> ?*/
> -static int davinci_spi_bufs_pio(struct spi_device *spi, struct spi_transfer *t)
> +static int davinci_spi_process_events(struct davinci_spi *davinci_spi)
> ?{
> - ? ? ? struct davinci_spi *davinci_spi;
> - ? ? ? int int_status, count, ret;
> - ? ? ? u8 conv, tmp;
> - ? ? ? u32 tx_data, data1_reg_val;
> - ? ? ? u32 buf_val, flg_val;
> - ? ? ? struct davinci_spi_platform_data *pdata;
> -
> - ? ? ? davinci_spi = spi_master_get_devdata(spi->master);
> - ? ? ? pdata = davinci_spi->pdata;
> -
> - ? ? ? davinci_spi->tx = t->tx_buf;
> - ? ? ? davinci_spi->rx = t->rx_buf;
> -
> - ? ? ? /* convert len to words based on bits_per_word */
> - ? ? ? conv = davinci_spi->slave[spi->chip_select].bytes_per_word;
> - ? ? ? davinci_spi->count = t->len / conv;
> -
> - ? ? ? INIT_COMPLETION(davinci_spi->done);
> -
> - ? ? ? ret = davinci_spi_bufs_prep(spi, davinci_spi);
> - ? ? ? if (ret)
> - ? ? ? ? ? ? ? return ret;
> -
> - ? ? ? /* Enable SPI */
> - ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK);
> -
> - ? ? ? iowrite32(0 | (pdata->c2tdelay << SPI_C2TDELAY_SHIFT) |
> - ? ? ? ? ? ? ? ? ? ? ? (pdata->t2cdelay << SPI_T2CDELAY_SHIFT),
> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDELAY);
> -
> - ? ? ? count = davinci_spi->count;
> - ? ? ? data1_reg_val = pdata->cs_hold << SPIDAT1_CSHOLD_SHIFT;
> - ? ? ? tmp = ~(0x1 << spi->chip_select);
> -
> - ? ? ? clear_io_bits(davinci_spi->base + SPIDEF, ~tmp);
> -
> - ? ? ? data1_reg_val |= tmp << SPIDAT1_CSNR_SHIFT;
> -
> - ? ? ? while ((ioread32(davinci_spi->base + SPIBUF)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_RXEMPTY_MASK) == 0)
> - ? ? ? ? ? ? ? cpu_relax();
> -
> - ? ? ? /* Determine the command to execute READ or WRITE */
> - ? ? ? if (t->tx_buf) {
> - ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL);
> -
> - ? ? ? ? ? ? ? while (1) {
> - ? ? ? ? ? ? ? ? ? ? ? tx_data = davinci_spi->get_tx(davinci_spi);
> -
> - ? ? ? ? ? ? ? ? ? ? ? data1_reg_val &= ~(0xFFFF);
> - ? ? ? ? ? ? ? ? ? ? ? data1_reg_val |= (0xFFFF & tx_data);
> -
> - ? ? ? ? ? ? ? ? ? ? ? buf_val = ioread32(davinci_spi->base + SPIBUF);
> - ? ? ? ? ? ? ? ? ? ? ? if ((buf_val & SPIBUF_TXFULL_MASK) == 0) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iowrite32(data1_reg_val,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1);
> -
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? count--;
> - ? ? ? ? ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? ? ? ? ? while (ioread32(davinci_spi->base + SPIBUF)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_RXEMPTY_MASK)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
> -
> - ? ? ? ? ? ? ? ? ? ? ? /* getting the returned byte */
> - ? ? ? ? ? ? ? ? ? ? ? if (t->rx_buf) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? buf_val = ioread32(davinci_spi->base + SPIBUF);
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->get_rx(buf_val, davinci_spi);
> - ? ? ? ? ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? ? ? ? ? if (count <= 0)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> - ? ? ? ? ? ? ? }
> - ? ? ? } else {
> - ? ? ? ? ? ? ? if (pdata->poll_mode) {
> - ? ? ? ? ? ? ? ? ? ? ? while (1) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* keeps the serial clock going */
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if ((ioread32(davinci_spi->base + SPIBUF)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_TXFULL_MASK) == 0)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iowrite32(data1_reg_val,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1);
> -
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? while (ioread32(davinci_spi->base + SPIBUF) &
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIBUF_RXEMPTY_MASK)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
> -
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? flg_val = ioread32(davinci_spi->base + SPIFLG);
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? buf_val = ioread32(davinci_spi->base + SPIBUF);
> -
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->get_rx(buf_val, davinci_spi);
> -
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? count--;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (count <= 0)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> - ? ? ? ? ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? } else { ? ? ? ?/* Receive in Interrupt mode */
> - ? ? ? ? ? ? ? ? ? ? ? int i;
> -
> - ? ? ? ? ? ? ? ? ? ? ? for (i = 0; i < davinci_spi->count; i++) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIINT,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIINT_BITERR_INTR
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIINT_OVRRUN_INTR
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIINT_RX_INTR);
> -
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iowrite32(data1_reg_val,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1);
> -
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? while (ioread32(davinci_spi->base + SPIINT) &
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIINT_RX_INTR)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
> - ? ? ? ? ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? ? ? ? ? iowrite32((data1_reg_val & 0x0ffcffff),
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1);
> - ? ? ? ? ? ? ? }
> + ? ? ? u32 status, tx_data, rx_data, spidat1;
> + ? ? ? u8 tx_word = 0;
> +
> + ? ? ? status = ioread32(davinci_spi->base + SPIFLG);
> +
> + ? ? ? if ((davinci_spi->version != SPI_VERSION_0) &&
> + ? ? ? ? ? (likely(status & SPIFLG_TX_INTR_MASK)) &&
> + ? ? ? ? ? (likely(davinci_spi->wcount > 0)))
> + ? ? ? ? ? ? ? tx_word = 1;
> +
> + ? ? ? if (likely(status & SPIFLG_RX_INTR_MASK)) {
> + ? ? ? ? ? ? ? rx_data = ioread32(davinci_spi->base + SPIBUF) & 0xFFFF;
> + ? ? ? ? ? ? ? davinci_spi->get_rx(rx_data, davinci_spi);
> + ? ? ? ? ? ? ? davinci_spi->rcount--;
> + ? ? ? ? ? ? ? if ((davinci_spi->version == SPI_VERSION_0) &&
> + ? ? ? ? ? ? ? ? ? (likely(davinci_spi->wcount > 0)))
> + ? ? ? ? ? ? ? ? ? ? ? tx_word = 1;
> ? ? ? ?}
>
> - ? ? ? /*
> - ? ? ? ?* Check for bit error, desync error,parity error,timeout error and
> - ? ? ? ?* receive overflow errors
> - ? ? ? ?*/
> - ? ? ? int_status = ioread32(davinci_spi->base + SPIFLG);
> -
> - ? ? ? ret = davinci_spi_check_error(davinci_spi, int_status);
> - ? ? ? if (ret != 0)
> - ? ? ? ? ? ? ? return ret;
> + ? ? ? if (unlikely(status & SPIFLG_ERROR_MASK)) {
> + ? ? ? ? ? ? ? davinci_spi->errors = (status & SPIFLG_ERROR_MASK);
> + ? ? ? ? ? ? ? return -1;
> + ? ? ? }
>
> - ? ? ? /* SPI Framework maintains the count only in bytes so convert back */
> - ? ? ? davinci_spi->count *= conv;
> + ? ? ? if (likely(tx_word)) {
> + ? ? ? ? ? ? ? spidat1 = ioread32(davinci_spi->base + SPIDAT1);
> + ? ? ? ? ? ? ? davinci_spi->wcount--;
> + ? ? ? ? ? ? ? tx_data = davinci_spi->get_tx(davinci_spi);
> + ? ? ? ? ? ? ? spidat1 &= 0xFFFF0000;
> + ? ? ? ? ? ? ? spidat1 |= (tx_data & 0xFFFF);
> + ? ? ? ? ? ? ? iowrite32(spidat1, davinci_spi->base + SPIDAT1);
> + ? ? ? }
>
> - ? ? ? return t->len;
> + ? ? ? return 0;
> ?}
>
> -#define DAVINCI_DMA_DATA_TYPE_S8 ? ? ? 0x01
> -#define DAVINCI_DMA_DATA_TYPE_S16 ? ? ?0x02
> -#define DAVINCI_DMA_DATA_TYPE_S32 ? ? ?0x04
> -
> -static int davinci_spi_bufs_dma(struct spi_device *spi, struct spi_transfer *t)
> +/**
> + * davinci_spi_txrx_bufs - function which will handle transfer data
> + * @spi: spi device on which data transfer to be done
> + * @t: spi transfer in which transfer info is filled
> + *
> + * This function will put data to be transferred into data register
> + * of SPI controller and then wait until the completion will be marked
> + * by the IRQ Handler.
> + */
> +static int davinci_spi_txrx_bufs(struct spi_device *spi, struct spi_transfer *t)
> ?{
> ? ? ? ?struct davinci_spi *davinci_spi;
> - ? ? ? int int_status = 0;
> - ? ? ? int count, temp_count;
> - ? ? ? u8 conv = 1;
> - ? ? ? u8 tmp;
> - ? ? ? u32 data1_reg_val;
> - ? ? ? struct davinci_spi_dma *davinci_spi_dma;
> - ? ? ? int word_len, data_type, ret;
> - ? ? ? unsigned long tx_reg, rx_reg;
> + ? ? ? int data_type, ret = 0;
> + ? ? ? u32 tx_data, spidat1;
> + ? ? ? u16 tx_buf_count = 0, rx_buf_count = 0;
> + ? ? ? struct davinci_spi_config *spi_cfg;
> ? ? ? ?struct davinci_spi_platform_data *pdata;
> + ? ? ? struct davinci_spi_dma *davinci_dma;
> ? ? ? ?struct device *sdev;
> + ? ? ? dma_addr_t tx_reg, rx_reg;
> + ? ? ? void *tx_buf, *rx_buf;
> + ? ? ? struct edmacc_param rx_param, tx_param;
>
> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
> ? ? ? ?pdata = davinci_spi->pdata;
> - ? ? ? sdev = davinci_spi->bitbang.master->dev.parent;
> -
> - ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
> -
> - ? ? ? tx_reg = (unsigned long)davinci_spi->pbase + SPIDAT1;
> - ? ? ? rx_reg = (unsigned long)davinci_spi->pbase + SPIBUF;
> + ? ? ? spi_cfg = (struct davinci_spi_config *)spi->controller_data;
> + ? ? ? davinci_dma = &(davinci_spi->dma_channels);
>
> ? ? ? ?davinci_spi->tx = t->tx_buf;
> ? ? ? ?davinci_spi->rx = t->rx_buf;
> + ? ? ? davinci_spi->wcount = t->len / spi_cfg->bytes_per_word;
> + ? ? ? davinci_spi->rcount = davinci_spi->wcount;
> + ? ? ? davinci_spi->errors = 0;
>
> - ? ? ? /* convert len to words based on bits_per_word */
> - ? ? ? conv = davinci_spi->slave[spi->chip_select].bytes_per_word;
> - ? ? ? davinci_spi->count = t->len / conv;
> + ? ? ? spidat1 = ioread32(davinci_spi->base + SPIDAT1);
>
> - ? ? ? INIT_COMPLETION(davinci_spi->done);
> -
> - ? ? ? init_completion(&davinci_spi_dma->dma_rx_completion);
> - ? ? ? init_completion(&davinci_spi_dma->dma_tx_completion);
> -
> - ? ? ? word_len = conv * 8;
> -
> - ? ? ? if (word_len <= 8)
> - ? ? ? ? ? ? ? data_type = DAVINCI_DMA_DATA_TYPE_S8;
> - ? ? ? else if (word_len <= 16)
> - ? ? ? ? ? ? ? data_type = DAVINCI_DMA_DATA_TYPE_S16;
> - ? ? ? else if (word_len <= 32)
> - ? ? ? ? ? ? ? data_type = DAVINCI_DMA_DATA_TYPE_S32;
> - ? ? ? else
> - ? ? ? ? ? ? ? return -EINVAL;
> -
> - ? ? ? ret = davinci_spi_bufs_prep(spi, davinci_spi);
> - ? ? ? if (ret)
> - ? ? ? ? ? ? ? return ret;
> -
> - ? ? ? /* Put delay val if required */
> - ? ? ? iowrite32(0 | (pdata->c2tdelay << SPI_C2TDELAY_SHIFT) |
> - ? ? ? ? ? ? ? ? ? ? ? (pdata->t2cdelay << SPI_T2CDELAY_SHIFT),
> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDELAY);
> -
> - ? ? ? count = davinci_spi->count; ? ? /* the number of elements */
> - ? ? ? data1_reg_val = pdata->cs_hold << SPIDAT1_CSHOLD_SHIFT;
> -
> - ? ? ? /* CS default = 0xFF */
> - ? ? ? tmp = ~(0x1 << spi->chip_select);
> -
> - ? ? ? clear_io_bits(davinci_spi->base + SPIDEF, ~tmp);
> -
> - ? ? ? data1_reg_val |= tmp << SPIDAT1_CSNR_SHIFT;
> -
> - ? ? ? /* disable all interrupts for dma transfers */
> - ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL);
> - ? ? ? /* Disable SPI to write configuration bits in SPIDAT */
> - ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK);
> - ? ? ? iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1);
> - ? ? ? /* Enable SPI */
> + ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK);
> ? ? ? ?set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK);
>
> - ? ? ? while ((ioread32(davinci_spi->base + SPIBUF)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_RXEMPTY_MASK) == 0)
> - ? ? ? ? ? ? ? cpu_relax();
> -
> + ? ? ? INIT_COMPLETION(davinci_spi->done);
>
> - ? ? ? if (t->tx_buf) {
> - ? ? ? ? ? ? ? t->tx_dma = dma_map_single(&spi->dev, (void *)t->tx_buf, count,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_TO_DEVICE);
> - ? ? ? ? ? ? ? if (dma_mapping_error(&spi->dev, t->tx_dma)) {
> - ? ? ? ? ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to DMA map a %d bytes"
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? " TX buffer\n", count);
> - ? ? ? ? ? ? ? ? ? ? ? return -ENOMEM;
> + ? ? ? if ((spi_cfg->io_type == SPI_IO_TYPE_INTR) ||
> + ? ? ? ? ? (spi_cfg->io_type == SPI_IO_TYPE_POLL)) {
> +
> + ? ? ? ? ? ? ? if (spi_cfg->io_type == SPI_IO_TYPE_INTR)
> + ? ? ? ? ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKINT);
> +
> + ? ? ? ? ? ? ? /* start the transfer */
> + ? ? ? ? ? ? ? davinci_spi->wcount--;
> + ? ? ? ? ? ? ? tx_data = davinci_spi->get_tx(davinci_spi);
> + ? ? ? ? ? ? ? spidat1 &= 0xFFFF0000;
> + ? ? ? ? ? ? ? spidat1 |= (tx_data & 0xFFFF);
> + ? ? ? ? ? ? ? iowrite32(spidat1, davinci_spi->base + SPIDAT1);
> +
> + ? ? ? } else if (spi_cfg->io_type == SPI_IO_TYPE_DMA) {
> + ? ? ? ? ? ? ? data_type = spi_cfg->bytes_per_word;
> + ? ? ? ? ? ? ? tx_reg = (dma_addr_t)davinci_spi->pbase + SPIDAT1;
> + ? ? ? ? ? ? ? rx_reg = (dma_addr_t)davinci_spi->pbase + SPIBUF;
> +
> + ? ? ? ? ? ? ? if (t->tx_buf) {
> + ? ? ? ? ? ? ? ? ? ? ? tx_buf = ((void *)t->tx_buf);
> + ? ? ? ? ? ? ? ? ? ? ? tx_buf_count = davinci_spi->wcount;
> + ? ? ? ? ? ? ? } else {
> + ? ? ? ? ? ? ? ? ? ? ? tx_buf = (void *)davinci_spi->tmp_buf;
> + ? ? ? ? ? ? ? ? ? ? ? tx_buf_count = SPI_BUFSIZ;
> ? ? ? ? ? ? ? ?}
> - ? ? ? ? ? ? ? temp_count = count;
> - ? ? ? } else {
> - ? ? ? ? ? ? ? /* We need TX clocking for RX transaction */
> - ? ? ? ? ? ? ? t->tx_dma = dma_map_single(&spi->dev,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (void *)davinci_spi->tmp_buf, count + 1,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_TO_DEVICE);
> - ? ? ? ? ? ? ? if (dma_mapping_error(&spi->dev, t->tx_dma)) {
> - ? ? ? ? ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to DMA map a %d bytes"
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? " TX tmp buffer\n", count);
> - ? ? ? ? ? ? ? ? ? ? ? return -ENOMEM;
> + ? ? ? ? ? ? ? if (t->rx_buf) {
> + ? ? ? ? ? ? ? ? ? ? ? rx_buf = (void *)t->rx_buf;
> + ? ? ? ? ? ? ? ? ? ? ? rx_buf_count = davinci_spi->rcount;
> + ? ? ? ? ? ? ? } else {
> + ? ? ? ? ? ? ? ? ? ? ? rx_buf = (void *)davinci_spi->tmp_buf;
> + ? ? ? ? ? ? ? ? ? ? ? rx_buf_count = SPI_BUFSIZ;
> ? ? ? ? ? ? ? ?}
> - ? ? ? ? ? ? ? temp_count = count + 1;
> +
> + ? ? ? ? ? ? ? t->tx_dma = dma_map_single(&spi->dev, tx_buf,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? tx_buf_count, DMA_TO_DEVICE);
> + ? ? ? ? ? ? ? t->rx_dma = dma_map_single(&spi->dev, rx_buf,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rx_buf_count, DMA_FROM_DEVICE);
> +
> + ? ? ? ? ? ? ? tx_param.opt = TCINTEN | EDMA_TCC(davinci_dma->dma_tx_channel);
> + ? ? ? ? ? ? ? tx_param.src = t->tx_buf ? t->tx_dma : tx_reg;
> + ? ? ? ? ? ? ? tx_param.a_b_cnt = davinci_spi->wcount << 16 | data_type;
> + ? ? ? ? ? ? ? tx_param.dst = tx_reg;
> + ? ? ? ? ? ? ? tx_param.src_dst_bidx = t->tx_buf ? data_type : 0;
> + ? ? ? ? ? ? ? tx_param.link_bcntrld = 0xffff;
> + ? ? ? ? ? ? ? tx_param.src_dst_cidx = 0;
> + ? ? ? ? ? ? ? tx_param.ccnt = 1;
> + ? ? ? ? ? ? ? edma_write_slot(davinci_dma->dma_tx_channel, &tx_param);
> + ? ? ? ? ? ? ? edma_link(davinci_dma->dma_tx_channel,
> + ? ? ? ? ? ? ? ? ? ? ? ? davinci_dma->dummy_param_slot);
> +
> + ? ? ? ? ? ? ? rx_param.opt = TCINTEN | EDMA_TCC(davinci_dma->dma_rx_channel);
> + ? ? ? ? ? ? ? rx_param.src = rx_reg;
> + ? ? ? ? ? ? ? rx_param.a_b_cnt = davinci_spi->rcount << 16 | data_type;
> + ? ? ? ? ? ? ? rx_param.dst = t->rx_dma;
> + ? ? ? ? ? ? ? rx_param.src_dst_bidx = (t->rx_buf ? data_type : 0) << 16;
> + ? ? ? ? ? ? ? rx_param.link_bcntrld = 0xffff;
> + ? ? ? ? ? ? ? rx_param.src_dst_cidx = 0;
> + ? ? ? ? ? ? ? rx_param.ccnt = 1;
> + ? ? ? ? ? ? ? edma_write_slot(davinci_dma->dma_rx_channel, &rx_param);
> +
> + ? ? ? ? ? ? ? iowrite16(spidat1 >> SPIDAT1_CSNR_SHIFT,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1 + 2);
> +
> + ? ? ? ? ? ? ? edma_start(davinci_dma->dma_rx_channel);
> + ? ? ? ? ? ? ? edma_start(davinci_dma->dma_tx_channel);
> + ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN);
> ? ? ? ?}
>
> - ? ? ? edma_set_transfer_params(davinci_spi_dma->dma_tx_channel,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? data_type, temp_count, 1, 0, ASYNC);
> - ? ? ? edma_set_dest(davinci_spi_dma->dma_tx_channel, tx_reg, INCR, W8BIT);
> - ? ? ? edma_set_src(davinci_spi_dma->dma_tx_channel, t->tx_dma, INCR, W8BIT);
> - ? ? ? edma_set_src_index(davinci_spi_dma->dma_tx_channel, data_type, 0);
> - ? ? ? edma_set_dest_index(davinci_spi_dma->dma_tx_channel, 0, 0);
> -
> - ? ? ? if (t->rx_buf) {
> - ? ? ? ? ? ? ? /* initiate transaction */
> - ? ? ? ? ? ? ? iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1);
> -
> - ? ? ? ? ? ? ? t->rx_dma = dma_map_single(&spi->dev, (void *)t->rx_buf, count,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_FROM_DEVICE);
> - ? ? ? ? ? ? ? if (dma_mapping_error(&spi->dev, t->rx_dma)) {
> - ? ? ? ? ? ? ? ? ? ? ? dev_dbg(sdev, "Couldn't DMA map a %d bytes RX buffer\n",
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? count);
> - ? ? ? ? ? ? ? ? ? ? ? if (t->tx_buf != NULL)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_unmap_single(NULL, t->tx_dma,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?count, DMA_TO_DEVICE);
> - ? ? ? ? ? ? ? ? ? ? ? return -ENOMEM;
> + ? ? ? /* Wait for the transfer to complete */
> + ? ? ? if (spi_cfg->io_type != SPI_IO_TYPE_POLL) {
> + ? ? ? ? ? ? ? wait_for_completion_interruptible(&(davinci_spi->done));
> + ? ? ? } else {
> + ? ? ? ? ? ? ? while ((davinci_spi->rcount > 0) && (ret == 0)) {
> + ? ? ? ? ? ? ? ? ? ? ? ret = davinci_spi_process_events(davinci_spi);
> + ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
> ? ? ? ? ? ? ? ?}
> - ? ? ? ? ? ? ? edma_set_transfer_params(davinci_spi_dma->dma_rx_channel,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? data_type, count, 1, 0, ASYNC);
> - ? ? ? ? ? ? ? edma_set_src(davinci_spi_dma->dma_rx_channel,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rx_reg, INCR, W8BIT);
> - ? ? ? ? ? ? ? edma_set_dest(davinci_spi_dma->dma_rx_channel,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? t->rx_dma, INCR, W8BIT);
> - ? ? ? ? ? ? ? edma_set_src_index(davinci_spi_dma->dma_rx_channel, 0, 0);
> - ? ? ? ? ? ? ? edma_set_dest_index(davinci_spi_dma->dma_rx_channel,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? data_type, 0);
> ? ? ? ?}
>
> - ? ? ? if ((t->tx_buf) || (t->rx_buf))
> - ? ? ? ? ? ? ? edma_start(davinci_spi_dma->dma_tx_channel);
> -
> - ? ? ? if (t->rx_buf)
> - ? ? ? ? ? ? ? edma_start(davinci_spi_dma->dma_rx_channel);
> -
> - ? ? ? if ((t->rx_buf) || (t->tx_buf))
> - ? ? ? ? ? ? ? davinci_spi_set_dma_req(spi, 1);
> -
> - ? ? ? if (t->tx_buf)
> - ? ? ? ? ? ? ? wait_for_completion_interruptible(
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &davinci_spi_dma->dma_tx_completion);
> -
> - ? ? ? if (t->rx_buf)
> - ? ? ? ? ? ? ? wait_for_completion_interruptible(
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &davinci_spi_dma->dma_rx_completion);
> -
> - ? ? ? dma_unmap_single(NULL, t->tx_dma, temp_count, DMA_TO_DEVICE);
> -
> - ? ? ? if (t->rx_buf)
> - ? ? ? ? ? ? ? dma_unmap_single(NULL, t->rx_dma, count, DMA_FROM_DEVICE);
> -
> - ? ? ? /*
> - ? ? ? ?* Check for bit error, desync error,parity error,timeout error and
> - ? ? ? ?* receive overflow errors
> - ? ? ? ?*/
> - ? ? ? int_status = ioread32(davinci_spi->base + SPIFLG);
> + ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL);
> + ? ? ? if (spi_cfg->io_type == SPI_IO_TYPE_DMA) {
> + ? ? ? ? ? ? ? dma_unmap_single(NULL, t->tx_dma, tx_buf_count,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_TO_DEVICE);
> + ? ? ? ? ? ? ? dma_unmap_single(NULL, t->rx_dma, rx_buf_count,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_FROM_DEVICE);
> + ? ? ? }
>
> - ? ? ? ret = davinci_spi_check_error(davinci_spi, int_status);
> - ? ? ? if (ret != 0)
> - ? ? ? ? ? ? ? return ret;
> + ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK);
> + ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK);
>
> - ? ? ? /* SPI Framework maintains the count only in bytes so convert back */
> - ? ? ? davinci_spi->count *= conv;
> + ? ? ? if (davinci_spi->errors) {
> + ? ? ? ? ? ? ? ret = davinci_spi_check_error(davinci_spi, davinci_spi->errors);
> + ? ? ? ? ? ? ? if (ret != 0)
> + ? ? ? ? ? ? ? ? ? ? ? return ret;
> + ? ? ? }
> + ? ? ? if ((davinci_spi->rcount != 0) || (davinci_spi->wcount != 0)) {
> + ? ? ? ? ? ? ? sdev = davinci_spi->bitbang.master->dev.parent;
> + ? ? ? ? ? ? ? dev_info(sdev, "SPI data transfer error\n");
> + ? ? ? ? ? ? ? return -EIO;
> + ? ? ? }
>
> ? ? ? ?return t->len;
> ?}
>
> ?/**
> - * davinci_spi_irq - IRQ handler for DaVinci SPI
> + * davinci_spi_irq - probe function for SPI Master Controller

This doesn't look right.

> ?* @irq: IRQ number for this SPI Master
> ?* @context_data: structure for SPI Master controller davinci_spi
> + *
> + * ISR will determine that interrupt arrives either for READ or WRITE command.
> + * According to command it will do the appropriate action. It will check
> + * transfer length and if it is not zero then dispatch transfer command again.
> + * If transfer length is zero then it will indicate the COMPLETION so that
> + * davinci_spi_bufs function can go ahead.
> ?*/
> ?static irqreturn_t davinci_spi_irq(s32 irq, void *context_data)
> ?{
> ? ? ? ?struct davinci_spi *davinci_spi = context_data;
> - ? ? ? u32 int_status, rx_data = 0;
> - ? ? ? irqreturn_t ret = IRQ_NONE;
> + ? ? ? int status;
>
> - ? ? ? int_status = ioread32(davinci_spi->base + SPIFLG);
> + ? ? ? status = davinci_spi_process_events(davinci_spi);
> + ? ? ? if (unlikely(status != 0))
> + ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKINT);
>
> - ? ? ? while ((int_status & SPIFLG_RX_INTR_MASK)) {
> - ? ? ? ? ? ? ? if (likely(int_status & SPIFLG_RX_INTR_MASK)) {
> - ? ? ? ? ? ? ? ? ? ? ? ret = IRQ_HANDLED;
> + ? ? ? if ((davinci_spi->rcount == 0) || (status != 0))
> + ? ? ? ? ? ? ? complete(&(davinci_spi->done));
>
> - ? ? ? ? ? ? ? ? ? ? ? rx_data = ioread32(davinci_spi->base + SPIBUF);
> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->get_rx(rx_data, davinci_spi);
> + ? ? ? return IRQ_HANDLED;
> +}
>
> - ? ? ? ? ? ? ? ? ? ? ? /* Disable Receive Interrupt */
> - ? ? ? ? ? ? ? ? ? ? ? iowrite32(~(SPIINT_RX_INTR | SPIINT_TX_INTR),
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIINT);
> - ? ? ? ? ? ? ? } else
> - ? ? ? ? ? ? ? ? ? ? ? (void)davinci_spi_check_error(davinci_spi, int_status);
> +resource_size_t davinci_spi_get_dma_by_index(struct platform_device *dev,
> + ? ? ? ? ? ? ? unsigned long index)
> +{
> + ? ? ? struct resource *r;
>
> - ? ? ? ? ? ? ? int_status = ioread32(davinci_spi->base + SPIFLG);
> - ? ? ? }
> + ? ? ? r = platform_get_resource(dev, IORESOURCE_DMA, index);
> + ? ? ? if (r != NULL)
> + ? ? ? ? ? ? ? return r->start;
>
> - ? ? ? return ret;
> + ? ? ? return SPI_NO_RESOURCE;
> ?}
>
> ?/**
> ?* davinci_spi_probe - probe function for SPI Master Controller
> ?* @pdev: platform_device structure which contains plateform specific data
> + *
> + * According to Linux Device Model this function will be invoked by Linux
> + * with platform_device struct which contains the device specific info.
> + * This function will map the SPI controller's memory, register IRQ,
> + * Reset SPI controller and setting its registers to default value.
> + * It will invoke spi_bitbang_start to create work queue so that client driver
> + * can register transfer method to work queue.

Another candidate; improve documentation

> ?*/
> ?static int davinci_spi_probe(struct platform_device *pdev)
> ?{
> @@ -1020,6 +887,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
> ? ? ? ?resource_size_t dma_tx_chan = SPI_NO_RESOURCE;
> ? ? ? ?resource_size_t dma_eventq = SPI_NO_RESOURCE;
> ? ? ? ?int i = 0, ret = 0;
> + ? ? ? u32 spipc0;
>
> ? ? ? ?pdata = pdev->dev.platform_data;
> ? ? ? ?if (pdata == NULL) {
> @@ -1071,10 +939,12 @@ static int davinci_spi_probe(struct platform_device *pdev)
> ? ? ? ? ? ? ? ?goto unmap_io;
> ? ? ? ?}
>
> - ? ? ? ret = request_irq(davinci_spi->irq, davinci_spi_irq, IRQF_DISABLED,
> + ? ? ? ret = request_irq(davinci_spi->irq, davinci_spi_irq, 0,
> ? ? ? ? ? ? ? ? ? ? ? ? ?dev_name(&pdev->dev), davinci_spi);
> - ? ? ? if (ret)
> + ? ? ? if (ret != 0) {
> + ? ? ? ? ? ? ? ret = -EAGAIN;
> ? ? ? ? ? ? ? ?goto unmap_io;
> + ? ? ? }
>
> ? ? ? ?/* Allocate tmp_buf for tx_buf */
> ? ? ? ?davinci_spi->tmp_buf = kzalloc(SPI_BUFSIZ, GFP_KERNEL);
> @@ -1104,55 +974,23 @@ static int davinci_spi_probe(struct platform_device *pdev)
>
> ? ? ? ?davinci_spi->bitbang.chipselect = davinci_spi_chipselect;
> ? ? ? ?davinci_spi->bitbang.setup_transfer = davinci_spi_setup_transfer;
> + ? ? ? davinci_spi->bitbang.txrx_bufs = davinci_spi_txrx_bufs;
>
> ? ? ? ?davinci_spi->version = pdata->version;
> - ? ? ? use_dma = pdata->use_dma;
>
> ? ? ? ?davinci_spi->bitbang.flags = SPI_NO_CS | SPI_LSB_FIRST | SPI_LOOP;
> ? ? ? ?if (davinci_spi->version == SPI_VERSION_2)
> ? ? ? ? ? ? ? ?davinci_spi->bitbang.flags |= SPI_READY;
>
> - ? ? ? if (use_dma) {
> - ? ? ? ? ? ? ? ? ? ? ? r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> - ? ? ? ? ? ? ? ? ? ? ? if (r)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_rx_chan = r->start;
> - ? ? ? ? ? ? ? ? ? ? ? r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
> - ? ? ? ? ? ? ? ? ? ? ? if (r)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_tx_chan = r->start;
> - ? ? ? ? ? ? ? ? ? ? ? r = platform_get_resource(pdev, IORESOURCE_DMA, 2);
> - ? ? ? ? ? ? ? ? ? ? ? if (r)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_eventq = r->start;
> - ? ? ? }
> -
> - ? ? ? if (!use_dma ||
> - ? ? ? ? ? dma_rx_chan == SPI_NO_RESOURCE ||
> - ? ? ? ? ? dma_tx_chan == SPI_NO_RESOURCE ||
> - ? ? ? ? ? dma_eventq ?== SPI_NO_RESOURCE) {
> - ? ? ? ? ? ? ? davinci_spi->bitbang.txrx_bufs = davinci_spi_bufs_pio;
> - ? ? ? ? ? ? ? use_dma = 0;
> - ? ? ? } else {
> - ? ? ? ? ? ? ? davinci_spi->bitbang.txrx_bufs = davinci_spi_bufs_dma;
> - ? ? ? ? ? ? ? davinci_spi->dma_channels = kzalloc(master->num_chipselect
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? * sizeof(struct davinci_spi_dma), GFP_KERNEL);
> - ? ? ? ? ? ? ? if (davinci_spi->dma_channels == NULL) {
> - ? ? ? ? ? ? ? ? ? ? ? ret = -ENOMEM;
> - ? ? ? ? ? ? ? ? ? ? ? goto free_clk;
> - ? ? ? ? ? ? ? }
> -
> - ? ? ? ? ? ? ? for (i = 0; i < master->num_chipselect; i++) {
> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].dma_rx_channel = -1;
> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].dma_rx_sync_dev =
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_rx_chan;
> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].dma_tx_channel = -1;
> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].dma_tx_sync_dev =
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_tx_chan;
> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].eventq = dma_eventq;
> - ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? dev_info(&pdev->dev, "DaVinci SPI driver in EDMA mode\n"
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Using RX channel = %d , TX channel = %d and "
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "event queue = %d", dma_rx_chan, dma_tx_chan,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_eventq);
> - ? ? ? }
> + ? ? ? dma_rx_chan = davinci_spi_get_dma_by_index(pdev, RX_DMA_INDEX);
> + ? ? ? dma_tx_chan = davinci_spi_get_dma_by_index(pdev, TX_DMA_INDEX);
> + ? ? ? dma_eventq ?= davinci_spi_get_dma_by_index(pdev, EVENTQ_DMA_INDEX);
> + ? ? ? davinci_spi->dma_channels.dma_rx_channel = -1;
> + ? ? ? davinci_spi->dma_channels.dma_rx_sync_dev = dma_rx_chan;
> + ? ? ? davinci_spi->dma_channels.dma_tx_channel = -1;
> + ? ? ? davinci_spi->dma_channels.dma_tx_sync_dev = dma_tx_chan;
> + ? ? ? davinci_spi->dma_channels.dummy_param_slot = -1;
> + ? ? ? davinci_spi->dma_channels.eventq = dma_eventq;
>
> ? ? ? ?davinci_spi->get_rx = davinci_spi_rx_buf_u8;
> ? ? ? ?davinci_spi->get_tx = davinci_spi_tx_buf_u8;
> @@ -1164,31 +1002,28 @@ static int davinci_spi_probe(struct platform_device *pdev)
> ? ? ? ?udelay(100);
> ? ? ? ?iowrite32(1, davinci_spi->base + SPIGCR0);
>
> - ? ? ? /* Clock internal */
> - ? ? ? if (davinci_spi->pdata->clk_internal)
> - ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIGCR1,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_CLKMOD_MASK);
> - ? ? ? else
> - ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_CLKMOD_MASK);
> + ? ? ? /* Set up SPIPC0. ?CS and ENA init is done in davinci_spi_setup */
> + ? ? ? spipc0 = SPIPC0_DIFUN_MASK | SPIPC0_DOFUN_MASK | SPIPC0_CLKFUN_MASK;
> + ? ? ? iowrite32(spipc0, davinci_spi->base + SPIPC0);
>
> - ? ? ? /* master mode default */
> - ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK);
> + ? ? ? /* initialize chip selects */
> + ? ? ? if (pdata->chip_sel != NULL) {
> + ? ? ? ? ? ? ? for (i = 0; i < pdata->num_chipselect; i++) {
> + ? ? ? ? ? ? ? ? ? ? ? if (pdata->chip_sel[i] != SPI_INTERN_CS)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? gpio_direction_output(pdata->chip_sel[i], 1);
> + ? ? ? ? ? ? ? }
> + ? ? ? }
> + ? ? ? iowrite32(SPIDEF_CSDEF_MASK, davinci_spi->base + SPIDEF);
>
> - ? ? ? if (davinci_spi->pdata->intr_level)
> - ? ? ? ? ? ? ? iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL);
> - ? ? ? else
> - ? ? ? ? ? ? ? iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL);
> + ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_CLKMOD_MASK);
> + ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK);
> + ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK);
>
> ? ? ? ?ret = spi_bitbang_start(&davinci_spi->bitbang);
> - ? ? ? if (ret)
> + ? ? ? if (ret != 0)
> ? ? ? ? ? ? ? ?goto free_clk;
>
> - ? ? ? dev_info(&pdev->dev, "Controller at 0x%p \n", davinci_spi->base);
> -
> - ? ? ? if (!pdata->poll_mode)
> - ? ? ? ? ? ? ? dev_info(&pdev->dev, "Operating in interrupt mode"
> - ? ? ? ? ? ? ? ? ? ? ? " using IRQ %d\n", davinci_spi->irq);
> + ? ? ? dev_info(&pdev->dev, "Controller at 0x%p\n", davinci_spi->base);
>
> ? ? ? ?return ret;
>
> @@ -1220,7 +1055,7 @@ err:
> ?* It will also call spi_bitbang_stop to destroy the work queue which was
> ?* created by spi_bitbang_start.
> ?*/
> -static int __exit davinci_spi_remove(struct platform_device *pdev)
> +static int __devexit davinci_spi_remove(struct platform_device *pdev)
> ?{
> ? ? ? ?struct davinci_spi *davinci_spi;
> ? ? ? ?struct spi_master *master;
> @@ -1242,8 +1077,11 @@ static int __exit davinci_spi_remove(struct platform_device *pdev)
> ?}
>
> ?static struct platform_driver davinci_spi_driver = {
> - ? ? ? .driver.name = "spi_davinci",
> - ? ? ? .remove = __exit_p(davinci_spi_remove),
> + ? ? ? .driver = {
> + ? ? ? ? ? ? ? .name = "spi_davinci",
> + ? ? ? ? ? ? ? .owner = THIS_MODULE,
> + ? ? ? },
> + ? ? ? .remove = __devexit_p(davinci_spi_remove),
> ?};

Another candidate.  Corrections to platform_driver structure and
__devexit annotations.

>
> ?static int __init davinci_spi_init(void)
> --
> 1.6.3.3
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

From const at linuxdriver.co.il  Sun Aug  1 05:14:35 2010
From: const at linuxdriver.co.il (Constantine Shulyupin)
Date: Sun, 1 Aug 2010 13:14:35 +0300
Subject: Boot time
Message-ID: <AANLkTikK1s+ov=fgjyPPsjTMDXOB1Crse=uLZBrNGDFu@mail.gmail.com>

We designed fast boot for functional DaVinci network camera. Gross
reboot time takes 3.2 seconds. (measured on network) Firmware boot
time is 2.5 seconds. (measured on serial console).

Booting Linux dm365 Network Camera in 3.2 seconds:
http://e2e.ti.com/support/embedded/f/354/t/51158.aspx

Boot of kernel and shell in 0.5 sec (not including u-boot and decompression):
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7616/30088.aspx


-- 
Constantine Shulyupin
Embedded Linux Expert
TI DaVinci Expert
http://www.LinuxDriver.co.il/

From sshtylyov at ru.mvista.com  Sun Aug  1 12:15:16 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Sun, 1 Aug 2010 21:15:16 +0400
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
Message-ID: <201008012115.16423.sshtylyov@ru.mvista.com>

The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
specific and as such shouldn't be in da850.c -- copy them to board-da850-evm.c,
renaming to da850_evm_nand_pins/da850_evm_nor_pins respectively, and merge the
two lists in da850.c into one, representing the EMIF 2.5 module as a whole, 
just like we have it in da830.c...

While at it, remove the '__init' modifier from da850_evm_setup_nor_nand() as
this function is called from non '__init' code...

Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

---
The patch is against the recent DaVinci tree. It has only been build-tested as
I don't have DA850 EVM board...

 arch/arm/mach-davinci/board-da850-evm.c    |   30 ++++++++++++++++++++++++---
 arch/arm/mach-davinci/da850.c              |   32 ++++++++++-------------------
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 --
 3 files changed, 40 insertions(+), 25 deletions(-)

Index: linux-davinci/arch/arm/mach-davinci/board-da850-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-da850-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-da850-evm.c
@@ -195,6 +195,30 @@ static void __init da850_evm_init_nor(vo
 	iounmap(aemif_addr);
 }
 
+static const short da850_evm_nand_pins[] = {
+	DA850_EMA_D_0, DA850_EMA_D_1, DA850_EMA_D_2, DA850_EMA_D_3,
+	DA850_EMA_D_4, DA850_EMA_D_5, DA850_EMA_D_6, DA850_EMA_D_7,
+	DA850_EMA_A_1, DA850_EMA_A_2, DA850_NEMA_CS_3, DA850_NEMA_CS_4,
+	DA850_NEMA_WE, DA850_NEMA_OE,
+	-1
+};
+
+static const short da850_evm_nor_pins[] = {
+	DA850_EMA_BA_1, DA850_EMA_CLK, DA850_EMA_WAIT_1, DA850_NEMA_CS_2,
+	DA850_NEMA_WE, DA850_NEMA_OE, DA850_EMA_D_0, DA850_EMA_D_1,
+	DA850_EMA_D_2, DA850_EMA_D_3, DA850_EMA_D_4, DA850_EMA_D_5,
+	DA850_EMA_D_6, DA850_EMA_D_7, DA850_EMA_D_8, DA850_EMA_D_9,
+	DA850_EMA_D_10, DA850_EMA_D_11, DA850_EMA_D_12, DA850_EMA_D_13,
+	DA850_EMA_D_14, DA850_EMA_D_15, DA850_EMA_A_0, DA850_EMA_A_1,
+	DA850_EMA_A_2, DA850_EMA_A_3, DA850_EMA_A_4, DA850_EMA_A_5,
+	DA850_EMA_A_6, DA850_EMA_A_7, DA850_EMA_A_8, DA850_EMA_A_9,
+	DA850_EMA_A_10, DA850_EMA_A_11, DA850_EMA_A_12, DA850_EMA_A_13,
+	DA850_EMA_A_14, DA850_EMA_A_15, DA850_EMA_A_16, DA850_EMA_A_17,
+	DA850_EMA_A_18, DA850_EMA_A_19, DA850_EMA_A_20, DA850_EMA_A_21,
+	DA850_EMA_A_22, DA850_EMA_A_23,
+	-1
+};
+
 static u32 ui_card_detected;
 
 #if defined(CONFIG_MMC_DAVINCI) || \
@@ -204,17 +228,17 @@ static u32 ui_card_detected;
 #define HAS_MMC 0
 #endif
 
-static __init void da850_evm_setup_nor_nand(void)
+static inline void da850_evm_setup_nor_nand(void)
 {
 	int ret = 0;
 
 	if (ui_card_detected & !HAS_MMC) {
-		ret = davinci_cfg_reg_list(da850_nand_pins);
+		ret = davinci_cfg_reg_list(da850_evm_nand_pins);
 		if (ret)
 			pr_warning("da850_evm_init: nand mux setup failed: "
 					"%d\n", ret);
 
-		ret = davinci_cfg_reg_list(da850_nor_pins);
+		ret = davinci_cfg_reg_list(da850_evm_nor_pins);
 		if (ret)
 			pr_warning("da850_evm_init: nor mux setup failed: %d\n",
 				ret);
Index: linux-davinci/arch/arm/mach-davinci/da850.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/da850.c
+++ linux-davinci/arch/arm/mach-davinci/da850.c
@@ -607,27 +607,19 @@ const short da850_mmcsd0_pins[] __initda
 	-1
 };
 
-const short da850_nand_pins[] __initdata = {
-	DA850_EMA_D_7, DA850_EMA_D_6, DA850_EMA_D_5, DA850_EMA_D_4,
-	DA850_EMA_D_3, DA850_EMA_D_2, DA850_EMA_D_1, DA850_EMA_D_0,
-	DA850_EMA_A_1, DA850_EMA_A_2, DA850_NEMA_CS_3, DA850_NEMA_CS_4,
-	DA850_NEMA_WE, DA850_NEMA_OE,
-	-1
-};
-
-const short da850_nor_pins[] __initdata = {
+const short da850_emif25_pins[] __initdata = {
 	DA850_EMA_BA_1, DA850_EMA_CLK, DA850_EMA_WAIT_1, DA850_NEMA_CS_2,
-	DA850_NEMA_WE, DA850_NEMA_OE, DA850_EMA_D_0, DA850_EMA_D_1,
-	DA850_EMA_D_2, DA850_EMA_D_3, DA850_EMA_D_4, DA850_EMA_D_5,
-	DA850_EMA_D_6, DA850_EMA_D_7, DA850_EMA_D_8, DA850_EMA_D_9,
-	DA850_EMA_D_10, DA850_EMA_D_11, DA850_EMA_D_12, DA850_EMA_D_13,
-	DA850_EMA_D_14, DA850_EMA_D_15, DA850_EMA_A_0, DA850_EMA_A_1,
-	DA850_EMA_A_2, DA850_EMA_A_3, DA850_EMA_A_4, DA850_EMA_A_5,
-	DA850_EMA_A_6, DA850_EMA_A_7, DA850_EMA_A_8, DA850_EMA_A_9,
-	DA850_EMA_A_10, DA850_EMA_A_11, DA850_EMA_A_12, DA850_EMA_A_13,
-	DA850_EMA_A_14, DA850_EMA_A_15, DA850_EMA_A_16, DA850_EMA_A_17,
-	DA850_EMA_A_18, DA850_EMA_A_19, DA850_EMA_A_20, DA850_EMA_A_21,
-	DA850_EMA_A_22, DA850_EMA_A_23,
+	DA850_NEMA_CS_3, DA850_NEMA_CS_4, DA850_NEMA_WE, DA850_NEMA_OE,
+	DA850_EMA_D_0, DA850_EMA_D_1, DA850_EMA_D_2, DA850_EMA_D_3,
+	DA850_EMA_D_4, DA850_EMA_D_5, DA850_EMA_D_6, DA850_EMA_D_7,
+	DA850_EMA_D_8, DA850_EMA_D_9, DA850_EMA_D_10, DA850_EMA_D_11,
+	DA850_EMA_D_12, DA850_EMA_D_13, DA850_EMA_D_14, DA850_EMA_D_15,
+	DA850_EMA_A_0, DA850_EMA_A_1, DA850_EMA_A_2, DA850_EMA_A_3,
+	DA850_EMA_A_4, DA850_EMA_A_5, DA850_EMA_A_6, DA850_EMA_A_7,
+	DA850_EMA_A_8, DA850_EMA_A_9, DA850_EMA_A_10, DA850_EMA_A_11,
+	DA850_EMA_A_12, DA850_EMA_A_13, DA850_EMA_A_14, DA850_EMA_A_15,
+	DA850_EMA_A_16, DA850_EMA_A_17, DA850_EMA_A_18, DA850_EMA_A_19,
+	DA850_EMA_A_20, DA850_EMA_A_21, DA850_EMA_A_22, DA850_EMA_A_23,
 	-1
 };
 
Index: linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/da8xx.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -124,7 +124,6 @@ extern const short da850_rmii_pins[];
 extern const short da850_mcasp_pins[];
 extern const short da850_lcdcntl_pins[];
 extern const short da850_mmcsd0_pins[];
-extern const short da850_nand_pins[];
-extern const short da850_nor_pins[];
+extern const short da850_emif25_pins[];
 
 #endif /* __ASM_ARCH_DAVINCI_DA8XX_H */

From sshtylyov at ru.mvista.com  Sun Aug  1 12:17:00 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Sun, 1 Aug 2010 21:17:00 +0400
Subject: [PATCH 2/2] DA850: move MII/RMII pin lists to the board file
Message-ID: <201008012117.00730.sshtylyov@ru.mvista.com>

The CPGMAC pin list in da850.c was incorrectly split into two MII/RMII mode
specific pin lists, while what pin group is used is a function of how the board
is wired.  Copy the pin lists to board-da850-evm.c, renaming them accordingly,
and merge the two lists in da850.c into one, da850_cpgmac_pins[], representing
the CPGMAC module as a whole...

Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

---
The patch is against the recent DaVinci tree. It has only been build-tested as
I don't have DA850 EVM board...

 arch/arm/mach-davinci/board-da850-evm.c    |   21 +++++++++++++++++++--
 arch/arm/mach-davinci/da850.c              |   12 +++---------
 arch/arm/mach-davinci/include/mach/da8xx.h |    1 -
 3 files changed, 22 insertions(+), 12 deletions(-)

Index: linux-davinci/arch/arm/mach-davinci/board-da850-evm.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/board-da850-evm.c
+++ linux-davinci/arch/arm/mach-davinci/board-da850-evm.c
@@ -592,6 +592,23 @@ static const short da850_evm_lcdc_pins[]
 	-1
 };
 
+static const short da850_evm_mii_pins[] = {
+	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
+	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
+	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
+	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
+static const short da850_evm_rmii_pins[] = {
+	DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
+	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
+	DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
 static int __init da850_evm_config_emac(void)
 {
 	void __iomem *cfg_chip3_base;
@@ -609,12 +626,12 @@ static int __init da850_evm_config_emac(
 
 	if (rmii_en) {
 		val |= BIT(8);
-		ret = davinci_cfg_reg_list(da850_rmii_pins);
+		ret = davinci_cfg_reg_list(da850_evm_rmii_pins);
 		pr_info("EMAC: RMII PHY configured, MII PHY will not be"
 							" functional\n");
 	} else {
 		val &= ~BIT(8);
-		ret = davinci_cfg_reg_list(da850_cpgmac_pins);
+		ret = davinci_cfg_reg_list(da850_evm_mii_pins);
 		pr_info("EMAC: MII PHY configured, RMII PHY will not be"
 							" functional\n");
 	}
Index: linux-davinci/arch/arm/mach-davinci/da850.c
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/da850.c
+++ linux-davinci/arch/arm/mach-davinci/da850.c
@@ -572,15 +572,9 @@ const short da850_cpgmac_pins[] __initda
 	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
 	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
 	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
-	DA850_MDIO_D,
-	-1
-};
-
-const short da850_rmii_pins[] __initdata = {
-	DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
-	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
-	DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
-	DA850_MDIO_D,
+	DA850_MDIO_D, DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
+	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1, DA850_RMII_RXER,
+	DA850_RMII_MHZ_50_CLK,
 	-1
 };
 
Index: linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/da8xx.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -120,7 +120,6 @@ extern const short da850_uart2_pins[];
 extern const short da850_i2c0_pins[];
 extern const short da850_i2c1_pins[];
 extern const short da850_cpgmac_pins[];
-extern const short da850_rmii_pins[];
 extern const short da850_mcasp_pins[];
 extern const short da850_lcdcntl_pins[];
 extern const short da850_mmcsd0_pins[];

From tobias.knutsson at gmail.com  Mon Aug  2 04:49:52 2010
From: tobias.knutsson at gmail.com (Tobias Waldekranz (Knutsson))
Date: Mon, 2 Aug 2010 11:49:52 +0200
Subject: Kernel Booting Problem
In-Reply-To: <SNT127-W276B5D7652A515A3569BDDB7C50@phx.gbl>
References: <SNT127-W1472449397106BADF8E5A6B7C50@phx.gbl>
	<201006231323.17134.caglarakyuz@gmail.com>
	<SNT127-W13F6EE6972EFF03582FC9EB7C50@phx.gbl>
	<201006231342.19014.caglarakyuz@gmail.com>
	<SNT127-W276B5D7652A515A3569BDDB7C50@phx.gbl>
Message-ID: <AANLkTi=q72DAdDq5UFeUKkJ2C9Vw8rXqj+UduuXfrJEO@mail.gmail.com>

2010/6/23 amr ali <amraldo at hotmail.com>:
> I tried my new kernel with my new file system, I build with buildroot.
> The kernel booted and passed by the free init message, the current log is:
> "Freeing init memory: 124K
>
> Warning: unable to open an initial console.

This message is usually given when init cannot open /dev/console. The
bare minimum to boot is /dev/console and /dev/null.
>
> warning: `proftpd' uses 32-bit capabilities (legacy support in use)"
> and nothing happens after.
>
> Any help?
> --
> Amr Ali Abdel-Naby
> Embedded Systems Developer
> www.embedded-tips.blogspot.com
>
>
>
>
>> From: caglarakyuz at gmail.com
>> To: amraldo at hotmail.com
>> Subject: Re: Kernel Booting Problem
>> Date: Wed, 23 Jun 2010 13:42:18 +0300
>> CC: davinci-linux-open-source at linux.davincidsp.com
>>
>> On Wednesday 23 June 2010 01:31:05 pm amr ali wrote:
>> > I have a new file system, I generated it by buildroot.
>> > What should be in that filesystem. I do not have device nodes, how do I
>> > create them automatically? --
>>
>> I guess you extracti! ng a tar image for NFS use, if so then you should
>> extract
>> file system image with root permissions otherwise device nodes won't be
>> populated.
>>
>> If you still have problems, then please give Narcissus a go.
>>
>> Regards,
>> Caglar
>>
>> > Amr Ali Abdel-Naby
>> > Embedded Systems Developer
>> > www.embedded-tips.blogspot.com
>> >
>> > > From: caglarakyuz at gmail.com
>> > > To: davinci-linux-open-source at linux.davincidsp.com
>> > > Subject: Re: Kernel Booting Problem
>> > > Date: Wed, 23 Jun 2010 13:23:17 +0300
>> > > CC: amraldo at hotmail.com
>> > >
>> > > On Wednesday 23 June 2010 01:03:25 pm amr ali wrote:
>> > > > I downloaded the standard Linux kernel 2.6.33.2 and compiled it with
>> > > > the default TI Davinci kernel configuration. I am booting the kernel
>> > > > with NFS! as Root FS. Kernel boots till I get the message Freeing
>> > > > INIT
>> > > > memory and nothing happens. When I try to boot withh montavista
>> > > > .6.10
>> > > > kernel with the same file systems it continue booting with no
>> > > > problems.
>> > > > The booting log can for the non-working kernel can be found here @
>> > >
>> > > I'm not suprised that it is not working. This is an EABI/OABI issue,
>> > > besides many other things changed for C library as well.
>> > >
>> > > In short, you need a new file system. May I suggest narcissus [1]?
>> > >
>> > > Regards,
>> > > Caglar
>> > >
>> > > [1] http://www.angstrom-distribution.org/narcissus/
>> > >
>> > > > http://pastebin.org/354048 Any ideas, why the kernel is not running
>> > > > my
>> > > > init application?
>> > > >
>> > > > --
>> > > > Amr Ali Abdel-Naby
>> > > > Embedded ! Systems Developer
>> > > > www.embedded-tips.blogspot.com
>> > > >
>> > > >
>> > > >
>> > > > _________________________________________________________________
>> > > > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
>> > > > https://signup.live.com/signup.aspx?id=60969
>> >
>> > _________________________________________________________________
>> > Hotmail: Trusted email with Microsoft?s powerful SPAM protection.
>> > https://signup.live.com/signup.aspx?id=60969
>> >
>
> ________________________________
> Hotmail: Trusted email with Microsoft?s powerful SPAM protection. Sign up
> now.
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>



-- 

H?lsningar/Regards
Tobias Waldekranz

From tobias.knutsson at gmail.com  Mon Aug  2 05:06:39 2010
From: tobias.knutsson at gmail.com (Tobias Waldekranz (Knutsson))
Date: Mon, 2 Aug 2010 12:06:39 +0200
Subject: Symbol names
In-Reply-To: <880572.16919.qm@web38804.mail.mud.yahoo.com>
References: <880572.16919.qm@web38804.mail.mud.yahoo.com>
Message-ID: <AANLkTikx3BXdVymYsGWUqz3FC9qsip7ZB6eE+AUjTQoU@mail.gmail.com>

<toolchain-prefix>nm <kernel> | grep <the six MSBs of the address> should
narrow it down pretty much.

On Mon, May 17, 2010 at 07:42, Vijay Soni <vij_soni at yahoo.com> wrote:

> Does anyone know how I can get symbols names from their addresses. I am
> trying to debug an kernel oops which gives function address in the
> Backtrace. I know I can turn on KALLSYMS but I cannot rebuild my kernel
> because of other module dependency. Can we get this info from vmlinux? If so
> how?
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>


-- 

H?lsningar/Regards
Tobias Waldekranz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100802/b69b006d/attachment.html>

From schen at mvista.com  Mon Aug  2 08:06:45 2010
From: schen at mvista.com (Steve Chen)
Date: Mon, 2 Aug 2010 08:06:45 -0500
Subject: Symbol names
In-Reply-To: <AANLkTikx3BXdVymYsGWUqz3FC9qsip7ZB6eE+AUjTQoU@mail.gmail.com>
References: <880572.16919.qm@web38804.mail.mud.yahoo.com>
	<AANLkTikx3BXdVymYsGWUqz3FC9qsip7ZB6eE+AUjTQoU@mail.gmail.com>
Message-ID: <AANLkTi=osYuK4MqYbCxZz=C7nxSjRk8LH3mXbSNeAT+g@mail.gmail.com>

On Mon, Aug 2, 2010 at 5:06 AM, Tobias Waldekranz (Knutsson) <
tobias.knutsson at gmail.com> wrote:

> <toolchain-prefix>nm <kernel> | grep <the six MSBs of the address> should
> narrow it down pretty much.
>
> On Mon, May 17, 2010 at 07:42, Vijay Soni <vij_soni at yahoo.com> wrote:
>
>> Does anyone know how I can get symbols names from their addresses. I am
>> trying to debug an kernel oops which gives function address in the
>> Backtrace. I know I can turn on KALLSYMS but I cannot rebuild my kernel
>> because of other module dependency. Can we get this info from vmlinux? If so
>> how?
>>
>>
>
>
The other option is to use

<toolchain-prefix->addr2line -e <.../vmlinux> -f <address>

Regards,

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100802/a3ab71c6/attachment-0001.html>

From bniebuhr3 at gmail.com  Mon Aug  2 09:10:29 2010
From: bniebuhr3 at gmail.com (Brian Niebuhr)
Date: Mon, 2 Aug 2010 09:10:29 -0500
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <AANLkTimu+G-5wTrdQ6YiWi60i+5uN9sydfsZKMKQX7_f@mail.gmail.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<1280355490-11878-2-git-send-email-bniebuhr@efjohnson.com>
	<AANLkTimu+G-5wTrdQ6YiWi60i+5uN9sydfsZKMKQX7_f@mail.gmail.com>
Message-ID: <AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>

Grant -

That's fine - I understand your position.  I do wish you had decided
earlier that you weren't going to accept the patch in that form though
so I could have decided whether I wanted to spend any more time on it.
 For my part, I've already sunk way more time into this than I ever
intended, and I really have no clue how to break this patch down into
smaller patches.  I don't really care much if the patch gets accepted
or not - I am just trying to help out all of the other users that are
stuck with a broken driver like I was.  Maybe if TI wants to give
their customers a driver that actually works they'll pick it up and do
the rest of the work that's necessary to get it accepted.  I'm just
way too swamped with other work to keep going on this.

Thanks for your help though.  Sorry to waste all of the time you've
put into this.

Brian

On Sun, Aug 1, 2010 at 12:12 AM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Wed, Jul 28, 2010 at 4:18 PM, Brian Niebuhr <bniebuhr3 at gmail.com> wrote:
>> INTRODUCTION
>>
>> I have been working on a custom OMAP-L138 board that has multiple spi
>> devices (seven) on one controller. ?These devices have a wide range of
>> transfer parameters (speed, phase, polarity, internal and gpio chip
>> selects). ?During my testing I found multiple errors in the davinci spi
>> driver as a result of this complex setup. ?The primary issues were:
>>
>> 1. There is a race condition due to the SPIBUF read busy-waits for slow
>> ? ? ? ?devices
>> 2. I found some DMA transfer length errors under some conditions
>> 3. The chip select code caused extra byte transfers (with no chip
>> ? ? ? ?select active) due to writes to SPIDAT1
>> 4. Several issues prevented using multiple SPI devices, especially
>> ? ? ? ?the DMA code, as disucussed previously on the davinci list.
>>
>> The fixes to these problems were not simple. ?I ended up making fairly
>> large changes to the driver, and those changes are contained in these
>> patches. ?The full list of changes follows.
>>
>> CHANGE LIST
>>
>> 1. davinci_spi_chipelect() now performs both activation and deactivation
>> ? ? ? ?of chip selects. ?This lets spi_bitbang fully control chip
>> ? ? ? ?select activation, as intended by the SPI API.
>> 2. Chip select activation does not cause extra writes to the SPI bus
>> 3. Chip select activation does not use SPIDEF for control. ?This change
>> ? ? ? ?will also allow for implementation of inverted (active high)
>> ? ? ? ?chip selects in the future.
>> 4. Added back gpio chip select capability from the old driver
>> 5. Fixed prescale calculation for non-integer fractions of spi clock
>> 6. Allow specification of SPI transfer parameters on a per-device
>> ? ? ? ?(instead of per-controller) basis
>> 7. Allow specification of polled, interrupt-based, or DMA operation on
>> ? ? ? ?a per-device basis
>> 8. Allow DMA with when more than one device is connected
>> 9. Combined pio and dma txrx_bufs functions into one since they share
>> ? ? ? ?large parts of their functionality, and to simplify item (8).
>> 10. Use only SPIFMT0 to allow more than 4 devices
>>
>> TESTING
>>
>> I have tested the driver using a custom SPI stress test on my
>> OMAP-L138-based board with three devices connected. ?I have tested
>> configurations with all three devices polled, all three interrupt-based,
>> all three DMA, and a mixture.
>>
>> I have compiled with the davinci_all_defconfig, but I don't have EVMs
>> for the other davinci platforms to test with.
>>
>> Signed-off-by: Brian Niebuhr <bniebuhr at efjohnson.com>
>
> Hi Brian,
>
> I'm getting a little frustrated, and I wouldn't be surprised if you're
> getting a little frustrated too, but I cannot merge this as is. ?It is
> just too big to be able to review sanely, when I know there are
> bite-size chunks that can be factored out into separate patches and
> can be merged independently.
>
> At a *bare minimum* I would need acks from several davinci users that
> it is tested and working before I'd merge something like this, but
> even then I'm not sure I would. ?It certainly will not make me happy.
> It also means that when someone does have problems with the new driver
> over the old that they won't have a hope of bisecting it to figure out
> which change broken their system. ?There will be less pain all around
> if you split it up instead.
>
> ...
>
> In fact, after taking another look at it, I insist. ?I can tell that
> while major changes have been made, it is *still* the same driver with
> changes that can be logically identified. ?Split it up.
>
> I'm more than happy to help you with the tools and techniques for
> splitting a single monolithic patch into logical changes if you've not
> done that before. ?Send me a private email if you prefer.
>
> Comments below:
>
>> ---
>> ?arch/arm/mach-davinci/board-dm355-evm.c ? ? | ? 10 +
>> ?arch/arm/mach-davinci/board-dm355-leopard.c | ? 10 +
>> ?arch/arm/mach-davinci/board-dm365-evm.c ? ? | ? 10 +
>> ?arch/arm/mach-davinci/dm355.c ? ? ? ? ? ? ? | ? ?8 +-
>> ?arch/arm/mach-davinci/dm365.c ? ? ? ? ? ? ? | ? ?6 -
>> ?arch/arm/mach-davinci/include/mach/spi.h ? ?| ? 35 +-
>> ?drivers/spi/davinci_spi.c ? ? ? ? ? ? ? ? ? | 1098 ++++++++++++---------------
>> ?7 files changed, 521 insertions(+), 656 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
>> index a319101..ad8779b 100644
>> --- a/arch/arm/mach-davinci/board-dm355-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
>> @@ -32,6 +32,7 @@
>> ?#include <mach/nand.h>
>> ?#include <mach/mmc.h>
>> ?#include <mach/usb.h>
>> +#include <mach/spi.h>
>>
>> ?/* NOTE: ?this is geared for the standard config, with a socketed
>> ?* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. ?If you
>> @@ -300,10 +301,19 @@ static struct spi_eeprom at25640a = {
>> ? ? ? ?.flags ? ? ? ? ?= EE_ADDR2,
>> ?};
>>
>> +static struct davinci_spi_config at25640a_spi_cfg = {
>> + ? ? ? .parity_enable ?= false,
>> + ? ? ? .intr_level ? ? = 0,
>> + ? ? ? .io_type ? ? ? ?= SPI_IO_TYPE_DMA,
>> + ? ? ? .wdelay ? ? ? ? = 0,
>> + ? ? ? .timer_disable ?= true,
>> +};
>> +
>> ?static struct spi_board_info dm355_evm_spi_info[] __initconst = {
>> ? ? ? ?{
>> ? ? ? ? ? ? ? ?.modalias ? ? ? = "at25",
>> ? ? ? ? ? ? ? ?.platform_data ?= &at25640a,
>> + ? ? ? ? ? ? ? .controller_data = &at25640a_spi_cfg,
>> ? ? ? ? ? ? ? ?.max_speed_hz ? = 10 * 1000 * 1000, ? ? /* at 3v3 */
>> ? ? ? ? ? ? ? ?.bus_num ? ? ? ?= 0,
>> ? ? ? ? ? ? ? ?.chip_select ? ?= 0,
>> diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
>> index f1d8132..b2d8d48 100644
>> --- a/arch/arm/mach-davinci/board-dm355-leopard.c
>> +++ b/arch/arm/mach-davinci/board-dm355-leopard.c
>> @@ -29,6 +29,7 @@
>> ?#include <mach/nand.h>
>> ?#include <mach/mmc.h>
>> ?#include <mach/usb.h>
>> +#include <mach/spi.h>
>>
>> ?/* NOTE: ?this is geared for the standard config, with a socketed
>> ?* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. ?If you
>> @@ -222,10 +223,19 @@ static struct spi_eeprom at25640a = {
>> ? ? ? ?.flags ? ? ? ? ?= EE_ADDR2,
>> ?};
>>
>> +static struct davinci_spi_config at25640a_spi_cfg = {
>> + ? ? ? .parity_enable ?= false,
>> + ? ? ? .intr_level ? ? = 0,
>> + ? ? ? .io_type ? ? ? ?= SPI_IO_TYPE_DMA,
>> + ? ? ? .wdelay ? ? ? ? = 0,
>> + ? ? ? .timer_disable ?= true,
>> +};
>> +
>> ?static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
>> ? ? ? ?{
>> ? ? ? ? ? ? ? ?.modalias ? ? ? = "at25",
>> ? ? ? ? ? ? ? ?.platform_data ?= &at25640a,
>> + ? ? ? ? ? ? ? .controller_data = &at25640a_spi_cfg,
>> ? ? ? ? ? ? ? ?.max_speed_hz ? = 10 * 1000 * 1000, ? ? /* at 3v3 */
>> ? ? ? ? ? ? ? ?.bus_num ? ? ? ?= 0,
>> ? ? ? ? ? ? ? ?.chip_select ? ?= 0,
>> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
>> index 5bb86b2..db85372 100644
>> --- a/arch/arm/mach-davinci/board-dm365-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
>> @@ -39,6 +39,7 @@
>> ?#include <mach/mmc.h>
>> ?#include <mach/nand.h>
>> ?#include <mach/keyscan.h>
>> +#include <mach/spi.h>
>>
>> ?#include <media/tvp514x.h>
>>
>> @@ -579,10 +580,19 @@ static struct spi_eeprom at25640 = {
>> ? ? ? ?.flags ? ? ? ? ?= EE_ADDR2,
>> ?};
>>
>> +static struct davinci_spi_config at25640_spi_cfg = {
>> + ? ? ? .parity_enable ?= false,
>> + ? ? ? .intr_level ? ? = 0,
>> + ? ? ? .io_type ? ? ? ?= SPI_IO_TYPE_DMA,
>> + ? ? ? .wdelay ? ? ? ? = 0,
>> + ? ? ? .timer_disable ?= true,
>> +};
>> +
>> ?static struct spi_board_info dm365_evm_spi_info[] __initconst = {
>> ? ? ? ?{
>> ? ? ? ? ? ? ? ?.modalias ? ? ? = "at25",
>> ? ? ? ? ? ? ? ?.platform_data ?= &at25640,
>> + ? ? ? ? ? ? ? .controller_data = &at25640_spi_cfg,
>> ? ? ? ? ? ? ? ?.max_speed_hz ? = 10 * 1000 * 1000,
>> ? ? ? ? ? ? ? ?.bus_num ? ? ? ?= 0,
>> ? ? ? ? ? ? ? ?.chip_select ? ?= 0,
>> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
>> index 3834781..b79b798 100644
>> --- a/arch/arm/mach-davinci/dm355.c
>> +++ b/arch/arm/mach-davinci/dm355.c
>> @@ -410,14 +410,8 @@ static struct resource dm355_spi0_resources[] = {
>> ?};
>>
>> ?static struct davinci_spi_platform_data dm355_spi0_pdata = {
>> - ? ? ? .version ? ? ? ?= SPI_VERSION_1,
>> + ? ? ? .version ? ? ? ?= SPI_VERSION_0,
>> ? ? ? ?.num_chipselect = 2,
>> - ? ? ? .clk_internal ? = 1,
>> - ? ? ? .cs_hold ? ? ? ?= 1,
>> - ? ? ? .intr_level ? ? = 0,
>> - ? ? ? .poll_mode ? ? ?= 1, ? ?/* 0 -> interrupt mode 1-> polling mode */
>> - ? ? ? .c2tdelay ? ? ? = 0,
>> - ? ? ? .t2cdelay ? ? ? = 0,
>> ?};
>> ?static struct platform_device dm355_spi0_device = {
>> ? ? ? ?.name = "spi_davinci",
>> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
>> index 652f4b6..4aea346 100644
>> --- a/arch/arm/mach-davinci/dm365.c
>> +++ b/arch/arm/mach-davinci/dm365.c
>> @@ -625,12 +625,6 @@ static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
>> ?static struct davinci_spi_platform_data dm365_spi0_pdata = {
>> ? ? ? ?.version ? ? ? ?= SPI_VERSION_1,
>> ? ? ? ?.num_chipselect = 2,
>> - ? ? ? .clk_internal ? = 1,
>> - ? ? ? .cs_hold ? ? ? ?= 1,
>> - ? ? ? .intr_level ? ? = 0,
>> - ? ? ? .poll_mode ? ? ?= 1, ? ?/* 0 -> interrupt mode 1-> polling mode */
>> - ? ? ? .c2tdelay ? ? ? = 0,
>> - ? ? ? .t2cdelay ? ? ? = 0,
>> ?};
>>
>> ?static struct resource dm365_spi0_resources[] = {
>> diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
>> index 910efbf..3f77dab 100644
>> --- a/arch/arm/mach-davinci/include/mach/spi.h
>> +++ b/arch/arm/mach-davinci/include/mach/spi.h
>> @@ -19,26 +19,35 @@
>> ?#ifndef __ARCH_ARM_DAVINCI_SPI_H
>> ?#define __ARCH_ARM_DAVINCI_SPI_H
>>
>> +#define SPI_INTERN_CS ?0xFF
>> +
>> ?enum {
>> - ? ? ? SPI_VERSION_1, /* For DM355/DM365/DM6467 */
>> + ? ? ? SPI_VERSION_0, /* For DM355 (reduced features, no Tx interrupt) */
>> + ? ? ? SPI_VERSION_1, /* For DM365/DM6467 (reduced features) */
>> ? ? ? ?SPI_VERSION_2, /* For DA8xx */
>> ?};
>>
>> ?struct davinci_spi_platform_data {
>> ? ? ? ?u8 ? ? ?version;
>> - ? ? ? u8 ? ? ?num_chipselect;
>> - ? ? ? u8 ? ? ?wdelay;
>> - ? ? ? u8 ? ? ?odd_parity;
>> - ? ? ? u8 ? ? ?parity_enable;
>> - ? ? ? u8 ? ? ?wait_enable;
>> - ? ? ? u8 ? ? ?timer_disable;
>> - ? ? ? u8 ? ? ?clk_internal;
>> - ? ? ? u8 ? ? ?cs_hold;
>> + ? ? ? u16 ? ? num_chipselect;
>> + ? ? ? u8 ? ? ?*chip_sel;
>> +};
>> +
>> +struct davinci_spi_config {
>> + ? ? ? bool ? ?odd_parity;
>> + ? ? ? bool ? ?parity_enable;
>> ? ? ? ?u8 ? ? ?intr_level;
>> - ? ? ? u8 ? ? ?poll_mode;
>> - ? ? ? u8 ? ? ?use_dma;
>> - ? ? ? u8 ? ? ?c2tdelay;
>> - ? ? ? u8 ? ? ?t2cdelay;
>> + ? ? ? u8 ? ? ?io_type;
>> +#define SPI_IO_TYPE_INTR ? ?0
>> +#define SPI_IO_TYPE_POLL ? ?1
>> +#define SPI_IO_TYPE_DMA ? ? 2
>> + ? ? ? u8 ? ? ?bytes_per_word;
>> + ? ? ? u8 ? ? ?wdelay;
>> + ? ? ? bool ? ?timer_disable;
>> + ? ? ? u8 ? ? ?c2t_delay;
>> + ? ? ? u8 ? ? ?t2c_delay;
>> + ? ? ? u8 ? ? ?t2e_delay;
>> + ? ? ? u8 ? ? ?c2e_delay;
>> ?};
>>
>> ?#endif /* __ARCH_ARM_DAVINCI_SPI_H */
>> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
>> index b85090c..5c9e9ce 100644
>> --- a/drivers/spi/davinci_spi.c
>> +++ b/drivers/spi/davinci_spi.c
>> @@ -1,5 +1,6 @@
>> ?/*
>> ?* Copyright (C) 2009 Texas Instruments.
>> + * Copyright (C) 2010 EF Johnson Technologies
>> ?*
>> ?* This program is free software; you can redistribute it and/or modify
>> ?* it under the terms of the GNU General Public License as published by
>> @@ -27,21 +28,19 @@
>> ?#include <linux/dma-mapping.h>
>> ?#include <linux/spi/spi.h>
>> ?#include <linux/spi/spi_bitbang.h>
>> -#include <linux/slab.h>
>>
>> ?#include <mach/spi.h>
>> ?#include <mach/edma.h>
>>
>> ?#define SPI_NO_RESOURCE ? ? ? ? ? ? ? ?((resource_size_t)-1)
>>
>> -#define SPI_MAX_CHIPSELECT ? ? 2
>> -
>> ?#define CS_DEFAULT ? ? 0xFF
>>
>> ?#define SPI_BUFSIZ ? ? (SMP_CACHE_BYTES + 1)
>> -#define DAVINCI_DMA_DATA_TYPE_S8 ? ? ? 0x01
>> -#define DAVINCI_DMA_DATA_TYPE_S16 ? ? ?0x02
>> -#define DAVINCI_DMA_DATA_TYPE_S32 ? ? ?0x04
>> +
>> +#define RX_DMA_INDEX ? ? ? ? ? 0
>> +#define TX_DMA_INDEX ? ? ? ? ? 1
>> +#define EVENTQ_DMA_INDEX ? ? ? 2
>>
>> ?#define SPIFMT_PHASE_MASK ? ? ?BIT(16)
>> ?#define SPIFMT_POLARITY_MASK ? BIT(17)
>> @@ -53,9 +52,11 @@
>> ?#define SPIFMT_WDELAY_MASK ? ? 0x3f000000u
>> ?#define SPIFMT_WDELAY_SHIFT ? ?24
>> ?#define SPIFMT_CHARLEN_MASK ? ?0x0000001Fu
>> +#define SPIFMT_PRESCALE_SHIFT ?8
>>
>> ?/* SPIGCR1 */
>> -#define SPIGCR1_SPIENA_MASK ? ?0x01000000u
>> +#define SPIGCR1_SPIENA_MASK ? ?BIT(24)
>> +#define SPIGCR1_POWERDOWN_MASK BIT(8)
>>
>> ?/* SPIPC0 */
>> ?#define SPIPC0_DIFUN_MASK ? ? ?BIT(11) ? ? ? ? /* MISO */
>> @@ -66,20 +67,38 @@
>> ?#define SPIPC0_EN0FUN_MASK ? ? BIT(0)
>>
>> ?#define SPIINT_MASKALL ? ? ? ? 0x0101035F
>> +#define SPIINT_MASKINT ? ? ? ? 0x0000035F
>> ?#define SPI_INTLVL_1 ? ? ? ? ? 0x000001FFu
>> ?#define SPI_INTLVL_0 ? ? ? ? ? 0x00000000u
>>
>> ?/* SPIDAT1 */
>> +#define SPIDAT1_CSHOLD_MASK ? ?BIT(28)
>> ?#define SPIDAT1_CSHOLD_SHIFT ? 28
>> +#define SPIDAT1_WDEL_MASK ? ? ?BIT(26)
>> +#define SPIDAT1_CSNR_MASK ? ? ?0x00FF0000u
>> ?#define SPIDAT1_CSNR_SHIFT ? ? 16
>> +#define SPIDAT1_DFSEL_MASK ? ? (BIT(24 | BIT(25))
>> ?#define SPIGCR1_CLKMOD_MASK ? ?BIT(1)
>> -#define SPIGCR1_MASTER_MASK ? ? BIT(0)
>> +#define SPIGCR1_MASTER_MASK ? ?BIT(0)
>> ?#define SPIGCR1_LOOPBACK_MASK ?BIT(16)
>>
>> ?/* SPIBUF */
>> ?#define SPIBUF_TXFULL_MASK ? ? BIT(29)
>> ?#define SPIBUF_RXEMPTY_MASK ? ?BIT(31)
>>
>> +/* SPIDELAY */
>> +#define SPIDELAY_C2TDELAY_MASK ?0xFF000000u
>> +#define SPIDELAY_C2TDELAY_SHIFT 24
>> +#define SPIDELAY_T2CDELAY_MASK ?0x00FF0000u
>> +#define SPIDELAY_T2CDELAY_SHIFT 16
>> +#define SPIDELAY_T2EDELAY_MASK ?0x0000FF00u
>> +#define SPIDELAY_T2EDELAY_SHIFT 8
>> +#define SPIDELAY_C2EDELAY_MASK ?0x000000FFu
>> +#define SPIDELAY_C2EDELAY_SHIFT 0
>> +
>> +/* SPIDEF */
>> +#define SPIDEF_CSDEF_MASK ? ? ? 0x000000FFu
>> +
>> ?/* Error Masks */
>> ?#define SPIFLG_DLEN_ERR_MASK ? ? ? ? ? BIT(0)
>> ?#define SPIFLG_TIMEOUT_MASK ? ? ? ? ? ?BIT(1)
>> @@ -90,11 +109,12 @@
>> ?#define SPIFLG_RX_INTR_MASK ? ? ? ? ? ?BIT(8)
>> ?#define SPIFLG_TX_INTR_MASK ? ? ? ? ? ?BIT(9)
>> ?#define SPIFLG_BUF_INIT_ACTIVE_MASK ? ?BIT(24)
>> -#define SPIFLG_MASK ? ? ? ? ? ? ? ? ? ?(SPIFLG_DLEN_ERR_MASK \
>> +#define SPIFLG_ERROR_MASK ? ? ? ? ? ? ?(SPIFLG_DLEN_ERR_MASK \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SPIFLG_TIMEOUT_MASK | SPIFLG_PARERR_MASK \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SPIFLG_DESYNC_MASK | SPIFLG_BITERR_MASK \
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIFLG_OVRRUN_MASK | SPIFLG_RX_INTR_MASK \
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIFLG_TX_INTR_MASK \
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIFLG_OVRRUN_MASK)
>> +#define SPIFLG_MASK ? ? ? ? ? ? ? ? ? ?(SPIFLG_ERROR_MASK \
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIFLG_RX_INTR_MASK | SPIFLG_TX_INTR_MASK \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SPIFLG_BUF_INIT_ACTIVE_MASK)
>>
>> ?#define SPIINT_DLEN_ERR_INTR ? BIT(0)
>> @@ -139,11 +159,10 @@
>> ?#define TGINTVEC0 ? ? ?0x60
>> ?#define TGINTVEC1 ? ? ?0x64
>>
>> -struct davinci_spi_slave {
>> - ? ? ? u32 ? ? cmd_to_write;
>> - ? ? ? u32 ? ? clk_ctrl_to_write;
>> - ? ? ? u32 ? ? bytes_per_word;
>> - ? ? ? u8 ? ? ?active_cs;
>> +const char * const io_type_names[] = {
>> + ? ? ? [SPI_IO_TYPE_INTR] = "Interrupt",
>> + ? ? ? [SPI_IO_TYPE_POLL] = "Polled",
>> + ? ? ? [SPI_IO_TYPE_DMA] = "DMA",
>> ?};
>>
>> ?/* We have 2 DMA channels per CS, one for RX and one for TX */
>> @@ -152,10 +171,8 @@ struct davinci_spi_dma {
>> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? dma_rx_channel;
>> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? dma_tx_sync_dev;
>> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? dma_rx_sync_dev;
>> + ? ? ? int ? ? ? ? ? ? ? ? ? ? dummy_param_slot;
>> ? ? ? ?enum dma_event_q ? ? ? ?eventq;
>> -
>> - ? ? ? struct completion ? ? ? dma_tx_completion;
>> - ? ? ? struct completion ? ? ? dma_rx_completion;
>> ?};
>>
>> ?/* SPI Controller driver's private data. */
>> @@ -173,51 +190,53 @@ struct davinci_spi {
>> ? ? ? ?const void ? ? ? ? ? ? ?*tx;
>> ? ? ? ?void ? ? ? ? ? ? ? ? ? ?*rx;
>> ? ? ? ?u8 ? ? ? ? ? ? ? ? ? ? ?*tmp_buf;
>> - ? ? ? int ? ? ? ? ? ? ? ? ? ? count;
>> - ? ? ? struct davinci_spi_dma ?*dma_channels;
>> - ? ? ? struct ? ? ? ? ? ? ? ? ?davinci_spi_platform_data *pdata;
>> + ? ? ? int ? ? ? ? ? ? ? ? ? ? rcount;
>> + ? ? ? int ? ? ? ? ? ? ? ? ? ? wcount;
>> + ? ? ? u32 ? ? ? ? ? ? ? ? ? ? errors;
>> + ? ? ? struct davinci_spi_dma ?dma_channels;
>> + ? ? ? struct davinci_spi_platform_data *pdata;
>>
>> ? ? ? ?void ? ? ? ? ? ? ? ? ? ?(*get_rx)(u32 rx_data, struct davinci_spi *);
>> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? (*get_tx)(struct davinci_spi *);
>> -
>> - ? ? ? struct davinci_spi_slave slave[SPI_MAX_CHIPSELECT];
>> ?};
>>
>> -static unsigned use_dma;
>> -
>> ?static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
>> ?{
>> - ? ? ? u8 *rx = davinci_spi->rx;
>> -
>> - ? ? ? *rx++ = (u8)data;
>> - ? ? ? davinci_spi->rx = rx;
>> + ? ? ? if (davinci_spi->rx) {
>> + ? ? ? ? ? ? ? u8 *rx = davinci_spi->rx;
>> + ? ? ? ? ? ? ? *rx++ = (u8)data;
>> + ? ? ? ? ? ? ? davinci_spi->rx = rx;
>> + ? ? ? }
>> ?}
>>
>> ?static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
>> ?{
>> - ? ? ? u16 *rx = davinci_spi->rx;
>> -
>> - ? ? ? *rx++ = (u16)data;
>> - ? ? ? davinci_spi->rx = rx;
>> + ? ? ? if (davinci_spi->rx) {
>> + ? ? ? ? ? ? ? u16 *rx = davinci_spi->rx;
>> + ? ? ? ? ? ? ? *rx++ = (u16)data;
>> + ? ? ? ? ? ? ? davinci_spi->rx = rx;
>> + ? ? ? }
>> ?}
>>
>> ?static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
>> ?{
>> - ? ? ? u32 data;
>> - ? ? ? const u8 *tx = davinci_spi->tx;
>> -
>> - ? ? ? data = *tx++;
>> - ? ? ? davinci_spi->tx = tx;
>> + ? ? ? u32 data = 0;
>> + ? ? ? if (davinci_spi->tx) {
>> + ? ? ? ? ? ? ? const u8 *tx = davinci_spi->tx;
>> + ? ? ? ? ? ? ? data = *tx++;
>> + ? ? ? ? ? ? ? davinci_spi->tx = tx;
>> + ? ? ? }
>> ? ? ? ?return data;
>> ?}
>
> Here's an excellent candidate for a separate patch. ?Validation of the
> rx/tx buffer before transfering data to/from it.
>
>>
>> ?static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
>> ?{
>> - ? ? ? u32 data;
>> - ? ? ? const u16 *tx = davinci_spi->tx;
>> -
>> - ? ? ? data = *tx++;
>> - ? ? ? davinci_spi->tx = tx;
>> + ? ? ? u32 data = 0;
>> + ? ? ? if (davinci_spi->tx) {
>> + ? ? ? ? ? ? ? const u16 *tx = davinci_spi->tx;
>> + ? ? ? ? ? ? ? data = *tx++;
>> + ? ? ? ? ? ? ? davinci_spi->tx = tx;
>> + ? ? ? }
>> ? ? ? ?return data;
>> ?}
>>
>> @@ -237,26 +256,6 @@ static inline void clear_io_bits(void __iomem *addr, u32 bits)
>> ? ? ? ?iowrite32(v, addr);
>> ?}
>>
>> -static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
>> -{
>> - ? ? ? set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
>> -}
>> -
>> -static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
>> -{
>> - ? ? ? clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
>> -}
>> -
>> -static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable)
>> -{
>> - ? ? ? struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master);
>> -
>> - ? ? ? if (enable)
>> - ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN);
>> -}
>> -
>> ?/*
>> ?* Interface to control the chip select signal
>> ?*/
>> @@ -264,25 +263,54 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value)
>> ?{
>> ? ? ? ?struct davinci_spi *davinci_spi;
>> ? ? ? ?struct davinci_spi_platform_data *pdata;
>> - ? ? ? u32 data1_reg_val = 0;
>> + ? ? ? u8 i, chip_sel = spi->chip_select;
>> + ? ? ? u32 spidat1;
>> + ? ? ? u16 spidat1_cfg;
>>
>> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
>> ? ? ? ?pdata = davinci_spi->pdata;
>>
>> - ? ? ? /*
>> - ? ? ? ?* Board specific chip select logic decides the polarity and cs
>> - ? ? ? ?* line for the controller
>> - ? ? ? ?*/
>> - ? ? ? if (value == BITBANG_CS_INACTIVE) {
>> - ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIDEF, CS_DEFAULT);
>> -
>> - ? ? ? ? ? ? ? data1_reg_val |= CS_DEFAULT << SPIDAT1_CSNR_SHIFT;
>> - ? ? ? ? ? ? ? iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1);
>> + ? ? ? spidat1 = SPIDAT1_CSNR_MASK;
>> + ? ? ? if (value == BITBANG_CS_ACTIVE)
>> + ? ? ? ? ? ? ? spidat1 |= SPIDAT1_CSHOLD_MASK;
>> + ? ? ? else
>> + ? ? ? ? ? ? ? spidat1 |= SPIDAT1_WDEL_MASK;
>>
>> - ? ? ? ? ? ? ? while ((ioread32(davinci_spi->base + SPIBUF)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_RXEMPTY_MASK) == 0)
>> - ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
>> + ? ? ? if (pdata->chip_sel == NULL) {
>> + ? ? ? ? ? ? ? if (value == BITBANG_CS_ACTIVE)
>> + ? ? ? ? ? ? ? ? ? ? ? spidat1 &= ~((0x1 << chip_sel) << SPIDAT1_CSNR_SHIFT);
>> + ? ? ? } else {
>> + ? ? ? ? ? ? ? for (i = 0; i < pdata->num_chipselect; i++) {
>> + ? ? ? ? ? ? ? ? ? ? ? if (pdata->chip_sel[i] == SPI_INTERN_CS) {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if ((i == chip_sel) &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (value == BITBANG_CS_ACTIVE)) {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spidat1 &= ~((0x1 << chip_sel)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDAT1_CSNR_SHIFT);
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? ? ? ? ? } else {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (value == BITBANG_CS_INACTIVE)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? gpio_set_value(pdata->chip_sel[i], 1);
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? else if (i == chip_sel)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? gpio_set_value(pdata->chip_sel[i], 0);
>> + ? ? ? ? ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? }
>> ? ? ? ?}
>> +
>> + ? ? ? spidat1_cfg = spidat1 >> SPIDAT1_CSNR_SHIFT;
>> + ? ? ? iowrite16(spidat1_cfg, davinci_spi->base + SPIDAT1 + 2);
>> +}
>> +
>> +/**
>> + * davinci_spi_get_prescale - Calculates the correct prescale value
>> + * @max_speed_hz: the maximum rate the SPI clock can run at
>> + *
>> + * This function calculates the prescale value that generates a clock rate
>> + * less than or equal to the specified maximum
>> + */
>> +static inline u32 davinci_spi_get_prescale(struct davinci_spi *davinci_spi,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u32 max_speed_hz)
>> +{
>> + ? ? ? return ((clk_get_rate(davinci_spi->clk) - 1) / max_speed_hz) & 0xff;
>> ?}
>>
>> ?/**
>> @@ -297,14 +325,15 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value)
>> ?static int davinci_spi_setup_transfer(struct spi_device *spi,
>> ? ? ? ? ? ? ? ?struct spi_transfer *t)
>> ?{
>> -
>> ? ? ? ?struct davinci_spi *davinci_spi;
>> ? ? ? ?struct davinci_spi_platform_data *pdata;
>> + ? ? ? struct davinci_spi_config *spi_cfg;
>> ? ? ? ?u8 bits_per_word = 0;
>> - ? ? ? u32 hz = 0, prescale = 0, clkspeed;
>> + ? ? ? u32 hz = 0, spifmt = 0, prescale, delay = 0;
>>
>> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
>> ? ? ? ?pdata = davinci_spi->pdata;
>> + ? ? ? spi_cfg = spi->controller_data;
>>
>> ? ? ? ?if (t) {
>> ? ? ? ? ? ? ? ?bits_per_word = t->bits_per_word;
>> @@ -322,76 +351,112 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
>> ? ? ? ?if (bits_per_word <= 8 && bits_per_word >= 2) {
>> ? ? ? ? ? ? ? ?davinci_spi->get_rx = davinci_spi_rx_buf_u8;
>> ? ? ? ? ? ? ? ?davinci_spi->get_tx = davinci_spi_tx_buf_u8;
>> - ? ? ? ? ? ? ? davinci_spi->slave[spi->chip_select].bytes_per_word = 1;
>> + ? ? ? ? ? ? ? spi_cfg->bytes_per_word = 1;
>> ? ? ? ?} else if (bits_per_word <= 16 && bits_per_word >= 2) {
>> ? ? ? ? ? ? ? ?davinci_spi->get_rx = davinci_spi_rx_buf_u16;
>> ? ? ? ? ? ? ? ?davinci_spi->get_tx = davinci_spi_tx_buf_u16;
>> - ? ? ? ? ? ? ? davinci_spi->slave[spi->chip_select].bytes_per_word = 2;
>> + ? ? ? ? ? ? ? spi_cfg->bytes_per_word = 2;
>> ? ? ? ?} else
>> ? ? ? ? ? ? ? ?return -EINVAL;
>>
>> ? ? ? ?if (!hz)
>> ? ? ? ? ? ? ? ?hz = spi->max_speed_hz;
>>
>> - ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_CHARLEN_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? set_fmt_bits(davinci_spi->base, bits_per_word & 0x1f,
>> - ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> + ? ? ? prescale = davinci_spi_get_prescale(davinci_spi, hz);
>> + ? ? ? spifmt |= (prescale << SPIFMT_PRESCALE_SHIFT);
>> +
>> + ? ? ? spifmt |= (bits_per_word & 0x1f);
>> +
>> + ? ? ? if (spi->mode & SPI_LSB_FIRST)
>> + ? ? ? ? ? ? ? spifmt |= SPIFMT_SHIFTDIR_MASK;
>> +
>> + ? ? ? if (spi->mode & SPI_CPOL)
>> + ? ? ? ? ? ? ? spifmt |= SPIFMT_POLARITY_MASK;
>> +
>> + ? ? ? if (!(spi->mode & SPI_CPHA))
>> + ? ? ? ? ? ? ? spifmt |= SPIFMT_PHASE_MASK;
>> +
>> + ? ? ? if (davinci_spi->version == SPI_VERSION_2) {
>> + ? ? ? ? ? ? ? spifmt |= ((spi_cfg->wdelay << SPIFMT_WDELAY_SHIFT)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIFMT_WDELAY_MASK);
>> +
>> + ? ? ? ? ? ? ? if (spi_cfg->odd_parity)
>> + ? ? ? ? ? ? ? ? ? ? ? spifmt |= SPIFMT_ODD_PARITY_MASK;
>> +
>> + ? ? ? ? ? ? ? if (spi_cfg->parity_enable)
>> + ? ? ? ? ? ? ? ? ? ? ? spifmt |= SPIFMT_PARITYENA_MASK;
>> +
>> + ? ? ? ? ? ? ? if (spi->mode & SPI_READY) {
>> + ? ? ? ? ? ? ? ? ? ? ? spifmt |= SPIFMT_WAITENA_MASK;
>> + ? ? ? ? ? ? ? ? ? ? ? delay |= (spi_cfg->t2e_delay
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDELAY_T2EDELAY_SHIFT)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIDELAY_T2EDELAY_MASK;
>> + ? ? ? ? ? ? ? ? ? ? ? delay |= (spi_cfg->c2e_delay
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDELAY_C2EDELAY_SHIFT)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIDELAY_C2EDELAY_MASK;
>> + ? ? ? ? ? ? ? }
>> +
>> + ? ? ? ? ? ? ? if (spi_cfg->timer_disable) {
>> + ? ? ? ? ? ? ? ? ? ? ? spifmt |= SPIFMT_DISTIMER_MASK;
>> + ? ? ? ? ? ? ? } else {
>> + ? ? ? ? ? ? ? ? ? ? ? delay |= (spi_cfg->c2t_delay
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDELAY_C2TDELAY_SHIFT)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIDELAY_C2TDELAY_MASK;
>> + ? ? ? ? ? ? ? ? ? ? ? delay |= (spi_cfg->t2c_delay
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIDELAY_T2CDELAY_SHIFT)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIDELAY_T2CDELAY_MASK;
>> + ? ? ? ? ? ? ? }
>>
>> - ? ? ? clkspeed = clk_get_rate(davinci_spi->clk);
>> - ? ? ? if (hz > clkspeed / 2)
>> - ? ? ? ? ? ? ? prescale = 1 << 8;
>> - ? ? ? if (hz < clkspeed / 256)
>> - ? ? ? ? ? ? ? prescale = 255 << 8;
>> - ? ? ? if (!prescale)
>> - ? ? ? ? ? ? ? prescale = ((clkspeed / hz - 1) << 8) & 0x0000ff00;
>> + ? ? ? ? ? ? ? iowrite32(delay, davinci_spi->base + SPIDELAY);
>> + ? ? ? }
>> +
>> + ? ? ? iowrite32(spifmt, davinci_spi->base + SPIFMT0);
>>
>> - ? ? ? clear_fmt_bits(davinci_spi->base, 0x0000ff00, spi->chip_select);
>> - ? ? ? set_fmt_bits(davinci_spi->base, prescale, spi->chip_select);
>> + ? ? ? if (spi_cfg->intr_level)
>> + ? ? ? ? ? ? ? iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL);
>> + ? ? ? else
>> + ? ? ? ? ? ? ? iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL);
>> +
>> + ? ? ? if (spi->mode & SPI_LOOP)
>> + ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIGCR1,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_LOOPBACK_MASK);
>> + ? ? ? else
>> + ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_LOOPBACK_MASK);
>>
>> ? ? ? ?return 0;
>> ?}
>>
>> ?static void davinci_spi_dma_rx_callback(unsigned lch, u16 ch_status, void *data)
>> ?{
>> - ? ? ? struct spi_device *spi = (struct spi_device *)data;
>> - ? ? ? struct davinci_spi *davinci_spi;
>> + ? ? ? struct davinci_spi *davinci_spi = data;
>> ? ? ? ?struct davinci_spi_dma *davinci_spi_dma;
>> ? ? ? ?struct davinci_spi_platform_data *pdata;
>>
>> - ? ? ? davinci_spi = spi_master_get_devdata(spi->master);
>> - ? ? ? davinci_spi_dma = &(davinci_spi->dma_channels[spi->chip_select]);
>> + ? ? ? davinci_spi_dma = &(davinci_spi->dma_channels);
>> ? ? ? ?pdata = davinci_spi->pdata;
>>
>> + ? ? ? edma_stop(davinci_spi_dma->dma_rx_channel);
>> +
>> ? ? ? ?if (ch_status == DMA_COMPLETE)
>> - ? ? ? ? ? ? ? edma_stop(davinci_spi_dma->dma_rx_channel);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? edma_clean_channel(davinci_spi_dma->dma_rx_channel);
>> + ? ? ? ? ? ? ? davinci_spi->rcount = 0;
>>
>> - ? ? ? complete(&davinci_spi_dma->dma_rx_completion);
>> - ? ? ? /* We must disable the DMA RX request */
>> - ? ? ? davinci_spi_set_dma_req(spi, 0);
>> + ? ? ? complete(&davinci_spi->done);
>> ?}
>>
>> ?static void davinci_spi_dma_tx_callback(unsigned lch, u16 ch_status, void *data)
>> ?{
>> - ? ? ? struct spi_device *spi = (struct spi_device *)data;
>> - ? ? ? struct davinci_spi *davinci_spi;
>> + ? ? ? struct davinci_spi *davinci_spi = data;
>> ? ? ? ?struct davinci_spi_dma *davinci_spi_dma;
>> ? ? ? ?struct davinci_spi_platform_data *pdata;
>>
>> - ? ? ? davinci_spi = spi_master_get_devdata(spi->master);
>> - ? ? ? davinci_spi_dma = &(davinci_spi->dma_channels[spi->chip_select]);
>> + ? ? ? davinci_spi_dma = &(davinci_spi->dma_channels);
>> ? ? ? ?pdata = davinci_spi->pdata;
>>
>> - ? ? ? if (ch_status == DMA_COMPLETE)
>> - ? ? ? ? ? ? ? edma_stop(davinci_spi_dma->dma_tx_channel);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? edma_clean_channel(davinci_spi_dma->dma_tx_channel);
>> + ? ? ? edma_stop(davinci_spi_dma->dma_tx_channel);
>>
>> - ? ? ? complete(&davinci_spi_dma->dma_tx_completion);
>> - ? ? ? /* We must disable the DMA TX request */
>> - ? ? ? davinci_spi_set_dma_req(spi, 0);
>> + ? ? ? if (ch_status == DMA_COMPLETE)
>> + ? ? ? ? ? ? ? davinci_spi->wcount = 0;
>> ?}
>>
>> ?static int davinci_spi_request_dma(struct spi_device *spi)
>> @@ -403,30 +468,51 @@ static int davinci_spi_request_dma(struct spi_device *spi)
>> ? ? ? ?int r;
>>
>> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
>> - ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
>> + ? ? ? davinci_spi_dma = &davinci_spi->dma_channels;
>> ? ? ? ?pdata = davinci_spi->pdata;
>> ? ? ? ?sdev = davinci_spi->bitbang.master->dev.parent;
>>
>> ? ? ? ?r = edma_alloc_channel(davinci_spi_dma->dma_rx_sync_dev,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi_dma_rx_callback, spi,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi_dma_rx_callback, davinci_spi,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?davinci_spi_dma->eventq);
>> ? ? ? ?if (r < 0) {
>> - ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request DMA channel for SPI RX\n");
>> - ? ? ? ? ? ? ? return -EAGAIN;
>> + ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request DMA channel for MibSPI RX\n");
>> + ? ? ? ? ? ? ? r = ?-EAGAIN;
>> + ? ? ? ? ? ? ? goto rx_dma_failed;
>> ? ? ? ?}
>> ? ? ? ?davinci_spi_dma->dma_rx_channel = r;
>> +
>> ? ? ? ?r = edma_alloc_channel(davinci_spi_dma->dma_tx_sync_dev,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi_dma_tx_callback, spi,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi_dma_tx_callback, davinci_spi,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?davinci_spi_dma->eventq);
>> ? ? ? ?if (r < 0) {
>> - ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_rx_channel);
>> - ? ? ? ? ? ? ? davinci_spi_dma->dma_rx_channel = -1;
>> - ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request DMA channel for SPI TX\n");
>> - ? ? ? ? ? ? ? return -EAGAIN;
>> + ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request DMA channel for MibSPI TX\n");
>> + ? ? ? ? ? ? ? r = -EAGAIN;
>> + ? ? ? ? ? ? ? goto tx_dma_failed;
>> ? ? ? ?}
>> ? ? ? ?davinci_spi_dma->dma_tx_channel = r;
>>
>> + ? ? ? r = edma_alloc_slot(EDMA_CTLR(davinci_spi_dma->dma_tx_sync_dev),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? EDMA_SLOT_ANY);
>> + ? ? ? if (r < 0) {
>> + ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to request SPI DMA param slot\n");
>> + ? ? ? ? ? ? ? r = -EAGAIN;
>> + ? ? ? ? ? ? ? goto param_failed;
>> + ? ? ? }
>> + ? ? ? davinci_spi_dma->dummy_param_slot = r;
>> + ? ? ? edma_link(davinci_spi_dma->dummy_param_slot,
>> + ? ? ? ? ? ? ? ? davinci_spi_dma->dummy_param_slot);
>> +
>> ? ? ? ?return 0;
>> +
>> +param_failed:
>> + ? ? ? edma_free_channel(davinci_spi_dma->dma_tx_channel);
>> + ? ? ? davinci_spi_dma->dma_tx_channel = -1;
>> +tx_dma_failed:
>> + ? ? ? edma_free_channel(davinci_spi_dma->dma_rx_channel);
>> + ? ? ? davinci_spi_dma->dma_rx_channel = -1;
>> +rx_dma_failed:
>> + ? ? ? return r;
>> ?}
>>
>> ?/**
>> @@ -438,129 +524,54 @@ static int davinci_spi_request_dma(struct spi_device *spi)
>>
>> ?static int davinci_spi_setup(struct spi_device *spi)
>> ?{
>> - ? ? ? int retval;
>> + ? ? ? int retval = 0;
>> ? ? ? ?struct davinci_spi *davinci_spi;
>> - ? ? ? struct davinci_spi_dma *davinci_spi_dma;
>> - ? ? ? struct device *sdev;
>> + ? ? ? struct davinci_spi_dma *davinci_dma;
>> + ? ? ? struct davinci_spi_platform_data *pdata;
>> + ? ? ? struct davinci_spi_config *spi_cfg;
>> + ? ? ? u32 prescale;
>>
>> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
>> - ? ? ? sdev = davinci_spi->bitbang.master->dev.parent;
>> + ? ? ? pdata = davinci_spi->pdata;
>> + ? ? ? spi_cfg = (struct davinci_spi_config *)spi->controller_data;
>> + ? ? ? davinci_dma = &(davinci_spi->dma_channels);
>>
>> ? ? ? ?/* if bits per word length is zero then set it default 8 */
>> ? ? ? ?if (!spi->bits_per_word)
>> ? ? ? ? ? ? ? ?spi->bits_per_word = 8;
>>
>> - ? ? ? davinci_spi->slave[spi->chip_select].cmd_to_write = 0;
>> + ? ? ? if (!(spi->mode & SPI_NO_CS)) {
>> + ? ? ? ? ? ? ? if ((pdata->chip_sel == NULL) ||
>> + ? ? ? ? ? ? ? ? ? (pdata->chip_sel[spi->chip_select] == SPI_INTERN_CS))
>> + ? ? ? ? ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIPC0,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 << spi->chip_select);
>>
>> - ? ? ? if (use_dma && davinci_spi->dma_channels) {
>> - ? ? ? ? ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
>> -
>> - ? ? ? ? ? ? ? if ((davinci_spi_dma->dma_rx_channel == -1)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || (davinci_spi_dma->dma_tx_channel == -1)) {
>> - ? ? ? ? ? ? ? ? ? ? ? retval = davinci_spi_request_dma(spi);
>> - ? ? ? ? ? ? ? ? ? ? ? if (retval < 0)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? return retval;
>> - ? ? ? ? ? ? ? }
>> - ? ? ? }
>> -
>> - ? ? ? /*
>> - ? ? ? ?* SPI in DaVinci and DA8xx operate between
>> - ? ? ? ?* 600 KHz and 50 MHz
>> - ? ? ? ?*/
>> - ? ? ? if (spi->max_speed_hz < 600000 || spi->max_speed_hz > 50000000) {
>> - ? ? ? ? ? ? ? dev_dbg(sdev, "Operating frequency is not in acceptable "
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "range\n");
>> - ? ? ? ? ? ? ? return -EINVAL;
>> ? ? ? ?}
>>
>> - ? ? ? /*
>> - ? ? ? ?* Set up SPIFMTn register, unique to this chipselect.
>> - ? ? ? ?*
>> - ? ? ? ?* NOTE: we could do all of these with one write. ?Also, some
>> - ? ? ? ?* of the "version 2" features are found in chips that don't
>> - ? ? ? ?* support all of them...
>> - ? ? ? ?*/
>> - ? ? ? if (spi->mode & SPI_LSB_FIRST)
>> - ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base, SPIFMT_SHIFTDIR_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_SHIFTDIR_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> + ? ? ? if (spi->mode & SPI_READY)
>> + ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIPC0, SPIPC0_SPIENA_MASK);
>>
>> - ? ? ? if (spi->mode & SPI_CPOL)
>> - ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base, SPIFMT_POLARITY_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_POLARITY_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> + ? ? ? if (spi_cfg->io_type == SPI_IO_TYPE_DMA) {
>> + ? ? ? ? ? ? ? davinci_dma = &(davinci_spi->dma_channels);
>>
>> - ? ? ? if (!(spi->mode & SPI_CPHA))
>> - ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base, SPIFMT_PHASE_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_PHASE_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> + ? ? ? ? ? ? ? if ((davinci_dma->dma_tx_sync_dev == SPI_NO_RESOURCE) ||
>> + ? ? ? ? ? ? ? ? ? (davinci_dma->dma_rx_sync_dev == SPI_NO_RESOURCE) ||
>> + ? ? ? ? ? ? ? ? ? (davinci_dma->eventq == SPI_NO_RESOURCE))
>> + ? ? ? ? ? ? ? ? ? ? ? spi_cfg->io_type = SPI_IO_TYPE_INTR;
>> + ? ? ? ? ? ? ? else if ((davinci_dma->dma_rx_channel == -1) ||
>> + ? ? ? ? ? ? ? ? ? ? ? ?(davinci_dma->dma_tx_channel == -1))
>> + ? ? ? ? ? ? ? ? ? ? ? retval = davinci_spi_request_dma(spi);
>> + ? ? ? }
>>
>> ? ? ? ?/*
>> - ? ? ? ?* Version 1 hardware supports two basic SPI modes:
>> - ? ? ? ?* ?- Standard SPI mode uses 4 pins, with chipselect
>> - ? ? ? ?* ?- 3 pin SPI is a 4 pin variant without CS (SPI_NO_CS)
>> - ? ? ? ?* ? ? ?(distinct from SPI_3WIRE, with just one data wire;
>> - ? ? ? ?* ? ? ?or similar variants without MOSI or without MISO)
>> - ? ? ? ?*
>> - ? ? ? ?* Version 2 hardware supports an optional handshaking signal,
>> - ? ? ? ?* so it can support two more modes:
>> - ? ? ? ?* ?- 5 pin SPI variant is standard SPI plus SPI_READY
>> - ? ? ? ?* ?- 4 pin with enable is (SPI_READY | SPI_NO_CS)
>> + ? ? ? ?* Validate desired clock rate
>> ? ? ? ? */
>> + ? ? ? prescale = davinci_spi_get_prescale(davinci_spi, spi->max_speed_hz);
>> + ? ? ? if ((prescale < 2) || (prescale > 255))
>> + ? ? ? ? ? ? ? return -EINVAL;
>>
>> - ? ? ? if (davinci_spi->version == SPI_VERSION_2) {
>> - ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base, SPIFMT_WDELAY_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (davinci_spi->pdata->wdelay
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << SPIFMT_WDELAY_SHIFT)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIFMT_WDELAY_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> -
>> - ? ? ? ? ? ? ? if (davinci_spi->pdata->odd_parity)
>> - ? ? ? ? ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_ODD_PARITY_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? ? ? ? ? else
>> - ? ? ? ? ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_ODD_PARITY_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> -
>> - ? ? ? ? ? ? ? if (davinci_spi->pdata->parity_enable)
>> - ? ? ? ? ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_PARITYENA_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? ? ? ? ? else
>> - ? ? ? ? ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_PARITYENA_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> -
>> - ? ? ? ? ? ? ? if (davinci_spi->pdata->wait_enable)
>> - ? ? ? ? ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_WAITENA_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? ? ? ? ? else
>> - ? ? ? ? ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_WAITENA_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> -
>> - ? ? ? ? ? ? ? if (davinci_spi->pdata->timer_disable)
>> - ? ? ? ? ? ? ? ? ? ? ? set_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_DISTIMER_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? ? ? ? ? else
>> - ? ? ? ? ? ? ? ? ? ? ? clear_fmt_bits(davinci_spi->base,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIFMT_DISTIMER_MASK,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? spi->chip_select);
>> - ? ? ? }
>> -
>> - ? ? ? retval = davinci_spi_setup_transfer(spi, NULL);
>> + ? ? ? dev_info(&spi->dev, "DaVinci SPI driver in %s mode\n",
>> + ? ? ? ? ? ? ? ? ? ? ? io_type_names[spi_cfg->io_type]);
>>
>> ? ? ? ?return retval;
>> ?}
>> @@ -569,50 +580,19 @@ static void davinci_spi_cleanup(struct spi_device *spi)
>> ?{
>> ? ? ? ?struct davinci_spi *davinci_spi = spi_master_get_devdata(spi->master);
>> ? ? ? ?struct davinci_spi_dma *davinci_spi_dma;
>> + ? ? ? struct davinci_spi_platform_data *pdata;
>>
>> - ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
>> -
>> - ? ? ? if (use_dma && davinci_spi->dma_channels) {
>> - ? ? ? ? ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
>> -
>> - ? ? ? ? ? ? ? if ((davinci_spi_dma->dma_rx_channel != -1)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? && (davinci_spi_dma->dma_tx_channel != -1)) {
>> - ? ? ? ? ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_tx_channel);
>> - ? ? ? ? ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_rx_channel);
>> - ? ? ? ? ? ? ? }
>> - ? ? ? }
>> -}
>> -
>> -static int davinci_spi_bufs_prep(struct spi_device *spi,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct davinci_spi *davinci_spi)
>> -{
>> - ? ? ? int op_mode = 0;
>> -
>> - ? ? ? /*
>> - ? ? ? ?* REVISIT ?unless devices disagree about SPI_LOOP or
>> - ? ? ? ?* SPI_READY (SPI_NO_CS only allows one device!), this
>> - ? ? ? ?* should not need to be done before each message...
>> - ? ? ? ?* optimize for both flags staying cleared.
>> - ? ? ? ?*/
>> -
>> - ? ? ? op_mode = SPIPC0_DIFUN_MASK
>> - ? ? ? ? ? ? ? | SPIPC0_DOFUN_MASK
>> - ? ? ? ? ? ? ? | SPIPC0_CLKFUN_MASK;
>> - ? ? ? if (!(spi->mode & SPI_NO_CS))
>> - ? ? ? ? ? ? ? op_mode |= 1 << spi->chip_select;
>> - ? ? ? if (spi->mode & SPI_READY)
>> - ? ? ? ? ? ? ? op_mode |= SPIPC0_SPIENA_MASK;
>> + ? ? ? davinci_spi_dma = &davinci_spi->dma_channels;
>> + ? ? ? pdata = davinci_spi->pdata;
>>
>> - ? ? ? iowrite32(op_mode, davinci_spi->base + SPIPC0);
>> + ? ? ? if (davinci_spi_dma->dma_rx_channel != -1)
>> + ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_rx_channel);
>>
>> - ? ? ? if (spi->mode & SPI_LOOP)
>> - ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIGCR1,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_LOOPBACK_MASK);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_LOOPBACK_MASK);
>> + ? ? ? if (davinci_spi_dma->dma_tx_channel != -1)
>> + ? ? ? ? ? ? ? edma_free_channel(davinci_spi_dma->dma_tx_channel);
>>
>> - ? ? ? return 0;
>> + ? ? ? if (davinci_spi_dma->dummy_param_slot != -1)
>> + ? ? ? ? ? ? ? edma_free_slot(davinci_spi_dma->dummy_param_slot);
>> ?}
>>
>> ?static int davinci_spi_check_error(struct davinci_spi *davinci_spi,
>> @@ -660,355 +640,242 @@ static int davinci_spi_check_error(struct davinci_spi *davinci_spi,
>> ?}
>>
>> ?/**
>> - * davinci_spi_bufs - functions which will handle transfer data
>> - * @spi: spi device on which data transfer to be done
>> - * @t: spi transfer in which transfer info is filled
>> + * davinci_spi_process_events - check for and handle any SPI controller events
>> + * @davinci_spi: the controller data
>> ?*
>> - * This function will put data to be transferred into data register
>> - * of SPI controller and then wait until the completion will be marked
>> - * by the IRQ Handler.
>> + * This function will check the SPIFLG register and handle any events that are
>> + * detected there
>> ?*/
>> -static int davinci_spi_bufs_pio(struct spi_device *spi, struct spi_transfer *t)
>> +static int davinci_spi_process_events(struct davinci_spi *davinci_spi)
>> ?{
>> - ? ? ? struct davinci_spi *davinci_spi;
>> - ? ? ? int int_status, count, ret;
>> - ? ? ? u8 conv, tmp;
>> - ? ? ? u32 tx_data, data1_reg_val;
>> - ? ? ? u32 buf_val, flg_val;
>> - ? ? ? struct davinci_spi_platform_data *pdata;
>> -
>> - ? ? ? davinci_spi = spi_master_get_devdata(spi->master);
>> - ? ? ? pdata = davinci_spi->pdata;
>> -
>> - ? ? ? davinci_spi->tx = t->tx_buf;
>> - ? ? ? davinci_spi->rx = t->rx_buf;
>> -
>> - ? ? ? /* convert len to words based on bits_per_word */
>> - ? ? ? conv = davinci_spi->slave[spi->chip_select].bytes_per_word;
>> - ? ? ? davinci_spi->count = t->len / conv;
>> -
>> - ? ? ? INIT_COMPLETION(davinci_spi->done);
>> -
>> - ? ? ? ret = davinci_spi_bufs_prep(spi, davinci_spi);
>> - ? ? ? if (ret)
>> - ? ? ? ? ? ? ? return ret;
>> -
>> - ? ? ? /* Enable SPI */
>> - ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK);
>> -
>> - ? ? ? iowrite32(0 | (pdata->c2tdelay << SPI_C2TDELAY_SHIFT) |
>> - ? ? ? ? ? ? ? ? ? ? ? (pdata->t2cdelay << SPI_T2CDELAY_SHIFT),
>> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDELAY);
>> -
>> - ? ? ? count = davinci_spi->count;
>> - ? ? ? data1_reg_val = pdata->cs_hold << SPIDAT1_CSHOLD_SHIFT;
>> - ? ? ? tmp = ~(0x1 << spi->chip_select);
>> -
>> - ? ? ? clear_io_bits(davinci_spi->base + SPIDEF, ~tmp);
>> -
>> - ? ? ? data1_reg_val |= tmp << SPIDAT1_CSNR_SHIFT;
>> -
>> - ? ? ? while ((ioread32(davinci_spi->base + SPIBUF)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_RXEMPTY_MASK) == 0)
>> - ? ? ? ? ? ? ? cpu_relax();
>> -
>> - ? ? ? /* Determine the command to execute READ or WRITE */
>> - ? ? ? if (t->tx_buf) {
>> - ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL);
>> -
>> - ? ? ? ? ? ? ? while (1) {
>> - ? ? ? ? ? ? ? ? ? ? ? tx_data = davinci_spi->get_tx(davinci_spi);
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? data1_reg_val &= ~(0xFFFF);
>> - ? ? ? ? ? ? ? ? ? ? ? data1_reg_val |= (0xFFFF & tx_data);
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? buf_val = ioread32(davinci_spi->base + SPIBUF);
>> - ? ? ? ? ? ? ? ? ? ? ? if ((buf_val & SPIBUF_TXFULL_MASK) == 0) {
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iowrite32(data1_reg_val,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1);
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? count--;
>> - ? ? ? ? ? ? ? ? ? ? ? }
>> - ? ? ? ? ? ? ? ? ? ? ? while (ioread32(davinci_spi->base + SPIBUF)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_RXEMPTY_MASK)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? /* getting the returned byte */
>> - ? ? ? ? ? ? ? ? ? ? ? if (t->rx_buf) {
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? buf_val = ioread32(davinci_spi->base + SPIBUF);
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->get_rx(buf_val, davinci_spi);
>> - ? ? ? ? ? ? ? ? ? ? ? }
>> - ? ? ? ? ? ? ? ? ? ? ? if (count <= 0)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
>> - ? ? ? ? ? ? ? }
>> - ? ? ? } else {
>> - ? ? ? ? ? ? ? if (pdata->poll_mode) {
>> - ? ? ? ? ? ? ? ? ? ? ? while (1) {
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* keeps the serial clock going */
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if ((ioread32(davinci_spi->base + SPIBUF)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_TXFULL_MASK) == 0)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iowrite32(data1_reg_val,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1);
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? while (ioread32(davinci_spi->base + SPIBUF) &
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIBUF_RXEMPTY_MASK)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? flg_val = ioread32(davinci_spi->base + SPIFLG);
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? buf_val = ioread32(davinci_spi->base + SPIBUF);
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->get_rx(buf_val, davinci_spi);
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? count--;
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (count <= 0)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
>> - ? ? ? ? ? ? ? ? ? ? ? }
>> - ? ? ? ? ? ? ? } else { ? ? ? ?/* Receive in Interrupt mode */
>> - ? ? ? ? ? ? ? ? ? ? ? int i;
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? for (i = 0; i < davinci_spi->count; i++) {
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIINT,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIINT_BITERR_INTR
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIINT_OVRRUN_INTR
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | SPIINT_RX_INTR);
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iowrite32(data1_reg_val,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1);
>> -
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? while (ioread32(davinci_spi->base + SPIINT) &
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIINT_RX_INTR)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
>> - ? ? ? ? ? ? ? ? ? ? ? }
>> - ? ? ? ? ? ? ? ? ? ? ? iowrite32((data1_reg_val & 0x0ffcffff),
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1);
>> - ? ? ? ? ? ? ? }
>> + ? ? ? u32 status, tx_data, rx_data, spidat1;
>> + ? ? ? u8 tx_word = 0;
>> +
>> + ? ? ? status = ioread32(davinci_spi->base + SPIFLG);
>> +
>> + ? ? ? if ((davinci_spi->version != SPI_VERSION_0) &&
>> + ? ? ? ? ? (likely(status & SPIFLG_TX_INTR_MASK)) &&
>> + ? ? ? ? ? (likely(davinci_spi->wcount > 0)))
>> + ? ? ? ? ? ? ? tx_word = 1;
>> +
>> + ? ? ? if (likely(status & SPIFLG_RX_INTR_MASK)) {
>> + ? ? ? ? ? ? ? rx_data = ioread32(davinci_spi->base + SPIBUF) & 0xFFFF;
>> + ? ? ? ? ? ? ? davinci_spi->get_rx(rx_data, davinci_spi);
>> + ? ? ? ? ? ? ? davinci_spi->rcount--;
>> + ? ? ? ? ? ? ? if ((davinci_spi->version == SPI_VERSION_0) &&
>> + ? ? ? ? ? ? ? ? ? (likely(davinci_spi->wcount > 0)))
>> + ? ? ? ? ? ? ? ? ? ? ? tx_word = 1;
>> ? ? ? ?}
>>
>> - ? ? ? /*
>> - ? ? ? ?* Check for bit error, desync error,parity error,timeout error and
>> - ? ? ? ?* receive overflow errors
>> - ? ? ? ?*/
>> - ? ? ? int_status = ioread32(davinci_spi->base + SPIFLG);
>> -
>> - ? ? ? ret = davinci_spi_check_error(davinci_spi, int_status);
>> - ? ? ? if (ret != 0)
>> - ? ? ? ? ? ? ? return ret;
>> + ? ? ? if (unlikely(status & SPIFLG_ERROR_MASK)) {
>> + ? ? ? ? ? ? ? davinci_spi->errors = (status & SPIFLG_ERROR_MASK);
>> + ? ? ? ? ? ? ? return -1;
>> + ? ? ? }
>>
>> - ? ? ? /* SPI Framework maintains the count only in bytes so convert back */
>> - ? ? ? davinci_spi->count *= conv;
>> + ? ? ? if (likely(tx_word)) {
>> + ? ? ? ? ? ? ? spidat1 = ioread32(davinci_spi->base + SPIDAT1);
>> + ? ? ? ? ? ? ? davinci_spi->wcount--;
>> + ? ? ? ? ? ? ? tx_data = davinci_spi->get_tx(davinci_spi);
>> + ? ? ? ? ? ? ? spidat1 &= 0xFFFF0000;
>> + ? ? ? ? ? ? ? spidat1 |= (tx_data & 0xFFFF);
>> + ? ? ? ? ? ? ? iowrite32(spidat1, davinci_spi->base + SPIDAT1);
>> + ? ? ? }
>>
>> - ? ? ? return t->len;
>> + ? ? ? return 0;
>> ?}
>>
>> -#define DAVINCI_DMA_DATA_TYPE_S8 ? ? ? 0x01
>> -#define DAVINCI_DMA_DATA_TYPE_S16 ? ? ?0x02
>> -#define DAVINCI_DMA_DATA_TYPE_S32 ? ? ?0x04
>> -
>> -static int davinci_spi_bufs_dma(struct spi_device *spi, struct spi_transfer *t)
>> +/**
>> + * davinci_spi_txrx_bufs - function which will handle transfer data
>> + * @spi: spi device on which data transfer to be done
>> + * @t: spi transfer in which transfer info is filled
>> + *
>> + * This function will put data to be transferred into data register
>> + * of SPI controller and then wait until the completion will be marked
>> + * by the IRQ Handler.
>> + */
>> +static int davinci_spi_txrx_bufs(struct spi_device *spi, struct spi_transfer *t)
>> ?{
>> ? ? ? ?struct davinci_spi *davinci_spi;
>> - ? ? ? int int_status = 0;
>> - ? ? ? int count, temp_count;
>> - ? ? ? u8 conv = 1;
>> - ? ? ? u8 tmp;
>> - ? ? ? u32 data1_reg_val;
>> - ? ? ? struct davinci_spi_dma *davinci_spi_dma;
>> - ? ? ? int word_len, data_type, ret;
>> - ? ? ? unsigned long tx_reg, rx_reg;
>> + ? ? ? int data_type, ret = 0;
>> + ? ? ? u32 tx_data, spidat1;
>> + ? ? ? u16 tx_buf_count = 0, rx_buf_count = 0;
>> + ? ? ? struct davinci_spi_config *spi_cfg;
>> ? ? ? ?struct davinci_spi_platform_data *pdata;
>> + ? ? ? struct davinci_spi_dma *davinci_dma;
>> ? ? ? ?struct device *sdev;
>> + ? ? ? dma_addr_t tx_reg, rx_reg;
>> + ? ? ? void *tx_buf, *rx_buf;
>> + ? ? ? struct edmacc_param rx_param, tx_param;
>>
>> ? ? ? ?davinci_spi = spi_master_get_devdata(spi->master);
>> ? ? ? ?pdata = davinci_spi->pdata;
>> - ? ? ? sdev = davinci_spi->bitbang.master->dev.parent;
>> -
>> - ? ? ? davinci_spi_dma = &davinci_spi->dma_channels[spi->chip_select];
>> -
>> - ? ? ? tx_reg = (unsigned long)davinci_spi->pbase + SPIDAT1;
>> - ? ? ? rx_reg = (unsigned long)davinci_spi->pbase + SPIBUF;
>> + ? ? ? spi_cfg = (struct davinci_spi_config *)spi->controller_data;
>> + ? ? ? davinci_dma = &(davinci_spi->dma_channels);
>>
>> ? ? ? ?davinci_spi->tx = t->tx_buf;
>> ? ? ? ?davinci_spi->rx = t->rx_buf;
>> + ? ? ? davinci_spi->wcount = t->len / spi_cfg->bytes_per_word;
>> + ? ? ? davinci_spi->rcount = davinci_spi->wcount;
>> + ? ? ? davinci_spi->errors = 0;
>>
>> - ? ? ? /* convert len to words based on bits_per_word */
>> - ? ? ? conv = davinci_spi->slave[spi->chip_select].bytes_per_word;
>> - ? ? ? davinci_spi->count = t->len / conv;
>> + ? ? ? spidat1 = ioread32(davinci_spi->base + SPIDAT1);
>>
>> - ? ? ? INIT_COMPLETION(davinci_spi->done);
>> -
>> - ? ? ? init_completion(&davinci_spi_dma->dma_rx_completion);
>> - ? ? ? init_completion(&davinci_spi_dma->dma_tx_completion);
>> -
>> - ? ? ? word_len = conv * 8;
>> -
>> - ? ? ? if (word_len <= 8)
>> - ? ? ? ? ? ? ? data_type = DAVINCI_DMA_DATA_TYPE_S8;
>> - ? ? ? else if (word_len <= 16)
>> - ? ? ? ? ? ? ? data_type = DAVINCI_DMA_DATA_TYPE_S16;
>> - ? ? ? else if (word_len <= 32)
>> - ? ? ? ? ? ? ? data_type = DAVINCI_DMA_DATA_TYPE_S32;
>> - ? ? ? else
>> - ? ? ? ? ? ? ? return -EINVAL;
>> -
>> - ? ? ? ret = davinci_spi_bufs_prep(spi, davinci_spi);
>> - ? ? ? if (ret)
>> - ? ? ? ? ? ? ? return ret;
>> -
>> - ? ? ? /* Put delay val if required */
>> - ? ? ? iowrite32(0 | (pdata->c2tdelay << SPI_C2TDELAY_SHIFT) |
>> - ? ? ? ? ? ? ? ? ? ? ? (pdata->t2cdelay << SPI_T2CDELAY_SHIFT),
>> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDELAY);
>> -
>> - ? ? ? count = davinci_spi->count; ? ? /* the number of elements */
>> - ? ? ? data1_reg_val = pdata->cs_hold << SPIDAT1_CSHOLD_SHIFT;
>> -
>> - ? ? ? /* CS default = 0xFF */
>> - ? ? ? tmp = ~(0x1 << spi->chip_select);
>> -
>> - ? ? ? clear_io_bits(davinci_spi->base + SPIDEF, ~tmp);
>> -
>> - ? ? ? data1_reg_val |= tmp << SPIDAT1_CSNR_SHIFT;
>> -
>> - ? ? ? /* disable all interrupts for dma transfers */
>> - ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL);
>> - ? ? ? /* Disable SPI to write configuration bits in SPIDAT */
>> - ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK);
>> - ? ? ? iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1);
>> - ? ? ? /* Enable SPI */
>> + ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK);
>> ? ? ? ?set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK);
>>
>> - ? ? ? while ((ioread32(davinci_spi->base + SPIBUF)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? & SPIBUF_RXEMPTY_MASK) == 0)
>> - ? ? ? ? ? ? ? cpu_relax();
>> -
>> + ? ? ? INIT_COMPLETION(davinci_spi->done);
>>
>> - ? ? ? if (t->tx_buf) {
>> - ? ? ? ? ? ? ? t->tx_dma = dma_map_single(&spi->dev, (void *)t->tx_buf, count,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_TO_DEVICE);
>> - ? ? ? ? ? ? ? if (dma_mapping_error(&spi->dev, t->tx_dma)) {
>> - ? ? ? ? ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to DMA map a %d bytes"
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? " TX buffer\n", count);
>> - ? ? ? ? ? ? ? ? ? ? ? return -ENOMEM;
>> + ? ? ? if ((spi_cfg->io_type == SPI_IO_TYPE_INTR) ||
>> + ? ? ? ? ? (spi_cfg->io_type == SPI_IO_TYPE_POLL)) {
>> +
>> + ? ? ? ? ? ? ? if (spi_cfg->io_type == SPI_IO_TYPE_INTR)
>> + ? ? ? ? ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKINT);
>> +
>> + ? ? ? ? ? ? ? /* start the transfer */
>> + ? ? ? ? ? ? ? davinci_spi->wcount--;
>> + ? ? ? ? ? ? ? tx_data = davinci_spi->get_tx(davinci_spi);
>> + ? ? ? ? ? ? ? spidat1 &= 0xFFFF0000;
>> + ? ? ? ? ? ? ? spidat1 |= (tx_data & 0xFFFF);
>> + ? ? ? ? ? ? ? iowrite32(spidat1, davinci_spi->base + SPIDAT1);
>> +
>> + ? ? ? } else if (spi_cfg->io_type == SPI_IO_TYPE_DMA) {
>> + ? ? ? ? ? ? ? data_type = spi_cfg->bytes_per_word;
>> + ? ? ? ? ? ? ? tx_reg = (dma_addr_t)davinci_spi->pbase + SPIDAT1;
>> + ? ? ? ? ? ? ? rx_reg = (dma_addr_t)davinci_spi->pbase + SPIBUF;
>> +
>> + ? ? ? ? ? ? ? if (t->tx_buf) {
>> + ? ? ? ? ? ? ? ? ? ? ? tx_buf = ((void *)t->tx_buf);
>> + ? ? ? ? ? ? ? ? ? ? ? tx_buf_count = davinci_spi->wcount;
>> + ? ? ? ? ? ? ? } else {
>> + ? ? ? ? ? ? ? ? ? ? ? tx_buf = (void *)davinci_spi->tmp_buf;
>> + ? ? ? ? ? ? ? ? ? ? ? tx_buf_count = SPI_BUFSIZ;
>> ? ? ? ? ? ? ? ?}
>> - ? ? ? ? ? ? ? temp_count = count;
>> - ? ? ? } else {
>> - ? ? ? ? ? ? ? /* We need TX clocking for RX transaction */
>> - ? ? ? ? ? ? ? t->tx_dma = dma_map_single(&spi->dev,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (void *)davinci_spi->tmp_buf, count + 1,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_TO_DEVICE);
>> - ? ? ? ? ? ? ? if (dma_mapping_error(&spi->dev, t->tx_dma)) {
>> - ? ? ? ? ? ? ? ? ? ? ? dev_dbg(sdev, "Unable to DMA map a %d bytes"
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? " TX tmp buffer\n", count);
>> - ? ? ? ? ? ? ? ? ? ? ? return -ENOMEM;
>> + ? ? ? ? ? ? ? if (t->rx_buf) {
>> + ? ? ? ? ? ? ? ? ? ? ? rx_buf = (void *)t->rx_buf;
>> + ? ? ? ? ? ? ? ? ? ? ? rx_buf_count = davinci_spi->rcount;
>> + ? ? ? ? ? ? ? } else {
>> + ? ? ? ? ? ? ? ? ? ? ? rx_buf = (void *)davinci_spi->tmp_buf;
>> + ? ? ? ? ? ? ? ? ? ? ? rx_buf_count = SPI_BUFSIZ;
>> ? ? ? ? ? ? ? ?}
>> - ? ? ? ? ? ? ? temp_count = count + 1;
>> +
>> + ? ? ? ? ? ? ? t->tx_dma = dma_map_single(&spi->dev, tx_buf,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? tx_buf_count, DMA_TO_DEVICE);
>> + ? ? ? ? ? ? ? t->rx_dma = dma_map_single(&spi->dev, rx_buf,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rx_buf_count, DMA_FROM_DEVICE);
>> +
>> + ? ? ? ? ? ? ? tx_param.opt = TCINTEN | EDMA_TCC(davinci_dma->dma_tx_channel);
>> + ? ? ? ? ? ? ? tx_param.src = t->tx_buf ? t->tx_dma : tx_reg;
>> + ? ? ? ? ? ? ? tx_param.a_b_cnt = davinci_spi->wcount << 16 | data_type;
>> + ? ? ? ? ? ? ? tx_param.dst = tx_reg;
>> + ? ? ? ? ? ? ? tx_param.src_dst_bidx = t->tx_buf ? data_type : 0;
>> + ? ? ? ? ? ? ? tx_param.link_bcntrld = 0xffff;
>> + ? ? ? ? ? ? ? tx_param.src_dst_cidx = 0;
>> + ? ? ? ? ? ? ? tx_param.ccnt = 1;
>> + ? ? ? ? ? ? ? edma_write_slot(davinci_dma->dma_tx_channel, &tx_param);
>> + ? ? ? ? ? ? ? edma_link(davinci_dma->dma_tx_channel,
>> + ? ? ? ? ? ? ? ? ? ? ? ? davinci_dma->dummy_param_slot);
>> +
>> + ? ? ? ? ? ? ? rx_param.opt = TCINTEN | EDMA_TCC(davinci_dma->dma_rx_channel);
>> + ? ? ? ? ? ? ? rx_param.src = rx_reg;
>> + ? ? ? ? ? ? ? rx_param.a_b_cnt = davinci_spi->rcount << 16 | data_type;
>> + ? ? ? ? ? ? ? rx_param.dst = t->rx_dma;
>> + ? ? ? ? ? ? ? rx_param.src_dst_bidx = (t->rx_buf ? data_type : 0) << 16;
>> + ? ? ? ? ? ? ? rx_param.link_bcntrld = 0xffff;
>> + ? ? ? ? ? ? ? rx_param.src_dst_cidx = 0;
>> + ? ? ? ? ? ? ? rx_param.ccnt = 1;
>> + ? ? ? ? ? ? ? edma_write_slot(davinci_dma->dma_rx_channel, &rx_param);
>> +
>> + ? ? ? ? ? ? ? iowrite16(spidat1 >> SPIDAT1_CSNR_SHIFT,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIDAT1 + 2);
>> +
>> + ? ? ? ? ? ? ? edma_start(davinci_dma->dma_rx_channel);
>> + ? ? ? ? ? ? ? edma_start(davinci_dma->dma_tx_channel);
>> + ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIINT, SPIINT_DMA_REQ_EN);
>> ? ? ? ?}
>>
>> - ? ? ? edma_set_transfer_params(davinci_spi_dma->dma_tx_channel,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? data_type, temp_count, 1, 0, ASYNC);
>> - ? ? ? edma_set_dest(davinci_spi_dma->dma_tx_channel, tx_reg, INCR, W8BIT);
>> - ? ? ? edma_set_src(davinci_spi_dma->dma_tx_channel, t->tx_dma, INCR, W8BIT);
>> - ? ? ? edma_set_src_index(davinci_spi_dma->dma_tx_channel, data_type, 0);
>> - ? ? ? edma_set_dest_index(davinci_spi_dma->dma_tx_channel, 0, 0);
>> -
>> - ? ? ? if (t->rx_buf) {
>> - ? ? ? ? ? ? ? /* initiate transaction */
>> - ? ? ? ? ? ? ? iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1);
>> -
>> - ? ? ? ? ? ? ? t->rx_dma = dma_map_single(&spi->dev, (void *)t->rx_buf, count,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_FROM_DEVICE);
>> - ? ? ? ? ? ? ? if (dma_mapping_error(&spi->dev, t->rx_dma)) {
>> - ? ? ? ? ? ? ? ? ? ? ? dev_dbg(sdev, "Couldn't DMA map a %d bytes RX buffer\n",
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? count);
>> - ? ? ? ? ? ? ? ? ? ? ? if (t->tx_buf != NULL)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_unmap_single(NULL, t->tx_dma,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?count, DMA_TO_DEVICE);
>> - ? ? ? ? ? ? ? ? ? ? ? return -ENOMEM;
>> + ? ? ? /* Wait for the transfer to complete */
>> + ? ? ? if (spi_cfg->io_type != SPI_IO_TYPE_POLL) {
>> + ? ? ? ? ? ? ? wait_for_completion_interruptible(&(davinci_spi->done));
>> + ? ? ? } else {
>> + ? ? ? ? ? ? ? while ((davinci_spi->rcount > 0) && (ret == 0)) {
>> + ? ? ? ? ? ? ? ? ? ? ? ret = davinci_spi_process_events(davinci_spi);
>> + ? ? ? ? ? ? ? ? ? ? ? cpu_relax();
>> ? ? ? ? ? ? ? ?}
>> - ? ? ? ? ? ? ? edma_set_transfer_params(davinci_spi_dma->dma_rx_channel,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? data_type, count, 1, 0, ASYNC);
>> - ? ? ? ? ? ? ? edma_set_src(davinci_spi_dma->dma_rx_channel,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rx_reg, INCR, W8BIT);
>> - ? ? ? ? ? ? ? edma_set_dest(davinci_spi_dma->dma_rx_channel,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? t->rx_dma, INCR, W8BIT);
>> - ? ? ? ? ? ? ? edma_set_src_index(davinci_spi_dma->dma_rx_channel, 0, 0);
>> - ? ? ? ? ? ? ? edma_set_dest_index(davinci_spi_dma->dma_rx_channel,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? data_type, 0);
>> ? ? ? ?}
>>
>> - ? ? ? if ((t->tx_buf) || (t->rx_buf))
>> - ? ? ? ? ? ? ? edma_start(davinci_spi_dma->dma_tx_channel);
>> -
>> - ? ? ? if (t->rx_buf)
>> - ? ? ? ? ? ? ? edma_start(davinci_spi_dma->dma_rx_channel);
>> -
>> - ? ? ? if ((t->rx_buf) || (t->tx_buf))
>> - ? ? ? ? ? ? ? davinci_spi_set_dma_req(spi, 1);
>> -
>> - ? ? ? if (t->tx_buf)
>> - ? ? ? ? ? ? ? wait_for_completion_interruptible(
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &davinci_spi_dma->dma_tx_completion);
>> -
>> - ? ? ? if (t->rx_buf)
>> - ? ? ? ? ? ? ? wait_for_completion_interruptible(
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &davinci_spi_dma->dma_rx_completion);
>> -
>> - ? ? ? dma_unmap_single(NULL, t->tx_dma, temp_count, DMA_TO_DEVICE);
>> -
>> - ? ? ? if (t->rx_buf)
>> - ? ? ? ? ? ? ? dma_unmap_single(NULL, t->rx_dma, count, DMA_FROM_DEVICE);
>> -
>> - ? ? ? /*
>> - ? ? ? ?* Check for bit error, desync error,parity error,timeout error and
>> - ? ? ? ?* receive overflow errors
>> - ? ? ? ?*/
>> - ? ? ? int_status = ioread32(davinci_spi->base + SPIFLG);
>> + ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKALL);
>> + ? ? ? if (spi_cfg->io_type == SPI_IO_TYPE_DMA) {
>> + ? ? ? ? ? ? ? dma_unmap_single(NULL, t->tx_dma, tx_buf_count,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_TO_DEVICE);
>> + ? ? ? ? ? ? ? dma_unmap_single(NULL, t->rx_dma, rx_buf_count,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DMA_FROM_DEVICE);
>> + ? ? ? }
>>
>> - ? ? ? ret = davinci_spi_check_error(davinci_spi, int_status);
>> - ? ? ? if (ret != 0)
>> - ? ? ? ? ? ? ? return ret;
>> + ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_SPIENA_MASK);
>> + ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK);
>>
>> - ? ? ? /* SPI Framework maintains the count only in bytes so convert back */
>> - ? ? ? davinci_spi->count *= conv;
>> + ? ? ? if (davinci_spi->errors) {
>> + ? ? ? ? ? ? ? ret = davinci_spi_check_error(davinci_spi, davinci_spi->errors);
>> + ? ? ? ? ? ? ? if (ret != 0)
>> + ? ? ? ? ? ? ? ? ? ? ? return ret;
>> + ? ? ? }
>> + ? ? ? if ((davinci_spi->rcount != 0) || (davinci_spi->wcount != 0)) {
>> + ? ? ? ? ? ? ? sdev = davinci_spi->bitbang.master->dev.parent;
>> + ? ? ? ? ? ? ? dev_info(sdev, "SPI data transfer error\n");
>> + ? ? ? ? ? ? ? return -EIO;
>> + ? ? ? }
>>
>> ? ? ? ?return t->len;
>> ?}
>>
>> ?/**
>> - * davinci_spi_irq - IRQ handler for DaVinci SPI
>> + * davinci_spi_irq - probe function for SPI Master Controller
>
> This doesn't look right.
>
>> ?* @irq: IRQ number for this SPI Master
>> ?* @context_data: structure for SPI Master controller davinci_spi
>> + *
>> + * ISR will determine that interrupt arrives either for READ or WRITE command.
>> + * According to command it will do the appropriate action. It will check
>> + * transfer length and if it is not zero then dispatch transfer command again.
>> + * If transfer length is zero then it will indicate the COMPLETION so that
>> + * davinci_spi_bufs function can go ahead.
>> ?*/
>> ?static irqreturn_t davinci_spi_irq(s32 irq, void *context_data)
>> ?{
>> ? ? ? ?struct davinci_spi *davinci_spi = context_data;
>> - ? ? ? u32 int_status, rx_data = 0;
>> - ? ? ? irqreturn_t ret = IRQ_NONE;
>> + ? ? ? int status;
>>
>> - ? ? ? int_status = ioread32(davinci_spi->base + SPIFLG);
>> + ? ? ? status = davinci_spi_process_events(davinci_spi);
>> + ? ? ? if (unlikely(status != 0))
>> + ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIINT, SPIINT_MASKINT);
>>
>> - ? ? ? while ((int_status & SPIFLG_RX_INTR_MASK)) {
>> - ? ? ? ? ? ? ? if (likely(int_status & SPIFLG_RX_INTR_MASK)) {
>> - ? ? ? ? ? ? ? ? ? ? ? ret = IRQ_HANDLED;
>> + ? ? ? if ((davinci_spi->rcount == 0) || (status != 0))
>> + ? ? ? ? ? ? ? complete(&(davinci_spi->done));
>>
>> - ? ? ? ? ? ? ? ? ? ? ? rx_data = ioread32(davinci_spi->base + SPIBUF);
>> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->get_rx(rx_data, davinci_spi);
>> + ? ? ? return IRQ_HANDLED;
>> +}
>>
>> - ? ? ? ? ? ? ? ? ? ? ? /* Disable Receive Interrupt */
>> - ? ? ? ? ? ? ? ? ? ? ? iowrite32(~(SPIINT_RX_INTR | SPIINT_TX_INTR),
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? davinci_spi->base + SPIINT);
>> - ? ? ? ? ? ? ? } else
>> - ? ? ? ? ? ? ? ? ? ? ? (void)davinci_spi_check_error(davinci_spi, int_status);
>> +resource_size_t davinci_spi_get_dma_by_index(struct platform_device *dev,
>> + ? ? ? ? ? ? ? unsigned long index)
>> +{
>> + ? ? ? struct resource *r;
>>
>> - ? ? ? ? ? ? ? int_status = ioread32(davinci_spi->base + SPIFLG);
>> - ? ? ? }
>> + ? ? ? r = platform_get_resource(dev, IORESOURCE_DMA, index);
>> + ? ? ? if (r != NULL)
>> + ? ? ? ? ? ? ? return r->start;
>>
>> - ? ? ? return ret;
>> + ? ? ? return SPI_NO_RESOURCE;
>> ?}
>>
>> ?/**
>> ?* davinci_spi_probe - probe function for SPI Master Controller
>> ?* @pdev: platform_device structure which contains plateform specific data
>> + *
>> + * According to Linux Device Model this function will be invoked by Linux
>> + * with platform_device struct which contains the device specific info.
>> + * This function will map the SPI controller's memory, register IRQ,
>> + * Reset SPI controller and setting its registers to default value.
>> + * It will invoke spi_bitbang_start to create work queue so that client driver
>> + * can register transfer method to work queue.
>
> Another candidate; improve documentation
>
>> ?*/
>> ?static int davinci_spi_probe(struct platform_device *pdev)
>> ?{
>> @@ -1020,6 +887,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
>> ? ? ? ?resource_size_t dma_tx_chan = SPI_NO_RESOURCE;
>> ? ? ? ?resource_size_t dma_eventq = SPI_NO_RESOURCE;
>> ? ? ? ?int i = 0, ret = 0;
>> + ? ? ? u32 spipc0;
>>
>> ? ? ? ?pdata = pdev->dev.platform_data;
>> ? ? ? ?if (pdata == NULL) {
>> @@ -1071,10 +939,12 @@ static int davinci_spi_probe(struct platform_device *pdev)
>> ? ? ? ? ? ? ? ?goto unmap_io;
>> ? ? ? ?}
>>
>> - ? ? ? ret = request_irq(davinci_spi->irq, davinci_spi_irq, IRQF_DISABLED,
>> + ? ? ? ret = request_irq(davinci_spi->irq, davinci_spi_irq, 0,
>> ? ? ? ? ? ? ? ? ? ? ? ? ?dev_name(&pdev->dev), davinci_spi);
>> - ? ? ? if (ret)
>> + ? ? ? if (ret != 0) {
>> + ? ? ? ? ? ? ? ret = -EAGAIN;
>> ? ? ? ? ? ? ? ?goto unmap_io;
>> + ? ? ? }
>>
>> ? ? ? ?/* Allocate tmp_buf for tx_buf */
>> ? ? ? ?davinci_spi->tmp_buf = kzalloc(SPI_BUFSIZ, GFP_KERNEL);
>> @@ -1104,55 +974,23 @@ static int davinci_spi_probe(struct platform_device *pdev)
>>
>> ? ? ? ?davinci_spi->bitbang.chipselect = davinci_spi_chipselect;
>> ? ? ? ?davinci_spi->bitbang.setup_transfer = davinci_spi_setup_transfer;
>> + ? ? ? davinci_spi->bitbang.txrx_bufs = davinci_spi_txrx_bufs;
>>
>> ? ? ? ?davinci_spi->version = pdata->version;
>> - ? ? ? use_dma = pdata->use_dma;
>>
>> ? ? ? ?davinci_spi->bitbang.flags = SPI_NO_CS | SPI_LSB_FIRST | SPI_LOOP;
>> ? ? ? ?if (davinci_spi->version == SPI_VERSION_2)
>> ? ? ? ? ? ? ? ?davinci_spi->bitbang.flags |= SPI_READY;
>>
>> - ? ? ? if (use_dma) {
>> - ? ? ? ? ? ? ? ? ? ? ? r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
>> - ? ? ? ? ? ? ? ? ? ? ? if (r)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_rx_chan = r->start;
>> - ? ? ? ? ? ? ? ? ? ? ? r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
>> - ? ? ? ? ? ? ? ? ? ? ? if (r)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_tx_chan = r->start;
>> - ? ? ? ? ? ? ? ? ? ? ? r = platform_get_resource(pdev, IORESOURCE_DMA, 2);
>> - ? ? ? ? ? ? ? ? ? ? ? if (r)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_eventq = r->start;
>> - ? ? ? }
>> -
>> - ? ? ? if (!use_dma ||
>> - ? ? ? ? ? dma_rx_chan == SPI_NO_RESOURCE ||
>> - ? ? ? ? ? dma_tx_chan == SPI_NO_RESOURCE ||
>> - ? ? ? ? ? dma_eventq ?== SPI_NO_RESOURCE) {
>> - ? ? ? ? ? ? ? davinci_spi->bitbang.txrx_bufs = davinci_spi_bufs_pio;
>> - ? ? ? ? ? ? ? use_dma = 0;
>> - ? ? ? } else {
>> - ? ? ? ? ? ? ? davinci_spi->bitbang.txrx_bufs = davinci_spi_bufs_dma;
>> - ? ? ? ? ? ? ? davinci_spi->dma_channels = kzalloc(master->num_chipselect
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? * sizeof(struct davinci_spi_dma), GFP_KERNEL);
>> - ? ? ? ? ? ? ? if (davinci_spi->dma_channels == NULL) {
>> - ? ? ? ? ? ? ? ? ? ? ? ret = -ENOMEM;
>> - ? ? ? ? ? ? ? ? ? ? ? goto free_clk;
>> - ? ? ? ? ? ? ? }
>> -
>> - ? ? ? ? ? ? ? for (i = 0; i < master->num_chipselect; i++) {
>> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].dma_rx_channel = -1;
>> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].dma_rx_sync_dev =
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_rx_chan;
>> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].dma_tx_channel = -1;
>> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].dma_tx_sync_dev =
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_tx_chan;
>> - ? ? ? ? ? ? ? ? ? ? ? davinci_spi->dma_channels[i].eventq = dma_eventq;
>> - ? ? ? ? ? ? ? }
>> - ? ? ? ? ? ? ? dev_info(&pdev->dev, "DaVinci SPI driver in EDMA mode\n"
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Using RX channel = %d , TX channel = %d and "
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "event queue = %d", dma_rx_chan, dma_tx_chan,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_eventq);
>> - ? ? ? }
>> + ? ? ? dma_rx_chan = davinci_spi_get_dma_by_index(pdev, RX_DMA_INDEX);
>> + ? ? ? dma_tx_chan = davinci_spi_get_dma_by_index(pdev, TX_DMA_INDEX);
>> + ? ? ? dma_eventq ?= davinci_spi_get_dma_by_index(pdev, EVENTQ_DMA_INDEX);
>> + ? ? ? davinci_spi->dma_channels.dma_rx_channel = -1;
>> + ? ? ? davinci_spi->dma_channels.dma_rx_sync_dev = dma_rx_chan;
>> + ? ? ? davinci_spi->dma_channels.dma_tx_channel = -1;
>> + ? ? ? davinci_spi->dma_channels.dma_tx_sync_dev = dma_tx_chan;
>> + ? ? ? davinci_spi->dma_channels.dummy_param_slot = -1;
>> + ? ? ? davinci_spi->dma_channels.eventq = dma_eventq;
>>
>> ? ? ? ?davinci_spi->get_rx = davinci_spi_rx_buf_u8;
>> ? ? ? ?davinci_spi->get_tx = davinci_spi_tx_buf_u8;
>> @@ -1164,31 +1002,28 @@ static int davinci_spi_probe(struct platform_device *pdev)
>> ? ? ? ?udelay(100);
>> ? ? ? ?iowrite32(1, davinci_spi->base + SPIGCR0);
>>
>> - ? ? ? /* Clock internal */
>> - ? ? ? if (davinci_spi->pdata->clk_internal)
>> - ? ? ? ? ? ? ? set_io_bits(davinci_spi->base + SPIGCR1,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_CLKMOD_MASK);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? clear_io_bits(davinci_spi->base + SPIGCR1,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SPIGCR1_CLKMOD_MASK);
>> + ? ? ? /* Set up SPIPC0. ?CS and ENA init is done in davinci_spi_setup */
>> + ? ? ? spipc0 = SPIPC0_DIFUN_MASK | SPIPC0_DOFUN_MASK | SPIPC0_CLKFUN_MASK;
>> + ? ? ? iowrite32(spipc0, davinci_spi->base + SPIPC0);
>>
>> - ? ? ? /* master mode default */
>> - ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK);
>> + ? ? ? /* initialize chip selects */
>> + ? ? ? if (pdata->chip_sel != NULL) {
>> + ? ? ? ? ? ? ? for (i = 0; i < pdata->num_chipselect; i++) {
>> + ? ? ? ? ? ? ? ? ? ? ? if (pdata->chip_sel[i] != SPI_INTERN_CS)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? gpio_direction_output(pdata->chip_sel[i], 1);
>> + ? ? ? ? ? ? ? }
>> + ? ? ? }
>> + ? ? ? iowrite32(SPIDEF_CSDEF_MASK, davinci_spi->base + SPIDEF);
>>
>> - ? ? ? if (davinci_spi->pdata->intr_level)
>> - ? ? ? ? ? ? ? iowrite32(SPI_INTLVL_1, davinci_spi->base + SPILVL);
>> - ? ? ? else
>> - ? ? ? ? ? ? ? iowrite32(SPI_INTLVL_0, davinci_spi->base + SPILVL);
>> + ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_CLKMOD_MASK);
>> + ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_MASTER_MASK);
>> + ? ? ? set_io_bits(davinci_spi->base + SPIGCR1, SPIGCR1_POWERDOWN_MASK);
>>
>> ? ? ? ?ret = spi_bitbang_start(&davinci_spi->bitbang);
>> - ? ? ? if (ret)
>> + ? ? ? if (ret != 0)
>> ? ? ? ? ? ? ? ?goto free_clk;
>>
>> - ? ? ? dev_info(&pdev->dev, "Controller at 0x%p \n", davinci_spi->base);
>> -
>> - ? ? ? if (!pdata->poll_mode)
>> - ? ? ? ? ? ? ? dev_info(&pdev->dev, "Operating in interrupt mode"
>> - ? ? ? ? ? ? ? ? ? ? ? " using IRQ %d\n", davinci_spi->irq);
>> + ? ? ? dev_info(&pdev->dev, "Controller at 0x%p\n", davinci_spi->base);
>>
>> ? ? ? ?return ret;
>>
>> @@ -1220,7 +1055,7 @@ err:
>> ?* It will also call spi_bitbang_stop to destroy the work queue which was
>> ?* created by spi_bitbang_start.
>> ?*/
>> -static int __exit davinci_spi_remove(struct platform_device *pdev)
>> +static int __devexit davinci_spi_remove(struct platform_device *pdev)
>> ?{
>> ? ? ? ?struct davinci_spi *davinci_spi;
>> ? ? ? ?struct spi_master *master;
>> @@ -1242,8 +1077,11 @@ static int __exit davinci_spi_remove(struct platform_device *pdev)
>> ?}
>>
>> ?static struct platform_driver davinci_spi_driver = {
>> - ? ? ? .driver.name = "spi_davinci",
>> - ? ? ? .remove = __exit_p(davinci_spi_remove),
>> + ? ? ? .driver = {
>> + ? ? ? ? ? ? ? .name = "spi_davinci",
>> + ? ? ? ? ? ? ? .owner = THIS_MODULE,
>> + ? ? ? },
>> + ? ? ? .remove = __devexit_p(davinci_spi_remove),
>> ?};
>
> Another candidate. ?Corrections to platform_driver structure and
> __devexit annotations.
>
>>
>> ?static int __init davinci_spi_init(void)
>> --
>> 1.6.3.3
>>
>>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>

From zhan5425 at 163.com  Mon Aug  2 02:32:11 2010
From: zhan5425 at 163.com (=?gbk?B?1bKzyb2t?=)
Date: Mon, 2 Aug 2010 15:32:11 +0800 (CST)
Subject: Multiple NAND chips on OMAPL137
Message-ID: <ae4f7f.bf99.12a31b70411.Coremail.zhan5425@163.com>

Hi,

     We want to use tow NADN chips on Omapl137 device,They are selected by CS3 and CS4 on EMFIA,Now I can use one Nandflash chip on CS3 with MTD. The chip can be found by uboot or Linux kernel,when linux kernel starting ,the nandflash was created to 5  MTD partitions on "nand_davinci.0" as below:
                         0x00000000-0x00020000 : "bootloader"
                         0x00020000-0x00040000 : "params"
                         0x00200000-0x00400000 : "kernel"
                         0x00400000-0x00800000 : "RamDisk"
                         0x00800000-0x04000000 : "yaffs2"
It's ok.   Now I want to use another chip for file system,2Gbits.But I don't know how to use it,Is there any project to use linux MTD like this,or omapl37 can't support two chips at the same time?  Any thoughts/pitfalls would be appreciated.

thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100802/4f3d1c15/attachment.html>

From nsekhar at ti.com  Mon Aug  2 10:53:16 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 2 Aug 2010 21:23:16 +0530
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<1280355490-11878-2-git-send-email-bniebuhr@efjohnson.com>
	<AANLkTimu+G-5wTrdQ6YiWi60i+5uN9sydfsZKMKQX7_f@mail.gmail.com>
	<AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A13@dbde02.ent.ti.com>


Hi Brian,

On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
> Grant -
>

>  For my part, I've already sunk way more time into this than I ever
> intended, and I really have no clue how to break this patch down into
> smaller patches.  I don't really care much if the patch gets accepted
> or not - I am just trying to help out all of the other users that are
> stuck with a broken driver like I was.  Maybe if TI wants to give
> their customers a driver that actually works they'll pick it up and do
> the rest of the work that's necessary to get it accepted.

Thanks for all the work on this so far. We will work on breaking
this patch up and getting the fixes accepted upstream.

Regards,
Sekhar

From nsekhar at ti.com  Mon Aug  2 11:04:46 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 2 Aug 2010 21:34:46 +0530
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <201008012115.16423.sshtylyov@ru.mvista.com>
References: <201008012115.16423.sshtylyov@ru.mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A21@dbde02.ent.ti.com>


Hi Sergei,

On Sun, Aug 01, 2010 at 22:45:16, Sergei Shtylyov wrote:
> The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
> specific

Have you come across any board which uses different set of pins?

On NAND the ALE/CLE pins could (theoretically) be different on different boards
but as long as you are booting from NAND, you are stuck with the same address lines
as that used by ROM code.

On NOR, a board with 8-bit NOR could probably do with less number of pins so may be
that could be included in the common list and the board file could optionally list
pins 8-15?

Thanks,
Sekhar



From nsekhar at ti.com  Mon Aug  2 11:15:30 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 2 Aug 2010 21:45:30 +0530
Subject: [PATCH 2/2] DA850: move MII/RMII pin lists to the board file
In-Reply-To: <201008012117.00730.sshtylyov@ru.mvista.com>
References: <201008012117.00730.sshtylyov@ru.mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A2B@dbde02.ent.ti.com>

On Sun, Aug 01, 2010 at 22:47:00, Sergei Shtylyov wrote:
> The CPGMAC pin list in da850.c was incorrectly split into two MII/RMII mode
> specific pin lists, while what pin group is used is a function of how the board
> is wired.  Copy the pin lists to board-da850-evm.c, renaming them accordingly,
> and merge the two lists in da850.c into one, da850_cpgmac_pins[], representing
> the CPGMAC module as a whole...

da850_cpgmac_pins[] is not going to be useful because the board can either be
in MII or RMII mode. The pins for the unused mode are likely be used for other
purposes.

How about creating a common list of pins and two other lists for MII and RMII
pins which could probably be placed in the board file.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Aug  2 11:35:04 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 2 Aug 2010 22:05:04 +0530
Subject: Touchscreen - MFD driver for TPS6507x family
In-Reply-To: <AANLkTimU=-dnm+sTSLg1fQeZ4uYaXMJA=BQ5f_OESRyz@mail.gmail.com>
References: <AANLkTikk0V460qb14nZeghWMzcPtPGu2_HzDHtc6rgQu@mail.gmail.com>
	<201006081014.33072.caglarakyuz@gmail.com>
	<1089858925.76837.1275989074229.JavaMail.open-xchange@oxltgw14.schlund.de>
	<201006081305.15022.caglarakyuz@gmail.com>
	<AANLkTikdT6O4f4GuD0Hwl6UIk5GS5EU2tAB6YB3lfT1N@mail.gmail.com>
	<903202309.136917.1276073978778.JavaMail.open-xchange@oxltgw02.schlund.de>
	<1276114677.21486.872.camel@sax-lx>
	<AANLkTi=pXq8f+X1+Y50zNmBkjPSEaSFDh0bjtcbYFwRy@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7E3A1DB@dbde02.ent.ti.com>
	<1280403790.22713.8.camel@sax-lx>
	<AANLkTinPagcWmk-oSxH7fsOx6cV5PksFuXyQf0ybLQMX@mail.gmail.com>
	<AANLkTimFCrcrTHP9p5PbBDn3CaJ6mnOU4KiSZ-YC1Lpx@mail.gmail.com>
	<1280416797.22713.502.camel@sax-lx>
	<AANLkTikMuo0Bv_w7JDLn+QivyF8aOSwdqapzRMxosH4t@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7E3AA61@dbde02.ent.ti.com>
	<AANLkTimU=-dnm+sTSLg1fQeZ4uYaXMJA=BQ5f_OESRyz@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A40@dbde02.ent.ti.com>


Hi Nicolas,

On Fri, Jul 30, 2010 at 23:05:21, Nicolas Luna wrote:
> Sekhar,
>
> We do not have this buffer on our custom hardware and we have the NACK
> problem. SDA and SCL are directly connected from PMIC to OMAP with
> pull-up.
>
> Is Todd right with the silicon issue? Or a I2C driver issue when it is
> used too much... ?

There is no silicon issue that I know of. The silicon meets I2C specification.
All the advisories with silicon are documented here: http://focus.ti.com/lit/er/sprz301c/sprz301c.pdf

>       i2c_davinci i2c_davinci.1: controller timed out
>       i2c_davinci i2c_davinci.1: initiating i2c bus recovery

I remember users on the list reporting these errors when a slave device is
pulling the clock low for a long time. The first thing to try is a lower
bus frequency - this is done on DM644x EVM to talk to a slow MSP430 based
slave.

Also, as I remember, this can even be caused by a slave you are not talking to.
Are there other devices on the I2C bus?

Thanks,
Sekhar

From michael.williamson at criticallink.com  Mon Aug  2 11:42:55 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Mon, 02 Aug 2010 12:42:55 -0400
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A21@dbde02.ent.ti.com>
References: <201008012115.16423.sshtylyov@ru.mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A21@dbde02.ent.ti.com>
Message-ID: <4C56F58F.4080801@criticallink.com>

 On 8/2/2010 12:04 PM, Nori, Sekhar wrote:
> Hi Sergei,
>
> On Sun, Aug 01, 2010 at 22:45:16, Sergei Shtylyov wrote:
>> The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
>> specific
> Have you come across any board which uses different set of pins?
>
> On NAND the ALE/CLE pins could (theoretically) be different on different boards
> but as long as you are booting from NAND, you are stuck with the same address lines
> as that used by ROM code.
>
> On NOR, a board with 8-bit NOR could probably do with less number of pins so may be
> that could be included in the common list and the board file could optionally list
> pins 8-15?

There are boards using da850 architecture that use 16-bit NAND instead of 8-bit.
So at least having separate lists (or an extension) to support the upper data
lines for the NAND pins might be nice if the lists are maintained in a common location...

-Mike

From sshtylyov at mvista.com  Mon Aug  2 12:16:25 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Mon, 02 Aug 2010 21:16:25 +0400
Subject: [PATCH 2/2] DA850: move MII/RMII pin lists to the board file
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A2B@dbde02.ent.ti.com>
References: <201008012117.00730.sshtylyov@ru.mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A2B@dbde02.ent.ti.com>
Message-ID: <4C56FD69.5070903@mvista.com>

Hello.

Nori, Sekhar wrote:

>> The CPGMAC pin list in da850.c was incorrectly split into two MII/RMII mode
>> specific pin lists, while what pin group is used is a function of how the board
>> is wired.  Copy the pin lists to board-da850-evm.c, renaming them accordingly,
>> and merge the two lists in da850.c into one, da850_cpgmac_pins[], representing
>> the CPGMAC module as a whole...

> da850_cpgmac_pins[] is not going to be useful 

    I know. Nevertheless, in da850.c we should have the generic pin lists, per 
module. Not always useful, but that's the rule.

> because the board can either be
> in MII or RMII mode. The pins for the unused mode are likely be used for other
> purposes.

> How about creating a common list of pins and two other lists for MII and RMII
> pins which could probably be placed in the board file.

    I thought that was what I did...

> Thanks,
> Sekhar

WBR, Sergei

From sshtylyov at mvista.com  Mon Aug  2 12:24:08 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Mon, 02 Aug 2010 21:24:08 +0400
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A21@dbde02.ent.ti.com>
References: <201008012115.16423.sshtylyov@ru.mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A21@dbde02.ent.ti.com>
Message-ID: <4C56FF38.4090606@mvista.com>

Hello.

Nori, Sekhar wrote:

> On Sun, Aug 01, 2010 at 22:45:16, Sergei Shtylyov wrote:
>> The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
>> specific

> Have you come across any board which uses different set of pins?

    I think you have been replied already.

> On NAND the ALE/CLE pins could (theoretically) be different on different boards
> but as long as you are booting from NAND, you are stuck with the same address lines
> as that used by ROM code.

    And?

> On NOR, a board with 8-bit NOR could probably do with less number of pins so may be
> that could be included in the common list and the board file could optionally list
> pins 8-15?

    The "common" lists (in da8[35]0.c) were meant to be per-module lists, not 
per module function lists, so there could be no NAND/NOR lists there. Those 
lists are not always useful, I agree -- but that was the design.

> Thanks,
> Sekhar

WBR, Sergei


From luna.id at gmail.com  Mon Aug  2 14:51:14 2010
From: luna.id at gmail.com (Nicolas Luna)
Date: Mon, 2 Aug 2010 15:51:14 -0400
Subject: Touchscreen - MFD driver for TPS6507x family
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A40@dbde02.ent.ti.com>
References: <AANLkTikk0V460qb14nZeghWMzcPtPGu2_HzDHtc6rgQu@mail.gmail.com>
	<201006081014.33072.caglarakyuz@gmail.com>
	<1089858925.76837.1275989074229.JavaMail.open-xchange@oxltgw14.schlund.de>
	<201006081305.15022.caglarakyuz@gmail.com>
	<AANLkTikdT6O4f4GuD0Hwl6UIk5GS5EU2tAB6YB3lfT1N@mail.gmail.com>
	<903202309.136917.1276073978778.JavaMail.open-xchange@oxltgw02.schlund.de>
	<1276114677.21486.872.camel@sax-lx>
	<AANLkTi=pXq8f+X1+Y50zNmBkjPSEaSFDh0bjtcbYFwRy@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7E3A1DB@dbde02.ent.ti.com>
	<1280403790.22713.8.camel@sax-lx>
	<AANLkTinPagcWmk-oSxH7fsOx6cV5PksFuXyQf0ybLQMX@mail.gmail.com>
	<AANLkTimFCrcrTHP9p5PbBDn3CaJ6mnOU4KiSZ-YC1Lpx@mail.gmail.com>
	<1280416797.22713.502.camel@sax-lx>
	<AANLkTikMuo0Bv_w7JDLn+QivyF8aOSwdqapzRMxosH4t@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7E3AA61@dbde02.ent.ti.com>
	<AANLkTimU=-dnm+sTSLg1fQeZ4uYaXMJA=BQ5f_OESRyz@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A40@dbde02.ent.ti.com>
Message-ID: <AANLkTin0kCKKSjse=Sbgsry_P-oUaTAmGHXRUL78W=Bu@mail.gmail.com>

Hi Sekhar,

Yes there is an other device on the bus, but I removed it and I decreased
the clock to 20khz. I cannot go below because the i2c seems not to work. It
does solved the problem.

I modified the driver to add a while(1) when it got an abnormal termination.
I notified that every time the driver makes this error, I can see a clock
stretch (with a scope) on the last i2c frame.

- The PMIC (tps65070) is rated to work at 400khz, but even at 20khz it seems
to need more time to response when it is addressed to much. I modified the
touchscreen polling period to 100 msec and I still got errors. Maybe if the
touchscreen driver was working by interruption that would leave a chance to
the PMIC.

- Why the i2c driver do not handles clock stretching?

- On a test there was 2 successive reads to register 02h with a delay of 85
msec between. The first went right but while the next read, the salve put
the clock low to stretch it. It sounds like a problem to me because the chip
was not receiving a lot of messages and it stretched the clock. I cannot
find any place in the datasheet that is talking about that issue.

Thank you.

Regards,

Nicolas



On Mon, Aug 2, 2010 at 12:35 PM, Nori, Sekhar <nsekhar at ti.com> wrote:

>
> Hi Nicolas,
>
> On Fri, Jul 30, 2010 at 23:05:21, Nicolas Luna wrote:
> > Sekhar,
> >
> > We do not have this buffer on our custom hardware and we have the NACK
> > problem. SDA and SCL are directly connected from PMIC to OMAP with
> > pull-up.
> >
> > Is Todd right with the silicon issue? Or a I2C driver issue when it is
> > used too much... ?
>
> There is no silicon issue that I know of. The silicon meets I2C
> specification.
> All the advisories with silicon are documented here:
> http://focus.ti.com/lit/er/sprz301c/sprz301c.pdf
>
> >       i2c_davinci i2c_davinci.1: controller timed out
> >       i2c_davinci i2c_davinci.1: initiating i2c bus recovery
>
> I remember users on the list reporting these errors when a slave device is
> pulling the clock low for a long time. The first thing to try is a lower
> bus frequency - this is done on DM644x EVM to talk to a slow MSP430 based
> slave.
>
> Also, as I remember, this can even be caused by a slave you are not talking
> to.
> Are there other devices on the I2C bus?
>
> Thanks,
> Sekhar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100802/2d3d606e/attachment.html>

From grant.likely at secretlab.ca  Tue Aug  3 02:33:55 2010
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 3 Aug 2010 01:33:55 -0600
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com> 
	<1280355490-11878-2-git-send-email-bniebuhr@efjohnson.com> 
	<AANLkTimu+G-5wTrdQ6YiWi60i+5uN9sydfsZKMKQX7_f@mail.gmail.com> 
	<AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
Message-ID: <AANLkTik99cgA83iOZPbidri000Lg2u-YCPUHU9PS5-=U@mail.gmail.com>

On Mon, Aug 2, 2010 at 8:10 AM, Brian Niebuhr <bniebuhr3 at gmail.com> wrote:
> Grant -
>
> That's fine - I understand your position. ?I do wish you had decided
> earlier that you weren't going to accept the patch in that form though
> so I could have decided whether I wanted to spend any more time on it.
> ?For my part, I've already sunk way more time into this than I ever
> intended, and I really have no clue how to break this patch down into
> smaller patches. ?I don't really care much if the patch gets accepted
> or not - I am just trying to help out all of the other users that are
> stuck with a broken driver like I was.

Hi Brian.  I'm sorry to hear that, but I totally understand having
heavy demands on your time.  Thanks for the work that you have done.
I know it is frustrating when things don't go in as easily as hoped.
I also want to see your changes merged, but I also have to be mindful
of other engineers looking at your commit after the fact and being
able to bisect it.

If you do change your mind, my offer still stands to help you break
the patch down into logical pieces.  It is actually pretty easy to do.

>?Maybe if TI wants to give
> their customers a driver that actually works they'll pick it up and do
> the rest of the work that's necessary to get it accepted. ?I'm just
> way too swamped with other work to keep going on this.
>
> Thanks for your help though. ?Sorry to waste all of the time you've
> put into this.

It hasn't been wasted time.  You've done all the hard work.  Sounds
like Sekhar from TI will pick up the driver and split it up, which is
an almost mechanical process when you know how to do it.  Thanks for
the time you have spent on this.

Cheers,
g.

From c.aeschlimann at acn-group.ch  Tue Aug  3 02:55:58 2010
From: c.aeschlimann at acn-group.ch (Christophe Aeschlimann)
Date: Tue, 03 Aug 2010 09:55:58 +0200
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>	<1280355490-11878-2-git-send-email-bniebuhr@efjohnson.com>	<AANLkTimu+G-5wTrdQ6YiWi60i+5uN9sydfsZKMKQX7_f@mail.gmail.com>
	<AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
Message-ID: <4C57CB8E.6050207@acn-group.ch>

Hi,

On 02.08.2010 16:10, Brian Niebuhr wrote:
> Grant -

[...]

> I am just trying to help out all of the other users that are
> stuck with a broken driver like I was.  

Thank you Brian. The work you've done there is very much appreciated.

> Maybe if TI wants to give their customers a driver that actually 
> works they'll pick it up and do the rest of the work that's necessary 
> to get it accepted.  

It seems they got the message ! :)

> Brian

Regards,

-- 
Christophe Aeschlimann

Embedded Software Engineer

Advanced Communications Networks S.A.

Rue du Puits-Godet 8a
2000 Neuch?tel, Switzerland

T?l. +41 32 724 74 31

c.aeschlimann at acn-group.ch

From nsekhar at ti.com  Tue Aug  3 08:24:12 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 3 Aug 2010 18:54:12 +0530
Subject: [PATCH 2/2] DA850: move MII/RMII pin lists to the board file
In-Reply-To: <4C56FD69.5070903@mvista.com>
References: <201008012117.00730.sshtylyov@ru.mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A2B@dbde02.ent.ti.com>
	<4C56FD69.5070903@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED1067@dbde02.ent.ti.com>


Hi Sergei,

On Mon, Aug 02, 2010 at 22:46:25, Sergei Shtylyov wrote:
> Hello.
>
> Nori, Sekhar wrote:
>
> >> The CPGMAC pin list in da850.c was incorrectly split into two MII/RMII mode
> >> specific pin lists, while what pin group is used is a function of how the board
> >> is wired.  Copy the pin lists to board-da850-evm.c, renaming them accordingly,
> >> and merge the two lists in da850.c into one, da850_cpgmac_pins[], representing
> >> the CPGMAC module as a whole...
>
> > da850_cpgmac_pins[] is not going to be useful
>
>     I know. Nevertheless, in da850.c we should have the generic pin lists, per
> module. Not always useful, but that's the rule.

If the common list is never going to be used, it should be removed to save bytes.

Thanks,
Sekhar


From cyril at ti.com  Tue Aug  3 08:31:45 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:45 -0400
Subject: [PATCH 0/8] split out emac cpdma and mdio for reuse
Message-ID: <1280842313-3743-1-git-send-email-cyril@ti.com>

Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine.
These hardware modules are not restricted to EMAC device alone.  For example,
CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules
internally.  This patch series separates out EMAC's MDIO and CPDMA
functionality, allowing these individual pieces to be reused across TI
hardware.  

This patch series has been broadly organized as follows:

MDIO:
  - Add new functionality
      netdev: separate out davinci mdio controller code
  - Hookup new functionality
      davinci: add mdio platform devices
      netdev: switch davinci emac to new mdio driver
  - Cleanup left over cruft
      davinci: cleanup unused davinci mdio arch code
      netdev: cleanup unused davinci mdio emac code

CPDMA:
  - Add new functionality
     netdev: separate out davinci cpdma controller code
  - Hookup new functionality
     netdev: switch davinci emac to new cpdma layer
  - Cleanup left over cruft
     netdev: cleanup unused davinci emac cpdma code

This series has been tested on dm365 and tnetv107x (with additional cpsw
patches) hardware.  Additional omap tree patches will be required for am35xx
as well (not included here).


Cyril Chemparathy (8):
  netdev: separate out davinci mdio controller code
  davinci: add mdio platform devices
  netdev: switch davinci emac to new mdio driver
  davinci: cleanup unused davinci mdio arch code
  netdev: cleanup unused davinci mdio emac code
  netdev: separate out davinci cpdma controller code
  netdev: switch davinci emac to new cpdma layer
  netdev: cleanup unused davinci emac cpdma code

 arch/arm/mach-davinci/board-da830-evm.c     |    5 -
 arch/arm/mach-davinci/board-da850-evm.c     |    6 -
 arch/arm/mach-davinci/board-dm365-evm.c     |    7 -
 arch/arm/mach-davinci/board-dm644x-evm.c    |    7 -
 arch/arm/mach-davinci/board-dm646x-evm.c    |    8 -
 arch/arm/mach-davinci/board-neuros-osd2.c   |    7 -
 arch/arm/mach-davinci/board-sffsdr.c        |    7 -
 arch/arm/mach-davinci/devices-da8xx.c       |   31 +-
 arch/arm/mach-davinci/dm365.c               |   23 +-
 arch/arm/mach-davinci/dm644x.c              |   23 +-
 arch/arm/mach-davinci/dm646x.c              |   23 +-
 arch/arm/mach-davinci/include/mach/dm365.h  |    2 +-
 arch/arm/mach-davinci/include/mach/dm644x.h |    2 +-
 arch/arm/mach-davinci/include/mach/dm646x.h |    2 +-
 drivers/net/Kconfig                         |   21 +
 drivers/net/Makefile                        |    2 +
 drivers/net/davinci_cpdma.c                 |  836 +++++++++++++++++
 drivers/net/davinci_cpdma.h                 |  105 +++
 drivers/net/davinci_emac.c                  | 1335 ++++-----------------------
 drivers/net/davinci_mdio.c                  |  386 ++++++++
 include/linux/davinci_emac.h                |    8 +-
 21 files changed, 1615 insertions(+), 1231 deletions(-)
 create mode 100644 drivers/net/davinci_cpdma.c
 create mode 100644 drivers/net/davinci_cpdma.h
 create mode 100644 drivers/net/davinci_mdio.c


From cyril at ti.com  Tue Aug  3 08:31:46 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:46 -0400
Subject: [PATCH 1/8] netdev: separate out davinci mdio controller code
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <1280842313-3743-2-git-send-email-cyril@ti.com>

Davinci's MDIO controller is present on other TI devices, without an
accompanying EMAC.  For example, on tnetv107x, the same MDIO module is used in
conjunction with a 3-port switch hardware.

By separating the MDIO controller code into its own platform driver, this
patch allows common logic to be reused on such platforms.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 drivers/net/Kconfig          |   10 +
 drivers/net/Makefile         |    1 +
 drivers/net/davinci_mdio.c   |  386 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/davinci_emac.h |    4 +
 4 files changed, 401 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/davinci_mdio.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2decc59..fe6658a 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -947,6 +947,16 @@ config TI_DAVINCI_EMAC
 	  To compile this driver as a module, choose M here: the module
 	  will be called davinci_emac_driver.  This is recommended.
 
+config TI_DAVINCI_MDIO
+	tristate "TI DaVinci MDIO Support"
+	depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
+	select PHYLIB
+	help
+	  This driver supports TI's DaVinci MDIO module.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called davinci_mdio.  This is recommended.
+
 config DM9000
 	tristate "DM9000 support"
 	depends on ARM || BLACKFIN || MIPS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 0a0512a..84cf18d 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_MDIO) += mdio.o
 obj-$(CONFIG_PHYLIB) += phy/
 
 obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
+obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
 
 obj-$(CONFIG_E1000) += e1000/
 obj-$(CONFIG_E1000E) += e1000e/
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
new file mode 100644
index 0000000..d34a53a
--- /dev/null
+++ b/drivers/net/davinci_mdio.c
@@ -0,0 +1,386 @@
+/*
+ * DaVinci MDIO Module driver
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * Shamelessly ripped out of davinci_emac.c, original copyrights follow:
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * ---------------------------------------------------------------------------
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * ---------------------------------------------------------------------------
+ */
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/phy.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/davinci_emac.h>
+
+#define PHY_REG_MASK		0x1f
+#define PHY_ID_MASK		0x1f
+
+#define DEF_OUT_FREQ		2200000		/* 2.2 MHz */
+
+struct davinci_mdio_regs {
+	u32	version;
+	u32	control;
+#define CONTROL_IDLE		BIT(31)
+#define CONTROL_ENABLE		BIT(30)
+#define CONTROL_MAX_DIV		(0xff)
+
+	u32	alive;
+	u32	link;
+	u32	linkintraw;
+	u32	linkintmasked;
+	u32	__reserved_0[2];
+	u32	userintraw;
+	u32	userintmasked;
+	u32	userintmaskset;
+	u32	userintmaskclr;
+	u32	__reserved_1[20];
+
+	struct {
+		u32	access;
+#define USERACCESS_GO		BIT(31)
+#define USERACCESS_WRITE	BIT(30)
+#define USERACCESS_ACK		BIT(29)
+#define USERACCESS_READ		(0)
+#define USERACCESS_DATA		(0xffff)
+
+		u32	physel;
+	}	user[0];
+};
+
+struct mdio_platform_data default_pdata = {
+	.bus_freq = DEF_OUT_FREQ,
+};
+
+struct davinci_mdio_data {
+	struct mdio_platform_data pdata;
+	struct davinci_mdio_regs __iomem *regs;
+	spinlock_t	lock;
+	struct clk	*clk;
+	struct device	*dev;
+	struct mii_bus	*bus;
+	bool		suspended;
+};
+
+/* wait until hardware is ready for another user access */
+static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
+{
+	struct davinci_mdio_regs __iomem *regs = data->regs;
+	u32 reg;
+
+	while ((reg = __raw_readl(&regs->user[0].access)) & USERACCESS_GO)
+		;
+
+	return reg;
+}
+
+/* wait until hardware state machine is idle */
+static inline void wait_for_idle(struct davinci_mdio_data *data)
+{
+	struct davinci_mdio_regs __iomem *regs = data->regs;
+
+	while ((__raw_readl(&regs->control) & CONTROL_IDLE) == 0)
+		;
+}
+
+static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
+{
+	struct davinci_mdio_data *data = bus->priv;
+	u32 reg;
+
+	if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
+		return -EINVAL;
+
+	spin_lock(&data->lock);
+
+	if (data->suspended) {
+		spin_unlock(&data->lock);
+		return -ENODEV;
+	}
+
+	wait_for_user_access(data);
+	reg = (USERACCESS_GO | USERACCESS_READ | (phy_reg << 21) |
+	       (phy_id << 16));
+	__raw_writel(reg, &data->regs->user[0].access);
+	reg = wait_for_user_access(data);
+	spin_unlock(&data->lock);
+
+	return (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -EIO;
+}
+
+static int davinci_mdio_write(struct mii_bus *bus, int phy_id,
+			      int phy_reg, u16 phy_data)
+{
+	struct davinci_mdio_data *data = bus->priv;
+	u32 reg;
+
+	if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
+		return -EINVAL;
+
+	spin_lock(&data->lock);
+
+	if (data->suspended) {
+		spin_unlock(&data->lock);
+		return -ENODEV;
+	}
+
+	wait_for_user_access(data);
+	reg = (USERACCESS_GO | USERACCESS_WRITE | (phy_reg << 21) |
+		   (phy_id << 16) | (phy_data & USERACCESS_DATA));
+	__raw_writel(reg, &data->regs->user[0].access);
+	wait_for_user_access(data);
+	spin_unlock(&data->lock);
+
+	return 0;
+}
+
+static int __devinit davinci_mdio_probe(struct platform_device *pdev)
+{
+	struct mdio_platform_data *pdata = pdev->dev.platform_data;
+	struct device *dev = &pdev->dev;
+	struct davinci_mdio_data *data;
+	struct resource *res;
+	u32 mdio_in_freq, mdio_out_freq, div, phy_mask, ver;
+	struct phy_device *phy;
+	int ret, addr;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		dev_err(dev, "failed to alloc device data\n");
+		return -ENOMEM;
+	}
+
+	data->pdata = pdata ? (*pdata) : default_pdata;
+
+	data->bus = mdiobus_alloc();
+	if (!data->bus) {
+		dev_err(dev, "failed to alloc mii bus\n");
+		ret = -ENOMEM;
+		goto bail_out;
+	}
+
+	data->bus->name		= dev_name(dev);
+	data->bus->read		= davinci_mdio_read,
+	data->bus->write	= davinci_mdio_write,
+	data->bus->parent	= dev;
+	data->bus->priv		= data;
+	snprintf(data->bus->id, MII_BUS_ID_SIZE, "%x", pdev->id);
+
+	data->clk = clk_get(dev, NULL);
+	if (IS_ERR(data->clk)) {
+		data->clk = NULL;
+		dev_err(dev, "failed to get device clock\n");
+		ret = PTR_ERR(data->clk);
+		goto bail_out;
+	}
+
+	clk_enable(data->clk);
+
+	dev_set_drvdata(dev, data);
+	data->dev = dev;
+	spin_lock_init(&data->lock);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "could not find register map resource\n");
+		ret = -ENOENT;
+		goto bail_out;
+	}
+
+	res = devm_request_mem_region(dev, res->start, resource_size(res),
+					    dev_name(dev));
+	if (!res) {
+		dev_err(dev, "could not allocate register map resource\n");
+		ret = -ENXIO;
+		goto bail_out;
+	}
+
+	data->regs = devm_ioremap_nocache(dev, res->start, resource_size(res));
+	if (!data->regs) {
+		dev_err(dev, "could not map mdio registers\n");
+		ret = -ENOMEM;
+		goto bail_out;
+	}
+
+	mdio_in_freq = clk_get_rate(data->clk);
+	div = (mdio_in_freq / data->pdata.bus_freq) - 1;
+	if (div > CONTROL_MAX_DIV)
+		div = CONTROL_MAX_DIV;
+	mdio_out_freq = mdio_in_freq / (div + 1);
+
+	/* set enable and clock divider */
+	__raw_writel(div | CONTROL_ENABLE, &data->regs->control);
+
+	/*
+	 * wait for scan logic to settle:
+	 * the scan time consists of (a) a large fixed component, and (b) a
+	 * small component that varies with the mii bus frequency.  These
+	 * were estimated using measurements at 1.1 and 2.2 MHz on tnetv107x
+	 * silicon.  Since the effect of (b) was found to be largely
+	 * negligible, we keep things simple here.
+	 */
+	mdelay(1);
+
+	/* dump hardware version info */
+	ver = __raw_readl(&data->regs->version);
+	dev_info(dev, "davinci mdio revision %d.%d\n",
+			(ver >> 8) & 0xff, ver & 0xff);
+
+	/* get phy mask from the alive register */
+	phy_mask = __raw_readl(&data->regs->alive);
+	if (phy_mask) {
+		/* restrict mdio bus to live phys only */
+		dev_info(dev, "detected phy mask %x\n", ~phy_mask);
+		phy_mask = ~phy_mask;
+	} else {
+		/* desperately scan all phys */
+		dev_warn(dev, "failed to detect live phys, scanning all\n");
+		phy_mask = 0;
+	}
+	data->bus->phy_mask = phy_mask;
+
+	/* register the mii bus */
+	ret = mdiobus_register(data->bus);
+	if (ret)
+		goto bail_out;
+
+	/* scan and dump the bus */
+	for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
+		phy = data->bus->phy_map[addr];
+		if (phy) {
+			dev_info(dev, "phy[%d]: device %s, driver %s\n",
+				 phy->addr, dev_name(&phy->dev),
+				 phy->drv ? phy->drv->name : "unknown");
+		}
+	}
+
+	return 0;
+
+bail_out:
+	if (data->bus)
+		mdiobus_free(data->bus);
+
+	if (data->clk) {
+		clk_disable(data->clk);
+		clk_put(data->clk);
+	}
+
+	kfree(data);
+
+	return ret;
+}
+
+static int __devexit davinci_mdio_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct davinci_mdio_data *data = dev_get_drvdata(dev);
+
+	if (data->bus)
+		mdiobus_free(data->bus);
+
+	if (data->clk) {
+		clk_disable(data->clk);
+		clk_put(data->clk);
+	}
+
+	dev_set_drvdata(dev, NULL);
+
+	kfree(data);
+
+	return 0;
+}
+
+static int davinci_mdio_suspend(struct device *dev)
+{
+	struct davinci_mdio_data *data = dev_get_drvdata(dev);
+	u32 ctrl;
+
+	spin_lock(&data->lock);
+
+	/* shutdown the scan state machine */
+	ctrl = __raw_readl(&data->regs->control);
+	ctrl &= ~CONTROL_ENABLE;
+	__raw_writel(ctrl, &data->regs->control);
+	wait_for_idle(data);
+
+	if (data->clk)
+		clk_disable(data->clk);
+
+	data->suspended = true;
+	spin_unlock(&data->lock);
+
+	return 0;
+}
+
+static int davinci_mdio_resume(struct device *dev)
+{
+	struct davinci_mdio_data *data = dev_get_drvdata(dev);
+	u32 ctrl;
+
+	spin_lock(&data->lock);
+	if (data->clk)
+		clk_enable(data->clk);
+
+	/* restart the scan state machine */
+	ctrl = __raw_readl(&data->regs->control);
+	ctrl |= CONTROL_ENABLE;
+	__raw_writel(ctrl, &data->regs->control);
+
+	data->suspended = false;
+	spin_unlock(&data->lock);
+
+	return 0;
+}
+
+static const struct dev_pm_ops davinci_mdio_pm_ops = {
+	.suspend	= davinci_mdio_suspend,
+	.resume		= davinci_mdio_resume,
+};
+
+static struct platform_driver davinci_mdio_driver = {
+	.driver = {
+		.name	 = "davinci_mdio",
+		.owner	 = THIS_MODULE,
+		.pm	 = &davinci_mdio_pm_ops,
+	},
+	.probe = davinci_mdio_probe,
+	.remove = __devexit_p(davinci_mdio_remove),
+};
+
+static int __init davinci_mdio_init(void)
+{
+	return platform_driver_register(&davinci_mdio_driver);
+}
+device_initcall(davinci_mdio_init);
+
+static void __exit davinci_mdio_exit(void)
+{
+	platform_driver_unregister(&davinci_mdio_driver);
+}
+module_exit(davinci_mdio_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("DaVinci MDIO driver");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 7c930db..a04fd8c 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -14,6 +14,10 @@
 #include <linux/if_ether.h>
 #include <linux/memory.h>
 
+struct mdio_platform_data {
+	unsigned long		bus_freq;
+};
+
 struct emac_platform_data {
 	char mac_addr[ETH_ALEN];
 	u32 ctrl_reg_offset;
-- 
1.7.0.4


From cyril at ti.com  Tue Aug  3 08:31:47 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:47 -0400
Subject: [PATCH 2/8] davinci: add mdio platform devices
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <1280842313-3743-3-git-send-email-cyril@ti.com>

This patch adds mdio platform devices on SoCs that have the necessary
hardware.  Clock lookup entries (aliases) have also been added, so that the
MDIO and EMAC drivers can independently enable/disable a shared underlying
clock.  Further, the EMAC MMR region has been split down into separate MDIO
and EMAC regions.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/devices-da8xx.c       |   29 +++++++++++++++++++++++++-
 arch/arm/mach-davinci/dm365.c               |   22 +++++++++++++++++++-
 arch/arm/mach-davinci/dm644x.c              |   22 +++++++++++++++++++-
 arch/arm/mach-davinci/dm646x.c              |   22 +++++++++++++++++++-
 arch/arm/mach-davinci/include/mach/dm365.h  |    1 +
 arch/arm/mach-davinci/include/mach/dm644x.h |    1 +
 arch/arm/mach-davinci/include/mach/dm646x.h |    1 +
 7 files changed, 93 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 8cda729..c673e2a 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -341,7 +341,7 @@ int __init da8xx_register_watchdog(void)
 static struct resource da8xx_emac_resources[] = {
 	{
 		.start	= DA8XX_EMAC_CPPI_PORT_BASE,
-		.end	= DA8XX_EMAC_CPPI_PORT_BASE + 0x5000 - 1,
+		.end	= DA8XX_EMAC_CPPI_PORT_BASE + SZ_16K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
@@ -385,9 +385,34 @@ static struct platform_device da8xx_emac_device = {
 	.resource	= da8xx_emac_resources,
 };
 
+static struct resource da8xx_mdio_resources[] = {
+	{
+		.start	= DA8XX_EMAC_MDIO_BASE,
+		.end	= DA8XX_EMAC_MDIO_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device da8xx_mdio_device = {
+	.name		= "davinci_mdio",
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(da8xx_mdio_resources),
+	.resource	= da8xx_mdio_resources,
+};
+
 int __init da8xx_register_emac(void)
 {
-	return platform_device_register(&da8xx_emac_device);
+	int ret;
+
+	ret = platform_device_register(&da8xx_mdio_device);
+	if (ret < 0)
+		return ret;
+	ret = platform_device_register(&da8xx_emac_device);
+	if (ret < 0)
+		return ret;
+	ret = clk_add_alias(NULL, dev_name(&da8xx_mdio_device.dev),
+			    NULL, &da8xx_emac_device.dev);
+	return ret;
 }
 
 static struct resource da830_mcasp1_resources[] = {
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 652f4b6..4a58f03 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -699,7 +699,7 @@ static struct emac_platform_data dm365_emac_pdata = {
 static struct resource dm365_emac_resources[] = {
 	{
 		.start	= DM365_EMAC_BASE,
-		.end	= DM365_EMAC_BASE + 0x47ff,
+		.end	= DM365_EMAC_BASE + SZ_16K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
@@ -734,6 +734,21 @@ static struct platform_device dm365_emac_device = {
 	.resource	= dm365_emac_resources,
 };
 
+static struct resource dm365_mdio_resources[] = {
+	{
+		.start	= DM365_EMAC_MDIO_BASE,
+		.end	= DM365_EMAC_MDIO_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device dm365_mdio_device = {
+	.name		= "davinci_mdio",
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(dm365_mdio_resources),
+	.resource	= dm365_mdio_resources,
+};
+
 static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
 	[IRQ_VDINT0]			= 2,
 	[IRQ_VDINT1]			= 6,
@@ -1218,7 +1233,12 @@ static int __init dm365_init_devices(void)
 
 	davinci_cfg_reg(DM365_INT_EDMA_CC);
 	platform_device_register(&dm365_edma_device);
+
+	platform_device_register(&dm365_mdio_device);
 	platform_device_register(&dm365_emac_device);
+	clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
+		      NULL, &dm365_emac_device.dev);
+
 	/* Add isif clock alias */
 	clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
 	platform_device_register(&dm365_vpss_device);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 7ad1520..2673723 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -330,7 +330,7 @@ static struct emac_platform_data dm644x_emac_pdata = {
 static struct resource dm644x_emac_resources[] = {
 	{
 		.start	= DM644X_EMAC_BASE,
-		.end	= DM644X_EMAC_BASE + 0x47ff,
+		.end	= DM644X_EMAC_BASE + SZ_16K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
@@ -350,6 +350,21 @@ static struct platform_device dm644x_emac_device = {
        .resource	= dm644x_emac_resources,
 };
 
+static struct resource dm644x_mdio_resources[] = {
+	{
+		.start	= DM644X_EMAC_MDIO_BASE,
+		.end	= DM644X_EMAC_MDIO_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device dm644x_mdio_device = {
+       .name		= "davinci_mdio",
+       .id		= 0,
+       .num_resources	= ARRAY_SIZE(dm644x_mdio_resources),
+       .resource	= dm644x_mdio_resources,
+};
+
 /*
  * Device specific mux setup
  *
@@ -775,7 +790,12 @@ static int __init dm644x_init_devices(void)
 	clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL);
 	clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL);
 	platform_device_register(&dm644x_edma_device);
+
+	platform_device_register(&dm644x_mdio_device);
 	platform_device_register(&dm644x_emac_device);
+	clk_add_alias(NULL, dev_name(&dm644x_mdio_device.dev),
+		      NULL, &dm644x_emac_device.dev);
+
 	platform_device_register(&dm644x_vpss_device);
 	platform_device_register(&dm644x_ccdc_dev);
 	platform_device_register(&vpfe_capture_dev);
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 9404565..4e90511 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -366,7 +366,7 @@ static struct emac_platform_data dm646x_emac_pdata = {
 static struct resource dm646x_emac_resources[] = {
 	{
 		.start	= DM646X_EMAC_BASE,
-		.end	= DM646X_EMAC_BASE + 0x47ff,
+		.end	= DM646X_EMAC_BASE + SZ_16K - 1,
 		.flags	= IORESOURCE_MEM,
 	},
 	{
@@ -401,6 +401,21 @@ static struct platform_device dm646x_emac_device = {
 	.resource	= dm646x_emac_resources,
 };
 
+static struct resource dm646x_mdio_resources[] = {
+	{
+		.start	= DM646X_EMAC_MDIO_BASE,
+		.end	= DM646X_EMAC_MDIO_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device dm646x_mdio_device = {
+	.name		= "davinci_mdio",
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(dm646x_mdio_resources),
+	.resource	= dm646x_mdio_resources,
+};
+
 /*
  * Device specific mux setup
  *
@@ -889,7 +904,12 @@ static int __init dm646x_init_devices(void)
 		return 0;
 
 	platform_device_register(&dm646x_edma_device);
+
+	platform_device_register(&dm646x_mdio_device);
 	platform_device_register(&dm646x_emac_device);
+	clk_add_alias(NULL, dev_name(&dm646x_mdio_device.dev),
+		      NULL, &dm646x_emac_device.dev);
+
 	return 0;
 }
 postcore_initcall(dm646x_init_devices);
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index ea5df3b..dbb5052 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -21,6 +21,7 @@
 #include <media/davinci/vpfe_capture.h>
 
 #define DM365_EMAC_BASE			(0x01D07000)
+#define DM365_EMAC_MDIO_BASE		(DM365_EMAC_BASE + 0x4000)
 #define DM365_EMAC_CNTRL_OFFSET		(0x0000)
 #define DM365_EMAC_CNTRL_MOD_OFFSET	(0x3000)
 #define DM365_EMAC_CNTRL_RAM_OFFSET	(0x1000)
diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h
index 6fca568..5159117 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -28,6 +28,7 @@
 #include <media/davinci/vpfe_capture.h>
 
 #define DM644X_EMAC_BASE		(0x01C80000)
+#define DM644X_EMAC_MDIO_BASE		(DM644X_EMAC_BASE + 0x4000)
 #define DM644X_EMAC_CNTRL_OFFSET	(0x0000)
 #define DM644X_EMAC_CNTRL_MOD_OFFSET	(0x1000)
 #define DM644X_EMAC_CNTRL_RAM_OFFSET	(0x2000)
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h
index add6f79..fc2bdd0 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -19,6 +19,7 @@
 #include <linux/davinci_emac.h>
 
 #define DM646X_EMAC_BASE		(0x01C80000)
+#define DM646X_EMAC_MDIO_BASE		(DM646X_EMAC_BASE + 0x4000)
 #define DM646X_EMAC_CNTRL_OFFSET	(0x0000)
 #define DM646X_EMAC_CNTRL_MOD_OFFSET	(0x1000)
 #define DM646X_EMAC_CNTRL_RAM_OFFSET	(0x2000)
-- 
1.7.0.4


From cyril at ti.com  Tue Aug  3 08:31:48 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:48 -0400
Subject: [PATCH 3/8] netdev: switch davinci emac to new mdio driver
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <1280842313-3743-4-git-send-email-cyril@ti.com>

This patch switches the emac implementation over to the newly separated
MDIO driver.

With this, the mdio bus frequency defaults to a safe 2.2MHz.  Boards may
optionally specify a bus frequency via platform data.

The phy identification scheme has been modified to use a phy bus id instead
of a mask.  This largely serves to eliminate the "phy search" code in emac
init.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 drivers/net/Kconfig          |    1 +
 drivers/net/davinci_emac.c   |   89 ++++++++++++++---------------------------
 include/linux/davinci_emac.h |    1 +
 3 files changed, 33 insertions(+), 58 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index fe6658a..3c324c2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -940,6 +940,7 @@ config NET_NETX
 config TI_DAVINCI_EMAC
 	tristate "TI DaVinci EMAC Support"
 	depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
+	select TI_DAVINCI_MDIO
 	select PHYLIB
 	help
 	  This driver supports TI's DaVinci Ethernet .
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 08e82b1..8e21a42 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -482,6 +482,7 @@ struct emac_priv {
 	u32 phy_mask;
 	/* mii_bus,phy members */
 	struct mii_bus *mii_bus;
+	const char *phy_id;
 	struct phy_device *phydev;
 	spinlock_t lock;
 	/*platform specific members*/
@@ -666,7 +667,7 @@ static int emac_get_settings(struct net_device *ndev,
 			     struct ethtool_cmd *ecmd)
 {
 	struct emac_priv *priv = netdev_priv(ndev);
-	if (priv->phy_mask)
+	if (priv->phydev)
 		return phy_ethtool_gset(priv->phydev, ecmd);
 	else
 		return -EOPNOTSUPP;
@@ -684,7 +685,7 @@ static int emac_get_settings(struct net_device *ndev,
 static int emac_set_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
 {
 	struct emac_priv *priv = netdev_priv(ndev);
-	if (priv->phy_mask)
+	if (priv->phydev)
 		return phy_ethtool_sset(priv->phydev, ecmd);
 	else
 		return -EOPNOTSUPP;
@@ -722,7 +723,7 @@ static void emac_update_phystatus(struct emac_priv *priv)
 	mac_control = emac_read(EMAC_MACCONTROL);
 	cur_duplex = (mac_control & EMAC_MACCONTROL_FULLDUPLEXEN) ?
 			DUPLEX_FULL : DUPLEX_HALF;
-	if (priv->phy_mask)
+	if (priv->phydev)
 		new_duplex = priv->phydev->duplex;
 	else
 		new_duplex = DUPLEX_FULL;
@@ -2370,6 +2371,11 @@ static int emac_devioctl(struct net_device *ndev, struct ifreq *ifrq, int cmd)
 	return -EOPNOTSUPP;
 }
 
+static int match_first_device(struct device *dev, void *data)
+{
+	return 1;
+}
+
 /**
  * emac_dev_open: EMAC device open
  * @ndev: The DaVinci EMAC network adapter
@@ -2384,7 +2390,6 @@ static int emac_dev_open(struct net_device *ndev)
 {
 	struct device *emac_dev = &ndev->dev;
 	u32 rc, cnt, ch;
-	int phy_addr;
 	struct resource *res;
 	int q, m;
 	int i = 0;
@@ -2437,28 +2442,27 @@ static int emac_dev_open(struct net_device *ndev)
 	/* Start/Enable EMAC hardware */
 	emac_hw_enable(priv);
 
-	/* find the first phy */
 	priv->phydev = NULL;
-	if (priv->phy_mask) {
-		emac_mii_reset(priv->mii_bus);
-		for (phy_addr = 0; phy_addr < PHY_MAX_ADDR; phy_addr++) {
-			if (priv->mii_bus->phy_map[phy_addr]) {
-				priv->phydev = priv->mii_bus->phy_map[phy_addr];
-				break;
-			}
-		}
 
-		if (!priv->phydev) {
-			printk(KERN_ERR "%s: no PHY found\n", ndev->name);
-			return -1;
-		}
+	/* use the first phy on the bus if pdata did not give us a phy id */
+	if (!priv->phy_id) {
+		struct device *phy;
+
+		phy = bus_find_device(&mdio_bus_type, NULL, NULL,
+				      match_first_device);
+		if (phy)
+			priv->phy_id = dev_name(phy);
+	}
 
-		priv->phydev = phy_connect(ndev, dev_name(&priv->phydev->dev),
-				&emac_adjust_link, 0, PHY_INTERFACE_MODE_MII);
+	if (priv->phy_id) {
+		priv->phydev = phy_connect(ndev, priv->phy_id,
+					   &emac_adjust_link, 0,
+					   PHY_INTERFACE_MODE_MII);
 
 		if (IS_ERR(priv->phydev)) {
-			printk(KERN_ERR "%s: Could not attach to PHY\n",
-								ndev->name);
+			dev_err(emac_dev, "could not connect to phy %s\n",
+				priv->phy_id);
+			priv->phydev = NULL;
 			return PTR_ERR(priv->phydev);
 		}
 
@@ -2466,12 +2470,13 @@ static int emac_dev_open(struct net_device *ndev)
 		priv->speed = 0;
 		priv->duplex = ~0;
 
-		printk(KERN_INFO "%s: attached PHY driver [%s] "
-			"(mii_bus:phy_addr=%s, id=%x)\n", ndev->name,
+		dev_info(emac_dev, "attached PHY driver [%s] "
+			"(mii_bus:phy_addr=%s, id=%x)\n",
 			priv->phydev->drv->name, dev_name(&priv->phydev->dev),
 			priv->phydev->phy_id);
-	} else{
+	} else {
 		/* No PHY , fix the link, speed and duplex settings */
+		dev_notice(emac_dev, "no phy, defaulting to 100/full\n");
 		priv->link = 1;
 		priv->speed = SPEED_100;
 		priv->duplex = DUPLEX_FULL;
@@ -2484,7 +2489,7 @@ static int emac_dev_open(struct net_device *ndev)
 	if (netif_msg_drv(priv))
 		dev_notice(emac_dev, "DaVinci EMAC: Opened %s\n", ndev->name);
 
-	if (priv->phy_mask)
+	if (priv->phydev)
 		phy_start(priv->phydev);
 
 	return 0;
@@ -2671,7 +2676,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 
 	/* MAC addr and PHY mask , RMII enable info from platform_data */
 	memcpy(priv->mac_addr, pdata->mac_addr, 6);
-	priv->phy_mask = pdata->phy_mask;
+	priv->phy_id = pdata->phy_id;
 	priv->rmii_en = pdata->rmii_en;
 	priv->version = pdata->version;
 	priv->int_enable = pdata->interrupt_enable;
@@ -2745,32 +2750,6 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 	}
 
 
-	/* MII/Phy intialisation, mdio bus registration */
-	emac_mii = mdiobus_alloc();
-	if (emac_mii == NULL) {
-		dev_err(emac_dev, "DaVinci EMAC: Error allocating mii_bus\n");
-		rc = -ENOMEM;
-		goto mdio_alloc_err;
-	}
-
-	priv->mii_bus = emac_mii;
-	emac_mii->name  = "emac-mii",
-	emac_mii->read  = emac_mii_read,
-	emac_mii->write = emac_mii_write,
-	emac_mii->reset = emac_mii_reset,
-	emac_mii->irq   = mii_irqs,
-	emac_mii->phy_mask = ~(priv->phy_mask);
-	emac_mii->parent = &pdev->dev;
-	emac_mii->priv = priv->remap_addr + pdata->mdio_reg_offset;
-	snprintf(priv->mii_bus->id, MII_BUS_ID_SIZE, "%x", priv->pdev->id);
-	mdio_max_freq = pdata->mdio_max_freq;
-	emac_mii->reset(emac_mii);
-
-	/* Register the MII bus */
-	rc = mdiobus_register(emac_mii);
-	if (rc)
-		goto mdiobus_quit;
-
 	if (netif_msg_probe(priv)) {
 		dev_notice(emac_dev, "DaVinci EMAC Probe found device "\
 			   "(regs: %p, irq: %d)\n",
@@ -2778,11 +2757,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 	}
 	return 0;
 
-mdiobus_quit:
-	mdiobus_free(emac_mii);
-
 netdev_reg_err:
-mdio_alloc_err:
 	clk_disable(emac_clk);
 no_irq_res:
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2812,8 +2787,6 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, NULL);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	mdiobus_unregister(priv->mii_bus);
-	mdiobus_free(priv->mii_bus);
 
 	release_mem_region(res->start, res->end - res->start + 1);
 
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index a04fd8c..6bcd247 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -28,6 +28,7 @@ struct emac_platform_data {
 	u32 ctrl_ram_size;
 	u32 phy_mask;
 	u32 mdio_max_freq;
+	const char *phy_id;
 	u8 rmii_en;
 	u8 version;
 	void (*interrupt_enable) (void);
-- 
1.7.0.4


From cyril at ti.com  Tue Aug  3 08:31:49 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:49 -0400
Subject: [PATCH 4/8] davinci: cleanup unused davinci mdio arch code
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <1280842313-3743-5-git-send-email-cyril@ti.com>

This patch removes davinci architecture code that has now been rendered
useless by the previous patches in the MDIO separation series.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/board-da830-evm.c     |    5 -----
 arch/arm/mach-davinci/board-da850-evm.c     |    6 ------
 arch/arm/mach-davinci/board-dm365-evm.c     |    7 -------
 arch/arm/mach-davinci/board-dm644x-evm.c    |    7 -------
 arch/arm/mach-davinci/board-dm646x-evm.c    |    8 --------
 arch/arm/mach-davinci/board-neuros-osd2.c   |    7 -------
 arch/arm/mach-davinci/board-sffsdr.c        |    7 -------
 arch/arm/mach-davinci/devices-da8xx.c       |    2 --
 arch/arm/mach-davinci/dm365.c               |    1 -
 arch/arm/mach-davinci/dm644x.c              |    1 -
 arch/arm/mach-davinci/dm646x.c              |    1 -
 arch/arm/mach-davinci/include/mach/dm365.h  |    1 -
 arch/arm/mach-davinci/include/mach/dm644x.h |    1 -
 arch/arm/mach-davinci/include/mach/dm646x.h |    1 -
 14 files changed, 0 insertions(+), 55 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 212d970..76e9a9b 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -30,9 +30,6 @@
 #include <mach/da8xx.h>
 #include <mach/usb.h>
 
-#define DA830_EVM_PHY_MASK		0x0
-#define DA830_EVM_MDIO_FREQUENCY	2200000	/* PHY bus frequency */
-
 /*
  * USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4].
  */
@@ -516,8 +513,6 @@ static __init void da830_evm_init(void)
 
 	da830_evm_usb_init();
 
-	soc_info->emac_pdata->phy_mask = DA830_EVM_PHY_MASK;
-	soc_info->emac_pdata->mdio_max_freq = DA830_EVM_MDIO_FREQUENCY;
 	soc_info->emac_pdata->rmii_en = 1;
 
 	ret = davinci_cfg_reg_list(da830_cpgmac_pins);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 2ec3095..c6e39cc 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -36,9 +36,6 @@
 #include <mach/nand.h>
 #include <mach/mux.h>
 
-#define DA850_EVM_PHY_MASK		0x1
-#define DA850_EVM_MDIO_FREQUENCY	2200000 /* PHY bus frequency */
-
 #define DA850_LCD_PWR_PIN		GPIO_TO_PIN(2, 8)
 #define DA850_LCD_BL_PIN		GPIO_TO_PIN(2, 15)
 
@@ -617,9 +614,6 @@ static int __init da850_evm_config_emac(void)
 	/* Enable/Disable MII MDIO clock */
 	gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, rmii_en);
 
-	soc_info->emac_pdata->phy_mask = DA850_EVM_PHY_MASK;
-	soc_info->emac_pdata->mdio_max_freq = DA850_EVM_MDIO_FREQUENCY;
-
 	ret = da8xx_register_emac();
 	if (ret)
 		pr_warning("da850_evm_init: emac registration failed: %d\n",
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 5bb86b2..e89263e 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -54,9 +54,6 @@ static inline int have_tvp7002(void)
 	return 0;
 }
 
-#define DM365_EVM_PHY_MASK		(0x2)
-#define DM365_EVM_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
-
 /*
  * A MAX-II CPLD is used for various board control functions.
  */
@@ -528,16 +525,12 @@ fail:
 		/* externally mux MMC1/ENET/AIC33 to imager */
 		mux |= BIT(6) | BIT(5) | BIT(3);
 	} else {
-		struct davinci_soc_info *soc_info = &davinci_soc_info;
-
 		/* we can use MMC1 ... */
 		dm365evm_mmc_configure();
 		davinci_setup_mmc(1, &dm365evm_mmc_config);
 
 		/* ... and ENET ... */
 		dm365evm_emac_configure();
-		soc_info->emac_pdata->phy_mask = DM365_EVM_PHY_MASK;
-		soc_info->emac_pdata->mdio_max_freq = DM365_EVM_MDIO_FREQUENCY;
 		resets &= ~BIT(3);
 
 		/* ... and AIC33 */
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 34c8b41..9e8193e 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -38,9 +38,6 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 
-#define DM644X_EVM_PHY_MASK		(0x2)
-#define DM644X_EVM_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
-
 #define LXT971_PHY_ID	(0x001378e2)
 #define LXT971_PHY_MASK	(0xfffffff0)
 
@@ -660,7 +657,6 @@ static int davinci_phy_fixup(struct phy_device *phydev)
 static __init void davinci_evm_init(void)
 {
 	struct clk *aemif_clk;
-	struct davinci_soc_info *soc_info = &davinci_soc_info;
 
 	aemif_clk = clk_get(NULL, "aemif");
 	clk_enable(aemif_clk);
@@ -695,9 +691,6 @@ static __init void davinci_evm_init(void)
 	davinci_serial_init(&uart_config);
 	dm644x_init_asp(&dm644x_evm_snd_data);
 
-	soc_info->emac_pdata->phy_mask = DM644X_EVM_PHY_MASK;
-	soc_info->emac_pdata->mdio_max_freq = DM644X_EVM_MDIO_FREQUENCY;
-
 	/* Register the fixup for PHY on DaVinci */
 	phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,
 					davinci_phy_fixup);
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 6d88893..a3ce716 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -718,13 +718,8 @@ static struct davinci_uart_config uart_config __initdata = {
 	.enabled_uarts = (1 << 0),
 };
 
-#define DM646X_EVM_PHY_MASK		(0x2)
-#define DM646X_EVM_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
-
 static __init void evm_init(void)
 {
-	struct davinci_soc_info *soc_info = &davinci_soc_info;
-
 	evm_init_i2c();
 	davinci_serial_init(&uart_config);
 	dm646x_init_mcasp0(&dm646x_evm_snd_data[0]);
@@ -734,9 +729,6 @@ static __init void evm_init(void)
 
 	if (HAS_ATA)
 		davinci_init_ide();
-
-	soc_info->emac_pdata->phy_mask = DM646X_EVM_PHY_MASK;
-	soc_info->emac_pdata->mdio_max_freq = DM646X_EVM_MDIO_FREQUENCY;
 }
 
 #define DM646X_EVM_REF_FREQ		27000000
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 4c30e92..4b32f0a 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -39,9 +39,6 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 
-#define NEUROS_OSD2_PHY_MASK		0x2
-#define NEUROS_OSD2_MDIO_FREQUENCY	2200000 /* PHY bus frequency */
-
 #define LXT971_PHY_ID			0x001378e2
 #define LXT971_PHY_MASK			0xfffffff0
 
@@ -218,7 +215,6 @@ static struct davinci_mmc_config davinci_ntosd2_mmc_config = {
 static __init void davinci_ntosd2_init(void)
 {
 	struct clk *aemif_clk;
-	struct davinci_soc_info *soc_info = &davinci_soc_info;
 	int	status;
 
 	aemif_clk = clk_get(NULL, "aemif");
@@ -252,9 +248,6 @@ static __init void davinci_ntosd2_init(void)
 	davinci_serial_init(&uart_config);
 	dm644x_init_asp(&dm644x_ntosd2_snd_data);
 
-	soc_info->emac_pdata->phy_mask = NEUROS_OSD2_PHY_MASK;
-	soc_info->emac_pdata->mdio_max_freq = NEUROS_OSD2_MDIO_FREQUENCY;
-
 	davinci_setup_usb(1000, 8);
 	/*
 	 * Mux the pins to be GPIOs, VLYNQEN is already done at startup.
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index 23e664a..b372d7f 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -42,9 +42,6 @@
 #include <mach/mux.h>
 #include <mach/usb.h>
 
-#define SFFSDR_PHY_MASK		(0x2)
-#define SFFSDR_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
-
 static struct mtd_partition davinci_sffsdr_nandflash_partition[] = {
 	/* U-Boot Environment: Block 0
 	 * UBL:                Block 1
@@ -137,14 +134,10 @@ static void __init davinci_sffsdr_map_io(void)
 
 static __init void davinci_sffsdr_init(void)
 {
-	struct davinci_soc_info *soc_info = &davinci_soc_info;
-
 	platform_add_devices(davinci_sffsdr_devices,
 			     ARRAY_SIZE(davinci_sffsdr_devices));
 	sffsdr_init_i2c();
 	davinci_serial_init(&uart_config);
-	soc_info->emac_pdata->phy_mask = SFFSDR_PHY_MASK;
-	soc_info->emac_pdata->mdio_max_freq = SFFSDR_MDIO_FREQUENCY;
 	davinci_setup_usb(0, 0); /* We support only peripheral mode. */
 
 	/* mux VLYNQ pins */
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index c673e2a..b905e5c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -41,7 +41,6 @@
 #define DA8XX_EMAC_CTRL_REG_OFFSET	0x3000
 #define DA8XX_EMAC_MOD_REG_OFFSET	0x2000
 #define DA8XX_EMAC_RAM_OFFSET		0x0000
-#define DA8XX_MDIO_REG_OFFSET		0x4000
 #define DA8XX_EMAC_CTRL_RAM_SIZE	SZ_8K
 
 void __iomem *da8xx_syscfg0_base;
@@ -370,7 +369,6 @@ struct emac_platform_data da8xx_emac_pdata = {
 	.ctrl_reg_offset	= DA8XX_EMAC_CTRL_REG_OFFSET,
 	.ctrl_mod_reg_offset	= DA8XX_EMAC_MOD_REG_OFFSET,
 	.ctrl_ram_offset	= DA8XX_EMAC_RAM_OFFSET,
-	.mdio_reg_offset	= DA8XX_MDIO_REG_OFFSET,
 	.ctrl_ram_size		= DA8XX_EMAC_CTRL_RAM_SIZE,
 	.version		= EMAC_VERSION_2,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4a58f03..7b69790 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -691,7 +691,6 @@ static struct emac_platform_data dm365_emac_pdata = {
 	.ctrl_reg_offset	= DM365_EMAC_CNTRL_OFFSET,
 	.ctrl_mod_reg_offset	= DM365_EMAC_CNTRL_MOD_OFFSET,
 	.ctrl_ram_offset	= DM365_EMAC_CNTRL_RAM_OFFSET,
-	.mdio_reg_offset	= DM365_EMAC_MDIO_OFFSET,
 	.ctrl_ram_size		= DM365_EMAC_CNTRL_RAM_SIZE,
 	.version		= EMAC_VERSION_2,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2673723..6de35ef 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -322,7 +322,6 @@ static struct emac_platform_data dm644x_emac_pdata = {
 	.ctrl_reg_offset	= DM644X_EMAC_CNTRL_OFFSET,
 	.ctrl_mod_reg_offset	= DM644X_EMAC_CNTRL_MOD_OFFSET,
 	.ctrl_ram_offset	= DM644X_EMAC_CNTRL_RAM_OFFSET,
-	.mdio_reg_offset	= DM644X_EMAC_MDIO_OFFSET,
 	.ctrl_ram_size		= DM644X_EMAC_CNTRL_RAM_SIZE,
 	.version		= EMAC_VERSION_1,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 4e90511..f8ba8f4 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -358,7 +358,6 @@ static struct emac_platform_data dm646x_emac_pdata = {
 	.ctrl_reg_offset	= DM646X_EMAC_CNTRL_OFFSET,
 	.ctrl_mod_reg_offset	= DM646X_EMAC_CNTRL_MOD_OFFSET,
 	.ctrl_ram_offset	= DM646X_EMAC_CNTRL_RAM_OFFSET,
-	.mdio_reg_offset	= DM646X_EMAC_MDIO_OFFSET,
 	.ctrl_ram_size		= DM646X_EMAC_CNTRL_RAM_SIZE,
 	.version		= EMAC_VERSION_2,
 };
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index dbb5052..2563bf4 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -25,7 +25,6 @@
 #define DM365_EMAC_CNTRL_OFFSET		(0x0000)
 #define DM365_EMAC_CNTRL_MOD_OFFSET	(0x3000)
 #define DM365_EMAC_CNTRL_RAM_OFFSET	(0x1000)
-#define DM365_EMAC_MDIO_OFFSET		(0x4000)
 #define DM365_EMAC_CNTRL_RAM_SIZE	(0x2000)
 
 /* Base of key scan register bank */
diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h
index 5159117..5a1b26d 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -32,7 +32,6 @@
 #define DM644X_EMAC_CNTRL_OFFSET	(0x0000)
 #define DM644X_EMAC_CNTRL_MOD_OFFSET	(0x1000)
 #define DM644X_EMAC_CNTRL_RAM_OFFSET	(0x2000)
-#define DM644X_EMAC_MDIO_OFFSET		(0x4000)
 #define DM644X_EMAC_CNTRL_RAM_SIZE	(0x2000)
 
 #define DM644X_ASYNC_EMIF_CONTROL_BASE	0x01E00000
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h
index fc2bdd0..38e54c6 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -23,7 +23,6 @@
 #define DM646X_EMAC_CNTRL_OFFSET	(0x0000)
 #define DM646X_EMAC_CNTRL_MOD_OFFSET	(0x1000)
 #define DM646X_EMAC_CNTRL_RAM_OFFSET	(0x2000)
-#define DM646X_EMAC_MDIO_OFFSET		(0x4000)
 #define DM646X_EMAC_CNTRL_RAM_SIZE	(0x2000)
 
 #define DM646X_ASYNC_EMIF_CONTROL_BASE	0x20008000
-- 
1.7.0.4


From cyril at ti.com  Tue Aug  3 08:31:50 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:50 -0400
Subject: [PATCH 5/8] netdev: cleanup unused davinci mdio emac code
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <1280842313-3743-6-git-send-email-cyril@ti.com>

This patch removes code that has been rendered useless by the previous patches
in this series.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 drivers/net/davinci_emac.c   |  107 ------------------------------------------
 include/linux/davinci_emac.h |    3 -
 2 files changed, 0 insertions(+), 110 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 8e21a42..33dc8b5 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -113,7 +113,6 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
 #define EMAC_DEF_MAX_FRAME_SIZE		(1500 + 14 + 4 + 4)
 #define EMAC_DEF_TX_CH			(0) /* Default 0th channel */
 #define EMAC_DEF_RX_CH			(0) /* Default 0th channel */
-#define EMAC_DEF_MDIO_TICK_MS		(10) /* typically 1 tick=1 ms) */
 #define EMAC_DEF_MAX_TX_CH		(1) /* Max TX channels configured */
 #define EMAC_DEF_MAX_RX_CH		(1) /* Max RX channels configured */
 #define EMAC_POLL_WEIGHT		(64) /* Default NAPI poll weight */
@@ -298,25 +297,6 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
 #define EMAC_CTRL_EWCTL		(0x4)
 #define EMAC_CTRL_EWINTTCNT	(0x8)
 
-/* EMAC MDIO related */
-/* Mask & Control defines */
-#define MDIO_CONTROL_CLKDIV	(0xFF)
-#define MDIO_CONTROL_ENABLE	BIT(30)
-#define MDIO_USERACCESS_GO	BIT(31)
-#define MDIO_USERACCESS_WRITE	BIT(30)
-#define MDIO_USERACCESS_READ	(0)
-#define MDIO_USERACCESS_REGADR	(0x1F << 21)
-#define MDIO_USERACCESS_PHYADR	(0x1F << 16)
-#define MDIO_USERACCESS_DATA	(0xFFFF)
-#define MDIO_USERPHYSEL_LINKSEL	BIT(7)
-#define MDIO_VER_MODID		(0xFFFF << 16)
-#define MDIO_VER_REVMAJ		(0xFF   << 8)
-#define MDIO_VER_REVMIN		(0xFF)
-
-#define MDIO_USERACCESS(inst)	(0x80 + (inst * 8))
-#define MDIO_USERPHYSEL(inst)	(0x84 + (inst * 8))
-#define MDIO_CONTROL		(0x04)
-
 /* EMAC DM646X control module registers */
 #define EMAC_DM646X_CMRXINTEN	(0x14)
 #define EMAC_DM646X_CMTXINTEN	(0x18)
@@ -475,13 +455,6 @@ struct emac_priv {
 	u32 mac_hash2;
 	u32 multicast_hash_cnt[EMAC_NUM_MULTICAST_BITS];
 	u32 rx_addr_type;
-	/* periodic timer required for MDIO polling */
-	struct timer_list periodic_timer;
-	u32 periodic_ticks;
-	u32 timer_active;
-	u32 phy_mask;
-	/* mii_bus,phy members */
-	struct mii_bus *mii_bus;
 	const char *phy_id;
 	struct phy_device *phydev;
 	spinlock_t lock;
@@ -493,7 +466,6 @@ struct emac_priv {
 /* clock frequency for EMAC */
 static struct clk *emac_clk;
 static unsigned long emac_bus_frequency;
-static unsigned long mdio_max_freq;
 
 #define emac_virt_to_phys(addr, priv) \
 	(((u32 __force)(addr) - (u32 __force)(priv->emac_ctrl_ram)) \
@@ -531,9 +503,6 @@ static char *emac_rxhost_errcodes[16] = {
 #define emac_ctrl_read(reg)	  ioread32((priv->ctrl_base + (reg)))
 #define emac_ctrl_write(reg, val) iowrite32(val, (priv->ctrl_base + (reg)))
 
-#define emac_mdio_read(reg)	  ioread32(bus->priv + (reg))
-#define emac_mdio_write(reg, val) iowrite32(val, (bus->priv + (reg)))
-
 /**
  * emac_dump_regs: Dump important EMAC registers to debug terminal
  * @priv: The DaVinci EMAC private adapter structure
@@ -637,9 +606,6 @@ static void emac_dump_regs(struct emac_priv *priv)
 		emac_read(EMAC_RXDMAOVERRUNS));
 }
 
-/*************************************************************************
- *  EMAC MDIO/Phy Functionality
- *************************************************************************/
 /**
  * emac_get_drvinfo: Get EMAC driver information
  * @ndev: The DaVinci EMAC network adapter
@@ -2234,79 +2200,6 @@ void emac_poll_controller(struct net_device *ndev)
 }
 #endif
 
-/* PHY/MII bus related */
-
-/* Wait until mdio is ready for next command */
-#define MDIO_WAIT_FOR_USER_ACCESS\
-		while ((emac_mdio_read((MDIO_USERACCESS(0))) &\
-			MDIO_USERACCESS_GO) != 0)
-
-static int emac_mii_read(struct mii_bus *bus, int phy_id, int phy_reg)
-{
-	unsigned int phy_data = 0;
-	unsigned int phy_control;
-
-	/* Wait until mdio is ready for next command */
-	MDIO_WAIT_FOR_USER_ACCESS;
-
-	phy_control = (MDIO_USERACCESS_GO |
-		       MDIO_USERACCESS_READ |
-		       ((phy_reg << 21) & MDIO_USERACCESS_REGADR) |
-		       ((phy_id << 16) & MDIO_USERACCESS_PHYADR) |
-		       (phy_data & MDIO_USERACCESS_DATA));
-	emac_mdio_write(MDIO_USERACCESS(0), phy_control);
-
-	/* Wait until mdio is ready for next command */
-	MDIO_WAIT_FOR_USER_ACCESS;
-
-	return emac_mdio_read(MDIO_USERACCESS(0)) & MDIO_USERACCESS_DATA;
-
-}
-
-static int emac_mii_write(struct mii_bus *bus, int phy_id,
-			  int phy_reg, u16 phy_data)
-{
-
-	unsigned int control;
-
-	/*  until mdio is ready for next command */
-	MDIO_WAIT_FOR_USER_ACCESS;
-
-	control = (MDIO_USERACCESS_GO |
-		   MDIO_USERACCESS_WRITE |
-		   ((phy_reg << 21) & MDIO_USERACCESS_REGADR) |
-		   ((phy_id << 16) & MDIO_USERACCESS_PHYADR) |
-		   (phy_data & MDIO_USERACCESS_DATA));
-	emac_mdio_write(MDIO_USERACCESS(0), control);
-
-	return 0;
-}
-
-static int emac_mii_reset(struct mii_bus *bus)
-{
-	unsigned int clk_div;
-	int mdio_bus_freq = emac_bus_frequency;
-
-	if (mdio_max_freq && mdio_bus_freq)
-		clk_div = ((mdio_bus_freq / mdio_max_freq) - 1);
-	else
-		clk_div = 0xFF;
-
-	clk_div &= MDIO_CONTROL_CLKDIV;
-
-	/* Set enable and clock divider in MDIOControl */
-	emac_mdio_write(MDIO_CONTROL, (clk_div | MDIO_CONTROL_ENABLE));
-
-	return 0;
-
-}
-
-static int mii_irqs[PHY_MAX_ADDR] = { PHY_POLL, PHY_POLL };
-
-/* emac_driver: EMAC MII bus structure */
-
-static struct mii_bus *emac_mii;
-
 static void emac_adjust_link(struct net_device *ndev)
 {
 	struct emac_priv *priv = netdev_priv(ndev);
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 6bcd247..7508e49 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -24,10 +24,7 @@ struct emac_platform_data {
 	u32 ctrl_mod_reg_offset;
 	u32 ctrl_ram_offset;
 	u32 hw_ram_addr;
-	u32 mdio_reg_offset;
 	u32 ctrl_ram_size;
-	u32 phy_mask;
-	u32 mdio_max_freq;
 	const char *phy_id;
 	u8 rmii_en;
 	u8 version;
-- 
1.7.0.4


From cyril at ti.com  Tue Aug  3 08:31:52 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:52 -0400
Subject: [PATCH 7/8] netdev: switch davinci emac to new cpdma layer
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <1280842313-3743-8-git-send-email-cyril@ti.com>

This patch hooks up the emac driver with the newly separated cpdma driver.

Key differences introduced here:

 - The old buffer list scheme is no longer required

 - The original code maintained mac address per rx channel, even if only one
   rx channel was being used.  With this change, mac address is maintained
   device wide.  If support for multiple rx channels is added in future, this
   will need to be reworked a bit.

 - The new CPDMA code handles short packets better than before.  The
   earlier code was adjusting the length up, without ensuring that the tail
   end of the padding was cleared - a possible security issue.  This has been
   fixed to use skb_padto().

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 drivers/net/davinci_emac.c |  238 ++++++++++++++++++++++++++++----------------
 1 files changed, 150 insertions(+), 88 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 33dc8b5..3efa42d 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -63,6 +63,8 @@
 #include <asm/irq.h>
 #include <asm/page.h>
 
+#include "davinci_cpdma.h"
+
 static int debug_level;
 module_param(debug_level, int, 0);
 MODULE_PARM_DESC(debug_level, "DaVinci EMAC debug level (NETIF_MSG bits)");
@@ -113,6 +115,7 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
 #define EMAC_DEF_MAX_FRAME_SIZE		(1500 + 14 + 4 + 4)
 #define EMAC_DEF_TX_CH			(0) /* Default 0th channel */
 #define EMAC_DEF_RX_CH			(0) /* Default 0th channel */
+#define EMAC_DEF_RX_NUM_DESC		(128)
 #define EMAC_DEF_MAX_TX_CH		(1) /* Max TX channels configured */
 #define EMAC_DEF_MAX_RX_CH		(1) /* Max RX channels configured */
 #define EMAC_POLL_WEIGHT		(64) /* Default NAPI poll weight */
@@ -443,6 +446,9 @@ struct emac_priv {
 	u32 hw_ram_addr;
 	struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
 	struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
+	struct cpdma_ctlr *dma;
+	struct cpdma_chan *txchan;
+	struct cpdma_chan *rxchan;
 	u32 link; /* 1=link on, 0=link off */
 	u32 speed; /* 0=Auto Neg, 1=No PHY, 10,100, 1000 - mbps */
 	u32 duplex; /* Link duplex: 0=Half, 1=Full */
@@ -1032,6 +1038,58 @@ static irqreturn_t emac_irq(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static struct sk_buff *emac_rx_alloc(struct emac_priv *priv)
+{
+	struct sk_buff *skb = dev_alloc_skb(priv->rx_buf_size);
+	if (WARN_ON(!skb))
+		return NULL;
+	skb->dev = priv->ndev;
+	skb_reserve(skb, NET_IP_ALIGN);
+	return skb;
+}
+
+static void emac_rx_handler(void *token, int len, int status)
+{
+	struct sk_buff		*skb = token;
+	struct net_device	*ndev = skb->dev;
+	struct emac_priv	*priv = netdev_priv(ndev);
+	int			ret;
+
+	if (status < 0) {
+		/* error */
+		goto recycle;
+	}
+
+	skb_put(skb, len);
+	skb->protocol = eth_type_trans(skb, ndev);
+	netif_receive_skb(skb);
+	priv->net_dev_stats.rx_bytes += len;
+	priv->net_dev_stats.rx_packets++;
+
+	/* alloc a new packet for receive */
+	skb = emac_rx_alloc(priv);
+
+recycle:
+	if (skb) {
+		ret = cpdma_chan_submit(priv->rxchan, skb, skb->data,
+					skb_tailroom(skb), GFP_KERNEL);
+		WARN_ON(ret < 0);
+	}
+}
+
+static void emac_tx_handler(void *token, int len, int status)
+{
+	struct sk_buff		*skb = token;
+	struct net_device	*ndev = skb->dev;
+	struct emac_priv	*priv = netdev_priv(ndev);
+
+	if (unlikely(netif_queue_stopped(ndev)))
+		netif_start_queue(ndev);
+	priv->net_dev_stats.tx_packets++;
+	priv->net_dev_stats.tx_bytes += len;
+	dev_kfree_skb_any(skb);
+}
+
 /** EMAC on-chip buffer descriptor memory
  *
  * WARNING: Please note that the on chip memory is used for both TX and RX
@@ -1412,42 +1470,36 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
 {
 	struct device *emac_dev = &ndev->dev;
 	int ret_code;
-	struct emac_netbufobj tx_buf; /* buffer obj-only single frame support */
-	struct emac_netpktobj tx_packet;  /* packet object */
 	struct emac_priv *priv = netdev_priv(ndev);
 
 	/* If no link, return */
 	if (unlikely(!priv->link)) {
 		if (netif_msg_tx_err(priv) && net_ratelimit())
 			dev_err(emac_dev, "DaVinci EMAC: No link to transmit");
-		return NETDEV_TX_BUSY;
+		goto fail_tx;
 	}
 
-	/* Build the buffer and packet objects - Since only single fragment is
-	 * supported, need not set length and token in both packet & object.
-	 * Doing so for completeness sake & to show that this needs to be done
-	 * in multifragment case
-	 */
-	tx_packet.buf_list = &tx_buf;
-	tx_packet.num_bufs = 1; /* only single fragment supported */
-	tx_packet.pkt_length = skb->len;
-	tx_packet.pkt_token = (void *)skb;
-	tx_buf.length = skb->len;
-	tx_buf.buf_token = (void *)skb;
-	tx_buf.data_ptr = skb->data;
-	ret_code = emac_send(priv, &tx_packet, EMAC_DEF_TX_CH);
+	ret_code = skb_padto(skb, EMAC_DEF_MIN_ETHPKTSIZE);
+	if (unlikely(ret_code < 0)) {
+		if (netif_msg_tx_err(priv) && net_ratelimit())
+			dev_err(emac_dev, "DaVinci EMAC: packet pad failed");
+		goto fail_tx;
+	}
+
+	ret_code = cpdma_chan_submit(priv->txchan, skb, skb->data, skb->len,
+				     GFP_KERNEL);
 	if (unlikely(ret_code != 0)) {
-		if (ret_code == EMAC_ERR_TX_OUT_OF_BD) {
-			if (netif_msg_tx_err(priv) && net_ratelimit())
-				dev_err(emac_dev, "DaVinci EMAC: xmit() fatal"\
-					" err. Out of TX BD's");
-			netif_stop_queue(priv->ndev);
-		}
-		priv->net_dev_stats.tx_dropped++;
-		return NETDEV_TX_BUSY;
+		if (netif_msg_tx_err(priv) && net_ratelimit())
+			dev_err(emac_dev, "DaVinci EMAC: desc submit failed");
+		goto fail_tx;
 	}
 
 	return NETDEV_TX_OK;
+
+fail_tx:
+	priv->net_dev_stats.tx_dropped++;
+	netif_stop_queue(priv->ndev);
+	return NETDEV_TX_BUSY;
 }
 
 /**
@@ -1470,11 +1522,8 @@ static void emac_dev_tx_timeout(struct net_device *ndev)
 
 	priv->net_dev_stats.tx_errors++;
 	emac_int_disable(priv);
-	emac_stop_txch(priv, EMAC_DEF_TX_CH);
-	emac_cleanup_txch(priv, EMAC_DEF_TX_CH);
-	emac_init_txch(priv, EMAC_DEF_TX_CH);
-	emac_write(EMAC_TXHDP(0), 0);
-	emac_write(EMAC_TXINTMASKSET, BIT(EMAC_DEF_TX_CH));
+	cpdma_chan_stop(priv->txchan);
+	cpdma_chan_start(priv->txchan);
 	emac_int_enable(priv);
 }
 
@@ -1795,7 +1844,6 @@ static void emac_setmac(struct emac_priv *priv, u32 ch, char *mac_addr)
 static int emac_dev_setmac_addr(struct net_device *ndev, void *addr)
 {
 	struct emac_priv *priv = netdev_priv(ndev);
-	struct emac_rxch *rxch = priv->rxch[EMAC_DEF_RX_CH];
 	struct device *emac_dev = &priv->ndev->dev;
 	struct sockaddr *sa = addr;
 
@@ -1806,11 +1854,10 @@ static int emac_dev_setmac_addr(struct net_device *ndev, void *addr)
 	memcpy(priv->mac_addr, sa->sa_data, ndev->addr_len);
 	memcpy(ndev->dev_addr, sa->sa_data, ndev->addr_len);
 
-	/* If the interface is down - rxch is NULL. */
 	/* MAC address is configured only after the interface is enabled. */
 	if (netif_running(ndev)) {
-		memcpy(rxch->mac_addr, sa->sa_data, ndev->addr_len);
-		emac_setmac(priv, EMAC_DEF_RX_CH, rxch->mac_addr);
+		memcpy(priv->mac_addr, sa->sa_data, ndev->addr_len);
+		emac_setmac(priv, EMAC_DEF_RX_CH, priv->mac_addr);
 	}
 
 	if (netif_msg_drv(priv))
@@ -2019,7 +2066,7 @@ end_emac_rx_bdproc:
  */
 static int emac_hw_enable(struct emac_priv *priv)
 {
-	u32 ch, val, mbp_enable, mac_control;
+	u32 val, mbp_enable, mac_control;
 
 	/* Soft reset */
 	emac_write(EMAC_SOFTRESET, 1);
@@ -2062,26 +2109,9 @@ static int emac_hw_enable(struct emac_priv *priv)
 	emac_write(EMAC_RXUNICASTCLEAR, EMAC_RX_UNICAST_CLEAR_ALL);
 	priv->rx_addr_type = (emac_read(EMAC_MACCONFIG) >> 8) & 0xFF;
 
-	val = emac_read(EMAC_TXCONTROL);
-	val |= EMAC_TX_CONTROL_TX_ENABLE_VAL;
-	emac_write(EMAC_TXCONTROL, val);
-	val = emac_read(EMAC_RXCONTROL);
-	val |= EMAC_RX_CONTROL_RX_ENABLE_VAL;
-	emac_write(EMAC_RXCONTROL, val);
 	emac_write(EMAC_MACINTMASKSET, EMAC_MAC_HOST_ERR_INTMASK_VAL);
 
-	for (ch = 0; ch < EMAC_DEF_MAX_TX_CH; ch++) {
-		emac_write(EMAC_TXHDP(ch), 0);
-		emac_write(EMAC_TXINTMASKSET, BIT(ch));
-	}
-	for (ch = 0; ch < EMAC_DEF_MAX_RX_CH; ch++) {
-		struct emac_rxch *rxch = priv->rxch[ch];
-		emac_setmac(priv, ch, rxch->mac_addr);
-		emac_write(EMAC_RXINTMASKSET, BIT(ch));
-		rxch->queue_active = 1;
-		emac_write(EMAC_RXHDP(ch),
-			   emac_virt_to_phys(rxch->active_queue_head, priv));
-	}
+	emac_setmac(priv, EMAC_DEF_RX_CH, priv->mac_addr);
 
 	/* Enable MII */
 	val = emac_read(EMAC_MACCONTROL);
@@ -2126,9 +2156,9 @@ static int emac_poll(struct napi_struct *napi, int budget)
 		mask = EMAC_DM646X_MAC_IN_VECTOR_TX_INT_VEC;
 
 	if (status & mask) {
-		num_pkts = emac_tx_bdproc(priv, EMAC_DEF_TX_CH,
-					  EMAC_DEF_TX_MAX_SERVICE);
-	} /* TX processing */
+		num_pkts = cpdma_chan_process(priv->txchan,
+					      EMAC_DEF_TX_MAX_SERVICE);
+	}
 
 	if (num_pkts)
 		return budget;
@@ -2138,9 +2168,8 @@ static int emac_poll(struct napi_struct *napi, int budget)
 	if (priv->version == EMAC_VERSION_2)
 		mask = EMAC_DM646X_MAC_IN_VECTOR_RX_INT_VEC;
 
-	if (status & mask) {
-		num_pkts = emac_rx_bdproc(priv, EMAC_DEF_RX_CH, budget);
-	} /* RX processing */
+	if (status & mask)
+		num_pkts = cpdma_chan_process(priv->rxchan, budget);
 
 	if (num_pkts < budget) {
 		napi_complete(napi);
@@ -2282,9 +2311,9 @@ static int match_first_device(struct device *dev, void *data)
 static int emac_dev_open(struct net_device *ndev)
 {
 	struct device *emac_dev = &ndev->dev;
-	u32 rc, cnt, ch;
+	u32 cnt;
 	struct resource *res;
-	int q, m;
+	int q, m, ret;
 	int i = 0;
 	int k = 0;
 	struct emac_priv *priv = netdev_priv(ndev);
@@ -2296,29 +2325,21 @@ static int emac_dev_open(struct net_device *ndev)
 	/* Configuration items */
 	priv->rx_buf_size = EMAC_DEF_MAX_FRAME_SIZE + NET_IP_ALIGN;
 
-	/* Clear basic hardware */
-	for (ch = 0; ch < EMAC_MAX_TXRX_CHANNELS; ch++) {
-		emac_write(EMAC_TXHDP(ch), 0);
-		emac_write(EMAC_RXHDP(ch), 0);
-		emac_write(EMAC_RXHDP(ch), 0);
-		emac_write(EMAC_RXINTMASKCLEAR, EMAC_INT_MASK_CLEAR);
-		emac_write(EMAC_TXINTMASKCLEAR, EMAC_INT_MASK_CLEAR);
-	}
 	priv->mac_hash1 = 0;
 	priv->mac_hash2 = 0;
 	emac_write(EMAC_MACHASH1, 0);
 	emac_write(EMAC_MACHASH2, 0);
 
-	/* multi ch not supported - open 1 TX, 1RX ch by default */
-	rc = emac_init_txch(priv, EMAC_DEF_TX_CH);
-	if (0 != rc) {
-		dev_err(emac_dev, "DaVinci EMAC: emac_init_txch() failed");
-		return rc;
-	}
-	rc = emac_init_rxch(priv, EMAC_DEF_RX_CH, priv->mac_addr);
-	if (0 != rc) {
-		dev_err(emac_dev, "DaVinci EMAC: emac_init_rxch() failed");
-		return rc;
+	for (i = 0; i < EMAC_DEF_RX_NUM_DESC; i++) {
+		struct sk_buff *skb = emac_rx_alloc(priv);
+
+		if (!skb)
+			break;
+
+		ret = cpdma_chan_submit(priv->rxchan, skb, skb->data,
+					skb_tailroom(skb), GFP_KERNEL);
+		if (WARN_ON(ret < 0))
+			break;
 	}
 
 	/* Request IRQ */
@@ -2335,6 +2356,8 @@ static int emac_dev_open(struct net_device *ndev)
 	/* Start/Enable EMAC hardware */
 	emac_hw_enable(priv);
 
+	cpdma_ctlr_start(priv->dma);
+
 	priv->phydev = NULL;
 
 	/* use the first phy on the bus if pdata did not give us a phy id */
@@ -2423,10 +2446,7 @@ static int emac_dev_stop(struct net_device *ndev)
 
 	netif_carrier_off(ndev);
 	emac_int_disable(priv);
-	emac_stop_txch(priv, EMAC_DEF_TX_CH);
-	emac_stop_rxch(priv, EMAC_DEF_RX_CH);
-	emac_cleanup_txch(priv, EMAC_DEF_TX_CH);
-	emac_cleanup_rxch(priv, EMAC_DEF_RX_CH);
+	cpdma_ctlr_stop(priv->dma);
 	emac_write(EMAC_SOFTRESET, 1);
 
 	if (priv->phydev)
@@ -2531,9 +2551,10 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 	struct resource *res;
 	struct net_device *ndev;
 	struct emac_priv *priv;
-	unsigned long size;
+	unsigned long size, hw_ram_addr;
 	struct emac_platform_data *pdata;
 	struct device *emac_dev;
+	struct cpdma_params dma_params;
 
 	/* obtain emac clock from kernel */
 	emac_clk = clk_get(&pdev->dev, NULL);
@@ -2606,11 +2627,40 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 	priv->ctrl_ram_size = pdata->ctrl_ram_size;
 	priv->emac_ctrl_ram = priv->remap_addr + pdata->ctrl_ram_offset;
 
-	if (pdata->hw_ram_addr)
-		priv->hw_ram_addr = pdata->hw_ram_addr;
-	else
-		priv->hw_ram_addr = (u32 __force)res->start +
-					pdata->ctrl_ram_offset;
+	hw_ram_addr = pdata->hw_ram_addr;
+	if (!hw_ram_addr)
+		hw_ram_addr = (u32 __force)res->start + pdata->ctrl_ram_offset;
+
+	memset(&dma_params, 0, sizeof(dma_params));
+	dma_params.dev			= emac_dev;
+	dma_params.dmaregs		= priv->emac_base;
+	dma_params.rxthresh		= priv->emac_base + 0x120;
+	dma_params.rxfree		= priv->emac_base + 0x140;
+	dma_params.txhdp		= priv->emac_base + 0x600;
+	dma_params.rxhdp		= priv->emac_base + 0x620;
+	dma_params.txcp			= priv->emac_base + 0x640;
+	dma_params.rxcp			= priv->emac_base + 0x660;
+	dma_params.num_chan		= EMAC_MAX_TXRX_CHANNELS;
+	dma_params.min_packet_size	= EMAC_DEF_MIN_ETHPKTSIZE;
+	dma_params.desc_mem_phys	= hw_ram_addr;
+	dma_params.desc_mem_size	= pdata->ctrl_ram_size;
+	dma_params.desc_align		= 16;
+
+	priv->dma = cpdma_ctlr_create(&dma_params);
+	if (!priv->dma) {
+		dev_err(emac_dev, "DaVinci EMAC: Error initializing DMA\n");
+		rc = -ENOMEM;
+		goto no_dma;
+	}
+
+	priv->txchan = cpdma_chan_create(priv->dma, tx_chan_num(EMAC_DEF_TX_CH),
+				       emac_tx_handler);
+	priv->rxchan = cpdma_chan_create(priv->dma, rx_chan_num(EMAC_DEF_RX_CH),
+				       emac_rx_handler);
+	if (WARN_ON(!priv->txchan || !priv->rxchan)) {
+		rc = -ENOMEM;
+		goto no_irq_res;
+	}
 
 	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 	if (!res) {
@@ -2653,6 +2703,12 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 netdev_reg_err:
 	clk_disable(emac_clk);
 no_irq_res:
+	if (priv->txchan)
+		cpdma_chan_destroy(priv->txchan);
+	if (priv->rxchan)
+		cpdma_chan_destroy(priv->rxchan);
+	cpdma_ctlr_destroy(priv->dma);
+no_dma:
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	release_mem_region(res->start, res->end - res->start + 1);
 	iounmap(priv->remap_addr);
@@ -2681,6 +2737,12 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev)
 	platform_set_drvdata(pdev, NULL);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
+	if (priv->txchan)
+		cpdma_chan_destroy(priv->txchan);
+	if (priv->rxchan)
+		cpdma_chan_destroy(priv->rxchan);
+	cpdma_ctlr_destroy(priv->dma);
+
 	release_mem_region(res->start, res->end - res->start + 1);
 
 	unregister_netdev(ndev);
-- 
1.7.0.4


From cyril at ti.com  Tue Aug  3 08:31:51 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:51 -0400
Subject: [PATCH 6/8] netdev: separate out davinci cpdma controller code
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <1280842313-3743-7-git-send-email-cyril@ti.com>

In addition to being embedded into the EMAC controller, the CPDMA hardware
block is used in TI's CPSW switch controller.  Fortunately, the programming
interface to this hardware block remains pretty nicely consistent across these
devices.

This patch adds a new CPDMA services layer, which can then be reused across
EMAC and CPSW drivers.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 drivers/net/Kconfig         |   10 +
 drivers/net/Makefile        |    1 +
 drivers/net/davinci_cpdma.c |  836 +++++++++++++++++++++++++++++++++++++++++++
 drivers/net/davinci_cpdma.h |  105 ++++++
 4 files changed, 952 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/davinci_cpdma.c
 create mode 100644 drivers/net/davinci_cpdma.h

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 3c324c2..462ade5 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -941,6 +941,7 @@ config TI_DAVINCI_EMAC
 	tristate "TI DaVinci EMAC Support"
 	depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
 	select TI_DAVINCI_MDIO
+	select TI_DAVINCI_CPDMA
 	select PHYLIB
 	help
 	  This driver supports TI's DaVinci Ethernet .
@@ -958,6 +959,15 @@ config TI_DAVINCI_MDIO
 	  To compile this driver as a module, choose M here: the module
 	  will be called davinci_mdio.  This is recommended.
 
+config TI_DAVINCI_CPDMA
+	tristate "TI DaVinci CPDMA Support"
+	depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
+	help
+	  This driver supports TI's DaVinci CPDMA dma engine.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called davinci_cpdma.  This is recommended.
+
 config DM9000
 	tristate "DM9000 support"
 	depends on ARM || BLACKFIN || MIPS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 84cf18d..4780a9c 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PHYLIB) += phy/
 
 obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
 obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
+obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
 
 obj-$(CONFIG_E1000) += e1000/
 obj-$(CONFIG_E1000E) += e1000e/
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
new file mode 100644
index 0000000..acce1c1
--- /dev/null
+++ b/drivers/net/davinci_cpdma.c
@@ -0,0 +1,836 @@
+/*
+ * Texas Instruments CPDMA Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/spinlock.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+
+#include "davinci_cpdma.h"
+
+/* DMA Registers */
+#define CPDMA_TXIDVER		0x00
+#define CPDMA_TXCONTROL		0x04
+#define CPDMA_TXTEARDOWN	0x08
+#define CPDMA_RXIDVER		0x10
+#define CPDMA_RXCONTROL		0x14
+#define CPDMA_SOFTRESET		0x1c
+#define CPDMA_RXTEARDOWN	0x18
+#define CPDMA_TXINTSTATRAW	0x80
+#define CPDMA_TXINTSTATMASKED	0x84
+#define CPDMA_TXINTMASKSET	0x88
+#define CPDMA_TXINTMASKCLEAR	0x8c
+#define CPDMA_MACINVECTOR	0x90
+#define CPDMA_MACEOIVECTOR	0x94
+#define CPDMA_RXINTSTATRAW	0xa0
+#define CPDMA_RXINTSTATMASKED	0xa4
+#define CPDMA_RXINTMASKSET	0xa8
+#define CPDMA_RXINTMASKCLEAR	0xac
+#define CPDMA_DMAINTSTATRAW	0xb0
+#define CPDMA_DMAINTSTATMASKED	0xb4
+#define CPDMA_DMAINTMASKSET	0xb8
+#define CPDMA_DMAINTMASKCLEAR	0xbc
+#define CPDMA_DMAINT_HOSTERR	BIT(1)
+
+/* the following exist only if has_ext_regs is set */
+#define CPDMA_DMACONTROL	0x20
+#define CPDMA_DMASTATUS		0x24
+#define CPDMA_RXBUFFOFS		0x28
+#define CPDMA_EM_CONTROL	0x2c
+
+/* Descriptor mode bits */
+#define CPDMA_DESC_SOP		BIT(31)
+#define CPDMA_DESC_EOP		BIT(30)
+#define CPDMA_DESC_OWNER	BIT(29)
+#define CPDMA_DESC_EOQ		BIT(28)
+#define CPDMA_DESC_TD_COMPLETE	BIT(27)
+#define CPDMA_DESC_PASS_CRC	BIT(26)
+
+#define CPDMA_TEARDOWN_VALUE	0xfffffffc
+
+struct cpdma_desc {
+	/* hardware fields */
+	u32			hw_next;
+	u32			hw_buffer;
+	u32			hw_len;
+	u32			hw_mode;
+	/* software fields */
+	void			*sw_token;
+	u32			sw_buffer;
+	u32			sw_len;
+};
+
+struct cpdma_desc_pool {
+	u32			phys;
+	void __iomem		*iomap;		/* ioremap map */
+	void			*cpumap;	/* dma_alloc map */
+	int			desc_size, mem_size;
+	int			num_desc, used_desc;
+	unsigned long		*bitmap;
+	struct device		*dev;
+	spinlock_t		lock;
+};
+
+enum cpdma_state {
+	CPDMA_STATE_IDLE,
+	CPDMA_STATE_ACTIVE,
+	CPDMA_STATE_TEARDOWN,
+};
+
+struct cpdma_ctlr {
+	enum cpdma_state	state;
+	struct cpdma_params	params;
+	struct device		*dev;
+	struct cpdma_desc_pool	*pool;
+	spinlock_t		lock;
+	struct cpdma_chan	*channels[2 * CPDMA_MAX_CHANNELS];
+};
+
+struct cpdma_chan {
+	enum cpdma_state		state;
+	struct cpdma_ctlr		*ctlr;
+	int				chan_num;
+	spinlock_t			lock;
+	struct cpdma_desc __iomem	*head, *tail;
+	int				count;
+	void __iomem			*hdp, *cp, *rxfree;
+	u32				mask;
+	cpdma_handler_fn		handler;
+	enum dma_data_direction		dir;
+	struct cpdma_chan_stats		stats;
+	/* offsets into dmaregs */
+	int	int_set, int_clear, td;
+};
+
+/* The following make access to common cpdma_ctlr params more readable */
+#define dmaregs		params.dmaregs
+#define num_chan	params.num_chan
+
+/* various accessors */
+#define dma_reg_read(ctlr, ofs)		__raw_readl((ctlr)->dmaregs + (ofs))
+#define chan_read(chan, fld)		__raw_readl((chan)->fld)
+#define desc_read(desc, fld)		__raw_readl(&(desc)->fld)
+#define dma_reg_write(ctlr, ofs, v)	__raw_writel(v, (ctlr)->dmaregs + (ofs))
+#define chan_write(chan, fld, v)	__raw_writel(v, (chan)->fld)
+#define desc_write(desc, fld, v)	__raw_writel((u32)(v), &(desc)->fld)
+
+/*
+ * Utility constructs for a cpdma descriptor pool.  Some devices (e.g. davinci
+ * emac) have dedicated on-chip memory for these descriptors.  Some other
+ * devices (e.g. cpsw switches) use plain old memory.  Descriptor pools
+ * abstract out these details
+ */
+static struct cpdma_desc_pool *
+cpdma_desc_pool_create(struct device *dev, u32 phys, int size, int align)
+{
+	int bitmap_size;
+	struct cpdma_desc_pool *pool;
+
+	pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+	if (!pool)
+		return NULL;
+
+	spin_lock_init(&pool->lock);
+
+	pool->dev	= dev;
+	pool->mem_size	= size;
+	pool->desc_size	= ALIGN(sizeof(struct cpdma_desc), align);
+	pool->num_desc	= size / pool->desc_size;
+
+	bitmap_size  = (pool->num_desc / BITS_PER_LONG) * sizeof(long);
+	pool->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+	if (!pool->bitmap)
+		goto fail;
+
+	if (phys) {
+		pool->phys  = phys;
+		pool->iomap = ioremap(phys, size);
+	} else {
+		pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
+						  GFP_KERNEL);
+		pool->iomap = (void __force __iomem *)pool->cpumap;
+	}
+
+	if (pool->iomap)
+		return pool;
+
+fail:
+	kfree(pool->bitmap);
+	kfree(pool);
+	return NULL;
+}
+
+static void cpdma_desc_pool_destroy(struct cpdma_desc_pool *pool)
+{
+	unsigned long flags;
+
+	if (!pool)
+		return;
+
+	spin_lock_irqsave(&pool->lock, flags);
+	WARN_ON(pool->used_desc);
+	kfree(pool->bitmap);
+	if (pool->cpumap) {
+		dma_free_coherent(pool->dev, pool->mem_size, pool->cpumap,
+				  pool->phys);
+	} else {
+		iounmap(pool->iomap);
+	}
+	spin_unlock_irqrestore(&pool->lock, flags);
+	kfree(pool);
+}
+
+static inline dma_addr_t desc_phys(struct cpdma_desc_pool *pool,
+		  struct cpdma_desc __iomem *desc)
+{
+	if (!desc)
+		return 0;
+	return pool->phys + (__force dma_addr_t)desc -
+			    (__force dma_addr_t)pool->iomap;
+}
+
+static inline struct cpdma_desc __iomem *
+desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t dma)
+{
+	return dma ? pool->iomap + dma - pool->phys : NULL;
+}
+
+static struct cpdma_desc __iomem *
+cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc)
+{
+	unsigned long flags;
+	int index;
+	struct cpdma_desc __iomem *desc = NULL;
+
+	spin_lock_irqsave(&pool->lock, flags);
+
+	index = bitmap_find_next_zero_area(pool->bitmap, pool->num_desc, 0,
+					   num_desc, 0);
+	if (index < pool->num_desc) {
+		bitmap_set(pool->bitmap, index, num_desc);
+		desc = pool->iomap + pool->desc_size * index;
+		pool->used_desc++;
+	}
+
+	spin_unlock_irqrestore(&pool->lock, flags);
+	return desc;
+}
+
+static void cpdma_desc_free(struct cpdma_desc_pool *pool,
+			    struct cpdma_desc __iomem *desc, int num_desc)
+{
+	unsigned long flags, index;
+
+	index = ((unsigned long)desc - (unsigned long)pool->iomap) /
+		pool->desc_size;
+	spin_lock_irqsave(&pool->lock, flags);
+	bitmap_clear(pool->bitmap, index, num_desc);
+	pool->used_desc--;
+	spin_unlock_irqrestore(&pool->lock, flags);
+}
+
+struct cpdma_ctlr *cpdma_ctlr_create(struct cpdma_params *params)
+{
+	struct cpdma_ctlr *ctlr;
+
+	ctlr = kzalloc(sizeof(*ctlr), GFP_KERNEL);
+	if (!ctlr)
+		return NULL;
+
+	ctlr->state = CPDMA_STATE_IDLE;
+	ctlr->params = *params;
+	ctlr->dev = params->dev;
+	spin_lock_init(&ctlr->lock);
+
+	ctlr->pool = cpdma_desc_pool_create(ctlr->dev,
+					    ctlr->params.desc_mem_phys,
+					    ctlr->params.desc_mem_size,
+					    ctlr->params.desc_align);
+	if (!ctlr->pool) {
+		kfree(ctlr);
+		return NULL;
+	}
+
+	if (WARN_ON(ctlr->num_chan > CPDMA_MAX_CHANNELS))
+		ctlr->num_chan = CPDMA_MAX_CHANNELS;
+	return ctlr;
+}
+
+int cpdma_ctlr_start(struct cpdma_ctlr *ctlr)
+{
+	unsigned long flags;
+	int i;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+	if (ctlr->state != CPDMA_STATE_IDLE) {
+		spin_unlock_irqrestore(&ctlr->lock, flags);
+		return -EBUSY;
+	}
+
+	if (ctlr->params.has_soft_reset) {
+		unsigned long timeout = jiffies + HZ/10;
+
+		dma_reg_write(ctlr, CPDMA_SOFTRESET, 1);
+		while (time_before(jiffies, timeout)) {
+			if (dma_reg_read(ctlr, CPDMA_SOFTRESET) == 0)
+				break;
+		}
+		WARN_ON(!time_before(jiffies, timeout));
+	}
+
+	for (i = 0; i < ctlr->num_chan; i++) {
+		__raw_writel(0, ctlr->params.txhdp + 4 * i);
+		__raw_writel(0, ctlr->params.rxhdp + 4 * i);
+		__raw_writel(0, ctlr->params.txcp + 4 * i);
+		__raw_writel(0, ctlr->params.rxcp + 4 * i);
+	}
+
+	dma_reg_write(ctlr, CPDMA_RXINTMASKCLEAR, 0xffffffff);
+	dma_reg_write(ctlr, CPDMA_TXINTMASKCLEAR, 0xffffffff);
+
+	dma_reg_write(ctlr, CPDMA_TXCONTROL, 1);
+	dma_reg_write(ctlr, CPDMA_RXCONTROL, 1);
+
+	ctlr->state = CPDMA_STATE_ACTIVE;
+
+	for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
+		if (ctlr->channels[i])
+			cpdma_chan_start(ctlr->channels[i]);
+	}
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+	return 0;
+}
+
+int cpdma_ctlr_stop(struct cpdma_ctlr *ctlr)
+{
+	unsigned long flags;
+	int i;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+	if (ctlr->state != CPDMA_STATE_ACTIVE) {
+		spin_unlock_irqrestore(&ctlr->lock, flags);
+		return -EINVAL;
+	}
+
+	ctlr->state = CPDMA_STATE_TEARDOWN;
+
+	for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
+		if (ctlr->channels[i])
+			cpdma_chan_stop(ctlr->channels[i]);
+	}
+
+	dma_reg_write(ctlr, CPDMA_RXINTMASKCLEAR, 0xffffffff);
+	dma_reg_write(ctlr, CPDMA_TXINTMASKCLEAR, 0xffffffff);
+
+	dma_reg_write(ctlr, CPDMA_TXCONTROL, 0);
+	dma_reg_write(ctlr, CPDMA_RXCONTROL, 0);
+
+	ctlr->state = CPDMA_STATE_IDLE;
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+	return 0;
+}
+
+int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
+{
+	unsigned long flags;
+	int ret = 0, i;
+
+	if (!ctlr)
+		return -EINVAL;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+	if (ctlr->state != CPDMA_STATE_IDLE)
+		cpdma_ctlr_stop(ctlr);
+
+	for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
+		if (ctlr->channels[i])
+			cpdma_chan_destroy(ctlr->channels[i]);
+	}
+
+	cpdma_desc_pool_destroy(ctlr->pool);
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+	kfree(ctlr);
+	return ret;
+}
+
+int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
+{
+	unsigned long flags;
+	int i, reg;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+	if (ctlr->state != CPDMA_STATE_ACTIVE) {
+		spin_unlock_irqrestore(&ctlr->lock, flags);
+		return -EINVAL;
+	}
+
+	reg = enable ? CPDMA_DMAINTMASKSET : CPDMA_DMAINTMASKCLEAR;
+	dma_reg_write(ctlr, reg, CPDMA_DMAINT_HOSTERR);
+
+	for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
+		if (ctlr->channels[i])
+			cpdma_chan_int_ctrl(ctlr->channels[i], enable);
+	}
+
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+	return 0;
+}
+
+void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
+{
+	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
+}
+
+struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
+				     cpdma_handler_fn handler)
+{
+	struct cpdma_chan *chan;
+	int ret, offset = (chan_num % CPDMA_MAX_CHANNELS) * 4;
+	unsigned long flags;
+
+	if (__chan_linear(chan_num) >= ctlr->num_chan)
+		return NULL;
+
+	ret = -ENOMEM;
+	chan = kzalloc(sizeof(*chan), GFP_KERNEL);
+	if (!chan)
+		goto err_chan_alloc;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+	ret = -EBUSY;
+	if (ctlr->channels[chan_num])
+		goto err_chan_busy;
+
+	chan->ctlr	= ctlr;
+	chan->state	= CPDMA_STATE_IDLE;
+	chan->chan_num	= chan_num;
+	chan->handler	= handler;
+
+	if (is_rx_chan(chan)) {
+		chan->hdp	= ctlr->params.rxhdp + offset;
+		chan->cp	= ctlr->params.rxcp + offset;
+		chan->rxfree	= ctlr->params.rxfree + offset;
+		chan->int_set	= CPDMA_RXINTMASKSET;
+		chan->int_clear	= CPDMA_RXINTMASKCLEAR;
+		chan->td	= CPDMA_RXTEARDOWN;
+		chan->dir	= DMA_FROM_DEVICE;
+	} else {
+		chan->hdp	= ctlr->params.txhdp + offset;
+		chan->cp	= ctlr->params.txcp + offset;
+		chan->int_set	= CPDMA_TXINTMASKSET;
+		chan->int_clear	= CPDMA_TXINTMASKCLEAR;
+		chan->td	= CPDMA_TXTEARDOWN;
+		chan->dir	= DMA_TO_DEVICE;
+	}
+	chan->mask = BIT(chan_linear(chan));
+
+	spin_lock_init(&chan->lock);
+
+	ctlr->channels[chan_num] = chan;
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+	return chan;
+
+err_chan_busy:
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+err_chan_alloc:
+	return ERR_PTR(ret);
+}
+
+int cpdma_chan_destroy(struct cpdma_chan *chan)
+{
+	struct cpdma_ctlr *ctlr = chan->ctlr;
+	unsigned long flags;
+
+	if (!chan)
+		return -EINVAL;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+	if (chan->state != CPDMA_STATE_IDLE)
+		cpdma_chan_stop(chan);
+	ctlr->channels[chan->chan_num] = NULL;
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+	kfree(chan);
+	return 0;
+}
+
+int cpdma_chan_get_stats(struct cpdma_chan *chan,
+			 struct cpdma_chan_stats *stats)
+{
+	unsigned long flags;
+	if (!chan)
+		return -EINVAL;
+	spin_lock_irqsave(&chan->lock, flags);
+	memcpy(stats, &chan->stats, sizeof(*stats));
+	spin_unlock_irqrestore(&chan->lock, flags);
+	return 0;
+}
+
+static void __cpdma_chan_submit(struct cpdma_chan *chan,
+				struct cpdma_desc __iomem *desc)
+{
+	struct cpdma_ctlr		*ctlr = chan->ctlr;
+	struct cpdma_desc __iomem	*prev = chan->tail;
+	struct cpdma_desc_pool		*pool = ctlr->pool;
+	dma_addr_t			desc_dma;
+
+	desc_dma = desc_phys(pool, desc);
+
+	/* simple case - idle channel */
+	if (!chan->head) {
+		chan->stats.head_enqueue++;
+		chan->head = desc;
+		chan->tail = desc;
+		if (chan->state == CPDMA_STATE_ACTIVE)
+			chan_write(chan, hdp, desc_dma);
+		return;
+	}
+
+	/* first chain the descriptor at the tail of the list */
+	desc_write(prev, hw_next, desc_dma);
+	chan->tail = desc;
+	chan->stats.tail_enqueue++;
+
+	/* next check if EOQ has been triggered already */
+	if (desc_read(prev, hw_mode) & CPDMA_DESC_EOQ &&
+	    chan->state == CPDMA_STATE_ACTIVE) {
+		chan_write(chan, hdp, desc_dma);
+		chan->stats.misqueued++;
+	}
+}
+
+int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
+		      int len, gfp_t gfp_mask)
+{
+	struct cpdma_ctlr		*ctlr = chan->ctlr;
+	struct cpdma_desc __iomem	*desc;
+	dma_addr_t			buffer;
+	unsigned long			flags;
+	u32				mode;
+	int				ret = 0;
+
+	spin_lock_irqsave(&chan->lock, flags);
+
+	if (chan->state == CPDMA_STATE_TEARDOWN) {
+		ret = -EINVAL;
+		goto unlock_ret;
+	}
+
+	desc = cpdma_desc_alloc(ctlr->pool, 1);
+	if (!desc) {
+		chan->stats.desc_alloc_fail++;
+		ret = -ENOMEM;
+		goto unlock_ret;
+	}
+
+	if (len < ctlr->params.min_packet_size) {
+		len = ctlr->params.min_packet_size;
+		chan->stats.runt_transmit_buff++;
+	}
+
+	buffer = dma_map_single(ctlr->dev, data, len, chan->dir);
+	mode = CPDMA_DESC_OWNER | CPDMA_DESC_SOP | CPDMA_DESC_EOP;
+
+	desc_write(desc, hw_next,   0);
+	desc_write(desc, hw_buffer, buffer);
+	desc_write(desc, hw_len,    len);
+	desc_write(desc, hw_mode,   mode | len);
+	desc_write(desc, sw_token,  token);
+	desc_write(desc, sw_buffer, buffer);
+	desc_write(desc, sw_len,    len);
+
+	__cpdma_chan_submit(chan, desc);
+
+	if (chan->state == CPDMA_STATE_ACTIVE && chan->rxfree)
+		chan_write(chan, rxfree, 1);
+
+	chan->count++;
+
+unlock_ret:
+	spin_unlock_irqrestore(&chan->lock, flags);
+	return ret;
+}
+
+static void __cpdma_chan_free(struct cpdma_chan *chan,
+			      struct cpdma_desc __iomem *desc,
+			      int outlen, int status)
+{
+	struct cpdma_ctlr		*ctlr = chan->ctlr;
+	struct cpdma_desc_pool		*pool = ctlr->pool;
+	dma_addr_t			buff_dma;
+	int				origlen;
+	void				*token;
+
+	token      = (void *)desc_read(desc, sw_token);
+	buff_dma   = desc_read(desc, sw_buffer);
+	origlen    = desc_read(desc, sw_len);
+
+	dma_unmap_single(ctlr->dev, buff_dma, origlen, chan->dir);
+	cpdma_desc_free(pool, desc, 1);
+	(*chan->handler)(token, outlen, status);
+}
+
+static int __cpdma_chan_process(struct cpdma_chan *chan)
+{
+	struct cpdma_ctlr		*ctlr = chan->ctlr;
+	struct cpdma_desc __iomem	*desc;
+	int				status, outlen;
+	struct cpdma_desc_pool		*pool = ctlr->pool;
+	dma_addr_t			desc_dma;
+	unsigned long			flags;
+
+	spin_lock_irqsave(&chan->lock, flags);
+
+	desc = chan->head;
+	if (!desc) {
+		chan->stats.empty_dequeue++;
+		status = -ENOENT;
+		goto unlock_ret;
+	}
+	desc_dma = desc_phys(pool, desc);
+
+	status	= __raw_readl(&desc->hw_mode);
+	outlen	= status & 0x7ff;
+	if (status & CPDMA_DESC_OWNER) {
+		chan->stats.busy_dequeue++;
+		status = -EBUSY;
+		goto unlock_ret;
+	}
+	status	= status & (CPDMA_DESC_EOQ | CPDMA_DESC_TD_COMPLETE);
+
+	chan->head = desc_from_phys(pool, desc_read(desc, hw_next));
+	chan_write(chan, cp, desc_dma);
+	chan->count--;
+	chan->stats.good_dequeue++;
+
+	spin_unlock_irqrestore(&chan->lock, flags);
+
+	__cpdma_chan_free(chan, desc, outlen, status);
+	return status;
+
+unlock_ret:
+	spin_unlock_irqrestore(&chan->lock, flags);
+	return status;
+}
+
+int cpdma_chan_process(struct cpdma_chan *chan, int quota)
+{
+	int used = 0, ret = 0;
+
+	if (chan->state != CPDMA_STATE_ACTIVE)
+		return -EINVAL;
+
+	while (used < quota) {
+		ret = __cpdma_chan_process(chan);
+		if (ret < 0)
+			break;
+		used++;
+	}
+	return used;
+}
+
+int cpdma_chan_start(struct cpdma_chan *chan)
+{
+	struct cpdma_ctlr	*ctlr = chan->ctlr;
+	struct cpdma_desc_pool	*pool = ctlr->pool;
+	unsigned long		flags;
+
+	spin_lock_irqsave(&chan->lock, flags);
+	if (chan->state != CPDMA_STATE_IDLE) {
+		spin_unlock_irqrestore(&chan->lock, flags);
+		return -EBUSY;
+	}
+	if (ctlr->state != CPDMA_STATE_ACTIVE) {
+		spin_unlock_irqrestore(&chan->lock, flags);
+		return -EINVAL;
+	}
+	dma_reg_write(ctlr, chan->int_set, chan->mask);
+	chan->state = CPDMA_STATE_ACTIVE;
+	if (chan->head) {
+		chan_write(chan, hdp, desc_phys(pool, chan->head));
+		if (chan->rxfree)
+			chan_write(chan, rxfree, chan->count);
+	}
+
+	spin_unlock_irqrestore(&chan->lock, flags);
+	return 0;
+}
+
+int cpdma_chan_stop(struct cpdma_chan *chan)
+{
+	struct cpdma_ctlr	*ctlr = chan->ctlr;
+	struct cpdma_desc_pool	*pool = ctlr->pool;
+	unsigned long		flags;
+	int			ret;
+	unsigned long		timeout;
+
+	spin_lock_irqsave(&chan->lock, flags);
+	if (chan->state != CPDMA_STATE_ACTIVE) {
+		spin_unlock_irqrestore(&chan->lock, flags);
+		return -EINVAL;
+	}
+
+	chan->state = CPDMA_STATE_TEARDOWN;
+	dma_reg_write(ctlr, chan->int_clear, chan->mask);
+
+	/* trigger teardown */
+	dma_reg_write(ctlr, chan->td, chan->chan_num);
+
+	/* wait for teardown complete */
+	timeout = jiffies + HZ/10;	/* 100 msec */
+	while (time_before(jiffies, timeout)) {
+		u32 cp = chan_read(chan, cp);
+		if ((cp & CPDMA_TEARDOWN_VALUE) == CPDMA_TEARDOWN_VALUE)
+			break;
+		cpu_relax();
+	}
+	WARN_ON(!time_before(jiffies, timeout));
+	chan_write(chan, cp, CPDMA_TEARDOWN_VALUE);
+
+	/* handle completed packets */
+	do {
+		ret = __cpdma_chan_process(chan);
+		if (ret < 0)
+			break;
+	} while ((ret & CPDMA_DESC_TD_COMPLETE) == 0);
+
+	/* remaining packets haven't been tx/rx'ed, clean them up */
+	while (chan->head) {
+		struct cpdma_desc __iomem *desc = chan->head;
+		dma_addr_t next_dma;
+
+		next_dma = desc_read(desc, hw_next);
+		chan->head = desc_from_phys(pool, next_dma);
+		chan->stats.teardown_dequeue++;
+
+		/* issue callback without locks held */
+		spin_unlock_irqrestore(&chan->lock, flags);
+		__cpdma_chan_free(chan, desc, 0, -ENOSYS);
+		spin_lock_irqsave(&chan->lock, flags);
+	}
+
+	chan->state = CPDMA_STATE_IDLE;
+	spin_unlock_irqrestore(&chan->lock, flags);
+	return 0;
+}
+
+int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&chan->lock, flags);
+	if (chan->state != CPDMA_STATE_ACTIVE) {
+		spin_unlock_irqrestore(&chan->lock, flags);
+		return -EINVAL;
+	}
+
+	dma_reg_write(chan->ctlr, enable ? chan->int_set : chan->int_clear,
+		      chan->mask);
+	spin_unlock_irqrestore(&chan->lock, flags);
+
+	return 0;
+}
+
+struct cpdma_control_info {
+	u32		reg;
+	u32		shift, mask;
+	int		access;
+#define ACCESS_RO	BIT(0)
+#define ACCESS_WO	BIT(1)
+#define ACCESS_RW	(ACCESS_RO | ACCESS_WO)
+};
+
+struct cpdma_control_info controls[] = {
+	[CPDMA_CMD_IDLE]	  = {CPDMA_DMACONTROL,	3,  1,      ACCESS_WO},
+	[CPDMA_COPY_ERROR_FRAMES] = {CPDMA_DMACONTROL,	4,  1,      ACCESS_RW},
+	[CPDMA_RX_OFF_LEN_UPDATE] = {CPDMA_DMACONTROL,	2,  1,      ACCESS_RW},
+	[CPDMA_RX_OWNERSHIP_FLIP] = {CPDMA_DMACONTROL,	1,  1,      ACCESS_RW},
+	[CPDMA_TX_PRIO_FIXED]	  = {CPDMA_DMACONTROL,	0,  1,      ACCESS_RW},
+	[CPDMA_STAT_IDLE]	  = {CPDMA_DMASTATUS,	31, 1,      ACCESS_RO},
+	[CPDMA_STAT_TX_ERR_CODE]  = {CPDMA_DMASTATUS,	20, 0xf,    ACCESS_RW},
+	[CPDMA_STAT_TX_ERR_CHAN]  = {CPDMA_DMASTATUS,	16, 0x7,    ACCESS_RW},
+	[CPDMA_STAT_RX_ERR_CODE]  = {CPDMA_DMASTATUS,	12, 0xf,    ACCESS_RW},
+	[CPDMA_STAT_RX_ERR_CHAN]  = {CPDMA_DMASTATUS,	8,  0x7,    ACCESS_RW},
+	[CPDMA_RX_BUFFER_OFFSET]  = {CPDMA_RXBUFFOFS,	0,  0xffff, ACCESS_RW},
+};
+
+int cpdma_control_get(struct cpdma_ctlr *ctlr, int control)
+{
+	unsigned long flags;
+	struct cpdma_control_info *info = &controls[control];
+	int ret;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	ret = -ENOTSUPP;
+	if (!ctlr->params.has_ext_regs)
+		goto unlock_ret;
+
+	ret = -EINVAL;
+	if (ctlr->state != CPDMA_STATE_ACTIVE)
+		goto unlock_ret;
+
+	ret = -ENOENT;
+	if (control < 0 || control >= ARRAY_SIZE(controls))
+		goto unlock_ret;
+
+	ret = -EPERM;
+	if ((info->access & ACCESS_RO) != ACCESS_RO)
+		goto unlock_ret;
+
+	ret = (dma_reg_read(ctlr, info->reg) >> info->shift) & info->mask;
+
+unlock_ret:
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+	return ret;
+}
+
+int cpdma_control_set(struct cpdma_ctlr *ctlr, int control, int value)
+{
+	unsigned long flags;
+	struct cpdma_control_info *info = &controls[control];
+	int ret;
+	u32 val;
+
+	spin_lock_irqsave(&ctlr->lock, flags);
+
+	ret = -ENOTSUPP;
+	if (!ctlr->params.has_ext_regs)
+		goto unlock_ret;
+
+	ret = -EINVAL;
+	if (ctlr->state != CPDMA_STATE_ACTIVE)
+		goto unlock_ret;
+
+	ret = -ENOENT;
+	if (control < 0 || control >= ARRAY_SIZE(controls))
+		goto unlock_ret;
+
+	ret = -EPERM;
+	if ((info->access & ACCESS_WO) != ACCESS_WO)
+		goto unlock_ret;
+
+	val  = dma_reg_read(ctlr, info->reg);
+	val &= ~(info->mask << info->shift);
+	val |= (value & info->mask) << info->shift;
+	dma_reg_write(ctlr, info->reg, val);
+	ret = 0;
+
+unlock_ret:
+	spin_unlock_irqrestore(&ctlr->lock, flags);
+	return ret;
+}
diff --git a/drivers/net/davinci_cpdma.h b/drivers/net/davinci_cpdma.h
new file mode 100644
index 0000000..d50ee35
--- /dev/null
+++ b/drivers/net/davinci_cpdma.h
@@ -0,0 +1,105 @@
+/*
+ * Texas Instruments CPDMA Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __DAVINCI_CPDMA_H__
+#define __DAVINCI_CPDMA_H__
+
+#define CPDMA_MAX_CHANNELS	BITS_PER_LONG
+
+#define tx_chan_num(chan)	(chan)
+#define rx_chan_num(chan)	((chan) + CPDMA_MAX_CHANNELS)
+#define is_rx_chan(chan)	((chan)->chan_num >= CPDMA_MAX_CHANNELS)
+#define is_tx_chan(chan)	(!is_rx_chan(chan))
+#define __chan_linear(chan_num)	((chan_num) & (CPDMA_MAX_CHANNELS - 1))
+#define chan_linear(chan)	__chan_linear((chan)->chan_num)
+
+struct cpdma_params {
+	struct device		*dev;
+	void __iomem		*dmaregs;
+	void __iomem		*txhdp, *rxhdp, *txcp, *rxcp;
+	void __iomem		*rxthresh, *rxfree;
+	int			num_chan;
+	bool			has_soft_reset;
+	int			min_packet_size;
+	u32			desc_mem_phys;
+	int			desc_mem_size;
+	int			desc_align;
+
+	/*
+	 * Some instances of embedded cpdma controllers have extra control and
+	 * status registers.  The following flag enables access to these
+	 * "extended" registers.
+	 */
+	bool			has_ext_regs;
+};
+
+struct cpdma_chan_stats {
+	u32			head_enqueue;
+	u32			tail_enqueue;
+	u32			pad_enqueue;
+	u32			misqueued;
+	u32			desc_alloc_fail;
+	u32			pad_alloc_fail;
+	u32			runt_receive_buff;
+	u32			runt_transmit_buff;
+	u32			empty_dequeue;
+	u32			busy_dequeue;
+	u32			good_dequeue;
+	u32			teardown_dequeue;
+};
+
+struct cpdma_ctlr;
+struct cpdma_chan;
+
+typedef void (*cpdma_handler_fn)(void *token, int len, int status);
+
+struct cpdma_ctlr *cpdma_ctlr_create(struct cpdma_params *params);
+int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr);
+int cpdma_ctlr_start(struct cpdma_ctlr *ctlr);
+int cpdma_ctlr_stop(struct cpdma_ctlr *ctlr);
+
+struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
+				     cpdma_handler_fn handler);
+int cpdma_chan_destroy(struct cpdma_chan *chan);
+int cpdma_chan_start(struct cpdma_chan *chan);
+int cpdma_chan_stop(struct cpdma_chan *chan);
+
+int cpdma_chan_get_stats(struct cpdma_chan *chan,
+			 struct cpdma_chan_stats *stats);
+int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
+		      int len, gfp_t gfp_mask);
+int cpdma_chan_process(struct cpdma_chan *chan, int quota);
+
+int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable);
+void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr);
+int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable);
+
+enum cpdma_control {
+	CPDMA_CMD_IDLE,			/* write-only */
+	CPDMA_COPY_ERROR_FRAMES,	/* read-write */
+	CPDMA_RX_OFF_LEN_UPDATE,	/* read-write */
+	CPDMA_RX_OWNERSHIP_FLIP,	/* read-write */
+	CPDMA_TX_PRIO_FIXED,		/* read-write */
+	CPDMA_STAT_IDLE,		/* read-only */
+	CPDMA_STAT_TX_ERR_CHAN,		/* read-only */
+	CPDMA_STAT_TX_ERR_CODE,		/* read-only */
+	CPDMA_STAT_RX_ERR_CHAN,		/* read-only */
+	CPDMA_STAT_RX_ERR_CODE,		/* read-only */
+	CPDMA_RX_BUFFER_OFFSET,		/* read-write */
+};
+
+int cpdma_control_get(struct cpdma_ctlr *ctlr, int control);
+int cpdma_control_set(struct cpdma_ctlr *ctlr, int control, int value);
+
+#endif
-- 
1.7.0.4


From cyril at ti.com  Tue Aug  3 08:31:53 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 09:31:53 -0400
Subject: [PATCH 8/8] netdev: cleanup unused davinci emac cpdma code
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <1280842313-3743-9-git-send-email-cyril@ti.com>

Having switched over to the newly introduced cpdma layer, this patch now
removes a whole bunch of code that is now unused.  This patch has been
maintained separate strictly for reasons of readability.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 drivers/net/davinci_emac.c |  929 --------------------------------------------
 1 files changed, 0 insertions(+), 929 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 3efa42d..00f26fa 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -127,7 +127,6 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
 /* EMAC register related defines */
 #define EMAC_ALL_MULTI_REG_VALUE	(0xFFFFFFFF)
 #define EMAC_NUM_MULTICAST_BITS		(64)
-#define EMAC_TEARDOWN_VALUE		(0xFFFFFFFC)
 #define EMAC_TX_CONTROL_TX_ENABLE_VAL	(0x1)
 #define EMAC_RX_CONTROL_RX_ENABLE_VAL	(0x1)
 #define EMAC_MAC_HOST_ERR_INTMASK_VAL	(0x2)
@@ -214,24 +213,10 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
 #define EMAC_DEF_MAX_MULTICAST_ADDRESSES (64) /* Max mcast addr's */
 
 /* EMAC Peripheral Device Register Memory Layout structure */
-#define EMAC_TXIDVER		0x0
-#define EMAC_TXCONTROL		0x4
-#define EMAC_TXTEARDOWN		0x8
-#define EMAC_RXIDVER		0x10
-#define EMAC_RXCONTROL		0x14
-#define EMAC_RXTEARDOWN		0x18
-#define EMAC_TXINTSTATRAW	0x80
-#define EMAC_TXINTSTATMASKED	0x84
-#define EMAC_TXINTMASKSET	0x88
-#define EMAC_TXINTMASKCLEAR	0x8C
 #define EMAC_MACINVECTOR	0x90
 
 #define EMAC_DM646X_MACEOIVECTOR	0x94
 
-#define EMAC_RXINTSTATRAW	0xA0
-#define EMAC_RXINTSTATMASKED	0xA4
-#define EMAC_RXINTMASKSET	0xA8
-#define EMAC_RXINTMASKCLEAR	0xAC
 #define EMAC_MACINTSTATRAW	0xB0
 #define EMAC_MACINTSTATMASKED	0xB4
 #define EMAC_MACINTMASKSET	0xB8
@@ -258,12 +243,6 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
 #define EMAC_MACADDRHI		0x504
 #define EMAC_MACINDEX		0x508
 
-/* EMAC HDP and Completion registors */
-#define EMAC_TXHDP(ch)		(0x600 + (ch * 4))
-#define EMAC_RXHDP(ch)		(0x620 + (ch * 4))
-#define EMAC_TXCP(ch)		(0x640 + (ch * 4))
-#define EMAC_RXCP(ch)		(0x660 + (ch * 4))
-
 /* EMAC statistics registers */
 #define EMAC_RXGOODFRAMES	0x200
 #define EMAC_RXBCASTFRAMES	0x204
@@ -311,120 +290,6 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
 /* EMAC Stats Clear Mask */
 #define EMAC_STATS_CLR_MASK    (0xFFFFFFFF)
 
-/** net_buf_obj: EMAC network bufferdata structure
- *
- * EMAC network buffer data structure
- */
-struct emac_netbufobj {
-	void *buf_token;
-	char *data_ptr;
-	int length;
-};
-
-/** net_pkt_obj: EMAC network packet data structure
- *
- * EMAC network packet data structure - supports buffer list (for future)
- */
-struct emac_netpktobj {
-	void *pkt_token; /* data token may hold tx/rx chan id */
-	struct emac_netbufobj *buf_list; /* array of network buffer objects */
-	int num_bufs;
-	int pkt_length;
-};
-
-/** emac_tx_bd: EMAC TX Buffer descriptor data structure
- *
- * EMAC TX Buffer descriptor data structure
- */
-struct emac_tx_bd {
-	int h_next;
-	int buff_ptr;
-	int off_b_len;
-	int mode; /* SOP, EOP, ownership, EOQ, teardown,Qstarv, length */
-	struct emac_tx_bd __iomem *next;
-	void *buf_token;
-};
-
-/** emac_txch: EMAC TX Channel data structure
- *
- * EMAC TX Channel data structure
- */
-struct emac_txch {
-	/* Config related */
-	u32 num_bd;
-	u32 service_max;
-
-	/* CPPI specific */
-	u32 alloc_size;
-	void __iomem *bd_mem;
-	struct emac_tx_bd __iomem *bd_pool_head;
-	struct emac_tx_bd __iomem *active_queue_head;
-	struct emac_tx_bd __iomem *active_queue_tail;
-	struct emac_tx_bd __iomem *last_hw_bdprocessed;
-	u32 queue_active;
-	u32 teardown_pending;
-	u32 *tx_complete;
-
-	/** statistics */
-	u32 proc_count;     /* TX: # of times emac_tx_bdproc is called */
-	u32 mis_queued_packets;
-	u32 queue_reinit;
-	u32 end_of_queue_add;
-	u32 out_of_tx_bd;
-	u32 no_active_pkts; /* IRQ when there were no packets to process */
-	u32 active_queue_count;
-};
-
-/** emac_rx_bd: EMAC RX Buffer descriptor data structure
- *
- * EMAC RX Buffer descriptor data structure
- */
-struct emac_rx_bd {
-	int h_next;
-	int buff_ptr;
-	int off_b_len;
-	int mode;
-	struct emac_rx_bd __iomem *next;
-	void *data_ptr;
-	void *buf_token;
-};
-
-/** emac_rxch: EMAC RX Channel data structure
- *
- * EMAC RX Channel data structure
- */
-struct emac_rxch {
-	/* configuration info */
-	u32 num_bd;
-	u32 service_max;
-	u32 buf_size;
-	char mac_addr[6];
-
-	/** CPPI specific */
-	u32 alloc_size;
-	void __iomem *bd_mem;
-	struct emac_rx_bd __iomem *bd_pool_head;
-	struct emac_rx_bd __iomem *active_queue_head;
-	struct emac_rx_bd __iomem *active_queue_tail;
-	u32 queue_active;
-	u32 teardown_pending;
-
-	/* packet and buffer objects */
-	struct emac_netpktobj pkt_queue;
-	struct emac_netbufobj buf_queue;
-
-	/** statistics */
-	u32 proc_count; /* number of times emac_rx_bdproc is called */
-	u32 processed_bd;
-	u32 recycled_bd;
-	u32 out_of_rx_bd;
-	u32 out_of_rx_buffers;
-	u32 queue_reinit;
-	u32 end_of_queue_add;
-	u32 end_of_queue;
-	u32 mis_queued_packets;
-};
-
 /* emac_priv: EMAC private data structure
  *
  * EMAC adapter private data structure
@@ -435,17 +300,10 @@ struct emac_priv {
 	struct platform_device *pdev;
 	struct napi_struct napi;
 	char mac_addr[6];
-	spinlock_t tx_lock;
-	spinlock_t rx_lock;
 	void __iomem *remap_addr;
 	u32 emac_base_phys;
 	void __iomem *emac_base;
 	void __iomem *ctrl_base;
-	void __iomem *emac_ctrl_ram;
-	u32 ctrl_ram_size;
-	u32 hw_ram_addr;
-	struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
-	struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
 	struct cpdma_ctlr *dma;
 	struct cpdma_chan *txchan;
 	struct cpdma_chan *rxchan;
@@ -473,18 +331,6 @@ struct emac_priv {
 static struct clk *emac_clk;
 static unsigned long emac_bus_frequency;
 
-#define emac_virt_to_phys(addr, priv) \
-	(((u32 __force)(addr) - (u32 __force)(priv->emac_ctrl_ram)) \
-	+ priv->hw_ram_addr)
-
-/* Cache macros - Packet buffers would be from skb pool which is cached */
-#define EMAC_VIRT_NOCACHE(addr) (addr)
-
-/* DM644x does not have BD's in cached memory - so no cache functions */
-#define BD_CACHE_INVALIDATE(addr, size)
-#define BD_CACHE_WRITEBACK(addr, size)
-#define BD_CACHE_WRITEBACK_INVALIDATE(addr, size)
-
 /* EMAC TX Host Error description strings */
 static char *emac_txhost_errcodes[16] = {
 	"No error", "SOP error", "Ownership bit not set in SOP buffer",
@@ -525,20 +371,6 @@ static void emac_dump_regs(struct emac_priv *priv)
 	dev_info(emac_dev, "EMAC: EWCTL: %08X, EWINTTCNT: %08X\n",
 		emac_ctrl_read(EMAC_CTRL_EWCTL),
 		emac_ctrl_read(EMAC_CTRL_EWINTTCNT));
-	dev_info(emac_dev, "EMAC: TXID: %08X %s, RXID: %08X %s\n",
-		emac_read(EMAC_TXIDVER),
-		((emac_read(EMAC_TXCONTROL)) ? "enabled" : "disabled"),
-		emac_read(EMAC_RXIDVER),
-		((emac_read(EMAC_RXCONTROL)) ? "enabled" : "disabled"));
-	dev_info(emac_dev, "EMAC: TXIntRaw:%08X, TxIntMasked: %08X, "\
-		"TxIntMasSet: %08X\n", emac_read(EMAC_TXINTSTATRAW),
-		emac_read(EMAC_TXINTSTATMASKED), emac_read(EMAC_TXINTMASKSET));
-	dev_info(emac_dev, "EMAC: RXIntRaw:%08X, RxIntMasked: %08X, "\
-		"RxIntMasSet: %08X\n", emac_read(EMAC_RXINTSTATRAW),
-		emac_read(EMAC_RXINTSTATMASKED), emac_read(EMAC_RXINTMASKSET));
-	dev_info(emac_dev, "EMAC: MacIntRaw:%08X, MacIntMasked: %08X, "\
-		"MacInVector=%08X\n", emac_read(EMAC_MACINTSTATRAW),
-		emac_read(EMAC_MACINTSTATMASKED), emac_read(EMAC_MACINVECTOR));
 	dev_info(emac_dev, "EMAC: EmuControl:%08X, FifoControl: %08X\n",
 		emac_read(EMAC_EMCONTROL), emac_read(EMAC_FIFOCONTROL));
 	dev_info(emac_dev, "EMAC: MBPEnable:%08X, RXUnicastSet: %08X, "\
@@ -547,8 +379,6 @@ static void emac_dump_regs(struct emac_priv *priv)
 	dev_info(emac_dev, "EMAC: MacControl:%08X, MacStatus: %08X, "\
 		"MacConfig=%08X\n", emac_read(EMAC_MACCONTROL),
 		emac_read(EMAC_MACSTATUS), emac_read(EMAC_MACCONFIG));
-	dev_info(emac_dev, "EMAC: TXHDP[0]:%08X, RXHDP[0]: %08X\n",
-		emac_read(EMAC_TXHDP(0)), emac_read(EMAC_RXHDP(0)));
 	dev_info(emac_dev, "EMAC Statistics\n");
 	dev_info(emac_dev, "EMAC: rx_good_frames:%d\n",
 		emac_read(EMAC_RXGOODFRAMES));
@@ -1090,372 +920,6 @@ static void emac_tx_handler(void *token, int len, int status)
 	dev_kfree_skb_any(skb);
 }
 
-/** EMAC on-chip buffer descriptor memory
- *
- * WARNING: Please note that the on chip memory is used for both TX and RX
- * buffer descriptor queues and is equally divided between TX and RX desc's
- * If the number of TX or RX descriptors change this memory pointers need
- * to be adjusted. If external memory is allocated then these pointers can
- * pointer to the memory
- *
- */
-#define EMAC_TX_BD_MEM(priv)	((priv)->emac_ctrl_ram)
-#define EMAC_RX_BD_MEM(priv)	((priv)->emac_ctrl_ram + \
-				(((priv)->ctrl_ram_size) >> 1))
-
-/**
- * emac_init_txch: TX channel initialization
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: RX channel number
- *
- * Called during device init to setup a TX channel (allocate buffer desc
- * create free pool and keep ready for transmission
- *
- * Returns success(0) or mem alloc failures error code
- */
-static int emac_init_txch(struct emac_priv *priv, u32 ch)
-{
-	struct device *emac_dev = &priv->ndev->dev;
-	u32 cnt, bd_size;
-	void __iomem *mem;
-	struct emac_tx_bd __iomem *curr_bd;
-	struct emac_txch *txch = NULL;
-
-	txch = kzalloc(sizeof(struct emac_txch), GFP_KERNEL);
-	if (NULL == txch) {
-		dev_err(emac_dev, "DaVinci EMAC: TX Ch mem alloc failed");
-		return -ENOMEM;
-	}
-	priv->txch[ch] = txch;
-	txch->service_max = EMAC_DEF_TX_MAX_SERVICE;
-	txch->active_queue_head = NULL;
-	txch->active_queue_tail = NULL;
-	txch->queue_active = 0;
-	txch->teardown_pending = 0;
-
-	/* allocate memory for TX CPPI channel on a 4 byte boundry */
-	txch->tx_complete = kzalloc(txch->service_max * sizeof(u32),
-				    GFP_KERNEL);
-	if (NULL == txch->tx_complete) {
-		dev_err(emac_dev, "DaVinci EMAC: Tx service mem alloc failed");
-		kfree(txch);
-		return -ENOMEM;
-	}
-
-	/* allocate buffer descriptor pool align every BD on four word
-	 * boundry for future requirements */
-	bd_size = (sizeof(struct emac_tx_bd) + 0xF) & ~0xF;
-	txch->num_bd = (priv->ctrl_ram_size >> 1) / bd_size;
-	txch->alloc_size = (((bd_size * txch->num_bd) + 0xF) & ~0xF);
-
-	/* alloc TX BD memory */
-	txch->bd_mem = EMAC_TX_BD_MEM(priv);
-	__memzero((void __force *)txch->bd_mem, txch->alloc_size);
-
-	/* initialize the BD linked list */
-	mem = (void __force __iomem *)
-			(((u32 __force) txch->bd_mem + 0xF) & ~0xF);
-	txch->bd_pool_head = NULL;
-	for (cnt = 0; cnt < txch->num_bd; cnt++) {
-		curr_bd = mem + (cnt * bd_size);
-		curr_bd->next = txch->bd_pool_head;
-		txch->bd_pool_head = curr_bd;
-	}
-
-	/* reset statistics counters */
-	txch->out_of_tx_bd = 0;
-	txch->no_active_pkts = 0;
-	txch->active_queue_count = 0;
-
-	return 0;
-}
-
-/**
- * emac_cleanup_txch: Book-keep function to clean TX channel resources
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: TX channel number
- *
- * Called to clean up TX channel resources
- *
- */
-static void emac_cleanup_txch(struct emac_priv *priv, u32 ch)
-{
-	struct emac_txch *txch = priv->txch[ch];
-
-	if (txch) {
-		if (txch->bd_mem)
-			txch->bd_mem = NULL;
-		kfree(txch->tx_complete);
-		kfree(txch);
-		priv->txch[ch] = NULL;
-	}
-}
-
-/**
- * emac_net_tx_complete: TX packet completion function
- * @priv: The DaVinci EMAC private adapter structure
- * @net_data_tokens: packet token - skb pointer
- * @num_tokens: number of skb's to free
- * @ch: TX channel number
- *
- * Frees the skb once packet is transmitted
- *
- */
-static int emac_net_tx_complete(struct emac_priv *priv,
-				void **net_data_tokens,
-				int num_tokens, u32 ch)
-{
-	u32 cnt;
-
-	if (unlikely(num_tokens && netif_queue_stopped(priv->ndev)))
-		netif_start_queue(priv->ndev);
-	for (cnt = 0; cnt < num_tokens; cnt++) {
-		struct sk_buff *skb = (struct sk_buff *)net_data_tokens[cnt];
-		if (skb == NULL)
-			continue;
-		priv->net_dev_stats.tx_packets++;
-		priv->net_dev_stats.tx_bytes += skb->len;
-		dev_kfree_skb_any(skb);
-	}
-	return 0;
-}
-
-/**
- * emac_txch_teardown: TX channel teardown
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: TX channel number
- *
- * Called to teardown TX channel
- *
- */
-static void emac_txch_teardown(struct emac_priv *priv, u32 ch)
-{
-	struct device *emac_dev = &priv->ndev->dev;
-	u32 teardown_cnt = 0xFFFFFFF0; /* Some high value */
-	struct emac_txch *txch = priv->txch[ch];
-	struct emac_tx_bd __iomem *curr_bd;
-
-	while ((emac_read(EMAC_TXCP(ch)) & EMAC_TEARDOWN_VALUE) !=
-	       EMAC_TEARDOWN_VALUE) {
-		/* wait till tx teardown complete */
-		cpu_relax(); /* TODO: check if this helps ... */
-		--teardown_cnt;
-		if (0 == teardown_cnt) {
-			dev_err(emac_dev, "EMAC: TX teardown aborted\n");
-			break;
-		}
-	}
-	emac_write(EMAC_TXCP(ch), EMAC_TEARDOWN_VALUE);
-
-	/* process sent packets and return skb's to upper layer */
-	if (1 == txch->queue_active) {
-		curr_bd = txch->active_queue_head;
-		while (curr_bd != NULL) {
-			dma_unmap_single(emac_dev, curr_bd->buff_ptr,
-				curr_bd->off_b_len & EMAC_RX_BD_BUF_SIZE,
-				DMA_TO_DEVICE);
-
-			emac_net_tx_complete(priv, (void __force *)
-					&curr_bd->buf_token, 1, ch);
-			if (curr_bd != txch->active_queue_tail)
-				curr_bd = curr_bd->next;
-			else
-				break;
-		}
-		txch->bd_pool_head = txch->active_queue_head;
-		txch->active_queue_head =
-		txch->active_queue_tail = NULL;
-	}
-}
-
-/**
- * emac_stop_txch: Stop TX channel operation
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: TX channel number
- *
- * Called to stop TX channel operation
- *
- */
-static void emac_stop_txch(struct emac_priv *priv, u32 ch)
-{
-	struct emac_txch *txch = priv->txch[ch];
-
-	if (txch) {
-		txch->teardown_pending = 1;
-		emac_write(EMAC_TXTEARDOWN, 0);
-		emac_txch_teardown(priv, ch);
-		txch->teardown_pending = 0;
-		emac_write(EMAC_TXINTMASKCLEAR, BIT(ch));
-	}
-}
-
-/**
- * emac_tx_bdproc: TX buffer descriptor (packet) processing
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: TX channel number to process buffer descriptors for
- * @budget: number of packets allowed to process
- * @pending: indication to caller that packets are pending to process
- *
- * Processes TX buffer descriptors after packets are transmitted - checks
- * ownership bit on the TX * descriptor and requeues it to free pool & frees
- * the SKB buffer. Only "budget" number of packets are processed and
- * indication of pending packets provided to the caller
- *
- * Returns number of packets processed
- */
-static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
-{
-	struct device *emac_dev = &priv->ndev->dev;
-	unsigned long flags;
-	u32 frame_status;
-	u32 pkts_processed = 0;
-	u32 tx_complete_cnt = 0;
-	struct emac_tx_bd __iomem *curr_bd;
-	struct emac_txch *txch = priv->txch[ch];
-	u32 *tx_complete_ptr = txch->tx_complete;
-
-	if (unlikely(1 == txch->teardown_pending)) {
-		if (netif_msg_tx_err(priv) && net_ratelimit()) {
-			dev_err(emac_dev, "DaVinci EMAC:emac_tx_bdproc: "\
-				"teardown pending\n");
-		}
-		return 0;  /* dont handle any pkt completions */
-	}
-
-	++txch->proc_count;
-	spin_lock_irqsave(&priv->tx_lock, flags);
-	curr_bd = txch->active_queue_head;
-	if (NULL == curr_bd) {
-		emac_write(EMAC_TXCP(ch),
-			   emac_virt_to_phys(txch->last_hw_bdprocessed, priv));
-		txch->no_active_pkts++;
-		spin_unlock_irqrestore(&priv->tx_lock, flags);
-		return 0;
-	}
-	BD_CACHE_INVALIDATE(curr_bd, EMAC_BD_LENGTH_FOR_CACHE);
-	frame_status = curr_bd->mode;
-	while ((curr_bd) &&
-	      ((frame_status & EMAC_CPPI_OWNERSHIP_BIT) == 0) &&
-	      (pkts_processed < budget)) {
-		emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd, priv));
-		txch->active_queue_head = curr_bd->next;
-		if (frame_status & EMAC_CPPI_EOQ_BIT) {
-			if (curr_bd->next) {	/* misqueued packet */
-				emac_write(EMAC_TXHDP(ch), curr_bd->h_next);
-				++txch->mis_queued_packets;
-			} else {
-				txch->queue_active = 0; /* end of queue */
-			}
-		}
-
-		dma_unmap_single(emac_dev, curr_bd->buff_ptr,
-				curr_bd->off_b_len & EMAC_RX_BD_BUF_SIZE,
-				DMA_TO_DEVICE);
-
-		*tx_complete_ptr = (u32) curr_bd->buf_token;
-		++tx_complete_ptr;
-		++tx_complete_cnt;
-		curr_bd->next = txch->bd_pool_head;
-		txch->bd_pool_head = curr_bd;
-		--txch->active_queue_count;
-		pkts_processed++;
-		txch->last_hw_bdprocessed = curr_bd;
-		curr_bd = txch->active_queue_head;
-		if (curr_bd) {
-			BD_CACHE_INVALIDATE(curr_bd, EMAC_BD_LENGTH_FOR_CACHE);
-			frame_status = curr_bd->mode;
-		}
-	} /* end of pkt processing loop */
-
-	emac_net_tx_complete(priv,
-			     (void *)&txch->tx_complete[0],
-			     tx_complete_cnt, ch);
-	spin_unlock_irqrestore(&priv->tx_lock, flags);
-	return pkts_processed;
-}
-
-#define EMAC_ERR_TX_OUT_OF_BD -1
-
-/**
- * emac_send: EMAC Transmit function (internal)
- * @priv: The DaVinci EMAC private adapter structure
- * @pkt: packet pointer (contains skb ptr)
- * @ch: TX channel number
- *
- * Called by the transmit function to queue the packet in EMAC hardware queue
- *
- * Returns success(0) or error code (typically out of desc's)
- */
-static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
-{
-	unsigned long flags;
-	struct emac_tx_bd __iomem *curr_bd;
-	struct emac_txch *txch;
-	struct emac_netbufobj *buf_list;
-
-	txch = priv->txch[ch];
-	buf_list = pkt->buf_list;   /* get handle to the buffer array */
-
-	/* check packet size and pad if short */
-	if (pkt->pkt_length < EMAC_DEF_MIN_ETHPKTSIZE) {
-		buf_list->length += (EMAC_DEF_MIN_ETHPKTSIZE - pkt->pkt_length);
-		pkt->pkt_length = EMAC_DEF_MIN_ETHPKTSIZE;
-	}
-
-	spin_lock_irqsave(&priv->tx_lock, flags);
-	curr_bd = txch->bd_pool_head;
-	if (curr_bd == NULL) {
-		txch->out_of_tx_bd++;
-		spin_unlock_irqrestore(&priv->tx_lock, flags);
-		return EMAC_ERR_TX_OUT_OF_BD;
-	}
-
-	txch->bd_pool_head = curr_bd->next;
-	curr_bd->buf_token = buf_list->buf_token;
-	curr_bd->buff_ptr = dma_map_single(&priv->ndev->dev, buf_list->data_ptr,
-			buf_list->length, DMA_TO_DEVICE);
-	curr_bd->off_b_len = buf_list->length;
-	curr_bd->h_next = 0;
-	curr_bd->next = NULL;
-	curr_bd->mode = (EMAC_CPPI_SOP_BIT | EMAC_CPPI_OWNERSHIP_BIT |
-			 EMAC_CPPI_EOP_BIT | pkt->pkt_length);
-
-	/* flush the packet from cache if write back cache is present */
-	BD_CACHE_WRITEBACK_INVALIDATE(curr_bd, EMAC_BD_LENGTH_FOR_CACHE);
-
-	/* send the packet */
-	if (txch->active_queue_head == NULL) {
-		txch->active_queue_head = curr_bd;
-		txch->active_queue_tail = curr_bd;
-		if (1 != txch->queue_active) {
-			emac_write(EMAC_TXHDP(ch),
-					emac_virt_to_phys(curr_bd, priv));
-			txch->queue_active = 1;
-		}
-		++txch->queue_reinit;
-	} else {
-		register struct emac_tx_bd __iomem *tail_bd;
-		register u32 frame_status;
-
-		tail_bd = txch->active_queue_tail;
-		tail_bd->next = curr_bd;
-		txch->active_queue_tail = curr_bd;
-		tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
-		tail_bd->h_next = (int)emac_virt_to_phys(curr_bd, priv);
-		frame_status = tail_bd->mode;
-		if (frame_status & EMAC_CPPI_EOQ_BIT) {
-			emac_write(EMAC_TXHDP(ch),
-				emac_virt_to_phys(curr_bd, priv));
-			frame_status &= ~(EMAC_CPPI_EOQ_BIT);
-			tail_bd->mode = frame_status;
-			++txch->end_of_queue_add;
-		}
-	}
-	txch->active_queue_count++;
-	spin_unlock_irqrestore(&priv->tx_lock, flags);
-	return 0;
-}
-
 /**
  * emac_dev_xmit: EMAC Transmit function
  * @skb: SKB pointer
@@ -1528,207 +992,6 @@ static void emac_dev_tx_timeout(struct net_device *ndev)
 }
 
 /**
- * emac_net_alloc_rx_buf: Allocate a skb for RX
- * @priv: The DaVinci EMAC private adapter structure
- * @buf_size: size of SKB data buffer to allocate
- * @data_token: data token returned (skb handle for storing in buffer desc)
- * @ch: RX channel number
- *
- * Called during RX channel setup - allocates skb buffer of required size
- * and provides the skb handle and allocated buffer data pointer to caller
- *
- * Returns skb data pointer or 0 on failure to alloc skb
- */
-static void *emac_net_alloc_rx_buf(struct emac_priv *priv, int buf_size,
-		void **data_token, u32 ch)
-{
-	struct net_device *ndev = priv->ndev;
-	struct device *emac_dev = &ndev->dev;
-	struct sk_buff *p_skb;
-
-	p_skb = dev_alloc_skb(buf_size);
-	if (unlikely(NULL == p_skb)) {
-		if (netif_msg_rx_err(priv) && net_ratelimit())
-			dev_err(emac_dev, "DaVinci EMAC: failed to alloc skb");
-		return NULL;
-	}
-
-	/* set device pointer in skb and reserve space for extra bytes */
-	p_skb->dev = ndev;
-	skb_reserve(p_skb, NET_IP_ALIGN);
-	*data_token = (void *) p_skb;
-	return p_skb->data;
-}
-
-/**
- * emac_init_rxch: RX channel initialization
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: RX channel number
- * @param: mac address for RX channel
- *
- * Called during device init to setup a RX channel (allocate buffers and
- * buffer descriptors, create queue and keep ready for reception
- *
- * Returns success(0) or mem alloc failures error code
- */
-static int emac_init_rxch(struct emac_priv *priv, u32 ch, char *param)
-{
-	struct device *emac_dev = &priv->ndev->dev;
-	u32 cnt, bd_size;
-	void __iomem *mem;
-	struct emac_rx_bd __iomem *curr_bd;
-	struct emac_rxch *rxch = NULL;
-
-	rxch = kzalloc(sizeof(struct emac_rxch), GFP_KERNEL);
-	if (NULL == rxch) {
-		dev_err(emac_dev, "DaVinci EMAC: RX Ch mem alloc failed");
-		return -ENOMEM;
-	}
-	priv->rxch[ch] = rxch;
-	rxch->buf_size = priv->rx_buf_size;
-	rxch->service_max = EMAC_DEF_RX_MAX_SERVICE;
-	rxch->queue_active = 0;
-	rxch->teardown_pending = 0;
-
-	/* save mac address */
-	for (cnt = 0; cnt < 6; cnt++)
-		rxch->mac_addr[cnt] = param[cnt];
-
-	/* allocate buffer descriptor pool align every BD on four word
-	 * boundry for future requirements */
-	bd_size = (sizeof(struct emac_rx_bd) + 0xF) & ~0xF;
-	rxch->num_bd = (priv->ctrl_ram_size >> 1) / bd_size;
-	rxch->alloc_size = (((bd_size * rxch->num_bd) + 0xF) & ~0xF);
-	rxch->bd_mem = EMAC_RX_BD_MEM(priv);
-	__memzero((void __force *)rxch->bd_mem, rxch->alloc_size);
-	rxch->pkt_queue.buf_list = &rxch->buf_queue;
-
-	/* allocate RX buffer and initialize the BD linked list */
-	mem = (void __force __iomem *)
-			(((u32 __force) rxch->bd_mem + 0xF) & ~0xF);
-	rxch->active_queue_head = NULL;
-	rxch->active_queue_tail = mem;
-	for (cnt = 0; cnt < rxch->num_bd; cnt++) {
-		curr_bd = mem + (cnt * bd_size);
-		/* for future use the last parameter contains the BD ptr */
-		curr_bd->data_ptr = emac_net_alloc_rx_buf(priv,
-				    rxch->buf_size,
-				    (void __force **)&curr_bd->buf_token,
-				    EMAC_DEF_RX_CH);
-		if (curr_bd->data_ptr == NULL) {
-			dev_err(emac_dev, "DaVinci EMAC: RX buf mem alloc " \
-				"failed for ch %d\n", ch);
-			kfree(rxch);
-			return -ENOMEM;
-		}
-
-		/* populate the hardware descriptor */
-		curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head,
-				priv);
-		curr_bd->buff_ptr = dma_map_single(emac_dev, curr_bd->data_ptr,
-				rxch->buf_size, DMA_FROM_DEVICE);
-		curr_bd->off_b_len = rxch->buf_size;
-		curr_bd->mode = EMAC_CPPI_OWNERSHIP_BIT;
-
-		/* write back to hardware memory */
-		BD_CACHE_WRITEBACK_INVALIDATE((u32) curr_bd,
-					      EMAC_BD_LENGTH_FOR_CACHE);
-		curr_bd->next = rxch->active_queue_head;
-		rxch->active_queue_head = curr_bd;
-	}
-
-	/* At this point rxCppi->activeQueueHead points to the first
-	   RX BD ready to be given to RX HDP and rxch->active_queue_tail
-	   points to the last RX BD
-	 */
-	return 0;
-}
-
-/**
- * emac_rxch_teardown: RX channel teardown
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: RX channel number
- *
- * Called during device stop to teardown RX channel
- *
- */
-static void emac_rxch_teardown(struct emac_priv *priv, u32 ch)
-{
-	struct device *emac_dev = &priv->ndev->dev;
-	u32 teardown_cnt = 0xFFFFFFF0; /* Some high value */
-
-	while ((emac_read(EMAC_RXCP(ch)) & EMAC_TEARDOWN_VALUE) !=
-	       EMAC_TEARDOWN_VALUE) {
-		/* wait till tx teardown complete */
-		cpu_relax(); /* TODO: check if this helps ... */
-		--teardown_cnt;
-		if (0 == teardown_cnt) {
-			dev_err(emac_dev, "EMAC: RX teardown aborted\n");
-			break;
-		}
-	}
-	emac_write(EMAC_RXCP(ch), EMAC_TEARDOWN_VALUE);
-}
-
-/**
- * emac_stop_rxch: Stop RX channel operation
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: RX channel number
- *
- * Called during device stop to stop RX channel operation
- *
- */
-static void emac_stop_rxch(struct emac_priv *priv, u32 ch)
-{
-	struct emac_rxch *rxch = priv->rxch[ch];
-
-	if (rxch) {
-		rxch->teardown_pending = 1;
-		emac_write(EMAC_RXTEARDOWN, ch);
-		/* wait for teardown complete */
-		emac_rxch_teardown(priv, ch);
-		rxch->teardown_pending = 0;
-		emac_write(EMAC_RXINTMASKCLEAR, BIT(ch));
-	}
-}
-
-/**
- * emac_cleanup_rxch: Book-keep function to clean RX channel resources
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: RX channel number
- *
- * Called during device stop to clean up RX channel resources
- *
- */
-static void emac_cleanup_rxch(struct emac_priv *priv, u32 ch)
-{
-	struct emac_rxch *rxch = priv->rxch[ch];
-	struct emac_rx_bd __iomem *curr_bd;
-
-	if (rxch) {
-		/* free the receive buffers previously allocated */
-		curr_bd = rxch->active_queue_head;
-		while (curr_bd) {
-			if (curr_bd->buf_token) {
-				dma_unmap_single(&priv->ndev->dev,
-					curr_bd->buff_ptr,
-					curr_bd->off_b_len
-						& EMAC_RX_BD_BUF_SIZE,
-					DMA_FROM_DEVICE);
-
-				dev_kfree_skb_any((struct sk_buff *)\
-						  curr_bd->buf_token);
-			}
-			curr_bd = curr_bd->next;
-		}
-		if (rxch->bd_mem)
-			rxch->bd_mem = NULL;
-		kfree(rxch);
-		priv->rxch[ch] = NULL;
-	}
-}
-
-/**
  * emac_set_type0addr: Set EMAC Type0 mac address
  * @priv: The DaVinci EMAC private adapter structure
  * @ch: RX channel number
@@ -1868,194 +1131,6 @@ static int emac_dev_setmac_addr(struct net_device *ndev, void *addr)
 }
 
 /**
- * emac_addbd_to_rx_queue: Recycle RX buffer descriptor
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: RX channel number to process buffer descriptors for
- * @curr_bd: current buffer descriptor
- * @buffer: buffer pointer for descriptor
- * @buf_token: buffer token (stores skb information)
- *
- * Prepares the recycled buffer descriptor and addes it to hardware
- * receive queue - if queue empty this descriptor becomes the head
- * else addes the descriptor to end of queue
- *
- */
-static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
-		struct emac_rx_bd __iomem *curr_bd,
-		char *buffer, void *buf_token)
-{
-	struct emac_rxch *rxch = priv->rxch[ch];
-
-	/* populate the hardware descriptor */
-	curr_bd->h_next = 0;
-	curr_bd->buff_ptr = dma_map_single(&priv->ndev->dev, buffer,
-				rxch->buf_size, DMA_FROM_DEVICE);
-	curr_bd->off_b_len = rxch->buf_size;
-	curr_bd->mode = EMAC_CPPI_OWNERSHIP_BIT;
-	curr_bd->next = NULL;
-	curr_bd->data_ptr = buffer;
-	curr_bd->buf_token = buf_token;
-
-	/* write back  */
-	BD_CACHE_WRITEBACK_INVALIDATE(curr_bd, EMAC_BD_LENGTH_FOR_CACHE);
-	if (rxch->active_queue_head == NULL) {
-		rxch->active_queue_head = curr_bd;
-		rxch->active_queue_tail = curr_bd;
-		if (0 != rxch->queue_active) {
-			emac_write(EMAC_RXHDP(ch),
-			   emac_virt_to_phys(rxch->active_queue_head, priv));
-			rxch->queue_active = 1;
-		}
-	} else {
-		struct emac_rx_bd __iomem *tail_bd;
-		u32 frame_status;
-
-		tail_bd = rxch->active_queue_tail;
-		rxch->active_queue_tail = curr_bd;
-		tail_bd->next = curr_bd;
-		tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
-		tail_bd->h_next = emac_virt_to_phys(curr_bd, priv);
-		frame_status = tail_bd->mode;
-		if (frame_status & EMAC_CPPI_EOQ_BIT) {
-			emac_write(EMAC_RXHDP(ch),
-					emac_virt_to_phys(curr_bd, priv));
-			frame_status &= ~(EMAC_CPPI_EOQ_BIT);
-			tail_bd->mode = frame_status;
-			++rxch->end_of_queue_add;
-		}
-	}
-	++rxch->recycled_bd;
-}
-
-/**
- * emac_net_rx_cb: Prepares packet and sends to upper layer
- * @priv: The DaVinci EMAC private adapter structure
- * @net_pkt_list: Network packet list (received packets)
- *
- * Invalidates packet buffer memory and sends the received packet to upper
- * layer
- *
- * Returns success or appropriate error code (none as of now)
- */
-static int emac_net_rx_cb(struct emac_priv *priv,
-			  struct emac_netpktobj *net_pkt_list)
-{
-	struct sk_buff *p_skb;
-	p_skb = (struct sk_buff *)net_pkt_list->pkt_token;
-	/* set length of packet */
-	skb_put(p_skb, net_pkt_list->pkt_length);
-	p_skb->protocol = eth_type_trans(p_skb, priv->ndev);
-	netif_receive_skb(p_skb);
-	priv->net_dev_stats.rx_bytes += net_pkt_list->pkt_length;
-	priv->net_dev_stats.rx_packets++;
-	return 0;
-}
-
-/**
- * emac_rx_bdproc: RX buffer descriptor (packet) processing
- * @priv: The DaVinci EMAC private adapter structure
- * @ch: RX channel number to process buffer descriptors for
- * @budget: number of packets allowed to process
- * @pending: indication to caller that packets are pending to process
- *
- * Processes RX buffer descriptors - checks ownership bit on the RX buffer
- * descriptor, sends the receive packet to upper layer, allocates a new SKB
- * and recycles the buffer descriptor (requeues it in hardware RX queue).
- * Only "budget" number of packets are processed and indication of pending
- * packets provided to the caller.
- *
- * Returns number of packets processed (and indication of pending packets)
- */
-static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
-{
-	unsigned long flags;
-	u32 frame_status;
-	u32 pkts_processed = 0;
-	char *new_buffer;
-	struct emac_rx_bd __iomem *curr_bd;
-	struct emac_rx_bd __iomem *last_bd;
-	struct emac_netpktobj *curr_pkt, pkt_obj;
-	struct emac_netbufobj buf_obj;
-	struct emac_netbufobj *rx_buf_obj;
-	void *new_buf_token;
-	struct emac_rxch *rxch = priv->rxch[ch];
-
-	if (unlikely(1 == rxch->teardown_pending))
-		return 0;
-	++rxch->proc_count;
-	spin_lock_irqsave(&priv->rx_lock, flags);
-	pkt_obj.buf_list = &buf_obj;
-	curr_pkt = &pkt_obj;
-	curr_bd = rxch->active_queue_head;
-	BD_CACHE_INVALIDATE(curr_bd, EMAC_BD_LENGTH_FOR_CACHE);
-	frame_status = curr_bd->mode;
-
-	while ((curr_bd) &&
-	       ((frame_status & EMAC_CPPI_OWNERSHIP_BIT) == 0) &&
-	       (pkts_processed < budget)) {
-
-		new_buffer = emac_net_alloc_rx_buf(priv, rxch->buf_size,
-					&new_buf_token, EMAC_DEF_RX_CH);
-		if (unlikely(NULL == new_buffer)) {
-			++rxch->out_of_rx_buffers;
-			goto end_emac_rx_bdproc;
-		}
-
-		/* populate received packet data structure */
-		rx_buf_obj = &curr_pkt->buf_list[0];
-		rx_buf_obj->data_ptr = (char *)curr_bd->data_ptr;
-		rx_buf_obj->length = curr_bd->off_b_len & EMAC_RX_BD_BUF_SIZE;
-		rx_buf_obj->buf_token = curr_bd->buf_token;
-
-		dma_unmap_single(&priv->ndev->dev, curr_bd->buff_ptr,
-				curr_bd->off_b_len & EMAC_RX_BD_BUF_SIZE,
-				DMA_FROM_DEVICE);
-
-		curr_pkt->pkt_token = curr_pkt->buf_list->buf_token;
-		curr_pkt->num_bufs = 1;
-		curr_pkt->pkt_length =
-			(frame_status & EMAC_RX_BD_PKT_LENGTH_MASK);
-		emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd, priv));
-		++rxch->processed_bd;
-		last_bd = curr_bd;
-		curr_bd = last_bd->next;
-		rxch->active_queue_head = curr_bd;
-
-		/* check if end of RX queue ? */
-		if (frame_status & EMAC_CPPI_EOQ_BIT) {
-			if (curr_bd) {
-				++rxch->mis_queued_packets;
-				emac_write(EMAC_RXHDP(ch),
-					   emac_virt_to_phys(curr_bd, priv));
-			} else {
-				++rxch->end_of_queue;
-				rxch->queue_active = 0;
-			}
-		}
-
-		/* recycle BD */
-		emac_addbd_to_rx_queue(priv, ch, last_bd, new_buffer,
-				       new_buf_token);
-
-		/* return the packet to the user - BD ptr passed in
-		 * last parameter for potential *future* use */
-		spin_unlock_irqrestore(&priv->rx_lock, flags);
-		emac_net_rx_cb(priv, curr_pkt);
-		spin_lock_irqsave(&priv->rx_lock, flags);
-		curr_bd = rxch->active_queue_head;
-		if (curr_bd) {
-			BD_CACHE_INVALIDATE(curr_bd, EMAC_BD_LENGTH_FOR_CACHE);
-			frame_status = curr_bd->mode;
-		}
-		++pkts_processed;
-	}
-
-end_emac_rx_bdproc:
-	spin_unlock_irqrestore(&priv->rx_lock, flags);
-	return pkts_processed;
-}
-
-/**
  * emac_hw_enable: Enable EMAC hardware for packet transmission/reception
  * @priv: The DaVinci EMAC private adapter structure
  *
@@ -2578,8 +1653,6 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 	priv->ndev = ndev;
 	priv->msg_enable = netif_msg_init(debug_level, DAVINCI_EMAC_DEBUG);
 
-	spin_lock_init(&priv->tx_lock);
-	spin_lock_init(&priv->rx_lock);
 	spin_lock_init(&priv->lock);
 
 	pdata = pdev->dev.platform_data;
@@ -2624,8 +1697,6 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 	ndev->base_addr = (unsigned long)priv->remap_addr;
 
 	priv->ctrl_base = priv->remap_addr + pdata->ctrl_mod_reg_offset;
-	priv->ctrl_ram_size = pdata->ctrl_ram_size;
-	priv->emac_ctrl_ram = priv->remap_addr + pdata->ctrl_ram_offset;
 
 	hw_ram_addr = pdata->hw_ram_addr;
 	if (!hw_ram_addr)
-- 
1.7.0.4


From sshtylyov at mvista.com  Tue Aug  3 09:08:12 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 03 Aug 2010 18:08:12 +0400
Subject: [PATCH 2/2] DA850: move MII/RMII pin lists to the board file
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED1067@dbde02.ent.ti.com>
References: <201008012117.00730.sshtylyov@ru.mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A2B@dbde02.ent.ti.com>
	<4C56FD69.5070903@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED1067@dbde02.ent.ti.com>
Message-ID: <4C5822CC.5050805@mvista.com>

Nori, Sekhar wrote:

>> Hello.

>> Nori, Sekhar wrote:

>>>> The CPGMAC pin list in da850.c was incorrectly split into two MII/RMII mode
>>>> specific pin lists, while what pin group is used is a function of how the board
>>>> is wired.  Copy the pin lists to board-da850-evm.c, renaming them accordingly,
>>>> and merge the two lists in da850.c into one, da850_cpgmac_pins[], representing
>>>> the CPGMAC module as a whole...

>>> da850_cpgmac_pins[] is not going to be useful

>>     I know. Nevertheless, in da850.c we should have the generic pin lists, per
>> module. Not always useful, but that's the rule.

> If the common list is never going to be used, it should be removed to save bytes.

    I believe that would be the matter of another patch. CPGMAC pin list would 
not be the only one unused.

> Thanks,
> Sekhar

WBR, Sergei


From cyril at ti.com  Tue Aug  3 09:32:25 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue, 03 Aug 2010 10:32:25 -0400
Subject: [PATCH 2/8] davinci: add mdio platform devices
In-Reply-To: <4C58227A.4080502@compulab.co.il>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
	<1280842313-3743-3-git-send-email-cyril@ti.com>
	<4C58227A.4080502@compulab.co.il>
Message-ID: <4C582879.7060708@ti.com>

Hi Igor,

> Shouldn't arch/arm/mach-omap2/board-am3517evm.c be on your list?
> I think it should, or else it will be broken by:
> [PATCH 5/8] netdev: cleanup unused davinci mdio emac code

Correct.  As stated in the series summary:

> Additional omap tree patches will be required for am35xx as well
> (not included here).

Regards
Cyril.

From broonie at opensource.wolfsonmicro.com  Tue Aug  3 10:13:45 2010
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Tue, 3 Aug 2010 16:13:45 +0100
Subject: [PATCH 2/3] ASoC: DaVinci: Added support based on
	copy_from_user instead of DMA
In-Reply-To: <1279291619-5081-3-git-send-email-lamiaposta71@gmail.com>
References: <1279291619-5081-1-git-send-email-lamiaposta71@gmail.com>
	<1279291619-5081-3-git-send-email-lamiaposta71@gmail.com>
Message-ID: <20100803151345.GH25306@rakim.wolfsonmicro.main>

On Fri, Jul 16, 2010 at 04:46:58PM +0200, Raffaele Recalcati wrote:
> From: Davide Bonfanti <davide.bonfanti at bticino.it>
> 
>     This driver implements a pcm interface without the use of a DMA but with
>     a copy_from_user.
>     There's a buffer in the driver that is filled with davinci_pcm_copy.
>     When pcm is running, a TIMER interrupt is activated in order to fill
>     HW FIFO.
>     BUG: It happens sometimes that the peripheral stops working so there's a
>     trap.

Looking at this code the main thing that jumps out at me is that it
doesn't look at all DaVinci specific - all the interaction with the
hardware is hidden behind the ops structure you've defined, though the
ops structure doesn't define things like the maximum number of channels
and sample rate which I'd expect it to.  This suggests that either the
patch shouldn't be DaVinci specific or the splitting out of the ops
structure isn't adding anything.

> +int pointer_sub;

These should all be static.

> +int hw_fifo_size;
> +u16 *local_buffer;
> +static struct hrtimer hrtimer;
> +struct snd_pcm_substream *substream_loc;
> +int ns_for_interrupt = 1500000;

Magic number?

> +       gpio_set_value(69, 0);

Magic number again, and nothing requests this GPIO either.  Looks like
another thing for the ops structure.

From CHASE.KIM at ARROWASIA.COM  Tue Aug  3 11:00:28 2010
From: CHASE.KIM at ARROWASIA.COM (CHASE.KIM at ARROWASIA.COM)
Date: Wed, 4 Aug 2010 01:00:28 +0900
Subject: CHASE KIM/KR/AEKL/AAP is out of the office.
Message-ID: <OFD40CF1DC.4845549F-ON49257774.0057EF38@arrowasia.com>

I will be out of the office starting  2010-08-03 and will not return until
2010-08-06.

I will respond to your message when I return.


From nsekhar at ti.com  Tue Aug  3 11:43:54 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 3 Aug 2010 22:13:54 +0530
Subject: Touchscreen - MFD driver for TPS6507x family
In-Reply-To: <AANLkTin0kCKKSjse=Sbgsry_P-oUaTAmGHXRUL78W=Bu@mail.gmail.com>
References: <AANLkTikk0V460qb14nZeghWMzcPtPGu2_HzDHtc6rgQu@mail.gmail.com>
	<201006081014.33072.caglarakyuz@gmail.com>
	<1089858925.76837.1275989074229.JavaMail.open-xchange@oxltgw14.schlund.de>
	<201006081305.15022.caglarakyuz@gmail.com>
	<AANLkTikdT6O4f4GuD0Hwl6UIk5GS5EU2tAB6YB3lfT1N@mail.gmail.com>
	<903202309.136917.1276073978778.JavaMail.open-xchange@oxltgw02.schlund.de>
	<1276114677.21486.872.camel@sax-lx>
	<AANLkTi=pXq8f+X1+Y50zNmBkjPSEaSFDh0bjtcbYFwRy@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7E3A1DB@dbde02.ent.ti.com>
	<1280403790.22713.8.camel@sax-lx>
	<AANLkTinPagcWmk-oSxH7fsOx6cV5PksFuXyQf0ybLQMX@mail.gmail.com>
	<AANLkTimFCrcrTHP9p5PbBDn3CaJ6mnOU4KiSZ-YC1Lpx@mail.gmail.com>
	<1280416797.22713.502.camel@sax-lx>
	<AANLkTikMuo0Bv_w7JDLn+QivyF8aOSwdqapzRMxosH4t@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7E3AA61@dbde02.ent.ti.com>
	<AANLkTimU=-dnm+sTSLg1fQeZ4uYaXMJA=BQ5f_OESRyz@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A40@dbde02.ent.ti.com>
	<AANLkTin0kCKKSjse=Sbgsry_P-oUaTAmGHXRUL78W=Bu@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7F6E6A4@dbde02.ent.ti.com>

Hi Nicolas,

On Tue, Aug 03, 2010 at 01:21:14, Nicolas Luna wrote:
> Hi Sekhar,
>
> Yes there is an other device on the bus, but I removed it and I
> decreased the clock to 20khz. I cannot go below because the i2c seems
> not to work. It does solved the problem.
>
> I modified the driver to add a while(1) when it got an abnormal
> termination. I notified that every time the driver makes this error, I
> can see a clock stretch (with a scope) on the last i2c frame.
>
> - The PMIC (tps65070) is rated to work at 400khz, but even at 20khz it
> seems to need more time to response when it is addressed to much. I
> modified the touchscreen polling period to 100 msec and I still got
> errors. Maybe if the touchscreen driver was working by interruption that
> would leave a chance to the PMIC.

It should be possible to use an interrupt on a correctly wired hardware.
Can you try getting the interrupt mode working? Hopefully Todd or others
from list can help out in case you run into issues.

>
> - Why the i2c driver do not handles clock stretching?

It should and seems like there is a 1 second time out the driver has
waiting for transfer to complete. How long does the clock stretch in
your case? Please see DAVINCI_I2C_TIMEOUT in drivers/i2c/busses/i2c-davinci.c

> - On a test there was 2 successive reads to register 02h with a delay of
> 85 msec between. The first went right but while the next read, the salve
> put the clock low to stretch it. It sounds like a problem to me because
> the chip was not receiving a lot of messages and it stretched the clock.
> I cannot find any place in the datasheet that is talking about that
> issue.

Not sure regarding this. This will likely need some TPS hardware person to
analyze. Can you please post your observations to the PMU forum at:
http://e2e.ti.com/support/power_management/pmu/f/200.aspx

Thanks,
Sekhar


From luna.id at gmail.com  Tue Aug  3 13:36:17 2010
From: luna.id at gmail.com (Nicolas Luna)
Date: Tue, 3 Aug 2010 14:36:17 -0400
Subject: Touchscreen - MFD driver for TPS6507x family
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7F6E6A4@dbde02.ent.ti.com>
References: <AANLkTikk0V460qb14nZeghWMzcPtPGu2_HzDHtc6rgQu@mail.gmail.com>
	<201006081014.33072.caglarakyuz@gmail.com>
	<1089858925.76837.1275989074229.JavaMail.open-xchange@oxltgw14.schlund.de>
	<201006081305.15022.caglarakyuz@gmail.com>
	<AANLkTikdT6O4f4GuD0Hwl6UIk5GS5EU2tAB6YB3lfT1N@mail.gmail.com>
	<903202309.136917.1276073978778.JavaMail.open-xchange@oxltgw02.schlund.de>
	<1276114677.21486.872.camel@sax-lx>
	<AANLkTi=pXq8f+X1+Y50zNmBkjPSEaSFDh0bjtcbYFwRy@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7E3A1DB@dbde02.ent.ti.com>
	<1280403790.22713.8.camel@sax-lx>
	<AANLkTinPagcWmk-oSxH7fsOx6cV5PksFuXyQf0ybLQMX@mail.gmail.com>
	<AANLkTimFCrcrTHP9p5PbBDn3CaJ6mnOU4KiSZ-YC1Lpx@mail.gmail.com>
	<1280416797.22713.502.camel@sax-lx>
	<AANLkTikMuo0Bv_w7JDLn+QivyF8aOSwdqapzRMxosH4t@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7E3AA61@dbde02.ent.ti.com>
	<AANLkTimU=-dnm+sTSLg1fQeZ4uYaXMJA=BQ5f_OESRyz@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A40@dbde02.ent.ti.com>
	<AANLkTin0kCKKSjse=Sbgsry_P-oUaTAmGHXRUL78W=Bu@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7F6E6A4@dbde02.ent.ti.com>
Message-ID: <AANLkTimA18s6AvSUwtMoAfhCE9rQHNxeNzrgj0AZnYz2@mail.gmail.com>

Sekhar,


On Tue, Aug 3, 2010 at 12:43 PM, Nori, Sekhar <nsekhar at ti.com> wrote:

> Hi Nicolas,
>
> On Tue, Aug 03, 2010 at 01:21:14, Nicolas Luna wrote:
> > Hi Sekhar,
> >
> > Yes there is an other device on the bus, but I removed it and I
> > decreased the clock to 20khz. I cannot go below because the i2c seems
> > not to work. It does solved the problem.
> >
> > I modified the driver to add a while(1) when it got an abnormal
> > termination. I notified that every time the driver makes this error, I
> > can see a clock stretch (with a scope) on the last i2c frame.
> >
> > - The PMIC (tps65070) is rated to work at 400khz, but even at 20khz it
> > seems to need more time to response when it is addressed to much. I
> > modified the touchscreen polling period to 100 msec and I still got
> > errors. Maybe if the touchscreen driver was working by interruption that
> > would leave a chance to the PMIC.
>
> It should be possible to use an interrupt on a correctly wired hardware.
> Can you try getting the interrupt mode working? Hopefully Todd or others
> from list can help out in case you run into issues.
>

I'll see what I can do.


>
> >
> > - Why the i2c driver do not handles clock stretching?
>
> It should and seems like there is a 1 second time out the driver has
> waiting for transfer to complete. How long does the clock stretch in
> your case? Please see DAVINCI_I2C_TIMEOUT in
> drivers/i2c/busses/i2c-davinci.c
>

I already tried to change the I2C delay to more than 1 second and my
conclusion is that 1 second is really enough because even with more I had
errors. I think that the delay is not the problem there is something else
when the driver wait for completion. The max stretch I got was not more than
30 msec (when using 30msec polling period). I think that this is due to the
polling period. The touchscreen driver send an other request to the PMIC
even if the last one didn't finished.

*To summarize:*

1- The touchscreen driver should not send an other request if the last one
is not finish. (Interrupts could solve that issue)
2- It's sometime a little long to get a response from the PMIC (I dont know
exacly but it's more than 100msec) let see what TPS hardware person will
say.


>
> > - On a test there was 2 successive reads to register 02h with a delay of
> > 85 msec between. The first went right but while the next read, the salve
> > put the clock low to stretch it. It sounds like a problem to me because
> > the chip was not receiving a lot of messages and it stretched the clock.
> > I cannot find any place in the datasheet that is talking about that
> > issue.
>
> Not sure regarding this. This will likely need some TPS hardware person to
> analyze. Can you please post your observations to the PMU forum at:
> http://e2e.ti.com/support/power_management/pmu/f/200.aspx
>
>
Done.


> Thanks,
> Sekhar
>
>
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100803/8b149bd3/attachment.html>

From cyril at ti.com  Tue Aug  3 19:44:41 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue, 03 Aug 2010 20:44:41 -0400
Subject: [PATCH 1/8] netdev: separate out davinci mdio controller code
In-Reply-To: <27F9C60D11D683428E133F85D2BB4A53043F3C8C2A@dlee03.ent.ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
	<1280842313-3743-2-git-send-email-cyril@ti.com>
	<27F9C60D11D683428E133F85D2BB4A53043F3C8C2A@dlee03.ent.ti.com>
Message-ID: <4C58B7F9.6010608@ti.com>

Hi Omar,

[...]
>> +	while ((reg = __raw_readl(&regs->user[0].access)) & USERACCESS_GO)
>> +		;
> 
> potential infinite loop? I saw another place in your series using time_after, might fit in here too.
[...]
>> +	while ((__raw_readl(&regs->control) & CONTROL_IDLE) == 0)
>> +		;
> 
> Ditto

Thanks.  Will modify.

Regards
Cyril.

From cyril at ti.com  Tue Aug  3 19:46:41 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue, 03 Aug 2010 20:46:41 -0400
Subject: [PATCH 6/8] netdev: separate out davinci cpdma controller code
In-Reply-To: <27F9C60D11D683428E133F85D2BB4A53043F3C8C2B@dlee03.ent.ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
	<1280842313-3743-7-git-send-email-cyril@ti.com>
	<27F9C60D11D683428E133F85D2BB4A53043F3C8C2B@dlee03.ent.ti.com>
Message-ID: <4C58B871.8070107@ti.com>

Hi Omar,

[...]
>> +	if (ctlr->channels[chan_num])
>> +		goto err_chan_busy;
> 
> Mem leaking 'chan'
> 

Thanks.  Will modify for v2.

Regards
Cyril.

From cyril at ti.com  Tue Aug  3 20:04:16 2010
From: cyril at ti.com (Cyril Chemparathy)
Date: Tue,  3 Aug 2010 21:04:16 -0400
Subject: [PATCH] Davinci: tnetv107x: retain psc reg base after init
Message-ID: <1280883856-7844-1-git-send-email-cyril@ti.com>

This is a bugfix for the original tnetv107x submission series.  The psc_regs
base array was being discarded post-init, and this was causing a crash during
post-init clock enable/disable.

Signed-off-by: Cyril Chemparathy <cyril at ti.com>
---
 arch/arm/mach-davinci/tnetv107x.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
index 864e604..06d2ac9 100644
--- a/arch/arm/mach-davinci/tnetv107x.c
+++ b/arch/arm/mach-davinci/tnetv107x.c
@@ -104,7 +104,7 @@ static u32 pll_ext_freq[] = {
 };
 
 /* PSC control registers */
-static u32 psc_regs[] __initconst = { TNETV107X_PSC_BASE };
+static u32 psc_regs[] = { TNETV107X_PSC_BASE };
 
 /* Host map for interrupt controller */
 static u32 intc_host_map[] = { 0x01010000, 0x01010101, -1 };
-- 
1.7.0.4


From nsekhar at ti.com  Wed Aug  4 11:07:41 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 4 Aug 2010 21:37:41 +0530
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <4C56FF38.4090606@mvista.com>
References: <201008012115.16423.sshtylyov@ru.mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A21@dbde02.ent.ti.com>
	<4C56FF38.4090606@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7F6ED55@dbde02.ent.ti.com>

Hi Sergei,

On Mon, Aug 02, 2010 at 22:54:08, Sergei Shtylyov wrote:
> Hello.
>
> Nori, Sekhar wrote:
>
> > On Sun, Aug 01, 2010 at 22:45:16, Sergei Shtylyov wrote:
> >> The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
> >> specific
>
> > Have you come across any board which uses different set of pins?
>
>     I think you have been replied already.

'different' needs some qualification here. The minimum set of NAND pins required still
remains the same across all boards. 16-bit NANDs would require extra data pins which
can be defined on boards which use 16-bit NANDs (haven't seen many).

>
> > On NAND the ALE/CLE pins could (theoretically) be different on different boards
> > but as long as you are booting from NAND, you are stuck with the same address lines
> > as that used by ROM code.
>
>     And?

And so it makes sense to keep the minimum set of NAND pins in da850.c itself
instead of replicating for each board.

>
> > On NOR, a board with 8-bit NOR could probably do with less number of pins so may be
> > that could be included in the common list and the board file could optionally list
> > pins 8-15?
>
>     The "common" lists (in da8[35]0.c) were meant to be per-module lists, not
> per module function lists, so there could be no NAND/NOR lists there. Those
> lists are not always useful, I agree -- but that was the design.
>

Not sure if it's such a hard-and-fast rule. If space wastage is a concern, the
NAND and NOR lists could be defined as empty lists in case NAND/NOR is not built
in.

Thanks,
Sekhar


From lamiaposta71 at gmail.com  Wed Aug  4 11:26:14 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Wed,  4 Aug 2010 18:26:14 +0200
Subject: [PATCH v3] DaVinci: dm365: Added clockout2 management.
Message-ID: <1280939175-4764-1-git-send-email-lamiaposta71@gmail.com>

From: Davide Bonfanti <davide.bonfanti at bticino.it>

    Clockout2 is added as a child of pll1_sysclk9.
    A new dm365_clkout2_set_rate is used to set clockout2 frequency.

Signed-off-by: Davide Bonfanti <davide.bonfanti at bticino.it>
Signed-off-by: Raffaele Recalcati <raffaele.recalcati at bticino.it>
---
This patch has been developed against http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git and has been tested for dm365 cpu on BMX board.
This patch depends on the following one submitted to the mailing list:
https://patchwork.kernel.org/patch/112994
The clkout2 management has been introduced as leaf clock.
A fine tuning of clkout2 is possible using the following function
static int clkout2_fine_setting(unsigned long rate)
{
        struct clk *pll1_sysclk9;
        struct clk *clkout2;
        int i, err, min_err, i_min_err;
        int ret = -EINVAL;

        pll1_sysclk9 = clk_get(NULL, "pll1_sysclk9");
        if (IS_ERR(pll1_sysclk9)) {
                printk(KERN_ERR "Could not get pll1_sysclk9\n");
                return -ENODEV;
        }
        clk_enable(pll1_sysclk9);

        /* check all possibilities to get best fitting for the required freq */
        i_min_err = min_err = INT_MAX;
        for (i = 0x0F; i > 0; i--) {
                ret = clk_set_rate(pll1_sysclk9, rate * i);
                err = clk_get_rate(pll1_sysclk9) - rate * i;
                if (min_err > abs(err)) {
                        min_err = abs(err);
                        i_min_err = i;
                }
        }

        /* setting the best one to pll1_sysclk9 */
        ret = clk_set_rate(pll1_sysclk9, rate * i_min_err);
        if (ret)
                return ret;

        /* setting the best one to clkout2 */
        clkout2 = clk_get(NULL, "clkout2");
        if (IS_ERR(clkout2)) {
                printk(KERN_ERR "Could not get clkout2\n");
                return -ENODEV;
        }
        clk_enable(clkout2);
        clk_set_rate(clkout2,rate);
        return 0;
}


 arch/arm/mach-davinci/clock.h |    3 +++
 arch/arm/mach-davinci/dm365.c |   41 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
index a717d98..00c4497 100644
--- a/arch/arm/mach-davinci/clock.h
+++ b/arch/arm/mach-davinci/clock.h
@@ -50,6 +50,9 @@
 #define PLLDIV_EN       BIT(15)
 #define PLLDIV_RATIO_MASK 0x1f
 
+#define PERI_CLKCTL	0x48
+#define CLOCKOUT2EN	2
+
 /*
  * OMAP-L138 system reference guide recommends a wait for 4 OSCIN/CLKIN
  * cycles to ensure that the PLLC has switched to bypass mode. Delay of 1us
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 42fd4a4..4846b62 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -40,6 +40,38 @@
 #include "mux.h"
 
 #define DM365_REF_FREQ		24000000	/* 24 MHz on the DM365 EVM */
+#define DIV1_MASK		0x78		/* DIV1 mask in PERI_CLKCTL */
+
+int dm365_clkout2_set_rate(struct clk *clk, unsigned long rate)
+{
+	int i;
+	unsigned long input;
+	unsigned ratio;
+	u32 regval;
+	static void __iomem *system_module_base;
+
+	/* There must be a parent... */
+	if (WARN_ON(!clk->parent))
+		return 0;
+
+	input = clk->parent->rate;
+
+	if (input > rate)
+		ratio = DIV_ROUND_UP(input, rate) - 1;
+
+	system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
+	regval = __raw_readl(system_module_base + PERI_CLKCTL);
+	regval &= DIV1_MASK;
+	regval |= ratio << 3;
+
+	/* to make changes work stop CLOCKOUT & start it again */
+	regval |= 1 << CLOCKOUT2EN;
+	__raw_writel(regval, system_module_base + PERI_CLKCTL);
+	regval &= ~(1 << CLOCKOUT2EN);
+	__raw_writel(regval, system_module_base + PERI_CLKCTL);
+
+	return 0;
+}
 
 static struct pll_data pll1_data = {
 	.num		= 1,
@@ -124,6 +156,7 @@ static struct clk pll1_sysclk6 = {
 	.parent		= &pll1_clk,
 	.flags		= CLK_PLL,
 	.div_reg	= PLLDIV6,
+	.set_rate	= davinci_set_sysclk_rate,
 };
 
 static struct clk pll1_sysclk7 = {
@@ -145,6 +178,13 @@ static struct clk pll1_sysclk9 = {
 	.parent		= &pll1_clk,
 	.flags		= CLK_PLL,
 	.div_reg	= PLLDIV9,
+	.set_rate	= davinci_set_sysclk_rate,
+};
+
+static struct clk clkout2_clk = {
+	.name		= "clkout2",
+	.parent		= &pll1_sysclk9,
+	.set_rate       = dm365_clkout2_set_rate,
 };
 
 static struct clk pll2_clk = {
@@ -421,6 +461,7 @@ static struct clk_lookup dm365_clks[] = {
 	CLK(NULL, "pll1_sysclk7", &pll1_sysclk7),
 	CLK(NULL, "pll1_sysclk8", &pll1_sysclk8),
 	CLK(NULL, "pll1_sysclk9", &pll1_sysclk9),
+	CLK(NULL, "clkout2", &clkout2_clk),
 	CLK(NULL, "pll2", &pll2_clk),
 	CLK(NULL, "pll2_aux", &pll2_aux_clk),
 	CLK(NULL, "clkout1", &clkout1_clk),
-- 
1.7.0.4


From krunal.patil at einfochips.com  Thu Aug  5 00:22:21 2010
From: krunal.patil at einfochips.com (Krunal Patil)
Date: Thu, 5 Aug 2010 10:52:21 +0530 (IST)
Subject: test mail.
In-Reply-To: <1361711496.192706.1280985693670.JavaMail.root@ahm.einfochips.com>
Message-ID: <1401934804.192713.1280985741390.JavaMail.root@ahm.einfochips.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100805/b217b49c/attachment.html>

From krunal.patil at einfochips.com  Thu Aug  5 00:24:38 2010
From: krunal.patil at einfochips.com (Krunal Patil)
Date: Thu, 5 Aug 2010 10:54:38 +0530 (IST)
Subject: test mail.
Message-ID: <823608306.192728.1280985878202.JavaMail.root@ahm.einfochips.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100805/71f630bf/attachment.html>

From nsekhar at ti.com  Thu Aug  5 06:12:45 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 5 Aug 2010 16:42:45 +0530
Subject: [PATCH v3] DaVinci: dm365: Added clockout2 management.
In-Reply-To: <1280939175-4764-1-git-send-email-lamiaposta71@gmail.com>
References: <1280939175-4764-1-git-send-email-lamiaposta71@gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7F6F2A7@dbde02.ent.ti.com>

Hi Raffaele,

On Wed, Aug 04, 2010 at 21:56:14, Raffaele Recalcati wrote:
> From: Davide Bonfanti <davide.bonfanti at bticino.it>
>
>     Clockout2 is added as a child of pll1_sysclk9.
>     A new dm365_clkout2_set_rate is used to set clockout2 frequency.

I thought a recalculate rate function is needed as well?

>
> Signed-off-by: Davide Bonfanti <davide.bonfanti at bticino.it>
> Signed-off-by: Raffaele Recalcati <raffaele.recalcati at bticino.it>
> ---
> This patch has been developed against http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git and has been tested for dm365 cpu on BMX board.
> This patch depends on the following one submitted to the mailing list:
> https://patchwork.kernel.org/patch/112994
> The clkout2 management has been introduced as leaf clock.
> A fine tuning of clkout2 is possible using the following function
> static int clkout2_fine_setting(unsigned long rate)
> {
>         struct clk *pll1_sysclk9;
>         struct clk *clkout2;
>         int i, err, min_err, i_min_err;
>         int ret = -EINVAL;
>
>         pll1_sysclk9 = clk_get(NULL, "pll1_sysclk9");
>         if (IS_ERR(pll1_sysclk9)) {
>                 printk(KERN_ERR "Could not get pll1_sysclk9\n");
>                 return -ENODEV;
>         }
>         clk_enable(pll1_sysclk9);
>
>         /* check all possibilities to get best fitting for the required freq */
>         i_min_err = min_err = INT_MAX;
>         for (i = 0x0F; i > 0; i--) {
>                 ret = clk_set_rate(pll1_sysclk9, rate * i);
>                 err = clk_get_rate(pll1_sysclk9) - rate * i;
>                 if (min_err > abs(err)) {
>                         min_err = abs(err);
>                         i_min_err = i;
>                 }
>         }

Do you really need to go through like this? the same
'precision' should be achieved by DIV_ROUND_CLOSEST()
in the davinci_set_sysclk_rate() function if the max_rate
is passed for the sys clock.

Anyway, since my patch is not yet accepted and this code
is not included in the patch I won't bother you further
with my ideas :)

>
>         /* setting the best one to pll1_sysclk9 */
>         ret = clk_set_rate(pll1_sysclk9, rate * i_min_err);
>         if (ret)
>                 return ret;
>
>         /* setting the best one to clkout2 */
>         clkout2 = clk_get(NULL, "clkout2");
>         if (IS_ERR(clkout2)) {
>                 printk(KERN_ERR "Could not get clkout2\n");
>                 return -ENODEV;
>         }
>         clk_enable(clkout2);
>         clk_set_rate(clkout2,rate);
>         return 0;
> }
>
>
>  arch/arm/mach-davinci/clock.h |    3 +++
>  arch/arm/mach-davinci/dm365.c |   41 +++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 44 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/clock.h b/arch/arm/mach-davinci/clock.h
> index a717d98..00c4497 100644
> --- a/arch/arm/mach-davinci/clock.h
> +++ b/arch/arm/mach-davinci/clock.h
> @@ -50,6 +50,9 @@
>  #define PLLDIV_EN       BIT(15)
>  #define PLLDIV_RATIO_MASK 0x1f
>
> +#define PERI_CLKCTL  0x48
> +#define CLOCKOUT2EN  2

These defines need to be moved into dm365.c since they are only
used there.

> +
>  /*
>   * OMAP-L138 system reference guide recommends a wait for 4 OSCIN/CLKIN
>   * cycles to ensure that the PLLC has switched to bypass mode. Delay of 1us
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 42fd4a4..4846b62 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -40,6 +40,38 @@
>  #include "mux.h"
>
>  #define DM365_REF_FREQ               24000000        /* 24 MHz on the DM365 EVM */
> +#define DIV1_MASK            0x78            /* DIV1 mask in PERI_CLKCTL */
> +
> +int dm365_clkout2_set_rate(struct clk *clk, unsigned long rate)
> +{
> +     int i;
> +     unsigned long input;
> +     unsigned ratio;
> +     u32 regval;

Can you either use 'unsigned' or 'u32' instead of mixing them?

> +     static void __iomem *system_module_base;

Why does this have to be static?

> +
> +     /* There must be a parent... */
> +     if (WARN_ON(!clk->parent))
> +             return 0;

Should return -EINVAL?

> +
> +     input = clk->parent->rate;
> +
> +     if (input > rate)
> +             ratio = DIV_ROUND_UP(input, rate) - 1;
> +
> +     system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
> +     regval = __raw_readl(system_module_base + PERI_CLKCTL);
> +     regval &= DIV1_MASK;

regval &= ~DIV1_MASK;

> +     regval |= ratio << 3;

Looks like the same register supports setting clocks for voice codec
and keyscan module as well. This can cause a race if those clocks are
modified in a different context. Can you extend this function to cover
those clocks as well? May be clk->lpsc can be used to determine if div1,
div2 or div3 need to be changed. This way you can serialize the setting
up of these clocks.

> +
> +     /* to make changes work stop CLOCKOUT & start it again */
> +     regval |= 1 << CLOCKOUT2EN;

regval |= BIT(CLOCKOUT2EN) is more modern.

> +     __raw_writel(regval, system_module_base + PERI_CLKCTL);
> +     regval &= ~(1 << CLOCKOUT2EN);
> +     __raw_writel(regval, system_module_base + PERI_CLKCTL);
> +

Need to play nice and unmap system_module_base.

> +     return 0;
> +}
>
>  static struct pll_data pll1_data = {
>       .num            = 1,
> @@ -124,6 +156,7 @@ static struct clk pll1_sysclk6 = {
>       .parent         = &pll1_clk,
>       .flags          = CLK_PLL,
>       .div_reg        = PLLDIV6,
> +     .set_rate       = davinci_set_sysclk_rate,

Why is set_rate populated for sysclk6? Isn't clockout2 obtained
from sysclk9?

Thanks,
Sekhar


From nsekhar at ti.com  Thu Aug  5 09:44:45 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 5 Aug 2010 20:14:45 +0530
Subject: [PATCH] davinci: I2C: Adding bus frequency as module parameter
In-Reply-To: <1279788945-3643-1-git-send-email-vishwanath.k@ti.com>
References: <1279788945-3643-1-git-send-email-vishwanath.k@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E7F6F494@dbde02.ent.ti.com>

Hi Vishwanath,

On Thu, Jul 22, 2010 at 14:25:45, Kamalapur, Vishwanath wrote:
> From: vishwa <vishwanath.k at ti.com>
>
> With current implementation, when I2C is used as a module,
> for slave devices which operate at different frequencies,
> the bus frequency needs to be modified in the board
> configuration file and kernel needs to be re-built.
>
> This patch addresses this issue by adding bus frequency as
> module parameter.
>
> Signed-off-by: vishwa <vishwanath.k at ti.com>
> ---
>  drivers/i2c/busses/i2c-davinci.c |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
> index 2222c87..ba0817c 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -98,6 +98,13 @@
>  #define DAVINCI_I2C_IMR_NACK BIT(1)
>  #define DAVINCI_I2C_IMR_AL   BIT(0)
>
> +/*
> + * Following are the default values for the module parameters
> + * If user didn't specify the bus frequency, driver will
> + * take the bus freq from board configuration.
> + */

No need of this comment, I think.

> +static int i2c_davinci_busfreq;
> +
>  struct davinci_i2c_dev {
>       struct device           *dev;
>       void __iomem            *base;
> @@ -217,6 +224,9 @@ static void i2c_davinci_calc_clk_dividers(struct davinci_i2c_dev *dev)
>               psc++;  /* better to run under spec than over */
>       d = (psc >= 2) ? 5 : 7 - psc;
>
> +     if (i2c_davinci_busfreq != 0)
> +             pdata->bus_freq = i2c_davinci_busfreq;
> +

This is rather done in davinci_i2c_init() right after the pdata is sanitized.

>       clk = ((input_clock / (psc + 1)) / (pdata->bus_freq * 1000)) - (d << 1);
>       clkh = clk >> 1;
>       clkl = clk - clkh;
> @@ -818,6 +828,7 @@ static void __exit davinci_i2c_exit_driver(void)
>       platform_driver_unregister(&davinci_i2c_driver);
>  }
>  module_exit(davinci_i2c_exit_driver);
> +module_param(i2c_davinci_busfreq, int, 0);

Module parameters are usually defined at the beginning
of the file. Please add a MODULE_PARM_DESC() as well.

You can check drivers/mmc/host/davinci_mmc.c for an example.

Once done, please submit to I2C subsystem list and CC the I2C
maintainers and this list.

Thanks,
Sekhar


From lamiaposta71 at gmail.com  Thu Aug  5 09:45:53 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Thu, 5 Aug 2010 16:45:53 +0200
Subject: [PATCH v3] DaVinci: dm365: Added clockout2 management.
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7F6F2A7@dbde02.ent.ti.com>
References: <1280939175-4764-1-git-send-email-lamiaposta71@gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7F6F2A7@dbde02.ent.ti.com>
Message-ID: <AANLkTin+Th9Hc_15xFwK-EN2Cgcp8Lozv=rETkf8hpNH@mail.gmail.com>

2010/8/5 Nori, Sekhar <nsekhar at ti.com>

> Hi Raffaele,
>
> On Wed, Aug 04, 2010 at 21:56:14, Raffaele Recalcati wrote:
> > From: Davide Bonfanti <davide.bonfanti at bticino.it>
> >
> >     Clockout2 is added as a child of pll1_sysclk9.
> >     A new dm365_clkout2_set_rate is used to set clockout2 frequency.
>
> I thought a recalculate rate function is needed as well?
>

I don't know how to point to it in davinci_clk_init

                        /* Check if clock is a PLL */
                        if (clk->pll_data)
                                clk->recalc = clk_pllclk_recalc;

                        /* Else, if it is a PLL-derived clock */
                        else if (clk->flags & CLK_PLL)
                                clk->recalc = clk_sysclk_recalc;

                        /* Otherwise, it is a leaf clock (PSC clock) */
                        else if (clk->parent)
                                clk->recalc = clk_leafclk_recalc;

I need a new type?


>
> >
> > Signed-off-by: Davide Bonfanti <davide.bonfanti at bticino.it>
> > Signed-off-by: Raffaele Recalcati <raffaele.recalcati at bticino.it>
> > ---
> > This patch has been developed against
> http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.gitand has been tested for dm365 cpu on BMX board.
> > This patch depends on the following one submitted to the mailing list:
> > https://patchwork.kernel.org/patch/112994
> > The clkout2 management has been introduced as leaf clock.
> > A fine tuning of clkout2 is possible using the following function
> > static int clkout2_fine_setting(unsigned long rate)
> > {
> >         struct clk *pll1_sysclk9;
> >         struct clk *clkout2;
> >         int i, err, min_err, i_min_err;
> >         int ret = -EINVAL;
> >
> >         pll1_sysclk9 = clk_get(NULL, "pll1_sysclk9");
> >         if (IS_ERR(pll1_sysclk9)) {
> >                 printk(KERN_ERR "Could not get pll1_sysclk9\n");
> >                 return -ENODEV;
> >         }
> >         clk_enable(pll1_sysclk9);
> >
> >         /* check all possibilities to get best fitting for the required
> freq */
> >         i_min_err = min_err = INT_MAX;
> >         for (i = 0x0F; i > 0; i--) {
> >                 ret = clk_set_rate(pll1_sysclk9, rate * i);
> >                 err = clk_get_rate(pll1_sysclk9) - rate * i;
> >                 if (min_err > abs(err)) {
> >                         min_err = abs(err);
> >                         i_min_err = i;
> >                 }
> >         }
>
> Do you really need to go through like this? the same
> 'precision' should be achieved by DIV_ROUND_CLOSEST()
> in the davinci_set_sysclk_rate() function if the max_rate
> is passed for the sys clock.
>

I'll try do understand.


>
> Anyway, since my patch is not yet accepted and this code
> is not included in the patch I won't bother you further
> with my ideas :)
>

ok, no problem.


>
> >
> >         /* setting the best one to pll1_sysclk9 */
> >         ret = clk_set_rate(pll1_sysclk9, rate * i_min_err);
> >         if (ret)
> >                 return ret;
> >
> >         /* setting the best one to clkout2 */
> >         clkout2 = clk_get(NULL, "clkout2");
> >         if (IS_ERR(clkout2)) {
> >                 printk(KERN_ERR "Could not get clkout2\n");
> >                 return -ENODEV;
> >         }
> >         clk_enable(clkout2);
> >         clk_set_rate(clkout2,rate);
> >         return 0;
> > }
> >
> >
> >  arch/arm/mach-davinci/clock.h |    3 +++
> >  arch/arm/mach-davinci/dm365.c |   41
> +++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 44 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/clock.h
> b/arch/arm/mach-davinci/clock.h
> > index a717d98..00c4497 100644
> > --- a/arch/arm/mach-davinci/clock.h
> > +++ b/arch/arm/mach-davinci/clock.h
> > @@ -50,6 +50,9 @@
> >  #define PLLDIV_EN       BIT(15)
> >  #define PLLDIV_RATIO_MASK 0x1f
> >
> > +#define PERI_CLKCTL  0x48
> > +#define CLOCKOUT2EN  2
>
> These defines need to be moved into dm365.c since they are only
> used there.
>

done


> > +
> >  /*
> >   * OMAP-L138 system reference guide recommends a wait for 4 OSCIN/CLKIN
> >   * cycles to ensure that the PLLC has switched to bypass mode. Delay of
> 1us
> > diff --git a/arch/arm/mach-davinci/dm365.c
> b/arch/arm/mach-davinci/dm365.c
> > index 42fd4a4..4846b62 100644
> > --- a/arch/arm/mach-davinci/dm365.c
> > +++ b/arch/arm/mach-davinci/dm365.c
> > @@ -40,6 +40,38 @@
> >  #include "mux.h"
> >
> >  #define DM365_REF_FREQ               24000000        /* 24 MHz on the
> DM365 EVM */
> > +#define DIV1_MASK            0x78            /* DIV1 mask in PERI_CLKCTL
> */
> > +
> > +int dm365_clkout2_set_rate(struct clk *clk, unsigned long rate)
> > +{
> > +     int i;
> > +     unsigned long input;
> > +     unsigned ratio;
> > +     u32 regval;
>
> Can you either use 'unsigned' or 'u32' instead of mixing them?
>

> > +     static void __iomem *system_module_base;
>

> Why does this have to be static?
>

ok


>
> > +
> > +     /* There must be a parent... */
> > +     if (WARN_ON(!clk->parent))
> > +             return 0;
>
> Should return -EINVAL?
>

right


>
> > +
> > +     input = clk->parent->rate;
> > +
> > +     if (input > rate)
> > +             ratio = DIV_ROUND_UP(input, rate) - 1;
> > +
> > +     system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
> > +     regval = __raw_readl(system_module_base + PERI_CLKCTL);
> > +     regval &= DIV1_MASK;
>
> regval &= ~DIV1_MASK;
>

ops


>
> > +     regval |= ratio << 3;
>
> Looks like the same register supports setting clocks for voice codec
> and keyscan module as well. This can cause a race if those clocks are
> modified in a different context. Can you extend this function to cover
> those clocks as well? May be clk->lpsc can be used to determine if div1,
> div2 or div3 need to be changed. This way you can serialize the setting
> up of these clocks.
>

interesting.
I'm looking at davinci_psc_config, but I'm not sure to understand correctly.
I understand the race, but not what to do.


>
> > +
> > +     /* to make changes work stop CLOCKOUT & start it again */
> > +     regval |= 1 << CLOCKOUT2EN;
>
> regval |= BIT(CLOCKOUT2EN) is more modern.
>
> > +     __raw_writel(regval, system_module_base + PERI_CLKCTL);
> > +     regval &= ~(1 << CLOCKOUT2EN);
> > +     __raw_writel(regval, system_module_base + PERI_CLKCTL);
> > +
>
> Need to play nice and unmap system_module_base.
>

I'm sorry, I can't understand "play nice".


> > +     return 0;
> > +}
> >
> >  static struct pll_data pll1_data = {
> >       .num            = 1,
> > @@ -124,6 +156,7 @@ static struct clk pll1_sysclk6 = {
> >       .parent         = &pll1_clk,
> >       .flags          = CLK_PLL,
> >       .div_reg        = PLLDIV6,
> > +     .set_rate       = davinci_set_sysclk_rate,
>
> Why is set_rate populated for sysclk6? Isn't clockout2 obtained
> from sysclk9?
>

yes, but, I guess that Davide tought to provide a set_rate function also for
sysclk6.
By the way, now we are using you davinci_set_sysclk_rate and so I'll delete
this modification.


> Thanks,
> Sekhar
>
>

I'll be back from holiday the 23th of August.
In order to remember well the situation I send you today a new patch with
some modifications you are asking.
Below "---" I'll take track of TODO.

Thank you very much for your help.
Raffaele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100805/c7e716d0/attachment-0001.html>

From lamiaposta71 at gmail.com  Thu Aug  5 09:55:27 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Thu,  5 Aug 2010 16:55:27 +0200
Subject: [PATCH v4] DaVinci: dm365: Added clockout2 management.
Message-ID: <1281020128-5947-1-git-send-email-lamiaposta71@gmail.com>

From: Davide Bonfanti <davide.bonfanti at bticino.it>

    Clockout2 is added as a child of pll1_sysclk9.
    A new dm365_clkout2_set_rate is used to set clockout2 frequency.

Signed-off-by: Davide Bonfanti <davide.bonfanti at bticino.it>
Signed-off-by: Raffaele Recalcati <raffaele.recalcati at bticino.it>
---
This patch has been developed against 
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git 
and has been tested for dm365 cpu on BMX board.
This patch depends on the following one submitted to the mailing list:
https://patchwork.kernel.org/patch/112994

TODO LIST
-The clkout2 management needs a recalc function, but I by now I don't know how to
point to it from davinci_clk_init.
-The unmapping of system_module_base has to be checked.
-Solving a possible race when writing PERI_CLKCTL, see Nori Sekhar explanation:
"Looks like the same register supports setting clocks for voice codec
and keyscan module as well. This can cause a race if those clocks are
modified in a different context. Can you extend this function to cover
those clocks as well? May be clk->lpsc can be used to determine if div1,
div2 or div3 need to be changed. This way you can serialize the setting
up of these clocks."

A fine tuning of clkout2 is possible using the function below (it is 
possible to do something similar with Nori Sekhar work about DIV_ROUND_CLOSEST()
in the davinci_set_sysclk_rate() function (max_rate has to be passed).

static int clkout2_fine_setting(unsigned long rate)
{
        struct clk *pll1_sysclk9;
        struct clk *clkout2;
        int i, err, min_err, i_min_err;
        int ret = -EINVAL;

        pll1_sysclk9 = clk_get(NULL, "pll1_sysclk9");
        if (IS_ERR(pll1_sysclk9)) {
                printk(KERN_ERR "Could not get pll1_sysclk9\n");
                return -ENODEV;
        }
        clk_enable(pll1_sysclk9);

        /* check all possibilities to get best fitting for the required freq */
        i_min_err = min_err = INT_MAX;
        for (i = 0x0F; i > 0; i--) {
                ret = clk_set_rate(pll1_sysclk9, rate * i);
                err = clk_get_rate(pll1_sysclk9) - rate * i;
                if (min_err > abs(err)) {
                        min_err = abs(err);
                        i_min_err = i;
                }
        }

        /* setting the best one to pll1_sysclk9 */
        ret = clk_set_rate(pll1_sysclk9, rate * i_min_err);
        if (ret)
                return ret;

        /* setting the best one to clkout2 */
        clkout2 = clk_get(NULL, "clkout2");
        if (IS_ERR(clkout2)) {
                printk(KERN_ERR "Could not get clkout2\n");
                return -ENODEV;
        }
        clk_enable(clkout2);
        clk_set_rate(clkout2,rate);
        return 0;
}



 arch/arm/mach-davinci/dm365.c |   42 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 42fd4a4..0101a6c 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -40,6 +40,40 @@
 #include "mux.h"
 
 #define DM365_REF_FREQ		24000000	/* 24 MHz on the DM365 EVM */
+#define DIV1_MASK		0x78		/* DIV1 mask in PERI_CLKCTL */
+#define PERI_CLKCTL		0x48
+#define CLOCKOUT2EN		2
+
+int dm365_clkout2_set_rate(struct clk *clk, unsigned long rate)
+{
+	int i;
+	unsigned long input;
+	unsigned ratio;
+	unsigned regval;
+	void __iomem *system_module_base;
+
+	/* There must be a parent... */
+	if (WARN_ON(!clk->parent))
+		return -EINVAL;
+
+	input = clk->parent->rate;
+
+	if (input > rate)
+		ratio = DIV_ROUND_UP(input, rate) - 1;
+
+	system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
+	regval = __raw_readl(system_module_base + PERI_CLKCTL);
+	regval &= ~DIV1_MASK;
+	regval |= ratio << 3;
+
+	/* to make changes work stop CLOCKOUT & start it again */
+	regval |= BIT(CLOCKOUT2EN);
+	__raw_writel(regval, system_module_base + PERI_CLKCTL);
+	regval &= ~(1 << CLOCKOUT2EN);
+	__raw_writel(regval, system_module_base + PERI_CLKCTL);
+	iounmap(system_module_base);
+	return 0;
+}
 
 static struct pll_data pll1_data = {
 	.num		= 1,
@@ -145,6 +179,13 @@ static struct clk pll1_sysclk9 = {
 	.parent		= &pll1_clk,
 	.flags		= CLK_PLL,
 	.div_reg	= PLLDIV9,
+	.set_rate	= davinci_set_sysclk_rate,
+};
+
+static struct clk clkout2_clk = {
+	.name		= "clkout2",
+	.parent		= &pll1_sysclk9,
+	.set_rate       = dm365_clkout2_set_rate,
 };
 
 static struct clk pll2_clk = {
@@ -421,6 +462,7 @@ static struct clk_lookup dm365_clks[] = {
 	CLK(NULL, "pll1_sysclk7", &pll1_sysclk7),
 	CLK(NULL, "pll1_sysclk8", &pll1_sysclk8),
 	CLK(NULL, "pll1_sysclk9", &pll1_sysclk9),
+	CLK(NULL, "clkout2", &clkout2_clk),
 	CLK(NULL, "pll2", &pll2_clk),
 	CLK(NULL, "pll2_aux", &pll2_aux_clk),
 	CLK(NULL, "clkout1", &clkout1_clk),
-- 
1.7.0.4


From pchevalier at imajing.fr  Thu Aug  5 10:38:58 2010
From: pchevalier at imajing.fr (Pierre)
Date: Thu, 05 Aug 2010 17:38:58 +0200
Subject: Linux Usb key and Fat buffer.
Message-ID: <4C5ADB12.9080606@imajing.fr>

<www.imajing.fr>Hi all,

I am wondering how writing to an USB key formated as FAT32 filesystem is 
handle by linux ( we are using linux 2.6.18 on a dm355 ).

We have our embedded system that is logging binary data from different 
sensors, and images, our total number of files open is around 7.

We have 6 files opened for writing small chunks of data (total of small 
chunk bitrate 8k per second ) and an avi files that we are using as a 
container for 5Mpx jpeg images (500k) at 5fps. When we test the key's 
performance we have 7MB per second  (writing 100 chunks of 500k data) so 
the performance of the key should be enough for storing our data.
The problem is that we are expriencing a peridodic slow down of the 
writing speed of the images. We have not mounted the key as physically 
synchronised.

My question is :
- How is handled the writing buffer to usb key ?
- What is the buffer size when writing to fat ? (I didn't find an option 
for that in the mount option)
- Should i use in my application a fifo buffer for writing data to avoid 
the slow down?

Thanks.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100805/3efafe2c/attachment.html>

From khilman at deeprootsystems.com  Thu Aug  5 12:21:20 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 10:21:20 -0700
Subject: [GIT PULL] davinci updates for 2.6.36
Message-ID: <87ocdhvuun.fsf@deeprootsystems.com>

Linus,

Here are the updates for the DaVinci family of ARM-based SoCs for 2.6.36.

The bulk of this is the addition of the core support for a new SoC in
the family: the tnetv107x.

Also, This was recently rebased to drop the addition of another ARM
defconfig from the original tnetv series as well as to address a
conflict discovered in linux-next.

Kevin


The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02:

  Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-for-linus

Cyril Chemparathy (5):
      Davinci: generalized debug macros
      Davinci: tnetv107x decompresser uart definitions
      Davinci: tnetv107x soc support
      Davinci: tnetv107x initial gpio support
      Davinci: tnetv107x evm board initial support

Rajashekhara, Sudhakar (3):
      davinci: support for EDMA resource sharing
      davinci: da8xx/omapl EVM: Specify reserved channels/slots
      davinci: dm646x EVM: Specify reserved EDMA channel/slots

Sekhar Nori (2):
      davinci: da8xx: sparse cleanup: remove duplicate entries in irq priorities
      davinci: edma: provide ability to detect insufficient CC info data

Thomas Koeller (1):
      davinci: DM365: fixed second serial port

 arch/arm/mach-davinci/Kconfig                    |   12 +
 arch/arm/mach-davinci/Makefile                   |    3 +
 arch/arm/mach-davinci/board-da830-evm.c          |   32 +-
 arch/arm/mach-davinci/board-da850-evm.c          |   52 ++-
 arch/arm/mach-davinci/board-dm646x-evm.c         |   35 +
 arch/arm/mach-davinci/board-tnetv107x-evm.c      |  174 +++++
 arch/arm/mach-davinci/da830.c                    |    5 -
 arch/arm/mach-davinci/da850.c                    |   25 -
 arch/arm/mach-davinci/devices-da8xx.c            |   50 +-
 arch/arm/mach-davinci/devices-tnetv107x.c        |  320 +++++++++
 arch/arm/mach-davinci/dm355.c                    |   22 +-
 arch/arm/mach-davinci/dm365.c                    |   28 +-
 arch/arm/mach-davinci/dm644x.c                   |   22 +-
 arch/arm/mach-davinci/dm646x.c                   |   30 +-
 arch/arm/mach-davinci/dma.c                      |   62 ++-
 arch/arm/mach-davinci/gpio-tnetv107x.c           |  205 ++++++
 arch/arm/mach-davinci/include/mach/da8xx.h       |    3 +-
 arch/arm/mach-davinci/include/mach/debug-macro.S |   50 ++-
 arch/arm/mach-davinci/include/mach/dm646x.h      |    1 +
 arch/arm/mach-davinci/include/mach/edma.h        |   11 +
 arch/arm/mach-davinci/include/mach/gpio.h        |   22 +-
 arch/arm/mach-davinci/include/mach/serial.h      |   21 +
 arch/arm/mach-davinci/include/mach/tnetv107x.h   |   55 ++
 arch/arm/mach-davinci/include/mach/uncompress.h  |   87 ++-
 arch/arm/mach-davinci/tnetv107x.c                |  753 ++++++++++++++++++++++
 25 files changed, 1933 insertions(+), 147 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-tnetv107x-evm.c
 create mode 100644 arch/arm/mach-davinci/devices-tnetv107x.c
 create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c
 create mode 100644 arch/arm/mach-davinci/include/mach/tnetv107x.h
 create mode 100644 arch/arm/mach-davinci/tnetv107x.c

From khilman at deeprootsystems.com  Thu Aug  5 13:02:12 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 11:02:12 -0700
Subject: [PATCH 1/2] davinci: clean up inconsistent usage of spaces in
	Kconfig
In-Reply-To: <1277991050-5218-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's
	message of "Thu, 1 Jul 2010 19:00:49 +0530")
References: <1277991050-5218-1-git-send-email-nsekhar@ti.com>
Message-ID: <87fwytvsyj.fsf@deeprootsystems.com>

Sekhar Nori <nsekhar at ti.com> writes:

> In arch/arm/mach-davinci/Kconfig, some of the configuration
> items are indented with multiple spaces instead of tabs.
>
> Also, in couple of places, two spaces are used in the middle
> of help text where one should do.
>
> This patch fixes both issues.
>
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>

Thanks, applying, queuing this series for next merge window (2.6.37)

Kevin

> ---
> This patch triggers a non-relevant checkpatch warning because of insufficient
> help text for DAVINCI_MUX_DEBUG.
>
>  arch/arm/mach-davinci/Kconfig |   32 ++++++++++++++++----------------
>  1 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 71f90f8..b291da1 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -20,17 +20,17 @@ config ARCH_DAVINCI_DM644x
>  	select ARCH_DAVINCI_DMx
>  
>  config ARCH_DAVINCI_DM355
> -        bool "DaVinci 355 based system"
> +	bool "DaVinci 355 based system"
>  	select AINTC
>  	select ARCH_DAVINCI_DMx
>  
>  config ARCH_DAVINCI_DM646x
> -        bool "DaVinci 646x based system"
> +	bool "DaVinci 646x based system"
>  	select AINTC
>  	select ARCH_DAVINCI_DMx
>  
>  config ARCH_DAVINCI_DA830
> -        bool "DA830/OMAP-L137 based system"
> +	bool "DA830/OMAP-L137 based system"
>  	select CP_INTC
>  	select ARCH_DAVINCI_DA8XX
>  	select CPU_DCACHE_WRITETHROUGH # needed on silicon revs 1.0, 1.1
> @@ -140,7 +140,7 @@ config DA830_UI_LCD
>  config DA830_UI_NAND
>  	bool "NAND flash"
>  	help
> -	  Say Y here to use the NAND flash.  Do not forget to setup
> +	  Say Y here to use the NAND flash. Do not forget to setup
>  	  the switch correctly.
>  endchoice
>  
> @@ -195,20 +195,20 @@ config DAVINCI_MUX
>  	  say Y.
>  
>  config DAVINCI_MUX_DEBUG
> -        bool "Multiplexing debug output"
> -        depends on DAVINCI_MUX
> -        help
> -          Makes the multiplexing functions print out a lot of debug info.
> -          This is useful if you want to find out the correct values of the
> -          multiplexing registers.
> +	bool "Multiplexing debug output"
> +	depends on DAVINCI_MUX
> +	help
> +	  Makes the multiplexing functions print out a lot of debug info.
> +	  This is useful if you want to find out the correct values of the
> +	  multiplexing registers.
>  
>  config DAVINCI_MUX_WARNINGS
> -        bool "Warn about pins the bootloader didn't set up"
> -        depends on DAVINCI_MUX
> -        help
> -          Choose Y here to warn whenever driver initialization logic needs
> -          to change the pin multiplexing setup.  When there are no warnings
> -          printed, it's safe to deselect DAVINCI_MUX for your product.
> +	bool "Warn about pins the bootloader didn't set up"
> +	depends on DAVINCI_MUX
> +	help
> +	  Choose Y here to warn whenever driver initialization logic needs
> +	  to change the pin multiplexing setup. When there are no warnings
> +	  printed, it's safe to deselect DAVINCI_MUX for your product.
>  
>  config DAVINCI_RESET_CLOCKS
>  	bool "Reset unused clocks during boot"

From khilman at deeprootsystems.com  Thu Aug  5 13:20:13 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 11:20:13 -0700
Subject: [PATCH v2 1/6] davinci: add support for aemif timing configuration
In-Reply-To: <1278410661-18211-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's
	message of "Tue, 6 Jul 2010 15:34:16 +0530")
References: <1278410661-18211-1-git-send-email-nsekhar@ti.com>
Message-ID: <871vacx6oy.fsf@deeprootsystems.com>

Sekhar Nori <nsekhar at ti.com> writes:

> This patch adds support to configure the AEMIF interface
> with supplied timing values.
>
> Since this capability is useful both from NOR and NAND
> flashes, it is provided as a new interface and in a file
> of its own.
>
> AEMIF timing configuration is required in cases:
>
> 1) Where the AEMIF clock rate can change at runtime (a side
>    affect of cpu frequency change).
>
> 2) Where U-Boot does not support NAND/NOR but supports other
>    media like SPI Flash or MMC/SD and thus does not care about
>    setting up the AEMIF timing for kernel to use.
>
> 3) Where U-Boot just hasn't configured the timing values and
>    cannot be upgraded because the box is already in the field.
>
> Since there is now a header file for AEMIF interface, the
> common (non-NAND specific) defines for AEMIF registers have
> been moved from nand.h into the newly created aemif.h
>
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>

This series looks great, and is a very nice cleanup.  Also, those
performance improvments are pretty impressive.

Apart from the minor comment below (which I can fixup myself if you
approve), I'll apply this whole series.

[...]

> +
> +#define TIMING_MASK	(TA(TA_MAX) | \
> +				RHOLD(RHOLD_MAX) | \
> +				RSTROBE(RSTROBE_MAX) |	\
> +				RSETUP(RSETUP_MAX) | \
> +				WHOLD(WHOLD_MAX) | \
> +				WSTROBE(WSTROBE_MAX) | \
> +				WSETUP(WSETUP_MAX))
> +
> +#define NS_IN_KHZ	1000000

Minor nit: <linux/time.h> already nas NSEC_PER_MSEC, can use that instead.

Kevin

From khilman at deeprootsystems.com  Thu Aug  5 13:22:45 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 11:22:45 -0700
Subject: [PATCH 1/2] davinci: am18x/da850/omap-l138: use 'NOM' voltage
	defined in datasheet as min voltage
In-Reply-To: <1278491570-11832-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's
	message of "Wed, 7 Jul 2010 14:02:49 +0530")
References: <1278491570-11832-1-git-send-email-nsekhar@ti.com>
Message-ID: <87sk2svs0a.fsf@deeprootsystems.com>

Sekhar Nori <nsekhar at ti.com> writes:

> For each DA850 OPP, the normal ('NOM') voltage defined in the tecnical
> reference manual (TRM) is actually the minimum voltage the frequency
> is supported at.
>
> The minimum ('MIN') voltage defined in TRM is meant to take care of
> voltage fluctuations and the device should not be run at this voltage
> for extended periods of time.
>
> Fix the OPP definitions to define the cvdd_min as the normal voltage
> defined in the datasheet.
>
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>

OK, applying 1/2.

Kevin

> ---
>  arch/arm/mach-davinci/da850.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 6b8331b..a275e8b 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -876,7 +876,7 @@ static const struct da850_opp da850_opp_300 = {
>  	.prediv		= 1,
>  	.mult		= 25,
>  	.postdiv	= 2,
> -	.cvdd_min	= 1140000,
> +	.cvdd_min	= 1200000,
>  	.cvdd_max	= 1320000,
>  };
>  
> @@ -885,7 +885,7 @@ static const struct da850_opp da850_opp_200 = {
>  	.prediv		= 1,
>  	.mult		= 25,
>  	.postdiv	= 3,
> -	.cvdd_min	= 1050000,
> +	.cvdd_min	= 1100000,
>  	.cvdd_max	= 1160000,
>  };
>  
> @@ -894,7 +894,7 @@ static const struct da850_opp da850_opp_96 = {
>  	.prediv		= 1,
>  	.mult		= 20,
>  	.postdiv	= 5,
> -	.cvdd_min	= 950000,
> +	.cvdd_min	= 1000000,
>  	.cvdd_max	= 1050000,
>  };

From khilman at deeprootsystems.com  Thu Aug  5 13:26:40 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 11:26:40 -0700
Subject: [PATCH 2/2] davinci: am18x/da850/omap-l138: add support for
	higher frequencies
In-Reply-To: <1278491570-11832-2-git-send-email-nsekhar@ti.com> (Sekhar Nori's
	message of "Wed, 7 Jul 2010 14:02:50 +0530")
References: <1278491570-11832-1-git-send-email-nsekhar@ti.com>
	<1278491570-11832-2-git-send-email-nsekhar@ti.com>
Message-ID: <87d3twvrtr.fsf@deeprootsystems.com>

Sekhar Nori <nsekhar at ti.com> writes:

> AM18x/DA850/OMAP-L138 SoCs have variants that can operate
> at a maximum of 456 MHz at 1.3V operating point. Also the
> 1.2V operating point has a variant that can support a maximum
> of 372 MHz.
>
> This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz)
> to the list of DA850 OPPs.
>
> Not all silicon is qualified to run at higher speeds and
> unfortunately the maximum speed the chip can support can only
> be read from the label on the package (not software readable).

doh

> Because of this, kernel configuration options have been
> introduced to help users enable higher speeds if they know
> that their slicon can support the higher speed.

I don't like introducing Kconfig options for this kind of thing.  

For example, what if you want one kernel binary to support different
speed-qualified parts?

I'd rather have this configurable at runtime using the board files.
Make the default the common speed, and folks with parts with higher
qualified chips can make changes in their board file.

Kevin

From khilman at deeprootsystems.com  Thu Aug  5 13:35:30 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 11:35:30 -0700
Subject: [PATCH v3] mtd-nand: davinci: correct 4-bit error correction
In-Reply-To: <1279521506-4537-1-git-send-email-sudhakar.raj@ti.com> (Sudhakar
	Rajashekhara's message of "Mon, 19 Jul 2010 12:08:26 +0530")
References: <1279521506-4537-1-git-send-email-sudhakar.raj@ti.com>
Message-ID: <878w4kvrf1.fsf@deeprootsystems.com>

Sudhakar Rajashekhara <sudhakar.raj at ti.com> writes:

> On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
> 4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
> before waiting for the NAND Flash status register to be equal to 1, 2 or
> 3, we have to wait till the ECC HW goes to correction state.  Without this
> wait, ECC correction calculations will not be proper.
>
> This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
> EVMs.
>
> Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
> Acked-by: Sneha Narnakaje <nsnehaprabha at ti.com>
> Cc: David Woodhouse <dwmw2 at infradead.org>
> Signed-off-by: Andrew Morton <akpm at linux-foundation.org>

Acked-by: Kevin Hilman <khilman at deeprootsystems.com>


From khilman at deeprootsystems.com  Thu Aug  5 13:44:33 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 11:44:33 -0700
Subject: [PATCH 1/4] davinci: cpufreq: bailout on regulator errors
In-Reply-To: <1279624611-8255-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's
	message of "Tue, 20 Jul 2010 16:46:48 +0530")
References: <1279624611-8255-1-git-send-email-nsekhar@ti.com>
Message-ID: <8739usvqzy.fsf@deeprootsystems.com>

Sekhar Nori <nsekhar at ti.com> writes:

> Current cpufreq code does not consider errors that can occur while
> changing voltage. Code to increase CPU  frequency goes ahead even in
> the case the regulator has failed to increase the voltage. This leads
> to hard error since lower voltages cannot support increased frequency.
>
> Prevent this by not increasing frequency in case increasing voltage
> is not successful.
>
> Also, do not lower the voltage if changing the cpu frequency has failed
> for some reason.
>
> Note that we do not return error on failure to decrease voltage as
> that is not a hard error.
>
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>

Series looks good.

Applying the whole series after doing the 'ratio--' change locally as
suggested by Sergei.

Kevin

From khilman at deeprootsystems.com  Thu Aug  5 14:01:12 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 12:01:12 -0700
Subject: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <4C4D8449.9040706@criticallink.com> (Michael Williamson's message
	of "Mon, 26 Jul 2010 08:49:13 -0400")
References: <4C45AE5E.7070905@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7D0AF64@dbde02.ent.ti.com>
	<4C4D8449.9040706@criticallink.com>
Message-ID: <87mxt0ubnr.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

>  On 7/26/2010 5:29 AM, Nori, Sekhar wrote:
>
>>
>> Hi Michael,
>>
>> On Tue, Jul 20, 2010 at 19:40:38, Michael Williamson wrote:
>>>  This patch adds support for the MityDSP-L138 and MityARM-1808 system on
>>> module (SOM) under the registered machine "mityomapl138".  These SOMs
>>> are based on the da850 davinci CPU architecture.  Information on these
>>> SOMs may be found at http://www.mitydsp.com.
>>>
>>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>>> ---
>>
>> [...]
>>
>>>
>>>  arch/arm/configs/da8xx_omapl_defconfig             |  291 ++++++--
>>>  arch/arm/include/asm/setup.h                       |    5 +
>>>  arch/arm/mach-davinci/Kconfig                      |    7 +
>>>  arch/arm/mach-davinci/Makefile                     |    1 +
>>>  arch/arm/mach-davinci/board-mityomapl138.c         |  793 ++++++++++++++++++++
>>>  .../mach-davinci/include/mach/cb-mityomapl138.h    |  125 +++
>>>  arch/arm/mach-davinci/include/mach/da8xx.h         |    1 +
>>>  arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
>>>  8 files changed, 1181 insertions(+), 43 deletions(-)
>>>
>>
>> [...]
>>
>>> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
>>> index f392fb4..d6b1a47 100644
>>> --- a/arch/arm/include/asm/setup.h
>>> +++ b/arch/arm/include/asm/setup.h
>>> @@ -143,6 +143,11 @@ struct tag_memclk {
>>>      __u32 fmemclk;
>>>  };
>>>
>>> +/** MityDSP-L138 peripheral configuration info,
>>> +  *  see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
>>> +  */
>>> +#define ATAG_PERIPHERALS 0x42000101
>>
>> Instead of naming this so generic, can you call this ATAG_MITYDSPL138 or
>> something like that?
>
>
>
> Yes.  I would be glad to rename it, assuming some other approach is not
> used instead.
>
>>
>> Since passing peripheral configuration from bootloader is a first for
>> DaVinci, can you please explain why this is the best suited method for this
>> board and why methods used on other boards wont work?
>>
>
>
>
> Well, the problem we are struggling with is that we'd like to avoid
> generating a pile of separate machine types for the different boards
> that are needed to support for this common SOM part with regards
> to the peripheral selection.  There are already have 4 different
> boards with slightly different peripherals already being used with this SOM,
> and it's a challenge enough just to try to get one configuration through
> this cycle (which I am new to).  We are expecting many more (10's per
> year). 
>
> In general, the only real difference on any of these boards will be in regards
> to peripheral selection/configuration.  E.G., using RMII vs. MII, or using
> different McASP pins or different numbers of channels, or adding a couple
> of SPI devices on different chip selects, LCD settings, etc. 
> Seems like we shouldn't need to make a whole new machine up to support
> these kinds of things. 
>
> This came up in a thread on this mailing list, see
>
> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17042.html
>
> The approach here was pretty much what Kevin suggested as an alternate
> to trying to port a flat device tree implementation like the powerpc
> folks use.  The only difference was that I didn't think I could jam
> everything I wanted onto the kernel command line without it getting out
> of hand, so I am proposing a separate ATAG to provide the peripheral
> configuration.  It's not perfect, but I wanted to get something out
> there as if it's rejected then we only have a few boards to rewrite code
> for.
>
> Other than device trees, the only other approaches I've seen so far to
> sort out altering peripheral configuration is:
>
> a) Make a new board (a new board file, etc., KConfig option, etc.)
>
> b) Start in with a pile of #ifdefs, etc., and add a lot of peripheral
> on/off options to the KConfig/Make system.  That means supporting
> many variants of kernels for the different host boards, not
> just an EVM.  I'd like to avoid that if I could, as the regression
> testing for new options might get out of hand.  And it didn't seem
> consistent with making a flexible kernel.
>
> c) Allow peripheral drivers to probe and initialize pins, etc. in the
> modules, then load the right drivers up for your board.  There are a lot
> of threads about why letting drivers mess with the pins is bad.  So this
> is a non-starter.

d) use ATAG_REVISION and a single board file

There is currently a tag called ATAG_REVISION which sets a global
variable 'system_rev' based on this tagq.  This tag was intended for
exactly this purpose.

You can then have a single machine type, a single board file and the
boot loader can change ATAG_REVISION based on the board specifics.  The
board file can then check 'system_rev' and handle specifics that way.

This is also much clearer as all the things that are unique to that
board will be contained in the board file and not hidden away in the
bootloader.

Kevin

From khilman at deeprootsystems.com  Thu Aug  5 14:06:34 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 12:06:34 -0700
Subject: [PATCH] Davinci: tnetv107x: retain psc reg base after init
In-Reply-To: <1280883856-7844-1-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Tue, 3 Aug 2010 21:04:16 -0400")
References: <1280883856-7844-1-git-send-email-cyril@ti.com>
Message-ID: <87hbj8ubet.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> This is a bugfix for the original tnetv107x submission series.  The psc_regs
> base array was being discarded post-init, and this was causing a crash during
> post-init clock enable/disable.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>

Thanks, will queue for 2.6.36-rc.

Kevin

> ---
>  arch/arm/mach-davinci/tnetv107x.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
> index 864e604..06d2ac9 100644
> --- a/arch/arm/mach-davinci/tnetv107x.c
> +++ b/arch/arm/mach-davinci/tnetv107x.c
> @@ -104,7 +104,7 @@ static u32 pll_ext_freq[] = {
>  };
>  
>  /* PSC control registers */
> -static u32 psc_regs[] __initconst = { TNETV107X_PSC_BASE };
> +static u32 psc_regs[] = { TNETV107X_PSC_BASE };
>  
>  /* Host map for interrupt controller */
>  static u32 intc_host_map[] = { 0x01010000, 0x01010101, -1 };

From khilman at deeprootsystems.com  Thu Aug  5 14:17:42 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 12:17:42 -0700
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <201008012115.16423.sshtylyov@ru.mvista.com> (Sergei Shtylyov's
	message of "Sun, 1 Aug 2010 21:15:16 +0400")
References: <201008012115.16423.sshtylyov@ru.mvista.com>
Message-ID: <8739usuaw9.fsf@deeprootsystems.com>

Sergei Shtylyov <sshtylyov at ru.mvista.com> writes:

> The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
> specific and as such shouldn't be in da850.c -- copy them to board-da850-evm.c,
> renaming to da850_evm_nand_pins/da850_evm_nor_pins respectively, and merge the
> two lists in da850.c into one, representing the EMIF 2.5 module as a whole, 
> just like we have it in da830.c...
>
> While at it, remove the '__init' modifier from da850_evm_setup_nor_nand() as
> this function is called from non '__init' code...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>
> ---
> The patch is against the recent DaVinci tree. It has only been build-tested as
> I don't have DA850 EVM board...

I'm OK with this series, but would like to see some test reports on
da850-evm using nand and nor using this before I apply it.

Kevin

>  arch/arm/mach-davinci/board-da850-evm.c    |   30 ++++++++++++++++++++++++---
>  arch/arm/mach-davinci/da850.c              |   32 ++++++++++-------------------
>  arch/arm/mach-davinci/include/mach/da8xx.h |    3 --
>  3 files changed, 40 insertions(+), 25 deletions(-)
>
> Index: linux-davinci/arch/arm/mach-davinci/board-da850-evm.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/board-da850-evm.c
> +++ linux-davinci/arch/arm/mach-davinci/board-da850-evm.c
> @@ -195,6 +195,30 @@ static void __init da850_evm_init_nor(vo
>  	iounmap(aemif_addr);
>  }
>  
> +static const short da850_evm_nand_pins[] = {
> +	DA850_EMA_D_0, DA850_EMA_D_1, DA850_EMA_D_2, DA850_EMA_D_3,
> +	DA850_EMA_D_4, DA850_EMA_D_5, DA850_EMA_D_6, DA850_EMA_D_7,
> +	DA850_EMA_A_1, DA850_EMA_A_2, DA850_NEMA_CS_3, DA850_NEMA_CS_4,
> +	DA850_NEMA_WE, DA850_NEMA_OE,
> +	-1
> +};
> +
> +static const short da850_evm_nor_pins[] = {
> +	DA850_EMA_BA_1, DA850_EMA_CLK, DA850_EMA_WAIT_1, DA850_NEMA_CS_2,
> +	DA850_NEMA_WE, DA850_NEMA_OE, DA850_EMA_D_0, DA850_EMA_D_1,
> +	DA850_EMA_D_2, DA850_EMA_D_3, DA850_EMA_D_4, DA850_EMA_D_5,
> +	DA850_EMA_D_6, DA850_EMA_D_7, DA850_EMA_D_8, DA850_EMA_D_9,
> +	DA850_EMA_D_10, DA850_EMA_D_11, DA850_EMA_D_12, DA850_EMA_D_13,
> +	DA850_EMA_D_14, DA850_EMA_D_15, DA850_EMA_A_0, DA850_EMA_A_1,
> +	DA850_EMA_A_2, DA850_EMA_A_3, DA850_EMA_A_4, DA850_EMA_A_5,
> +	DA850_EMA_A_6, DA850_EMA_A_7, DA850_EMA_A_8, DA850_EMA_A_9,
> +	DA850_EMA_A_10, DA850_EMA_A_11, DA850_EMA_A_12, DA850_EMA_A_13,
> +	DA850_EMA_A_14, DA850_EMA_A_15, DA850_EMA_A_16, DA850_EMA_A_17,
> +	DA850_EMA_A_18, DA850_EMA_A_19, DA850_EMA_A_20, DA850_EMA_A_21,
> +	DA850_EMA_A_22, DA850_EMA_A_23,
> +	-1
> +};
> +
>  static u32 ui_card_detected;
>  
>  #if defined(CONFIG_MMC_DAVINCI) || \
> @@ -204,17 +228,17 @@ static u32 ui_card_detected;
>  #define HAS_MMC 0
>  #endif
>  
> -static __init void da850_evm_setup_nor_nand(void)
> +static inline void da850_evm_setup_nor_nand(void)
>  {
>  	int ret = 0;
>  
>  	if (ui_card_detected & !HAS_MMC) {
> -		ret = davinci_cfg_reg_list(da850_nand_pins);
> +		ret = davinci_cfg_reg_list(da850_evm_nand_pins);
>  		if (ret)
>  			pr_warning("da850_evm_init: nand mux setup failed: "
>  					"%d\n", ret);
>  
> -		ret = davinci_cfg_reg_list(da850_nor_pins);
> +		ret = davinci_cfg_reg_list(da850_evm_nor_pins);
>  		if (ret)
>  			pr_warning("da850_evm_init: nor mux setup failed: %d\n",
>  				ret);
> Index: linux-davinci/arch/arm/mach-davinci/da850.c
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/da850.c
> +++ linux-davinci/arch/arm/mach-davinci/da850.c
> @@ -607,27 +607,19 @@ const short da850_mmcsd0_pins[] __initda
>  	-1
>  };
>  
> -const short da850_nand_pins[] __initdata = {
> -	DA850_EMA_D_7, DA850_EMA_D_6, DA850_EMA_D_5, DA850_EMA_D_4,
> -	DA850_EMA_D_3, DA850_EMA_D_2, DA850_EMA_D_1, DA850_EMA_D_0,
> -	DA850_EMA_A_1, DA850_EMA_A_2, DA850_NEMA_CS_3, DA850_NEMA_CS_4,
> -	DA850_NEMA_WE, DA850_NEMA_OE,
> -	-1
> -};
> -
> -const short da850_nor_pins[] __initdata = {
> +const short da850_emif25_pins[] __initdata = {
>  	DA850_EMA_BA_1, DA850_EMA_CLK, DA850_EMA_WAIT_1, DA850_NEMA_CS_2,
> -	DA850_NEMA_WE, DA850_NEMA_OE, DA850_EMA_D_0, DA850_EMA_D_1,
> -	DA850_EMA_D_2, DA850_EMA_D_3, DA850_EMA_D_4, DA850_EMA_D_5,
> -	DA850_EMA_D_6, DA850_EMA_D_7, DA850_EMA_D_8, DA850_EMA_D_9,
> -	DA850_EMA_D_10, DA850_EMA_D_11, DA850_EMA_D_12, DA850_EMA_D_13,
> -	DA850_EMA_D_14, DA850_EMA_D_15, DA850_EMA_A_0, DA850_EMA_A_1,
> -	DA850_EMA_A_2, DA850_EMA_A_3, DA850_EMA_A_4, DA850_EMA_A_5,
> -	DA850_EMA_A_6, DA850_EMA_A_7, DA850_EMA_A_8, DA850_EMA_A_9,
> -	DA850_EMA_A_10, DA850_EMA_A_11, DA850_EMA_A_12, DA850_EMA_A_13,
> -	DA850_EMA_A_14, DA850_EMA_A_15, DA850_EMA_A_16, DA850_EMA_A_17,
> -	DA850_EMA_A_18, DA850_EMA_A_19, DA850_EMA_A_20, DA850_EMA_A_21,
> -	DA850_EMA_A_22, DA850_EMA_A_23,
> +	DA850_NEMA_CS_3, DA850_NEMA_CS_4, DA850_NEMA_WE, DA850_NEMA_OE,
> +	DA850_EMA_D_0, DA850_EMA_D_1, DA850_EMA_D_2, DA850_EMA_D_3,
> +	DA850_EMA_D_4, DA850_EMA_D_5, DA850_EMA_D_6, DA850_EMA_D_7,
> +	DA850_EMA_D_8, DA850_EMA_D_9, DA850_EMA_D_10, DA850_EMA_D_11,
> +	DA850_EMA_D_12, DA850_EMA_D_13, DA850_EMA_D_14, DA850_EMA_D_15,
> +	DA850_EMA_A_0, DA850_EMA_A_1, DA850_EMA_A_2, DA850_EMA_A_3,
> +	DA850_EMA_A_4, DA850_EMA_A_5, DA850_EMA_A_6, DA850_EMA_A_7,
> +	DA850_EMA_A_8, DA850_EMA_A_9, DA850_EMA_A_10, DA850_EMA_A_11,
> +	DA850_EMA_A_12, DA850_EMA_A_13, DA850_EMA_A_14, DA850_EMA_A_15,
> +	DA850_EMA_A_16, DA850_EMA_A_17, DA850_EMA_A_18, DA850_EMA_A_19,
> +	DA850_EMA_A_20, DA850_EMA_A_21, DA850_EMA_A_22, DA850_EMA_A_23,
>  	-1
>  };
>  
> Index: linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -124,7 +124,6 @@ extern const short da850_rmii_pins[];
>  extern const short da850_mcasp_pins[];
>  extern const short da850_lcdcntl_pins[];
>  extern const short da850_mmcsd0_pins[];
> -extern const short da850_nand_pins[];
> -extern const short da850_nor_pins[];
> +extern const short da850_emif25_pins[];
>  
>  #endif /* __ASM_ARCH_DAVINCI_DA8XX_H */

From michael.williamson at criticallink.com  Thu Aug  5 14:39:36 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu, 05 Aug 2010 15:39:36 -0400
Subject: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <87mxt0ubnr.fsf@deeprootsystems.com>
References: <4C45AE5E.7070905@criticallink.com>	<B85A65D85D7EB246BE421B3FB0FBB59301E7D0AF64@dbde02.ent.ti.com>	<4C4D8449.9040706@criticallink.com>
	<87mxt0ubnr.fsf@deeprootsystems.com>
Message-ID: <4C5B1378.7080400@criticallink.com>

 On 8/5/2010 3:01 PM, Kevin Hilman wrote:

> Michael Williamson <michael.williamson at criticallink.com> writes:
>
>>  On 7/26/2010 5:29 AM, Nori, Sekhar wrote:
>>
>>>
>>> Hi Michael,
>>>
>>> On Tue, Jul 20, 2010 at 19:40:38, Michael Williamson wrote:
>>>>  This patch adds support for the MityDSP-L138 and MityARM-1808 system on
>>>> module (SOM) under the registered machine "mityomapl138".  These SOMs
>>>> are based on the da850 davinci CPU architecture.  Information on these
>>>> SOMs may be found at http://www.mitydsp.com.
>>>>
>>>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>>>> ---
>>>
>>> [...]
>>>
>>>>
>>>>  arch/arm/configs/da8xx_omapl_defconfig             |  291 ++++++--
>>>>  arch/arm/include/asm/setup.h                       |    5 +
>>>>  arch/arm/mach-davinci/Kconfig                      |    7 +
>>>>  arch/arm/mach-davinci/Makefile                     |    1 +
>>>>  arch/arm/mach-davinci/board-mityomapl138.c         |  793 ++++++++++++++++++++
>>>>  .../mach-davinci/include/mach/cb-mityomapl138.h    |  125 +++
>>>>  arch/arm/mach-davinci/include/mach/da8xx.h         |    1 +
>>>>  arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
>>>>  8 files changed, 1181 insertions(+), 43 deletions(-)
>>>>
>>>
>>> [...]
>>>
>>>> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
>>>> index f392fb4..d6b1a47 100644
>>>> --- a/arch/arm/include/asm/setup.h
>>>> +++ b/arch/arm/include/asm/setup.h
>>>> @@ -143,6 +143,11 @@ struct tag_memclk {
>>>>      __u32 fmemclk;
>>>>  };
>>>>
>>>> +/** MityDSP-L138 peripheral configuration info,
>>>> +  *  see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
>>>> +  */
>>>> +#define ATAG_PERIPHERALS 0x42000101
>>>
>>> Instead of naming this so generic, can you call this ATAG_MITYDSPL138 or
>>> something like that?
>>
>>
>>
>> Yes.  I would be glad to rename it, assuming some other approach is not
>> used instead.
>>
>>>
>>> Since passing peripheral configuration from bootloader is a first for
>>> DaVinci, can you please explain why this is the best suited method for this
>>> board and why methods used on other boards wont work?
>>>
>>
>>
>>
>> Well, the problem we are struggling with is that we'd like to avoid
>> generating a pile of separate machine types for the different boards
>> that are needed to support for this common SOM part with regards
>> to the peripheral selection.  There are already have 4 different
>> boards with slightly different peripherals already being used with this SOM,
>> and it's a challenge enough just to try to get one configuration through
>> this cycle (which I am new to).  We are expecting many more (10's per
>> year). 
>>
>> In general, the only real difference on any of these boards will be in regards
>> to peripheral selection/configuration.  E.G., using RMII vs. MII, or using
>> different McASP pins or different numbers of channels, or adding a couple
>> of SPI devices on different chip selects, LCD settings, etc. 
>> Seems like we shouldn't need to make a whole new machine up to support
>> these kinds of things. 
>>
>> This came up in a thread on this mailing list, see
>>
>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17042.html
>>
>> The approach here was pretty much what Kevin suggested as an alternate
>> to trying to port a flat device tree implementation like the powerpc
>> folks use.  The only difference was that I didn't think I could jam
>> everything I wanted onto the kernel command line without it getting out
>> of hand, so I am proposing a separate ATAG to provide the peripheral
>> configuration.  It's not perfect, but I wanted to get something out
>> there as if it's rejected then we only have a few boards to rewrite code
>> for.
>>
>> Other than device trees, the only other approaches I've seen so far to
>> sort out altering peripheral configuration is:
>>
>> a) Make a new board (a new board file, etc., KConfig option, etc.)
>>
>> b) Start in with a pile of #ifdefs, etc., and add a lot of peripheral
>> on/off options to the KConfig/Make system.  That means supporting
>> many variants of kernels for the different host boards, not
>> just an EVM.  I'd like to avoid that if I could, as the regression
>> testing for new options might get out of hand.  And it didn't seem
>> consistent with making a flexible kernel.
>>
>> c) Allow peripheral drivers to probe and initialize pins, etc. in the
>> modules, then load the right drivers up for your board.  There are a lot
>> of threads about why letting drivers mess with the pins is bad.  So this
>> is a non-starter.
>
> d) use ATAG_REVISION and a single board file
>
> There is currently a tag called ATAG_REVISION which sets a global
> variable 'system_rev' based on this tagq.  This tag was intended for
> exactly this purpose.
>
> You can then have a single machine type, a single board file and the
> boot loader can change ATAG_REVISION based on the board specifics.  The
> board file can then check 'system_rev' and handle specifics that way.
>
> This is also much clearer as all the things that are unique to that
> board will be contained in the board file and not hidden away in the
> bootloader.



So, if for example, we have 3 boards that use this SOM, and they
vary by desired peripheral:

Host Board 1 Peripherals = UARTS 0 and 1, SPI0 CS2, RMII, etc.
Host Board 2 Peripherals = UARTS 1 and 2, SPI1 CS1, MII, etc.
Host Board 3 Peripherals = UARTS 0, 1 and 2, SPI1 CS1, MII, etc.

Then by this approach we would have:

mityomapl138_init()
{
   /* Common NAND/NOR Init */

   switch (system_rev) {
      case 1:
          /* setup uarts 0 & 1, SPI0 CS2, RMII */
      case 2:
          /* setup uarts 1 & 2, SPI1 CS1, MII */
      case 3:
      default:
          /* setup uarts 0 & 1 & 2, SPI1 CS1, MII */
          /* and so forth.... */
   }

   /* Common Peripheral Init */
}

Each time a new board is developed to use the SOM, you then grow the init
code accordingly?  I was hoping not to have to continuously drop patches
for new boards using this SOM.  I was really trying to have one binary
kernel that would be flexible enough to support the peripherals that
need to be handed to the device framework for any host board using this
SOM (properly configured via bootloader).  Is this not possible?

Thanks for the insight.

-Mike




From khilman at deeprootsystems.com  Thu Aug  5 14:47:13 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 05 Aug 2010 12:47:13 -0700
Subject: [PATCH v4] DaVinci: dm365: Added clockout2 management.
In-Reply-To: <1281020128-5947-1-git-send-email-lamiaposta71@gmail.com>
	(Raffaele Recalcati's message of "Thu, 5 Aug 2010 16:55:27 +0200")
References: <1281020128-5947-1-git-send-email-lamiaposta71@gmail.com>
Message-ID: <87k4o4suym.fsf@deeprootsystems.com>

Raffaele Recalcati <lamiaposta71 at gmail.com> writes:

> From: Davide Bonfanti <davide.bonfanti at bticino.it>
>
>     Clockout2 is added as a child of pll1_sysclk9.
>     A new dm365_clkout2_set_rate is used to set clockout2 frequency.
>
> Signed-off-by: Davide Bonfanti <davide.bonfanti at bticino.it>
> Signed-off-by: Raffaele Recalcati <raffaele.recalcati at bticino.it>
> ---
> This patch has been developed against 
> http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git 
> and has been tested for dm365 cpu on BMX board.
> This patch depends on the following one submitted to the mailing list:
> https://patchwork.kernel.org/patch/112994
>
> TODO LIST
> -The clkout2 management needs a recalc function, but I by now I don't know how to
> point to it from davinci_clk_init.

Not sure I follow the problem here, but can't you use the .recalc field
of 'struct clk'?  What am I missing?

> -The unmapping of system_module_base has to be checked.

Looks like you're doing it in this version

> -Solving a possible race when writing PERI_CLKCTL, see Nori Sekhar explanation:
> "Looks like the same register supports setting clocks for voice codec
> and keyscan module as well. This can cause a race if those clocks are
> modified in a different context. Can you extend this function to cover
> those clocks as well? May be clk->lpsc can be used to determine if div1,
> div2 or div3 need to be changed. This way you can serialize the setting
> up of these clocks."

I agree with Sekhar. This needs to be addresed before this patch is mergable.

> A fine tuning of clkout2 is possible using the function below (it is 
> possible to do something similar with Nori Sekhar work about DIV_ROUND_CLOSEST()
> in the davinci_set_sysclk_rate() function (max_rate has to be passed).
>
> static int clkout2_fine_setting(unsigned long rate)
> {
>         struct clk *pll1_sysclk9;
>         struct clk *clkout2;
>         int i, err, min_err, i_min_err;
>         int ret = -EINVAL;
>
>         pll1_sysclk9 = clk_get(NULL, "pll1_sysclk9");
>         if (IS_ERR(pll1_sysclk9)) {
>                 printk(KERN_ERR "Could not get pll1_sysclk9\n");
>                 return -ENODEV;
>         }
>         clk_enable(pll1_sysclk9);
>
>         /* check all possibilities to get best fitting for the required freq */
>         i_min_err = min_err = INT_MAX;
>         for (i = 0x0F; i > 0; i--) {
>                 ret = clk_set_rate(pll1_sysclk9, rate * i);
>                 err = clk_get_rate(pll1_sysclk9) - rate * i;
>                 if (min_err > abs(err)) {
>                         min_err = abs(err);
>                         i_min_err = i;
>                 }
>         }
>
>         /* setting the best one to pll1_sysclk9 */
>         ret = clk_set_rate(pll1_sysclk9, rate * i_min_err);
>         if (ret)
>                 return ret;
>
>         /* setting the best one to clkout2 */
>         clkout2 = clk_get(NULL, "clkout2");
>         if (IS_ERR(clkout2)) {
>                 printk(KERN_ERR "Could not get clkout2\n");
>                 return -ENODEV;
>         }
>         clk_enable(clkout2);
>         clk_set_rate(clkout2,rate);
>         return 0;
> }
>
>
>
>  arch/arm/mach-davinci/dm365.c |   42 +++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 42 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 42fd4a4..0101a6c 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -40,6 +40,40 @@
>  #include "mux.h"
>  
>  #define DM365_REF_FREQ		24000000	/* 24 MHz on the DM365 EVM */
> +#define DIV1_MASK		0x78		/* DIV1 mask in PERI_CLKCTL */
> +#define PERI_CLKCTL		0x48
> +#define CLOCKOUT2EN		2
> +
> +int dm365_clkout2_set_rate(struct clk *clk, unsigned long rate)
> +{
> +	int i;
> +	unsigned long input;
> +	unsigned ratio;
> +	unsigned regval;
> +	void __iomem *system_module_base;
> +
> +	/* There must be a parent... */
> +	if (WARN_ON(!clk->parent))
> +		return -EINVAL;
> +
> +	input = clk->parent->rate;
> +
> +	if (input > rate)
> +		ratio = DIV_ROUND_UP(input, rate) - 1;

else ratio is undefined, and clock will be programmed to undefined
value.

Kevin

> +	system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
> +	regval = __raw_readl(system_module_base + PERI_CLKCTL);
> +	regval &= ~DIV1_MASK;
> +	regval |= ratio << 3;
> +
> +	/* to make changes work stop CLOCKOUT & start it again */
> +	regval |= BIT(CLOCKOUT2EN);
> +	__raw_writel(regval, system_module_base + PERI_CLKCTL);
> +	regval &= ~(1 << CLOCKOUT2EN);
> +	__raw_writel(regval, system_module_base + PERI_CLKCTL);
> +	iounmap(system_module_base);
> +	return 0;
> +}
>  
>  static struct pll_data pll1_data = {
>  	.num		= 1,
> @@ -145,6 +179,13 @@ static struct clk pll1_sysclk9 = {
>  	.parent		= &pll1_clk,
>  	.flags		= CLK_PLL,
>  	.div_reg	= PLLDIV9,
> +	.set_rate	= davinci_set_sysclk_rate,
> +};
> +
> +static struct clk clkout2_clk = {
> +	.name		= "clkout2",
> +	.parent		= &pll1_sysclk9,
> +	.set_rate       = dm365_clkout2_set_rate,
>  };
>  
>  static struct clk pll2_clk = {
> @@ -421,6 +462,7 @@ static struct clk_lookup dm365_clks[] = {
>  	CLK(NULL, "pll1_sysclk7", &pll1_sysclk7),
>  	CLK(NULL, "pll1_sysclk8", &pll1_sysclk8),
>  	CLK(NULL, "pll1_sysclk9", &pll1_sysclk9),
> +	CLK(NULL, "clkout2", &clkout2_clk),
>  	CLK(NULL, "pll2", &pll2_clk),
>  	CLK(NULL, "pll2_aux", &pll2_aux_clk),
>  	CLK(NULL, "clkout1", &clkout1_clk),

From bengardiner at nanometrics.ca  Thu Aug  5 15:01:58 2010
From: bengardiner at nanometrics.ca (Ben Gardiner)
Date: Thu, 5 Aug 2010 16:01:58 -0400
Subject: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <4C5B1378.7080400@criticallink.com>
References: <4C45AE5E.7070905@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7D0AF64@dbde02.ent.ti.com>
	<4C4D8449.9040706@criticallink.com>
	<87mxt0ubnr.fsf@deeprootsystems.com>
	<4C5B1378.7080400@criticallink.com>
Message-ID: <AANLkTik1Z1mromdUMK0Qf9iC9tude_4=4XgsL7A-x+K7@mail.gmail.com>

On Thu, Aug 5, 2010 at 3:39 PM, Michael Williamson
<michael.williamson at criticallink.com> wrote:
> ?On 8/5/2010 3:01 PM, Kevin Hilman wrote:
>
>> Michael Williamson <michael.williamson at criticallink.com> writes:
>>
>>> ?On 7/26/2010 5:29 AM, Nori, Sekhar wrote:
>>>
>>>>
>>>> Hi Michael,
>>>>
>>>> On Tue, Jul 20, 2010 at 19:40:38, Michael Williamson wrote:
>>>>> ?This patch adds support for the MityDSP-L138 and MityARM-1808 system on
>>>>> module (SOM) under the registered machine "mityomapl138". ?These SOMs
>>>>> are based on the da850 davinci CPU architecture. ?Information on these
>>>>> SOMs may be found at http://www.mitydsp.com.
>>>>>
>>>>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>>
>>>>> ?arch/arm/configs/da8xx_omapl_defconfig ? ? ? ? ? ? | ?291 ++++++--
>>>>> ?arch/arm/include/asm/setup.h ? ? ? ? ? ? ? ? ? ? ? | ? ?5 +
>>>>> ?arch/arm/mach-davinci/Kconfig ? ? ? ? ? ? ? ? ? ? ?| ? ?7 +
>>>>> ?arch/arm/mach-davinci/Makefile ? ? ? ? ? ? ? ? ? ? | ? ?1 +
>>>>> ?arch/arm/mach-davinci/board-mityomapl138.c ? ? ? ? | ?793 ++++++++++++++++++++
>>>>> ?.../mach-davinci/include/mach/cb-mityomapl138.h ? ?| ?125 +++
>>>>> ?arch/arm/mach-davinci/include/mach/da8xx.h ? ? ? ? | ? ?1 +
>>>>> ?arch/arm/mach-davinci/include/mach/uncompress.h ? ?| ? ?1 +
>>>>> ?8 files changed, 1181 insertions(+), 43 deletions(-)
>>>>>
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
>>>>> index f392fb4..d6b1a47 100644
>>>>> --- a/arch/arm/include/asm/setup.h
>>>>> +++ b/arch/arm/include/asm/setup.h
>>>>> @@ -143,6 +143,11 @@ struct tag_memclk {
>>>>> ? ? ?__u32 fmemclk;
>>>>> ?};
>>>>>
>>>>> +/** MityDSP-L138 peripheral configuration info,
>>>>> + ?* ?see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
>>>>> + ?*/
>>>>> +#define ATAG_PERIPHERALS 0x42000101
>>>>
>>>> Instead of naming this so generic, can you call this ATAG_MITYDSPL138 or
>>>> something like that?
>>>
>>>
>>>
>>> Yes. ?I would be glad to rename it, assuming some other approach is not
>>> used instead.
>>>
>>>>
>>>> Since passing peripheral configuration from bootloader is a first for
>>>> DaVinci, can you please explain why this is the best suited method for this
>>>> board and why methods used on other boards wont work?
>>>>
>>>
>>>
>>>
>>> Well, the problem we are struggling with is that we'd like to avoid
>>> generating a pile of separate machine types for the different boards
>>> that are needed to support for this common SOM part with regards
>>> to the peripheral selection. ?There are already have 4 different
>>> boards with slightly different peripherals already being used with this SOM,
>>> and it's a challenge enough just to try to get one configuration through
>>> this cycle (which I am new to). ?We are expecting many more (10's per
>>> year).
>>>
>>> In general, the only real difference on any of these boards will be in regards
>>> to peripheral selection/configuration. ?E.G., using RMII vs. MII, or using
>>> different McASP pins or different numbers of channels, or adding a couple
>>> of SPI devices on different chip selects, LCD settings, etc.
>>> Seems like we shouldn't need to make a whole new machine up to support
>>> these kinds of things.
>>>
>>> This came up in a thread on this mailing list, see
>>>
>>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17042.html
>>>
>>> The approach here was pretty much what Kevin suggested as an alternate
>>> to trying to port a flat device tree implementation like the powerpc
>>> folks use. ?The only difference was that I didn't think I could jam
>>> everything I wanted onto the kernel command line without it getting out
>>> of hand, so I am proposing a separate ATAG to provide the peripheral
>>> configuration. ?It's not perfect, but I wanted to get something out
>>> there as if it's rejected then we only have a few boards to rewrite code
>>> for.
>>>
>>> Other than device trees, the only other approaches I've seen so far to
>>> sort out altering peripheral configuration is:
>>>
>>> a) Make a new board (a new board file, etc., KConfig option, etc.)
>>>
>>> b) Start in with a pile of #ifdefs, etc., and add a lot of peripheral
>>> on/off options to the KConfig/Make system. ?That means supporting
>>> many variants of kernels for the different host boards, not
>>> just an EVM. ?I'd like to avoid that if I could, as the regression
>>> testing for new options might get out of hand. ?And it didn't seem
>>> consistent with making a flexible kernel.
>>>
>>> c) Allow peripheral drivers to probe and initialize pins, etc. in the
>>> modules, then load the right drivers up for your board. ?There are a lot
>>> of threads about why letting drivers mess with the pins is bad. ?So this
>>> is a non-starter.
>>
>> d) use ATAG_REVISION and a single board file
>>
>> There is currently a tag called ATAG_REVISION which sets a global
>> variable 'system_rev' based on this tagq. ?This tag was intended for
>> exactly this purpose.
>>
>> You can then have a single machine type, a single board file and the
>> boot loader can change ATAG_REVISION based on the board specifics. ?The
>> board file can then check 'system_rev' and handle specifics that way.
>>
>> This is also much clearer as all the things that are unique to that
>> board will be contained in the board file and not hidden away in the
>> bootloader.
>
>
>
> So, if for example, we have 3 boards that use this SOM, and they
> vary by desired peripheral:
>
> Host Board 1 Peripherals = UARTS 0 and 1, SPI0 CS2, RMII, etc.
> Host Board 2 Peripherals = UARTS 1 and 2, SPI1 CS1, MII, etc.
> Host Board 3 Peripherals = UARTS 0, 1 and 2, SPI1 CS1, MII, etc.
>
> Then by this approach we would have:
>
> mityomapl138_init()
> {
> ? /* Common NAND/NOR Init */
>
> ? switch (system_rev) {
> ? ? ?case 1:
> ? ? ? ? ?/* setup uarts 0 & 1, SPI0 CS2, RMII */
> ? ? ?case 2:
> ? ? ? ? ?/* setup uarts 1 & 2, SPI1 CS1, MII */
> ? ? ?case 3:
> ? ? ?default:
> ? ? ? ? ?/* setup uarts 0 & 1 & 2, SPI1 CS1, MII */
> ? ? ? ? ?/* and so forth.... */
> ? }
>
> ? /* Common Peripheral Init */
> }
>
> Each time a new board is developed to use the SOM, you then grow the init
> code accordingly? ?I was hoping not to have to continuously drop patches
> for new boards using this SOM. ?I was really trying to have one binary
> kernel that would be flexible enough to support the peripherals that
> need to be handed to the device framework for any host board using this
> SOM (properly configured via bootloader). ?Is this not possible?

Michael, could you pack the available peripherals into the bits of
ATAG_REVISION?

#define MIGHTYDSP_UART0 BIT(0)
#define MIGHTYDSP_UART1 BIT(1)
#define MIGHTYDSP_UART2 BIT(2)
#define MIGHTYDSP_SPI1 BIT(3)

mityomapl138_init()
{
  /* Common NAND/NOR Init */

  if(system_rev & MIGHTYDSP_UART0) { /* setup uart0 */ }

  if(system_rev & MIGHTYDSP_SPI1) { /*setup spi1*/ }

  /* Common Peripheral Init */
}

Kevin, is that legal use of ATAG_REVISION?

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

From michael.williamson at criticallink.com  Thu Aug  5 15:13:32 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu, 05 Aug 2010 16:13:32 -0400
Subject: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <AANLkTik1Z1mromdUMK0Qf9iC9tude_4=4XgsL7A-x+K7@mail.gmail.com>
References: <4C45AE5E.7070905@criticallink.com>	<B85A65D85D7EB246BE421B3FB0FBB59301E7D0AF64@dbde02.ent.ti.com>	<4C4D8449.9040706@criticallink.com>	<87mxt0ubnr.fsf@deeprootsystems.com>	<4C5B1378.7080400@criticallink.com>
	<AANLkTik1Z1mromdUMK0Qf9iC9tude_4=4XgsL7A-x+K7@mail.gmail.com>
Message-ID: <4C5B1B6C.2040601@criticallink.com>

 On 8/5/2010 4:01 PM, Ben Gardiner wrote:

> On Thu, Aug 5, 2010 at 3:39 PM, Michael Williamson
> <michael.williamson at criticallink.com> wrote:
>>  On 8/5/2010 3:01 PM, Kevin Hilman wrote:
>>
>>> Michael Williamson <michael.williamson at criticallink.com> writes:
>>>
>>>>  On 7/26/2010 5:29 AM, Nori, Sekhar wrote:
>>>>
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> On Tue, Jul 20, 2010 at 19:40:38, Michael Williamson wrote:
>>>>>>  This patch adds support for the MityDSP-L138 and MityARM-1808 system on
>>>>>> module (SOM) under the registered machine "mityomapl138".  These SOMs
>>>>>> are based on the da850 davinci CPU architecture.  Information on these
>>>>>> SOMs may be found at http://www.mitydsp.com.
>>>>>>
>>>>>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>>  arch/arm/configs/da8xx_omapl_defconfig             |  291 ++++++--
>>>>>>  arch/arm/include/asm/setup.h                       |    5 +
>>>>>>  arch/arm/mach-davinci/Kconfig                      |    7 +
>>>>>>  arch/arm/mach-davinci/Makefile                     |    1 +
>>>>>>  arch/arm/mach-davinci/board-mityomapl138.c         |  793 ++++++++++++++++++++
>>>>>>  .../mach-davinci/include/mach/cb-mityomapl138.h    |  125 +++
>>>>>>  arch/arm/mach-davinci/include/mach/da8xx.h         |    1 +
>>>>>>  arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
>>>>>>  8 files changed, 1181 insertions(+), 43 deletions(-)
>>>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
>>>>>> index f392fb4..d6b1a47 100644
>>>>>> --- a/arch/arm/include/asm/setup.h
>>>>>> +++ b/arch/arm/include/asm/setup.h
>>>>>> @@ -143,6 +143,11 @@ struct tag_memclk {
>>>>>>      __u32 fmemclk;
>>>>>>  };
>>>>>>
>>>>>> +/** MityDSP-L138 peripheral configuration info,
>>>>>> +  *  see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
>>>>>> +  */
>>>>>> +#define ATAG_PERIPHERALS 0x42000101
>>>>>
>>>>> Instead of naming this so generic, can you call this ATAG_MITYDSPL138 or
>>>>> something like that?
>>>>
>>>>
>>>>
>>>> Yes.  I would be glad to rename it, assuming some other approach is not
>>>> used instead.
>>>>
>>>>>
>>>>> Since passing peripheral configuration from bootloader is a first for
>>>>> DaVinci, can you please explain why this is the best suited method for this
>>>>> board and why methods used on other boards wont work?
>>>>>
>>>>
>>>>
>>>>
>>>> Well, the problem we are struggling with is that we'd like to avoid
>>>> generating a pile of separate machine types for the different boards
>>>> that are needed to support for this common SOM part with regards
>>>> to the peripheral selection.  There are already have 4 different
>>>> boards with slightly different peripherals already being used with this SOM,
>>>> and it's a challenge enough just to try to get one configuration through
>>>> this cycle (which I am new to).  We are expecting many more (10's per
>>>> year).
>>>>
>>>> In general, the only real difference on any of these boards will be in regards
>>>> to peripheral selection/configuration.  E.G., using RMII vs. MII, or using
>>>> different McASP pins or different numbers of channels, or adding a couple
>>>> of SPI devices on different chip selects, LCD settings, etc.
>>>> Seems like we shouldn't need to make a whole new machine up to support
>>>> these kinds of things.
>>>>
>>>> This came up in a thread on this mailing list, see
>>>>
>>>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17042.html
>>>>
>>>> The approach here was pretty much what Kevin suggested as an alternate
>>>> to trying to port a flat device tree implementation like the powerpc
>>>> folks use.  The only difference was that I didn't think I could jam
>>>> everything I wanted onto the kernel command line without it getting out
>>>> of hand, so I am proposing a separate ATAG to provide the peripheral
>>>> configuration.  It's not perfect, but I wanted to get something out
>>>> there as if it's rejected then we only have a few boards to rewrite code
>>>> for.
>>>>
>>>> Other than device trees, the only other approaches I've seen so far to
>>>> sort out altering peripheral configuration is:
>>>>
>>>> a) Make a new board (a new board file, etc., KConfig option, etc.)
>>>>
>>>> b) Start in with a pile of #ifdefs, etc., and add a lot of peripheral
>>>> on/off options to the KConfig/Make system.  That means supporting
>>>> many variants of kernels for the different host boards, not
>>>> just an EVM.  I'd like to avoid that if I could, as the regression
>>>> testing for new options might get out of hand.  And it didn't seem
>>>> consistent with making a flexible kernel.
>>>>
>>>> c) Allow peripheral drivers to probe and initialize pins, etc. in the
>>>> modules, then load the right drivers up for your board.  There are a lot
>>>> of threads about why letting drivers mess with the pins is bad.  So this
>>>> is a non-starter.
>>>
>>> d) use ATAG_REVISION and a single board file
>>>
>>> There is currently a tag called ATAG_REVISION which sets a global
>>> variable 'system_rev' based on this tagq.  This tag was intended for
>>> exactly this purpose.
>>>
>>> You can then have a single machine type, a single board file and the
>>> boot loader can change ATAG_REVISION based on the board specifics.  The
>>> board file can then check 'system_rev' and handle specifics that way.
>>>
>>> This is also much clearer as all the things that are unique to that
>>> board will be contained in the board file and not hidden away in the
>>> bootloader.
>>
>>
>>
>> So, if for example, we have 3 boards that use this SOM, and they
>> vary by desired peripheral:
>>
>> Host Board 1 Peripherals = UARTS 0 and 1, SPI0 CS2, RMII, etc.
>> Host Board 2 Peripherals = UARTS 1 and 2, SPI1 CS1, MII, etc.
>> Host Board 3 Peripherals = UARTS 0, 1 and 2, SPI1 CS1, MII, etc.
>>
>> Then by this approach we would have:
>>
>> mityomapl138_init()
>> {
>>   /* Common NAND/NOR Init */
>>
>>   switch (system_rev) {
>>      case 1:
>>          /* setup uarts 0 & 1, SPI0 CS2, RMII */
>>      case 2:
>>          /* setup uarts 1 & 2, SPI1 CS1, MII */
>>      case 3:
>>      default:
>>          /* setup uarts 0 & 1 & 2, SPI1 CS1, MII */
>>          /* and so forth.... */
>>   }
>>
>>   /* Common Peripheral Init */
>> }
>>
>> Each time a new board is developed to use the SOM, you then grow the init
>> code accordingly?  I was hoping not to have to continuously drop patches
>> for new boards using this SOM.  I was really trying to have one binary
>> kernel that would be flexible enough to support the peripherals that
>> need to be handed to the device framework for any host board using this
>> SOM (properly configured via bootloader).  Is this not possible?
>
> Michael, could you pack the available peripherals into the bits of
> ATAG_REVISION?
>
> #define MIGHTYDSP_UART0 BIT(0)
> #define MIGHTYDSP_UART1 BIT(1)
> #define MIGHTYDSP_UART2 BIT(2)
> #define MIGHTYDSP_SPI1 BIT(3)
>
> mityomapl138_init()
> {
>   /* Common NAND/NOR Init */
>
>   if(system_rev & MIGHTYDSP_UART0) { /* setup uart0 */ }
>
>   if(system_rev & MIGHTYDSP_SPI1) { /*setup spi1*/ }
>
>   /* Common Peripheral Init */
> }
>
> Kevin, is that legal use of ATAG_REVISION?
>



It's unlikely.  There are strings to pass to the framebuffer device
for the da850, multiple CS pin assignments as well as multiple McASP
channel configurations.  I'll look into it. Thanks.

-Mike


From bengardiner at nanometrics.ca  Thu Aug  5 16:31:50 2010
From: bengardiner at nanometrics.ca (Ben Gardiner)
Date: Thu, 5 Aug 2010 17:31:50 -0400
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <8739usuaw9.fsf@deeprootsystems.com>
References: <201008012115.16423.sshtylyov@ru.mvista.com>
	<8739usuaw9.fsf@deeprootsystems.com>
Message-ID: <AANLkTik7UbkMtRj6uSPfCpQVVFxts_En6wf+X6DTDtRM@mail.gmail.com>

On Thu, Aug 5, 2010 at 3:17 PM, Kevin Hilman
<khilman at deeprootsystems.com> wrote:
> Sergei Shtylyov <sshtylyov at ru.mvista.com> writes:
>
>> The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
>> specific and as such shouldn't be in da850.c -- copy them to board-da850-evm.c,
>> renaming to da850_evm_nand_pins/da850_evm_nor_pins respectively, and merge the
>> two lists in da850.c into one, representing the EMIF 2.5 module as a whole,
>> just like we have it in da830.c...
>>
>> While at it, remove the '__init' modifier from da850_evm_setup_nor_nand() as
>> this function is called from non '__init' code...
>>
>> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>>
>> ---
>> The patch is against the recent DaVinci tree. It has only been build-tested as
>> I don't have DA850 EVM board...
>
> I'm OK with this series, but would like to see some test reports on
> da850-evm using nand and nor using this before I apply it.
>
> Kevin

Tested-by: Ben Gardiner<bengardiner at nanometrics.ca>

The patch applies cleanly to 939c222e5e793c8b9d7494e2b125676e8fd7dcaf
of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
and results in a bootable kernel with a config from the omap-l1 tree
and 'make oldconfig < /dev/null' after USB and the voltage regulators
are disabled.

The kernel appears to run as well with the patch applied as without --
tested on a da850evm booting from NAND and mounting JFFS2 rootfs from
NAND.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

From bengardiner at nanometrics.ca  Thu Aug  5 16:33:38 2010
From: bengardiner at nanometrics.ca (Ben Gardiner)
Date: Thu, 5 Aug 2010 17:33:38 -0400
Subject: [PATCH 2/2] DA850: move MII/RMII pin lists to the board file
In-Reply-To: <201008012117.00730.sshtylyov@ru.mvista.com>
References: <201008012117.00730.sshtylyov@ru.mvista.com>
Message-ID: <AANLkTi=Hd8UvPGrCWmmxp6+6fNvck5dSWF9S-2btu7LV@mail.gmail.com>

On Sun, Aug 1, 2010 at 1:17 PM, Sergei Shtylyov <sshtylyov at ru.mvista.com> wrote:
> The CPGMAC pin list in da850.c was incorrectly split into two MII/RMII mode
> specific pin lists, while what pin group is used is a function of how the board
> is wired. ?Copy the pin lists to board-da850-evm.c, renaming them accordingly,
> and merge the two lists in da850.c into one, da850_cpgmac_pins[], representing
> the CPGMAC module as a whole...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>

Tested-by: Ben Gardiner<bengardiner at nanometrics.ca>

The patch applies cleanly to 939c222e5e793c8b9d7494e2b125676e8fd7dcaf
of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
and results in a bootable kernel with a config from the omap-l1 tree
and 'make oldconfig < /dev/null' after USB and the voltage regulators
are disabled.

The kernel appears to run as well with the patch applied as without --
tested on a da850evm booting from NAND and mounting JFFS2 rootfs from
NAND.

Best Regards,
Ben Gardiner

From seek_for at 163.com  Tue Aug 10 20:33:48 2010
From: seek_for at 163.com (seek_for)
Date: Wed, 11 Aug 2010 09:33:48 +0800
Subject: How to exit this group?please
Message-ID: <201008110933474848695@163.com>

How to exit this group?please 

2010-08-11 



seek_for 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100811/33c2fbcd/attachment.html>

From nsekhar at ti.com  Fri Aug  6 00:05:27 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 6 Aug 2010 10:35:27 +0530
Subject: [rtc-linux] RE: [PATCH v2] rtc: omap: let device wakeup
	capability be configured from chip init logic
In-Reply-To: <AANLkTimpgKAL-O01wiECR9eCwEGzWVupQiyqoTt9wbku@mail.gmail.com>
References: <B85A65D85D7EB246BE421B3FB0FBB59301E75F0E15@dbde02.ent.ti.com>
	<389061.41765.qm@web180310.mail.gq1.yahoo.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7D0A1D5@dbde02.ent.ti.com>
	<AANLkTimpgKAL-O01wiECR9eCwEGzWVupQiyqoTt9wbku@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E800B7EB@dbde02.ent.ti.com>


Hi Andrew,

On Fri, Jul 23, 2010 at 15:16:19, Wan ZongShun wrote:
> 2010/7/22 Nori, Sekhar <nsekhar at ti.com>:
> > Hi Alessandro,
> >
> > On Mon, Jul 19, 2010 at 02:22:13, David Brownell wrote:
> >>
> >>
> >> --- On Wed, 6/16/10, Nori, Sekhar <nsekhar at ti.com> wrote:
> >> <rtc-linux at googlegroups.com>
> >> > Date: Wednesday, June 16, 2010, 9:46 PM
> >> > Hi Dave,
> >> >
> >> > Any thoughts on my responses below? If you are
> >> > satisfied, would you please Ack my patch?
> >>
> >> I don't have time to properly review it.  If it
> >> works, go for it ... bugs can be fixed later, and
> >> the principle behind the patch is fine.
> >>
> >
> > Since Dave is OK with merging this, would you please
> > queue this for 2.6.36?
>
> Alessandro is so busy too, you can get merging help from Andrew.

Can you please help merge this patch? Here is the patch
in question:

http://patchwork.ozlabs.org/patch/47089/

I can resend it to the list if that?s more convenient.

Thanks,
Sekhar

From nsekhar at ti.com  Fri Aug  6 07:47:02 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 6 Aug 2010 18:17:02 +0530
Subject: [PATCH v2 1/6] davinci: add support for aemif timing configuration
In-Reply-To: <871vacx6oy.fsf@deeprootsystems.com>
References: <1278410661-18211-1-git-send-email-nsekhar@ti.com>
	<871vacx6oy.fsf@deeprootsystems.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E800BBD0@dbde02.ent.ti.com>

On Thu, Aug 05, 2010 at 23:50:13, Kevin Hilman wrote:
> Sekhar Nori <nsekhar at ti.com> writes:
>
> > This patch adds support to configure the AEMIF interface
> > with supplied timing values.
> >
> > Since this capability is useful both from NOR and NAND
> > flashes, it is provided as a new interface and in a file
> > of its own.
> >
> > AEMIF timing configuration is required in cases:
> >
> > 1) Where the AEMIF clock rate can change at runtime (a side
> >    affect of cpu frequency change).
> >
> > 2) Where U-Boot does not support NAND/NOR but supports other
> >    media like SPI Flash or MMC/SD and thus does not care about
> >    setting up the AEMIF timing for kernel to use.
> >
> > 3) Where U-Boot just hasn't configured the timing values and
> >    cannot be upgraded because the box is already in the field.
> >
> > Since there is now a header file for AEMIF interface, the
> > common (non-NAND specific) defines for AEMIF registers have
> > been moved from nand.h into the newly created aemif.h
> >
> > Signed-off-by: Sekhar Nori <nsekhar at ti.com>
>
> This series looks great, and is a very nice cleanup.  Also, those
> performance improvments are pretty impressive.
>
> Apart from the minor comment below (which I can fixup myself if you
> approve), I'll apply this whole series.

Thanks Kevin!

Patch 2/6 touches mtd nand driver. Do you want to take that patch through
davinci as well? I guess mtd list would have to be involved someway. Shall
I post the series to mtd list with your sign-off/ack to see what the mtd
maintainer wants to do?

>
> [...]
>
> > +
> > +#define TIMING_MASK        (TA(TA_MAX) | \
> > +                           RHOLD(RHOLD_MAX) | \
> > +                           RSTROBE(RSTROBE_MAX) |  \
> > +                           RSETUP(RSETUP_MAX) | \
> > +                           WHOLD(WHOLD_MAX) | \
> > +                           WSTROBE(WSTROBE_MAX) | \
> > +                           WSETUP(WSETUP_MAX))
> > +
> > +#define NS_IN_KHZ  1000000
>
> Minor nit: <linux/time.h> already nas NSEC_PER_MSEC, can use that instead.

If I am going to have to re-post this, I can make this change while
posting.

Thanks,
Sekhar


From khilman at deeprootsystems.com  Fri Aug  6 19:45:42 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 06 Aug 2010 17:45:42 -0700
Subject: [PATCH v2 1/6] davinci: add support for aemif timing configuration
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E800BBD0@dbde02.ent.ti.com>
	(Sekhar Nori's message of "Fri, 6 Aug 2010 18:17:02 +0530")
References: <1278410661-18211-1-git-send-email-nsekhar@ti.com>
	<871vacx6oy.fsf@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E800BBD0@dbde02.ent.ti.com>
Message-ID: <87sk2rmert.fsf@deeprootsystems.com>

"Nori, Sekhar" <nsekhar at ti.com> writes:

> On Thu, Aug 05, 2010 at 23:50:13, Kevin Hilman wrote:
>> Sekhar Nori <nsekhar at ti.com> writes:
>>
>> > This patch adds support to configure the AEMIF interface
>> > with supplied timing values.
>> >
>> > Since this capability is useful both from NOR and NAND
>> > flashes, it is provided as a new interface and in a file
>> > of its own.
>> >
>> > AEMIF timing configuration is required in cases:
>> >
>> > 1) Where the AEMIF clock rate can change at runtime (a side
>> >    affect of cpu frequency change).
>> >
>> > 2) Where U-Boot does not support NAND/NOR but supports other
>> >    media like SPI Flash or MMC/SD and thus does not care about
>> >    setting up the AEMIF timing for kernel to use.
>> >
>> > 3) Where U-Boot just hasn't configured the timing values and
>> >    cannot be upgraded because the box is already in the field.
>> >
>> > Since there is now a header file for AEMIF interface, the
>> > common (non-NAND specific) defines for AEMIF registers have
>> > been moved from nand.h into the newly created aemif.h
>> >
>> > Signed-off-by: Sekhar Nori <nsekhar at ti.com>
>>
>> This series looks great, and is a very nice cleanup.  Also, those
>> performance improvments are pretty impressive.
>>
>> Apart from the minor comment below (which I can fixup myself if you
>> approve), I'll apply this whole series.
>
> Thanks Kevin!
>
> Patch 2/6 touches mtd nand driver. Do you want to take that patch through
> davinci as well? I guess mtd list would have to be involved someway. Shall
> I post the series to mtd list with your sign-off/ack to see what the mtd
> maintainer wants to do?

Yes please.  You can add my ack.

>>
>> [...]
>>
>> > +
>> > +#define TIMING_MASK        (TA(TA_MAX) | \
>> > +                           RHOLD(RHOLD_MAX) | \
>> > +                           RSTROBE(RSTROBE_MAX) |  \
>> > +                           RSETUP(RSETUP_MAX) | \
>> > +                           WHOLD(WHOLD_MAX) | \
>> > +                           WSTROBE(WSTROBE_MAX) | \
>> > +                           WSETUP(WSETUP_MAX))
>> > +
>> > +#define NS_IN_KHZ  1000000
>>
>> Minor nit: <linux/time.h> already nas NSEC_PER_MSEC, can use that instead.
>
> If I am going to have to re-post this, I can make this change while
> posting.

OK, thanks.

Kevin

From khilman at deeprootsystems.com  Fri Aug  6 19:46:38 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 06 Aug 2010 17:46:38 -0700
Subject: How to exit this group?please
In-Reply-To: <201008110933474848695@163.com> (seek for's message of "Wed, 11
	Aug 2010 09:33:48 +0800")
References: <201008110933474848695@163.com>
Message-ID: <87lj8jmeq9.fsf@deeprootsystems.com>

"seek_for" <seek_for at 163.com> writes:

> How to exit this group?please
>  
> 2010-08-11
> -------------------------------------------------------------------------------
> seek_for
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

The bottom of every email has a URL to the list admin interface.  You
can unsubscribe yourself there.

Kevin

From david-b at pacbell.net  Fri Aug  6 20:22:54 2010
From: david-b at pacbell.net (David Brownell)
Date: Fri, 6 Aug 2010 18:22:54 -0700 (PDT)
Subject: MUSB: Idea: board-specific OTG ID pin interrupt support
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE08E055CE48@Cloud.RL.local>
Message-ID: <728084.49982.qm@web180311.mail.gq1.yahoo.com>



--- On Wed, 6/2/10, Jon Povey <Jon.Povey at racelogic.co.uk> wrote:

> From: Jon Povey <Jon.Povey at racelogic.co.uk>
> Subject: MUSB: Idea: board-specific OTG ID pin interrupt support
> To: "linux-usb at vger.kernel.org" <linux-usb at vger.kernel.org>, "davinci-linux-open-source at linux.davincidsp.com" <davinci-linux-open-source at linux.davincidsp.com>
> Cc: "felipe.balbi at nokia.com" <felipe.balbi at nokia.com>, "Sergei Shtylyov" <sshtylyov at mvista.com>
> Date: Wednesday, June 2, 2010, 5:52 PM
> Playing around with MUSB OTG on TI
> DM355 I am having some trouble getting A-B role switching
> working.
> 
> On my board by happy design foresight, USB ID is also wired
> to a GPIO. I am currently having a go at hacking an ID
> interrupt into the MUSB driver to prod the state machine.


I don't recall having difficulties getting the
ID-based role switching to behave with
the DM355 EVM...

  GPIO IRQs should not be needed.

Of course, maybe my memory has faded; this is
the type of situation where Mentor's silicon
design team gratuitiously disregarded OTG specs.
In fact ISTR some chicken/egg issues specifically
regarding the ID pin status bit in whichever
register held it... making host vs perhipheral
initialization a real PITA.  Maybe ULPI hooks
would help.

Regardless, I did see the cable based role
switch logic working without such gpio logic.


- Dave



From pratik.joshi at einfochips.com  Sat Aug  7 01:02:13 2010
From: pratik.joshi at einfochips.com (pratik.joshi)
Date: Sat, 7 Aug 2010 11:32:13 +0530
Subject: Help needed for DM365 SPI driver in DMA mode
Message-ID: <000e01cb35f6$14ba6d20$3e2f4760$@joshi@einfochips.com>

Hi All,

 

I am currently working on SPI driver for DM365. I am using MVL5. I am using
SPI1 as a master device. The problem is I could see 1 byte being transferred
to SPI slave but after that there is no clock (checked and verified on CRO)
for subsequent data. The data transfer is configured to use DMA. I verified
EDMA configuration and found it ok. Can anyone advice me on what could be
wrong?

 

Regards,

Pratik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100807/4ad4b031/attachment.html>

From ghl.bhrt at gmail.com  Sat Aug  7 03:28:53 2010
From: ghl.bhrt at gmail.com (bharat gohil)
Date: Sat, 7 Aug 2010 13:58:53 +0530
Subject: No subject
Message-ID: <AANLkTinHAcYVxTCsyjTNkLHEPnpaQbBTx2Gbg+838tGB@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100807/02debc26/attachment.html>

From schen at mvista.com  Sat Aug  7 09:53:32 2010
From: schen at mvista.com (Steve Chen)
Date: Sat, 7 Aug 2010 09:53:32 -0500
Subject: Help needed for DM365 SPI driver in DMA mode
In-Reply-To: <7226679261985975375@unknownmsgid>
References: <7226679261985975375@unknownmsgid>
Message-ID: <AANLkTim_L9d5WJa+PQTdiPjbmSmDyNFhT9Mb4CEVLMr_@mail.gmail.com>

On Sat, Aug 7, 2010 at 1:02 AM, pratik.joshi
<pratik.joshi at einfochips.com> wrote:
> Hi All,
>
>
>
> I am currently working on SPI driver for DM365. I am using MVL5. I am using
> SPI1 as a master device. The problem is I could see 1 byte being transferred
> to SPI slave but after that there is no clock (checked and verified on CRO)
> for subsequent data. The data transfer is configured to use DMA. I verified
> EDMA configuration and found it ok. Can anyone advice me on what could be
> wrong?
>

Since you are using a distro from Monta Vista/TI, have you tried MV or
TI support?

Steve

From sshtylyov at ru.mvista.com  Sun Aug  8 12:22:40 2010
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Sun, 8 Aug 2010 21:22:40 +0400
Subject: [PATCH RFC v9] MUSB: DA8xx/OMAP-L1x glue layer
Message-ID: <201008082122.40610.sshtylyov@ru.mvista.com>

Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver.

Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
Signed-off-by: Yadviga Grigorieva <yadviga at ru.mvista.com>

---
The patch is against the recent Linus' tree. Felipe, please ACK it soonish,
so it can go into 2.6.36 at last...

WARNING: the MUSB and OHCI drivers will only work if your boot loader leaves
the DA8xx boot configuration registers unlocked, otherwise they will lock up
the kernel!

The OTG mode still doesn't work...

Changes since the previous version:
- changed the parameter list of musb_platform_init() to match the new
  prototype;
- also call clk_disable() iff otg_get_transceiver() fails;
- call otg_put_transceiver() from musb_platform_exit();
- remove VBUS fall waiting from musb_platform_exit() -- it either causes a
  meaningless delay (in host mode) or just doesn't occur (in OTG mode)...

 drivers/usb/musb/Kconfig     |    5 
 drivers/usb/musb/Makefile    |    4 
 drivers/usb/musb/da8xx.c     |  469 +++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/musb/musb_core.h |    1 
 4 files changed, 478 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/usb/musb/Kconfig
===================================================================
--- linux-2.6.orig/drivers/usb/musb/Kconfig
+++ linux-2.6/drivers/usb/musb/Kconfig
@@ -45,6 +45,9 @@ config USB_MUSB_SOC
 comment "DaVinci 35x and 644x USB support"
 	depends on USB_MUSB_HDRC && ARCH_DAVINCI_DMx
 
+comment "DA8xx/OMAP-L1x USB support"
+	depends on USB_MUSB_HDRC && ARCH_DAVINCI_DA8XX
+
 comment "OMAP 243x high speed USB support"
 	depends on USB_MUSB_HDRC && ARCH_OMAP2430
 
@@ -144,7 +147,7 @@ config USB_MUSB_HDRC_HCD
 config MUSB_PIO_ONLY
 	bool 'Disable DMA (always use PIO)'
 	depends on USB_MUSB_HDRC
-	default y if USB_TUSB6010
+	default USB_TUSB6010 || ARCH_DAVINCI_DA8XX
 	help
 	  All data is copied between memory and FIFO by the CPU.
 	  DMA controllers are ignored.
Index: linux-2.6/drivers/usb/musb/Makefile
===================================================================
--- linux-2.6.orig/drivers/usb/musb/Makefile
+++ linux-2.6/drivers/usb/musb/Makefile
@@ -10,6 +10,10 @@ ifeq ($(CONFIG_ARCH_DAVINCI_DMx),y)
 	musb_hdrc-objs	+= davinci.o
 endif
 
+ifeq ($(CONFIG_ARCH_DAVINCI_DA8XX),y)
+	musb_hdrc-objs	+= da8xx.o
+endif
+
 ifeq ($(CONFIG_USB_TUSB6010),y)
 	musb_hdrc-objs	+= tusb6010.o
 endif
Index: linux-2.6/drivers/usb/musb/da8xx.c
===================================================================
--- /dev/null
+++ linux-2.6/drivers/usb/musb/da8xx.c
@@ -0,0 +1,469 @@
+/*
+ * Texas Instruments DA8xx/OMAP-L1x "glue layer"
+ *
+ * Copyright (c) 2008-2009 MontaVista Software, Inc. <source at mvista.com>
+ *
+ * Based on the DaVinci "glue layer" code.
+ * Copyright (C) 2005-2006 by Texas Instruments
+ *
+ * This file is part of the Inventra Controller Driver for Linux.
+ *
+ * The Inventra Controller Driver for Linux 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.
+ *
+ * The Inventra Controller Driver for Linux is distributed in
+ * the hope that it will be useful, but WITHOUT ANY WARRANTY;
+ * without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+ * License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with The Inventra Controller Driver for Linux ; if not,
+ * write to the Free Software Foundation, Inc., 59 Temple Place,
+ * Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+
+#include <mach/da8xx.h>
+#include <mach/usb.h>
+
+#include "musb_core.h"
+
+/*
+ * DA8XX specific definitions
+ */
+
+/* USB 2.0 OTG module registers */
+#define DA8XX_USB_REVISION_REG	0x00
+#define DA8XX_USB_CTRL_REG	0x04
+#define DA8XX_USB_STAT_REG	0x08
+#define DA8XX_USB_EMULATION_REG 0x0c
+#define DA8XX_USB_MODE_REG	0x10	/* Transparent, CDC, [Generic] RNDIS */
+#define DA8XX_USB_AUTOREQ_REG	0x14
+#define DA8XX_USB_SRP_FIX_TIME_REG 0x18
+#define DA8XX_USB_TEARDOWN_REG	0x1c
+#define DA8XX_USB_INTR_SRC_REG	0x20
+#define DA8XX_USB_INTR_SRC_SET_REG 0x24
+#define DA8XX_USB_INTR_SRC_CLEAR_REG 0x28
+#define DA8XX_USB_INTR_MASK_REG 0x2c
+#define DA8XX_USB_INTR_MASK_SET_REG 0x30
+#define DA8XX_USB_INTR_MASK_CLEAR_REG 0x34
+#define DA8XX_USB_INTR_SRC_MASKED_REG 0x38
+#define DA8XX_USB_END_OF_INTR_REG 0x3c
+#define DA8XX_USB_GENERIC_RNDIS_EP_SIZE_REG(n) (0x50 + (((n) - 1) << 2))
+
+/* Control register bits */
+#define DA8XX_SOFT_RESET_MASK	1
+
+#define DA8XX_USB_TX_EP_MASK	0x1f		/* EP0 + 4 Tx EPs */
+#define DA8XX_USB_RX_EP_MASK	0x1e		/* 4 Rx EPs */
+
+/* USB interrupt register bits */
+#define DA8XX_INTR_USB_SHIFT	16
+#define DA8XX_INTR_USB_MASK	(0x1ff << DA8XX_INTR_USB_SHIFT) /* 8 Mentor */
+					/* interrupts and DRVVBUS interrupt */
+#define DA8XX_INTR_DRVVBUS	0x100
+#define DA8XX_INTR_RX_SHIFT	8
+#define DA8XX_INTR_RX_MASK	(DA8XX_USB_RX_EP_MASK << DA8XX_INTR_RX_SHIFT)
+#define DA8XX_INTR_TX_SHIFT	0
+#define DA8XX_INTR_TX_MASK	(DA8XX_USB_TX_EP_MASK << DA8XX_INTR_TX_SHIFT)
+
+#define DA8XX_MENTOR_CORE_OFFSET 0x400
+
+#define CFGCHIP2	IO_ADDRESS(DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP2_REG)
+
+/*
+ * REVISIT (PM): we should be able to keep the PHY in low power mode most
+ * of the time (24 MHz oscillator and PLL off, etc.) by setting POWER.D0
+ * and, when in host mode, autosuspending idle root ports... PHY_PLLON
+ * (overriding SUSPENDM?) then likely needs to stay off.
+ */
+
+static inline void phy_on(void)
+{
+	u32 cfgchip2 = __raw_readl(CFGCHIP2);
+
+	/*
+	 * Start the on-chip PHY and its PLL.
+	 */
+	cfgchip2 &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN);
+	cfgchip2 |= CFGCHIP2_PHY_PLLON;
+	__raw_writel(cfgchip2, CFGCHIP2);
+
+	pr_info("Waiting for USB PHY clock good...\n");
+	while (!(__raw_readl(CFGCHIP2) & CFGCHIP2_PHYCLKGD))
+		cpu_relax();
+}
+
+static inline void phy_off(void)
+{
+	u32 cfgchip2 = __raw_readl(CFGCHIP2);
+
+	/*
+	 * Ensure that USB 1.1 reference clock is not being sourced from
+	 * USB 2.0 PHY.  Otherwise do not power down the PHY.
+	 */
+	if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX) &&
+	     (cfgchip2 & CFGCHIP2_USB1SUSPENDM)) {
+		pr_warning("USB 1.1 clocked from USB 2.0 PHY -- "
+			   "can't power it down\n");
+		return;
+	}
+
+	/*
+	 * Power down the on-chip PHY.
+	 */
+	cfgchip2 |= CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN;
+	__raw_writel(cfgchip2, CFGCHIP2);
+}
+
+/*
+ * Because we don't set CTRL.UINT, it's "important" to:
+ *	- not read/write INTRUSB/INTRUSBE (except during
+ *	  initial setup, as a workaround);
+ *	- use INTSET/INTCLR instead.
+ */
+
+/**
+ * musb_platform_enable - enable interrupts
+ */
+void musb_platform_enable(struct musb *musb)
+{
+	void __iomem *reg_base = musb->ctrl_base;
+	u32 mask;
+
+	/* Workaround: setup IRQs through both register sets. */
+	mask = ((musb->epmask & DA8XX_USB_TX_EP_MASK) << DA8XX_INTR_TX_SHIFT) |
+	       ((musb->epmask & DA8XX_USB_RX_EP_MASK) << DA8XX_INTR_RX_SHIFT) |
+	       DA8XX_INTR_USB_MASK;
+	musb_writel(reg_base, DA8XX_USB_INTR_MASK_SET_REG, mask);
+
+	/* Force the DRVVBUS IRQ so we can start polling for ID change. */
+	if (is_otg_enabled(musb))
+		musb_writel(reg_base, DA8XX_USB_INTR_SRC_SET_REG,
+			    DA8XX_INTR_DRVVBUS << DA8XX_INTR_USB_SHIFT);
+}
+
+/**
+ * musb_platform_disable - disable HDRC and flush interrupts
+ */
+void musb_platform_disable(struct musb *musb)
+{
+	void __iomem *reg_base = musb->ctrl_base;
+
+	musb_writel(reg_base, DA8XX_USB_INTR_MASK_CLEAR_REG,
+		    DA8XX_INTR_USB_MASK |
+		    DA8XX_INTR_TX_MASK | DA8XX_INTR_RX_MASK);
+	musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
+	musb_writel(reg_base, DA8XX_USB_END_OF_INTR_REG, 0);
+}
+
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+#define portstate(stmt) 	stmt
+#else
+#define portstate(stmt)
+#endif
+
+static void da8xx_set_vbus(struct musb *musb, int is_on)
+{
+	WARN_ON(is_on && is_peripheral_active(musb));
+}
+
+#define	POLL_SECONDS	2
+
+static struct timer_list otg_workaround;
+
+static void otg_timer(unsigned long _musb)
+{
+	struct musb		*musb = (void *)_musb;
+	void __iomem		*mregs = musb->mregs;
+	u8			devctl;
+	unsigned long		flags;
+
+	/*
+	 * We poll because DaVinci's won't expose several OTG-critical
+	 * status change events (from the transceiver) otherwise.
+	 */
+	devctl = musb_readb(mregs, MUSB_DEVCTL);
+	DBG(7, "Poll devctl %02x (%s)\n", devctl, otg_state_string(musb));
+
+	spin_lock_irqsave(&musb->lock, flags);
+	switch (musb->xceiv->state) {
+	case OTG_STATE_A_WAIT_BCON:
+		devctl &= ~MUSB_DEVCTL_SESSION;
+		musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
+
+		devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
+		if (devctl & MUSB_DEVCTL_BDEVICE) {
+			musb->xceiv->state = OTG_STATE_B_IDLE;
+			MUSB_DEV_MODE(musb);
+		} else {
+			musb->xceiv->state = OTG_STATE_A_IDLE;
+			MUSB_HST_MODE(musb);
+		}
+		break;
+	case OTG_STATE_A_WAIT_VFALL:
+		/*
+		 * Wait till VBUS falls below SessionEnd (~0.2 V); the 1.3
+		 * RTL seems to mis-handle session "start" otherwise (or in
+		 * our case "recover"), in routine "VBUS was valid by the time
+		 * VBUSERR got reported during enumeration" cases.
+		 */
+		if (devctl & MUSB_DEVCTL_VBUS) {
+			mod_timer(&otg_workaround, jiffies + POLL_SECONDS * HZ);
+			break;
+		}
+		musb->xceiv->state = OTG_STATE_A_WAIT_VRISE;
+		musb_writel(musb->ctrl_base, DA8XX_USB_INTR_SRC_SET_REG,
+			    MUSB_INTR_VBUSERROR << DA8XX_INTR_USB_SHIFT);
+		break;
+	case OTG_STATE_B_IDLE:
+		if (!is_peripheral_enabled(musb))
+			break;
+
+		/*
+		 * There's no ID-changed IRQ, so we have no good way to tell
+		 * when to switch to the A-Default state machine (by setting
+		 * the DEVCTL.Session bit).
+		 *
+		 * Workaround:  whenever we're in B_IDLE, try setting the
+		 * session flag every few seconds.  If it works, ID was
+		 * grounded and we're now in the A-Default state machine.
+		 *
+		 * NOTE: setting the session flag is _supposed_ to trigger
+		 * SRP but clearly it doesn't.
+		 */
+		musb_writeb(mregs, MUSB_DEVCTL, devctl | MUSB_DEVCTL_SESSION);
+		devctl = musb_readb(mregs, MUSB_DEVCTL);
+		if (devctl & MUSB_DEVCTL_BDEVICE)
+			mod_timer(&otg_workaround, jiffies + POLL_SECONDS * HZ);
+		else
+			musb->xceiv->state = OTG_STATE_A_IDLE;
+		break;
+	default:
+		break;
+	}
+	spin_unlock_irqrestore(&musb->lock, flags);
+}
+
+void musb_platform_try_idle(struct musb *musb, unsigned long timeout)
+{
+	static unsigned long last_timer;
+
+	if (!is_otg_enabled(musb))
+		return;
+
+	if (timeout == 0)
+		timeout = jiffies + msecs_to_jiffies(3);
+
+	/* Never idle if active, or when VBUS timeout is not set as host */
+	if (musb->is_active || (musb->a_wait_bcon == 0 &&
+				musb->xceiv->state == OTG_STATE_A_WAIT_BCON)) {
+		DBG(4, "%s active, deleting timer\n", otg_state_string(musb));
+		del_timer(&otg_workaround);
+		last_timer = jiffies;
+		return;
+	}
+
+	if (time_after(last_timer, timeout) && timer_pending(&otg_workaround)) {
+		DBG(4, "Longer idle timer already pending, ignoring...\n");
+		return;
+	}
+	last_timer = timeout;
+
+	DBG(4, "%s inactive, starting idle timer for %u ms\n",
+	    otg_state_string(musb), jiffies_to_msecs(timeout - jiffies));
+	mod_timer(&otg_workaround, timeout);
+}
+
+static irqreturn_t da8xx_interrupt(int irq, void *hci)
+{
+	struct musb		*musb = hci;
+	void __iomem		*reg_base = musb->ctrl_base;
+	unsigned long		flags;
+	irqreturn_t		ret = IRQ_NONE;
+	u32			status;
+
+	spin_lock_irqsave(&musb->lock, flags);
+
+	/*
+	 * NOTE: DA8XX shadows the Mentor IRQs.  Don't manage them through
+	 * the Mentor registers (except for setup), use the TI ones and EOI.
+	 */
+
+	/* Acknowledge and handle non-CPPI interrupts */
+	status = musb_readl(reg_base, DA8XX_USB_INTR_SRC_MASKED_REG);
+	if (!status)
+		goto eoi;
+
+	musb_writel(reg_base, DA8XX_USB_INTR_SRC_CLEAR_REG, status);
+	DBG(4, "USB IRQ %08x\n", status);
+
+	musb->int_rx = (status & DA8XX_INTR_RX_MASK) >> DA8XX_INTR_RX_SHIFT;
+	musb->int_tx = (status & DA8XX_INTR_TX_MASK) >> DA8XX_INTR_TX_SHIFT;
+	musb->int_usb = (status & DA8XX_INTR_USB_MASK) >> DA8XX_INTR_USB_SHIFT;
+
+	/*
+	 * DRVVBUS IRQs are the only proxy we have (a very poor one!) for
+	 * DA8xx's missing ID change IRQ.  We need an ID change IRQ to
+	 * switch appropriately between halves of the OTG state machine.
+	 * Managing DEVCTL.Session per Mentor docs requires that we know its
+	 * value but DEVCTL.BDevice is invalid without DEVCTL.Session set.
+	 * Also, DRVVBUS pulses for SRP (but not at 5 V)...
+	 */
+	if (status & (DA8XX_INTR_DRVVBUS << DA8XX_INTR_USB_SHIFT)) {
+		int drvvbus = musb_readl(reg_base, DA8XX_USB_STAT_REG);
+		void __iomem *mregs = musb->mregs;
+		u8 devctl = musb_readb(mregs, MUSB_DEVCTL);
+		int err;
+
+		err = is_host_enabled(musb) && (musb->int_usb &
+						MUSB_INTR_VBUSERROR);
+		if (err) {
+			/*
+			 * The Mentor core doesn't debounce VBUS as needed
+			 * to cope with device connect current spikes. This
+			 * means it's not uncommon for bus-powered devices
+			 * to get VBUS errors during enumeration.
+			 *
+			 * This is a workaround, but newer RTL from Mentor
+			 * seems to allow a better one: "re"-starting sessions
+			 * without waiting for VBUS to stop registering in
+			 * devctl.
+			 */
+			musb->int_usb &= ~MUSB_INTR_VBUSERROR;
+			musb->xceiv->state = OTG_STATE_A_WAIT_VFALL;
+			mod_timer(&otg_workaround, jiffies + POLL_SECONDS * HZ);
+			WARNING("VBUS error workaround (delay coming)\n");
+		} else if (is_host_enabled(musb) && drvvbus) {
+			MUSB_HST_MODE(musb);
+			musb->xceiv->default_a = 1;
+			musb->xceiv->state = OTG_STATE_A_WAIT_VRISE;
+			portstate(musb->port1_status |= USB_PORT_STAT_POWER);
+			del_timer(&otg_workaround);
+		} else {
+			musb->is_active = 0;
+			MUSB_DEV_MODE(musb);
+			musb->xceiv->default_a = 0;
+			musb->xceiv->state = OTG_STATE_B_IDLE;
+			portstate(musb->port1_status &= ~USB_PORT_STAT_POWER);
+		}
+
+		DBG(2, "VBUS %s (%s)%s, devctl %02x\n",
+				drvvbus ? "on" : "off",
+				otg_state_string(musb),
+				err ? " ERROR" : "",
+				devctl);
+		ret = IRQ_HANDLED;
+	}
+
+	if (musb->int_tx || musb->int_rx || musb->int_usb)
+		ret |= musb_interrupt(musb);
+
+ eoi:
+	/* EOI needs to be written for the IRQ to be re-asserted. */
+	if (ret == IRQ_HANDLED || status)
+		musb_writel(reg_base, DA8XX_USB_END_OF_INTR_REG, 0);
+
+	/* Poll for ID change */
+	if (is_otg_enabled(musb) && musb->xceiv->state == OTG_STATE_B_IDLE)
+		mod_timer(&otg_workaround, jiffies + POLL_SECONDS * HZ);
+
+	spin_unlock_irqrestore(&musb->lock, flags);
+
+	return ret;
+}
+
+int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
+{
+	u32 cfgchip2 = __raw_readl(CFGCHIP2);
+
+	cfgchip2 &= ~CFGCHIP2_OTGMODE;
+	switch (musb_mode) {
+#ifdef	CONFIG_USB_MUSB_HDRC_HCD
+	case MUSB_HOST:		/* Force VBUS valid, ID = 0 */
+		cfgchip2 |= CFGCHIP2_FORCE_HOST;
+		break;
+#endif
+#ifdef	CONFIG_USB_GADGET_MUSB_HDRC
+	case MUSB_PERIPHERAL:	/* Force VBUS valid, ID = 1 */
+		cfgchip2 |= CFGCHIP2_FORCE_DEVICE;
+		break;
+#endif
+#ifdef	CONFIG_USB_MUSB_OTG
+	case MUSB_OTG:		/* Don't override the VBUS/ID comparators */
+		cfgchip2 |= CFGCHIP2_NO_OVERRIDE;
+		break;
+#endif
+	default:
+		DBG(2, "Trying to set unsupported mode %u\n", musb_mode);
+	}
+
+	__raw_writel(cfgchip2, CFGCHIP2);
+	return 0;
+}
+
+int __init musb_platform_init(struct musb *musb, void *board_data)
+{
+	void __iomem *reg_base = musb->ctrl_base;
+	u32 rev;
+
+	musb->mregs += DA8XX_MENTOR_CORE_OFFSET;
+
+	clk_enable(musb->clock);
+
+	/* Returns zero if e.g. not clocked */
+	rev = musb_readl(reg_base, DA8XX_USB_REVISION_REG);
+	if (!rev)
+		goto fail;
+
+	usb_nop_xceiv_register();
+	musb->xceiv = otg_get_transceiver();
+	if (!musb->xceiv)
+		goto fail;
+
+	if (is_host_enabled(musb))
+		setup_timer(&otg_workaround, otg_timer, (unsigned long)musb);
+
+	musb->board_set_vbus = da8xx_set_vbus;
+
+	/* Reset the controller */
+	musb_writel(reg_base, DA8XX_USB_CTRL_REG, DA8XX_SOFT_RESET_MASK);
+
+	/* Start the on-chip PHY and its PLL. */
+	phy_on();
+
+	msleep(5);
+
+	/* NOTE: IRQs are in mixed mode, not bypass to pure MUSB */
+	pr_debug("DA8xx OTG revision %08x, PHY %03x, control %02x\n",
+		 rev, __raw_readl(CFGCHIP2),
+		 musb_readb(reg_base, DA8XX_USB_CTRL_REG));
+
+	musb->isr = da8xx_interrupt;
+	return 0;
+fail:
+	clk_disable(musb->clock);
+	return -ENODEV;
+}
+
+int musb_platform_exit(struct musb *musb)
+{
+	if (is_host_enabled(musb))
+		del_timer_sync(&otg_workaround);
+
+	phy_off();
+
+	otg_put_transceiver(musb->xceiv);
+	usb_nop_xceiv_unregister();
+
+	clk_disable(musb->clock);
+
+	return 0;
+}
Index: linux-2.6/drivers/usb/musb/musb_core.h
===================================================================
--- linux-2.6.orig/drivers/usb/musb/musb_core.h
+++ linux-2.6/drivers/usb/musb/musb_core.h
@@ -599,6 +599,7 @@ extern void musb_hnp_stop(struct musb *m
 extern int musb_platform_set_mode(struct musb *musb, u8 musb_mode);
 
 #if defined(CONFIG_USB_TUSB6010) || defined(CONFIG_BLACKFIN) || \
+	defined(CONFIG_ARCH_DAVINCI_DA8XX) || \
 	defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
 	defined(CONFIG_ARCH_OMAP4)
 extern void musb_platform_try_idle(struct musb *musb, unsigned long timeout);

From Jon.Povey at racelogic.co.uk  Mon Aug  9 00:19:37 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Mon, 9 Aug 2010 06:19:37 +0100
Subject: Linux Usb key and Fat buffer.
In-Reply-To: <4C5ADB12.9080606@imajing.fr>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0903D773B9@Cloud.RL.local>

Pierre wrote:
> we are expriencing a
> peridodic slow down of the writing speed of the images. We have not
> mounted the key as physically synchronised.

> - Should i use in my application a fifo buffer for writing data to
> avoid the slow down?

I found similar things a while back with 2.6.10, ended up splitting the app into two threads, producer and writer. That worked to smooth out the slow spots.

As for the underlying cause.. I'd love to know.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From sshtylyov at mvista.com  Mon Aug  9 04:39:13 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Mon, 09 Aug 2010 13:39:13 +0400
Subject: [PATCH RFC v9] MUSB: DA8xx/OMAP-L1x glue layer
In-Reply-To: <20100808175433.GA6442@suse.de>
References: <201008082122.40610.sshtylyov@ru.mvista.com>
	<20100808175433.GA6442@suse.de>
Message-ID: <4C5FCCC1.4060901@ru.mvista.com>

Hello.

Greg KH wrote:

>> Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver.

>> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>> Signed-off-by: Yadviga Grigorieva <yadviga at ru.mvista.com>

>> ---
>> The patch is against the recent Linus' tree. Felipe, please ACK it soonish,
>> so it can go into 2.6.36 at last...

> It's too late for .36, sorry, patches needed to be in my tree _before_
> the merge window opened.

    How much longer will I have to wait with this, I wonder?
You could have merged version 8 but Felipe just ignored it. :-(

> thanks,

> greg k-h

WBR, Sergei

From nsekhar at ti.com  Mon Aug  9 05:16:34 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon,  9 Aug 2010 15:46:34 +0530
Subject: [PATCH 0/6] davinci: add support for aemif timing configuration
Message-ID: <1281349000-822-1-git-send-email-nsekhar@ti.com>

This series of patches adds support for AEMIF timing configuration
for DaVinci SoCs.

Currently AEMIF timing configuration is done as a special case for
DM644x EVM. This work provides for a generic way of doing this.

David,
	Patch 1/6 and 2/6 of this series touch the
	drivers/mtd/nand/davinci_nand.c file along with other arch specific
	files. Based on the discussion on DaVinci list, Kevin is OK to merge
	this with your agreement. Please let us know how to proceed.

Sekhar Nori (5):
  davinci: add support for aemif timing configuration
  nand: davinci: add support for timing configuration
  davinci: dm644x evm: setup NAND flash timing
  davinci: am18x/da850/omap-l138 evm: setup NAND flash timing
  davinci: dm6467t evm: setup NAND flash timing

Sudhakar Rajashekhara (1):
  davinci: am17x/da830/omap-l137 evm: setup NAND flash timing

 arch/arm/mach-davinci/Makefile             |    2 +-
 arch/arm/mach-davinci/aemif.c              |  133 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/board-da830-evm.c    |   12 +++
 arch/arm/mach-davinci/board-da850-evm.c    |   12 +++
 arch/arm/mach-davinci/board-dm644x-evm.c   |   12 +++
 arch/arm/mach-davinci/board-dm646x-evm.c   |   14 +++
 arch/arm/mach-davinci/include/mach/aemif.h |   36 ++++++++
 arch/arm/mach-davinci/include/mach/nand.h  |    6 +-
 drivers/mtd/nand/davinci_nand.c            |   61 +++++--------
 9 files changed, 246 insertions(+), 42 deletions(-)
 create mode 100644 arch/arm/mach-davinci/aemif.c
 create mode 100644 arch/arm/mach-davinci/include/mach/aemif.h


From nsekhar at ti.com  Mon Aug  9 05:16:37 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon,  9 Aug 2010 15:46:37 +0530
Subject: [PATCH 3/6] davinci: dm644x evm: setup NAND flash timing
In-Reply-To: <1281349000-822-3-git-send-email-nsekhar@ti.com>
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
	<1281349000-822-2-git-send-email-nsekhar@ti.com>
	<1281349000-822-3-git-send-email-nsekhar@ti.com>
Message-ID: <1281349000-822-4-git-send-email-nsekhar@ti.com>

The DM644x EVM nand flash timing was earlier being
done as a special case in the NAND driver itself.

With the NAND driver now capable of progamming the
AEMIF interface using timing data passed from the
platform, the timing values are being moved into
their rightful place in the EVM specific board file.

The values being programmed match what was being done
earlier and thus do not represent any change in
performance/functionality.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
---
 arch/arm/mach-davinci/board-dm644x-evm.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 34c8b41..65bb940 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -37,6 +37,7 @@
 #include <mach/nand.h>
 #include <mach/mmc.h>
 #include <mach/usb.h>
+#include <mach/aemif.h>
 
 #define DM644X_EVM_PHY_MASK		(0x2)
 #define DM644X_EVM_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
@@ -137,11 +138,22 @@ static struct mtd_partition davinci_evm_nandflash_partition[] = {
 	 */
 };
 
+static struct davinci_aemif_timing davinci_evm_nandflash_timing = {
+	.wsetup		= 20,
+	.wstrobe	= 40,
+	.whold		= 20,
+	.rsetup		= 10,
+	.rstrobe	= 40,
+	.rhold		= 10,
+	.ta		= 40,
+};
+
 static struct davinci_nand_pdata davinci_evm_nandflash_data = {
 	.parts		= davinci_evm_nandflash_partition,
 	.nr_parts	= ARRAY_SIZE(davinci_evm_nandflash_partition),
 	.ecc_mode	= NAND_ECC_HW,
 	.options	= NAND_USE_FLASH_BBT,
+	.timing		= &davinci_evm_nandflash_timing,
 };
 
 static struct resource davinci_evm_nandflash_resource[] = {
-- 
1.6.2.4


From nsekhar at ti.com  Mon Aug  9 05:16:40 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon,  9 Aug 2010 15:46:40 +0530
Subject: [PATCH v2 6/6] davinci: dm6467t evm: setup NAND flash timing
In-Reply-To: <1281349000-822-6-git-send-email-nsekhar@ti.com>
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
	<1281349000-822-2-git-send-email-nsekhar@ti.com>
	<1281349000-822-3-git-send-email-nsekhar@ti.com>
	<1281349000-822-4-git-send-email-nsekhar@ti.com>
	<1281349000-822-5-git-send-email-nsekhar@ti.com>
	<1281349000-822-6-git-send-email-nsekhar@ti.com>
Message-ID: <1281349000-822-7-git-send-email-nsekhar@ti.com>

Setup NAND flash timing on DM6467T EVM.

Without the timing setup, the NAND flash on DM6467T
RevC EVM reports a number of random bad blocks because
of read errors.

Also, with this, copying a 100M file on RevB EVM takes
~35 sec against 1 minute 30 seconds earlier.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
---
v2: DM6467T and DM6467 EVMs use slightly different NAND parts, made the
    timing configuration specific to DM6467T.

 arch/arm/mach-davinci/board-dm646x-evm.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index b8b1dec..c8843c9 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -42,6 +42,7 @@
 #include <mach/nand.h>
 #include <mach/clock.h>
 #include <mach/cdce949.h>
+#include <mach/aemif.h>
 
 #include "clock.h"
 
@@ -71,6 +72,16 @@ static struct mtd_partition davinci_nand_partitions[] = {
 	}
 };
 
+static struct davinci_aemif_timing dm6467tevm_nandflash_timing = {
+	.wsetup		= 29,
+	.wstrobe	= 24,
+	.whold		= 14,
+	.rsetup		= 19,
+	.rstrobe	= 33,
+	.rhold		= 0,
+	.ta		= 29,
+};
+
 static struct davinci_nand_pdata davinci_nand_data = {
 	.mask_cle 		= 0x80000,
 	.mask_ale 		= 0x40000,
@@ -763,6 +774,9 @@ static __init void evm_init(void)
 	dm646x_init_mcasp0(&dm646x_evm_snd_data[0]);
 	dm646x_init_mcasp1(&dm646x_evm_snd_data[1]);
 
+	if (machine_is_davinci_dm6467tevm())
+		davinci_nand_data.timing = &dm6467tevm_nandflash_timing;
+
 	platform_device_register(&davinci_nand_device);
 
 	dm646x_init_edma(dm646x_edma_rsv);
-- 
1.6.2.4


From nsekhar at ti.com  Mon Aug  9 05:16:36 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon,  9 Aug 2010 15:46:36 +0530
Subject: [PATCH v2 2/6] nand: davinci: add support for timing configuration
In-Reply-To: <1281349000-822-2-git-send-email-nsekhar@ti.com>
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
	<1281349000-822-2-git-send-email-nsekhar@ti.com>
Message-ID: <1281349000-822-3-git-send-email-nsekhar@ti.com>

This patch modifies the DaVinci NAND driver to use the
new AEMIF timing setup API to configure the NAND access
timings.

Earlier, AEMIF configuration was being done as a special
case for DM644x board, but now more boards emerge which have
capability to boot for other media (SPI flash, NOR flash) and
have the kernel access NAND flash. This means that kernel cannot
always  depend on the bootloader to setup the NAND.

Also, on platforms such as da850/omap-l138, the aemif input
frequency changes as cpu frequency changes; necessiating
re-calculation of timimg values as part of cpufreq transtitions.
This patch forms the basis for adding that support.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
---
v2: no need to include aemif.h in nand.c in this patch since patch 1/6 does
    that now.

 arch/arm/mach-davinci/include/mach/nand.h |    3 +
 drivers/mtd/nand/davinci_nand.c           |   60 ++++++++++------------------
 2 files changed, 25 insertions(+), 38 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/nand.h b/arch/arm/mach-davinci/include/mach/nand.h
index b5893f0..0251510 100644
--- a/arch/arm/mach-davinci/include/mach/nand.h
+++ b/arch/arm/mach-davinci/include/mach/nand.h
@@ -80,6 +80,9 @@ struct davinci_nand_pdata {		/* platform_data */
 	/* Main and mirror bbt descriptor overrides */
 	struct nand_bbt_descr	*bbt_td;
 	struct nand_bbt_descr	*bbt_md;
+
+	/* Access timings */
+	struct davinci_aemif_timing	*timing;
 };
 
 #endif	/* __ARCH_ARM_DAVINCI_NAND_H */
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 8e2d56c..8beb0d0 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -75,6 +75,8 @@ struct davinci_nand_info {
 	uint32_t		mask_cle;
 
 	uint32_t		core_chipsel;
+
+	struct davinci_aemif_timing	*timing;
 };
 
 static DEFINE_SPINLOCK(davinci_nand_lock);
@@ -479,36 +481,6 @@ static int nand_davinci_dev_ready(struct mtd_info *mtd)
 	return davinci_nand_readl(info, NANDFSR_OFFSET) & BIT(0);
 }
 
-static void __init nand_dm6446evm_flash_init(struct davinci_nand_info *info)
-{
-	uint32_t regval, a1cr;
-
-	/*
-	 * NAND FLASH timings @ PLL1 == 459 MHz
-	 *  - AEMIF.CLK freq   = PLL1/6 = 459/6 = 76.5 MHz
-	 *  - AEMIF.CLK period = 1/76.5 MHz = 13.1 ns
-	 */
-	regval = 0
-		| (0 << 31)           /* selectStrobe */
-		| (0 << 30)           /* extWait (never with NAND) */
-		| (1 << 26)           /* writeSetup      10 ns */
-		| (3 << 20)           /* writeStrobe     40 ns */
-		| (1 << 17)           /* writeHold       10 ns */
-		| (0 << 13)           /* readSetup       10 ns */
-		| (3 << 7)            /* readStrobe      60 ns */
-		| (0 << 4)            /* readHold        10 ns */
-		| (3 << 2)            /* turnAround      ?? ns */
-		| (0 << 0)            /* asyncSize       8-bit bus */
-		;
-	a1cr = davinci_nand_readl(info, A1CR_OFFSET);
-	if (a1cr != regval) {
-		dev_dbg(info->dev, "Warning: NAND config: Set A1CR " \
-		       "reg to 0x%08x, was 0x%08x, should be done by " \
-		       "bootloader.\n", regval, a1cr);
-		davinci_nand_writel(info, A1CR_OFFSET, regval);
-	}
-}
-
 /*----------------------------------------------------------------------*/
 
 /* An ECC layout for using 4-bit ECC with small-page flash, storing
@@ -612,6 +584,7 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
 	info->chip.options	= pdata->options;
 	info->chip.bbt_td	= pdata->bbt_td;
 	info->chip.bbt_md	= pdata->bbt_md;
+	info->timing		= pdata->timing;
 
 	info->ioaddr		= (uint32_t __force) vaddr;
 
@@ -689,15 +662,25 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
 		goto err_clk_enable;
 	}
 
-	/* EMIF timings should normally be set by the boot loader,
-	 * especially after boot-from-NAND.  The *only* reason to
-	 * have this special casing for the DM6446 EVM is to work
-	 * with boot-from-NOR ... with CS0 manually re-jumpered
-	 * (after startup) so it addresses the NAND flash, not NOR.
-	 * Even for dev boards, that's unusually rude...
+	/*
+	 * Setup Async configuration register in case we did not boot from
+	 * NAND and so bootloader did not bother to set it up.
 	 */
-	if (machine_is_davinci_evm())
-		nand_dm6446evm_flash_init(info);
+	val = davinci_nand_readl(info, A1CR_OFFSET + info->core_chipsel * 4);
+
+	/* Extended Wait is not valid and Select Strobe mode is not used */
+	val &= ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
+	if (info->chip.options & NAND_BUSWIDTH_16)
+		val |= 0x1;
+
+	davinci_nand_writel(info, A1CR_OFFSET + info->core_chipsel * 4, val);
+
+	ret = davinci_aemif_setup_timing(info->timing, info->base,
+							info->core_chipsel);
+	if (ret < 0) {
+		dev_dbg(&pdev->dev, "NAND timing values setup fail\n");
+		goto err_timing;
+	}
 
 	spin_lock_irq(&davinci_nand_lock);
 
@@ -810,6 +793,7 @@ syndrome_done:
 	return 0;
 
 err_scan:
+err_timing:
 	clk_disable(info->clk);
 
 err_clk_enable:
-- 
1.6.2.4


From nsekhar at ti.com  Mon Aug  9 05:16:35 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon,  9 Aug 2010 15:46:35 +0530
Subject: [PATCH v3 1/6] davinci: add support for aemif timing configuration
In-Reply-To: <1281349000-822-1-git-send-email-nsekhar@ti.com>
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
Message-ID: <1281349000-822-2-git-send-email-nsekhar@ti.com>

This patch adds support to configure the AEMIF interface
with supplied timing values.

Since this capability is useful both from NOR and NAND
flashes, it is provided as a new interface and in a file
of its own.

AEMIF timing configuration is required in cases:

1) Where the AEMIF clock rate can change at runtime (a side
   affect of cpu frequency change).

2) Where U-Boot does not support NAND/NOR but supports other
   media like SPI Flash or MMC/SD and thus does not care about
   setting up the AEMIF timing for kernel to use.

3) Where U-Boot just hasn't configured the timing values and
   cannot be upgraded because the box is already in the field.

Since there is now a header file for AEMIF interface, the
common (non-NAND specific) defines for AEMIF registers have
been moved from nand.h into the newly created aemif.h

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
---
v3: use NSEC_PER_MSEC from <linux/time.h> instead of defining a new macro

 arch/arm/mach-davinci/Makefile             |    2 +-
 arch/arm/mach-davinci/aemif.c              |  133 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/aemif.h |   36 ++++++++
 arch/arm/mach-davinci/include/mach/nand.h  |    3 -
 drivers/mtd/nand/davinci_nand.c            |    1 +
 5 files changed, 171 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-davinci/aemif.c
 create mode 100644 arch/arm/mach-davinci/include/mach/aemif.h

diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..77a0f71 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
 
 # Common objects
 obj-y 			:= time.o clock.o serial.o io.o psc.o \
-			   gpio.o dma.o usb.o common.o sram.o
+			   gpio.o dma.o usb.o common.o sram.o aemif.o
 
 obj-$(CONFIG_DAVINCI_MUX)		+= mux.o
 
diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
new file mode 100644
index 0000000..9c3f500
--- /dev/null
+++ b/arch/arm/mach-davinci/aemif.c
@@ -0,0 +1,133 @@
+/*
+ * AEMIF support for DaVinci SoCs
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.com/
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/time.h>
+
+#include <mach/aemif.h>
+
+/* Timing value configuration */
+
+#define TA(x)		((x) << 2)
+#define RHOLD(x)	((x) << 4)
+#define RSTROBE(x)	((x) << 7)
+#define RSETUP(x)	((x) << 13)
+#define WHOLD(x)	((x) << 17)
+#define WSTROBE(x)	((x) << 20)
+#define WSETUP(x)	((x) << 26)
+
+#define TA_MAX		0x3
+#define RHOLD_MAX	0x7
+#define RSTROBE_MAX	0x3f
+#define RSETUP_MAX	0xf
+#define WHOLD_MAX	0x7
+#define WSTROBE_MAX	0x3f
+#define WSETUP_MAX	0xf
+
+#define TIMING_MASK	(TA(TA_MAX) | \
+				RHOLD(RHOLD_MAX) | \
+				RSTROBE(RSTROBE_MAX) |	\
+				RSETUP(RSETUP_MAX) | \
+				WHOLD(WHOLD_MAX) | \
+				WSTROBE(WSTROBE_MAX) | \
+				WSETUP(WSETUP_MAX))
+
+/*
+ * aemif_calc_rate - calculate timing data.
+ * @wanted: The cycle time needed in nanoseconds.
+ * @clk: The input clock rate in kHz.
+ * @max: The maximum divider value that can be programmed.
+ *
+ * On success, returns the calculated timing value minus 1 for easy
+ * programming into AEMIF timing registers, else negative errno.
+ */
+static int aemif_calc_rate(int wanted, unsigned long clk, int max)
+{
+	int result;
+
+	result = DIV_ROUND_UP((wanted * clk), NSEC_PER_MSEC) - 1;
+
+	pr_debug("%s: result %d from %ld, %d\n", __func__, result, clk, wanted);
+
+	/* It is generally OK to have a more relaxed timing than requested... */
+	if (result < 0)
+		result = 0;
+
+	/* ... But configuring tighter timings is not an option. */
+	else if (result > max)
+		result = -EINVAL;
+
+	return result;
+}
+
+/**
+ * davinci_aemif_setup_timing - setup timing values for a given AEMIF interface
+ * @t: timing values to be progammed
+ * @base: The virtual base address of the AEMIF interface
+ * @cs: chip-select to program the timing values for
+ *
+ * This function programs the given timing values (in real clock) into the
+ * AEMIF registers taking the AEMIF clock into account.
+ *
+ * This function does not use any locking while programming the AEMIF
+ * because it is expected that there is only one user of a given
+ * chip-select.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
+					void __iomem *base, unsigned cs)
+{
+	unsigned set, val;
+	unsigned ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup;
+	unsigned offset = A1CR_OFFSET + cs * 4;
+	struct clk *aemif_clk;
+	unsigned long clkrate;
+
+	if (!t)
+		return 0;	/* Nothing to do */
+
+	aemif_clk = clk_get(NULL, "aemif");
+	if (IS_ERR(aemif_clk))
+		return PTR_ERR(aemif_clk);
+
+	clkrate = clk_get_rate(aemif_clk);
+
+	clkrate /= 1000;	/* turn clock into kHz for ease of use */
+
+	ta	= aemif_calc_rate(t->ta, clkrate, TA_MAX);
+	rhold	= aemif_calc_rate(t->rhold, clkrate, RHOLD_MAX);
+	rstrobe	= aemif_calc_rate(t->rstrobe, clkrate, RSTROBE_MAX);
+	rsetup	= aemif_calc_rate(t->rsetup, clkrate, RSETUP_MAX);
+	whold	= aemif_calc_rate(t->whold, clkrate, WHOLD_MAX);
+	wstrobe	= aemif_calc_rate(t->wstrobe, clkrate, WSTROBE_MAX);
+	wsetup	= aemif_calc_rate(t->wsetup, clkrate, WSETUP_MAX);
+
+	if (ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 ||
+			whold < 0 || wstrobe < 0 || wsetup < 0) {
+		pr_err("%s: cannot get suitable timings\n", __func__);
+		return -EINVAL;
+	}
+
+	set = TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | RSETUP(rsetup) |
+		WHOLD(whold) | WSTROBE(wstrobe) | WSETUP(wsetup);
+
+	val = __raw_readl(base + offset);
+	val &= ~TIMING_MASK;
+	val |= set;
+	__raw_writel(val, base + offset);
+
+	return 0;
+}
+EXPORT_SYMBOL(davinci_aemif_setup_timing);
diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/arch/arm/mach-davinci/include/mach/aemif.h
new file mode 100644
index 0000000..05b2934
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/aemif.h
@@ -0,0 +1,36 @@
+/*
+ * TI DaVinci AEMIF support
+ *
+ * Copyright 2010 (C) Texas Instruments, Inc. http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+#ifndef _MACH_DAVINCI_AEMIF_H
+#define _MACH_DAVINCI_AEMIF_H
+
+#define NRCSR_OFFSET		0x00
+#define AWCCR_OFFSET		0x04
+#define A1CR_OFFSET		0x10
+
+#define ACR_ASIZE_MASK		0x3
+#define ACR_EW_MASK		BIT(30)
+#define ACR_SS_MASK		BIT(31)
+
+/* All timings in nanoseconds */
+struct davinci_aemif_timing {
+	u8	wsetup;
+	u8	wstrobe;
+	u8	whold;
+
+	u8	rsetup;
+	u8	rstrobe;
+	u8	rhold;
+
+	u8	ta;
+};
+
+int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
+					void __iomem *base, unsigned cs);
+#endif
diff --git a/arch/arm/mach-davinci/include/mach/nand.h b/arch/arm/mach-davinci/include/mach/nand.h
index b2ad809..b5893f0 100644
--- a/arch/arm/mach-davinci/include/mach/nand.h
+++ b/arch/arm/mach-davinci/include/mach/nand.h
@@ -30,9 +30,6 @@
 
 #include <linux/mtd/nand.h>
 
-#define NRCSR_OFFSET		0x00
-#define AWCCR_OFFSET		0x04
-#define A1CR_OFFSET		0x10
 #define NANDFCR_OFFSET		0x60
 #define NANDFSR_OFFSET		0x64
 #define NANDF1ECC_OFFSET	0x70
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 2ac7367..8e2d56c 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -35,6 +35,7 @@
 #include <linux/slab.h>
 
 #include <mach/nand.h>
+#include <mach/aemif.h>
 
 #include <asm/mach-types.h>
 
-- 
1.6.2.4


From nsekhar at ti.com  Mon Aug  9 05:16:38 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon,  9 Aug 2010 15:46:38 +0530
Subject: [PATCH 4/6] davinci: am17x/da830/omap-l137 evm: setup NAND flash
	timing
In-Reply-To: <1281349000-822-4-git-send-email-nsekhar@ti.com>
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
	<1281349000-822-2-git-send-email-nsekhar@ti.com>
	<1281349000-822-3-git-send-email-nsekhar@ti.com>
	<1281349000-822-4-git-send-email-nsekhar@ti.com>
Message-ID: <1281349000-822-5-git-send-email-nsekhar@ti.com>

From: Sudhakar Rajashekhara <sudhakar.raj at ti.com>

Setup the NAND flash timings for DA830 EVM.

Before configuring the timing values, throughput calculation
using dd command yielded 477 kB/s write and 970 kB/s read speed.

After the timing configuration, the throughput was measured to
be 2.5 MB/s write and 5.1 MB/s read.

[Mukul Bhatnagar: actual calculation of timing values from the
NAND datasheet]

Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
Cc: Mukul Bhatnagar <mbhatnagar at ti.com>
Signed-off-by: Sekhar Nori <nsekhar at ti.com>
Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
---
 arch/arm/mach-davinci/board-da830-evm.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index b61e872..4edbf3d 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -29,6 +29,7 @@
 #include <mach/nand.h>
 #include <mach/da8xx.h>
 #include <mach/usb.h>
+#include <mach/aemif.h>
 
 #define DA830_EVM_PHY_MASK		0x0
 #define DA830_EVM_MDIO_FREQUENCY	2200000	/* PHY bus frequency */
@@ -360,6 +361,16 @@ static struct nand_bbt_descr da830_evm_nand_bbt_mirror_descr = {
 	.pattern	= da830_evm_nand_mirror_pattern
 };
 
+static struct davinci_aemif_timing da830_evm_nandflash_timing = {
+	.wsetup         = 24,
+	.wstrobe        = 21,
+	.whold          = 14,
+	.rsetup         = 19,
+	.rstrobe        = 50,
+	.rhold          = 0,
+	.ta             = 20,
+};
+
 static struct davinci_nand_pdata da830_evm_nand_pdata = {
 	.parts		= da830_evm_nand_partitions,
 	.nr_parts	= ARRAY_SIZE(da830_evm_nand_partitions),
@@ -368,6 +379,7 @@ static struct davinci_nand_pdata da830_evm_nand_pdata = {
 	.options	= NAND_USE_FLASH_BBT,
 	.bbt_td		= &da830_evm_nand_bbt_main_descr,
 	.bbt_md		= &da830_evm_nand_bbt_mirror_descr,
+	.timing         = &da830_evm_nandflash_timing,
 };
 
 static struct resource da830_evm_nand_resources[] = {
-- 
1.6.2.4


From nsekhar at ti.com  Mon Aug  9 05:16:39 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon,  9 Aug 2010 15:46:39 +0530
Subject: [PATCH 5/6] davinci: am18x/da850/omap-l138 evm: setup NAND flash
	timing
In-Reply-To: <1281349000-822-5-git-send-email-nsekhar@ti.com>
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
	<1281349000-822-2-git-send-email-nsekhar@ti.com>
	<1281349000-822-3-git-send-email-nsekhar@ti.com>
	<1281349000-822-4-git-send-email-nsekhar@ti.com>
	<1281349000-822-5-git-send-email-nsekhar@ti.com>
Message-ID: <1281349000-822-6-git-send-email-nsekhar@ti.com>

Setup the NAND flash timings for DA850 EVM

Before configuring the timing values, throughput calculation
using dd command yielded 469 kB/s write and 966 kB/s read speed.

After the timing configuration, the throughput was measured to
be 2.4 MB/s write and 5 MB/s read.

[Mukul Bhatnagar: actual calculation of timing values from the
NAND datasheet]

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
Cc: Mukul Bhatnagar <mbhatnagar at ti.com>
Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index fa429cc..b5ac86f 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -36,6 +36,7 @@
 #include <mach/da8xx.h>
 #include <mach/nand.h>
 #include <mach/mux.h>
+#include <mach/aemif.h>
 
 #define DA850_EVM_PHY_MASK		0x1
 #define DA850_EVM_MDIO_FREQUENCY	2200000 /* PHY bus frequency */
@@ -143,12 +144,23 @@ static struct mtd_partition da850_evm_nandflash_partition[] = {
 	},
 };
 
+static struct davinci_aemif_timing da850_evm_nandflash_timing = {
+	.wsetup		= 24,
+	.wstrobe	= 21,
+	.whold		= 14,
+	.rsetup		= 19,
+	.rstrobe	= 50,
+	.rhold		= 0,
+	.ta		= 20,
+};
+
 static struct davinci_nand_pdata da850_evm_nandflash_data = {
 	.parts		= da850_evm_nandflash_partition,
 	.nr_parts	= ARRAY_SIZE(da850_evm_nandflash_partition),
 	.ecc_mode	= NAND_ECC_HW,
 	.ecc_bits	= 4,
 	.options	= NAND_USE_FLASH_BBT,
+	.timing		= &da850_evm_nandflash_timing,
 };
 
 static struct resource da850_evm_nandflash_resource[] = {
-- 
1.6.2.4


From nsekhar at ti.com  Mon Aug  9 05:33:14 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 9 Aug 2010 16:03:14 +0530
Subject: [PATCH 2/2] davinci: am18x/da850/omap-l138: add support for
	higher frequencies
In-Reply-To: <87d3twvrtr.fsf@deeprootsystems.com>
References: <1278491570-11832-1-git-send-email-nsekhar@ti.com>
	<1278491570-11832-2-git-send-email-nsekhar@ti.com>
	<87d3twvrtr.fsf@deeprootsystems.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E800C353@dbde02.ent.ti.com>

Hi Kevin,

On Thu, Aug 05, 2010 at 23:56:40, Kevin Hilman wrote:
> Sekhar Nori <nsekhar at ti.com> writes:
>
> > AM18x/DA850/OMAP-L138 SoCs have variants that can operate
> > at a maximum of 456 MHz at 1.3V operating point. Also the
> > 1.2V operating point has a variant that can support a maximum
> > of 372 MHz.
> >
> > This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz)
> > to the list of DA850 OPPs.
> >
> > Not all silicon is qualified to run at higher speeds and
> > unfortunately the maximum speed the chip can support can only
> > be read from the label on the package (not software readable).
>
> doh
>
> > Because of this, kernel configuration options have been
> > introduced to help users enable higher speeds if they know
> > that their slicon can support the higher speed.
>
> I don't like introducing Kconfig options for this kind of thing.
>
> For example, what if you want one kernel binary to support different
> speed-qualified parts?
>
> I'd rather have this configurable at runtime using the board files.
> Make the default the common speed, and folks with parts with higher
> qualified chips can make changes in their board file.

Right, using DA850 specific configuration will force all boards to
the same maximum speed. Hadn't thought of that! Will come up with
some board specific control of max cpufreq speed.

For the EVM, Kconfig still seems to be the way to go since the same
EVM could be populated with different speed grade devices. U-Boot
doesn't have to change when a different speed grade device is used so
forcing a different U-Boot build (just to pass a different machine type
or ATAG_REVISION) seems bad idea as well.

Thanks,
Sekhar

From khilman at deeprootsystems.com  Mon Aug  9 09:33:56 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 09 Aug 2010 07:33:56 -0700
Subject: [PATCH 2/2] davinci: am18x/da850/omap-l138: add support for
	higher frequencies
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E800C353@dbde02.ent.ti.com>
	(Sekhar Nori's message of "Mon, 9 Aug 2010 16:03:14 +0530")
References: <1278491570-11832-1-git-send-email-nsekhar@ti.com>
	<1278491570-11832-2-git-send-email-nsekhar@ti.com>
	<87d3twvrtr.fsf@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E800C353@dbde02.ent.ti.com>
Message-ID: <87aaovn9d7.fsf@deeprootsystems.com>

"Nori, Sekhar" <nsekhar at ti.com> writes:

> Hi Kevin,
>
> On Thu, Aug 05, 2010 at 23:56:40, Kevin Hilman wrote:
>> Sekhar Nori <nsekhar at ti.com> writes:
>>
>> > AM18x/DA850/OMAP-L138 SoCs have variants that can operate
>> > at a maximum of 456 MHz at 1.3V operating point. Also the
>> > 1.2V operating point has a variant that can support a maximum
>> > of 372 MHz.
>> >
>> > This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz)
>> > to the list of DA850 OPPs.
>> >
>> > Not all silicon is qualified to run at higher speeds and
>> > unfortunately the maximum speed the chip can support can only
>> > be read from the label on the package (not software readable).
>>
>> doh
>>
>> > Because of this, kernel configuration options have been
>> > introduced to help users enable higher speeds if they know
>> > that their slicon can support the higher speed.
>>
>> I don't like introducing Kconfig options for this kind of thing.
>>
>> For example, what if you want one kernel binary to support different
>> speed-qualified parts?
>>
>> I'd rather have this configurable at runtime using the board files.
>> Make the default the common speed, and folks with parts with higher
>> qualified chips can make changes in their board file.
>
> Right, using DA850 specific configuration will force all boards to
> the same maximum speed. Hadn't thought of that! Will come up with
> some board specific control of max cpufreq speed.
>
> For the EVM, Kconfig still seems to be the way to go since the same
> EVM could be populated with different speed grade devices. U-Boot
> doesn't have to change when a different speed grade device is used so
> forcing a different U-Boot build (just to pass a different machine type
> or ATAG_REVISION) seems bad idea as well.

Whether it's Kconfig or board-file, you'll have to re-compile to support
these parts.   I prefer board-file, but will accept Kconfig-based if
that's your preference.

This is why the HW folks should be reminded that this kind of difference
should be detectable in SW. :)

Kevin


From michael.williamson at criticallink.com  Mon Aug  9 09:57:25 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Mon, 09 Aug 2010 10:57:25 -0400
Subject: [PATCH 2/2] davinci: am18x/da850/omap-l138: add support for higher
	frequencies
In-Reply-To: <87aaovn9d7.fsf@deeprootsystems.com>
References: <1278491570-11832-1-git-send-email-nsekhar@ti.com>	<1278491570-11832-2-git-send-email-nsekhar@ti.com>	<87d3twvrtr.fsf@deeprootsystems.com>	<B85A65D85D7EB246BE421B3FB0FBB59301E800C353@dbde02.ent.ti.com>
	<87aaovn9d7.fsf@deeprootsystems.com>
Message-ID: <4C601755.5030807@criticallink.com>

 On 8/9/2010 10:33 AM, Kevin Hilman wrote:

> "Nori, Sekhar" <nsekhar at ti.com> writes:
>
>> Hi Kevin,
>>
>> On Thu, Aug 05, 2010 at 23:56:40, Kevin Hilman wrote:
>>> Sekhar Nori <nsekhar at ti.com> writes:
>>>
>>>> AM18x/DA850/OMAP-L138 SoCs have variants that can operate
>>>> at a maximum of 456 MHz at 1.3V operating point. Also the
>>>> 1.2V operating point has a variant that can support a maximum
>>>> of 372 MHz.
>>>>
>>>> This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz)
>>>> to the list of DA850 OPPs.
>>>>
>>>> Not all silicon is qualified to run at higher speeds and
>>>> unfortunately the maximum speed the chip can support can only
>>>> be read from the label on the package (not software readable).
>>>
>>> doh
>>>
>>>> Because of this, kernel configuration options have been
>>>> introduced to help users enable higher speeds if they know
>>>> that their slicon can support the higher speed.
>>>
>>> I don't like introducing Kconfig options for this kind of thing.
>>>
>>> For example, what if you want one kernel binary to support different
>>> speed-qualified parts?
>>>
>>> I'd rather have this configurable at runtime using the board files.
>>> Make the default the common speed, and folks with parts with higher
>>> qualified chips can make changes in their board file.
>>
>> Right, using DA850 specific configuration will force all boards to
>> the same maximum speed. Hadn't thought of that! Will come up with
>> some board specific control of max cpufreq speed.
>>
>> For the EVM, Kconfig still seems to be the way to go since the same
>> EVM could be populated with different speed grade devices. U-Boot
>> doesn't have to change when a different speed grade device is used so
>> forcing a different U-Boot build (just to pass a different machine type
>> or ATAG_REVISION) seems bad idea as well.
>
> Whether it's Kconfig or board-file, you'll have to re-compile to support
> these parts.   I prefer board-file, but will accept Kconfig-based if
> that's your preference.
>
> This is why the HW folks should be reminded that this kind of difference
> should be detectable in SW. :)
>



I have a bit of kernel newbie question about this and some other items
that seem to fall into the same category.  Would it be bad to make the
maximum CPU clock some sort of run-time configurable attribute in sysfs
or in /proc (root writable only, of course)?  Initialize it to the
"safe" rate then allow users to bump it up if they have a chip that
supports it?

I had a similar questions about things like the video timings for the
da8xx_fb driver (e.g., to be able to switch from 640x480 to 1024x768,
etc) and the SPI driver (clock speed, polarity, wordsize, etc.). 

Or is hardcoding these parameters and generating unique board files
whenever something varies the way to go?  Is there a rule-of-thumb for
making items runtime verses compile time parameters?

Thank you for any insight.

-Mike



From wenaideyu at gmail.com  Mon Aug  9 10:41:11 2010
From: wenaideyu at gmail.com (wenaideyu wenaideyu)
Date: Mon, 9 Aug 2010 23:41:11 +0800
Subject: The 6467t evm goes to reset immediately after the switching to PCI 
	mode from nand
Message-ID: <AANLkTi=rBAatFOcg7jXb9QYYzruVnVgr+dKANj3XZwO+@mail.gmail.com>

Hi:

    The 6467t evm reset immediately when I try to switch to PCI mode
on evm by the following steps:

    1 I turn the sw3 in evm borads to boot from nandflash.

    2 I select to boot the evm from tftp and nfs

    3 The system goes to reset immediately when the kernel calls
"davinci_cfg_reg(DM646X_PCIEN)" in the file of board-dm646x-evm.c

    I have selected CONFIG_PCI in the configuration of kernel. the
version of kernel is Linux kernel version 2.6.32-rc1, here is link
    http://arago-project.org/files/releases/davinci-psp_3.x.0.0-r37/sources/linux-davinci-staging.tar.gz

    Best wisches!

From hemantp at ti.com  Mon Aug  9 22:00:05 2010
From: hemantp at ti.com (Pedanekar, Hemant)
Date: Tue, 10 Aug 2010 08:30:05 +0530
Subject: The 6467t evm goes to reset immediately after the switching to
	PCI 	mode from nand
In-Reply-To: <AANLkTi=rBAatFOcg7jXb9QYYzruVnVgr+dKANj3XZwO+@mail.gmail.com>
References: <AANLkTi=rBAatFOcg7jXb9QYYzruVnVgr+dKANj3XZwO+@mail.gmail.com>
Message-ID: <2A3DCF3DA181AD40BDE86A3150B27B6B030E65C9C5@dbde02.ent.ti.com>

Switching from NAND to PCI will reset the board unless PCI_RST is driven high.
 
Please refer following http://processors.wiki.ti.com/index.php?title=Pinmux_Switching_from_NAND_to_PCI#Using_the_DM6467_EVM

-
Hemant
 
 

> -----Original Message-----
> From: wenaideyu wenaideyu [mailto:wenaideyu at gmail.com] 
> Sent: Monday, August 09, 2010 9:11 PM
> To: davinci-linux-open-source at linux.davincidsp.com; Pedanekar, Hemant
> Subject: The 6467t evm goes to reset immediately after the 
> switching to PCI mode from nand
> 
> Hi:
> 
>     The 6467t evm reset immediately when I try to switch to PCI mode
> on evm by the following steps:
> 
>     1 I turn the sw3 in evm borads to boot from nandflash.
> 
>     2 I select to boot the evm from tftp and nfs
> 
>     3 The system goes to reset immediately when the kernel calls
> "davinci_cfg_reg(DM646X_PCIEN)" in the file of board-dm646x-evm.c
> 
>     I have selected CONFIG_PCI in the configuration of kernel. the
> version of kernel is Linux kernel version 2.6.32-rc1, here is link
>     
> http://arago-project.org/files/releases/davinci-psp_3.x.0.0-r3
7/sources/linux-davinci-staging.tar.gz
> 
>     Best wisches!
> 

From sudhakar.raj at ti.com  Tue Aug 10 01:42:58 2010
From: sudhakar.raj at ti.com (Sudhakar Rajashekhara)
Date: Tue, 10 Aug 2010 12:12:58 +0530
Subject: [PATCH] m25p80: add support for a callback to platform code on
	successful device probe
Message-ID: <1281422578-20461-1-git-send-email-sudhakar.raj@ti.com>

On some platforms, MTD device can hold MAC address, calibration
data, serial numbers etc.

On TI's DA850/OMAP-L138/AM18xx EVM, MAC address is stored on
the last sector of the SPI flash, which is exported as an MTD
device.

This patch adds two new members to the 'flash_platform_data'
structure, a function handler which will be called after
add_mtd_device() and an argument to be passed to this function,
for example: offset to read from.

Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
---
 drivers/mtd/devices/m25p80.c |   15 +++++++++++++--
 include/linux/spi/flash.h    |    2 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..b832091 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -765,6 +765,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
 	struct m25p			*flash;
 	struct flash_info		*info;
 	unsigned			i;
+	int				ret;
 
 	/* Platform data helps sort out which chip type we have, as
 	 * well as how this board partitions it.  If we don't have
@@ -924,13 +925,23 @@ static int __devinit m25p_probe(struct spi_device *spi)
 					(long long)(parts[i].size >> 10));
 			}
 			flash->partitioned = 1;
-			return add_mtd_partitions(&flash->mtd, parts, nr_parts);
+			ret = add_mtd_partitions(&flash->mtd, parts, nr_parts);
+			if (!ret)
+				goto out;
+
+			return ret;
 		}
 	} else if (data && data->nr_parts)
 		dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
 				data->nr_parts, data->name);
 
-	return add_mtd_device(&flash->mtd) == 1 ? -ENODEV : 0;
+	ret = add_mtd_device(&flash->mtd);
+
+out:
+	if (data->setup && !ret)
+		(data->setup)(&flash->mtd, (void *)data->context);
+
+	return (ret == 1) ? -ENODEV : 0;
 }
 
 
diff --git a/include/linux/spi/flash.h b/include/linux/spi/flash.h
index 3f22932..daa4875 100644
--- a/include/linux/spi/flash.h
+++ b/include/linux/spi/flash.h
@@ -24,6 +24,8 @@ struct flash_platform_data {
 	unsigned int	nr_parts;
 
 	char		*type;
+	void		(*setup)(struct mtd_info *, void *context);
+	void		*context;
 
 	/* we'll likely add more ... use JEDEC IDs, etc */
 };
-- 
1.5.6


From sudhakar.raj at ti.com  Tue Aug 10 04:05:04 2010
From: sudhakar.raj at ti.com (Sudhakar Rajashekhara)
Date: Tue, 10 Aug 2010 14:35:04 +0530
Subject: [PATCH v2] m25p80: add support for a callback to platform code on
	successful device probe
Message-ID: <1281431104-17546-1-git-send-email-sudhakar.raj@ti.com>

On some platforms, MTD device can hold MAC address, calibration
data, serial numbers etc.

On TI's DA850/OMAP-L138/AM18xx EVM, MAC address is stored on
the last sector of the SPI flash, which is exported as an MTD
device. Ethernet driver on this platform needs MAC address to
be passed through platform data. The callback function can be
used to read the MAC address. The callback has to be invoked
after the MTD device is setup.

This patch adds two new members to the 'flash_platform_data'
structure, a function handler which will be called after
add_mtd_device() and an argument to be passed to this function,
for example: offset to read from.

Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
---
Since v1: Updated the changelog

 drivers/mtd/devices/m25p80.c |   15 +++++++++++++--
 include/linux/spi/flash.h    |    2 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..b832091 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -765,6 +765,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
 	struct m25p			*flash;
 	struct flash_info		*info;
 	unsigned			i;
+	int				ret;
 
 	/* Platform data helps sort out which chip type we have, as
 	 * well as how this board partitions it.  If we don't have
@@ -924,13 +925,23 @@ static int __devinit m25p_probe(struct spi_device *spi)
 					(long long)(parts[i].size >> 10));
 			}
 			flash->partitioned = 1;
-			return add_mtd_partitions(&flash->mtd, parts, nr_parts);
+			ret = add_mtd_partitions(&flash->mtd, parts, nr_parts);
+			if (!ret)
+				goto out;
+
+			return ret;
 		}
 	} else if (data && data->nr_parts)
 		dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
 				data->nr_parts, data->name);
 
-	return add_mtd_device(&flash->mtd) == 1 ? -ENODEV : 0;
+	ret = add_mtd_device(&flash->mtd);
+
+out:
+	if (data->setup && !ret)
+		(data->setup)(&flash->mtd, (void *)data->context);
+
+	return (ret == 1) ? -ENODEV : 0;
 }
 
 
diff --git a/include/linux/spi/flash.h b/include/linux/spi/flash.h
index 3f22932..daa4875 100644
--- a/include/linux/spi/flash.h
+++ b/include/linux/spi/flash.h
@@ -24,6 +24,8 @@ struct flash_platform_data {
 	unsigned int	nr_parts;
 
 	char		*type;
+	void		(*setup)(struct mtd_info *, void *context);
+	void		*context;
 
 	/* we'll likely add more ... use JEDEC IDs, etc */
 };
-- 
1.5.6


From sudhakar.raj at ti.com  Tue Aug 10 04:26:39 2010
From: sudhakar.raj at ti.com (Sudhakar Rajashekhara)
Date: Tue, 10 Aug 2010 14:56:39 +0530
Subject: [PATCH] m25p80: add support for a callback to platform code on
	successful device probe
In-Reply-To: <AANLkTimJAiUfyAYd6aoftbexKaBOz5A8BjX-fgumkWU9@mail.gmail.com>
References: <1281422578-20461-1-git-send-email-sudhakar.raj@ti.com>
	<AANLkTimJAiUfyAYd6aoftbexKaBOz5A8BjX-fgumkWU9@mail.gmail.com>
Message-ID: <016d01cb386e$22e28660$68a79320$@raj@ti.com>

Hi,

On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote:
> On Tue, Aug 10, 2010 at 02:42, Sudhakar Rajashekhara wrote:
> > On some platforms, MTD device can hold MAC address, calibration
> > data, serial numbers etc.
> 
> pretty standard behavior ...
> 
> > On TI's DA850/OMAP-L138/AM18xx EVM, MAC address is stored on
> > the last sector of the SPI flash, which is exported as an MTD
> > device.
> 
> again, nothing unique here ...
> 
> > This patch adds two new members to the 'flash_platform_data'
> > structure, a function handler which will be called after
> > add_mtd_device() and an argument to be passed to this function,
> > for example: offset to read from.
> 
> ... and your changelog falls apart.  the intro gives no basis that i
> can see as to why you need these hooks.
> 
> please give examples of what you're actually trying to accomplish and
> how these hooks help you accomplish said goal and why it is necessary
> that you do these things from kernel space instead of standard
> userspace.

I have submitted an updated version of this patch in which I have
addressed your concerns.

Regards,
Sudhakar



From nsekhar at ti.com  Tue Aug 10 07:08:25 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 10 Aug 2010 17:38:25 +0530
Subject: [PATCH 2/2] davinci: am18x/da850/omap-l138: add support for
	higher frequencies
In-Reply-To: <87aaovn9d7.fsf@deeprootsystems.com>
References: <1278491570-11832-1-git-send-email-nsekhar@ti.com>
	<1278491570-11832-2-git-send-email-nsekhar@ti.com>
	<87d3twvrtr.fsf@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E800C353@dbde02.ent.ti.com>
	<87aaovn9d7.fsf@deeprootsystems.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E80AC428@dbde02.ent.ti.com>

On Mon, Aug 09, 2010 at 20:03:56, Kevin Hilman wrote:
> "Nori, Sekhar" <nsekhar at ti.com> writes:
>
> > Hi Kevin,
> >
> > On Thu, Aug 05, 2010 at 23:56:40, Kevin Hilman wrote:
> >> Sekhar Nori <nsekhar at ti.com> writes:
> >>
> >> > AM18x/DA850/OMAP-L138 SoCs have variants that can operate
> >> > at a maximum of 456 MHz at 1.3V operating point. Also the
> >> > 1.2V operating point has a variant that can support a maximum
> >> > of 372 MHz.
> >> >
> >> > This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz)
> >> > to the list of DA850 OPPs.
> >> >
> >> > Not all silicon is qualified to run at higher speeds and
> >> > unfortunately the maximum speed the chip can support can only
> >> > be read from the label on the package (not software readable).
> >>
> >> doh
> >>
> >> > Because of this, kernel configuration options have been
> >> > introduced to help users enable higher speeds if they know
> >> > that their slicon can support the higher speed.
> >>
> >> I don't like introducing Kconfig options for this kind of thing.
> >>
> >> For example, what if you want one kernel binary to support different
> >> speed-qualified parts?
> >>
> >> I'd rather have this configurable at runtime using the board files.
> >> Make the default the common speed, and folks with parts with higher
> >> qualified chips can make changes in their board file.
> >
> > Right, using DA850 specific configuration will force all boards to
> > the same maximum speed. Hadn't thought of that! Will come up with
> > some board specific control of max cpufreq speed.
> >
> > For the EVM, Kconfig still seems to be the way to go since the same
> > EVM could be populated with different speed grade devices. U-Boot
> > doesn't have to change when a different speed grade device is used so
> > forcing a different U-Boot build (just to pass a different machine type
> > or ATAG_REVISION) seems bad idea as well.
>
> Whether it's Kconfig or board-file, you'll have to re-compile to support
> these parts.   I prefer board-file, but will accept Kconfig-based if
> that's your preference.
>

On second thoughts I decided to let U-Boot specify the speed grade to
the kernel using ATAG_REVISION. I sent a patch for this to the U-boot
mailing list (CCed you for information). Based on the feedback I see
for that patch, I will submit a new revision for kernel support.

Thanks,
Sekhar


From nsekhar at ti.com  Tue Aug 10 07:34:55 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 10 Aug 2010 18:04:55 +0530
Subject: [PATCH 2/2] davinci: am18x/da850/omap-l138: add support for
	higher	frequencies
In-Reply-To: <4C601755.5030807@criticallink.com>
References: <1278491570-11832-1-git-send-email-nsekhar@ti.com>
	<1278491570-11832-2-git-send-email-nsekhar@ti.com>
	<87d3twvrtr.fsf@deeprootsystems.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E800C353@dbde02.ent.ti.com>
	<87aaovn9d7.fsf@deeprootsystems.com>
	<4C601755.5030807@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E80AC456@dbde02.ent.ti.com>


Hi Michael,

On Mon, Aug 09, 2010 at 20:27:25, Michael Williamson wrote:

> I have a bit of kernel newbie question about this and some other items
> that seem to fall into the same category.  Would it be bad to make the
> maximum CPU clock some sort of run-time configurable attribute in sysfs
> or in /proc (root writable only, of course)?  Initialize it to the
> "safe" rate then allow users to bump it up if they have a chip that
> supports it?

cpufreq supports changing cpu clock at runtime. The issue here is how to
determine if the rate user is setting can be supported by hardware or not.
Since hardware does not provide that information, it has to be setup manually
in the software - somewhere.

>
> I had a similar questions about things like the video timings for the
> da8xx_fb driver (e.g., to be able to switch from 640x480 to 1024x768,

I think the right way to do this is to use the video timings database
already created in drivers/video/modedb.c. Right now the da8xx_fb driver
does not support using this feature.

> etc) and the SPI driver (clock speed, polarity, wordsize, etc.).

In this case I guess your board is really an exception. Once SPI bus is wired
chip select, clock speed supported etc usually don't change.

>
> Or is hardcoding these parameters and generating unique board files
> whenever something varies the way to go?  Is there a rule-of-thumb for
> making items runtime verses compile time parameters?

Generally speaking runtime configuration is preferred over compile time
configuration. Not sure about any documented guidelines.

Thanks,
Sekhar

From david-b at pacbell.net  Tue Aug 10 08:07:47 2010
From: david-b at pacbell.net (David Brownell)
Date: Tue, 10 Aug 2010 06:07:47 -0700 (PDT)
Subject: [PATCH] m25p80: add support for a callback to platform code on
	successful device probe
In-Reply-To: <016d01cb386e$22e28660$68a79320$@raj@ti.com>
Message-ID: <893387.4342.qm@web180301.mail.gq1.yahoo.com>


> On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote:

> it is necessary
> > that you do these things from kernel space instead of
> standard
> > userspace.

Hard to get userspace to do this stuff if
you're doing a network boot, and thus need
to have the MAC address working early.. it's
easy if the kernel can get the MAC address,
else not possible to boot.  Right?




From sudhakar.raj at ti.com  Tue Aug 10 08:07:24 2010
From: sudhakar.raj at ti.com (Sudhakar Rajashekhara)
Date: Tue, 10 Aug 2010 18:37:24 +0530
Subject: [PATCH] m25p80: add support for a callback to platform code on
	successful device probe
In-Reply-To: <893387.4342.qm@web180301.mail.gq1.yahoo.com>
References: <016d01cb386e$22e28660$68a79320$@raj@ti.com>
	<893387.4342.qm@web180301.mail.gq1.yahoo.com>
Message-ID: <019301cb388c$f9a777f0$ecf667d0$@raj@ti.com>

On Tue, Aug 10, 2010 at 18:37:47, David Brownell wrote:
> 
> > On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote:
> 
> > it is necessary
> > > that you do these things from kernel space instead of
> > standard
> > > userspace.
> 
> Hard to get userspace to do this stuff if
> you're doing a network boot, and thus need
> to have the MAC address working early.. it's
> easy if the kernel can get the MAC address,
> else not possible to boot.  Right?
> 

You are absolutely right.

- Sudhakar



From sshtylyov at mvista.com  Tue Aug 10 08:41:49 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 10 Aug 2010 17:41:49 +0400
Subject: [PATCH] m25p80: add support for a callback to platform code on
	successful device probe
In-Reply-To: <1281422578-20461-1-git-send-email-sudhakar.raj@ti.com>
References: <1281422578-20461-1-git-send-email-sudhakar.raj@ti.com>
Message-ID: <4C61571D.1030906@mvista.com>

Hello.

Sudhakar Rajashekhara wrote:

> On some platforms, MTD device can hold MAC address, calibration
> data, serial numbers etc.

> On TI's DA850/OMAP-L138/AM18xx EVM, MAC address is stored on
> the last sector of the SPI flash, which is exported as an MTD
> device.

> This patch adds two new members to the 'flash_platform_data'
> structure, a function handler which will be called after
> add_mtd_device() and an argument to be passed to this function,
> for example: offset to read from.

> Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
> ---
>  drivers/mtd/devices/m25p80.c |   15 +++++++++++++--
>  include/linux/spi/flash.h    |    2 ++
>  2 files changed, 15 insertions(+), 2 deletions(-)

> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 81e49a9..b832091 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
[...]
> @@ -924,13 +925,23 @@ static int __devinit m25p_probe(struct spi_device *spi)
>  					(long long)(parts[i].size >> 10));
>  			}
>  			flash->partitioned = 1;
> -			return add_mtd_partitions(&flash->mtd, parts, nr_parts);
> +			ret = add_mtd_partitions(&flash->mtd, parts, nr_parts);
> +			if (!ret)
> +				goto out;
> +
> +			return ret;
>  		}
>  	} else if (data && data->nr_parts)
>  		dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
>  				data->nr_parts, data->name);
>  
> -	return add_mtd_device(&flash->mtd) == 1 ? -ENODEV : 0;
> +	ret = add_mtd_device(&flash->mtd);
> +
> +out:
> +	if (data->setup && !ret)
> +		(data->setup)(&flash->mtd, (void *)data->context);

    Parens not necessary around 'data->setup'.

> diff --git a/include/linux/spi/flash.h b/include/linux/spi/flash.h
> index 3f22932..daa4875 100644
> --- a/include/linux/spi/flash.h
> +++ b/include/linux/spi/flash.h
> @@ -24,6 +24,8 @@ struct flash_platform_data {
>  	unsigned int	nr_parts;
>  
>  	char		*type;
> +	void		(*setup)(struct mtd_info *, void *context);
> +	void		*context;
>  
>  	/* we'll likely add more ... use JEDEC IDs, etc */
>  };

    Hm, is m25p80.c the only SPI flash driver using this structure? I guess 
not -- I'm seeing at least sst25l.c and mtd_dataflash.c...

WBR, Sergei


From khilman at deeprootsystems.com  Tue Aug 10 09:29:26 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 10 Aug 2010 07:29:26 -0700
Subject: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <4C5B1B6C.2040601@criticallink.com> (Michael Williamson's message
	of "Thu, 05 Aug 2010 16:13:32 -0400")
References: <4C45AE5E.7070905@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7D0AF64@dbde02.ent.ti.com>
	<4C4D8449.9040706@criticallink.com>
	<87mxt0ubnr.fsf@deeprootsystems.com>
	<4C5B1378.7080400@criticallink.com>
	<AANLkTik1Z1mromdUMK0Qf9iC9tude_4=4XgsL7A-x+K7@mail.gmail.com>
	<4C5B1B6C.2040601@criticallink.com>
Message-ID: <87r5i68rsp.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

>  On 8/5/2010 4:01 PM, Ben Gardiner wrote:
>
>> On Thu, Aug 5, 2010 at 3:39 PM, Michael Williamson
>> <michael.williamson at criticallink.com> wrote:
>>>  On 8/5/2010 3:01 PM, Kevin Hilman wrote:
>>>
>>>> Michael Williamson <michael.williamson at criticallink.com> writes:
>>>>
>>>>>  On 7/26/2010 5:29 AM, Nori, Sekhar wrote:
>>>>>
>>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> On Tue, Jul 20, 2010 at 19:40:38, Michael Williamson wrote:
>>>>>>>  This patch adds support for the MityDSP-L138 and MityARM-1808 system on
>>>>>>> module (SOM) under the registered machine "mityomapl138".  These SOMs
>>>>>>> are based on the da850 davinci CPU architecture.  Information on these
>>>>>>> SOMs may be found at http://www.mitydsp.com.
>>>>>>>
>>>>>>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>>>>>>> ---
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>
>>>>>>>  arch/arm/configs/da8xx_omapl_defconfig             |  291 ++++++--
>>>>>>>  arch/arm/include/asm/setup.h                       |    5 +
>>>>>>>  arch/arm/mach-davinci/Kconfig                      |    7 +
>>>>>>>  arch/arm/mach-davinci/Makefile                     |    1 +
>>>>>>>  arch/arm/mach-davinci/board-mityomapl138.c         |  793 ++++++++++++++++++++
>>>>>>>  .../mach-davinci/include/mach/cb-mityomapl138.h    |  125 +++
>>>>>>>  arch/arm/mach-davinci/include/mach/da8xx.h         |    1 +
>>>>>>>  arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
>>>>>>>  8 files changed, 1181 insertions(+), 43 deletions(-)
>>>>>>>
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
>>>>>>> index f392fb4..d6b1a47 100644
>>>>>>> --- a/arch/arm/include/asm/setup.h
>>>>>>> +++ b/arch/arm/include/asm/setup.h
>>>>>>> @@ -143,6 +143,11 @@ struct tag_memclk {
>>>>>>>      __u32 fmemclk;
>>>>>>>  };
>>>>>>>
>>>>>>> +/** MityDSP-L138 peripheral configuration info,
>>>>>>> +  *  see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
>>>>>>> +  */
>>>>>>> +#define ATAG_PERIPHERALS 0x42000101
>>>>>>
>>>>>> Instead of naming this so generic, can you call this ATAG_MITYDSPL138 or
>>>>>> something like that?
>>>>>
>>>>>
>>>>>
>>>>> Yes.  I would be glad to rename it, assuming some other approach is not
>>>>> used instead.
>>>>>
>>>>>>
>>>>>> Since passing peripheral configuration from bootloader is a first for
>>>>>> DaVinci, can you please explain why this is the best suited method for this
>>>>>> board and why methods used on other boards wont work?
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Well, the problem we are struggling with is that we'd like to avoid
>>>>> generating a pile of separate machine types for the different boards
>>>>> that are needed to support for this common SOM part with regards
>>>>> to the peripheral selection.  There are already have 4 different
>>>>> boards with slightly different peripherals already being used with this SOM,
>>>>> and it's a challenge enough just to try to get one configuration through
>>>>> this cycle (which I am new to).  We are expecting many more (10's per
>>>>> year).
>>>>>
>>>>> In general, the only real difference on any of these boards will be in regards
>>>>> to peripheral selection/configuration.  E.G., using RMII vs. MII, or using
>>>>> different McASP pins or different numbers of channels, or adding a couple
>>>>> of SPI devices on different chip selects, LCD settings, etc.
>>>>> Seems like we shouldn't need to make a whole new machine up to support
>>>>> these kinds of things.
>>>>>
>>>>> This came up in a thread on this mailing list, see
>>>>>
>>>>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17042.html
>>>>>
>>>>> The approach here was pretty much what Kevin suggested as an alternate
>>>>> to trying to port a flat device tree implementation like the powerpc
>>>>> folks use.  The only difference was that I didn't think I could jam
>>>>> everything I wanted onto the kernel command line without it getting out
>>>>> of hand, so I am proposing a separate ATAG to provide the peripheral
>>>>> configuration.  It's not perfect, but I wanted to get something out
>>>>> there as if it's rejected then we only have a few boards to rewrite code
>>>>> for.
>>>>>
>>>>> Other than device trees, the only other approaches I've seen so far to
>>>>> sort out altering peripheral configuration is:
>>>>>
>>>>> a) Make a new board (a new board file, etc., KConfig option, etc.)
>>>>>
>>>>> b) Start in with a pile of #ifdefs, etc., and add a lot of peripheral
>>>>> on/off options to the KConfig/Make system.  That means supporting
>>>>> many variants of kernels for the different host boards, not
>>>>> just an EVM.  I'd like to avoid that if I could, as the regression
>>>>> testing for new options might get out of hand.  And it didn't seem
>>>>> consistent with making a flexible kernel.
>>>>>
>>>>> c) Allow peripheral drivers to probe and initialize pins, etc. in the
>>>>> modules, then load the right drivers up for your board.  There are a lot
>>>>> of threads about why letting drivers mess with the pins is bad.  So this
>>>>> is a non-starter.
>>>>
>>>> d) use ATAG_REVISION and a single board file
>>>>
>>>> There is currently a tag called ATAG_REVISION which sets a global
>>>> variable 'system_rev' based on this tagq.  This tag was intended for
>>>> exactly this purpose.
>>>>
>>>> You can then have a single machine type, a single board file and the
>>>> boot loader can change ATAG_REVISION based on the board specifics.  The
>>>> board file can then check 'system_rev' and handle specifics that way.
>>>>
>>>> This is also much clearer as all the things that are unique to that
>>>> board will be contained in the board file and not hidden away in the
>>>> bootloader.
>>>
>>>
>>>
>>> So, if for example, we have 3 boards that use this SOM, and they
>>> vary by desired peripheral:
>>>
>>> Host Board 1 Peripherals = UARTS 0 and 1, SPI0 CS2, RMII, etc.
>>> Host Board 2 Peripherals = UARTS 1 and 2, SPI1 CS1, MII, etc.
>>> Host Board 3 Peripherals = UARTS 0, 1 and 2, SPI1 CS1, MII, etc.
>>>
>>> Then by this approach we would have:
>>>
>>> mityomapl138_init()
>>> {
>>>   /* Common NAND/NOR Init */
>>>
>>>   switch (system_rev) {
>>>      case 1:
>>>          /* setup uarts 0 & 1, SPI0 CS2, RMII */
>>>      case 2:
>>>          /* setup uarts 1 & 2, SPI1 CS1, MII */
>>>      case 3:
>>>      default:
>>>          /* setup uarts 0 & 1 & 2, SPI1 CS1, MII */
>>>          /* and so forth.... */
>>>   }
>>>
>>>   /* Common Peripheral Init */
>>> }
>>>
>>> Each time a new board is developed to use the SOM, you then grow the init
>>> code accordingly?  I was hoping not to have to continuously drop patches
>>> for new boards using this SOM.  I was really trying to have one binary
>>> kernel that would be flexible enough to support the peripherals that
>>> need to be handed to the device framework for any host board using this
>>> SOM (properly configured via bootloader).  Is this not possible?
>>
>> Michael, could you pack the available peripherals into the bits of
>> ATAG_REVISION?
>>
>> #define MIGHTYDSP_UART0 BIT(0)
>> #define MIGHTYDSP_UART1 BIT(1)
>> #define MIGHTYDSP_UART2 BIT(2)
>> #define MIGHTYDSP_SPI1 BIT(3)
>>
>> mityomapl138_init()
>> {
>>   /* Common NAND/NOR Init */
>>
>>   if(system_rev & MIGHTYDSP_UART0) { /* setup uart0 */ }
>>
>>   if(system_rev & MIGHTYDSP_SPI1) { /*setup spi1*/ }
>>
>>   /* Common Peripheral Init */
>> }
>>
>> Kevin, is that legal use of ATAG_REVISION?
>
>
>
> It's unlikely.  There are strings to pass to the framebuffer device
> for the da850, 

For the framebuffer, there are existing command-line options to be used
and/or expanded.

> multiple CS pin assignments as well as multiple McASP
> channel configurations.  I'll look into it. Thanks.

I would advise using the ATAG_REVISION for basic setup, but consider
using/expanding the command-line options for specific drivers.

Kevin



From khilman at deeprootsystems.com  Tue Aug 10 09:35:21 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 10 Aug 2010 07:35:21 -0700
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <AANLkTik7UbkMtRj6uSPfCpQVVFxts_En6wf+X6DTDtRM@mail.gmail.com>
	(Ben Gardiner's message of "Thu, 5 Aug 2010 17:31:50 -0400")
References: <201008012115.16423.sshtylyov@ru.mvista.com>
	<8739usuaw9.fsf@deeprootsystems.com>
	<AANLkTik7UbkMtRj6uSPfCpQVVFxts_En6wf+X6DTDtRM@mail.gmail.com>
Message-ID: <87hbj28riu.fsf@deeprootsystems.com>

Ben Gardiner <bengardiner at nanometrics.ca> writes:

> On Thu, Aug 5, 2010 at 3:17 PM, Kevin Hilman
> <khilman at deeprootsystems.com> wrote:
>> Sergei Shtylyov <sshtylyov at ru.mvista.com> writes:
>>
>>> The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
>>> specific and as such shouldn't be in da850.c -- copy them to board-da850-evm.c,
>>> renaming to da850_evm_nand_pins/da850_evm_nor_pins respectively, and merge the
>>> two lists in da850.c into one, representing the EMIF 2.5 module as a whole,
>>> just like we have it in da830.c...
>>>
>>> While at it, remove the '__init' modifier from da850_evm_setup_nor_nand() as
>>> this function is called from non '__init' code...
>>>
>>> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>>>
>>> ---
>>> The patch is against the recent DaVinci tree. It has only been build-tested as
>>> I don't have DA850 EVM board...
>>
>> I'm OK with this series, but would like to see some test reports on
>> da850-evm using nand and nor using this before I apply it.
>>
>> Kevin
>
> Tested-by: Ben Gardiner<bengardiner at nanometrics.ca>
>
> The patch applies cleanly to 939c222e5e793c8b9d7494e2b125676e8fd7dcaf
> of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
> and results in a bootable kernel with a config from the omap-l1 tree
> and 'make oldconfig < /dev/null' after USB and the voltage regulators
> are disabled.
>
> The kernel appears to run as well with the patch applied as without --
> tested on a da850evm booting from NAND and mounting JFFS2 rootfs from
> NAND.
>

Ben, 

Thanks or testing.  Applying both patches in this series and queueing
for 2.6.37.

Kevin

From sshtylyov at mvista.com  Tue Aug 10 09:38:44 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 10 Aug 2010 18:38:44 +0400
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <87hbj28riu.fsf@deeprootsystems.com>
References: <201008012115.16423.sshtylyov@ru.mvista.com>	<8739usuaw9.fsf@deeprootsystems.com>	<AANLkTik7UbkMtRj6uSPfCpQVVFxts_En6wf+X6DTDtRM@mail.gmail.com>
	<87hbj28riu.fsf@deeprootsystems.com>
Message-ID: <4C616474.5030300@mvista.com>

Hello.

Kevin Hilman wrote:

>>>> The NAND/NOR flash pin lists (da850_nand_pins/da850_nor_pins) are purely board
>>>> specific and as such shouldn't be in da850.c -- copy them to board-da850-evm.c,
>>>> renaming to da850_evm_nand_pins/da850_evm_nor_pins respectively, and merge the
>>>> two lists in da850.c into one, representing the EMIF 2.5 module as a whole,
>>>> just like we have it in da830.c...

>>>> While at it, remove the '__init' modifier from da850_evm_setup_nor_nand() as
>>>> this function is called from non '__init' code...

>>>> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

>>>> ---
>>>> The patch is against the recent DaVinci tree. It has only been build-tested as
>>>> I don't have DA850 EVM board...

>>> I'm OK with this series, but would like to see some test reports on
>>> da850-evm using nand and nor using this before I apply it.

>>> Kevin

>> Tested-by: Ben Gardiner<bengardiner at nanometrics.ca>

>> The patch applies cleanly to 939c222e5e793c8b9d7494e2b125676e8fd7dcaf
>> of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
>> and results in a bootable kernel with a config from the omap-l1 tree
>> and 'make oldconfig < /dev/null' after USB and the voltage regulators
>> are disabled.

>> The kernel appears to run as well with the patch applied as without --
>> tested on a da850evm booting from NAND and mounting JFFS2 rootfs from
>> NAND.

> Ben, 

> Thanks or testing.  Applying both patches in this series and queueing
> for 2.6.37.

    I was hoping for 2.6.36. Sigh... :-(

> Kevin

WBR, Sergei

From michael.williamson at criticallink.com  Tue Aug 10 10:13:03 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 10 Aug 2010 11:13:03 -0400
Subject: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <87r5i68rsp.fsf@deeprootsystems.com>
References: <4C45AE5E.7070905@criticallink.com>	<B85A65D85D7EB246BE421B3FB0FBB59301E7D0AF64@dbde02.ent.ti.com>	<4C4D8449.9040706@criticallink.com>	<87mxt0ubnr.fsf@deeprootsystems.com>	<4C5B1378.7080400@criticallink.com>	<AANLkTik1Z1mromdUMK0Qf9iC9tude_4=4XgsL7A-x+K7@mail.gmail.com>	<4C5B1B6C.2040601@criticallink.com>
	<87r5i68rsp.fsf@deeprootsystems.com>
Message-ID: <4C616C7F.3060206@criticallink.com>

 On 8/10/2010 10:29 AM, Kevin Hilman wrote:

> Michael Williamson <michael.williamson at criticallink.com> writes:
>
>>  On 8/5/2010 4:01 PM, Ben Gardiner wrote:
>>
>>> On Thu, Aug 5, 2010 at 3:39 PM, Michael Williamson
>>> <michael.williamson at criticallink.com> wrote:
>>>>  On 8/5/2010 3:01 PM, Kevin Hilman wrote:
>>>>
>>>>> Michael Williamson <michael.williamson at criticallink.com> writes:
>>>>>
>>>>>>  On 7/26/2010 5:29 AM, Nori, Sekhar wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> On Tue, Jul 20, 2010 at 19:40:38, Michael Williamson wrote:
>>>>>>>>  This patch adds support for the MityDSP-L138 and MityARM-1808 system on
>>>>>>>> module (SOM) under the registered machine "mityomapl138".  These SOMs
>>>>>>>> are based on the da850 davinci CPU architecture.  Information on these
>>>>>>>> SOMs may be found at http://www.mitydsp.com.
>>>>>>>>
>>>>>>>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>>>>>>>> ---
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>>
>>>>>>>>  arch/arm/configs/da8xx_omapl_defconfig             |  291 ++++++--
>>>>>>>>  arch/arm/include/asm/setup.h                       |    5 +
>>>>>>>>  arch/arm/mach-davinci/Kconfig                      |    7 +
>>>>>>>>  arch/arm/mach-davinci/Makefile                     |    1 +
>>>>>>>>  arch/arm/mach-davinci/board-mityomapl138.c         |  793 ++++++++++++++++++++
>>>>>>>>  .../mach-davinci/include/mach/cb-mityomapl138.h    |  125 +++
>>>>>>>>  arch/arm/mach-davinci/include/mach/da8xx.h         |    1 +
>>>>>>>>  arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
>>>>>>>>  8 files changed, 1181 insertions(+), 43 deletions(-)
>>>>>>>>
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
>>>>>>>> index f392fb4..d6b1a47 100644
>>>>>>>> --- a/arch/arm/include/asm/setup.h
>>>>>>>> +++ b/arch/arm/include/asm/setup.h
>>>>>>>> @@ -143,6 +143,11 @@ struct tag_memclk {
>>>>>>>>      __u32 fmemclk;
>>>>>>>>  };
>>>>>>>>
>>>>>>>> +/** MityDSP-L138 peripheral configuration info,
>>>>>>>> +  *  see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
>>>>>>>> +  */
>>>>>>>> +#define ATAG_PERIPHERALS 0x42000101
>>>>>>>
>>>>>>> Instead of naming this so generic, can you call this ATAG_MITYDSPL138 or
>>>>>>> something like that?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes.  I would be glad to rename it, assuming some other approach is not
>>>>>> used instead.
>>>>>>
>>>>>>>
>>>>>>> Since passing peripheral configuration from bootloader is a first for
>>>>>>> DaVinci, can you please explain why this is the best suited method for this
>>>>>>> board and why methods used on other boards wont work?
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Well, the problem we are struggling with is that we'd like to avoid
>>>>>> generating a pile of separate machine types for the different boards
>>>>>> that are needed to support for this common SOM part with regards
>>>>>> to the peripheral selection.  There are already have 4 different
>>>>>> boards with slightly different peripherals already being used with this SOM,
>>>>>> and it's a challenge enough just to try to get one configuration through
>>>>>> this cycle (which I am new to).  We are expecting many more (10's per
>>>>>> year).
>>>>>>
>>>>>> In general, the only real difference on any of these boards will be in regards
>>>>>> to peripheral selection/configuration.  E.G., using RMII vs. MII, or using
>>>>>> different McASP pins or different numbers of channels, or adding a couple
>>>>>> of SPI devices on different chip selects, LCD settings, etc.
>>>>>> Seems like we shouldn't need to make a whole new machine up to support
>>>>>> these kinds of things.
>>>>>>
>>>>>> This came up in a thread on this mailing list, see
>>>>>>
>>>>>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17042.html
>>>>>>
>>>>>> The approach here was pretty much what Kevin suggested as an alternate
>>>>>> to trying to port a flat device tree implementation like the powerpc
>>>>>> folks use.  The only difference was that I didn't think I could jam
>>>>>> everything I wanted onto the kernel command line without it getting out
>>>>>> of hand, so I am proposing a separate ATAG to provide the peripheral
>>>>>> configuration.  It's not perfect, but I wanted to get something out
>>>>>> there as if it's rejected then we only have a few boards to rewrite code
>>>>>> for.
>>>>>>
>>>>>> Other than device trees, the only other approaches I've seen so far to
>>>>>> sort out altering peripheral configuration is:
>>>>>>
>>>>>> a) Make a new board (a new board file, etc., KConfig option, etc.)
>>>>>>
>>>>>> b) Start in with a pile of #ifdefs, etc., and add a lot of peripheral
>>>>>> on/off options to the KConfig/Make system.  That means supporting
>>>>>> many variants of kernels for the different host boards, not
>>>>>> just an EVM.  I'd like to avoid that if I could, as the regression
>>>>>> testing for new options might get out of hand.  And it didn't seem
>>>>>> consistent with making a flexible kernel.
>>>>>>
>>>>>> c) Allow peripheral drivers to probe and initialize pins, etc. in the
>>>>>> modules, then load the right drivers up for your board.  There are a lot
>>>>>> of threads about why letting drivers mess with the pins is bad.  So this
>>>>>> is a non-starter.
>>>>>
>>>>> d) use ATAG_REVISION and a single board file
>>>>>
>>>>> There is currently a tag called ATAG_REVISION which sets a global
>>>>> variable 'system_rev' based on this tagq.  This tag was intended for
>>>>> exactly this purpose.
>>>>>
>>>>> You can then have a single machine type, a single board file and the
>>>>> boot loader can change ATAG_REVISION based on the board specifics.  The
>>>>> board file can then check 'system_rev' and handle specifics that way.
>>>>>
>>>>> This is also much clearer as all the things that are unique to that
>>>>> board will be contained in the board file and not hidden away in the
>>>>> bootloader.
>>>>
>>>>
>>>>
>>>> So, if for example, we have 3 boards that use this SOM, and they
>>>> vary by desired peripheral:
>>>>
>>>> Host Board 1 Peripherals = UARTS 0 and 1, SPI0 CS2, RMII, etc.
>>>> Host Board 2 Peripherals = UARTS 1 and 2, SPI1 CS1, MII, etc.
>>>> Host Board 3 Peripherals = UARTS 0, 1 and 2, SPI1 CS1, MII, etc.
>>>>
>>>> Then by this approach we would have:
>>>>
>>>> mityomapl138_init()
>>>> {
>>>>   /* Common NAND/NOR Init */
>>>>
>>>>   switch (system_rev) {
>>>>      case 1:
>>>>          /* setup uarts 0 & 1, SPI0 CS2, RMII */
>>>>      case 2:
>>>>          /* setup uarts 1 & 2, SPI1 CS1, MII */
>>>>      case 3:
>>>>      default:
>>>>          /* setup uarts 0 & 1 & 2, SPI1 CS1, MII */
>>>>          /* and so forth.... */
>>>>   }
>>>>
>>>>   /* Common Peripheral Init */
>>>> }
>>>>
>>>> Each time a new board is developed to use the SOM, you then grow the init
>>>> code accordingly?  I was hoping not to have to continuously drop patches
>>>> for new boards using this SOM.  I was really trying to have one binary
>>>> kernel that would be flexible enough to support the peripherals that
>>>> need to be handed to the device framework for any host board using this
>>>> SOM (properly configured via bootloader).  Is this not possible?
>>>
>>> Michael, could you pack the available peripherals into the bits of
>>> ATAG_REVISION?
>>>
>>> #define MIGHTYDSP_UART0 BIT(0)
>>> #define MIGHTYDSP_UART1 BIT(1)
>>> #define MIGHTYDSP_UART2 BIT(2)
>>> #define MIGHTYDSP_SPI1 BIT(3)
>>>
>>> mityomapl138_init()
>>> {
>>>   /* Common NAND/NOR Init */
>>>
>>>   if(system_rev & MIGHTYDSP_UART0) { /* setup uart0 */ }
>>>
>>>   if(system_rev & MIGHTYDSP_SPI1) { /*setup spi1*/ }
>>>
>>>   /* Common Peripheral Init */
>>> }
>>>
>>> Kevin, is that legal use of ATAG_REVISION?
>>
>>
>>
>> It's unlikely.  There are strings to pass to the framebuffer device
>> for the da850, 
>
> For the framebuffer, there are existing command-line options to be used
> and/or expanded.
>
>> multiple CS pin assignments as well as multiple McASP
>> channel configurations.  I'll look into it. Thanks.
>
> I would advise using the ATAG_REVISION for basic setup, but consider
> using/expanding the command-line options for specific drivers.
>
> Kevin
>
>



Looks like ATAG_REVISION is going to be (at least partially) consumed by the
patch Sekhar is working on here:

https://patchwork.kernel.org/patch/110577/

I think the problem I have is that we need to support multiple boards
using the developed SOM.  The SOM in and of itself does not define a
"board".  It has to be paired with a host board.

I had thought there would be a way to avoid generation of multiple board
files that only differed in the chip peripheral instantiation /
configuration.  With the powerpc architecture, the device tree allowed
instantiation and configuration of SOC peripherals at load/runtime.  I
don't see anything like that capability in the ARM architecture.  The
command line options might work, but I expect that they would rapidly
devolve into hacks.

The patch that has been put forth to read additional board information (MAC
address, etc.) from a SPI NOR device during the MTD probe phase (link below)
might work, but it requires that the SPI and the MTD drivers are working
well enough to read this data out.  Not helpful if you want to be able
to configure the SPI at startup (add additional chip selects, etc.)

https://patchwork.kernel.org/patch/118530/

I think I need to withdraw this submission.  We can't afford to
maintain the board files for the number of host boards that are already
being developed, and there's no way we could get them all issued to
the mainline.

There don't appear to be any instances of non-EVM type boards in
mach-davinci (at least for the da850), so my guess is other users of
this SOC have come to the same conclusion.

Thanks for all the comments.

-Mike




From khilman at deeprootsystems.com  Tue Aug 10 10:15:08 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 10 Aug 2010 08:15:08 -0700
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <4C616474.5030300@mvista.com> (Sergei Shtylyov's message of "Tue, 
	10 Aug 2010 18:38:44 +0400")
References: <201008012115.16423.sshtylyov@ru.mvista.com>
	<8739usuaw9.fsf@deeprootsystems.com>
	<AANLkTik7UbkMtRj6uSPfCpQVVFxts_En6wf+X6DTDtRM@mail.gmail.com>
	<87hbj28riu.fsf@deeprootsystems.com> <4C616474.5030300@mvista.com>
Message-ID: <87y6ce7b43.fsf@deeprootsystems.com>

Sergei Shtylyov <sshtylyov at mvista.com> writes:

[...]

>>> The kernel appears to run as well with the patch applied as without --
>>> tested on a da850evm booting from NAND and mounting JFFS2 rootfs from
>>> NAND.
>
>> Ben, 
>
>> Thanks or testing.  Applying both patches in this series and queueing
>> for 2.6.37.
>
>    I was hoping for 2.6.36. Sigh... :-(

Sorry, it was way to late for 2.6.36.

You posted this one day before the merge window opened.  If you want
patches/features to go in during the merge window, they need to be
submitted, reviewed and merged by me well before the merge window opens.

I want things cooking in davinci git and linux-next for at least a week
before I submit a pull request to Linus.

Kevin

From wenaideyu at gmail.com  Tue Aug 10 10:28:35 2010
From: wenaideyu at gmail.com (wenaideyu wenaideyu)
Date: Tue, 10 Aug 2010 23:28:35 +0800
Subject: The 6467t evm goes to reset immediately after the switching to 
	PCI mode from nand
In-Reply-To: <AANLkTi=rBAatFOcg7jXb9QYYzruVnVgr+dKANj3XZwO+@mail.gmail.com>
References: <AANLkTi=rBAatFOcg7jXb9QYYzruVnVgr+dKANj3XZwO+@mail.gmail.com>
Message-ID: <AANLkTikOHWdmK4hViBU7=vEJZnD2iGXfcubcmhnrKOn4@mail.gmail.com>

Hi:
   thanks a lot for your advice. I have printed the value of
PCI_RST(GPIO[13]) before switching from NAND to PCI, the value is 1.
Itmeans PCI_RST has been driven high.

   but the board still resets while the kernel calls
"davinci_cfg_reg(DM646X_PCIEN)" in the file of board-dm646x-evm.c

   I just select the PCI bus support in the configuration of
kernel,and I do not select the support of mtd and ata in kernel.

  shoud I do some configuration about the Davincihd1080p evm while it
acts as a PCI host?

   best wishes!

From khilman at deeprootsystems.com  Tue Aug 10 10:34:18 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 10 Aug 2010 08:34:18 -0700
Subject: [PATCH v3] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <4C616C7F.3060206@criticallink.com> (Michael Williamson's message
	of "Tue, 10 Aug 2010 11:13:03 -0400")
References: <4C45AE5E.7070905@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7D0AF64@dbde02.ent.ti.com>
	<4C4D8449.9040706@criticallink.com>
	<87mxt0ubnr.fsf@deeprootsystems.com>
	<4C5B1378.7080400@criticallink.com>
	<AANLkTik1Z1mromdUMK0Qf9iC9tude_4=4XgsL7A-x+K7@mail.gmail.com>
	<4C5B1B6C.2040601@criticallink.com>
	<87r5i68rsp.fsf@deeprootsystems.com>
	<4C616C7F.3060206@criticallink.com>
Message-ID: <8762zi7a85.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

>  On 8/10/2010 10:29 AM, Kevin Hilman wrote:
>

[...]

>>
>> I would advise using the ATAG_REVISION for basic setup, but consider
>> using/expanding the command-line options for specific drivers.
>>
>
> Looks like ATAG_REVISION is going to be (at least partially) consumed by the
> patch Sekhar is working on here:
>
> https://patchwork.kernel.org/patch/110577/
>
> I think the problem I have is that we need to support multiple boards
> using the developed SOM.  The SOM in and of itself does not define a
> "board".  It has to be paired with a host board.
>
> I had thought there would be a way to avoid generation of multiple board
> files that only differed in the chip peripheral instantiation /
> configuration.  With the powerpc architecture, the device tree allowed
> instantiation and configuration of SOC peripherals at load/runtime.  I
> don't see anything like that capability in the ARM architecture.  

The good news is that there is active work for device tree support for
ARM.  The bad news is that it is still a ways from being ready.

> The command line options might work, but I expect that they would
> rapidly devolve into hacks.
>
> The patch that has been put forth to read additional board information (MAC

> address, etc.) from a SPI NOR device during the MTD probe phase (link below)
> might work, but it requires that the SPI and the MTD drivers are working
> well enough to read this data out.  Not helpful if you want to be able
> to configure the SPI at startup (add additional chip selects, etc.)

Another possible option is to use ATAG_REVISION to do the absolute
minimal setup so you can get to from non-volatile storage.  In your
case, the minimum is probably SPI chipselect (and UART for debug.)
After that, the config for all the other peripherals could be flashed.

> https://patchwork.kernel.org/patch/118530/
>
> I think I need to withdraw this submission.  We can't afford to
> maintain the board files for the number of host boards that are already
> being developed, and there's no way we could get them all issued to
> the mainline.

I agree, having to maintain a large number of minimally different board
files is not a good solution either.

> There don't appear to be any instances of non-EVM type boards in
> mach-davinci (at least for the da850), so my guess is other users of
> this SOC have come to the same conclusion.

Possibly, but from what I see and hear, it's more likely that most other
users have not been as interested in getting support for their boards
upstream.  Thanks for putting in the extra effort to try.  

If you're willing to give it another spin, I still think it's possible
to get what you would need with the "hybrid" solution of using
ATAG_REVISION for minimal setup, and getting the rest from flash.

Kevin



From sshtylyov at mvista.com  Tue Aug 10 10:52:15 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 10 Aug 2010 19:52:15 +0400
Subject: [PATCH 1/2] DA850: move NAND/NOR pin lists to the board file
In-Reply-To: <87y6ce7b43.fsf@deeprootsystems.com>
References: <201008012115.16423.sshtylyov@ru.mvista.com>	<8739usuaw9.fsf@deeprootsystems.com>	<AANLkTik7UbkMtRj6uSPfCpQVVFxts_En6wf+X6DTDtRM@mail.gmail.com>	<87hbj28riu.fsf@deeprootsystems.com>
	<4C616474.5030300@mvista.com> <87y6ce7b43.fsf@deeprootsystems.com>
Message-ID: <4C6175AF.2020505@mvista.com>

Hello.

Kevin Hilman wrote:

> [...]

>>>> The kernel appears to run as well with the patch applied as without --
>>>> tested on a da850evm booting from NAND and mounting JFFS2 rootfs from
>>>> NAND.

>>> Ben, 
>>> Thanks or testing.  Applying both patches in this series and queueing
>>> for 2.6.37.

>>    I was hoping for 2.6.36. Sigh... :-(

> Sorry, it was way to late for 2.6.36.

> You posted this one day before the merge window opened.  If you want
> patches/features to go in during the merge window, they need to be
> submitted, reviewed and merged by me well before the merge window opens.

> I want things cooking in davinci git and linux-next for at least a week
> before I submit a pull request to Linus.

    I'm lacking time to work on DA8xx stuff currently, and I really didn't 
expect that Linus would release 2.6.35 so soon. I could still have submitted 
the patches somewhat earlier though in this case... :-/

> Kevin

WBR, Sergei

From kidjan at gmail.com  Tue Aug 10 11:57:22 2010
From: kidjan at gmail.com (Jeremy Noring)
Date: Tue, 10 Aug 2010 09:57:22 -0700
Subject: mmcqd taking up a lot of CPU?
Message-ID: <AANLkTimx1v=00XC7Trswrf5R3tkWw71YJFoZGJdg19kA@mail.gmail.com>

Hi, we're using the MontaVista kernel (2.6.18), and I've been noticing that
our mmcqd process uses a lot of CPU time when we're writing:

Mem: 63372K used, 4360K free, 0K shrd, 208K buff, 40612K cached
Load average: 3.00 2.29 2.04  (Status: S=sleeping R=running, W=waiting)
  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
  214 root     DW<        0    14 28.6  0.0 mmcqd
  585 root     S       3372     1 28.1  4.9 ............
  530 root     S      17028     1 28.0 25.0 .............
 1243 root     R        892   536  1.3  1.3 top
 1209 root     SW         0    14  0.1  0.0 pdflush
 1201 root     SW         0    14  0.1  0.0 pdflush
  545 root     S       2212     1  0.0  3.2 netconfigd
  536 root     S        940     1  0.0  1.3 sh
  640 root     S <      844     1  0.0  1.2 wdt.out
    1 root     S        584     0  0.0  0.8 init
 1245 root     S        580   530  0.0  0.8 sh
 1246 root     R        528  1245  0.0  0.7 mv
  282 root     S <      420     1  0.0  0.6 udevd
  572 root     S        228     1  0.0  0.3 udhcpc
   76 root     SW<        0    14  0.0  0.0 kswapd0
  217 root     SW<        0    14  0.0  0.0 rpciod/0
   13 root     SW<        0     1  0.0  0.0 khelper
   11 root     SW<        0     1  0.0  0.0 desched/0
   12 root     SW<        0     1  0.0  0.0 events/0
   14 root     SW<        0     1  0.0  0.0 kthread
    2 root     SW         0     1  0.0  0.0 posix_cpu_timer

My question is: has there been any change in the mainline kernel that might
address this sort of write performance?  Or does anyone know why mmcqd
consumes so much CPU time in the MV kernel?

Any help is much appreciated,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100810/9cc3f654/attachment.html>

From deepali at ti.com  Wed Aug 11 01:37:39 2010
From: deepali at ti.com (Uppal, Deepali)
Date: Wed, 11 Aug 2010 12:07:39 +0530
Subject: DSP/BIOS Link for GIT Kernel
In-Reply-To: <790971.15697.qm@web24108.mail.ird.yahoo.com>
References: <790971.15697.qm@web24108.mail.ird.yahoo.com>
Message-ID: <2A3DCF3DA181AD40BDE86A3150B27B6B030E7008B1@dbde02.ent.ti.com>

Yes,

Support for DM6446 with git kernel has been added in DSPLink release 1.65.00.02 available at http://software-dl.ti.com/dsps/dsps_public_sw/DSPLink/1_65/index.html

Deepali

________________________________
From: davinci-linux-open-source-bounces+deepali=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+deepali=ti.com at linux.davincidsp.com] On Behalf Of rohan tabish
Sent: Friday, July 16, 2010 3:30 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: DSP/BIOS Link for GIT Kernel

Is there any source for DSP/BIOS/Link for git kernel

Regard's
RT


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100811/75a48cc5/attachment.html>

From Jon.Povey at racelogic.co.uk  Wed Aug 11 04:30:28 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Wed, 11 Aug 2010 10:30:28 +0100
Subject: How to stop mtd char device generating ECC on writes?
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0903DC2323@Cloud.RL.local>

I am trying to write a binary image to NAND flash using nandwrite on TI DaVinci DM355. For historical reasons involving badly-written ROM bootloaders, I want to write the "legacy" OOB format for one area of flash (the UBL, second-stage bootloader).

For reference the legacy layout of a 2KB flash page is
  4x (512B data followed by 16B OOB (6 spare then 10 ECC)).

The "new" format used by u-boot, MTD etc. is
  2KB data followed by 64B OOB (24 spare then 40 ECC).

I can get a bootloader image with the needed (legacy) OOB and ECC using
  nanddump -f ubl0.dump -s 0x20000 -l 0x8000 -n /dev/mtd0

But I can't seem to write it back properly using nandwrite.
Testing on another partition mtd6, If I do this:
  nandwrite -r -s 0x20000 /dev/mtd6 ubl0.dump
then it seems my 64 bytes of "OOB" are skipped and I get a generated 24 bytes of 0xFF spare and 40 bytes of generated ECC.

If I use --noecc --oob instead of -r, it looks like my 64 bytes of "OOB" does get written, but then hardware ECC is getting written OVER THE TOP, i.e. the last 40 bytes have various bits 0 that should be 1 (but no 1s that should be 0)

I am looking through the nandwrite and drivers/mtd sources at the moment, but would love to get a clue if someone can tell me

- Does MTD support what I'm trying to do from userland?

- If yes, could this be a bug in the DaVinci NAND driver?

- Or, is nandwrite supposed to support this? or do I need to modify it?

Thanks folks,

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From Jon.Povey at racelogic.co.uk  Wed Aug 11 04:46:06 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Wed, 11 Aug 2010 10:46:06 +0100
Subject: How to stop mtd char device generating ECC on writes?
In-Reply-To: <4C6270A9.5090606@parrot.com>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0903DC232C@Cloud.RL.local>

Matthieu CASTET wrote:
> Jon Povey a ?crit :
>> - Does MTD support what I'm trying to do from userland?
> yes write in raw mode + MEMWRITEOOB. But you will need 2 number of
> program.

Thanks Matthieu.

Sod's law, I actually found the answer a few minutes after sending the email..
Realised I hadn't tried "--noecc --raw" combination of switches. Works great.

Sorry for noise, hopefuly some archive reader can learn from my mistake.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From vishwanath.k at ti.com  Wed Aug 11 05:08:33 2010
From: vishwanath.k at ti.com (vishwa)
Date: Wed, 11 Aug 2010 15:38:33 +0530
Subject: [PATCH v2] davinci: I2C: Adding bus frequency as module parameter
Message-ID: <1281521313-4556-1-git-send-email-vishwanath.k@ti.com>

With current implementation, when I2C is used as a module,
for slave devices which operate at different frequencies,
the bus frequency needs to be modified in the board
configuration file and kernel needs to be re-built.

This patch addresses this issue by adding bus frequency as
module parameter.

Signed-off-by: vishwa <vishwanath.k at ti.com>
---
Since v1:
a. added MODULE_PARAM_DESC.
b. Moved module parameter definitions to the beginning of the file.
c. 'pdata->bus_freq' is being set in i2c_davinci_init() function.

 drivers/i2c/busses/i2c-davinci.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 2222c87..8fbfaa2 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -98,6 +98,10 @@
 #define DAVINCI_I2C_IMR_NACK	BIT(1)
 #define DAVINCI_I2C_IMR_AL	BIT(0)
 
+static int i2c_davinci_busfreq;
+module_param(i2c_davinci_busfreq, int, 0);
+MODULE_PARM_DESC(i2c_davinci_busfreq, "bus frequency");
+
 struct davinci_i2c_dev {
 	struct device           *dev;
 	void __iomem		*base;
@@ -243,6 +247,9 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev)
 	/* put I2C into reset */
 	davinci_i2c_reset_ctrl(dev, 0);
 
+	if (i2c_davinci_busfreq != 0)
+		pdata->bus_freq = i2c_davinci_busfreq;
+
 	/* compute clock dividers */
 	i2c_davinci_calc_clk_dividers(dev);
 
-- 
1.5.6


From sshtylyov at mvista.com  Wed Aug 11 06:30:44 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 11 Aug 2010 15:30:44 +0400
Subject: [PATCH RFC v9] MUSB: DA8xx/OMAP-L1x glue layer
In-Reply-To: <20100810232245.GA26940@suse.de>
References: <201008082122.40610.sshtylyov@ru.mvista.com>
	<20100808175433.GA6442@suse.de> <4C5FCCC1.4060901@ru.mvista.com>
	<20100810232245.GA26940@suse.de>
Message-ID: <4C6289E4.3040908@ru.mvista.com>

Hello.

Greg KH wrote:

>>>> Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver.
>>>> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
>>>> Signed-off-by: Yadviga Grigorieva <yadviga at ru.mvista.com>
>>>> ---
>>>> The patch is against the recent Linus' tree. Felipe, please ACK it soonish,
>>>> so it can go into 2.6.36 at last...

>>> It's too late for .36, sorry, patches needed to be in my tree _before_
>>> the merge window opened.

>>    How much longer will I have to wait with this, I wonder?
>> You could have merged version 8 but Felipe just ignored it. :-(

> I rely on Felipe to be the one to send me musb patches.  If he's
> ignoring your patches, please take it up with him.

    Well, he's on CC list of this mail...

> thanks,

> greg k-h

WBR, Sergei

From sudhakar.raj at ti.com  Wed Aug 11 06:56:07 2010
From: sudhakar.raj at ti.com (Sudhakar Rajashekhara)
Date: Wed, 11 Aug 2010 17:26:07 +0530
Subject: [PATCH] m25p80: add support for a callback to platform code on
	successful device probe
In-Reply-To: <AANLkTi=RqZjXojM0XD0RhYj23fY+zrunFRtFTYGd3POp@mail.gmail.com>
References: <893387.4342.qm@web180301.mail.gq1.yahoo.com>
	<AANLkTi=RqZjXojM0XD0RhYj23fY+zrunFRtFTYGd3POp@mail.gmail.com>
Message-ID: <02b001cb394c$2e7ec9f0$8b7c5dd0$@raj@ti.com>

Hi Mike,

On Wed, Aug 11, 2010 at 00:32:00, Mike Frysinger wrote:
> On Tue, Aug 10, 2010 at 09:07, David Brownell wrote:
> >> On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote:
> >> it is necessary
> >> > that you do these things from kernel space instead of
> >> standard
> >> > userspace.
> >
> > Hard to get userspace to do this stuff if
> > you're doing a network boot, and thus need
> > to have the MAC address working early.. it's
> > easy if the kernel can get the MAC address,
> > else not possible to boot.  Right?
> 
> no, that isnt true at all.  you can easily have a small initramfs to
> handle all of your random setup.  if that's too much overhead, you can
> add a late initcall to your boards file that is run after the MTD
> devices are probed and let that read the required information.  all of
> this is more than documented:
> http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux
> 

I looked around in the kernel and found mtd_notifier callbacks which get
called upon addition of MTD device. Inside this callback, I am checking
for the device in which I am interested and doing a mtd->read to get the
MAC address. So this patch can be dropped.

Thanks,
Sudhakar



From rsanchezs at infoglobal.es  Wed Aug 11 08:40:42 2010
From: rsanchezs at infoglobal.es (=?utf-8?q?Ra=C3=BAl_S=C3=A1nchez_Siles?=)
Date: Wed, 11 Aug 2010 15:40:42 +0200
Subject: GIT Kernel and CMEM 2.25.04.10
In-Reply-To: <AANLkTinWicep4ygyRPeMjyKvtUgLLf062P2r1wbE2KMP@mail.gmail.com>
References: <AANLkTinWicep4ygyRPeMjyKvtUgLLf062P2r1wbE2KMP@mail.gmail.com>
Message-ID: <201008111540.43712.rsanchezs@infoglobal.es>

  Hello:

El Viernes, 23 de Julio de 2010 17:57:13 Vitaly Makarov escribi?:
> Dear All,
> 
> I am trying to compile the latest CMEM (2.25.04.10) for the latest git
> kernel and getting the following error:
> WARNING: "arm926_dma_map_area" [BSP/cmem/src/module/cmemk.ko]
> and this module can not be used with the kernel due unresolved symbol.
> 
> Did anyone faced the issue and successfully resolved it?
> 
> Thank you

  I don't know the answer to your question, but I've noticed a new linuxutils 
has been released after the ones you are using [0]. I've also seen this wiki 
page useful as general information: [1]

  HTH,

[0] http://software-
dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/index.html
[1] http://processors.wiki.ti.com/index.php/LinuxUtils_Internals

-- 
Ra?l S?nchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarc?n (Madrid), Espa?a
* T: +34 91 506 40 00
* F: +34 91 506 40 01


From khilman at deeprootsystems.com  Wed Aug 11 10:39:02 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Wed, 11 Aug 2010 08:39:02 -0700
Subject: [PATCH v2] davinci: I2C: Adding bus frequency as module parameter
In-Reply-To: <1281521313-4556-1-git-send-email-vishwanath.k@ti.com> (vishwa's
	message of "Wed, 11 Aug 2010 15:38:33 +0530")
References: <1281521313-4556-1-git-send-email-vishwanath.k@ti.com>
Message-ID: <87aaot40rt.fsf@deeprootsystems.com>

vishwa <vishwanath.k at ti.com> writes:

> With current implementation, when I2C is used as a module,
> for slave devices which operate at different frequencies,
> the bus frequency needs to be modified in the board
> configuration file and kernel needs to be re-built.
>
> This patch addresses this issue by adding bus frequency as
> module parameter.
>
> Signed-off-by: vishwa <vishwanath.k at ti.com>
> ---
> Since v1:
> a. added MODULE_PARAM_DESC.
> b. Moved module parameter definitions to the beginning of the file.
> c. 'pdata->bus_freq' is being set in i2c_davinci_init() function.
>
>  drivers/i2c/busses/i2c-davinci.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
> index 2222c87..8fbfaa2 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -98,6 +98,10 @@
>  #define DAVINCI_I2C_IMR_NACK	BIT(1)
>  #define DAVINCI_I2C_IMR_AL	BIT(0)
>  
> +static int i2c_davinci_busfreq;
> +module_param(i2c_davinci_busfreq, int, 0);
> +MODULE_PARM_DESC(i2c_davinci_busfreq, "bus frequency");
> +
>  struct davinci_i2c_dev {
>  	struct device           *dev;
>  	void __iomem		*base;
> @@ -243,6 +247,9 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev)
>  	/* put I2C into reset */
>  	davinci_i2c_reset_ctrl(dev, 0);
>  
> +	if (i2c_davinci_busfreq != 0)
> +		pdata->bus_freq = i2c_davinci_busfreq;

I don't really like using a module parameter to modify the contents of
struct platform_data, especially when this comes from a board file.

Intead this should look something like

	if (!i2c_davinci_busfreq)
		i2c_davinci_bus_freq = pdata->bus_freq;

and the code should use i2c_davinci_busfreq instead of pdata->bus_freq.

Kevin




From hemantp at ti.com  Thu Aug 12 01:15:26 2010
From: hemantp at ti.com (Pedanekar, Hemant)
Date: Thu, 12 Aug 2010 11:45:26 +0530
Subject: The 6467t evm goes to reset immediately after the switching to
	PCI mode from nand
In-Reply-To: <AANLkTikOHWdmK4hViBU7=vEJZnD2iGXfcubcmhnrKOn4@mail.gmail.com>
References: <AANLkTi=rBAatFOcg7jXb9QYYzruVnVgr+dKANj3XZwO+@mail.gmail.com>
	<AANLkTikOHWdmK4hViBU7=vEJZnD2iGXfcubcmhnrKOn4@mail.gmail.com>
Message-ID: <2A3DCF3DA181AD40BDE86A3150B27B6B030E700F6C@dbde02.ent.ti.com>

wenaideyu wenaideyu wrote on Tuesday, August 10, 2010 8:59 PM:

> Hi:
>    thanks a lot for your advice. I have printed the value of
> PCI_RST(GPIO[13]) before switching from NAND to PCI, the value is 1.
> Itmeans PCI_RST has been driven high.
> 
>    but the board still resets while the kernel calls
> "davinci_cfg_reg(DM646X_PCIEN)" in the file of board-dm646x-evm.c
> 
>    I just select the PCI bus support in the configuration of
> kernel,and I do not select the support of mtd and ata in kernel.
> 
>   shoud I do some configuration about the Davincihd1080p evm while it acts
> as a PCI host? 
> 
>    best wishes!

By default, GPIO13 may  not be used as PCI_RST.

As per the wiki link, "The Altera CPLD on the board controls the mux switches 
depending on whether or not the EVM is plugged into a PCI backplane. To instead 
control the switches with a GPIO, the CPLD must be reprogrammed with a modified 
firmware..."

-
Hemant


From scerveau at awox.com  Thu Aug 12 09:21:35 2010
From: scerveau at awox.com (Stephane Cerveau)
Date: Thu, 12 Aug 2010 16:21:35 +0200
Subject: usb 1-1: device descriptor read/64, error -110
Message-ID: <B670FA1DB6CA6E4A945001BA08E200CE30FB7D7BBF@TENERIFE.awox.com>

Dear David,



I'm using a DaVinci DM6446 and I also encounter this error.



In that case, most of the time I receive a STALL on ep0 and my usb key is blocked. I reproduce the bug very easily with a RT73 Wifi dongle, doing download on the usb key with wget.

The bug appears randomly but can be reproduced after 5/10 minutes. It seems to depend on the usb mass storage key. In that case I need to unplug the key( key locked ... blinking) and replug it. Removing the driver do not allow to recover.



What do we have to do after a stall?

In the documentation, it seems that we can restart without reseting the device but in the musb_host code it exit with  -110 (ETIMEDOUT).



I'm trying to determine the USB key provider and I will try to come back to you.



If this is a problem with my usb key, how can I detect that this key is damaged ? Do you know any PC tool which can help determining it?

Best regards.







St?phane Cerveau
Software Engineer

scerveau at awox.com<mailto:scerveau at awox.com>

Phone: +33 4 99 53 27 39


93, Pierre Duhem
34000 Montpellier
FRANCE
Phone: +33 4 67 47 10 00
Fax:      +33 4 67 47 10 15

cid:069332510 at 17112008-1528



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100812/49c204e4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 16426 bytes
Desc: image001.jpg
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100812/49c204e4/attachment-0001.jpg>

From grinberg at compulab.co.il  Tue Aug  3 09:06:50 2010
From: grinberg at compulab.co.il (Igor Grinberg)
Date: Tue, 03 Aug 2010 17:06:50 +0300
Subject: [PATCH 2/8] davinci: add mdio platform devices
In-Reply-To: <1280842313-3743-3-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
	<1280842313-3743-3-git-send-email-cyril@ti.com>
Message-ID: <4C58227A.4080502@compulab.co.il>

On 08/03/10 16:31, Cyril Chemparathy wrote:
> This patch adds mdio platform devices on SoCs that have the necessary
> hardware.  Clock lookup entries (aliases) have also been added, so that the
> MDIO and EMAC drivers can independently enable/disable a shared underlying
> clock.  Further, the EMAC MMR region has been split down into separate MDIO
> and EMAC regions.
>
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
>  arch/arm/mach-davinci/devices-da8xx.c       |   29 +++++++++++++++++++++++++-
>  arch/arm/mach-davinci/dm365.c               |   22 +++++++++++++++++++-
>  arch/arm/mach-davinci/dm644x.c              |   22 +++++++++++++++++++-
>  arch/arm/mach-davinci/dm646x.c              |   22 +++++++++++++++++++-
>  arch/arm/mach-davinci/include/mach/dm365.h  |    1 +
>  arch/arm/mach-davinci/include/mach/dm644x.h |    1 +
>  arch/arm/mach-davinci/include/mach/dm646x.h |    1 +
>  7 files changed, 93 insertions(+), 5 deletions(-)
>   

Shouldn't arch/arm/mach-omap2/board-am3517evm.c be on your list?
I think it should, or else it will be broken by:
[PATCH 5/8] netdev: cleanup unused davinci mdio emac code

-- 
Regards,
Igor.


From omar.ramirez at ti.com  Tue Aug  3 18:29:46 2010
From: omar.ramirez at ti.com (Ramirez Luna, Omar)
Date: Tue, 3 Aug 2010 18:29:46 -0500
Subject: [PATCH 1/8] netdev: separate out davinci mdio controller code
In-Reply-To: <1280842313-3743-2-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
	<1280842313-3743-2-git-send-email-cyril@ti.com>
Message-ID: <27F9C60D11D683428E133F85D2BB4A53043F3C8C2A@dlee03.ent.ti.com>

Hi,

>From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Cyril
>Chemparathy
>
>Davinci's MDIO controller is present on other TI devices, without an
>accompanying EMAC.  For example, on tnetv107x, the same MDIO module is used in
>conjunction with a 3-port switch hardware.
>
>By separating the MDIO controller code into its own platform driver, this
>patch allows common logic to be reused on such platforms.
>
>Signed-off-by: Cyril Chemparathy <cyril at ti.com>
>---
> drivers/net/Kconfig          |   10 +
> drivers/net/Makefile         |    1 +
> drivers/net/davinci_mdio.c   |  386 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/davinci_emac.h |    4 +
> 4 files changed, 401 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/davinci_mdio.c
>
[...]
>diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
>new file mode 100644
>index 0000000..d34a53a
>--- /dev/null
>+++ b/drivers/net/davinci_mdio.c
[...]
>+
>+/* wait until hardware is ready for another user access */
>+static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
>+{
>+	struct davinci_mdio_regs __iomem *regs = data->regs;
>+	u32 reg;
>+
>+	while ((reg = __raw_readl(&regs->user[0].access)) & USERACCESS_GO)
>+		;

potential infinite loop? I saw another place in your series using time_after, might fit in here too.

>+
>+	return reg;
>+}
>+
>+/* wait until hardware state machine is idle */
>+static inline void wait_for_idle(struct davinci_mdio_data *data)
>+{
>+	struct davinci_mdio_regs __iomem *regs = data->regs;
>+
>+	while ((__raw_readl(&regs->control) & CONTROL_IDLE) == 0)
>+		;

Ditto

>+}
>+
[...]

Regards,

omar

From omar.ramirez at ti.com  Tue Aug  3 18:30:02 2010
From: omar.ramirez at ti.com (Ramirez Luna, Omar)
Date: Tue, 3 Aug 2010 18:30:02 -0500
Subject: [PATCH 6/8] netdev: separate out davinci cpdma controller code
In-Reply-To: <1280842313-3743-7-git-send-email-cyril@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
	<1280842313-3743-7-git-send-email-cyril@ti.com>
Message-ID: <27F9C60D11D683428E133F85D2BB4A53043F3C8C2B@dlee03.ent.ti.com>

Hi,

>From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of
>Chemparathy, Cyril
>
>In addition to being embedded into the EMAC controller, the CPDMA hardware
>block is used in TI's CPSW switch controller.  Fortunately, the programming
>interface to this hardware block remains pretty nicely consistent across these
>devices.
>
>This patch adds a new CPDMA services layer, which can then be reused across
>EMAC and CPSW drivers.
>
>Signed-off-by: Cyril Chemparathy <cyril at ti.com>
>---
> drivers/net/Kconfig         |   10 +
> drivers/net/Makefile        |    1 +
> drivers/net/davinci_cpdma.c |  836 +++++++++++++++++++++++++++++++++++++++++++
> drivers/net/davinci_cpdma.h |  105 ++++++
> 4 files changed, 952 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/davinci_cpdma.c
> create mode 100644 drivers/net/davinci_cpdma.h
>
[...]
>diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
>new file mode 100644
>index 0000000..acce1c1
>--- /dev/null
>+++ b/drivers/net/davinci_cpdma.c
[...]
>+struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
>+				     cpdma_handler_fn handler)
>+{
>+	struct cpdma_chan *chan;
>+	int ret, offset = (chan_num % CPDMA_MAX_CHANNELS) * 4;
>+	unsigned long flags;
>+
>+	if (__chan_linear(chan_num) >= ctlr->num_chan)
>+		return NULL;
>+
>+	ret = -ENOMEM;
>+	chan = kzalloc(sizeof(*chan), GFP_KERNEL);
>+	if (!chan)
>+		goto err_chan_alloc;
>+
>+	spin_lock_irqsave(&ctlr->lock, flags);
>+	ret = -EBUSY;
>+	if (ctlr->channels[chan_num])
>+		goto err_chan_busy;

Mem leaking 'chan'

>+
>+	chan->ctlr	= ctlr;
>+	chan->state	= CPDMA_STATE_IDLE;
>+	chan->chan_num	= chan_num;
>+	chan->handler	= handler;
>+
>+	if (is_rx_chan(chan)) {
>+		chan->hdp	= ctlr->params.rxhdp + offset;
>+		chan->cp	= ctlr->params.rxcp + offset;
>+		chan->rxfree	= ctlr->params.rxfree + offset;
>+		chan->int_set	= CPDMA_RXINTMASKSET;
>+		chan->int_clear	= CPDMA_RXINTMASKCLEAR;
>+		chan->td	= CPDMA_RXTEARDOWN;
>+		chan->dir	= DMA_FROM_DEVICE;
>+	} else {
>+		chan->hdp	= ctlr->params.txhdp + offset;
>+		chan->cp	= ctlr->params.txcp + offset;
>+		chan->int_set	= CPDMA_TXINTMASKSET;
>+		chan->int_clear	= CPDMA_TXINTMASKCLEAR;
>+		chan->td	= CPDMA_TXTEARDOWN;
>+		chan->dir	= DMA_TO_DEVICE;
>+	}
>+	chan->mask = BIT(chan_linear(chan));
>+
>+	spin_lock_init(&chan->lock);
>+
>+	ctlr->channels[chan_num] = chan;
>+	spin_unlock_irqrestore(&ctlr->lock, flags);
>+	return chan;
>+
>+err_chan_busy:
>+	spin_unlock_irqrestore(&ctlr->lock, flags);
>+err_chan_alloc:
>+	return ERR_PTR(ret);
>+}
[...]

Regards,

omar

From grinberg at compulab.co.il  Wed Aug  4 01:58:26 2010
From: grinberg at compulab.co.il (Igor Grinberg)
Date: Wed, 04 Aug 2010 09:58:26 +0300
Subject: [PATCH 2/8] davinci: add mdio platform devices
In-Reply-To: <4C582879.7060708@ti.com>
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
	<1280842313-3743-3-git-send-email-cyril@ti.com>
	<4C58227A.4080502@compulab.co.il> <4C582879.7060708@ti.com>
Message-ID: <4C590F92.1040003@compulab.co.il>

On 08/03/10 17:32, Cyril Chemparathy wrote:
> Hi Igor,
>
>   
>> Shouldn't arch/arm/mach-omap2/board-am3517evm.c be on your list?
>> I think it should, or else it will be broken by:
>> [PATCH 5/8] netdev: cleanup unused davinci mdio emac code
>>     
> Correct.  As stated in the series summary:
>
>   
>> Additional omap tree patches will be required for am35xx as well
>> (not included here).
>>     

Sorry for missing that,
my laziness and long cover letter made me miss it :)
Do you plan on bringing those patches?
Wouldn't it be better for those patches to be included in the series?
Because, merging code that breaks other platform(s) is not so nice...

> Regards
> Cyril.
>
>   

-- 
Regards,
Igor.


From santosh.shilimkar at ti.com  Sun Aug  8 05:18:22 2010
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Sun,  8 Aug 2010 15:48:22 +0530
Subject: [PATCH 3/3] davinci: Map sram using MT_MEMORY_NONCACHED instead of
	MT_DEVICE
Message-ID: <1281262702-27732-1-git-send-email-santosh.shilimkar@ti.com>

On Davinci SRAM is mapped as MT_DEVICE becasue of the section
mapping pre-requisite instead of intended MT_MEMORY_NONCACHED

Since the section mapping limitation gets fixed with first
patch in this series, the MT_MEMORY_NONCACHED can be used now.

Have not tested this, so somebody with Davinci hardware can
try this out

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: Kevin Hilman <khilman at deeprootsystems.com>
---
 arch/arm/mach-davinci/dm355.c  |    3 +--
 arch/arm/mach-davinci/dm365.c  |    3 +--
 arch/arm/mach-davinci/dm644x.c |    3 +--
 arch/arm/mach-davinci/dm646x.c |    3 +--
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 3834781..e7bd2ad 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -767,8 +767,7 @@ static struct map_desc dm355_io_desc[] = {
 		.virtual	= SRAM_VIRT,
 		.pfn		= __phys_to_pfn(0x00010000),
 		.length		= SZ_32K,
-		/* MT_MEMORY_NONCACHED requires supersection alignment */
-		.type		= MT_DEVICE,
+		.type		= MT_MEMORY_NONCACHED,
 	},
 };
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index a146849..5dee032 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -967,8 +967,7 @@ static struct map_desc dm365_io_desc[] = {
 		.virtual	= SRAM_VIRT,
 		.pfn		= __phys_to_pfn(0x00010000),
 		.length		= SZ_32K,
-		/* MT_MEMORY_NONCACHED requires supersection alignment */
-		.type		= MT_DEVICE,
+		.type		= MT_MEMORY_NONCACHED,
 	},
 };
 
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 7ad1520..5112d51 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -651,8 +651,7 @@ static struct map_desc dm644x_io_desc[] = {
 		.virtual	= SRAM_VIRT,
 		.pfn		= __phys_to_pfn(0x00008000),
 		.length		= SZ_16K,
-		/* MT_MEMORY_NONCACHED requires supersection alignment */
-		.type		= MT_DEVICE,
+		.type		= MT_MEMORY_NONCACHED,
 	},
 };
 
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 9404565..97078f4 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -735,8 +735,7 @@ static struct map_desc dm646x_io_desc[] = {
 		.virtual	= SRAM_VIRT,
 		.pfn		= __phys_to_pfn(0x00010000),
 		.length		= SZ_32K,
-		/* MT_MEMORY_NONCACHED requires supersection alignment */
-		.type		= MT_DEVICE,
+		.type		= MT_MEMORY_NONCACHED,
 	},
 };
 
-- 
1.6.0.4


From gregkh at suse.de  Sun Aug  8 12:54:33 2010
From: gregkh at suse.de (Greg KH)
Date: Sun, 8 Aug 2010 10:54:33 -0700
Subject: [PATCH RFC v9] MUSB: DA8xx/OMAP-L1x glue layer
In-Reply-To: <201008082122.40610.sshtylyov@ru.mvista.com>
References: <201008082122.40610.sshtylyov@ru.mvista.com>
Message-ID: <20100808175433.GA6442@suse.de>

On Sun, Aug 08, 2010 at 09:22:40PM +0400, Sergei Shtylyov wrote:
> Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver.
> 
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
> Signed-off-by: Yadviga Grigorieva <yadviga at ru.mvista.com>
> 
> ---
> The patch is against the recent Linus' tree. Felipe, please ACK it soonish,
> so it can go into 2.6.36 at last...

It's too late for .36, sorry, patches needed to be in my tree _before_
the merge window opened.

thanks,

greg k-h

From vapier.adi at gmail.com  Tue Aug 10 02:17:05 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Tue, 10 Aug 2010 03:17:05 -0400
Subject: [PATCH] m25p80: add support for a callback to platform code on 
	successful device probe
In-Reply-To: <1281422578-20461-1-git-send-email-sudhakar.raj@ti.com>
References: <1281422578-20461-1-git-send-email-sudhakar.raj@ti.com>
Message-ID: <AANLkTimJAiUfyAYd6aoftbexKaBOz5A8BjX-fgumkWU9@mail.gmail.com>

On Tue, Aug 10, 2010 at 02:42, Sudhakar Rajashekhara wrote:
> On some platforms, MTD device can hold MAC address, calibration
> data, serial numbers etc.

pretty standard behavior ...

> On TI's DA850/OMAP-L138/AM18xx EVM, MAC address is stored on
> the last sector of the SPI flash, which is exported as an MTD
> device.

again, nothing unique here ...

> This patch adds two new members to the 'flash_platform_data'
> structure, a function handler which will be called after
> add_mtd_device() and an argument to be passed to this function,
> for example: offset to read from.

... and your changelog falls apart.  the intro gives no basis that i
can see as to why you need these hooks.

please give examples of what you're actually trying to accomplish and
how these hooks help you accomplish said goal and why it is necessary
that you do these things from kernel space instead of standard
userspace.
-mike

From vapier.adi at gmail.com  Tue Aug 10 14:02:00 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Tue, 10 Aug 2010 15:02:00 -0400
Subject: [PATCH] m25p80: add support for a callback to platform code on 
	successful device probe
In-Reply-To: <893387.4342.qm@web180301.mail.gq1.yahoo.com>
References: <893387.4342.qm@web180301.mail.gq1.yahoo.com>
Message-ID: <AANLkTi=RqZjXojM0XD0RhYj23fY+zrunFRtFTYGd3POp@mail.gmail.com>

On Tue, Aug 10, 2010 at 09:07, David Brownell wrote:
>> On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote:
>> it is necessary
>> > that you do these things from kernel space instead of
>> standard
>> > userspace.
>
> Hard to get userspace to do this stuff if
> you're doing a network boot, and thus need
> to have the MAC address working early.. it's
> easy if the kernel can get the MAC address,
> else not possible to boot. ?Right?

no, that isnt true at all.  you can easily have a small initramfs to
handle all of your random setup.  if that's too much overhead, you can
add a late initcall to your boards file that is run after the MTD
devices are probed and let that read the required information.  all of
this is more than documented:
http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux

i still see these callbacks as unnecessary overhead to solve problems
that can already be done multiple ways with existing code.
-mike

From gregkh at suse.de  Tue Aug 10 18:22:45 2010
From: gregkh at suse.de (Greg KH)
Date: Tue, 10 Aug 2010 16:22:45 -0700
Subject: [PATCH RFC v9] MUSB: DA8xx/OMAP-L1x glue layer
In-Reply-To: <4C5FCCC1.4060901@ru.mvista.com>
References: <201008082122.40610.sshtylyov@ru.mvista.com>
	<20100808175433.GA6442@suse.de> <4C5FCCC1.4060901@ru.mvista.com>
Message-ID: <20100810232245.GA26940@suse.de>

On Mon, Aug 09, 2010 at 01:39:13PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> Greg KH wrote:
> 
> >>Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver.
> 
> >>Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
> >>Signed-off-by: Yadviga Grigorieva <yadviga at ru.mvista.com>
> 
> >>---
> >>The patch is against the recent Linus' tree. Felipe, please ACK it soonish,
> >>so it can go into 2.6.36 at last...
> 
> >It's too late for .36, sorry, patches needed to be in my tree _before_
> >the merge window opened.
> 
>    How much longer will I have to wait with this, I wonder?
> You could have merged version 8 but Felipe just ignored it. :-(

I rely on Felipe to be the one to send me musb patches.  If he's
ignoring your patches, please take it up with him.

thanks,

greg k-h

From matthieu.castet at parrot.com  Wed Aug 11 04:43:05 2010
From: matthieu.castet at parrot.com (Matthieu CASTET)
Date: Wed, 11 Aug 2010 11:43:05 +0200
Subject: How to stop mtd char device generating ECC on writes?
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0903DC2323@Cloud.RL.local>
References: <70E876B0EA86DD4BAF101844BC814DFE0903DC2323@Cloud.RL.local>
Message-ID: <4C6270A9.5090606@parrot.com>

Hi,

Jon Povey a ?crit :
> But I can't seem to write it back properly using nandwrite.
> Testing on another partition mtd6, If I do this:
>   nandwrite -r -s 0x20000 /dev/mtd6 ubl0.dump
> then it seems my 64 bytes of "OOB" are skipped and I get a generated 24 bytes of 0xFF spare and 40 bytes of generated ECC.
> 
> If I use --noecc --oob instead of -r, it looks like my 64 bytes of "OOB" does get written, but then hardware ECC is getting written OVER THE TOP, i.e. the last 40 bytes have various bits 0 that should be 1 (but no 1s that should be 0)
> 
> I am looking through the nandwrite and drivers/mtd sources at the moment, but would love to get a clue if someone can tell me
> 
> - Does MTD support what I'm trying to do from userland?
yes write in raw mode + MEMWRITEOOB. But you will need 2 number of program.

> 
> - If yes, could this be a bug in the DaVinci NAND driver?
> 
> - Or, is nandwrite supposed to support this? or do I need to modify it?
> 
I don't know nandwrite


Matthieu.

From vapier.adi at gmail.com  Wed Aug 11 12:27:36 2010
From: vapier.adi at gmail.com (Mike Frysinger)
Date: Wed, 11 Aug 2010 13:27:36 -0400
Subject: [PATCH] m25p80: add support for a callback to platform code on 
	successful device probe
In-Reply-To: <-1845909207770903949@unknownmsgid>
References: <893387.4342.qm@web180301.mail.gq1.yahoo.com>
	<AANLkTi=RqZjXojM0XD0RhYj23fY+zrunFRtFTYGd3POp@mail.gmail.com> 
	<-1845909207770903949@unknownmsgid>
Message-ID: <AANLkTimQOPe3MvxKtQ8q1Wf3+EsOf+NY7Vr8R5SG+uqU@mail.gmail.com>

On Wed, Aug 11, 2010 at 07:56, Sudhakar Rajashekhara wrote:
> On Wed, Aug 11, 2010 at 00:32:00, Mike Frysinger wrote:
>> On Tue, Aug 10, 2010 at 09:07, David Brownell wrote:
>> >> On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote:
>> >> it is necessary
>> >> > that you do these things from kernel space instead of
>> >> standard
>> >> > userspace.
>> >
>> > Hard to get userspace to do this stuff if
>> > you're doing a network boot, and thus need
>> > to have the MAC address working early.. it's
>> > easy if the kernel can get the MAC address,
>> > else not possible to boot. ?Right?
>>
>> no, that isnt true at all. ?you can easily have a small initramfs to
>> handle all of your random setup. ?if that's too much overhead, you can
>> add a late initcall to your boards file that is run after the MTD
>> devices are probed and let that read the required information. ?all of
>> this is more than documented:
>> http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux
>
> I looked around in the kernel and found mtd_notifier callbacks which get
> called upon addition of MTD device. Inside this callback, I am checking
> for the device in which I am interested and doing a mtd->read to get the
> MAC address. So this patch can be dropped.

thanks for the follow up explanation
-mike

From wenaideyu at gmail.com  Sat Aug 14 00:19:43 2010
From: wenaideyu at gmail.com (wenaideyu wenaideyu)
Date: Sat, 14 Aug 2010 13:19:43 +0800
Subject: The 6467t evm goes to reset immediately after the switching to
	PCI mode from nand
In-Reply-To: <2A3DCF3DA181AD40BDE86A3150B27B6B030E700F6C@dbde02.ent.ti.com>
References: <AANLkTi=rBAatFOcg7jXb9QYYzruVnVgr+dKANj3XZwO+@mail.gmail.com>
	<AANLkTikOHWdmK4hViBU7=vEJZnD2iGXfcubcmhnrKOn4@mail.gmail.com>
	<2A3DCF3DA181AD40BDE86A3150B27B6B030E700F6C@dbde02.ent.ti.com>
Message-ID: <AANLkTinbSu5b=onYekU2n6mJwSywQhd-JCyZi+tRV1oh@mail.gmail.com>

thanks, we have reprogrammed the CPLD, but it still resets as before.

1?  we use TMS320DM6467 HD 1080P Evaluation Module ,  DM6467T(1Ghz)
and we use 2.6.32-rc2 and select "Bus support--->PCI support" in
kernel.


2?  set of SW3 on the board ?1110 0000?select " NAND Flash  boot";

3?  after Uboot  finished,we use tftp to download uImage

4?  uImage is uncompressed compeletely, then begins to run ...   when
it runs to "nand flash -> PCI"("davinci_cfg_reg(DM646X_PCIEN)" in
board-dm646x-evm.c), the board resets again?

2010/8/12, Pedanekar, Hemant <hemantp at ti.com>:
> wenaideyu wenaideyu wrote on Tuesday, August 10, 2010 8:59 PM:
>
>> Hi:
>>    thanks a lot for your advice. I have printed the value of
>> PCI_RST(GPIO[13]) before switching from NAND to PCI, the value is 1.
>> Itmeans PCI_RST has been driven high.
>>
>>    but the board still resets while the kernel calls
>> "davinci_cfg_reg(DM646X_PCIEN)" in the file of board-dm646x-evm.c
>>
>>    I just select the PCI bus support in the configuration of
>> kernel,and I do not select the support of mtd and ata in kernel.
>>
>>   shoud I do some configuration about the Davincihd1080p evm while it acts
>> as a PCI host?
>>
>>    best wishes!
>
> By default, GPIO13 may  not be used as PCI_RST.
>
> As per the wiki link, "The Altera CPLD on the board controls the mux
> switches
> depending on whether or not the EVM is plugged into a PCI backplane. To
> instead
> control the switches with a GPIO, the CPLD must be reprogrammed with a
> modified
> firmware..."
>
> -
> Hemant
>
>

From gu.xy.george at gmail.com  Sat Aug 14 00:23:28 2010
From: gu.xy.george at gmail.com (Gu George)
Date: Sat, 14 Aug 2010 13:23:28 +0800
Subject: The 6467t evm goes to reset immediately after the switching to
	PCI mode from nand
In-Reply-To: <AANLkTinbSu5b=onYekU2n6mJwSywQhd-JCyZi+tRV1oh@mail.gmail.com>
References: <AANLkTi=rBAatFOcg7jXb9QYYzruVnVgr+dKANj3XZwO+@mail.gmail.com>
	<AANLkTikOHWdmK4hViBU7=vEJZnD2iGXfcubcmhnrKOn4@mail.gmail.com>
	<2A3DCF3DA181AD40BDE86A3150B27B6B030E700F6C@dbde02.ent.ti.com>
	<AANLkTinbSu5b=onYekU2n6mJwSywQhd-JCyZi+tRV1oh@mail.gmail.com>
Message-ID: <AANLkTikLPO0Ag+8OJkHjgN2AQ_=D_HNm2URnX4pBkz4M@mail.gmail.com>

Guy?

Pls refer the errata of DM6467T first, there is bug related to your
question.

? 2010?8?14? ??1:19?wenaideyu wenaideyu <wenaideyu at gmail.com>???

> thanks, we have reprogrammed the CPLD, but it still resets as before.
>
> 1?  we use TMS320DM6467 HD 1080P Evaluation Module ,  DM6467T(1Ghz)
> and we use 2.6.32-rc2 and select "Bus support--->PCI support" in
> kernel.
>
>
> 2?  set of SW3 on the board ?1110 0000?select " NAND Flash  boot";
>
> 3?  after Uboot  finished,we use tftp to download uImage
>
> 4?  uImage is uncompressed compeletely, then begins to run ...   when
> it runs to "nand flash -> PCI"("davinci_cfg_reg(DM646X_PCIEN)" in
> board-dm646x-evm.c), the board resets again?
>
> 2010/8/12, Pedanekar, Hemant <hemantp at ti.com>:
> > wenaideyu wenaideyu wrote on Tuesday, August 10, 2010 8:59 PM:
> >
> >> Hi:
> >>    thanks a lot for your advice. I have printed the value of
> >> PCI_RST(GPIO[13]) before switching from NAND to PCI, the value is 1.
> >> Itmeans PCI_RST has been driven high.
> >>
> >>    but the board still resets while the kernel calls
> >> "davinci_cfg_reg(DM646X_PCIEN)" in the file of board-dm646x-evm.c
> >>
> >>    I just select the PCI bus support in the configuration of
> >> kernel,and I do not select the support of mtd and ata in kernel.
> >>
> >>   shoud I do some configuration about the Davincihd1080p evm while it
> acts
> >> as a PCI host?
> >>
> >>    best wishes!
> >
> > By default, GPIO13 may  not be used as PCI_RST.
> >
> > As per the wiki link, "The Altera CPLD on the board controls the mux
> > switches
> > depending on whether or not the EVM is plugged into a PCI backplane. To
> > instead
> > control the switches with a GPIO, the CPLD must be reprogrammed with a
> > modified
> > firmware..."
> >
> > -
> > Hemant
> >
> >
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100814/89c53e7b/attachment.html>

From vladoman at gmail.com  Sat Aug 14 07:58:06 2010
From: vladoman at gmail.com (Vladimir Pantelic)
Date: Sat, 14 Aug 2010 14:58:06 +0200
Subject: How to exit this group?please
In-Reply-To: <201008110933474848695@163.com>
References: <201008110933474848695@163.com>
Message-ID: <4C6692DE.4010308@gmail.com>

On 08/11/2010 03:33 AM, seek_for wrote:
> How to exit this group?please

clicking on the links at the bottom of each post might help...

> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


From windlazio at gmail.com  Sun Aug 15 03:30:55 2010
From: windlazio at gmail.com (Han Jun-peng)
Date: Sun, 15 Aug 2010 16:30:55 +0800
Subject: The type of the Noise filter in DM355
Message-ID: <AANLkTimYka6_M1FSrZfCyz5+CkFggjnMf4-w_JD9TCxA@mail.gmail.com>

Hi,All
I have a project to use the DM355 to develop an IPNC, but the image noise is
very serious,there is very little information of noise filter in the DM355
VPFE document.
I want to use noise filter in DM355 IPIPE module to fllter out the noise and
make the image looks more smooth,any body can provide some information about
this noise
filter and what does it mean that the threshold value,the intensity value
and the spread value?
I think this module is mainly used to filter out the Gguassian noise in the
image, isn't it?so what is the type of the noise filter?sigma filter or
other?how it works,thank you!
Any help will be appreciated! thank you very much again!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100815/5d9803c2/attachment.html>

From hitesh.patel at einfochips.com  Mon Aug 16 03:18:28 2010
From: hitesh.patel at einfochips.com (hitesh)
Date: Mon, 16 Aug 2010 13:48:28 +0530
Subject: IPIPE issue in DM365
Message-ID: <4C68F454.6010700@einfochips.com>

  Hi All,

I am facing memory leak issue in Chroma Conversion module of  DM365 IPIPE.
When I run the ioctl(resizer_fd, RSZ_RESIZE, &convert) ioctl, It 
increase my memory usage and it is gradually increasing it in
every call of of ioctl. Do you have any solution? I want to do chroma 
conversion for encode my video with H264 encoder.

My configuration for IPIPE is as below.
     INPUT_WIDTH =1280
     INPUT_HEIGHT =720

          rsz_ss_config.input.image_width = INPUT_WIDTH;
         rsz_ss_config.input.image_height = INPUT_HEIGHT;
         rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
         rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height + 10;
         rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
         rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
         rsz_ss_config.output1.enable = 1;
         rsz_ss_config.output1.width = INPUT_WIDTH;
         rsz_ss_config.output1.height = INPUT_HEIGHT;
         rsz_ss_config.output2.enable = 0;

         rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
         rsz_chan_config.chain = 0;


I am calling ioctl as below.

  convert.in_buff.buf_type = IMP_BUF_IN;
         convert.in_buff.index = 0;
         convert.in_buff.offset = buf_in[0].offset;
         convert.in_buff.size = buf_in[0].size;
         convert.out_buff1.buf_type = IMP_BUF_OUT1;
         convert.out_buff1.index = 0;
         convert.out_buff1.offset = buf_out1[0].offset;
         convert.out_buff1.size = buf_out1[0].size;
         if (ioctl(resizer_fd, RSZ_RESIZE, &convert) < 0) {
                 perror("Error in doing preview\n");
                 munmap(input_buffer, buf_in[0].size);
                 munmap(output_buffer, buf_out1[0].size);
                 close(resizer_fd);
                 fclose(inp_f);
                 fclose(outp_f);
                 exit(1);
         }



Thanks
Hitesh



From albertbu at gmail.com  Mon Aug 16 05:17:51 2010
From: albertbu at gmail.com (Albert Burbea)
Date: Mon, 16 Aug 2010 13:17:51 +0300
Subject: IPIPE issue in DM365
In-Reply-To: <4C68F454.6010700@einfochips.com>
References: <4C68F454.6010700@einfochips.com>
Message-ID: <AANLkTi=H7JbER954UHYb89fXHQL4MT6ueCTn6adN6b5m@mail.gmail.com>

Hi
seems strange to me that you use
convert.in_buff.index = 0;
convert.out_buff1.index = 0;
with the same index.
In the dvsdk for DaVinci (2.1 to the best of my knowledge) you should use -1
for buffers that have not been allocated by the resizer itself.
I hope this did not confuse you
Albert

On Mon, Aug 16, 2010 at 11:18 AM, hitesh <hitesh.patel at einfochips.com>wrote:

>  Hi All,
>
> I am facing memory leak issue in Chroma Conversion module of  DM365 IPIPE.
> When I run the ioctl(resizer_fd, RSZ_RESIZE, &convert) ioctl, It increase
> my memory usage and it is gradually increasing it in
> every call of of ioctl. Do you have any solution? I want to do chroma
> conversion for encode my video with H264 encoder.
>
> My configuration for IPIPE is as below.
>    INPUT_WIDTH =1280
>    INPUT_HEIGHT =720
>
>         rsz_ss_config.input.image_width = INPUT_WIDTH;
>        rsz_ss_config.input.image_height = INPUT_HEIGHT;
>        rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
>        rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height + 10;
>        rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
>        rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
>        rsz_ss_config.output1.enable = 1;
>        rsz_ss_config.output1.width = INPUT_WIDTH;
>        rsz_ss_config.output1.height = INPUT_HEIGHT;
>        rsz_ss_config.output2.enable = 0;
>
>        rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
>        rsz_chan_config.chain = 0;
>
>
> I am calling ioctl as below.
>
>  convert.in_buff.buf_type = IMP_BUF_IN;
>        convert.in_buff.index = 0;
>        convert.in_buff.offset = buf_in[0].offset;
>        convert.in_buff.size = buf_in[0].size;
>        convert.out_buff1.buf_type = IMP_BUF_OUT1;
>        convert.out_buff1.index = 0;
>        convert.out_buff1.offset = buf_out1[0].offset;
>        convert.out_buff1.size = buf_out1[0].size;
>        if (ioctl(resizer_fd, RSZ_RESIZE, &convert) < 0) {
>                perror("Error in doing preview\n");
>                munmap(input_buffer, buf_in[0].size);
>                munmap(output_buffer, buf_out1[0].size);
>                close(resizer_fd);
>                fclose(inp_f);
>                fclose(outp_f);
>                exit(1);
>        }
>
>
>
> Thanks
> Hitesh
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>



-- 
Albert Burbea
Harishonim 8
Ramat Gan 52502, Israel
Tel/Fax + 972-3-7526016
Mobile: +972-52-3541842
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100816/5e8e3f3f/attachment.html>

From hitesh.patel at einfochips.com  Mon Aug 16 06:17:11 2010
From: hitesh.patel at einfochips.com (hitesh)
Date: Mon, 16 Aug 2010 16:47:11 +0530
Subject: IPIPE issue in DM365
In-Reply-To: <AANLkTi=H7JbER954UHYb89fXHQL4MT6ueCTn6adN6b5m@mail.gmail.com>
References: <4C68F454.6010700@einfochips.com>
	<AANLkTi=H7JbER954UHYb89fXHQL4MT6ueCTn6adN6b5m@mail.gmail.com>
Message-ID: <4C691E37.30301@einfochips.com>

  Thanks  Albert for your prompt response..

If my application want to allocate memory  and I want to pass that 
memory to IPIPE module then
what should be the parameter?
Do you have any sample application that only doing chroma conversion 
from 422 to 420 without resizing of width and height?
My application getting kernel panic as below.




Read from file done
hResizerHandle 0x2f6c0,srcOffset 0x8ba3e000,destOffset 0x8b87c000
Again in Hell1
Again in Hell22
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Resize operationpgd = c41f0000
  completed succe[00000000] *pgd=8770f031ssfully.Write to, *pte=00000000 
file done
cou, *ppte=00000000nt 13
file read

Read from fileInternal error: Oops: 817 [#1]
Modules linked in: dm365mmap edmak irqk cmemk
CPU: 0
PC is at nfs_update_request+0x194/0x36c
LR is at radix_tree_node_alloc+0x24/0x5c
pc : [<c0120798>]    lr : [<c01d68dc>]    Not tainted
sp : c41dbc70  ip : c057c960  fp : c41dbcb4
r10: c40f8a10  r9 : c40f8918  r8 : 00000000
r7 : c40f89f0  r6 : c44863a0  r5 : ffffffef  r4 : 00000000
r3 : ffffffef  r2 : 00000001  r1 : c33e7ee8  r0 : ffffffef
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 5317F
Table: 841F0000  DAC: 00000015
Process resizer_test (pid: 830, stack limit = 0xc41da258)
Stack: (0xc41dbc70 to 0xc41dc000)

-Hitesh



On 08/16/2010 03:47 PM, Albert Burbea wrote:
> Hi
> seems strange to me that you use
> convert.in_buff.index = 0;
> convert.out_buff1.index = 0;
> with the same index.
> In the dvsdk for DaVinci (2.1 to the best of my knowledge) you should 
> use -1 for buffers that have not been allocated by the resizer itself.
> I hope this did not confuse you
> Albert
>
> On Mon, Aug 16, 2010 at 11:18 AM, hitesh <hitesh.patel at einfochips.com 
> <mailto:hitesh.patel at einfochips.com>> wrote:
>
>      Hi All,
>
>     I am facing memory leak issue in Chroma Conversion module of
>      DM365 IPIPE.
>     When I run the ioctl(resizer_fd, RSZ_RESIZE, &convert) ioctl, It
>     increase my memory usage and it is gradually increasing it in
>     every call of of ioctl. Do you have any solution? I want to do
>     chroma conversion for encode my video with H264 encoder.
>
>     My configuration for IPIPE is as below.
>        INPUT_WIDTH =1280
>        INPUT_HEIGHT =720
>
>             rsz_ss_config.input.image_width = INPUT_WIDTH;
>            rsz_ss_config.input.image_height = INPUT_HEIGHT;
>            rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
>            rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height
>     + 10;
>            rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
>            rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
>            rsz_ss_config.output1.enable = 1;
>            rsz_ss_config.output1.width = INPUT_WIDTH;
>            rsz_ss_config.output1.height = INPUT_HEIGHT;
>            rsz_ss_config.output2.enable = 0;
>
>            rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
>            rsz_chan_config.chain = 0;
>
>
>     I am calling ioctl as below.
>
>      convert.in_buff.buf_type = IMP_BUF_IN;
>            convert.in_buff.index = 0;
>            convert.in_buff.offset = buf_in[0].offset;
>            convert.in_buff.size = buf_in[0].size;
>            convert.out_buff1.buf_type = IMP_BUF_OUT1;
>            convert.out_buff1.index = 0;
>            convert.out_buff1.offset = buf_out1[0].offset;
>            convert.out_buff1.size = buf_out1[0].size;
>            if (ioctl(resizer_fd, RSZ_RESIZE, &convert) < 0) {
>                    perror("Error in doing preview\n");
>                    munmap(input_buffer, buf_in[0].size);
>                    munmap(output_buffer, buf_out1[0].size);
>                    close(resizer_fd);
>                    fclose(inp_f);
>                    fclose(outp_f);
>                    exit(1);
>            }
>
>
>
>     Thanks
>     Hitesh
>
>
>     _______________________________________________
>     Davinci-linux-open-source mailing list
>     Davinci-linux-open-source at linux.davincidsp.com
>     <mailto:Davinci-linux-open-source at linux.davincidsp.com>
>     http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
>
>
> -- 
> Albert Burbea
> Harishonim 8
> Ramat Gan 52502, Israel
> Tel/Fax + 972-3-7526016
> Mobile: +972-52-3541842
>
>
> *Email Scanned for Virus & Dangerous Content by :* 
> *www.CleanMailGateway.com*
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100816/06c36f3f/attachment-0001.html>

From Jon.Povey at racelogic.co.uk  Mon Aug 16 06:43:50 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Mon, 16 Aug 2010 12:43:50 +0100
Subject: C implementation of DaVinci 4-bit NAND ECC?
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0903DC286C@Cloud.RL.local>

Just on the off-chance I'm reinventing the wheel, are there any C implementations of the DaVinci 4-bit NAND ECC algorithm out there?

I am aware of the C# implementation in the TI flash_utils, looking through it there is more Scary Maths than I anticipated. Planning to reverse-engineer and rewrite it in C, hardcoded for 512 bytes + 4-bit sizing, unless there is a better idea (no, I don't want to use Mono, and it needs to build with GCC.)

For context, this is to run on the DM355 so I can calculate ECC in software and write NAND flash in raw mode with different OOB layouts.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From c.aeschlimann at acn-group.ch  Mon Aug 16 07:35:32 2010
From: c.aeschlimann at acn-group.ch (Christophe Aeschlimann)
Date: Mon, 16 Aug 2010 14:35:32 +0200
Subject: C implementation of DaVinci 4-bit NAND ECC?
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0903DC286C@Cloud.RL.local>
References: <70E876B0EA86DD4BAF101844BC814DFE0903DC286C@Cloud.RL.local>
Message-ID: <4C693094.7070805@acn-group.ch>

On 16.08.2010 13:43, Jon Povey wrote:
> Just on the off-chance I'm reinventing the wheel, are there any C implementations of the DaVinci 4-bit NAND ECC algorithm out there?
>
> I am aware of the C# implementation in the TI flash_utils, looking through it there is more Scary Maths than I anticipated. Planning to reverse-engineer and rewrite it in C, hardcoded for 512 bytes + 4-bit sizing, unless there is a better idea (no, I don't want to use Mono, and it needs to build with GCC.)
>
> For context, this is to run on the DM355 so I can calculate ECC in software and write NAND flash in raw mode with different OOB layouts.

I think it's been implemented as a part of the OpenOCD project.

Have a look : http://developer.berlios.de/projects/openocd/

Regards,


-- 
Christophe Aeschlimann

Embedded Software Engineer

Advanced Communications Networks S.A.

Rue du Puits-Godet 8a
2000 Neuch?tel, Switzerland

T?l. +41 32 724 74 31

c.aeschlimann at acn-group.ch

>
> --
> Jon Povey
> jon.povey at racelogic.co.uk
>
> Racelogic is a limited company registered in England. Registered number 2743719 .
> Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
>
> The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From david-b at pacbell.net  Mon Aug 16 07:41:49 2010
From: david-b at pacbell.net (David Brownell)
Date: Mon, 16 Aug 2010 05:41:49 -0700 (PDT)
Subject: C implementation of DaVinci 4-bit NAND ECC?
In-Reply-To: <4C693094.7070805@acn-group.ch>
Message-ID: <397319.55754.qm@web180312.mail.gq1.yahoo.com>

> I think it's been implemented as a part of the
> OpenOCD project.

Not unless someone snuck in a LOT of code when I
wasn't looking.  The original DaVinci NAND support
used the hardware ECC logic for 1-bit and 4-bit ECC.

- Dave



From c.aeschlimann at acn-group.ch  Mon Aug 16 07:56:38 2010
From: c.aeschlimann at acn-group.ch (Christophe Aeschlimann)
Date: Mon, 16 Aug 2010 14:56:38 +0200
Subject: C implementation of DaVinci 4-bit NAND ECC?
In-Reply-To: <397319.55754.qm@web180312.mail.gq1.yahoo.com>
References: <397319.55754.qm@web180312.mail.gq1.yahoo.com>
Message-ID: <4C693586.4010303@acn-group.ch>

On 16.08.2010 14:41, David Brownell wrote:
>> I think it's been implemented as a part of the
>> OpenOCD project.
>
> Not unless someone snuck in a LOT of code when I
> wasn't looking.  The original DaVinci NAND support
> used the hardware ECC logic for 1-bit and 4-bit ECC.
>
> - Dave

Yeap you're right sorry.

Regards,

-- 
Christophe Aeschlimann

Embedded Software Engineer

Advanced Communications Networks S.A.

Rue du Puits-Godet 8a
2000 Neuch?tel, Switzerland

T?l. +41 32 724 74 31

c.aeschlimann at acn-group.ch

From albertbu at gmail.com  Mon Aug 16 09:01:46 2010
From: albertbu at gmail.com (Albert Burbea)
Date: Mon, 16 Aug 2010 17:01:46 +0300
Subject: IPIPE issue in DM365
In-Reply-To: <4C691E37.30301@einfochips.com>
References: <4C68F454.6010700@einfochips.com>
	<AANLkTi=H7JbER954UHYb89fXHQL4MT6ueCTn6adN6b5m@mail.gmail.com>
	<4C691E37.30301@einfochips.com>
Message-ID: <AANLkTimD9tciJbwF+2VEcN6xj=J8dLgQhonsvT6_GeLj@mail.gmail.com>

Hi
i  do not have any sample like this. But it is trange you are getting kernle
panic
Are the offsets initialized? It could be that, because u used 0 (zero) as
your buffer index, the resizer did something, but now it is receiving stale
pointers.
Albert

On Mon, Aug 16, 2010 at 2:17 PM, hitesh <hitesh.patel at einfochips.com> wrote:

> Thanks  Albert for your prompt response..
>
> If my application want to allocate memory  and I want to pass that memory
> to IPIPE module then
> what should be the parameter?
> Do you have any sample application that only doing chroma conversion from
> 422 to 420 without resizing of width and height?
> My application getting kernel panic as below.
>
>
>
>
> Read from file done
> hResizerHandle 0x2f6c0,srcOffset 0x8ba3e000,destOffset 0x8b87c000
> Again in Hell1
> Again in Hell22
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> Resize operationpgd = c41f0000
>  completed succe[00000000] *pgd=8770f031ssfully.Write to, *pte=00000000
> file done
> cou, *ppte=00000000nt 13
> file read
>
> Read from fileInternal error: Oops: 817 [#1]
> Modules linked in: dm365mmap edmak irqk cmemk
> CPU: 0
> PC is at nfs_update_request+0x194/0x36c
> LR is at radix_tree_node_alloc+0x24/0x5c
> pc : [<c0120798>]    lr : [<c01d68dc>]    Not tainted
> sp : c41dbc70  ip : c057c960  fp : c41dbcb4
> r10: c40f8a10  r9 : c40f8918  r8 : 00000000
> r7 : c40f89f0  r6 : c44863a0  r5 : ffffffef  r4 : 00000000
> r3 : ffffffef  r2 : 00000001  r1 : c33e7ee8  r0 : ffffffef
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: 5317F
> Table: 841F0000  DAC: 00000015
> Process resizer_test (pid: 830, stack limit = 0xc41da258)
> Stack: (0xc41dbc70 to 0xc41dc000)
>
> -Hitesh
>
>
>
> On 08/16/2010 03:47 PM, Albert Burbea wrote:
>
>  Hi
> seems strange to me that you use
> convert.in_buff.index = 0;
> convert.out_buff1.index = 0;
> with the same index.
> In the dvsdk for DaVinci (2.1 to the best of my knowledge) you should use
> -1 for buffers that have not been allocated by the resizer itself.
> I hope this did not confuse you
> Albert
>
> On Mon, Aug 16, 2010 at 11:18 AM, hitesh <hitesh.patel at einfochips.com>wrote:
>
>>  Hi All,
>>
>> I am facing memory leak issue in Chroma Conversion module of  DM365 IPIPE.
>> When I run the ioctl(resizer_fd, RSZ_RESIZE, &convert) ioctl, It increase
>> my memory usage and it is gradually increasing it in
>> every call of of ioctl. Do you have any solution? I want to do chroma
>> conversion for encode my video with H264 encoder.
>>
>> My configuration for IPIPE is as below.
>>    INPUT_WIDTH =1280
>>    INPUT_HEIGHT =720
>>
>>         rsz_ss_config.input.image_width = INPUT_WIDTH;
>>        rsz_ss_config.input.image_height = INPUT_HEIGHT;
>>        rsz_ss_config.input.ppln = rsz_ss_config.input.image_width + 8;
>>        rsz_ss_config.input.lpfr = rsz_ss_config.input.image_height + 10;
>>        rsz_ss_config.input.pix_fmt = IPIPE_UYVY;
>>        rsz_ss_config.output1.pix_fmt = IPIPE_YUV420SP;
>>        rsz_ss_config.output1.enable = 1;
>>        rsz_ss_config.output1.width = INPUT_WIDTH;
>>        rsz_ss_config.output1.height = INPUT_HEIGHT;
>>        rsz_ss_config.output2.enable = 0;
>>
>>        rsz_chan_config.oper_mode = IMP_MODE_SINGLE_SHOT;
>>        rsz_chan_config.chain = 0;
>>
>>
>> I am calling ioctl as below.
>>
>>  convert.in_buff.buf_type = IMP_BUF_IN;
>>        convert.in_buff.index = 0;
>>        convert.in_buff.offset = buf_in[0].offset;
>>        convert.in_buff.size = buf_in[0].size;
>>        convert.out_buff1.buf_type = IMP_BUF_OUT1;
>>        convert.out_buff1.index = 0;
>>        convert.out_buff1.offset = buf_out1[0].offset;
>>        convert.out_buff1.size = buf_out1[0].size;
>>        if (ioctl(resizer_fd, RSZ_RESIZE, &convert) < 0) {
>>                perror("Error in doing preview\n");
>>                munmap(input_buffer, buf_in[0].size);
>>                munmap(output_buffer, buf_out1[0].size);
>>                close(resizer_fd);
>>                fclose(inp_f);
>>                fclose(outp_f);
>>                exit(1);
>>        }
>>
>>
>>
>> Thanks
>> Hitesh
>>
>>
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>
>
>
> --
> Albert Burbea
> Harishonim 8
> Ramat Gan 52502, Israel
> Tel/Fax + 972-3-7526016
> Mobile: +972-52-3541842
>
>
>   *Email Scanned for Virus & Dangerous Content by :* *
> www.CleanMailGateway.com <http://www.cleanmailgateway.com/>*
>
>
>


-- 
Albert Burbea
Harishonim 8
Ramat Gan 52502, Israel
Tel/Fax + 972-3-7526016
Mobile: +972-52-3541842
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100816/f425c7b3/attachment-0001.html>

From Juha.Kuikka at elektrobit.com  Mon Aug 16 15:05:09 2010
From: Juha.Kuikka at elektrobit.com (Juha.Kuikka at elektrobit.com)
Date: Mon, 16 Aug 2010 13:05:09 -0700
Subject: [PATCH 0/4] Add support for second MMCSD controller for DA-850
Message-ID: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7BE@usrdes03.ebgroup.elektrobit.com>

This small patch series adds the second MMCSD controller as a platform
device as well as the required resource definitions.

Tested on a custom board with a WiFi peripheral.

Sorry for the formatting in advance. Outlook is not very git-friendly.

Juha Kuikka (4):
  DA850: Add LPSC id for MMCSD1
  DA8xx: Add MMCSD1 base and device registration function
  DA850: Split MMCSD clock into two to support both MMCSD peripherals
  DA8xx: Add MMCSD1 resources, platform device and convenience
    registration function

 arch/arm/mach-davinci/da850.c              |   14 ++++++++--
 arch/arm/mach-davinci/devices-da8xx.c      |   36
++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    2 +
 arch/arm/mach-davinci/include/mach/psc.h   |    1 +
 4 files changed, 50 insertions(+), 3 deletions(-)
 mode change 100644 => 100755 arch/arm/mach-davinci/devices-da8xx.c
 mode change 100644 => 100755 arch/arm/mach-davinci/include/mach/da8xx.h

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.


From Juha.Kuikka at elektrobit.com  Mon Aug 16 15:06:29 2010
From: Juha.Kuikka at elektrobit.com (Juha.Kuikka at elektrobit.com)
Date: Mon, 16 Aug 2010 13:06:29 -0700
Subject: [PATCH 1/4] DA850: Add LPSC id for MMCSD1
Message-ID: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7BF@usrdes03.ebgroup.elektrobit.com>

Signed-off-by: Juha Kuikka <juha.kuikka at elektrobit.com>

diff --git a/arch/arm/mach-davinci/include/mach/psc.h
b/arch/arm/mach-davinci/include/mach/psc.h
index 983da6e..05118e7 100644
--- a/arch/arm/mach-davinci/include/mach/psc.h
+++ b/arch/arm/mach-davinci/include/mach/psc.h
@@ -172,6 +172,7 @@
 #define DA8XX_LPSC1_UART2              13
 #define DA8XX_LPSC1_LCDC               16
 #define DA8XX_LPSC1_PWM                        17
+#define DA8XX_LPSC1_MMC_SD1            18
 #define DA8XX_LPSC1_ECAP               20
 #define DA830_LPSC1_EQEP               21
 #define DA850_LPSC1_TPTC2              21
--
1.6.0.1

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.


From Juha.Kuikka at elektrobit.com  Mon Aug 16 15:06:34 2010
From: Juha.Kuikka at elektrobit.com (Juha.Kuikka at elektrobit.com)
Date: Mon, 16 Aug 2010 13:06:34 -0700
Subject: [PATCH 2/4] DA8xx: Add MMCSD1 base and device registration function
Message-ID: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7C0@usrdes03.ebgroup.elektrobit.com>

Signed-off-by: Juha Kuikka <juha.kuikka at elektrobit.com>

diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
b/arch/arm/mach-davinci/include/mach/da8xx.h
old mode 100644
new mode 100755
index 3c07059..fefa03d
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -58,6 +58,7 @@ extern void __iomem *da8xx_syscfg1_base;
 #define DA8XX_LCD_CNTRL_BASE   0x01e13000
 #define DA8XX_PLL1_BASE                0x01e1a000
 #define DA8XX_MMCSD0_BASE      0x01c40000
+#define DA8XX_MMCSD1_BASE      0x01e1b000
 #define DA8XX_AEMIF_CS2_BASE   0x60000000
 #define DA8XX_AEMIF_CS3_BASE   0x62000000
 #define DA8XX_AEMIF_CTL_BASE   0x68000000
@@ -76,6 +77,7 @@ int da8xx_register_usb11(struct da8xx_ohci_root_hub
*pdata);
 int da8xx_register_emac(void);
 int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
 int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
+int da8xx_register_mmcsd1(struct davinci_mmc_config *config);
 void __init da8xx_register_mcasp(int id, struct snd_platform_data
*pdata);
 int da8xx_register_rtc(void);
 int da850_register_cpufreq(void);
--
1.6.0.1

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.


From Juha.Kuikka at elektrobit.com  Mon Aug 16 15:06:40 2010
From: Juha.Kuikka at elektrobit.com (Juha.Kuikka at elektrobit.com)
Date: Mon, 16 Aug 2010 13:06:40 -0700
Subject: [PATCH 3/4] DA850: Split MMCSD clock into two to support both MMCSD
	peripherals
Message-ID: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7C1@usrdes03.ebgroup.elektrobit.com>

Signed-off-by: Juha Kuikka <juha.kuikka at elektrobit.com>

diff --git a/arch/arm/mach-davinci/da850.c
b/arch/arm/mach-davinci/da850.c
index 68ed58a..36407e2 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -323,12 +323,19 @@ static struct clk lcdc_clk = {
        .gpsc           = 1,
 };

-static struct clk mmcsd_clk = {
-       .name           = "mmcsd",
+static struct clk mmcsd0_clk = {
+       .name           = "mmcsd0",
        .parent         = &pll0_sysclk2,
        .lpsc           = DA8XX_LPSC0_MMC_SD,
 };

+static struct clk mmcsd1_clk = {
+       .name           = "mmcsd1",
+       .parent         = &pll0_sysclk2,
+       .lpsc           = DA8XX_LPSC1_MMC_SD1,
+       .gpsc           = 1,
+};
+
 static struct clk aemif_clk = {
        .name           = "aemif",
        .parent         = &pll0_sysclk3,
@@ -375,7 +382,8 @@ static struct clk_lookup da850_clks[] = {
        CLK("davinci_emac.1",   NULL,           &emac_clk),
        CLK("davinci-mcasp.0",  NULL,           &mcasp_clk),
        CLK("da8xx_lcdc.0",     NULL,           &lcdc_clk),
-       CLK("davinci_mmc.0",    NULL,           &mmcsd_clk),
+       CLK("davinci_mmc.0",    NULL,           &mmcsd0_clk),
+       CLK("davinci_mmc.1",    NULL,           &mmcsd1_clk),
        CLK(NULL,               "aemif",        &aemif_clk),
        CLK(NULL,               NULL,           NULL),
 };
--
1.6.0.1

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.


From Juha.Kuikka at elektrobit.com  Mon Aug 16 15:06:46 2010
From: Juha.Kuikka at elektrobit.com (Juha.Kuikka at elektrobit.com)
Date: Mon, 16 Aug 2010 13:06:46 -0700
Subject: [PATCH 4/4] DA8xx: Add MMCSD1 resources,
	platform device and convenience registration function
Message-ID: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7C2@usrdes03.ebgroup.elektrobit.com>

Signed-off-by: Juha Kuikka <juha.kuikka at elektrobit.com>

diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
old mode 100644
new mode 100755
index 52bc7b1..9e1a8be
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -566,6 +566,42 @@ int __init da8xx_register_mmcsd0(struct
davinci_mmc_config *config)
        return platform_device_register(&da8xx_mmcsd0_device);
 }

+static struct resource da8xx_mmcsd1_resources[] = {
+       {               /* registers */
+               .start  = DA8XX_MMCSD1_BASE,
+               .end    = DA8XX_MMCSD1_BASE + SZ_4K - 1,
+               .flags  = IORESOURCE_MEM,
+       },
+       {               /* interrupt */
+               .start  = IRQ_DA850_MMCSDINT0_1,
+               .end    = IRQ_DA850_MMCSDINT0_1,
+               .flags  = IORESOURCE_IRQ,
+       },
+       {               /* DMA RX */
+               .start  = EDMA_CTLR_CHAN(1, 28),
+               .end    = EDMA_CTLR_CHAN(1, 28),
+               .flags  = IORESOURCE_DMA,
+       },
+       {               /* DMA TX */
+               .start  = EDMA_CTLR_CHAN(1, 29),
+               .end    = EDMA_CTLR_CHAN(1, 29),
+               .flags  = IORESOURCE_DMA,
+       },
+};
+
+static struct platform_device da8xx_mmcsd1_device = {
+       .name           = "davinci_mmc",
+       .id             = 1,
+       .num_resources  = ARRAY_SIZE(da8xx_mmcsd1_resources),
+       .resource       = da8xx_mmcsd1_resources,
+};
+
+int __init da8xx_register_mmcsd1(struct davinci_mmc_config *config)
+{
+       da8xx_mmcsd1_device.dev.platform_data = config;
+       return platform_device_register(&da8xx_mmcsd1_device);
+}
+
 static struct resource da8xx_rtc_resources[] = {
        {
                .start          = DA8XX_RTC_BASE,
--
1.6.0.1

Juha Kuikka
Senior Software Engineer, Mobile Device Solutions




----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.


From johnny at tpsee.com  Mon Aug 16 22:44:50 2010
From: johnny at tpsee.com (johnny)
Date: Tue, 17 Aug 2010 11:44:50 +0800
Subject: dm365 h264dec buf usage problem
Message-ID: <201008171144488089544@tpsee.com>

problem of h264dec:

the version of h264dec is 2.0.0.5.

in source code vdec2.c in dmai:

Int Vdec2_process(Vdec2_Handle hVd, Buffer_Handle hInBuf,
                  Buffer_Handle hDstBuf)
{
    VIDDEC2_InArgs          inArgs;
    VIDDEC2_OutArgs         outArgs;
    XDM1_BufDesc            inBufDesc;
    XDM_BufDesc             outBufDesc;
    XDAS_Int32              outBufSizeArray[XDM_MAX_IO_BUFFERS];
    XDAS_Int8              *outBufPtrArray[XDM_MAX_IO_BUFFERS];
    XDAS_Int32              status;
    Int                     bufIdx;
    BufferGfx_Dimensions    dim;
    XDAS_Int8              *inPtr, *dstPtr;
    Int                     ret = Dmai_EOK;
    UInt32                  offset;
    UInt32                  bpp;
    assert(hVd);
    assert(hInBuf);
    assert(hDstBuf);
    assert(Buffer_getUserPtr(hInBuf));
    assert(Buffer_getUserPtr(hDstBuf));
    assert(Buffer_getNumBytesUsed(hInBuf));
    assert(Buffer_getSize(hDstBuf));
    assert(Buffer_getType(hDstBuf) == Buffer_Type_GRAPHICS);
    bpp = ColorSpace_getBpp(BufferGfx_getColorSpace(hDstBuf));

    BufferGfx_getDimensions(hDstBuf, &dim);
    offset = (dim.y * dim.lineLength) + (dim.x * (bpp >> 3));
    assert(offset < Buffer_getSize(hDstBuf));
    inPtr  = Buffer_getUserPtr(hInBuf);
    dstPtr = Buffer_getUserPtr(hDstBuf) + offset;
    if (BufferGfx_getColorSpace(hDstBuf) == ColorSpace_YUV420PSEMI) {
        outBufPtrArray[0]       = dstPtr;
        outBufSizeArray[0]      = hVd->minOutBufSize[0];
        outBufPtrArray[1]       = dstPtr + Buffer_getSize(hDstBuf) * 2 / 3;
        outBufSizeArray[1]      = hVd->minOutBufSize[1];
    }
    else if (BufferGfx_getColorSpace(hDstBuf) == ColorSpace_UYVY) {
        outBufPtrArray[0]       = dstPtr;
        outBufSizeArray[0]      = hVd->minOutBufSize[0];
    }
    else {
        Dmai_err0("Unsupported color format of destination buffer\n");
        return Dmai_EINVAL;
    }
    outBufDesc.numBufs          = hVd->minNumOutBufs;
    outBufDesc.bufSizes         = outBufSizeArray;
    outBufDesc.bufs             = outBufPtrArray;
    /* One buffer with encoded data */
    inBufDesc.numBufs           = 1;
    inBufDesc.descs[0].buf      = inPtr;
    inBufDesc.descs[0].bufSize  = Buffer_getNumBytesUsed(hInBuf);
    inArgs.size                 = sizeof(VIDDEC2_InArgs);
    inArgs.numBytes             = Buffer_getNumBytesUsed(hInBuf);
    inArgs.inputID              = GETID(Buffer_getId(hDstBuf));
    outArgs.size                = sizeof(VIDDEC2_OutArgs);
    /* Decode video buffer */
    status = VIDDEC2_process(hVd->hDecode, &inBufDesc, &outBufDesc, &inArgs,
                             &outArgs);
    Buffer_setNumBytesUsed(hInBuf, outArgs.bytesConsumed);
    Dmai_dbg4("VIDDEC2_process() ret %d inId %d inUse %d consumed %d\n",
              status, Buffer_getId(hDstBuf), outArgs.outBufsInUseFlag,
              outArgs.bytesConsumed);
    if (status != VIDDEC2_EOK) {
        if (XDM_ISFATALERROR(outArgs.decodedBufs.extendedError)) {
            Dmai_err2("VIDDEC2_process() failed with error (%d ext: 0x%x)\n",
                      (Int)status, (Uns) outArgs.decodedBufs.extendedError);
            return Dmai_EFAIL;
        }
        else {
            Dmai_dbg1("VIDDEC2_process() non-fatal error 0x%x\n",
                      (Uns) outArgs.decodedBufs.extendedError);
            ret = Dmai_EBITERROR;
        }
    }
    /* Prepare buffers for display */
    for (bufIdx = 0;
         bufIdx < IVIDDEC2_MAX_IO_BUFFERS && outArgs.outputID[bufIdx] > 0;
         bufIdx++) {
        hVd->hDisplayBufs[bufIdx] =
            BufTab_getBuf(hVd->hOutBufTab, GETIDX(outArgs.outputID[bufIdx]));
        dim.width = outArgs.displayBufs[bufIdx].frameWidth;
        dim.height = outArgs.displayBufs[bufIdx].frameHeight;
        dim.lineLength = outArgs.displayBufs[bufIdx].framePitch;
        /* Is there an offset to where we are supposed to start displaying? */
        offset = outArgs.displayBufs[bufIdx].bufDesc[0].buf -
                 Buffer_getUserPtr(hVd->hDisplayBufs[bufIdx]);
        dim.y = offset / dim.lineLength;
        dim.x = offset - ((dim.y * dim.lineLength) >> (bpp >> 4));
#ifdef Dmai_Device_dm365
        if (BufferGfx_getColorSpace(hDstBuf) == ColorSpace_YUV420PSEMI) {
            
            BufferGfx_Dimensions    cbcrDim;
            Int8                   *pSrc, *pDst;
            
            offset = dim.y * dim.lineLength / 2 + (dim.x * (bpp >> 3)); 
            pSrc   = (Int8 *) outArgs.displayBufs[bufIdx].bufDesc[1].buf;
            pDst   = Buffer_getUserPtr(hVd->hDisplayBufs[bufIdx]) + offset 
                     + (Buffer_getSize(hVd->hDisplayBufs[bufIdx]) * 2 / 3);
            
            if(pSrc != pDst) {
                /* Move the CbCr plane to its right place */
                printf("Move the CbCr plane to its right place\n");
                cbcrDim = dim;
                cbcrDim.height = cbcrDim.height / 2;
                _Framecopy_accel_move(hVd->hFc, &cbcrDim, pSrc, pDst);
            }
        }
#endif
        Buffer_setNumBytesUsed(hVd->hDisplayBufs[bufIdx],
                               Vdec2_getOutBufSize(hVd));
        BufferGfx_setFrameType(hVd->hDisplayBufs[bufIdx],
                               outArgs.displayBufs[bufIdx].frameType);
        if (BufferGfx_setDimensions(hVd->hDisplayBufs[bufIdx], &dim) < 0) {
            Dmai_err0("Frame does not fit in allocated buffer\n");
            return Dmai_EFAIL;
        }
    }
    /* Null terminate the list of display buffers */
    if (bufIdx < IVIDDEC2_MAX_IO_BUFFERS) {
        hVd->hDisplayBufs[bufIdx] = NULL;
    }
    hVd->displayBufIdx = 0;


????????????????????????????????????????????????????????????????????????
prblem here:
sometimes entries of outArgs.outputID[] are all zero, that means no decoded output.

If this happened, the hDstBuf will never be released, and all the buffers will be used utill there are no free buffers, and the display and decode thread will be blocked.

     question:
why did this happen? one encoded buffer input should make one decoded buffer output, isn't it ?

I have tried to free this hDstBuf manually, it works, the decode and display buffer will not be blocked,
 but the decoded video has some problem, some ruled color dots will appear in the image.

I do like this:

if(bufIndex == 0)
{
Buffer_freeUseMask(hDstBuf, 3);  //0x01 for display, 0x02 for decode
}


    /* Prepare buffers to be freed */
    for (bufIdx = 0;
         bufIdx < IVIDDEC2_MAX_IO_BUFFERS && outArgs.freeBufID[bufIdx] > 0;
         bufIdx++) {
        hVd->hFreeBufs[bufIdx] =
            BufTab_getBuf(hVd->hOutBufTab, GETIDX(outArgs.freeBufID[bufIdx]));
    }
    /* Null terminate the list of free buffers */
    if (bufIdx < IVIDDEC2_MAX_IO_BUFFERS) {
        hVd->hFreeBufs[bufIdx] = NULL;
    }
    hVd->freeBufIdx = 0;
    /* Was this just the first field of an interlaced frame? */
    if (outArgs.outBufsInUseFlag) {
        ret = Dmai_EFIRSTFIELD;
    }
    return ret;
}







2010-08-17 



johnny 

2010-08-17 



johnny 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/55f08ad3/attachment-0001.html>

From nsekhar at ti.com  Tue Aug 17 00:09:16 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 17 Aug 2010 10:39:16 +0530
Subject: [PATCH 0/4] Add support for second MMCSD controller for DA-850
In-Reply-To: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7BE@usrdes03.ebgroup.elektrobit.com>
References: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7BE@usrdes03.ebgroup.elektrobit.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E81E8F96@dbde02.ent.ti.com>

Hi Juha,

On Tue, Aug 17, 2010 at 01:35:09, Juha.Kuikka at elektrobit.com wrote:
> This small patch series adds the second MMCSD controller as a platform
> device as well as the required resource definitions.

Thanks! I remember some EDMA changes were discussed on the list for MMCSD1
support. Are those resolved upstream?

>
> Tested on a custom board with a WiFi peripheral.
>
> Sorry for the formatting in advance. Outlook is not very git-friendly.

No need to use outlook to send patches. Use git-send-email.

Regards,
Sekhar


From nsekhar at ti.com  Tue Aug 17 00:18:38 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 17 Aug 2010 10:48:38 +0530
Subject: [PATCH 1/4] DA850: Add LPSC id for MMCSD1
In-Reply-To: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7BF@usrdes03.ebgroup.elektrobit.com>
References: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7BF@usrdes03.ebgroup.elektrobit.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E81E8FA8@dbde02.ent.ti.com>

On Tue, Aug 17, 2010 at 01:36:29, Juha.Kuikka at elektrobit.com wrote:
> Signed-off-by: Juha Kuikka <juha.kuikka at elektrobit.com>
>
> diff --git a/arch/arm/mach-davinci/include/mach/psc.h
> b/arch/arm/mach-davinci/include/mach/psc.h
> index 983da6e..05118e7 100644
> --- a/arch/arm/mach-davinci/include/mach/psc.h
> +++ b/arch/arm/mach-davinci/include/mach/psc.h
> @@ -172,6 +172,7 @@
>  #define DA8XX_LPSC1_UART2              13
>  #define DA8XX_LPSC1_LCDC               16
>  #define DA8XX_LPSC1_PWM                        17
> +#define DA8XX_LPSC1_MMC_SD1            18

Since MMC/SD1 is present only on DA850 and not on
DA830, this define should rather be DA850_LPSC1_MMC_SD1
to be consistent with what is being done for other
such modules.

Thanks,
Sekhar


From nsekhar at ti.com  Tue Aug 17 00:28:45 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 17 Aug 2010 10:58:45 +0530
Subject: [PATCH 2/4] DA8xx: Add MMCSD1 base and device registration
	function
In-Reply-To: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7C0@usrdes03.ebgroup.elektrobit.com>
References: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7C0@usrdes03.ebgroup.elektrobit.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E81E8FBD@dbde02.ent.ti.com>

On Tue, Aug 17, 2010 at 01:36:34, Juha.Kuikka at elektrobit.com wrote:
> Signed-off-by: Juha Kuikka <juha.kuikka at elektrobit.com>
>
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
> b/arch/arm/mach-davinci/include/mach/da8xx.h
> old mode 100644
> new mode 100755
> index 3c07059..fefa03d
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -58,6 +58,7 @@ extern void __iomem *da8xx_syscfg1_base;
>  #define DA8XX_LCD_CNTRL_BASE   0x01e13000
>  #define DA8XX_PLL1_BASE                0x01e1a000
>  #define DA8XX_MMCSD0_BASE      0x01c40000
> +#define DA8XX_MMCSD1_BASE      0x01e1b000

Since this define is only going to be used in
devices-da8xx.c, it should be kept in that file
itself. MMC/SD0 is not following this and probably
needs fixing. Also, similar to the LPSC comment,
the define should be DA850_MMCSD1_BASE.

>  #define DA8XX_AEMIF_CS2_BASE   0x60000000
>  #define DA8XX_AEMIF_CS3_BASE   0x62000000
>  #define DA8XX_AEMIF_CTL_BASE   0x68000000
> @@ -76,6 +77,7 @@ int da8xx_register_usb11(struct da8xx_ohci_root_hub
> *pdata);
>  int da8xx_register_emac(void);
>  int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
>  int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
> +int da8xx_register_mmcsd1(struct davinci_mmc_config *config);

This should be part of patch 4/4

Thanks,
Sekhar


From sshtylyov at mvista.com  Tue Aug 17 04:43:22 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 17 Aug 2010 13:43:22 +0400
Subject: [PATCH 4/4] DA8xx: Add MMCSD1 resources, platform device and
	convenience registration function
In-Reply-To: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7C2@usrdes03.ebgroup.elektrobit.com>
References: <C681C76E0D5F1E4BB01DE79E0A80EEC70287E7C2@usrdes03.ebgroup.elektrobit.com>
Message-ID: <4C6A59BA.9000907@mvista.com>

Hello.

Juha.Kuikka at elektrobit.com wrote:

> Signed-off-by: Juha Kuikka <juha.kuikka at elektrobit.com>

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
> b/arch/arm/mach-davinci/devices-da8xx.c
> old mode 100644
> new mode 100755

    Don't change the mode of the file please. You're making it executable for 
no reason.

> index 52bc7b1..9e1a8be
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -566,6 +566,42 @@ int __init da8xx_register_mmcsd0(struct
> davinci_mmc_config *config)

    Your patch is line-wrapped.

> ----------------------------------------------------------------
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.

    Could you get rid of this trailer?

WBR, Sergei


From luna.id at gmail.com  Tue Aug 17 09:15:32 2010
From: luna.id at gmail.com (Nicolas Luna)
Date: Tue, 17 Aug 2010 10:15:32 -0400
Subject: Boot time
In-Reply-To: <201007311210.53529.caglarakyuz@gmail.com>
References: <AANLkTinu7xrdhPwbqYWK_OL8WJmkZA2jBPZnxFnajyvM@mail.gmail.com>
	<817859.2735.qm@web24102.mail.ird.yahoo.com>
	<AANLkTi=0C0QM-u1yEzGUsREQT0n063nOabz_p35xZWRD@mail.gmail.com>
	<201007311210.53529.caglarakyuz@gmail.com>
Message-ID: <AANLkTin_JmMaPGN4GGu8idrbDO6C+dFkuY+Jc7_MX4E_@mail.gmail.com>

Caglar,

I tried to use static linking, it reduced the boot time but not enough. Is
it possible to have a look at the code that you ported from linux kernel to
u-boot/UBL ?

Thank you.

Regards,

Nicolas



On Sat, Jul 31, 2010 at 5:10 AM, Caglar Akyuz <caglarakyuz at gmail.com> wrote:

> On Friday 30 July 2010 11:47:14 pm Nicolas Luna wrote:
> > Hi,
> >
> > Thanks guys for your advices, I applied few of them and I save a lot of
> > time, I'm at 3.9 seconds now. I'll also apply the deferred init calls
> >  concept later.
> >
> > I have two other questions.
> >
> > I'm not sure to understand how to use EDMA to copy from NOR to RAM in
> >  uboot. Every post that I found it is never explain the procedure to
> apply
> >  this patch.
>
> Where is this patch?
>
> >  Do you guys have a piece of code or something to get started
> >  with that?
> >
>
> I ported edma code from Linux kernel to u-boot(and ubl as well), then I
> changed memcpy with edma copy function under u-boot where kernel is copied
> from flash to ram, and later for the relocation in ram. That's all.
>
> > In the same way, after the kernel boot, I have to start an application
> with
> > QT and it takes 10 seconds to transfert QT lib (libQtCore, libQtGui,
> > libQtNetwork, fonts) from NOR to RAM and start the application. QT stuff
> is
> > ~20MB, I removed every useless lib to reduce the amount of data to
> > transfert. I also optimised the EMIFA CS2 (I changed EMIFA clock to 150
> Mhz
> > and changed CS timing to be at the maximum of my NOR). I probed the NOR
> >  chip select and there are big delays between read access. I suppose that
> >  is because it is not using EDMA and the CPU is not able to feed the
> NOR...
> >  I would like to reduce this transfert time to ~4 secondes or less and I
> >  think that EDMA could maybe help to do it. Do you have any idea how to
> >  apply it, or any other ideas?
> >
>
> I think optimizing link time is more important than optimizing transfer
> time.
> You can use static linking but then your application needs to be GPL. So I
> don't think using static linking is an option. In that case you may use
> prelinking feature of gnu linker [1].
>
> [1] http://people.redhat.com/jakub/prelink.pdf
>
> Regards,
> Caglar
>
> > Thanks for your time.
> >
> > Regards,
> >
> > Nicolas
> >
> > On Thu, Jul 29, 2010 at 10:42 PM, rohan tabish
> <rohan_javed at yahoo.co.uk>wrote:
> > > set verify=n this will ignore checksum
> > >
> > > Regard's
> > > RT
> > >
> > > --- On *Thu, 29/7/10, Nicolas Luna <luna.id at gmail.com>* wrote:
> > >
> > >
> > > From: Nicolas Luna <luna.id at gmail.com>
> > > Subject: Boot time
> > > To: davinci-linux-open-source at linux.davincidsp.com
> > > Date: Thursday, 29 July, 2010, 0:59
> > >
> > >
> > > Hi guys,
> > >
> > > I'm trying to make by board boot as quick as possible. I did some
> > > optimisation with the "All This For 1 Second Boot" wiki and other
> > > website. I would like to reduce a little bit more the boot time and I
> > > wonder if you guys could give me some clues.
> > >
> > > I copied my boot log below. For sure I'll remove the uboot autoboot
> delay
> > > and probably build a new kernel with modules. I putted in bold part
> that
> > > I think it is possible to do more optimisation.
> > >
> > > 1- See bullet #3.
> > > 2- The verifying Checksum is about 400 msec is it possible to skip it?
> > > 3- It takes ~1 sec to start booting the kernel and there is a other ~1
> > > sec delay between the starting kernel and the beginning of the
> > > uncompressing. Why it's so long? Ok maybe there is the copy from NOR to
> > > RAM but it should not take more than few msec.
> > > 4- It takes ~1 sec to the kernel to free 120K memory... I got enought
> RAM
> > > is it possible to remove it?
> > >
> > > I got custom hardware based on OMAP-L138 with FS (jffs2) and compressed
> > > kernel in NOR Flash.
> > >
> > > Thanks a lot
> > >
> > > Nicolas
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > >------------
> > >
> > > 0.000 0.000: OMAP-L138 initialization passed!
> > > 0.000 0.000: Booting TI User Boot Loader
> > > 0.004 0.004:    UBL Version: 1.65
> > > 0.004 0.000:    UBL Flashtype: NOR
> > > 0.008 0.004: Starting NOR Copy...
> > > 0.008 0.000: CFI Query...passed.
> > > 0.012 0.004: NOR Initialization:
> > > 0.012 0.000:    Command Set: Intel
> > > 0.012 0.000:    Manufacturer: INTEL
> > > 0.016 0.004:    Size: 0x00000020 MB
> > > 0.020 0.004: Valid magicnum, 0x55424CBB, found..
> > > 0.184 0.164:    DONE
> > > 0.188 0.004: Jumping to entry point at 0xC1080000.
> > > 0.504 0.316:
> > > 1.548 1.044: Hit any key to stop autoboot:  0
> > > *2.372 0.824: ## Booting kernel from Legacy Image at c0007fc0 ...*
> > > 2.372 0.000:    Image Name:   Linux-2.6.34
> > > 2.380 0.008:    Image Type:   ARM Linux Kernel Image (uncompressed)
> > > 2.380 0.000:    Data Size:    1505956 Bytes =  1.4 MB
> > > 2.384 0.004:    Load Address: c0008000
> > > 2.388 0.004:    Entry Point:  c0008000
> > > *2.808 0.420:    Verifying Checksum ... OK*
> > > 2.808 0.000:    Loading Kernel Image ... OK
> > > 2.808 0.000: OK
> > > 2.808 0.000:
> > > *2.812 0.004: Starting kernel ...*
> > > *2.812 0.000:*
> > > *3.860 1.048: Uncompressing Linux... done, booting the kernel.*
> > > 4.264 0.404: Linux version 2.6.34 (id at idt-ubuntu-linux) (gcc version
> > > 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #89 PREEMPT Thu Jul 22 15:24:03
> > > EDT 2010 4.268 0.004: CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ),
> > > cr=00053177 4.272 0.004: CPU: VIVT data cache, VIVT instruction cache
> > > 4.276 0.004: Machine: DaVinci DA850/OMAP-L138 EVM
> > > 4.280 0.004: Memory policy: ECC disabled, Data cache writeback
> > > 4.284 0.004: DaVinci da850/omap-l138 variant 0x0
> > > 4.288 0.004: Built 1 zonelists in Zone order, mobility grouping on.
> > > Total pages: 32512
> > > 4.300 0.012: Kernel command line: lpj=747520 mem=128M
> > > console=ttyS2,115200n8 root=/dev/mtdblock2 rootfstype=jffs2 rw ip=off
> > > 4.304 0.004: PID hash table entries: 512 (order: -1, 2048 bytes)
> > > 4.308 0.004: Dentry cache hash table entries: 16384 (order: 4, 65536
> > > bytes) 4.316 0.008: Inode-cache hash table entries: 8192 (order: 3,
> 32768
> > > bytes) 4.316 0.000: Memory: 128MB = 128MB total
> > > 4.324 0.008: Memory: 126752k/126752k available, 4320k reserved, 0K
> > > highmem 4.324 0.000: Virtual kernel memory layout:
> > > 4.332 0.008:     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> > > 4.336 0.004:     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> > > 4.340 0.004:     DMA     : 0xff000000 - 0xffe00000   (  14 MB)
> > > 4.344 0.004:     vmalloc : 0xc8800000 - 0xfea00000   ( 866 MB)
> > > 4.348 0.004:     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
> > > 4.352 0.004:     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> > > 4.356 0.004:       .init : 0xc0008000 - 0xc0026000   ( 120 kB)
> > > 4.360 0.004:       .text : 0xc0026000 - 0xc02e8000   (2824 kB)
> > > 4.364 0.004:       .data : 0xc02e8000 - 0xc0307a60   ( 127 kB)
> > > 4.372 0.008: SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0,
> > > CPUs=1, Nodes=1
> > > 4.376 0.004: Hierarchical RCU implementation.
> > > 4.376 0.000: NR_IRQS:245
> > > 4.380 0.004: Console: colour dummy device 80x30
> > > 4.384 0.004: Calibrating delay loop (skipped) preset value.. 149.50
> > > BogoMIPS (lpj=747520)
> > > 4.388 0.004: Mount-cache hash table entries: 512
> > > 4.392 0.004: CPU: Testing write buffer coherency: ok
> > > 4.396 0.004: DaVinci: 144 gpio irqs
> > > 4.396 0.000: NET: Registered protocol family 16
> > > 4.400 0.004: bio: create slab <bio-0> at 0
> > > 4.404 0.004: SCSI subsystem initialized
> > > 4.408 0.004: usbcore: registered new interface driver usbfs
> > > 4.412 0.004: usbcore: registered new interface driver hub
> > > 4.416 0.004: usbcore: registered new device driver usb
> > > 4.416 0.000: Switching to clocksource timer0_1
> > > 4.420 0.004: musb_hdrc: version 6.0, pio, host, debug=0
> > > 4.424 0.004: Waiting for USB PHY clock good...
> > > 4.428 0.004: musb_hdrc musb_hdrc: MUSB HDRC host driver
> > > 4.432 0.004: musb_hdrc musb_hdrc: new USB bus registered, assigned bus
> > > number 1
> > > 4.436 0.004: hub 1-0:1.0: USB hub found
> > > 4.440 0.004: hub 1-0:1.0: 1 port detected
> > > 4.444 0.004: musb_hdrc musb_hdrc: USB Host mode controller at fee00000
> > > using PIO, IRQ 58
> > > 4.448 0.004: NET: Registered protocol family 2
> > > 4.456 0.008: IP route cache hash table entries: 1024 (order: 0, 4096
> > > bytes) 4.460 0.004: TCP established hash table entries: 4096 (order: 3,
> > > 32768 bytes)
> > > 4.464 0.004: TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> > > 4.468 0.004: TCP: Hash tables configured (established 4096 bind 4096)
> > > 4.472 0.004: TCP reno registered
> > > 4.476 0.004: UDP hash table entries: 256 (order: 0, 4096 bytes)
> > > 4.480 0.004: UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> > > 4.484 0.004: NET: Registered protocol family 1
> > > 4.488 0.004: RPC: Registered udp transport module.
> > > 4.492 0.004: RPC: Registered tcp transport module.
> > > 4.496 0.004: RPC: Registered tcp NFSv4.1 backchannel transport module.
> > > 4.500 0.004: JFFS2 version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
> > > 4.504 0.004: msgmni has been set to 247
> > > 4.508 0.004: io scheduler noop registered (default)
> > > 4.512 0.004: da8xx_lcdc da8xx_lcdc.0: GLCD: Found Sharp_LK043T1DG01
> panel
> > > 4.516 0.004: Console: switching to colour frame buffer device 60x34
> > > 4.520 0.004: Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
> > > 4.528 0.008: serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a
> 16550A
> > > 4.532 0.004: serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a
> 16550A
> > > 4.540 0.008: serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a
> 16550A
> > > 4.540 0.000: console [ttyS2] enabled
> > > 4.548 0.008: brd: module loaded
> > > 4.556 0.008: physmap platform flash device: 02000000 at 60000000
> > > 4.564 0.008: physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
> > > 4.568 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > 4.572 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > 4.576 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > 4.580 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > 4.584 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > 4.588 0.004: Using buffer write method
> > > 4.588 0.000: Using auto-unlock on power-up/resume
> > > 4.592 0.004: cfi_cmdset_0001: Erase suspend on write enabled
> > > 4.596 0.004: RedBoot partition parsing not available
> > > 4.600 0.004: Using physmap partition information
> > > 4.604 0.004: Creating 3 MTD partitions on "physmap-flash.0":
> > > 4.608 0.004: 0x000000000000-0x000000080000 : "bootloaders + env"
> > > 4.620 0.012: 0x000000080000-0x000000280000 : "kernel"
> > > 4.628 0.008: 0x000000280000-0x000002000000 : "filesystem"
> > > 4.636 0.008: physmap-flash.0: failed to claim resource 0
> > > 4.644 0.008: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron
> > > NAND 512MiB 3,3V 8-bit)
> > > 4.652 0.008: Creating 2 MTD partitions on "davinci_nand.1":
> > > 4.656 0.004: 0x000000000000-0x000001900000 : "data"
> > > 4.664 0.008: 0x000001900000-0x000020000000 : "else"
> > > 4.672 0.008: davinci_nand davinci_nand.1: controller rev. 2.5
> > > 4.680 0.008: spi_davinci spi_davinci.1: Controller at 0xfef0e000
> > > 4.692 0.012: tun: Universal TUN/TAP device driver, 1.6
> > > 4.696 0.004: tun: (C) 1999-2004 Max Krasnyansky
> > > <maxk at qualcomm.com<http://mc/compose?to=maxk at qualcomm.com>
> > >
> > > 4.704 0.008: ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> > > 4.708 0.004: ohci ohci.0: DA8xx OHCI
> > > 4.712 0.004: ohci ohci.0: new USB bus registered, assigned bus number 2
> > > 4.716 0.004: Waiting for USB PHY clock good...
> > > 4.720 0.004: ohci ohci.0: irq 59, io mem 0x01e25000
> > > 4.788 0.068: hub 2-0:1.0: USB hub found
> > > 4.788 0.000: hub 2-0:1.0: 1 port detected
> > > 4.796 0.008: Initializing USB Mass Storage driver...
> > > 4.804 0.008: usbcore: registered new interface driver usb-storage
> > > 4.804 0.000: USB Mass Storage support registered.
> > > 5.804 1.000: i2c_davinci i2c_davinci.1: controller timed out
> > > 5.808 0.004: i2c_davinci i2c_davinci.1: initiating i2c bus recovery
> > > 5.812 0.004: tps6507x-ts: probe of tps6507x-ts failed with error -110
> > > 5.820 0.008: omap_rtc omap_rtc: rtc core: registered omap_rtc as rtc0
> > > 5.824 0.004: omap_rtc: RTC power up reset detected
> > > 5.824 0.000: omap_rtc: already running
> > > 5.828 0.004: i2c /dev entries driver
> > > 5.832 0.004: TCP cubic registered
> > > 5.836 0.004: Clocks: disable unused i2c1
> > > 5.840 0.004: Clocks: disable unused emac
> > > 5.848 0.008: davinci_emac_probe: using random MAC addr:
> 72:93:72:ad:15:13
> > > 5.852 0.004: emac-mii: probed
> > > 5.860 0.008: omap_rtc omap_rtc: setting system clock to 2000-01-01
> > > 01:34:03 UTC (946690443)
> > > 6.136 0.276: VFS: Mounted root (jffs2 filesystem) on device 31:2.
> > > *6.140 0.004: Freeing init memory: 120K*
> > > *7.356 1.216: Mounting proc*
> > >
> > > -----Inline Attachment Follows-----
> > >
> > >
> > > _______________________________________________
> > > Davinci-linux-open-source mailing list
> > > Davinci-linux-open-source at linux.davincidsp.com<
> http://mc/compose?to=Davin
> > >ci-linux-open-source at linux.davincidsp.com>
> > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/0616f1a9/attachment-0001.html>

From luna.id at gmail.com  Tue Aug 17 09:33:20 2010
From: luna.id at gmail.com (Nicolas Luna)
Date: Tue, 17 Aug 2010 10:33:20 -0400
Subject: Boot time
In-Reply-To: <201008171731.11314.caglarakyuz@gmail.com>
References: <AANLkTinu7xrdhPwbqYWK_OL8WJmkZA2jBPZnxFnajyvM@mail.gmail.com>
	<201007311210.53529.caglarakyuz@gmail.com>
	<AANLkTin_JmMaPGN4GGu8idrbDO6C+dFkuY+Jc7_MX4E_@mail.gmail.com>
	<201008171731.11314.caglarakyuz@gmail.com>
Message-ID: <AANLkTi=yrXGL3x2WHzGMQzMoDoRaa95XyoxyPomTxmYK@mail.gmail.com>

Caglar,

Thank you, it's appreciated. I would be interested to receive u-boot level
changes as a patch.

Regards,

Nicolas



On Tue, Aug 17, 2010 at 10:31 AM, Caglar Akyuz <caglarakyuz at gmail.com>wrote:

> On Tuesday 17 August 2010 05:15:32 pm Nicolas Luna wrote:
> > Caglar,
> >
> > I tried to use static linking, it reduced the boot time but not enough.
> Is
> > it possible to have a look at the code that you ported from linux kernel
> to
> > u-boot/UBL ?
> >
>
> My local UBL git tree is attached. You can see both DMA and Linux booting
> related changes in history. I can provide u-boot level changes(for dma and
> some small optimizations) as a patch for u-boot as well.
>
> Regards,
> Caglar
>
>
> > Thank you.
> >
> > Regards,
> >
> > Nicolas
> >
> > On Sat, Jul 31, 2010 at 5:10 AM, Caglar Akyuz <caglarakyuz at gmail.com>
> wrote:
> > > On Friday 30 July 2010 11:47:14 pm Nicolas Luna wrote:
> > > > Hi,
> > > >
> > > > Thanks guys for your advices, I applied few of them and I save a lot
> of
> > > > time, I'm at 3.9 seconds now. I'll also apply the deferred init calls
> > > >  concept later.
> > > >
> > > > I have two other questions.
> > > >
> > > > I'm not sure to understand how to use EDMA to copy from NOR to RAM in
> > > >  uboot. Every post that I found it is never explain the procedure to
> > >
> > > apply
> > >
> > > >  this patch.
> > >
> > > Where is this patch?
> > >
> > > >  Do you guys have a piece of code or something to get started
> > > >  with that?
> > >
> > > I ported edma code from Linux kernel to u-boot(and ubl as well), then I
> > > changed memcpy with edma copy function under u-boot where kernel is
> > > copied from flash to ram, and later for the relocation in ram. That's
> > > all.
> > >
> > > > In the same way, after the kernel boot, I have to start an
> application
> > >
> > > with
> > >
> > > > QT and it takes 10 seconds to transfert QT lib (libQtCore, libQtGui,
> > > > libQtNetwork, fonts) from NOR to RAM and start the application. QT
> > > > stuff
> > >
> > > is
> > >
> > > > ~20MB, I removed every useless lib to reduce the amount of data to
> > > > transfert. I also optimised the EMIFA CS2 (I changed EMIFA clock to
> 150
> > >
> > > Mhz
> > >
> > > > and changed CS timing to be at the maximum of my NOR). I probed the
> NOR
> > > >  chip select and there are big delays between read access. I suppose
> > > > that is because it is not using EDMA and the CPU is not able to feed
> > > > the
> > >
> > > NOR...
> > >
> > > >  I would like to reduce this transfert time to ~4 secondes or less
> and
> > > > I think that EDMA could maybe help to do it. Do you have any idea how
> > > > to apply it, or any other ideas?
> > >
> > > I think optimizing link time is more important than optimizing transfer
> > > time.
> > > You can use static linking but then your application needs to be GPL.
> So
> > > I don't think using static linking is an option. In that case you may
> use
> > > prelinking feature of gnu linker [1].
> > >
> > > [1] http://people.redhat.com/jakub/prelink.pdf
> > >
> > > Regards,
> > > Caglar
> > >
> > > > Thanks for your time.
> > > >
> > > > Regards,
> > > >
> > > > Nicolas
> > > >
> > > > On Thu, Jul 29, 2010 at 10:42 PM, rohan tabish
> > >
> > > <rohan_javed at yahoo.co.uk>wrote:
> > > > > set verify=n this will ignore checksum
> > > > >
> > > > > Regard's
> > > > > RT
> > > > >
> > > > > --- On *Thu, 29/7/10, Nicolas Luna <luna.id at gmail.com>* wrote:
> > > > >
> > > > >
> > > > > From: Nicolas Luna <luna.id at gmail.com>
> > > > > Subject: Boot time
> > > > > To: davinci-linux-open-source at linux.davincidsp.com
> > > > > Date: Thursday, 29 July, 2010, 0:59
> > > > >
> > > > >
> > > > > Hi guys,
> > > > >
> > > > > I'm trying to make by board boot as quick as possible. I did some
> > > > > optimisation with the "All This For 1 Second Boot" wiki and other
> > > > > website. I would like to reduce a little bit more the boot time and
> I
> > > > > wonder if you guys could give me some clues.
> > > > >
> > > > > I copied my boot log below. For sure I'll remove the uboot autoboot
> > >
> > > delay
> > >
> > > > > and probably build a new kernel with modules. I putted in bold part
> > >
> > > that
> > >
> > > > > I think it is possible to do more optimisation.
> > > > >
> > > > > 1- See bullet #3.
> > > > > 2- The verifying Checksum is about 400 msec is it possible to skip
> > > > > it? 3- It takes ~1 sec to start booting the kernel and there is a
> > > > > other ~1 sec delay between the starting kernel and the beginning of
> > > > > the uncompressing. Why it's so long? Ok maybe there is the copy
> from
> > > > > NOR to RAM but it should not take more than few msec.
> > > > > 4- It takes ~1 sec to the kernel to free 120K memory... I got
> enought
> > >
> > > RAM
> > >
> > > > > is it possible to remove it?
> > > > >
> > > > > I got custom hardware based on OMAP-L138 with FS (jffs2) and
> > > > > compressed kernel in NOR Flash.
> > > > >
> > > > > Thanks a lot
> > > > >
> > > > > Nicolas
> > >
> > >
> -------------------------------------------------------------------------
> > >
> > > > >------------
> > > > >
> > > > > 0.000 0.000: OMAP-L138 initialization passed!
> > > > > 0.000 0.000: Booting TI User Boot Loader
> > > > > 0.004 0.004:    UBL Version: 1.65
> > > > > 0.004 0.000:    UBL Flashtype: NOR
> > > > > 0.008 0.004: Starting NOR Copy...
> > > > > 0.008 0.000: CFI Query...passed.
> > > > > 0.012 0.004: NOR Initialization:
> > > > > 0.012 0.000:    Command Set: Intel
> > > > > 0.012 0.000:    Manufacturer: INTEL
> > > > > 0.016 0.004:    Size: 0x00000020 MB
> > > > > 0.020 0.004: Valid magicnum, 0x55424CBB, found..
> > > > > 0.184 0.164:    DONE
> > > > > 0.188 0.004: Jumping to entry point at 0xC1080000.
> > > > > 0.504 0.316:
> > > > > 1.548 1.044: Hit any key to stop autoboot:  0
> > > > > *2.372 0.824: ## Booting kernel from Legacy Image at c0007fc0 ...*
> > > > > 2.372 0.000:    Image Name:   Linux-2.6.34
> > > > > 2.380 0.008:    Image Type:   ARM Linux Kernel Image (uncompressed)
> > > > > 2.380 0.000:    Data Size:    1505956 Bytes =  1.4 MB
> > > > > 2.384 0.004:    Load Address: c0008000
> > > > > 2.388 0.004:    Entry Point:  c0008000
> > > > > *2.808 0.420:    Verifying Checksum ... OK*
> > > > > 2.808 0.000:    Loading Kernel Image ... OK
> > > > > 2.808 0.000: OK
> > > > > 2.808 0.000:
> > > > > *2.812 0.004: Starting kernel ...*
> > > > > *2.812 0.000:*
> > > > > *3.860 1.048: Uncompressing Linux... done, booting the kernel.*
> > > > > 4.264 0.404: Linux version 2.6.34 (id at idt-ubuntu-linux) (gcc
> version
> > > > > 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #89 PREEMPT Thu Jul 22
> > > > > 15:24:03 EDT 2010 4.268 0.004: CPU: ARM926EJ-S [41069265] revision
> 5
> > > > > (ARMv5TEJ), cr=00053177 4.272 0.004: CPU: VIVT data cache, VIVT
> > > > > instruction cache 4.276 0.004: Machine: DaVinci DA850/OMAP-L138 EVM
> > > > > 4.280 0.004: Memory policy: ECC disabled, Data cache writeback
> > > > > 4.284 0.004: DaVinci da850/omap-l138 variant 0x0
> > > > > 4.288 0.004: Built 1 zonelists in Zone order, mobility grouping on.
> > > > > Total pages: 32512
> > > > > 4.300 0.012: Kernel command line: lpj=747520 mem=128M
> > > > > console=ttyS2,115200n8 root=/dev/mtdblock2 rootfstype=jffs2 rw
> ip=off
> > > > > 4.304 0.004: PID hash table entries: 512 (order: -1, 2048 bytes)
> > > > > 4.308 0.004: Dentry cache hash table entries: 16384 (order: 4,
> 65536
> > > > > bytes) 4.316 0.008: Inode-cache hash table entries: 8192 (order: 3,
> > >
> > > 32768
> > >
> > > > > bytes) 4.316 0.000: Memory: 128MB = 128MB total
> > > > > 4.324 0.008: Memory: 126752k/126752k available, 4320k reserved, 0K
> > > > > highmem 4.324 0.000: Virtual kernel memory layout:
> > > > > 4.332 0.008:     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> > > > > 4.336 0.004:     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> > > > > 4.340 0.004:     DMA     : 0xff000000 - 0xffe00000   (  14 MB)
> > > > > 4.344 0.004:     vmalloc : 0xc8800000 - 0xfea00000   ( 866 MB)
> > > > > 4.348 0.004:     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
> > > > > 4.352 0.004:     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> > > > > 4.356 0.004:       .init : 0xc0008000 - 0xc0026000   ( 120 kB)
> > > > > 4.360 0.004:       .text : 0xc0026000 - 0xc02e8000   (2824 kB)
> > > > > 4.364 0.004:       .data : 0xc02e8000 - 0xc0307a60   ( 127 kB)
> > > > > 4.372 0.008: SLUB: Genslabs=11, HWalign=32, Order=0-3,
> MinObjects=0,
> > > > > CPUs=1, Nodes=1
> > > > > 4.376 0.004: Hierarchical RCU implementation.
> > > > > 4.376 0.000: NR_IRQS:245
> > > > > 4.380 0.004: Console: colour dummy device 80x30
> > > > > 4.384 0.004: Calibrating delay loop (skipped) preset value.. 149.50
> > > > > BogoMIPS (lpj=747520)
> > > > > 4.388 0.004: Mount-cache hash table entries: 512
> > > > > 4.392 0.004: CPU: Testing write buffer coherency: ok
> > > > > 4.396 0.004: DaVinci: 144 gpio irqs
> > > > > 4.396 0.000: NET: Registered protocol family 16
> > > > > 4.400 0.004: bio: create slab <bio-0> at 0
> > > > > 4.404 0.004: SCSI subsystem initialized
> > > > > 4.408 0.004: usbcore: registered new interface driver usbfs
> > > > > 4.412 0.004: usbcore: registered new interface driver hub
> > > > > 4.416 0.004: usbcore: registered new device driver usb
> > > > > 4.416 0.000: Switching to clocksource timer0_1
> > > > > 4.420 0.004: musb_hdrc: version 6.0, pio, host, debug=0
> > > > > 4.424 0.004: Waiting for USB PHY clock good...
> > > > > 4.428 0.004: musb_hdrc musb_hdrc: MUSB HDRC host driver
> > > > > 4.432 0.004: musb_hdrc musb_hdrc: new USB bus registered, assigned
> > > > > bus number 1
> > > > > 4.436 0.004: hub 1-0:1.0: USB hub found
> > > > > 4.440 0.004: hub 1-0:1.0: 1 port detected
> > > > > 4.444 0.004: musb_hdrc musb_hdrc: USB Host mode controller at
> > > > > fee00000 using PIO, IRQ 58
> > > > > 4.448 0.004: NET: Registered protocol family 2
> > > > > 4.456 0.008: IP route cache hash table entries: 1024 (order: 0,
> 4096
> > > > > bytes) 4.460 0.004: TCP established hash table entries: 4096
> (order:
> > > > > 3, 32768 bytes)
> > > > > 4.464 0.004: TCP bind hash table entries: 4096 (order: 2, 16384
> > > > > bytes) 4.468 0.004: TCP: Hash tables configured (established 4096
> > > > > bind 4096) 4.472 0.004: TCP reno registered
> > > > > 4.476 0.004: UDP hash table entries: 256 (order: 0, 4096 bytes)
> > > > > 4.480 0.004: UDP-Lite hash table entries: 256 (order: 0, 4096
> bytes)
> > > > > 4.484 0.004: NET: Registered protocol family 1
> > > > > 4.488 0.004: RPC: Registered udp transport module.
> > > > > 4.492 0.004: RPC: Registered tcp transport module.
> > > > > 4.496 0.004: RPC: Registered tcp NFSv4.1 backchannel transport
> > > > > module. 4.500 0.004: JFFS2 version 2.2. (NAND) ?? 2001-2006 Red
> Hat,
> > > > > Inc. 4.504 0.004: msgmni has been set to 247
> > > > > 4.508 0.004: io scheduler noop registered (default)
> > > > > 4.512 0.004: da8xx_lcdc da8xx_lcdc.0: GLCD: Found Sharp_LK043T1DG01
> > >
> > > panel
> > >
> > > > > 4.516 0.004: Console: switching to colour frame buffer device 60x34
> > > > > 4.520 0.004: Serial: 8250/16550 driver, 3 ports, IRQ sharing
> disabled
> > > > > 4.528 0.008: serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a
> > >
> > > 16550A
> > >
> > > > > 4.532 0.004: serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a
> > >
> > > 16550A
> > >
> > > > > 4.540 0.008: serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a
> > >
> > > 16550A
> > >
> > > > > 4.540 0.000: console [ttyS2] enabled
> > > > > 4.548 0.008: brd: module loaded
> > > > > 4.556 0.008: physmap platform flash device: 02000000 at 60000000
> > > > > 4.564 0.008: physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit
> > > > > bank 4.568 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > > > 4.572 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > > > 4.576 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > > > 4.580 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > > > 4.584 0.004:  Intel/Sharp Extended Query Table at 0x010A
> > > > > 4.588 0.004: Using buffer write method
> > > > > 4.588 0.000: Using auto-unlock on power-up/resume
> > > > > 4.592 0.004: cfi_cmdset_0001: Erase suspend on write enabled
> > > > > 4.596 0.004: RedBoot partition parsing not available
> > > > > 4.600 0.004: Using physmap partition information
> > > > > 4.604 0.004: Creating 3 MTD partitions on "physmap-flash.0":
> > > > > 4.608 0.004: 0x000000000000-0x000000080000 : "bootloaders + env"
> > > > > 4.620 0.012: 0x000000080000-0x000000280000 : "kernel"
> > > > > 4.628 0.008: 0x000000280000-0x000002000000 : "filesystem"
> > > > > 4.636 0.008: physmap-flash.0: failed to claim resource 0
> > > > > 4.644 0.008: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc
> > > > > (Micron NAND 512MiB 3,3V 8-bit)
> > > > > 4.652 0.008: Creating 2 MTD partitions on "davinci_nand.1":
> > > > > 4.656 0.004: 0x000000000000-0x000001900000 : "data"
> > > > > 4.664 0.008: 0x000001900000-0x000020000000 : "else"
> > > > > 4.672 0.008: davinci_nand davinci_nand.1: controller rev. 2.5
> > > > > 4.680 0.008: spi_davinci spi_davinci.1: Controller at 0xfef0e000
> > > > > 4.692 0.012: tun: Universal TUN/TAP device driver, 1.6
> > > > > 4.696 0.004: tun: (C) 1999-2004 Max Krasnyansky
> > > > > <maxk at qualcomm.com<http://mc/compose?to=maxk at qualcomm.com>
> > > > >
> > > > > 4.704 0.008: ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> > > > > 4.708 0.004: ohci ohci.0: DA8xx OHCI
> > > > > 4.712 0.004: ohci ohci.0: new USB bus registered, assigned bus
> number
> > > > > 2 4.716 0.004: Waiting for USB PHY clock good...
> > > > > 4.720 0.004: ohci ohci.0: irq 59, io mem 0x01e25000
> > > > > 4.788 0.068: hub 2-0:1.0: USB hub found
> > > > > 4.788 0.000: hub 2-0:1.0: 1 port detected
> > > > > 4.796 0.008: Initializing USB Mass Storage driver...
> > > > > 4.804 0.008: usbcore: registered new interface driver usb-storage
> > > > > 4.804 0.000: USB Mass Storage support registered.
> > > > > 5.804 1.000: i2c_davinci i2c_davinci.1: controller timed out
> > > > > 5.808 0.004: i2c_davinci i2c_davinci.1: initiating i2c bus recovery
> > > > > 5.812 0.004: tps6507x-ts: probe of tps6507x-ts failed with error
> -110
> > > > > 5.820 0.008: omap_rtc omap_rtc: rtc core: registered omap_rtc as
> rtc0
> > > > > 5.824 0.004: omap_rtc: RTC power up reset detected
> > > > > 5.824 0.000: omap_rtc: already running
> > > > > 5.828 0.004: i2c /dev entries driver
> > > > > 5.832 0.004: TCP cubic registered
> > > > > 5.836 0.004: Clocks: disable unused i2c1
> > > > > 5.840 0.004: Clocks: disable unused emac
> > > > > 5.848 0.008: davinci_emac_probe: using random MAC addr:
> > >
> > > 72:93:72:ad:15:13
> > >
> > > > > 5.852 0.004: emac-mii: probed
> > > > > 5.860 0.008: omap_rtc omap_rtc: setting system clock to 2000-01-01
> > > > > 01:34:03 UTC (946690443)
> > > > > 6.136 0.276: VFS: Mounted root (jffs2 filesystem) on device 31:2.
> > > > > *6.140 0.004: Freeing init memory: 120K*
> > > > > *7.356 1.216: Mounting proc*
> > > > >
> > > > > -----Inline Attachment Follows-----
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Davinci-linux-open-source mailing list
> > > > > Davinci-linux-open-source at linux.davincidsp.com<
> > >
> > > http://mc/compose?to=Davin
> > >
> > > > >ci-linux-open-source at linux.davincidsp.com>
> > > > >
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-sourc
> > > > >e
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/e07b2919/attachment-0001.html>

From juha.kuikka at elektrobit.com  Tue Aug 17 13:56:48 2010
From: juha.kuikka at elektrobit.com (Juha Kuikka)
Date: Tue, 17 Aug 2010 11:56:48 -0700
Subject: [PATCH v2 3/3] DA850: Add MMCSD1 resources,
	platform device and convenience registration function
In-Reply-To: <1282071408-1213-3-git-send-email-juha.kuikka@elektrobit.com>
References: <1282071408-1213-1-git-send-email-juha.kuikka@elektrobit.com>
	<1282071408-1213-2-git-send-email-juha.kuikka@elektrobit.com>
	<1282071408-1213-3-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <1282071408-1213-4-git-send-email-juha.kuikka@elektrobit.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/7e16d5b8/attachment.pl>

From juha.kuikka at elektrobit.com  Tue Aug 17 13:56:47 2010
From: juha.kuikka at elektrobit.com (Juha Kuikka)
Date: Tue, 17 Aug 2010 11:56:47 -0700
Subject: [PATCH v2 2/3] DA850: Split MMCSD clock into two to support both
	MMCSD peripherals
In-Reply-To: <1282071408-1213-2-git-send-email-juha.kuikka@elektrobit.com>
References: <1282071408-1213-1-git-send-email-juha.kuikka@elektrobit.com>
	<1282071408-1213-2-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <1282071408-1213-3-git-send-email-juha.kuikka@elektrobit.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/ae9219c5/attachment.pl>

From juha.kuikka at elektrobit.com  Tue Aug 17 13:56:45 2010
From: juha.kuikka at elektrobit.com (Juha Kuikka)
Date: Tue, 17 Aug 2010 11:56:45 -0700
Subject: [PATCH v2 0/3] Add support for second MMCSD controller for DA-850
Message-ID: <1282071408-1213-1-git-send-email-juha.kuikka@elektrobit.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/753ab260/attachment.pl>

From juha.kuikka at elektrobit.com  Tue Aug 17 13:56:46 2010
From: juha.kuikka at elektrobit.com (Juha Kuikka)
Date: Tue, 17 Aug 2010 11:56:46 -0700
Subject: [PATCH v2 1/3] DA850: Add LPSC id for MMCSD1 peripheral
In-Reply-To: <1282071408-1213-1-git-send-email-juha.kuikka@elektrobit.com>
References: <1282071408-1213-1-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <1282071408-1213-2-git-send-email-juha.kuikka@elektrobit.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/3aed58e6/attachment.pl>

From rohan_javed at yahoo.co.uk  Wed Aug 18 03:29:29 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Wed, 18 Aug 2010 08:29:29 +0000 (GMT)
Subject: How to configure DDR2??
Message-ID: <90651.45456.qm@web24106.mail.ird.yahoo.com>

how to change the bus width of ddr2 in linux i changed it using u-boot by following

mm 0x20000008

and try to configure it for 16 bits but it everything gets halt anyone knows how to configure DDR2 for 16 bit

Regard's



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100818/132637b4/attachment.html>

From sshtylyov at mvista.com  Wed Aug 18 04:04:11 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 18 Aug 2010 13:04:11 +0400
Subject: [PATCH v2 3/3] DA850: Add MMCSD1 resources, platform device and
	convenience registration function
In-Reply-To: <1282071408-1213-4-git-send-email-juha.kuikka@elektrobit.com>
References: <1282071408-1213-1-git-send-email-juha.kuikka@elektrobit.com>	<1282071408-1213-2-git-send-email-juha.kuikka@elektrobit.com>	<1282071408-1213-3-git-send-email-juha.kuikka@elektrobit.com>
	<1282071408-1213-4-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <4C6BA20B.1090103@mvista.com>

Hello.

Juha Kuikka wrote:

> Signed-off-by: Juha Kuikka <juha.kuikka at elektrobit.com>

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index 52bc7b1..104f1ba 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -37,6 +37,7 @@
>  #define DA8XX_EMAC_MDIO_BASE		0x01e24000
>  #define DA8XX_GPIO_BASE			0x01e26000
>  #define DA8XX_I2C1_BASE			0x01e28000
> +#define DA850_MMCSD1_BASE		0x01e1b000

    It's preferable to keep this sorted...

> @@ -566,6 +567,42 @@ int __init da8xx_register_mmcsd0(struct davinci_mmc_config *config)
>  	return platform_device_register(&da8xx_mmcsd0_device);
>  }
>  
> +static struct resource da850_mmcsd1_resources[] = {
> +	{		/* registers */
> +		.start	= DA850_MMCSD1_BASE,
> +		.end	= DA850_MMCSD1_BASE + SZ_4K - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	{		/* interrupt */
> +		.start	= IRQ_DA850_MMCSDINT0_1,
> +		.end	= IRQ_DA850_MMCSDINT0_1,
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +	{		/* DMA RX */
> +		.start	= EDMA_CTLR_CHAN(1, 28),
> +		.end	= EDMA_CTLR_CHAN(1, 28),
> +		.flags	= IORESOURCE_DMA,
> +	},
> +	{		/* DMA TX */
> +		.start	= EDMA_CTLR_CHAN(1, 29),
> +		.end	= EDMA_CTLR_CHAN(1, 29),
> +		.flags	= IORESOURCE_DMA,
> +	},
> +};
> +
> +static struct platform_device da850_mmcsd1_device = {
> +	.name		= "davinci_mmc",
> +	.id		= 1,
> +	.num_resources	= ARRAY_SIZE(da850_mmcsd1_resources),
> +	.resource	= da850_mmcsd1_resources,
> +};
> +
> +int __init da850_register_mmcsd1(struct davinci_mmc_config *config)
> +{
> +	da850_mmcsd1_device.dev.platform_data = config;
> +	return platform_device_register(&da850_mmcsd1_device);
> +}
> +

    Could enclose this into #idfef CONFIG_DAVINCI_DA850...

WBR, Sergei


From rohan_javed at yahoo.co.uk  Wed Aug 18 06:43:06 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Wed, 18 Aug 2010 11:43:06 +0000 (GMT)
Subject: configuring RAM with 16bit?
Message-ID: <7289.55427.qm@web24106.mail.ird.yahoo.com>

How to boot linux using DDR2 with 16bit bus width i did the following modification at the u-boot prompt

mm 0x20000008

and changed to 0x00004611 and the board started doing BOOTME BOOTME so i want to know what is the best place to configure it do 16 bit wide bus 

Regard's



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100818/b1f90781/attachment-0001.html>

From aazamansari at gmail.com  Wed Aug 18 10:05:30 2010
From: aazamansari at gmail.com (Azam Ansari)
Date: Wed, 18 Aug 2010 08:05:30 -0700
Subject: Android2.2 on DM355
Message-ID: <AANLkTinjdMfdkkkPb2Th9JSB3LUqnG+9je1eSJCJQpoO@mail.gmail.com>

Hi,

has anyone ported Android2.2 on DM355?
Can anyone give me directions.


azam.

-- 
Happiness keeps you Sweet, Trials keep you Strong, Sorrows keep you Human,
Failures keep you humble , Success keeps You Glowing, but Only God
keeps You Going!

From khasim at ti.com  Wed Aug 18 10:22:39 2010
From: khasim at ti.com (Syed Mohammed, Khasim)
Date: Wed, 18 Aug 2010 20:52:39 +0530
Subject: Android2.2 on DM355
In-Reply-To: <AANLkTinjdMfdkkkPb2Th9JSB3LUqnG+9je1eSJCJQpoO@mail.gmail.com>
References: <AANLkTinjdMfdkkkPb2Th9JSB3LUqnG+9je1eSJCJQpoO@mail.gmail.com>
Message-ID: <0680EC522D0CC943BC586913CF3768C003B39A32D7@dbde02.ent.ti.com>



> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-
> linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Azam Ansari
> Sent: Wednesday, August 18, 2010 8:36 PM
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: Android2.2 on DM355
> 
> Hi,
> 
> has anyone ported Android2.2 on DM355?
> Can anyone give me directions.
> 
No, we don't have a Android port on DM355, there were some efforts from SpectraCore and others to get Android on D355 not sure if they progressed any further.

Given the DM355 architecture, we feel Android is not a best fit for this kind of processor. Basically Android needs SGX (Hardware accelerated OpenGL), more memory, more mips. The best fit for Android will be Cortex A8 processors, like OMAP35x, AM35x, AM37x, DM37x, etc.

There is a port on OMAP L 138 (ARM9) on Hawkboard from CoreDruids, you can try this on DM355.

Regards,
Khasim

> 
> azam.
> 
> --
> Happiness keeps you Sweet, Trials keep you Strong, Sorrows keep you Human,
> Failures keep you humble , Success keeps You Glowing, but Only God
> keeps You Going!
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From rohan_javed at yahoo.co.uk  Thu Aug 19 00:00:29 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Thu, 19 Aug 2010 05:00:29 +0000 (GMT)
Subject: Booting linux for DDR2 with 16bit bus width
Message-ID: <892360.98154.qm@web24105.mail.ird.yahoo.com>

what is the place to configure linux with 16bit bus width? Is it UBL U-boot or kernel???

We have a design in which we only want to use 128MB of RAM that is only 16bit bus width?

Regard's




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100819/74d7a62a/attachment.html>

From rohan_javed at yahoo.co.uk  Thu Aug 19 03:26:07 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Thu, 19 Aug 2010 08:26:07 +0000 (GMT)
Subject: steps to compile UBL?
Message-ID: <721693.15727.qm@web24105.mail.ird.yahoo.com>

I have dwonload UBL source from sourceforge but compiling it gives errors any one knows what are the steps to compile 

Regard's



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100819/74658c1c/attachment.html>

From rohan_javed at yahoo.co.uk  Thu Aug 19 03:35:06 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Thu, 19 Aug 2010 08:35:06 +0000 (GMT)
Subject: steps to compile UBL?
Message-ID: <172916.78661.qm@web24104.mail.ird.yahoo.com>

I have dwonload UBL source from sourceforge but compiling it gives errors any one knows what are the steps to compile 

Regard's



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100819/d20d896a/attachment.html>

From khilman at deeprootsystems.com  Thu Aug 19 13:29:27 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 19 Aug 2010 11:29:27 -0700
Subject: [PATCH 3/3] davinci: Map sram using MT_MEMORY_NONCACHED instead
	of MT_DEVICE
In-Reply-To: <1281262702-27732-1-git-send-email-santosh.shilimkar@ti.com>
References: <1281262702-27732-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <AANLkTi=9k19RUmfnNBO8AfFj_LtyNtsPPVYC_=-AW5yE@mail.gmail.com>

On Sun, Aug 8, 2010 at 3:18 AM, Santosh Shilimkar
<santosh.shilimkar at ti.com> wrote:
> On Davinci SRAM is mapped as MT_DEVICE becasue of the section
> mapping pre-requisite instead of intended MT_MEMORY_NONCACHED
>
> Since the section mapping limitation gets fixed with first
> patch in this series, the MT_MEMORY_NONCACHED can be used now.
>
> Have not tested this, so somebody with Davinci hardware can
> try this out
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: Kevin Hilman <khilman at deeprootsystems.com>

Acked-by: Kevin Hilman <khilman at deeprootsystems.com>

> ---
> ?arch/arm/mach-davinci/dm355.c ?| ? ?3 +--
> ?arch/arm/mach-davinci/dm365.c ?| ? ?3 +--
> ?arch/arm/mach-davinci/dm644x.c | ? ?3 +--
> ?arch/arm/mach-davinci/dm646x.c | ? ?3 +--
> ?4 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index 3834781..e7bd2ad 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -767,8 +767,7 @@ static struct map_desc dm355_io_desc[] = {
> ? ? ? ? ? ? ? ?.virtual ? ? ? ?= SRAM_VIRT,
> ? ? ? ? ? ? ? ?.pfn ? ? ? ? ? ?= __phys_to_pfn(0x00010000),
> ? ? ? ? ? ? ? ?.length ? ? ? ? = SZ_32K,
> - ? ? ? ? ? ? ? /* MT_MEMORY_NONCACHED requires supersection alignment */
> - ? ? ? ? ? ? ? .type ? ? ? ? ? = MT_DEVICE,
> + ? ? ? ? ? ? ? .type ? ? ? ? ? = MT_MEMORY_NONCACHED,
> ? ? ? ?},
> ?};
>
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index a146849..5dee032 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -967,8 +967,7 @@ static struct map_desc dm365_io_desc[] = {
> ? ? ? ? ? ? ? ?.virtual ? ? ? ?= SRAM_VIRT,
> ? ? ? ? ? ? ? ?.pfn ? ? ? ? ? ?= __phys_to_pfn(0x00010000),
> ? ? ? ? ? ? ? ?.length ? ? ? ? = SZ_32K,
> - ? ? ? ? ? ? ? /* MT_MEMORY_NONCACHED requires supersection alignment */
> - ? ? ? ? ? ? ? .type ? ? ? ? ? = MT_DEVICE,
> + ? ? ? ? ? ? ? .type ? ? ? ? ? = MT_MEMORY_NONCACHED,
> ? ? ? ?},
> ?};
>
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index 7ad1520..5112d51 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -651,8 +651,7 @@ static struct map_desc dm644x_io_desc[] = {
> ? ? ? ? ? ? ? ?.virtual ? ? ? ?= SRAM_VIRT,
> ? ? ? ? ? ? ? ?.pfn ? ? ? ? ? ?= __phys_to_pfn(0x00008000),
> ? ? ? ? ? ? ? ?.length ? ? ? ? = SZ_16K,
> - ? ? ? ? ? ? ? /* MT_MEMORY_NONCACHED requires supersection alignment */
> - ? ? ? ? ? ? ? .type ? ? ? ? ? = MT_DEVICE,
> + ? ? ? ? ? ? ? .type ? ? ? ? ? = MT_MEMORY_NONCACHED,
> ? ? ? ?},
> ?};
>
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index 9404565..97078f4 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -735,8 +735,7 @@ static struct map_desc dm646x_io_desc[] = {
> ? ? ? ? ? ? ? ?.virtual ? ? ? ?= SRAM_VIRT,
> ? ? ? ? ? ? ? ?.pfn ? ? ? ? ? ?= __phys_to_pfn(0x00010000),
> ? ? ? ? ? ? ? ?.length ? ? ? ? = SZ_32K,
> - ? ? ? ? ? ? ? /* MT_MEMORY_NONCACHED requires supersection alignment */
> - ? ? ? ? ? ? ? .type ? ? ? ? ? = MT_DEVICE,
> + ? ? ? ? ? ? ? .type ? ? ? ? ? = MT_MEMORY_NONCACHED,
> ? ? ? ?},
> ?};
>
> --
> 1.6.0.4
>
>

From chris-meng at ti.com  Thu Aug 19 20:10:36 2010
From: chris-meng at ti.com (Meng, Chris)
Date: Fri, 20 Aug 2010 09:10:36 +0800
Subject: steps to compile UBL?
In-Reply-To: <mailman.1.1282237201.7984.davinci-linux-open-source@linux.davincidsp.com>
References: <mailman.1.1282237201.7984.davinci-linux-open-source@linux.davincidsp.com>
Message-ID: <CD86D59BDF1BF442B77237F2BB27793C21503B64@dqhe04.ent.ti.com>


Rohan,

If you meet problem when building ubl in ccs3.3, pls check http://processors.wiki.ti.com/index.php/How_to_update_CCS_ARM_cgtools_to_build_the_DM365_ubl_in_CCS_3.3.

Chris

From harry_cat at 163.com  Fri Aug 20 02:58:47 2010
From: harry_cat at 163.com (harry_cat)
Date: Fri, 20 Aug 2010 15:58:47 +0800
Subject: Demo of DM6467T
Message-ID: <201008201558453283601@163.com>

     I have buy the platform of DM6467T, now I want to build the application of 720P video encoder and decoder. But I can only get the demo software about the platform of DM6467,  can this kind of demo software  be used for DM6467T without modification?
     Thanks a lot.


2010-08-20 



wei jun zou 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100820/7b1de8e9/attachment.html>

From caglarakyuz at gmail.com  Fri Aug 20 06:06:33 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Fri, 20 Aug 2010 14:06:33 +0300
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A13@dbde02.ent.ti.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A13@dbde02.ent.ti.com>
Message-ID: <201008201406.33473.caglarakyuz@gmail.com>

On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
> Hi Brian,
> 
> On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
> > Grant -
> >
> >
> >  For my part, I've already sunk way more time into this than I ever
> > intended, and I really have no clue how to break this patch down into
> > smaller patches.  I don't really care much if the patch gets accepted
> > or not - I am just trying to help out all of the other users that are
> > stuck with a broken driver like I was.  Maybe if TI wants to give
> > their customers a driver that actually works they'll pick it up and do
> > the rest of the work that's necessary to get it accepted.
> 
> Thanks for all the work on this so far. We will work on breaking
> this patch up and getting the fixes accepted upstream.
> 

Is there any improvement on this or anybody is actively working on submitting 
patches?

I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different 
peripherals. If nobody is expected to submit something soon, then I can work 
on preparing incremental patches while working with the driver. I can start 
sending patches next week or so.

Best Regards,
Caglar

> Regards,
> Sekhar
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

From todd.fischer at ridgerun.com  Fri Aug 20 09:46:35 2010
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Fri, 20 Aug 2010 08:46:35 -0600
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <201008201406.33473.caglarakyuz@gmail.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A13@dbde02.ent.ti.com>
	<201008201406.33473.caglarakyuz@gmail.com>
Message-ID: <1282315595.1215.2043.camel@sax-lx>

On Fri, 2010-08-20 at 14:06 +0300, Caglar Akyuz wrote:

> On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
> > Hi Brian,
> > 
> > On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
> > > Grant -
> > >
> > >
> > >  For my part, I've already sunk way more time into this than I ever
> > > intended, and I really have no clue how to break this patch down into
> > > smaller patches.  I don't really care much if the patch gets accepted
> > > or not - I am just trying to help out all of the other users that are
> > > stuck with a broken driver like I was.  Maybe if TI wants to give
> > > their customers a driver that actually works they'll pick it up and do
> > > the rest of the work that's necessary to get it accepted.
> > 
> > Thanks for all the work on this so far. We will work on breaking
> > this patch up and getting the fixes accepted upstream.
> > 
> 
> Is there any improvement on this or anybody is actively working on submitting 
> patches?
> 
> I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different 
> peripherals. If nobody is expected to submit something soon, then I can work 
> on preparing incremental patches while working with the driver. I can start 
> sending patches next week or so.



Caglar,

I will be using Brian's driver on DM365.  I will let you know if I
encounter any issues.

Todd


> Best Regards,
> Caglar
> 
> > Regards,
> > Sekhar
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source at linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> > 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100820/596b6a5f/attachment.html>

From grant.likely at secretlab.ca  Fri Aug 20 12:19:12 2010
From: grant.likely at secretlab.ca (Grant Likely)
Date: Fri, 20 Aug 2010 11:19:12 -0600
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <201008201406.33473.caglarakyuz@gmail.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A13@dbde02.ent.ti.com>
	<201008201406.33473.caglarakyuz@gmail.com>
Message-ID: <AANLkTi=YuaPSeQrKbzvMgdux-u5H_puA-p-iqCYjbwPp@mail.gmail.com>

On Fri, Aug 20, 2010 at 5:06 AM, Caglar Akyuz <caglarakyuz at gmail.com> wrote:
> On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
>> Hi Brian,
>>
>> On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
>> > Grant -
>> >
>> >
>> > ?For my part, I've already sunk way more time into this than I ever
>> > intended, and I really have no clue how to break this patch down into
>> > smaller patches. ?I don't really care much if the patch gets accepted
>> > or not - I am just trying to help out all of the other users that are
>> > stuck with a broken driver like I was. ?Maybe if TI wants to give
>> > their customers a driver that actually works they'll pick it up and do
>> > the rest of the work that's necessary to get it accepted.
>>
>> Thanks for all the work on this so far. We will work on breaking
>> this patch up and getting the fixes accepted upstream.
>>
>
> Is there any improvement on this or anybody is actively working on submitting
> patches?
>
> I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different
> peripherals. If nobody is expected to submit something soon, then I can work
> on preparing incremental patches while working with the driver. I can start
> sending patches next week or so.
>
> Best Regards,
> Caglar

Thanks Caglar for picking up this work.  I look forward to seeing the
patches.  Let me know if you need any help with getting them in shape
for merging.

g.

From nsekhar at ti.com  Sun Aug 22 23:28:48 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 23 Aug 2010 09:58:48 +0530
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <201008201406.33473.caglarakyuz@gmail.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A13@dbde02.ent.ti.com>
	<201008201406.33473.caglarakyuz@gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E8350B45@dbde02.ent.ti.com>

Hi Caglar,

On Fri, Aug 20, 2010 at 16:36:33, Caglar Akyuz wrote:
> On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
> > Hi Brian,
> >
> > On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
> > > Grant -
> > >
> > >
> > >  For my part, I've already sunk way more time into this than I ever
> > > intended, and I really have no clue how to break this patch down into
> > > smaller patches.  I don't really care much if the patch gets accepted
> > > or not - I am just trying to help out all of the other users that are
> > > stuck with a broken driver like I was.  Maybe if TI wants to give
> > > their customers a driver that actually works they'll pick it up and do
> > > the rest of the work that's necessary to get it accepted.
> >
> > Thanks for all the work on this so far. We will work on breaking
> > this patch up and getting the fixes accepted upstream.
> >
>
> Is there any improvement on this or anybody is actively working on submitting
> patches?
>
> I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different
> peripherals. If nobody is expected to submit something soon, then I can work
> on preparing incremental patches while working with the driver. I can start
> sending patches next week or so.

I have been spending time on this (admittedly on and off) since I wrote that
email and have broken down the work into ~20 patches so far. Starting to
scratch the DMA related changes right now. So, I guess I am somewhere midway.

I pushed a branch containing the work so far here:

http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

This isn't tested or submit-worthy yet. I was hoping to break down the
complete work, test it and get reviewed by Brian. Also, the final work
may differ from Brian's work slightly as I did some improvements while
I was the fat patch breaking down.

The breakdown wasn't mechanical because Brian's improvements are very
intertwined and if I just simply 'selected hunks' it wouldn't make for
a very reviewable patch series.

Have you also been parallely working on this? If not, I hope you can start
from what I have already completed. I will continue to work on it anyway.
This way hopefully the patch series should be ready sooner.

Thanks,
Sekhar


From grant.likely at secretlab.ca  Sun Aug 22 23:40:56 2010
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sun, 22 Aug 2010 22:40:56 -0600
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E8350B45@dbde02.ent.ti.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<AANLkTim-FB6YrGSTmDQhmnS+Qw-dGm7D-pH7iCzy0-Td@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E7ED0A13@dbde02.ent.ti.com>
	<201008201406.33473.caglarakyuz@gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E8350B45@dbde02.ent.ti.com>
Message-ID: <062ea2aa-f41b-4320-bbcc-57300da08fb0@email.android.com>



"Nori, Sekhar" <nsekhar at ti.com> wrote:

>Hi Caglar,
>
>On Fri, Aug 20, 2010 at 16:36:33, Caglar Akyuz wrote:
>> On Monday 02 August 2010 06:53:16 pm Nori, Sekhar wrote:
>> > Hi Brian,
>> >
>> > On Mon, Aug 02, 2010 at 19:40:29, Brian Niebuhr wrote:
>> > > Grant -
>> > >
>> > >
>> > >  For my part, I've already sunk way more time into this than I ever
>> > > intended, and I really have no clue how to break this patch down into
>> > > smaller patches.  I don't really care much if the patch gets accepted
>> > > or not - I am just trying to help out all of the other users that are
>> > > stuck with a broken driver like I was.  Maybe if TI wants to give
>> > > their customers a driver that actually works they'll pick it up and do
>> > > the rest of the work that's necessary to get it accepted.
>> >
>> > Thanks for all the work on this so far. We will work on breaking
>> > this patch up and getting the fixes accepted upstream.
>> >
>>
>> Is there any improvement on this or anybody is actively working on submitting
>> patches?
>>
>> I'm going to try this driver on DaVinci DM6446 and OMAP L-138 with different
>> peripherals. If nobody is expected to submit something soon, then I can work
>> on preparing incremental patches while working with the driver. I can start
>> sending patches next week or so.
>
>I have been spending time on this (admittedly on and off) since I wrote that
>email and have broken down the work into ~20 patches so far. Starting to
>scratch the DMA related changes right now. So, I guess I am somewhere midway.
>
>I pushed a branch containing the work so far here:
>
>http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

I like what I see so far.  Feel free to post subsets of the whole series as soon as you feel they are ready so I can start adding bits to my next-door branch.

g.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From huangsw at temobi.com  Mon Aug 23 01:38:00 2010
From: huangsw at temobi.com (huangsw)
Date: Mon, 23 Aug 2010 14:38:00 +0800
Subject: Is there a USB 802.11n wifi card which suit DM6446?
Message-ID: <201008231437389687392@temobi.com>

Hello everybody, i want to select a 802.11n  usb wifi card to connect to my dm6446 board, can you give me some advices on chip types and drivers?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100823/086f2c15/attachment.html>

From swami.iyer at ti.com  Mon Aug 23 03:49:26 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Mon, 23 Aug 2010 14:19:26 +0530
Subject: Is there a USB 802.11n wifi card which suit DM6446?
In-Reply-To: <201008231437389687392@temobi.com>
References: <201008231437389687392@temobi.com>
Message-ID: <FCCFB4CDC6E5564B9182F639FC3560870303E76554@dbde02.ent.ti.com>

Zydas 1211b chipset - (now) Atheros chipset, from edimax and other vendors.
________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of huangsw [huangsw at temobi.com]
Sent: Monday, August 23, 2010 12:08 PM
To: davinci-linux-open-source
Subject: Is there a USB 802.11n wifi card which suit DM6446?

Hello everybody, i want to select a 802.11n  usb wifi card to connect to my dm6446 board, can you give me some advices on chip types and drivers?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100823/335dfcbd/attachment.html>

From caglarakyuz at gmail.com  Mon Aug 23 03:54:10 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Mon, 23 Aug 2010 11:54:10 +0300
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E8350B45@dbde02.ent.ti.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<201008201406.33473.caglarakyuz@gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E8350B45@dbde02.ent.ti.com>
Message-ID: <201008231154.10411.caglarakyuz@gmail.com>

On Monday 23 August 2010 07:28:48 am Nori, Sekhar wrote:
> Hi Caglar,
> 

Hi,

[...]

> I have been spending time on this (admittedly on and off) since I wrote
>  that email and have broken down the work into ~20 patches so far. Starting
>  to scratch the DMA related changes right now. So, I guess I am somewhere
>  midway.
> 
> I pushed a branch containing the work so far here:
> 
> http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=ref
> s/heads/davinci-spi-rewrite
> 

This is great.

> This isn't tested or submit-worthy yet. I was hoping to break down the
> complete work, test it and get reviewed by Brian. Also, the final work
> may differ from Brian's work slightly as I did some improvements while
> I was the fat patch breaking down.
> 
> The breakdown wasn't mechanical because Brian's improvements are very
> intertwined and if I just simply 'selected hunks' it wouldn't make for
> a very reviewable patch series.
> 

I was hoping to reach to an exact copy of Brian's version since that version 
is tested by Brian and some others. but if you say so...
  
> Have you also been parallely working on this? If not, I hope you can start
> from what I have already completed. I will continue to work on it anyway.
> This way hopefully the patch series should be ready sooner.
> 

I'll start this week working on this, so your patches are perfect for me. I 
don't want to interrupt your working process, I'll follow your tree closely 
for your in-coming changes.

Regards,
Caglar

> Thanks,
> Sekhar
> 

From nsekhar at ti.com  Mon Aug 23 04:30:22 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 23 Aug 2010 15:00:22 +0530
Subject: [PATCH v5 1/1] davinci: spi: replace existing driver
In-Reply-To: <201008231154.10411.caglarakyuz@gmail.com>
References: <1280355490-11878-1-git-send-email-bniebuhr@efjohnson.com>
	<201008201406.33473.caglarakyuz@gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301E8350B45@dbde02.ent.ti.com>
	<201008231154.10411.caglarakyuz@gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E8350E47@dbde02.ent.ti.com>

On Mon, Aug 23, 2010 at 14:24:10, Caglar Akyuz wrote:
> On Monday 23 August 2010 07:28:48 am Nori, Sekhar wrote:
> > Hi Caglar,
> >
>
> Hi,
>
> [...]
>
> > I have been spending time on this (admittedly on and off) since I wrote
> >  that email and have broken down the work into ~20 patches so far. Starting
> >  to scratch the DMA related changes right now. So, I guess I am somewhere
> >  midway.
> >
> > I pushed a branch containing the work so far here:
> >
> > http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=ref
> > s/heads/davinci-spi-rewrite
> >
>
> This is great.
>
> > This isn't tested or submit-worthy yet. I was hoping to break down the
> > complete work, test it and get reviewed by Brian. Also, the final work
> > may differ from Brian's work slightly as I did some improvements while
> > I was the fat patch breaking down.
> >
> > The breakdown wasn't mechanical because Brian's improvements are very
> > intertwined and if I just simply 'selected hunks' it wouldn't make for
> > a very reviewable patch series.
> >
>
> I was hoping to reach to an exact copy of Brian's version since that version
> is tested by Brian and some others. but if you say so...

Yeah, that was my initial goal too. Anyway, at the end of it we can review
the delta separately and make sure the changes are worth making and don't
actually break functionality.

Thanks,
Sekhar


From hebert.marcandre at gmail.com  Mon Aug 23 10:37:22 2010
From: hebert.marcandre at gmail.com (=?ISO-8859-1?Q?Marc=2DAndr=E9_H=E9bert?=)
Date: Mon, 23 Aug 2010 11:37:22 -0400
Subject: Problem booting with a omapl138 sdram board
Message-ID: <AANLkTimQ2+wJiz6p-hNn4BpowT14m+Nz3tOzzG4-tLfz@mail.gmail.com>

Hi,

I'm working on 2 different OMAPLl138 boards. The first is stuffed with
32MB of mDDR and the second with 16MB of SDRAM. My mDDR board is
booting fine but I am having problems with my SDRAM board. To add
support for a SDRAM board I added a ARCH_DAVINCI_DA8XX_BASE_DDR or
ARCH_DAVINCI_DA8XX_BASE_SDRAM config to arch/arm/mach-davinci/Kconfig
and modified arch/arm/mach-davinci/include/mach/memory.h as such:
#define DA8XX_SDRAM_BASE    0x40000000

#elif defined(CONFIG_ARCH_DAVINCI_DA8XX)

#if defined(CONFIG_ARCH_DAVINCI_DA8XX_BASE_DDR)
#define PHYS_OFFSET DA8XX_DDR_BASE
#else
#define PHYS_OFFSET DA8XX_SDRAM_BASE
#endif

#else

The kernel starts but stalls when initializing the SPI1 controller (my
u-boot is able to use the flash on SPI1just fine). After some checking
it seems accessing the SPI1 registers is the problem, sort of like
accessing an address not mapped with the MMU. To verify this, I added
different debugging traces to my board_init to see if execution would
halt:

printk( "GPIO: %x\n", __raw_readl(IO_ADDRESS(0x01E26000))); //OK
printk( "EDMA3 TC2: %x\n", __raw_readl(IO_ADDRESS(0x01E38000))); //OK
printk( "eHRPWM0: %x\n", __raw_readl(IO_ADDRESS(0x01F00000))); //Stalls
printk( "SPI1: %x\n", __raw_readl(IO_ADDRESS(0x01F0E000))); //Stalls

I don't see how my change to the PHYS_OFFSET would affect this, but
this is the only change I can think of that might affect this.
Any leads or suggestions would be appreciated.

Marc

From Jon.Povey at racelogic.co.uk  Tue Aug 24 01:04:29 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Tue, 24 Aug 2010 07:04:29 +0100
Subject: SDIO WIFI for DM355? [Hijacked, was: Is there a USB 802.11n wifi
	card which suit DM6446?]
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC3560870303E76554@dbde02.ent.ti.com>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0903E02546@Cloud.RL.local>

Subbrathnam, Swaminathan wrote:
> Zydas 1211b chipset - (now) Atheros chipset, from edimax and other
> vendors.

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network
________________________________

A related question; anyone care to recommend an SDIO WIFI card for use with DM355?

Thanks,

--
Jon Povey
jon.povey at racelogic.co.uk


From swami.iyer at ti.com  Tue Aug 24 01:06:33 2010
From: swami.iyer at ti.com (Subbrathnam, Swaminathan)
Date: Tue, 24 Aug 2010 11:36:33 +0530
Subject: SDIO WIFI for DM355? [Hijacked, was: Is there a USB 802.11n
	wifi card which suit DM6446?]
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0903E02546@Cloud.RL.local>
References: <FCCFB4CDC6E5564B9182F639FC3560870303E76554@dbde02.ent.ti.com>,
	<70E876B0EA86DD4BAF101844BC814DFE0903E02546@Cloud.RL.local>
Message-ID: <FCCFB4CDC6E5564B9182F639FC3560870303E76569@dbde02.ent.ti.com>

Solutions from Marvel were used by customers earlier.

________________________________________
From: Jon Povey [Jon.Povey at racelogic.co.uk]
Sent: Tuesday, August 24, 2010 11:34 AM
To: Subbrathnam, Swaminathan; huangsw; davinci-linux-open-source
Subject: SDIO WIFI for DM355? [Hijacked, was: Is there a USB 802.11n wifi card which suit DM6446?]

Subbrathnam, Swaminathan wrote:
> Zydas 1211b chipset - (now) Atheros chipset, from edimax and other
> vendors.

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network
________________________________

A related question; anyone care to recommend an SDIO WIFI card for use with DM355?

Thanks,

--
Jon Povey
jon.povey at racelogic.co.uk

From nsekhar at ti.com  Tue Aug 24 01:54:28 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 24 Aug 2010 12:24:28 +0530
Subject: SDIO WIFI for DM355? [Hijacked, was: Is there a USB 802.11n
	wifi	card which suit DM6446?]
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0903E02546@Cloud.RL.local>
References: <FCCFB4CDC6E5564B9182F639FC3560870303E76554@dbde02.ent.ti.com>
	<70E876B0EA86DD4BAF101844BC814DFE0903E02546@Cloud.RL.local>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E8351402@dbde02.ent.ti.com>

On Tue, Aug 24, 2010 at 11:34:29, Jon Povey wrote:
>
> A related question; anyone care to recommend an SDIO WIFI card for use with DM355?

There are some part numbers that are mentioned here:

http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17678.html

Thanks,
Sekhar

From nsekhar at ti.com  Tue Aug 24 02:00:22 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 24 Aug 2010 12:30:22 +0530
Subject: Problem booting with a omapl138 sdram board
In-Reply-To: <AANLkTimQ2+wJiz6p-hNn4BpowT14m+Nz3tOzzG4-tLfz@mail.gmail.com>
References: <AANLkTimQ2+wJiz6p-hNn4BpowT14m+Nz3tOzzG4-tLfz@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301E835140D@dbde02.ent.ti.com>

Hi Marc-Andr?,

On Mon, Aug 23, 2010 at 21:07:22, Marc-Andr? H?bert wrote:
> Hi,
>
> I'm working on 2 different OMAPLl138 boards. The first is stuffed with
> 32MB of mDDR and the second with 16MB of SDRAM. My mDDR board is
> booting fine but I am having problems with my SDRAM board. To add
> support for a SDRAM board I added a ARCH_DAVINCI_DA8XX_BASE_DDR or
> ARCH_DAVINCI_DA8XX_BASE_SDRAM config to arch/arm/mach-davinci/Kconfig
> and modified arch/arm/mach-davinci/include/mach/memory.h as such:
> #define DA8XX_SDRAM_BASE    0x40000000
>
> #elif defined(CONFIG_ARCH_DAVINCI_DA8XX)
>
> #if defined(CONFIG_ARCH_DAVINCI_DA8XX_BASE_DDR)
> #define PHYS_OFFSET DA8XX_DDR_BASE
> #else
> #define PHYS_OFFSET DA8XX_SDRAM_BASE
> #endif
>
> #else
>
> The kernel starts but stalls when initializing the SPI1 controller (my
> u-boot is able to use the flash on SPI1just fine). After some checking
> it seems accessing the SPI1 registers is the problem, sort of like
> accessing an address not mapped with the MMU. To verify this, I added
> different debugging traces to my board_init to see if execution would
> halt:
>
> printk( "GPIO: %x\n", __raw_readl(IO_ADDRESS(0x01E26000))); //OK
> printk( "EDMA3 TC2: %x\n", __raw_readl(IO_ADDRESS(0x01E38000))); //OK
> printk( "eHRPWM0: %x\n", __raw_readl(IO_ADDRESS(0x01F00000))); //Stalls
> printk( "SPI1: %x\n", __raw_readl(IO_ADDRESS(0x01F0E000))); //Stalls

The module clocks aren't enabled until the drivers load,
so board int would be too early for access. Typically only
drivers need to access the module registers.

It is strange that PHYS_OFFSET change is causing a change in
behavior. But the above needs to be fixed anyway.

Thanks,
Sekhar


From ozanyusufoglu at hotmail.com  Tue Aug 24 02:38:04 2010
From: ozanyusufoglu at hotmail.com (=?ISO-8859-9?Q?=D6zg=FCr_Ozan_Yusufo=F0lu?=)
Date: Tue, 24 Aug 2010 10:38:04 +0300
Subject: DM6446 Drivers
Message-ID: <BLU0-SMTP18427D9078C7C98DD588974A8830@phx.gbl>

Hi, I'm a novice embedded engineer who works in a IPTV STB project. We 
are using a DaVinci DM6446 based evaluation board for developing a 
firmware for our STB.  Unfortunetaly I am the only engineer who work in 
the software development side, and  don't have enough backround to deal 
with problems which I encountered.  Could you please enlighten me about 
these issues

1. I will use the open source Linux DaVinci kernel for development, and 
I didn't understand the driver side, in documents of TI its been said 
that LSP is integrated with Montavista kernel, is it still available to 
use LSP with open community Linux kernel? If it is,how can I do this?

2. Is there any pre-builded open source Linux kernel that all these 
drivers work completely within ?

3. It seems that the video-display  driver not functional  for Dm644x, 
in the http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel

4. What is the difference between LSP and PSP.  I couldn't find any 
document that gives detail about these issues . Could you give me any 
advice about where to start

From lamiaposta71 at gmail.com  Tue Aug 24 03:36:20 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Tue, 24 Aug 2010 10:36:20 +0200
Subject: [PATCH v4] DaVinci: dm365: Added clockout2 management.
In-Reply-To: <87k4o4suym.fsf@deeprootsystems.com>
References: <1281020128-5947-1-git-send-email-lamiaposta71@gmail.com>
	<87k4o4suym.fsf@deeprootsystems.com>
Message-ID: <AANLkTi=YN-0k1cFHsx+RBtOEPcSObKeHKD2BZd=tqYnn@mail.gmail.com>

2010/8/5 Kevin Hilman <khilman at deeprootsystems.com>

> Raffaele Recalcati <lamiaposta71 at gmail.com> writes:
>
> > From: Davide Bonfanti <davide.bonfanti at bticino.it>
> >
> >     Clockout2 is added as a child of pll1_sysclk9.
> >     A new dm365_clkout2_set_rate is used to set clockout2 frequency.
> >
> > Signed-off-by: Davide Bonfanti <davide.bonfanti at bticino.it>
> > Signed-off-by: Raffaele Recalcati <raffaele.recalcati at bticino.it>
> > ---
> > This patch has been developed against
> > http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
> > and has been tested for dm365 cpu on BMX board.
> > This patch depends on the following one submitted to the mailing list:
> > https://patchwork.kernel.org/patch/112994
> >
> > TODO LIST
> > -The clkout2 management needs a recalc function, but I by now I don't
> know how to
> > point to it from davinci_clk_init.
>
> Not sure I follow the problem here, but can't you use the .recalc field
> of 'struct clk'?  What am I missing?
>

I didn't know it, thx.
I've added the function now.


>
> > -The unmapping of system_module_base has to be checked.
>
> Looks like you're doing it in this version
>

ok,


>
> > -Solving a possible race when writing PERI_CLKCTL, see Nori Sekhar
> explanation:
> > "Looks like the same register supports setting clocks for voice codec
> > and keyscan module as well. This can cause a race if those clocks are
> > modified in a different context. Can you extend this function to cover
> > those clocks as well? May be clk->lpsc can be used to determine if div1,
> > div2 or div3 need to be changed. This way you can serialize the setting
> > up of these clocks."
>
> I agree with Sekhar. This needs to be addresed before this patch is
> mergable.
>

It is more difficult.
Something like the following?

int dm365_peri_clkctl_set_rate(struct clk *clk, unsigned long rate)
{
        int i;
        unsigned long input;
        unsigned ratio;
        unsigned regval;
        void __iomem *system_module_base;

        /* There must be a parent... */
        if (WARN_ON(!clk->parent))
                return -EINVAL;

        input = clk->parent->rate;

        if (input > rate)
                ratio = DIV_ROUND_UP(input, rate) - 1;

        system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
        regval = __raw_readl(system_module_base + PERI_CLKCTL);

        regval &= ~DIV1_MASK;
        regval |= ratio << 3;

        /* to make changes work stop CLOCKOUT & start it again */
        regval |= BIT(CLOCKOUT2EN);

       mutex_lock(&peri_clkctl_mutex);

        __raw_writel(regval, system_module_base + PERI_CLKCTL);
        regval &= ~(1 << CLOCKOUT2EN);
        __raw_writel(regval, system_module_base + PERI_CLKCTL);

       mutex_unlock(&peri_clkctl_mutex);

        iounmap(system_module_base);
        return 0;
}








>
> > A fine tuning of clkout2 is possible using the function below (it is
> > possible to do something similar with Nori Sekhar work about
> DIV_ROUND_CLOSEST()
> > in the davinci_set_sysclk_rate() function (max_rate has to be passed).
> >
> > static int clkout2_fine_setting(unsigned long rate)
> > {
> >         struct clk *pll1_sysclk9;
> >         struct clk *clkout2;
> >         int i, err, min_err, i_min_err;
> >         int ret = -EINVAL;
> >
> >         pll1_sysclk9 = clk_get(NULL, "pll1_sysclk9");
> >         if (IS_ERR(pll1_sysclk9)) {
> >                 printk(KERN_ERR "Could not get pll1_sysclk9\n");
> >                 return -ENODEV;
> >         }
> >         clk_enable(pll1_sysclk9);
> >
> >         /* check all possibilities to get best fitting for the required
> freq */
> >         i_min_err = min_err = INT_MAX;
> >         for (i = 0x0F; i > 0; i--) {
> >                 ret = clk_set_rate(pll1_sysclk9, rate * i);
> >                 err = clk_get_rate(pll1_sysclk9) - rate * i;
> >                 if (min_err > abs(err)) {
> >                         min_err = abs(err);
> >                         i_min_err = i;
> >                 }
> >         }
> >
> >         /* setting the best one to pll1_sysclk9 */
> >         ret = clk_set_rate(pll1_sysclk9, rate * i_min_err);
> >         if (ret)
> >                 return ret;
> >
> >         /* setting the best one to clkout2 */
> >         clkout2 = clk_get(NULL, "clkout2");
> >         if (IS_ERR(clkout2)) {
> >                 printk(KERN_ERR "Could not get clkout2\n");
> >                 return -ENODEV;
> >         }
> >         clk_enable(clkout2);
> >         clk_set_rate(clkout2,rate);
> >         return 0;
> > }
> >
> >
> >
> >  arch/arm/mach-davinci/dm365.c |   42
> +++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 42 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/dm365.c
> b/arch/arm/mach-davinci/dm365.c
> > index 42fd4a4..0101a6c 100644
> > --- a/arch/arm/mach-davinci/dm365.c
> > +++ b/arch/arm/mach-davinci/dm365.c
> > @@ -40,6 +40,40 @@
> >  #include "mux.h"
> >
> >  #define DM365_REF_FREQ               24000000        /* 24 MHz on the
> DM365 EVM */
> > +#define DIV1_MASK            0x78            /* DIV1 mask in PERI_CLKCTL
> */
> > +#define PERI_CLKCTL          0x48
> > +#define CLOCKOUT2EN          2
> > +
> > +int dm365_clkout2_set_rate(struct clk *clk, unsigned long rate)
> > +{
> > +     int i;
> > +     unsigned long input;
> > +     unsigned ratio;
> > +     unsigned regval;
> > +     void __iomem *system_module_base;
> > +
> > +     /* There must be a parent... */
> > +     if (WARN_ON(!clk->parent))
> > +             return -EINVAL;
> > +
> > +     input = clk->parent->rate;
> > +
> > +     if (input > rate)
> > +             ratio = DIV_ROUND_UP(input, rate) - 1;
>
> else ratio is undefined, and clock will be programmed to undefined
> value.
>

I guess there is a similar problem in davinci_set_sysclk_rate function in
the case
input <= rate.

Couldn't be the following a solution?

if (input > rate)
     ratio = DIV_ROUND_UP(input, rate) - 1;
else
     return -EINVAL;

As I'm calculating a divisor I need surely (input > rate).



>  Kevin
>
> > +     system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
> > +     regval = __raw_readl(system_module_base + PERI_CLKCTL);
> > +     regval &= ~DIV1_MASK;
> > +     regval |= ratio << 3;
> > +
> > +     /* to make changes work stop CLOCKOUT & start it again */
> > +     regval |= BIT(CLOCKOUT2EN);
> > +     __raw_writel(regval, system_module_base + PERI_CLKCTL);
> > +     regval &= ~(1 << CLOCKOUT2EN);
> > +     __raw_writel(regval, system_module_base + PERI_CLKCTL);
> > +     iounmap(system_module_base);
> > +     return 0;
> > +}
> >
> >  static struct pll_data pll1_data = {
> >       .num            = 1,
> > @@ -145,6 +179,13 @@ static struct clk pll1_sysclk9 = {
> >       .parent         = &pll1_clk,
> >       .flags          = CLK_PLL,
> >       .div_reg        = PLLDIV9,
> > +     .set_rate       = davinci_set_sysclk_rate,
> > +};
> > +
> > +static struct clk clkout2_clk = {
> > +     .name           = "clkout2",
> > +     .parent         = &pll1_sysclk9,
> > +     .set_rate       = dm365_clkout2_set_rate,
> >  };
> >
> >  static struct clk pll2_clk = {
> > @@ -421,6 +462,7 @@ static struct clk_lookup dm365_clks[] = {
> >       CLK(NULL, "pll1_sysclk7", &pll1_sysclk7),
> >       CLK(NULL, "pll1_sysclk8", &pll1_sysclk8),
> >       CLK(NULL, "pll1_sysclk9", &pll1_sysclk9),
> > +     CLK(NULL, "clkout2", &clkout2_clk),
> >       CLK(NULL, "pll2", &pll2_clk),
> >       CLK(NULL, "pll2_aux", &pll2_aux_clk),
> >       CLK(NULL, "clkout1", &clkout1_clk),
>



Regards,
Raffaele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100824/faff1ff7/attachment-0001.html>

From lamiaposta71 at gmail.com  Tue Aug 24 03:52:59 2010
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Tue, 24 Aug 2010 10:52:59 +0200
Subject: [PATCH v4] DaVinci: dm365: Added clockout2 management.
In-Reply-To: <AANLkTi=YN-0k1cFHsx+RBtOEPcSObKeHKD2BZd=tqYnn@mail.gmail.com>
References: <1281020128-5947-1-git-send-email-lamiaposta71@gmail.com>
	<87k4o4suym.fsf@deeprootsystems.com>
	<AANLkTi=YN-0k1cFHsx+RBtOEPcSObKeHKD2BZd=tqYnn@mail.gmail.com>
Message-ID: <AANLkTikp9edCR4-fnbXmXi_+Kv7SVLGM5+4LtoXSZRCQ@mail.gmail.com>

Sorry, please integrate the previous e-mail with this one...
(I made a mistake sending the e-mail)


>> > -Solving a possible race when writing PERI_CLKCTL, see Nori Sekhar
>> explanation:
>> > "Looks like the same register supports setting clocks for voice codec
>> > and keyscan module as well. This can cause a race if those clocks are
>> > modified in a different context. Can you extend this function to cover
>> > those clocks as well? May be clk->lpsc can be used to determine if div1,
>> > div2 or div3 need to be changed. This way you can serialize the setting
>> > up of these clocks."
>>
>> I agree with Sekhar. This needs to be addresed before this patch is
>> mergable.
>>
>
> It is more difficult.
> Something like the following?
>

int dm365_peri_clkctl_set_rate(struct clk *clk, unsigned long rate)
{
        int i;
        unsigned long input;
        unsigned ratio;
        unsigned regval;
        void __iomem *system_module_base;

        /* There must be a parent... */
        if (WARN_ON(!clk->parent))
                return -EINVAL;

        input = clk->parent->rate;

        if (input > rate)
                ratio = DIV_ROUND_UP(input, rate) - 1;

        system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
        regval = __raw_readl(system_module_base + PERI_CLKCTL);

        switch (clk->lpsc) {
        case DM365_LPSC_CLKOUT2:
              regval &= ~DIV1_MASK;
              regval |= ratio << 3;
              break;
        case DM365_LPSC_VOICE_CODEC:
              regval &= ~DIV2_MASK;
              regval |= ratio << 7;
              break;
        case DM365_LPSC_KEYSCAN:
            regval &= ~DIV3_MASK;
              regval |= ratio << 16;
              break;

        /* to make changes work stop CLOCKOUT & start it again */
        regval |= BIT(CLOCKOUT2EN);

       mutex_lock(&peri_clkctl_mutex);
        __raw_writel(regval, system_module_base + PERI_CLKCTL);
        regval &= ~(1 << CLOCKOUT2EN);
        __raw_writel(regval, system_module_base + PERI_CLKCTL);
       mutex_unlock(&peri_clkctl_mutex);

        iounmap(system_module_base);
        return 0;
}

Obviously a similar modification to the following recalc function will be
needed.

Regards,
Raffaele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100824/a28ae8fc/attachment.html>

From lidongfengstar at gmail.com  Tue Aug 24 20:43:08 2010
From: lidongfengstar at gmail.com (Dongfeng)
Date: Wed, 25 Aug 2010 09:43:08 +0800
Subject: FBdev On DM365IPNC not work correctly
Message-ID: <AANLkTikJ6S8dy+MfUYK0L-cetv7ONiyMyJAx0SqmXkcG@mail.gmail.com>

Hi,everyone:

My /dev/fb/0 2 do not work correctly on DM365IPNC.need help.

I wrote a OSD programme based on dm355IPNC,now we turn to dm365IPNC,since my
OSD programme is based on /dev/fb/0 and 2,and the dm365IPNC does not have
FBdev,although I reconfigured the kernel of dm365IPNC according to LSP 2.10
DaVinci Linux VPBE Frame Buffer Driver,although the /dev/fb/0 and 2 come
back,but when I use it ,it dose not work correctly,how can this happen? dose
DM365IPNC support FBDEV?

Thanks!
-- 
*Best Wishes?*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100825/5290f18d/attachment.html>

From raghu_ramaraj at mindtree.com  Wed Aug 25 00:57:25 2010
From: raghu_ramaraj at mindtree.com (Raghu Ramaraj)
Date: Wed, 25 Aug 2010 11:27:25 +0530
Subject: No subject
Message-ID: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DBB2@MTW02MSG02.mindtree.com>



Thanks & Regards,
Raghu Ramaraj| Tech Lead | MindTree Ltd. | West Campus Phase - 1 Global Village, RVCE Post, Mysore Road, Bangalore- 560 059, INDIA | Voice +91 80 67064000  / Fax +91 80 6706 4100 | Ext 64307|Mob: +91 9886652214 | email: raghu_ramaraj at mindtree.com| www.mindtree.com<http://www.mindtree.com/> |


________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100825/dcbbdab7/attachment.html>

From raghu_ramaraj at mindtree.com  Wed Aug 25 02:28:37 2010
From: raghu_ramaraj at mindtree.com (Raghu Ramaraj)
Date: Wed, 25 Aug 2010 12:58:37 +0530
Subject: need help- fw_printenv& fw_setenv
Message-ID: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>


Hi,
       We facing some issue while using fw_printenv and fw_setenv ( uboot tools). Pls find the logs/steps below
I have used linux 2.6.32 rc5 kernel source.


1)       MTD partition in the kernel level

Cat /proc/mtd
mtd0: 00020000 00004000 "params"
mtd1: 00140000 00004000 "bootloader"
mtd2: 00400000 00004000 "kernel"
mtd3: 03aa0000 00004000 "file system"
       param & bootloader  partitions are interchanged ?

2)       Cat /dev/mtd0 ->its displaying param related information


3)       I have used /etc/fw_env.config file


/dev/mtd0               0x0000          0x4000          0x4000
/dev/mtd1               0x4000          0x4000          0x4000


4)       If I do ./fw_printenv , I am getting the all the boot params
5)       If I do ./fw_setenv bootdelay , I am getting the following
Permission denied


Losg  are..............


root at 172.22.67.13:/home/raghu/env# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00004000 "params"
mtd1: 00140000 00004000 "bootloader"
mtd2: 00400000 00004000 "kernel"
mtd3: 03aa0000 00004000 "filesystem"
root at 172.22.67.13:/home/raghu/env# cat /dev/mtd0
uE?bootdelay=3baudrate=115200bootfile="uImage"addclk=setenv bootargs ${bootargs}
 clkref=${clkref}ethact=DaVinci EMACfilesize=D9CB0Ffileaddr=87000000gatewayip=17
2.22.64.1netmask=255.255.240.0ipaddr=172.22.66.43bootcmd=ping 192.168.1.1;nand r
ead 0x84600000 0x4a0000 0x1400000;nboot 0x80700000 0 0xa0000;bootmserverip=172.2
2.75.253ethaddr=00:0e:99:02:b5:69clkref=33000000stdin=serialstdout=serialstderr=
serialver=U-Boot 2009.08 (Jul 10 2010 - 11:44:06)bootargs=console=ttyS0,115200n8
 noinitrd rw root=/dev/nfs nfsroot=172.22.75.253:/opt/mv_pro_5.0/montavista/pro/
devkit/arm/v5t_le/target/,nolock mem=80M eth=00:0e:99:02:b5:69 ip=dhcp0 - 14:34:
54)0700000 0 0xa0000;bootm
root at 172.22.67.13:/home/raghu/env# ./fw_printenv
ootdelay=3
baudrate=115200
bootfile="uImage"
addclk=setenv bootargs ${bootargs} clkref=${clkref}
ethact=DaVinci EMAC
filesize=D9CB0F
fileaddr=87000000
gatewayip=172.22.64.1
netmask=255.255.240.0
ipaddr=172.22.66.43
bootcmd=ping 192.168.1.1;nand read 0x84600000 0x4a0000 0x1400000;nboot 0x8070000
0 0 0xa0000;bootm
serverip=172.22.75.253
ethaddr=00:0e:99:02:b5:69
clkref=33000000
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.08 (Jul 10 2010 - 11:44:06)
bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs nfsroot=172.22.75.253:
/opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/,nolock mem=80M eth=00:0
e:99:02:b5:69 ip=dhcp
root at 172.22.67.13:/home/raghu/env# ./fw_setenv bootdelay 0
Can't open /dev/mtd1: Permission denied
Error: can't write fw_env to flash
root at 172.22.67.13:/home/raghu/env#



Thanks & Regards
Raghu Ramaraj

________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100825/4768b3b9/attachment-0001.html>

From amraldo at hotmail.com  Wed Aug 25 02:58:50 2010
From: amraldo at hotmail.com (amr ali)
Date: Wed, 25 Aug 2010 09:58:50 +0200
Subject: Flash Enabled Web Browser
Message-ID: <SNT127-W64C40C68BF1308EED0842DB7840@phx.gbl>


Is there any flash enabled web browser or flash player that can run on TI Davinci DM6446 EVM?
--
Amr Ali Abdel-Naby
Embedded Systems Developer
www.embedded-tips.blogspot.com


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100825/4dce098e/attachment.html>

From caglarakyuz at gmail.com  Wed Aug 25 03:12:37 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Wed, 25 Aug 2010 11:12:37 +0300
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
Message-ID: <201008251112.37971.caglarakyuz@gmail.com>

On Wednesday 25 August 2010 10:28:37 am Raghu Ramaraj wrote:
> Hi,
>        We facing some issue while using fw_printenv and fw_setenv ( uboot
>  tools). Pls find the logs/steps below I have used linux 2.6.32 rc5 kernel
>  source.
> 
> 
> 1)       MTD partition in the kernel level
> 
> Cat /proc/mtd
> mtd0: 00020000 00004000 "params"
> mtd1: 00140000 00004000 "bootloader"
> mtd2: 00400000 00004000 "kernel"
> mtd3: 03aa0000 00004000 "file system"
>        param & bootloader  partitions are interchanged ?
> 
> 2)       Cat /dev/mtd0 ->its displaying param related information
> 
> 
> 3)       I have used /etc/fw_env.config file
> 
> 
> /dev/mtd0               0x0000          0x4000          0x4000
> /dev/mtd1               0x4000          0x4000          0x4000
> 
> 
> 4)       If I do ./fw_printenv , I am getting the all the boot params
> 5)       If I do ./fw_setenv bootdelay , I am getting the following
> Permission denied
> 

AFAIR, params partition is set read-only in board file.

Regards,
Caglar

> 
> Losg  are..............
> 
> 
> root at 172.22.67.13:/home/raghu/env# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00020000 00004000 "params"
> mtd1: 00140000 00004000 "bootloader"
> mtd2: 00400000 00004000 "kernel"
> mtd3: 03aa0000 00004000 "filesystem"
> root at 172.22.67.13:/home/raghu/env# cat /dev/mtd0
> uE?bootdelay=3baudrate=115200bootfile="uImage"addclk=setenv bootargs
>  ${bootargs} clkref=${clkref}ethact=DaVinci
>  EMACfilesize=D9CB0Ffileaddr=87000000gatewayip=17
>  2.22.64.1netmask=255.255.240.0ipaddr=172.22.66.43bootcmd=ping
>  192.168.1.1;nand r ead 0x84600000 0x4a0000 0x1400000;nboot 0x80700000 0
>  0xa0000;bootmserverip=172.2
>  2.75.253ethaddr=00:0e:99:02:b5:69clkref=33000000stdin=serialstdout=serials
> tderr= serialver=U-Boot 2009.08 (Jul 10 2010 -
>  11:44:06)bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
>  nfsroot=172.22.75.253:/opt/mv_pro_5.0/montavista/pro/
>  devkit/arm/v5t_le/target/,nolock mem=80M eth=00:0e:99:02:b5:69 ip=dhcp0 -
>  14:34: 54)0700000 0 0xa0000;bootm
> root at 172.22.67.13:/home/raghu/env# ./fw_printenv
> ootdelay=3
> baudrate=115200
> bootfile="uImage"
> addclk=setenv bootargs ${bootargs} clkref=${clkref}
> ethact=DaVinci EMAC
> filesize=D9CB0F
> fileaddr=87000000
> gatewayip=172.22.64.1
> netmask=255.255.240.0
> ipaddr=172.22.66.43
> bootcmd=ping 192.168.1.1;nand read 0x84600000 0x4a0000 0x1400000;nboot
>  0x8070000 0 0 0xa0000;bootm
> serverip=172.22.75.253
> ethaddr=00:0e:99:02:b5:69
> clkref=33000000
> stdin=serial
> stdout=serial
> stderr=serial
> ver=U-Boot 2009.08 (Jul 10 2010 - 11:44:06)
> bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
>  nfsroot=172.22.75.253:
>  /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/,nolock mem=80M
>  eth=00:0 e:99:02:b5:69 ip=dhcp
> root at 172.22.67.13:/home/raghu/env# ./fw_setenv bootdelay 0
> Can't open /dev/mtd1: Permission denied
> Error: can't write fw_env to flash
> root at 172.22.67.13:/home/raghu/env#
> 
> 
> 
> Thanks & Regards
> Raghu Ramaraj
> 
> ________________________________
> http://www.mindtree.com/email/disclaimer.html
> 

From raghu_ramaraj at mindtree.com  Wed Aug 25 03:31:30 2010
From: raghu_ramaraj at mindtree.com (Raghu Ramaraj)
Date: Wed, 25 Aug 2010 14:01:30 +0530
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <201008251112.37971.caglarakyuz@gmail.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
	<201008251112.37971.caglarakyuz@gmail.com>
Message-ID: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DDF6@MTW02MSG02.mindtree.com>


Pls find the partitions in arch/arm/mach-davinci/board-dm646x-evm.c


static struct mtd_partition davinci_nand_partitions[] = {
        {
                /* U-Boot environment */
                .name           = "params",
                .offset         = 0,
                .size           = 1 * NAND_BLOCK_SIZE,
                .mask_flags     = 0,
        }, {
                /* UBL, U-Boot */
                .name           = "bootloader",
                .offset         = MTDPART_OFS_APPEND,
                .size           = 10 * NAND_BLOCK_SIZE,
                .mask_flags     = MTD_WRITEABLE,        /* force read-only */
        }, {
                .name           = "kernel",
                .offset         = MTDPART_OFS_APPEND,
                .size           = SZ_4M,
                .mask_flags     = 0,
        }, {
                .name           = "filesystem",
                .offset         = MTDPART_OFS_APPEND,
                .size           = MTDPART_SIZ_FULL,
                .mask_flags     = 0,
        }
};

Thanks & Regards,
Raghu Ramaraj

 
-----Original Message-----
From: Caglar Akyuz [mailto:caglarakyuz at gmail.com] 
Sent: Wednesday, August 25, 2010 1:43 PM
To: davinci-linux-open-source at linux.davincidsp.com
Cc: Raghu Ramaraj; Jose, Frangline
Subject: Re: need help- fw_printenv& fw_setenv

On Wednesday 25 August 2010 10:28:37 am Raghu Ramaraj wrote:
> Hi,
>        We facing some issue while using fw_printenv and fw_setenv ( uboot
>  tools). Pls find the logs/steps below I have used linux 2.6.32 rc5 kernel
>  source.
> 
> 
> 1)       MTD partition in the kernel level
> 
> Cat /proc/mtd
> mtd0: 00020000 00004000 "params"
> mtd1: 00140000 00004000 "bootloader"
> mtd2: 00400000 00004000 "kernel"
> mtd3: 03aa0000 00004000 "file system"
>        param & bootloader  partitions are interchanged ?
> 
> 2)       Cat /dev/mtd0 ->its displaying param related information
> 
> 
> 3)       I have used /etc/fw_env.config file
> 
> 
> /dev/mtd0               0x0000          0x4000          0x4000
> /dev/mtd1               0x4000          0x4000          0x4000
> 
> 
> 4)       If I do ./fw_printenv , I am getting the all the boot params
> 5)       If I do ./fw_setenv bootdelay , I am getting the following
> Permission denied
> 

AFAIR, params partition is set read-only in board file.

Regards,
Caglar

> 
> Losg  are..............
> 
> 
> root at 172.22.67.13:/home/raghu/env# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00020000 00004000 "params"
> mtd1: 00140000 00004000 "bootloader"
> mtd2: 00400000 00004000 "kernel"
> mtd3: 03aa0000 00004000 "filesystem"
> root at 172.22.67.13:/home/raghu/env# cat /dev/mtd0
> uE?bootdelay=3baudrate=115200bootfile="uImage"addclk=setenv bootargs
>  ${bootargs} clkref=${clkref}ethact=DaVinci
>  EMACfilesize=D9CB0Ffileaddr=87000000gatewayip=17
>  2.22.64.1netmask=255.255.240.0ipaddr=172.22.66.43bootcmd=ping
>  192.168.1.1;nand r ead 0x84600000 0x4a0000 0x1400000;nboot 0x80700000 0
>  0xa0000;bootmserverip=172.2
>  2.75.253ethaddr=00:0e:99:02:b5:69clkref=33000000stdin=serialstdout=serials
> tderr= serialver=U-Boot 2009.08 (Jul 10 2010 -
>  11:44:06)bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
>  nfsroot=172.22.75.253:/opt/mv_pro_5.0/montavista/pro/
>  devkit/arm/v5t_le/target/,nolock mem=80M eth=00:0e:99:02:b5:69 ip=dhcp0 -
>  14:34: 54)0700000 0 0xa0000;bootm
> root at 172.22.67.13:/home/raghu/env# ./fw_printenv
> ootdelay=3
> baudrate=115200
> bootfile="uImage"
> addclk=setenv bootargs ${bootargs} clkref=${clkref}
> ethact=DaVinci EMAC
> filesize=D9CB0F
> fileaddr=87000000
> gatewayip=172.22.64.1
> netmask=255.255.240.0
> ipaddr=172.22.66.43
> bootcmd=ping 192.168.1.1;nand read 0x84600000 0x4a0000 0x1400000;nboot
>  0x8070000 0 0 0xa0000;bootm
> serverip=172.22.75.253
> ethaddr=00:0e:99:02:b5:69
> clkref=33000000
> stdin=serial
> stdout=serial
> stderr=serial
> ver=U-Boot 2009.08 (Jul 10 2010 - 11:44:06)
> bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
>  nfsroot=172.22.75.253:
>  /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/,nolock mem=80M
>  eth=00:0 e:99:02:b5:69 ip=dhcp
> root at 172.22.67.13:/home/raghu/env# ./fw_setenv bootdelay 0
> Can't open /dev/mtd1: Permission denied
> Error: can't write fw_env to flash
> root at 172.22.67.13:/home/raghu/env#
> 
> 
> 
> Thanks & Regards
> Raghu Ramaraj
> 
> ________________________________
> http://www.mindtree.com/email/disclaimer.html
> 

From schen at mvista.com  Wed Aug 25 05:22:50 2010
From: schen at mvista.com (Steve Chen)
Date: Wed, 25 Aug 2010 05:22:50 -0500
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DDF6@MTW02MSG02.mindtree.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
	<201008251112.37971.caglarakyuz@gmail.com>
	<DE1563FF5EF45A4794D1220EF0363CB4120CF8DDF6@MTW02MSG02.mindtree.com>
Message-ID: <AANLkTikRsfr5ZRXxrVYntmiipX3Mq-vzMsd=kx7mF9-9@mail.gmail.com>

On Wed, Aug 25, 2010 at 3:31 AM, Raghu Ramaraj
<raghu_ramaraj at mindtree.com> wrote:

> ? ? ? ? ? ? ? ?/* UBL, U-Boot */
> ? ? ? ? ? ? ? ?.name ? ? ? ? ? = "bootloader",
> ? ? ? ? ? ? ? ?.offset ? ? ? ? = MTDPART_OFS_APPEND,
> ? ? ? ? ? ? ? ?.size ? ? ? ? ? = 10 * NAND_BLOCK_SIZE,
> ? ? ? ? ? ? ? ?.mask_flags ? ? = MTD_WRITEABLE, ? ? ? ?/* force read-only */

mtd1 is set to read only here.
...

>> root at 172.22.67.13:/home/raghu/env# ./fw_setenv bootdelay 0
>> Can't open /dev/mtd1: Permission denied
>> Error: can't write fw_env to flash

so this should be expected.

Regards,

Steve

From raghu_ramaraj at mindtree.com  Wed Aug 25 06:15:40 2010
From: raghu_ramaraj at mindtree.com (Raghu Ramaraj)
Date: Wed, 25 Aug 2010 16:45:40 +0530
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <AANLkTikRsfr5ZRXxrVYntmiipX3Mq-vzMsd=kx7mF9-9@mail.gmail.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
	<201008251112.37971.caglarakyuz@gmail.com>
	<DE1563FF5EF45A4794D1220EF0363CB4120CF8DDF6@MTW02MSG02.mindtree.com>
	<AANLkTikRsfr5ZRXxrVYntmiipX3Mq-vzMsd=kx7mF9-9@mail.gmail.com>
Message-ID: <DE1563FF5EF45A4794D1220EF0363CB4120CF8E0F5@MTW02MSG02.mindtree.com>

That's u-boot partition... not the param. The fw_setenv is always looking /dev/mtd1. But here it is not a param partition.
Even if I change to " MTD_WRITEABLE" to 0 , it corrupting the u-boot.


Thanks & Regards,
Raghu Ramaraj

-----Original Message-----
From: Steve Chen [mailto:schen at mvista.com]
Sent: Wednesday, August 25, 2010 3:53 PM
To: Raghu Ramaraj
Cc: Caglar Akyuz; davinci-linux-open-source at linux.davincidsp.com; Jose, Frangline
Subject: Re: need help- fw_printenv& fw_setenv

On Wed, Aug 25, 2010 at 3:31 AM, Raghu Ramaraj
<raghu_ramaraj at mindtree.com> wrote:

>                /* UBL, U-Boot */
>                .name           = "bootloader",
>                .offset         = MTDPART_OFS_APPEND,
>                .size           = 10 * NAND_BLOCK_SIZE,
>                .mask_flags     = MTD_WRITEABLE,        /* force read-only */

mtd1 is set to read only here.
...

>> root at 172.22.67.13:/home/raghu/env# ./fw_setenv bootdelay 0
>> Can't open /dev/mtd1: Permission denied
>> Error: can't write fw_env to flash

so this should be expected.

Regards,

Steve

http://www.mindtree.com/email/disclaimer.html

From schen at mvista.com  Wed Aug 25 06:37:01 2010
From: schen at mvista.com (Steve Chen)
Date: Wed, 25 Aug 2010 06:37:01 -0500
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <DE1563FF5EF45A4794D1220EF0363CB4120CF8E0F5@MTW02MSG02.mindtree.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
	<201008251112.37971.caglarakyuz@gmail.com>
	<DE1563FF5EF45A4794D1220EF0363CB4120CF8DDF6@MTW02MSG02.mindtree.com>
	<AANLkTikRsfr5ZRXxrVYntmiipX3Mq-vzMsd=kx7mF9-9@mail.gmail.com>
	<DE1563FF5EF45A4794D1220EF0363CB4120CF8E0F5@MTW02MSG02.mindtree.com>
Message-ID: <AANLkTikXgAt2Qnyh_bkPLSR-SDtJnLhtvk+pbYCG8ics@mail.gmail.com>

On Wed, Aug 25, 2010 at 6:15 AM, Raghu Ramaraj
<raghu_ramaraj at mindtree.com> wrote:
> That's u-boot partition... not the param. The fw_setenv is always looking /dev/mtd1. But here it is not a param partition.

>From the code, it is pretty obvious mtd1 is the u-boot partition.  I
guess I'm also stating the obvious that fw_setenv should update mtd0
instead of mtd1.  At least, we both agree on that.

> Even if I change to " MTD_WRITEABLE" to 0 , it corrupting the u-boot.

If fw_sentenv writes to mtd1, isn't that the expected behavior?

Steve

From caglarakyuz at gmail.com  Wed Aug 25 06:52:18 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Wed, 25 Aug 2010 14:52:18 +0300
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
Message-ID: <201008251452.18749.caglarakyuz@gmail.com>

On Wednesday 25 August 2010 10:28:37 am Raghu Ramaraj wrote:
> Hi,
>        We facing some issue while using fw_printenv and fw_setenv ( uboot
>  tools). Pls find the logs/steps below I have used linux 2.6.32 rc5 kernel
>  source.
> 
> 
> 1)       MTD partition in the kernel level
> 
> Cat /proc/mtd
> mtd0: 00020000 00004000 "params"
> mtd1: 00140000 00004000 "bootloader"
> mtd2: 00400000 00004000 "kernel"
> mtd3: 03aa0000 00004000 "file system"
>        param & bootloader  partitions are interchanged ?
> 
> 2)       Cat /dev/mtd0 ->its displaying param related information
> 
> 
> 3)       I have used /etc/fw_env.config file
> 
> 
> /dev/mtd0               0x0000          0x4000          0x4000
> /dev/mtd1               0x4000          0x4000          0x4000
> 

This file is completely wrong for DM6467. I guess you copied the exact config 
from u-boot tree but this is for 2 NAND flashes with small page. Correct 
version should be:

/dev/mtd0               0x0000          0x20000         0x20000

Assuming your page size is 2KiB.

Regards,
Caglar

> 
> 4)       If I do ./fw_printenv , I am getting the all the boot params
> 5)       If I do ./fw_setenv bootdelay , I am getting the following
> Permission denied
> 
> 
> Losg  are..............
> 
> 
> root at 172.22.67.13:/home/raghu/env# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00020000 00004000 "params"
> mtd1: 00140000 00004000 "bootloader"
> mtd2: 00400000 00004000 "kernel"
> mtd3: 03aa0000 00004000 "filesystem"
> root at 172.22.67.13:/home/raghu/env# cat /dev/mtd0
> uE?bootdelay=3baudrate=115200bootfile="uImage"addclk=setenv bootargs
>  ${bootargs} clkref=${clkref}ethact=DaVinci
>  EMACfilesize=D9CB0Ffileaddr=87000000gatewayip=17
>  2.22.64.1netmask=255.255.240.0ipaddr=172.22.66.43bootcmd=ping
>  192.168.1.1;nand r ead 0x84600000 0x4a0000 0x1400000;nboot 0x80700000 0
>  0xa0000;bootmserverip=172.2
>  2.75.253ethaddr=00:0e:99:02:b5:69clkref=33000000stdin=serialstdout=serials
> tderr= serialver=U-Boot 2009.08 (Jul 10 2010 -
>  11:44:06)bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
>  nfsroot=172.22.75.253:/opt/mv_pro_5.0/montavista/pro/
>  devkit/arm/v5t_le/target/,nolock mem=80M eth=00:0e:99:02:b5:69 ip=dhcp0 -
>  14:34: 54)0700000 0 0xa0000;bootm
> root at 172.22.67.13:/home/raghu/env# ./fw_printenv
> ootdelay=3
> baudrate=115200
> bootfile="uImage"
> addclk=setenv bootargs ${bootargs} clkref=${clkref}
> ethact=DaVinci EMAC
> filesize=D9CB0F
> fileaddr=87000000
> gatewayip=172.22.64.1
> netmask=255.255.240.0
> ipaddr=172.22.66.43
> bootcmd=ping 192.168.1.1;nand read 0x84600000 0x4a0000 0x1400000;nboot
>  0x8070000 0 0 0xa0000;bootm
> serverip=172.22.75.253
> ethaddr=00:0e:99:02:b5:69
> clkref=33000000
> stdin=serial
> stdout=serial
> stderr=serial
> ver=U-Boot 2009.08 (Jul 10 2010 - 11:44:06)
> bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
>  nfsroot=172.22.75.253:
>  /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/,nolock mem=80M
>  eth=00:0 e:99:02:b5:69 ip=dhcp
> root at 172.22.67.13:/home/raghu/env# ./fw_setenv bootdelay 0
> Can't open /dev/mtd1: Permission denied
> Error: can't write fw_env to flash
> root at 172.22.67.13:/home/raghu/env#
> 
> 
> 
> Thanks & Regards
> Raghu Ramaraj
> 
> ________________________________
> http://www.mindtree.com/email/disclaimer.html
> 

From raghu_ramaraj at mindtree.com  Wed Aug 25 07:09:33 2010
From: raghu_ramaraj at mindtree.com (Raghu Ramaraj)
Date: Wed, 25 Aug 2010 17:39:33 +0530
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <AANLkTikXgAt2Qnyh_bkPLSR-SDtJnLhtvk+pbYCG8ics@mail.gmail.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
	<201008251112.37971.caglarakyuz@gmail.com>
	<DE1563FF5EF45A4794D1220EF0363CB4120CF8DDF6@MTW02MSG02.mindtree.com>
	<AANLkTikRsfr5ZRXxrVYntmiipX3Mq-vzMsd=kx7mF9-9@mail.gmail.com>
	<DE1563FF5EF45A4794D1220EF0363CB4120CF8E0F5@MTW02MSG02.mindtree.com>
	<AANLkTikXgAt2Qnyh_bkPLSR-SDtJnLhtvk+pbYCG8ics@mail.gmail.com>
Message-ID: <DE1563FF5EF45A4794D1220EF0363CB4120D20F521@MTW02MSG02.mindtree.com>

Some workaround is required to resolve this
1) Have to change the partition table in kernel/uboot/ubl
2) Have to change the device from /dev/mtd1 to /dev/mtd0 in fw_env.c


Thanks & Regards,
Raghu Ramaraj


-----Original Message-----
From: Steve Chen [mailto:schen at mvista.com]
Sent: Wednesday, August 25, 2010 5:07 PM
To: Raghu Ramaraj
Cc: Caglar Akyuz; davinci-linux-open-source at linux.davincidsp.com; Jose, Frangline
Subject: Re: need help- fw_printenv& fw_setenv

On Wed, Aug 25, 2010 at 6:15 AM, Raghu Ramaraj
<raghu_ramaraj at mindtree.com> wrote:
> That's u-boot partition... not the param. The fw_setenv is always looking /dev/mtd1. But here it is not a param partition.

>From the code, it is pretty obvious mtd1 is the u-boot partition.  I
guess I'm also stating the obvious that fw_setenv should update mtd0
instead of mtd1.  At least, we both agree on that.

> Even if I change to " MTD_WRITEABLE" to 0 , it corrupting the u-boot.

If fw_sentenv writes to mtd1, isn't that the expected behavior?

Steve

http://www.mindtree.com/email/disclaimer.html

From raghu_ramaraj at mindtree.com  Wed Aug 25 07:14:07 2010
From: raghu_ramaraj at mindtree.com (Raghu Ramaraj)
Date: Wed, 25 Aug 2010 17:44:07 +0530
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <201008251452.18749.caglarakyuz@gmail.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
	<201008251452.18749.caglarakyuz@gmail.com>
Message-ID: <DE1563FF5EF45A4794D1220EF0363CB4120D20F538@MTW02MSG02.mindtree.com>


I have added the following lines in config file

# MTD device name       Device offset   Env. size       Flash sector size       Number of sectors
#/dev/mtd0              0x0000          0x4000          0x4000
#/dev/mtd1              0x4000          0x4000          0x4000
#/dev/mtd2              0x0000          0x4000          0x4000

#/dev/mtd0              0x0000          0x4000          0x4000
#/dev/mtd1              0x4000          0x4000          0x4000

# NAND example
#/dev/mtd0              0x0000          0x4000          0x4000                  2
#/dev/mtd1              0x4000          0x4000          0x4000                  2

#/dev/mtd1              0x0000          0x140000        0x4000                  50
/dev/mtd0               0x0000          0x20000         0x20000

Its giving " Segmentation fault"


Thanks & Regards,
Raghu Ramaraj

-----Original Message-----
From: Caglar Akyuz [mailto:caglarakyuz at gmail.com] 
Sent: Wednesday, August 25, 2010 5:22 PM
To: davinci-linux-open-source at linux.davincidsp.com
Cc: Raghu Ramaraj; Jose, Frangline
Subject: Re: need help- fw_printenv& fw_setenv

On Wednesday 25 August 2010 10:28:37 am Raghu Ramaraj wrote:
> Hi,
>        We facing some issue while using fw_printenv and fw_setenv ( uboot
>  tools). Pls find the logs/steps below I have used linux 2.6.32 rc5 kernel
>  source.
> 
> 
> 1)       MTD partition in the kernel level
> 
> Cat /proc/mtd
> mtd0: 00020000 00004000 "params"
> mtd1: 00140000 00004000 "bootloader"
> mtd2: 00400000 00004000 "kernel"
> mtd3: 03aa0000 00004000 "file system"
>        param & bootloader  partitions are interchanged ?
> 
> 2)       Cat /dev/mtd0 ->its displaying param related information
> 
> 
> 3)       I have used /etc/fw_env.config file
> 
> 
> /dev/mtd0               0x0000          0x4000          0x4000
> /dev/mtd1               0x4000          0x4000          0x4000
> 

This file is completely wrong for DM6467. I guess you copied the exact config 
from u-boot tree but this is for 2 NAND flashes with small page. Correct 
version should be:

/dev/mtd0               0x0000          0x20000         0x20000

Assuming your page size is 2KiB.

Regards,
Caglar

> 
> 4)       If I do ./fw_printenv , I am getting the all the boot params
> 5)       If I do ./fw_setenv bootdelay , I am getting the following
> Permission denied
> 
> 
> Losg  are..............
> 
> 
> root at 172.22.67.13:/home/raghu/env# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00020000 00004000 "params"
> mtd1: 00140000 00004000 "bootloader"
> mtd2: 00400000 00004000 "kernel"
> mtd3: 03aa0000 00004000 "filesystem"
> root at 172.22.67.13:/home/raghu/env# cat /dev/mtd0
> uE?bootdelay=3baudrate=115200bootfile="uImage"addclk=setenv bootargs
>  ${bootargs} clkref=${clkref}ethact=DaVinci
>  EMACfilesize=D9CB0Ffileaddr=87000000gatewayip=17
>  2.22.64.1netmask=255.255.240.0ipaddr=172.22.66.43bootcmd=ping
>  192.168.1.1;nand r ead 0x84600000 0x4a0000 0x1400000;nboot 0x80700000 0
>  0xa0000;bootmserverip=172.2
>  2.75.253ethaddr=00:0e:99:02:b5:69clkref=33000000stdin=serialstdout=serials
> tderr= serialver=U-Boot 2009.08 (Jul 10 2010 -
>  11:44:06)bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
>  nfsroot=172.22.75.253:/opt/mv_pro_5.0/montavista/pro/
>  devkit/arm/v5t_le/target/,nolock mem=80M eth=00:0e:99:02:b5:69 ip=dhcp0 -
>  14:34: 54)0700000 0 0xa0000;bootm
> root at 172.22.67.13:/home/raghu/env# ./fw_printenv
> ootdelay=3
> baudrate=115200
> bootfile="uImage"
> addclk=setenv bootargs ${bootargs} clkref=${clkref}
> ethact=DaVinci EMAC
> filesize=D9CB0F
> fileaddr=87000000
> gatewayip=172.22.64.1
> netmask=255.255.240.0
> ipaddr=172.22.66.43
> bootcmd=ping 192.168.1.1;nand read 0x84600000 0x4a0000 0x1400000;nboot
>  0x8070000 0 0 0xa0000;bootm
> serverip=172.22.75.253
> ethaddr=00:0e:99:02:b5:69
> clkref=33000000
> stdin=serial
> stdout=serial
> stderr=serial
> ver=U-Boot 2009.08 (Jul 10 2010 - 11:44:06)
> bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
>  nfsroot=172.22.75.253:
>  /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/,nolock mem=80M
>  eth=00:0 e:99:02:b5:69 ip=dhcp
> root at 172.22.67.13:/home/raghu/env# ./fw_setenv bootdelay 0
> Can't open /dev/mtd1: Permission denied
> Error: can't write fw_env to flash
> root at 172.22.67.13:/home/raghu/env#
> 
> 
> 
> Thanks & Regards
> Raghu Ramaraj
> 
> ________________________________
> http://www.mindtree.com/email/disclaimer.html
> 

From caglarakyuz at gmail.com  Wed Aug 25 07:22:37 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Wed, 25 Aug 2010 15:22:37 +0300
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <DE1563FF5EF45A4794D1220EF0363CB4120D20F538@MTW02MSG02.mindtree.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
	<201008251452.18749.caglarakyuz@gmail.com>
	<DE1563FF5EF45A4794D1220EF0363CB4120D20F538@MTW02MSG02.mindtree.com>
Message-ID: <201008251522.37921.caglarakyuz@gmail.com>

On Wednesday 25 August 2010 03:14:07 pm Raghu Ramaraj wrote:
> I have added the following lines in config file
> 
> # MTD device name       Device offset   Env. size       Flash sector size  
>      Number of sectors #/dev/mtd0              0x0000          0x4000      
>     0x4000
> #/dev/mtd1              0x4000          0x4000          0x4000
> #/dev/mtd2              0x0000          0x4000          0x4000
> 
> #/dev/mtd0              0x0000          0x4000          0x4000
> #/dev/mtd1              0x4000          0x4000          0x4000
> 
> # NAND example
> #/dev/mtd0              0x0000          0x4000          0x4000             
>      2 #/dev/mtd1              0x4000          0x4000          0x4000      
>             2
> 
> #/dev/mtd1              0x0000          0x140000        0x4000             
>      50 /dev/mtd0               0x0000          0x20000         0x20000
> 
> Its giving " Segmentation fault"
> 

I remember a bug in fw_printenv but I'm not sure if this is related to that 
bug or not. I reported this issue in a thread in this list. If you search the 
archives maybe that solution can help you as well.

Regards,
Caglar

> 
> Thanks & Regards,
> Raghu Ramaraj
> 
> -----Original Message-----
> From: Caglar Akyuz [mailto:caglarakyuz at gmail.com]
> Sent: Wednesday, August 25, 2010 5:22 PM
> To: davinci-linux-open-source at linux.davincidsp.com
> Cc: Raghu Ramaraj; Jose, Frangline
> Subject: Re: need help- fw_printenv& fw_setenv
> 
> On Wednesday 25 August 2010 10:28:37 am Raghu Ramaraj wrote:
> > Hi,
> >        We facing some issue while using fw_printenv and fw_setenv ( uboot
> >  tools). Pls find the logs/steps below I have used linux 2.6.32 rc5
> > kernel source.
> >
> >
> > 1)       MTD partition in the kernel level
> >
> > Cat /proc/mtd
> > mtd0: 00020000 00004000 "params"
> > mtd1: 00140000 00004000 "bootloader"
> > mtd2: 00400000 00004000 "kernel"
> > mtd3: 03aa0000 00004000 "file system"
> >        param & bootloader  partitions are interchanged ?
> >
> > 2)       Cat /dev/mtd0 ->its displaying param related information
> >
> >
> > 3)       I have used /etc/fw_env.config file
> >
> >
> > /dev/mtd0               0x0000          0x4000          0x4000
> > /dev/mtd1               0x4000          0x4000          0x4000
> 
> This file is completely wrong for DM6467. I guess you copied the exact
>  config from u-boot tree but this is for 2 NAND flashes with small page.
>  Correct version should be:
> 
> /dev/mtd0               0x0000          0x20000         0x20000
> 
> Assuming your page size is 2KiB.
> 
> Regards,
> Caglar
> 
> > 4)       If I do ./fw_printenv , I am getting the all the boot params
> > 5)       If I do ./fw_setenv bootdelay , I am getting the following
> > Permission denied
> >
> >
> > Losg  are..............
> >
> >
> > root at 172.22.67.13:/home/raghu/env# cat /proc/mtd
> > dev:    size   erasesize  name
> > mtd0: 00020000 00004000 "params"
> > mtd1: 00140000 00004000 "bootloader"
> > mtd2: 00400000 00004000 "kernel"
> > mtd3: 03aa0000 00004000 "filesystem"
> > root at 172.22.67.13:/home/raghu/env# cat /dev/mtd0
> > uE?bootdelay=3baudrate=115200bootfile="uImage"addclk=setenv bootargs
> >  ${bootargs} clkref=${clkref}ethact=DaVinci
> >  EMACfilesize=D9CB0Ffileaddr=87000000gatewayip=17
> >  2.22.64.1netmask=255.255.240.0ipaddr=172.22.66.43bootcmd=ping
> >  192.168.1.1;nand r ead 0x84600000 0x4a0000 0x1400000;nboot 0x80700000 0
> >  0xa0000;bootmserverip=172.2
> > 
> > 2.75.253ethaddr=00:0e:99:02:b5:69clkref=33000000stdin=serialstdout=serial
> >s tderr= serialver=U-Boot 2009.08 (Jul 10 2010 -
> >  11:44:06)bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
> >  nfsroot=172.22.75.253:/opt/mv_pro_5.0/montavista/pro/
> >  devkit/arm/v5t_le/target/,nolock mem=80M eth=00:0e:99:02:b5:69 ip=dhcp0
> > - 14:34: 54)0700000 0 0xa0000;bootm
> > root at 172.22.67.13:/home/raghu/env# ./fw_printenv
> > ootdelay=3
> > baudrate=115200
> > bootfile="uImage"
> > addclk=setenv bootargs ${bootargs} clkref=${clkref}
> > ethact=DaVinci EMAC
> > filesize=D9CB0F
> > fileaddr=87000000
> > gatewayip=172.22.64.1
> > netmask=255.255.240.0
> > ipaddr=172.22.66.43
> > bootcmd=ping 192.168.1.1;nand read 0x84600000 0x4a0000 0x1400000;nboot
> >  0x8070000 0 0 0xa0000;bootm
> > serverip=172.22.75.253
> > ethaddr=00:0e:99:02:b5:69
> > clkref=33000000
> > stdin=serial
> > stdout=serial
> > stderr=serial
> > ver=U-Boot 2009.08 (Jul 10 2010 - 11:44:06)
> > bootargs=console=ttyS0,115200n8 noinitrd rw root=/dev/nfs
> >  nfsroot=172.22.75.253:
> >  /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/target/,nolock mem=80M
> >  eth=00:0 e:99:02:b5:69 ip=dhcp
> > root at 172.22.67.13:/home/raghu/env# ./fw_setenv bootdelay 0
> > Can't open /dev/mtd1: Permission denied
> > Error: can't write fw_env to flash
> > root at 172.22.67.13:/home/raghu/env#
> >
> >
> >
> > Thanks & Regards
> > Raghu Ramaraj
> >
> > ________________________________
> > http://www.mindtree.com/email/disclaimer.html
> 

From sudhakar.raj at ti.com  Wed Aug 25 07:27:40 2010
From: sudhakar.raj at ti.com (Sudhakar Rajashekhara)
Date: Wed, 25 Aug 2010 17:57:40 +0530
Subject: [RFC] nand/davinci: Fix comment to match the code
In-Reply-To: <1282738700-30966-1-git-send-email-w.sang@pengutronix.de>
References: <1282738700-30966-1-git-send-email-w.sang@pengutronix.de>
Message-ID: <039d01cb4450$e8f7d6a0$bae783e0$@raj@ti.com>

Hi,

On Wed, Aug 25, 2010 at 17:48:20, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang <w.sang at pengutronix.de>
> Cc: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
> Cc: Sneha Narnakaje <nsnehaprabha at ti.com>
> Cc: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
> ---
> 
> Found while debugging a NAND issue with a dm365.
> 
>  drivers/mtd/nand/davinci_nand.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
> index 2ac7367..53f864a 100644
> --- a/drivers/mtd/nand/davinci_nand.c
> +++ b/drivers/mtd/nand/davinci_nand.c
> @@ -369,8 +369,9 @@ compare:
>  	 * after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
>  	 * begin trying to poll for the state, you may fall right out of your
>  	 * loop without any of the correction calculations having taken place.
> -	 * The recommendation from the hardware team is to wait till ECC_STATE
> -	 * reads less than 4, which means ECC HW has entered correction state.
> +	 * The recommendation from the hardware team is to initially delay as
> +	 * long as ECC_STATE reads less than 4. After that, ECC HW has entered
> +	 * correction state.
>  	 */
>  	do {
>  		ecc_state = (davinci_nand_readl(info,
> -- 

Thanks for pointing this out, but I have already corrected this and submitted
the patch. Artem Bityutskity has pushed this patch to his l2-mtd-2.6 / master
tree.

Regards,
Sudhakar



From bengardiner at nanometrics.ca  Wed Aug 25 08:00:07 2010
From: bengardiner at nanometrics.ca (Ben Gardiner)
Date: Wed, 25 Aug 2010 09:00:07 -0400
Subject: need help- fw_printenv& fw_setenv
In-Reply-To: <201008251522.37921.caglarakyuz@gmail.com>
References: <DE1563FF5EF45A4794D1220EF0363CB4120CF8DD45@MTW02MSG02.mindtree.com>
	<201008251452.18749.caglarakyuz@gmail.com>
	<DE1563FF5EF45A4794D1220EF0363CB4120D20F538@MTW02MSG02.mindtree.com>
	<201008251522.37921.caglarakyuz@gmail.com>
Message-ID: <AANLkTimOYPRxwfKtGmWk3ti7f5zdu4RZ2N=YzY6eZUX6@mail.gmail.com>

On Wed, Aug 25, 2010 at 8:22 AM, Caglar Akyuz <caglarakyuz at gmail.com> wrote:
> On Wednesday 25 August 2010 03:14:07 pm Raghu Ramaraj wrote:
>> I have added the following lines in config file
>>
>> # MTD device name ? ? ? Device offset ? Env. size ? ? ? Flash sector size
>> ? ? ?Number of sectors #/dev/mtd0 ? ? ? ? ? ? ?0x0000 ? ? ? ? ?0x4000
>> ? ? 0x4000
>> #/dev/mtd1 ? ? ? ? ? ? ?0x4000 ? ? ? ? ?0x4000 ? ? ? ? ?0x4000
>> #/dev/mtd2 ? ? ? ? ? ? ?0x0000 ? ? ? ? ?0x4000 ? ? ? ? ?0x4000
>>
>> #/dev/mtd0 ? ? ? ? ? ? ?0x0000 ? ? ? ? ?0x4000 ? ? ? ? ?0x4000
>> #/dev/mtd1 ? ? ? ? ? ? ?0x4000 ? ? ? ? ?0x4000 ? ? ? ? ?0x4000
>>
>> # NAND example
>> #/dev/mtd0 ? ? ? ? ? ? ?0x0000 ? ? ? ? ?0x4000 ? ? ? ? ?0x4000
>> ? ? ?2 #/dev/mtd1 ? ? ? ? ? ? ?0x4000 ? ? ? ? ?0x4000 ? ? ? ? ?0x4000
>> ? ? ? ? ? ? 2
>>
>> #/dev/mtd1 ? ? ? ? ? ? ?0x0000 ? ? ? ? ?0x140000 ? ? ? ?0x4000
>> ? ? ?50 /dev/mtd0 ? ? ? ? ? ? ? 0x0000 ? ? ? ? ?0x20000 ? ? ? ? 0x20000
>>
>> Its giving " Segmentation fault"
>>
>
> I remember a bug in fw_printenv but I'm not sure if this is related to that
> bug or not. I reported this issue in a thread in this list. If you search the
> archives maybe that solution can help you as well.

I agree. I think there is a problem with older u-boots and fw_setenv
on NAND flash. I also got a segfault trying to do fw_setenv with the
u-boot that was I built with arago: u-boot-utils_1.2.0.bb from
99a23da17daa0303b3068522353618613fe06b83 of
git://arago-project.org/git/arago-oe-dev.git.

The problem was fixed by building fw_printenv from a recent u-boot and
installing it as 'fw_printenv' _and_ 'fw_setenv'. The utility is built
by the top-level 'env' target in (at least) u-boot 2010.03.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

From luna.id at gmail.com  Wed Aug 25 13:36:45 2010
From: luna.id at gmail.com (Nicolas Luna)
Date: Wed, 25 Aug 2010 14:36:45 -0400
Subject: Unhandled USB IRQ
Message-ID: <AANLkTimiEsspa9ZSt_7uO1YY3hbQkHjoMpDBPsm=hDmn@mail.gmail.com>

Hi,

I got this message when I disconnect usb key from my USB2.0 connector.

*da8xx_interrupt 514: Unhandled USB IRQ 00280000*

I'm on OMAPL138 with custum hardware based on EVM. I'm using khilman tree
Linux-2.6.34 with DA8xx glue layer and I modified my board specific files to
add usb 2.0 support.

Any idea what I could look at to correct this issue?

Also, I'll would like to know if its possible to use sda with usb2.0 and sdb
with usb1.1. I'm not using udev all my dev are static.

Thanks

Regards,
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100825/1640e880/attachment.html>

From sshtylyov at mvista.com  Wed Aug 25 13:50:19 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 25 Aug 2010 22:50:19 +0400
Subject: Unhandled USB IRQ
In-Reply-To: <AANLkTimiEsspa9ZSt_7uO1YY3hbQkHjoMpDBPsm=hDmn@mail.gmail.com>
References: <AANLkTimiEsspa9ZSt_7uO1YY3hbQkHjoMpDBPsm=hDmn@mail.gmail.com>
Message-ID: <4C7565EB.7020901@mvista.com>

Hello.

Nicolas Luna wrote:

> I got this message when I disconnect usb key from my USB2.0 connector. 

> */da8xx_interrupt 514: Unhandled USB IRQ 00280000/*

> I'm on OMAPL138 with custum hardware based on EVM. I'm using khilman 
> tree Linux-2.6.34 with DA8xx glue layer and I modified my board specific 
> files to add usb 2.0 support.

> Any idea what I could look at to correct this issue?

    The following patch from 2.6.35 should help:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=7d9645fdca444d53907b22a4b73e3967efe09781

> Also, I'll would like to know if its possible to use sda with usb2.0 and 
> sdb with usb1.1.

    Don't think so.

WBR, Sergei


From luna.id at gmail.com  Wed Aug 25 14:09:12 2010
From: luna.id at gmail.com (Nicolas Luna)
Date: Wed, 25 Aug 2010 15:09:12 -0400
Subject: Unhandled USB IRQ
In-Reply-To: <4C7565EB.7020901@mvista.com>
References: <AANLkTimiEsspa9ZSt_7uO1YY3hbQkHjoMpDBPsm=hDmn@mail.gmail.com>
	<4C7565EB.7020901@mvista.com>
Message-ID: <AANLkTi==-iAQL8Zi6JVDEX4mWr82MSfDU4fQ+DbWe6uQ@mail.gmail.com>

Thank you it solved the problem.

Regards,
Nicolas


On Wed, Aug 25, 2010 at 2:50 PM, Sergei Shtylyov <sshtylyov at mvista.com>wrote:

> Hello.
>
>
> Nicolas Luna wrote:
>
>  I got this message when I disconnect usb key from my USB2.0 connector.
>>
>
>  */da8xx_interrupt 514: Unhandled USB IRQ 00280000/*
>>
>
>  I'm on OMAPL138 with custum hardware based on EVM. I'm using khilman tree
>> Linux-2.6.34 with DA8xx glue layer and I modified my board specific files to
>> add usb 2.0 support.
>>
>
>  Any idea what I could look at to correct this issue?
>>
>
>   The following patch from 2.6.35 should help:
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=7d9645fdca444d53907b22a4b73e3967efe09781
>
>
>  Also, I'll would like to know if its possible to use sda with usb2.0 and
>> sdb with usb1.1.
>>
>
>   Don't think so.
>
> WBR, Sergei
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100825/754a8304/attachment.html>

From sudhakar.raj at ti.com  Wed Aug 25 22:59:56 2010
From: sudhakar.raj at ti.com (Sudhakar Rajashekhara)
Date: Thu, 26 Aug 2010 09:29:56 +0530
Subject: [RFC] nand/davinci: Fix comment to match the code
In-Reply-To: <1282740906.24044.210.camel@localhost>
References: <1282738700-30966-1-git-send-email-w.sang@pengutronix.de>	<039d01cb4450$e8f7d6a0$bae783e0$@raj@ti.com>
	<1282740906.24044.210.camel@localhost>
Message-ID: <045301cb44d3$2551fef0$6ff5fcd0$@raj@ti.com>

On Wed, Aug 25, 2010 at 18:25:06, Artem Bityutskiy wrote:
> On Wed, 2010-08-25 at 17:57 +0530, Sudhakar Rajashekhara wrote:
> > > --- a/drivers/mtd/nand/davinci_nand.c
> > > +++ b/drivers/mtd/nand/davinci_nand.c
> > > @@ -369,8 +369,9 @@ compare:
> > >  	 * after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
> > >  	 * begin trying to poll for the state, you may fall right out of your
> > >  	 * loop without any of the correction calculations having taken place.
> > > -	 * The recommendation from the hardware team is to wait till ECC_STATE
> > > -	 * reads less than 4, which means ECC HW has entered correction state.
> > > +	 * The recommendation from the hardware team is to initially delay as
> > > +	 * long as ECC_STATE reads less than 4. After that, ECC HW has entered
> > > +	 * correction state.
> > >  	 */
> > >  	do {
> > >  		ecc_state = (davinci_nand_readl(info,
> > > -- 
> > 
> > Thanks for pointing this out, but I have already corrected this and submitted
> > the patch. Artem Bityutskity has pushed this patch to his l2-mtd-2.6 / master
> > tree.
> 
> If you mean
> 
> commit 1c3275b656045aff9a75bb2c9f3251af1043ebb3
> Author: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
> Date:   Tue Jul 20 15:24:01 2010 -0700
> 
>     mtd: nand: davinci: correct 4-bit error correction
>     
>     On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
>     4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
>     before waiting for the NAND Flash status register to be equal to 1, 2 or
>     3, we have to wait till the ECC HW goes to correction state.  Without this
>     wait, ECC correction calculations will not be proper.
>     
>     This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
>     EVMs.
>     
>     Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
>     Acked-by: Sneha Narnakaje <nsnehaprabha at ti.com>
>     Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
>     Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
>     Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>
> 
> then it is already in upstream in Linus' tree. I do not have anything else from you.
> 

Yes, this was the patch I was talking about. But this patch seems little
different than the one I submitted to linux-mtd list at
http://patchwork.ozlabs.org/patch/59180/. But I can submit another patch
which corrects it. 

Wolfram Sang,
Do you agree that in the above link which shows the patch I have submitted,
the comment matches the code?

Regards,
Sudhakar



From khilman at deeprootsystems.com  Thu Aug 26 13:04:43 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 26 Aug 2010 11:04:43 -0700
Subject: [PATCH 0/6] davinci: add support for aemif timing configuration
In-Reply-To: <1281349000-822-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's
	message of "Mon, 9 Aug 2010 15:46:34 +0530")
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
Message-ID: <878w3t45dw.fsf@deeprootsystems.com>

Sekhar Nori <nsekhar at ti.com> writes:

> This series of patches adds support for AEMIF timing configuration
> for DaVinci SoCs.
>
> Currently AEMIF timing configuration is done as a special case for
> DM644x EVM. This work provides for a generic way of doing this.
>
> David,
> 	Patch 1/6 and 2/6 of this series touch the
> 	drivers/mtd/nand/davinci_nand.c file along with other arch specific
> 	files. Based on the discussion on DaVinci list, Kevin is OK to merge
> 	this with your agreement. Please let us know how to proceed.

David,

Can I go ahead and merge the 2 drivers/mtd/* patches in this series
along the rest of them when I merge this into the davinci tree?

Thanks,

Kevin


> Sekhar Nori (5):
>   davinci: add support for aemif timing configuration
>   nand: davinci: add support for timing configuration
>   davinci: dm644x evm: setup NAND flash timing
>   davinci: am18x/da850/omap-l138 evm: setup NAND flash timing
>   davinci: dm6467t evm: setup NAND flash timing
>
> Sudhakar Rajashekhara (1):
>   davinci: am17x/da830/omap-l137 evm: setup NAND flash timing
>
>  arch/arm/mach-davinci/Makefile             |    2 +-
>  arch/arm/mach-davinci/aemif.c              |  133 ++++++++++++++++++++++++++++
>  arch/arm/mach-davinci/board-da830-evm.c    |   12 +++
>  arch/arm/mach-davinci/board-da850-evm.c    |   12 +++
>  arch/arm/mach-davinci/board-dm644x-evm.c   |   12 +++
>  arch/arm/mach-davinci/board-dm646x-evm.c   |   14 +++
>  arch/arm/mach-davinci/include/mach/aemif.h |   36 ++++++++
>  arch/arm/mach-davinci/include/mach/nand.h  |    6 +-
>  drivers/mtd/nand/davinci_nand.c            |   61 +++++--------
>  9 files changed, 246 insertions(+), 42 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/aemif.c
>  create mode 100644 arch/arm/mach-davinci/include/mach/aemif.h

From khilman at deeprootsystems.com  Thu Aug 26 13:09:53 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 26 Aug 2010 11:09:53 -0700
Subject: [PATCH v2 0/3] Add support for second MMCSD controller for DA-850
In-Reply-To: <1282071408-1213-1-git-send-email-juha.kuikka@elektrobit.com>
	(Juha Kuikka's message of "Tue, 17 Aug 2010 11:56:45 -0700")
References: <1282071408-1213-1-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <871v9l455a.fsf@deeprootsystems.com>

Juha Kuikka <juha.kuikka at elektrobit.com> writes:

> This small patch series adds the second MMCSD controller as a platform
> device as well as the required resource definitions.
>
> Tested on a custom board with a WiFi peripheral.
>
> Thanks for comments Sekhar and Sergei.
>
> v2 changes:
> 	- No functional changes.
> 	- LPSC definition renamed to DA850_LPSC1_MMC_SD1
> 	- MMCSD1 base moved to devices-da8xx.c
> 	- File mode change removed.
> 	- Renamed resources from da8xx_* to da850_* as MMCSD1 
> 	  is only present on DA850
> 	- Renamed registration function to da850_register_mmcsd1()

Can you please add a small changelog to each of the patches please?

Thanks,

Kevin

> Juha Kuikka (3):
>   DA850: Add LPSC id for MMCSD1 peripheral
>   DA850: Split MMCSD clock into two to support both MMCSD peripherals
>   DA850: Add MMCSD1 resources, platform device and convenience
>     registration function
>
>  arch/arm/mach-davinci/da850.c              |   14 ++++++++--
>  arch/arm/mach-davinci/devices-da8xx.c      |   37 ++++++++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
>  arch/arm/mach-davinci/include/mach/psc.h   |    1 +
>  4 files changed, 50 insertions(+), 3 deletions(-)
>
>
>
> ----------------------------------------------------------------
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From khilman at deeprootsystems.com  Thu Aug 26 13:25:06 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 26 Aug 2010 11:25:06 -0700
Subject: [PATCH 1/5] arm: mach-davinci: check irq2ctlr() result
In-Reply-To: <1279379947-15152-1-git-send-email-segooon@gmail.com> (Kulikov
	Vasiliy's message of "Sat, 17 Jul 2010 19:19:07 +0400")
References: <1279379947-15152-1-git-send-email-segooon@gmail.com>
Message-ID: <87wrrd2pvh.fsf@deeprootsystems.com>

Kulikov Vasiliy <segooon at gmail.com> writes:

> If irq2ctlr() fails return IRQ_NONE.
> Also as it can fail make 'ctlr' signed.

[...]

> Signed-off-by: Kulikov Vasiliy <segooon at gmail.com>

Sorry for the lag on this one.

Queueing for 2.6.37 in linux-davinci.git

Kevin

From khilman at deeprootsystems.com  Thu Aug 26 13:39:05 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 26 Aug 2010 11:39:05 -0700
Subject: [PATCH 0/8] split out emac cpdma and mdio for reuse
In-Reply-To: <1280842313-3743-1-git-send-email-cyril@ti.com> (Cyril
	Chemparathy's message of "Tue, 3 Aug 2010 09:31:45 -0400")
References: <1280842313-3743-1-git-send-email-cyril@ti.com>
Message-ID: <87r5hl2p86.fsf@deeprootsystems.com>

Cyril Chemparathy <cyril at ti.com> writes:

> Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine.
> These hardware modules are not restricted to EMAC device alone.  For example,
> CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules
> internally.  This patch series separates out EMAC's MDIO and CPDMA
> functionality, allowing these individual pieces to be reused across TI
> hardware.  

Hi Cyril,

Another minor request for v2.  

The subject for the drivers/net/* patches should be something like
'net: davinci_emac: ..." instead of netdev.

Thanks,

Kevin

From chtpatil at gmail.com  Thu Aug 26 14:02:19 2010
From: chtpatil at gmail.com (chetan patil)
Date: Fri, 27 Aug 2010 00:32:19 +0530
Subject: ToolChain
Message-ID: <AANLkTikYtdUhYrdPqhm55YTy8k85LQ1TrL2WkEr-QhzX@mail.gmail.com>

In simple words can someone tell how to get started with environment or
toolchain for Davinci EVM 6446

I got fedora12.
Now what.



-- 
Regards,

Chetan Arvind Patil,
+919970018364
http://sites.google.com/site/chtpatil/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100827/a1874ebc/attachment.html>

From schen at mvista.com  Thu Aug 26 14:11:43 2010
From: schen at mvista.com (Steve Chen)
Date: Thu, 26 Aug 2010 14:11:43 -0500
Subject: ToolChain
In-Reply-To: <AANLkTikYtdUhYrdPqhm55YTy8k85LQ1TrL2WkEr-QhzX@mail.gmail.com>
References: <AANLkTikYtdUhYrdPqhm55YTy8k85LQ1TrL2WkEr-QhzX@mail.gmail.com>
Message-ID: <AANLkTimn0qx9xad_fuJDFVDQLk+P=7+C6=R__JymM+6v@mail.gmail.com>

On Thu, Aug 26, 2010 at 2:02 PM, chetan patil <chtpatil at gmail.com> wrote:
> In simple words can someone tell how to get started with environment or
> toolchain for Davinci EVM 6446

Google :-)

>
> I got fedora12.
> Now what.

May want to take a look here.

http://processors.wiki.ti.com/index.php/Linux_Toolchain

Regards,

Steve

From b.hutchman at gmail.com  Thu Aug 26 14:28:26 2010
From: b.hutchman at gmail.com (Brian Hutchinson)
Date: Thu, 26 Aug 2010 15:28:26 -0400
Subject: ToolChain
In-Reply-To: <AANLkTikYtdUhYrdPqhm55YTy8k85LQ1TrL2WkEr-QhzX@mail.gmail.com>
References: <AANLkTikYtdUhYrdPqhm55YTy8k85LQ1TrL2WkEr-QhzX@mail.gmail.com>
Message-ID: <AANLkTik8kbzNHhB8B9oE9HRRR8RMH85S_z22bePfVWSJ@mail.gmail.com>

On Thu, Aug 26, 2010 at 3:02 PM, chetan patil <chtpatil at gmail.com> wrote:
> In simple words can someone tell how to get started with environment or
> toolchain for Davinci EVM 6446
>
> I got fedora12.
> Now what.

If you want community tools (toolchain, kernel u-boot etc.) you might
want to take a look at:
http://processors.wiki.ti.com/index.php/Community_Linux_DVEVM_Software_Migration_Guide
http://processors.wiki.ti.com/index.php/UG:_DaVinci_PSP_Installation_on_DM644x_EVM

Regards,

Brian

From juha.kuikka at elektrobit.com  Thu Aug 26 14:40:46 2010
From: juha.kuikka at elektrobit.com (Juha Kuikka)
Date: Thu, 26 Aug 2010 12:40:46 -0700
Subject: [PATCH v3 2/3] DA850: Split MMCSD clock into two to support both
	MMCSD peripherals
In-Reply-To: <1282851647-14336-2-git-send-email-juha.kuikka@elektrobit.com>
References: <1282851647-14336-1-git-send-email-juha.kuikka@elektrobit.com>
	<1282851647-14336-2-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <1282851647-14336-3-git-send-email-juha.kuikka@elektrobit.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100826/9b38d94e/attachment.pl>

From juha.kuikka at elektrobit.com  Thu Aug 26 14:40:47 2010
From: juha.kuikka at elektrobit.com (Juha Kuikka)
Date: Thu, 26 Aug 2010 12:40:47 -0700
Subject: [PATCH v3 3/3] DA850: Add MMCSD1 resources,
	platform device and convenience registration function
In-Reply-To: <1282851647-14336-3-git-send-email-juha.kuikka@elektrobit.com>
References: <1282851647-14336-1-git-send-email-juha.kuikka@elektrobit.com>
	<1282851647-14336-2-git-send-email-juha.kuikka@elektrobit.com>
	<1282851647-14336-3-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <1282851647-14336-4-git-send-email-juha.kuikka@elektrobit.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100826/07b8ae11/attachment.pl>

From juha.kuikka at elektrobit.com  Thu Aug 26 14:40:44 2010
From: juha.kuikka at elektrobit.com (Juha Kuikka)
Date: Thu, 26 Aug 2010 12:40:44 -0700
Subject: [PATCH v3 0/3] Add support for second MMCSD controller for DA-850
Message-ID: <1282851647-14336-1-git-send-email-juha.kuikka@elektrobit.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100826/90cd3664/attachment.pl>

From juha.kuikka at elektrobit.com  Thu Aug 26 14:40:45 2010
From: juha.kuikka at elektrobit.com (Juha Kuikka)
Date: Thu, 26 Aug 2010 12:40:45 -0700
Subject: [PATCH v3 1/3] DA850: Add LPSC id for MMCSD1 peripheral
In-Reply-To: <1282851647-14336-1-git-send-email-juha.kuikka@elektrobit.com>
References: <1282851647-14336-1-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <1282851647-14336-2-git-send-email-juha.kuikka@elektrobit.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100826/495c33de/attachment.pl>

From khilman at deeprootsystems.com  Thu Aug 26 16:37:28 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 26 Aug 2010 14:37:28 -0700
Subject: [PATCH 3/3] davinci: Map sram using MT_MEMORY_NONCACHED instead
	of MT_DEVICE
In-Reply-To: <AANLkTi=9k19RUmfnNBO8AfFj_LtyNtsPPVYC_=-AW5yE@mail.gmail.com>
	(Kevin Hilman's message of "Thu, 19 Aug 2010 11:29:27 -0700")
References: <1281262702-27732-1-git-send-email-santosh.shilimkar@ti.com>
	<AANLkTi=9k19RUmfnNBO8AfFj_LtyNtsPPVYC_=-AW5yE@mail.gmail.com>
Message-ID: <87hbih2gyv.fsf@deeprootsystems.com>

Kevin Hilman <khilman at deeprootsystems.com> writes:

> On Sun, Aug 8, 2010 at 3:18 AM, Santosh Shilimkar
> <santosh.shilimkar at ti.com> wrote:
>> On Davinci SRAM is mapped as MT_DEVICE becasue of the section
>> mapping pre-requisite instead of intended MT_MEMORY_NONCACHED
>>
>> Since the section mapping limitation gets fixed with first
>> patch in this series, the MT_MEMORY_NONCACHED can be used now.
>>
>> Have not tested this, so somebody with Davinci hardware can
>> try this out
>>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: Kevin Hilman <khilman at deeprootsystems.com>
>
> Acked-by: Kevin Hilman <khilman at deeprootsystems.com>

Also, FYI... while not a very thorough test, I boot-tested this series
on DaVinci (dm355, omapl138) and it worked fine.

I'll include in davinci git (in the davinci-testing branch) so it gets a
bit more testing.

Kevin

From khilman at deeprootsystems.com  Thu Aug 26 17:25:13 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 26 Aug 2010 15:25:13 -0700
Subject: [PATCH v4] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <4C516634.5040804@criticallink.com> (Michael Williamson's message
	of "Thu, 29 Jul 2010 07:29:56 -0400")
References: <4C516634.5040804@criticallink.com>
Message-ID: <877hjd106u.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

>  This patch adds support for the MityDSP-L138 and MityARM-1808 system on
> module (SOM) under the registered machine "mityomapl138".  These SOMs
> are based on the da850 davinci CPU architecture.  Information on these
> SOMs may be found at http://www.mitydsp.com.
>
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
> ---
> This patch is against Kevin's tree, but is dependent on the following patch,
> which is queued for 2.6.36:
>
> [1] http://git.kernel.org/?p=linux/kernel/git/broonie/sound-2.6.git;a=commit;h=48519f0ae03bc7e86b3dc93e56f1334d53803770

Running this patch through scripts/checkpatch.pl, I get:

   total: 268 errors, 586 warnings, 1632 lines checked

Please fix all errors and warnings.

For future reference, normally, I don't even read the rest of a patch if
there are any checkpatch errors. 

> Changes since v3 patch was submitted:
>     * renamed ATAG_PERIPHERALS to ATAG_MITYDSPL138

This new ATAG should be a separate patch.

However, as I mentioned in earlier versions, new ATAGs are not welcome
upstream, and I will not merge this.  Other suggestions have been
proposed to solve this.

If you insist, after the bare board support is merged, you can post your
ATAG patch to linux-arm-kernel and see if Russell is willing to merge
this, but I doubt it.

>     * removed unused header files
>     * renamed config structure items to remove camel case naming
>     * don't use GPIO if resources aren't acquired
>     * don't use device_initcall on emac config
>     * handle upcoming patch to platform sound config
>     * clean up mcasp configuration
>     * misc cleanup per comments
>
>  arch/arm/configs/da8xx_omapl_defconfig             |  291 ++++++-

The defconfig change needs to be redone against current tree, since some
major changes where done here for 2.6.36.

>  arch/arm/include/asm/setup.h                       |    5 +
>  arch/arm/mach-davinci/Kconfig                      |    8 +
>  arch/arm/mach-davinci/Makefile                     |    1 +
>  arch/arm/mach-davinci/board-mityomapl138.c         |  806 ++++++++++++++++++++
>  .../mach-davinci/include/mach/cb-mityomapl138.h    |  120 +++
>  arch/arm/mach-davinci/include/mach/da8xx.h         |    1 +
>  arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
>  8 files changed, 1190 insertions(+), 43 deletions(-)

Normally, I like to see new board support broken down more.  It's rather
difficult to do a good review of new board file when everything is added
in a single patch.

Typically, a basic patch that just supports basic boot (typically to
UART console) is the first patch.  Then additional patches are added to
add peripheral support (display, MMC, SPI, flash, regulators, ...)

Breaking things up this way helps reviewers and maintainers greatly.

[...]

> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> index f392fb4..1d3a8cf 100644
> --- a/arch/arm/include/asm/setup.h
> +++ b/arch/arm/include/asm/setup.h
> @@ -143,6 +143,11 @@ struct tag_memclk {
>      __u32 fmemclk;
>  };
>  
> +/** MityDSP-L138 peripheral configuration info,

please fix multi-line comment style.  search for 'multi-line' in
Documentation/CodingStytle.  There are several instances of this problem
in the patch.

> +  *  see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
> +  */
> +#define ATAG_MITYDSPL138 0x42000101
> +
>  struct tag {
>      struct tag_header hdr;
>      union {
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 71f90f8..8fcf47d 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -178,6 +178,14 @@ config DA850_UI_RMII
>  
>  endchoice
>  
> +config MACH_MITYOMAPL138
> +    bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
> +    depends on ARCH_DAVINCI_DA850
> +    help
> +      Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
> +      System on Module.  Information on this SoM may be found at
> +      http://www.mitydsp.com.
> +
>  config MACH_TNETV107X
>      bool "TI TNETV107X Reference Platform"
>      default ARCH_DAVINCI_TNETV107X
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index eab4c0f..dfc0fc4 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)    += board-dm646x-evm.o cdce949.o
>  obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)    += board-dm365-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)    += board-da830-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)    += board-da850-evm.o
> +obj-$(CONFIG_MACH_MITYOMAPL138)    += board-mityomapl138.o
>  obj-$(CONFIG_MACH_TNETV107X)        += board-tnetv107x-evm.o
>  
>  # Power Management
> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> new file mode 100644
> index 0000000..57a4ab4
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> @@ -0,0 +1,806 @@
> +/*
> + * Critical Link MityOMAP-L138 SoM
> + *
> + * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
> + *
> + * Derived from board-da850-evm.c
> + * Original Copyrights follow:
> + *
> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * Derived from: arch/arm/mach-davinci/board-da830-evm.c
> + * Original Copyrights follow:
> + *
> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +
> +#define pr_fmt(fmt) "%s: " fmt, __func__

I don't find any users of this in the patch.  Please remove.

> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/i2c.h>
> +#include <linux/i2c/at24.h>

I don't think you need at24.h here.  Please remove any headers that you
are not actually using.

[...]

Kevin

From khilman at deeprootsystems.com  Thu Aug 26 17:39:56 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 26 Aug 2010 15:39:56 -0700
Subject: [PATCH v3 0/3] Add support for second MMCSD controller for DA-850
In-Reply-To: <1282851647-14336-1-git-send-email-juha.kuikka@elektrobit.com>
	(Juha Kuikka's message of "Thu, 26 Aug 2010 12:40:44 -0700")
References: <1282851647-14336-1-git-send-email-juha.kuikka@elektrobit.com>
Message-ID: <87wrrdyp4z.fsf@deeprootsystems.com>

Juha Kuikka <juha.kuikka at elektrobit.com> writes:

> This small patch series adds the second MMCSD controller as a platform
> device as well as the required resource definitions.
>
> Tested on a custom board with a WiFi peripheral.

Thanks, applying and queuing for 2.6.37

Kevin

> Thanks for comments Sekhar, Sergei and Kevin.
>
> v3 changes:
> 	- No functional changes
> 	- Moved DA850_MMCSD1_BASE definition to keep list sorted
> 	- Enclosed DA850 specific resources in #ifdef CONFIG_ARCH_DAVINCI_DA850
> 	- Added changelog texts to patch bodies.
>
> v2 changes:
>         - No functional changes.
>         - LPSC definition renamed to DA850_LPSC1_MMC_SD1
>         - MMCSD1 base moved to devices-da8xx.c
>         - File mode change removed.
>         - Renamed resources from da8xx_* to da850_* as MMCSD1
>           is only present on DA850
>         - Renamed registration function to da850_register_mmcsd1()
>
>
> *** BLURB HERE ***
>
> Juha Kuikka (3):
>   DA850: Add LPSC id for MMCSD1 peripheral
>   DA850: Split MMCSD clock into two to support both MMCSD peripherals
>   DA850: Add MMCSD1 resources, platform device and convenience
>     registration function
>
>  arch/arm/mach-davinci/da850.c              |   14 ++++++++--
>  arch/arm/mach-davinci/devices-da8xx.c      |   39 ++++++++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
>  arch/arm/mach-davinci/include/mach/psc.h   |    1 +
>  4 files changed, 52 insertions(+), 3 deletions(-)
>
>
>
> ----------------------------------------------------------------
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From khilman at deeprootsystems.com  Thu Aug 26 17:44:04 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Thu, 26 Aug 2010 15:44:04 -0700
Subject: davinci git updated to v2.6.36-rc2, patchwork updated
Message-ID: <87lj7tyoy3.fsf@deeprootsystems.com>

Hello,

FYI... davinci git has been updated to be based on v2.6.36-rc2.  The
previous 2.6.35-based kernel was tagged v2.6.35-davinci1.

Also, I've finally caught up to the queue of patches waiting for me in
patchwork[1].  The only ones pending now are those where I'm waiting
some feedback/status from other subsystem maintainers.

If you've sent a patch which hasn't been merged or hasn't received
comments, please yell at me (and then re-post)  :)

Kevin

[1]   https://patchwork.kernel.org/project/linux-davinci/list/

From michael.williamson at criticallink.com  Thu Aug 26 19:12:27 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu, 26 Aug 2010 20:12:27 -0400
Subject: [PATCH v4] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <877hjd106u.fsf@deeprootsystems.com>
References: <4C516634.5040804@criticallink.com>
	<877hjd106u.fsf@deeprootsystems.com>
Message-ID: <4C7702EB.8040905@criticallink.com>

Hi Kevin,

On 08/26/2010 06:25 PM, Kevin Hilman wrote:
> Michael Williamson<michael.williamson at criticallink.com>  writes:
>
>    
>>   This patch adds support for the MityDSP-L138 and MityARM-1808 system on
>> module (SOM) under the registered machine "mityomapl138".  These SOMs
>> are based on the da850 davinci CPU architecture.  Information on these
>> SOMs may be found at http://www.mitydsp.com.
>>
>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
>> ---
>> This patch is against Kevin's tree, but is dependent on the following patch,
>> which is queued for 2.6.36:
>>
>> [1] http://git.kernel.org/?p=linux/kernel/git/broonie/sound-2.6.git;a=commit;h=48519f0ae03bc7e86b3dc93e56f1334d53803770
>>      
> Running this patch through scripts/checkpatch.pl, I get:
>
>     total: 268 errors, 586 warnings, 1632 lines checked
>
> Please fix all errors and warnings.
>
> For future reference, normally, I don't even read the rest of a patch if
> there are any checkpatch errors.
>
>    

As expected. At the time I submitted this (before your comments came in
on V3, actually), I had run a checkpatch.pl and it had passed.  That was
prior to the 2.6.35 merge when you got back from vacation.  Given your
comments on V3, I had withdrawn the submission.  This submission should
have been dropped.  I'm sorry if I generated extra reviewing work for you.
I didn't catch that our thread of discussion was on the V3 submission.

Please drop all submissions relating to this subject.  If there was 
something
more I should have done, please let me know.

>> Changes since v3 patch was submitted:
>>      * renamed ATAG_PERIPHERALS to ATAG_MITYDSPL138
>>      
> This new ATAG should be a separate patch.
>
> However, as I mentioned in earlier versions, new ATAGs are not welcome
> upstream, and I will not merge this.  Other suggestions have been
> proposed to solve this.
>
> If you insist, after the bare board support is merged, you can post your
> ATAG patch to linux-arm-kernel and see if Russell is willing to merge
> this, but I doubt it.
>    

Understood.  Not trying to use this ATAG patch for the mainline anymore,
trying other techniques but not ready for resubmission.
>    
>>      * removed unused header files
>>      * renamed config structure items to remove camel case naming
>>      * don't use GPIO if resources aren't acquired
>>      * don't use device_initcall on emac config
>>      * handle upcoming patch to platform sound config
>>      * clean up mcasp configuration
>>      * misc cleanup per comments
>>
>>   arch/arm/configs/da8xx_omapl_defconfig             |  291 ++++++-
>>      
> The defconfig change needs to be redone against current tree, since some
> major changes where done here for 2.6.36.
>    
I saw that go by.  If I get around to a resubmission, I'll be sure to 
sync up.
>    
>>   arch/arm/include/asm/setup.h                       |    5 +
>>   arch/arm/mach-davinci/Kconfig                      |    8 +
>>   arch/arm/mach-davinci/Makefile                     |    1 +
>>   arch/arm/mach-davinci/board-mityomapl138.c         |  806 ++++++++++++++++++++
>>   .../mach-davinci/include/mach/cb-mityomapl138.h    |  120 +++
>>   arch/arm/mach-davinci/include/mach/da8xx.h         |    1 +
>>   arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
>>   8 files changed, 1190 insertions(+), 43 deletions(-)
>>      
> Normally, I like to see new board support broken down more.  It's rather
> difficult to do a good review of new board file when everything is added
> in a single patch.
>
> Typically, a basic patch that just supports basic boot (typically to
> UART console) is the first patch.  Then additional patches are added to
> add peripheral support (display, MMC, SPI, flash, regulators, ...)
>
> Breaking things up this way helps reviewers and maintainers greatly.
>
> [...]
>    
OK.  Most of the board file is a large cut-and-paste of the da850
EVM.  It seems unlikely that I'll have any measure of success here, but if
I get time I might try again.

>    
>> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
>> index f392fb4..1d3a8cf 100644
>> --- a/arch/arm/include/asm/setup.h
>> +++ b/arch/arm/include/asm/setup.h
>> @@ -143,6 +143,11 @@ struct tag_memclk {
>>       __u32 fmemclk;
>>   };
>>
>> +/** MityDSP-L138 peripheral configuration info,
>>      
> please fix multi-line comment style.  search for 'multi-line' in
> Documentation/CodingStytle.  There are several instances of this problem
> in the patch.
>
>    
OK.  I'll watch for that if I resubmit.  Thanks.
>> +  *  see arch/arm/mach-davinci/include/mach/cb-mityomapl138.h
>> +  */
>> +#define ATAG_MITYDSPL138 0x42000101
>> +
>>   struct tag {
>>       struct tag_header hdr;
>>       union {
>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>> index 71f90f8..8fcf47d 100644
>> --- a/arch/arm/mach-davinci/Kconfig
>> +++ b/arch/arm/mach-davinci/Kconfig
>> @@ -178,6 +178,14 @@ config DA850_UI_RMII
>>
>>   endchoice
>>
>> +config MACH_MITYOMAPL138
>> +    bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
>> +    depends on ARCH_DAVINCI_DA850
>> +    help
>> +      Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
>> +      System on Module.  Information on this SoM may be found at
>> +      http://www.mitydsp.com.
>> +
>>   config MACH_TNETV107X
>>       bool "TI TNETV107X Reference Platform"
>>       default ARCH_DAVINCI_TNETV107X
>> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
>> index eab4c0f..dfc0fc4 100644
>> --- a/arch/arm/mach-davinci/Makefile
>> +++ b/arch/arm/mach-davinci/Makefile
>> @@ -32,6 +32,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM6467_EVM)    += board-dm646x-evm.o cdce949.o
>>   obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)    += board-dm365-evm.o
>>   obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)    += board-da830-evm.o
>>   obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)    += board-da850-evm.o
>> +obj-$(CONFIG_MACH_MITYOMAPL138)    += board-mityomapl138.o
>>   obj-$(CONFIG_MACH_TNETV107X)        += board-tnetv107x-evm.o
>>
>>   # Power Management
>> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
>> new file mode 100644
>> index 0000000..57a4ab4
>> --- /dev/null
>> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
>> @@ -0,0 +1,806 @@
>> +/*
>> + * Critical Link MityOMAP-L138 SoM
>> + *
>> + * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
>> + *
>> + * Derived from board-da850-evm.c
>> + * Original Copyrights follow:
>> + *
>> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * Derived from: arch/arm/mach-davinci/board-da830-evm.c
>> + * Original Copyrights follow:
>> + *
>> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
>> + * the terms of the GNU General Public License version 2. This program
>> + * is licensed "as is" without any warranty of any kind, whether express
>> + * or implied.
>> + */
>> +
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
>>      
> I don't find any users of this in the patch.  Please remove.
>
>    
OK.  Thanks (I had another comment recommending I use that).
>> +#include<linux/kernel.h>
>> +#include<linux/init.h>
>> +#include<linux/console.h>
>> +#include<linux/i2c.h>
>> +#include<linux/i2c/at24.h>
>>      
> I don't think you need at24.h here.  Please remove any headers that you
> are not actually using.
>
> [...]
>
> Kevin
>    
Thanks.



From santosh.shilimkar at ti.com  Thu Aug 26 23:46:54 2010
From: santosh.shilimkar at ti.com (Shilimkar, Santosh)
Date: Fri, 27 Aug 2010 10:16:54 +0530
Subject: [PATCH 3/3] davinci: Map sram using MT_MEMORY_NONCACHED instead
	of MT_DEVICE
In-Reply-To: <87hbih2gyv.fsf@deeprootsystems.com>
References: <1281262702-27732-1-git-send-email-santosh.shilimkar@ti.com>
	<AANLkTi=9k19RUmfnNBO8AfFj_LtyNtsPPVYC_=-AW5yE@mail.gmail.com>
	<87hbih2gyv.fsf@deeprootsystems.com>
Message-ID: <EAF47CD23C76F840A9E7FCE10091EFAB02CCA86A68@dbde02.ent.ti.com>

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at deeprootsystems.com]
> Sent: Friday, August 27, 2010 3:07 AM
> To: Shilimkar, Santosh
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: [PATCH 3/3] davinci: Map sram using MT_MEMORY_NONCACHED
> instead of MT_DEVICE
> 
> Kevin Hilman <khilman at deeprootsystems.com> writes:
> 
> > On Sun, Aug 8, 2010 at 3:18 AM, Santosh Shilimkar
> > <santosh.shilimkar at ti.com> wrote:
> >> On Davinci SRAM is mapped as MT_DEVICE becasue of the section
> >> mapping pre-requisite instead of intended MT_MEMORY_NONCACHED
> >>
> >> Since the section mapping limitation gets fixed with first
> >> patch in this series, the MT_MEMORY_NONCACHED can be used now.
> >>
> >> Have not tested this, so somebody with Davinci hardware can
> >> try this out
> >>
> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> >> Cc: davinci-linux-open-source at linux.davincidsp.com
> >> Cc: Kevin Hilman <khilman at deeprootsystems.com>
> >
> > Acked-by: Kevin Hilman <khilman at deeprootsystems.com>
> 
> Also, FYI... while not a very thorough test, I boot-tested this series
> on DaVinci (dm355, omapl138) and it worked fine.
> 
> I'll include in davinci git (in the davinci-testing branch) so it gets a
> bit more testing.

Thanks a lot Kevin!!

Tony, 
Can you merge this in lo master as well. Actually I want all these
3 patches go together so that it doesn't break OMAP/DAVINCI.

Regards,
Santosh

From nsekhar at ti.com  Fri Aug 27 01:32:59 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 27 Aug 2010 12:02:59 +0530
Subject: [PATCH v2 RESEND] rtc: omap: let device wakeup capability be
	configured from chip init logic
Message-ID: <1282890779-21536-1-git-send-email-nsekhar@ti.com>

The rtc-omap driver currently hardcodes the RTC wakeup capability
to be "not capable". While this seems to be true for existing OMAP1
boards which are not wired for this, the DA850/OMAP-L138 SoC, the
RTC can always be wake up source from its "deep sleep" mode.

This patch lets the wakeup capability to be set from platform data and
does not override the setting from the driver. For DA850/OMAP-L138, this
is done from arch/arm/mach-davinci/devices-da8xx.c:da8xx_register_rtc()

Note that this patch does not change the behavior on any existing OMAP1
board since the platform device registration sets the wakeup capability
to 0 by default.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Kevin Hilman <khilman at deeprootsystems.com>
---
Resending this patch since it was not merged anywhere. The previous discussion
on this patch is here: http://groups.google.com/group/rtc-linux/browse_thread/thread/25c76c71c8ec9f70/9fe51fa05e09c657

 drivers/rtc/rtc-omap.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 64d9727..73377b0 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -34,7 +34,8 @@
  * Board-specific wiring options include using split power mode with
  * RTC_OFF_NOFF used as the reset signal (so the RTC won't be reset),
  * and wiring RTC_WAKE_INT (so the RTC alarm can wake the system from
- * low power modes).  See the BOARD-SPECIFIC CUSTOMIZATION comment.
+ * low power modes) for OMAP1 boards (OMAP-L138 has this built into
+ * the SoC). See the BOARD-SPECIFIC CUSTOMIZATION comment.
  */
 
 #define OMAP_RTC_BASE			0xfffb4800
@@ -401,16 +402,17 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	/* BOARD-SPECIFIC CUSTOMIZATION CAN GO HERE:
 	 *
-	 *  - Boards wired so that RTC_WAKE_INT does something, and muxed
-	 *    right (W13_1610_RTC_WAKE_INT is the default after chip reset),
-	 *    should initialize the device wakeup flag appropriately.
+	 *  - Device wake-up capability setting should come through chip
+	 *    init logic. OMAP1 boards should initialize the "wakeup capable"
+	 *    flag in the platform device if the board is wired right for
+	 *    being woken up by RTC alarm. For OMAP-L138, this capability
+	 *    is built into the SoC by the "Deep Sleep" capability.
 	 *
 	 *  - Boards wired so RTC_ON_nOFF is used as the reset signal,
 	 *    rather than nPWRON_RESET, should forcibly enable split
 	 *    power mode.  (Some chip errata report that RTC_CTRL_SPLIT
 	 *    is write-only, and always reads as zero...)
 	 */
-	device_init_wakeup(&pdev->dev, 0);
 
 	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
 		pr_info("%s: split power mode\n", pdev->name);
-- 
1.6.2.4


From nsekhar at ti.com  Fri Aug 27 03:44:03 2010
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 27 Aug 2010 14:14:03 +0530
Subject: [PATCH] davinci: dm365 evm: use EDMAQ_3 as the audio DMA queue
Message-ID: <1282898643-10565-1-git-send-email-nsekhar@ti.com>

By default the audio driver uses EDMAQ_0 as the DMA queue,
but on DM365 this queue is specially designed for video
transfers with a large fifo size. Having both audio and
video transfers on the same queue leads to noise on the
audio side.

This patch changes the audio queue number for DM365 to
EDMAQ_3.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-dm365-evm.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 5bb86b2..60c59dd 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -175,7 +175,9 @@ static struct at24_platform_data eeprom_info = {
 	.context	= (void *)0x7f00,
 };
 
-static struct snd_platform_data dm365_evm_snd_data;
+static struct snd_platform_data dm365_evm_snd_data = {
+	.asp_chan_q = EVENTQ_3,
+};
 
 static struct i2c_board_info i2c_info[] = {
 	{
-- 
1.6.2.4


From ozanyusufoglu at hotmail.com  Fri Aug 27 05:38:09 2010
From: ozanyusufoglu at hotmail.com (=?UTF-8?B?w5Z6Z8O8ciBPemFu?=)
Date: Fri, 27 Aug 2010 13:38:09 +0300
Subject: Fwd: Re: DM6446 Drivers
Message-ID: <BLU0-SMTP996D2CC83DEC5B7725F1C2A8860@phx.gbl>



-------- Original Message --------
Subject: 	Re: DM6446 Drivers
Date: 	Wed, 25 Aug 2010 15:47:06 +0000 (GMT)
From: 	rohan tabish <rohan_javed at yahoo.co.uk>
To: 	?zg?r Ozan <ozanyusufoglu at hotmail.com>



Well i have don't alot of development of on TMS320DM6446 and written 
drivers for many peripherial Like spi, VLYNQ and audio serial port i 
havn't used video perperials but i can use them u can tel what you 
actually developing i can help you in writing Linux driver for the video 
perhperials. I can provide help with the code composer version also man...

Thanks
Rohan Tabish

--- On *Wed, 25/8/10, ?zg?r Ozan /<ozanyusufoglu at hotmail.com>/* wrote:


    From: ?zg?r Ozan <ozanyusufoglu at hotmail.com>
    Subject: Re: DM6446 Drivers
    To: "rohan tabish" <rohan_javed at yahoo.co.uk>
    Date: Wednesday, 25 August, 2010, 14:50

    Thank you for kind reply,Rohan. I am from Istanbul,Turkey. As I
    mentioned in mail,I'm developing a STB firmware, so I need a kernel
    which of video drivers work flawless. I read almost all of TI's
    documents but it's hard to bring all thus instructions together. Some of
    my questions may sound silly to you but I'm a newbie you know,forgive
    me :) Now, drivers  what are occupying my mind. I dont know which
    package I have to use with whic kernel . There are LSP and PSP, what are
    differences between them ? Can I use LSP with my davinci-Git-kernel or
    just use PSP for open-source. DOes PSP involve DVDSK content like DSP
    tools etc. And shall we understand  just Linux Davinci git kernel when
    we say open source  Davinci kernel, or is there any alternative ? I will
    be pleasent if you enlighten me about this issues, you can just show me
    where to start,point some documents.

    Best Regards.

    24-08-2010 17:32, rohan tabish yazm??:
>
>     First of all I wil say not to wory man there are alot of things
>     that u wil learn with courage most of the source is open source u
>     can use the git kernel i have also used the git kernel i have also
>     done development with DSP.you can ask me any help you want man.
>
>     BTW where are u from
>
>     Regard's
>
>
>     --- On *Tue, 24/8/10, ?zg?r Ozan Yusufo?lu
>     /<ozanyusufoglu at hotmail.com>
>     </mc/compose?to=ozanyusufoglu at hotmail.com>/* wrote:
>
>
>         From: ?zg?r Ozan Yusufo?lu <ozanyusufoglu at hotmail.com>
>         </mc/compose?to=ozanyusufoglu at hotmail.com>
>         Subject: DM6446 Drivers
>         To: davinci-linux-open-source at linux.davincidsp.com
>         </mc/compose?to=davinci-linux-open-source at linux.davincidsp.com>
>         Date: Tuesday, 24 August, 2010, 12:38
>
>         Hi, I'm a novice embedded engineer who works in a IPTV STB
>         project. We are using a DaVinci DM6446 based evaluation board
>         for developing a firmware for our STB.  Unfortunetaly I am the
>         only engineer who work in the software development side, and 
>         don't have enough backround to deal with problems which I
>         encountered.  Could you please enlighten me about these issues
>
>         1. I will use the open source Linux DaVinci kernel for
>         development, and I didn't understand the driver side, in
>         documents of TI its been said that LSP is integrated with
>         Montavista kernel, is it still available to use LSP with open
>         community Linux kernel? If it is,how can I do this?
>
>         2. Is there any pre-builded open source Linux kernel that all
>         these drivers work completely within ?
>
>         3. It seems that the video-display  driver not functional  for
>         Dm644x, in the
>         http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel
>
>         4. What is the difference between LSP and PSP.  I couldn't
>         find any document that gives detail about these issues . Could
>         you give me any advice about where to start
>         _______________________________________________
>         Davinci-linux-open-source mailing list
>         Davinci-linux-open-source at linux.davincidsp.com
>         http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100827/8160a024/attachment-0001.html>

From michael.williamson at criticallink.com  Fri Aug 27 06:12:57 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Fri, 27 Aug 2010 07:12:57 -0400
Subject: [PATCH v4] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <4C7702EB.8040905@criticallink.com>
References: <4C516634.5040804@criticallink.com>
	<877hjd106u.fsf@deeprootsystems.com>
	<4C7702EB.8040905@criticallink.com>
Message-ID: <4C779DB9.20107@criticallink.com>

On 08/26/2010 08:12 PM, Michael Williamson wrote:
> Hi Kevin,
>
> On 08/26/2010 06:25 PM, Kevin Hilman wrote:
>> Michael Williamson<michael.williamson at criticallink.com>  writes:
>>
>>>   This patch adds support for the MityDSP-L138 and MityARM-1808 
>>> system on
>>> module (SOM) under the registered machine "mityomapl138".  These SOMs
>>> are based on the da850 davinci CPU architecture.  Information on these
>>> SOMs may be found at http://www.mitydsp.com.
>>>
>>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
>>> ---
>>> This patch is against Kevin's tree, but is dependent on the 
>>> following patch,
>>> which is queued for 2.6.36:
>>>
>>> [1] 
>>> http://git.kernel.org/?p=linux/kernel/git/broonie/sound-2.6.git;a=commit;h=48519f0ae03bc7e86b3dc93e56f1334d53803770 
>>>
>> Running this patch through scripts/checkpatch.pl, I get:
>>
>>     total: 268 errors, 586 warnings, 1632 lines checked
>>
>> Please fix all errors and warnings.
>>
>> For future reference, normally, I don't even read the rest of a patch if
>> there are any checkpatch errors.
>>
>
> As expected. At the time I submitted this (before your comments came in
> on V3, actually), I had run a checkpatch.pl and it had passed.  That was
> prior to the 2.6.35 merge when you got back from vacation.
That should have read 2.6.36.  I also must have blown the checkpatch as 
well.

-Mike




From nsekhar at ti.com  Fri Aug 27 08:11:26 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 27 Aug 2010 18:41:26 +0530
Subject: [PATCH v4] DaVinci: dm365: Added clockout2 management.
In-Reply-To: <AANLkTikp9edCR4-fnbXmXi_+Kv7SVLGM5+4LtoXSZRCQ@mail.gmail.com>
References: <1281020128-5947-1-git-send-email-lamiaposta71@gmail.com>
	<87k4o4suym.fsf@deeprootsystems.com>
	<AANLkTi=YN-0k1cFHsx+RBtOEPcSObKeHKD2BZd=tqYnn@mail.gmail.com>
	<AANLkTikp9edCR4-fnbXmXi_+Kv7SVLGM5+4LtoXSZRCQ@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301F6614D13@dbde02.ent.ti.com>

Hi Raffaele,

Can you please set your gmail to use plain text instead of HTML?

On Tue, Aug 24, 2010 at 14:22:59, Raffaele Recalcati wrote:
> Sorry, please integrate the previous e-mail with this one...
> (I made a mistake sending the e-mail)
>
>
>
>
>               > -Solving a possible race when writing PERI_CLKCTL, see
> Nori Sekhar explanation:
>               > "Looks like the same register supports setting clocks
> for voice codec
>               > and keyscan module as well. This can cause a race if
> those clocks are
>               > modified in a different context. Can you extend this
> function to cover
>               > those clocks as well? May be clk->lpsc can be used to
> determine if div1,
>               > div2 or div3 need to be changed. This way you can
> serialize the setting
>               > up of these clocks."
>
>
>               I agree with Sekhar. This needs to be addresed before
> this patch is mergable.
>
>
>
>       It is more difficult.
>       Something like the following?
>
>
>
> int dm365_peri_clkctl_set_rate(struct clk *clk, unsigned long rate)
> {
>         int i;
>         unsigned long input;
>         unsigned ratio;
>         unsigned regval;
>         void __iomem *system_module_base;
>
>         /* There must be a parent... */
>         if (WARN_ON(!clk->parent))
>                 return -EINVAL;
>
>         input = clk->parent->rate;
>
>         if (input > rate)
>                 ratio = DIV_ROUND_UP(input, rate) - 1;
>
>
>         system_module_base = ioremap(DAVINCI_SYSTEM_MODULE_BASE, SZ_4K);
>         regval = __raw_readl(system_module_base + PERI_CLKCTL);
>
>         switch (clk->lpsc) {
>         case DM365_LPSC_CLKOUT2:
>               regval &= ~DIV1_MASK;
>               regval |= ratio << 3;
>               break;
>         case DM365_LPSC_VOICE_CODEC:
>               regval &= ~DIV2_MASK;
>               regval |= ratio << 7;
>               break;
>         case DM365_LPSC_KEYSCAN:
>             regval &= ~DIV3_MASK;
>               regval |= ratio << 16;
>               break;

This is similar to what I had in mind. No need of _LPSC_ in the
defines though, I think. DM365_PERICLK_CLKOUT2 is more readable.

>
>         /* to make changes work stop CLOCKOUT & start it again */
>         regval |= BIT(CLOCKOUT2EN);

This should only be done in the case of "DM365_PERICLK_CLKOUT2"?

>
>
>        mutex_lock(&peri_clkctl_mutex);

This mutex should not be needed. clk->set_rate is already called in
atomic context. Just need to make sure the PERI_CLKCTL register isn't
programmed from some stray code somewhere else. If there are instances
of that, those need to be converted to use the clk_set_rate() API.

Miguel, can you please highlight any instances you may know?

Thanks,
Sekhar


From schen at mvista.com  Fri Aug 27 08:49:09 2010
From: schen at mvista.com (Steve Chen)
Date: Fri, 27 Aug 2010 08:49:09 -0500
Subject: DM6446 Drivers
In-Reply-To: <BLU0-SMTP18427D9078C7C98DD588974A8830@phx.gbl>
References: <BLU0-SMTP18427D9078C7C98DD588974A8830@phx.gbl>
Message-ID: <AANLkTinuX2BP1Rc3UvaaA+f=B+_1-bKD3aPqByF0URK1@mail.gmail.com>

2010/8/24 ?zg?r Ozan Yusufo?lu <ozanyusufoglu at hotmail.com>:
> Hi, I'm a novice embedded engineer who works in a IPTV STB project. We are
> using a DaVinci DM6446 based evaluation board for developing a firmware for
> our STB. ?Unfortunetaly I am the only engineer who work in the software
> development side, and ?don't have enough backround to deal with problems
> which I encountered. ?Could you please enlighten me about these issues
>
> 1. I will use the open source Linux DaVinci kernel for development, and I
> didn't understand the driver side, in documents of TI its been said that LSP
> is integrated with Montavista kernel, is it still available to use LSP with
> open community Linux kernel? If it is,how can I do this?

LSP (Linux Support Package) is a term Monta Vista uses for all the
software packages you need to boot Linux on a board.  This includes
kernel, cross compiler, file system (libraries, binutils, userland,
etc.)  Last time I tried it (well over a year ago), I was able to
compile open source kernel with MV toolchain and boot the MV
filesystem.

>
> 2. Is there any pre-builded open source Linux kernel that all these drivers
> work completely within ?

Google for TI arago project, you should be able to find a lot of
useful information.

>
> 3. It seems that the video-display ?driver not functional ?for Dm644x, in
> the http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel

There are 2 open source kernels for DaVinci.  First is the the git
tree maintained by Kevin Hilman, and the second is the Arago project
maintained by TI.  Updates from the Arago project eventually migrated
to Kevin's tree.  In other words, Arago project's kernel is more
up-to-date, but it has more code churn.

I understand the video driver works for Arago tree, so you may want to
try it.  There are a number of video experts from TI that are quite
active in the mailing list.  They may be able to give you some
pointers if you have specific questions.

>
> 4. What is the difference between LSP and PSP. ?I couldn't find any document
> that gives detail about these issues . Could you give me any advice about
> where to start

LSP is a MontaVista term.  PSP is a TI term, so I'll leave it TIers to
provide the proper definition.

Regards,

Steve

From khilman at deeprootsystems.com  Fri Aug 27 09:11:58 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 27 Aug 2010 07:11:58 -0700
Subject: [PATCH v4] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <4C7702EB.8040905@criticallink.com> (Michael Williamson's message
	of "Thu, 26 Aug 2010 20:12:27 -0400")
References: <4C516634.5040804@criticallink.com>
	<877hjd106u.fsf@deeprootsystems.com>
	<4C7702EB.8040905@criticallink.com>
Message-ID: <8762ywrvpt.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

>> Normally, I like to see new board support broken down more.  It's rather
>> difficult to do a good review of new board file when everything is added
>> in a single patch.
>>
>> Typically, a basic patch that just supports basic boot (typically to
>> UART console) is the first patch.  Then additional patches are added to
>> add peripheral support (display, MMC, SPI, flash, regulators, ...)
>>
>> Breaking things up this way helps reviewers and maintainers greatly.
>>
>> [...]
>>    
> OK.  Most of the board file is a large cut-and-paste of the da850
> EVM.  It seems unlikely that I'll have any measure of success here, but if
> I get time I might try again.

OK, if it's mostly a cut-and-paste of da850, then maybe just break it up
into two patches, 1) the cut, paste & rename patch and 2) a separate
patch for things that are different on your board.

Thanks,

Kevin

From khilman at deeprootsystems.com  Fri Aug 27 09:14:48 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 27 Aug 2010 07:14:48 -0700
Subject: [PATCH] davinci: dm365 evm: use EDMAQ_3 as the audio DMA queue
In-Reply-To: <1282898643-10565-1-git-send-email-nsekhar@ti.com> (Sekhar Nori's
	message of "Fri, 27 Aug 2010 14:14:03 +0530")
References: <1282898643-10565-1-git-send-email-nsekhar@ti.com>
Message-ID: <87y6bsqh0n.fsf@deeprootsystems.com>

Sekhar Nori <nsekhar at ti.com> writes:

> By default the audio driver uses EDMAQ_0 as the DMA queue,
> but on DM365 this queue is specially designed for video
> transfers with a large fifo size. Having both audio and
> video transfers on the same queue leads to noise on the
> audio side.
>
> This patch changes the audio queue number for DM365 to
> EDMAQ_3.
>
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>

Thanks, applying and queuing for 2.6.37.

Kevin

> ---
>  arch/arm/mach-davinci/board-dm365-evm.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index 5bb86b2..60c59dd 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -175,7 +175,9 @@ static struct at24_platform_data eeprom_info = {
>  	.context	= (void *)0x7f00,
>  };
>  
> -static struct snd_platform_data dm365_evm_snd_data;
> +static struct snd_platform_data dm365_evm_snd_data = {
> +	.asp_chan_q = EVENTQ_3,
> +};
>  
>  static struct i2c_board_info i2c_info[] = {
>  	{

From vm.rod25 at gmail.com  Fri Aug 27 10:08:00 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Fri, 27 Aug 2010 10:08:00 -0500
Subject: Change in UART configuration
Message-ID: <AANLkTin3wN_OvgskaKsNQij+yGeC2kKhxanisPFdiP77@mail.gmail.com>

HI
One simple question Which is the big change in UART configuration from
2.6.35-rc6 to 2.635 + ? because I am rebaising a code to the latest
one, now the init code for the board is just to load the UART, but
when i boot the kernel image it stop in

Starting Kernel.....

Happens the same if I comment  the

davinci_serial_init(&my_board_uart_config);

in the 2.6.35 -rc6

I have check the serial.c and both are the same i supouse is the
debugmacro.S but if I change the code in 2.635-rc6 it is still working

Any clue would be grat

Thanks

Victor Rodriguez

From michael.williamson at criticallink.com  Fri Aug 27 11:24:29 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Fri, 27 Aug 2010 12:24:29 -0400
Subject: [PATCH v4] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <8762ywrvpt.fsf@deeprootsystems.com>
References: <4C516634.5040804@criticallink.com>	<877hjd106u.fsf@deeprootsystems.com>	<4C7702EB.8040905@criticallink.com>
	<8762ywrvpt.fsf@deeprootsystems.com>
Message-ID: <4C77E6BD.4000303@criticallink.com>

On 08/27/2010 10:11 AM, Kevin Hilman wrote:
> Michael Williamson<michael.williamson at criticallink.com>  writes:
>
>    
>>> Normally, I like to see new board support broken down more.  It's rather
>>> difficult to do a good review of new board file when everything is added
>>> in a single patch.
>>>
>>> Typically, a basic patch that just supports basic boot (typically to
>>> UART console) is the first patch.  Then additional patches are added to
>>> add peripheral support (display, MMC, SPI, flash, regulators, ...)
>>>
>>> Breaking things up this way helps reviewers and maintainers greatly.
>>>
>>> [...]
>>>
>>>        
>> OK.  Most of the board file is a large cut-and-paste of the da850
>> EVM.  It seems unlikely that I'll have any measure of success here, but if
>> I get time I might try again.
>>      
> OK, if it's mostly a cut-and-paste of da850, then maybe just break it up
> into two patches, 1) the cut, paste&  rename patch and 2) a separate
> patch for things that are different on your board.
>
> Thanks,
>
> Kevin
>    

I think I am going to try again.  I intend to basically start over, leaving
the console UART, NAND, and EMAC (hardcoded to MII interface for now).
This is the minimum set of devices I need to get one of our base boards to
boot and mount a root filesystem and run some tests here.

I will remove all the ATAG garbage and anything that is runtime configurable
as well as the LCD, McASP, SPI, SPI-NOR, and I2C based peripherals.  If the
patch is OK, then I'll add them back one by one for review.

Would this be a reasonable approach?  And should I post it as a v5 to this
series or create a different series (given the large change of code)?

Should I pull the general ARM mailing list off the distribution as this 
should
now be specific only to mach-davinci?

Thanks again for any insight.

-Mike


From khilman at deeprootsystems.com  Fri Aug 27 13:03:11 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 27 Aug 2010 11:03:11 -0700
Subject: Change in UART configuration
In-Reply-To: <AANLkTin3wN_OvgskaKsNQij+yGeC2kKhxanisPFdiP77@mail.gmail.com>
	(Victor Rodriguez's message of "Fri, 27 Aug 2010 10:08:00 -0500")
References: <AANLkTin3wN_OvgskaKsNQij+yGeC2kKhxanisPFdiP77@mail.gmail.com>
Message-ID: <87r5hkorvk.fsf@deeprootsystems.com>

Victor Rodriguez <vm.rod25 at gmail.com> writes:

> HI
> One simple question Which is the big change in UART configuration from
> 2.6.35-rc6 to 2.635 + ? because I am rebaising a code to the latest
> one, now the init code for the board is just to load the UART, but
> when i boot the kernel image it stop in
>
> Starting Kernel.....

Hmm, if you're not even seeing 'Uncompressing kernel...', it means the
kernel itself hasn't even started, and the uncompress stage has probably
failed somewhere.

As of 2.6.36, there's a change in how the debug UART is determined in
the early boot and passed to teh kernel boot. 

Check out the DEBUG_LL_DAVINCI() macros used in <mach/uncompress.h>.

As an example, check out commit 38db050e0bfc8c483e5d7b85feef23d46069ec18
which adds support for the tnetv platform.  You'll have t do the same
for your platform.

Kevin



>
> Happens the same if I comment  the
>
> davinci_serial_init(&my_board_uart_config);
>
> in the 2.6.35 -rc6
>
> I have check the serial.c and both are the same i supouse is the
> debugmacro.S but if I change the code in 2.635-rc6 it is still working
>
> Any clue would be grat
>
> Thanks
>
> Victor Rodriguez
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From khilman at deeprootsystems.com  Fri Aug 27 13:05:03 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Fri, 27 Aug 2010 11:05:03 -0700
Subject: [PATCH v4] davinci: Add MityDSP-L138/MityARM-1808 SOM support
In-Reply-To: <4C77E6BD.4000303@criticallink.com> (Michael Williamson's message
	of "Fri, 27 Aug 2010 12:24:29 -0400")
References: <4C516634.5040804@criticallink.com>
	<877hjd106u.fsf@deeprootsystems.com>
	<4C7702EB.8040905@criticallink.com>
	<8762ywrvpt.fsf@deeprootsystems.com>
	<4C77E6BD.4000303@criticallink.com>
Message-ID: <87fwy0orsg.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

> On 08/27/2010 10:11 AM, Kevin Hilman wrote:
>> Michael Williamson<michael.williamson at criticallink.com>  writes:
>>
>>    
>>>> Normally, I like to see new board support broken down more.  It's rather
>>>> difficult to do a good review of new board file when everything is added
>>>> in a single patch.
>>>>
>>>> Typically, a basic patch that just supports basic boot (typically to
>>>> UART console) is the first patch.  Then additional patches are added to
>>>> add peripheral support (display, MMC, SPI, flash, regulators, ...)
>>>>
>>>> Breaking things up this way helps reviewers and maintainers greatly.
>>>>
>>>> [...]
>>>>
>>>>        
>>> OK.  Most of the board file is a large cut-and-paste of the da850
>>> EVM.  It seems unlikely that I'll have any measure of success here, but if
>>> I get time I might try again.
>>>      
>> OK, if it's mostly a cut-and-paste of da850, then maybe just break it up
>> into two patches, 1) the cut, paste&  rename patch and 2) a separate
>> patch for things that are different on your board.
>>
>> Thanks,
>>
>> Kevin
>>    
>
> I think I am going to try again.  I intend to basically start over, leaving
> the console UART, NAND, and EMAC (hardcoded to MII interface for now).
> This is the minimum set of devices I need to get one of our base boards to
> boot and mount a root filesystem and run some tests here.
>
> I will remove all the ATAG garbage and anything that is runtime configurable
> as well as the LCD, McASP, SPI, SPI-NOR, and I2C based peripherals.  If the
> patch is OK, then I'll add them back one by one for review.
>
> Would this be a reasonable approach?  

Yes, perfect!

> And should I post it as a v5 to this
> series or create a different series (given the large change of code)?

A new series is fine.

> Should I pull the general ARM mailing list off the distribution as
> this should now be specific only to mach-davinci?

Keeping linux-arm-kernel in copy is good.

Kevin

From michael.williamson at criticallink.com  Sat Aug 28 06:59:34 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Sat, 28 Aug 2010 07:59:34 -0400
Subject: [PATCH] davinci: Initial support for MityDSP-L138/MityARM-1808
Message-ID: <4C78FA26.4040801@criticallink.com>

This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
on the da850 davinci CPU architecture.  Information on these SOMs may be 
found at http://www.mitydsp.com.

Basic support for the console UART, NAND, and EMAC (MII interface) is 
included in this patch. 

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
Notes:
  1) Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's 
     tree (2.6.36-rc2).
  2) I did not include a defconfig update in this patch.  Until the regulator
     support is added back in (planned subsequent patch), it cannot be added
     to da8xx_omapl_defconfig as the CONFIG_REGULATOR option doesn't play
     nice with platforms not defining a regulator.  If a defconfig support
     is required, this platform should go in da8xx_omapl_defconfig.  We'd
     prefer to just manage/supply a .config file to folks who needed one
     outside of the mainline via the web.  Is that acceptable?  Users should
     be able to use the da8xx_omapl_defconfig as a starting point if they
     want to reference only the mainline software.

 arch/arm/mach-davinci/Kconfig                   |    8 +
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-mityomapl138.c      |  216 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 4 files changed, 226 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2bf03e9..9aca60c 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -185,6 +185,14 @@ config MACH_TNETV107X
 	help
 	  Say Y here to select the TI TNETV107X Evaluation Module.
 
+config MACH_MITYOMAPL138
+	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
+	depends on ARCH_DAVINCI_DA850
+	help
+	  Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
+	  System on Module.  Information on this SoM may be found at
+	  http://www.mitydsp.com
+
 config DAVINCI_MUX
 	bool "DAVINCI multiplexing support"
 	depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..3e966e8 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
 obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
+obj-$(CONFIG_MACH_MITYOMAPL138)		+= board-mityomapl138.o
 
 # Power Management
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
new file mode 100644
index 0000000..3e141cf
--- /dev/null
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -0,0 +1,216 @@
+/*
+ * Critical Link MityOMAP-L138 SoM
+ *
+ * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of
+ * any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/common.h>
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+#include <mach/nand.h>
+#include <mach/mux.h>
+
+#define MITYOMAPL138_PHY_MASK		0x08 /* hardcoded for now */
+#define MITYOMAPL138_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
+
+/* MityDSP-L138 includes a 256 MByte large-page NAND flash
+ * (128K blocks).
+ */
+struct mtd_partition mityomapl138_nandflash_partition[] = {
+	{
+		.name		= "rootfs",
+		.offset		= 0,
+		.size		= SZ_128M,
+		.mask_flags	= 0, /* MTD_WRITEABLE, */
+	},
+	{
+		.name		= "homefs",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0,
+	},
+};
+
+static struct davinci_nand_pdata mityomapl138_nandflash_data = {
+	.parts		= mityomapl138_nandflash_partition,
+	.nr_parts	= ARRAY_SIZE(mityomapl138_nandflash_partition),
+	.ecc_mode	= NAND_ECC_HW,
+	.options	= NAND_USE_FLASH_BBT | NAND_BUSWIDTH_16,
+	.ecc_bits   = 1, /* 4 bit mode is not supported with 16 bit NAND */
+};
+
+static struct resource mityomapl138_nandflash_resource[] = {
+	{
+		.start	= DA8XX_AEMIF_CS3_BASE,
+		.end	= DA8XX_AEMIF_CS3_BASE + SZ_512K + 2 * SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.start	= DA8XX_AEMIF_CTL_BASE,
+		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device mityomapl138_nandflash_device = {
+	.name		= "davinci_nand",
+	.id		= 0,
+	.dev		= {
+		.platform_data	= &mityomapl138_nandflash_data,
+	},
+	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
+	.resource	= mityomapl138_nandflash_resource,
+};
+
+static struct platform_device *mityomapl138_devices[] __initdata = {
+	&mityomapl138_nandflash_device,
+};
+
+static void __init mityomapl138_setup_nand(void)
+{
+	platform_add_devices(mityomapl138_devices,
+				 ARRAY_SIZE(mityomapl138_devices));
+}
+
+static struct davinci_uart_config mityomapl138_uart_config __initdata = {
+	.enabled_uarts = 0x7,
+};
+
+static const short mityomap_mii_pins[] = {
+	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
+	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
+	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
+	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
+static const short mityomap_rmii_pins[] = {
+	DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
+	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
+	DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
+static void __init mityomapl138_config_emac(void)
+{
+	void __iomem *cfg_chip3_base;
+	int ret;
+	u32 val;
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	soc_info->emac_pdata->rmii_en = 0; /* hardcoded for now */
+
+	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+	val = __raw_readl(cfg_chip3_base);
+
+	if (soc_info->emac_pdata->rmii_en) {
+		val |= BIT(8);
+		ret = davinci_cfg_reg_list(mityomap_rmii_pins);
+		pr_info("RMII PHY configured\n");
+	} else {
+		val &= ~BIT(8);
+		ret = davinci_cfg_reg_list(mityomap_mii_pins);
+		pr_info("MII PHY configured\n");
+	}
+
+	if (ret) {
+		pr_warning("mii/rmii mux setup failed: %d\n", ret);
+		return;
+	}
+
+	/* configure the CFGCHIP3 register for RMII or MII */
+	__raw_writel(val, cfg_chip3_base);
+
+	soc_info->emac_pdata->phy_mask = MITYOMAPL138_PHY_MASK;
+	pr_info("setting phy_mask to %x\n", soc_info->emac_pdata->phy_mask);
+	soc_info->emac_pdata->mdio_max_freq = MITYOMAPL138_MDIO_FREQUENCY;
+
+	ret = da8xx_register_emac();
+	if (ret)
+		pr_warning("emac registration failed: %d\n", ret);
+}
+
+static struct davinci_pm_config da850_pm_pdata = {
+	.sleepcount = 128,
+};
+
+static struct platform_device da850_pm_device = {
+	.name	= "pm-davinci",
+	.dev = {
+		.platform_data  = &da850_pm_pdata,
+	},
+	.id	= -1,
+};
+
+static void __init mityomapl138_init(void)
+{
+	int ret;
+
+	/* for now, no special EDMA channels are reserved */
+	ret = da850_register_edma(NULL);
+	if (ret)
+		pr_warning("edma registration failed: %d\n", ret);
+
+	ret = da8xx_register_watchdog();
+	if (ret)
+		pr_warning("watchdog registration failed: %d\n", ret);
+
+	davinci_serial_init(&mityomapl138_uart_config);
+
+	mityomapl138_setup_nand();
+
+	mityomapl138_config_emac();
+
+	ret = da8xx_register_rtc();
+	if (ret)
+		pr_warning("rtc setup failed: %d\n", ret);
+
+	ret = da850_register_cpufreq("pll0_sysclk3");
+	if (ret)
+		pr_warning("cpufreq registration failed: %d\n", ret);
+
+	ret = da8xx_register_cpuidle();
+	if (ret)
+		pr_warning("cpuidle registration failed: %d\n", ret);
+
+	ret = da850_register_pm(&da850_pm_device);
+	if (ret)
+		pr_warning("da850_evm_init: suspend registration failed: %d\n",
+				ret);
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init mityomapl138_console_init(void)
+{
+	return add_preferred_console("ttyS", 1, "115200");
+}
+console_initcall(mityomapl138_console_init);
+#endif
+
+static void __init mityomapl138_map_io(void)
+{
+	da850_init();
+}
+
+MACHINE_START(MITYOMAPL138, "MityDSP-L138/MityARM-1808")
+	.phys_io	= IO_PHYS,
+	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
+	.boot_params	= (DA8XX_DDR_BASE + 0x100),
+	.map_io		= mityomapl138_map_io,
+	.init_irq	= cp_intc_init,
+	.timer		= &davinci_timer,
+	.init_machine	= mityomapl138_init,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 15a6192..d370391 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 		/* DA8xx boards */
 		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
 		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+		DEBUG_LL_DA8XX(mityomapl138,		1);
 
 		/* TNETV107x boards */
 		DEBUG_LL_TNETV107X(tnetv107x,		1);

From sumeshkkn at hotmail.com  Sat Aug 28 08:26:14 2010
From: sumeshkkn at hotmail.com (Sumesh Kaana)
Date: Sat, 28 Aug 2010 13:26:14 +0000
Subject: mmc over SPI on DM6467 based board. card not detected.
In-Reply-To: <87fwy0orsg.fsf@deeprootsystems.com>
References: <4C516634.5040804@criticallink.com>,
	<877hjd106u.fsf@deeprootsystems.com>,
	<4C7702EB.8040905@criticallink.com>,
	<8762ywrvpt.fsf@deeprootsystems.com>,
	<4C77E6BD.4000303@criticallink.com>,
	<87fwy0orsg.fsf@deeprootsystems.com>
Message-ID: <BLU124-W40A2B008B886302781867B4870@phx.gbl>


Hi all,

 I am trying to mount SD-Card over SPI on our custom DM6467
board. davinci spi controller driver and mmc over spi drver are selected in the menuconfig. i am using davinci-PSP.03-XX-00-37 kernel. 
I have also edited board initialization file to probe the MMC card under SPI as below:

 

static struct spi_board_info
dm646x_spi_info[] __initconst = {

#ifdef CONFIG_MMC_SPI

       
{

               
.modalias = "mmc_spi",

               
.max_speed_hz = (750 * 1000 ),     /* max spi clock (SCK)
speed in HZ */

               
.bus_num = 0,

               
.chip_select =
0,                      
/* CS0 */

               
.mode           = SPI_MODE_0,

       
},

#endif

 


The kernel boots with following log

 

spi_davinci spi_davinci.0: DaVinci
SPI driver in EDMA mode

Using RX channel = 17 , TX channel =
16 and event queue = 3

spi_davinci spi_davinci.0:
Controller at 0xfec66800

?????

????..

mmc_spi spi0.0: ASSUMING SPI bus
stays unshared!

mmc_spi spi0.0: ASSUMING 3.2-3.4 V
slot power

mmc0: clock 0Hz busmode 0 powermode
0 cs 0 Vdd 0 width 0 timing 0

mmc_spi spi0.0: SD/MMC host mmc0, no
WP, no poweroff

mmc0: clock 0Hz busmode 2 powermode
1 cs 1 Vdd 21 width 0 timing 0

mmc_spi spi0.0: mmc_spi: power up
(21)

 

mmc0: Minimum clock frequency too
high for identification mode

mmc0: clock 750000Hz busmode 2
powermode 2 cs 1 Vdd 21 width 0 timing 0

mmc_spi spi0.0: mmc_spi: power on
(21)

mmc_spi spi0.0: can't change
chip-select polarity 1

mmc0: starting CMD52 arg 80000c08
flags 00000015

mmc_spi spi0.0: bogus command

Backtrace: 

[<c002a7d0>]
(dump_backtrace+0x0/0x114) from [<c023f5e4>] (dump_stack+0x18/0x1c)

 r7:ce0bf400 r6:ce0bf400
r5:ce0bf5c0 r4:00000000

[<c023f5cc>]
(dump_stack+0x0/0x1c) from [<c01af3f0>] (mmc_spi_request+0xa8/0x9d8)

[<c01af348>]
(mmc_spi_request+0x0/0x9d8) from [<c01a75f8>]
(mmc_wait_for_req+0x1f4/0x21c)

[<c01a7404>]
(mmc_wait_for_req+0x0/0x21c) from [<c01a768c>] (mmc_wait_for_cmd+0x6c/0x7c)

 r7:00000000 r6:ce0bf400
r5:ce091f1c r4:ce091ee4

[<c01a7620>]
(mmc_wait_for_cmd+0x0/0x7c) from [<c01ab4f0>] (mmc_reset_sdio+0x5c/0x6c)

 r7:ce090000 r6:ce0bf550
r5:ce0bf400 r4:ce091f1c

[<c01ab494>]
(mmc_reset_sdio+0x0/0x6c) from [<c01a71f0>] (mmc_rescan+0x24c/0x2ec)

 r5:60000013 r4:ce0bf400

[<c01a6fa4>]
(mmc_rescan+0x0/0x2ec) from [<c004eb28>] (worker_thread+0x138/0x1f8)

 r6:ce092de0 r5:ce0bf550
r4:ce0bf554

[<c004e9f0>]
(worker_thread+0x0/0x1f8) from [<c0052904>] (kthread+0x88/0x90)

[<c005287c>] (kthread+0x0/0x90)
from [<c003f9b8>] (do_exit+0x0/0x684)

 r7:00000000 r6:00000000
r5:00000000 r4:00000000

mmc0: req done (CMD52): -22:
00000000 00000000 00000000 00000000

mmc0: starting CMD0 arg 00000000
flags 000000c0

mmc_spi spi0.0:   mmc_spi:
CMD0, resp R1

 I am not able to identify the micro SD card. Is there
anything which i am missing?

 

Regards,

Sumesh. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100828/1ca3b06c/attachment-0001.html>

From chtpatil at gmail.com  Sat Aug 28 23:35:15 2010
From: chtpatil at gmail.com (chetan patil)
Date: Sun, 29 Aug 2010 10:05:15 +0530
Subject: Kernel
Message-ID: <AANLkTinw+rcx-3cQqdOEj9G9pZBEkT7wLMdS+EDagsM5@mail.gmail.com>

Got fedora 12 ready.

DO i need to install DaVinci GIT kernel for as fedora has its own kernel.

I want to make environment for cross compiler.

-- 
Regards,

Chetan Arvind Patil,
+919970018364
http://sites.google.com/site/chtpatil/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100829/c77f9314/attachment.html>

From caglarakyuz at gmail.com  Mon Aug 30 03:01:23 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Mon, 30 Aug 2010 11:01:23 +0300
Subject: [PATCH 1/4] davinci: cpufreq: bailout on regulator errors
In-Reply-To: <8739usvqzy.fsf@deeprootsystems.com>
References: <1279624611-8255-1-git-send-email-nsekhar@ti.com>
	<8739usvqzy.fsf@deeprootsystems.com>
Message-ID: <201008301101.23873.caglarakyuz@gmail.com>

On Thursday 05 August 2010 09:44:33 pm Kevin Hilman wrote:
> Sekhar Nori <nsekhar at ti.com> writes:
> > Current cpufreq code does not consider errors that can occur while
> > changing voltage. Code to increase CPU  frequency goes ahead even in
> > the case the regulator has failed to increase the voltage. This leads
> > to hard error since lower voltages cannot support increased frequency.
> >
> > Prevent this by not increasing frequency in case increasing voltage
> > is not successful.
> >
> > Also, do not lower the voltage if changing the cpu frequency has failed
> > for some reason.
> >
> > Note that we do not return error on failure to decrease voltage as
> > that is not a hard error.
> >
> > Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> 
> Series looks good.
> 
> Applying the whole series after doing the 'ratio--' change locally as
> suggested by Sergei.
> 

Just noticed... 4th patch in this series breaks build for non-cpufreq 
kernels. I guess since you pushed the change a proper patch is 
needed?

Best Regards,
Caglar

From: Caglar Akyuz <caglar at bilkon-kontrol.com.tr>
Date: Mon, 30 Aug 2010 10:40:59 +0300
Subject: davinci: Match da850_register_cpufreq signature for non-cpufreq kernels.

Function signature for da850_register_cpufreq is changed by commit:

  davinci: am18x/da850/omap-l138: keep async clock constant with cpufreq

However that commit did not changed funtion for non-cpufreq kernels, so
build fails when cpufreq is disabled.

Signed-off-by: Caglar Akyuz <caglar at bilkon-kontrol.com.tr>
---
 arch/arm/mach-davinci/da850.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 9b59678..63916b9 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -985,7 +985,7 @@ static int da850_set_pll0rate(struct clk *clk, unsigned long index)
 	return 0;
 }
 #else
-int __init da850_register_cpufreq(void)
+int __init da850_register_cpufreq(char *async_clk)
 {
 	return 0;
 }
-- 
1.6.4.2


> Kevin
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

From nsekhar at ti.com  Mon Aug 30 06:47:25 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 30 Aug 2010 17:17:25 +0530
Subject: [PATCH 1/4] davinci: cpufreq: bailout on regulator errors
In-Reply-To: <201008301101.23873.caglarakyuz@gmail.com>
References: <1279624611-8255-1-git-send-email-nsekhar@ti.com>
	<8739usvqzy.fsf@deeprootsystems.com>
	<201008301101.23873.caglarakyuz@gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301F6615536@dbde02.ent.ti.com>


Hi Caglar,

On Mon, Aug 30, 2010 at 13:31:23, Caglar Akyuz wrote:
> On Thursday 05 August 2010 09:44:33 pm Kevin Hilman wrote:
> > Sekhar Nori <nsekhar at ti.com> writes:
> > > Current cpufreq code does not consider errors that can occur while
> > > changing voltage. Code to increase CPU  frequency goes ahead even in
> > > the case the regulator has failed to increase the voltage. This leads
> > > to hard error since lower voltages cannot support increased frequency.
> > >
> > > Prevent this by not increasing frequency in case increasing voltage
> > > is not successful.
> > >
> > > Also, do not lower the voltage if changing the cpu frequency has failed
> > > for some reason.
> > >
> > > Note that we do not return error on failure to decrease voltage as
> > > that is not a hard error.
> > >
> > > Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> >
> > Series looks good.
> >
> > Applying the whole series after doing the 'ratio--' change locally as
> > suggested by Sergei.
> >
>
> Just noticed... 4th patch in this series breaks build for non-cpufreq
> kernels. I guess since you pushed the change a proper patch is
> needed?

Indeed I missed the update for non-cpufreq build. Thanks for fixing this.

I think you should go ahead and submit a formal patch. Since the original
patch has not been sent to Linus, with your yes, the patch can be merged
into mine while sending upstream (the change log can be updated to reflect
inclusion of your fix).

Kevin can confirm if this is the preferred route.

Thanks,
Sekhar

>
> Best Regards,
> Caglar
>
> From: Caglar Akyuz <caglar at bilkon-kontrol.com.tr>
> Date: Mon, 30 Aug 2010 10:40:59 +0300
> Subject: davinci: Match da850_register_cpufreq signature for non-cpufreq kernels.
>
> Function signature for da850_register_cpufreq is changed by commit:
>
>   davinci: am18x/da850/omap-l138: keep async clock constant with cpufreq
>
> However that commit did not changed funtion for non-cpufreq kernels, so
> build fails when cpufreq is disabled.
>
> Signed-off-by: Caglar Akyuz <caglar at bilkon-kontrol.com.tr>
> ---
>  arch/arm/mach-davinci/da850.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 9b59678..63916b9 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -985,7 +985,7 @@ static int da850_set_pll0rate(struct clk *clk, unsigned long index)
>       return 0;
>  }
>  #else
> -int __init da850_register_cpufreq(void)
> +int __init da850_register_cpufreq(char *async_clk)
>  {
>       return 0;
>  }
> --
> 1.6.4.2
>
>
> > Kevin
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source at linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> >
>


From nsekhar at ti.com  Mon Aug 30 06:58:12 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 30 Aug 2010 17:28:12 +0530
Subject: [PATCH] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <4C78FA26.4040801@criticallink.com>
References: <4C78FA26.4040801@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301F6615555@dbde02.ent.ti.com>

Hi Michael,

On Sat, Aug 28, 2010 at 17:29:34, Michael Williamson wrote:
> This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
> on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
> on the da850 davinci CPU architecture.  Information on these SOMs may be
> found at http://www.mitydsp.com.
>
> Basic support for the console UART, NAND, and EMAC (MII interface) is
> included in this patch.
>
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
> ---
> Notes:
>   1) Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's
>      tree (2.6.36-rc2).
>   2) I did not include a defconfig update in this patch.  Until the regulator
>      support is added back in (planned subsequent patch), it cannot be added
>      to da8xx_omapl_defconfig as the CONFIG_REGULATOR option doesn't play
>      nice with platforms not defining a regulator.  If a defconfig support

What is the issue you are facing? I have seen in the past that enabling
CONFIG_REGULATOR_DUMMY helped overcome an aic3x codec initialization issue
when the aic3x probe expects a few regulators to be present in the system
if CONFIG_REGULATOR is on.

Thanks,
Sekhar


From ohad at wizery.com  Mon Aug 30 07:30:09 2010
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Mon, 30 Aug 2010 15:30:09 +0300
Subject: SDIO WIFI for DM355? [Hijacked, was: Is there a USB 802.11n wifi
	card which suit DM6446?]
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC3560870303E76569@dbde02.ent.ti.com>
References: <FCCFB4CDC6E5564B9182F639FC3560870303E76554@dbde02.ent.ti.com>
	<70E876B0EA86DD4BAF101844BC814DFE0903E02546@Cloud.RL.local>
	<FCCFB4CDC6E5564B9182F639FC3560870303E76569@dbde02.ent.ti.com>
Message-ID: <AANLkTinGdx56NOqhCbP9S4fCU46Lr9dq5HkgN1hQOwkJ@mail.gmail.com>

On Tue, Aug 24, 2010 at 9:06 AM, Subbrathnam, Swaminathan
<swami.iyer at ti.com> wrote:
>>From: Jon Povey <Jon.Povey at racelogic.co.uk>
>> A related question; anyone care to recommend an SDIO WIFI card for use with DM355?

> Solutions from Marvel were used by customers earlier.


TI also have their wl1271 wifi sdio device ported to several davinci
types and boards.

From schen at mvista.com  Mon Aug 30 08:27:32 2010
From: schen at mvista.com (Steve Chen)
Date: Mon, 30 Aug 2010 08:27:32 -0500
Subject: mmc over SPI on DM6467 based board. card not detected.
In-Reply-To: <BLU124-W40A2B008B886302781867B4870@phx.gbl>
References: <4C516634.5040804@criticallink.com>
	<877hjd106u.fsf@deeprootsystems.com>
	<4C7702EB.8040905@criticallink.com>
	<8762ywrvpt.fsf@deeprootsystems.com>
	<4C77E6BD.4000303@criticallink.com>
	<87fwy0orsg.fsf@deeprootsystems.com>
	<BLU124-W40A2B008B886302781867B4870@phx.gbl>
Message-ID: <AANLkTinZEWUqhV_yVh78hYNA82JbJ8OKYP_UJ2fRD6BA@mail.gmail.com>

On Sat, Aug 28, 2010 at 8:26 AM, Sumesh Kaana <sumeshkkn at hotmail.com> wrote:
> Hi all,
>
>
>
> I am trying to mount SD-Card over SPI on our custom DM6467 board. davinci
> spi controller driver and mmc over spi drver are selected in the menuconfig.
> i am using davinci-PSP.03-XX-00-37 kernel.
>
> I have also edited board initialization file to probe the MMC card under SPI
> as below:
>
>
>
> static struct spi_board_info dm646x_spi_info[] __initconst = {
>
> #ifdef CONFIG_MMC_SPI
>
> ??????? {
>
> ??????????????? .modalias = "mmc_spi",
>
> ??????????????? .max_speed_hz = (750 * 1000 ),???? /* max spi clock (SCK)
> speed in HZ */
>
> ??????????????? .bus_num = 0,
>
> ??????????????? .chip_select = 0,?????????????????????? /* CS0 */
>
> ??????????????? .mode?????????? = SPI_MODE_0,
>
> ??????? },
>
> #endif
>
>
>
> The kernel boots with following log
>
...
> mmc0: Minimum clock frequency too high for identification mode
...

Have you tried lower the clock frequency?

Steve

From michael.williamson at criticallink.com  Mon Aug 30 08:29:22 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Mon, 30 Aug 2010 09:29:22 -0400
Subject: [PATCH] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301F6615555@dbde02.ent.ti.com>
References: <4C78FA26.4040801@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301F6615555@dbde02.ent.ti.com>
Message-ID: <4C7BB232.80502@criticallink.com>

 Hi Sekhar,

On 8/30/2010 7:58 AM, Nori, Sekhar wrote:
> Hi Michael,
>
> On Sat, Aug 28, 2010 at 17:29:34, Michael Williamson wrote:
>> This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
>> on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
>> on the da850 davinci CPU architecture.  Information on these SOMs may be
>> found at http://www.mitydsp.com.
>>
>> Basic support for the console UART, NAND, and EMAC (MII interface) is
>> included in this patch.
>>
>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>> ---
>> Notes:
>>   1) Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's
>>      tree (2.6.36-rc2).
>>   2) I did not include a defconfig update in this patch.  Until the regulator
>>      support is added back in (planned subsequent patch), it cannot be added
>>      to da8xx_omapl_defconfig as the CONFIG_REGULATOR option doesn't play
>>      nice with platforms not defining a regulator.  If a defconfig support
> What is the issue you are facing? I have seen in the past that enabling
> CONFIG_REGULATOR_DUMMY helped overcome an aic3x codec initialization issue
> when the aic3x probe expects a few regulators to be present in the system
> if CONFIG_REGULATOR is on.
>
Enabling CONFIG_REGULATOR_DUMMY will remove the error message for this SOM. 
This brings up a couple of questions I've wanted to ask:  Are there ground
rules are for adding options to defconfig files that cover more than one
architecture/board?  Is a defconfig required for new boards?

Is it OK that I add CONFIG_REGULATOR_DUMMY to the da8xx_omapl_defconfig file? 
Or should there be a critical warning as currently defined if there
is no regulator found for the other da8xx platforms? 

Can I add the other options to support booting from NAND in this as well?
If the answer is "sure", then I can update the da8xx_omapl_defconfig and submit
that as a separate patch or resubmit this one.

Thank you for any insight.

-Mike
  

From schen at mvista.com  Mon Aug 30 08:29:45 2010
From: schen at mvista.com (Steve Chen)
Date: Mon, 30 Aug 2010 08:29:45 -0500
Subject: Kernel
In-Reply-To: <AANLkTinw+rcx-3cQqdOEj9G9pZBEkT7wLMdS+EDagsM5@mail.gmail.com>
References: <AANLkTinw+rcx-3cQqdOEj9G9pZBEkT7wLMdS+EDagsM5@mail.gmail.com>
Message-ID: <AANLkTinsSzqc0s_bnnM+2F3pywPqs6uR8uA3EPpA3XP6@mail.gmail.com>

On Sat, Aug 28, 2010 at 11:35 PM, chetan patil <chtpatil at gmail.com> wrote:
> Got fedora 12 ready.
>
> DO i need to install DaVinci GIT kernel for as fedora has its own kernel.

Yes, you need DaVinci GIT kernel.

>
> I want to make environment for cross compiler.

Yes, you need cross toolchain as well.

Steve

From hitesh.patel at einfochips.com  Mon Aug 30 08:46:14 2010
From: hitesh.patel at einfochips.com (hitesh)
Date: Mon, 30 Aug 2010 19:16:14 +0530
Subject: Problem with 256MB DDR on DM365
Message-ID: <4C7BB626.3020204@einfochips.com>

  Hi ALL

We are facing one issue related to the memory allocation on DM365 based 
board. We have 256MB DDR on our board.
But when we allocate more than 128 MB of memory to the kernel (in 
bootargs), sometimes kernel gives paging request errors while running 
application or sometimes it is not able to even boot (i.e. kernel panic).

We have done changes in the U-boot to configure the DDR of 256MB.

We have modified the following U-boot source file:
File: include/configs/davinci_dm365_evm.h
Change: (As below)

#define CFG_MALLOC_LEN                  (0x40000 + 128*1024)         /* 
malloc () len */
#define CFG_GBL_DATA_SIZE               (128)                        /* 
reserved for initial data */
#define CFG_MEMTEST_START               (0x82000000)                 /* 
memtest start address  */
#define CFG_MEMTEST_END                 (0x90000000)                 /* 
16MB RAM test          */
#define CONFIG_NR_DRAM_BANKS            (1)                          /* 
we have 1 bank of DRAM */
#define CONFIG_STACKSIZE                (256*1024)                   /* 
regular stack          */
#define PHYS_SDRAM_1                    0x80000000                   /* 
DDR Start              */
// ORIGINAL: #define PHYS_SDRAM_1_SIZE  0x8000000                    /* 
DDR size 128MB         */
#define PHYS_SDRAM_1_SIZE               0x10000000                   /* 
DDR size 256MB         */


Details of our DM365 board is as follows:

    * Silicon Version of DM365:   DM365ZCE30
    * DVSDK Version:              dvsdk_2_10_01_18
    * Linux Version:              linux-2.6.18_pro500
    * PSP Version:                PSP_02_10_00_14
    * DDR Size:                   256MB.

Any body help me what are the changes are still left?
Is there any missing in setting?
What are the setting if we go from 128MB ddr to 256MB size of DDR?

Thanks
Hitesh Patel
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100830/aa6987ea/attachment.html>

From viral at allaboutif.com  Mon Aug 30 08:48:04 2010
From: viral at allaboutif.com (Viral Sachde)
Date: Mon, 30 Aug 2010 19:18:04 +0530
Subject: Kernel
In-Reply-To: <AANLkTinsSzqc0s_bnnM+2F3pywPqs6uR8uA3EPpA3XP6@mail.gmail.com>
References: <AANLkTinw+rcx-3cQqdOEj9G9pZBEkT7wLMdS+EDagsM5@mail.gmail.com>
	<AANLkTinsSzqc0s_bnnM+2F3pywPqs6uR8uA3EPpA3XP6@mail.gmail.com>
Message-ID: <AANLkTi=gt8vRLuXGm6KYAFzYdKPZJWz-7De4R860S2mV@mail.gmail.com>

On Mon, Aug 30, 2010 at 6:59 PM, Steve Chen <schen at mvista.com> wrote:
> On Sat, Aug 28, 2010 at 11:35 PM, chetan patil <chtpatil at gmail.com> wrote:
>> Got fedora 12 ready.
>>
>> DO i need to install DaVinci GIT kernel for as fedora has its own kernel.
>
> Yes, you need DaVinci GIT kernel.
>
>>
>> I want to make environment for cross compiler.
>
> Yes, you need cross toolchain as well.
>
> Steve

You can just download cross compiler and kernel source code and
compile them.  You can use your default kernel on host (Fedora 12).
You can start with any pre-compiled cross compiler (Such as from MV,
Codesourcery ...) and compile kernel code. As suggested in
respectively read me file, you may need to proper tool chain path's to
environment variable, PATH (ex export PATH=$PATH:Tool-chain-path )
Regards, Viral

From vm.rod25 at gmail.com  Mon Aug 30 08:51:13 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Mon, 30 Aug 2010 08:51:13 -0500
Subject: Kernel
In-Reply-To: <AANLkTimCR9BXji6vf_nCKv1ZKEtCcAfZu+aLyX1pN2j3@mail.gmail.com>
References: <AANLkTinw+rcx-3cQqdOEj9G9pZBEkT7wLMdS+EDagsM5@mail.gmail.com>
	<AANLkTi=GG_9w=LJm5Ycdojw+SSdEAWvfHPyTqYakjPiN@mail.gmail.com>
	<AANLkTikw+ORe8g40bKxRbMTGm_fyxY_HgfCwAcWamjTq@mail.gmail.com>
	<AANLkTikZKh0H3=QAcRnS3votwnbRbygxK9_eNGu0tCJo@mail.gmail.com>
	<AANLkTimCR9BXji6vf_nCKv1ZKEtCcAfZu+aLyX1pN2j3@mail.gmail.com>
Message-ID: <AANLkTimHBO3j7Q59jt_YsyW-obREQQfzZ6qEk3aZ7fA-@mail.gmail.com>

On Sun, Aug 29, 2010 at 12:38 PM, chetan patil <chtpatil at gmail.com> wrote:
> Actually we are working on final year project involving DaVinci DM6446.
>
> So we need to set up environment on Linux and the cross compile it to
> DaVinci processor.!
>
> On Sun, Aug 29, 2010 at 10:53 PM, Victor Rodriguez <vm.rod25 at gmail.com>
> wrote:
>>
>> Hi
>>
>> On Sun, Aug 29, 2010 at 9:08 AM, chetan patil <chtpatil at gmail.com> wrote:
>> > Hey hi,
>> >
>> > I installed GCC toolchain.
>> >
>> > Installed:
>> > ??? (I)A GNU Collection of "Binary
>> > Utilities.(Binutlis-2.19.51.0.14-34.fc12
>> > (i686))"
>> > ??? (II)With this also installed "Cross Compiling GNU binutlis targeted
>> > at
>> > arm-gp2x linux"
>> >
>> > Installed:
>> > ??? (I)GCC (C & C++ Complier)
>> > ??? (II)"Cross Compiling GNU GCC targeted at arm-gp2x linux"
>> >
>> > Installed:
>> > ??? (I)Glibc
>> >
>> > Now will try to run some simple code. But how to cross compile that i
>> > have
>> > to learn.
>> > On Sun, Aug 29, 2010 at 7:33 PM, Victor Rodriguez <vm.rod25 at gmail.com>
>> > wrote:
>> >>
>> >> On Sat, Aug 28, 2010 at 11:35 PM, chetan patil <chtpatil at gmail.com>
>> >> wrote:
>> >> > Got fedora 12 ready.
>> >> >
>> >> > DO i need to install DaVinci GIT kernel for as fedora has its own
>> >> > kernel.
>> >> >
>> >> > I want to make environment for cross compiler.
>> >> >
>> >> > --
>> >> > Regards,
>> >> >
>> >> > Chetan Arvind Patil,
>> >> > +919970018364
>> >> > http://sites.google.com/site/chtpatil/
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Davinci-linux-open-source mailing list
>> >> > Davinci-linux-open-source at linux.davincidsp.com
>> >> >
>> >> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>> >> >
>> >> >
>> >>
>> >> You need a cross compiler firs check code sourcery for arm
>> >> architecture, then download thedavincy git kernel and croscompile
>> >> until you get your uImage.
>> >>
>> >> Hope it helps
>> >>
>> >> Victor Rodriguez
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Chetan Arvind Patil,
>> > +919970018364
>> > http://sites.google.com/site/chtpatil/
>> >
>> >
>>
>> What do you want to croscompile ?? ?check this web page
>>
>> http://elinux.org/Hawkboard
>>
>>
>> it is an open architecture ARM board. It is hawkboar, it is relative
>> new you can find more information ?here
>>
>> http://www.hawkboard.org/
>>
>>
>> It is just like beagle board another ARM open architecture
>>
>> It is very didactic for learn about embeded sistems
>>
>> now i have never used the tools that you have told me
>>
>> download this is the one that i use for arm architecture
>>
>>
>> Sourcery G++ Lite 2009q3-68.
>>
>>
>> ?http://www.codesourcery.com/sgpp/lite/arm/portal/release1033
>>
>> hope it helps
>>
>>
>> VIctor Rodriguez
>
>
>
> --
> Regards,
>
> Chetan Arvind Patil,
> +919970018364
> http://sites.google.com/site/chtpatil/
>
>


Hi I do not know your board i google it and found that is a DSP board
for multimedia, weel if you tipe git grep  DM6446 in the linux-davinci
directory you will fine thta your board already have suport for it ,
you need to find wichconfiguration file exist , i google DM6446 linux
kernel and found suport for HOWTO , afeter you isntalled the coude
sourcery you need to do this in your linux-davincy directory

  make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- distclean
  make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- your
DM6446_defconfig (check wich fits your board)
  make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage

and afeter all that you have your uImage ready to transfer to your uprocesor

try to find something like this for your board is also from TI , i
supouse that should be something similar for DM6446

http://elinux.org/Hawkboard#Compiling_Linux_Kerne

Hope it helps

VIctor Rodriguez

From hankm at ncast.com  Mon Aug 30 09:06:49 2010
From: hankm at ncast.com (Hank Magnuski)
Date: Mon, 30 Aug 2010 07:06:49 -0700 (PDT)
Subject: Problem with 256MB DDR on DM365
In-Reply-To: <4C7BB626.3020204@einfochips.com>
References: <4C7BB626.3020204@einfochips.com>
Message-ID: <alpine.LRH.2.00.1008300702340.18001@sv-04.mtinet.com>


As far as I can tell the U-boot settings aren't very critical to the change in 
memory size. U-boot basically reports what you tell it in this case.

We just changed the kernel parameters and it worked for us.

Perhaps you are having some clocking or speed issue. Some type of hardware 
timing problem.

Hank



On Mon, 30 Aug 2010, hitesh wrote:

>  Hi ALL
>
> We have done changes in the U-boot to configure the DDR of 256MB.

Hank

From schen at mvista.com  Mon Aug 30 09:06:45 2010
From: schen at mvista.com (Steve Chen)
Date: Mon, 30 Aug 2010 09:06:45 -0500
Subject: Kernel
In-Reply-To: <AANLkTi=gt8vRLuXGm6KYAFzYdKPZJWz-7De4R860S2mV@mail.gmail.com>
References: <AANLkTinw+rcx-3cQqdOEj9G9pZBEkT7wLMdS+EDagsM5@mail.gmail.com>
	<AANLkTinsSzqc0s_bnnM+2F3pywPqs6uR8uA3EPpA3XP6@mail.gmail.com>
	<AANLkTi=gt8vRLuXGm6KYAFzYdKPZJWz-7De4R860S2mV@mail.gmail.com>
Message-ID: <AANLkTimZi02uJD5XPyF77QOUh82xa4b-pRdQjmzEKMbx@mail.gmail.com>

On Mon, Aug 30, 2010 at 8:48 AM, Viral Sachde <viral at allaboutif.com> wrote:
> On Mon, Aug 30, 2010 at 6:59 PM, Steve Chen <schen at mvista.com> wrote:
>> On Sat, Aug 28, 2010 at 11:35 PM, chetan patil <chtpatil at gmail.com> wrote:
>>> Got fedora 12 ready.
>>>
>>> DO i need to install DaVinci GIT kernel for as fedora has its own kernel.
>>
>> Yes, you need DaVinci GIT kernel.
>>
>>>
>>> I want to make environment for cross compiler.
>>
>> Yes, you need cross toolchain as well.
>>
>> Steve
>
> You can just download cross compiler and kernel source code and
> compile them. ?You can use your default kernel on host (Fedora 12).
> You can start with any pre-compiled cross compiler (Such as from MV,
> Codesourcery ...) and compile kernel code. As suggested in
> respectively read me file, you may need to proper tool chain path's to
> environment variable, PATH (ex export PATH=$PATH:Tool-chain-path )
> Regards, Viral

All good info.  There are certainly many many ways to go about
building the kernel.  Personally, Fedora kernel would not be my first
kernel of choice because it is optimized for X86, and the DaVinci
specific code may not be up-to-date.  It may save a lot of heartache
going for something that is known to work.  The two top free choices
are the DaVinci git and Arango project kernel.

Steve

From schen at mvista.com  Mon Aug 30 09:06:45 2010
From: schen at mvista.com (Steve Chen)
Date: Mon, 30 Aug 2010 09:06:45 -0500
Subject: Kernel
In-Reply-To: <AANLkTi=gt8vRLuXGm6KYAFzYdKPZJWz-7De4R860S2mV@mail.gmail.com>
References: <AANLkTinw+rcx-3cQqdOEj9G9pZBEkT7wLMdS+EDagsM5@mail.gmail.com>
	<AANLkTinsSzqc0s_bnnM+2F3pywPqs6uR8uA3EPpA3XP6@mail.gmail.com>
	<AANLkTi=gt8vRLuXGm6KYAFzYdKPZJWz-7De4R860S2mV@mail.gmail.com>
Message-ID: <AANLkTimZi02uJD5XPyF77QOUh82xa4b-pRdQjmzEKMbx@mail.gmail.com>

On Mon, Aug 30, 2010 at 8:48 AM, Viral Sachde <viral at allaboutif.com> wrote:
> On Mon, Aug 30, 2010 at 6:59 PM, Steve Chen <schen at mvista.com> wrote:
>> On Sat, Aug 28, 2010 at 11:35 PM, chetan patil <chtpatil at gmail.com> wrote:
>>> Got fedora 12 ready.
>>>
>>> DO i need to install DaVinci GIT kernel for as fedora has its own kernel.
>>
>> Yes, you need DaVinci GIT kernel.
>>
>>>
>>> I want to make environment for cross compiler.
>>
>> Yes, you need cross toolchain as well.
>>
>> Steve
>
> You can just download cross compiler and kernel source code and
> compile them. ?You can use your default kernel on host (Fedora 12).
> You can start with any pre-compiled cross compiler (Such as from MV,
> Codesourcery ...) and compile kernel code. As suggested in
> respectively read me file, you may need to proper tool chain path's to
> environment variable, PATH (ex export PATH=$PATH:Tool-chain-path )
> Regards, Viral

All good info.  There are certainly many many ways to go about
building the kernel.  Personally, Fedora kernel would not be my first
kernel of choice because it is optimized for X86, and the DaVinci
specific code may not be up-to-date.  It may save a lot of heartache
going for something that is known to work.  The two top free choices
are the DaVinci git and Arango project kernel.

Steve

From viral at allaboutif.com  Mon Aug 30 09:15:04 2010
From: viral at allaboutif.com (Viral Sachde)
Date: Mon, 30 Aug 2010 19:45:04 +0530
Subject: Kernel
In-Reply-To: <AANLkTimZi02uJD5XPyF77QOUh82xa4b-pRdQjmzEKMbx@mail.gmail.com>
References: <AANLkTinw+rcx-3cQqdOEj9G9pZBEkT7wLMdS+EDagsM5@mail.gmail.com>
	<AANLkTinsSzqc0s_bnnM+2F3pywPqs6uR8uA3EPpA3XP6@mail.gmail.com>
	<AANLkTi=gt8vRLuXGm6KYAFzYdKPZJWz-7De4R860S2mV@mail.gmail.com>
	<AANLkTimZi02uJD5XPyF77QOUh82xa4b-pRdQjmzEKMbx@mail.gmail.com>
Message-ID: <AANLkTimAaTBc6fNa8tgRE1B0QJ2PuPu8pLUZo75g5+s3@mail.gmail.com>

On Mon, Aug 30, 2010 at 7:36 PM, Steve Chen <schen at mvista.com> wrote:
> On Mon, Aug 30, 2010 at 8:48 AM, Viral Sachde <viral at allaboutif.com> wrote:
>> On Mon, Aug 30, 2010 at 6:59 PM, Steve Chen <schen at mvista.com> wrote:
>>> On Sat, Aug 28, 2010 at 11:35 PM, chetan patil <chtpatil at gmail.com> wrote:
>>>> Got fedora 12 ready.
>>>>
>>>> DO i need to install DaVinci GIT kernel for as fedora has its own kernel.
>>>
>>> Yes, you need DaVinci GIT kernel.
>>>
>>>>
>>>> I want to make environment for cross compiler.
>>>
>>> Yes, you need cross toolchain as well.
>>>
>>> Steve
>>
>> You can just download cross compiler and kernel source code and
>> compile them. ?You can use your default kernel on host (Fedora 12).
>> You can start with any pre-compiled cross compiler (Such as from MV,
>> Codesourcery ...) and compile kernel code. As suggested in
>> respectively read me file, you may need to proper tool chain path's to
>> environment variable, PATH (ex export PATH=$PATH:Tool-chain-path )
>> Regards, Viral
>
> All good info. ?There are certainly many many ways to go about
> building the kernel. ?Personally, Fedora kernel would not be my first
> kernel of choice because it is optimized for X86, and the DaVinci
> specific code may not be up-to-date. ?It may save a lot of heartache
> going for something that is known to work. ?The two top free choices
> are the DaVinci git and Arango project kernel.
>
> Steve
>

Hi Steve & Chetan,
Thanks for input. I just wanted to clear one point to chetan,
- One does not need to install any kernel on Fedora.
- He just needs to download source code and compile them for davinci
with cross-compiler tool chain.
Thanks, Viral

From khilman at deeprootsystems.com  Mon Aug 30 09:36:46 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 30 Aug 2010 07:36:46 -0700
Subject: [PATCH 0/6] davinci: add support for aemif timing configuration
In-Reply-To: <1283082501.2131.29.camel@brekeke> (Artem Bityutskiy's message of
	"Sun, 29 Aug 2010 14:48:21 +0300")
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
	<1283082501.2131.29.camel@brekeke>
Message-ID: <877hj8b20x.fsf@deeprootsystems.com>

Artem Bityutskiy <dedekind1 at gmail.com> writes:

> On Mon, 2010-08-09 at 15:46 +0530, Sekhar Nori wrote:
>> This series of patches adds support for AEMIF timing configuration
>> for DaVinci SoCs.
>> 
>> Currently AEMIF timing configuration is done as a special case for
>> DM644x EVM. This work provides for a generic way of doing this.
>> 
>> David,
>> 	Patch 1/6 and 2/6 of this series touch the
>> 	drivers/mtd/nand/davinci_nand.c file along with other arch specific
>> 	files. Based on the discussion on DaVinci list, Kevin is OK to merge
>> 	this with your agreement. Please let us know how to proceed.
>
> Pushed to l2-mtd-2.6.git / dunno.

Hi Artem,

If it's OK with you, and with your Ack, I'd prefer to merge this series
via the davinci tree.

The reason is because the files touched in arch/arm/mach-davinci/* are
also getting lots of other changes for 2.6.37, and I'd like to minimize
conflicts.

Let me know if that's OK with you and if I can add your signoff to the
drivers/mtd/* patches.  

Thanks,

Kevin


From khilman at deeprootsystems.com  Mon Aug 30 09:59:21 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 30 Aug 2010 07:59:21 -0700
Subject: [PATCH 1/4] davinci: cpufreq: bailout on regulator errors
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301F6615536@dbde02.ent.ti.com>
	(Sekhar Nori's message of "Mon, 30 Aug 2010 17:17:25 +0530")
References: <1279624611-8255-1-git-send-email-nsekhar@ti.com>
	<8739usvqzy.fsf@deeprootsystems.com>
	<201008301101.23873.caglarakyuz@gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301F6615536@dbde02.ent.ti.com>
Message-ID: <87mxs49meu.fsf@deeprootsystems.com>

"Nori, Sekhar" <nsekhar at ti.com> writes:

> Hi Caglar,
>
> On Mon, Aug 30, 2010 at 13:31:23, Caglar Akyuz wrote:
>> On Thursday 05 August 2010 09:44:33 pm Kevin Hilman wrote:
>> > Sekhar Nori <nsekhar at ti.com> writes:
>> > > Current cpufreq code does not consider errors that can occur while
>> > > changing voltage. Code to increase CPU  frequency goes ahead even in
>> > > the case the regulator has failed to increase the voltage. This leads
>> > > to hard error since lower voltages cannot support increased frequency.
>> > >
>> > > Prevent this by not increasing frequency in case increasing voltage
>> > > is not successful.
>> > >
>> > > Also, do not lower the voltage if changing the cpu frequency has failed
>> > > for some reason.
>> > >
>> > > Note that we do not return error on failure to decrease voltage as
>> > > that is not a hard error.
>> > >
>> > > Signed-off-by: Sekhar Nori <nsekhar at ti.com>
>> >
>> > Series looks good.
>> >
>> > Applying the whole series after doing the 'ratio--' change locally as
>> > suggested by Sergei.
>> >
>>
>> Just noticed... 4th patch in this series breaks build for non-cpufreq
>> kernels. I guess since you pushed the change a proper patch is
>> needed?
>
> Indeed I missed the update for non-cpufreq build. Thanks for fixing this.
>
> I think you should go ahead and submit a formal patch. Since the original
> patch has not been sent to Linus, with your yes, the patch can be merged
> into mine while sending upstream (the change log can be updated to reflect
> inclusion of your fix).
>
> Kevin can confirm if this is the preferred route.

Yes, in fact I did it using this patch, so it's done.

Thanks Caglar for the fix.

Kevin

From khilman at deeprootsystems.com  Mon Aug 30 10:05:59 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 30 Aug 2010 08:05:59 -0700
Subject: [PATCH] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <4C78FA26.4040801@criticallink.com> (Michael Williamson's message
	of "Sat, 28 Aug 2010 07:59:34 -0400")
References: <4C78FA26.4040801@criticallink.com>
Message-ID: <87k4n89m3s.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

> This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
> on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
> on the da850 davinci CPU architecture.  Information on these SOMs may be 
> found at http://www.mitydsp.com.
>
> Basic support for the console UART, NAND, and EMAC (MII interface) is 
> included in this patch. 
>
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
> ---
> Notes:
>   1) Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's 
>      tree (2.6.36-rc2).
>   2) I did not include a defconfig update in this patch.  Until the regulator
>      support is added back in (planned subsequent patch), it cannot be added
>      to da8xx_omapl_defconfig as the CONFIG_REGULATOR option doesn't play
>      nice with platforms not defining a regulator.  If a defconfig support
>      is required, this platform should go in da8xx_omapl_defconfig.  We'd
>      prefer to just manage/supply a .config file to folks who needed one
>      outside of the mainline via the web.  Is that acceptable?  Users should
>      be able to use the da8xx_omapl_defconfig as a starting point if they
>      want to reference only the mainline software.
>
>  arch/arm/mach-davinci/Kconfig                   |    8 +
>  arch/arm/mach-davinci/Makefile                  |    1 +
>  arch/arm/mach-davinci/board-mityomapl138.c      |  216 +++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
>  4 files changed, 226 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 2bf03e9..9aca60c 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -185,6 +185,14 @@ config MACH_TNETV107X
>  	help
>  	  Say Y here to select the TI TNETV107X Evaluation Module.
>  
> +config MACH_MITYOMAPL138
> +	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
> +	depends on ARCH_DAVINCI_DA850
> +	help
> +	  Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
> +	  System on Module.  Information on this SoM may be found at
> +	  http://www.mitydsp.com
> +
>  config DAVINCI_MUX
>  	bool "DAVINCI multiplexing support"
>  	depends on ARCH_DAVINCI
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index eab4c0f..3e966e8 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
>  obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
> +obj-$(CONFIG_MACH_MITYOMAPL138)		+= board-mityomapl138.o
>  
>  # Power Management
>  obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> new file mode 100644
> index 0000000..3e141cf
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> @@ -0,0 +1,216 @@
> +/*
> + * Critical Link MityOMAP-L138 SoM
> + *
> + * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of
> + * any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/platform_device.h>
> +#include <linux/mtd/partitions.h>
> +
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/common.h>
> +#include <mach/cp_intc.h>
> +#include <mach/da8xx.h>
> +#include <mach/nand.h>
> +#include <mach/mux.h>
> +
> +#define MITYOMAPL138_PHY_MASK		0x08 /* hardcoded for now */
> +#define MITYOMAPL138_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
> +
> +/* MityDSP-L138 includes a 256 MByte large-page NAND flash
> + * (128K blocks).
> + */

minor nit: please fix multi-line comment style.  search for 'multi-line'
in Documentation/CodingStyle for details.

> +struct mtd_partition mityomapl138_nandflash_partition[] = {
> +	{
> +		.name		= "rootfs",
> +		.offset		= 0,
> +		.size		= SZ_128M,
> +		.mask_flags	= 0, /* MTD_WRITEABLE, */
> +	},
> +	{
> +		.name		= "homefs",
> +		.offset		= MTDPART_OFS_APPEND,
> +		.size		= MTDPART_SIZ_FULL,
> +		.mask_flags	= 0,
> +	},
> +};

It's your board, you can have your partitions however you choose, but
just curious... Is your bootloader somehwhere in NAND too?  Also 128M
seems pretty small for a root filesystem.

> +static struct davinci_nand_pdata mityomapl138_nandflash_data = {
> +	.parts		= mityomapl138_nandflash_partition,
> +	.nr_parts	= ARRAY_SIZE(mityomapl138_nandflash_partition),
> +	.ecc_mode	= NAND_ECC_HW,
> +	.options	= NAND_USE_FLASH_BBT | NAND_BUSWIDTH_16,
> +	.ecc_bits   = 1, /* 4 bit mode is not supported with 16 bit NAND */
> +};
> +
> +static struct resource mityomapl138_nandflash_resource[] = {
> +	{
> +		.start	= DA8XX_AEMIF_CS3_BASE,
> +		.end	= DA8XX_AEMIF_CS3_BASE + SZ_512K + 2 * SZ_1K - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	{
> +		.start	= DA8XX_AEMIF_CTL_BASE,
> +		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +};
> +
> +static struct platform_device mityomapl138_nandflash_device = {
> +	.name		= "davinci_nand",
> +	.id		= 0,
> +	.dev		= {
> +		.platform_data	= &mityomapl138_nandflash_data,
> +	},
> +	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
> +	.resource	= mityomapl138_nandflash_resource,
> +};
> +
> +static struct platform_device *mityomapl138_devices[] __initdata = {
> +	&mityomapl138_nandflash_device,
> +};
> +
> +static void __init mityomapl138_setup_nand(void)
> +{
> +	platform_add_devices(mityomapl138_devices,
> +				 ARRAY_SIZE(mityomapl138_devices));
> +}
> +
> +static struct davinci_uart_config mityomapl138_uart_config __initdata = {
> +	.enabled_uarts = 0x7,
> +};
> +
> +static const short mityomap_mii_pins[] = {
> +	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
> +	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
> +	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
> +	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
> +	DA850_MDIO_D,
> +	-1
> +};
> +
> +static const short mityomap_rmii_pins[] = {
> +	DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
> +	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
> +	DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
> +	DA850_MDIO_D,
> +	-1
> +};
> +
> +static void __init mityomapl138_config_emac(void)
> +{
> +	void __iomem *cfg_chip3_base;
> +	int ret;
> +	u32 val;
> +	struct davinci_soc_info *soc_info = &davinci_soc_info;
> +	soc_info->emac_pdata->rmii_en = 0; /* hardcoded for now */
> +
> +	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
> +	val = __raw_readl(cfg_chip3_base);
> +
> +	if (soc_info->emac_pdata->rmii_en) {
> +		val |= BIT(8);
> +		ret = davinci_cfg_reg_list(mityomap_rmii_pins);
> +		pr_info("RMII PHY configured\n");
> +	} else {
> +		val &= ~BIT(8);
> +		ret = davinci_cfg_reg_list(mityomap_mii_pins);
> +		pr_info("MII PHY configured\n");
> +	}
> +
> +	if (ret) {
> +		pr_warning("mii/rmii mux setup failed: %d\n", ret);
> +		return;
> +	}
> +
> +	/* configure the CFGCHIP3 register for RMII or MII */
> +	__raw_writel(val, cfg_chip3_base);
> +
> +	soc_info->emac_pdata->phy_mask = MITYOMAPL138_PHY_MASK;
> +	pr_info("setting phy_mask to %x\n", soc_info->emac_pdata->phy_mask);
> +	soc_info->emac_pdata->mdio_max_freq = MITYOMAPL138_MDIO_FREQUENCY;
> +
> +	ret = da8xx_register_emac();
> +	if (ret)
> +		pr_warning("emac registration failed: %d\n", ret);
> +}
> +
> +static struct davinci_pm_config da850_pm_pdata = {
> +	.sleepcount = 128,
> +};
> +
> +static struct platform_device da850_pm_device = {
> +	.name	= "pm-davinci",
> +	.dev = {
> +		.platform_data  = &da850_pm_pdata,
> +	},
> +	.id	= -1,
> +};
> +
> +static void __init mityomapl138_init(void)
> +{
> +	int ret;
> +
> +	/* for now, no special EDMA channels are reserved */
> +	ret = da850_register_edma(NULL);
> +	if (ret)
> +		pr_warning("edma registration failed: %d\n", ret);
> +
> +	ret = da8xx_register_watchdog();
> +	if (ret)
> +		pr_warning("watchdog registration failed: %d\n", ret);
> +
> +	davinci_serial_init(&mityomapl138_uart_config);
> +
> +	mityomapl138_setup_nand();
> +
> +	mityomapl138_config_emac();
> +
> +	ret = da8xx_register_rtc();
> +	if (ret)
> +		pr_warning("rtc setup failed: %d\n", ret);
> +
> +	ret = da850_register_cpufreq("pll0_sysclk3");
> +	if (ret)
> +		pr_warning("cpufreq registration failed: %d\n", ret);
> +
> +	ret = da8xx_register_cpuidle();
> +	if (ret)
> +		pr_warning("cpuidle registration failed: %d\n", ret);
> +
> +	ret = da850_register_pm(&da850_pm_device);
> +	if (ret)
> +		pr_warning("da850_evm_init: suspend registration failed: %d\n",
> +				ret);
> +}
> +
> +#ifdef CONFIG_SERIAL_8250_CONSOLE
> +static int __init mityomapl138_console_init(void)
> +{

You need a machine_is_* check here since this will be run whenever this
is compiled in.  E.g., if a kernel is built to support all da8xx platforms,

In fact, the da850-evm board file should have this too since when both
this board and the EVM are compiled in, they will both be setting a
different preferred console.

> +	return add_preferred_console("ttyS", 1, "115200");
> +}
> +console_initcall(mityomapl138_console_init);
> +#endif
> +
> +static void __init mityomapl138_map_io(void)
> +{
> +	da850_init();
> +}
> +
> +MACHINE_START(MITYOMAPL138, "MityDSP-L138/MityARM-1808")
> +	.phys_io	= IO_PHYS,
> +	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
> +	.boot_params	= (DA8XX_DDR_BASE + 0x100),
> +	.map_io		= mityomapl138_map_io,
> +	.init_irq	= cp_intc_init,
> +	.timer		= &davinci_timer,
> +	.init_machine	= mityomapl138_init,
> +MACHINE_END
> diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
> index 15a6192..d370391 100644
> --- a/arch/arm/mach-davinci/include/mach/uncompress.h
> +++ b/arch/arm/mach-davinci/include/mach/uncompress.h
> @@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
>  		/* DA8xx boards */
>  		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
>  		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
> +		DEBUG_LL_DA8XX(mityomapl138,		1);
>  
>  		/* TNETV107x boards */
>  		DEBUG_LL_TNETV107X(tnetv107x,		1);

Kevin

From michael.williamson at criticallink.com  Mon Aug 30 10:35:37 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Mon, 30 Aug 2010 11:35:37 -0400
Subject: [PATCH] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <87k4n89m3s.fsf@deeprootsystems.com>
References: <4C78FA26.4040801@criticallink.com>
	<87k4n89m3s.fsf@deeprootsystems.com>
Message-ID: <4C7BCFC9.7050004@criticallink.com>

 On 8/30/2010 11:05 AM, Kevin Hilman wrote:
> Michael Williamson <michael.williamson at criticallink.com> writes:
>
>> This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
>> on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
>> on the da850 davinci CPU architecture.  Information on these SOMs may be 
>> found at http://www.mitydsp.com.
>>
>> Basic support for the console UART, NAND, and EMAC (MII interface) is 
>> included in this patch. 
>>
>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>> ---
>> Notes:
>>   1) Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's 
>>      tree (2.6.36-rc2).
>>   2) I did not include a defconfig update in this patch.  Until the regulator
>>      support is added back in (planned subsequent patch), it cannot be added
>>      to da8xx_omapl_defconfig as the CONFIG_REGULATOR option doesn't play
>>      nice with platforms not defining a regulator.  If a defconfig support
>>      is required, this platform should go in da8xx_omapl_defconfig.  We'd
>>      prefer to just manage/supply a .config file to folks who needed one
>>      outside of the mainline via the web.  Is that acceptable?  Users should
>>      be able to use the da8xx_omapl_defconfig as a starting point if they
>>      want to reference only the mainline software.
>>
>>  arch/arm/mach-davinci/Kconfig                   |    8 +
>>  arch/arm/mach-davinci/Makefile                  |    1 +
>>  arch/arm/mach-davinci/board-mityomapl138.c      |  216 +++++++++++++++++++++++
>>  arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
>>  4 files changed, 226 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>> index 2bf03e9..9aca60c 100644
>> --- a/arch/arm/mach-davinci/Kconfig
>> +++ b/arch/arm/mach-davinci/Kconfig
>> @@ -185,6 +185,14 @@ config MACH_TNETV107X
>>  	help
>>  	  Say Y here to select the TI TNETV107X Evaluation Module.
>>  
>> +config MACH_MITYOMAPL138
>> +	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
>> +	depends on ARCH_DAVINCI_DA850
>> +	help
>> +	  Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
>> +	  System on Module.  Information on this SoM may be found at
>> +	  http://www.mitydsp.com
>> +
>>  config DAVINCI_MUX
>>  	bool "DAVINCI multiplexing support"
>>  	depends on ARCH_DAVINCI
>> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
>> index eab4c0f..3e966e8 100644
>> --- a/arch/arm/mach-davinci/Makefile
>> +++ b/arch/arm/mach-davinci/Makefile
>> @@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
>>  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
>>  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
>>  obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
>> +obj-$(CONFIG_MACH_MITYOMAPL138)		+= board-mityomapl138.o
>>  
>>  # Power Management
>>  obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
>> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
>> new file mode 100644
>> index 0000000..3e141cf
>> --- /dev/null
>> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
>> @@ -0,0 +1,216 @@
>> +/*
>> + * Critical Link MityOMAP-L138 SoM
>> + *
>> + * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
>> + *
>> + * This file is licensed under the terms of the GNU General Public License
>> + * version 2. This program is licensed "as is" without any warranty of
>> + * any kind, whether express or implied.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/console.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/mtd/partitions.h>
>> +
>> +#include <asm/mach-types.h>
>> +#include <asm/mach/arch.h>
>> +#include <mach/common.h>
>> +#include <mach/cp_intc.h>
>> +#include <mach/da8xx.h>
>> +#include <mach/nand.h>
>> +#include <mach/mux.h>
>> +
>> +#define MITYOMAPL138_PHY_MASK		0x08 /* hardcoded for now */
>> +#define MITYOMAPL138_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
>> +
>> +/* MityDSP-L138 includes a 256 MByte large-page NAND flash
>> + * (128K blocks).
>> + */
> minor nit: please fix multi-line comment style.  search for 'multi-line'
> in Documentation/CodingStyle for details.

OK.

>> +struct mtd_partition mityomapl138_nandflash_partition[] = {
>> +	{
>> +		.name		= "rootfs",
>> +		.offset		= 0,
>> +		.size		= SZ_128M,
>> +		.mask_flags	= 0, /* MTD_WRITEABLE, */
>> +	},
>> +	{
>> +		.name		= "homefs",
>> +		.offset		= MTDPART_OFS_APPEND,
>> +		.size		= MTDPART_SIZ_FULL,
>> +		.mask_flags	= 0,
>> +	},
>> +};
> It's your board, you can have your partitions however you choose, but
> just curious... Is your bootloader somehwhere in NAND too?  Also 128M
> seems pretty small for a root filesystem.
>
The bootloader (u-boot) and kernel is on an onboard SPI-NOR device.  I was
going add the SPI stuff and the appropriate partitions on a next round
of patches (if this one makes it) per your guidance.  It's not needed to get
the kernel up and running, which was why we left it out.  There's nothing
precluding using NAND for storing the bootloader, etc., but by default we
weren't going to do that.  We're planning to normally support partition options
passed by command line anyway (MTDPARTS).  My understanding is that partition
options would override these values, right?

The 128M supports quite a few configurations so far (we're sitting at around
68M with the bloat of Qt-embedded jammed in there).  This was mostly a line
in the sand.  Since I will be resubmitting, I might bump it up.  Thanks.

>> +static struct davinci_nand_pdata mityomapl138_nandflash_data = {
>> +	.parts		= mityomapl138_nandflash_partition,
>> +	.nr_parts	= ARRAY_SIZE(mityomapl138_nandflash_partition),
>> +	.ecc_mode	= NAND_ECC_HW,
>> +	.options	= NAND_USE_FLASH_BBT | NAND_BUSWIDTH_16,
>> +	.ecc_bits   = 1, /* 4 bit mode is not supported with 16 bit NAND */
>> +};
>> +
>> +static struct resource mityomapl138_nandflash_resource[] = {
>> +	{
>> +		.start	= DA8XX_AEMIF_CS3_BASE,
>> +		.end	= DA8XX_AEMIF_CS3_BASE + SZ_512K + 2 * SZ_1K - 1,
>> +		.flags	= IORESOURCE_MEM,
>> +	},
>> +	{
>> +		.start	= DA8XX_AEMIF_CTL_BASE,
>> +		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
>> +		.flags	= IORESOURCE_MEM,
>> +	},
>> +};
>> +
>> +static struct platform_device mityomapl138_nandflash_device = {
>> +	.name		= "davinci_nand",
>> +	.id		= 0,
>> +	.dev		= {
>> +		.platform_data	= &mityomapl138_nandflash_data,
>> +	},
>> +	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
>> +	.resource	= mityomapl138_nandflash_resource,
>> +};
>> +
>> +static struct platform_device *mityomapl138_devices[] __initdata = {
>> +	&mityomapl138_nandflash_device,
>> +};
>> +
>> +static void __init mityomapl138_setup_nand(void)
>> +{
>> +	platform_add_devices(mityomapl138_devices,
>> +				 ARRAY_SIZE(mityomapl138_devices));
>> +}
>> +
>> +static struct davinci_uart_config mityomapl138_uart_config __initdata = {
>> +	.enabled_uarts = 0x7,
>> +};
>> +
>> +static const short mityomap_mii_pins[] = {
>> +	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
>> +	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
>> +	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
>> +	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
>> +	DA850_MDIO_D,
>> +	-1
>> +};
>> +
>> +static const short mityomap_rmii_pins[] = {
>> +	DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
>> +	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
>> +	DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
>> +	DA850_MDIO_D,
>> +	-1
>> +};
>> +
>> +static void __init mityomapl138_config_emac(void)
>> +{
>> +	void __iomem *cfg_chip3_base;
>> +	int ret;
>> +	u32 val;
>> +	struct davinci_soc_info *soc_info = &davinci_soc_info;
>> +	soc_info->emac_pdata->rmii_en = 0; /* hardcoded for now */
>> +
>> +	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
>> +	val = __raw_readl(cfg_chip3_base);
>> +
>> +	if (soc_info->emac_pdata->rmii_en) {
>> +		val |= BIT(8);
>> +		ret = davinci_cfg_reg_list(mityomap_rmii_pins);
>> +		pr_info("RMII PHY configured\n");
>> +	} else {
>> +		val &= ~BIT(8);
>> +		ret = davinci_cfg_reg_list(mityomap_mii_pins);
>> +		pr_info("MII PHY configured\n");
>> +	}
>> +
>> +	if (ret) {
>> +		pr_warning("mii/rmii mux setup failed: %d\n", ret);
>> +		return;
>> +	}
>> +
>> +	/* configure the CFGCHIP3 register for RMII or MII */
>> +	__raw_writel(val, cfg_chip3_base);
>> +
>> +	soc_info->emac_pdata->phy_mask = MITYOMAPL138_PHY_MASK;
>> +	pr_info("setting phy_mask to %x\n", soc_info->emac_pdata->phy_mask);
>> +	soc_info->emac_pdata->mdio_max_freq = MITYOMAPL138_MDIO_FREQUENCY;
>> +
>> +	ret = da8xx_register_emac();
>> +	if (ret)
>> +		pr_warning("emac registration failed: %d\n", ret);
>> +}
>> +
>> +static struct davinci_pm_config da850_pm_pdata = {
>> +	.sleepcount = 128,
>> +};
>> +
>> +static struct platform_device da850_pm_device = {
>> +	.name	= "pm-davinci",
>> +	.dev = {
>> +		.platform_data  = &da850_pm_pdata,
>> +	},
>> +	.id	= -1,
>> +};
>> +
>> +static void __init mityomapl138_init(void)
>> +{
>> +	int ret;
>> +
>> +	/* for now, no special EDMA channels are reserved */
>> +	ret = da850_register_edma(NULL);
>> +	if (ret)
>> +		pr_warning("edma registration failed: %d\n", ret);
>> +
>> +	ret = da8xx_register_watchdog();
>> +	if (ret)
>> +		pr_warning("watchdog registration failed: %d\n", ret);
>> +
>> +	davinci_serial_init(&mityomapl138_uart_config);
>> +
>> +	mityomapl138_setup_nand();
>> +
>> +	mityomapl138_config_emac();
>> +
>> +	ret = da8xx_register_rtc();
>> +	if (ret)
>> +		pr_warning("rtc setup failed: %d\n", ret);
>> +
>> +	ret = da850_register_cpufreq("pll0_sysclk3");
>> +	if (ret)
>> +		pr_warning("cpufreq registration failed: %d\n", ret);
>> +
>> +	ret = da8xx_register_cpuidle();
>> +	if (ret)
>> +		pr_warning("cpuidle registration failed: %d\n", ret);
>> +
>> +	ret = da850_register_pm(&da850_pm_device);
>> +	if (ret)
>> +		pr_warning("da850_evm_init: suspend registration failed: %d\n",
>> +				ret);
>> +}
>> +
>> +#ifdef CONFIG_SERIAL_8250_CONSOLE
>> +static int __init mityomapl138_console_init(void)
>> +{
> You need a machine_is_* check here since this will be run whenever this
> is compiled in.  E.g., if a kernel is built to support all da8xx platforms,
>
> In fact, the da850-evm board file should have this too since when both
> this board and the EVM are compiled in, they will both be setting a
> different preferred console.

OK.  I had wondered about that.  I will add machine checks for both files
and resubmit.  Thanks.

>> +	return add_preferred_console("ttyS", 1, "115200");
>> +}
>> +console_initcall(mityomapl138_console_init);
>> +#endif
>> +
>> +static void __init mityomapl138_map_io(void)
>> +{
>> +	da850_init();
>> +}
>> +
>> +MACHINE_START(MITYOMAPL138, "MityDSP-L138/MityARM-1808")
>> +	.phys_io	= IO_PHYS,
>> +	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
>> +	.boot_params	= (DA8XX_DDR_BASE + 0x100),
>> +	.map_io		= mityomapl138_map_io,
>> +	.init_irq	= cp_intc_init,
>> +	.timer		= &davinci_timer,
>> +	.init_machine	= mityomapl138_init,
>> +MACHINE_END
>> diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
>> index 15a6192..d370391 100644
>> --- a/arch/arm/mach-davinci/include/mach/uncompress.h
>> +++ b/arch/arm/mach-davinci/include/mach/uncompress.h
>> @@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
>>  		/* DA8xx boards */
>>  		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
>>  		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
>> +		DEBUG_LL_DA8XX(mityomapl138,		1);
>>  
>>  		/* TNETV107x boards */
>>  		DEBUG_LL_TNETV107X(tnetv107x,		1);
> Kevin


From khilman at deeprootsystems.com  Mon Aug 30 11:21:43 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Mon, 30 Aug 2010 09:21:43 -0700
Subject: [PATCH] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <4C7BCFC9.7050004@criticallink.com> (Michael Williamson's message
	of "Mon, 30 Aug 2010 11:35:37 -0400")
References: <4C78FA26.4040801@criticallink.com>
	<87k4n89m3s.fsf@deeprootsystems.com>
	<4C7BCFC9.7050004@criticallink.com>
Message-ID: <87mxs48414.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

[...]

>>> +struct mtd_partition mityomapl138_nandflash_partition[] = {
>>> +	{
>>> +		.name		= "rootfs",
>>> +		.offset		= 0,
>>> +		.size		= SZ_128M,
>>> +		.mask_flags	= 0, /* MTD_WRITEABLE, */
>>> +	},
>>> +	{
>>> +		.name		= "homefs",
>>> +		.offset		= MTDPART_OFS_APPEND,
>>> +		.size		= MTDPART_SIZ_FULL,
>>> +		.mask_flags	= 0,
>>> +	},
>>> +};
>> It's your board, you can have your partitions however you choose, but
>> just curious... Is your bootloader somehwhere in NAND too?  Also 128M
>> seems pretty small for a root filesystem.
>>
> The bootloader (u-boot) and kernel is on an onboard SPI-NOR device.  I was
> going add the SPI stuff and the appropriate partitions on a next round
> of patches (if this one makes it) per your guidance.  It's not needed to get
> the kernel up and running, which was why we left it out.  There's nothing
> precluding using NAND for storing the bootloader, etc., but by default we
> weren't going to do that.  

OK, thanks for the clarification.  As I mentioned, I'm not going to
dictate what goes here, you get to decide.  I was just curious.

> We're planning to normally support partition options
> passed by command line anyway (MTDPARTS).  My understanding is that partition
> options would override these values, right?

Correct.

> The 128M supports quite a few configurations so far (we're sitting at around
> 68M with the bloat of Qt-embedded jammed in there).  This was mostly a line
> in the sand.  Since I will be resubmitting, I might bump it up.  Thanks.

OK.

Kevin


From vm.rod25 at gmail.com  Mon Aug 30 12:38:19 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Mon, 30 Aug 2010 12:38:19 -0500
Subject: [PATCH] hawkboard
In-Reply-To: <1283019503-3070-1-git-send-email-vm.rod25@gmail.com>
References: <1283019503-3070-1-git-send-email-vm.rod25@gmail.com>
Message-ID: <AANLkTi=5QH6DDEX=Os0LsqjYaNQtvyqYZVyDWJd=XdRK@mail.gmail.com>

Basic support for Hawkboard OMAPL138 just UART cominication is included

Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>

Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03 from
? ? ? ?Kernel development tree for TI DaVinci family of processors

? ? ? ?This patch works with basic da8xx_omapl_defconfig, it just have
basic support
? ? ? ?for UART console
---
?arch/arm/mach-davinci/Kconfig ? ? ? ? ? ? ? ? ? | ? ?9 +++
?arch/arm/mach-davinci/Makefile ? ? ? ? ? ? ? ? ?| ? ?1 +
?arch/arm/mach-davinci/board-da850-hawk.c ? ? ? ?| ? 69 +++++++++++++++++++++++
?arch/arm/mach-davinci/include/mach/uncompress.h | ? ?1 +
?4 files changed, 80 insertions(+), 0 deletions(-)
?create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2bf03e9..fd8a11c 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -185,6 +185,15 @@ config MACH_TNETV107X
? ? ? ?help
? ? ? ? ?Say Y here to select the TI TNETV107X Evaluation Module.

+config MACH_OMAPL138_HAWKBOARD
+ ? ? ? bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
+ ? ? ? default ARCH_DAVINCI_DA850
+ ? ? ? depends on ARCH_DAVINCI_DA850
+ ? ? ? help
+ ? ? ? ? Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
+ ? ? ? ? Information of this board may be found at
+ ? ? ? ? http://www.hawkboard.org/
+
?config DAVINCI_MUX
? ? ? ?bool "DAVINCI multiplexing support"
? ? ? ?depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..fd271cd 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) ?+= board-dm365-evm.o
?obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) ? += board-da830-evm.o
?obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) ? += board-da850-evm.o
?obj-$(CONFIG_MACH_TNETV107X) ? ? ? ? ? += board-tnetv107x-evm.o
+obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD) ?+= board-da850-hawk.o

?# Power Management
?obj-$(CONFIG_CPU_FREQ) ? ? ? ? ? ? ? ? += cpufreq.o
diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
b/arch/arm/mach-davinci/board-da850-hawk.c
new file mode 100644
index 0000000..e34bcbb
--- /dev/null
+++ b/arch/arm/mach-davinci/board-da850-hawk.c
@@ -0,0 +1,69 @@
+/*
+ * Hawkboar.org based on TI's OMAP-L138 Platform
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Derived from: arch/arm/mach-davinci/board-da850-evm.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/gpio.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+
+
+
+static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
+ ? ? ? .enabled_uarts = 0x7,
+};
+
+static __init void omapl138_hawk_init(void)
+{
+
+ ? ? ? davinci_serial_init(&omapl138_hawk_uart_config);
+
+ ? ? ? /*
+ ? ? ? ?* shut down uart 0 and 1; they are not used on the board and
+ ? ? ? ?* accessing them causes endless "too much work in irq53" messages
+ ? ? ? ?* with arago fs
+ ? ? ? ?*/
+ ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
+ ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init omapl138_hawk_console_init(void)
+{
+ ? ? ? return add_preferred_console("ttyS", 2, "115200");
+}
+console_initcall(omapl138_hawk_console_init);
+#endif
+
+static void __init omapl138_hawk_map_io(void)
+{
+ ? ? ? da850_init();
+}
+
+MACHINE_START(OMAPL138_HAWKBOARD, "OMAPL 138 Hawkboard.org")
+ ? ? ? .phys_io ? ? ? ?= IO_PHYS,
+ ? ? ? .io_pg_offst ? ?= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
+ ? ? ? .boot_params ? ?= (DA8XX_DDR_BASE + 0x100),
+ ? ? ? .map_io ? ? ? ? = omapl138_hawk_map_io,
+ ? ? ? .init_irq ? ? ? = cp_intc_init,
+ ? ? ? .timer ? ? ? ? ?= &davinci_timer,
+ ? ? ? .init_machine ? = omapl138_hawk_init,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
b/arch/arm/mach-davinci/include/mach/uncompress.h
index 15a6192..640f834 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
? ? ? ? ? ? ? ?/* DA8xx boards */
? ? ? ? ? ? ? ?DEBUG_LL_DA8XX(davinci_da830_evm, ? ? ? 2);
? ? ? ? ? ? ? ?DEBUG_LL_DA8XX(davinci_da850_evm, ? ? ? 2);
+ ? ? ? ? ? ? ? DEBUG_LL_DA8XX(omapl138_hawkboard, ? ? ?2);

? ? ? ? ? ? ? ?/* TNETV107x boards */
? ? ? ? ? ? ? ?DEBUG_LL_TNETV107X(tnetv107x, ? ? ? ? ? 1);
--
1.6.0.5

From vm.rod25 at gmail.com  Mon Aug 30 12:41:24 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Mon, 30 Aug 2010 12:41:24 -0500
Subject: [PATCH] hawkboard
Message-ID: <AANLkTimZoBJx=nvHmXv9Z1TJ0uPt=cLMm1wh9LPZahhG@mail.gmail.com>

Basic support for Hawkboard OMAPL138 just UART cominication is included

Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>

Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03 from
       Kernel development tree for TI DaVinci family of processors

       This patch works with basic da8xx_omapl_defconfig, it just have
basic support
       for UART console
---
 arch/arm/mach-davinci/Kconfig                   |    9 +++
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-da850-hawk.c        |   69 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 4 files changed, 80 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2bf03e9..fd8a11c 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -185,6 +185,15 @@ config MACH_TNETV107X
       help
         Say Y here to select the TI TNETV107X Evaluation Module.

+config MACH_OMAPL138_HAWKBOARD
+       bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
+       default ARCH_DAVINCI_DA850
+       depends on ARCH_DAVINCI_DA850
+       help
+         Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
+         Information of this board may be found at
+         http://www.hawkboard.org/
+
 config DAVINCI_MUX
       bool "DAVINCI multiplexing support"
       depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..fd271cd 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)  += board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)   += board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)   += board-da850-evm.o
 obj-$(CONFIG_MACH_TNETV107X)           += board-tnetv107x-evm.o
+obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD)  += board-da850-hawk.o

 # Power Management
 obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o
diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
b/arch/arm/mach-davinci/board-da850-hawk.c
new file mode 100644
index 0000000..e34bcbb
--- /dev/null
+++ b/arch/arm/mach-davinci/board-da850-hawk.c
@@ -0,0 +1,69 @@
+/*
+ * Hawkboar.org based on TI's OMAP-L138 Platform
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Derived from: arch/arm/mach-davinci/board-da850-evm.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/gpio.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+
+
+
+static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
+       .enabled_uarts = 0x7,
+};
+
+static __init void omapl138_hawk_init(void)
+{
+
+       davinci_serial_init(&omapl138_hawk_uart_config);
+
+       /*
+        * shut down uart 0 and 1; they are not used on the board and
+        * accessing them causes endless "too much work in irq53" messages
+        * with arago fs
+        */
+       __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
+       __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init omapl138_hawk_console_init(void)
+{
+       return add_preferred_console("ttyS", 2, "115200");
+}
+console_initcall(omapl138_hawk_console_init);
+#endif
+
+static void __init omapl138_hawk_map_io(void)
+{
+       da850_init();
+}
+
+MACHINE_START(OMAPL138_HAWKBOARD, "OMAPL 138 Hawkboard.org")
+       .phys_io        = IO_PHYS,
+       .io_pg_offst    = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
+       .boot_params    = (DA8XX_DDR_BASE + 0x100),
+       .map_io         = omapl138_hawk_map_io,
+       .init_irq       = cp_intc_init,
+       .timer          = &davinci_timer,
+       .init_machine   = omapl138_hawk_init,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
b/arch/arm/mach-davinci/include/mach/uncompress.h
index 15a6192..640f834 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
               /* DA8xx boards */
               DEBUG_LL_DA8XX(davinci_da830_evm,       2);
               DEBUG_LL_DA8XX(davinci_da850_evm,       2);
+               DEBUG_LL_DA8XX(omapl138_hawkboard,      2);

               /* TNETV107x boards */
               DEBUG_LL_TNETV107X(tnetv107x,           1);
--
1.6.0.5

From vm.rod25 at gmail.com  Mon Aug 30 12:45:34 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Mon, 30 Aug 2010 12:45:34 -0500
Subject: [PATCH] hawkboard
Message-ID: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>

Basic support for Hawkboard OMAPL138 just UART cominication is included

Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>

Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03 from
       Kernel development tree for TI DaVinci family of processors

       This patch works with basic da8xx_omapl_defconfig, it just have
basic support
       for UART console
---
 arch/arm/mach-davinci/Kconfig                   |    9 +++
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-da850-hawk.c        |   69 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 4 files changed, 80 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2bf03e9..fd8a11c 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -185,6 +185,15 @@ config MACH_TNETV107X
       help
         Say Y here to select the TI TNETV107X Evaluation Module.

+config MACH_OMAPL138_HAWKBOARD
+       bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
+       default ARCH_DAVINCI_DA850
+       depends on ARCH_DAVINCI_DA850
+       help
+         Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
+         Information of this board may be found at
+         http://www.hawkboard.org/
+
 config DAVINCI_MUX
       bool "DAVINCI multiplexing support"
       depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..fd271cd 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)  += board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)   += board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)   += board-da850-evm.o
 obj-$(CONFIG_MACH_TNETV107X)           += board-tnetv107x-evm.o
+obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD)  += board-da850-hawk.o

 # Power Management
 obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o
diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
b/arch/arm/mach-davinci/board-da850-hawk.c
new file mode 100644
index 0000000..e34bcbb
--- /dev/null
+++ b/arch/arm/mach-davinci/board-da850-hawk.c
@@ -0,0 +1,69 @@
+/*
+ * Hawkboar.org based on TI's OMAP-L138 Platform
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Derived from: arch/arm/mach-davinci/board-da850-evm.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/gpio.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+
+
+
+static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
+       .enabled_uarts = 0x7,
+};
+
+static __init void omapl138_hawk_init(void)
+{
+
+       davinci_serial_init(&omapl138_hawk_uart_config);
+
+       /*
+        * shut down uart 0 and 1; they are not used on the board and
+        * accessing them causes endless "too much work in irq53" messages
+        * with arago fs
+        */
+       __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
+       __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init omapl138_hawk_console_init(void)
+{
+       return add_preferred_console("ttyS", 2, "115200");
+}
+console_initcall(omapl138_hawk_console_init);
+#endif
+
+static void __init omapl138_hawk_map_io(void)
+{
+       da850_init();
+}
+
+MACHINE_START(OMAPL138_HAWKBOARD, "OMAPL 138 Hawkboard.org")
+       .phys_io        = IO_PHYS,
+       .io_pg_offst    = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
+       .boot_params    = (DA8XX_DDR_BASE + 0x100),
+       .map_io         = omapl138_hawk_map_io,
+       .init_irq       = cp_intc_init,
+       .timer          = &davinci_timer,
+       .init_machine   = omapl138_hawk_init,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
b/arch/arm/mach-davinci/include/mach/uncompress.h
index 15a6192..640f834 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
               /* DA8xx boards */
               DEBUG_LL_DA8XX(davinci_da830_evm,       2);
               DEBUG_LL_DA8XX(davinci_da850_evm,       2);
+               DEBUG_LL_DA8XX(omapl138_hawkboard,      2);

               /* TNETV107x boards */
               DEBUG_LL_TNETV107X(tnetv107x,           1);
--
1.6.0.5

From vm.rod25 at gmail.com  Mon Aug 30 12:56:17 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Mon, 30 Aug 2010 12:56:17 -0500
Subject: Problem git send patch
Message-ID: <AANLkTikn_zEgqL2DA5-Q+62jyKtSoaOeQf=4+suUp18N@mail.gmail.com>

Hi Kevin just to tell you that I have already sent the patch for
Hawkboard omap l138 , sorry for so many mails but I commit a mistake
with my git sent mail, and i sent to another list in the beginning

Hope it helps for open source in davinci technology

Please do not hesitate to tell me if something is wrong with my patch

Thanks for all your help , waiting for your response

Sincerely yours

Victor Rodriguez

From cring at ti.com  Mon Aug 30 13:23:33 2010
From: cring at ti.com (Ring, Chris)
Date: Mon, 30 Aug 2010 13:23:33 -0500
Subject: Problem with 256MB DDR on DM365
In-Reply-To: <4C7BB626.3020204@einfochips.com>
References: <4C7BB626.3020204@einfochips.com>
Message-ID: <92CDD168D1E81F4F9D3839DC45903FC68A707417@dlee03.ent.ti.com>

Are you using CMEM?  http://processors.wiki.ti.com/index.php/CMEM_Overview

If so, maybe there's a memory map collision between the kernel and CMEM?  Hint - CMEM's memory map is set when the driver is loaded (insmod param).

Chris

________________________________
From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of hitesh
Sent: Monday, August 30, 2010 6:46 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Problem with 256MB DDR on DM365

Hi ALL

We are facing one issue related to the memory allocation on DM365 based board. We have 256MB DDR on our board.
But when we allocate more than 128 MB of memory to the kernel (in bootargs), sometimes kernel gives paging request errors while running application or sometimes it is not able to even boot (i.e. kernel panic).

We have done changes in the U-boot to configure the DDR of 256MB.

We have modified the following U-boot source file:
File: include/configs/davinci_dm365_evm.h
Change: (As below)

#define CFG_MALLOC_LEN                  (0x40000 + 128*1024)         /* malloc () len */
#define CFG_GBL_DATA_SIZE               (128)                        /* reserved for initial data */
#define CFG_MEMTEST_START               (0x82000000)                 /* memtest start address  */
#define CFG_MEMTEST_END                 (0x90000000)                 /* 16MB RAM test          */
#define CONFIG_NR_DRAM_BANKS            (1)                          /* we have 1 bank of DRAM */
#define CONFIG_STACKSIZE                (256*1024)                   /* regular stack          */
#define PHYS_SDRAM_1                    0x80000000                   /* DDR Start              */
// ORIGINAL: #define PHYS_SDRAM_1_SIZE  0x8000000                    /* DDR size 128MB         */
#define PHYS_SDRAM_1_SIZE               0x10000000                   /* DDR size 256MB         */


Details of our DM365 board is as follows:

 *   Silicon Version of DM365:   DM365ZCE30
 *   DVSDK Version:              dvsdk_2_10_01_18
 *   Linux Version:              linux-2.6.18_pro500
 *   PSP Version:                PSP_02_10_00_14
 *   DDR Size:                   256MB.

Any body help me what are the changes are still left?
Is there any missing in setting?
What are the setting if we go from 128MB ddr to 256MB size of DDR?

Thanks
Hitesh Patel
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100830/cf2650ad/attachment-0001.html>

From michael.williamson at criticallink.com  Mon Aug 30 19:55:25 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Mon, 30 Aug 2010 20:55:25 -0400
Subject: [PATCH v1] davinci: Initial support for MityDSP-L138/MityARM-1808
Message-ID: <4C7C52FD.6010608@criticallink.com>

This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
on the da850 davinci CPU architecture.  Information on these SOMs may be 
found at http://www.mitydsp.com.

Basic support for the console UART, NAND, and EMAC (MII interface) is 
included in this patch. 

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's tree 
(2.6.36-rc2).

Changes since v0:
  1) Added CONFIG_REGULATOR_DUMMY to da8xx_omapl_defconfig to support
     DA8XX machines not providing voltage regulation.
  2) Added machine checks on da830/da850 EVM as well as MityDSP-L138 
     console init routines.
  3) Defaulted MACH_MITYOMAPL138 on for ARCH_DAVINCI_DA850 selection in 
     KConfig.
  4) Fixed comment block whitespace violation.  

(Elected to leave the default NAND partition as is)

 arch/arm/configs/da8xx_omapl_defconfig          |    1 +
 arch/arm/mach-davinci/Kconfig                   |    9 +
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-da830-evm.c         |    3 +
 arch/arm/mach-davinci/board-da850-evm.c         |    3 +
 arch/arm/mach-davinci/board-mityomapl138.c      |  220 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 7 files changed, 238 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/da8xx_omapl_defconfig b/arch/arm/configs/da8xx_omapl_defconfig
index ba66705..3952a4e 100644
--- a/arch/arm/configs/da8xx_omapl_defconfig
+++ b/arch/arm/configs/da8xx_omapl_defconfig
@@ -79,6 +79,7 @@ CONFIG_I2C_DAVINCI=y
 # CONFIG_HWMON is not set
 CONFIG_WATCHDOG=y
 CONFIG_REGULATOR=y
+CONFIG_REGULATOR_DUMMY=y
 CONFIG_REGULATOR_TPS6507X=y
 CONFIG_FB=y
 CONFIG_FB_DA8XX=y
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2bf03e9..633eccb 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -185,6 +185,15 @@ config MACH_TNETV107X
 	help
 	  Say Y here to select the TI TNETV107X Evaluation Module.
 
+config MACH_MITYOMAPL138
+	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
+	default ARCH_DAVINCI_DA850
+	depends on ARCH_DAVINCI_DA850
+	help
+	  Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
+	  System on Module.  Information on this SoM may be found at
+	  http://www.mitydsp.com
+
 config DAVINCI_MUX
 	bool "DAVINCI multiplexing support"
 	depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..3e966e8 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
 obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
+obj-$(CONFIG_MACH_MITYOMAPL138)		+= board-mityomapl138.o
 
 # Power Management
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 292e8b7..e51a80f 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -586,6 +586,9 @@ static __init void da830_evm_init(void)
 #ifdef CONFIG_SERIAL_8250_CONSOLE
 static int __init da830_evm_console_init(void)
 {
+	if (!machine_is_davinci_da830_evm())
+		return 0;
+
 	return add_preferred_console("ttyS", 2, "115200");
 }
 console_initcall(da830_evm_console_init);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 190ebd3..d491b5f 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -847,6 +847,9 @@ static __init void da850_evm_init(void)
 #ifdef CONFIG_SERIAL_8250_CONSOLE
 static int __init da850_evm_console_init(void)
 {
+	if (!machine_is_davinci_da850_evm())
+		return 0;
+
 	return add_preferred_console("ttyS", 2, "115200");
 }
 console_initcall(da850_evm_console_init);
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
new file mode 100644
index 0000000..7338adb
--- /dev/null
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -0,0 +1,220 @@
+/*
+ * Critical Link MityOMAP-L138 SoM
+ *
+ * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of
+ * any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/common.h>
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+#include <mach/nand.h>
+#include <mach/mux.h>
+
+#define MITYOMAPL138_PHY_MASK		0x08 /* hardcoded for now */
+#define MITYOMAPL138_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
+
+/*
+ * MityDSP-L138 includes a 256 MByte large-page NAND flash
+ * (128K blocks).
+ */
+struct mtd_partition mityomapl138_nandflash_partition[] = {
+	{
+		.name		= "rootfs",
+		.offset		= 0,
+		.size		= SZ_128M,
+		.mask_flags	= 0, /* MTD_WRITEABLE, */
+	},
+	{
+		.name		= "homefs",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0,
+	},
+};
+
+static struct davinci_nand_pdata mityomapl138_nandflash_data = {
+	.parts		= mityomapl138_nandflash_partition,
+	.nr_parts	= ARRAY_SIZE(mityomapl138_nandflash_partition),
+	.ecc_mode	= NAND_ECC_HW,
+	.options	= NAND_USE_FLASH_BBT | NAND_BUSWIDTH_16,
+	.ecc_bits   = 1, /* 4 bit mode is not supported with 16 bit NAND */
+};
+
+static struct resource mityomapl138_nandflash_resource[] = {
+	{
+		.start	= DA8XX_AEMIF_CS3_BASE,
+		.end	= DA8XX_AEMIF_CS3_BASE + SZ_512K + 2 * SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.start	= DA8XX_AEMIF_CTL_BASE,
+		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device mityomapl138_nandflash_device = {
+	.name		= "davinci_nand",
+	.id		= 0,
+	.dev		= {
+		.platform_data	= &mityomapl138_nandflash_data,
+	},
+	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
+	.resource	= mityomapl138_nandflash_resource,
+};
+
+static struct platform_device *mityomapl138_devices[] __initdata = {
+	&mityomapl138_nandflash_device,
+};
+
+static void __init mityomapl138_setup_nand(void)
+{
+	platform_add_devices(mityomapl138_devices,
+				 ARRAY_SIZE(mityomapl138_devices));
+}
+
+static struct davinci_uart_config mityomapl138_uart_config __initdata = {
+	.enabled_uarts = 0x7,
+};
+
+static const short mityomap_mii_pins[] = {
+	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
+	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
+	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
+	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
+static const short mityomap_rmii_pins[] = {
+	DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
+	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
+	DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
+static void __init mityomapl138_config_emac(void)
+{
+	void __iomem *cfg_chip3_base;
+	int ret;
+	u32 val;
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	soc_info->emac_pdata->rmii_en = 0; /* hardcoded for now */
+
+	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+	val = __raw_readl(cfg_chip3_base);
+
+	if (soc_info->emac_pdata->rmii_en) {
+		val |= BIT(8);
+		ret = davinci_cfg_reg_list(mityomap_rmii_pins);
+		pr_info("RMII PHY configured\n");
+	} else {
+		val &= ~BIT(8);
+		ret = davinci_cfg_reg_list(mityomap_mii_pins);
+		pr_info("MII PHY configured\n");
+	}
+
+	if (ret) {
+		pr_warning("mii/rmii mux setup failed: %d\n", ret);
+		return;
+	}
+
+	/* configure the CFGCHIP3 register for RMII or MII */
+	__raw_writel(val, cfg_chip3_base);
+
+	soc_info->emac_pdata->phy_mask = MITYOMAPL138_PHY_MASK;
+	pr_info("setting phy_mask to %x\n", soc_info->emac_pdata->phy_mask);
+	soc_info->emac_pdata->mdio_max_freq = MITYOMAPL138_MDIO_FREQUENCY;
+
+	ret = da8xx_register_emac();
+	if (ret)
+		pr_warning("emac registration failed: %d\n", ret);
+}
+
+static struct davinci_pm_config da850_pm_pdata = {
+	.sleepcount = 128,
+};
+
+static struct platform_device da850_pm_device = {
+	.name	= "pm-davinci",
+	.dev = {
+		.platform_data  = &da850_pm_pdata,
+	},
+	.id	= -1,
+};
+
+static void __init mityomapl138_init(void)
+{
+	int ret;
+
+	/* for now, no special EDMA channels are reserved */
+	ret = da850_register_edma(NULL);
+	if (ret)
+		pr_warning("edma registration failed: %d\n", ret);
+
+	ret = da8xx_register_watchdog();
+	if (ret)
+		pr_warning("watchdog registration failed: %d\n", ret);
+
+	davinci_serial_init(&mityomapl138_uart_config);
+
+	mityomapl138_setup_nand();
+
+	mityomapl138_config_emac();
+
+	ret = da8xx_register_rtc();
+	if (ret)
+		pr_warning("rtc setup failed: %d\n", ret);
+
+	ret = da850_register_cpufreq("pll0_sysclk3");
+	if (ret)
+		pr_warning("cpufreq registration failed: %d\n", ret);
+
+	ret = da8xx_register_cpuidle();
+	if (ret)
+		pr_warning("cpuidle registration failed: %d\n", ret);
+
+	ret = da850_register_pm(&da850_pm_device);
+	if (ret)
+		pr_warning("da850_evm_init: suspend registration failed: %d\n",
+				ret);
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init mityomapl138_console_init(void)
+{
+	if (!machine_is_mityomapl138())
+		return 0;
+
+	return add_preferred_console("ttyS", 1, "115200");
+}
+console_initcall(mityomapl138_console_init);
+#endif
+
+static void __init mityomapl138_map_io(void)
+{
+	da850_init();
+}
+
+MACHINE_START(MITYOMAPL138, "MityDSP-L138/MityARM-1808")
+	.phys_io	= IO_PHYS,
+	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
+	.boot_params	= (DA8XX_DDR_BASE + 0x100),
+	.map_io		= mityomapl138_map_io,
+	.init_irq	= cp_intc_init,
+	.timer		= &davinci_timer,
+	.init_machine	= mityomapl138_init,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 15a6192..d370391 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 		/* DA8xx boards */
 		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
 		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+		DEBUG_LL_DA8XX(mityomapl138,		1);
 
 		/* TNETV107x boards */
 		DEBUG_LL_TNETV107X(tnetv107x,		1);

From rohan_javed at yahoo.co.uk  Mon Aug 30 22:37:34 2010
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Tue, 31 Aug 2010 03:37:34 +0000 (GMT)
Subject: Problem with 256MB DDR on DM365
In-Reply-To: <4C7BB626.3020204@einfochips.com>
Message-ID: <737520.87770.qm@web24107.mail.ird.yahoo.com>


??? 128Mb of DDR? is selected from UBL and it depends on whether the RAM is selected with 16bit bus width or 32-bit bus width

Regard's

Rohan Tabish
--- On Mon, 30/8/10, hitesh <hitesh.patel at einfochips.com> wrote:

From: hitesh <hitesh.patel at einfochips.com>
Subject: Problem with 256MB DDR on DM365
To: davinci-linux-open-source at linux.davincidsp.com
Date: Monday, 30 August, 2010, 18:46



  

    
  Hi ALL

     

      We are facing one issue related to the memory allocation on DM365
      based board. We have 256MB DDR on our board.

      But when we allocate more than 128 MB of memory to the kernel (in
      bootargs), sometimes kernel gives paging request errors while
      running application or sometimes it is not able to even boot (i.e.
      kernel panic).

      

      We have done changes in the U-boot to configure the DDR of 256MB.
      

      

      We have modified the following U-boot source file: 

      File: include/configs/davinci_dm365_evm.h

      Change: (As below)

      

      #define CFG_MALLOC_LEN????????????????? (0x40000 +
      128*1024)???????? /* malloc () len */

      #define CFG_GBL_DATA_SIZE??????????????
      (128)??????????????????????? /* reserved for initial data */

      #define CFG_MEMTEST_START??????????????
      (0x82000000)???????????????? /* memtest start address? */

      #define CFG_MEMTEST_END????????????????
      (0x90000000)???????????????? /* 16MB RAM test????????? */

      #define CONFIG_NR_DRAM_BANKS??????????? (1)
      ???????????????????????? /* we have 1 bank of DRAM */

      #define CONFIG_STACKSIZE??????????????? (256*1024)? ? ? ? ? ? ?
      ???? /* regular stack????????? */

      #define PHYS_SDRAM_1?????????? ? ? ? ??
      0x80000000?????????????????? /* DDR Start????????????? */

      // ORIGINAL: #define PHYS_SDRAM_1_SIZE?
      0x8000000??????????????????? /* DDR size 128MB???????? */

      #define PHYS_SDRAM_1_SIZE??????????????
      0x10000000?????????????????? /* DDR size 256MB???????? */

      

      

      Details of our DM365 board is as follows:

    
    
      Silicon Version of DM365:?? DM365ZCE30
      DVSDK Version:????????????? dvsdk_2_10_01_18
      Linux Version:????????????? linux-2.6.18_pro500

        
      PSP Version:??????????????? PSP_02_10_00_14
      DDR Size:?????????????????? 256MB.
    
    Any body help me what are the changes are still left?

      Is there any missing in setting?

      What are the setting if we go from 128MB ddr to 256MB size of DDR?

      

      Thanks

      Hitesh Patel

      ---

    
  

-----Inline Attachment Follows-----

_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100831/af9577e8/attachment.html>

From hitesh.patel at einfochips.com  Tue Aug 31 00:00:11 2010
From: hitesh.patel at einfochips.com (hitesh)
Date: Tue, 31 Aug 2010 10:30:11 +0530
Subject: Problem with 256MB DDR on DM365
In-Reply-To: <alpine.LRH.2.00.1008300702340.18001@sv-04.mtinet.com>
References: <4C7BB626.3020204@einfochips.com>
	<alpine.LRH.2.00.1008300702340.18001@sv-04.mtinet.com>
Message-ID: <4C7C8C5B.1080703@einfochips.com>

  On 08/30/2010 07:36 PM, Hank Magnuski wrote:
> itesh wrot
Hi Hank,

Thanks for reply.
Can you please explain me what type of changes you had done in kernel?

Thanks,
Hitesh

From hitesh.patel at einfochips.com  Tue Aug 31 00:03:53 2010
From: hitesh.patel at einfochips.com (hitesh)
Date: Tue, 31 Aug 2010 10:33:53 +0530
Subject: Problem with 256MB DDR on DM365
In-Reply-To: <92CDD168D1E81F4F9D3839DC45903FC68A707417@dlee03.ent.ti.com>
References: <4C7BB626.3020204@einfochips.com>
	<92CDD168D1E81F4F9D3839DC45903FC68A707417@dlee03.ent.ti.com>
Message-ID: <4C7C8D39.9050406@einfochips.com>

  Hi Chris,

There is no any collision between the kernel and CMEM because I am able 
to boot the kernel with more the 128MB memory allocation to kernel.
It get hang or give kernel panic in booting.

Thanks
Hitesh Patel

On 08/30/2010 11:53 PM, Ring, Chris wrote:
> Are you using CMEM? http://processors.wiki.ti.com/index.php/CMEM_Overview
> If so, maybe there's a memory map collision between the kernel and 
> CMEM?  Hint - CMEM's memory map is set when the driver is loaded 
> (insmod param).
> Chris
>
>     ------------------------------------------------------------------------
>     *From:* davinci-linux-open-source-bounces at linux.davincidsp.com
>     [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com]
>     *On Behalf Of *hitesh
>     *Sent:* Monday, August 30, 2010 6:46 AM
>     *To:* davinci-linux-open-source at linux.davincidsp.com
>     *Subject:* Problem with 256MB DDR on DM365
>
>     Hi ALL
>
>     We are facing one issue related to the memory allocation on DM365
>     based board. We have 256MB DDR on our board.
>     But when we allocate more than 128 MB of memory to the kernel (in
>     bootargs), sometimes kernel gives paging request errors while
>     running application or sometimes it is not able to even boot (i.e.
>     kernel panic).
>
>     We have done changes in the U-boot to configure the DDR of 256MB.
>
>     We have modified the following U-boot source file:
>     File: include/configs/davinci_dm365_evm.h
>     Change: (As below)
>
>     #define CFG_MALLOC_LEN                  (0x40000 +
>     128*1024)         /* malloc () len */
>     #define CFG_GBL_DATA_SIZE              
>     (128)                        /* reserved for initial data */
>     #define CFG_MEMTEST_START              
>     (0x82000000)                 /* memtest start address  */
>     #define CFG_MEMTEST_END                
>     (0x90000000)                 /* 16MB RAM test          */
>     #define CONFIG_NR_DRAM_BANKS            (1)
>                              /* we have 1 bank of DRAM */
>     #define CONFIG_STACKSIZE                (256*1024)             
>          /* regular stack          */
>     #define PHYS_SDRAM_1                   
>     0x80000000                   /* DDR Start              */
>     // ORIGINAL: #define PHYS_SDRAM_1_SIZE 
>     0x8000000                    /* DDR size 128MB         */
>     #define PHYS_SDRAM_1_SIZE              
>     0x10000000                   /* DDR size 256MB         */
>
>
>     Details of our DM365 board is as follows:
>
>         * Silicon Version of DM365:   DM365ZCE30
>         * DVSDK Version:              dvsdk_2_10_01_18
>         * Linux Version:              linux-2.6.18_pro500
>         * PSP Version:                PSP_02_10_00_14
>         * DDR Size:                   256MB.
>
>     Any body help me what are the changes are still left?
>     Is there any missing in setting?
>     What are the setting if we go from 128MB ddr to 256MB size of DDR?
>
>     Thanks
>     Hitesh Patel
>     ---
>
>
> ____________________________________________________________________________________
> Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.
> _
>   ___________________________________________________________________________________
>
>
>
>
> *Email Scanned for Virus & Dangerous Content by :* 
> *www.CleanMailGateway.com*
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100831/a05ef519/attachment.html>

From hankm at ncast.com  Tue Aug 31 00:06:25 2010
From: hankm at ncast.com (Hank Magnuski)
Date: Mon, 30 Aug 2010 22:06:25 -0700 (PDT)
Subject: Problem with 256MB DDR on DM365
In-Reply-To: <4C7C8C5B.1080703@einfochips.com>
References: <4C7BB626.3020204@einfochips.com>
	<alpine.LRH.2.00.1008300702340.18001@sv-04.mtinet.com>
	<4C7C8C5B.1080703@einfochips.com>
Message-ID: <alpine.LRH.2.00.1008302205210.15294@sv-04.mtinet.com>


In bootargs:

  MEM=256M

That's all.

> Hi Hank,
>
> Thanks for reply.
> Can you please explain me what type of changes you had done in kernel?
>
> Thanks,
> Hitesh


From hitesh.patel at einfochips.com  Tue Aug 31 00:13:56 2010
From: hitesh.patel at einfochips.com (hitesh)
Date: Tue, 31 Aug 2010 10:43:56 +0530
Subject: Problem with 256MB DDR on DM365
In-Reply-To: <alpine.LRH.2.00.1008302205210.15294@sv-04.mtinet.com>
References: <4C7BB626.3020204@einfochips.com>
	<alpine.LRH.2.00.1008300702340.18001@sv-04.mtinet.com>
	<4C7C8C5B.1080703@einfochips.com>
	<alpine.LRH.2.00.1008302205210.15294@sv-04.mtinet.com>
Message-ID: <4C7C8F94.2030905@einfochips.com>

  Hi Hank,
I f pass MEM=256MB then I can't able to boot kernel and log is below.

U-Boot 1.3.4 (Jul 29 2010 - 07:26:57)

I2C:   ready
DRAM:  256 MB
NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 
1GiB 3,3V 8-bit)
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 
8-bit)
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
2048 MiB
In:    serial
Out:   serial
Err:   serial

EEPROM @ 0x50 read FAILED!!!
Ethernet PHY: GENERIC @ 0x00
Hit any key to stop autoboot:  0
DM365 EVM :>
DM365 EVM :>setenv bootargs console=ttyS1,115200n8 noinitrd rw ip=dhcp 
root=/dev/nfs nfsroot=10.100.4.179:/opt/DM365/workdir/
filesys,nolock mem=256M 
video=davincifb:vid0=1024x768x16,4800K:vid1=off:osd0=1024x768x16,1600K 
dm365_imp.oper_mode=1 davinci_
capture.device_type=5
DM365 EVM :>boot
TFTP from server 10.100.4.179; our IP address is 10.100.4.172
Filename 'uImage'.
Load address: 0x80700000
Loading: #################################################################
          #########################T 
########################################
          #######################################T 
###########################
          ######
done
Bytes transferred = 2052056 (1f4fd8 hex)
## Booting kernel from Legacy Image at 80700000 ...
    Image Name:   Linux-2.6.18_pro500-davinci_evm-
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2051992 Bytes =  2 MB
    Load Address: 80008000
    Entry Point:  80008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
OK

Starting kernel ...


Thanks
Hitesh



On 08/31/2010 10:36 AM, Hank Magnuski wrote:
>
> In bootargs:
>
>  MEM=256M
>
> That's all.
>
>> Hi Hank,
>>
>> Thanks for reply.
>> Can you please explain me what type of changes you had done in kernel?
>>
>> Thanks,
>> Hitesh
>
>
>
> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>
> ____________________________________________________________________________________ 
>
> Disclaimer: This e-mail message and all attachments transmitted with 
> it are intended solely for the use of the addressee and may contain 
> legally privileged and confidential information. If the reader of this 
> message is not the intended recipient, or an employee or agent 
> responsible for delivering this message to the intended recipient, you 
> are hereby notified that any dissemination, distribution, copying, or 
> other use of this message or its attachments is strictly prohibited. 
> If you have received this message in error, please notify the sender 
> immediately by replying to this message and please delete it from your 
> computer. Any views expressed in this message are those of the 
> individual sender unless otherwise stated.Company has taken enough 
> precautions to prevent the spread of viruses. However the company 
> accepts no liability for any damage caused by any virus transmitted by 
> this email.
> ____________________________________________________________________________________ 
>
>


From caglarakyuz at gmail.com  Tue Aug 31 03:05:34 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Tue, 31 Aug 2010 11:05:34 +0300
Subject: [PATCH] hawkboard
In-Reply-To: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
Message-ID: <201008311105.34712.caglarakyuz@gmail.com>

On Monday 30 August 2010 08:45:34 pm Victor Rodriguez wrote:
> Basic support for Hawkboard OMAPL138 just UART cominication is included
> 
> Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
> 
> Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03
>  from Kernel development tree for TI DaVinci family of processors
> 

I tried to apply this patch on top of 0a50e05, but it seems like patch is 
corrupt or my MUA is breaking it. Are you able to apply this patch from your 
mailbox?

Besides, checkpatch is complaining about errors in the patch. Have you used 
scripts/checkpatch.pl with this patch?

>        This patch works with basic da8xx_omapl_defconfig, it just have
> basic support
>        for UART console

Are you planning to add other peripherals or is this all for now? I'm asking 
because Roger Monk(CCed) had added complete support for this board against 
Arago tree. Maybe we can work on adapting that patch againts mainline?

Best Regards,
Caglar

> ---
>  arch/arm/mach-davinci/Kconfig                   |    9 +++
>  arch/arm/mach-davinci/Makefile                  |    1 +
>  arch/arm/mach-davinci/board-da850-hawk.c        |   69
>  +++++++++++++++++++++++ arch/arm/mach-davinci/include/mach/uncompress.h | 
>    1 +
>  4 files changed, 80 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
> 
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 2bf03e9..fd8a11c 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -185,6 +185,15 @@ config MACH_TNETV107X
>        help
>          Say Y here to select the TI TNETV107X Evaluation Module.
> 
> +config MACH_OMAPL138_HAWKBOARD
> +       bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
> +       default ARCH_DAVINCI_DA850
> +       depends on ARCH_DAVINCI_DA850
> +       help
> +         Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
> +         Information of this board may be found at
> +         http://www.hawkboard.org/
> +
>  config DAVINCI_MUX
>        bool "DAVINCI multiplexing support"
>        depends on ARCH_DAVINCI
> diff --git a/arch/arm/mach-davinci/Makefile
>  b/arch/arm/mach-davinci/Makefile index eab4c0f..fd271cd 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)  +=
>  board-dm365-evm.o obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)   +=
>  board-da830-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)   += board-da850-evm.o
>  obj-$(CONFIG_MACH_TNETV107X)           += board-tnetv107x-evm.o
> +obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD)  += board-da850-hawk.o
> 
>  # Power Management
>  obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o
> diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
> b/arch/arm/mach-davinci/board-da850-hawk.c
> new file mode 100644
> index 0000000..e34bcbb
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-da850-hawk.c
> @@ -0,0 +1,69 @@
> +/*
> + * Hawkboar.org based on TI's OMAP-L138 Platform
> + *
> + * Initial code: Syed Mohammed Khasim
> + *
> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
> + *
> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
> + * Original Copyrights follow:
> + *
> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/gpio.h>
> +
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +
> +#include <mach/cp_intc.h>
> +#include <mach/da8xx.h>
> +
> +
> +
> +static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
> +       .enabled_uarts = 0x7,
> +};
> +
> +static __init void omapl138_hawk_init(void)
> +{
> +
> +       davinci_serial_init(&omapl138_hawk_uart_config);
> +
> +       /*
> +        * shut down uart 0 and 1; they are not used on the board and
> +        * accessing them causes endless "too much work in irq53" messages
> +        * with arago fs
> +        */
> +       __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
> +       __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
> +
> +}
> +
> +#ifdef CONFIG_SERIAL_8250_CONSOLE
> +static int __init omapl138_hawk_console_init(void)
> +{
> +       return add_preferred_console("ttyS", 2, "115200");
> +}
> +console_initcall(omapl138_hawk_console_init);
> +#endif
> +
> +static void __init omapl138_hawk_map_io(void)
> +{
> +       da850_init();
> +}
> +
> +MACHINE_START(OMAPL138_HAWKBOARD, "OMAPL 138 Hawkboard.org")
> +       .phys_io        = IO_PHYS,
> +       .io_pg_offst    = (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
> +       .boot_params    = (DA8XX_DDR_BASE + 0x100),
> +       .map_io         = omapl138_hawk_map_io,
> +       .init_irq       = cp_intc_init,
> +       .timer          = &davinci_timer,
> +       .init_machine   = omapl138_hawk_init,
> +MACHINE_END
> diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
> b/arch/arm/mach-davinci/include/mach/uncompress.h
> index 15a6192..640f834 100644
> --- a/arch/arm/mach-davinci/include/mach/uncompress.h
> +++ b/arch/arm/mach-davinci/include/mach/uncompress.h
> @@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long
>  arch_id) /* DA8xx boards */
>                DEBUG_LL_DA8XX(davinci_da830_evm,       2);
>                DEBUG_LL_DA8XX(davinci_da850_evm,       2);
> +               DEBUG_LL_DA8XX(omapl138_hawkboard,      2);
> 
>                /* TNETV107x boards */
>                DEBUG_LL_TNETV107X(tnetv107x,           1);
> --
> 1.6.0.5
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

From sshtylyov at mvista.com  Tue Aug 31 04:07:33 2010
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 31 Aug 2010 13:07:33 +0400
Subject: [PATCH] hawkboard
In-Reply-To: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
Message-ID: <4C7CC655.3060104@mvista.com>

Victor Rodriguez wrote:
> Basic support for Hawkboard OMAPL138 just UART cominication is included

> Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>

> Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03 from
>        Kernel development tree for TI DaVinci family of processors

>        This patch works with basic da8xx_omapl_defconfig, it just have
> basic support
>        for UART console
> ---
>  arch/arm/mach-davinci/Kconfig                   |    9 +++
>  arch/arm/mach-davinci/Makefile                  |    1 +
>  arch/arm/mach-davinci/board-da850-hawk.c        |   69 +++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
>  4 files changed, 80 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
> 
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 2bf03e9..fd8a11c 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -185,6 +185,15 @@ config MACH_TNETV107X
>        help
>          Say Y here to select the TI TNETV107X Evaluation Module.
> 
> +config MACH_OMAPL138_HAWKBOARD
> +       bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
> +       default ARCH_DAVINCI_DA850

    Only EVM boards are enabled by default.

> +       depends on ARCH_DAVINCI_DA850
> +       help
> +         Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
> +         Information of this board may be found at
> +         http://www.hawkboard.org/
> +
>  config DAVINCI_MUX
>        bool "DAVINCI multiplexing support"
>        depends on ARCH_DAVINCI
[...]
> diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
> b/arch/arm/mach-davinci/board-da850-hawk.c
> new file mode 100644
> index 0000000..e34bcbb
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-da850-hawk.c
> @@ -0,0 +1,69 @@
> +/*
> + * Hawkboar.org based on TI's OMAP-L138 Platform

    Hawkboard.org?

> + *
> + * Initial code: Syed Mohammed Khasim
> + *
> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
> + *
> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
> + * Original Copyrights follow:
> + *
> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under

    MV didn't write any code in board-da850-evm.c, so the original copyright 
is wrong.

> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/gpio.h>
> +
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +
> +#include <mach/cp_intc.h>
> +#include <mach/da8xx.h>
> +
> +
> +

    Too many empty lines?

> +static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
> +       .enabled_uarts = 0x7,

    Why enable URARTs 0 and 1 if you shut down them below?

> +};
> +
> +static __init void omapl138_hawk_init(void)
> +{
> +
> +       davinci_serial_init(&omapl138_hawk_uart_config);
> +
> +       /*
> +        * shut down uart 0 and 1; they are not used on the board and
> +        * accessing them causes endless "too much work in irq53" messages
> +        * with arago fs
> +        */
> +       __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
> +       __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
> +
> +}

WBR, Sergei


From caglarakyuz at gmail.com  Tue Aug 31 06:33:08 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Tue, 31 Aug 2010 14:33:08 +0300
Subject: [PATCH] hawkboard
In-Reply-To: <4C7CC655.3060104@mvista.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<4C7CC655.3060104@mvista.com>
Message-ID: <201008311433.08565.caglarakyuz@gmail.com>

On Tuesday 31 August 2010 12:07:33 pm Sergei Shtylyov wrote:
> Victor Rodriguez wrote:
> > Basic support for Hawkboard OMAPL138 just UART cominication is included
> >
> > Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
> >
> > Notes: This patch is checked with
> > 0a50e05b20f3c6af67656303bdb3661a2541ce03 from Kernel development tree for
> > TI DaVinci family of processors
> >
> >        This patch works with basic da8xx_omapl_defconfig, it just have
> > basic support
> >        for UART console
> > ---
> >  arch/arm/mach-davinci/Kconfig                   |    9 +++
> >  arch/arm/mach-davinci/Makefile                  |    1 +
> >  arch/arm/mach-davinci/board-da850-hawk.c        |   69
> > +++++++++++++++++++++++ arch/arm/mach-davinci/include/mach/uncompress.h |
> >    1 +
> >  4 files changed, 80 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
> >
> > diff --git a/arch/arm/mach-davinci/Kconfig
> > b/arch/arm/mach-davinci/Kconfig index 2bf03e9..fd8a11c 100644
> > --- a/arch/arm/mach-davinci/Kconfig
> > +++ b/arch/arm/mach-davinci/Kconfig
> > @@ -185,6 +185,15 @@ config MACH_TNETV107X
> >        help
> >          Say Y here to select the TI TNETV107X Evaluation Module.
> >
> > +config MACH_OMAPL138_HAWKBOARD
> > +       bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
> > +       default ARCH_DAVINCI_DA850
> 
>     Only EVM boards are enabled by default.
> 
> > +       depends on ARCH_DAVINCI_DA850
> > +       help
> > +         Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
> > +         Information of this board may be found at
> > +         http://www.hawkboard.org/
> > +
> >  config DAVINCI_MUX
> >        bool "DAVINCI multiplexing support"
> >        depends on ARCH_DAVINCI
> 
> [...]
> 
> > diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
> > b/arch/arm/mach-davinci/board-da850-hawk.c
> > new file mode 100644
> > index 0000000..e34bcbb
> > --- /dev/null
> > +++ b/arch/arm/mach-davinci/board-da850-hawk.c
> > @@ -0,0 +1,69 @@
> > +/*
> > + * Hawkboar.org based on TI's OMAP-L138 Platform
> 
>     Hawkboard.org?
> 
> > + *
> > + * Initial code: Syed Mohammed Khasim
> > + *
> > + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
> > + *
> > + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
> > + * Original Copyrights follow:
> > + *
> > + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
> 
>     MV didn't write any code in board-da850-evm.c, so the original
>  copyright is wrong.
> 
> > + * the terms of the GNU General Public License version 2. This program
> > + * is licensed "as is" without any warranty of any kind, whether express
> > + * or implied.
> > + */
> > +#include <linux/kernel.h>
> > +#include <linux/init.h>
> > +#include <linux/console.h>
> > +#include <linux/gpio.h>
> > +
> > +#include <asm/mach-types.h>
> > +#include <asm/mach/arch.h>
> > +
> > +#include <mach/cp_intc.h>
> > +#include <mach/da8xx.h>
> > +
> > +
> > +
> 
>     Too many empty lines?
> 
> > +static struct davinci_uart_config omapl138_hawk_uart_config __initdata =
> > { +       .enabled_uarts = 0x7,
> 
>     Why enable URARTs 0 and 1 if you shut down them below?
> 

This is the same method used in 'board-da850-evm.c'.  I tried making this 
0x4 but kernel locked-up. I see following on the kernel log:

 Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled                                                                                                                            
 serial8250 serial8250.0: unable to register port at index 0 (IO0 MEM1c42000 IRQ25): -22                                                                                             
 serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM1d0c000 IRQ53): -22                                                                                             
 serial8250.0: ttyS0 at MMIO 0x1d0d000 (irq = 61) is a 16550A

Maybe someone can explain the root cause.

Best Regards,
Caglar

> > +};
> > +
> > +static __init void omapl138_hawk_init(void)
> > +{
> > +
> > +       davinci_serial_init(&omapl138_hawk_uart_config);
> > +
> > +       /*
> > +        * shut down uart 0 and 1; they are not used on the board and
> > +        * accessing them causes endless "too much work in irq53"
> > messages +        * with arago fs
> > +        */
> > +       __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
> > +       __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
> > +
> > +}
> 
> WBR, Sergei
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

From nsekhar at ti.com  Tue Aug 31 07:42:56 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 31 Aug 2010 18:12:56 +0530
Subject: [PATCH] hawkboard
In-Reply-To: <201008311433.08565.caglarakyuz@gmail.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<4C7CC655.3060104@mvista.com>
	<201008311433.08565.caglarakyuz@gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301F6AC5527@dbde02.ent.ti.com>

Hi Caglar,

On Tue, Aug 31, 2010 at 17:03:08, Caglar Akyuz wrote:

> > > +static struct davinci_uart_config omapl138_hawk_uart_config __initdata =
> > > { +       .enabled_uarts = 0x7,
> >
> >     Why enable URARTs 0 and 1 if you shut down them below?
> >
>
> This is the same method used in 'board-da850-evm.c'.  I tried making this
> 0x4 but kernel locked-up. I see following on the kernel log:
>
>  Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
>  serial8250 serial8250.0: unable to register port at index 0 (IO0 MEM1c42000 IRQ25): -22
>  serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM1d0c000 IRQ53): -22
>  serial8250.0: ttyS0 at MMIO 0x1d0d000 (irq = 61) is a 16550A
>
> Maybe someone can explain the root cause.

The UART clock is enabled by arch/arm/mach-davinci/serial.c. Without that
the 8250.c will not be able to recognize the UART.

Showing only one UART to Linux should help. That should be possible by
editing da8xx_serial_pdata[]. But that will affect all boards. So, the
serial platform data would need to be made board specific.

However, I don't think this error alone can cause lock-up. Did you also
change the console= kernel parameter to ttyS0?

Thanks,
Sekhar


From caglarakyuz at gmail.com  Tue Aug 31 08:44:21 2010
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Tue, 31 Aug 2010 16:44:21 +0300
Subject: [PATCH] hawkboard
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301F6AC5527@dbde02.ent.ti.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<201008311433.08565.caglarakyuz@gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301F6AC5527@dbde02.ent.ti.com>
Message-ID: <201008311644.21745.caglarakyuz@gmail.com>

On Tuesday 31 August 2010 03:42:56 pm Nori, Sekhar wrote:
> Hi Caglar,
> 
> On Tue, Aug 31, 2010 at 17:03:08, Caglar Akyuz wrote:
> > > > +static struct davinci_uart_config omapl138_hawk_uart_config
> > > > __initdata = { +       .enabled_uarts = 0x7,
> > >
> > >     Why enable URARTs 0 and 1 if you shut down them below?
> >
> > This is the same method used in 'board-da850-evm.c'.  I tried making this
> > 0x4 but kernel locked-up. I see following on the kernel log:
> >
> >  Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
> >  serial8250 serial8250.0: unable to register port at index 0 (IO0
> > MEM1c42000 IRQ25): -22 serial8250 serial8250.0: unable to register port
> > at index 1 (IO0 MEM1d0c000 IRQ53): -22 serial8250.0: ttyS0 at MMIO
> > 0x1d0d000 (irq = 61) is a 16550A
> >
> > Maybe someone can explain the root cause.
> 
> The UART clock is enabled by arch/arm/mach-davinci/serial.c. Without that
> the 8250.c will not be able to recognize the UART.
> 
> Showing only one UART to Linux should help. That should be possible by
> editing da8xx_serial_pdata[]. But that will affect all boards. So, the
> serial platform data would need to be made board specific.
> 
> However, I don't think this error alone can cause lock-up. Did you also
> change the console= kernel parameter to ttyS0?
> 

Of course not! Thanks for reminding. Now it is working. 

I think Hawkboard should do the same as EVM wrt uart init for userspace 
compatibility.

Best Regards,
Caglar

> Thanks,
> Sekhar
> 

From vm.rod25 at gmail.com  Tue Aug 31 09:02:08 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Tue, 31 Aug 2010 09:02:08 -0500
Subject: [PATCH] hawkboard
In-Reply-To: <201008311105.34712.caglarakyuz@gmail.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<201008311105.34712.caglarakyuz@gmail.com>
Message-ID: <AANLkTimnYyeY2iq7dY=wLviQ20Apo7TnBKMJC4Z-rPfO@mail.gmail.com>

On Tue, Aug 31, 2010 at 3:05 AM, Caglar Akyuz <caglarakyuz at gmail.com> wrote:
> On Monday 30 August 2010 08:45:34 pm Victor Rodriguez wrote:
>> Basic support for Hawkboard OMAPL138 just UART cominication is included
>>
>> Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
>>
>> Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03
>> ?from Kernel development tree for TI DaVinci family of processors
>>
>
> I tried to apply this patch on top of 0a50e05, but it seems like patch is
> corrupt or my MUA is breaking it. Are you able to apply this patch from your
> mailbox?
>
> Besides, checkpatch is complaining about errors in the patch. Have you used
> scripts/checkpatch.pl with this patch?

Sorry about it I sent to my mail box and then reply it, I am really
sorry about that , i will send it from git send mail next time, I
tried but like i am behind a proxy server I had some problems in the
beginning. Really sorry about it

>> ? ? ? ?This patch works with basic da8xx_omapl_defconfig, it just have
>> basic support
>> ? ? ? ?for UART console
>
> Are you planning to add other peripherals or is this all for now? I'm asking
> because Roger Monk(CCed) had added complete support for this board against
> Arago tree. Maybe we can work on adapting that patch againts mainline?


Yes i already have almost the complete support (except for the USB)
but i talk to Kevin and seems better to just to start with the basic
UART suport

> Best Regards,
> Caglar
>
>> ---
>> ?arch/arm/mach-davinci/Kconfig ? ? ? ? ? ? ? ? ? | ? ?9 +++
>> ?arch/arm/mach-davinci/Makefile ? ? ? ? ? ? ? ? ?| ? ?1 +
>> ?arch/arm/mach-davinci/board-da850-hawk.c ? ? ? ?| ? 69
>> ?+++++++++++++++++++++++ arch/arm/mach-davinci/include/mach/uncompress.h |
>> ? ?1 +
>> ?4 files changed, 80 insertions(+), 0 deletions(-)
>> ?create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
>>
>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>> index 2bf03e9..fd8a11c 100644
>> --- a/arch/arm/mach-davinci/Kconfig
>> +++ b/arch/arm/mach-davinci/Kconfig
>> @@ -185,6 +185,15 @@ config MACH_TNETV107X
>> ? ? ? ?help
>> ? ? ? ? ?Say Y here to select the TI TNETV107X Evaluation Module.
>>
>> +config MACH_OMAPL138_HAWKBOARD
>> + ? ? ? bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
>> + ? ? ? default ARCH_DAVINCI_DA850
>> + ? ? ? depends on ARCH_DAVINCI_DA850
>> + ? ? ? help
>> + ? ? ? ? Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
>> + ? ? ? ? Information of this board may be found at
>> + ? ? ? ? http://www.hawkboard.org/
>> +
>> ?config DAVINCI_MUX
>> ? ? ? ?bool "DAVINCI multiplexing support"
>> ? ? ? ?depends on ARCH_DAVINCI
>> diff --git a/arch/arm/mach-davinci/Makefile
>> ?b/arch/arm/mach-davinci/Makefile index eab4c0f..fd271cd 100644
>> --- a/arch/arm/mach-davinci/Makefile
>> +++ b/arch/arm/mach-davinci/Makefile
>> @@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM) ?+=
>> ?board-dm365-evm.o obj-$(CONFIG_MACH_DAVINCI_DA830_EVM) ? +=
>> ?board-da830-evm.o
>> ?obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) ? += board-da850-evm.o
>> ?obj-$(CONFIG_MACH_TNETV107X) ? ? ? ? ? += board-tnetv107x-evm.o
>> +obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD) ?+= board-da850-hawk.o
>>
>> ?# Power Management
>> ?obj-$(CONFIG_CPU_FREQ) ? ? ? ? ? ? ? ? += cpufreq.o
>> diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
>> b/arch/arm/mach-davinci/board-da850-hawk.c
>> new file mode 100644
>> index 0000000..e34bcbb
>> --- /dev/null
>> +++ b/arch/arm/mach-davinci/board-da850-hawk.c
>> @@ -0,0 +1,69 @@
>> +/*
>> + * Hawkboar.org based on TI's OMAP-L138 Platform
>> + *
>> + * Initial code: Syed Mohammed Khasim
>> + *
>> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
>> + *
>> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
>> + * Original Copyrights follow:
>> + *
>> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
>> + * the terms of the GNU General Public License version 2. This program
>> + * is licensed "as is" without any warranty of any kind, whether express
>> + * or implied.
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/console.h>
>> +#include <linux/gpio.h>
>> +
>> +#include <asm/mach-types.h>
>> +#include <asm/mach/arch.h>
>> +
>> +#include <mach/cp_intc.h>
>> +#include <mach/da8xx.h>
>> +
>> +
>> +
>> +static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
>> + ? ? ? .enabled_uarts = 0x7,
>> +};
>> +
>> +static __init void omapl138_hawk_init(void)
>> +{
>> +
>> + ? ? ? davinci_serial_init(&omapl138_hawk_uart_config);
>> +
>> + ? ? ? /*
>> + ? ? ? ?* shut down uart 0 and 1; they are not used on the board and
>> + ? ? ? ?* accessing them causes endless "too much work in irq53" messages
>> + ? ? ? ?* with arago fs
>> + ? ? ? ?*/
>> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
>> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
>> +
>> +}
>> +
>> +#ifdef CONFIG_SERIAL_8250_CONSOLE
>> +static int __init omapl138_hawk_console_init(void)
>> +{
>> + ? ? ? return add_preferred_console("ttyS", 2, "115200");
>> +}
>> +console_initcall(omapl138_hawk_console_init);
>> +#endif
>> +
>> +static void __init omapl138_hawk_map_io(void)
>> +{
>> + ? ? ? da850_init();
>> +}
>> +
>> +MACHINE_START(OMAPL138_HAWKBOARD, "OMAPL 138 Hawkboard.org")
>> + ? ? ? .phys_io ? ? ? ?= IO_PHYS,
>> + ? ? ? .io_pg_offst ? ?= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
>> + ? ? ? .boot_params ? ?= (DA8XX_DDR_BASE + 0x100),
>> + ? ? ? .map_io ? ? ? ? = omapl138_hawk_map_io,
>> + ? ? ? .init_irq ? ? ? = cp_intc_init,
>> + ? ? ? .timer ? ? ? ? ?= &davinci_timer,
>> + ? ? ? .init_machine ? = omapl138_hawk_init,
>> +MACHINE_END
>> diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
>> b/arch/arm/mach-davinci/include/mach/uncompress.h
>> index 15a6192..640f834 100644
>> --- a/arch/arm/mach-davinci/include/mach/uncompress.h
>> +++ b/arch/arm/mach-davinci/include/mach/uncompress.h
>> @@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long
>> ?arch_id) /* DA8xx boards */
>> ? ? ? ? ? ? ? ?DEBUG_LL_DA8XX(davinci_da830_evm, ? ? ? 2);
>> ? ? ? ? ? ? ? ?DEBUG_LL_DA8XX(davinci_da850_evm, ? ? ? 2);
>> + ? ? ? ? ? ? ? DEBUG_LL_DA8XX(omapl138_hawkboard, ? ? ?2);
>>
>> ? ? ? ? ? ? ? ?/* TNETV107x boards */
>> ? ? ? ? ? ? ? ?DEBUG_LL_TNETV107X(tnetv107x, ? ? ? ? ? 1);
>> --
>> 1.6.0.5
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>

From vm.rod25 at gmail.com  Tue Aug 31 09:08:57 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Tue, 31 Aug 2010 09:08:57 -0500
Subject: [PATCH] hawkboard
In-Reply-To: <4C7CC655.3060104@mvista.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<4C7CC655.3060104@mvista.com>
Message-ID: <AANLkTi=hMx2HND6cax2kxQoNdF5=Z-eC7KTj7Tq5U77x@mail.gmail.com>

On Tue, Aug 31, 2010 at 4:07 AM, Sergei Shtylyov <sshtylyov at mvista.com> wrote:
> Victor Rodriguez wrote:
>>
>> Basic support for Hawkboard OMAPL138 just UART cominication is included
>
>> Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
>
>> Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03
>> from
>> ? ? ? Kernel development tree for TI DaVinci family of processors
>
>> ? ? ? This patch works with basic da8xx_omapl_defconfig, it just have
>> basic support
>> ? ? ? for UART console
>> ---
>> ?arch/arm/mach-davinci/Kconfig ? ? ? ? ? ? ? ? ? | ? ?9 +++
>> ?arch/arm/mach-davinci/Makefile ? ? ? ? ? ? ? ? ?| ? ?1 +
>> ?arch/arm/mach-davinci/board-da850-hawk.c ? ? ? ?| ? 69
>> +++++++++++++++++++++++
>> ?arch/arm/mach-davinci/include/mach/uncompress.h | ? ?1 +
>> ?4 files changed, 80 insertions(+), 0 deletions(-)
>> ?create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
>>
>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>> index 2bf03e9..fd8a11c 100644
>> --- a/arch/arm/mach-davinci/Kconfig
>> +++ b/arch/arm/mach-davinci/Kconfig
>> @@ -185,6 +185,15 @@ config MACH_TNETV107X
>> ? ? ? help
>> ? ? ? ? Say Y here to select the TI TNETV107X Evaluation Module.
>>
>> +config MACH_OMAPL138_HAWKBOARD
>> + ? ? ? bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
>> + ? ? ? default ARCH_DAVINCI_DA850
>
> ? Only EVM boards are enabled by default.
>
>> + ? ? ? depends on ARCH_DAVINCI_DA850
>> + ? ? ? help
>> + ? ? ? ? Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
>> + ? ? ? ? Information of this board may be found at
>> + ? ? ? ? http://www.hawkboard.org/
>> +
>> ?config DAVINCI_MUX
>> ? ? ? bool "DAVINCI multiplexing support"
>> ? ? ? depends on ARCH_DAVINCI
>
> [...]
>>
>> diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
>> b/arch/arm/mach-davinci/board-da850-hawk.c
>> new file mode 100644
>> index 0000000..e34bcbb
>> --- /dev/null
>> +++ b/arch/arm/mach-davinci/board-da850-hawk.c
>> @@ -0,0 +1,69 @@
>> +/*
>> + * Hawkboar.org based on TI's OMAP-L138 Platform
>
> ? Hawkboard.org?

Sorry for the typo i will work on it right now

>> + *
>> + * Initial code: Syed Mohammed Khasim
>> + *
>> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
>> + *
>> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
>> + * Original Copyrights follow:
>> + *
>> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
>
> ? MV didn't write any code in board-da850-evm.c, so the original copyright
> is wrong.

Sorry about it i tried to keep all the copy right possibles but if it
is wrong I will delete it

>> + * the terms of the GNU General Public License version 2. This program
>> + * is licensed "as is" without any warranty of any kind, whether express
>> + * or implied.
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/console.h>
>> +#include <linux/gpio.h>
>> +
>> +#include <asm/mach-types.h>
>> +#include <asm/mach/arch.h>
>> +
>> +#include <mach/cp_intc.h>
>> +#include <mach/da8xx.h>
>> +
>> +
>> +
>
> ? Too many empty lines?

Fixing..

>> +static struct davinci_uart_config omapl138_hawk_uart_config __initdata =
>> {
>> + ? ? ? .enabled_uarts = 0x7,
>
> ? Why enable URARTs 0 and 1 if you shut down them below?

Because maybe with another files systems could work the UART 0 and 1,
There is a problem with these UART s even in hardware because one of
them is multiplexed with Ethernet, so i decided to let them available
and let the comment, because until new the only file systems bailable
is from Argo

>> +};
>> +
>> +static __init void omapl138_hawk_init(void)
>> +{
>> +
>> + ? ? ? davinci_serial_init(&omapl138_hawk_uart_config);
>> +
>> + ? ? ? /*
>> + ? ? ? ?* shut down uart 0 and 1; they are not used on the board and
>> + ? ? ? ?* accessing them causes endless "too much work in irq53" messages
>> + ? ? ? ?* with arago fs
>> + ? ? ? ?*/
>> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
>> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
>> +
>> +}
>
> WBR, Sergei
>
>

From vm.rod25 at gmail.com  Tue Aug 31 09:46:26 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Tue, 31 Aug 2010 09:46:26 -0500
Subject: [PATCH] hawkboard
In-Reply-To: <4C7CC655.3060104@mvista.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<4C7CC655.3060104@mvista.com>
Message-ID: <AANLkTindjAFnfXrgmgPyBcPudy=YdEH68DARToVMNLdz@mail.gmail.com>

On Tue, Aug 31, 2010 at 4:07 AM, Sergei Shtylyov <sshtylyov at mvista.com> wrote:
> Victor Rodriguez wrote:
>>
>> Basic support for Hawkboard OMAPL138 just UART cominication is included
>
>> Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
>
>> Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03
>> from
>> ? ? ? Kernel development tree for TI DaVinci family of processors
>
>> ? ? ? This patch works with basic da8xx_omapl_defconfig, it just have
>> basic support
>> ? ? ? for UART console
>> ---
>> ?arch/arm/mach-davinci/Kconfig ? ? ? ? ? ? ? ? ? | ? ?9 +++
>> ?arch/arm/mach-davinci/Makefile ? ? ? ? ? ? ? ? ?| ? ?1 +
>> ?arch/arm/mach-davinci/board-da850-hawk.c ? ? ? ?| ? 69
>> +++++++++++++++++++++++
>> ?arch/arm/mach-davinci/include/mach/uncompress.h | ? ?1 +
>> ?4 files changed, 80 insertions(+), 0 deletions(-)
>> ?create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
>>
>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>> index 2bf03e9..fd8a11c 100644
>> --- a/arch/arm/mach-davinci/Kconfig
>> +++ b/arch/arm/mach-davinci/Kconfig
>> @@ -185,6 +185,15 @@ config MACH_TNETV107X
>> ? ? ? help
>> ? ? ? ? Say Y here to select the TI TNETV107X Evaluation Module.
>>
>> +config MACH_OMAPL138_HAWKBOARD
>> + ? ? ? bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
>> + ? ? ? default ARCH_DAVINCI_DA850
>
> ? Only EVM boards are enabled by default.
>
>> + ? ? ? depends on ARCH_DAVINCI_DA850
>> + ? ? ? help
>> + ? ? ? ? Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
>> + ? ? ? ? Information of this board may be found at
>> + ? ? ? ? http://www.hawkboard.org/
>> +
>> ?config DAVINCI_MUX
>> ? ? ? bool "DAVINCI multiplexing support"
>> ? ? ? depends on ARCH_DAVINCI
>
> [...]
>>
>> diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
>> b/arch/arm/mach-davinci/board-da850-hawk.c
>> new file mode 100644
>> index 0000000..e34bcbb
>> --- /dev/null
>> +++ b/arch/arm/mach-davinci/board-da850-hawk.c
>> @@ -0,0 +1,69 @@
>> +/*
>> + * Hawkboar.org based on TI's OMAP-L138 Platform
>
> ? Hawkboard.org?
>
>> + *
>> + * Initial code: Syed Mohammed Khasim
>> + *
>> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
>> + *
>> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
>> + * Original Copyrights follow:
>> + *
>> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
>
> ? MV didn't write any code in board-da850-evm.c, so the original copyright
> is wrong.


One question i was looking for the root of the original code and found this

board-da850-hawk.c is derived from


arch/arm/mach-davinci/board-da850-evm.c

and it is derived from

arch/arm/mach-davinci/board-da830-evm.c

and it is derived from

arch/arm/mach-davinci/board-dm644x-evm.c

which shows this

/*
 * TI DaVinci EVM board support
 *
 * Author: Kevin Hilman, MontaVista Software, Inc. <source at mvista.com>
 *
 * 2007 (c) MontaVista Software, Inc. This file is licensed under
 * the terms of the GNU General Public License version 2. This program
 * is licensed "as is" without any warranty of any kind, whether express
 * or implied.
 */

Until i understand Kevin wrote that code there is no more derived from
so i think the best is to keep with that copy right but, is just a
question please tell me which should i write like original copy right



>> + * the terms of the GNU General Public License version 2. This program
>> + * is licensed "as is" without any warranty of any kind, whether express
>> + * or implied.
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/console.h>
>> +#include <linux/gpio.h>
>> +
>> +#include <asm/mach-types.h>
>> +#include <asm/mach/arch.h>
>> +
>> +#include <mach/cp_intc.h>
>> +#include <mach/da8xx.h>
>> +
>> +
>> +
>
> ? Too many empty lines?
>
>> +static struct davinci_uart_config omapl138_hawk_uart_config __initdata =
>> {
>> + ? ? ? .enabled_uarts = 0x7,
>
> ? Why enable URARTs 0 and 1 if you shut down them below?
>
>> +};
>> +
>> +static __init void omapl138_hawk_init(void)
>> +{
>> +
>> + ? ? ? davinci_serial_init(&omapl138_hawk_uart_config);
>> +
>> + ? ? ? /*
>> + ? ? ? ?* shut down uart 0 and 1; they are not used on the board and
>> + ? ? ? ?* accessing them causes endless "too much work in irq53" messages
>> + ? ? ? ?* with arago fs
>> + ? ? ? ?*/
>> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
>> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
>> +
>> +}
>
> WBR, Sergei
>
>

Whit Best Regards

Victor Rodriguez

From khilman at deeprootsystems.com  Tue Aug 31 09:49:41 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 31 Aug 2010 07:49:41 -0700
Subject: [PATCH 0/6] davinci: add support for aemif timing configuration
In-Reply-To: <1283254660.2018.29.camel@brekeke> (Artem Bityutskiy's message of
	"Tue, 31 Aug 2010 14:37:40 +0300")
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
	<1283082501.2131.29.camel@brekeke>
	<877hj8b20x.fsf@deeprootsystems.com>
	<1283254660.2018.29.camel@brekeke>
Message-ID: <877hj6vnui.fsf@deeprootsystems.com>

Artem Bityutskiy <dedekind1 at gmail.com> writes:

> On Mon, 2010-08-30 at 07:36 -0700, Kevin Hilman wrote:
>> > Pushed to l2-mtd-2.6.git / dunno.
>> 
>> Hi Artem,
>> 
>> If it's OK with you, and with your Ack, I'd prefer to merge this series
>> via the davinci tree.
>> 
>> The reason is because the files touched in arch/arm/mach-davinci/* are
>> also getting lots of other changes for 2.6.37, and I'd like to minimize
>> conflicts.
>
> Right, I've just removed them from my tree.
>
>> Let me know if that's OK with you and if I can add your signoff to the
>> drivers/mtd/* patches.  
>
> The MTD part is small there, feel free to add
>
> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>

Thanks Artem,

Kevin

From khasim at ti.com  Tue Aug 31 09:51:42 2010
From: khasim at ti.com (Syed Mohammed, Khasim)
Date: Tue, 31 Aug 2010 20:21:42 +0530
Subject: [PATCH] hawkboard
In-Reply-To: <AANLkTindjAFnfXrgmgPyBcPudy=YdEH68DARToVMNLdz@mail.gmail.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<4C7CC655.3060104@mvista.com>
	<AANLkTindjAFnfXrgmgPyBcPudy=YdEH68DARToVMNLdz@mail.gmail.com>
Message-ID: <0680EC522D0CC943BC586913CF3768C003C1CA4C39@dbde02.ent.ti.com>



> -----Original Message-----
> From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-
> linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Victor Rodriguez
> Sent: Tuesday, August 31, 2010 8:16 PM
> To: Sergei Shtylyov; davinci-linux-open-source at linux.davincidsp.com
> Subject: Re: [PATCH] hawkboard
> 
> On Tue, Aug 31, 2010 at 4:07 AM, Sergei Shtylyov <sshtylyov at mvista.com> wrote:
> > Victor Rodriguez wrote:
> >>
> >> Basic support for Hawkboard OMAPL138 just UART cominication is included
> >
> >> Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
> >
> >> Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03
> >> from
> >> ? ? ? Kernel development tree for TI DaVinci family of processors
> >
> >> ? ? ? This patch works with basic da8xx_omapl_defconfig, it just have
> >> basic support
> >> ? ? ? for UART console
> >> ---
> >> ?arch/arm/mach-davinci/Kconfig ? ? ? ? ? ? ? ? ? | ? ?9 +++
> >> ?arch/arm/mach-davinci/Makefile ? ? ? ? ? ? ? ? ?| ? ?1 +
> >> ?arch/arm/mach-davinci/board-da850-hawk.c ? ? ? ?| ? 69
> >> +++++++++++++++++++++++
> >> ?arch/arm/mach-davinci/include/mach/uncompress.h | ? ?1 +
> >> ?4 files changed, 80 insertions(+), 0 deletions(-)
> >> ?create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
> >>
> >> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >> index 2bf03e9..fd8a11c 100644
> >> --- a/arch/arm/mach-davinci/Kconfig
> >> +++ b/arch/arm/mach-davinci/Kconfig
> >> @@ -185,6 +185,15 @@ config MACH_TNETV107X
> >> ? ? ? help
> >> ? ? ? ? Say Y here to select the TI TNETV107X Evaluation Module.
> >>
> >> +config MACH_OMAPL138_HAWKBOARD
> >> + ? ? ? bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
> >> + ? ? ? default ARCH_DAVINCI_DA850
> >
> > ? Only EVM boards are enabled by default.
> >
> >> + ? ? ? depends on ARCH_DAVINCI_DA850
> >> + ? ? ? help
> >> + ? ? ? ? Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
> >> + ? ? ? ? Information of this board may be found at
> >> + ? ? ? ? http://www.hawkboard.org/
> >> +
> >> ?config DAVINCI_MUX
> >> ? ? ? bool "DAVINCI multiplexing support"
> >> ? ? ? depends on ARCH_DAVINCI
> >
> > [...]
> >>
> >> diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
> >> b/arch/arm/mach-davinci/board-da850-hawk.c
> >> new file mode 100644
> >> index 0000000..e34bcbb
> >> --- /dev/null
> >> +++ b/arch/arm/mach-davinci/board-da850-hawk.c
> >> @@ -0,0 +1,69 @@
> >> +/*
> >> + * Hawkboar.org based on TI's OMAP-L138 Platform
> >
> > ? Hawkboard.org?
> >
> >> + *
> >> + * Initial code: Syed Mohammed Khasim
> >> + *
> >> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
> >> + *
> >> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
> >> + * Original Copyrights follow:
> >> + *
> >> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
> >
> > ? MV didn't write any code in board-da850-evm.c, so the original copyright
> > is wrong.
> 
> 
> One question i was looking for the root of the original code and found this
> 
> board-da850-hawk.c is derived from
> 
> 
> arch/arm/mach-davinci/board-da850-evm.c
> 
> and it is derived from
> 
> arch/arm/mach-davinci/board-da830-evm.c
> 
> and it is derived from
> 
> arch/arm/mach-davinci/board-dm644x-evm.c
> 
> which shows this
> 
> /*
>  * TI DaVinci EVM board support
>  *
>  * Author: Kevin Hilman, MontaVista Software, Inc. <source at mvista.com>
>  *
>  * 2007 (c) MontaVista Software, Inc. This file is licensed under
>  * the terms of the GNU General Public License version 2. This program
>  * is licensed "as is" without any warranty of any kind, whether express
>  * or implied.
>  */
> 
> Until i understand Kevin wrote that code there is no more derived from
> so i think the best is to keep with that copy right but, is just a
> question please tell me which should i write like original copy right
> 
> 
I generally follow the immediate one, in this case we can say derived from board-da850-evm.c, with this we will know which code to refer for in future for porting or merging. We can track any changes that happen to this board file and are generic to be taken up across the da850 based boards.

> 
> >> + * the terms of the GNU General Public License version 2. This program
> >> + * is licensed "as is" without any warranty of any kind, whether express
> >> + * or implied.
> >> + */
> >> +#include <linux/kernel.h>
> >> +#include <linux/init.h>
> >> +#include <linux/console.h>
> >> +#include <linux/gpio.h>
> >> +
> >> +#include <asm/mach-types.h>
> >> +#include <asm/mach/arch.h>
> >> +
> >> +#include <mach/cp_intc.h>
> >> +#include <mach/da8xx.h>
> >> +
> >> +
> >> +
> >
> > ? Too many empty lines?
> >
> >> +static struct davinci_uart_config omapl138_hawk_uart_config __initdata =
> >> {
> >> + ? ? ? .enabled_uarts = 0x7,
> >
> > ? Why enable URARTs 0 and 1 if you shut down them below?
> >
> >> +};
> >> +
> >> +static __init void omapl138_hawk_init(void)
> >> +{
> >> +
> >> + ? ? ? davinci_serial_init(&omapl138_hawk_uart_config);
> >> +
> >> + ? ? ? /*
> >> + ? ? ? ?* shut down uart 0 and 1; they are not used on the board and
> >> + ? ? ? ?* accessing them causes endless "too much work in irq53" messages
> >> + ? ? ? ?* with arago fs
> >> + ? ? ? ?*/
> >> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
> >> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
> >> +
> >> +}
> >
> > WBR, Sergei
> >
> >
> 
> Whit Best Regards
> 
> Victor Rodriguez
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Regards,
Khasim

From khilman at deeprootsystems.com  Tue Aug 31 09:52:37 2010
From: khilman at deeprootsystems.com (Kevin Hilman)
Date: Tue, 31 Aug 2010 07:52:37 -0700
Subject: [PATCH v1] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <4C7C52FD.6010608@criticallink.com> (Michael Williamson's message
	of "Mon, 30 Aug 2010 20:55:25 -0400")
References: <4C7C52FD.6010608@criticallink.com>
Message-ID: <87zkw2u956.fsf@deeprootsystems.com>

Michael Williamson <michael.williamson at criticallink.com> writes:

> This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
> on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
> on the da850 davinci CPU architecture.  Information on these SOMs may be 
> found at http://www.mitydsp.com.
>
> Basic support for the console UART, NAND, and EMAC (MII interface) is 
> included in this patch. 
>
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
> ---
> Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's tree 
> (2.6.36-rc2).
>
> Changes since v0:
>   1) Added CONFIG_REGULATOR_DUMMY to da8xx_omapl_defconfig to support
>      DA8XX machines not providing voltage regulation.
>   2) Added machine checks on da830/da850 EVM as well as MityDSP-L138 
>      console init routines.

These two should be a separate patch as it's a fix not directly related
to your board support.

>   3) Defaulted MACH_MITYOMAPL138 on for ARCH_DAVINCI_DA850 selection in 
>      KConfig.
>   4) Fixed comment block whitespace violation.  

Otherwise, the rest of this looks fine.

Kevin

> (Elected to leave the default NAND partition as is)
>
>  arch/arm/configs/da8xx_omapl_defconfig          |    1 +
>  arch/arm/mach-davinci/Kconfig                   |    9 +
>  arch/arm/mach-davinci/Makefile                  |    1 +
>  arch/arm/mach-davinci/board-da830-evm.c         |    3 +
>  arch/arm/mach-davinci/board-da850-evm.c         |    3 +
>  arch/arm/mach-davinci/board-mityomapl138.c      |  220 +++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
>  7 files changed, 238 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/configs/da8xx_omapl_defconfig b/arch/arm/configs/da8xx_omapl_defconfig
> index ba66705..3952a4e 100644
> --- a/arch/arm/configs/da8xx_omapl_defconfig
> +++ b/arch/arm/configs/da8xx_omapl_defconfig
> @@ -79,6 +79,7 @@ CONFIG_I2C_DAVINCI=y
>  # CONFIG_HWMON is not set
>  CONFIG_WATCHDOG=y
>  CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_DUMMY=y
>  CONFIG_REGULATOR_TPS6507X=y
>  CONFIG_FB=y
>  CONFIG_FB_DA8XX=y
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 2bf03e9..633eccb 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -185,6 +185,15 @@ config MACH_TNETV107X
>  	help
>  	  Say Y here to select the TI TNETV107X Evaluation Module.
>  
> +config MACH_MITYOMAPL138
> +	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
> +	default ARCH_DAVINCI_DA850
> +	depends on ARCH_DAVINCI_DA850
> +	help
> +	  Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
> +	  System on Module.  Information on this SoM may be found at
> +	  http://www.mitydsp.com
> +
>  config DAVINCI_MUX
>  	bool "DAVINCI multiplexing support"
>  	depends on ARCH_DAVINCI
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index eab4c0f..3e966e8 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
>  obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
>  obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
> +obj-$(CONFIG_MACH_MITYOMAPL138)		+= board-mityomapl138.o
>  
>  # Power Management
>  obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
> diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
> index 292e8b7..e51a80f 100644
> --- a/arch/arm/mach-davinci/board-da830-evm.c
> +++ b/arch/arm/mach-davinci/board-da830-evm.c
> @@ -586,6 +586,9 @@ static __init void da830_evm_init(void)
>  #ifdef CONFIG_SERIAL_8250_CONSOLE
>  static int __init da830_evm_console_init(void)
>  {
> +	if (!machine_is_davinci_da830_evm())
> +		return 0;
> +
>  	return add_preferred_console("ttyS", 2, "115200");
>  }
>  console_initcall(da830_evm_console_init);
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 190ebd3..d491b5f 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -847,6 +847,9 @@ static __init void da850_evm_init(void)
>  #ifdef CONFIG_SERIAL_8250_CONSOLE
>  static int __init da850_evm_console_init(void)
>  {
> +	if (!machine_is_davinci_da850_evm())
> +		return 0;
> +
>  	return add_preferred_console("ttyS", 2, "115200");
>  }
>  console_initcall(da850_evm_console_init);
> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> new file mode 100644
> index 0000000..7338adb
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> @@ -0,0 +1,220 @@
> +/*
> + * Critical Link MityOMAP-L138 SoM
> + *
> + * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of
> + * any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/platform_device.h>
> +#include <linux/mtd/partitions.h>
> +
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/common.h>
> +#include <mach/cp_intc.h>
> +#include <mach/da8xx.h>
> +#include <mach/nand.h>
> +#include <mach/mux.h>
> +
> +#define MITYOMAPL138_PHY_MASK		0x08 /* hardcoded for now */
> +#define MITYOMAPL138_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
> +
> +/*
> + * MityDSP-L138 includes a 256 MByte large-page NAND flash
> + * (128K blocks).
> + */
> +struct mtd_partition mityomapl138_nandflash_partition[] = {
> +	{
> +		.name		= "rootfs",
> +		.offset		= 0,
> +		.size		= SZ_128M,
> +		.mask_flags	= 0, /* MTD_WRITEABLE, */
> +	},
> +	{
> +		.name		= "homefs",
> +		.offset		= MTDPART_OFS_APPEND,
> +		.size		= MTDPART_SIZ_FULL,
> +		.mask_flags	= 0,
> +	},
> +};
> +
> +static struct davinci_nand_pdata mityomapl138_nandflash_data = {
> +	.parts		= mityomapl138_nandflash_partition,
> +	.nr_parts	= ARRAY_SIZE(mityomapl138_nandflash_partition),
> +	.ecc_mode	= NAND_ECC_HW,
> +	.options	= NAND_USE_FLASH_BBT | NAND_BUSWIDTH_16,
> +	.ecc_bits   = 1, /* 4 bit mode is not supported with 16 bit NAND */
> +};
> +
> +static struct resource mityomapl138_nandflash_resource[] = {
> +	{
> +		.start	= DA8XX_AEMIF_CS3_BASE,
> +		.end	= DA8XX_AEMIF_CS3_BASE + SZ_512K + 2 * SZ_1K - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	{
> +		.start	= DA8XX_AEMIF_CTL_BASE,
> +		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +};
> +
> +static struct platform_device mityomapl138_nandflash_device = {
> +	.name		= "davinci_nand",
> +	.id		= 0,
> +	.dev		= {
> +		.platform_data	= &mityomapl138_nandflash_data,
> +	},
> +	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
> +	.resource	= mityomapl138_nandflash_resource,
> +};
> +
> +static struct platform_device *mityomapl138_devices[] __initdata = {
> +	&mityomapl138_nandflash_device,
> +};
> +
> +static void __init mityomapl138_setup_nand(void)
> +{
> +	platform_add_devices(mityomapl138_devices,
> +				 ARRAY_SIZE(mityomapl138_devices));
> +}
> +
> +static struct davinci_uart_config mityomapl138_uart_config __initdata = {
> +	.enabled_uarts = 0x7,
> +};
> +
> +static const short mityomap_mii_pins[] = {
> +	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
> +	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
> +	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
> +	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
> +	DA850_MDIO_D,
> +	-1
> +};
> +
> +static const short mityomap_rmii_pins[] = {
> +	DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
> +	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
> +	DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
> +	DA850_MDIO_D,
> +	-1
> +};
> +
> +static void __init mityomapl138_config_emac(void)
> +{
> +	void __iomem *cfg_chip3_base;
> +	int ret;
> +	u32 val;
> +	struct davinci_soc_info *soc_info = &davinci_soc_info;
> +	soc_info->emac_pdata->rmii_en = 0; /* hardcoded for now */
> +
> +	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
> +	val = __raw_readl(cfg_chip3_base);
> +
> +	if (soc_info->emac_pdata->rmii_en) {
> +		val |= BIT(8);
> +		ret = davinci_cfg_reg_list(mityomap_rmii_pins);
> +		pr_info("RMII PHY configured\n");
> +	} else {
> +		val &= ~BIT(8);
> +		ret = davinci_cfg_reg_list(mityomap_mii_pins);
> +		pr_info("MII PHY configured\n");
> +	}
> +
> +	if (ret) {
> +		pr_warning("mii/rmii mux setup failed: %d\n", ret);
> +		return;
> +	}
> +
> +	/* configure the CFGCHIP3 register for RMII or MII */
> +	__raw_writel(val, cfg_chip3_base);
> +
> +	soc_info->emac_pdata->phy_mask = MITYOMAPL138_PHY_MASK;
> +	pr_info("setting phy_mask to %x\n", soc_info->emac_pdata->phy_mask);
> +	soc_info->emac_pdata->mdio_max_freq = MITYOMAPL138_MDIO_FREQUENCY;
> +
> +	ret = da8xx_register_emac();
> +	if (ret)
> +		pr_warning("emac registration failed: %d\n", ret);
> +}
> +
> +static struct davinci_pm_config da850_pm_pdata = {
> +	.sleepcount = 128,
> +};
> +
> +static struct platform_device da850_pm_device = {
> +	.name	= "pm-davinci",
> +	.dev = {
> +		.platform_data  = &da850_pm_pdata,
> +	},
> +	.id	= -1,
> +};
> +
> +static void __init mityomapl138_init(void)
> +{
> +	int ret;
> +
> +	/* for now, no special EDMA channels are reserved */
> +	ret = da850_register_edma(NULL);
> +	if (ret)
> +		pr_warning("edma registration failed: %d\n", ret);
> +
> +	ret = da8xx_register_watchdog();
> +	if (ret)
> +		pr_warning("watchdog registration failed: %d\n", ret);
> +
> +	davinci_serial_init(&mityomapl138_uart_config);
> +
> +	mityomapl138_setup_nand();
> +
> +	mityomapl138_config_emac();
> +
> +	ret = da8xx_register_rtc();
> +	if (ret)
> +		pr_warning("rtc setup failed: %d\n", ret);
> +
> +	ret = da850_register_cpufreq("pll0_sysclk3");
> +	if (ret)
> +		pr_warning("cpufreq registration failed: %d\n", ret);
> +
> +	ret = da8xx_register_cpuidle();
> +	if (ret)
> +		pr_warning("cpuidle registration failed: %d\n", ret);
> +
> +	ret = da850_register_pm(&da850_pm_device);
> +	if (ret)
> +		pr_warning("da850_evm_init: suspend registration failed: %d\n",
> +				ret);
> +}
> +
> +#ifdef CONFIG_SERIAL_8250_CONSOLE
> +static int __init mityomapl138_console_init(void)
> +{
> +	if (!machine_is_mityomapl138())
> +		return 0;
> +
> +	return add_preferred_console("ttyS", 1, "115200");
> +}
> +console_initcall(mityomapl138_console_init);
> +#endif
> +
> +static void __init mityomapl138_map_io(void)
> +{
> +	da850_init();
> +}
> +
> +MACHINE_START(MITYOMAPL138, "MityDSP-L138/MityARM-1808")
> +	.phys_io	= IO_PHYS,
> +	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
> +	.boot_params	= (DA8XX_DDR_BASE + 0x100),
> +	.map_io		= mityomapl138_map_io,
> +	.init_irq	= cp_intc_init,
> +	.timer		= &davinci_timer,
> +	.init_machine	= mityomapl138_init,
> +MACHINE_END
> diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
> index 15a6192..d370391 100644
> --- a/arch/arm/mach-davinci/include/mach/uncompress.h
> +++ b/arch/arm/mach-davinci/include/mach/uncompress.h
> @@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
>  		/* DA8xx boards */
>  		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
>  		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
> +		DEBUG_LL_DA8XX(mityomapl138,		1);
>  
>  		/* TNETV107x boards */
>  		DEBUG_LL_TNETV107X(tnetv107x,		1);

From michael.williamson at criticallink.com  Tue Aug 31 09:59:09 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 31 Aug 2010 10:59:09 -0400
Subject: [PATCH v1] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <87zkw2u956.fsf@deeprootsystems.com>
References: <4C7C52FD.6010608@criticallink.com>
	<87zkw2u956.fsf@deeprootsystems.com>
Message-ID: <4C7D18BD.9050708@criticallink.com>

 On 8/31/2010 10:52 AM, Kevin Hilman wrote:
> Michael Williamson <michael.williamson at criticallink.com> writes:
>
>> This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
>> on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
>> on the da850 davinci CPU architecture.  Information on these SOMs may be 
>> found at http://www.mitydsp.com.
>>
>> Basic support for the console UART, NAND, and EMAC (MII interface) is 
>> included in this patch. 
>>
>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>> ---
>> Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's tree 
>> (2.6.36-rc2).
>>
>> Changes since v0:
>>   1) Added CONFIG_REGULATOR_DUMMY to da8xx_omapl_defconfig to support
>>      DA8XX machines not providing voltage regulation.
>>   2) Added machine checks on da830/da850 EVM as well as MityDSP-L138 
>>      console init routines.
> These two should be a separate patch as it's a fix not directly related
> to your board support.
>

OK.  I'll separate them and resubmit.  Thanks for your help.

-Mike


From vm.rod25 at gmail.com  Tue Aug 31 10:02:36 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Tue, 31 Aug 2010 10:02:36 -0500
Subject: [PATCH] hawkboard
In-Reply-To: <0680EC522D0CC943BC586913CF3768C003C1CA4C39@dbde02.ent.ti.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<4C7CC655.3060104@mvista.com>
	<AANLkTindjAFnfXrgmgPyBcPudy=YdEH68DARToVMNLdz@mail.gmail.com>
	<0680EC522D0CC943BC586913CF3768C003C1CA4C39@dbde02.ent.ti.com>
Message-ID: <AANLkTi=_7kWVAg6ntakRqgHibqW5TSB3Sboqa7iYFevY@mail.gmail.com>

On Tue, Aug 31, 2010 at 9:51 AM, Syed Mohammed, Khasim <khasim at ti.com> wrote:
>
>
>> -----Original Message-----
>> From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-
>> linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Victor Rodriguez
>> Sent: Tuesday, August 31, 2010 8:16 PM
>> To: Sergei Shtylyov; davinci-linux-open-source at linux.davincidsp.com
>> Subject: Re: [PATCH] hawkboard
>>
>> On Tue, Aug 31, 2010 at 4:07 AM, Sergei Shtylyov <sshtylyov at mvista.com> wrote:
>> > Victor Rodriguez wrote:
>> >>
>> >> Basic support for Hawkboard OMAPL138 just UART cominication is included
>> >
>> >> Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
>> >
>> >> Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03
>> >> from
>> >> ? ? ? Kernel development tree for TI DaVinci family of processors
>> >
>> >> ? ? ? This patch works with basic da8xx_omapl_defconfig, it just have
>> >> basic support
>> >> ? ? ? for UART console
>> >> ---
>> >> ?arch/arm/mach-davinci/Kconfig ? ? ? ? ? ? ? ? ? | ? ?9 +++
>> >> ?arch/arm/mach-davinci/Makefile ? ? ? ? ? ? ? ? ?| ? ?1 +
>> >> ?arch/arm/mach-davinci/board-da850-hawk.c ? ? ? ?| ? 69
>> >> +++++++++++++++++++++++
>> >> ?arch/arm/mach-davinci/include/mach/uncompress.h | ? ?1 +
>> >> ?4 files changed, 80 insertions(+), 0 deletions(-)
>> >> ?create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
>> >>
>> >> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>> >> index 2bf03e9..fd8a11c 100644
>> >> --- a/arch/arm/mach-davinci/Kconfig
>> >> +++ b/arch/arm/mach-davinci/Kconfig
>> >> @@ -185,6 +185,15 @@ config MACH_TNETV107X
>> >> ? ? ? help
>> >> ? ? ? ? Say Y here to select the TI TNETV107X Evaluation Module.
>> >>
>> >> +config MACH_OMAPL138_HAWKBOARD
>> >> + ? ? ? bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
>> >> + ? ? ? default ARCH_DAVINCI_DA850
>> >
>> > ? Only EVM boards are enabled by default.
>> >
>> >> + ? ? ? depends on ARCH_DAVINCI_DA850
>> >> + ? ? ? help
>> >> + ? ? ? ? Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
>> >> + ? ? ? ? Information of this board may be found at
>> >> + ? ? ? ? http://www.hawkboard.org/
>> >> +
>> >> ?config DAVINCI_MUX
>> >> ? ? ? bool "DAVINCI multiplexing support"
>> >> ? ? ? depends on ARCH_DAVINCI
>> >
>> > [...]
>> >>
>> >> diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
>> >> b/arch/arm/mach-davinci/board-da850-hawk.c
>> >> new file mode 100644
>> >> index 0000000..e34bcbb
>> >> --- /dev/null
>> >> +++ b/arch/arm/mach-davinci/board-da850-hawk.c
>> >> @@ -0,0 +1,69 @@
>> >> +/*
>> >> + * Hawkboar.org based on TI's OMAP-L138 Platform
>> >
>> > ? Hawkboard.org?
>> >
>> >> + *
>> >> + * Initial code: Syed Mohammed Khasim
>> >> + *
>> >> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
>> >> + *
>> >> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
>> >> + * Original Copyrights follow:
>> >> + *
>> >> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
>> >
>> > ? MV didn't write any code in board-da850-evm.c, so the original copyright
>> > is wrong.
>>
>>
>> One question i was looking for the root of the original code and found this
>>
>> board-da850-hawk.c is derived from
>>
>>
>> arch/arm/mach-davinci/board-da850-evm.c
>>
>> and it is derived from
>>
>> arch/arm/mach-davinci/board-da830-evm.c
>>
>> and it is derived from
>>
>> arch/arm/mach-davinci/board-dm644x-evm.c
>>
>> which shows this
>>
>> /*
>> ?* TI DaVinci EVM board support
>> ?*
>> ?* Author: Kevin Hilman, MontaVista Software, Inc. <source at mvista.com>
>> ?*
>> ?* 2007 (c) MontaVista Software, Inc. This file is licensed under
>> ?* the terms of the GNU General Public License version 2. This program
>> ?* is licensed "as is" without any warranty of any kind, whether express
>> ?* or implied.
>> ?*/
>>
>> Until i understand Kevin wrote that code there is no more derived from
>> so i think the best is to keep with that copy right but, is just a
>> question please tell me which should i write like original copy right
>>
>>
> I generally follow the immediate one, in this case we can say derived from board-da850-evm.c, with this we will know which code to refer for in future for porting or merging. We can track any changes that happen to this board file and are generic to be taken up across the da850 based boards.

Thanks Khasim I will keep it just like you wrote in the original
board-da850-hawk.c

Bye the way Nori and Caglar found these mistake about serial

change the console= kernel parameter to ttyS0?

Any clue I really do not understand.

Until I understand the serial port works fine for my Hawkboard if i keep

	__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
	__raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);

Otherwise it will show the

too much work in irq53
too much work in irq53
...

messages

Thanks for the help and do not worry about the work to get this patch
accepted  I like these job

Best regards

Victor Rodriguez

>
>>
>> >> + * the terms of the GNU General Public License version 2. This program
>> >> + * is licensed "as is" without any warranty of any kind, whether express
>> >> + * or implied.
>> >> + */
>> >> +#include <linux/kernel.h>
>> >> +#include <linux/init.h>
>> >> +#include <linux/console.h>
>> >> +#include <linux/gpio.h>
>> >> +
>> >> +#include <asm/mach-types.h>
>> >> +#include <asm/mach/arch.h>
>> >> +
>> >> +#include <mach/cp_intc.h>
>> >> +#include <mach/da8xx.h>
>> >> +
>> >> +
>> >> +
>> >
>> > ? Too many empty lines?
>> >
>> >> +static struct davinci_uart_config omapl138_hawk_uart_config __initdata =
>> >> {
>> >> + ? ? ? .enabled_uarts = 0x7,
>> >
>> > ? Why enable URARTs 0 and 1 if you shut down them below?
>> >
>> >> +};
>> >> +
>> >> +static __init void omapl138_hawk_init(void)
>> >> +{
>> >> +
>> >> + ? ? ? davinci_serial_init(&omapl138_hawk_uart_config);
>> >> +
>> >> + ? ? ? /*
>> >> + ? ? ? ?* shut down uart 0 and 1; they are not used on the board and
>> >> + ? ? ? ?* accessing them causes endless "too much work in irq53" messages
>> >> + ? ? ? ?* with arago fs
>> >> + ? ? ? ?*/
>> >> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
>> >> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
>> >> +
>> >> +}
>> >
>> > WBR, Sergei
>> >
>> >
>>
>> Whit Best Regards
>>
>> Victor Rodriguez
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
> Regards,
> Khasim
>

From vm.rod25 at gmail.com  Tue Aug 31 10:11:54 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Tue, 31 Aug 2010 10:11:54 -0500
Subject: [PATCH] hawkboard
In-Reply-To: <AANLkTi=_7kWVAg6ntakRqgHibqW5TSB3Sboqa7iYFevY@mail.gmail.com>
References: <AANLkTinw5QBcVcO3OmdXMqRBbfx6LE6WHSPqjtkg16vj@mail.gmail.com>
	<4C7CC655.3060104@mvista.com>
	<AANLkTindjAFnfXrgmgPyBcPudy=YdEH68DARToVMNLdz@mail.gmail.com>
	<0680EC522D0CC943BC586913CF3768C003C1CA4C39@dbde02.ent.ti.com>
	<AANLkTi=_7kWVAg6ntakRqgHibqW5TSB3Sboqa7iYFevY@mail.gmail.com>
Message-ID: <AANLkTi=Xn3fCbR8YHs3-0Cwh+dWHoOnu8wSYtfU8qT9p@mail.gmail.com>

On Tue, Aug 31, 2010 at 10:02 AM, Victor Rodriguez <vm.rod25 at gmail.com> wrote:
> On Tue, Aug 31, 2010 at 9:51 AM, Syed Mohammed, Khasim <khasim at ti.com> wrote:
>>
>>
>>> -----Original Message-----
>>> From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-
>>> linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Victor Rodriguez
>>> Sent: Tuesday, August 31, 2010 8:16 PM
>>> To: Sergei Shtylyov; davinci-linux-open-source at linux.davincidsp.com
>>> Subject: Re: [PATCH] hawkboard
>>>
>>> On Tue, Aug 31, 2010 at 4:07 AM, Sergei Shtylyov <sshtylyov at mvista.com> wrote:
>>> > Victor Rodriguez wrote:
>>> >>
>>> >> Basic support for Hawkboard OMAPL138 just UART cominication is included
>>> >
>>> >> Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
>>> >
>>> >> Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03
>>> >> from
>>> >> ? ? ? Kernel development tree for TI DaVinci family of processors
>>> >
>>> >> ? ? ? This patch works with basic da8xx_omapl_defconfig, it just have
>>> >> basic support
>>> >> ? ? ? for UART console
>>> >> ---
>>> >> ?arch/arm/mach-davinci/Kconfig ? ? ? ? ? ? ? ? ? | ? ?9 +++
>>> >> ?arch/arm/mach-davinci/Makefile ? ? ? ? ? ? ? ? ?| ? ?1 +
>>> >> ?arch/arm/mach-davinci/board-da850-hawk.c ? ? ? ?| ? 69
>>> >> +++++++++++++++++++++++
>>> >> ?arch/arm/mach-davinci/include/mach/uncompress.h | ? ?1 +
>>> >> ?4 files changed, 80 insertions(+), 0 deletions(-)
>>> >> ?create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c
>>> >>
>>> >> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>> >> index 2bf03e9..fd8a11c 100644
>>> >> --- a/arch/arm/mach-davinci/Kconfig
>>> >> +++ b/arch/arm/mach-davinci/Kconfig
>>> >> @@ -185,6 +185,15 @@ config MACH_TNETV107X
>>> >> ? ? ? help
>>> >> ? ? ? ? Say Y here to select the TI TNETV107X Evaluation Module.
>>> >>
>>> >> +config MACH_OMAPL138_HAWKBOARD
>>> >> + ? ? ? bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
>>> >> + ? ? ? default ARCH_DAVINCI_DA850
>>> >
>>> > ? Only EVM boards are enabled by default.
>>> >
>>> >> + ? ? ? depends on ARCH_DAVINCI_DA850
>>> >> + ? ? ? help
>>> >> + ? ? ? ? Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
>>> >> + ? ? ? ? Information of this board may be found at
>>> >> + ? ? ? ? http://www.hawkboard.org/
>>> >> +
>>> >> ?config DAVINCI_MUX
>>> >> ? ? ? bool "DAVINCI multiplexing support"
>>> >> ? ? ? depends on ARCH_DAVINCI
>>> >
>>> > [...]
>>> >>
>>> >> diff --git a/arch/arm/mach-davinci/board-da850-hawk.c
>>> >> b/arch/arm/mach-davinci/board-da850-hawk.c
>>> >> new file mode 100644
>>> >> index 0000000..e34bcbb
>>> >> --- /dev/null
>>> >> +++ b/arch/arm/mach-davinci/board-da850-hawk.c
>>> >> @@ -0,0 +1,69 @@
>>> >> +/*
>>> >> + * Hawkboar.org based on TI's OMAP-L138 Platform
>>> >
>>> > ? Hawkboard.org?
>>> >
>>> >> + *
>>> >> + * Initial code: Syed Mohammed Khasim
>>> >> + *
>>> >> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
>>> >> + *
>>> >> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
>>> >> + * Original Copyrights follow:
>>> >> + *
>>> >> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
>>> >
>>> > ? MV didn't write any code in board-da850-evm.c, so the original copyright
>>> > is wrong.
>>>
>>>
>>> One question i was looking for the root of the original code and found this
>>>
>>> board-da850-hawk.c is derived from
>>>
>>>
>>> arch/arm/mach-davinci/board-da850-evm.c
>>>
>>> and it is derived from
>>>
>>> arch/arm/mach-davinci/board-da830-evm.c
>>>
>>> and it is derived from
>>>
>>> arch/arm/mach-davinci/board-dm644x-evm.c
>>>
>>> which shows this
>>>
>>> /*
>>> ?* TI DaVinci EVM board support
>>> ?*
>>> ?* Author: Kevin Hilman, MontaVista Software, Inc. <source at mvista.com>
>>> ?*
>>> ?* 2007 (c) MontaVista Software, Inc. This file is licensed under
>>> ?* the terms of the GNU General Public License version 2. This program
>>> ?* is licensed "as is" without any warranty of any kind, whether express
>>> ?* or implied.
>>> ?*/
>>>
>>> Until i understand Kevin wrote that code there is no more derived from
>>> so i think the best is to keep with that copy right but, is just a
>>> question please tell me which should i write like original copy right
>>>
>>>
>> I generally follow the immediate one, in this case we can say derived from board-da850-evm.c, with this we will know which code to refer for in future for porting or merging. We can track any changes that happen to this board file and are generic to be taken up across the da850 based boards.
>
> Thanks Khasim I will keep it just like you wrote in the original
> board-da850-hawk.c
>
> Bye the way Nori and Caglar found these mistake about serial
>
> change the console= kernel parameter to ttyS0?
>
> Any clue I really do not understand.
>
> Until I understand the serial port works fine for my Hawkboard if i keep
>
> ? ? ? ?__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
> ? ? ? ?__raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
>
> Otherwise it will show the
>
> too much work in irq53
> too much work in irq53
> ...
>
> messages
>
> Thanks for the help and do not worry about the work to get this patch
> accepted ?I like these job
>
> Best regards
>
> Victor Rodriguez
>
>>
>>>
>>> >> + * the terms of the GNU General Public License version 2. This program
>>> >> + * is licensed "as is" without any warranty of any kind, whether express
>>> >> + * or implied.
>>> >> + */
>>> >> +#include <linux/kernel.h>
>>> >> +#include <linux/init.h>
>>> >> +#include <linux/console.h>
>>> >> +#include <linux/gpio.h>
>>> >> +
>>> >> +#include <asm/mach-types.h>
>>> >> +#include <asm/mach/arch.h>
>>> >> +
>>> >> +#include <mach/cp_intc.h>
>>> >> +#include <mach/da8xx.h>
>>> >> +
>>> >> +
>>> >> +
>>> >
>>> > ? Too many empty lines?
>>> >
>>> >> +static struct davinci_uart_config omapl138_hawk_uart_config __initdata =
>>> >> {
>>> >> + ? ? ? .enabled_uarts = 0x7,
>>> >
>>> > ? Why enable URARTs 0 and 1 if you shut down them below?
>>> >
>>> >> +};
>>> >> +
>>> >> +static __init void omapl138_hawk_init(void)
>>> >> +{
>>> >> +
>>> >> + ? ? ? davinci_serial_init(&omapl138_hawk_uart_config);
>>> >> +
>>> >> + ? ? ? /*
>>> >> + ? ? ? ?* shut down uart 0 and 1; they are not used on the board and
>>> >> + ? ? ? ?* accessing them causes endless "too much work in irq53" messages
>>> >> + ? ? ? ?* with arago fs
>>> >> + ? ? ? ?*/
>>> >> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
>>> >> + ? ? ? __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
>>> >> +
>>> >> +}
>>> >
>>> > WBR, Sergei
>>> >
>>> >
>>>
>>> Whit Best Regards
>>>
>>> Victor Rodriguez
>>> _______________________________________________
>>> Davinci-linux-open-source mailing list
>>> Davinci-linux-open-source at linux.davincidsp.com
>>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>> Regards,
>> Khasim
>>
>

I sorry for the last patch i send the next from git send email, about
the serial problems it woks fine for booting the kernel in hawkboard.
And until i understand is the same the hawkboard is usnig the same
UART configuration that all the da8xx boards

 		/* DA8xx boards */
		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
		DEBUG_LL_DA8XX(omapl138_hawkboard,	2);




Thanks for all your comments , help me to improve the code

Sincerely yours

Victor Rodriguez

From vm.rod25 at gmail.com  Tue Aug 31 10:17:25 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Tue, 31 Aug 2010 10:17:25 -0500
Subject: [PATCH] hawkboard v_2
Message-ID: <1283267845-2646-1-git-send-email-vm.rod25@gmail.com>

Basic support for Hawkboard OMAPL138 just UART cominication is included

Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>

Notes: This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03 from
	Kernel development tree for TI DaVinci family of processors

	This patch works with basic da8xx_omapl_defconfig, it just have basic support
	for UART console

Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
---
 arch/arm/mach-davinci/Kconfig                   |    9 +++
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-da850-hawk.c        |   69 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 4 files changed, 80 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2bf03e9..fd8a11c 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -185,6 +185,15 @@ config MACH_TNETV107X
 	help
 	  Say Y here to select the TI TNETV107X Evaluation Module.
 
+config MACH_OMAPL138_HAWKBOARD
+	bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
+	default ARCH_DAVINCI_DA850
+	depends on ARCH_DAVINCI_DA850
+	help
+	  Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
+	  Information of this board may be found at
+	  http://www.hawkboard.org/
+
 config DAVINCI_MUX
 	bool "DAVINCI multiplexing support"
 	depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..fd271cd 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
 obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
+obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD)	+= board-da850-hawk.o
 
 # Power Management
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
diff --git a/arch/arm/mach-davinci/board-da850-hawk.c b/arch/arm/mach-davinci/board-da850-hawk.c
new file mode 100644
index 0000000..e34bcbb
--- /dev/null
+++ b/arch/arm/mach-davinci/board-da850-hawk.c
@@ -0,0 +1,69 @@
+/*
+ * Hawkboar.org based on TI's OMAP-L138 Platform
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Derived from: arch/arm/mach-davinci/board-da850-evm.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/gpio.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+
+
+
+static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
+	.enabled_uarts = 0x7,
+};
+
+static __init void omapl138_hawk_init(void)
+{
+
+	davinci_serial_init(&omapl138_hawk_uart_config);
+
+	/*
+	 * shut down uart 0 and 1; they are not used on the board and
+	 * accessing them causes endless "too much work in irq53" messages
+	 * with arago fs
+	 */
+	__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
+	__raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init omapl138_hawk_console_init(void)
+{
+	return add_preferred_console("ttyS", 2, "115200");
+}
+console_initcall(omapl138_hawk_console_init);
+#endif
+
+static void __init omapl138_hawk_map_io(void)
+{
+	da850_init();
+}
+
+MACHINE_START(OMAPL138_HAWKBOARD, "OMAPL 138 Hawkboard.org")
+	.phys_io	= IO_PHYS,
+	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
+	.boot_params	= (DA8XX_DDR_BASE + 0x100),
+	.map_io		= omapl138_hawk_map_io,
+	.init_irq	= cp_intc_init,
+	.timer		= &davinci_timer,
+	.init_machine	= omapl138_hawk_init,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 15a6192..640f834 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 		/* DA8xx boards */
 		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
 		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+		DEBUG_LL_DA8XX(omapl138_hawkboard,	2);
 
 		/* TNETV107x boards */
 		DEBUG_LL_TNETV107X(tnetv107x,		1);
-- 
1.6.0.5


From nsekhar at ti.com  Tue Aug 31 10:39:20 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 31 Aug 2010 21:09:20 +0530
Subject: [PATCH v1] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <4C7C52FD.6010608@criticallink.com>
References: <4C7C52FD.6010608@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301F6AC5679@dbde02.ent.ti.com>

Hi Michael,

On Tue, Aug 31, 2010 at 06:25:25, Michael Williamson wrote:
> This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
> on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
> on the da850 davinci CPU architecture.  Information on these SOMs may be
> found at http://www.mitydsp.com.
>
> Basic support for the console UART, NAND, and EMAC (MII interface) is
> included in this patch.
>
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>

[...]

> diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
> index 292e8b7..e51a80f 100644
> --- a/arch/arm/mach-davinci/board-da830-evm.c
> +++ b/arch/arm/mach-davinci/board-da830-evm.c
> @@ -586,6 +586,9 @@ static __init void da830_evm_init(void)
>  #ifdef CONFIG_SERIAL_8250_CONSOLE
>  static int __init da830_evm_console_init(void)
>  {
> +     if (!machine_is_davinci_da830_evm())
> +             return 0;
> +
>       return add_preferred_console("ttyS", 2, "115200");
>  }
>  console_initcall(da830_evm_console_init);
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 190ebd3..d491b5f 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -847,6 +847,9 @@ static __init void da850_evm_init(void)
>  #ifdef CONFIG_SERIAL_8250_CONSOLE
>  static int __init da850_evm_console_init(void)
>  {
> +     if (!machine_is_davinci_da850_evm())
> +             return 0;
> +
>       return add_preferred_console("ttyS", 2, "115200");
>  }
>  console_initcall(da850_evm_console_init);

I think this should be carved into a separate patch as
this is a bug fix of existing code rather than addition
of new board as subject and description of this patch
indicate.

> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> new file mode 100644
> index 0000000..7338adb
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> @@ -0,0 +1,220 @@
> +/*
> + * Critical Link MityOMAP-L138 SoM
> + *
> + * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of
> + * any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/console.h>
> +#include <linux/platform_device.h>
> +#include <linux/mtd/partitions.h>
> +
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/common.h>
> +#include <mach/cp_intc.h>
> +#include <mach/da8xx.h>
> +#include <mach/nand.h>
> +#include <mach/mux.h>
> +
> +#define MITYOMAPL138_PHY_MASK                0x08 /* hardcoded for now */
> +#define MITYOMAPL138_MDIO_FREQUENCY  (2200000) /* PHY bus frequency */
> +
> +/*
> + * MityDSP-L138 includes a 256 MByte large-page NAND flash
> + * (128K blocks).
> + */
> +struct mtd_partition mityomapl138_nandflash_partition[] = {
> +     {
> +             .name           = "rootfs",
> +             .offset         = 0,
> +             .size           = SZ_128M,
> +             .mask_flags     = 0, /* MTD_WRITEABLE, */
> +     },
> +     {
> +             .name           = "homefs",
> +             .offset         = MTDPART_OFS_APPEND,
> +             .size           = MTDPART_SIZ_FULL,
> +             .mask_flags     = 0,
> +     },
> +};
> +
> +static struct davinci_nand_pdata mityomapl138_nandflash_data = {
> +     .parts          = mityomapl138_nandflash_partition,
> +     .nr_parts       = ARRAY_SIZE(mityomapl138_nandflash_partition),
> +     .ecc_mode       = NAND_ECC_HW,
> +     .options        = NAND_USE_FLASH_BBT | NAND_BUSWIDTH_16,
> +     .ecc_bits   = 1, /* 4 bit mode is not supported with 16 bit NAND */
> +};
> +
> +static struct resource mityomapl138_nandflash_resource[] = {
> +     {
> +             .start  = DA8XX_AEMIF_CS3_BASE,
> +             .end    = DA8XX_AEMIF_CS3_BASE + SZ_512K + 2 * SZ_1K - 1,
> +             .flags  = IORESOURCE_MEM,
> +     },
> +     {
> +             .start  = DA8XX_AEMIF_CTL_BASE,
> +             .end    = DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
> +             .flags  = IORESOURCE_MEM,
> +     },
> +};
> +
> +static struct platform_device mityomapl138_nandflash_device = {
> +     .name           = "davinci_nand",
> +     .id             = 0,
> +     .dev            = {
> +             .platform_data  = &mityomapl138_nandflash_data,
> +     },
> +     .num_resources  = ARRAY_SIZE(mityomapl138_nandflash_resource),
> +     .resource       = mityomapl138_nandflash_resource,
> +};
> +
> +static struct platform_device *mityomapl138_devices[] __initdata = {
> +     &mityomapl138_nandflash_device,
> +};
> +
> +static void __init mityomapl138_setup_nand(void)
> +{
> +     platform_add_devices(mityomapl138_devices,
> +                              ARRAY_SIZE(mityomapl138_devices));
> +}
> +
> +static struct davinci_uart_config mityomapl138_uart_config __initdata = {
> +     .enabled_uarts = 0x7,
> +};
> +
> +static const short mityomap_mii_pins[] = {
> +     DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
> +     DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
> +     DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
> +     DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
> +     DA850_MDIO_D,
> +     -1
> +};
> +
> +static const short mityomap_rmii_pins[] = {
> +     DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
> +     DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
> +     DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
> +     DA850_MDIO_D,
> +     -1
> +};
> +
> +static void __init mityomapl138_config_emac(void)
> +{
> +     void __iomem *cfg_chip3_base;
> +     int ret;
> +     u32 val;
> +     struct davinci_soc_info *soc_info = &davinci_soc_info;
> +     soc_info->emac_pdata->rmii_en = 0; /* hardcoded for now */
> +
> +     cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
> +     val = __raw_readl(cfg_chip3_base);
> +
> +     if (soc_info->emac_pdata->rmii_en) {
> +             val |= BIT(8);
> +             ret = davinci_cfg_reg_list(mityomap_rmii_pins);
> +             pr_info("RMII PHY configured\n");
> +     } else {
> +             val &= ~BIT(8);
> +             ret = davinci_cfg_reg_list(mityomap_mii_pins);
> +             pr_info("MII PHY configured\n");
> +     }
> +
> +     if (ret) {
> +             pr_warning("mii/rmii mux setup failed: %d\n", ret);
> +             return;
> +     }
> +
> +     /* configure the CFGCHIP3 register for RMII or MII */
> +     __raw_writel(val, cfg_chip3_base);
> +
> +     soc_info->emac_pdata->phy_mask = MITYOMAPL138_PHY_MASK;
> +     pr_info("setting phy_mask to %x\n", soc_info->emac_pdata->phy_mask);

This should be pr_debug()?

Thanks,
Sekhar


From nsekhar at ti.com  Tue Aug 31 11:14:16 2010
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 31 Aug 2010 21:44:16 +0530
Subject: [PATCH v1] davinci: Initial support for MityDSP-L138/MityARM-1808
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301F6AC5679@dbde02.ent.ti.com>
References: <4C7C52FD.6010608@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59301F6AC5679@dbde02.ent.ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301F6AC5699@dbde02.ent.ti.com>

On Tue, Aug 31, 2010 at 21:09:20, Nori, Sekhar wrote:
> > @@ -586,6 +586,9 @@ static __init void da830_evm_init(void)
> >  #ifdef CONFIG_SERIAL_8250_CONSOLE
> >  static int __init da830_evm_console_init(void)
> >  {
> > +     if (!machine_is_davinci_da830_evm())
> > +             return 0;
> > +
> >       return add_preferred_console("ttyS", 2, "115200");
> >  }
> >  console_initcall(da830_evm_console_init);
> > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> > index 190ebd3..d491b5f 100644
> > --- a/arch/arm/mach-davinci/board-da850-evm.c
> > +++ b/arch/arm/mach-davinci/board-da850-evm.c
> > @@ -847,6 +847,9 @@ static __init void da850_evm_init(void)
> >  #ifdef CONFIG_SERIAL_8250_CONSOLE
> >  static int __init da850_evm_console_init(void)
> >  {
> > +     if (!machine_is_davinci_da850_evm())
> > +             return 0;
> > +
> >       return add_preferred_console("ttyS", 2, "115200");
> >  }
> >  console_initcall(da850_evm_console_init);
>
> I think this should be carved into a separate patch as
> this is a bug fix of existing code rather than addition
> of new board as subject and description of this patch
> indicate.
>

Oops, missed seeing that Kevin already pointed this out.
Sorry about that.

Thanks,
Sekhar


From hankm at ncast.com  Tue Aug 31 13:11:55 2010
From: hankm at ncast.com (Hank Magnuski)
Date: Tue, 31 Aug 2010 11:11:55 -0700 (PDT)
Subject: DM365 - Watchdog Timer
In-Reply-To: <4C7C8F94.2030905@einfochips.com>
References: <4C7BB626.3020204@einfochips.com>
	<alpine.LRH.2.00.1008300702340.18001@sv-04.mtinet.com>
	<4C7C8C5B.1080703@einfochips.com>
	<alpine.LRH.2.00.1008302205210.15294@sv-04.mtinet.com>
	<4C7C8F94.2030905@einfochips.com>
Message-ID: <alpine.LRH.2.00.1008311108350.13495@sv-04.mtinet.com>


I'm trying to find code in UBL and/or U-Boot where the watchdog timer is reset.

Is that part of the normal boot process, or is it only done in Linux?

Any pointers to code where this is done would be appreciated.

Regards,

Hank


From michael.williamson at criticallink.com  Tue Aug 31 13:30:15 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 31 Aug 2010 14:30:15 -0400
Subject: [PATCH] davinci: Add machine checks to DA8XX serial console init
	routines
Message-ID: <1283279415-25678-1-git-send-email-michael.williamson@criticallink.com>

This patch adds machine checks in the serial console init routines
for the DA8XX EVM boards.  This is needed because there are other
DA8XX based machines that use a different UART/tty as the console
and may be included in a common kernel build.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-da830-evm.c |    3 +++
 arch/arm/mach-davinci/board-da850-evm.c |    3 +++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 292e8b7..e51a80f 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -586,6 +586,9 @@ static __init void da830_evm_init(void)
 #ifdef CONFIG_SERIAL_8250_CONSOLE
 static int __init da830_evm_console_init(void)
 {
+	if (!machine_is_davinci_da830_evm())
+		return 0;
+
 	return add_preferred_console("ttyS", 2, "115200");
 }
 console_initcall(da830_evm_console_init);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 190ebd3..d491b5f 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -847,6 +847,9 @@ static __init void da850_evm_init(void)
 #ifdef CONFIG_SERIAL_8250_CONSOLE
 static int __init da850_evm_console_init(void)
 {
+	if (!machine_is_davinci_da850_evm())
+		return 0;
+
 	return add_preferred_console("ttyS", 2, "115200");
 }
 console_initcall(da850_evm_console_init);
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Aug 31 13:42:32 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 31 Aug 2010 14:42:32 -0400
Subject: [PATCH] davinci: Add CONFIG_REGULATOR_DUMMY to DA8XX defconfig file.
Message-ID: <1283280152-26059-1-git-send-email-michael.williamson@criticallink.com>

In order to support reference DA8XX machines not providing a
voltage regulator control for the core voltage, the REGULATOR_DUMMY
option is required.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/configs/da8xx_omapl_defconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/da8xx_omapl_defconfig b/arch/arm/configs/da8xx_omapl_defconfig
index ba66705..3952a4e 100644
--- a/arch/arm/configs/da8xx_omapl_defconfig
+++ b/arch/arm/configs/da8xx_omapl_defconfig
@@ -79,6 +79,7 @@ CONFIG_I2C_DAVINCI=y
 # CONFIG_HWMON is not set
 CONFIG_WATCHDOG=y
 CONFIG_REGULATOR=y
+CONFIG_REGULATOR_DUMMY=y
 CONFIG_REGULATOR_TPS6507X=y
 CONFIG_FB=y
 CONFIG_FB_DA8XX=y
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Aug 31 13:56:55 2010
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 31 Aug 2010 14:56:55 -0400
Subject: [PATCH v2] davinci: Initial support for MityDSP-L138/MityARM-1808
Message-ID: <1283281015-28360-1-git-send-email-michael.williamson@criticallink.com>

This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
on the da850 davinci CPU architecture.  Information on these SOMs may be
found at http://www.mitydsp.com.

Basic support for the console UART, NAND, and EMAC (MII interface) is
included in this patch.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
Changes since v1:
   1) Split out defconfig changes to separate patch.
   2) Split out console init changes to DA8XX EVMS to separate patch.
   3) Change a pr_info() to a pr_debug().

 arch/arm/mach-davinci/Kconfig                   |    9 +
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-mityomapl138.c      |  220 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 4 files changed, 231 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-mityomapl138.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2bf03e9..633eccb 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -185,6 +185,15 @@ config MACH_TNETV107X
 	help
 	  Say Y here to select the TI TNETV107X Evaluation Module.
 
+config MACH_MITYOMAPL138
+	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
+	default ARCH_DAVINCI_DA850
+	depends on ARCH_DAVINCI_DA850
+	help
+	  Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
+	  System on Module.  Information on this SoM may be found at
+	  http://www.mitydsp.com
+
 config DAVINCI_MUX
 	bool "DAVINCI multiplexing support"
 	depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..3e966e8 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
 obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
+obj-$(CONFIG_MACH_MITYOMAPL138)		+= board-mityomapl138.o
 
 # Power Management
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
new file mode 100644
index 0000000..f95cd9c
--- /dev/null
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -0,0 +1,220 @@
+/*
+ * Critical Link MityOMAP-L138 SoM
+ *
+ * Copyright (C) 2010 Critical Link LLC - http://www.criticallink.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of
+ * any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/common.h>
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+#include <mach/nand.h>
+#include <mach/mux.h>
+
+#define MITYOMAPL138_PHY_MASK		0x08 /* hardcoded for now */
+#define MITYOMAPL138_MDIO_FREQUENCY	(2200000) /* PHY bus frequency */
+
+/*
+ * MityDSP-L138 includes a 256 MByte large-page NAND flash
+ * (128K blocks).
+ */
+struct mtd_partition mityomapl138_nandflash_partition[] = {
+	{
+		.name		= "rootfs",
+		.offset		= 0,
+		.size		= SZ_128M,
+		.mask_flags	= 0, /* MTD_WRITEABLE, */
+	},
+	{
+		.name		= "homefs",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0,
+	},
+};
+
+static struct davinci_nand_pdata mityomapl138_nandflash_data = {
+	.parts		= mityomapl138_nandflash_partition,
+	.nr_parts	= ARRAY_SIZE(mityomapl138_nandflash_partition),
+	.ecc_mode	= NAND_ECC_HW,
+	.options	= NAND_USE_FLASH_BBT | NAND_BUSWIDTH_16,
+	.ecc_bits   = 1, /* 4 bit mode is not supported with 16 bit NAND */
+};
+
+static struct resource mityomapl138_nandflash_resource[] = {
+	{
+		.start	= DA8XX_AEMIF_CS3_BASE,
+		.end	= DA8XX_AEMIF_CS3_BASE + SZ_512K + 2 * SZ_1K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.start	= DA8XX_AEMIF_CTL_BASE,
+		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device mityomapl138_nandflash_device = {
+	.name		= "davinci_nand",
+	.id		= 0,
+	.dev		= {
+		.platform_data	= &mityomapl138_nandflash_data,
+	},
+	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
+	.resource	= mityomapl138_nandflash_resource,
+};
+
+static struct platform_device *mityomapl138_devices[] __initdata = {
+	&mityomapl138_nandflash_device,
+};
+
+static void __init mityomapl138_setup_nand(void)
+{
+	platform_add_devices(mityomapl138_devices,
+				 ARRAY_SIZE(mityomapl138_devices));
+}
+
+static struct davinci_uart_config mityomapl138_uart_config __initdata = {
+	.enabled_uarts = 0x7,
+};
+
+static const short mityomap_mii_pins[] = {
+	DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
+	DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
+	DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
+	DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
+static const short mityomap_rmii_pins[] = {
+	DA850_RMII_TXD_0, DA850_RMII_TXD_1, DA850_RMII_TXEN,
+	DA850_RMII_CRS_DV, DA850_RMII_RXD_0, DA850_RMII_RXD_1,
+	DA850_RMII_RXER, DA850_RMII_MHZ_50_CLK, DA850_MDIO_CLK,
+	DA850_MDIO_D,
+	-1
+};
+
+static void __init mityomapl138_config_emac(void)
+{
+	void __iomem *cfg_chip3_base;
+	int ret;
+	u32 val;
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+	soc_info->emac_pdata->rmii_en = 0; /* hardcoded for now */
+
+	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+	val = __raw_readl(cfg_chip3_base);
+
+	if (soc_info->emac_pdata->rmii_en) {
+		val |= BIT(8);
+		ret = davinci_cfg_reg_list(mityomap_rmii_pins);
+		pr_info("RMII PHY configured\n");
+	} else {
+		val &= ~BIT(8);
+		ret = davinci_cfg_reg_list(mityomap_mii_pins);
+		pr_info("MII PHY configured\n");
+	}
+
+	if (ret) {
+		pr_warning("mii/rmii mux setup failed: %d\n", ret);
+		return;
+	}
+
+	/* configure the CFGCHIP3 register for RMII or MII */
+	__raw_writel(val, cfg_chip3_base);
+
+	soc_info->emac_pdata->phy_mask = MITYOMAPL138_PHY_MASK;
+	pr_debug("setting phy_mask to %x\n", soc_info->emac_pdata->phy_mask);
+	soc_info->emac_pdata->mdio_max_freq = MITYOMAPL138_MDIO_FREQUENCY;
+
+	ret = da8xx_register_emac();
+	if (ret)
+		pr_warning("emac registration failed: %d\n", ret);
+}
+
+static struct davinci_pm_config da850_pm_pdata = {
+	.sleepcount = 128,
+};
+
+static struct platform_device da850_pm_device = {
+	.name	= "pm-davinci",
+	.dev = {
+		.platform_data  = &da850_pm_pdata,
+	},
+	.id	= -1,
+};
+
+static void __init mityomapl138_init(void)
+{
+	int ret;
+
+	/* for now, no special EDMA channels are reserved */
+	ret = da850_register_edma(NULL);
+	if (ret)
+		pr_warning("edma registration failed: %d\n", ret);
+
+	ret = da8xx_register_watchdog();
+	if (ret)
+		pr_warning("watchdog registration failed: %d\n", ret);
+
+	davinci_serial_init(&mityomapl138_uart_config);
+
+	mityomapl138_setup_nand();
+
+	mityomapl138_config_emac();
+
+	ret = da8xx_register_rtc();
+	if (ret)
+		pr_warning("rtc setup failed: %d\n", ret);
+
+	ret = da850_register_cpufreq("pll0_sysclk3");
+	if (ret)
+		pr_warning("cpufreq registration failed: %d\n", ret);
+
+	ret = da8xx_register_cpuidle();
+	if (ret)
+		pr_warning("cpuidle registration failed: %d\n", ret);
+
+	ret = da850_register_pm(&da850_pm_device);
+	if (ret)
+		pr_warning("da850_evm_init: suspend registration failed: %d\n",
+				ret);
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init mityomapl138_console_init(void)
+{
+	if (!machine_is_mityomapl138())
+		return 0;
+
+	return add_preferred_console("ttyS", 1, "115200");
+}
+console_initcall(mityomapl138_console_init);
+#endif
+
+static void __init mityomapl138_map_io(void)
+{
+	da850_init();
+}
+
+MACHINE_START(MITYOMAPL138, "MityDSP-L138/MityARM-1808")
+	.phys_io	= IO_PHYS,
+	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
+	.boot_params	= (DA8XX_DDR_BASE + 0x100),
+	.map_io		= mityomapl138_map_io,
+	.init_irq	= cp_intc_init,
+	.timer		= &davinci_timer,
+	.init_machine	= mityomapl138_init,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 15a6192..d370391 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 		/* DA8xx boards */
 		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
 		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+		DEBUG_LL_DA8XX(mityomapl138,		1);
 
 		/* TNETV107x boards */
 		DEBUG_LL_TNETV107X(tnetv107x,		1);
-- 
1.7.0.4


From vm.rod25 at gmail.com  Tue Aug 31 14:48:36 2010
From: vm.rod25 at gmail.com (Victor Rodriguez)
Date: Tue, 31 Aug 2010 14:48:36 -0500
Subject: [PATCH] hawkboard v_2
Message-ID: <1283284116-3288-1-git-send-email-vm.rod25@gmail.com>

Basic support for Hawkboard OMAPL138 just UART cominication is included

Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>

Notes: 	This patch deletes empty lines and typo mistakes from previous version

	This patch is checked with 0a50e05b20f3c6af67656303bdb3661a2541ce03 from
	Kernel development tree for TI DaVinci family of processors

	This patch works with basic da8xx_omapl_defconfig, it just have basic support
	for UART console

	This patch just works with UART 2 for argo file system

Signed-off-by: Victor Rodriguez <vm.rod25 at gmail.com>
---
 arch/arm/mach-davinci/Kconfig                   |    9 +++
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-da850-hawk.c        |   67 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 4 files changed, 78 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/board-da850-hawk.c

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 2bf03e9..fd8a11c 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -185,6 +185,15 @@ config MACH_TNETV107X
 	help
 	  Say Y here to select the TI TNETV107X Evaluation Module.
 
+config MACH_OMAPL138_HAWKBOARD
+	bool "TI DA850/OMAP-L138/AM18xx Hawkboard(.org) Platform"
+	default ARCH_DAVINCI_DA850
+	depends on ARCH_DAVINCI_DA850
+	help
+	  Say Y here to select the TI DA850/OMAP-L138/AM18xx Hawkboard.
+	  Information of this board may be found at
+	  http://www.hawkboard.org/
+
 config DAVINCI_MUX
 	bool "DAVINCI multiplexing support"
 	depends on ARCH_DAVINCI
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..fd271cd 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_DAVINCI_DM365_EVM)	+= board-dm365-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)	+= board-da830-evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
 obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
+obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD)	+= board-da850-hawk.o
 
 # Power Management
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
diff --git a/arch/arm/mach-davinci/board-da850-hawk.c b/arch/arm/mach-davinci/board-da850-hawk.c
new file mode 100644
index 0000000..4a7f2da
--- /dev/null
+++ b/arch/arm/mach-davinci/board-da850-hawk.c
@@ -0,0 +1,67 @@
+/*
+ * Hawkboard.org based on TI's OMAP-L138 Platform
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Derived from: arch/arm/mach-davinci/board-da830-hawk.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/console.h>
+#include <linux/gpio.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+
+static struct davinci_uart_config omapl138_hawk_uart_config __initdata = {
+	.enabled_uarts = 0x7,
+};
+
+static __init void omapl138_hawk_init(void)
+{
+
+	davinci_serial_init(&omapl138_hawk_uart_config);
+
+	/*
+	 * shut down uart 0 and 1; they are not used on the board and
+	 * accessing them causes endless "too much work in irq53" messages
+	 * with arago fs
+	 */
+	__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
+	__raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init omapl138_hawk_console_init(void)
+{
+	return add_preferred_console("ttyS", 2, "115200");
+}
+console_initcall(omapl138_hawk_console_init);
+#endif
+
+static void __init omapl138_hawk_map_io(void)
+{
+	da850_init();
+}
+
+MACHINE_START(OMAPL138_HAWKBOARD, "OMAPL 138 Hawkboard.org")
+	.phys_io	= IO_PHYS,
+	.io_pg_offst	= (__IO_ADDRESS(IO_PHYS) >> 18) & 0xfffc,
+	.boot_params	= (DA8XX_DDR_BASE + 0x100),
+	.map_io		= omapl138_hawk_map_io,
+	.init_irq	= cp_intc_init,
+	.timer		= &davinci_timer,
+	.init_machine	= omapl138_hawk_init,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 15a6192..640f834 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -88,6 +88,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 		/* DA8xx boards */
 		DEBUG_LL_DA8XX(davinci_da830_evm,	2);
 		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
+		DEBUG_LL_DA8XX(omapl138_hawkboard,	2);
 
 		/* TNETV107x boards */
 		DEBUG_LL_TNETV107X(tnetv107x,		1);
-- 
1.6.0.5


From Jon.Povey at racelogic.co.uk  Tue Aug 31 20:46:36 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Wed, 1 Sep 2010 02:46:36 +0100
Subject: DM365 - Watchdog Timer
In-Reply-To: <alpine.LRH.2.00.1008311108350.13495@sv-04.mtinet.com>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0903E02F3D@Cloud.RL.local>

Hank Magnuski wrote:
> I'm trying to find code in UBL and/or U-Boot where the watchdog timer
> is reset.
>
> Is that part of the normal boot process, or is it only done in Linux?

UBL and U-Boot don't touch the WDT.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From Jon.Povey at racelogic.co.uk  Tue Aug 31 21:01:37 2010
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Wed, 1 Sep 2010 03:01:37 +0100
Subject: DM365 - Watchdog Timer
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0903E02F3D@Cloud.RL.local>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0903E02F3F@Cloud.RL.local>

Jon Povey wrote:
> Hank Magnuski wrote:
>> I'm trying to find code in UBL and/or U-Boot where the watchdog
>> timer is reset.
>>
>> Is that part of the normal boot process, or is it only done in Linux?
>
> UBL and U-Boot don't touch the WDT.

Oh, I tell a lie. U-Boot uses it to reset the CPU, but doesn't use it as an actual watchdog.
Reset code in cpu/arm926ejs/davinci/reset.S

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network



From qinrui.taurus at gmail.com  Tue Aug 31 21:39:19 2010
From: qinrui.taurus at gmail.com (=?GB2312?B?x9jI8A==?=)
Date: Wed, 1 Sep 2010 10:39:19 +0800
Subject: unsubscribe from the mail list
Message-ID: <AANLkTikE032paWgUOW0L4_buT7=jEWx0LWX6+TOeoXac@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100901/aeaee6c9/attachment.html>

From freebard_86 at hotmail.com  Mon Aug 23 09:35:59 2010
From: freebard_86 at hotmail.com (=?ISO-8859-9?Q?=F6zg=FCr_Ozan_Yusufo=F0lu?=)
Date: Mon, 23 Aug 2010 14:35:59 -0000
Subject: Driver
Message-ID: <BLU0-SMTP141571965820A4099302299F820@phx.gbl>

Hi, I'm a novice embedded engineer who works in a IPTV STB project. We 
are using a DaVinci DM6446 based evaluation board for developing a 
firmware for our STB.  Unfortunetaly I am the only engineer who work in 
the software development side, and  don't have enough backround to deal 
with problems which I encountered.  Could you please enlighten me about 
these issues

1. I will use the open source Linux DaVinci kernel for development, and 
I didn't understand the driver side, in documents of TI its been said 
that LSP is integrated with Montavista kernel, is it still available to 
use LSP with open community Linux kernel? If it is,how can I do this?

2. Is there any pre-builded open source Linux kernel that all these 
drivers work completely within ?

3. It seems that the video-display  driver not functional  for Dm644x, 
in the http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel

4. What is the difference between LSP and PSP.  I couldn't find any 
document that gives detail about these issues . Could you give me any 
advice about where to start  ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100823/9b66f558/attachment-0001.html>

From Artem.Bityutskiy at nokia.com  Wed Aug 25 07:56:46 2010
From: Artem.Bityutskiy at nokia.com (Artem Bityutskiy)
Date: Wed, 25 Aug 2010 12:56:46 -0000
Subject: [RFC] nand/davinci: Fix comment to match the code
In-Reply-To: <039d01cb4450$e8f7d6a0$bae783e0$@raj@ti.com>
References: <1282738700-30966-1-git-send-email-w.sang@pengutronix.de>
	<039d01cb4450$e8f7d6a0$bae783e0$@raj@ti.com>
Message-ID: <1282740906.24044.210.camel@localhost>

On Wed, 2010-08-25 at 17:57 +0530, Sudhakar Rajashekhara wrote:
> > --- a/drivers/mtd/nand/davinci_nand.c
> > +++ b/drivers/mtd/nand/davinci_nand.c
> > @@ -369,8 +369,9 @@ compare:
> >  	 * after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
> >  	 * begin trying to poll for the state, you may fall right out of your
> >  	 * loop without any of the correction calculations having taken place.
> > -	 * The recommendation from the hardware team is to wait till ECC_STATE
> > -	 * reads less than 4, which means ECC HW has entered correction state.
> > +	 * The recommendation from the hardware team is to initially delay as
> > +	 * long as ECC_STATE reads less than 4. After that, ECC HW has entered
> > +	 * correction state.
> >  	 */
> >  	do {
> >  		ecc_state = (davinci_nand_readl(info,
> > -- 
> 
> Thanks for pointing this out, but I have already corrected this and submitted
> the patch. Artem Bityutskity has pushed this patch to his l2-mtd-2.6 / master
> tree.

If you mean

commit 1c3275b656045aff9a75bb2c9f3251af1043ebb3
Author: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
Date:   Tue Jul 20 15:24:01 2010 -0700

    mtd: nand: davinci: correct 4-bit error correction
    
    On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
    4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
    before waiting for the NAND Flash status register to be equal to 1, 2 or
    3, we have to wait till the ECC HW goes to correction state.  Without this
    wait, ECC correction calculations will not be proper.
    
    This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
    EVMs.
    
    Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
    Acked-by: Sneha Narnakaje <nsnehaprabha at ti.com>
    Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
    Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>

then it is already in upstream in Linus' tree. I do not have anything else from you.

-- 
Best Regards,
Artem Bityutskiy (????? ????????)


From dedekind1 at gmail.com  Sun Aug 29 06:48:21 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Sun, 29 Aug 2010 14:48:21 +0300
Subject: [PATCH 0/6] davinci: add support for aemif timing configuration
In-Reply-To: <1281349000-822-1-git-send-email-nsekhar@ti.com>
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
Message-ID: <1283082501.2131.29.camel@brekeke>

On Mon, 2010-08-09 at 15:46 +0530, Sekhar Nori wrote:
> This series of patches adds support for AEMIF timing configuration
> for DaVinci SoCs.
> 
> Currently AEMIF timing configuration is done as a special case for
> DM644x EVM. This work provides for a generic way of doing this.
> 
> David,
> 	Patch 1/6 and 2/6 of this series touch the
> 	drivers/mtd/nand/davinci_nand.c file along with other arch specific
> 	files. Based on the discussion on DaVinci list, Kevin is OK to merge
> 	this with your agreement. Please let us know how to proceed.

Pushed to l2-mtd-2.6.git / dunno.

-- 
Best Regards,
Artem Bityutskiy (???????? ?????)


From hongkong-aoli at vip.163.com  Mon Aug 30 19:23:44 2010
From: hongkong-aoli at vip.163.com (=?UTF-8?Q?Hongkong=C2=A0Aoli?=)
Date: Tue, 31 Aug 2010 08:23:44 +0800 (CST)
Subject: USB DVR from Shenzhen China
Message-ID: <7d8ddd.253.12ac5872c6b.Coremail.hongkong-aoli@vip.163.com>

hello.Dear sir?
     
     The attached file is the USB DVR quotation,Please note it.How many do you need?Anticipated your reply, hoped we can cooperate!If you have any questions, please contact us.
MOQ:20pcs,date of delivery:2days,Payment:By 100% by T/T  or Western Union. Have sth. in stock,modeoftranspor:EMS/UPS/DHL door to door.Warranty period:1 year.
 
 
Best wishes to you and to your family
Mr.Mike Wang
 
Shenzhen Aoli-Olyeem Electronics CO.,Ltd
Address :A630,1F, Huitong security market Shennan Road, Futian District, Shenzhen, Guangdong, China ZIP: 518109
website:http://www.007spycamera.com.cn
MSN:     ao.li168 at hotmail.com
E-mail:  ao.li0168 at hotmail.com
QQ: 810334902
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100831/adea0206/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: USB DVR quotation.xls
Type: application/vnd.ms-excel
Size: 376832 bytes
Desc: not available
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100831/adea0206/attachment-0001.xls>

From dedekind1 at gmail.com  Tue Aug 31 06:37:40 2010
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 31 Aug 2010 14:37:40 +0300
Subject: [PATCH 0/6] davinci: add support for aemif timing configuration
In-Reply-To: <877hj8b20x.fsf@deeprootsystems.com>
References: <1281349000-822-1-git-send-email-nsekhar@ti.com>
	<1283082501.2131.29.camel@brekeke> <877hj8b20x.fsf@deeprootsystems.com>
Message-ID: <1283254660.2018.29.camel@brekeke>

On Mon, 2010-08-30 at 07:36 -0700, Kevin Hilman wrote:
> > Pushed to l2-mtd-2.6.git / dunno.
> 
> Hi Artem,
> 
> If it's OK with you, and with your Ack, I'd prefer to merge this series
> via the davinci tree.
> 
> The reason is because the files touched in arch/arm/mach-davinci/* are
> also getting lots of other changes for 2.6.37, and I'd like to minimize
> conflicts.

Right, I've just removed them from my tree.

> Let me know if that's OK with you and if I can add your signoff to the
> drivers/mtd/* patches.  

The MTD part is small there, feel free to add

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>

Thanks!

-- 
Best Regards,
Artem Bityutskiy (???????? ?????)


From w.sang at pengutronix.de  Wed Aug 25 07:18:40 2010
From: w.sang at pengutronix.de (Wolfram Sang)
Date: Wed, 25 Aug 2010 12:18:40 -0000
Subject: [RFC] nand/davinci: Fix comment to match the code
Message-ID: <1282738700-30966-1-git-send-email-w.sang@pengutronix.de>

Signed-off-by: Wolfram Sang <w.sang at pengutronix.de>
Cc: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
Cc: Sneha Narnakaje <nsnehaprabha at ti.com>
Cc: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
---

Found while debugging a NAND issue with a dm365.

 drivers/mtd/nand/davinci_nand.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 2ac7367..53f864a 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -369,8 +369,9 @@ compare:
 	 * after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
 	 * begin trying to poll for the state, you may fall right out of your
 	 * loop without any of the correction calculations having taken place.
-	 * The recommendation from the hardware team is to wait till ECC_STATE
-	 * reads less than 4, which means ECC HW has entered correction state.
+	 * The recommendation from the hardware team is to initially delay as
+	 * long as ECC_STATE reads less than 4. After that, ECC HW has entered
+	 * correction state.
 	 */
 	do {
 		ecc_state = (davinci_nand_readl(info,
-- 
1.7.1


From Priya_Raghavendra at mindtree.com  Tue Aug 17 06:06:15 2010
From: Priya_Raghavendra at mindtree.com (Priya Raghavendra)
Date: Tue, 17 Aug 2010 11:06:15 -0000
Subject: Reduced drive operation for the DDR2 SDRAM device
Message-ID: <1B3CA99331DE5E47BB89385002F8D1EF1143744FD3@MTW02MSG02.mindtree.com>

Hi,

On our embedded board we have a TI DM6467 processor connected to a DDR2 SDRAM.
We have configured the DM6467's DDR2 controller in half-drive mode. We need to configure the DDR2 SDRAM device, Micron MT47H64M16HR-3:H in reduced drive mode. We are told by Micron that the initialization sequence at the Davinci needs to be configured to reprogram the EMR register in the DDR2 SDRAM device.

Refer pages 82-83 of the DDR data sheet. Refer Fig 37.

"The EMR is programmed via the LM command and will retain the stored information until it is programmed again or the device loses power. Reprogramming the EMR will not alter the contents of the memory array, provided it is performed correctly."

[cid:image001.gif at 01CB3E29.EB5134A0]


Can anyone help us program the DDR register using this LM command from the Uboot?

Thanks,
Priya



________________________________
http://www.mindtree.com/email/disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/c499da87/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 29047 bytes
Desc: image001.gif
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100817/c499da87/attachment-0001.gif>

From w.sang at pengutronix.de  Wed Aug 25 08:30:53 2010
From: w.sang at pengutronix.de (Wolfram Sang)
Date: Wed, 25 Aug 2010 13:30:53 -0000
Subject: [RFC] nand/davinci: Fix comment to match the code
In-Reply-To: <1282740906.24044.210.camel@localhost>
References: <1282738700-30966-1-git-send-email-w.sang@pengutronix.de>
	<039d01cb4450$e8f7d6a0$bae783e0$@raj@ti.com>
	<1282740906.24044.210.camel@localhost>
Message-ID: <20100825133045.GB9916@pengutronix.de>

On Wed, Aug 25, 2010 at 03:55:06PM +0300, Artem Bityutskiy wrote:

> then it is already in upstream in Linus' tree. I do not have anything else from you.

I checked linux-next before creating this patch; the comment was the
same as in linus-tree.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100825/fc644010/attachment.bin>

From w.sang at pengutronix.de  Thu Aug 26 01:24:06 2010
From: w.sang at pengutronix.de (Wolfram Sang)
Date: Thu, 26 Aug 2010 06:24:06 -0000
Subject: [RFC] nand/davinci: Fix comment to match the code
In-Reply-To: <045301cb44d3$2551fef0$6ff5fcd0$@raj@ti.com>
References: <1282738700-30966-1-git-send-email-w.sang@pengutronix.de>
	<1282740906.24044.210.camel@localhost>
	<045301cb44d3$2551fef0$6ff5fcd0$@raj@ti.com>
Message-ID: <20100826062357.GA874@pengutronix.de>

Sudhakar,

> > commit 1c3275b656045aff9a75bb2c9f3251af1043ebb3
> > Author: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
> > Date:   Tue Jul 20 15:24:01 2010 -0700
> > 
> >     mtd: nand: davinci: correct 4-bit error correction
> >     
> >     On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
> >     4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
> >     before waiting for the NAND Flash status register to be equal to 1, 2 or
> >     3, we have to wait till the ECC HW goes to correction state.  Without this
> >     wait, ECC correction calculations will not be proper.
> >     
> >     This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
> >     EVMs.
> >     
> >     Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj at ti.com>
> >     Acked-by: Sneha Narnakaje <nsnehaprabha at ti.com>
> >     Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
> >     Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy at nokia.com>
> >     Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>
> > 
> > then it is already in upstream in Linus' tree. I do not have anything else from you.
> > 
> 
> Yes, this was the patch I was talking about. But this patch seems little
> different than the one I submitted to linux-mtd list at
> http://patchwork.ozlabs.org/patch/59180/. But I can submit another patch
> which corrects it. 
> 
> Wolfram Sang,
> Do you agree that in the above link which shows the patch I have submitted,
> the comment matches the code?

Yes. Also, where and how 'timeo' is handled is much better in this patch. If
you create an update patch to make the code look like in the patchwork-link,
you can instantly add my:

Acked-by: Wolfram Sang <w.sang at pengutronix.de>

Thanks,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100826/14f92064/attachment.bin>