msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Nov 04, 2013 1:23 pm

Status-update on spi-bcm2835dma:

The driver has now the first implementation of the spi_prepare_message interface that will go live with linux 3.14.
So it is currently a bit of a "hack" getting it in place without any updates to the spi infrastructure.

Also the drivers which want to make use of it have to call this interface "manually" to make use of it.

So as I am also working on a new driver for the CAN controller mcp2515 I have modified this one to make use of that interface.
The result is:

Without prepare I see:
  • 14.6k interrupts
  • 17.2k context-switches
  • 88%CPU-System load
While with prepare I see:
  • 29.2k interrupts
  • 34.5k context-switches
  • 80%CPU-System load
In both cases I am handling about 3400 packets/second.

Unfortunately I have not had the time yet to look at the things actually happening on the SPI Bus lines itself.

But from what it looks like we are doubling the interrupt and context-switches but reducing system load.
One interpretation is that the prepared DMA version is much faster, so that it handles each one of these packets individually with an interrupt while the version that is not using the prepared statement seems to be handling 2 packets at a time and is thus at a higher risk of a buffer-overflow in the controller itself.

As said: I can not confirm this guess yet, but at least it looks promising...

If I can confirm this guess, then I will try to take the next step and try to work without any external thread for SPI queuing (and the corresponding context-switches), which should REALLY bring down CPU utilization, context switches and interrupts...

But again: this is based on a driver that is "focused" on streamlined SPI transfers already.
Theoretically with the "inline DMA queueing" approach, it should work with 3 interrupts/message and no context-switch.
Right now calculating interrupts and context switches using the one_message_approach I would get to 4 interrupts/message and the same amount of context switches. Those context switches themselves may require additional interrupts.

Also the above does NOT account for other overheads due to the packet delivery framework in Linux.
When removing the "overhead" of packet-delivery (by commenting out that part) CPU load goes down to 65% CPU, but interrupts increase further to 30.8k and context switches to 36.5k.

"Abusing" some counters I can say that for the version without "prepare", I see that out of 3438 packets 1528 packets are delivered from the second CAN buffer.
But with the prepared interface the counters show: only 57 Packets out of 3283 packets get delivered from the second buffer.

So this really explains the doubling of the number of interrupts - even _without_ looking at the logic analyzer...

Ciao,
Martin

P.s: one more observation - as you have seen, the packet source is not 100% constant, but that is due to the fact that it will reset itself every 4 seconds (which results in a time without messages). And as the above values are taken from 10 second averages that means we see some variation - depending on when the "sampling" of those 10 second starts.

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Nov 04, 2013 4:14 pm

Here to Images that show what I have suspected before:

The different lines without preparing statements:
no_prepare.png
no_prepare.png (58.83 KiB) Viewed 5544 times
While with prepared statements:
prepare.png
prepare.png (51.29 KiB) Viewed 5544 times
Both sow the first CAN Frame read from a sequence of 5 Frames.
It also shows the end of the first frame (with Int-line going down) till the interrupt-line goes down for the second message.

(unfortunately I can not scale the X-Axis to be identical for the 2 images)

All is taken at 8MHz SPI Bus speed.

Rows are:
  • /CS
  • MISO
  • MOSI
  • SCK
  • ignore
  • /Preparing DMA Chain
  • Interrupt line of mcp2515
  • CAN Message
So we see that:
  • the overall time needed to handle the transfers has been reduced tremendously (I did cut of the Message
  • The time spent preparing has become almost 0
So everything that I was guessing has been confirmed.

This makes performance much stabler already...

Now this leaves the time between the interrupt and the actual transfer to optimize by pipelining the messages.

Also note that the 2nd message is scheduled WITH the first message, so these 2 messages could get chained together via DMA without the "gap" of 51us.
Also we have a callback only on the 1st and on the 3rd message, so as soon as the 1st message callback gets triggered, it will schedule (some variant of) the 3rd message.
So assuming the callback can happen within the time of the transfer of the 2nd message (37us), the 3rd message would already be DMA scheduled by the time the 2nd message has finished the transfer.

In total this would reduce the "delivery time" from 163us to 70us (=25+37us+8us) plus a bit of DMA overhead.

To put it in perspective: the CAN extended Iientifierer alone takes 78us to transfer and a full 8-byte message 280us (and including "bus-idle" after a transmit: 336s)

So theoretically we can handle 2 MCP2515 running at 100% BUS-utilization with extended frames and 8 byte data on a single SPI bus. without problems.
If you increase the bus-speed to 10MHz even more would be possible.

So there is quite some benefit to improving further.

But obviously the drivers HAVE to get written with such scheduling in mind to get the highest thru-put possible from the HW...

Martin

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Fri Nov 08, 2013 10:31 pm

I have been trying to get the enc28j60 to work with my new driver, but for some reason it does not work. Even during the initialization phase it fails.
Unfortunately my logic analyzer is failing to show anything suspicious.

I start to fear that there is some chipselect glitch where CS goes up momentarily during the switch from read to write (say below 0,1us)...
Something where the mcp2515 might less sensible...

I wish I had a fast oscilloscope to check that this is not true...

Martin

Zeta
Posts: 72
Joined: Wed Dec 12, 2012 9:51 pm

Re: SPI driver latency and a possible solution

Sat Nov 09, 2013 12:11 am

Hello Martin,
msperl wrote:I start to fear that there is some chipselect glitch where CS goes up momentarily during the switch from read to write (say below 0,1us)...
Something where the mcp2515 might less sensible...

I wish I had a fast oscilloscope to check that this is not true...
I am not 100% sure, but if there is only one device connected on the SPI bus (of the two possible), then you should be able to use it with the chip select always active, no ? I don't think there is an edge needed on it to start communication ?

Looking at wikipedia we find this:
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Operation wrote:If a single slave device is used, the SS pin may be fixed to logic low if the slave permits it. Some slaves require a falling edge of the chip select signal to initiate an action, an example is the Maxim MAX1242 ADC, which starts conversion on a high→low transition.
So it seems it depends on the device...

Then, if it works with the chip select always active (by tying it to a low potential, not connected to the raspi CS line), then you'll know that the problem is really in the CS line somewhere in driver or the hardware SPI controller. This would not solve the problem, but maybe help to confirm it.

Good luck with this one !

Zeta

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Nov 11, 2013 7:51 am

Some investigations: I am no 100% sure if the issue happens because of one of the later code changes, or if it was always there, but error handling in the mcp2515 driver only came a bit later an is now also showing "issues" from time to time.

In one sample it seems as if in 7291 out of 170529 cases I have observed there is a "glitch" in CS going high when switching from read to write for possibly 62ns (but that is as fast as my logic analyzer can go reliably.) So that is in 4% of all cases, which is not a good sign...

I will need to review the latest code changes. The biggest change was which DMA is used to schedule the DMA.
Before it was the TX queue which would switch to RX and which later would switch to TX again - looking a bit like ping-pong between the to DMA chains.
But now it is only RX with TX getting scheduled "from time to time" to run only some TX transfers...

But as the "issue" possibly also exists also with ENC28j60.
And there it seems reasonable to assume, that the read can be flawed there as well....
The ENC28j60 may react to shorter "CS" pulses than the mcp2515 - especially as the mcp2515 clock is running in my case at 16MHz, while the ENC28j60 has a dedicated clock of 25MHz which could indicate that it can detect if the clock is "deactivated" for 40ns...
My logic analyzer would only see such "glitches" in rare cases, when sampling would occur right on time, but as it happens during the initialization phase on the ENC28j60 I would not be able so see this phenomenon except by doing lots of testing...

working on it...

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Nov 11, 2013 9:09 am

Quick analysis: after waiting WAIT cycles in DMA it shows the error is related to the fact that under some circumstances (or for an ever so short "time" not always measurable by me) the CS goes high when resetting the TX/RX FIFOs to 0. This might be related to the write to CS itself, or it may be related to the reset functionality...

And as I have to write 2 bytes and read 3 this means that with DMA only able to work in 32 bit mode, I have to reset the TX and RX fifos when switching from write to read (as I would otherwise transmit/receive the "other" data from the 32 bit transfer , which is definitely not what we want) and then the CS goes up for a short period of time.

A fast oscilloscope with lots of memory might confirm if it really happens all the time or if it is just a bug that happens under some circumstances. I unfortunately do not have one available right now, which makes it awkward to figure out a "workarround"...

Martin

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Nov 11, 2013 9:07 pm

I believe I can confirm that this CS glitch is a HW issue - a simple setting CLEAR_TX_FIFO in a loop without DMA also shows the "behavior" of the issue - CS gets de-asserted and reasserted also in about 4% of all "events".

But there is a work-around that is a bit of a hack: making use of the reserved CS=3 and inverts the Polarity of the CS we are using... This seems to work, but there might be other issues that this may introduce...

A high-speed oscilloscope (>500MHz sample rate - the more the better) would be welcome to see if there are any other glitches in CS... (why so high, because of the undivided SPI clock, which typically runs at 250MHz. And the "glitches" might be in the range of a few of those clock cycles, so we need higher frequencies for some oversampling...)

I will try to fix the final unload issue that I experience now and then I will publish the next version of the driver.
I also hope that the driver now will also support the SPI-Ethernet device ENC28j60 as a second confirmed device besides the MCP2515 CAN controller...

Martin

Zeta
Posts: 72
Joined: Wed Dec 12, 2012 9:51 pm

Re: SPI driver latency and a possible solution

Mon Nov 11, 2013 9:23 pm

msperl wrote:A high-speed oscilloscope (>500MHz sample rate - the more the better) would be welcome to see if there are any other glitches in CS...
I'll take a look at work tomorrow, but I am not sure we have one that goes that high... I'll keep you informed.

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Nov 11, 2013 10:14 pm

Good news!

The enc28j60 is also working with the "patched" driver - so the CS-"glitches" were responsible for the not-functioning driver.

The problem of unloading the mcp2515 driver under high load still persist - this may relate to the new locking scheme in place now in preparation for the "pipelined" DMA....

@Zeta: thanks for the offer - I would recommend to wait a bit so that I can prepare a test that makes it easy to "test" without a connected SPI-device... I need to write a test spi device anyway, that will be producing repeatable IO-pattern to measure how much the System improves compared to the "original" driver and where it will be slower...

So the driver in its current incarnation should already be able to handle any device of your choice, so please give it a try and provide feedback if it works or not...

Martin

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Nov 11, 2013 10:16 pm

P.s: the next devices I will try are an SD-Card via SPI and a Display (taking notros device driver) - that will probably handle most typical "use-cases"...

Zeta
Posts: 72
Joined: Wed Dec 12, 2012 9:51 pm

Re: SPI driver latency and a possible solution

Tue Nov 12, 2013 11:25 pm

msperl wrote:@Zeta: thanks for the offer - I would recommend to wait a bit so that I can prepare a test that makes it easy to "test" without a connected SPI-device... I need to write a test spi device anyway, that will be producing repeatable IO-pattern to measure how much the System improves compared to the "original" driver and where it will be slower...
I took a look. The best I got is a 300MHz/2.5GSPS oscilloscope. But it only has 3.5" floppy disks for export... I also have a more recent one with CompactFlash but only 200MHz/1GSPS performances. I never used the saving system on them yet, but it should work.
If you still need something that is easy to test, I can try to find some time. Let me know.

Zeta

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Wed Nov 27, 2013 8:36 am

Update:
I am currently working to get some code upstream (and that requires a lot of convincing and also cleaning up code).
fact is that I am still stuck in the interrupt-driven stage, as I already try to optimize the "non-optimized" spi_messages,
so that the CPU overhead (and scheduling delays) for this is reduced to the level of the spi-bcm2835 driver.

Here a quick-summary of measurements for a 100% saturated 125KHz CAN Bus):
* SPI-BCM2835: 35% System load at 25000 interrupts
* SPI-BCM2835dma without optimize interface: 45% System load at 5000 interrupts
* SPI-BCM2835dma with optimize interface: 27% System load at 4000 interrupts.

So that optimization will take some more time to get it right - especially as it is requested to make it "generic" enough to allow other drivers to also make use of the code...

Martin

User avatar
mikronauts
Posts: 2722
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: SPI driver latency and a possible solution

Wed Nov 27, 2013 4:09 pm

As you mentioned wanting to make your excellent driver more generic, may I suggest the following benchmarks:

- reading the 16 inputs from a MCP23S17 as fast as possible
- writing the 16 outputs on a MCP23S17 as fast as possible
- reading 1/2/4/8 channels from an MCP3208 (or MCP3008) as fast as possible

These are probably the most used SPI I/O devices, and everyone would benefit greatly from getting the best speed out of them, and I think they would provide excellent additional benchmark data points.

What speed are you running the SPI clock at? (my apologies if I missed that information earlier in this thread)

Regards,

Bill
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Wed Nov 27, 2013 7:08 pm

Well - I found out that a lot really depends on how the driver itself is written and how the driver schedules transfers.
If the driver is using the synchronous interface the driver will never be able to run as many messages as possible.
But if he runs the async Messages and schedules a lot of those, then the transfers can get done very quickly.

Because the reason for most delays are the latencies when handling an Interrupt.
So if you got a predefined pattern: like 1 Write,2 Reads and you need to run those as fast as possible
then if you schedule those syncronously it means you have lost a lot of opportunity.

If you really want to run those pattern as fast as possible, then you will have to use a driver that does something like this:
* prepare two transfer that execute this pattern:
** Write 1 Byte , Read 2 Bytes, bring CS up
** Write 1 Byte , Read 2 Bytes, bring CS up
** Write 1 Byte , Read 2 Bytes, bring CS up
** Write 1 Byte , Read 2 Bytes, bring CS up
* potentially MemoryMap the source/destination address
* schedule both spi_messages via spi_async
* the complete handler should copy the data where it really belongs and then schedule the message immediately again
* maybe more than just 2 such messages are needed to avoid irq latencies.

Then you can do high-volume transfers with minimal "gaps" and almost predictable scheduling.
(there would be some jitter, as the DMA would still be dependent on memory bandwidth and thus there is no absolute guarantee on speedy transfers.)

If I ever get to finish the "pipelined" DMA driver, then this would mean that the SPI clock (whatever value you set it to) would be running most of the time. Obviously you should avoid that other devices are using the SPI bus, as otherwise you would have "gaps" due to the transfer of the other device...

Martin

User avatar
mikronauts
Posts: 2722
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: SPI driver latency and a possible solution

Wed Nov 27, 2013 11:12 pm

Makes sense. I'll have to look into this in detail as timer permits.

Sounds like your pipelined DMA driver would be able to saturate the SPI bus - which would be great news :)
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Dec 02, 2013 7:10 pm

Status update:

Progress is quite slow at this very moment.
We need some minor changes to the upstream SPI framework to make everything work with optimal performance, so communication with upstream is needed and i need to learn the requirements for upstream kernel development.
Still there is some progress to the "politics"...

On the other side I got requested to think of a solution that could also benefit other devices in the future, so that means more coding and thinking to minimize the negative impact when SPI messages are NOT prepared ahead of time for multiple use.
That requires quite some effort.

So this is moving slowly in the right direction, but it will take longer than expected...

Martin

Markus989
Posts: 7
Joined: Thu Jun 06, 2013 9:22 am

Re: SPI driver latency and a possible solution

Fri Jan 03, 2014 11:16 am

Hi all,
I have a question concerning the spi performance with your patch when sending only 1 Byte per spi-message. My SPI-slave expects between every Byte a GPIO -Signal(called a framesignal). This means for me its only possible to send the spi message byte after byte, with a gpio trigger in between. As mention above, in this case DMA-mode is not an advantage. My problem is that between every Byte there is a huge time gap(around 50µs), which causes a very slow transmission :( . In the attached scope picture the GPIO-signal is illustrated in red and the one Byte SPI-Clock is blue.
2013129.jpg
2013129.jpg (49.01 KiB) Viewed 4476 times
I use a Raspbian OS with an rt-patch.
Is it still possible to reduce this time gap with your patch(because of the improvement concerning the workqueues) :?: I mean only the time between the two (1-Byte) spi-messages.
Or can someone give me a hint how to locate and eliminate this loss of time :?:

Thanks for every help!!

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Fri Jan 03, 2014 12:47 pm

not fully knowing how you do it, I assume you want to do a thing like:
  • Read X bytes
  • wait X ms
  • Read X bytes
  • wait
  • ...
using spidev.

Unfortunately the issue lies with the realtime behaviour of linux and how the SPI framework is implemented.
It is mostly related to scheduling latencies, because the way it works is:
  • you schedule your transfers from userspace
  • this gets transferred to the kernel, where it gets validated before creating the corresponding kernel internal SPI messages
  • these get queued in the kernel and a kernel internal thread gets woken up to handle the SPI transfer
  • here your process stays "waiting for the transfer to complete" (assuming syncronous transfers)
  • now the worker thread running SPI is woken (or possibly another high-priority thread, in which case we wait some more)
  • the thread takes the SPI message in the queue and starts processing it
  • longer transfers are done via interrupts so the CPU is yielded by this thread and other processes may continue their work. (note that interrupts again are often implemented as a separate thread (especially in the case of the stock driver, so this adds additional latencies.
  • when the transfer is finished, then the spi driver is woken to continue its work (again with scheduling)
  • this then wakes the kernel thread that is your call to SPIdev (again with scheduling)
  • this releases some internal memory and returns to the user process
so you see there is a lot processes-switching and each of which will add some latencies.

The best you can do is schedule multiple x-byte transfers with delays within a single SPI Message (not sure if it is permissible with SPIDEV).
This way at least you avoid 2 context switches to and from your process to the spi controller thread.

What you also can do is create 2 connections to SPIdev to schedule the messages from connection a and from connection b in a non-blocking fashion to improve the situation.

It also helps if your "user-process" also runs with higher priorities - preferably real-time, so that you do not incur other scheduling latencies...

If you really need hard-realtime, then add a MCU to your setup that does the hard realtime part and feeds you the data in chunks. (Or you write your own realtime OS).

Hope this helps explain the situation,

Martin

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: SPI driver latency and a possible solution

Fri Jan 03, 2014 4:56 pm

One way to cut through all the processing that Martin describes, is to write directly to the hardware registers.
This C library does that: http://www.airspayce.com/mikem/bcm2835/

Disclaimer: I haven't tried that library myself.

Markus989
Posts: 7
Joined: Thu Jun 06, 2013 9:22 am

Re: SPI driver latency and a possible solution

Sat Jan 04, 2014 11:13 am

Thanks msperl for the overview of the procedure which is taken place!!!
I already investigate the code to find those latencies, but Im new to linux module development, so its not that easy for me. Sorry for the poor description I gave :| I'm not using the spidev driver, I work on implementing a spi protocoll driver for a network device. The following code describes my situation better:

Code: Select all

USIGN32 TPS1_SendReceiveData(u8* transmit, unsigned short length, u8* receive)
{
  
  int ret = 0;
  int i;

  for(i = 0; i < length; i++){

    struct spi_transfer t = {
                .tx_buf = transmit +i,
                .rx_buf = receive  +i,
                .len = 1,
                .speed_hz = MAX_SPI_CLOCK,
    };

    struct spi_message msg;
    spi_message_init(&msg);
    spi_message_add_tail(&t, &msg);

    gpio_set_value(HOST_SFRN, 1);
    gpio_set_value(HOST_SFRN, 0);

    ret = spi_sync(tps->spi, &msg);
 }
 return TPS_ACTION_OK;
}
Any idea how to improve the transmission inside the kernelcontext(if its possible)?
Thanks a lot for your help!

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Sun Jan 05, 2014 9:43 pm

Make use of spi_async for anything that is timing critical, then you shortcut the context switch!

But I believe what you really want to do is have a spi message scheduled at regular intervals. And I believe there are some ideas to implement something like this in the future in the stock kernel, but right now you have to do it on your own...

What you may end up doing is scheduling your (read) message from a timer interrupt triggering at regular intervals. That should be the most consistent method from a scheduling perspective - at the worsted you have a latency of one time-slice.

Martin

Markus989
Posts: 7
Joined: Thu Jun 06, 2013 9:22 am

Re: SPI driver latency and a possible solution

Mon Jan 06, 2014 3:07 pm

msperl wrote:Make use of spi_async for anything that is timing critical, then you shortcut the context switch!
What you may end up doing is scheduling your (read) message from a timer interrupt triggering at regular intervals. That should be the most consistent method from a scheduling perspective - at the worsted you have a latency of one time-slice.
Martin
Can you describe roughly how to realize that? Do you mean to modify the stockdriver in a way to eliminate the workerthread (bcm2708_work) and instead call the bcm2708_process_transfer method via a timer interrupt? Is there some open documentation how to access the rpi-spi hardware register(like the stockdriver)?

Many Thanks!

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Mon Jan 06, 2014 3:21 pm

In your driver:

Code: Select all

/* callback to execute when the transfer is finished - note that this may run in interrupt context, so no sleep!!! */
void complete_function(void*) {
  /* do something with data */
  /* possibly register a timer callback for in X usec that schedules the next message */
}
/* globally allocated structure - can get reused */
struct spi_message msg;
msg.complete=complete_function
...
/* schedule transfer and continue*/
spi_async(t);
As for running things periodically look here for some ideas how to use the HighResolutionTimer: http://lwn.net/Articles/167897/

Martin

tungl
Posts: 4
Joined: Mon Jan 27, 2014 1:31 pm
Location: Germany

Re: SPI driver latency and a possible solution

Wed Jan 29, 2014 2:31 pm

Are there any news regarding this topic? I've just tried to compile the kernel with this patch which ended like this when I tried to compile:
CC arch/arm/mach-bcm2708/bcm2708.o
arch/arm/mach-bcm2708/bcm2708.c: In function ‘bcm2708_restart’:
arch/arm/mach-bcm2708/bcm2708.c:675:2: warning: passing argument 1 of ‘__raw_readl’ makes pointer from integer without a cast [enabled by default]
/home/pi/kernel/linux/arch/arm/include/asm/io.h:104:19: note: expected ‘const volatile void *’ but argument is of type ‘unsigned int’
arch/arm/mach-bcm2708/bcm2708.c:680:2: warning: passing argument 2 of ‘__raw_writel’ makes pointer from integer without a cast [enabled by default]
/home/pi/kernel/linux/arch/arm/include/asm/io.h:88:20: note: expected ‘volatile void *’ but argument is of type ‘unsigned int’
arch/arm/mach-bcm2708/bcm2708.c:681:2: warning: passing argument 2 of ‘__raw_writel’ makes pointer from integer without a cast [enabled by default]
/home/pi/kernel/linux/arch/arm/include/asm/io.h:88:20: note: expected ‘volatile void *’ but argument is of type ‘unsigned int’
arch/arm/mach-bcm2708/bcm2708.c: In function ‘bcm2708_power_off’:
arch/arm/mach-bcm2708/bcm2708.c:688:2: warning: passing argument 1 of ‘__raw_readl’ makes pointer from integer without a cast [enabled by default]
/home/pi/kernel/linux/arch/arm/include/asm/io.h:104:19: note: expected ‘const volatile void *’ but argument is of type ‘unsigned int’
arch/arm/mach-bcm2708/bcm2708.c:690:2: warning: passing argument 2 of ‘__raw_writel’ makes pointer from integer without a cast [enabled by default]
/home/pi/kernel/linux/arch/arm/include/asm/io.h:88:20: note: expected ‘volatile void *’ but argument is of type ‘unsigned int’
arch/arm/mach-bcm2708/bcm2708.c: At top level:
arch/arm/mach-bcm2708/bcm2708.c:851:8: error: variable ‘bcm2708_timer’ has initializer but incomplete type
arch/arm/mach-bcm2708/bcm2708.c:852:2: error: unknown field ‘init’ specified in initializer
arch/arm/mach-bcm2708/bcm2708.c:852:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-bcm2708/bcm2708.c:852:2: warning: (near initialization for ‘bcm2708_timer’) [enabled by default]
arch/arm/mach-bcm2708/bcm2708.c:945:2: error: unknown field ‘timer’ specified in initializer
arch/arm/mach-bcm2708/bcm2708.c:945:2: warning: initialization from incompatible pointer type [enabled by default]
arch/arm/mach-bcm2708/bcm2708.c:945:2: warning: (near initialization for ‘__mach_desc_BCM2708.init_time’) [enabled by default]
make[1]: *** [arch/arm/mach-bcm2708/bcm2708.o] Error 1
make: *** [arch/arm/mach-bcm2708] Error 2

msperl
Posts: 344
Joined: Thu Sep 20, 2012 3:40 pm

Re: SPI driver latency and a possible solution

Wed Jan 29, 2014 2:35 pm

No - I am still working on it (if I find some time...)

Return to “Interfacing (DSI, CSI, I2C, etc.)”