2011-05-20 04:58:59     Issues with bfin_sport bf-527

Document created by Aaronwu Employee on Aug 27, 2013
Version 1Show Document
  • View in full screen mode

2011-05-20 04:58:59     Issues with bfin_sport bf-527

Ciaran Watterson (IRELAND)

Message: 100774   

 

Hi having an issue with the SPORT character device. Seems the DMA interrupt return is never being called and transfer fails on the second attempt. Here are the print outs of the transfer

 

 

bfin_sport: sport_write count:38  dma_tx_chan:4

bfin_sport: DMA mode

bfin_sport: wait for transfer finished

bfin_sport: waiting over **Where are all the DMA interrupt return messages?**

bfin_sport: sport_write count:38  dma_tx_chan:4

bfin_sport: DMA mode

bfin_sport: wait for transfer finished

**BLOCKED!**

 

Looking at what debug messages should print out - I can see that the "completion flag" must already be set on the first write - I guess this should probably be forced to "incomplete" before the transaction.

 

Is it possible that the interrupts can be set up wrong? eg. a bug in set_dma_callback(...) . My board is siml to the bf527 ezkit would there be any major differences in how interrupts are set up in the BF-527?

 

Due to the setup of my board I would be surprised if the SPORT does block - I have the pins it should be coming out on set in 'loopback' - the main thing here is the RSCLK and RFS. The pin mux scheme is a little complicated so I might have it setup wrong - my SPORT should be on PORT F.

 

I've included my test app, In case my config is worng or something stupid.

 

sdp_sport_test.c

QuoteReplyEditDelete

 

 

2011-05-20 05:28:12     Re: Issues with bfin_sport bf-527

Aaron Wu (CHINA)

Message: 100776   

 

Did you mean to use internal clock? If so you may also need to set config.int_clk to 1.

QuoteReplyEditDelete

 

 

2011-05-20 05:47:31     Re: Issues with bfin_sport bf-527

Ciaran Watterson (IRELAND)

Message: 100777   

 

Yes - thanks for that! For some reason I thought that would be the default value. It's at least not blocking now - but I'm not seeing output yet. Will get back to you if there are anymore issues.

QuoteReplyEditDelete

 

 

2011-05-20 10:11:45     Re: Issues with bfin_sport bf-527

Ciaran Watterson (IRELAND)

Message: 100779   

 

Okay I have the SPORT driver working no bother and it looks like I'll probably use it.

 

I was hoping to use the spi-sport driver and then the iio on top for an AD9834 demo. I'm testing the spi-sport driver using the Spidev and spidev_test. However I seem to be getting a kernel panic (attached). I am right in thinking the spidev driver should work in this situation?

 

As a note, I think it would be worthwhile if both these drivers were built on the same interface to SPORT so that they could be used together. With Software Chip select and disable for frame sync, more parts might be supported on the one system - without having to load and unload drivers.

 

spidevErrLong.log

QuoteReplyEditDelete

 

 

2011-05-23 22:17:45     Re: Issues with bfin_sport bf-527

Mike Frysinger (UNITED STATES)

Message: 100806   

 

sorry, but i dont follow.  what exactly do you mean "both these drivers were built on the same interface" ?

 

using the SPORT/SPI bus master driver should not cause a panic by simply doing traffic over spidev.  please open a tracker item with your log for the issue.

QuoteReplyEditDelete

 

 

2011-05-25 07:06:52     Re: Issues with bfin_sport bf-527

Ciaran Watterson (IRELAND)

Message: 100831   

 

Sorry, I suppose I actually meant backend. The main idea that both sport-spi master and sport char could be loaded at the same time. Something like this:

 

spidev->spi.h->sport_spi->bfin_sportbackend

 

And

 

sport_char(bfin_sport)->bfin_sportbackend

 

Where each driver would only obtain a lock on the SPORT bus when open/operations are called. Actually I find a more general issue where drivers acquire resources when loaded - with the extensive pin sharing on the bf527 this really means you end up having to load and unload modules - and for SPI actually, chip selects/gpio seem to be reserved even before the slave driver is loaded (by the blackfin spi master I presume).

 

Another example, the GPIO assisted parallel Flash - this reserves the GPIO pin when loaded, rather than on a transaction basis. On one of my older boards the GPIO actually swaps between two devices - so a driver for the other device, also needs to be able to acquire the GPIO and block until it is available. Then it would need to be able to assert its enable.

 

I don't have the time to look into the SPORT/SPI issue at the moment, just going to use bfin_sport. Maybe this is a setup issue on my end if you're able to get this working on the bf527 ezkit.

QuoteReplyEditDelete

 

 

2011-05-26 01:10:58     Re: Issues with bfin_sport bf-527

Mike Frysinger (UNITED STATES)

Message: 100845   

 

the bfin_sport driver kind of sucks atm in that it attempts to grab all SPORTs.  that should be fixed.  then you could use say SPORT0 with bfin_sport and SPORT1 with spi_bfin_sport.

 

but there are no plans to make it so that you can use the bfin_sport and spi_bfin_sport on the same SPORT peripheral simultaneously.  i dont believe the SPI core allows you to do this.

 

the SPI master only reserves chip selects when spi devices are declared.  this is how the SPI core works.

QuoteReplyEditDelete

 

 

2011-05-26 06:47:39     Re: Issues with bfin_sport bf-527

Ciaran Watterson (IRELAND)

Message: 100871   

 

Yes well that would certainly improve things a bit. Chips Selects and GPIO CS seem to be reserved in the "setup" function in spi_bf5xx so I would say the CS could be reserved at the start of a pump_transfers message (if not already reserved) and released at the end, if no further messages are pending.

 

This is similar in the spi_bfin_sport.c - these are platform specific files so there are no public changes to the interface needed. The sport and sport/spi driver could also reserve the sport peripheral pins during transfers only. The major issue is that attempting to acquire resource will return an error, rather than block. Okay for transfers to fail in this case (my application would probably not attempt to use both at the same time anyway).  To share the resources properly, it might need new gpio_request/peripheral_request functions that would block with a specified timeout (to prevent possible deadlocks?).

 

At that point, I think we're talking a major architectural change in how resources are managed - I can see it could be a bit too much to bite off.

QuoteReplyEditDelete

 

 

2011-07-19 15:21:37     Re: Issues with bfin_sport bf-527

Mike Frysinger (UNITED STATES)

Message: 102540   

 

ive filed some tracker items for reworking the bfin_sport driver:

  blackfin.uclinux.org/gf/tracker/6697

Outcomes