vga_pw sysfs file

[Oskar Senft]

Hi

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
rebooting.

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
quick.

Thanks
Oskar.


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
> though...).
>
> [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.
>
> Cheers,
>
>
> Jeremy
>