Re: [RFC][PATCH] DSPBRIDGE: Video Playback Cache Optimization

2009-06-10 Thread Hiroshi DOYU 
From: ext Ramirez Luna, Omar omar.rami...@ti.com
Subject: RE: [RFC][PATCH] DSPBRIDGE: Video Playback Cache Optimization
Date: Wed, 10 Jun 2009 01:18:29 +0200

 Hi,
 
 [sending as plain text to l-o]
 
 Could you please comment on this patch.
 
 From: Sripal Bagadia baga...@ti.com
 Date: Tue, 9 Jun 2009 16:05:09 -0500
 Subject: [PATCH] DSPBRIDGE: Video Playback Cache Optimization
 
 Avoid get_user_pages cache flush overheads for uncached  reserved
 buffers (e.g. display  camera buffers).

Would it be possible to tell the case/path,
where no L_PTE_CACHEABLE/L_PTE_BUFFERABLE is set with VM_IO/VM_RESERVED ?

 
 Signed-off-by: Sripal Bagadia baga...@ti.com
 ---
  drivers/dsp/bridge/wmd/tiomap3430.c |    4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c 
 b/drivers/dsp/bridge/wmd/tiomap3430.c
 index 7a9603d..a2f32e8 100644
 --- a/drivers/dsp/bridge/wmd/tiomap3430.c
 +++ b/drivers/dsp/bridge/wmd/tiomap3430.c
 @@ -1461,7 +1461,9 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT 
 *hDevContext,
     goto func_cont;
   }
  
 - if (vma-vm_flags  VM_IO) {
 + if ((vma-vm_flags  VM_IO) | ((vma-vm_flags  VM_RESERVED)  
 + (~pgprot_val(vma-vm_page_prot)  L_PTE_CACHEABLE) 
 + (~pgprot_val(vma-vm_page_prot)  L_PTE_BUFFERABLE))) {
     numUsrPgs =  ulNumBytes / PG_SIZE_4K;
     mpuAddr = ulMpuAddr;
     DBG_Trace(DBG_LEVEL4, WMD_BRD_MemMap:numOfActualTabEntries=%d,
 -- 
 1.6.2.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] Please help in adding ams-delta support to ASoC

2009-06-10 Thread Peter Ujfalusi 
On Tuesday 09 June 2009 18:17:42 ext Janusz Krzysztofik wrote:
 Peter Ujfalusi wrote:
  I'm kind of bad at visualizing things, is it possible to put somewhere
  the screenshoot of the scope showing at least one sample?

 Good idea. I'll take some screenshots for future reference and let you
 know when available.

  I have been looking for clues around the net, and it seams that the codec
  in question has stereo 16 bit format.

  From the very minimal mcbsp setup I get best audio experience with
 (using original omap-alsa based driver - see below), it looks like the
 codec speeks DSP (single phase), 16-bit mono @8kHz on output, but 8-bit
 stereo @8kHz on input. Capturing one channel only (the first one) I
 can't hear myself speaking, so audio from the microphone must be sent
 over the second input channel.

 +static struct omap_mcbsp_reg_cfg mcbsp_regs = {
 +   .spcr2 = FREE | XINTM(3) | XRST,
 +   .spcr1 = RINTM(3) | RRST,
 +   .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
 +   .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
 +};


 +static snd_pcm_hardware_t vc_snd_omap_alsa_playback = {
 +   .info = (SNDRV_PCM_INFO_INTERLEAVED |
 SNDRV_PCM_INFO_BLOCK_TRANSFER |
 +SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
 +   .formats = (SNDRV_PCM_FMTBIT_S16_LE),
 +   .rates = (SNDRV_PCM_RATE_8000 |
 + SNDRV_PCM_RATE_KNOT),
 +   .rate_min = 8000,
 +   .rate_max = 8000,
 +   .channels_min = 1,
 +   .channels_max = 1,
 +   .buffer_bytes_max = 128 * 1024,
 +   .period_bytes_min = 32,
 +   .period_bytes_max = 8 * 1024,
 +   .periods_min = 16,
 +   .periods_max = 255,
 +   .fifo_size = 0,
 +};
 +
 +static snd_pcm_hardware_t vc_snd_omap_alsa_capture = {
 +   .info = (SNDRV_PCM_INFO_INTERLEAVED |
 SNDRV_PCM_INFO_BLOCK_TRANSFER |
 +SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
 +   .formats = (SNDRV_PCM_FMTBIT_U8),
 +   .rates = (SNDRV_PCM_RATE_8000 |
 + SNDRV_PCM_RATE_KNOT),
 +   .rate_min = 8000,
 +   .rate_max = 8000,
 +   .channels_min = 2,
 +   .channels_max = 2,
 +   .buffer_bytes_max = 128 * 1024,
 +   .period_bytes_min = 32,
 +   .period_bytes_max = 8 * 1024,
 +   .periods_min = 16,
 +   .periods_max = 255,
 +   .fifo_size = 0,
 +};

 For other combinations of single/dual phase, sample size, mono/stereo,
 sound I get is much more distorted. Playing with polarisation and delays
 for getting still better experience remains on my todo list.

 BTW, I can't see any way of specifying a similiar mcbsp setup in new
 omap asoc framework.

Yeah, 8 bit is not supported - in fact only 16 bit is supported - with ASoC on 
OMAP.
But you should be able to use the playback with the current ASoC.


 --

  --- a/sound/soc/omap/omap-pcm.c
  +++ b/sound/soc/omap/omap-pcm.c
  @@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct
  snd_pcm_substream *substream, int cmd)
  case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
  prtd-period_index = 0;
  omap_start_dma(prtd-dma_ch);
  +   printk(omap_pcm_trigger START: DMA pointer at 0x%08x\n,
  +   (unsigned)omap_get_dma_src_pos(prtd-dma_ch));
  break;
 
  case SNDRV_PCM_TRIGGER_STOP:
  case SNDRV_PCM_TRIGGER_SUSPEND:
  case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
  +   printk(omap_pcm_trigger STOP: DMA pointer at 0x%08x\n,
  +   (unsigned)omap_get_dma_src_pos(prtd-dma_ch));
  prtd-period_index = -1;
  omap_stop_dma(prtd-dma_ch);
  break;
 
 
  Than start a playback, and stop it with CTRL+C, see if the two pointers
  are different...

 Both playback and capture start with their own but always the same value
 (something like 0x1101a0d0 for playback, 0xe101a0d0 for capture), and
 always stop with this value unchanged.

Hmm, this means that the DMA was not running at all (since it has not been 
progressed). So you might have the missing DMA interrupt problem, but first we 
should get the DMA to actually run.
Looking at the dma code for clues...
Even bigger Hmmm...
For OMAP1 the DMA synchronization is not configured.
I just wonder how this supposed to be working on OMAP1 platforms.
Anyway, can you try the following patch (and please keep the previous printk 
in the omap-pcm.c):

--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int data_type, 
int elem_count,
ccr = ~(1  5);
if (sync_mode == OMAP_DMA_SYNC_FRAME)
ccr |= 1  5;
+   if (dma_trigger)
+   ccr |= dma_trigger  0x1f;
dma_write(ccr, CCR(lch));

ccr = dma_read(CCR2(lch));

in the  if (cpu_class_is_omap1()) { path...

The interesting thing is the following:
the old ALSA

Re: [alsa-devel] Please help in adding ams-delta support to ASoC

2009-06-10 Thread Janusz Krzysztofik 
Hi Peter,

Wednesday 10 June 2009 10:12:32 Peter Ujfalusi napisał(a):
 On Tuesday 09 June 2009 18:17:42 ext Janusz Krzysztofik wrote:
  +static struct omap_mcbsp_reg_cfg mcbsp_regs = {
  +   .spcr2 = FREE | XINTM(3) | XRST,
  +   .spcr1 = RINTM(3) | RRST,
  +   .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
  +   .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
  +};
 
  BTW, I can't see any way of specifying a similiar mcbsp setup in new
  omap asoc framework.

 Yeah, 8 bit is not supported - in fact only 16 bit is supported - with ASoC
 on OMAP.

Not only this. AFAICS, there is no way of specifying single phase stereo (with 
XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)). Isn't this 
required for correct DSP_A/DSP_B support?

 But you should be able to use the playback with the current ASoC.

Definitelly yes. I am aware that the above limitations have nothing to do with 
the main problem, as with current mcbsp code I should always be able to get 
some kind of noise at least using one of supported formats, as far as 
clocking is set up correctly.

 --- a/arch/arm/plat-omap/dma.c
 +++ b/arch/arm/plat-omap/dma.c
 @@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int
 data_type, int elem_count,
 ccr = ~(1  5);
 if (sync_mode == OMAP_DMA_SYNC_FRAME)
 ccr |= 1  5;
 +   if (dma_trigger)
 +   ccr |= dma_trigger  0x1f;
 dma_write(ccr, CCR(lch));

 ccr = dma_read(CCR2(lch));

Applied, sorry, did not help (with capture, unlike playback, set up for 
internal clocking for as much device isolation as possible).

# aplay -D hw:0,0 -f S16_LE /dev/urandom
Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 8000 Hz, 
Mono
omap_pcm_trigger START: DMA pointer at 0x11d4a0d0
omap_pcm_trigger STOP: DMA pointer at 0x11d4a0d0 error
# arecord -D hw:0,0 -f S16_LE -t raw /dev/null
Recording raw data '/dev/null' : Signed 16 bit Little Endian, Rate 8000 Hz, 
Mono
omap_pcm_trigger START: DMA pointer at 0xe101a0d0
arecord: pcm_read:1529: read error: Input/output error
omap_pcm_trigger STOP: DMA pointer at 0xe101a0d0
# cat /dev/urandom /dev/dsp
omap_pcm_trigger START: DMA pointer at 0x11d4a0d0
cat: write error: Input/output error
omap_pcm_trigger STOP: DMA pointer at 0x11d4a0d0
# cat /dev/dsp /dev/null
omap_pcm_trigger START: DMA pointer at 0xe101a0d0
cat: read error: Input/output eromap_pcm_trigger STOP: DMA pointer at 
0xe101a0d0
ror
#

BTW, I have found that, when invoked with those -D hw:0,0 -f SE16_LE 
options, aplay/arecord behave correctly, exactly as Mark has pointed out once 
at the beginning of this huge thread, stopping themselves after 10 seconds 
with an error message, without need for ^C.

 I would expected that by just copying (I know that there are other things
 involved) the old ALSA arm directory to the latest kernel and compiling it
 should be working... It seams I was wrong.

Anyway, if you find porting one or another framework, back or forward, 
helpfull in any way, just let me know, I can try.

Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] Please help in adding ams-delta support to ASoC

2009-06-10 Thread Peter Ujfalusi 
On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote:
 Not only this. AFAICS, there is no way of specifying single phase stereo
 (with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)).
 Isn't this required for correct DSP_A/DSP_B support?

Sure it is possible:
format = mcbsp_data-fmt  SND_SOC_DAIFMT_FORMAT_MASK;
wpf = channels = params_channels(params);
switch (channels) {
case 2:
if (format == SND_SOC_DAIFMT_I2S) {
/* Use dual-phase frames */
regs-rcr2  |= RPHASE;
regs-xcr2  |= XPHASE;
/* Set 1 word per (McBSP) frame for phase1 and phase2 */
wpf--;
regs-rcr2  |= RFRLEN2(wpf - 1);
regs-xcr2  |= XFRLEN2(wpf - 1);
}
case 1:
case 4:
/* Set word per (McBSP) frame for phase1 */
regs-rcr1  |= RFRLEN1(wpf - 1);
regs-xcr1  |= XFRLEN1(wpf - 1);
break;
default:
/* Unsupported number of channels */
return -EINVAL;
}

wpf = channels == 2, format is not I2S -- RFRLEN1(wpf - 1), XFRLEN1(wpf - 1), 
RFRLEN1(2 - 1), XFRLEN1(2 - 1)


  But you should be able to use the playback with the current ASoC.

 Definitelly yes. I am aware that the above limitations have nothing to do
 with the main problem, as with current mcbsp code I should always be able
 to get some kind of noise at least using one of supported formats, as far
 as clocking is set up correctly.

  --- a/arch/arm/plat-omap/dma.c
  +++ b/arch/arm/plat-omap/dma.c
  @@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int
  data_type, int elem_count,
  ccr = ~(1  5);
  if (sync_mode == OMAP_DMA_SYNC_FRAME)
  ccr |= 1  5;
  +   if (dma_trigger)
  +   ccr |= dma_trigger  0x1f;
  dma_write(ccr, CCR(lch));
 
  ccr = dma_read(CCR2(lch));

 Applied, sorry, did not help (with capture, unlike playback, set up for
 internal clocking for as much device isolation as possible).

I would have guessed this, since even when the DMA was not HW synced, it did 
not sent a single bit to the McBSP DXR1 register...

Just out of curiosity, can you try this one as well:

--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -191,6 +191,7 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream 
*substream, int cmd,
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
if (!mcbsp_data-active++)
omap_mcbsp_start(mcbsp_data-bus_id);
+   omap_mcbsp_pollwrite(mcbsp_data-bus_id, 0xdb55);
break;

basically write 0xdb55 to the DXR1 register (0xdb55 is 1101101101010101)
With this, if McBSP is operating correctly you should be seeing this pattern 
going to the codec. If it does, than we have some problems with the McBSP/DMA 
cooperation, if this pattern is not seen on the bus, than the McBSP is not 
shifting data out for some reason.


  I would expected that by just copying (I know that there are other things
  involved) the old ALSA arm directory to the latest kernel and compiling
  it should be working... It seams I was wrong.

 Anyway, if you find porting one or another framework, back or forward,
 helpfull in any way, just let me know, I can try.

I'm not sure if it could prove anything at the end. There are - I think - 
other moving parts, which can break things.


 Thanks,
 Janusz

-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] Please help in adding ams-delta support to ASoC

2009-06-10 Thread Janusz Krzysztofik 

Peter Ujfalusi wrote:

On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote:

Not only this. AFAICS, there is no way of specifying single phase stereo
(with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)).
Isn't this required for correct DSP_A/DSP_B support?


Sure it is possible:
format = mcbsp_data-fmt  SND_SOC_DAIFMT_FORMAT_MASK;
wpf = channels = params_channels(params);
switch (channels) {
case 2:
if (format == SND_SOC_DAIFMT_I2S) {
/* Use dual-phase frames */
regs-rcr2   |= RPHASE;
regs-xcr2   |= XPHASE;
/* Set 1 word per (McBSP) frame for phase1 and phase2 */
wpf--;
regs-rcr2   |= RFRLEN2(wpf - 1);
regs-xcr2   |= XFRLEN2(wpf - 1);
}
case 1:
case 4:
/* Set word per (McBSP) frame for phase1 */
regs-rcr1   |= RFRLEN1(wpf - 1);
regs-xcr1   |= XFRLEN1(wpf - 1);
break;
default:
/* Unsupported number of channels */
return -EINVAL;
}

wpf = channels == 2, format is not I2S -- RFRLEN1(wpf - 1), XFRLEN1(wpf - 1), 
RFRLEN1(2 - 1), XFRLEN1(2 - 1)


OK, I see I have to update my base before commenting the code ;).

Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB Host problems

2009-06-10 Thread Gary Thomas 
Pandita, Vikram wrote:
 
 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Tuesday, June 09, 2009 1:28 PM
 To: Pandita, Vikram
 Cc: linux-omap@vger.kernel.org
 Subject: Re: MUSB Host problems

 Pandita, Vikram wrote:
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gary
 Thomas
 Sent: Tuesday, June 09, 2009 12:46 PM
 To: linux-omap@vger.kernel.org
 Subject: MUSB Host problems

 I'm trying to get MUSB Host working on my 3530 platform (very
 Based on your description, its not MUSB but the USBHOST EHCI block that you 
 want to get working.
 Sorry, mistaken terminology.  Yes, I'm trying to get the host ECHI working.

 similar to the Beagle).  When I startup, I get this message:
  Clock usbhost_48m_fck didn't enable in 10 tries
 This is bad
 Why?  What does it mean?  How do I fix it?
 
 The ehci driver on linux-omap works for Beagleboard and sdp.
 so this may not be a fatal problem
 
 What does this mean?  How do I fix it?

 Currently, the USB subsystem finds the various hubs (ports 0-2).
 The OTG port (0) works great.  When I plug in a device to USB-1,
 Is this a full speed device?

 it sees it, but immediately gives up :-(
ehci-omap ehci-omap.0: GetStatus port 1 status 001803 POWER sig=j CSC 
 CONNECT
hub 1-0:1.0: port 1: status 0501 change 0001
hub 1-0:1.0: state 7 ports 3 chg 0002 evt 
hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s
ehci-omap ehci-omap.0: port 1 full speed -- companion
 Looks like your device is getting recognized as a full speed.
 So EHCI cannot handle it.
 Odd, this is a high speed device (USB 2.0).  I also tried a 2.0 hub, same 
 result.
 What could confuse it like this?
 
 Is it PHY mode or TLL mode?
 If its PHY: then the transceiver used definitely matters.
 SDP has ISP1504 and
 Beagle board has SMSC phy
 
 The 60Mhz clock is fed from omap into the Transceiver (Input clocking mode).
 Only few phy's in market support this.
  
 You need to have OHCI driver built in which is not present in linux-omap 
 code base.
 Do, how does one use an arbitrary device on the EHCI port?  Must I use a 2.0 
 hub?

ehci-omap ehci-omap.0: GetStatus port 1 status 003801 POWER OWNER sig=j 
 CONNECT
hub 1-0:1.0: port 1 not reset yet, waiting 50ms
ehci-omap ehci-omap.0: GetStatus port 1 status 003002 POWER OWNER 
 sig=se0 CSC
hub 1-0:1.0: unable to enumerate USB device on port 1
hub 1-0:1.0: state 7 ports 3 chg  evt 0002
hub 1-0:1.0: hub_suspend
 Then it's dead.  Any ideas?
 Note: this is unproven hardware, I'm mostly looking for ideas on
 how to troubleshoot the problems.
 
 Have one side working: 
 Say have EHCI working on SDP/Beagle and then connect your device to it.

As I said, unproven hardware.  It turns out the PHY was [hardware
strapping] set in the wrong mode.  Fixing this and all seems to work.

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Important changes, bunch of legacy code removed from linux-omap tree

2009-06-10 Thread Tony Lindgren 
Hi all,

I've pushed a big pile of patches that take us to sync with what's about to get
merged to the mainline kernel. So we'll be using the mainline omap code that is
already queued up to go in this merge window for 2.6.31. It's basically a
backport of omap code that will be in 2.6.31 to 2.6.30.

This means that tons of legacy code got removed. That needs to be worked to
get it to mainline, so some people may want to carry those patches along in
their tree for a while. Apologies for doing it so late in the game with 2.6.30
out already, but after diffing and thinking about it for a few days, that just
seemed like the sanest way to go forward.

This will also make it way easier for us to merge in various topic branches
such as Kevin's PM branch and Tomi's DSS branch as all the topic branches are
(or at least should be) done against the mainline tree.

Also all the board-*.c files got reset to their mainline versions. So all 
board-*.c maintainers, please send patches against the mainline kernel to add
back any of the lost functionality! Help is really needed now to get the
remaining board-*.c patches done and queued up for mainline.

I've left in the base N8x0 stuff so we can clean that up for mainline as
discussed earlier. For the SDP boards, we should put together a generic
sdp-flash.c board init file and get that to mainline too.

If you want to see what legacy code has been removed, just do:

$ git log --grep=REMOVE OMAP LEGACY CODE

Some of this code has been merged back from Imre's fb-upstream branch, and
Hiroshi's iommu branch. Looks like Paul's omap-clock-upstream branch needs
to be refreshed in order to merge it. We should also start merging in
Kevin's PM branch and Tomi's DSS2 branch as soon as they are available.

For the other legacy code, at least the following changes need to be done:

- The gpio-switch.c should be replaced with a combination of gpio-keys.c
  and gpiolib, where gpio-keys handles input events, and gpiolib can handle
  toggling of the GPIO pins from userspace.

- Omap specific ATAGs should not be used as they are not going to get
  into mainline as discussed earlier. Instead, standard cmdline options
  should be used. If ATAGs are needed, they should be ARM generic.
  Also the open firmware device tree might offer a solution to replace
  the omap specific ATAGs.

I'll branch out omap-2.6.30 by 2.6.31-rc1, so let's try to sort out the
remaining issues by then.

Cheers,

Tony


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] Please help in adding ams-delta support to ASoC

2009-06-10 Thread Janusz Krzysztofik 

Janusz Krzysztofik wrote:

Peter Ujfalusi wrote:
I'm kind of bad at visualizing things, is it possible to put somewhere 
the screenshoot of the scope showing at least one sample?


Good idea. I'll take some screenshots for future reference and let you 
know when available.


Hi,

Some screenshots are available at http://www.icnet.pl/download/cx20442/

Cheers,
Janusz

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

OMAP submissions for next merge window

2009-06-10 Thread Kevin Hilman 
Russell,

For this merge window, we submitted multiple changesets for OMAP which
Tony then queued up in his for-next branch.  In some offline
discussions, you suggested for the next window we might try a slightly
different approach.  You expressed a preference for merging each
series directly into your tree after review.  Can you confirm and/or
clarify your preference here?

Thanks,

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] omapfb: Add support for MIPI-DCS compatible LCDs

2009-06-10 Thread Imre Deak 
Fixed-by: Mike Wege ext-mike.w...@nokia.com
Fixed-by: Arnaud Patard arnaud.pat...@rtp-net.org
Fixed-by: Timo Savola tsav...@movial.fi
Fixed-by: Hiroshi DOYU hiroshi.d...@nokia.com
Fixed-by: Trilok Soni soni.tri...@gmail.com
Signed-off-by: Imre Deak imre.d...@solidboot.com
Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com
---
 arch/arm/plat-omap/include/mach/lcd_mipid.h |5 +
 drivers/video/omap/Kconfig  |8 +
 drivers/video/omap/Makefile |1 +
 drivers/video/omap/lcd_mipid.c  |  625 +++
 4 files changed, 639 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap/lcd_mipid.c

diff --git a/arch/arm/plat-omap/include/mach/lcd_mipid.h 
b/arch/arm/plat-omap/include/mach/lcd_mipid.h
index f8fbc48..8e52c65 100644
--- a/arch/arm/plat-omap/include/mach/lcd_mipid.h
+++ b/arch/arm/plat-omap/include/mach/lcd_mipid.h
@@ -16,7 +16,12 @@ enum mipid_test_result {
 struct mipid_platform_data {
int nreset_gpio;
int data_lines;
+
void(*shutdown)(struct mipid_platform_data *pdata);
+   void(*set_bklight_level)(struct mipid_platform_data *pdata,
+int level);
+   int (*get_bklight_level)(struct mipid_platform_data *pdata);
+   int (*get_bklight_max)(struct mipid_platform_data *pdata);
 };
 
 #endif
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 4440885..574453f 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -7,6 +7,14 @@ config FB_OMAP
help
   Frame buffer driver for OMAP based boards.
 
+config FB_OMAP_LCD_MIPID
+   bool MIPI DBI-C/DCS compatible LCD support
+   depends on FB_OMAP  SPI_MASTER
+   help
+ Say Y here if you want to have support for LCDs compatible with
+ the Mobile Industry Processor Interface DBI-C/DCS
+ specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3)
+
 config FB_OMAP_BOOTLOADER_INIT
bool Check bootloader initialization
depends on FB_OMAP
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index d053498..d86d54a 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -25,6 +25,7 @@ objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += 
lcd_inn1510.o
 objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
 
 objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
+objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
 
 omapfb-objs := $(objs-yy)
 
diff --git a/drivers/video/omap/lcd_mipid.c b/drivers/video/omap/lcd_mipid.c
new file mode 100644
index 000..918ee89
--- /dev/null
+++ b/drivers/video/omap/lcd_mipid.c
@@ -0,0 +1,625 @@
+/*
+ * LCD driver for MIPI DBI-C / DCS compatible LCDs
+ *
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.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; 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/device.h
+#include linux/delay.h
+#include linux/workqueue.h
+#include linux/spi/spi.h
+
+#include mach/omapfb.h
+#include mach/lcd_mipid.h
+
+#define MIPID_MODULE_NAME  lcd_mipid
+
+#define MIPID_CMD_READ_DISP_ID 0x04
+#define MIPID_CMD_READ_RED 0x06
+#define MIPID_CMD_READ_GREEN   0x07
+#define MIPID_CMD_READ_BLUE0x08
+#define MIPID_CMD_READ_DISP_STATUS 0x09
+#define MIPID_CMD_RDDSDR   0x0F
+#define MIPID_CMD_SLEEP_IN 0x10
+#define MIPID_CMD_SLEEP_OUT0x11
+#define MIPID_CMD_DISP_OFF 0x28
+#define MIPID_CMD_DISP_ON  0x29
+
+#define MIPID_ESD_CHECK_PERIOD msecs_to_jiffies(5000)
+
+#define to_mipid_device(p) container_of(p, struct mipid_device, \
+   panel)
+struct mipid_device {
+   int enabled;
+   int revision;
+   unsigned intsaved_bklight_level;
+   unsigned long   hw_guard_end;   /* next value of jiffies
+  when we can issue the
+  next sleep in/out command */
+   unsigned long   hw_guard_wait;  /* max guard time in jiffies */
+
+   struct omapfb_device*fbdev;
+   struct spi_device   *spi;
+

DSS2 TV settings

2009-06-10 Thread Gary Thomas 
Tomi,

I'm running your latest DSS2 tree and have some questions about
the TV settings.  The timings, as published, don't work all that
well on our TV sets.  When I display a frame buffer to the TV
(using the recipe from the Documentation directory), some of
the actual frame buffer does not show on the screen.  In particular,
if I have tux from the default system console framebuffer
showing, the top of his head is chopped off, as is a fair
amount of his left side.  Further tests show that some amount
of the frame buffer is not present on all margins.

Is this to be expected?
Can the timings be adjusted so that the whole frame buffer shows?

[not 100% related] The documentation says that TI is working on
the V4L2 support.  Do you know the status of this?  where I might
find it?

Thanks for your comments

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] Please help in adding ams-delta support to ASoC

2009-06-10 Thread Janusz Krzysztofik 
Wednesday 10 June 2009 12:53:42 Peter Ujfalusi napisał(a):
 On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote:
 Just out of curiosity, can you try this one as well:

 --- a/sound/soc/omap/omap-mcbsp.c
 +++ b/sound/soc/omap/omap-mcbsp.c
 @@ -191,6 +191,7 @@ static int omap_mcbsp_dai_trigger(struct
 snd_pcm_substream *substream, int cmd,
 case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
 if (!mcbsp_data-active++)
 omap_mcbsp_start(mcbsp_data-bus_id);
 +   omap_mcbsp_pollwrite(mcbsp_data-bus_id, 0xdb55);
 break;

 basically write 0xdb55 to the DXR1 register (0xdb55 is 1101101101010101)
 With this, if McBSP is operating correctly you should be seeing this
 pattern going to the codec.

Peter,

I am not sure how did you expect me to see this pattern. On a scope screen? 
Unforunatelly I had to return the scope this morning.

I have further modified the code like this:

@@ -25,6 +25,7 @@
 #include linux/init.h
 #include linux/module.h
 #include linux/device.h
+#include linux/random.h
 #include sound/core.h
 #include sound/pcm.h
 #include sound/pcm_params.h
@@ -186,7 +186,7 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream 
*substream, int cmd,
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
-   int err = 0;
+   int i, err = 0;

switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -191,6 +191,8 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream 
*substream, int cmd,
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
if (!mcbsp_data-active++)
omap_mcbsp_start(mcbsp_data-bus_id);
+   for (i = 8000; i  0; i--)
+   omap_mcbsp_pollwrite(mcbsp_data-bus_id, (u16)random32
());
break;

case SNDRV_PCM_TRIGGER_STOP:

in hope I should be able to hear a noise for one second, shouldn't I.

 If it does, than we have some problems with the 
 McBSP/DMA cooperation, if this pattern is not seen on the bus, than the
 McBSP is not shifting data out for some reason.

Now aplay returns 1 second later than before, so I conclude the loop is 
processed correctly. However, I am not able to hear a single ripple nor see 
any error messages from omap_mcbsp_pollwrite() :(, so it looks like the 
latter is more probable.

Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] IOMMU: function flush_iotlb_page is not flushing correct entry

2009-06-10 Thread Guzman Lugo, Fernando 

Hi,

The function flush_iotlb_page is not loading into the CAM register the 
entry to be removed, so it function removes the last entry loaded into the CAM 
register, so it is leaving a mapped address which maybe would not be validad.

From 14aef69914856e4bc679bdacfaf48d9214f8dfc9 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 10 Jun 2009 13:32:14 -0500
Subject: [PATCH] IOMMU: function flush_iotlb_page is not flushing correct entry

The function flush_iotlb_page is not loading the CAM register with
the correct entry to be flushed, so it is flushing other entry

Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/iommu.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
 mode change 100644 = 100755 arch/arm/plat-omap/iommu.c

diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
old mode 100644
new mode 100755
index 4cf449f..4a03013
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -298,7 +298,7 @@ void flush_iotlb_page(struct iommu *obj, u32 da)
if ((start = da)  (da  start + bytes)) {
dev_dbg(obj-dev, %s: %08x=%08x(%x)\n,
__func__, start, da, bytes);
-
+   iotlb_load_cr(obj, cr);
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
-- 
1.5.6.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

2009-06-10 Thread Hugo Vincent 
Hi everyone,

I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix Overo
based board working.

Compiling 2.6.29-omap1 with
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
and MMC polling enabled (mmc-caps |= MMC_CAP_NEEDS_POLL; in omap_hsmmc.c)

then doing: $ echo 8  /proc/sys/kernel/printk
gives the following:

clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc2: starting CMD0 arg  flags 00c0
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
mmc2: req done (CMD0): 0:    
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: starting CMD8 arg 01aa flags 02f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x01aa
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD8): -110:    
mmc2: starting CMD5 arg  flags 02e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD5): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD1 arg  flags 00e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD1): -110:    
mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0

It seems every request returns -110 which is -ETIMEDOUT.

I've checked the hardware, and it appears to be correct (level
translators etc seem to be doing their job).

During polling, the CMD and CLK signals show activity, but the data
lines never change; this is presumably why every request is timing
out.

I've also tried it with 2.6.30-omap1 in git, which changes some
MMC3-specific stuff (notably DMA), but has the exact same behaviour.

I've also checked pin multiplexing settings and confirmed that the
correct values are set for the MMC3 data pins. The card I'm using is a
microSD card that works when attached to MMC1 (the Gumstix Overo
built-in microSD slot). The slot is powered by 3.3V that is always on,
there is no provision for power switching with this particular board.

Any ideas?

Many thanks,
Hugo Vincent
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

2009-06-10 Thread Pandita, Vikram 
Hugo

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hugo
Vincent
Sent: Wednesday, June 10, 2009 9:14 PM
To: linux-omap; General mailing list for gumstix users.
Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

Hi everyone,

I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix Overo
based board working.

Please check if your MMC3 Mux setting are as follows:
Note the input configuration for CLK and CMD. This is needed.

/* MMC3 */
MUX_CFG_34XX(AF10_3430_MMC3_CLK, 0x1d0,
   OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AC3_3430_MMC3_CMD, 0x5d8,
   OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AE11_3430_MMC3_DAT0, 0x5e4,
   OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AH9_3430_MMC3_DAT1, 0x5e6,
   OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AF13_3430_MMC3_DAT2, 0x5e8,
   OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AF13_3430_MMC3_DAT3, 0x5e2,
   OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)


Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.



Compiling 2.6.29-omap1 with
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
and MMC polling enabled (mmc-caps |= MMC_CAP_NEEDS_POLL; in omap_hsmmc.c)

then doing: $ echo 8  /proc/sys/kernel/printk
gives the following:

clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc2: starting CMD0 arg  flags 00c0
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
mmc2: req done (CMD0): 0:    
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: starting CMD8 arg 01aa flags 02f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x01aa
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD8): -110:    
mmc2: starting CMD5 arg  flags 02e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD5): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD1 arg  flags 00e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD1): -110:    
mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0

It seems every request returns -110 which is -ETIMEDOUT.

I've checked the hardware, and it appears to be correct (level
translators etc seem to be doing their job).

During polling, the CMD and CLK signals show activity, but the data
lines never change; this is presumably why every request is timing
out.

I've also tried it with 2.6.30-omap1 in git, which

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

2009-06-10 Thread Hugo Vincent 
On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikramvikram.pand...@ti.com wrote:
 Hugo

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hugo
Vincent
Sent: Wednesday, June 10, 2009 9:14 PM
To: linux-omap; General mailing list for gumstix users.
Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

Hi everyone,

I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix Overo
based board working.

 Please check if your MMC3 Mux setting are as follows:
 Note the input configuration for CLK and CMD. This is needed.

 /* MMC3 */
 MUX_CFG_34XX(AF10_3430_MMC3_CLK, 0x1d0,
               OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
 MUX_CFG_34XX(AC3_3430_MMC3_CMD, 0x5d8,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
 MUX_CFG_34XX(AE11_3430_MMC3_DAT0, 0x5e4,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
 MUX_CFG_34XX(AH9_3430_MMC3_DAT1, 0x5e6,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
 MUX_CFG_34XX(AF13_3430_MMC3_DAT2, 0x5e8,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
 MUX_CFG_34XX(AF13_3430_MMC3_DAT3, 0x5e2,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)


 Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.

Thanks for that Vikram. Unfortunately, these are the exact mux 
pullup settings I was already using. (In my case, they were set by
u-boot, but to be sure, I've copied and pasted the above exactly into
mach-omap2/mux.c - same result). Any other ideas?


Compiling 2.6.29-omap1 with
    CONFIG_MMC=y
    CONFIG_MMC_DEBUG=y
    CONFIG_MMC_BLOCK=y
    CONFIG_MMC_BLOCK_BOUNCE=y
and MMC polling enabled (mmc-caps |= MMC_CAP_NEEDS_POLL; in omap_hsmmc.c)

then doing: $ echo 8  /proc/sys/kernel/printk
gives the following:

clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc2: starting CMD0 arg  flags 00c0
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
mmc2: req done (CMD0): 0:    
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: starting CMD8 arg 01aa flags 02f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x01aa
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD8): -110:    
mmc2: starting CMD5 arg  flags 02e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD5): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110:    
mmc2: starting CMD1 arg  flags 00e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD1): -110:    
mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0

It seems every