vga_pw sysfs file
osk at google.com
Wed Nov 17 11:54:20 AEDT 2021
Jeremy, Thanks for the explanation!
I think the problem is that the gfx driver effectively changed the
semantic of the "vga_pw": In the past this was merely the contents of
said register. With the new driver, it claims to report "1" if the
host is driving the VGA, 0 otherwise. From what I can tell, it's not
possible to make such a statement just from the VGA scratch registers.
This is evident in that the uart_render_controller uses additional
signals (i.e. the "power" / run state of the host) to make a
determination on whether the host is driving VGA or not.
No that you mentioned it, I do remember from testing a couple of years
ago, that the register does not reliably return to 0 when the host is
With that, I suggest changing the gfx driver's "vga_pw" back to just
reporting the contents of the register and leaving it to a user space
process (like uart_render_controller) to use a variety of signals to
make a determination.
Joel, if I sent such a patch, would you accept that? If it's easier to
argue with the actual patch in hand, I'd be happy to prep it real
On Tue, Nov 16, 2021 at 7:48 PM Jeremy Kerr <jk at codeconstruct.com.au> wrote:
> Hi Oskar,
> I think Joel will send some details on the gfx driver side, but:
> > In uart_render_controller, however, we're checking whether the bottom
> > 8 bit equal to 0xa8 (why are we not checking for != 0 here?)
> This is because we want to ensure that we're in the init process of the
> host-side GPU driver, and not some arbitrary other access; it's been a
> while since working on this, but I *think* I remember seeing other areas
> of the scratch reg at non-zero values (granted, not the lower 8 bits
> [There was some discussion with aspeed about the init value
> of 0x0 not being guaranteed on some part of the scratch register
> interface, but I don't recall what that applied to]
> We could change this to != 0, but there's a solid convention that the
> host-side driver is writing 0xa8 as the first part of init, so I think
> the current behaviour would provide a more solid check.
More information about the Linux-aspeed