stuck in wait_for_completion

Hi all;

    My project is about obtaining high speed data with McBSP 1 on OMAP
3530. I suppose i successfully initialize MCBSP with proper functions
respectively:
omap_mcbsp_request
omap_mcbsp_enable_clks
omap_mcbsp_config
omap_mcbsp_start

Then the loopback functions is calling :

omap_mcbsp_xmit_word

omap_mcbsp_recv_word

but in the omap_mcbsp_xmit_word it is stuck in function
wait_for_completion and timeout. What could be the reason for it? Is
it beacuse my configurations or another reason? What do you suggest
for me to do XINTM and RINTM? Thanks in advance.

Fatih

I'd look at SPCR2.XINTM and SPCR1.RINTM.

You also might need this patch depending on the kernel you are working
on.

Hey Scott

Thanks a lot for your answer Scott. My project is about obtaining high
speed data with McBSP 1 and i will use DMA and receiving data only
same as you. Because i am newbie on mcbsp, i just tried to succeed
basic loopback with irq ( It is not about my project though ).
As you can see our goal to use mcbsp is the same, therefore if it is
not private code or secret code for your company can you share your
code with me. I really appreciate if you can and you save my lots of
time (which i have already late with my schedule :frowning: . If you cant any
help will be appreciated ( you may help me by showing a route and
configurations i should use). Thanks in advance.

(By the way this is different question i couldnot clarify. At the
driver code that includes mcbsp.h. Should i use the registers like
devconf0 in order to activate internal clock of the mcbsp , or
omap_mcbsp_request with configurations CLKM=1 SCLKME=0 done it instead
of use automatically.)

Best Regards

Fatih

It was contract work, so I'll have to ask.

It wasn't the 'special sauce' for their project, just a small piece,
so
they might not mind if I made the whole driver open.

I never messed with devconf0. The process was

mcbsp_request
mcbsp_config
<setup dma>
mcbsp_start

then just continually process the data in the dma callbacks.

The omap_mcbsp_reg_cfg I used was the same I posted previously,
with some of the fields like CLKDV, RFRLEN1, FWID controlled by
user settings at runtime.

Also, that driver was my one and only experience with the McBSP
controller. I am no expert on it either.

Scott thanks a lot.
    I am waiting for your post about driver. Also i wonder about Setup
DMA part of the driver. Is it just dma_alloc_coherent or something
different. Can you clearify this part at least.
    I tried to obtain data with omap_mcbsp_recv_buffer and
omap_mcbsp_xmit_buffer. These are correct functions for DMA right?
When i use them again i stuck with wait_for_completion function inside
of them. If you have any suggestion please let me know.

Fatih

Unlikely to get the code freed. Owned by the government.

Yes, omap_mcbsp_recv_buffer and omap_mcbsp_xmit_buffer are
what you would use for dma transfers if you aren't writing your own
handlers. I never used them.

Look at the code in arch/arm/plat-omap/mcbsp.c if you want to
write you own dma functions. omap_mcbsp_recv_buffer() is
an example.

You can enable some more debug output in the kernel by defining
DEBUG in mcbsp.c before including <linux/device.h>

...
#include <linux/module.h>
#include <linux/init.h>
#define DEBUG
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/wait.h>
#include <linux/completion.h>
...

You can also put your own printks in mcbsp.c so you can better
follow what's going on. That's what I did.

After calling mcbsp_start and using the config that I posted you
should be seeing activity on fsx and clkx.

If you don't, is your pin-muxing for McBSP1 correct in u-boot?

What is the device are you trying to talk to?

Thanks scott. I have already define DEBUG and put some printk s
thats why i can understand it stuck at wait for completion :slight_smile: and when
i use exactly your configurations (i attached below) it stucks inside
omap_mcbsp_request tx_irq_handler (It enters infinite loop without any
for or while :frowning: I use OMAP3530 EVM by the way.
      When i connect the fsx and clkx i couldnot obtain any clock
signal with oscilloscope so i didnt understand what should be the
reason. I try to use internal clock as doing CLKSM=1 and SCLKME=0 as
in TRM. When i dump clock structure inside struct omap_mcbsp i see:
clk flag:0x1 iclk id:0x2 iclk rate :83000000

it can also obtain irq s and dma from board:
rx_irq:60 tx_irq=59 dma_rx_sync=20 dma_tx_sync=1f

Therefore mcbsp port couldnot shifting data and i stuck in
wait_for_completion.

If you show me where am i wrong i really appreciate cause i go
crazy :slight_smile:

fatih

CONFIGS:

static struct omap_mcbsp_reg_cfg mcbsp_dma_config = {
        .spcr2 = FREE,
        .spcr1 = RJUST(RIGHT_JUSTIFY_AND_SIGN_EXTEND_MSB) | RINTM(3),
        .rcr2 = RDATDLY(0),
        .rcr1 = RFRLEN1(DEFAULT_NUM_ADC_CHANNELS - 1)
                        > RWDLEN1(OMAP_MCBSP_WORD_24),
        .xcr2 = 0,
        .xcr1 = 0,
        .srgr1 = FWID(95) | CLKGDV(56),
        .srgr2 = CLKSM | FSGM | FPER(255),
        .mcr2 = 0,
        .mcr1 = 0,
        .pcr0 = CLKXM | CLKRM | FSXM | FSRM,
        .xccr = 0,
        .rccr = RFULL_CYCLE | RDMAEN | RDISABLE,
};

You never said whether you checked the u-boot pin muxing.

For u-boot 2010.9, I see this in the default board/ti/beagle/beagle.h

  MUX_VAL(CP(MCBSP1_CLKR), (IDIS | PTD | DIS | M4)) /*GPIO_156*/\
  MUX_VAL(CP(MCBSP1_FSR), (IDIS | PTU | EN | M4)) /*GPIO_157*/\
  MUX_VAL(CP(MCBSP1_DX), (IDIS | PTD | DIS | M4)) /*GPIO_158*/\
  MUX_VAL(CP(MCBSP1_DR), (IDIS | PTD | DIS | M4)) /*GPIO_159*/\
  MUX_VAL(CP(MCBSP_CLKS), (IEN | PTU | DIS | M0)) /*McBSP_CLKS*/\
  MUX_VAL(CP(MCBSP1_FSX), (IDIS | PTD | DIS | M4)) /*GPIO_161*/\
  MUX_VAL(CP(MCBSP1_CLKX), (IDIS | PTD | DIS | M4)) /*GPIO_162*/\

This has the MCBSP1 pins muxed as GPIO. This would not be what you
want if you are using the expansion header of the older beagleboards.
I didn't look at the xm board.

Working with MCBSP3 I only had CLKX, FSX, DX and DR.

I mux'd those 4 as as IEN | PTD | DIS | Mx

In your case, Mx should be M0.

With MCBSP1 you have CLKR and FSR too. I don't think you have to mess
with MCBSP_CLKS.

Yeah you are absolutely right it was about pin muxing thanks a lot :slight_smile:
Finally i see the first spark of life from mcbsp. I couldnot change it
in u-boot, my board couldnot work with my u-boot but i have changed it
with memutils application. Now next step is obtaining data, i may need
your help. I really appreciate and thank you again..

Fatih