lynxpoint: Don't write to non-existent EHCI

The LynxPoint-LP chipset only has one EHCI controller so we should
not attempt to write into the second one that only exists on LynxPoint-H.

BUG=chrome-os-partner:21342
BRANCH=falco,peppy
TEST=emerge-falco chromeos-coreboot-falco

Change-Id: I1eae060c7f0a5873c9684e5abfeea5cb5895ab62
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
lynxpoint: Move USB SMI sleep code to separate USB files

Move this to the existing USB source files so they can share some
helper functions and keep the main smihandler code cleaner.

The XHCI sleep prepare code now implements the actual sleep
preparation steps from the ref code instead of the docs.

BUG=chrome-os-partner:19975
BRANCH=falco,peppy
CQ-DEPEND=CL:63802
TEST=emerge-falco chromeos-coreboot-falco

Change-Id: Ic90adbdaba947a6b53824e548c785b4fb3990ab5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63800
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
lynxpoint: Route all USB ports to XHCI in finalize step

This commit adds a new Kconfig option for the LynxPoint
southbridge that will have coreboot route all of the USB
ports to the XHCI controller in the finalize step (i.e.
after the bootloader) and disable the EHCI controller(s).

Additionally when doing this the XHCI USB3 ports need
to be put into an expected state on resume in order to make
the kernel state machine happy.

Part of this could also be done in depthcharge but there
are also some resume-time steps required so it makes sense
to keep it all together in coreboot.

This can theoretically save ~100mW at runtime.

BUG=chrome-os-partner:21342
BRANCH=falco,peppy
CQ-DEPEND=CL:63800
TEST=emerge-falco chromeos-coreboot-falco

Verify that the EHCI controller is not found in Linux and
that booting from USB still works.

Change-Id: I3ddfecc0ab12a4302e6034ea8d13ccd8ea2a655d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63802
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
lynxpoint: Fix issues with XHCI init

- Put the device into D0 and not D3 so memory bar is available
and the subsequent commands actually do something useful
- Remove set of 818Ch[7:0]=FFh (gone in ref code)
- Fix reg 0x40/0x44 mixup

BUG=chrome-os-partner:19975
BRANCH=falco,peppy
TEST=emerge-falco chromeos-coreboot-falco

Verify that expected bits are set:
localhost ~ # pci_read32 0 0x14 0 0x10
0xe0500004
localhost ~ # mmio_read32 0xe0508144
0x000003ff
localhost ~ # mmio_read32 0xe050816c
0x000f0038

Change-Id: I388398e8c7d11e538ca18dab55d8bbd9b88f17df
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63801
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
lynxpoint: XHCI: Advertise D3 as lowest wake state

The recommended value in docs is D2, but lynxpoint XHCI does not even
support D2 state which causes the kernel to think this device cannot
be used as a wake source:

kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
kernel: ACPI: Device does not support D2
kernel: xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI

Additionally this means the kernel will never put the device into D3
state by itself.  There is SMI code that will put the device into D3
before suspend so advertising D3 here should be correct.

With this change the kernel will put the controller into D3 on suspend
and back to D0 on resume, including executing the ACPI methods
for _PS0/_PS3 that contain chipset specific workarounds.

In addition add a _PSC method to directly return the D state from the
device registers.  With ALL USB devices removed the XHCI controller
goes into D3 state and the kernel can have a hard time determining
the state of the device at boot.

BUG=chrome-os-partner:21342
BRANCH=falco,peppy
TEST=emerge-falco chromeos-coreboot-falco

A kernel compiled with CONFIG_ACPI_DEBUG=y and module parameters
acpi.debug_layer=0x7f acpi.debug_level=0x2f can be used to see
what ACPI methods are executed:

kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS3] (Node ffff8801000a7f50)
kernel: ACPI: Preparing to enter system sleep state S3
...
kernel: ACPI: Waking up from system sleep state S3
kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS0] (Node ffff8801000a7f28)
kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D0

Change-Id: Ic64040eb4dd1947a1e2f0ee253a64be683e0ec70
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>

meld with s3d

Change-Id: Ic6789720c4efe661dcb03a4afce8d88115854472
Reviewed-on: https://gerrit.chromium.org/gerrit/63916
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Pit: disable SYSMMU for graphics.

It's not needed and it's a potential problem source.

BUG=None
TEST=Build and boot and it works
BRANCH=None

Change-Id: Ic4cafe74e7fc3a9031d852895ad7fd5e5cd64d11
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62279
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Add a kirby board which is mostly a copy of pit.

BUG=None
TEST=Along with some other changes, emerged chromeos-coreboot-peach_kirby.
BRANCH=None

Change-Id: Ic78c65486816015f7574a13affc6e54acbbea73e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63875
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
libpayload: Add a config for peach_kirby.

BUG=None
TEST=With other changes, emerged libpayload for kirby.
BRANCH=None

Change-Id: I365a38a5621be1d42d2675d96acfdc133ec2d04d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63876
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
kirby: Neutralize wakeup.c and delete the mostly unused exynos5420.h.

The function in wakeup.c isn't applicable on kirby. The only constant in
exynos5420.h that was used was the speed of the 4th i2c bus. Instead of having
a whole header file for that one constant used in one place, the constant is
just moved inline along with the comment it had in the header.

BUG=None
TEST=Built for kirby.
BRANCH=None

Change-Id: I5ad50c5eeaecbbf7865d76afb31a12d36c3371ee
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63882
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
kirby: Clean some cruft from mainboard.c.

1. Kirby doesn't have a backlight enable GPIO on the AP since that's handled
entirely by the DP-to-LVDS bridge.
2. There is no tps65090 on the other side of the EC who's settings need to be
adjusted. If we need to turn on the LCD or backlight power manually, it will
have to be done in a different way.
3. The PMIC doesn't provide a 32KHz output for the audio codec.

BUG=None
TEST=Built for kirby.
BRANCH=None

Change-Id: Iadc5f3aec4818805edf3f2517da9e6fee87085dc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63883
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
falco: Drive GPIO59/LTE_DISABLE_L low on S3/S5

Try to prevent WWAN from causing spurious wakes.

BUG=chrome-os-partner:20832
BRANCH=falco
TEST=emerge-falco chromeos-coreboot-falco

Change-Id: Ifcc44063de0eb1634cab9dd244737071568e3455
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63987
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
chromeec: Add event methods for EC requested throttle

Two new events possible from the EC for starting and stopping throttle.

These are handled in a per-board method that is defined under the
thermal zone.  This is not quite where I wanted it but the scoping
rules in ACPI don't let me have a defined external object in the
same scope.

BUG=chrome-os-partner:20739
BRANCH=falco
TEST=emerge-falco chromeos-coreboot-falco

Change-Id: I766f07b4365b29df3daa8e45e88f7c38c645c287
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63988
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
falco: Enable EC controlled throttling

When the EC requests the host to throttle (for charging or thermal
related reasons) the package power consumption will be limited.

Right now this is set at 12W but that is somewhat arbitrary and may
need tuning.

1) define the THRT method in \_TZ scope for EC to call
2) enable SCI events for throttle start and stop
3) define the power limit at 12W and set it in NVS

BUG=chrome-os-partner:20739
BRANCH=falco
TEST=manual:

1) Enable CONFIG_ACPI_DEBUG=y in the kernel

2) Enable the Debug object event in acpi module
acpi.debug_layer=0x7f acpi.debug_level=0x2f

3) Using EC console generate host event for throttle start
> hostevent set 0x20000

4) Check dmesg for throttle start events
ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._Q12] (Node ffff8801002c5988)
[ACPI Debug]  String [0x12] "EC: THROTTLE START"
[ACPI Debug]  String [0x10] "Enable PL1 Limit"

5) Using EC console generate host event for throttle stop
> hostevent set 0x40000

6) Check dmesg for throttle stop events
ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._Q13] (Node ffff8801002c59b0)
[ACPI Debug]  String [0x11] "EC: THROTTLE STOP"
[ACPI Debug]  String [0x11] "Disable PL1 Limit"

Change-Id: I39b53a5e8abc2892846bcd214a333fe204c6da9b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63989
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
exynos5420: Apply pwm const fix to the 5420 as well.

When the const was removed from write function arguments, a related bug in the
5250 code was fixed so that it would still compile. Unfortunately, that same
change needed to be made to the 5420.

BUG=chrome-os-partner:19420
TEST=Built for pit and saw the build succeed.
BRANCH=None

Change-Id: If15057c92422de91dc8e35dbd8b5c978bfae122a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64154
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
exynos5420: Get rid of the PWM code like on the 5250.

The timer code was supposed to be using the mct, and also using the monotonic
timer infrastructure instead of the get_timer function. This change had been
made for the 5250 but not yet for the 5420.

BUG=chrome-os-partner:19420
TEST=Built and booted on pit.
BRANCH=None

Change-Id: I03a4fbb434f2346761f28fb6bd2218b526f2a4a2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64159
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
exynos5250: Add mct_start to the timer init blob in timer_monotonic_get.

A previous change removed init_timer from timer_monotonic_get because its old
implementation set up the PWM based timer which was going away. It would still
be a good idea to initialize the timer at that point, just not the pwm.

BUG=chrome-os-partner:19420
TEST=Built and booted on snow.
BRANCH=None

Change-Id: I4816710ec2c9d5ca53b704c6b9397bcfac183fdc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64160
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
pit: Get rid of the mostly unnecessary exynos5420.h.

Like on kirby, this header had a single constant in it that was actually used.
This change moves that constant inline and gets rid of the header file.

BUG=chrome-os-partner:19420
TEST=Built and booted on pit.
BRANCH=None

Change-Id: Ibe380396f72fddb121fb6ceb3cee24f1b9a85738
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64163
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
kirby: pit: Fix up wakeup_need_reset.

In a previous commit the contents of wakeup_need_reset were removed because
the GPIO it referred to wasn't connected to anything on pit. I didn't realize
at that time that that could have been because we hadn't tried getting
suspend/resume working on pit and hadn't updated that file. On snow, the GPIO
is the recovery mode pin. This change updates pit to have the right GPIO,
kirby to read that GPIO, and makes the comments for both pit and kirby more
explicit and spells out the fact that this is the recovery mode GPIO.

Having a check here at all may still be a holdover from snow that isn't
applicable to pit or kirby, but since there is a parallel as far as the
recovery mode GPIO we might as well make them match while waiting for more
information.

BUG=chrome-os-partner:19420
TEST=Built and booted on pit. Built for kirby.
BRANCH=None

Change-Id: Ic1f3f605a0fddf89e8f5668c7a8df30bdfb91d94
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64164
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Patch to add cpu transcoder attribute to intel dp.

Also, used this attribute in the calculation of htotal and other registers
Added intel_dp_* functions for m,n registers and dimension register calculations

Change-Id: I99dd7156700d59b0b4c85e34c9aa1c6408c7f31a
Reviewed-on: https://gerrit.chromium.org/gerrit/64001
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Slippy/Falco: Patch to fill in right values for PHSYNC and PVSYNC in transcoder flags

Depending upon the values decoded from edid, the function decides the appropriate bits to
be set in flags parameter (Important for fastboot to work correctly in kernel)

Change-Id: I3b0f914dc2b0fd887eb6a1f706f87b87c86ff856
Reviewed-on: https://gerrit.chromium.org/gerrit/64265
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>