Hi George,
On Tue, Jun 14, 2016 at 12:12 AM, George McCollister
<george.mccollis...@gmail.com> wrote:
> On Fri, Jun 10, 2016 at 7:25 PM, Bin Meng <bmeng...@gmail.com> wrote:
>> Hi George,
>>
>> +Simon, Stefan
>>
>> On Fri, Jun 10, 2016 at 1:17 AM, George McCollister
>> <george.mccollis...@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.
>
Great, that means we will have another baytrail board support :)
>>
>> 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.
>
That's actually on my todo list. I will see if I can implement this
soon while leaving you to focus on HD audio.
>>
>> 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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
