From sshtylyov at mvista.com  Tue Feb  1 05:44:03 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 01 Feb 2011 14:44:03 +0300
Subject: [PATCH 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <1296518716-5004-2-git-send-email-michael.williamson@criticallink.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>
	<1296518716-5004-2-git-send-email-michael.williamson@criticallink.com>
Message-ID: <4D47F203.5090502@mvista.com>

Hello.

On 01-02-2011 3:05, Michael Williamson wrote:

> Add SPI registration routines, clocks, and driver resources for
> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.

> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
[...]

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index beda8a4..5f8ff96 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -725,3 +725,91 @@ int __init da8xx_register_cpuidle(void)
>
>   	return platform_device_register(&da8xx_cpuidle_device);
>   }
> +
> +static struct resource da8xx_spi0_resources[] = {
> +	[0] = {
> +		.start = 0x01c41000,
> +		.end   = 0x01c41fff,
> +		.flags = IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start = IRQ_DA8XX_SPINT0,
> +		.start = IRQ_DA8XX_SPINT0,

    You mean '.end'?

> +		.flags = IORESOURCE_IRQ,
> +	},
> +	[2] = {
> +		.start = EDMA_CTLR_CHAN(0, 14),
> +		.end = EDMA_CTLR_CHAN(0, 14),

    Could you align = uniformly with resource 0 -- preferably with a tab?

> +		.flags = IORESOURCE_DMA,
> +	},
> +	[3] = {
> +		.start = EDMA_CTLR_CHAN(0, 15),
> +		.end = EDMA_CTLR_CHAN(0, 15),

    Same here.

> +		.flags = IORESOURCE_DMA,
> +	},
> +	[4] = {
> +		.start = 0,
> +		.end = 0,

    There's no need to init to 0.

> +		.flags = IORESOURCE_DMA,
> +	},
> +};
> +
> +static struct resource da8xx_spi1_resources[] = {
> +	[0] = {
> +		.start = 0x01f0e000,
> +		.end   = 0x01f0efff,
> +		.flags = IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start = IRQ_DA8XX_SPINT1,
> +		.start = IRQ_DA8XX_SPINT1,

    You meand '.end'?

> +		.flags = IORESOURCE_IRQ,
> +	},
> +	[2] = {
> +		.start = EDMA_CTLR_CHAN(0, 18),
> +		.end = EDMA_CTLR_CHAN(0, 18),

    Could you align = uniformly with resource 0 -- preferably with a tab?

> +		.flags = IORESOURCE_DMA,
> +	},
> +	[3] = {
> +		.start = EDMA_CTLR_CHAN(0, 19),
> +		.end = EDMA_CTLR_CHAN(0, 19),

    Same here.

> +		.flags = IORESOURCE_DMA,
> +	},
> +	[4] = {
> +		.start = 0,
> +		.end = 0,

    There's no need to init to 0.

> +		.flags = IORESOURCE_DMA,
> +	},
> +};
> +
> +static struct platform_device da8xx_spi_device[] = {
> +	[0] = {
> +		.name = "spi_davinci",
> +		.id = 0,
> +		.num_resources = ARRAY_SIZE(da8xx_spi0_resources),
> +		.resource = da8xx_spi0_resources,
> +	},
> +	[1] = {
> +		.name = "spi_davinci",
> +		.id = 1,
> +		.num_resources = ARRAY_SIZE(da8xx_spi1_resources),
> +		.resource = da8xx_spi1_resources,
> +	},
> +};
> +
> +int __init da8xx_register_spi(int instance,
> +			      struct davinci_spi_platform_data *pdata)
> +{
> +	struct platform_device *pdev;
> +
> +	if (instance == 0)
> +		pdev =&da8xx_spi_device[0];
> +	else if (instance == 1)
> +		pdev =&da8xx_spi_device[1];

    Why not:

	if (instance == 0 || instance == 1)
		pdev = &da8xx_spi_device[instance];

> +	else
> +		return -EINVAL;
> +
> +	pdev->dev.platform_data = pdata;
> +
> +	return platform_device_register(pdev);
> +}

WBR, Sergei

From sshtylyov at mvista.com  Tue Feb  1 05:54:12 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 01 Feb 2011 14:54:12 +0300
Subject: [PATCH 3/4] davinci: add spi devices support for
	da850/omap-l138/am18x evm
In-Reply-To: <1296518716-5004-4-git-send-email-michael.williamson@criticallink.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>
	<1296518716-5004-4-git-send-email-michael.williamson@criticallink.com>
Message-ID: <4D47F464.4090204@mvista.com>

Hello.

On 01-02-2011 3:05, Michael Williamson wrote:

> From: Sekhar Nori <nsekhar at ti.com>

> This patch adds the on-board SPI flash device to the
> DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
> device to the MTD subsystem.

> Based on SPI flash device support for MityDSP-L138F platform.

> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>

    Why Sekhar hasn't signed off on this patch?

WBR, Sergei

From sshtylyov at mvista.com  Tue Feb  1 06:06:35 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 01 Feb 2011 15:06:35 +0300
Subject: [PATCH 4/4] davinci: add spi devices support for
	da830/omap-l137/am17x evm
In-Reply-To: <1296518716-5004-5-git-send-email-michael.williamson@criticallink.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>
	<1296518716-5004-5-git-send-email-michael.williamson@criticallink.com>
Message-ID: <4D47F74B.9060309@mvista.com>

Hello.

On 01-02-2011 3:05, Michael Williamson wrote:

> From: Sekhar Nori<nsekhar at ti.com>

> This patch adds the on-board SPI flash device to the
> DA830/OMAP-L137/AM17x EVM. It also registers the SPI flash
> device to the MTD subsystem.

> Based on SPI flash device support for MityDSP-L138F platform.

> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>

    Why Sekhar hasn't signed off on this patch?

> diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
> index b52a3a1..15077a0 100644
> --- a/arch/arm/mach-davinci/board-da830-evm.c
> +++ b/arch/arm/mach-davinci/board-da830-evm.c
[...]
> @@ -534,6 +537,83 @@ static struct edma_rsv_info da830_edma_rsv[] = {
>   	},
>   };
>
> +static struct davinci_spi_platform_data da830evm_spi0_pdata = {
> +	.version	= SPI_VERSION_2,
> +	.num_chipselect = 1,
> +	.intr_line      = 1,
> +};
> +
> +static struct mtd_partition da830evm_spiflash_part[] = {
> +	[0] = {
> +		.name = "DSP-UBL",
> +		.offset = 0,
> +		.size = SZ_8K,
> +		.mask_flags = MTD_WRITEABLE,
> +	},
> +	[1] = {
> +		.name = "ARM-UBL",
> +		.offset = MTDPART_OFS_APPEND,
> +		.size = SZ_16K + SZ_8K,
> +		.mask_flags = MTD_WRITEABLE,
> +	},
> +	[2] = {
> +		.name = "U-Boot",
> +		.offset = MTDPART_OFS_APPEND,
> +		.size = SZ_256K - SZ_32K,
> +		.mask_flags = MTD_WRITEABLE,
> +	},
> +	[3] = {
> +		.name = "U-Boot-Environment",
> +		.offset = MTDPART_OFS_APPEND,
> +		.size = SZ_16K,
> +		.mask_flags = 0,
> +	},
> +	[4] = {
> +		.name = "Kernel",
> +		.offset = MTDPART_OFS_APPEND,
> +		.size = MTDPART_SIZ_FULL,
> +		.mask_flags = 0,

    There's no need to explicitly init to 0.

WBR, Sergei

From nsekhar at ti.com  Tue Feb  1 06:11:37 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 1 Feb 2011 17:41:37 +0530
Subject: [PATCH 4/4] davinci: add spi devices support for
	da830/omap-l137/am17x evm
In-Reply-To: <4D47F74B.9060309@mvista.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>
	<1296518716-5004-5-git-send-email-michael.williamson@criticallink.com>
	<4D47F74B.9060309@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930248777A33@dbde02.ent.ti.com>

On Tue, Feb 01, 2011 at 17:36:35, Sergei Shtylyov wrote:
> Hello.
> 
> On 01-02-2011 3:05, Michael Williamson wrote:
> 
> > From: Sekhar Nori<nsekhar at ti.com>
> 
> > This patch adds the on-board SPI flash device to the
> > DA830/OMAP-L137/AM17x EVM. It also registers the SPI flash
> > device to the MTD subsystem.
> 
> > Based on SPI flash device support for MityDSP-L138F platform.
> 
> > Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
> 
>     Why Sekhar hasn't signed off on this patch?

I should have.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From nsekhar at ti.com  Tue Feb  1 06:21:58 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 1 Feb 2011 17:51:58 +0530
Subject: [PATCH 2/4] davinci: add spi devices support for
	MityDSP-L138/MityARM-1808 platform
In-Reply-To: <1296518716-5004-3-git-send-email-michael.williamson@criticallink.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>
	<1296518716-5004-3-git-send-email-michael.williamson@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930248777A4B@dbde02.ent.ti.com>

Hi Mike,

On Tue, Feb 01, 2011 at 05:35:14, Michael Williamson wrote:
> This patch adds support for accessing the on board SPI NOR FLASH
> device for MityDSP-L138 and MityARM-1808 SoMs.
> 
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
> Tested-by: Michael Williamson <michael.williamson at criticallink.com>
> ---
>  arch/arm/mach-davinci/board-mityomapl138.c |  104 ++++++++++++++++++++++++++++
>  1 files changed, 104 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c


> +
> +static struct davinci_spi_platform_data mityomapl138_spi1_pdata = {
> +	.version	= SPI_VERSION_2,
> +	.num_chipselect	= 1,
> +	.intr_line	= 1,
> +};

This platform data is better placed in devices-da8xx.c as most of
it is common across all DA8xx platforms. Only num_chipselect and
chip_sel array are expected to be board specific so only those should
be passed on from board files.

Thanks,
Sekhar

From michael.williamson at criticallink.com  Tue Feb  1 06:26:51 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 01 Feb 2011 07:26:51 -0500
Subject: [PATCH 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D47F203.5090502@mvista.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>
	<1296518716-5004-2-git-send-email-michael.williamson@criticallink.com>
	<4D47F203.5090502@mvista.com>
Message-ID: <4D47FC0B.80608@criticallink.com>

Hi Sergei,

On 2/1/2011 6:44 AM, Sergei Shtylyov wrote:

> Hello.
> 
> On 01-02-2011 3:05, Michael Williamson wrote:
> 
>> Add SPI registration routines, clocks, and driver resources for
>> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.
> 
>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>> index beda8a4..5f8ff96 100644
>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>> @@ -725,3 +725,91 @@ int __init da8xx_register_cpuidle(void)
>>
>>       return platform_device_register(&da8xx_cpuidle_device);
>>   }
>> +
>> +static struct resource da8xx_spi0_resources[] = {
>> +    [0] = {
>> +        .start = 0x01c41000,
>> +        .end   = 0x01c41fff,
>> +        .flags = IORESOURCE_MEM,
>> +    },
>> +    [1] = {
>> +        .start = IRQ_DA8XX_SPINT0,
>> +        .start = IRQ_DA8XX_SPINT0,
> 
>    You mean '.end'?
> 


Yes.  I will correct.

>> +        .flags = IORESOURCE_IRQ,
>> +    },
>> +    [2] = {
>> +        .start = EDMA_CTLR_CHAN(0, 14),
>> +        .end = EDMA_CTLR_CHAN(0, 14),
> 
>    Could you align = uniformly with resource 0 -- preferably with a tab?
> 


Sure.

>> +        .flags = IORESOURCE_DMA,
>> +    },
>> +    [3] = {
>> +        .start = EDMA_CTLR_CHAN(0, 15),
>> +        .end = EDMA_CTLR_CHAN(0, 15),
> 
>    Same here.
> 
>> +        .flags = IORESOURCE_DMA,
>> +    },
>> +    [4] = {
>> +        .start = 0,
>> +        .end = 0,
> 
>    There's no need to init to 0.
> 


OK.

>> +        .flags = IORESOURCE_DMA,
>> +    },
>> +};
>> +
>> +static struct resource da8xx_spi1_resources[] = {
>> +    [0] = {
>> +        .start = 0x01f0e000,
>> +        .end   = 0x01f0efff,
>> +        .flags = IORESOURCE_MEM,
>> +    },
>> +    [1] = {
>> +        .start = IRQ_DA8XX_SPINT1,
>> +        .start = IRQ_DA8XX_SPINT1,
> 
>    You meand '.end'?
> 


I did, but I see that .end is not used by platform_get_irq(), only .start.
[wondering why testing didn't catch this, and why no compiler warnings on
 double assignment].  I will correct. Thanks.

>> +        .flags = IORESOURCE_IRQ,
>> +    },
>> +    [2] = {
>> +        .start = EDMA_CTLR_CHAN(0, 18),
>> +        .end = EDMA_CTLR_CHAN(0, 18),
> 
>    Could you align = uniformly with resource 0 -- preferably with a tab?
> 


Sure.

>> +        .flags = IORESOURCE_DMA,
>> +    },
>> +    [3] = {
>> +        .start = EDMA_CTLR_CHAN(0, 19),
>> +        .end = EDMA_CTLR_CHAN(0, 19),
> 
>    Same here.
> 


Got it.

>> +        .flags = IORESOURCE_DMA,
>> +    },
>> +    [4] = {
>> +        .start = 0,
>> +        .end = 0,
> 
>    There's no need to init to 0.
> 


OK.

>> +        .flags = IORESOURCE_DMA,
>> +    },
>> +};
>> +
>> +static struct platform_device da8xx_spi_device[] = {
>> +    [0] = {
>> +        .name = "spi_davinci",
>> +        .id = 0,
>> +        .num_resources = ARRAY_SIZE(da8xx_spi0_resources),
>> +        .resource = da8xx_spi0_resources,
>> +    },
>> +    [1] = {
>> +        .name = "spi_davinci",
>> +        .id = 1,
>> +        .num_resources = ARRAY_SIZE(da8xx_spi1_resources),
>> +        .resource = da8xx_spi1_resources,
>> +    },
>> +};
>> +
>> +int __init da8xx_register_spi(int instance,
>> +                  struct davinci_spi_platform_data *pdata)
>> +{
>> +    struct platform_device *pdev;
>> +
>> +    if (instance == 0)
>> +        pdev =&da8xx_spi_device[0];
>> +    else if (instance == 1)
>> +        pdev =&da8xx_spi_device[1];
> 
>    Why not:
> 
>     if (instance == 0 || instance == 1)
>         pdev = &da8xx_spi_device[instance];
> 


OK.

>> +    else
>> +        return -EINVAL;
>> +
>> +    pdev->dev.platform_data = pdata;
>> +
>> +    return platform_device_register(pdev);
>> +}
> 
> WBR, Sergei


Thanks for the review Sergei.

-Mike

From michael.williamson at criticallink.com  Tue Feb  1 06:33:08 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 01 Feb 2011 07:33:08 -0500
Subject: [PATCH 2/4] davinci: add spi devices support for
	MityDSP-L138/MityARM-1808 platform
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248777A4B@dbde02.ent.ti.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>
	<1296518716-5004-3-git-send-email-michael.williamson@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248777A4B@dbde02.ent.ti.com>
Message-ID: <4D47FD84.4040302@criticallink.com>

Hi Sekhar,

On 2/1/2011 7:21 AM, Nori, Sekhar wrote:

> Hi Mike,
> 
> On Tue, Feb 01, 2011 at 05:35:14, Michael Williamson wrote:
>> This patch adds support for accessing the on board SPI NOR FLASH
>> device for MityDSP-L138 and MityARM-1808 SoMs.
>>
>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>> Tested-by: Michael Williamson <michael.williamson at criticallink.com>
>> ---
>>  arch/arm/mach-davinci/board-mityomapl138.c |  104 ++++++++++++++++++++++++++++
>>  1 files changed, 104 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> 
> 
>> +
>> +static struct davinci_spi_platform_data mityomapl138_spi1_pdata = {
>> +	.version	= SPI_VERSION_2,
>> +	.num_chipselect	= 1,
>> +	.intr_line	= 1,
>> +};
> 
> This platform data is better placed in devices-da8xx.c as most of
> it is common across all DA8xx platforms. Only num_chipselect and
> chip_sel array are expected to be board specific so only those should
> be passed on from board files.
> 
> Thanks,
> Sekhar


I will move this to devices-da8xx.c and create a placeholder for spi0.

Thanks.

-Mike

From michael.williamson at criticallink.com  Tue Feb  1 06:43:13 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 01 Feb 2011 07:43:13 -0500
Subject: [PATCH 4/4] davinci: add spi devices support for
	da830/omap-l137/am17x evm
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248777A33@dbde02.ent.ti.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>	<1296518716-5004-5-git-send-email-michael.williamson@criticallink.com>
	<4D47F74B.9060309@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248777A33@dbde02.ent.ti.com>
Message-ID: <4D47FFE1.6040901@criticallink.com>

Hi Sekhar,

On 2/1/2011 7:11 AM, Nori, Sekhar wrote:

> On Tue, Feb 01, 2011 at 17:36:35, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 01-02-2011 3:05, Michael Williamson wrote:
>>
>>> From: Sekhar Nori<nsekhar at ti.com>
>>
>>> This patch adds the on-board SPI flash device to the
>>> DA830/OMAP-L137/AM17x EVM. It also registers the SPI flash
>>> device to the MTD subsystem.
>>
>>> Based on SPI flash device support for MityDSP-L138F platform.
>>
>>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
>>
>>     Why Sekhar hasn't signed off on this patch?
> 
> I should have.
> 
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> 
> Thanks,
> Sekhar
> 


I need to move the da830evm_spi0_pdata structure into the common devices-da8xx.c
based on your other comment to part 2/4 of this series.  

For my clarification on patch submission, do I need to change the authorship if
I touch it in anyway?  Or should I leave you the author (given you ack the mods, 
and confirm your sign-off)?

Thanks.

-Mike

From nsekhar at ti.com  Tue Feb  1 07:01:16 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 1 Feb 2011 18:31:16 +0530
Subject: [PATCH 4/4] davinci: add spi devices support for
	da830/omap-l137/am17x evm
In-Reply-To: <4D47FFE1.6040901@criticallink.com>
References: <1296518716-5004-1-git-send-email-michael.williamson@criticallink.com>
	<1296518716-5004-5-git-send-email-michael.williamson@criticallink.com>
	<4D47F74B.9060309@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248777A33@dbde02.ent.ti.com>
	<4D47FFE1.6040901@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930248777A8F@dbde02.ent.ti.com>

On Tue, Feb 01, 2011 at 18:13:13, Michael Williamson wrote:

> I need to move the da830evm_spi0_pdata structure into the common devices-da8xx.c
> based on your other comment to part 2/4 of this series.  
> 
> For my clarification on patch submission, do I need to change the authorship if
> I touch it in anyway?  Or should I leave you the author (given you ack the mods, 
> and confirm your sign-off)?

If you do not end up modifying the patch heavily, you can keep me
as the author.

In this case, the change you have done can be noted in between the
sign-offs. Thus:

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da830evm_spi0_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>

Thanks,
Sekhar


From stathis.voukelatos at aircraftmedical.com  Tue Feb  1 07:23:58 2011
From: stathis.voukelatos at aircraftmedical.com (Stathis Voukelatos)
Date: Tue, 1 Feb 2011 13:23:58 -0000
Subject: USB WiFi issue on DM365 EVM
Message-ID: <FED2876F225E224ABC04332199761C59D3394A@larry.aircraftmedical.com>

Hi all,

 

I am trying to get a WiFi dongle working with the DM365 EVM. The dongle
has the 

Zydas ZD1211B chipset. I am using kernel version 2.6.32-rc2, the one
included in

the DVSDK 4.00.00.22.

When I plug in the dongle at the USB port of the board I occasionally
get the following 

error and the interface does not come up.

 

usb 1-1: new high speed USB device using musb_hdrc and address 8

usb 1-1: New USB device found, idVendor=0ace, idProduct=1215

usb 1-1: New USB device strings: Mfr=16, Product=32, SerialNumber=0

usb 1-1: Product: USB2.0 WLAN

usb 1-1: Manufacturer: ZyDAS

usb 1-1: configuration #1 chosen from 1 choice

usb 1-1: print_id() 0ace:1215 v4810 high

usb 1-1: reset high speed USB device using musb_hdrc and address 8

zd1211rw 1-1:1.0: zd_chip_read_mac_addr_fw() 

phy6: Selected rate control algorithm 'minstrel'

zd1211rw 1-1:1.0: probe() successful

zd1211rw 1-1:1.0: phy6

zd1211rw 1-1:1.0: zd_usb_init_hw() 

usb 1-1: request_fw_file() fw name zd1211/zd1211b_ub

usb 1-1: firmware: requesting zd1211/zd1211b_ub

usb 1-1: upload_firmware() firmware device id 0x4810 is equal to the
actual device id

usb 1-1: request_fw_file() fw name zd1211/zd1211b_uphr

usb 1-1: firmware: requesting zd1211/zd1211b_uphr

usb 1-1: upload_code() transfer size 4018

usb 1-1: upload_code() firmware confirm return value 0x01

zd1211rw 1-1:1.0: zd_usb_init_hw() couldn't reset configuration. Error
number -110

 

The error 110 stands for ETIMEDOUT and it is intermittent, ie if I
unplug and plug the USB 

dongle a few times it will eventually work. Any ideas where the problem
may be?

 

Cheers,

Stathis

 

 

Stathis Voukelatos

Firmware Engineer

Aircraft Medical Ltd

12 Ridge Way

Donibristle Industrial Park

Hillend, Dunfermline

KY11 9JN, UK

Tel:  +44 (0)1383 824326

Fax: +44 (0)1383 660328

email: stathis.voukelatos at aircraftmedical.com
<mailto:stathis.voukelatos at aircraftmedical.com> 

 

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

From khilman at ti.com  Tue Feb  1 14:53:42 2011
From: khilman at ti.com (Kevin Hilman)
Date: Tue, 01 Feb 2011 12:53:42 -0800
Subject: [PATCH 1/2 v1] davinci: support disabling modem status interrupts
	on SOC UARTS
In-Reply-To: <4D44803E.8000703@criticallink.com> (Michael Williamson's message
	of "Sat, 29 Jan 2011 16:01:50 -0500")
References: <1294230392-29564-1-git-send-email-michael.williamson@criticallink.com>
	<4D44803E.8000703@criticallink.com>
Message-ID: <871v3rwk6h.fsf@ti.com>

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

> Hi Kevin...
>
> On 01/05/2011 07:26 AM, Michael Williamson wrote:
>> On the da850/omap-l138/am18x family of SoCs, up to three on chip UARTS may be
>> configured.  These peripherals support the standard Tx/Rx signals as well as
>> CTS/RTS hardware flow control signals.  The pins on these SOC's associated with
>> these signals are multiplexed; e.g., the pin providing UART0_TXD capability
>> also provides SPI0 chip select line 5 output capability.  The configuration of
>> the pin multiplexing occurs during platform initialization (or by earlier
>> bootloader operations).
>> 
>> There is a problem with the multiplexing implementation on these SOCs.  Only
>> the output and output enable portions of the I/O section of the pin are
>> multiplexed.  All peripheral input functions remain connected to a given pin
>> regardless of configuration.
>> 
>> In many configurations of these parts, providing a UART with Tx/Rx capability
>> is needed, but the HW flow control capability is not.  Furthermore, the pins
>> associated with the CTS inputs on these UARTS are often configured to support
>> a different peripheral, and they may be active/toggling during runtime.  This
>> can result in false modem status (CTS) interrupts being asserted to the 8250
>> driver controlling the associated Tx/Rx pins, and will impact system
>> performance.
>> 
>> The 8250 serial driver platform data does not provide a direct mechanism to
>> tell the driver to disable modem status (i.e., CTS) interrupts for a given
>> port.  As a work-around, intercept register writes to the IER and disable
>> modem status interrupts.
>> 
>> This patch was tested using a MityDSP-L138 SOM having UART1 enabled with the
>> associated CTS pin connected to a clock (configured for the AHCLKX function).
>> 
>> Background / problem reports related to this issue are captured in the links
>> below:
>> http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/36701.aspx
>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg19524.html
>> 
>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>> Tested-by: Michael Williamson <michael.williamson at criticallink.com>
>> ---
>> This is against the linux-davinci tree.
>> 
>> Changes from original proposed patch:
>> - instead of overriding set_termios, now override serial_out driver hook
>>   and intercept writes to the MSR.
>> 
>> An alternate patch was proposed that modified the serial core driver and added a UPF_NO_MSR
>> flag.  There was resistance to this patch.  The reasoning is that the core 8250 driver code
>> should not continue to get muddied by platform hacks.
>> 
>
> I'd like to withdraw this patch.  It works, but it's inefficient and ugly, and 
> I also get the feeling it isn't going to make it in it's current form anyway.
>
> I have another patch that is limited to just the mityomapl138 platform that 
> I would like to submit in place of this.  No other board appears to have this
> problem, so it makes sense to constrain the fix to platform file that does.
>

OK

Kevin

From michael.williamson at criticallink.com  Tue Feb  1 15:49:35 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue,  1 Feb 2011 16:49:35 -0500
Subject: [PATCH v1 0/4] davinci: Add SPI support for da8xx platforms
Message-ID: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>

This patch series adds the necessary SPI resources and registration
routines for da850/OMAP-L138/AM18x and da830/OMAP-L137/AM17x devices.
It also adds on-board SPI FLASH devices for the da830 evm, the da850
evm, and the MityDSP-L138/MityARM-1808 platforms.

These patches are based on work done during testing of davinci SPI driver 
submissions incorporated in version 2.6.38 of the kernel, at [1].

The da850 and da830 EVM portions of this patch need verification / ack.

The MityDSP-L138 platform patch has been tested.

The patch series is against commit 8fb837c158e342413d08d6f211b5b8f67d5adc2f
of kevin's tree.

[1] http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

---
Changes since v0:
   - fixed up issues in device stuctures pointed out by Sergei
   - moved spi platform data structures to common array in devices-da8xx.c
   - Added sign-off information for Sekhar's patches per comments.

Michael Williamson (2):
  davinci: da8xx/omap-l1: add support for SPI
  davinci: add spi devices support for MityDSP-L138/MityARM-1808
    platform

Sekhar Nori (2):
  davinci: add spi devices support for da850/omap-l138/am18x evm
  davinci: add spi devices support for da830/omap-l137/am17x evm

 arch/arm/mach-davinci/board-da830-evm.c    |   78 ++++++++++++++++++++++
 arch/arm/mach-davinci/board-da850-evm.c    |   84 +++++++++++++++++++++++
 arch/arm/mach-davinci/board-mityomapl138.c |  100 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/da850.c              |   16 +++++
 arch/arm/mach-davinci/devices-da8xx.c      |   96 ++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 6 files changed, 377 insertions(+), 0 deletions(-)


From michael.williamson at criticallink.com  Tue Feb  1 15:49:36 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue,  1 Feb 2011 16:49:36 -0500
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>

Add SPI registration routines, clocks, and driver resources for
DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/da850.c              |   16 +++++
 arch/arm/mach-davinci/devices-da8xx.c      |   96 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 3 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..68fe4c2 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -359,6 +359,20 @@ static struct clk usb20_clk = {
 	.gpsc		= 1,
 };
 
+static struct clk spi0_clk = {
+	.name		= "spi0",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_SPI0,
+};
+
+static struct clk spi1_clk = {
+	.name		= "spi1",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_SPI1,
+	.gpsc		= 1,
+	.flags		= DA850_CLK_ASYNC3,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -403,6 +417,8 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"aemif",	&aemif_clk),
 	CLK(NULL,		"usb11",	&usb11_clk),
 	CLK(NULL,		"usb20",	&usb20_clk),
+	CLK("spi_davinci.0",	NULL,		&spi0_clk),
+	CLK("spi_davinci.1",	NULL,		&spi1_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..f421f97 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+
+static struct resource da8xx_spi0_resources[] = {
+	[0] = {
+		.start	= 0x01c41000,
+		.end	= 0x01c41fff,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_DA8XX_SPINT0,
+		.end	= IRQ_DA8XX_SPINT0,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		.start	= EDMA_CTLR_CHAN(0, 14),
+		.end	= EDMA_CTLR_CHAN(0, 14),
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		.start	= EDMA_CTLR_CHAN(0, 15),
+		.end	= EDMA_CTLR_CHAN(0, 15),
+		.flags	= IORESOURCE_DMA,
+	},
+	[4] = {
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+static struct resource da8xx_spi1_resources[] = {
+	[0] = {
+		.start	= 0x01f0e000,
+		.end	= 0x01f0efff,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_DA8XX_SPINT1,
+		.end	= IRQ_DA8XX_SPINT1,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		.start	= EDMA_CTLR_CHAN(0, 18),
+		.end	= EDMA_CTLR_CHAN(0, 18),
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		.start	= EDMA_CTLR_CHAN(0, 19),
+		.end	= EDMA_CTLR_CHAN(0, 19),
+		.flags	= IORESOURCE_DMA,
+	},
+	[4] = {
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+struct davinci_spi_platform_data da8xx_spi_pdata[] = {
+	[0] = {
+		.version	= SPI_VERSION_2,
+		.intr_line	= 1,
+	},
+	[1] = {
+		.version	= SPI_VERSION_2,
+		.intr_line	= 1,
+	},
+};
+
+static struct platform_device da8xx_spi_device[] = {
+	[0] = {
+		.name		= "spi_davinci",
+		.id		= 0,
+		.num_resources	= ARRAY_SIZE(da8xx_spi0_resources),
+		.resource	= da8xx_spi0_resources,
+		.dev		= {
+			.platform_data = &da8xx_spi_pdata[0],
+		},
+	},
+	[1] = {
+		.name		= "spi_davinci",
+		.id		= 1,
+		.num_resources	= ARRAY_SIZE(da8xx_spi1_resources),
+		.resource	= da8xx_spi1_resources,
+		.dev		= {
+			.platform_data = &da8xx_spi_pdata[1],
+		},
+	},
+};
+
+int __init da8xx_register_spi(int instance)
+{
+	struct platform_device *pdev;
+
+	if (instance == 0 || instance == 1)
+		pdev = &da8xx_spi_device[instance];
+	else
+		return -EINVAL;
+
+	return platform_device_register(pdev);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..0c5fa01 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -23,6 +23,7 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 #include <mach/pm.h>
+#include <mach/spi.h>
 
 extern void __iomem *da8xx_syscfg0_base;
 extern void __iomem *da8xx_syscfg1_base;
@@ -77,6 +78,7 @@ void __init da850_init(void);
 int da830_register_edma(struct edma_rsv_info *rsv);
 int da850_register_edma(struct edma_rsv_info *rsv[2]);
 int da8xx_register_i2c(int instance, struct davinci_i2c_platform_data *pdata);
+int da8xx_register_spi(int instance);
 int da8xx_register_watchdog(void);
 int da8xx_register_usb20(unsigned mA, unsigned potpgt);
 int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
@@ -95,6 +97,7 @@ extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
+extern struct davinci_spi_platform_data da8xx_spi_pdata[];
 
 extern struct platform_device da8xx_wdt_device;
 
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb  1 15:49:37 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue,  1 Feb 2011 16:49:37 -0500
Subject: [PATCH v1 2/4] davinci: add spi devices support for
	MityDSP-L138/MityARM-1808 platform
In-Reply-To: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1296596979-18524-3-git-send-email-michael.williamson@criticallink.com>

This patch adds support for accessing the on board SPI NOR FLASH
device for MityDSP-L138 and MityARM-1808 SoMs.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Tested-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-mityomapl138.c |  100 ++++++++++++++++++++++++++++
 1 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 0ea5932..dc4c3f1 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -17,6 +17,8 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/etherdevice.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -25,6 +27,7 @@
 #include <mach/da8xx.h>
 #include <mach/nand.h>
 #include <mach/mux.h>
+#include <mach/spi.h>
 
 #define MITYOMAPL138_PHY_ID		"0:03"
 
@@ -294,6 +297,100 @@ static int __init pmic_tps65023_init(void)
 }
 
 /*
+ * SPI Devices:
+ *	SPI1_CS0: 8M Flash ST-M25P64-VME6G
+ */
+static struct mtd_partition spi_flash_partitions[] = {
+	[0] = {
+		.name		= "ubl",
+		.offset		= 0,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[1] = {
+		.name		= "u-boot",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_512K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[2] = {
+		.name		= "u-boot-env",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[3] = {
+		.name		= "periph-config",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[4] = {
+		.name		= "reserved",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_256K + SZ_64K,
+	},
+	[5] = {
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M + SZ_1M,
+	},
+	[6] = {
+		.name		= "fpga",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M,
+	},
+	[7] = {
+		.name		= "spare",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+	},
+};
+
+static struct flash_platform_data mityomapl138_spi_flash_data = {
+	.name		= "m25p80",
+	.parts		= spi_flash_partitions,
+	.nr_parts	= ARRAY_SIZE(spi_flash_partitions),
+	.type		= "m24p64",
+};
+
+static struct davinci_spi_config spi_eprom_config = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info mityomapl138_spi_flash_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &mityomapl138_spi_flash_data,
+		.controller_data	= &spi_eprom_config,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 1,
+		.chip_select		= 0,
+	},
+};
+
+static void __init mityomapl138_init_spi1(struct spi_board_info *info,
+					  unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("%s: failed to register board info : %d\n",
+				__func__, ret);
+
+	da8xx_spi_pdata[1].num_chipselect = len;
+
+	ret = da8xx_register_spi(1);
+	if (ret)
+		pr_warning("%s: failed to register spi 1 device : %d\n",
+				__func__, ret);
+}
+
+/*
  * MityDSP-L138 includes a 256 MByte large-page NAND flash
  * (128K blocks).
  */
@@ -448,6 +545,9 @@ static void __init mityomapl138_init(void)
 
 	mityomapl138_setup_nand();
 
+	mityomapl138_init_spi1(mityomapl138_spi_flash_info,
+			       ARRAY_SIZE(mityomapl138_spi_flash_info));
+
 	mityomapl138_config_emac();
 
 	ret = da8xx_register_rtc();
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb  1 15:49:38 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue,  1 Feb 2011 16:49:38 -0500
Subject: [PATCH v1 3/4] davinci: add spi devices support for
	da850/omap-l138/am18x evm
In-Reply-To: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1296596979-18524-4-git-send-email-michael.williamson@criticallink.com>

From: Sekhar Nori <nsekhar at ti.com>

This patch adds the on-board SPI flash device to the
DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
device to the MTD subsystem.

Based on SPI flash device support for MityDSP-L138F platform.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da850_evm_spi1_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   84 +++++++++++++++++++++++++++++++
 1 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..487bd3a 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,8 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/tps6507x.h>
 #include <linux/input/tps6507x-ts.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -38,6 +40,7 @@
 #include <mach/nand.h>
 #include <mach/mux.h>
 #include <mach/aemif.h>
+#include <mach/spi.h>
 
 #define DA850_EVM_PHY_ID		"0:00"
 #define DA850_LCD_PWR_PIN		GPIO_TO_PIN(2, 8)
@@ -48,6 +51,85 @@
 
 #define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
 
+static struct mtd_partition da850evm_spiflash_part[] = {
+	[0] = {
+		.name = "UBL",
+		.offset = 0,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[1] = {
+		.name = "U-Boot",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_512K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[2] = {
+		.name = "U-Boot-Env",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[3] = {
+		.name = "Kernel",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_2M + SZ_512K,
+		.mask_flags = 0,
+	},
+	[4] = {
+		.name = "Filesystem",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_4M,
+		.mask_flags = 0,
+	},
+	[5] = {
+		.name = "MAC-Address",
+		.offset = SZ_8M - SZ_64K,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+};
+
+static struct flash_platform_data da850evm_spiflash_data = {
+	.name		= "m25p80",
+	.parts		= da850evm_spiflash_part,
+	.nr_parts	= ARRAY_SIZE(da850evm_spiflash_part),
+	.type		= "m25p64",
+};
+
+static struct davinci_spi_config da850evm_spiflash_cfg = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info da850evm_spi_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &da850evm_spiflash_data,
+		.controller_data	= &da850evm_spiflash_cfg,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 1,
+		.chip_select		= 0,
+	},
+};
+
+static void __init da850evm_init_spi1(struct spi_board_info *info, unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("failed to register board info : %d\n", ret);
+
+	da8xx_spi_pdata[1].num_chipselect = len;
+
+	ret = da8xx_register_spi(1);
+	if (ret)
+		pr_warning("failed to register spi 1 device : %d\n", ret);
+}
+
 static struct mtd_partition da850_evm_norflash_partition[] = {
 	{
 		.name           = "bootloaders + env",
@@ -1167,6 +1249,8 @@ static __init void da850_evm_init(void)
 	if (ret)
 		pr_warning("da850_evm_init: suspend registration failed: %d\n",
 				ret);
+
+	da850evm_init_spi1(da850evm_spi_info, ARRAY_SIZE(da850evm_spi_info));
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb  1 15:49:39 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue,  1 Feb 2011 16:49:39 -0500
Subject: [PATCH v1 4/4] davinci: add spi devices support for
	da830/omap-l137/am17x evm
In-Reply-To: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1296596979-18524-5-git-send-email-michael.williamson@criticallink.com>

From: Sekhar Nori <nsekhar at ti.com>

This patch adds the on-board SPI flash device to the
DA830/OMAP-L137/AM17x EVM. It also registers the SPI flash
device to the MTD subsystem.

Based on SPI flash device support for MityDSP-L138F platform.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da830evm_spi0_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-da830-evm.c |   78 +++++++++++++++++++++++++++++++
 1 files changed, 78 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index b52a3a1..01319bd 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -20,6 +20,8 @@
 #include <linux/i2c/at24.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -30,6 +32,7 @@
 #include <mach/da8xx.h>
 #include <mach/usb.h>
 #include <mach/aemif.h>
+#include <mach/spi.h>
 
 #define DA830_EVM_PHY_ID		""
 /*
@@ -534,6 +537,79 @@ static struct edma_rsv_info da830_edma_rsv[] = {
 	},
 };
 
+static struct mtd_partition da830evm_spiflash_part[] = {
+	[0] = {
+		.name = "DSP-UBL",
+		.offset = 0,
+		.size = SZ_8K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[1] = {
+		.name = "ARM-UBL",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_16K + SZ_8K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[2] = {
+		.name = "U-Boot",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_256K - SZ_32K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[3] = {
+		.name = "U-Boot-Environment",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_16K,
+		.mask_flags = 0,
+	},
+	[4] = {
+		.name = "Kernel",
+		.offset = MTDPART_OFS_APPEND,
+		.size = MTDPART_SIZ_FULL,
+		.mask_flags = 0,
+	},
+};
+
+static struct flash_platform_data da830evm_spiflash_data = {
+	.name		= "m25p80",
+	.parts		= da830evm_spiflash_part,
+	.nr_parts	= ARRAY_SIZE(da830evm_spiflash_part),
+	.type		= "w25x32",
+};
+
+static struct davinci_spi_config da830evm_spiflash_cfg = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info da830evm_spi_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &da830evm_spiflash_data,
+		.controller_data	= &da830evm_spiflash_cfg,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 0,
+		.chip_select		= 0,
+	},
+};
+
+static void __init da830evm_init_spi0(struct spi_board_info *info, unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("failed to register board info : %d\n", ret);
+
+	da8xx_spi_pdata[0].num_chipselect = len;
+
+	ret = da8xx_register_spi(0);
+	if (ret)
+		pr_warning("failed to register spi 0 device : %d\n", ret);
+}
+
 static __init void da830_evm_init(void)
 {
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -590,6 +666,8 @@ static __init void da830_evm_init(void)
 	ret = da8xx_register_rtc();
 	if (ret)
 		pr_warning("da830_evm_init: rtc setup failed: %d\n", ret);
+
+	da830evm_init_spi0(da830evm_spi_info, ARRAY_SIZE(da830evm_spi_info));
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.0.4


From sshtylyov at mvista.com  Wed Feb  2 05:49:26 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 14:49:26 +0300
Subject: [PATCH v1 2/9] da850: pruss board specific additions.
In-Reply-To: <1296571667-12049-3-git-send-email-subhasish@mistralsolutions.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<1296571667-12049-3-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D4944C6.5060406@mvista.com>

Hello.

On 01-02-2011 17:47, Subhasish Ghosh wrote:

> This patch adds board specific initializations and setup routines.

> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
[...]

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 11f986b..7938c6d 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1053,6 +1053,29 @@ static __init int da850_evm_init_cpufreq(void)
>   static __init int da850_evm_init_cpufreq(void) { return 0; }
>   #endif
>
> +static struct da8xx_pruss_devices pruss_devices[] = {
> +	{.dev_name = NULL,},
> +};
> +
> +static int __init da8xx_evm_setup_pruss(void)

    Only da850_evm_setup_pruss() -- we're in the DA850 EVM support file.

> +{
> +	u32 ret = 0;
> +	u32 count;
> +
> +	for (count = 0; count < ARRAY_SIZE(pruss_devices); count++) {
> +		if (pruss_devices[count].setup != NULL) {
> +			ret = pruss_devices[count].setup();
> +			if (ret) {
> +				pr_warning("%s: %s init failed: %d\n", __func__,
> +					pruss_devices[count].dev_name, ret);
> +				return ret;
> +			}
> +		}
> +	}
> +
> +	return da8xx_register_pruss(pruss_devices);
> +}
> +
>   static __init void da850_evm_init(void)
>   {
>   	int ret;
> @@ -1127,6 +1150,11 @@ static __init void da850_evm_init(void)
>
>   	da8xx_register_mcasp(0,&da850_evm_snd_data);
>
> +	ret = da8xx_evm_setup_pruss();
> +	if (ret)
> +		pr_warning("%s: pruss initialization failed: %d\n",
> +				__func__, ret);

    Does it really make sense to print 2 messages for one error?

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 05:55:17 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 14:55:17 +0300
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <1296571667-12049-4-git-send-email-subhasish@mistralsolutions.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<1296571667-12049-4-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D494625.4030503@mvista.com>

Hello.

On 01-02-2011 17:47, Subhasish Ghosh wrote:

> This patch adds the platform device and assignes the platform resources
> for the PRUSS mfd driver.

> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
[...]

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3443d97..341d836 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -238,6 +238,12 @@ static struct clk tptc2_clk = {
>   	.flags		= ALWAYS_ENABLED,
>   };
>
> +static struct clk pruss_clk = {
> +	.name		= "pruss",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC0_DMAX,

    IIRC, you were asked to change/add a new name for what is known as 
DA8XX_LPSC0_DMAX...

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index beda8a4..562882c 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c

> +struct platform_device da8xx_pruss_dev = {
> +	.name			=	"da8xx_pruss",
> +	.id				=	-1,
> +	.num_resources	=	ARRAY_SIZE(da8xx_pruss_resources),
> +	.resource		=	da8xx_pruss_resources,

    Please align = uniformly.

> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index cfcb223..e5c178a 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
[...]
> @@ -81,6 +82,7 @@ int da8xx_register_watchdog(void);
>  int da8xx_register_usb20(unsigned mA, unsigned potpgt);
>  int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
>  int da8xx_register_emac(void);
> +int da8xx_register_pruss(struct da8xx_pruss_devices *);
>  int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
>  int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
>  int da850_register_mmcsd1(struct davinci_mmc_config *config);

    This patch should clearly precede the patch 2/9 as it defines 
da8xx_register_pruss() which 2/9 uses.

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 06:01:34 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 15:01:34 +0300
Subject: [PATCH v1 5/9] da850: pruss CAN board specific additions.
In-Reply-To: <1296571667-12049-6-git-send-email-subhasish@mistralsolutions.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<1296571667-12049-6-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D49479E.3010008@mvista.com>

Hello.

On 01-02-2011 17:47, Subhasish Ghosh wrote:

> This patch adds the pruss CAN pin mux and registers the device
> with the pruss mfd driver.

> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
[...]

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 7938c6d..285545f 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1053,8 +1053,46 @@ static __init int da850_evm_init_cpufreq(void)
>   static __init int da850_evm_init_cpufreq(void) { return 0; }
>   #endif
>
> +const short da850_pruss_can_pins[] = {

    Only da850_evm_pruss_can_pins[].

> +	DA850_PRUSS_PRU0_R31_0, DA850_PRUSS_PRU1_R30_15,
> +	DA850_PRUSS_PRU1_R31_18,
> +	-1
> +};
> +
> +static int __init da850_evm_setup_pruss_can(void)
> +{
> +	int ret, val = 0;
> +	void __iomem *cfg_chip3_base;

    CFGCHIP3 is a signle register, so it doesn't make sense to talk about its 
base...

> +	if (!machine_is_davinci_da850_evm())
> +		return 0;

    This check doesn't make sense as this function is not declared as 
*_initcall(). It will only be called on this machine anyway.

> +	ret = davinci_cfg_reg_list(da850_pruss_can_pins);
> +	if (ret)
> +		pr_warning("%s: da850_pruss_can_pins mux setup "
> +					"failed:%d\n", __func__, ret);
> +	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
> +	val = __raw_readl(cfg_chip3_base);
> +	val |= BIT(3);
> +	__raw_writel(val, cfg_chip3_base);
> +
> +	return ret;
> +}
> +
> +static struct da8xx_pruss_can_data can_data = {
> +	.version	= 1,
> +};
> +
>   static struct da8xx_pruss_devices pruss_devices[] = {
> -	{.dev_name = NULL,},
> +	{
> +		.dev_name	= "da8xx_pruss_can",
> +		.pdata		= &can_data,
> +		.pdata_size	= sizeof(can_data),
> +		.setup		= da850_evm_setup_pruss_can,
> +	},
> +	{
> +		.dev_name	= NULL,
> +	},

    Why you need a dummy lst element in this array?

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 06:03:35 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 15:03:35 +0300
Subject: [PATCH v1 6/9] da850: pruss CAN platform specific additions.
In-Reply-To: <1296571667-12049-7-git-send-email-subhasish@mistralsolutions.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<1296571667-12049-7-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D494817.4030204@mvista.com>

Hello.

On 01-02-2011 17:47, Subhasish Ghosh wrote:

> This patch adds the necessary pins for the pruss CAN.

> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
[...]

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 341d836..11ce7ba 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -565,6 +565,10 @@ static const struct mux_config da850_pins[] = {
>   	MUX_CFG(DA850, EMA_CLK,		6,	0,	15,	1,	false)
>   	MUX_CFG(DA850, EMA_WAIT_1,	6,	24,	15,	1,	false)
>   	MUX_CFG(DA850, NEMA_CS_2,	7,	0,	15,	1,	false)
> +	/* PRU functions for soft CAN */
> +	MUX_CFG(DA850, PRUSS_PRU0_R31_0,	7,	28,	15,	0,	false)
> +	MUX_CFG(DA850, PRUSS_PRU1_R30_15,	12,	0,	15,	4,	false)
> +	MUX_CFG(DA850, PRUSS_PRU1_R31_18,	11,	20,	15,	0,	false)
>   	/* GPIO function */
>   	MUX_CFG(DA850, GPIO2_4,		6,	12,	15,	8,	false)
>   	MUX_CFG(DA850, GPIO2_6,		6,	4,	15,	8,	false)
> diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
> index 5d4e0fe..10f49f2 100644
> --- a/arch/arm/mach-davinci/include/mach/mux.h
> +++ b/arch/arm/mach-davinci/include/mach/mux.h
> @@ -906,6 +906,10 @@ enum davinci_da850_index {
>   	DA850_EMA_CLK,
>   	DA850_EMA_WAIT_1,
>   	DA850_NEMA_CS_2,
> +	/* PRU I/O */
> +	DA850_PRUSS_PRU0_R31_0,
> +	DA850_PRUSS_PRU1_R30_15,
> +	DA850_PRUSS_PRU1_R31_18,

    Again, this patch should precede the patch 5/9 due to PinMux dependencies. 
I thought it must be pretty clear...

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 06:05:09 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 15:05:09 +0300
Subject: [PATCH v1 7/9] mfd: pruss CAN private data.
In-Reply-To: <1296571667-12049-8-git-send-email-subhasish@mistralsolutions.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<1296571667-12049-8-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D494875.50002@mvista.com>

Hello.

On 01-02-2011 17:47, Subhasish Ghosh wrote:

> This patch adds the PRUSS CAN data.

> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
[...]

> diff --git a/include/linux/mfd/pruss/da8xx_pru.h b/include/linux/mfd/pruss/da8xx_pru.h
> index 318dad8..2fa7ff5 100644
> --- a/include/linux/mfd/pruss/da8xx_pru.h
> +++ b/include/linux/mfd/pruss/da8xx_pru.h
> @@ -74,6 +74,10 @@ struct da8xx_pruss_devices {
>   	int (*setup)(void);
>   };
>
> +struct da8xx_pruss_can_data {
> +	u32 version;
> +};
> +

    This patch too should precede the patch 5/9 as it defines the stucture 
used there...

WBR, Sergei


From sshtylyov at mvista.com  Wed Feb  2 06:07:04 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 15:07:04 +0300
Subject: [PATCH v1 8/9] da850: pruss CAN board specific changes for gpios.
In-Reply-To: <1296571667-12049-9-git-send-email-subhasish@mistralsolutions.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<1296571667-12049-9-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D4948E8.4020106@mvista.com>

On 01-02-2011 17:47, Subhasish Ghosh wrote:

> This patch adds the GPIO modifications required for the pruss CAN.

> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
> ---
>   arch/arm/mach-davinci/board-da850-evm.c |   11 ++++++++++-
>   1 files changed, 10 insertions(+), 1 deletions(-)

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 285545f..737df73 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -45,6 +45,7 @@
>
>   #define DA850_MMCSD_CD_PIN		GPIO_TO_PIN(4, 0)
>   #define DA850_MMCSD_WP_PIN		GPIO_TO_PIN(4, 1)
> +#define DA850_PRUSS_CAN_TRX_PIN	GPIO_TO_PIN(2, 0)
>
>   #define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
>
> @@ -1055,7 +1056,7 @@ static __init int da850_evm_init_cpufreq(void) { return 0; }
>
>   const short da850_pruss_can_pins[] = {
>   	DA850_PRUSS_PRU0_R31_0, DA850_PRUSS_PRU1_R30_15,
> -	DA850_PRUSS_PRU1_R31_18,
> +	DA850_PRUSS_PRU1_R31_18, DA850_GPIO2_0,
>   	-1
>   };
>
> @@ -1076,6 +1077,14 @@ static int __init da850_evm_setup_pruss_can(void)
>   	val |= BIT(3);
>   	__raw_writel(val, cfg_chip3_base);
>
> +	/* value = 0 to enable the CAN transceiver */
> +	ret = gpio_request_one(DA850_PRUSS_CAN_TRX_PIN,
> +					GPIOF_OUT_INIT_LOW, "pruss_can_en");
> +	if (ret) {
> +		pr_warning("Cannot setup GPIO %d\n", DA850_PRUSS_CAN_TRX_PIN);
> +		gpio_free(DA850_PRUSS_CAN_TRX_PIN);
> +	}
> +
>   	return ret;
>   }

    Should be mereged with patch 5/9, I think...

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 06:08:12 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 15:08:12 +0300
Subject: [PATCH v1 9/9] da850: pruss CAN platform specific changes for
	gpios.
In-Reply-To: <1296571667-12049-10-git-send-email-subhasish@mistralsolutions.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<1296571667-12049-10-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D49492C.1000303@mvista.com>

On 01-02-2011 17:47, Subhasish Ghosh wrote:

> This patch adds the GPIOs for the pruss CAN device.

> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
[...]

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 11ce7ba..9382b4f 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -570,6 +570,7 @@ static const struct mux_config da850_pins[] = {
>   	MUX_CFG(DA850, PRUSS_PRU1_R30_15,	12,	0,	15,	4,	false)
>   	MUX_CFG(DA850, PRUSS_PRU1_R31_18,	11,	20,	15,	0,	false)
>   	/* GPIO function */
> +	MUX_CFG(DA850, GPIO2_0,		6,	28,	15,	8,	false)
>   	MUX_CFG(DA850, GPIO2_4,		6,	12,	15,	8,	false)
>   	MUX_CFG(DA850, GPIO2_6,		6,	4,	15,	8,	false)
>   	MUX_CFG(DA850, GPIO2_8,		5,	28,	15,	8,	false)
> diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
> index 10f49f2..85b3a0d 100644
> --- a/arch/arm/mach-davinci/include/mach/mux.h
> +++ b/arch/arm/mach-davinci/include/mach/mux.h
> @@ -912,6 +912,7 @@ enum davinci_da850_index {
>   	DA850_PRUSS_PRU1_R31_18,
>
>   	/* GPIO function */
> +	DA850_GPIO2_0,
>   	DA850_GPIO2_4,
>   	DA850_GPIO2_6,
>   	DA850_GPIO2_8,

    Should again precede the previous patch. I thought that must be obvious...

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 06:22:02 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 15:22:02 +0300
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
Message-ID: <4D494C6A.30507@mvista.com>

Hello.

On 02-02-2011 0:49, Michael Williamson wrote:

> Add SPI registration routines, clocks, and driver resources for
> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.

    You're only adding clocks for the former platform -- the ones for the 
latter platfrom are already there...

> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
[...]

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3443d97..68fe4c2 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -359,6 +359,20 @@ static struct clk usb20_clk = {
>   	.gpsc		= 1,
>   };
>
> +static struct clk spi0_clk = {
> +	.name		= "spi0",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC0_SPI0,
> +};
> +
> +static struct clk spi1_clk = {
> +	.name		= "spi1",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC1_SPI1,
> +	.gpsc		= 1,
> +	.flags		= DA850_CLK_ASYNC3,
> +};
> +
>   static struct clk_lookup da850_clks[] = {
>   	CLK(NULL,		"ref",		&ref_clk),
>   	CLK(NULL,		"pll0",		&pll0_clk),
> @@ -403,6 +417,8 @@ static struct clk_lookup da850_clks[] = {
>   	CLK(NULL,		"aemif",	&aemif_clk),
>   	CLK(NULL,		"usb11",	&usb11_clk),
>   	CLK(NULL,		"usb20",	&usb20_clk),
> +	CLK("spi_davinci.0",	NULL,		&spi0_clk),
> +	CLK("spi_davinci.1",	NULL,		&spi1_clk),
>   	CLK(NULL,		NULL,		NULL),
>   };

    It's worth separating this into a patch of its own...

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index beda8a4..f421f97 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
>
>   	return platform_device_register(&da8xx_cpuidle_device);
>   }
> +
> +static struct resource da8xx_spi0_resources[] = {
> +	[0] = {
> +		.start	= 0x01c41000,
> +		.end	= 0x01c41fff,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= IRQ_DA8XX_SPINT0,
> +		.end	= IRQ_DA8XX_SPINT0,
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +	[2] = {
> +		.start	= EDMA_CTLR_CHAN(0, 14),
> +		.end	= EDMA_CTLR_CHAN(0, 14),
> +		.flags	= IORESOURCE_DMA,
> +	},
> +	[3] = {
> +		.start	= EDMA_CTLR_CHAN(0, 15),
> +		.end	= EDMA_CTLR_CHAN(0, 15),
> +		.flags	= IORESOURCE_DMA,
> +	},

    We have DA830_DMACH_SPI0_[RT]X defined for SPI0 DMA channels...

> +	[4] = {
> +		.flags	= IORESOURCE_DMA,
> +	},

    BTW, why do you need this placeholder?

> +};
> +
> +static struct resource da8xx_spi1_resources[] = {
> +	[0] = {
> +		.start	= 0x01f0e000,
> +		.end	= 0x01f0efff,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= IRQ_DA8XX_SPINT1,
> +		.end	= IRQ_DA8XX_SPINT1,
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +	[2] = {
> +		.start	= EDMA_CTLR_CHAN(0, 18),
> +		.end	= EDMA_CTLR_CHAN(0, 18),
> +		.flags	= IORESOURCE_DMA,
> +	},
> +	[3] = {
> +		.start	= EDMA_CTLR_CHAN(0, 19),
> +		.end	= EDMA_CTLR_CHAN(0, 19),
> +		.flags	= IORESOURCE_DMA,
> +	},

    We have DA830_DMACH_SPI1_[RT]X defined for SPI1 DMA channels...

> +	[4] = {
> +		.flags	= IORESOURCE_DMA,

     ... and this one?

> +	},
> +};
> +

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 06:29:01 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 15:29:01 +0300
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
Message-ID: <4D494E0D.4090207@mvista.com>

Hello.

On 02-02-2011 0:49, Michael Williamson wrote:

> Add SPI registration routines, clocks, and driver resources for
> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.

> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
[...]

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3443d97..68fe4c2 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
[...]
> @@ -403,6 +417,8 @@ static struct clk_lookup da850_clks[] = {
>   	CLK(NULL,		"aemif",	&aemif_clk),
>   	CLK(NULL,		"usb11",	&usb11_clk),
>   	CLK(NULL,		"usb20",	&usb20_clk),
> +	CLK("spi_davinci.0",	NULL,		&spi0_clk),
> +	CLK("spi_davinci.1",	NULL,		&spi1_clk),

    BTW, da830.c has "dm_spi.[01]" instead -- which should be fixed (by yet 
another patch).

>   	CLK(NULL,		NULL,		NULL),
>   };
>

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 06:53:40 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 15:53:40 +0300
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
Message-ID: <4D4953D4.7080204@mvista.com>

Hello.

On 02-02-2011 0:49, Michael Williamson wrote:

> Add SPI registration routines, clocks, and driver resources for
> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.

> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
[...]

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index beda8a4..f421f97 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
>
>   	return platform_device_register(&da8xx_cpuidle_device);
>   }
> +
> +static struct resource da8xx_spi0_resources[] = {
> +	[0] = {
> +		.start	= 0x01c41000,
> +		.end	= 0x01c41fff,

    BTW, I suggest to declare DA8XX_SPI0_BASE, not to deviate from the 
tradition developed in this file...

> +static struct resource da8xx_spi1_resources[] = {
> +	[0] = {
> +		.start	= 0x01f0e000,
> +		.end	= 0x01f0efff,

    The same about DA8XX_SPI1_BASE...

WBR, Sergei

From michael.williamson at criticallink.com  Wed Feb  2 06:55:22 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 02 Feb 2011 07:55:22 -0500
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D494C6A.30507@mvista.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D494C6A.30507@mvista.com>
Message-ID: <4D49543A.1070302@criticallink.com>

Hi Sergei,

On 2/2/2011 7:22 AM, Sergei Shtylyov wrote:

> Hello.
> 
> On 02-02-2011 0:49, Michael Williamson wrote:
> 
>> Add SPI registration routines, clocks, and driver resources for
>> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.
> 
>    You're only adding clocks for the former platform -- the ones for the latter platfrom are already there...
> 
>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> index 3443d97..68fe4c2 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -359,6 +359,20 @@ static struct clk usb20_clk = {
>>       .gpsc        = 1,
>>   };
>>
>> +static struct clk spi0_clk = {
>> +    .name        = "spi0",
>> +    .parent        = &pll0_sysclk2,
>> +    .lpsc        = DA8XX_LPSC0_SPI0,
>> +};
>> +
>> +static struct clk spi1_clk = {
>> +    .name        = "spi1",
>> +    .parent        = &pll0_sysclk2,
>> +    .lpsc        = DA8XX_LPSC1_SPI1,
>> +    .gpsc        = 1,
>> +    .flags        = DA850_CLK_ASYNC3,
>> +};
>> +
>>   static struct clk_lookup da850_clks[] = {
>>       CLK(NULL,        "ref",        &ref_clk),
>>       CLK(NULL,        "pll0",        &pll0_clk),
>> @@ -403,6 +417,8 @@ static struct clk_lookup da850_clks[] = {
>>       CLK(NULL,        "aemif",    &aemif_clk),
>>       CLK(NULL,        "usb11",    &usb11_clk),
>>       CLK(NULL,        "usb20",    &usb20_clk),
>> +    CLK("spi_davinci.0",    NULL,        &spi0_clk),
>> +    CLK("spi_davinci.1",    NULL,        &spi1_clk),
>>       CLK(NULL,        NULL,        NULL),
>>   };
> 
>    It's worth separating this into a patch of its own...
> 


OK, I will pull this into a separate patch.

>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>> index beda8a4..f421f97 100644
>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>> @@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
>>
>>       return platform_device_register(&da8xx_cpuidle_device);
>>   }
>> +
>> +static struct resource da8xx_spi0_resources[] = {
>> +    [0] = {
>> +        .start    = 0x01c41000,
>> +        .end    = 0x01c41fff,
>> +        .flags    = IORESOURCE_MEM,
>> +    },
>> +    [1] = {
>> +        .start    = IRQ_DA8XX_SPINT0,
>> +        .end    = IRQ_DA8XX_SPINT0,
>> +        .flags    = IORESOURCE_IRQ,
>> +    },
>> +    [2] = {
>> +        .start    = EDMA_CTLR_CHAN(0, 14),
>> +        .end    = EDMA_CTLR_CHAN(0, 14),
>> +        .flags    = IORESOURCE_DMA,
>> +    },
>> +    [3] = {
>> +        .start    = EDMA_CTLR_CHAN(0, 15),
>> +        .end    = EDMA_CTLR_CHAN(0, 15),
>> +        .flags    = IORESOURCE_DMA,
>> +    },
> 
>    We have DA830_DMACH_SPI0_[RT]X defined for SPI0 DMA channels...
> 


Right.  The current routines/structures were designed to support either da830 or
da850.  They work because the interrupts and the DMA channels are fortunately
the same for the SPI devices between the platforms.  I can use the DA830 enums, 
but I had preferred the clarity of the EDMA_CTRL_CHAN macro, and it would 
remove confusion that this might only apply for DA830 and not DA850.  It would
be nice to rename that DA8XX_DMAC_SPI_[RT]X if the enums were used...

Can I leave this, or do you really want me to use the enums?

>> +    [4] = {
>> +        .flags    = IORESOURCE_DMA,
>> +    },
> 
>    BTW, why do you need this placeholder?
> 


This is for the eventq selection in the edma allocation by the spi driver.  When I 
previously had 0, I should have used EVENTQ_0 (how it was tested).  I will add it 
back in to clarification.

>> +};
>> +
>> +static struct resource da8xx_spi1_resources[] = {
>> +    [0] = {
>> +        .start    = 0x01f0e000,
>> +        .end    = 0x01f0efff,
>> +        .flags    = IORESOURCE_MEM,
>> +    },
>> +    [1] = {
>> +        .start    = IRQ_DA8XX_SPINT1,
>> +        .end    = IRQ_DA8XX_SPINT1,
>> +        .flags    = IORESOURCE_IRQ,
>> +    },
>> +    [2] = {
>> +        .start    = EDMA_CTLR_CHAN(0, 18),
>> +        .end    = EDMA_CTLR_CHAN(0, 18),
>> +        .flags    = IORESOURCE_DMA,
>> +    },
>> +    [3] = {
>> +        .start    = EDMA_CTLR_CHAN(0, 19),
>> +        .end    = EDMA_CTLR_CHAN(0, 19),
>> +        .flags    = IORESOURCE_DMA,
>> +    },
> 
>    We have DA830_DMACH_SPI1_[RT]X defined for SPI1 DMA channels...
> 


I'd really prefer this way, but will change it to DA830_DMAC_SPI1* enum
if you require it.

>> +    [4] = {
>> +        .flags    = IORESOURCE_DMA,
> 
>     ... and this one?
> 


See above.

>> +    },
>> +};
>> +
> 
> WBR, Sergei



From michael.williamson at criticallink.com  Wed Feb  2 06:56:22 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 02 Feb 2011 07:56:22 -0500
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D4953D4.7080204@mvista.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D4953D4.7080204@mvista.com>
Message-ID: <4D495476.1040002@criticallink.com>

On 2/2/2011 7:53 AM, Sergei Shtylyov wrote:

> Hello.
> 
> On 02-02-2011 0:49, Michael Williamson wrote:
> 
>> Add SPI registration routines, clocks, and driver resources for
>> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.
> 
>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>> index beda8a4..f421f97 100644
>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>> @@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
>>
>>       return platform_device_register(&da8xx_cpuidle_device);
>>   }
>> +
>> +static struct resource da8xx_spi0_resources[] = {
>> +    [0] = {
>> +        .start    = 0x01c41000,
>> +        .end    = 0x01c41fff,
> 
>    BTW, I suggest to declare DA8XX_SPI0_BASE, not to deviate from the tradition developed in this file...
> 


OK. Thanks.

>> +static struct resource da8xx_spi1_resources[] = {
>> +    [0] = {
>> +        .start    = 0x01f0e000,
>> +        .end    = 0x01f0efff,
> 
>    The same about DA8XX_SPI1_BASE...
> 

Thanks.

> WBR, Sergei



From michael.williamson at criticallink.com  Wed Feb  2 06:59:30 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 02 Feb 2011 07:59:30 -0500
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D494E0D.4090207@mvista.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D494E0D.4090207@mvista.com>
Message-ID: <4D495532.7020205@criticallink.com>

On 2/2/2011 7:29 AM, Sergei Shtylyov wrote:

> Hello.
> 
> On 02-02-2011 0:49, Michael Williamson wrote:
> 
>> Add SPI registration routines, clocks, and driver resources for
>> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.
> 
>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> index 3443d97..68fe4c2 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
> [...]
>> @@ -403,6 +417,8 @@ static struct clk_lookup da850_clks[] = {
>>       CLK(NULL,        "aemif",    &aemif_clk),
>>       CLK(NULL,        "usb11",    &usb11_clk),
>>       CLK(NULL,        "usb20",    &usb20_clk),
>> +    CLK("spi_davinci.0",    NULL,        &spi0_clk),
>> +    CLK("spi_davinci.1",    NULL,        &spi1_clk),
> 
>    BTW, da830.c has "dm_spi.[01]" instead -- which should be fixed (by yet another patch).
> 


As I am going around the loop again, I will add a separate patch to the series to rename
this clock to spi_davinci.[01].  Thanks for the close look.  I clearly missed some of the
da830 details.

>>       CLK(NULL,        NULL,        NULL),
>>   };
>>
> 
> WBR, Sergei



From sshtylyov at mvista.com  Wed Feb  2 07:04:34 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 16:04:34 +0300
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D49543A.1070302@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D494C6A.30507@mvista.com> <4D49543A.1070302@criticallink.com>
Message-ID: <4D495662.3060302@mvista.com>

Hello.

On 02-02-2011 15:55, Michael Williamson wrote:

>>> Add SPI registration routines, clocks, and driver resources for
>>> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.

>>     You're only adding clocks for the former platform -- the ones for the latter platfrom are already there...

>>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
>> [...]

>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>>> index beda8a4..f421f97 100644
>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>> @@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
>>>
>>>        return platform_device_register(&da8xx_cpuidle_device);
>>>    }
>>> +
>>> +static struct resource da8xx_spi0_resources[] = {
>>> +    [0] = {
>>> +        .start    = 0x01c41000,
>>> +        .end    = 0x01c41fff,
>>> +        .flags    = IORESOURCE_MEM,
>>> +    },
>>> +    [1] = {
>>> +        .start    = IRQ_DA8XX_SPINT0,
>>> +        .end    = IRQ_DA8XX_SPINT0,
>>> +        .flags    = IORESOURCE_IRQ,
>>> +    },
>>> +    [2] = {
>>> +        .start    = EDMA_CTLR_CHAN(0, 14),
>>> +        .end    = EDMA_CTLR_CHAN(0, 14),
>>> +        .flags    = IORESOURCE_DMA,
>>> +    },
>>> +    [3] = {
>>> +        .start    = EDMA_CTLR_CHAN(0, 15),
>>> +        .end    = EDMA_CTLR_CHAN(0, 15),
>>> +        .flags    = IORESOURCE_DMA,
>>> +    },

>>     We have DA830_DMACH_SPI0_[RT]X defined for SPI0 DMA channels...

> Right.  The current routines/structures were designed to support either da830 or
> da850.  They work because the interrupts and the DMA channels are fortunately
> the same for the SPI devices between the platforms.  I can use the DA830 enums,
> but I had preferred the clarity of the EDMA_CTRL_CHAN macro, and it would
> remove confusion that this might only apply for DA830 and not DA850.  It would
> be nice to rename that DA8XX_DMAC_SPI_[RT]X if the enums were used...

> Can I leave this, or do you really want me to use the enums?

    OK, you can leave this as is...

>>> +    [4] = {
>>> +        .flags    = IORESOURCE_DMA,
>>> +    },

>>     BTW, why do you need this placeholder?

> This is for the eventq selection in the edma allocation by the spi driver.  When I
> previously had 0, I should have used EVENTQ_0 (how it was tested).  I will add it
> back in to clarification.

    But event queue is not a DMA channel, so can't have just IORESOURCE_DMA in 
'flags'. IIUC, there was a patch to add some clarifying flag(s) to 
IORESOURCE_DMA to support the event queue resource (which I never approved :-).

WBR, Sergei

From subhasish at mistralsolutions.com  Wed Feb  2 07:10:12 2011
From: subhasish at mistralsolutions.com (subhasish)
Date: Wed, 2 Feb 2011 05:10:12 -0800 (PST)
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <4D494625.4030503@mvista.com>
References: <4D494625.4030503@mvista.com>
Message-ID: <1296652212347-5984699.post@n2.nabble.com>



Sergei Shtylyov-2 wrote:
> 
> Hello.
> 
> On 01-02-2011 17:47, Subhasish Ghosh wrote:
> 
>> This patch adds the platform device and assignes the platform resources
>> for the PRUSS mfd driver.
> 
>> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/da850.c
>> b/arch/arm/mach-davinci/da850.c
>> index 3443d97..341d836 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -238,6 +238,12 @@ static struct clk tptc2_clk = {
>>   	.flags		= ALWAYS_ENABLED,
>>   };
>>
>> +static struct clk pruss_clk = {
>> +	.name		= "pruss",
>> +	.parent		= &pll0_sysclk2,
>> +	.lpsc		= DA8XX_LPSC0_DMAX,
> 
>     IIRC, you were asked to change/add a new name for what is known as 
> DA8XX_LPSC0_DMAX...
> 
>    [SG]  This macro is also getting used by arch/arm/mach-davinci/da830.c.
> Hence, changing this is breaking the da830 build. Not sure how to go about
> it.
> 
>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
>> b/arch/arm/mach-davinci/devices-da8xx.c
>> index beda8a4..562882c 100644
>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> 
>> +struct platform_device da8xx_pruss_dev = {
>> +	.name			=	"da8xx_pruss",
>> +	.id				=	-1,
>> +	.num_resources	=	ARRAY_SIZE(da8xx_pruss_resources),
>> +	.resource		=	da8xx_pruss_resources,
> 
>     Please align = uniformly.
> 
> [SG]  -- I think the problem is the tabs stops. I use ts=4, but, I think
> the web displays as ts=8. When I looked into other platform files, I
> noticed that many other macros/initializers get aligned/misaligned if I
> change between ts=4 and ts=8.
> 
>> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
>> b/arch/arm/mach-davinci/include/mach/da8xx.h
>> index cfcb223..e5c178a 100644
>> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
>> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> [...]
>> @@ -81,6 +82,7 @@ int da8xx_register_watchdog(void);
>>  int da8xx_register_usb20(unsigned mA, unsigned potpgt);
>>  int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
>>  int da8xx_register_emac(void);
>> +int da8xx_register_pruss(struct da8xx_pruss_devices *);
>>  int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
>>  int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
>>  int da850_register_mmcsd1(struct davinci_mmc_config *config);
> 
>     This patch should clearly precede the patch 2/9 as it defines 
> da8xx_register_pruss() which 2/9 uses.
> 
>  [SG] -- Yes, I think I messed up the overall patch sequence. Will fix
> these with the next version.
> 
> 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
> 
> 

-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/Re-PATCH-v1-3-9-da850-pruss-platform-specific-additions-tp5984493p5984699.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From sshtylyov at mvista.com  Wed Feb  2 07:16:25 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 16:16:25 +0300
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <1296652212347-5984699.post@n2.nabble.com>
References: <4D494625.4030503@mvista.com>
	<1296652212347-5984699.post@n2.nabble.com>
Message-ID: <4D495929.40405@mvista.com>

Hello.

On 02-02-2011 16:10, subhasish wrote:

    You have strange manner of replying -- please don't quote your own words...

> Sergei Shtylyov-2 wrote:

    2?

>>> This patch adds the platform device and assignes the platform resources
>>> for the PRUSS mfd driver.

>>> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
>> [...]

>>> diff --git a/arch/arm/mach-davinci/da850.c
>>> b/arch/arm/mach-davinci/da850.c
>>> index 3443d97..341d836 100644
>>> --- a/arch/arm/mach-davinci/da850.c
>>> +++ b/arch/arm/mach-davinci/da850.c
>>> @@ -238,6 +238,12 @@ static struct clk tptc2_clk = {
>>>    	.flags		= ALWAYS_ENABLED,
>>>    };
>>>
>>> +static struct clk pruss_clk = {
>>> +	.name		= "pruss",
>>> +	.parent		= &pll0_sysclk2,
>>> +	.lpsc		= DA8XX_LPSC0_DMAX,

>>      IIRC, you were asked to change/add a new name for what is known as
>> DA8XX_LPSC0_DMAX...

>     [SG]  This macro is also getting used by arch/arm/mach-davinci/da830.c.
> Hence, changing this is breaking the da830 build. Not sure how to go about
> it.

    I suspect that dMAX is specific to DA830, and PRUSS is specific to DA850. 
Therefore I think you should add the DA850_LPSC0_PRUSS definition (and 
probably change from DA8XX_LPSC0_DMAX to DA830_LPSC0_DMAX) with another patch.

>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
>>> b/arch/arm/mach-davinci/devices-da8xx.c
>>> index beda8a4..562882c 100644
>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c

>>> +struct platform_device da8xx_pruss_dev = {
>>> +	.name			=	"da8xx_pruss",
>>> +	.id				=	-1,
>>> +	.num_resources	=	ARRAY_SIZE(da8xx_pruss_resources),
>>> +	.resource		=	da8xx_pruss_resources,

>>      Please align = uniformly.

> [SG]  -- I think the problem is the tabs stops. I use ts=4, but, I think
> the web displays as ts=8. When I looked into other platform files, I
> noticed that many other macros/initializers get aligned/misaligned if I
> change between ts=4 and ts=8.

    Just always use ts=8.

WBR, Sergei

From subhasish at mistralsolutions.com  Wed Feb  2 07:18:13 2011
From: subhasish at mistralsolutions.com (subhasish)
Date: Wed, 2 Feb 2011 05:18:13 -0800 (PST)
Subject: [PATCH v1 5/9] da850: pruss CAN board specific additions.
In-Reply-To: <4D49479E.3010008@mvista.com>
References: <4D49479E.3010008@mvista.com>
Message-ID: <1296652693554-5984717.post@n2.nabble.com>



Sergei Shtylyov-2 wrote:
> 
> Hello.
> 
> On 01-02-2011 17:47, Subhasish Ghosh wrote:
> 
>> This patch adds the pruss CAN pin mux and registers the device
>> with the pruss mfd driver.
> 
>> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
>> b/arch/arm/mach-davinci/board-da850-evm.c
>> index 7938c6d..285545f 100644
>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
>> @@ -1053,8 +1053,46 @@ static __init int da850_evm_init_cpufreq(void)
>>   static __init int da850_evm_init_cpufreq(void) { return 0; }
>>   #endif
>>
>> +const short da850_pruss_can_pins[] = {
> 
>     Only da850_evm_pruss_can_pins[].
> 
> [SG] -- Will Change this.
> 
>> +	DA850_PRUSS_PRU0_R31_0, DA850_PRUSS_PRU1_R30_15,
>> +	DA850_PRUSS_PRU1_R31_18,
>> +	-1
>> +};
>> +
>> +static int __init da850_evm_setup_pruss_can(void)
>> +{
>> +	int ret, val = 0;
>> +	void __iomem *cfg_chip3_base;
> 
>     CFGCHIP3 is a signle register, so it doesn't make sense to talk about
> its 
> base...
> 
> [SG] -- ok, will rename to cfg_chip3_reg
> 
>> +	if (!machine_is_davinci_da850_evm())
>> +		return 0;
> 
>     This check doesn't make sense as this function is not declared as 
> *_initcall(). It will only be called on this machine anyway.
> 
> [SG] -- ok, will remove.
> 
>> +	ret = davinci_cfg_reg_list(da850_pruss_can_pins);
>> +	if (ret)
>> +		pr_warning("%s: da850_pruss_can_pins mux setup "
>> +					"failed:%d\n", __func__, ret);
>> +	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
>> +	val = __raw_readl(cfg_chip3_base);
>> +	val |= BIT(3);
>> +	__raw_writel(val, cfg_chip3_base);
>> +
>> +	return ret;
>> +}
>> +
>> +static struct da8xx_pruss_can_data can_data = {
>> +	.version	= 1,
>> +};
>> +
>>   static struct da8xx_pruss_devices pruss_devices[] = {
>> -	{.dev_name = NULL,},
>> +	{
>> +		.dev_name	= "da8xx_pruss_can",
>> +		.pdata		= &can_data,
>> +		.pdata_size	= sizeof(can_data),
>> +		.setup		= da850_evm_setup_pruss_can,
>> +	},
>> +	{
>> +		.dev_name	= NULL,
>> +	},
> 
>     Why you need a dummy lst element in this array?
> 
> [SG] -- I am using this as a delimiter. In the MFD driver, I use this to
> figure out the number of devices.
>            At that point I don't have the ARRAY_SIZE.
> 
> 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
> 
> 

-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/Re-PATCH-v1-5-9-da850-pruss-CAN-board-specific-additions-tp5984507p5984717.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From subhasish at mistralsolutions.com  Wed Feb  2 07:19:26 2011
From: subhasish at mistralsolutions.com (subhasish)
Date: Wed, 2 Feb 2011 05:19:26 -0800 (PST)
Subject: [PATCH v1 6/9] da850: pruss CAN platform specific additions.
In-Reply-To: <4D494817.4030204@mvista.com>
References: <4D494817.4030204@mvista.com>
Message-ID: <1296652766953-5984725.post@n2.nabble.com>



Sergei Shtylyov-2 wrote:
> 
> Hello.
> 
> On 01-02-2011 17:47, Subhasish Ghosh wrote:
> 
>> This patch adds the necessary pins for the pruss CAN.
> 
>> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/da850.c
>> b/arch/arm/mach-davinci/da850.c
>> index 341d836..11ce7ba 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -565,6 +565,10 @@ static const struct mux_config da850_pins[] = {
>>   	MUX_CFG(DA850, EMA_CLK,		6,	0,	15,	1,	false)
>>   	MUX_CFG(DA850, EMA_WAIT_1,	6,	24,	15,	1,	false)
>>   	MUX_CFG(DA850, NEMA_CS_2,	7,	0,	15,	1,	false)
>> +	/* PRU functions for soft CAN */
>> +	MUX_CFG(DA850, PRUSS_PRU0_R31_0,	7,	28,	15,	0,	false)
>> +	MUX_CFG(DA850, PRUSS_PRU1_R30_15,	12,	0,	15,	4,	false)
>> +	MUX_CFG(DA850, PRUSS_PRU1_R31_18,	11,	20,	15,	0,	false)
>>   	/* GPIO function */
>>   	MUX_CFG(DA850, GPIO2_4,		6,	12,	15,	8,	false)
>>   	MUX_CFG(DA850, GPIO2_6,		6,	4,	15,	8,	false)
>> diff --git a/arch/arm/mach-davinci/include/mach/mux.h
>> b/arch/arm/mach-davinci/include/mach/mux.h
>> index 5d4e0fe..10f49f2 100644
>> --- a/arch/arm/mach-davinci/include/mach/mux.h
>> +++ b/arch/arm/mach-davinci/include/mach/mux.h
>> @@ -906,6 +906,10 @@ enum davinci_da850_index {
>>   	DA850_EMA_CLK,
>>   	DA850_EMA_WAIT_1,
>>   	DA850_NEMA_CS_2,
>> +	/* PRU I/O */
>> +	DA850_PRUSS_PRU0_R31_0,
>> +	DA850_PRUSS_PRU1_R30_15,
>> +	DA850_PRUSS_PRU1_R31_18,
> 
>     Again, this patch should precede the patch 5/9 due to PinMux
> dependencies. 
> I thought it must be pretty clear...
> 
> [SG] -- Wil fix the order in the next version.
> 
> 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
> 
> 

-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/Re-PATCH-v1-6-9-da850-pruss-CAN-platform-specific-additions-tp5984511p5984725.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From subhasish at mistralsolutions.com  Wed Feb  2 07:19:52 2011
From: subhasish at mistralsolutions.com (subhasish)
Date: Wed, 2 Feb 2011 05:19:52 -0800 (PST)
Subject: [PATCH v1 7/9] mfd: pruss CAN private data.
In-Reply-To: <4D494875.50002@mvista.com>
References: <4D494875.50002@mvista.com>
Message-ID: <1296652792489-5984726.post@n2.nabble.com>



Sergei Shtylyov-2 wrote:
> 
> Hello.
> 
> On 01-02-2011 17:47, Subhasish Ghosh wrote:
> 
>> This patch adds the PRUSS CAN data.
> 
>> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
> [...]
> 
>> diff --git a/include/linux/mfd/pruss/da8xx_pru.h
>> b/include/linux/mfd/pruss/da8xx_pru.h
>> index 318dad8..2fa7ff5 100644
>> --- a/include/linux/mfd/pruss/da8xx_pru.h
>> +++ b/include/linux/mfd/pruss/da8xx_pru.h
>> @@ -74,6 +74,10 @@ struct da8xx_pruss_devices {
>>   	int (*setup)(void);
>>   };
>>
>> +struct da8xx_pruss_can_data {
>> +	u32 version;
>> +};
>> +
> 
>     This patch too should precede the patch 5/9 as it defines the stucture 
> used there...
> [SG] -- Wil fix the order in the next version.
> 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
> 
> 

-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/Re-PATCH-v1-7-9-mfd-pruss-CAN-private-data-tp5984520p5984726.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From michael.williamson at criticallink.com  Wed Feb  2 07:21:24 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 02 Feb 2011 08:21:24 -0500
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D495662.3060302@mvista.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D494C6A.30507@mvista.com> <4D49543A.1070302@criticallink.com>
	<4D495662.3060302@mvista.com>
Message-ID: <4D495A54.2090702@criticallink.com>

On 2/2/2011 8:04 AM, Sergei Shtylyov wrote:

> Hello.
> 
> On 02-02-2011 15:55, Michael Williamson wrote:
> 
>>>> Add SPI registration routines, clocks, and driver resources for
>>>> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.
> 
>>>     You're only adding clocks for the former platform -- the ones for the latter platfrom are already there...
> 
>>>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
>>> [...]
> 
>>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>>>> index beda8a4..f421f97 100644
>>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>>> @@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
>>>>
>>>>        return platform_device_register(&da8xx_cpuidle_device);
>>>>    }
>>>> +
>>>> +static struct resource da8xx_spi0_resources[] = {
>>>> +    [0] = {
>>>> +        .start    = 0x01c41000,
>>>> +        .end    = 0x01c41fff,
>>>> +        .flags    = IORESOURCE_MEM,
>>>> +    },
>>>> +    [1] = {
>>>> +        .start    = IRQ_DA8XX_SPINT0,
>>>> +        .end    = IRQ_DA8XX_SPINT0,
>>>> +        .flags    = IORESOURCE_IRQ,
>>>> +    },
>>>> +    [2] = {
>>>> +        .start    = EDMA_CTLR_CHAN(0, 14),
>>>> +        .end    = EDMA_CTLR_CHAN(0, 14),
>>>> +        .flags    = IORESOURCE_DMA,
>>>> +    },
>>>> +    [3] = {
>>>> +        .start    = EDMA_CTLR_CHAN(0, 15),
>>>> +        .end    = EDMA_CTLR_CHAN(0, 15),
>>>> +        .flags    = IORESOURCE_DMA,
>>>> +    },
> 
>>>     We have DA830_DMACH_SPI0_[RT]X defined for SPI0 DMA channels...
> 
>> Right.  The current routines/structures were designed to support either da830 or
>> da850.  They work because the interrupts and the DMA channels are fortunately
>> the same for the SPI devices between the platforms.  I can use the DA830 enums,
>> but I had preferred the clarity of the EDMA_CTRL_CHAN macro, and it would
>> remove confusion that this might only apply for DA830 and not DA850.  It would
>> be nice to rename that DA8XX_DMAC_SPI_[RT]X if the enums were used...
> 
>> Can I leave this, or do you really want me to use the enums?
> 
>    OK, you can leave this as is...
> 
>>>> +    [4] = {
>>>> +        .flags    = IORESOURCE_DMA,
>>>> +    },
> 
>>>     BTW, why do you need this placeholder?
> 
>> This is for the eventq selection in the edma allocation by the spi driver.  When I
>> previously had 0, I should have used EVENTQ_0 (how it was tested).  I will add it
>> back in to clarification.
> 
>    But event queue is not a DMA channel, so can't have just IORESOURCE_DMA in 'flags'. IIUC, there was a patch to add some clarifying flag(s) to IORESOURCE_DMA to support the event queue resource (which I never approved :-).
> 



I'd like to get the support in there for the driver that's currently in 
the mainline, which needs this resource as it is.  I had essentially copied
the setup approach from the dm365.c board file, which is doing the same thing.

It looks like other devices take EVENTQ information as platform data (e.g., 
snd_platform_data takes .asp_chan_q).  Would it make sense to update the
spi platform data to accept an EVENTQ parameter as well?  I would be willing
to push a follow on patch to sort this out, if it is required.

Thanks.

> WBR, Sergei



From subhasish at mistralsolutions.com  Wed Feb  2 07:21:52 2011
From: subhasish at mistralsolutions.com (subhasish)
Date: Wed, 2 Feb 2011 05:21:52 -0800 (PST)
Subject: [PATCH v1 8/9] da850: pruss CAN board specific changes for gpios.
In-Reply-To: <4D4948E8.4020106@mvista.com>
References: <4D4948E8.4020106@mvista.com>
Message-ID: <1296652912036-5984741.post@n2.nabble.com>



Sergei Shtylyov-2 wrote:
> 
> On 01-02-2011 17:47, Subhasish Ghosh wrote:
> 
>> This patch adds the GPIO modifications required for the pruss CAN.
> 
>> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
>> ---
>>   arch/arm/mach-davinci/board-da850-evm.c |   11 ++++++++++-
>>   1 files changed, 10 insertions(+), 1 deletions(-)
> 
>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
>> b/arch/arm/mach-davinci/board-da850-evm.c
>> index 285545f..737df73 100644
>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
>> @@ -45,6 +45,7 @@
>>
>>   #define DA850_MMCSD_CD_PIN		GPIO_TO_PIN(4, 0)
>>   #define DA850_MMCSD_WP_PIN		GPIO_TO_PIN(4, 1)
>> +#define DA850_PRUSS_CAN_TRX_PIN	GPIO_TO_PIN(2, 0)
>>
>>   #define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
>>
>> @@ -1055,7 +1056,7 @@ static __init int da850_evm_init_cpufreq(void) {
>> return 0; }
>>
>>   const short da850_pruss_can_pins[] = {
>>   	DA850_PRUSS_PRU0_R31_0, DA850_PRUSS_PRU1_R30_15,
>> -	DA850_PRUSS_PRU1_R31_18,
>> +	DA850_PRUSS_PRU1_R31_18, DA850_GPIO2_0,
>>   	-1
>>   };
>>
>> @@ -1076,6 +1077,14 @@ static int __init da850_evm_setup_pruss_can(void)
>>   	val |= BIT(3);
>>   	__raw_writel(val, cfg_chip3_base);
>>
>> +	/* value = 0 to enable the CAN transceiver */
>> +	ret = gpio_request_one(DA850_PRUSS_CAN_TRX_PIN,
>> +					GPIOF_OUT_INIT_LOW, "pruss_can_en");
>> +	if (ret) {
>> +		pr_warning("Cannot setup GPIO %d\n", DA850_PRUSS_CAN_TRX_PIN);
>> +		gpio_free(DA850_PRUSS_CAN_TRX_PIN);
>> +	}
>> +
>>   	return ret;
>>   }
> 
>     Should be mereged with patch 5/9, I think...
> 
> [SG] -- I can merge it, but I am not sure either.
> 
> 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
> 
> 

-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/Re-PATCH-v1-8-9-da850-pruss-CAN-board-specific-changes-for-gpios-tp5984524p5984741.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From subhasish at mistralsolutions.com  Wed Feb  2 07:23:08 2011
From: subhasish at mistralsolutions.com (subhasish)
Date: Wed, 2 Feb 2011 05:23:08 -0800 (PST)
Subject: [PATCH v1 9/9] da850: pruss CAN platform specific changes for
	gpios.
In-Reply-To: <4D49492C.1000303@mvista.com>
References: <4D49492C.1000303@mvista.com>
Message-ID: <1296652988339-5984747.post@n2.nabble.com>



Sergei Shtylyov-2 wrote:
> 
> On 01-02-2011 17:47, Subhasish Ghosh wrote:
> 
>> This patch adds the GPIOs for the pruss CAN device.
> 
>> Signed-off-by: Subhasish Ghosh<subhasish at mistralsolutions.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/da850.c
>> b/arch/arm/mach-davinci/da850.c
>> index 11ce7ba..9382b4f 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -570,6 +570,7 @@ static const struct mux_config da850_pins[] = {
>>   	MUX_CFG(DA850, PRUSS_PRU1_R30_15,	12,	0,	15,	4,	false)
>>   	MUX_CFG(DA850, PRUSS_PRU1_R31_18,	11,	20,	15,	0,	false)
>>   	/* GPIO function */
>> +	MUX_CFG(DA850, GPIO2_0,		6,	28,	15,	8,	false)
>>   	MUX_CFG(DA850, GPIO2_4,		6,	12,	15,	8,	false)
>>   	MUX_CFG(DA850, GPIO2_6,		6,	4,	15,	8,	false)
>>   	MUX_CFG(DA850, GPIO2_8,		5,	28,	15,	8,	false)
>> diff --git a/arch/arm/mach-davinci/include/mach/mux.h
>> b/arch/arm/mach-davinci/include/mach/mux.h
>> index 10f49f2..85b3a0d 100644
>> --- a/arch/arm/mach-davinci/include/mach/mux.h
>> +++ b/arch/arm/mach-davinci/include/mach/mux.h
>> @@ -912,6 +912,7 @@ enum davinci_da850_index {
>>   	DA850_PRUSS_PRU1_R31_18,
>>
>>   	/* GPIO function */
>> +	DA850_GPIO2_0,
>>   	DA850_GPIO2_4,
>>   	DA850_GPIO2_6,
>>   	DA850_GPIO2_8,
> 
>     Should again precede the previous patch. I thought that must be
> obvious...
> 
> [SG] -- Wil fix the order in the next version. Thanks a lot for your
> comments.
> 
> 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
> 
> 

-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/Re-PATCH-v1-9-9-da850-pruss-CAN-platform-specific-changes-for-gpios-tp5984525p5984747.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From nsekhar at ti.com  Wed Feb  2 07:33:16 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 2 Feb 2011 19:03:16 +0530
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D49543A.1070302@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D494C6A.30507@mvista.com> <4D49543A.1070302@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59302487782C9@dbde02.ent.ti.com>

On Wed, Feb 02, 2011 at 18:25:22, Michael Williamson wrote:

> >> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> >> index beda8a4..f421f97 100644
> >> --- a/arch/arm/mach-davinci/devices-da8xx.c
> >> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> >> @@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
> >>
> >>       return platform_device_register(&da8xx_cpuidle_device);
> >>   }
> >> +
> >> +static struct resource da8xx_spi0_resources[] = {
> >> +    [0] = {
> >> +        .start    = 0x01c41000,
> >> +        .end    = 0x01c41fff,
> >> +        .flags    = IORESOURCE_MEM,
> >> +    },
> >> +    [1] = {
> >> +        .start    = IRQ_DA8XX_SPINT0,
> >> +        .end    = IRQ_DA8XX_SPINT0,
> >> +        .flags    = IORESOURCE_IRQ,
> >> +    },
> >> +    [2] = {
> >> +        .start    = EDMA_CTLR_CHAN(0, 14),
> >> +        .end    = EDMA_CTLR_CHAN(0, 14),
> >> +        .flags    = IORESOURCE_DMA,
> >> +    },
> >> +    [3] = {
> >> +        .start    = EDMA_CTLR_CHAN(0, 15),
> >> +        .end    = EDMA_CTLR_CHAN(0, 15),
> >> +        .flags    = IORESOURCE_DMA,
> >> +    },
> > 
> >    We have DA830_DMACH_SPI0_[RT]X defined for SPI0 DMA channels...
> > 
> 
> 
> Right.  The current routines/structures were designed to support either da830 or
> da850.  They work because the interrupts and the DMA channels are fortunately
> the same for the SPI devices between the platforms.  I can use the DA830 enums, 
> but I had preferred the clarity of the EDMA_CTRL_CHAN macro, and it would 
> remove confusion that this might only apply for DA830 and not DA850.  It would
> be nice to rename that DA8XX_DMAC_SPI_[RT]X if the enums were used...
> 
> Can I leave this, or do you really want me to use the enums?
> 

Looks like a bunch of cleaning-up needs to happen in this area.
The DA830_DMACH_* are not used anywhere at all. Instead most of
devices-da8xx.c uses DMA channel numbers directly (except for ASP,
which has them defined in asp.h).

Since all the platform device definitions for DA8XX devices happens
in devices-da8xx.c, it makes sense to get rid of the DA830_DMACH_*
enum altogether and instead just define the channel numbers used in
devices-da8xx.c above the actual usage.

Mike, is that something you are willing take-up?

Thanks,
Sekhar


From sshtylyov at mvista.com  Wed Feb  2 07:36:33 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 16:36:33 +0300
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D495A54.2090702@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D494C6A.30507@mvista.com> <4D49543A.1070302@criticallink.com>
	<4D495662.3060302@mvista.com> <4D495A54.2090702@criticallink.com>
Message-ID: <4D495DE1.6000808@mvista.com>

Hello.

On 02-02-2011 16:21, Michael Williamson wrote:

>>>>> Add SPI registration routines, clocks, and driver resources for
>>>>> DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms.

>>>>      You're only adding clocks for the former platform -- the ones for the latter platfrom are already there...

>>>>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
>>>> [...]

>>>>> +    [4] = {
>>>>> +        .flags    = IORESOURCE_DMA,
>>>>> +    },

>>>>      BTW, why do you need this placeholder?

>>> This is for the eventq selection in the edma allocation by the spi driver.  When I
>>> previously had 0, I should have used EVENTQ_0 (how it was tested).  I will add it
>>> back in to clarification.

>>     But event queue is not a DMA channel, so can't have just IORESOURCE_DMA in 'flags'. IIUC,

    IIRC, I meant to type.

> there was a patch to add some clarifying flag(s) to IORESOURCE_DMA to support the event queue resource (which I never approved :-).


> I'd like to get the support in there for the driver that's currently in
> the mainline, which needs this resource as it is.  I had essentially copied
> the setup approach from the dm365.c board file, which is doing the same thing.

> It looks like other devices take EVENTQ information as platform data (e.g.,
> snd_platform_data takes .asp_chan_q).  Would it make sense to update the
> spi platform data to accept an EVENTQ parameter as well?

    Yes, as the event queue is not really a DMA resource (DMA channels are).

> Thanks.

WBR, Sergei

From subhasish at mistralsolutions.com  Wed Feb  2 07:44:52 2011
From: subhasish at mistralsolutions.com (subhasish)
Date: Wed, 2 Feb 2011 05:44:52 -0800 (PST)
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <4D495929.40405@mvista.com>
References: <4D494625.4030503@mvista.com>
	<1296652212347-5984699.post@n2.nabble.com>
	<4D495929.40405@mvista.com>
Message-ID: <1296654292279-5984821.post@n2.nabble.com>


Hi Sergei,

I am using the mail interface at
http://davinci-linux-open-source.1494791.n2.nabble.com/

and I enable "Quote before replying. What interface are you using to reply.
Actually, I was not subscribed to this mailing list, so it reported that my
patches are pending approval of the ML moderator. I think you are using some
other interface, so now this list contain only those patches to which you
replied!!. 

Will do the da830 changes, I was using ts=4 all throughout, so now complete
code is misaligned!! Is there any easy was to fix this.
-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/Re-PATCH-v1-3-9-da850-pruss-platform-specific-additions-tp5984493p5984821.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From subhasish at mistralsolutions.com  Wed Feb  2 07:52:16 2011
From: subhasish at mistralsolutions.com (subhasish)
Date: Wed, 2 Feb 2011 05:52:16 -0800 (PST)
Subject: [PATCH v1 2/9] da850: pruss board specific additions.
In-Reply-To: <4D4944C6.5060406@mvista.com>
References: <4D4944C6.5060406@mvista.com>
Message-ID: <1296654736857-5984841.post@n2.nabble.com>


Hi Sergei,

Will change to da850_evm_setup_pruss and remove the extra print.

PS: If I don't enable "Quote, this is what the replies would look like. I am
not able to reply inline.
Please let me know how you are replying.

Thanks,
Subhasish
-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/Re-PATCH-v1-2-9-da850-pruss-board-specific-additions-tp5984483p5984841.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From michael.williamson at criticallink.com  Wed Feb  2 08:48:39 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 02 Feb 2011 09:48:39 -0500
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302487782C9@dbde02.ent.ti.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>	<4D494C6A.30507@mvista.com>
	<4D49543A.1070302@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302487782C9@dbde02.ent.ti.com>
Message-ID: <4D496EC7.1010808@criticallink.com>

On 2/2/2011 8:33 AM, Nori, Sekhar wrote:

> On Wed, Feb 02, 2011 at 18:25:22, Michael Williamson wrote:
> 
>>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>>>> index beda8a4..f421f97 100644
>>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>>> @@ -725,3 +725,99 @@ int __init da8xx_register_cpuidle(void)
>>>>
>>>>       return platform_device_register(&da8xx_cpuidle_device);
>>>>   }
>>>> +
>>>> +static struct resource da8xx_spi0_resources[] = {
>>>> +    [0] = {
>>>> +        .start    = 0x01c41000,
>>>> +        .end    = 0x01c41fff,
>>>> +        .flags    = IORESOURCE_MEM,
>>>> +    },
>>>> +    [1] = {
>>>> +        .start    = IRQ_DA8XX_SPINT0,
>>>> +        .end    = IRQ_DA8XX_SPINT0,
>>>> +        .flags    = IORESOURCE_IRQ,
>>>> +    },
>>>> +    [2] = {
>>>> +        .start    = EDMA_CTLR_CHAN(0, 14),
>>>> +        .end    = EDMA_CTLR_CHAN(0, 14),
>>>> +        .flags    = IORESOURCE_DMA,
>>>> +    },
>>>> +    [3] = {
>>>> +        .start    = EDMA_CTLR_CHAN(0, 15),
>>>> +        .end    = EDMA_CTLR_CHAN(0, 15),
>>>> +        .flags    = IORESOURCE_DMA,
>>>> +    },
>>>
>>>    We have DA830_DMACH_SPI0_[RT]X defined for SPI0 DMA channels...
>>>
>>
>>
>> Right.  The current routines/structures were designed to support either da830 or
>> da850.  They work because the interrupts and the DMA channels are fortunately
>> the same for the SPI devices between the platforms.  I can use the DA830 enums, 
>> but I had preferred the clarity of the EDMA_CTRL_CHAN macro, and it would 
>> remove confusion that this might only apply for DA830 and not DA850.  It would
>> be nice to rename that DA8XX_DMAC_SPI_[RT]X if the enums were used...
>>
>> Can I leave this, or do you really want me to use the enums?
>>
> 
> Looks like a bunch of cleaning-up needs to happen in this area.
> The DA830_DMACH_* are not used anywhere at all. Instead most of
> devices-da8xx.c uses DMA channel numbers directly (except for ASP,
> which has them defined in asp.h).
> 


I did a quick check, a large volume of the #defines in the asp.h file
are only used in the platform setup.  Wondering if they should really
be in that file at all...

> Since all the platform device definitions for DA8XX devices happens
> in devices-da8xx.c, it makes sense to get rid of the DA830_DMACH_*
> enum altogether and instead just define the channel numbers used in
> devices-da8xx.c above the actual usage.
> 
> Mike, is that something you are willing take-up?
> 


I can take this up as a separate patch series. I'd like to keep the 
spi platform support series isolated to that subject matter, if that's
OK.

> Thanks,
> Sekhar
> 



From vaibhav.bedia at ti.com  Wed Feb  2 08:54:04 2011
From: vaibhav.bedia at ti.com (Vaibhav Bedia)
Date: Wed,  2 Feb 2011 20:24:04 +0530
Subject: [PATCH] asoc: davinci: da830/omap-l138: correct cpu_dai_name
Message-ID: <1296658444-8836-1-git-send-email-vaibhav.bedia@ti.com>

McASP1 is used on the DA830/OMAP-L137 platform for the codec.
This is different from the DA850/OMAP-L138 platform which uses McASP0.

This is fixed by adding a new snd_soc_dai_link struct.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
---
 sound/soc/davinci/davinci-evm.c |   18 +++++++++++++++---
 1 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index b36f0b3..fe79842 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -218,7 +218,19 @@ static struct snd_soc_dai_link dm6467_evm_dai[] = {
 		.ops = &evm_spdif_ops,
 	},
 };
-static struct snd_soc_dai_link da8xx_evm_dai = {
+
+static struct snd_soc_dai_link da830_evm_dai = {
+	.name = "TLV320AIC3X",
+	.stream_name = "AIC3X",
+	.cpu_dai_name = "davinci-mcasp.1",
+	.codec_dai_name = "tlv320aic3x-hifi",
+	.codec_name = "tlv320aic3x-codec.1-0018",
+	.platform_name = "davinci-pcm-audio",
+	.init = evm_aic3x_init,
+	.ops = &evm_ops,
+};
+
+static struct snd_soc_dai_link da850_evm_dai = {
 	.name = "TLV320AIC3X",
 	.stream_name = "AIC3X",
 	.cpu_dai_name= "davinci-mcasp.0",
@@ -259,13 +271,13 @@ static struct snd_soc_card dm6467_snd_soc_card_evm = {
 
 static struct snd_soc_card da830_snd_soc_card = {
 	.name = "DA830/OMAP-L137 EVM",
-	.dai_link = &da8xx_evm_dai,
+	.dai_link = &da830_evm_dai,
 	.num_links = 1,
 };
 
 static struct snd_soc_card da850_snd_soc_card = {
 	.name = "DA850/OMAP-L138 EVM",
-	.dai_link = &da8xx_evm_dai,
+	.dai_link = &da850_evm_dai,
 	.num_links = 1,
 };
 
-- 
1.6.2.4


From nsekhar at ti.com  Wed Feb  2 09:37:08 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 2 Feb 2011 21:07:08 +0530
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D496EC7.1010808@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D494C6A.30507@mvista.com> <4D49543A.1070302@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302487782C9@dbde02.ent.ti.com>
	<4D496EC7.1010808@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024877837A@dbde02.ent.ti.com>

Hi Mike,

On Wed, Feb 02, 2011 at 20:18:39, Michael Williamson wrote:
 
> > Since all the platform device definitions for DA8XX devices happens
> > in devices-da8xx.c, it makes sense to get rid of the DA830_DMACH_*
> > enum altogether and instead just define the channel numbers used in
> > devices-da8xx.c above the actual usage.
> > 
> > Mike, is that something you are willing take-up?
> > 
> 
> 
> I can take this up as a separate patch series. I'd like to keep the 
> spi platform support series isolated to that subject matter, if that's
> OK.

Yes, the clean-up can be a separate series - but it will have to
precede the SPI series.

Thanks,
Sekhar


From sshtylyov at mvista.com  Wed Feb  2 09:51:58 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 18:51:58 +0300
Subject: [PATCH] asoc: davinci: da830/omap-l138: correct cpu_dai_name
In-Reply-To: <1296658444-8836-1-git-send-email-vaibhav.bedia@ti.com>
References: <1296658444-8836-1-git-send-email-vaibhav.bedia@ti.com>
Message-ID: <4D497D9E.9040201@mvista.com>

Hello.

Vaibhav Bedia wrote:

> McASP1 is used on the DA830/OMAP-L137 platform for the codec.
> This is different from the DA850/OMAP-L138 platform which uses McASP0.

    I guess that in the subject you meant to type "da830/omap-l137"?

> This is fixed by adding a new snd_soc_dai_link struct.

> Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>

WBR, Sergei


From nsekhar at ti.com  Wed Feb  2 09:54:58 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 2 Feb 2011 21:24:58 +0530
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <4D495929.40405@mvista.com>
References: <4D494625.4030503@mvista.com>
	<1296652212347-5984699.post@n2.nabble.com> <4D495929.40405@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930248778396@dbde02.ent.ti.com>

On Wed, Feb 02, 2011 at 18:46:25, Sergei Shtylyov wrote:

> >>> +static struct clk pruss_clk = {
> >>> +	.name		= "pruss",
> >>> +	.parent		= &pll0_sysclk2,
> >>> +	.lpsc		= DA8XX_LPSC0_DMAX,
> 
> >>      IIRC, you were asked to change/add a new name for what is known as
> >> DA8XX_LPSC0_DMAX...
> 
> >     [SG]  This macro is also getting used by arch/arm/mach-davinci/da830.c.
> > Hence, changing this is breaking the da830 build. Not sure how to go about
> > it.
> 
>     I suspect that dMAX is specific to DA830, and PRUSS is specific to DA850. 

DMAX is the same as PRUSS. PRUSS is what the module is referred
to in TI documentation so any reference to DMAX should be replaced
by PRUSS.

So just search and replace DA8XX_LPSC0_DMAX with DA8XX_LPSC0_PRUSS
in a pre-patch.

Thanks,
Sekhar


From vaibhav.bedia at ti.com  Wed Feb  2 09:55:55 2011
From: vaibhav.bedia at ti.com (Bedia, Vaibhav)
Date: Wed, 2 Feb 2011 21:25:55 +0530
Subject: [PATCH] asoc: davinci: da830/omap-l138: correct cpu_dai_name
In-Reply-To: <4D497D9E.9040201@mvista.com>
References: <1296658444-8836-1-git-send-email-vaibhav.bedia@ti.com>
	<4D497D9E.9040201@mvista.com>
Message-ID: <FCCFB4CDC6E5564B9182F639FC356087035FBEDD9B@dbde02.ent.ti.com>

?On Wednesday, February 02, 2011 9:22 PM, Sergei Shtylyov wrote:
> Hello.
> 
> Vaibhav Bedia wrote:
> 
>> McASP1 is used on the DA830/OMAP-L137 platform for the codec.
>> This is different from the DA850/OMAP-L138 platform which
>> uses McASP0. 
> 
>     I guess that in the subject you meant to type
> "da830/omap-l137"? 

Oops. Sorry. Will resend with correct subject.

Regards,
Vaibhav

From nsekhar at ti.com  Wed Feb  2 10:00:48 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 2 Feb 2011 21:30:48 +0530
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <1296652212347-5984699.post@n2.nabble.com>
References: <4D494625.4030503@mvista.com>
	<1296652212347-5984699.post@n2.nabble.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024877839B@dbde02.ent.ti.com>

Hi subhasish,

Please don't drop Linux ARM kernel list in your replies.

Thanks,
Sekhar


From nsekhar at ti.com  Wed Feb  2 10:13:51 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 2 Feb 2011 21:43:51 +0530
Subject: [PATCH v1 0/9] pruss mfd drivers
In-Reply-To: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59302487783A6@dbde02.ent.ti.com>

On Tue, Feb 01, 2011 at 20:17:38, Subhasish Ghosh wrote:

>  arch/arm/mach-davinci/board-da850-evm.c     |   75 ++
>  arch/arm/mach-davinci/da850.c               |   12 +
>  arch/arm/mach-davinci/devices-da8xx.c       |   65 ++
>  arch/arm/mach-davinci/include/mach/da8xx.h  |    2 +
>  arch/arm/mach-davinci/include/mach/mux.h    |    5 +
>  drivers/mfd/Kconfig                         |   10 +
>  drivers/mfd/Makefile                        |    1 +
>  drivers/mfd/da8xx_pru.c                     |  403 +++++++++
>  drivers/net/can/Kconfig                     |    1 +
>  drivers/net/can/Makefile                    |    1 +
>  drivers/net/can/da8xx_pruss/Kconfig         |   73 ++
>  drivers/net/can/da8xx_pruss/Makefile        |    7 +
>  drivers/net/can/da8xx_pruss/pruss_can.c     |  759 +++++++++++++++++
>  drivers/net/can/da8xx_pruss/pruss_can_api.c | 1224 

The MFD and netdev lists need to be copied on this submission
as this cannot be merged without an ack from the maintainers
of those subsystems.

To automate copying the right folks on each patch, please use:

git-send-email --to <davinci list> --cc-cmd=scripts/get_maintainer.pl  [...]

Thanks,
Sekhar


From sshtylyov at mvista.com  Wed Feb  2 10:15:51 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 19:15:51 +0300
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248778396@dbde02.ent.ti.com>
References: <4D494625.4030503@mvista.com>	<1296652212347-5984699.post@n2.nabble.com>
	<4D495929.40405@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778396@dbde02.ent.ti.com>
Message-ID: <4D498337.1000002@mvista.com>

Hello.

Nori, Sekhar wrote:

>>>>> +static struct clk pruss_clk = {
>>>>> +	.name		= "pruss",
>>>>> +	.parent		= &pll0_sysclk2,
>>>>> +	.lpsc		= DA8XX_LPSC0_DMAX,

>>>>      IIRC, you were asked to change/add a new name for what is known as
>>>> DA8XX_LPSC0_DMAX...

>>>     [SG]  This macro is also getting used by arch/arm/mach-davinci/da830.c.
>>> Hence, changing this is breaking the da830 build. Not sure how to go about
>>> it.

>>     I suspect that dMAX is specific to DA830, and PRUSS is specific to DA850. 

> DMAX is the same as PRUSS.

    Ah, indeed -- I've just read the preliminary documentation for DA830, and 
the description of dMAX looked the same as that one of PRU given in this patch set.

> PRUSS is what the module is referred to in TI documentation so any reference to DMAX should be replaced
> by PRUSS.

    Only perhaps DMAXss is the same as PRUSS, and dMAX is the same as PRU. BTW, 
could you refer me to that documentation you've referred to?

> So just search and replace DA8XX_LPSC0_DMAX with DA8XX_LPSC0_PRUSS
> in a pre-patch.

    Perhaps just DA8XX_LPSC0_PRU...

> Thanks,
> Sekhar

WBR, Sergei

From sshtylyov at mvista.com  Wed Feb  2 10:18:52 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 19:18:52 +0300
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <1296654292279-5984821.post@n2.nabble.com>
References: <4D494625.4030503@mvista.com>	<1296652212347-5984699.post@n2.nabble.com>	<4D495929.40405@mvista.com>
	<1296654292279-5984821.post@n2.nabble.com>
Message-ID: <4D4983EC.50404@mvista.com>

Hello.

subhasish wrote:

> I am using the mail interface at
> http://davinci-linux-open-source.1494791.n2.nabble.com/

> and I enable "Quote before replying. What interface are you using to reply.

   I'm just using my mail client, Thunderbird. :-)

> Actually, I was not subscribed to this mailing list, so it reported that my
> patches are pending approval of the ML moderator. I think you are using some
> other interface, so now this list contain only those patches to which you
> replied!!. 

> Will do the da830 changes, I was using ts=4 all throughout, so now complete
> code is misaligned!! Is there any easy was to fix this.

    Try scripts/cleanpatch, perhaps...

WBR, Sergei

From broonie at opensource.wolfsonmicro.com  Wed Feb  2 10:20:48 2011
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Wed, 2 Feb 2011 16:20:48 +0000
Subject: [PATCH v1 0/9] pruss mfd drivers
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302487783A6@dbde02.ent.ti.com>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302487783A6@dbde02.ent.ti.com>
Message-ID: <20110202162048.GF9810@sirena.org.uk>

On Wed, Feb 02, 2011 at 09:43:51PM +0530, Nori, Sekhar wrote:

> To automate copying the right folks on each patch, please use:

> git-send-email --to <davinci list> --cc-cmd=scripts/get_maintainer.pl  [...]

Please don't use get_maintainer.pl directly like this - you need to
apply some thought and consideration to the results as it generates both
false positives and false negatives.

From sshtylyov at mvista.com  Wed Feb  2 10:20:50 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 19:20:50 +0300
Subject: [PATCH v1 2/9] da850: pruss board specific additions.
In-Reply-To: <1296654736857-5984841.post@n2.nabble.com>
References: <4D4944C6.5060406@mvista.com>
	<1296654736857-5984841.post@n2.nabble.com>
Message-ID: <4D498462.3030801@mvista.com>

subhasish wrote:

> Will change to da850_evm_setup_pruss and remove the extra print.

> PS: If I don't enable "Quote, this is what the replies would look like. I am
> not able to reply inline.

    It's not clear why enabling quoting makes your own text quoted too...

> Please let me know how you are replying.

    Using my mail client, of course.

> Thanks,
> Subhasish

WBR, Sergei

From nsekhar at ti.com  Wed Feb  2 10:36:47 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 2 Feb 2011 22:06:47 +0530
Subject: [PATCH v1 0/9] pruss mfd drivers
In-Reply-To: <20110202162048.GF9810@sirena.org.uk>
References: <1296571667-12049-1-git-send-email-subhasish@mistralsolutions.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302487783A6@dbde02.ent.ti.com>
	<20110202162048.GF9810@sirena.org.uk>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59302487783CA@dbde02.ent.ti.com>

On Wed, Feb 02, 2011 at 21:50:48, Mark Brown wrote:
> On Wed, Feb 02, 2011 at 09:43:51PM +0530, Nori, Sekhar wrote:
> 
> > To automate copying the right folks on each patch, please use:
> 
> > git-send-email --to <davinci list> --cc-cmd=scripts/get_maintainer.pl  [...]
> 
> Please don't use get_maintainer.pl directly like this - you need to
> apply some thought and consideration to the results as it generates both
> false positives and false negatives.

Point taken. I usually do a --dry-run before actually sending
just to verify the results.

Thanks,
Sekhar


From nsekhar at ti.com  Wed Feb  2 10:46:21 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 2 Feb 2011 22:16:21 +0530
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <4D498337.1000002@mvista.com>
References: <4D494625.4030503@mvista.com>
	<1296652212347-5984699.post@n2.nabble.com> <4D495929.40405@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778396@dbde02.ent.ti.com>
	<4D498337.1000002@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59302487783D6@dbde02.ent.ti.com>

Hi Sergei,

On Wed, Feb 02, 2011 at 21:45:51, Sergei Shtylyov wrote:

> could you refer me to that documentation you've referred to?

All the OMAP-L138 documentation is here: 
http://focus.ti.com/docs/prod/folders/print/omap-l138.html

> 
> > So just search and replace DA8XX_LPSC0_DMAX with DA8XX_LPSC0_PRUSS
> > in a pre-patch.
> 
>     Perhaps just DA8XX_LPSC0_PRU...

No, PRUSS is how the LPSC is referred to as in the datasheet
(page 109 of http://focus.ti.com/lit/ds/symlink/omap-l138.pdf)

Thanks,
Sekhar


From urwithsughosh at gmail.com  Wed Feb  2 11:53:14 2011
From: urwithsughosh at gmail.com (Sughosh Ganu)
Date: Wed,  2 Feb 2011 23:23:14 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
Message-ID: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>

The omapl-138 based hawkboard comes with a 128MiB Nand Flash. Add
support for the same.

Signed-off-by: Sughosh Ganu <urwithsughosh at gmail.com>
---
 arch/arm/mach-davinci/Kconfig               |   10 +++
 arch/arm/mach-davinci/board-omapl138-hawk.c |   95 +++++++++++++++++++++++++++
 2 files changed, 105 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 32f1479..e13b7e0 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
 config MACH_OMAPL138_HAWKBOARD
 	bool "TI AM1808 / OMAPL-138 Hawkboard platform"
 	depends on ARCH_DAVINCI_DA850
+	select MTD
+	select MTD_PARTITIONS
+	select MTD_CHAR
+	select MTD_BLKDEVS
+	select MTD_BLOCK
+	select MTD_PHYSMAP
+	select MTD_CFI
+	select MTD_NAND
+	select MTD_NAND_IDS
+	select MTD_NAND_DAVINCI
 	help
 	  Say Y here to select the TI AM1808 / OMAPL-138 Hawkboard platform .
 	  Information of this board may be found at
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 67c38d0..eac2d69 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -13,6 +13,10 @@
 #include <linux/init.h>
 #include <linux/console.h>
 #include <linux/gpio.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -20,6 +24,7 @@
 #include <mach/cp_intc.h>
 #include <mach/da8xx.h>
 #include <mach/mux.h>
+#include <mach/nand.h>
 
 #define HAWKBOARD_PHY_ID		"0:07"
 #define DA850_HAWK_MMCSD_CD_PIN		GPIO_TO_PIN(3, 12)
@@ -28,6 +33,81 @@
 #define DA850_USB1_VBUS_PIN		GPIO_TO_PIN(2, 4)
 #define DA850_USB1_OC_PIN		GPIO_TO_PIN(6, 13)
 
+static struct mtd_partition omapl_hawk_nandflash_partition[] = {
+	{
+		.name		= "u-boot env",
+		.offset		= 0,
+		.size		= SZ_128K,
+		.mask_flags	= MTD_WRITEABLE,
+	 },
+	{
+		.name		= "nand_spl",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_128K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	{
+		.name		= "u-boot",
+		.offset		= 0xe0000,
+		.size		= 2 * SZ_128K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	{
+		.name		= "kernel",
+		.offset		= 0x200000,
+		.size		= SZ_2M,
+		.mask_flags	= 0,
+	},
+	{
+		.name		= "filesystem",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0,
+	},
+};
+
+static struct davinci_nand_pdata omapl_hawk_nandflash_data = {
+	.parts		= omapl_hawk_nandflash_partition,
+	.nr_parts	= ARRAY_SIZE(omapl_hawk_nandflash_partition),
+	.ecc_mode	= NAND_ECC_HW,
+	.ecc_bits	= 4,
+	.options	= NAND_USE_FLASH_BBT,
+};
+
+static struct resource omapl_hawk_nandflash_resource[] = {
+	{
+		.start	= DA8XX_AEMIF_CS3_BASE,
+		.end	= DA8XX_AEMIF_CS3_BASE + PAGE_SIZE - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.start	= DA8XX_AEMIF_CTL_BASE,
+		.end	= DA8XX_AEMIF_CTL_BASE + SZ_32K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device omapl_hawk_nandflash_device = {
+	.name		= "davinci_nand",
+	.id		= 1,
+	.dev		= {
+		.platform_data	= &omapl_hawk_nandflash_data,
+	},
+	.num_resources	= ARRAY_SIZE(omapl_hawk_nandflash_resource),
+	.resource	= omapl_hawk_nandflash_resource,
+};
+
+static struct platform_device *omapl_hawk_devices[] __initdata = {
+	&omapl_hawk_nandflash_device,
+};
+
+static const short omapl_hawk_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_WE,
+	DA850_NEMA_OE, -1
+};
+
 static short omapl138_hawk_mii_pins[] __initdata = {
 	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,
@@ -37,6 +117,19 @@ static short omapl138_hawk_mii_pins[] __initdata = {
 	-1
 };
 
+static void omapl_hawk_nand_setup(void)
+{
+	int ret = 0;
+
+	ret = davinci_cfg_reg_list(omapl_hawk_nand_pins);
+	if (ret)
+		pr_warning("da850_evm_init: nand mux setup failed: "
+			   "%d\n", ret);
+
+	platform_add_devices(omapl_hawk_devices,
+			     ARRAY_SIZE(omapl_hawk_devices));
+}
+
 static __init void omapl138_hawk_config_emac(void)
 {
 	void __iomem *cfgchip3 = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
@@ -314,6 +407,8 @@ static __init void omapl138_hawk_init(void)
 
 	omapl138_hawk_usb_init();
 
+	omapl_hawk_nand_setup();
+
 	ret = da8xx_register_watchdog();
 	if (ret)
 		pr_warning("omapl138_hawk_init: "
-- 
1.7.0.4


From sshtylyov at mvista.com  Wed Feb  2 12:22:22 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 21:22:22 +0300
Subject: [PATCH v1 3/9] da850: pruss platform specific additions.
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302487783D6@dbde02.ent.ti.com>
References: <4D494625.4030503@mvista.com>	<1296652212347-5984699.post@n2.nabble.com>
	<4D495929.40405@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778396@dbde02.ent.ti.com>
	<4D498337.1000002@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302487783D6@dbde02.ent.ti.com>
Message-ID: <4D49A0DE.8010100@mvista.com>

Hello.

Nori, Sekhar wrote:

>> could you refer me to that documentation you've referred to?

> All the OMAP-L138 documentation is here: 
> http://focus.ti.com/docs/prod/folders/print/omap-l138.html

>>> So just search and replace DA8XX_LPSC0_DMAX with DA8XX_LPSC0_PRUSS
>>> in a pre-patch.
>>     Perhaps just DA8XX_LPSC0_PRU...

> No, PRUSS is how the LPSC is referred to as in the datasheet
> (page 109 of http://focus.ti.com/lit/ds/symlink/omap-l138.pdf)

    Thanks. Looks like I had an obsolete version of that...

> Thanks,
> Sekhar

WBR, Sergei

From juha.kuikka at gmail.com  Wed Feb  2 12:45:08 2011
From: juha.kuikka at gmail.com (Juha Kuikka)
Date: Wed, 2 Feb 2011 10:45:08 -0800
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
Message-ID: <AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>

On Wed, Feb 2, 2011 at 9:53 AM, Sughosh Ganu <urwithsughosh at gmail.com>wrote:

> The omapl-138 based hawkboard comes with a 128MiB Nand Flash. Add
> support for the same.
>
> Signed-off-by: Sughosh Ganu <urwithsughosh at gmail.com>
> ---
>  arch/arm/mach-davinci/Kconfig               |   10 +++
>  arch/arm/mach-davinci/board-omapl138-hawk.c |   95
> +++++++++++++++++++++++++++
>  2 files changed, 105 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 32f1479..e13b7e0 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>  config MACH_OMAPL138_HAWKBOARD
>        bool "TI AM1808 / OMAPL-138 Hawkboard platform"
>        depends on ARCH_DAVINCI_DA850
> +       select MTD
> +       select MTD_PARTITIONS
> +       select MTD_CHAR
> +       select MTD_BLKDEVS
> +       select MTD_BLOCK
> +       select MTD_PHYSMAP
> +       select MTD_CFI
>


I don't think CFI is necessary for NAND?

 - Juha

-- 
Duck tape is like the force, it has a light side and a dark side and it
holds the universe together.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110202/32dcf9bd/attachment.html>

From sshtylyov at mvista.com  Wed Feb  2 14:00:13 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 02 Feb 2011 23:00:13 +0300
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
Message-ID: <4D49B7CD.9090006@mvista.com>

Hello.

Juha Kuikka wrote:

>     The omapl-138 based hawkboard comes with a 128MiB Nand Flash. Add
>     support for the same.

>     Signed-off-by: Sughosh Ganu <urwithsughosh at gmail.com>
[...]

>     diff --git a/arch/arm/mach-davinci/Kconfig
>     b/arch/arm/mach-davinci/Kconfig
>     index 32f1479..e13b7e0 100644
>     --- a/arch/arm/mach-davinci/Kconfig
>     +++ b/arch/arm/mach-davinci/Kconfig
>     @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>      config MACH_OMAPL138_HAWKBOARD
>            bool "TI AM1808 / OMAPL-138 Hawkboard platform"
>            depends on ARCH_DAVINCI_DA850
>     +       select MTD
>     +       select MTD_PARTITIONS
>     +       select MTD_CHAR
>     +       select MTD_BLKDEVS
>     +       select MTD_BLOCK
>     +       select MTD_PHYSMAP
>     +       select MTD_CFI

> I don't think CFI is necessary for NAND?

    Neither is the 'physmap' driver. And all this part of the patch looks 
completely bogus.

>  - Juha

WBR, Sergei


From urwithsughosh at gmail.com  Thu Feb  3 00:55:42 2011
From: urwithsughosh at gmail.com (sughosh ganu)
Date: Thu, 3 Feb 2011 12:25:42 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <4D49B7CD.9090006@mvista.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
Message-ID: <AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>

hi,

On Thu, Feb 3, 2011 at 1:30 AM, Sergei Shtylyov <sshtylyov at mvista.com>wrote:

> Hello.
>
>>    diff --git a/arch/arm/mach-davinci/Kconfig
>>    b/arch/arm/mach-davinci/Kconfig
>>    index 32f1479..e13b7e0 100644
>>    --- a/arch/arm/mach-davinci/Kconfig
>>    +++ b/arch/arm/mach-davinci/Kconfig
>>    @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>>     config MACH_OMAPL138_HAWKBOARD
>>           bool "TI AM1808 / OMAPL-138 Hawkboard platform"
>>           depends on ARCH_DAVINCI_DA850
>>    +       select MTD
>>    +       select MTD_PARTITIONS
>>    +       select MTD_CHAR
>>    +       select MTD_BLKDEVS
>>    +       select MTD_BLOCK
>>    +       select MTD_PHYSMAP
>>    +       select MTD_CFI
>>
>
>  I don't think CFI is necessary for NAND?
>>
>
>   Neither is the 'physmap' driver. And all this part of the patch looks
> completely bogus.
>

I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest of the
options for mtd related stuff. I guess i can include these in the same
patch. Will come up with an updated revision. Thanks.

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

From nsekhar at ti.com  Thu Feb  3 01:47:07 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 3 Feb 2011 13:17:07 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>

Hi sughosh,

On Thu, Feb 03, 2011 at 12:25:42, sughosh ganu wrote:
> hi,
> 
> 
> On Thu, Feb 3, 2011 at 1:30 AM, Sergei Shtylyov <sshtylyov at mvista.com>
> wrote:
> 
> 
> 	Hello.
> 
> 		   diff --git a/arch/arm/mach-davinci/Kconfig
> 		   b/arch/arm/mach-davinci/Kconfig
> 		   index 32f1479..e13b7e0 100644
> 		   --- a/arch/arm/mach-davinci/Kconfig
> 		   +++ b/arch/arm/mach-davinci/Kconfig
> 		   @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
> 		    config MACH_OMAPL138_HAWKBOARD
> 		          bool "TI AM1808 / OMAPL-138 Hawkboard
> platform"
> 		          depends on ARCH_DAVINCI_DA850
> 		   +       select MTD
> 		   +       select MTD_PARTITIONS
> 		   +       select MTD_CHAR
> 		   +       select MTD_BLKDEVS
> 		   +       select MTD_BLOCK
> 		   +       select MTD_PHYSMAP
> 		   +       select MTD_CFI
> 		
> 
> 
> 		I don't think CFI is necessary for NAND?
> 		
> 
> 
> 	  Neither is the 'physmap' driver. And all this part of the
> patch looks completely bogus.
> 	
> 
> 
> I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest of the
> options for mtd related stuff. I guess i can include these in the same
> patch. Will come up with an updated revision. Thanks.

Why do you need to select these through Kconfig. Why cant these
be enabled/disabled by users using menuconfig?

Thanks,
Sekhar


From urwithsughosh at gmail.com  Thu Feb  3 02:39:47 2011
From: urwithsughosh at gmail.com (sughosh ganu)
Date: Thu, 3 Feb 2011 14:09:47 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
Message-ID: <AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>

hi Sekhar,

On Thu, Feb 3, 2011 at 1:17 PM, Nori, Sekhar <nsekhar at ti.com> wrote:

> >                  diff --git a/arch/arm/mach-davinci/Kconfig
> >                  b/arch/arm/mach-davinci/Kconfig
> >                  index 32f1479..e13b7e0 100644
> >                  --- a/arch/arm/mach-davinci/Kconfig
> >                  +++ b/arch/arm/mach-davinci/Kconfig
> >                  @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
> >                   config MACH_OMAPL138_HAWKBOARD
> >                         bool "TI AM1808 / OMAPL-138 Hawkboard
> > platform"
> >                         depends on ARCH_DAVINCI_DA850
> >                  +       select MTD
> >                  +       select MTD_PARTITIONS
> >                  +       select MTD_CHAR
> >                  +       select MTD_BLKDEVS
> >                  +       select MTD_BLOCK
> >                  +       select MTD_PHYSMAP
> >                  +       select MTD_CFI
> >
> >
> >
> >               I don't think CFI is necessary for NAND?
> >
> >
> >
> >         Neither is the 'physmap' driver. And all this part of the
> > patch looks completely bogus.
> >
> >
> >
> > I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest of the
> > options for mtd related stuff. I guess i can include these in the same
> > patch. Will come up with an updated revision. Thanks.
>
> Why do you need to select these through Kconfig. Why cant these
> be enabled/disabled by users using menuconfig?
>

Since the hawkboard comes with a default Nand chip, i thought these could be
part of the default config. But i see that these configs are not defined for
for other ARM boards(except PXA). In that case, i can remove these configs
from the deault. Thanks.

-sughosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110203/352416e9/attachment-0001.html>

From jon.povey at racelogic.co.uk  Thu Feb  3 03:10:33 2011
From: jon.povey at racelogic.co.uk (Jon Povey)
Date: Thu,  3 Feb 2011 18:10:33 +0900
Subject: [RFC] mmc: davinci: fix corruption after surprise card eject
Message-ID: <1296724233-3903-1-git-send-email-jon.povey@racelogic.co.uk>

Ejecting a card during a write results in a bad controller state which
corrupts all writes to subsequently inserted cards.

Work around this by resetting the controller in the set_ios() POWER_OFF
handler.

Tested on DM355.

Signed-off-by: Jon Povey <jon.povey at racelogic.co.uk>
---

This patch is against 2.6.36, it does not include the latest SDIO patch
at least.

To reproduce this in the unpatched sources, write heavily to the card
and eject it during a write. Note that for the first few seconds of
"writing a file" nothing is actually written to the card, it is cached
by Linux.

In the broken state that results, if a card is reinserted, the effect
is as if an internal write FIFO has not been cleared and contains 2
extra bytes. Tests suggest this is not the documented 32-byte FIFO but
something beyond that.
All blocks appear on the card starting with the last two bytes of the
previous block write, then the remaining sector data; the last two
bytes overflow into the next written sector, etc.

Toggling MMCCTL.CMDRST,DATRST clears this condition. These are toggled
several times during the error handlers called when the card is ejected
during write, but it seems the bad state is entered at some point later.

set_ios(MMC_POWER_OFF) seems to consistently be called at the end of
the cleanup process before a newly-inserted card is accessed, putting
an extra controller reset in here gets rid of the problem - but I'm not
sure this is the right way to fix this, it has a workaround feel.

Comments sought.. thanks.

---
 drivers/mmc/host/davinci_mmc.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 33d9f1b..e5ee1c1 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -795,6 +795,9 @@ static void calculate_clk_divider(struct mmc_host *mmc, struct mmc_ios *ios)
 	}
 }
 
+static void
+davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data);
+
 static void mmc_davinci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 {
 	struct mmc_davinci_host *host = mmc_priv(mmc);
@@ -856,9 +859,14 @@ static void mmc_davinci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 		}
 		if (lose)
 			dev_warn(mmc_dev(host->mmc), "powerup timeout\n");
-	}
 
-	/* FIXME on power OFF, reset things ... */
+	} else if (ios->power_mode == MMC_POWER_OFF) {
+
+		/* Controller maybe in bad state, e.g. card pulled while writing */
+		davinci_abort_data(host, NULL);
+
+		/* FIXME on power OFF, reset more things ...? */
+	}
 }
 
 static void
-- 
1.6.3.3


From adityabarawkar at gmail.com  Thu Feb  3 03:11:49 2011
From: adityabarawkar at gmail.com (Aditya Barawkar)
Date: Thu, 3 Feb 2011 14:41:49 +0530
Subject: boot through tftp
Message-ID: <AANLkTimp0M=26RAAEVv3MachA3NCCPBHjAjqs4Oikt72@mail.gmail.com>

hi,
We are using a DM6446 EVM.
 We have compiled a kernel for the board, in which we enabled various
drivers required(through make menuconfig)

Now we want the kernel to be booted via tftp(unlike what is default booting
from flash) and the filesys will be nfs as usual.

the bootargs for the tftp are as follows...(as given in the texas getting
started guide)

EVM  # setenv bootcmd 'dhcp;bootm'
EVM  # setenv serverip <tftp server ip address>
EVM  # setenv bootfile <name of kernel image>
EVM  # setenv rootpath <root directory to mount>
EVM  # setenv nfshost <ip address of nfs host>
EVM  # setenv bootargs video=davincifb:vid0=720x576x16,
    2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K
    davinci_enc_mngr.ch0_output=COMPOSITE
    davinci_enc_mngr.ch0_mode=$(videostd)
   console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs
    nfsroot=$(nfshost):$(rootpath),nolock mem=120M



but when we boot the board we get following error:

Unknown command 'dhcp' - try 'help'

and the kernel boots from flash as default.



TirDavinci_EVM# printenv
bootdelay=3
baudrate=115200
ethaddr=ff:ff:ff:ff:ff:ff
ipaddr=192.168.0.51
nfshost=10.42.43.1
rootpath=/home/aditya/workdir/filesys
serverip=10.42.43.1
bootargs=video=davincifb:vid0=
720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K
davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=NTSC
console=ttyS0,11M
bootfile=/var/lib/tftpboot/uImage
bootcmd=dhcp;bootm         * <<<---------------For boot through tftp
(refering to section 4.7 , A.4.4  in getting started guide..sprue66d.pdf)*
stdin=serial
stdout=serial
stderr=serial

Environment size: 526/8188 bytes



TirDavinci_EVM# boot
Unknown command 'dhcp' - try 'help'
*<<<---------------dhcp
command not recognised by uboot*
## Booting image at 02050000 ...
   Image Name:   Linux-2.6.10_mvl401-davinci_evm
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1324188 Bytes =  1.3 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting Davinci linux kernel...

Uncompressing
Linux..................................................................................................
done, booting thee



and the orignal kernel is booted...


Also we are confused on
1) can we boot the kernel through tftp without copying the image into the
memory of target?? or we necessarily have to copy the image into the memory
of target and then boot??

2)we have searched on booting via tftp...and we found that lot of people use
following command::
tftp 0x80700000 uImage
will this command write the new "uImage" to 0x80700000 on the target?
what is the address 0x80700000 pointing to?
will my orignal kernel get affected if we write to this address?



thanks in advace!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110203/8bd71e6d/attachment.html>

From Jon.Povey at racelogic.co.uk  Thu Feb  3 03:15:28 2011
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Thu, 3 Feb 2011 09:15:28 +0000
Subject: Intermittent SD write corruption on DM355, kernel 2.6.36
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE093F9AEA5C@Cloud.RL.local>

>>>> Jon Povey wrote:
>>>>> I am seeing rare SD card write corruption on DM355

I think I have a fix for this now - just CC'd you on the patch RFC

[RFC] mmc: davinci: fix corruption after surprise card eject

(Which fixes it, but may not be the best way of going about it).

--
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 urwithsughosh at gmail.com  Thu Feb  3 03:19:00 2011
From: urwithsughosh at gmail.com (sughosh ganu)
Date: Thu, 3 Feb 2011 14:49:00 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
Message-ID: <AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>

hi Sekhar,

On Thu, Feb 3, 2011 at 2:09 PM, sughosh ganu <urwithsughosh at gmail.com>wrote:

> hi Sekhar,
>
>
> On Thu, Feb 3, 2011 at 1:17 PM, Nori, Sekhar <nsekhar at ti.com> wrote:
>
>> >                  diff --git a/arch/arm/mach-davinci/Kconfig
>> >                  b/arch/arm/mach-davinci/Kconfig
>> >                  index 32f1479..e13b7e0 100644
>> >                  --- a/arch/arm/mach-davinci/Kconfig
>> >                  +++ b/arch/arm/mach-davinci/Kconfig
>> >                  @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>> >                   config MACH_OMAPL138_HAWKBOARD
>> >                         bool "TI AM1808 / OMAPL-138 Hawkboard
>> > platform"
>> >                         depends on ARCH_DAVINCI_DA850
>> >                  +       select MTD
>> >                  +       select MTD_PARTITIONS
>> >                  +       select MTD_CHAR
>> >                  +       select MTD_BLKDEVS
>> >                  +       select MTD_BLOCK
>> >                  +       select MTD_PHYSMAP
>> >                  +       select MTD_CFI
>> >
>> >
>> >
>> >               I don't think CFI is necessary for NAND?
>> >
>> >
>> >
>> >         Neither is the 'physmap' driver. And all this part of the
>> > patch looks completely bogus.
>> >
>> >
>> >
>> > I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest of the
>> > options for mtd related stuff. I guess i can include these in the same
>> > patch. Will come up with an updated revision. Thanks.
>>
>> Why do you need to select these through Kconfig. Why cant these
>> be enabled/disabled by users using menuconfig?
>>
>
> Since the hawkboard comes with a default Nand chip, i thought these could
> be part of the default config. But i see that these configs are not defined
> for for other ARM boards(except PXA). In that case, i can remove these
> configs from the deault. Thanks.
>

Looking through the defconfigs, looks like a lot of boards define the
configs for MTD as default. Given that the hawkboard comes with a Nand
flash, i think the above change can stay. Please let me know, and i will
respin my patch accordingly.

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

From jp.francois at cynove.com  Thu Feb  3 03:28:08 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Thu, 3 Feb 2011 10:28:08 +0100
Subject: Recent kernel for DM365 and status of the staging tree
Message-ID: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>

Hi,

What is the status of the arago staging tree ?
It once was tracking the mainline kernel without much lag, but
it seems to be stuck at 2.6.34

I am interested in :
- video capture
- single-shot previewer operation
- cmem, edma and all other DVSDK modules can build against it
- video display (optional)
- OSD (optional)

I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
or older kernel, because I am interested
in the uvc gadget driver.

What tree could be a good starting point for this ?

From jp.francois at cynove.com  Thu Feb  3 03:32:36 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Thu, 3 Feb 2011 10:32:36 +0100
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
Message-ID: <AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>

2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
> Hi,
>
> What is the status of the arago staging tree ?
> It once was tracking the mainline kernel without much lag, but
> it seems to be stuck at 2.6.34
>
> I am interested in :
> - video capture
Both bayer and YUV, using USERPTR IO

> - single-shot previewer operation
> - cmem, edma and all other DVSDK modules can build against it
> - video display (optional)
> - OSD (optional)
>
> I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
> or older kernel, because I am interested
> in the uvc gadget driver.
>
> What tree could be a good starting point for this ?
>

From c.aeschlimann at acn-group.ch  Thu Feb  3 03:38:39 2011
From: c.aeschlimann at acn-group.ch (Christophe Aeschlimann)
Date: Thu, 03 Feb 2011 10:38:39 +0100
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
Message-ID: <4D4A779F.8030305@acn-group.ch>

Hi,

I'm working with the arago omapl1 kernel on a custom OMAP-L138 board.

http://arago-project.org/git/projects/?p=linux-omapl1.git

Recently I made some testing with the PREEMPT_RT patches (that were also
applied in a branch in the arago kernel). The Kernel seems to behave
correctly but I have issues with the GPIO interface. E.G. I'm using the
"gpio-keys" and "matrix-keypad" drivers and they don't behave correctly.
The symptoms are :

Just after boot, I can press a button attached to a GPIO and get an
event through the input subsystem, but after a few presses (few being
random) the button doesn't generate an event any-more. (the interrupt is
also not reported in /proc/interrupts).

By browsing the mailing list archives I saw these old patches for the
davinci tree and the omap tree :

http://linux.omap.com/pipermail/davinci-linux-open-source/2007-October/004283.html

http://marc.info/?l=linux-omap&m=119634477133936&w=2

(both are also listed here
https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch)

Of course quite a lot of things changed since 2.6.23 so it's difficult
to just adapt the patches (I don't even know if they are still required
or if I'm facing another issue).

Anyway just wanted to know if someone is having the same issues or if
there is a new version of the patches for the latest davinci kernel that
I may have missed.

Thank you,

Christophe

-- 
Christophe Aeschlimann

Embedded Software Engineer

ACN 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 subhranil.choudhury at ittiam.com  Thu Feb  3 03:44:35 2011
From: subhranil.choudhury at ittiam.com (Subhranil Choudhury)
Date: Thu, 3 Feb 2011 15:14:35 +0530
Subject: boot through tftp
In-Reply-To: <AANLkTimp0M=26RAAEVv3MachA3NCCPBHjAjqs4Oikt72@mail.gmail.com>
References: <AANLkTimp0M=26RAAEVv3MachA3NCCPBHjAjqs4Oikt72@mail.gmail.com>
Message-ID: <5052CF0C8A1F6A42954B0191C11C4F6202BACE374D@is01mx01>

Hey Aditya,
You can use the bootarguments as
setenv serverip <tftp server ip address>
setenv serverip <tftp board ip address>
setenv bootcmd tftp 0x80700000 uImage_teleste \;bootm 0x80700000

Please make sure that the tftp server and board ip address are in the same subnet mask.

Remarks on you confusion:

Also we are confused on
1) can we boot the kernel through tftp without copying the image into the memory of target?? or we necessarily have to copy the image into the memory of target and then boot??
---------------- Whatever might be the source or uImage(flash/nfs/tftp), the image will be copied to DDR first and un-compressed there and then the board will boot from there.

2)we have searched on booting via tftp...and we found that lot of people use following command::
tftp 0x80700000 uImage
will this command write the new "uImage" to 0x80700000 on the target?
what is the address 0x80700000 pointing to?
will my orignal kernel get affected if we write to this address?
-------------------------------
This command will write the uImage to location 0x80700000 of DDR.
Your original kernel is present in NAND/NOR flash of 6446 EVM. The image in flash will also be copied into the same location of DDR before booting.
Using TFTP you will copy the uImage into 0x80700000 location of DDR and flash where your actual image is present is no-where coming into picture.
So, in case of TFTP instead of flash you are copying the image from the tftp server. This is the only difference.









Subhranil.


From: davinci-linux-open-source-bounces+subhranil.choudhury=ittiam.com at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+subhranil.choudhury=ittiam.com at linux.davincidsp.com] On Behalf Of Aditya Barawkar
Sent: Thursday, February 03, 2011 2:42 PM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: boot through tftp

hi,
We are using a DM6446 EVM.
 We have compiled a kernel for the board, in which we enabled various drivers required(through make menuconfig)

Now we want the kernel to be booted via tftp(unlike what is default booting from flash) and the filesys will be nfs as usual.

the bootargs for the tftp are as follows...(as given in the texas getting started guide)

EVM  # setenv bootcmd 'dhcp;bootm'
EVM  # setenv serverip <tftp server ip address>
EVM  # setenv bootfile <name of kernel image>
EVM  # setenv rootpath <root directory to mount>
EVM  # setenv nfshost <ip address of nfs host>
EVM  # setenv bootargs video=davincifb:vid0=720x576x16,
    2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K
    davinci_enc_mngr.ch0_output=COMPOSITE
    davinci_enc_mngr.ch0_mode=$(videostd)
   console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs
    nfsroot=$(nfshost):$(rootpath),nolock mem=120M



but when we boot the board we get following error:

Unknown command 'dhcp' - try 'help'

and the kernel boots from flash as default.



TirDavinci_EVM# printenv
bootdelay=3
baudrate=115200
ethaddr=ff:ff:ff:ff:ff:ff
ipaddr=192.168.0.51
nfshost=10.42.43.1
rootpath=/home/aditya/workdir/filesys
serverip=10.42.43.1
bootargs=video=davincifb:vid0=
720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=NTSC console=ttyS0,11M
bootfile=/var/lib/tftpboot/uImage
bootcmd=dhcp;bootm          <<<---------------For boot through tftp (refering to section 4.7 , A.4.4  in getting started guide..sprue66d.pdf)
stdin=serial
stdout=serial
stderr=serial

Environment size: 526/8188 bytes



TirDavinci_EVM# boot
Unknown command 'dhcp' - try 'help'                         <<<---------------dhcp command not recognised by uboot
## Booting image at 02050000 ...
   Image Name:   Linux-2.6.10_mvl401-davinci_evm
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1324188 Bytes =  1.3 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting Davinci linux kernel...

Uncompressing Linux.................................................................................................. done, booting thee


and the orignal kernel is booted...


Also we are confused on
1) can we boot the kernel through tftp without copying the image into the memory of target?? or we necessarily have to copy the image into the memory of target and then boot??

2)we have searched on booting via tftp...and we found that lot of people use following command::
tftp 0x80700000 uImage
will this command write the new "uImage" to 0x80700000 on the target?
what is the address 0x80700000 pointing to?
will my orignal kernel get affected if we write to this address?



thanks in advace!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110203/eb0301fc/attachment.html>

From msponchiado at ciellecnc.com  Thu Feb  3 03:57:22 2011
From: msponchiado at ciellecnc.com (Michele Sponchiado)
Date: Thu, 3 Feb 2011 10:57:22 +0100
Subject: R: boot through tftp
In-Reply-To: <AANLkTimp0M=26RAAEVv3MachA3NCCPBHjAjqs4Oikt72@mail.gmail.com>
References: <AANLkTimp0M=26RAAEVv3MachA3NCCPBHjAjqs4Oikt72@mail.gmail.com>
Message-ID: <006501cbc388$c0a7c4a0$41f74de0$@com>

To boot via tftp, on OMAP_L137_EVM I set the bootcmd env variable like this:
bootcmd=tftp;bootm
 
 
here a printout of my tftp working environment:
bootdelay=3
baudrate=115200
ethaddr=00:0e:99:02:fd:82
filesize=1B8994
fileaddr=C0700000
rootpath=/home/bagside/workdir/filesys
bootfile=uImage
serverip=192.168.0.198
ipaddr=192.168.0.199
nfshost=192.168.0.198
bootcmd=tftp;bootm
bootargs=console=ttyS2,115200n8 noinitrd rw ip=dhcp root=/dev/nfs
nfsroot=192.168.0.198:/home/bagside/workdir/filesys,nolock mem=32M
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 1.3.3 (Apr 23 2009 - 17:32:00)
 
Da:
davinci-linux-open-source-bounces+msponchiado=ciellecnc.com at linux.davincidsp
.com
[mailto:davinci-linux-open-source-bounces+msponchiado=ciellecnc.com at linux.da
vincidsp.com] Per conto di Aditya Barawkar
Inviato: gioved? 3 febbraio 2011 10.12
A: davinci-linux-open-source at linux.davincidsp.com
Oggetto: boot through tftp
 
hi,
We are using a DM6446 EVM.
 We have compiled a kernel for the board, in which we enabled various
drivers required(through make menuconfig)

Now we want the kernel to be booted via tftp(unlike what is default booting
from flash) and the filesys will be nfs as usual.

the bootargs for the tftp are as follows...(as given in the texas getting
started guide)

EVM  # setenv bootcmd 'dhcp;bootm'
EVM  # setenv serverip <tftp server ip address>
EVM  # setenv bootfile <name of kernel image>
EVM  # setenv rootpath <root directory to mount>
EVM  # setenv nfshost <ip address of nfs host>
EVM  # setenv bootargs video=davincifb:vid0=720x576x16,
    2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K
    davinci_enc_mngr.ch0_output=COMPOSITE
    davinci_enc_mngr.ch0_mode=$(videostd)
   console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs
    nfsroot=$(nfshost):$(rootpath),nolock mem=120M



but when we boot the board we get following error:

Unknown command 'dhcp' - try 'help'

and the kernel boots from flash as default.



TirDavinci_EVM# printenv
bootdelay=3
baudrate=115200
ethaddr=ff:ff:ff:ff:ff:ff
ipaddr=192.168.0.51
nfshost=10.42.43.1
rootpath=/home/aditya/workdir/filesys
serverip=10.42.43.1
bootargs=video=davincifb:vid0=
720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K
davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=NTSC
console=ttyS0,11M
bootfile=/var/lib/tftpboot/uImage
bootcmd=dhcp;bootm          <<<---------------For boot through tftp
(refering to section 4.7 , A.4.4  in getting started guide..sprue66d.pdf)
stdin=serial
stdout=serial
stderr=serial

Environment size: 526/8188 bytes



TirDavinci_EVM# boot
Unknown command 'dhcp' - try 'help'
<<<---------------dhcp command not recognised by uboot
## Booting image at 02050000 ...
   Image Name:   Linux-2.6.10_mvl401-davinci_evm
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1324188 Bytes =  1.3 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting Davinci linux kernel...

Uncompressing
Linux.......................................................................
........................... done, booting thee
 


and the orignal kernel is booted...


Also we are confused on 
1) can we boot the kernel through tftp without copying the image into the
memory of target?? or we necessarily have to copy the image into the memory
of target and then boot??

2)we have searched on booting via tftp...and we found that lot of people use
following command::
tftp 0x80700000 uImage
will this command write the new "uImage" to 0x80700000 on the target?
what is the address 0x80700000 pointing to?
will my orignal kernel get affected if we write to this address?



thanks in advace!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110203/9a76cb3a/attachment-0001.html>

From vaibhav.bedia at ti.com  Thu Feb  3 05:12:25 2011
From: vaibhav.bedia at ti.com (Vaibhav Bedia)
Date: Thu,  3 Feb 2011 16:42:25 +0530
Subject: [PATCH v2] asoc: davinci: da830/omap-l137: correct cpu_dai_name
Message-ID: <1296731545-8338-1-git-send-email-vaibhav.bedia@ti.com>

McASP1 is used on the DA830/OMAP-L137 platform for the codec.
This is different from the DA850/OMAP-L138 platform which uses McASP0.

This is fixed by adding a new snd_soc_dai_link struct.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
---

v2: 
Fixed the subject as pointed out by Sergei.

 sound/soc/davinci/davinci-evm.c |   18 +++++++++++++++---
 1 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index b36f0b3..fe79842 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -218,7 +218,19 @@ static struct snd_soc_dai_link dm6467_evm_dai[] = {
 		.ops = &evm_spdif_ops,
 	},
 };
-static struct snd_soc_dai_link da8xx_evm_dai = {
+
+static struct snd_soc_dai_link da830_evm_dai = {
+	.name = "TLV320AIC3X",
+	.stream_name = "AIC3X",
+	.cpu_dai_name = "davinci-mcasp.1",
+	.codec_dai_name = "tlv320aic3x-hifi",
+	.codec_name = "tlv320aic3x-codec.1-0018",
+	.platform_name = "davinci-pcm-audio",
+	.init = evm_aic3x_init,
+	.ops = &evm_ops,
+};
+
+static struct snd_soc_dai_link da850_evm_dai = {
 	.name = "TLV320AIC3X",
 	.stream_name = "AIC3X",
 	.cpu_dai_name= "davinci-mcasp.0",
@@ -259,13 +271,13 @@ static struct snd_soc_card dm6467_snd_soc_card_evm = {
 
 static struct snd_soc_card da830_snd_soc_card = {
 	.name = "DA830/OMAP-L137 EVM",
-	.dai_link = &da8xx_evm_dai,
+	.dai_link = &da830_evm_dai,
 	.num_links = 1,
 };
 
 static struct snd_soc_card da850_snd_soc_card = {
 	.name = "DA850/OMAP-L138 EVM",
-	.dai_link = &da8xx_evm_dai,
+	.dai_link = &da850_evm_dai,
 	.num_links = 1,
 };
 
-- 
1.6.2.4


From gilles.chanteperdrix at nexvision.fr  Thu Feb  3 05:15:05 2011
From: gilles.chanteperdrix at nexvision.fr (Gilles Chanteperdrix)
Date: Thu, 03 Feb 2011 12:15:05 +0100
Subject: Intermittent SD write corruption on DM355, kernel 2.6.36
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE093F9AEA5C@Cloud.RL.local>
References: <70E876B0EA86DD4BAF101844BC814DFE093F9AEA5C@Cloud.RL.local>
Message-ID: <4D4A8E39.2030709@nexvision.fr>

Jon Povey wrote:
>>>>> Jon Povey wrote:
>>>>>> I am seeing rare SD card write corruption on DM355
> 
> I think I have a fix for this now - just CC'd you on the patch RFC
> 
> [RFC] mmc: davinci: fix corruption after surprise card eject
> 
> (Which fixes it, but may not be the best way of going about it).

If I read you correctly, it seems that the fix does things which are
already done, right? So, how come it fixes ? :-)

Although, maybe it may makes sense to post the patch on the
linux-arm-kernel mailing list too.

-- 
Gilles Chanteperdrix
NexVision, http://www.nexvision.fr
Office: 99, av Clot-Bey, 13008 Marseille, France
Phone: +33 (0)4 91 77 62 87 / Fax: +33 (0)4 91 77 64 10

From sshtylyov at mvista.com  Thu Feb  3 05:49:47 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 03 Feb 2011 14:49:47 +0300
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>	<4D49B7CD.9090006@mvista.com>	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>
Message-ID: <4D4A965B.3000809@mvista.com>

Hello.

On 03-02-2011 12:19, sughosh ganu wrote:

>          >                  diff --git a/arch/arm/mach-davinci/Kconfig
>          >                  b/arch/arm/mach-davinci/Kconfig
>          >                  index 32f1479..e13b7e0 100644
>          >                  --- a/arch/arm/mach-davinci/Kconfig
>          >                  +++ b/arch/arm/mach-davinci/Kconfig
>          >                  @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>          >                   config MACH_OMAPL138_HAWKBOARD
>          >                         bool "TI AM1808 / OMAPL-138 Hawkboard
>          > platform"
>          >                         depends on ARCH_DAVINCI_DA850
>          >                  +       select MTD
>          >                  +       select MTD_PARTITIONS
>          >                  +       select MTD_CHAR
>          >                  +       select MTD_BLKDEVS
>          >                  +       select MTD_BLOCK
>          >                  +       select MTD_PHYSMAP
>          >                  +       select MTD_CFI
>          >
>          >
>          >
>          >               I don't think CFI is necessary for NAND?
>          >
>          >
>          >
>          >         Neither is the 'physmap' driver. And all this part of the
>          > patch looks completely bogus.
>          >
>          >
>          >
>          > I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest of the
>          > options for mtd related stuff. I guess i can include these in the same
>          > patch. Will come up with an updated revision. Thanks.
>
>         Why do you need to select these through Kconfig. Why cant these
>         be enabled/disabled by users using menuconfig?
>
>
>     Since the hawkboard comes with a default Nand chip, i thought these could
>     be part of the default config. But i see that these configs are not
>     defined for for other ARM boards(except PXA). In that case, i can remove
>     these configs from the deault. Thanks.

> Looking through the defconfigs, looks like a lot of boards define the configs
> for MTD as default.

    So what? Defconfigs are not created by forcing the options via Kconfig, 
they are created by manually configuring in the needed options.

> Given that the hawkboard comes with a Nand flash, i think
> the above change can stay.

    Why?

> Please let me know, and i will respin my patch accordingly.

    Please get rid of these selects.

> -sughosh

WBR, Sergei

From urwithsughosh at gmail.com  Thu Feb  3 06:16:18 2011
From: urwithsughosh at gmail.com (sughosh ganu)
Date: Thu, 3 Feb 2011 17:46:18 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <4D4A965B.3000809@mvista.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>
	<4D4A965B.3000809@mvista.com>
Message-ID: <AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>

hi,

On Thu, Feb 3, 2011 at 5:19 PM, Sergei Shtylyov <sshtylyov at mvista.com>wrote:

>
>          >                  diff --git a/arch/arm/mach-davinci/Kconfig
>>         >                  b/arch/arm/mach-davinci/Kconfig
>>         >                  index 32f1479..e13b7e0 100644
>>         >                  --- a/arch/arm/mach-davinci/Kconfig
>>         >                  +++ b/arch/arm/mach-davinci/Kconfig
>>         >                  @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>>         >                   config MACH_OMAPL138_HAWKBOARD
>>         >                         bool "TI AM1808 / OMAPL-138 Hawkboard
>>         > platform"
>>         >                         depends on ARCH_DAVINCI_DA850
>>         >                  +       select MTD
>>         >                  +       select MTD_PARTITIONS
>>         >                  +       select MTD_CHAR
>>         >                  +       select MTD_BLKDEVS
>>         >                  +       select MTD_BLOCK
>>         >                  +       select MTD_PHYSMAP
>>         >                  +       select MTD_CFI
>>         >
>>         >
>>         >
>>         >               I don't think CFI is necessary for NAND?
>>         >
>>         >
>>         >
>>         >         Neither is the 'physmap' driver. And all this part of
>> the
>>         > patch looks completely bogus.
>>         >
>>         >
>>         >
>>         > I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest
>> of the
>>         > options for mtd related stuff. I guess i can include these in
>> the same
>>         > patch. Will come up with an updated revision. Thanks.
>>
>>        Why do you need to select these through Kconfig. Why cant these
>>        be enabled/disabled by users using menuconfig?
>>
>>
>>    Since the hawkboard comes with a default Nand chip, i thought these
>> could
>>    be part of the default config. But i see that these configs are not
>>    defined for for other ARM boards(except PXA). In that case, i can
>> remove
>>    these configs from the deault. Thanks.
>>
>
>  Looking through the defconfigs, looks like a lot of boards define the
>> configs
>> for MTD as default.
>>
>
>   So what? Defconfigs are not created by forcing the options via Kconfig,
> they are created by manually configuring in the needed options.


Hmm. So then how do you suggest me to get the MTD configurations for the
board. I think it makes sense to get these as NAND comes mounted by
default(as i pointed in my earlier mail). The da8xx_omapl_defconfig is
shared by multiple boards, and this is the way i see things being configured
for individual boards, e.g MACH_DAVINCI_DA830_EVM.  If there is any better
way, let me know.

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

From sshtylyov at mvista.com  Thu Feb  3 06:16:34 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 03 Feb 2011 15:16:34 +0300
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
Message-ID: <4D4A9CA2.4080801@mvista.com>

Hello.

On 02-02-2011 20:53, Sughosh Ganu wrote:

> The omapl-138 based hawkboard comes with a 128MiB Nand Flash. Add
> support for the same.

> Signed-off-by: Sughosh Ganu<urwithsughosh at gmail.com>
[...]

> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 32f1479..e13b7e0 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>   config MACH_OMAPL138_HAWKBOARD
>   	bool "TI AM1808 / OMAPL-138 Hawkboard platform"
>   	depends on ARCH_DAVINCI_DA850
> +	select MTD
> +	select MTD_PARTITIONS
> +	select MTD_CHAR
> +	select MTD_BLKDEVS
> +	select MTD_BLOCK
> +	select MTD_PHYSMAP
> +	select MTD_CFI
> +	select MTD_NAND
> +	select MTD_NAND_IDS
> +	select MTD_NAND_DAVINCI

    Please get rid of these selects, these options are not really necessary to 
build the kernel.

> diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
> index 67c38d0..eac2d69 100644
> --- a/arch/arm/mach-davinci/board-omapl138-hawk.c
> +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
[...]
> @@ -28,6 +33,81 @@
[...]
> +static struct platform_device omapl_hawk_nandflash_device = {
> +	.name		= "davinci_nand",
> +	.id		= 1,

    Why 1 and not -1, of there's only one NAND device?

> +	.dev		= {
> +		.platform_data	=&omapl_hawk_nandflash_data,
> +	},
> +	.num_resources	= ARRAY_SIZE(omapl_hawk_nandflash_resource),
> +	.resource	= omapl_hawk_nandflash_resource,
> +};
> +
> +static struct platform_device *omapl_hawk_devices[] __initdata = {
> +	&omapl_hawk_nandflash_device,
> +};

    Why you're creating a list for NAND device registered only from 
omapl_hawk_nand_setup()?

> @@ -37,6 +117,19 @@ static short omapl138_hawk_mii_pins[] __initdata = {
>   	-1
>   };
>
> +static void omapl_hawk_nand_setup(void)
> +{
> +	int ret = 0;

    Why initialize it if you assign it in the next statement? :-/

> +
> +	ret = davinci_cfg_reg_list(omapl_hawk_nand_pins);
> +	if (ret)
> +		pr_warning("da850_evm_init: nand mux setup failed: "

    You're not in that function (and not even in DA850 EVM module); use 
__func__ to print the function name instead.

> +			   "%d\n", ret);
> +
> +	platform_add_devices(omapl_hawk_devices,
> +			     ARRAY_SIZE(omapl_hawk_devices));

    Why in the world you're not just using platform_device_register() when 
you're registering a single NAND device here? :-/

WBR, Sergei

From michael.williamson at criticallink.com  Thu Feb  3 06:23:37 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu, 03 Feb 2011 07:23:37 -0500
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024877837A@dbde02.ent.ti.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>	<4D494C6A.30507@mvista.com>
	<4D49543A.1070302@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302487782C9@dbde02.ent.ti.com>
	<4D496EC7.1010808@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024877837A@dbde02.ent.ti.com>
Message-ID: <4D4A9E49.60606@criticallink.com>

Hi Sekhar,

On 2/2/2011 10:37 AM, Nori, Sekhar wrote:

> Hi Mike,
> 
> On Wed, Feb 02, 2011 at 20:18:39, Michael Williamson wrote:
>  
>>> Since all the platform device definitions for DA8XX devices happens
>>> in devices-da8xx.c, it makes sense to get rid of the DA830_DMACH_*
>>> enum altogether and instead just define the channel numbers used in
>>> devices-da8xx.c above the actual usage.
>>>
>>> Mike, is that something you are willing take-up?
>>>
>>
>>
>> I can take this up as a separate patch series. I'd like to keep the 
>> spi platform support series isolated to that subject matter, if that's
>> OK.
> 
> Yes, the clean-up can be a separate series - but it will have to
> precede the SPI series.

> 


Quick question:

In addition to cleaning up the enums in edma.h, are you also asking to 
pull the channel / base resources for ASP currently defined in asp.h 
into devices-da8xx.c as well?  Or should that be left alone? E.G., 
these defines look like they should go in devices-da8xx and come out 
of asp.h:

DAVINCI_DA8XX_MCASP0_REG_BASE
DAVINCI_DA830_MCASP1_REG_BASE
DAVINCI_DA8XX_DMA_MCASP0_AREVT
DAVINCI_DA8XX_DMA_MCASP0_AXEVT
DAVINCI_DA830_DMA_MCASP1_AREVT
DAVINCI_DA830_DMA_MCASP1_AXEVT

If moved, there are other #defines that should then be shuffled out of asp.h
to other files for other chips/platforms for completeness, E.G.

DAVINCI_DM646X_DMA_MCASP0_AXEVT0 should go to dm646x.c.

I'm not too keen on shuffling stuff around like that if I can't test it beyond
compiling.  Especially if it's not adding any functionality.  But, I will submit
it if it's necessary to get the SPI support in.

Thanks.

-Mike


From sshtylyov at mvista.com  Thu Feb  3 06:25:12 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 03 Feb 2011 15:25:12 +0300
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>	<4D49B7CD.9090006@mvista.com>	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>	<4D4A965B.3000809@mvista.com>
	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>
Message-ID: <4D4A9EA8.8000500@mvista.com>

Hello.

On 03-02-2011 15:16, sughosh ganu wrote:

>          >                  diff --git a/arch/arm/mach-davinci/Kconfig
>          >                  b/arch/arm/mach-davinci/Kconfig
>          >                  index 32f1479..e13b7e0 100644
>          >                  --- a/arch/arm/mach-davinci/Kconfig
>          >                  +++ b/arch/arm/mach-davinci/Kconfig
>          >                  @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>          >                   config MACH_OMAPL138_HAWKBOARD
>          >                         bool "TI AM1808 / OMAPL-138 Hawkboard
>          > platform"
>          >                         depends on ARCH_DAVINCI_DA850
>          >                  +       select MTD
>          >                  +       select MTD_PARTITIONS
>          >                  +       select MTD_CHAR
>          >                  +       select MTD_BLKDEVS
>          >                  +       select MTD_BLOCK
>          >                  +       select MTD_PHYSMAP
>          >                  +       select MTD_CFI
>          >
>          >
>          >
>          >               I don't think CFI is necessary for NAND?
>          >
>          >
>          >
>          >         Neither is the 'physmap' driver. And all this part of the
>          > patch looks completely bogus.
>          >
>          >
>          >
>          > I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest of the
>          > options for mtd related stuff. I guess i can include these in the same
>          > patch. Will come up with an updated revision. Thanks.

>                 Why do you need to select these through Kconfig. Why cant these
>                 be enabled/disabled by users using menuconfig?

>             Since the hawkboard comes with a default Nand chip, i thought
>         these could
>             be part of the default config. But i see that these configs are not
>             defined for for other ARM boards(except PXA). In that case, i can
>         remove
>             these configs from the deault. Thanks.

>         Looking through the defconfigs, looks like a lot of boards define the
>         configs
>         for MTD as default.

>        So what? Defconfigs are not created by forcing the options via Kconfig,
>     they are created by manually configuring in the needed options.

> Hmm. So then how do you suggest me to get the MTD configurations for the
> board. I think it makes sense to get these as NAND comes mounted by default(as
> i pointed in my earlier mail). The da8xx_omapl_defconfig is shared by multiple
> boards, and this is the way i see things being configured for individual
> boards, e.g MACH_DAVINCI_DA830_EVM.

    I don't understand, what's the way? DA830 EVM doesn't force unnecessary 
options.

> If there is any better way, let me know.

    If you really want to enable the NAND related options, just change 
da8xx_omapl_defconfig.

> -sughosh

WBR, Sergei

From nsekhar at ti.com  Thu Feb  3 06:59:22 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 3 Feb 2011 18:29:22 +0530
Subject: [PATCH v1 1/4] davinci: da8xx/omap-l1: add support for SPI
In-Reply-To: <4D4A9E49.60606@criticallink.com>
References: <1296596979-18524-1-git-send-email-michael.williamson@criticallink.com>
	<1296596979-18524-2-git-send-email-michael.williamson@criticallink.com>
	<4D494C6A.30507@mvista.com> <4D49543A.1070302@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302487782C9@dbde02.ent.ti.com>
	<4D496EC7.1010808@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024877837A@dbde02.ent.ti.com>
	<4D4A9E49.60606@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024880B1D9@dbde02.ent.ti.com>

Hi Mike,

On Thu, Feb 03, 2011 at 17:53:37, Michael Williamson wrote:
> Hi Sekhar,
> 
> On 2/2/2011 10:37 AM, Nori, Sekhar wrote:
> 
> > Hi Mike,
> > 
> > On Wed, Feb 02, 2011 at 20:18:39, Michael Williamson wrote:
> >  
> >>> Since all the platform device definitions for DA8XX devices happens
> >>> in devices-da8xx.c, it makes sense to get rid of the DA830_DMACH_*
> >>> enum altogether and instead just define the channel numbers used in
> >>> devices-da8xx.c above the actual usage.
> >>>
> >>> Mike, is that something you are willing take-up?
> >>>
> >>
> >>
> >> I can take this up as a separate patch series. I'd like to keep the 
> >> spi platform support series isolated to that subject matter, if that's
> >> OK.
> > 
> > Yes, the clean-up can be a separate series - but it will have to
> > precede the SPI series.
> 
> > 
> 
> 
> Quick question:
> 
> In addition to cleaning up the enums in edma.h, are you also asking to 
> pull the channel / base resources for ASP currently defined in asp.h 
> into devices-da8xx.c as well?  Or should that be left alone? E.G., 
> these defines look like they should go in devices-da8xx and come out 
> of asp.h:
> 
> DAVINCI_DA8XX_MCASP0_REG_BASE
> DAVINCI_DA830_MCASP1_REG_BASE
> DAVINCI_DA8XX_DMA_MCASP0_AREVT
> DAVINCI_DA8XX_DMA_MCASP0_AXEVT
> DAVINCI_DA830_DMA_MCASP1_AREVT
> DAVINCI_DA830_DMA_MCASP1_AXEVT
> 
> If moved, there are other #defines that should then be shuffled out of asp.h
> to other files for other chips/platforms for completeness, E.G.
> 
> DAVINCI_DM646X_DMA_MCASP0_AXEVT0 should go to dm646x.c.
> 
> I'm not too keen on shuffling stuff around like that if I can't test it beyond
> compiling.  Especially if it's not adding any functionality.  But, I will submit
> it if it's necessary to get the SPI support in.

I don't think cleaning up all this ASP stuff is necessary to get SPI in.
Just do:

1) Get rid of the DA830 DMA event enum in edma.h
2) define local macros in devices-da8xx.c for the DMA events used in that 
   file.

The ASP clean-up can be taken-up at a later time.

Thanks for your efforts on this.

Best Regards,
Sekhar


From bengardiner at nanometrics.ca  Thu Feb  3 07:51:34 2011
From: bengardiner at nanometrics.ca (Ben Gardiner)
Date: Thu, 3 Feb 2011 08:51:34 -0500
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <4D4A9EA8.8000500@mvista.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>
	<4D4A965B.3000809@mvista.com>
	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>
	<4D4A9EA8.8000500@mvista.com>
Message-ID: <AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>

Hi Sergei and Sugosh,

I'm sorry to jump in so late, but I think (hope) I may have a
compromise-solution.

On Thu, Feb 3, 2011 at 7:25 AM, Sergei Shtylyov <sshtylyov at mvista.com> wrote:
> On 03-02-2011 15:16, sughosh ganu wrote:
>
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?diff --git a/arch/arm/mach-davinci/Kconfig
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?b/arch/arm/mach-davinci/Kconfig
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?index 32f1479..e13b7e0 100644
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?--- a/arch/arm/mach-davinci/Kconfig
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?+++ b/arch/arm/mach-davinci/Kconfig
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?@@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>> ? ? ? ? > ? ? ? ? ? ? ? ? ? config MACH_OMAPL138_HAWKBOARD
>> ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? bool "TI AM1808 / OMAPL-138 Hawkboard
>> ? ? ? ? > platform"
>> ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? depends on ARCH_DAVINCI_DA850
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?+ ? ? ? select MTD
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?+ ? ? ? select MTD_PARTITIONS
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?+ ? ? ? select MTD_CHAR
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?+ ? ? ? select MTD_BLKDEVS
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?+ ? ? ? select MTD_BLOCK
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?+ ? ? ? select MTD_PHYSMAP
>> ? ? ? ? > ? ? ? ? ? ? ? ? ?+ ? ? ? select MTD_CFI
>> ? ? ? ? >
>> ? ? ? ? >
>> ? ? ? ? >
>> ? ? ? ? > ? ? ? ? ? ? ? I don't think CFI is necessary for NAND?
>> ? ? ? ? >
>> ? ? ? ? >
>> ? ? ? ? >
>> ? ? ? ? > ? ? ? ? Neither is the 'physmap' driver. And all this part of
>> the
>> ? ? ? ? > patch looks completely bogus.
>> ? ? ? ? >
>> ? ? ? ? >
>> ? ? ? ? >
>> ? ? ? ? > I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest
>> of the
>> ? ? ? ? > options for mtd related stuff. I guess i can include these in
>> the same
>> ? ? ? ? > patch. Will come up with an updated revision. Thanks.
>
>> ? ? ? ? ? ? ? ?Why do you need to select these through Kconfig. Why cant
>> these
>> ? ? ? ? ? ? ? ?be enabled/disabled by users using menuconfig?
>
>> ? ? ? ? ? ?Since the hawkboard comes with a default Nand chip, i thought
>> ? ? ? ?these could
>> ? ? ? ? ? ?be part of the default config. But i see that these configs are
>> not
>> ? ? ? ? ? ?defined for for other ARM boards(except PXA). In that case, i
>> can
>> ? ? ? ?remove
>> ? ? ? ? ? ?these configs from the deault. Thanks.
>
>> ? ? ? ?Looking through the defconfigs, looks like a lot of boards define
>> the
>> ? ? ? ?configs
>> ? ? ? ?for MTD as default.
>
>> ? ? ? So what? Defconfigs are not created by forcing the options via
>> Kconfig,
>> ? ?they are created by manually configuring in the needed options.
>
>> Hmm. So then how do you suggest me to get the MTD configurations for the
>> board. I think it makes sense to get these as NAND comes mounted by
>> default(as
>> i pointed in my earlier mail). The da8xx_omapl_defconfig is shared by
>> multiple
>> boards, and this is the way i see things being configured for individual
>> boards, e.g MACH_DAVINCI_DA830_EVM.
>
> ? I don't understand, what's the way? DA830 EVM doesn't force unnecessary
> options.
>
>> If there is any better way, let me know.
>
> ? If you really want to enable the NAND related options, just change
> da8xx_omapl_defconfig.

Sergei, perhaps it would be acceptable for the Hawkboard
MACH_OMAPL138_HAWKBOARD bool to be the 'default' for the necessary MTD
settings? This would be similar to KEYBOARD_GPIO_POLLED in
9cc3049911d0166d54247cf2471802eb5293c66c and GPIO_PCA953X in
d5539ca0a5c9abd5cbf9ddcbbc1c2a507b5fd63c.

Sugosh, this means you would make an entry in
arch/arm/mach-davinci/KConfig for each of the 'selects' above.
Something like:

config MTD
 ? ? ? default MACH_OMAPL138_HAWKBOARD
config MTD_PARTITIONS
 ? ? ? default MACH_OMAPL138_HAWKBOARD
[etc.]

I agree that MTD_CFI and MTD_PHYSMAP are not needed and so should not
be included in the 'defaults.'

Again, I am sorry for jumping in at the last minute -- I would like to
see the da850's get the best mainline support possible and I hoped
that this suggestion could help accomplish that.

Best Regards,
Ben Gardiner

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

From sshtylyov at mvista.com  Thu Feb  3 08:00:45 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 03 Feb 2011 17:00:45 +0300
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>	<4D49B7CD.9090006@mvista.com>	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>	<4D4A965B.3000809@mvista.com>	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>	<4D4A9EA8.8000500@mvista.com>
	<AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
Message-ID: <4D4AB50D.4040109@mvista.com>

Hello.

On 03-02-2011 16:51, Ben Gardiner wrote:

> I'm sorry to jump in so late, but I think (hope) I may have a
> compromise-solution.

    You're not late -- patch hasn't been resubmitted yet. :-)

> On Thu, Feb 3, 2011 at 7:25 AM, Sergei Shtylyov<sshtylyov at mvista.com>  wrote:
>> On 03-02-2011 15:16, sughosh ganu wrote:
>>
>>>          >                    diff --git a/arch/arm/mach-davinci/Kconfig
>>>          >                    b/arch/arm/mach-davinci/Kconfig
>>>          >                    index 32f1479..e13b7e0 100644
>>>          >                    --- a/arch/arm/mach-davinci/Kconfig
>>>          >                    +++ b/arch/arm/mach-davinci/Kconfig
>>>          >                    @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
>>>          >                     config MACH_OMAPL138_HAWKBOARD
>>>          >                           bool "TI AM1808 / OMAPL-138 Hawkboard
>>>          >  platform"
>>>          >                           depends on ARCH_DAVINCI_DA850
>>>          >                    +       select MTD
>>>          >                    +       select MTD_PARTITIONS
>>>          >                    +       select MTD_CHAR
>>>          >                    +       select MTD_BLKDEVS
>>>          >                    +       select MTD_BLOCK
>>>          >                    +       select MTD_PHYSMAP
>>>          >                    +       select MTD_CFI
>>>          >
>>>          >
>>>          >
>>>          >                 I don't think CFI is necessary for NAND?
>>>          >
>>>          >
>>>          >
>>>          >           Neither is the 'physmap' driver. And all this part of
>>> the
>>>          >  patch looks completely bogus.
>>>          >
>>>          >
>>>          >
>>>          >  I think MTD_CFI and MTD_PHYSMAP are not needed. I need the rest
>>> of the
>>>          >  options for mtd related stuff. I guess i can include these in
>>> the same
>>>          >  patch. Will come up with an updated revision. Thanks.
>>
>>>                 Why do you need to select these through Kconfig. Why cant
>>> these
>>>                 be enabled/disabled by users using menuconfig?
>>
>>>             Since the hawkboard comes with a default Nand chip, i thought
>>>         these could
>>>             be part of the default config. But i see that these configs are
>>> not
>>>             defined for for other ARM boards(except PXA). In that case, i
>>> can
>>>         remove
>>>             these configs from the deault. Thanks.
>>
>>>         Looking through the defconfigs, looks like a lot of boards define
>>> the
>>>         configs
>>>         for MTD as default.
>>
>>>        So what? Defconfigs are not created by forcing the options via
>>> Kconfig,
>>>     they are created by manually configuring in the needed options.
>>
>>> Hmm. So then how do you suggest me to get the MTD configurations for the
>>> board. I think it makes sense to get these as NAND comes mounted by
>>> default(as
>>> i pointed in my earlier mail). The da8xx_omapl_defconfig is shared by
>>> multiple
>>> boards, and this is the way i see things being configured for individual
>>> boards, e.g MACH_DAVINCI_DA830_EVM.

>>    I don't understand, what's the way? DA830 EVM doesn't force unnecessary
>> options.

>>> If there is any better way, let me know.

>>    If you really want to enable the NAND related options, just change
>> da8xx_omapl_defconfig.

> Sergei, perhaps it would be acceptable for the Hawkboard
> MACH_OMAPL138_HAWKBOARD bool to be the 'default' for the necessary MTD
> settings?

    In my opinion, this is not acceptable either. This is a sure way to turn 
Kconfig into hell, if everybody starts doing that...

WBR, Sergei

From urwithsughosh at gmail.com  Thu Feb  3 08:33:35 2011
From: urwithsughosh at gmail.com (sughosh ganu)
Date: Thu, 3 Feb 2011 20:03:35 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>
	<4D4A965B.3000809@mvista.com>
	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>
	<4D4A9EA8.8000500@mvista.com>
	<AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
Message-ID: <AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>

hi Ben and Sergei,

On Thu, Feb 3, 2011 at 7:21 PM, Ben Gardiner <bengardiner at nanometrics.ca>wrote:

> > On 03-02-2011 15:16, sughosh ganu wrote:
> >
> >>         >                  diff --git a/arch/arm/mach-davinci/Kconfig
> >>         >                  b/arch/arm/mach-davinci/Kconfig
> >>         >                  index 32f1479..e13b7e0 100644
> >>         >                  --- a/arch/arm/mach-davinci/Kconfig
> >>         >                  +++ b/arch/arm/mach-davinci/Kconfig
> >>         >                  @@ -213,6 +213,16 @@ config MACH_MITYOMAPL138
> >>         >                   config MACH_OMAPL138_HAWKBOARD
> >>         >                         bool "TI AM1808 / OMAPL-138 Hawkboard
> >>         > platform"
> >>         >                         depends on ARCH_DAVINCI_DA850
> >>         >                  +       select MTD
> >>         >                  +       select MTD_PARTITIONS
> >>         >                  +       select MTD_CHAR
> >>         >                  +       select MTD_BLKDEVS
> >>         >                  +       select MTD_BLOCK
> >>         >                  +       select MTD_PHYSMAP
> >>         >                  +       select MTD_CFI
>

<snip>

Sergei, perhaps it would be acceptable for the Hawkboard
> MACH_OMAPL138_HAWKBOARD bool to be the 'default' for the necessary MTD
> settings? This would be similar to KEYBOARD_GPIO_POLLED in
> 9cc3049911d0166d54247cf2471802eb5293c66c and GPIO_PCA953X in
> d5539ca0a5c9abd5cbf9ddcbbc1c2a507b5fd63c.
>
> Sugosh, this means you would make an entry in
> arch/arm/mach-davinci/KConfig for each of the 'selects' above.
> Something like:
>
> config MTD
>        default MACH_OMAPL138_HAWKBOARD
> config MTD_PARTITIONS
>        default MACH_OMAPL138_HAWKBOARD
> [etc.]
>
>
Thanks a lot for your hints. I am ready to go this way too. Let me test this
and get back.


> I agree that MTD_CFI and MTD_PHYSMAP are not needed and so should not
> be included in the 'defaults.'
>

No, this was an error, these options should be removed.


@Sergei

We have a common da8xx_omapl_defconfig which is being currently used by
multiple boards(including hawkboard). Not all boards have a nand flash
mounted as default. So i cannot add this in the above defconfig file. So
then, the flash driver, along with the neccessary mtd configs will have to
be included everytime through the menuconfig, inspite of the fact that the
flash is a default component on the board.

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

From lrg at slimlogic.co.uk  Thu Feb  3 10:15:17 2011
From: lrg at slimlogic.co.uk (Liam Girdwood)
Date: Thu, 03 Feb 2011 16:15:17 +0000
Subject: [alsa-devel] [PATCH v2] asoc: davinci: da830/omap-l137:
	correct cpu_dai_name
In-Reply-To: <1296731545-8338-1-git-send-email-vaibhav.bedia@ti.com>
References: <1296731545-8338-1-git-send-email-vaibhav.bedia@ti.com>
Message-ID: <1296749717.3456.122.camel@odin>

On Thu, 2011-02-03 at 16:42 +0530, Vaibhav Bedia wrote:
> McASP1 is used on the DA830/OMAP-L137 platform for the codec.
> This is different from the DA850/OMAP-L138 platform which uses McASP0.
> 
> This is fixed by adding a new snd_soc_dai_link struct.
> 
> Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
> ---
> 
> v2: 
> Fixed the subject as pointed out by Sergei.
> 

Acked-by: Liam Girdwood <lrg at slimlogic.co.uk>
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk


From nsekhar at ti.com  Thu Feb  3 11:08:09 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 3 Feb 2011 22:38:09 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>
	<4D4A965B.3000809@mvista.com>
	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>
	<4D4A9EA8.8000500@mvista.com>
	<AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
	<AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024880B327@dbde02.ent.ti.com>

Hi sughosh,

On Thu, Feb 03, 2011 at 20:03:35, sughosh ganu wrote:

> 
> We have a common da8xx_omapl_defconfig which is being currently used by
> multiple boards(including hawkboard). Not all boards have a nand flash
> mounted as default. So i cannot add this in the above defconfig file. So

Why? Boards which do not have NAND flash will not have
NAND platform data registered. Enabling the NAND driver
should cause no harm (except an increase in image size).

Thanks,
Sekhar

> then, the flash driver, along with the neccessary mtd configs will have
> to be included everytime through the menuconfig, inspite of the fact
> that the flash is a default component on the board.
> 
> -sughosh
> 
> 
> 


From urwithsughosh at gmail.com  Thu Feb  3 12:01:48 2011
From: urwithsughosh at gmail.com (sughosh ganu)
Date: Thu, 3 Feb 2011 23:31:48 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024880B327@dbde02.ent.ti.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>
	<4D4A965B.3000809@mvista.com>
	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>
	<4D4A9EA8.8000500@mvista.com>
	<AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
	<AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B327@dbde02.ent.ti.com>
Message-ID: <AANLkTik7U2adxVsUgn4J0u+micHdmDsc7PKyUr-FfsmG@mail.gmail.com>

hi Sekhar,

On Thu, Feb 3, 2011 at 10:38 PM, Nori, Sekhar <nsekhar at ti.com> wrote:

> >
> > We have a common da8xx_omapl_defconfig which is being currently used by
> > multiple boards(including hawkboard). Not all boards have a nand flash
> > mounted as default. So i cannot add this in the above defconfig file. So
>
> On Thu, Feb 03, 2011 at 20:03:35, sughosh ganu wrote:
> Why? Boards which do not have NAND flash will not have
> NAND platform data registered. Enabling the NAND driver
> should cause no harm (except an increase in image size).
>

Because i thought adding configs for features not used by all boards not to
be a clean way of implementing it. I am confused as to why adding the
configs for the board that uses those features is being frowned upon, but
enabling them for boards which do not use it is fine. Can someone please
elucidate.

But if adding them to the defconfig file is ok, i will respin the patch
accordingly and resubmit. Thanks.

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

From sshtylyov at mvista.com  Thu Feb  3 13:19:28 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 03 Feb 2011 22:19:28 +0300
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>	<4D49B7CD.9090006@mvista.com>	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>	<4D4A965B.3000809@mvista.com>	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>	<4D4A9EA8.8000500@mvista.com>	<AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
	<AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>
Message-ID: <4D4AFFC0.7010505@mvista.com>

Hello.

sughosh ganu wrote:

> hi Ben and Sergei,

> On Thu, Feb 3, 2011 at 7:21 PM, Ben Gardiner <bengardiner at nanometrics.ca 
> <mailto:bengardiner at nanometrics.ca>> wrote:
> 
>      > On 03-02-2011 15:16, sughosh ganu wrote:
>      >
>      >>         >                  diff --git
>     a/arch/arm/mach-davinci/Kconfig
>      >>         >                  b/arch/arm/mach-davinci/Kconfig
>      >>         >                  index 32f1479..e13b7e0 100644
>      >>         >                  --- a/arch/arm/mach-davinci/Kconfig
>      >>         >                  +++ b/arch/arm/mach-davinci/Kconfig
>      >>         >                  @@ -213,6 +213,16 @@ config
>     MACH_MITYOMAPL138
>      >>         >                   config MACH_OMAPL138_HAWKBOARD
>      >>         >                         bool "TI AM1808 / OMAPL-138
>     Hawkboard
>      >>         > platform"
>      >>         >                         depends on ARCH_DAVINCI_DA850
>      >>         >                  +       select MTD
>      >>         >                  +       select MTD_PARTITIONS
>      >>         >                  +       select MTD_CHAR
>      >>         >                  +       select MTD_BLKDEVS
>      >>         >                  +       select MTD_BLOCK
>      >>         >                  +       select MTD_PHYSMAP
>      >>         >                  +       select MTD_CFI


> <snip>

>     Sergei, perhaps it would be acceptable for the Hawkboard
>     MACH_OMAPL138_HAWKBOARD bool to be the 'default' for the necessary MTD
>     settings? This would be similar to KEYBOARD_GPIO_POLLED in
>     9cc3049911d0166d54247cf2471802eb5293c66c and GPIO_PCA953X in
>     d5539ca0a5c9abd5cbf9ddcbbc1c2a507b5fd63c.

>     Sugosh, this means you would make an entry in
>     arch/arm/mach-davinci/KConfig for each of the 'selects' above.
>     Something like:

>     config MTD
>            default MACH_OMAPL138_HAWKBOARD
>     config MTD_PARTITIONS
>            default MACH_OMAPL138_HAWKBOARD
>     [etc.]

> Thanks a lot for your hints. I am ready to go this way too. Let me test 
> this and get back.

    Don't even waste your time, it won't be acceptable.

>     I agree that MTD_CFI and MTD_PHYSMAP are not needed and so should not
>     be included in the 'defaults.'

> No, this was an error, these options should be removed.


> @Sergei
> 
> We have a common da8xx_omapl_defconfig which is being currently used by 
> multiple boards(including hawkboard). Not all boards have a nand flash 
> mounted as default. So i cannot add this in the above defconfig file.

    Why? If the board doesn't have a NAND flash, it doesn't register the 
platform device and the driver doesn't see it. What's the issue?

> So then, the flash driver, along with the neccessary mtd configs will have 
> to be included everytime through the menuconfig, inspite of the fact 
> that the flash is a default component on the board.

    Note that a NAND flash is a default component of DA850 EVM board too, 
nevertheless the NAND driver is not enabled in the defconfig.

> -sughosh

WBR, Sergei

From sshtylyov at mvista.com  Thu Feb  3 13:28:46 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 03 Feb 2011 22:28:46 +0300
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <4D4AFFC0.7010505@mvista.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>	<4D49B7CD.9090006@mvista.com>	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>	<4D4A965B.3000809@mvista.com>	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>	<4D4A9EA8.8000500@mvista.com>	<AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
	<AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>
	<4D4AFFC0.7010505@mvista.com>
Message-ID: <4D4B01EE.90700@mvista.com>

Hello, I wrote:

>> @Sergei

>> We have a common da8xx_omapl_defconfig which is being currently used 
>> by multiple boards(including hawkboard). Not all boards have a nand 
>> flash mounted as default. So i cannot add this in the above defconfig 
>> file.

>    Why? If the board doesn't have a NAND flash, it doesn't register the 
> platform device and the driver doesn't see it. What's the issue?

>> So then, the flash driver, along with the neccessary mtd configs will 
>> have to be included everytime through the menuconfig, inspite of the 
>> fact that the flash is a default component on the board.

>    Note that a NAND flash is a default component of DA850 EVM board too, 
> nevertheless the NAND driver is not enabled in the defconfig.

    Nevermind, the misleading comment made me think that NAND is mounted on the 
EVM itself -- actually it's on UI daughter board, just like with DA830 EVM... :-/

>> -sughosh

WBR, Sergei

From sshtylyov at mvista.com  Thu Feb  3 13:43:50 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Thu, 03 Feb 2011 22:43:50 +0300
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTik7U2adxVsUgn4J0u+micHdmDsc7PKyUr-FfsmG@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>	<4D49B7CD.9090006@mvista.com>	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>	<4D4A965B.3000809@mvista.com>	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>	<4D4A9EA8.8000500@mvista.com>	<AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>	<AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB593024880B327@dbde02.ent.ti.com>
	<AANLkTik7U2adxVsUgn4J0u+micHdmDsc7PKyUr-FfsmG@mail.gmail.com>
Message-ID: <4D4B0576.3070207@mvista.com>

Hello.

sughosh ganu wrote:

>      >
>      > We have a common da8xx_omapl_defconfig which is being currently
>     used by
>      > multiple boards(including hawkboard). Not all boards have a nand
>     flash
>      > mounted as default. So i cannot add this in the above defconfig
>     file. So
> 
>     On Thu, Feb 03, 2011 at 20:03:35, sughosh ganu wrote:
>     Why? Boards which do not have NAND flash will not have
>     NAND platform data registered. Enabling the NAND driver
>     should cause no harm (except an increase in image size).


> Because i thought adding configs for features not used by all boards not 
> to be a clean way of implementing it. I am confused as to why adding the 
> configs for the board that uses those features is being frowned upon, 

   You're not just adding the MTD configs, you're *forcing* them, devoiding the 
users of any freedom of choice.

> -sughosh

WBR, Sergei

From adityabarawkar at gmail.com  Thu Feb  3 13:56:02 2011
From: adityabarawkar at gmail.com (Aditya Barawkar)
Date: Fri, 4 Feb 2011 01:26:02 +0530
Subject: Error While Running Demos
Message-ID: <AANLkTimhZy=SLnZvQm=zTqQe9XKQi3Ofkkof2xwFr0xW@mail.gmail.com>

I'm trying to run demos for encode decode which came with DVSDK v1.30.01 for
DM6446 EVM

When i boot the board then I'm not seeing any demos which should run
automatically as per the TI doc.

So i opted to run the demos using command line.

First i loaded all the modules which are required to run the demos
Modules loaded :: cmemk.ko and dsplinkk.ko

root at 10.42.43.10:/opt/demos/dm6446/decode/release# lsmod
Module                  Size  Used by
cmemk                  17368  0
dsplinkk               96360  0

But when i excute command to run the demo ::: ./decode -v
/opt/demos/dm6446/data/videos/davincieffect_ntsc.m2v -k
i get following error::


Decode demo started.
TraceUtil> Error: Failed to open codec engine "decode"
TraceUtil> Error: Aborting TraceUtil_start
Decode Error: Failed to open codec engine decode
Decode Error: Failed to open codec engine decode
root at 10.42.43.10:/opt/demos/dm6446/decode/release#

Please help me out on how to make the sample demos run.

Thanks in advance.!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/fd96e4df/attachment.html>

From michael.williamson at criticallink.com  Thu Feb  3 14:11:59 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu,  3 Feb 2011 15:11:59 -0500
Subject: [PATCH] davinci: remove unused DA830_edma_ch enum
Message-ID: <1296763920-4165-1-git-send-email-michael.williamson@criticallink.com>

The DA830_edma_ch enum set is not used.  Remove it.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/include/mach/edma.h |   36 -----------------------------
 1 files changed, 0 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/edma.h b/arch/arm/mach-davinci/include/mach/edma.h
index dc10ef6..20c77f2 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -151,42 +151,6 @@ struct edmacc_param {
 #define DA830_DMACH2EVENT_MAP1		0x00000000u
 #define DA830_EDMA_ARM_OWN		0x30FFCCFFu
 
-/* DA830 specific EDMA3 Events Information */
-enum DA830_edma_ch {
-	DA830_DMACH_MCASP0_RX,
-	DA830_DMACH_MCASP0_TX,
-	DA830_DMACH_MCASP1_RX,
-	DA830_DMACH_MCASP1_TX,
-	DA830_DMACH_MCASP2_RX,
-	DA830_DMACH_MCASP2_TX,
-	DA830_DMACH_GPIO_BNK0INT,
-	DA830_DMACH_GPIO_BNK1INT,
-	DA830_DMACH_UART0_RX,
-	DA830_DMACH_UART0_TX,
-	DA830_DMACH_TMR64P0_EVTOUT12,
-	DA830_DMACH_TMR64P0_EVTOUT34,
-	DA830_DMACH_UART1_RX,
-	DA830_DMACH_UART1_TX,
-	DA830_DMACH_SPI0_RX,
-	DA830_DMACH_SPI0_TX,
-	DA830_DMACH_MMCSD_RX,
-	DA830_DMACH_MMCSD_TX,
-	DA830_DMACH_SPI1_RX,
-	DA830_DMACH_SPI1_TX,
-	DA830_DMACH_DMAX_EVTOUT6,
-	DA830_DMACH_DMAX_EVTOUT7,
-	DA830_DMACH_GPIO_BNK2INT,
-	DA830_DMACH_GPIO_BNK3INT,
-	DA830_DMACH_I2C0_RX,
-	DA830_DMACH_I2C0_TX,
-	DA830_DMACH_I2C1_RX,
-	DA830_DMACH_I2C1_TX,
-	DA830_DMACH_GPIO_BNK4INT,
-	DA830_DMACH_GPIO_BNK5INT,
-	DA830_DMACH_UART2_RX,
-	DA830_DMACH_UART2_TX
-};
-
 /*ch_status paramater of callback function possible values*/
 #define DMA_COMPLETE 1
 #define DMA_CC_ERROR 2
-- 
1.7.0.4


From michael.williamson at criticallink.com  Thu Feb  3 14:12:00 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu,  3 Feb 2011 15:12:00 -0500
Subject: [PATCH] davinci: da8xx: clean up magic numbers in devices-da8xx.c
In-Reply-To: <1296763920-4165-1-git-send-email-michael.williamson@criticallink.com>
References: <1296763920-4165-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1296763920-4165-2-git-send-email-michael.williamson@criticallink.com>

Extract magic numbers from DMA resource initializers to #defines.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/devices-da8xx.c |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..119d46e 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -44,6 +44,11 @@
 #define DA8XX_EMAC_RAM_OFFSET		0x0000
 #define DA8XX_EMAC_CTRL_RAM_SIZE	SZ_8K
 
+#define DA8XX_DMA_MMCSD0_RX	EDMA_CTLR_CHAN(0, 16)
+#define DA8XX_DMA_MMCSD0_TX	EDMA_CTLR_CHAN(0, 17)
+#define DA850_DMA_MMCSD1_RX	EDMA_CTLR_CHAN(1, 28)
+#define DA850_DMA_MMCSD1_TX	EDMA_CTLR_CHAN(1, 29)
+
 void __iomem *da8xx_syscfg0_base;
 void __iomem *da8xx_syscfg1_base;
 
@@ -573,13 +578,13 @@ static struct resource da8xx_mmcsd0_resources[] = {
 		.flags	= IORESOURCE_IRQ,
 	},
 	{		/* DMA RX */
-		.start	= EDMA_CTLR_CHAN(0, 16),
-		.end	= EDMA_CTLR_CHAN(0, 16),
+		.start	= DA8XX_DMA_MMCSD0_RX,
+		.end	= DA8XX_DMA_MMCSD0_RX,
 		.flags	= IORESOURCE_DMA,
 	},
 	{		/* DMA TX */
-		.start	= EDMA_CTLR_CHAN(0, 17),
-		.end	= EDMA_CTLR_CHAN(0, 17),
+		.start	= DA8XX_DMA_MMCSD0_TX,
+		.end	= DA8XX_DMA_MMCSD0_TX,
 		.flags	= IORESOURCE_DMA,
 	},
 };
@@ -610,13 +615,13 @@ static struct resource da850_mmcsd1_resources[] = {
 		.flags	= IORESOURCE_IRQ,
 	},
 	{		/* DMA RX */
-		.start	= EDMA_CTLR_CHAN(1, 28),
-		.end	= EDMA_CTLR_CHAN(1, 28),
+		.start	= DA850_DMA_MMCSD1_RX,
+		.end	= DA850_DMA_MMCSD1_RX,
 		.flags	= IORESOURCE_DMA,
 	},
 	{		/* DMA TX */
-		.start	= EDMA_CTLR_CHAN(1, 29),
-		.end	= EDMA_CTLR_CHAN(1, 29),
+		.start	= DA850_DMA_MMCSD1_TX,
+		.end	= DA850_DMA_MMCSD1_TX,
 		.flags	= IORESOURCE_DMA,
 	},
 };
-- 
1.7.0.4


From broonie at opensource.wolfsonmicro.com  Thu Feb  3 14:22:53 2011
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Thu, 3 Feb 2011 20:22:53 +0000
Subject: [PATCH v2] asoc: davinci: da830/omap-l137: correct cpu_dai_name
In-Reply-To: <1296731545-8338-1-git-send-email-vaibhav.bedia@ti.com>
References: <1296731545-8338-1-git-send-email-vaibhav.bedia@ti.com>
Message-ID: <20110203202252.GA3835@opensource.wolfsonmicro.com>

On Thu, Feb 03, 2011 at 04:42:25PM +0530, Vaibhav Bedia wrote:
> McASP1 is used on the DA830/OMAP-L137 platform for the codec.
> This is different from the DA850/OMAP-L138 platform which uses McASP0.
> 
> This is fixed by adding a new snd_soc_dai_link struct.

Applied, thanks.

From rtivy at ti.com  Thu Feb  3 15:31:48 2011
From: rtivy at ti.com (Tivy, Robert)
Date: Thu, 3 Feb 2011 15:31:48 -0600
Subject: Error While Running Demos
In-Reply-To: <AANLkTimhZy=SLnZvQm=zTqQe9XKQi3Ofkkof2xwFr0xW@mail.gmail.com>
References: <AANLkTimhZy=SLnZvQm=zTqQe9XKQi3Ofkkof2xwFr0xW@mail.gmail.com>
Message-ID: <6B8224E84039B140AA662F0BB03616430188FA63B9@dlee04.ent.ti.com>

More details about the failure to open the codec engine are needed.  You can generate more info by setting the environment variable CE_DEBUG=3 and re-running your app:
    % export CE_DEBUG=3
    % ./decode ...

Regards,

- Rob

________________________________
From: davinci-linux-open-source-bounces+rtivy=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy=ti.com at linux.davincidsp.com] On Behalf Of Aditya Barawkar
Sent: Thursday, February 03, 2011 11:56 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Error While Running Demos

I'm trying to run demos for encode decode which came with DVSDK v1.30.01 for DM6446 EVM

When i boot the board then I'm not seeing any demos which should run automatically as per the TI doc.

So i opted to run the demos using command line.

First i loaded all the modules which are required to run the demos
Modules loaded :: cmemk.ko and dsplinkk.ko

root at 10.42.43.10:/opt/demos/dm6446/decode/release# lsmod
Module                  Size  Used by
cmemk                  17368  0
dsplinkk               96360  0

But when i excute command to run the demo ::: ./decode -v /opt/demos/dm6446/data/videos/davincieffect_ntsc.m2v -k
i get following error::


Decode demo started.
TraceUtil> Error: Failed to open codec engine "decode"
TraceUtil> Error: Aborting TraceUtil_start
Decode Error: Failed to open codec engine decode
Decode Error: Failed to open codec engine decode
root at 10.42.43.10:/opt/demos/dm6446/decode/release#

Please help me out on how to make the sample demos run.

Thanks in advance.!

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

From michael.williamson at criticallink.com  Thu Feb  3 18:34:47 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu,  3 Feb 2011 19:34:47 -0500
Subject: [PATCH 0/3] spi: davinci: move eventq parameter to platform data 
Message-ID: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>

For DMA operation, the davinci spi driver needs an eventq number.
Currently, this number is passed as a IORESOURCE_DMA.  This is not
correct, as the eventq is not a DMA channel.  Pass the eventq
via the platform data structure instead as is done with davinci
devices such as the McASP.

Two platforms (dm355 and dm365) are using the davinci spi driver 
with DMA's enabled, move the eventq parameter out of the resources
and into the platform data.

I have tested this patch with an OMAP-L138 (patch submission for this
platform is in progress).  I do not have a dm355 or dm365, so these
platforms have not been tested.

Michael Williamson (3):
  davinci: spi: move event_q parameter to platform data
  davinci: dm355: move spi0 eventq assignment from resources to
    platform data
  davinci: dm365: move spi0 eventq assignment from resources to
    platform data

 arch/arm/mach-davinci/dm355.c            |    5 +----
 arch/arm/mach-davinci/dm365.c            |    5 +----
 arch/arm/mach-davinci/include/mach/spi.h |   15 ++++++++++-----
 drivers/spi/davinci_spi.c                |   11 +++--------
 4 files changed, 15 insertions(+), 21 deletions(-)


From michael.williamson at criticallink.com  Thu Feb  3 18:34:48 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu,  3 Feb 2011 19:34:48 -0500
Subject: [PATCH 1/3] davinci: spi: move event_q parameter to platform data
In-Reply-To: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>
References: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1296779690-9723-2-git-send-email-michael.williamson@criticallink.com>

For DMA operation, the davinci spi driver needs an eventq number.
Currently, this number is passed as a IORESOURCE_DMA.  This is not
correct, as the eventq is not a DMA channel.  Pass the eventq
via the platform data structure instead.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/include/mach/spi.h |   15 ++++++++++-----
 drivers/spi/davinci_spi.c                |   11 +++--------
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
index 38f4da5..0853a5f 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -19,6 +19,8 @@
 #ifndef __ARCH_ARM_DAVINCI_SPI_H
 #define __ARCH_ARM_DAVINCI_SPI_H
 
+#include <mach/edma.h>
+
 #define SPI_INTERN_CS	0xFF
 
 enum {
@@ -39,13 +41,16 @@ enum {
  *		to populate if all chip-selects are internal.
  * @cshold_bug:	set this to true if the SPI controller on your chip requires
  *		a write to CSHOLD bit in between transfers (like in DM355).
+ * @dma_event_q: DMA event_q to use if SPI_IO_TYPE_DMA is used for any device
+ *		on the bus.
  */
 struct davinci_spi_platform_data {
-	u8	version;
-	u8	num_chipselect;
-	u8	intr_line;
-	u8	*chip_sel;
-	bool	cshold_bug;
+	u8			version;
+	u8			num_chipselect;
+	u8			intr_line;
+	u8			*chip_sel;
+	bool			cshold_bug;
+	enum dma_event_q	dma_event_q;
 };
 
 /**
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 6beab99..166a879 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -790,7 +790,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	struct resource *r, *mem;
 	resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
 	resource_size_t	dma_tx_chan = SPI_NO_RESOURCE;
-	resource_size_t	dma_eventq = SPI_NO_RESOURCE;
 	int i = 0, ret = 0;
 	u32 spipc0;
 
@@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	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;
 
 	dspi->bitbang.txrx_bufs = davinci_spi_bufs;
 	if (dma_rx_chan != SPI_NO_RESOURCE &&
-	    dma_tx_chan != SPI_NO_RESOURCE &&
-	    dma_eventq != SPI_NO_RESOURCE) {
+	    dma_tx_chan != SPI_NO_RESOURCE) {
 		dspi->dma.rx_channel = dma_rx_chan;
 		dspi->dma.tx_channel = dma_tx_chan;
-		dspi->dma.eventq = dma_eventq;
+		dspi->dma.eventq = pdata->dma_event_q;
 
 		ret = davinci_spi_request_dma(dspi);
 		if (ret)
@@ -897,7 +892,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
 		dev_info(&pdev->dev, "DMA: supported\n");
 		dev_info(&pdev->dev, "DMA: RX channel: %d, TX channel: %d, "
 				"event queue: %d\n", dma_rx_chan, dma_tx_chan,
-				dma_eventq);
+				pdata->dma_event_q);
 	}
 
 	dspi->get_rx = davinci_spi_rx_buf_u8;
-- 
1.7.0.4


From michael.williamson at criticallink.com  Thu Feb  3 18:34:49 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu,  3 Feb 2011 19:34:49 -0500
Subject: [PATCH 2/3] davinci: dm355: move spi0 eventq assignment from
	resources to platform data
In-Reply-To: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>
References: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1296779690-9723-3-git-send-email-michael.williamson@criticallink.com>

Move the eventq assignment for spi0 out of resources and into platform data.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/dm355.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a5f8a80..76364d1 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -403,16 +403,13 @@ static struct resource dm355_spi0_resources[] = {
 		.start = 16,
 		.flags = IORESOURCE_DMA,
 	},
-	{
-		.start = EVENTQ_1,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct davinci_spi_platform_data dm355_spi0_pdata = {
 	.version 	= SPI_VERSION_1,
 	.num_chipselect = 2,
 	.cshold_bug	= true,
+	.dma_event_q	= EVENTQ_1,
 };
 static struct platform_device dm355_spi0_device = {
 	.name = "spi_davinci",
-- 
1.7.0.4


From michael.williamson at criticallink.com  Thu Feb  3 18:34:50 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Thu,  3 Feb 2011 19:34:50 -0500
Subject: [PATCH 3/3] davinci: dm365: move spi0 eventq assignment from
	resources to platform data
In-Reply-To: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>
References: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1296779690-9723-4-git-send-email-michael.williamson@criticallink.com>

Move the spi0 eventq assignment out of resources array and into platform data.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/dm365.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 02d2cc3..4604e72 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -625,6 +625,7 @@ 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,
+	.dma_event_q	= EVENTQ_3,
 };
 
 static struct resource dm365_spi0_resources[] = {
@@ -645,10 +646,6 @@ static struct resource dm365_spi0_resources[] = {
 		.start = 16,
 		.flags = IORESOURCE_DMA,
 	},
-	{
-		.start = EVENTQ_3,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct platform_device dm365_spi0_device = {
-- 
1.7.0.4


From spam_master at chungbuk.ac.kr  Thu Feb  3 20:23:18 2011
From: spam_master at chungbuk.ac.kr (spam_master at chungbuk.ac.kr)
Date: Fri, 04 Feb 2011 11:23:18 +0900
Subject: [Err] Davinci-linux-open-source Digest, Vol 62, Issue 18
Message-ID: <2615178025574061084986162173788@psmtp.com>

Transmit Report:

wowhul at cbnu.ac.kr???? ???? ?????? 3?? ?????????? ??????????????.
(???? ???? : 900 Socket connect fail(210.115.161.38))

<????> ???? ?????? ???? ????
User unknown       :?????? ?????? ???????? ???????? ????
Socket connect fail:???? ???? ?????? ???? ????
DATA write fail    :???? ???? ?????? ?????? ???? ????
DATA reponse fail  :???? ???? ?????????? ?????? ???? ????
-------------- next part --------------
An embedded message was scrubbed...
From: davinci-linux-open-source-request at linux.davincidsp.com
Subject: Davinci-linux-open-source Digest, Vol 62, Issue 18
Date: Thu, 03 Feb 2011 18:31:07 -0600
Size: 15417
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/4d7e5e87/attachment.mht>

From spam_master at chungbuk.ac.kr  Thu Feb  3 20:27:15 2011
From: spam_master at chungbuk.ac.kr (spam_master at chungbuk.ac.kr)
Date: Fri, 04 Feb 2011 11:27:15 +0900
Subject: [Err] Davinci-linux-open-source Digest, Vol 62, Issue 17
Message-ID: <2615178027752887084986177632774@psmtp.com>

Transmit Report:

wowhul at cbnu.ac.kr???? ???? ?????? 3?? ?????????? ??????????????.
(???? ???? : 900 Socket connect fail(210.115.161.38))

<????> ???? ?????? ???? ????
User unknown       :?????? ?????? ???????? ???????? ????
Socket connect fail:???? ???? ?????? ???? ????
DATA write fail    :???? ???? ?????? ?????? ???? ????
DATA reponse fail  :???? ???? ?????????? ?????? ???? ????
-------------- next part --------------
An embedded message was scrubbed...
From: davinci-linux-open-source-request at linux.davincidsp.com
Subject: Davinci-linux-open-source Digest, Vol 62, Issue 17
Date: Thu, 03 Feb 2011 14:08:15 -0600
Size: 15334
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/324b42b9/attachment-0001.mht>

From spam_master at chungbuk.ac.kr  Thu Feb  3 20:37:58 2011
From: spam_master at chungbuk.ac.kr (spam_master at chungbuk.ac.kr)
Date: Fri, 04 Feb 2011 11:37:58 +0900
Subject: [Err] Davinci-linux-open-source Digest, Vol 62, Issue 19
Message-ID: <2615178025727120084986219910316@psmtp.com>

Transmit Report:

wowhul at cbnu.ac.kr???? ???? ?????? 3?? ?????????? ??????????????.
(???? ???? : 900 Socket connect fail(210.115.161.38))

<????> ???? ?????? ???? ????
User unknown       :?????? ?????? ???????? ???????? ????
Socket connect fail:???? ???? ?????? ???? ????
DATA write fail    :???? ???? ?????? ?????? ???? ????
DATA reponse fail  :???? ???? ?????????? ?????? ???? ????
-------------- next part --------------
An embedded message was scrubbed...
From: davinci-linux-open-source-request at linux.davincidsp.com
Subject: Davinci-linux-open-source Digest, Vol 62, Issue 19
Date: Thu, 03 Feb 2011 20:22:40 -0600
Size: 7280
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/4de8bea8/attachment.mht>

From Jon.Povey at racelogic.co.uk  Thu Feb  3 20:36:20 2011
From: Jon.Povey at racelogic.co.uk (Jon Povey)
Date: Fri, 4 Feb 2011 02:36:20 +0000
Subject: Intermittent SD write corruption on DM355, kernel 2.6.36
In-Reply-To: <4D4A8E39.2030709@nexvision.fr>
Message-ID: <70E876B0EA86DD4BAF101844BC814DFE093F9AEC95@Cloud.RL.local>

Gilles Chanteperdrix wrote:
> Jon Povey wrote:
>> I think I have a fix for this now - just CC'd you on the patch RFC
>>
>> [RFC] mmc: davinci: fix corruption after surprise card eject
>>
>> (Which fixes it, but may not be the best way of going about it).
>
> If I read you correctly, it seems that the fix does things which are
> already done, right? So, how come it fixes ? :-)

Not sure I understand.
The existing code resets the controller core when handling certain errors,
but more MMC commands are run after those error handlers. Presumably one
of those puts the core into a bad state, a later reset (my patch) fixes it.

Feel free to try it out!

> Although, maybe it may makes sense to post the patch on the
> linux-arm-kernel mailing list too.

Hmm, should maybe have CC'd them. And David Brownell. Ho well.

--
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 spam_master at chungbuk.ac.kr  Thu Feb  3 20:44:20 2011
From: spam_master at chungbuk.ac.kr (spam_master at chungbuk.ac.kr)
Date: Fri, 04 Feb 2011 11:44:20 +0900
Subject: [Err] Davinci-linux-open-source Digest, Vol 62, Issue 16
Message-ID: <2615178025574026084986244881829@psmtp.com>

Transmit Report:

wowhul at cbnu.ac.kr???? ???? ?????? 3?? ?????????? ??????????????.
(???? ???? : 900 Socket connect fail(210.115.161.38))

<????> ???? ?????? ???? ????
User unknown       :?????? ?????? ???????? ???????? ????
Socket connect fail:???? ???? ?????? ???? ????
DATA write fail    :???? ???? ?????? ?????? ???? ????
DATA reponse fail  :???? ???? ?????????? ?????? ???? ????
-------------- next part --------------
An embedded message was scrubbed...
From: davinci-linux-open-source-request at linux.davincidsp.com
Subject: Davinci-linux-open-source Digest, Vol 62, Issue 16
Date: Thu, 03 Feb 2011 12:00:00 -0600
Size: 9173
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/d2719e35/attachment.mht>

From adityabarawkar at gmail.com  Thu Feb  3 23:04:07 2011
From: adityabarawkar at gmail.com (Aditya Barawkar)
Date: Fri, 4 Feb 2011 10:34:07 +0530
Subject: Error While Running Demos
In-Reply-To: <6B8224E84039B140AA662F0BB03616430188FA63B9@dlee04.ent.ti.com>
References: <AANLkTimhZy=SLnZvQm=zTqQe9XKQi3Ofkkof2xwFr0xW@mail.gmail.com>
	<6B8224E84039B140AA662F0BB03616430188FA63B9@dlee04.ent.ti.com>
Message-ID: <AANLkTin0qPs+wuomtd3dpyptueQiWdmm7=pQS-LeAD5W@mail.gmail.com>

Thanks for looking into problem.

here is the log with CE_DEBUG=3





Decode demo started.
@0,448,089us: [+4 T:0x40018528 S:0xbefff8cc] OG - Global_init> This program
was built with the following packages:
@0,448,733us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
gnu.targets.rts470MV
(/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/gnu/targets/rts470MV/)
[1,0,0,0,1193542866293]
@0,448,978us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.g711dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/)
[1,0,0,1210922571648]
@0,449,140us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.aachedec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/)
[1,0,0,1210922563756]
@0,449,289us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mp3dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/)
[1,0,0,1210922592446]
@0,449,433us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.h264dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/)
[1,0,0,1210922581723]
@0,449,624us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mpeg2dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/)
[1,0,0,1210922600503]
@0,449,773us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mpeg4dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/)
[1,0,0,1210922605176]
@0,449,914us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.xdais.dm(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/dm/)
[1,0,4,0]
@0,450,046us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/)
[1,2,1,0]
@0,450,184us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.utils.trace
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/utils/trace/)
[1,0,0,0]
@0,450,325us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.utils.xdm
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/xdm/)
[1,0,1,1200333457442]
@0,450,464us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package dsplink.gpp
(/db/atree/library/trees/linuxdemos-a46x/imports/dsplink-dm644x-v140-05p1-prebuilt/packages/dsplink/gpp/)
[1,1,0,0]
@0,450,607us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.linuxutils.cmem
(/db/atree/library/trees/linuxdemos-a46x/imports/build/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/)
[2,0,0,0]
@0,450,750us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.fc.acpy3
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/acpy3/)
[1,0,2,0]
@0,450,893us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.fc.dman3
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/dman3/)
[1,0,3,0]
@0,451,035us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.osal
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/osal/)
[2,0,1,1200333329943]
@0,451,178us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.alg
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/alg/)
[1,0,0,1200332939285]
@0,451,317us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.catalog.c470
(/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/catalog/c470/)
[1,0,1,0,1192229332845]
@0,451,458us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.platforms.evmDM6446
(/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/platforms/evmDM6446/)
[1,0,0,1,1192229600615]
@0,451,599us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/)
[1,0,5,1200332924185]
@0,452,339us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.speech
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/speech/)
[1,0,1,1200333353059]
@0,452,548us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.g711dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/ce/)
[1,0,0,1210922072831]
@0,452,703us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.audio
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/audio/)
[1,0,1,1200332949776]
@0,452,849us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.aachedec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/ce/)
[1,0,0,1210922061774]
@0,452,999us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mp3dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/ce/)
[1,0,0,1210922155277]
@0,453,146us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.video
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/video/)
[1,0,2,1200333474655]
@0,453,291us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.h264dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/ce/)
[1,0,0,1210922114696]
@0,453,437us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mpeg2dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/ce/)
[1,0,0,1210922171166]
@0,453,584us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mpeg4dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/ce/)
[1,0,0,1210922199273]
@0,453,731us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.bioslog
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/bioslog/)
[1,0,1,1200332966901]
@0,453,873us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.utils.trace
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/trace/)
[1,0,1,1200333448031]
@0,454,016us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package decode_config
(/db/atree/library/trees/linuxdemos-a46x/imports/build/demos/dm6446/decode/decode_config/)
[]
@0,454,198us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x1d148)
@0,454,354us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c41534f]
@0,454,700us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x0]
@0,456,366us: [+7 T:0x40018528 S:0xbefff8d4] OM - Memory_init> ERROR: Failed
to initialize CMEM
@0,456,616us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
(fxn=0x1b258)
@0,456,905us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
(fxn=0x1d618)
@0,457,251us: [+0 T:0x40018528 S:0xbefff8cc] OG - Global_atexit> enter
(fxn=0x1c0e8)
@0,457,710us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Enter
(fxn=0x1e9fc, attrs=0x0)
@0,458,813us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Exit
(task=0x48180)
@0,459,038us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x1e59c)
@0,459,390us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x1a028)
@0,459,636us: [+2 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.alg - ALG_init>
Enter
@0,459,796us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415351 count: 1
@0,459,964us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,460,153us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x8001]
@0,461,093us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x10002 refCount: 1
@0,461,328us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x8001]
@0,461,513us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,461,665us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x482d8]
@0,461,817us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415352 count: 1
@0,461,993us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,462,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x18001]
@0,462,507us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x20003 refCount: 1
@0,462,689us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x18001]
@0,462,859us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,463,008us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x482e8]
@0,463,164us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415353 count: 1
@0,463,334us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,463,519us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x28001]
@0,463,767us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x30004 refCount: 1
@0,463,943us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x28001]
@0,464,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,464,254us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x482f8]
@0,464,405us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415354 count: 1
@0,464,577us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,464,764us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x38001]
@0,465,017us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x40005 refCount: 1
@0,465,199us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x38001]
@0,465,372us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,465,523us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48308]
@0,465,671us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415355 count: 1
@0,465,837us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,466,012us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x48001]
@0,466,296us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x50006 refCount: 1
@0,466,475us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x48001]
@0,466,645us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,466,786us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48318]
@0,466,932us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415356 count: 1
@0,467,096us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,467,284us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x58001]
@0,467,656us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x60007 refCount: 1
@0,467,857us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x58001]
@0,468,034us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,468,182us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48328]
@0,468,334us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415357 count: 1
@0,468,507us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,159,411us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x68001]
@1,159,729us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x70008 refCount: 1
@1,159,915us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x68001]
@1,160,092us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,160,248us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48338]
@1,160,403us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415358 count: 1
@1,160,620us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,160,823us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x78001]
@1,161,084us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x80009 refCount: 1
@1,161,272us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x78001]
@1,161,447us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,161,598us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48348]
@1,161,749us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415359 count: 1
@1,161,919us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,162,157us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x88001]
@1,162,414us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x9000a refCount: 1
@1,162,597us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x88001]
@1,162,770us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,162,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48358]
@1,163,067us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535a count: 1
@1,163,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,163,459us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x98001]
@1,163,727us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xa000b refCount: 1
@1,163,907us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x98001]
@1,164,077us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,164,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48368]
@1,164,383us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535b count: 1
@1,164,548us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,164,736us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xa8001]
@1,165,047us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xb000c refCount: 1
@1,165,237us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xa8001]
@1,165,411us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,165,557us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48378]
@1,165,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535c count: 1
@1,165,875us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,166,063us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xb8001]
@1,166,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xc000d refCount: 1
@1,166,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xb8001]
@1,166,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,166,852us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48388]
@1,167,043us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535d count: 1
@1,167,682us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,167,938us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xc8001]
@1,168,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xd000e refCount: 1
@1,168,418us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xc8001]
@1,168,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,168,745us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48398]
@1,168,893us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535e count: 1
@1,169,102us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,169,308us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xd8001]
@1,169,575us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xe000f refCount: 1
@1,169,752us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xd8001]
@1,169,923us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,170,069us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483a8]
@1,170,222us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535f count: 1
@1,170,392us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,170,624us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xe8001]
@1,170,896us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xf0010 refCount: 1
@1,171,076us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xe8001]
@1,171,253us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,171,404us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483b8]
@1,171,553us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415360 count: 1
@1,171,720us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,171,908us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xf8001]
@1,172,212us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x100011 refCount: 1
@1,172,397us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xf8001]
@1,172,572us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,172,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483c8]
@1,172,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415361 count: 1
@1,173,034us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,173,224us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x108001]
@1,173,525us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x110012 refCount: 1
@1,173,712us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x108001]
@1,173,889us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,174,040us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483d8]
@1,174,195us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415362 count: 1
@1,174,366us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,174,554us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x118001]
@1,174,848us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x120013 refCount: 1
@1,175,035us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x118001]
@1,175,211us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,175,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483e8]
@1,175,795us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415363 count: 1
@1,865,769us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,866,065us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x128001]
@1,866,417us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x130014 refCount: 1
@1,866,616us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x128001]
@1,866,798us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,866,947us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483f8]
@1,867,097us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415364 count: 1
@1,867,264us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,867,640us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread created.
@1,868,071us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x138001]
@1,868,391us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x140015 refCount: 1
@1,868,581us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x138001]
@1,868,757us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,868,958us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48408]
@1,869,120us: [+0 T:0x40018528 S:0xbefff8b4] OG - Global_atexit> enter
(fxn=0x19810)
@1,869,284us: [+2 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.alg - ALG_init>
Exit
@1,869,436us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x19330)
@1,869,632us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x1c238)
@1,869,905us: [+6 T:0x40018528 S:0xbefff8d4] CE - Engine_init> CE debugging
on (CE_DEBUG=3; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
@1,870,088us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
(fxn=0x16d58)
@1,870,444us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x15c00)
@1,870,805us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x12d38)
@1,871,014us: [+0 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x0]
@1,871,205us: [+0 T:0x40018528 S:0xbefff8f4] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not active
(unset CE_DEBUG if you need TraceUtil)
@1,880,635us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@1,880,944us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@1,881,119us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> returning physAddr=0x0
@1,881,512us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> CMEM_getPhys(0x412cb000) = 0x0.
@1,881,892us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> return (0x0)
@1,889,122us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@1,889,346us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@1,889,514us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> returning physAddr=0x0
@1,889,826us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41373c00) = 0x0.
@1,890,130us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> return (0x0)
@1,897,283us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@1,897,567us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@1,897,756us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> returning physAddr=0x0
@1,898,071us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> CMEM_getPhys(0x4141c800) = 0x0.
@1,898,385us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> return (0x0)
@1,905,591us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open>
Enter('decode', 0x0, 0xbefff634)
@1,905,923us: [+0 T:0x40018528 S:0xbefff5ec] CE -
rserverOpen('./decodeCombo.x64P'), count = 0
@1,906,118us: [+0 T:0x40018528 S:0xbefff56c] OP - Process_create>
Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0xbefff638)
@1,907,328us: [+7 T:0x40018528 S:0xbefff56c] OP - Process_create> ERROR:
cannot access file ./decodeCombo.x64P
@1,907,698us: [+6 T:0x40018528 S:0xbefff5ec] CE - rserverOpen: can't start
'./decodeCombo.x64P'; Process_create failed
@1,907,884us: [+0 T:0x40018528 S:0xbefff5ec] CE -
rserverOpen('./decodeCombo.x64P'): 0x0 done.
@1,908,051us: [+0 T:0x40018528 S:0xbefff5cc] CE - Engine_close(0x485d8)
@1,908,313us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> return(0)
@2,071,878us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open>
Enter('decode', 0x0, 0x41cc5494)
@2,072,296us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
rserverOpen('./decodeCombo.x64P'), count = 0
@2,072,500us: [+0 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create>
Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0x41cc5498)
@2,072,781us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR:
cannot access file ./decodeCombo.x64P
@2,072,973us: [+6 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen: can't start
'./decodeCombo.x64P'; Process_create failed
@2,073,151us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
rserverOpen('./decodeCombo.x64P'): 0x0 done.
@2,073,327us: [+0 T:0x41cc5b60 S:0x41cc542c] CE - Engine_close(0x485d8)
@2,073,514us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> return(0)
@2,607,774us: [+0 T:0x40018528 S:0xbefff8dc] OG - Global_exit> enter
@2,607,990us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x12d38()...
@2,608,198us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x15c00()...
@2,608,412us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x16d58()...
@2,608,592us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1c238()...
@2,608,747us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x19330()...
@2,608,901us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x482d8]
@2,609,055us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,609,251us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x148000]
@2,609,437us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x10002, ref count: 1
@2,609,672us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x10002
@2,609,889us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x148000]
@2,610,071us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,610,229us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,610,375us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x482e8]
@2,610,527us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,610,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x150000]
@2,610,886us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x20003, ref count: 1
@2,611,111us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x20003
@2,611,321us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x150000]
@2,611,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,611,651us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,611,792us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x482f8]
@2,611,942us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,612,121us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x158000]
@2,612,294us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x30004, ref count: 1
@2,612,513us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x30004
@2,613,356us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x158000]
@2,613,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,613,766us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,613,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48308]
@2,614,109us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,614,312us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x160000]
@2,614,491us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x40005, ref count: 1
@2,614,716us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x40005
@2,614,886us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x160000]
@2,615,055us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,615,207us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,615,351us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48318]
@2,615,542us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,615,733us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x168000]
@2,615,908us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x50006, ref count: 1
@2,616,130us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x50006
@2,616,300us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x168000]
@2,616,471us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,616,624us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,616,771us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48328]
@2,616,961us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,617,148us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x170000]
@2,617,330us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x60007, ref count: 1
@2,617,685us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x60007
@2,617,883us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x170000]
@2,618,052us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,618,206us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,618,407us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48338]
@2,618,563us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,618,746us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x178000]
@2,618,918us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x70008, ref count: 1
@2,619,131us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x70008
@2,619,298us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x178000]
@2,619,469us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,619,623us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,619,800us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48348]
@2,619,959us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,620,140us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x180000]
@2,620,319us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x80009, ref count: 1
@2,620,537us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x80009
@2,620,704us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x180000]
@2,621,138us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,621,389us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,621,548us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48358]
@2,621,707us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,621,896us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x188000]
@2,622,073us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x9000a, ref count: 1
@2,622,304us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x9000a
@2,622,480us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x188000]
@2,622,689us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,622,850us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,622,996us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48368]
@2,623,147us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,623,329us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x190000]
@2,623,508us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xa000b, ref count: 1
@2,623,725us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xa000b
@2,623,892us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x190000]
@2,624,102us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,624,262us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,624,406us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48378]
@2,624,559us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,624,737us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x198000]
@2,624,915us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xb000c, ref count: 1
@2,625,135us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xb000c
@2,625,306us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x198000]
@2,625,515us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,625,676us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,625,820us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48388]
@2,625,969us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,626,146us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1a0000]
@2,626,322us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xc000d, ref count: 1
@2,626,538us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xc000d
@2,626,705us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1a0000]
@2,626,907us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,627,066us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,627,217us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48398]
@2,627,368us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,627,676us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1a8000]
@2,627,878us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xd000e, ref count: 1
@2,628,102us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xd000e
@2,628,305us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1a8000]
@2,628,494us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,628,649us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,628,974us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483a8]
@3,318,647us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,318,886us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1b0000]
@3,319,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xe000f, ref count: 1
@3,319,345us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xe000f
@3,319,557us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1b0000]
@3,319,736us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,319,887us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,320,029us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483b8]
@3,320,181us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,320,362us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1b8000]
@3,320,535us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xf0010, ref count: 1
@3,320,750us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xf0010
@3,320,960us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1b8000]
@3,321,140us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,321,291us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,321,439us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483c8]
@3,321,592us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,321,767us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1c0000]
@3,321,942us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x100011, ref count: 1
@3,322,156us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x100011
@3,322,359us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1c0000]
@3,322,540us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,322,696us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,322,841us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483d8]
@3,322,988us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,323,166us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1c8000]
@3,323,340us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x110012, ref count: 1
@3,323,552us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x110012
@3,323,718us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1c8000]
@3,323,930us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,324,083us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,324,234us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483e8]
@3,324,384us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,324,561us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1d0000]
@3,324,740us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x120013, ref count: 1
@3,324,958us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x120013
@3,325,128us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1d0000]
@3,325,344us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,325,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,325,646us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483f8]
@3,325,794us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,326,227us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1d8000]
@3,326,463us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x130014, ref count: 1
@3,326,745us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x130014
@3,326,928us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1d8000]
@3,327,103us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,327,263us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,327,408us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48408]
@3,327,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,327,910us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1e0000]
@3,328,137us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x140015, ref count: 1
@3,328,371us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x140015
@3,328,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1e0000]
@3,328,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,328,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,329,017us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x19810()...
@3,329,177us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1a028()...
@3,329,327us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1e59c()...
@3,329,743us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread terminating
@3,330,253us: [+0 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> Enter
(task=0x48180)
@3,330,566us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
pthread_cancel (0x3)
@3,330,761us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
pthread_join (0x0)
@3,330,979us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_delete> Exit
(task=0x48180)
@3,331,149us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1c0e8()...
@3,331,371us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1d618()...
@3,331,549us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1b258()...
@3,331,708us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1d148()...
@3,331,862us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1c45c()...









On Fri, Feb 4, 2011 at 3:01 AM, Tivy, Robert <rtivy at ti.com> wrote:

>  More details about the failure to open the codec engine are needed.  You
> can generate more info by setting the environment variable CE_DEBUG=3 and
> re-running your app:
>     % export CE_DEBUG=3
>     % ./decode ...
>
> Regards,
>
> - Rob
>
>  ------------------------------
> *From:* davinci-linux-open-source-bounces+rtivy=ti.com@
> linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy<davinci-linux-open-source-bounces%2Brtivy>
> =ti.com at linux.davincidsp.com] *On Behalf Of *Aditya Barawkar
> *Sent:* Thursday, February 03, 2011 11:56 AM
> *To:* davinci-linux-open-source at linux.davincidsp.com
> *Subject:* Error While Running Demos
>
> I'm trying to run demos for encode decode which came with DVSDK v1.30.01
> for DM6446 EVM
>
> When i boot the board then I'm not seeing any demos which should run
> automatically as per the TI doc.
>
> So i opted to run the demos using command line.
>
> First i loaded all the modules which are required to run the demos
> Modules loaded :: cmemk.ko and dsplinkk.ko
>
> root at 10.42.43.10:/opt/demos/dm6446/decode/release# lsmod
> Module                  Size  Used by
> cmemk                  17368  0
> dsplinkk               96360  0
>
> But when i excute command to run the demo ::: ./decode -v
> /opt/demos/dm6446/data/videos/davincieffect_ntsc.m2v -k
> i get following error::
>
>
> Decode demo started.
> TraceUtil> Error: Failed to open codec engine "decode"
> TraceUtil> Error: Aborting TraceUtil_start
> Decode Error: Failed to open codec engine decode
> Decode Error: Failed to open codec engine decode
> root at 10.42.43.10:/opt/demos/dm6446/decode/release#
>
> Please help me out on how to make the sample demos run.
>
> Thanks in advance.!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/faf56307/attachment-0001.html>

From adityabarawkar at gmail.com  Thu Feb  3 23:11:16 2011
From: adityabarawkar at gmail.com (Aditya Barawkar)
Date: Fri, 4 Feb 2011 10:41:16 +0530
Subject: Error While Running Demos
In-Reply-To: <AANLkTin0qPs+wuomtd3dpyptueQiWdmm7=pQS-LeAD5W@mail.gmail.com>
References: <AANLkTimhZy=SLnZvQm=zTqQe9XKQi3Ofkkof2xwFr0xW@mail.gmail.com>
	<6B8224E84039B140AA662F0BB03616430188FA63B9@dlee04.ent.ti.com>
	<AANLkTin0qPs+wuomtd3dpyptueQiWdmm7=pQS-LeAD5W@mail.gmail.com>
Message-ID: <AANLkTinQKoBe0CHVVdXOQA-_RC02ePkV9mG80pEaoA4K@mail.gmail.com>

Sorry log in last mail was without inserting two modules cmemk.ko &
dsplinkk.ko

This log was generated after inserting above two modules.

Thanks.

Decode demo started.
@0,448,089us: [+4 T:0x40018528 S:0xbefff8cc] OG - Global_init> This program
was built with the following packages:
@0,448,733us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
gnu.targets.rts470MV
(/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/gnu/targets/rts470MV/)
[1,0,0,0,1193542866293]
@0,448,978us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.g711dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/)
[1,0,0,1210922571648]
@0,449,140us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.aachedec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/)
[1,0,0,1210922563756]
@0,449,289us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mp3dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/)
[1,0,0,1210922592446]
@0,449,433us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.h264dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/)
[1,0,0,1210922581723]
@0,449,624us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mpeg2dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/)
[1,0,0,1210922600503]
@0,449,773us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mpeg4dec
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/)
[1,0,0,1210922605176]
@0,449,914us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.xdais.dm(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/dm/)
[1,0,4,0]
@0,450,046us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/)
[1,2,1,0]
@0,450,184us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.utils.trace
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/utils/trace/)
[1,0,0,0]
@0,450,325us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.utils.xdm
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/xdm/)
[1,0,1,1200333457442]
@0,450,464us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package dsplink.gpp
(/db/atree/library/trees/linuxdemos-a46x/imports/dsplink-dm644x-v140-05p1-prebuilt/packages/dsplink/gpp/)
[1,1,0,0]
@0,450,607us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.linuxutils.cmem
(/db/atree/library/trees/linuxdemos-a46x/imports/build/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/)
[2,0,0,0]
@0,450,750us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.fc.acpy3
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/acpy3/)
[1,0,2,0]
@0,450,893us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.fc.dman3
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/dman3/)
[1,0,3,0]
@0,451,035us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.osal
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/osal/)
[2,0,1,1200333329943]
@0,451,178us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.alg
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/alg/)
[1,0,0,1200332939285]
@0,451,317us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.catalog.c470
(/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/catalog/c470/)
[1,0,1,0,1192229332845]
@0,451,458us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.platforms.evmDM6446
(/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/platforms/evmDM6446/)
[1,0,0,1,1192229600615]
@0,451,599us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/)
[1,0,5,1200332924185]
@0,452,339us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.speech
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/speech/)
[1,0,1,1200333353059]
@0,452,548us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.g711dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/ce/)
[1,0,0,1210922072831]
@0,452,703us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.audio
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/audio/)
[1,0,1,1200332949776]
@0,452,849us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.aachedec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/ce/)
[1,0,0,1210922061774]
@0,452,999us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mp3dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/ce/)
[1,0,0,1210922155277]
@0,453,146us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.video
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/video/)
[1,0,2,1200333474655]
@0,453,291us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.h264dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/ce/)
[1,0,0,1210922114696]
@0,453,437us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mpeg2dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/ce/)
[1,0,0,1210922171166]
@0,453,584us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.codecs.mpeg4dec.ce
(/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/ce/)
[1,0,0,1210922199273]
@0,453,731us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.bioslog
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/bioslog/)
[1,0,1,1200332966901]
@0,453,873us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
ti.sdo.ce.utils.trace
(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/trace/)
[1,0,1,1200333448031]
@0,454,016us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package decode_config
(/db/atree/library/trees/linuxdemos-a46x/imports/build/demos/dm6446/decode/decode_config/)
[]
@0,454,198us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x1d148)
@0,454,354us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c41534f]
@0,454,700us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x0]
@0,456,366us: [+7 T:0x40018528 S:0xbefff8d4] OM - Memory_init> ERROR: Failed
to initialize CMEM
@0,456,616us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
(fxn=0x1b258)
@0,456,905us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
(fxn=0x1d618)
@0,457,251us: [+0 T:0x40018528 S:0xbefff8cc] OG - Global_atexit> enter
(fxn=0x1c0e8)
@0,457,710us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Enter
(fxn=0x1e9fc, attrs=0x0)
@0,458,813us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Exit
(task=0x48180)
@0,459,038us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x1e59c)
@0,459,390us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x1a028)
@0,459,636us: [+2 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.alg - ALG_init>
Enter
@0,459,796us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415351 count: 1
@0,459,964us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,460,153us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x8001]
@0,461,093us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x10002 refCount: 1
@0,461,328us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x8001]
@0,461,513us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,461,665us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x482d8]
@0,461,817us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415352 count: 1
@0,461,993us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,462,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x18001]
@0,462,507us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x20003 refCount: 1
@0,462,689us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x18001]
@0,462,859us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,463,008us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x482e8]
@0,463,164us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415353 count: 1
@0,463,334us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,463,519us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x28001]
@0,463,767us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x30004 refCount: 1
@0,463,943us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x28001]
@0,464,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,464,254us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x482f8]
@0,464,405us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415354 count: 1
@0,464,577us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,464,764us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x38001]
@0,465,017us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x40005 refCount: 1
@0,465,199us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x38001]
@0,465,372us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,465,523us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48308]
@0,465,671us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415355 count: 1
@0,465,837us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,466,012us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x48001]
@0,466,296us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x50006 refCount: 1
@0,466,475us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x48001]
@0,466,645us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,466,786us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48318]
@0,466,932us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415356 count: 1
@0,467,096us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@0,467,284us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x58001]
@0,467,656us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x60007 refCount: 1
@0,467,857us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x58001]
@0,468,034us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@0,468,182us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48328]
@0,468,334us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415357 count: 1
@0,468,507us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,159,411us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x68001]
@1,159,729us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x70008 refCount: 1
@1,159,915us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x68001]
@1,160,092us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,160,248us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48338]
@1,160,403us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415358 count: 1
@1,160,620us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,160,823us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x78001]
@1,161,084us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x80009 refCount: 1
@1,161,272us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x78001]
@1,161,447us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,161,598us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48348]
@1,161,749us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415359 count: 1
@1,161,919us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,162,157us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x88001]
@1,162,414us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x9000a refCount: 1
@1,162,597us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x88001]
@1,162,770us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,162,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48358]
@1,163,067us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535a count: 1
@1,163,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,163,459us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x98001]
@1,163,727us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xa000b refCount: 1
@1,163,907us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x98001]
@1,164,077us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,164,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48368]
@1,164,383us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535b count: 1
@1,164,548us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,164,736us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xa8001]
@1,165,047us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xb000c refCount: 1
@1,165,237us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xa8001]
@1,165,411us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,165,557us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48378]
@1,165,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535c count: 1
@1,165,875us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,166,063us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xb8001]
@1,166,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xc000d refCount: 1
@1,166,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xb8001]
@1,166,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,166,852us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48388]
@1,167,043us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535d count: 1
@1,167,682us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,167,938us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xc8001]
@1,168,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xd000e refCount: 1
@1,168,418us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xc8001]
@1,168,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,168,745us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48398]
@1,168,893us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535e count: 1
@1,169,102us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,169,308us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xd8001]
@1,169,575us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xe000f refCount: 1
@1,169,752us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xd8001]
@1,169,923us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,170,069us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483a8]
@1,170,222us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c41535f count: 1
@1,170,392us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,170,624us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xe8001]
@1,170,896us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0xf0010 refCount: 1
@1,171,076us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xe8001]
@1,171,253us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,171,404us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483b8]
@1,171,553us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415360 count: 1
@1,171,720us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,171,908us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0xf8001]
@1,172,212us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x100011 refCount: 1
@1,172,397us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0xf8001]
@1,172,572us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,172,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483c8]
@1,172,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415361 count: 1
@1,173,034us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,173,224us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x108001]
@1,173,525us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x110012 refCount: 1
@1,173,712us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x108001]
@1,173,889us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,174,040us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483d8]
@1,174,195us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415362 count: 1
@1,174,366us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,174,554us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x118001]
@1,174,848us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x120013 refCount: 1
@1,175,035us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x118001]
@1,175,211us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,175,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483e8]
@1,175,795us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415363 count: 1
@1,865,769us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,866,065us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x128001]
@1,866,417us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x130014 refCount: 1
@1,866,616us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x128001]
@1,866,798us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,866,947us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x483f8]
@1,867,097us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> key: 0x4c415364 count: 1
@1,867,264us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@1,867,640us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread created.
@1,868,071us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x138001]
@1,868,391us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_create> semId: 0x140015 refCount: 1
@1,868,581us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x138001]
@1,868,757us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@1,868,958us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_create> sem[0x48408]
@1,869,120us: [+0 T:0x40018528 S:0xbefff8b4] OG - Global_atexit> enter
(fxn=0x19810)
@1,869,284us: [+2 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.alg - ALG_init>
Exit
@1,869,436us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x19330)
@1,869,632us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x1c238)
@1,869,905us: [+6 T:0x40018528 S:0xbefff8d4] CE - Engine_init> CE debugging
on (CE_DEBUG=3; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
@1,870,088us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
(fxn=0x16d58)
@1,870,444us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x15c00)
@1,870,805us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
(fxn=0x12d38)
@1,871,014us: [+0 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x0]
@1,871,205us: [+0 T:0x40018528 S:0xbefff8f4] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not active
(unset CE_DEBUG if you need TraceUtil)
@1,880,635us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@1,880,944us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@1,881,119us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> returning physAddr=0x0
@1,881,512us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> CMEM_getPhys(0x412cb000) = 0x0.
@1,881,892us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> return (0x0)
@1,889,122us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@1,889,346us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@1,889,514us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> returning physAddr=0x0
@1,889,826us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41373c00) = 0x0.
@1,890,130us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> return (0x0)
@1,897,283us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@1,897,567us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@1,897,756us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory__getPhysicalAddress> returning physAddr=0x0
@1,898,071us: [+1 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> CMEM_getPhys(0x4141c800) = 0x0.
@1,898,385us: [+0 T:0x412cab60 S:0x412ca27c] OM -
Memory_getBufferPhysicalAddress> return (0x0)
@1,905,591us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open>
Enter('decode', 0x0, 0xbefff634)
@1,905,923us: [+0 T:0x40018528 S:0xbefff5ec] CE -
rserverOpen('./decodeCombo.x64P'), count = 0
@1,906,118us: [+0 T:0x40018528 S:0xbefff56c] OP - Process_create>
Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0xbefff638)
@1,907,328us: [+7 T:0x40018528 S:0xbefff56c] OP - Process_create> ERROR:
cannot access file ./decodeCombo.x64P
@1,907,698us: [+6 T:0x40018528 S:0xbefff5ec] CE - rserverOpen: can't start
'./decodeCombo.x64P'; Process_create failed
@1,907,884us: [+0 T:0x40018528 S:0xbefff5ec] CE -
rserverOpen('./decodeCombo.x64P'): 0x0 done.
@1,908,051us: [+0 T:0x40018528 S:0xbefff5cc] CE - Engine_close(0x485d8)
@1,908,313us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> return(0)
@2,071,878us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open>
Enter('decode', 0x0, 0x41cc5494)
@2,072,296us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
rserverOpen('./decodeCombo.x64P'), count = 0
@2,072,500us: [+0 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create>
Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0x41cc5498)
@2,072,781us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR:
cannot access file ./decodeCombo.x64P
@2,072,973us: [+6 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen: can't start
'./decodeCombo.x64P'; Process_create failed
@2,073,151us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
rserverOpen('./decodeCombo.x64P'): 0x0 done.
@2,073,327us: [+0 T:0x41cc5b60 S:0x41cc542c] CE - Engine_close(0x485d8)
@2,073,514us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> return(0)
@2,607,774us: [+0 T:0x40018528 S:0xbefff8dc] OG - Global_exit> enter
@2,607,990us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x12d38()...
@2,608,198us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x15c00()...
@2,608,412us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x16d58()...
@2,608,592us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1c238()...
@2,608,747us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x19330()...
@2,608,901us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x482d8]
@2,609,055us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,609,251us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x148000]
@2,609,437us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x10002, ref count: 1
@2,609,672us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x10002
@2,609,889us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x148000]
@2,610,071us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,610,229us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,610,375us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x482e8]
@2,610,527us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,610,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x150000]
@2,610,886us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x20003, ref count: 1
@2,611,111us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x20003
@2,611,321us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x150000]
@2,611,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,611,651us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,611,792us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x482f8]
@2,611,942us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,612,121us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x158000]
@2,612,294us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x30004, ref count: 1
@2,612,513us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x30004
@2,613,356us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x158000]
@2,613,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,613,766us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,613,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48308]
@2,614,109us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,614,312us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x160000]
@2,614,491us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x40005, ref count: 1
@2,614,716us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x40005
@2,614,886us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x160000]
@2,615,055us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,615,207us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,615,351us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48318]
@2,615,542us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,615,733us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x168000]
@2,615,908us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x50006, ref count: 1
@2,616,130us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x50006
@2,616,300us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x168000]
@2,616,471us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,616,624us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,616,771us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48328]
@2,616,961us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,617,148us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x170000]
@2,617,330us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x60007, ref count: 1
@2,617,685us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x60007
@2,617,883us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x170000]
@2,618,052us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,618,206us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,618,407us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48338]
@2,618,563us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,618,746us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x178000]
@2,618,918us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x70008, ref count: 1
@2,619,131us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x70008
@2,619,298us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x178000]
@2,619,469us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,619,623us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,619,800us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48348]
@2,619,959us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,620,140us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x180000]
@2,620,319us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x80009, ref count: 1
@2,620,537us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x80009
@2,620,704us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x180000]
@2,621,138us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,621,389us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,621,548us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48358]
@2,621,707us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,621,896us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x188000]
@2,622,073us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x9000a, ref count: 1
@2,622,304us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x9000a
@2,622,480us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x188000]
@2,622,689us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,622,850us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,622,996us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48368]
@2,623,147us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,623,329us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x190000]
@2,623,508us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xa000b, ref count: 1
@2,623,725us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xa000b
@2,623,892us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x190000]
@2,624,102us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,624,262us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,624,406us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48378]
@2,624,559us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,624,737us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x198000]
@2,624,915us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xb000c, ref count: 1
@2,625,135us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xb000c
@2,625,306us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x198000]
@2,625,515us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,625,676us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,625,820us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48388]
@2,625,969us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,626,146us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1a0000]
@2,626,322us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xc000d, ref count: 1
@2,626,538us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xc000d
@2,626,705us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1a0000]
@2,626,907us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,627,066us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,627,217us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48398]
@2,627,368us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@2,627,676us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1a8000]
@2,627,878us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xd000e, ref count: 1
@2,628,102us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xd000e
@2,628,305us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1a8000]
@2,628,494us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@2,628,649us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@2,628,974us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483a8]
@3,318,647us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,318,886us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1b0000]
@3,319,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xe000f, ref count: 1
@3,319,345us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xe000f
@3,319,557us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1b0000]
@3,319,736us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,319,887us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,320,029us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483b8]
@3,320,181us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,320,362us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1b8000]
@3,320,535us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0xf0010, ref count: 1
@3,320,750us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0xf0010
@3,320,960us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1b8000]
@3,321,140us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,321,291us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,321,439us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483c8]
@3,321,592us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,321,767us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1c0000]
@3,321,942us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x100011, ref count: 1
@3,322,156us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x100011
@3,322,359us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1c0000]
@3,322,540us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,322,696us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,322,841us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483d8]
@3,322,988us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,323,166us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1c8000]
@3,323,340us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x110012, ref count: 1
@3,323,552us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x110012
@3,323,718us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1c8000]
@3,323,930us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,324,083us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,324,234us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483e8]
@3,324,384us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,324,561us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1d0000]
@3,324,740us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x120013, ref count: 1
@3,324,958us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x120013
@3,325,128us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1d0000]
@3,325,344us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,325,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,325,646us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x483f8]
@3,325,794us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,326,227us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1d8000]
@3,326,463us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x130014, ref count: 1
@3,326,745us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x130014
@3,326,928us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1d8000]
@3,327,103us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,327,263us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,327,408us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
Sem_delete> sem[0x48408]
@3,327,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
Sem_enterCS> key[0x4c415350]
@3,327,910us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
Sem_enterCS> id[0x1e0000]
@3,328,137us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> sem: 0x140015, ref count: 1
@3,328,371us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
Sem_delete> Deleted semaphore: 0x140015
@3,328,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
Sem_exitCS> id[0x1e0000]
@3,328,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_exitCS
@3,328,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
Sem_delete>
@3,329,017us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x19810()...
@3,329,177us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1a028()...
@3,329,327us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1e59c()...
@3,329,743us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread terminating
@3,330,253us: [+0 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> Enter
(task=0x48180)
@3,330,566us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
pthread_cancel (0x3)
@3,330,761us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
pthread_join (0x0)
@3,330,979us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_delete> Exit
(task=0x48180)
@3,331,149us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1c0e8()...
@3,331,371us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1d618()...
@3,331,549us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1b258()...
@3,331,708us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1d148()...
@3,331,862us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
function *0x1c45c()...



On Fri, Feb 4, 2011 at 10:34 AM, Aditya Barawkar
<adityabarawkar at gmail.com>wrote:

>
> Thanks for looking into problem.
>
> here is the log with CE_DEBUG=3
>
>
>
>
>
> Decode demo started.
> @0,448,089us: [+4 T:0x40018528 S:0xbefff8cc] OG - Global_init> This program
> was built with the following packages:
> @0,448,733us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> gnu.targets.rts470MV
> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/gnu/targets/rts470MV/)
> [1,0,0,0,1193542866293]
> @0,448,978us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.g711dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/)
> [1,0,0,1210922571648]
> @0,449,140us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.aachedec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/)
> [1,0,0,1210922563756]
> @0,449,289us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mp3dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/)
> [1,0,0,1210922592446]
> @0,449,433us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.h264dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/)
> [1,0,0,1210922581723]
> @0,449,624us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mpeg2dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/)
> [1,0,0,1210922600503]
> @0,449,773us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mpeg4dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/)
> [1,0,0,1210922605176]
> @0,449,914us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais.dm(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/dm/)
> [1,0,4,0]
> @0,450,046us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/)
> [1,2,1,0]
> @0,450,184us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.utils.trace
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/utils/trace/)
> [1,0,0,0]
> @0,450,325us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.utils.xdm
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/xdm/)
> [1,0,1,1200333457442]
> @0,450,464us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package dsplink.gpp
> (/db/atree/library/trees/linuxdemos-a46x/imports/dsplink-dm644x-v140-05p1-prebuilt/packages/dsplink/gpp/)
> [1,1,0,0]
> @0,450,607us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.linuxutils.cmem
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/)
> [2,0,0,0]
> @0,450,750us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.fc.acpy3
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/acpy3/)
> [1,0,2,0]
> @0,450,893us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.fc.dman3
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/dman3/)
> [1,0,3,0]
> @0,451,035us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.osal
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/osal/)
> [2,0,1,1200333329943]
> @0,451,178us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.alg
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/alg/)
> [1,0,0,1200332939285]
> @0,451,317us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.catalog.c470
> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/catalog/c470/)
> [1,0,1,0,1192229332845]
> @0,451,458us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.platforms.evmDM6446
> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/platforms/evmDM6446/)
> [1,0,0,1,1192229600615]
> @0,451,599us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/)
> [1,0,5,1200332924185]
> @0,452,339us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.speech
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/speech/)
> [1,0,1,1200333353059]
> @0,452,548us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.g711dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/ce/)
> [1,0,0,1210922072831]
> @0,452,703us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.audio
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/audio/)
> [1,0,1,1200332949776]
> @0,452,849us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.aachedec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/ce/)
> [1,0,0,1210922061774]
> @0,452,999us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mp3dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/ce/)
> [1,0,0,1210922155277]
> @0,453,146us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.video
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/video/)
> [1,0,2,1200333474655]
> @0,453,291us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.h264dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/ce/)
> [1,0,0,1210922114696]
> @0,453,437us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mpeg2dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/ce/)
> [1,0,0,1210922171166]
> @0,453,584us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mpeg4dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/ce/)
> [1,0,0,1210922199273]
> @0,453,731us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.bioslog
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/bioslog/)
> [1,0,1,1200332966901]
> @0,453,873us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.utils.trace
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/trace/)
> [1,0,1,1200333448031]
> @0,454,016us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package decode_config
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/demos/dm6446/decode/decode_config/)
> []
> @0,454,198us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x1d148)
> @0,454,354us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c41534f]
> @0,454,700us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x0]
> @0,456,366us: [+7 T:0x40018528 S:0xbefff8d4] OM - Memory_init> ERROR:
> Failed to initialize CMEM
> @0,456,616us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
> (fxn=0x1b258)
> @0,456,905us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
> (fxn=0x1d618)
> @0,457,251us: [+0 T:0x40018528 S:0xbefff8cc] OG - Global_atexit> enter
> (fxn=0x1c0e8)
> @0,457,710us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Enter
> (fxn=0x1e9fc, attrs=0x0)
> @0,458,813us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Exit
> (task=0x48180)
> @0,459,038us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x1e59c)
> @0,459,390us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x1a028)
> @0,459,636us: [+2 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.alg - ALG_init>
> Enter
> @0,459,796us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415351 count: 1
> @0,459,964us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,460,153us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x8001]
> @0,461,093us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x10002 refCount: 1
> @0,461,328us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x8001]
> @0,461,513us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,461,665us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x482d8]
> @0,461,817us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415352 count: 1
> @0,461,993us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,462,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x18001]
> @0,462,507us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x20003 refCount: 1
> @0,462,689us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x18001]
> @0,462,859us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,463,008us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x482e8]
> @0,463,164us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415353 count: 1
> @0,463,334us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,463,519us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x28001]
> @0,463,767us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x30004 refCount: 1
> @0,463,943us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x28001]
> @0,464,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,464,254us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x482f8]
> @0,464,405us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415354 count: 1
> @0,464,577us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,464,764us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x38001]
> @0,465,017us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x40005 refCount: 1
> @0,465,199us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x38001]
> @0,465,372us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,465,523us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48308]
> @0,465,671us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415355 count: 1
> @0,465,837us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,466,012us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x48001]
> @0,466,296us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x50006 refCount: 1
> @0,466,475us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x48001]
> @0,466,645us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,466,786us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48318]
> @0,466,932us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415356 count: 1
> @0,467,096us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,467,284us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x58001]
> @0,467,656us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x60007 refCount: 1
> @0,467,857us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x58001]
> @0,468,034us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,468,182us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48328]
> @0,468,334us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415357 count: 1
> @0,468,507us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,159,411us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x68001]
> @1,159,729us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x70008 refCount: 1
> @1,159,915us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x68001]
> @1,160,092us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,160,248us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48338]
> @1,160,403us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415358 count: 1
> @1,160,620us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,160,823us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x78001]
> @1,161,084us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x80009 refCount: 1
> @1,161,272us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x78001]
> @1,161,447us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,161,598us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48348]
> @1,161,749us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415359 count: 1
> @1,161,919us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,162,157us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x88001]
> @1,162,414us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x9000a refCount: 1
> @1,162,597us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x88001]
> @1,162,770us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,162,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48358]
> @1,163,067us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535a count: 1
> @1,163,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,163,459us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x98001]
> @1,163,727us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xa000b refCount: 1
> @1,163,907us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x98001]
> @1,164,077us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,164,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48368]
> @1,164,383us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535b count: 1
> @1,164,548us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,164,736us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xa8001]
> @1,165,047us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xb000c refCount: 1
> @1,165,237us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xa8001]
> @1,165,411us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,165,557us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48378]
> @1,165,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535c count: 1
> @1,165,875us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,166,063us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xb8001]
> @1,166,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xc000d refCount: 1
> @1,166,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xb8001]
> @1,166,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,166,852us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48388]
> @1,167,043us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535d count: 1
> @1,167,682us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,167,938us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xc8001]
> @1,168,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xd000e refCount: 1
> @1,168,418us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xc8001]
> @1,168,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,168,745us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48398]
> @1,168,893us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535e count: 1
> @1,169,102us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,169,308us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xd8001]
> @1,169,575us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xe000f refCount: 1
> @1,169,752us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xd8001]
> @1,169,923us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,170,069us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483a8]
> @1,170,222us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535f count: 1
> @1,170,392us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,170,624us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xe8001]
> @1,170,896us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xf0010 refCount: 1
> @1,171,076us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xe8001]
> @1,171,253us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,171,404us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483b8]
> @1,171,553us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415360 count: 1
> @1,171,720us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,171,908us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xf8001]
> @1,172,212us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x100011 refCount: 1
> @1,172,397us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xf8001]
> @1,172,572us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,172,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483c8]
> @1,172,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415361 count: 1
> @1,173,034us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,173,224us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x108001]
> @1,173,525us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x110012 refCount: 1
> @1,173,712us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x108001]
> @1,173,889us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,174,040us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483d8]
> @1,174,195us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415362 count: 1
> @1,174,366us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,174,554us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x118001]
> @1,174,848us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x120013 refCount: 1
> @1,175,035us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x118001]
> @1,175,211us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,175,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483e8]
> @1,175,795us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415363 count: 1
> @1,865,769us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,866,065us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x128001]
> @1,866,417us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x130014 refCount: 1
> @1,866,616us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x128001]
> @1,866,798us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,866,947us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483f8]
> @1,867,097us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415364 count: 1
> @1,867,264us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,867,640us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread created.
> @1,868,071us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x138001]
> @1,868,391us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x140015 refCount: 1
> @1,868,581us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x138001]
> @1,868,757us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,868,958us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48408]
> @1,869,120us: [+0 T:0x40018528 S:0xbefff8b4] OG - Global_atexit> enter
> (fxn=0x19810)
> @1,869,284us: [+2 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.alg - ALG_init>
> Exit
> @1,869,436us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x19330)
> @1,869,632us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x1c238)
> @1,869,905us: [+6 T:0x40018528 S:0xbefff8d4] CE - Engine_init> CE debugging
> on (CE_DEBUG=3; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
> @1,870,088us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
> (fxn=0x16d58)
> @1,870,444us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x15c00)
> @1,870,805us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x12d38)
> @1,871,014us: [+0 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x0]
> @1,871,205us: [+0 T:0x40018528 S:0xbefff8f4] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not active
> (unset CE_DEBUG if you need TraceUtil)
> @1,880,635us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
> @1,880,944us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
> @1,881,119us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> returning physAddr=0x0
> @1,881,512us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x412cb000) = 0x0.
> @1,881,892us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> return (0x0)
> @1,889,122us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
> @1,889,346us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
> @1,889,514us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> returning physAddr=0x0
> @1,889,826us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41373c00) = 0x0.
> @1,890,130us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> return (0x0)
> @1,897,283us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
> @1,897,567us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
> @1,897,756us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> returning physAddr=0x0
> @1,898,071us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x4141c800) = 0x0.
> @1,898,385us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> return (0x0)
> @1,905,591us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open>
> Enter('decode', 0x0, 0xbefff634)
> @1,905,923us: [+0 T:0x40018528 S:0xbefff5ec] CE -
> rserverOpen('./decodeCombo.x64P'), count = 0
> @1,906,118us: [+0 T:0x40018528 S:0xbefff56c] OP - Process_create>
> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0xbefff638)
> @1,907,328us: [+7 T:0x40018528 S:0xbefff56c] OP - Process_create> ERROR:
> cannot access file ./decodeCombo.x64P
> @1,907,698us: [+6 T:0x40018528 S:0xbefff5ec] CE - rserverOpen: can't start
> './decodeCombo.x64P'; Process_create failed
> @1,907,884us: [+0 T:0x40018528 S:0xbefff5ec] CE -
> rserverOpen('./decodeCombo.x64P'): 0x0 done.
> @1,908,051us: [+0 T:0x40018528 S:0xbefff5cc] CE - Engine_close(0x485d8)
> @1,908,313us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> return(0)
> @2,071,878us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open>
> Enter('decode', 0x0, 0x41cc5494)
> @2,072,296us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
> rserverOpen('./decodeCombo.x64P'), count = 0
> @2,072,500us: [+0 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create>
> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0x41cc5498)
> @2,072,781us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR:
> cannot access file ./decodeCombo.x64P
> @2,072,973us: [+6 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen: can't start
> './decodeCombo.x64P'; Process_create failed
> @2,073,151us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
> rserverOpen('./decodeCombo.x64P'): 0x0 done.
> @2,073,327us: [+0 T:0x41cc5b60 S:0x41cc542c] CE - Engine_close(0x485d8)
> @2,073,514us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> return(0)
> @2,607,774us: [+0 T:0x40018528 S:0xbefff8dc] OG - Global_exit> enter
> @2,607,990us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x12d38()...
> @2,608,198us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x15c00()...
> @2,608,412us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x16d58()...
> @2,608,592us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1c238()...
> @2,608,747us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x19330()...
> @2,608,901us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x482d8]
> @2,609,055us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,609,251us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x148000]
> @2,609,437us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x10002, ref count: 1
> @2,609,672us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x10002
> @2,609,889us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x148000]
> @2,610,071us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,610,229us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,610,375us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x482e8]
> @2,610,527us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,610,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x150000]
> @2,610,886us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x20003, ref count: 1
> @2,611,111us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x20003
> @2,611,321us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x150000]
> @2,611,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,611,651us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,611,792us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x482f8]
> @2,611,942us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,612,121us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x158000]
> @2,612,294us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x30004, ref count: 1
> @2,612,513us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x30004
> @2,613,356us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x158000]
> @2,613,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,613,766us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,613,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48308]
> @2,614,109us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,614,312us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x160000]
> @2,614,491us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x40005, ref count: 1
> @2,614,716us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x40005
> @2,614,886us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x160000]
> @2,615,055us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,615,207us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,615,351us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48318]
> @2,615,542us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,615,733us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x168000]
> @2,615,908us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x50006, ref count: 1
> @2,616,130us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x50006
> @2,616,300us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x168000]
> @2,616,471us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,616,624us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,616,771us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48328]
> @2,616,961us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,617,148us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x170000]
> @2,617,330us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x60007, ref count: 1
> @2,617,685us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x60007
> @2,617,883us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x170000]
> @2,618,052us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,618,206us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,618,407us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48338]
> @2,618,563us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,618,746us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x178000]
> @2,618,918us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x70008, ref count: 1
> @2,619,131us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x70008
> @2,619,298us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x178000]
> @2,619,469us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,619,623us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,619,800us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48348]
> @2,619,959us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,620,140us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x180000]
> @2,620,319us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x80009, ref count: 1
> @2,620,537us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x80009
> @2,620,704us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x180000]
> @2,621,138us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,621,389us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,621,548us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48358]
> @2,621,707us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,621,896us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x188000]
> @2,622,073us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x9000a, ref count: 1
> @2,622,304us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x9000a
> @2,622,480us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x188000]
> @2,622,689us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,622,850us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,622,996us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48368]
> @2,623,147us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,623,329us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x190000]
> @2,623,508us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xa000b, ref count: 1
> @2,623,725us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xa000b
> @2,623,892us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x190000]
> @2,624,102us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,624,262us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,624,406us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48378]
> @2,624,559us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,624,737us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x198000]
> @2,624,915us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xb000c, ref count: 1
> @2,625,135us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xb000c
> @2,625,306us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x198000]
> @2,625,515us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,625,676us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,625,820us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48388]
> @2,625,969us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,626,146us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1a0000]
> @2,626,322us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xc000d, ref count: 1
> @2,626,538us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xc000d
> @2,626,705us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1a0000]
> @2,626,907us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,627,066us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,627,217us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48398]
> @2,627,368us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,627,676us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1a8000]
> @2,627,878us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xd000e, ref count: 1
> @2,628,102us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xd000e
> @2,628,305us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1a8000]
> @2,628,494us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,628,649us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,628,974us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483a8]
> @3,318,647us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,318,886us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1b0000]
> @3,319,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xe000f, ref count: 1
> @3,319,345us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xe000f
> @3,319,557us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1b0000]
> @3,319,736us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,319,887us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,320,029us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483b8]
> @3,320,181us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,320,362us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1b8000]
> @3,320,535us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xf0010, ref count: 1
> @3,320,750us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xf0010
> @3,320,960us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1b8000]
> @3,321,140us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,321,291us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,321,439us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483c8]
> @3,321,592us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,321,767us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1c0000]
> @3,321,942us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x100011, ref count: 1
> @3,322,156us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x100011
> @3,322,359us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1c0000]
> @3,322,540us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,322,696us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,322,841us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483d8]
> @3,322,988us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,323,166us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1c8000]
> @3,323,340us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x110012, ref count: 1
> @3,323,552us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x110012
> @3,323,718us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1c8000]
> @3,323,930us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,324,083us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,324,234us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483e8]
> @3,324,384us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,324,561us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1d0000]
> @3,324,740us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x120013, ref count: 1
> @3,324,958us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x120013
> @3,325,128us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1d0000]
> @3,325,344us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,325,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,325,646us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483f8]
> @3,325,794us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,326,227us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1d8000]
> @3,326,463us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x130014, ref count: 1
> @3,326,745us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x130014
> @3,326,928us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1d8000]
> @3,327,103us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,327,263us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,327,408us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48408]
> @3,327,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,327,910us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1e0000]
> @3,328,137us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x140015, ref count: 1
> @3,328,371us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x140015
> @3,328,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1e0000]
> @3,328,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,328,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,329,017us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x19810()...
> @3,329,177us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1a028()...
> @3,329,327us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1e59c()...
> @3,329,743us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread
> terminating
> @3,330,253us: [+0 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> Enter
> (task=0x48180)
> @3,330,566us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
> pthread_cancel (0x3)
> @3,330,761us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
> pthread_join (0x0)
> @3,330,979us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_delete> Exit
> (task=0x48180)
> @3,331,149us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1c0e8()...
> @3,331,371us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1d618()...
> @3,331,549us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1b258()...
> @3,331,708us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1d148()...
> @3,331,862us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1c45c()...
>
>
>
>
>
>
>
>
>
>
> On Fri, Feb 4, 2011 at 3:01 AM, Tivy, Robert <rtivy at ti.com> wrote:
>
>>  More details about the failure to open the codec engine are needed.  You
>> can generate more info by setting the environment variable CE_DEBUG=3 and
>> re-running your app:
>>     % export CE_DEBUG=3
>>     % ./decode ...
>>
>> Regards,
>>
>> - Rob
>>
>>  ------------------------------
>> *From:* davinci-linux-open-source-bounces+rtivy=ti.com@
>> linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy<davinci-linux-open-source-bounces%2Brtivy>
>> =ti.com at linux.davincidsp.com] *On Behalf Of *Aditya Barawkar
>> *Sent:* Thursday, February 03, 2011 11:56 AM
>> *To:* davinci-linux-open-source at linux.davincidsp.com
>> *Subject:* Error While Running Demos
>>
>> I'm trying to run demos for encode decode which came with DVSDK v1.30.01
>> for DM6446 EVM
>>
>> When i boot the board then I'm not seeing any demos which should run
>> automatically as per the TI doc.
>>
>> So i opted to run the demos using command line.
>>
>> First i loaded all the modules which are required to run the demos
>> Modules loaded :: cmemk.ko and dsplinkk.ko
>>
>> root at 10.42.43.10:/opt/demos/dm6446/decode/release# lsmod
>> Module                  Size  Used by
>> cmemk                  17368  0
>> dsplinkk               96360  0
>>
>> But when i excute command to run the demo ::: ./decode -v
>> /opt/demos/dm6446/data/videos/davincieffect_ntsc.m2v -k
>> i get following error::
>>
>>
>> Decode demo started.
>> TraceUtil> Error: Failed to open codec engine "decode"
>> TraceUtil> Error: Aborting TraceUtil_start
>> Decode Error: Failed to open codec engine decode
>> Decode Error: Failed to open codec engine decode
>> root at 10.42.43.10:/opt/demos/dm6446/decode/release#
>>
>> Please help me out on how to make the sample demos run.
>>
>> Thanks in advance.!
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/4c586382/attachment-0001.html>

From adityabarawkar at gmail.com  Thu Feb  3 23:50:27 2011
From: adityabarawkar at gmail.com (Aditya Barawkar)
Date: Fri, 4 Feb 2011 11:20:27 +0530
Subject: Error While Running Demos
In-Reply-To: <AANLkTinQKoBe0CHVVdXOQA-_RC02ePkV9mG80pEaoA4K@mail.gmail.com>
References: <AANLkTimhZy=SLnZvQm=zTqQe9XKQi3Ofkkof2xwFr0xW@mail.gmail.com>
	<6B8224E84039B140AA662F0BB03616430188FA63B9@dlee04.ent.ti.com>
	<AANLkTin0qPs+wuomtd3dpyptueQiWdmm7=pQS-LeAD5W@mail.gmail.com>
	<AANLkTinQKoBe0CHVVdXOQA-_RC02ePkV9mG80pEaoA4K@mail.gmail.com>
Message-ID: <AANLkTiniqjF8GNhdXpyP_-BV3dnQtfpTKa911GreB1ag@mail.gmail.com>

Ignore all the previous logs....just see the log.txt file attached..
sorry for the  inconvineince...

On Fri, Feb 4, 2011 at 10:41 AM, Aditya Barawkar
<adityabarawkar at gmail.com>wrote:

> Sorry log in last mail was without inserting two modules cmemk.ko &
> dsplinkk.ko
>
> This log was generated after inserting above two modules.
>
> Thanks.
>
>
> Decode demo started.
> @0,448,089us: [+4 T:0x40018528 S:0xbefff8cc] OG - Global_init> This program
> was built with the following packages:
> @0,448,733us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> gnu.targets.rts470MV
> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/gnu/targets/rts470MV/)
> [1,0,0,0,1193542866293]
> @0,448,978us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.g711dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/)
> [1,0,0,1210922571648]
> @0,449,140us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.aachedec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/)
> [1,0,0,1210922563756]
> @0,449,289us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mp3dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/)
> [1,0,0,1210922592446]
> @0,449,433us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.h264dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/)
> [1,0,0,1210922581723]
> @0,449,624us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mpeg2dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/)
> [1,0,0,1210922600503]
> @0,449,773us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mpeg4dec
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/)
> [1,0,0,1210922605176]
> @0,449,914us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais.dm(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/dm/)
> [1,0,4,0]
> @0,450,046us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/)
> [1,2,1,0]
> @0,450,184us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.utils.trace
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/utils/trace/)
> [1,0,0,0]
> @0,450,325us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.utils.xdm
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/xdm/)
> [1,0,1,1200333457442]
> @0,450,464us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package dsplink.gpp
> (/db/atree/library/trees/linuxdemos-a46x/imports/dsplink-dm644x-v140-05p1-prebuilt/packages/dsplink/gpp/)
> [1,1,0,0]
> @0,450,607us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.linuxutils.cmem
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/)
> [2,0,0,0]
> @0,450,750us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.fc.acpy3
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/acpy3/)
> [1,0,2,0]
> @0,450,893us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.fc.dman3
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/dman3/)
> [1,0,3,0]
> @0,451,035us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.osal
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/osal/)
> [2,0,1,1200333329943]
> @0,451,178us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.alg
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/alg/)
> [1,0,0,1200332939285]
> @0,451,317us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.catalog.c470
> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/catalog/c470/)
> [1,0,1,0,1192229332845]
> @0,451,458us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.platforms.evmDM6446
> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/platforms/evmDM6446/)
> [1,0,0,1,1192229600615]
> @0,451,599us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/)
> [1,0,5,1200332924185]
> @0,452,339us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.speech
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/speech/)
> [1,0,1,1200333353059]
> @0,452,548us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.g711dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/ce/)
> [1,0,0,1210922072831]
> @0,452,703us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.audio
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/audio/)
> [1,0,1,1200332949776]
> @0,452,849us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.aachedec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/ce/)
> [1,0,0,1210922061774]
> @0,452,999us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mp3dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/ce/)
> [1,0,0,1210922155277]
> @0,453,146us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.video
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/video/)
> [1,0,2,1200333474655]
> @0,453,291us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.h264dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/ce/)
> [1,0,0,1210922114696]
> @0,453,437us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mpeg2dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/ce/)
> [1,0,0,1210922171166]
> @0,453,584us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.codecs.mpeg4dec.ce
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/ce/)
> [1,0,0,1210922199273]
> @0,453,731us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.bioslog
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/bioslog/)
> [1,0,1,1200332966901]
> @0,453,873us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
> ti.sdo.ce.utils.trace
> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/trace/)
> [1,0,1,1200333448031]
> @0,454,016us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package decode_config
> (/db/atree/library/trees/linuxdemos-a46x/imports/build/demos/dm6446/decode/decode_config/)
> []
> @0,454,198us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x1d148)
> @0,454,354us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c41534f]
> @0,454,700us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x0]
> @0,456,366us: [+7 T:0x40018528 S:0xbefff8d4] OM - Memory_init> ERROR:
> Failed to initialize CMEM
> @0,456,616us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
> (fxn=0x1b258)
> @0,456,905us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
> (fxn=0x1d618)
> @0,457,251us: [+0 T:0x40018528 S:0xbefff8cc] OG - Global_atexit> enter
> (fxn=0x1c0e8)
> @0,457,710us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Enter
> (fxn=0x1e9fc, attrs=0x0)
> @0,458,813us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Exit
> (task=0x48180)
> @0,459,038us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x1e59c)
> @0,459,390us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x1a028)
> @0,459,636us: [+2 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.alg - ALG_init>
> Enter
> @0,459,796us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415351 count: 1
> @0,459,964us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,460,153us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x8001]
> @0,461,093us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x10002 refCount: 1
> @0,461,328us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x8001]
> @0,461,513us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,461,665us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x482d8]
> @0,461,817us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415352 count: 1
> @0,461,993us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,462,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x18001]
> @0,462,507us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x20003 refCount: 1
> @0,462,689us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x18001]
> @0,462,859us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,463,008us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x482e8]
> @0,463,164us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415353 count: 1
> @0,463,334us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,463,519us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x28001]
> @0,463,767us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x30004 refCount: 1
> @0,463,943us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x28001]
> @0,464,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,464,254us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x482f8]
> @0,464,405us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415354 count: 1
> @0,464,577us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,464,764us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x38001]
> @0,465,017us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x40005 refCount: 1
> @0,465,199us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x38001]
> @0,465,372us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,465,523us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48308]
> @0,465,671us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415355 count: 1
> @0,465,837us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,466,012us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x48001]
> @0,466,296us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x50006 refCount: 1
> @0,466,475us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x48001]
> @0,466,645us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,466,786us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48318]
> @0,466,932us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415356 count: 1
> @0,467,096us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @0,467,284us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x58001]
> @0,467,656us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x60007 refCount: 1
> @0,467,857us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x58001]
> @0,468,034us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @0,468,182us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48328]
> @0,468,334us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415357 count: 1
> @0,468,507us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,159,411us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x68001]
> @1,159,729us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x70008 refCount: 1
> @1,159,915us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x68001]
> @1,160,092us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,160,248us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48338]
> @1,160,403us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415358 count: 1
> @1,160,620us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,160,823us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x78001]
> @1,161,084us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x80009 refCount: 1
> @1,161,272us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x78001]
> @1,161,447us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,161,598us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48348]
> @1,161,749us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415359 count: 1
> @1,161,919us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,162,157us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x88001]
> @1,162,414us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x9000a refCount: 1
> @1,162,597us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x88001]
> @1,162,770us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,162,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48358]
> @1,163,067us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535a count: 1
> @1,163,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,163,459us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x98001]
> @1,163,727us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xa000b refCount: 1
> @1,163,907us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x98001]
> @1,164,077us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,164,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48368]
> @1,164,383us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535b count: 1
> @1,164,548us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,164,736us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xa8001]
> @1,165,047us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xb000c refCount: 1
> @1,165,237us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xa8001]
> @1,165,411us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,165,557us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48378]
> @1,165,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535c count: 1
> @1,165,875us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,166,063us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xb8001]
> @1,166,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xc000d refCount: 1
> @1,166,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xb8001]
> @1,166,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,166,852us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48388]
> @1,167,043us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535d count: 1
> @1,167,682us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,167,938us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xc8001]
> @1,168,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xd000e refCount: 1
> @1,168,418us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xc8001]
> @1,168,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,168,745us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48398]
> @1,168,893us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535e count: 1
> @1,169,102us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,169,308us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xd8001]
> @1,169,575us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xe000f refCount: 1
> @1,169,752us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xd8001]
> @1,169,923us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,170,069us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483a8]
> @1,170,222us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c41535f count: 1
> @1,170,392us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,170,624us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xe8001]
> @1,170,896us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0xf0010 refCount: 1
> @1,171,076us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xe8001]
> @1,171,253us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,171,404us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483b8]
> @1,171,553us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415360 count: 1
> @1,171,720us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,171,908us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0xf8001]
> @1,172,212us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x100011 refCount: 1
> @1,172,397us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0xf8001]
> @1,172,572us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,172,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483c8]
> @1,172,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415361 count: 1
> @1,173,034us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,173,224us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x108001]
> @1,173,525us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x110012 refCount: 1
> @1,173,712us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x108001]
> @1,173,889us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,174,040us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483d8]
> @1,174,195us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415362 count: 1
> @1,174,366us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,174,554us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x118001]
> @1,174,848us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x120013 refCount: 1
> @1,175,035us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x118001]
> @1,175,211us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,175,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483e8]
> @1,175,795us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415363 count: 1
> @1,865,769us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,866,065us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x128001]
> @1,866,417us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x130014 refCount: 1
> @1,866,616us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x128001]
> @1,866,798us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,866,947us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x483f8]
> @1,867,097us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> key: 0x4c415364 count: 1
> @1,867,264us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @1,867,640us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread created.
> @1,868,071us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x138001]
> @1,868,391us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_create> semId: 0x140015 refCount: 1
> @1,868,581us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x138001]
> @1,868,757us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @1,868,958us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_create> sem[0x48408]
> @1,869,120us: [+0 T:0x40018528 S:0xbefff8b4] OG - Global_atexit> enter
> (fxn=0x19810)
> @1,869,284us: [+2 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.alg - ALG_init>
> Exit
> @1,869,436us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x19330)
> @1,869,632us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x1c238)
> @1,869,905us: [+6 T:0x40018528 S:0xbefff8d4] CE - Engine_init> CE debugging
> on (CE_DEBUG=3; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
> @1,870,088us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
> (fxn=0x16d58)
> @1,870,444us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x15c00)
> @1,870,805us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
> (fxn=0x12d38)
> @1,871,014us: [+0 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x0]
> @1,871,205us: [+0 T:0x40018528 S:0xbefff8f4] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not active
> (unset CE_DEBUG if you need TraceUtil)
> @1,880,635us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
> @1,880,944us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
> @1,881,119us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> returning physAddr=0x0
> @1,881,512us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x412cb000) = 0x0.
> @1,881,892us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> return (0x0)
> @1,889,122us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
> @1,889,346us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
> @1,889,514us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> returning physAddr=0x0
> @1,889,826us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41373c00) = 0x0.
> @1,890,130us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> return (0x0)
> @1,897,283us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
> @1,897,567us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
> @1,897,756us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory__getPhysicalAddress> returning physAddr=0x0
> @1,898,071us: [+1 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x4141c800) = 0x0.
> @1,898,385us: [+0 T:0x412cab60 S:0x412ca27c] OM -
> Memory_getBufferPhysicalAddress> return (0x0)
> @1,905,591us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open>
> Enter('decode', 0x0, 0xbefff634)
> @1,905,923us: [+0 T:0x40018528 S:0xbefff5ec] CE -
> rserverOpen('./decodeCombo.x64P'), count = 0
> @1,906,118us: [+0 T:0x40018528 S:0xbefff56c] OP - Process_create>
> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0xbefff638)
> @1,907,328us: [+7 T:0x40018528 S:0xbefff56c] OP - Process_create> ERROR:
> cannot access file ./decodeCombo.x64P
> @1,907,698us: [+6 T:0x40018528 S:0xbefff5ec] CE - rserverOpen: can't start
> './decodeCombo.x64P'; Process_create failed
> @1,907,884us: [+0 T:0x40018528 S:0xbefff5ec] CE -
> rserverOpen('./decodeCombo.x64P'): 0x0 done.
> @1,908,051us: [+0 T:0x40018528 S:0xbefff5cc] CE - Engine_close(0x485d8)
> @1,908,313us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> return(0)
> @2,071,878us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open>
> Enter('decode', 0x0, 0x41cc5494)
> @2,072,296us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
> rserverOpen('./decodeCombo.x64P'), count = 0
> @2,072,500us: [+0 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create>
> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0x41cc5498)
> @2,072,781us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR:
> cannot access file ./decodeCombo.x64P
> @2,072,973us: [+6 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen: can't start
> './decodeCombo.x64P'; Process_create failed
> @2,073,151us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
> rserverOpen('./decodeCombo.x64P'): 0x0 done.
> @2,073,327us: [+0 T:0x41cc5b60 S:0x41cc542c] CE - Engine_close(0x485d8)
> @2,073,514us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> return(0)
> @2,607,774us: [+0 T:0x40018528 S:0xbefff8dc] OG - Global_exit> enter
> @2,607,990us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x12d38()...
> @2,608,198us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x15c00()...
> @2,608,412us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x16d58()...
> @2,608,592us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1c238()...
> @2,608,747us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x19330()...
> @2,608,901us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x482d8]
> @2,609,055us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,609,251us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x148000]
> @2,609,437us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x10002, ref count: 1
> @2,609,672us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x10002
> @2,609,889us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x148000]
> @2,610,071us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,610,229us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,610,375us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x482e8]
> @2,610,527us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,610,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x150000]
> @2,610,886us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x20003, ref count: 1
> @2,611,111us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x20003
> @2,611,321us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x150000]
> @2,611,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,611,651us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,611,792us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x482f8]
> @2,611,942us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,612,121us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x158000]
> @2,612,294us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x30004, ref count: 1
> @2,612,513us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x30004
> @2,613,356us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x158000]
> @2,613,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,613,766us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,613,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48308]
> @2,614,109us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,614,312us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x160000]
> @2,614,491us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x40005, ref count: 1
> @2,614,716us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x40005
> @2,614,886us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x160000]
> @2,615,055us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,615,207us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,615,351us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48318]
> @2,615,542us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,615,733us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x168000]
> @2,615,908us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x50006, ref count: 1
> @2,616,130us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x50006
> @2,616,300us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x168000]
> @2,616,471us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,616,624us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,616,771us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48328]
> @2,616,961us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,617,148us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x170000]
> @2,617,330us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x60007, ref count: 1
> @2,617,685us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x60007
> @2,617,883us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x170000]
> @2,618,052us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,618,206us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,618,407us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48338]
> @2,618,563us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,618,746us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x178000]
> @2,618,918us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x70008, ref count: 1
> @2,619,131us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x70008
> @2,619,298us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x178000]
> @2,619,469us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,619,623us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,619,800us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48348]
> @2,619,959us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,620,140us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x180000]
> @2,620,319us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x80009, ref count: 1
> @2,620,537us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x80009
> @2,620,704us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x180000]
> @2,621,138us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,621,389us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,621,548us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48358]
> @2,621,707us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,621,896us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x188000]
> @2,622,073us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x9000a, ref count: 1
> @2,622,304us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x9000a
> @2,622,480us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x188000]
> @2,622,689us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,622,850us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,622,996us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48368]
> @2,623,147us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,623,329us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x190000]
> @2,623,508us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xa000b, ref count: 1
> @2,623,725us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xa000b
> @2,623,892us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x190000]
> @2,624,102us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,624,262us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,624,406us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48378]
> @2,624,559us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,624,737us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x198000]
> @2,624,915us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xb000c, ref count: 1
> @2,625,135us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xb000c
> @2,625,306us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x198000]
> @2,625,515us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,625,676us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,625,820us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48388]
> @2,625,969us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,626,146us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1a0000]
> @2,626,322us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xc000d, ref count: 1
> @2,626,538us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xc000d
> @2,626,705us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1a0000]
> @2,626,907us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,627,066us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,627,217us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48398]
> @2,627,368us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @2,627,676us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1a8000]
> @2,627,878us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xd000e, ref count: 1
> @2,628,102us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xd000e
> @2,628,305us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1a8000]
> @2,628,494us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @2,628,649us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @2,628,974us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483a8]
> @3,318,647us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,318,886us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1b0000]
> @3,319,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xe000f, ref count: 1
> @3,319,345us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xe000f
> @3,319,557us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1b0000]
> @3,319,736us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,319,887us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,320,029us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483b8]
> @3,320,181us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,320,362us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1b8000]
> @3,320,535us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0xf0010, ref count: 1
> @3,320,750us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0xf0010
> @3,320,960us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1b8000]
> @3,321,140us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,321,291us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,321,439us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483c8]
> @3,321,592us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,321,767us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1c0000]
> @3,321,942us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x100011, ref count: 1
> @3,322,156us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x100011
> @3,322,359us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1c0000]
> @3,322,540us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,322,696us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,322,841us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483d8]
> @3,322,988us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,323,166us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1c8000]
> @3,323,340us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x110012, ref count: 1
> @3,323,552us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x110012
> @3,323,718us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1c8000]
> @3,323,930us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,324,083us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,324,234us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483e8]
> @3,324,384us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,324,561us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1d0000]
> @3,324,740us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x120013, ref count: 1
> @3,324,958us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x120013
> @3,325,128us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1d0000]
> @3,325,344us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,325,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,325,646us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x483f8]
> @3,325,794us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,326,227us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1d8000]
> @3,326,463us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x130014, ref count: 1
> @3,326,745us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x130014
> @3,326,928us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1d8000]
> @3,327,103us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,327,263us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,327,408us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
> Sem_delete> sem[0x48408]
> @3,327,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
> Sem_enterCS> key[0x4c415350]
> @3,327,910us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
> Sem_enterCS> id[0x1e0000]
> @3,328,137us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> sem: 0x140015, ref count: 1
> @3,328,371us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
> Sem_delete> Deleted semaphore: 0x140015
> @3,328,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
> Sem_exitCS> id[0x1e0000]
> @3,328,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_exitCS
> @3,328,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
> Sem_delete>
> @3,329,017us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x19810()...
> @3,329,177us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1a028()...
> @3,329,327us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1e59c()...
> @3,329,743us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread
> terminating
> @3,330,253us: [+0 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> Enter
> (task=0x48180)
> @3,330,566us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
> pthread_cancel (0x3)
> @3,330,761us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
> pthread_join (0x0)
> @3,330,979us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_delete> Exit
> (task=0x48180)
> @3,331,149us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1c0e8()...
> @3,331,371us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1d618()...
> @3,331,549us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1b258()...
> @3,331,708us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1d148()...
> @3,331,862us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
> function *0x1c45c()...
>
>
>
> On Fri, Feb 4, 2011 at 10:34 AM, Aditya Barawkar <adityabarawkar at gmail.com
> > wrote:
>
>>
>> Thanks for looking into problem.
>>
>> here is the log with CE_DEBUG=3
>>
>>
>>
>>
>>
>> Decode demo started.
>> @0,448,089us: [+4 T:0x40018528 S:0xbefff8cc] OG - Global_init> This
>> program was built with the following packages:
>> @0,448,733us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> gnu.targets.rts470MV
>> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/gnu/targets/rts470MV/)
>> [1,0,0,0,1193542866293]
>> @0,448,978us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.g711dec
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/)
>> [1,0,0,1210922571648]
>> @0,449,140us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.aachedec
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/)
>> [1,0,0,1210922563756]
>> @0,449,289us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.mp3dec
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/)
>> [1,0,0,1210922592446]
>> @0,449,433us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.h264dec
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/)
>> [1,0,0,1210922581723]
>> @0,449,624us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.mpeg2dec
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/)
>> [1,0,0,1210922600503]
>> @0,449,773us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.mpeg4dec
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/)
>> [1,0,0,1210922605176]
>> @0,449,914us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais.dm(/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/dm/)
>> [1,0,4,0]
>> @0,450,046us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/)
>> [1,2,1,0]
>> @0,450,184us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.utils.trace
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/utils/trace/)
>> [1,0,0,0]
>> @0,450,325us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.ce.utils.xdm
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/xdm/)
>> [1,0,1,1200333457442]
>> @0,450,464us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package dsplink.gpp
>> (/db/atree/library/trees/linuxdemos-a46x/imports/dsplink-dm644x-v140-05p1-prebuilt/packages/dsplink/gpp/)
>> [1,1,0,0]
>> @0,450,607us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.linuxutils.cmem
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/)
>> [2,0,0,0]
>> @0,450,750us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.fc.acpy3
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/acpy3/)
>> [1,0,2,0]
>> @0,450,893us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.fc.dman3
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/dman3/)
>> [1,0,3,0]
>> @0,451,035us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.ce.osal
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/osal/)
>> [2,0,1,1200333329943]
>> @0,451,178us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.ce.alg
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/alg/)
>> [1,0,0,1200332939285]
>> @0,451,317us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.catalog.c470
>> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/catalog/c470/)
>> [1,0,1,0,1192229332845]
>> @0,451,458us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.platforms.evmDM6446
>> (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/platforms/evmDM6446/)
>> [1,0,0,1,1192229600615]
>> @0,451,599us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/)
>> [1,0,5,1200332924185]
>> @0,452,339us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.ce.speech
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/speech/)
>> [1,0,1,1200333353059]
>> @0,452,548us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.g711dec.ce
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/ce/)
>> [1,0,0,1210922072831]
>> @0,452,703us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.ce.audio
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/audio/)
>> [1,0,1,1200332949776]
>> @0,452,849us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.aachedec.ce
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/ce/)
>> [1,0,0,1210922061774]
>> @0,452,999us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.mp3dec.ce
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/ce/)
>> [1,0,0,1210922155277]
>> @0,453,146us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.ce.video
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/video/)
>> [1,0,2,1200333474655]
>> @0,453,291us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.h264dec.ce
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/ce/)
>> [1,0,0,1210922114696]
>> @0,453,437us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.mpeg2dec.ce
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/ce/)
>> [1,0,0,1210922171166]
>> @0,453,584us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.codecs.mpeg4dec.ce
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/ce/)
>> [1,0,0,1210922199273]
>> @0,453,731us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.ce.bioslog
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/bioslog/)
>> [1,0,1,1200332966901]
>> @0,453,873us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> ti.sdo.ce.utils.trace
>> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/trace/)
>> [1,0,1,1200333448031]
>> @0,454,016us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package
>> decode_config
>> (/db/atree/library/trees/linuxdemos-a46x/imports/build/demos/dm6446/decode/decode_config/)
>> []
>> @0,454,198us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
>> (fxn=0x1d148)
>> @0,454,354us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c41534f]
>> @0,454,700us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x0]
>> @0,456,366us: [+7 T:0x40018528 S:0xbefff8d4] OM - Memory_init> ERROR:
>> Failed to initialize CMEM
>> @0,456,616us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
>> (fxn=0x1b258)
>> @0,456,905us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
>> (fxn=0x1d618)
>> @0,457,251us: [+0 T:0x40018528 S:0xbefff8cc] OG - Global_atexit> enter
>> (fxn=0x1c0e8)
>> @0,457,710us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Enter
>> (fxn=0x1e9fc, attrs=0x0)
>> @0,458,813us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Exit
>> (task=0x48180)
>> @0,459,038us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
>> (fxn=0x1e59c)
>> @0,459,390us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
>> (fxn=0x1a028)
>> @0,459,636us: [+2 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.alg -
>> ALG_init> Enter
>> @0,459,796us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415351 count: 1
>> @0,459,964us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @0,460,153us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x8001]
>> @0,461,093us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x10002 refCount: 1
>> @0,461,328us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x8001]
>> @0,461,513us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @0,461,665us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x482d8]
>> @0,461,817us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415352 count: 1
>> @0,461,993us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @0,462,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x18001]
>> @0,462,507us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x20003 refCount: 1
>> @0,462,689us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x18001]
>> @0,462,859us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @0,463,008us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x482e8]
>> @0,463,164us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415353 count: 1
>> @0,463,334us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @0,463,519us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x28001]
>> @0,463,767us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x30004 refCount: 1
>> @0,463,943us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x28001]
>> @0,464,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @0,464,254us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x482f8]
>> @0,464,405us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415354 count: 1
>> @0,464,577us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @0,464,764us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x38001]
>> @0,465,017us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x40005 refCount: 1
>> @0,465,199us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x38001]
>> @0,465,372us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @0,465,523us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48308]
>> @0,465,671us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415355 count: 1
>> @0,465,837us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @0,466,012us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x48001]
>> @0,466,296us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x50006 refCount: 1
>> @0,466,475us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x48001]
>> @0,466,645us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @0,466,786us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48318]
>> @0,466,932us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415356 count: 1
>> @0,467,096us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @0,467,284us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x58001]
>> @0,467,656us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x60007 refCount: 1
>> @0,467,857us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x58001]
>> @0,468,034us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @0,468,182us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48328]
>> @0,468,334us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415357 count: 1
>> @0,468,507us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,159,411us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x68001]
>> @1,159,729us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x70008 refCount: 1
>> @1,159,915us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x68001]
>> @1,160,092us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,160,248us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48338]
>> @1,160,403us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415358 count: 1
>> @1,160,620us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,160,823us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x78001]
>> @1,161,084us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x80009 refCount: 1
>> @1,161,272us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x78001]
>> @1,161,447us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,161,598us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48348]
>> @1,161,749us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415359 count: 1
>> @1,161,919us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,162,157us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x88001]
>> @1,162,414us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x9000a refCount: 1
>> @1,162,597us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x88001]
>> @1,162,770us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,162,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48358]
>> @1,163,067us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c41535a count: 1
>> @1,163,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,163,459us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x98001]
>> @1,163,727us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0xa000b refCount: 1
>> @1,163,907us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x98001]
>> @1,164,077us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,164,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48368]
>> @1,164,383us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c41535b count: 1
>> @1,164,548us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,164,736us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0xa8001]
>> @1,165,047us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0xb000c refCount: 1
>> @1,165,237us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0xa8001]
>> @1,165,411us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,165,557us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48378]
>> @1,165,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c41535c count: 1
>> @1,165,875us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,166,063us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0xb8001]
>> @1,166,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0xc000d refCount: 1
>> @1,166,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0xb8001]
>> @1,166,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,166,852us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48388]
>> @1,167,043us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c41535d count: 1
>> @1,167,682us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,167,938us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0xc8001]
>> @1,168,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0xd000e refCount: 1
>> @1,168,418us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0xc8001]
>> @1,168,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,168,745us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48398]
>> @1,168,893us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c41535e count: 1
>> @1,169,102us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,169,308us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0xd8001]
>> @1,169,575us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0xe000f refCount: 1
>> @1,169,752us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0xd8001]
>> @1,169,923us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,170,069us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x483a8]
>> @1,170,222us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c41535f count: 1
>> @1,170,392us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,170,624us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0xe8001]
>> @1,170,896us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0xf0010 refCount: 1
>> @1,171,076us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0xe8001]
>> @1,171,253us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,171,404us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x483b8]
>> @1,171,553us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415360 count: 1
>> @1,171,720us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,171,908us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0xf8001]
>> @1,172,212us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x100011 refCount: 1
>> @1,172,397us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0xf8001]
>> @1,172,572us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,172,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x483c8]
>> @1,172,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415361 count: 1
>> @1,173,034us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,173,224us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x108001]
>> @1,173,525us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x110012 refCount: 1
>> @1,173,712us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x108001]
>> @1,173,889us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,174,040us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x483d8]
>> @1,174,195us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415362 count: 1
>> @1,174,366us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,174,554us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x118001]
>> @1,174,848us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x120013 refCount: 1
>> @1,175,035us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x118001]
>> @1,175,211us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,175,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x483e8]
>> @1,175,795us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415363 count: 1
>> @1,865,769us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,866,065us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x128001]
>> @1,866,417us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x130014 refCount: 1
>> @1,866,616us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x128001]
>> @1,866,798us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,866,947us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x483f8]
>> @1,867,097us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> key: 0x4c415364 count: 1
>> @1,867,264us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @1,867,640us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread created.
>> @1,868,071us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x138001]
>> @1,868,391us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_create> semId: 0x140015 refCount: 1
>> @1,868,581us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x138001]
>> @1,868,757us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @1,868,958us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_create> sem[0x48408]
>> @1,869,120us: [+0 T:0x40018528 S:0xbefff8b4] OG - Global_atexit> enter
>> (fxn=0x19810)
>> @1,869,284us: [+2 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.alg -
>> ALG_init> Exit
>> @1,869,436us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
>> (fxn=0x19330)
>> @1,869,632us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
>> (fxn=0x1c238)
>> @1,869,905us: [+6 T:0x40018528 S:0xbefff8d4] CE - Engine_init> CE
>> debugging on (CE_DEBUG=3; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
>> @1,870,088us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter
>> (fxn=0x16d58)
>> @1,870,444us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
>> (fxn=0x15c00)
>> @1,870,805us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter
>> (fxn=0x12d38)
>> @1,871,014us: [+0 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x0]
>> @1,871,205us: [+0 T:0x40018528 S:0xbefff8f4] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not
>> active (unset CE_DEBUG if you need TraceUtil)
>> @1,880,635us: [+0 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
>> @1,880,944us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory__getPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
>> @1,881,119us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory__getPhysicalAddress> returning physAddr=0x0
>> @1,881,512us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x412cb000) = 0x0.
>> @1,881,892us: [+0 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> return (0x0)
>> @1,889,122us: [+0 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
>> @1,889,346us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory__getPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
>> @1,889,514us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory__getPhysicalAddress> returning physAddr=0x0
>> @1,889,826us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41373c00) = 0x0.
>> @1,890,130us: [+0 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> return (0x0)
>> @1,897,283us: [+0 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
>> @1,897,567us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory__getPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
>> @1,897,756us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory__getPhysicalAddress> returning physAddr=0x0
>> @1,898,071us: [+1 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> CMEM_getPhys(0x4141c800) = 0x0.
>> @1,898,385us: [+0 T:0x412cab60 S:0x412ca27c] OM -
>> Memory_getBufferPhysicalAddress> return (0x0)
>> @1,905,591us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open>
>> Enter('decode', 0x0, 0xbefff634)
>> @1,905,923us: [+0 T:0x40018528 S:0xbefff5ec] CE -
>> rserverOpen('./decodeCombo.x64P'), count = 0
>> @1,906,118us: [+0 T:0x40018528 S:0xbefff56c] OP - Process_create>
>> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0xbefff638)
>> @1,907,328us: [+7 T:0x40018528 S:0xbefff56c] OP - Process_create> ERROR:
>> cannot access file ./decodeCombo.x64P
>> @1,907,698us: [+6 T:0x40018528 S:0xbefff5ec] CE - rserverOpen: can't start
>> './decodeCombo.x64P'; Process_create failed
>> @1,907,884us: [+0 T:0x40018528 S:0xbefff5ec] CE -
>> rserverOpen('./decodeCombo.x64P'): 0x0 done.
>> @1,908,051us: [+0 T:0x40018528 S:0xbefff5cc] CE - Engine_close(0x485d8)
>> @1,908,313us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> return(0)
>> @2,071,878us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open>
>> Enter('decode', 0x0, 0x41cc5494)
>> @2,072,296us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
>> rserverOpen('./decodeCombo.x64P'), count = 0
>> @2,072,500us: [+0 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create>
>> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0x41cc5498)
>> @2,072,781us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR:
>> cannot access file ./decodeCombo.x64P
>> @2,072,973us: [+6 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen: can't start
>> './decodeCombo.x64P'; Process_create failed
>> @2,073,151us: [+0 T:0x41cc5b60 S:0x41cc544c] CE -
>> rserverOpen('./decodeCombo.x64P'): 0x0 done.
>> @2,073,327us: [+0 T:0x41cc5b60 S:0x41cc542c] CE - Engine_close(0x485d8)
>> @2,073,514us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> return(0)
>> @2,607,774us: [+0 T:0x40018528 S:0xbefff8dc] OG - Global_exit> enter
>> @2,607,990us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x12d38()...
>> @2,608,198us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x15c00()...
>> @2,608,412us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x16d58()...
>> @2,608,592us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x1c238()...
>> @2,608,747us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x19330()...
>> @2,608,901us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x482d8]
>> @2,609,055us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,609,251us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x148000]
>> @2,609,437us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x10002, ref count: 1
>> @2,609,672us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x10002
>> @2,609,889us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x148000]
>> @2,610,071us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,610,229us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,610,375us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x482e8]
>> @2,610,527us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,610,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x150000]
>> @2,610,886us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x20003, ref count: 1
>> @2,611,111us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x20003
>> @2,611,321us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x150000]
>> @2,611,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,611,651us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,611,792us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x482f8]
>> @2,611,942us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,612,121us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x158000]
>> @2,612,294us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x30004, ref count: 1
>> @2,612,513us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x30004
>> @2,613,356us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x158000]
>> @2,613,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,613,766us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,613,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48308]
>> @2,614,109us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,614,312us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x160000]
>> @2,614,491us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x40005, ref count: 1
>> @2,614,716us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x40005
>> @2,614,886us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x160000]
>> @2,615,055us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,615,207us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,615,351us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48318]
>> @2,615,542us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,615,733us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x168000]
>> @2,615,908us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x50006, ref count: 1
>> @2,616,130us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x50006
>> @2,616,300us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x168000]
>> @2,616,471us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,616,624us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,616,771us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48328]
>> @2,616,961us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,617,148us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x170000]
>> @2,617,330us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x60007, ref count: 1
>> @2,617,685us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x60007
>> @2,617,883us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x170000]
>> @2,618,052us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,618,206us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,618,407us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48338]
>> @2,618,563us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,618,746us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x178000]
>> @2,618,918us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x70008, ref count: 1
>> @2,619,131us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x70008
>> @2,619,298us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x178000]
>> @2,619,469us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,619,623us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,619,800us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48348]
>> @2,619,959us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,620,140us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x180000]
>> @2,620,319us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x80009, ref count: 1
>> @2,620,537us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x80009
>> @2,620,704us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x180000]
>> @2,621,138us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,621,389us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,621,548us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48358]
>> @2,621,707us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,621,896us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x188000]
>> @2,622,073us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x9000a, ref count: 1
>> @2,622,304us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x9000a
>> @2,622,480us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x188000]
>> @2,622,689us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,622,850us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,622,996us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48368]
>> @2,623,147us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,623,329us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x190000]
>> @2,623,508us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0xa000b, ref count: 1
>> @2,623,725us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0xa000b
>> @2,623,892us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x190000]
>> @2,624,102us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,624,262us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,624,406us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48378]
>> @2,624,559us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,624,737us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x198000]
>> @2,624,915us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0xb000c, ref count: 1
>> @2,625,135us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0xb000c
>> @2,625,306us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x198000]
>> @2,625,515us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,625,676us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,625,820us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48388]
>> @2,625,969us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,626,146us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1a0000]
>> @2,626,322us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0xc000d, ref count: 1
>> @2,626,538us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0xc000d
>> @2,626,705us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1a0000]
>> @2,626,907us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,627,066us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,627,217us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48398]
>> @2,627,368us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @2,627,676us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1a8000]
>> @2,627,878us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0xd000e, ref count: 1
>> @2,628,102us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0xd000e
>> @2,628,305us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1a8000]
>> @2,628,494us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @2,628,649us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @2,628,974us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x483a8]
>> @3,318,647us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @3,318,886us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1b0000]
>> @3,319,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0xe000f, ref count: 1
>> @3,319,345us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0xe000f
>> @3,319,557us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1b0000]
>> @3,319,736us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @3,319,887us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @3,320,029us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x483b8]
>> @3,320,181us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @3,320,362us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1b8000]
>> @3,320,535us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0xf0010, ref count: 1
>> @3,320,750us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0xf0010
>> @3,320,960us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1b8000]
>> @3,321,140us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @3,321,291us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @3,321,439us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x483c8]
>> @3,321,592us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @3,321,767us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1c0000]
>> @3,321,942us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x100011, ref count: 1
>> @3,322,156us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x100011
>> @3,322,359us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1c0000]
>> @3,322,540us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @3,322,696us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @3,322,841us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x483d8]
>> @3,322,988us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @3,323,166us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1c8000]
>> @3,323,340us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x110012, ref count: 1
>> @3,323,552us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x110012
>> @3,323,718us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1c8000]
>> @3,323,930us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @3,324,083us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @3,324,234us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x483e8]
>> @3,324,384us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @3,324,561us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1d0000]
>> @3,324,740us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x120013, ref count: 1
>> @3,324,958us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x120013
>> @3,325,128us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1d0000]
>> @3,325,344us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @3,325,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @3,325,646us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x483f8]
>> @3,325,794us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @3,326,227us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1d8000]
>> @3,326,463us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x130014, ref count: 1
>> @3,326,745us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x130014
>> @3,326,928us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1d8000]
>> @3,327,103us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @3,327,263us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @3,327,408us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered
>> Sem_delete> sem[0x48408]
>> @3,327,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered
>> Sem_enterCS> key[0x4c415350]
>> @3,327,910us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving
>> Sem_enterCS> id[0x1e0000]
>> @3,328,137us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> sem: 0x140015, ref count: 1
>> @3,328,371us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem -
>> Sem_delete> Deleted semaphore: 0x140015
>> @3,328,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered
>> Sem_exitCS> id[0x1e0000]
>> @3,328,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_exitCS
>> @3,328,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving
>> Sem_delete>
>> @3,329,017us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x19810()...
>> @3,329,177us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x1a028()...
>> @3,329,327us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x1e59c()...
>> @3,329,743us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread
>> terminating
>> @3,330,253us: [+0 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> Enter
>> (task=0x48180)
>> @3,330,566us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
>> pthread_cancel (0x3)
>> @3,330,761us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete>
>> pthread_join (0x0)
>> @3,330,979us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_delete> Exit
>> (task=0x48180)
>> @3,331,149us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x1c0e8()...
>> @3,331,371us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x1d618()...
>> @3,331,549us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x1b258()...
>> @3,331,708us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x1d148()...
>> @3,331,862us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling
>> function *0x1c45c()...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 4, 2011 at 3:01 AM, Tivy, Robert <rtivy at ti.com> wrote:
>>
>>>  More details about the failure to open the codec engine are needed.
>>> You can generate more info by setting the environment variable CE_DEBUG=3
>>> and re-running your app:
>>>     % export CE_DEBUG=3
>>>     % ./decode ...
>>>
>>> Regards,
>>>
>>> - Rob
>>>
>>>  ------------------------------
>>> *From:* davinci-linux-open-source-bounces+rtivy=ti.com@
>>> linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy<davinci-linux-open-source-bounces%2Brtivy>
>>> =ti.com at linux.davincidsp.com] *On Behalf Of *Aditya Barawkar
>>> *Sent:* Thursday, February 03, 2011 11:56 AM
>>> *To:* davinci-linux-open-source at linux.davincidsp.com
>>> *Subject:* Error While Running Demos
>>>
>>> I'm trying to run demos for encode decode which came with DVSDK v1.30.01
>>> for DM6446 EVM
>>>
>>> When i boot the board then I'm not seeing any demos which should run
>>> automatically as per the TI doc.
>>>
>>> So i opted to run the demos using command line.
>>>
>>> First i loaded all the modules which are required to run the demos
>>> Modules loaded :: cmemk.ko and dsplinkk.ko
>>>
>>> root at 10.42.43.10:/opt/demos/dm6446/decode/release# lsmod
>>> Module                  Size  Used by
>>> cmemk                  17368  0
>>> dsplinkk               96360  0
>>>
>>> But when i excute command to run the demo ::: ./decode -v
>>> /opt/demos/dm6446/data/videos/davincieffect_ntsc.m2v -k
>>> i get following error::
>>>
>>>
>>> Decode demo started.
>>> TraceUtil> Error: Failed to open codec engine "decode"
>>> TraceUtil> Error: Aborting TraceUtil_start
>>> Decode Error: Failed to open codec engine decode
>>> Decode Error: Failed to open codec engine decode
>>> root at 10.42.43.10:/opt/demos/dm6446/decode/release#
>>>
>>> Please help me out on how to make the sample demos run.
>>>
>>> Thanks in advance.!
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/aa1ef0a7/attachment-0001.html>
-------------- next part --------------
Decode demo started.
@0,405,272us: [+4 T:0x40018528 S:0xbefff8ec] OG - Global_init> This program was built with the following packages:
@0,405,886us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package gnu.targets.rts470MV (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/gnu/targets/rts470MV/) [1,0,0,0,1193542866293]
@0,406,121us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.g711dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/) [1,0,0,1210922571648]
@0,406,284us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.aachedec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/) [1,0,0,1210922563756]
@0,406,438us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.mp3dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/) [1,0,0,1210922592446]
@0,406,583us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.h264dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/) [1,0,0,1210922581723]
@0,406,730us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.mpeg2dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/) [1,0,0,1210922600503]
@0,406,876us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.mpeg4dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/) [1,0,0,1210922605176]
@0,407,017us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.xdais.dm (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/dm/) [1,0,4,0]
@0,407,159us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.xdais (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/) [1,2,1,0]
@0,407,295us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.utils.trace (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/utils/trace/) [1,0,0,0]
@0,407,439us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce.utils.xdm (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1200333457442]
@0,407,708us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package dsplink.gpp (/db/atree/library/trees/linuxdemos-a46x/imports/dsplink-dm644x-v140-05p1-prebuilt/packages/dsplink/gpp/) [1,1,0,0]
@0,407,867us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.linuxutils.cmem (/db/atree/library/trees/linuxdemos-a46x/imports/build/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/) [2,0,0,0]
@0,408,018us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.fc.acpy3 (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/acpy3/) [1,0,2,0]
@0,408,167us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.fc.dman3 (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/dman3/) [1,0,3,0]
@0,408,314us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce.osal (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/osal/) [2,0,1,1200333329943]
@0,408,455us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce.alg (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/alg/) [1,0,0,1200332939285]
@0,408,596us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.catalog.c470 (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/catalog/c470/) [1,0,1,0,1192229332845]
@0,408,738us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.platforms.evmDM6446 (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
@0,408,884us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/) [1,0,5,1200332924185]
@0,622,288us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce.speech (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/speech/) [1,0,1,1200333353059]
@0,622,496us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.g711dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/ce/) [1,0,0,1210922072831]
@0,622,660us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce.audio (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/audio/) [1,0,1,1200332949776]
@0,622,807us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.aachedec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/ce/) [1,0,0,1210922061774]
@0,622,957us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.mp3dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/ce/) [1,0,0,1210922155277]
@0,623,109us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce.video (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/video/) [1,0,2,1200333474655]
@0,623,256us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.h264dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/ce/) [1,0,0,1210922114696]
@0,623,403us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.mpeg2dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/ce/) [1,0,0,1210922171166]
@0,623,554us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.codecs.mpeg4dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/ce/) [1,0,0,1210922199273]
@0,623,701us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce.bioslog (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/bioslog/) [1,0,1,1200332966901]
@0,623,846us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package ti.sdo.ce.utils.trace (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/trace/) [1,0,1,1200333448031]
@0,623,989us: [+4 T:0x40018528 S:0xbefff8ec] OG -     package decode_config (/db/atree/library/trees/linuxdemos-a46x/imports/build/demos/dm6446/decode/decode_config/) []
@0,624,161us: [+0 T:0x40018528 S:0xbefff8f4] OG - Global_atexit> enter (fxn=0x1d148)
@0,624,320us: [+0 T:0x40018528 S:0xbefff8e4] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c41534f]
@0,624,674us: [+0 T:0x40018528 S:0xbefff8e4] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x988000]
@0,625,585us: [+0 T:0x40018528 S:0xbefff8e4] OG - Global_atexit> enter (fxn=0x1b258)
@0,625,920us: [+0 T:0x40018528 S:0xbefff8e4] OG - Global_atexit> enter (fxn=0x1d618)
@0,626,264us: [+0 T:0x40018528 S:0xbefff8ec] OG - Global_atexit> enter (fxn=0x1c0e8)
@0,626,680us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_create> Enter (fxn=0x1e9fc, attrs=0x0)
@0,627,747us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_create> Exit (task=0x48180)
@0,627,978us: [+0 T:0x40018528 S:0xbefff8f4] OG - Global_atexit> enter (fxn=0x1e59c)
@0,628,268us: [+0 T:0x40018528 S:0xbefff8f4] OG - Global_atexit> enter (fxn=0x1a028)
@0,628,509us: [+2 T:0x40018528 S:0xbefff8e4] ti.sdo.ce.osal.alg - ALG_init> Enter
@0,628,668us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415351 count: 1
@0,628,838us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,629,031us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x990001]
@0,629,416us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x998002 refCount: 1
@0,630,093us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x990001]
@0,630,334us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,630,489us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482d8]
@0,630,644us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415352 count: 1
@0,630,819us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,631,011us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x9a0001]
@0,631,273us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x9a8003 refCount: 1
@0,631,455us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x9a0001]
@0,631,625us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,631,770us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482e8]
@0,631,918us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415353 count: 1
@0,632,086us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,632,271us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x9b0001]
@0,632,515us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x9b8004 refCount: 1
@0,632,695us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x9b0001]
@0,632,869us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,633,020us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482f8]
@0,633,171us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415354 count: 1
@0,633,340us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,633,529us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x9c0001]
@0,633,790us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x9c8005 refCount: 1
@0,633,971us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x9c0001]
@0,634,149us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,634,296us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48308]
@0,634,448us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415355 count: 1
@0,634,615us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,634,798us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x9d0001]
@0,635,048us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x9d8006 refCount: 1
@0,635,226us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x9d0001]
@0,635,398us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,635,539us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48318]
@0,635,692us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415356 count: 1
@0,635,857us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,636,036us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x9e0001]
@0,636,285us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x9e8007 refCount: 1
@0,636,462us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x9e0001]
@0,636,635us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,636,778us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48328]
@0,636,925us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415357 count: 1
@0,637,089us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,637,274us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x9f0001]
@1,327,729us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x9f8008 refCount: 1
@1,327,945us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x9f0001]
@1,328,168us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,328,323us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48338]
@1,328,476us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415358 count: 1
@1,328,648us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,328,840us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa00001]
@1,329,097us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa08009 refCount: 1
@1,329,281us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa00001]
@1,329,497us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,329,651us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48348]
@1,329,806us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415359 count: 1
@1,329,973us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,330,159us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa10001]
@1,330,411us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa1800a refCount: 1
@1,330,592us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa10001]
@1,330,764us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,330,955us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48358]
@1,331,113us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535a count: 1
@1,331,283us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,331,473us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa20001]
@1,331,731us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa2800b refCount: 1
@1,331,914us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa20001]
@1,332,090us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,332,267us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48368]
@1,332,426us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535b count: 1
@1,332,594us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,332,782us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa30001]
@1,333,085us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa3800c refCount: 1
@1,333,278us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa30001]
@1,333,455us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,333,605us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48378]
@1,333,807us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535c count: 1
@1,333,982us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,334,176us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa40001]
@1,334,433us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa4800d refCount: 1
@1,334,611us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa40001]
@1,334,783us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,334,931us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48388]
@1,335,114us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535d count: 1
@1,335,297us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,335,831us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa50001]
@1,336,164us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa5800e refCount: 1
@1,336,357us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa50001]
@1,336,574us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,336,736us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48398]
@1,336,888us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535e count: 1
@1,337,058us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,337,253us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa60001]
@1,337,622us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa6800f refCount: 1
@1,337,829us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa60001]
@1,338,056us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,338,212us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483a8]
@1,338,366us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535f count: 1
@1,338,536us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,338,730us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa70001]
@1,338,998us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa78010 refCount: 1
@1,339,180us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa70001]
@1,339,384us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,339,545us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483b8]
@1,339,694us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415360 count: 1
@1,339,863us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,340,054us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa80001]
@1,340,318us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa88011 refCount: 1
@1,340,498us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa80001]
@1,340,670us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,340,862us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483c8]
@1,341,020us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415361 count: 1
@1,341,190us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,341,377us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa90001]
@1,341,641us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa98012 refCount: 1
@1,341,822us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa90001]
@1,341,993us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,342,142us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483d8]
@1,342,343us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415362 count: 1
@1,342,516us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,342,704us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xaa0001]
@1,342,968us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xaa8013 refCount: 1
@1,343,147us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xaa0001]
@1,343,319us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,343,468us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483e8]
@1,343,645us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415363 count: 1
@2,034,638us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,034,935us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xab0001]
@2,035,237us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xab8014 refCount: 1
@2,035,430us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xab0001]
@2,035,612us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,035,763us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483f8]
@2,035,920us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415364 count: 1
@2,036,092us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,036,316us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xac0001]
@2,036,596us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xac8015 refCount: 1
@2,036,776us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xac0001]
@2,036,955us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,037,102us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48408]
@2,037,251us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x19810)
@2,037,416us: [+2 T:0x40018528 S:0xbefff8fc] ti.sdo.ce.osal.alg - ALG_init> Exit
@2,037,866us: [+0 T:0x40018528 S:0xbefff8f4] OG - Global_atexit> enter (fxn=0x19330)
@2,038,096us: [+0 T:0x40018528 S:0xbefff8f4] OG - Global_atexit> enter (fxn=0x1c238)
@2,038,382us: [+6 T:0x40018528 S:0xbefff8f4] CE - Engine_init> CE debugging on (CE_DEBUG=3; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
@2,038,571us: [+0 T:0x40018528 S:0xbefff8e4] OG - Global_atexit> enter (fxn=0x16d58)
@2,038,887us: [+0 T:0x40018528 S:0xbefff8f4] OG - Global_atexit> enter (fxn=0x15c00)
@2,039,279us: [+0 T:0x40018528 S:0xbefff8f4] OG - Global_atexit> enter (fxn=0x12d38)
@2,039,499us: [+0 T:0x40018528 S:0xbefff8fc] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x988000]
@2,039,696us: [+0 T:0x40018528 S:0xbefff914] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not active (unset CE_DEBUG if you need TraceUtil)
@2,048,833us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@2,049,166us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@2,049,345us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@2,049,530us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x412cb000) = 0x80800000.
@2,049,720us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> Enter(virtAddr=0x412cb000, size=4, physAddr=0x80800000)
@2,049,896us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> creating new contigBuf object
@2,050,068us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> returning: cb->phys=0x80800000, cb->size=4, cb->virt=0x412cb000
@2,050,241us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x80800000)
@2,057,362us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@2,057,707us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@2,057,891us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@2,058,080us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41373c00) = 0x808a8c00.
@2,058,272us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> Enter(virtAddr=0x41373c00, size=4, physAddr=0x808a8c00)
@2,058,446us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> creating new contigBuf object
@2,058,614us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> returning: cb->phys=0x808a8c00, cb->size=4, cb->virt=0x41373c00
@2,067,192us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x808a8c00)
@2,074,489us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@2,074,755us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@2,074,929us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@2,075,114us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x4141c800) = 0x80951800.
@2,075,308us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> Enter(virtAddr=0x4141c800, size=4, physAddr=0x80951800)
@2,075,483us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> creating new contigBuf object
@2,075,653us: [+1 T:0x412cab60 S:0x412ca23c] OM - Memory__addContigBuf> returning: cb->phys=0x80951800, cb->size=4, cb->virt=0x4141c800
@2,075,830us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x80951800)
@2,076,402us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> Enter('decode', 0x0, 0x41cc5494)
@2,076,812us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen('./decodeCombo.x64P'), count = 0
@2,077,021us: [+0 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0x41cc5498)
@2,079,461us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR: cannot access file ./decodeCombo.x64P
@2,079,716us: [+6 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen: can't start './decodeCombo.x64P'; Process_create failed
@2,079,910us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen('./decodeCombo.x64P'): 0x0 done.
@2,080,090us: [+0 T:0x41cc5b60 S:0x41cc542c] CE - Engine_close(0x48620)
@2,080,400us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> return(0)
@2,081,409us: [+0 T:0x40018528 S:0xbefff60c] CE - Engine_open> Enter('decode', 0x0, 0xbefff654)
@2,081,705us: [+0 T:0x40018528 S:0xbefff60c] CE - rserverOpen('./decodeCombo.x64P'), count = 0
@2,081,950us: [+0 T:0x40018528 S:0xbefff58c] OP - Process_create> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0xbefff658)
@2,082,211us: [+7 T:0x40018528 S:0xbefff58c] OP - Process_create> ERROR: cannot access file ./decodeCombo.x64P
@2,082,403us: [+6 T:0x40018528 S:0xbefff60c] CE - rserverOpen: can't start './decodeCombo.x64P'; Process_create failed
@2,082,569us: [+0 T:0x40018528 S:0xbefff60c] CE - rserverOpen('./decodeCombo.x64P'): 0x0 done.
@2,082,731us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_close(0x48620)
@2,082,908us: [+0 T:0x40018528 S:0xbefff60c] CE - Engine_open> return(0)
@2,083,458us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread created.
@2,120,893us: [+0 T:0x40018528 S:0xbefff8fc] OG - Global_exit> enter
@2,121,114us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x12d38()...
@2,121,319us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x15c00()...
@2,121,491us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x16d58()...
@2,121,707us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x1c238()...
@2,121,865us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x19330()...
@2,122,019us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482d8]
@2,122,179us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,122,371us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xad0000]
@2,122,555us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x998002, ref count: 1
@2,122,782us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x998002
@2,122,954us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xad0000]
@2,123,174us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,123,330us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,123,474us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482e8]
@2,774,193us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,774,495us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xad8000]
@2,774,696us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x9a8003, ref count: 1
@2,774,927us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x9a8003
@2,775,107us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xad8000]
@2,775,285us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,775,446us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,775,587us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482f8]
@2,775,737us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,775,967us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xae0000]
@2,776,148us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x9b8004, ref count: 1
@2,776,371us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x9b8004
@2,776,541us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xae0000]
@2,776,714us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,776,865us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,777,009us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48308]
@2,777,168us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,777,398us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xae8000]
@2,777,733us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x9c8005, ref count: 1
@2,777,970us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x9c8005
@2,778,142us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xae8000]
@2,778,311us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,778,460us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,778,598us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48318]
@2,778,789us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,779,010us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xaf0000]
@2,779,190us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x9d8006, ref count: 1
@2,779,408us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x9d8006
@2,779,573us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xaf0000]
@2,779,735us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,779,885us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,780,029us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48328]
@2,780,224us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,780,408us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xaf8000]
@2,780,584us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x9e8007, ref count: 1
@2,780,800us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x9e8007
@2,780,973us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xaf8000]
@2,781,144us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,781,295us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,781,435us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48338]
@2,781,629us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,782,067us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb00000]
@2,782,303us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x9f8008, ref count: 1
@2,782,544us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x9f8008
@2,782,725us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb00000]
@2,782,938us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,783,107us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,783,258us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48348]
@2,783,409us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,783,589us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb08000]
@2,783,770us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa08009, ref count: 1
@2,783,994us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa08009
@2,784,168us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb08000]
@2,784,378us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,784,543us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,784,687us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48358]
@2,784,839us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,785,018us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb10000]
@2,785,194us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa1800a, ref count: 1
@2,785,414us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa1800a
@2,785,579us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb10000]
@2,785,782us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,785,946us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,786,094us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48368]
@2,786,245us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,786,423us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb18000]
@2,786,599us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa2800b, ref count: 1
@2,786,818us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa2800b
@2,786,989us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb18000]
@2,787,197us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,787,364us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,787,631us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48378]
@2,787,807us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,787,997us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb20000]
@2,788,177us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa3800c, ref count: 1
@2,788,398us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa3800c
@2,788,567us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb20000]
@2,788,785us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,788,938us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,789,080us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48388]
@2,789,233us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,789,413us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb28000]
@2,789,776us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa4800d, ref count: 1
@2,790,101us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa4800d
@3,479,968us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb28000]
@3,480,198us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,480,360us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,480,506us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48398]
@3,480,658us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,480,844us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb30000]
@3,481,024us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa5800e, ref count: 1
@3,481,292us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa5800e
@3,481,474us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb30000]
@3,481,650us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,481,804us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,481,943us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483a8]
@3,482,091us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,482,273us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb38000]
@3,482,445us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa6800f, ref count: 1
@3,482,693us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa6800f
@3,482,872us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb38000]
@3,483,046us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,483,201us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,483,343us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483b8]
@3,483,489us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,483,670us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb40000]
@3,483,841us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa78010, ref count: 1
@3,484,084us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa78010
@3,484,262us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb40000]
@3,484,437us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,484,590us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,484,730us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483c8]
@3,484,881us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,485,060us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb48000]
@3,485,231us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa88011, ref count: 1
@3,485,445us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa88011
@3,485,655us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb48000]
@3,485,831us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,485,987us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,486,128us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483d8]
@3,486,278us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,486,454us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb50000]
@3,486,629us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa98012, ref count: 1
@3,486,842us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa98012
@3,487,052us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb50000]
@3,487,620us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,487,841us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,488,002us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483e8]
@3,488,165us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,488,392us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb58000]
@3,488,586us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xaa8013, ref count: 1
@3,488,820us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xaa8013
@3,488,988us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb58000]
@3,489,162us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,489,317us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,489,460us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483f8]
@3,489,612us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,489,828us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb60000]
@3,490,013us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xab8014, ref count: 1
@3,490,231us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xab8014
@3,490,401us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb60000]
@3,490,570us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,490,719us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,490,858us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48408]
@3,491,007us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,491,218us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb68000]
@3,491,405us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xac8015, ref count: 1
@3,491,623us: [+1 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xac8015
@3,491,788us: [+0 T:0x40018528 S:0xbefff88c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb68000]
@3,491,957us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,492,104us: [+0 T:0x40018528 S:0xbefff8a4] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,492,252us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x19810()...
@3,492,407us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x1a028()...
@3,492,562us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x1e59c()...
@3,492,977us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread terminating
@3,493,486us: [+0 T:0x40018528 S:0xbefff8cc] OT - Thread_delete> Enter (task=0x48180)
@3,493,800us: [+4 T:0x40018528 S:0xbefff8cc] OT - Thread_delete> pthread_cancel (0x3)
@3,494,004us: [+4 T:0x40018528 S:0xbefff8cc] OT - Thread_delete> pthread_join (0x0)
@3,494,228us: [+0 T:0x40018528 S:0xbefff8e4] OT - Thread_delete> Exit (task=0x48180)
@3,494,391us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x1c0e8()...
@3,494,616us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x1d618()...
@3,494,799us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x1b258()...
@3,495,031us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x1d148()...
@3,495,206us: [+2 T:0x40018528 S:0xbefff8fc] OG - Global_exit> calling function *0x1c45c()...

From nsekhar at ti.com  Thu Feb  3 23:52:20 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 4 Feb 2011 11:22:20 +0530
Subject: [PATCH 1/1] Add support for Nand flash on Hawkboard.
In-Reply-To: <AANLkTik7U2adxVsUgn4J0u+micHdmDsc7PKyUr-FfsmG@mail.gmail.com>
References: <1296669194-11926-1-git-send-email-urwithsughosh@gmail.com>
	<AANLkTi=Lnr+DXHqfh=rJGReU4eW65R5_y7kKL3sa43fi@mail.gmail.com>
	<4D49B7CD.9090006@mvista.com>
	<AANLkTimoPGvZGEuX3pTaJPBBu+e9X_cB8q-2J1PNt365@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248778723@dbde02.ent.ti.com>
	<AANLkTi=O85kF1+s0fX6D3yjzpJr8_t8wmHBdXBbJ_OE7@mail.gmail.com>
	<AANLkTi=DjC=6BRppjiy4FTM52PWRixYPWfZEn42+Nvpm@mail.gmail.com>
	<4D4A965B.3000809@mvista.com>
	<AANLkTi=njfnxjaxg1C9=uhuo0xxzyDmPb2pRa85YLbuj@mail.gmail.com>
	<4D4A9EA8.8000500@mvista.com>
	<AANLkTi=qDR_rxMuFNVq1UO1jeghUn7CEoUALwOAZNX1x@mail.gmail.com>
	<AANLkTi=mLWz1gTRhpKUJZJ3DnKH6ZPPeOFGQSuQ_73ky@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B327@dbde02.ent.ti.com>
	<AANLkTik7U2adxVsUgn4J0u+micHdmDsc7PKyUr-FfsmG@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024880B531@dbde02.ent.ti.com>

Hi sughosh,

On Thu, Feb 03, 2011 at 23:31:48, sughosh ganu wrote:
> hi Sekhar,
> 
> 
> On Thu, Feb 3, 2011 at 10:38 PM, Nori, Sekhar <nsekhar at ti.com> wrote:
> 
> 
> 	>
> 	> We have a common da8xx_omapl_defconfig which is being
> currently used by
> 	> multiple boards(including hawkboard). Not all boards have a
> nand flash
> 	> mounted as default. So i cannot add this in the above
> defconfig file. So
> 	
> 	
> 	On Thu, Feb 03, 2011 at 20:03:35, sughosh ganu wrote:
> 	Why? Boards which do not have NAND flash will not have
> 	NAND platform data registered. Enabling the NAND driver
> 	should cause no harm (except an increase in image size).
> 	
> 
> 
> Because i thought adding configs for features not used by all boards not
> to be a clean way of implementing it. I am confused as to why adding the
> configs for the board that uses those features is being frowned upon,
> but enabling them for boards which do not use it is fine. Can someone
> please elucidate.

Why do we think all Hawkboard users will need NAND? May be most users
like to boot using NFS?

> But if adding them to the defconfig file is ok, i will respin the patch
> accordingly and resubmit. Thanks.

This should be a separate patch. I think it is better to not mix defconfig 
updates with board file changes. Also, when you re-post, please make sure
to CC linux-arm-kernel.

Thanks,
Sekhar


From sudhakar.raj at ti.com  Fri Feb  4 03:05:54 2011
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Fri, 4 Feb 2011 14:35:54 +0530
Subject: DaVinci EMAC driver uses random MAC addresses
In-Reply-To: <AANLkTikJtF02W2BG_o4TVityj+Kk3iDAMQd1=UQn50NW@mail.gmail.com>
References: <4D271FB9.4020402@mvista.com> <4D27365F.4020504@ti.com>
	<AANLkTi=VrfzF5zKhhE3Vneq=OqhdCDAM-e7bOUL7EjuD@mail.gmail.com>
	<4D273C6C.8030801@criticallink.com> <878vywi8cb.fsf@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024829B2C0@dbde02.ent.ti.com>
	<AANLkTimDKVCDh-_L1qmhr9TL_MQU-Xeti21ssF4_Ur90@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024829B7E4@dbde02.ent.ti.com>
	<AANLkTinT5DjQ_4F1o_CYjdo8o8phd_077T5pYc5zDvL9@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248349789@dbde02.ent.ti.com>
	<AANLkTikJtF02W2BG_o4TVityj+Kk3iDAMQd1=UQn50NW@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024880B69D@dbde02.ent.ti.com>

Hi Steve,

On Tue, Jan 11, 2011 at 23:48:43, Steve Chen wrote:
> On Tue, Jan 11, 2011 at 10:38 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
> > Hi Steve,
> >
> > On Mon, Jan 10, 2011 at 20:40:56, Steve Chen wrote:
> >
> >> Yes, this seems to be NFS specific. ?Ethernet works fine when mounting
> >> on EXT3 on SD. ?I'm not sure if this is related to the lengthy NFS
> >> discussion happening on ARM mailing list either, but is seems unlikely
> >> since it would affect all DaVinci variants. ?I can retest when a patch
> >> becomes available.
> >
> > Not sure if you noticed but Trond already posted a patch and it has
> > already received some acks. Even without the patch, I was able to boot
> > my OMAP-L138 board fine except some occasional errors and freezes.
> > I have applied Trond's patch to my tree and will be testing it during
> > my regular development.
> 
> Sekhar,
> 
> I'm still getting
> 
> ...
> root: mount: mounting rootfs on / failed: No such file or directory
> root: mount: mounting usbfs on /proc/bus/usb failed: No such file or directory
> Setting up IP spoofing protection: rp_filter.
> Configuring network interfaces... udhcpc (v1.13.2) started
> Sending discover...
> Sending select for 192.168.40.109...
> Lease of 192.168.40.109 obtained, lease time 604800
> nfs: server 192.168.40.101 not responding, still trying
> 
> The init went passed udev, so NFS must be working earlier in the boot
> process.  The failure is likely caused by some incompatibilities
> between the kernel and filesystem.
> 
> Thanks for looking.
> 

I also faced this issue when used ip=dhcp in bootargs and this turned out to
be a file system specific issue. Arago file system starts a dhcp client on eth0
interface. Disabling this DHCP client resolves the above issue. You need to
edit the /etc/network/interfaces file of file system and comment out the
line "auto eth0".

Regards,
Sudhakar

From sudhakar.raj at ti.com  Fri Feb  4 03:22:26 2011
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Fri, 4 Feb 2011 14:52:26 +0530
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>

Hi Steve,

On Thu, Jan 13, 2011 at 19:53:26, Steve Chen wrote:
> Hello,
> 
> Running latest Davinci git kernel.  I issued
> 
>  # echo mem > /sys/power/state
> 
> to put DA850 EVM in sleep mode.  I'm unable to wake up the processor
> (tried UART, USB, or Ethernet).  Anyone knows how to bring the
> processor back?
> 

I am facing an issue while doing suspend/resume on latest DaVinci git
kernel. I followed:

* Compiled using da8xx_omapl_defconfig.
* Enabled CONFIG_PM and CONFIG_SUSPEND
* booted the EVM using NFS
* issued "echo mem > /sys/power/state"

At this stage I did not see any messages on the console. So I added
"no_console_suspend" to bootargs and got the below error messages
after issuing "echo mem > /sys/power/state":

------------[ cut here ]------------
WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf0/0x110()
Modules linked in:
[<c002d81c>] (unwind_backtrace+0x0/0xec) from [<c003d0b4>] (warn_slowpath_common+0x4c/0x64)
[<c003d0b4>] (warn_slowpath_common+0x4c/0x64) from [<c003d0e4>] (warn_slowpath_null+0x18/0x1c)
[<c003d0e4>] (warn_slowpath_null+0x18/0x1c) from [<c01a7c08>] (emac_rx_handler+0xf0/0x110)
[<c01a7c08>] (emac_rx_handler+0xf0/0x110) from [<c01a87a4>] (__cpdma_chan_free+0xb0/0xb4)
[<c01a87a4>] (__cpdma_chan_free+0xb0/0xb4) from [<c01a8ab8>] (cpdma_chan_stop+0x174/0x1d4)
[<c01a8ab8>] (cpdma_chan_stop+0x174/0x1d4) from [<c01a8b98>] (cpdma_ctlr_stop+0x80/0xe4)
[<c01a8b98>] (cpdma_ctlr_stop+0x80/0xe4) from [<c01a72a8>] (emac_dev_stop+0xb0/0x168)
[<c01a72a8>] (emac_dev_stop+0xb0/0x168) from [<c01a7378>] (davinci_emac_suspend+0x18/0x30)
[<c01a7378>] (davinci_emac_suspend+0x18/0x30) from [<c019d5ec>] (platform_pm_suspend+0x30/0x5c)
[<c019d5ec>] (platform_pm_suspend+0x30/0x5c) from [<c019fdd4>] (pm_op+0x4c/0xac)
[<c019fdd4>] (pm_op+0x4c/0xac) from [<c01a0674>] (__device_suspend+0xec/0x140)
[<c01a0674>] (__device_suspend+0xec/0x140) from [<c01a0934>] (dpm_suspend_start+0x26c/0x36c)
[<c01a0934>] (dpm_suspend_start+0x26c/0x36c) from [<c006cca0>] (suspend_devices_and_enter+0x40/0x1ac)
[<c006cca0>] (suspend_devices_and_enter+0x40/0x1ac) from [<c006ceb0>] (enter_state+0xa4/0xe0)
[<c006ceb0>] (enter_state+0xa4/0xe0) from [<c006c5d8>] (state_store+0x90/0xb8)
[<c006c5d8>] (state_store+0x90/0xb8) from [<c0159dc8>] (kobj_attr_store+0x18/0x1c)
[<c0159dc8>] (kobj_attr_store+0x18/0x1c) from [<c00e5dbc>] (sysfs_write_file+0x108/0x140)
[<c00e5dbc>] (sysfs_write_file+0x108/0x140) from [<c009cc30>] (vfs_write+0xac/0x134)
[<c009cc30>] (vfs_write+0xac/0x134) from [<c009cd64>] (sys_write+0x3c/0x68)
[<c009cd64>] (sys_write+0x3c/0x68) from [<c0028f80>] (ret_fast_syscall+0x0/0x2c)
---[ end trace febdd54cdf7fde9e ]---

I saw that you have mentioned that suspend/resume worked fine for you. Have
you tried suspend/resume when using NFS root file system?

I have not enabled any drivers in menuconfig except for I2C, Watchdog, RTC
and Ethernet.

emac_rx_handler() function was introduced by commit id 3ef0fdb2342cf58f617ce2bdcd133978629c2403.
I have also cc'ed the author of this commit, just in case he can help.

Regards,
Sudhakar

From jp.francois at cynove.com  Fri Feb  4 04:58:05 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Fri, 4 Feb 2011 11:58:05 +0100
Subject: DM365 uvc gadget
Message-ID: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>

Hi,

I have backported the UVC gadget patch by laurent pinchart on a custom
DM365 board.
It fails to allocate the required endpoints :

	ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
	if (!ep) {
		INFO(cdev, "Unable to allocate streaming EP\n");
		goto error;
	}

I can see the message "Unable to allocate streaming EP" in the log.
How can I debug / fix this ?

The mass storage gadget is working fine.

Here is the failing endpoint descriptor :

static struct usb_endpoint_descriptor uvc_streaming_ep = {
	.bLength		= USB_DT_ENDPOINT_SIZE,
	.bDescriptorType	= USB_DT_ENDPOINT,
	.bEndpointAddress	= USB_DIR_IN,
	.bmAttributes		= USB_ENDPOINT_XFER_ISOC,
	.wMaxPacketSize		= cpu_to_le16(1024),
	.bInterval		= 1,
};

Jean-Philippe Fran?ois

From ravibabu at ti.com  Fri Feb  4 05:09:55 2011
From: ravibabu at ti.com (B, Ravi)
Date: Fri, 4 Feb 2011 16:39:55 +0530
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024880B7C7@dbde02.ent.ti.com>

Hi

> -----Original Message-----
> From: davinci-linux-open-source-
> bounces+ravibabu=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-
> source-bounces+ravibabu=ti.com at linux.davincidsp.com] On Behalf Of jean-
> philippe francois
> Sent: Friday, February 04, 2011 4:28 PM
> To: davinci-linux-open-source at linux.davincidsp.com
> Subject: DM365 uvc gadget
> 
> Hi,
> 
> I have backported the UVC gadget patch by laurent pinchart on a custom
> DM365 board.
> It fails to allocate the required endpoints :
> 
> 	ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
> 	if (!ep) {
> 		INFO(cdev, "Unable to allocate streaming EP\n");
> 		goto error;
> 	}
> 
> I can see the message "Unable to allocate streaming EP" in the log.
> How can I debug / fix this ?
> 
> The mass storage gadget is working fine.
> 
> Here is the failing endpoint descriptor :
> 
> static struct usb_endpoint_descriptor uvc_streaming_ep = {
> 	.bLength		= USB_DT_ENDPOINT_SIZE,
> 	.bDescriptorType	= USB_DT_ENDPOINT,
> 	.bEndpointAddress	= USB_DIR_IN,
> 	.bmAttributes		= USB_ENDPOINT_XFER_ISOC,
> 	.wMaxPacketSize		= cpu_to_le16(1024),
> 	.bInterval		= 1,
> };
> 

The above endpoint requires endpoint fifo size to be 1024. Check with the fifo table entries in musb_core.c file and update as per requirement.

> Jean-Philippe Fran?ois
> _______________________________________________
> 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  Fri Feb  4 06:03:43 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 04 Feb 2011 15:03:43 +0300
Subject: [PATCH 1/3] davinci: spi: move event_q parameter to platform data
In-Reply-To: <1296779690-9723-2-git-send-email-michael.williamson@criticallink.com>
References: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>
	<1296779690-9723-2-git-send-email-michael.williamson@criticallink.com>
Message-ID: <4D4BEB1F.6060200@mvista.com>

Hello.

On 04-02-2011 3:34, Michael Williamson wrote:

> For DMA operation, the davinci spi driver needs an eventq number.
> Currently, this number is passed as a IORESOURCE_DMA.  This is not
> correct, as the eventq is not a DMA channel.  Pass the eventq
> via the platform data structure instead.

> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
[...]

> diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
> index 38f4da5..0853a5f 100644
> --- a/arch/arm/mach-davinci/include/mach/spi.h
> +++ b/arch/arm/mach-davinci/include/mach/spi.h
[...]
> @@ -39,13 +41,16 @@ enum {
>    *		to populate if all chip-selects are internal.
>    * @cshold_bug:	set this to true if the SPI controller on your chip requires
>    *		a write to CSHOLD bit in between transfers (like in DM355).
> + * @dma_event_q: DMA event_q to use if SPI_IO_TYPE_DMA is used for any device

    s/event_q/event queue/?

> + *		on the bus.
>    */
>   struct davinci_spi_platform_data {
> -	u8	version;
> -	u8	num_chipselect;
> -	u8	intr_line;
> -	u8	*chip_sel;
> -	bool	cshold_bug;
> +	u8			version;
> +	u8			num_chipselect;
> +	u8			intr_line;
> +	u8			*chip_sel;
> +	bool			cshold_bug;
> +	enum dma_event_q	dma_event_q;
>   };
>
>   /**
> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
> index 6beab99..166a879 100644
> --- a/drivers/spi/davinci_spi.c
> +++ b/drivers/spi/davinci_spi.c
[...]
> @@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device *pdev)
>   	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;
>
>   	dspi->bitbang.txrx_bufs = davinci_spi_bufs;
>   	if (dma_rx_chan != SPI_NO_RESOURCE&&
> -	    dma_tx_chan != SPI_NO_RESOURCE&&
> -	    dma_eventq != SPI_NO_RESOURCE) {
> +	    dma_tx_chan != SPI_NO_RESOURCE) {
>   		dspi->dma.rx_channel = dma_rx_chan;
>   		dspi->dma.tx_channel = dma_tx_chan;
> -		dspi->dma.eventq = dma_eventq;
> +		dspi->dma.eventq = pdata->dma_event_q;

    It makes sense to merge this patch with the patches 2 and 3 as otherwise 
the bisectability is prevented for DM3[56]5 -- their 'dma_event_q' field will 
be anonymously initialized to 0 after this patch but should be 1 and 3 instead 
correspondingly. Although, this doesn't seem to be a fatal defect, so the 
patches can be kept separate... Don't know what's better.

WBR, Sergei

From michael.williamson at criticallink.com  Fri Feb  4 06:27:16 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Fri, 04 Feb 2011 07:27:16 -0500
Subject: [PATCH 1/3] davinci: spi: move event_q parameter to platform data
In-Reply-To: <4D4BEB1F.6060200@mvista.com>
References: <1296779690-9723-1-git-send-email-michael.williamson@criticallink.com>
	<1296779690-9723-2-git-send-email-michael.williamson@criticallink.com>
	<4D4BEB1F.6060200@mvista.com>
Message-ID: <4D4BF0A4.9010509@criticallink.com>

Hi Sergei,

On 2/4/2011 7:03 AM, Sergei Shtylyov wrote:

> Hello.
> 
> On 04-02-2011 3:34, Michael Williamson wrote:
> 
>> For DMA operation, the davinci spi driver needs an eventq number.
>> Currently, this number is passed as a IORESOURCE_DMA.  This is not
>> correct, as the eventq is not a DMA channel.  Pass the eventq
>> via the platform data structure instead.
> 
>> Signed-off-by: Michael Williamson<michael.williamson at criticallink.com>
> [...]
> 
>> diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
>> index 38f4da5..0853a5f 100644
>> --- a/arch/arm/mach-davinci/include/mach/spi.h
>> +++ b/arch/arm/mach-davinci/include/mach/spi.h
> [...]
>> @@ -39,13 +41,16 @@ enum {
>>    *        to populate if all chip-selects are internal.
>>    * @cshold_bug:    set this to true if the SPI controller on your chip requires
>>    *        a write to CSHOLD bit in between transfers (like in DM355).
>> + * @dma_event_q: DMA event_q to use if SPI_IO_TYPE_DMA is used for any device
> 
>    s/event_q/event queue/?
> 
>> + *        on the bus.
>>    */
>>   struct davinci_spi_platform_data {
>> -    u8    version;
>> -    u8    num_chipselect;
>> -    u8    intr_line;
>> -    u8    *chip_sel;
>> -    bool    cshold_bug;
>> +    u8            version;
>> +    u8            num_chipselect;
>> +    u8            intr_line;
>> +    u8            *chip_sel;
>> +    bool            cshold_bug;
>> +    enum dma_event_q    dma_event_q;
>>   };
>>
>>   /**
>> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
>> index 6beab99..166a879 100644
>> --- a/drivers/spi/davinci_spi.c
>> +++ b/drivers/spi/davinci_spi.c
> [...]
>> @@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device *pdev)
>>       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;
>>
>>       dspi->bitbang.txrx_bufs = davinci_spi_bufs;
>>       if (dma_rx_chan != SPI_NO_RESOURCE&&
>> -        dma_tx_chan != SPI_NO_RESOURCE&&
>> -        dma_eventq != SPI_NO_RESOURCE) {
>> +        dma_tx_chan != SPI_NO_RESOURCE) {
>>           dspi->dma.rx_channel = dma_rx_chan;
>>           dspi->dma.tx_channel = dma_tx_chan;
>> -        dspi->dma.eventq = dma_eventq;
>> +        dspi->dma.eventq = pdata->dma_event_q;
> 
>    It makes sense to merge this patch with the patches 2 and 3 as otherwise the bisectability is prevented for DM3[56]5 -- their 'dma_event_q' field will be anonymously initialized to 0 after this patch but should be 1 and 3 instead correspondingly. Although, this doesn't seem to be a fatal defect, so the patches can be kept separate... Don't know what's better.
> 


Barring any other comments, I will collapse the patches and resend.  
I will correct the typo you mentioned above as well.

Thanks.

-Mike


> WBR, Sergei



From jp.francois at cynove.com  Fri Feb  4 06:47:09 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Fri, 4 Feb 2011 13:47:09 +0100
Subject: DM365 uvc gadget
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024880B7C7@dbde02.ent.ti.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B7C7@dbde02.ent.ti.com>
Message-ID: <AANLkTik9MYm6pin4E=QvOnLh0uYf=USP1pUuS28SvLMk@mail.gmail.com>

2011/2/4 B, Ravi <ravibabu at ti.com>:
> Hi
>
>> -----Original Message-----
>> From: davinci-linux-open-source-
>> bounces+ravibabu=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-
>> source-bounces+ravibabu=ti.com at linux.davincidsp.com] On Behalf Of jean-
>> philippe francois
>> Sent: Friday, February 04, 2011 4:28 PM
>> To: davinci-linux-open-source at linux.davincidsp.com
>> Subject: DM365 uvc gadget
>>
>> Hi,
>>
>> I have backported the UVC gadget patch by laurent pinchart on a custom
>> DM365 board.
>> It fails to allocate the required endpoints :
>>
>> ? ? ? ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
>> ? ? ? if (!ep) {
>> ? ? ? ? ? ? ? INFO(cdev, "Unable to allocate streaming EP\n");
>> ? ? ? ? ? ? ? goto error;
>> ? ? ? }
>>
>> I can see the message "Unable to allocate streaming EP" in the log.
>> How can I debug / fix this ?
>>
>> The mass storage gadget is working fine.
>>
>> Here is the failing endpoint descriptor :
>>
>> static struct usb_endpoint_descriptor uvc_streaming_ep = {
>> ? ? ? .bLength ? ? ? ? ? ? ? ?= USB_DT_ENDPOINT_SIZE,
>> ? ? ? .bDescriptorType ? ? ? ?= USB_DT_ENDPOINT,
>> ? ? ? .bEndpointAddress ? ? ? = USB_DIR_IN,
>> ? ? ? .bmAttributes ? ? ? ? ? = USB_ENDPOINT_XFER_ISOC,
>> ? ? ? .wMaxPacketSize ? ? ? ? = cpu_to_le16(1024),
>> ? ? ? .bInterval ? ? ? ? ? ? ?= 1,
>> };
>>
>
> The above endpoint requires endpoint fifo size to be 1024. Check with the fifo table entries in musb_core.c file and update as per requirement.
>

So I can either change the fifo_mode module paramete to pick another config, or
change the endpoint config to use a smaller packet size ?

>> Jean-Philippe Fran?ois
>> _______________________________________________
>> 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 ravibabu at ti.com  Fri Feb  4 06:54:54 2011
From: ravibabu at ti.com (B, Ravi)
Date: Fri, 4 Feb 2011 18:24:54 +0530
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTik9MYm6pin4E=QvOnLh0uYf=USP1pUuS28SvLMk@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B7C7@dbde02.ent.ti.com>
	<AANLkTik9MYm6pin4E=QvOnLh0uYf=USP1pUuS28SvLMk@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024880B867@dbde02.ent.ti.com>


> >> Hi,
> >>
> >> I have backported the UVC gadget patch by laurent pinchart on a custom
> >> DM365 board.
> >> It fails to allocate the required endpoints :
> >>
> >> ? ? ? ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
> >> ? ? ? if (!ep) {
> >> ? ? ? ? ? ? ? INFO(cdev, "Unable to allocate streaming EP\n");
> >> ? ? ? ? ? ? ? goto error;
> >> ? ? ? }
> >>
> >> I can see the message "Unable to allocate streaming EP" in the log.
> >> How can I debug / fix this ?
> >>
> >> The mass storage gadget is working fine.
> >>
> >> Here is the failing endpoint descriptor :
> >>
> >> static struct usb_endpoint_descriptor uvc_streaming_ep = {
> >> ? ? ? .bLength ? ? ? ? ? ? ? ?= USB_DT_ENDPOINT_SIZE,
> >> ? ? ? .bDescriptorType ? ? ? ?= USB_DT_ENDPOINT,
> >> ? ? ? .bEndpointAddress ? ? ? = USB_DIR_IN,
> >> ? ? ? .bmAttributes ? ? ? ? ? = USB_ENDPOINT_XFER_ISOC,
> >> ? ? ? .wMaxPacketSize ? ? ? ? = cpu_to_le16(1024),
> >> ? ? ? .bInterval ? ? ? ? ? ? ?= 1,
> >> };
> >>
> >
> > The above endpoint requires endpoint fifo size to be 1024. Check with
> the fifo table entries in musb_core.c file and update as per requirement.
> >
> 
> So I can either change the fifo_mode module paramete to pick another
> config, or
> change the endpoint config to use a smaller packet size ?
> 

If the UVC driver requirement may be 1024 bytes packet size, then you cannot change, what you can do is change the current fifo-mode 
configuration sizes as per your device requirements. 

For example :
/* mode 4 - fits in 4KB */
static struct musb_fifo_cfg __devinitdata mode_4_cfg[] = {
{ .hw_ep_num =  1, .style = FIFO_TX,   .maxpacket = 512, },
{ .hw_ep_num =  1, .style = FIFO_RX,   .maxpacket = 512, },
{ .hw_ep_num =  2, .style = FIFO_TX,   .maxpacket = 1024, },
{ .hw_ep_num =  2, .style = FIFO_RX,   .maxpacket = 1024, },
{ .hw_ep_num =  3, .style = FIFO_TX,   .maxpacket = 256, },
{ .hw_ep_num =  3, .style = FIFO_RX,   .maxpacket = 256, },

Ravi

> >> Jean-Philippe Fran?ois
> >> _______________________________________________
> >> 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 caglarakyuz at gmail.com  Fri Feb  4 07:21:56 2011
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Fri, 4 Feb 2011 15:21:56 +0200
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
Message-ID: <201102041521.56299.caglarakyuz@gmail.com>

On Friday 04 February 2011 11:22:26 am Rajashekhara, Sudhakar wrote:
> Hi Steve,
> 
> On Thu, Jan 13, 2011 at 19:53:26, Steve Chen wrote:
> > Hello,
> >
> > Running latest Davinci git kernel.  I issued
> >
> >  # echo mem > /sys/power/state
> >
> > to put DA850 EVM in sleep mode.  I'm unable to wake up the processor
> > (tried UART, USB, or Ethernet).  Anyone knows how to bring the
> > processor back?
> 
> I am facing an issue while doing suspend/resume on latest DaVinci git
> kernel. I followed:
> 
> * Compiled using da8xx_omapl_defconfig.
> * Enabled CONFIG_PM and CONFIG_SUSPEND
> * booted the EVM using NFS
> * issued "echo mem > /sys/power/state"
> 
> At this stage I did not see any messages on the console. So I added
> "no_console_suspend" to bootargs and got the below error messages
> after issuing "echo mem > /sys/power/state":
> 
> ------------[ cut here ]------------
> WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf0/0x110()
> Modules linked in:
> [<c002d81c>] (unwind_backtrace+0x0/0xec) from [<c003d0b4>]
>  (warn_slowpath_common+0x4c/0x64) [<c003d0b4>]
>  (warn_slowpath_common+0x4c/0x64) from [<c003d0e4>]
>  (warn_slowpath_null+0x18/0x1c) [<c003d0e4>] (warn_slowpath_null+0x18/0x1c)
>  from [<c01a7c08>] (emac_rx_handler+0xf0/0x110) [<c01a7c08>]
>  (emac_rx_handler+0xf0/0x110) from [<c01a87a4>]
>  (__cpdma_chan_free+0xb0/0xb4) [<c01a87a4>] (__cpdma_chan_free+0xb0/0xb4)
>  from [<c01a8ab8>] (cpdma_chan_stop+0x174/0x1d4) [<c01a8ab8>]
>  (cpdma_chan_stop+0x174/0x1d4) from [<c01a8b98>]
>  (cpdma_ctlr_stop+0x80/0xe4) [<c01a8b98>] (cpdma_ctlr_stop+0x80/0xe4) from
>  [<c01a72a8>] (emac_dev_stop+0xb0/0x168) [<c01a72a8>]
>  (emac_dev_stop+0xb0/0x168) from [<c01a7378>]
>  (davinci_emac_suspend+0x18/0x30) [<c01a7378>]
>  (davinci_emac_suspend+0x18/0x30) from [<c019d5ec>]
>  (platform_pm_suspend+0x30/0x5c) [<c019d5ec>]
>  (platform_pm_suspend+0x30/0x5c) from [<c019fdd4>] (pm_op+0x4c/0xac)
>  [<c019fdd4>] (pm_op+0x4c/0xac) from [<c01a0674>]
>  (__device_suspend+0xec/0x140) [<c01a0674>] (__device_suspend+0xec/0x140)
>  from [<c01a0934>] (dpm_suspend_start+0x26c/0x36c) [<c01a0934>]
>  (dpm_suspend_start+0x26c/0x36c) from [<c006cca0>]
>  (suspend_devices_and_enter+0x40/0x1ac) [<c006cca0>]
>  (suspend_devices_and_enter+0x40/0x1ac) from [<c006ceb0>]
>  (enter_state+0xa4/0xe0) [<c006ceb0>] (enter_state+0xa4/0xe0) from
>  [<c006c5d8>] (state_store+0x90/0xb8) [<c006c5d8>] (state_store+0x90/0xb8)
>  from [<c0159dc8>] (kobj_attr_store+0x18/0x1c) [<c0159dc8>]
>  (kobj_attr_store+0x18/0x1c) from [<c00e5dbc>]
>  (sysfs_write_file+0x108/0x140) [<c00e5dbc>] (sysfs_write_file+0x108/0x140)
>  from [<c009cc30>] (vfs_write+0xac/0x134) [<c009cc30>]
>  (vfs_write+0xac/0x134) from [<c009cd64>] (sys_write+0x3c/0x68)
>  [<c009cd64>] (sys_write+0x3c/0x68) from [<c0028f80>]
>  (ret_fast_syscall+0x0/0x2c) ---[ end trace febdd54cdf7fde9e ]---
> 
> I saw that you have mentioned that suspend/resume worked fine for you. Have
> you tried suspend/resume when using NFS root file system?
> 
> I have not enabled any drivers in menuconfig except for I2C, Watchdog, RTC
> and Ethernet.
> 

I cannot suspend/resume on DM6446 while ethernet is active. emac driver is not 
well behaving wrt to suspend. After shutting down eth interfaces(ifconfig eth0 
down) I can suspend/resume without any problem.

> emac_rx_handler() function was introduced by commit id
>  3ef0fdb2342cf58f617ce2bdcd133978629c2403. I have also cc'ed the author of
>  this commit, just in case he can help.
> 

I reverted that commit and results were the same. I don't think problem is 
introduced by new cpdma layer patches.

Regards,
Caglar 

From jp.francois at cynove.com  Fri Feb  4 07:41:41 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Fri, 4 Feb 2011 14:41:41 +0100
Subject: DM365 uvc gadget
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024880B867@dbde02.ent.ti.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B7C7@dbde02.ent.ti.com>
	<AANLkTik9MYm6pin4E=QvOnLh0uYf=USP1pUuS28SvLMk@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B867@dbde02.ent.ti.com>
Message-ID: <AANLkTinSQjic73tNsd54o_h=8scjtbkf4XC==sCHMs5E@mail.gmail.com>

2011/2/4 B, Ravi <ravibabu at ti.com>:
>
>> >> Hi,
>> >>
>> >> I have backported the UVC gadget patch by laurent pinchart on a custom
>> >> DM365 board.
>> >> It fails to allocate the required endpoints :
>> >>
>> >> ? ? ? ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
>> >> ? ? ? if (!ep) {
>> >> ? ? ? ? ? ? ? INFO(cdev, "Unable to allocate streaming EP\n");
>> >> ? ? ? ? ? ? ? goto error;
>> >> ? ? ? }
>> >>
>> >> I can see the message "Unable to allocate streaming EP" in the log.
>> >> How can I debug / fix this ?
>> >>
>> >> The mass storage gadget is working fine.
>> >>
>> >> Here is the failing endpoint descriptor :
>> >>
>> >> static struct usb_endpoint_descriptor uvc_streaming_ep = {
>> >> ? ? ? .bLength ? ? ? ? ? ? ? ?= USB_DT_ENDPOINT_SIZE,
>> >> ? ? ? .bDescriptorType ? ? ? ?= USB_DT_ENDPOINT,
>> >> ? ? ? .bEndpointAddress ? ? ? = USB_DIR_IN,
>> >> ? ? ? .bmAttributes ? ? ? ? ? = USB_ENDPOINT_XFER_ISOC,
>> >> ? ? ? .wMaxPacketSize ? ? ? ? = cpu_to_le16(1024),
>> >> ? ? ? .bInterval ? ? ? ? ? ? ?= 1,
>> >> };
>> >>
>> >
>> > The above endpoint requires endpoint fifo size to be 1024. Check with
>> the fifo table entries in musb_core.c file and update as per requirement.
>> >
>>
>> So I can either change the fifo_mode module paramete to pick another
>> config, or
>> change the endpoint config to use a smaller packet size ?
>>
>
> If the UVC driver requirement may be 1024 bytes packet size, then you cannot change, what you can do is change the current fifo-mode
> configuration sizes as per your device requirements.
>
> For example :
> /* mode 4 - fits in 4KB */
> static struct musb_fifo_cfg __devinitdata mode_4_cfg[] = {
> { .hw_ep_num = ?1, .style = FIFO_TX, ? .maxpacket = 512, },
> { .hw_ep_num = ?1, .style = FIFO_RX, ? .maxpacket = 512, },
> { .hw_ep_num = ?2, .style = FIFO_TX, ? .maxpacket = 1024, },
> { .hw_ep_num = ?2, .style = FIFO_RX, ? .maxpacket = 1024, },
> { .hw_ep_num = ?3, .style = FIFO_TX, ? .maxpacket = 256, },
> { .hw_ep_num = ?3, .style = FIFO_RX, ? .maxpacket = 256, },
>
Thank you, I can see that more recent kernel have the possibility
to specify this config in platform_data, which is great !

> Ravi
>
>> >> Jean-Philippe Fran?ois
>> >> _______________________________________________
>> >> 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 michael.williamson at criticallink.com  Fri Feb  4 08:09:12 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Fri,  4 Feb 2011 09:09:12 -0500
Subject: [PATCH v1] davinci: spi: move event queue parameter to platform data
Message-ID: <1296828552-11765-1-git-send-email-michael.williamson@criticallink.com>

For DMA operation, the davinci spi driver needs an event queue number.
Currently, this number is passed as a IORESOURCE_DMA.  This is not
correct, as the event queue is not a DMA channel.  Pass the event queue
via the platform data structure instead.

On dm355 and dm365, move the eventq assignment for spi0 out of resources
array and into platform data.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
Changes since v0:
  - combined separate platform patches with driver patch to avoid
    potential regression if doing a bissect.
  - fixed up typo per comments.

 arch/arm/mach-davinci/dm355.c            |    5 +----
 arch/arm/mach-davinci/dm365.c            |    5 +----
 arch/arm/mach-davinci/include/mach/spi.h |   15 ++++++++++-----
 drivers/spi/davinci_spi.c                |   11 +++--------
 4 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a5f8a80..76364d1 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -403,16 +403,13 @@ static struct resource dm355_spi0_resources[] = {
 		.start = 16,
 		.flags = IORESOURCE_DMA,
 	},
-	{
-		.start = EVENTQ_1,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct davinci_spi_platform_data dm355_spi0_pdata = {
 	.version 	= SPI_VERSION_1,
 	.num_chipselect = 2,
 	.cshold_bug	= true,
+	.dma_event_q	= EVENTQ_1,
 };
 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 02d2cc3..4604e72 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -625,6 +625,7 @@ 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,
+	.dma_event_q	= EVENTQ_3,
 };
 
 static struct resource dm365_spi0_resources[] = {
@@ -645,10 +646,6 @@ static struct resource dm365_spi0_resources[] = {
 		.start = 16,
 		.flags = IORESOURCE_DMA,
 	},
-	{
-		.start = EVENTQ_3,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct platform_device dm365_spi0_device = {
diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
index 38f4da5..0853a5f 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -19,6 +19,8 @@
 #ifndef __ARCH_ARM_DAVINCI_SPI_H
 #define __ARCH_ARM_DAVINCI_SPI_H
 
+#include <mach/edma.h>
+
 #define SPI_INTERN_CS	0xFF
 
 enum {
@@ -39,13 +41,16 @@ enum {
  *		to populate if all chip-selects are internal.
  * @cshold_bug:	set this to true if the SPI controller on your chip requires
  *		a write to CSHOLD bit in between transfers (like in DM355).
+ * @dma_event_q: DMA event_q to use if SPI_IO_TYPE_DMA is used for any device
+ *		on the bus.
  */
 struct davinci_spi_platform_data {
-	u8	version;
-	u8	num_chipselect;
-	u8	intr_line;
-	u8	*chip_sel;
-	bool	cshold_bug;
+	u8			version;
+	u8			num_chipselect;
+	u8			intr_line;
+	u8			*chip_sel;
+	bool			cshold_bug;
+	enum dma_event_q	dma_event_q;
 };
 
 /**
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 6beab99..166a879 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -790,7 +790,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	struct resource *r, *mem;
 	resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
 	resource_size_t	dma_tx_chan = SPI_NO_RESOURCE;
-	resource_size_t	dma_eventq = SPI_NO_RESOURCE;
 	int i = 0, ret = 0;
 	u32 spipc0;
 
@@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	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;
 
 	dspi->bitbang.txrx_bufs = davinci_spi_bufs;
 	if (dma_rx_chan != SPI_NO_RESOURCE &&
-	    dma_tx_chan != SPI_NO_RESOURCE &&
-	    dma_eventq != SPI_NO_RESOURCE) {
+	    dma_tx_chan != SPI_NO_RESOURCE) {
 		dspi->dma.rx_channel = dma_rx_chan;
 		dspi->dma.tx_channel = dma_tx_chan;
-		dspi->dma.eventq = dma_eventq;
+		dspi->dma.eventq = pdata->dma_event_q;
 
 		ret = davinci_spi_request_dma(dspi);
 		if (ret)
@@ -897,7 +892,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
 		dev_info(&pdev->dev, "DMA: supported\n");
 		dev_info(&pdev->dev, "DMA: RX channel: %d, TX channel: %d, "
 				"event queue: %d\n", dma_rx_chan, dma_tx_chan,
-				dma_eventq);
+				pdata->dma_event_q);
 	}
 
 	dspi->get_rx = davinci_spi_rx_buf_u8;
-- 
1.7.0.4


From schen at mvista.com  Fri Feb  4 09:54:42 2011
From: schen at mvista.com (Steve Chen)
Date: Fri, 4 Feb 2011 09:54:42 -0600
Subject: DaVinci EMAC driver uses random MAC addresses
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024880B69D@dbde02.ent.ti.com>
References: <4D271FB9.4020402@mvista.com> <4D27365F.4020504@ti.com>
	<AANLkTi=VrfzF5zKhhE3Vneq=OqhdCDAM-e7bOUL7EjuD@mail.gmail.com>
	<4D273C6C.8030801@criticallink.com> <878vywi8cb.fsf@ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024829B2C0@dbde02.ent.ti.com>
	<AANLkTimDKVCDh-_L1qmhr9TL_MQU-Xeti21ssF4_Ur90@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024829B7E4@dbde02.ent.ti.com>
	<AANLkTinT5DjQ_4F1o_CYjdo8o8phd_077T5pYc5zDvL9@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930248349789@dbde02.ent.ti.com>
	<AANLkTikJtF02W2BG_o4TVityj+Kk3iDAMQd1=UQn50NW@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B69D@dbde02.ent.ti.com>
Message-ID: <AANLkTin5ETtPPfXE_KCkvGSynHKwzU4uZOqhkrVZkJiC@mail.gmail.com>

On Fri, Feb 4, 2011 at 3:05 AM, Rajashekhara, Sudhakar
<sudhakar.raj at ti.com> wrote:
> Hi Steve,
>
> On Tue, Jan 11, 2011 at 23:48:43, Steve Chen wrote:
>> On Tue, Jan 11, 2011 at 10:38 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
>> > Hi Steve,
>> >
>> > On Mon, Jan 10, 2011 at 20:40:56, Steve Chen wrote:
>> >
>> >> Yes, this seems to be NFS specific. ?Ethernet works fine when mounting
>> >> on EXT3 on SD. ?I'm not sure if this is related to the lengthy NFS
>> >> discussion happening on ARM mailing list either, but is seems unlikely
>> >> since it would affect all DaVinci variants. ?I can retest when a patch
>> >> becomes available.
>> >
>> > Not sure if you noticed but Trond already posted a patch and it has
>> > already received some acks. Even without the patch, I was able to boot
>> > my OMAP-L138 board fine except some occasional errors and freezes.
>> > I have applied Trond's patch to my tree and will be testing it during
>> > my regular development.
>>
>> Sekhar,
>>
>> I'm still getting
>>
>> ...
>> root: mount: mounting rootfs on / failed: No such file or directory
>> root: mount: mounting usbfs on /proc/bus/usb failed: No such file or directory
>> Setting up IP spoofing protection: rp_filter.
>> Configuring network interfaces... udhcpc (v1.13.2) started
>> Sending discover...
>> Sending select for 192.168.40.109...
>> Lease of 192.168.40.109 obtained, lease time 604800
>> nfs: server 192.168.40.101 not responding, still trying
>>
>> The init went passed udev, so NFS must be working earlier in the boot
>> process. ?The failure is likely caused by some incompatibilities
>> between the kernel and filesystem.
>>
>> Thanks for looking.
>>
>
> I also faced this issue when used ip=dhcp in bootargs and this turned out to
> be a file system specific issue. Arago file system starts a dhcp client on eth0
> interface. Disabling this DHCP client resolves the above issue. You need to
> edit the /etc/network/interfaces file of file system and comment out the
> line "auto eth0".

Sudhakar,

NFS comes up great after comment out that line.

Thanks,

Steve

From schen at mvista.com  Fri Feb  4 10:12:41 2011
From: schen at mvista.com (Steve Chen)
Date: Fri, 4 Feb 2011 10:12:41 -0600
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
Message-ID: <AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>

On Fri, Feb 4, 2011 at 3:22 AM, Rajashekhara, Sudhakar
<sudhakar.raj at ti.com> wrote:
> Hi Steve,
>
> On Thu, Jan 13, 2011 at 19:53:26, Steve Chen wrote:
>> Hello,
>>
>> Running latest Davinci git kernel. ?I issued
>>
>> ?# echo mem > /sys/power/state
>>
>> to put DA850 EVM in sleep mode. ?I'm unable to wake up the processor
>> (tried UART, USB, or Ethernet). ?Anyone knows how to bring the
>> processor back?
>>
>
> I am facing an issue while doing suspend/resume on latest DaVinci git
> kernel. I followed:
>
> * Compiled using da8xx_omapl_defconfig.
> * Enabled CONFIG_PM and CONFIG_SUSPEND
> * booted the EVM using NFS
> * issued "echo mem > /sys/power/state"
>
> At this stage I did not see any messages on the console. So I added
> "no_console_suspend" to bootargs and got the below error messages
> after issuing "echo mem > /sys/power/state":
>
> ------------[ cut here ]------------
> WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf0/0x110()
> Modules linked in:
> [<c002d81c>] (unwind_backtrace+0x0/0xec) from [<c003d0b4>] (warn_slowpath_common+0x4c/0x64)
> [<c003d0b4>] (warn_slowpath_common+0x4c/0x64) from [<c003d0e4>] (warn_slowpath_null+0x18/0x1c)
> [<c003d0e4>] (warn_slowpath_null+0x18/0x1c) from [<c01a7c08>] (emac_rx_handler+0xf0/0x110)
> [<c01a7c08>] (emac_rx_handler+0xf0/0x110) from [<c01a87a4>] (__cpdma_chan_free+0xb0/0xb4)
> [<c01a87a4>] (__cpdma_chan_free+0xb0/0xb4) from [<c01a8ab8>] (cpdma_chan_stop+0x174/0x1d4)
> [<c01a8ab8>] (cpdma_chan_stop+0x174/0x1d4) from [<c01a8b98>] (cpdma_ctlr_stop+0x80/0xe4)
> [<c01a8b98>] (cpdma_ctlr_stop+0x80/0xe4) from [<c01a72a8>] (emac_dev_stop+0xb0/0x168)
> [<c01a72a8>] (emac_dev_stop+0xb0/0x168) from [<c01a7378>] (davinci_emac_suspend+0x18/0x30)
> [<c01a7378>] (davinci_emac_suspend+0x18/0x30) from [<c019d5ec>] (platform_pm_suspend+0x30/0x5c)
> [<c019d5ec>] (platform_pm_suspend+0x30/0x5c) from [<c019fdd4>] (pm_op+0x4c/0xac)
> [<c019fdd4>] (pm_op+0x4c/0xac) from [<c01a0674>] (__device_suspend+0xec/0x140)
> [<c01a0674>] (__device_suspend+0xec/0x140) from [<c01a0934>] (dpm_suspend_start+0x26c/0x36c)
> [<c01a0934>] (dpm_suspend_start+0x26c/0x36c) from [<c006cca0>] (suspend_devices_and_enter+0x40/0x1ac)
> [<c006cca0>] (suspend_devices_and_enter+0x40/0x1ac) from [<c006ceb0>] (enter_state+0xa4/0xe0)
> [<c006ceb0>] (enter_state+0xa4/0xe0) from [<c006c5d8>] (state_store+0x90/0xb8)
> [<c006c5d8>] (state_store+0x90/0xb8) from [<c0159dc8>] (kobj_attr_store+0x18/0x1c)
> [<c0159dc8>] (kobj_attr_store+0x18/0x1c) from [<c00e5dbc>] (sysfs_write_file+0x108/0x140)
> [<c00e5dbc>] (sysfs_write_file+0x108/0x140) from [<c009cc30>] (vfs_write+0xac/0x134)
> [<c009cc30>] (vfs_write+0xac/0x134) from [<c009cd64>] (sys_write+0x3c/0x68)
> [<c009cd64>] (sys_write+0x3c/0x68) from [<c0028f80>] (ret_fast_syscall+0x0/0x2c)
> ---[ end trace febdd54cdf7fde9e ]---
>
> I saw that you have mentioned that suspend/resume worked fine for you. Have
> you tried suspend/resume when using NFS root file system?
>
> I have not enabled any drivers in menuconfig except for I2C, Watchdog, RTC
> and Ethernet.
>
> emac_rx_handler() function was introduced by commit id 3ef0fdb2342cf58f617ce2bdcd133978629c2403.
> I have also cc'ed the author of this commit, just in case he can help.

Sudhakar,

I just tried suspend/resume with NFS mounted file system.  NFS did not
wake up for me either.  For my case, I got the following output from
rtcwake

> rtcwake  -s 40 rtc0
rtcwake: /dev/rtc not enabled for wakeup events

It appears the RTC was not setup correctly for me with NFS mounted
filesystem, but rtcwake works when I have rootfs on SD or SPI FLASH.
Did you do anything special to get rtcwake working?

Steve

From nsekhar at ti.com  Fri Feb  4 10:52:43 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 4 Feb 2011 22:22:43 +0530
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>

Hi Steve,

On Fri, Feb 04, 2011 at 21:42:41, Steve Chen wrote:

> > rtcwake  -s 40 rtc0
> rtcwake: /dev/rtc not enabled for wakeup events

I have a feeling rtcwake is looking at the wrong device
node. Can you try:

$ rtcwake -d /dev/rtc0 -s 20 -m mem

Thanks,
Sekhar

From schen at mvista.com  Fri Feb  4 11:15:17 2011
From: schen at mvista.com (Steve Chen)
Date: Fri, 4 Feb 2011 11:15:17 -0600
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>
Message-ID: <AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>

On Fri, Feb 4, 2011 at 10:52 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
> Hi Steve,
>
> On Fri, Feb 04, 2011 at 21:42:41, Steve Chen wrote:
>
>> > rtcwake ?-s 40 rtc0
>> rtcwake: /dev/rtc not enabled for wakeup events
>
> I have a feeling rtcwake is looking at the wrong device
> node. Can you try:
>
> $ rtcwake -d /dev/rtc0 -s 20 -m mem
>

Doh!!.   Sekhar, you are right.  I did not include the "-d" flag.
After passing the correct parameter to rtcwake, I'm able to wake up
from sleep with NFS rootfs.  I'm running the kernel/filesystem from
PSP 03.20.00.14.

Steve

From dmarsh10 at hotmail.com  Fri Feb  4 11:45:40 2011
From: dmarsh10 at hotmail.com (Danny Marsh)
Date: Fri, 4 Feb 2011 11:45:40 -0600
Subject: Linux + CE + POSIX interval timers
Message-ID: <SNT109-DS18450C922EF9FFB20BBE01CFE60@phx.gbl>

Hello,

We are developing a DM6446 platform with linux and the dvsdk_2_00_00_22.  We have created several iUniversal Codec Engine algorithms and can get them to run independently.  We then tried to integrate the algorithms into another application that was using interval timers (setitimer and timer_create), and ALSA.  This is where we started running into issues.  First when we started the interval timers before opening the DSP server, the server wouldn't even open.  When we opened the handles to the DSP server before starting the interval timers it opened, but the interval timers weren't working correctly.

Has anyone had experience trying to do this?

Is there a better way to do accurate timing (20 msec) than with interval timers?

Thanks,
Danny  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110204/6527170e/attachment.html>

From rtivy at ti.com  Fri Feb  4 12:07:53 2011
From: rtivy at ti.com (Tivy, Robert)
Date: Fri, 4 Feb 2011 12:07:53 -0600
Subject: Error While Running Demos
In-Reply-To: <AANLkTiniqjF8GNhdXpyP_-BV3dnQtfpTKa911GreB1ag@mail.gmail.com>
References: <AANLkTimhZy=SLnZvQm=zTqQe9XKQi3Ofkkof2xwFr0xW@mail.gmail.com>
	<6B8224E84039B140AA662F0BB03616430188FA63B9@dlee04.ent.ti.com>
	<AANLkTin0qPs+wuomtd3dpyptueQiWdmm7=pQS-LeAD5W@mail.gmail.com>
	<AANLkTinQKoBe0CHVVdXOQA-_RC02ePkV9mG80pEaoA4K@mail.gmail.com>
	<AANLkTiniqjF8GNhdXpyP_-BV3dnQtfpTKa911GreB1ag@mail.gmail.com>
Message-ID: <6B8224E84039B140AA662F0BB036164301890353B4@dlee04.ent.ti.com>

The Codec Engine "Processor" module can't locate your CE server executable:

@2,079,461us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR: cannot access file ./decodeCombo.x64P

The server executable needs to be present in the same directory as your application (since you have "./" as the path).

For the future, probably a better place to go for support is the TI Forums.  Here's a link to the Embedded Software forum:
http://e2e.ti.com/support/embedded/default.aspx
Your query of this sort would belong in either the Linux forum or the Multimedia Software Codecs forum.

Regards,

- Rob

________________________________
From: Aditya Barawkar [mailto:adityabarawkar at gmail.com]
Sent: Thursday, February 03, 2011 9:50 PM
To: Tivy, Robert
Cc: davinci-linux-open-source at linux.davincidsp.com
Subject: Re: Error While Running Demos

Ignore all the previous logs....just see the log.txt file attached..
sorry for the  inconvineince...

On Fri, Feb 4, 2011 at 10:41 AM, Aditya Barawkar <adityabarawkar at gmail.com<mailto:adityabarawkar at gmail.com>> wrote:
Sorry log in last mail was without inserting two modules cmemk.ko & dsplinkk.ko

This log was generated after inserting above two modules.

Thanks.


Decode demo started.
@0,448,089us: [+4 T:0x40018528 S:0xbefff8cc] OG - Global_init> This program was built with the following packages:
@0,448,733us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package gnu.targets.rts470MV (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/gnu/targets/rts470MV/) [1,0,0,0,1193542866293]
@0,448,978us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.g711dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/) [1,0,0,1210922571648]
@0,449,140us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.aachedec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/) [1,0,0,1210922563756]
@0,449,289us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mp3dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/) [1,0,0,1210922592446]
@0,449,433us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.h264dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/) [1,0,0,1210922581723]
@0,449,624us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mpeg2dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/) [1,0,0,1210922600503]
@0,449,773us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mpeg4dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/) [1,0,0,1210922605176]
@0,449,914us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais.dm<http://ti.xdais.dm> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/dm/) [1,0,4,0]
@0,450,046us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/) [1,2,1,0]
@0,450,184us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.utils.trace (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/utils/trace/) [1,0,0,0]
@0,450,325us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.utils.xdm (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1200333457442]
@0,450,464us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package dsplink.gpp (/db/atree/library/trees/linuxdemos-a46x/imports/dsplink-dm644x-v140-05p1-prebuilt/packages/dsplink/gpp/) [1,1,0,0]
@0,450,607us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.linuxutils.cmem (/db/atree/library/trees/linuxdemos-a46x/imports/build/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/) [2,0,0,0]
@0,450,750us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.fc.acpy3 (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/acpy3/) [1,0,2,0]
@0,450,893us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.fc.dman3 (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/dman3/) [1,0,3,0]
@0,451,035us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.osal (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/osal/) [2,0,1,1200333329943]
@0,451,178us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.alg (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/alg/) [1,0,0,1200332939285]
@0,451,317us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.catalog.c470 (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/catalog/c470/) [1,0,1,0,1192229332845]
@0,451,458us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.platforms.evmDM6446 (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
@0,451,599us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/) [1,0,5,1200332924185]
@0,452,339us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.speech (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/speech/) [1,0,1,1200333353059]
@0,452,548us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.g711dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/ce/) [1,0,0,1210922072831]
@0,452,703us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.audio (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/audio/) [1,0,1,1200332949776]
@0,452,849us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.aachedec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/ce/) [1,0,0,1210922061774]
@0,452,999us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mp3dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/ce/) [1,0,0,1210922155277]
@0,453,146us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.video (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/video/) [1,0,2,1200333474655]
@0,453,291us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.h264dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/ce/) [1,0,0,1210922114696]
@0,453,437us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mpeg2dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/ce/) [1,0,0,1210922171166]
@0,453,584us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mpeg4dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/ce/) [1,0,0,1210922199273]
@0,453,731us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.bioslog (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/bioslog/) [1,0,1,1200332966901]
@0,453,873us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.utils.trace (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/trace/) [1,0,1,1200333448031]
@0,454,016us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package decode_config (/db/atree/library/trees/linuxdemos-a46x/imports/build/demos/dm6446/decode/decode_config/) []
@0,454,198us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x1d148)
@0,454,354us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c41534f]
@0,454,700us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x0]
@0,456,366us: [+7 T:0x40018528 S:0xbefff8d4] OM - Memory_init> ERROR: Failed to initialize CMEM
@0,456,616us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter (fxn=0x1b258)
@0,456,905us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter (fxn=0x1d618)
@0,457,251us: [+0 T:0x40018528 S:0xbefff8cc] OG - Global_atexit> enter (fxn=0x1c0e8)
@0,457,710us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Enter (fxn=0x1e9fc, attrs=0x0)
@0,458,813us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Exit (task=0x48180)
@0,459,038us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x1e59c)
@0,459,390us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x1a028)
@0,459,636us: [+2 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.alg - ALG_init> Enter
@0,459,796us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415351 count: 1
@0,459,964us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,460,153us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x8001]
@0,461,093us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x10002 refCount: 1
@0,461,328us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x8001]
@0,461,513us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,461,665us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482d8]
@0,461,817us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415352 count: 1
@0,461,993us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,462,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x18001]
@0,462,507us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x20003 refCount: 1
@0,462,689us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x18001]
@0,462,859us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,463,008us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482e8]
@0,463,164us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415353 count: 1
@0,463,334us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,463,519us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x28001]
@0,463,767us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x30004 refCount: 1
@0,463,943us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x28001]
@0,464,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,464,254us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482f8]
@0,464,405us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415354 count: 1
@0,464,577us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,464,764us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x38001]
@0,465,017us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x40005 refCount: 1
@0,465,199us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x38001]
@0,465,372us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,465,523us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48308]
@0,465,671us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415355 count: 1
@0,465,837us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,466,012us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x48001]
@0,466,296us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x50006 refCount: 1
@0,466,475us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x48001]
@0,466,645us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,466,786us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48318]
@0,466,932us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415356 count: 1
@0,467,096us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,467,284us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x58001]
@0,467,656us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x60007 refCount: 1
@0,467,857us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x58001]
@0,468,034us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,468,182us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48328]
@0,468,334us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415357 count: 1
@0,468,507us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,159,411us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x68001]
@1,159,729us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x70008 refCount: 1
@1,159,915us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x68001]
@1,160,092us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,160,248us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48338]
@1,160,403us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415358 count: 1
@1,160,620us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,160,823us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x78001]
@1,161,084us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x80009 refCount: 1
@1,161,272us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x78001]
@1,161,447us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,161,598us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48348]
@1,161,749us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415359 count: 1
@1,161,919us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,162,157us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x88001]
@1,162,414us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x9000a refCount: 1
@1,162,597us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x88001]
@1,162,770us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,162,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48358]
@1,163,067us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535a count: 1
@1,163,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,163,459us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x98001]
@1,163,727us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa000b refCount: 1
@1,163,907us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x98001]
@1,164,077us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,164,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48368]
@1,164,383us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535b count: 1
@1,164,548us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,164,736us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa8001]
@1,165,047us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xb000c refCount: 1
@1,165,237us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa8001]
@1,165,411us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,165,557us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48378]
@1,165,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535c count: 1
@1,165,875us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,166,063us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb8001]
@1,166,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xc000d refCount: 1
@1,166,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb8001]
@1,166,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,166,852us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48388]
@1,167,043us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535d count: 1
@1,167,682us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,167,938us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xc8001]
@1,168,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xd000e refCount: 1
@1,168,418us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xc8001]
@1,168,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,168,745us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48398]
@1,168,893us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535e count: 1
@1,169,102us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,169,308us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xd8001]
@1,169,575us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xe000f refCount: 1
@1,169,752us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xd8001]
@1,169,923us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,170,069us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483a8]
@1,170,222us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535f count: 1
@1,170,392us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,170,624us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xe8001]
@1,170,896us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xf0010 refCount: 1
@1,171,076us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xe8001]
@1,171,253us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,171,404us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483b8]
@1,171,553us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415360 count: 1
@1,171,720us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,171,908us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xf8001]
@1,172,212us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x100011 refCount: 1
@1,172,397us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xf8001]
@1,172,572us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,172,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483c8]
@1,172,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415361 count: 1
@1,173,034us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,173,224us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x108001]
@1,173,525us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x110012 refCount: 1
@1,173,712us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x108001]
@1,173,889us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,174,040us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483d8]
@1,174,195us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415362 count: 1
@1,174,366us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,174,554us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x118001]
@1,174,848us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x120013 refCount: 1
@1,175,035us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x118001]
@1,175,211us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,175,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483e8]
@1,175,795us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415363 count: 1
@1,865,769us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,866,065us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x128001]
@1,866,417us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x130014 refCount: 1
@1,866,616us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x128001]
@1,866,798us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,866,947us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483f8]
@1,867,097us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415364 count: 1
@1,867,264us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,867,640us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread created.
@1,868,071us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x138001]
@1,868,391us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x140015 refCount: 1
@1,868,581us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x138001]
@1,868,757us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,868,958us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48408]
@1,869,120us: [+0 T:0x40018528 S:0xbefff8b4] OG - Global_atexit> enter (fxn=0x19810)
@1,869,284us: [+2 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.alg - ALG_init> Exit
@1,869,436us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x19330)
@1,869,632us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x1c238)
@1,869,905us: [+6 T:0x40018528 S:0xbefff8d4] CE - Engine_init> CE debugging on (CE_DEBUG=3; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
@1,870,088us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter (fxn=0x16d58)
@1,870,444us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x15c00)
@1,870,805us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x12d38)
@1,871,014us: [+0 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x0]
@1,871,205us: [+0 T:0x40018528 S:0xbefff8f4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not active (unset CE_DEBUG if you need TraceUtil)
@1,880,635us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@1,880,944us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@1,881,119us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@1,881,512us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x412cb000) = 0x0.
@1,881,892us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x0)
@1,889,122us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@1,889,346us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@1,889,514us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@1,889,826us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41373c00) = 0x0.
@1,890,130us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x0)
@1,897,283us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@1,897,567us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@1,897,756us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@1,898,071us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x4141c800) = 0x0.
@1,898,385us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x0)
@1,905,591us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> Enter('decode', 0x0, 0xbefff634)
@1,905,923us: [+0 T:0x40018528 S:0xbefff5ec] CE - rserverOpen('./decodeCombo.x64P'), count = 0
@1,906,118us: [+0 T:0x40018528 S:0xbefff56c] OP - Process_create> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0xbefff638)
@1,907,328us: [+7 T:0x40018528 S:0xbefff56c] OP - Process_create> ERROR: cannot access file ./decodeCombo.x64P
@1,907,698us: [+6 T:0x40018528 S:0xbefff5ec] CE - rserverOpen: can't start './decodeCombo.x64P'; Process_create failed
@1,907,884us: [+0 T:0x40018528 S:0xbefff5ec] CE - rserverOpen('./decodeCombo.x64P'): 0x0 done.
@1,908,051us: [+0 T:0x40018528 S:0xbefff5cc] CE - Engine_close(0x485d8)
@1,908,313us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> return(0)
@2,071,878us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> Enter('decode', 0x0, 0x41cc5494)
@2,072,296us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen('./decodeCombo.x64P'), count = 0
@2,072,500us: [+0 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0x41cc5498)
@2,072,781us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR: cannot access file ./decodeCombo.x64P
@2,072,973us: [+6 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen: can't start './decodeCombo.x64P'; Process_create failed
@2,073,151us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen('./decodeCombo.x64P'): 0x0 done.
@2,073,327us: [+0 T:0x41cc5b60 S:0x41cc542c] CE - Engine_close(0x485d8)
@2,073,514us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> return(0)
@2,607,774us: [+0 T:0x40018528 S:0xbefff8dc] OG - Global_exit> enter
@2,607,990us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x12d38()...
@2,608,198us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x15c00()...
@2,608,412us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x16d58()...
@2,608,592us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1c238()...
@2,608,747us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x19330()...
@2,608,901us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482d8]
@2,609,055us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,609,251us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x148000]
@2,609,437us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x10002, ref count: 1
@2,609,672us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x10002
@2,609,889us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x148000]
@2,610,071us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,610,229us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,610,375us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482e8]
@2,610,527us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,610,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x150000]
@2,610,886us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x20003, ref count: 1
@2,611,111us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x20003
@2,611,321us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x150000]
@2,611,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,611,651us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,611,792us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482f8]
@2,611,942us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,612,121us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x158000]
@2,612,294us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x30004, ref count: 1
@2,612,513us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x30004
@2,613,356us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x158000]
@2,613,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,613,766us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,613,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48308]
@2,614,109us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,614,312us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x160000]
@2,614,491us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x40005, ref count: 1
@2,614,716us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x40005
@2,614,886us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x160000]
@2,615,055us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,615,207us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,615,351us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48318]
@2,615,542us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,615,733us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x168000]
@2,615,908us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x50006, ref count: 1
@2,616,130us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x50006
@2,616,300us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x168000]
@2,616,471us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,616,624us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,616,771us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48328]
@2,616,961us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,617,148us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x170000]
@2,617,330us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x60007, ref count: 1
@2,617,685us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x60007
@2,617,883us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x170000]
@2,618,052us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,618,206us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,618,407us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48338]
@2,618,563us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,618,746us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x178000]
@2,618,918us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x70008, ref count: 1
@2,619,131us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x70008
@2,619,298us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x178000]
@2,619,469us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,619,623us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,619,800us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48348]
@2,619,959us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,620,140us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x180000]
@2,620,319us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x80009, ref count: 1
@2,620,537us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x80009
@2,620,704us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x180000]
@2,621,138us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,621,389us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,621,548us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48358]
@2,621,707us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,621,896us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x188000]
@2,622,073us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x9000a, ref count: 1
@2,622,304us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x9000a
@2,622,480us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x188000]
@2,622,689us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,622,850us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,622,996us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48368]
@2,623,147us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,623,329us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x190000]
@2,623,508us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa000b, ref count: 1
@2,623,725us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa000b
@2,623,892us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x190000]
@2,624,102us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,624,262us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,624,406us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48378]
@2,624,559us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,624,737us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x198000]
@2,624,915us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xb000c, ref count: 1
@2,625,135us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xb000c
@2,625,306us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x198000]
@2,625,515us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,625,676us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,625,820us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48388]
@2,625,969us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,626,146us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1a0000]
@2,626,322us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xc000d, ref count: 1
@2,626,538us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xc000d
@2,626,705us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1a0000]
@2,626,907us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,627,066us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,627,217us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48398]
@2,627,368us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,627,676us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1a8000]
@2,627,878us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xd000e, ref count: 1
@2,628,102us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xd000e
@2,628,305us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1a8000]
@2,628,494us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,628,649us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,628,974us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483a8]
@3,318,647us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,318,886us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1b0000]
@3,319,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xe000f, ref count: 1
@3,319,345us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xe000f
@3,319,557us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1b0000]
@3,319,736us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,319,887us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,320,029us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483b8]
@3,320,181us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,320,362us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1b8000]
@3,320,535us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xf0010, ref count: 1
@3,320,750us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xf0010
@3,320,960us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1b8000]
@3,321,140us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,321,291us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,321,439us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483c8]
@3,321,592us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,321,767us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1c0000]
@3,321,942us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x100011, ref count: 1
@3,322,156us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x100011
@3,322,359us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1c0000]
@3,322,540us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,322,696us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,322,841us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483d8]
@3,322,988us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,323,166us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1c8000]
@3,323,340us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x110012, ref count: 1
@3,323,552us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x110012
@3,323,718us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1c8000]
@3,323,930us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,324,083us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,324,234us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483e8]
@3,324,384us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,324,561us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1d0000]
@3,324,740us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x120013, ref count: 1
@3,324,958us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x120013
@3,325,128us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1d0000]
@3,325,344us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,325,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,325,646us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483f8]
@3,325,794us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,326,227us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1d8000]
@3,326,463us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x130014, ref count: 1
@3,326,745us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x130014
@3,326,928us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1d8000]
@3,327,103us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,327,263us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,327,408us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48408]
@3,327,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,327,910us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1e0000]
@3,328,137us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x140015, ref count: 1
@3,328,371us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x140015
@3,328,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1e0000]
@3,328,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,328,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,329,017us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x19810()...
@3,329,177us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1a028()...
@3,329,327us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1e59c()...
@3,329,743us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread terminating
@3,330,253us: [+0 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> Enter (task=0x48180)
@3,330,566us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> pthread_cancel (0x3)
@3,330,761us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> pthread_join (0x0)
@3,330,979us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_delete> Exit (task=0x48180)
@3,331,149us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1c0e8()...
@3,331,371us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1d618()...
@3,331,549us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1b258()...
@3,331,708us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1d148()...
@3,331,862us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1c45c()...



On Fri, Feb 4, 2011 at 10:34 AM, Aditya Barawkar <adityabarawkar at gmail.com<mailto:adityabarawkar at gmail.com>> wrote:

Thanks for looking into problem.

here is the log with CE_DEBUG=3





Decode demo started.
@0,448,089us: [+4 T:0x40018528 S:0xbefff8cc] OG - Global_init> This program was built with the following packages:
@0,448,733us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package gnu.targets.rts470MV (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/gnu/targets/rts470MV/) [1,0,0,0,1193542866293]
@0,448,978us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.g711dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/) [1,0,0,1210922571648]
@0,449,140us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.aachedec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/) [1,0,0,1210922563756]
@0,449,289us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mp3dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/) [1,0,0,1210922592446]
@0,449,433us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.h264dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/) [1,0,0,1210922581723]
@0,449,624us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mpeg2dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/) [1,0,0,1210922600503]
@0,449,773us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mpeg4dec (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/) [1,0,0,1210922605176]
@0,449,914us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais.dm<http://ti.xdais.dm> (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/dm/) [1,0,4,0]
@0,450,046us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.xdais (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/xdais_6_00_01/packages/ti/xdais/) [1,2,1,0]
@0,450,184us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.utils.trace (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/utils/trace/) [1,0,0,0]
@0,450,325us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.utils.xdm (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/xdm/) [1,0,1,1200333457442]
@0,450,464us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package dsplink.gpp (/db/atree/library/trees/linuxdemos-a46x/imports/dsplink-dm644x-v140-05p1-prebuilt/packages/dsplink/gpp/) [1,1,0,0]
@0,450,607us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.linuxutils.cmem (/db/atree/library/trees/linuxdemos-a46x/imports/build/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/) [2,0,0,0]
@0,450,750us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.fc.acpy3 (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/acpy3/) [1,0,2,0]
@0,450,893us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.fc.dman3 (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/framework_components_2_00_01/packages/ti/sdo/fc/dman3/) [1,0,3,0]
@0,451,035us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.osal (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/osal/) [2,0,1,1200333329943]
@0,451,178us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.alg (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/alg/) [1,0,0,1200332939285]
@0,451,317us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.catalog.c470 (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/catalog/c470/) [1,0,1,0,1192229332845]
@0,451,458us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.platforms.evmDM6446 (/db/rtree/install/trees/products/xdcprod-h14/product/Linux/xdc_3_00_02/packages/ti/platforms/evmDM6446/) [1,0,0,1,1192229600615]
@0,451,599us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/) [1,0,5,1200332924185]
@0,452,339us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.speech (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/speech/) [1,0,1,1200333353059]
@0,452,548us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.g711dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/g711dec/ce/) [1,0,0,1210922072831]
@0,452,703us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.audio (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/audio/) [1,0,1,1200332949776]
@0,452,849us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.aachedec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/aachedec/ce/) [1,0,0,1210922061774]
@0,452,999us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mp3dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mp3dec/ce/) [1,0,0,1210922155277]
@0,453,146us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.video (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/video/) [1,0,2,1200333474655]
@0,453,291us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.h264dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/h264dec/ce/) [1,0,0,1210922114696]
@0,453,437us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mpeg2dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg2dec/ce/) [1,0,0,1210922171166]
@0,453,584us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.codecs.mpeg4dec.ce (/db/atree/library/trees/linuxdemos-a46x/imports/build/dm6446_dvsdk_combos_1_35/packages-production/ti/sdo/codecs/mpeg4dec/ce/) [1,0,0,1210922199273]
@0,453,731us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.bioslog (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/bioslog/) [1,0,1,1200332966901]
@0,453,873us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package ti.sdo.ce.utils.trace (/db/atree/library/trees/linuxdemos-a46x/imports/MFP20/codec_engine_2_00_01/packages/ti/sdo/ce/utils/trace/) [1,0,1,1200333448031]
@0,454,016us: [+4 T:0x40018528 S:0xbefff8cc] OG -     package decode_config (/db/atree/library/trees/linuxdemos-a46x/imports/build/demos/dm6446/decode/decode_config/) []
@0,454,198us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x1d148)
@0,454,354us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c41534f]
@0,454,700us: [+0 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x0]
@0,456,366us: [+7 T:0x40018528 S:0xbefff8d4] OM - Memory_init> ERROR: Failed to initialize CMEM
@0,456,616us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter (fxn=0x1b258)
@0,456,905us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter (fxn=0x1d618)
@0,457,251us: [+0 T:0x40018528 S:0xbefff8cc] OG - Global_atexit> enter (fxn=0x1c0e8)
@0,457,710us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Enter (fxn=0x1e9fc, attrs=0x0)
@0,458,813us: [+0 T:0x40018528 S:0xbefff8a4] OT - Thread_create> Exit (task=0x48180)
@0,459,038us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x1e59c)
@0,459,390us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x1a028)
@0,459,636us: [+2 T:0x40018528 S:0xbefff8c4] ti.sdo.ce.osal.alg - ALG_init> Enter
@0,459,796us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415351 count: 1
@0,459,964us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,460,153us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x8001]
@0,461,093us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x10002 refCount: 1
@0,461,328us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x8001]
@0,461,513us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,461,665us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482d8]
@0,461,817us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415352 count: 1
@0,461,993us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,462,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x18001]
@0,462,507us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x20003 refCount: 1
@0,462,689us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x18001]
@0,462,859us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,463,008us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482e8]
@0,463,164us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415353 count: 1
@0,463,334us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,463,519us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x28001]
@0,463,767us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x30004 refCount: 1
@0,463,943us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x28001]
@0,464,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,464,254us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x482f8]
@0,464,405us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415354 count: 1
@0,464,577us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,464,764us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x38001]
@0,465,017us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x40005 refCount: 1
@0,465,199us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x38001]
@0,465,372us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,465,523us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48308]
@0,465,671us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415355 count: 1
@0,465,837us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,466,012us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x48001]
@0,466,296us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x50006 refCount: 1
@0,466,475us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x48001]
@0,466,645us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,466,786us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48318]
@0,466,932us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415356 count: 1
@0,467,096us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@0,467,284us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x58001]
@0,467,656us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x60007 refCount: 1
@0,467,857us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x58001]
@0,468,034us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@0,468,182us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48328]
@0,468,334us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415357 count: 1
@0,468,507us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,159,411us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x68001]
@1,159,729us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x70008 refCount: 1
@1,159,915us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x68001]
@1,160,092us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,160,248us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48338]
@1,160,403us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415358 count: 1
@1,160,620us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,160,823us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x78001]
@1,161,084us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x80009 refCount: 1
@1,161,272us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x78001]
@1,161,447us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,161,598us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48348]
@1,161,749us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415359 count: 1
@1,161,919us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,162,157us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x88001]
@1,162,414us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x9000a refCount: 1
@1,162,597us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x88001]
@1,162,770us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,162,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48358]
@1,163,067us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535a count: 1
@1,163,238us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,163,459us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x98001]
@1,163,727us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xa000b refCount: 1
@1,163,907us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x98001]
@1,164,077us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,164,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48368]
@1,164,383us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535b count: 1
@1,164,548us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,164,736us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xa8001]
@1,165,047us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xb000c refCount: 1
@1,165,237us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xa8001]
@1,165,411us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,165,557us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48378]
@1,165,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535c count: 1
@1,165,875us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,166,063us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xb8001]
@1,166,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xc000d refCount: 1
@1,166,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xb8001]
@1,166,708us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,166,852us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48388]
@1,167,043us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535d count: 1
@1,167,682us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,167,938us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xc8001]
@1,168,226us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xd000e refCount: 1
@1,168,418us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xc8001]
@1,168,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,168,745us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48398]
@1,168,893us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535e count: 1
@1,169,102us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,169,308us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xd8001]
@1,169,575us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xe000f refCount: 1
@1,169,752us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xd8001]
@1,169,923us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,170,069us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483a8]
@1,170,222us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c41535f count: 1
@1,170,392us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,170,624us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xe8001]
@1,170,896us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0xf0010 refCount: 1
@1,171,076us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xe8001]
@1,171,253us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,171,404us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483b8]
@1,171,553us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415360 count: 1
@1,171,720us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,171,908us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0xf8001]
@1,172,212us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x100011 refCount: 1
@1,172,397us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0xf8001]
@1,172,572us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,172,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483c8]
@1,172,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415361 count: 1
@1,173,034us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,173,224us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x108001]
@1,173,525us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x110012 refCount: 1
@1,173,712us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x108001]
@1,173,889us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,174,040us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483d8]
@1,174,195us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415362 count: 1
@1,174,366us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,174,554us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x118001]
@1,174,848us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x120013 refCount: 1
@1,175,035us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x118001]
@1,175,211us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,175,362us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483e8]
@1,175,795us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415363 count: 1
@1,865,769us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,866,065us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x128001]
@1,866,417us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x130014 refCount: 1
@1,866,616us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x128001]
@1,866,798us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,866,947us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x483f8]
@1,867,097us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> key: 0x4c415364 count: 1
@1,867,264us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@1,867,640us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread created.
@1,868,071us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x138001]
@1,868,391us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_create> semId: 0x140015 refCount: 1
@1,868,581us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x138001]
@1,868,757us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@1,868,958us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_create> sem[0x48408]
@1,869,120us: [+0 T:0x40018528 S:0xbefff8b4] OG - Global_atexit> enter (fxn=0x19810)
@1,869,284us: [+2 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.alg - ALG_init> Exit
@1,869,436us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x19330)
@1,869,632us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x1c238)
@1,869,905us: [+6 T:0x40018528 S:0xbefff8d4] CE - Engine_init> CE debugging on (CE_DEBUG=3; allowed CE_DEBUG levels: 1=min, 2=good, 3=max)
@1,870,088us: [+0 T:0x40018528 S:0xbefff8c4] OG - Global_atexit> enter (fxn=0x16d58)
@1,870,444us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x15c00)
@1,870,805us: [+0 T:0x40018528 S:0xbefff8d4] OG - Global_atexit> enter (fxn=0x12d38)
@1,871,014us: [+0 T:0x40018528 S:0xbefff8dc] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x0]
@1,871,205us: [+0 T:0x40018528 S:0xbefff8f4] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
TraceUtil_start> note: CE_DEBUG env. var is set, so TraceUtil is not active (unset CE_DEBUG if you need TraceUtil)
@1,880,635us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@1,880,944us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x412cb000, size=4)
@1,881,119us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@1,881,512us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x412cb000) = 0x0.
@1,881,892us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x0)
@1,889,122us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@1,889,346us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x41373c00, size=4)
@1,889,514us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@1,889,826us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41373c00) = 0x0.
@1,890,130us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x0)
@1,897,283us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@1,897,567us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x4141c800, size=4)
@1,897,756us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@1,898,071us: [+1 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x4141c800) = 0x0.
@1,898,385us: [+0 T:0x412cab60 S:0x412ca27c] OM - Memory_getBufferPhysicalAddress> return (0x0)
@1,905,591us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> Enter('decode', 0x0, 0xbefff634)
@1,905,923us: [+0 T:0x40018528 S:0xbefff5ec] CE - rserverOpen('./decodeCombo.x64P'), count = 0
@1,906,118us: [+0 T:0x40018528 S:0xbefff56c] OP - Process_create> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0xbefff638)
@1,907,328us: [+7 T:0x40018528 S:0xbefff56c] OP - Process_create> ERROR: cannot access file ./decodeCombo.x64P
@1,907,698us: [+6 T:0x40018528 S:0xbefff5ec] CE - rserverOpen: can't start './decodeCombo.x64P'; Process_create failed
@1,907,884us: [+0 T:0x40018528 S:0xbefff5ec] CE - rserverOpen('./decodeCombo.x64P'): 0x0 done.
@1,908,051us: [+0 T:0x40018528 S:0xbefff5cc] CE - Engine_close(0x485d8)
@1,908,313us: [+0 T:0x40018528 S:0xbefff5ec] CE - Engine_open> return(0)
@2,071,878us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> Enter('decode', 0x0, 0x41cc5494)
@2,072,296us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen('./decodeCombo.x64P'), count = 0
@2,072,500us: [+0 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> Enter(imageName='./decodeCombo.x64P', linkCfg='(null)', attrs=0x41cc5498)
@2,072,781us: [+7 T:0x41cc5b60 S:0x41cc53cc] OP - Process_create> ERROR: cannot access file ./decodeCombo.x64P
@2,072,973us: [+6 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen: can't start './decodeCombo.x64P'; Process_create failed
@2,073,151us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - rserverOpen('./decodeCombo.x64P'): 0x0 done.
@2,073,327us: [+0 T:0x41cc5b60 S:0x41cc542c] CE - Engine_close(0x485d8)
@2,073,514us: [+0 T:0x41cc5b60 S:0x41cc544c] CE - Engine_open> return(0)
@2,607,774us: [+0 T:0x40018528 S:0xbefff8dc] OG - Global_exit> enter
@2,607,990us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x12d38()...
@2,608,198us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x15c00()...
@2,608,412us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x16d58()...
@2,608,592us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1c238()...
@2,608,747us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x19330()...
@2,608,901us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482d8]
@2,609,055us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,609,251us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x148000]
@2,609,437us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x10002, ref count: 1
@2,609,672us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x10002
@2,609,889us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x148000]
@2,610,071us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,610,229us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,610,375us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482e8]
@2,610,527us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,610,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x150000]
@2,610,886us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x20003, ref count: 1
@2,611,111us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x20003
@2,611,321us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x150000]
@2,611,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,611,651us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,611,792us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x482f8]
@2,611,942us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,612,121us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x158000]
@2,612,294us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x30004, ref count: 1
@2,612,513us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x30004
@2,613,356us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x158000]
@2,613,597us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,613,766us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,613,914us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48308]
@2,614,109us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,614,312us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x160000]
@2,614,491us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x40005, ref count: 1
@2,614,716us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x40005
@2,614,886us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x160000]
@2,615,055us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,615,207us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,615,351us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48318]
@2,615,542us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,615,733us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x168000]
@2,615,908us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x50006, ref count: 1
@2,616,130us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x50006
@2,616,300us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x168000]
@2,616,471us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,616,624us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,616,771us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48328]
@2,616,961us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,617,148us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x170000]
@2,617,330us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x60007, ref count: 1
@2,617,685us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x60007
@2,617,883us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x170000]
@2,618,052us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,618,206us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,618,407us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48338]
@2,618,563us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,618,746us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x178000]
@2,618,918us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x70008, ref count: 1
@2,619,131us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x70008
@2,619,298us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x178000]
@2,619,469us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,619,623us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,619,800us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48348]
@2,619,959us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,620,140us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x180000]
@2,620,319us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x80009, ref count: 1
@2,620,537us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x80009
@2,620,704us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x180000]
@2,621,138us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,621,389us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,621,548us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48358]
@2,621,707us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,621,896us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x188000]
@2,622,073us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x9000a, ref count: 1
@2,622,304us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x9000a
@2,622,480us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x188000]
@2,622,689us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,622,850us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,622,996us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48368]
@2,623,147us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,623,329us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x190000]
@2,623,508us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xa000b, ref count: 1
@2,623,725us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xa000b
@2,623,892us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x190000]
@2,624,102us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,624,262us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,624,406us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48378]
@2,624,559us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,624,737us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x198000]
@2,624,915us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xb000c, ref count: 1
@2,625,135us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xb000c
@2,625,306us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x198000]
@2,625,515us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,625,676us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,625,820us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48388]
@2,625,969us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,626,146us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1a0000]
@2,626,322us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xc000d, ref count: 1
@2,626,538us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xc000d
@2,626,705us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1a0000]
@2,626,907us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,627,066us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,627,217us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48398]
@2,627,368us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@2,627,676us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1a8000]
@2,627,878us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xd000e, ref count: 1
@2,628,102us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xd000e
@2,628,305us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1a8000]
@2,628,494us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@2,628,649us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@2,628,974us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483a8]
@3,318,647us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,318,886us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1b0000]
@3,319,110us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xe000f, ref count: 1
@3,319,345us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xe000f
@3,319,557us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1b0000]
@3,319,736us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,319,887us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,320,029us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483b8]
@3,320,181us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,320,362us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1b8000]
@3,320,535us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0xf0010, ref count: 1
@3,320,750us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0xf0010
@3,320,960us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1b8000]
@3,321,140us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,321,291us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,321,439us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483c8]
@3,321,592us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,321,767us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1c0000]
@3,321,942us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x100011, ref count: 1
@3,322,156us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x100011
@3,322,359us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1c0000]
@3,322,540us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,322,696us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,322,841us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483d8]
@3,322,988us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,323,166us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1c8000]
@3,323,340us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x110012, ref count: 1
@3,323,552us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x110012
@3,323,718us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1c8000]
@3,323,930us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,324,083us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,324,234us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483e8]
@3,324,384us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,324,561us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1d0000]
@3,324,740us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x120013, ref count: 1
@3,324,958us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x120013
@3,325,128us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1d0000]
@3,325,344us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,325,500us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,325,646us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x483f8]
@3,325,794us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,326,227us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1d8000]
@3,326,463us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x130014, ref count: 1
@3,326,745us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x130014
@3,326,928us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1d8000]
@3,327,103us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,327,263us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,327,408us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Entered Sem_delete> sem[0x48408]
@3,327,711us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Entered Sem_enterCS> key[0x4c415350]
@3,327,910us: [+0 T:0x40018528 S:0xbefff864] ti.sdo.ce.osal.Sem - Leaving Sem_enterCS> id[0x1e0000]
@3,328,137us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> sem: 0x140015, ref count: 1
@3,328,371us: [+1 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Sem_delete> Deleted semaphore: 0x140015
@3,328,540us: [+0 T:0x40018528 S:0xbefff86c] ti.sdo.ce.osal.Sem - Entered Sem_exitCS> id[0x1e0000]
@3,328,716us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_exitCS
@3,328,868us: [+0 T:0x40018528 S:0xbefff884] ti.sdo.ce.osal.Sem - Leaving Sem_delete>
@3,329,017us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x19810()...
@3,329,177us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1a028()...
@3,329,327us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1e59c()...
@3,329,743us: [+1 T:0x40acab60 S:0x40aca524] OP - daemon> thread terminating
@3,330,253us: [+0 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> Enter (task=0x48180)
@3,330,566us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> pthread_cancel (0x3)
@3,330,761us: [+4 T:0x40018528 S:0xbefff8ac] OT - Thread_delete> pthread_join (0x0)
@3,330,979us: [+0 T:0x40018528 S:0xbefff8c4] OT - Thread_delete> Exit (task=0x48180)
@3,331,149us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1c0e8()...
@3,331,371us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1d618()...
@3,331,549us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1b258()...
@3,331,708us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1d148()...
@3,331,862us: [+2 T:0x40018528 S:0xbefff8dc] OG - Global_exit> calling function *0x1c45c()...










On Fri, Feb 4, 2011 at 3:01 AM, Tivy, Robert <rtivy at ti.com<mailto:rtivy at ti.com>> wrote:
More details about the failure to open the codec engine are needed.  You can generate more info by setting the environment variable CE_DEBUG=3 and re-running your app:
    % export CE_DEBUG=3
    % ./decode ...

Regards,

- Rob

________________________________
From: davinci-linux-open-source-bounces+rtivy=ti.com<http://ti.com>@linux.davincidsp.com<http://linux.davincidsp.com> [mailto:davinci-linux-open-source-bounces+rtivy<mailto:davinci-linux-open-source-bounces%2Brtivy>=ti.com<http://ti.com>@linux.davincidsp.com<http://linux.davincidsp.com>] On Behalf Of Aditya Barawkar
Sent: Thursday, February 03, 2011 11:56 AM
To: davinci-linux-open-source at linux.davincidsp.com<mailto:davinci-linux-open-source at linux.davincidsp.com>
Subject: Error While Running Demos

I'm trying to run demos for encode decode which came with DVSDK v1.30.01 for DM6446 EVM

When i boot the board then I'm not seeing any demos which should run automatically as per the TI doc.

So i opted to run the demos using command line.

First i loaded all the modules which are required to run the demos
Modules loaded :: cmemk.ko and dsplinkk.ko

root at 10.42.43.10:/opt/demos/dm6446/decode/release# lsmod
Module                  Size  Used by
cmemk                  17368  0
dsplinkk               96360  0

But when i excute command to run the demo ::: ./decode -v /opt/demos/dm6446/data/videos/davincieffect_ntsc.m2v -k
i get following error::


Decode demo started.
TraceUtil> Error: Failed to open codec engine "decode"
TraceUtil> Error: Aborting TraceUtil_start
Decode Error: Failed to open codec engine decode
Decode Error: Failed to open codec engine decode
root at 10.42.43.10:/opt/demos/dm6446/decode/release#

Please help me out on how to make the sample demos run.

Thanks in advance.!




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

From will.kelleher at nuvixa.com  Fri Feb  4 14:30:09 2011
From: will.kelleher at nuvixa.com (Will Kelleher)
Date: Fri, 4 Feb 2011 14:30:09 -0600
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTinSQjic73tNsd54o_h=8scjtbkf4XC==sCHMs5E@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B7C7@dbde02.ent.ti.com>
	<AANLkTik9MYm6pin4E=QvOnLh0uYf=USP1pUuS28SvLMk@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B867@dbde02.ent.ti.com>
	<AANLkTinSQjic73tNsd54o_h=8scjtbkf4XC==sCHMs5E@mail.gmail.com>
Message-ID: <AANLkTikBtBURWSv6M3kX8F_Rmr7uHOxRnAHSXwjKGvtA@mail.gmail.com>

Hi,

I also recently backported the UVC gadget (g_webcam) from 2.6.36 to
2.6.32.  Where did you encounter this error?  I'm able to load the
module and the DM365 is detected as a UVC device by a Windows host,
but then I am unable to add DirectShow filters to the device.  Perhaps
the root cause is similar?

Thanks,

Will Kelleher
Nuvixa, Inc.



On Fri, Feb 4, 2011 at 7:41 AM, jean-philippe francois
<jp.francois at cynove.com> wrote:
> 2011/2/4 B, Ravi <ravibabu at ti.com>:
>>
>>> >> Hi,
>>> >>
>>> >> I have backported the UVC gadget patch by laurent pinchart on a custom
>>> >> DM365 board.
>>> >> It fails to allocate the required endpoints :
>>> >>
>>> >> ? ? ? ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
>>> >> ? ? ? if (!ep) {
>>> >> ? ? ? ? ? ? ? INFO(cdev, "Unable to allocate streaming EP\n");
>>> >> ? ? ? ? ? ? ? goto error;
>>> >> ? ? ? }
>>> >>
>>> >> I can see the message "Unable to allocate streaming EP" in the log.
>>> >> How can I debug / fix this ?
>>> >>
>>> >> The mass storage gadget is working fine.
>>> >>
>>> >> Here is the failing endpoint descriptor :
>>> >>
>>> >> static struct usb_endpoint_descriptor uvc_streaming_ep = {
>>> >> ? ? ? .bLength ? ? ? ? ? ? ? ?= USB_DT_ENDPOINT_SIZE,
>>> >> ? ? ? .bDescriptorType ? ? ? ?= USB_DT_ENDPOINT,
>>> >> ? ? ? .bEndpointAddress ? ? ? = USB_DIR_IN,
>>> >> ? ? ? .bmAttributes ? ? ? ? ? = USB_ENDPOINT_XFER_ISOC,
>>> >> ? ? ? .wMaxPacketSize ? ? ? ? = cpu_to_le16(1024),
>>> >> ? ? ? .bInterval ? ? ? ? ? ? ?= 1,
>>> >> };
>>> >>
>>> >
>>> > The above endpoint requires endpoint fifo size to be 1024. Check with
>>> the fifo table entries in musb_core.c file and update as per requirement.
>>> >
>>>
>>> So I can either change the fifo_mode module paramete to pick another
>>> config, or
>>> change the endpoint config to use a smaller packet size ?
>>>
>>
>> If the UVC driver requirement may be 1024 bytes packet size, then you cannot change, what you can do is change the current fifo-mode
>> configuration sizes as per your device requirements.
>>
>> For example :
>> /* mode 4 - fits in 4KB */
>> static struct musb_fifo_cfg __devinitdata mode_4_cfg[] = {
>> { .hw_ep_num = ?1, .style = FIFO_TX, ? .maxpacket = 512, },
>> { .hw_ep_num = ?1, .style = FIFO_RX, ? .maxpacket = 512, },
>> { .hw_ep_num = ?2, .style = FIFO_TX, ? .maxpacket = 1024, },
>> { .hw_ep_num = ?2, .style = FIFO_RX, ? .maxpacket = 1024, },
>> { .hw_ep_num = ?3, .style = FIFO_TX, ? .maxpacket = 256, },
>> { .hw_ep_num = ?3, .style = FIFO_RX, ? .maxpacket = 256, },
>>
> Thank you, I can see that more recent kernel have the possibility
> to specify this config in platform_data, which is great !
>
>> Ravi
>>
>>> >> Jean-Philippe Fran?ois
>>> >> _______________________________________________
>>> >> 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
>

From will.kelleher at nuvixa.com  Fri Feb  4 14:36:12 2011
From: will.kelleher at nuvixa.com (Will Kelleher)
Date: Fri, 4 Feb 2011 14:36:12 -0600
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>
Message-ID: <AANLkTimxt6fJU29F38oKm+h6LfwTkfO=dPXv-jiVHgmP@mail.gmail.com>

Hello,

The staging tree that I recently pulled from Arago
(git://arago-project.org/git/projects/linux-davinci.git) is 2.6.32.17.
 If you're interested in the UVC gadget, you'll have to backport the
code, along with portions of V4L2 (or remove the dependency on this
from the UVC code).

Will Kelleher
Nuvixa, Inc.



On Thu, Feb 3, 2011 at 3:32 AM, jean-philippe francois
<jp.francois at cynove.com> wrote:
> 2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
>> Hi,
>>
>> What is the status of the arago staging tree ?
>> It once was tracking the mainline kernel without much lag, but
>> it seems to be stuck at 2.6.34
>>
>> I am interested in :
>> - video capture
> Both bayer and YUV, using USERPTR IO
>
>> - single-shot previewer operation
>> - cmem, edma and all other DVSDK modules can build against it
>> - video display (optional)
>> - OSD (optional)
>>
>> I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
>> or older kernel, because I am interested
>> in the uvc gadget driver.
>>
>> What tree could be a good starting point for this ?
>>
> _______________________________________________
> 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 michael.williamson at criticallink.com  Fri Feb  4 15:02:55 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Fri, 04 Feb 2011 16:02:55 -0500
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>
	<AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>
Message-ID: <4D4C697F.2080400@criticallink.com>

On 2/4/2011 12:15 PM, Steve Chen wrote:

> On Fri, Feb 4, 2011 at 10:52 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
>> Hi Steve,
>>
>> On Fri, Feb 04, 2011 at 21:42:41, Steve Chen wrote:
>>
>>>> rtcwake  -s 40 rtc0
>>> rtcwake: /dev/rtc not enabled for wakeup events
>>
>> I have a feeling rtcwake is looking at the wrong device
>> node. Can you try:
>>
>> $ rtcwake -d /dev/rtc0 -s 20 -m mem
>>
> 
> Doh!!.   Sekhar, you are right.  I did not include the "-d" flag.
> After passing the correct parameter to rtcwake, I'm able to wake up
> from sleep with NFS rootfs.  I'm running the kernel/filesystem from
> PSP 03.20.00.14.
> 


I was wondering if you (or anyone) have numbers for how much power the
AM1808 you have is drawing while sleeping?  I was able to run the same 
command as above with an AM1808 module here today, and the power draw 
I am seeing by the module was still pretty high.  About 1/2 normal
operation, but still pretty high.

Does sleeping to disk / MMC reduce the consumption?  Or are there other
tricks with the regulators (e.g., allowing them to actually be shut down
with the constraints flags) that need to be done?

Thanks for any clues.

-Mike

From schen at mvista.com  Fri Feb  4 15:36:20 2011
From: schen at mvista.com (Steve Chen)
Date: Fri, 4 Feb 2011 15:36:20 -0600
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <4D4C697F.2080400@criticallink.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>
	<AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>
	<4D4C697F.2080400@criticallink.com>
Message-ID: <AANLkTi=im=9p4LhcgS5nob5sXBmAsr7Dhf27yNRF1xbH@mail.gmail.com>

On Fri, Feb 4, 2011 at 3:02 PM, Michael Williamson
<michael.williamson at criticallink.com> wrote:
> On 2/4/2011 12:15 PM, Steve Chen wrote:
>
>> On Fri, Feb 4, 2011 at 10:52 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
>>> Hi Steve,
>>>
>>> On Fri, Feb 04, 2011 at 21:42:41, Steve Chen wrote:
>>>
>>>>> rtcwake ?-s 40 rtc0
>>>> rtcwake: /dev/rtc not enabled for wakeup events
>>>
>>> I have a feeling rtcwake is looking at the wrong device
>>> node. Can you try:
>>>
>>> $ rtcwake -d /dev/rtc0 -s 20 -m mem
>>>
>>
>> Doh!!. ? Sekhar, you are right. ?I did not include the "-d" flag.
>> After passing the correct parameter to rtcwake, I'm able to wake up
>> from sleep with NFS rootfs. ?I'm running the kernel/filesystem from
>> PSP 03.20.00.14.
>>
>
>
> I was wondering if you (or anyone) have numbers for how much power the
> AM1808 you have is drawing while sleeping? ?I was able to run the same
> command as above with an AM1808 module here today, and the power draw
> I am seeing by the module was still pretty high. ?About 1/2 normal
> operation, but still pretty high.
>
> Does sleeping to disk / MMC reduce the consumption? ?Or are there other
> tricks with the regulators (e.g., allowing them to actually be shut down
> with the constraints flags) that need to be done?
>
> Thanks for any clues.

Mike,

I have the Logic PD AM1808 EVM (I'm not sure if there are any others
out there).  Looking at the SOM-M1 schematic, power to AM1808 and DRAM
can be measured at u14 and u16 (pin 1 and 2).  With SoC frequency at
300MHz, it uses about 315mW (please note that I turned off audio,
video, SATA, and a few other controllers).  At suspend, AM1808 + DRAM
draws 27 mW.  I have not done anything other then the "echo mem..".

Also, if I measure the power on R84, I get roughly 45% power saving.

Regards,

Steve

From swapashtekar at gmail.com  Sat Feb  5 07:05:00 2011
From: swapashtekar at gmail.com (Swapnil Ashtekar)
Date: Sat, 5 Feb 2011 18:35:00 +0530
Subject: UART2 Error
Message-ID: <AANLkTikRFKdK_jm5PQ9ph0MSArfXc4izD6s+uVdagsRB@mail.gmail.com>

Hey,

        I am using DM6446, I want to transfer data using serial port, I
wrote simple code for it , used the appropriate register addresses,

but the binary of C code is not working on the environment of DM6446, it is
showing* error : segmentation fault*..

Is it because of  the inactivation of the uart2 ? The uart0 of the board is
being used for other purpose.

Can I have both UART enabled same time ?

What am I supposed to do ? I am a novice, please guide me.





Thank You in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110205/148eff1e/attachment.html>

From jp.francois at cynove.com  Mon Feb  7 02:33:21 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Mon, 7 Feb 2011 09:33:21 +0100
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTikBtBURWSv6M3kX8F_Rmr7uHOxRnAHSXwjKGvtA@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B7C7@dbde02.ent.ti.com>
	<AANLkTik9MYm6pin4E=QvOnLh0uYf=USP1pUuS28SvLMk@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B867@dbde02.ent.ti.com>
	<AANLkTinSQjic73tNsd54o_h=8scjtbkf4XC==sCHMs5E@mail.gmail.com>
	<AANLkTikBtBURWSv6M3kX8F_Rmr7uHOxRnAHSXwjKGvtA@mail.gmail.com>
Message-ID: <AANLkTim7qC-ha7OzRxb2XYVo-7-SE64yF7VqkqUR-5v5@mail.gmail.com>

2011/2/4 Will Kelleher <will.kelleher at nuvixa.com>:
> Hi,
>
> I also recently backported the UVC gadget (g_webcam) from 2.6.36 to
> 2.6.32. ?Where did you encounter this error?

The module loads fine, except for the following message in dmesg output
   INFO(cdev, "Unable to allocate streaming EP\n");

I had to set the wMawPacketSize to 512 in the following struct for the endpoint
allocation to work :

static struct usb_endpoint_descriptor uvc_streaming_ep = {
	.bLength		= USB_DT_ENDPOINT_SIZE,
	.bDescriptorType	= USB_DT_ENDPOINT,
	.bEndpointAddress	= USB_DIR_IN,
	.bmAttributes		= USB_ENDPOINT_XFER_ISOC,
	.wMaxPacketSize		= cpu_to_le16(512),
	.bInterval		= 1,
};


> I'm able to load the
> module and the DM365 is detected as a UVC device by a Windows host,
> but then I am unable to add DirectShow filters to the device. ?Perhaps
> the root cause is similar?

With the current gadget driver, all "class specific" control message
on endpoint 0
are redirected to userspace. So you need cooperation from userspace on
the gadget side
to answer these requests. I will look into it today.

>
> Thanks,
>
> Will Kelleher
> Nuvixa, Inc.
>
>
>
> On Fri, Feb 4, 2011 at 7:41 AM, jean-philippe francois
> <jp.francois at cynove.com> wrote:
>> 2011/2/4 B, Ravi <ravibabu at ti.com>:
>>>
>>>> >> Hi,
>>>> >>
>>>> >> I have backported the UVC gadget patch by laurent pinchart on a custom
>>>> >> DM365 board.
>>>> >> It fails to allocate the required endpoints :
>>>> >>
>>>> >> ? ? ? ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
>>>> >> ? ? ? if (!ep) {
>>>> >> ? ? ? ? ? ? ? INFO(cdev, "Unable to allocate streaming EP\n");
>>>> >> ? ? ? ? ? ? ? goto error;
>>>> >> ? ? ? }
>>>> >>
>>>> >> I can see the message "Unable to allocate streaming EP" in the log.
>>>> >> How can I debug / fix this ?
>>>> >>
>>>> >> The mass storage gadget is working fine.
>>>> >>
>>>> >> Here is the failing endpoint descriptor :
>>>> >>
>>>> >> static struct usb_endpoint_descriptor uvc_streaming_ep = {
>>>> >> ? ? ? .bLength ? ? ? ? ? ? ? ?= USB_DT_ENDPOINT_SIZE,
>>>> >> ? ? ? .bDescriptorType ? ? ? ?= USB_DT_ENDPOINT,
>>>> >> ? ? ? .bEndpointAddress ? ? ? = USB_DIR_IN,
>>>> >> ? ? ? .bmAttributes ? ? ? ? ? = USB_ENDPOINT_XFER_ISOC,
>>>> >> ? ? ? .wMaxPacketSize ? ? ? ? = cpu_to_le16(1024),
>>>> >> ? ? ? .bInterval ? ? ? ? ? ? ?= 1,
>>>> >> };
>>>> >>
>>>> >
>>>> > The above endpoint requires endpoint fifo size to be 1024. Check with
>>>> the fifo table entries in musb_core.c file and update as per requirement.
>>>> >
>>>>
>>>> So I can either change the fifo_mode module paramete to pick another
>>>> config, or
>>>> change the endpoint config to use a smaller packet size ?
>>>>
>>>
>>> If the UVC driver requirement may be 1024 bytes packet size, then you cannot change, what you can do is change the current fifo-mode
>>> configuration sizes as per your device requirements.
>>>
>>> For example :
>>> /* mode 4 - fits in 4KB */
>>> static struct musb_fifo_cfg __devinitdata mode_4_cfg[] = {
>>> { .hw_ep_num = ?1, .style = FIFO_TX, ? .maxpacket = 512, },
>>> { .hw_ep_num = ?1, .style = FIFO_RX, ? .maxpacket = 512, },
>>> { .hw_ep_num = ?2, .style = FIFO_TX, ? .maxpacket = 1024, },
>>> { .hw_ep_num = ?2, .style = FIFO_RX, ? .maxpacket = 1024, },
>>> { .hw_ep_num = ?3, .style = FIFO_TX, ? .maxpacket = 256, },
>>> { .hw_ep_num = ?3, .style = FIFO_RX, ? .maxpacket = 256, },
>>>
>> Thank you, I can see that more recent kernel have the possibility
>> to specify this config in platform_data, which is great !
>>
>>> Ravi
>>>
>>>> >> Jean-Philippe Fran?ois
>>>> >> _______________________________________________
>>>> >> 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
>>
>

From jp.francois at cynove.com  Mon Feb  7 02:35:51 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Mon, 7 Feb 2011 09:35:51 +0100
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <AANLkTimxt6fJU29F38oKm+h6LfwTkfO=dPXv-jiVHgmP@mail.gmail.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>
	<AANLkTimxt6fJU29F38oKm+h6LfwTkfO=dPXv-jiVHgmP@mail.gmail.com>
Message-ID: <AANLkTik6cGcjkr=nq7SuVyvpKR+gomv4=JgU-p8Nhca0@mail.gmail.com>

2011/2/4 Will Kelleher <will.kelleher at nuvixa.com>:
> Hello,
>
> The staging tree that I recently pulled from Arago
> (git://arago-project.org/git/projects/linux-davinci.git) is 2.6.32.17.
> ?If you're interested in the UVC gadget, you'll have to backport the
> code, along with portions of V4L2 (or remove the dependency on this
> from the UVC code).
>

What path did you choose ? Are the V4L2 event framework patches
applying cleanly ?
Where can I find them ?

> Will Kelleher
> Nuvixa, Inc.
>
>
>
> On Thu, Feb 3, 2011 at 3:32 AM, jean-philippe francois
> <jp.francois at cynove.com> wrote:
>> 2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
>>> Hi,
>>>
>>> What is the status of the arago staging tree ?
>>> It once was tracking the mainline kernel without much lag, but
>>> it seems to be stuck at 2.6.34
>>>
>>> I am interested in :
>>> - video capture
>> Both bayer and YUV, using USERPTR IO
>>
>>> - single-shot previewer operation
>>> - cmem, edma and all other DVSDK modules can build against it
>>> - video display (optional)
>>> - OSD (optional)
>>>
>>> I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
>>> or older kernel, because I am interested
>>> in the uvc gadget driver.
>>>
>>> What tree could be a good starting point for this ?
>>>
>> _______________________________________________
>> 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 laurent.pinchart at ideasonboard.com  Mon Feb  7 04:02:55 2011
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 7 Feb 2011 11:02:55 +0100
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
Message-ID: <201102071102.55990.laurent.pinchart@ideasonboard.com>

Hi Jean-Philippe,

On Friday 04 February 2011 11:58:05 jean-philippe francois wrote:
> Hi,
> 
> I have backported the UVC gadget patch by laurent pinchart on a custom
> DM365 board.
> It fails to allocate the required endpoints :
> 
> 	ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
> 	if (!ep) {
> 		INFO(cdev, "Unable to allocate streaming EP\n");
> 		goto error;
> 	}
> 
> I can see the message "Unable to allocate streaming EP" in the log.
> How can I debug / fix this ?
> 
> The mass storage gadget is working fine.
> 
> Here is the failing endpoint descriptor :
> 
> static struct usb_endpoint_descriptor uvc_streaming_ep = {
> 	.bLength		= USB_DT_ENDPOINT_SIZE,
> 	.bDescriptorType	= USB_DT_ENDPOINT,
> 	.bEndpointAddress	= USB_DIR_IN,
> 	.bmAttributes		= USB_ENDPOINT_XFER_ISOC,
> 	.wMaxPacketSize		= cpu_to_le16(1024),
> 	.bInterval		= 1,
> };

The MUSB FIFO configurations don't support 1024 bytes endpoint buffers out of 
the box. You can modify that in drivers/usb/musb/musb_core.c (mode_*_cfg). 
Remember that the DM365 MUSB FIFO RAM is only 4kB long.

-- 
Regards,

Laurent Pinchart

From jp.francois at cynove.com  Mon Feb  7 04:18:28 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Mon, 7 Feb 2011 11:18:28 +0100
Subject: DM365 uvc gadget
In-Reply-To: <201102071102.55990.laurent.pinchart@ideasonboard.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<201102071102.55990.laurent.pinchart@ideasonboard.com>
Message-ID: <AANLkTi=aVjNNsOxfTPm8SY9O2ykqtymNABW=7yS0uwyf@mail.gmail.com>

>
> The MUSB FIFO configurations don't support 1024 bytes endpoint buffers out of
> the box. You can modify that in drivers/usb/musb/musb_core.c (mode_*_cfg).
> Remember that the DM365 MUSB FIFO RAM is only 4kB long.
>

But is it mandatory, or can I modify the gadget driver instead ? Does
UVC somehow
needs 1024 bytes endpoint ?

> --
> Regards,
>
> Laurent Pinchart
>

From ajay.gupta at ti.com  Mon Feb  7 04:23:07 2011
From: ajay.gupta at ti.com (Gupta, Ajay Kumar)
Date: Mon, 7 Feb 2011 15:53:07 +0530
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTi=aVjNNsOxfTPm8SY9O2ykqtymNABW=7yS0uwyf@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<201102071102.55990.laurent.pinchart@ideasonboard.com>
	<AANLkTi=aVjNNsOxfTPm8SY9O2ykqtymNABW=7yS0uwyf@mail.gmail.com>
Message-ID: <19F8576C6E063C45BE387C64729E739404BD900987@dbde02.ent.ti.com>

> > The MUSB FIFO configurations don't support 1024 bytes endpoint buffers
> out of
> > the box. You can modify that in drivers/usb/musb/musb_core.c
> (mode_*_cfg).
> > Remember that the DM365 MUSB FIFO RAM is only 4kB long.
> >
> 
> But is it mandatory, or can I modify the gadget driver instead ? Does
> UVC somehow
> needs 1024 bytes endpoint ?

For a better performance use ISO endpoint with 1024 Byte packet size. Please
Change the fifo cfg at musb_core.c to have one 1024 Tx entry.

-Ajay
> 
> > --
> > Regards,
> >
> > Laurent Pinchart
> >
> _______________________________________________
> 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 laurent.pinchart at ideasonboard.com  Mon Feb  7 05:25:02 2011
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 7 Feb 2011 12:25:02 +0100
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTi=aVjNNsOxfTPm8SY9O2ykqtymNABW=7yS0uwyf@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<201102071102.55990.laurent.pinchart@ideasonboard.com>
	<AANLkTi=aVjNNsOxfTPm8SY9O2ykqtymNABW=7yS0uwyf@mail.gmail.com>
Message-ID: <201102071225.02616.laurent.pinchart@ideasonboard.com>

Hi Jean-Philippe,

On Monday 07 February 2011 11:18:28 jean-philippe francois wrote:
> > The MUSB FIFO configurations don't support 1024 bytes endpoint buffers
> > out of the box. You can modify that in drivers/usb/musb/musb_core.c
> > (mode_*_cfg). Remember that the DM365 MUSB FIFO RAM is only 4kB long.
> 
> But is it mandatory, or can I modify the gadget driver instead ? Does
> UVC somehow needs 1024 bytes endpoint ?

1024 should offer better performances, but yyou can modify the endpoint max 
packet size to 512.

-- 
Regards,

Laurent Pinchart

From schen at mvista.com  Mon Feb  7 08:00:47 2011
From: schen at mvista.com (Steve Chen)
Date: Mon, 7 Feb 2011 08:00:47 -0600
Subject: UART2 Error
In-Reply-To: <AANLkTikRFKdK_jm5PQ9ph0MSArfXc4izD6s+uVdagsRB@mail.gmail.com>
References: <AANLkTikRFKdK_jm5PQ9ph0MSArfXc4izD6s+uVdagsRB@mail.gmail.com>
Message-ID: <AANLkTin3tbwzyH0sRLktz4XfsKQP9sHFSNKmDwfA5Baq@mail.gmail.com>

On Sat, Feb 5, 2011 at 7:05 AM, Swapnil Ashtekar <swapashtekar at gmail.com> wrote:
> Hey,
>
> ?? ? ? ?I am using DM6446, I want to transfer data using serial port, I
> wrote simple code for it , used the appropriate register addresses,

Are you using Linux?  There is already a driver for it, so you don't
need to write any code that involves in changing values in registers.

>
> but the binary of C code is not working on the environment of DM6446, it is
> showing?error : segmentation fault..
>
> Is it because of ?the inactivation of the uart2 ? The uart0 of the board is
> being used for other purpose.
>
> Can I have both UART enabled same time ?

Existing DM6446 driver supports multiple UART at the same time.

>
> What am I supposed to do ? I am a novice, please guide me.

Open /dev/ttySx associated with the UART you want to use and
read/write as you would for normal file.

Regards,

Steve

From sshtylyov at ru.mvista.com  Mon Feb  7 09:45:37 2011
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Mon, 7 Feb 2011 18:45:37 +0300
Subject: [PATCH] DA850 EVM: kill useless variable
Message-ID: <201102071845.37812.sshtylyov@ru.mvista.com>

Commit 75e2ea643fe43d5aa836475acee5bd97cd9ea4bf (davinci: DA850/OMAP-L138 EVM
expander setup and UI card detection) introduced a useless variable: it's
always set to 1 before it's checked in da850_evm_setup_nor_nand()...

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 |    5 +----
 1 file changed, 1 insertion(+), 4 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
@@ -231,8 +231,6 @@ static const short da850_evm_nor_pins[] 
 	-1
 };
 
-static u32 ui_card_detected;
-
 #if defined(CONFIG_MMC_DAVINCI) || \
     defined(CONFIG_MMC_DAVINCI_MODULE)
 #define HAS_MMC 1
@@ -244,7 +242,7 @@ static inline void da850_evm_setup_nor_n
 {
 	int ret = 0;
 
-	if (ui_card_detected & !HAS_MMC) {
+	if (!HAS_MMC) {
 		ret = davinci_cfg_reg_list(da850_evm_nand_pins);
 		if (ret)
 			pr_warning("da850_evm_init: nand mux setup failed: "
@@ -394,7 +392,6 @@ static int da850_evm_ui_expander_setup(s
 		goto exp_setup_keys_fail;
 	}
 
-	ui_card_detected = 1;
 	pr_info("DA850/OMAP-L138 EVM UI card detected\n");
 
 	da850_evm_setup_nor_nand();

From will.kelleher at nuvixa.com  Mon Feb  7 11:53:08 2011
From: will.kelleher at nuvixa.com (Will Kelleher)
Date: Mon, 7 Feb 2011 11:53:08 -0600
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <AANLkTik6cGcjkr=nq7SuVyvpKR+gomv4=JgU-p8Nhca0@mail.gmail.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>
	<AANLkTimxt6fJU29F38oKm+h6LfwTkfO=dPXv-jiVHgmP@mail.gmail.com>
	<AANLkTik6cGcjkr=nq7SuVyvpKR+gomv4=JgU-p8Nhca0@mail.gmail.com>
Message-ID: <AANLkTinj42yYB9YbaYMxYk8E9=kepwazbY0FiTxMRb-g@mail.gmail.com>

I didn't use patches, I just overwrote all the 2.6.32 V4L2 files with the
set from the current 2.6.36 kernel.  I had to make a few other changes to
get the module to compile correctly, but it was relatively painless.

Will Kelleher
Nuvixa, Inc.



On Mon, Feb 7, 2011 at 2:35 AM, jean-philippe francois <
jp.francois at cynove.com> wrote:

> 2011/2/4 Will Kelleher <will.kelleher at nuvixa.com>:
> > Hello,
> >
> > The staging tree that I recently pulled from Arago
> > (git://arago-project.org/git/projects/linux-davinci.git) is 2.6.32.17.
> >  If you're interested in the UVC gadget, you'll have to backport the
> > code, along with portions of V4L2 (or remove the dependency on this
> > from the UVC code).
> >
>
> What path did you choose ? Are the V4L2 event framework patches
> applying cleanly ?
> Where can I find them ?
>
> > Will Kelleher
> > Nuvixa, Inc.
> >
> >
> >
> > On Thu, Feb 3, 2011 at 3:32 AM, jean-philippe francois
> > <jp.francois at cynove.com> wrote:
> >> 2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
> >>> Hi,
> >>>
> >>> What is the status of the arago staging tree ?
> >>> It once was tracking the mainline kernel without much lag, but
> >>> it seems to be stuck at 2.6.34
> >>>
> >>> I am interested in :
> >>> - video capture
> >> Both bayer and YUV, using USERPTR IO
> >>
> >>> - single-shot previewer operation
> >>> - cmem, edma and all other DVSDK modules can build against it
> >>> - video display (optional)
> >>> - OSD (optional)
> >>>
> >>> I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
> >>> or older kernel, because I am interested
> >>> in the uvc gadget driver.
> >>>
> >>> What tree could be a good starting point for this ?
> >>>
> >> _______________________________________________
> >> 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/20110207/bc6d2ec3/attachment.html>

From nsekhar at ti.com  Tue Feb  8 01:53:58 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 8 Feb 2011 13:23:58 +0530
Subject: [PATCH v1] davinci: spi: move event queue parameter to platform
	data
In-Reply-To: <1296828552-11765-1-git-send-email-michael.williamson@criticallink.com>
References: <1296828552-11765-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59302488B9AFA@dbde02.ent.ti.com>

On Fri, Feb 04, 2011 at 19:39:12, Michael Williamson wrote:
> For DMA operation, the davinci spi driver needs an event queue number.
> Currently, this number is passed as a IORESOURCE_DMA.  This is not
> correct, as the event queue is not a DMA channel.  Pass the event queue
> via the platform data structure instead.
> 
> On dm355 and dm365, move the eventq assignment for spi0 out of resources
> array and into platform data.
> 
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>

Tested this on DM355 and DM365 EVMs. Event queue numbers show up
properly in the logs and DMA transfers to on-board SPI EEPROMs
happen correctly.

> ---
> Changes since v0:
>   - combined separate platform patches with driver patch to avoid
>     potential regression if doing a bissect.
>   - fixed up typo per comments.

This typo doesn't seem fixed?

> + * @dma_event_q: DMA event_q to use if SPI_IO_TYPE_DMA is used for any device
> + *		on the bus.

On 2/4/2011 7:03 AM, Sergei Shtylyov wrote:
>> + * @dma_event_q: DMA event_q to use if SPI_IO_TYPE_DMA is used for any device
> 
>    s/event_q/event queue/?

Can you please re-spin with this fixed and my ack included:

Acked-by: Sekhar Nori <nsekhar at ti.com>

With Grant's ack this should probably get merged through
DaVinci tree (since it touches mach-davinci).

Thanks,
Sekhar


From nsekhar at ti.com  Tue Feb  8 03:00:04 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 8 Feb 2011 14:30:04 +0530
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59302488B9BB6@dbde02.ent.ti.com>

Hi jean-philippe,

On Thu, Feb 03, 2011 at 15:02:36, jean-philippe francois wrote:
> 2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
> > Hi,
> >
> > What is the status of the arago staging tree ?
> > It once was tracking the mainline kernel without much lag, but
> > it seems to be stuck at 2.6.34

Recently a 2.6.37 based baseline was pushed[1]. This is
work in progress and we are shooting for end-of-march
for a full fledged kernel release on DM365 and OMAP-L138/AM18x.

> >
> > I am interested in :
> > - video capture
> Both bayer and YUV, using USERPTR IO
> 
> > - single-shot previewer operation
> > - cmem, edma and all other DVSDK modules can build against it
> > - video display (optional)
> > - OSD (optional)

cmem is not part of this kernel. This will surely become
available as and when a DVSDK release is available based on the
above mentioned kernel baseline. You can check on e2e.ti.com for
updates on DVSDK roadmap.

EDMA has been verified already.

For updates on the other items I am CCing Manju who has been
working on updating all the video related components.

Thanks,
Sekhar

[1] http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/03.21.00.03

> >
> > I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
> > or older kernel, because I am interested
> > in the uvc gadget driver.
> >
> > What tree could be a good starting point for this ?
> >
> _______________________________________________
> 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 ottavio.campana at dei.unipd.it  Tue Feb  8 03:15:06 2011
From: ottavio.campana at dei.unipd.it (Ottavio Campana)
Date: Tue, 08 Feb 2011 10:15:06 +0100
Subject: Linux + CE + POSIX interval timers
In-Reply-To: <SNT109-DS18450C922EF9FFB20BBE01CFE60@phx.gbl>
References: <SNT109-DS18450C922EF9FFB20BBE01CFE60@phx.gbl>
Message-ID: <4D51099A.3060400@dei.unipd.it>

On 02/04/2011 06:45 PM, Danny Marsh wrote:
> Hello,
> We are developing a DM6446 platform with linux and the 
> dvsdk_2_00_00_22.  We have created several iUniversal Codec Engine 
> algorithms and can get them to run independently.  We then tried to 
> integrate the algorithms into another application that was using 
> interval timers (setitimer and timer_create), and ALSA.  This is where 
> we started running into issues.  First when we started the interval 
> timers before opening the DSP server, the server wouldn't even 
> open.  When we opened the handles to the DSP server before starting 
> the interval timers it opened, but the interval timers weren't working 
> correctly.

I used timers in a previous project, and the worked fine with kernel 
2.6.18. But I did not use alsa, only video.

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

From sudhakar.raj at ti.com  Tue Feb  8 03:30:06 2011
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Tue, 8 Feb 2011 15:00:06 +0530
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
In-Reply-To: <4D4A779F.8030305@acn-group.ch>
References: <4D4A779F.8030305@acn-group.ch>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>

Hi,

On Thu, Feb 03, 2011 at 15:08:39, Christophe Aeschlimann wrote:
> Hi,
> 
> I'm working with the arago omapl1 kernel on a custom OMAP-L138 board.
> 
> http://arago-project.org/git/projects/?p=linux-omapl1.git
> 
> Recently I made some testing with the PREEMPT_RT patches (that were also
> applied in a branch in the arago kernel). The Kernel seems to behave
> correctly but I have issues with the GPIO interface. E.G. I'm using the
> "gpio-keys" and "matrix-keypad" drivers and they don't behave correctly.
> The symptoms are :
> 
> Just after boot, I can press a button attached to a GPIO and get an
> event through the input subsystem, but after a few presses (few being
> random) the button doesn't generate an event any-more. (the interrupt is
> also not reported in /proc/interrupts).
> 
> By browsing the mailing list archives I saw these old patches for the
> davinci tree and the omap tree :
> 
> http://linux.omap.com/pipermail/davinci-linux-open-source/2007-October/004283.html
> 
> http://marc.info/?l=linux-omap&m=119634477133936&w=2
> 
> (both are also listed here
> https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch)
> 
> Of course quite a lot of things changed since 2.6.23 so it's difficult
> to just adapt the patches (I don't even know if they are still required
> or if I'm facing another issue).
> 
> Anyway just wanted to know if someone is having the same issues or if
> there is a new version of the patches for the latest davinci kernel that
> I may have missed.
> 

I downloaded the Linux Kernel from arago which had these patches applied. I
added support for "gpio-keys-polled" driver and tested it on AM1810 EVM from
spectrum digital. I did not observe the issue you have reported. I pressed
the push buttons on the daughter card for about 800 times and I used evtest
to test.

Regards,
Sudhakar

From c.aeschlimann at acn-group.ch  Tue Feb  8 04:13:30 2011
From: c.aeschlimann at acn-group.ch (Christophe Aeschlimann)
Date: Tue, 08 Feb 2011 11:13:30 +0100
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>
References: <4D4A779F.8030305@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>
Message-ID: <4D51174A.7050504@acn-group.ch>

Hi Sudhakar,

On 08.02.2011 10:30, Rajashekhara, Sudhakar wrote:
> Hi,
> 
> On Thu, Feb 03, 2011 at 15:08:39, Christophe Aeschlimann wrote:
>> Hi,
>>
>> I'm working with the arago omapl1 kernel on a custom OMAP-L138 board.
>>
>> http://arago-project.org/git/projects/?p=linux-omapl1.git
>>
>> Recently I made some testing with the PREEMPT_RT patches (that were also
>> applied in a branch in the arago kernel). The Kernel seems to behave
>> correctly but I have issues with the GPIO interface. E.G. I'm using the
>> "gpio-keys" and "matrix-keypad" drivers and they don't behave correctly.
>> The symptoms are :
>>
>> Just after boot, I can press a button attached to a GPIO and get an
>> event through the input subsystem, but after a few presses (few being
>> random) the button doesn't generate an event any-more. (the interrupt is
>> also not reported in /proc/interrupts).
>>
>> By browsing the mailing list archives I saw these old patches for the
>> davinci tree and the omap tree :
>>
>> http://linux.omap.com/pipermail/davinci-linux-open-source/2007-October/004283.html
>>
>> http://marc.info/?l=linux-omap&m=119634477133936&w=2
>>
>> (both are also listed here
>> https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch)
>>
>> Of course quite a lot of things changed since 2.6.23 so it's difficult
>> to just adapt the patches (I don't even know if they are still required
>> or if I'm facing another issue).
>>
>> Anyway just wanted to know if someone is having the same issues or if
>> there is a new version of the patches for the latest davinci kernel that
>> I may have missed.
>>
> 
> I downloaded the Linux Kernel from arago which had these patches applied. I
> added support for "gpio-keys-polled" driver and tested it on AM1810 EVM from
> spectrum digital. I did not observe the issue you have reported. I pressed
> the push buttons on the daughter card for about 800 times and I used evtest
> to test.

Thanks for doing some testing on your side.

Any specific reason why you used the gpio-keys-polled driver ? I'm using
the standard gpio-keys driver which is based on a interrupt instead of
polling. As I said I think it's a problem with the interruption mechanism.

I'm defining my buttons with a debounce_interval of 30 in case it
changes anything.

Thanks for your help,

> Regards,
> Sudhakar

Best regards,

Christophe


-- 
Christophe Aeschlimann

Embedded Software Engineer & IT Manager

ACN 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 jp.francois at cynove.com  Tue Feb  8 04:44:42 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Tue, 8 Feb 2011 11:44:42 +0100
Subject: Linux + CE + POSIX interval timers
In-Reply-To: <SNT109-DS18450C922EF9FFB20BBE01CFE60@phx.gbl>
References: <SNT109-DS18450C922EF9FFB20BBE01CFE60@phx.gbl>
Message-ID: <AANLkTimAk0r6H0JjT3+Va49o30OuOMo7a1qcFsASQ-Nq@mail.gmail.com>

2011/2/4 Danny Marsh <dmarsh10 at hotmail.com>:
> Hello,
>
> We are developing a DM6446 platform with linux and?the dvsdk_2_00_00_22.? We
> have created several iUniversal Codec Engine algorithms and can get them to
> run independently.? We then tried to integrate the algorithms into another
> application that was using interval timers (setitimer and timer_create), and
> ALSA.? This is where we started running into issues.? First when we started
> the interval timers before opening the DSP server, the server wouldn't even
> open.??When we opened the handles to the DSP server before starting the
> interval timers it?opened, but the interval timers weren't working
> correctly.
>
> Has anyone had experience trying to do this?

No, but if you have different parts of your code trying to use SIGALARM,
then you are doomed ! I don't know if the codec engine does, but it
sure looks like it.
>
> Is there a better way to do accurate timing (20 msec) than with interval
> timers?
>
Maybe using thread and semaphore etc... is the only options you have left
if you can't use any SIGALARM messing call (setitimer, sleep, usleep....)

Then if you want a timeout, you can do so with the timeout arg of a select call,
where all three sets are empty.

> Thanks,
> Danny
> _______________________________________________
> 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 sudhakar.raj at ti.com  Tue Feb  8 05:19:43 2011
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Tue, 8 Feb 2011 16:49:43 +0530
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
In-Reply-To: <4D51174A.7050504@acn-group.ch>
References: <4D4A779F.8030305@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>
	<4D51174A.7050504@acn-group.ch>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59302488B9CEE@dbde02.ent.ti.com>

Hi Christophe,

On Tue, Feb 08, 2011 at 15:43:30, Christophe Aeschlimann wrote:
> Hi Sudhakar,
> 

[...]

> 
> Thanks for doing some testing on your side.
> 
> Any specific reason why you used the gpio-keys-polled driver ? I'm using
> the standard gpio-keys driver which is based on a interrupt instead of
> polling. As I said I think it's a problem with the interruption mechanism.
> 

I am not able boot my board when I use the gpio-keys driver? Have you done any
modifications to the kernel to use gpio-keys driver?

Regards,
Sudhakar

From c.aeschlimann at acn-group.ch  Tue Feb  8 05:59:44 2011
From: c.aeschlimann at acn-group.ch (Christophe Aeschlimann)
Date: Tue, 08 Feb 2011 12:59:44 +0100
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302488B9CEE@dbde02.ent.ti.com>
References: <4D4A779F.8030305@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>
	<4D51174A.7050504@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9CEE@dbde02.ent.ti.com>
Message-ID: <4D513030.1050306@acn-group.ch>

On 08.02.2011 12:19, Rajashekhara, Sudhakar wrote:
> Hi Christophe,
> 
> On Tue, Feb 08, 2011 at 15:43:30, Christophe Aeschlimann wrote:
>> Hi Sudhakar,
>>
> 
> [...]
> 
>>
>> Thanks for doing some testing on your side.
>>
>> Any specific reason why you used the gpio-keys-polled driver ? I'm using
>> the standard gpio-keys driver which is based on a interrupt instead of
>> polling. As I said I think it's a problem with the interruption mechanism.
>>
> 
> I am not able boot my board when I use the gpio-keys driver? Have you done any
> modifications to the kernel to use gpio-keys driver?

No I didn't change anything that would affect that.

I'm defining a struct gpio_keys_button with my buttons that is
encapsulated in a static struct gpio_keys_platform_data that is
encapsulated in a static struct platform_device that is then registered
with the system.

I have the following set :

CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_MATRIX=y

Our custom kernel is based on CONFIG_MACH_DAVINCI_DA850_EVM and boots
fine. I used the driver on the Hawkboard as well and it was also ok.

Regards,

Christophe


-- 
Christophe Aeschlimann

Embedded Software Engineer & IT Manager

ACN 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 michael.williamson at criticallink.com  Tue Feb  8 06:59:55 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue,  8 Feb 2011 07:59:55 -0500
Subject: [PATCH v2] davinci: spi: move event queue parameter to platform data
Message-ID: <1297169995-31321-1-git-send-email-michael.williamson@criticallink.com>

For DMA operation, the davinci spi driver needs an event queue number.
Currently, this number is passed as a IORESOURCE_DMA.  This is not
correct, as the event queue is not a DMA channel.  Pass the event queue
via the platform data structure instead.

On dm355 and dm365, move the eventq assignment for spi0 out of resources
array and into platform data.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
Changes since v1:
   - Add Sekhar's Ack.
   - Really fix the typo.  This time for sure (blew the format patch
     on last go around).

 arch/arm/mach-davinci/dm355.c            |    5 +----
 arch/arm/mach-davinci/dm365.c            |    5 +----
 arch/arm/mach-davinci/include/mach/spi.h |   15 ++++++++++-----
 drivers/spi/davinci_spi.c                |   11 +++--------
 4 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a5f8a80..76364d1 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -403,16 +403,13 @@ static struct resource dm355_spi0_resources[] = {
 		.start = 16,
 		.flags = IORESOURCE_DMA,
 	},
-	{
-		.start = EVENTQ_1,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct davinci_spi_platform_data dm355_spi0_pdata = {
 	.version 	= SPI_VERSION_1,
 	.num_chipselect = 2,
 	.cshold_bug	= true,
+	.dma_event_q	= EVENTQ_1,
 };
 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 02d2cc3..4604e72 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -625,6 +625,7 @@ 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,
+	.dma_event_q	= EVENTQ_3,
 };
 
 static struct resource dm365_spi0_resources[] = {
@@ -645,10 +646,6 @@ static struct resource dm365_spi0_resources[] = {
 		.start = 16,
 		.flags = IORESOURCE_DMA,
 	},
-	{
-		.start = EVENTQ_3,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct platform_device dm365_spi0_device = {
diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
index 38f4da5..7af305b 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -19,6 +19,8 @@
 #ifndef __ARCH_ARM_DAVINCI_SPI_H
 #define __ARCH_ARM_DAVINCI_SPI_H
 
+#include <mach/edma.h>
+
 #define SPI_INTERN_CS	0xFF
 
 enum {
@@ -39,13 +41,16 @@ enum {
  *		to populate if all chip-selects are internal.
  * @cshold_bug:	set this to true if the SPI controller on your chip requires
  *		a write to CSHOLD bit in between transfers (like in DM355).
+ * @dma_event_q: DMA event queue to use if SPI_IO_TYPE_DMA is used for any
+ *		device on the bus.
  */
 struct davinci_spi_platform_data {
-	u8	version;
-	u8	num_chipselect;
-	u8	intr_line;
-	u8	*chip_sel;
-	bool	cshold_bug;
+	u8			version;
+	u8			num_chipselect;
+	u8			intr_line;
+	u8			*chip_sel;
+	bool			cshold_bug;
+	enum dma_event_q	dma_event_q;
 };
 
 /**
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 6beab99..166a879 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -790,7 +790,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	struct resource *r, *mem;
 	resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
 	resource_size_t	dma_tx_chan = SPI_NO_RESOURCE;
-	resource_size_t	dma_eventq = SPI_NO_RESOURCE;
 	int i = 0, ret = 0;
 	u32 spipc0;
 
@@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	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;
 
 	dspi->bitbang.txrx_bufs = davinci_spi_bufs;
 	if (dma_rx_chan != SPI_NO_RESOURCE &&
-	    dma_tx_chan != SPI_NO_RESOURCE &&
-	    dma_eventq != SPI_NO_RESOURCE) {
+	    dma_tx_chan != SPI_NO_RESOURCE) {
 		dspi->dma.rx_channel = dma_rx_chan;
 		dspi->dma.tx_channel = dma_tx_chan;
-		dspi->dma.eventq = dma_eventq;
+		dspi->dma.eventq = pdata->dma_event_q;
 
 		ret = davinci_spi_request_dma(dspi);
 		if (ret)
@@ -897,7 +892,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
 		dev_info(&pdev->dev, "DMA: supported\n");
 		dev_info(&pdev->dev, "DMA: RX channel: %d, TX channel: %d, "
 				"event queue: %d\n", dma_rx_chan, dma_tx_chan,
-				dma_eventq);
+				pdata->dma_event_q);
 	}
 
 	dspi->get_rx = davinci_spi_rx_buf_u8;
-- 
1.7.0.4


From manjunath.hadli at ti.com  Tue Feb  8 07:59:24 2011
From: manjunath.hadli at ti.com (Hadli, Manjunath)
Date: Tue, 8 Feb 2011 19:29:24 +0530
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302488B9BB6@dbde02.ent.ti.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>,
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9BB6@dbde02.ent.ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930247F50DBA@dbde02.ent.ti.com>

Jean-Philippe,
 Among the Video related items you mentioned, pretty much everything is planned to be supported. I will check back on the User Pointer I/O and get back to you.
-Manju

________________________________________
From: Nori, Sekhar
Sent: Tuesday, February 08, 2011 2:30 PM
To: jean-philippe francois; davinci-linux-open-source at linux.davincidsp.com
Cc: Hadli, Manjunath; Rajashekhara, Sudhakar
Subject: RE: Recent kernel for DM365 and status of the staging tree

Hi jean-philippe,

On Thu, Feb 03, 2011 at 15:02:36, jean-philippe francois wrote:
> 2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
> > Hi,
> >
> > What is the status of the arago staging tree ?
> > It once was tracking the mainline kernel without much lag, but
> > it seems to be stuck at 2.6.34

Recently a 2.6.37 based baseline was pushed[1]. This is
work in progress and we are shooting for end-of-march
for a full fledged kernel release on DM365 and OMAP-L138/AM18x.

> >
> > I am interested in :
> > - video capture
> Both bayer and YUV, using USERPTR IO
>
> > - single-shot previewer operation
> > - cmem, edma and all other DVSDK modules can build against it
> > - video display (optional)
> > - OSD (optional)

cmem is not part of this kernel. This will surely become
available as and when a DVSDK release is available based on the
above mentioned kernel baseline. You can check on e2e.ti.com for
updates on DVSDK roadmap.

EDMA has been verified already.

For updates on the other items I am CCing Manju who has been
working on updating all the video related components.

Thanks,
Sekhar

[1] http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/03.21.00.03

> >
> > I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
> > or older kernel, because I am interested
> > in the uvc gadget driver.
> >
> > What tree could be a good starting point for this ?
> >
> _______________________________________________
> 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 caglarakyuz at gmail.com  Tue Feb  8 08:18:19 2011
From: caglarakyuz at gmail.com (Caglar Akyuz)
Date: Tue, 8 Feb 2011 16:18:19 +0200
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930247F50DBA@dbde02.ent.ti.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9BB6@dbde02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930247F50DBA@dbde02.ent.ti.com>
Message-ID: <201102081618.19900.caglarakyuz@gmail.com>

On Tuesday 08 February 2011 03:59:24 pm Hadli, Manjunath wrote:
> Jean-Philippe,
>  Among the Video related items you mentioned, pretty much everything is
>  planned to be supported. I will check back on the User Pointer I/O and get
>  back to you. -Manju
> 

I wanted test your latest v12 patch series for video drivers, but without a 
proper FB support it is not easy to test series for me. Can you point us to a 
GIT tree where current progress is going on? I tried to scan all arago trees 
but cannot find one.

Thanks,
Caglar
> ________________________________________
> From: Nori, Sekhar
> Sent: Tuesday, February 08, 2011 2:30 PM
> To: jean-philippe francois; davinci-linux-open-source at linux.davincidsp.com
> Cc: Hadli, Manjunath; Rajashekhara, Sudhakar
> Subject: RE: Recent kernel for DM365 and status of the staging tree
> 
> Hi jean-philippe,
> 
> On Thu, Feb 03, 2011 at 15:02:36, jean-philippe francois wrote:
> > 2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
> > > Hi,
> > >
> > > What is the status of the arago staging tree ?
> > > It once was tracking the mainline kernel without much lag, but
> > > it seems to be stuck at 2.6.34
> 
> Recently a 2.6.37 based baseline was pushed[1]. This is
> work in progress and we are shooting for end-of-march
> for a full fledged kernel release on DM365 and OMAP-L138/AM18x.
> 
> > > I am interested in :
> > > - video capture
> >
> > Both bayer and YUV, using USERPTR IO
> >
> > > - single-shot previewer operation
> > > - cmem, edma and all other DVSDK modules can build against it
> > > - video display (optional)
> > > - OSD (optional)
> 
> cmem is not part of this kernel. This will surely become
> available as and when a DVSDK release is available based on the
> above mentioned kernel baseline. You can check on e2e.ti.com for
> updates on DVSDK roadmap.
> 
> EDMA has been verified already.
> 
> For updates on the other items I am CCing Manju who has been
> working on updating all the video related components.
> 
> Thanks,
> Sekhar
> 
> [1]
>  http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=re
> fs/heads/03.21.00.03
> 
> > > I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
> > > or older kernel, because I am interested
> > > in the uvc gadget driver.
> > >
> > > What tree could be a good starting point for this ?
> >
> > _______________________________________________
> > 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
> 

From manjunath.hadli at ti.com  Tue Feb  8 08:42:47 2011
From: manjunath.hadli at ti.com (Hadli, Manjunath)
Date: Tue, 8 Feb 2011 20:12:47 +0530
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <201102081618.19900.caglarakyuz@gmail.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9BB6@dbde02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930247F50DBA@dbde02.ent.ti.com>,
	<201102081618.19900.caglarakyuz@gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930247F50DBB@dbde02.ent.ti.com>

Jean-Philippe,
The fbdev is under development and the trees have to be cleaned up before opening up. Request you to wait till Friday when I can publish you the particulars. Please ping me again later in the week.

-Manju
________________________________________
From: Caglar Akyuz [caglarakyuz at gmail.com]
Sent: Tuesday, February 08, 2011 7:48 PM
To: Hadli, Manjunath
Cc: davinci-linux-open-source at linux.davincidsp.com; Nori, Sekhar; jean-philippe francois
Subject: Re: Recent kernel for DM365 and status of the staging tree

On Tuesday 08 February 2011 03:59:24 pm Hadli, Manjunath wrote:
> Jean-Philippe,
>  Among the Video related items you mentioned, pretty much everything is
>  planned to be supported. I will check back on the User Pointer I/O and get
>  back to you. -Manju
>

I wanted test your latest v12 patch series for video drivers, but without a
proper FB support it is not easy to test series for me. Can you point us to a
GIT tree where current progress is going on? I tried to scan all arago trees
but cannot find one.

Thanks,
Caglar
> ________________________________________
> From: Nori, Sekhar
> Sent: Tuesday, February 08, 2011 2:30 PM
> To: jean-philippe francois; davinci-linux-open-source at linux.davincidsp.com
> Cc: Hadli, Manjunath; Rajashekhara, Sudhakar
> Subject: RE: Recent kernel for DM365 and status of the staging tree
>
> Hi jean-philippe,
>
> On Thu, Feb 03, 2011 at 15:02:36, jean-philippe francois wrote:
> > 2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
> > > Hi,
> > >
> > > What is the status of the arago staging tree ?
> > > It once was tracking the mainline kernel without much lag, but
> > > it seems to be stuck at 2.6.34
>
> Recently a 2.6.37 based baseline was pushed[1]. This is
> work in progress and we are shooting for end-of-march
> for a full fledged kernel release on DM365 and OMAP-L138/AM18x.
>
> > > I am interested in :
> > > - video capture
> >
> > Both bayer and YUV, using USERPTR IO
> >
> > > - single-shot previewer operation
> > > - cmem, edma and all other DVSDK modules can build against it
> > > - video display (optional)
> > > - OSD (optional)
>
> cmem is not part of this kernel. This will surely become
> available as and when a DVSDK release is available based on the
> above mentioned kernel baseline. You can check on e2e.ti.com for
> updates on DVSDK roadmap.
>
> EDMA has been verified already.
>
> For updates on the other items I am CCing Manju who has been
> working on updating all the video related components.
>
> Thanks,
> Sekhar
>
> [1]
>  http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=re
> fs/heads/03.21.00.03
>
> > > I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
> > > or older kernel, because I am interested
> > > in the uvc gadget driver.
> > >
> > > What tree could be a good starting point for this ?
> >
> > _______________________________________________
> > 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
>

From jp.francois at cynove.com  Tue Feb  8 09:56:22 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Tue, 8 Feb 2011 16:56:22 +0100
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930247F50DBA@dbde02.ent.ti.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9BB6@dbde02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930247F50DBA@dbde02.ent.ti.com>
Message-ID: <AANLkTinVdBhO8BJoTekPGbYVwdJkZgiqxkLR7YQFEEnx@mail.gmail.com>

2011/2/8 Hadli, Manjunath <manjunath.hadli at ti.com>:
> Jean-Philippe,
> ?Among the Video related items you mentioned, pretty much everything is planned to be supported. I will check back on the User Pointer I/O and get back to you.
> -Manju
>
Thank you for the information, this is very interesting.
To be more precise, what is needed is a way to use the same buffer in
acquisition (V4L2 API) and as input to an encoder or the previewer,
and avoid any memcpy.

Currently (2.6.32 + DVSDK) , a buffer can be allocated using cmem, and
it can be used  within the V4L2 stack using user pointer IO.

Is that possible using mmap ? If I remember correctly, allocation
fails when working with multimegapixel input.


> ________________________________________
> From: Nori, Sekhar
> Sent: Tuesday, February 08, 2011 2:30 PM
> To: jean-philippe francois; davinci-linux-open-source at linux.davincidsp.com
> Cc: Hadli, Manjunath; Rajashekhara, Sudhakar
> Subject: RE: Recent kernel for DM365 and status of the staging tree
>
> Hi jean-philippe,
>
> On Thu, Feb 03, 2011 at 15:02:36, jean-philippe francois wrote:
>> 2011/2/3 jean-philippe francois <jp.francois at cynove.com>:
>> > Hi,
>> >
>> > What is the status of the arago staging tree ?
>> > It once was tracking the mainline kernel without much lag, but
>> > it seems to be stuck at 2.6.34
>
> Recently a 2.6.37 based baseline was pushed[1]. This is
> work in progress and we are shooting for end-of-march
> for a full fledged kernel release on DM365 and OMAP-L138/AM18x.
>
>> >
>> > I am interested in :
>> > - video capture
>> Both bayer and YUV, using USERPTR IO
>>
>> > - single-shot previewer operation
>> > - cmem, edma and all other DVSDK modules can build against it
>> > - video display (optional)
>> > - OSD (optional)
>
> cmem is not part of this kernel. This will surely become
> available as and when a DVSDK release is available based on the
> above mentioned kernel baseline. You can check on e2e.ti.com for
> updates on DVSDK roadmap.
>
> EDMA has been verified already.
>
> For updates on the other items I am CCing Manju who has been
> working on updating all the video related components.
>
> Thanks,
> Sekhar
>
> [1] http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/03.21.00.03
>
>> >
>> > I am currently using a 2.6.32 tree, but I would like to have a 2.6.35
>> > or older kernel, because I am interested
>> > in the uvc gadget driver.
>> >
>> > What tree could be a good starting point for this ?
>> >
>> _______________________________________________
>> 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 jp.francois at cynove.com  Tue Feb  8 10:06:39 2011
From: jp.francois at cynove.com (jean-philippe francois)
Date: Tue, 8 Feb 2011 17:06:39 +0100
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTikBtBURWSv6M3kX8F_Rmr7uHOxRnAHSXwjKGvtA@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B7C7@dbde02.ent.ti.com>
	<AANLkTik9MYm6pin4E=QvOnLh0uYf=USP1pUuS28SvLMk@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B867@dbde02.ent.ti.com>
	<AANLkTinSQjic73tNsd54o_h=8scjtbkf4XC==sCHMs5E@mail.gmail.com>
	<AANLkTikBtBURWSv6M3kX8F_Rmr7uHOxRnAHSXwjKGvtA@mail.gmail.com>
Message-ID: <AANLkTin9LGwH-AY8_jK4JH4irWn5A+esXeb53xD6aq-Y@mail.gmail.com>

2011/2/4 Will Kelleher <will.kelleher at nuvixa.com>:
> Hi,
>
> I also recently backported the UVC gadget (g_webcam) from 2.6.36 to
> 2.6.32. ?Where did you encounter this error? ?I'm able to load the
> module and the DM365 is detected as a UVC device by a Windows host,
> but then I am unable to add DirectShow filters to the device. ?Perhaps
> the root cause is similar?
>

I took a step back and ported the current version of uvc_gadget to 2.6.32.
In this version, endpoint size is 512, so it doesn't clash anymore with the fifo
configuration.

The cause of your problem is more likely the fact that the Video Class specific
setup request needs to be handled by userspace.


> Thanks,
>
> Will Kelleher
> Nuvixa, Inc.
>
>
>
> On Fri, Feb 4, 2011 at 7:41 AM, jean-philippe francois
> <jp.francois at cynove.com> wrote:
>> 2011/2/4 B, Ravi <ravibabu at ti.com>:
>>>
>>>> >> Hi,
>>>> >>
>>>> >> I have backported the UVC gadget patch by laurent pinchart on a custom
>>>> >> DM365 board.
>>>> >> It fails to allocate the required endpoints :
>>>> >>
>>>> >> ? ? ? ep = usb_ep_autoconfig(cdev->gadget, &uvc_streaming_ep);
>>>> >> ? ? ? if (!ep) {
>>>> >> ? ? ? ? ? ? ? INFO(cdev, "Unable to allocate streaming EP\n");
>>>> >> ? ? ? ? ? ? ? goto error;
>>>> >> ? ? ? }
>>>> >>
>>>> >> I can see the message "Unable to allocate streaming EP" in the log.
>>>> >> How can I debug / fix this ?
>>>> >>
>>>> >> The mass storage gadget is working fine.
>>>> >>
>>>> >> Here is the failing endpoint descriptor :
>>>> >>
>>>> >> static struct usb_endpoint_descriptor uvc_streaming_ep = {
>>>> >> ? ? ? .bLength ? ? ? ? ? ? ? ?= USB_DT_ENDPOINT_SIZE,
>>>> >> ? ? ? .bDescriptorType ? ? ? ?= USB_DT_ENDPOINT,
>>>> >> ? ? ? .bEndpointAddress ? ? ? = USB_DIR_IN,
>>>> >> ? ? ? .bmAttributes ? ? ? ? ? = USB_ENDPOINT_XFER_ISOC,
>>>> >> ? ? ? .wMaxPacketSize ? ? ? ? = cpu_to_le16(1024),
>>>> >> ? ? ? .bInterval ? ? ? ? ? ? ?= 1,
>>>> >> };
>>>> >>
>>>> >
>>>> > The above endpoint requires endpoint fifo size to be 1024. Check with
>>>> the fifo table entries in musb_core.c file and update as per requirement.
>>>> >
>>>>
>>>> So I can either change the fifo_mode module paramete to pick another
>>>> config, or
>>>> change the endpoint config to use a smaller packet size ?
>>>>
>>>
>>> If the UVC driver requirement may be 1024 bytes packet size, then you cannot change, what you can do is change the current fifo-mode
>>> configuration sizes as per your device requirements.
>>>
>>> For example :
>>> /* mode 4 - fits in 4KB */
>>> static struct musb_fifo_cfg __devinitdata mode_4_cfg[] = {
>>> { .hw_ep_num = ?1, .style = FIFO_TX, ? .maxpacket = 512, },
>>> { .hw_ep_num = ?1, .style = FIFO_RX, ? .maxpacket = 512, },
>>> { .hw_ep_num = ?2, .style = FIFO_TX, ? .maxpacket = 1024, },
>>> { .hw_ep_num = ?2, .style = FIFO_RX, ? .maxpacket = 1024, },
>>> { .hw_ep_num = ?3, .style = FIFO_TX, ? .maxpacket = 256, },
>>> { .hw_ep_num = ?3, .style = FIFO_RX, ? .maxpacket = 256, },
>>>
>> Thank you, I can see that more recent kernel have the possibility
>> to specify this config in platform_data, which is great !
>>
>>> Ravi
>>>
>>>> >> Jean-Philippe Fran?ois
>>>> >> _______________________________________________
>>>> >> 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
>>
>

From khilman at ti.com  Tue Feb  8 15:20:24 2011
From: khilman at ti.com (Kevin Hilman)
Date: Tue, 08 Feb 2011 13:20:24 -0800
Subject: [PATCH] davinci: tnetv107x: fix register indexing for
	GPIOs	numbers > 31
In-Reply-To: <4D43409C.9090203@ti.com> (Cyril Chemparathy's message of "Fri,
	28 Jan 2011 17:18:04 -0500")
References: <1295993126-6841-1-git-send-email-hirosh.dabui@snom.com>
	<8762t8d7jr.fsf@ti.com> <4D43409C.9090203@ti.com>
Message-ID: <8762sunrzb.fsf@ti.com>

Cyril Chemparathy <cyril at ti.com> writes:

> On 01/28/2011 04:47 PM, Hilman, Kevin wrote:
>> Hirosh Dabui <hirosh.dabui at snom.com> writes:
>> 
>>> This patch fix a bug in the register indexing for GPIOs numbers >  31
>>> to get the relevant hardware registers of tnetv107x to control the GPIOs.
>>>
> [...]
>> 
>> Thanks, applied and queuing for 2.6.39.
>> 
>
> Does this bug fix need to wait for .39?
>

Hmm, no.  It should go for .38-rc.  Will queue in davinci-fixes.

Kevin

From khilman at ti.com  Tue Feb  8 15:54:38 2011
From: khilman at ti.com (Kevin Hilman)
Date: Tue, 08 Feb 2011 13:54:38 -0800
Subject: TI DaVinci support under new maintainer: Sekhar Nori
Message-ID: <87pqr2kx9d.fsf@ti.com>

Hello,

I will be stepping aside as maintainer of the TI DaVinci family of
SoCs and Sekhar Nori from TI will be taking over these responsibilities.

Sekhar has long been an active developer, primary contributor and
reviewer so taking over the maintainer role is a logical next step for
him.

I will aid in the transition for a couple merge windows to help make a
smooth transition, but will be fading away from an active role in
davinci. 

Kevin

From khilman at ti.com  Tue Feb  8 15:58:54 2011
From: khilman at ti.com (Kevin Hilman)
Date: Tue, 08 Feb 2011 13:58:54 -0800
Subject: [PATCH v2] davinci: spi: move event queue parameter to platform
	data
In-Reply-To: <1297169995-31321-1-git-send-email-michael.williamson@criticallink.com>
	(Michael Williamson's message of "Tue, 8 Feb 2011 07:59:55 -0500")
References: <1297169995-31321-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <87k4hakx29.fsf@ti.com>

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

> For DMA operation, the davinci spi driver needs an event queue number.
> Currently, this number is passed as a IORESOURCE_DMA.  This is not
> correct, as the event queue is not a DMA channel.  Pass the event queue
> via the platform data structure instead.
>
> On dm355 and dm365, move the eventq assignment for spi0 out of resources
> array and into platform data.
>
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
> Acked-by: Sekhar Nori <nsekhar at ti.com>

With Grant's ack, will merge this through davinci tree.

Kevin

> ---
> Changes since v1:
>    - Add Sekhar's Ack.
>    - Really fix the typo.  This time for sure (blew the format patch
>      on last go around).
>
>  arch/arm/mach-davinci/dm355.c            |    5 +----
>  arch/arm/mach-davinci/dm365.c            |    5 +----
>  arch/arm/mach-davinci/include/mach/spi.h |   15 ++++++++++-----
>  drivers/spi/davinci_spi.c                |   11 +++--------
>  4 files changed, 15 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index a5f8a80..76364d1 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -403,16 +403,13 @@ static struct resource dm355_spi0_resources[] = {
>  		.start = 16,
>  		.flags = IORESOURCE_DMA,
>  	},
> -	{
> -		.start = EVENTQ_1,
> -		.flags = IORESOURCE_DMA,
> -	},
>  };
>  
>  static struct davinci_spi_platform_data dm355_spi0_pdata = {
>  	.version 	= SPI_VERSION_1,
>  	.num_chipselect = 2,
>  	.cshold_bug	= true,
> +	.dma_event_q	= EVENTQ_1,
>  };
>  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 02d2cc3..4604e72 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -625,6 +625,7 @@ 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,
> +	.dma_event_q	= EVENTQ_3,
>  };
>  
>  static struct resource dm365_spi0_resources[] = {
> @@ -645,10 +646,6 @@ static struct resource dm365_spi0_resources[] = {
>  		.start = 16,
>  		.flags = IORESOURCE_DMA,
>  	},
> -	{
> -		.start = EVENTQ_3,
> -		.flags = IORESOURCE_DMA,
> -	},
>  };
>  
>  static struct platform_device dm365_spi0_device = {
> diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
> index 38f4da5..7af305b 100644
> --- a/arch/arm/mach-davinci/include/mach/spi.h
> +++ b/arch/arm/mach-davinci/include/mach/spi.h
> @@ -19,6 +19,8 @@
>  #ifndef __ARCH_ARM_DAVINCI_SPI_H
>  #define __ARCH_ARM_DAVINCI_SPI_H
>  
> +#include <mach/edma.h>
> +
>  #define SPI_INTERN_CS	0xFF
>  
>  enum {
> @@ -39,13 +41,16 @@ enum {
>   *		to populate if all chip-selects are internal.
>   * @cshold_bug:	set this to true if the SPI controller on your chip requires
>   *		a write to CSHOLD bit in between transfers (like in DM355).
> + * @dma_event_q: DMA event queue to use if SPI_IO_TYPE_DMA is used for any
> + *		device on the bus.
>   */
>  struct davinci_spi_platform_data {
> -	u8	version;
> -	u8	num_chipselect;
> -	u8	intr_line;
> -	u8	*chip_sel;
> -	bool	cshold_bug;
> +	u8			version;
> +	u8			num_chipselect;
> +	u8			intr_line;
> +	u8			*chip_sel;
> +	bool			cshold_bug;
> +	enum dma_event_q	dma_event_q;
>  };
>  
>  /**
> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
> index 6beab99..166a879 100644
> --- a/drivers/spi/davinci_spi.c
> +++ b/drivers/spi/davinci_spi.c
> @@ -790,7 +790,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
>  	struct resource *r, *mem;
>  	resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
>  	resource_size_t	dma_tx_chan = SPI_NO_RESOURCE;
> -	resource_size_t	dma_eventq = SPI_NO_RESOURCE;
>  	int i = 0, ret = 0;
>  	u32 spipc0;
>  
> @@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device *pdev)
>  	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;
>  
>  	dspi->bitbang.txrx_bufs = davinci_spi_bufs;
>  	if (dma_rx_chan != SPI_NO_RESOURCE &&
> -	    dma_tx_chan != SPI_NO_RESOURCE &&
> -	    dma_eventq != SPI_NO_RESOURCE) {
> +	    dma_tx_chan != SPI_NO_RESOURCE) {
>  		dspi->dma.rx_channel = dma_rx_chan;
>  		dspi->dma.tx_channel = dma_tx_chan;
> -		dspi->dma.eventq = dma_eventq;
> +		dspi->dma.eventq = pdata->dma_event_q;
>  
>  		ret = davinci_spi_request_dma(dspi);
>  		if (ret)
> @@ -897,7 +892,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
>  		dev_info(&pdev->dev, "DMA: supported\n");
>  		dev_info(&pdev->dev, "DMA: RX channel: %d, TX channel: %d, "
>  				"event queue: %d\n", dma_rx_chan, dma_tx_chan,
> -				dma_eventq);
> +				pdata->dma_event_q);
>  	}
>  
>  	dspi->get_rx = davinci_spi_rx_buf_u8;

From grant.likely at secretlab.ca  Tue Feb  8 16:04:46 2011
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 8 Feb 2011 15:04:46 -0700
Subject: [PATCH v2] davinci: spi: move event queue parameter to platform
	data
In-Reply-To: <87k4hakx29.fsf@ti.com>
References: <1297169995-31321-1-git-send-email-michael.williamson@criticallink.com>
	<87k4hakx29.fsf@ti.com>
Message-ID: <AANLkTimwdYr4riFtcd1JGwVYRKXtA+XSSgjBpF8eQSV2@mail.gmail.com>

On Tue, Feb 8, 2011 at 2:58 PM, Kevin Hilman <khilman at ti.com> wrote:
> Michael Williamson <michael.williamson at criticallink.com> writes:
>
>> For DMA operation, the davinci spi driver needs an event queue number.
>> Currently, this number is passed as a IORESOURCE_DMA. ?This is not
>> correct, as the event queue is not a DMA channel. ?Pass the event queue
>> via the platform data structure instead.
>>
>> On dm355 and dm365, move the eventq assignment for spi0 out of resources
>> array and into platform data.
>>
>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>> Acked-by: Sekhar Nori <nsekhar at ti.com>
>
> With Grant's ack, will merge this through davinci tree.

Acked-by: Grant Likely <grant.likely at secretlab.ca>

>
> Kevin
>
>> ---
>> Changes since v1:
>> ? ?- Add Sekhar's Ack.
>> ? ?- Really fix the typo. ?This time for sure (blew the format patch
>> ? ? ?on last go around).
>>
>> ?arch/arm/mach-davinci/dm355.c ? ? ? ? ? ?| ? ?5 +----
>> ?arch/arm/mach-davinci/dm365.c ? ? ? ? ? ?| ? ?5 +----
>> ?arch/arm/mach-davinci/include/mach/spi.h | ? 15 ++++++++++-----
>> ?drivers/spi/davinci_spi.c ? ? ? ? ? ? ? ?| ? 11 +++--------
>> ?4 files changed, 15 insertions(+), 21 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
>> index a5f8a80..76364d1 100644
>> --- a/arch/arm/mach-davinci/dm355.c
>> +++ b/arch/arm/mach-davinci/dm355.c
>> @@ -403,16 +403,13 @@ static struct resource dm355_spi0_resources[] = {
>> ? ? ? ? ? ? ? .start = 16,
>> ? ? ? ? ? ? ? .flags = IORESOURCE_DMA,
>> ? ? ? },
>> - ? ? {
>> - ? ? ? ? ? ? .start = EVENTQ_1,
>> - ? ? ? ? ? ? .flags = IORESOURCE_DMA,
>> - ? ? },
>> ?};
>>
>> ?static struct davinci_spi_platform_data dm355_spi0_pdata = {
>> ? ? ? .version ? ? ? ?= SPI_VERSION_1,
>> ? ? ? .num_chipselect = 2,
>> ? ? ? .cshold_bug ? ? = true,
>> + ? ? .dma_event_q ? ?= EVENTQ_1,
>> ?};
>> ?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 02d2cc3..4604e72 100644
>> --- a/arch/arm/mach-davinci/dm365.c
>> +++ b/arch/arm/mach-davinci/dm365.c
>> @@ -625,6 +625,7 @@ 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,
>> + ? ? .dma_event_q ? ?= EVENTQ_3,
>> ?};
>>
>> ?static struct resource dm365_spi0_resources[] = {
>> @@ -645,10 +646,6 @@ static struct resource dm365_spi0_resources[] = {
>> ? ? ? ? ? ? ? .start = 16,
>> ? ? ? ? ? ? ? .flags = IORESOURCE_DMA,
>> ? ? ? },
>> - ? ? {
>> - ? ? ? ? ? ? .start = EVENTQ_3,
>> - ? ? ? ? ? ? .flags = IORESOURCE_DMA,
>> - ? ? },
>> ?};
>>
>> ?static struct platform_device dm365_spi0_device = {
>> diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
>> index 38f4da5..7af305b 100644
>> --- a/arch/arm/mach-davinci/include/mach/spi.h
>> +++ b/arch/arm/mach-davinci/include/mach/spi.h
>> @@ -19,6 +19,8 @@
>> ?#ifndef __ARCH_ARM_DAVINCI_SPI_H
>> ?#define __ARCH_ARM_DAVINCI_SPI_H
>>
>> +#include <mach/edma.h>
>> +
>> ?#define SPI_INTERN_CS ? ? ? ?0xFF
>>
>> ?enum {
>> @@ -39,13 +41,16 @@ enum {
>> ? * ? ? ? ? ? to populate if all chip-selects are internal.
>> ? * @cshold_bug: ? ? ?set this to true if the SPI controller on your chip requires
>> ? * ? ? ? ? ? a write to CSHOLD bit in between transfers (like in DM355).
>> + * @dma_event_q: DMA event queue to use if SPI_IO_TYPE_DMA is used for any
>> + * ? ? ? ? ? device on the bus.
>> ? */
>> ?struct davinci_spi_platform_data {
>> - ? ? u8 ? ? ?version;
>> - ? ? u8 ? ? ?num_chipselect;
>> - ? ? u8 ? ? ?intr_line;
>> - ? ? u8 ? ? ?*chip_sel;
>> - ? ? bool ? ?cshold_bug;
>> + ? ? u8 ? ? ? ? ? ? ? ? ? ? ?version;
>> + ? ? u8 ? ? ? ? ? ? ? ? ? ? ?num_chipselect;
>> + ? ? u8 ? ? ? ? ? ? ? ? ? ? ?intr_line;
>> + ? ? u8 ? ? ? ? ? ? ? ? ? ? ?*chip_sel;
>> + ? ? bool ? ? ? ? ? ? ? ? ? ?cshold_bug;
>> + ? ? enum dma_event_q ? ? ? ?dma_event_q;
>> ?};
>>
>> ?/**
>> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
>> index 6beab99..166a879 100644
>> --- a/drivers/spi/davinci_spi.c
>> +++ b/drivers/spi/davinci_spi.c
>> @@ -790,7 +790,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
>> ? ? ? struct resource *r, *mem;
>> ? ? ? resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
>> ? ? ? resource_size_t dma_tx_chan = SPI_NO_RESOURCE;
>> - ? ? resource_size_t dma_eventq = SPI_NO_RESOURCE;
>> ? ? ? int i = 0, ret = 0;
>> ? ? ? u32 spipc0;
>>
>> @@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device *pdev)
>> ? ? ? 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;
>>
>> ? ? ? dspi->bitbang.txrx_bufs = davinci_spi_bufs;
>> ? ? ? if (dma_rx_chan != SPI_NO_RESOURCE &&
>> - ? ? ? ? dma_tx_chan != SPI_NO_RESOURCE &&
>> - ? ? ? ? dma_eventq != SPI_NO_RESOURCE) {
>> + ? ? ? ? dma_tx_chan != SPI_NO_RESOURCE) {
>> ? ? ? ? ? ? ? dspi->dma.rx_channel = dma_rx_chan;
>> ? ? ? ? ? ? ? dspi->dma.tx_channel = dma_tx_chan;
>> - ? ? ? ? ? ? dspi->dma.eventq = dma_eventq;
>> + ? ? ? ? ? ? dspi->dma.eventq = pdata->dma_event_q;
>>
>> ? ? ? ? ? ? ? ret = davinci_spi_request_dma(dspi);
>> ? ? ? ? ? ? ? if (ret)
>> @@ -897,7 +892,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
>> ? ? ? ? ? ? ? dev_info(&pdev->dev, "DMA: supported\n");
>> ? ? ? ? ? ? ? dev_info(&pdev->dev, "DMA: RX channel: %d, TX channel: %d, "
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "event queue: %d\n", dma_rx_chan, dma_tx_chan,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? dma_eventq);
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? pdata->dma_event_q);
>> ? ? ? }
>>
>> ? ? ? dspi->get_rx = davinci_spi_rx_buf_u8;
>



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

From michael.williamson at criticallink.com  Wed Feb  9 07:11:48 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed,  9 Feb 2011 08:11:48 -0500
Subject: [PATCH v2 0/6] davinci: Add SPI support for da8xx platforms
Message-ID: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>

This patch series adds the necessary SPI resources and registration
routines for da850/OMAP-L138/AM18x and da830/OMAP-L137/AM17x devices.
It also adds on-board SPI FLASH devices for the da830 evm, the da850
evm, and the MityDSP-L138/MityARM-1808 platforms.

These patches are based on work done during testing of davinci SPI driver
submissions incorporated in version 2.6.38 of the kernel, at [1].

The da850 and da830 EVM portions of this patch need verification / ack.

The MityDSP-L138 platform patch has been tested.

The patch series is against linux-davinci tree, but is dependent on the 
patches [2] (approved, but not applied) and [3] (submitted 2/3/2011), which 
were generated as a result of initial review of this series.

[1] http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite
[2] https://patchwork.kernel.org/patch/540831/
[3] https://patchwork.kernel.org/patch/530471/

---
Changes since v1:
   - move event queue parameter to platform data structures
   - move magic numbers to #defines
   - rename da830 spi clock name to match driver
   - clarify patch description for resource additions per comments

Michael Williamson (4):
  davinci: da830: fix driver name for spi clocks
  davinci: da850: add spi device clock definitions
  davinci: da8xx: add spi resources and registration routine
  davinci: add spi devices support for MityDSP-L138/MityARM-1808
    platform

Sekhar Nori (2):
  davinci: add spi devices support for da850/omap-l138/am18x evm
  davinci: add spi devices support for da830/omap-l137/am17x evm

 arch/arm/mach-davinci/board-da830-evm.c    |   78 ++++++++++++++++++++++
 arch/arm/mach-davinci/board-da850-evm.c    |   84 +++++++++++++++++++++++
 arch/arm/mach-davinci/board-mityomapl138.c |  100 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/da830.c              |    4 +-
 arch/arm/mach-davinci/da850.c              |   16 +++++
 arch/arm/mach-davinci/devices-da8xx.c      |   98 +++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 7 files changed, 381 insertions(+), 2 deletions(-)


From michael.williamson at criticallink.com  Wed Feb  9 07:11:49 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed,  9 Feb 2011 08:11:49 -0500
Subject: [PATCH v2 1/6] davinci: da830: fix driver name for spi clocks
In-Reply-To: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1297257114-764-2-git-send-email-michael.williamson@criticallink.com>

The spi driver name called out for the da830 spi clock list is not correct,
fix it.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/da830.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index ec23ab4..826118e 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -397,8 +397,8 @@ static struct clk_lookup da830_clks[] = {
 	CLK(NULL,		"uart0",	&uart0_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
-	CLK("dm_spi.0",		NULL,		&spi0_clk),
-	CLK("dm_spi.1",		NULL,		&spi1_clk),
+	CLK("spi_davinci.0",	NULL,		&spi0_clk),
+	CLK("spi_davinci.1",	NULL,		&spi1_clk),
 	CLK(NULL,		"ecap0",	&ecap0_clk),
 	CLK(NULL,		"ecap1",	&ecap1_clk),
 	CLK(NULL,		"ecap2",	&ecap2_clk),
-- 
1.7.0.4


From michael.williamson at criticallink.com  Wed Feb  9 07:11:50 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed,  9 Feb 2011 08:11:50 -0500
Subject: [PATCH v2 2/6] davinci: da850: add spi device clock definitions
In-Reply-To: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1297257114-764-3-git-send-email-michael.williamson@criticallink.com>

Add spi clock information for da850.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/da850.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..68fe4c2 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -359,6 +359,20 @@ static struct clk usb20_clk = {
 	.gpsc		= 1,
 };
 
+static struct clk spi0_clk = {
+	.name		= "spi0",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_SPI0,
+};
+
+static struct clk spi1_clk = {
+	.name		= "spi1",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_SPI1,
+	.gpsc		= 1,
+	.flags		= DA850_CLK_ASYNC3,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -403,6 +417,8 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"aemif",	&aemif_clk),
 	CLK(NULL,		"usb11",	&usb11_clk),
 	CLK(NULL,		"usb20",	&usb20_clk),
+	CLK("spi_davinci.0",	NULL,		&spi0_clk),
+	CLK("spi_davinci.1",	NULL,		&spi1_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
-- 
1.7.0.4


From michael.williamson at criticallink.com  Wed Feb  9 07:11:51 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed,  9 Feb 2011 08:11:51 -0500
Subject: [PATCH v2 3/6] davinci: da8xx: add spi resources and registration
	routine
In-Reply-To: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1297257114-764-4-git-send-email-michael.williamson@criticallink.com>

Add IO resource structures, platform data, and a registration
routine in order to support spi device on DA850/OMAP-L138/AM18x
and DA830/OMAP-L137/AM17x platforms.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/devices-da8xx.c      |   98 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 2 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 119d46e..b72399a 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -38,14 +38,20 @@
 #define DA8XX_EMAC_MDIO_BASE		0x01e24000
 #define DA8XX_GPIO_BASE			0x01e26000
 #define DA8XX_I2C1_BASE			0x01e28000
+#define DA8XX_SPI0_BASE			0x01c41000
+#define DA8XX_SPI1_BASE			0x01f0e000
 
 #define DA8XX_EMAC_CTRL_REG_OFFSET	0x3000
 #define DA8XX_EMAC_MOD_REG_OFFSET	0x2000
 #define DA8XX_EMAC_RAM_OFFSET		0x0000
 #define DA8XX_EMAC_CTRL_RAM_SIZE	SZ_8K
 
+#define DA8XX_DMA_SPI0_RX	EDMA_CTLR_CHAN(0, 14)
+#define DA8XX_DMA_SPI0_TX	EDMA_CTLR_CHAN(0, 15)
 #define DA8XX_DMA_MMCSD0_RX	EDMA_CTLR_CHAN(0, 16)
 #define DA8XX_DMA_MMCSD0_TX	EDMA_CTLR_CHAN(0, 17)
+#define DA8XX_DMA_SPI1_RX	EDMA_CTLR_CHAN(0, 18)
+#define DA8XX_DMA_SPI1_TX	EDMA_CTLR_CHAN(0, 19)
 #define DA850_DMA_MMCSD1_RX	EDMA_CTLR_CHAN(1, 28)
 #define DA850_DMA_MMCSD1_TX	EDMA_CTLR_CHAN(1, 29)
 
@@ -730,3 +736,95 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+
+static struct resource da8xx_spi0_resources[] = {
+	[0] = {
+		.start	= DA8XX_SPI0_BASE,
+		.end	= DA8XX_SPI0_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_DA8XX_SPINT0,
+		.end	= IRQ_DA8XX_SPINT0,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		.start	= DA8XX_DMA_SPI0_RX,
+		.end	= DA8XX_DMA_SPI0_RX,
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		.start	= DA8XX_DMA_SPI0_TX,
+		.end	= DA8XX_DMA_SPI0_TX,
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+static struct resource da8xx_spi1_resources[] = {
+	[0] = {
+		.start	= DA8XX_SPI1_BASE,
+		.end	= DA8XX_SPI1_BASE + SZ_4K -1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_DA8XX_SPINT1,
+		.end	= IRQ_DA8XX_SPINT1,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		.start	= DA8XX_DMA_SPI1_RX,
+		.end	= DA8XX_DMA_SPI1_RX,
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		.start	= DA8XX_DMA_SPI1_TX,
+		.end	= DA8XX_DMA_SPI1_TX,
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+struct davinci_spi_platform_data da8xx_spi_pdata[] = {
+	[0] = {
+		.version	= SPI_VERSION_2,
+		.intr_line	= 1,
+		.dma_event_q	= EVENTQ_0,
+	},
+	[1] = {
+		.version	= SPI_VERSION_2,
+		.intr_line	= 1,
+		.dma_event_q	= EVENTQ_0,
+	},
+};
+
+static struct platform_device da8xx_spi_device[] = {
+	[0] = {
+		.name		= "spi_davinci",
+		.id		= 0,
+		.num_resources	= ARRAY_SIZE(da8xx_spi0_resources),
+		.resource	= da8xx_spi0_resources,
+		.dev		= {
+			.platform_data = &da8xx_spi_pdata[0],
+		},
+	},
+	[1] = {
+		.name		= "spi_davinci",
+		.id		= 1,
+		.num_resources	= ARRAY_SIZE(da8xx_spi1_resources),
+		.resource	= da8xx_spi1_resources,
+		.dev		= {
+			.platform_data = &da8xx_spi_pdata[1],
+		},
+	},
+};
+
+int __init da8xx_register_spi(int instance)
+{
+	struct platform_device *pdev;
+
+	if (instance == 0 || instance == 1)
+		pdev = &da8xx_spi_device[instance];
+	else
+		return -EINVAL;
+
+	return platform_device_register(pdev);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..0c5fa01 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -23,6 +23,7 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 #include <mach/pm.h>
+#include <mach/spi.h>
 
 extern void __iomem *da8xx_syscfg0_base;
 extern void __iomem *da8xx_syscfg1_base;
@@ -77,6 +78,7 @@ void __init da850_init(void);
 int da830_register_edma(struct edma_rsv_info *rsv);
 int da850_register_edma(struct edma_rsv_info *rsv[2]);
 int da8xx_register_i2c(int instance, struct davinci_i2c_platform_data *pdata);
+int da8xx_register_spi(int instance);
 int da8xx_register_watchdog(void);
 int da8xx_register_usb20(unsigned mA, unsigned potpgt);
 int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
@@ -95,6 +97,7 @@ extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
+extern struct davinci_spi_platform_data da8xx_spi_pdata[];
 
 extern struct platform_device da8xx_wdt_device;
 
-- 
1.7.0.4


From michael.williamson at criticallink.com  Wed Feb  9 07:11:52 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed,  9 Feb 2011 08:11:52 -0500
Subject: [PATCH v2 4/6] davinci: add spi devices support for
	MityDSP-L138/MityARM-1808 platform
In-Reply-To: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1297257114-764-5-git-send-email-michael.williamson@criticallink.com>

This patch adds support for accessing the on board SPI NOR FLASH
device for MityDSP-L138 and MityARM-1808 SoMs.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Tested-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-mityomapl138.c |  100 ++++++++++++++++++++++++++++
 1 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 0ea5932..dc4c3f1 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -17,6 +17,8 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/etherdevice.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -25,6 +27,7 @@
 #include <mach/da8xx.h>
 #include <mach/nand.h>
 #include <mach/mux.h>
+#include <mach/spi.h>
 
 #define MITYOMAPL138_PHY_ID		"0:03"
 
@@ -294,6 +297,100 @@ static int __init pmic_tps65023_init(void)
 }
 
 /*
+ * SPI Devices:
+ *	SPI1_CS0: 8M Flash ST-M25P64-VME6G
+ */
+static struct mtd_partition spi_flash_partitions[] = {
+	[0] = {
+		.name		= "ubl",
+		.offset		= 0,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[1] = {
+		.name		= "u-boot",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_512K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[2] = {
+		.name		= "u-boot-env",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[3] = {
+		.name		= "periph-config",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[4] = {
+		.name		= "reserved",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_256K + SZ_64K,
+	},
+	[5] = {
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M + SZ_1M,
+	},
+	[6] = {
+		.name		= "fpga",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M,
+	},
+	[7] = {
+		.name		= "spare",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+	},
+};
+
+static struct flash_platform_data mityomapl138_spi_flash_data = {
+	.name		= "m25p80",
+	.parts		= spi_flash_partitions,
+	.nr_parts	= ARRAY_SIZE(spi_flash_partitions),
+	.type		= "m24p64",
+};
+
+static struct davinci_spi_config spi_eprom_config = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info mityomapl138_spi_flash_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &mityomapl138_spi_flash_data,
+		.controller_data	= &spi_eprom_config,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 1,
+		.chip_select		= 0,
+	},
+};
+
+static void __init mityomapl138_init_spi1(struct spi_board_info *info,
+					  unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("%s: failed to register board info : %d\n",
+				__func__, ret);
+
+	da8xx_spi_pdata[1].num_chipselect = len;
+
+	ret = da8xx_register_spi(1);
+	if (ret)
+		pr_warning("%s: failed to register spi 1 device : %d\n",
+				__func__, ret);
+}
+
+/*
  * MityDSP-L138 includes a 256 MByte large-page NAND flash
  * (128K blocks).
  */
@@ -448,6 +545,9 @@ static void __init mityomapl138_init(void)
 
 	mityomapl138_setup_nand();
 
+	mityomapl138_init_spi1(mityomapl138_spi_flash_info,
+			       ARRAY_SIZE(mityomapl138_spi_flash_info));
+
 	mityomapl138_config_emac();
 
 	ret = da8xx_register_rtc();
-- 
1.7.0.4


From michael.williamson at criticallink.com  Wed Feb  9 07:11:53 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed,  9 Feb 2011 08:11:53 -0500
Subject: [PATCH v2 5/6] davinci: add spi devices support for
	da850/omap-l138/am18x evm
In-Reply-To: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1297257114-764-6-git-send-email-michael.williamson@criticallink.com>

From: Sekhar Nori <nsekhar at ti.com>

This patch adds the on-board SPI flash device to the
DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
device to the MTD subsystem.

Based on SPI flash device support for MityDSP-L138F platform.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da850_evm_spi1_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   84 +++++++++++++++++++++++++++++++
 1 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..487bd3a 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,8 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/tps6507x.h>
 #include <linux/input/tps6507x-ts.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -38,6 +40,7 @@
 #include <mach/nand.h>
 #include <mach/mux.h>
 #include <mach/aemif.h>
+#include <mach/spi.h>
 
 #define DA850_EVM_PHY_ID		"0:00"
 #define DA850_LCD_PWR_PIN		GPIO_TO_PIN(2, 8)
@@ -48,6 +51,85 @@
 
 #define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
 
+static struct mtd_partition da850evm_spiflash_part[] = {
+	[0] = {
+		.name = "UBL",
+		.offset = 0,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[1] = {
+		.name = "U-Boot",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_512K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[2] = {
+		.name = "U-Boot-Env",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[3] = {
+		.name = "Kernel",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_2M + SZ_512K,
+		.mask_flags = 0,
+	},
+	[4] = {
+		.name = "Filesystem",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_4M,
+		.mask_flags = 0,
+	},
+	[5] = {
+		.name = "MAC-Address",
+		.offset = SZ_8M - SZ_64K,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+};
+
+static struct flash_platform_data da850evm_spiflash_data = {
+	.name		= "m25p80",
+	.parts		= da850evm_spiflash_part,
+	.nr_parts	= ARRAY_SIZE(da850evm_spiflash_part),
+	.type		= "m25p64",
+};
+
+static struct davinci_spi_config da850evm_spiflash_cfg = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info da850evm_spi_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &da850evm_spiflash_data,
+		.controller_data	= &da850evm_spiflash_cfg,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 1,
+		.chip_select		= 0,
+	},
+};
+
+static void __init da850evm_init_spi1(struct spi_board_info *info, unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("failed to register board info : %d\n", ret);
+
+	da8xx_spi_pdata[1].num_chipselect = len;
+
+	ret = da8xx_register_spi(1);
+	if (ret)
+		pr_warning("failed to register spi 1 device : %d\n", ret);
+}
+
 static struct mtd_partition da850_evm_norflash_partition[] = {
 	{
 		.name           = "bootloaders + env",
@@ -1167,6 +1249,8 @@ static __init void da850_evm_init(void)
 	if (ret)
 		pr_warning("da850_evm_init: suspend registration failed: %d\n",
 				ret);
+
+	da850evm_init_spi1(da850evm_spi_info, ARRAY_SIZE(da850evm_spi_info));
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.0.4


From michael.williamson at criticallink.com  Wed Feb  9 07:11:54 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed,  9 Feb 2011 08:11:54 -0500
Subject: [PATCH v2 6/6] davinci: add spi devices support for
	da830/omap-l137/am17x evm
In-Reply-To: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1297257114-764-7-git-send-email-michael.williamson@criticallink.com>

From: Sekhar Nori <nsekhar at ti.com>

This patch adds the on-board SPI flash device to the
DA830/OMAP-L137/AM17x EVM. It also registers the SPI flash
device to the MTD subsystem.

Based on SPI flash device support for MityDSP-L138F platform.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da830evm_spi0_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-da830-evm.c |   78 +++++++++++++++++++++++++++++++
 1 files changed, 78 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index b52a3a1..01319bd 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -20,6 +20,8 @@
 #include <linux/i2c/at24.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -30,6 +32,7 @@
 #include <mach/da8xx.h>
 #include <mach/usb.h>
 #include <mach/aemif.h>
+#include <mach/spi.h>
 
 #define DA830_EVM_PHY_ID		""
 /*
@@ -534,6 +537,79 @@ static struct edma_rsv_info da830_edma_rsv[] = {
 	},
 };
 
+static struct mtd_partition da830evm_spiflash_part[] = {
+	[0] = {
+		.name = "DSP-UBL",
+		.offset = 0,
+		.size = SZ_8K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[1] = {
+		.name = "ARM-UBL",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_16K + SZ_8K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[2] = {
+		.name = "U-Boot",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_256K - SZ_32K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[3] = {
+		.name = "U-Boot-Environment",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_16K,
+		.mask_flags = 0,
+	},
+	[4] = {
+		.name = "Kernel",
+		.offset = MTDPART_OFS_APPEND,
+		.size = MTDPART_SIZ_FULL,
+		.mask_flags = 0,
+	},
+};
+
+static struct flash_platform_data da830evm_spiflash_data = {
+	.name		= "m25p80",
+	.parts		= da830evm_spiflash_part,
+	.nr_parts	= ARRAY_SIZE(da830evm_spiflash_part),
+	.type		= "w25x32",
+};
+
+static struct davinci_spi_config da830evm_spiflash_cfg = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info da830evm_spi_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &da830evm_spiflash_data,
+		.controller_data	= &da830evm_spiflash_cfg,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 0,
+		.chip_select		= 0,
+	},
+};
+
+static void __init da830evm_init_spi0(struct spi_board_info *info, unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("failed to register board info : %d\n", ret);
+
+	da8xx_spi_pdata[0].num_chipselect = len;
+
+	ret = da8xx_register_spi(0);
+	if (ret)
+		pr_warning("failed to register spi 0 device : %d\n", ret);
+}
+
 static __init void da830_evm_init(void)
 {
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -590,6 +666,8 @@ static __init void da830_evm_init(void)
 	ret = da8xx_register_rtc();
 	if (ret)
 		pr_warning("da830_evm_init: rtc setup failed: %d\n", ret);
+
+	da830evm_init_spi0(da830evm_spi_info, ARRAY_SIZE(da830evm_spi_info));
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.0.4


From vaibhav.bedia at ti.com  Wed Feb  9 07:09:54 2011
From: vaibhav.bedia at ti.com (Vaibhav Bedia)
Date: Wed,  9 Feb 2011 18:39:54 +0530
Subject: [PATCH v2 3/3] ASoC: Davinci: Replace usage of IO_ADDRESS with
	ioremap()
In-Reply-To: <1297256994-17137-2-git-send-email-vaibhav.bedia@ti.com>
References: <1297256994-17137-1-git-send-email-vaibhav.bedia@ti.com>
	<1297256994-17137-2-git-send-email-vaibhav.bedia@ti.com>
Message-ID: <1297256994-17137-3-git-send-email-vaibhav.bedia@ti.com>

This patch modifies the Davinci i2s and mcasp drivers to make use of
ioremap() instead of IO_ADDRESS()

Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
---

v2:
Don't call iounmap when ioremap has failed.

Other comments from Sergie on the previous patch has been incorporated in a different patch.

v1:
http://thread.gmane.org/gmane.linux.alsa.devel/80120

 sound/soc/davinci/davinci-i2s.c   |   19 +++++++++++++------
 sound/soc/davinci/davinci-mcasp.c |   20 ++++++++++++++------
 2 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index e763d58..d0d60b8 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -694,20 +694,25 @@ static int davinci_i2s_probe(struct platform_device *pdev)
 	}
 	clk_enable(dev->clk);
 
-	dev->base = (void __iomem *)IO_ADDRESS(mem->start);
+	dev->base = ioremap(mem->start, resource_size(mem));
+	if (!dev->base) {
+		dev_err(&pdev->dev, "ioremap failed\n");
+		ret = -ENOMEM;
+		goto err_release_clk;
+	}
 
 	dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK].dma_addr =
-	    (dma_addr_t)(io_v2p(dev->base) + DAVINCI_MCBSP_DXR_REG);
+	    (dma_addr_t)(mem->start + DAVINCI_MCBSP_DXR_REG);
 
 	dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].dma_addr =
-	    (dma_addr_t)(io_v2p(dev->base) + DAVINCI_MCBSP_DRR_REG);
+	    (dma_addr_t)(mem->start + DAVINCI_MCBSP_DRR_REG);
 
 	/* first TX, then RX */
 	res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
 	if (!res) {
 		dev_err(&pdev->dev, "no DMA resource\n");
 		ret = -ENXIO;
-		goto err_release_clk;
+		goto err_iounmap;
 	}
 	dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK].channel = res->start;
 
@@ -715,7 +720,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
 	if (!res) {
 		dev_err(&pdev->dev, "no DMA resource\n");
 		ret = -ENXIO;
-		goto err_release_clk;
+		goto err_iounmap;
 	}
 	dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = res->start;
 	dev->dev = &pdev->dev;
@@ -724,10 +729,12 @@ static int davinci_i2s_probe(struct platform_device *pdev)
 
 	ret = snd_soc_register_dai(&pdev->dev, &davinci_i2s_dai);
 	if (ret != 0)
-		goto err_release_clk;
+		goto err_iounmap;
 
 	return 0;
 
+err_iounmap:
+	iounmap(dev->base);
 err_release_clk:
 	clk_disable(dev->clk);
 	clk_put(dev->clk);
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
index e7ae621..a5af834 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -885,7 +885,13 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	clk_enable(dev->clk);
 	dev->clk_active = 1;
 
-	dev->base = (void __iomem *)IO_ADDRESS(mem->start);
+	dev->base = ioremap(mem->start, resource_size(mem));
+	if (!dev->base) {
+		dev_err(&pdev->dev, "ioremap failed\n");
+		ret = -ENOMEM;
+		goto err_release_clk;
+	}
+
 	dev->op_mode = pdata->op_mode;
 	dev->tdm_slots = pdata->tdm_slots;
 	dev->num_serializer = pdata->num_serializer;
@@ -899,14 +905,14 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	dma_data->asp_chan_q = pdata->asp_chan_q;
 	dma_data->ram_chan_q = pdata->ram_chan_q;
 	dma_data->dma_addr = (dma_addr_t) (pdata->tx_dma_offset +
-							io_v2p(dev->base));
+							mem->start);
 
 	/* first TX, then RX */
 	res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
 	if (!res) {
 		dev_err(&pdev->dev, "no DMA resource\n");
 		ret = -ENODEV;
-		goto err_release_clk;
+		goto err_iounmap;
 	}
 
 	dma_data->channel = res->start;
@@ -915,13 +921,13 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	dma_data->asp_chan_q = pdata->asp_chan_q;
 	dma_data->ram_chan_q = pdata->ram_chan_q;
 	dma_data->dma_addr = (dma_addr_t)(pdata->rx_dma_offset +
-							io_v2p(dev->base));
+							mem->start);
 
 	res = platform_get_resource(pdev, IORESOURCE_DMA, 1);
 	if (!res) {
 		dev_err(&pdev->dev, "no DMA resource\n");
 		ret = -ENODEV;
-		goto err_release_clk;
+		goto err_iounmap;
 	}
 
 	dma_data->channel = res->start;
@@ -929,9 +935,11 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	ret = snd_soc_register_dai(&pdev->dev, &davinci_mcasp_dai[pdata->op_mode]);
 
 	if (ret != 0)
-		goto err_release_clk;
+		goto err_iounmap;
 	return 0;
 
+err_iounmap:
+	iounmap(dev->base);
 err_release_clk:
 	clk_disable(dev->clk);
 	clk_put(dev->clk);
-- 
1.6.2.4


From vaibhav.bedia at ti.com  Wed Feb  9 07:09:52 2011
From: vaibhav.bedia at ti.com (Vaibhav Bedia)
Date: Wed,  9 Feb 2011 18:39:52 +0530
Subject: [PATCH 1/3] ASoC: Davinci: Use resource_size() helper function
Message-ID: <1297256994-17137-1-git-send-email-vaibhav.bedia@ti.com>

This patch modifies the Davinci i2s and mcasp drivers
to make use of the resource_size() helper function for readability.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
---
 sound/soc/davinci/davinci-i2s.c   |    6 +++---
 sound/soc/davinci/davinci-mcasp.c |    6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index 9e0e565..f8c8487 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -658,7 +658,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	ioarea = request_mem_region(mem->start, (mem->end - mem->start) + 1,
+	ioarea = request_mem_region(mem->start, resource_size(mem),
 				    pdev->name);
 	if (!ioarea) {
 		dev_err(&pdev->dev, "McBSP region already claimed\n");
@@ -731,7 +731,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
 err_free_mem:
 	kfree(dev);
 err_release_region:
-	release_mem_region(mem->start, (mem->end - mem->start) + 1);
+	release_mem_region(mem->start, resource_size(mem));
 
 	return ret;
 }
@@ -747,7 +747,7 @@ static int davinci_i2s_remove(struct platform_device *pdev)
 	dev->clk = NULL;
 	kfree(dev);
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	release_mem_region(mem->start, (mem->end - mem->start) + 1);
+	release_mem_region(mem->start, resource_size(mem));
 
 	return 0;
 }
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
index fb55d2c..9b5d5ca 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -868,7 +868,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	}
 
 	ioarea = request_mem_region(mem->start,
-			(mem->end - mem->start) + 1, pdev->name);
+			resource_size(mem), pdev->name);
 	if (!ioarea) {
 		dev_err(&pdev->dev, "Audio region already claimed\n");
 		ret = -EBUSY;
@@ -933,7 +933,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	return 0;
 
 err_release_region:
-	release_mem_region(mem->start, (mem->end - mem->start) + 1);
+	release_mem_region(mem->start, resource_size(mem));
 err_release_data:
 	kfree(dev);
 
@@ -951,7 +951,7 @@ static int davinci_mcasp_remove(struct platform_device *pdev)
 	dev->clk = NULL;
 
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	release_mem_region(mem->start, (mem->end - mem->start) + 1);
+	release_mem_region(mem->start, resource_size(mem));
 
 	kfree(dev);
 
-- 
1.6.2.4


From vaibhav.bedia at ti.com  Wed Feb  9 07:09:53 2011
From: vaibhav.bedia at ti.com (Vaibhav Bedia)
Date: Wed,  9 Feb 2011 18:39:53 +0530
Subject: [PATCH 2/3] ASoC: Davinci: Call clk_disable() and clk_put() in case
	of error
In-Reply-To: <1297256994-17137-1-git-send-email-vaibhav.bedia@ti.com>
References: <1297256994-17137-1-git-send-email-vaibhav.bedia@ti.com>
Message-ID: <1297256994-17137-2-git-send-email-vaibhav.bedia@ti.com>

In case of any error in probe() function, clk_disable() and clk_put()
should be called if clk_enable() and clk_get() went through.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
---
 sound/soc/davinci/davinci-i2s.c   |    9 ++++++---
 sound/soc/davinci/davinci-mcasp.c |    9 ++++++---
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index f8c8487..e763d58 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -707,7 +707,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
 	if (!res) {
 		dev_err(&pdev->dev, "no DMA resource\n");
 		ret = -ENXIO;
-		goto err_free_mem;
+		goto err_release_clk;
 	}
 	dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK].channel = res->start;
 
@@ -715,7 +715,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
 	if (!res) {
 		dev_err(&pdev->dev, "no DMA resource\n");
 		ret = -ENXIO;
-		goto err_free_mem;
+		goto err_release_clk;
 	}
 	dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = res->start;
 	dev->dev = &pdev->dev;
@@ -724,10 +724,13 @@ static int davinci_i2s_probe(struct platform_device *pdev)
 
 	ret = snd_soc_register_dai(&pdev->dev, &davinci_i2s_dai);
 	if (ret != 0)
-		goto err_free_mem;
+		goto err_release_clk;
 
 	return 0;
 
+err_release_clk:
+	clk_disable(dev->clk);
+	clk_put(dev->clk);
 err_free_mem:
 	kfree(dev);
 err_release_region:
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
index 9b5d5ca..e7ae621 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -906,7 +906,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	if (!res) {
 		dev_err(&pdev->dev, "no DMA resource\n");
 		ret = -ENODEV;
-		goto err_release_region;
+		goto err_release_clk;
 	}
 
 	dma_data->channel = res->start;
@@ -921,7 +921,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	if (!res) {
 		dev_err(&pdev->dev, "no DMA resource\n");
 		ret = -ENODEV;
-		goto err_release_region;
+		goto err_release_clk;
 	}
 
 	dma_data->channel = res->start;
@@ -929,9 +929,12 @@ static int davinci_mcasp_probe(struct platform_device *pdev)
 	ret = snd_soc_register_dai(&pdev->dev, &davinci_mcasp_dai[pdata->op_mode]);
 
 	if (ret != 0)
-		goto err_release_region;
+		goto err_release_clk;
 	return 0;
 
+err_release_clk:
+	clk_disable(dev->clk);
+	clk_put(dev->clk);
 err_release_region:
 	release_mem_region(mem->start, resource_size(mem));
 err_release_data:
-- 
1.6.2.4


From gary at mlbassoc.com  Wed Feb  9 09:11:43 2011
From: gary at mlbassoc.com (Gary Thomas)
Date: Wed, 09 Feb 2011 08:11:43 -0700
Subject: MMC/SD1 on OMAP-L138
In-Reply-To: <AANLkTimEXesd-27y845r6fxFmmt+y=62XYU8=L5YPDA2@mail.gmail.com>
References: <4D4707AD.7070209@mlbassoc.com>	<AANLkTikhfOBMMdffk36xkv0Es95RHQP1=Q39PYPbj3KA@mail.gmail.com>	<AANLkTim2tmn4ppSS1b8vwRRwp71QPiwA0w2Eb44QN=bg@mail.gmail.com>
	<AANLkTimEXesd-27y845r6fxFmmt+y=62XYU8=L5YPDA2@mail.gmail.com>
Message-ID: <4D52AEAF.5060402@mlbassoc.com>

On 01/31/2011 02:49 PM, Juha Kuikka wrote:
> On Mon, Jan 31, 2011 at 11:47 AM, Steve Chen <schen at mvista.com <mailto:schen at mvista.com>> wrote:
>
>     On Mon, Jan 31, 2011 at 1:36 PM, Juha Kuikka <juha.kuikka at gmail.com <mailto:juha.kuikka at gmail.com>> wrote:
>     >  On Mon, Jan 31, 2011 at 11:04 AM, Gary Thomas <gary at mlbassoc.com <mailto:gary at mlbassoc.com>> wrote:
>     > >
>     > > I have a board which is uses the OMAP-L138.  It's similar in
>     > > many respects to the EVM/DA850 modules, but there are differences.
>     > > In particular, my board uses MMC/SD1 since it also uses NOR FLASH.
>     > >
>     > > I was able to modify U-Boot to handle this without much trouble.
>     > > However, it doesn't run in Linux.  I added the driver bits for
>     > > this, but what I see is that the very first command issued sets
>     > > up for a completion interrupt (which the registers tell me happens),
>     > > but the driver IRQ handler is never called.
>     > >
>     > > Am I alone in this? as I didn't find any support for MMC/SD1
>     > > in the Linux kernel (I checked the most recent public 2.6.37)
>     > >
>     > > Does anyone have experience using MMC/SD1 on the OMAP-L138
>     > > with the Linux driver?
>     > >
>     >  I think I ran into the same issue.
>     >  Check this conversation on the subject, especially the third
>     >  mail: http://davinci-linux-open-source.1494791.n2.nabble.com/DA850-and-MMCSD1-EDMA-td5077613.html
>     >  I guess I should have pushed that patch but for some reason I never got
>     >  Sudhakar's comment on it. :(
>     >  If this is the solution to your problem maybe you can refresh it against the
>     >  latest kernel and submit it? I don't have access to the HW any more so I
>     >  cannot verify it.
>     >   - Juha
>
>     Hello Juha,
>
>     Followed the link you provided, it seems that Sudhakar did respond.
>     He suggested you to submit your patch to the davinci mailing list.
>
> Sorry, my comment was unclear, I see now that he did respond but I never got that email when the issue was originally discussed so I dropped the ball.
>
> Anyway, we cannot just change the default event queues on all the devices, see this chain. http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg18038.html
>
> Then I got busy and didn't have time to implement and test the proper solution.

Do you have suggestions for what a proper solution is?

I just merged these changes into [mainline] 2.6.37.  I had to
make a few tiny adjustments, e.g. part of the changes are already
in place, just not all, but it seems to be working for me.  I'd
like to see the correct code figured out and pushed.

Thanks


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

From sshtylyov at mvista.com  Wed Feb  9 11:16:01 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 09 Feb 2011 20:16:01 +0300
Subject: DaVinci EMAC driver uses random MAC addresses
In-Reply-To: <4D27365F.4020504@ti.com>
References: <4D271FB9.4020402@mvista.com> <4D27365F.4020504@ti.com>
Message-ID: <4D52CBD1.6020506@mvista.com>

Hello.

Cyril Chemparathy wrote:

>>     Haven't anybody noticed that the EMAC driver in the current DaVinci/DA8xx 
>> kernels now uses random MAC addresses instead of the fixed ones.  I suspect 
>> the recent changes to the driver made by Cyril Chemparathy... :-)

> The emac driver uses the mac_addr stuffed into the pdata, and defaults
> to a random mac only if the pdata mac is invalid.  It seems to be doing
> the right thing at probe:

> 	...
> 	memcpy(priv->mac_addr, pdata->mac_addr, 6);
> 	...
> 	if (!is_valid_ether_addr(priv->mac_addr)) {
> 		/* Use random MAC if none passed */
> 		random_ether_addr(priv->mac_addr);
> 		printk(KERN_WARNING "%s: using random MAC addr: %pM\n",
> 			__func__, priv->mac_addr);
> 	}
> 	...

> Could you verify that the pdata mac is correctly populated (from eeprom)
> before emac probe happens?

    Just tried to verify this and the issue seems to have magically cured 
itself, i.e. davinci_get_mac_addr() in arch/arm/mach-davinci/common.c now timely 
fills in the MAC address and the EMAC driver is content with it. Not sure what 
happened...

> Regards
> Cyril.

WBR, Sergei

PS: Now my DA830 EVM board doesn't want to reboot. :-)

From sshtylyov at mvista.com  Wed Feb  9 11:51:14 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 09 Feb 2011 20:51:14 +0300
Subject: DaVinci EMAC driver uses random MAC addresses
In-Reply-To: <4D52CBD1.6020506@mvista.com>
References: <4D271FB9.4020402@mvista.com> <4D27365F.4020504@ti.com>
	<4D52CBD1.6020506@mvista.com>
Message-ID: <4D52D412.7090100@mvista.com>

Hello.

I wrote:

>>>     Haven't anybody noticed that the EMAC driver in the current 
>>> DaVinci/DA8xx kernels now uses random MAC addresses instead of the 
>>> fixed ones.  I suspect the recent changes to the driver made by Cyril 
>>> Chemparathy... :-)

>> The emac driver uses the mac_addr stuffed into the pdata, and defaults
>> to a random mac only if the pdata mac is invalid.  It seems to be doing
>> the right thing at probe:

>>     ...
>>     memcpy(priv->mac_addr, pdata->mac_addr, 6);
>>     ...
>>     if (!is_valid_ether_addr(priv->mac_addr)) {
>>         /* Use random MAC if none passed */
>>         random_ether_addr(priv->mac_addr);
>>         printk(KERN_WARNING "%s: using random MAC addr: %pM\n",
>>             __func__, priv->mac_addr);
>>     }
>>     ...

>> Could you verify that the pdata mac is correctly populated (from eeprom)
>> before emac probe happens?

>    Just tried to verify this and the issue seems to have magically cured 
> itself, i.e. davinci_get_mac_addr() in arch/arm/mach-davinci/common.c 
> now timely fills in the MAC address and the EMAC driver is content with 
> it. Not sure what happened...

    To be sure, I have pulled from linux-davinci.git recently. So I just don't 
know what fixed the issue. :-)

>> Regards
>> Cyril.

WBR, Sergei


From sshtylyov at ru.mvista.com  Wed Feb  9 12:33:23 2011
From: sshtylyov at ru.mvista.com (Sergei Shtylyov)
Date: Wed, 9 Feb 2011 21:33:23 +0300
Subject: [PATCH] DaVinci: fix compilation warnings in <mach/clkdev.h>
Message-ID: <201102092133.23765.sshtylyov@ru.mvista.com>

Commit 6d803ba736abb5e122dede70a4720e4843dd6df4 (ARM: 6483/1: arm & sh:
factorised duplicated clkdev.c) caused the following warnings:

In file included from /home/headless/src/kernel.org/linux-davinci/arch/arm/
include/asm/clkdev.h:17,
                 from include/linux/clkdev.h:15,
                 from arch/arm/mach-davinci/clock.h:71,
                 from arch/arm/mach-davinci/common.c:22:
arch/arm/mach-davinci/include/mach/clkdev.h:4: warning: `struct clk' declared
inside parameter list
arch/arm/mach-davinci/include/mach/clkdev.h:4: warning: its scope is only this
definition or declaration, which is probably not what you want
arch/arm/mach-davinci/include/mach/clkdev.h:9: warning: `struct clk' declared
inside parameter list

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

---
The patch is against the recent DaVinci tree.

 arch/arm/mach-davinci/include/mach/clkdev.h |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-davinci/arch/arm/mach-davinci/include/mach/clkdev.h
===================================================================
--- linux-davinci.orig/arch/arm/mach-davinci/include/mach/clkdev.h
+++ linux-davinci/arch/arm/mach-davinci/include/mach/clkdev.h
@@ -1,6 +1,8 @@
 #ifndef __MACH_CLKDEV_H
 #define __MACH_CLKDEV_H
 
+struct clk;
+
 static inline int __clk_get(struct clk *clk)
 {
 	return 1;

From nsekhar at ti.com  Wed Feb  9 12:58:46 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 10 Feb 2011 00:28:46 +0530
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <4D4C697F.2080400@criticallink.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>
	<AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>
	<4D4C697F.2080400@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024894B7B5@dbde02.ent.ti.com>

Hi Mike,

On Sat, Feb 05, 2011 at 02:32:55, Michael Williamson wrote:
> On 2/4/2011 12:15 PM, Steve Chen wrote:
> 
> > On Fri, Feb 4, 2011 at 10:52 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
> >> Hi Steve,
> >>
> >> On Fri, Feb 04, 2011 at 21:42:41, Steve Chen wrote:
> >>
> >>>> rtcwake  -s 40 rtc0
> >>> rtcwake: /dev/rtc not enabled for wakeup events
> >>
> >> I have a feeling rtcwake is looking at the wrong device
> >> node. Can you try:
> >>
> >> $ rtcwake -d /dev/rtc0 -s 20 -m mem
> >>
> > 
> > Doh!!.   Sekhar, you are right.  I did not include the "-d" flag.
> > After passing the correct parameter to rtcwake, I'm able to wake up
> > from sleep with NFS rootfs.  I'm running the kernel/filesystem from
> > PSP 03.20.00.14.
> > 
> 
> 
> I was wondering if you (or anyone) have numbers for how much power the
> AM1808 you have is drawing while sleeping?  I was able to run the same 
> command as above with an AM1808 module here today, and the power draw 
> I am seeing by the module was still pretty high.  About 1/2 normal
> operation, but still pretty high.

Were you able to wake-up successfully back from suspend during
this test? I want to make sure you actually hit DeepSleep and did
not crash somewhere on the way to it.

Thanks,
Sekhar


From michael.williamson at criticallink.com  Wed Feb  9 14:40:47 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 09 Feb 2011 15:40:47 -0500
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024894B7B5@dbde02.ent.ti.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>
	<AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>
	<4D4C697F.2080400@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024894B7B5@dbde02.ent.ti.com>
Message-ID: <4D52FBCF.3040702@criticallink.com>

Sekhar,

On 02/09/2011 01:58 PM, Nori, Sekhar wrote:
> Hi Mike,
> 
> On Sat, Feb 05, 2011 at 02:32:55, Michael Williamson wrote:
>> On 2/4/2011 12:15 PM, Steve Chen wrote:
>>
>>> On Fri, Feb 4, 2011 at 10:52 AM, Nori, Sekhar <nsekhar at ti.com> wrote:
>>>> Hi Steve,
>>>>
>>>> On Fri, Feb 04, 2011 at 21:42:41, Steve Chen wrote:
>>>>
>>>>>> rtcwake  -s 40 rtc0
>>>>> rtcwake: /dev/rtc not enabled for wakeup events
>>>>
>>>> I have a feeling rtcwake is looking at the wrong device
>>>> node. Can you try:
>>>>
>>>> $ rtcwake -d /dev/rtc0 -s 20 -m mem
>>>>
>>>
>>> Doh!!.   Sekhar, you are right.  I did not include the "-d" flag.
>>> After passing the correct parameter to rtcwake, I'm able to wake up
>>> from sleep with NFS rootfs.  I'm running the kernel/filesystem from
>>> PSP 03.20.00.14.
>>>
>>
>>
>> I was wondering if you (or anyone) have numbers for how much power the
>> AM1808 you have is drawing while sleeping?  I was able to run the same 
>> command as above with an AM1808 module here today, and the power draw 
>> I am seeing by the module was still pretty high.  About 1/2 normal
>> operation, but still pretty high.
> 
> Were you able to wake-up successfully back from suspend during
> this test? I want to make sure you actually hit DeepSleep and did
> not crash somewhere on the way to it.
> 

Well, turns out when I ran that test I was running a branch off of the 
arago l138 kernel PSP.  I didn't realize it until this morning.  Sorry
for the confusion.  I bounce between the two too many times in the span
of a day.  On the mainline, my 1808 unit hangs entering sleep.  So I think 
there may indeed be something different / problematic there.  I haven't
had a chance to get back to it yet to make sure I didn't have a bad config
or something, but I don't think I did.

While running off of the PSP branch, it does appear to enter sleep (console
messages look sane, no oops, etc.) and it does appear to wake up on
the timer I configure.  I was able to cycle through this multiple times without
rebooting and run other apps / code in between cycles, etc.  Is there a log 
level or debug level that I can turn on to confirm actually making it to 
deepsleep?

-Mike

> Thanks,
> Sekhar
> 


From lrg at slimlogic.co.uk  Wed Feb  9 15:53:46 2011
From: lrg at slimlogic.co.uk (Liam Girdwood)
Date: Wed, 09 Feb 2011 21:53:46 +0000
Subject: [PATCH 1/3] ASoC: Davinci: Use resource_size() helper function
In-Reply-To: <1297256994-17137-1-git-send-email-vaibhav.bedia@ti.com>
References: <1297256994-17137-1-git-send-email-vaibhav.bedia@ti.com>
Message-ID: <1297288426.3297.188.camel@odin>

On Wed, 2011-02-09 at 18:39 +0530, Vaibhav Bedia wrote:
> This patch modifies the Davinci i2s and mcasp drivers
> to make use of the resource_size() helper function for readability.
> 
> Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>

All

Acked-by: Liam Girdwood <lrg at slimlogic.co.uk>
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk


From broonie at opensource.wolfsonmicro.com  Wed Feb  9 16:35:46 2011
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Wed, 9 Feb 2011 22:35:46 +0000
Subject: [PATCH 1/3] ASoC: Davinci: Use resource_size() helper function
In-Reply-To: <1297288426.3297.188.camel@odin>
References: <1297256994-17137-1-git-send-email-vaibhav.bedia@ti.com>
	<1297288426.3297.188.camel@odin>
Message-ID: <20110209223546.GA13655@opensource.wolfsonmicro.com>

On Wed, Feb 09, 2011 at 09:53:46PM +0000, Liam Girdwood wrote:
> On Wed, 2011-02-09 at 18:39 +0530, Vaibhav Bedia wrote:
> > This patch modifies the Davinci i2s and mcasp drivers
> > to make use of the resource_size() helper function for readability.
> > 
> > Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
> 
> All
> 
> Acked-by: Liam Girdwood <lrg at slimlogic.co.uk>

Applied, thanks.

From laurent.pinchart at ideasonboard.com  Thu Feb 10 04:11:08 2011
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 10 Feb 2011 11:11:08 +0100
Subject: DM365 uvc gadget
In-Reply-To: <AANLkTin9LGwH-AY8_jK4JH4irWn5A+esXeb53xD6aq-Y@mail.gmail.com>
References: <AANLkTinyGbsHL0A-ndPPHEUvuDtJet89vTR6S24HLHks@mail.gmail.com>
	<AANLkTikBtBURWSv6M3kX8F_Rmr7uHOxRnAHSXwjKGvtA@mail.gmail.com>
	<AANLkTin9LGwH-AY8_jK4JH4irWn5A+esXeb53xD6aq-Y@mail.gmail.com>
Message-ID: <201102101111.08733.laurent.pinchart@ideasonboard.com>

Hi Jean-Philippe,

On Tuesday 08 February 2011 17:06:39 jean-philippe francois wrote:
> 2011/2/4 Will Kelleher <will.kelleher at nuvixa.com>:
> > Hi,
> > 
> > I also recently backported the UVC gadget (g_webcam) from 2.6.36 to
> > 2.6.32.  Where did you encounter this error?  I'm able to load the
> > module and the DM365 is detected as a UVC device by a Windows host,
> > but then I am unable to add DirectShow filters to the device.  Perhaps
> > the root cause is similar?
> 
> I took a step back and ported the current version of uvc_gadget to 2.6.32.
> In this version, endpoint size is 512, so it doesn't clash anymore with the
> fifo configuration.
> 
> The cause of your problem is more likely the fact that the Video Class
> specific setup request needs to be handled by userspace.

You will find a sample userspace application for this at 
http://git.ideasonboard.org/?p=uvc-gadget.git;a=summary

-- 
Regards,

Laurent Pinchart

From jaya.krishnan at samsung.com  Thu Feb 10 04:47:16 2011
From: jaya.krishnan at samsung.com (Jayakrishnan Melur Madhathil)
Date: Thu, 10 Feb 2011 10:47:16 +0000 (GMT)
Subject: DM365 MPEG4  Encoder Bitrate in VBR  Mode
Message-ID: <24877984.523861297334836474.JavaMail.weblogic@epml18>

Hi
I want to operate DM365 MPEG4 Encoder (dm365_mpeg4enc_01_10_00_03_production.bin) in VBR  mode. In order  to get  a linear  variation  in bitrate  I set the parameters  as  follows.
rateControlPreset=IMP4VENC_CVBR_LBR1;

and  to control the  quality  , I  set  the  parameters  as  follows.
rcQMax=31;
rcQMin is  varied  between  4 to 31 (In 20 steps)
initQ=0;
intraFrameQP=0;
interFrameQP=0;

I  get  a variation in bitrate  , but is  not  linear with  the  degaradation in qualitIy.
I have  no problems  with CBR  mode.
(I  have  tried  other modes  also,IVIDEO_STORAGE  & IMP4VENC_CVBR_LBR1), but  was  not  successful.
Is  this  a  bug? I have tried  with earlier  version   of the  Encoder (which  also  runs  in MJCP).
Pls help

Regards
JK





Jayakrishnan M M
Research Engineer
R&D Team-2 , Group-5
Security Solutions  Division
SAMSUNG TECHWIN CO.,LTD

TEL +82-70-7147-8482
FAX +82-31-8018-3712
Mobile +82-10-6409-3619
E-mail:jaya.krishnan at samsung.com




  

From hebert.marcandre at gmail.com  Thu Feb 10 10:25:43 2011
From: hebert.marcandre at gmail.com (=?ISO-8859-1?Q?Marc=2DAndr=E9_H=E9bert?=)
Date: Thu, 10 Feb 2011 11:25:43 -0500
Subject: Omapl138 Missing data with audio CD with SATA drive
Message-ID: <AANLkTik6p-uzTRGAD0TYqznwmWTBAJYkdM0gs9Xn5s59@mail.gmail.com>

Hi,

We're having a weird problems and was wondering if people had
suggestions on where to look. Our omapl138 board has a SATA CD/DVD
drive and we are running the arago tree.

When we are reading data from an audio CD (we use the ioctl
CDROMREADAUDIO) there are sometimes glitches in the audio. Our
analysis has revealed the following:
-There are no glitches if using a USB CDROM.
-There are no glitches if we reduce the system load (instead of
processing the audio, we just dump to a file).
-The glitches are in the data returned from the ioctl (as confirmed
from dumping to file with normal system load)
-When it happens, it seems the read operation is incomplete. A sector
is 2352 bytes, the last 4-12 bytes are incorrect (they still hold the
data before the call to the ioctl).
-In case it was an incomplete DMA bug, we tried using libata.dma=0. It
didn't make a difference.

This pretty much sums it up. We haven't seen any problems with reading
from a mounted filesystem on a CD.

Regards
Marc

From nsekhar at ti.com  Thu Feb 10 23:02:35 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 11 Feb 2011 10:32:35 +0530
Subject: AM1808 EVM with davinci git sleep wake up
In-Reply-To: <4D52FBCF.3040702@criticallink.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>
	<AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>
	<4D4C697F.2080400@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024894B7B5@dbde02.ent.ti.com>
	<4D52FBCF.3040702@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024894BFDC@dbde02.ent.ti.com>

Hi Mike,

On Thu, Feb 10, 2011 at 02:10:47, Michael Williamson wrote:

> Well, turns out when I ran that test I was running a branch off of the 
> arago l138 kernel PSP.  I didn't realize it until this morning.  Sorry
> for the confusion.  I bounce between the two too many times in the span
> of a day.  On the mainline, my 1808 unit hangs entering sleep.  So I think 
> there may indeed be something different / problematic there.  I haven't

Okay, will have to check this.

> had a chance to get back to it yet to make sure I didn't have a bad config
> or something, but I don't think I did.
> 
> While running off of the PSP branch, it does appear to enter sleep (console
> messages look sane, no oops, etc.) and it does appear to wake up on
> the timer I configure.  I was able to cycle through this multiple times without
> rebooting and run other apps / code in between cycles, etc.  Is there a log 
> level or debug level that I can turn on to confirm actually making it to 
> deepsleep?

The code which actually enters deepsleep is in assembly so not much of
logging is possible there. From your description it appears that
suspend-to-RAM is working fine. Were you able to make any power
measurements while in deepsleep state?

Thanks,
Sekhar


From c.aeschlimann at acn-group.ch  Fri Feb 11 03:28:13 2011
From: c.aeschlimann at acn-group.ch (Christophe Aeschlimann)
Date: Fri, 11 Feb 2011 10:28:13 +0100
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302488B9CEE@dbde02.ent.ti.com>
References: <4D4A779F.8030305@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>
	<4D51174A.7050504@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9CEE@dbde02.ent.ti.com>
Message-ID: <4D55012D.8020608@acn-group.ch>

On 08.02.2011 12:19, Rajashekhara, Sudhakar wrote:
> Hi Christophe,
> 
> On Tue, Feb 08, 2011 at 15:43:30, Christophe Aeschlimann wrote:
>> Hi Sudhakar,
>>
> 
> [...]
> 
>>
>> Thanks for doing some testing on your side.
>>
>> Any specific reason why you used the gpio-keys-polled driver ? I'm using
>> the standard gpio-keys driver which is based on a interrupt instead of
>> polling. As I said I think it's a problem with the interruption mechanism.
>>
> 
> I am not able boot my board when I use the gpio-keys driver? Have you done any
> modifications to the kernel to use gpio-keys driver?
> 
> Regards,
> Sudhakar

Hi Sudhakar,

Did you sort it out ?

Tell me if you need any additional information.

Regards,

Christophe


-- 
Christophe Aeschlimann

Embedded Software Engineer & IT Manager

ACN 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 sudhakar.raj at ti.com  Fri Feb 11 05:03:08 2011
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Fri, 11 Feb 2011 16:33:08 +0530
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
In-Reply-To: <4D55012D.8020608@acn-group.ch>
References: <4D4A779F.8030305@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>
	<4D51174A.7050504@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9CEE@dbde02.ent.ti.com>
	<4D55012D.8020608@acn-group.ch>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024894C2D1@dbde02.ent.ti.com>

Hi,

On Fri, Feb 11, 2011 at 14:58:13, Christophe Aeschlimann wrote:
> On 08.02.2011 12:19, Rajashekhara, Sudhakar wrote:
> > Hi Christophe,
> > 
> > On Tue, Feb 08, 2011 at 15:43:30, Christophe Aeschlimann wrote:
> >> Hi Sudhakar,
> >>
> > 
> > [...]
> > 
> >>
> >> Thanks for doing some testing on your side.
> >>
> >> Any specific reason why you used the gpio-keys-polled driver ? I'm using
> >> the standard gpio-keys driver which is based on a interrupt instead of
> >> polling. As I said I think it's a problem with the interruption mechanism.
> >>
> > 
> > I am not able boot my board when I use the gpio-keys driver? Have you done any
> > modifications to the kernel to use gpio-keys driver?
> > 
> > Regards,
> > Sudhakar
> 
> Hi Sudhakar,
> 
> Did you sort it out ?
> 
> Tell me if you need any additional information.
> 

When I enable the "gpio-keys" driver I am getting the below error message when kernel is booting:

"gpio-keys gpio-keys.0: Unable to get irq number for GPIO 152, error -6"

I am yet to debug this.

Regards,
Sudhakar

From todd.fischer at ridgerun.com  Fri Feb 11 07:45:28 2011
From: todd.fischer at ridgerun.com (Todd Fischer)
Date: Fri, 11 Feb 2011 06:45:28 -0700
Subject: DM365 deep sleep
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024894BFDC@dbde02.ent.ti.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>	<B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>	<AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>	<4D4C697F.2080400@criticallink.com>	<B85A65D85D7EB246BE421B3FB0FBB593024894B7B5@dbde02.ent.ti.com>	<4D52FBCF.3040702@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024894BFDC@dbde02.ent.ti.com>
Message-ID: <4D553D78.3000404@ridgerun.com>

Sekhar,

What is the status for deep sleep support on the DM365?  If it is 
available, where can I find it?  If not available, I was planning on 
starting adding DM365 deep sleep support using the mach-davinci pm.c and 
sleep.S code from the latest davinci-linux git repo unless you have 
another suggestion.

Todd


From subhasish at mistralsolutions.com  Fri Feb 11 08:18:25 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 19:48:25 +0530
Subject: [PATCH 1/1] da830: macro rename DA8XX_LPSC0_DMAX to DA8XX_LPSC0_PRUSS.
Message-ID: <1297433905-27925-1-git-send-email-subhasish@mistralsolutions.com>

The PRUSS was named as DMAX on da830 platform.
This patch resolves the naming conflict by replacing the macro
DA8XX_LPSC0_DMAX with DA8XX_LPSC0_PRUSS.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/da830.c            |    2 +-
 arch/arm/mach-davinci/include/mach/psc.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index ec23ab4..0577a5d 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -148,7 +148,7 @@ static struct clk scr2_ss_clk = {
 static struct clk dmax_clk = {
 	.name		= "dmax",
 	.parent		= &pll0_sysclk2,
-	.lpsc		= DA8XX_LPSC0_DMAX,
+	.lpsc		= DA8XX_LPSC0_PRUSS,
 	.flags		= ALWAYS_ENABLED,
 };
 
diff --git a/arch/arm/mach-davinci/include/mach/psc.h b/arch/arm/mach-davinci/include/mach/psc.h
index 62b0858..a47e6f2 100644
--- a/arch/arm/mach-davinci/include/mach/psc.h
+++ b/arch/arm/mach-davinci/include/mach/psc.h
@@ -150,7 +150,7 @@
 #define DA8XX_LPSC0_SCR0_SS		10
 #define DA8XX_LPSC0_SCR1_SS		11
 #define DA8XX_LPSC0_SCR2_SS		12
-#define DA8XX_LPSC0_DMAX		13
+#define DA8XX_LPSC0_PRUSS		13
 #define DA8XX_LPSC0_ARM			14
 #define DA8XX_LPSC0_GEM			15
 
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:21:28 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 19:51:28 +0530
Subject: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.
Message-ID: <1297434088-27995-1-git-send-email-subhasish@mistralsolutions.com>

This patch modifies the sram allocator to allocate memory
from the DA8XX shared RAM.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/da850.c              |    6 +++---
 arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..8a4de97 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -711,7 +711,7 @@ static struct map_desc da850_io_desc[] = {
 	},
 	{
 		.virtual	= SRAM_VIRT,
-		.pfn		= __phys_to_pfn(DA8XX_ARM_RAM_BASE),
+		.pfn		= __phys_to_pfn(DA8XX_SHARED_RAM_BASE),
 		.length		= SZ_8K,
 		.type		= MT_DEVICE
 	},
@@ -1083,8 +1083,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
-	.sram_len		= SZ_8K,
+	.sram_dma		= DA8XX_SHARED_RAM_BASE,
+	.sram_len		= SZ_128K,
 	.reset_device		= &da8xx_wdt_device,
 };
 
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..c3c3339 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -70,6 +70,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
+#define DA8XX_SHARED_RAM_BASE	0x80000000
 
 void __init da830_init(void);
 void __init da850_init(void);
-- 
1.7.2.3


From bengardiner at nanometrics.ca  Fri Feb 11 08:34:07 2011
From: bengardiner at nanometrics.ca (Ben Gardiner)
Date: Fri, 11 Feb 2011 09:34:07 -0500
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024894C2D1@dbde02.ent.ti.com>
References: <4D4A779F.8030305@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>
	<4D51174A.7050504@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9CEE@dbde02.ent.ti.com>
	<4D55012D.8020608@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB593024894C2D1@dbde02.ent.ti.com>
Message-ID: <AANLkTinKptNSueM221KfGm-gRgx2-oM+AsFaGW4dF+ug@mail.gmail.com>

Hi Sudhakar,

On Fri, Feb 11, 2011 at 6:03 AM, Rajashekhara, Sudhakar
<sudhakar.raj at ti.com> wrote:
> When I enable the "gpio-keys" driver I am getting the below error message when kernel is booting:
>
> "gpio-keys gpio-keys.0: Unable to get irq number for GPIO 152, error -6"

This error looks familiar to me; please excuse me if I presume too much.

It looks like you may be trying to use the gpio-keys driver on an i2c
expander. This driver requires interrupt-capable GPIOs and i2c
expander GPIOs are not interrupt capable -- yet. The support needed
for chained interrupts is being developed by Lennert Buytenhek as part
of the ARM device tree support [1].

To reproduce Chritophe's problem, try using the L138's GPIOs directly
in a gpio-keys driver instance.

Best Regards,
Ben Gardiner

[1] http://article.gmane.org/gmane.linux.drivers.devicetree/4261

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

From subhasish at mistralsolutions.com  Fri Feb 11 08:51:19 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:19 +0530
Subject: [PATCH v2 00/13] pruss mfd drivers
Message-ID: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>


                           PRUSS Functional Block Diagram
               /----------------------------------------------------\
               |                                                    |
               |                      |------|                      |
     32GPO<------->PRU CORE-0 <------>|      |<------> DRAM 0       |
     30GPI<------->(4KB IRAM)         |  S   |       (512 Bytes)    |
               |                      |      |                      |
     32GPO<------->PRU CORE-1 <------>|  C   |<------> DRAM 1       |
     30GPI<------->(4KB IRAM)         |      |       (512 Bytes)    |
               |                      |  R   |                      |
               |                      |      |                      |
 Ints to ARM/  |    Interrupt <------>|      |-------------------------> Master I/F (to SCR2)
 DSP INTC <------->Controller         |      |<------------------------- Slave I/F (from SCR2)
 Events from   |     (INTC)           |------|                      |
 Periph + PRUs |                                                    |
               \----------------------------------------------------/

Programmable Realtime Unit (PRU) is basically a 32-bit RISC
processor available within TI's DA8XX SOCs. It consists of local
instruction and data RAM and also has access to SOC resources
via a Switched Central Resource (SCR).

There are two PRU's available within DA8XX SOC's PRUSS, hence providing
two execution cores. Devices/Protocols can be emulated on these utilizing
either both or only one of the PRUs independently.

The rational behind the MFD driver being the fact that multiple devices can
be implemented on the cores independently.
It's also possible, as in our case, to implement a single device on both
the PRU's resulting in improved load sharing.

A detailed description is also available here:
http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem

version 2:
==========
* added pruss TTY Soft-UART driver.
* added pruss Soft-UART board and platform changes.
* fixed previous review comments.
* reordered patch sequence.

version 1:
==========
* added pruss mfd driver.
* added pruss mfd board and platform changes.
* added pruss SocketCAN driver.
* added pruss SocketCAN board and platform changes.
* added pruss SocketCAN GPIOs.
* added previous review comments.

Subhasish Ghosh (13):
  mfd: pruss mfd driver.
  da850: pruss platform specific additions.
  da850: pruss board specific additions.
  mfd: pruss CAN private data.
  da850: pruss CAN platform specific additions.
  da850: pruss CAN board specific additions.
  da850: pruss CAN platform specific changes for gpios.
  da850: pruss CAN board specific changes for gpios.
  can: pruss CAN driver.
  mfd: pruss SUART private data.
  da850: pruss SUART board specific additions.
  da850: pruss SUART platform specific additions.
  tty: pruss SUART driver

 arch/arm/mach-davinci/board-da850-evm.c            |  105 +
 arch/arm/mach-davinci/da850.c                      |   12 +
 arch/arm/mach-davinci/devices-da8xx.c              |   76 +
 arch/arm/mach-davinci/include/mach/da8xx.h         |    2 +
 arch/arm/mach-davinci/include/mach/mux.h           |    5 +
 drivers/mfd/Kconfig                                |   10 +
 drivers/mfd/Makefile                               |    1 +
 drivers/mfd/da8xx_pru.c                            |  446 ++++
 drivers/net/can/Kconfig                            |    1 +
 drivers/net/can/Makefile                           |    1 +
 drivers/net/can/da8xx_pruss/Kconfig                |   73 +
 drivers/net/can/da8xx_pruss/Makefile               |    7 +
 drivers/net/can/da8xx_pruss/pruss_can.c            |  758 +++++++
 drivers/net/can/da8xx_pruss/pruss_can_api.c        | 1227 ++++++++++
 drivers/net/can/da8xx_pruss/pruss_can_api.h        |  290 +++
 drivers/tty/serial/Kconfig                         |    2 +
 drivers/tty/serial/Makefile                        |    1 +
 drivers/tty/serial/da8xx_pruss/Kconfig             |   19 +
 drivers/tty/serial/da8xx_pruss/Makefile            |    9 +
 drivers/tty/serial/da8xx_pruss/pruss_suart.c       | 1014 +++++++++
 drivers/tty/serial/da8xx_pruss/pruss_suart_api.c   | 2350 ++++++++++++++++++++
 drivers/tty/serial/da8xx_pruss/pruss_suart_api.h   |  345 +++
 drivers/tty/serial/da8xx_pruss/pruss_suart_board.h |   58 +
 drivers/tty/serial/da8xx_pruss/pruss_suart_err.h   |   48 +
 drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h |  526 +++++
 drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h  |  153 ++
 drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c |  384 ++++
 drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h |   63 +
 include/linux/mfd/pruss/da8xx_pru.h                |  131 ++
 include/linux/mfd/pruss/da8xx_prucore.h            |   74 +
 include/linux/serial_core.h                        |    2 +
 31 files changed, 8193 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/da8xx_pru.c
 create mode 100644 drivers/net/can/da8xx_pruss/Kconfig
 create mode 100644 drivers/net/can/da8xx_pruss/Makefile
 create mode 100644 drivers/net/can/da8xx_pruss/pruss_can.c
 create mode 100644 drivers/net/can/da8xx_pruss/pruss_can_api.c
 create mode 100644 drivers/net/can/da8xx_pruss/pruss_can_api.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/Kconfig
 create mode 100644 drivers/tty/serial/da8xx_pruss/Makefile
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart.c
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_api.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_board.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_err.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h
 create mode 100644 include/linux/mfd/pruss/da8xx_pru.h
 create mode 100644 include/linux/mfd/pruss/da8xx_prucore.h

-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:20 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:20 +0530
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>

This patch adds the pruss MFD driver and associated include files.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 drivers/mfd/Kconfig                     |   10 +
 drivers/mfd/Makefile                    |    1 +
 drivers/mfd/da8xx_pru.c                 |  446 +++++++++++++++++++++++++++++++
 include/linux/mfd/pruss/da8xx_pru.h     |  122 +++++++++
 include/linux/mfd/pruss/da8xx_prucore.h |   74 +++++
 5 files changed, 653 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/da8xx_pru.c
 create mode 100644 include/linux/mfd/pruss/da8xx_pru.h
 create mode 100644 include/linux/mfd/pruss/da8xx_prucore.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index fd01836..6c437df 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
 	  boards.  MSP430 firmware manages resets and power sequencing,
 	  inputs from buttons and the IR remote, LEDs, an RTC, and more.
 
+config MFD_DA8XX_PRUSS
+	tristate "Texas Instruments DA8XX PRUSS support"
+	depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
+	select MFD_CORE
+	help
+	    This driver provides support api's for the programmable
+		realtime unit (PRU) present on TI's da8xx processors. It
+		provides basic read, write, config, enable, disable
+		routines to facilitate devices emulated on it.
+
 config HTC_EGPIO
 	bool "HTC EGPIO support"
 	depends on GENERIC_HARDIRQS && GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a54e2c7..670d6b0 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_HTC_PASIC3)	+= htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)	+= htc-i2cpld.o
 
 obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)	+= davinci_voicecodec.o
+obj-$(CONFIG_MFD_DA8XX_PRUSS)	+= da8xx_pru.o
 obj-$(CONFIG_MFD_DM355EVM_MSP)	+= dm355evm_msp.o
 
 obj-$(CONFIG_MFD_STMPE)		+= stmpe.o
diff --git a/drivers/mfd/da8xx_pru.c b/drivers/mfd/da8xx_pru.c
new file mode 100644
index 0000000..f7868a4
--- /dev/null
+++ b/drivers/mfd/da8xx_pru.c
@@ -0,0 +1,446 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ *
+ * 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/init.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/module.h>
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/errno.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/mfd/pruss/da8xx_prucore.h>
+#include <linux/mfd/pruss/da8xx_pru.h>
+#include <linux/mfd/core.h>
+#include <linux/io.h>
+#include <mach/da8xx.h>
+
+struct da8xx_pruss {
+	struct device *dev;
+	struct resource *res;
+	struct clk *clk;
+	u32 clk_freq;
+	void __iomem *ioaddr;
+};
+
+u32 pruss_get_clk_freq(struct device *dev)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+
+	return pruss->clk_freq;
+}
+EXPORT_SYMBOL(pruss_get_clk_freq);
+
+u32 pruss_disable(struct device *dev, u8 pruss_num)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	da8xx_prusscore_regs h_pruss;
+	u32 temp_reg;
+
+	if (pruss_num == DA8XX_PRUCORE_0) {
+		/* Disable PRU0  */
+		h_pruss = (da8xx_prusscore_regs)
+			((u32) pruss->ioaddr + 0x7000);
+
+		temp_reg = __raw_readl(&h_pruss->CONTROL);
+		temp_reg = (temp_reg &
+				~DA8XX_PRUCORE_CONTROL_COUNTENABLE_MASK) |
+				((DA8XX_PRUCORE_CONTROL_COUNTENABLE_DISABLE <<
+				DA8XX_PRUCORE_CONTROL_COUNTENABLE_SHIFT) &
+				DA8XX_PRUCORE_CONTROL_COUNTENABLE_MASK);
+		__raw_writel(temp_reg, &h_pruss->CONTROL);
+
+		temp_reg = __raw_readl(&h_pruss->CONTROL);
+		temp_reg = (temp_reg &
+				~DA8XX_PRUCORE_CONTROL_ENABLE_MASK) |
+				((DA8XX_PRUCORE_CONTROL_ENABLE_DISABLE <<
+				DA8XX_PRUCORE_CONTROL_ENABLE_SHIFT) &
+				DA8XX_PRUCORE_CONTROL_ENABLE_MASK);
+		__raw_writel(temp_reg, &h_pruss->CONTROL);
+
+		/* Reset PRU0 */
+		__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
+				&h_pruss->CONTROL);
+	} else if (pruss_num == DA8XX_PRUCORE_1) {
+		/* Disable PRU1 */
+		h_pruss = (da8xx_prusscore_regs)
+		((u32) pruss->ioaddr + 0x7800);
+		temp_reg = __raw_readl(&h_pruss->CONTROL);
+		temp_reg = (temp_reg &
+				~DA8XX_PRUCORE_CONTROL_COUNTENABLE_MASK) |
+				((DA8XX_PRUCORE_CONTROL_COUNTENABLE_DISABLE <<
+				DA8XX_PRUCORE_CONTROL_COUNTENABLE_SHIFT) &
+				DA8XX_PRUCORE_CONTROL_COUNTENABLE_MASK);
+		__raw_writel(temp_reg, &h_pruss->CONTROL);
+
+		temp_reg = __raw_readl(&h_pruss->CONTROL);
+		temp_reg = (temp_reg &
+				~DA8XX_PRUCORE_CONTROL_ENABLE_MASK) |
+				((DA8XX_PRUCORE_CONTROL_ENABLE_DISABLE <<
+				DA8XX_PRUCORE_CONTROL_ENABLE_SHIFT) &
+				DA8XX_PRUCORE_CONTROL_ENABLE_MASK);
+		__raw_writel(temp_reg, &h_pruss->CONTROL);
+
+		/* Reset PRU1 */
+		__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL, &h_pruss->CONTROL);
+	} else
+		return -EINVAL;
+
+	return 0;
+}
+EXPORT_SYMBOL(pruss_disable);
+
+u32 pruss_enable(struct device *dev, u8 pruss_num)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	da8xx_prusscore_regs h_pruss;
+
+	if (pruss_num == DA8XX_PRUCORE_0) {
+		/* Reset PRU0 */
+		h_pruss = (da8xx_prusscore_regs)
+			((u32) pruss->ioaddr + 0x7000);
+		__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
+			&h_pruss->CONTROL);
+	} else if (pruss_num == DA8XX_PRUCORE_1) {
+		/* Reset PRU1  */
+		h_pruss = (da8xx_prusscore_regs)
+			((u32) pruss->ioaddr + 0x7800);
+		__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
+			&h_pruss->CONTROL);
+	} else
+		return -EINVAL;
+
+	return 0;
+}
+EXPORT_SYMBOL(pruss_enable);
+
+/* Load the specified PRU with code */
+u32 pruss_load(struct device *dev, u8 pruss_num,
+			u32 *pruss_code, u32 code_size_in_words)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	u32 *pruss_iram;
+	u32 i;
+
+	if (pruss_num == DA8XX_PRUCORE_0) {
+		pruss_iram = (u32 *) ((u32) pruss->ioaddr + 0x8000);
+	} else if (pruss_num == DA8XX_PRUCORE_1) {
+		pruss_iram = (u32 *) ((u32) pruss->ioaddr + 0xc000);
+	} else
+		return -EINVAL;
+
+	pruss_enable(dev, pruss_num);
+
+	/* Copy dMAX code to its instruction RAM  */
+	for (i = 0; i < code_size_in_words; i++) {
+		__raw_writel(pruss_code[i], (pruss_iram + i));
+	}
+	return 0;
+}
+EXPORT_SYMBOL(pruss_load);
+
+u32 pruss_run(struct device *dev, u8 pruss_num)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	da8xx_prusscore_regs h_pruss;
+
+	u32 temp_reg;
+
+	if (pruss_num == DA8XX_PRUCORE_0) {
+		/* DA8XX_PRUCORE_0_REGS; */
+		h_pruss = (da8xx_prusscore_regs)
+			((u32) pruss->ioaddr + 0x7000);
+	} else if (pruss_num == DA8XX_PRUCORE_1) {
+		/* DA8XX_PRUCORE_1_REGS; */
+		h_pruss = (da8xx_prusscore_regs)
+			((u32) pruss->ioaddr + 0x7800);
+	} else
+		return -EINVAL;
+
+	/* Enable dMAX, let it execute the code we just copied */
+	temp_reg = __raw_readl(&h_pruss->CONTROL);
+	temp_reg = (temp_reg &
+			~DA8XX_PRUCORE_CONTROL_COUNTENABLE_MASK) |
+			((DA8XX_PRUCORE_CONTROL_COUNTENABLE_ENABLE <<
+			DA8XX_PRUCORE_CONTROL_COUNTENABLE_SHIFT) &
+			DA8XX_PRUCORE_CONTROL_COUNTENABLE_MASK);
+	__raw_writel(temp_reg, &h_pruss->CONTROL);
+
+	temp_reg = __raw_readl(&h_pruss->CONTROL);
+	temp_reg = (temp_reg &
+			~DA8XX_PRUCORE_CONTROL_ENABLE_MASK) |
+			((DA8XX_PRUCORE_CONTROL_ENABLE_ENABLE <<
+			DA8XX_PRUCORE_CONTROL_ENABLE_SHIFT) &
+			DA8XX_PRUCORE_CONTROL_ENABLE_MASK);
+	__raw_writel(temp_reg, &h_pruss->CONTROL);
+	return 0;
+}
+EXPORT_SYMBOL(pruss_run);
+
+u32 pruss_wait_for_halt(struct device *dev, u8 pruss_num, u32 timeout)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	da8xx_prusscore_regs h_pruss;
+	u32 temp_reg;
+	u32 cnt = timeout;
+
+	if (pruss_num == DA8XX_PRUCORE_0) {
+		/* DA8XX_PRUCORE_0_REGS; */
+		h_pruss = (da8xx_prusscore_regs)
+			((u32) pruss->ioaddr + 0x7000);
+	} else if (pruss_num == DA8XX_PRUCORE_1) {
+		/* DA8XX_PRUCORE_1_REGS; */
+		h_pruss = (da8xx_prusscore_regs)
+			((u32) pruss->ioaddr + 0x7800);
+	} else
+		return -EINVAL;
+
+	while (cnt--) {
+		temp_reg = __raw_readl(&h_pruss->CONTROL);
+		if (((temp_reg & DA8XX_PRUCORE_CONTROL_RUNSTATE_MASK) >>
+				DA8XX_PRUCORE_CONTROL_RUNSTATE_SHIFT) ==
+					DA8XX_PRUCORE_CONTROL_RUNSTATE_HALT)
+			break;
+	}
+	if (cnt == 0)
+		return -EBUSY;
+
+	return 0;
+}
+EXPORT_SYMBOL(pruss_wait_for_halt);
+
+s16 pruss_writeb(struct device *dev, u32 u32offset,
+		u8 *pu8datatowrite, u16 u16bytestowrite)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	u8 *pu8addresstowrite;
+	u16 u16loop;
+	u32offset = (u32)pruss->ioaddr + u32offset;
+	pu8addresstowrite = (u8 *) (u32offset);
+
+	for (u16loop = 0; u16loop < u16bytestowrite; u16loop++)
+		__raw_writeb(*pu8datatowrite++, pu8addresstowrite++);
+	return 0;
+}
+EXPORT_SYMBOL(pruss_writeb);
+
+s16 pruss_readb(struct device *dev, u32 u32offset,
+		u8 *pu8datatoread, u16 u16bytestoread)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	u8 *pu8addresstoread;
+	u16 u16loop;
+	u32offset = (u32)pruss->ioaddr + u32offset;
+	pu8addresstoread = (u8 *) (u32offset);
+
+	for (u16loop = 0; u16loop < u16bytestoread; u16loop++)
+		*pu8datatoread++ = __raw_readb(pu8addresstoread++);
+	return 0;
+}
+EXPORT_SYMBOL(pruss_readb);
+
+s16 pruss_writel(struct device *dev, u32 u32offset,
+		u32 *pu32datatowrite, s16 u16wordstowrite)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	u32 *pu32addresstowrite;
+	s16 u16loop;
+
+	/* TODO: Get all the driver API's fixed */
+	u32offset = (u32)pruss->ioaddr + u32offset;
+	pu32addresstowrite = (u32 *)(u32offset);
+
+	for (u16loop = 0; u16loop < u16wordstowrite; u16loop++)
+		__raw_writel(*pu32datatowrite++, pu32addresstowrite++);
+	return 0;
+}
+EXPORT_SYMBOL(pruss_writel);
+
+s16 pruss_readl(struct device *dev, u32 u32offset,
+		u32 *pu32datatoread, s16 u16wordstoread)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	u32 *pu32addresstoread;
+	s16 u16loop;
+
+	/* TODO: Get all the driver API's fixed */
+	u32offset = (u32)pruss->ioaddr + u32offset;
+	pu32addresstoread = (u32 *)(u32offset);
+
+	for (u16loop = 0; u16loop < u16wordstoread; u16loop++)
+		*pu32datatoread++ = __raw_readl(pu32addresstoread++);
+	return 0;
+}
+EXPORT_SYMBOL(pruss_readl);
+
+s16 pruss_writew(struct device *dev, u32 u32offset,
+		u16 *pu16datatowrite, s16 u16wordstowrite)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	u32 *pu32addresstowrite;
+	s16 u16loop;
+
+	/* TODO: Get all the driver API's fixed */
+	u32offset = (u32)pruss->ioaddr + u32offset;
+	pu32addresstowrite = (u32 *)(u32offset);
+
+	for (u16loop = 0; u16loop < u16wordstowrite; u16loop++) {
+		__raw_writew(*(pu16datatowrite++), (pu32addresstowrite++));
+	}
+	return 0;
+}
+EXPORT_SYMBOL(pruss_writew);
+
+s16 pruss_readw(struct device *dev, u32 u32offset,
+			u16 *pu16datatoread, s16 u16wordstoread)
+{
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
+	u32 *pu32addresstoread;
+	s16 u16loop;
+
+	/* TODO: Get all the driver API's fixed */
+	u32offset = (u32)pruss->ioaddr + u32offset;
+	pu32addresstoread = (u32 *)(u32offset);
+
+	for (u16loop = 0; u16loop < u16wordstoread; u16loop++)
+		*pu16datatoread++ = __raw_readw(pu32addresstoread++);
+	return 0;
+}
+EXPORT_SYMBOL(pruss_readw);
+
+static int pruss_mfd_add_devices(struct platform_device *pdev)
+{
+	struct da8xx_pruss_devices *dev_data = pdev->dev.platform_data;
+	struct device *dev = &pdev->dev;
+	struct mfd_cell cell;
+	u32 err, count;
+
+	for (count = 0; (dev_data + count)->dev_name != NULL; count++) {
+		memset(&cell, 0, sizeof(struct mfd_cell));
+		cell.id			= count;
+		cell.name		= (dev_data + count)->dev_name;
+		cell.platform_data	= (dev_data + count)->pdata;
+		cell.data_size		= (dev_data + count)->pdata_size;
+
+		err = mfd_add_devices(dev, 0, &cell, 1, NULL, 0);
+		if (err) {
+			dev_err(dev, "cannot add mfd cells\n");
+			return err;
+		}
+	}
+	return err;
+}
+
+static int __devinit da8xx_pruss_probe(struct platform_device *pdev)
+{
+	struct da8xx_pruss *pruss_dev = NULL;
+	u32 err;
+
+	pruss_dev = kzalloc(sizeof(struct da8xx_pruss), GFP_KERNEL);
+	if (!pruss_dev)
+		return -ENOMEM;
+
+	pruss_dev->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!pruss_dev->res) {
+		dev_err(&pdev->dev,
+		"unable to get pruss memory resources!\n");
+		err = -ENODEV;
+		goto probe_exit_kfree;
+	}
+
+	if (!request_mem_region(pruss_dev->res->start, resource_size(pruss_dev->res),
+		dev_name(&pdev->dev))) {
+		dev_err(&pdev->dev, "pruss memory region already claimed!\n");
+		err = -EBUSY;
+		goto probe_exit_kfree;
+	}
+
+	pruss_dev->ioaddr = ioremap(pruss_dev->res->start,
+	resource_size(pruss_dev->res));
+	if (!pruss_dev->ioaddr) {
+		dev_err(&pdev->dev, "ioremap failed\n");
+		err = -ENOMEM;
+		goto probe_exit_free_region;
+	}
+
+	pruss_dev->clk = clk_get(NULL, "pruss");
+	if (IS_ERR(pruss_dev->clk)) {
+		dev_err(&pdev->dev, "no clock available: pruss\n");
+		err = -ENODEV;
+		pruss_dev->clk = NULL;
+		goto probe_exit_iounmap;
+	}
+
+	clk_enable(pruss_dev->clk);
+	pruss_dev->clk_freq = clk_get_rate(pruss_dev->clk);
+
+	err = pruss_mfd_add_devices(pdev);
+	if (err)
+		goto probe_exit_clock;
+
+	platform_set_drvdata(pdev, pruss_dev);
+	pruss_dev->dev = &pdev->dev;
+	return 0;
+
+probe_exit_clock:
+	clk_put(pruss_dev->clk);
+	clk_disable(pruss_dev->clk);
+probe_exit_iounmap:
+	iounmap(pruss_dev->ioaddr);
+probe_exit_free_region:
+	release_mem_region(pruss_dev->res->start, resource_size(pruss_dev->res));
+probe_exit_kfree:
+	kfree(pruss_dev);
+	return err;
+}
+
+static int __devexit da8xx_pruss_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct da8xx_pruss *pruss = dev_get_drvdata(dev);
+
+	mfd_remove_devices(dev);
+	clk_disable(pruss->clk);
+	clk_put(pruss->clk);
+	iounmap(pruss->ioaddr);
+	release_mem_region(pruss->res->start, resource_size(pruss->res));
+	kfree(pruss);
+	dev_set_drvdata(dev, NULL);
+	return 0;
+}
+
+static struct platform_driver da8xx_pruss_driver = {
+	.probe	= da8xx_pruss_probe,
+	.remove	= __devexit_p(da8xx_pruss_remove),
+	.driver	= {
+		.name	= "da8xx_pruss",
+		.owner	= THIS_MODULE,
+	}
+};
+
+static int __init da8xx_pruss_init(void)
+{
+	return platform_driver_register(&da8xx_pruss_driver);
+}
+module_init(da8xx_pruss_init);
+
+static void __exit da8xx_pruss_exit(void)
+{
+	platform_driver_unregister(&da8xx_pruss_driver);
+}
+module_exit(da8xx_pruss_exit);
+
+MODULE_DESCRIPTION("Programmable Realtime Unit (PRU) Driver");
+MODULE_AUTHOR("Subhasish Ghosh");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/pruss/da8xx_pru.h b/include/linux/mfd/pruss/da8xx_pru.h
new file mode 100644
index 0000000..68d8421
--- /dev/null
+++ b/include/linux/mfd/pruss/da8xx_pru.h
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
+ *
+ * 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 _PRUSS_H_
+#define _PRUSS_H_
+
+#include <linux/types.h>
+#include <linux/platform_device.h>
+#include "da8xx_prucore.h"
+
+#define PRUSS_NUM0			DA8XX_PRUCORE_0
+#define PRUSS_NUM1			DA8XX_PRUCORE_1
+
+#define PRUSS_PRU0_BASE_ADDRESS		0
+#define PRUSS_INTC_BASE_ADDRESS		(PRUSS_PRU0_BASE_ADDRESS + 0x4000)
+#define PRUSS_INTC_GLBLEN		(PRUSS_INTC_BASE_ADDRESS + 0x10)
+#define PRUSS_INTC_GLBLNSTLVL		(PRUSS_INTC_BASE_ADDRESS + 0x1C)
+#define PRUSS_INTC_STATIDXSET		(PRUSS_INTC_BASE_ADDRESS + 0x20)
+#define PRUSS_INTC_STATIDXCLR		(PRUSS_INTC_BASE_ADDRESS + 0x24)
+#define PRUSS_INTC_ENIDXSET		(PRUSS_INTC_BASE_ADDRESS + 0x28)
+#define PRUSS_INTC_ENIDXCLR		(PRUSS_INTC_BASE_ADDRESS + 0x2C)
+#define PRUSS_INTC_HSTINTENIDXSET	(PRUSS_INTC_BASE_ADDRESS + 0x34)
+#define PRUSS_INTC_HSTINTENIDXCLR	(PRUSS_INTC_BASE_ADDRESS + 0x38)
+#define PRUSS_INTC_GLBLPRIIDX		(PRUSS_INTC_BASE_ADDRESS + 0x80)
+#define PRUSS_INTC_STATSETINT0		(PRUSS_INTC_BASE_ADDRESS + 0x200)
+#define PRUSS_INTC_STATSETINT1		(PRUSS_INTC_BASE_ADDRESS + 0x204)
+#define PRUSS_INTC_STATCLRINT0		(PRUSS_INTC_BASE_ADDRESS + 0x280)
+#define PRUSS_INTC_STATCLRINT1		(PRUSS_INTC_BASE_ADDRESS + 0x284)
+#define PRUSS_INTC_ENABLESET0		(PRUSS_INTC_BASE_ADDRESS + 0x300)
+#define PRUSS_INTC_ENABLESET1		(PRUSS_INTC_BASE_ADDRESS + 0x304)
+#define PRUSS_INTC_ENABLECLR0		(PRUSS_INTC_BASE_ADDRESS + 0x380)
+#define PRUSS_INTC_ENABLECLR1		(PRUSS_INTC_BASE_ADDRESS + 0x384)
+#define PRUSS_INTC_CHANMAP0		(PRUSS_INTC_BASE_ADDRESS + 0x400)
+#define PRUSS_INTC_CHANMAP1		(PRUSS_INTC_BASE_ADDRESS + 0x404)
+#define PRUSS_INTC_CHANMAP2		(PRUSS_INTC_BASE_ADDRESS + 0x408)
+#define PRUSS_INTC_CHANMAP3		(PRUSS_INTC_BASE_ADDRESS + 0x40C)
+#define PRUSS_INTC_CHANMAP4		(PRUSS_INTC_BASE_ADDRESS + 0x410)
+#define PRUSS_INTC_CHANMAP5		(PRUSS_INTC_BASE_ADDRESS + 0x414)
+#define PRUSS_INTC_CHANMAP6		(PRUSS_INTC_BASE_ADDRESS + 0x418)
+#define PRUSS_INTC_CHANMAP7		(PRUSS_INTC_BASE_ADDRESS + 0x41C)
+#define PRUSS_INTC_CHANMAP8		(PRUSS_INTC_BASE_ADDRESS + 0x420)
+#define PRUSS_INTC_CHANMAP9		(PRUSS_INTC_BASE_ADDRESS + 0x424)
+#define PRUSS_INTC_CHANMAP10		(PRUSS_INTC_BASE_ADDRESS + 0x428)
+#define PRUSS_INTC_CHANMAP11		(PRUSS_INTC_BASE_ADDRESS + 0x42C)
+#define PRUSS_INTC_CHANMAP12		(PRUSS_INTC_BASE_ADDRESS + 0x430)
+#define PRUSS_INTC_CHANMAP13		(PRUSS_INTC_BASE_ADDRESS + 0x434)
+#define PRUSS_INTC_CHANMAP14		(PRUSS_INTC_BASE_ADDRESS + 0x438)
+#define PRUSS_INTC_CHANMAP15		(PRUSS_INTC_BASE_ADDRESS + 0x43C)
+#define PRUSS_INTC_HOSTMAP0		(PRUSS_INTC_BASE_ADDRESS + 0x800)
+#define PRUSS_INTC_HOSTMAP1		(PRUSS_INTC_BASE_ADDRESS + 0x804)
+#define PRUSS_INTC_HOSTMAP2		(PRUSS_INTC_BASE_ADDRESS + 0x808)
+#define PRUSS_INTC_POLARITY0		(PRUSS_INTC_BASE_ADDRESS + 0xD00)
+#define PRUSS_INTC_POLARITY1		(PRUSS_INTC_BASE_ADDRESS + 0xD04)
+#define PRUSS_INTC_TYPE0		(PRUSS_INTC_BASE_ADDRESS + 0xD80)
+#define PRUSS_INTC_TYPE1		(PRUSS_INTC_BASE_ADDRESS + 0xD84)
+#define PRUSS_INTC_HOSTINTEN		(PRUSS_INTC_BASE_ADDRESS + 0x1500)
+#define PRUSS_INTC_HOSTINTLVL_MAX	9
+
+#define PRU_INTC_CHAN_123_HOST		(0x03020100)
+#define PRU_INTC_CHAN_4567_HOST		(0x07060504)
+#define PRU_INTC_CHAN_89_HOST		(0x00000908)
+
+#define PRU_INTC_CHAN_0_SYSEVT_31	(0x00000000)
+#define PRU_INTC_CHAN_12_SYSEVT		(0x02020100)
+#define PRU_INTC_CHAN_34_SYSEVT_36_39	(0x04040303)
+#define PRU_INTC_CHAN_56_SYSEVT_40_43	(0x06060505)
+#define PRU_INTC_CHAN_78_SYSEVT_44_47	(0x08080707)
+#define PRU_INTC_CHAN_9_SYSEVT_48_49	(0x00010909)
+#define PRU_INTC_CHAN_0123_SYSEVT_32_35	(0x03020100)
+#define PRU_INTC_CHAN_4567_SYSEVT_36_39	(0x07060504)
+#define PRU_INTC_CHAN_8923_SYSEVT_40_43	(0x03020908)
+#define PRU_INTC_CHAN_4567_SYSEVT_44_47	(0x07060504)
+
+struct da8xx_pruss_devices {
+	const char *dev_name;
+	void *pdata;
+	size_t pdata_size;
+	int (*setup)(void);
+};
+
+u32 pruss_get_clk_freq(struct device *dev);
+
+u32 pruss_enable(struct device *dev, u8 pruss_num);
+
+u32 pruss_load(struct device *dev, u8 pruss_num, u32 *pruss_code,
+			u32 code_size_in_words);
+
+u32 pruss_run(struct device *dev, u8 pruss_num);
+
+u32 pruss_wait_for_halt(struct device *dev, u8 pruss_num, u32 timeout);
+
+u32 pruss_disable(struct device *dev, u8 pruss_num);
+
+s16 pruss_writeb(struct device *dev, u32 u32offset,
+			u8 *pu8datatowrite, u16 u16wordstowrite);
+
+s16 pruss_readb(struct device *dev, u32 u32offset,
+			u8 *pu8datatoread, u16 u16wordstoread);
+
+s16 pruss_readl(struct device *dev, u32 u32offset,
+			u32 *pu32datatoread, s16 s16wordstoread);
+
+s16 pruss_writel(struct device *dev, u32 u32offset,
+			u32 *pu32datatoread, s16 s16wordstoread);
+
+s16 pruss_writew(struct device *dev, u32 u32offset,
+			u16 *u16datatowrite, s16 u16wordstowrite);
+
+s16 pruss_readw(struct device *dev, u32 u32offset,
+			u16 *pu32datatoread, s16 u16wordstoread);
+#endif	/* End _PRUSS_H_ */
diff --git a/include/linux/mfd/pruss/da8xx_prucore.h b/include/linux/mfd/pruss/da8xx_prucore.h
new file mode 100644
index 0000000..81f2ff9
--- /dev/null
+++ b/include/linux/mfd/pruss/da8xx_prucore.h
@@ -0,0 +1,74 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
+ *
+ * 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 _DA8XX_PRUCORE_H_
+#define _DA8XX_PRUCORE_H_
+
+#include <linux/types.h>
+
+#define DA8XX_PRUCORE_0		(0)
+#define DA8XX_PRUCORE_1		(1)
+
+#define DA8XX_PRUCORE_CONTROL_PCRESETVAL_MASK			(0xFFFF0000u)
+#define DA8XX_PRUCORE_CONTROL_PCRESETVAL_SHIFT			(0x00000010u)
+#define DA8XX_PRUCORE_CONTROL_PCRESETVAL_RESETVAL		(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_RUNSTATE_MASK			(0x00008000u)
+#define DA8XX_PRUCORE_CONTROL_RUNSTATE_SHIFT			(0x0000000Fu)
+#define DA8XX_PRUCORE_CONTROL_RUNSTATE_RESETVAL			(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_RUNSTATE_HALT			(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_RUNSTATE_RUN			(0x00000001u)
+#define DA8XX_PRUCORE_CONTROL_SINGLESTEP_MASK			(0x00000100u)
+#define DA8XX_PRUCORE_CONTROL_SINGLESTEP_SHIFT			(0x00000008u)
+#define DA8XX_PRUCORE_CONTROL_SINGLESTEP_RESETVAL		(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_SINGLESTEP_FREERUN		(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_SINGLESTEP_SINGLE			(0x00000001u)
+#define DA8XX_PRUCORE_CONTROL_COUNTENABLE_MASK			(0x00000008u)
+#define DA8XX_PRUCORE_CONTROL_COUNTENABLE_SHIFT			(0x00000003u)
+#define DA8XX_PRUCORE_CONTROL_COUNTENABLE_RESETVAL		(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_COUNTENABLE_DISABLE		(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_COUNTENABLE_ENABLE		(0x00000001u)
+#define DA8XX_PRUCORE_CONTROL_SLEEPING_MASK			(0x00000004u)
+#define DA8XX_PRUCORE_CONTROL_SLEEPING_SHIFT			(0x00000002u)
+#define DA8XX_PRUCORE_CONTROL_SLEEPING_RESETVAL			(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_SLEEPING_NOTASLEEP		(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_SLEEPING_ASLEEP			(0x00000001u)
+#define DA8XX_PRUCORE_CONTROL_ENABLE_MASK			(0x00000002u)
+#define DA8XX_PRUCORE_CONTROL_ENABLE_SHIFT			(0x00000001u)
+#define DA8XX_PRUCORE_CONTROL_ENABLE_RESETVAL			(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_ENABLE_DISABLE			(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_ENABLE_ENABLE			(0x00000001u)
+#define DA8XX_PRUCORE_CONTROL_SOFTRESET_MASK			(0x00000001u)
+#define DA8XX_PRUCORE_CONTROL_SOFTRESET_SHIFT			(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_SOFTRESET_RESETVAL		(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_SOFTRESET_RESET			(0x00000000u)
+#define DA8XX_PRUCORE_CONTROL_SOFTRESET_OUT_OF_RESET		(0x00000001u)
+#define DA8XX_PRUCORE_CONTROL_RESETVAL				(0x00000000u)
+
+typedef struct {
+	u32 CONTROL;
+	u32 STATUS;
+	u32 WAKEUP;
+	u32 CYCLECNT;
+	u32 STALLCNT;
+	u8  RSVD0[12];
+	u32 CONTABBLKIDX0;
+	u32 CONTABBLKIDX1;
+	u32 CONTABPROPTR0;
+	u32 CONTABPROPTR1;
+	u8  RSVD1[976];
+	u32 INTGPR[32];
+	u32 INTCTER[32];
+} *da8xx_prusscore_regs;
+
+#endif
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:21 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:21 +0530
Subject: [PATCH v2 02/13] da850: pruss platform specific additions.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-3-git-send-email-subhasish@mistralsolutions.com>

This patch adds the platform device and assignes the platform resources
for the PRUSS mfd driver.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/da850.c              |    7 +++
 arch/arm/mach-davinci/devices-da8xx.c      |   65 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    2 +
 3 files changed, 74 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 8a4de97..a098263 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -238,6 +238,12 @@ static struct clk tptc2_clk = {
 	.flags		= ALWAYS_ENABLED,
 };
 
+static struct clk pruss_clk = {
+	.name		= "pruss",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_PRUSS,
+};
+
 static struct clk uart0_clk = {
 	.name		= "uart0",
 	.parent		= &pll0_sysclk2,
@@ -387,6 +393,7 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
 	CLK(NULL,		"uart0",	&uart0_clk),
+	CLK(NULL,		"pruss",	&pruss_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
 	CLK(NULL,		"aintc",	&aintc_clk),
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..e15de72 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -20,6 +20,7 @@
 #include <mach/time.h>
 #include <mach/da8xx.h>
 #include <mach/cpuidle.h>
+#include <linux/mfd/pruss/da8xx_pru.h>
 
 #include "clock.h"
 
@@ -499,6 +500,70 @@ void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
 	}
 }
 
+#define DA8XX_PRUSS_MEM_BASE		0x01C30000
+
+static struct resource da8xx_pruss_resources[] = {
+	{
+		.name	= "da8xx_pruss",
+		.start	= DA8XX_PRUSS_MEM_BASE,
+		.end	= DA8XX_PRUSS_MEM_BASE + 0xFFFF,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT0,
+		.end	= IRQ_DA8XX_EVTOUT0,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT1,
+		.end	= IRQ_DA8XX_EVTOUT1,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT2,
+		.end	= IRQ_DA8XX_EVTOUT2,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT3,
+		.end	= IRQ_DA8XX_EVTOUT3,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT4,
+		.end	= IRQ_DA8XX_EVTOUT4,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT5,
+		.end	= IRQ_DA8XX_EVTOUT5,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT6,
+		.end	= IRQ_DA8XX_EVTOUT6,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT7,
+		.end	= IRQ_DA8XX_EVTOUT7,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+struct platform_device da8xx_pruss_dev = {
+	.name		= "da8xx_pruss",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(da8xx_pruss_resources),
+	.resource	= da8xx_pruss_resources,
+};
+
+int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
+{
+	da8xx_pruss_dev.dev.platform_data = pruss_device;
+	return platform_device_register(&da8xx_pruss_dev);
+}
+
 static const struct display_panel disp_panel = {
 	QVGA,
 	16,
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index c3c3339..2c400d4 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -15,6 +15,7 @@
 
 #include <linux/platform_device.h>
 #include <linux/davinci_emac.h>
+#include <linux/mfd/pruss/da8xx_pru.h>
 
 #include <mach/serial.h>
 #include <mach/edma.h>
@@ -82,6 +83,7 @@ int da8xx_register_watchdog(void);
 int da8xx_register_usb20(unsigned mA, unsigned potpgt);
 int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
 int da8xx_register_emac(void);
+int da8xx_register_pruss(struct da8xx_pruss_devices *);
 int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
 int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
 int da850_register_mmcsd1(struct davinci_mmc_config *config);
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:22 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:22 +0530
Subject: [PATCH v2 03/13] da850: pruss board specific additions.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-4-git-send-email-subhasish@mistralsolutions.com>

This patch adds board specific initializations and setup routines.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..242d1ed 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1053,6 +1053,26 @@ static __init int da850_evm_init_cpufreq(void)
 static __init int da850_evm_init_cpufreq(void) { return 0; }
 #endif
 
+static struct da8xx_pruss_devices pruss_devices[] = {
+	{.dev_name = NULL,},
+};
+
+static int __init da8xx_evm_setup_pruss(void)
+{
+	u32 ret = 0;
+	u32 count;
+
+	for (count = 0; count < ARRAY_SIZE(pruss_devices); count++) {
+		if (pruss_devices[count].setup != NULL) {
+			ret = pruss_devices[count].setup();
+			if (ret)
+				return ret;
+		}
+	}
+
+	return da8xx_register_pruss(pruss_devices);
+}
+
 static __init void da850_evm_init(void)
 {
 	int ret;
@@ -1127,6 +1147,11 @@ static __init void da850_evm_init(void)
 
 	da8xx_register_mcasp(0, &da850_evm_snd_data);
 
+	ret = da8xx_evm_setup_pruss();
+	if (ret)
+		pr_warning("%s: pruss initialization failed: %d\n",
+				__func__, ret);
+
 	ret = davinci_cfg_reg_list(da850_lcdcntl_pins);
 	if (ret)
 		pr_warning("da850_evm_init: lcdcntl mux setup failed: %d\n",
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:23 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:23 +0530
Subject: [PATCH v2 04/13] mfd: pruss CAN private data.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-5-git-send-email-subhasish@mistralsolutions.com>

This patch adds the PRUSS CAN data.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 include/linux/mfd/pruss/da8xx_pru.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/linux/mfd/pruss/da8xx_pru.h b/include/linux/mfd/pruss/da8xx_pru.h
index 68d8421..50f2ede 100644
--- a/include/linux/mfd/pruss/da8xx_pru.h
+++ b/include/linux/mfd/pruss/da8xx_pru.h
@@ -89,6 +89,10 @@ struct da8xx_pruss_devices {
 	int (*setup)(void);
 };
 
+struct da8xx_pruss_can_data {
+	u32 version;
+};
+
 u32 pruss_get_clk_freq(struct device *dev);
 
 u32 pruss_enable(struct device *dev, u8 pruss_num);
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:24 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:24 +0530
Subject: [PATCH v2 05/13] da850: pruss CAN platform specific additions.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-6-git-send-email-subhasish@mistralsolutions.com>

This patch adds the necessary pins for the pruss CAN.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/da850.c            |    4 ++++
 arch/arm/mach-davinci/include/mach/mux.h |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index a098263..4862c28 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -565,6 +565,10 @@ static const struct mux_config da850_pins[] = {
 	MUX_CFG(DA850, EMA_CLK,		6,	0,	15,	1,	false)
 	MUX_CFG(DA850, EMA_WAIT_1,	6,	24,	15,	1,	false)
 	MUX_CFG(DA850, NEMA_CS_2,	7,	0,	15,	1,	false)
+	/* PRU functions for soft CAN */
+	MUX_CFG(DA850, PRUSS_PRU0_R31_0,	7,	28,	15,	0,	false)
+	MUX_CFG(DA850, PRUSS_PRU1_R30_15,	12,	0,	15,	4,	false)
+	MUX_CFG(DA850, PRUSS_PRU1_R31_18,	11,	20,	15,	0,	false)
 	/* GPIO function */
 	MUX_CFG(DA850, GPIO2_4,		6,	12,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_6,		6,	4,	15,	8,	false)
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index 5d4e0fe..10f49f2 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -906,6 +906,10 @@ enum davinci_da850_index {
 	DA850_EMA_CLK,
 	DA850_EMA_WAIT_1,
 	DA850_NEMA_CS_2,
+	/* PRU I/O */
+	DA850_PRUSS_PRU0_R31_0,
+	DA850_PRUSS_PRU1_R30_15,
+	DA850_PRUSS_PRU1_R31_18,
 
 	/* GPIO function */
 	DA850_GPIO2_4,
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:25 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:25 +0530
Subject: [PATCH v2 06/13] da850: pruss CAN board specific additions.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-7-git-send-email-subhasish@mistralsolutions.com>

This patch adds the pruss CAN pin mux and registers the device
with the pruss mfd driver.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   37 ++++++++++++++++++++++++++++++-
 1 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 242d1ed..2ce5536 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1053,8 +1053,43 @@ static __init int da850_evm_init_cpufreq(void)
 static __init int da850_evm_init_cpufreq(void) { return 0; }
 #endif
 
+const short da850_evm_pruss_can_pins[] = {
+	DA850_PRUSS_PRU0_R31_0, DA850_PRUSS_PRU1_R30_15,
+	DA850_PRUSS_PRU1_R31_18,
+	-1
+};
+
+static int __init da850_evm_setup_pruss_can(void)
+{
+	int ret, val = 0;
+	void __iomem *cfg_chip3_reg;
+
+	ret = davinci_cfg_reg_list(da850_evm_pruss_can_pins);
+	if (ret)
+		pr_warning("%s: da850_evm_pruss_can_pins mux setup "
+					"failed:%d\n", __func__, ret);
+	cfg_chip3_reg = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+	val = __raw_readl(cfg_chip3_reg);
+	val |= BIT(3);
+	__raw_writel(val, cfg_chip3_reg);
+
+	return ret;
+}
+
+static struct da8xx_pruss_can_data can_data = {
+	.version	= 1,
+};
+
 static struct da8xx_pruss_devices pruss_devices[] = {
-	{.dev_name = NULL,},
+	{
+		.dev_name	= "da8xx_pruss_can",
+		.pdata		= &can_data,
+		.pdata_size	= sizeof(can_data),
+		.setup		= da850_evm_setup_pruss_can,
+	},
+	{
+		.dev_name	= NULL,
+	},
 };
 
 static int __init da8xx_evm_setup_pruss(void)
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:26 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:26 +0530
Subject: [PATCH v2 07/13] da850: pruss CAN platform specific changes for gpios.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-8-git-send-email-subhasish@mistralsolutions.com>

This patch adds the GPIOs for the pruss CAN device.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/da850.c            |    1 +
 arch/arm/mach-davinci/include/mach/mux.h |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4862c28..a15571d 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -570,6 +570,7 @@ static const struct mux_config da850_pins[] = {
 	MUX_CFG(DA850, PRUSS_PRU1_R30_15,	12,	0,	15,	4,	false)
 	MUX_CFG(DA850, PRUSS_PRU1_R31_18,	11,	20,	15,	0,	false)
 	/* GPIO function */
+	MUX_CFG(DA850, GPIO2_0,		6,	28,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_4,		6,	12,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_6,		6,	4,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_8,		5,	28,	15,	8,	false)
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index 10f49f2..85b3a0d 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -912,6 +912,7 @@ enum davinci_da850_index {
 	DA850_PRUSS_PRU1_R31_18,
 
 	/* GPIO function */
+	DA850_GPIO2_0,
 	DA850_GPIO2_4,
 	DA850_GPIO2_6,
 	DA850_GPIO2_8,
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:27 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:27 +0530
Subject: [PATCH v2 08/13] da850: pruss CAN board specific changes for gpios.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-9-git-send-email-subhasish@mistralsolutions.com>

This patch adds the GPIO modifications required for the pruss CAN.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 2ce5536..f9c38f8 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -45,6 +45,7 @@
 
 #define DA850_MMCSD_CD_PIN		GPIO_TO_PIN(4, 0)
 #define DA850_MMCSD_WP_PIN		GPIO_TO_PIN(4, 1)
+#define DA850_PRUSS_CAN_TRX_PIN	GPIO_TO_PIN(2, 0)
 
 #define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
 
@@ -1055,7 +1056,7 @@ static __init int da850_evm_init_cpufreq(void) { return 0; }
 
 const short da850_evm_pruss_can_pins[] = {
 	DA850_PRUSS_PRU0_R31_0, DA850_PRUSS_PRU1_R30_15,
-	DA850_PRUSS_PRU1_R31_18,
+	DA850_PRUSS_PRU1_R31_18, DA850_GPIO2_0,
 	-1
 };
 
@@ -1073,6 +1074,14 @@ static int __init da850_evm_setup_pruss_can(void)
 	val |= BIT(3);
 	__raw_writel(val, cfg_chip3_reg);
 
+	/* value = 0 to enable the CAN transceiver */
+	ret = gpio_request_one(DA850_PRUSS_CAN_TRX_PIN,
+					GPIOF_OUT_INIT_LOW, "pruss_can_en");
+	if (ret) {
+		pr_warning("Cannot setup GPIO %d\n", DA850_PRUSS_CAN_TRX_PIN);
+		gpio_free(DA850_PRUSS_CAN_TRX_PIN);
+	}
+
 	return ret;
 }
 
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:28 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:28 +0530
Subject: [PATCH v2 09/13] can: pruss CAN driver.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>

This patch adds support for the CAN device emulated on PRUSS.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 drivers/net/can/Kconfig                     |    1 +
 drivers/net/can/Makefile                    |    1 +
 drivers/net/can/da8xx_pruss/Kconfig         |   73 ++
 drivers/net/can/da8xx_pruss/Makefile        |    7 +
 drivers/net/can/da8xx_pruss/pruss_can.c     |  758 +++++++++++++++++
 drivers/net/can/da8xx_pruss/pruss_can_api.c | 1227 +++++++++++++++++++++++++++
 drivers/net/can/da8xx_pruss/pruss_can_api.h |  290 +++++++
 7 files changed, 2357 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/can/da8xx_pruss/Kconfig
 create mode 100644 drivers/net/can/da8xx_pruss/Makefile
 create mode 100644 drivers/net/can/da8xx_pruss/pruss_can.c
 create mode 100644 drivers/net/can/da8xx_pruss/pruss_can_api.c
 create mode 100644 drivers/net/can/da8xx_pruss/pruss_can_api.h

diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index d5a9db6..ae8f0f9 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -112,6 +112,7 @@ config PCH_CAN
 	  This driver can access CAN bus.
 
 source "drivers/net/can/mscan/Kconfig"
+source "drivers/net/can/da8xx_pruss/Kconfig"
 
 source "drivers/net/can/sja1000/Kconfig"
 
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index 07ca159..849cdbf 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_CAN_SJA1000)	+= sja1000/
 obj-$(CONFIG_CAN_MSCAN)		+= mscan/
 obj-$(CONFIG_CAN_AT91)		+= at91_can.o
 obj-$(CONFIG_CAN_TI_HECC)	+= ti_hecc.o
+obj-$(CONFIG_CAN_TI_DA8XX_PRU)	+= da8xx_pruss/
 obj-$(CONFIG_CAN_MCP251X)	+= mcp251x.o
 obj-$(CONFIG_CAN_BFIN)		+= bfin_can.o
 obj-$(CONFIG_CAN_JANZ_ICAN3)	+= janz-ican3.o
diff --git a/drivers/net/can/da8xx_pruss/Kconfig b/drivers/net/can/da8xx_pruss/Kconfig
new file mode 100644
index 0000000..8b68f68
--- /dev/null
+++ b/drivers/net/can/da8xx_pruss/Kconfig
@@ -0,0 +1,73 @@
+#
+# CAN Lite Kernel Configuration
+#
+config CAN_TI_DA8XX_PRU
+	depends on CAN_DEV && ARCH_DAVINCI && ARCH_DAVINCI_DA850
+	tristate "PRU based CAN emulation for DA8XX"
+	---help---
+	Enable this to emulate a CAN controller on the PRU of DA8XX.
+	If not sure, mark N
+
+config DA8XX_PRU_CANID_MBX0
+	hex "CANID for mailbox 0"
+	depends on CAN_TI_DA8XX_PRU
+	default "0x123"
+	---help---
+	Enter the CANID for mailbox 0
+	Default value is set to 0x123, change this as required.
+
+config DA8XX_PRU_CANID_MBX1
+	hex "CANID for mailbox 1"
+	depends on CAN_TI_DA8XX_PRU
+	default "0x123"
+	 ---help---
+	Enter the CANID for mailbox 1
+	Default value is set to 0x123, change this as required.
+
+config DA8XX_PRU_CANID_MBX2
+	hex "CANID for mailbox 2"
+	depends on CAN_TI_DA8XX_PRU
+	default "0x123"
+	---help---
+	Enter the CANID for mailbox 2
+	Default value is set to 0x123, change this as required.
+
+config DA8XX_PRU_CANID_MBX3
+	hex "CANID for mailbox 3"
+	depends on CAN_TI_DA8XX_PRU
+	default "0x123"
+	---help---
+	Enter the CANID for mailbox 3
+	Default value is set to 0x123, change this as required.
+
+config DA8XX_PRU_CANID_MBX4
+	hex "CANID for mailbox 4"
+	depends on CAN_TI_DA8XX_PRU
+	default "0x123"
+	---help---
+	Enter the CANID for mailbox 4
+	Default value is set to 0x123, change this as required.
+
+config DA8XX_PRU_CANID_MBX5
+	hex "CANID for mailbox 5"
+	depends on CAN_TI_DA8XX_PRU
+	default "0x123"
+	---help---
+	Enter the CANID for mailbox 5
+	Default value is set to 0x123, change this as required.
+
+config DA8XX_PRU_CANID_MBX6
+	hex "CANID for mailbox 6"
+	depends on CAN_TI_DA8XX_PRU
+	default "0x123"
+	---help---
+	Enter the CANID for mailbox 6
+	Default value is set to 0x123, change this as required.
+
+config DA8XX_PRU_CANID_MBX7
+	hex "CANID for mailbox 7"
+	depends on CAN_TI_DA8XX_PRU
+	default "0x123"
+	---help---
+	Enter the CANID for mailbox 7
+	Default value is set to 0x123, change this as required.
diff --git a/drivers/net/can/da8xx_pruss/Makefile b/drivers/net/can/da8xx_pruss/Makefile
new file mode 100644
index 0000000..48f3055
--- /dev/null
+++ b/drivers/net/can/da8xx_pruss/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for CAN Lite emulation
+#
+can_emu-objs :=   pruss_can.o \
+                  pruss_can_api.o
+
+obj-$(CONFIG_CAN_TI_DA8XX_PRU)    += can_emu.o
diff --git a/drivers/net/can/da8xx_pruss/pruss_can.c b/drivers/net/can/da8xx_pruss/pruss_can.c
new file mode 100644
index 0000000..1b3afde
--- /dev/null
+++ b/drivers/net/can/da8xx_pruss/pruss_can.c
@@ -0,0 +1,758 @@
+/*
+ *  TI DA8XX PRU CAN Emulation device driver
+ *  Author: subhasish at mistralsolutions.com
+ *
+ *  This driver supports TI's PRU CAN Emulation and the
+ *  specs for the same is available at <http://www.ti.com>
+ *
+ *  Copyright (C) 2009 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 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/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/errno.h>
+#include <linux/netdevice.h>
+#include <linux/skbuff.h>
+#include <linux/platform_device.h>
+#include <linux/firmware.h>
+#include <linux/clk.h>
+#include <linux/types.h>
+
+#include <linux/can.h>
+#include <linux/can/dev.h>
+#include <linux/can/error.h>
+#include <mach/da8xx.h>
+#include "pruss_can_api.h"
+
+#define DRV_NAME "da8xx_pruss_can"
+#define DRV_DESC "TI PRU CAN Controller Driver v0.1"
+#define PRU_CAN_START		1
+#define PRU_CAN_STOP		0
+#define MB_MIN			0
+#define MB_MAX			7
+
+#define PRU_CANMID_IDE			BIT(29)	/* Extended frame format */
+
+#define PRU_CAN_ISR_BIT_CCI		BIT(15)
+#define PRU_CAN_ISR_BIT_ESI		BIT(14)
+#define PRU_CAN_ISR_BIT_SRDI		BIT(13)
+#define PRU_CAN_ISR_BIT_RRI		BIT(8)
+
+#define PRU_CAN_MBXSR_BIT_STATE		BIT(7)
+#define PRU_CAN_MBXSR_BIT_TC		BIT(6)
+#define PRU_CAN_MBXSR_BIT_ERR		BIT(5)
+#define PRU_CAN_MBXSR_BIT_OF		BIT(0)
+
+#define PRU_CAN_GSR_BIT_TXM		BIT(7)
+#define PRU_CAN_GSR_BIT_RXM		BIT(6)
+#define PRU_CAN_GSR_BIT_CM		BIT(5)
+#define PRU_CAN_GSR_BIT_EPM		BIT(4)
+#define PRU_CAN_GSR_BIT_BFM		BIT(3)
+#define RTR_MBX_NO			8
+#define MAX_INIT_RETRIES		20
+#define L138_PRU_ARM_FREQ		312000
+#define DFLT_PRU_FREQ			156000000
+#define DFLT_PRU_BITRATE		125000
+
+#define CONFIG_DA8XX_PRU_CANID_MBX0	0x123
+#define CONFIG_DA8XX_PRU_CANID_MBX1	0x123
+#define CONFIG_DA8XX_PRU_CANID_MBX2	0x123
+#define CONFIG_DA8XX_PRU_CANID_MBX3	0x123
+#define CONFIG_DA8XX_PRU_CANID_MBX4	0x123
+#define CONFIG_DA8XX_PRU_CANID_MBX5	0x123
+#define CONFIG_DA8XX_PRU_CANID_MBX6	0x123
+#define CONFIG_DA8XX_PRU_CANID_MBX7	0x123
+
+#ifdef __CAN_DEBUG
+#define __can_debug(fmt, args...) printk(KERN_DEBUG "can_debug: " fmt, ## args)
+#else
+#define __can_debug(fmt, args...)
+#endif
+#define __can_err(fmt, args...) printk(KERN_ERR "can_err: " fmt, ## args)
+
+/*
+ * omapl_pru can private data
+ */
+struct omapl_pru_can_priv {
+	struct can_priv can;
+	struct workqueue_struct *pru_can_wQ;
+	struct work_struct rx_work;
+	struct net_device *ndev;
+	struct device *dev; /* pdev->dev */
+	struct clk *clk_timer;
+	u32 timer_freq;
+	can_emu_app_hndl can_tx_hndl;
+	can_emu_app_hndl can_rx_hndl;
+	const struct firmware *fw_rx;
+	const struct firmware *fw_tx;
+	spinlock_t mbox_lock;
+	u32 trx_irq;
+	u32 tx_head;
+	u32 tx_tail;
+	u32 tx_next;
+	u32 rx_next;
+};
+
+static int omapl_pru_can_get_state(const struct net_device *ndev,
+				   enum can_state *state)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	*state = priv->can.state;
+	return 0;
+}
+
+static int omapl_pru_can_set_bittiming(struct net_device *ndev)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	struct can_bittiming *bt = &priv->can.bittiming;
+	long bit_error = 0;
+
+	if (priv->can.ctrlmode & CAN_CTRLMODE_3_SAMPLES) {
+		dev_warn(priv->dev, "WARN: Triple"
+			 "sampling not set due to h/w limitations");
+	}
+	if (pru_can_calc_timing(priv->dev, priv->can.clock.freq,
+				bt->bitrate) != 0)
+		return -EINVAL;
+	bit_error =
+	    (((priv->timer_freq / (priv->timer_freq / bt->bitrate)) -
+	      bt->bitrate) * 1000) / bt->bitrate;
+	if (bit_error) {
+		bit_error =
+		    (((priv->timer_freq / (priv->timer_freq / bt->bitrate)) -
+		      bt->bitrate) * 1000000) / bt->bitrate;
+		printk(KERN_INFO "\nBitrate error %ld.%ld%%\n",
+			bit_error / 10000, bit_error % 1000);
+	} else
+		printk(KERN_INFO "\nBitrate error 0.0%%\n");
+
+	return 0;
+}
+
+static void omapl_pru_can_stop(struct net_device *ndev)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	u16 int_mask = 0;
+
+	pru_can_mask_ints(priv->dev, int_mask);	/* mask all ints */
+	pru_can_start_abort_tx(priv->dev, PRU_CAN_STOP);
+	priv->can.state = CAN_STATE_STOPPED;
+}
+
+/*
+ * This is to just set the can state to ERROR_ACTIVE
+ *	ip link set canX up type can bitrate 125000
+ */
+static void omapl_pru_can_start(struct net_device *ndev)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	u16 int_mask = 0xFFFF;
+
+	if (priv->can.state != CAN_STATE_STOPPED)
+		omapl_pru_can_stop(ndev);
+
+	pru_can_mask_ints(priv->dev, int_mask);	/* unmask all ints */
+
+	pru_can_get_global_status(priv->dev, &priv->can_tx_hndl);
+	pru_can_get_global_status(priv->dev, &priv->can_rx_hndl);
+
+	if (PRU_CAN_GSR_BIT_EPM & priv->can_tx_hndl.u32globalstatus)
+		priv->can.state = CAN_STATE_ERROR_PASSIVE;
+	else if (PRU_CAN_GSR_BIT_BFM & priv->can_tx_hndl.u32globalstatus)
+		priv->can.state = CAN_STATE_BUS_OFF;
+	else
+		priv->can.state = CAN_STATE_ERROR_ACTIVE;
+}
+
+static int omapl_pru_can_set_mode(struct net_device *ndev, enum can_mode mode)
+{
+	int ret = 0;
+
+	switch (mode) {
+	case CAN_MODE_START:
+		omapl_pru_can_start(ndev);
+		if (netif_queue_stopped(ndev))
+			netif_wake_queue(ndev);
+		break;
+	case CAN_MODE_STOP:
+		omapl_pru_can_stop(ndev);
+		if (!netif_queue_stopped(ndev))
+			netif_stop_queue(ndev);
+		break;
+	default:
+		ret = -EOPNOTSUPP;
+		break;
+	}
+	return ret;
+}
+
+static netdev_tx_t omapl_pru_can_start_xmit(struct sk_buff *skb,
+					    struct net_device *ndev)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	struct can_frame *cf = (struct can_frame *)skb->data;
+	int count;
+	u8 *data = cf->data;
+	u8 dlc = cf->can_dlc;
+	u8 *ptr8data = NULL;
+
+	netif_stop_queue(ndev);
+	if (cf->can_id & CAN_EFF_FLAG)	/* Extended frame format */
+		*((u32 *) &priv->can_tx_hndl.strcanmailbox) =
+		    (cf->can_id & CAN_EFF_MASK) | PRU_CANMID_IDE;
+	else			/* Standard frame format */
+		*((u32 *) &priv->can_tx_hndl.strcanmailbox) =
+		    (cf->can_id & CAN_SFF_MASK) << 18;
+
+	if (cf->can_id & CAN_RTR_FLAG)	/* Remote transmission request */
+		*((u32 *) &priv->can_tx_hndl.strcanmailbox) |= CAN_RTR_FLAG;
+
+	ptr8data = &priv->can_tx_hndl.strcanmailbox.u8data7 + (dlc - 1);
+	for (count = 0; count < (u8) dlc; count++) {
+		*ptr8data-- = *data++;
+	}
+	*((u32 *) &priv->can_tx_hndl.strcanmailbox.u16datalength) = (u32) dlc;
+/*
+ * search for the next available mbx
+ * if the next mbx is busy, then try the next + 1
+ * do this until the head is reached.
+ * if still unable to tx, stop accepting any packets
+ * if able to tx and the head is reached, then reset next to tail, i.e mbx0
+ * if head is not reached, then just point to the next mbx
+ */
+	for (; priv->tx_next <= priv->tx_head; priv->tx_next++) {
+		priv->can_tx_hndl.ecanmailboxnumber =
+		    (can_mailbox_number) priv->tx_next;
+		if (-1 == pru_can_write_data_to_mailbox(priv->dev,
+					&priv->can_tx_hndl)) {
+			if (priv->tx_next == priv->tx_head) {
+				priv->tx_next = priv->tx_tail;
+				if (!netif_queue_stopped(ndev))
+					netif_stop_queue(ndev);	/* IF stalled */
+				dev_err(priv->dev,
+					"%s: no tx mbx available", __func__);
+				return NETDEV_TX_BUSY;
+			} else
+				continue;
+		} else {
+			/* set transmit request */
+			pru_can_tx(priv->dev, priv->tx_next, CAN_TX_PRU_1);
+			pru_can_tx_mode_set(priv->dev, false, ecanreceive);
+			pru_can_tx_mode_set(priv->dev, true, ecantransmit);
+			pru_can_start_abort_tx(priv->dev, PRU_CAN_START);
+			priv->tx_next++;
+			can_put_echo_skb(skb, ndev, 0);
+			break;
+		}
+	}
+	if (priv->tx_next > priv->tx_head) {
+		priv->tx_next = priv->tx_tail;
+	}
+	return NETDEV_TX_OK;
+}
+
+static int omapl_pru_can_rx(struct net_device *ndev, u32 mbxno)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	struct net_device_stats *stats = &ndev->stats;
+	struct can_frame *cf;
+	struct sk_buff *skb;
+	u32 pru_can_mbx_data;
+	u8 *data = NULL;
+	u8 *ptr8data = NULL;
+	int count = 0;
+
+	skb = alloc_can_skb(ndev, &cf);
+	if (!skb) {
+		if (printk_ratelimit())
+			dev_err(priv->dev,
+				"alloc_can_skb() failed\n");
+		return -ENOMEM;
+	}
+	data = cf->data;
+	/*      get payload */
+	priv->can_rx_hndl.ecanmailboxnumber = (can_mailbox_number) mbxno;
+	if (pru_can_get_data_from_mailbox(priv->dev, &priv->can_rx_hndl)) {
+		__can_err("failed to get data from mailbox\n");
+		return -EAGAIN;
+	}
+	/* give ownweship to pru */
+	pru_can_tx(priv->dev, mbxno, CAN_RX_PRU_0);
+
+	/* get data length code */
+	cf->can_dlc =
+	    get_can_dlc(*
+			((u32 *) &priv->can_rx_hndl.strcanmailbox.
+			 u16datalength) & 0xF);
+	if (cf->can_dlc <= 4) {
+		ptr8data =
+		    &priv->can_rx_hndl.strcanmailbox.u8data3 + (4 -
+								cf->can_dlc);
+		for (count = 0; count < cf->can_dlc; count++) {
+			*data++ = *ptr8data++;
+		}
+	} else {
+		ptr8data = &priv->can_rx_hndl.strcanmailbox.u8data3;
+		for (count = 0; count < 4; count++) {
+			*data++ = *ptr8data++;
+		}
+		ptr8data =
+		    &priv->can_rx_hndl.strcanmailbox.u8data4 - (cf->can_dlc -
+								5);
+		for (count = 0; count < cf->can_dlc - 4; count++) {
+			*data++ = *ptr8data++;
+		}
+	}
+
+	pru_can_mbx_data = *((u32 *) &priv->can_rx_hndl.strcanmailbox);
+	/* get id extended or std */
+	if (pru_can_mbx_data & PRU_CANMID_IDE)
+		cf->can_id = (pru_can_mbx_data & CAN_EFF_MASK) | CAN_EFF_FLAG;
+	else
+		cf->can_id = (pru_can_mbx_data >> 18) & CAN_SFF_MASK;
+
+	if (pru_can_mbx_data & CAN_RTR_FLAG)
+		cf->can_id |= CAN_RTR_FLAG;
+
+	netif_rx_ni(skb);
+	stats->rx_packets++;
+	stats->rx_bytes += cf->can_dlc;
+	return 0;
+}
+
+static int omapl_pru_can_err(struct net_device *ndev, int int_status,
+			     int err_status)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	struct net_device_stats *stats = &ndev->stats;
+	struct can_frame *cf;
+	struct sk_buff *skb;
+	int tx_err_cnt, rx_err_cnt;
+
+	/* propogate the error condition to the can stack */
+	skb = alloc_can_err_skb(ndev, &cf);
+	if (!skb) {
+		if (printk_ratelimit())
+			dev_err(priv->dev,
+				"alloc_can_err_skb() failed\n");
+		return -ENOMEM;
+	}
+
+	if (err_status & PRU_CAN_GSR_BIT_EPM) {	/* error passive int */
+		priv->can.state = CAN_STATE_ERROR_PASSIVE;
+		++priv->can.can_stats.error_passive;
+		cf->can_id |= CAN_ERR_CRTL;
+		tx_err_cnt = pru_can_get_error_cnt(priv->dev, CAN_TX_PRU_1);
+		rx_err_cnt = pru_can_get_error_cnt(priv->dev, CAN_RX_PRU_0);
+		if (tx_err_cnt > 127)
+			cf->data[1] |= CAN_ERR_CRTL_TX_PASSIVE;
+		if (rx_err_cnt > 127)
+			cf->data[1] |= CAN_ERR_CRTL_RX_PASSIVE;
+
+		dev_dbg(priv->ndev->dev.parent, "Error passive interrupt\n");
+	}
+
+	if (err_status & PRU_CAN_GSR_BIT_BFM) {
+		priv->can.state = CAN_STATE_BUS_OFF;
+		cf->can_id |= CAN_ERR_BUSOFF;
+		/*
+		 *      Disable all interrupts in bus-off to avoid int hog
+		 *      this should be handled by the pru
+		 */
+		pru_can_mask_ints(priv->dev, 0xFFFF);
+		can_bus_off(ndev);
+		dev_dbg(priv->ndev->dev.parent, "Bus off mode\n");
+	}
+
+	netif_rx(skb);
+	stats->rx_packets++;
+	stats->rx_bytes += cf->can_dlc;
+	return 0;
+}
+
+void omapl_pru_can_rx_wQ(struct work_struct *work)
+{
+	struct omapl_pru_can_priv *priv = container_of(work,
+			struct omapl_pru_can_priv, rx_work);
+	struct net_device *ndev = priv->ndev;
+	u32 bit_set, mbxno = 0;
+
+	if (-1 == pru_can_get_intr_status(priv->dev, &priv->can_rx_hndl))
+		return;
+
+	if (PRU_CAN_ISR_BIT_RRI & priv->can_rx_hndl.u32interruptstatus) {
+		mbxno = RTR_MBX_NO;
+		omapl_pru_can_rx(ndev, mbxno);
+	} else {
+		/* Extract the mboxno from the status */
+		for (bit_set = 0; ((priv->can_rx_hndl.u32interruptstatus & 0xFF)
+						>> bit_set != 0); bit_set++)
+		;
+		if (0 == bit_set) {
+			dev_err(priv->dev,
+				"%s: invalid mailbox number: %X\n", __func__,
+				priv->can_rx_hndl.u32interruptstatus);
+		} else {
+			mbxno = bit_set - 1;
+			if (PRU_CAN_ISR_BIT_ESI & priv->can_rx_hndl.
+			    u32interruptstatus) {
+				pru_can_get_global_status(priv->dev,
+					&priv->can_rx_hndl);
+				omapl_pru_can_err(ndev,
+				priv->can_rx_hndl.u32interruptstatus,
+				priv->can_rx_hndl.u32globalstatus);
+			} else {
+				omapl_pru_can_rx(ndev, mbxno);
+			}
+		}
+	}
+}
+
+irqreturn_t omapl_tx_can_intr(int irq, void *dev_id)
+{
+	struct net_device *ndev = dev_id;
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	struct net_device_stats *stats = &ndev->stats;
+	u32 bit_set, mbxno;
+
+	pru_can_get_intr_status(priv->dev, &priv->can_tx_hndl);
+	if ((PRU_CAN_ISR_BIT_CCI & priv->can_tx_hndl.u32interruptstatus)
+	    || (PRU_CAN_ISR_BIT_SRDI & priv->can_tx_hndl.u32interruptstatus)) {
+		__can_debug("tx_int_status = 0x%X\n",
+			    priv->can_tx_hndl.u32interruptstatus);
+		can_free_echo_skb(ndev, 0);
+	} else {
+		for (bit_set = 0; ((priv->can_tx_hndl.u32interruptstatus & 0xFF)
+						>> bit_set != 0); bit_set++)
+		;
+		if (0 == bit_set) {
+			__can_err("%s: invalid mailbox number\n", __func__);
+			can_free_echo_skb(ndev, 0);
+		} else {
+			mbxno = bit_set - 1;	/* mail box numbering starts from 0 */
+			if (PRU_CAN_ISR_BIT_ESI & priv->can_tx_hndl.
+			    u32interruptstatus) {
+				/* read gsr and ack pru */
+				pru_can_get_global_status(priv->dev, &priv->can_tx_hndl);
+				omapl_pru_can_err(ndev,
+						  priv->can_tx_hndl.
+						  u32interruptstatus,
+						  priv->can_tx_hndl.
+						  u32globalstatus);
+			} else {
+				stats->tx_packets++;
+				/* stats->tx_bytes += dlc; */
+				/*can_get_echo_skb(ndev, 0);*/
+			}
+		}
+	}
+	if (netif_queue_stopped(ndev))
+		netif_wake_queue(ndev);
+
+	can_get_echo_skb(ndev, 0);
+	pru_can_tx_mode_set(priv->dev, true, ecanreceive);
+	return IRQ_HANDLED;
+}
+
+irqreturn_t omapl_rx_can_intr(int irq, void *dev_id)
+{
+
+	struct net_device *ndev = dev_id;
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	u32 intc_status = 0;
+
+	intc_status = pru_can_get_intc_status(priv->dev);
+	if (intc_status & 4)
+		return omapl_tx_can_intr(irq, dev_id);
+	if (intc_status & 2) {
+		if (!work_pending(&priv->rx_work))
+			queue_work(priv->pru_can_wQ, &priv->rx_work);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int omapl_pru_can_open(struct net_device *ndev)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+	int err;
+
+	/* register interrupt handler */
+	err = request_irq(priv->trx_irq, &omapl_rx_can_intr, IRQF_SHARED,
+			  "pru_can_irq", ndev);
+	if (err) {
+		dev_err(priv->dev, "error requesting rx interrupt\n");
+		goto exit_trx_irq;
+	}
+	/* common open */
+	err = open_candev(ndev);
+	if (err) {
+		dev_err(priv->dev, "open_candev() failed %d\n", err);
+		goto exit_open;
+	}
+
+	pru_can_emu_init(priv->dev, priv->can.clock.freq);
+	priv->tx_tail = MB_MIN;
+	priv->tx_head = MB_MAX;
+
+	pru_can_rx_id_map(priv->dev, CONFIG_DA8XX_PRU_CANID_MBX0, 0);
+	pru_can_rx_id_map(priv->dev, CONFIG_DA8XX_PRU_CANID_MBX1, 1);
+	pru_can_rx_id_map(priv->dev, CONFIG_DA8XX_PRU_CANID_MBX2, 2);
+	pru_can_rx_id_map(priv->dev, CONFIG_DA8XX_PRU_CANID_MBX3, 3);
+	pru_can_rx_id_map(priv->dev, CONFIG_DA8XX_PRU_CANID_MBX4, 4);
+	pru_can_rx_id_map(priv->dev, CONFIG_DA8XX_PRU_CANID_MBX5, 5);
+	pru_can_rx_id_map(priv->dev, CONFIG_DA8XX_PRU_CANID_MBX6, 6);
+	pru_can_rx_id_map(priv->dev, CONFIG_DA8XX_PRU_CANID_MBX7, 7);
+
+	omapl_pru_can_start(ndev);
+	netif_start_queue(ndev);
+	return 0;
+
+exit_open:
+	free_irq(priv->trx_irq, ndev);
+exit_trx_irq:
+	return err;
+}
+
+static int omapl_pru_can_close(struct net_device *ndev)
+{
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+
+	if (!netif_queue_stopped(ndev))
+		netif_stop_queue(ndev);
+
+	close_candev(ndev);
+
+	free_irq(priv->trx_irq, ndev);
+	return 0;
+}
+
+static const struct net_device_ops omapl_pru_can_netdev_ops = {
+	.ndo_open		= omapl_pru_can_open,
+	.ndo_stop		= omapl_pru_can_close,
+	.ndo_start_xmit		= omapl_pru_can_start_xmit,
+};
+
+static int __devinit omapl_pru_can_probe(struct platform_device *pdev)
+{
+	struct net_device *ndev = NULL;
+	const struct da8xx_pru_can_data *pdata;
+	struct omapl_pru_can_priv *priv = NULL;
+	struct device *dev = &pdev->dev;
+	u32 err;
+
+	pdata = dev->platform_data;
+	if (!pdata) {
+		dev_err(&pdev->dev, "platform data not found\n");
+		return -EINVAL;
+	}
+
+	ndev = alloc_candev(sizeof(struct omapl_pru_can_priv), MB_MAX + 1);
+	if (!ndev) {
+		dev_err(&pdev->dev, "alloc_candev failed\n");
+		err = -ENOMEM;
+		goto probe_exit;
+	}
+	priv = netdev_priv(ndev);
+
+	priv->trx_irq = platform_get_irq(to_platform_device(dev->parent), 0);
+	if (!priv->trx_irq) {
+		dev_err(&pdev->dev, "unable to get pru interrupt resources!\n");
+		err = -ENODEV;
+		goto probe_exit;
+	}
+
+	priv->ndev = ndev;
+	priv->dev = dev; /* priv->dev = pdev->dev */
+
+	priv->can.bittiming_const = NULL;
+	priv->can.do_set_bittiming = omapl_pru_can_set_bittiming;
+	priv->can.do_set_mode = omapl_pru_can_set_mode;
+	priv->can.do_get_state = omapl_pru_can_get_state;
+	priv->can_tx_hndl.u8prunumber = CAN_TX_PRU_1;
+	priv->can_rx_hndl.u8prunumber = CAN_RX_PRU_0;
+
+	/* we support local echo, no arp */
+	ndev->flags |= (IFF_ECHO | IFF_NOARP);
+
+	/* pdev->dev->device_private->driver_data = ndev */
+	platform_set_drvdata(pdev, ndev);
+	SET_NETDEV_DEV(ndev, &pdev->dev);
+	ndev->netdev_ops = &omapl_pru_can_netdev_ops;
+
+	priv->can.clock.freq = pruss_get_clk_freq(priv->dev);
+
+	priv->clk_timer = clk_get(&pdev->dev, "pll1_sysclk2");
+	if (IS_ERR(priv->clk_timer)) {
+		dev_err(&pdev->dev, "no timer clock available\n");
+		err = PTR_ERR(priv->clk_timer);
+		priv->clk_timer = NULL;
+		goto probe_exit_candev;
+	}
+	priv->timer_freq = clk_get_rate(priv->clk_timer);
+
+	err = register_candev(ndev);
+	if (err) {
+		dev_err(&pdev->dev, "register_candev() failed\n");
+		err = -ENODEV;
+		goto probe_exit_clk;
+	}
+
+	err = request_firmware(&priv->fw_tx, "PRU_CAN_Emulation_Tx.bin",
+			&pdev->dev);
+	if (err) {
+		dev_err(&pdev->dev, "can't load firmware\n");
+		err = -ENODEV;
+		goto probe_exit_clk;
+	}
+
+	dev_info(&pdev->dev, "fw_tx size %d. downloading...\n",
+		 priv->fw_tx->size);
+
+	err = request_firmware(&priv->fw_rx, "PRU_CAN_Emulation_Rx.bin",
+			&pdev->dev);
+	if (err) {
+		dev_err(&pdev->dev, "can't load firmware\n");
+		err = -ENODEV;
+		goto probe_release_fw;
+	}
+	dev_info(&pdev->dev, "fw_rx size %d. downloading...\n",
+		 priv->fw_rx->size);
+
+	/* init the pru */
+	pru_can_emu_init(priv->dev, priv->can.clock.freq);
+	udelay(200);
+
+	pruss_enable(priv->dev, CAN_RX_PRU_0);
+	pruss_enable(priv->dev, CAN_TX_PRU_1);
+
+	/* download firmware into pru */
+	err = pruss_load(priv->dev, CAN_RX_PRU_0,
+		(u32 *)priv->fw_rx->data, (priv->fw_rx->size / 4));
+	if (err) {
+		dev_err(&pdev->dev, "firmware download error\n");
+		err = -ENODEV;
+		goto probe_release_fw_1;
+	}
+	err = pruss_load(priv->dev, CAN_TX_PRU_1,
+		(u32 *)priv->fw_tx->data, (priv->fw_tx->size / 4));
+	if (err) {
+		dev_err(&pdev->dev, "firmware download error\n");
+		err = -ENODEV;
+		goto probe_release_fw_1;
+	}
+
+	if (pru_can_calc_timing(priv->dev, DFLT_PRU_FREQ,
+				DFLT_PRU_BITRATE) != 0)
+		return -EINVAL;
+
+	pruss_run(priv->dev, CAN_RX_PRU_0);
+	pruss_run(priv->dev, CAN_TX_PRU_1);
+
+	/*Create The Work Queue */
+	priv->pru_can_wQ = create_freezeable_workqueue("omapl_pru_wQ");
+	if (priv->pru_can_wQ == NULL) {
+		dev_err(&pdev->dev, "failed to create work queue\n");
+		err = -ENODEV;
+		goto probe_release_fw_1;
+	}
+
+	INIT_WORK(&priv->rx_work, omapl_pru_can_rx_wQ);
+	dev_info(&pdev->dev,
+		 "%s device registered (trx_irq = %d,  clk = %d)\n",
+		 DRV_NAME, priv->trx_irq, priv->can.clock.freq);
+
+	return 0;
+
+probe_release_fw_1:
+	release_firmware(priv->fw_rx);
+probe_release_fw:
+	release_firmware(priv->fw_tx);
+probe_exit_clk:
+	clk_put(priv->clk_timer);
+probe_exit_candev:
+	if (NULL != ndev)
+		free_candev(ndev);
+probe_exit:
+	return err;
+}
+
+static int __devexit omapl_pru_can_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+	struct omapl_pru_can_priv *priv = netdev_priv(ndev);
+
+	omapl_pru_can_stop(ndev);
+
+	pru_can_emu_exit(priv->dev);
+	release_firmware(priv->fw_tx);
+	release_firmware(priv->fw_rx);
+	clk_put(priv->clk_timer);
+	flush_workqueue(priv->pru_can_wQ);
+	destroy_workqueue(priv->pru_can_wQ);
+	unregister_candev(ndev);
+	free_candev(ndev);
+	platform_set_drvdata(pdev, NULL);
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int omapl_pru_can_suspend(struct platform_device *pdev,
+			pm_message_t mesg)
+{
+	dev_info(&pdev->dev, "%s not yet implemented\n", __func__);
+	return 0;
+}
+
+static int omapl_pru_can_resume(struct platform_device *pdev)
+{
+	dev_info(&pdev->dev, "%s not yet implemented\n", __func__);
+	return 0;
+}
+#else
+#define omapl_pru_can_suspend NULL
+#define omapl_pru_can_resume NULL
+#endif /* CONFIG_PM */
+
+static struct platform_driver omapl_pru_can_driver = {
+	.probe		= omapl_pru_can_probe,
+	.remove		= __devexit_p(omapl_pru_can_remove),
+	.suspend	= omapl_pru_can_suspend,
+	.resume		= omapl_pru_can_resume,
+	.driver		= {
+		.name	= DRV_NAME,
+		.owner	= THIS_MODULE,
+	},
+};
+
+static int __init omapl_pru_can_init(void)
+{
+	__can_debug(KERN_INFO DRV_DESC "\n");
+	return platform_driver_register(&omapl_pru_can_driver);
+}
+
+module_init(omapl_pru_can_init);
+
+static void __exit omapl_pru_can_exit(void)
+{
+	__can_debug(KERN_INFO DRV_DESC " unloaded\n");
+	platform_driver_unregister(&omapl_pru_can_driver);
+}
+
+module_exit(omapl_pru_can_exit);
+
+MODULE_AUTHOR("Subhasish Ghosh <subhasish at mistralsolutions.com>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("omapl pru CAN netdevice driver");
diff --git a/drivers/net/can/da8xx_pruss/pruss_can_api.c b/drivers/net/can/da8xx_pruss/pruss_can_api.c
new file mode 100644
index 0000000..2f7438a
--- /dev/null
+++ b/drivers/net/can/da8xx_pruss/pruss_can_api.c
@@ -0,0 +1,1227 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Wilfred Felix
+ *
+ * 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 "pruss_can_api.h"
+
+static can_emu_drv_inst gstr_can_inst[ecanmaxinst];
+
+/*
+ * pru_can_set_brp()	Updates the  BRP register of PRU0
+ * and PRU1 of OMAP L138. This API will be called by the
+ * Application to updtae the BRP register of PRU0 and PRU1
+ *
+ * param	u16bitrateprescaler		The can bus bitrate
+ * prescaler value be set
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_set_brp(struct device *dev, u16 u16bitrateprescaler)
+{
+
+	u32 u32offset;
+
+	if (u16bitrateprescaler > 255) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_CLOCK_BRP_REGISTER);
+	pruss_writel(dev, u32offset, (u32 *) &u16bitrateprescaler, 1);
+
+	u32offset = (PRU_CAN_TX_CLOCK_BRP_REGISTER);
+	pruss_writel(dev, u32offset, (u32 *) &u16bitrateprescaler, 1);
+
+	return 0;
+
+}
+
+/*
+ * pru_can_set_bit_timing()		Updates the timing register
+ * of PRU0 and PRU1 of OMAP L138. This API will be called by
+ * the Application to updtae the timing register of PRU0 and PRU1
+ *
+ * param	pstrbittiming		Pointer to structure holding
+ * the bit timing values for can bus.
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_set_bit_timing(struct device *dev,
+		can_bit_timing_consts *pstrbittiming)
+{
+
+	u32 u32offset;
+	u32 u32serregister;
+
+	u32serregister = 0;
+
+	if (pstrbittiming == NULL) {
+		return -1;
+	}
+
+	if ((pstrbittiming->u8syncjumpwidth > PRU_CAN_MAX_SJW) ||
+	    (pstrbittiming->u8phseg1 > PRU_CAN_MAX_PHSEG1) ||
+	    (pstrbittiming->u8phseg2 > PRU_CAN_MAX_PHSEG2)) {
+		return -1;
+	}
+
+	u32serregister = u32serregister |
+			((pstrbittiming->u8syncjumpwidth << 7) |
+			(pstrbittiming->u8phseg1 << 3) |
+			(pstrbittiming->u8phseg2));
+
+	u32offset = (PRU_CAN_TX_TIMING_REGISTER);
+	pruss_writel(dev, u32offset, (u32 *) &u32serregister, 1);
+
+	u32offset = (PRU_CAN_RX_TIMING_REGISTER);
+	pruss_writel(dev, u32offset, (u32 *) &u32serregister, 1);
+
+	return 0;
+}
+
+
+/*
+ * pru_can_calc_timing()
+ * Updates the  timing values of PRU0 and PRU1 of OMAP L138.
+ * This API will be called by the
+ * Application to updtae the timing values of PRU0 and PRU1
+ *
+ * return   SUCCESS or FAILURE
+ */
+
+s16 pru_can_calc_timing(struct device *dev, u32 pru_freq, u32 bit_rate)
+{
+	u16 u16phaseseg1;
+	u16 u16phaseseg2;
+	u32 u32offset;
+	u32 u32timing_value;
+	u32 u32setup_value;
+	u32timing_value = TIMER_CLK_FREQ / bit_rate;
+	u32offset = (PRU_CAN_TIMING_VAL_TX);
+	pruss_writel(dev, u32offset, (u32 *) &u32timing_value, 4);
+	pruss_readl(dev, u32offset, (u32 *) &u32timing_value, 4);
+	u32setup_value =
+	    (GPIO_SETUP_DELAY * (pru_freq / 1000000) / 1000) /
+	    DELAY_LOOP_LENGTH;
+	u32offset = (PRU_CAN_TIMING_VAL_TX_SJW);
+	pruss_writel(dev, u32offset, (u32 *) &u32setup_value, 4);
+	u16phaseseg1 = (u16) (u32timing_value / 2);
+	u16phaseseg2 = u32timing_value - u16phaseseg1;
+	u16phaseseg1 -= TIMER_SETUP_DELAY;
+	u16phaseseg2 -= TIMER_SETUP_DELAY;
+	u32setup_value = (u16phaseseg1 << 16) | u16phaseseg2;
+	u32offset = (PRU_CAN_TIMING_VAL_RX);
+	pruss_writel(dev, u32offset, (u32 *) &u32setup_value, 4);
+	u32offset = (PRU_CAN_TIMING_VAL_RX + 4);
+	pruss_writel(dev, u32offset, (u32 *) &u32timing_value, 4);
+
+	return 0;
+}
+
+/*
+ * pru_can_write_data_to_mailbox()
+ * Updates the transmit mailboxes of PRU1 of OMAP L138.
+ * This API will be called by the Application to update
+ * the transmit mailboxes of PRU1
+ *
+ * param  pu16canframedata	Can mailbox data buffer
+ *
+ * param  u8mailboxnum		Mailbox to be updated
+ *
+ * return SUCCESS or FAILURE
+ */
+s16 pru_can_write_data_to_mailbox(struct device *dev,
+			can_emu_app_hndl *pstremuapphndl)
+{
+	s16 s16subrtnretval;
+	u32 u32offset;
+
+	if (pstremuapphndl == NULL) {
+		return -1;
+	}
+
+	switch ((u8) pstremuapphndl->ecanmailboxnumber) {
+	case 0:
+		u32offset = (PRU_CAN_TX_MAILBOX0);
+		break;
+	case 1:
+		u32offset = (PRU_CAN_TX_MAILBOX1);
+		break;
+	case 2:
+		u32offset = (PRU_CAN_TX_MAILBOX2);
+		break;
+	case 3:
+		u32offset = (PRU_CAN_TX_MAILBOX3);
+		break;
+	case 4:
+		u32offset = (PRU_CAN_TX_MAILBOX4);
+		break;
+	case 5:
+		u32offset = (PRU_CAN_TX_MAILBOX5);
+		break;
+	case 6:
+		u32offset = (PRU_CAN_TX_MAILBOX6);
+		break;
+	case 7:
+		u32offset = (PRU_CAN_TX_MAILBOX7);
+		break;
+	default:
+		return -1;
+	}
+
+	s16subrtnretval = pruss_writel(dev, u32offset,
+		(u32 *) &(pstremuapphndl->strcanmailbox), 4);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	return 0;
+}
+
+/*
+ * pru_can_get_data_from_mailbox()
+ * Receive data from the receive mailboxes of PRU0  of OMAP L138.
+ * This API will be called by the Application to get data from
+ * the receive mailboxes of PRU0
+ *
+ * param  pu16canframedata	Can mailbox data buffer
+ *
+ * param  u8mailboxnum		Mailbox to be updated
+ *
+ * return SUCCESS or FAILURE
+ */
+s16 pru_can_get_data_from_mailbox(struct device *dev,
+		can_emu_app_hndl *pstremuapphndl)
+{
+	s16 s16subrtnretval;
+	u32 u32offset;
+
+	if (pstremuapphndl == NULL) {
+		return -1;
+	}
+
+	switch ((u8) pstremuapphndl->ecanmailboxnumber) {
+	case 0:
+		u32offset = (PRU_CAN_RX_MAILBOX0);
+		break;
+	case 1:
+		u32offset = (PRU_CAN_RX_MAILBOX1);
+		break;
+	case 2:
+		u32offset = (PRU_CAN_RX_MAILBOX2);
+		break;
+	case 3:
+		u32offset = (PRU_CAN_RX_MAILBOX3);
+		break;
+	case 4:
+		u32offset = (PRU_CAN_RX_MAILBOX4);
+		break;
+	case 5:
+		u32offset = (PRU_CAN_RX_MAILBOX5);
+		break;
+	case 6:
+		u32offset = (PRU_CAN_RX_MAILBOX6);
+		break;
+	case 7:
+		u32offset = (PRU_CAN_RX_MAILBOX7);
+		break;
+	case 8:
+		u32offset = (PRU_CAN_RX_MAILBOX8);
+		break;
+	default:
+		return -1;
+	}
+
+	s16subrtnretval =
+	    pruss_readl(dev, u32offset,
+		  (u32 *) &(pstremuapphndl->strcanmailbox),
+				  4);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	return 0;
+}
+
+/*
+ * pru_can_receive_id_map()
+ * Receive mailboxes ID Mapping of PRU0  of OMAP L138.
+ * This API will be called by the Application
+ * to map the IDs  to receive mailboxes of PRU0
+ *
+ * param  u32nodeid		Can node ID
+ *
+ * param  ecanmailboxno		Mailbox to be mapped
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_rx_id_map(struct device *dev, u32 u32nodeid,
+		can_mailbox_number ecanmailboxno)
+{
+
+	pruss_writel(dev, (PRU_CAN_ID_MAP +
+		(((u8) ecanmailboxno) * 4)), (u32 *) &u32nodeid, 1);
+
+	return 0;
+}
+
+/*
+ * pru_can_get_intr_status()
+ * Gets the interrupts status register value.
+ * This API will be called by the Application
+ * to get the interrupts status register value
+ *
+ * param  u8prunumber	PRU number for which IntStatusReg
+ * has to be read
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_get_intr_status(struct device *dev,
+		can_emu_app_hndl *pstremuapphndl)
+{
+	u32 u32offset;
+	s16 s16subrtnretval = -1;
+
+	if (pstremuapphndl == NULL) {
+		return -1;
+	}
+
+	if (pstremuapphndl->u8prunumber == DA8XX_PRUCORE_1) {
+		u32offset = (PRU_CAN_TX_INTERRUPT_STATUS_REGISTER);
+	} else if (pstremuapphndl->u8prunumber == DA8XX_PRUCORE_0) {
+		u32offset = (PRU_CAN_RX_INTERRUPT_STATUS_REGISTER);
+	} else {
+		return -1;
+	}
+
+	s16subrtnretval = pruss_readl(dev, u32offset,
+		(u32 *) &pstremuapphndl->u32interruptstatus, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	return 0;
+}
+
+/*
+ * pru_can_get_global_status()	Gets the globalstatus
+ * register value. This API will be called by the Application
+ * to  get the global status register value
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_get_global_status(struct device *dev,
+		can_emu_app_hndl *pstremuapphndl)
+{
+	u32 u32offset;
+	int s16subrtnretval = -1;
+
+	if (pstremuapphndl == NULL) {
+		return -1;
+	}
+
+	if (pstremuapphndl->u8prunumber == DA8XX_PRUCORE_1) {
+		u32offset = (PRU_CAN_TX_GLOBAL_STATUS_REGISTER);
+	} else if (pstremuapphndl->u8prunumber == DA8XX_PRUCORE_0) {
+		u32offset = (PRU_CAN_RX_GLOBAL_STATUS_REGISTER);
+	} else {
+		return -1;
+	}
+
+	s16subrtnretval = pruss_readl(dev, u32offset,
+		(u32 *) &pstremuapphndl->u32globalstatus, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	return 0;
+}
+
+/*
+ * pru_can_get_mailbox_status()		Gets the mailbox status
+ * register value. This API will be called by the Application
+ * to get the mailbox status register value
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_get_mailbox_status(struct device *dev,
+		can_emu_app_hndl *pstremuapphndl)
+{
+	u32 u32offset;
+	s16 s16subrtnretval = -1;
+
+	if (pstremuapphndl == NULL) {
+		return -1;
+	}
+
+	if (pstremuapphndl->u8prunumber == DA8XX_PRUCORE_1) {
+		switch (pstremuapphndl->ecanmailboxnumber) {
+		case 0:
+			u32offset = (PRU_CAN_TX_MAILBOX0_STATUS_REGISTER);
+			break;
+		case 1:
+			u32offset = (PRU_CAN_TX_MAILBOX1_STATUS_REGISTER);
+			break;
+		case 2:
+			u32offset = (PRU_CAN_TX_MAILBOX2_STATUS_REGISTER);
+			break;
+		case 3:
+			u32offset = (PRU_CAN_TX_MAILBOX3_STATUS_REGISTER);
+			break;
+		case 4:
+			u32offset = (PRU_CAN_TX_MAILBOX4_STATUS_REGISTER);
+			break;
+		case 5:
+			u32offset = (PRU_CAN_TX_MAILBOX5_STATUS_REGISTER);
+			break;
+		case 6:
+			u32offset = (PRU_CAN_TX_MAILBOX6_STATUS_REGISTER);
+			break;
+		case 7:
+			u32offset = (PRU_CAN_TX_MAILBOX7_STATUS_REGISTER);
+			break;
+		default:
+			return -1;
+		}
+	}
+
+	else if (pstremuapphndl->u8prunumber == DA8XX_PRUCORE_0) {
+		switch (pstremuapphndl->ecanmailboxnumber) {
+		case 0:
+			u32offset = (PRU_CAN_RX_MAILBOX0_STATUS_REGISTER);
+			break;
+		case 1:
+			u32offset = (PRU_CAN_RX_MAILBOX1_STATUS_REGISTER);
+			break;
+		case 2:
+			u32offset = (PRU_CAN_RX_MAILBOX2_STATUS_REGISTER);
+			break;
+		case 3:
+			u32offset = (PRU_CAN_RX_MAILBOX3_STATUS_REGISTER);
+			break;
+		case 4:
+			u32offset = (PRU_CAN_RX_MAILBOX4_STATUS_REGISTER);
+			break;
+		case 5:
+			u32offset = (PRU_CAN_RX_MAILBOX5_STATUS_REGISTER);
+			break;
+		case 6:
+			u32offset = (PRU_CAN_RX_MAILBOX6_STATUS_REGISTER);
+			break;
+		case 7:
+			u32offset = (PRU_CAN_RX_MAILBOX7_STATUS_REGISTER);
+			break;
+		case 8:
+			u32offset = (PRU_CAN_RX_MAILBOX8_STATUS_REGISTER);
+			break;
+		default:
+			return -1;
+		}
+	}
+
+	else {
+		return -1;
+	}
+
+	s16subrtnretval = pruss_readl(dev, u32offset,
+		(u32 *) &pstremuapphndl->u32mailboxstatus, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	return 0;
+}
+
+s16 pru_can_tx_mode_set(struct device *dev, bool btransfer_flag,
+				can_transfer_direction ecan_trx)
+{
+	u32 u32offset;
+	u32 u32value;
+
+	if (ecan_trx == ecantransmit) {
+		u32offset = (PRU_CAN_RX_GLOBAL_STATUS_REGISTER);
+		pruss_readl(dev, u32offset, &u32value, 1);
+		if (btransfer_flag == true) {
+			u32value &= 0x1F;
+			u32value |= 0x80;
+		} else {
+			u32value &= 0x7F;
+		}
+		pruss_writel(dev, u32offset, &u32value, 1);
+		u32offset = (PRU_CAN_TX_GLOBAL_STATUS_REGISTER);
+		pruss_writel(dev, u32offset, &u32value, 1);
+	} else if (ecan_trx == ecanreceive) {
+		u32offset = (PRU_CAN_RX_GLOBAL_STATUS_REGISTER);
+		pruss_readl(dev, u32offset, &u32value, 1);
+		if (btransfer_flag == true) {
+			u32value &= 0x1F;
+			u32value |= 0x40;
+		} else {
+			u32value &= 0xBF;
+		}
+		pruss_writel(dev, u32offset, &u32value, 1);
+		u32offset = (PRU_CAN_TX_GLOBAL_STATUS_REGISTER);
+		pruss_writel(dev, u32offset, &u32value, 1);
+	} else
+		return -1;
+
+	return 0;
+}
+
+/*
+ * pru_can_config_mode_set()		Sets the timing value
+ * for data transfer. This API will be called by the Application
+ * to set timing valus for data transfer
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_config_mode_set(struct device *dev, bool bconfigmodeflag)
+{
+
+	u32 u32bitrateprescaler;
+	u32 u32canbittiming;
+
+	pruss_readl(dev, (PRU_CAN_TX_CLOCK_BRP_REGISTER),
+			(u32 *) &u32bitrateprescaler, 1);
+	pruss_readl(dev, (PRU_CAN_TX_TIMING_REGISTER),
+			(u32 *) &u32canbittiming, 1);
+
+	if (bconfigmodeflag == 1) {
+		pru_can_calc_timing(dev, u32canbittiming, u32bitrateprescaler);
+	}
+
+	else {
+		pru_can_calc_timing(dev, 0, 0);
+	}
+
+	return 0;
+}
+
+/*
+ * pru_can_emu_init()		Initializes the Can
+ * Emulation Parameters. This API will be called by the Application
+ * to Initialize the Can Emulation Parameters
+ *
+ * param    u32pruclock         PRU Clock value
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_emu_init(struct device *dev, u32 u32pruclock)
+{
+	u32 u32offset;
+	u32 u32value;
+	s16 s16subrtnretval = -1;
+	u8 u8loop;
+
+	for (u8loop = 0; u8loop < (u8) ecanmaxinst; u8loop++) {
+		gstr_can_inst[u8loop].bcaninststate = (bool) 0;
+		gstr_can_inst[u8loop].ecantransferdirection =
+		    (can_transfer_direction) 0;
+		gstr_can_inst[u8loop].u32apphandlerptr = 0;
+	}
+
+	u32offset = (PRU_CAN_TX_GLOBAL_CONTROL_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_GLOBAL_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000040;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	u32offset = (PRU_CAN_RX_GLOBAL_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000040;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_INTERRUPT_MASK_REGISTER & 0xFFFF);
+	u32value = 0x00004000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_INTERRUPT_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_MAILBOX0_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000001;
+	s16subrtnretval =
+	    pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_MAILBOX1_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000001;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_MAILBOX2_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000001;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_MAILBOX3_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000001;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_MAILBOX4_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000001;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_MAILBOX5_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000001;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_MAILBOX6_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000001;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_MAILBOX7_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000001;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_ERROR_COUNTER_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_TIMING_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_CLOCK_BRP_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_TX_ERROR_COUNTER_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_POLARITY0 & 0xFFFF);
+	u32value = 0xFFFFFFFF;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	u32offset = (PRUSS_INTC_POLARITY1 & 0xFFFF);
+	u32value = 0xFFFFFFFF;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	u32offset = (PRUSS_INTC_TYPE0 & 0xFFFF);
+	u32value = 0x1C000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	u32offset = (PRUSS_INTC_TYPE1 & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_HSTINTENIDXCLR & 0xFFFF);
+	u32value = 0x0;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_GLBLEN & 0xFFFF);
+	u32value = 0x1;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	/* tx intr map arm->pru */
+	u32offset = (PRUSS_INTC_HSTINTENIDXSET & 0xFFFF);
+	u32value = 0x0;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_HOSTMAP0 & 0xFFFF);
+	u32value = 0x03020100;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_HOSTMAP1 & 0xFFFF);
+	u32value = 0x07060504;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_HOSTMAP2 & 0xFFFF);
+	u32value = 0x0000908;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_CHANMAP0 & 0xFFFF);
+	u32value = 0;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_CHANMAP8 & 0xFFFF);
+	u32value = 0x00020200;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_STATIDXCLR & 0xFFFF);
+	u32value = 32;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_STATIDXCLR & 0xFFFF);
+	u32value = 19;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 19;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	u32offset = (PRUSS_INTC_STATIDXCLR & 0xFFFF);
+	u32value = 18;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 18;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_STATIDXCLR & 0xFFFF);
+	u32value = 34;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 34;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 32;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRUSS_INTC_HOSTINTEN & 0xFFFF);
+	u32value = 0x5;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+/* PRU0 - Rx Internal Registers Initializations */
+
+	u32offset = (PRU_CAN_RX_GLOBAL_CONTROL_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_GLOBAL_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000040;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_INTERRUPT_MASK_REGISTER & 0xFFFF);
+	u32value = 0x00004000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_INTERRUPT_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_MAILBOX0_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_MAILBOX1_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x0000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_MAILBOX2_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_MAILBOX3_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_MAILBOX4_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_MAILBOX5_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_MAILBOX6_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_MAILBOX7_STATUS_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_ERROR_COUNTER_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_TIMING_REGISTER & 0xFFFF);
+	u32value = 0x0000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+
+	u32offset = (PRU_CAN_RX_CLOCK_BRP_REGISTER & 0xFFFF);
+	u32value = 0x00000000;
+	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	return 0;
+}
+
+
+/*
+ * pru_can_emu_open()		Opens the can emu for
+ * application to use. This API will be called by the Application
+ * to Open the can emu for application to use.
+ *
+ * param	pstremuapphndl	Pointer to application handler
+ * structure
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_emu_open(struct device *dev, can_emu_app_hndl *pstremuapphndl)
+{
+
+	if (pstremuapphndl == NULL) {
+		return -1;
+	}
+
+	if (gstr_can_inst[pstremuapphndl->ecaninstance].bcaninststate == 1) {
+		return -1;
+	}
+
+	gstr_can_inst[(u8) pstremuapphndl->ecaninstance].
+					bcaninststate = (bool)1;
+	gstr_can_inst[(u8) pstremuapphndl->
+		ecaninstance].ecantransferdirection =
+		(can_transfer_direction)(u8)pstremuapphndl->ecantransferdirection;
+	gstr_can_inst[(u8) pstremuapphndl->ecaninstance].
+		u32apphandlerptr = (u32) pstremuapphndl;
+
+	return 0;
+}
+
+
+/*
+ * brief    pru_can_emu_close()	Closes the can emu for other
+ * applications to use. This API will be called by the Application to Close
+ * the can emu for other applications to use
+ *
+ * param	pstremuapphndl	Pointer to application handler structure
+ *
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_emu_close(struct device *dev, can_emu_app_hndl *pstremuapphndl)
+{
+
+	if (pstremuapphndl == NULL) {
+		return -1;
+	}
+	if (gstr_can_inst[pstremuapphndl->ecaninstance].bcaninststate == 0) {
+		return -1;
+	}
+	if ((u32) pstremuapphndl != gstr_can_inst[(u8) pstremuapphndl->
+			ecaninstance].u32apphandlerptr){
+		return -1;
+	}
+	gstr_can_inst[(u8) pstremuapphndl->ecaninstance].bcaninststate
+		= (bool) 0;
+	gstr_can_inst[(u8) pstremuapphndl->
+	ecaninstance].ecantransferdirection = (can_transfer_direction) 0;
+	gstr_can_inst[(u8) pstremuapphndl->ecaninstance].u32apphandlerptr = 0;
+
+	return 0;
+}
+
+/*
+ * brief    pru_can_emu_exit()	Diables all the PRUs
+ * This API will be called by the Application to disable all PRUs
+ * param	None
+ * return   SUCCESS or FAILURE
+ */
+s16 pru_can_emu_exit(struct device *dev)
+{
+	s16 s16subrtnretval;
+
+	s16subrtnretval = pruss_disable(dev, CAN_RX_PRU_0);
+	if (s16subrtnretval == -1)
+		return -1;
+	s16subrtnretval = pruss_disable(dev, CAN_TX_PRU_1);
+	if (s16subrtnretval == -1)
+		return -1;
+
+	return 0;
+}
+
+s16 pru_can_emu_sreset(struct device *dev)
+{
+	return 0;
+}
+
+s16 pru_can_tx(struct device *dev, u8 u8mailboxnumber, u8 u8prunumber)
+{
+	u32 u32offset = 0;
+	u32 u32value = 0;
+	s16 s16subrtnretval = -1;
+
+	if (DA8XX_PRUCORE_1 == u8prunumber) {
+		switch (u8mailboxnumber) {
+		case 0:
+			u32offset = (PRU_CAN_TX_MAILBOX0_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000080;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+					(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 1:
+			u32offset = (PRU_CAN_TX_MAILBOX1_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000080;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 2:
+			u32offset = (PRU_CAN_TX_MAILBOX2_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000080;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 3:
+			u32offset = (PRU_CAN_TX_MAILBOX3_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000080;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 4:
+			u32offset = (PRU_CAN_TX_MAILBOX4_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000080;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 5:
+			u32offset = (PRU_CAN_TX_MAILBOX5_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000080;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 6:
+			u32offset = (PRU_CAN_TX_MAILBOX6_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000080;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 7:
+			u32offset = (PRU_CAN_TX_MAILBOX7_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000080;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		default:
+			return -1;
+		}
+	} else {
+
+		u32offset = (PRU_CAN_RX_INTERRUPT_STATUS_REGISTER & 0xFFFF);
+		u32value = 0x00000000;
+		s16subrtnretval = pruss_readl(dev, u32offset,
+						(u32 *) &u32value, 1);
+		if (s16subrtnretval == -1) {
+			return -1;
+		}
+		u32value = u32value & ~(1 << u8mailboxnumber);
+		s16subrtnretval = pruss_writel(dev, u32offset,
+					(u32 *) &u32value, 1);
+		if (s16subrtnretval == -1) {
+			return -1;
+		}
+
+		switch (u8mailboxnumber) {
+		case 0:
+			u32offset = (PRU_CAN_RX_MAILBOX0_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000000;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 1:
+			u32offset = (PRU_CAN_RX_MAILBOX1_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000000;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 2:
+			u32offset = (PRU_CAN_RX_MAILBOX2_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000000;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 3:
+			u32offset = (PRU_CAN_RX_MAILBOX3_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000000;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 4:
+			u32offset = (PRU_CAN_RX_MAILBOX4_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000000;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 5:
+			u32offset = (PRU_CAN_RX_MAILBOX5_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000000;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 6:
+			u32offset = (PRU_CAN_RX_MAILBOX6_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000000;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		case 7:
+			u32offset = (PRU_CAN_RX_MAILBOX7_STATUS_REGISTER & 0xFFFF);
+			u32value = 0x00000000;
+			s16subrtnretval = pruss_writel(dev, u32offset,
+						(u32 *) &u32value, 1);
+			if (s16subrtnretval == -1) {
+				return -1;
+			}
+			break;
+		default:
+			return -1;
+		}
+	}
+	return 0;
+}
+
+s16 pru_can_start_abort_tx(struct device *dev, bool bcantransmitabortflag)
+{
+	u32 u32offset;
+	u32 u32value;
+	s16 s16subrtnretval;
+	u32offset = (PRUSS_INTC_STATIDXCLR & 0xFFFF);
+	u32value = 32;
+	s16subrtnretval = pruss_writel(dev, u32offset,
+					(u32 *) &u32value, 1);
+
+	u32offset = (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 32;
+	s16subrtnretval = pruss_writel(dev, u32offset,
+					(u32 *) &u32value, 1);
+
+	u32offset = (PRUSS_INTC_STATIDXSET & 0xFFFF);
+	u32value = 32;
+	s16subrtnretval = pruss_writel(dev, u32offset,
+					(u32 *) &u32value, 1);
+	if (s16subrtnretval == -1) {
+		return -1;
+	}
+	return 0;
+}
+
+s16 pru_can_mask_ints(struct device *dev, u32 int_mask)
+{
+	return 0;
+}
+
+int pru_can_get_error_cnt(struct device *dev, u8 u8prunumber)
+{
+	return 0;
+}
+
+int pru_can_get_intc_status(struct device *dev)
+{
+	u32 u32offset = 0;
+	u32 u32getvalue = 0;
+	u32 u32clrvalue = 0;
+
+	u32offset = (PRUSS_INTC_STATCLRINT1 & 0xFFFF);
+	pruss_readl(dev, u32offset, (u32 *) &u32getvalue, 1);
+
+	if (u32getvalue & 4)
+		u32clrvalue = 34;	/* CLR Event 34 */
+
+	if (u32getvalue & 2)
+		u32clrvalue = 33;	/* CLR Event 33  */
+
+	if (u32clrvalue) {
+		u32offset = (PRUSS_INTC_STATIDXCLR & 0xFFFF);
+		pruss_writel(dev, u32offset, &u32clrvalue, 1);
+	} else
+		return -1;
+
+	return u32getvalue;
+}
diff --git a/drivers/net/can/da8xx_pruss/pruss_can_api.h b/drivers/net/can/da8xx_pruss/pruss_can_api.h
new file mode 100644
index 0000000..7550456
--- /dev/null
+++ b/drivers/net/can/da8xx_pruss/pruss_can_api.h
@@ -0,0 +1,290 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Ganeshan N
+ *
+ * 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 _PRU_CAN_API_H_
+#define _PRU_CAN_API_H_
+
+#include <linux/types.h>
+#include <linux/mfd/pruss/da8xx_pru.h>
+
+
+#define CAN_BIT_TIMINGS			(0x273)
+
+/* Timer Clock is sourced from DDR freq (PLL1 SYS CLK 2) */
+#define	TIMER_CLK_FREQ			132000000
+
+#define TIMER_SETUP_DELAY		14
+#define GPIO_SETUP_DELAY		150
+
+#define CAN_RX_PRU_0			PRUSS_NUM0
+#define CAN_TX_PRU_1			PRUSS_NUM1
+
+/* Number of Instruction in the Delay loop */
+#define DELAY_LOOP_LENGTH		2
+
+#define PRU1_BASE_ADDR			0x2000
+
+#define PRU_CAN_TX_GLOBAL_CONTROL_REGISTER		(PRU1_BASE_ADDR)
+#define PRU_CAN_TX_GLOBAL_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x04)
+#define PRU_CAN_TX_INTERRUPT_MASK_REGISTER		(PRU1_BASE_ADDR	+ 0x08)
+#define PRU_CAN_TX_INTERRUPT_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x0C)
+#define PRU_CAN_TX_MAILBOX0_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x10)
+#define PRU_CAN_TX_MAILBOX1_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x14)
+#define PRU_CAN_TX_MAILBOX2_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x18)
+#define PRU_CAN_TX_MAILBOX3_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x1C)
+#define PRU_CAN_TX_MAILBOX4_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x20)
+#define PRU_CAN_TX_MAILBOX5_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x24)
+#define PRU_CAN_TX_MAILBOX6_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x28)
+#define PRU_CAN_TX_MAILBOX7_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x2C)
+#define PRU_CAN_TX_ERROR_COUNTER_REGISTER		(PRU1_BASE_ADDR	+ 0x30)
+#define PRU_CAN_TX_TIMING_REGISTER			(PRU1_BASE_ADDR	+ 0x34)
+#define PRU_CAN_TX_CLOCK_BRP_REGISTER			(PRU1_BASE_ADDR	+ 0x38)
+
+#define PRU_CAN_TX_MAILBOX0				(PRU1_BASE_ADDR	+ 0x40)
+#define PRU_CAN_TX_MAILBOX1				(PRU1_BASE_ADDR	+ 0x50)
+#define PRU_CAN_TX_MAILBOX2				(PRU1_BASE_ADDR	+ 0x60)
+#define PRU_CAN_TX_MAILBOX3				(PRU1_BASE_ADDR	+ 0x70)
+#define PRU_CAN_TX_MAILBOX4				(PRU1_BASE_ADDR	+ 0x80)
+#define PRU_CAN_TX_MAILBOX5				(PRU1_BASE_ADDR	+ 0x90)
+#define PRU_CAN_TX_MAILBOX6				(PRU1_BASE_ADDR	+ 0xA0)
+#define PRU_CAN_TX_MAILBOX7				(PRU1_BASE_ADDR	+ 0xB0)
+
+#define PRU_CAN_TIMING_VAL_TX				(PRU1_BASE_ADDR	+ 0xC0)
+#define PRU_CAN_TIMING_VAL_TX_SJW			(PRU1_BASE_ADDR	+ 0xC4)
+#define PRU_CAN_TRANSMIT_FRAME				(PRU1_BASE_ADDR	+ 0xE0)
+
+#define PRU0_BASE_ADDR					0
+
+#define PRU_CAN_RX_GLOBAL_CONTROL_REGISTER		(PRU0_BASE_ADDR)
+#define PRU_CAN_RX_GLOBAL_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x04)
+#define PRU_CAN_RX_INTERRUPT_MASK_REGISTER		(PRU0_BASE_ADDR	+ 0x08)
+#define PRU_CAN_RX_INTERRUPT_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x0C)
+#define PRU_CAN_RX_MAILBOX0_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x10)
+#define PRU_CAN_RX_MAILBOX1_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x14)
+#define PRU_CAN_RX_MAILBOX2_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x18)
+#define PRU_CAN_RX_MAILBOX3_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x1C)
+#define PRU_CAN_RX_MAILBOX4_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x20)
+#define PRU_CAN_RX_MAILBOX5_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x24)
+#define PRU_CAN_RX_MAILBOX6_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x28)
+#define PRU_CAN_RX_MAILBOX7_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x2C)
+#define PRU_CAN_RX_MAILBOX8_STATUS_REGISTER		(PRU0_BASE_ADDR	+ 0x30)
+#define PRU_CAN_RX_ERROR_COUNTER_REGISTER		(PRU0_BASE_ADDR	+ 0x34)
+#define PRU_CAN_RX_TIMING_REGISTER			(PRU0_BASE_ADDR	+ 0x38)
+#define PRU_CAN_RX_CLOCK_BRP_REGISTER			(PRU0_BASE_ADDR	+ 0x3C)
+
+#define PRU_CAN_RX_MAILBOX0				(PRU0_BASE_ADDR	+ 0x40)
+#define PRU_CAN_RX_MAILBOX1				(PRU0_BASE_ADDR	+ 0x50)
+#define PRU_CAN_RX_MAILBOX2				(PRU0_BASE_ADDR	+ 0x60)
+#define PRU_CAN_RX_MAILBOX3				(PRU0_BASE_ADDR	+ 0x70)
+#define PRU_CAN_RX_MAILBOX4				(PRU0_BASE_ADDR	+ 0x80)
+#define PRU_CAN_RX_MAILBOX5				(PRU0_BASE_ADDR	+ 0x90)
+#define PRU_CAN_RX_MAILBOX6				(PRU0_BASE_ADDR	+ 0xA0)
+#define PRU_CAN_RX_MAILBOX7				(PRU0_BASE_ADDR	+ 0xB0)
+#define PRU_CAN_RX_MAILBOX8				(PRU0_BASE_ADDR	+ 0xC0)
+
+#define PRU_CAN_TIMING_VAL_RX				(PRU0_BASE_ADDR	+ 0xD0)
+#define PRU_CAN_RECEIVE_FRAME				(PRU0_BASE_ADDR	+ 0xD4)
+#define PRU_CAN_ID_MAP					(PRU0_BASE_ADDR	+ 0xF0)
+
+#define PRU_CAN_ERROR_ACTIVE				128
+
+#define CAN_ACK_FAILED					0xE
+#define CAN_ARBTR_FAIL					0xD
+#define CAN_BIT_ERROR					0xC
+#define CAN_TRANSMISSION_SUCCESS			0xA
+
+#define STD_DATA_FRAME					0x1
+#define EXTD_DATA_FRAME					0x2
+#define STD_REMOTE_FRAME				0x3
+#define EXTD_REMOTE_FRAME				0x4
+
+#define PRU_CAN_MAX_SJW					8
+#define PRU_CAN_MAX_PHSEG1				25
+#define PRU_CAN_MAX_PHSEG2				25
+
+#define DA8XX_PRUCANCORE_0_REGS				0x7000
+#define DA8XX_PRUCANCORE_1_REGS				0x7800
+#define PRU0_PROG_RAM_START_OFFSET			0x8000
+#define PRU1_PROG_RAM_START_OFFSET			0xC000
+#define PRU_CAN_INIT_MAX_TIMEOUT			0xFF
+
+typedef enum {
+	ecaninst0 = 0,
+	ecaninst1,
+	ecanmaxinst
+} can_instance_enum;
+
+typedef enum {
+	ecanmailbox0 = 0,
+	ecanmailbox1,
+	ecanmailbox2,
+	ecanmailbox3,
+	ecanmailbox4,
+	ecanmailbox5,
+	ecanmailbox6,
+	ecanmailbox7
+} can_mailbox_number;
+
+typedef enum {
+	ecandirectioninit = 0,
+	ecantransmit,
+	ecanreceive
+} can_transfer_direction;
+
+typedef struct {
+	u16 u16extendedidentifier;
+	u16 u16baseidentifier;
+	u8 u8data7;
+	u8 u8data6;
+	u8 u8data5;
+	u8 u8data4;
+	u8 u8data3;
+	u8 u8data2;
+	u8 u8data1;
+	u8 u8data0;
+	u16 u16datalength;
+	u16 u16crc;
+} can_mail_box_structure;
+
+typedef struct {
+	can_transfer_direction ecantransferdirection;
+} can_mailbox_config;
+
+typedef struct {
+	can_instance_enum ecaninstance;
+	can_transfer_direction ecantransferdirection;
+	can_mail_box_structure strcanmailbox;
+	can_mailbox_number ecanmailboxnumber;
+	u8 u8prunumber;
+	u32 u32globalstatus;
+	u32 u32interruptstatus;
+	u32 u32mailboxstatus;
+} can_emu_app_hndl;
+
+typedef struct {
+	bool bcaninststate;
+	can_transfer_direction ecantransferdirection;
+	u32 u32apphandlerptr;
+} can_emu_drv_inst;
+
+typedef struct {
+	u8 u8syncjumpwidth;
+	u8 u8phseg1;
+	u8 u8phseg2;
+} can_bit_timing_consts;
+
+/* Field Definition Macros  */
+
+/* CONTROL */
+
+/*
+ * pru_can_set_brp() Updates the  BRP register of PRU.
+ */
+s16 pru_can_set_brp(struct device *dev, u16 u16prescaler);
+
+/*
+ * pru_can_set_bit_timing() Updates the  timing register of PRU
+ */
+s16 pru_can_set_bit_timing(struct device *dev,
+			can_bit_timing_consts *pstrbittiming);
+
+/*
+ * pru_can_calc_timing() Updates the timing values of PRU
+ */
+s16 pru_can_calc_timing(struct device *dev,
+			u32 u32bittiming, u32 u32bitrateprescaler);
+
+/*
+ * pru_can_write_data_to_mailbox() Updates the transmit mailboxes of PRU1
+ */
+s16 pru_can_write_data_to_mailbox(struct device *dev,
+			can_emu_app_hndl *pstremuapphndl);
+
+/*
+ * pru_can_get_data_from_mailbox() Receive data from receive mailboxes
+ */
+s16 pru_can_get_data_from_mailbox(struct device *dev,
+			can_emu_app_hndl *pstremuapphndl);
+
+/*
+ * pru_can_rx_id_map() Receive mailboxes ID Mapping of PRU0
+ */
+s16 pru_can_rx_id_map(struct device *dev,
+			u32 u32nodeid, can_mailbox_number ecanmailboxno);
+
+/*
+ *pru_can_get_intr_status() Get interrupts status register value
+ */
+s16 pru_can_get_intr_status(struct device *dev,
+			can_emu_app_hndl *pstremuapphndl);
+
+
+/*
+ * pru_can_get_global_status() Get the globalstatus register value
+ */
+s16 pru_can_get_global_status(struct device *dev,
+			can_emu_app_hndl *pstremuapphndl);
+
+/*
+ * pru_can_get_mailbox_status() Get mailbox status reg value
+ */
+s16 pru_can_get_mailbox_status(struct device *dev,
+			can_emu_app_hndl *pstremuapphndl);
+
+/*
+ * pru_can_configuration_mode_set() Sets timing val for data transfer
+ */
+s16 pru_can_config_mode_set(struct device *dev,
+			bool bconfig_modeflag);
+
+/*
+ * pru_can_emu_init() Initializes Can Emulation Parameters
+ */
+s16 pru_can_emu_init(struct device *dev,
+			u32 u32pruclock);
+
+/*
+ * pru_can_emu_open() Opens can emu for application to use
+ */
+s16 pru_can_emu_open(struct device *dev,
+			can_emu_app_hndl *pstremuapphndl);
+
+/*
+ * pru_can_emu_close() Closes can emu for applications to use
+ */
+s16 pru_can_emu_close(struct device *dev,
+			can_emu_app_hndl *pstremuapphndl);
+
+/*
+ * pru_can_emu_exit() Diables all the PRUs
+ */
+s16 pru_can_emu_exit(struct device *dev);
+
+s16 pru_can_tx_mode_set(struct device *dev, bool btransfer_flag,
+			 can_transfer_direction ecan_trx);
+
+s16 pru_can_emu_sreset(struct device *dev);
+
+s16 pru_can_tx(struct device *dev,
+			u8 u8mailboxnumber, u8 u8prunumber);
+
+s16 pru_can_start_abort_tx(struct device *dev,
+			bool btxabort_flag);
+
+s16 pru_can_mask_ints(struct device *dev, u32 int_mask);
+
+s32 pru_can_get_error_cnt(struct device *dev, u8 u8prunumber);
+
+s32 pru_can_get_intc_status(struct device *dev);
+#endif
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:29 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:29 +0530
Subject: [PATCH v2 10/13] mfd: pruss SUART private data.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-11-git-send-email-subhasish@mistralsolutions.com>

This patch adds the PRUSS SUART data.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 include/linux/mfd/pruss/da8xx_pru.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/linux/mfd/pruss/da8xx_pru.h b/include/linux/mfd/pruss/da8xx_pru.h
index 50f2ede..4230d10 100644
--- a/include/linux/mfd/pruss/da8xx_pru.h
+++ b/include/linux/mfd/pruss/da8xx_pru.h
@@ -93,6 +93,11 @@ struct da8xx_pruss_can_data {
 	u32 version;
 };
 
+struct da850_evm_pruss_suart_data {
+	u32 version;
+	struct resource resource;
+};
+
 u32 pruss_get_clk_freq(struct device *dev);
 
 u32 pruss_enable(struct device *dev, u8 pruss_num);
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:30 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:30 +0530
Subject: [PATCH v2 11/13] da850: pruss SUART board specific additions.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-12-git-send-email-subhasish@mistralsolutions.com>

This patch adds the pruss SUART pin mux and registers the device
with the pruss mfd driver.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   36 +++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index f9c38f8..3858516 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1060,6 +1060,25 @@ const short da850_evm_pruss_can_pins[] = {
 	-1
 };
 
+const short da850_evm_pruss_suart_pins[] = {
+	DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
+	DA850_AHCLKR, DA850_ACLKR, DA850_AFSR,
+	DA850_AXR_13, DA850_AXR_9, DA850_AXR_7,
+	DA850_AXR_14, DA850_AXR_10, DA850_AXR_8,
+	-1
+};
+
+static int __init da850_evm_setup_pruss_suart(void)
+{
+	int ret;
+
+	ret = davinci_cfg_reg_list(da850_evm_pruss_suart_pins);
+	if (ret)
+		pr_warning("%s: da850_evm_pruss_suart_pins "
+			"mux setup failed: %d\n", __func__, ret);
+	return ret;
+}
+
 static int __init da850_evm_setup_pruss_can(void)
 {
 	int ret, val = 0;
@@ -1085,6 +1104,17 @@ static int __init da850_evm_setup_pruss_can(void)
 	return ret;
 }
 
+static struct da850_evm_pruss_suart_data suart_data = {
+	.version	= 1,
+	.resource	= {
+			.name	= "da8xx_mcasp0_iomem",
+			.start	= DAVINCI_DA8XX_MCASP0_REG_BASE,
+			.end	= DAVINCI_DA8XX_MCASP0_REG_BASE +
+					(SZ_1K * 12) - 1,
+			.flags	= IORESOURCE_MEM,
+		},
+};
+
 static struct da8xx_pruss_can_data can_data = {
 	.version	= 1,
 };
@@ -1094,6 +1124,12 @@ static struct da8xx_pruss_devices pruss_devices[] = {
 		.dev_name	= "da8xx_pruss_can",
 		.pdata		= &can_data,
 		.pdata_size	= sizeof(can_data),
+		.setup		= da850_evm_setup_pruss_suart,
+	},
+	{
+		.dev_name	= "da8xx_pruss_uart",
+		.pdata		= &suart_data,
+		.pdata_size	= sizeof(suart_data),
 		.setup		= da850_evm_setup_pruss_can,
 	},
 	{
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:31 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:31 +0530
Subject: [PATCH v2 12/13] da850: pruss SUART platform specific additions.
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-13-git-send-email-subhasish@mistralsolutions.com>

This patch adds the McASP clock alias.
The alias is used by the pruss suart driver
for enabling the McASP PSC.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 arch/arm/mach-davinci/devices-da8xx.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index e15de72..f1cf605 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -560,7 +560,18 @@ struct platform_device da8xx_pruss_dev = {
 
 int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
 {
+#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
+	int ret;
+#endif
+
 	da8xx_pruss_dev.dev.platform_data = pruss_device;
+
+#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
+	ret = clk_add_alias(NULL, "da8xx_pruss_uart.1",
+	NULL, &da850_mcasp_device.dev);
+	if (ret < 0)
+		return ret;
+#endif
 	return platform_device_register(&da8xx_pruss_dev);
 }
 
-- 
1.7.2.3


From subhasish at mistralsolutions.com  Fri Feb 11 08:51:32 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 11 Feb 2011 20:21:32 +0530
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <1297435892-28278-14-git-send-email-subhasish@mistralsolutions.com>

This patch adds support for the TTY compliant
Soft-UART device emulated on PRUSS.

Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
---
 drivers/tty/serial/Kconfig                         |    2 +
 drivers/tty/serial/Makefile                        |    1 +
 drivers/tty/serial/da8xx_pruss/Kconfig             |   19 +
 drivers/tty/serial/da8xx_pruss/Makefile            |    9 +
 drivers/tty/serial/da8xx_pruss/pruss_suart.c       | 1014 +++++++++
 drivers/tty/serial/da8xx_pruss/pruss_suart_api.c   | 2350 ++++++++++++++++++++
 drivers/tty/serial/da8xx_pruss/pruss_suart_api.h   |  345 +++
 drivers/tty/serial/da8xx_pruss/pruss_suart_board.h |   58 +
 drivers/tty/serial/da8xx_pruss/pruss_suart_err.h   |   48 +
 drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h |  526 +++++
 drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h  |  153 ++
 drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c |  384 ++++
 drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h |   63 +
 include/linux/serial_core.h                        |    2 +
 14 files changed, 4974 insertions(+), 0 deletions(-)
 create mode 100644 drivers/tty/serial/da8xx_pruss/Kconfig
 create mode 100644 drivers/tty/serial/da8xx_pruss/Makefile
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart.c
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_api.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_board.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_err.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c
 create mode 100644 drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index b1682d7..68c40c2 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1595,4 +1595,6 @@ config SERIAL_PCH_UART
 	  This driver is for PCH(Platform controller Hub) UART of Intel EG20T
 	  which is an IOH(Input/Output Hub) for x86 embedded processor.
 	  Enabling PCH_DMA, this PCH UART works as DMA mode.
+
+source "drivers/tty/serial/da8xx_pruss/Kconfig"
 endmenu
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 8ea92e9..51c89e9 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_SERIAL_MRST_MAX3110)	+= mrst_max3110.o
 obj-$(CONFIG_SERIAL_MFD_HSU)	+= mfd.o
 obj-$(CONFIG_SERIAL_IFX6X60)  	+= ifx6x60.o
 obj-$(CONFIG_SERIAL_PCH_UART)	+= pch_uart.o
+obj-$(CONFIG_SERIAL_PRUSS_SUART)	+= da8xx_pruss/
diff --git a/drivers/tty/serial/da8xx_pruss/Kconfig b/drivers/tty/serial/da8xx_pruss/Kconfig
new file mode 100644
index 0000000..23ac53f
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/Kconfig
@@ -0,0 +1,19 @@
+#
+# SUART Kernel Configuration
+#
+
+config SERIAL_PRUSS_SUART
+	depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
+	select SERIAL_CORE
+	tristate "PRUSS based SoftUART emulation on DA8XX"
+	---help---
+	Enable this to emulate a UART controller on the PRUSS of DA8XX.
+	If not sure, mark N
+
+config PRUSS_SUART_MCASP
+    int "McASP number"
+    depends on ARCH_DAVINCI && ARCH_DAVINCI_DA830 && SERIAL_PRUSS_SUART
+    default "0"
+    ---help---
+    Enter the McASP number to use with SUART (0, 1 or 2).
+	You will need to recompile the kernel if this is changed.
diff --git a/drivers/tty/serial/da8xx_pruss/Makefile b/drivers/tty/serial/da8xx_pruss/Makefile
new file mode 100644
index 0000000..34a5b1f
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for SoftUART emulation
+#
+
+suart_emu-objs :=       pruss_suart.o \
+                        pruss_suart_api.o \
+                        pruss_suart_utils.o
+
+obj-$(CONFIG_SERIAL_PRUSS_SUART)        += suart_emu.o
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart.c b/drivers/tty/serial/da8xx_pruss/pruss_suart.c
new file mode 100644
index 0000000..d222e2e
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart.c
@@ -0,0 +1,1014 @@
+/*
+ * PRUSS SUART Emulation device driver
+ * Author: subhasish at mistralsolutions.com
+ *
+ * This driver supports TI's PRU SUART Emulation and the
+ * specs for the same is available at <http://www.ti.com>
+ *
+ * Copyright (C) 2009 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 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/errno.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/module.h>
+#include <mach/da8xx.h>
+#include <linux/platform_device.h>
+#include <linux/firmware.h>
+#include <linux/clk.h>
+#include <linux/serial_reg.h>
+#include <linux/delay.h>
+#include <mach/sram.h>
+#include "pruss_suart_board.h"
+#include "pruss_suart_api.h"
+#include "pruss_suart_utils.h"
+#include "pruss_suart_err.h"
+
+#define NR_SUART			8
+#define DRV_NAME			"da8xx_pruss_uart"
+#define DRV_DESC			"PRUSS SUART Driver v1.0"
+#define MAX_SUART_RETRIES		100
+#define SUART_CNTX_SZ			512
+#define SUART_FIFO_TIMEOUT_DFLT		5
+#define SUART_FIFO_TIMEOUT_MIN		4
+#define SUART_FIFO_TIMEOUT_MAX		500
+
+#ifdef __SUART_DEBUG
+#define __suart_debug(fmt, args...) \
+		printk(KERN_DEBUG "suart_debug: " fmt, ## args)
+#else
+#define __suart_debug(fmt, args...)
+#endif
+
+#define  __suart_err(fmt, args...) printk(KERN_ERR "suart_err: " fmt, ## args)
+
+/* Default timeout set to 5ms */
+static s16 suart_timeout = SUART_FIFO_TIMEOUT_DFLT;
+module_param(suart_timeout, short, S_IRUGO);
+MODULE_PARM_DESC(suart_timeout,
+		 "fifo timeout in milli seconds (min: 4; max: 500)");
+
+struct suart_fifo {
+	void *fifo_vaddr_buff_tx;
+	void *fifo_vaddr_buff_rx;
+	void *fifo_phys_addr_tx;
+	void *fifo_phys_addr_rx;
+};
+
+struct omapl_pru_suart {
+	struct uart_port port[NR_SUART];
+	struct device *dev; /* pdev->dev */
+	struct semaphore port_sem[NR_SUART];
+	struct clk *clk_mcasp;
+	struct suart_fifo suart_fifo_addr[NR_SUART];
+	const struct firmware *fw;
+	suart_struct_handle suart_hdl[NR_SUART];
+	pruss_suart_iomap suart_iomap;
+	u32 clk_freq_pru;
+	u32 clk_freq_mcasp;
+	u32 tx_loadsz;
+};
+
+static u32 suart_get_duplex(struct omapl_pru_suart *soft_uart, u32 uart_no)
+{
+	return soft_uart->suart_hdl[uart_no].uart_type;
+}
+
+static inline void __stop_tx(struct omapl_pru_suart *soft_uart, u32 uart_no)
+{
+	struct device *dev = soft_uart->dev;
+	u16 txready;
+	u32 i;
+
+	/* Check if any TX in progress */
+	for (i = 0, txready = 1; (i < 10000) && txready; i++) {
+		txready = (pru_softuart_get_tx_status
+			(dev, &soft_uart->suart_hdl[uart_no]) &
+				CHN_TXRX_STATUS_RDY);
+	}
+	/* To stop tx, disable the TX interrupt */
+	suart_intr_clrmask(dev, soft_uart->suart_hdl[uart_no].uart_num,
+				PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
+	pru_softuart_clr_tx_status(dev, &soft_uart->suart_hdl[uart_no]);
+}
+
+static void pruss_suart_stop_tx(struct uart_port *port)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	__stop_tx(soft_uart, port->line);
+}
+
+static void omapl_pru_tx_chars(struct omapl_pru_suart *soft_uart, u32 uart_no)
+{
+	struct circ_buf *xmit = &soft_uart->port[uart_no].state->xmit;
+	struct device *dev = soft_uart->dev;
+	s32 count = 0;
+
+	if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
+		return;
+
+	if (down_trylock(&soft_uart->port_sem[uart_no]))
+		return;
+
+	if (uart_circ_empty(xmit) ||
+			uart_tx_stopped(&soft_uart->port[uart_no])) {
+		pruss_suart_stop_tx(&soft_uart->port[uart_no]);
+		up(&soft_uart->port_sem[uart_no]);
+		return;
+	}
+
+	for (count = 0; count <= soft_uart->tx_loadsz; count++) {
+		*((s8 *)soft_uart->suart_fifo_addr[uart_no].fifo_vaddr_buff_tx
+		+ count) = xmit->buf[xmit->tail];
+		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+		soft_uart->port[uart_no].icount.tx++;
+		if (uart_circ_empty(xmit)) {
+			uart_circ_clear(xmit);
+			break;
+		}
+	}
+
+	if (count == (SUART_FIFO_LEN + 1))
+		count = SUART_FIFO_LEN;
+
+	/* Write the character to the data port */
+	if (SUART_SUCCESS != pru_softuart_write(dev,
+		&soft_uart->suart_hdl[uart_no],
+			(u32 *)&soft_uart->suart_fifo_addr
+				[uart_no].fifo_phys_addr_tx, count)) {
+		__suart_err("failed to tx data\n");
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(&soft_uart->port[uart_no]);
+
+#if 0
+	if (uart_circ_empty(xmit))
+		__stop_tx(soft_uart, uart_no);
+#endif
+}
+
+static void omapl_pru_rx_chars(struct omapl_pru_suart *soft_uart, u32 uart_no)
+{
+	struct tty_struct *tty = soft_uart->port[uart_no].state->port.tty;
+	struct device *dev = soft_uart->dev;
+	s8 flags = TTY_NORMAL;
+	u16 rx_status, data_len = SUART_FIFO_LEN;
+	u32 data_len_read;
+	u8 suart_data[SUART_FIFO_LEN + 1];
+	s32 i = 0;
+
+	if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_RX))
+		return;
+	/* read the status */
+	rx_status = pru_softuart_get_rx_status(dev,
+			&soft_uart->suart_hdl[uart_no]);
+
+	/* check for errors */
+	if (rx_status & CHN_TXRX_STATUS_ERR) {
+		if (rx_status & CHN_TXRX_STATUS_FE)
+			soft_uart->port[uart_no].icount.frame++;
+		if (rx_status & CHN_TXRX_STATUS_OVRNERR)
+			soft_uart->port[uart_no].icount.overrun++;
+		if (rx_status & CHN_TXRX_STATUS_BI)
+			soft_uart->port[uart_no].icount.brk++;
+		rx_status &= soft_uart->port[uart_no].read_status_mask;
+		if (rx_status & CHN_TXRX_STATUS_FE)
+			flags = TTY_FRAME;
+		if (rx_status & CHN_TXRX_STATUS_OVRNERR)
+			flags = TTY_OVERRUN;
+		if (rx_status & CHN_TXRX_STATUS_BI)
+			flags = TTY_BREAK;
+
+#ifdef SUPPORT_SYSRQ
+		soft_uart->port[uart_no].sysrq = 0;
+#endif
+	} else {
+		pru_softuart_read_data(dev, &soft_uart->suart_hdl[uart_no],
+				       suart_data, data_len + 1,
+				       &data_len_read);
+
+		for (i = 0; i <= data_len_read; i++) {
+			soft_uart->port[uart_no].icount.rx++;
+			/* check for sys rq */
+			if (uart_handle_sysrq_char
+			    (&soft_uart->port[uart_no], suart_data))
+				continue;
+		}
+		/* update the tty data structure */
+		tty_insert_flip_string(tty, suart_data, data_len_read);
+	}
+
+	/* push data into tty */
+	pru_softuart_clr_rx_status(dev, &soft_uart->suart_hdl[uart_no]);
+	spin_unlock(&soft_uart->port[uart_no].lock);
+	tty_flip_buffer_push(tty);
+	spin_lock(&soft_uart->port[uart_no].lock);
+}
+
+static irqreturn_t pruss_suart_interrupt(s32 irq, void *dev_id)
+{
+	struct uart_port *port = dev_id;
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct device *dev = soft_uart->dev;
+	u16 txrx_flag;
+	u32 ret;
+	unsigned long flags = 0;
+	u16 uart_num = port->line + 1;
+
+	spin_lock_irqsave(&soft_uart->port[port->line].lock, flags);
+	do {
+		ret = pru_softuart_get_isrstatus(dev, uart_num, &txrx_flag);
+		if (PRU_SUART_SUCCESS != ret) {
+			__suart_err("suart%d: failed to get interrupt, ret:"
+				" 0x%X txrx_flag 0x%X\n",
+				port->line, ret, txrx_flag);
+			spin_unlock_irqrestore(&soft_uart->
+				port[port->line].lock, flags);
+			return IRQ_NONE;
+		}
+		if ((PRU_RX_INTR & txrx_flag) == PRU_RX_INTR) {
+			pru_intr_clr_isrstatus(dev, uart_num, PRU_RX_INTR);
+			if ((soft_uart->port[port->line].ignore_status_mask &
+				CHN_TXRX_STATUS_RDY) == CHN_TXRX_STATUS_RDY) {
+				pru_softuart_clr_rx_status(dev,
+					&soft_uart->suart_hdl
+				[port->line]);
+			} else {
+				omapl_pru_rx_chars(soft_uart, port->line);
+			}
+		}
+
+		if ((PRU_TX_INTR & txrx_flag) == PRU_TX_INTR) {
+			pru_intr_clr_isrstatus(dev, uart_num, PRU_TX_INTR);
+			pru_softuart_clr_tx_status(dev, &soft_uart->suart_hdl
+						 [port->line]);
+			up(&soft_uart->port_sem[port->line]);
+			omapl_pru_tx_chars(soft_uart, port->line);
+		}
+	} while (txrx_flag & (PRU_RX_INTR | PRU_TX_INTR));
+
+	spin_unlock_irqrestore(&soft_uart->port[port->line].lock, flags);
+	return IRQ_HANDLED;
+}
+
+static void pruss_suart_stop_rx(struct uart_port *port)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct device *dev = soft_uart->dev;
+	/* disable rx interrupt */
+	suart_intr_clrmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_RX_INTR, CHN_TXRX_IE_MASK_BI
+			   | CHN_TXRX_IE_MASK_FE | CHN_TXRX_IE_MASK_CMPLT
+			   | CHN_TXRX_IE_MASK_TIMEOUT);
+}
+
+static void pruss_suart_enable_ms(struct uart_port *port)
+{
+	__suart_err("modem control timer not supported\n");
+}
+
+static void pruss_suart_start_tx(struct uart_port *port)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct device *dev = soft_uart->dev;
+	/* unmask the tx interrupts */
+
+	suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
+	omapl_pru_tx_chars(soft_uart, port->line);
+}
+
+static u32 pruss_suart_tx_empty(struct uart_port *port)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct device *dev = soft_uart->dev;
+
+	return (pru_softuart_get_tx_status(dev,
+		&soft_uart->suart_hdl[port->line])
+		& CHN_TXRX_STATUS_RDY) ? 0 : TIOCSER_TEMT;
+}
+
+static u32 pruss_suart_get_mctrl(struct uart_port *port)
+{
+	return -ENOTSUPP;
+}
+
+static void pruss_suart_set_mctrl(struct uart_port *port, u32 mctrl)
+{
+	__suart_debug("modem control not supported\n");
+}
+
+static void pruss_suart_break_ctl(struct uart_port *port, s32 break_state)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct device *dev = soft_uart->dev;
+	unsigned long flags = 0;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	if (break_state == -1)
+		suart_intr_clrmask(dev,
+			soft_uart->suart_hdl[port->line].uart_num,
+			PRU_RX_INTR, CHN_TXRX_IE_MASK_BI);
+	else
+		suart_intr_setmask(dev,
+			soft_uart->suart_hdl[port->line].uart_num,
+			PRU_RX_INTR, CHN_TXRX_IE_MASK_BI);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void pruss_suart_set_termios(struct uart_port *port,
+				  struct ktermios *termios,
+				  struct ktermios *old)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct device *dev = soft_uart->dev;
+	u8 cval = 0;
+	unsigned long flags = 0;
+	u32 baud = 0;
+	u32 old_csize = old ? old->c_cflag & CSIZE : CS8;
+
+/*
+ * Do not allow unsupported configurations to be set
+ */
+	if (1) {
+		termios->c_cflag &= ~(HUPCL | CRTSCTS | CMSPAR | CSTOPB
+				      | PARENB | PARODD | CMSPAR);
+		termios->c_cflag |= CLOCAL;
+	}
+
+	switch (termios->c_cflag & CSIZE) {
+	case CS6:
+		cval = ePRU_SUART_DATA_BITS6;
+		break;
+	case CS7:
+		cval = ePRU_SUART_DATA_BITS7;
+		break;
+	default:
+	case CS8:
+		cval = ePRU_SUART_DATA_BITS8;
+		break;
+	}
+	/*
+	 * We do not support CS5.
+	 */
+	if ((termios->c_cflag & CSIZE) == CS5) {
+		termios->c_cflag &= ~CSIZE;
+		termios->c_cflag |= old_csize;
+	}
+	if (SUART_SUCCESS != pru_softuart_setdatabits
+		(dev, &soft_uart->suart_hdl[port->line], cval, cval))
+		__suart_err("failed to set data bits to: %d\n", cval);
+
+/*
+ * Ask the core to calculate the divisor for us.
+ */
+	baud = uart_get_baud_rate(port, termios, old,
+			  port->uartclk / 16 / 0xffff,
+			  port->uartclk / 16);
+
+/*
+ * Ok, we're now changing the port state.  Do it with
+ * interrupts disabled.
+ */
+	spin_lock_irqsave(&port->lock, flags);
+
+	/* Set the baud */
+	if (SUART_SUCCESS !=
+	    pru_softuart_setbaud(dev, &soft_uart->suart_hdl[port->line],
+				 SUART_DEFAULT_BAUD / baud,
+				 SUART_DEFAULT_BAUD / baud))
+		__suart_err("failed to set baud to: %d\n", baud);
+
+/*
+ * update port->read_config_mask and port->ignore_config_mask
+ * to indicate the events we are interested in receiving
+ */
+	suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_RX_INTR, SUART_GBL_INTR_ERR_MASK);
+	port->read_status_mask = 0;
+	if (termios->c_iflag & INPCK) {	/* Input parity check not supported,
+					just enabled FE */
+		port->read_status_mask |= CHN_TXRX_STATUS_FE;
+		suart_intr_setmask(dev,
+			soft_uart->suart_hdl[port->line].uart_num,
+			PRU_RX_INTR, CHN_TXRX_IE_MASK_FE);
+	}
+	if (termios->c_iflag & (BRKINT | PARMRK)) {
+		port->read_status_mask |= CHN_TXRX_STATUS_BI;
+		suart_intr_setmask(dev,
+			soft_uart->suart_hdl[port->line].uart_num,
+			PRU_RX_INTR, CHN_TXRX_IE_MASK_BI);
+	}
+/*
+ * Characteres to ignore
+ */
+	port->ignore_status_mask = 0;
+	if (termios->c_iflag & IGNBRK) {
+		port->ignore_status_mask |= CHN_TXRX_STATUS_BI;
+		/*
+		 * If we're ignoring break indicators,
+		 * ignore overruns too (for real raw support).
+		 */
+		if (termios->c_iflag & IGNPAR) {
+			port->ignore_status_mask |=
+			    (CHN_TXRX_STATUS_OVRNERR | CHN_TXRX_STATUS_FE);
+			/*
+			 * Overrun in case of RX
+			 * Underrun in case of TX
+			 */
+			suart_intr_clrmask(dev, soft_uart->
+					   suart_hdl[port->line].uart_num,
+					   PRU_RX_INTR, CHN_TXRX_IE_MASK_FE);
+		}
+		suart_intr_clrmask(dev,
+			soft_uart->suart_hdl[port->line].uart_num,
+			PRU_RX_INTR, CHN_TXRX_IE_MASK_BI);
+	}
+/*
+ * ignore all characters if CREAD is not set
+ */
+	if ((termios->c_cflag & CREAD) == 0) {
+		port->ignore_status_mask |= CHN_TXRX_STATUS_RDY;
+		pruss_suart_stop_rx(port);
+	}
+
+	spin_unlock_irqrestore(&port->lock, flags);
+	/* Don't rewrite B0 */
+	if (tty_termios_baud_rate(termios))
+		tty_termios_encode_baud_rate(termios, baud, baud);
+}
+
+/*
+ *	Grab any interrupt resources and initialise any low level driver
+ *	state.  Enable the port for reception.  It should not activate
+ *	RTS nor DTR; this will be done via a separate call to set_mctrl.
+ *
+ *	This method will only be called when the port is initially opened.
+ *
+ *	Locking: port_sem taken.
+ *	Interrupts: globally disabled.
+ */
+static s32 pruss_suart_startup(struct uart_port *port)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct device *dev = soft_uart->dev;
+	s32 retval;
+
+	/*
+	 * Disable interrupts from this port
+	 */
+	suart_intr_clrmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
+	suart_intr_clrmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_RX_INTR, CHN_TXRX_IE_MASK_BI
+			   | CHN_TXRX_IE_MASK_FE | CHN_TXRX_IE_MASK_CMPLT
+			   | CHN_TXRX_IE_MASK_TIMEOUT);
+
+	retval = request_irq(port->irq, pruss_suart_interrupt,
+			     port->irqflags, "suart_irq", port);
+	if (retval) {
+		free_irq(port->irq, port); /* should we free this if err */
+		goto out;
+	}
+	/*
+	 * enable interrupts from this port
+	 */
+	suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_RX_INTR, SUART_GBL_INTR_ERR_MASK);
+
+	suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_RX_INTR, CHN_TXRX_IE_MASK_BI
+			   | CHN_TXRX_IE_MASK_FE | CHN_TXRX_IE_MASK_CMPLT
+			   | CHN_TXRX_IE_MASK_TIMEOUT);
+
+	suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
+
+	if ((suart_get_duplex(soft_uart, port->line) & ePRU_SUART_HALF_TX)
+	    == ePRU_SUART_HALF_TX) {
+		suart_pru_to_host_intr_enable(dev, soft_uart->
+			suart_hdl[port->line].uart_num, PRU_TX_INTR, true);
+	}
+	/* Seed RX if port is half-rx or full-duplex */
+	if ((suart_get_duplex(soft_uart, port->line) & ePRU_SUART_HALF_RX)
+		== ePRU_SUART_HALF_RX) {
+		suart_pru_to_host_intr_enable(dev, soft_uart->
+			suart_hdl[port->line].uart_num, PRU_RX_INTR, true);
+		pru_softuart_read(dev, &soft_uart->suart_hdl[port->line],
+			(u32 *)&soft_uart->suart_fifo_addr[port->line].
+			fifo_phys_addr_rx, SUART_FIFO_LEN);
+	}
+out:
+	return retval;
+}
+
+/*
+ * Disable the port, disable any break condition that may be in
+ * effect, and free any interrupt resources.  It should not disable
+ * RTS nor DTR; this will have already been done via a separate
+ * call to set_mctrl.
+ *
+ * Drivers must not access port->info once this call has completed.
+ *
+ * This method will only be called when there are no more users of
+ * this port.
+ *
+ * Locking: port_sem taken.
+ * Interrupts: caller dependent.
+ */
+
+static void pruss_suart_shutdown(struct uart_port *port)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct device *dev = soft_uart->dev;
+
+	/*
+	 * Disable interrupts from this port
+	 */
+	/* Disable BI and FE intr */
+	suart_intr_clrmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
+	suart_intr_clrmask(dev, soft_uart->suart_hdl[port->line].uart_num,
+			   PRU_RX_INTR, CHN_TXRX_IE_MASK_BI
+			   | CHN_TXRX_IE_MASK_FE | CHN_TXRX_IE_MASK_CMPLT
+			   | CHN_TXRX_IE_MASK_TIMEOUT);
+
+	/* free interrupts */
+	free_irq(port->irq, port);
+}
+
+/*
+ * Return a pointer to a string constant describing the specified
+ * port, or return NULL, in which case the string 'unknown' is
+ * substituted.
+ *
+ * Locking: none.
+ * Interrupts: caller dependent.
+ */
+
+static const char *pruss_suart_type(struct uart_port *port)
+{
+	return "suart_tty";
+}
+
+/*
+ * Release any memory and IO region resources currently in use by
+ * the port.
+ *
+ * Locking: none.
+ * Interrupts: caller dependent.
+ */
+
+static void pruss_suart_release_port(struct uart_port *port)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct platform_device *pdev = to_platform_device(port->dev);
+
+	if (0 != pru_softuart_close(&soft_uart->suart_hdl[port->line]))
+		dev_err(&pdev->dev, "failed to close suart\n");
+
+	return;
+}
+
+/*
+ * Request any memory and IO region resources required by the port.
+ * If any fail, no resources should be registered when this function
+ * returns, and it should return -EBUSY on failure.
+ *
+ * Locking: none.
+ * Interrupts: caller dependent.
+ *
+ * We need to d/l the f/w in probe and since this api
+ * is called per uart, the request_mem_region should
+ * be called in probe itself.
+ */
+static s32 pruss_suart_request_port(struct uart_port *port)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	struct platform_device *pdev = to_platform_device(port->dev);
+	struct device *dev = soft_uart->dev;
+	suart_config pru_suart_config;
+	s16 timeout = 0;
+	u32 err = 0;
+
+	if (soft_uart == NULL) {
+		__suart_err("soft_uart ptr failed\n");
+		return -ENODEV;
+	}
+	err = pru_softuart_open(&soft_uart->suart_hdl[port->line]);
+	if (PRU_SUART_SUCCESS != err) {
+		dev_err(&pdev->dev, "failed to open suart: %d\n", err);
+		err = -ENODEV;
+		goto exit;
+	}
+
+	/* set fifo /timeout */
+	if (SUART_FIFO_TIMEOUT_MIN > suart_timeout) {
+		__suart_err("fifo timeout less than %d ms not supported\n",
+			    SUART_FIFO_TIMEOUT_MIN);
+		suart_timeout = SUART_FIFO_TIMEOUT_MIN;
+	} else if (SUART_FIFO_TIMEOUT_MAX < suart_timeout) {
+		__suart_err("fifo timeout more than %d ms not supported\n",
+			    SUART_FIFO_TIMEOUT_MAX);
+		suart_timeout = SUART_FIFO_TIMEOUT_MAX;
+	}
+
+	/* This is only for x8 */
+	timeout = (SUART_DEFAULT_BAUD * suart_timeout) / 1000;
+	pru_set_fifo_timeout(dev, timeout);
+
+	if (soft_uart->suart_hdl[port->line].uart_num == PRU_SUART_UART1) {
+		pru_suart_config.tx_serializer = PRU_SUART0_CONFIG_TX_SER;
+		pru_suart_config.rx_serializer = PRU_SUART0_CONFIG_RX_SER;
+	} else if (soft_uart->suart_hdl[port->line].uart_num ==
+							PRU_SUART_UART2) {
+		pru_suart_config.tx_serializer = PRU_SUART1_CONFIG_TX_SER;
+		pru_suart_config.rx_serializer = PRU_SUART1_CONFIG_RX_SER;
+	} else if (soft_uart->suart_hdl[port->line].uart_num ==
+							PRU_SUART_UART3) {
+		pru_suart_config.tx_serializer = PRU_SUART2_CONFIG_TX_SER;
+		pru_suart_config.rx_serializer = PRU_SUART2_CONFIG_RX_SER;
+	} else if (soft_uart->suart_hdl[port->line].uart_num ==
+							PRU_SUART_UART4) {
+		pru_suart_config.tx_serializer = PRU_SUART3_CONFIG_TX_SER;
+		pru_suart_config.rx_serializer = PRU_SUART3_CONFIG_RX_SER;
+	} else if (soft_uart->suart_hdl[port->line].uart_num ==
+							PRU_SUART_UART5) {
+		pru_suart_config.tx_serializer = PRU_SUART4_CONFIG_TX_SER;
+		pru_suart_config.rx_serializer = PRU_SUART4_CONFIG_RX_SER;
+	} else if (soft_uart->suart_hdl[port->line].uart_num ==
+							PRU_SUART_UART6) {
+		pru_suart_config.tx_serializer = PRU_SUART5_CONFIG_TX_SER;
+		pru_suart_config.rx_serializer = PRU_SUART5_CONFIG_RX_SER;
+	} else if (soft_uart->suart_hdl[port->line].uart_num ==
+							PRU_SUART_UART7) {
+		pru_suart_config.tx_serializer = PRU_SUART6_CONFIG_TX_SER;
+		pru_suart_config.rx_serializer = PRU_SUART6_CONFIG_RX_SER;
+	} else if (soft_uart->suart_hdl[port->line].uart_num ==
+							PRU_SUART_UART8) {
+		pru_suart_config.tx_serializer = PRU_SUART7_CONFIG_TX_SER;
+		pru_suart_config.rx_serializer = PRU_SUART7_CONFIG_RX_SER;
+	} else {
+		return -ENOTSUPP;
+	}
+
+	/* Some defaults to startup. reconfigured by terimos later */
+	pru_suart_config.tx_clk_divisor = 1;
+	pru_suart_config.rx_clk_divisor = 1;
+	pru_suart_config.tx_bits_per_char = ePRU_SUART_DATA_BITS8;
+	pru_suart_config.rx_bits_per_char = ePRU_SUART_DATA_BITS8;
+	pru_suart_config.oversampling = SUART_DEFAULT_OVRSMPL;
+
+	if (PRU_SUART_SUCCESS !=
+		pru_softuart_setconfig(dev, &soft_uart->suart_hdl[port->line],
+			&pru_suart_config)) {
+		dev_err(&pdev->dev,
+			"pru_softuart_setconfig: failed to set config: %X\n",
+			err);
+	}
+exit:
+	return err;
+}
+
+/*
+ * Perform any autoconfiguration steps required for the port.  `flag`
+ * contains a bit mask of the required configuration.  UART_CONFIG_TYPE
+ * indicates that the port requires detection and identification.
+ * port->type should be set to the type found, or PORT_UNKNOWN if
+ * no port was detected.
+ *
+ * UART_CONFIG_IRQ indicates autoconfiguration of the interrupt signal,
+ * which should be probed using standard kernel autoprobing techniques.
+ * This is not necessary on platforms where ports have interrupts
+ * internally hard wired (eg, system on a chip implementations).
+ *
+ * Locking: none.
+ * Interrupts: caller dependent.
+ */
+
+static void pruss_suart_config_port(struct uart_port *port, s32 flags)
+{
+	if (flags & UART_CONFIG_TYPE && pruss_suart_request_port(port) == 0)
+		port->type = PORT_DA8XX_PRU_SUART;
+}
+
+/*
+ * Verify the new serial port information contained within serinfo is
+ * suitable for this port type.
+ *
+ * Locking: none.
+ * Interrupts: caller dependent.
+ */
+static s32 pruss_suart_verify_port(struct uart_port *port,
+				 struct serial_struct *ser)
+{
+	struct omapl_pru_suart *soft_uart =
+	    container_of(port, struct omapl_pru_suart, port[port->line]);
+	s32 ret = 0;
+
+	if (ser->type != PORT_UNKNOWN && ser->type != PORT_DA8XX_PRU_SUART)
+		ret = -EINVAL;
+	if (soft_uart->port[port->line].irq != ser->irq)
+		ret = -EINVAL;
+	if (ser->io_type != UPIO_MEM)
+		ret = -EINVAL;
+	if (soft_uart->port[port->line].uartclk / 16 != ser->baud_base)
+		ret = -EINVAL;
+	if ((void *)soft_uart->port[port->line].mapbase != ser->iomem_base)
+		ret = -EINVAL;
+	if (soft_uart->port[port->line].iobase != ser->port)
+		ret = -EINVAL;
+	return ret;
+}
+
+static struct uart_ops pruss_suart_ops = {
+	.tx_empty	= pruss_suart_tx_empty,
+	.set_mctrl	= pruss_suart_set_mctrl,
+	.get_mctrl	= pruss_suart_get_mctrl,
+	.stop_tx	= pruss_suart_stop_tx,
+	.start_tx	= pruss_suart_start_tx,
+	.stop_rx	= pruss_suart_stop_rx,
+	.enable_ms	= pruss_suart_enable_ms,
+	.break_ctl	= pruss_suart_break_ctl,
+	.startup	= pruss_suart_startup,
+	.shutdown	= pruss_suart_shutdown,
+	.set_termios	= pruss_suart_set_termios,
+	.type		= pruss_suart_type,
+	.release_port	= pruss_suart_release_port,
+	.request_port	= pruss_suart_request_port,
+	.config_port	= pruss_suart_config_port,
+	.verify_port	= pruss_suart_verify_port,
+};
+
+static struct uart_driver pruss_suart_reg = {
+	.owner		= THIS_MODULE,
+	.driver_name	= DRV_NAME,
+	.dev_name	= "ttySU",
+	.major		= 0,
+	.minor		= 16,
+	.nr		= NR_SUART,
+};
+
+static s32 __devinit pruss_suart_probe(struct platform_device *pdev)
+{
+	struct omapl_pru_suart *soft_uart;
+	const struct da850_evm_pruss_suart_data *pdata;
+	struct device *dev = &pdev->dev;
+	s32 err, i;
+	u8 *fw_data = NULL;
+
+	pdata = dev->platform_data;
+	if (!pdata) {
+		dev_err(&pdev->dev, "platform data not found\n");
+		return -EINVAL;
+	}
+
+	soft_uart = kzalloc(sizeof(struct omapl_pru_suart), GFP_KERNEL);
+	if (!soft_uart)
+		return -ENOMEM;
+
+	if (!request_mem_region(pdata->resource.start,
+			resource_size(&pdata->resource),
+			dev_name(&pdev->dev))) {
+		dev_err(&pdev->dev, "mcasp memory region already claimed!\n");
+		err = -EBUSY;
+		goto probe_exit;
+	}
+
+	soft_uart->suart_iomap.mcasp_io_addr =
+			ioremap(pdata->resource.start,
+			resource_size(&pdata->resource));
+	if (!soft_uart->suart_iomap.mcasp_io_addr) {
+		dev_err(&pdev->dev, "mcasp ioremap failed\n");
+		err = -EFAULT;
+		goto probe_exit_1;
+	}
+
+	soft_uart->suart_iomap.p_fifo_buff_virt_base =
+	sram_alloc(SUART_CNTX_SZ * NR_SUART * 2,
+	(dma_addr_t *) &soft_uart->suart_iomap.p_fifo_buff_phys_base);
+	if (!soft_uart->suart_iomap.p_fifo_buff_virt_base)
+		goto probe_exit_iounmap;
+
+	soft_uart->clk_freq_pru = pruss_get_clk_freq(dev);
+
+	soft_uart->clk_mcasp = clk_get(&pdev->dev, NULL);
+	if (IS_ERR(soft_uart->clk_mcasp)) {
+		dev_err(&pdev->dev, "no clock available: mcasp\n");
+		err = -ENODEV;
+		soft_uart->clk_mcasp = NULL;
+		goto probe_exit_sram_free;
+	}
+
+	soft_uart->clk_freq_mcasp = clk_get_rate(soft_uart->clk_mcasp);
+	clk_enable(soft_uart->clk_mcasp);
+
+	err = request_firmware(&soft_uart->fw, "PRU_SUART_Emulation.bin",
+			       &pdev->dev);
+	if (err) {
+		dev_err(&pdev->dev, "can't load firmware\n");
+		err = -ENODEV;
+		goto probe_exit_clk;
+	}
+	dev_info(&pdev->dev, "fw size %td. downloading...\n",
+		soft_uart->fw->size);
+
+	/* download firmware into pru  & init */
+	fw_data = kmalloc(soft_uart->fw->size, GFP_KERNEL);
+	memcpy((void *)fw_data, (const void *)soft_uart->fw->data,
+		soft_uart->fw->size);
+
+	soft_uart->suart_iomap.pru_clk_freq =
+		(soft_uart->clk_freq_pru / 1000000);
+
+	err = pru_softuart_init(dev, SUART_DEFAULT_BAUD, SUART_DEFAULT_BAUD,
+			SUART_DEFAULT_OVRSMPL, fw_data,
+			soft_uart->fw->size, &soft_uart->suart_iomap);
+	if (err) {
+		dev_err(&pdev->dev, "pruss init error\n");
+		err = -ENODEV;
+		kfree((const void *)fw_data);
+		goto probe_release_fw;
+	}
+	kfree((const void *)fw_data);
+
+	platform_set_drvdata(pdev, &soft_uart->port[0]);
+	soft_uart->dev = dev;
+
+	for (i = 0; i < NR_SUART; i++) {
+		soft_uart->port[i].ops = &pruss_suart_ops;
+		soft_uart->port[i].iotype = UPIO_MEM;
+		soft_uart->port[i].flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP;
+		soft_uart->port[i].mapbase =
+			(u32)soft_uart->suart_iomap.p_fifo_buff_virt_base;
+		soft_uart->port[i].membase =
+			(u8 *)&soft_uart->suart_iomap;
+		soft_uart->port[i].type = PORT_DA8XX_PRU_SUART;
+		soft_uart->port[i].irq =
+			platform_get_irq(to_platform_device(dev->parent), i);
+		soft_uart->port[i].dev = &pdev->dev;
+		soft_uart->port[i].irqflags = IRQF_SHARED;
+		soft_uart->port[i].uartclk = soft_uart->clk_freq_mcasp;
+		soft_uart->port[i].fifosize = SUART_FIFO_LEN;
+		soft_uart->tx_loadsz = SUART_FIFO_LEN;
+		soft_uart->port[i].custom_divisor = 1;
+		soft_uart->port[i].line = i;
+		soft_uart->suart_hdl[i].uart_num = i + 1;
+		spin_lock_init(&soft_uart->port[i].lock);
+		soft_uart->port[i].serial_in = NULL;
+
+		soft_uart->suart_fifo_addr[i].fifo_vaddr_buff_tx =
+		soft_uart->suart_iomap.p_fifo_buff_virt_base +
+		(2 * SUART_CNTX_SZ * i);
+
+		soft_uart->suart_fifo_addr[i].fifo_vaddr_buff_rx =
+		soft_uart->suart_iomap.p_fifo_buff_virt_base +
+		((2 * SUART_CNTX_SZ * i) + SUART_CNTX_SZ);
+
+		soft_uart->suart_fifo_addr[i].fifo_phys_addr_tx =
+		soft_uart->suart_iomap.p_fifo_buff_phys_base +
+		(2 * SUART_CNTX_SZ * i);
+
+		soft_uart->suart_fifo_addr[i].fifo_phys_addr_rx =
+		soft_uart->suart_iomap.p_fifo_buff_phys_base +
+		((2 * SUART_CNTX_SZ * i) + SUART_CNTX_SZ);
+
+		soft_uart->port[i].serial_out = NULL;
+		uart_add_one_port(&pruss_suart_reg, &soft_uart->port[i]);
+		sema_init(&soft_uart->port_sem[i], 1);
+	}
+
+	dev_info(&pdev->dev,
+		"%s device registered (pru_clk=%d, asp_clk=%d)\n",
+		DRV_NAME, soft_uart->clk_freq_pru, soft_uart->clk_freq_mcasp);
+
+	return 0;
+
+probe_release_fw:
+	release_firmware(soft_uart->fw);
+probe_exit_clk:
+	clk_put(soft_uart->clk_mcasp);
+	clk_disable(soft_uart->clk_mcasp);
+probe_exit_sram_free:
+	sram_free(soft_uart->suart_iomap.p_fifo_buff_virt_base,
+	SUART_CNTX_SZ * NR_SUART * 2);
+probe_exit_iounmap:
+	iounmap(soft_uart->suart_iomap.mcasp_io_addr);
+probe_exit_1:
+	release_mem_region(pdata->resource.start,
+		resource_size(&pdata->resource));
+probe_exit:
+	kfree(soft_uart);
+	return err;
+}
+
+static s32 __devexit pruss_suart_remove(struct platform_device *pdev)
+{
+	struct omapl_pru_suart *soft_uart = platform_get_drvdata(pdev);
+	const struct da850_evm_pruss_suart_data *pdata;
+	struct device *dev = &pdev->dev;
+	int i;
+
+	pdata = dev->platform_data;
+	if (!pdata)
+		dev_err(&pdev->dev, "platform data not found\n");
+
+	platform_set_drvdata(pdev, NULL);
+
+	if (soft_uart) {
+		for (i = 0; i < NR_SUART; i++) {
+			uart_remove_one_port(&pruss_suart_reg,
+			&soft_uart->port[i]);
+		}
+	}
+
+	sram_free(soft_uart->suart_iomap.p_fifo_buff_virt_base,
+		SUART_CNTX_SZ * NR_SUART * 2);
+	release_firmware(soft_uart->fw);
+	clk_put(soft_uart->clk_mcasp);
+	clk_disable(soft_uart->clk_mcasp);
+	iounmap(soft_uart->suart_iomap.mcasp_io_addr);
+	if (pdata) {
+		release_mem_region(pdata->resource.start,
+			resource_size(&pdata->resource));
+	}
+	kfree(soft_uart);
+	return 0;
+}
+
+#define pruss_suart_suspend NULL
+#define pruss_suart_resume NULL
+
+static struct platform_driver serial_pruss_driver = {
+	.probe		= pruss_suart_probe,
+	.remove		= __devexit_p(pruss_suart_remove),
+	.suspend	= pruss_suart_suspend,
+	.resume		= pruss_suart_resume,
+	.driver		= {
+			.name	= DRV_NAME,
+			.owner	= THIS_MODULE,
+	},
+};
+
+static s32 __init pruss_suart_init(void)
+{
+	s32 ret;
+
+	pruss_suart_reg.nr = NR_SUART;
+	ret = uart_register_driver(&pruss_suart_reg);
+	if (ret)
+		return ret;
+	ret = platform_driver_register(&serial_pruss_driver);
+	if (ret)
+		goto out;
+
+	__suart_debug("SUART serial driver loaded\n");
+	return ret;
+out:
+	uart_unregister_driver(&pruss_suart_reg);
+	return ret;
+}
+
+module_init(pruss_suart_init);
+
+static void __exit pruss_suart_exit(void)
+{
+	platform_driver_unregister(&serial_pruss_driver);
+	uart_unregister_driver(&pruss_suart_reg);
+	__suart_debug("SUART serial driver unloaded\n");
+}
+
+module_exit(pruss_suart_exit);
+
+/* Module information */
+MODULE_AUTHOR("Subhasish Ghosh <subhasish at mistralsolutions.com>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION(DRV_DESC);
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
new file mode 100644
index 0000000..d809dd3
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
@@ -0,0 +1,2350 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
+ *
+ * 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/types.h>
+#include <linux/mfd/pruss/da8xx_pru.h>
+#include <linux/io.h>
+#include <mach/hardware.h>
+#include "pruss_suart_api.h"
+#include "pruss_suart_regs.h"
+#include "pruss_suart_board.h"
+#include "pruss_suart_utils.h"
+#include "pruss_suart_err.h"
+
+static u8 g_uart_statu_table[8];
+static pruss_suart_iomap suart_iomap;
+
+static u32 uart_rx[8] = {PRU_SUART0_CONFIG_RX_SER, PRU_SUART1_CONFIG_RX_SER,
+			PRU_SUART2_CONFIG_RX_SER, PRU_SUART3_CONFIG_RX_SER,
+			PRU_SUART4_CONFIG_RX_SER, PRU_SUART5_CONFIG_RX_SER,
+			PRU_SUART6_CONFIG_RX_SER, PRU_SUART7_CONFIG_RX_SER};
+
+static u32 uart_tx[8] = {PRU_SUART0_CONFIG_TX_SER, PRU_SUART1_CONFIG_TX_SER,
+			PRU_SUART2_CONFIG_TX_SER, PRU_SUART3_CONFIG_TX_SER,
+			PRU_SUART4_CONFIG_TX_SER, PRU_SUART5_CONFIG_TX_SER,
+			PRU_SUART6_CONFIG_TX_SER, PRU_SUART7_CONFIG_TX_SER};
+
+static u32 uart_config[8] = {PRU_SUART0_CONFIG_DUPLEX, PRU_SUART1_CONFIG_DUPLEX,
+			PRU_SUART2_CONFIG_DUPLEX, PRU_SUART3_CONFIG_DUPLEX,
+			PRU_SUART4_CONFIG_DUPLEX, PRU_SUART5_CONFIG_DUPLEX,
+			PRU_SUART6_CONFIG_DUPLEX, PRU_SUART7_CONFIG_DUPLEX};
+
+#if (PRU_ACTIVE == BOTH_PRU)
+#if 1
+void pru_set_ram_data(struct device *dev, pruss_suart_iomap *pruss_ioaddr)
+{
+	u16 u16datatowrite;
+	u32 u32datatowrite;
+	u32 i;
+	pru_suart_regs_ovly pru_suart_regs = PRU0_DATARAM_OFFSET;
+	u32 *pu32_sr_ctl_addr = (u32 *)(pruss_ioaddr->mcasp_io_addr + 0x180);
+	pru_suart_tx_cntx_priv *pru_suart_tx_priv = NULL;
+	pru_suart_rx_cntx_priv *pru_suart_rx_priv = NULL;
+
+	/* RX PRU - 0 Chanel 0-7 context information */
+	for (i = 0; i < 8; i++, pru_suart_regs++) {
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_ctrl, &u16datatowrite, 1);
+		u16datatowrite |= (SUART_CHN_RX << 0);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_ctrl,
+						&u16datatowrite, 1);
+
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_ctrl, &u16datatowrite, 1);
+		u16datatowrite |= ((0xF & uart_rx[i]) << 8);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_ctrl,
+						&u16datatowrite, 1);
+
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_config1,
+						&u16datatowrite, 1);
+		u16datatowrite |= (SUART_DEFAULT_OVRSMPL << 10);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_config1,
+						&u16datatowrite, 1);
+
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_config2,
+						&u16datatowrite, 1);
+		u16datatowrite |= 8;
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_config2,
+						&u16datatowrite, 1);
+
+		if ((uart_config[i] & PRU_SUART_HALF_RX_DISABLED) ==
+					PRU_SUART_HALF_RX_DISABLED) {
+			pruss_readw(dev, (u32) &pru_suart_regs->ch_txrx_status,
+						&u16datatowrite, 1);
+			u16datatowrite |= (SUART_CHN_DISABLED << 15) ;
+			pruss_writew(dev, (u32) &pru_suart_regs->ch_txrx_status,
+						&u16datatowrite, 1);
+		} else {
+			pruss_readw(dev, (u32) &pru_suart_regs->ch_txrx_status,
+						&u16datatowrite, 1);
+			u16datatowrite |= (SUART_CHN_ENABLED << 15);
+			pruss_writew(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+		__raw_writel(MCASP_SRCTL_RX_MODE, pu32_sr_ctl_addr +
+								uart_rx[i]);
+		}
+		/*
+		* RX is active by default, write the dummy received data at
+		* PRU RAM addr 0x1FC to avoid memory corruption.
+		*/
+		pruss_readl(dev, (u32) &pru_suart_regs->ch_txrx_data,
+							&u32datatowrite, 1);
+		u32datatowrite |= RX_DEFAULT_DATA_DUMP_ADDR;
+		pruss_writel(dev, (u32) &pru_suart_regs->ch_txrx_data,
+							&u32datatowrite, 1);
+		pruss_readl(dev, (u32) &pru_suart_regs->reserved1, &u32datatowrite, 1);
+		u32datatowrite = 0;
+		pruss_writel(dev, (u32) &pru_suart_regs->reserved1,
+							&u32datatowrite, 1);
+		/* SUART1 RX context base addr */
+		pru_suart_rx_priv = (pru_suart_rx_cntx_priv *)
+				(PRU0_DATARAM_OFFSET + (0x090 + (i * 0x020)));
+		u32datatowrite = (MCASP_RBUF_BASE_ADDR + (uart_rx[i] << 2));
+		pruss_writel(dev, (u32) &pru_suart_rx_priv->asp_rbuf_base,
+				&u32datatowrite, 1);
+		u32datatowrite = (MCASP_SRCTL_BASE_ADDR + (uart_rx[i] << 2));
+		pruss_writel(dev, (u32) &pru_suart_rx_priv->asp_rsrctl_base,
+				&u32datatowrite, 1);
+	}
+
+	/* ****************** PRU1 RAM BASE ADDR ************************ */
+	pru_suart_regs = (pru_suart_regs_ovly) PRU1_DATARAM_OFFSET;
+
+	/* ******************* TX PRU - 1  *********************** */
+	/* Channel 0-7 context information */
+	for (i = 0; i < 8; i++, pru_suart_regs++) {
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_ctrl, &u16datatowrite, 1);
+		u16datatowrite |= (SUART_CHN_TX << 0);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_ctrl,
+						&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_ctrl, &u16datatowrite, 1);
+		u16datatowrite |= (0xF & uart_tx[i] << 8);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_ctrl,
+							&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_config1,
+						&u16datatowrite, 1);
+		u16datatowrite |= (SUART_DEFAULT_OVRSMPL << 10);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_config1,
+						&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_config2,
+						&u16datatowrite, 1);
+		u16datatowrite |= 8;
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_config2,
+						&u16datatowrite, 1);
+		if ((uart_config[i] & PRU_SUART_HALF_TX_DISABLED) ==
+						PRU_SUART_HALF_TX_DISABLED) {
+			pruss_readw(dev, (u32) &pru_suart_regs->ch_txrx_status,
+						&u16datatowrite, 1);
+			u16datatowrite |= (SUART_CHN_DISABLED << 15);
+			pruss_writew(dev, (u32) &pru_suart_regs->ch_txrx_status,
+						&u16datatowrite, 1);
+		} else {
+			pruss_readw(dev, (u32) &pru_suart_regs->ch_txrx_status,
+						&u16datatowrite, 1);
+			u16datatowrite |= (SUART_CHN_ENABLED << 15);
+			pruss_writew(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+		__raw_writel(MCASP_SRCTL_TX_MODE,
+				pu32_sr_ctl_addr + uart_tx[i]);
+		}
+		pruss_readl(dev, (u32) &pru_suart_regs->reserved1, &u32datatowrite, 1);
+		u32datatowrite |= 1;
+		pruss_writel(dev, (u32) &pru_suart_regs->reserved1,
+							 &u32datatowrite, 1);
+	/* SUART1 TX context base addr */
+		 pru_suart_tx_priv = (pru_suart_tx_cntx_priv *)
+			(PRU1_DATARAM_OFFSET + (0x0B0 + (i * 0x02C)));
+		u32datatowrite = (MCASP_SRCTL_BASE_ADDR + (uart_tx[i] << 2));
+		pruss_writel(dev, (u32) &pru_suart_tx_priv->asp_xsrctl_base,
+				&u32datatowrite, 1);
+		u32datatowrite = (MCASP_XBUF_BASE_ADDR + (uart_tx[i] << 2));
+		pruss_writel(dev, (u32) &pru_suart_tx_priv->asp_xbuf_base,
+				&u32datatowrite, 1);
+	/* SUART1 TX formatted data base addr */
+		u32datatowrite = (0x0090 + (i * 0x002C));
+		pruss_writel(dev, (u32) &pru_suart_tx_priv->buff_addr,
+					&u32datatowrite, 1);
+	}
+}
+#endif
+#else
+void pru_set_ram_data(struct device *dev, pruss_suart_iomap *pruss_ioaddr)
+{
+
+	pru_suart_regs_ovly pru_suart_regs = (pru_suart_regs_ovly)
+						pruss_ioaddr->pru_io_addr;
+	u32 i;
+	u32 *pu32_sr_ctl_addr = (u32 *)(pruss_ioaddr->mcasp_io_addr + 0x180);
+	pru_suart_tx_cntx_priv *pru_suart_tx_priv = NULL;
+	pru_suart_rx_cntx_priv *pru_suart_rx_priv = NULL;
+
+	/* ***************** UART 0  ************************ */
+	/* Channel 0 context information is Tx */
+	for (i = 0; i < 4; i++, pru_suart_regs++) {
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_ctrl, &u16datatowrite, 1);
+		u16datatowrite |= (SUART_CHN_TX << 8);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_ctrl,
+							&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_ctrl, &u16datatowrite, 1);
+		u16datatowrite |= (0xF & uart_tx[i]);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_ctrl,
+							&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_config1,
+							&u16datatowrite, 1);
+		u16datatowrite |= (SUART_DEFAULT_OVRSMPL << 10);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_config1,
+							&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_config2,
+							&u16datatowrite, 1);
+		u16datatowrite |= 8;
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_config2,
+							&u16datatowrite, 1);
+		if ((uart_config[i] & PRU_SUART_HALF_TX_DISABLED) ==
+						PRU_SUART_HALF_TX_DISABLED){
+			pruss_readw(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+			u16datatowrite |= (SUART_CHN_DISABLED << 15);
+			pruss_writew(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+		} else {
+			pruss_readw(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+			u16datatowrite |= (SUART_CHN_ENABLED << 15);
+			pruss_writew(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+			__raw_writel(MCASP_SRCTL_TX_MODE,
+						pu32_sr_ctl_addr + uart_tx[i]);
+		}
+		pruss_readl(dev, (u32) &pru_suart_regs->reserved1, &u32datatowrite, 1);
+		u32datatowrite |= 1;
+		pruss_writel(dev, (u32) &pru_suart_regs->reserved1,
+							&u32datatowrite, 1);
+	/* SUART1 TX context base addr */
+		 pru_suart_tx_priv = (pru_suart_tx_cntx_priv *)
+				(PRU0_DATARAM_OFFSET + (0x0B0 + (i * 0x50)));
+		pruss_writel(dev, (u32) &pru_suart_tx_priv->asp_xsrctl_base,
+				(MCASP_SRCTL_BASE_ADDR + (uart_tx[i] << 2)), 1);
+		pruss_writel(dev, (u32) &pru_suart_tx_priv->asp_xbuf_base,
+				(MCASP_XBUF_BASE_ADDR + (uart_tx[i] << 2)), 1);
+	/* SUART1 TX formatted data base addr */
+		pruss_writel(dev, (u32) &pru_suart_tx_priv->buff_addr,
+					(0x0090 + (i * 0x050)), 1);
+
+	/* Channel 1 is Rx context information */
+		pru_suart_regs++;
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_ctrl, &u16datatowrite, 1);
+		u16datatowrite |= (SUART_CHN_RX << 8);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_ctrl,
+						&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_ctrl, &u16datatowrite, 1);
+		u16datatowrite |= (0xF & uart_rx[i]);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_ctrl,
+							&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_config1,
+							&u16datatowrite, 1);
+		u16datatowrite |= (SUART_DEFAULT_OVRSMPL << 10);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_config1,
+							&u16datatowrite, 1);
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_config2,
+							&u16datatowrite, 1);
+		u16datatowrite |= 8;
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_config2,
+							&u16datatowrite, 1);
+		if ((uart_config[i] & PRU_SUART_HALF_RX_DISABLED) ==
+						PRU_SUART_HALF_RX_DISABLED) {
+			pruss_readw(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+			u16datatowrite |= (SUART_CHN_DISABLED << 15);
+			pruss_writew(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+		} else {
+		pruss_readw(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+		u16datatowrite |= (SUART_CHN_ENABLED << 15);
+		pruss_writew(dev, (u32) &pru_suart_regs->ch_txrx_status,
+							&u16datatowrite, 1);
+		__raw_writel(MCASP_SRCTL_RX_MODE,
+					pu32_sr_ctl_addr + uart_rx[i]);
+		}
+	/* RX is active by default, write the dummy received data
+	 * at PRU RAM addr 0x1FC to avoid memory corruption
+	 */
+		pruss_readl(dev, (u32) &pru_surt_regs->ch_txrx_data,
+						&u32datatowrite, 1);
+		u32datatowrite |= RX_DEFAULT_DATA_DUMP_ADDR;
+		pruss_writel(dev, (u32) &pru_suart_regs->ch_txrx_data,
+							&u32datatowrite, 1);
+		pruss_readl(dev, (u32) &pru_suart_regs->reserved1, &u32datatowrite, 1);
+		u32datatowrite = 0;
+	pruss_writel(dev, (u32) &pru_suart_regs->reserved1, &u32datatowrite, 1);
+	/* SUART1 RX context base addr */
+		pru_suart_rx_priv = (pru_suart_rx_cntx_priv *)
+			(PRU0_DATARAM_OFFSET + (0x0C0 + (i * 0x50)));
+		pruss_writel(dev, (u32) &pru_suart_rx_priv->asp_rbuf_base,
+				(MCASP_RBUF_BASE_ADDR + (uart_rx[i] << 2)), 1);
+		pruss_writel(dev, (u32) &pru_suart_rx_priv->asp_rsrctl_base,
+				(MCASP_SRCTL_BASE_ADDR + (uart_rx[i] << 2)), 1);
+	}
+}
+#endif
+
+static void pru_set_rx_tx_mode(struct device *dev, u32 pru_mode, u32 pru_num)
+{
+
+	u32 pru_offset;
+
+	if (pru_num == PRUSS_NUM0)
+		pru_offset = PRU_SUART_PRU0_RX_TX_MODE;
+	else if (pru_num == PRUSS_NUM1)
+		pru_offset = PRU_SUART_PRU1_RX_TX_MODE;
+	else
+		return;
+	pruss_writeb(dev, pru_offset, (u8 *) &pru_mode, 1);
+}
+
+static void pru_set_delay_count(struct device *dev, u32 pru_freq)
+{
+	u32 u32delay_cnt;
+
+	if (pru_freq == 228)
+		u32delay_cnt = 5;
+	else if (pru_freq == 186)
+		u32delay_cnt = 5;
+	else
+		u32delay_cnt = 3;
+
+	/* PRU 0 */
+	pruss_writeb(dev, PRU_SUART_PRU0_DELAY_OFFSET,
+		(u8 *) &u32delay_cnt, 1);
+
+	/* PRU 1 */
+	pruss_writeb(dev, PRU_SUART_PRU1_DELAY_OFFSET,
+		(u8 *) &u32delay_cnt, 1);
+}
+
+static s32 suart_set_pru_id(struct device *dev, u32 pru_no)
+{
+	u32 offset;
+	u8 reg_val = 0;
+
+	if (0 == pru_no)
+		offset = PRU_SUART_PRU0_ID_ADDR;
+	else if (1 == pru_no)
+		offset = PRU_SUART_PRU1_ID_ADDR;
+	else
+		return PRU_SUART_FAILURE;
+
+	reg_val = pru_no;
+	pruss_writeb(dev, offset, (u8 *) &reg_val, 1);
+
+	return PRU_SUART_SUCCESS;
+}
+
+/*
+ * suart Initialization routine
+ */
+s16 pru_softuart_init(struct device *dev, u32 tx_baud_value,
+			u32 rx_baud_value, u32 oversampling,
+			u8 *pru_suart_emu_code, u32 fw_size,
+			pruss_suart_iomap *pruss_ioaddr)
+{
+	u32 u32datatowrite[128] = {0};
+	s16 status = PRU_SUART_SUCCESS;
+	s16 idx;
+	s16 retval;
+
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) &&
+				(PRU1_MODE == PRU_MODE_RX_TX_BOTH))
+		return PRU_SUART_FAILURE;
+
+	suart_iomap.mcasp_io_addr = pruss_ioaddr->mcasp_io_addr;
+	suart_iomap.p_fifo_buff_phys_base =
+					pruss_ioaddr->p_fifo_buff_phys_base;
+	suart_iomap.p_fifo_buff_virt_base =
+					pruss_ioaddr->p_fifo_buff_virt_base;
+	suart_iomap.pru_clk_freq = pruss_ioaddr->pru_clk_freq;
+	/* Configure McASP0  */
+	suart_mcasp_config(tx_baud_value,
+			rx_baud_value, oversampling, pruss_ioaddr);
+	pruss_enable(dev, PRUSS_NUM0);
+	pruss_enable(dev, PRUSS_NUM1);
+
+	/* Reset PRU RAM */
+	pruss_writel(dev, PRU0_DATARAM_OFFSET, u32datatowrite,
+				 (PRU0_DATARAM_SIZE / sizeof(int)));
+	pruss_writel(dev, PRU1_DATARAM_OFFSET, u32datatowrite,
+				 (PRU1_DATARAM_SIZE / sizeof(int)));
+	pruss_load(dev, PRUSS_NUM0, (u32 *)pru_suart_emu_code,
+				(fw_size / sizeof(u32)));
+	pruss_load(dev, PRUSS_NUM1, (u32 *)pru_suart_emu_code,
+				(fw_size / sizeof(u32)));
+	retval = arm_to_pru_intr_init(dev);
+	if (-1 == retval)
+		return status;
+	pru_set_delay_count(dev, pruss_ioaddr->pru_clk_freq);
+	suart_set_pru_id(dev, PRUSS_NUM0);
+	suart_set_pru_id(dev, PRUSS_NUM1);
+	pru_set_rx_tx_mode(dev, PRU0_MODE, PRUSS_NUM0);
+	pru_set_rx_tx_mode(dev, PRU1_MODE, PRUSS_NUM1);
+	pru_set_ram_data(dev, pruss_ioaddr);
+	pruss_run(dev, PRUSS_NUM0);
+	pruss_run(dev, PRUSS_NUM1);
+
+	/* Initialize g_uart_statu_table */
+	for (idx = 0; idx < 8; idx++)
+		g_uart_statu_table[idx] = ePRU_SUART_UART_FREE;
+
+	return status;
+}
+
+void pru_set_fifo_timeout(struct device *dev, s16 timeout)
+{
+	pruss_writew(dev, PRU_SUART_PRU0_IDLE_TIMEOUT_OFFSET,
+		&timeout, 1);
+	pruss_writew(dev, PRU_SUART_PRU1_IDLE_TIMEOUT_OFFSET,
+		&timeout, 1);
+}
+
+s16 pru_softuart_deinit(struct device *dev)
+{
+	u32 offset;
+	s16 s16retval = 0;
+	u32 u32value = 0;
+
+	offset = (u32) (PRUSS_INTC_STATCLRINT1 & 0xFFFF);
+	u32value = 0xFFFFFFFF;
+	s16retval = pruss_writel(dev, offset, (u32 *)&u32value, 1);
+	if (-1 == s16retval)
+		return -1;
+	offset = (u32) (PRUSS_INTC_STATCLRINT0 & 0xFFFF);
+	u32value = 0xFFFFFFFF;
+	s16retval = pruss_writel(dev, offset, (u32 *)&u32value, 1);
+	if (-1 == s16retval)
+		return -1;
+	pruss_disable(dev, 0);
+	pruss_disable(dev, 1);
+
+	return PRU_SUART_SUCCESS;
+}
+
+/* suart Instance open routine  */
+s16 pru_softuart_open(suart_handle h_suart)
+{
+	s16 status = PRU_SUART_SUCCESS;
+
+	switch (h_suart->uart_num) {
+	case PRU_SUART_UART1:
+		if (g_uart_statu_table[PRU_SUART_UART1 - 1] ==
+				ePRU_SUART_UART_IN_USE) {
+			status = SUART_UART_IN_USE;
+			return status;
+		} else {
+			h_suart->uart_status = ePRU_SUART_UART_IN_USE;
+			h_suart->uart_type = PRU_SUART0_CONFIG_DUPLEX;
+			h_suart->uart_tx_channel = PRU_SUART0_CONFIG_TX_SER;
+			h_suart->uart_rx_channel = PRU_SUART0_CONFIG_RX_SER;
+			g_uart_statu_table[PRU_SUART_UART1 - 1] =
+			    ePRU_SUART_UART_IN_USE;
+		}
+		break;
+
+	case PRU_SUART_UART2:
+		if (g_uart_statu_table[PRU_SUART_UART2 - 1] ==
+				ePRU_SUART_UART_IN_USE) {
+			status = SUART_UART_IN_USE;
+			return status;
+		} else {
+
+			h_suart->uart_status = ePRU_SUART_UART_IN_USE;
+			h_suart->uart_type = PRU_SUART1_CONFIG_DUPLEX;
+			h_suart->uart_tx_channel = PRU_SUART1_CONFIG_TX_SER;
+			h_suart->uart_rx_channel = PRU_SUART1_CONFIG_RX_SER;
+			g_uart_statu_table[PRU_SUART_UART2 - 1] =
+			    ePRU_SUART_UART_IN_USE;
+		}
+		break;
+
+	case PRU_SUART_UART3:
+		if (g_uart_statu_table[PRU_SUART_UART3 - 1] ==
+				ePRU_SUART_UART_IN_USE) {
+			status = SUART_UART_IN_USE;
+			return status;
+		} else {
+
+			h_suart->uart_status = ePRU_SUART_UART_IN_USE;
+			h_suart->uart_type = PRU_SUART2_CONFIG_DUPLEX;
+			h_suart->uart_tx_channel = PRU_SUART2_CONFIG_TX_SER;
+			h_suart->uart_rx_channel = PRU_SUART2_CONFIG_RX_SER;
+			g_uart_statu_table[PRU_SUART_UART3 - 1] =
+			    ePRU_SUART_UART_IN_USE;
+		}
+		break;
+
+	case PRU_SUART_UART4:
+		if (g_uart_statu_table[PRU_SUART_UART4 - 1] ==
+				ePRU_SUART_UART_IN_USE) {
+			status = SUART_UART_IN_USE;
+			return status;
+		} else {
+
+			h_suart->uart_status = ePRU_SUART_UART_IN_USE;
+			h_suart->uart_type = PRU_SUART3_CONFIG_DUPLEX;
+			h_suart->uart_tx_channel = PRU_SUART3_CONFIG_TX_SER;
+			h_suart->uart_rx_channel = PRU_SUART3_CONFIG_RX_SER;
+
+			g_uart_statu_table[PRU_SUART_UART4 - 1] =
+			    ePRU_SUART_UART_IN_USE;
+		}
+		break;
+
+	case PRU_SUART_UART5:
+		if (g_uart_statu_table[PRU_SUART_UART5 - 1] ==
+				ePRU_SUART_UART_IN_USE) {
+			status = SUART_UART_IN_USE;
+			return status;
+		} else {
+			h_suart->uart_status = ePRU_SUART_UART_IN_USE;
+			h_suart->uart_type = PRU_SUART4_CONFIG_DUPLEX;
+			h_suart->uart_tx_channel = PRU_SUART4_CONFIG_TX_SER;
+			h_suart->uart_rx_channel = PRU_SUART4_CONFIG_RX_SER;
+
+			g_uart_statu_table[PRU_SUART_UART5 - 1] =
+			    ePRU_SUART_UART_IN_USE;
+		}
+		break;
+
+	case PRU_SUART_UART6:
+		if (g_uart_statu_table[PRU_SUART_UART6 - 1] ==
+				ePRU_SUART_UART_IN_USE) {
+			status = SUART_UART_IN_USE;
+			return status;
+		} else {
+			h_suart->uart_status = ePRU_SUART_UART_IN_USE;
+			h_suart->uart_type = PRU_SUART5_CONFIG_DUPLEX;
+			h_suart->uart_tx_channel = PRU_SUART5_CONFIG_TX_SER;
+			h_suart->uart_rx_channel = PRU_SUART5_CONFIG_RX_SER;
+			g_uart_statu_table[PRU_SUART_UART6 - 1] =
+			    ePRU_SUART_UART_IN_USE;
+		}
+		break;
+
+	case PRU_SUART_UART7:
+		if (g_uart_statu_table[PRU_SUART_UART7 - 1] ==
+				ePRU_SUART_UART_IN_USE) {
+			status = SUART_UART_IN_USE;
+			return status;
+		} else {
+			h_suart->uart_status = ePRU_SUART_UART_IN_USE;
+			h_suart->uart_type = PRU_SUART6_CONFIG_DUPLEX;
+			h_suart->uart_tx_channel = PRU_SUART6_CONFIG_TX_SER;
+			h_suart->uart_rx_channel = PRU_SUART6_CONFIG_RX_SER;
+			g_uart_statu_table[PRU_SUART_UART7 - 1] =
+			    ePRU_SUART_UART_IN_USE;
+		}
+		break;
+
+	case PRU_SUART_UART8:
+		if (g_uart_statu_table[PRU_SUART_UART8 - 1] ==
+				ePRU_SUART_UART_IN_USE) {
+			status = SUART_UART_IN_USE;
+			return status;
+		} else {
+			h_suart->uart_status = ePRU_SUART_UART_IN_USE;
+			h_suart->uart_type = PRU_SUART7_CONFIG_DUPLEX;
+			h_suart->uart_tx_channel = PRU_SUART7_CONFIG_TX_SER;
+			h_suart->uart_rx_channel = PRU_SUART7_CONFIG_RX_SER;
+			g_uart_statu_table[PRU_SUART_UART8 - 1] =
+			    ePRU_SUART_UART_IN_USE;
+		}
+		break;
+
+	default:
+		status = SUART_INVALID_UART_NUM;
+		break;
+	}
+	return status;
+}
+
+/* suart instance close routine */
+s16 pru_softuart_close(suart_handle h_uart)
+{
+	s16 status = SUART_SUCCESS;
+
+	if (h_uart == NULL) {
+		return PRU_SUART_ERR_HANDLE_INVALID;
+	} else {
+		g_uart_statu_table[h_uart->uart_num - 1] =
+			ePRU_SUART_UART_FREE;
+		/* Reset the Instance to Invalid */
+		h_uart->uart_num = PRU_SUART_UARTx_INVALID;
+		h_uart->uart_status = ePRU_SUART_UART_FREE;
+	}
+	return status;
+}
+
+/*
+ * suart routine for setting relative baud rate
+ */
+s16 pru_softuart_setbaud(struct device *dev, suart_handle h_uart,
+		u16 tx_clk_divisor, u16 rx_clk_divisor)
+{
+	u32 offset;
+	u32 pru_offset;
+	s16 status = SUART_SUCCESS;
+	u16 ch_num;
+	u16 regval = 0;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	/* Set the clock divisor value s32o the McASP */
+	if ((tx_clk_divisor > 385) || (tx_clk_divisor == 0))
+		return SUART_INVALID_CLKDIVISOR;
+	if ((rx_clk_divisor > 385) || (rx_clk_divisor == 0))
+		return SUART_INVALID_CLKDIVISOR;
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+		|| (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+		}
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	if (tx_clk_divisor != 0) {
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= (~0x3FF);
+		regval |= tx_clk_divisor;
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+	}
+	if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+			(PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num++;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+	regval = 0;
+	if (rx_clk_divisor != 0) {
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= (~0x3FF);
+		regval |= tx_clk_divisor;
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+	}
+	return status;
+}
+
+/*
+ * suart routine for setting number of bits per character for a specific uart
+ */
+s16 pru_softuart_setdatabits(struct device *dev, suart_handle h_uart,
+		u16 tx_data_bits, u16 rx_data_bits)
+{
+	u32 offset;
+	u32 pru_offset;
+	s16 status = SUART_SUCCESS;
+	u16 ch_num;
+	u32 reg_val;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	/*
+	 * NOTE:
+	 * The supported data bits are 6,7,8,9,10,11,12 bits per character
+	 */
+
+	if ((tx_data_bits < ePRU_SUART_DATA_BITS6)
+			|| (tx_data_bits > ePRU_SUART_DATA_BITS12))
+		return PRU_SUART_ERR_PARAMETER_INVALID;
+
+	if ((rx_data_bits < ePRU_SUART_DATA_BITS6)
+			|| (rx_data_bits > ePRU_SUART_DATA_BITS12))
+		return PRU_SUART_ERR_PARAMETER_INVALID;
+
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+			|| (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+		}
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	if (tx_data_bits != 0) {
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG2_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &reg_val, 1);
+		reg_val &= ~(0xF);
+		reg_val |= tx_data_bits;
+		pruss_writeb(dev, offset, (u8 *) &reg_val, 1);
+	}
+	if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+			|| (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num++;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+	if (rx_data_bits != 0) {
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG2_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &reg_val, 1);
+		reg_val &= ~(0xF);
+		reg_val |= rx_data_bits;
+		pruss_writeb(dev, offset, (u8 *) &rx_data_bits, 1);
+	}
+
+	return status;
+}
+
+/*
+ * suart routine to configure specific uart
+ */
+s16 pru_softuart_setconfig(struct device *dev, suart_handle h_uart,
+				suart_config *config_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	s16 status = SUART_SUCCESS;
+	u16 ch_num;
+	u16 reg_val = 0;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	/*
+	 * NOTE:
+	 * Dependent baud rate for the given UART,the value MUST BE LESS THAN OR
+	 * EQUAL TO 64, preScalarValue <= 64
+	 */
+	if ((config_uart->tx_clk_divisor > 384)
+			|| (config_uart->rx_clk_divisor > 384)) {
+		return SUART_INVALID_CLKDIVISOR;
+	}
+	if ((config_uart->tx_bits_per_char < 8)
+			|| (config_uart->tx_bits_per_char > 14)) {
+		return PRU_SUART_ERR_PARAMETER_INVALID;
+	}
+	if ((config_uart->rx_bits_per_char < 8)
+			|| (config_uart->rx_bits_per_char > 14)) {
+		return PRU_SUART_ERR_PARAMETER_INVALID;
+	}
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+			|| (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num = (h_uart->uart_num * SUART_NUM_OF_CHANNELS_PER_SUART)
+									 - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+		}
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	/* Configuring the Transmit part of the given UART */
+	/* Serializer has been as TX in mcasp config, by writing 1 in bits
+	*  corresponding to tx serializer in PFUNC regsiter ie already set
+	*  to GPIO mode PRU code will set then back to MCASP mode once TX
+	*  request for that serializer is posted.It is required because at this
+	*  pos32 Mcasp is accessed by both PRU and DSP have lower priority for
+	*  Mcasp in comparison to PRU and DPS keeps on looping there only
+	*/
+	/*
+	 * suart_mcasp_tx_serialzier_set
+	 * (config_uart->tx_serializer, &suart_iomap);
+	 */
+	/* Configuring TX serializer  */
+	if (config_uart->tx_serializer != PRU_SUART_SERIALIZER_NONE) {
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CTRL_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+		reg_val = reg_val | (config_uart->tx_serializer <<
+			PRU_SUART_CH_CTRL_SR_SHIFT);
+		pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+		reg_val = reg_val | (config_uart->tx_clk_divisor <<
+			PRU_SUART_CH_CONFIG1_DIVISOR_SHIFT);
+		pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG2_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+		reg_val = reg_val | (config_uart->tx_bits_per_char <<
+			PRU_SUART_CH_CONFIG2_BITPERCHAR_SHIFT);
+		pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+		offset = 8;
+		pru_softuart_write(dev, h_uart, &offset, 0);
+	}
+
+	if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+			(PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num++;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	/* Configuring the Transmit part of the given UART */
+	if (config_uart->rx_serializer != PRU_SUART_SERIALIZER_NONE) {
+		/* Configuring RX serializer  */
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CTRL_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+		reg_val = reg_val | (config_uart->rx_serializer <<
+			PRU_SUART_CH_CTRL_SR_SHIFT);
+		pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+
+		/* Configuring RX prescalar value and Oversampling */
+		offset = pru_offset +
+			(ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+		reg_val = reg_val | (config_uart->rx_clk_divisor <<
+			PRU_SUART_CH_CONFIG1_DIVISOR_SHIFT) |
+			(config_uart->oversampling <<
+			PRU_SUART_CH_CONFIG1_OVS_SHIFT);
+		pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+
+		/* Configuring RX bits per character value */
+		offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL)
+						+ PRU_SUART_CH_CONFIG2_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+		reg_val = reg_val | (config_uart->rx_bits_per_char <<
+			PRU_SUART_CH_CONFIG1_DIVISOR_SHIFT);
+		pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+	}
+	return status;
+}
+
+/*
+ * suart routine for getting the number of bytes transfered
+ */
+s16 pru_softuart_get_tx_data_len(struct device *dev, suart_handle h_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 ch_num;
+	u16 u16_read_value = 0;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	ch_num = h_uart->uart_num - 1;
+
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+				(PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num = (h_uart->uart_num * SUART_NUM_OF_CHANNELS_PER_SUART)
+									 - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+		}
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CONFIG2_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &u16_read_value, 2);
+	u16_read_value = ((u16_read_value & PRU_SUART_CH_CONFIG1_DIVISOR_MASK)
+					>> PRU_SUART_CH_CONFIG2_DATALEN_SHIFT);
+	return u16_read_value;
+}
+
+/*
+ * suart routine for getting the number of bytes received
+ */
+s16 pru_softuart_get_rx_data_len(struct device *dev, suart_handle h_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 ch_num;
+	u16 u16_read_value = 0;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+				(PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+		}
+		ch_num++;
+	} else if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CONFIG2_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &u16_read_value, 2);
+	u16_read_value = ((u16_read_value & PRU_SUART_CH_CONFIG1_DIVISOR_MASK)
+					>> PRU_SUART_CH_CONFIG2_DATALEN_SHIFT);
+
+	return u16_read_value;
+}
+
+/*
+ * suart routine to get the configuration information from a specific uart
+ */
+s16 pru_softuart_getconfig(struct device *dev,
+			 suart_handle h_uart, suart_config *config_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 ch_num;
+	u16 reg_val = 0;
+	s16 status = SUART_SUCCESS;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	/*
+	 * NOTE:
+	 * Dependent baud rate for the given UART,the value MUST BE LESS THAN OR
+	 * EQUAL TO 64, preScalarValue <= 64
+	 */
+
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+					 (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num * SUART_NUM_OF_CHANNELS_PER_SUART)
+									 - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+		}
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	/* Configuring the Transmit part of the given UART */
+	/* Configuring TX serializer  */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CTRL_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	config_uart->tx_serializer = ((reg_val & PRU_SUART_CH_CTRL_SR_MASK) >>
+						PRU_SUART_CH_CTRL_SR_SHIFT);
+	/* Configuring TX prescalar value */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CONFIG1_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	config_uart->tx_clk_divisor = ((reg_val &
+				 PRU_SUART_CH_CONFIG1_DIVISOR_MASK) >>
+					 PRU_SUART_CH_CONFIG1_DIVISOR_SHIFT);
+
+	/* Configuring TX bits per character value */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+					PRU_SUART_CH_CONFIG2_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	config_uart->tx_bits_per_char = ((reg_val &
+				 PRU_SUART_CH_CONFIG1_DIVISOR_MASK) >>
+					PRU_SUART_CH_CONFIG1_DIVISOR_SHIFT);
+
+	if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+				(PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num++;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+	/* Configuring the Transmit part of the given UART */
+	/* Configuring RX serializer  */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CTRL_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	config_uart->rx_serializer = ((reg_val & PRU_SUART_CH_CTRL_SR_MASK) >>
+						PRU_SUART_CH_CTRL_SR_SHIFT);
+
+	/* Configuring RX prescalar value and oversampling */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CONFIG1_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	config_uart->rx_clk_divisor = ((reg_val &
+					 PRU_SUART_CH_CONFIG1_DIVISOR_MASK)
+					>> PRU_SUART_CH_CONFIG1_DIVISOR_SHIFT);
+	config_uart->oversampling = ((reg_val &
+					 PRU_SUART_CH_CONFIG1_OVS_MASK) >>
+						PRU_SUART_CH_CONFIG1_OVS_SHIFT);
+
+	/* Configuring RX bits per character value */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CONFIG2_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	config_uart->rx_bits_per_char = ((reg_val &
+					 PRU_SUART_CH_CONFIG1_DIVISOR_MASK)
+					>> PRU_SUART_CH_CONFIG1_DIVISOR_SHIFT);
+
+	return status;
+}
+
+s32 pru_softuart_pending_tx_request(struct device *dev)
+{
+	u32 offset = 0;
+	u32 u32ISR_value = 0;
+
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		return SUART_SUCCESS;
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		/* Read PRU Interrupt Status Register from PRU */
+		offset = (u32) (PRUSS_INTC_STATCLRINT1 & 0xFFFF);
+		pruss_readl(dev, offset, (u32 *)&u32ISR_value, 1);
+		if ((u32ISR_value & 0x1) == 0x1)
+			return PRU_SUART_FAILURE;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		/* Read PRU Interrupt Status Register from PRU */
+		offset = (u32) (PRUSS_INTC_STATCLRINT1 & 0xFFFF);
+		pruss_readl(dev, offset, (u32 *)&u32ISR_value, 1);
+		if ((u32ISR_value & 0x2) == 0x2)
+			return PRU_SUART_FAILURE;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	return SUART_SUCCESS;
+}
+
+/*
+ * suart data transmit routine
+ */
+s16 pru_softuart_write(struct device *dev, suart_handle h_uart,
+		u32 *pt_tx_data_buf, u16 data_len)
+{
+	u32 offset = 0;
+	u32 pru_offset;
+	s16 status = SUART_SUCCESS;
+	u16 ch_num;
+	u16 reg_val = 0;
+	u16 pru_num;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+			pru_num = h_uart->uart_num;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+			pru_num = h_uart->uart_num;
+		}
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		pru_num = 0;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+		pru_num = 1;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	/* Writing data length to SUART channel register */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+				PRU_SUART_CH_CONFIG2_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	reg_val &= ~PRU_SUART_CH_CONFIG2_DATALEN_MASK;
+	reg_val = reg_val | (data_len << PRU_SUART_CH_CONFIG2_DATALEN_SHIFT);
+	pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+
+	/* Writing the data pos32er to channel TX data pointer */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+				PRU_SUART_CH_TXRXDATA_OFFSET;
+	pruss_writeb(dev, offset, (u8 *) pt_tx_data_buf, 4);
+
+	/* Service Request to PRU */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+				PRU_SUART_CH_CTRL_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	reg_val &= ~(PRU_SUART_CH_CTRL_MODE_MASK |
+			PRU_SUART_CH_CTRL_SREQ_MASK);
+	reg_val |= (PRU_SUART_CH_CTRL_TX_MODE <<
+		PRU_SUART_CH_CTRL_MODE_SHIFT) | (PRU_SUART_CH_CTRL_SREQ <<
+		PRU_SUART_CH_CTRL_SREQ_SHIFT);
+	pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+
+	/* generate ARM->PRU event */
+	suart_arm_to_pru_intr(dev, pru_num);
+
+	return status;
+}
+
+/*
+ * suart data receive routine
+ */
+s16 pru_softuart_read(struct device *dev, suart_handle h_uart,
+		u32 *ptDataBuf, u16 data_len)
+{
+	u32 offset = 0;
+	u32 pru_offset;
+	s16 status = SUART_SUCCESS;
+	u16 ch_num;
+	u16 reg_val = 0;
+	u16 pru_num;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+			 (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+	ch_num = (h_uart->uart_num * SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+			pru_num = h_uart->uart_num;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+			pru_num = h_uart->uart_num;
+		}
+		ch_num++;
+	} else if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		pru_num = 0;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+		pru_num = 1;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+	/* Writing data length to SUART channel register */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+					PRU_SUART_CH_CONFIG2_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	reg_val &= ~PRU_SUART_CH_CONFIG2_DATALEN_MASK;
+	reg_val = reg_val | (data_len << PRU_SUART_CH_CONFIG2_DATALEN_SHIFT);
+	pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+
+	/* Writing the data pos32er to channel RX data pointer */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+		PRU_SUART_CH_TXRXDATA_OFFSET;
+	pruss_writeb(dev, offset, (u8 *) ptDataBuf, 4);
+
+	/* Service Request to PRU */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+		PRU_SUART_CH_CTRL_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	reg_val &= ~(PRU_SUART_CH_CTRL_MODE_MASK |
+		PRU_SUART_CH_CTRL_SREQ_MASK);
+	reg_val |= (PRU_SUART_CH_CTRL_RX_MODE <<
+		PRU_SUART_CH_CTRL_MODE_SHIFT) | (PRU_SUART_CH_CTRL_SREQ <<
+		PRU_SUART_CH_CTRL_SREQ_SHIFT);
+	pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+
+	/* enable the timeout s32errupt */
+	suart_intr_setmask(dev, h_uart->uart_num, PRU_RX_INTR,
+		CHN_TXRX_IE_MASK_TIMEOUT);
+
+	/* generate ARM->PRU event */
+	suart_arm_to_pru_intr(dev, pru_num);
+
+	return status;
+}
+
+/*
+ * suart routine to read the data from the RX FIFO
+ */
+s16 pru_softuart_read_data(struct device *dev, suart_handle h_uart,
+				u8 *p_data_buffer, s32 s32max_len,
+					u32 *pu32data_read)
+{
+	s16 ret_val = PRU_SUART_SUCCESS;
+	u8 *pu8src_addr = NULL;
+	u32 u32data_read = 0;
+	u32 u32data_len = 0;
+	u32 u32char_len = 0;
+	u32 offset = 0;
+	u32 pru_offset;
+	u16 ch_num;
+	u16 u16status = 0;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+		if (h_uart->uart_num <= 4) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			ch_num -= 8;
+		}
+		ch_num++;
+	} else if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	/* Get the data pos32er from channel RX data pointer */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_TXRXDATA_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &pu8src_addr, 4);
+
+	/* Reading data length from SUART channel register */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CONFIG2_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &u32data_len, 2);
+
+	/* read the character length */
+	u32char_len = u32data_len & PRU_SUART_CH_CONFIG2_BITPERCHAR_MASK;
+	u32char_len -= 2;	/* remove the START & STOP bit */
+
+	u32data_len &= PRU_SUART_CH_CONFIG2_DATALEN_MASK;
+	u32data_len = u32data_len >> PRU_SUART_CH_CONFIG2_DATALEN_SHIFT;
+	u32data_len++;
+
+	/* if the character length is greater than 8, then the size doubles */
+	if (u32char_len > 8)
+		u32data_len *= 2;
+
+	/* Check if the time-out had occured. If, yes, then we need to find the
+	 * number of bytes read from PRU. Else, we need to
+	 * read the requested bytes
+	 */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_TXRXSTATUS_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &u16status, 1);
+	if (CHN_TXRX_STATUS_TIMEOUT == (u16status & CHN_TXRX_STATUS_TIMEOUT)) {
+		/* determine the number of bytes read s32o the FIFO */
+		offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL)
+				 + PRU_SUART_CH_BYTESDONECNTR_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &u32data_read, 1);
+
+		/* if the character length is greater than 8,
+				then the size doubles */
+		if (u32char_len > 8)
+			u32data_read *= 2;
+
+/*
+ * the data corresponding is loaded in second
+ * half during the timeout
+ */
+		if (u32data_read > u32data_len) {
+			u32data_read -= u32data_len;
+			pu8src_addr += (u32data_len + 1);
+		}
+
+		pru_softuart_clr_rx_fifo(dev, h_uart);
+	} else {
+		u32data_read = u32data_len;
+/*
+ * if the bit is set, the data is in the first
+ * half of the FIFO else the data is in the second half
+ */
+		/* Determine the buffer index by reading FIFO_OddEven flag*/
+		if (u16status & CHN_TXRX_STATUS_CMPLT)
+			pu8src_addr += u32data_len;
+	}
+
+	/* we should be copying only max len given by the application */
+	if (u32data_read > s32max_len)
+		u32data_read = s32max_len;
+
+/* evaluate the virtual address of the FIFO address
+ * based on the physical addr
+ */
+	pu8src_addr = (u8 *)((u32) pu8src_addr -
+		(u32) suart_iomap.p_fifo_buff_phys_base +
+		(u32) suart_iomap.p_fifo_buff_virt_base);
+
+	/* Now we have both the data length and the source address. copy */
+	for (offset = 0; offset < u32data_read; offset++) {
+		*p_data_buffer++ = *pu8src_addr++;
+	}
+	*pu32data_read = u32data_read;
+	ret_val = PRU_SUART_SUCCESS;
+
+	return ret_val;
+}
+
+/*
+ * suart routine to disable the receive functionality.
+ * This routine stops the PRU from receiving on selected
+ * UART and also disables the McASP serializer corresponding
+ * to this UART Rx line.
+ */
+s16 pru_softuart_stop_receive(struct device *dev, suart_handle h_uart)
+{
+	u16 status = SUART_SUCCESS;
+	u32 offset;
+	u32 pru_offset;
+	u16 ch_num;
+	u16 u16status;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+
+		if (h_uart->uart_num <= 4) {
+			/* PRU0 */
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			/* PRU1 */
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			/* First 8 channel corresponds to PRU0 */
+			ch_num -= 8;
+		}
+		ch_num++;
+	} else if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	/* read the existing value of status flag */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_TXRXSTATUS_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &u16status, 1);
+
+	/* we need to clear the busy bit corresponding to receive channel */
+	u16status &= ~(CHN_TXRX_STATUS_RDY);
+	pruss_writeb(dev, offset, (u8 *) &u16status, 1);
+
+	/* get the serizlizer number being used for this Rx channel */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CTRL_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &u16status, 2);
+	u16status &= PRU_SUART_CH_CTRL_SR_MASK;
+	u16status = u16status >> PRU_SUART_CH_CTRL_SR_SHIFT;
+
+	/* we need to de-activate the serializer corresponding to this rx */
+	status = suart_asp_serializer_deactivate(u16status, &suart_iomap);
+
+	return status;
+}
+
+/*
+ * suart routine to get the tx status for a specific uart
+ */
+s16 pru_softuart_get_tx_status(struct device *dev, suart_handle h_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 status = SUART_SUCCESS;
+	u16 ch_num;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+
+		if (h_uart->uart_num <= 4) {
+			/* PRU0 */
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			/* PRU1 */
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			/* First 8 channel corresponds to PRU0 */
+			ch_num -= 8;
+		}
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+					PRU_SUART_CH_TXRXSTATUS_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &status, 1);
+	return status;
+}
+
+s16 pru_softuart_clr_tx_status(struct device *dev, suart_handle h_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 status = SUART_SUCCESS;
+	u16 ch_num;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	ch_num = h_uart->uart_num - 1;
+
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+
+		if (h_uart->uart_num <= 4) {
+			/* PRU0 */
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			/* PRU1 */
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			/* First 8 channel corresponds to PRU0 */
+			ch_num -= 8;
+		}
+	} else if (PRU0_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_TX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+					PRU_SUART_CH_TXRXSTATUS_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &status, 1);
+	status &= ~(0x2);
+	pruss_writeb(dev, offset, (u8 *) &status, 1);
+	return status;
+}
+
+/*
+ * suart routine to get the rx status for a specific uart
+ */
+s16 pru_softuart_get_rx_status(struct device *dev, suart_handle h_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 status = SUART_SUCCESS;
+	u16 ch_num;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+
+		if (h_uart->uart_num <= 4) {
+			/* PRU0 */
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			/* PRU1 */
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			/* First 8 channel corresponds to PRU0 */
+			ch_num -= 8;
+		}
+		ch_num++;
+	} else if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+				PRU_SUART_CH_TXRXSTATUS_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &status, 1);
+	return status;
+}
+
+s16 pru_softuart_clr_rx_fifo(struct device *dev, suart_handle h_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 status = SUART_SUCCESS;
+	u16 ch_num;
+	u16 reg_val;
+	u16 uart_num;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+	uart_num = h_uart->uart_num;
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num * SUART_NUM_OF_CHANNELS_PER_SUART)
+									 - 2;
+
+		if (h_uart->uart_num <= 4) {
+			/* PRU0 */
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			/* PRU1 */
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			/* First 8 channel corresponds to PRU0 */
+			ch_num -= 8;
+		}
+		ch_num++;
+	} else if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		uart_num = 0;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+		uart_num = 1;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	/* Service Request to PRU */
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+						PRU_SUART_CH_CTRL_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &reg_val, 2);
+	reg_val &= ~(PRU_SUART_CH_CTRL_MODE_MASK | PRU_SUART_CH_CTRL_SREQ_MASK);
+	reg_val |= (PRU_SUART_CH_CTRL_RX_MODE << PRU_SUART_CH_CTRL_MODE_SHIFT) |
+		(PRU_SUART_CH_CTRL_SREQ << PRU_SUART_CH_CTRL_SREQ_SHIFT);
+	pruss_writeb(dev, offset, (u8 *) &reg_val, 2);
+	suart_intr_setmask(dev, h_uart->uart_num, PRU_RX_INTR,
+						CHN_TXRX_IE_MASK_TIMEOUT);
+
+	/* generate ARM->PRU event */
+	suart_arm_to_pru_intr(dev, uart_num);
+
+	return status;
+}
+
+s16 pru_softuart_clr_rx_status(struct device *dev, suart_handle h_uart)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 status = SUART_SUCCESS;
+	u16 ch_num;
+
+	if (h_uart == NULL)
+		return PRU_SUART_ERR_HANDLE_INVALID;
+
+	ch_num = h_uart->uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+		(PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = (h_uart->uart_num *
+			SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+
+		if (h_uart->uart_num <= 4) {
+			/* PRU0 */
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		} else {
+			/* PRU1 */
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			/* First 8 channel corresponds to PRU0 */
+			ch_num -= 8;
+		}
+		ch_num++;
+	} else if (PRU0_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+	} else if (PRU1_MODE == PRU_MODE_RX_ONLY) {
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	offset = pru_offset + (ch_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_TXRXSTATUS_OFFSET;
+	pruss_readb(dev, offset, (u8 *) &status, 1);
+	status &= ~(0x3C);
+	pruss_writeb(dev, offset, (u8 *) &status, 1);
+	return status;
+}
+
+/*
+ * suart_s32r_status_read: Gets the Global Interrupt status register
+ * for the specified SUART.
+ * uart_num < 1 to 6 >
+ * txrx_flag < Indicates TX or RX s32errupt for the uart >
+ */
+s16 pru_softuart_get_isrstatus(struct device *dev, u16 uart_num, u16 *txrx_flag)
+{
+	u32 offset;
+	u32 u32intc_offset;
+	u32 ch_num = 0xFF;
+	u32 reg_val = 0;
+	u32 u32reg_val = 0;
+	u32 u32ISR_value = 0;
+	u32 u32ack_reg_val = 0;
+	u8 pru0_mode = PRU_MODE_INVALID;
+	u8 pru1_mode = PRU_MODE_INVALID;
+	u32 u32stat_inx_clr_regoffset = 0;
+
+	/* initialize the status & Flag to known value */
+	*txrx_flag = 0;
+
+	u32stat_inx_clr_regoffset = (u32) (PRUSS_INTC_STATIDXCLR & 0xFFFF);
+
+	/* Read PRU Interrupt Status Register from PRU */
+	u32intc_offset = (u32) (PRUSS_INTC_STATCLRINT1 & 0xFFFF);
+
+	pruss_readl(dev, u32intc_offset, (u32 *)&u32ISR_value, 1);
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+		|| (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* determine if the s32errupt occured current UART context */
+		u32reg_val = (PRU_SUART0_TX_EVT_BIT | PRU_SUART0_RX_EVT_BIT) <<
+				((uart_num - 1) * 2);
+
+		/* channel starts from 0 and uart instance starts from 1 */
+		ch_num = uart_num * 2 - 2;
+		if (uart_num <= 4)
+			pru0_mode = PRU_MODE_RX_TX_BOTH;
+		else
+			pru1_mode = PRU_MODE_RX_TX_BOTH;
+	} else {
+		ch_num = uart_num - 1;
+		if ((u32ISR_value & 0x03FC) != 0) {
+			u32reg_val = 0;
+
+			offset = PRU_SUART_PRU0_RX_TX_MODE;
+			pruss_readb(dev, offset, (u8 *) &pru0_mode, 1);
+			u32reg_val |= 1 << (uart_num + 1);
+			if (u32ISR_value & u32reg_val) {
+				/* acknowledge the s32errupt  */
+				u32ack_reg_val = ch_num + PRU_SUART0_TX_EVT;
+				pruss_writel(dev, u32stat_inx_clr_regoffset,
+					(u32 *)&u32ack_reg_val, 1);
+				*txrx_flag |= PRU_RX_INTR;
+			}
+		}
+		pruss_readl(dev, u32intc_offset, (u32 *)&u32ISR_value, 1);
+		if (u32ISR_value & 0x3FC00) {
+			u32reg_val = 0;
+			offset = PRU_SUART_PRU1_RX_TX_MODE;
+			pruss_readb(dev, offset, (u8 *) &pru1_mode, 1);
+			u32reg_val |= 1 << (uart_num + 9);
+			if (u32ISR_value & u32reg_val) {
+				/* acknowledge the s32errupt  */
+				u32ack_reg_val = ch_num + PRU_SUART4_TX_EVT;
+				pruss_writel(dev, u32stat_inx_clr_regoffset,
+					(u32 *)&u32ack_reg_val, 1);
+				*txrx_flag |= PRU_TX_INTR;
+			}
+		}
+	}
+	if (u32ISR_value & u32reg_val) {
+		if ((pru0_mode == PRU_MODE_RX_TX_BOTH)
+		    || (pru1_mode == PRU_MODE_RX_TX_BOTH)) {
+			/* Check if the s32errupt occured for Tx */
+			u32reg_val = PRU_SUART0_TX_EVT_BIT << ((uart_num - 1)
+									 * 2);
+			if (u32ISR_value & u32reg_val) {
+				/* s32erupt occured for TX */
+				*txrx_flag |= PRU_TX_INTR;
+				/* acknowledge the RX s32errupt  */
+				u32ack_reg_val = ch_num + PRU_SUART0_TX_EVT;
+				pruss_writel(dev, u32stat_inx_clr_regoffset,
+					(u32 *)&u32ack_reg_val, 1);
+			}
+
+			/* Check if the s32errupt occured for Rx */
+			u32reg_val = PRU_SUART0_RX_EVT_BIT<<((uart_num - 1)
+									 * 2);
+			if (u32ISR_value & u32reg_val) {
+				/* s32erupt occured for RX */
+				*txrx_flag |= PRU_RX_INTR;
+				ch_num += 1;
+
+				/* acknowledge the RX s32errupt  */
+				u32ack_reg_val = ch_num + PRU_SUART0_TX_EVT;
+				pruss_writel(dev, u32stat_inx_clr_regoffset,
+					(u32 *)&u32ack_reg_val, 1);
+			}
+		}
+		reg_val = SUART_SUCCESS;
+	}
+	return reg_val;
+}
+
+s32 pru_intr_clr_isrstatus(struct device *dev, u16 uart_num, u32 txrxmode)
+{
+	u32 offset;
+	u16 txrx_flag = 0;
+	u16 chn_num;
+
+	chn_num = uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		chn_num = (uart_num * SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+		if (uart_num <= 4) {
+			/* PRU0 */
+			offset = PRU_SUART_PRU0_ISR_OFFSET + 1;
+		} else {
+			/* PRU1 */
+			offset = PRU_SUART_PRU1_ISR_OFFSET + 1;
+			/* First 8 channel corresponds to PRU0 */
+			chn_num -= 8;
+		}
+		if (2 == txrxmode)
+			chn_num++;
+	} else if (PRU0_MODE == txrxmode) {
+		offset = PRU_SUART_PRU0_ISR_OFFSET + 1;
+	} else if (PRU1_MODE == txrxmode) {
+		offset = PRU_SUART_PRU1_ISR_OFFSET + 1;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+
+	pruss_readb(dev, offset, (u8 *) &txrx_flag, 1);
+	txrx_flag &= ~(0x2);
+	pruss_writeb(dev, offset, (u8 *) &txrx_flag, 1);
+
+	return 0;
+}
+
+s16 suart_arm_to_pru_intr(struct device *dev, u16 uart_num)
+{
+	u32 u32offset;
+	u32 u32value;
+	s16 s16retval;
+
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		if ((uart_num > 0) && (uart_num <= 4)) {
+			/* PRU0 SYS_EVT32 */
+			u32value = 0x20;
+		} else if ((uart_num > 4) && (uart_num <= 8)) {
+			/* PRU1 SYS_EVT33 */
+			u32value = 0x21;
+		} else {
+			return SUART_INVALID_UART_NUM;
+		}
+	}
+
+	if ((PRU0_MODE == PRU_MODE_RX_ONLY) || (PRU1_MODE == PRU_MODE_RX_ONLY)
+	    || (PRU0_MODE == PRU_MODE_TX_ONLY)
+	    || (PRU1_MODE == PRU_MODE_TX_ONLY)) {
+		if (uart_num == PRUSS_NUM0) {
+			/* PRU0 SYS_EVT32 */
+			u32value = 0x20;
+		}
+
+		if (uart_num == PRUSS_NUM1) {
+			/* PRU0 SYS_EVT33 */
+			u32value = 0x21;
+		}
+	}
+
+	u32offset = (u32) (PRUSS_INTC_STATIDXSET & 0xFFFF);
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (s16retval == -1)
+		return -1;
+	return 0;
+}
+
+s16 arm_to_pru_intr_init(struct device *dev)
+{
+	u32 u32offset;
+	u32 u32value;
+	u32 int_offset;
+	s16 s16retval = -1;
+#if 0
+	/* Set the MCASP Event to PRU0 as Edge Triggered */
+	u32offset = (u32)(PRU_INTC_TYPE0 & 0xFFFF);
+	u32value = 0x80000000;
+	s16retval =
+	    pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (s16retval == -1)
+		return -1;
+
+#endif
+	/* Clear all the host s32errupts */
+	for (int_offset = 0; int_offset <= PRUSS_INTC_HOSTINTLVL_MAX;
+							int_offset++) {
+		u32offset = (u32) (PRUSS_INTC_HSTINTENIDXCLR & 0xFFFF);
+		u32value = int_offset;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (s16retval == -1)
+			return -1;
+	}
+
+	/* Enable the global s32errupt */
+	u32offset = (u32) (PRUSS_INTC_GLBLEN & 0xFFFF);
+	u32value = 0x1;
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (s16retval == -1)
+		return -1;
+
+	/* Enable the Host s32errupts for all host channels */
+	for (int_offset = 0; int_offset <= PRUSS_INTC_HOSTINTLVL_MAX;
+							 int_offset++) {
+		u32offset = (u32) (PRUSS_INTC_HSTINTENIDXSET & 0xFFFF);
+		u32value = int_offset;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (s16retval == -1)
+			return -1;
+	}
+
+	u32offset = (u32) (PRUSS_INTC_HOSTMAP0 & 0xFFFF);
+	u32value = PRU_INTC_CHAN_123_HOST;
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (-1 == s16retval)
+		return -1;
+
+	u32offset = (u32) (PRUSS_INTC_HOSTMAP1 & 0xFFFF);
+	u32value = PRU_INTC_CHAN_4567_HOST;
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (-1 == s16retval)
+		return -1;
+	u32offset = (u32) (PRUSS_INTC_HOSTMAP2 & 0xFFFF);
+	u32value = PRU_INTC_CHAN_89_HOST;
+	s16retval =
+	    pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (-1 == s16retval)
+		return -1;
+
+	/* Set the channel for System s32rrupts
+	 * MAP Channel 0 to SYS_EVT31
+	 */
+	u32offset =	(u32) (PRUSS_INTC_CHANMAP7 & 0xFFFF);
+	u32value = PRU_INTC_CHAN_0_SYSEVT_31;
+	s16retval =
+	    pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (-1 == s16retval)
+		return -1;
+
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		u32offset = (u32) (PRUSS_INTC_CHANMAP8 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_12_SYSEVT;
+		s16retval =
+		    pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 3 to SYS_EVT36   SUART1-Tx
+		 * MAP channel 3 to SYS_EVT37   SUART1-Rx
+		 * MAP channel 4 to SYS_EVT38   SUART2-Tx
+		 * MAP channel 4 to SYS_EVT39   SUART2-Rx
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP9 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_34_SYSEVT_36_39;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 5 to SYS_EVT40   SUART3-Tx
+		 * MAP channel 5 to SYS_EVT41   SUART3-Rx
+		 * MAP channel 6 to SYS_EVT42   SUART4-Tx
+		 * MAP channel 6 to SYS_EVT43   SUART4-Rx
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP10 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_56_SYSEVT_40_43;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 7 to SYS_EVT44   SUART5-Tx
+		 * MAP channel 7 to SYS_EVT45   SUART5-Rx
+		 * MAP channel 8 to SYS_EVT46   SUART6-Tx
+		 * MAP channel 8 to SYS_EVT47   SUART6-Rx
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP11 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_78_SYSEVT_44_47;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 9 to SYS_EVT48   SUART7-Tx
+		 * MAP channel 9 to SYS_EVT49   SUART7-Rx
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP12 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_9_SYSEVT_48_49;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+	}
+	if ((PRU0_MODE == PRU_MODE_RX_ONLY) || (PRU1_MODE == PRU_MODE_RX_ONLY)
+	    || (PRU0_MODE == PRU_MODE_TX_ONLY)
+	    || (PRU1_MODE == PRU_MODE_TX_ONLY)) {
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 0 to SYS_EVT32
+		 * MAP channel 1 to SYS_EVT33
+		 * MAP channel 2 to SYS_EVT34  SUART0
+		 * MAP channel 3 to SYS_EVT35  SUART1
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP8 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_0123_SYSEVT_32_35;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 4 to SYS_EVT36   SUART2
+		 * MAP channel 5 to SYS_EVT37   SUART3
+		 * MAP channel 6 to SYS_EVT38   SUART4
+		 * MAP channel 7 to SYS_EVT39   SUART5
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP9 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_4567_SYSEVT_36_39;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 8 to SYS_EVT40   SUART6
+		 * MAP channel 9 to SYS_EVT41   SUART7
+		 * MAP channel 2 to SYS_EVT42   SUART0
+		 * MAP channel 3 to SYS_EVT43   SUART1
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP10 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_8923_SYSEVT_40_43;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 4 to SYS_EVT44   SUART2
+		 * MAP channel 5 to SYS_EVT45   SUART3
+		 * MAP channel 6 to SYS_EVT46   SUART4
+		 * MAP channel 7 to SYS_EVT47   SUART5
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP11 & 0xFFFF);
+		u32value = PRU_INTC_CHAN_4567_SYSEVT_44_47;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+
+		/* Sets the channel for the system s32errupt
+		 * MAP channel 8 to SYS_EVT48   SUART6
+		 * MAP channel 9 to SYS_EVT49   SUART7
+		 */
+		u32offset = (u32) (PRUSS_INTC_CHANMAP12 & 0xFFFF);
+		u32value = 0x00010908;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (-1 == s16retval)
+			return -1;
+	}
+
+	/* Clear required set of system events
+	* and enable them using indexed register
+	*/
+	for (int_offset = 0; int_offset < 18; int_offset++) {
+		u32offset = (u32) (PRUSS_INTC_STATIDXCLR & 0xFFFF);
+		u32value = 32 + int_offset;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (s16retval == -1)
+			return -1;
+
+	}
+	/* enable only the HOST to PRU s32errupts and let the PRU to Host events
+	 * enabled by the separate API on demand basis.
+	 */
+	u32offset = (u32) (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 31;
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (s16retval == -1)
+		return -1;
+
+	u32offset = (u32) (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 32;
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (s16retval == -1)
+		return -1;
+	u32offset = (u32) (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 33;
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (s16retval == -1)
+		return -1;
+	u32offset = (u32) (PRUSS_INTC_ENIDXSET & 0xFFFF);
+	u32value = 50;
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (s16retval == -1)
+		return -1;
+
+	/* Enable the global s32errupt */
+	u32offset = (u32) (PRUSS_INTC_GLBLEN & 0xFFFF);
+	u32value = 0x1;
+	s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+	if (s16retval == -1)
+		return -1;
+
+	/* Enable the Host s32errupts for all host channels */
+	for (int_offset = 0; int_offset <= PRUSS_INTC_HOSTINTLVL_MAX;
+							int_offset++) {
+		u32offset = (u32) (PRUSS_INTC_HSTINTENIDXSET & 0xFFFF);
+		u32value = int_offset;
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (s16retval == -1)
+			return -1;
+	}
+
+	return 0;
+}
+
+s32 suart_pru_to_host_intr_enable(struct device *dev, u16 uart_num,
+		u32 txrxmode, s32 s32_flag)
+{
+	s32 ret_val = 0;
+	u32 u32offset;
+	u32 chn_num;
+	u32 u32value;
+	s16 s16retval = 0;
+
+	if (uart_num > 8)
+		return SUART_INVALID_UART_NUM;
+
+	chn_num = uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH) ||
+		(PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		chn_num = (uart_num * 2) - 2;
+		if (2 == txrxmode)	/* Rx mode */
+			chn_num++;
+		u32value = 34 + chn_num;
+	} else if ((PRU_MODE_RX_ONLY == txrxmode)
+		&& (PRU0_MODE == PRU_MODE_RX_ONLY))
+		u32value = 34 + chn_num;
+	else if ((PRU_MODE_RX_ONLY == txrxmode)
+		&& (PRU1_MODE == PRU_MODE_RX_ONLY))
+		u32value = 42 + chn_num;
+	else if ((PRU_MODE_TX_ONLY == txrxmode)
+		&& (PRU0_MODE == PRU_MODE_TX_ONLY))
+		u32value = 34 + chn_num;
+	else if ((PRU_MODE_TX_ONLY == txrxmode)
+		&& (PRU1_MODE == PRU_MODE_TX_ONLY))
+		u32value = 42 + chn_num;
+	else
+		return -1;
+
+	if (SUART_TRUE == s32_flag) {
+		u32offset = (u32) (PRUSS_INTC_ENIDXSET & 0xFFFF);
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (s16retval == -1)
+			return -1;
+	} else {
+		u32offset = (u32) (PRUSS_INTC_ENIDXCLR & 0xFFFF);
+		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
+		if (s16retval == -1)
+			return -1;
+	}
+	return ret_val;
+}
+
+s32 suart_intr_setmask(struct device *dev, u16 uart_num,
+		u32 txrxmode, u32 s32rmask)
+{
+	u32 offset;
+	u32 pru_offset;
+	u32 txrx_flag;
+	u32 regval = 0;
+	u32 chn_num;
+
+	chn_num = uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		chn_num = (uart_num * SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+
+		if ((uart_num > 0) && (uart_num <= 4)) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+			offset = PRU_SUART_PRU0_IMR_OFFSET;
+		} else if ((uart_num > 4) && (uart_num <= 8)) {
+			offset = PRU_SUART_PRU1_IMR_OFFSET;
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			chn_num -= 8;
+		} else {
+			return SUART_INVALID_UART_NUM;
+		}
+		if (2 == txrxmode) {	/* rx mode */
+			chn_num++;
+		}
+	} else if (PRU0_MODE == txrxmode) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		offset = PRU_SUART_PRU0_IMR_OFFSET;
+	} else if (PRU1_MODE == txrxmode) {
+		offset = PRU_SUART_PRU1_IMR_OFFSET;
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+	regval = 1 << chn_num;
+	if (CHN_TXRX_IE_MASK_CMPLT == (s32rmask & CHN_TXRX_IE_MASK_CMPLT)) {
+		pruss_readb(dev, offset, (u8 *) &txrx_flag, 2);
+		txrx_flag &= ~(regval);
+		txrx_flag |= regval;
+		pruss_writeb(dev, offset, (u8 *) &txrx_flag, 2);
+	}
+	if ((s32rmask & SUART_GBL_INTR_ERR_MASK) ==
+			SUART_GBL_INTR_ERR_MASK) {
+		regval = 0;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= ~(SUART_GBL_INTR_ERR_MASK);
+		regval |= (SUART_GBL_INTR_ERR_MASK);
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+
+	}
+	/* Break Indicator Interrupt Masked */
+	if ((s32rmask & CHN_TXRX_IE_MASK_FE) == CHN_TXRX_IE_MASK_FE) {
+		regval = 0;
+		offset = pru_offset +
+			(chn_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= ~(CHN_TXRX_IE_MASK_FE);
+		regval |= CHN_TXRX_IE_MASK_FE;
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+	}
+	/* Framing Error Interrupt Masked */
+	if (CHN_TXRX_IE_MASK_BI == (s32rmask & CHN_TXRX_IE_MASK_BI)) {
+		regval = 0;
+		offset = pru_offset +
+			(chn_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= ~(CHN_TXRX_IE_MASK_BI);
+		regval |= CHN_TXRX_IE_MASK_BI;
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+	}
+	/* Timeout error Interrupt Masked */
+	if (CHN_TXRX_IE_MASK_TIMEOUT ==
+			(s32rmask & CHN_TXRX_IE_MASK_TIMEOUT)) {
+		regval = 0;
+		offset = pru_offset +
+			(chn_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= ~(CHN_TXRX_IE_MASK_TIMEOUT);
+		regval |= CHN_TXRX_IE_MASK_TIMEOUT;
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+	}
+	return 0;
+}
+
+s32 suart_intr_clrmask(struct device *dev, u16 uart_num,
+		u32 txrxmode, u32 s32rmask)
+{
+	u32 offset;
+	u32 pru_offset;
+	u16 txrx_flag;
+	u16 regval = 0;
+	u16 chn_num;
+
+	chn_num = uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		chn_num = (uart_num * SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+		if ((uart_num > 0) && (uart_num <= 4)) {
+			pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+			offset = PRU_SUART_PRU0_IMR_OFFSET;
+		} else if ((uart_num > 4) && (uart_num <= 8)) {
+			/* PRU1 */
+			offset = PRU_SUART_PRU1_IMR_OFFSET;
+			pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+			/* First 8 channel corresponds to PRU0 */
+			chn_num -= 8;
+		} else {
+			return SUART_INVALID_UART_NUM;
+		}
+		if (2 == txrxmode) {	/* rx mode */
+			chn_num++;
+		}
+	} else if (PRU0_MODE == txrxmode) {
+		pru_offset = PRU_SUART_PRU0_CH0_OFFSET;
+		offset = PRU_SUART_PRU0_IMR_OFFSET;
+	} else if (PRU1_MODE == txrxmode) {
+		offset = PRU_SUART_PRU1_IMR_OFFSET;
+		pru_offset = PRU_SUART_PRU1_CH0_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+	regval = 1 << chn_num;
+	if (CHN_TXRX_IE_MASK_CMPLT == (s32rmask & CHN_TXRX_IE_MASK_CMPLT)) {
+		pruss_readb(dev, offset, (u8 *) &txrx_flag, 2);
+		txrx_flag &= ~(regval);
+		pruss_writeb(dev, offset, (u8 *) &txrx_flag, 2);
+	}
+
+	if ((s32rmask & SUART_GBL_INTR_ERR_MASK) == SUART_GBL_INTR_ERR_MASK) {
+		regval = 0;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= ~(SUART_GBL_INTR_ERR_MASK);
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+
+	}
+	/* Break Indicator Interrupt Masked */
+	if ((s32rmask & CHN_TXRX_IE_MASK_FE) == CHN_TXRX_IE_MASK_FE) {
+		regval = 0;
+		offset = pru_offset +
+			(chn_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= ~(CHN_TXRX_IE_MASK_FE);
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+	}
+	/* Framing Error Interrupt Masked */
+	if (CHN_TXRX_IE_MASK_BI == (s32rmask & CHN_TXRX_IE_MASK_BI)) {
+		regval = 0;
+		offset = pru_offset +
+			(chn_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= ~(CHN_TXRX_IE_MASK_BI);
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+	}
+
+	/* Timeout error Interrupt Masked */
+	if (CHN_TXRX_IE_MASK_TIMEOUT ==
+			(s32rmask & CHN_TXRX_IE_MASK_TIMEOUT)) {
+		regval = 0;
+		offset = pru_offset +
+			(chn_num * SUART_NUM_OF_BYTES_PER_CHANNEL) +
+			PRU_SUART_CH_CONFIG1_OFFSET;
+		pruss_readb(dev, offset, (u8 *) &regval, 2);
+		regval &= ~(CHN_TXRX_IE_MASK_TIMEOUT);
+		pruss_writeb(dev, offset, (u8 *) &regval, 2);
+	}
+	return 0;
+}
+
+s32 suart_intr_getmask(struct device *dev, u16 uart_num, u32 txrxmode,
+			u32 s32rmask)
+{
+	u16 chn_num;
+	u32 offset;
+	u16 txrx_flag;
+	u16 regval = 1;
+
+	chn_num = uart_num - 1;
+	if ((PRU0_MODE == PRU_MODE_RX_TX_BOTH)
+	    || (PRU1_MODE == PRU_MODE_RX_TX_BOTH)) {
+		/* channel starts from 0 and uart instance starts from 1 */
+		chn_num = (uart_num * SUART_NUM_OF_CHANNELS_PER_SUART) - 2;
+
+		if ((uart_num > 0) && (uart_num <= 4)) {
+
+			offset = PRU_SUART_PRU0_IMR_OFFSET;
+		} else if ((uart_num > 4) && (uart_num <= 8)) {
+			/* PRU1 */
+			offset = PRU_SUART_PRU1_IMR_OFFSET;
+			/* First 8 channel corresponds to PRU0 */
+			chn_num -= 8;
+		} else {
+			return SUART_INVALID_UART_NUM;
+		}
+
+		if (2 == txrxmode) {	/* rx mode */
+			chn_num++;
+		}
+	} else if (PRU0_MODE == txrxmode) {
+		offset = PRU_SUART_PRU0_IMR_OFFSET;
+	} else if (PRU1_MODE == txrxmode) {
+		offset = PRU_SUART_PRU1_IMR_OFFSET;
+	} else {
+		return PRU_MODE_INVALID;
+	}
+	regval = regval << chn_num;
+	pruss_readb(dev, offset, (u8 *) &txrx_flag, 2);
+	txrx_flag &= regval;
+	if (0 == s32rmask) {
+		if (txrx_flag == 0)
+			return 1;
+	}
+	if (1 == s32rmask) {
+		if (txrx_flag == regval)
+			return 1;
+	}
+	return 0;
+}
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_api.h b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.h
new file mode 100644
index 0000000..4ce5621
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.h
@@ -0,0 +1,345 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
+ *
+ * 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 _SUART_API_H_
+#define _SUART_API_H_
+
+#include <linux/types.h>
+#include <linux/bitops.h>
+#include <linux/mfd/pruss/da8xx_pru.h>
+
+#define SINGLE_PRU				0
+#define BOTH_PRU				1
+#define PRU_ACTIVE				BOTH_PRU
+
+#define SUART_NUM_OF_CHANNELS_PER_SUART		2
+#define SUART_NUM_OF_BYTES_PER_CHANNEL		16
+
+#define SUART_PASS				0
+#define SUART_SUCCESS				0
+#define SUART_FAIL				1
+#define SUART_FALSE				0
+#define SUART_TRUE				1
+
+#define PRU_TX_INTR				1
+#define PRU_RX_INTR				2
+
+#define CHN_TXRX_STATUS_TIMEOUT			BIT(6)
+#define CHN_TXRX_STATUS_BI			BIT(5)
+#define CHN_TXRX_STATUS_FE			BIT(4)
+#define CHN_TXRX_STATUS_UNERR			BIT(3)
+#define CHN_TXRX_STATUS_OVRNERR			BIT(3)
+#define CHN_TXRX_STATUS_ERR			BIT(2)
+#define CHN_TXRX_STATUS_CMPLT			BIT(1)
+#define CHN_TXRX_STATUS_RDY			BIT(0)
+
+#define CHN_TXRX_IE_MASK_TIMEOUT		BIT(14)
+#define CHN_TXRX_IE_MASK_BI			BIT(13)
+#define CHN_TXRX_IE_MASK_FE			BIT(12)
+#define CHN_TXRX_IE_MASK_CMPLT			BIT(1)
+
+#define SUART_GBL_INTR_ERR_MASK			BIT(9)
+#define SUART_PRU_ID_MASK			0xFF
+
+#define SUART_FIFO_LEN				15
+#define SUART_8X_OVRSMPL			1
+#define SUART_16X_OVRSMPL			2
+#define SUART_DEFAULT_OVRSMPL			SUART_8X_OVRSMPL
+
+#if (SUART_DEFAULT_OVRSMPL == SUART_16X_OVRSMPL)
+#define SUART_DEFAULT_BAUD			57600
+#else
+#define SUART_DEFAULT_BAUD			115200
+#endif
+
+#define PRU_MODE_INVALID			0x00
+#define PRU_MODE_TX_ONLY			0x1
+#define PRU_MODE_RX_ONLY			0x2
+#define PRU_MODE_RX_TX_BOTH			0x3
+
+#if (PRU_ACTIVE == BOTH_PRU)
+#define PRU0_MODE				PRU_MODE_RX_ONLY
+#define PRU1_MODE				PRU_MODE_TX_ONLY
+#elif (PRU_ACTIVE ==  SINGLE_PRU)
+#define PRU0_MODE				PRU_MODE_RX_TX_BOTH
+#define PRU1_MODE				PRU_MODE_INVALID
+#else
+#define PRU0_MODE				PRU_MODE_INVALID
+#define PRU1_MODE				PRU_MODE_INVALID
+#endif
+
+#define MCASP_XBUF_BASE_ADDR			(0x01d00200)
+#define MCASP_RBUF_BASE_ADDR			(0x01d00280)
+#define MCASP_SRCTL_BASE_ADDR			(0x01d00180)
+
+#define MCASP_SRCTL_TX_MODE			(0x000D)
+#define MCASP_SRCTL_RX_MODE			(0x000E)
+
+/* Since only PRU0 can work as RX */
+#define RX_DEFAULT_DATA_DUMP_ADDR		(0x00001FC)
+#define PRU_NUM_OF_CHANNELS			(16)
+
+#define	PRU_SUART_UART1		(1u)
+#define	PRU_SUART_UART2		(2u)
+#define	PRU_SUART_UART3		(3u)
+#define	PRU_SUART_UART4		(4u)
+#define	PRU_SUART_UART5		(5u)
+#define	PRU_SUART_UART6		(6u)
+#define	PRU_SUART_UART7		(7u)
+#define PRU_SUART_UART8		(8u)
+
+#define PRU_SUART_UARTx_INVALID	(9u)
+
+#define PRU_SUART_HALF_TX	(1u)
+#define PRU_SUART_HALF_RX			(2u)
+#define PRU_SUART_HALF_TX_DISABLED		(4u)
+#define PRU_SUART_HALF_RX_DISABLED		(8u)
+
+
+/*
+ *  This enum is used to specify the direction of the channel in UART
+ */
+typedef enum {
+	SUART_CHN_TX = 1,
+	SUART_CHN_RX = 2
+} SUART_CHN_DIR;
+
+/*
+ *  This enum is used to specify the state of the channel in UART. It
+ *  is either enabled or disabled.
+ */
+typedef enum {
+	SUART_CHN_DISABLED = 0,
+	SUART_CHN_ENABLED = 1
+} SUART_CHN_STATE;
+
+typedef enum {
+	ePRU_SUART_DATA_BITS6 = 8,
+	ePRU_SUART_DATA_BITS7,
+	ePRU_SUART_DATA_BITS8,
+	ePRU_SUART_DATA_BITS9,
+	ePRU_SUART_DATA_BITS10,
+	ePRU_SUART_DATA_BITS11,
+	ePRU_SUART_DATA_BITS12
+	} SUART_EN_BITSPERCHAR;
+
+typedef enum {
+	ePRU_SUART_NUM_1 = 1,
+	ePRU_SUART_NUM_2,
+	ePRU_SUART_NUM_3,
+	ePRU_SUART_NUM_4,
+	ePRU_SUART_NUM_5,
+	ePRU_SUART_NUM_6,
+	ePRU_SUART_NUM_7,
+	ePRU_SUART_NUM_8
+} SUART_EN_UARTNUM;
+
+typedef enum {
+	ePRU_SUART_HALF_TX = 1,
+	ePRU_SUART_HALF_RX,
+	ePRU_SUART_FULL_TX_RX
+} SUART_EN_UARTTYPE;
+
+typedef enum {
+	ePRU_SUART_TX_CH0 = 0,
+	ePRU_SUART_TX_CH1,
+	ePRU_SUART_TX_CH2,
+	ePRU_SUART_TX_CH3,
+	ePRU_SUART_TX_CH4,
+	ePRU_SUART_TX_CH5,
+	ePRU_SUART_TX_CH6,
+	ePRU_SUART_TX_CH7
+} SUART_EN_TXCHANNEL;
+
+typedef enum {
+	ePRU_SUART_RX_CH0 = 0,
+	ePRU_SUART_RX_CH1,
+	ePRU_SUART_RX_CH2,
+	ePRU_SUART_RX_CH3,
+	ePRU_SUART_RX_CH4,
+	ePRU_SUART_RX_CH5,
+	ePRU_SUART_RX_CH6,
+	ePRU_SUART_RX_CH7
+} SUART_EN_RXCHANNEL;
+
+typedef enum {
+	ePRU_SUART_UART_FREE = 0,
+	ePRU_SUART_UART_IN_USE
+} SUART_EN_UART_STATUS;
+
+typedef struct {
+	u16 mode:2;
+	u16 service_req:1;
+	u16 asp_id:2;
+	u16 reserved1:3;
+	u16 serializer_num:4;
+	u16 reserved2:4;
+
+} pru_suart_chn_cntrl;
+
+typedef struct {
+	u16 presacler:10;
+	u16 over_sampling:2;
+	u16 framing_mask:1;
+	u16 break_mask:1;
+	u16 timeout_mask:1;
+	u16 reserved:1;
+} pru_suart_cnh_config1;
+
+typedef struct {
+	u16 bits_per_char:4;
+	u16 reserved1:4;
+	u16 data_len:4;
+	u16 reserved:4;
+} pru_suart_chn_config2;
+
+typedef struct {
+	u16 txrx_ready:1;
+	u16 txrx_complete:1;
+	u16 txrx_error:1;
+	u16 txrx_underrun:1;
+	u16 framing_error:1;
+	u16 break_error:1;
+	u16 timeout_error:1;
+	u16 reserved:8;
+	u16 chn_state:1;
+} pru_suart_chn_status;
+
+typedef struct {
+	pru_suart_chn_cntrl ch_ctrl;
+	pru_suart_cnh_config1 ch_config1;
+	pru_suart_chn_config2 ch_config2;
+	pru_suart_chn_status ch_txrx_status;
+	u32 ch_txrx_data;
+	u32 reserved1;
+} pru_suart_regs, *pru_suart_regs_ovly;
+
+typedef struct {
+	u32 asp_xsrctl_base;
+	u32 asp_xbuf_base;
+	u16 buff_addr;
+	u8 buff_size;
+	u8 bits_loaded;
+} pru_suart_tx_cntx_priv, *ppru_suart_tx_cntx_priv;
+
+typedef struct {
+	u32 asp_rbuf_base;
+	u32 asp_rsrctl_base;
+	u32 reserved1;
+	u32 reserved2;
+	u32 reserved3;
+	u32 reserved4;
+} pru_suart_rx_cntx_priv, *ppru_suart_rx_cntx_priv;
+
+typedef struct {
+	u8  tx_serializer;
+	u8  rx_serializer;
+	u16 tx_clk_divisor;
+	u16 rx_clk_divisor;
+	u8  tx_bits_per_char;
+	u8  rx_bits_per_char;
+	u8  oversampling;
+	u8  bi_inter_mask;
+	u8  fe_intr_mask;
+} suart_config;
+
+typedef struct {
+	u16 uart_num;
+	u16 uart_type;
+	u16 uart_tx_channel;
+	u16 uart_rx_channel;
+	u16 uart_status;
+} suart_struct_handle, *suart_handle;
+
+typedef struct {
+	void *mcasp_io_addr;
+	void *p_fifo_buff_phys_base;
+	void *p_fifo_buff_virt_base;
+	u32  pru_clk_freq;
+} pruss_suart_iomap;
+
+s16 pru_softuart_init(struct device *dev, u32 tx_baud_value,
+			u32 rx_baud_value, u32 oversampling,
+			u8 *pru_suart_emu_code, u32 fw_size,
+			pruss_suart_iomap *pruss_ioaddr);
+
+s16 pru_softuart_open(suart_handle h_suart);
+
+s16 pru_softuart_close(suart_handle h_uart);
+
+s16 pru_softuart_setbaud(struct device *dev, suart_handle h_uart,
+			u16 tx_clk_divisor, u16 rx_clk_divisor);
+
+s16 pru_softuart_setdatabits(struct device *dev, suart_handle h_uart,
+			u16 tx_data_bits, u16 rx_data_bits);
+
+s16 pru_softuart_setconfig(struct device *dev, suart_handle h_uart,
+			suart_config *config_uart);
+
+s16 pru_softuart_getconfig(struct device *dev, suart_handle h_uart,
+			suart_config *config_uart);
+
+s32 pru_softuart_pending_tx_request(struct device *dev);
+
+s16 pru_softuart_write(struct device *dev, suart_handle h_uart,
+			u32 *pt_tx_data_buf, u16 data_len);
+
+s16 pru_softuart_read(struct device *dev, suart_handle h_uart,
+			u32 *pt_data_buf, u16 data_len);
+
+s32 suart_intr_clrmask(struct device *dev, u16 uart_num, u32 txrxmode,
+			u32 intrmask);
+
+s16 pru_softuart_clr_tx_status(struct device *dev, suart_handle h_uart);
+
+s16 pru_softuart_get_tx_status(struct device *dev, suart_handle h_uart);
+
+s16 pru_softuart_clr_rx_status(struct device *dev, suart_handle h_uart);
+
+s16 pru_softuart_get_rx_status(struct device *dev, suart_handle h_uart);
+
+s16 pru_softuart_get_isrstatus(struct device *dev, u16 uart_num,
+			u16 *txrx_flag);
+
+s32 pru_intr_clr_isrstatus(struct device *dev, u16 uart_num, u32 txrxmode);
+
+s32 suart_intr_getmask(struct device *dev, u16 uart_num, u32 txrxmode,
+			u32 intrmask);
+
+s32 suart_intr_setmask(struct device *dev, u16 uart_num,
+			u32 txrxmode, u32 intrmask);
+
+s16 pru_softuart_get_tx_data_len(struct device *dev, suart_handle h_uart);
+
+s16 pru_softuart_get_rx_data_len(struct device *dev, suart_handle h_uart);
+
+s16 suart_arm_to_pru_intr(struct device *dev, u16 uart_num);
+
+s16 arm_to_pru_intr_init(struct device *dev);
+
+s16 pru_softuart_deinit(struct device *dev);
+
+s16 pru_softuart_clr_rx_fifo(struct device *dev, suart_handle h_uart);
+
+s16 pru_softuart_read_data(struct device *dev, suart_handle h_uart,
+			u8 *p_data_buffer, s32 s32_max_len,
+			u32 *pu32data_read);
+
+s16 pru_softuart_stop_receive(struct device *dev, suart_handle h_uart);
+
+s32 suart_pru_to_host_intr_enable(struct device *dev, u16 uart_num,
+			u32 txrxmode, s32 s32flag);
+
+void pru_set_fifo_timeout(struct device *dev, s16 timeout);
+#endif
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_board.h b/drivers/tty/serial/da8xx_pruss/pruss_suart_board.h
new file mode 100644
index 0000000..58cc9e4
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_board.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: subhasish at mistralsolutions.com
+ *
+ * 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 _OMAPL_SUART_BOARD_H_
+#define _OMAPL_SUART_BOARD_H_
+
+#define PRU_SUART0_CONFIG_DUPLEX	(PRU_SUART_HALF_TX_DISABLED | \
+					PRU_SUART_HALF_RX_DISABLED)
+#define PRU_SUART0_CONFIG_RX_SER	(PRU_SUART_SERIALIZER_NONE)
+#define PRU_SUART0_CONFIG_TX_SER	(PRU_SUART_SERIALIZER_NONE)
+
+#define PRU_SUART1_CONFIG_DUPLEX	(PRU_SUART_HALF_TX | \
+					PRU_SUART_HALF_RX)
+#define PRU_SUART1_CONFIG_RX_SER	(PRU_SUART_SERIALIZER_7)
+#define PRU_SUART1_CONFIG_TX_SER	(PRU_SUART_SERIALIZER_8)
+
+#define PRU_SUART2_CONFIG_DUPLEX	(PRU_SUART_HALF_TX | \
+					PRU_SUART_HALF_RX)
+#define PRU_SUART2_CONFIG_RX_SER	(PRU_SUART_SERIALIZER_9)
+#define PRU_SUART2_CONFIG_TX_SER	(PRU_SUART_SERIALIZER_10)
+
+#define PRU_SUART3_CONFIG_DUPLEX	(PRU_SUART_HALF_TX_DISABLED | \
+					PRU_SUART_HALF_RX_DISABLED)
+#define PRU_SUART3_CONFIG_RX_SER	(PRU_SUART_SERIALIZER_NONE)
+#define PRU_SUART3_CONFIG_TX_SER	(PRU_SUART_SERIALIZER_NONE)
+
+#define PRU_SUART4_CONFIG_DUPLEX	(PRU_SUART_HALF_TX_DISABLED | \
+					PRU_SUART_HALF_RX_DISABLED)
+#define PRU_SUART4_CONFIG_RX_SER	(PRU_SUART_SERIALIZER_NONE)
+#define PRU_SUART4_CONFIG_TX_SER	(PRU_SUART_SERIALIZER_NONE)
+
+#define PRU_SUART5_CONFIG_DUPLEX	(PRU_SUART_HALF_TX_DISABLED | \
+					PRU_SUART_HALF_RX_DISABLED)
+#define PRU_SUART5_CONFIG_RX_SER	(PRU_SUART_SERIALIZER_NONE)
+#define PRU_SUART5_CONFIG_TX_SER	(PRU_SUART_SERIALIZER_NONE)
+
+#define PRU_SUART6_CONFIG_DUPLEX	(PRU_SUART_HALF_TX_DISABLED | \
+					PRU_SUART_HALF_RX_DISABLED)
+#define PRU_SUART6_CONFIG_RX_SER	(PRU_SUART_SERIALIZER_NONE)
+#define PRU_SUART6_CONFIG_TX_SER	(PRU_SUART_SERIALIZER_NONE)
+
+#define PRU_SUART7_CONFIG_DUPLEX	(PRU_SUART_HALF_TX_DISABLED | \
+					PRU_SUART_HALF_RX_DISABLED)
+#define PRU_SUART7_CONFIG_RX_SER	(PRU_SUART_SERIALIZER_NONE)
+#define PRU_SUART7_CONFIG_TX_SER	(PRU_SUART_SERIALIZER_NONE)
+
+#endif				/* End of _OMAPL_SUART_BOARD_H_ */
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_err.h b/drivers/tty/serial/da8xx_pruss/pruss_suart_err.h
new file mode 100644
index 0000000..dd94f4e
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_err.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: jitendra at mistralsolutions.com
+ *
+ * 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 _SUART_ERR_H_
+#define _SUART_ERR_H_
+
+#define PRU_SUART_SUCCESS	(0u)
+#define PRU_SUART_FAILURE	(-1)
+
+#define PRU_SUART_ERR_DEVICE_NOT_OPEN	(1u)
+#define PRU_SUART_ERR_UARTS_INIT_FAIL	(2u)
+#define PRU_SUART_ERR_UARTS_RESET_FAIL	(3u)
+#define PRU_SUART_ERR_HANDLE_INVALID	(4u)
+#define PRU_SUART_ERR_PARAMETER_INVALID	(5u)
+
+#define PRU_SUART_ERR_TX		(6u)
+#define PRU_SUART_TX_COMPLETE		(7u)
+#define PRU_SUART_TX_BUSY		(8u)
+#define PRU_SUART_TX_UNDERRUN		(9u)
+
+#define PRU_SUART_ERR_RX		(10u)
+#define PRU_SUART_RX_COMPLETE		(11u)
+#define PRU_SUART_RX_BUSY		(12u)
+#define PRU_SUART_RX_OVERRUN		(13u)
+
+/* API Specific Errors */
+#define SUART_INVALID_TX_BAUD		(14u)
+#define SUART_INVALID_OVERSAMPLING	(15u)
+#define SUART_INVALID_RX_BAUD		(16u)
+
+#define SUART_UART_IN_USE		(17u)
+
+#define SUART_INVALID_CLKDIVISOR	(18u)
+#define SUART_INVALID_UART_NUM		(19u)
+#define SUART_INVALID_SR_NUM		(20u)
+
+#endif
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h b/drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h
new file mode 100644
index 0000000..fa99c6b
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h
@@ -0,0 +1,526 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
+ *
+ * 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 _OMAPLR_MCASP_H_
+#define _OMAPLR_MCASP_H_
+
+#include <linux/types.h>
+#include <linux/io.h>
+#include <linux/mfd/pruss/da8xx_pru.h>
+
+typedef struct {
+	u32 REVID;
+	u32 RSVD0[3];
+	u32 PFUNC;
+	u32 PDIR;
+	u32 PDOUT;
+	u32 PDIN;
+	u32 PDCLR;
+	u32 RSVD1[8];
+	u32 GBLCTL;
+	u32 AMUTE;
+	u32 DLBCTL;
+	u32 DITCTL;
+	u32 RSVD2[3];
+	u32 RGBLCTL;
+	u32 RMASK;
+	u32 RFMT;
+	u32 AFSRCTL;
+	u32 ACLKRCTL;
+	u32 AHCLKRCTL;
+	u32 RTDM;
+	u32 RINTCTL;
+	u32 RSTAT;
+	u32 RSLOT;
+	u32 RCLKCHK;
+	u32 REVTCTL;
+	u32 RSVD3[4];
+	u32 XGBLCTL;
+	u32 XMASK;
+	u32 XFMT;
+	u32 AFSXCTL;
+	u32 ACLKXCTL;
+	u32 AHCLKXCTL;
+	u32 XTDM;
+	u32 XINTCTL;
+	u32 XSTAT;
+	u32 XSLOT;
+	u32 XCLKCHK;
+	u32 XEVTCTL;
+	u32 RSVD4[12];
+	u32 DITCSRA0;
+	u32 DITCSRA1;
+	u32 DITCSRA2;
+	u32 DITCSRA3;
+	u32 DITCSRA4;
+	u32 DITCSRA5;
+	u32 DITCSRB0;
+	u32 DITCSRB1;
+	u32 DITCSRB2;
+	u32 DITCSRB3;
+	u32 DITCSRB4;
+	u32 DITCSRB5;
+	u32 DITUDRA0;
+	u32 DITUDRA1;
+	u32 DITUDRA2;
+	u32 DITUDRA3;
+	u32 DITUDRA4;
+	u32 DITUDRA5;
+	u32 DITUDRB0;
+	u32 DITUDRB1;
+	u32 DITUDRB2;
+	u32 DITUDRB3;
+	u32 DITUDRB4;
+	u32 DITUDRB5;
+	u32 RSVD5[8];
+	u32 SRCTL0;
+	u32 SRCTL1;
+	u32 SRCTL2;
+	u32 SRCTL3;
+	u32 SRCTL4;
+	u32 SRCTL5;
+	u32 SRCTL6;
+	u32 SRCTL7;
+	u32 SRCTL8;
+	u32 SRCTL9;
+	u32 SRCTL10;
+	u32 SRCTL11;
+	u32 SRCTL12;
+	u32 SRCTL13;
+	u32 SRCTL14;
+	u32 SRCTL15;
+	u32 RSVD6[16];
+	u32 XBUF0;
+	u32 XBUF1;
+	u32 XBUF2;
+	u32 XBUF3;
+	u32 XBUF4;
+	u32 XBUF5;
+	u32 XBUF6;
+	u32 XBUF7;
+	u32 XBUF8;
+	u32 XBUF9;
+	u32 XBUF10;
+	u32 XBUF11;
+	u32 XBUF12;
+	u32 XBUF13;
+	u32 XBUF14;
+	u32 XBUF15;
+	u32 RSVD7[16];
+	u32 RBUF0;
+	u32 RBUF1;
+	u32 RBUF2;
+	u32 RBUF3;
+	u32 RBUF4;
+	u32 RBUF5;
+	u32 RBUF6;
+	u32 RBUF7;
+	u32 RBUF8;
+	u32 RBUF9;
+	u32 RBUF10;
+	u32 RBUF11;
+	u32 RBUF12;
+	u32 RBUF13;
+	u32 RBUF14;
+	u32 RBUF15;
+} omapl_mcasp_regs, *omapl_mcasp_regs_ovly;
+
+
+#define OMAPL_MCASP_PFUNC_AFSR_MASK			(0x80000000u)
+#define OMAPL_MCASP_PFUNC_AFSR_SHIFT			(0x0000001Fu)
+#define OMAPL_MCASP_PFUNC_AFSR_RESETVAL			(0x00000000u)
+/* AFSR Tokens */
+#define OMAPL_MCASP_PFUNC_AFSR_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AFSR_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AHCLKR_MASK			(0x40000000u)
+#define OMAPL_MCASP_PFUNC_AHCLKR_SHIFT			(0x0000001Eu)
+#define OMAPL_MCASP_PFUNC_AHCLKR_RESETVAL		(0x00000000u)
+/* AHCLKR Tokens */
+#define OMAPL_MCASP_PFUNC_AHCLKR_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AHCLKR_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_ACLKR_MASK			(0x20000000u)
+#define OMAPL_MCASP_PFUNC_ACLKR_SHIFT			(0x0000001Du)
+#define OMAPL_MCASP_PFUNC_ACLKR_RESETVAL		(0x00000000u)
+/* ACLKR Tokens */
+#define OMAPL_MCASP_PFUNC_ACLKR_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_ACLKR_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AFSX_MASK			(0x10000000u)
+#define OMAPL_MCASP_PFUNC_AFSX_SHIFT			(0x0000001Cu)
+#define OMAPL_MCASP_PFUNC_AFSX_RESETVAL			(0x00000000u)
+/* AFSX Tokens */
+#define OMAPL_MCASP_PFUNC_AFSX_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AFSX_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AHCLKX_MASK			(0x08000000u)
+#define OMAPL_MCASP_PFUNC_AHCLKX_SHIFT			(0x0000001Bu)
+#define OMAPL_MCASP_PFUNC_AHCLKX_RESETVAL		(0x00000000u)
+/* AHCLKX Tokens */
+#define OMAPL_MCASP_PFUNC_AHCLKX_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AHCLKX_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_ACLKX_MASK			(0x04000000u)
+#define OMAPL_MCASP_PFUNC_ACLKX_SHIFT			(0x0000001Au)
+#define OMAPL_MCASP_PFUNC_ACLKX_RESETVAL		(0x00000000u)
+/* ACLKX Tokens */
+#define OMAPL_MCASP_PFUNC_ACLKX_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_ACLKX_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AMUTE_MASK			(0x02000000u)
+#define OMAPL_MCASP_PFUNC_AMUTE_SHIFT			(0x00000019u)
+#define OMAPL_MCASP_PFUNC_AMUTE_RESETVAL		(0x00000000u)
+/* AMUTE Tokens */
+#define OMAPL_MCASP_PFUNC_AMUTE_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AMUTE_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR15_MASK			(0x00008000u)
+#define OMAPL_MCASP_PFUNC_AXR15_SHIFT			(0x0000000Fu)
+#define OMAPL_MCASP_PFUNC_AXR15_RESETVAL		(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR15_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR15_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR14_MASK			(0x00004000u)
+#define OMAPL_MCASP_PFUNC_AXR14_SHIFT			(0x0000000Eu)
+#define OMAPL_MCASP_PFUNC_AXR14_RESETVAL		(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR14_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR14_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR13_MASK			(0x00002000u)
+#define OMAPL_MCASP_PFUNC_AXR13_SHIFT			(0x0000000Du)
+#define OMAPL_MCASP_PFUNC_AXR13_RESETVAL		(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR13_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR13_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR12_MASK			(0x00001000u)
+#define OMAPL_MCASP_PFUNC_AXR12_SHIFT			(0x0000000Cu)
+#define OMAPL_MCASP_PFUNC_AXR12_RESETVAL		(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR12_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR12_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR11_MASK			(0x00000800u)
+#define OMAPL_MCASP_PFUNC_AXR11_SHIFT			(0x0000000Bu)
+#define OMAPL_MCASP_PFUNC_AXR11_RESETVAL		(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR11_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR11_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR10_MASK			(0x00000400u)
+#define OMAPL_MCASP_PFUNC_AXR10_SHIFT			(0x0000000Au)
+#define OMAPL_MCASP_PFUNC_AXR10_RESETVAL		(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR10_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR10_GPIO			(0x00000001u)
+#define OMAPL_MCASP_PFUNC_AXR9_MASK			(0x00000200u)
+#define OMAPL_MCASP_PFUNC_AXR9_SHIFT			(0x00000009u)
+#define OMAPL_MCASP_PFUNC_AXR9_RESETVAL			(0x00000000u)
+/* AXR9 Token */
+#define OMAPL_MCASP_PFUNC_AXR9_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR9_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR8_MASK			(0x00000100u)
+#define OMAPL_MCASP_PFUNC_AXR8_SHIFT			(0x00000008u)
+#define OMAPL_MCASP_PFUNC_AXR8_RESETVAL			(0x00000000u)
+/* AXR8 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR8_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR8_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR7_MASK			(0x00000080u)
+#define OMAPL_MCASP_PFUNC_AXR7_SHIFT			(0x00000007u)
+#define OMAPL_MCASP_PFUNC_AXR7_RESETVAL			(0x00000000u)
+/* AXR7 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR7_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR7_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR6_MASK			(0x00000040u)
+#define OMAPL_MCASP_PFUNC_AXR6_SHIFT			(0x00000006u)
+#define OMAPL_MCASP_PFUNC_AXR6_RESETVAL			(0x00000000u)
+/* AXR6 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR6_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR6_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR5_MASK			(0x00000020u)
+#define OMAPL_MCASP_PFUNC_AXR5_SHIFT			(0x00000005u)
+#define OMAPL_MCASP_PFUNC_AXR5_RESETVAL			(0x00000000u)
+/* AXR5 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR5_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR5_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR4_MASK			(0x00000010u)
+#define OMAPL_MCASP_PFUNC_AXR4_SHIFT			(0x00000004u)
+#define OMAPL_MCASP_PFUNC_AXR4_RESETVAL			(0x00000000u)
+/* AXR4 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR4_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR4_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR3_MASK			(0x00000008u)
+#define OMAPL_MCASP_PFUNC_AXR3_SHIFT			(0x00000003u)
+#define OMAPL_MCASP_PFUNC_AXR3_RESETVAL			(0x00000000u)
+/* AXR3 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR3_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR3_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR2_MASK			(0x00000004u)
+#define OMAPL_MCASP_PFUNC_AXR2_SHIFT			(0x00000002u)
+#define OMAPL_MCASP_PFUNC_AXR2_RESETVAL			(0x00000000u)
+/* AXR2 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR2_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR2_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR1_MASK			(0x00000002u)
+#define OMAPL_MCASP_PFUNC_AXR1_SHIFT			(0x00000001u)
+#define OMAPL_MCASP_PFUNC_AXR1_RESETVAL			(0x00000000u)
+/* AXR1 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR1_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR1_GPIO			(0x00000001u)
+
+#define OMAPL_MCASP_PFUNC_AXR0_MASK			(0x00000001u)
+#define OMAPL_MCASP_PFUNC_AXR0_SHIFT			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR0_RESETVAL			(0x00000000u)
+/* AXR0 Tokens */
+#define OMAPL_MCASP_PFUNC_AXR0_MCASP			(0x00000000u)
+#define OMAPL_MCASP_PFUNC_AXR0_GPIO			(0x00000001u)
+#define OMAPL_MCASP_PFUNC_RESETVAL			(0x00000000u)
+
+#define OMAPL_MCASP_PDIR_AFSR_MASK			(0x80000000u)
+#define OMAPL_MCASP_PDIR_AFSR_SHIFT			(0x0000001Fu)
+#define OMAPL_MCASP_PDIR_AFSR_RESETVAL			(0x00000000u)
+/* AFSR Tokens */
+#define OMAPL_MCASP_PDIR_AFSR_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AFSR_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AHCLKR_MASK			(0x40000000u)
+#define OMAPL_MCASP_PDIR_AHCLKR_SHIFT			(0x0000001Eu)
+#define OMAPL_MCASP_PDIR_AHCLKR_RESETVAL		(0x00000000u)
+/* AHCLKR Tokens */
+#define OMAPL_MCASP_PDIR_AHCLKR_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AHCLKR_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_ACLKR_MASK			(0x20000000u)
+#define OMAPL_MCASP_PDIR_ACLKR_SHIFT			(0x0000001Du)
+#define OMAPL_MCASP_PDIR_ACLKR_RESETVAL			(0x00000000u)
+/* ACLKR Tokens */
+#define OMAPL_MCASP_PDIR_ACLKR_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_ACLKR_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AFSX_MASK			(0x10000000u)
+#define OMAPL_MCASP_PDIR_AFSX_SHIFT			(0x0000001Cu)
+#define OMAPL_MCASP_PDIR_AFSX_RESETVAL			(0x00000000u)
+/* AFSX Tokens */
+#define OMAPL_MCASP_PDIR_AFSX_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AFSX_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AHCLKX_MASK			(0x08000000u)
+#define OMAPL_MCASP_PDIR_AHCLKX_SHIFT			(0x0000001Bu)
+#define OMAPL_MCASP_PDIR_AHCLKX_RESETVAL		(0x00000000u)
+/* AHCLKX Tokens */
+#define OMAPL_MCASP_PDIR_AHCLKX_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AHCLKX_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_ACLKX_MASK			(0x04000000u)
+#define OMAPL_MCASP_PDIR_ACLKX_SHIFT			(0x0000001Au)
+#define OMAPL_MCASP_PDIR_ACLKX_RESETVAL			(0x00000000u)
+/* ACLKX Tokens */
+#define OMAPL_MCASP_PDIR_ACLKX_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_ACLKX_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AMUTE_MASK			(0x02000000u)
+#define OMAPL_MCASP_PDIR_AMUTE_SHIFT			(0x00000019u)
+#define OMAPL_MCASP_PDIR_AMUTE_RESETVAL			(0x00000000u)
+/* AMUTE Tokens */
+#define OMAPL_MCASP_PDIR_AMUTE_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AMUTE_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR15_MASK			(0x00008000u)
+#define OMAPL_MCASP_PDIR_AXR15_SHIFT			(0x0000000Fu)
+#define OMAPL_MCASP_PDIR_AXR15_RESETVAL			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR15_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR15_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR14_MASK			(0x00004000u)
+#define OMAPL_MCASP_PDIR_AXR14_SHIFT			(0x0000000Eu)
+#define OMAPL_MCASP_PDIR_AXR14_RESETVAL			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR14_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR14_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR13_MASK			(0x00002000u)
+#define OMAPL_MCASP_PDIR_AXR13_SHIFT			(0x0000000Du)
+#define OMAPL_MCASP_PDIR_AXR13_RESETVAL			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR13_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR13_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR12_MASK			(0x00001000u)
+#define OMAPL_MCASP_PDIR_AXR12_SHIFT			(0x0000000Cu)
+#define OMAPL_MCASP_PDIR_AXR12_RESETVAL			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR12_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR12_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR11_MASK			(0x00000800u)
+#define OMAPL_MCASP_PDIR_AXR11_SHIFT			(0x0000000Bu)
+#define OMAPL_MCASP_PDIR_AXR11_RESETVAL			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR11_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR11_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR10_MASK			(0x00000400u)
+#define OMAPL_MCASP_PDIR_AXR10_SHIFT			(0x0000000Au)
+#define OMAPL_MCASP_PDIR_AXR10_RESETVAL			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR10_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR10_OUTPUT			(0x00000001u)
+#define OMAPL_MCASP_PDIR_AXR9_MASK			(0x00000200u)
+#define OMAPL_MCASP_PDIR_AXR9_SHIFT			(0x00000009u)
+#define OMAPL_MCASP_PDIR_AXR9_RESETVAL			(0x00000000u)
+/* AXR9 Tokens */
+#define OMAPL_MCASP_PDIR_AXR9_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR9_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR8_MASK			(0x00000100u)
+#define OMAPL_MCASP_PDIR_AXR8_SHIFT			(0x00000008u)
+#define OMAPL_MCASP_PDIR_AXR8_RESETVAL			(0x00000000u)
+/* AXR8 Tokens */
+#define OMAPL_MCASP_PDIR_AXR8_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR8_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR7_MASK			(0x00000080u)
+#define OMAPL_MCASP_PDIR_AXR7_SHIFT			(0x00000007u)
+#define OMAPL_MCASP_PDIR_AXR7_RESETVAL			(0x00000000u)
+/*----AXR7 Tokens----*/
+#define OMAPL_MCASP_PDIR_AXR7_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR7_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR6_MASK			(0x00000040u)
+#define OMAPL_MCASP_PDIR_AXR6_SHIFT			(0x00000006u)
+#define OMAPL_MCASP_PDIR_AXR6_RESETVAL			(0x00000000u)
+/*----AXR6 Tokens----*/
+#define OMAPL_MCASP_PDIR_AXR6_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR6_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR5_MASK			(0x00000020u)
+#define OMAPL_MCASP_PDIR_AXR5_SHIFT			(0x00000005u)
+#define OMAPL_MCASP_PDIR_AXR5_RESETVAL			(0x00000000u)
+/*----AXR5 Tokens----*/
+#define OMAPL_MCASP_PDIR_AXR5_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR5_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR4_MASK			(0x00000010u)
+#define OMAPL_MCASP_PDIR_AXR4_SHIFT			(0x00000004u)
+#define OMAPL_MCASP_PDIR_AXR4_RESETVAL			(0x00000000u)
+/*----AXR4 Tokens----*/
+#define OMAPL_MCASP_PDIR_AXR4_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR4_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR3_MASK			(0x00000008u)
+#define OMAPL_MCASP_PDIR_AXR3_SHIFT			(0x00000003u)
+#define OMAPL_MCASP_PDIR_AXR3_RESETVAL			(0x00000000u)
+/*----AXR3 Tokens----*/
+#define OMAPL_MCASP_PDIR_AXR3_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR3_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR2_MASK			(0x00000004u)
+#define OMAPL_MCASP_PDIR_AXR2_SHIFT			(0x00000002u)
+#define OMAPL_MCASP_PDIR_AXR2_RESETVAL			(0x00000000u)
+/*----AXR2 Tokens----*/
+#define OMAPL_MCASP_PDIR_AXR2_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR2_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR1_MASK			(0x00000002u)
+#define OMAPL_MCASP_PDIR_AXR1_SHIFT			(0x00000001u)
+#define OMAPL_MCASP_PDIR_AXR1_RESETVAL			(0x00000000u)
+/*----AXR1 Tokens----*/
+#define OMAPL_MCASP_PDIR_AXR1_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR1_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_AXR0_MASK			(0x00000001u)
+#define OMAPL_MCASP_PDIR_AXR0_SHIFT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR0_RESETVAL			(0x00000000u)
+/*----AXR0 Tokens----*/
+#define OMAPL_MCASP_PDIR_AXR0_INPUT			(0x00000000u)
+#define OMAPL_MCASP_PDIR_AXR0_OUTPUT			(0x00000001u)
+
+#define OMAPL_MCASP_PDIR_RESETVAL			(0x00000000u)
+
+#define OMAPL_MCASP_ACLKXCTL_CLKXP_MASK			(0x00000080u)
+#define OMAPL_MCASP_ACLKXCTL_CLKXP_SHIFT		(0x00000007u)
+#define OMAPL_MCASP_ACLKXCTL_CLKXP_RESETVAL		(0x00000000u)
+/*----CLKXP Tokens----*/
+#define OMAPL_MCASP_ACLKXCTL_CLKXP_RISINGEDGE		(0x00000000u)
+#define OMAPL_MCASP_ACLKXCTL_CLKXP_FALLINGEDGE		(0x00000001u)
+
+#define OMAPL_MCASP_ACLKXCTL_ASYNC_MASK			(0x00000040u)
+#define OMAPL_MCASP_ACLKXCTL_ASYNC_SHIFT		(0x00000006u)
+#define OMAPL_MCASP_ACLKXCTL_ASYNC_RESETVAL		(0x00000001u)
+/*----ASYNC Tokens----*/
+#define OMAPL_MCASP_ACLKXCTL_ASYNC_SYNC			(0x00000000u)
+#define OMAPL_MCASP_ACLKXCTL_ASYNC_ASYNC		(0x00000001u)
+
+#define OMAPL_MCASP_ACLKXCTL_CLKXM_MASK			(0x00000020u)
+#define OMAPL_MCASP_ACLKXCTL_CLKXM_SHIFT		(0x00000005u)
+#define OMAPL_MCASP_ACLKXCTL_CLKXM_RESETVAL		(0x00000001u)
+/*----CLKXM Tokens----*/
+#define OMAPL_MCASP_ACLKXCTL_CLKXM_EXTERNAL		(0x00000000u)
+#define OMAPL_MCASP_ACLKXCTL_CLKXM_INTERNAL		(0x00000001u)
+
+#define OMAPL_MCASP_ACLKXCTL_CLKXDIV_MASK		(0x0000001Fu)
+#define OMAPL_MCASP_ACLKXCTL_CLKXDIV_SHIFT		(0x00000000u)
+#define OMAPL_MCASP_ACLKXCTL_CLKXDIV_RESETVAL		(0x00000000u)
+
+#define OMAPL_MCASP_ACLKXCTL_RESETVAL			(0x00000060u)
+
+/* AHCLKXCTL */
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXM_MASK		(0x00008000u)
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXM_SHIFT		(0x0000000Fu)
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXM_RESETVAL		(0x00000001u)
+/*----HCLKXM Tokens----*/
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXM_EXTERNAL		(0x00000000u)
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXM_INTERNAL		(0x00000001u)
+
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXP_MASK		(0x00004000u)
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXP_SHIFT		(0x0000000Eu)
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXP_RESETVAL		(0x00000000u)
+/*----HCLKXP Tokens----*/
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXP_NOTINVERTED	(0x00000000u)
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXP_INVERTED		(0x00000001u)
+
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXDIV_MASK		(0x00000FFFu)
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXDIV_SHIFT		(0x00000000u)
+#define OMAPL_MCASP_AHCLKXCTL_HCLKXDIV_RESETVAL		(0x00000000u)
+
+#define OMAPL_MCASP_AHCLKXCTL_RESETVAL			(0x00008000u)
+
+#define MCASP_SUART_GBLCTL				(0X00000000)
+#define MCASP_SUART_RGBLCTL				(0X00000000)
+#define MCASP_SUART_XGBLCTL				(0X00000000)
+#define MCASP_SUART_RMASK_8				(0x000000FF)
+#define MCASP_SUART_RMASK_16				(0x0000FFFF)
+#define MCASP_SUART_RFMT_8				(0x0000A038)
+#define MCASP_SUART_RFMT_16				(0x0000A078)
+#define MCASP_SUART_FSRM				(0X00000002)
+#define MCASP_SUART_CLKRM_CLKRP				(0X000000A0)
+#define MCASP_SUART_HCLKRP				(0X00008000)
+#define MCASP_SUART_RTDMS0				(0X00000001)
+#define MCASP_SUART_RSYNCERR				(0X00000002)
+#define MCASP_SUART_RMAX_RPS_256			(0x00FF0008)
+#define MCASP_SUART_XMASK_0_31				(0X0000FFFF)
+#define MCASP_SUART_XBUSEL_XSSZ_16_XPAD_0		(0x00002078)
+#define MCASP_SUART_FSXM				(0x00000002)
+#define MCASP_SUART_CLKXM_ASYNC_CLKXP			(0x000000E0)
+#define MCASP_SUART_HCLKXM				(0x00008000)
+#define MCASP_SUART_XTDMS0				(0X00000001)
+#define MCASP_SUART_XSYNCERR				(0x00000002)
+#define MCASP_SUART_XMAX_XPS_256			(0x00FF0008)
+#define MCASP_SUART_SRCTL_DISMOD			(0x0000000c)
+#define MCASP_SUART_DIT_DISABLE				(0X00000000)
+#define MCASP_SUART_LOOPBACK_DISABLE			(0x00000000)
+#define MCASP_SUART_AMUTE_DISABLE			(0X00000000)
+#define MCASP_SUART_XSTAT				(0x0000FFFF)
+#define MCASP_SUART_RSTAT				(0x0000FFFF)
+#endif
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h b/drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h
new file mode 100644
index 0000000..c2aa9d7
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h
@@ -0,0 +1,153 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: jitendra at mistralsolutions.com
+ *
+ * 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 _SUART_PRU_REGS_H_
+#define _SUART_PRU_REGS_H_
+
+#include <linux/types.h>
+
+/** PRU0 DATA RAM base address */
+#define PRU0_DATARAM_OFFSET		(0x0000u)
+/** PRU1 DATA RAM base address */
+#define PRU1_DATARAM_OFFSET		(0x2000u)
+
+/** PRU0 DATA RAM size */
+#define PRU0_DATARAM_SIZE		(0x200u)
+/** PRU1 DATA RAM size */
+#define PRU1_DATARAM_SIZE		(0x200u)
+
+#define PRU_SUART_PRU0_CH0_OFFSET	(0x0000)
+#define PRU_SUART_PRU0_CH1_OFFSET	(0x0010)
+#define PRU_SUART_PRU0_CH2_OFFSET	(0x0020)
+#define PRU_SUART_PRU0_CH3_OFFSET	(0x0030)
+#define PRU_SUART_PRU0_CH4_OFFSET	(0x0040)
+#define PRU_SUART_PRU0_CH5_OFFSET	(0x0050)
+#define PRU_SUART_PRU0_CH6_OFFSET	(0x0060)
+#define PRU_SUART_PRU0_CH7_OFFSET	(0x0070)
+#define PRU_SUART_PRU0_IMR_OFFSET	(0x0080)
+/** Interrupt Mask Register */
+#define PRU_SUART_PRU0_ISR_OFFSET	(0x0082)
+/** Interrupt Status Register */
+#define PRU_SUART_PRU0_ID_ADDR		(0x0084)
+/** PRU ID Register */
+#define PRU_SUART_PRU0_RX_TX_MODE	(0x0085)
+#define PRU_SUART_PRU0_DELAY_OFFSET	(0x0086)
+#define PRU_SUART_PRU0_IDLE_TIMEOUT_OFFSET	(0x0088)
+
+/* ********* PRU 1 Macros ************* */
+#define PRU_SUART_PRU1_CH0_OFFSET	(0x2000)
+#define PRU_SUART_PRU1_CH1_OFFSET	(0x2010)
+#define PRU_SUART_PRU1_CH2_OFFSET	(0x2020)
+#define PRU_SUART_PRU1_CH3_OFFSET	(0x2030)
+#define PRU_SUART_PRU1_CH4_OFFSET	(0x2040)
+#define PRU_SUART_PRU1_CH5_OFFSET	(0x2050)
+#define PRU_SUART_PRU1_CH6_OFFSET	(0x2060)
+#define PRU_SUART_PRU1_CH7_OFFSET	(0x2070)
+#define PRU_SUART_PRU1_IMR_OFFSET	(0x2080)
+#define PRU_SUART_PRU1_ISR_OFFSET	(0x2082)
+#define PRU_SUART_PRU1_ID_ADDR		(0x2084)
+#define PRU_SUART_PRU1_RX_TX_MODE	(0x2085)
+#define PRU_SUART_PRU1_DELAY_OFFSET	(0x2086)
+#define PRU_SUART_PRU1_IDLE_TIMEOUT_OFFSET	(0x2088)
+
+/* SUART Channel Control Register bit descriptions */
+#define PRU_SUART_CH_CTRL_MODE_SHIFT		0x0000
+#define PRU_SUART_CH_CTRL_MODE_MASK		0x0003
+#define PRU_SUART_CH_CTRL_TX_MODE		0x0001
+#define PRU_SUART_CH_CTRL_RX_MODE		0x0002
+
+/* Service Request */
+#define PRU_SUART_CH_CTRL_SREQ_SHIFT		0x0002
+#define PRU_SUART_CH_CTRL_SREQ_MASK		0x0004
+#define PRU_SUART_CH_CTRL_SREQ			0x0001
+
+/* McASP Instance */
+#define PRU_SUART_CH_CTRL_MCASP_SHIFT		0x0003
+#define PRU_SUART_CH_CTRL_MCASP_MASK		0x0018
+#define PRU_SUART_CH_CTRL_SR_SHIFT		0x0008
+#define PRU_SUART_CH_CTRL_SR_MASK		0x0F00
+
+/* SUART channel configuration1 register descriptions */
+
+/* clock divisor -  relative baud value */
+#define PRU_SUART_CH_CONFIG1_DIVISOR_SHIFT	0x0000
+#define PRU_SUART_CH_CONFIG1_DIVISOR_MASK	0x03FF
+/* oversampling */
+#define PRU_SUART_CH_CONFIG1_OVS_SHIFT		0x000A
+#define PRU_SUART_CH_CONFIG1_OVS_MASK		0x0C00
+
+/* SUART channel configuration2 register descriptions */
+/* Bits per character */
+#define PRU_SUART_CH_CONFIG2_BITPERCHAR_SHIFT	0x0000
+#define PRU_SUART_CH_CONFIG2_BITPERCHAR_MASK	0x000F
+
+/* Bits per character */
+#define PRU_SUART_CH_CONFIG2_DATALEN_SHIFT	0x0008
+#define PRU_SUART_CH_CONFIG2_DATALEN_MASK	0x0F00
+
+/* SUART Channel register offsets */
+#define PRU_SUART_CH_CTRL_OFFSET		0x00
+#define PRU_SUART_CH_CONFIG1_OFFSET		0x02
+#define PRU_SUART_CH_CONFIG2_OFFSET		0x04
+#define PRU_SUART_CH_TXRXSTATUS_OFFSET		0x06
+#define PRU_SUART_CH_TXRXDATA_OFFSET		0x08
+#define PRU_SUART_CH_BYTESDONECNTR_OFFSET	0x0C
+
+/* SUART Event Numbers macros */
+#define PRU_SUART0_TX_EVT	34
+#define PRU_SUART0_RX_EVT	35
+#define PRU_SUART1_TX_EVT	36
+#define PRU_SUART1_RX_EVT	37
+#define PRU_SUART2_TX_EVT	38
+#define PRU_SUART2_RX_EVT	39
+#define PRU_SUART3_TX_EVT	40
+#define PRU_SUART3_RX_EVT	41
+#define PRU_SUART4_TX_EVT	42
+#define PRU_SUART4_RX_EVT	43
+#define PRU_SUART5_TX_EVT	44
+#define PRU_SUART5_RX_EVT	45
+#define PRU_SUART6_TX_EVT	46
+#define PRU_SUART6_RX_EVT	47
+#define PRU_SUART7_TX_EVT	48
+#define PRU_SUART7_RX_EVT	49
+
+#define PRU_SUART0_TX_EVT_BIT	BIT(2)
+#define PRU_SUART0_RX_EVT_BIT	BIT(3)
+#define PRU_SUART1_TX_EVT_BIT	BIT(4)
+#define PRU_SUART1_RX_EVT_BIT	BIT(5)
+#define PRU_SUART2_TX_EVT_BIT	BIT(6)
+#define PRU_SUART2_RX_EVT_BIT	BIT(7)
+#define PRU_SUART3_TX_EVT_BIT	BIT(8)
+#define PRU_SUART3_RX_EVT_BIT	BIT(9)
+#define PRU_SUART4_TX_EVT_BIT	BIT(10)
+#define PRU_SUART4_RX_EVT_BIT	BIT(11)
+#define PRU_SUART5_TX_EVT_BIT	BIT(12)
+#define PRU_SUART5_RX_EVT_BIT	BIT(13)
+#define PRU_SUART6_TX_EVT_BIT	BIT(14)
+#define PRU_SUART6_RX_EVT_BIT	BIT(15)
+#define PRU_SUART7_TX_EVT_BIT	BIT(16)
+#define PRU_SUART7_RX_EVT_BIT	BIT(17)
+
+/*
+ *  SUART Config regs
+ */
+typedef struct {
+	u16 chn_ctrl;
+	u16 chn_config1;
+	u16 chn_config2;
+	u16 chn_txrx_status;
+	u32 chn_txrx_data;
+} suart_struct_pru_regs;
+
+#endif
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c b/drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c
new file mode 100644
index 0000000..7ced423
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c
@@ -0,0 +1,384 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
+ *
+ * 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/mfd/pruss/da8xx_pru.h>
+#include "pruss_suart_mcasp.h"
+#include "pruss_suart_api.h"
+#include "pruss_suart_regs.h"
+#include "pruss_suart_board.h"
+#include "pruss_suart_utils.h"
+#include "pruss_suart_err.h"
+
+
+#define SUART_TRX_DIV_CONF_SZ	4
+
+static s16 suart_mcasp_tx_baud_set(u32 tx_baud_value,
+			pruss_suart_iomap *pruss_ioaddr);
+static s16 suart_mcasp_rx_baud_set(u32 rx_baud_value, u32 oversampling,
+			pruss_suart_iomap *pruss_ioaddr);
+
+/*
+ * Lookup table for TX baud rate
+ * The divisor value is calculated using the formula
+ *
+ * ACLKX = (AUXCLK)/(CLKXDIV * HCLKXDIV)
+ *
+ * Where
+ *		CLKXDIV takes values from 1-32
+ *		HCLKXDIV takes values from 1-4096
+ * Here
+ *		AUXCLK = 24MHz
+ */
+u32 lt_tx_baud_rate[][SUART_TRX_DIV_CONF_SZ] = {
+	/*BaudRate,	Divisor,	CLKXDIV,HCLKXDIV */
+	{300,		80000,		24,		3200},
+	{600,		40000,		15,		2500},
+	{1800,		13333,		10,		1212},
+	{2400,		10000,		4,		2000},
+	{4800,		5000,		1,		2500},
+	{7200,		3333,		0,		3333},
+	{9600,		2500,		0,		2500},
+	{14400,		1666,		0,		1666},
+	{19200,		1250,		0,		1250},
+	{38400,		625,		0,		625},
+	{57600,		416,		0,		416},
+	{115200,	208,		0,		208},
+	{230400,	104,		0,		104}
+};
+
+/*
+ * Lookup table for RX baud rate for 8 bit oversampling
+ * The divisor value is calculated using the formula
+ *
+ *	ACLKR = (AUXCLK)/(CLKRDIV * HCLKRDIV) * Oversampling
+ *
+ * Where
+ *		CLKRDIV takes values from 1-32
+ *		HCLKRDIV takes values from 1-4096
+ * Here
+ *		AUXCLK = 24MHz
+ */
+u32 lt_rx_8x_baud_rate[][SUART_TRX_DIV_CONF_SZ] = {
+/* BaudRate,	Divisor,	CLKXDIV,	HCLKXDIV */
+	{300,		10000,		4,		2000},
+	{600,		5000,		1,		2500},
+	{1800,		1667,		0,		1667},
+	{2400,		1250,		0,		1250},
+	{7200,		417,		0,		417},
+	{4800,		625,		0,		625},
+	{9600,		312,		0,		312},
+	{14400,		208,		0,		208},
+	{19200,		156,		0,		156},
+	{38400,		78,		0,		78},
+	{57600,		52,		0,		52},
+	{115200,	26,		0,		26},
+	{230400,	13,		0,		13}
+};
+
+/*
+ * Lookup table for RX baud rate for 16 bit oversampling
+ * The divisor value is calculated using the formula
+ *
+ *	ACLKR = (AUXCLK)/(CLKRDIV * HCLKRDIV) * Oversampling
+ *
+ * Where
+ *		CLKRDIV takes values from 1-32
+ *		HCLKRDIV takes values from 1-4096
+ * Here
+ *		AUXCLK = 24MHz
+ */
+u32 lt_rx_16x_baud_rate[][SUART_TRX_DIV_CONF_SZ] = {
+/*BaudRate,	Divisor,	CLKXDIV,	HCLKXDIV */
+	{300,		5000,		1,		2500},
+	{600,		2500,		0,		2500},
+	{1800,		833,		0,		833},
+	{2400,		625,		0,		625},
+	{4800,		312,		0,		312},
+	{7200,		208,		0,		208},
+	{9600,		156,		0,		156},
+	{14400,		104,		0,		104},
+	{19200,		78,		0,		78},
+	{38400,		39,		0,		39},
+	{57600,		26,		0,		26},
+	{115200,	13,		0,		13},
+	{230400,	6,		0,		6}
+};
+
+/*
+ * McASP configuration routine
+ */
+void suart_mcasp_config(u32 tx_baud_value,
+			u32 rx_baud_value,
+			u32 oversampling,
+			pruss_suart_iomap *pruss_ioaddr)
+{
+	omapl_mcasp_regs_ovly mcasp0_regs =
+		(omapl_mcasp_regs_ovly) pruss_ioaddr->mcasp_io_addr;
+	u32 temp_reg;
+
+	/* reset mcasp */
+	__raw_writel(MCASP_SUART_GBLCTL, &mcasp0_regs->GBLCTL);
+	__raw_writel(MCASP_SUART_RGBLCTL, &mcasp0_regs->RGBLCTL);
+	__raw_writel(MCASP_SUART_XGBLCTL, &mcasp0_regs->XGBLCTL);
+
+	/* configure receive registers */
+	if ((SUART_8X_OVRSMPL == oversampling) || (0 == oversampling)) {
+		__raw_writel(MCASP_SUART_RMASK_8, &mcasp0_regs->RMASK);
+		__raw_writel(MCASP_SUART_RFMT_8, &mcasp0_regs->RFMT);
+	}
+	if (SUART_16X_OVRSMPL == oversampling) {
+		__raw_writel(MCASP_SUART_RMASK_16, &mcasp0_regs->RMASK);
+		__raw_writel(MCASP_SUART_RFMT_16, &mcasp0_regs->RFMT);
+
+	}
+
+	__raw_writel(MCASP_SUART_FSRM, &mcasp0_regs->AFSRCTL);
+	__raw_writel(MCASP_SUART_CLKRM_CLKRP, &mcasp0_regs->ACLKRCTL);
+	__raw_writel(MCASP_SUART_HCLKRP, &mcasp0_regs->AHCLKRCTL);
+	suart_mcasp_rx_baud_set(rx_baud_value, oversampling, pruss_ioaddr);
+	__raw_writel(MCASP_SUART_RTDMS0, &mcasp0_regs->RTDM);
+	__raw_writel(MCASP_SUART_RSYNCERR, &mcasp0_regs->RINTCTL);
+	__raw_writel(MCASP_SUART_RMAX_RPS_256, &mcasp0_regs->RCLKCHK);
+
+	/* configure transmit registers. */
+	__raw_writel(MCASP_SUART_XMASK_0_31, &mcasp0_regs->XMASK);
+	__raw_writel(MCASP_SUART_XBUSEL_XSSZ_16_XPAD_0, &mcasp0_regs->XFMT);
+	__raw_writel(MCASP_SUART_FSXM, &mcasp0_regs->AFSXCTL);
+	__raw_writel(MCASP_SUART_CLKXM_ASYNC_CLKXP, &mcasp0_regs->ACLKXCTL);
+	__raw_writel(MCASP_SUART_HCLKXM, &mcasp0_regs->AHCLKXCTL);
+
+	suart_mcasp_tx_baud_set(tx_baud_value, pruss_ioaddr);
+	__raw_writel(MCASP_SUART_XTDMS0, &mcasp0_regs->XTDM);
+	__raw_writel(MCASP_SUART_XSYNCERR, &mcasp0_regs->XINTCTL);
+	__raw_writel(MCASP_SUART_XMAX_XPS_256, &mcasp0_regs->XCLKCHK);
+
+	/* Serializer as a transmitter */
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL0);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL1);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL2);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL3);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL4);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL5);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL6);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL7);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL8);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL9);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL10);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL11);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL12);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL13);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL14);
+	__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL15);
+
+	/* Configure all AXR[n] as McASP pins  */
+
+	/*
+	 *  Setting  all TX MCASP AXR[n] Pin mapped to Even Serializer number
+	 *  (0,2,4,6,8,10,12,14) to GPIO Mode by default. During setting the
+	 *  serializer to TX mode in PRU assembly code, the MCASP AXR[n] Pin
+	 *  would get configured to MCASP mode of operation,
+	 *  before Actual Data Transfer
+	 */
+
+	/* Setting  all TX Pin to GPIO Mode by default */
+	temp_reg = (OMAPL_MCASP_PFUNC_RESETVAL) |
+	    (1 << PRU_SUART0_CONFIG_TX_SER) | (1 << PRU_SUART1_CONFIG_TX_SER) |
+	    (1 << PRU_SUART2_CONFIG_TX_SER) | (1 << PRU_SUART3_CONFIG_TX_SER) |
+	    (1 << PRU_SUART4_CONFIG_TX_SER) | (1 << PRU_SUART5_CONFIG_TX_SER) |
+	    (1 << PRU_SUART6_CONFIG_TX_SER) | (1 << PRU_SUART7_CONFIG_TX_SER);
+	__raw_writel(temp_reg, &mcasp0_regs->PFUNC);
+
+	__raw_writel(0xFFF, &mcasp0_regs->PDOUT);
+
+	/* config pin function and direction */
+	__raw_writel(0x00000000, &mcasp0_regs->PDIR);
+	temp_reg =
+	    (1 << PRU_SUART0_CONFIG_TX_SER) | (1 << PRU_SUART1_CONFIG_TX_SER) |
+	    (1 << PRU_SUART2_CONFIG_TX_SER) | (1 << PRU_SUART3_CONFIG_TX_SER) |
+	    (1 << PRU_SUART4_CONFIG_TX_SER) | (1 << PRU_SUART5_CONFIG_TX_SER) |
+	    (1 << PRU_SUART6_CONFIG_TX_SER) | (1 << PRU_SUART7_CONFIG_TX_SER) |
+	    (MCASP_PDIR_VAL);
+	__raw_writel(temp_reg, &mcasp0_regs->PDIR);
+
+	__raw_writel(MCASP_SUART_DIT_DISABLE, &mcasp0_regs->DITCTL);
+	__raw_writel(MCASP_SUART_LOOPBACK_DISABLE, &mcasp0_regs->DLBCTL);
+	__raw_writel(MCASP_SUART_AMUTE_DISABLE, &mcasp0_regs->AMUTE);
+
+	__raw_writel(MCASP_SUART_XSTAT, &mcasp0_regs->XSTAT);
+	__raw_writel(MCASP_SUART_RSTAT, &mcasp0_regs->RSTAT);
+}
+
+void suart_mcasp_tx_serialzier_set(u32 serializer_num,
+		pruss_suart_iomap *pruss_ioaddr)
+{
+	omapl_mcasp_regs_ovly mcasp0_regs =
+	    (omapl_mcasp_regs_ovly) pruss_ioaddr->mcasp_io_addr;
+	u32 temp_reg;
+	temp_reg = mcasp0_regs->PFUNC | (0x1 << serializer_num);
+	__raw_writel(temp_reg, &mcasp0_regs->PFUNC);
+}
+
+/*
+ * mcasp TX buard rate setting routine
+ */
+s16 suart_mcasp_tx_baud_set(u32 tx_baud_value,
+		pruss_suart_iomap *pruss_ioaddr)
+{
+	u32 clk_div_val;
+	u32 loop_cnt;
+	s16 status = SUART_SUCCESS;
+	s16 found_val = SUART_FALSE;
+
+	omapl_mcasp_regs_ovly mcasp0_regs =
+	    (omapl_mcasp_regs_ovly) pruss_ioaddr->mcasp_io_addr;
+	u32 temp_reg;
+
+	/* Search the supported baud rate in the table */
+	for (loop_cnt = 0; loop_cnt < SUART_NUM_OF_BAUDS_SUPPORTED;
+							loop_cnt++) {
+		if (tx_baud_value == lt_tx_baud_rate[loop_cnt][0]) {
+			found_val = SUART_TRUE;
+			break;
+		}
+	}
+	if (found_val == SUART_TRUE) {
+		clk_div_val = lt_tx_baud_rate[loop_cnt][2];
+		temp_reg = mcasp0_regs->ACLKXCTL |
+			clk_div_val << OMAPL_MCASP_ACLKXCTL_CLKXDIV_SHIFT;
+		__raw_writel(temp_reg, &mcasp0_regs->ACLKXCTL);
+		clk_div_val = lt_tx_baud_rate[loop_cnt][3];
+		temp_reg = mcasp0_regs->AHCLKXCTL |
+			clk_div_val << OMAPL_MCASP_AHCLKXCTL_HCLKXDIV_SHIFT;
+		__raw_writel(temp_reg, &mcasp0_regs->AHCLKXCTL);
+	} else {
+		return SUART_INVALID_TX_BAUD;
+	}
+	return status;
+}
+
+/*
+ * mcasp RX buard rate setting routine
+ */
+s16 suart_mcasp_rx_baud_set(u32 rx_baud_value,
+	u32 oversampling, pruss_suart_iomap *pruss_ioaddr)
+{
+	u32 clk_div_val;
+	u32 loop_cnt;
+	s16 status = SUART_SUCCESS;
+	s16 found_val = SUART_FALSE;
+
+	omapl_mcasp_regs_ovly mcasp0_regs =
+	    (omapl_mcasp_regs_ovly) pruss_ioaddr->mcasp_io_addr;
+	u32 temp_reg;
+
+	if (oversampling == SUART_8X_OVRSMPL) {
+		for (loop_cnt = 0; loop_cnt < SUART_NUM_OF_BAUDS_SUPPORTED;
+		     loop_cnt++) {
+			if (rx_baud_value == lt_rx_8x_baud_rate[loop_cnt][0]) {
+				clk_div_val = lt_rx_8x_baud_rate[loop_cnt][2];
+				temp_reg = mcasp0_regs->ACLKRCTL | (clk_div_val
+					<< OMAPL_MCASP_ACLKXCTL_CLKXDIV_SHIFT);
+
+				__raw_writel(temp_reg, &mcasp0_regs->ACLKRCTL);
+
+				clk_div_val =
+				lt_rx_8x_baud_rate[loop_cnt][3] - 1;
+
+				temp_reg = mcasp0_regs->AHCLKRCTL | (clk_div_val
+				<< OMAPL_MCASP_AHCLKXCTL_HCLKXDIV_SHIFT);
+
+				__raw_writel(temp_reg, &mcasp0_regs->AHCLKRCTL);
+
+				found_val = SUART_TRUE;
+				break;
+			}
+		}
+	} else if (oversampling == SUART_16X_OVRSMPL) {
+		for (loop_cnt = 0; loop_cnt < SUART_NUM_OF_BAUDS_SUPPORTED;
+		     loop_cnt++) {
+			if (rx_baud_value == lt_rx_16x_baud_rate[loop_cnt][0]) {
+				clk_div_val = lt_rx_16x_baud_rate[loop_cnt][2];
+				temp_reg =
+					mcasp0_regs->ACLKRCTL | (clk_div_val <<
+					OMAPL_MCASP_ACLKXCTL_CLKXDIV_SHIFT);
+				__raw_writel(temp_reg, &mcasp0_regs->ACLKRCTL);
+				clk_div_val = lt_rx_16x_baud_rate[loop_cnt][3];
+				temp_reg =
+				mcasp0_regs->AHCLKRCTL | (clk_div_val <<
+				OMAPL_MCASP_AHCLKXCTL_HCLKXDIV_SHIFT);
+				__raw_writel(temp_reg, &mcasp0_regs->AHCLKRCTL);
+				found_val = SUART_TRUE;
+				break;
+			}
+		}
+	} else if (oversampling == 0) {
+		for (loop_cnt = 0; loop_cnt < SUART_NUM_OF_BAUDS_SUPPORTED;
+		     loop_cnt++) {
+			if (rx_baud_value == lt_tx_baud_rate[loop_cnt][0]) {
+				clk_div_val = lt_tx_baud_rate[loop_cnt][2];
+				temp_reg =
+				mcasp0_regs->ACLKRCTL | (clk_div_val <<
+				OMAPL_MCASP_ACLKXCTL_CLKXDIV_SHIFT);
+				__raw_writel(temp_reg, &mcasp0_regs->ACLKRCTL);
+				clk_div_val = lt_tx_baud_rate[loop_cnt][3];
+				temp_reg =
+				mcasp0_regs->AHCLKRCTL | (clk_div_val <<
+				OMAPL_MCASP_AHCLKXCTL_HCLKXDIV_SHIFT);
+				__raw_writel(temp_reg, &mcasp0_regs->AHCLKRCTL);
+				found_val = SUART_TRUE;
+				break;
+			}
+		}
+	} else {
+		return SUART_INVALID_OVERSAMPLING;
+	}
+
+	if (found_val != SUART_TRUE)
+		return SUART_INVALID_RX_BAUD;
+
+	return status;
+}
+
+/*
+ * mcasp buard rate setting routine
+ */
+s16 suart_asp_baud_set(u32 tx_baud_value, u32 rx_baud_value, u32 oversampling,
+					pruss_suart_iomap *pruss_ioaddr)
+{
+	s16 status = SUART_SUCCESS;
+
+	status = suart_mcasp_tx_baud_set(tx_baud_value, pruss_ioaddr);
+	status = suart_mcasp_rx_baud_set(rx_baud_value, oversampling,
+					pruss_ioaddr);
+
+	return status;
+}
+
+/*
+ * mcasp deactivate the selected serializer
+ */
+s16 suart_asp_serializer_deactivate(u16 u16sr_num,
+		pruss_suart_iomap *pruss_ioaddr)
+{
+	s16 status = SUART_SUCCESS;
+	omapl_mcasp_regs_ovly mcasp0_regs = (omapl_mcasp_regs_ovly)
+				pruss_ioaddr->mcasp_io_addr;
+	if (u16sr_num > 15)
+		status = SUART_INVALID_SR_NUM;
+	else
+		__raw_writel(MCASP_SUART_SRCTL_DISMOD, &mcasp0_regs->SRCTL0);
+
+	return status;
+}
diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h b/drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h
new file mode 100644
index 0000000..7839eb6
--- /dev/null
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h
@@ -0,0 +1,63 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: jitendra at mistralsolutions.com
+ *
+ * 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 _SUART_UTILS_H_
+#define _SUART_UTILS_H_
+
+#include <linux/types.h>
+
+/* ************ Serializers ***************** */
+#define PRU_SUART_SERIALIZER_0		(0u)
+#define PRU_SUART_SERIALIZER_1		(1u)
+#define PRU_SUART_SERIALIZER_2		(2u)
+#define PRU_SUART_SERIALIZER_3		(3u)
+#define PRU_SUART_SERIALIZER_4		(4u)
+#define PRU_SUART_SERIALIZER_5		(5u)
+#define PRU_SUART_SERIALIZER_6		(6u)
+#define PRU_SUART_SERIALIZER_7		(7u)
+#define PRU_SUART_SERIALIZER_8		(8u)
+#define PRU_SUART_SERIALIZER_9		(9u)
+#define PRU_SUART_SERIALIZER_10		(10u)
+#define PRU_SUART_SERIALIZER_11		(11u)
+#define PRU_SUART_SERIALIZER_12		(12u)
+#define PRU_SUART_SERIALIZER_13		(13u)
+#define PRU_SUART_SERIALIZER_14		(14u)
+#define PRU_SUART_SERIALIZER_15		(15u)
+#define PRU_SUART_SERIALIZER_NONE	(16u)
+
+/* Total number of baud rates supported */
+#define SUART_NUM_OF_BAUDS_SUPPORTED	13
+
+#define MCASP_PDIR_VAL ( \
+	OMAPL_MCASP_PDIR_AFSR_OUTPUT<<OMAPL_MCASP_PDIR_AFSR_SHIFT | \
+	OMAPL_MCASP_PDIR_AHCLKR_OUTPUT<<OMAPL_MCASP_PDIR_AHCLKR_SHIFT | \
+	OMAPL_MCASP_PDIR_ACLKR_OUTPUT<<OMAPL_MCASP_PDIR_ACLKR_SHIFT | \
+	OMAPL_MCASP_PDIR_AFSX_OUTPUT<<OMAPL_MCASP_PDIR_AFSX_SHIFT | \
+	OMAPL_MCASP_PDIR_AHCLKX_OUTPUT<<OMAPL_MCASP_PDIR_AHCLKX_SHIFT | \
+	OMAPL_MCASP_PDIR_ACLKX_OUTPUT<<OMAPL_MCASP_PDIR_ACLKX_SHIFT)
+
+extern void suart_mcasp_config(u32 tx_baud_value,
+			u32 rx_baud_value, u32 oversampling,
+			pruss_suart_iomap *pruss_ioaddr);
+
+extern short suart_asp_baud_set(u32 tx_baud_value,
+			u32 rx_baud_value, u32 oversampling,
+			pruss_suart_iomap *pruss_ioaddr);
+
+extern short suart_asp_serializer_deactivate(u16 u16sr_num,
+			pruss_suart_iomap *pruss_ioaddr);
+
+extern void suart_mcasp_tx_serialzier_set(u32 serializer_num,
+			pruss_suart_iomap *pruss_ioaddr);
+#endif
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 758c5b0..eae37fe 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -202,6 +202,8 @@
 /* VIA VT8500 SoC */
 #define PORT_VT8500	97
 
+#define PORT_DA8XX_PRU_SUART	98
+
 #ifdef __KERNEL__
 
 #include <linux/compiler.h>
-- 
1.7.2.3


From sudhakar.raj at ti.com  Fri Feb 11 08:53:27 2011
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Fri, 11 Feb 2011 20:23:27 +0530
Subject: PREEMPT_RT patches and GPIO (interrupts) problem
In-Reply-To: <AANLkTinKptNSueM221KfGm-gRgx2-oM+AsFaGW4dF+ug@mail.gmail.com>
References: <4D4A779F.8030305@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9C00@dbde02.ent.ti.com>
	<4D51174A.7050504@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9CEE@dbde02.ent.ti.com>
	<4D55012D.8020608@acn-group.ch>
	<B85A65D85D7EB246BE421B3FB0FBB593024894C2D1@dbde02.ent.ti.com>
	<AANLkTinKptNSueM221KfGm-gRgx2-oM+AsFaGW4dF+ug@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024894C46C@dbde02.ent.ti.com>

Hi Ben,

On Fri, Feb 11, 2011 at 20:04:07, Ben Gardiner wrote:
> Hi Sudhakar,
> 
> On Fri, Feb 11, 2011 at 6:03 AM, Rajashekhara, Sudhakar
> <sudhakar.raj at ti.com> wrote:
> > When I enable the "gpio-keys" driver I am getting the below error message when kernel is booting:
> >
> > "gpio-keys gpio-keys.0: Unable to get irq number for GPIO 152, error -6"
> 
> This error looks familiar to me; please excuse me if I presume too much.
> 
> It looks like you may be trying to use the gpio-keys driver on an i2c
> expander.

You are right.

> This driver requires interrupt-capable GPIOs and i2c
> expander GPIOs are not interrupt capable -- yet. The support needed
> for chained interrupts is being developed by Lennert Buytenhek as part
> of the ARM device tree support [1].
> 

Thanks for the information.

> To reproduce Chritophe's problem, try using the L138's GPIOs directly
> in a gpio-keys driver instance.
> 

I'll look into this.

Thanks,
Sudhakar 


From michael.williamson at criticallink.com  Fri Feb 11 09:26:27 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Fri, 11 Feb 2011 10:26:27 -0500
Subject: [PATCH v2 11/13] da850: pruss SUART board specific additions.
In-Reply-To: <1297435892-28278-12-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-12-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D555523.7040507@criticallink.com>

Hi Subhasish,

On 2/11/2011 9:51 AM, Subhasish Ghosh wrote:

> This patch adds the pruss SUART pin mux and registers the device
> with the pruss mfd driver.
> 
> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> ---
>  arch/arm/mach-davinci/board-da850-evm.c |   36 +++++++++++++++++++++++++++++++
>  1 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index f9c38f8..3858516 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1060,6 +1060,25 @@ const short da850_evm_pruss_can_pins[] = {
>  	-1
>  };
>  
> +const short da850_evm_pruss_suart_pins[] = {
> +	DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
> +	DA850_AHCLKR, DA850_ACLKR, DA850_AFSR,
> +	DA850_AXR_13, DA850_AXR_9, DA850_AXR_7,
> +	DA850_AXR_14, DA850_AXR_10, DA850_AXR_8,
> +	-1
> +};
> +


Shouldn't this pins select PRU[0,1]_XXX type functions and not McASP functions?
E.G.: PRU0_R31[17] instead of AHCLKX, PRU0_R31[18] instead of AHCLKR, etc.

> +static int __init da850_evm_setup_pruss_suart(void)
> +{
> +	int ret;
> +
> +	ret = davinci_cfg_reg_list(da850_evm_pruss_suart_pins);
> +	if (ret)
> +		pr_warning("%s: da850_evm_pruss_suart_pins "
> +			"mux setup failed: %d\n", __func__, ret);
> +	return ret;
> +}
> +
>  static int __init da850_evm_setup_pruss_can(void)
>  {
>  	int ret, val = 0;
> @@ -1085,6 +1104,17 @@ static int __init da850_evm_setup_pruss_can(void)
>  	return ret;
>  }
>  
> +static struct da850_evm_pruss_suart_data suart_data = {
> +	.version	= 1,
> +	.resource	= {
> +			.name	= "da8xx_mcasp0_iomem",
> +			.start	= DAVINCI_DA8XX_MCASP0_REG_BASE,
> +			.end	= DAVINCI_DA8XX_MCASP0_REG_BASE +
> +					(SZ_1K * 12) - 1,
> +			.flags	= IORESOURCE_MEM,
> +		},
> +};
> +
>  static struct da8xx_pruss_can_data can_data = {
>  	.version	= 1,
>  };
> @@ -1094,6 +1124,12 @@ static struct da8xx_pruss_devices pruss_devices[] = {
>  		.dev_name	= "da8xx_pruss_can",
>  		.pdata		= &can_data,
>  		.pdata_size	= sizeof(can_data),
> +		.setup		= da850_evm_setup_pruss_suart,


Should this be da850_evm_setup_pruss_can instead?

> +	},
> +	{
> +		.dev_name	= "da8xx_pruss_uart",
> +		.pdata		= &suart_data,
> +		.pdata_size	= sizeof(suart_data),
>  		.setup		= da850_evm_setup_pruss_can,


Should this be da850_evm_setup_pruss_suart instead?

>  	},
>  	{


-Mike


From alan at lxorguk.ukuu.org.uk  Fri Feb 11 10:28:14 2011
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 11 Feb 2011 16:28:14 +0000
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <1297435892-28278-14-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-14-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <20110211162814.6ff274f1@lxorguk.ukuu.org.uk>

Don't see why it needs its own sub-directory



> +#ifdef __SUART_DEBUG
> +#define __suart_debug(fmt, args...) \
> +		printk(KERN_DEBUG "suart_debug: " fmt, ## args)
> +#else
> +#define __suart_debug(fmt, args...)
> +#endif
> +
> +#define  __suart_err(fmt, args...) printk(KERN_ERR "suart_err: " fmt, ## args)

Use dev_dbg/dev_err/pr_debug/pr_err


> +static void omapl_pru_tx_chars(struct omapl_pru_suart *soft_uart, u32 uart_no)
> +{
> +	struct circ_buf *xmit = &soft_uart->port[uart_no].state->xmit;
> +	struct device *dev = soft_uart->dev;
> +	s32 count = 0;
> +
> +	if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
> +		return;
> +
> +	if (down_trylock(&soft_uart->port_sem[uart_no]))
> +		return;

Please use a mutex not a semaphore. We are trying to get almost all the
kernel using mutexes as it is needed for hard real time.


> +		pru_softuart_read_data(dev, &soft_uart->suart_hdl[uart_no],
> +				       suart_data, data_len + 1,
> +				       &data_len_read);
> +
> +		for (i = 0; i <= data_len_read; i++) {
> +			soft_uart->port[uart_no].icount.rx++;
> +			/* check for sys rq */
> +			if (uart_handle_sysrq_char
> +			    (&soft_uart->port[uart_no], suart_data))
> +				continue;
> +		}
> +		/* update the tty data structure */
> +		tty_insert_flip_string(tty, suart_data, data_len_read);

You can avoid a copy here by using tty_prepare_flip_string()

Also please use the tty_port_tty_get/tty_kref_put interfaces so the tty
refcounting is right


> +static void pruss_suart_set_termios(struct uart_port *port,
> +				  struct ktermios *termios,
> +				  struct ktermios *old)
> +{
> +	struct omapl_pru_suart *soft_uart =
> +	    container_of(port, struct omapl_pru_suart, port[port->line]);
> +	struct device *dev = soft_uart->dev;
> +	u8 cval = 0;
> +	unsigned long flags = 0;
> +	u32 baud = 0;
> +	u32 old_csize = old ? old->c_cflag & CSIZE : CS8;
> +
> +/*
> + * Do not allow unsupported configurations to be set
> + */
> +	if (1) {
> +		termios->c_cflag &= ~(HUPCL | CRTSCTS | CMSPAR | CSTOPB
> +				      | PARENB | PARODD | CMSPAR);
> +		termios->c_cflag |= CLOCAL;

No. CLOCAL and HUPCL are user side flags. Apps expect to able to set them
even if in fact they have no effect, so leave those two alone. The rest
is fine.


> +/*
> + * Characteres to ignore

Typo



> diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
> new file mode 100644
> index 0000000..d809dd3
> --- /dev/null
> +++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
> @@ -0,0 +1,2350 @@
> +/*
> + * Copyright (C) 2010 Texas Instruments Incorporated
> + * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
> + *
> + * 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/types.h>
> +#include <linux/mfd/pruss/da8xx_pru.h>
> +#include <linux/io.h>
> +#include <mach/hardware.h>
> +#include "pruss_suart_api.h"
> +#include "pruss_suart_regs.h"
> +#include "pruss_suart_board.h"
> +#include "pruss_suart_utils.h"
> +#include "pruss_suart_err.h"
> +
> +static u8 g_uart_statu_table[8];
Can you lose the g_, its  a windows naming convention we dont use


> +s16 pru_softuart_open(suart_handle h_suart)
> +{

If you just used normal integers you could surely make this routine
trivial and remove all the duplication in the switches

> +	s16 status = PRU_SUART_SUCCESS;

And please stick to Linux error codes


> +/* suart instance close routine */
> +s16 pru_softuart_close(suart_handle h_uart)
> +{
> +	s16 status = SUART_SUCCESS;
> +
> +	if (h_uart == NULL) {
> +		return PRU_SUART_ERR_HANDLE_INVALID;

Which is never checked. Far better to use WARN_ON and the like for such
cases - or if like this one they don't appear to be possible to simply
delete them

> +	if ((tx_clk_divisor > 385) || (tx_clk_divisor == 0))
> +		return SUART_INVALID_CLKDIVISOR;
> +	if ((rx_clk_divisor > 385) || (rx_clk_divisor == 0))
> +		return SUART_INVALID_CLKDIVISOR;

[minor] Lots of excess brackets


> +		u32offset = (u32) (PRUSS_INTC_CHANMAP9 & 0xFFFF);
> +		u32value = PRU_INTC_CHAN_34_SYSEVT_36_39;
> +		s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
> +		if (-1 == s16retval)
> +			return -1;

If you fixed the API here you'd be able to just write

		if (pruss_writel(dev, PRUSS_INTC_CHANMAP9 & 0xFFFF,
				PRU_INTC_BLAH)

or similar which would clean up a lot of messy code and shrink it
dramatically. Given you have lots of series of writes some kind of

	pruss_writel_multi(dev, array, len)

that took an array of addr/value pairs might also clean up a ton of code
and turn it into trivial tables


From sshtylyov at mvista.com  Fri Feb 11 12:41:21 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 11 Feb 2011 21:41:21 +0300
Subject: [PATCH v2 02/13] da850: pruss platform specific additions.
In-Reply-To: <1297435892-28278-3-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-3-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D5582D1.9040005@mvista.com>

Hello.

Subhasish Ghosh wrote:

> This patch adds the platform device and assignes the platform resources
> for the PRUSS mfd driver.

    You also add the PRUSS clock (and I would have done that as a separate patch).

> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>

    You should have noted the patch dependency here -- this patch depends on the 
one nenaming DA8XX_LPSC0_DMAX.

WBR, Sergei

From sshtylyov at mvista.com  Fri Feb 11 12:43:03 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 11 Feb 2011 21:43:03 +0300
Subject: [PATCH v2 03/13] da850: pruss board specific additions.
In-Reply-To: <1297435892-28278-4-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-4-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D558337.2060401@mvista.com>

Subhasish Ghosh wrote:

> This patch adds board specific initializations and setup routines.

> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
[...]

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 11f986b..242d1ed 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1053,6 +1053,26 @@ static __init int da850_evm_init_cpufreq(void)
>  static __init int da850_evm_init_cpufreq(void) { return 0; }
>  #endif
>  
> +static struct da8xx_pruss_devices pruss_devices[] = {
> +	{.dev_name = NULL,},

    No need to explicitly initialize to NULL.

WBR, Sergei


From sshtylyov at mvista.com  Fri Feb 11 12:45:35 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 11 Feb 2011 21:45:35 +0300
Subject: [PATCH v2 06/13] da850: pruss CAN board specific additions.
In-Reply-To: <1297435892-28278-7-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-7-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D5583CF.8010905@mvista.com>

Subhasish Ghosh wrote:

> This patch adds the pruss CAN pin mux and registers the device
> with the pruss mfd driver.

> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
[...]

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 242d1ed..2ce5536 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1053,8 +1053,43 @@ static __init int da850_evm_init_cpufreq(void)
[...]
>  static struct da8xx_pruss_devices pruss_devices[] = {
> -	{.dev_name = NULL,},
> +	{
> +		.dev_name	= "da8xx_pruss_can",
> +		.pdata		= &can_data,
> +		.pdata_size	= sizeof(can_data),
> +		.setup		= da850_evm_setup_pruss_can,
> +	},
> +	{
> +		.dev_name	= NULL,
> +	},

    No need to explicitly initialize to NULL.

WBR, Sergei

From sshtylyov at mvista.com  Fri Feb 11 12:47:49 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 11 Feb 2011 21:47:49 +0300
Subject: [PATCH v2 07/13] da850: pruss CAN platform specific changes for
	gpios.
In-Reply-To: <1297435892-28278-8-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-8-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D558455.8090709@mvista.com>

Hello.

Subhasish Ghosh wrote:

> This patch adds the GPIOs for the pruss CAN device.

> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>

    I still think this patch should be merged with patch 5, and patch 8 with 
patch 6...

WBR, Sergei

From sshtylyov at mvista.com  Fri Feb 11 12:50:20 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 11 Feb 2011 21:50:20 +0300
Subject: [PATCH v2 11/13] da850: pruss SUART board specific additions.
In-Reply-To: <1297435892-28278-12-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-12-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D5584EC.4070506@mvista.com>

Subhasish Ghosh wrote:

> This patch adds the pruss SUART pin mux and registers the device
> with the pruss mfd driver.

> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> ---
>  arch/arm/mach-davinci/board-da850-evm.c |   36 +++++++++++++++++++++++++++++++
>  1 files changed, 36 insertions(+), 0 deletions(-)

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index f9c38f8..3858516 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
[...]
> @@ -1085,6 +1104,17 @@ static int __init da850_evm_setup_pruss_can(void)
>  	return ret;
>  }
>  
> +static struct da850_evm_pruss_suart_data suart_data = {
> +	.version	= 1,
> +	.resource	= {
> +			.name	= "da8xx_mcasp0_iomem",
> +			.start	= DAVINCI_DA8XX_MCASP0_REG_BASE,
> +			.end	= DAVINCI_DA8XX_MCASP0_REG_BASE +
> +					(SZ_1K * 12) - 1,
> +			.flags	= IORESOURCE_MEM,
> +		},
> +};
> +

    I don't think passing a resource thru platform data is good idea... 
Resources should be bound to the platform device.

WBR, Sergei

From sshtylyov at mvista.com  Fri Feb 11 12:55:10 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 11 Feb 2011 21:55:10 +0300
Subject: [PATCH v2 12/13] da850: pruss SUART platform specific additions.
In-Reply-To: <1297435892-28278-13-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-13-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <4D55860E.3090908@mvista.com>

Subhasish Ghosh wrote:

> This patch adds the McASP clock alias.
> The alias is used by the pruss suart driver
> for enabling the McASP PSC.

> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
[...]

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index e15de72..f1cf605 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -560,7 +560,18 @@ struct platform_device da8xx_pruss_dev = {
>  
>  int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
>  {
> +#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE

    #ifdef's in the function body are generally fromned upon.

> +	int ret;
> +#endif
> +

    This line should have been inside #ifdef...

>  	da8xx_pruss_dev.dev.platform_data = pruss_device;
> +
> +#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE

    Why not do it before assigning the platform data and avoid extra #ifdef?

> +	ret = clk_add_alias(NULL, "da8xx_pruss_uart.1",
> +	NULL, &da850_mcasp_device.dev);

    This line should be indented more to the right.

> +	if (ret < 0)
> +		return ret;
> +#endif

WBR, Sergei

From lamiaposta71 at gmail.com  Sat Feb 12 08:02:17 2011
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Sat, 12 Feb 2011 15:02:17 +0100
Subject: TI DaVinci support under new maintainer: Sekhar Nori
In-Reply-To: <87pqr2kx9d.fsf@ti.com>
References: <87pqr2kx9d.fsf@ti.com>
Message-ID: <AANLkTinhOXBkQ+Tg+Tt5PSx6fKgTq5cAR84CLUH7ESys@mail.gmail.com>

Hi Kevin,

On Tue, Feb 8, 2011 at 10:54 PM, Kevin Hilman <khilman at ti.com> wrote:
> Hello,
>
> I will be stepping aside as maintainer of the TI DaVinci family of
> SoCs and Sekhar Nori from TI will be taking over these responsibilities.
>
> Sekhar has long been an active developer, primary contributor and
> reviewer so taking over the maintainer role is a logical next step for
> him.
>
> I will aid in the transition for a couple merge windows to help make a
> smooth transition, but will be fading away from an active role in
> davinci.

Your help has been very useful in the past to guide me to achieve a
small community role..
I can understand that you have new interests.
I think that Nori Sekhar has a deep experience and I'm happy for this decision.
See you in some other ml.

bye,
Raffaele
Raffaele

From lamiaposta71 at gmail.com  Sat Feb 12 08:11:23 2011
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Sat, 12 Feb 2011 15:11:23 +0100
Subject: dm365 support
Message-ID: <AANLkTimkzH+z56V_7tmQYLNXeR15ObfMtNXTPrHureC8@mail.gmail.com>

I'd like to know if anybody has interest in the following projects:

https://bticino at github.com/bticino/bubl.git
bubl: a replacement of ubl
booting from SPI, running u-boot from eMMC, from UART loader in SREC
format or from NAND (next future), ubl mmc drivers taken from u-boot,
clean pll setup.
Plannig to launch the linux kernel directly.

A dvsdk401 2.6.32.17 PSP linux kernel with ASoC, voide codec, and more ..
https://bticino at github.com/bticino/linux.git

Bye,
Raffaele
-- 
www.opensurf.it

From chtpatil at gmail.com  Sat Feb 12 11:32:51 2011
From: chtpatil at gmail.com (chetan patil)
Date: Sat, 12 Feb 2011 23:02:51 +0530
Subject: UART
Message-ID: <AANLkTi=CWZR+=U1hfO2fY6mngTZ_3-k6F=1YcEJV6RD_@mail.gmail.com>

Hi,

    Is it possible to use UART0 and UART1 simultaneously.???
I want to use UART0 for minicom and other one to run my module
which i have designed.

Not able to find any configure option in kernel after doing make menuconfig.

Please suggest possible ways!

Thanks in advance

-- 
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/20110212/154f21bd/attachment.html>

From const at makelinux.com  Sun Feb 13 17:00:33 2011
From: const at makelinux.com (Constantine Shulyupin)
Date: Mon, 14 Feb 2011 01:00:33 +0200
Subject: Please help to run XIP kernel
Message-ID: <AANLkTi=k1TCjuRH=W1E4oD58Q-YA2SgqAaZ-LJ8zm3kf@mail.gmail.com>

Hi,

Please help to run XIP kernel on dm6446 with NOR flash.

I do
compile kernels: linux-2.6.10  (DVSDK 1_20_00_014)  linux-2.6.18
(DVSDK 02_00_00_140),  linux-2.6.37
With
CONFIG_XIP_KERNEL=y
CONFIG_XIP_PHYS_ADDR=0x02300000

Flash with:

tftp 0x80700000 xipImage;
protect off 0x02300000 +0x$(filesize);erase 0x02300000
+0x$(filesize);cp.b 0x80700000 0x02300000 0x$(filesize);protect on
0x02300000 +0x$(filesize)

Run with
go 0x02300000
And the processor hangs.

What is the problem?

Thanks.
-- 
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci

From subhasish at mistralsolutions.com  Sun Feb 13 22:54:48 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Mon, 14 Feb 2011 10:24:48 +0530
Subject: [PATCH v2 09/13] can: pruss CAN driver.
In-Reply-To: <20110211150602.GB373@e-circ.dyndns.org>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>
	<20110211150602.GB373@e-circ.dyndns.org>
Message-ID: <C1C4300CE90A406FBDA2388D5491FAD5@subhasishg>

Hello,

I had a discussion regarding this with Wolfgang:

http://www.mail-archive.com/socketcan-users at lists.berlios.de/msg00324.html

The problem here is that we must configure the mailbox ID's and this support 
is not available in the socketCan sub-system.

--------------------------------------------------
From: "Kurt Van Dijck" <kurt.van.dijck at eia.be>
Sent: Friday, February 11, 2011 8:36 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>; 
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "Wolfgang Grandegger" 
<wg at grandegger.com>; "open list:CAN NETWORK DRIVERS" 
<socketcan-core at lists.berlios.de>; "open list:CAN NETWORK DRIVERS" 
<netdev at vger.kernel.org>; "open list" <linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.

> On Fri, Feb 11, 2011 at 08:21:28PM +0530, Subhasish Ghosh wrote:
>> +config DA8XX_PRU_CANID_MBX0
>> + hex "CANID for mailbox 0"
>> + depends on CAN_TI_DA8XX_PRU
>> + default "0x123"
>> + ---help---
>> + Enter the CANID for mailbox 0
>> + Default value is set to 0x123, change this as required.
>> +
>> +config DA8XX_PRU_CANID_MBX1
>> + hex "CANID for mailbox 1"
>> + depends on CAN_TI_DA8XX_PRU
>> + default "0x123"
>> + ---help---
>> + Enter the CANID for mailbox 1
>> + Default value is set to 0x123, change this as required.
>> +
>> +config DA8XX_PRU_CANID_MBX2
>> + hex "CANID for mailbox 2"
>> + depends on CAN_TI_DA8XX_PRU
>> + default "0x123"
>> + ---help---
>> + Enter the CANID for mailbox 2
>> + Default value is set to 0x123, change this as required.
>> +
>> +config DA8XX_PRU_CANID_MBX3
>> + hex "CANID for mailbox 3"
>> + depends on CAN_TI_DA8XX_PRU
>> + default "0x123"
>> + ---help---
>> + Enter the CANID for mailbox 3
>> + Default value is set to 0x123, change this as required.
>> +
>> +config DA8XX_PRU_CANID_MBX4
>> + hex "CANID for mailbox 4"
>> + depends on CAN_TI_DA8XX_PRU
>> + default "0x123"
>> + ---help---
>> + Enter the CANID for mailbox 4
>> + Default value is set to 0x123, change this as required.
>> +
>> +config DA8XX_PRU_CANID_MBX5
>> + hex "CANID for mailbox 5"
>> + depends on CAN_TI_DA8XX_PRU
>> + default "0x123"
>> + ---help---
>> + Enter the CANID for mailbox 5
>> + Default value is set to 0x123, change this as required.
>> +
>> +config DA8XX_PRU_CANID_MBX6
>> + hex "CANID for mailbox 6"
>> + depends on CAN_TI_DA8XX_PRU
>> + default "0x123"
>> + ---help---
>> + Enter the CANID for mailbox 6
>> + Default value is set to 0x123, change this as required.
>> +
>> +config DA8XX_PRU_CANID_MBX7
>> + hex "CANID for mailbox 7"
>> + depends on CAN_TI_DA8XX_PRU
>> + default "0x123"
>> + ---help---
>> + Enter the CANID for mailbox 7
>> + Default value is set to 0x123, change this as required.
> Why is filling the mailboxes the job of kernel config?
>
> Regards,
> Kurt 


From subhasish at mistralsolutions.com  Mon Feb 14 02:45:06 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Mon, 14 Feb 2011 14:15:06 +0530
Subject: [PATCH v2 09/13] can: pruss CAN driver.
In-Reply-To: <4D58D854.5090503@grandegger.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>
	<20110211150602.GB373@e-circ.dyndns.org>
	<C1C4300CE90A406FBDA2388D5491FAD5@subhasishg>
	<4D58D854.5090503@grandegger.com>
Message-ID: <1F33D30F9B2D47ECA80CEC807A6C0727@subhasishg>

That is correct, we receive only pre-programmed CAN ids and "all" or "range" 
implementation is not there in the PRU firmware.
Will check the sysfs option and update.

--------------------------------------------------
From: "Wolfgang Grandegger" <wg at grandegger.com>
Sent: Monday, February 14, 2011 12:53 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: "Kurt Van Dijck" <kurt.van.dijck at eia.be>; 
<davinci-linux-open-source at linux.davincidsp.com>; 
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>; 
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "open list:CAN NETWORK 
DRIVERS" <socketcan-core at lists.berlios.de>; "open list:CAN NETWORK DRIVERS" 
<netdev at vger.kernel.org>; "open list" <linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.

> On 02/14/2011 05:54 AM, Subhasish Ghosh wrote:
>> Hello,
>>
>> I had a discussion regarding this with Wolfgang:
>>
>> http://www.mail-archive.com/socketcan-users at lists.berlios.de/msg00324.html
>>
>> The problem here is that we must configure the mailbox ID's and this
>> support is not available in the socketCan sub-system.
>
> To understand you correctly. A mailbox (or message object) can *only*
> receive messages with the pre-programmed CAN id? Isn't there a chance to
> receive all or a range of CAN ids? That's a very unusual piece of
> hardware. Anyway, using kernel configuration parameters to define the
> CAN id's would be the less flexible method. The user will not have a
> chance to change them at run-time. Using SysFS files would already be
> much better.
>
> Wolfgang. 


From subhasish at mistralsolutions.com  Mon Feb 14 07:15:17 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Mon, 14 Feb 2011 18:45:17 +0530
Subject: [PATCH v2 09/13] can: pruss CAN driver.
In-Reply-To: <4D58F77B.9080005@pengutronix.de>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>
	<20110211150602.GB373@e-circ.dyndns.org>
	<C1C4300CE90A406FBDA2388D5491FAD5@subhasishg>
	<4D58D854.5090503@grandegger.com>
	<1F33D30F9B2D47ECA80CEC807A6C0727@subhasishg>
	<4D58F77B.9080005@pengutronix.de>
Message-ID: <8CB9F2C8F75C4041B9F0691D209DDAFD@subhasishg>

Hello,

The problem with the "all" implementation is that it hogs the ARM/DSP 
heavily and that's the reason why we specifically avoided this in our 
firmware design.
Hence, implementing this condition spoils the whole purpose of the PRU!!

--------------------------------------------------
From: "Marc Kleine-Budde" <mkl at pengutronix.de>
Sent: Monday, February 14, 2011 3:05 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: "Wolfgang Grandegger" <wg at grandegger.com>; "Kurt Van Dijck" 
<kurt.van.dijck at eia.be>; <davinci-linux-open-source at linux.davincidsp.com>; 
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>; 
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "open list:CAN NETWORK 
DRIVERS" <socketcan-core at lists.berlios.de>; "open list:CAN NETWORK DRIVERS" 
<netdev at vger.kernel.org>; "open list" <linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.

Hello,

On 02/14/2011 09:45 AM, Subhasish Ghosh wrote:
> That is correct, we receive only pre-programmed CAN ids and "all" or
> "range" implementation is not there in the PRU firmware.

I'd really like to see that you add a "all" implementation to the
firmware. Or even better use the standard id/mask approach.

cheers, Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   | 


From gilles.chanteperdrix at nexvision.fr  Mon Feb 14 09:04:34 2011
From: gilles.chanteperdrix at nexvision.fr (Gilles Chanteperdrix)
Date: Mon, 14 Feb 2011 16:04:34 +0100
Subject: Intermittent SD write corruption on DM355, kernel 2.6.36
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE093F9AEA5C@Cloud.RL.local>
References: <70E876B0EA86DD4BAF101844BC814DFE093F9AEA5C@Cloud.RL.local>
Message-ID: <4D594482.70806@nexvision.fr>

Jon Povey wrote:
>>>>> Jon Povey wrote:
>>>>>> I am seeing rare SD card write corruption on DM355
> 
> I think I have a fix for this now - just CC'd you on the patch RFC
> 
> [RFC] mmc: davinci: fix corruption after surprise card eject
> 
> (Which fixes it, but may not be the best way of going about it).

Tested on DM368, where this appears to fix the issue as well.

-- 
Gilles Chanteperdrix
NexVision, http://www.nexvision.fr
Office: 99, av Clot-Bey, 13008 Marseille, France
Phone: +33 (0)4 91 77 62 87 / Fax: +33 (0)4 91 77 64 10

From nsekhar at ti.com  Tue Feb 15 06:41:03 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 15 Feb 2011 18:11:03 +0530
Subject: DM365 deep sleep
In-Reply-To: <4D553D78.3000404@ridgerun.com>
References: <AANLkTimHkbbX-T-WZzhdoM8Ti=_oYTBAUH2cF924F-ay@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B6B8@dbde02.ent.ti.com>
	<AANLkTi=YANecdwwze3szZTsSX23+hMLGOQTCgihTAaGz@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024880B943@dbde02.ent.ti.com>
	<AANLkTimD_DA9pvXL3x4nRe0h5eeaVtuGGGa_W4EL7EQb@mail.gmail.com>
	<4D4C697F.2080400@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024894B7B5@dbde02.ent.ti.com>
	<4D52FBCF.3040702@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024894BFDC@dbde02.ent.ti.com>
	<4D553D78.3000404@ridgerun.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930248A01826@dbde02.ent.ti.com>

Hi Todd,

On Fri, Feb 11, 2011 at 19:15:28, Todd Fischer wrote:
> Sekhar,
> 
> What is the status for deep sleep support on the DM365?  If it is 
> available, where can I find it?  If not available, I was planning on 

AFAIK, DeepSleep support is not available on DM365. I am also
not aware of anyone working on it.

> starting adding DM365 deep sleep support using the mach-davinci pm.c and 
> sleep.S code from the latest davinci-linux git repo unless you have 
> another suggestion.

Yes, that's a good idea. Thanks for taking this up.

Thanks,
Sekhar


From steve at fl-eng.com  Tue Feb 15 21:01:40 2011
From: steve at fl-eng.com (steve spano)
Date: Tue, 15 Feb 2011 22:01:40 -0500
Subject: ### OSD Vanish/Disabled
Message-ID: <a00c0dce751f445bdf15ca2ec0dcf619.squirrel@webmail.fl-eng.com>

Hi

I have an odd issue. We are using a modified version of encode/decode app.
The encode/decode process/etc works fine, but the OSD layer seems to
become disabled after 10-20 minutes, or after some random time period.
The OSD0 ACT bit in the OSD0 control register actually becomes set to '0'
so the OSD stops. We have to manually poll this bit and then set it back
to'1' which restarts the OSD but it causes an awful flicker on the screen.
Has anyone seen this issue? I cannot seem to find where in the
drivers/code/etc this OSD0 active bit could be getting set back to '0'.

Please advise....

Thanks




From sudhakar.raj at ti.com  Wed Feb 16 05:49:00 2011
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Wed, 16 Feb 2011 17:19:00 +0530
Subject: [PATCH v4 1/2] mtd: NOR flash driver for OMAP-L137/AM17x
In-Reply-To: <1291261815.14534.14.camel@koala>
References: <1291111325-25784-1-git-send-email-savinay.dharmappa@ti.com>
	<1291261815.14534.14.camel@koala>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB5930248AAF048@dbde02.ent.ti.com>

Hi,

On Thu, Dec 02, 2010 at 09:20:15, Artem Bityutskiy wrote:
> On Tue, 2010-11-30 at 15:32 +0530, Savinay Dharmappa wrote:
> > From: David Griego <dgriego at mvista.com>
> > 
> > OMAP-L137/AM17x has limited number of dedicated EMIFA address pins, 
> > enough to interface directly to an SDRAM.
> > If a device such as an asynchronous flash needs to be attached to the 
> > EMIFA, then either GPIO pins or a chip select may be used to control 
> > the flash device's upper address lines.
> > 
> > This patch adds support for the NOR flash on the OMAP-L137/ AM17x user 
> > interface daughter board using the latch-addr-flash MTD mapping driver 
> > which allows flashes to be partially physically addressed. The upper 
> > address lines are set by a board specific code which is a separate 
> > patch.
> > 
> > Signed-off-by: David Griego <dgriego at mvista.com>
> > Signed-off-by: Aleksey Makarov <amakarov at ru.mvista.com>
> > Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
> > Signed-off-by: Savinay Dharmappa <savinay.dharmappa at ti.com>
> 
> Pushed these to l2-mtd-2.6.git, thanks.
> 

I do not see these patches in Linus's tree [1] or at l2-mtd-2.6.git tree [2].
Is there any tree where these patches are available?

[1] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
[2] git://git.infradead.org/users/dedekind/l2-mtd-2.6.git

Thanks,
Sudhakar

From c.aeschlimann at acn-group.ch  Wed Feb 16 08:07:57 2011
From: c.aeschlimann at acn-group.ch (Christophe Aeschlimann)
Date: Wed, 16 Feb 2011 15:07:57 +0100
Subject: ALSA issue on DA850/OMAP-L138/AM18x
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302484734E0@dbde02.ent.ti.com>
References: <B85A65D85D7EB246BE421B3FB0FBB59302484734E0@dbde02.ent.ti.com>
Message-ID: <4D5BDA3D.5080905@acn-group.ch>

Hi Sudhakar,

On 18.01.2011 05:43, Rajashekhara, Sudhakar wrote:

[...]

 > With the above fixes, arecord and aplay does not work for the first time.
 > Couple of times I get the below error:
 >
 > root at da850-omapl138-evm:~# arecord -f dat | aplay -f dat
 > arecord: main:608: audio open error: Invalid argument
 > aplay: playback:2297: read error
 > root at da850-omapl138-evm:~# arecord -f dat | aplay -f dat
 > aplay: main:608: audio open error: Invalid argument
 > Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, 
Stereo
 >
 > Third time arecord and aplay work normally.
 >
 > Has anyone seen such issues on DA850 or any other platform?
 >
 > I am currently debugging this issue. I'll submit the above patch to 
community
 > once the issue of fixed.

I'm facing the same issue here.

Did you make any progress on that one ?

 > Regards,
 > Sudhakar

Regards,

Christophe

From sudhakar.raj at ti.com  Wed Feb 16 22:23:40 2011
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Thu, 17 Feb 2011 09:53:40 +0530
Subject: ALSA issue on DA850/OMAP-L138/AM18x
In-Reply-To: <4D5BDA3D.5080905@acn-group.ch>
References: <B85A65D85D7EB246BE421B3FB0FBB59302484734E0@dbde02.ent.ti.com>
	<4D5BDA3D.5080905@acn-group.ch>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024B83B5E4@dbde02.ent.ti.com>

Hi Christophe,

On Wed, Feb 16, 2011 at 19:37:57, Christophe Aeschlimann wrote:
> Hi Sudhakar,
> 
> On 18.01.2011 05:43, Rajashekhara, Sudhakar wrote:
> 
> [...]
> 
>  > With the above fixes, arecord and aplay does not work for the first time.
>  > Couple of times I get the below error:
>  >
>  > root at da850-omapl138-evm:~# arecord -f dat | aplay -f dat
>  > arecord: main:608: audio open error: Invalid argument
>  > aplay: playback:2297: read error
>  > root at da850-omapl138-evm:~# arecord -f dat | aplay -f dat
>  > aplay: main:608: audio open error: Invalid argument
>  > Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, 
> Stereo
>  >
>  > Third time arecord and aplay work normally.
>  >
>  > Has anyone seen such issues on DA850 or any other platform?
>  >
>  > I am currently debugging this issue. I'll submit the above patch to 
> community
>  > once the issue of fixed.
> 
> I'm facing the same issue here.
> 
> Did you make any progress on that one ?
> 

Reverting the commit 140176159597ea1f23dcccb47b5c38fdf7c7faa8 
(ASoC: Configure symmetric rates for tlv320aic3x) resolves the issue. We are
still working on the proper fix.

Thanks,
Sudhakar 


From gasparini at imavis.com  Thu Feb 17 10:25:29 2011
From: gasparini at imavis.com (Andrea Gasparini)
Date: Thu, 17 Feb 2011 17:25:29 +0100
Subject: ipipe driver
Message-ID: <201102171725.29916.gasparini@imavis.com>

Hi,
is there any plan to port IPIPE driver to the mainline kernel?
i.e. if I want to use the latest git kernel, it'd be reasonable that I will 
see an IPIPE driver in the near future?

thanks, bye!
-- 
Andrea Gasparini 
---- ImaVis S.r.l. ----
web: www.imavis.com

From rohan_javed at yahoo.co.uk  Thu Feb 17 11:37:03 2011
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Thu, 17 Feb 2011 17:37:03 +0000 (GMT)
Subject: LAN9313 support
Message-ID: <69212.47438.qm@web24108.mail.ird.yahoo.com>

We are using LAN9313 switch with our custom board DM6446 can anyone tell  is 
there any support for it in the kernel.I have seen the source there  is no 
support for this chip.

Can anyone help in getting started 


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

From rohan_javed at yahoo.co.uk  Thu Feb 17 23:47:55 2011
From: rohan_javed at yahoo.co.uk (rohan tabish)
Date: Fri, 18 Feb 2011 05:47:55 +0000 (GMT)
Subject: Fw: [ERR] LAN9313 support
Message-ID: <26328.73598.qm@web24106.mail.ird.yahoo.com>





      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110218/e4fe74c3/attachment.html>
-------------- next part --------------
An embedded message was scrubbed...
From: rohan tabish <rohan_javed at yahoo.co.uk>
Subject: LAN9313 support
Date: Thu, 17 Feb 2011 17:37:03 +0000 (GMT)
Size: 7011
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110218/e4fe74c3/attachment.mht>

From subhasish at mistralsolutions.com  Fri Feb 18 01:07:31 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 12:37:31 +0530
Subject: [PATCH v2 09/13] can: pruss CAN driver.
In-Reply-To: <20110211152026.GC373@e-circ.dyndns.org>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>
	<20110211152026.GC373@e-circ.dyndns.org>
Message-ID: <32A5399EB727427C98185089E5DBFA65@subhasishg>

--------------------------------------------------
From: "Kurt Van Dijck" <kurt.van.dijck at eia.be>
Sent: Friday, February 11, 2011 8:50 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>; 
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "Wolfgang Grandegger" 
<wg at grandegger.com>; "open list:CAN NETWORK DRIVERS" 
<socketcan-core at lists.berlios.de>; "open list:CAN NETWORK DRIVERS" 
<netdev at vger.kernel.org>; "open list" <linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.

> Hi,
>
> I looked a bit at the TX path:
>
> On Fri, Feb 11, 2011 at 08:21:28PM +0530, Subhasish Ghosh wrote:
>> +static int omapl_pru_can_set_bittiming(struct net_device *ndev)
>> +{
>> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
>> + struct can_bittiming *bt = &priv->can.bittiming;
>> + long bit_error = 0;
>> +
>> + if (priv->can.ctrlmode & CAN_CTRLMODE_3_SAMPLES) {
>> + dev_warn(priv->dev, "WARN: Triple"
>> + "sampling not set due to h/w limitations");
> You should not have enabled CAN_CTRLMODE_3_SAMPLES in the first place?

SG - Ok Will remove.
>> + }
>> + if (pru_can_calc_timing(priv->dev, priv->can.clock.freq,
>> + bt->bitrate) != 0)
>> + return -EINVAL;
>> + bit_error =
>> +     (((priv->timer_freq / (priv->timer_freq / bt->bitrate)) -
>> +       bt->bitrate) * 1000) / bt->bitrate;
>> + if (bit_error) {
>> + bit_error =
>> +     (((priv->timer_freq / (priv->timer_freq / bt->bitrate)) -
>> +       bt->bitrate) * 1000000) / bt->bitrate;
>> + printk(KERN_INFO "\nBitrate error %ld.%ld%%\n",
>> + bit_error / 10000, bit_error % 1000);
>> + } else
>> + printk(KERN_INFO "\nBitrate error 0.0%%\n");
>> +
>> + return 0;
>> +}
> I wonder how much of this code is duplicated from drivers/net/can/dev.c ?
SG - Well, I just followed ti_hecc.c :-)

>
>> +static netdev_tx_t omapl_pru_can_start_xmit(struct sk_buff *skb,
>> +     struct net_device *ndev)
>> +{
>> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
>> + struct can_frame *cf = (struct can_frame *)skb->data;
>> + int count;
>> + u8 *data = cf->data;
>> + u8 dlc = cf->can_dlc;
>> + u8 *ptr8data = NULL;
>> +
> most drivers start with:
> if (can_dropped_invalid_skb(dev, skb))
> return NETDEV_TX_OK;

SG - Will do.
>
>> + netif_stop_queue(ndev);
> why would you stop when you just resumed the queue?

SG - I do not want more than one transmit request at one time. Hence, on 
entering the transmit
I am using netif_stop_queue to disable tx.

>> + if (cf->can_id & CAN_EFF_FLAG) /* Extended frame format */
>> + *((u32 *) &priv->can_tx_hndl.strcanmailbox) =
>> +     (cf->can_id & CAN_EFF_MASK) | PRU_CANMID_IDE;
>> + else /* Standard frame format */
>> + *((u32 *) &priv->can_tx_hndl.strcanmailbox) =
>> +     (cf->can_id & CAN_SFF_MASK) << 18;
>> +
>> + if (cf->can_id & CAN_RTR_FLAG) /* Remote transmission request */
>> + *((u32 *) &priv->can_tx_hndl.strcanmailbox) |= CAN_RTR_FLAG;
>> +
>> + ptr8data = &priv->can_tx_hndl.strcanmailbox.u8data7 + (dlc - 1);
>> + for (count = 0; count < (u8) dlc; count++) {
>> + *ptr8data-- = *data++;
>> + }
>> + *((u32 *) &priv->can_tx_hndl.strcanmailbox.u16datalength) = (u32) dlc;
>> +/*
>> + * search for the next available mbx
>> + * if the next mbx is busy, then try the next + 1
>> + * do this until the head is reached.
>> + * if still unable to tx, stop accepting any packets
>> + * if able to tx and the head is reached, then reset next to tail, i.e 
>> mbx0
>> + * if head is not reached, then just point to the next mbx
>> + */
>> + for (; priv->tx_next <= priv->tx_head; priv->tx_next++) {
>> + priv->can_tx_hndl.ecanmailboxnumber =
>> +     (can_mailbox_number) priv->tx_next;
>> + if (-1 == pru_can_write_data_to_mailbox(priv->dev,
>> + &priv->can_tx_hndl)) {
>> + if (priv->tx_next == priv->tx_head) {
>> + priv->tx_next = priv->tx_tail;
>> + if (!netif_queue_stopped(ndev))
> If you get here, the queue is not stopped. This test is therefore useless.

SG -Ok, will remove
>> + netif_stop_queue(ndev); /* IF stalled */
>> + dev_err(priv->dev,
>> + "%s: no tx mbx available", __func__);
>> + return NETDEV_TX_BUSY;
>> + } else
>> + continue;
>> + } else {
>> + /* set transmit request */
>> + pru_can_tx(priv->dev, priv->tx_next, CAN_TX_PRU_1);
>> + pru_can_tx_mode_set(priv->dev, false, ecanreceive);
>> + pru_can_tx_mode_set(priv->dev, true, ecantransmit);
>> + pru_can_start_abort_tx(priv->dev, PRU_CAN_START);
>> + priv->tx_next++;
>> + can_put_echo_skb(skb, ndev, 0);
>> + break;
>> + }
>> + }
>> + if (priv->tx_next > priv->tx_head) {
>> + priv->tx_next = priv->tx_tail;
>> + }
>> + return NETDEV_TX_OK;
>> +}
>> +
>> +
>
>> +irqreturn_t omapl_tx_can_intr(int irq, void *dev_id)
>> +{
>> + struct net_device *ndev = dev_id;
>> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
>> + struct net_device_stats *stats = &ndev->stats;
>> + u32 bit_set, mbxno;
>> +
>> + pru_can_get_intr_status(priv->dev, &priv->can_tx_hndl);
>> + if ((PRU_CAN_ISR_BIT_CCI & priv->can_tx_hndl.u32interruptstatus)
>> +     || (PRU_CAN_ISR_BIT_SRDI & priv->can_tx_hndl.u32interruptstatus)) {
>> + __can_debug("tx_int_status = 0x%X\n",
>> +     priv->can_tx_hndl.u32interruptstatus);
>> + can_free_echo_skb(ndev, 0);
>> + } else {
>> + for (bit_set = 0; ((priv->can_tx_hndl.u32interruptstatus & 0xFF)
>> + >> bit_set != 0); bit_set++)
>> + ;
>> + if (0 == bit_set) {
>> + __can_err("%s: invalid mailbox number\n", __func__);
>> + can_free_echo_skb(ndev, 0);
>> + } else {
>> + mbxno = bit_set - 1; /* mail box numbering starts from 0 */
>> + if (PRU_CAN_ISR_BIT_ESI & priv->can_tx_hndl.
>> +     u32interruptstatus) {
>> + /* read gsr and ack pru */
>> + pru_can_get_global_status(priv->dev, &priv->can_tx_hndl);
>> + omapl_pru_can_err(ndev,
>> +   priv->can_tx_hndl.
>> +   u32interruptstatus,
>> +   priv->can_tx_hndl.
>> +   u32globalstatus);
>> + } else {
>> + stats->tx_packets++;
>> + /* stats->tx_bytes += dlc; */
>> + /*can_get_echo_skb(ndev, 0);*/
>> + }
>> + }
>> + }
>> + if (netif_queue_stopped(ndev))
> you can call netif_wake_queue(ndev) multiple times, so there is no need
> for netif_queue_stopped()

SG -Ok, will remove

>> + netif_wake_queue(ndev);
>> +
>> + can_get_echo_skb(ndev, 0);
>> + pru_can_tx_mode_set(priv->dev, true, ecanreceive);
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int omapl_pru_can_open(struct net_device *ndev)
>> +{
>> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
>> + int err;
>> +
>> + /* register interrupt handler */
>> + err = request_irq(priv->trx_irq, &omapl_rx_can_intr, IRQF_SHARED,
>> +   "pru_can_irq", ndev);
> you're doing a lot of work _in_ the irq handler. Maybe threaded irq?
>
SG -Ok, will do

>> +static int omapl_pru_can_close(struct net_device *ndev)
>> +{
>> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
>> +
>> + if (!netif_queue_stopped(ndev))
> check is not needed.

SG -Ok, will remove

>> + netif_stop_queue(ndev);
>> +
>> + close_candev(ndev);
>> +
>> + free_irq(priv->trx_irq, ndev);
>> + return 0;
>> +}
>> +
>
> Regards,
> Kurt 


From subhasish at mistralsolutions.com  Fri Feb 18 01:13:32 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 12:43:32 +0530
Subject: [PATCH v2 11/13] da850: pruss SUART board specific additions.
In-Reply-To: <4D555523.7040507@criticallink.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-12-git-send-email-subhasish@mistralsolutions.com>
	<4D555523.7040507@criticallink.com>
Message-ID: <B7287DA9F96B436894703FF6663F1E13@subhasishg>

--------------------------------------------------
From: "Michael Williamson" <michael.williamson at criticallink.com>
Sent: Friday, February 11, 2011 8:56 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<sachi at mistralsolutions.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Kevin Hilman" <khilman at deeprootsystems.com>; "open list" 
<linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 11/13] da850: pruss SUART board specific additions.

> Hi Subhasish,
>
> On 2/11/2011 9:51 AM, Subhasish Ghosh wrote:
>
>> This patch adds the pruss SUART pin mux and registers the device
>> with the pruss mfd driver.
>>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
>> ---
>>  arch/arm/mach-davinci/board-da850-evm.c |   36 
>> +++++++++++++++++++++++++++++++
>>  1 files changed, 36 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
>> b/arch/arm/mach-davinci/board-da850-evm.c
>> index f9c38f8..3858516 100644
>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
>> @@ -1060,6 +1060,25 @@ const short da850_evm_pruss_can_pins[] = {
>>  -1
>>  };
>>
>> +const short da850_evm_pruss_suart_pins[] = {
>> + DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
>> + DA850_AHCLKR, DA850_ACLKR, DA850_AFSR,
>> + DA850_AXR_13, DA850_AXR_9, DA850_AXR_7,
>> + DA850_AXR_14, DA850_AXR_10, DA850_AXR_8,
>> + -1
>> +};
>> +
>
>
> Shouldn't this pins select PRU[0,1]_XXX type functions and not McASP 
> functions?
> E.G.: PRU0_R31[17] instead of AHCLKX, PRU0_R31[18] instead of AHCLKR, etc.
>

SG - The Soft-UART implementation uses the McASP as shift registers to push 
out the data sequentially.
            Hence, we configure the McASP PINS and not the PRU PINS.

>> +static int __init da850_evm_setup_pruss_suart(void)
>> +{
>> + int ret;
>> +
>> + ret = davinci_cfg_reg_list(da850_evm_pruss_suart_pins);
>> + if (ret)
>> + pr_warning("%s: da850_evm_pruss_suart_pins "
>> + "mux setup failed: %d\n", __func__, ret);
>> + return ret;
>> +}
>> +
>>  static int __init da850_evm_setup_pruss_can(void)
>>  {
>>  int ret, val = 0;
>> @@ -1085,6 +1104,17 @@ static int __init da850_evm_setup_pruss_can(void)
>>  return ret;
>>  }
>>
>> +static struct da850_evm_pruss_suart_data suart_data = {
>> + .version = 1,
>> + .resource = {
>> + .name = "da8xx_mcasp0_iomem",
>> + .start = DAVINCI_DA8XX_MCASP0_REG_BASE,
>> + .end = DAVINCI_DA8XX_MCASP0_REG_BASE +
>> + (SZ_1K * 12) - 1,
>> + .flags = IORESOURCE_MEM,
>> + },
>> +};
>> +
>>  static struct da8xx_pruss_can_data can_data = {
>>  .version = 1,
>>  };
>> @@ -1094,6 +1124,12 @@ static struct da8xx_pruss_devices pruss_devices[] 
>> = {
>>  .dev_name = "da8xx_pruss_can",
>>  .pdata = &can_data,
>>  .pdata_size = sizeof(can_data),
>> + .setup = da850_evm_setup_pruss_suart,
>
>
> Should this be da850_evm_setup_pruss_can instead?

SG - This just the way the patch is displayed. In the code the order is 
correct.

>
>> + },
>> + {
>> + .dev_name = "da8xx_pruss_uart",
>> + .pdata = &suart_data,
>> + .pdata_size = sizeof(suart_data),
>>  .setup = da850_evm_setup_pruss_can,
>
>
> Should this be da850_evm_setup_pruss_suart instead?
SG - Ditto
>
>>  },
>>  {
>
>
> -Mike
> 

From subhasish at mistralsolutions.com  Fri Feb 18 01:18:30 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 12:48:30 +0530
Subject: [PATCH v2 02/13] da850: pruss platform specific additions.
In-Reply-To: <4D5582D1.9040005@mvista.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-3-git-send-email-subhasish@mistralsolutions.com>
	<4D5582D1.9040005@mvista.com>
Message-ID: <6C4C94BAB9814DDB9D0500AF2BA1A319@subhasishg>

--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov at mvista.com>
Sent: Saturday, February 12, 2011 12:11 AM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>; 
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "Kevin Hilman (supporter:TI 
DAVINCI MACHIN...,commit_signer:16/18=89%)" <khilman at deeprootsystems.com>; 
"Russell King (maintainer:ARM PORT)" <linux at arm.linux.org.uk>; "Michael 
Williamson (commit_signer:5/18=28%)" <michael.williamson at criticallink.com>; 
"Cyril Chemparathy (commit_signer:3/18=17%)" <cyril at ti.com>; "Sergei 
Shtylyov (commit_signer:3/18=17%)" <sshtylyov at ru.mvista.com>; "open list" 
<linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 02/13] da850: pruss platform specific additions.

> Hello.
>
> Subhasish Ghosh wrote:
>
>> This patch adds the platform device and assignes the platform resources
>> for the PRUSS mfd driver.
>
>    You also add the PRUSS clock (and I would have done that as a separate 
> patch).
>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
>
>    You should have noted the patch dependency here -- this patch depends 
> on the one nenaming DA8XX_LPSC0_DMAX.

SG - Will do
>
> WBR, Sergei 


From subhasish at mistralsolutions.com  Fri Feb 18 01:18:51 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 12:48:51 +0530
Subject: [PATCH v2 03/13] da850: pruss board specific additions.
In-Reply-To: <4D558337.2060401@mvista.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-4-git-send-email-subhasish@mistralsolutions.com>
	<4D558337.2060401@mvista.com>
Message-ID: <DB2461FECF1749F38B5F6E48D67E5A31@subhasishg>



--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov at mvista.com>
Sent: Saturday, February 12, 2011 12:13 AM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<sachi at mistralsolutions.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Kevin Hilman" <khilman at deeprootsystems.com>; "open list" 
<linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 03/13] da850: pruss board specific additions.

> Subhasish Ghosh wrote:
>
>> This patch adds board specific initializations and setup routines.
>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> [...]
>
>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
>> b/arch/arm/mach-davinci/board-da850-evm.c
>> index 11f986b..242d1ed 100644
>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
>> @@ -1053,6 +1053,26 @@ static __init int da850_evm_init_cpufreq(void)
>>  static __init int da850_evm_init_cpufreq(void) { return 0; }
>>  #endif
>>  +static struct da8xx_pruss_devices pruss_devices[] = {
>> + {.dev_name = NULL,},
>
>    No need to explicitly initialize to NULL.
>
SG - Ok, Will remove

> WBR, Sergei
> 

From subhasish at mistralsolutions.com  Fri Feb 18 01:19:49 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 12:49:49 +0530
Subject: [PATCH v2 06/13] da850: pruss CAN board specific additions.
In-Reply-To: <4D5583CF.8010905@mvista.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-7-git-send-email-subhasish@mistralsolutions.com>
	<4D5583CF.8010905@mvista.com>
Message-ID: <22D5E56F60D24A7190AD7FEAD0EF75D2@subhasishg>



--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov at mvista.com>
Sent: Saturday, February 12, 2011 12:15 AM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<sachi at mistralsolutions.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Kevin Hilman" <khilman at deeprootsystems.com>; <nsekhar at ti.com>; "open list" 
<linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 06/13] da850: pruss CAN board specific additions.

> Subhasish Ghosh wrote:
>
>> This patch adds the pruss CAN pin mux and registers the device
>> with the pruss mfd driver.
>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> [...]
>
>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
>> b/arch/arm/mach-davinci/board-da850-evm.c
>> index 242d1ed..2ce5536 100644
>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
>> @@ -1053,8 +1053,43 @@ static __init int da850_evm_init_cpufreq(void)
> [...]
>>  static struct da8xx_pruss_devices pruss_devices[] = {
>> - {.dev_name = NULL,},
>> + {
>> + .dev_name = "da8xx_pruss_can",
>> + .pdata = &can_data,
>> + .pdata_size = sizeof(can_data),
>> + .setup = da850_evm_setup_pruss_can,
>> + },
>> + {
>> + .dev_name = NULL,
>> + },
>
>    No need to explicitly initialize to NULL.

SG -- ok, Will remove
>
> WBR, Sergei 


From subhasish at mistralsolutions.com  Fri Feb 18 01:20:24 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 12:50:24 +0530
Subject: [PATCH v2 07/13] da850: pruss CAN platform specific changes for
	gpios.
In-Reply-To: <4D558455.8090709@mvista.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-8-git-send-email-subhasish@mistralsolutions.com>
	<4D558455.8090709@mvista.com>
Message-ID: <2FF339434FAA4AA6957A44481CCF0A42@subhasishg>



--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov at mvista.com>
Sent: Saturday, February 12, 2011 12:17 AM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<sachi at mistralsolutions.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Kevin Hilman" <khilman at deeprootsystems.com>; "Thomas Koeller" 
<thomas.koeller at baslerweb.com>; <nsekhar at ti.com>; "open list" 
<linux-kernel at vger.kernel.org>; "Victor Rodriguez" <vm.rod25 at gmail.com>; 
"Cyril Chemparathy" <cyril at ti.com>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 07/13] da850: pruss CAN platform specific changes for 
gpios.

> Hello.
>
> Subhasish Ghosh wrote:
>
>> This patch adds the GPIOs for the pruss CAN device.
>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
>
>    I still think this patch should be merged with patch 5, and patch 8 
> with patch 6...
>
SG -- Ok, Will do.

> WBR, Sergei 


From subhasish at mistralsolutions.com  Fri Feb 18 01:19:49 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 12:49:49 +0530
Subject: [PATCH v2 06/13] da850: pruss CAN board specific additions.
In-Reply-To: <4D5583CF.8010905@mvista.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-7-git-send-email-subhasish@mistralsolutions.com>
	<4D5583CF.8010905@mvista.com>
Message-ID: <2774EB35C1E04E299E5BF2E60CC956B7@subhasishg>



--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov at mvista.com>
Sent: Saturday, February 12, 2011 12:15 AM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<sachi at mistralsolutions.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Kevin Hilman" <khilman at deeprootsystems.com>; <nsekhar at ti.com>; "open list" 
<linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 06/13] da850: pruss CAN board specific additions.

> Subhasish Ghosh wrote:
>
>> This patch adds the pruss CAN pin mux and registers the device
>> with the pruss mfd driver.
>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> [...]
>
>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
>> b/arch/arm/mach-davinci/board-da850-evm.c
>> index 242d1ed..2ce5536 100644
>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
>> @@ -1053,8 +1053,43 @@ static __init int da850_evm_init_cpufreq(void)
> [...]
>>  static struct da8xx_pruss_devices pruss_devices[] = {
>> - {.dev_name = NULL,},
>> + {
>> + .dev_name = "da8xx_pruss_can",
>> + .pdata = &can_data,
>> + .pdata_size = sizeof(can_data),
>> + .setup = da850_evm_setup_pruss_can,
>> + },
>> + {
>> + .dev_name = NULL,
>> + },
>
>    No need to explicitly initialize to NULL.

SG -- ok, Will remove
>
> WBR, Sergei 


From subhasish at mistralsolutions.com  Fri Feb 18 02:15:57 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 13:45:57 +0530
Subject: [PATCH v2 09/13] can: pruss CAN driver.
In-Reply-To: <4D5E2570.10108@grandegger.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>	<1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>	<20110211152026.GC373@e-circ.dyndns.org>
	<32A5399EB727427C98185089E5DBFA65@subhasishg>
	<4D5E2570.10108@grandegger.com>
Message-ID: <184FA07B783D4F5FAAC09D5C11737A3F@subhasishg>

> On 02/18/2011 08:07 AM, Subhasish Ghosh wrote:
>> --------------------------------------------------
>> From: "Kurt Van Dijck" <kurt.van.dijck at eia.be>
>
> ...
>>>> + /* register interrupt handler */
>>>> + err = request_irq(priv->trx_irq, &omapl_rx_can_intr, IRQF_SHARED,
>>>> +   "pru_can_irq", ndev);
>>> you're doing a lot of work _in_ the irq handler. Maybe threaded irq?
>>>
>> SG -Ok, will do
>
> No, please use NAPI instead.

We are using h/w filters, so the number of interrupts coming into the 
processor are not hogging it.
I feel that we may not require an interrupt mitigation.

-Subhasish 


From subhasish at mistralsolutions.com  Fri Feb 18 03:09:15 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 14:39:15 +0530
Subject: [PATCH v2 09/13] can: pruss CAN driver.
In-Reply-To: <4D5E2F86.1020400@pengutronix.de>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>	<1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>	<20110211152026.GC373@e-circ.dyndns.org>	<32A5399EB727427C98185089E5DBFA65@subhasishg>	<4D5E2570.10108@grandegger.com>
	<184FA07B783D4F5FAAC09D5C11737A3F@subhasishg>
	<4D5E2F86.1020400@pengutronix.de>
Message-ID: <CAA7B3D71228413B9F7F3C0F5A011119@subhasishg>

Ok, will do NAPI


On 02/18/2011 09:15 AM, Subhasish Ghosh wrote:
>> On 02/18/2011 08:07 AM, Subhasish Ghosh wrote:
>>> --------------------------------------------------
>>> From: "Kurt Van Dijck" <kurt.van.dijck at eia.be>
>>
>> ...
>>>>> + /* register interrupt handler */
>>>>> + err = request_irq(priv->trx_irq, &omapl_rx_can_intr, IRQF_SHARED,
>>>>> +   "pru_can_irq", ndev);
>>>> you're doing a lot of work _in_ the irq handler. Maybe threaded irq?
>>>>
>>> SG -Ok, will do
>>
>> No, please use NAPI instead.
> 
> We are using h/w filters, so the number of interrupts coming into the
> processor are not hogging it.
> I feel that we may not require an interrupt mitigation.

As davem stated the other day, all new drivers should use NAPI.

regards, Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 | 

From synmyth at gmail.com  Fri Feb 18 04:44:52 2011
From: synmyth at gmail.com (Yinglin Luan)
Date: Fri, 18 Feb 2011 18:44:52 +0800
Subject: Kernel Memory Leak
Message-ID: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>

Hi, everyone

I notice that the amount of free memory on my dm365 evm gets smaller and
smaller, so I enable CONFIG_DEBUG_KMEMLEAK in "Kernel hacking".When I do
'cat /sys/kernel/debug/kmemleak', I get an output:

unreferenced object 0xc12920c0 (size 192):
  comm "softirq", pid 0, jiffies 126399
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 20 a4 c2 00 00 00 00  ......... ......
  backtrace:
    [<c00ab5d8>] __save_stack_trace+0x34/0x40
    [<c00ab6e8>] create_object+0x104/0x1fc
    [<c0326a90>] kmemleak_alloc+0x40/0x84
    [<c00a891c>] kmem_cache_alloc+0xf4/0x10c
    [<c028b028>] __alloc_skb+0x34/0x108
    [<c028bc7c>] dev_alloc_skb+0x20/0x44
    [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
    [<c02047e8>] emac_poll+0x244/0x5d0
    [<c0292af4>] net_rx_action+0xb4/0x274
    [<c004f648>] __do_softirq+0xb0/0x164
    [<c004f75c>] irq_exit+0x60/0xb8
    [<c0035074>] asm_do_IRQ+0x74/0x8c
    [<c0035ad8>] __irq_svc+0x58/0xa4
    [<c0036fac>] cpu_idle+0x80/0xf0
    [<c0326478>] rest_init+0x70/0x84
    [<c00089dc>] start_kernel+0x28c/0x2e4
unreferenced object 0xc2c34000 (size 2048):
  comm "softirq", pid 0, jiffies 126399
  hex dump (first 32 bytes):
    00 00 00 00 4c 37 f5 2b 6a 6a 19 63 98 82 08 00  ....L7.+jj.c....
    45 00 05 dc fd 34 20 b9 40 11 d2 a2 c0 a8 01 c8  E....4 . at .......
  backtrace:
    [<c00ab5d8>] __save_stack_trace+0x34/0x40
    [<c00ab6e8>] create_object+0x104/0x1fc
    [<c0326a90>] kmemleak_alloc+0x40/0x84
    [<c00a8fb0>] __kmalloc_track_caller+0x144/0x15c
    [<c028b048>] __alloc_skb+0x54/0x108
    [<c028bc7c>] dev_alloc_skb+0x20/0x44
    [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
    [<c02047e8>] emac_poll+0x244/0x5d0
    [<c0292af4>] net_rx_action+0xb4/0x274
    [<c004f648>] __do_softirq+0xb0/0x164
    [<c004f75c>] irq_exit+0x60/0xb8
    [<c0035074>] asm_do_IRQ+0x74/0x8c
    [<c0035ad8>] __irq_svc+0x58/0xa4
    [<c0036fac>] cpu_idle+0x80/0xf0
    [<c0326478>] rest_init+0x70/0x84
    [<c00089dc>] start_kernel+0x28c/0x2e4
......
(the output is too long and the backtrace is almost the same as above)

Is this real kernel memory leaks, or it's only transient?

-- 
Yinglin Luan
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110218/026758da/attachment-0001.html>

From subhasish at mistralsolutions.com  Fri Feb 18 07:47:38 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Fri, 18 Feb 2011 19:17:38 +0530
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <20110211162814.6ff274f1@lxorguk.ukuu.org.uk>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com><1297435892-28278-14-git-send-email-subhasish@mistralsolutions.com>
	<20110211162814.6ff274f1@lxorguk.ukuu.org.uk>
Message-ID: <90BDE50764124CA8AAD560BB1E92C062@subhasishg>

Hello,

Regarding the semaphore to mutex migration.
We are using down_trylock in interrupt context,
mutex_trylock cannot be used in interrupt context, so we cannot use mutex in 
our driver.

--------------------------------------------------
From: "Alan Cox" <alan at lxorguk.ukuu.org.uk>
Sent: Friday, February 11, 2011 9:58 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>; 
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "Greg Kroah-Hartman" 
<gregkh at suse.de>; "open list" <linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver

> Don't see why it needs its own sub-directory
>
>
>
>> +#ifdef __SUART_DEBUG
>> +#define __suart_debug(fmt, args...) \
>> + printk(KERN_DEBUG "suart_debug: " fmt, ## args)
>> +#else
>> +#define __suart_debug(fmt, args...)
>> +#endif
>> +
>> +#define  __suart_err(fmt, args...) printk(KERN_ERR "suart_err: " fmt, ## 
>> args)
>
> Use dev_dbg/dev_err/pr_debug/pr_err
>
>
>> +static void omapl_pru_tx_chars(struct omapl_pru_suart *soft_uart, u32 
>> uart_no)
>> +{
>> + struct circ_buf *xmit = &soft_uart->port[uart_no].state->xmit;
>> + struct device *dev = soft_uart->dev;
>> + s32 count = 0;
>> +
>> + if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
>> + return;
>> +
>> + if (down_trylock(&soft_uart->port_sem[uart_no]))
>> + return;
>
> Please use a mutex not a semaphore. We are trying to get almost all the
> kernel using mutexes as it is needed for hard real time.
>
>
>> + pru_softuart_read_data(dev, &soft_uart->suart_hdl[uart_no],
>> +        suart_data, data_len + 1,
>> +        &data_len_read);
>> +
>> + for (i = 0; i <= data_len_read; i++) {
>> + soft_uart->port[uart_no].icount.rx++;
>> + /* check for sys rq */
>> + if (uart_handle_sysrq_char
>> +     (&soft_uart->port[uart_no], suart_data))
>> + continue;
>> + }
>> + /* update the tty data structure */
>> + tty_insert_flip_string(tty, suart_data, data_len_read);
>
> You can avoid a copy here by using tty_prepare_flip_string()
>
> Also please use the tty_port_tty_get/tty_kref_put interfaces so the tty
> refcounting is right
>
>
>> +static void pruss_suart_set_termios(struct uart_port *port,
>> +   struct ktermios *termios,
>> +   struct ktermios *old)
>> +{
>> + struct omapl_pru_suart *soft_uart =
>> +     container_of(port, struct omapl_pru_suart, port[port->line]);
>> + struct device *dev = soft_uart->dev;
>> + u8 cval = 0;
>> + unsigned long flags = 0;
>> + u32 baud = 0;
>> + u32 old_csize = old ? old->c_cflag & CSIZE : CS8;
>> +
>> +/*
>> + * Do not allow unsupported configurations to be set
>> + */
>> + if (1) {
>> + termios->c_cflag &= ~(HUPCL | CRTSCTS | CMSPAR | CSTOPB
>> +       | PARENB | PARODD | CMSPAR);
>> + termios->c_cflag |= CLOCAL;
>
> No. CLOCAL and HUPCL are user side flags. Apps expect to able to set them
> even if in fact they have no effect, so leave those two alone. The rest
> is fine.
>
>
>> +/*
>> + * Characteres to ignore
>
> Typo
>
>
>
>> diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c 
>> b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
>> new file mode 100644
>> index 0000000..d809dd3
>> --- /dev/null
>> +++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
>> @@ -0,0 +1,2350 @@
>> +/*
>> + * Copyright (C) 2010 Texas Instruments Incorporated
>> + * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
>> + *
>> + * 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/types.h>
>> +#include <linux/mfd/pruss/da8xx_pru.h>
>> +#include <linux/io.h>
>> +#include <mach/hardware.h>
>> +#include "pruss_suart_api.h"
>> +#include "pruss_suart_regs.h"
>> +#include "pruss_suart_board.h"
>> +#include "pruss_suart_utils.h"
>> +#include "pruss_suart_err.h"
>> +
>> +static u8 g_uart_statu_table[8];
> Can you lose the g_, its  a windows naming convention we dont use
>
>
>> +s16 pru_softuart_open(suart_handle h_suart)
>> +{
>
> If you just used normal integers you could surely make this routine
> trivial and remove all the duplication in the switches
>
>> + s16 status = PRU_SUART_SUCCESS;
>
> And please stick to Linux error codes
>
>
>> +/* suart instance close routine */
>> +s16 pru_softuart_close(suart_handle h_uart)
>> +{
>> + s16 status = SUART_SUCCESS;
>> +
>> + if (h_uart == NULL) {
>> + return PRU_SUART_ERR_HANDLE_INVALID;
>
> Which is never checked. Far better to use WARN_ON and the like for such
> cases - or if like this one they don't appear to be possible to simply
> delete them
>
>> + if ((tx_clk_divisor > 385) || (tx_clk_divisor == 0))
>> + return SUART_INVALID_CLKDIVISOR;
>> + if ((rx_clk_divisor > 385) || (rx_clk_divisor == 0))
>> + return SUART_INVALID_CLKDIVISOR;
>
> [minor] Lots of excess brackets
>
>
>> + u32offset = (u32) (PRUSS_INTC_CHANMAP9 & 0xFFFF);
>> + u32value = PRU_INTC_CHAN_34_SYSEVT_36_39;
>> + s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
>> + if (-1 == s16retval)
>> + return -1;
>
> If you fixed the API here you'd be able to just write
>
> if (pruss_writel(dev, PRUSS_INTC_CHANMAP9 & 0xFFFF,
> PRU_INTC_BLAH)
>
> or similar which would clean up a lot of messy code and shrink it
> dramatically. Given you have lots of series of writes some kind of
>
> pruss_writel_multi(dev, array, len)
>
> that took an array of addr/value pairs might also clean up a ton of code
> and turn it into trivial tables
> 

From schen at mvista.com  Fri Feb 18 08:14:02 2011
From: schen at mvista.com (Steve Chen)
Date: Fri, 18 Feb 2011 08:14:02 -0600
Subject: Kernel Memory Leak
In-Reply-To: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>
References: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>
Message-ID: <AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>

On Fri, Feb 18, 2011 at 4:44 AM, Yinglin Luan <synmyth at gmail.com> wrote:
> Hi, everyone
>
> I notice that the amount of free memory on my dm365 evm gets smaller and
> smaller, so I enable CONFIG_DEBUG_KMEMLEAK in "Kernel hacking".When I do
> 'cat /sys/kernel/debug/kmemleak', I get an output:
>
> unreferenced object 0xc12920c0 (size 192):
> ? comm "softirq", pid 0, jiffies 126399
> ? hex dump (first 32 bytes):
> ??? 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00? ................
> ??? 00 00 00 00 00 00 00 00 00 20 a4 c2 00 00 00 00? ......... ......
> ? backtrace:
> ??? [<c00ab5d8>] __save_stack_trace+0x34/0x40
> ??? [<c00ab6e8>] create_object+0x104/0x1fc
> ??? [<c0326a90>] kmemleak_alloc+0x40/0x84
> ??? [<c00a891c>] kmem_cache_alloc+0xf4/0x10c
> ??? [<c028b028>] __alloc_skb+0x34/0x108
> ??? [<c028bc7c>] dev_alloc_skb+0x20/0x44
> ??? [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
> ??? [<c02047e8>] emac_poll+0x244/0x5d0
> ??? [<c0292af4>] net_rx_action+0xb4/0x274
> ??? [<c004f648>] __do_softirq+0xb0/0x164
> ??? [<c004f75c>] irq_exit+0x60/0xb8
> ??? [<c0035074>] asm_do_IRQ+0x74/0x8c
> ??? [<c0035ad8>] __irq_svc+0x58/0xa4
> ??? [<c0036fac>] cpu_idle+0x80/0xf0
> ??? [<c0326478>] rest_init+0x70/0x84
> ??? [<c00089dc>] start_kernel+0x28c/0x2e4
> unreferenced object 0xc2c34000 (size 2048):
> ? comm "softirq", pid 0, jiffies 126399
> ? hex dump (first 32 bytes):
> ??? 00 00 00 00 4c 37 f5 2b 6a 6a 19 63 98 82 08 00? ....L7.+jj.c....
> ??? 45 00 05 dc fd 34 20 b9 40 11 d2 a2 c0 a8 01 c8? E....4 . at .......
> ? backtrace:
> ??? [<c00ab5d8>] __save_stack_trace+0x34/0x40
> ??? [<c00ab6e8>] create_object+0x104/0x1fc
> ??? [<c0326a90>] kmemleak_alloc+0x40/0x84
> ??? [<c00a8fb0>] __kmalloc_track_caller+0x144/0x15c
> ??? [<c028b048>] __alloc_skb+0x54/0x108
> ??? [<c028bc7c>] dev_alloc_skb+0x20/0x44
> ??? [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
> ??? [<c02047e8>] emac_poll+0x244/0x5d0
> ??? [<c0292af4>] net_rx_action+0xb4/0x274
> ??? [<c004f648>] __do_softirq+0xb0/0x164
> ??? [<c004f75c>] irq_exit+0x60/0xb8
> ??? [<c0035074>] asm_do_IRQ+0x74/0x8c
> ??? [<c0035ad8>] __irq_svc+0x58/0xa4
> ??? [<c0036fac>] cpu_idle+0x80/0xf0
> ??? [<c0326478>] rest_init+0x70/0x84
> ??? [<c00089dc>] start_kernel+0x28c/0x2e4
> ......
> (the output is too long and the backtrace is almost the same as above)
>
> Is this real kernel memory leaks, or it's only transient?

In general, the Linux kernel tries to cache as much data in memory as
possible in order to improve performance.  Therefore, it is quite
normal to see decreasing free memory over time.  As long as the kernel
is able to free memory cache when needed, there are no issues.

Regards,

Steve

From alan at lxorguk.ukuu.org.uk  Fri Feb 18 08:35:00 2011
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 18 Feb 2011 14:35:00 +0000
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <90BDE50764124CA8AAD560BB1E92C062@subhasishg>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-14-git-send-email-subhasish@mistralsolutions.com>
	<20110211162814.6ff274f1@lxorguk.ukuu.org.uk>
	<90BDE50764124CA8AAD560BB1E92C062@subhasishg>
Message-ID: <20110218143500.23b3044b@lxorguk.ukuu.org.uk>

On Fri, 18 Feb 2011 19:17:38 +0530
"Subhasish Ghosh" <subhasish at mistralsolutions.com> wrote:

> Hello,
> 
> Regarding the semaphore to mutex migration.
> We are using down_trylock in interrupt context,
> mutex_trylock cannot be used in interrupt context, so we cannot use mutex in 
> our driver.

Then you probably need to rework your locking. Best bet might be to fix
all the other stuff and report the driver, and people can think about the
locking problem.

Alan

From pratheesh at ti.com  Fri Feb 18 09:05:29 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Fri, 18 Feb 2011 20:35:29 +0530
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
Message-ID: <1298041530-26855-2-git-send-email-pratheesh@ti.com>

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>

This patch implements PRUSS (Programmable Real-time Unit Sub System)
UIO driver which exports SOC resources associated with PRUSS like
I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
processors which is efficient in performing embedded tasks that
require manipulation of packed memory mapped data structures and
efficient in handling system events that have tight real time
constraints. This driver is currently supported on Texas Instruments
DA850, AM18xx and OMAPL1-38 devices.
For example, PRUSS runs firmware for real-time critical industrial
communication data link layer and communicates with application stack
running in user space via shared memory and IRQs.
---
 drivers/uio/Kconfig     |   10 ++
 drivers/uio/Makefile    |    1 +
 drivers/uio/uio_pruss.c |  250 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 261 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index bb44079..631ffe3 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -94,4 +94,14 @@ config UIO_NETX
 	  To compile this driver as a module, choose M here; the module
 	  will be called uio_netx.
 
+config UIO_PRUSS
+	tristate "Texas Instruments PRUSS driver"
+	depends on ARCH_DAVINCI_DA850
+	default n
+	help
+	  PRUSS driver for OMAPL138/DA850/AM18XX devices
+	  PRUSS driver requires user space components
+	  To compile this driver as a module, choose M here: the module
+	  will be called uio_pruss.
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..d4dd9a5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC)	+= uio_aec.o
 obj-$(CONFIG_UIO_SERCOS3)	+= uio_sercos3.o
 obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
+obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
new file mode 100644
index 0000000..5ae78a5
--- /dev/null
+++ b/drivers/uio/uio_pruss.c
@@ -0,0 +1,250 @@
+/*
+ * Programmable Real-Time Unit Sub System (PRUSS) UIO driver (uio_pruss)
+ *
+ * This driver exports PRUSS host event out interrupts and PRUSS, L3 RAM,
+ * and DDR RAM to user space for applications interacting with PRUSS firmware 
+ *
+ * Copyright (C) 2010-11 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 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/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+
+#define DRV_NAME "pruss"
+#define DRV_VERSION "0.50"
+
+/*
+ * Host event IRQ numbers from PRUSS 	
+ * 3 PRU_EVTOUT0 PRUSS Interrupt
+ * 4 PRU_EVTOUT1 PRUSS Interrupt
+ * 5 PRU_EVTOUT2 PRUSS Interrupt
+ * 6 PRU_EVTOUT3 PRUSS Interrupt
+ * 7 PRU_EVTOUT4 PRUSS Interrupt
+ * 8 PRU_EVTOUT5 PRUSS Interrupt
+ * 9 PRU_EVTOUT6 PRUSS Interrupt
+ * 10 PRU_EVTOUT7 PRUSS Interrupt
+*/
+
+#define MAX_PRUSS_EVTOUT_INSTANCE	(8)
+
+static struct clk *pruss_clk;
+static struct uio_info *info[MAX_PRUSS_EVTOUT_INSTANCE];
+static void *ddr_virt_addr;
+static dma_addr_t ddr_phy_addr;
+
+static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
+{
+	return IRQ_HANDLED;
+}
+
+static int __devinit pruss_probe(struct platform_device *dev)
+{
+	int ret = -ENODEV;
+	int count = 0;
+	struct resource *regs_pruram, *regs_l3ram, *regs_ddr;
+	char *string;
+
+	/* Power on PRU in case its not done as part of boot-loader */
+	pruss_clk = clk_get(&dev->dev, "pruss");
+	if (IS_ERR(pruss_clk)) {
+		dev_err(&dev->dev, "Failed to get clock\n");
+		ret = PTR_ERR(pruss_clk);
+		pruss_clk = NULL;
+		return ret;
+	} else {
+		clk_enable(pruss_clk);
+	}
+
+	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
+		info[count] = kzalloc(sizeof(struct uio_info), GFP_KERNEL);
+		if (!info[count])
+			return -ENOMEM;
+	}
+
+	regs_pruram = platform_get_resource(dev, IORESOURCE_MEM, 0);
+	if (!regs_pruram) {
+		dev_err(&dev->dev, "No memory resource specified\n");
+		goto out_free;
+	}
+
+	regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
+	if (!regs_l3ram) {
+		dev_err(&dev->dev, "No memory resource specified\n");
+		goto out_free;
+	}
+
+	regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
+	if (!regs_ddr) {
+		dev_err(&dev->dev, "No memory resource specified\n");
+		goto out_free;
+	}
+	ddr_virt_addr =
+	    dma_alloc_coherent(&dev->dev, regs_ddr->end - regs_ddr->start + 1,
+			       &ddr_phy_addr, GFP_KERNEL | GFP_DMA);
+	if (!ddr_virt_addr) {
+		dev_err(&dev->dev, "Could not allocate external memory\n");
+		goto out_free;
+	}
+
+	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
+		info[count]->mem[0].addr = regs_pruram->start;
+		info[count]->mem[0].size =
+		    regs_pruram->end - regs_pruram->start + 1;
+		if (!info[count]->mem[0].addr
+		    || !(info[count]->mem[0].size - 1)) {
+			dev_err(&dev->dev, "Invalid memory resource\n");
+			break;
+		}
+		info[count]->mem[0].internal_addr =
+		    ioremap(regs_pruram->start, info[count]->mem[0].size);
+		if (!info[count]->mem[0].internal_addr) {
+			dev_err(&dev->dev,
+				"Can't remap memory address range\n");
+			break;
+		}
+		info[count]->mem[0].memtype = UIO_MEM_PHYS;
+
+		info[count]->mem[1].addr = regs_l3ram->start;
+		info[count]->mem[1].size =
+		    regs_l3ram->end - regs_l3ram->start + 1;
+		if (!info[count]->mem[1].addr
+		    || !(info[count]->mem[1].size - 1)) {
+			dev_err(&dev->dev, "Invalid memory resource\n");
+			break;
+		}
+		info[count]->mem[1].internal_addr =
+		    ioremap(regs_l3ram->start, info[count]->mem[1].size);
+		if (!info[count]->mem[1].internal_addr) {
+			dev_err(&dev->dev,
+				"Can't remap memory address range\n");
+			break;
+		}
+		info[count]->mem[1].memtype = UIO_MEM_PHYS;
+
+		info[count]->mem[2].addr = ddr_phy_addr;
+		info[count]->mem[2].size = regs_ddr->end - regs_ddr->start + 1;
+		if (!info[count]->mem[2].addr
+		    || !(info[count]->mem[2].size - 1)) {
+			dev_err(&dev->dev, "Invalid memory resource\n");
+			break;
+		}
+		info[count]->mem[2].internal_addr = ddr_virt_addr;
+		if (!info[count]->mem[2].internal_addr) {
+			dev_err(&dev->dev,
+				"Can't remap memory address range\n");
+			break;
+		}
+		info[count]->mem[2].memtype = UIO_MEM_PHYS;
+
+		string = kzalloc(20, GFP_KERNEL);
+		sprintf(string, "pruss_evt%d", count);
+		info[count]->name = string;
+		info[count]->version = "0.50";
+
+		/* Register PRUSS IRQ lines */
+		info[count]->irq = IRQ_DA8XX_EVTOUT0 + count;
+
+		info[count]->irq_flags = IRQF_SHARED;
+		info[count]->handler = pruss_handler;
+
+		ret = uio_register_device(&dev->dev, info[count]);
+
+		if (ret < 0)
+			break;
+	}
+
+	if (ret < 0) {
+		if (ddr_virt_addr)
+			dma_free_coherent(&dev->dev,
+					  regs_ddr->end - regs_ddr->start + 1,
+					  ddr_virt_addr, ddr_phy_addr);
+		while (count--) {
+			uio_unregister_device(info[count]);
+			kfree(info[count]->name);
+			iounmap(info[count]->mem[0].internal_addr);
+		}
+	} else {
+		platform_set_drvdata(dev, info);
+		return 0;
+	}
+
+out_free:
+	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++)
+		kfree(info[count]);
+
+	if (pruss_clk != NULL)
+		clk_put(pruss_clk);
+
+	return ret;
+}
+
+static int __devexit pruss_remove(struct platform_device *dev)
+{
+	int count = 0;
+	struct uio_info **info;
+
+	info = (struct uio_info **)platform_get_drvdata(dev);
+
+	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
+		uio_unregister_device(info[count]);
+		kfree(info[count]->name);
+
+	}
+	iounmap(info[0]->mem[0].internal_addr);
+	iounmap(info[0]->mem[1].internal_addr);
+	if (ddr_virt_addr)
+		dma_free_coherent(&dev->dev, info[0]->mem[2].size,
+				  info[0]->mem[2].internal_addr,
+				  info[0]->mem[2].addr);
+
+	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++)
+		kfree(info[count]);
+
+	platform_set_drvdata(dev, NULL);
+
+	if (pruss_clk != NULL)
+		clk_put(pruss_clk);
+	return 0;
+}
+
+static struct platform_driver pruss_driver = {
+	.probe = pruss_probe,
+	.remove = __devexit_p(pruss_remove),
+	.driver = {
+		   .name = DRV_NAME,
+		   .owner = THIS_MODULE,
+		   },
+};
+
+static int __init pruss_init_module(void)
+{
+	return platform_driver_register(&pruss_driver);
+}
+
+module_init(pruss_init_module);
+
+static void __exit pruss_exit_module(void)
+{
+	platform_driver_unregister(&pruss_driver);
+}
+
+module_exit(pruss_exit_module);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Amit Chatterjee <amit.chatterjee at ti.com>");
+MODULE_AUTHOR("Pratheesh Gangadhar <pratheesh at ti.com>");
-- 
1.6.0.6


From pratheesh at ti.com  Fri Feb 18 09:05:28 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Fri, 18 Feb 2011 20:35:28 +0530
Subject: [PATCH 0/2] Add PRUSS UIO driver support
Message-ID: <1298041530-26855-1-git-send-email-pratheesh@ti.com>

This patch series add support for PRUSS (Programmable Real-time Unit Sub System) UIO driver in Texas Instruments DA850, AM18xx and OMAPL1-38 processors. PRUSS is programmable RISC core which can be used to implement Soft IPs (eg:- DMA, CAN, UART,SmartCard) and Industrial communications data link layers (eg:- PROFIBUS). UIO driver exposes PRUSS resources like memory and interrupts to user space application.PRUSS UIO application API can be used to control PRUs in PRUSS, setup PRU INTC, load firmware to PRUs and implement IPC between Host processor and PRUs. More information on PRUSS and UIO linux user space API available in the links below

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide 

PRUSS UIO driver support patch applies on top of Linus's tree latest.
Both patches applies on top of linux-davinci tree latest. 

Pratheesh Gangadhar (2):
  PRUSS UIO driver support
  Defines DA850/AM18xx/OMAPL1-38 SOC resources used by PRUSS UIO driver

 arch/arm/mach-davinci/board-da850-evm.c    |    4 +
 arch/arm/mach-davinci/da850.c              |   35 ++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 ++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 drivers/uio/Kconfig                        |   10 +
 drivers/uio/Makefile                       |    1 +
 drivers/uio/uio_pruss.c                    |  250 ++++++++++++++++++++++++++++
 7 files changed, 376 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c


From pratheesh at ti.com  Fri Feb 18 09:05:30 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Fri, 18 Feb 2011 20:35:30 +0530
Subject: [PATCH 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used by
	PRUSS UIO driver
In-Reply-To: <1298041530-26855-2-git-send-email-pratheesh@ti.com>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
Message-ID: <1298041530-26855-3-git-send-email-pratheesh@ti.com>

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>

This patch defines PRUSS, ECAP clocks, memory and IRQ resources
used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
DDR buffer to user space. PRUSS has 8 host event interrupt lines
mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
with shared memory can be used to implement IPC between ARM9 and
PRUSS.
---
 arch/arm/mach-davinci/board-da850-evm.c    |    4 ++
 arch/arm/mach-davinci/da850.c              |   35 +++++++++++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 4 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..ddcbac8 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
 		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
 				ret);
 
+	ret = da8xx_register_pruss();
+       if (ret)
+                pr_warning("da850_evm_init: pruss registration failed: %d\n",
+                                 ret);
 
 	ret = da8xx_register_watchdog();
 	if (ret)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..0096d4f 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
 	.flags		= ALWAYS_ENABLED,
 };
 
+static struct clk pruss_clk = {
+	.name		= "pruss",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_DMAX,
+	.flags		= ALWAYS_ENABLED,
+};
+
 static struct clk uart0_clk = {
 	.name		= "uart0",
 	.parent		= &pll0_sysclk2,
@@ -359,6 +366,30 @@ static struct clk usb20_clk = {
 	.gpsc		= 1,
 };
 
+static struct clk ecap0_clk = {
+	.name		= "ecap0",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap1_clk = {
+	.name		= "ecap1",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap2_clk = {
+	.name		= "ecap2",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -386,6 +417,7 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tptc1",	&tptc1_clk),
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
+	CLK(NULL,		"pruss",	&pruss_clk),
 	CLK(NULL,		"uart0",	&uart0_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
@@ -403,6 +435,9 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"aemif",	&aemif_clk),
 	CLK(NULL,		"usb11",	&usb11_clk),
 	CLK(NULL,		"usb20",	&usb20_clk),
+	CLK(NULL,		"ecap0",	&ecap0_clk),
+	CLK(NULL,		"ecap1",	&ecap1_clk),
+	CLK(NULL,		"ecap2",	&ecap2_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..4ea3d1f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+static struct resource pruss_resources[] = {
+	[0] = {
+		.start  = DA8XX_PRUSS_BASE,
+		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[1] = {
+		.start  = DA8XX_L3RAM_BASE,
+		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[2] = {
+		.start  = 0,
+		.end    = SZ_256K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+
+	[3] = {
+		.start  = IRQ_DA8XX_EVTOUT0,
+		.end    = IRQ_DA8XX_EVTOUT0,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[4] = {
+		.start  = IRQ_DA8XX_EVTOUT1,
+		.end    = IRQ_DA8XX_EVTOUT1,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[5] = {
+		.start  = IRQ_DA8XX_EVTOUT2,
+		.end    = IRQ_DA8XX_EVTOUT2,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[6] = {
+		.start  = IRQ_DA8XX_EVTOUT3,
+		.end    = IRQ_DA8XX_EVTOUT3,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[7] = {
+		.start  = IRQ_DA8XX_EVTOUT4,
+		.end    = IRQ_DA8XX_EVTOUT4,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[8] = {
+		.start  = IRQ_DA8XX_EVTOUT5,
+		.end    = IRQ_DA8XX_EVTOUT5,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[9] = {
+		.start  = IRQ_DA8XX_EVTOUT6,
+		.end    = IRQ_DA8XX_EVTOUT6,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[10] = {
+		.start  = IRQ_DA8XX_EVTOUT7,
+		.end    = IRQ_DA8XX_EVTOUT7,
+		.flags  = IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device pruss_device = {
+	.name			= "pruss",
+	.id			= 0,
+	.num_resources		= ARRAY_SIZE(pruss_resources),
+	.resource		= pruss_resources,
+	.dev	 =	{
+		.coherent_dma_mask = 0xffffffff,
+	}
+};
+
+int __init da8xx_register_pruss()
+{
+	return platform_device_register(&pruss_device);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..3ed6ee0 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -60,6 +60,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_PLL0_BASE		0x01c11000
 #define DA8XX_TIMER64P0_BASE	0x01c20000
 #define DA8XX_TIMER64P1_BASE	0x01c21000
+#define DA8XX_PRUSS_BASE	0x01c30000
 #define DA8XX_GPIO_BASE		0x01e26000
 #define DA8XX_PSC1_BASE		0x01e27000
 #define DA8XX_LCD_CNTRL_BASE	0x01e13000
@@ -68,6 +69,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CS2_BASE	0x60000000
 #define DA8XX_AEMIF_CS3_BASE	0x62000000
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
+#define DA8XX_L3RAM_BASE	0x80000000
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
 
@@ -90,6 +92,7 @@ int da850_register_cpufreq(char *async_clk);
 int da8xx_register_cpuidle(void);
 void __iomem * __init da8xx_get_mem_ctlr(void);
 int da850_register_pm(struct platform_device *pdev);
+int da8xx_register_pruss(void);
 
 extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
-- 
1.6.0.6


From arnd at arndb.de  Fri Feb 18 09:07:20 2011
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 18 Feb 2011 16:07:20 +0100
Subject: [PATCH v2 09/13] can: pruss CAN driver.
In-Reply-To: <1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <201102181607.20787.arnd@arndb.de>

On Friday 11 February 2011, Subhasish Ghosh wrote:
> This patch adds support for the CAN device emulated on PRUSS.

Hi Subhasish,

This is a detailed walk through the can driver. The pruss_can.c
file mostly looks good, there are very tiny changes that I'm
suggesting to improve the code. I assume that you wrote that file.

The pruss_can_api.c is a bit of a mess and looks like it was copied
from some other code base and just barely changed to follow Linux
coding style. I can tell from the main driver file that you can do
better than that.

My recommendation for that would be to throw it away and reimplement
the few parts that you actually need, in proper coding style.
You can also try to fix the file according to the comments I give
you below, but I assume that would be signficantly more work.

Moving everything into one file also makes things easier to read
here and lets you identifer more quickly what is unused.

	Arnd

> +#ifdef __CAN_DEBUG
> +#define __can_debug(fmt, args...) printk(KERN_DEBUG "can_debug: " fmt, ## args)
> +#else
> +#define __can_debug(fmt, args...)
> +#endif
> +#define __can_err(fmt, args...) printk(KERN_ERR "can_err: " fmt, ## args)

Better use the existing dev_dbg() and dev_err() macros that provide the
same functionality in a more standard way. You already use them in
some places, as I noticed.

If you don't have a way to pass a meaningful device, you can use
pr_debug/pr_err.

> +void omapl_pru_can_rx_wQ(struct work_struct *work)
> +{

This is only used in the same file, so better make it static.

> +	if (-1 == pru_can_get_intr_status(priv->dev, &priv->can_rx_hndl))
> +		return;

Don't make up your own return values, just use the standard error codes,
e.g. -EIO or -EAGAIN, whatever fits.

The more common way to write the comparison would be the other way round,

	if (pru_can_get_intr_status(priv->dev, &priv->can_rx_hndl) == -EAGAIN)
		return;

or, simpler

	if (pru_can_get_intr_status(priv->dev, &priv->can_rx_hndl))
		return;

> +irqreturn_t omapl_tx_can_intr(int irq, void *dev_id)
> +{

This also should be static

> +		for (bit_set = 0; ((priv->can_tx_hndl.u32interruptstatus & 0xFF)
> +						>> bit_set != 0); bit_set++)
> +		;

	bit_set = fls(priv->can_tx_hndl.u32interruptstatus & 0xFF); ?

> +irqreturn_t omapl_rx_can_intr(int irq, void *dev_id)

static

> diff --git a/drivers/net/can/da8xx_pruss/pruss_can_api.c b/drivers/net/can/da8xx_pruss/pruss_can_api.c
> new file mode 100644
> index 0000000..2f7438a
> --- /dev/null
> +++ b/drivers/net/can/da8xx_pruss/pruss_can_api.c

A lot of code in this file seems to be unused. Is that right?
I would suggest adding only the code that is actually being
used. If you add more functionality later, you can always
add back the low-level functions, but dead code usually
turns into broken code quickly.

> +static can_emu_drv_inst gstr_can_inst[ecanmaxinst];

This is global data and probably needs some for of locking

> +/*
> + * pru_can_set_brp()	Updates the  BRP register of PRU0
> + * and PRU1 of OMAP L138. This API will be called by the
> + * Application to updtae the BRP register of PRU0 and PRU1
> + *
> + * param	u16bitrateprescaler		The can bus bitrate
> + * prescaler value be set
> + *
> + * return   SUCCESS or FAILURE
> + */
> +s16 pru_can_set_brp(struct device *dev, u16 u16bitrateprescaler)
> +{

unused.

> +	u32 u32offset;
> +
> +	if (u16bitrateprescaler > 255) {
> +		return -1;
> +	}

non-standard error code. It also doesn't match the comment, which
claims it is SUCCESS or FAILURE, both of which are (rightfully)
not defined.

> +	u32offset = (PRU_CAN_RX_CLOCK_BRP_REGISTER);
> +	pruss_writel(dev, u32offset, (u32 *) &u16bitrateprescaler, 1);
> +
> +	u32offset = (PRU_CAN_TX_CLOCK_BRP_REGISTER);
> +	pruss_writel(dev, u32offset, (u32 *) &u16bitrateprescaler, 1);

You pass a 32 bit pointer to a 16 bit local variable here.
This has an undefined effect, and if you build this code on
a big-endian platform, it cannot possibly do anything good.

pruss_writel() is defined in a funny way if it takes a thirty-two bit
input argument by reference, rather than by value. What is going
on there?

> +s16 pru_can_set_bit_timing(struct device *dev,
> +		can_bit_timing_consts *pstrbittiming)

unused.

> +	u32 u32offset;
> +	u32 u32serregister;

It's a bit silly to put the name of the type into the name
of a variable. You already spell it out in the definition.

> +s16 pru_can_write_data_to_mailbox(struct device *dev,
> +			can_emu_app_hndl *pstremuapphndl)
> +{
> +	s16 s16subrtnretval;
> +	u32 u32offset;
> +
> +	if (pstremuapphndl == NULL) {
> +		return -1;
> +	}

nonstandard error code. Also, why the heck is type function
return type s16 when the only possible return values are 0
and -1? Just make this an int.

> +	switch ((u8) pstremuapphndl->ecanmailboxnumber) {
> +	case 0:
> +		u32offset = (PRU_CAN_TX_MAILBOX0);
> +		break;
> +	case 1:
> +		u32offset = (PRU_CAN_TX_MAILBOX1);
> +		break;
> +	case 2:
> +		u32offset = (PRU_CAN_TX_MAILBOX2);
> +		break;
> +	case 3:
> +		u32offset = (PRU_CAN_TX_MAILBOX3);
> +		break;
> +	case 4:
> +		u32offset = (PRU_CAN_TX_MAILBOX4);
> +		break;
> +	case 5:
> +		u32offset = (PRU_CAN_TX_MAILBOX5);
> +		break;
> +	case 6:
> +		u32offset = (PRU_CAN_TX_MAILBOX6);
> +		break;
> +	case 7:
> +		u32offset = (PRU_CAN_TX_MAILBOX7);
> +		break;
> +	default:
> +		return -1;
> +	}

Lovely switch statement. I'm sure you find a better way to express this ;-)

> +	s16subrtnretval = pruss_writel(dev, u32offset,
> +		(u32 *) &(pstremuapphndl->strcanmailbox), 4);
> +	if (s16subrtnretval == -1) {
> +		return -1;
> +	}
> +	return 0;
> +}

return pruss_writel(...) ?

> +
> +/*
> + * pru_can_get_intr_status()
> + * Gets the interrupts status register value.
> + * This API will be called by the Application
> + * to get the interrupts status register value
> + *
> + * param  u8prunumber	PRU number for which IntStatusReg
> + * has to be read
> + *
> + * return   SUCCESS or FAILURE
> + */
> +s16 pru_can_get_intr_status(struct device *dev,
> +		can_emu_app_hndl *pstremuapphndl)
> +{
> +	u32 u32offset;
> +	s16 s16subrtnretval = -1;
> +
> +	if (pstremuapphndl == NULL) {
> +		return -1;
> +	}

In every function you check that pstremuapphndl is present. This seems
rather pointless. How about just making sure you never pass a NULL
value to these functions? That should not be hard at all from the
high-level driver.

> +	if (pstremuapphndl->u8prunumber == DA8XX_PRUCORE_1) {
> +		u32offset = (PRU_CAN_TX_INTERRUPT_STATUS_REGISTER);
> +	} else if (pstremuapphndl->u8prunumber == DA8XX_PRUCORE_0) {
> +		u32offset = (PRU_CAN_RX_INTERRUPT_STATUS_REGISTER);
> +	} else {
> +		return -1;
> +	}
> +
> +	s16subrtnretval = pruss_readl(dev, u32offset,
> +		(u32 *) &pstremuapphndl->u32interruptstatus, 1);
> +	if (s16subrtnretval == -1) {
> +		return -1;
> +	}

You can also get rid of all these {} braces around one-line statements.

> +/*
> + * pru_can_get_mailbox_status()		Gets the mailbox status
> + * register value. This API will be called by the Application
> + * to get the mailbox status register value
> + *
> + * return   SUCCESS or FAILURE
> + */
> +s16 pru_can_get_mailbox_status(struct device *dev,
> +		can_emu_app_hndl *pstremuapphndl)

unused.

> +/*
> + * pru_can_config_mode_set()		Sets the timing value
> + * for data transfer. This API will be called by the Application
> + * to set timing valus for data transfer
> + *
> + * return   SUCCESS or FAILURE
> + */
> +s16 pru_can_config_mode_set(struct device *dev, bool bconfigmodeflag)

unused.

> +	u32offset = (PRU_CAN_TX_GLOBAL_CONTROL_REGISTER & 0xFFFF);
> +	u32value = 0x00000000;
> +	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
> +	if (s16subrtnretval == -1) {
> +		return -1;
> +	}
> +
> +	u32offset = (PRU_CAN_TX_GLOBAL_STATUS_REGISTER & 0xFFFF);
> +	u32value = 0x00000040;
> +	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
> +	if (s16subrtnretval == -1) {
> +		return -1;
> +	}
> +	u32offset = (PRU_CAN_RX_GLOBAL_STATUS_REGISTER & 0xFFFF);
> +	u32value = 0x00000040;
> +	s16subrtnretval = pruss_writel(dev, u32offset, (u32 *) &u32value, 1);
> +	if (s16subrtnretval == -1) {
> +		return -1;
> +	}

<skipping 50 (!) more of these>

After the third time of writing the same code, you should have noticed that
there is some duplication involved that can trivially be reduced. A good
way to express the same would be a table with the contents:

static struct pru_can_register_init {
	u16 offset;
	u32 value;
} = {
	{ PRU_CAN_TX_GLOBAL_CONTROL_REGISTER, 0, },
	{ PRU_CAN_TX_GLOBAL_STATUS_REGISTER, 0x40, },
	{ PRU_CAN_RX_GLOBAL_STATUS_REGISTER, 0x40, },
	...
};


> +
> +
> +/*
> + * pru_can_emu_open()		Opens the can emu for
> + * application to use. This API will be called by the Application
> + * to Open the can emu for application to use.
> + *
> + * param	pstremuapphndl	Pointer to application handler
> + * structure
> + *
> + * return   SUCCESS or FAILURE
> + */
> +s16 pru_can_emu_open(struct device *dev, can_emu_app_hndl *pstremuapphndl)

unused.

> +/*
> + * brief    pru_can_emu_close()	Closes the can emu for other
> + * applications to use. This API will be called by the Application to Close
> + * the can emu for other applications to use
> + *
> + * param	pstremuapphndl	Pointer to application handler structure
> + *
> + * return   SUCCESS or FAILURE
> + */
> +s16 pru_can_emu_close(struct device *dev, can_emu_app_hndl *pstremuapphndl)

unused

> +s16 pru_can_emu_sreset(struct device *dev)
> +{
> +	return 0;
> +}

pointless.

> +s16 pru_can_tx(struct device *dev, u8 u8mailboxnumber, u8 u8prunumber)
> +{
> +	u32 u32offset = 0;
> +	u32 u32value = 0;
> +	s16 s16subrtnretval = -1;
> +
> +	if (DA8XX_PRUCORE_1 == u8prunumber) {
> +		switch (u8mailboxnumber) {
> +		case 0:
> +			u32offset = (PRU_CAN_TX_MAILBOX0_STATUS_REGISTER & 0xFFFF);
> +			u32value = 0x00000080;
> +			s16subrtnretval = pruss_writel(dev, u32offset,
> +					(u32 *) &u32value, 1);
> +			if (s16subrtnretval == -1) {
> +				return -1;
> +			}
> +			break;
> +		case 1:
> +			u32offset = (PRU_CAN_TX_MAILBOX1_STATUS_REGISTER & 0xFFFF);
> +			u32value = 0x00000080;
> +			s16subrtnretval = pruss_writel(dev, u32offset,
> +						(u32 *) &u32value, 1);
> +			if (s16subrtnretval == -1) {
> +				return -1;
> +			}
> +			break;
> +		case 2:
> +			u32offset = (PRU_CAN_TX_MAILBOX2_STATUS_REGISTER & 0xFFFF);

Another pointless switch statement.

> +s16 pru_can_mask_ints(struct device *dev, u32 int_mask)
> +{
> +	return 0;
> +}
> +
> +int pru_can_get_error_cnt(struct device *dev, u8 u8prunumber)
> +{
> +	return 0;
> +}

useless.

> +int pru_can_get_intc_status(struct device *dev)
> +{
> +	u32 u32offset = 0;
> +	u32 u32getvalue = 0;
> +	u32 u32clrvalue = 0;
> +
> +	u32offset = (PRUSS_INTC_STATCLRINT1 & 0xFFFF);
> +	pruss_readl(dev, u32offset, (u32 *) &u32getvalue, 1);
> +
> +	if (u32getvalue & 4)
> +		u32clrvalue = 34;	/* CLR Event 34 */
> +
> +	if (u32getvalue & 2)
> +		u32clrvalue = 33;	/* CLR Event 33  */
> +
> +	if (u32clrvalue) {
> +		u32offset = (PRUSS_INTC_STATIDXCLR & 0xFFFF);
> +		pruss_writel(dev, u32offset, &u32clrvalue, 1);
> +	} else
> +		return -1;

Could the controller signal both event 34 and 33 simultaneously?
The only user of this function looks at the individual bits
of the return value again, which looks wrong for all possible
return values here.

> +#ifndef _PRU_CAN_API_H_
> +#define CAN_BIT_TIMINGS			(0x273)
> +
> +/* Timer Clock is sourced from DDR freq (PLL1 SYS CLK 2) */
> +#define	TIMER_CLK_FREQ			132000000
> +
> +#define TIMER_SETUP_DELAY		14
> +#define GPIO_SETUP_DELAY		150
> +
> +#define CAN_RX_PRU_0			PRUSS_NUM0
> +#define CAN_TX_PRU_1			PRUSS_NUM1
> +
> +/* Number of Instruction in the Delay loop */
> +#define DELAY_LOOP_LENGTH		2
> +
> +#define PRU1_BASE_ADDR			0x2000
> +
> +#define PRU_CAN_TX_GLOBAL_CONTROL_REGISTER		(PRU1_BASE_ADDR)
> +#define PRU_CAN_TX_GLOBAL_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x04)
> +#define PRU_CAN_TX_INTERRUPT_MASK_REGISTER		(PRU1_BASE_ADDR	+ 0x08)
> +#define PRU_CAN_TX_INTERRUPT_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x0C)
> +#define PRU_CAN_TX_MAILBOX0_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x10)
> +#define PRU_CAN_TX_MAILBOX1_STATUS_REGISTER		(PRU1_BASE_ADDR	+ 0x14)

The header file should be used for interfaces between the two .c files,
don't mix that with hardware specific definitions. Sometimes you may want
to have register number lists in a header, if that list is going to be
used in multiple places. In this case, there is just one user, so better
move all those definitions over there.

> +typedef enum {
> +	ecaninst0 = 0,
> +	ecaninst1,
> +	ecanmaxinst
> +} can_instance_enum;
> +
> +typedef enum {
> +	ecanmailbox0 = 0,
> +	ecanmailbox1,
> +	ecanmailbox2,
> +	ecanmailbox3,
> +	ecanmailbox4,
> +	ecanmailbox5,
> +	ecanmailbox6,
> +	ecanmailbox7
> +} can_mailbox_number;
> +
> +typedef enum {
> +	ecandirectioninit = 0,
> +	ecantransmit,
> +	ecanreceive
> +} can_transfer_direction;

The values are all unused, you only use the typedefs.
IMHO it would be more sensible to just pass these as unsigned int
or u32 values, but if you prefer, there is no reason to just do 

typedef u32 can_mailbox_number;

etc.

> +typedef struct {
> +	u16 u16extendedidentifier;
> +	u16 u16baseidentifier;
> +	u8 u8data7;
> +	u8 u8data6;
> +	u8 u8data5;
> +	u8 u8data4;
> +	u8 u8data3;
> +	u8 u8data2;
> +	u8 u8data1;
> +	u8 u8data0;
> +	u16 u16datalength;
> +	u16 u16crc;
> +} can_mail_box_structure;

Please don't use typedef for complex data structures, and learn about
better naming of identifiers. I would suggest writing this as

struct pru_can_mailbox {
	u16	ext_id;
	u16	base_id;
	u8	data[8]; /* note: reverse order */
	u16	len;
	u16	crc;
};

Sames rules apply to the other structures.

	Arnd

From synmyth at gmail.com  Fri Feb 18 09:42:56 2011
From: synmyth at gmail.com (Yinglin Luan)
Date: Fri, 18 Feb 2011 23:42:56 +0800
Subject: Kernel Memory Leak
In-Reply-To: <AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>
References: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>
	<AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>
Message-ID: <AANLkTimQFJ7Tfgb_Dnb-JBvo0PuVzPjNYByzZG616_Rd@mail.gmail.com>

On Fri, Feb 18, 2011 at 10:14 PM, Steve Chen <schen at mvista.com> wrote:

> On Fri, Feb 18, 2011 at 4:44 AM, Yinglin Luan <synmyth at gmail.com> wrote:
> > Hi, everyone
> >
> > I notice that the amount of free memory on my dm365 evm gets smaller and
> > smaller, so I enable CONFIG_DEBUG_KMEMLEAK in "Kernel hacking".When I do
> > 'cat /sys/kernel/debug/kmemleak', I get an output:
> >
> > unreferenced object 0xc12920c0 (size 192):
> >   comm "softirq", pid 0, jiffies 126399
> >   hex dump (first 32 bytes):
> >     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >     00 00 00 00 00 00 00 00 00 20 a4 c2 00 00 00 00  ......... ......
> >   backtrace:
> >     [<c00ab5d8>] __save_stack_trace+0x34/0x40
> >     [<c00ab6e8>] create_object+0x104/0x1fc
> >     [<c0326a90>] kmemleak_alloc+0x40/0x84
> >     [<c00a891c>] kmem_cache_alloc+0xf4/0x10c
> >     [<c028b028>] __alloc_skb+0x34/0x108
> >     [<c028bc7c>] dev_alloc_skb+0x20/0x44
> >     [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
> >     [<c02047e8>] emac_poll+0x244/0x5d0
> >     [<c0292af4>] net_rx_action+0xb4/0x274
> >     [<c004f648>] __do_softirq+0xb0/0x164
> >     [<c004f75c>] irq_exit+0x60/0xb8
> >     [<c0035074>] asm_do_IRQ+0x74/0x8c
> >     [<c0035ad8>] __irq_svc+0x58/0xa4
> >     [<c0036fac>] cpu_idle+0x80/0xf0
> >     [<c0326478>] rest_init+0x70/0x84
> >     [<c00089dc>] start_kernel+0x28c/0x2e4
> > unreferenced object 0xc2c34000 (size 2048):
> >   comm "softirq", pid 0, jiffies 126399
> >   hex dump (first 32 bytes):
> >     00 00 00 00 4c 37 f5 2b 6a 6a 19 63 98 82 08 00  ....L7.+jj.c....
> >     45 00 05 dc fd 34 20 b9 40 11 d2 a2 c0 a8 01 c8  E....4 . at .......
> >   backtrace:
> >     [<c00ab5d8>] __save_stack_trace+0x34/0x40
> >     [<c00ab6e8>] create_object+0x104/0x1fc
> >     [<c0326a90>] kmemleak_alloc+0x40/0x84
> >     [<c00a8fb0>] __kmalloc_track_caller+0x144/0x15c
> >     [<c028b048>] __alloc_skb+0x54/0x108
> >     [<c028bc7c>] dev_alloc_skb+0x20/0x44
> >     [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
> >     [<c02047e8>] emac_poll+0x244/0x5d0
> >     [<c0292af4>] net_rx_action+0xb4/0x274
> >     [<c004f648>] __do_softirq+0xb0/0x164
> >     [<c004f75c>] irq_exit+0x60/0xb8
> >     [<c0035074>] asm_do_IRQ+0x74/0x8c
> >     [<c0035ad8>] __irq_svc+0x58/0xa4
> >     [<c0036fac>] cpu_idle+0x80/0xf0
> >     [<c0326478>] rest_init+0x70/0x84
> >     [<c00089dc>] start_kernel+0x28c/0x2e4
> > ......
> > (the output is too long and the backtrace is almost the same as above)
> >
> > Is this real kernel memory leaks, or it's only transient?
>
> In general, the Linux kernel tries to cache as much data in memory as
> possible in order to improve performance.  Therefore, it is quite
> normal to see decreasing free memory over time.  As long as the kernel
> is able to free memory cache when needed, there are no issues.
>
> Regards,
>
> Steve
>

Thanks for your reply. Maybe the kernel caches sk_buff, but kmemleak
considers them as unreferenced object. I find that the addresses of the
"unreferenced object" reported by kmemleak always change, if they are real
memory leaks, the addresses should be fixed, am I right?

-- 
Yinglin Luan
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110218/7f55931e/attachment-0001.html>

From arnd at arndb.de  Fri Feb 18 09:44:17 2011
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 18 Feb 2011 16:44:17 +0100
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <1298041530-26855-2-git-send-email-pratheesh@ti.com>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
Message-ID: <201102181644.17634.arnd@arndb.de>

On Friday 18 February 2011, Pratheesh Gangadhar wrote:
> Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> 
> This patch implements PRUSS (Programmable Real-time Unit Sub System)
> UIO driver which exports SOC resources associated with PRUSS like
> I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
> processors which is efficient in performing embedded tasks that
> require manipulation of packed memory mapped data structures and
> efficient in handling system events that have tight real time
> constraints. This driver is currently supported on Texas Instruments
> DA850, AM18xx and OMAPL1-38 devices.
> For example, PRUSS runs firmware for real-time critical industrial
> communication data link layer and communicates with application stack
> running in user space via shared memory and IRQs.

Looks basically ok, but there are two limitations that I see that you
might consider fixing.

Oh, and you should put the Signed-off-by statement below the changelog,
not above it, but that has nothing to do with the code.

> +/*
> + * Host event IRQ numbers from PRUSS 	
> + * 3 PRU_EVTOUT0 PRUSS Interrupt
> + * 4 PRU_EVTOUT1 PRUSS Interrupt
> + * 5 PRU_EVTOUT2 PRUSS Interrupt
> + * 6 PRU_EVTOUT3 PRUSS Interrupt
> + * 7 PRU_EVTOUT4 PRUSS Interrupt
> + * 8 PRU_EVTOUT5 PRUSS Interrupt
> + * 9 PRU_EVTOUT6 PRUSS Interrupt
> + * 10 PRU_EVTOUT7 PRUSS Interrupt
> +*/
> +
> +#define MAX_PRUSS_EVTOUT_INSTANCE	(8)
> +
> +static struct clk *pruss_clk;
> +static struct uio_info *info[MAX_PRUSS_EVTOUT_INSTANCE];
> +static void *ddr_virt_addr;
> +static dma_addr_t ddr_phy_addr;

By making all of these static variables, you limit youself to
a single PRUSS instance in the system. It's generally better
to write device drivers in a way that makes it possible to
have multiple instances, e.g. by moving these four variables
into the 'priv' part of struct uio_info.

> +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> +{
> +	return IRQ_HANDLED;
> +}

An empty interrupt handler is rather pointless. I guess you really
notify user space when the interrupt handler gets called, as this
is the main point of a UIO driver as far as I understand it.

	Arnd

From schen at mvista.com  Fri Feb 18 10:21:44 2011
From: schen at mvista.com (Steve Chen)
Date: Fri, 18 Feb 2011 10:21:44 -0600
Subject: Kernel Memory Leak
In-Reply-To: <AANLkTimQFJ7Tfgb_Dnb-JBvo0PuVzPjNYByzZG616_Rd@mail.gmail.com>
References: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>
	<AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>
	<AANLkTimQFJ7Tfgb_Dnb-JBvo0PuVzPjNYByzZG616_Rd@mail.gmail.com>
Message-ID: <AANLkTimUuxe6zXJzdSgp+whZ8buQGcMh=HEvNtat9K_F@mail.gmail.com>

On Fri, Feb 18, 2011 at 9:42 AM, Yinglin Luan <synmyth at gmail.com> wrote:
>
> On Fri, Feb 18, 2011 at 10:14 PM, Steve Chen <schen at mvista.com> wrote:
>>
>> On Fri, Feb 18, 2011 at 4:44 AM, Yinglin Luan <synmyth at gmail.com> wrote:
>> > Hi, everyone
>> >
>> > I notice that the amount of free memory on my dm365 evm gets smaller and
>> > smaller, so I enable CONFIG_DEBUG_KMEMLEAK in "Kernel hacking".When I do
>> > 'cat /sys/kernel/debug/kmemleak', I get an output:
>> >
>> > unreferenced object 0xc12920c0 (size 192):
>> > ? comm "softirq", pid 0, jiffies 126399
>> > ? hex dump (first 32 bytes):
>> > ??? 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00? ................
>> > ??? 00 00 00 00 00 00 00 00 00 20 a4 c2 00 00 00 00? ......... ......
>> > ? backtrace:
>> > ??? [<c00ab5d8>] __save_stack_trace+0x34/0x40
>> > ??? [<c00ab6e8>] create_object+0x104/0x1fc
>> > ??? [<c0326a90>] kmemleak_alloc+0x40/0x84
>> > ??? [<c00a891c>] kmem_cache_alloc+0xf4/0x10c
>> > ??? [<c028b028>] __alloc_skb+0x34/0x108
>> > ??? [<c028bc7c>] dev_alloc_skb+0x20/0x44
>> > ??? [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
>> > ??? [<c02047e8>] emac_poll+0x244/0x5d0
>> > ??? [<c0292af4>] net_rx_action+0xb4/0x274
>> > ??? [<c004f648>] __do_softirq+0xb0/0x164
>> > ??? [<c004f75c>] irq_exit+0x60/0xb8
>> > ??? [<c0035074>] asm_do_IRQ+0x74/0x8c
>> > ??? [<c0035ad8>] __irq_svc+0x58/0xa4
>> > ??? [<c0036fac>] cpu_idle+0x80/0xf0
>> > ??? [<c0326478>] rest_init+0x70/0x84
>> > ??? [<c00089dc>] start_kernel+0x28c/0x2e4
>> > unreferenced object 0xc2c34000 (size 2048):
>> > ? comm "softirq", pid 0, jiffies 126399
>> > ? hex dump (first 32 bytes):
>> > ??? 00 00 00 00 4c 37 f5 2b 6a 6a 19 63 98 82 08 00? ....L7.+jj.c....
>> > ??? 45 00 05 dc fd 34 20 b9 40 11 d2 a2 c0 a8 01 c8? E....4 . at .......
>> > ? backtrace:
>> > ??? [<c00ab5d8>] __save_stack_trace+0x34/0x40
>> > ??? [<c00ab6e8>] create_object+0x104/0x1fc
>> > ??? [<c0326a90>] kmemleak_alloc+0x40/0x84
>> > ??? [<c00a8fb0>] __kmalloc_track_caller+0x144/0x15c
>> > ??? [<c028b048>] __alloc_skb+0x54/0x108
>> > ??? [<c028bc7c>] dev_alloc_skb+0x20/0x44
>> > ??? [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8
>> > ??? [<c02047e8>] emac_poll+0x244/0x5d0
>> > ??? [<c0292af4>] net_rx_action+0xb4/0x274
>> > ??? [<c004f648>] __do_softirq+0xb0/0x164
>> > ??? [<c004f75c>] irq_exit+0x60/0xb8
>> > ??? [<c0035074>] asm_do_IRQ+0x74/0x8c
>> > ??? [<c0035ad8>] __irq_svc+0x58/0xa4
>> > ??? [<c0036fac>] cpu_idle+0x80/0xf0
>> > ??? [<c0326478>] rest_init+0x70/0x84
>> > ??? [<c00089dc>] start_kernel+0x28c/0x2e4
>> > ......
>> > (the output is too long and the backtrace is almost the same as above)
>> >
>> > Is this real kernel memory leaks, or it's only transient?
>>
>> In general, the Linux kernel tries to cache as much data in memory as
>> possible in order to improve performance. ?Therefore, it is quite
>> normal to see decreasing free memory over time. ?As long as the kernel
>> is able to free memory cache when needed, there are no issues.
>>
>> Regards,
>>
>> Steve
>
> Thanks for your reply. Maybe the kernel caches sk_buff, but kmemleak
> considers them as unreferenced object. I find that the addresses of the
> "unreferenced object" reported by kmemleak always change, if they are real
> memory leaks, the addresses should be fixed, am I right?

I have not studied kmemleak, so I don't know the answer.

Regards,

Steve

From arnd at arndb.de  Fri Feb 18 10:31:05 2011
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 18 Feb 2011 17:31:05 +0100
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <alpine.LFD.2.00.1102181713480.2701@localhost6.localdomain6>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<201102181644.17634.arnd@arndb.de>
	<alpine.LFD.2.00.1102181713480.2701@localhost6.localdomain6>
Message-ID: <201102181731.05644.arnd@arndb.de>

On Friday 18 February 2011, Thomas Gleixner wrote:
> On Fri, 18 Feb 2011, Arnd Bergmann wrote:
> > On Friday 18 February 2011, Pratheesh Gangadhar wrote:
> > > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> > > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > > +{
> > > +   return IRQ_HANDLED;
> > > +}
> > 
> > An empty interrupt handler is rather pointless. I guess you really
> > notify user space when the interrupt handler gets called, as this
> > is the main point of a UIO driver as far as I understand it.
> 
> The UIO core code does this for you when the driver handler returns
> IRQ_HANDLED

Ah, right.

> but the empty handler raises a different questions:
> 
> Is the interrupt edge triggerd or how do you avoid an irq storm here?
> Usually UIO drivers are requested to mask the interrupt in the device
> itself.

If it's edge triggered, it should not advertise IRQF_SHARED, right?

	Arnd

From gregkh at suse.de  Fri Feb 18 11:05:38 2011
From: gregkh at suse.de (Greg KH)
Date: Fri, 18 Feb 2011 09:05:38 -0800
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <20110218163147.GD4684@local>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
	<20110218163147.GD4684@local>
Message-ID: <20110218170538.GB11773@suse.de>

On Fri, Feb 18, 2011 at 05:31:47PM +0100, Hans J. Koch wrote:
> On Fri, Feb 18, 2011 at 08:35:29PM +0530, Pratheesh Gangadhar wrote:
> > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>

As noted by others, this needs to go at the end of the changelog
comment.

Also, always run your patches through the scripts/checkpatch.pl script
and fix the warnings and errors it finds.  To not do so is just rude as
you are asking us to do the basic review work that you yourself did not
do in the first place.

> > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > +{
> > +	return IRQ_HANDLED;
> > +}
> 
> ROTFL. That reminds me of an old story. The last time I wrote this, and
> Greg dared to post it, we received this reply:
> 
> http://marc.info/?l=linux-kernel&m=116604101232144&w=2
> 
> So, if you really have a _very_ good reason why this _always_ works on
> _any_ DA850 board, add a comment that explains why. Otherwise the whole
> patch set will be doomed.

Nope, this whole patch set is doomed if this isn't fixed, I'm not going
to accept it no matter how much you want to try to say this is ok on
this hardware.

thanks,

greg k-h

From arnd at arndb.de  Fri Feb 18 12:51:32 2011
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 18 Feb 2011 19:51:32 +0100
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <alpine.LFD.2.00.1102181917520.2701@localhost6.localdomain6>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<20110218143500.23b3044b@lxorguk.ukuu.org.uk>
	<alpine.LFD.2.00.1102181917520.2701@localhost6.localdomain6>
Message-ID: <201102181951.32631.arnd@arndb.de>

On Friday 18 February 2011 19:23:49 Thomas Gleixner wrote:
> On Fri, 18 Feb 2011, Alan Cox wrote:
> 
> > On Fri, 18 Feb 2011 19:17:38 +0530
> > "Subhasish Ghosh" <subhasish at mistralsolutions.com> wrote:
> > 
> > > Hello,
> > > 
> > > Regarding the semaphore to mutex migration.
> > > We are using down_trylock in interrupt context,
> > > mutex_trylock cannot be used in interrupt context, so we cannot use mutex in 
> > > our driver.
> > 
> > Then you probably need to rework your locking. Best bet might be to fix
> > all the other stuff and report the driver, and people can think about the
> > locking problem.
> 
> That semaphore is utterly useless to begin with. There are more
> serious locking problems than this one. Non serialized calls to
> suart_intr_clrmask/suart_intr_setmask are the most obvious ones.
> 
> Aside of that the code is complete unreadable.

I think it mostly suffers from the same problem as the CAN driver
I commented on earlier: One of the files (pruss_suart_api.c) was
clearly not written with Linux as the target, and the other files
try to work around this by wrapping a Linux driver around it.

The suart_api HAL stuff clearly needs to go away, so that the rest
can be rewritten into a proper device driver.

	Arnd

From sshtylyov at mvista.com  Fri Feb 18 14:38:18 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 18 Feb 2011 23:38:18 +0300
Subject: [PATCH] DaVinci: fix compilation warnings in <mach/clkdev.h>
In-Reply-To: <201102092133.23765.sshtylyov@ru.mvista.com>
References: <201102092133.23765.sshtylyov@ru.mvista.com>
Message-ID: <4D5ED8BA.5000703@mvista.com>

Hello.

I wrote:

> Commit 6d803ba736abb5e122dede70a4720e4843dd6df4 (ARM: 6483/1: arm & sh:
> factorised duplicated clkdev.c) caused the following warnings:

> In file included from /home/headless/src/kernel.org/linux-davinci/arch/arm/
> include/asm/clkdev.h:17,
>                  from include/linux/clkdev.h:15,
>                  from arch/arm/mach-davinci/clock.h:71,
>                  from arch/arm/mach-davinci/common.c:22:
> arch/arm/mach-davinci/include/mach/clkdev.h:4: warning: `struct clk' declared
> inside parameter list
> arch/arm/mach-davinci/include/mach/clkdev.h:4: warning: its scope is only this
> definition or declaration, which is probably not what you want
> arch/arm/mach-davinci/include/mach/clkdev.h:9: warning: `struct clk' declared
> inside parameter list

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

> ---
> The patch is against the recent DaVinci tree.

>  arch/arm/mach-davinci/include/mach/clkdev.h |    2 ++
>  1 file changed, 2 insertions(+)

> Index: linux-davinci/arch/arm/mach-davinci/include/mach/clkdev.h
> ===================================================================
> --- linux-davinci.orig/arch/arm/mach-davinci/include/mach/clkdev.h
> +++ linux-davinci/arch/arm/mach-davinci/include/mach/clkdev.h
> @@ -1,6 +1,8 @@
>  #ifndef __MACH_CLKDEV_H
>  #define __MACH_CLKDEV_H
>  
> +struct clk;
> +
>  static inline int __clk_get(struct clk *clk)
>  {
>  	return 1;

    Kevin, Sekhar, will you apply this?

WBR, Sergei

From lamiaposta71 at gmail.com  Sat Feb 19 02:15:26 2011
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Sat, 19 Feb 2011 09:15:26 +0100
Subject: Kernel Memory Leak
In-Reply-To: <AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>
References: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>
	<AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>
Message-ID: <AANLkTinmeTekUG1zvBsmSooMYf4oAmH-BmaM2xAtLzV_@mail.gmail.com>

Hi Steve,

> In general, the Linux kernel tries to cache as much data in memory as
> possible in order to improve performance. ?Therefore, it is quite
> normal to see decreasing free memory over time. ?As long as the kernel
> is able to free memory cache when needed, there are no issues.

I saw many times free memory reducing in many arm systems.
Normally, for example when 3MB remain and I tried a malloc of 4MB
(writing also data in it .. because I don't trust 'disabling over
commit') the kernel frees tha pages needed and goes on.
If the ram is really finishing, the kernel kills, launching a function
called oom_killer (http://linux-mm.org/OOM_Killer), at least one
process, and then goes on.

I have create a small and easy memory mapper tool using a list of pointer.
When you press '+' on the cmdline 1MB are malloc'ed and filled of data.
The opposite when you press '-'.
So you are sure that the memory can be used.

I'm still searching instead a way to know how much memory can be used
without using it.
I'd like to work on a system with not enough ram to make every process
working simultaneously.

Hoping it helps,
Raffaele

From pratheesh at ti.com  Sat Feb 19 04:19:25 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Sat, 19 Feb 2011 15:49:25 +0530
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <201102181644.17634.arnd@arndb.de>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
	<201102181644.17634.arnd@arndb.de>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024B83C0DA@dbde02.ent.ti.com>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, February 18, 2011 9:14 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: TK, Pratheesh Gangadhar; davinci-linux-open-
> source at linux.davincidsp.com; gregkh at suse.de; Chatterjee, Amit;
> hjk at linutronix.de; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH 1/2] PRUSS UIO driver support
> 
> On Friday 18 February 2011, Pratheesh Gangadhar wrote:
> > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> >
> > This patch implements PRUSS (Programmable Real-time Unit Sub System)
> > UIO driver which exports SOC resources associated with PRUSS like
> > I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
> > processors which is efficient in performing embedded tasks that
> > require manipulation of packed memory mapped data structures and
> > efficient in handling system events that have tight real time
> > constraints. This driver is currently supported on Texas Instruments
> > DA850, AM18xx and OMAPL1-38 devices.
> > For example, PRUSS runs firmware for real-time critical industrial
> > communication data link layer and communicates with application stack
> > running in user space via shared memory and IRQs.
> 
> Looks basically ok, but there are two limitations that I see that you
> might consider fixing.
> 
> Oh, and you should put the Signed-off-by statement below the changelog,
> not above it, but that has nothing to do with the code.
> 
> > +/*
> > + * Host event IRQ numbers from PRUSS
> > + * 3 PRU_EVTOUT0 PRUSS Interrupt
> > + * 4 PRU_EVTOUT1 PRUSS Interrupt
> > + * 5 PRU_EVTOUT2 PRUSS Interrupt
> > + * 6 PRU_EVTOUT3 PRUSS Interrupt
> > + * 7 PRU_EVTOUT4 PRUSS Interrupt
> > + * 8 PRU_EVTOUT5 PRUSS Interrupt
> > + * 9 PRU_EVTOUT6 PRUSS Interrupt
> > + * 10 PRU_EVTOUT7 PRUSS Interrupt
> > +*/
> > +
> > +#define MAX_PRUSS_EVTOUT_INSTANCE	(8)
> > +
> > +static struct clk *pruss_clk;
> > +static struct uio_info *info[MAX_PRUSS_EVTOUT_INSTANCE];
> > +static void *ddr_virt_addr;
> > +static dma_addr_t ddr_phy_addr;
> 
> By making all of these static variables, you limit youself to
> a single PRUSS instance in the system. It's generally better
> to write device drivers in a way that makes it possible to
> have multiple instances, e.g. by moving these four variables
> into the 'priv' part of struct uio_info.

Ok, I agree with making them non-static. Making them part of uio_info might
not be desired. PRUSS_EVOUT_INSTANCE is not same as PRUSS instances. Each
PRUSS can have up to 8 event out interrupt lines to host ARM.
> 
> > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > +{
> > +	return IRQ_HANDLED;
> > +}
> 
> An empty interrupt handler is rather pointless. I guess you really
> notify user space when the interrupt handler gets called, as this
> is the main point of a UIO driver as far as I understand it.
> 
As discussed in the later E-mails, UIO core takes care of this.
Will cover this in following responses.

Thanks,
Pratheesh

From pratheesh at ti.com  Sat Feb 19 05:30:12 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Sat, 19 Feb 2011 17:00:12 +0530
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <20110218163147.GD4684@local>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
	<20110218163147.GD4684@local>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024B83C0E8@dbde02.ent.ti.com>

> -----Original Message-----
> From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> Sent: Friday, February 18, 2011 10:02 PM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; hjk at hansjkoch.de;
> gregkh at suse.de; Chatterjee, Amit; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 1/2] PRUSS UIO driver support
> 
> On Fri, Feb 18, 2011 at 08:35:29PM +0530, Pratheesh Gangadhar wrote:
> > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> >
> > This patch implements PRUSS (Programmable Real-time Unit Sub System)
> > UIO driver which exports SOC resources associated with PRUSS like
> > I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
> > processors which is efficient in performing embedded tasks that
> > require manipulation of packed memory mapped data structures and
> > efficient in handling system events that have tight real time
> > constraints. This driver is currently supported on Texas Instruments
> > DA850, AM18xx and OMAPL1-38 devices.
> > For example, PRUSS runs firmware for real-time critical industrial
> > communication data link layer and communicates with application stack
> > running in user space via shared memory and IRQs.
> 
> I see a few issues, comments below.
> 
> Thanks,
> Hans
> 
> > ---
> >  drivers/uio/Kconfig     |   10 ++
> >  drivers/uio/Makefile    |    1 +
> >  drivers/uio/uio_pruss.c |  250
> +++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 261 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/uio/uio_pruss.c
> >
> > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> > index bb44079..631ffe3 100644
> > --- a/drivers/uio/Kconfig
> > +++ b/drivers/uio/Kconfig
> > @@ -94,4 +94,14 @@ config UIO_NETX
> >  	  To compile this driver as a module, choose M here; the module
> >  	  will be called uio_netx.
> >
> > +config UIO_PRUSS
> > +	tristate "Texas Instruments PRUSS driver"
> > +	depends on ARCH_DAVINCI_DA850
> > +	default n
> 
> That line is unneccessary, "n" is already the default.
> 
Ok, will fix in the next version.
> > +	help
> > +	  PRUSS driver for OMAPL138/DA850/AM18XX devices
> > +	  PRUSS driver requires user space components
> > +	  To compile this driver as a module, choose M here: the module
> > +	  will be called uio_pruss.
> > +
> >  endif
> > +#define MAX_PRUSS_EVTOUT_INSTANCE	(8)
> 
> The brackets are not needed.
> 
Will fix in the next version.
> > +
> > +static struct clk *pruss_clk;
> > +static struct uio_info *info[MAX_PRUSS_EVTOUT_INSTANCE];
> 
> is it really neccessary to allocate that statically?
> 
> > +static void *ddr_virt_addr;
> > +static dma_addr_t ddr_phy_addr;
> > +
Agree - not necessary - will fix.

> > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > +{
> > +	return IRQ_HANDLED;
> > +}
> 
> ROTFL. That reminds me of an old story. The last time I wrote this, and
> Greg dared to post it, we received this reply:
> 
> http://marc.info/?l=linux-kernel&m=116604101232144&w=2
> 
> So, if you really have a _very_ good reason why this _always_ works on
> _any_ DA850 board, add a comment that explains why. Otherwise the whole
> patch set will be doomed.
> 
It always worked for me during the tests on the h/w. So did not bother to dig into the details then. From AM1808/AM1810 ARM Microprocessor System Reference Guide (http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprugm9a&fileType=pdf), section 11.3.1 Interrupt processing
The interrupt processing block does the following tasks:
	-Synchronization of slower and asynchronous interrupts
	- Conversion of polarity to active high
	- Conversion of interrupt type to pulse interrupts
After the processing block, all interrupts will be active-high pulses

Interrupt processing is the first step in INTC h/w which maps system interrupts to ARM (host) interrupts (FIQ, IRQ). 

However I am willing to clean this up to meet the kernel guidelines and good practices... 
> > +
> > +static int __devinit pruss_probe(struct platform_device *dev)
> > +{
> > +	int ret = -ENODEV;
> > +	int count = 0;
> > +	struct resource *regs_pruram, *regs_l3ram, *regs_ddr;
> > +	char *string;
> > +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
> > +		info[count]->mem[0].addr = regs_pruram->start;
> > +		info[count]->mem[0].size =
> > +		    regs_pruram->end - regs_pruram->start + 1;
> > +		if (!info[count]->mem[0].addr
> > +		    || !(info[count]->mem[0].size - 1)) {
> 
> That size check looks fishy. If somebody forgot to set the size it's OK ?
> 
size is set just previous line, right? If regs_prum_ram->end== regs_prum_ram->start - then there is something wrong... 

> > +			dev_err(&dev->dev, "Invalid memory resource\n");
> > +			break;
> > +		}
> > +		info[count]->mem[0].internal_addr =
> > +		    ioremap(regs_pruram->start, info[count]->mem[0].size);
> > +		if (!info[count]->mem[0].internal_addr) {
> > +			dev_err(&dev->dev,
> > +				"Can't remap memory address range\n");
> > +			break;
> > +		}
> > +		/* Register PRUSS IRQ lines */
> > +		info[count]->irq = IRQ_DA8XX_EVTOUT0 + count;
> > +
> > +		info[count]->irq_flags = IRQF_SHARED;
> 
> How do you handle shared interrupts with the handler above?
> 
> > +		info[count]->handler = pruss_handler;
> 
> And how do you make sure your interrupts are not level triggered? The
> handler above will hang for level triggered interrupts.

As mentioned above interrupt controller (ARM INTC) converts interrupt type to pulse. After required processing is complete - user space handler clears the interrupt from PRUSS.

Thanks,
Pratheesh

From pratheesh at ti.com  Sat Feb 19 06:47:19 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Sat, 19 Feb 2011 18:17:19 +0530
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <alpine.LFD.2.00.1102181715260.2701@localhost6.localdomain6>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
	<alpine.LFD.2.00.1102181715260.2701@localhost6.localdomain6>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024B83C0ED@dbde02.ent.ti.com>

> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx at linutronix.de]
> Sent: Friday, February 18, 2011 10:22 PM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; Hans J. Koch;
> gregkh at suse.de; Chatterjee, Amit; LKML; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 1/2] PRUSS UIO driver support
> 
> On Fri, 18 Feb 2011, Pratheesh Gangadhar wrote:
> > +/*
> > + * Host event IRQ numbers from PRUSS
> > + * 3 PRU_EVTOUT0 PRUSS Interrupt
> > + * 4 PRU_EVTOUT1 PRUSS Interrupt
> > + * 5 PRU_EVTOUT2 PRUSS Interrupt
> > + * 6 PRU_EVTOUT3 PRUSS Interrupt
> > + * 7 PRU_EVTOUT4 PRUSS Interrupt
> > + * 8 PRU_EVTOUT5 PRUSS Interrupt
> > + * 9 PRU_EVTOUT6 PRUSS Interrupt
> > + * 10 PRU_EVTOUT7 PRUSS Interrupt
> > +*/
> > +
> > +#define MAX_PRUSS_EVTOUT_INSTANCE	(8)
> > +
> > +static struct clk *pruss_clk;
> > +static struct uio_info *info[MAX_PRUSS_EVTOUT_INSTANCE];
> > +static void *ddr_virt_addr;
> > +static dma_addr_t ddr_phy_addr;
> > +
> > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > +{
> > +	return IRQ_HANDLED;
> 
>   See other mail.
> 
I responded in the other mail.

> > +}
> > +
> > +static int __devinit pruss_probe(struct platform_device *dev)
> > +{
> > +	int ret = -ENODEV;
> > +	int count = 0;
> 
>   Please make this one line.
> 
Sure, will do.
> > +	struct resource *regs_pruram, *regs_l3ram, *regs_ddr;
> > +	char *string;
> > +
> > +	/* Power on PRU in case its not done as part of boot-loader */
> > +	pruss_clk = clk_get(&dev->dev, "pruss");
> > +	if (IS_ERR(pruss_clk)) {
> > +		dev_err(&dev->dev, "Failed to get clock\n");
> > +		ret = PTR_ERR(pruss_clk);
> > +		pruss_clk = NULL;
> > +		return ret;
> > +	} else {
> > +		clk_enable(pruss_clk);
> > +	}
> > +
> > +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
> > +		info[count] = kzalloc(sizeof(struct uio_info), GFP_KERNEL);
> > +		if (!info[count])
> > +			return -ENOMEM;
> 
>   That leaks memory in case of count > 0
> 
Correct...
>   And this whole loop is crap:
> 
>   struct uio_info *info = kzalloc(sizeof(struct uio_info) *
> MAX_PRUSS_EVTOUT_INSTANCE,
>   	 	  	  	  GFP_KERNEL);
> 
>   perhaps ?
> 
Will do.
> > +	}
> > +
> > +	regs_pruram = platform_get_resource(dev, IORESOURCE_MEM, 0);
> > +	if (!regs_pruram) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +
> > +	regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
> > +	if (!regs_l3ram) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +
> > +	regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
> > +	if (!regs_ddr) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +	ddr_virt_addr =
> > +	    dma_alloc_coherent(&dev->dev, regs_ddr->end - regs_ddr->start +
> 1,
> > +			       &ddr_phy_addr, GFP_KERNEL | GFP_DMA);
> > +	if (!ddr_virt_addr) {
> > +		dev_err(&dev->dev, "Could not allocate external memory\n");
> > +		goto out_free;
> > +	}
> > +
> > +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
> > +		info[count]->mem[0].addr = regs_pruram->start;
> > +		info[count]->mem[0].size =
> > +		    regs_pruram->end - regs_pruram->start + 1;
> > +		if (!info[count]->mem[0].addr
> > +		    || !(info[count]->mem[0].size - 1)) {
> > +			dev_err(&dev->dev, "Invalid memory resource\n");
> > +			break;
> 
>   Is this break intentional ? Assume you have registered one uio
>   instance already then ret = 0 and you fall into the good path below.
> 
This is a bug. Will fix...
> > +		}
> > +		info[count]->mem[0].internal_addr =
> > +		    ioremap(regs_pruram->start, info[count]->mem[0].size);
> > +		if (!info[count]->mem[0].internal_addr) {
> > +			dev_err(&dev->dev,
> > +				"Can't remap memory address range\n");
> > +			break;
> 
>   Ditto
> 
> > +		}
> > +		info[count]->mem[0].memtype = UIO_MEM_PHYS;
> > +
> > +		info[count]->mem[1].addr = regs_l3ram->start;
> > +		info[count]->mem[1].size =
> > +		    regs_l3ram->end - regs_l3ram->start + 1;
> > +		if (!info[count]->mem[1].addr
> > +		    || !(info[count]->mem[1].size - 1)) {
> > +			dev_err(&dev->dev, "Invalid memory resource\n");
> > +			break;
> > +		}
> > +		info[count]->mem[1].internal_addr =
> > +		    ioremap(regs_l3ram->start, info[count]->mem[1].size);
> > +		if (!info[count]->mem[1].internal_addr) {
> > +			dev_err(&dev->dev,
> > +				"Can't remap memory address range\n");
> > +			break;
> > +		}
> > +		info[count]->mem[1].memtype = UIO_MEM_PHYS;
> > +
> > +		info[count]->mem[2].addr = ddr_phy_addr;
> > +		info[count]->mem[2].size = regs_ddr->end - regs_ddr->start +
> 1;
> > +		if (!info[count]->mem[2].addr
> > +		    || !(info[count]->mem[2].size - 1)) {
> > +			dev_err(&dev->dev, "Invalid memory resource\n");
> > +			break;
> 
>   This is silly. If ddr_virt_addr == NULL you never reach that code.
> 
Right... Will fix.
> 
> > +		}
> > +		info[count]->mem[2].internal_addr = ddr_virt_addr;
> > +		if (!info[count]->mem[2].internal_addr) {
> > +			dev_err(&dev->dev,
> > +				"Can't remap memory address range\n");
> 
>   This is silly. If ddr_virt_addr == NULL you never reach that code.
> 
Right... Will fix.
> > +			break;
> > +		}
> > +		info[count]->mem[2].memtype = UIO_MEM_PHYS;
> > +
> > +		string = kzalloc(20, GFP_KERNEL);
> > +		sprintf(string, "pruss_evt%d", count);
> > +		info[count]->name = string;
> > +		info[count]->version = "0.50";
> > +
> > +		/* Register PRUSS IRQ lines */
> > +		info[count]->irq = IRQ_DA8XX_EVTOUT0 + count;
> > +
> > +		info[count]->irq_flags = IRQF_SHARED;
> 
>   Huch. That can be shared ? Then you must in the interrupt handler
> 
>   1) check whether the interrupt is originated from your device
>   2) mask at the device level.
This interrupt is not shared. Must admit I am newbie to linux interrupt framework. 
> 
> > +		info[count]->handler = pruss_handler;
> > +
> > +		ret = uio_register_device(&dev->dev, info[count]);
> > +
> > +		if (ret < 0)
> > +			break;
> > +	}
> > +
> > +	if (ret < 0) {
> > +		if (ddr_virt_addr)
> > +			dma_free_coherent(&dev->dev,
> > +					  regs_ddr->end - regs_ddr->start + 1,
> > +					  ddr_virt_addr, ddr_phy_addr);
> > +		while (count--) {
> > +			uio_unregister_device(info[count]);
> > +			kfree(info[count]->name);
> > +			iounmap(info[count]->mem[0].internal_addr);
> 
>   Please move that section below the return 0 and use goto out_uio;
>   instead of break;
> 
>   This is real horrible.
> 
Ok, will do.
> > +		}
> > +	} else {
> > +		platform_set_drvdata(dev, info);
> > +		return 0;
> > +	}
> > +
> > +out_free:
> > +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++)
> > +		kfree(info[count]);
> > +
> > +	if (pruss_clk != NULL)
> > +		clk_put(pruss_clk);
> > +
> > +	return ret;
> > +}
> > +
> > +static int __devexit pruss_remove(struct platform_device *dev)
> > +{
> > +	int count = 0;
> > +	struct uio_info **info;
> > +
> > +	info = (struct uio_info **)platform_get_drvdata(dev);
> > +
> > +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
> > +		uio_unregister_device(info[count]);
> > +		kfree(info[count]->name);
> 
>   In the above error exit path you do:
> 
> 		iounmap(info[count]->mem[0].internal_addr);
> 
>   And in both cases you dont unmap info[count]->mem[1].internal_addr
> 
>   Why do you have those kernel mappings at all if you do not access
>   the device from this code ?
> 
I got this from existing UIO drivers which I used as reference. Should have paid more attention as this h/w is quite different...Was under the impression that ioremap is necessary for the user space access to those memory regions.
> > +
> > +	}
> > +	iounmap(info[0]->mem[0].internal_addr);
> > +	iounmap(info[0]->mem[1].internal_addr);
> 
>   Sigh
> 
> > +	if (ddr_virt_addr)
> > +		dma_free_coherent(&dev->dev, info[0]->mem[2].size,
> > +				  info[0]->mem[2].internal_addr,
> > +				  info[0]->mem[2].addr);
> > +
> > +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++)
> > +		kfree(info[count]);
> > +
> > +	platform_set_drvdata(dev, NULL);
> > +
> > +	if (pruss_clk != NULL)
> > +		clk_put(pruss_clk);
> > +	return 0;
> 
> So you have basically the same cleanup code twice with different bugs.
> Please avoid this kind of mistake which will happen with duplicated
> code. The right way to do that is creating a cleanup function and call
> them from both places.
> 
Agree and will fix this.
> You can call uio_unregister_device on a non registered info struct as
> well. So all it takes is:
> 
> 	if (ddr_virt_addr)
> 		dma_free_coherent(&dev->dev, info[0]->mem[2].size,
> 				  info[0]->mem[2].internal_addr,
> 				  info[0]->mem[2].addr);
> 
> 	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
>       	  	if (!info[count])
> 			break;
> 
> 		uio_unregister_device(info[count]);
> 		kfree(info[count]->name);
> 		...
> 		kfree(info[count]);
> 		info[count] = NULL;
>         }
> 
> 	platform_set_drvdata(dev, NULL);
> 
> 	if (pruss_clk)
> 		clk_put(pruss_clk);
> 
Thanks a lot for a detailed review. I will address these comments in the next revision of the patch... 

Thanks,
Pratheesh

From linux at arm.linux.org.uk  Sat Feb 19 07:26:42 2011
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 19 Feb 2011 13:26:42 +0000
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <1298041530-26855-2-git-send-email-pratheesh@ti.com>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
Message-ID: <20110219132642.GD29493@n2100.arm.linux.org.uk>

On Fri, Feb 18, 2011 at 08:35:29PM +0530, Pratheesh Gangadhar wrote:
> +static int __devinit pruss_probe(struct platform_device *dev)
> +{
> +	int ret = -ENODEV;
> +	int count = 0;
> +	struct resource *regs_pruram, *regs_l3ram, *regs_ddr;
> +	char *string;
> +
> +	/* Power on PRU in case its not done as part of boot-loader */
> +	pruss_clk = clk_get(&dev->dev, "pruss");
> +	if (IS_ERR(pruss_clk)) {
> +		dev_err(&dev->dev, "Failed to get clock\n");
> +		ret = PTR_ERR(pruss_clk);
> +		pruss_clk = NULL;

Delete this line.

...
> +out_free:
> +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++)
> +		kfree(info[count]);
> +
> +	if (pruss_clk != NULL)

	if (!IS_ERR(pruss_clk))

> +		clk_put(pruss_clk);
...
> +static int __devexit pruss_remove(struct platform_device *dev)
...
> +	platform_set_drvdata(dev, NULL);
> +
> +	if (pruss_clk != NULL)

	if (!IS_ERR(pruss_clk))

> +		clk_put(pruss_clk);

From pratheesh at ti.com  Sat Feb 19 09:40:23 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Sat, 19 Feb 2011 21:10:23 +0530
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <alpine.LFD.2.00.1102181802580.2701@localhost6.localdomain6>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<201102181644.17634.arnd@arndb.de>
	<alpine.LFD.2.00.1102181713480.2701@localhost6.localdomain6>
	<201102181731.05644.arnd@arndb.de>
	<alpine.LFD.2.00.1102181802580.2701@localhost6.localdomain6>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024B83C108@dbde02.ent.ti.com>

> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx at linutronix.de]
> Sent: Friday, February 18, 2011 10:33 PM
> To: Arnd Bergmann
> Cc: linux-arm-kernel at lists.infradead.org; TK, Pratheesh Gangadhar;
> davinci-linux-open-source at linux.davincidsp.com; gregkh at suse.de;
> Chatterjee, Amit; Hans J. Koch; LKML
> Subject: Re: [PATCH 1/2] PRUSS UIO driver support
> 
> On Fri, 18 Feb 2011, Arnd Bergmann wrote:
> 
> > On Friday 18 February 2011, Thomas Gleixner wrote:
> > > On Fri, 18 Feb 2011, Arnd Bergmann wrote:
> > > > On Friday 18 February 2011, Pratheesh Gangadhar wrote:
> > > > > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> > > > > +static irqreturn_t pruss_handler(int irq, struct uio_info
> *dev_info)
> > > > > +{
> > > > > +   return IRQ_HANDLED;
> > > > > +}
> > > >
> > > > An empty interrupt handler is rather pointless. I guess you really
> > > > notify user space when the interrupt handler gets called, as this
> > > > is the main point of a UIO driver as far as I understand it.
> > >
> > > The UIO core code does this for you when the driver handler returns
> > > IRQ_HANDLED
> >
> > Ah, right.
> >
> > > but the empty handler raises a different questions:
> > >
> > > Is the interrupt edge triggerd or how do you avoid an irq storm here?
> > > Usually UIO drivers are requested to mask the interrupt in the device
> > > itself.
> >
> > If it's edge triggered, it should not advertise IRQF_SHARED, right?
> 
> Nope. And the handler needs a fat comment why this works.

For my understanding - if the interrupt is not shared and not level triggered - is this okay to have empty handler? In this specific case, these interrupt lines are internal to SOC and hooked to ARM INTC from PRUSS. PRUSS has another INTC to handle system events to PRUSS as well as to generate system events to host ARM. These generated events are used for IPC between user application and PRU firmware and for async notifications from PRU firmware to user space. I don't see a reason to make it shared as we have 8 lines available for use. As mentioned before ARM INTC interrupt processing logic converts interrupts to active high pulses.

I also looked at the interrupt handling in existing UIO drivers


static irqreturn_t my_uio_handler(int irq, struct uio_info *dev_info)
{
        if (no interrupt is enabled and no interrupt is active) /For shared interrupt handling
                return IRQ_NONE;

        disable interrupt; // For level triggered interrupts 
        return IRQ_HANDLED;
}

It's not clear how and where interrupts are re-enabled. Is this expected to be done from user space?

Uio_secos3.c has an irqcontrol function to enable/disable interrupts. Is this the recommended approach?

Thanks and Regards,
Pratheesh

From pratheesh at ti.com  Sat Feb 19 10:06:22 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Sat, 19 Feb 2011 21:36:22 +0530
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <20110218170538.GB11773@suse.de>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
	<20110218163147.GD4684@local> <20110218170538.GB11773@suse.de>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024B83C10E@dbde02.ent.ti.com>

> -----Original Message-----
> From: Greg KH [mailto:gregkh at suse.de]
> Sent: Friday, February 18, 2011 10:36 PM
> To: TK, Pratheesh Gangadhar
> Cc: Hans J. Koch; davinci-linux-open-source at linux.davincidsp.com;
> Chatterjee, Amit; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 1/2] PRUSS UIO driver support
> 
> On Fri, Feb 18, 2011 at 05:31:47PM +0100, Hans J. Koch wrote:
> > On Fri, Feb 18, 2011 at 08:35:29PM +0530, Pratheesh Gangadhar wrote:
> > > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> 
> As noted by others, this needs to go at the end of the changelog
> comment.
> 
> Also, always run your patches through the scripts/checkpatch.pl script
> and fix the warnings and errors it finds.  To not do so is just rude as
> you are asking us to do the basic review work that you yourself did not
> do in the first place.

I actually ran checkpatch multiple times, but made some more changes before sending and missed to run again. Sorry about this. Will make sure these issues are fixed in the next version.
> 
> > > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > > +{
> > > +	return IRQ_HANDLED;
> > > +}
> >
> > ROTFL. That reminds me of an old story. The last time I wrote this, and
> > Greg dared to post it, we received this reply:
> >
> > http://marc.info/?l=linux-kernel&m=116604101232144&w=2
> >
> > So, if you really have a _very_ good reason why this _always_ works on
> > _any_ DA850 board, add a comment that explains why. Otherwise the whole
> > patch set will be doomed.
> 
> Nope, this whole patch set is doomed if this isn't fixed, I'm not going
> to accept it no matter how much you want to try to say this is ok on
> this hardware.
Okay. I had some queries in the previous mail. Will fix this once I am clear about the options.

Thanks,
Pratheesh

From schen at mvista.com  Sat Feb 19 11:47:26 2011
From: schen at mvista.com (Steve Chen)
Date: Sat, 19 Feb 2011 11:47:26 -0600
Subject: Kernel Memory Leak
In-Reply-To: <AANLkTinmeTekUG1zvBsmSooMYf4oAmH-BmaM2xAtLzV_@mail.gmail.com>
References: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>
	<AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>
	<AANLkTinmeTekUG1zvBsmSooMYf4oAmH-BmaM2xAtLzV_@mail.gmail.com>
Message-ID: <AANLkTi=_bCK0Pd3J0Tm0GJR6SbR5SHWeCw1DTBSOy_wT@mail.gmail.com>

On Sat, Feb 19, 2011 at 2:15 AM, Raffaele Recalcati
<lamiaposta71 at gmail.com> wrote:
> Hi Steve,
>
>> In general, the Linux kernel tries to cache as much data in memory as
>> possible in order to improve performance. ?Therefore, it is quite
>> normal to see decreasing free memory over time. ?As long as the kernel
>> is able to free memory cache when needed, there are no issues.
>
> I saw many times free memory reducing in many arm systems.
> Normally, for example when 3MB remain and I tried a malloc of 4MB
> (writing also data in it .. because I don't trust 'disabling over
> commit') the kernel frees tha pages needed and goes on.
> If the ram is really finishing, the kernel kills, launching a function
> called oom_killer (http://linux-mm.org/OOM_Killer), at least one
> process, and then goes on.

Yes, you are right that OOM killer helps to keep the kernel going by
killing off some tasks and free up memory.  The problem is that OOM
killer does not always make the best choice on the task to terminate.
OOM killer may (and often does) affect system stability and cause
unexpected behavior.

>
> I have create a small and easy memory mapper tool using a list of pointer.
> When you press '+' on the cmdline 1MB are malloc'ed and filled of data.
> The opposite when you press '-'.
> So you are sure that the memory can be used.
>
> I'm still searching instead a way to know how much memory can be used
> without using it.

I suspect some combination of  parameters in /proc/meminfo and
/proc/buddyinfo will give you that information.

> I'd like to work on a system with not enough ram to make every process
> working simultaneously.

This is certainly a very interesting engineering challenge to make the
system as small and as efficient as possible.  This is the type of
stuff we technical people live for.  However, we also need to be
sensitive to business side of things.  Due to rapidly declining price
of memory, the savings in memory may not justify the engineering cost.

>
> Hoping it helps,

Yes, thank you for sharing your insights.

Regards,

Steve

From lamiaposta71 at gmail.com  Sun Feb 20 07:17:21 2011
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Sun, 20 Feb 2011 14:17:21 +0100
Subject: Kernel Memory Leak
In-Reply-To: <AANLkTi=_bCK0Pd3J0Tm0GJR6SbR5SHWeCw1DTBSOy_wT@mail.gmail.com>
References: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>
	<AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>
	<AANLkTinmeTekUG1zvBsmSooMYf4oAmH-BmaM2xAtLzV_@mail.gmail.com>
	<AANLkTi=_bCK0Pd3J0Tm0GJR6SbR5SHWeCw1DTBSOy_wT@mail.gmail.com>
Message-ID: <AANLkTi=Mqppkdn5uRJcpMvS_8utNCZRWnOLYZWCsy2EJ@mail.gmail.com>

Hi Steve,

> OOM killer may (and often does) affect system stability and cause
> unexpected behavior.

We should have a daemon that re-stabilize the system in any case,
re-launching processes killed. But, obvioulsy, that daemon has not be
killed by oom_killer.

>> I have create a small and easy memory mapper tool using a list of pointer.
>> When you press '+' on the cmdline 1MB are malloc'ed and filled of data.
>> The opposite when you press '-'.
>> So you are sure that the memory can be used.
>>
>> I'm still searching instead a way to know how much memory can be used
>> without using it.
>
> I suspect some combination of ?parameters in /proc/meminfo and
> /proc/buddyinfo will give you that information.

I don't think so.
After startup the free memory decreases.
Even if you do some free call it doesn't increase, because of VFS
caching (nice for performance, not for know how much memory is really
free).
Maybe latest kernels are more sincer.

>Due to rapidly declining price
> of memory, the savings in memory may not justify the engineering cost.

You are absolutely right, but to know how much memory is really free I
think it is important.
At least I'd like to find any memory leakage, that can make our system
unstable even if with a lot of ram.

> Yes, thank you for sharing your insights.

nice,
Raffaele

From nsekhar at ti.com  Sun Feb 20 07:30:09 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Sun, 20 Feb 2011 19:00:09 +0530
Subject: Kernel Memory Leak
In-Reply-To: <AANLkTi=Mqppkdn5uRJcpMvS_8utNCZRWnOLYZWCsy2EJ@mail.gmail.com>
References: <AANLkTin2d0cp4yQsPp4KDJoHsJRhdByAryUb2w6JMaFt@mail.gmail.com>
	<AANLkTimxwmevTNGAGxuoWy8O57qV6WaNLv0U9syyzw29@mail.gmail.com>
	<AANLkTinmeTekUG1zvBsmSooMYf4oAmH-BmaM2xAtLzV_@mail.gmail.com>
	<AANLkTi=_bCK0Pd3J0Tm0GJR6SbR5SHWeCw1DTBSOy_wT@mail.gmail.com>
	<AANLkTi=Mqppkdn5uRJcpMvS_8utNCZRWnOLYZWCsy2EJ@mail.gmail.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024B83C160@dbde02.ent.ti.com>

Hi Raffaele,

On Sun, Feb 20, 2011 at 18:47:21, Raffaele Recalcati wrote:

> I don't think so.
> After startup the free memory decreases.
> Even if you do some free call it doesn't increase, because of VFS
> caching (nice for performance, not for know how much memory is really
> free).
> Maybe latest kernels are more sincer.

This command will drop the non-dirty caches:

$ echo 3 > /proc/sys/vm/drop_caches

Thanks,
Sekhar


From pratheesh at ti.com  Sun Feb 20 21:57:47 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Mon, 21 Feb 2011 09:27:47 +0530
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <20110219183427.GG4684@local>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<201102181644.17634.arnd@arndb.de>
	<alpine.LFD.2.00.1102181713480.2701@localhost6.localdomain6>
	<201102181731.05644.arnd@arndb.de>
	<alpine.LFD.2.00.1102181802580.2701@localhost6.localdomain6>
	<B85A65D85D7EB246BE421B3FB0FBB593024B83C108@dbde02.ent.ti.com>
	<20110219183427.GG4684@local>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024B83C20F@dbde02.ent.ti.com>

Hi Hans,

> -----Original Message-----
> From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> Sent: Sunday, February 20, 2011 12:04 AM
> To: TK, Pratheesh Gangadhar
> Cc: Thomas Gleixner; Arnd Bergmann; linux-arm-kernel at lists.infradead.org;
> davinci-linux-open-source at linux.davincidsp.com; gregkh at suse.de;
> Chatterjee, Amit; Hans J. Koch; LKML
> Subject: Re: [PATCH 1/2] PRUSS UIO driver support
> 
> On Sat, Feb 19, 2011 at 09:10:23PM +0530, TK, Pratheesh Gangadhar wrote:
> >
> > For my understanding - if the interrupt is not shared and not level
> triggered -
> > is this okay to have empty handler?
> 
> Greg already said he won't accept that. And I'm quite sure these
> interrupts
> are level triggered, since that is the default on arch/omap.
> 
> E.g. in arch/arm/mach-omap1/irq.c, a loop sets all irqs to level triggered
> handling: set_irq_handler(j, handle_level_irq); (line 234)

You should be looking at arch/arm/mach-davinci/irq.c and all interrupts except IRQ_TINT1_TINT34 is set to edge trigger mode (line 160).
> 
> > In this specific case, these interrupt lines are internal to SOC and
> hooked to ARM INTC from PRUSS. PRUSS has another INTC to handle system
> events to PRUSS as well as to generate system events to host ARM. These
> generated events are used for IPC between user application and PRU
> firmware and for async notifications from PRU firmware to user space. I
> don't see a reason to make it shared as we have 8 lines available for use.
> As mentioned before ARM INTC interrupt processing logic converts
> interrupts to active high pulses.
> 
> What's a "pulse triggered interrupt"? I know level and edge triggered
> ones.

Basically it's same as edge triggered.

Thanks,
Pratheesh

From nsekhar at ti.com  Mon Feb 21 06:13:06 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 21 Feb 2011 17:43:06 +0530
Subject: [PATCH] DaVinci: fix compilation warnings in <mach/clkdev.h>
In-Reply-To: <4D5ED8BA.5000703@mvista.com>
References: <201102092133.23765.sshtylyov@ru.mvista.com>
	<4D5ED8BA.5000703@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BD48A9B@dbde02.ent.ti.com>

Hi Sergei,

On Sat, Feb 19, 2011 at 02:08:18, Sergei Shtylyov wrote:

>     Kevin, Sekhar, will you apply this?

Last two weeks were pretty busy for me and there has been
a patch backlog. I started today with testing of Mike's SPI
patches.

I should get to your patches this week itself.

Thanks,
Sekhar


From sameo at linux.intel.com  Mon Feb 21 10:30:28 2011
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Mon, 21 Feb 2011 17:30:28 +0100
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
In-Reply-To: <1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <20110221163027.GF10686@sortiz-mobl>

Hi Subhasish,

On Fri, Feb 11, 2011 at 08:21:20PM +0530, Subhasish Ghosh wrote:
> This patch adds the pruss MFD driver and associated include files.
A more detailed changelog would be better. What is this device, why is it an
MFD and what are its potential subdevices ?

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index fd01836..6c437df 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
>  	  boards.  MSP430 firmware manages resets and power sequencing,
>  	  inputs from buttons and the IR remote, LEDs, an RTC, and more.
>  
> +config MFD_DA8XX_PRUSS
> +	tristate "Texas Instruments DA8XX PRUSS support"
> +	depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
Why are we depending on those ?


> +	select MFD_CORE
> +	help
> +	    This driver provides support api's for the programmable
> +		realtime unit (PRU) present on TI's da8xx processors. It
> +		provides basic read, write, config, enable, disable
> +		routines to facilitate devices emulated on it.
Please fix your identation here.

> --- /dev/null
> +++ b/drivers/mfd/da8xx_pru.c
> @@ -0,0 +1,446 @@
> +/*
> + * Copyright (C) 2010 Texas Instruments Incorporated
s/2010/2011/ ? 

> + * 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/init.h>
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/module.h>
> +#include <linux/bitops.h>
> +#include <linux/interrupt.h>
> +#include <linux/errno.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +#include <linux/mfd/pruss/da8xx_prucore.h>
> +#include <linux/mfd/pruss/da8xx_pru.h>
> +#include <linux/mfd/core.h>
> +#include <linux/io.h>
> +#include <mach/da8xx.h>
Is that include needed ?


> +struct da8xx_pruss {
What is the "ss" suffix for ?


> +u32 pruss_disable(struct device *dev, u8 pruss_num)
> +{
> +	struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
> +	da8xx_prusscore_regs h_pruss;
> +	u32 temp_reg;
> +
> +	if (pruss_num == DA8XX_PRUCORE_0) {
> +		/* Disable PRU0  */
> +		h_pruss = (da8xx_prusscore_regs)
> +			((u32) pruss->ioaddr + 0x7000);
So it seems you're doing this in several places, and I have a few comments:

- You don't need the da8xx_prusscore_regs at all.
- Define the register map through a set of #define in your header file.
- Use a static routine that takes the core number and returns the register map
offset.

Then routines like this one will look a lot more readable.

> +s16 pruss_writeb(struct device *dev, u32 u32offset,
> +		u8 *pu8datatowrite, u16 u16bytestowrite)
>From CodingStyle: "Encoding the type of a function into the name (so-called
Hungarian notation) is brain damaged"

Also, all your exported routines severely lack any sort of locking. An IO
mutex or spinlock is mandatory here. 

> +static int pruss_mfd_add_devices(struct platform_device *pdev)
> +{
> +	struct da8xx_pruss_devices *dev_data = pdev->dev.platform_data;
> +	struct device *dev = &pdev->dev;
> +	struct mfd_cell cell;
> +	u32 err, count;
> +
> +	for (count = 0; (dev_data + count)->dev_name != NULL; count++) {
> +		memset(&cell, 0, sizeof(struct mfd_cell));
> +		cell.id			= count;
> +		cell.name		= (dev_data + count)->dev_name;
> +		cell.platform_data	= (dev_data + count)->pdata;
> +		cell.data_size		= (dev_data + count)->pdata_size;
> +
> +		err = mfd_add_devices(dev, 0, &cell, 1, NULL, 0);
> +		if (err) {
> +			dev_err(dev, "cannot add mfd cells\n");
> +			return err;
> +		}
> +	}
> +	return err;
> +}
So, what are the potential subdevices for this driver ? If it's a really
dynamic setup, I'm fine with passing those as platform data but then do it so
that you pass a NULL terminated da8xx_pruss_devices array. That will avoid
most of the ugly casts you're doing here.

> diff --git a/include/linux/mfd/pruss/da8xx_pru.h b/include/linux/mfd/pruss/da8xx_pru.h
> new file mode 100644
> index 0000000..68d8421
> --- /dev/null
> +++ b/include/linux/mfd/pruss/da8xx_pru.h
> @@ -0,0 +1,122 @@
> +/*
> + * Copyright (C) 2010 Texas Instruments Incorporated
> + * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
> + *
> + * 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 _PRUSS_H_
> +#define _PRUSS_H_
> +
> +#include <linux/types.h>
> +#include <linux/platform_device.h>
> +#include "da8xx_prucore.h"
> +
> +#define PRUSS_NUM0			DA8XX_PRUCORE_0
> +#define PRUSS_NUM1			DA8XX_PRUCORE_1
Those are unused.

> diff --git a/include/linux/mfd/pruss/da8xx_prucore.h b/include/linux/mfd/pruss/da8xx_prucore.h
> new file mode 100644
> index 0000000..81f2ff9
> --- /dev/null
> +++ b/include/linux/mfd/pruss/da8xx_prucore.h
Please rename your mfd include directory to include/linux/mfd/da8xx/, so that
one can match it with the drivers/mfd/da8xx driver code.


> +typedef struct {
> +	u32 CONTROL;
> +	u32 STATUS;
> +	u32 WAKEUP;
> +	u32 CYCLECNT;
> +	u32 STALLCNT;
> +	u8  RSVD0[12];
> +	u32 CONTABBLKIDX0;
> +	u32 CONTABBLKIDX1;
> +	u32 CONTABPROPTR0;
> +	u32 CONTABPROPTR1;
> +	u8  RSVD1[976];
> +	u32 INTGPR[32];
> +	u32 INTCTER[32];
> +} *da8xx_prusscore_regs;
Again, we don't need that structure.

Cheers,
Samuel.


-- 
Intel Open Source Technology Centre
http://oss.intel.com/

From shilpab at spectrumdigital.com  Mon Feb 21 10:32:34 2011
From: shilpab at spectrumdigital.com (shilpab)
Date: Mon, 21 Feb 2011 08:32:34 -0800 (PST)
Subject: USB0 problem on OMAPL138
In-Reply-To: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
References: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
Message-ID: <1298305954111-6049272.post@n2.nabble.com>


Hi Marc,

We have been trying to test USB WIFI on OMAP L138 Logic PD board. I see from
your message that you have succeeded in doing so. Could you please help me
setup my kernel to achieve the above?

Q1. What do we need to turn on in the kernel to setup a WIFI?
Q2. Is there any special driver to be installed in the kernel to test on
D-Link DWA160A2 ?

Appreciate your help on this.

Thanks,
SHilpa.
-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/USB0-problem-on-OMAPL138-tp5559521p6049272.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From hebert.marcandre at gmail.com  Mon Feb 21 10:47:50 2011
From: hebert.marcandre at gmail.com (=?ISO-8859-1?Q?Marc=2DAndr=E9_H=E9bert?=)
Date: Mon, 21 Feb 2011 11:47:50 -0500
Subject: USB0 problem on OMAPL138
In-Reply-To: <1298305954111-6049272.post@n2.nabble.com>
References: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
	<1298305954111-6049272.post@n2.nabble.com>
Message-ID: <AANLkTinTUU8AMJSAeK1HyNWnQ4Bg2Z9EZDNmhBZN0umx@mail.gmail.com>

Hi,

Here are some of the instructions based on the notesI kept after
trying out the DWA-160A2:

Make sure the following options are set in the kernel:
CONFIG_NET
CONFIG_PACKET
CONFIG_INET
WIRELESS
CONFIG_CFG80211
CONFIG_MAC80211
CONFIG_NETDEVICES
CONFIG_WLAN
CONFIG_ATH_COMMON
CONFIG_AR9170_USB

Make sure the following options are set in busybox:
CONFIG_FEATURE_MDEV_LOAD_FIRMWARE

Download the firmware from
http://linuxwireless.org/en/users/Drivers/ar9170 and place it under
/lib/firmware/.

Build iwconfig.

You can connect to a WEP Wi-Fi router using:
ifconfig lo up
ifconfig wlan0 up
iwconfig wlan0 mode managed
iwconfig wlan0 essid "name"
iwconfig wlan0 key 10_digit_key
iwconfig wlan0 channel auto
udhcpc -i wlan0

Regards
Marc

From shilpab at spectrumdigital.com  Mon Feb 21 11:02:30 2011
From: shilpab at spectrumdigital.com (shilpab)
Date: Mon, 21 Feb 2011 09:02:30 -0800 (PST)
Subject: USB0 problem on OMAPL138
In-Reply-To: <AANLkTinTUU8AMJSAeK1HyNWnQ4Bg2Z9EZDNmhBZN0umx@mail.gmail.com>
References: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
	<1298305954111-6049272.post@n2.nabble.com>
	<AANLkTinTUU8AMJSAeK1HyNWnQ4Bg2Z9EZDNmhBZN0umx@mail.gmail.com>
Message-ID: <1298307750577-6049369.post@n2.nabble.com>


Thanks Marc for the quick reply. 

Shilpa.
-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/USB0-problem-on-OMAPL138-tp5559521p6049369.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From sshtylyov at mvista.com  Mon Feb 21 11:10:26 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Mon, 21 Feb 2011 20:10:26 +0300
Subject: [PATCH 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used
	by PRUSS UIO driver
In-Reply-To: <1298041530-26855-3-git-send-email-pratheesh@ti.com>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
	<1298041530-26855-3-git-send-email-pratheesh@ti.com>
Message-ID: <4D629C82.3080906@mvista.com>

Hello.

Pratheesh Gangadhar wrote:

> Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>

    Signoff should follow the change log, not precede it. "From:" line may 
precede the change log.

> This patch defines PRUSS, ECAP clocks, memory and IRQ resources
> used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
> driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
> DDR buffer to user space. PRUSS has 8 host event interrupt lines
> mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
> with shared memory can be used to implement IPC between ARM9 and
> PRUSS.

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 11f986b..ddcbac8 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
>  		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
>  				ret);
>  
> +	ret = da8xx_register_pruss();
> +       if (ret)
> +                pr_warning("da850_evm_init: pruss registration failed: %d\n",
> +                                 ret);
>  
>  	ret = da8xx_register_watchdog();
>  	if (ret)

    I'd put this into a pacth of its own, to have the SoC level changes 
separated from board-level changes...

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3443d97..0096d4f 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
>  	.flags		= ALWAYS_ENABLED,
>  };
>  
> +static struct clk pruss_clk = {
> +	.name		= "pruss",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC0_DMAX,

    We have patch submitted by TI that renames this #define to DA8XX_LPSC0_PRUSS...

> +	.flags		= ALWAYS_ENABLED,
> +};
> +

    We already have patch submitted by TI that defines this clock. It would be 
nice if you coordinated your efforts to avoid such conflicts.
    Again, I'd put the part adding the clocks into a patch of its own.

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index beda8a4..4ea3d1f 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
>  
>  	return platform_device_register(&da8xx_cpuidle_device);
>  }
> +static struct resource pruss_resources[] = {
> +	[0] = {
> +		.start  = DA8XX_PRUSS_BASE,
> +		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
> +		.flags  = IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start  = DA8XX_L3RAM_BASE,
> +		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
> +		.flags  = IORESOURCE_MEM,

    Are you going to use all SRAM?

> +	},
> +	[2] = {
> +		.start  = 0,
> +		.end    = SZ_256K - 1,
> +		.flags  = IORESOURCE_MEM,
> +	},
> +
> +	[3] = {
> +		.start  = IRQ_DA8XX_EVTOUT0,
> +		.end    = IRQ_DA8XX_EVTOUT0,
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +	[4] = {
> +		.start  = IRQ_DA8XX_EVTOUT1,
> +		.end    = IRQ_DA8XX_EVTOUT1,
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +	[5] = {
> +		.start  = IRQ_DA8XX_EVTOUT2,
> +		.end    = IRQ_DA8XX_EVTOUT2,
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +	[6] = {
> +		.start  = IRQ_DA8XX_EVTOUT3,
> +		.end    = IRQ_DA8XX_EVTOUT3,
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +	[7] = {
> +		.start  = IRQ_DA8XX_EVTOUT4,
> +		.end    = IRQ_DA8XX_EVTOUT4,
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +	[8] = {
> +		.start  = IRQ_DA8XX_EVTOUT5,
> +		.end    = IRQ_DA8XX_EVTOUT5,
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +	[9] = {
> +		.start  = IRQ_DA8XX_EVTOUT6,
> +		.end    = IRQ_DA8XX_EVTOUT6,
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +	[10] = {
> +		.start  = IRQ_DA8XX_EVTOUT7,
> +		.end    = IRQ_DA8XX_EVTOUT7,
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device pruss_device = {
> +	.name			= "pruss",
> +	.id			= 0,
> +	.num_resources		= ARRAY_SIZE(pruss_resources),
> +	.resource		= pruss_resources,
> +	.dev	 =	{
> +		.coherent_dma_mask = 0xffffffff,
> +	}
> +};
> +
> +int __init da8xx_register_pruss()
> +{
> +	return platform_device_register(&pruss_device);
> +}

    Again, there's TI patch that adds this device already...

WBR, Sergei

From pratheesh at ti.com  Mon Feb 21 11:35:14 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Mon, 21 Feb 2011 23:05:14 +0530
Subject: [PATCH v2 1/2] PRUSS UIO driver support
In-Reply-To: <1298309715-21362-1-git-send-email-pratheesh@ti.com>
References: <1298309715-21362-1-git-send-email-pratheesh@ti.com>
Message-ID: <1298309715-21362-2-git-send-email-pratheesh@ti.com>

This patch implements PRUSS (Programmable Real-time Unit Sub System)
UIO driver which exports SOC resources associated with PRUSS like
I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
processors which is efficient in performing embedded tasks that
require manipulation of packed memory mapped data structures and
efficient in handling system events that have tight real time
constraints. This driver is currently supported on Texas Instruments
DA850, AM18xx and OMAPL1-38 devices.
For example, PRUSS runs firmware for real-time critical industrial
communication data link layer and communicates with application stack
running in user space via shared memory and IRQs.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
---
 drivers/uio/Kconfig     |    9 ++
 drivers/uio/Makefile    |    1 +
 drivers/uio/uio_pruss.c |  231 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 241 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index bb44079..f92f20d 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -94,4 +94,13 @@ config UIO_NETX
 	  To compile this driver as a module, choose M here; the module
 	  will be called uio_netx.
 
+config UIO_PRUSS
+	tristate "Texas Instruments PRUSS driver"
+	depends on ARCH_DAVINCI_DA850
+	help
+	  PRUSS driver for OMAPL138/DA850/AM18XX devices
+	  PRUSS driver requires user space components
+	  To compile this driver as a module, choose M here: the module
+	  will be called uio_pruss.
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..d4dd9a5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC)	+= uio_aec.o
 obj-$(CONFIG_UIO_SERCOS3)	+= uio_sercos3.o
 obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
+obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
new file mode 100644
index 0000000..b402197
--- /dev/null
+++ b/drivers/uio/uio_pruss.c
@@ -0,0 +1,231 @@
+/*
+ * Programmable Real-Time Unit Sub System (PRUSS) UIO driver (uio_pruss)
+ *
+ * This driver exports PRUSS host event out interrupts and PRUSS, L3 RAM,
+ * and DDR RAM to user space for applications interacting with PRUSS firmware
+ *
+ * Copyright (C) 2010-11 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 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/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+
+#define DRV_NAME "pruss"
+#define DRV_VERSION "0.50"
+
+/*
+ * Host event IRQ numbers from PRUSS - PRUSS can generate upto 8 interrupt
+ * events to AINTC of ARM host processor - which can be used for IPC b/w PRUSS
+ * firmware and user space application, async notification from PRU firmware
+ * to user space application
+ * 3	PRU_EVTOUT0
+ * 4	PRU_EVTOUT1
+ * 5	PRU_EVTOUT2
+ * 6	PRU_EVTOUT3
+ * 7	PRU_EVTOUT4
+ * 8	PRU_EVTOUT5
+ * 9	PRU_EVTOUT6
+ * 10	PRU_EVTOUT7
+*/
+
+#define MAX_PRUSS_EVTOUT_INSTANCE	8
+
+#define	PRUSS_INTC_HIPIR		0x4900
+#define	PRUSS_INTC_HIPIR_INTPEND_MASK	0x80000000
+#define	PRUSS_INTC_HIER			0x5500
+
+struct clk *pruss_clk;
+struct uio_info *info;
+void *ddr_virt_addr;
+dma_addr_t ddr_phy_addr;
+
+static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
+{
+	void __iomem *int_enable_reg = dev_info->mem[0].internal_addr
+					+ PRUSS_INTC_HIER;
+	void __iomem *int_status_reg = dev_info->mem[0].internal_addr
+					+ PRUSS_INTC_HIPIR+((irq-1) << 2);
+	/* Is interrupt enabled and active ? */
+	if (!(ioread32(int_enable_reg) & (1<<(irq-1))) &&
+		 (ioread32(int_status_reg) & PRUSS_INTC_HIPIR_INTPEND_MASK))
+		return IRQ_NONE;
+
+	/* Disable interrupt */
+	iowrite32(ioread32(int_enable_reg) & ~(1<<(irq-1)),
+		int_enable_reg);
+	return IRQ_HANDLED;
+}
+
+static void pruss_cleanup(struct platform_device *dev, struct uio_info *info)
+{
+	int count;
+	if (info) {
+		for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
+			uio_unregister_device(&info[count]);
+			kfree(info[count].name);
+			iounmap(info[count].mem[0].internal_addr);
+
+		}
+		if (ddr_virt_addr)
+			dma_free_coherent(&dev->dev, info[0].mem[2].size,
+					  info[0].mem[2].internal_addr,
+					  info[0].mem[2].addr);
+		kfree(info);
+	}
+	if (pruss_clk != NULL)
+		clk_put(pruss_clk);
+}
+
+static int __devinit pruss_probe(struct platform_device *dev)
+{
+	int ret = -ENODEV, count = 0;
+	struct resource *regs_pruram, *regs_l3ram, *regs_ddr;
+	char *string;
+
+	/* Power on PRU in case its not done as part of boot-loader */
+	pruss_clk = clk_get(&dev->dev, "pruss");
+	if (IS_ERR(pruss_clk)) {
+		dev_err(&dev->dev, "Failed to get clock\n");
+		ret = PTR_ERR(pruss_clk);
+		return ret;
+	} else {
+		clk_enable(pruss_clk);
+	}
+
+	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVTOUT_INSTANCE,
+		       GFP_KERNEL);
+	if (info == NULL)
+		return -ENOMEM;
+
+	regs_pruram = platform_get_resource(dev, IORESOURCE_MEM, 0);
+	if (!regs_pruram) {
+		dev_err(&dev->dev, "No memory resource specified\n");
+		goto out_free;
+	}
+
+	regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
+	if (!regs_l3ram) {
+		dev_err(&dev->dev, "No memory resource specified\n");
+		goto out_free;
+	}
+
+	regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
+	if (!regs_ddr) {
+		dev_err(&dev->dev, "No memory resource specified\n");
+		goto out_free;
+	}
+	ddr_virt_addr =
+	    dma_alloc_coherent(&dev->dev, regs_ddr->end - regs_ddr->start + 1,
+			       &ddr_phy_addr, GFP_KERNEL | GFP_DMA);
+	if (!ddr_virt_addr) {
+		dev_err(&dev->dev, "Could not allocate external memory\n");
+		goto out_free;
+	}
+
+	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
+		info[count].mem[0].addr = regs_pruram->start;
+		info[count].mem[0].size =
+		    regs_pruram->end - regs_pruram->start + 1;
+		if (!info[count].mem[0].addr ||
+			!(info[count].mem[0].size - 1)) {
+			dev_err(&dev->dev, "Invalid memory resource\n");
+			goto out_free;
+		}
+		info[count].mem[0].internal_addr =
+		    ioremap(regs_pruram->start, info[count].mem[0].size);
+		if (!info[count].mem[0].internal_addr) {
+			dev_err(&dev->dev,
+				"Can't remap memory address range\n");
+			goto out_free;
+		}
+		info[count].mem[0].memtype = UIO_MEM_PHYS;
+
+		info[count].mem[1].addr = regs_l3ram->start;
+		info[count].mem[1].size =
+		    regs_l3ram->end - regs_l3ram->start + 1;
+		if (!info[count].mem[1].addr ||
+			!(info[count].mem[1].size - 1)) {
+			dev_err(&dev->dev, "Invalid memory resource\n");
+			goto out_free;
+		}
+		info[count].mem[1].memtype = UIO_MEM_PHYS;
+
+		info[count].mem[2].internal_addr = ddr_virt_addr;
+		info[count].mem[2].addr = ddr_phy_addr;
+		info[count].mem[2].size = regs_ddr->end - regs_ddr->start + 1;
+		info[count].mem[2].memtype = UIO_MEM_PHYS;
+
+		string = kzalloc(20, GFP_KERNEL);
+		sprintf(string, "pruss_evt%d", count);
+		info[count].name = string;
+		info[count].version = "0.50";
+
+		/* Register PRUSS IRQ lines */
+		info[count].irq = IRQ_DA8XX_EVTOUT0 + count;
+
+		info[count].irq_flags = 0;
+		info[count].handler = pruss_handler;
+
+		ret = uio_register_device(&dev->dev, &info[count]);
+
+		if (ret < 0)
+			goto out_free;
+	}
+
+	platform_set_drvdata(dev, info);
+	return 0;
+
+out_free:
+	pruss_cleanup(dev, info);
+	return ret;
+}
+
+static int __devexit pruss_remove(struct platform_device *dev)
+{
+	struct uio_info *info = platform_get_drvdata(dev);
+	pruss_cleanup(dev, info);
+	platform_set_drvdata(dev, NULL);
+	return 0;
+}
+
+static struct platform_driver pruss_driver = {
+	.probe = pruss_probe,
+	.remove = __devexit_p(pruss_remove),
+	.driver = {
+		   .name = DRV_NAME,
+		   .owner = THIS_MODULE,
+		   },
+};
+
+static int __init pruss_init_module(void)
+{
+	return platform_driver_register(&pruss_driver);
+}
+
+module_init(pruss_init_module);
+
+static void __exit pruss_exit_module(void)
+{
+	platform_driver_unregister(&pruss_driver);
+}
+
+module_exit(pruss_exit_module);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Amit Chatterjee <amit.chatterjee at ti.com>");
+MODULE_AUTHOR("Pratheesh Gangadhar <pratheesh at ti.com>");
-- 
1.6.0.6


From pratheesh at ti.com  Mon Feb 21 11:35:15 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Mon, 21 Feb 2011 23:05:15 +0530
Subject: [PATCH v2 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used by
	PRUSS UIO driver
In-Reply-To: <1298309715-21362-2-git-send-email-pratheesh@ti.com>
References: <1298309715-21362-1-git-send-email-pratheesh@ti.com>
	<1298309715-21362-2-git-send-email-pratheesh@ti.com>
Message-ID: <1298309715-21362-3-git-send-email-pratheesh@ti.com>

This patch defines PRUSS, ECAP clocks, memory and IRQ resources
used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
DDR buffer to user space. PRUSS has 8 host event interrupt lines
mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
with shared memory can be used to implement IPC between ARM9 and
PRUSS.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c    |    4 ++
 arch/arm/mach-davinci/da850.c              |   35 +++++++++++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 4 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..bd85aa3 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
 		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
 				ret);
 
+	ret = da8xx_register_pruss();
+	if (ret)
+		pr_warning("da850_evm_init: pruss registration failed: %d\n",
+				ret);
 
 	ret = da8xx_register_watchdog();
 	if (ret)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..0096d4f 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
 	.flags		= ALWAYS_ENABLED,
 };
 
+static struct clk pruss_clk = {
+	.name		= "pruss",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_DMAX,
+	.flags		= ALWAYS_ENABLED,
+};
+
 static struct clk uart0_clk = {
 	.name		= "uart0",
 	.parent		= &pll0_sysclk2,
@@ -359,6 +366,30 @@ static struct clk usb20_clk = {
 	.gpsc		= 1,
 };
 
+static struct clk ecap0_clk = {
+	.name		= "ecap0",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap1_clk = {
+	.name		= "ecap1",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap2_clk = {
+	.name		= "ecap2",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -386,6 +417,7 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tptc1",	&tptc1_clk),
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
+	CLK(NULL,		"pruss",	&pruss_clk),
 	CLK(NULL,		"uart0",	&uart0_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
@@ -403,6 +435,9 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"aemif",	&aemif_clk),
 	CLK(NULL,		"usb11",	&usb11_clk),
 	CLK(NULL,		"usb20",	&usb20_clk),
+	CLK(NULL,		"ecap0",	&ecap0_clk),
+	CLK(NULL,		"ecap1",	&ecap1_clk),
+	CLK(NULL,		"ecap2",	&ecap2_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..4ea3d1f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+static struct resource pruss_resources[] = {
+	[0] = {
+		.start  = DA8XX_PRUSS_BASE,
+		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[1] = {
+		.start  = DA8XX_L3RAM_BASE,
+		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[2] = {
+		.start  = 0,
+		.end    = SZ_256K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+
+	[3] = {
+		.start  = IRQ_DA8XX_EVTOUT0,
+		.end    = IRQ_DA8XX_EVTOUT0,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[4] = {
+		.start  = IRQ_DA8XX_EVTOUT1,
+		.end    = IRQ_DA8XX_EVTOUT1,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[5] = {
+		.start  = IRQ_DA8XX_EVTOUT2,
+		.end    = IRQ_DA8XX_EVTOUT2,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[6] = {
+		.start  = IRQ_DA8XX_EVTOUT3,
+		.end    = IRQ_DA8XX_EVTOUT3,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[7] = {
+		.start  = IRQ_DA8XX_EVTOUT4,
+		.end    = IRQ_DA8XX_EVTOUT4,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[8] = {
+		.start  = IRQ_DA8XX_EVTOUT5,
+		.end    = IRQ_DA8XX_EVTOUT5,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[9] = {
+		.start  = IRQ_DA8XX_EVTOUT6,
+		.end    = IRQ_DA8XX_EVTOUT6,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[10] = {
+		.start  = IRQ_DA8XX_EVTOUT7,
+		.end    = IRQ_DA8XX_EVTOUT7,
+		.flags  = IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device pruss_device = {
+	.name			= "pruss",
+	.id			= 0,
+	.num_resources		= ARRAY_SIZE(pruss_resources),
+	.resource		= pruss_resources,
+	.dev	 =	{
+		.coherent_dma_mask = 0xffffffff,
+	}
+};
+
+int __init da8xx_register_pruss()
+{
+	return platform_device_register(&pruss_device);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..3ed6ee0 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -60,6 +60,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_PLL0_BASE		0x01c11000
 #define DA8XX_TIMER64P0_BASE	0x01c20000
 #define DA8XX_TIMER64P1_BASE	0x01c21000
+#define DA8XX_PRUSS_BASE	0x01c30000
 #define DA8XX_GPIO_BASE		0x01e26000
 #define DA8XX_PSC1_BASE		0x01e27000
 #define DA8XX_LCD_CNTRL_BASE	0x01e13000
@@ -68,6 +69,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CS2_BASE	0x60000000
 #define DA8XX_AEMIF_CS3_BASE	0x62000000
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
+#define DA8XX_L3RAM_BASE	0x80000000
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
 
@@ -90,6 +92,7 @@ int da850_register_cpufreq(char *async_clk);
 int da8xx_register_cpuidle(void);
 void __iomem * __init da8xx_get_mem_ctlr(void);
 int da850_register_pm(struct platform_device *pdev);
+int da8xx_register_pruss(void);
 
 extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
-- 
1.6.0.6


From pratheesh at ti.com  Mon Feb 21 11:35:13 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Mon, 21 Feb 2011 23:05:13 +0530
Subject: [PATCH v2 0/2] Add PRUSS UIO driver support
Message-ID: <1298309715-21362-1-git-send-email-pratheesh@ti.com>

This patch series add support for PRUSS (Programmable Real-time Unit Sub
System) UIO driver in Texas Instruments DA850, AM18xx and OMAPL1-38 processors.
PRUSS is programmable RISC core which can be used to implement Soft IPs
(eg:- DMA, CAN, UART,SmartCard) and Industrial communications data link layers
(eg:- PROFIBUS). UIO driver exposes PRUSS resources like memory and 
interrupts to user space application.PRUSS UIO application API can be used 
to control PRUs in PRUSS, setup PRU INTC, load firmware to PRUs and implement
 IPC between Host processor and PRUs. More information on PRUSS and UIO linux
 user space API available in the links below

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide 


Pratheesh Gangadhar (2):
  PRUSS UIO driver support
  Defines DA850/AM18xx/OMAPL1-38 SOC resources used by PRUSS UIO driver

 arch/arm/mach-davinci/board-da850-evm.c    |    4 +
 arch/arm/mach-davinci/da850.c              |   35 ++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 +++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 drivers/uio/Kconfig                        |    9 +
 drivers/uio/Makefile                       |    1 +
 drivers/uio/uio_pruss.c                    |  231 ++++++++++++++++++++++++++++
 7 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c


From shilpab at spectrumdigital.com  Mon Feb 21 12:49:05 2011
From: shilpab at spectrumdigital.com (shilpab)
Date: Mon, 21 Feb 2011 10:49:05 -0800 (PST)
Subject: USB0 problem on OMAPL138
In-Reply-To: <1298307750577-6049369.post@n2.nabble.com>
References: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
	<1298305954111-6049272.post@n2.nabble.com>
	<AANLkTinTUU8AMJSAeK1HyNWnQ4Bg2Z9EZDNmhBZN0umx@mail.gmail.com>
	<1298307750577-6049369.post@n2.nabble.com>
Message-ID: <1298314145591-6049714.post@n2.nabble.com>


Marc,

Sorry for bothering you again. Couple of questions. 

1. Make sure the following options are set in busybox: 
CONFIG_FEATURE_MDEV_LOAD_FIRMWARE - Where can I find the source for busybox.

2. How do I build wconfig?

Thanks,
Shilpa
-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/USB0-problem-on-OMAPL138-tp5559521p6049714.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From hebert.marcandre at gmail.com  Mon Feb 21 12:54:19 2011
From: hebert.marcandre at gmail.com (=?ISO-8859-1?Q?Marc=2DAndr=E9_H=E9bert?=)
Date: Mon, 21 Feb 2011 13:54:19 -0500
Subject: USB0 problem on OMAPL138
In-Reply-To: <1298314145591-6049714.post@n2.nabble.com>
References: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
	<1298305954111-6049272.post@n2.nabble.com>
	<AANLkTinTUU8AMJSAeK1HyNWnQ4Bg2Z9EZDNmhBZN0umx@mail.gmail.com>
	<1298307750577-6049369.post@n2.nabble.com>
	<1298314145591-6049714.post@n2.nabble.com>
Message-ID: <AANLkTi=rHoR5m6_Q6+9LFi+NPNTDzWy=3bRdPex6zOWm@mail.gmail.com>

> 1. Make sure the following options are set in busybox:
> CONFIG_FEATURE_MDEV_LOAD_FIRMWARE - Where can I find the source for busybox.
>
> 2. How do I build wconfig?
I build iwconfig and busybox using buildroot. I don't know what you
use to build your root filesystem.

From sshtylyov at mvista.com  Mon Feb 21 13:53:04 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Mon, 21 Feb 2011 22:53:04 +0300
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <20110221193316.GC2773@local>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>	<201102181644.17634.arnd@arndb.de>	<alpine.LFD.2.00.1102181713480.2701@localhost6.localdomain6>	<201102181731.05644.arnd@arndb.de>	<alpine.LFD.2.00.1102181802580.2701@localhost6.localdomain6>	<B85A65D85D7EB246BE421B3FB0FBB593024B83C108@dbde02.ent.ti.com>	<20110219183427.GG4684@local>	<B85A65D85D7EB246BE421B3FB0FBB593024B83C20F@dbde02.ent.ti.com>
	<20110221193316.GC2773@local>
Message-ID: <4D62C2A0.6060405@mvista.com>

Hello.

Hans J. Koch wrote:

>>> -----Original Message-----
>>> From: Hans J. Koch [mailto:hjk at hansjkoch.de]
>>> Sent: Sunday, February 20, 2011 12:04 AM
>>> To: TK, Pratheesh Gangadhar
>>> Cc: Thomas Gleixner; Arnd Bergmann; linux-arm-kernel at lists.infradead.org;
>>> davinci-linux-open-source at linux.davincidsp.com; gregkh at suse.de;
>>> Chatterjee, Amit; Hans J. Koch; LKML
>>> Subject: Re: [PATCH 1/2] PRUSS UIO driver support

>>> On Sat, Feb 19, 2011 at 09:10:23PM +0530, TK, Pratheesh Gangadhar wrote:
>>>> For my understanding - if the interrupt is not shared and not level triggered -
>>>> is this okay to have empty handler?

>>> Greg already said he won't accept that. And I'm quite sure these
>>> interrupts
>>> are level triggered, since that is the default on arch/omap.

>>> E.g. in arch/arm/mach-omap1/irq.c, a loop sets all irqs to level triggered
>>> handling: set_irq_handler(j, handle_level_irq); (line 234)

>> You should be looking at arch/arm/mach-davinci/irq.c

    Into arch/arm/mach-davinci/cp_intc.c actually as we're not talking about a 
"real" DaVincis here, but about OMAP-L138.

> Hmpf. I alway get lost in the directory structure of TI SoCs...
> At least I learned that OMAP3 is in the omap2 directory :)

    It's probably even more convoluted with DaVinci and friends. :-)

>> and all interrupts except IRQ_TINT1_TINT34 is set to edge trigger mode (line 160).

> Is that really needed? Level triggered interrupts should certainly be
> preferred if possible.

    Don't look there, this code is for "real" DaVincis only.

> Thanks,
> Hans

WBR, Sergei

From shilpab at spectrumdigital.com  Mon Feb 21 14:05:09 2011
From: shilpab at spectrumdigital.com (shilpab)
Date: Mon, 21 Feb 2011 12:05:09 -0800 (PST)
Subject: USB0 problem on OMAPL138
In-Reply-To: <AANLkTi=rHoR5m6_Q6+9LFi+NPNTDzWy=3bRdPex6zOWm@mail.gmail.com>
References: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
	<1298305954111-6049272.post@n2.nabble.com>
	<AANLkTinTUU8AMJSAeK1HyNWnQ4Bg2Z9EZDNmhBZN0umx@mail.gmail.com>
	<1298307750577-6049369.post@n2.nabble.com>
	<1298314145591-6049714.post@n2.nabble.com>
	<AANLkTi=rHoR5m6_Q6+9LFi+NPNTDzWy=3bRdPex6zOWm@mail.gmail.com>
Message-ID: <1298318709085-6049926.post@n2.nabble.com>


We use already built arago-base-image filesystem that comes with the sdk. We
have never built a filesystem from scratch before. I'll try to look in the
arago website for building procedures. Please do let me know if you know of
any resources.

Thanks,
Shilpa.
-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/USB0-problem-on-OMAPL138-tp5559521p6049926.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From hebert.marcandre at gmail.com  Mon Feb 21 14:25:55 2011
From: hebert.marcandre at gmail.com (=?ISO-8859-1?Q?Marc=2DAndr=E9_H=E9bert?=)
Date: Mon, 21 Feb 2011 15:25:55 -0500
Subject: USB0 problem on OMAPL138
In-Reply-To: <1298318709085-6049926.post@n2.nabble.com>
References: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
	<1298305954111-6049272.post@n2.nabble.com>
	<AANLkTinTUU8AMJSAeK1HyNWnQ4Bg2Z9EZDNmhBZN0umx@mail.gmail.com>
	<1298307750577-6049369.post@n2.nabble.com>
	<1298314145591-6049714.post@n2.nabble.com>
	<AANLkTi=rHoR5m6_Q6+9LFi+NPNTDzWy=3bRdPex6zOWm@mail.gmail.com>
	<1298318709085-6049926.post@n2.nabble.com>
Message-ID: <AANLkTim2kOE+-YkPyem1g+JZhL2CTOHYy8wiDhO7439J@mail.gmail.com>

iwconfig is part of the wireless-tools package which can be found at :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/wireless_tools.29.tar.gz

Busybox can be found here: http://www.busybox.net/ but you may not
need to rebuild if what you have now supports loading firmware images.

There is one thing to watch out for: I've had problems when the
drivers are included directly in the kernel. Make sure the Wi-Fi is
unplugged when you boot up the device. Otherwise it seems the drivers
tries to request a firmware image before the root filesystem is
available and it created some issues.

Marc

From henryzhang62 at yahoo.com  Mon Feb 21 20:50:55 2011
From: henryzhang62 at yahoo.com (hong zhang)
Date: Mon, 21 Feb 2011 18:50:55 -0800 (PST)
Subject: Cortex A8 and DSP with audio
Message-ID: <27220.28242.qm@web161703.mail.bf1.yahoo.com>

List,

I have a TI DM8168 EVM which TI does not provide mechanism transfer audio between Cortex A8 and DSP using EDMA. McASP locates in sound/soc/davinci. 

Any idea where to look into?

Thanks.

---Henry


      

From subhasish at mistralsolutions.com  Mon Feb 21 23:43:38 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Tue, 22 Feb 2011 11:13:38 +0530
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
In-Reply-To: <20110221163027.GF10686@sortiz-mobl>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
	<20110221163027.GF10686@sortiz-mobl>
Message-ID: <37B3755C4AE64BAA805DFBAEBDC3D9E4@subhasishg>

Thank you for your comments.

--------------------------------------------------
From: "Samuel Ortiz" <sameo at linux.intel.com>
Sent: Monday, February 21, 2011 10:00 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>; 
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "open list" 
<linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 01/13] mfd: pruss mfd driver.

> Hi Subhasish,
>
> On Fri, Feb 11, 2011 at 08:21:20PM +0530, Subhasish Ghosh wrote:
>> This patch adds the pruss MFD driver and associated include files.
> A more detailed changelog would be better. What is this device, why is it 
> an
> MFD and what are its potential subdevices ?
>

SG -- Will add a more detailed change log.

>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index fd01836..6c437df 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
>>    boards.  MSP430 firmware manages resets and power sequencing,
>>    inputs from buttons and the IR remote, LEDs, an RTC, and more.
>>
>> +config MFD_DA8XX_PRUSS
>> + tristate "Texas Instruments DA8XX PRUSS support"
>> + depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
> Why are we depending on those ?

SG -- The PRUSS core in only available within DA850 and DA830,
            DA830 support is not yet implemented.

>
>
>> + select MFD_CORE
>> + help
>> +     This driver provides support api's for the programmable
>> + realtime unit (PRU) present on TI's da8xx processors. It
>> + provides basic read, write, config, enable, disable
>> + routines to facilitate devices emulated on it.
> Please fix your identation here.

SG -- Will do.

>
>> --- /dev/null
>> +++ b/drivers/mfd/da8xx_pru.c
>> @@ -0,0 +1,446 @@
>> +/*
>> + * Copyright (C) 2010 Texas Instruments Incorporated
> s/2010/2011/ ?
>
>> + * 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/init.h>
>> +#include <linux/kernel.h>
>> +#include <linux/types.h>
>> +#include <linux/module.h>
>> +#include <linux/bitops.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/errno.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/clk.h>
>> +#include <linux/mfd/pruss/da8xx_prucore.h>
>> +#include <linux/mfd/pruss/da8xx_pru.h>
>> +#include <linux/mfd/core.h>
>> +#include <linux/io.h>
>> +#include <mach/da8xx.h>
> Is that include needed ?

SG  - Will remove if not needed.

>
>
>> +struct da8xx_pruss {
> What is the "ss" suffix for ?

SG -- We call it the PRU Sub-System.

>
>
>> +u32 pruss_disable(struct device *dev, u8 pruss_num)
>> +{
>> + struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
>> + da8xx_prusscore_regs h_pruss;
>> + u32 temp_reg;
>> +
>> + if (pruss_num == DA8XX_PRUCORE_0) {
>> + /* Disable PRU0  */
>> + h_pruss = (da8xx_prusscore_regs)
>> + ((u32) pruss->ioaddr + 0x7000);
> So it seems you're doing this in several places, and I have a few 
> comments:
>
> - You don't need the da8xx_prusscore_regs at all.
> - Define the register map through a set of #define in your header file.
> - Use a static routine that takes the core number and returns the register 
> map
> offset.
>
> Then routines like this one will look a lot more readable.

SG -- There are a huge number of PRUSS registers. A lot of them are reserved 
and are expected to change as development on the
            controller is still ongoing. If we use #defines to plot all the 
registers, then first, there are too many array type registers which will 
need to be duplicated.
            And if the offset of one of the macro changes in between, we 
will require to adjust all the rest of the macros. So I felt like a 
structure was a better option here.
            I also named the structure elements as per the register names. 
so why should it be less readable ?  But, we can definitely use macros to 
define the PRUSS0 & 1
            offsets instead of the magic numbers as above.
>
>> +s16 pruss_writeb(struct device *dev, u32 u32offset,
>> + u8 *pu8datatowrite, u16 u16bytestowrite)
> From CodingStyle: "Encoding the type of a function into the name 
> (so-called
> Hungarian notation) is brain damaged"

SG -- Will change.
>
> Also, all your exported routines severely lack any sort of locking. An IO
> mutex or spinlock is mandatory here.

SG - As per our current implementation, we do not have two devices running 
simultaneously on the PRU,
        so we do not have any way to test it. We have kept this as an 
enhancement if request comes in for
        multiple devices.

>
>> +static int pruss_mfd_add_devices(struct platform_device *pdev)
>> +{
>> + struct da8xx_pruss_devices *dev_data = pdev->dev.platform_data;
>> + struct device *dev = &pdev->dev;
>> + struct mfd_cell cell;
>> + u32 err, count;
>> +
>> + for (count = 0; (dev_data + count)->dev_name != NULL; count++) {
>> + memset(&cell, 0, sizeof(struct mfd_cell));
>> + cell.id = count;
>> + cell.name = (dev_data + count)->dev_name;
>> + cell.platform_data = (dev_data + count)->pdata;
>> + cell.data_size = (dev_data + count)->pdata_size;
>> +
>> + err = mfd_add_devices(dev, 0, &cell, 1, NULL, 0);
>> + if (err) {
>> + dev_err(dev, "cannot add mfd cells\n");
>> + return err;
>> + }
>> + }
>> + return err;
>> +}
> So, what are the potential subdevices for this driver ? If it's a really
> dynamic setup, I'm fine with passing those as platform data but then do it 
> so
> that you pass a NULL terminated da8xx_pruss_devices array. That will avoid
> most of the ugly casts you're doing here.

SG -- I did not follow your recommendations here, could you please 
elaborate.
            I am already checking the dev_name for a NULL.
            This device is basically a microcontroller within DA850, so 
basically any device or protocol can be
            emulated on it. Currently, we have emulated 8 UARTS using the 
two PRUs and also a CAN device.
>
>> diff --git a/include/linux/mfd/pruss/da8xx_pru.h 
>> b/include/linux/mfd/pruss/da8xx_pru.h
>> new file mode 100644
>> index 0000000..68d8421
>> --- /dev/null
>> +++ b/include/linux/mfd/pruss/da8xx_pru.h
>> @@ -0,0 +1,122 @@
>> +/*
>> + * Copyright (C) 2010 Texas Instruments Incorporated
>> + * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
>> + *
>> + * 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 _PRUSS_H_
>> +#define _PRUSS_H_
>> +
>> +#include <linux/types.h>
>> +#include <linux/platform_device.h>
>> +#include "da8xx_prucore.h"
>> +
>> +#define PRUSS_NUM0 DA8XX_PRUCORE_0
>> +#define PRUSS_NUM1 DA8XX_PRUCORE_1
> Those are unused.

SG - These are getting used by the CAN & UART drivers.

>
>> diff --git a/include/linux/mfd/pruss/da8xx_prucore.h 
>> b/include/linux/mfd/pruss/da8xx_prucore.h
>> new file mode 100644
>> index 0000000..81f2ff9
>> --- /dev/null
>> +++ b/include/linux/mfd/pruss/da8xx_prucore.h
> Please rename your mfd include directory to include/linux/mfd/da8xx/, so 
> that
> one can match it with the drivers/mfd/da8xx driver code.

SG - Will do.

>
>
>> +typedef struct {
>> + u32 CONTROL;
>> + u32 STATUS;
>> + u32 WAKEUP;
>> + u32 CYCLECNT;
>> + u32 STALLCNT;
>> + u8  RSVD0[12];
>> + u32 CONTABBLKIDX0;
>> + u32 CONTABBLKIDX1;
>> + u32 CONTABPROPTR0;
>> + u32 CONTABPROPTR1;
>> + u8  RSVD1[976];
>> + u32 INTGPR[32];
>> + u32 INTCTER[32];
>> +} *da8xx_prusscore_regs;
> Again, we don't need that structure.

SG - As mentioned above.

>
> Cheers,
> Samuel.
>
>
> -- 
> Intel Open Source Technology Centre
> http://oss.intel.com/ 


From nsekhar at ti.com  Tue Feb 22 00:14:48 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 22 Feb 2011 11:44:48 +0530
Subject: [PATCH v2 3/6] davinci: da8xx: add spi resources and
	registration routine
In-Reply-To: <1297257114-764-4-git-send-email-michael.williamson@criticallink.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
	<1297257114-764-4-git-send-email-michael.williamson@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BD48E7B@dbde02.ent.ti.com>

Hi Mike,

On Wed, Feb 09, 2011 at 18:41:51, Michael Williamson wrote:
> Add IO resource structures, platform data, and a registration
> routine in order to support spi device on DA850/OMAP-L138/AM18x
> and DA830/OMAP-L137/AM17x platforms.
> 
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>

[...]

> +static struct resource da8xx_spi1_resources[] = {
> +	[0] = {
> +		.start	= DA8XX_SPI1_BASE,
> +		.end	= DA8XX_SPI1_BASE + SZ_4K -1,

checkpatch reports a warning here. Need to have spaces
on either side of binary '-'

I tested this series and the two patches it depends on
using SPI flash present on DA850 and DA830 EVMs (tested
in DMA mode) and found no issues.

So, with this minor issue fixed, can you please repost
with my Ack? You can include the two dependent patches
in the same series so it is easy to pick-up the whole
bunch.

Thanks,
Sekhar


From subhasish at mistralsolutions.com  Tue Feb 22 00:22:08 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Tue, 22 Feb 2011 11:52:08 +0530
Subject: [PATCH v2 11/13] da850: pruss SUART board specific additions.
In-Reply-To: <4D5584EC.4070506@mvista.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-12-git-send-email-subhasish@mistralsolutions.com>
	<4D5584EC.4070506@mvista.com>
Message-ID: <66FC4FA6F0A146B68ED19D473735C15D@subhasishg>

Hello,

Have modified this as shown below:
Please let me know if this looks ok.

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
+static struct da850_evm_pruss_can_data can_data = {
        .version        = 1,
 };

+static struct resource da850_evm_suart_resource[] = 
  ------------------------->>> Added a separate resource structure for 
suart.
+       {
+               .name   = "da8xx_mcasp0_iomem",
+               .start  = DAVINCI_DA8XX_MCASP0_REG_BASE,
+               .end    = DAVINCI_DA8XX_MCASP0_REG_BASE +
+                               (SZ_1K * 12) - 1,
+               .flags  = IORESOURCE_MEM,
+       },
+};
+
 static struct da8xx_pruss_devices pruss_devices[] = {
        {
                .dev_name       = "da8xx_pruss_can",
                .pdata          = &can_data,
                .pdata_size     = sizeof(can_data),
                .setup          = da850_evm_setup_pruss_can,
+               .num_resources  = 0,
+               .resources      = NULL,
        },
        {
                .dev_name       = "da8xx_pruss_uart",
                .pdata          = &suart_data,
                .pdata_size     = sizeof(suart_data),
                .setup          = da850_evm_setup_pruss_suart,
+               .num_resources  = ARRAY_SIZE(da850_evm_suart_resource),
+               .resources      = 
a850_evm_suart_resource,  ---------------------------- >>>>> Initialized it 
here
        },
        {
                .dev_name       = NULL,


diff --git a/drivers/mfd/da8xx_pru.c b/drivers/mfd/da8xx_pru.c
index f7868a4..140bf14 100644
--- a/drivers/mfd/da8xx_pru.c
+++ b/drivers/mfd/da8xx_pru.c
@@ -332,6 +332,8 @@ static int pruss_mfd_add_devices(struct platform_device 
*pdev)
                cell.name               = (dev_data + count)->dev_name;
                cell.platform_data      = (dev_data + count)->pdata;
                cell.data_size          = (dev_data + count)->pdata_size;
+               cell.resources          = (dev_data + 
ount)->resources;  ---------------------->>>Modified the MFD driver to add 
the resources.
+               cell.num_resources      = (dev_data + count)->num_resources;


diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart.c 
b/drivers/tty/serial/da8xx_pruss/pruss_suart.c

+       res = platform_get_resource(pdev, IORESOURCE_MEM, 
0); ------------------>> Used platform infrastructure to get the data.
+       if (!res) {
+               dev_err(&pdev->dev, "Failed to get resource");
+               return -ENOMEM;
+       }
+
+       if (!request_mem_region(res->start,
+                       resource_size(res),



--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov at mvista.com>
Sent: Saturday, February 12, 2011 12:20 AM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<sachi at mistralsolutions.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Kevin Hilman" <khilman at deeprootsystems.com>; <nsekhar at ti.com>; "open list" 
<linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 11/13] da850: pruss SUART board specific additions.

> Subhasish Ghosh wrote:
>
>> This patch adds the pruss SUART pin mux and registers the device
>> with the pruss mfd driver.
>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
>> ---
>>  arch/arm/mach-davinci/board-da850-evm.c |   36 
>> +++++++++++++++++++++++++++++++
>>  1 files changed, 36 insertions(+), 0 deletions(-)
>
>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
>> b/arch/arm/mach-davinci/board-da850-evm.c
>> index f9c38f8..3858516 100644
>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> [...]
>> @@ -1085,6 +1104,17 @@ static int __init da850_evm_setup_pruss_can(void)
>>  return ret;
>>  }
>>  +static struct da850_evm_pruss_suart_data suart_data = {
>> + .version = 1,
>> + .resource = {
>> + .name = "da8xx_mcasp0_iomem",
>> + .start = DAVINCI_DA8XX_MCASP0_REG_BASE,
>> + .end = DAVINCI_DA8XX_MCASP0_REG_BASE +
>> + (SZ_1K * 12) - 1,
>> + .flags = IORESOURCE_MEM,
>> + },
>> +};
>> +
>
>    I don't think passing a resource thru platform data is good idea... 
> Resources should be bound to the platform device.
>
> WBR, Sergei 


From nsekhar at ti.com  Tue Feb 22 00:37:59 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 22 Feb 2011 12:07:59 +0530
Subject: [PATCH v2 5/6] davinci: add spi devices support for
	da850/omap-l138/am18x evm
In-Reply-To: <1297257114-764-6-git-send-email-michael.williamson@criticallink.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
	<1297257114-764-6-git-send-email-michael.williamson@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BD48EB5@dbde02.ent.ti.com>

On Wed, Feb 09, 2011 at 18:41:53, Michael Williamson wrote:
> From: Sekhar Nori <nsekhar at ti.com>
> 
> This patch adds the on-board SPI flash device to the
> DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
> device to the MTD subsystem.
> 
> Based on SPI flash device support for MityDSP-L138F platform.
> 
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> [michael.williamson at criticallink.com: moved da850_evm_spi1_pdata to devices-da8xx.c]
> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
> +static void __init da850evm_init_spi1(struct spi_board_info *info, unsigned len)
> +{
> +	int ret;
> +
> +	ret = spi_register_board_info(info, len);
> +	if (ret)
> +		pr_warning("failed to register board info : %d\n", ret);
> +
> +	da8xx_spi_pdata[1].num_chipselect = len;
> +
> +	ret = da8xx_register_spi(1);
> +	if (ret)
> +		pr_warning("failed to register spi 1 device : %d\n", ret);
> +}

When reposting can you also modify this to print function name
with the error message (so it is easy to find what exactly failed).

The same thing needs to be done with DA830 EVM.

Rest of the stuff looks good to me.

Thanks,
Sekhar

From subhasish at mistralsolutions.com  Tue Feb 22 02:42:32 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Tue, 22 Feb 2011 14:12:32 +0530
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <201102181951.32631.arnd@arndb.de>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<20110218143500.23b3044b@lxorguk.ukuu.org.uk>
	<alpine.LFD.2.00.1102181917520.2701@localhost6.localdomain6>
	<201102181951.32631.arnd@arndb.de>
Message-ID: <9826735BD9DD48A599C595D28C4A05F0@subhasishg>

Hello,

I had kept separate files to affirm the modularity and ease of portability 
of the system.

There are three different interfaces,
1. The Linux driver interface
2. The PRU control interface
3. The McASP serializer interface.

To maintain modularity, I  had classified the files respectively as :
1.  pruss_suart.c
2.  pruss_suart_api.c
3.  pruss_suart_utils.c

This is not a single device which can be expressed as a single file,
but functionally different devices logically cascaded together to work in 
unison.

We use the PRU for packet processing, but the actual data is 
transmitted/received through the
McASP, which we use as a serializer.

I feel to combine these disparate functionalities into a single file will 
not

1. Help better understanding the device. I mean, why should a TTY UART 
driver be aware of the McASP or the PRU.
2. In case of a bug in the API layer or McASP, the driver need not be 
touched, thus improve maintainability.
3. If we need to port it to another Linux version, just editing the driver 
file should suffice, this will reduce bugs while porting.

To me, combining all of these into a single file only creates a mess. This 
is the reason I had separated them into different files!!
I don't understand why should it be better to have all of these into a 
single file.

--------------------------------------------------
From: "Arnd Bergmann" <arnd at arndb.de>
Sent: Saturday, February 19, 2011 12:21 AM
To: <linux-arm-kernel at lists.infradead.org>
Cc: "Thomas Gleixner" <tglx at linutronix.de>; "Alan Cox" 
<alan at lxorguk.ukuu.org.uk>; <sachi at mistralsolutions.com>; 
<davinci-linux-open-source at linux.davincidsp.com>; "Subhasish Ghosh" 
<subhasish at mistralsolutions.com>; "Greg Kroah-Hartman" <gregkh at suse.de>; 
<nsekhar at ti.com>; "open list" <linux-kernel at vger.kernel.org>; 
<m-watkins at ti.com>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver

> On Friday 18 February 2011 19:23:49 Thomas Gleixner wrote:
>> On Fri, 18 Feb 2011, Alan Cox wrote:
>>
>> > On Fri, 18 Feb 2011 19:17:38 +0530
>> > "Subhasish Ghosh" <subhasish at mistralsolutions.com> wrote:
>> >
>> > > Hello,
>> > >
>> > > Regarding the semaphore to mutex migration.
>> > > We are using down_trylock in interrupt context,
>> > > mutex_trylock cannot be used in interrupt context, so we cannot use 
>> > > mutex in
>> > > our driver.
>> >
>> > Then you probably need to rework your locking. Best bet might be to fix
>> > all the other stuff and report the driver, and people can think about 
>> > the
>> > locking problem.
>>
>> That semaphore is utterly useless to begin with. There are more
>> serious locking problems than this one. Non serialized calls to
>> suart_intr_clrmask/suart_intr_setmask are the most obvious ones.
>>
>> Aside of that the code is complete unreadable.
>
> I think it mostly suffers from the same problem as the CAN driver
> I commented on earlier: One of the files (pruss_suart_api.c) was
> clearly not written with Linux as the target, and the other files
> try to work around this by wrapping a Linux driver around it.
>
> The suart_api HAL stuff clearly needs to go away, so that the rest
> can be rewritten into a proper device driver.
>
> Arnd 


From subhasish at mistralsolutions.com  Tue Feb 22 02:43:21 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Tue, 22 Feb 2011 14:13:21 +0530
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <201102181951.32631.arnd@arndb.de>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<20110218143500.23b3044b@lxorguk.ukuu.org.uk>
	<alpine.LFD.2.00.1102181917520.2701@localhost6.localdomain6>
	<201102181951.32631.arnd@arndb.de>
Message-ID: <DADE3366197E4479A57F3B967A881C33@subhasishg>

I agree with the Codingstyle which needs to be fixed and would appreciate 
more feedback on it.

I have also gotten rid of the semaphore completely, please let me know what 
you feel of this implementation:
I have tested this without any problem.
What I am basically doing below is that, I am getting the data from the circ 
buff and then using the interrupt handler to
pump out the data. As the circ buff empties, I am accepting another request 
from the TTY.
Are you noticing any problems with this:

diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart.c 
b/drivers/tty/serial/da8xx_pruss/pruss_suart.c
index d222e2e..edc3863 100644
--- a/drivers/tty/serial/da8xx_pruss/pruss_suart.c
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart.c
@@ -72,7 +72,7 @@ struct suart_fifo {
 struct omapl_pru_suart {
        struct uart_port port[NR_SUART];
        struct device *dev; /* pdev->dev */
-       struct semaphore port_sem[NR_SUART];
+       bool tx_empty[NR_SUART];
        struct clk *clk_mcasp;
        struct suart_fifo suart_fifo_addr[NR_SUART];
        const struct firmware *fw;
@@ -122,13 +122,10 @@ static void omapl_pru_tx_chars(struct omapl_pru_suart 
*soft_uart, u32 uart_no)
        if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
                return;

-       if (down_trylock(&soft_uart->port_sem[uart_no]))
-               return;
-
        if (uart_circ_empty(xmit) ||
                        uart_tx_stopped(&soft_uart->port[uart_no])) {
                pruss_suart_stop_tx(&soft_uart->port[uart_no]);
-               up(&soft_uart->port_sem[uart_no]);
+               soft_uart->tx_empty[uart_no] = true;
                return;
        }

@@ -259,7 +256,6 @@ static irqreturn_t pruss_suart_interrupt(s32 irq, void 
*dev_id)
                        pru_intr_clr_isrstatus(dev, uart_num, PRU_TX_INTR);
                        pru_softuart_clr_tx_status(dev, 
&soft_uart->suart_hdl
                                                 [port->line]);
-                       up(&soft_uart->port_sem[port->line]);
                        omapl_pru_tx_chars(soft_uart, port->line);
                }
        } while (txrx_flag & (PRU_RX_INTR | PRU_TX_INTR));
@@ -294,7 +290,10 @@ static void pruss_suart_start_tx(struct uart_port 
*port)

        suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
                           PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
-       omapl_pru_tx_chars(soft_uart, port->line);
+       if (soft_uart->tx_empty[port->line] == true) {
+               soft_uart->tx_empty[port->line] = false;
+               omapl_pru_tx_chars(soft_uart, port->line);
+       }
 }


--------------------------------------------------
From: "Arnd Bergmann" <arnd at arndb.de>
Sent: Saturday, February 19, 2011 12:21 AM
To: <linux-arm-kernel at lists.infradead.org>
Cc: "Thomas Gleixner" <tglx at linutronix.de>; "Alan Cox" 
<alan at lxorguk.ukuu.org.uk>; <sachi at mistralsolutions.com>; 
<davinci-linux-open-source at linux.davincidsp.com>; "Subhasish Ghosh" 
<subhasish at mistralsolutions.com>; "Greg Kroah-Hartman" <gregkh at suse.de>; 
<nsekhar at ti.com>; "open list" <linux-kernel at vger.kernel.org>; 
<m-watkins at ti.com>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver

> On Friday 18 February 2011 19:23:49 Thomas Gleixner wrote:
>> On Fri, 18 Feb 2011, Alan Cox wrote:
>>
>> > On Fri, 18 Feb 2011 19:17:38 +0530
>> > "Subhasish Ghosh" <subhasish at mistralsolutions.com> wrote:
>> >
>> > > Hello,
>> > >
>> > > Regarding the semaphore to mutex migration.
>> > > We are using down_trylock in interrupt context,
>> > > mutex_trylock cannot be used in interrupt context, so we cannot use 
>> > > mutex in
>> > > our driver.
>> >
>> > Then you probably need to rework your locking. Best bet might be to fix
>> > all the other stuff and report the driver, and people can think about 
>> > the
>> > locking problem.
>>
>> That semaphore is utterly useless to begin with. There are more
>> serious locking problems than this one. Non serialized calls to
>> suart_intr_clrmask/suart_intr_setmask are the most obvious ones.
>>
>> Aside of that the code is complete unreadable.
>
> I think it mostly suffers from the same problem as the CAN driver
> I commented on earlier: One of the files (pruss_suart_api.c) was
> clearly not written with Linux as the target, and the other files
> try to work around this by wrapping a Linux driver around it.
>
> The suart_api HAL stuff clearly needs to go away, so that the rest
> can be rewritten into a proper device driver.
>
> Arnd 


From subhasish at mistralsolutions.com  Tue Feb 22 03:18:13 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Tue, 22 Feb 2011 14:48:13 +0530
Subject: [PATCH v2 12/13] da850: pruss SUART platform specific additions.
In-Reply-To: <4D55860E.3090908@mvista.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-13-git-send-email-subhasish@mistralsolutions.com>
	<4D55860E.3090908@mvista.com>
Message-ID: <B2D7D72494BB443F80DA08E22323999B@subhasishg>

Hello,

I could not follow your recommendations clearly, are you suggesting this:

int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
{
#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
        int ret;

        ret = clk_add_alias(NULL, "da8xx_pruss_uart.1",
                            NULL, &da850_mcasp_device.dev);
        if (ret < 0)
                return ret;
#endif
        da8xx_pruss_dev.dev.platform_data = pruss_device;
        return platform_device_register(&da8xx_pruss_dev);
}

--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov at mvista.com>
Sent: Saturday, February 12, 2011 12:25 AM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<sachi at mistralsolutions.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Kevin Hilman" <khilman at deeprootsystems.com>; <nsekhar at ti.com>; "open list" 
<linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 12/13] da850: pruss SUART platform specific 
additions.

> Subhasish Ghosh wrote:
>
>> This patch adds the McASP clock alias.
>> The alias is used by the pruss suart driver
>> for enabling the McASP PSC.
>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> [...]
>
>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
>> b/arch/arm/mach-davinci/devices-da8xx.c
>> index e15de72..f1cf605 100644
>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>> @@ -560,7 +560,18 @@ struct platform_device da8xx_pruss_dev = {
>>  int __init da8xx_register_pruss(struct da8xx_pruss_devices 
>> *pruss_device)
>>  {
>> +#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
>
>    #ifdef's in the function body are generally fromned upon.
>
>> + int ret;
>> +#endif
>> +
>
>    This line should have been inside #ifdef...
>
>>  da8xx_pruss_dev.dev.platform_data = pruss_device;
>> +
>> +#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
>
>    Why not do it before assigning the platform data and avoid extra 
> #ifdef?
>
>> + ret = clk_add_alias(NULL, "da8xx_pruss_uart.1",
>> + NULL, &da850_mcasp_device.dev);
>
>    This line should be indented more to the right.
>
>> + if (ret < 0)
>> + return ret;
>> +#endif
>
> WBR, Sergei 


From subhasish at mistralsolutions.com  Tue Feb 22 04:26:41 2011
From: subhasish at mistralsolutions.com (Subhasish)
Date: Tue, 22 Feb 2011 15:56:41 +0530
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <20110211162814.6ff274f1@lxorguk.ukuu.org.uk>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com><1297435892-28278-14-git-send-email-subhasish@mistralsolutions.com>
	<20110211162814.6ff274f1@lxorguk.ukuu.org.uk>
Message-ID: <A6D1CF0E941748448610BE8874FC586F@subhasishg>

--------------------------------------------------
From: "Alan Cox" <alan at lxorguk.ukuu.org.uk>
Sent: Friday, February 11, 2011 9:58 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>;
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>;
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "Greg Kroah-Hartman"
<gregkh at suse.de>; "open list" <linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver

> Don't see why it needs its own sub-directory

SG - We have two different layers of implementation. One is the driver
layer, which interacts with the TTY sub-system and the other is the API 
layer,
which interacts with the PRUSS. To maintain this (also explained in the 
other mail),
we used separate files and hence we decided to keep the code in a separate
directory so that the related files can be identified easily.

>
>
>
>> +#ifdef __SUART_DEBUG
>> +#define __suart_debug(fmt, args...) \
>> + printk(KERN_DEBUG "suart_debug: " fmt, ## args)
>> +#else
>> +#define __suart_debug(fmt, args...)
>> +#endif
>> +
>> +#define  __suart_err(fmt, args...) printk(KERN_ERR "suart_err: " fmt, ##
>> args)
>
> Use dev_dbg/dev_err/pr_debug/pr_err

SG - did you mean replace the printks above with dev_dgb/err or the 
suart_dbg/err.

>
>
>> +static void omapl_pru_tx_chars(struct omapl_pru_suart *soft_uart, u32
>> uart_no)
>> +{
>> + struct circ_buf *xmit = &soft_uart->port[uart_no].state->xmit;
>> + struct device *dev = soft_uart->dev;
>> + s32 count = 0;
>> +
>> + if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
>> + return;
>> +
>> + if (down_trylock(&soft_uart->port_sem[uart_no]))
>> + return;
>
> Please use a mutex not a semaphore. We are trying to get almost all the
> kernel using mutexes as it is needed for hard real time.

SG - Have removed, need your feedback.

>
>
>> + pru_softuart_read_data(dev, &soft_uart->suart_hdl[uart_no],
>> +        suart_data, data_len + 1,
>> +        &data_len_read);
>> +
>> + for (i = 0; i <= data_len_read; i++) {
>> + soft_uart->port[uart_no].icount.rx++;
>> + /* check for sys rq */
>> + if (uart_handle_sysrq_char
>> +     (&soft_uart->port[uart_no], suart_data))
>> + continue;
>> + }
>> + /* update the tty data structure */
>> + tty_insert_flip_string(tty, suart_data, data_len_read);
>
> You can avoid a copy here by using tty_prepare_flip_string()

SG - Ok, Thus this look ok ?
==================================================================================
--- a/drivers/tty/serial/da8xx_pruss/pruss_suart.c
+++ b/drivers/tty/serial/da8xx_pruss/pruss_suart.c
@@ -170,8 +170,9 @@ static void omapl_pru_rx_chars(struct omapl_pru_suart 
*soft_uart, u32 uart_no)
        s8 flags = TTY_NORMAL;
        u16 rx_status, data_len = SUART_FIFO_LEN;
        u32 data_len_read;
-       u8 suart_data[SUART_FIFO_LEN + 1];
+       u8 *suart_data = NULL;
        s32 i = 0;
+       s32 alloc_len = 0;

        if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_RX))
                return;
@@ -199,9 +200,10 @@ static void omapl_pru_rx_chars(struct omapl_pru_suart 
*soft_uart, u32 uart_no)
                soft_uart->port[uart_no].sysrq = 0;
 #endif
        } else {
+               alloc_len = tty_prepare_flip_string(tty, &suart_data, 
data_len + 1);
                pru_softuart_read_data(dev, &soft_uart->suart_hdl[uart_no],
-                                      suart_data, data_len + 1,
-                                      &data_len_read);
+                                               suart_data, alloc_len,
+                                               &data_len_read);

                for (i = 0; i <= data_len_read; i++) {
                        soft_uart->port[uart_no].icount.rx++;
@@ -210,8 +212,6 @@ static void omapl_pru_rx_chars(struct omapl_pru_suart 
*soft_uart, u32 uart_no)
                            (&soft_uart->port[uart_no], suart_data))
                                continue;
                }
-               /* update the tty data structure */
-               tty_insert_flip_string(tty, suart_data, data_len_read);
        }
============================================================================================

> Also please use the tty_port_tty_get/tty_kref_put interfaces so the tty
> refcounting is right

SG - Ok, Will do.

>
>
>> +static void pruss_suart_set_termios(struct uart_port *port,
>> +   struct ktermios *termios,
>> +   struct ktermios *old)
>> +{
>> + struct omapl_pru_suart *soft_uart =
>> +     container_of(port, struct omapl_pru_suart, port[port->line]);
>> + struct device *dev = soft_uart->dev;
>> + u8 cval = 0;
>> + unsigned long flags = 0;
>> + u32 baud = 0;
>> + u32 old_csize = old ? old->c_cflag & CSIZE : CS8;
>> +
>> +/*
>> + * Do not allow unsupported configurations to be set
>> + */
>> + if (1) {
>> + termios->c_cflag &= ~(HUPCL | CRTSCTS | CMSPAR | CSTOPB
>> +       | PARENB | PARODD | CMSPAR);
>> + termios->c_cflag |= CLOCAL;
>
> No. CLOCAL and HUPCL are user side flags. Apps expect to able to set them
> even if in fact they have no effect, so leave those two alone. The rest
> is fine.

SG -Ok, will do.

>
>
>> +/*
>> + * Characteres to ignore
>
> Typo
>

SG - ok.

>
>
>> diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
>> b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
>> new file mode 100644
>> index 0000000..d809dd3
>> --- /dev/null
>> +++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
>> @@ -0,0 +1,2350 @@
>> +/*
>> + * Copyright (C) 2010 Texas Instruments Incorporated
>> + * Author: Jitendra Kumar <jitendra at mistralsolutions.com>
>> + *
>> + * 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/types.h>
>> +#include <linux/mfd/pruss/da8xx_pru.h>
>> +#include <linux/io.h>
>> +#include <mach/hardware.h>
>> +#include "pruss_suart_api.h"
>> +#include "pruss_suart_regs.h"
>> +#include "pruss_suart_board.h"
>> +#include "pruss_suart_utils.h"
>> +#include "pruss_suart_err.h"
>> +
>> +static u8 g_uart_statu_table[8];
> Can you lose the g_, its  a windows naming convention we dont use

SG -- Ok, I can also see the Hungarian style like u32Offset, will get rid of 
these as well.
            Would really appreciate if you may please point me out more such 
problems.

>
>
>> +s16 pru_softuart_open(suart_handle h_suart)
>> +{
>
> If you just used normal integers you could surely make this routine
> trivial and remove all the duplication in the switches

SG -- Ok, will do.

>
>> + s16 status = PRU_SUART_SUCCESS;
>
> And please stick to Linux error codes

SG - Ok, Will do
>
>
>> +/* suart instance close routine */
>> +s16 pru_softuart_close(suart_handle h_uart)
>> +{
>> + s16 status = SUART_SUCCESS;
>> +
>> + if (h_uart == NULL) {
>> + return PRU_SUART_ERR_HANDLE_INVALID;
>
> Which is never checked. Far better to use WARN_ON and the like for such
> cases - or if like this one they don't appear to be possible to simply
> delete them

SG -- OK, does this look ok ?
=================================
if (h_uart == NULL) {
+WARN_ON(1);
- return PRU_SUART_ERR_HANDLE_INVALID;
+return -EINVAL;
}
=================================

>
>> + if ((tx_clk_divisor > 385) || (tx_clk_divisor == 0))
>> + return SUART_INVALID_CLKDIVISOR;
>> + if ((rx_clk_divisor > 385) || (rx_clk_divisor == 0))
>> + return SUART_INVALID_CLKDIVISOR;
>
> [minor] Lots of excess brackets

Ok - Will do.
>
>
>> + u32offset = (u32) (PRUSS_INTC_CHANMAP9 & 0xFFFF);
>> + u32value = PRU_INTC_CHAN_34_SYSEVT_36_39;
>> + s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
>> + if (-1 == s16retval)
>> + return -1;
>
> If you fixed the API here you'd be able to just write
>
> if (pruss_writel(dev, PRUSS_INTC_CHANMAP9 & 0xFFFF,
> PRU_INTC_BLAH)
>
> or similar which would clean up a lot of messy code and shrink it
> dramatically. Given you have lots of series of writes some kind of
>
> pruss_writel_multi(dev, array, len)
>
> that took an array of addr/value pairs might also clean up a ton of code
> and turn it into trivial tables

SG -- Will shrink this function.

> 

Please do not print this email unless it is absolutely necessary. Spread environmental awareness.

-------------------------------------------------------DISCLAIMER------------------------------------------------------
The information transmitted herewith is confidential and proprietary information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
---------------------------------------------------------------------------------------------------------------------------


From sameo at linux.intel.com  Tue Feb 22 04:31:27 2011
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 22 Feb 2011 11:31:27 +0100
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
In-Reply-To: <37B3755C4AE64BAA805DFBAEBDC3D9E4@subhasishg>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
	<20110221163027.GF10686@sortiz-mobl>
	<37B3755C4AE64BAA805DFBAEBDC3D9E4@subhasishg>
Message-ID: <20110222103127.GC30279@sortiz-mobl>

Hi Subhasish,

On Tue, Feb 22, 2011 at 11:13:38AM +0530, Subhasish Ghosh wrote:
> Thank you for your comments.
No problem.

> >>diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >>index fd01836..6c437df 100644
> >>--- a/drivers/mfd/Kconfig
> >>+++ b/drivers/mfd/Kconfig
> >>@@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
> >>   boards.  MSP430 firmware manages resets and power sequencing,
> >>   inputs from buttons and the IR remote, LEDs, an RTC, and more.
> >>
> >>+config MFD_DA8XX_PRUSS
> >>+ tristate "Texas Instruments DA8XX PRUSS support"
> >>+ depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
> >Why are we depending on those ?
> 
> SG -- The PRUSS core in only available within DA850 and DA830,
>            DA830 support is not yet implemented.
Sure, but if there are no actual code dependencies, I'd like to get rid of
those depends.

> >>+u32 pruss_disable(struct device *dev, u8 pruss_num)
> >>+{
> >>+ struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
> >>+ da8xx_prusscore_regs h_pruss;
> >>+ u32 temp_reg;
> >>+
> >>+ if (pruss_num == DA8XX_PRUCORE_0) {
> >>+ /* Disable PRU0  */
> >>+ h_pruss = (da8xx_prusscore_regs)
> >>+ ((u32) pruss->ioaddr + 0x7000);
> >So it seems you're doing this in several places, and I have a few
> >comments:
> >
> >- You don't need the da8xx_prusscore_regs at all.
> >- Define the register map through a set of #define in your header file.
> >- Use a static routine that takes the core number and returns the
> >register map
> >offset.
> >
> >Then routines like this one will look a lot more readable.
> 
> SG -- There are a huge number of PRUSS registers. A lot of them are
> reserved and are expected to change as development on the
>            controller is still ongoing. 
First of all, from what I read in your patch you're only using the CONTROL
offset.

> If we use #defines to plot
> all the registers, then first, there are too many array type
> registers which will need to be duplicated.
What I'm expecting is a small set of defines for the register offsets. You
have 13 fields in your da8xx_prusscore_regs, you only need to define 13
register offsets.

So, if you have a:

static u32 reg_offset(struct device *dev, u8 pru_num)
{
	struct da8xx_pruss *pru = dev_get_drvdata(dev->parent);

	switch (pru_num) {
	case DA8XX_PRUCORE_0:
		return (u32) pru->ioaddr + 0x7000;
	case DA8XX_PRUCORE_1:
		return (u32) pru->ioaddr + 0x7800;
	default:
		return 0;
}


then routines like pruss_enable (which should return an int, btw) would look
like:

int pruss_enable(struct device *dev, u8 pruss_num)
{
	u32 offset = reg_offset(dev, pruss_num);

	if (offset == 0)
		return -EINVAL;

	__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
			offset + PRU_CORE_CONTROL);

	return 0;
}

> >Also, all your exported routines severely lack any sort of locking. An IO
> >mutex or spinlock is mandatory here.
> 
> SG - As per our current implementation, we do not have two devices
> running simultaneously on the PRU,
>        so we do not have any way to test it. We have kept this as an
> enhancement if request comes in for
>        multiple devices.
It's not about having multiple devices at the same time, it's about having
multiple callers writing and reading to the same registers. Since you're
exporting all your I/O routines you have no way to prevent 2 drivers from
writing to the same register at the "same" time. You need locking here,
regardless of the number of devices that you can have on a system.

 
> >>+static int pruss_mfd_add_devices(struct platform_device *pdev)
> >>+{
> >>+ struct da8xx_pruss_devices *dev_data = pdev->dev.platform_data;
> >>+ struct device *dev = &pdev->dev;
> >>+ struct mfd_cell cell;
> >>+ u32 err, count;
> >>+
> >>+ for (count = 0; (dev_data + count)->dev_name != NULL; count++) {
> >>+ memset(&cell, 0, sizeof(struct mfd_cell));
> >>+ cell.id = count;
> >>+ cell.name = (dev_data + count)->dev_name;
> >>+ cell.platform_data = (dev_data + count)->pdata;
> >>+ cell.data_size = (dev_data + count)->pdata_size;
> >>+
> >>+ err = mfd_add_devices(dev, 0, &cell, 1, NULL, 0);
> >>+ if (err) {
> >>+ dev_err(dev, "cannot add mfd cells\n");
> >>+ return err;
> >>+ }
> >>+ }
> >>+ return err;
> >>+}
> >So, what are the potential subdevices for this driver ? If it's a really
> >dynamic setup, I'm fine with passing those as platform data but
> >then do it so
> >that you pass a NULL terminated da8xx_pruss_devices array. That will avoid
> >most of the ugly casts you're doing here.
> 
> SG -- I did not follow your recommendations here, could you please
> elaborate.
>            I am already checking the dev_name for a NULL.
>            This device is basically a microcontroller within DA850,
> so basically any device or protocol can be
>            emulated on it. Currently, we have emulated 8 UARTS using
> the two PRUs and also a CAN device.
Ok, I wasnt sure you can emulate anything on that thing. So I'm fine with you
passing all your devices through platform_data. But I'd prefer this routine to
look like:

[...]
	for (count = 0; dev_data[count] != NULL; count++) {
		memset(&cell, 0, sizeof(struct mfd_cell));
		cell.id			= count;
		cell.name		= dev_data[count]->dev_name;
		cell.platform_data	= dev_data[count]->pdata;
		cell.data_size		= dev_data[count]->pdata_size;

Looks nicer to me.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

From alan at lxorguk.ukuu.org.uk  Tue Feb 22 05:11:03 2011
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Tue, 22 Feb 2011 11:11:03 +0000
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <A6D1CF0E941748448610BE8874FC586F@subhasishg>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-14-git-send-email-subhasish@mistralsolutions.com>
	<20110211162814.6ff274f1@lxorguk.ukuu.org.uk>
	<A6D1CF0E941748448610BE8874FC586F@subhasishg>
Message-ID: <20110222111103.5d0dd0a7@lxorguk.ukuu.org.uk>

> we used separate files and hence we decided to keep the code in a separate
> directory so that the related files can be identified easily.

Fair enough but I would have thought you could drop the two files in the
serial directory if they have obviously related names- trivial item/
> 
> >
> >
> >
> >> +#ifdef __SUART_DEBUG
> >> +#define __suart_debug(fmt, args...) \
> >> + printk(KERN_DEBUG "suart_debug: " fmt, ## args)
> >> +#else
> >> +#define __suart_debug(fmt, args...)
> >> +#endif
> >> +
> >> +#define  __suart_err(fmt, args...) printk(KERN_ERR "suart_err: " fmt, ##
> >> args)
> >
> > Use dev_dbg/dev_err/pr_debug/pr_err
> 
> SG - did you mean replace the printks above with dev_dgb/err or the 
> suart_dbg/err.

Ideally all the messages shopuld use dev_dbg/dev_err etc. That allows you
to configure debug levels and the like nicely as well as producing
clearer printk info. In some cases with tty code you may not know the
device so have to use pr_err/pr_debug etc.

Ok

> > Which is never checked. Far better to use WARN_ON and the like for such
> > cases - or if like this one they don't appear to be possible to simply
> > delete them
> 
> SG -- OK, does this look ok ?
> =================================
> if (h_uart == NULL) {
> +WARN_ON(1);
> - return PRU_SUART_ERR_HANDLE_INVALID;
> +return -EINVAL;
> }

Yep - the user will now get a backtrace, and in addition kerneloops.org
can capture it if that is set up in the distro in use.

Alan

From sshtylyov at mvista.com  Tue Feb 22 05:20:56 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Tue, 22 Feb 2011 14:20:56 +0300
Subject: [PATCH v2 12/13] da850: pruss SUART platform specific additions.
In-Reply-To: <B2D7D72494BB443F80DA08E22323999B@subhasishg>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-13-git-send-email-subhasish@mistralsolutions.com>
	<4D55860E.3090908@mvista.com>
	<B2D7D72494BB443F80DA08E22323999B@subhasishg>
Message-ID: <4D639C18.9010309@mvista.com>

Hello.

On 22-02-2011 12:18, Subhasish Ghosh wrote:

> I could not follow your recommendations clearly, are you suggesting this:

> int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
> {
> #ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
> int ret;
>
> ret = clk_add_alias(NULL, "da8xx_pruss_uart.1",
> NULL, &da850_mcasp_device.dev);
> if (ret < 0)
> return ret;
> #endif
> da8xx_pruss_dev.dev.platform_data = pruss_device;
> return platform_device_register(&da8xx_pruss_dev);
> }

    Yes. But still better would be to wrap clk_add_alias() into a function of 
its own (defining it empty if CONFIG_SERIAL_PRUSS_SUART_MODULE is not defined).

WBR, Sergei

From sameo at linux.intel.com  Tue Feb 22 05:33:11 2011
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Tue, 22 Feb 2011 12:33:11 +0100
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
In-Reply-To: <4D639493.1060601@grandegger.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
	<20110221163027.GF10686@sortiz-mobl>
	<37B3755C4AE64BAA805DFBAEBDC3D9E4@subhasishg>
	<20110222103127.GC30279@sortiz-mobl>
	<4D639493.1060601@grandegger.com>
Message-ID: <20110222113310.GD30279@sortiz-mobl>

On Tue, Feb 22, 2011 at 11:48:51AM +0100, Wolfgang Grandegger wrote:
> On 02/22/2011 11:31 AM, Samuel Ortiz wrote:
> > Hi Subhasish,
> > 
> > On Tue, Feb 22, 2011 at 11:13:38AM +0530, Subhasish Ghosh wrote:
> >> Thank you for your comments.
> > No problem.
> > 
> >>>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >>>> index fd01836..6c437df 100644
> >>>> --- a/drivers/mfd/Kconfig
> >>>> +++ b/drivers/mfd/Kconfig
> >>>> @@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
> >>>>   boards.  MSP430 firmware manages resets and power sequencing,
> >>>>   inputs from buttons and the IR remote, LEDs, an RTC, and more.
> >>>>
> >>>> +config MFD_DA8XX_PRUSS
> >>>> + tristate "Texas Instruments DA8XX PRUSS support"
> >>>> + depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
> >>> Why are we depending on those ?
> >>
> >> SG -- The PRUSS core in only available within DA850 and DA830,
> >>            DA830 support is not yet implemented.
> > Sure, but if there are no actual code dependencies, I'd like to get rid of
> > those depends.
> > 
> >>>> +u32 pruss_disable(struct device *dev, u8 pruss_num)
> >>>> +{
> >>>> + struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
> >>>> + da8xx_prusscore_regs h_pruss;
> >>>> + u32 temp_reg;
> >>>> +
> >>>> + if (pruss_num == DA8XX_PRUCORE_0) {
> >>>> + /* Disable PRU0  */
> >>>> + h_pruss = (da8xx_prusscore_regs)
> >>>> + ((u32) pruss->ioaddr + 0x7000);
> >>> So it seems you're doing this in several places, and I have a few
> >>> comments:
> >>>
> >>> - You don't need the da8xx_prusscore_regs at all.
> >>> - Define the register map through a set of #define in your header file.
> >>> - Use a static routine that takes the core number and returns the
> >>> register map
> >>> offset.
> >>>
> >>> Then routines like this one will look a lot more readable.
> >>
> >> SG -- There are a huge number of PRUSS registers. A lot of them are
> >> reserved and are expected to change as development on the
> >>            controller is still ongoing. 
> > First of all, from what I read in your patch you're only using the CONTROL
> > offset.
> > 
> >> If we use #defines to plot
> >> all the registers, then first, there are too many array type
> >> registers which will need to be duplicated.
> > What I'm expecting is a small set of defines for the register offsets. You
> > have 13 fields in your da8xx_prusscore_regs, you only need to define 13
> > register offsets.
> > 
> > So, if you have a:
> > 
> > static u32 reg_offset(struct device *dev, u8 pru_num)
> > {
> > 	struct da8xx_pruss *pru = dev_get_drvdata(dev->parent);
> > 
> > 	switch (pru_num) {
> > 	case DA8XX_PRUCORE_0:
> > 		return (u32) pru->ioaddr + 0x7000;
> > 	case DA8XX_PRUCORE_1:
> > 		return (u32) pru->ioaddr + 0x7800;
> > 	default:
> > 		return 0;
> > }
> > 
> > 
> > then routines like pruss_enable (which should return an int, btw) would look
> > like:
> > 
> > int pruss_enable(struct device *dev, u8 pruss_num)
> > {
> > 	u32 offset = reg_offset(dev, pruss_num);
> > 
> > 	if (offset == 0)
> > 		return -EINVAL;
> > 
> > 	__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
> > 			offset + PRU_CORE_CONTROL);
> > 
> > 	return 0;
> > }
> 
> All registers are memory mapped and could nicely be described by
> structures (and sub-structures). Therefore we asked to considerer
> structs, at least for the Pruss SocketCAN drivers. 
>
> That would result in
> much much clearer and better readable code. The code above would shrink to:
> 
> 	__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
> 		     &prucore[pruss_num].control);
This driver seems to exclusively use the control offset, which is why I don't
see an absolute need for doing this mapping.
But if both maps are contiguous then doing the mapping would prevent us from
calling reg_offset() and would bring some advantage. I'd then be fine with it.
For now, da8xx_prusscore_regs seems to be larger than the 0x800 interval
between the 2 maps, so I have no idea if both maps are indeed contiguous.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

From pratheesh at ti.com  Tue Feb 22 05:38:26 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Tue, 22 Feb 2011 17:08:26 +0530
Subject: [PATCH 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used
	by PRUSS UIO driver
In-Reply-To: <4D629C82.3080906@mvista.com>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<1298041530-26855-2-git-send-email-pratheesh@ti.com>
	<1298041530-26855-3-git-send-email-pratheesh@ti.com>
	<4D629C82.3080906@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BD49121@dbde02.ent.ti.com>

Hi,

> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov at mvista.com]
> Sent: Monday, February 21, 2011 10:40 PM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; gregkh at suse.de;
> Chatterjee, Amit; hjk at linutronix.de; linux-kernel at vger.kernel.org; linux-
> arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used
> by PRUSS UIO driver
> 
> Hello.
> 
> Pratheesh Gangadhar wrote:
> 
> > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> 
>     Signoff should follow the change log, not precede it. "From:" line may
> precede the change log.
Fixed this in the new version.
> 
> > This patch defines PRUSS, ECAP clocks, memory and IRQ resources
> > used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
> > driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
> > DDR buffer to user space. PRUSS has 8 host event interrupt lines
> > mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
> > with shared memory can be used to implement IPC between ARM9 and
> > PRUSS.
> 
> > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-
> davinci/board-da850-evm.c
> > index 11f986b..ddcbac8 100644
> > --- a/arch/arm/mach-davinci/board-da850-evm.c
> > +++ b/arch/arm/mach-davinci/board-da850-evm.c
> > @@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
> >  		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
> >  				ret);
> >
> > +	ret = da8xx_register_pruss();
> > +       if (ret)
> > +                pr_warning("da850_evm_init: pruss registration failed:
> %d\n",
> > +                                 ret);
> >
> >  	ret = da8xx_register_watchdog();
> >  	if (ret)
> 
>     I'd put this into a pacth of its own, to have the SoC level changes
> separated from board-level changes...

Ok. I will do this; I need to make this change for hawkboard as well.
> 
> > diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-
> davinci/da850.c
> > index 3443d97..0096d4f 100644
> > --- a/arch/arm/mach-davinci/da850.c
> > +++ b/arch/arm/mach-davinci/da850.c
> > @@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
> >  	.flags		= ALWAYS_ENABLED,
> >  };
> >
> > +static struct clk pruss_clk = {
> > +	.name		= "pruss",
> > +	.parent		= &pll0_sysclk2,
> > +	.lpsc		= DA8XX_LPSC0_DMAX,
> 
>     We have patch submitted by TI that renames this #define to
> DA8XX_LPSC0_PRUSS...
> 
> > +	.flags		= ALWAYS_ENABLED,
> > +};
> > +
> 
>     We already have patch submitted by TI that defines this clock. It
> would be
> nice if you coordinated your efforts to avoid such conflicts.
>     Again, I'd put the part adding the clocks into a patch of its own.

I will try to sync with that patch. 
> 
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-
> davinci/devices-da8xx.c
> > index beda8a4..4ea3d1f 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
> >
> >  	return platform_device_register(&da8xx_cpuidle_device);
> >  }
> > +static struct resource pruss_resources[] = {
> > +	[0] = {
> > +		.start  = DA8XX_PRUSS_BASE,
> > +		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
> > +		.flags  = IORESOURCE_MEM,
> > +	},
> > +	[1] = {
> > +		.start  = DA8XX_L3RAM_BASE,
> > +		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
> > +		.flags  = IORESOURCE_MEM,
> 
>     Are you going to use all SRAM?
Its application dependent - we don't use more than 10KB at this point.
> 
> > +	},
> > +	[2] = {
> > +		.start  = 0,
> > +		.end    = SZ_256K - 1,
> > +		.flags  = IORESOURCE_MEM,
> > +	},
> > +
> > +	[3] = {
> > +		.start  = IRQ_DA8XX_EVTOUT0,
> > +		.end    = IRQ_DA8XX_EVTOUT0,
> > +		.flags  = IORESOURCE_IRQ,
> > +	},
> > +	[4] = {
> > +		.start  = IRQ_DA8XX_EVTOUT1,
> > +		.end    = IRQ_DA8XX_EVTOUT1,
> > +		.flags  = IORESOURCE_IRQ,
> > +	},
> > +	[5] = {
> > +		.start  = IRQ_DA8XX_EVTOUT2,
> > +		.end    = IRQ_DA8XX_EVTOUT2,
> > +		.flags  = IORESOURCE_IRQ,
> > +	},
> > +	[6] = {
> > +		.start  = IRQ_DA8XX_EVTOUT3,
> > +		.end    = IRQ_DA8XX_EVTOUT3,
> > +		.flags  = IORESOURCE_IRQ,
> > +	},
> > +	[7] = {
> > +		.start  = IRQ_DA8XX_EVTOUT4,
> > +		.end    = IRQ_DA8XX_EVTOUT4,
> > +		.flags  = IORESOURCE_IRQ,
> > +	},
> > +	[8] = {
> > +		.start  = IRQ_DA8XX_EVTOUT5,
> > +		.end    = IRQ_DA8XX_EVTOUT5,
> > +		.flags  = IORESOURCE_IRQ,
> > +	},
> > +	[9] = {
> > +		.start  = IRQ_DA8XX_EVTOUT6,
> > +		.end    = IRQ_DA8XX_EVTOUT6,
> > +		.flags  = IORESOURCE_IRQ,
> > +	},
> > +	[10] = {
> > +		.start  = IRQ_DA8XX_EVTOUT7,
> > +		.end    = IRQ_DA8XX_EVTOUT7,
> > +		.flags  = IORESOURCE_IRQ,
> > +	},
> > +};
> > +
> > +static struct platform_device pruss_device = {
> > +	.name			= "pruss",
> > +	.id			= 0,
> > +	.num_resources		= ARRAY_SIZE(pruss_resources),
> > +	.resource		= pruss_resources,
> > +	.dev	 =	{
> > +		.coherent_dma_mask = 0xffffffff,
> > +	}
> > +};
> > +
> > +int __init da8xx_register_pruss()
> > +{
> > +	return platform_device_register(&pruss_device);
> > +}
> 
>     Again, there's TI patch that adds this device already...
I will check this.


Thanks,
Pratheesh



From pratheesh at ti.com  Tue Feb 22 05:58:43 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Tue, 22 Feb 2011 17:28:43 +0530
Subject: [PATCH v2 1/2] PRUSS UIO driver support
In-Reply-To: <alpine.LFD.2.00.1102211939110.2701@localhost6.localdomain6>
References: <1298309715-21362-1-git-send-email-pratheesh@ti.com>
	<1298309715-21362-2-git-send-email-pratheesh@ti.com>
	<alpine.LFD.2.00.1102211939110.2701@localhost6.localdomain6>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BD49152@dbde02.ent.ti.com>

Hi,

> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx at linutronix.de]
> Sent: Tuesday, February 22, 2011 12:24 AM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; hjk at hansjkoch.de;
> gregkh at suse.de; Chatterjee, Amit; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v2 1/2] PRUSS UIO driver support
> 
> On Mon, 21 Feb 2011, Pratheesh Gangadhar wrote:
> > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > +{
> > +	void __iomem *int_enable_reg = dev_info->mem[0].internal_addr
> > +					+ PRUSS_INTC_HIER;
> > +	void __iomem *int_status_reg = dev_info->mem[0].internal_addr
> > +					+ PRUSS_INTC_HIPIR+((irq-1) << 2);
> 
>   	void __iomem *base = dev_info->mem[0].internal_addr;
> 	void __iomem *int_enable_reg = base + PRUSS_INTC_HIER;
> 	....
> 
> Makes that readable.
Ok.
> 
> > +	/* Is interrupt enabled and active ? */
> > +	if (!(ioread32(int_enable_reg) & (1<<(irq-1))) &&
> > +		 (ioread32(int_status_reg) & PRUSS_INTC_HIPIR_INTPEND_MASK))
> > +		return IRQ_NONE;
> 
>   That returns when the interrupt is disabled _AND_ pending. It should
>   return when the interrupt is disabled _OR_ not pending.
I should have named it _NOPEND_MASK, basically mask is set when there is no pending interrupt.

> > +
> > +	/* Disable interrupt */
> > +	iowrite32(ioread32(int_enable_reg) & ~(1<<(irq-1)),
> > +		int_enable_reg);
> 
> Chosing shorter variable names avoid those line breaks all over the
> place.
> 
Ok.
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static void pruss_cleanup(struct platform_device *dev, struct uio_info
> *info)
> > +{
> > +	int count;
> 
> New line between variables and code please
> 
Ok.
> > +	if (info) {
> 
> This check is silly. pruss_probe() returns right away when it cannot
> allocate info. pruss_remove() is never called when info == NULL
> 
Ok.
> > +		for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
> > +			uio_unregister_device(&info[count]);
> > +			kfree(info[count].name);
> > +			iounmap(info[count].mem[0].internal_addr);
> 
> Why do you map/unmap the same physical address 8 times ????
Will fix this.
> 
> > +		}
> > +		if (ddr_virt_addr)
> > +			dma_free_coherent(&dev->dev, info[0].mem[2].size,
> > +					  info[0].mem[2].internal_addr,
> > +					  info[0].mem[2].addr);
> > +		kfree(info);
> > +	}
> > +	if (pruss_clk != NULL)
> 
> Silly check as well.
> 
Ok.
> > +		clk_put(pruss_clk);
> > +}
> > +
> > +static int __devinit pruss_probe(struct platform_device *dev)
> > +{
> > +	int ret = -ENODEV, count = 0;
> > +	struct resource *regs_pruram, *regs_l3ram, *regs_ddr;
> > +	char *string;
> > +
> > +	/* Power on PRU in case its not done as part of boot-loader */
> > +	pruss_clk = clk_get(&dev->dev, "pruss");
> > +	if (IS_ERR(pruss_clk)) {
> > +		dev_err(&dev->dev, "Failed to get clock\n");
> > +		ret = PTR_ERR(pruss_clk);
> > +		return ret;
> > +	} else {
> > +		clk_enable(pruss_clk);
> > +	}
> > +
> > +	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVTOUT_INSTANCE,
> > +		       GFP_KERNEL);
> > +	if (info == NULL)
> 
>   if (!info)
> 
> > +		return -ENOMEM;
> 
>   Leaves the clock enabled
> 
Will fix this.
> > +	regs_pruram = platform_get_resource(dev, IORESOURCE_MEM, 0);
> > +	if (!regs_pruram) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +
> > +	regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
> > +	if (!regs_l3ram) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +
> > +	regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
> > +	if (!regs_ddr) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +	ddr_virt_addr =
> > +	    dma_alloc_coherent(&dev->dev, regs_ddr->end - regs_ddr->start +
> 1,
> > +			       &ddr_phy_addr, GFP_KERNEL | GFP_DMA);
> > +	if (!ddr_virt_addr) {
> > +		dev_err(&dev->dev, "Could not allocate external memory\n");
> > +		goto out_free;
> > +	}
> > +
> > +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
> 
> Sigh. Can't you have a pointer struct uio_info *p and do the following.
> 
Ok.
>       for (cnt = 0; p = info; cnt < MAX_PRUSS_EVTOUT_INSTANCE; cnt++, p++)
> {
> 
>       	       p->mem[0] ...
> 
> > +		info[count].mem[0].addr = regs_pruram->start;
> > +		info[count].mem[0].size =
> > +		    regs_pruram->end - regs_pruram->start + 1;
> > +		if (!info[count].mem[0].addr ||
> > +			!(info[count].mem[0].size - 1)) {
> 
> All you catch is size == 0. So with size == 1 it works ???
I can drop this check as well as normally one won't specify improbable size for mapping memory during configuration.
> 
> > +			dev_err(&dev->dev, "Invalid memory resource\n");
> > +			goto out_free;
> > +		}
> > +		info[count].mem[0].internal_addr =
> > +		    ioremap(regs_pruram->start, info[count].mem[0].size);
> 
> That's redundant to remap the same address 8 times. That and the check
> above should be done before the loop and the result used in the loop.
> 
Ok, will do.
> > +		if (!info[count].mem[0].internal_addr) {
> > +			dev_err(&dev->dev,
> > +				"Can't remap memory address range\n");
> > +			goto out_free;
> > +		}
> > +		info[count].mem[0].memtype = UIO_MEM_PHYS;
> > +
> > +		info[count].mem[1].addr = regs_l3ram->start;
> > +		info[count].mem[1].size =
> > +		    regs_l3ram->end - regs_l3ram->start + 1;
> > +		if (!info[count].mem[1].addr ||
> > +			!(info[count].mem[1].size - 1)) {
> > +			dev_err(&dev->dev, "Invalid memory resource\n");
> > +			goto out_free;
> > +		}
> 
> No need to check the same thing over and over.
> 
> > +		info[count].mem[1].memtype = UIO_MEM_PHYS;
> > +
> > +		info[count].mem[2].internal_addr = ddr_virt_addr;
> > +		info[count].mem[2].addr = ddr_phy_addr;
> > +		info[count].mem[2].size = regs_ddr->end - regs_ddr->start + 1;
> > +		info[count].mem[2].memtype = UIO_MEM_PHYS;
> > +
> > +		string = kzalloc(20, GFP_KERNEL);
> > +		sprintf(string, "pruss_evt%d", count);
> > +		info[count].name = string;
> 
>   kasprintf() please
Ok.
> 
> > +		info[count].version = "0.50";
> > +
> > +		/* Register PRUSS IRQ lines */
> > +		info[count].irq = IRQ_DA8XX_EVTOUT0 + count;
> > +
> > +		info[count].irq_flags = 0;
> 
>   Is already zero
> 
Ok.
> > +		info[count].handler = pruss_handler;
> > +
> > +		ret = uio_register_device(&dev->dev, &info[count]);
> > +
> > +		if (ret < 0)
> > +			goto out_free;
> > +	}
> > +
> > +	platform_set_drvdata(dev, info);
> > +	return 0;
> > +
> > +out_free:
> > +	pruss_cleanup(dev, info);
> > +	return ret;
> > +}
> > +
> > +static int __devexit pruss_remove(struct platform_device *dev)
> > +{
> > +	struct uio_info *info = platform_get_drvdata(dev);
> 
> Empty line between variables and code.
> 
Ok.
> > +	pruss_cleanup(dev, info);
> > +	platform_set_drvdata(dev, NULL);
> > +	return 0;
> 
Thanks,
Pratheesh

From pratheesh at ti.com  Tue Feb 22 06:01:30 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Tue, 22 Feb 2011 17:31:30 +0530
Subject: [PATCH v2 1/2] PRUSS UIO driver support
In-Reply-To: <20110221184432.GA2773@local>
References: <1298309715-21362-1-git-send-email-pratheesh@ti.com>
	<1298309715-21362-2-git-send-email-pratheesh@ti.com>
	<20110221184432.GA2773@local>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BD49158@dbde02.ent.ti.com>

Hi,

> -----Original Message-----
> From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> Sent: Tuesday, February 22, 2011 12:15 AM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; hjk at hansjkoch.de;
> gregkh at suse.de; Chatterjee, Amit; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v2 1/2] PRUSS UIO driver support
> 
> On Mon, Feb 21, 2011 at 11:05:14PM +0530, Pratheesh Gangadhar wrote:
> > This patch implements PRUSS (Programmable Real-time Unit Sub System)
> > UIO driver which exports SOC resources associated with PRUSS like
> > I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
> > processors which is efficient in performing embedded tasks that
> > require manipulation of packed memory mapped data structures and
> > efficient in handling system events that have tight real time
> > constraints. This driver is currently supported on Texas Instruments
> > DA850, AM18xx and OMAPL1-38 devices.
> > For example, PRUSS runs firmware for real-time critical industrial
> > communication data link layer and communicates with application stack
> > running in user space via shared memory and IRQs.
> >
> > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> 
> Looks much better now. Just some minor issues, see below.
> 
> Thanks,
> Hans
> 
> > ---
> >  drivers/uio/Kconfig     |    9 ++
> >  drivers/uio/Makefile    |    1 +
> >  drivers/uio/uio_pruss.c |  231
> +++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 241 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/uio/uio_pruss.c
> >
> > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> > index bb44079..f92f20d 100644
> > --- a/drivers/uio/Kconfig
> > +++ b/drivers/uio/Kconfig
> > @@ -94,4 +94,13 @@ config UIO_NETX
> >  	  To compile this driver as a module, choose M here; the module
> >  	  will be called uio_netx.
> >
> > +config UIO_PRUSS
> > +	tristate "Texas Instruments PRUSS driver"
> > +	depends on ARCH_DAVINCI_DA850
> > +	help
> > +	  PRUSS driver for OMAPL138/DA850/AM18XX devices
> > +	  PRUSS driver requires user space components
> 
> It would be nice to mention a link here where these user space components
> are
> available.
Ok, will do.
> 
> > +	  To compile this driver as a module, choose M here: the module
> > +	  will be called uio_pruss.
> > +
> >  endif
> > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > index 18fd818..d4dd9a5 100644
> > --- a/drivers/uio/Makefile
> > +++ b/drivers/uio/Makefile
> > @@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC)	+= uio_aec.o
> >  obj-$(CONFIG_UIO_SERCOS3)	+= uio_sercos3.o
> >  obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
> >  obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
> > +obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
> > diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
> > new file mode 100644
> > index 0000000..b402197
> > --- /dev/null
> > +++ b/drivers/uio/uio_pruss.c
> > @@ -0,0 +1,231 @@
> > +/*
> > + * Programmable Real-Time Unit Sub System (PRUSS) UIO driver
> (uio_pruss)
> > + *
> > + * This driver exports PRUSS host event out interrupts and PRUSS, L3
> RAM,
> > + * and DDR RAM to user space for applications interacting with PRUSS
> firmware
> > + *
> > + * Copyright (C) 2010-11 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 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/device.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/uio_driver.h>
> > +#include <linux/io.h>
> > +#include <linux/clk.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/slab.h>
> > +
> > +#define DRV_NAME "pruss"
> > +#define DRV_VERSION "0.50"
> > +
> > +/*
> > + * Host event IRQ numbers from PRUSS - PRUSS can generate upto 8
> interrupt
> > + * events to AINTC of ARM host processor - which can be used for IPC
> b/w PRUSS
> > + * firmware and user space application, async notification from PRU
> firmware
> > + * to user space application
> > + * 3	PRU_EVTOUT0
> > + * 4	PRU_EVTOUT1
> > + * 5	PRU_EVTOUT2
> > + * 6	PRU_EVTOUT3
> > + * 7	PRU_EVTOUT4
> > + * 8	PRU_EVTOUT5
> > + * 9	PRU_EVTOUT6
> > + * 10	PRU_EVTOUT7
> > +*/
> > +
> > +#define MAX_PRUSS_EVTOUT_INSTANCE	8
> > +
> > +#define	PRUSS_INTC_HIPIR		0x4900
> > +#define	PRUSS_INTC_HIPIR_INTPEND_MASK	0x80000000
> > +#define	PRUSS_INTC_HIER			0x5500
> > +
> > +struct clk *pruss_clk;
> > +struct uio_info *info;
> > +void *ddr_virt_addr;
> > +dma_addr_t ddr_phy_addr;
> > +
> > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > +{
> > +	void __iomem *int_enable_reg = dev_info->mem[0].internal_addr
> > +					+ PRUSS_INTC_HIER;
> > +	void __iomem *int_status_reg = dev_info->mem[0].internal_addr
> > +					+ PRUSS_INTC_HIPIR+((irq-1) << 2);
> 
> Blank line between variable definitions and code, please.
> 
Ok.
> > +	/* Is interrupt enabled and active ? */
> > +	if (!(ioread32(int_enable_reg) & (1<<(irq-1))) &&
> 
> Hmm. I'd prefer blanks around operands, like (1 << (irq - 1))).
> I won't be too picky about that, noticing that checkpatch.pl doesn't
> complain.
> If you want to do me a favor, you can fix it ;-)
> 
Ok.
> > +		 (ioread32(int_status_reg) & PRUSS_INTC_HIPIR_INTPEND_MASK))
> > +		return IRQ_NONE;
> > +
> > +	/* Disable interrupt */
> > +	iowrite32(ioread32(int_enable_reg) & ~(1<<(irq-1)),
> 
> If you save the return value of the first ioread32(int_enable_reg) in a
> variable,
> you don't need the second hardware access.
> 
Will do.
> > +		int_enable_reg);
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static void pruss_cleanup(struct platform_device *dev, struct uio_info
> *info)
> > +{
> > +	int count;
> 
> Blank line between variable definitions and code, please.
> 
Ok.
> > +	if (info) {
> > +		for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
> > +			uio_unregister_device(&info[count]);
> > +			kfree(info[count].name);
> > +			iounmap(info[count].mem[0].internal_addr);
> > +
> > +		}
> > +		if (ddr_virt_addr)
> > +			dma_free_coherent(&dev->dev, info[0].mem[2].size,
> > +					  info[0].mem[2].internal_addr,
> > +					  info[0].mem[2].addr);
> > +		kfree(info);
> > +	}
> > +	if (pruss_clk != NULL)
> > +		clk_put(pruss_clk);
> > +}
> > +
> > +static int __devinit pruss_probe(struct platform_device *dev)
> > +{
> > +	int ret = -ENODEV, count = 0;
> > +	struct resource *regs_pruram, *regs_l3ram, *regs_ddr;
> > +	char *string;
> > +
> > +	/* Power on PRU in case its not done as part of boot-loader */
> > +	pruss_clk = clk_get(&dev->dev, "pruss");
> > +	if (IS_ERR(pruss_clk)) {
> > +		dev_err(&dev->dev, "Failed to get clock\n");
> > +		ret = PTR_ERR(pruss_clk);
> > +		return ret;
> > +	} else {
> > +		clk_enable(pruss_clk);
> > +	}
> > +
> > +	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVTOUT_INSTANCE,
> > +		       GFP_KERNEL);
> > +	if (info == NULL)
> 
> if (!info) looks better.
> 
> > +		return -ENOMEM;
> > +
> > +	regs_pruram = platform_get_resource(dev, IORESOURCE_MEM, 0);
> > +	if (!regs_pruram) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +
> > +	regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
> > +	if (!regs_l3ram) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +
> > +	regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
> > +	if (!regs_ddr) {
> > +		dev_err(&dev->dev, "No memory resource specified\n");
> > +		goto out_free;
> > +	}
> > +	ddr_virt_addr =
> > +	    dma_alloc_coherent(&dev->dev, regs_ddr->end - regs_ddr->start +
> 1,
> > +			       &ddr_phy_addr, GFP_KERNEL | GFP_DMA);
> > +	if (!ddr_virt_addr) {
> > +		dev_err(&dev->dev, "Could not allocate external memory\n");
> > +		goto out_free;
> > +	}
> > +
> > +	for (count = 0; count < MAX_PRUSS_EVTOUT_INSTANCE; count++) {
> > +		info[count].mem[0].addr = regs_pruram->start;
> > +		info[count].mem[0].size =
> > +		    regs_pruram->end - regs_pruram->start + 1;
> > +		if (!info[count].mem[0].addr ||
> > +			!(info[count].mem[0].size - 1)) {
> > +			dev_err(&dev->dev, "Invalid memory resource\n");
> > +			goto out_free;
> > +		}
> > +		info[count].mem[0].internal_addr =
> > +		    ioremap(regs_pruram->start, info[count].mem[0].size);
> > +		if (!info[count].mem[0].internal_addr) {
> > +			dev_err(&dev->dev,
> > +				"Can't remap memory address range\n");
> > +			goto out_free;
> > +		}
> > +		info[count].mem[0].memtype = UIO_MEM_PHYS;
> > +
> > +		info[count].mem[1].addr = regs_l3ram->start;
> > +		info[count].mem[1].size =
> > +		    regs_l3ram->end - regs_l3ram->start + 1;
> > +		if (!info[count].mem[1].addr ||
> > +			!(info[count].mem[1].size - 1)) {
> > +			dev_err(&dev->dev, "Invalid memory resource\n");
> > +			goto out_free;
> > +		}
> > +		info[count].mem[1].memtype = UIO_MEM_PHYS;
> > +
> > +		info[count].mem[2].internal_addr = ddr_virt_addr;
> > +		info[count].mem[2].addr = ddr_phy_addr;
> > +		info[count].mem[2].size = regs_ddr->end - regs_ddr->start + 1;
> > +		info[count].mem[2].memtype = UIO_MEM_PHYS;
> > +
> > +		string = kzalloc(20, GFP_KERNEL);
> > +		sprintf(string, "pruss_evt%d", count);
> > +		info[count].name = string;
> > +		info[count].version = "0.50";
> > +
> > +		/* Register PRUSS IRQ lines */
> > +		info[count].irq = IRQ_DA8XX_EVTOUT0 + count;
> > +
> > +		info[count].irq_flags = 0;
> > +		info[count].handler = pruss_handler;
> > +
> > +		ret = uio_register_device(&dev->dev, &info[count]);
> > +
> > +		if (ret < 0)
> > +			goto out_free;
> > +	}
> > +
> > +	platform_set_drvdata(dev, info);
> > +	return 0;
> > +
> > +out_free:
> > +	pruss_cleanup(dev, info);
> > +	return ret;
> > +}
> > +
> > +static int __devexit pruss_remove(struct platform_device *dev)
> > +{
> > +	struct uio_info *info = platform_get_drvdata(dev);
> 
> Blank line, please.
> 
Ok.

Thanks,
Pratheesh

From pratheesh at ti.com  Tue Feb 22 06:06:23 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Tue, 22 Feb 2011 17:36:23 +0530
Subject: [PATCH 1/2] PRUSS UIO driver support
In-Reply-To: <4D62C2A0.6060405@mvista.com>
References: <1298041530-26855-1-git-send-email-pratheesh@ti.com>
	<201102181644.17634.arnd@arndb.de>
	<alpine.LFD.2.00.1102181713480.2701@localhost6.localdomain6>
	<201102181731.05644.arnd@arndb.de>
	<alpine.LFD.2.00.1102181802580.2701@localhost6.localdomain6>
	<B85A65D85D7EB246BE421B3FB0FBB593024B83C108@dbde02.ent.ti.com>
	<20110219183427.GG4684@local>
	<B85A65D85D7EB246BE421B3FB0FBB593024B83C20F@dbde02.ent.ti.com>
	<20110221193316.GC2773@local> <4D62C2A0.6060405@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BD4916A@dbde02.ent.ti.com>

Hi,

> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov at mvista.com]
> Sent: Tuesday, February 22, 2011 1:23 AM
> To: Hans J. Koch
> Cc: TK, Pratheesh Gangadhar; davinci-linux-open-
> source at linux.davincidsp.com; Arnd Bergmann; Chatterjee, Amit;
> gregkh at suse.de; LKML; Thomas Gleixner; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 1/2] PRUSS UIO driver support
> 
> Hello.
> 
> Hans J. Koch wrote:
> 
> >>> -----Original Message-----
> >>> From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> >>> Sent: Sunday, February 20, 2011 12:04 AM
> >>> To: TK, Pratheesh Gangadhar
> >>> Cc: Thomas Gleixner; Arnd Bergmann; linux-arm-
> kernel at lists.infradead.org;
> >>> davinci-linux-open-source at linux.davincidsp.com; gregkh at suse.de;
> >>> Chatterjee, Amit; Hans J. Koch; LKML
> >>> Subject: Re: [PATCH 1/2] PRUSS UIO driver support
> 
> >>> On Sat, Feb 19, 2011 at 09:10:23PM +0530, TK, Pratheesh Gangadhar
> wrote:
> >>>> For my understanding - if the interrupt is not shared and not level
> triggered -
> >>>> is this okay to have empty handler?
> 
> >>> Greg already said he won't accept that. And I'm quite sure these
> >>> interrupts
> >>> are level triggered, since that is the default on arch/omap.
> 
> >>> E.g. in arch/arm/mach-omap1/irq.c, a loop sets all irqs to level
> triggered
> >>> handling: set_irq_handler(j, handle_level_irq); (line 234)
> 
> >> You should be looking at arch/arm/mach-davinci/irq.c
> 
>     Into arch/arm/mach-davinci/cp_intc.c actually as we're not talking
> about a
> "real" DaVincis here, but about OMAP-L138.
> 
> > Hmpf. I alway get lost in the directory structure of TI SoCs...
> > At least I learned that OMAP3 is in the omap2 directory :)
> 
>     It's probably even more convoluted with DaVinci and friends. :-)
> 
> >> and all interrupts except IRQ_TINT1_TINT34 is set to edge trigger mode
> (line 160).
> 
> > Is that really needed? Level triggered interrupts should certainly be
> > preferred if possible.
> 
>     Don't look there, this code is for "real" DaVincis only.
> 

Thanks for correcting. Interrupts are configured as edge triggered here as well.

Thanks and Regards,
Pratheesh

From michael.williamson at criticallink.com  Tue Feb 22 06:13:29 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 07:13:29 -0500
Subject: [PATCH v2 3/6] davinci: da8xx: add spi resources and registration
	routine
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BD48E7B@dbde02.ent.ti.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
	<1297257114-764-4-git-send-email-michael.williamson@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BD48E7B@dbde02.ent.ti.com>
Message-ID: <4D63A869.1070401@criticallink.com>

On 2/22/2011 1:14 AM, Nori, Sekhar wrote:

> Hi Mike,
> 
> On Wed, Feb 09, 2011 at 18:41:51, Michael Williamson wrote:
>> Add IO resource structures, platform data, and a registration
>> routine in order to support spi device on DA850/OMAP-L138/AM18x
>> and DA830/OMAP-L137/AM17x platforms.
>>
>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
> 
> [...]
> 
>> +static struct resource da8xx_spi1_resources[] = {
>> +	[0] = {
>> +		.start	= DA8XX_SPI1_BASE,
>> +		.end	= DA8XX_SPI1_BASE + SZ_4K -1,
> 
> checkpatch reports a warning here. Need to have spaces
> on either side of binary '-'
> 


Sorry about that... not sure how I missed that one.

> I tested this series and the two patches it depends on
> using SPI flash present on DA850 and DA830 EVMs (tested
> in DMA mode) and found no issues.
> 


Thanks for testing, Sekhar.

> So, with this minor issue fixed, can you please repost
> with my Ack? You can include the two dependent patches
> in the same series so it is easy to pick-up the whole
> bunch.
> 


OK.

> Thanks,
> Sekhar
> 



From michael.williamson at criticallink.com  Tue Feb 22 06:13:59 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 07:13:59 -0500
Subject: [PATCH v2 5/6] davinci: add spi devices support for
	da850/omap-l138/am18x evm
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BD48EB5@dbde02.ent.ti.com>
References: <1297257114-764-1-git-send-email-michael.williamson@criticallink.com>
	<1297257114-764-6-git-send-email-michael.williamson@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BD48EB5@dbde02.ent.ti.com>
Message-ID: <4D63A887.6050301@criticallink.com>

On 2/22/2011 1:37 AM, Nori, Sekhar wrote:

> On Wed, Feb 09, 2011 at 18:41:53, Michael Williamson wrote:
>> From: Sekhar Nori <nsekhar at ti.com>
>>
>> This patch adds the on-board SPI flash device to the
>> DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
>> device to the MTD subsystem.
>>
>> Based on SPI flash device support for MityDSP-L138F platform.
>>
>> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
>> [michael.williamson at criticallink.com: moved da850_evm_spi1_pdata to devices-da8xx.c]
>> Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
>> +static void __init da850evm_init_spi1(struct spi_board_info *info, unsigned len)
>> +{
>> +	int ret;
>> +
>> +	ret = spi_register_board_info(info, len);
>> +	if (ret)
>> +		pr_warning("failed to register board info : %d\n", ret);
>> +
>> +	da8xx_spi_pdata[1].num_chipselect = len;
>> +
>> +	ret = da8xx_register_spi(1);
>> +	if (ret)
>> +		pr_warning("failed to register spi 1 device : %d\n", ret);
>> +}
> 
> When reposting can you also modify this to print function name
> with the error message (so it is easy to find what exactly failed).
> 
> The same thing needs to be done with DA830 EVM.
> 
> Rest of the stuff looks good to me.
> 


Sure.

> Thanks,
> Sekhar



From subhasish at mistralsolutions.com  Tue Feb 22 06:49:25 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Tue, 22 Feb 2011 18:19:25 +0530
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
In-Reply-To: <20110222113310.GD30279@sortiz-mobl>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
	<20110221163027.GF10686@sortiz-mobl>
	<37B3755C4AE64BAA805DFBAEBDC3D9E4@subhasishg>
	<20110222103127.GC30279@sortiz-mobl>
	<4D639493.1060601@grandegger.com>
	<20110222113310.GD30279@sortiz-mobl>
Message-ID: <C73EA0C998A34C709A8130A50A1C443F@subhasishg>

I am not sure if I understood you correctly, but the current sizeof the 
structure da8xx_prusscore_regs  is 0x500.

Here is a link to the PRUSS memory map:
http://processors.wiki.ti.com/index.php/PRUSS_Memory_Map

The offset 0x00007000 is the PRU0 reg offset and 0x00007800 is the PRU1 reg 
offset.
We cannot have a register file larger than this, but lot of space is left 
out, possibly for future development.

--------------------------------------------------
From: "Samuel Ortiz" <sameo at linux.intel.com>
Sent: Tuesday, February 22, 2011 5:03 PM
To: "Wolfgang Grandegger" <wg at grandegger.com>
Cc: "Subhasish Ghosh" <subhasish at mistralsolutions.com>; 
<sachi at mistralsolutions.com>; 
<davinci-linux-open-source at linux.davincidsp.com>; <nsekhar at ti.com>; "open 
list" <linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 01/13] mfd: pruss mfd driver.

> On Tue, Feb 22, 2011 at 11:48:51AM +0100, Wolfgang Grandegger wrote:
>> On 02/22/2011 11:31 AM, Samuel Ortiz wrote:
>> > Hi Subhasish,
>> >
>> > On Tue, Feb 22, 2011 at 11:13:38AM +0530, Subhasish Ghosh wrote:
>> >> Thank you for your comments.
>> > No problem.
>> >
>> >>>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> >>>> index fd01836..6c437df 100644
>> >>>> --- a/drivers/mfd/Kconfig
>> >>>> +++ b/drivers/mfd/Kconfig
>> >>>> @@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
>> >>>>   boards.  MSP430 firmware manages resets and power sequencing,
>> >>>>   inputs from buttons and the IR remote, LEDs, an RTC, and more.
>> >>>>
>> >>>> +config MFD_DA8XX_PRUSS
>> >>>> + tristate "Texas Instruments DA8XX PRUSS support"
>> >>>> + depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
>> >>> Why are we depending on those ?
>> >>
>> >> SG -- The PRUSS core in only available within DA850 and DA830,
>> >>            DA830 support is not yet implemented.
>> > Sure, but if there are no actual code dependencies, I'd like to get rid 
>> > of
>> > those depends.
>> >
>> >>>> +u32 pruss_disable(struct device *dev, u8 pruss_num)
>> >>>> +{
>> >>>> + struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
>> >>>> + da8xx_prusscore_regs h_pruss;
>> >>>> + u32 temp_reg;
>> >>>> +
>> >>>> + if (pruss_num == DA8XX_PRUCORE_0) {
>> >>>> + /* Disable PRU0  */
>> >>>> + h_pruss = (da8xx_prusscore_regs)
>> >>>> + ((u32) pruss->ioaddr + 0x7000);
>> >>> So it seems you're doing this in several places, and I have a few
>> >>> comments:
>> >>>
>> >>> - You don't need the da8xx_prusscore_regs at all.
>> >>> - Define the register map through a set of #define in your header 
>> >>> file.
>> >>> - Use a static routine that takes the core number and returns the
>> >>> register map
>> >>> offset.
>> >>>
>> >>> Then routines like this one will look a lot more readable.
>> >>
>> >> SG -- There are a huge number of PRUSS registers. A lot of them are
>> >> reserved and are expected to change as development on the
>> >>            controller is still ongoing.
>> > First of all, from what I read in your patch you're only using the 
>> > CONTROL
>> > offset.
>> >
>> >> If we use #defines to plot
>> >> all the registers, then first, there are too many array type
>> >> registers which will need to be duplicated.
>> > What I'm expecting is a small set of defines for the register offsets. 
>> > You
>> > have 13 fields in your da8xx_prusscore_regs, you only need to define 13
>> > register offsets.
>> >
>> > So, if you have a:
>> >
>> > static u32 reg_offset(struct device *dev, u8 pru_num)
>> > {
>> > struct da8xx_pruss *pru = dev_get_drvdata(dev->parent);
>> >
>> > switch (pru_num) {
>> > case DA8XX_PRUCORE_0:
>> > return (u32) pru->ioaddr + 0x7000;
>> > case DA8XX_PRUCORE_1:
>> > return (u32) pru->ioaddr + 0x7800;
>> > default:
>> > return 0;
>> > }
>> >
>> >
>> > then routines like pruss_enable (which should return an int, btw) would 
>> > look
>> > like:
>> >
>> > int pruss_enable(struct device *dev, u8 pruss_num)
>> > {
>> > u32 offset = reg_offset(dev, pruss_num);
>> >
>> > if (offset == 0)
>> > return -EINVAL;
>> >
>> > __raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
>> > offset + PRU_CORE_CONTROL);
>> >
>> > return 0;
>> > }
>>
>> All registers are memory mapped and could nicely be described by
>> structures (and sub-structures). Therefore we asked to considerer
>> structs, at least for the Pruss SocketCAN drivers.
>>
>> That would result in
>> much much clearer and better readable code. The code above would shrink 
>> to:
>>
>> __raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
>>      &prucore[pruss_num].control);
> This driver seems to exclusively use the control offset, which is why I 
> don't
> see an absolute need for doing this mapping.
> But if both maps are contiguous then doing the mapping would prevent us 
> from
> calling reg_offset() and would bring some advantage. I'd then be fine with 
> it.
> For now, da8xx_prusscore_regs seems to be larger than the 0x800 interval
> between the 2 maps, so I have no idea if both maps are indeed contiguous.
>
> Cheers,
> Samuel.
>
> -- 
> Intel Open Source Technology Centre
> http://oss.intel.com/ 


From subhasish at mistralsolutions.com  Tue Feb 22 07:24:18 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Tue, 22 Feb 2011 18:54:18 +0530
Subject: [PATCH v2 12/13] da850: pruss SUART platform specific additions.
In-Reply-To: <4D639C18.9010309@mvista.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-13-git-send-email-subhasish@mistralsolutions.com>
	<4D55860E.3090908@mvista.com>
	<B2D7D72494BB443F80DA08E22323999B@subhasishg>
	<4D639C18.9010309@mvista.com>
Message-ID: <01ADA340BA2E4A62BBFC1E4FB630B380@subhasishg>

Ok, will do.

--------------------------------------------------
From: "Sergei Shtylyov" <sshtylyov at mvista.com>
Sent: Tuesday, February 22, 2011 4:50 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<sachi at mistralsolutions.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Kevin Hilman" <khilman at deeprootsystems.com>; <nsekhar at ti.com>; "open list" 
<linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; 
<linux-arm-kernel at lists.infradead.org>
Subject: Re: [PATCH v2 12/13] da850: pruss SUART platform specific 
additions.

> Hello.
>
> On 22-02-2011 12:18, Subhasish Ghosh wrote:
>
>> I could not follow your recommendations clearly, are you suggesting this:
>
>> int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
>> {
>> #ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
>> int ret;
>>
>> ret = clk_add_alias(NULL, "da8xx_pruss_uart.1",
>> NULL, &da850_mcasp_device.dev);
>> if (ret < 0)
>> return ret;
>> #endif
>> da8xx_pruss_dev.dev.platform_data = pruss_device;
>> return platform_device_register(&da8xx_pruss_dev);
>> }
>
>    Yes. But still better would be to wrap clk_add_alias() into a function 
> of its own (defining it empty if CONFIG_SERIAL_PRUSS_SUART_MODULE is not 
> defined).
>
> WBR, Sergei 


From michael.williamson at criticallink.com  Tue Feb 22 07:36:56 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:36:56 -0500
Subject: [PATCH v3 1/9] davinci: remove unused DA830_edma_ch enum
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-2-git-send-email-michael.williamson@criticallink.com>

The DA830_edma_ch enum set is not used.  Remove it.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/include/mach/edma.h |   36 -----------------------------
 1 files changed, 0 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/edma.h b/arch/arm/mach-davinci/include/mach/edma.h
index dc10ef6..20c77f2 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -151,42 +151,6 @@ struct edmacc_param {
 #define DA830_DMACH2EVENT_MAP1		0x00000000u
 #define DA830_EDMA_ARM_OWN		0x30FFCCFFu
 
-/* DA830 specific EDMA3 Events Information */
-enum DA830_edma_ch {
-	DA830_DMACH_MCASP0_RX,
-	DA830_DMACH_MCASP0_TX,
-	DA830_DMACH_MCASP1_RX,
-	DA830_DMACH_MCASP1_TX,
-	DA830_DMACH_MCASP2_RX,
-	DA830_DMACH_MCASP2_TX,
-	DA830_DMACH_GPIO_BNK0INT,
-	DA830_DMACH_GPIO_BNK1INT,
-	DA830_DMACH_UART0_RX,
-	DA830_DMACH_UART0_TX,
-	DA830_DMACH_TMR64P0_EVTOUT12,
-	DA830_DMACH_TMR64P0_EVTOUT34,
-	DA830_DMACH_UART1_RX,
-	DA830_DMACH_UART1_TX,
-	DA830_DMACH_SPI0_RX,
-	DA830_DMACH_SPI0_TX,
-	DA830_DMACH_MMCSD_RX,
-	DA830_DMACH_MMCSD_TX,
-	DA830_DMACH_SPI1_RX,
-	DA830_DMACH_SPI1_TX,
-	DA830_DMACH_DMAX_EVTOUT6,
-	DA830_DMACH_DMAX_EVTOUT7,
-	DA830_DMACH_GPIO_BNK2INT,
-	DA830_DMACH_GPIO_BNK3INT,
-	DA830_DMACH_I2C0_RX,
-	DA830_DMACH_I2C0_TX,
-	DA830_DMACH_I2C1_RX,
-	DA830_DMACH_I2C1_TX,
-	DA830_DMACH_GPIO_BNK4INT,
-	DA830_DMACH_GPIO_BNK5INT,
-	DA830_DMACH_UART2_RX,
-	DA830_DMACH_UART2_TX
-};
-
 /*ch_status paramater of callback function possible values*/
 #define DMA_COMPLETE 1
 #define DMA_CC_ERROR 2
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:36:57 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:36:57 -0500
Subject: [PATCH v3 2/9] davinci: da8xx: clean up magic numbers in
	devices-da8xx.c
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-3-git-send-email-michael.williamson@criticallink.com>

Extract magic numbers from DMA resource initializers to #defines.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/devices-da8xx.c |   21 +++++++++++++--------
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..119d46e 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -44,6 +44,11 @@
 #define DA8XX_EMAC_RAM_OFFSET		0x0000
 #define DA8XX_EMAC_CTRL_RAM_SIZE	SZ_8K
 
+#define DA8XX_DMA_MMCSD0_RX	EDMA_CTLR_CHAN(0, 16)
+#define DA8XX_DMA_MMCSD0_TX	EDMA_CTLR_CHAN(0, 17)
+#define DA850_DMA_MMCSD1_RX	EDMA_CTLR_CHAN(1, 28)
+#define DA850_DMA_MMCSD1_TX	EDMA_CTLR_CHAN(1, 29)
+
 void __iomem *da8xx_syscfg0_base;
 void __iomem *da8xx_syscfg1_base;
 
@@ -573,13 +578,13 @@ static struct resource da8xx_mmcsd0_resources[] = {
 		.flags	= IORESOURCE_IRQ,
 	},
 	{		/* DMA RX */
-		.start	= EDMA_CTLR_CHAN(0, 16),
-		.end	= EDMA_CTLR_CHAN(0, 16),
+		.start	= DA8XX_DMA_MMCSD0_RX,
+		.end	= DA8XX_DMA_MMCSD0_RX,
 		.flags	= IORESOURCE_DMA,
 	},
 	{		/* DMA TX */
-		.start	= EDMA_CTLR_CHAN(0, 17),
-		.end	= EDMA_CTLR_CHAN(0, 17),
+		.start	= DA8XX_DMA_MMCSD0_TX,
+		.end	= DA8XX_DMA_MMCSD0_TX,
 		.flags	= IORESOURCE_DMA,
 	},
 };
@@ -610,13 +615,13 @@ static struct resource da850_mmcsd1_resources[] = {
 		.flags	= IORESOURCE_IRQ,
 	},
 	{		/* DMA RX */
-		.start	= EDMA_CTLR_CHAN(1, 28),
-		.end	= EDMA_CTLR_CHAN(1, 28),
+		.start	= DA850_DMA_MMCSD1_RX,
+		.end	= DA850_DMA_MMCSD1_RX,
 		.flags	= IORESOURCE_DMA,
 	},
 	{		/* DMA TX */
-		.start	= EDMA_CTLR_CHAN(1, 29),
-		.end	= EDMA_CTLR_CHAN(1, 29),
+		.start	= DA850_DMA_MMCSD1_TX,
+		.end	= DA850_DMA_MMCSD1_TX,
 		.flags	= IORESOURCE_DMA,
 	},
 };
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:36:58 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:36:58 -0500
Subject: [PATCH v3 3/9] davinci: spi: move event queue parameter to platform
	data
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-4-git-send-email-michael.williamson@criticallink.com>

For DMA operation, the davinci spi driver needs an event queue number.
Currently, this number is passed as a IORESOURCE_DMA.  This is not
correct, as the event queue is not a DMA channel.  Pass the event queue
via the platform data structure instead.

On dm355 and dm365, move the eventq assignment for spi0 out of resources
array and into platform data.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Grant Likely <grant.likely at secretlab.ca>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/dm355.c            |    5 +----
 arch/arm/mach-davinci/dm365.c            |    5 +----
 arch/arm/mach-davinci/include/mach/spi.h |   15 ++++++++++-----
 drivers/spi/davinci_spi.c                |   11 +++--------
 4 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a5f8a80..76364d1 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -403,16 +403,13 @@ static struct resource dm355_spi0_resources[] = {
 		.start = 16,
 		.flags = IORESOURCE_DMA,
 	},
-	{
-		.start = EVENTQ_1,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct davinci_spi_platform_data dm355_spi0_pdata = {
 	.version 	= SPI_VERSION_1,
 	.num_chipselect = 2,
 	.cshold_bug	= true,
+	.dma_event_q	= EVENTQ_1,
 };
 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 02d2cc3..4604e72 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -625,6 +625,7 @@ 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,
+	.dma_event_q	= EVENTQ_3,
 };
 
 static struct resource dm365_spi0_resources[] = {
@@ -645,10 +646,6 @@ static struct resource dm365_spi0_resources[] = {
 		.start = 16,
 		.flags = IORESOURCE_DMA,
 	},
-	{
-		.start = EVENTQ_3,
-		.flags = IORESOURCE_DMA,
-	},
 };
 
 static struct platform_device dm365_spi0_device = {
diff --git a/arch/arm/mach-davinci/include/mach/spi.h b/arch/arm/mach-davinci/include/mach/spi.h
index 38f4da5..7af305b 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -19,6 +19,8 @@
 #ifndef __ARCH_ARM_DAVINCI_SPI_H
 #define __ARCH_ARM_DAVINCI_SPI_H
 
+#include <mach/edma.h>
+
 #define SPI_INTERN_CS	0xFF
 
 enum {
@@ -39,13 +41,16 @@ enum {
  *		to populate if all chip-selects are internal.
  * @cshold_bug:	set this to true if the SPI controller on your chip requires
  *		a write to CSHOLD bit in between transfers (like in DM355).
+ * @dma_event_q: DMA event queue to use if SPI_IO_TYPE_DMA is used for any
+ *		device on the bus.
  */
 struct davinci_spi_platform_data {
-	u8	version;
-	u8	num_chipselect;
-	u8	intr_line;
-	u8	*chip_sel;
-	bool	cshold_bug;
+	u8			version;
+	u8			num_chipselect;
+	u8			intr_line;
+	u8			*chip_sel;
+	bool			cshold_bug;
+	enum dma_event_q	dma_event_q;
 };
 
 /**
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 6beab99..166a879 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -790,7 +790,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	struct resource *r, *mem;
 	resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
 	resource_size_t	dma_tx_chan = SPI_NO_RESOURCE;
-	resource_size_t	dma_eventq = SPI_NO_RESOURCE;
 	int i = 0, ret = 0;
 	u32 spipc0;
 
@@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device *pdev)
 	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;
 
 	dspi->bitbang.txrx_bufs = davinci_spi_bufs;
 	if (dma_rx_chan != SPI_NO_RESOURCE &&
-	    dma_tx_chan != SPI_NO_RESOURCE &&
-	    dma_eventq != SPI_NO_RESOURCE) {
+	    dma_tx_chan != SPI_NO_RESOURCE) {
 		dspi->dma.rx_channel = dma_rx_chan;
 		dspi->dma.tx_channel = dma_tx_chan;
-		dspi->dma.eventq = dma_eventq;
+		dspi->dma.eventq = pdata->dma_event_q;
 
 		ret = davinci_spi_request_dma(dspi);
 		if (ret)
@@ -897,7 +892,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
 		dev_info(&pdev->dev, "DMA: supported\n");
 		dev_info(&pdev->dev, "DMA: RX channel: %d, TX channel: %d, "
 				"event queue: %d\n", dma_rx_chan, dma_tx_chan,
-				dma_eventq);
+				pdata->dma_event_q);
 	}
 
 	dspi->get_rx = davinci_spi_rx_buf_u8;
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:37:00 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:37:00 -0500
Subject: [PATCH v3 5/9] davinci: da850: add spi device clock definitions
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-6-git-send-email-michael.williamson@criticallink.com>

Add spi clock information for da850.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/da850.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..68fe4c2 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -359,6 +359,20 @@ static struct clk usb20_clk = {
 	.gpsc		= 1,
 };
 
+static struct clk spi0_clk = {
+	.name		= "spi0",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_SPI0,
+};
+
+static struct clk spi1_clk = {
+	.name		= "spi1",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_SPI1,
+	.gpsc		= 1,
+	.flags		= DA850_CLK_ASYNC3,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -403,6 +417,8 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"aemif",	&aemif_clk),
 	CLK(NULL,		"usb11",	&usb11_clk),
 	CLK(NULL,		"usb20",	&usb20_clk),
+	CLK("spi_davinci.0",	NULL,		&spi0_clk),
+	CLK("spi_davinci.1",	NULL,		&spi1_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:37:03 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:37:03 -0500
Subject: [PATCH v3 8/9] davinci: add spi devices support for
	da850/omap-l138/am18x evm
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-9-git-send-email-michael.williamson@criticallink.com>

From: Sekhar Nori <nsekhar at ti.com>

This patch adds the on-board SPI flash device to the
DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
device to the MTD subsystem.

Based on SPI flash device support for MityDSP-L138F platform.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da850_evm_spi1_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   86 +++++++++++++++++++++++++++++++
 1 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..ee2094f 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,8 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/tps6507x.h>
 #include <linux/input/tps6507x-ts.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -38,6 +40,7 @@
 #include <mach/nand.h>
 #include <mach/mux.h>
 #include <mach/aemif.h>
+#include <mach/spi.h>
 
 #define DA850_EVM_PHY_ID		"0:00"
 #define DA850_LCD_PWR_PIN		GPIO_TO_PIN(2, 8)
@@ -48,6 +51,87 @@
 
 #define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
 
+static struct mtd_partition da850evm_spiflash_part[] = {
+	[0] = {
+		.name = "UBL",
+		.offset = 0,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[1] = {
+		.name = "U-Boot",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_512K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[2] = {
+		.name = "U-Boot-Env",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[3] = {
+		.name = "Kernel",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_2M + SZ_512K,
+		.mask_flags = 0,
+	},
+	[4] = {
+		.name = "Filesystem",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_4M,
+		.mask_flags = 0,
+	},
+	[5] = {
+		.name = "MAC-Address",
+		.offset = SZ_8M - SZ_64K,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+};
+
+static struct flash_platform_data da850evm_spiflash_data = {
+	.name		= "m25p80",
+	.parts		= da850evm_spiflash_part,
+	.nr_parts	= ARRAY_SIZE(da850evm_spiflash_part),
+	.type		= "m25p64",
+};
+
+static struct davinci_spi_config da850evm_spiflash_cfg = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info da850evm_spi_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &da850evm_spiflash_data,
+		.controller_data	= &da850evm_spiflash_cfg,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 1,
+		.chip_select		= 0,
+	},
+};
+
+static void __init da850evm_init_spi1(struct spi_board_info *info, unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("%s: failed to register board info : %d\n",
+			   __func__, ret);
+
+	da8xx_spi_pdata[1].num_chipselect = len;
+
+	ret = da8xx_register_spi(1);
+	if (ret)
+		pr_warning("%s: failed to register spi 1 device : %d\n",
+			   __func__, ret);
+}
+
 static struct mtd_partition da850_evm_norflash_partition[] = {
 	{
 		.name           = "bootloaders + env",
@@ -1167,6 +1251,8 @@ static __init void da850_evm_init(void)
 	if (ret)
 		pr_warning("da850_evm_init: suspend registration failed: %d\n",
 				ret);
+
+	da850evm_init_spi1(da850evm_spi_info, ARRAY_SIZE(da850evm_spi_info));
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:37:04 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:37:04 -0500
Subject: [PATCH v3 9/9] davinci: add spi devices support for
	da830/omap-l137/am17x evm
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-10-git-send-email-michael.williamson@criticallink.com>

From: Sekhar Nori <nsekhar at ti.com>

This patch adds the on-board SPI flash device to the
DA830/OMAP-L137/AM17x EVM. It also registers the SPI flash
device to the MTD subsystem.

Based on SPI flash device support for MityDSP-L138F platform.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da830evm_spi0_pdata to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-da830-evm.c |   80 +++++++++++++++++++++++++++++++
 1 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index b52a3a1..93a47e3 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -20,6 +20,8 @@
 #include <linux/i2c/at24.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -30,6 +32,7 @@
 #include <mach/da8xx.h>
 #include <mach/usb.h>
 #include <mach/aemif.h>
+#include <mach/spi.h>
 
 #define DA830_EVM_PHY_ID		""
 /*
@@ -534,6 +537,81 @@ static struct edma_rsv_info da830_edma_rsv[] = {
 	},
 };
 
+static struct mtd_partition da830evm_spiflash_part[] = {
+	[0] = {
+		.name = "DSP-UBL",
+		.offset = 0,
+		.size = SZ_8K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[1] = {
+		.name = "ARM-UBL",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_16K + SZ_8K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[2] = {
+		.name = "U-Boot",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_256K - SZ_32K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[3] = {
+		.name = "U-Boot-Environment",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_16K,
+		.mask_flags = 0,
+	},
+	[4] = {
+		.name = "Kernel",
+		.offset = MTDPART_OFS_APPEND,
+		.size = MTDPART_SIZ_FULL,
+		.mask_flags = 0,
+	},
+};
+
+static struct flash_platform_data da830evm_spiflash_data = {
+	.name		= "m25p80",
+	.parts		= da830evm_spiflash_part,
+	.nr_parts	= ARRAY_SIZE(da830evm_spiflash_part),
+	.type		= "w25x32",
+};
+
+static struct davinci_spi_config da830evm_spiflash_cfg = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info da830evm_spi_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &da830evm_spiflash_data,
+		.controller_data	= &da830evm_spiflash_cfg,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 0,
+		.chip_select		= 0,
+	},
+};
+
+static void __init da830evm_init_spi0(struct spi_board_info *info, unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("%s: failed to register board info : %d\n",
+			   __func__, ret);
+
+	da8xx_spi_pdata[0].num_chipselect = len;
+
+	ret = da8xx_register_spi(0);
+	if (ret)
+		pr_warning("%s: failed to register spi 0 device : %d\n",
+			   __func__, ret);
+}
+
 static __init void da830_evm_init(void)
 {
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -590,6 +668,8 @@ static __init void da830_evm_init(void)
 	ret = da8xx_register_rtc();
 	if (ret)
 		pr_warning("da830_evm_init: rtc setup failed: %d\n", ret);
+
+	da830evm_init_spi0(da830evm_spi_info, ARRAY_SIZE(da830evm_spi_info));
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:37:02 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:37:02 -0500
Subject: [PATCH v3 7/9] davinci: add spi devices support for
	MityDSP-L138/MityARM-1808 platform
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-8-git-send-email-michael.williamson@criticallink.com>

This patch adds support for accessing the on board SPI NOR FLASH
device for MityDSP-L138 and MityARM-1808 SoMs.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Tested-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-mityomapl138.c |  100 ++++++++++++++++++++++++++++
 1 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 0ea5932..dc4c3f1 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -17,6 +17,8 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/etherdevice.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -25,6 +27,7 @@
 #include <mach/da8xx.h>
 #include <mach/nand.h>
 #include <mach/mux.h>
+#include <mach/spi.h>
 
 #define MITYOMAPL138_PHY_ID		"0:03"
 
@@ -294,6 +297,100 @@ static int __init pmic_tps65023_init(void)
 }
 
 /*
+ * SPI Devices:
+ *	SPI1_CS0: 8M Flash ST-M25P64-VME6G
+ */
+static struct mtd_partition spi_flash_partitions[] = {
+	[0] = {
+		.name		= "ubl",
+		.offset		= 0,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[1] = {
+		.name		= "u-boot",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_512K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[2] = {
+		.name		= "u-boot-env",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[3] = {
+		.name		= "periph-config",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[4] = {
+		.name		= "reserved",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_256K + SZ_64K,
+	},
+	[5] = {
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M + SZ_1M,
+	},
+	[6] = {
+		.name		= "fpga",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M,
+	},
+	[7] = {
+		.name		= "spare",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+	},
+};
+
+static struct flash_platform_data mityomapl138_spi_flash_data = {
+	.name		= "m25p80",
+	.parts		= spi_flash_partitions,
+	.nr_parts	= ARRAY_SIZE(spi_flash_partitions),
+	.type		= "m24p64",
+};
+
+static struct davinci_spi_config spi_eprom_config = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info mityomapl138_spi_flash_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &mityomapl138_spi_flash_data,
+		.controller_data	= &spi_eprom_config,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 1,
+		.chip_select		= 0,
+	},
+};
+
+static void __init mityomapl138_init_spi1(struct spi_board_info *info,
+					  unsigned len)
+{
+	int ret;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("%s: failed to register board info : %d\n",
+				__func__, ret);
+
+	da8xx_spi_pdata[1].num_chipselect = len;
+
+	ret = da8xx_register_spi(1);
+	if (ret)
+		pr_warning("%s: failed to register spi 1 device : %d\n",
+				__func__, ret);
+}
+
+/*
  * MityDSP-L138 includes a 256 MByte large-page NAND flash
  * (128K blocks).
  */
@@ -448,6 +545,9 @@ static void __init mityomapl138_init(void)
 
 	mityomapl138_setup_nand();
 
+	mityomapl138_init_spi1(mityomapl138_spi_flash_info,
+			       ARRAY_SIZE(mityomapl138_spi_flash_info));
+
 	mityomapl138_config_emac();
 
 	ret = da8xx_register_rtc();
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:36:59 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:36:59 -0500
Subject: [PATCH v3 4/9] davinci: da830: fix driver name for spi clocks
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-5-git-send-email-michael.williamson@criticallink.com>

The spi driver name called out for the da830 spi clock list is not correct,
fix it.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/da830.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index ec23ab4..826118e 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -397,8 +397,8 @@ static struct clk_lookup da830_clks[] = {
 	CLK(NULL,		"uart0",	&uart0_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
-	CLK("dm_spi.0",		NULL,		&spi0_clk),
-	CLK("dm_spi.1",		NULL,		&spi1_clk),
+	CLK("spi_davinci.0",	NULL,		&spi0_clk),
+	CLK("spi_davinci.1",	NULL,		&spi1_clk),
 	CLK(NULL,		"ecap0",	&ecap0_clk),
 	CLK(NULL,		"ecap1",	&ecap1_clk),
 	CLK(NULL,		"ecap2",	&ecap2_clk),
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:37:01 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:37:01 -0500
Subject: [PATCH v3 6/9] davinci: da8xx: add spi resources and registration
	routine
In-Reply-To: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298381824-7723-7-git-send-email-michael.williamson@criticallink.com>

Add IO resource structures, platform data, and a registration
routine in order to support spi device on DA850/OMAP-L138/AM18x
and DA830/OMAP-L137/AM17x platforms.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/devices-da8xx.c      |   98 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 2 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 119d46e..3a6e4fd 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -38,14 +38,20 @@
 #define DA8XX_EMAC_MDIO_BASE		0x01e24000
 #define DA8XX_GPIO_BASE			0x01e26000
 #define DA8XX_I2C1_BASE			0x01e28000
+#define DA8XX_SPI0_BASE			0x01c41000
+#define DA8XX_SPI1_BASE			0x01f0e000
 
 #define DA8XX_EMAC_CTRL_REG_OFFSET	0x3000
 #define DA8XX_EMAC_MOD_REG_OFFSET	0x2000
 #define DA8XX_EMAC_RAM_OFFSET		0x0000
 #define DA8XX_EMAC_CTRL_RAM_SIZE	SZ_8K
 
+#define DA8XX_DMA_SPI0_RX	EDMA_CTLR_CHAN(0, 14)
+#define DA8XX_DMA_SPI0_TX	EDMA_CTLR_CHAN(0, 15)
 #define DA8XX_DMA_MMCSD0_RX	EDMA_CTLR_CHAN(0, 16)
 #define DA8XX_DMA_MMCSD0_TX	EDMA_CTLR_CHAN(0, 17)
+#define DA8XX_DMA_SPI1_RX	EDMA_CTLR_CHAN(0, 18)
+#define DA8XX_DMA_SPI1_TX	EDMA_CTLR_CHAN(0, 19)
 #define DA850_DMA_MMCSD1_RX	EDMA_CTLR_CHAN(1, 28)
 #define DA850_DMA_MMCSD1_TX	EDMA_CTLR_CHAN(1, 29)
 
@@ -730,3 +736,95 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+
+static struct resource da8xx_spi0_resources[] = {
+	[0] = {
+		.start	= DA8XX_SPI0_BASE,
+		.end	= DA8XX_SPI0_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_DA8XX_SPINT0,
+		.end	= IRQ_DA8XX_SPINT0,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		.start	= DA8XX_DMA_SPI0_RX,
+		.end	= DA8XX_DMA_SPI0_RX,
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		.start	= DA8XX_DMA_SPI0_TX,
+		.end	= DA8XX_DMA_SPI0_TX,
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+static struct resource da8xx_spi1_resources[] = {
+	[0] = {
+		.start	= DA8XX_SPI1_BASE,
+		.end	= DA8XX_SPI1_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_DA8XX_SPINT1,
+		.end	= IRQ_DA8XX_SPINT1,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		.start	= DA8XX_DMA_SPI1_RX,
+		.end	= DA8XX_DMA_SPI1_RX,
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		.start	= DA8XX_DMA_SPI1_TX,
+		.end	= DA8XX_DMA_SPI1_TX,
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+struct davinci_spi_platform_data da8xx_spi_pdata[] = {
+	[0] = {
+		.version	= SPI_VERSION_2,
+		.intr_line	= 1,
+		.dma_event_q	= EVENTQ_0,
+	},
+	[1] = {
+		.version	= SPI_VERSION_2,
+		.intr_line	= 1,
+		.dma_event_q	= EVENTQ_0,
+	},
+};
+
+static struct platform_device da8xx_spi_device[] = {
+	[0] = {
+		.name		= "spi_davinci",
+		.id		= 0,
+		.num_resources	= ARRAY_SIZE(da8xx_spi0_resources),
+		.resource	= da8xx_spi0_resources,
+		.dev		= {
+			.platform_data = &da8xx_spi_pdata[0],
+		},
+	},
+	[1] = {
+		.name		= "spi_davinci",
+		.id		= 1,
+		.num_resources	= ARRAY_SIZE(da8xx_spi1_resources),
+		.resource	= da8xx_spi1_resources,
+		.dev		= {
+			.platform_data = &da8xx_spi_pdata[1],
+		},
+	},
+};
+
+int __init da8xx_register_spi(int instance)
+{
+	struct platform_device *pdev;
+
+	if (instance == 0 || instance == 1)
+		pdev = &da8xx_spi_device[instance];
+	else
+		return -EINVAL;
+
+	return platform_device_register(pdev);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..0c5fa01 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -23,6 +23,7 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 #include <mach/pm.h>
+#include <mach/spi.h>
 
 extern void __iomem *da8xx_syscfg0_base;
 extern void __iomem *da8xx_syscfg1_base;
@@ -77,6 +78,7 @@ void __init da850_init(void);
 int da830_register_edma(struct edma_rsv_info *rsv);
 int da850_register_edma(struct edma_rsv_info *rsv[2]);
 int da8xx_register_i2c(int instance, struct davinci_i2c_platform_data *pdata);
+int da8xx_register_spi(int instance);
 int da8xx_register_watchdog(void);
 int da8xx_register_usb20(unsigned mA, unsigned potpgt);
 int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
@@ -95,6 +97,7 @@ extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
+extern struct davinci_spi_platform_data da8xx_spi_pdata[];
 
 extern struct platform_device da8xx_wdt_device;
 
-- 
1.7.0.4


From michael.williamson at criticallink.com  Tue Feb 22 07:36:55 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 22 Feb 2011 08:36:55 -0500
Subject: [PATCH v3 0/9] davinci: Add spi support for da8xx platforms
Message-ID: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>

This patch series adds the necessary SPI resources and registration
routines for da850/OMAP-L138/AM18x and da830/OMAP-L137/AM17x devices.

It removes some unused enumerations related to the DMA channels
for the da830 platform as a result of initial reviews of the patch
series.

It moves the event queue number for the SPI DMA control out of
the resources array and into the platform data structure passed to
the davinci spi driver.

It adds on-board SPI FLASH devices for the da830 evm, the da850
evm, and the MityDSP-L138/MityARM-1808 platforms.

These patches are based on work done during testing of davinci SPI driver
submissions incorporated in version 2.6.38 of the kernel, at [1].

This patch series has been tested using a MityDSP-L138 platform, 
and the da850 and da830 EVMs.

The patch series is against linux-davinci tree.  The davinci spi driver
portion of this patch has been reviewed by the spi list and Acked
by Grant with the agreement to submit through linux-davinci tree.

[1] http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/davinci-spi-rewrite

---
Changes since v2:
   - combined previously approved / Acked patches into this 
     patch series per request from maintainer.
   - fixed whitespace issue identified by checkpatch
   - added function name for warning tracing per comments

Michael Williamson (7):
  davinci: remove unused DA830_edma_ch enum
  davinci: da8xx: clean up magic numbers in devices-da8xx.c
  davinci: spi: move event queue parameter to platform data
  davinci: da830: fix driver name for spi clocks
  davinci: da850: add spi device clock definitions
  davinci: da8xx: add spi resources and registration routine
  davinci: add spi devices support for MityDSP-L138/MityARM-1808
    platform

Sekhar Nori (2):
  davinci: add spi devices support for da850/omap-l138/am18x evm
  davinci: add spi devices support for da830/omap-l137/am17x evm

 arch/arm/mach-davinci/board-da830-evm.c    |   80 +++++++++++++++++++
 arch/arm/mach-davinci/board-da850-evm.c    |   86 ++++++++++++++++++++
 arch/arm/mach-davinci/board-mityomapl138.c |  100 +++++++++++++++++++++++
 arch/arm/mach-davinci/da830.c              |    4 +-
 arch/arm/mach-davinci/da850.c              |   16 ++++
 arch/arm/mach-davinci/devices-da8xx.c      |  119 ++++++++++++++++++++++++++--
 arch/arm/mach-davinci/dm355.c              |    5 +-
 arch/arm/mach-davinci/dm365.c              |    5 +-
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 arch/arm/mach-davinci/include/mach/edma.h  |   36 ---------
 arch/arm/mach-davinci/include/mach/spi.h   |   15 +++-
 drivers/spi/davinci_spi.c                  |   11 +--
 12 files changed, 413 insertions(+), 67 deletions(-)


From gregkh at suse.de  Tue Feb 22 08:37:04 2011
From: gregkh at suse.de (Greg KH)
Date: Tue, 22 Feb 2011 06:37:04 -0800
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <9826735BD9DD48A599C595D28C4A05F0@subhasishg>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<20110218143500.23b3044b@lxorguk.ukuu.org.uk>
	<alpine.LFD.2.00.1102181917520.2701@localhost6.localdomain6>
	<201102181951.32631.arnd@arndb.de>
	<9826735BD9DD48A599C595D28C4A05F0@subhasishg>
Message-ID: <20110222143704.GA978@suse.de>

On Tue, Feb 22, 2011 at 02:12:32PM +0530, Subhasish Ghosh wrote:
> Hello,
> 
> I had kept separate files to affirm the modularity and ease of
> portability of the system.
> 
> There are three different interfaces,
> 1. The Linux driver interface
> 2. The PRU control interface
> 3. The McASP serializer interface.
> 
> To maintain modularity, I  had classified the files respectively as :
> 1.  pruss_suart.c
> 2.  pruss_suart_api.c
> 3.  pruss_suart_utils.c
> 
> This is not a single device which can be expressed as a single file,
> but functionally different devices logically cascaded together to
> work in unison.
> 
> We use the PRU for packet processing, but the actual data is
> transmitted/received through the
> McASP, which we use as a serializer.
> 
> I feel to combine these disparate functionalities into a single file
> will not
> 
> 1. Help better understanding the device. I mean, why should a TTY
> UART driver be aware of the McASP or the PRU.
> 2. In case of a bug in the API layer or McASP, the driver need not
> be touched, thus improve maintainability.
> 3. If we need to port it to another Linux version, just editing the
> driver file should suffice, this will reduce bugs while porting.

If your code is in the kernel tree, you do not need to ever port it to a
new version, as it will happen automatically as new kernels are
released, so this really isn't anything to worry about.

> To me, combining all of these into a single file only creates a
> mess. This is the reason I had separated them into different files!!
> I don't understand why should it be better to have all of these into
> a single file.

As Alan stated, just use 3 files in the directory with the other
drivers, you don't need a subdir for something small like this.

thanks,

greg k-h

From shilpab at spectrumdigital.com  Tue Feb 22 09:56:58 2011
From: shilpab at spectrumdigital.com (shilpab)
Date: Tue, 22 Feb 2011 07:56:58 -0800 (PST)
Subject: USB0 problem on OMAPL138
In-Reply-To: <AANLkTim2kOE+-YkPyem1g+JZhL2CTOHYy8wiDhO7439J@mail.gmail.com>
References: <AANLkTim8sy97TwGuUmBTZmngryhKHs3wQ5PGah9BdMv0@mail.gmail.com>
	<1298305954111-6049272.post@n2.nabble.com>
	<AANLkTinTUU8AMJSAeK1HyNWnQ4Bg2Z9EZDNmhBZN0umx@mail.gmail.com>
	<1298307750577-6049369.post@n2.nabble.com>
	<1298314145591-6049714.post@n2.nabble.com>
	<AANLkTi=rHoR5m6_Q6+9LFi+NPNTDzWy=3bRdPex6zOWm@mail.gmail.com>
	<1298318709085-6049926.post@n2.nabble.com>
	<AANLkTim2kOE+-YkPyem1g+JZhL2CTOHYy8wiDhO7439J@mail.gmail.com>
Message-ID: <1298390218956-6052861.post@n2.nabble.com>


Thanks Marc for all your help .We got the wireless adapter to enumerate on
both USB0 and USB1 ports and successfully get the ipaddresses. We couldn't
have done without your help.

Shilpa.
-- 
View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/USB0-problem-on-OMAPL138-tp5559521p6052861.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.

From arnd at arndb.de  Tue Feb 22 10:34:15 2011
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 22 Feb 2011 17:34:15 +0100
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <DADE3366197E4479A57F3B967A881C33@subhasishg>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<201102181951.32631.arnd@arndb.de>
	<DADE3366197E4479A57F3B967A881C33@subhasishg>
Message-ID: <201102221734.15582.arnd@arndb.de>

On Tuesday 22 February 2011, Subhasish Ghosh wrote:

> @@ -122,13 +122,10 @@ static void omapl_pru_tx_chars(struct omapl_pru_suart 
> *soft_uart, u32 uart_no)
>         if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
>                 return;
> 
> -       if (down_trylock(&soft_uart->port_sem[uart_no]))
> -               return;
> -
>         if (uart_circ_empty(xmit) ||
>                         uart_tx_stopped(&soft_uart->port[uart_no])) {
>                 pruss_suart_stop_tx(&soft_uart->port[uart_no]);
> -               up(&soft_uart->port_sem[uart_no]);
> +               soft_uart->tx_empty[uart_no] = true;
>                 return;
>         }
> 
> @@ -259,7 +256,6 @@ static irqreturn_t pruss_suart_interrupt(s32 irq, void 
> *dev_id)
>                         pru_intr_clr_isrstatus(dev, uart_num, PRU_TX_INTR);
>                         pru_softuart_clr_tx_status(dev, &soft_uart->suart_hdl
>                                                  [port->line]);
> -                       up(&soft_uart->port_sem[port->line]);
>                         omapl_pru_tx_chars(soft_uart, port->line);
>                 }
>         } while (txrx_flag & (PRU_RX_INTR | PRU_TX_INTR));
> @@ -294,7 +290,10 @@ static void pruss_suart_start_tx(struct uart_port 
> *port)
> 
>         suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
>                            PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
> -       omapl_pru_tx_chars(soft_uart, port->line);
> +       if (soft_uart->tx_empty[port->line] == true) {
> +               soft_uart->tx_empty[port->line] = false;
> +               omapl_pru_tx_chars(soft_uart, port->line);
> +       }
>  }

This looks racy, and I think you at least need to take the spinlock in
pruss_suart_start_tx(), but I don't fully understand the intention of the
code.

I guess you could also use a bitmask for tx_empty and use test_and_clear_bit()
on that to guarantee atomicity.

	Arnd

From lamiaposta71 at gmail.com  Tue Feb 22 20:52:30 2011
From: lamiaposta71 at gmail.com (Raffaele Recalcati)
Date: Wed, 23 Feb 2011 03:52:30 +0100
Subject: Recent kernel for DM365 and status of the staging tree
In-Reply-To: <AANLkTinVdBhO8BJoTekPGbYVwdJkZgiqxkLR7YQFEEnx@mail.gmail.com>
References: <AANLkTingc3Zh9UqYr3mr6-75XHAG22FMQ3dm9ofsh1RW@mail.gmail.com>
	<AANLkTimLGUa=DsJyyD-3YQB8vUoF3BC-_zD_+jX8q7+x@mail.gmail.com>
	<B85A65D85D7EB246BE421B3FB0FBB59302488B9BB6@dbde02.ent.ti.com>
	<B85A65D85D7EB246BE421B3FB0FBB5930247F50DBA@dbde02.ent.ti.com>
	<AANLkTinVdBhO8BJoTekPGbYVwdJkZgiqxkLR7YQFEEnx@mail.gmail.com>
Message-ID: <AANLkTi=KArn7OtJncLc16v8qSSvDhRHUqOgdWOAM5S6j@mail.gmail.com>

My need for a recent kernel involves mmc management and a clean way to sync
and suspend it quikly while the power is going away (an irq advise me 100ms
before powerdown).
Regarding video capability I need yuv422 to yuv420 conversion for pal and
h264 encoding for pal and 720p formats.

Thx,
Raffaele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110223/f045e466/attachment.html>

From adityabarawkar at gmail.com  Tue Feb 22 21:38:44 2011
From: adityabarawkar at gmail.com (Aditya Barawkar)
Date: Wed, 23 Feb 2011 09:08:44 +0530
Subject: encodedecode demo audio-video
Message-ID: <AANLkTimVEn-i0bk8MjL07u+-OVi-YQrHHmHN12NgAtV1@mail.gmail.com>

hi,
 I am using a dm6446 EVM.
 I use the DVSDK1.2.

I have the demos encodedecode demo running.
But now i want that the audio should also be encoded and
decoded. Currently the encode decode demo supports only h.264 codec (after
googling i found dat it is a video only codec....no audio)
How can i make changes to the encodedecode demo to make the demo running for
audio??


My final aim is to develop an OSD application using embedded Qt, so the Qt
windows is on the OSD layer and the video input is being displayed in the
video window, with the audio component of it!

i think modifying the encodedecode demo can help(open for comment).


Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20110223/4a970a2b/attachment.html>

From subhasish at mistralsolutions.com  Tue Feb 22 23:30:25 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Wed, 23 Feb 2011 11:00:25 +0530
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <20110222143704.GA978@suse.de>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<20110218143500.23b3044b@lxorguk.ukuu.org.uk>
	<alpine.LFD.2.00.1102181917520.2701@localhost6.localdomain6>
	<201102181951.32631.arnd@arndb.de>
	<9826735BD9DD48A599C595D28C4A05F0@subhasishg>
	<20110222143704.GA978@suse.de>
Message-ID: <86364E209B534BF1ADB2764227483070@subhasishg>

I could not follow the recommendations clearly.
This is just to clarify.

Currently, I have the following files for the suart implementation:

drivers/tty/serial/da8xx_pruss/pruss_suart_api.h
drivers/tty/serial/da8xx_pruss/pruss_suart_err.h
drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h
drivers/tty/serial/da8xx_pruss/pruss_suart_board.h
drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h
drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h

drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
drivers/tty/serial/da8xx_pruss/pruss_suart.c
drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c

Of these, I will be removing pruss_suart_err.h as part of the Linux error 
code cleanup.
But, I need to keep at least  pruss_suart_board.h as a separate file, as 
this defines
configurations which will be often modified by users, I don't want to mix it 
with other files.

Should I combine rest of the headers into a single file ? and keep the other 
three .c files under "drivers/tty/serial/"
and remove the da8xx_pruss directory altogether.


--------------------------------------------------
From: "Greg KH" <gregkh at suse.de>
Sent: Tuesday, February 22, 2011 8:07 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: "Arnd Bergmann" <arnd at arndb.de>; <linux-arm-kernel at lists.infradead.org>; 
"Thomas Gleixner" <tglx at linutronix.de>; "Alan Cox" 
<alan at lxorguk.ukuu.org.uk>; <sachi at mistralsolutions.com>; 
<davinci-linux-open-source at linux.davincidsp.com>; <nsekhar at ti.com>; "open 
list" <linux-kernel at vger.kernel.org>; <m-watkins at ti.com>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver

> On Tue, Feb 22, 2011 at 02:12:32PM +0530, Subhasish Ghosh wrote:
>> Hello,
>>
>> I had kept separate files to affirm the modularity and ease of
>> portability of the system.
>>
>> There are three different interfaces,
>> 1. The Linux driver interface
>> 2. The PRU control interface
>> 3. The McASP serializer interface.
>>
>> To maintain modularity, I  had classified the files respectively as :
>> 1.  pruss_suart.c
>> 2.  pruss_suart_api.c
>> 3.  pruss_suart_utils.c
>>
>> This is not a single device which can be expressed as a single file,
>> but functionally different devices logically cascaded together to
>> work in unison.
>>
>> We use the PRU for packet processing, but the actual data is
>> transmitted/received through the
>> McASP, which we use as a serializer.
>>
>> I feel to combine these disparate functionalities into a single file
>> will not
>>
>> 1. Help better understanding the device. I mean, why should a TTY
>> UART driver be aware of the McASP or the PRU.
>> 2. In case of a bug in the API layer or McASP, the driver need not
>> be touched, thus improve maintainability.
>> 3. If we need to port it to another Linux version, just editing the
>> driver file should suffice, this will reduce bugs while porting.
>
> If your code is in the kernel tree, you do not need to ever port it to a
> new version, as it will happen automatically as new kernels are
> released, so this really isn't anything to worry about.
>
>> To me, combining all of these into a single file only creates a
>> mess. This is the reason I had separated them into different files!!
>> I don't understand why should it be better to have all of these into
>> a single file.
>
> As Alan stated, just use 3 files in the directory with the other
> drivers, you don't need a subdir for something small like this.
>
> thanks,
>
> greg k-h 


From nsekhar at ti.com  Wed Feb 23 06:01:38 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 23 Feb 2011 17:31:38 +0530
Subject: [PATCH] DaVinci: fix compilation warnings in <mach/clkdev.h>
In-Reply-To: <201102092133.23765.sshtylyov@ru.mvista.com>
References: <201102092133.23765.sshtylyov@ru.mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BD4987F@dbde02.ent.ti.com>

Hi Sergei,

On Thu, Feb 10, 2011 at 00:03:23, Sergei Shtylyov wrote:
> Commit 6d803ba736abb5e122dede70a4720e4843dd6df4 (ARM: 6483/1: arm & sh:
> factorised duplicated clkdev.c) caused the following warnings:
> 
> In file included from /home/headless/src/kernel.org/linux-davinci/arch/arm/
> include/asm/clkdev.h:17,
>                  from include/linux/clkdev.h:15,
>                  from arch/arm/mach-davinci/clock.h:71,
>                  from arch/arm/mach-davinci/common.c:22:
> arch/arm/mach-davinci/include/mach/clkdev.h:4: warning: `struct clk' declared
> inside parameter list
> arch/arm/mach-davinci/include/mach/clkdev.h:4: warning: its scope is only this
> definition or declaration, which is probably not what you want
> arch/arm/mach-davinci/include/mach/clkdev.h:9: warning: `struct clk' declared
> inside parameter list
> 
> Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>

>  
> +struct clk;
> +
>  static inline int __clk_get(struct clk *clk)
>  {
>  	return 1;

This looks good to me. It should be queued for 2.6.38-rc
Kevin is going to handle the 2.6.38 and 2.6.39 kernels
so will queue this for him.

Thanks,
Sekhar


From subhasish at mistralsolutions.com  Wed Feb 23 06:25:44 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Wed, 23 Feb 2011 17:55:44 +0530
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
In-Reply-To: <20110222103127.GC30279@sortiz-mobl>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
	<20110221163027.GF10686@sortiz-mobl>
	<37B3755C4AE64BAA805DFBAEBDC3D9E4@subhasishg>
	<20110222103127.GC30279@sortiz-mobl>
Message-ID: <24ADBD8C15AA48568F25C781C14387B2@subhasishg>

--------------------------------------------------
From: "Samuel Ortiz" <sameo at linux.intel.com>
Sent: Tuesday, February 22, 2011 4:01 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Cc: <davinci-linux-open-source at linux.davincidsp.com>; 
<linux-arm-kernel at lists.infradead.org>; <m-watkins at ti.com>; 
<nsekhar at ti.com>; <sachi at mistralsolutions.com>; "open list" 
<linux-kernel at vger.kernel.org>
Subject: Re: [PATCH v2 01/13] mfd: pruss mfd driver.

> Hi Subhasish,
>
> On Tue, Feb 22, 2011 at 11:13:38AM +0530, Subhasish Ghosh wrote:
>> Thank you for your comments.
> No problem.
>
>> >>diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> >>index fd01836..6c437df 100644
>> >>--- a/drivers/mfd/Kconfig
>> >>+++ b/drivers/mfd/Kconfig
>> >>@@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
>> >>   boards.  MSP430 firmware manages resets and power sequencing,
>> >>   inputs from buttons and the IR remote, LEDs, an RTC, and more.
>> >>
>> >>+config MFD_DA8XX_PRUSS
>> >>+ tristate "Texas Instruments DA8XX PRUSS support"
>> >>+ depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
>> >Why are we depending on those ?
>>
>> SG -- The PRUSS core in only available within DA850 and DA830,
>>            DA830 support is not yet implemented.
> Sure, but if there are no actual code dependencies, I'd like to get rid of
> those depends.


SG -- The PRU Clock and Power is the dependency here.
            This is available in arch/arm/mach-davinci/da850.c
            The source is specific to the SOC clock tree.

>
>> >>+u32 pruss_disable(struct device *dev, u8 pruss_num)
>> >>+{
>> >>+ struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
>> >>+ da8xx_prusscore_regs h_pruss;
>> >>+ u32 temp_reg;
>> >>+
>> >>+ if (pruss_num == DA8XX_PRUCORE_0) {
>> >>+ /* Disable PRU0  */
>> >>+ h_pruss = (da8xx_prusscore_regs)
>> >>+ ((u32) pruss->ioaddr + 0x7000);
>> >So it seems you're doing this in several places, and I have a few
>> >comments:
>> >
>> >- You don't need the da8xx_prusscore_regs at all.
>> >- Define the register map through a set of #define in your header file.
>> >- Use a static routine that takes the core number and returns the
>> >register map
>> >offset.
>> >
>> >Then routines like this one will look a lot more readable.
>>
>> SG -- There are a huge number of PRUSS registers. A lot of them are
>> reserved and are expected to change as development on the
>>            controller is still ongoing.
> First of all, from what I read in your patch you're only using the CONTROL
> offset.
>
>> If we use #defines to plot
>> all the registers, then first, there are too many array type
>> registers which will need to be duplicated.
> What I'm expecting is a small set of defines for the register offsets. You
> have 13 fields in your da8xx_prusscore_regs, you only need to define 13
> register offsets.
>
> So, if you have a:
>
> static u32 reg_offset(struct device *dev, u8 pru_num)
> {
> struct da8xx_pruss *pru = dev_get_drvdata(dev->parent);
>
> switch (pru_num) {
> case DA8XX_PRUCORE_0:
> return (u32) pru->ioaddr + 0x7000;
> case DA8XX_PRUCORE_1:
> return (u32) pru->ioaddr + 0x7800;
> default:
> return 0;
> }
>
>
> then routines like pruss_enable (which should return an int, btw) would 
> look
> like:
>
> int pruss_enable(struct device *dev, u8 pruss_num)
> {
> u32 offset = reg_offset(dev, pruss_num);
>
> if (offset == 0)
> return -EINVAL;
>
> __raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
> offset + PRU_CORE_CONTROL);
>
> return 0;
> }
>
>> >Also, all your exported routines severely lack any sort of locking. An 
>> >IO
>> >mutex or spinlock is mandatory here.
>>
>> SG - As per our current implementation, we do not have two devices
>> running simultaneously on the PRU,
>>        so we do not have any way to test it. We have kept this as an
>> enhancement if request comes in for
>>        multiple devices.
> It's not about having multiple devices at the same time, it's about having
> multiple callers writing and reading to the same registers. Since you're
> exporting all your I/O routines you have no way to prevent 2 drivers from
> writing to the same register at the "same" time. You need locking here,
> regardless of the number of devices that you can have on a system.
>

SG - Ok, will do

>
>> >>+static int pruss_mfd_add_devices(struct platform_device *pdev)
>> >>+{
>> >>+ struct da8xx_pruss_devices *dev_data = pdev->dev.platform_data;
>> >>+ struct device *dev = &pdev->dev;
>> >>+ struct mfd_cell cell;
>> >>+ u32 err, count;
>> >>+
>> >>+ for (count = 0; (dev_data + count)->dev_name != NULL; count++) {
>> >>+ memset(&cell, 0, sizeof(struct mfd_cell));
>> >>+ cell.id = count;
>> >>+ cell.name = (dev_data + count)->dev_name;
>> >>+ cell.platform_data = (dev_data + count)->pdata;
>> >>+ cell.data_size = (dev_data + count)->pdata_size;
>> >>+
>> >>+ err = mfd_add_devices(dev, 0, &cell, 1, NULL, 0);
>> >>+ if (err) {
>> >>+ dev_err(dev, "cannot add mfd cells\n");
>> >>+ return err;
>> >>+ }
>> >>+ }
>> >>+ return err;
>> >>+}
>> >So, what are the potential subdevices for this driver ? If it's a really
>> >dynamic setup, I'm fine with passing those as platform data but
>> >then do it so
>> >that you pass a NULL terminated da8xx_pruss_devices array. That will 
>> >avoid
>> >most of the ugly casts you're doing here.
>>
>> SG -- I did not follow your recommendations here, could you please
>> elaborate.
>>            I am already checking the dev_name for a NULL.
>>            This device is basically a microcontroller within DA850,
>> so basically any device or protocol can be
>>            emulated on it. Currently, we have emulated 8 UARTS using
>> the two PRUs and also a CAN device.
> Ok, I wasnt sure you can emulate anything on that thing. So I'm fine with 
> you
> passing all your devices through platform_data. But I'd prefer this 
> routine to
> look like:
>
> [...]
> for (count = 0; dev_data[count] != NULL; count++) {
> memset(&cell, 0, sizeof(struct mfd_cell));
> cell.id = count;
> cell.name = dev_data[count]->dev_name;
> cell.platform_data = dev_data[count]->pdata;
> cell.data_size = dev_data[count]->pdata_size;
>
> Looks nicer to me.

SG - I have a problem here, dev_data was initialized as a structure array.

static struct da8xx_pruss_devices pruss_devices[] = {
        {
                .dev_name       = "da8xx_pruss_can",
                .pdata          = &can_data,
                .pdata_size     = sizeof(can_data),
                .setup          = da850_evm_setup_pruss_can,
                .num_resources  = 0,
                .resources      = NULL,
        },
        {
                .dev_name       = "da8xx_pruss_uart",
                .pdata          = &suart_data,
                .pdata_size     = sizeof(suart_data),
                .setup          = da850_evm_setup_pruss_suart,
                .num_resources  = ARRAY_SIZE(da850_evm_suart_resource),
                .resources      = da850_evm_suart_resource,
        },
        {
                .dev_name       = NULL,
        },
};

How can I initialize the last array element to NULL!
I think, I must have some type of delimiter.

>
> Cheers,
> Samuel.
>
> -- 
> Intel Open Source Technology Centre
> http://oss.intel.com/ 


From linux at arm.linux.org.uk  Wed Feb 23 07:09:52 2011
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 23 Feb 2011 13:09:52 +0000
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
In-Reply-To: <20110222103127.GC30279@sortiz-mobl>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
	<20110221163027.GF10686@sortiz-mobl>
	<37B3755C4AE64BAA805DFBAEBDC3D9E4@subhasishg>
	<20110222103127.GC30279@sortiz-mobl>
Message-ID: <20110223130952.GJ29559@n2100.arm.linux.org.uk>

On Tue, Feb 22, 2011 at 11:31:27AM +0100, Samuel Ortiz wrote:
> So, if you have a:
> 
> static u32 reg_offset(struct device *dev, u8 pru_num)
> {
> 	struct da8xx_pruss *pru = dev_get_drvdata(dev->parent);
> 
> 	switch (pru_num) {
> 	case DA8XX_PRUCORE_0:
> 		return (u32) pru->ioaddr + 0x7000;
> 	case DA8XX_PRUCORE_1:
> 		return (u32) pru->ioaddr + 0x7800;
> 	default:
> 		return 0;
> }

No.  Please don't encourage people to have 'u32' as valid cookies for
readl,writel et.al.  Always make the mmio cookies __iomem pointer like.

From subhasish at mistralsolutions.com  Wed Feb 23 07:35:53 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Wed, 23 Feb 2011 19:05:53 +0530
Subject: [PATCH v2 13/13] tty: pruss SUART driver
Message-ID: <6E7634AAF813458489E0444DF71260CF@subhasishg>

Hello,

Anything regarding this.

--------------------------------------------------
From: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
Sent: Wednesday, February 23, 2011 11:00 AM
To: "Greg KH" <gregkh at suse.de>; "Alan Cox" <alan at lxorguk.ukuu.org.uk>
Cc: "Arnd Bergmann" <arnd at arndb.de>; <linux-arm-kernel at lists.infradead.org>; 
"Thomas Gleixner" <tglx at linutronix.de>; <sachi at mistralsolutions.com>; 
<davinci-linux-open-source at linux.davincidsp.com>; <nsekhar at ti.com>; "open 
list" <linux-kernel at vger.kernel.org>; <m-watkins at ti.com>; "Stalin 
Srinivasan" <stalin.s at mistralsolutions.com>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver

> I could not follow the recommendations clearly.
> This is just to clarify.
>
> Currently, I have the following files for the suart implementation:
>
> drivers/tty/serial/da8xx_pruss/pruss_suart_api.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_err.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_board.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h
>
> drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
> drivers/tty/serial/da8xx_pruss/pruss_suart.c
> drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c
>
> Of these, I will be removing pruss_suart_err.h as part of the Linux error 
> code cleanup.
> But, I need to keep at least  pruss_suart_board.h as a separate file, as 
> this defines
> configurations which will be often modified by users, I don't want to mix 
> it with other files.
>
> Should I combine rest of the headers into a single file ? and keep the 
> other three .c files under "drivers/tty/serial/"
> and remove the da8xx_pruss directory altogether.
>
>
> --------------------------------------------------
> From: "Greg KH" <gregkh at suse.de>
> Sent: Tuesday, February 22, 2011 8:07 PM
> To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>
> Cc: "Arnd Bergmann" <arnd at arndb.de>; 
> <linux-arm-kernel at lists.infradead.org>; "Thomas Gleixner" 
> <tglx at linutronix.de>; "Alan Cox" <alan at lxorguk.ukuu.org.uk>; 
> <sachi at mistralsolutions.com>; 
> <davinci-linux-open-source at linux.davincidsp.com>; <nsekhar at ti.com>; "open 
> list" <linux-kernel at vger.kernel.org>; <m-watkins at ti.com>
> Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver
>
>> On Tue, Feb 22, 2011 at 02:12:32PM +0530, Subhasish Ghosh wrote:
>>> Hello,
>>>
>>> I had kept separate files to affirm the modularity and ease of
>>> portability of the system.
>>>
>>> There are three different interfaces,
>>> 1. The Linux driver interface
>>> 2. The PRU control interface
>>> 3. The McASP serializer interface.
>>>
>>> To maintain modularity, I  had classified the files respectively as :
>>> 1.  pruss_suart.c
>>> 2.  pruss_suart_api.c
>>> 3.  pruss_suart_utils.c
>>>
>>> This is not a single device which can be expressed as a single file,
>>> but functionally different devices logically cascaded together to
>>> work in unison.
>>>
>>> We use the PRU for packet processing, but the actual data is
>>> transmitted/received through the
>>> McASP, which we use as a serializer.
>>>
>>> I feel to combine these disparate functionalities into a single file
>>> will not
>>>
>>> 1. Help better understanding the device. I mean, why should a TTY
>>> UART driver be aware of the McASP or the PRU.
>>> 2. In case of a bug in the API layer or McASP, the driver need not
>>> be touched, thus improve maintainability.
>>> 3. If we need to port it to another Linux version, just editing the
>>> driver file should suffice, this will reduce bugs while porting.
>>
>> If your code is in the kernel tree, you do not need to ever port it to a
>> new version, as it will happen automatically as new kernels are
>> released, so this really isn't anything to worry about.
>>
>>> To me, combining all of these into a single file only creates a
>>> mess. This is the reason I had separated them into different files!!
>>> I don't understand why should it be better to have all of these into
>>> a single file.
>>
>> As Alan stated, just use 3 files in the directory with the other
>> drivers, you don't need a subdir for something small like this.
>>
>> thanks,
>>
>> greg k-h
> 

From pratheesh at ti.com  Wed Feb 23 07:52:39 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Wed, 23 Feb 2011 19:22:39 +0530
Subject: [PATCH v3 0/2] Add PRUSS UIO driver support
Message-ID: <1298469161-7644-1-git-send-email-pratheesh@ti.com>

This patch series add support for PRUSS (Programmable Real-time Unit Sub
System) UIO driver in Texas Instruments DA850, AM18xx and OMAPL1-38 processors.
PRUSS is programmable RISC core which can be used to implement Soft IPs
(eg:- DMA, CAN, UART,SmartCard) and Industrial communications data link layers
(eg:- PROFIBUS). UIO driver exposes PRUSS resources like memory and interrupts 
to user space application.PRUSS UIO application API can be used to control PRUs
 in PRUSS, setup PRU INTC, load firmware to PRUs and implement IPC between Host
 processor and PRUs. More information on PRUSS and UIO linux user space API 
available in the links below

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide

Pratheesh Gangadhar (2):
  PRUSS UIO driver support
  Defines DA850/AM18xx/OMAPL1-38 SOC resources used by PRUSS UIO driver

 arch/arm/mach-davinci/board-da850-evm.c    |    4 +
 arch/arm/mach-davinci/da850.c              |   35 +++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 +++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 drivers/uio/Kconfig                        |   17 ++
 drivers/uio/Makefile                       |    1 +
 drivers/uio/uio_pruss.c                    |  223 ++++++++++++++++++++++++++++
 7 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c


From pratheesh at ti.com  Wed Feb 23 07:52:41 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Wed, 23 Feb 2011 19:22:41 +0530
Subject: [PATCH v3 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used by
	PRUSS UIO driver
In-Reply-To: <1298469161-7644-2-git-send-email-pratheesh@ti.com>
References: <1298469161-7644-1-git-send-email-pratheesh@ti.com>
	<1298469161-7644-2-git-send-email-pratheesh@ti.com>
Message-ID: <1298469161-7644-3-git-send-email-pratheesh@ti.com>

This patch defines PRUSS, ECAP clocks, memory and IRQ resources
used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
DDR buffer to user space. PRUSS has 8 host event interrupt lines
mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
with shared memory can be used to implement IPC between ARM9 and
PRUSS.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c    |    4 ++
 arch/arm/mach-davinci/da850.c              |   35 +++++++++++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 4 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..bd85aa3 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
 		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
 				ret);
 
+	ret = da8xx_register_pruss();
+	if (ret)
+		pr_warning("da850_evm_init: pruss registration failed: %d\n",
+				ret);
 
 	ret = da8xx_register_watchdog();
 	if (ret)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..0096d4f 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
 	.flags		= ALWAYS_ENABLED,
 };
 
+static struct clk pruss_clk = {
+	.name		= "pruss",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_DMAX,
+	.flags		= ALWAYS_ENABLED,
+};
+
 static struct clk uart0_clk = {
 	.name		= "uart0",
 	.parent		= &pll0_sysclk2,
@@ -359,6 +366,30 @@ static struct clk usb20_clk = {
 	.gpsc		= 1,
 };
 
+static struct clk ecap0_clk = {
+	.name		= "ecap0",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap1_clk = {
+	.name		= "ecap1",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap2_clk = {
+	.name		= "ecap2",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -386,6 +417,7 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tptc1",	&tptc1_clk),
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
+	CLK(NULL,		"pruss",	&pruss_clk),
 	CLK(NULL,		"uart0",	&uart0_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
@@ -403,6 +435,9 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"aemif",	&aemif_clk),
 	CLK(NULL,		"usb11",	&usb11_clk),
 	CLK(NULL,		"usb20",	&usb20_clk),
+	CLK(NULL,		"ecap0",	&ecap0_clk),
+	CLK(NULL,		"ecap1",	&ecap1_clk),
+	CLK(NULL,		"ecap2",	&ecap2_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..4ea3d1f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+static struct resource pruss_resources[] = {
+	[0] = {
+		.start  = DA8XX_PRUSS_BASE,
+		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[1] = {
+		.start  = DA8XX_L3RAM_BASE,
+		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[2] = {
+		.start  = 0,
+		.end    = SZ_256K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+
+	[3] = {
+		.start  = IRQ_DA8XX_EVTOUT0,
+		.end    = IRQ_DA8XX_EVTOUT0,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[4] = {
+		.start  = IRQ_DA8XX_EVTOUT1,
+		.end    = IRQ_DA8XX_EVTOUT1,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[5] = {
+		.start  = IRQ_DA8XX_EVTOUT2,
+		.end    = IRQ_DA8XX_EVTOUT2,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[6] = {
+		.start  = IRQ_DA8XX_EVTOUT3,
+		.end    = IRQ_DA8XX_EVTOUT3,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[7] = {
+		.start  = IRQ_DA8XX_EVTOUT4,
+		.end    = IRQ_DA8XX_EVTOUT4,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[8] = {
+		.start  = IRQ_DA8XX_EVTOUT5,
+		.end    = IRQ_DA8XX_EVTOUT5,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[9] = {
+		.start  = IRQ_DA8XX_EVTOUT6,
+		.end    = IRQ_DA8XX_EVTOUT6,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[10] = {
+		.start  = IRQ_DA8XX_EVTOUT7,
+		.end    = IRQ_DA8XX_EVTOUT7,
+		.flags  = IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device pruss_device = {
+	.name			= "pruss",
+	.id			= 0,
+	.num_resources		= ARRAY_SIZE(pruss_resources),
+	.resource		= pruss_resources,
+	.dev	 =	{
+		.coherent_dma_mask = 0xffffffff,
+	}
+};
+
+int __init da8xx_register_pruss()
+{
+	return platform_device_register(&pruss_device);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..3ed6ee0 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -60,6 +60,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_PLL0_BASE		0x01c11000
 #define DA8XX_TIMER64P0_BASE	0x01c20000
 #define DA8XX_TIMER64P1_BASE	0x01c21000
+#define DA8XX_PRUSS_BASE	0x01c30000
 #define DA8XX_GPIO_BASE		0x01e26000
 #define DA8XX_PSC1_BASE		0x01e27000
 #define DA8XX_LCD_CNTRL_BASE	0x01e13000
@@ -68,6 +69,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CS2_BASE	0x60000000
 #define DA8XX_AEMIF_CS3_BASE	0x62000000
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
+#define DA8XX_L3RAM_BASE	0x80000000
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
 
@@ -90,6 +92,7 @@ int da850_register_cpufreq(char *async_clk);
 int da8xx_register_cpuidle(void);
 void __iomem * __init da8xx_get_mem_ctlr(void);
 int da850_register_pm(struct platform_device *pdev);
+int da8xx_register_pruss(void);
 
 extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
-- 
1.6.0.6


From pratheesh at ti.com  Wed Feb 23 07:52:40 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Wed, 23 Feb 2011 19:22:40 +0530
Subject: [PATCH v3 1/2] PRUSS UIO driver support
In-Reply-To: <1298469161-7644-1-git-send-email-pratheesh@ti.com>
References: <1298469161-7644-1-git-send-email-pratheesh@ti.com>
Message-ID: <1298469161-7644-2-git-send-email-pratheesh@ti.com>

This patch implements PRUSS (Programmable Real-time Unit Sub System)
UIO driver which exports SOC resources associated with PRUSS like
I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
processors which is efficient in performing embedded tasks that
require manipulation of packed memory mapped data structures and
efficient in handling system events that have tight real time
constraints. This driver is currently supported on Texas Instruments
DA850, AM18xx and OMAPL1-38 devices.
For example, PRUSS runs firmware for real-time critical industrial
communication data link layer and communicates with application stack
running in user space via shared memory and IRQs.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
---
 drivers/uio/Kconfig     |   17 ++++
 drivers/uio/Makefile    |    1 +
 drivers/uio/uio_pruss.c |  223 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 241 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index bb44079..6f3ea9b 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -94,4 +94,21 @@ config UIO_NETX
 	  To compile this driver as a module, choose M here; the module
 	  will be called uio_netx.
 
+config UIO_PRUSS
+	tristate "Texas Instruments PRUSS driver"
+	depends on ARCH_DAVINCI_DA850
+	help
+	  PRUSS driver for OMAPL138/DA850/AM18XX devices
+	  PRUSS driver requires user space components, examples and user space
+	  driver is available from below SVN repo - you may use anonymous login
+
+	  https://gforge.ti.com/gf/project/pru_sw/
+
+	  More info on API is available at below wiki
+
+	  http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called uio_pruss.
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..d4dd9a5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC)	+= uio_aec.o
 obj-$(CONFIG_UIO_SERCOS3)	+= uio_sercos3.o
 obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
+obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
new file mode 100644
index 0000000..f2b2f4b
--- /dev/null
+++ b/drivers/uio/uio_pruss.c
@@ -0,0 +1,223 @@
+/*
+ * Programmable Real-Time Unit Sub System (PRUSS) UIO driver (uio_pruss)
+ *
+ * This driver exports PRUSS host event out interrupts and PRUSS, L3 RAM,
+ * and DDR RAM to user space for applications interacting with PRUSS firmware
+ *
+ * Copyright (C) 2010-11 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 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/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+
+#define DRV_NAME "pruss"
+#define DRV_VERSION "0.50"
+
+/*
+ * Host event IRQ numbers from PRUSS - PRUSS can generate upto 8 interrupt
+ * events to AINTC of ARM host processor - which can be used for IPC b/w PRUSS
+ * firmware and user space application, async notification from PRU firmware
+ * to user space application
+ * 3	PRU_EVTOUT0
+ * 4	PRU_EVTOUT1
+ * 5	PRU_EVTOUT2
+ * 6	PRU_EVTOUT3
+ * 7	PRU_EVTOUT4
+ * 8	PRU_EVTOUT5
+ * 9	PRU_EVTOUT6
+ * 10	PRU_EVTOUT7
+*/
+
+#define MAX_PRUSS_EVTOUT_INSTANCE	8
+
+#define	PINTC_HIPIR			0x4900
+#define	PINTC_HIPIR_NO_PEND_MASK	0x80000000
+#define	PINTC_HIER			0x5500
+
+struct clk *pruss_clk;
+struct uio_info *info;
+void *ddr_virt_addr = NULL, *prussio_virt_addr = NULL;
+dma_addr_t ddr_phy_addr;
+
+static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
+{
+	void __iomem *base = dev_info->mem[0].internal_addr;
+	void __iomem *intren_reg = base + PINTC_HIER;
+	void __iomem *intrstat_reg = base + PINTC_HIPIR + ((irq - 1) << 2);
+	int intren_regval = ioread32(intren_reg), intr_mask = (1 << (irq - 1));
+
+	/* Is interrupt enabled and active ? */
+	if (!(intren_regval & intr_mask)
+	    && (ioread32(intrstat_reg) & PINTC_HIPIR_NO_PEND_MASK))
+		return IRQ_NONE;
+
+	/* Disable interrupt */
+	iowrite32((intren_regval & ~intr_mask), intren_reg);
+	return IRQ_HANDLED;
+}
+
+static void pruss_cleanup(struct platform_device *dev, struct uio_info *info)
+{
+	int count;
+	struct uio_info *p;
+
+	for (count = 0, p = info; count < MAX_PRUSS_EVTOUT_INSTANCE;
+	     count++, p++) {
+		uio_unregister_device(p);
+		kfree(p->name);
+	}
+	iounmap(prussio_virt_addr);
+	dma_free_coherent(&dev->dev, info[0].mem[2].size,
+			  info[0].mem[2].internal_addr, info[0].mem[2].addr);
+
+	kfree(info);
+	clk_put(pruss_clk);
+}
+
+static int __devinit pruss_probe(struct platform_device *dev)
+{
+	int ret = -ENODEV, count = 0;
+	struct resource *regs_prussio, *regs_l3ram, *regs_ddr;
+	struct uio_info *p;
+
+	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVTOUT_INSTANCE,
+		       GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+
+	/* Power on PRU in case its not done as part of boot-loader */
+	pruss_clk = clk_get(&dev->dev, "pruss");
+	if (IS_ERR(pruss_clk)) {
+		dev_err(&dev->dev, "Failed to get clock\n");
+		ret = PTR_ERR(pruss_clk);
+		return ret;
+	} else {
+		clk_enable(pruss_clk);
+	}
+
+	regs_prussio = platform_get_resource(dev, IORESOURCE_MEM, 0);
+	if (!regs_prussio) {
+		dev_err(&dev->dev, "No PRUSS I/O resource specified\n");
+		goto out_free;
+	}
+
+	regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
+	if (!regs_l3ram) {
+		dev_err(&dev->dev, "No L3 RAM resource specified\n");
+		goto out_free;
+	}
+
+	regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
+	if (!regs_ddr) {
+		dev_err(&dev->dev, "No External RAM resource specified\n");
+		goto out_free;
+	}
+
+	if (!regs_prussio->start || !regs_l3ram->start) {
+		dev_err(&dev->dev, "Invalid memory resource\n");
+		goto out_free;
+	}
+
+	ddr_virt_addr =
+	    dma_alloc_coherent(&dev->dev, regs_ddr->end - regs_ddr->start + 1,
+			       &ddr_phy_addr, GFP_KERNEL | GFP_DMA);
+	if (!ddr_virt_addr) {
+		dev_err(&dev->dev, "Could not allocate external memory\n");
+		goto out_free;
+	}
+
+	prussio_virt_addr =
+	    ioremap(regs_prussio->start,
+		    regs_prussio->end - regs_prussio->start + 1);
+	if (prussio_virt_addr) {
+		dev_err(&dev->dev, "Can't remap PRUSS I/O  address range\n");
+		goto out_free;
+	}
+
+	for (count = 0, p = info; count < MAX_PRUSS_EVTOUT_INSTANCE;
+	     count++, p++) {
+		p->mem[0].internal_addr = prussio_virt_addr;
+		p->mem[0].addr = regs_prussio->start;
+		p->mem[0].size = regs_prussio->end - regs_prussio->start + 1;
+		p->mem[0].memtype = UIO_MEM_PHYS;
+
+		p->mem[1].addr = regs_l3ram->start;
+		p->mem[1].size = regs_l3ram->end - regs_l3ram->start + 1;
+		p->mem[1].memtype = UIO_MEM_PHYS;
+
+		p->mem[2].internal_addr = ddr_virt_addr;
+		p->mem[2].addr = ddr_phy_addr;
+		p->mem[2].size = regs_ddr->end - regs_ddr->start + 1;
+		p->mem[2].memtype = UIO_MEM_PHYS;
+
+		p->name = kasprintf(GFP_KERNEL, "pruss_evt%d", count);
+		p->version = "0.50";
+
+		/* Register PRUSS IRQ lines */
+		p->irq = IRQ_DA8XX_EVTOUT0 + count;
+		p->handler = pruss_handler;
+
+		ret = uio_register_device(&dev->dev, p);
+
+		if (ret < 0)
+			goto out_free;
+	}
+
+	platform_set_drvdata(dev, info);
+	return 0;
+
+out_free:
+	pruss_cleanup(dev, info);
+	return ret;
+}
+
+static int __devexit pruss_remove(struct platform_device *dev)
+{
+	struct uio_info *info = platform_get_drvdata(dev);
+
+	pruss_cleanup(dev, info);
+	platform_set_drvdata(dev, NULL);
+	return 0;
+}
+
+static struct platform_driver pruss_driver = {
+	.probe = pruss_probe,
+	.remove = __devexit_p(pruss_remove),
+	.driver = {
+		   .name = DRV_NAME,
+		   .owner = THIS_MODULE,
+		   },
+};
+
+static int __init pruss_init_module(void)
+{
+	return platform_driver_register(&pruss_driver);
+}
+
+module_init(pruss_init_module);
+
+static void __exit pruss_exit_module(void)
+{
+	platform_driver_unregister(&pruss_driver);
+}
+
+module_exit(pruss_exit_module);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Amit Chatterjee <amit.chatterjee at ti.com>");
+MODULE_AUTHOR("Pratheesh Gangadhar <pratheesh at ti.com>");
-- 
1.6.0.6


From schen at mvista.com  Wed Feb 23 08:18:10 2011
From: schen at mvista.com (Steve Chen)
Date: Wed, 23 Feb 2011 08:18:10 -0600
Subject: encodedecode demo audio-video
In-Reply-To: <AANLkTimVEn-i0bk8MjL07u+-OVi-YQrHHmHN12NgAtV1@mail.gmail.com>
References: <AANLkTimVEn-i0bk8MjL07u+-OVi-YQrHHmHN12NgAtV1@mail.gmail.com>
Message-ID: <AANLkTikGhrWv-JP5a=k9e1VkP6PB0KfcVuukkmo9QrPE@mail.gmail.com>

On Tue, Feb 22, 2011 at 9:38 PM, Aditya Barawkar
<adityabarawkar at gmail.com> wrote:
> hi,
> ?I am using a dm6446 EVM.
> ?I use the DVSDK1.2.
>
> I have the demos encodedecode demo running.
> But now i want that the audio should also be encoded and
> decoded.?Currently?the encode decode demo supports only h.264 codec (after
> googling i found dat it is a video only codec....no audio)
> How can i make changes to the encodedecode demo to make the demo running for
> audio??
>
>
> My final aim is to develop an OSD application using embedded Qt, so the Qt
> windows is on the OSD layer and the video input is being displayed in the
> video window, with the audio component of it!
> i think modifying the encodedecode demo can help(open for comment).
>

Gstreamer may be what you are looking for.  Take a look at
https://gstreamer.ti.com/gf/project/gstreamer_ti

Regards,

Steve

From nsekhar at ti.com  Wed Feb 23 08:50:27 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 23 Feb 2011 20:20:27 +0530
Subject: [PATCH v3 7/9] davinci: add spi devices support for
	MityDSP-L138/MityARM-1808 platform
In-Reply-To: <1298381824-7723-8-git-send-email-michael.williamson@criticallink.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
	<1298381824-7723-8-git-send-email-michael.williamson@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE4914B@dbde02.ent.ti.com>

Hi Mike,

On Tue, Feb 22, 2011 at 19:07:02, Michael Williamson wrote:

> +static void __init mityomapl138_init_spi1(struct spi_board_info *info,
> +					  unsigned len)
> +{
> +	int ret;
> +
> +	ret = spi_register_board_info(info, len);
> +	if (ret)
> +		pr_warning("%s: failed to register board info : %d\n",
> +				__func__, ret);
> +
> +	da8xx_spi_pdata[1].num_chipselect = len;
> +
> +	ret = da8xx_register_spi(1);
> +	if (ret)
> +		pr_warning("%s: failed to register spi 1 device : %d\n",
> +				__func__, ret);
> +}

I missed this previously. We seem to be adding this boilerplate
evm init function for every board. It will be worthwhile to
modify the da8xx_register_spi() function to take in the info and
num_chipselect too. The same function can then be called by each
evm.

Sorry about trickling in the comments - this should be the last
one ;) I have added the first five patches of the series to the
branch here:

http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/next-for-kevin

You can rebase to this branch so you will have to spin only the
modified patches again.

Thanks,
Sekhar


From michael.williamson at criticallink.com  Wed Feb 23 08:57:40 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 23 Feb 2011 09:57:40 -0500
Subject: [PATCH v3 7/9] davinci: add spi devices support for
	MityDSP-L138/MityARM-1808 platform
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BE4914B@dbde02.ent.ti.com>
References: <1298381824-7723-1-git-send-email-michael.williamson@criticallink.com>
	<1298381824-7723-8-git-send-email-michael.williamson@criticallink.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BE4914B@dbde02.ent.ti.com>
Message-ID: <4D652064.3020809@criticallink.com>

On 2/23/2011 9:50 AM, Nori, Sekhar wrote:

> Hi Mike,
> 
> On Tue, Feb 22, 2011 at 19:07:02, Michael Williamson wrote:
> 
>> +static void __init mityomapl138_init_spi1(struct spi_board_info *info,
>> +					  unsigned len)
>> +{
>> +	int ret;
>> +
>> +	ret = spi_register_board_info(info, len);
>> +	if (ret)
>> +		pr_warning("%s: failed to register board info : %d\n",
>> +				__func__, ret);
>> +
>> +	da8xx_spi_pdata[1].num_chipselect = len;
>> +
>> +	ret = da8xx_register_spi(1);
>> +	if (ret)
>> +		pr_warning("%s: failed to register spi 1 device : %d\n",
>> +				__func__, ret);
>> +}
> 
> I missed this previously. We seem to be adding this boilerplate
> evm init function for every board. It will be worthwhile to
> modify the da8xx_register_spi() function to take in the info and
> num_chipselect too. The same function can then be called by each
> evm.
> 
> Sorry about trickling in the comments - this should be the last
> one ;) I have added the first five patches of the series to the
> branch here:
> 

> http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/next-for-kevin
> 
> You can rebase to this branch so you will have to spin only the
> modified patches again.
> 


My arm's getting a bit tired from the polishing...  I'll resend against
your branch the merged routine.

> Thanks,
> Sekhar
> 



From nsekhar at ti.com  Wed Feb 23 09:24:52 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 23 Feb 2011 20:54:52 +0530
Subject: [PATCH 1/1] da830: macro rename DA8XX_LPSC0_DMAX to
	DA8XX_LPSC0_PRUSS.
In-Reply-To: <1297433905-27925-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297433905-27925-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE4916D@dbde02.ent.ti.com>

Hi Subhasish,

Please add a "davinci: " prefix to the subject line of
mach-davinci patches. The patch is not really specific
to DA830.

On Fri, Feb 11, 2011 at 19:48:25, Subhasish Ghosh wrote:
> The PRUSS was named as DMAX on da830 platform.
> This patch resolves the naming conflict by replacing the macro
> DA8XX_LPSC0_DMAX with DA8XX_LPSC0_PRUSS.

This description is inaccurate. Firstly, there is no naming
conflict. DMAX is an internal name for the module which is
known as PRUSS in TI public documentation. This patch just
gets the code in sync with TI documentation.

Can you please update the subject and re-spin this patch?

Thanks,
Sekhar

> 
> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> ---
>  arch/arm/mach-davinci/da830.c            |    2 +-
>  arch/arm/mach-davinci/include/mach/psc.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
> index ec23ab4..0577a5d 100644
> --- a/arch/arm/mach-davinci/da830.c
> +++ b/arch/arm/mach-davinci/da830.c
> @@ -148,7 +148,7 @@ static struct clk scr2_ss_clk = {
>  static struct clk dmax_clk = {
>  	.name		= "dmax",
>  	.parent		= &pll0_sysclk2,
> -	.lpsc		= DA8XX_LPSC0_DMAX,
> +	.lpsc		= DA8XX_LPSC0_PRUSS,
>  	.flags		= ALWAYS_ENABLED,
>  };
>  
> diff --git a/arch/arm/mach-davinci/include/mach/psc.h b/arch/arm/mach-davinci/include/mach/psc.h
> index 62b0858..a47e6f2 100644
> --- a/arch/arm/mach-davinci/include/mach/psc.h
> +++ b/arch/arm/mach-davinci/include/mach/psc.h
> @@ -150,7 +150,7 @@
>  #define DA8XX_LPSC0_SCR0_SS		10
>  #define DA8XX_LPSC0_SCR1_SS		11
>  #define DA8XX_LPSC0_SCR2_SS		12
> -#define DA8XX_LPSC0_DMAX		13
> +#define DA8XX_LPSC0_PRUSS		13
>  #define DA8XX_LPSC0_ARM			14
>  #define DA8XX_LPSC0_GEM			15
>  
> -- 
> 1.7.2.3
> 
> 


From nsekhar at ti.com  Wed Feb 23 09:30:29 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 23 Feb 2011 21:00:29 +0530
Subject: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.
In-Reply-To: <1297434088-27995-1-git-send-email-subhasish@mistralsolutions.com>
References: <1297434088-27995-1-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE49175@dbde02.ent.ti.com>

Hi Subhasish,

On Fri, Feb 11, 2011 at 19:51:28, Subhasish Ghosh wrote:
> This patch modifies the sram allocator to allocate memory
> from the DA8XX shared RAM.

It will be nice to know if you tried suspend-to-RAM
after this change and found it to be working.

Thanks,
Sekhar

> 
> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> ---
>  arch/arm/mach-davinci/da850.c              |    6 +++---
>  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3443d97..8a4de97 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -711,7 +711,7 @@ static struct map_desc da850_io_desc[] = {
>  	},
>  	{
>  		.virtual	= SRAM_VIRT,
> -		.pfn		= __phys_to_pfn(DA8XX_ARM_RAM_BASE),
> +		.pfn		= __phys_to_pfn(DA8XX_SHARED_RAM_BASE),
>  		.length		= SZ_8K,
>  		.type		= MT_DEVICE
>  	},
> @@ -1083,8 +1083,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
>  	.gpio_irq		= IRQ_DA8XX_GPIO0,
>  	.serial_dev		= &da8xx_serial_device,
>  	.emac_pdata		= &da8xx_emac_pdata,
> -	.sram_dma		= DA8XX_ARM_RAM_BASE,
> -	.sram_len		= SZ_8K,
> +	.sram_dma		= DA8XX_SHARED_RAM_BASE,
> +	.sram_len		= SZ_128K,
>  	.reset_device		= &da8xx_wdt_device,
>  };
>  
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index cfcb223..c3c3339 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -70,6 +70,7 @@ extern unsigned int da850_max_speed;
>  #define DA8XX_AEMIF_CTL_BASE	0x68000000
>  #define DA8XX_DDR2_CTL_BASE	0xb0000000
>  #define DA8XX_ARM_RAM_BASE	0xffff0000
> +#define DA8XX_SHARED_RAM_BASE	0x80000000
>  
>  void __init da830_init(void);
>  void __init da850_init(void);
> -- 
> 1.7.2.3
> 
> 


From gregkh at suse.de  Wed Feb 23 12:21:28 2011
From: gregkh at suse.de (Greg KH)
Date: Wed, 23 Feb 2011 10:21:28 -0800
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <6E7634AAF813458489E0444DF71260CF@subhasishg>
References: <6E7634AAF813458489E0444DF71260CF@subhasishg>
Message-ID: <20110223182128.GC30517@suse.de>

On Wed, Feb 23, 2011 at 07:05:53PM +0530, Subhasish Ghosh wrote:
> Hello,
> 
> Anything regarding this.

What is with the impatience?  We do sleep around here, sometimes...

thanks,

greg k-h

From gregkh at suse.de  Wed Feb 23 12:20:53 2011
From: gregkh at suse.de (Greg KH)
Date: Wed, 23 Feb 2011 10:20:53 -0800
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <86364E209B534BF1ADB2764227483070@subhasishg>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<20110218143500.23b3044b@lxorguk.ukuu.org.uk>
	<alpine.LFD.2.00.1102181917520.2701@localhost6.localdomain6>
	<201102181951.32631.arnd@arndb.de>
	<9826735BD9DD48A599C595D28C4A05F0@subhasishg>
	<20110222143704.GA978@suse.de>
	<86364E209B534BF1ADB2764227483070@subhasishg>
Message-ID: <20110223182053.GB30517@suse.de>

On Wed, Feb 23, 2011 at 11:00:25AM +0530, Subhasish Ghosh wrote:
> I could not follow the recommendations clearly.
> This is just to clarify.
> 
> Currently, I have the following files for the suart implementation:
> 
> drivers/tty/serial/da8xx_pruss/pruss_suart_api.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_err.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_board.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h
> 
> drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
> drivers/tty/serial/da8xx_pruss/pruss_suart.c
> drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c
> 
> Of these, I will be removing pruss_suart_err.h as part of the Linux
> error code cleanup.
> But, I need to keep at least  pruss_suart_board.h as a separate
> file, as this defines
> configurations which will be often modified by users, I don't want
> to mix it with other files.

Why would a .h file ever need to be "modified by users"?  That sounds
wrong to me.

> Should I combine rest of the headers into a single file ?

Yes, why would they need to be separate?

> and keep the other three .c files under "drivers/tty/serial/" and
> remove the da8xx_pruss directory altogether.

Yes.

thanks,

greg k-h

From michael.williamson at criticallink.com  Wed Feb 23 12:44:07 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 23 Feb 2011 13:44:07 -0500
Subject: [PATCH v4 0/4] davinci: add spi devices support for da8xx based
	platforms
Message-ID: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>

This patch series adds SPI bus support and devices for the MityDSP-L138,
MityARM-1808, da850 evm, and da830 evm platforms.  This patch series is 
against the staging tree at [1] as per Sekhar's instructions.

This series has been tested on the MityDSP-L138 platform.

[1] http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/next-for-kevin

---
changes since v3:
   -- first 5 patches of series are incorporated in [1] and not included 
      in this submission
   -- refactored common spi registration code into da8xx_register_spi
      routine, reducing effective lines of code for multiple platform
      support.

Michael Williamson (2):
  davinci: da8xx: add spi resources and registration routine
  davinci: add spi devices support for MityDSP-L138/MityARM-1808
    platform

Sekhar Nori (2):
  davinci: add spi devices support for da850/omap-l138/am18x evm
  davinci: add spi devices support for da830/omap-l137/am17x evm

 arch/arm/mach-davinci/board-da830-evm.c    |   67 ++++++++++++++++++
 arch/arm/mach-davinci/board-da850-evm.c    |   73 +++++++++++++++++++
 arch/arm/mach-davinci/board-mityomapl138.c |   84 ++++++++++++++++++++++
 arch/arm/mach-davinci/devices-da8xx.c      |  104 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    4 +
 5 files changed, 332 insertions(+), 0 deletions(-)


From michael.williamson at criticallink.com  Wed Feb 23 12:44:08 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 23 Feb 2011 13:44:08 -0500
Subject: [PATCH v4 1/4] davinci: da8xx: add spi resources and registration
	routine
In-Reply-To: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
References: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298486651-18882-2-git-send-email-michael.williamson@criticallink.com>

Add IO resource structures, platform data, and a registration
routine in order to support spi device on DA850/OMAP-L138/AM18x
and DA830/OMAP-L137/AM17x platforms.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/devices-da8xx.c      |  104 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    4 +
 2 files changed, 108 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 119d46e..625d4b6 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -38,14 +38,20 @@
 #define DA8XX_EMAC_MDIO_BASE		0x01e24000
 #define DA8XX_GPIO_BASE			0x01e26000
 #define DA8XX_I2C1_BASE			0x01e28000
+#define DA8XX_SPI0_BASE			0x01c41000
+#define DA8XX_SPI1_BASE			0x01f0e000
 
 #define DA8XX_EMAC_CTRL_REG_OFFSET	0x3000
 #define DA8XX_EMAC_MOD_REG_OFFSET	0x2000
 #define DA8XX_EMAC_RAM_OFFSET		0x0000
 #define DA8XX_EMAC_CTRL_RAM_SIZE	SZ_8K
 
+#define DA8XX_DMA_SPI0_RX	EDMA_CTLR_CHAN(0, 14)
+#define DA8XX_DMA_SPI0_TX	EDMA_CTLR_CHAN(0, 15)
 #define DA8XX_DMA_MMCSD0_RX	EDMA_CTLR_CHAN(0, 16)
 #define DA8XX_DMA_MMCSD0_TX	EDMA_CTLR_CHAN(0, 17)
+#define DA8XX_DMA_SPI1_RX	EDMA_CTLR_CHAN(0, 18)
+#define DA8XX_DMA_SPI1_TX	EDMA_CTLR_CHAN(0, 19)
 #define DA850_DMA_MMCSD1_RX	EDMA_CTLR_CHAN(1, 28)
 #define DA850_DMA_MMCSD1_TX	EDMA_CTLR_CHAN(1, 29)
 
@@ -730,3 +736,101 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+
+static struct resource da8xx_spi0_resources[] = {
+	[0] = {
+		.start	= DA8XX_SPI0_BASE,
+		.end	= DA8XX_SPI0_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_DA8XX_SPINT0,
+		.end	= IRQ_DA8XX_SPINT0,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		.start	= DA8XX_DMA_SPI0_RX,
+		.end	= DA8XX_DMA_SPI0_RX,
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		.start	= DA8XX_DMA_SPI0_TX,
+		.end	= DA8XX_DMA_SPI0_TX,
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+static struct resource da8xx_spi1_resources[] = {
+	[0] = {
+		.start	= DA8XX_SPI1_BASE,
+		.end	= DA8XX_SPI1_BASE + SZ_4K - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= IRQ_DA8XX_SPINT1,
+		.end	= IRQ_DA8XX_SPINT1,
+		.flags	= IORESOURCE_IRQ,
+	},
+	[2] = {
+		.start	= DA8XX_DMA_SPI1_RX,
+		.end	= DA8XX_DMA_SPI1_RX,
+		.flags	= IORESOURCE_DMA,
+	},
+	[3] = {
+		.start	= DA8XX_DMA_SPI1_TX,
+		.end	= DA8XX_DMA_SPI1_TX,
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+struct davinci_spi_platform_data da8xx_spi_pdata[] = {
+	[0] = {
+		.version	= SPI_VERSION_2,
+		.intr_line	= 1,
+		.dma_event_q	= EVENTQ_0,
+	},
+	[1] = {
+		.version	= SPI_VERSION_2,
+		.intr_line	= 1,
+		.dma_event_q	= EVENTQ_0,
+	},
+};
+
+static struct platform_device da8xx_spi_device[] = {
+	[0] = {
+		.name		= "spi_davinci",
+		.id		= 0,
+		.num_resources	= ARRAY_SIZE(da8xx_spi0_resources),
+		.resource	= da8xx_spi0_resources,
+		.dev		= {
+			.platform_data = &da8xx_spi_pdata[0],
+		},
+	},
+	[1] = {
+		.name		= "spi_davinci",
+		.id		= 1,
+		.num_resources	= ARRAY_SIZE(da8xx_spi1_resources),
+		.resource	= da8xx_spi1_resources,
+		.dev		= {
+			.platform_data = &da8xx_spi_pdata[1],
+		},
+	},
+};
+
+int __init da8xx_register_spi(int instance, struct spi_board_info *info,
+			      unsigned len)
+{
+	int ret;
+
+	if (instance < 0 || instance > 1)
+		return -EINVAL;
+
+	ret = spi_register_board_info(info, len);
+	if (ret)
+		pr_warning("%s: failed to register board info for spi %d :"
+			   " %d\n", __func__, instance, ret);
+
+	da8xx_spi_pdata[instance].num_chipselect = len;
+
+	return platform_device_register(&da8xx_spi_device[instance]);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..e4fc1af 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -15,6 +15,7 @@
 
 #include <linux/platform_device.h>
 #include <linux/davinci_emac.h>
+#include <linux/spi/spi.h>
 
 #include <mach/serial.h>
 #include <mach/edma.h>
@@ -23,6 +24,7 @@
 #include <mach/mmc.h>
 #include <mach/usb.h>
 #include <mach/pm.h>
+#include <mach/spi.h>
 
 extern void __iomem *da8xx_syscfg0_base;
 extern void __iomem *da8xx_syscfg1_base;
@@ -77,6 +79,7 @@ void __init da850_init(void);
 int da830_register_edma(struct edma_rsv_info *rsv);
 int da850_register_edma(struct edma_rsv_info *rsv[2]);
 int da8xx_register_i2c(int instance, struct davinci_i2c_platform_data *pdata);
+int da8xx_register_spi(int instance, struct spi_board_info *info, unsigned len);
 int da8xx_register_watchdog(void);
 int da8xx_register_usb20(unsigned mA, unsigned potpgt);
 int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
@@ -95,6 +98,7 @@ extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
+extern struct davinci_spi_platform_data da8xx_spi_pdata[];
 
 extern struct platform_device da8xx_wdt_device;
 
-- 
1.7.0.4


From michael.williamson at criticallink.com  Wed Feb 23 12:44:09 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 23 Feb 2011 13:44:09 -0500
Subject: [PATCH v4 2/4] davinci: add spi devices support for
	MityDSP-L138/MityARM-1808 platform
In-Reply-To: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
References: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298486651-18882-3-git-send-email-michael.williamson@criticallink.com>

This patch adds support for accessing the on board SPI NOR FLASH
device for MityDSP-L138 and MityARM-1808 SoMs.

Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
Tested-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-mityomapl138.c |   84 ++++++++++++++++++++++++++++
 1 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 0ea5932..2aa79c5 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -17,6 +17,8 @@
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
 #include <linux/etherdevice.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -25,6 +27,7 @@
 #include <mach/da8xx.h>
 #include <mach/nand.h>
 #include <mach/mux.h>
+#include <mach/spi.h>
 
 #define MITYOMAPL138_PHY_ID		"0:03"
 
@@ -294,6 +297,82 @@ static int __init pmic_tps65023_init(void)
 }
 
 /*
+ * SPI Devices:
+ *	SPI1_CS0: 8M Flash ST-M25P64-VME6G
+ */
+static struct mtd_partition spi_flash_partitions[] = {
+	[0] = {
+		.name		= "ubl",
+		.offset		= 0,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[1] = {
+		.name		= "u-boot",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_512K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[2] = {
+		.name		= "u-boot-env",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[3] = {
+		.name		= "periph-config",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= MTD_WRITEABLE,
+	},
+	[4] = {
+		.name		= "reserved",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_256K + SZ_64K,
+	},
+	[5] = {
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M + SZ_1M,
+	},
+	[6] = {
+		.name		= "fpga",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M,
+	},
+	[7] = {
+		.name		= "spare",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+	},
+};
+
+static struct flash_platform_data mityomapl138_spi_flash_data = {
+	.name		= "m25p80",
+	.parts		= spi_flash_partitions,
+	.nr_parts	= ARRAY_SIZE(spi_flash_partitions),
+	.type		= "m24p64",
+};
+
+static struct davinci_spi_config spi_eprom_config = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info mityomapl138_spi_flash_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &mityomapl138_spi_flash_data,
+		.controller_data	= &spi_eprom_config,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 1,
+		.chip_select		= 0,
+	},
+};
+
+/*
  * MityDSP-L138 includes a 256 MByte large-page NAND flash
  * (128K blocks).
  */
@@ -448,6 +527,11 @@ static void __init mityomapl138_init(void)
 
 	mityomapl138_setup_nand();
 
+	ret = da8xx_register_spi(1, mityomapl138_spi_flash_info,
+			       ARRAY_SIZE(mityomapl138_spi_flash_info));
+	if (ret)
+		pr_warning("spi 1 registration failed: %d\n", ret);
+
 	mityomapl138_config_emac();
 
 	ret = da8xx_register_rtc();
-- 
1.7.0.4


From michael.williamson at criticallink.com  Wed Feb 23 12:44:10 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 23 Feb 2011 13:44:10 -0500
Subject: [PATCH v4 3/4] davinci: add spi devices support for
	da850/omap-l138/am18x evm
In-Reply-To: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
References: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298486651-18882-4-git-send-email-michael.williamson@criticallink.com>

From: Sekhar Nori <nsekhar at ti.com>

This patch adds the on-board SPI flash device to the
DA850/OMAP-L138/AM18x EVM. It also registers the SPI flash
device to the MTD subsystem.

Based on SPI flash device support for MityDSP-L138F platform.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da850_evm_spi1_pdata to devices-da8xx.c]
[michael.williamson at criticallink.com: moved da850evm_init_spi1 to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-da850-evm.c |   73 +++++++++++++++++++++++++++++++
 1 files changed, 73 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..0aef6b2 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,8 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/tps6507x.h>
 #include <linux/input/tps6507x-ts.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -38,6 +40,7 @@
 #include <mach/nand.h>
 #include <mach/mux.h>
 #include <mach/aemif.h>
+#include <mach/spi.h>
 
 #define DA850_EVM_PHY_ID		"0:00"
 #define DA850_LCD_PWR_PIN		GPIO_TO_PIN(2, 8)
@@ -48,6 +51,70 @@
 
 #define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
 
+static struct mtd_partition da850evm_spiflash_part[] = {
+	[0] = {
+		.name = "UBL",
+		.offset = 0,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[1] = {
+		.name = "U-Boot",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_512K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[2] = {
+		.name = "U-Boot-Env",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[3] = {
+		.name = "Kernel",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_2M + SZ_512K,
+		.mask_flags = 0,
+	},
+	[4] = {
+		.name = "Filesystem",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_4M,
+		.mask_flags = 0,
+	},
+	[5] = {
+		.name = "MAC-Address",
+		.offset = SZ_8M - SZ_64K,
+		.size = SZ_64K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+};
+
+static struct flash_platform_data da850evm_spiflash_data = {
+	.name		= "m25p80",
+	.parts		= da850evm_spiflash_part,
+	.nr_parts	= ARRAY_SIZE(da850evm_spiflash_part),
+	.type		= "m25p64",
+};
+
+static struct davinci_spi_config da850evm_spiflash_cfg = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info da850evm_spi_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &da850evm_spiflash_data,
+		.controller_data	= &da850evm_spiflash_cfg,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 1,
+		.chip_select		= 0,
+	},
+};
+
 static struct mtd_partition da850_evm_norflash_partition[] = {
 	{
 		.name           = "bootloaders + env",
@@ -1167,6 +1234,12 @@ static __init void da850_evm_init(void)
 	if (ret)
 		pr_warning("da850_evm_init: suspend registration failed: %d\n",
 				ret);
+
+	ret = da8xx_register_spi(1, da850evm_spi_info,
+				 ARRAY_SIZE(da850evm_spi_info));
+	if (ret)
+		pr_warning("da850_evm_init: spi 1 registration failed: %d\n",
+				ret);
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.0.4


From michael.williamson at criticallink.com  Wed Feb 23 12:44:11 2011
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Wed, 23 Feb 2011 13:44:11 -0500
Subject: [PATCH v4 4/4] davinci: add spi devices support for
	da830/omap-l137/am17x evm
In-Reply-To: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
References: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <1298486651-18882-5-git-send-email-michael.williamson@criticallink.com>

From: Sekhar Nori <nsekhar at ti.com>

This patch adds the on-board SPI flash device to the
DA830/OMAP-L137/AM17x EVM. It also registers the SPI flash
device to the MTD subsystem.

Based on SPI flash device support for MityDSP-L138F platform.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
[michael.williamson at criticallink.com: moved da830evm_spi0_pdata to devices-da8xx.c]
[michael.williamson at criticallink.com: moved da830evm_init_spi0 to devices-da8xx.c]
Signed-off-by: Michael Williamson <michael.williamson at criticallink.com>
---
 arch/arm/mach-davinci/board-da830-evm.c |   67 +++++++++++++++++++++++++++++++
 1 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index b52a3a1..8bc3701 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -20,6 +20,8 @@
 #include <linux/i2c/at24.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -30,6 +32,7 @@
 #include <mach/da8xx.h>
 #include <mach/usb.h>
 #include <mach/aemif.h>
+#include <mach/spi.h>
 
 #define DA830_EVM_PHY_ID		""
 /*
@@ -534,6 +537,64 @@ static struct edma_rsv_info da830_edma_rsv[] = {
 	},
 };
 
+static struct mtd_partition da830evm_spiflash_part[] = {
+	[0] = {
+		.name = "DSP-UBL",
+		.offset = 0,
+		.size = SZ_8K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[1] = {
+		.name = "ARM-UBL",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_16K + SZ_8K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[2] = {
+		.name = "U-Boot",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_256K - SZ_32K,
+		.mask_flags = MTD_WRITEABLE,
+	},
+	[3] = {
+		.name = "U-Boot-Environment",
+		.offset = MTDPART_OFS_APPEND,
+		.size = SZ_16K,
+		.mask_flags = 0,
+	},
+	[4] = {
+		.name = "Kernel",
+		.offset = MTDPART_OFS_APPEND,
+		.size = MTDPART_SIZ_FULL,
+		.mask_flags = 0,
+	},
+};
+
+static struct flash_platform_data da830evm_spiflash_data = {
+	.name		= "m25p80",
+	.parts		= da830evm_spiflash_part,
+	.nr_parts	= ARRAY_SIZE(da830evm_spiflash_part),
+	.type		= "w25x32",
+};
+
+static struct davinci_spi_config da830evm_spiflash_cfg = {
+	.io_type	= SPI_IO_TYPE_DMA,
+	.c2tdelay	= 8,
+	.t2cdelay	= 8,
+};
+
+static struct spi_board_info da830evm_spi_info[] = {
+	{
+		.modalias		= "m25p80",
+		.platform_data		= &da830evm_spiflash_data,
+		.controller_data	= &da830evm_spiflash_cfg,
+		.mode			= SPI_MODE_0,
+		.max_speed_hz		= 30000000,
+		.bus_num		= 0,
+		.chip_select		= 0,
+	},
+};
+
 static __init void da830_evm_init(void)
 {
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -590,6 +651,12 @@ static __init void da830_evm_init(void)
 	ret = da8xx_register_rtc();
 	if (ret)
 		pr_warning("da830_evm_init: rtc setup failed: %d\n", ret);
+
+	ret = da8xx_register_spi(0, da830evm_spi_info,
+				 ARRAY_SIZE(da830evm_spi_info));
+	if (ret)
+		pr_warning("da830_evm_init: spi 0 registration failed: %d\n",
+			   ret);
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
-- 
1.7.0.4


From henryzhang62 at yahoo.com  Wed Feb 23 13:01:28 2011
From: henryzhang62 at yahoo.com (hong zhang)
Date: Wed, 23 Feb 2011 11:01:28 -0800 (PST)
Subject: Is any utility available to open /dev/hdmi and record voice?
Message-ID: <15997.43133.qm@web161714.mail.bf1.yahoo.com>

List,

My Davinci EVM has HDMI with audio. TI81xx_hdmi.ko is loaded. I like to record voice from HDMI microphone.

"arecord hdmi-audio.mv" does not record anything from hdmi but from regular microphone line. 

Is any utility available to open /dev/hdmi and record voice? 

---henry


      

From sshtylyov at mvista.com  Wed Feb 23 14:49:49 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 23 Feb 2011 23:49:49 +0300
Subject: [PATCH v3 1/2] PRUSS UIO driver support
In-Reply-To: <alpine.LFD.2.00.1102232057260.2701@localhost6.localdomain6>
References: <1298469161-7644-1-git-send-email-pratheesh@ti.com>	<1298469161-7644-2-git-send-email-pratheesh@ti.com>
	<alpine.LFD.2.00.1102232057260.2701@localhost6.localdomain6>
Message-ID: <4D6572ED.9020805@mvista.com>

Hello.

On 23-02-2011 23:25, Thomas Gleixner wrote:

>> +	prussio_virt_addr =
>> +	    ioremap(regs_prussio->start,
>> +		    regs_prussio->end - regs_prussio->start + 1);

> Either make those variable names shorter or do:

>         len = regs_prussio->end - regs_prussio->start + 1;

    Or even:

	len = resource_size(regs_prussio);

>         prussio_virt_addr = ioremap(regs_prussio->start, len);

WBR, Sergei

From dipa at ti.com  Wed Feb 23 17:34:26 2011
From: dipa at ti.com (Rao, Dipa)
Date: Wed, 23 Feb 2011 17:34:26 -0600
Subject: Is any utility available to open /dev/hdmi and record voice?
In-Reply-To: <15997.43133.qm@web161714.mail.bf1.yahoo.com>
References: <15997.43133.qm@web161714.mail.bf1.yahoo.com>
Message-ID: <B321760590390941B64F0F8AB59ED250B39691EA@dlee01.ent.ti.com>

Hi Henry,

We have discussed this with your team  earlier. We do not have HDMI audio path supported today on the EVM.
This is in our software gaps document.

Rgds
-Dipa-

-----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 hong zhang
Sent: Wednesday, February 23, 2011 11:01 AM
To: davinci-linux-open-source at linux.davincidsp.com
Subject: Is any utility available to open /dev/hdmi and record voice?

List,

My Davinci EVM has HDMI with audio. TI81xx_hdmi.ko is loaded. I like to record voice from HDMI microphone.

"arecord hdmi-audio.mv" does not record anything from hdmi but from regular microphone line. 

Is any utility available to open /dev/hdmi and record voice? 

---henry


      
_______________________________________________
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 subhasish at mistralsolutions.com  Thu Feb 24 04:24:56 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Thu, 24 Feb 2011 15:54:56 +0530
Subject: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BE49175@dbde02.ent.ti.com>
References: <1297434088-27995-1-git-send-email-subhasish@mistralsolutions.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BE49175@dbde02.ent.ti.com>
Message-ID: <886E26C48DE446C3937D89ECF86030B2@subhasishg>

--------------------------------------------------
From: "Nori, Sekhar" <nsekhar at ti.com>
Sent: Wednesday, February 23, 2011 9:00 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>; 
<davinci-linux-open-source at linux.davincidsp.com>
Cc: <linux-arm-kernel at lists.infradead.org>; "Watkins, Melissa" 
<m-watkins at ti.com>; <sachi at mistralsolutions.com>; "Kevin Hilman" 
<khilman at deeprootsystems.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Michael Williamson" <michael.williamson at criticallink.com>; "Chemparathy, 
Cyril" <cyril at ti.com>; "Sergei Shtylyov" <sshtylyov at ru.mvista.com>; "open 
list" <linux-kernel at vger.kernel.org>
Subject: RE: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.

> Hi Subhasish,
>
> On Fri, Feb 11, 2011 at 19:51:28, Subhasish Ghosh wrote:
>> This patch modifies the sram allocator to allocate memory
>> from the DA8XX shared RAM.
>
> It will be nice to know if you tried suspend-to-RAM
> after this change and found it to be working.
>

SG -- My file system is currently mounted from MMC.
          Suspend to RAM seems to have bug with MMC.
           (http://processors.wiki.ti.com/index.php/OMAP-L1_Linux_Drivers_Usage#Suspend-to-RAM)
          I had tried NFS earlier, but I think there is some problem with 
NFS boot and udev with this kernel.
           So, currently I will not be able to do it, but will try if I get 
a chance.

> Thanks,
> Sekhar
>
>>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
>> ---
>>  arch/arm/mach-davinci/da850.c              |    6 +++---
>>  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/da850.c 
>> b/arch/arm/mach-davinci/da850.c
>> index 3443d97..8a4de97 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -711,7 +711,7 @@ static struct map_desc da850_io_desc[] = {
>>  },
>>  {
>>  .virtual = SRAM_VIRT,
>> - .pfn = __phys_to_pfn(DA8XX_ARM_RAM_BASE),
>> + .pfn = __phys_to_pfn(DA8XX_SHARED_RAM_BASE),
>>  .length = SZ_8K,
>>  .type = MT_DEVICE
>>  },
>> @@ -1083,8 +1083,8 @@ static struct davinci_soc_info 
>> davinci_soc_info_da850 = {
>>  .gpio_irq = IRQ_DA8XX_GPIO0,
>>  .serial_dev = &da8xx_serial_device,
>>  .emac_pdata = &da8xx_emac_pdata,
>> - .sram_dma = DA8XX_ARM_RAM_BASE,
>> - .sram_len = SZ_8K,
>> + .sram_dma = DA8XX_SHARED_RAM_BASE,
>> + .sram_len = SZ_128K,
>>  .reset_device = &da8xx_wdt_device,
>>  };
>>
>> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h 
>> b/arch/arm/mach-davinci/include/mach/da8xx.h
>> index cfcb223..c3c3339 100644
>> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
>> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
>> @@ -70,6 +70,7 @@ extern unsigned int da850_max_speed;
>>  #define DA8XX_AEMIF_CTL_BASE 0x68000000
>>  #define DA8XX_DDR2_CTL_BASE 0xb0000000
>>  #define DA8XX_ARM_RAM_BASE 0xffff0000
>> +#define DA8XX_SHARED_RAM_BASE 0x80000000
>>
>>  void __init da830_init(void);
>>  void __init da850_init(void);
>> -- 
>> 1.7.2.3
>>
>>
> 

From subhasish at mistralsolutions.com  Thu Feb 24 04:27:35 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Thu, 24 Feb 2011 15:57:35 +0530
Subject: [PATCH 1/1] da830: macro rename DA8XX_LPSC0_DMAX to
	DA8XX_LPSC0_PRUSS.
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BE4916D@dbde02.ent.ti.com>
References: <1297433905-27925-1-git-send-email-subhasish@mistralsolutions.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BE4916D@dbde02.ent.ti.com>
Message-ID: <B078763F059B415E9DD8D61AA14F9D5C@subhasishg>

> Hi Subhasish,
>
> Please add a "davinci: " prefix to the subject line of
> mach-davinci patches. The patch is not really specific
> to DA830.

SG -- OK, Will do

>
> On Fri, Feb 11, 2011 at 19:48:25, Subhasish Ghosh wrote:
>> The PRUSS was named as DMAX on da830 platform.
>> This patch resolves the naming conflict by replacing the macro
>> DA8XX_LPSC0_DMAX with DA8XX_LPSC0_PRUSS.
>
> This description is inaccurate. Firstly, there is no naming
> conflict. DMAX is an internal name for the module which is
> known as PRUSS in TI public documentation. This patch just
> gets the code in sync with TI documentation.
>
> Can you please update the subject and re-spin this patch?

SG - OK, Will do.


>
> Thanks,
> Sekhar
>
>>
>> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
>> ---
>>  arch/arm/mach-davinci/da830.c            |    2 +-
>>  arch/arm/mach-davinci/include/mach/psc.h |    2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/da830.c 
>> b/arch/arm/mach-davinci/da830.c
>> index ec23ab4..0577a5d 100644
>> --- a/arch/arm/mach-davinci/da830.c
>> +++ b/arch/arm/mach-davinci/da830.c
>> @@ -148,7 +148,7 @@ static struct clk scr2_ss_clk = {
>>  static struct clk dmax_clk = {
>>  .name = "dmax",
>>  .parent = &pll0_sysclk2,
>> - .lpsc = DA8XX_LPSC0_DMAX,
>> + .lpsc = DA8XX_LPSC0_PRUSS,
>>  .flags = ALWAYS_ENABLED,
>>  };
>>
>> diff --git a/arch/arm/mach-davinci/include/mach/psc.h 
>> b/arch/arm/mach-davinci/include/mach/psc.h
>> index 62b0858..a47e6f2 100644
>> --- a/arch/arm/mach-davinci/include/mach/psc.h
>> +++ b/arch/arm/mach-davinci/include/mach/psc.h
>> @@ -150,7 +150,7 @@
>>  #define DA8XX_LPSC0_SCR0_SS 10
>>  #define DA8XX_LPSC0_SCR1_SS 11
>>  #define DA8XX_LPSC0_SCR2_SS 12
>> -#define DA8XX_LPSC0_DMAX 13
>> +#define DA8XX_LPSC0_PRUSS 13
>>  #define DA8XX_LPSC0_ARM 14
>>  #define DA8XX_LPSC0_GEM 15
>>
>> -- 
>> 1.7.2.3
>>
>>
> 

From subhasish at mistralsolutions.com  Thu Feb 24 04:31:06 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Thu, 24 Feb 2011 16:01:06 +0530
Subject: [PATCH v2 13/13] tty: pruss SUART driver
In-Reply-To: <201102221734.15582.arnd@arndb.de>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<201102181951.32631.arnd@arndb.de>
	<DADE3366197E4479A57F3B967A881C33@subhasishg>
	<201102221734.15582.arnd@arndb.de>
Message-ID: <E56D2F3DE46B46C1B03302394F463B19@subhasishg>

Hello,

Ok, have implemented the test_and_clear_bit.


> On Tuesday 22 February 2011, Subhasish Ghosh wrote:
>
>> @@ -122,13 +122,10 @@ static void omapl_pru_tx_chars(struct 
>> omapl_pru_suart
>> *soft_uart, u32 uart_no)
>>         if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
>>                 return;
>>
>> -       if (down_trylock(&soft_uart->port_sem[uart_no]))
>> -               return;
>> -
>>         if (uart_circ_empty(xmit) ||
>>                         uart_tx_stopped(&soft_uart->port[uart_no])) {
>>                 pruss_suart_stop_tx(&soft_uart->port[uart_no]);
>> -               up(&soft_uart->port_sem[uart_no]);
>> +               soft_uart->tx_empty[uart_no] = true;
>>                 return;
>>         }
>>
>> @@ -259,7 +256,6 @@ static irqreturn_t pruss_suart_interrupt(s32 irq, 
>> void
>> *dev_id)
>>                         pru_intr_clr_isrstatus(dev, uart_num, 
>> PRU_TX_INTR);
>>                         pru_softuart_clr_tx_status(dev, 
>> &soft_uart->suart_hdl
>>                                                  [port->line]);
>> -                       up(&soft_uart->port_sem[port->line]);
>>                         omapl_pru_tx_chars(soft_uart, port->line);
>>                 }
>>         } while (txrx_flag & (PRU_RX_INTR | PRU_TX_INTR));
>> @@ -294,7 +290,10 @@ static void pruss_suart_start_tx(struct uart_port
>> *port)
>>
>>         suart_intr_setmask(dev, 
>> soft_uart->suart_hdl[port->line].uart_num,
>>                            PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
>> -       omapl_pru_tx_chars(soft_uart, port->line);
>> +       if (soft_uart->tx_empty[port->line] == true) {
>> +               soft_uart->tx_empty[port->line] = false;
>> +               omapl_pru_tx_chars(soft_uart, port->line);
>> +       }
>>  }
>
> This looks racy, and I think you at least need to take the spinlock in
> pruss_suart_start_tx(), but I don't fully understand the intention of the
> code.
>
> I guess you could also use a bitmask for tx_empty and use 
> test_and_clear_bit()
> on that to guarantee atomicity.
>
> Arnd 


From nsekhar at ti.com  Thu Feb 24 05:27:54 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 24 Feb 2011 16:57:54 +0530
Subject: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.
In-Reply-To: <886E26C48DE446C3937D89ECF86030B2@subhasishg>
References: <1297434088-27995-1-git-send-email-subhasish@mistralsolutions.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BE49175@dbde02.ent.ti.com>
	<886E26C48DE446C3937D89ECF86030B2@subhasishg>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE49711@dbde02.ent.ti.com>

Hi Subhasish,

On Thu, Feb 24, 2011 at 15:54:56, Subhasish Ghosh wrote:
> --------------------------------------------------
> From: "Nori, Sekhar" <nsekhar at ti.com>
> Sent: Wednesday, February 23, 2011 9:00 PM
> To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>; 
> <davinci-linux-open-source at linux.davincidsp.com>
> Cc: <linux-arm-kernel at lists.infradead.org>; "Watkins, Melissa" 
> <m-watkins at ti.com>; <sachi at mistralsolutions.com>; "Kevin Hilman" 
> <khilman at deeprootsystems.com>; "Russell King" <linux at arm.linux.org.uk>; 
> "Michael Williamson" <michael.williamson at criticallink.com>; "Chemparathy, 
> Cyril" <cyril at ti.com>; "Sergei Shtylyov" <sshtylyov at ru.mvista.com>; "open 
> list" <linux-kernel at vger.kernel.org>
> Subject: RE: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.
> 
> > Hi Subhasish,
> >
> > On Fri, Feb 11, 2011 at 19:51:28, Subhasish Ghosh wrote:
> >> This patch modifies the sram allocator to allocate memory
> >> from the DA8XX shared RAM.
> >
> > It will be nice to know if you tried suspend-to-RAM
> > after this change and found it to be working.
> >
> 
> SG -- My file system is currently mounted from MMC.
>           Suspend to RAM seems to have bug with MMC.
>            (http://processors.wiki.ti.com/index.php/OMAP-L1_Linux_Drivers_Usage#Suspend-to-RAM)

You can try Kevin's suggestion here:

http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-January/021807.html

>           I had tried NFS earlier, but I think there is some problem with 
> NFS boot and udev with this kernel.

Anyway there are some problems reported with Ethernet
driver and suspend on the latest kernel. Folks inside
TI are working on it.

>            So, currently I will not be able to do it, but will try if I get 
> a chance.

How about using ramdisk?

Thanks,
Sekhar

> > Thanks,
> > Sekhar
> >
> >>
> >> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> >> ---
> >>  arch/arm/mach-davinci/da850.c              |    6 +++---
> >>  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
> >>  2 files changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-davinci/da850.c 
> >> b/arch/arm/mach-davinci/da850.c
> >> index 3443d97..8a4de97 100644
> >> --- a/arch/arm/mach-davinci/da850.c
> >> +++ b/arch/arm/mach-davinci/da850.c
> >> @@ -711,7 +711,7 @@ static struct map_desc da850_io_desc[] = {
> >>  },
> >>  {
> >>  .virtual = SRAM_VIRT,
> >> - .pfn = __phys_to_pfn(DA8XX_ARM_RAM_BASE),
> >> + .pfn = __phys_to_pfn(DA8XX_SHARED_RAM_BASE),
> >>  .length = SZ_8K,
> >>  .type = MT_DEVICE
> >>  },
> >> @@ -1083,8 +1083,8 @@ static struct davinci_soc_info 
> >> davinci_soc_info_da850 = {
> >>  .gpio_irq = IRQ_DA8XX_GPIO0,
> >>  .serial_dev = &da8xx_serial_device,
> >>  .emac_pdata = &da8xx_emac_pdata,
> >> - .sram_dma = DA8XX_ARM_RAM_BASE,
> >> - .sram_len = SZ_8K,
> >> + .sram_dma = DA8XX_SHARED_RAM_BASE,
> >> + .sram_len = SZ_128K,
> >>  .reset_device = &da8xx_wdt_device,
> >>  };
> >>
> >> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h 
> >> b/arch/arm/mach-davinci/include/mach/da8xx.h
> >> index cfcb223..c3c3339 100644
> >> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> >> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> >> @@ -70,6 +70,7 @@ extern unsigned int da850_max_speed;
> >>  #define DA8XX_AEMIF_CTL_BASE 0x68000000
> >>  #define DA8XX_DDR2_CTL_BASE 0xb0000000
> >>  #define DA8XX_ARM_RAM_BASE 0xffff0000
> >> +#define DA8XX_SHARED_RAM_BASE 0x80000000
> >>
> >>  void __init da830_init(void);
> >>  void __init da850_init(void);
> >> -- 
> >> 1.7.2.3
> >>
> >>
> > 
> 


From anibal.pinto at efacec.com  Thu Feb 24 07:39:08 2011
From: anibal.pinto at efacec.com (=?ISO-8859-1?Q?An=EDbal_Almeida_Pinto?=)
Date: Thu, 24 Feb 2011 13:39:08 +0000
Subject: Possible bug on davinci spi driver
Message-ID: <4D665F7C.2050508@efacec.com>

Hi,

I am using the davinci spi driver [1] on an OMAP L138 board and I think 
that the driver has a bug.

At function davinci_spi_chipselect when using CS of the controller you 
write on SPI1DAT register the upper 16 bits to one, with exception the 
bit corresponding to chip select.

The problem is the selection of CSHOLD to one, this is a parameter of 
spidev and is being wrote without verifying the value that is on the 
register.

I don't have full understand the driver, haven't found were the spidev 
options are wrote to the registers, but this may affect other settings.

I can give a hand on more tests, if needed.

Thanks.

Regards,
An?bal

[1] - 
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git 
with the last commit on it is 8fb837c158e342413d08d6f211b5b8f67d5adc2f


From pratheesh at ti.com  Thu Feb 24 07:54:55 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Thu, 24 Feb 2011 19:24:55 +0530
Subject: [PATCH v3 1/2] PRUSS UIO driver support
In-Reply-To: <alpine.LFD.2.00.1102232057260.2701@localhost6.localdomain6>
References: <1298469161-7644-1-git-send-email-pratheesh@ti.com>
	<1298469161-7644-2-git-send-email-pratheesh@ti.com>
	<alpine.LFD.2.00.1102232057260.2701@localhost6.localdomain6>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE49813@dbde02.ent.ti.com>


> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx at linutronix.de]
> Sent: Thursday, February 24, 2011 1:56 AM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; hjk at hansjkoch.de;
> gregkh at suse.de; Chatterjee, Amit; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v3 1/2] PRUSS UIO driver support
> 
> On Wed, 23 Feb 2011, Pratheesh Gangadhar wrote:
> 
> Is it actually too much of an hassle to cc the people who spent their
> time to review previous versions of your patch ?
> 
Sorry. Will do...
> > +struct clk *pruss_clk;
> > +struct uio_info *info;
> > +void *ddr_virt_addr = NULL, *prussio_virt_addr = NULL;
> 
> Grrr. We do not initialize with NULL.
> 
> > +dma_addr_t ddr_phy_addr;
> 
> Also all of these want to be static.
> 
Ok.
> 
> > +		uio_unregister_device(p);
> > +		kfree(p->name);
> > +	}
> > +	iounmap(prussio_virt_addr);
> > +	dma_free_coherent(&dev->dev, info[0].mem[2].size,
> > +			  info[0].mem[2].internal_addr, info[0].mem[2].addr);
> 
> You sure, that iounmap and dma_free_coherent are too happy about being
> called with NULL pointers?
> 
For iounmap its ok, not ok for dma_free_coherent. Will fix.
> > +
> > +	kfree(info);
> > +	clk_put(pruss_clk);
> > +}
> > +
> > +static int __devinit pruss_probe(struct platform_device *dev)
> > +{
> > +	int ret = -ENODEV, count = 0;
> > +	struct resource *regs_prussio, *regs_l3ram, *regs_ddr;
> > +	struct uio_info *p;
> > +
> > +	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVTOUT_INSTANCE,
> > +		       GFP_KERNEL);
> > +	if (!info)
> > +		return -ENOMEM;
> > +
> > +	/* Power on PRU in case its not done as part of boot-loader */
> > +	pruss_clk = clk_get(&dev->dev, "pruss");
> > +	if (IS_ERR(pruss_clk)) {
> > +		dev_err(&dev->dev, "Failed to get clock\n");
> > +		ret = PTR_ERR(pruss_clk);
> > +		return ret;
> 
> Memory leak.
Will fix.
 

Thanks,
Pratheesh

From pratheesh at ti.com  Thu Feb 24 07:55:51 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Thu, 24 Feb 2011 19:25:51 +0530
Subject: [PATCH v3 1/2] PRUSS UIO driver support
In-Reply-To: <alpine.LFD.2.00.1102232153500.2701@localhost6.localdomain6>
References: <1298469161-7644-1-git-send-email-pratheesh@ti.com>
	<1298469161-7644-2-git-send-email-pratheesh@ti.com>
	<alpine.LFD.2.00.1102232057260.2701@localhost6.localdomain6>
	<4D6572ED.9020805@mvista.com>
	<alpine.LFD.2.00.1102232153500.2701@localhost6.localdomain6>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE49815@dbde02.ent.ti.com>


> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx at linutronix.de]
> Sent: Thursday, February 24, 2011 2:24 AM
> To: Sergei Shtylyov
> Cc: TK, Pratheesh Gangadhar; davinci-linux-open-
> source at linux.davincidsp.com; Chatterjee, Amit; gregkh at suse.de; linux-
> kernel at vger.kernel.org; hjk at hansjkoch.de; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v3 1/2] PRUSS UIO driver support
> 
> On Wed, 23 Feb 2011, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 23-02-2011 23:25, Thomas Gleixner wrote:
> >
> > > > +	prussio_virt_addr =
> > > > +	    ioremap(regs_prussio->start,
> > > > +		    regs_prussio->end - regs_prussio->start + 1);
> >
> > > Either make those variable names shorter or do:
> >
> > >         len = regs_prussio->end - regs_prussio->start + 1;
> >
> >    Or even:
> >
> > 	len = resource_size(regs_prussio);
> >
> > >         prussio_virt_addr = ioremap(regs_prussio->start, len);
> 
> Good point. Forgot about that one :)
> 
Thanks will do this.

Pratheesh

From pratheesh at ti.com  Thu Feb 24 07:56:28 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Thu, 24 Feb 2011 19:26:28 +0530
Subject: [PATCH v3 1/2] PRUSS UIO driver support
In-Reply-To: <20110223173724.GA2801@local>
References: <1298469161-7644-1-git-send-email-pratheesh@ti.com>
	<1298469161-7644-2-git-send-email-pratheesh@ti.com>
	<20110223173724.GA2801@local>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE49816@dbde02.ent.ti.com>



> -----Original Message-----
> From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> Sent: Wednesday, February 23, 2011 11:07 PM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; hjk at hansjkoch.de;
> gregkh at suse.de; Chatterjee, Amit; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v3 1/2] PRUSS UIO driver support
> 
> On Wed, Feb 23, 2011 at 07:22:40PM +0530, Pratheesh Gangadhar wrote:
> > This patch implements PRUSS (Programmable Real-time Unit Sub System)
> > UIO driver which exports SOC resources associated with PRUSS like
> > I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
> > processors which is efficient in performing embedded tasks that
> > require manipulation of packed memory mapped data structures and
> > efficient in handling system events that have tight real time
> > constraints. This driver is currently supported on Texas Instruments
> > DA850, AM18xx and OMAPL1-38 devices.
> > For example, PRUSS runs firmware for real-time critical industrial
> > communication data link layer and communicates with application stack
> > running in user space via shared memory and IRQs.
> >
> > Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
> > ---
> >  drivers/uio/Kconfig     |   17 ++++
> >  drivers/uio/Makefile    |    1 +
> >  drivers/uio/uio_pruss.c |  223
> +++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 241 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/uio/uio_pruss.c
> >
> 
> [...]
> 
> > +
> > +static int __devinit pruss_probe(struct platform_device *dev)
> > +{
> > +	int ret = -ENODEV, count = 0;
> > +	struct resource *regs_prussio, *regs_l3ram, *regs_ddr;
> > +	struct uio_info *p;
> > +
> > +	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVTOUT_INSTANCE,
> > +		       GFP_KERNEL);
> > +	if (!info)
> > +		return -ENOMEM;
> > +
> > +	/* Power on PRU in case its not done as part of boot-loader */
> > +	pruss_clk = clk_get(&dev->dev, "pruss");
> > +	if (IS_ERR(pruss_clk)) {
> > +		dev_err(&dev->dev, "Failed to get clock\n");
> > +		ret = PTR_ERR(pruss_clk);
> > +		return ret;
> 
> You leak memory here. What about freeing "info"?

Ok. Will fix.

Thanks,
Pratheesh

From pratheesh at ti.com  Thu Feb 24 08:06:40 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Thu, 24 Feb 2011 19:36:40 +0530
Subject: [PATCH v4 0/2] Add PRUSS UIO driver support
Message-ID: <1298556402-26456-1-git-send-email-pratheesh@ti.com>

This patch series add support for PRUSS (Programmable Real-time Unit Sub
System) UIO driver in Texas Instruments DA850, AM18xx and OMAPL1-38 processors.
PRUSS is programmable RISC core which can be used to implement Soft IPs
(eg:- DMA, CAN, UART,SmartCard) and Industrial communications data link layers
(eg:- PROFIBUS). UIO driver exposes PRUSS resources like memory and interrupts 
to user space application.PRUSS UIO application API can be used to control PRUs
 in PRUSS, setup PRU INTC, load firmware to PRUs and implement IPC between Host
 processor and PRUs. More information on PRUSS and UIO linux user space API 
available in the links below

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide

Pratheesh Gangadhar (2):
  PRUSS UIO driver support
  Defines DA850/AM18xx/OMAPL1-38 SOC resources used by PRUSS UIO driver

 arch/arm/mach-davinci/board-da850-evm.c    |    4 +
 arch/arm/mach-davinci/da850.c              |   35 +++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 ++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 drivers/uio/Kconfig                        |   17 +++
 drivers/uio/Makefile                       |    1 +
 drivers/uio/uio_pruss.c                    |  216 ++++++++++++++++++++++++++++
 7 files changed, 349 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c


From pratheesh at ti.com  Thu Feb 24 08:06:41 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Thu, 24 Feb 2011 19:36:41 +0530
Subject: [PATCH v4 1/2] PRUSS UIO driver support
In-Reply-To: <1298556402-26456-1-git-send-email-pratheesh@ti.com>
References: <1298556402-26456-1-git-send-email-pratheesh@ti.com>
Message-ID: <1298556402-26456-2-git-send-email-pratheesh@ti.com>

This patch implements PRUSS (Programmable Real-time Unit Sub System)
UIO driver which exports SOC resources associated with PRUSS like
I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
processors which is efficient in performing embedded tasks that
require manipulation of packed memory mapped data structures and
efficient in handling system events that have tight real time
constraints. This driver is currently supported on Texas Instruments
DA850, AM18xx and OMAPL1-38 devices.
For example, PRUSS runs firmware for real-time critical industrial
communication data link layer and communicates with application stack
running in user space via shared memory and IRQs.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
---
 drivers/uio/Kconfig     |   17 ++++
 drivers/uio/Makefile    |    1 +
 drivers/uio/uio_pruss.c |  216 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 234 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index bb44079..6f3ea9b 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -94,4 +94,21 @@ config UIO_NETX
 	  To compile this driver as a module, choose M here; the module
 	  will be called uio_netx.
 
+config UIO_PRUSS
+	tristate "Texas Instruments PRUSS driver"
+	depends on ARCH_DAVINCI_DA850
+	help
+	  PRUSS driver for OMAPL138/DA850/AM18XX devices
+	  PRUSS driver requires user space components, examples and user space
+	  driver is available from below SVN repo - you may use anonymous login
+
+	  https://gforge.ti.com/gf/project/pru_sw/
+
+	  More info on API is available at below wiki
+
+	  http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called uio_pruss.
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..d4dd9a5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC)	+= uio_aec.o
 obj-$(CONFIG_UIO_SERCOS3)	+= uio_sercos3.o
 obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
+obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
new file mode 100644
index 0000000..bb92941
--- /dev/null
+++ b/drivers/uio/uio_pruss.c
@@ -0,0 +1,216 @@
+/*
+ * Programmable Real-Time Unit Sub System (PRUSS) UIO driver (uio_pruss)
+ *
+ * This driver exports PRUSS host event out interrupts and PRUSS, L3 RAM,
+ * and DDR RAM to user space for applications interacting with PRUSS firmware
+ *
+ * Copyright (C) 2010-11 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 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/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+
+#define DRV_NAME "pruss"
+#define DRV_VERSION "0.50"
+
+/*
+ * Host event IRQ numbers from PRUSS - PRUSS can generate upto 8 interrupt
+ * events to AINTC of ARM host processor - which can be used for IPC b/w PRUSS
+ * firmware and user space application, async notification from PRU firmware
+ * to user space application
+ * 3	PRU_EVTOUT0
+ * 4	PRU_EVTOUT1
+ * 5	PRU_EVTOUT2
+ * 6	PRU_EVTOUT3
+ * 7	PRU_EVTOUT4
+ * 8	PRU_EVTOUT5
+ * 9	PRU_EVTOUT6
+ * 10	PRU_EVTOUT7
+*/
+
+#define MAX_PRUSS_EVT			8
+
+#define	PINTC_HIPIR			0x4900
+#define	HIPIR_NOPEND			0x80000000
+#define	PINTC_HIER			0x5500
+
+static struct clk *pruss_clk;
+static struct uio_info *info;
+static dma_addr_t ddr_paddr;
+static void *ddr_vaddr, *prussio_vaddr;
+
+static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
+{
+	void __iomem *base = dev_info->mem[0].internal_addr;
+	void __iomem *intren_reg = base + PINTC_HIER;
+	void __iomem *intrstat_reg = base + PINTC_HIPIR + ((irq - 1) << 2);
+	int val = ioread32(intren_reg), intr_mask = (1 << (irq - 1));
+
+	/* Is interrupt enabled and active ? */
+	if (!(val & intr_mask) && (ioread32(intrstat_reg) & HIPIR_NOPEND))
+		return IRQ_NONE;
+
+	/* Disable interrupt */
+	iowrite32((val & ~intr_mask), intren_reg);
+	return IRQ_HANDLED;
+}
+
+static void pruss_cleanup(struct platform_device *dev, struct uio_info *info)
+{
+	struct uio_info *p = info;
+	int cnt;
+
+	for (cnt = 0; cnt < MAX_PRUSS_EVT; cnt++, p++) {
+		uio_unregister_device(p);
+		kfree(p->name);
+	}
+	iounmap(prussio_vaddr);
+	if (ddr_vaddr)
+		dma_free_coherent(&dev->dev, info->mem[2].size,
+			info->mem[2].internal_addr, info->mem[2].addr);
+	kfree(info);
+	clk_put(pruss_clk);
+}
+
+static int __devinit pruss_probe(struct platform_device *dev)
+{
+	struct uio_info *p;
+	int ret = -ENODEV, cnt = 0, len;
+	struct resource *regs_prussio, *regs_l3ram, *regs_ddr;
+
+	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVT, GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+	/* Power on PRU in case its not done as part of boot-loader */
+	pruss_clk = clk_get(&dev->dev, "pruss");
+	if (IS_ERR(pruss_clk)) {
+		dev_err(&dev->dev, "Failed to get clock\n");
+		kfree(info);
+		ret = PTR_ERR(pruss_clk);
+		return ret;
+	} else {
+		clk_enable(pruss_clk);
+	}
+
+	regs_prussio = platform_get_resource(dev, IORESOURCE_MEM, 0);
+	if (!regs_prussio) {
+		dev_err(&dev->dev, "No PRUSS I/O resource specified\n");
+		goto out_free;
+	}
+
+	regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
+	if (!regs_l3ram) {
+		dev_err(&dev->dev, "No L3 RAM resource specified\n");
+		goto out_free;
+	}
+
+	regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
+	if (!regs_ddr) {
+		dev_err(&dev->dev, "No External RAM resource specified\n");
+		goto out_free;
+	}
+
+	if (!regs_prussio->start || !regs_l3ram->start) {
+		dev_err(&dev->dev, "Invalid memory resource\n");
+		goto out_free;
+	}
+	len = resource_size(regs_ddr);
+	ddr_vaddr =
+	dma_alloc_coherent(&dev->dev, len, &ddr_paddr, GFP_KERNEL | GFP_DMA);
+	if (!ddr_vaddr) {
+		dev_err(&dev->dev, "Could not allocate external memory\n");
+		goto out_free;
+	}
+	len = resource_size(regs_prussio);
+	prussio_vaddr = ioremap(regs_prussio->start, len);
+	if (!prussio_vaddr) {
+		dev_err(&dev->dev, "Can't remap PRUSS I/O  address range\n");
+		goto out_free;
+	}
+
+	for (cnt = 0, p = info; cnt < MAX_PRUSS_EVT; cnt++, p++) {
+		p->mem[0].internal_addr = prussio_vaddr;
+		p->mem[0].addr = regs_prussio->start;
+		p->mem[0].size = resource_size(regs_prussio);
+		p->mem[0].memtype = UIO_MEM_PHYS;
+
+		p->mem[1].addr = regs_l3ram->start;
+		p->mem[1].size = resource_size(regs_l3ram);
+		p->mem[1].memtype = UIO_MEM_PHYS;
+
+		p->mem[2].internal_addr = ddr_vaddr;
+		p->mem[2].addr = ddr_paddr;
+		p->mem[2].size = resource_size(regs_ddr);
+		p->mem[2].memtype = UIO_MEM_PHYS;
+
+		p->name = kasprintf(GFP_KERNEL, "pruss_evt%d", cnt);
+		p->version = "0.50";
+
+		/* Register PRUSS IRQ lines */
+		p->irq = IRQ_DA8XX_EVTOUT0 + cnt;
+		p->handler = pruss_handler;
+
+		ret = uio_register_device(&dev->dev, p);
+
+		if (ret < 0)
+			goto out_free;
+	}
+
+	platform_set_drvdata(dev, info);
+	return 0;
+
+out_free:
+	pruss_cleanup(dev, info);
+	return ret;
+}
+
+static int __devexit pruss_remove(struct platform_device *dev)
+{
+	struct uio_info *info = platform_get_drvdata(dev);
+
+	pruss_cleanup(dev, info);
+	platform_set_drvdata(dev, NULL);
+	return 0;
+}
+
+static struct platform_driver pruss_driver = {
+	.probe = pruss_probe,
+	.remove = __devexit_p(pruss_remove),
+	.driver = {
+		   .name = DRV_NAME,
+		   .owner = THIS_MODULE,
+		   },
+};
+
+static int __init pruss_init_module(void)
+{
+	return platform_driver_register(&pruss_driver);
+}
+
+module_init(pruss_init_module);
+
+static void __exit pruss_exit_module(void)
+{
+	platform_driver_unregister(&pruss_driver);
+}
+
+module_exit(pruss_exit_module);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Amit Chatterjee <amit.chatterjee at ti.com>");
+MODULE_AUTHOR("Pratheesh Gangadhar <pratheesh at ti.com>");
-- 
1.6.0.6


From pratheesh at ti.com  Thu Feb 24 08:06:42 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Thu, 24 Feb 2011 19:36:42 +0530
Subject: [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used by
	PRUSS UIO driver
In-Reply-To: <1298556402-26456-2-git-send-email-pratheesh@ti.com>
References: <1298556402-26456-1-git-send-email-pratheesh@ti.com>
	<1298556402-26456-2-git-send-email-pratheesh@ti.com>
Message-ID: <1298556402-26456-3-git-send-email-pratheesh@ti.com>

This patch defines PRUSS, ECAP clocks, memory and IRQ resources
used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
DDR buffer to user space. PRUSS has 8 host event interrupt lines
mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
with shared memory can be used to implement IPC between ARM9 and
PRUSS.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c    |    4 ++
 arch/arm/mach-davinci/da850.c              |   35 +++++++++++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 4 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..bd85aa3 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
 		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
 				ret);
 
+	ret = da8xx_register_pruss();
+	if (ret)
+		pr_warning("da850_evm_init: pruss registration failed: %d\n",
+				ret);
 
 	ret = da8xx_register_watchdog();
 	if (ret)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..0096d4f 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
 	.flags		= ALWAYS_ENABLED,
 };
 
+static struct clk pruss_clk = {
+	.name		= "pruss",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_DMAX,
+	.flags		= ALWAYS_ENABLED,
+};
+
 static struct clk uart0_clk = {
 	.name		= "uart0",
 	.parent		= &pll0_sysclk2,
@@ -359,6 +366,30 @@ static struct clk usb20_clk = {
 	.gpsc		= 1,
 };
 
+static struct clk ecap0_clk = {
+	.name		= "ecap0",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap1_clk = {
+	.name		= "ecap1",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap2_clk = {
+	.name		= "ecap2",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -386,6 +417,7 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tptc1",	&tptc1_clk),
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
+	CLK(NULL,		"pruss",	&pruss_clk),
 	CLK(NULL,		"uart0",	&uart0_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
@@ -403,6 +435,9 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"aemif",	&aemif_clk),
 	CLK(NULL,		"usb11",	&usb11_clk),
 	CLK(NULL,		"usb20",	&usb20_clk),
+	CLK(NULL,		"ecap0",	&ecap0_clk),
+	CLK(NULL,		"ecap1",	&ecap1_clk),
+	CLK(NULL,		"ecap2",	&ecap2_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..4ea3d1f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+static struct resource pruss_resources[] = {
+	[0] = {
+		.start  = DA8XX_PRUSS_BASE,
+		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[1] = {
+		.start  = DA8XX_L3RAM_BASE,
+		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[2] = {
+		.start  = 0,
+		.end    = SZ_256K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+
+	[3] = {
+		.start  = IRQ_DA8XX_EVTOUT0,
+		.end    = IRQ_DA8XX_EVTOUT0,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[4] = {
+		.start  = IRQ_DA8XX_EVTOUT1,
+		.end    = IRQ_DA8XX_EVTOUT1,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[5] = {
+		.start  = IRQ_DA8XX_EVTOUT2,
+		.end    = IRQ_DA8XX_EVTOUT2,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[6] = {
+		.start  = IRQ_DA8XX_EVTOUT3,
+		.end    = IRQ_DA8XX_EVTOUT3,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[7] = {
+		.start  = IRQ_DA8XX_EVTOUT4,
+		.end    = IRQ_DA8XX_EVTOUT4,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[8] = {
+		.start  = IRQ_DA8XX_EVTOUT5,
+		.end    = IRQ_DA8XX_EVTOUT5,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[9] = {
+		.start  = IRQ_DA8XX_EVTOUT6,
+		.end    = IRQ_DA8XX_EVTOUT6,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[10] = {
+		.start  = IRQ_DA8XX_EVTOUT7,
+		.end    = IRQ_DA8XX_EVTOUT7,
+		.flags  = IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device pruss_device = {
+	.name			= "pruss",
+	.id			= 0,
+	.num_resources		= ARRAY_SIZE(pruss_resources),
+	.resource		= pruss_resources,
+	.dev	 =	{
+		.coherent_dma_mask = 0xffffffff,
+	}
+};
+
+int __init da8xx_register_pruss()
+{
+	return platform_device_register(&pruss_device);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..3ed6ee0 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -60,6 +60,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_PLL0_BASE		0x01c11000
 #define DA8XX_TIMER64P0_BASE	0x01c20000
 #define DA8XX_TIMER64P1_BASE	0x01c21000
+#define DA8XX_PRUSS_BASE	0x01c30000
 #define DA8XX_GPIO_BASE		0x01e26000
 #define DA8XX_PSC1_BASE		0x01e27000
 #define DA8XX_LCD_CNTRL_BASE	0x01e13000
@@ -68,6 +69,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CS2_BASE	0x60000000
 #define DA8XX_AEMIF_CS3_BASE	0x62000000
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
+#define DA8XX_L3RAM_BASE	0x80000000
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
 
@@ -90,6 +92,7 @@ int da850_register_cpufreq(char *async_clk);
 int da8xx_register_cpuidle(void);
 void __iomem * __init da8xx_get_mem_ctlr(void);
 int da850_register_pm(struct platform_device *pdev);
+int da8xx_register_pruss(void);
 
 extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
-- 
1.6.0.6


From nsekhar at ti.com  Thu Feb 24 10:53:43 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 24 Feb 2011 22:23:43 +0530
Subject: [PATCH v4 0/4] davinci: add spi devices support for da8xx based
	platforms
In-Reply-To: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
References: <1298486651-18882-1-git-send-email-michael.williamson@criticallink.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE498B5@dbde02.ent.ti.com>

Hi Mike,

On Thu, Feb 24, 2011 at 00:14:07, Michael Williamson wrote:
> This patch series adds SPI bus support and devices for the MityDSP-L138,
> MityARM-1808, da850 evm, and da830 evm platforms.  This patch series is 
> against the staging tree at [1] as per Sekhar's instructions.
> 
> This series has been tested on the MityDSP-L138 platform.

I queued these patches for Kevin to pick-up for 2.6.39

Thanks for your efforts on this.

Best Regards,
Sekhar

From pratheesh at ti.com  Fri Feb 25 02:45:29 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Fri, 25 Feb 2011 14:15:29 +0530
Subject: [PATCH v5 1/2] PRUSS UIO driver support
In-Reply-To: <1298623530-10294-1-git-send-email-pratheesh@ti.com>
References: <1298623530-10294-1-git-send-email-pratheesh@ti.com>
Message-ID: <1298623530-10294-2-git-send-email-pratheesh@ti.com>

This patch implements PRUSS (Programmable Real-time Unit Sub System)
UIO driver which exports SOC resources associated with PRUSS like
I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
processors which is efficient in performing embedded tasks that
require manipulation of packed memory mapped data structures and
efficient in handling system events that have tight real time
constraints. This driver is currently supported on Texas Instruments
DA850, AM18xx and OMAPL1-38 devices.
For example, PRUSS runs firmware for real-time critical industrial
communication data link layer and communicates with application stack
running in user space via shared memory and IRQs.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
Reviewed-by: Thomas Gleixner <tglx at linutronix.de>
---
 drivers/uio/Kconfig     |   17 ++++
 drivers/uio/Makefile    |    1 +
 drivers/uio/uio_pruss.c |  217 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 235 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index bb44079..6f3ea9b 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -94,4 +94,21 @@ config UIO_NETX
 	  To compile this driver as a module, choose M here; the module
 	  will be called uio_netx.
 
+config UIO_PRUSS
+	tristate "Texas Instruments PRUSS driver"
+	depends on ARCH_DAVINCI_DA850
+	help
+	  PRUSS driver for OMAPL138/DA850/AM18XX devices
+	  PRUSS driver requires user space components, examples and user space
+	  driver is available from below SVN repo - you may use anonymous login
+
+	  https://gforge.ti.com/gf/project/pru_sw/
+
+	  More info on API is available at below wiki
+
+	  http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called uio_pruss.
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..d4dd9a5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC)	+= uio_aec.o
 obj-$(CONFIG_UIO_SERCOS3)	+= uio_sercos3.o
 obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
+obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
new file mode 100644
index 0000000..d17d3aa
--- /dev/null
+++ b/drivers/uio/uio_pruss.c
@@ -0,0 +1,217 @@
+/*
+ * Programmable Real-Time Unit Sub System (PRUSS) UIO driver (uio_pruss)
+ *
+ * This driver exports PRUSS host event out interrupts and PRUSS, L3 RAM,
+ * and DDR RAM to user space for applications interacting with PRUSS firmware
+ *
+ * Copyright (C) 2010-11 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 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/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+
+#define DRV_NAME "pruss"
+#define DRV_VERSION "0.50"
+
+/*
+ * Host event IRQ numbers from PRUSS - PRUSS can generate upto 8 interrupt
+ * events to AINTC of ARM host processor - which can be used for IPC b/w PRUSS
+ * firmware and user space application, async notification from PRU firmware
+ * to user space application
+ * 3	PRU_EVTOUT0
+ * 4	PRU_EVTOUT1
+ * 5	PRU_EVTOUT2
+ * 6	PRU_EVTOUT3
+ * 7	PRU_EVTOUT4
+ * 8	PRU_EVTOUT5
+ * 9	PRU_EVTOUT6
+ * 10	PRU_EVTOUT7
+*/
+
+#define MAX_PRUSS_EVT			8
+
+#define	PINTC_HIPIR			0x4900
+#define	HIPIR_NOPEND			0x80000000
+#define	PINTC_HIER			0x5500
+
+static struct clk *pruss_clk;
+static struct uio_info *info;
+static dma_addr_t ddr_paddr;
+static void *ddr_vaddr, *prussio_vaddr;
+
+static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
+{
+	void __iomem *base = dev_info->mem[0].internal_addr;
+	void __iomem *intren_reg = base + PINTC_HIER;
+	void __iomem *intrstat_reg = base + PINTC_HIPIR + ((irq - 1) << 2);
+	int val = ioread32(intren_reg), intr_mask = (1 << (irq - 1));
+
+	/* Is interrupt enabled and active ? */
+	if (!(val & intr_mask) && (ioread32(intrstat_reg) & HIPIR_NOPEND))
+		return IRQ_NONE;
+
+	/* Disable interrupt */
+	iowrite32((val & ~intr_mask), intren_reg);
+	return IRQ_HANDLED;
+}
+
+static void pruss_cleanup(struct platform_device *dev, struct uio_info *info)
+{
+	struct uio_info *p = info;
+	int cnt;
+
+	for (cnt = 0; cnt < MAX_PRUSS_EVT; cnt++, p++) {
+		uio_unregister_device(p);
+		kfree(p->name);
+	}
+	iounmap(prussio_vaddr);
+	if (ddr_vaddr) {
+		dma_free_coherent(&dev->dev, info->mem[2].size,
+			info->mem[2].internal_addr, info->mem[2].addr);
+	}
+	kfree(info);
+	clk_put(pruss_clk);
+}
+
+static int __devinit pruss_probe(struct platform_device *dev)
+{
+	struct uio_info *p;
+	int ret = -ENODEV, cnt = 0, len;
+	struct resource *regs_prussio, *regs_l3ram, *regs_ddr;
+
+	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVT, GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+	/* Power on PRU in case its not done as part of boot-loader */
+	pruss_clk = clk_get(&dev->dev, "pruss");
+	if (IS_ERR(pruss_clk)) {
+		dev_err(&dev->dev, "Failed to get clock\n");
+		kfree(info);
+		ret = PTR_ERR(pruss_clk);
+		return ret;
+	} else {
+		clk_enable(pruss_clk);
+	}
+
+	regs_prussio = platform_get_resource(dev, IORESOURCE_MEM, 0);
+	if (!regs_prussio) {
+		dev_err(&dev->dev, "No PRUSS I/O resource specified\n");
+		goto out_free;
+	}
+
+	regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
+	if (!regs_l3ram) {
+		dev_err(&dev->dev, "No L3 RAM resource specified\n");
+		goto out_free;
+	}
+
+	regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
+	if (!regs_ddr) {
+		dev_err(&dev->dev, "No External RAM resource specified\n");
+		goto out_free;
+	}
+
+	if (!regs_prussio->start || !regs_l3ram->start) {
+		dev_err(&dev->dev, "Invalid memory resource\n");
+		goto out_free;
+	}
+	len = resource_size(regs_ddr);
+	ddr_vaddr = dma_alloc_coherent(&dev->dev, len, &ddr_paddr,
+				GFP_KERNEL | GFP_DMA);
+	if (!ddr_vaddr) {
+		dev_err(&dev->dev, "Could not allocate external memory\n");
+		goto out_free;
+	}
+	len = resource_size(regs_prussio);
+	prussio_vaddr = ioremap(regs_prussio->start, len);
+	if (!prussio_vaddr) {
+		dev_err(&dev->dev, "Can't remap PRUSS I/O  address range\n");
+		goto out_free;
+	}
+
+	for (cnt = 0, p = info; cnt < MAX_PRUSS_EVT; cnt++, p++) {
+		p->mem[0].internal_addr = prussio_vaddr;
+		p->mem[0].addr = regs_prussio->start;
+		p->mem[0].size = resource_size(regs_prussio);
+		p->mem[0].memtype = UIO_MEM_PHYS;
+
+		p->mem[1].addr = regs_l3ram->start;
+		p->mem[1].size = resource_size(regs_l3ram);
+		p->mem[1].memtype = UIO_MEM_PHYS;
+
+		p->mem[2].internal_addr = ddr_vaddr;
+		p->mem[2].addr = ddr_paddr;
+		p->mem[2].size = resource_size(regs_ddr);
+		p->mem[2].memtype = UIO_MEM_PHYS;
+
+		p->name = kasprintf(GFP_KERNEL, "pruss_evt%d", cnt);
+		p->version = "0.50";
+
+		/* Register PRUSS IRQ lines */
+		p->irq = IRQ_DA8XX_EVTOUT0 + cnt;
+		p->handler = pruss_handler;
+
+		ret = uio_register_device(&dev->dev, p);
+
+		if (ret < 0)
+			goto out_free;
+	}
+
+	platform_set_drvdata(dev, info);
+	return 0;
+
+out_free:
+	pruss_cleanup(dev, info);
+	return ret;
+}
+
+static int __devexit pruss_remove(struct platform_device *dev)
+{
+	struct uio_info *info = platform_get_drvdata(dev);
+
+	pruss_cleanup(dev, info);
+	platform_set_drvdata(dev, NULL);
+	return 0;
+}
+
+static struct platform_driver pruss_driver = {
+	.probe = pruss_probe,
+	.remove = __devexit_p(pruss_remove),
+	.driver = {
+		   .name = DRV_NAME,
+		   .owner = THIS_MODULE,
+		   },
+};
+
+static int __init pruss_init_module(void)
+{
+	return platform_driver_register(&pruss_driver);
+}
+
+module_init(pruss_init_module);
+
+static void __exit pruss_exit_module(void)
+{
+	platform_driver_unregister(&pruss_driver);
+}
+
+module_exit(pruss_exit_module);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Amit Chatterjee <amit.chatterjee at ti.com>");
+MODULE_AUTHOR("Pratheesh Gangadhar <pratheesh at ti.com>");
-- 
1.6.0.6


From pratheesh at ti.com  Fri Feb 25 02:45:28 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Fri, 25 Feb 2011 14:15:28 +0530
Subject: [PATCH v5 0/2] Add PRUSS UIO driver support
Message-ID: <1298623530-10294-1-git-send-email-pratheesh@ti.com>

This patch series add support for PRUSS (Programmable Real-time Unit Sub
System) UIO driver in Texas Instruments DA850, AM18xx and OMAPL1-38 processors.
PRUSS is programmable RISC core which can be used to implement Soft IPs
(eg:- DMA, CAN, UART,SmartCard) and Industrial communications data link layers
(eg:- PROFIBUS). UIO driver exposes PRUSS resources like memory and interrupts 
to user space application.PRUSS UIO application API can be used to control PRUs
 in PRUSS, setup PRU INTC, load firmware to PRUs and implement IPC between Host
 processor and PRUs. More information on PRUSS and UIO linux user space API 
available in the links below

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide

Pratheesh Gangadhar (2):
  PRUSS UIO driver support
  Defines DA850/AM18xx/OMAPL1-38 SOC resources used by PRUSS UIO driver

 arch/arm/mach-davinci/board-da850-evm.c    |    4 +
 arch/arm/mach-davinci/da850.c              |   35 +++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 ++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 drivers/uio/Kconfig                        |   17 +++
 drivers/uio/Makefile                       |    1 +
 drivers/uio/uio_pruss.c                    |  217 ++++++++++++++++++++++++++++
 7 files changed, 350 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c


From pratheesh at ti.com  Fri Feb 25 02:45:30 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Fri, 25 Feb 2011 14:15:30 +0530
Subject: [PATCH v5 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used by
	PRUSS UIO driver
In-Reply-To: <1298623530-10294-2-git-send-email-pratheesh@ti.com>
References: <1298623530-10294-1-git-send-email-pratheesh@ti.com>
	<1298623530-10294-2-git-send-email-pratheesh@ti.com>
Message-ID: <1298623530-10294-3-git-send-email-pratheesh@ti.com>

This patch defines PRUSS, ECAP clocks, memory and IRQ resources
used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
DDR buffer to user space. PRUSS has 8 host event interrupt lines
mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
with shared memory can be used to implement IPC between ARM9 and
PRUSS.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c    |    4 ++
 arch/arm/mach-davinci/da850.c              |   35 +++++++++++++
 arch/arm/mach-davinci/devices-da8xx.c      |   73 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 +
 4 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 11f986b..bd85aa3 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
 		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
 				ret);
 
+	ret = da8xx_register_pruss();
+	if (ret)
+		pr_warning("da850_evm_init: pruss registration failed: %d\n",
+				ret);
 
 	ret = da8xx_register_watchdog();
 	if (ret)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 3443d97..0096d4f 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
 	.flags		= ALWAYS_ENABLED,
 };
 
+static struct clk pruss_clk = {
+	.name		= "pruss",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_DMAX,
+	.flags		= ALWAYS_ENABLED,
+};
+
 static struct clk uart0_clk = {
 	.name		= "uart0",
 	.parent		= &pll0_sysclk2,
@@ -359,6 +366,30 @@ static struct clk usb20_clk = {
 	.gpsc		= 1,
 };
 
+static struct clk ecap0_clk = {
+	.name		= "ecap0",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap1_clk = {
+	.name		= "ecap1",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
+static struct clk ecap2_clk = {
+	.name		= "ecap2",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_ECAP,
+	.flags		= DA850_CLK_ASYNC3,
+	.gpsc		= 1,
+};
+
 static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -386,6 +417,7 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tptc1",	&tptc1_clk),
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
+	CLK(NULL,		"pruss",	&pruss_clk),
 	CLK(NULL,		"uart0",	&uart0_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
@@ -403,6 +435,9 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"aemif",	&aemif_clk),
 	CLK(NULL,		"usb11",	&usb11_clk),
 	CLK(NULL,		"usb20",	&usb20_clk),
+	CLK(NULL,		"ecap0",	&ecap0_clk),
+	CLK(NULL,		"ecap1",	&ecap1_clk),
+	CLK(NULL,		"ecap2",	&ecap2_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index beda8a4..4ea3d1f 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
 
 	return platform_device_register(&da8xx_cpuidle_device);
 }
+static struct resource pruss_resources[] = {
+	[0] = {
+		.start  = DA8XX_PRUSS_BASE,
+		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[1] = {
+		.start  = DA8XX_L3RAM_BASE,
+		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+	[2] = {
+		.start  = 0,
+		.end    = SZ_256K - 1,
+		.flags  = IORESOURCE_MEM,
+	},
+
+	[3] = {
+		.start  = IRQ_DA8XX_EVTOUT0,
+		.end    = IRQ_DA8XX_EVTOUT0,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[4] = {
+		.start  = IRQ_DA8XX_EVTOUT1,
+		.end    = IRQ_DA8XX_EVTOUT1,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[5] = {
+		.start  = IRQ_DA8XX_EVTOUT2,
+		.end    = IRQ_DA8XX_EVTOUT2,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[6] = {
+		.start  = IRQ_DA8XX_EVTOUT3,
+		.end    = IRQ_DA8XX_EVTOUT3,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[7] = {
+		.start  = IRQ_DA8XX_EVTOUT4,
+		.end    = IRQ_DA8XX_EVTOUT4,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[8] = {
+		.start  = IRQ_DA8XX_EVTOUT5,
+		.end    = IRQ_DA8XX_EVTOUT5,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[9] = {
+		.start  = IRQ_DA8XX_EVTOUT6,
+		.end    = IRQ_DA8XX_EVTOUT6,
+		.flags  = IORESOURCE_IRQ,
+	},
+	[10] = {
+		.start  = IRQ_DA8XX_EVTOUT7,
+		.end    = IRQ_DA8XX_EVTOUT7,
+		.flags  = IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device pruss_device = {
+	.name			= "pruss",
+	.id			= 0,
+	.num_resources		= ARRAY_SIZE(pruss_resources),
+	.resource		= pruss_resources,
+	.dev	 =	{
+		.coherent_dma_mask = 0xffffffff,
+	}
+};
+
+int __init da8xx_register_pruss()
+{
+	return platform_device_register(&pruss_device);
+}
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index cfcb223..3ed6ee0 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -60,6 +60,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_PLL0_BASE		0x01c11000
 #define DA8XX_TIMER64P0_BASE	0x01c20000
 #define DA8XX_TIMER64P1_BASE	0x01c21000
+#define DA8XX_PRUSS_BASE	0x01c30000
 #define DA8XX_GPIO_BASE		0x01e26000
 #define DA8XX_PSC1_BASE		0x01e27000
 #define DA8XX_LCD_CNTRL_BASE	0x01e13000
@@ -68,6 +69,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CS2_BASE	0x60000000
 #define DA8XX_AEMIF_CS3_BASE	0x62000000
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
+#define DA8XX_L3RAM_BASE	0x80000000
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
 
@@ -90,6 +92,7 @@ int da850_register_cpufreq(char *async_clk);
 int da8xx_register_cpuidle(void);
 void __iomem * __init da8xx_get_mem_ctlr(void);
 int da850_register_pm(struct platform_device *pdev);
+int da8xx_register_pruss(void);
 
 extern struct platform_device da8xx_serial_device;
 extern struct emac_platform_data da8xx_emac_pdata;
-- 
1.6.0.6


From dedekind1 at gmail.com  Fri Feb 25 02:56:29 2011
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Fri, 25 Feb 2011 10:56:29 +0200
Subject: [PATCH v4 1/2] mtd: NOR flash driver for OMAP-L137/AM17x
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248AAF048@dbde02.ent.ti.com>
References: <1291111325-25784-1-git-send-email-savinay.dharmappa@ti.com>
	<1291261815.14534.14.camel@koala>
	<B85A65D85D7EB246BE421B3FB0FBB5930248AAF048@dbde02.ent.ti.com>
Message-ID: <1298624189.2798.15.camel@localhost>

On Wed, 2011-02-16 at 17:19 +0530, Rajashekhara, Sudhakar wrote:
> Hi,
> 
> On Thu, Dec 02, 2010 at 09:20:15, Artem Bityutskiy wrote:
> > On Tue, 2010-11-30 at 15:32 +0530, Savinay Dharmappa wrote:
> > > From: David Griego <dgriego at mvista.com>
> > > 
> > > OMAP-L137/AM17x has limited number of dedicated EMIFA address pins, 
> > > enough to interface directly to an SDRAM.
> > > If a device such as an asynchronous flash needs to be attached to the 
> > > EMIFA, then either GPIO pins or a chip select may be used to control 
> > > the flash device's upper address lines.
> > > 
> > > This patch adds support for the NOR flash on the OMAP-L137/ AM17x user 
> > > interface daughter board using the latch-addr-flash MTD mapping driver 
> > > which allows flashes to be partially physically addressed. The upper 
> > > address lines are set by a board specific code which is a separate 
> > > patch.
> > > 
> > > Signed-off-by: David Griego <dgriego at mvista.com>
> > > Signed-off-by: Aleksey Makarov <amakarov at ru.mvista.com>
> > > Signed-off-by: Sergei Shtylyov <sshtylyov at ru.mvista.com>
> > > Signed-off-by: Savinay Dharmappa <savinay.dharmappa at ti.com>
> > 
> > Pushed these to l2-mtd-2.6.git, thanks.
> > 
> 
> I do not see these patches in Linus's tree [1] or at l2-mtd-2.6.git tree [2].
> Is there any tree where these patches are available?
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> [2] git://git.infradead.org/users/dedekind/l2-mtd-2.6.git

Hmm, sorry, I do not know how what happened to this patch and where it
was lost. I've just re-added it to my tree. Apologies.

-- 
Best Regards,
Artem Bityutskiy (????? ????????)


From vinay.hegde at ti.com  Fri Feb 25 03:56:28 2011
From: vinay.hegde at ti.com (Hegde, Vinay)
Date: Fri, 25 Feb 2011 15:26:28 +0530
Subject: [PATCH] davinci: da850/omap-l138: Add Carrier Link OK check in
	Davinci RX Handler
Message-ID: <1298627788-32339-1-git-send-email-vinay.hegde@ti.com>

This patch adds an additional check in the Davinci EMAC RX Handler,
which tests the __LINK_STATE_NOCARRIER flag along with the
__LINK_STATE_START flag as part EMAC shutting down procedure.

This avoids
WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf8/0x120()
during rtcwake used to suspend the target for a specified duration.

Signed-off-by: Hegde, Vinay <vinay.hegde at ti.com>
---
 drivers/net/davinci_emac.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 2a628d1..7018bfe 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1008,7 +1008,7 @@ static void emac_rx_handler(void *token, int len, int status)
 	int			ret;
 
 	/* free and bail if we are shutting down */
-	if (unlikely(!netif_running(ndev))) {
+	if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
 		dev_kfree_skb_any(skb);
 		return;
 	}
-- 
1.7.1


From gururaja.hebbar at ti.com  Fri Feb 25 05:21:12 2011
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Fri, 25 Feb 2011 16:51:12 +0530
Subject: Possible bug on davinci spi driver
In-Reply-To: <0F5FCFC9A064004DA46F28981BB330C4013C36736834@BLR2K7EXCL01.symphonysv.com>
References: <0F5FCFC9A064004DA46F28981BB330C4013C36736834@BLR2K7EXCL01.symphonysv.com>
Message-ID: <C82BA3053CFD354AACBD25EFBD2A4EC603EED78E39@dbde02.ent.ti.com>

Hi,

On Thur, Feb 24, 2011 7:09 PM, An?bal Almeida wrote:
> 
> Hi,
> 
> I am using the davinci spi driver [1] on an OMAP L138 board and I think 
> that the driver has a bug.

Just to make sure, are you looking at the current khilman/linux-davinci.git
@ http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=tree

This has a new SPI driver with updated code.
 
> At function davinci_spi_chipselect when using CS of the controller you 
> write on SPI1DAT register the upper 16 bits to one, with exception the 
> bit corresponding to chip select.

Looking at the code, only relevant bits in the SPIDAT1 registers are updated.

#define CS_DEFAULT		0xFF
#define BIT(nr)                 (1UL << (nr))
#define SPIDAT1_CSHOLD_MASK	BIT(12) /* ==> 0x1000 */

In func davinci_spi_chipselect()

	...
	...
	u16 spidat1 = CS_DEFAULT;
	...
	...
		if (value == BITBANG_CS_ACTIVE) {
			spidat1 |= SPIDAT1_CSHOLD_MASK;	 
			/* --> 0xff | 0x1000 = 0x10ff */
			spidat1 &= ~(0x1 << chip_sel);	 
			/* assuming chip select to be 1, 
			0x1 << 1 = 2. ~2 = 0xfffffffd.
			0x10ff & 0xfffffffd = 0x10FD */
		}

		iowrite16(spidat1, dspi->base + SPIDAT1 + 2); 
		/* since it's a 16 bit iowrite,
		 only upper 16 bits of SPIDAT1 i.e.[16-31]
		 are updated. */
	}
 
> The problem is the selection of CSHOLD to one, this is a parameter of 
> spidev and is being wrote without verifying the value that is on the 
> register.

Could you kindly explain a bit more.

[...]
[...]

However, I have a found an issue. 
SPIDAT1 bits 17-16 - CSNR = Chip select number. The value is a multiple 
choice and a not a number.

0 	Both chip select SPIx_SCS[0] and SPIx_SCS[1] are selected.
1h 	Chip select SPIx_SCS[1] is selected only.
2h 	Chip select SPIx_SCS[0] is selected only.
3h 	No chip select is used.

if the user wants to activate the SPIx_SCS[0], he sets the chip_select to 2.

spidat1 &= ~(0x1 << chip_sel);	 

0x1 << 2 = 4. This is invalid entry for CSNR.
This is should be updated to 

#define SPIDAT1_CSNR_MASK	0x3 

spidat1 &= ~(chip_sel & SPIDAT1_CSNR_MASK);	

what is your opinion. If its correct, I can send a patch for the same

Regards, 
Gururaja

From sshtylyov at mvista.com  Fri Feb 25 05:47:34 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 25 Feb 2011 14:47:34 +0300
Subject: [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used
	by PRUSS UIO driver
In-Reply-To: <1298556402-26456-3-git-send-email-pratheesh@ti.com>
References: <1298556402-26456-1-git-send-email-pratheesh@ti.com>
	<1298556402-26456-2-git-send-email-pratheesh@ti.com>
	<1298556402-26456-3-git-send-email-pratheesh@ti.com>
Message-ID: <4D6796D6.5050008@mvista.com>

On 24-02-2011 17:06, Pratheesh Gangadhar wrote:

> This patch defines PRUSS, ECAP clocks, memory and IRQ resources
> used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO

    It's OMAP-L138.

> driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
> DDR buffer to user space. PRUSS has 8 host event interrupt lines
> mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
> with shared memory can be used to implement IPC between ARM9 and
> PRUSS.

> Signed-off-by: Pratheesh Gangadhar<pratheesh at ti.com>
[...]

> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 11f986b..bd85aa3 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
>   		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
>   				ret);
>
> +	ret = da8xx_register_pruss();
> +	if (ret)
> +		pr_warning("da850_evm_init: pruss registration failed: %d\n",
> +				ret);

    Use __func__ to print the function name.

>
>   	ret = da8xx_register_watchdog();
>   	if (ret)

    As I said, please put this into serpate patch.

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 3443d97..0096d4f 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
>   	.flags		= ALWAYS_ENABLED,
>   };
>
> +static struct clk pruss_clk = {
> +	.name		= "pruss",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC0_DMAX,
> +	.flags		= ALWAYS_ENABLED,
> +};
> +

    This conflicts with previously posted patch.

>   static struct clk uart0_clk = {
>   	.name		= "uart0",
>   	.parent		=&pll0_sysclk2,
> @@ -359,6 +366,30 @@ static struct clk usb20_clk = {
>   	.gpsc		= 1,
>   };
>
> +static struct clk ecap0_clk = {
> +	.name		= "ecap0",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC1_ECAP,
> +	.flags		= DA850_CLK_ASYNC3,
> +	.gpsc		= 1,
> +};
> +
> +static struct clk ecap1_clk = {
> +	.name		= "ecap1",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC1_ECAP,
> +	.flags		= DA850_CLK_ASYNC3,
> +	.gpsc		= 1,
> +};
> +
> +static struct clk ecap2_clk = {
> +	.name		= "ecap2",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC1_ECAP,
> +	.flags		= DA850_CLK_ASYNC3,
> +	.gpsc		= 1,
> +};
> +

    This is worth separate patch too...

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index beda8a4..4ea3d1f 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
>
>   	return platform_device_register(&da8xx_cpuidle_device);
>   }
> +static struct resource pruss_resources[] = {
> +	[0] = {
> +		.start  = DA8XX_PRUSS_BASE,
> +		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
> +		.flags  = IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start  = DA8XX_L3RAM_BASE,
> +		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
> +		.flags  = IORESOURCE_MEM,
> +	},
> +	[2] = {
> +		.start  = 0,
> +		.end    = SZ_256K - 1,

    Huh? I don't see where it's filled...

> +		.flags  = IORESOURCE_MEM,
> +	},
> +
[...]
> +int __init da8xx_register_pruss()
> +{
> +	return platform_device_register(&pruss_device);
> +}
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index cfcb223..3ed6ee0 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -60,6 +60,7 @@ extern unsigned int da850_max_speed;
>   #define DA8XX_PLL0_BASE		0x01c11000
>   #define DA8XX_TIMER64P0_BASE	0x01c20000
>   #define DA8XX_TIMER64P1_BASE	0x01c21000
> +#define DA8XX_PRUSS_BASE	0x01c30000
>   #define DA8XX_GPIO_BASE		0x01e26000
>   #define DA8XX_PSC1_BASE		0x01e27000
>   #define DA8XX_LCD_CNTRL_BASE	0x01e13000
> @@ -68,6 +69,7 @@ extern unsigned int da850_max_speed;
>   #define DA8XX_AEMIF_CS2_BASE	0x60000000
>   #define DA8XX_AEMIF_CS3_BASE	0x62000000
>   #define DA8XX_AEMIF_CTL_BASE	0x68000000
> +#define DA8XX_L3RAM_BASE	0x80000000

    There were already patches defining macros for these base addresses...

WBR, Sergei

From sshtylyov at mvista.com  Fri Feb 25 05:55:45 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 25 Feb 2011 14:55:45 +0300
Subject: [PATCH] davinci: da850/omap-l138: Add Carrier Link OK check in
	Davinci RX Handler
In-Reply-To: <1298627788-32339-1-git-send-email-vinay.hegde@ti.com>
References: <1298627788-32339-1-git-send-email-vinay.hegde@ti.com>
Message-ID: <4D6798C1.7090404@mvista.com>

Hello.

On 25-02-2011 12:56, Hegde, Vinay wrote:

    This is not a patch to arch/arm/mach-davinci/, so the summary prefix 
should not be "davinci: da850/omap-l138:" but rather "davinci_emac:" as you're 
patching this driver.

> This patch adds an additional check in the Davinci EMAC RX Handler,
> which tests the __LINK_STATE_NOCARRIER flag along with the
> __LINK_STATE_START flag as part EMAC shutting down procedure.

> This avoids
> WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf8/0x120()
> during rtcwake used to suspend the target for a specified duration.

> Signed-off-by: Hegde, Vinay <vinay.hegde at ti.com>

> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 2a628d1..7018bfe 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -1008,7 +1008,7 @@ static void emac_rx_handler(void *token, int len, int status)
>   	int			ret;
>
>   	/* free and bail if we are shutting down */
> -	if (unlikely(!netif_running(ndev))) {
> +	if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
>   		dev_kfree_skb_any(skb);
>   		return;
>   	}

WBR, Sergei

From anibal.pinto at efacec.com  Fri Feb 25 06:14:59 2011
From: anibal.pinto at efacec.com (=?ISO-8859-1?Q?An=EDbal_Almeida_Pinto?=)
Date: Fri, 25 Feb 2011 12:14:59 +0000
Subject: Possible bug on davinci spi driver
In-Reply-To: <C82BA3053CFD354AACBD25EFBD2A4EC603EED78E39@dbde02.ent.ti.com>
References: <0F5FCFC9A064004DA46F28981BB330C4013C36736834@BLR2K7EXCL01.symphonysv.com>
	<C82BA3053CFD354AACBD25EFBD2A4EC603EED78E39@dbde02.ent.ti.com>
Message-ID: <4D679D43.10908@efacec.com>

Em 25-02-2011 11:21, Hebbar, Gururaja escreveu:
> Hi,
>
> On Thur, Feb 24, 2011 7:09 PM, An?bal Almeida wrote:
>>
>> Hi,
>>
>> I am using the davinci spi driver [1] on an OMAP L138 board and I
>> think that the driver has a bug.
>
> Just to make sure, are you looking at the current
> khilman/linux-davinci.git @
> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=tree
>
>  This has a new SPI driver with updated code.
>
>> At function davinci_spi_chipselect when using CS of the controller
>> you write on SPI1DAT register the upper 16 bits to one, with
>> exception the bit corresponding to chip select.
>
> Looking at the code, only relevant bits in the SPIDAT1 registers are
> updated.
>
> #define CS_DEFAULT		0xFF #define BIT(nr)                 (1UL<<
> (nr)) #define SPIDAT1_CSHOLD_MASK	BIT(12) /* ==>  0x1000 */
>
> In func davinci_spi_chipselect()
>
> ... ... u16 spidat1 = CS_DEFAULT; ... ... if (value ==
> BITBANG_CS_ACTIVE) { spidat1 |= SPIDAT1_CSHOLD_MASK; /* -->  0xff |
> 0x1000 = 0x10ff */ spidat1&= ~(0x1<<  chip_sel); /* assuming chip
> select to be 1, 0x1<<  1 = 2. ~2 = 0xfffffffd. 0x10ff&  0xfffffffd =
> 0x10FD */ }
>
> iowrite16(spidat1, dspi->base + SPIDAT1 + 2); /* since it's a 16 bit
> iowrite, only upper 16 bits of SPIDAT1 i.e.[16-31] are updated. */ }
>
>> The problem is the selection of CSHOLD to one, this is a parameter
>> of spidev and is being wrote without verifying the value that is on
>> the register.
>
> Could you kindly explain a bit more.

I have misunderstood the code ... but I think that this isn't write.

If you want to select CS_HOLD to 1 when using the spidev interface, this 
will overwrite your choice.

Other option that is forced is wdelay = 0, that is on bit 28.

The SPIDA1 register don't need to be read and after apply the 
modifications or only write the chip select ?

> [...] [...]
>
> However, I have a found an issue. SPIDAT1 bits 17-16 - CSNR = Chip
> select number. The value is a multiple choice and a not a number.
>
> 0 	Both chip select SPIx_SCS[0] and SPIx_SCS[1] are selected. 1h
> Chip select SPIx_SCS[1] is selected only. 2h 	Chip select SPIx_SCS[0]
> is selected only. 3h 	No chip select is used.
>
> if the user wants to activate the SPIx_SCS[0], he sets the
> chip_select to 2.
>
> spidat1&= ~(0x1<<  chip_sel);
>
> 0x1<<  2 = 4. This is invalid entry for CSNR. This is should be
> updated to
>
> #define SPIDAT1_CSNR_MASK	0x3
>
> spidat1&= ~(chip_sel&  SPIDAT1_CSNR_MASK);
>
> what is your opinion. If its correct, I can send a patch for the
> same

On OMAP-L138 you have 8 CS on SPI1, this will work for all the options ?

 From the data sheet you can have multiple chip select selected on a 
transfer but with this driver that isn't possible.


From cyril at ti.com  Fri Feb 25 07:16:18 2011
From: cyril at ti.com (Cyril Chemparathy)
Date: Fri, 25 Feb 2011 08:16:18 -0500
Subject: [PATCH] davinci: da850/omap-l138: Add Carrier Link OK check in
	Davinci RX Handler
In-Reply-To: <1298627788-32339-1-git-send-email-vinay.hegde@ti.com>
References: <1298627788-32339-1-git-send-email-vinay.hegde@ti.com>
Message-ID: <4D67ABA2.6060808@ti.com>

On 02/25/2011 04:56 AM, Hegde, Vinay wrote:
> This patch adds an additional check in the Davinci EMAC RX Handler,
> which tests the __LINK_STATE_NOCARRIER flag along with the
> __LINK_STATE_START flag as part EMAC shutting down procedure.
> 
> This avoids
> WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf8/0x120()
> during rtcwake used to suspend the target for a specified duration.
> 
> Signed-off-by: Hegde, Vinay <vinay.hegde at ti.com>
> ---
>  drivers/net/davinci_emac.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 2a628d1..7018bfe 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -1008,7 +1008,7 @@ static void emac_rx_handler(void *token, int len, int status)
>  	int			ret;
>  
>  	/* free and bail if we are shutting down */
> -	if (unlikely(!netif_running(ndev))) {
> +	if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
>  		dev_kfree_skb_any(skb);
>  		return;
>  	}

Looks ok.

Acked-by: Cyril Chemparathy <cyril at ti.com>

From sshtylyov at mvista.com  Fri Feb 25 07:22:02 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Fri, 25 Feb 2011 16:22:02 +0300
Subject: [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used
	by PRUSS UIO driver
In-Reply-To: <20110225130241.GA2791@local>
References: <1298556402-26456-1-git-send-email-pratheesh@ti.com>
	<1298556402-26456-2-git-send-email-pratheesh@ti.com>
	<1298556402-26456-3-git-send-email-pratheesh@ti.com>
	<4D6796D6.5050008@mvista.com> <20110225130241.GA2791@local>
Message-ID: <4D67ACFA.4090600@mvista.com>

Hello.

On 25-02-2011 16:02, Hans J. Koch wrote:

>>> This patch defines PRUSS, ECAP clocks, memory and IRQ resources
>>> used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO

>>     It's OMAP-L138.

> From the TI wiki: "The PRU subsystem is supported on
> OMAP-L1x8/C674m/AM18xx devices (where m is an even number)."

> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem

    I meant there's a typo in "OMAPL1-38".

> Thanks,
> Hans

WBR, Sergei

From nsekhar at ti.com  Fri Feb 25 09:36:04 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 25 Feb 2011 21:06:04 +0530
Subject: [PATCH] DA850 EVM: kill useless variable
In-Reply-To: <201102071845.37812.sshtylyov@ru.mvista.com>
References: <201102071845.37812.sshtylyov@ru.mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BE49F47@dbde02.ent.ti.com>

Hi Sergei,

On Mon, Feb 07, 2011 at 21:15:37, Sergei Shtylyov wrote:
> Commit 75e2ea643fe43d5aa836475acee5bd97cd9ea4bf (davinci: DA850/OMAP-L138 EVM
> expander setup and UI card detection) introduced a useless variable: it's
> always set to 1 before it's checked in da850_evm_setup_nor_nand()...

Added this patch in queue for 2.6.39. Added a "davinci: " prefix to
the subject line.

Thanks,
Sekhar

From subhasish at mistralsolutions.com  Sat Feb 26 06:12:39 2011
From: subhasish at mistralsolutions.com (Subhasish Ghosh)
Date: Sat, 26 Feb 2011 17:42:39 +0530
Subject: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BE49711@dbde02.ent.ti.com>
References: <1297434088-27995-1-git-send-email-subhasish@mistralsolutions.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BE49175@dbde02.ent.ti.com>
	<886E26C48DE446C3937D89ECF86030B2@subhasishg>
	<B85A65D85D7EB246BE421B3FB0FBB593024BE49711@dbde02.ent.ti.com>
Message-ID: <25DBF349769A4CF7B883D6D7FF01AD70@subhasishg>

Hi Sekhar,

I tried this using MMC and Kelvin's suggestions, but it never came back. 
Here is a log:

root at arago:~# rtcwake -d /dev/rtc0 -s 20 -m mem
wakeup from "mem" at Tue Apr 21 14:31:13 2009
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)

>From the Kconfig I had enabled RTC_DRV_OMAP, CONFIG_PM, CONFIG_SUSPEND.

--------------------------------------------------
From: "Nori, Sekhar" <nsekhar at ti.com>
Sent: Thursday, February 24, 2011 4:57 PM
To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>; 
<davinci-linux-open-source at linux.davincidsp.com>
Cc: <linux-arm-kernel at lists.infradead.org>; "Watkins, Melissa" 
<m-watkins at ti.com>; <sachi at mistralsolutions.com>; "Kevin Hilman" 
<khilman at deeprootsystems.com>; "Russell King" <linux at arm.linux.org.uk>; 
"Michael Williamson" <michael.williamson at criticallink.com>; "Chemparathy, 
Cyril" <cyril at ti.com>; "Sergei Shtylyov" <sshtylyov at ru.mvista.com>; "open 
list" <linux-kernel at vger.kernel.org>
Subject: RE: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.

> Hi Subhasish,
>
> On Thu, Feb 24, 2011 at 15:54:56, Subhasish Ghosh wrote:
>> --------------------------------------------------
>> From: "Nori, Sekhar" <nsekhar at ti.com>
>> Sent: Wednesday, February 23, 2011 9:00 PM
>> To: "Subhasish Ghosh" <subhasish at mistralsolutions.com>;
>> <davinci-linux-open-source at linux.davincidsp.com>
>> Cc: <linux-arm-kernel at lists.infradead.org>; "Watkins, Melissa"
>> <m-watkins at ti.com>; <sachi at mistralsolutions.com>; "Kevin Hilman"
>> <khilman at deeprootsystems.com>; "Russell King" <linux at arm.linux.org.uk>;
>> "Michael Williamson" <michael.williamson at criticallink.com>; "Chemparathy,
>> Cyril" <cyril at ti.com>; "Sergei Shtylyov" <sshtylyov at ru.mvista.com>; "open
>> list" <linux-kernel at vger.kernel.org>
>> Subject: RE: [PATCH 1/1] davinci: changed SRAM allocator to shared ram.
>>
>> > Hi Subhasish,
>> >
>> > On Fri, Feb 11, 2011 at 19:51:28, Subhasish Ghosh wrote:
>> >> This patch modifies the sram allocator to allocate memory
>> >> from the DA8XX shared RAM.
>> >
>> > It will be nice to know if you tried suspend-to-RAM
>> > after this change and found it to be working.
>> >
>>
>> SG -- My file system is currently mounted from MMC.
>>           Suspend to RAM seems to have bug with MMC.
>> 
>> (http://processors.wiki.ti.com/index.php/OMAP-L1_Linux_Drivers_Usage#Suspend-to-RAM)
>
> You can try Kevin's suggestion here:
>
> http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-January/021807.html
>
>>           I had tried NFS earlier, but I think there is some problem with
>> NFS boot and udev with this kernel.
>
> Anyway there are some problems reported with Ethernet
> driver and suspend on the latest kernel. Folks inside
> TI are working on it.
>
>>            So, currently I will not be able to do it, but will try if I 
>> get
>> a chance.
>
> How about using ramdisk?
>
> Thanks,
> Sekhar
>
>> > Thanks,
>> > Sekhar
>> >
>> >>
>> >> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
>> >> ---
>> >>  arch/arm/mach-davinci/da850.c              |    6 +++---
>> >>  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
>> >>  2 files changed, 4 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-davinci/da850.c
>> >> b/arch/arm/mach-davinci/da850.c
>> >> index 3443d97..8a4de97 100644
>> >> --- a/arch/arm/mach-davinci/da850.c
>> >> +++ b/arch/arm/mach-davinci/da850.c
>> >> @@ -711,7 +711,7 @@ static struct map_desc da850_io_desc[] = {
>> >>  },
>> >>  {
>> >>  .virtual = SRAM_VIRT,
>> >> - .pfn = __phys_to_pfn(DA8XX_ARM_RAM_BASE),
>> >> + .pfn = __phys_to_pfn(DA8XX_SHARED_RAM_BASE),
>> >>  .length = SZ_8K,
>> >>  .type = MT_DEVICE
>> >>  },
>> >> @@ -1083,8 +1083,8 @@ static struct davinci_soc_info
>> >> davinci_soc_info_da850 = {
>> >>  .gpio_irq = IRQ_DA8XX_GPIO0,
>> >>  .serial_dev = &da8xx_serial_device,
>> >>  .emac_pdata = &da8xx_emac_pdata,
>> >> - .sram_dma = DA8XX_ARM_RAM_BASE,
>> >> - .sram_len = SZ_8K,
>> >> + .sram_dma = DA8XX_SHARED_RAM_BASE,
>> >> + .sram_len = SZ_128K,
>> >>  .reset_device = &da8xx_wdt_device,
>> >>  };
>> >>
>> >> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
>> >> b/arch/arm/mach-davinci/include/mach/da8xx.h
>> >> index cfcb223..c3c3339 100644
>> >> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
>> >> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
>> >> @@ -70,6 +70,7 @@ extern unsigned int da850_max_speed;
>> >>  #define DA8XX_AEMIF_CTL_BASE 0x68000000
>> >>  #define DA8XX_DDR2_CTL_BASE 0xb0000000
>> >>  #define DA8XX_ARM_RAM_BASE 0xffff0000
>> >> +#define DA8XX_SHARED_RAM_BASE 0x80000000
>> >>
>> >>  void __init da830_init(void);
>> >>  void __init da850_init(void);
>> >> -- 
>> >> 1.7.2.3
>> >>
>> >>
>> >
>>
> 

From pratheesh at ti.com  Sun Feb 27 22:02:54 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Mon, 28 Feb 2011 09:32:54 +0530
Subject: [PATCH v5 1/2] PRUSS UIO driver support
In-Reply-To: <alpine.LFD.2.00.1102251049090.2701@localhost6.localdomain6>
References: <1298623530-10294-1-git-send-email-pratheesh@ti.com>
	<1298623530-10294-2-git-send-email-pratheesh@ti.com>
	<alpine.LFD.2.00.1102251049090.2701@localhost6.localdomain6>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BF358B3@dbde02.ent.ti.com>

Hi,

> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx at linutronix.de]
> Sent: Friday, February 25, 2011 3:24 PM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; hjk at hansjkoch.de;
> gregkh at suse.de; sshtylyov at mvista.com; arnd at arndb.de; Chatterjee, Amit;
> linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH v5 1/2] PRUSS UIO driver support
> 
> On Fri, 25 Feb 2011, Pratheesh Gangadhar wrote:
> > +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> > +{
> > +	void __iomem *base = dev_info->mem[0].internal_addr;
> > +	void __iomem *intren_reg = base + PINTC_HIER;
> > +	void __iomem *intrstat_reg = base + PINTC_HIPIR + ((irq - 1) << 2);
> > +	int val = ioread32(intren_reg), intr_mask = (1 << (irq - 1));
> > +
> > +	/* Is interrupt enabled and active ? */
> > +	if (!(val & intr_mask) && (ioread32(intrstat_reg) & HIPIR_NOPEND))
> > +		return IRQ_NONE;
> > +
> > +	/* Disable interrupt */
> > +	iowrite32((val & ~intr_mask), intren_reg);
> > +	return IRQ_HANDLED;
> > +}
> 
> Hmm, just noticed, that you fiddle with the interrupt enable register
> here totally unprotected. So on a SMP system you might haandle two
> different interrupts at the same time. That wants locking.
> 
> And even on UP, you have a problem as you reenable that thing from
> user space which requires a read modify write. Racy as hell.
> 
> Please look at the other UIO drivers which have the same problem.
> Sorry for not noticing earlier!

Thanks for pointing this out. Yes - this is a problem especially since we have more than one interrupt for PRUSS which is enabled/disabled in this register. I will fix this and resubmit along with fixes addressing Sergei's comments on platform specific portion.

Thanks,
Pratheesh


From pratheesh at ti.com  Sun Feb 27 22:46:18 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Mon, 28 Feb 2011 10:16:18 +0530
Subject: [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources
	used by PRUSS UIO driver
In-Reply-To: <4D6796D6.5050008@mvista.com>
References: <1298556402-26456-1-git-send-email-pratheesh@ti.com>
	<1298556402-26456-2-git-send-email-pratheesh@ti.com>
	<1298556402-26456-3-git-send-email-pratheesh@ti.com>
	<4D6796D6.5050008@mvista.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BF3591A@dbde02.ent.ti.com>

Hi,

> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov at mvista.com]
> Sent: Friday, February 25, 2011 5:18 PM
> To: TK, Pratheesh Gangadhar
> Cc: davinci-linux-open-source at linux.davincidsp.com; hjk at hansjkoch.de;
> gregkh at suse.de; tglx at linutronix.de; arnd at arndb.de; Chatterjee, Amit;
> linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources
> used by PRUSS UIO driver
> 
> On 24-02-2011 17:06, Pratheesh Gangadhar wrote:
> 
> > This patch defines PRUSS, ECAP clocks, memory and IRQ resources
> > used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO
> 
>     It's OMAP-L138.
Ok.
> 
> > driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
> > DDR buffer to user space. PRUSS has 8 host event interrupt lines
> > mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
> > with shared memory can be used to implement IPC between ARM9 and
> > PRUSS.
> 
> > Signed-off-by: Pratheesh Gangadhar<pratheesh at ti.com>
> [...]
> 
> > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-
> davinci/board-da850-evm.c
> > index 11f986b..bd85aa3 100644
> > --- a/arch/arm/mach-davinci/board-da850-evm.c
> > +++ b/arch/arm/mach-davinci/board-da850-evm.c
> > @@ -1077,6 +1077,10 @@ static __init void da850_evm_init(void)
> >   		pr_warning("da850_evm_init: i2c0 registration failed: %d\n",
> >   				ret);
> >
> > +	ret = da8xx_register_pruss();
> > +	if (ret)
> > +		pr_warning("da850_evm_init: pruss registration failed: %d\n",
> > +				ret);
> 
>     Use __func__ to print the function name.
> 
> >
> >   	ret = da8xx_register_watchdog();
> >   	if (ret)
> 
>     As I said, please put this into serpate patch.
> 
Ok, will do.
> > diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-
> davinci/da850.c
> > index 3443d97..0096d4f 100644
> > --- a/arch/arm/mach-davinci/da850.c
> > +++ b/arch/arm/mach-davinci/da850.c
> > @@ -238,6 +238,13 @@ static struct clk tptc2_clk = {
> >   	.flags		= ALWAYS_ENABLED,
> >   };
> >
> > +static struct clk pruss_clk = {
> > +	.name		= "pruss",
> > +	.parent		= &pll0_sysclk2,
> > +	.lpsc		= DA8XX_LPSC0_DMAX,
> > +	.flags		= ALWAYS_ENABLED,
> > +};
> > +
> 
>     This conflicts with previously posted patch.
> 
Ok, shall I rename to align with previous patch from Mistral or drop this from my patchset ?
> >   static struct clk uart0_clk = {
> >   	.name		= "uart0",
> >   	.parent		=&pll0_sysclk2,
> > @@ -359,6 +366,30 @@ static struct clk usb20_clk = {
> >   	.gpsc		= 1,
> >   };
> >
> > +static struct clk ecap0_clk = {
> > +	.name		= "ecap0",
> > +	.parent		= &pll0_sysclk2,
> > +	.lpsc		= DA8XX_LPSC1_ECAP,
> > +	.flags		= DA850_CLK_ASYNC3,
> > +	.gpsc		= 1,
> > +};
> > +
> > +static struct clk ecap1_clk = {
> > +	.name		= "ecap1",
> > +	.parent		= &pll0_sysclk2,
> > +	.lpsc		= DA8XX_LPSC1_ECAP,
> > +	.flags		= DA850_CLK_ASYNC3,
> > +	.gpsc		= 1,
> > +};
> > +
> > +static struct clk ecap2_clk = {
> > +	.name		= "ecap2",
> > +	.parent		= &pll0_sysclk2,
> > +	.lpsc		= DA8XX_LPSC1_ECAP,
> > +	.flags		= DA850_CLK_ASYNC3,
> > +	.gpsc		= 1,
> > +};
> > +
> 
>     This is worth separate patch too...
> 
Ok.
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-
> davinci/devices-da8xx.c
> > index beda8a4..4ea3d1f 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
> >
> >   	return platform_device_register(&da8xx_cpuidle_device);
> >   }
> > +static struct resource pruss_resources[] = {
> > +	[0] = {
> > +		.start  = DA8XX_PRUSS_BASE,
> > +		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
> > +		.flags  = IORESOURCE_MEM,
> > +	},
> > +	[1] = {
> > +		.start  = DA8XX_L3RAM_BASE,
> > +		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
> > +		.flags  = IORESOURCE_MEM,
> > +	},
> > +	[2] = {
> > +		.start  = 0,
> > +		.end    = SZ_256K - 1,
> 
>     Huh? I don't see where it's filled...
> 
The current use is only to indicate memory block size to the PRUSS UIO driver when we allocate DDR memory using dma_alloc_coherent. sram_alloc is changed to use L3_RAM (128KB) instead of ARM RAM (8KB) in Mistral patch set - I need to follow the same convention for L3 RAM as well if I need to align with that patch. Is there a better way to do this?
> > +		.flags  = IORESOURCE_MEM,
> > +	},
> > +
> [...]
> > +int __init da8xx_register_pruss()
> > +{
> > +	return platform_device_register(&pruss_device);
> > +}
> > diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-
> davinci/include/mach/da8xx.h
> > index cfcb223..3ed6ee0 100644
> > --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> > +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> > @@ -60,6 +60,7 @@ extern unsigned int da850_max_speed;
> >   #define DA8XX_PLL0_BASE		0x01c11000
> >   #define DA8XX_TIMER64P0_BASE	0x01c20000
> >   #define DA8XX_TIMER64P1_BASE	0x01c21000
> > +#define DA8XX_PRUSS_BASE	0x01c30000
> >   #define DA8XX_GPIO_BASE		0x01e26000
> >   #define DA8XX_PSC1_BASE		0x01e27000
> >   #define DA8XX_LCD_CNTRL_BASE	0x01e13000
> > @@ -68,6 +69,7 @@ extern unsigned int da850_max_speed;
> >   #define DA8XX_AEMIF_CS2_BASE	0x60000000
> >   #define DA8XX_AEMIF_CS3_BASE	0x62000000
> >   #define DA8XX_AEMIF_CTL_BASE	0x68000000
> > +#define DA8XX_L3RAM_BASE	0x80000000
> 
>     There were already patches defining macros for these base addresses...
>
Ok - will align with this.

Thanks,
Pratheesh

From nsekhar at ti.com  Mon Feb 28 01:02:09 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 28 Feb 2011 12:32:09 +0530
Subject: Possible bug on davinci spi driver
In-Reply-To: <C82BA3053CFD354AACBD25EFBD2A4EC603EED78E39@dbde02.ent.ti.com>
References: <0F5FCFC9A064004DA46F28981BB330C4013C36736834@BLR2K7EXCL01.symphonysv.com>
	<C82BA3053CFD354AACBD25EFBD2A4EC603EED78E39@dbde02.ent.ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BF35AC6@dbde02.ent.ti.com>

Hi Gururaja,

On Fri, Feb 25, 2011 at 16:51:12, Hebbar, Gururaja wrote:

> However, I have a found an issue. 
> SPIDAT1 bits 17-16 - CSNR = Chip select number. The value is a multiple 
> choice and a not a number.
> 
> 0 	Both chip select SPIx_SCS[0] and SPIx_SCS[1] are selected.
> 1h 	Chip select SPIx_SCS[1] is selected only.
> 2h 	Chip select SPIx_SCS[0] is selected only.
> 3h 	No chip select is used.

In short, if you need CS# N to go low (become active), you make
sure bit number N within the CSNR bitfield is 0. Rest of the
bits should be high (as only one chipselect can be active at a
time).

> 
> if the user wants to activate the SPIx_SCS[0], he sets the chip_select to 2.

Why? I think he would pass 0.

> 
> spidat1 &= ~(0x1 << chip_sel);	 
> 
> 0x1 << 2 = 4. This is invalid entry for CSNR.
> This is should be updated to 
> 
> #define SPIDAT1_CSNR_MASK	0x3 
> 
> spidat1 &= ~(chip_sel & SPIDAT1_CSNR_MASK);	
> 
> what is your opinion. If its correct, I can send a patch for the same

Not sure what the issue is, still.

Thanks,
Sekhar


From vinay.hegde at ti.com  Mon Feb 28 02:15:20 2011
From: vinay.hegde at ti.com (Hegde, Vinay)
Date: Mon, 28 Feb 2011 13:45:20 +0530
Subject: [PATCH v2] davinci_emac: Add Carrier Link OK check in Davinci RX
	Handler
Message-ID: <1298880920-22715-1-git-send-email-vinay.hegde@ti.com>

This patch adds an additional check in the Davinci EMAC RX Handler,
which tests the __LINK_STATE_NOCARRIER flag along with the
__LINK_STATE_START flag as part EMAC shutting down procedure.

This avoids
WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf8/0x120()
during rtcwake used to suspend the target for a specified duration.

Signed-off-by: Hegde, Vinay <vinay.hegde at ti.com>
Acked-by: Cyril Chemparathy <cyril at ti.com>
---
since v1: Changed the subject line

 drivers/net/davinci_emac.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 2a628d1..7018bfe 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1008,7 +1008,7 @@ static void emac_rx_handler(void *token, int len, int status)
 	int			ret;
 
 	/* free and bail if we are shutting down */
-	if (unlikely(!netif_running(ndev))) {
+	if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
 		dev_kfree_skb_any(skb);
 		return;
 	}
-- 
1.7.1


From gururaja.hebbar at ti.com  Mon Feb 28 03:13:18 2011
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Mon, 28 Feb 2011 14:43:18 +0530
Subject: Possible bug on davinci spi driver
In-Reply-To: <4D679D43.10908@efacec.com>
References: <0F5FCFC9A064004DA46F28981BB330C4013C36736834@BLR2K7EXCL01.symphonysv.com>
	<C82BA3053CFD354AACBD25EFBD2A4EC603EED78E39@dbde02.ent.ti.com>
	<4D679D43.10908@efacec.com>
Message-ID: <C82BA3053CFD354AACBD25EFBD2A4EC603EED79149@dbde02.ent.ti.com>

Hi,

On Fri, Feb 25, 2011 at 17:44:59, An?bal Almeida Pinto wrote:
> Em 25-02-2011 11:21, Hebbar, Gururaja escreveu:
> > Hi,
> >
> > On Thur, Feb 24, 2011 7:09 PM, An?bal Almeida wrote:
> >>
> >> Hi,
> >>
> >> I am using the davinci spi driver [1] on an OMAP L138 board and I
> >> think that the driver has a bug.
> >
> > Just to make sure, are you looking at the current
> > khilman/linux-davinci.git @
> > http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=tree
> >
> >  This has a new SPI driver with updated code.
> >
> >> At function davinci_spi_chipselect when using CS of the controller
> >> you write on SPI1DAT register the upper 16 bits to one, with
> >> exception the bit corresponding to chip select.
> >
> > Looking at the code, only relevant bits in the SPIDAT1 registers are
> > updated.
> >
> > #define CS_DEFAULT		0xFF #define BIT(nr)                 (1UL<<
> > (nr)) #define SPIDAT1_CSHOLD_MASK	BIT(12) /* ==>  0x1000 */
> >
> > In func davinci_spi_chipselect()
> >
> > ... ... u16 spidat1 = CS_DEFAULT; ... ... if (value ==
> > BITBANG_CS_ACTIVE) { spidat1 |= SPIDAT1_CSHOLD_MASK; /* -->  0xff |
> > 0x1000 = 0x10ff */ spidat1&= ~(0x1<<  chip_sel); /* assuming chip
> > select to be 1, 0x1<<  1 = 2. ~2 = 0xfffffffd. 0x10ff&  0xfffffffd =
> > 0x10FD */ }
> >
> > iowrite16(spidat1, dspi->base + SPIDAT1 + 2); /* since it's a 16 bit
> > iowrite, only upper 16 bits of SPIDAT1 i.e.[16-31] are updated. */ }
> >
> >> The problem is the selection of CSHOLD to one, this is a parameter
> >> of spidev and is being wrote without verifying the value that is on
> >> the register.
> >
> > Could you kindly explain a bit more.
> 
> I have misunderstood the code ... but I think that this isn't write.
> 
> If you want to select CS_HOLD to 1 when using the spidev interface, this 
> will overwrite your choice.

The option to setup the cs_hold existed in the old code. An updated code
exists @ http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=tree
The option to change cs_hold value have been removed.

 
> Other option that is forced is wdelay = 0, that is on bit 28.

In SPIDAT1 Register
Bit 28 is CSHOLD - Chip select hold mode &
Bit 26 is WDEL - Enable the delay counter at the end of the current transaction.

In SPIFMTn Register
Bit 29-24 = WDELAY - Delay in between transmissions.
WDELAY is valid only when WDEL bit in SPIDAT1 is 1. However current driver doesn't set 
WDEL to 1 and hence WDELAY is not considered.

> The SPIDA1 register don't need to be read and after apply the 
> modifications or only write the chip select ?

SPIDAT1 register contains both data to be transmitted & flags. Earlier driver 
had a bug related to duplicate data being sent when updating the flags. In the 
latest Driver, flags and data are written separately. 
 

> > [...] [...]
> >
> > However, I have a found an issue. SPIDAT1 bits 17-16 - CSNR = Chip
> > select number. The value is a multiple choice and a not a number.
> >
> > 0 	Both chip select SPIx_SCS[0] and SPIx_SCS[1] are selected. 1h
> > Chip select SPIx_SCS[1] is selected only. 2h 	Chip select SPIx_SCS[0]
> > is selected only. 3h 	No chip select is used.
> >
> > if the user wants to activate the SPIx_SCS[0], he sets the
> > chip_select to 2.
> >
> > spidat1&= ~(0x1<<  chip_sel);
> >
> > 0x1<<  2 = 4. This is invalid entry for CSNR. This is should be
> > updated to
> >
> > #define SPIDAT1_CSNR_MASK	0x3
> >
> > spidat1&= ~(chip_sel&  SPIDAT1_CSNR_MASK);
> >
> > what is your opinion. If its correct, I can send a patch for the
> > same


> On OMAP-L138 you have 8 CS on SPI1, this will work for all the options ?

Yes, you are correct. For OMAP-L138 this code is correct. 

>  From the data sheet you can have multiple chip select selected on a 
> transfer but with this driver that isn't possible.

davinci spi driver is designed to handle one device at a time. So only one device can 
be enabled at any given time. 


Regards, 
Gururaja

From nsekhar at ti.com  Mon Feb 28 04:08:38 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 28 Feb 2011 15:38:38 +0530
Subject: [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources
	used by PRUSS UIO driver
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BF3591A@dbde02.ent.ti.com>
References: <1298556402-26456-1-git-send-email-pratheesh@ti.com>
	<1298556402-26456-2-git-send-email-pratheesh@ti.com>
	<1298556402-26456-3-git-send-email-pratheesh@ti.com>
	<4D6796D6.5050008@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BF3591A@dbde02.ent.ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BF35C6E@dbde02.ent.ti.com>

Hi Pratheesh,

On Mon, Feb 28, 2011 at 10:16:18, TK, Pratheesh Gangadhar wrote:

> > > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-
> > davinci/devices-da8xx.c
> > > index beda8a4..4ea3d1f 100644
> > > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > > @@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
> > >
> > >   	return platform_device_register(&da8xx_cpuidle_device);
> > >   }
> > > +static struct resource pruss_resources[] = {
> > > +	[0] = {
> > > +		.start  = DA8XX_PRUSS_BASE,
> > > +		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
> > > +		.flags  = IORESOURCE_MEM,
> > > +	},
> > > +	[1] = {
> > > +		.start  = DA8XX_L3RAM_BASE,
> > > +		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
> > > +		.flags  = IORESOURCE_MEM,
> > > +	},
> > > +	[2] = {
> > > +		.start  = 0,
> > > +		.end    = SZ_256K - 1,
> > 
> >     Huh? I don't see where it's filled...
> > 
> The current use is only to indicate memory block size to the PRUSS UIO 
> driver when we allocate DDR memory using dma_alloc_coherent.

If the user/platform needs to specify the amount of memory that
will be allocated by the driver, it can be done though platform
data or (better) using module params.

> sram_alloc is changed to use L3_RAM (128KB) instead of ARM RAM (8KB) in 
> Mistral patch set - I need to follow the same convention for L3 RAM as well 
> if I need to align with that patch. Is there a better way to do this?

Yes, with that patch sram_alloc() will allocate from L3 RAM. You can make
calls to sram_alloc() in your driver. Again the size to be allocated can
be platform data or module params.

Thanks,
Sekhar


From sshtylyov at mvista.com  Mon Feb 28 04:27:34 2011
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Mon, 28 Feb 2011 13:27:34 +0300
Subject: [PATCH v4 2/2] Defines DA850/AM18xx/OMAPL1-38 SOC resources used
	by PRUSS UIO driver
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BF3591A@dbde02.ent.ti.com>
References: <1298556402-26456-1-git-send-email-pratheesh@ti.com>
	<1298556402-26456-2-git-send-email-pratheesh@ti.com>
	<1298556402-26456-3-git-send-email-pratheesh@ti.com>
	<4D6796D6.5050008@mvista.com>
	<B85A65D85D7EB246BE421B3FB0FBB593024BF3591A@dbde02.ent.ti.com>
Message-ID: <4D6B7896.6000703@mvista.com>

Hello.

On 28-02-2011 7:46, TK, Pratheesh Gangadhar wrote:

>>> This patch defines PRUSS, ECAP clocks, memory and IRQ resources
>>> used by PRUSS UIO driver in DA850/AM18xx/OMAPL1-38 devices. UIO

>>      It's OMAP-L138.
> Ok.

>>> driver exports 64K I/O region of PRUSS, 128KB L3 RAM and 256KB
>>> DDR buffer to user space. PRUSS has 8 host event interrupt lines
>>> mapped to IRQ_DA8XX_EVTOUT0..7 of ARM9 INTC.These in conjunction
>>> with shared memory can be used to implement IPC between ARM9 and
>>> PRUSS.

>>> Signed-off-by: Pratheesh Gangadhar<pratheesh at ti.com>

[...]

>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-
>> davinci/devices-da8xx.c
>>> index beda8a4..4ea3d1f 100644
>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>> @@ -725,3 +725,76 @@ int __init da8xx_register_cpuidle(void)
>>>
>>>    	return platform_device_register(&da8xx_cpuidle_device);
>>>    }
>>> +static struct resource pruss_resources[] = {
>>> +	[0] = {
>>> +		.start  = DA8XX_PRUSS_BASE,
>>> +		.end    = DA8XX_PRUSS_BASE + SZ_64K - 1,
>>> +		.flags  = IORESOURCE_MEM,
>>> +	},
>>> +	[1] = {
>>> +		.start  = DA8XX_L3RAM_BASE,
>>> +		.end    = DA8XX_L3RAM_BASE + SZ_128K - 1,
>>> +		.flags  = IORESOURCE_MEM,
>>> +	},
>>> +	[2] = {
>>> +		.start  = 0,
>>> +		.end    = SZ_256K - 1,

>>      Huh? I don't see where it's filled...

> The current use is only to indicate memory block size to the PRUSS UIO driver when we allocate DDR memory using dma_alloc_coherent.

    Why not pass this size via the platform data? There shouldn't be "dummy" 
resources.

> sram_alloc is changed to use L3_RAM (128KB) instead of ARM RAM (8KB) in Mistral patch set - I need to follow the same convention
 > for L3 RAM as well if I need to align with that patch. Is there a better 
way to do this?

    Didn't understand about L3 RAM.
    Also, please wrap your text at 80 columns.

WBR, Sergei

From nsekhar at ti.com  Mon Feb 28 06:34:32 2011
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 28 Feb 2011 18:04:32 +0530
Subject: [PATCH v8 03/11] gpio: add ti-ssp gpio driver
In-Reply-To: <1295378505-15221-4-git-send-email-cyril@ti.com>
References: <1295378505-15221-1-git-send-email-cyril@ti.com>
	<1295378505-15221-4-git-send-email-cyril@ti.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BF35DAF@dbde02.ent.ti.com>

Hi Grant,

On Wed, Jan 19, 2011 at 00:51:37, Chemparathy, Cyril wrote:
> TI's SSP controller pins can be directly read and written to behave like a
> GPIO.  This patch adds a GPIO driver that exposes such functionality.

Can you please review and ack the GPIO part of this
series too?

I see that you have already acked the SPI part of this work.

Thanks,
Sekhar

> 
> Signed-off-by: Cyril Chemparathy <cyril at ti.com>
> ---
>  drivers/gpio/Kconfig       |   10 ++
>  drivers/gpio/Makefile      |    1 +
>  drivers/gpio/ti-ssp-gpio.c |  207 ++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/mfd/ti_ssp.h |    4 +
>  4 files changed, 222 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/gpio/ti-ssp-gpio.c
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 3143ac7..05bbe4c 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -128,6 +128,16 @@ config GPIO_VX855
>  	  additional drivers must be enabled in order to use the
>  	  functionality of the device.
>  
> +config GPIO_TI_SSP
> +	tristate "TI Sequencer Serial Port - GPIO Support"
> +	depends on MFD_TI_SSP
> +	help
> +	  Say yes here to support a GPIO interface on TI SSP port pins.
> +	  Each SSP port translates into 4 GPIOs.
> +
> +	  This driver can also be built as a module. If so, the module
> +	  will be called ti-ssp-gpio.
> +
>  comment "I2C GPIO expanders:"
>  
>  config GPIO_MAX7300
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index bdf3dde..0e2a844 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_GPIO_PL061)	+= pl061.o
>  obj-$(CONFIG_GPIO_STMPE)	+= stmpe-gpio.o
>  obj-$(CONFIG_GPIO_TC35892)	+= tc35892-gpio.o
>  obj-$(CONFIG_GPIO_TIMBERDALE)	+= timbgpio.o
> +obj-$(CONFIG_GPIO_TI_SSP)	+= ti-ssp-gpio.o
>  obj-$(CONFIG_GPIO_TWL4030)	+= twl4030-gpio.o
>  obj-$(CONFIG_GPIO_UCB1400)	+= ucb1400_gpio.o
>  obj-$(CONFIG_GPIO_XILINX)	+= xilinx_gpio.o
> diff --git a/drivers/gpio/ti-ssp-gpio.c b/drivers/gpio/ti-ssp-gpio.c
> new file mode 100644
> index 0000000..edc3142
> --- /dev/null
> +++ b/drivers/gpio/ti-ssp-gpio.c
> @@ -0,0 +1,207 @@
> +/*
> + * Sequencer Serial Port (SSP) based virtual GPIO driver
> + *
> + * Copyright (C) 2010 Texas Instruments Inc
> + *
> + * 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/io.h>
> +#include <linux/err.h>
> +#include <linux/slab.h>
> +#include <linux/gpio.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/ti_ssp.h>
> +
> +struct ti_ssp_gpio_chip {
> +	struct gpio_chip		chip;
> +	struct device			*dev;
> +	spinlock_t			lock;
> +	u8				out;
> +	u32				iosel;
> +};
> +
> +#define to_ssp_gpio_chip(c) container_of(c, struct ti_ssp_gpio_chip, chip)
> +
> +static int ti_ssp_gpio_dir_in(struct gpio_chip *chip, unsigned gpio_num)
> +{
> +	struct ti_ssp_gpio_chip *gpio = to_ssp_gpio_chip(chip);
> +	int error = 0;
> +
> +	spin_lock(&gpio->lock);
> +
> +	gpio->iosel &= ~SSP_PIN_MASK(gpio_num);
> +	gpio->iosel |=  SSP_PIN_SEL(gpio_num, SSP_IN);
> +
> +	error = ti_ssp_set_iosel(gpio->dev, gpio->iosel);
> +
> +	spin_unlock(&gpio->lock);
> +
> +	return error;
> +}
> +
> +static int ti_ssp_gpio_dir_out(struct gpio_chip *chip, unsigned gpio_num,
> +			       int val)
> +{
> +	struct ti_ssp_gpio_chip *gpio = to_ssp_gpio_chip(chip);
> +	int error;
> +
> +	spin_lock(&gpio->lock);
> +
> +	gpio->iosel &= ~SSP_PIN_MASK(gpio_num);
> +	gpio->iosel |=  SSP_PIN_SEL(gpio_num, SSP_OUT);
> +
> +	error = ti_ssp_set_iosel(gpio->dev, gpio->iosel);
> +
> +	if (error < 0)
> +		goto error;
> +
> +	if (val)
> +		gpio->out |= BIT(gpio_num);
> +	else
> +		gpio->out &= ~BIT(gpio_num);
> +
> +	error = ti_ssp_raw_write(gpio->dev, gpio->out);
> +
> +error:
> +	spin_unlock(&gpio->lock);
> +	return error;
> +}
> +
> +static int ti_ssp_gpio_get(struct gpio_chip *chip, unsigned gpio_num)
> +{
> +	struct ti_ssp_gpio_chip *gpio = to_ssp_gpio_chip(chip);
> +	int ret;
> +
> +	spin_lock(&gpio->lock);
> +
> +	ret = ti_ssp_raw_read(gpio->dev);
> +	if (ret >= 0)
> +		ret = !!(ret & BIT(gpio_num));
> +
> +	spin_unlock(&gpio->lock);
> +	return ret;
> +}
> +
> +static void ti_ssp_gpio_set(struct gpio_chip *chip, unsigned gpio_num, int val)
> +{
> +	struct ti_ssp_gpio_chip *gpio = to_ssp_gpio_chip(chip);
> +
> +	spin_lock(&gpio->lock);
> +
> +	if (val)
> +		gpio->out |= BIT(gpio_num);
> +	else
> +		gpio->out &= ~BIT(gpio_num);
> +
> +	ti_ssp_raw_write(gpio->dev, gpio->out);
> +
> +	spin_unlock(&gpio->lock);
> +}
> +
> +static int __devinit ti_ssp_gpio_probe(struct platform_device *pdev)
> +{
> +	const struct ti_ssp_gpio_data *pdata = pdev->dev.platform_data;
> +	struct device *dev = &pdev->dev;
> +	struct ti_ssp_gpio_chip *gpio;
> +	int error;
> +
> +	if (!pdata) {
> +		dev_err(dev, "platform data not found\n");
> +		return -EINVAL;
> +	}
> +
> +	gpio = kzalloc(sizeof(*gpio), GFP_KERNEL);
> +	if (!gpio) {
> +		dev_err(dev, "cannot allocate driver data\n");
> +		return -ENOMEM;
> +	}
> +
> +	gpio->dev = dev;
> +	gpio->iosel = SSP_PIN_SEL(0, SSP_IN) | SSP_PIN_SEL(1, SSP_IN) |
> +		      SSP_PIN_SEL(2, SSP_IN) | SSP_PIN_SEL(3, SSP_IN);
> +	error = ti_ssp_set_iosel(gpio->dev, gpio->iosel);
> +	if (error < 0) {
> +		dev_err(dev, "gpio io setup failed (%d)\n", error);
> +		goto error;
> +	}
> +
> +	spin_lock_init(&gpio->lock);
> +	platform_set_drvdata(pdev, gpio);
> +
> +	gpio->chip.base  = pdata->start;
> +	gpio->chip.ngpio = 4;
> +	gpio->chip.dev   = &pdev->dev;
> +	gpio->chip.label = "ti_ssp_gpio";
> +	gpio->chip.owner = THIS_MODULE;
> +	gpio->chip.get   = ti_ssp_gpio_get;
> +	gpio->chip.set   = ti_ssp_gpio_set;
> +	gpio->chip.direction_input  = ti_ssp_gpio_dir_in;
> +	gpio->chip.direction_output = ti_ssp_gpio_dir_out;
> +
> +	error = gpiochip_add(&gpio->chip);
> +	if (error < 0) {
> +		dev_err(dev, "gpio chip registration failed (%d)\n", error);
> +		goto error;
> +	}
> +
> +	dev_info(dev, "ssp gpio interface registered\n");
> +	return 0;
> +
> +error:
> +	kfree(gpio);
> +	return error;
> +}
> +
> +static int __devexit ti_ssp_gpio_remove(struct platform_device *pdev)
> +{
> +	struct ti_ssp_gpio_chip *gpio = platform_get_drvdata(pdev);
> +	int error;
> +
> +	error = gpiochip_remove(&gpio->chip);
> +	if (error < 0)
> +		return error;
> +	kfree(gpio);
> +	return 0;
> +}
> +
> +static struct platform_driver ti_ssp_gpio_driver = {
> +	.probe		= ti_ssp_gpio_probe,
> +	.remove		= __devexit_p(ti_ssp_gpio_remove),
> +	.driver		= {
> +		.name	= "ti-ssp-gpio",
> +		.owner	= THIS_MODULE,
> +	},
> +};
> +
> +static int __init ti_ssp_gpio_init(void)
> +{
> +	return platform_driver_register(&ti_ssp_gpio_driver);
> +}
> +module_init(ti_ssp_gpio_init);
> +
> +static void __exit ti_ssp_gpio_exit(void)
> +{
> +	platform_driver_unregister(&ti_ssp_gpio_driver);
> +}
> +module_exit(ti_ssp_gpio_exit);
> +
> +MODULE_DESCRIPTION("GPIO interface for TI-SSP");
> +MODULE_AUTHOR("Cyril Chemparathy <cyril at ti.com>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:ti-ssp-gpio");
> diff --git a/include/linux/mfd/ti_ssp.h b/include/linux/mfd/ti_ssp.h
> index dbb4b43..10c65bb 100644
> --- a/include/linux/mfd/ti_ssp.h
> +++ b/include/linux/mfd/ti_ssp.h
> @@ -38,6 +38,10 @@ struct ti_ssp_spi_data {
>  	void		(*select)(int cs);
>  };
>  
> +struct ti_ssp_gpio_data {
> +	int		start;
> +};
> +
>  /*
>   * Sequencer port IO pin configuration bits.  These do not correlate 1-1 with
>   * the hardware.  The iosel field in the port data combines iosel1 and iosel2,
> -- 
> 1.7.1
> 
> _______________________________________________
> 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 pratheesh at ti.com  Mon Feb 28 07:04:10 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Mon, 28 Feb 2011 18:34:10 +0530
Subject: [PATCH v2 02/13] da850: pruss platform specific additions.
In-Reply-To: <1297435892-28278-3-git-send-email-subhasish@mistralsolutions.com>
References: <1297435892-28278-1-git-send-email-subhasish@mistralsolutions.com>
	<1297435892-28278-3-git-send-email-subhasish@mistralsolutions.com>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BF35DEE@dbde02.ent.ti.com>

Hi,

> -----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 Subhasish Ghosh
> Sent: Friday, February 11, 2011 8:21 PM
> To: davinci-linux-open-source at linux.davincidsp.com
> Cc: sachi at mistralsolutions.com; Russell King; Kevin Hilman; Subhasish
> Ghosh; open list; Watkins, Melissa; linux-arm-kernel at lists.infradead.org
> Subject: [PATCH v2 02/13] da850: pruss platform specific additions.
> 
> This patch adds the platform device and assignes the platform resources
> for the PRUSS mfd driver.
> 
> Signed-off-by: Subhasish Ghosh <subhasish at mistralsolutions.com>
> ---
> +struct platform_device da8xx_pruss_dev = {
Can you please rename this to da8xx_pruss_mfddev?
> +	.name		= "da8xx_pruss",
Can you please rename name string as pruss_mfd? This will help to
base my UIO patches on top of yours.
> +	.id		= -1,
> +	.num_resources	= ARRAY_SIZE(da8xx_pruss_resources),
> +	.resource	= da8xx_pruss_resources,
> +};
> +
> +int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
Please rename this to da8xx_register_pruss_mfd

Thanks,
Pratheesh

From pratheesh at ti.com  Mon Feb 28 15:01:35 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Tue,  1 Mar 2011 02:31:35 +0530
Subject: [PATCH v6 1/1] PRUSS UIO driver support
In-Reply-To: <1298926895-5294-1-git-send-email-pratheesh@ti.com>
References: <1298926895-5294-1-git-send-email-pratheesh@ti.com>
Message-ID: <1298926895-5294-2-git-send-email-pratheesh@ti.com>

This patch implements PRUSS (Programmable Real-time Unit Sub System)
UIO driver which exports SOC resources associated with PRUSS like
I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
processors which is efficient in performing embedded tasks that
require manipulation of packed memory mapped data structures and
handling system events that have tight real time constraints. This
driver is currently supported on Texas Instruments DA850, AM18xx and
OMAP-L138 devices.
For example, PRUSS runs firmware for real-time critical industrial
communication data link layer and communicates with application stack
running in user space via shared memory and IRQs.

Signed-off-by: Pratheesh Gangadhar <pratheesh at ti.com>
Reviewed-by: Thomas Gleixner <tglx at linutronix.de>
---
 drivers/uio/Kconfig     |   17 ++++
 drivers/uio/Makefile    |    1 +
 drivers/uio/uio_pruss.c |  237 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 255 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index bb44079..6f3ea9b 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -94,4 +94,21 @@ config UIO_NETX
 	  To compile this driver as a module, choose M here; the module
 	  will be called uio_netx.
 
+config UIO_PRUSS
+	tristate "Texas Instruments PRUSS driver"
+	depends on ARCH_DAVINCI_DA850
+	help
+	  PRUSS driver for OMAPL138/DA850/AM18XX devices
+	  PRUSS driver requires user space components, examples and user space
+	  driver is available from below SVN repo - you may use anonymous login
+
+	  https://gforge.ti.com/gf/project/pru_sw/
+
+	  More info on API is available at below wiki
+
+	  http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called uio_pruss.
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 18fd818..d4dd9a5 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_UIO_AEC)	+= uio_aec.o
 obj-$(CONFIG_UIO_SERCOS3)	+= uio_sercos3.o
 obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
+obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
new file mode 100644
index 0000000..e5ced29
--- /dev/null
+++ b/drivers/uio/uio_pruss.c
@@ -0,0 +1,237 @@
+/*
+ * Programmable Real-Time Unit Sub System (PRUSS) UIO driver (uio_pruss)
+ *
+ * This driver exports PRUSS host event out interrupts and PRUSS, L3 RAM,
+ * and DDR RAM to user space for applications interacting with PRUSS firmware
+ *
+ * Copyright (C) 2010-11 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 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/device.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <mach/sram.h>
+
+
+#define DRV_NAME "pruss_uio"
+#define DRV_VERSION "0.50"
+
+
+static int sram_pool_sz = SZ_16K;
+module_param(sram_pool_sz, int, 0);
+MODULE_PARM_DESC(sram_pool_sz, "sram pool size to allocate ");
+
+static int extram_pool_sz = SZ_256K;
+module_param(extram_pool_sz, int, 0);
+MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
+
+
+/*
+ * Host event IRQ numbers from PRUSS - PRUSS can generate upto 8 interrupt
+ * events to AINTC of ARM host processor - which can be used for IPC b/w PRUSS
+ * firmware and user space application, async notification from PRU firmware
+ * to user space application
+ * 3	PRU_EVTOUT0
+ * 4	PRU_EVTOUT1
+ * 5	PRU_EVTOUT2
+ * 6	PRU_EVTOUT3
+ * 7	PRU_EVTOUT4
+ * 8	PRU_EVTOUT5
+ * 9	PRU_EVTOUT6
+ * 10	PRU_EVTOUT7
+*/
+
+#define MAX_PRUSS_EVT			8
+
+#define	PINTC_HIPIR			0x4900
+#define	HIPIR_NOPEND			0x80000000
+#define	PINTC_HIER			0x5500
+
+static spinlock_t lock;
+static struct clk *pruss_clk;
+static struct uio_info *info;
+static dma_addr_t sram_paddr, ddr_paddr;
+static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
+
+static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
+{
+	unsigned long flags;
+	int val, intr_mask = (1 << (irq - 1));
+	void __iomem *base = dev_info->mem[0].internal_addr;
+	void __iomem *intren_reg = base + PINTC_HIER;
+	void __iomem *intrstat_reg = base + PINTC_HIPIR + ((irq - 1) << 2);
+
+	spin_lock_irqsave(&lock, flags);
+	val = ioread32(intren_reg);
+	/* Is interrupt enabled and active ? */
+	if (!(val & intr_mask) && (ioread32(intrstat_reg) & HIPIR_NOPEND)) {
+		spin_unlock_irqrestore(&lock, flags);
+		return IRQ_NONE;
+	}
+
+	/* Disable interrupt */
+	iowrite32((val & ~intr_mask), intren_reg);
+	spin_unlock_irqrestore(&lock, flags);
+	return IRQ_HANDLED;
+}
+
+static void pruss_cleanup(struct platform_device *dev, struct uio_info *info)
+{
+	struct uio_info *p = info;
+	int cnt;
+
+	for (cnt = 0; cnt < MAX_PRUSS_EVT; cnt++, p++) {
+		uio_unregister_device(p);
+		kfree(p->name);
+	}
+	iounmap(prussio_vaddr);
+	if (ddr_vaddr) {
+		dma_free_coherent(&dev->dev, extram_pool_sz, ddr_vaddr,
+			ddr_paddr);
+	}
+	if (sram_vaddr)
+		sram_free(sram_vaddr, sram_pool_sz);
+	kfree(info);
+	clk_put(pruss_clk);
+}
+
+static int __devinit pruss_probe(struct platform_device *dev)
+{
+	struct uio_info *p;
+	int ret = -ENODEV, cnt = 0, len;
+	struct resource *regs_prussio;
+
+	info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVT, GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+	/* Power on PRU in case its not done as part of boot-loader */
+	pruss_clk = clk_get(&dev->dev, "pruss");
+	if (IS_ERR(pruss_clk)) {
+		dev_err(&dev->dev, "Failed to get clock\n");
+		kfree(info);
+		ret = PTR_ERR(pruss_clk);
+		return ret;
+	} else {
+		clk_enable(pruss_clk);
+	}
+
+	regs_prussio = platform_get_resource(dev, IORESOURCE_MEM, 0);
+	if (!regs_prussio) {
+		dev_err(&dev->dev, "No PRUSS I/O resource specified\n");
+		goto out_free;
+	}
+
+	if (!regs_prussio->start) {
+		dev_err(&dev->dev, "Invalid memory resource\n");
+		goto out_free;
+	}
+
+	sram_vaddr = sram_alloc(sram_pool_sz, &sram_paddr);
+	if (!sram_vaddr) {
+		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
+		goto out_free;
+	}
+
+	ddr_vaddr = dma_alloc_coherent(&dev->dev, extram_pool_sz, &ddr_paddr,
+				GFP_KERNEL | GFP_DMA);
+	if (!ddr_vaddr) {
+		dev_err(&dev->dev, "Could not allocate external memory\n");
+		goto out_free;
+	}
+
+	len = resource_size(regs_prussio);
+	prussio_vaddr = ioremap(regs_prussio->start, len);
+	if (!prussio_vaddr) {
+		dev_err(&dev->dev, "Can't remap PRUSS I/O  address range\n");
+		goto out_free;
+	}
+
+	for (cnt = 0, p = info; cnt < MAX_PRUSS_EVT; cnt++, p++) {
+		p->mem[0].internal_addr = prussio_vaddr;
+		p->mem[0].addr = regs_prussio->start;
+		p->mem[0].size = resource_size(regs_prussio);
+		p->mem[0].memtype = UIO_MEM_PHYS;
+
+		p->mem[1].internal_addr = sram_vaddr;
+		p->mem[1].addr = sram_paddr;
+		p->mem[1].size = sram_pool_sz;
+		p->mem[1].memtype = UIO_MEM_PHYS;
+
+		p->mem[2].internal_addr = ddr_vaddr;
+		p->mem[2].addr = ddr_paddr;
+		p->mem[2].size = extram_pool_sz;
+		p->mem[2].memtype = UIO_MEM_PHYS;
+
+		p->name = kasprintf(GFP_KERNEL, "pruss_evt%d", cnt);
+		p->version = "0.50";
+
+		/* Register PRUSS IRQ lines */
+		p->irq = IRQ_DA8XX_EVTOUT0 + cnt;
+		p->handler = pruss_handler;
+
+		ret = uio_register_device(&dev->dev, p);
+
+		if (ret < 0)
+			goto out_free;
+	}
+
+	spin_lock_init(&lock);
+	platform_set_drvdata(dev, info);
+	return 0;
+
+out_free:
+	pruss_cleanup(dev, info);
+	return ret;
+}
+
+static int __devexit pruss_remove(struct platform_device *dev)
+{
+	struct uio_info *info = platform_get_drvdata(dev);
+
+	pruss_cleanup(dev, info);
+	platform_set_drvdata(dev, NULL);
+	return 0;
+}
+
+static struct platform_driver pruss_driver = {
+	.probe = pruss_probe,
+	.remove = __devexit_p(pruss_remove),
+	.driver = {
+		   .name = DRV_NAME,
+		   .owner = THIS_MODULE,
+		   },
+};
+
+static int __init pruss_init_module(void)
+{
+	return platform_driver_register(&pruss_driver);
+}
+
+module_init(pruss_init_module);
+
+static void __exit pruss_exit_module(void)
+{
+	platform_driver_unregister(&pruss_driver);
+}
+
+module_exit(pruss_exit_module);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Amit Chatterjee <amit.chatterjee at ti.com>");
+MODULE_AUTHOR("Pratheesh Gangadhar <pratheesh at ti.com>");
-- 
1.6.0.6


From pratheesh at ti.com  Mon Feb 28 15:01:34 2011
From: pratheesh at ti.com (Pratheesh Gangadhar)
Date: Tue,  1 Mar 2011 02:31:34 +0530
Subject: [PATCH v6 0/1] Add PRUSS UIO driver support
Message-ID: <1298926895-5294-1-git-send-email-pratheesh@ti.com>

This patch series add support for PRUSS (Programmable Real-time Unit Sub
System) UIO driver in Texas Instruments DA850, AM18xx and OMAP-L138 processors.
PRUSS is programmable RISC core which can be used to implement Soft IPs
(eg:- DMA, CAN, UART,SmartCard) and Industrial communications data link layers
(eg:- PROFIBUS). UIO driver exposes PRUSS resources like memory and interrupts
to user space application.PRUSS UIO application API can be used to control PRUs
in PRUSS, setup PRU INTC, load firmware to PRUs and implement IPC between Host
processor and PRUs. More information on PRUSS and UIO linux user space API
available in the links below

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide

Platform/board specific portion of this patch depends on Mistral patches below

[PATCH 1/1] davinci: changed SRAM allocator to shared ram :
				https://patchwork.kernel.org/patch/549351/
[PATCH 1/1] da830: macro rename DA8XX_LPSC0_DMAX to DA8XX_LPSC0_PRUSS :
				 https://patchwork.kernel.org/patch/549331/
[PATCH v2 01/13] mfd: pruss mfd driver :
				https://patchwork.kernel.org/patch/549531/
[PATCH v2 02/13] da850: pruss platform specific additions :
				https://patchwork.kernel.org/patch/549521/

I will submit a seperate patch set on top of these patches to support PRUSS UIO
driver.

Pratheesh Gangadhar (1):
  PRUSS UIO driver support

 drivers/uio/Kconfig     |   17 ++++
 drivers/uio/Makefile    |    1 +
 drivers/uio/uio_pruss.c |  237 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 255 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pruss.c


From khilman at ti.com  Mon Feb 28 17:41:36 2011
From: khilman at ti.com (Kevin Hilman)
Date: Mon, 28 Feb 2011 15:41:36 -0800
Subject: [GIT PULL] davinci fixes for 2.6.38-rc7
Message-ID: <87oc5vlob3.fsf@ti.com>

Hi Russell,

Please pull the following small series of davinci fixes for 2.6.38-rc7.

Thanks,

Kevin


The following changes since commit f5412be599602124d2bdd49947b231dd77c0bf99:

  Linux 2.6.38-rc6 (2011-02-21 17:25:52 -0800)

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

Axel Lin (1):
      davinci: cpufreq: fix section mismatch warning

Hirosh Dabui (1):
      davinci: tnetv107x: fix register indexing for GPIOs numbers > 31

Rajashekhara, Sudhakar (1):
      davinci: da8xx/omap-l1x: add platform device for davinci-pcm-audio

Sergei Shtylyov (1):
      DaVinci: fix compilation warnings in <mach/clkdev.h>

 arch/arm/mach-davinci/cpufreq.c             |    2 +-
 arch/arm/mach-davinci/devices-da8xx.c       |    7 +++++++
 arch/arm/mach-davinci/gpio-tnetv107x.c      |   18 +++++++++---------
 arch/arm/mach-davinci/include/mach/clkdev.h |    2 ++
 4 files changed, 19 insertions(+), 10 deletions(-)

From pratheesh at ti.com  Mon Feb 28 22:45:27 2011
From: pratheesh at ti.com (TK, Pratheesh Gangadhar)
Date: Tue, 1 Mar 2011 10:15:27 +0530
Subject: [PATCH v6 1/1] PRUSS UIO driver support
In-Reply-To: <20110228212638.GB16806@local>
References: <1298926895-5294-1-git-send-email-pratheesh@ti.com>
	<1298926895-5294-2-git-send-email-pratheesh@ti.com>
	<20110228212638.GB16806@local>
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024BF3601C@dbde02.ent.ti.com>

Hi,

> -----Original Message-----
> From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> Sent: Tuesday, March 01, 2011 2:57 AM
> To: TK, Pratheesh Gangadhar
> Cc: linux-kernel at vger.kernel.org; hjk at hansjkoch.de; gregkh at suse.de;
> tglx at linutronix.de; sshtylyov at mvista.com; arnd at arndb.de; Chatterjee, Amit;
> davinci-linux-open-source at linux.davincidsp.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v6 1/1] PRUSS UIO driver support
> 
> On Tue, Mar 01, 2011 at 02:31:35AM +0530, Pratheesh Gangadhar wrote:
> > +
> > +		/* Register PRUSS IRQ lines */
> > +		p->irq = IRQ_DA8XX_EVTOUT0 + cnt;
> > +		p->handler = pruss_handler;
> > +
> > +		ret = uio_register_device(&dev->dev, p);
> > +
> > +		if (ret < 0)
> > +			goto out_free;
> > +	}
> > +
> > +	spin_lock_init(&lock);
> 
> That's too late. uio_register_device() enables the irq, and your spin_lock
> is not ready at that time.

This is ok in this context as "modprobe uio_pruss" is pre-requisite for
running PRUSS firmware and without firmware running PRUSS won't
generate interrupts. Actually PRUSS INTC is not setup till we start
user application.

Thanks,
Pratheesh