Aaron Durbin (adurbin(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17129
-gerrit
commit 56b3f2933a6728e6f0e7d1eee0ad02171f5e34e8
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Tue Oct 25 15:16:26 2016 -0500
mainboard/google/reef: clarify memory part number details
Explain the reasoning for the part_num strings used in the
memory SKU table explaining the necessity of keeping mosys
in sync with the strings used. It's possible that actual part
numbers could change as the higher speed material gets cheaper,
for example.
BUG=chrome-os-partner:58966
Change-Id: If895e52791dc56e283261b3438106116b8b2ea05
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/mainboard/google/reef/variants/baseboard/memory.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/mainboard/google/reef/variants/baseboard/memory.c b/src/mainboard/google/reef/variants/baseboard/memory.c
index c4667f3..ab39a21 100644
--- a/src/mainboard/google/reef/variants/baseboard/memory.c
+++ b/src/mainboard/google/reef/variants/baseboard/memory.c
@@ -62,9 +62,15 @@ const struct lpddr4_swizzle_cfg baseboard_lpddr4_swizzle = {
},
};
+/*
+ * The strings in the part_num field aren't necessarily the exact part
+ * numbers used in all the designs. The reason is that the mosys userland
+ * tool uses these strings for dumping more infromation. Different speed bins
+ * could change in future systems, but the strings still need to match.
+ */
static const struct lpddr4_sku skus[] = {
/*
- * K4F6E304HB-MGCJ - both logical channels While the parts
+ * K4F6E304HB-MG - both logical channels While the parts
* are listed at 16Gb there are 2 ranks per channel so indicate
* the deneisty as 8Gb per rank.
*/
@@ -76,7 +82,7 @@ static const struct lpddr4_sku skus[] = {
.ch1_dual_rank = 1,
.part_num = "K4F6E304HB-MGCJ",
},
- /* K4F8E304HB-MGCJ - both logical channels */
+ /* K4F8E304HB-MG - both logical channels */
[1] = {
.speed = LP4_SPEED_2400,
.ch0_rank_density = LP4_8Gb_DENSITY,
@@ -84,7 +90,7 @@ static const struct lpddr4_sku skus[] = {
.part_num = "K4F8E304HB-MGCJ",
},
/*
- * MT53B512M32D2NP-062WT:C - both logical channels. While the parts
+ * MT53B512M32D2NP - both logical channels. While the parts
* are listed at 16Gb there are 2 ranks per channel so indicate
* the deneisty as 8Gb per rank.
*/
@@ -97,7 +103,7 @@ static const struct lpddr4_sku skus[] = {
.part_num = "MT53B512M32D2NP",
.disable_periodic_retraining = 1,
},
- /* MT53B256M32D1NP-062 WT:C - both logical channels */
+ /* MT53B256M32D1NP - both logical channels */
[3] = {
.speed = LP4_SPEED_2400,
.ch0_rank_density = LP4_8Gb_DENSITY,
@@ -106,7 +112,7 @@ static const struct lpddr4_sku skus[] = {
.disable_periodic_retraining = 1,
},
/*
- * H9HCNNNBPUMLHR-NLE - both logical channels. While the parts
+ * H9HCNNNBPUMLHR - both logical channels. While the parts
* are listed at 16Gb there are 2 ranks per channel so indicate the
* density as 8Gb per rank.
*/
@@ -118,7 +124,7 @@ static const struct lpddr4_sku skus[] = {
.ch1_dual_rank = 1,
.part_num = "H9HCNNNBPUMLHR",
},
- /* H9HCNNN8KUMLHR-NLE - both logical channels */
+ /* H9HCNNN8KUMLHR - both logical channels */
[5] = {
.speed = LP4_SPEED_2400,
.ch0_rank_density = LP4_8Gb_DENSITY,
Furquan Shaikh (furquan(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17128
-gerrit
commit e230ba75e39fc4baee4a61c25fdd511fb7e37ed1
Author: Furquan Shaikh <furquan(a)chromium.org>
Date: Tue Oct 25 12:36:17 2016 -0700
Documentation: Add documentation for GPIO toggling in ACPI AML
This document provides information about the different functions that a
driver can use for generating ACPI code for toggling GPIO. These
functions are expected to be implemented by the SoC. It also defines the
different constraints on use of Local variables in ACPI code while
implementing these functions.
BUG=chrome-os-partner:55988
Change-Id: Ibc03d766afb6d7b75bc0dc9f79920b561f1c4a78
Signed-off-by: Furquan Shaikh <furquan(a)chromium.org>
---
Documentation/acpi/gpio.md | 162 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 162 insertions(+)
diff --git a/Documentation/acpi/gpio.md b/Documentation/acpi/gpio.md
new file mode 100644
index 0000000..2c09148
--- /dev/null
+++ b/Documentation/acpi/gpio.md
@@ -0,0 +1,162 @@
+# GPIO toggling in ACPI AML for coreboot #
+
+# Table of contents #
+- Introduction
+- Platform Interface
+- Implementation details
+- Arguments and Local Variables Management
+
+# Introduction #
+
+ACPI provides platform-independent interfaces enabling the operating
+system to perform power management for devices as well as the entire
+system. An operating system can simply call into Method()s implemented
+by the interface to request different power management operations. In
+order to be able to perform these operations, an interface might
+require toggling of GPIOs. e.g. a touchscreen device interface might
+require toggling of reset-gpio in order to take the device out of
+reset or to put it back into reset.
+
+Thus, any coreboot driver that implements such an ACPI interface might
+require the ability to toggle GPIOs. However, toggling of GPIO is not
+the same across different platforms and it will require the driver to
+depend upon platform to do the required work. This document presents a
+simple interface that can be used by any coreboot driver to generate
+ACPI AML code for reading or toggling platform GPIOs.
+
+# Platform Interface #
+
+All platforms that use drivers requiring ACPI AML code for GPIO
+interactions need to be implement the following functions:
+1. Return GPIO Rx value if it is acting as input
+ int acpigen_soc_read_rx_gpio(unsigned int gpio_num)
+2. Return GPIO Tx value if it is acting as output
+ int acpigen_soc_get_tx_gpio(unsigned int gpio_num)
+3. Set GPIO Tx value to 1 if it is acting as output
+ int acpigen_soc_set_tx_gpio(unsigned int gpio_num)
+4. Set GPIO Tx value to 0 if it is acting as output
+ int acpigen_soc_clear_tx_gpio(unsigned int gpio_num)
+
+Each of the above functions takes as input gpio_num which is the gpio
+number that needs to be read or toggled and returns an integer which
+is:
+1. Error = -1
+2. Success = 0
+
+Above callback functions are chosen to be implemented in C rather than
+adding them as AML code callbacks for the following reasons:
+1. It is easier to add error prints in C which will inform the
+ developer that these callbacks are missing. It restricts debugging
+ to coreboot logs.
+2. GPIO conversion from number to register offset can be easily done
+ in C by reusing implemented functions rather than adding all the
+ logic to AML code or depending upon complicated macros to be added
+ to device-tree.
+3. Allows GPIO AML methods to be present under any device scope and
+ gives SoC the flexibility to call them without any restrictions.
+
+# Implementation Details #
+
+ACPI library in coreboot will provide weak definitions for all the
+above functions with error messages indicating that these functions
+are being used. This allows drivers to conditionally make use of GPIOs
+based on device-tree entries or any other config option. It is
+recommended that the SoC code in coreboot should provide
+implementations of all the above functions generating ACPI AML code
+irrespective of them being used in any driver. This allows mainboards
+to use any drivers and take advantage of this common infrastructure.
+
+Platforms are restricted to using Local5, Local6 and Local7 variables
+only in implementations of the above functions. Any AML methods called
+by the above functions do not have any such restrictions on use of
+Local variables in AML code. Local0 is to be used for all get/read
+functions to return values. This means that the driver code should not
+make any assumptions about the values in Local5, Local6 and Local7
+variables.
+
+ **Function** **Operation** **Return**
+ acpigen_soc_read_rx_gpio Generate ACPI AML code to Error = -1
+ read value of Rx in Local0. Success = 0
+ acpigen_soc_get_tx_gpio Generate ACPI AML code to Error = -1
+ get value of Tx in Local0. Success = 0
+ acpigen_soc_set_tx_gpio Generate ACPI AML code to Error = -1
+ set Tx to 1. Success = 0
+ acpigen_soc_clear_tx_gpio Generate ACPI AML code to Error = -1
+ set Tx to 0. Success = 0
+
+
+Ideally, the operation column in the above table should use one or
+more functions implemented by the platform in AML code library (like
+gpiolib.asl). In the example below SPC0 and GPC0 need to be
+implemented by the SoC in AML code library and they can be used by
+acpi_soc_set_tx_gpio to read and set bit in the appropriate register
+for the GPIO.
+
+**acpigen_soc_set_tx_gpio**
+
+ uint64_t gpio_reg_offset = gpio_get_reg_offset(gpio_num);
+
+ /* Store (\_SB.GPC0(gpio_reg_offset, Local5) */
+ acpigen_write_store();
+ acpigen_emit_namestring(“\\_SB.GPC0”);
+ acpigen_write_integer(gpio_reg_offset);
+ acpigen_emit_byte(LOCAL5_OP);
+
+
+ /* Or (Local5, TX_BIT, Local5) */
+ acpigen_write_or(LOCAL5_OP, TX_BIT, LOCAL5_OP);
+
+ /* \_SB.SPC0(gpio_reg_offset, LOCAL5) */
+ acpigen_emit_namestring(“\\_SB.SPC0”);
+ acpigen_write_integer(gpio_reg_offset);
+ acpigen_emit_byte(LOCAL5_OP);
+
+ return 0;
+
+**acpigen_soc_get_tx_gpio**
+
+ uint64_t gpio_reg_offset = gpio_get_reg_offset(gpio_num);
+
+
+ /* Store (\_SB.GPC0(gpio_reg_offset, Local5) */
+ acpigen_write_store();
+ acpigen_emit_namestring(“\\_SB.GPC0”);
+ acpigen_write_integer(gpio_reg_offset);
+ acpigen_emit_byte(LOCAL5_OP);
+
+
+ /*
+ * If (And (Local5, TX_BIT)) Store (One, Local0) Else Store (Zero,
+ * Local0)
+ */
+ acpigen_write_if_and(Local5, TX_BIT);
+ acpigen_write_store_args(ONE_OP, LOCAL0_OP);
+ acpigen_pop_len();
+ acpigen_write_else();
+ acpigen_write_store_args(ZERO_OP, LOCAL0_OP);
+ acpigen_pop_len();
+
+ return 0;
+
+
+These are reference implementations and the platforms are free to
+implement these functions in any way they like. Coreboot driver can
+then simply call into these functions to generate ACPI AML code to
+get/set/clear any GPIO. In order to decide whether GPIO operations are
+required, driver code can rely either on some config option or read
+device-tree to use any user-provided GPIOs.
+
+# Arguments and Local Variables Management #
+
+Platform-defined functions can call methods using the same calling
+conventions provided by AML code. However, use of Local Variables is
+restricted to Local5, Local6 and Local7 unless they call into some
+other method. Called method can use any Local variables, Local0 -
+Local7. In case of functions expected to return back value to the
+caller, this value is expected to be returned in Local0.
+
+Driver code should not make any assumptions about the contents of
+Local5, Local6 and Local7 across callbacks to SoC code. If it makes a
+read or get call to SoC, the return value should be used from Local0
+on return. However, if it makes a set or clear call to SoC, the value
+in Local0 is undefined.
Furquan Shaikh (furquan(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/17128
-gerrit
commit 1f7a705e5b72ff43ac082201e770293ca5e79428
Author: Furquan Shaikh <furquan(a)chromium.org>
Date: Tue Oct 25 12:36:17 2016 -0700
Documentation: Add documentation for GPIO toggling in ACPI AML
This document provides information about the different functions that a
driver can use for generating ACPI code for toggling GPIO. These
functions are expected to be implemented by SoC. It also defines the
different constaints on use of Local variables in ACPI code while
implementing these functions.
BUG=chrome-os-partner:55988
Change-Id: Ibc03d766afb6d7b75bc0dc9f79920b561f1c4a78
Signed-off-by: Furquan Shaikh <furquan(a)chromium.org>
---
Documentation/acpi/gpio.md | 162 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 162 insertions(+)
diff --git a/Documentation/acpi/gpio.md b/Documentation/acpi/gpio.md
new file mode 100644
index 0000000..2c09148
--- /dev/null
+++ b/Documentation/acpi/gpio.md
@@ -0,0 +1,162 @@
+# GPIO toggling in ACPI AML for coreboot #
+
+# Table of contents #
+- Introduction
+- Platform Interface
+- Implementation details
+- Arguments and Local Variables Management
+
+# Introduction #
+
+ACPI provides platform-independent interfaces enabling the operating
+system to perform power management for devices as well as the entire
+system. An operating system can simply call into Method()s implemented
+by the interface to request different power management operations. In
+order to be able to perform these operations, an interface might
+require toggling of GPIOs. e.g. a touchscreen device interface might
+require toggling of reset-gpio in order to take the device out of
+reset or to put it back into reset.
+
+Thus, any coreboot driver that implements such an ACPI interface might
+require the ability to toggle GPIOs. However, toggling of GPIO is not
+the same across different platforms and it will require the driver to
+depend upon platform to do the required work. This document presents a
+simple interface that can be used by any coreboot driver to generate
+ACPI AML code for reading or toggling platform GPIOs.
+
+# Platform Interface #
+
+All platforms that use drivers requiring ACPI AML code for GPIO
+interactions need to be implement the following functions:
+1. Return GPIO Rx value if it is acting as input
+ int acpigen_soc_read_rx_gpio(unsigned int gpio_num)
+2. Return GPIO Tx value if it is acting as output
+ int acpigen_soc_get_tx_gpio(unsigned int gpio_num)
+3. Set GPIO Tx value to 1 if it is acting as output
+ int acpigen_soc_set_tx_gpio(unsigned int gpio_num)
+4. Set GPIO Tx value to 0 if it is acting as output
+ int acpigen_soc_clear_tx_gpio(unsigned int gpio_num)
+
+Each of the above functions takes as input gpio_num which is the gpio
+number that needs to be read or toggled and returns an integer which
+is:
+1. Error = -1
+2. Success = 0
+
+Above callback functions are chosen to be implemented in C rather than
+adding them as AML code callbacks for the following reasons:
+1. It is easier to add error prints in C which will inform the
+ developer that these callbacks are missing. It restricts debugging
+ to coreboot logs.
+2. GPIO conversion from number to register offset can be easily done
+ in C by reusing implemented functions rather than adding all the
+ logic to AML code or depending upon complicated macros to be added
+ to device-tree.
+3. Allows GPIO AML methods to be present under any device scope and
+ gives SoC the flexibility to call them without any restrictions.
+
+# Implementation Details #
+
+ACPI library in coreboot will provide weak definitions for all the
+above functions with error messages indicating that these functions
+are being used. This allows drivers to conditionally make use of GPIOs
+based on device-tree entries or any other config option. It is
+recommended that the SoC code in coreboot should provide
+implementations of all the above functions generating ACPI AML code
+irrespective of them being used in any driver. This allows mainboards
+to use any drivers and take advantage of this common infrastructure.
+
+Platforms are restricted to using Local5, Local6 and Local7 variables
+only in implementations of the above functions. Any AML methods called
+by the above functions do not have any such restrictions on use of
+Local variables in AML code. Local0 is to be used for all get/read
+functions to return values. This means that the driver code should not
+make any assumptions about the values in Local5, Local6 and Local7
+variables.
+
+ **Function** **Operation** **Return**
+ acpigen_soc_read_rx_gpio Generate ACPI AML code to Error = -1
+ read value of Rx in Local0. Success = 0
+ acpigen_soc_get_tx_gpio Generate ACPI AML code to Error = -1
+ get value of Tx in Local0. Success = 0
+ acpigen_soc_set_tx_gpio Generate ACPI AML code to Error = -1
+ set Tx to 1. Success = 0
+ acpigen_soc_clear_tx_gpio Generate ACPI AML code to Error = -1
+ set Tx to 0. Success = 0
+
+
+Ideally, the operation column in the above table should use one or
+more functions implemented by the platform in AML code library (like
+gpiolib.asl). In the example below SPC0 and GPC0 need to be
+implemented by the SoC in AML code library and they can be used by
+acpi_soc_set_tx_gpio to read and set bit in the appropriate register
+for the GPIO.
+
+**acpigen_soc_set_tx_gpio**
+
+ uint64_t gpio_reg_offset = gpio_get_reg_offset(gpio_num);
+
+ /* Store (\_SB.GPC0(gpio_reg_offset, Local5) */
+ acpigen_write_store();
+ acpigen_emit_namestring(“\\_SB.GPC0”);
+ acpigen_write_integer(gpio_reg_offset);
+ acpigen_emit_byte(LOCAL5_OP);
+
+
+ /* Or (Local5, TX_BIT, Local5) */
+ acpigen_write_or(LOCAL5_OP, TX_BIT, LOCAL5_OP);
+
+ /* \_SB.SPC0(gpio_reg_offset, LOCAL5) */
+ acpigen_emit_namestring(“\\_SB.SPC0”);
+ acpigen_write_integer(gpio_reg_offset);
+ acpigen_emit_byte(LOCAL5_OP);
+
+ return 0;
+
+**acpigen_soc_get_tx_gpio**
+
+ uint64_t gpio_reg_offset = gpio_get_reg_offset(gpio_num);
+
+
+ /* Store (\_SB.GPC0(gpio_reg_offset, Local5) */
+ acpigen_write_store();
+ acpigen_emit_namestring(“\\_SB.GPC0”);
+ acpigen_write_integer(gpio_reg_offset);
+ acpigen_emit_byte(LOCAL5_OP);
+
+
+ /*
+ * If (And (Local5, TX_BIT)) Store (One, Local0) Else Store (Zero,
+ * Local0)
+ */
+ acpigen_write_if_and(Local5, TX_BIT);
+ acpigen_write_store_args(ONE_OP, LOCAL0_OP);
+ acpigen_pop_len();
+ acpigen_write_else();
+ acpigen_write_store_args(ZERO_OP, LOCAL0_OP);
+ acpigen_pop_len();
+
+ return 0;
+
+
+These are reference implementations and the platforms are free to
+implement these functions in any way they like. Coreboot driver can
+then simply call into these functions to generate ACPI AML code to
+get/set/clear any GPIO. In order to decide whether GPIO operations are
+required, driver code can rely either on some config option or read
+device-tree to use any user-provided GPIOs.
+
+# Arguments and Local Variables Management #
+
+Platform-defined functions can call methods using the same calling
+conventions provided by AML code. However, use of Local Variables is
+restricted to Local5, Local6 and Local7 unless they call into some
+other method. Called method can use any Local variables, Local0 -
+Local7. In case of functions expected to return back value to the
+caller, this value is expected to be returned in Local0.
+
+Driver code should not make any assumptions about the contents of
+Local5, Local6 and Local7 across callbacks to SoC code. If it makes a
+read or get call to SoC, the return value should be used from Local0
+on return. However, if it makes a set or clear call to SoC, the value
+in Local0 is undefined.
the following patch was just integrated into master:
commit 64e341ec1654645b77c9ec158b01fb992a44b882
Author: Arthur Heymans <arthur(a)aheymans.xyz>
Date: Mon Oct 24 00:57:54 2016 +0200
mb/ga-g41m-es2l: remove unneeded IGD IRQ setting in ACPI
According to: "Intel ® 4 Series Chipset Family datasheet"
the IGD only has 1 IRQ pin.
Change-Id: I974f002f5a213056f4593a1eab10772527bb241d
Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17098
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h(a)gmx.de>
See https://review.coreboot.org/17098 for details.
-gerrit
the following patch was just integrated into master:
commit c057a0611b9f5bb66ad3bd54890991eec7838192
Author: Arthur Heymans <arthur(a)aheymans.xyz>
Date: Sat Oct 22 14:16:48 2016 +0200
nb/i945/gma.c: Set the MSAC register correctly
This fixes an instability on 945gc where the IGD completely locks
up the system, when for instance tasked to do something with
compositing (like GNOME or GDM).
TESTED on ga-945gcm-s2l and d945gclf
TEST: launch GDM (gnome display manager)
Change-Id: Iec49bccf3e3164df9dc1e0b54460a616fe92e04d
Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17094
Reviewed-by: Nico Huber <nico.h(a)gmx.de>
Tested-by: build bot (Jenkins)
See https://review.coreboot.org/17094 for details.
-gerrit
the following patch was just integrated into master:
commit ab5d6902fdef7c7f26145619030a42aeda24b1ab
Author: Naresh G Solanki <naresh.solanki(a)intel.com>
Date: Sat Oct 15 18:13:55 2016 +0530
mainboard/intel/kblrvp: Initial commit for Intel Kaby Lake RVP3
Add support for Kaby Lake RVP3.
Use kunimitsu at commit 028200f as base.
Kabylake RVP3 is based on Kabylake-Y with onboard Dual Channel
LPDDR3 DIMM.
* Update board name to kblrvp
* Remove fsp 1.1 specific code( As Kabylake uses fsp2.0)
* Remove board id function.
* Remove unused spd & add rvp3 spd file.
This is an initial commit does not have full support to boot.
Will add more CLs to boot Chrome OS with depthcharge.
Change-Id: Id8e32c5b93fc32ba84278c5c5da8f8e30c201bea
Signed-off-by: Naresh G Solanki <naresh.solanki(a)intel.com>
Reviewed-on: https://review.coreboot.org/17032
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth(a)google.com>
See https://review.coreboot.org/17032 for details.
-gerrit
the following patch was just integrated into master:
commit 9369e10f1f4e9497a09eb7848d18d78b89593147
Author: Martin Roth <martinroth(a)google.com>
Date: Mon Oct 17 10:11:10 2016 -0600
payloads/external/Makefile.inc: Clean up makefile
- Add comments dividing the payload sections.
- Move separate TINT and Memtest sections that were intermingled.
Change-Id: If0bbd6e182359c5186a8b958dd2c9ab9f0e0a3f3
Signed-off-by: Martin Roth <martinroth(a)google.com>
Reviewed-on: https://review.coreboot.org/17046
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h(a)gmx.de>
See https://review.coreboot.org/17046 for details.
-gerrit