On 22 February 2008, Frantisek Dufka wrote:
> Kalle Valo wrote:
> >> Also CPU usage is very high because of busyloop when waiting till
> >> DMA transfer is done. Tasklet, which executes the code can't be
> >> easily preempted, as far as I understand kernel documentation. Maybe
> >> it is possible to split tasklet into several parts, one of them
> >> could be responsible for initiating DMA transfer, the other could be
> >> activated on DMA transfer completion? This all is important for
> >> video streaming as any excessive CPU resources consumption by WLAN
> >> driver negatively impacts video playback performance.
> >
> > Sorry, I'm not familiar with OMAP 1710 McBSP, so I can't comment.
>
> I think you don't have to. From the code (sm_drv_spi_io.c) it looks like
> McBSP is setup to use dma transfer with callback when it finishes
>
> omap_request_dma(OMAP_DMA_MCBSP2_TX, "McBSP TX", dma_tx_callback, ...
> omap_request_dma(OMAP_DMA_MCBSP2_RX, "McBSP RX", dma_rx_callback, ....
>
> and the dma_tx/rx_callback() code just sets variable
> spi_dma.dma__tx/rx_done to 1.
>
> But the code that sends/receives the frame busyloops for it like this
>
> omap_start_dma(spi_dma.dma_rx_ch);
>
>
> omap_start_dma(spi_dma.dma_tx_ch);
>
>
> while(!spi_dma.dma_rx_done) {
>
>
> udelay(5);
>
>
> }
>
>
>
>
> while(!spi_dma.dma_tx_done) {
>
>
> udelay(5);
>
>
> }
>
>
>
>
> spi_dma.dma_rx_done = 0;
>
>
> spi_dma.dma_tx_done = 0;
>
>
>
>
> So there is this nice dma architecture with callback used but the code
> still spins up the cpu waiting for the done flag instead of sleeping.
>
> So you need to be familiar with the driver and tell us if it is possible
> to sleep inside cx3110x_spi_dma_read and cx3110x_spi_dma_write. And one
> also needs to be familiar with kernel programming and waiting primitives
> to suggest how to sleep and wait for the callback (if possible in this
> context) and how to wake up the sleeping code from the dma callback.
A while ago I looked for various kernel docs to see what's happening in the
wlan driver and what can be done to reduce cpu load. My impression was that
tasklet can be only preempted by hardware interrupts, so it is impossible to
sleep in it and give cpu resources to userland applications. If that is true,
no matter if n800 driver looks nicer, it must end up busylooping too.
Though on Nokia 770 cpu usage is attributed to the application doing (for
example wget) and on N800 it is attributed to 'OMAP McSPI/0' process.
A solution that I tried to suggest might be to start DMA transfer, schedule
another tasklet to run after DMA transfer is done and exit from the first
tasklet. That another tasklet should get activated and do the rest of the job.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
