Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some of the vsync frequencies are inaccurate #960

Closed
PaulSlocum opened this Issue Mar 25, 2018 · 16 comments

Comments

Projects
None yet
2 participants
@PaulSlocum
Copy link

PaulSlocum commented Mar 25, 2018

Hi, I'm working on a system to do frame-locked synchronized video playback between multiple Raspberry Pis, and I discovered that some of the video modes have frequencies that are slightly off, which I'm trying to figure out how to work around (or perhaps it's something that can be fixed?) I can correct the frequencies with vcgencmd's hdmi_adjust_clock, but I'm not sure of any way to detect and correct the anomaly other than taking time samples for about a minute and then calculating the hdmi_adjust_clock value based on the result.

I had originally expected the HDMI clock timing to be in sync with the system clock, and that's what I find to be true for most modes. I pasted my Vsync timing test program below, and if I run it for a while on 1080p@60 or 1600x1200@60 it converges on a frame time of 16666.66 useconds. But a few modes like 1280x1024@60 (DMT 35), 1024x768@60 (DMT 16), and NTSC 4:3 mode consistently end up with odd frame times of 16661.17 usec, 16665.58 usec, and 16683.32 usec respectively. It doesn't sound like much, but it adds up fast.

Also, is there any possibility of adjusting the composite video output clock timing? Being able to output frame-locked composite video would be extremely useful for the preservation of video art.

#include <stdio.h>
#include <sys/time.h>
#include "bcm_host.h"

unsigned long previousTimeUsec = 0;
unsigned long startTimeUsec = 0;
unsigned long endTimeUsec = 0;
unsigned long vsyncCount = 0;
bool isFinished = false;

const long targetSampleCount = 60 * 60; // 60 frames per second in most cases

void vsyncCallback ( DISPMANX_UPDATE_HANDLE_T u, void* arg )  
{
  if( isFinished == false )
  {
    struct timeval timeStruct;
    gettimeofday( &timeStruct, NULL );
    unsigned long currentTimeUsec = (unsigned long) (timeStruct.tv_sec*1000000)+timeStruct.tv_usec;
    if( startTimeUsec == 0 )
    {
      startTimeUsec = currentTimeUsec;
      printf( "vsync count: %lu    start time = %lu \n", vsyncCount, startTimeUsec );
    }
    else
    {
      vsyncCount++;
      printf( "vsync count: %lu    vsync time period: %lu usec \n", vsyncCount, currentTimeUsec - previousTimeUsec );
    }

    if( vsyncCount >= targetSampleCount )
    {
      endTimeUsec = currentTimeUsec;
      isFinished = true;
    }
    previousTimeUsec = currentTimeUsec;
  }
} 

int main(void)
{
    bcm_host_init();
    DISPMANX_DISPLAY_HANDLE_T displayHandle = vc_dispmanx_display_open( 0 );
    vc_dispmanx_vsync_callback( displayHandle, vsyncCallback, NULL ); // enable callback
    while( isFinished == false )
      sleep( 1 );
    vc_dispmanx_vsync_callback( displayHandle, NULL, NULL ); // disable callback
    sleep( 1 );
    printf( "TOTAL VSYNC COUNT: %lu      AVERAGE USEC PER VSYNC PERIOD: %.2f \n", vsyncCount, ((double)endTimeUsec - (double)startTimeUsec) / (double)vsyncCount );
    vc_dispmanx_display_close( displayHandle );
    return 0;
}
@PaulSlocum

This comment has been minimized.

Copy link
Author

PaulSlocum commented Mar 25, 2018

I realized that the frame time value I'm getting for NTSC composite video output is actually 59.94Hz, which I found out is the real NTSC frame rate, although tvservice specifically reports "60.00Hz"

@PaulSlocum

This comment has been minimized.

Copy link
Author

PaulSlocum commented Mar 26, 2018

I wrote a program that prints out a table for me to look up the real frame timing rather than having to sample it each time. I'm getting totally incorrect frame timing values for some of the modes (indicated by "???")

//----------------------------------------------------------
// RASPBERRY PI REFRESH RATE SCANNER TABLE
// Number of VSYNC samples for each mode this run: 15 x 60 (900) 
//----------------------------------------------------------

struct ModeRefreshStruct
 { double actualFrameTimeUsec; double correctFrameTimeUsec; bool possibleToFixFrequency; }; 

ModeRefreshStruct dmtStruct[] = { 
 { 0, 0, 0 },                    // DMT 0  (invalid - not a real mode) 
 {11753.5756, 11764.7059, 0},    // DMT 1  640x350 @ 85.00Hz / Real FPS: 85.08Hz (!!)
 {11753.6178, 11764.7059, 0},    // DMT 2  640x400 @ 85.00Hz / Real FPS: 85.08Hz (!!)
 {11759.2922, 11764.7059, 0},    // DMT 3  720x400 @ 85.00Hz / Real FPS: 85.04Hz (!)
 {16666.6378, 16666.6667, 1},    // DMT 4  640x480 @ 60.00Hz / Real FPS: 60.00Hz 
 {13734.5722, 13888.8889, 0},    // DMT 5  640x480 @ 72.00Hz / Real FPS: 72.81Hz (!!!)
 {13333.3056, 13333.3333, 1},    // DMT 6  640x480 @ 75.00Hz / Real FPS: 75.00Hz 
 {11763.5078, 11764.7059, 1},    // DMT 7  640x480 @ 85.00Hz / Real FPS: 85.01Hz 
 {17777.7544, 17857.1429, 0},    // DMT 8  800x600 @ 56.00Hz / Real FPS: 56.25Hz (!!!)
 {16579.1744, 16666.6667, 0},    // DMT 9  800x600 @ 60.00Hz / Real FPS: 60.32Hz (!!!)
 {13852.7767, 13888.8889, 0},    // DMT 10  800x600 @ 72.00Hz / Real FPS: 72.19Hz (!!!)
 {13333.3044, 13333.3333, 1},    // DMT 11  800x600 @ 75.00Hz / Real FPS: 75.00Hz 
 {11756.1867, 11764.7059, 0},    // DMT 12  800x600 @ 85.00Hz / Real FPS: 85.06Hz (!!)
 {8335.2711, 8333.3333, 0},      // DMT 13  800x600 @ 120.00Hz / Real FPS: 119.97Hz (!)
 {16666.5200, 16666.6667, 1},    // DMT 14  848x480 @ 60.00Hz / Real FPS: 60.00Hz 
 { 0, 0, 0 },                    // DMT 15  (invalid - no vsync interrupt) 
 {16665.5667, 16666.6667, 1},    // DMT 16  1024x768 @ 60.00Hz / Real FPS: 60.00Hz 
 {14271.5444, 14285.7143, 0},    // DMT 17  1024x768 @ 70.00Hz / Real FPS: 70.07Hz (!!)
 {13328.2078, 13333.3333, 0},    // DMT 18  1024x768 @ 75.00Hz / Real FPS: 75.03Hz (!)
 {11765.1367, 11764.7059, 1},    // DMT 19  1024x768 @ 85.00Hz / Real FPS: 85.00Hz 
 {8334.1067, 8333.3333, 0},      // DMT 20  1024x768 @ 120.00Hz / Real FPS: 119.99Hz (!)
 {13333.3056, 13333.3333, 1},    // DMT 21  1152x864 @ 75.00Hz / Real FPS: 75.00Hz 
 {16668.0756, 16666.6667, 1},    // DMT 22  1280x768 @ 60.00Hz / Real FPS: 59.99Hz 
 {16702.7644, 16666.6667, 0},    // DMT 23  1280x768 @ 60.00Hz / Real FPS: 59.87Hz (!!)
 {13352.3356, 13333.3333, 0},    // DMT 24  1280x768 @ 75.00Hz / Real FPS: 74.89Hz (!!)
 {11787.2856, 11764.7059, 0},    // DMT 25  1280x768 @ 85.00Hz / Real FPS: 84.84Hz (!!!)
 {8347.3511, 8333.3333, 0},      // DMT 26  1280x768 @ 120.00Hz / Real FPS: 119.80Hz (!!!)
 {16691.7967, 16666.6667, 0},    // DMT 27  1280x800 @ 60.00Hz / Real FPS: 59.91Hz (!!)
 {16719.4778, 16666.6667, 0},    // DMT 28  1280x800 @ 60.00Hz / Real FPS: 59.81Hz (!!!)
 {13345.0167, 13333.3333, 0},    // DMT 29  1280x800 @ 75.00Hz / Real FPS: 74.93Hz (!!)
 {11781.3256, 11764.7059, 0},    // DMT 30  1280x800 @ 85.00Hz / Real FPS: 84.88Hz (!!)
 {8339.6622, 8333.3333, 0},      // DMT 31  1280x800 @ 120.00Hz / Real FPS: 119.91Hz (!!)
 {16666.6356, 16666.6667, 1},    // DMT 32  1280x960 @ 60.00Hz / Real FPS: 60.00Hz 
 {11764.3600, 11764.7059, 1},    // DMT 33  1280x960 @ 85.00Hz / Real FPS: 85.00Hz 
 {10170.8433, 8333.3333, 0},     // DMT 34  1280x960 @ 120.00Hz / Real FPS: 98.32Hz (???)
 {16661.1533, 16666.6667, 0},    // DMT 35  1280x1024 @ 60.00Hz / Real FPS: 60.02Hz (!)
 {13328.9267, 13333.3333, 0},    // DMT 36  1280x1024 @ 75.00Hz / Real FPS: 75.02Hz (!)
 {11761.3422, 11764.7059, 0},    // DMT 37  1280x1024 @ 85.00Hz / Real FPS: 85.02Hz (!)
 {12505.9056, 8333.3333, 0},     // DMT 38  1280x1024 @ 120.00Hz / Real FPS: 79.96Hz (???)
 {16662.4356, 16666.6667, 0},    // DMT 39  1360x768 @ 60.00Hz / Real FPS: 60.02Hz (!)
 {8335.6222, 8333.3333, 0},      // DMT 40  1360x768 @ 120.00Hz / Real FPS: 119.97Hz (!)
 {16681.1611, 16666.6667, 0},    // DMT 41  1400x1050 @ 60.00Hz / Real FPS: 59.95Hz (!!)
 {16672.6300, 16666.6667, 0},    // DMT 42  1400x1050 @ 60.00Hz / Real FPS: 59.98Hz (!)
 {13357.0478, 13333.3333, 0},    // DMT 43  1400x1050 @ 75.00Hz / Real FPS: 74.87Hz (!!)
 {15385.5456, 11764.7059, 0},    // DMT 44  1400x1050 @ 85.00Hz / Real FPS: 65.00Hz (???)
 {14660.3656, 8333.3333, 0},     // DMT 45  1400x1050 @ 120.00Hz / Real FPS: 68.21Hz (???)
 {16694.0467, 16666.6667, 0},    // DMT 46  1440x900 @ 60.00Hz / Real FPS: 59.90Hz (!!)
 {16697.9311, 16666.6667, 0},    // DMT 47  1440x900 @ 60.00Hz / Real FPS: 59.89Hz (!!)
 {13336.0844, 13333.3333, 0},    // DMT 48  1440x900 @ 75.00Hz / Real FPS: 74.98Hz (!)
 {11786.5633, 11764.7059, 0},    // DMT 49  1440x900 @ 85.00Hz / Real FPS: 84.84Hz (!!!)
 {11559.8933, 8333.3333, 0},     // DMT 50  1440x900 @ 120.00Hz / Real FPS: 86.51Hz (???)
 {16666.6389, 16666.6667, 1},    // DMT 51  1600x1200 @ 60.00Hz / Real FPS: 60.00Hz 
 {18751.5811, 15384.6154, 0},    // DMT 52  1600x1200 @ 65.00Hz / Real FPS: 53.33Hz (???)
 {21926.3644, 14285.7143, 0},    // DMT 53  1600x1200 @ 70.00Hz / Real FPS: 45.61Hz (???)
 {23551.2544, 13333.3333, 0},    // DMT 54  1600x1200 @ 75.00Hz / Real FPS: 42.46Hz (???)
 {27574.8411, 11764.7059, 0},    // DMT 55  1600x1200 @ 85.00Hz / Real FPS: 36.26Hz (???)
 {25608.1700, 8333.3333, 0},     // DMT 56  1600x1200 @ 120.00Hz / Real FPS: 39.05Hz (???)
 {16699.1289, 16666.6667, 0},    // DMT 57  1680x1050 @ 60.00Hz / Real FPS: 59.88Hz (!!)
 {16679.4256, 16666.6667, 0},    // DMT 58  1680x1050 @ 60.00Hz / Real FPS: 59.95Hz (!)
 {19974.2322, 13333.3333, 0},    // DMT 59  1680x1050 @ 75.00Hz / Real FPS: 50.06Hz (???)
 {22450.1178, 11764.7059, 0},    // DMT 60  1680x1050 @ 85.00Hz / Real FPS: 44.54Hz (???)
 {21918.6300, 8333.3333, 0},     // DMT 61  1680x1050 @ 120.00Hz / Real FPS: 45.62Hz (???)
 {29355.4167, 16666.6667, 0},    // DMT 62  1792x1344 @ 60.00Hz / Real FPS: 34.07Hz (???)
 {40942.9344, 13333.3333, 0},    // DMT 63  1792x1344 @ 75.00Hz / Real FPS: 24.42Hz (???)
 {32678.6922, 8333.3333, 0},     // DMT 64  1792x1344 @ 120.00Hz / Real FPS: 30.60Hz (???)
 {33338.8356, 16666.6667, 0},    // DMT 65  1856x1392 @ 60.00Hz / Real FPS: 30.00Hz (???)
 {43101.2022, 13333.3333, 0},    // DMT 66  1856x1392 @ 75.00Hz / Real FPS: 23.20Hz (???)
 {33353.9011, 8333.3333, 0},     // DMT 67  1856x1392 @ 120.00Hz / Real FPS: 29.98Hz (???)
 {16680.4989, 16666.6667, 0},    // DMT 68  1920x1200 @ 60.00Hz / Real FPS: 59.95Hz (!)
 {26529.7044, 16666.6667, 0},    // DMT 69  1920x1200 @ 60.00Hz / Real FPS: 37.69Hz (???)
 {34865.5789, 13333.3333, 0},    // DMT 70  1920x1200 @ 75.00Hz / Real FPS: 28.68Hz (???)
 {35559.1478, 11764.7059, 0},    // DMT 71  1920x1200 @ 85.00Hz / Real FPS: 28.12Hz (???)
 {28388.3211, 8333.3333, 0},     // DMT 72  1920x1200 @ 120.00Hz / Real FPS: 35.23Hz (???)
 {41214.8089, 16666.6667, 0},    // DMT 73  1920x1440 @ 60.00Hz / Real FPS: 24.26Hz (???)
 {47314.2033, 13333.3333, 0},    // DMT 74  1920x1440 @ 75.00Hz / Real FPS: 21.14Hz (???)
 {37899.1633, 8333.3333, 0},     // DMT 75  1920x1440 @ 120.00Hz / Real FPS: 26.39Hz (???)
 {47903.0133, 16666.6667, 0},    // DMT 76  2560x1600 @ 60.00Hz / Real FPS: 20.88Hz (???)
 {62158.2667, 16666.6667, 0},    // DMT 77  2560x1600 @ 60.00Hz / Real FPS: 16.09Hz (???)
 {53734.3933, 13333.3333, 0},    // DMT 78  2560x1600 @ 75.00Hz / Real FPS: 18.61Hz (???)
 {78512.1200, 11764.7059, 0},    // DMT 79  2560x1600 @ 85.00Hz / Real FPS: 12.74Hz (???)
 {37383.8078, 8333.3333, 0},     // DMT 80  2560x1600 @ 120.00Hz / Real FPS: 26.75Hz (???)
 {16725.3067, 16666.6667, 0},    // DMT 81  1366x768 @ 60.00Hz / Real FPS: 59.79Hz (!!!)
 {16666.6378, 16666.6667, 1},    // DMT 82  1920x1080 @ 60.00Hz / Real FPS: 60.00Hz 
 {16666.6433, 16666.6667, 1},    // DMT 83  1600x900 @ 60.00Hz / Real FPS: 60.00Hz 
 {16666.6378, 16666.6667, 1},    // DMT 84  2048x1152 @ 60.00Hz / Real FPS: 60.00Hz 
 {16666.6111, 16666.6667, 1},    // DMT 85  1280x720 @ 60.00Hz / Real FPS: 60.00Hz 
 {16666.6611, 16666.6667, 1}     // DMT 86  1366x768 @ 60.00Hz / Real FPS: 60.00Hz 
};
@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Mar 26, 2018

Without custom overclock commands, the max pixel clock frequency is 163MHz (you can increase this with hdmi_pixel_freq_limit in config.txt but that is in overclock territory).
That means the highest pixel rate we can support is 1920x1200@60 in reduced blanking mode (DMT68).
Resolutions and framerates above this will not be supported.

@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Mar 26, 2018

These are DMT modes that meet this pixel clock requirement.

640x400@85    2   31500000
IBM-VGA@85    3   35500000
VGA@60        4   25200000
VGA@72        5   31500000
VGA@75        6   31500000
VGA@85        7   36000000
SVGA@56       8   36000000
SVGA@60       9   40000000
SVGA@72      10   50000000
SVGA@75      11   49500000
SVGA@85      12   56250000
SVGA@120     13   73250000
848x480@60   14   33750000
XGA@43       15   44900000
XGA@60       16   65000000
XGA@70       17   75000000
XGA@75       18   78750000
XGA@85       19   94500000
XGA@120      20  115500000
XGA+@75      21  108000000
WXGArb       22   68250000
WXGA@60      23   79500000
WXGA@75      24  102250000
WXGA@85      25  117500000
WXGA@120     26  140250000
1280x8000rb  27   71000000
1280x800@60  28   83500000
1280x800@75  29  106500000
1280x800@85  30  122500000
1280x800@120 31  146250000
1280x960@60  32  108000000
1280x960@85  33  148500000
SXGA@60      35  108000000
SXGA@75      36  135000000
SXGA@85      37  157500000
1360x768@60  39   85500000
1360x768@120 40  148250000
SXGA+rb      41  101000000
SXGA+@60     42  121750000
SXGA+@75     43  156000000
1440x900rb   46   88750000
1440x900@60  47  106500000
1440x900@75  48  136750000
1440x900@85  49  157000000
UXGA@60      51  162000000
SWXGA+rb     57  119000000
SWXGA+@60    58  146250000
WUXGArb      68  154000000
1366x768@60  81   85500000
1080p60      82  148500000
1600x900rb   83  108000000
2048x1152rb  84  162000000
720p60       85   74250000
1366x768rb   86   72000000
@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Mar 26, 2018

This may be useful for determining the pixel clock for a valid mode.

$ vcgencmd measure_clock pixel
frequency(29)=148500000
@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Mar 26, 2018

Despite the name vcgencmd hdmi_adjust_clock will also apply to composite output.

@PaulSlocum

This comment has been minimized.

Copy link
Author

PaulSlocum commented Mar 26, 2018

Thanks for all this super useful information. I have a much better understanding now, and I mostly have synchronization working pretty well on various monitors now. However, although I've tried changing hdmi_adjust_clock with composite output several times, I can't see any changes. With the vsync timing program I posted in my first comment, you can clearly see changes to the vsync frame timing when the hdmi clock is set faster or slower when using hdmi output, but I always get 16683.3 usec for the frame timing on composite no matter what hdmi clock adjustment value I set. Is there something I need to do differently?

@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Mar 27, 2018

I've traced the code through on composite. The gencmd does try to adjust the vec PLL but I found it gets ignored later with this comment:
// unfortunately PLL changes cause a glitch on the VEC
I've disabled that in this test firmware and it does allow your fps measurement test to show the difference, but it may cause glitches when changing (unfortunately no composite display to hand to confirm this at present). Feel free to try this though:
https://drive.google.com/uc?id=1BitaKIlvtb0-PErnd4rXoQ-z7-SE6SMz&export=download

@PaulSlocum

This comment has been minimized.

Copy link
Author

PaulSlocum commented Mar 28, 2018

Thank you, I can now see that the timing changes.

I have a consumer CRT TV here and what I see is that the color gradually disappears when I set an hdmi_adjust_clock value further off center than about 1.0001. But the color returns when I set it back to 1.0. Unless there is some additional "glitch", then this is workable for my situation because I can keep hdmi_adjust_clock at or very close to the center frequency after it has reached to the phase I desire.

Maybe that linkage was disabled in your code because Omxplayer's HDMI phase shifting system could potentially cause color loss sometimes when used with composite video?

@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Mar 28, 2018

So smaller changes (e.g. 0.99995-1.00005) produce no disturbance on your display?
Only when you get to aroud 100ppm it starts to lose colour lock?

@PaulSlocum

This comment has been minimized.

Copy link
Author

PaulSlocum commented Mar 28, 2018

Yes, color is maybe very slightly off at 1.0001. Color becomes clearly distorted at 1.00013. Color disappears at 1.00014. But I still get a clear black and white picture at the maximum and minimum shift values. I also tried it on an LCD monitor with a composite input and got pretty much the same results as the CRT.

I've also noticed that it is possible to cause issues with HDMI/DVI monitors by changing hdmi_adjust_clock, but I've never seen Omxplayer alone cause problems. Maybe you just can't use extreme values or instantly go from the maximum to minimum values of hdmi_adjust_clock. Usually the monitor just goes black for a moment and sometimes shows its on screen display.

@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Mar 28, 2018

You can limit the change with hdmi_clock_change_limit=<ppm>
with the number specified as parts per million. This applies to composite too.
It defaults to 1000, but setting it to 100 or less may be safer.

There are a few devices that require this with HDMI (Onkyo receivers mostly - not seen it with a display) when using omxplayer with its pll adjustment on.

Composite may have worse behaviour but it's hard to predict without testing on all possible devices, so I'm a little reluctant to enable this by default. It could perhaps be enabled through a config option.

@PaulSlocum

This comment has been minimized.

Copy link
Author

PaulSlocum commented Mar 31, 2018

The custom firmware you built works great for our project, but it would be nice to have it as a config option in the future.

Could you help me understand how to calculate the exact frame duration from results of the vcgencmd measure_clock pixel command? I'm having trouble figuring out the exact pixel count in a frame including overscan and blanking.

I'm going to close this issue soon, but I might have a couple more questions after I do additional testing this weekend.

@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Mar 31, 2018

The total height of image (including blanking) will be VBP+HEIGHT+VFP.
The total width of image (including blanking) will be HBP+WIDTH+HFP.
The total pixel clocks per frame will be total_pixels=total_height * total_width
pixel_clock is total_pixels * fps
So fps=pixel_clock/((VBP+HEIGHT+VFP)*(HBP+WIDTH+HFP`))
The values of VBP, VFP etc can be got from the HDMI specs.

@PaulSlocum

This comment has been minimized.

Copy link
Author

PaulSlocum commented Apr 6, 2018

Thanks for all your help. Everything seems to be working as expected. I don't yet have two CRTs to do the final synchronization test, but based on what I've seen I expect it will work.

It's really fantastic to have this kind of deep control on the Raspberry Pi and also to have direct interaction with engineers. I always recommend the Raspberry Pi platform to anyone who will listen.

@PaulSlocum PaulSlocum closed this Apr 6, 2018

popcornmix added a commit that referenced this issue Apr 9, 2018

kernel: Bump to 4.14.33
kernel: net: lan78xx: Request s/w csum check on VLAN tagged packets
See: raspberrypi/linux#2458

kernel: lan78xx: Crash in lan78xx_writ_reg (Workqueue: events lan78xx_deferred_multicast_write)

firmware: arm_loader: Use a wrapper to set clocks either through turbo or non-turbo interfaces
See: #967

firmware: platform: Allow vec pll to be adjusted
See: #960

popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Apr 9, 2018

kernel: Bump to 4.14.33
kernel: net: lan78xx: Request s/w csum check on VLAN tagged packets
See: raspberrypi/linux#2458

kernel: lan78xx: Crash in lan78xx_writ_reg (Workqueue: events lan78xx_deferred_multicast_write)

firmware: arm_loader: Use a wrapper to set clocks either through turbo or non-turbo interfaces
See: raspberrypi/firmware#967

firmware: platform: Allow vec pll to be adjusted
See: raspberrypi/firmware#960
@popcornmix

This comment has been minimized.

Copy link
Contributor

popcornmix commented Apr 9, 2018

Latest firmware supports this but is disabled by default as we suspect it may cause issues for some users.
There is a secret switch to enable it - add safe_mode_gpio=64 to config.txt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.