Eric Sultan wrote:
> Garrett D'Amore wrote:
>> ...
>> 1) Would it make sense to support this on x86 hardware as well? (I'm
>> thinking server class headless systems, which I gather is the target
>> market for these chips.)
> It does make sense to support this on Solaris x86.
>>
>> 2) Does the driver support any power management features? (power(9e)
>> or DDI_SUSPEND?)
> The kernel device driver does not support chip-level power(9e)
> power-management, but does support display-level PM.
> I think, and will verify, that the driver does not support
> DDI_SUSPEND/DDI_RESUME.
DDI_SUSPEND/RESUME would be helpful for some server class systems.
(Especially when we have useful Wake-On-LAN.) It might be worth
supporting, but can be done as a bug fix/rfe.
>
>> 3) Does this driver support the graphics mode console and/or virtual
>> terminals? (Perhaps this question doesn't make sense -- I'm not sure
>> how this driver interacts with remote consoles... or maybe I'm
>> misunderstanding something.)
> Yes, the code does support coherent consoles. I need to look into
> virtual terminals before I can answer.
>
>>
>> 4) Actually, if this behaves in a manner that is quite different from
>> a typical framebuffer with local display and keyboard, then a bit
>> more detailed background information would be helpful. Of course, if
>> it really is just a typical framebuffer, then just simply say so...
>> the ASPEED website doesn't really help make things clear to me.
> Yes, the AST code will behave like a typical framebuffer.
Thank you for your answers to my questions, and Neal's. Sounds like
you've got all the bases covered.
Please consider this my formal +1 for this project.
-- Garrett
>
> -- Eric
>
>
