OS_Byte 19 issues

OS_Byte 19 has been causing me a few issues recently, and I can’t quite decide on the best way of solving it.

The problem I’m seeing is as follows:

• Something bad happens (e.g. FIFO underflow, register write at a bad time, bad mode timings, etc.) which causes a SYNCLOST interrupt on OMAP. When this happens it means the display controller state machine has got itself into a bad state and the controller needs to be reset.
• In response to the SYNCLOST IRQ, OMAPVideo starts to asynchronously reset the display controller. The first step is to tell it to enter the stopped state, and to disable all interrupts except the FRAMEDONE IRQ (which will fire once the controller has reached the stopped state, which will be at the end of the current frame)
• Once the FRAMEDONE IRQ is received, OMAPVideo’s interrupt handler will be entered again, and will reset & re-program the display controller. Re-locking the PLLs, etc. will take a while, so it enables interrupts during this process.
• Meanwhile, something in the foreground has requested that the hourglass be turned on. The hourglass module actually delays turning the hourglass on for a short period of time (half a second iIRC?), using TickerV to count down the time remaining. While the OMAPVideo IRQ handler is in the middle of dealing with the FRAMEDONE interrupt, the 100Hz timer IRQ fires, and the Hourglass module decides that it wants to turn the hourglass on now. However when turning it on it makes a call to OS_Byte 19 to make sure that the mouse palette update it performs occurs during vblank. But since VSync IRQs are currently disabled, and OMAPVideo’s IRQ handler is already in the middle of dealing with the FRAMEDONE interrupt, the OS_Byte 19 call puts the system into a deadlock state.

So the problem in a nutshell is that OS_Byte 19 doesn’t have a way of dealing with situations where VSync IRQs are temporarily unavailable – whether due to something like SYNCLOST handling on OMAP, or even something like the fact that VSyncs will almost certainly temporarily stop during a mode change.

Possible solutions I can think of include:

1. Change OMAPVideo to perform the display controller reset with IRQs disabled. This will will leave IRQs disabled for considerably longer than the PRM dictates as the maximum (PRM says 100us, but timing the reset code shows it takes about 1.3ms on OMAP4). It will also only deal with this one case – other cases (e.g. loss of VSync during mode change, loss of VSync in other drivers) will need fixing separately.
2. Change OS_Byte 19 to call the GraphicsV driver to do the VSync wait. This will allow the driver to use its own knowledge of the hardware state to work out whether VSyncs are currently enabled or not and to either wait or return immediately as appropriate. In a multi-monitor world it will also provide a convenient way for a program to sync with the VSync of a specific display (although, using a blocking call to wait for VSync from multiple display would only really make sense if RISC OS supported threads).
3. Change OS_Byte 19 to query the driver to find out if VSyncs are currently enabled. This will reduce code duplication in the sense that we won’t have to have a WFI/Portable_Idle loop (or similar) within each driver.
4. Change the drivers so that they fire off a service call when VSyncs start/stop being generated. The kernel can then track this state and check it from within OS_Byte 19 (much like the kernel already tracks the screen blank state, since it knows VSyncs will be disabled if the screen is blanked). But this could lead to bugs if the driver fails to notify the kernel of a VSync state change – having the driver poll its current state to see if VSyncs are enabled is likely to be a lot more reliable.

Looking at the above options, I’m leaning towards option 3. Anyone have any other preferences?

2 be 3
Heu… 3 with 2 in mind :)

Option 2 – it fits in with the GraphicsV design and future proofs multiple displays.

ADFFS uses 2 to achieve 50fps so if you do go with that option, we’d need to confirm ADFFS doesn’t break it when it suppresses the non-50Hz VSyncs that it’s internal frame pacing code is generating.

From your code perspective, if ADFFS’ blitter was running (ie you’re playing a game) when you issue GraphicsV 1, it will immediately return essentially NOPing the call, so I think that would work for you as it sounds like it’s the VSync wait actually occurring that’s causing the issue.

I don’t have an OMAP machine to test this unfortunately, I don’t even know if ADFFS works on OMAP, I think it failed when you tried it last, so this may be academic. Things have moved on in the upcoming beta release, so it does need testing at some stage.

Happy to assist where I can with RiscPC/Iyonix/Pi/Pi2 ROM testing to ensure there’s no knock on effect for gaming.

Option 2 – it fits in with the GraphicsV design and future proofs multiple displays.

Completely agree on this point…

I don’t even know if ADFFS works on OMAP

Just need to test :)

Note that option 3 doesn’t prevent multiple displays from being used. It’s just slightly harder to use if you want to wait for a certain display.

The wait loop in OS_Byte 19 is actually a good place we could allow callbacks to be triggered (if it’s safe to do so, i.e. SVC stack was empty on entry). Moving the wait loop into the drivers would prevent us from doing that (not that I have any intention to make such a change at the moment – but it might be nice for the future).

There’s also an option 5, which I forgot to list, which is to add a timeout to OS_Byte 19. But that’s a pretty horrible solution, so I doubt we’d want to go with that.

Happy to assist where I can with RiscPC/Iyonix/Pi/Pi2 ROM testing to ensure there’s no knock on effect for gaming.

There shouldn’t be any knock-on effects, other than a reduced chance of stuff hanging.

Looking at the code, I think it’s even possible for OS_Byte 19 to hang if the screen blanker activates – the kernel only checks if the screen is blanked at the start of the wait loop. So if it starts to wait for VSync and then the screen blanker module blanks the screen (which is done from TickerV, not from a VSync IRQ) then the loop may only terminate once the screen is turned back on again.

The wait loop in OS_Byte 19 is actually a good place we could allow callbacks to be triggered

In my ignorance, I thought that was already occurring. So besides OS_Byte utilizing WFI it sounds like OS_Byte 19 is stalling everything, not just the app that’s issued the SWI?

Perhaps OS_Byte 19 should be threaded so it can hand control to Callbacks and have the Callback handler pass back to all apps waiting on OS_Byte 19 when the IRQ occurs.

Looking at the code, I think it’s even possible for OS_Byte 19 to hang if the screen blanker activates – the kernel only checks if the screen is blanked at the start of the wait loop.

That would explain the random hang I see when the screensaver kicks with games running.