Simon Glass has uploaded this change for review. ( https://review.coreboot.org/25967
Change subject: mb/google/kahlee/variants/grunt: Enable BayHub720 driver
......................................................................
mb/google/kahlee/variants/grunt: Enable BayHub720 driver
Enable this driver along with power saving.
BUG=b:73726008
BRANCH=none
TEST=boot and see this message:
BayHub BH720: Power-saving enabled 110103
>From linux:
$ iotools pci_read32 2 0 0 0x90
0x00110103
Change-Id: I850e923f73e01fe629d66ad61b65afa58035845c
Signed-off-by: Simon Glass <sjg(a)chromium.org>
---
M src/mainboard/google/kahlee/Kconfig
M src/mainboard/google/kahlee/variants/grunt/devicetree.cb
2 files changed, 8 insertions(+), 2 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/67/25967/1
diff --git a/src/mainboard/google/kahlee/Kconfig b/src/mainboard/google/kahlee/Kconfig
index 22925f4..24881b5 100644
--- a/src/mainboard/google/kahlee/Kconfig
+++ b/src/mainboard/google/kahlee/Kconfig
@@ -36,6 +36,7 @@
select SOC_AMD_PSP_SELECTABLE_SMU_FW
select SOC_AMD_SMU_FANLESS
select HAVE_ACPI_RESUME
+ select DRIVERS_GENERIC_BH720 if BOARD_GOOGLE_GRUNT
if BOARD_GOOGLE_BASEBOARD_KAHLEE
diff --git a/src/mainboard/google/kahlee/variants/grunt/devicetree.cb b/src/mainboard/google/kahlee/variants/grunt/devicetree.cb
index cfc3198..0d4ad09 100644
--- a/src/mainboard/google/kahlee/variants/grunt/devicetree.cb
+++ b/src/mainboard/google/kahlee/variants/grunt/devicetree.cb
@@ -58,11 +58,16 @@
device pci 0.0 on end # Root Complex
device pci 1.0 on end # Internal Graphics P2P bridge 0x98e4
device pci 1.1 on end # Internal Multimedia
- device pci 2.0 on end # PCIe Host Bridge
+ device pci 2.0 on end # PCIe Host Bridge
device pci 2.1 on end #
device pci 2.2 on end #
device pci 2.3 on end #
- device pci 2.4 on end #
+ device pci 2.4 on
+ chip drivers/generic/bayhub
+ register "power_saving" = "1"
+ device pci 00.0 on end
+ end
+ end #
device pci 2.5 on end #
device pci 8.0 on end # PSP
device pci 9.0 on end # PCIe Host Bridge
--
To view, visit https://review.coreboot.org/25967
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I850e923f73e01fe629d66ad61b65afa58035845c
Gerrit-Change-Number: 25967
Gerrit-PatchSet: 1
Gerrit-Owner: Simon Glass <sjg(a)chromium.org>
Nico Huber has posted comments on this change. ( https://review.coreboot.org/25921 )
Change subject: Documentation/Intel: Add MultiProcessorInit documentation
......................................................................
Patch Set 3:
>> (4 comments)
>
> I agree with you on most this comments that you have put, but my
> only point is that, if i tries to put this implementation of
> creating EDK2 interface inside Coreboot to do certain thinks might
> not justify the purpose of adding those "foreign" interface as your
> words. Today coreboot code is so independent in nature so that we
> don;t need to talk help of such EDK2 interface to do certain
> things, if we really want to increase mp_init.c capability we could
> have done the same using native c why UEFI?
>
> UEFI is because this implementation only targeted for Intel fsp 9th
> gen + designs where we might want to do few things using coreboot
> callback from fsp, hence i could see a direct dependencies between
> this implementation proposal and supporting FSP model to justify
> that callback using SkipMpInit=0. if i make this code into common
> x86 place as well, no one will use this except 9th gen + socs from
> intel with proper FSP support.
>
> whats the point of keeping certain code into common when there are
> no user of that code expect intel native FSP support?
One point would be visibility. If anybody not familiar with the
soc/intel/ code would look at our MP interfaces, he might miss
the fact that a generic implementation of your EFI interface
already exists, might even reimplement it one way or another and
coreboot would decompose a little more.
That's just a general thought. I agree that this interface might
be too FSP specific (from a coreboot point of view).
>
> Hope i could able to explain my concern, i have written this
> document so that i can keep it anywhere but myself not very
> convinced about why other users will interested to make use of EFI
> code interface inside x86/coreboot when mp_init.c is capable of
> doing everything without those APIs.
You are right. I wouldn't expect it to be used inside coreboot,
I was implying other potential blob use cases.
--
To view, visit https://review.coreboot.org/25921
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I5b6096ef31d8a523c00cbad39ab9d4884e735fde
Gerrit-Change-Number: 25921
Gerrit-PatchSet: 3
Gerrit-Owner: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: Philipp Deppenwiese <zaolin.daisuki(a)gmail.com>
Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Nico Huber <nico.h(a)gmx.de>
Gerrit-CC: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Comment-Date: Tue, 01 May 2018 13:10:39 +0000
Gerrit-HasComments: No
Gerrit-HasLabels: No
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/25921 )
Change subject: Documentation/Intel: Add MultiProcessorInit documentation
......................................................................
Patch Set 3:
> (4 comments)
I agree with you on most this comments that you have put, but my only point is that, if i tries to put this implementation of creating EDK2 interface inside Coreboot to do certain thinks might not justify the purpose of adding those "foreign" interface as your words. Today coreboot code is so independent in nature so that we don;t need to talk help of such EDK2 interface to do certain things, if we really want to increase mp_init.c capability we could have done the same using native c why UEFI?
UEFI is because this implementation only targeted for Intel fsp 9th gen + designs where we might want to do few things using coreboot callback from fsp, hence i could see a direct dependencies between this implementation proposal and supporting FSP model to justify that callback using SkipMpInit=0. if i make this code into common x86 place as well, no one will use this except 9th gen + socs from intel with proper FSP support.
whats the point of keeping certain code into common when there are no user of that code expect intel native FSP support?
Hope i could able to explain my concern, i have written this document so that i can keep it anywhere but myself not very convinced about why other users will interested to make use of EFI code interface inside x86/coreboot when mp_init.c is capable of doing everything without those APIs.
--
To view, visit https://review.coreboot.org/25921
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I5b6096ef31d8a523c00cbad39ab9d4884e735fde
Gerrit-Change-Number: 25921
Gerrit-PatchSet: 3
Gerrit-Owner: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: Philipp Deppenwiese <zaolin.daisuki(a)gmail.com>
Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Nico Huber <nico.h(a)gmx.de>
Gerrit-CC: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Comment-Date: Tue, 01 May 2018 12:34:49 +0000
Gerrit-HasComments: No
Gerrit-HasLabels: No
Nico Huber has posted comments on this change. ( https://review.coreboot.org/25921 )
Change subject: Documentation/Intel: Add MultiProcessorInit documentation
......................................................................
Patch Set 3:
(4 comments)
https://review.coreboot.org/#/c/25921/3/Documentation/Intel/MultiProcessorI…
File Documentation/Intel/MultiProcessorInit/MultiProcessorInit.md:
https://review.coreboot.org/#/c/25921/3/Documentation/Intel/MultiProcessorI…
PS3, Line 7: for Intel 9th Gen (Cannon Lake) and beyond CPUs
> i have made this clear why we need to create this API interface in
> this section.
>
> Although i agree this is very generic implementation and dependent
> on mp_init.c so going forward we might feel a feed to make it
> generic, today we can't do because it has some EDK2 header
> dependencies which is only available for intel UDK2017 platform
> (CNL onwards).
I don't care. If somebody made a mess with these headers, fix it
please. Something like "vendor x does weird stuff with API headers
y" shouldn't stop progress of coreboot.
On second thought, you don't have to do anything. A correct solu-
tion would let the user decide, based on a properly guarded Kconfig
option. And then you don't have any compilation conflicts because
the code would simply not be compiled.
>
> btw, why you might need to have 2 document, i'm not going to
> explain how mp_init works on x86 platform, those are already in
> SDM, this document is to only talk about why we are creating EDK2
> interface in coreboot and how intel thinks this can help our
> partners design.
That's ok, I didn't mean a general document about MP init. Just
in case you can figure out the header problem, the API documen-
tation should be separated from the justification / Intel speci-
fics.
https://review.coreboot.org/#/c/25921/3/Documentation/Intel/MultiProcessorI…
PS3, Line 25: closed source in nature
> i don;t understand what you mean by can't be trusted ?
It is my try to interpret English (I'm not a native speaker).
I tried to make something up that "closed source in nature"
could mean.
If you would publish it, would it change its nature? That
seems wrong to me. But I might just need help how the term
"nature" is used in English.
https://review.coreboot.org/#/c/25921/3/Documentation/Intel/MultiProcessorI…
PS3, Line 35: It’s also possible for coreboot to extend its own
: support model and create a sets of APIs which later can be used by FSP to run CPU feature
: programming using coreboot published APIs
> i guess you have missed problem statement, you are referring to proposal and try to understand why i […]
Sorry I think we're talking past each other.
Just this sentence alone. You say "coreboot [can] create a set of
APIs which later can be used by FSP". I say, coreboot has created
a set of APIs (cpu/x86/mp.h) and they can be published and used by
FSP now.
Those are two conflicting statements no matter the problem state-
ment, AFAICS.
https://review.coreboot.org/#/c/25921/3/Documentation/Intel/MultiProcessorI…
PS3, Line 68: 1. coreboot was using SkipMpInit=1 which will skip entire FSP CPU feature programming.
> not sure what you mean by coreboot? this is a UPD which is intel fsp specific. […]
I meant "coreboot was using SkipMpInit=1" isn't true for all boards.
coreboot has a setting "FspSkipMpInit" that is set per board in the
devicetree. So a board maintainer already had the choice to enable
MpInit in FSP.
--
To view, visit https://review.coreboot.org/25921
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I5b6096ef31d8a523c00cbad39ab9d4884e735fde
Gerrit-Change-Number: 25921
Gerrit-PatchSet: 3
Gerrit-Owner: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: Philipp Deppenwiese <zaolin.daisuki(a)gmail.com>
Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Nico Huber <nico.h(a)gmx.de>
Gerrit-CC: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Comment-Date: Tue, 01 May 2018 12:22:09 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No