repaper / gratis

EPD Source codes and Documentation
238 stars 132 forks source link

Screen Update Slow #36

Closed blockbomb closed 8 years ago

blockbomb commented 8 years ago

I've been working with the repeper epd module 2.7" for a few months now on the BeagleBone Black and just moved my system from one of the Debian images on the 3.8 kernel to a reacent ARCH image

$ uname -a

Linux alarm 4.3.3-2-ARCH #1 Tue Jan 5 19:01:58 MST 2016 armv7l GNU/Linux

I've been stumbling my way along reading through the changes for working with 4.x kernels and I have the module drawing the epd_test program but the issue is that it is much much slower then the older system...

I'm still not 100% sure how to find what version of the panel I'm running but everything I've compiled has been for the V231_G2 model. I've been fumbling my way through to debug why it would be so slow and my initial thought was that maybe the data was just not getting clocked out at speed from the spi header, So I hooked up an o-scope and measured the bit rate got something like 6 Mhz. I noticed that on the faster system the epd_cs signal was much more active than on the ARCH system so I went went down a rabbit hole trying to figure out if maybe the pwm period settings were not getting set only to realize the PWM is not even used on the V231_G2 build.

I'm stuck at the moment and running out of ideas, however I did notice that there are a whole slew of error in dmesg multiple per ms exclaiming

[ 2925.614069] spidev spi1.0: not using DMA for McSPI

which seems like it may be related to the issue. I'm wondering if anyone else has seen this? or if it is just a matter of me missing something.

thank you for you input :)

blockbomb commented 8 years ago

Looks like it did have to do with the fact that the DMA over spi was disabled on my system. I will assume that others have not seen this issue due to the fact that I believe for the 4.x kernels we are using the bone-universal overlay and it must set up the spi0 hardware in the correct manor. I am using the EPD with a CryptoCape and I think the crypto is loading the BB-SPIDEV0-00A0 overlay, which I found from this thread ( http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2F_22bW7vMkW0%2F16mBP2faAQAJ ) was edited to not allow DMA transfers by adding the line

ti,pio-mode;

apparently in the 4.1 kernel that RCN is working on there was a bug that crashed the system when DMA kicked in. so for S & giggles I decided to decompile that overlay and recompile it with that line removed and I'm writing the screen @ speed :)

I still don't know what pio stands for but some other day I can figure that out.

hopefully this might help someone out like me who is still working wading their way around these systems on the BBB, Thank you for all your hard work on this project!

hxw commented 8 years ago

most likely it is polled input/output so it would be slow.