RE: How to use the fb-driver with the patch: davinci: fb: Frame Buffer driver for TI A8xx/OMAP-L1xx

2009-07-22 Thread Sudhakar Rajashekhara 
On Wed, Jul 22, 2009 at 17:04:43, Bastian Ruppert wrote:
> Hello, 
> i try to enable the patch [PATCH] davinci: fb: Frame Buffer driver for TI 
> A8xx/OMAP-L1xx from 
> Sudhakar Rajashekhara.
> 
> I can enable the Framebuffersupport via menuconfig, and there is a 
> functioncall to static int __init da8xx_fb_init(void)
> (da8xx-fb.c) when running the driver on the target-device.
> 
> But the function static int __init fb_probe(struct platform_device *device) 
> is never executed.
> 
> The question is: 
> What is to do to treat the kernel to call the function static int __init 
> fb_probe(struct platform_device *device)? 
> 

Bastian,

You need to initialize the platform data for this driver to work.
Which platform you are using this driver on? Is it OMAP-L137 or
OMAP-L138? I have pushed the platform data patch required for
OMAP-L138 to
http://arago-project.org/git/people/?p=sekhar/linux-omapl1.git;a=shortlog;h=refs/heads/staging.

If you are working on OMAP-L137, you need a similar patch for
that platform. Please note that, on OMAP-L137, IO expander at
i2c address 0x3f needs to be programmed for LCD to work.

Regards, Sudhakar


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

[PATCH] davinci: Configure MDIO pins for EMAC

2009-07-22 Thread Sudhakar Rajashekhara 
Earlier patch which adds EMAC support for da850/omap-l138
was not configuring the MDIO pins.

Ethernet was working fine with the earlier patch, because
the MDIO pins were configured from the boot loader. This
patch removes that dependency.

Also, this patch populates a member in the emac clk structure
to say that EMAC LPSC sits on controller 1.

Signed-off-by: Sudhakar Rajashekhara 
---
 This patch depends on the following patch which I have
 submitted to davinci git:
 [PATCH] davinci: Add MMC/SD support for da850/omap-l138

 arch/arm/mach-davinci/da850.c|6 +-
 arch/arm/mach-davinci/include/mach/mux.h |2 ++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4b5ac24..dc7ca1d 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -287,6 +287,7 @@ static struct clk emac_clk = {
.name   = "emac",
.parent = &pll0_sysclk4,
.lpsc   = DA8XX_LPSC1_CPGMAC,
+   .psc_ctlr   = 1,
 };
 
 static struct clk mmcsd_clk = {
@@ -377,6 +378,8 @@ static const struct mux_config da850_pins[] = {
MUX_CFG(DA850, MII_RXD_2,   3,  20, 15, 8,  false)
MUX_CFG(DA850, MII_RXD_1,   3,  24, 15, 8,  false)
MUX_CFG(DA850, MII_RXD_0,   3,  28, 15, 8,  false)
+   MUX_CFG(DA850, MDIO_CLK,4,  0,  15, 8,  false)
+   MUX_CFG(DA850, MDIO_D,  4,  4,  15, 8,  false)
/* MMC/SD0 function */
MUX_CFG(DA850, MMCSD0_DAT_0,10, 8,  15, 2,  false)
MUX_CFG(DA850, MMCSD0_DAT_1,10, 12, 15, 2,  false)
@@ -416,7 +419,8 @@ const short da850_cpgmac_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,
DA850_MII_CRS, DA850_MII_RXCLK, DA850_MII_RXDV, DA850_MII_RXD_3,
-   DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0,
+   DA850_MII_RXD_2, DA850_MII_RXD_1, DA850_MII_RXD_0, DA850_MDIO_CLK,
+   DA850_MDIO_D,
-1
 };
 
diff --git a/arch/arm/mach-davinci/include/mach/mux.h 
b/arch/arm/mach-davinci/include/mach/mux.h
index 09dbede..f5febdd 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -747,6 +747,8 @@ enum davinci_da850_index {
DA850_MII_RXD_2,
DA850_MII_RXD_1,
DA850_MII_RXD_0,
+   DA850_MDIO_CLK,
+   DA850_MDIO_D,
 
/* MMC/SD0 function */
DA850_MMCSD0_DAT_0,
-- 
1.5.6

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

PLL Bypass Problem

2009-07-22 Thread Azam Ansari 
Hi All,

I have written following function to do pll bypass.

void davinci_clk_at24MHz(void)
{
struct clk *clkp;
static struct clk *board_clks;
int count = 0, num_clks;
unsigned long pllcnt;

if (cpu_is_davinci_dm355()) {

pllcnt = davinci_readl(DAVINCI_PLL_CNTRL0_BASE + PLLCTL);
davinci_writel(DAVINCI_PLL_CNTRL0_BASE + PLLCTL, pllcnt & ~BIT(0));
udelay(4);
davinci_writel(DAVINCI_PLL_CNTRL0_BASE + PLLCTL, (pllcnt & ~BIT(0))
| PLLRST);

fixedrate = 2400;
armrate = fixedrate;
commonrate = armrate / 2;

board_clks = davinci_dm355_clks;
num_clks = ARRAY_SIZE(davinci_dm355_clks);
} else if (cpu_is_davinci_dm6467()) {
fixedrate = 2400;
div_by_four = ((PLL1_PLLM + 1) * 2700) / 4;
div_by_six = ((PLL1_PLLM + 1) * 2700) / 6;
div_by_eight = ((PLL1_PLLM + 1) * 2700) / 8;
armrate = ((PLL1_PLLM + 1) * 2700) / 2;

board_clks = davinci_dm6467_clks;
num_clks = ARRAY_SIZE(davinci_dm6467_clks);
} else {
fixedrate = 2700;
armrate = (PLL1_PLLM + 1) * (fixedrate / 2);
commonrate = armrate / 3;

board_clks = davinci_dm644x_clks;
num_clks = ARRAY_SIZE(davinci_dm644x_clks);
}

for (clkp = board_clks; count < num_clks; count++, clkp++) {
clk_register(clkp);

/* Turn on clocks that have been enabled in the
 * table above */
if (clkp->usecount) {
clk_enable(clkp);
}
}
}

I call this function through power management modules main.c file
enter_state() function.
I do following to enable PLL bypass mode.

# echo pllbypass > /sys/power/state


But I get following kernel dump after that:

Storing State to pllbypass
Unable to handle kernel paging request at virtual address df400040
pgd = c6c74000
[df400040] *pgd=
Internal error: Oops: 805 [#1]
Modules linked in: dm350mmap cmemk
CPU: 0
PC is at davinci_clk_at24MHz+0x38/0x23c
LR is at enter_state+0x68/0x1cc
pc : []lr : []Not tainted
sp : c08cbea0  ip : c08cbec8  fp : c08cbec4
r10: 000a  r9 : c08cbf78  r8 : 
r7 : 0009  r6 : df40  r5 : 01c40900  r4 : 0040
r3 : e104  r2 : 0350  r1 :   r0 : 0005
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 5317F  Table: 86C74000  DAC: 0015
Process sh (pid: 972, stack limit = 0xc08ca1a0)
Stack: (0xc08cbea0 to 0xc08cc000)
bea0: 000f  0005 0005 0009 c02f2854 c08cbeec
c08cbec8
bec0: c006fea0 c0044c64 c0052c04 c71b6000 c02f2844 0005 0009
c02f2830
bee0: c08cbf14 c08cbef0 c0070140 c006fe48 000a 40018000 c6c3cb20

bf00: c6c3cb38 c6c38680 c08cbf24 c08cbf18 c00c92fc c00700c4 c08cbf54
c08cbf28
bf20: c00c95ec c00c92e0  000a c6c38680 40018000 c08cbf78
c00362f4
bf40: c08ca000 0094 c08cbf74 c08cbf58 c0092ec0 c00c94ec 

bf60: c6c38680 0004 c08cbfa4 c08cbf78 c0092fb4 c0092e10 

bf80: c0092444  00017a80 000a 4020c798 40018000 
c08cbfa8
bfa0: c0035b60 c0092f7c 000a 4020c798 0001 40018000 000a

bfc0: 000a 4020c798 40018000 000a 400178c0 0a5c 4020c000
000bd744
bfe0:  befff724 401a5a4c 401a5a68 6010 0001 0400

Backtrace:
[] (davinci_clk_at24MHz+0x0/0x23c) from []
(enter_state+0x68/0x1cc)
 r8 = C02F2854  r7 = 0009  r6 = 0005  r5 = 0005
 r4 = 
[] (enter_state+0x0/0x1cc) from []
(state_store+0x8c/0xa0)
 r8 = C02F2830  r7 = 0009  r6 = 0005  r5 = C02F2844
 r4 = C71B6000
[] (state_store+0x0/0xa0) from []
(subsys_attr_store+0x2c/0x38)
[] (subsys_attr_store+0x0/0x38) from []
(sysfs_write_file+0x110/0x15c)
[] (sysfs_write_file+0x0/0x15c) from []
(vfs_write+0xc0/0xf8)
[] (vfs_write+0x0/0xf8) from [] (sys_write+0x48/0x74)
 r7 = 0004  r6 = C6C38680  r5 =   r4 = 
[] (sys_write+0x0/0x74) from []
(ret_fast_syscall+0x0/0x2c)
 r6 = 40018000  r5 = 4020C798  r4 = 000A
Code: e5934900 e59f61c0 e59f51c0 e3c44001 (e7845006)

MontaVista(R) Linux(R) Professional Edition 4.0.1 (0502020)

192.168.0.104 login:


I found that when I use davinci_readl() function it works fine. But when I
use davinci_writel() function to write the same read register it gives the
kernel dumt.

>>davinci_writel(DAVINCI_PLL_CNTRL0_BASE + PLLCTL, pllcnt & ~BIT(0));
(Hangs at this line)

Please can anyone help?

thanks,
azam.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v2] mfd: Correct ro and cd implemantion on DM355

2009-07-22 Thread David Brownell 
On Wednesday 22 July 2009, Vipin Bhandari wrote:
> This patch corrects the support for MMCSD card detection
> and read only feature for SoC DM355.
> 
> EVMDM355_ECP_VA4.pdf, from Spectrum digital, suggests that
> Bit 2 and 4 should be checked for card detection. However
> on the EVM, bits 1 and 3 gives this status, for MMC/SD
> instance 0 and 1 respectively. The pdf also suggests that
> Bit 1 and 3 should be checked for write protection. However
> on the EVM bits 2 and 4 gives this status.

In short:  card detection works iff the writeprotect switch
isn't used, since the two signals are swapped.

> 
> This document can be downloaded from
> http://c6000.spectrumdigital.com/evmdm355/reve/files/EVMDM355_ECP_VA4.pdf
> 
> Signed-off-by: Vipin Bhandari 

Acked-by: David Brownell 

 but this should merge through the MFD tree.  Send it to
(per MAINTAINERS):

MULTIFUNCTION DEVICES (MFD)
P:  Samuel Ortiz
M:  sa...@linux.intel.com
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git
S:  Supported
F:  drivers/mfd/

> ---
>  This patch has been tested on DM355 EVM.
> 
>  Since the previous version, format of the multi-line comment
>  has been corrected.
> 
>  drivers/mfd/dm355evm_msp.c |   12 ++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
> index 5b6e58a..3d4a861 100644
> --- a/drivers/mfd/dm355evm_msp.c
> +++ b/drivers/mfd/dm355evm_msp.c
> @@ -107,8 +107,16 @@ static const u8 msp_gpios[] = {
>   MSP_GPIO(2, SWITCH1), MSP_GPIO(3, SWITCH1),
>   MSP_GPIO(4, SWITCH1),
>   /* switches on MMC/SD sockets */
> - MSP_GPIO(1, SDMMC), MSP_GPIO(2, SDMMC), /* mmc0 WP, nCD */
> - MSP_GPIO(3, SDMMC), MSP_GPIO(4, SDMMC), /* mmc1 WP, nCD */
> + /*
> +  * Note: EVMDM355_ECP_VA4.pdf suggests that Bit 2 and 4 should be
> +  * checked for card detection. However on the EVM bit 1 and 3 gives
> +  * this status, for 0 and 1 instance respectively. The pdf also
> +  * suggests that Bit 1 and 3 should be checked for write protection.
> +  * However on the EVM bit 2 and 4 gives this status,for 0 and 1
> +  * instance respectively.
> +  */
> + MSP_GPIO(2, SDMMC), MSP_GPIO(1, SDMMC), /* mmc0 WP, nCD */
> + MSP_GPIO(4, SDMMC), MSP_GPIO(3, SDMMC), /* mmc1 WP, nCD */
>  };
>  
>  #define MSP_GPIO_REG(offset) (msp_gpios[(offset)] >> 3)
> -- 
> 1.5.6
> 
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 
> 




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

Re: problem while experimenting with g711enc

2009-07-22 Thread Jerry Johns 
Instead of doing all this work to get it working with VLC/etc, just use
Audacity which is an open source audio player

It has options to import raw signed 8-bit audio in ulaw/alaw form - this
is what I use to playback raw G.711 audio streams, as well as reading
WAV files, MP3, etc.

 

Thanks,

Jerry Johns
Design Engineer
Nuvation Research Corp - Canada
Tel: (519) 746-2304 ext. 221
www.nuvation.com  

 

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

Problem booting with filesystem in flash

2009-07-22 Thread Steve Ressler 




Hello,

I'm trying to boot my system with a cramfs filesystem in NOR flash. The
kernel shows the following output when booting:

physmap flash device: 200 at 800
RedBoot partition parsing not available
davinciflash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0041
davinciflash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 5 MTD partitions on "davinciflash.0":
0x-0x0002 : "bootloader"
0x0002-0x0004 : "params"
0x0004-0x0006 : "sw_params"
0x0006-0x005ec000 : "kernel"
mtd: partition "kernel" doesn't end on an erase block -- force read-only
0x005ec000-0x0200 : "filesystem"
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 1304KiB [1 disk] into ram disk... done.
VFS: Mounted root (cramfs filesystem) readonly.
VFS: Cannot open root device "ram0" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)


I've verified that the cramfs image contains /dev/ram0. My uboot
commands are:

bootargs=mem=30M console=ttyS0,115200n8 root=/dev/ram0 ro init=/startup
ip=off lpj=741376
bootcmd=cp.b 0x021a 0x8090 0x146040; bootm 0x0206 0x8090

Any idea what I'm doing wrong? Thanks for any help.

-Steve






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

Re: problem while experimenting with g711enc

2009-07-22 Thread Zuber 

Hi,

Header which we have used is as below, view this in hex viewer. It is 44 
bytes header.


RIFF$ qWAVEfmt 

For more information on this 44 bytes go through the link given below.
You have to modify some of the values from these 44 bytes as per your 
clip like no. of channels and sampling rate.


http://ccrma.stanford.edu/courses/422/projects/WaveFormat/

Zuber Saiyed
Embedded Engineer
eInfochips Ltd.
Tel. No. +91 79 26563705 Ext. 126
Cell. No. +91 96621 33369
www.einfochips.com



Ottavio Campana wrote:

would you mind posting the header you're using?

On Wed, Jul 22, 2009 at 02:43:12PM +0530, Zuber wrote:
  
One quick solution is to put 44 bytes wav header at the beginning of the 
G711 encoded file.
VLC will then recognize your clip and play it successfully. We have 
tested it here. It works with vlc player.


Zuber Saiyed
Embedded Engineer
eInfochips Ltd.
Tel. No. +91 79 26563705 Ext. 126
Cell. No. +91 96621 33369
www.einfochips.com



Ottavio Campana wrote:

mmm... 


vlc output is
[0287] main playlist: nothing to play
so I suspect I'm missing an header or something similar...

Do you add something at the beginning of the file? I currently just save
the encoded output.

Ottavio

On Wed, Jul 22, 2009 at 01:47:02PM +0530, bhushan wrote:
 
  

Hi,
You may have to download the g711 codec lib for a player such as winamp/
vlc then play it.

Bhushan

On Wed, Jul 22, 2009 at 12:48 PM, Ottavio Campana <
ottavio.camp...@dei.unipd.it> wrote:

   


Hi,

I'm trying to use g711enc to  make some experiments. Everything seems to
work fine,  but I don't know  how I can  play the compressed file  I get
  

>from the application.


How do you play it?

--
Non c'è più forza nella normalità, c'è solo monotonia.

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

 
  

--
Bhushan
   

 
  

--
_
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_




  

--
_
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_


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

RE: [PATCH] ASoC: tlv320aic3x: Enable PLL when not bypassed

2009-07-22 Thread chaithrika 
On Wed, Jul 22, 2009 at 18:09:58, Mani, Arun wrote:
> Hi Chaithrika,
> Do you know why it worked in dm644x. I don't see any specific path taken
for the DM644x.
> 

On DM644x EVM the MCLK frequency is different when compared
to DM646x and DM355 EVM. Also, some sample frequencies bypass the
PLL and will work fine. However for example in the case of 44100Hz
sampling rate, the PLL should be used but was not enabled and the 
playback is slightly faster: a 60s audio file plays in about 56s.
With this patch applied the playback seems to be correct.

Regards, 
Chaithrika
 
> Arun
> 
> -Original Message-
> From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Subrahmanya, Chaithrika
> Sent: Wednesday, July 22, 2009 7:45 AM
> To: alsa-de...@alsa-project.org
> Cc: davinci-linux-open-source@linux.davincidsp.com;
broo...@opensource.wolfsonmicro.com
> Subject: [PATCH] ASoC: tlv320aic3x: Enable PLL when not bypassed
> 
> PLL was not being enabled when it was not bypassed. This patch
> enables the PLL when it is used. Additionally, it disables the PLL
> when it is bypassed.
> 
> Without this patch, the audio on TI DM646x EVM and DM355 EVM
> does not work properly. The bit clocks and the frame sync signals
> from the codec are not correct and hence the playback/record are faster
> than usual for most sample rates. The reason for this was that the PLL
> was not enabled when it was not bypassed.
> 
> Tested on DM6467 EVM, playback tested on DM355 EVM.
> 
> Signed-off-by: Chaithrika U S 
> ---
> Applies to master branch of ALSA GIT tree at
> http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary
> 
>  sound/soc/codecs/tlv320aic3x.c |   11 ++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/sound/soc/codecs/tlv320aic3x.c
b/sound/soc/codecs/tlv320aic3x.c
> index ab099f4..cb0d1bf 100644
> --- a/sound/soc/codecs/tlv320aic3x.c
> +++ b/sound/soc/codecs/tlv320aic3x.c
> @@ -767,6 +767,7 @@ static int aic3x_hw_params(struct snd_pcm_substream
*substream,
>   int codec_clk = 0, bypass_pll = 0, fsref, last_clk = 0;
>   u8 data, r, p, pll_q, pll_p = 1, pll_r = 1, pll_j = 1;
>   u16 pll_d = 1;
> + u8 reg;
>  
>   /* select data word length */
>   data =
> @@ -801,8 +802,16 @@ static int aic3x_hw_params(struct snd_pcm_substream
*substream,
>   pll_q &= 0xf;
>   aic3x_write(codec, AIC3X_PLL_PROGA_REG, pll_q <<
PLLQ_SHIFT);
>   aic3x_write(codec, AIC3X_GPIOB_REG, CODEC_CLKIN_CLKDIV);
> - } else
> + /* disable PLL if it is bypassed */
> + reg = aic3x_read_reg_cache(codec, AIC3X_PLL_PROGA_REG);
> + aic3x_write(codec, AIC3X_PLL_PROGA_REG, reg & ~PLL_ENABLE);
> +
> + } else {
>   aic3x_write(codec, AIC3X_GPIOB_REG, CODEC_CLKIN_PLLDIV);
> + /* enable PLL when it is used */
> + reg = aic3x_read_reg_cache(codec, AIC3X_PLL_PROGA_REG);
> + aic3x_write(codec, AIC3X_PLL_PROGA_REG, reg | PLL_ENABLE);
> + }
>  
>   /* Route Left DAC to left channel input and
>* right DAC to right channel input */
> -- 
> 1.5.6
> 
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 



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

RE: [PATCH] ASoC: tlv320aic3x: Enable PLL when not bypassed

2009-07-22 Thread chaithrika 
On Wed, Jul 22, 2009 at 18:12:14, Mark Brown wrote:
> On Wed, Jul 22, 2009 at 07:45:04AM -0400, Chaithrika U S wrote:
> > PLL was not being enabled when it was not bypassed. This patch
> > enables the PLL when it is used. Additionally, it disables the PLL
> > when it is bypassed.
> > 
> > Without this patch, the audio on TI DM646x EVM and DM355 EVM
> > does not work properly. The bit clocks and the frame sync signals
> > from the codec are not correct and hence the playback/record are faster
> > than usual for most sample rates. The reason for this was that the PLL
> > was not enabled when it was not bypassed.
> 
> Looks reasonable though I've no knowledge of the CODEC.  Sounds like
> this is needed in 2.6.31?
> 

Yes, it is needed in 2.6.31.

Regards, 
Chaithrika


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

RE: [PATCH] ASoC: tlv320aic3x: Enable PLL when not bypassed

2009-07-22 Thread Mani, Arun 
Hi Chaithrika,
Do you know why it worked in dm644x. I don't see any specific path taken for 
the DM644x.

Arun

-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com 
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of 
Subrahmanya, Chaithrika
Sent: Wednesday, July 22, 2009 7:45 AM
To: alsa-de...@alsa-project.org
Cc: davinci-linux-open-source@linux.davincidsp.com; 
broo...@opensource.wolfsonmicro.com
Subject: [PATCH] ASoC: tlv320aic3x: Enable PLL when not bypassed

PLL was not being enabled when it was not bypassed. This patch
enables the PLL when it is used. Additionally, it disables the PLL
when it is bypassed.

Without this patch, the audio on TI DM646x EVM and DM355 EVM
does not work properly. The bit clocks and the frame sync signals
from the codec are not correct and hence the playback/record are faster
than usual for most sample rates. The reason for this was that the PLL
was not enabled when it was not bypassed.

Tested on DM6467 EVM, playback tested on DM355 EVM.

Signed-off-by: Chaithrika U S 
---
Applies to master branch of ALSA GIT tree at
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary

 sound/soc/codecs/tlv320aic3x.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index ab099f4..cb0d1bf 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -767,6 +767,7 @@ static int aic3x_hw_params(struct snd_pcm_substream 
*substream,
int codec_clk = 0, bypass_pll = 0, fsref, last_clk = 0;
u8 data, r, p, pll_q, pll_p = 1, pll_r = 1, pll_j = 1;
u16 pll_d = 1;
+   u8 reg;
 
/* select data word length */
data =
@@ -801,8 +802,16 @@ static int aic3x_hw_params(struct snd_pcm_substream 
*substream,
pll_q &= 0xf;
aic3x_write(codec, AIC3X_PLL_PROGA_REG, pll_q << PLLQ_SHIFT);
aic3x_write(codec, AIC3X_GPIOB_REG, CODEC_CLKIN_CLKDIV);
-   } else
+   /* disable PLL if it is bypassed */
+   reg = aic3x_read_reg_cache(codec, AIC3X_PLL_PROGA_REG);
+   aic3x_write(codec, AIC3X_PLL_PROGA_REG, reg & ~PLL_ENABLE);
+
+   } else {
aic3x_write(codec, AIC3X_GPIOB_REG, CODEC_CLKIN_PLLDIV);
+   /* enable PLL when it is used */
+   reg = aic3x_read_reg_cache(codec, AIC3X_PLL_PROGA_REG);
+   aic3x_write(codec, AIC3X_PLL_PROGA_REG, reg | PLL_ENABLE);
+   }
 
/* Route Left DAC to left channel input and
 * right DAC to right channel input */
-- 
1.5.6

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

[PATCH] ASoC: tlv320aic3x: Enable PLL when not bypassed

2009-07-22 Thread Chaithrika U S 
PLL was not being enabled when it was not bypassed. This patch
enables the PLL when it is used. Additionally, it disables the PLL
when it is bypassed.

Without this patch, the audio on TI DM646x EVM and DM355 EVM
does not work properly. The bit clocks and the frame sync signals
from the codec are not correct and hence the playback/record are faster
than usual for most sample rates. The reason for this was that the PLL
was not enabled when it was not bypassed.

Tested on DM6467 EVM, playback tested on DM355 EVM.

Signed-off-by: Chaithrika U S 
---
Applies to master branch of ALSA GIT tree at
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary

 sound/soc/codecs/tlv320aic3x.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index ab099f4..cb0d1bf 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -767,6 +767,7 @@ static int aic3x_hw_params(struct snd_pcm_substream 
*substream,
int codec_clk = 0, bypass_pll = 0, fsref, last_clk = 0;
u8 data, r, p, pll_q, pll_p = 1, pll_r = 1, pll_j = 1;
u16 pll_d = 1;
+   u8 reg;
 
/* select data word length */
data =
@@ -801,8 +802,16 @@ static int aic3x_hw_params(struct snd_pcm_substream 
*substream,
pll_q &= 0xf;
aic3x_write(codec, AIC3X_PLL_PROGA_REG, pll_q << PLLQ_SHIFT);
aic3x_write(codec, AIC3X_GPIOB_REG, CODEC_CLKIN_CLKDIV);
-   } else
+   /* disable PLL if it is bypassed */
+   reg = aic3x_read_reg_cache(codec, AIC3X_PLL_PROGA_REG);
+   aic3x_write(codec, AIC3X_PLL_PROGA_REG, reg & ~PLL_ENABLE);
+
+   } else {
aic3x_write(codec, AIC3X_GPIOB_REG, CODEC_CLKIN_PLLDIV);
+   /* enable PLL when it is used */
+   reg = aic3x_read_reg_cache(codec, AIC3X_PLL_PROGA_REG);
+   aic3x_write(codec, AIC3X_PLL_PROGA_REG, reg | PLL_ENABLE);
+   }
 
/* Route Left DAC to left channel input and
 * right DAC to right channel input */
-- 
1.5.6

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

[PATCH v2] mfd: Correct ro and cd implemantion on DM355

2009-07-22 Thread Vipin Bhandari 
This patch corrects the support for MMCSD card detection
and read only feature for SoC DM355.

EVMDM355_ECP_VA4.pdf, from Spectrum digital, suggests that
Bit 2 and 4 should be checked for card detection. However
on the EVM, bits 1 and 3 gives this status, for MMC/SD
instance 0 and 1 respectively. The pdf also suggests that
Bit 1 and 3 should be checked for write protection. However
on the EVM bits 2 and 4 gives this status.

This document can be downloaded from
http://c6000.spectrumdigital.com/evmdm355/reve/files/EVMDM355_ECP_VA4.pdf

Signed-off-by: Vipin Bhandari 
---
 This patch has been tested on DM355 EVM.

 Since the previous version, format of the multi-line comment
 has been corrected.

 drivers/mfd/dm355evm_msp.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
index 5b6e58a..3d4a861 100644
--- a/drivers/mfd/dm355evm_msp.c
+++ b/drivers/mfd/dm355evm_msp.c
@@ -107,8 +107,16 @@ static const u8 msp_gpios[] = {
MSP_GPIO(2, SWITCH1), MSP_GPIO(3, SWITCH1),
MSP_GPIO(4, SWITCH1),
/* switches on MMC/SD sockets */
-   MSP_GPIO(1, SDMMC), MSP_GPIO(2, SDMMC), /* mmc0 WP, nCD */
-   MSP_GPIO(3, SDMMC), MSP_GPIO(4, SDMMC), /* mmc1 WP, nCD */
+   /*
+* Note: EVMDM355_ECP_VA4.pdf suggests that Bit 2 and 4 should be
+* checked for card detection. However on the EVM bit 1 and 3 gives
+* this status, for 0 and 1 instance respectively. The pdf also
+* suggests that Bit 1 and 3 should be checked for write protection.
+* However on the EVM bit 2 and 4 gives this status,for 0 and 1
+* instance respectively.
+*/
+   MSP_GPIO(2, SDMMC), MSP_GPIO(1, SDMMC), /* mmc0 WP, nCD */
+   MSP_GPIO(4, SDMMC), MSP_GPIO(3, SDMMC), /* mmc1 WP, nCD */
 };
 
 #define MSP_GPIO_REG(offset)   (msp_gpios[(offset)] >> 3)
-- 
1.5.6

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

RE: [PATCH] mfd: Correct ro and cd implemantion on DM355

2009-07-22 Thread Vipin 
Thank you for the comments. I'll incorporate the same and send the updated
patch shortly.

Thanks and regards,
~Vipin


> -Original Message-
> From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
> Sent: Wednesday, July 22, 2009 5:41 PM
> To: Vipin Bhandari
> Cc: davinci-linux-open-source@linux.davincidsp.com
> Subject: Re: [PATCH] mfd: Correct ro and cd implemantion on DM355
> 
> Hello.
> 
> Vipin Bhandari wrote:
> 
> > This patch corrects the support for MMCSD card detection
> > and read only feature for SoC DM355.
> 
> > EVMDM355_ECP_VA4.pdf, from Spectrum digital, suggests that
> > Bit 2 and 4 should be checked for card detection. However
> > on the EVM, bits 1 and 3 gives this status, for MMC/SD
> > instance 0 and 1 respectively. The pdf also suggests that
> > Bit 1 and 3 should be checked for write protection. However
> > on the EVM bits 2 and 4 gives this status.
> 
> > This document can be downloaded from
> >
> http://c6000.spectrumdigital.com/evmdm355/reve/files/EVMDM355_ECP_VA4.p
> df
> 
> > Signed-off-by: Vipin Bhandari 
> > ---
> 
> [...]
> 
> > diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
> > index 5b6e58a..507fde0 100644
> > --- a/drivers/mfd/dm355evm_msp.c
> > +++ b/drivers/mfd/dm355evm_msp.c
> > @@ -107,8 +107,14 @@ static const u8 msp_gpios[] = {
> > MSP_GPIO(2, SWITCH1), MSP_GPIO(3, SWITCH1),
> > MSP_GPIO(4, SWITCH1),
> > /* switches on MMC/SD sockets */
> > -   MSP_GPIO(1, SDMMC), MSP_GPIO(2, SDMMC), /* mmc0 WP, nCD */
> > -   MSP_GPIO(3, SDMMC), MSP_GPIO(4, SDMMC), /* mmc1 WP, nCD */
> > +   /* Note: EVMDM355_ECP_VA4.pdf suggests that Bit 2 and 4 should be
> > +* checked for card detection. However on the EVM bit 1 and 3
> gives
> > +* this status, for 0 and 1 instance respectively. The pdf also
> > +* suggests that Bit 1 and 3 should be checked for write
> protection.
> > +* However on the EVM bit 2 and 4 gives this status,for 0 and 1
> > +* instance respectively */
> 
> Documentation/CodingStyle, chapter 8:
> 
> The preferred style for long (multi-line) comments is:
> 
> 
>  /*
>   * This is the preferred style for multi-line
>   * comments in the Linux kernel source code.
>   * Please use it consistently.
>   *
>   * Description:  A column of asterisks on the left side,
>   * with beginning and ending almost-blank lines.
>   */
> 
> WBR, Sergei


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

Re: [PATCH] mfd: Correct ro and cd implemantion on DM355

2009-07-22 Thread Sergei Shtylyov 

Hello.

Vipin Bhandari wrote:


This patch corrects the support for MMCSD card detection
and read only feature for SoC DM355.



EVMDM355_ECP_VA4.pdf, from Spectrum digital, suggests that
Bit 2 and 4 should be checked for card detection. However
on the EVM, bits 1 and 3 gives this status, for MMC/SD
instance 0 and 1 respectively. The pdf also suggests that
Bit 1 and 3 should be checked for write protection. However
on the EVM bits 2 and 4 gives this status.



This document can be downloaded from
http://c6000.spectrumdigital.com/evmdm355/reve/files/EVMDM355_ECP_VA4.pdf 



Signed-off-by: Vipin Bhandari 
---


[...]


diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
index 5b6e58a..507fde0 100644
--- a/drivers/mfd/dm355evm_msp.c
+++ b/drivers/mfd/dm355evm_msp.c
@@ -107,8 +107,14 @@ static const u8 msp_gpios[] = {
MSP_GPIO(2, SWITCH1), MSP_GPIO(3, SWITCH1),
MSP_GPIO(4, SWITCH1),
/* switches on MMC/SD sockets */
-   MSP_GPIO(1, SDMMC), MSP_GPIO(2, SDMMC), /* mmc0 WP, nCD */
-   MSP_GPIO(3, SDMMC), MSP_GPIO(4, SDMMC), /* mmc1 WP, nCD */
+   /* Note: EVMDM355_ECP_VA4.pdf suggests that Bit 2 and 4 should be
+* checked for card detection. However on the EVM bit 1 and 3 gives
+* this status, for 0 and 1 instance respectively. The pdf also
+* suggests that Bit 1 and 3 should be checked for write protection.
+* However on the EVM bit 2 and 4 gives this status,for 0 and 1
+* instance respectively */


   Documentation/CodingStyle, chapter 8:

The preferred style for long (multi-line) comments is:


/*
 * This is the preferred style for multi-line
 * comments in the Linux kernel source code.
 * Please use it consistently.
 *
 * Description:  A column of asterisks on the left side,
 * with beginning and ending almost-blank lines.
 */

WBR, Sergei

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

Re: problem while experimenting with g711enc

2009-07-22 Thread Ottavio Campana 
would you mind posting the header you're using?

On Wed, Jul 22, 2009 at 02:43:12PM +0530, Zuber wrote:
> One quick solution is to put 44 bytes wav header at the beginning of the 
> G711 encoded file.
> VLC will then recognize your clip and play it successfully. We have 
> tested it here. It works with vlc player.
> 
> Zuber Saiyed
> Embedded Engineer
> eInfochips Ltd.
> Tel. No. +91 79 26563705 Ext. 126
> Cell. No. +91 96621 33369
> www.einfochips.com
> 
> 
> 
> Ottavio Campana wrote:
> >mmm... 
> >
> >vlc output is
> >[0287] main playlist: nothing to play
> >so I suspect I'm missing an header or something similar...
> >
> >Do you add something at the beginning of the file? I currently just save
> >the encoded output.
> >
> >Ottavio
> >
> >On Wed, Jul 22, 2009 at 01:47:02PM +0530, bhushan wrote:
> >  
> >>Hi,
> >> You may have to download the g711 codec lib for a player such as winamp/
> >>vlc then play it.
> >>
> >>Bhushan
> >>
> >>On Wed, Jul 22, 2009 at 12:48 PM, Ottavio Campana <
> >>ottavio.camp...@dei.unipd.it> wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>I'm trying to use g711enc to  make some experiments. Everything seems to
> >>>work fine,  but I don't know  how I can  play the compressed file  I get
> >>>from the application.
> >>>
> >>>How do you play it?
> >>>
> >>>--
> >>>Non c'è più forza nella normalità, c'è solo monotonia.
> >>>
> >>>___
> >>>Davinci-linux-open-source mailing list
> >>>Davinci-linux-open-source@linux.davincidsp.com
> >>>http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> >>>
> >>>  
> >>
> >>-- 
> >>Bhushan
> >>
> >
> >  
> -- 
> _
> Disclaimer: This e-mail message and all attachments transmitted with it
> are intended solely for the use of the addressee and may contain legally
> privileged and confidential information. If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby
> notified that any dissemination, distribution, copying, or other use of
> this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any
> views expressed in this message are those of the individual sender
> unless otherwise stated.Company has taken enough precautions to prevent
> the spread of viruses. However the company accepts no liability for any
> damage caused by any virus transmitted by this email.
> _
> 

-- 
Non c'è più forza nella normalità, c'è solo monotonia.

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

How to use the fb-driver with the patch: davinci: fb: Frame Buffer driver for TI A8xx/OMAP-L1xx

2009-07-22 Thread Bastian Ruppert 
Hello, 
i try to enable the patch [PATCH] davinci: fb: Frame Buffer driver for TI 
A8xx/OMAP-L1xx from 
Sudhakar Rajashekhara.

I can enable the Framebuffersupport via menuconfig, and there is a functioncall 
to static int __init da8xx_fb_init(void)
(da8xx-fb.c) when running the driver on the target-device.

But the function static int __init fb_probe(struct platform_device *device) is 
never executed.

The question is: 
What is to do to treat the kernel to call the function static int __init 
fb_probe(struct platform_device *device)? 


Thank you very much.
Regards 
Bastian.

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

Re: fail to make uImage

2009-07-22 Thread zuowenping 
your toolchain version is not matched the kernel source,you must use 
toolchain5.0 above!


2009-07-22 



zuowenping 



发件人： linghai624 
发送时间： 2009-07-22  17:49:01 
收件人： davinci-linux-open-source 
抄送： 
主题： fail to make uImage 
 
Hi,
   I'am trying to use davinci linux git kernel 2.6.28 , but when I make uImage 
, I meet the error as follow,

hail...@hailing-desktop:~/workdir/lsp/linux/kernel/git/khilman/linux-davinci.git$
 make   ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage
scripts/kconfig/conf -s arch/arm/Kconfig
  CHK include/linux/version.h
  UPD include/linux/version.h
  Generating include/asm-arm/mach-types.h
  CHK include/linux/utsrelease.h
  UPD include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-arm
  CC  kernel/bounds.s
kernel/bounds.c:1: error: invalid ABI option: -mabi=aapcs-linux
make[1]: *** [kernel/bounds.s] Error 1
make: *** [prepare0] Error 2

I don't know what the problem it is ,please help me !





网易YEAH.NET免费邮箱：您的终身免费邮箱 
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH/RFC 1/1] recover from davinci i2c time out conditions

2009-07-22 Thread Philby John 
On Wed, 2009-07-22 at 04:03 -0700, Nitin Mahajan wrote:
> Hello,
> 
> - Original Message 
> > From: Philby John 
> > To: linux-...@vger.kernel.org
> > Cc: kh...@linux-fr.org; davinci-linux-open-source@linux.davincidsp.com
> > Sent: Wednesday, July 15, 2009 13:04:27
> > Subject: [PATCH/RFC 1/1] recover from davinci i2c time out conditions
> > 
> > >From dbe7e824d576636bb15b82a20fd2557fddc9a8f7 Mon Sep 17 00:00:00 2001
> > From: Philby John 
> > Date: Tue, 14 Jul 2009 21:46:47 +0530
> > Subject: [PATCH] Reset i2c bus to come out of time out conditions
> > 
> > Get out of i2c time out condition by resetting
> > the i2c bus. The kernel must be robust enough to
> > gracefully recover from i2c bus failure without having
> > to reset the machine. This is done by first NACKing the slave
> > and then resetting the i2c bus after a certain timeout.
> > 
> > Signed-off-by: Philby John 
> 
> I tried this on DM6443 based board with 2.6.18 kernel. The result I am 
> posting below. It gives controller time out again and again.
> 
> dhcppc9 login: i2c_davinci i2c_davinci.1: controller timed out
> i2c_davinci i2c_davinci.1: initiating i2c bus recovery
> i2c_davinci i2c_davinci.1: controller timed out
> i2c_davinci i2c_davinci.1: initiating i2c bus recovery


There is something gravely wrong about this patch and I would submit a
fix shortly incorporating the review comments. But please be aware that
I do not guarantee a definitive time line for a fix cause I have much at
hand at the moment.


Regards,
Philby


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

Re: [PATCH/RFC 1/1] recover from davinci i2c time out conditions

2009-07-22 Thread Nitin Mahajan 
Hello,



- Original Message 
> From: Philby John 
> To: linux-...@vger.kernel.org
> Cc: kh...@linux-fr.org; davinci-linux-open-source@linux.davincidsp.com
> Sent: Wednesday, July 15, 2009 13:04:27
> Subject: [PATCH/RFC 1/1] recover from davinci i2c time out conditions
> 
> >From dbe7e824d576636bb15b82a20fd2557fddc9a8f7 Mon Sep 17 00:00:00 2001
> From: Philby John 
> Date: Tue, 14 Jul 2009 21:46:47 +0530
> Subject: [PATCH] Reset i2c bus to come out of time out conditions
> 
> Get out of i2c time out condition by resetting
> the i2c bus. The kernel must be robust enough to
> gracefully recover from i2c bus failure without having
> to reset the machine. This is done by first NACKing the slave
> and then resetting the i2c bus after a certain timeout.
> 
> Signed-off-by: Philby John 

I tried this on DM6443 based board with 2.6.18 kernel. The result I am posting 
below. It gives controller time out again and again.

dhcppc9 login: i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery

regards

-Nitin
> ---
> drivers/i2c/busses/i2c-davinci.c |   98 +++--
> 1 files changed, 92 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-davinci.c 
> b/drivers/i2c/busses/i2c-davinci.c
> index 17f2ee7..4ed1a4c 100755
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -35,14 +35,18 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include 
> 
> #include 
> +#include 
> +#include 
> 
> /* - global defines --- */
> 
> #define DAVINCI_I2C_TIMEOUT(1*HZ)
> +#define DAVINCI_I2C_MAX_TRIES2
> #define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
>  DAVINCI_I2C_IMR_SCD | \
>  DAVINCI_I2C_IMR_ARDY | \
> @@ -135,6 +139,50 @@ static inline u16 davinci_i2c_read_reg(struct 
> davinci_i2c_dev *i2c_dev, int reg)
> }
> 
> /*
> + * Configure the i2c data pin as a GPIO input and the i2c clock pin as a
> + * high GPIO output.
> + */
> +static void disable_i2c_pins(void)
> +{
> +unsigned long flags;
> +
> +local_irq_save(flags);
> +if (cpu_is_davinci_dm355()) {
> +gpio_direction_input(15);
> +gpio_direction_output(14, 0);
> +gpio_set_value(14, 1);
> +davinci_cfg_reg(DM355_I2C_SDA);
> +davinci_cfg_reg(DM355_I2C_SCL);
> +}
> +local_irq_restore(flags);
> +}
> +
> +/* Connect the i2c pins to the i2c controller. */
> +static void enable_i2c_pins(void)
> +{
> +unsigned long flags;
> +
> +local_irq_save(flags);
> +if (cpu_is_davinci_dm355()) {
> +davinci_cfg_reg(DM355_I2C_SDA);
> +davinci_cfg_reg(DM355_I2C_SCL);
> +}
> +local_irq_restore(flags);
> +}
> +
> +
> +/* Generate a pulse on the i2c clock pin. */
> +static void pulse_i2c_clock(void)
> +{
> +if (cpu_is_davinci_dm355()) {
> +gpio_set_value(14, 0);
> +udelay(20);
> +gpio_set_value(14, 1);
> +udelay(20);
> +}
> +}
> +
> +/*
>   * This functions configures I2C and brings I2C out of reset.
>   * This function is called during I2C init function. This function
>   * also gets called if I2C encounters any errors.
> @@ -221,14 +269,36 @@ static int i2c_davinci_wait_bus_not_busy(struct 
> davinci_i2c_dev *dev,
>  char allow_sleep)
> {
> unsigned long timeout;
> +u16 i;
> +static u16 to_cnt = 0;
> +u32 flag = 0;
> 
> timeout = jiffies + dev->adapter.timeout;
> while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
> -   & DAVINCI_I2C_STR_BB) {
> -if (time_after(jiffies, timeout)) {
> -dev_warn(dev->dev,
> - "timeout waiting for bus ready\n");
> -return -ETIMEDOUT;
> +& DAVINCI_I2C_STR_BB) {
> +
> +if (to_cnt <= DAVINCI_I2C_MAX_TRIES) {
> +if (time_after(jiffies, timeout)) {
> +d

RE: [PATCH] davinci: Correct ro and cd feature in DM355

2009-07-22 Thread Vipin 

Thank you for the suggestion. I'll submit the patch again with the desired
changes.

Thanks and regards,
~Vipin


> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Wednesday, July 22, 2009 3:25 PM
> To: davinci-linux-open-source@linux.davincidsp.com; Vipin Bhandari
> Subject: Re: [PATCH] davinci: Correct ro and cd feature in DM355
> 
> On Tuesday 21 July 2009, Vipin Bhandari wrote:
> > This patch corrects the support for MMCSD card detection
> > and read only feature for SoC DM355.
> >
> > Signed-off-by: Vipin Bhandari 
> > ---
> >  This patch has been tested on DM355 EVM.
> 
> 
> I don't follow.  It does seem like some indices in
> the current driver, drivers/mfd/dm355evm_msp.c, may
> need to swap ... but why would a patch changing two
> lines of code need to get blown up into
> 
> >
> >  arch/arm/mach-davinci/board-dm355-evm.c |  107
> +++---
> >  1 files changed, 82 insertions(+), 25 deletions(-)
> 
>  107 lines of changes, breaking the RTC and IR/Remote
> drivers in the process
> 
> NAK on this patch.
> 
> It looks like you should only need to swap two index
> pairs in the drivers/mfd code, and add a comment about
> how the docs are wrong.
> 
> - Dave
> 
> 



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

[PATCH] mfd: Correct ro and cd implemantion on DM355

2009-07-22 Thread Vipin Bhandari 
This patch corrects the support for MMCSD card detection
and read only feature for SoC DM355.

EVMDM355_ECP_VA4.pdf, from Spectrum digital, suggests that
Bit 2 and 4 should be checked for card detection. However
on the EVM, bits 1 and 3 gives this status, for MMC/SD
instance 0 and 1 respectively. The pdf also suggests that
Bit 1 and 3 should be checked for write protection. However
on the EVM bits 2 and 4 gives this status.

This document can be downloaded from
http://c6000.spectrumdigital.com/evmdm355/reve/files/EVMDM355_ECP_VA4.pdf 

Signed-off-by: Vipin Bhandari 
---
 This patch has been tested on DM355 EVM.

 drivers/mfd/dm355evm_msp.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
index 5b6e58a..507fde0 100644
--- a/drivers/mfd/dm355evm_msp.c
+++ b/drivers/mfd/dm355evm_msp.c
@@ -107,8 +107,14 @@ static const u8 msp_gpios[] = {
MSP_GPIO(2, SWITCH1), MSP_GPIO(3, SWITCH1),
MSP_GPIO(4, SWITCH1),
/* switches on MMC/SD sockets */
-   MSP_GPIO(1, SDMMC), MSP_GPIO(2, SDMMC), /* mmc0 WP, nCD */
-   MSP_GPIO(3, SDMMC), MSP_GPIO(4, SDMMC), /* mmc1 WP, nCD */
+   /* Note: EVMDM355_ECP_VA4.pdf suggests that Bit 2 and 4 should be
+* checked for card detection. However on the EVM bit 1 and 3 gives
+* this status, for 0 and 1 instance respectively. The pdf also
+* suggests that Bit 1 and 3 should be checked for write protection.
+* However on the EVM bit 2 and 4 gives this status,for 0 and 1
+* instance respectively */
+   MSP_GPIO(2, SDMMC), MSP_GPIO(1, SDMMC), /* mmc0 WP, nCD */
+   MSP_GPIO(4, SDMMC), MSP_GPIO(3, SDMMC), /* mmc1 WP, nCD */
 };
 
 #define MSP_GPIO_REG(offset)   (msp_gpios[(offset)] >> 3)
-- 
1.5.6

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

Re: [PATCH] davinci: Correct ro and cd feature in DM355

2009-07-22 Thread David Brownell 
On Tuesday 21 July 2009, Vipin Bhandari wrote:
> This patch corrects the support for MMCSD card detection
> and read only feature for SoC DM355.
> 
> Signed-off-by: Vipin Bhandari 
> ---
>  This patch has been tested on DM355 EVM.


I don't follow.  It does seem like some indices in
the current driver, drivers/mfd/dm355evm_msp.c, may
need to swap ... but why would a patch changing two
lines of code need to get blown up into

> 
>  arch/arm/mach-davinci/board-dm355-evm.c |  107 +++---
>  1 files changed, 82 insertions(+), 25 deletions(-)

 107 lines of changes, breaking the RTC and IR/Remote
drivers in the process

NAK on this patch.

It looks like you should only need to swap two index
pairs in the drivers/mfd code, and add a comment about
how the docs are wrong.

- Dave




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

failed to import nfs server on dm6446

2009-07-22 Thread 黄守旺 
hellow everybody , i want to import nfs server on my davinci dm6446 board so 
that my SD memory can be accessed  remotely.

my steps are below

1:i copy  the files from  /mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/target/
cp  nfs-kernel-server/etc/init.d/

cp   rpc.mountd/usr/sbin
cp   rpc.nfsd   /usr/sbin
cp   exportfs  /usr/sbin


2: my exports is below
/home/nfs 192.168.8.*(rw,no_root_squash,no_all_squash,sync) 


3::i touch the files below:
touch /var/lib/nfs/etab 
touch /var/lib/nfs/rmtab 
touch /var/lib/nfs/state 
touch /var/lib/nfs/xtab
chmod 644 /var/lib/nfs/etab 
chmod 644 /var/lib/nfs/rmtab 
chmod 644 /var/lib/nfs/state 
chmod 644 /var/lib/nfs/xtab

4:i succeed to start the nfs server, on my SuSe PC,i get the info below when i  
run "showmount -e 192.168.8.113 "

Export list for 192.168.8.113:
/home/nfs 192.168.8.*


5:but when my PC try to " mount -t nfs 192.168.8.113:/home/nfs  /mnt",  i get 
the error message below:
 
 mount: 192.168.8.113:/home/nfs failed, reason given by server: Permission 
denied 


and my board log message is below:
Jan  1 00:51:39 rpc.mountd: authenticated mount request from 
192.168.8.109:926 for /mnt (/mnt)
Jan  1 00:51:39 rpc.mountd: getfh failed: Operation not permitted




thanks for any advice!
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: i2c "controller timed out\n" not able to recover

2009-07-22 Thread Madhu K 
Hi,
Its problem with the hardware.
In I2C device read/write wont generate stop bit properly.
So you need to disable after every write/read transaction.then re-enable
the I2c device.

The IRS bit in mode register of the device.Disable it and re-enable it.

On Wed, Jul 22, 2009 at 2:01 PM, Nitin Mahajan  wrote:

> HI!
>
> I have a DM6443 based board and a chip similar to the MSP430 on the
> development board communicating over i2c.
> I am getting  the error "controller timed out\n", while trying to send some
> command over i2c and reading some data over it.
>
> Can some one please help me understand what can be the cause of such
> timeout?
>
> Also a reinitialization which is triggered after such an error doesn't seem
> to be happening properly. After this error I keep getting the errors
> "timeout waiting for bus ready\n" from the function i2c_davinci_xfer() if
> any data transfer is attempted.
>
> Can somebody help me understanding why is it so?
>
> regards
>
> -Nitin
>
>
>
>  New Email names for you!
> Get the Email name you've always wanted on the new @ymail and @rocketmail.
> Hurry before someone else does!
> http://mail.promotions.yahoo.com/newdomains/aa/
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>



-- 
With Sweet Regards!!!
Madhura
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: problem while experimenting with g711enc

2009-07-22 Thread Zuber 
One quick solution is to put 44 bytes wav header at the beginning of the 
G711 encoded file.
VLC will then recognize your clip and play it successfully. We have 
tested it here. It works with vlc player.


Zuber Saiyed
Embedded Engineer
eInfochips Ltd.
Tel. No. +91 79 26563705 Ext. 126
Cell. No. +91 96621 33369
www.einfochips.com



Ottavio Campana wrote:
mmm... 


vlc output is
[0287] main playlist: nothing to play
so I suspect I'm missing an header or something similar...

Do you add something at the beginning of the file? I currently just save
the encoded output.

Ottavio

On Wed, Jul 22, 2009 at 01:47:02PM +0530, bhushan wrote:
  

Hi,
 You may have to download the g711 codec lib for a player such as winamp/
vlc then play it.

Bhushan

On Wed, Jul 22, 2009 at 12:48 PM, Ottavio Campana <
ottavio.camp...@dei.unipd.it> wrote:



Hi,

I'm trying to use g711enc to  make some experiments. Everything seems to
work fine,  but I don't know  how I can  play the compressed file  I get
from the application.

How do you play it?

--
Non c'è più forza nella normalità, c'è solo monotonia.

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

  


--
Bhushan



  

--
_
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_


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

fail to make uImage

2009-07-22 Thread linghai624 
Hi,
   I'am trying to use davinci linux git kernel 2.6.28 , but when I make uImage 
, I meet the error as follow,

hail...@hailing-desktop:~/workdir/lsp/linux/kernel/git/khilman/linux-davinci.git$
 make   ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage
scripts/kconfig/conf -s arch/arm/Kconfig
  CHK include/linux/version.h
  UPD include/linux/version.h
  Generating include/asm-arm/mach-types.h
  CHK include/linux/utsrelease.h
  UPD include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-arm
  CC  kernel/bounds.s
kernel/bounds.c:1: error: invalid ABI option: -mabi=aapcs-linux
make[1]: *** [kernel/bounds.s] Error 1
make: *** [prepare0] Error 2

I don't know what the problem it is ,please help me !

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

i2c "controller timed out\n" not able to recover

2009-07-22 Thread Nitin Mahajan 
HI!

I have a DM6443 based board and a chip similar to the MSP430 on the development 
board communicating over i2c.
I am getting  the error "controller timed out\n", while trying to send some 
command over i2c and reading some data over it.

Can some one please help me understand what can be the cause of such timeout? 

Also a reinitialization which is triggered after such an error doesn't seem to 
be happening properly. After this error I keep getting the errors
"timeout waiting for bus ready\n" from the function i2c_davinci_xfer() if any 
data transfer is attempted. 

Can somebody help me understanding why is it so?

regards

-Nitin



  New Email names for you! 
Get the Email name you've always wanted on the new @ymail and @rocketmail. 
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/

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

Re: problem while experimenting with g711enc

2009-07-22 Thread Ottavio Campana 
mmm... 

vlc output is
[0287] main playlist: nothing to play
so I suspect I'm missing an header or something similar...

Do you add something at the beginning of the file? I currently just save
the encoded output.

Ottavio

On Wed, Jul 22, 2009 at 01:47:02PM +0530, bhushan wrote:
> Hi,
>  You may have to download the g711 codec lib for a player such as winamp/
> vlc then play it.
> 
> Bhushan
> 
> On Wed, Jul 22, 2009 at 12:48 PM, Ottavio Campana <
> ottavio.camp...@dei.unipd.it> wrote:
> 
> > Hi,
> >
> > I'm trying to use g711enc to  make some experiments. Everything seems to
> > work fine,  but I don't know  how I can  play the compressed file  I get
> > from the application.
> >
> > How do you play it?
> >
> > --
> > Non c'è più forza nella normalità, c'è solo monotonia.
> >
> > ___
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source@linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> >
> 
> 
> 
> -- 
> Bhushan

-- 
Non c'è più forza nella normalità, c'è solo monotonia.

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

Re: problem while experimenting with g711enc

2009-07-22 Thread bhushan 
Hi,
 You may have to download the g711 codec lib for a player such as winamp/
vlc then play it.

Bhushan

On Wed, Jul 22, 2009 at 12:48 PM, Ottavio Campana <
ottavio.camp...@dei.unipd.it> wrote:

> Hi,
>
> I'm trying to use g711enc to  make some experiments. Everything seems to
> work fine,  but I don't know  how I can  play the compressed file  I get
> from the application.
>
> How do you play it?
>
> --
> Non c'è più forza nella normalità, c'è solo monotonia.
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>



-- 
Bhushan
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: problem while experimenting with g711enc

2009-07-22 Thread Zuber 

Hi Ottavio,

You can use Adobe Audition tool to play this g711 encoded file. You can 
download this tool from www.adobe.com


Zuber Saiyed
Embedded Engineer
eInfochips Ltd.
Tel. No. +91 79 26563705 Ext. 126
Cell. No. +91 96621 33369
www.einfochips.com



Ottavio Campana wrote:

Hi,

I'm trying to use g711enc to  make some experiments. Everything seems to
work fine,  but I don't know  how I can  play the compressed file  I get
from the application.

How do you play it?

  

--
_
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_


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

VPBE/DAC Clocking

2009-07-22 Thread Ferhat OLGUN 
Hi,

For my 480x272 TFT LCD I want to generate a 9Mhz VCLK using PLL2 mode
(sprue14b 5.2.5). In order to do that I want to set

-PLLM of PLL2 to "x10"
-PLLDIV1 to "/15"
-PLLDIV2 to "/1"
-VENC_DIV_2 to "/2"

so that I can modify 27MHz MXI to x10 /15 /2 = 9 MHz.
and I also want to set the timing signals for proper sync. signals in
logicpd_encoder.c.

but I could not find in which portion of the code these PLL registers are
initialized. Could you please help me to change these registers? Is there
any documents, application reports and patches which help me to modify the
VPBE driver for different resolution LCDs?

Ferhat
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

problem while experimenting with g711enc

2009-07-22 Thread Ottavio Campana 
Hi,

I'm trying to use g711enc to  make some experiments. Everything seems to
work fine,  but I don't know  how I can  play the compressed file  I get
from the application.

How do you play it?

-- 
Non c'è più forza nella normalità, c'è solo monotonia.

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

[PATCH] davinci: Correct ro and cd feature in DM355

2009-07-22 Thread Vipin Bhandari 
This patch corrects the support for MMCSD card detection
and read only feature for SoC DM355.

Signed-off-by: Vipin Bhandari 
---
 This patch has been tested on DM355 EVM.

 arch/arm/mach-davinci/board-dm355-evm.c |  107 +++---
 1 files changed, 82 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index ff55c52..92c3781 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -113,6 +113,37 @@ static struct platform_device davinci_nand_device = {
},
 };
 
+
+/*
+ * MSP430 supports card detection and write protection checking
+ */
+static struct i2c_client *dm355evm_msp;
+
+static int dm355evm_msp_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   dm355evm_msp = client;
+   return 0;
+}
+
+static int dm355evm_msp_remove(struct i2c_client *client)
+{
+   dm355evm_msp = NULL;
+   return 0;
+}
+
+static const struct i2c_device_id dm355evm_msp_ids[] = {
+   { "dm355evm_msp", 0, },
+   { /* end of list */ },
+};
+
+static struct i2c_driver dm355evm_msp_driver = {
+   .driver.name= "dm355evm_msp",
+   .id_table   = dm355evm_msp_ids,
+   .probe  = dm355evm_msp_probe,
+   .remove = dm355evm_msp_remove,
+};
+
 static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq   = 400   /* kHz */,
.bus_delay  = 0 /* usec */,
@@ -120,25 +151,9 @@ static struct davinci_i2c_platform_data i2c_pdata = {
 
 static struct snd_platform_data dm355_evm_snd_data;
 
-static int dm355evm_mmc_gpios = -EINVAL;
-
-static void dm355evm_mmcsd_gpios(unsigned gpio)
-{
-   gpio_request(gpio + 0, "mmc0_ro");
-   gpio_request(gpio + 1, "mmc0_cd");
-   gpio_request(gpio + 2, "mmc1_ro");
-   gpio_request(gpio + 3, "mmc1_cd");
 
-   /* we "know" these are input-only so we don't
-* need to call gpio_direction_input()
-*/
-
-   dm355evm_mmc_gpios = gpio;
-}
-
-static struct i2c_board_info dm355evm_i2c_info[] = {
+static struct i2c_board_info __initdata dm355evm_i2c_info[] = {
{ I2C_BOARD_INFO("dm355evm_msp", 0x25),
-   .platform_data = dm355evm_mmcsd_gpios,
/* plus irq */ },
/* { I2C_BOARD_INFO("tlv320aic3x", 0x1b), }, */
/* { I2C_BOARD_INFO("tvp5146", 0x5d), }, */
@@ -152,6 +167,8 @@ static void __init evm_init_i2c(void)
gpio_direction_input(5);
dm355evm_i2c_info[0].irq = gpio_to_irq(5);
 
+   i2c_add_driver(&dm355evm_msp_driver);
+
i2c_register_board_info(1, dm355evm_i2c_info,
ARRAY_SIZE(dm355evm_i2c_info));
 }
@@ -194,20 +211,60 @@ static void __init dm355_evm_map_io(void)
dm355_init();
 }
 
-static int dm355evm_mmc_get_cd(int module)
+static int dm355evm_msp430_get_pins(void)
 {
-   if (!gpio_is_valid(dm355evm_mmc_gpios))
+   static const char txbuf[1] = {0x06};
+   char buf[1];
+   struct i2c_msg msg[2] = {
+   {
+   .addr = dm355evm_msp->addr,
+   .flags = 0,
+   .len = 1,
+   .buf = (void __force *)txbuf,
+   },
+   {
+   .addr = dm355evm_msp->addr,
+   .flags = I2C_M_RD,
+   .len = 1,
+   .buf = buf,
+   },
+   };
+   int status;
+
+   if (!dm355evm_msp)
return -ENXIO;
-   /* low == card present */
-   return !gpio_get_value_cansleep(dm355evm_mmc_gpios + 2 * module + 1);
+
+   status = i2c_transfer(dm355evm_msp->adapter, msg, 2);
+   if (status < 0)
+   return status;
+
+   return buf[0];
+}
+
+static int dm355evm_mmc_get_cd(int module)
+{
+   int status = dm355evm_msp430_get_pins();
+   /* Bit value low == card present */
+   /* Note: EVMDM355_ECP_VA4.pdf suggests that Bit 2 and 4 should
+* be checked for card detection. However on the EVM bit 1 and 3 gives
+* this status, respectively for 0 and 1 instance */
+   if (module == 0)
+   return (status < 0) ? status : !(status & BIT(1));
+   else
+   return (status < 0) ? status : !(status & BIT(3));
 }
 
 static int dm355evm_mmc_get_ro(int module)
 {
-   if (!gpio_is_valid(dm355evm_mmc_gpios))
-   return -ENXIO;
-   /* high == card's write protect switch active */
-   return gpio_get_value_cansleep(dm355evm_mmc_gpios + 2 * module + 0);
+   int status = dm355evm_msp430_get_pins();
+   /* Bit value high == card's write protect switch active */
+   /* Note: EVMDM355_ECP_VA4.pdf suggests that Bit 1 and 3 should
+* be checked for card detection. However on the EVM bit 2 and 4 gives
+* this status, respectively for 0 and 1 instance */
+   if (module == 0)
+   return