coreboot-gerrit October 2016

coreboot-gerrit@coreboot.org

1 participants
1281 discussions

Patch set updated for coreboot: Gale: Fix the orange color to match the UX doc
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16767 -gerrit commit c39751aa06c2a29a796913b84f1cd2aebc1d9a44 Author: Suresh Rajashekara <sureshraj(a)google.com> Date: Thu Sep 22 08:20:16 2016 -0700 Gale: Fix the orange color to match the UX doc UX Doc = go/gale-hw-ui This color wasn't changed earlier as the change wasn't done in the OS also. However, since we cannot change this later in FW (but OS can change anytime), I am making this change after discussing with the UX team. BUG=b:31501528, b:31633562 TEST=Change the device state to 'recovery mode' to observe the new color. BRANCH=none Change-Id: Ia91f14eb77492095cb41a9de0bb9790e72aa4851 Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: 36a3d8c6eabbc0b23d0a15d5bddc5ed3bdeebe70 Original-Change-Id: I88768b94cf91804a6005e44b1a168e059698ec4b Original-Signed-off-by: Suresh Rajashekara <sureshraj(a)google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/388206 Original-Commit-Ready: Suresh Rajashekara <sureshraj(a)chromium.org> Original-Tested-by: Suresh Rajashekara <sureshraj(a)chromium.org> Original-Reviewed-by: Christopher Book <cbook(a)chromium.org> Original-Reviewed-by: Kan Yan <kyan(a)google.com> --- src/drivers/i2c/ww_ring/ww_ring_programs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/drivers/i2c/ww_ring/ww_ring_programs.c b/src/drivers/i2c/ww_ring/ww_ring_programs.c index fb74a1b..0c70e10 100644 --- a/src/drivers/i2c/ww_ring/ww_ring_programs.c +++ b/src/drivers/i2c/ww_ring/ww_ring_programs.c @@ -170,8 +170,8 @@ static const TiLp55231Program blink_wipeout1_program = { static const uint8_t blink_recovery1_text[] = { 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x90, 0x02, 0x94, 0x02, 0x9f, 0x80, 0x98, 255, 0x84, 0x62, - 0x9f, 0x81, 0x98, 50, 0x84, 0x62, 0x9f, 0x82, - 0x98, 0, 0x84, 0x62, 0x4c, 0x00, 0x86, 0x2c, + 0x9f, 0x81, 0x98, 100, 0x84, 0x62, 0x9f, 0x82, + 0x98, 10, 0x84, 0x62, 0x4c, 0x00, 0x86, 0x2c, 0x40, 0x00, 0x9f, 0x81, 0x40, 0x00, 0x9f, 0x80, 0x40, 0x00, 0x4c, 0x00, 0x86, 0x49, 0xa0, 0x03, 0xc0, 0x00, 0xc0, 0x00, 0x00,

1 0

Patch set updated for coreboot: i2c/ww_ring: LED changes for Gale EVT3
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16697 -gerrit commit 4c833c891ad02bfac8d6c2111a94befffd339014 Author: Suresh Rajashekara <sureshraj(a)google.com> Date: Mon Aug 15 16:18:11 2016 -0700 i2c/ww_ring: LED changes for Gale EVT3 Gale EVT3 has only one LED controller (earlier we had 2). Removing the support for the second controller and also the corresponding microcode. The color values used are the same as onHub (Arkham to be specific). BUG=b:30890905 TEST=Move the device to different states manually by appropriate actions (like dev mode, rec mode etc) and observe the differnet colors. BRANCH=None Change-Id: I853035610ea7ea7c8d29c30d2de13c9e2e786b2b Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: 593905d2d69daa7482318aa5f5c5cd7cf984043e Original-Change-Id: If8f22abd605faac6f6215ef600041740ce15ea0c Original-Signed-off-by: Suresh Rajashekara <sureshraj(a)google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/370821 Original-Commit-Ready: Suresh Rajashekara <sureshraj(a)chromium.org> Original-Tested-by: Suresh Rajashekara <sureshraj(a)chromium.org> Original-Reviewed-by: Kan Yan <kyan(a)google.com> --- src/drivers/i2c/ww_ring/ww_ring_programs.c | 232 ++++++----------------------- src/drivers/i2c/ww_ring/ww_ring_programs.h | 2 +- 2 files changed, 49 insertions(+), 185 deletions(-) diff --git a/src/drivers/i2c/ww_ring/ww_ring_programs.c b/src/drivers/i2c/ww_ring/ww_ring_programs.c index a35998c..5b0c8a8 100644 --- a/src/drivers/i2c/ww_ring/ww_ring_programs.c +++ b/src/drivers/i2c/ww_ring/ww_ring_programs.c @@ -46,36 +46,36 @@ * Solid LED display, the arguments of the set_pwm commands set intensity and * color of the display: -row_red: dw 0000000001001001b -row_green: dw 0000000010010010b -row_blue: dw 0000000100100100b +row_red: dw 0000000000000001b +row_green: dw 0000000000000010b +row_blue: dw 0000000000000100b .segment program1 mux_map_addr row_red - set_pwm 1 + set_pwm 0 end .segment program2 mux_map_addr row_green - set_pwm 1 + set_pwm 0 end .segment program3 mux_map_addr row_blue - set_pwm 1 + set_pwm 0 end */ /* RGB set to 000000, resulting in all LEDs off. */ static const uint8_t solid_000000_text[] = { - 0x00, 0x49, 0x00, 0x92, 0x01, 0x24, 0x9F, 0x80, + 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x9F, 0x80, 0x40, 0, 0xC0, 0x00, 0x9F, 0x81, 0x40, 0, 0xC0, 0x00, 0x9F, 0x82, 0x40, 0, 0xC0, 0x00 }; /* Rgb set to 128, resulting in a brightish white color. */ static const uint8_t solid_808080_text[] = { - 0x00, 0x49, 0x00, 0x92, 0x01, 0x24, 0x9F, 0x80, + 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x9F, 0x80, 0x40, 128, 0xC0, 0x00, 0x9F, 0x81, 0x40, 128, 0xC0, 0x00, 0x9F, 0x82, 0x40, 128, 0xC0, 0x00 }; @@ -100,20 +100,10 @@ static const TiLp55231Program solid_000000_program = { * The three internal engines seem to be competing for resources and get out * of sync in seconds if left running asynchronously. * - * When there are two separate controllers, with three engine each, they all - * run away from each other in no time, resulting in some completely chaotic - * LED behavior. - * * When solid patterns are deployed with instanteneous color intensity * changes, all three LEDs can be controlled by one engine in sequential * accesses. But the controllers still neeed to be synchronized. * - * The first controller is loaded and started first, but it sits waiting for - * the trigger from the second controller to actually start the cycle. Once - * both controllers start running, the first controller is the master, sending - * sych triggers to the second one each time the LED is supposed to be turned - * on or off. - * * The maximum timer duration of lp55231 is .48 seconds. To achieve longer * blinking intervals the loops delays are deployed. Only the first controller * intervals need to be changed, as the second one is in lockstep with the @@ -126,29 +116,26 @@ static const TiLp55231Program solid_000000_program = { */ /* * blink_solid1.src -row_red: dw 0000000001001001b -row_green: dw 0000000010010010b -row_blue: dw 0000000100100100b +row_red: dw 0000000000000001b +row_green: dw 0000000000000010b +row_blue: dw 0000000000000100b .segment program1 ld ra, 2 # LED on duration - ld rb, 10 # LED off duration + ld rb, 2 # LED off duration mux_map_addr row_red - trigger w{e} loop: - trigger s{e} - ld rc, 98 ; red intensity + ld rc, 180 ; red intensity set_pwm rc mux_map_addr row_green - ld rc, 0 ; green intensity + ld rc, 80 ; green intensity set_pwm rc mux_map_addr row_blue - ld rc, 234 ; blue intensity + ld rc, 0 ; blue intensity set_pwm rc wait1: wait 0.1 branch ra, wait1 - trigger s{e} set_pwm 0 mux_map_addr row_green set_pwm 0 @@ -158,203 +145,82 @@ wait2: wait 0.1 branch rb, wait2 branch 0, loop - -.segment program2 - end - -.segment program3 - end*/ -/* - * blink_solid2.src - -row_red: dw 0000000001001001b -row_green: dw 0000000010010010b -row_blue: dw 0000000100100100b - -.segment program1 - ld ra, 98 - ld rb, 0 - ld rc, 234 - trigger s{e} - mux_map_addr row_red -loop: - trigger w{e} - set_pwm ra ; red intensity - mux_map_addr row_green - set_pwm rb ; green intensity - mux_map_addr row_blue - set_pwm rc ; blue intensity -wait1: - wait 0.1 - branch 1, wait1 - trigger w{e} - set_pwm 0 - mux_map_addr row_green - set_pwm 0 - mux_map_addr row_red - set_pwm 0 -wait2: - wait 0.1 - branch 1, wait2 - branch 0, loop - .segment program2 end - .segment program3 end */ static const uint8_t blink_wipeout1_text[] = { - 0x00, 0x49, 0x00, 0x92, 0x01, 0x24, 0x90, 0x02, - 0x94, 0x02, 0x9f, 0x80, 0xf0, 0x00, 0xe0, 0x40, - 0x98, 255, 0x84, 0x62, 0x9f, 0x81, 0x98, 80, - 0x84, 0x62, 0x9f, 0x82, 0x98, 0, 0x84, 0x62, - 0x4c, 0x00, 0x86, 0x34, 0xe0, 0x40, 0x40, 0x00, - 0x9f, 0x81, 0x40, 0x00, 0x9f, 0x80, 0x40, 0x00, - 0x4c, 0x00, 0x86, 0x55, 0xa0, 0x04, 0xc0, 0x00, - 0xc0, 0x00, 0x00, -}; - -static const uint8_t blink_wipeout2_text[] = { - 0x00, 0x49, 0x00, 0x92, 0x01, 0x24, 0x90, 255, - 0x94, 80, 0x98, 0, 0xe0, 0x40, 0x9f, 0x80, - 0xf0, 0x00, 0x84, 0x60, 0x9f, 0x81, 0x84, 0x61, - 0x9f, 0x82, 0x84, 0x62, 0x4c, 0x00, 0xa0, 0x8b, - 0xf0, 0x00, 0x40, 0x00, 0x9f, 0x81, 0x40, 0x00, - 0x9f, 0x80, 0x40, 0x00, 0x4c, 0x00, 0xa0, 0x93, - 0xa0, 0x05, 0xc0, 0x00, 0xc0, 0x00, 0x00, + 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x90, 0x02, + 0x94, 0x02, 0x9f, 0x80, 0x98, 180, 0x84, 0x62, + 0x9f, 0x81, 0x98, 80, 0x84, 0x62, 0x9f, 0x82, + 0x98, 0, 0x84, 0x62, 0x4c, 0x00, 0x86, 0x2c, + 0x40, 0x00, 0x9f, 0x81, 0x40, 0x00, 0x9f, 0x80, + 0x40, 0x00, 0x4c, 0x00, 0x86, 0x49, 0xa0, 0x03, + 0xc0, 0x00, 0xc0, 0x00, 0x00, }; static const TiLp55231Program blink_wipeout1_program = { blink_wipeout1_text, sizeof(blink_wipeout1_text), 0, - { 3, 27, 28, } -}; -static const TiLp55231Program blink_wipeout2_program = { - blink_wipeout2_text, - sizeof(blink_wipeout2_text), - 0, - { 3, 26, 26, } + { 3, 24, 25, } }; static const uint8_t blink_recovery1_text[] = { - 0x00, 0x49, 0x00, 0x92, 0x01, 0x24, 0x90, 0x02, - 0x94, 0x02, 0x9f, 0x80, 0xf0, 0x00, 0xe0, 0x40, - 0x98, 255, 0x84, 0x62, 0x9f, 0x81, 0x98, 24, - 0x84, 0x62, 0x9f, 0x82, 0x98, 0, 0x84, 0x62, - 0x4c, 0x00, 0x86, 0x34, 0xe0, 0x40, 0x40, 0x00, - 0x9f, 0x81, 0x40, 0x00, 0x9f, 0x80, 0x40, 0x00, - 0x4c, 0x00, 0x86, 0x55, 0xa0, 0x04, 0xc0, 0x00, - 0xc0, 0x00, 0x00, + 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x90, 0x02, + 0x94, 0x02, 0x9f, 0x80, 0x98, 255, 0x84, 0x62, + 0x9f, 0x81, 0x98, 50, 0x84, 0x62, 0x9f, 0x82, + 0x98, 0, 0x84, 0x62, 0x4c, 0x00, 0x86, 0x2c, + 0x40, 0x00, 0x9f, 0x81, 0x40, 0x00, 0x9f, 0x80, + 0x40, 0x00, 0x4c, 0x00, 0x86, 0x49, 0xa0, 0x03, + 0xc0, 0x00, 0xc0, 0x00, 0x00, }; static const TiLp55231Program blink_recovery1_program = { blink_recovery1_text, sizeof(blink_recovery1_text), 0, - { 3, 27, 28, } -}; -static const uint8_t blink_recovery2_text[] = { - 0x00, 0x49, 0x00, 0x92, 0x01, 0x24, 0x90, 255, - 0x94, 24, 0x98, 0, 0xe0, 0x40, 0x9f, 0x80, - 0xf0, 0x00, 0x84, 0x60, 0x9f, 0x81, 0x84, 0x61, - 0x9f, 0x82, 0x84, 0x62, 0x4c, 0x00, 0xa0, 0x8b, - 0xf0, 0x00, 0x40, 0x00, 0x9f, 0x81, 0x40, 0x00, - 0x9f, 0x80, 0x40, 0x00, 0x4c, 0x00, 0xa0, 0x93, - 0xa0, 0x05, 0xc0, 0x00, 0xc0, 0x00, 0x00, -}; -static const TiLp55231Program blink_recovery2_program = { - blink_recovery2_text, - sizeof(blink_recovery2_text), - 0, - { 3, 26, 26, } + { 3, 24, 25, } }; /* * fade_in1.src * - row_red: dw 0000000001001001b - row_green: dw 0000000010010010b - row_blue: dw 0000000100100100b + row_red: dw 0000000000000001b + row_green: dw 0000000000000010b + row_blue: dw 0000000000000100b .segment program1 mux_map_addr row_red - set_pwm 0h - trigger w{e} + set_pwm 1h trigger s{2|3} end - .segment program2 mux_map_addr row_green set_pwm 0h - trigger w{1} - ramp 2, 87 + ramp 2, 50 end - .segment program3 mux_map_addr row_blue set_pwm 0h loop3: trigger w{1} - ramp 2, 155 - end -*/ -/* - * fade_in2.src - * - row_red: dw 0000000001001001b - row_green: dw 0000000010010010b - row_blue: dw 0000000100100100b - - .segment program1 - mux_map_addr row_red - set_pwm 0h - trigger s{e} - trigger s{2|3} - end - - .segment program2 - mux_map_addr row_green - set_pwm 0h - - trigger w{1} - ramp 2, 87 - end - -.segment program3 - mux_map_addr row_blue - set_pwm 0h - loop3: trigger w{1} - ramp 2, 155 + ramp 2, 255 end */ static const uint8_t fade_in1_text[] = { - 0x00, 0x49, 0x00, 0x92, 0x01, 0x24, 0x9f, 0x80, - 0x40, 0x00, 0xf0, 0x00, 0xe0, 0x0c, 0xc0, 0x00, - 0x9f, 0x81, 0x40, 0x00, 0xe0, 0x80, 0x42, 0x57, - 0xc0, 0x00, 0x9f, 0x82, 0x40, 0x00, 0xe0, 0x80, - 0x34, 0x9b, 0xc0, 0x00, 0x00, + 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x9f, 0x80, + 0x40, 0x01, 0xe0, 0x0c, 0xc0, 0x00, 0x9f, 0x81, + 0x40, 0x00, 0xe0, 0x80, 0x46, 0x32, 0xc0, 0x00, + 0x9f, 0x82, 0x40, 0x00, 0xe0, 0x80, 0x20, 0xff, + 0xc0, 0x00, 0x00, }; static const TiLp55231Program fade_in1_program = { fade_in1_text, sizeof(fade_in1_text), 0, - { 3, 8, 13, } -}; - -static const uint8_t fade_in2_text[] = { - 0x00, 0x49, 0x00, 0x92, 0x01, 0x24, 0x9f, 0x80, - 0x40, 0x00, 0xe0, 0x40, 0xe0, 0x0c, 0xc0, 0x00, - 0x9f, 0x81, 0x40, 0x00, 0xe0, 0x80, 0x42, 0x57, - 0xc0, 0x00, 0x9f, 0x82, 0x40, 0x00, 0xe0, 0x80, - 0x34, 0x9b, 0xc0, 0x00, 0x00, -}; -static const TiLp55231Program fade_in2_program = { - fade_in2_text, - sizeof(fade_in2_text), - 0, - { 3, 8, 13, } + { 3, 7, 12, } }; const WwRingStateProg wwr_state_programs[] = { @@ -362,12 +228,10 @@ const WwRingStateProg wwr_state_programs[] = { * for test purposes the blank screen program is set to blinking, will * be changed soon. */ - {WWR_ALL_OFF, {&solid_000000_program, &solid_000000_program} }, - {WWR_RECOVERY_PUSHED, {&solid_808080_program, &solid_808080_program} }, - {WWR_WIPEOUT_REQUEST, {&blink_wipeout1_program, - &blink_wipeout2_program} }, - {WWR_RECOVERY_REQUEST, {&blink_recovery1_program, - &blink_recovery2_program} }, - {WWR_NORMAL_BOOT, {&fade_in1_program, &fade_in2_program} }, + {WWR_ALL_OFF, {&solid_000000_program} }, + {WWR_RECOVERY_PUSHED, {&solid_808080_program} }, + {WWR_WIPEOUT_REQUEST, {&blink_wipeout1_program} }, + {WWR_RECOVERY_REQUEST, {&blink_recovery1_program} }, + {WWR_NORMAL_BOOT, {&fade_in1_program} }, {}, /* Empty record to mark the end of the table. */ }; diff --git a/src/drivers/i2c/ww_ring/ww_ring_programs.h b/src/drivers/i2c/ww_ring/ww_ring_programs.h index 9f4b928..5fb8ebf 100644 --- a/src/drivers/i2c/ww_ring/ww_ring_programs.h +++ b/src/drivers/i2c/ww_ring/ww_ring_programs.h @@ -36,7 +36,7 @@ #define LP55231_NUM_OF_ENGINES 3 /* Number of lp55321 controllers on the ring */ -#define WW_RING_NUM_LED_CONTROLLERS 2 +#define WW_RING_NUM_LED_CONTROLLERS 1 /* * Structure to describe an lp55231 program: pointer to the text of the

1 0

Patch set updated for coreboot: google/gru: drive WLAN_MODULE_RST# low as early as possible
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16882 -gerrit commit e3e5a5e1719aa02076bbca01805b1b91478b6b74 Author: Brian Norris <briannorris(a)chromium.org> Date: Wed Sep 21 18:16:54 2016 -0700 google/gru: drive WLAN_MODULE_RST# low as early as possible GPIO1_B3 (WLAN_MODULE_RST#) defaults as a pull-up input, but it is also "pulled up" by 1.8V_WLAN. However, 1.8V_WLAN remains low for some time during early boot. This leaves the signal floating somewhere in the middle. This has two potential issues: (1) we're leaking some power for some (hopefully) short period of time (2) we are possibly screwing with the Wifi power sequence; we aren't supposed to deassert PDn (i.e., MODULE_RST#) until all the rails have fully ramped for some period of time Neither of the above issues are likely to be significant, but it is nice to fix, I expect. BRANCH=gru BUG=chrome-os-partner:54026 TEST=measure WLAN_MODULE_RST# on scope at boot time Change-Id: Ia6af9ad6954ad8feeda33015e3f205842380939e Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: 0e890a2787bf034d3358a33fc88c2dd8078593ab Original-Change-Id: I120e26ad0ca486a326874986e142dcaee965b62d Original-Signed-off-by: Brian Norris <briannorris(a)chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/388009 Original-Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Original-Reviewed-by: Julius Werner <jwerner(a)chromium.org> --- src/mainboard/google/gru/mainboard.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/mainboard/google/gru/mainboard.c b/src/mainboard/google/gru/mainboard.c index 8b9f595..ae2c339 100644 --- a/src/mainboard/google/gru/mainboard.c +++ b/src/mainboard/google/gru/mainboard.c @@ -29,6 +29,16 @@ #include "board.h" +/* + * Wifi's PDN/RST line is pulled down by its (unpowered) voltage rails, but + * this reset pin is pulled up by default. Let's drive it low as early as we + * can. + */ +static void deassert_wifi_power(void) +{ + gpio_output(GPIO(1, B, 3), 0); /* Assert WLAN_MODULE_RST# */ +} + static void configure_emmc(void) { /* Host controller does not support programmable clock generator. @@ -236,6 +246,7 @@ static void setup_usb(void) static void mainboard_init(device_t dev) { + deassert_wifi_power(); configure_sdmmc(); configure_emmc(); configure_codec();

1 0

Patch set updated for coreboot: Revert "soc/intel/apollolake: Add pmc_ipc device support"
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16881 -gerrit commit a545d910afa121beafb9a12ee6cad546792f70f5 Author: Furquan Shaikh <furquan(a)chromium.org> Date: Thu Sep 29 19:37:49 2016 -0700 Revert "soc/intel/apollolake: Add pmc_ipc device support" This reverts commit 28821dbb2261267462a7e9b0cc1c23b51af2d3ee. (https://review.coreboot.org/16649) This change causes the kernel to boot really slow. Maybe there is an interrupt storm that prevents the kernel from making any progress. Reverting until the proper kernel dependency is met. BUG=chrome-os-partner:57364 BRANCH=None TEST=Kernels boots to prompt fine on DVT. Change-Id: I1c9913b4476a08303f9dd887b8631601c847dcf7 Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: d7014ee1bb88df7a2d7f6b3dced797fef75b252d Original-Change-Id: I061c0b03b43b516a190b370c04888e73a410fcf1 Original-Signed-off-by: Furquan Shaikh <furquan(a)chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/391233 Original-Reviewed-by: Duncan Laurie <dlaurie(a)google.com> --- src/soc/intel/apollolake/acpi/pmc_ipc.asl | 57 --------------------------- src/soc/intel/apollolake/acpi/southbridge.asl | 3 -- 2 files changed, 60 deletions(-) diff --git a/src/soc/intel/apollolake/acpi/pmc_ipc.asl b/src/soc/intel/apollolake/acpi/pmc_ipc.asl deleted file mode 100644 index b89bebf..0000000 --- a/src/soc/intel/apollolake/acpi/pmc_ipc.asl +++ /dev/null @@ -1,57 +0,0 @@ -/* - * This file is part of the coreboot project. - * - * Copyright (C) 2016 Intel Corp. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; version 2 of - * the License. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ - -#include <soc/iomap.h> - -#define MAILBOX_DATA 0x7080 -#define MAILBOX_INTF 0x7084 -#define PMIO_LENGTH 0x80 - -Device (IPC1) -{ - Name (_HID, "INT34D2") - Name (_CID, "INT34D2") - Name (_DDN, "Intel(R) IPC1 Controller") - Name (RBUF, ResourceTemplate () - { - Memory32Fixed (ReadWrite, 0x0, 0x2000, IBAR) - Memory32Fixed (ReadWrite, 0x0, 0x4, MDAT) - Memory32Fixed (ReadWrite, 0x0, 0x4, MINF) - IO (Decode16, ACPI_PMIO_BASE, ACPI_PMIO_BASE + PMIO_LENGTH, - 0x04, PMIO_LENGTH) - Memory32Fixed (ReadWrite, 0x0, 0x2000, SBAR) - Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , , ) - { - PMC_INT - } - }) - - Method (_CRS, 0x0, NotSerialized) - { - CreateDwordField (^RBUF, ^IBAR._BAS, IBAS) - Store (PMC_BAR0, IBAS) - - CreateDwordField (^RBUF, ^MDAT._BAS, MDBA) - Store (MCH_BASE_ADDR + MAILBOX_DATA, MDBA) - CreateDwordField (^RBUF, ^MINF._BAS, MIBA) - Store (MCH_BASE_ADDR + MAILBOX_INTF, MIBA) - - CreateDwordField (^RBUF, ^SBAR._BAS, SBAS) - Store (PMC_SRAM_BASE_0, SBAS) - - Return (^RBUF) - } -} diff --git a/src/soc/intel/apollolake/acpi/southbridge.asl b/src/soc/intel/apollolake/acpi/southbridge.asl index f2b09c7..1c10f1a 100644 --- a/src/soc/intel/apollolake/acpi/southbridge.asl +++ b/src/soc/intel/apollolake/acpi/southbridge.asl @@ -40,9 +40,6 @@ Scope (\_SB) #include "xhci.asl" -/* PMC IPC */ -#include "pmc_ipc.asl" - /* LPC */ #include "lpc.asl"

1 0

Patch set updated for coreboot: spi: Add a way to show SPI transfer speed for reads
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16701 -gerrit commit bef71b6fc97936211505b6264c7bb4874ec565c3 Author: Simon Glass <sjg(a)chromium.org> Date: Sat Aug 27 15:03:02 2016 -0600 spi: Add a way to show SPI transfer speed for reads SPI read speed directly impacts boot time and we do quite a lot of reading. Add a way to easily find out the speed of SPI flash reads within coreboot. Write speed is less important since there are very few writes and they are small. BUG=chrome-os-partner:56556 BRANCH=none TEST=run on gru with SPI_SPEED_DEBUG set to 1. See the output messages: read SPI 627d4 7d73: 18455 us, 1740 KB/s, 13.920 Mbps Change-Id: Id3814bd2b7bd045cdfcc67eb1fabc861bf9ed3b2 Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: 82cb93f6be47efce3b0a3843bab89d2381baef89 Original-Change-Id: Iec66f5b8e3ad62f14d836a538dc7801e4ca669e7 Original-Signed-off-by: Simon Glass <sjg(a)chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/376944 Original-Commit-Ready: Julius Werner <jwerner(a)chromium.org> Original-Tested-by: Simon Glass <sjg(a)google.com> Original-Reviewed-by: Julius Werner <jwerner(a)chromium.org> --- src/drivers/spi/cbfs_spi.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/src/drivers/spi/cbfs_spi.c b/src/drivers/spi/cbfs_spi.c index 1895b9d..46e7346 100644 --- a/src/drivers/spi/cbfs_spi.c +++ b/src/drivers/spi/cbfs_spi.c @@ -23,14 +23,44 @@ #include <spi_flash.h> #include <symbols.h> #include <cbmem.h> +#include <timer.h> static struct spi_flash *spi_flash_info; +/* + * Set this to 1 to debug SPI speed, 0 to disable it + * The format is: + * + * read SPI 62854 7db7: 10416 us, 3089 KB/s, 24.712 Mbps + * + * The important number is the last one. It should roughly match your SPI + * clock. If it doesn't, your driver might need a little tuning. + */ +#define SPI_SPEED_DEBUG 0 + static ssize_t spi_readat(const struct region_device *rd, void *b, size_t offset, size_t size) { + struct stopwatch sw; + bool show = SPI_SPEED_DEBUG && size >= 4 * KiB; + + if (show) + stopwatch_init(&sw); if (spi_flash_info->read(spi_flash_info, offset, size, b)) return -1; + if (show) { + long usecs; + + usecs = stopwatch_duration_usecs(&sw); + u64 speed; /* KiB/s */ + int bps; /* Bits per second */ + + speed = (u64)size * 1000 / usecs; + bps = speed * 8; + + printk(BIOS_DEBUG, "read SPI %#zx %#zx: %ld us, %lld KB/s, %d.%03d Mbps\n", + offset, size, usecs, speed, bps / 1000, bps % 1000); + } return size; }

1 0

Patch set updated for coreboot: google/gru: pass apio number to arm-trust-firmware
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16720 -gerrit commit 092200099e112292ff0ecdffdb7434de18e05b07 Author: Lin Huang <hl(a)rock-chips.com> Date: Tue Aug 30 15:34:42 2016 -0700 google/gru: pass apio number to arm-trust-firmware for save power consumption, some gpio2 ~ gpio4 need to set to input and pull none mode. It depend on these gpio should shut down there power supply, so pass apio number to ATF, to decide which gpio need to config. BRANCH=None BUG=chrome-os-partner:56423 TEST=run suspend_stress_test on kevin board Change-Id: Id57fe8f622ae3f9c2bc7e58be89518b2b846cd37 Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: 9c42082d1ca9a6baa735821382d3e83c1f8dc9ad Original-Change-Id: Iaf441e8e34c5591ffe7c65f6533fcf0b733ff5ac Original-Signed-off-by: Lin Huang <hl(a)rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/378475 Original-Commit-Ready: Caesar Wang <wxt(a)rock-chips.com> Original-Tested-by: Caesar Wang <wxt(a)rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner(a)chromium.org> --- src/mainboard/google/gru/mainboard.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/src/mainboard/google/gru/mainboard.c b/src/mainboard/google/gru/mainboard.c index 902228b..8b9f595 100644 --- a/src/mainboard/google/gru/mainboard.c +++ b/src/mainboard/google/gru/mainboard.c @@ -43,6 +43,23 @@ static void configure_emmc(void) rkclk_configure_emmc(); } +static void register_apio_suspend(void) +{ + static struct bl31_apio_param param_apio = { + .h = { + .type = PARAM_SUSPEND_APIO, + }, + .apio = { + .apio1 = 1, + .apio2 = 1, + .apio3 = 1, + .apio4 = 1, + .apio5 = 1, + }, + }; + register_bl31_param(&param_apio.h); +} + static void register_gpio_suspend(void) { /* @@ -227,6 +244,7 @@ static void mainboard_init(device_t dev) register_reset_to_bl31(); register_poweroff_to_bl31(); register_gpio_suspend(); + register_apio_suspend(); } static void enable_backlight_booster(void)

1 0

Patch set updated for coreboot: google/gru: set W2W_DIFFCS_DLY to 5
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16721 -gerrit commit 5e866271c1b3a17af6cea1c36a482a8bdfa3b40a Author: Lin Huang <hl(a)rock-chips.com> Date: Wed Sep 21 17:05:43 2016 +0800 google/gru: set W2W_DIFFCS_DLY to 5 It will enable PHY_PER_CS_TRAINING when DDR DDR frequency >= 666. For per cs training, the controller should consider the PHY delay line switch time,there should be more cycles to switch delay line. So need increase W2W_DIFFCS_DLY_ value from 0x1 to 0x5. BRANCH=none BUG=chrome-os-partner:56940 TEST=do memtester on kevin board, and pass Change-Id: I00df2d4724b0b77f3e7565809fb35bbd2ff01ea5 Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: c135ea3e33d810ed322d947eb8d512d1ac119cfc Original-Change-Id: I81b99cbc085769b7028e770509d79bd8d550820b Original-Signed-off-by: Lin Huang <hl(a)rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/387506 Original-Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Original-Reviewed-by: Derek Basehore <dbasehore(a)chromium.org> Original-Reviewed-by: Julius Werner <jwerner(a)chromium.org> --- src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-200.c | 4 ++-- src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-666.c | 4 ++-- src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-800.c | 4 ++-- src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-933.c | 6 +++--- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-200.c b/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-200.c index c877158..5330141 100644 --- a/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-200.c +++ b/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-200.c @@ -279,8 +279,8 @@ struct rk3399_sdram_params params = { 0x05050502, /* DENALI_CTL_215_DATA */ 0x02080808, /* DENALI_CTL_216_DATA */ 0x02050202, /* DENALI_CTL_217_DATA */ - 0x02010202, /* DENALI_CTL_218_DATA */ - 0x00010202, /* DENALI_CTL_219_DATA */ + 0x02050202, /* DENALI_CTL_218_DATA */ + 0x00050202, /* DENALI_CTL_219_DATA */ 0x00020202, /* DENALI_CTL_220_DATA */ 0x02010200, /* DENALI_CTL_221_DATA */ 0x00010201, /* DENALI_CTL_222_DATA */ diff --git a/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-666.c b/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-666.c index 591924d..4b73cb0 100644 --- a/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-666.c +++ b/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-666.c @@ -279,8 +279,8 @@ struct rk3399_sdram_params params = { 0x08080803, /* DENALI_CTL_215_DATA */ 0x08080808, /* DENALI_CTL_216_DATA */ 0x02050203, /* DENALI_CTL_217_DATA */ - 0x02010303, /* DENALI_CTL_218_DATA */ - 0x00010203, /* DENALI_CTL_219_DATA */ + 0x02050303, /* DENALI_CTL_218_DATA */ + 0x00050203, /* DENALI_CTL_219_DATA */ 0x00020202, /* DENALI_CTL_220_DATA */ 0x03020400, /* DENALI_CTL_221_DATA */ 0x00020401, /* DENALI_CTL_222_DATA */ diff --git a/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-800.c b/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-800.c index b738644..3056e55 100644 --- a/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-800.c +++ b/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-800.c @@ -279,8 +279,8 @@ struct rk3399_sdram_params params = { 0x0a0a0a03, /* DENALI_CTL_215_DATA */ 0x08080808, /* DENALI_CTL_216_DATA */ 0x02050103, /* DENALI_CTL_217_DATA */ - 0x02010103, /* DENALI_CTL_218_DATA */ - 0x00010103, /* DENALI_CTL_219_DATA */ + 0x02050103, /* DENALI_CTL_218_DATA */ + 0x00050103, /* DENALI_CTL_219_DATA */ 0x00020202, /* DENALI_CTL_220_DATA */ 0x03020500, /* DENALI_CTL_221_DATA */ 0x00020501, /* DENALI_CTL_222_DATA */ diff --git a/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-933.c b/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-933.c index 362489b..3947881 100644 --- a/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-933.c +++ b/src/mainboard/google/gru/sdram_params/sdram-lpddr3-hynix-4GB-933.c @@ -278,9 +278,9 @@ struct rk3399_sdram_params params = { 0x04040001, /* DENALI_CTL_214_DATA */ 0x0c0c0c04, /* DENALI_CTL_215_DATA */ 0x08080808, /* DENALI_CTL_216_DATA */ - 0x02010103, /* DENALI_CTL_217_DATA */ - 0x02010103, /* DENALI_CTL_218_DATA */ - 0x00010103, /* DENALI_CTL_219_DATA */ + 0x02050103, /* DENALI_CTL_217_DATA */ + 0x02050103, /* DENALI_CTL_218_DATA */ + 0x00050103, /* DENALI_CTL_219_DATA */ 0x00020202, /* DENALI_CTL_220_DATA */ 0x06030600, /* DENALI_CTL_221_DATA */ 0x00030603, /* DENALI_CTL_222_DATA */

1 0

Patch set updated for coreboot: rockchip/rk3399: dram: improve dram stability when run high frequency
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16722 -gerrit commit 095834e97c59f2274ab6be9346be78e8344a2bdc Author: Lin Huang <hl(a)rock-chips.com> Date: Wed Sep 21 18:19:24 2016 +0800 rockchip/rk3399: dram: improve dram stability when run high frequency there are two modify in the driver: 1. correctly set speeds base on DDR frequency. Controls the speeds in the predriver circuits to reduce power. SPEED[1:0] 2'b00:less than 800Mbps(400MHz) 2b01 : 800Mbps(400MHz) to 1600Mbps(800MHz) 2b10 : 1600Mbsp(800MHz) to 2400Mbps(1200MHz) 2b11 : 3200Mbps and greater 2. config the number of cycles phy clock pll wait time after locking base on ddr config file. BRANCH=none BUG=chrome-os-partner:56940 TEST=do memtester on kevin board, and pass Change-Id: Iaf6da59c6c5c290867e0922a2a99de272f4c7bde Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: 125cf8afac3a682d33896fe74a20ba1d498a3bd2 Original-Change-Id: Iabc17df37a701c4f052540c3c259f209a1db3c59 Original-Signed-off-by: Lin Huang <hl(a)rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/387428 Original-Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Original-Reviewed-by: Julius Werner <jwerner(a)chromium.org> --- src/soc/rockchip/rk3399/sdram.c | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/src/soc/rockchip/rk3399/sdram.c b/src/soc/rockchip/rk3399/sdram.c index 9211895..1021c6b 100644 --- a/src/soc/rockchip/rk3399/sdram.c +++ b/src/soc/rockchip/rk3399/sdram.c @@ -322,6 +322,7 @@ static void phy_io_config(u32 channel, u32 mode_sel = 0; u32 reg_value; u32 drv_value, odt_value; + u32 speed; /* vref setting */ if (sdram_params->dramtype == LPDDR4) { @@ -436,22 +437,33 @@ static void phy_io_config(u32 channel, /* PHY_939 PHY_PAD_CS_DRIVE */ clrsetbits_le32(&denali_phy[939], 0x7 << 14, mode_sel << 14); + + /* speed setting */ + if (sdram_params->ddr_freq < 400*MHz) + speed = 0x0; + else if (sdram_params->ddr_freq < 800*MHz) + speed = 0x1; + else if (sdram_params->ddr_freq < 1200*MHz) + speed = 0x2; + else + speed = 0x3; + /* PHY_924 PHY_PAD_FDBK_DRIVE */ - clrsetbits_le32(&denali_phy[924], 0x3 << 21, mode_sel << 21); + clrsetbits_le32(&denali_phy[924], 0x3 << 21, speed << 21); /* PHY_926 PHY_PAD_DATA_DRIVE */ - clrsetbits_le32(&denali_phy[926], 0x3 << 9, mode_sel << 9); + clrsetbits_le32(&denali_phy[926], 0x3 << 9, speed << 9); /* PHY_927 PHY_PAD_DQS_DRIVE */ - clrsetbits_le32(&denali_phy[927], 0x3 << 9, mode_sel << 9); + clrsetbits_le32(&denali_phy[927], 0x3 << 9, speed << 9); /* PHY_928 PHY_PAD_ADDR_DRIVE */ - clrsetbits_le32(&denali_phy[928], 0x3 << 17, mode_sel << 17); + clrsetbits_le32(&denali_phy[928], 0x3 << 17, speed << 17); /* PHY_929 PHY_PAD_CLK_DRIVE */ - clrsetbits_le32(&denali_phy[929], 0x3 << 17, mode_sel << 17); + clrsetbits_le32(&denali_phy[929], 0x3 << 17, speed << 17); /* PHY_935 PHY_PAD_CKE_DRIVE */ - clrsetbits_le32(&denali_phy[935], 0x3 << 17, mode_sel << 17); + clrsetbits_le32(&denali_phy[935], 0x3 << 17, speed << 17); /* PHY_937 PHY_PAD_RST_DRIVE */ - clrsetbits_le32(&denali_phy[937], 0x3 << 17, mode_sel << 17); + clrsetbits_le32(&denali_phy[937], 0x3 << 17, speed << 17); /* PHY_939 PHY_PAD_CS_DRIVE */ - clrsetbits_le32(&denali_phy[939], 0x3 << 17, mode_sel << 17); + clrsetbits_le32(&denali_phy[939], 0x3 << 17, speed << 17); } static void pctl_cfg(u32 channel, @@ -477,9 +489,10 @@ static void pctl_cfg(u32 channel, /* rank count need to set for init */ set_memory_map(channel, sdram_params); - write32(&denali_phy[910], 0x6400); - write32(&denali_phy[911], 0x01221102); - write32(&denali_phy[912], 0x0); + write32(&denali_phy[910], sdram_params->phy_regs.denali_phy[910]); + write32(&denali_phy[911], sdram_params->phy_regs.denali_phy[911]); + write32(&denali_phy[912], sdram_params->phy_regs.denali_phy[912]); + pwrup_srefresh_exit = read32(&denali_ctl[68]) & PWRUP_SREFRESH_EXIT; clrbits_le32(&denali_ctl[68], PWRUP_SREFRESH_EXIT);

1 0

Patch merged into coreboot/master: rockchip: spi: Set rxd sample delay when using high speed
by gerrit＠coreboot.org 04 Oct '16

04 Oct '16

the following patch was just integrated into master: commit 52669fc4dc4ab38e9ca61d65487fdfb809d3dd3d Author: Simon Glass <sjg(a)chromium.org> Date: Mon Sep 5 11:04:50 2016 -0600 rockchip: spi: Set rxd sample delay when using high speed At higher SPI bus speeds the SPI RX value is not available in time for sampling at the normal time. Add a delay to ensure that we read the correct data. The value of 40ns is chosen arbitrarily. In my testing I can use a sample delay of 1 even at 24MHz. But since it is not necessary, I have left that case alone. It kicks in at 25MHz and up. BUG=chrome-os-partner:56556 BRANCH=none TEST=boot on gru and see no change at current speed Change-Id: I3ef335d9a532eaef1e76034bd02e185acf11176a Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: e9b620c47fc3e39211487507fadb8657afdebee7 Original-Change-Id: I65d66d752cbbbee4d02f475de23a52069a0e9782 Original-Signed-off-by: Simon Glass <sjg(a)chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/381311 Original-Commit-Ready: Julius Werner <jwerner(a)chromium.org> Original-Tested-by: Simon Glass <sjg(a)google.com> Original-Reviewed-by: Julius Werner <jwerner(a)chromium.org> Reviewed-on: https://review.coreboot.org/16707 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi(a)google.com> See https://review.coreboot.org/16707 for details. -gerrit

1 0

New patch to review for coreboot: google/gru: drive WLAN_MODULE_RST# low as early as possible
by Patrick Georgi 04 Oct '16

04 Oct '16

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/16882 -gerrit commit eedcf7d3b6b5138b9e35e3c689875978b1428d13 Author: Brian Norris <briannorris(a)chromium.org> Date: Wed Sep 21 18:16:54 2016 -0700 google/gru: drive WLAN_MODULE_RST# low as early as possible GPIO1_B3 (WLAN_MODULE_RST#) defaults as a pull-up input, but it is also "pulled up" by 1.8V_WLAN. However, 1.8V_WLAN remains low for some time during early boot. This leaves the signal floating somewhere in the middle. This has two potential issues: (1) we're leaking some power for some (hopefully) short period of time (2) we are possibly screwing with the Wifi power sequence; we aren't supposed to deassert PDn (i.e., MODULE_RST#) until all the rails have fully ramped for some period of time Neither of the above issues are likely to be significant, but it is nice to fix, I expect. BRANCH=gru BUG=chrome-os-partner:54026 TEST=measure WLAN_MODULE_RST# on scope at boot time Change-Id: Ia6af9ad6954ad8feeda33015e3f205842380939e Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: 0e890a2787bf034d3358a33fc88c2dd8078593ab Original-Change-Id: I120e26ad0ca486a326874986e142dcaee965b62d Original-Signed-off-by: Brian Norris <briannorris(a)chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/388009 Original-Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Original-Reviewed-by: Julius Werner <jwerner(a)chromium.org> --- src/mainboard/google/gru/mainboard.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/mainboard/google/gru/mainboard.c b/src/mainboard/google/gru/mainboard.c index 8b9f595..ae2c339 100644 --- a/src/mainboard/google/gru/mainboard.c +++ b/src/mainboard/google/gru/mainboard.c @@ -29,6 +29,16 @@ #include "board.h" +/* + * Wifi's PDN/RST line is pulled down by its (unpowered) voltage rails, but + * this reset pin is pulled up by default. Let's drive it low as early as we + * can. + */ +static void deassert_wifi_power(void) +{ + gpio_output(GPIO(1, B, 3), 0); /* Assert WLAN_MODULE_RST# */ +} + static void configure_emmc(void) { /* Host controller does not support programmable clock generator. @@ -236,6 +246,7 @@ static void setup_usb(void) static void mainboard_init(device_t dev) { + deassert_wifi_power(); configure_sdmmc(); configure_emmc(); configure_codec();

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit October 2016