* [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis @ 2016-06-09 17:17 George McCollister 2016-06-11 0:25 ` Bin Meng 0 siblings, 1 reply; 6+ messages in thread From: George McCollister @ 2016-06-09 17:17 UTC (permalink / raw) To: u-boot 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. Regards, George McCollister ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis 2016-06-09 17:17 [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis George McCollister @ 2016-06-11 0:25 ` Bin Meng 2016-06-13 16:12 ` George McCollister 0 siblings, 1 reply; 6+ messages in thread From: Bin Meng @ 2016-06-11 0:25 UTC (permalink / raw) To: u-boot Hi George, +Simon, Stefan On Fri, Jun 10, 2016 at 1:17 AM, George McCollister <george.mccollister@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. 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. 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis 2016-06-11 0:25 ` Bin Meng @ 2016-06-13 16:12 ` George McCollister 2016-06-14 1:45 ` Bin Meng 0 siblings, 1 reply; 6+ messages in thread From: George McCollister @ 2016-06-13 16:12 UTC (permalink / raw) To: u-boot On Fri, Jun 10, 2016 at 7:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi George, > > +Simon, Stefan > > On Fri, Jun 10, 2016 at 1:17 AM, George McCollister > <george.mccollister@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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis 2016-06-13 16:12 ` George McCollister @ 2016-06-14 1:45 ` Bin Meng 2016-06-14 12:46 ` George McCollister 0 siblings, 1 reply; 6+ messages in thread From: Bin Meng @ 2016-06-14 1:45 UTC (permalink / raw) To: u-boot Hi George, On Tue, Jun 14, 2016 at 12:12 AM, George McCollister <george.mccollister@gmail.com> wrote: > On Fri, Jun 10, 2016 at 7:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi George, >> >> +Simon, Stefan >> >> On Fri, Jun 10, 2016 at 1:17 AM, George McCollister >> <george.mccollister@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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis 2016-06-14 1:45 ` Bin Meng @ 2016-06-14 12:46 ` George McCollister 2016-06-15 8:32 ` Bin Meng 0 siblings, 1 reply; 6+ messages in thread From: George McCollister @ 2016-06-14 12:46 UTC (permalink / raw) To: u-boot On Mon, Jun 13, 2016 at 8:45 PM, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi George, > > On Tue, Jun 14, 2016 at 12:12 AM, George McCollister > <george.mccollister@gmail.com> wrote: >> On Fri, Jun 10, 2016 at 7:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote: >>> Hi George, >>> >>> +Simon, Stefan >>> >>> On Fri, Jun 10, 2016 at 1:17 AM, George McCollister >>> <george.mccollister@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. Sounds great! > >>> >>> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis 2016-06-14 12:46 ` George McCollister @ 2016-06-15 8:32 ` Bin Meng 0 siblings, 0 replies; 6+ messages in thread From: Bin Meng @ 2016-06-15 8:32 UTC (permalink / raw) To: u-boot Hi George, On Tue, Jun 14, 2016 at 8:46 PM, George McCollister <george.mccollister@gmail.com> wrote: > On Mon, Jun 13, 2016 at 8:45 PM, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi George, >> >> On Tue, Jun 14, 2016 at 12:12 AM, George McCollister >> <george.mccollister@gmail.com> wrote: >>> On Fri, Jun 10, 2016 at 7:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> Hi George, >>>> >>>> +Simon, Stefan >>>> >>>> On Fri, Jun 10, 2016 at 1:17 AM, George McCollister >>>> <george.mccollister@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. > > Sounds great! > Patches are available at u-boot-x86/gnvs-working branch now. Please test it. Regards, Bin ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-06-15 8:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-09 17:17 [U-Boot] x86: acpi: Disabling SoC functions defined in ASL on a per board basis George McCollister 2016-06-11 0:25 ` Bin Meng 2016-06-13 16:12 ` George McCollister 2016-06-14 1:45 ` Bin Meng 2016-06-14 12:46 ` George McCollister 2016-06-15 8:32 ` Bin Meng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.