[U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis

[George McCollister]

On Fri, Jun 10, 2016 at 7:25 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi George,
>
> +Simon, Stefan
>
> On Fri, Jun 10, 2016 at 1:17 AM, George McCollister
> <george.mccollister at gmail.com> wrote:
>> Does anyone have any ideas on how we might go about disabling
>> functions defined in arch/x86/include/asm/arch-*/acpi on a per board
>> basis? With DT it's trivial to define all of the functions available
>> on an SoC and default them to disabled in the .dtsi, then simply mark
>> them as enabled in the board .dts if the board uses them. I need to
>> disable the internal UART definition for the baytrail board I'm adding
>> since if it's included the off chip UART gets killed when Linux does
>> it's acpi_bus_scan.
>>
>
> Which board are you using? Looks you are using a board that is similar
> to conga-qeval20-qa3-e3845.
I'm using an Advantech SOM-DB5800 carrier board with an SOM-6867 Com
Express board installed. I have a patch almost ready to add it to
u-boot. I'll need to make some changes to reflect recent patches and
was hoping to get this issue and azalia configuration resolved as
well. I could upstream it sooner but the UART will be broken in linux
(unless hacked out of dsdt prior to build) and HD audio wouldn't work.

>
> See the TODO comments in arch/x86/include/asm/arch-baytrail/acpi/lpc.asl.
>
> /* Internal UART */
> Device (IURT)
> {
> Name(_HID, EISAID("PNP0501"))
> Name(_UID, 1)
>
> Method(_STA, 0, Serialized)
> {
> /*
> * TODO:
> *
> * Need to hide the internal UART depending on whether
> * internal UART is enabled or not so that external
> * SuperIO UART can be exposed to system.
> */
> Store(1, UI3E)
> Store(1, UI4E)
> Store(1, C1EN)
> Return (STA_VISIBLE)
> }
>
> To solve this, we need introduce a variable that is set at runtime by
> U-Boot to tell the ASL codes to hide the internal UART. This is
> documented in README.x86 below as optional features, but I also
> mentioned we will need this sooner or later.
Okay, I see how this is handled in coreboot. Looks like global_nvs_t
for fsp_baytrail in coreboot has over 20 parameters I suppose I'd just
start with one and it would be expanded as needed. I need to
investigate more about gnvs then maybe I can implement it, time
permitting.

>
> Features that are optional:
>  * ACPI global NVS support. We may need it to simplify ASL code logic if
>    utilizing NVS variables. Most likely we will need this sooner or later.
>
> Another place that will need such feature is the memory size. We need
> tell ASL code to dynamically create the PCI memory space.
>
> Regards,
> Bin