I messed up in setting this register, it should be using Tj_max-Temp
which in the default case works out to be 90-90=0.
This was apparently heavly throttling the CPU at idle temps.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, run graphics_WebGLPerformance test
Change-Id: I4338280cf50db84dc44313d6fb6771ea5af21dad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183280
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
These values are for the 2 and 4 core B-step parts.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=boot on rambi and check for valid GPU power values from DPTF
Change-Id: I2772cb9dbf17560fc31f871a111f32131c7e5105
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183101
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 701273892c7bdaf898a94a337fae9f7373a9c748)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183102
Add support for initializing the rtc device. Also
add RTC well loss events to the eventlog and properly
clear the event so it doesn't get added again.
BUG=None
BRANCH=baytrail
TEST=Built and booted. Tested battery loss. Eventlog
has RTC event. In addition the rtc device can
be properly probed in the kernel resulting in
/sys/class/rtc/rtc0 being available.
Change-Id: I1ca608b069dc50db116d75963d5542a7f9b1811f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183051
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Apply the SOC thermal settings from DPTF reference code for
SdpProfile=4 and adjust graphics PUNIT setting to match.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=boot on rambi and check for valid GPU power values from DPTF
Change-Id: I59fc4b75b52084ebcc4c0556563afca0585ea6b8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182786
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Though the limited documentation indicates the default is
0 for the gfx_turbo_disable bit, in practice that isn't
true. Knock down the gfs_turbo_disable bit to enable
graphics turbo mode.
BUG=chrome-os-partner:25044
BRANCH=baytrail
TEST=Built and booted. Added debug code to output SB_BIOS_CONFIG.
Noted that bit 7 was set to 0.
Change-Id: I11210c6a0b29765cb709a54d6ebd94211538807b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182640
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On baytrail, it appears that the turbo disable setting is
actually building-block scoped. One can see this on quad
core parts where if enable_turbo() is called only on the
BSP then only cpus 0 and 1 have turbo enabled. Fix this
by calling enable_turbo() on all non-bsp cpus.
BUG=chrome-os-partner:25014
BRANCH=baytrail
TEST=Built and booted rambi. All cpus have bit 38 set to 0
in msr 0x1a0.
Change-Id: Id493e070c4a70bb236cdbd540d2321731a99aec2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182406
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This will allow USB devices to wake the system (if 5V is not turned off)
and the controller to enter D3 at runtime. (if autosuspend is enabled)
BUG=chrome-os-partner:23629
BRANCH=baytrail
TEST=build and boot on baytrail
1) with modified EC to leave 5V on in S3 ensure that waking from suspend
with USB keyboard works.
2) with laptop-mode-tools usb autosuepend config updated see that device
enters D3 at runtime when no external devices attached.
Change-Id: Ia396d42494e30105f06eb3bd65b4ba8b1372cf35
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182536
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch switches every last part of Coreboot on ARM over to Thumb
mode: libpayload, the internal libgcc, and assorted assembly files. In
combination with the respective depthcharge patch, this will switch to
Thumb mode right after the entry point of the bootblock and not switch
back to ARM until the final assembly stub that jumps to the kernel.
The required changes to make this work include some new headers and
Makefile flags to handle assembly files (using the unified syntax and
the same helper macros as Linux), modifying our custom-written libgcc
code for 64-bit division to support Thumb (removing some stale old files
that were never really used for clarity), and flipping the general
CFLAGS to Thumb (some more cleanup there as well while I'm at it).
BUG=None
TEST=Snow and Nyan still boot.
Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182212
Reviewed-by: Gabe Black <gabeblack@chromium.org>
libgcc/macros.h contains some useful assembly macros that are common in
Linux kernel code and facilitate things such as unified ARM/THUMB
assembly. This patch moves it to a more general place where it can be
used by other code as well.
BUG=None
TEST=Snow still boots.
Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The current byte value was being converted to an int
when checking against literal 0xff. As the type of
the current pointer was char (signed) it was sign
extending the value leading to 0xffffffff != 0xff.
Fix this by using an unsigned type and using a
constant type for expected erase value.
BUG=chrome-os-partner:24916
BRANCH=baytrail
TEST=Booted after chromeos-firmwareupdate. Noted that MRC
cache doesn't think the erased region isn't erased.
Change-Id: If95425fe26da050acb25f52bea060e288ad3633c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182154
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On a firmware update the MRC cache is destroyed. On the
subsequent boot the MRC region was attempted to be erased
even if it was already erased. This led to spi part taking
longer than it should have for an unnecessary erase
operation. Therefore, check that the region is erased
before issuing the erease command.
BUG=chrome-os-partner:24916
BRANCH=baytrail
TEST=Booted after chromeos-firmeareupdate. Noted no
error messages in this path.
Change-Id: I6fadeb6bc5fc178abb0a7e3f0898855e481add2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182153
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix the smeared screen observed when FB has not been initialized.
BUG=None
TEST=graphics comes up clean.
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I1ce2365d07d0463968fe50fc45a278badc9e9c0d
Reviewed-on: https://chromium-review.googlesource.com/182090
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
The hack seems to set up coreboot display to use window B. We eventually
want to use the same window as the kernel is going to use (I think), so
that's what this patch does.
We think window B is hiding the contents of window A, which is why we
weren't seeing ChromeOS UI come up. This fix makes that not happen anymore
by making coreboot use window A.
BUG=chrome-os-partner:24844
TEST=Can boot ChromeOS to UI from coreboot.
Change-Id: I24b95200ba2e8eaeadecd45392ccee5e270aa7da
Reviewed-on: https://chromium-review.googlesource.com/182001
Tested-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
This improves boot time in 2 ways for a firmware upgrade:
1. Normally MRC would detect the S0 state without an MRC cache
even though it's told to the S5 path. When it observes this
state a cold reset occurs. The cold reset stays in S5 for
at least 4 seconds which is time observed by the end user.
2. As the EC was running RW code before the reset after firmware
upgrade it will still be running the older RW code. Vboot will
then reboot the EC and the whole system to put the EC into RO
mode so it can handle the RW update.
The issues are mitigated by detecting the system is in S0 with
no MRC cache and the EC isn't in RO mode. Therefore we can do the
reboot without waiting the 4 secs and the EC is running RO so
the 2nd reboot is not necessary.
BUG=chrome-os-partner:24133
BRANCH=rambi,squawks
TEST=Booted. Updated firmware while in OS. Rebooted. Noted the
EC reboot before MRC execution.
Change-Id: I1c53d334a5e18c237a74ffbe96f263a7540cd8fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182061
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Added a method in each temp sensor to disable the aux trip points
and then a wrapper function to call this method for each enabled
temperature sensor.
The event handler function is changed to not use a switch statement
so it does not need to be serialized. This was causing issues
with nested locking between the global lock and the EC PATM mutex.
Some unused code in temp sensors that was added earlier is removed
and instead a critical threshold is specified in _CRT.
The top level DPTF device _OSC method is expanded to check for the
passive policy UUID and initialize thermal devices. This is done
for both enable and disable steps to ensure that the EC thermal
thresholds are reset in both cases.
Additionally the priority based _TRT is specified with TRTR=1.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, load esif_lf kernel drivers and start
esif_uf application. Observe that temperature thresholds are set
properly when running 'appstart Dptf' and that they are disabled
after running 'appstop Dptf'
Change-Id: Ia15824ca42164dadae2011d4e364b70905e36f85
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182024
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SMI on TCO timer timeout policy was copied from other
chipsets. However, it's not very advantageous to have
the TCO timer timeout trigger an SMI unless the firmware
was the one responsible for setting up the timer.
BUG=chromium:321832
BRANCH=rambi,squawks
TEST=Manually enabled TCO timer. TCO fires and logged in
eventlog.
Change-Id: I420b14d6aa778335a925784a64160fa885cba20f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181985
The PMC in baytrail maintains an additional set
wake status in memory-mapped registers. If these
bits aren't cleared the device won't be able to
go to S5 or S3 without being immediately woken up.
Therefore clear these registers.
BUG=chrome-os-partner:24913
BRANCH=rambi,squawks
TEST=Ensured PRSTS bit 4 is cleared after a reboot and S3 and S5 work
correctly.
Change-Id: I356e00ece851961135b4760cebcdd34e8b9da027
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181984
When CONFIG_ELOG is selected the reset, power, and wake
events are logged in the eventlog.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Various resets and wake sources. Interrogated eventlog
to ensure results are expected.
Change-Id: Ia68548562917be6c2a0d8d405a5b519102b8c563
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181983
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
1. Clean up some debug messages
2. Remove some dead code
3. Correct some delay time.
BUG=none
BRANCH=none
TEST=build and boot up graphic
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I4362cd886cfd625ef55535839e8ad1a7416977d4
Reviewed-on: https://chromium-review.googlesource.com/181003
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
- Remove some unused functions from CPU participant that were
confusing the userland component since the CPU does not have
an ACPI managed sensor.
- Guard the charger participant with an ifdef so it can be
left out if not supported.
- Use the EC methods for setting auxiliary trip points and for
handling the event when those trip points are crossed.
- Add _NTT _DTI _SCP methods for thermal sensors. I'm not
clear if these are required or not but they seem to be expected
by the other DPTF framework components.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi and load ESIF framework
Change-Id: I3c9d92d5c52e5a7ec890a377e65ebf118cdd7087
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The kernel expects CPUs to be in a known good state at boot, which
means the CPUs are not in reset and not gated. Ungate the clock
and clear the resets for the LP cluster (cluster1) as is done for
the G cluster.
BUG=chrome-os-partner:23816,chrome-os-partner:24487
TEST=No more hangs during cluster switching.
BRANCH=None
Change-Id: I88d80f6072281beb98bba6ae38a0ddeb81165038
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180866
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
The kernel does not support using pll_c_out0 as the parent of sclk,
nor does it support the use of super dividers. The reason for this
is that DVFS schemes must use the pre-divided rate with using super
dividers when setting voltages, which makes them essentially useless.
Instead, set pll_c_out1 to 300Mhz (pll_c / 2) and use that as the parent
of sclk.
BUG=chrome-os-partner:24487
TEST=Kernel now boots with sclk DVFS enabled
BRANCH=None
Change-Id: Ia106963d290122cddbaf9eaf88047fda2dfe8b8a
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180865
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
The BISOC.EXIT_SELF_REFRESH_LATENCY field should
not be updated from the default.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: I6e701a520513372318258648e998dd8c7ab29ea4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180730
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
When employing vboot firmware verification the reference
code loading should load from the verified firmware
section. Add this ability.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted rambi. Noted firmware being loaded
from rw verified area. Also noted S3 resume loading
from cached area.
Change-Id: I114de844f218b7573cf90107e174bf0962fdaa50
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180026
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This implements x2 mode when reading CBFS media over SPI.
In theory this effectively doubles our throughput, though the initial
results were almost negligibly better. Using a logic analyzer we see
a pattern of 12 clocks, ~70ns delay, 4 clocks, ~310ns delay. So if we
want to see further gains here then we'll probably need to tune AHB
arbitration and utilization to eliminate bubbles/stalls when copying
from APB DMA.
BUG=none
BRANCH=none
TEST=built and booted on Nyan.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I33d6ae30923fc42b4dc7103d029085985472cf3e
Reviewed-on: https://chromium-review.googlesource.com/177835
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This reverts commit 58ee4a7f63.
The underlying problem has been fixed by:
ARM: Define custom ELF headers for ARM.
$ cbfstool /build/nyan/firmware/coreboot.rom printcoreboot.rom: 1024 kB, bootblocksize 83968, romsize 1048576, offset 0x18080
alignment: 64 bytes, architecture: arm
Name Offset Type Size
fallback/romstage 0x18080 stage 17556
fallback/coreboot_ram 0x1c580 stage 31509
config 0x24100 raw 2920
(empty) 0x24cc0 null 897752
BUG=None
TEST=Built for nyan and verified that the ROM stage was less than 18KB instead
of being 46KB.
BRANCH=None
Change-Id: I4727f1b3d96a27a6382363565ab3153cec559547
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180164
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Remove many no longer needed code and files.
More clean up will be followed.
BUG=none
BRANCH=none
TEST=build and boot up graphic
Change-Id: I72471be01e7c9b5244aff12b45f887dd35dfe58e
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/180135
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
The ROMSTAGE_BASE currently must be aligned to 0x8000 bytes, otherwise linker
will try to do that and pad zeros, creating a large (ex, >40k) romstage blob,
which cannot be loaded properly.
BUG=none
TEST=Boots successfully on Nyan.
Change-Id: I7626542c8344bbf6641a200879e4aa18183dc1bd
Reviewed-on: https://chromium-review.googlesource.com/180150
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The kernel iosf driver uses HID INT33BD to probe and
be provided the 12 bytes in PCI for access.
BUG=chrome-os-partner:17279
BRANCH=none
TEST=build and boot on rambi, load iosf_mbi driver and
verify that it gets address 0xe00000d0
Change-Id: I865eafe664f00f21d1ebb967c291083830d895b9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180098
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To allow doing DRAM initialization in ROM stage instead of BootROM, we need to
move bootblock and ROM stage base address into iRAM, also the stack and CBFS
cache area just like TTB.
BUG=none
TEST=Boots on Nyan without problem.
Change-Id: I459faef5eb0f75561089dafbb111ae83729c3a29
Reviewed-on: https://chromium-review.googlesource.com/179822
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Add iRAM layout in Kconfig comments so we can know how and where to utilize iRAM
in future.
BUG=none
TEST=none # simply adding comments.
Change-Id: I77ec661e6980ad7d77a9c26840bd911a555cc37c
Reviewed-on: https://chromium-review.googlesource.com/179814
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Make sure reg_script is executed before the device is put into
ACPI mode.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi from eMMC in ACPI mode
Change-Id: I4090babbfc7fb0f3be4da869386e998d87a513ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179896
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since this file will get added to payloads it is useful if it
exports what offset in NVS it lives.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi with emmc in ACPI mode
Change-Id: I52860980c91dfe2525628e142b34ca192e69b258
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179848
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Correct norrin display specific settings. Drop venice2 supporting
functions.
norrin display code needs to be clean up.
BUG=None
TEST=built, flash and boot, graphic shown up
BRANCH=None
Change-Id: If62028b6f5cb101c4898f7198c3e057f2bac61f3
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/179745
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
In order to use the same reference code on S3 resume
that was booted the program needs to be cached. Piggy
back on the ramstage cache to save the loaded reference
code program.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed. Noted locations of reference
code caching and load addresses in console.
Change-Id: I90ceaf5697e8c269c3244370519d4d8a8ee2eb4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179777
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
To prepare for caching reference code for S3 resume the
ramstage cache needs to be accesible in ramstage as well.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: I4c825c965b98cd71ea0eb9c93fe168a358da4c97
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179776
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Certain code paths want to know if S3 resume is
happening. However, the current baytrail code doesn't
note S3 resume early enough. Therefore, mark S3
resume just after pattr setup.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: I5e5cc285940e4567521afb8483614ce6f813ddde
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179774
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The inclusion of reg_script_run_on_dev() allows
for removing some of the chained reg_scripts just
to set up the device context. Use the new reg_script
function in those cases.
BUG=None
BRANCH=None
TEST=Built and booted. Didn't see any bizarre dmesg or coreboot
console output.
Change-Id: I3207449424c1efe92186125004d5aea1bb5ba438
Signed-off-by: Aaron Durbin <adurbin@chromium.og>
Reviewed-on: https://chromium-review.googlesource.com/179541
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
According to the reference code all these registers
need to be set to their best known values.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted. Suspend and wake. No idea about
observable impact yet.
Change-Id: I0e31505a165eee1d177e5d726edcfa6947430476
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179749
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There's a slew of ports required to initialize baytrail's
perf and power values. Therefore, add the necessary
functionality in the iosf module as well as the reg_script
library.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted.
Change-Id: Id45def82f9b173abeba0e67e4055f21853e62772
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179748
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The iosf access functions already use some common code,
however there is a duplication for setting up the proper
control register for port and opcode. Introduce macros
to remove this verbosity.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted. Suspend and wake.
Change-Id: I5bad7e2a11fa8e8bd4a3d7fa53d917b2565644f8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179747
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds a new static assertion macro that can be used to check
the offsets in structures that overlay register sets at compile time. It
uses the _Static_assert() declaration from the new ISO C11 standard,
which is supported (even without -std=c11) by GCC after version 4.6.
(There is supposedly also support in clang, although I haven't tried
it... let's deal with compiler issues when/if they turn up.)
I've added it to all structures for our current ARM SoCs for now, and I
think every new register overlay we add going forward should use them
(at least for the last member, but feel free to add more if you think
it's useful).
BUG=None
TEST=Compiled for Snow, Pit and Nyan.
Change-Id: If32510e7049739ad05618d363a854dc372d64386
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179412
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This adds the option to put LPSS and SCC devices into ACPI mode
by saving their BAR0 and BAR1 base addresses in a new device
NVS structure that is placed at offset 0x1000 within the global
NVS table.
The Chrome NVS strcture is padded out to 0xf00 bytes so there
is a clean offset to work with as it will need to be used by
depthcharge to know what addresses devices live at.
A few ACPI Mode IRQs are fixed up, DMA1 and DMA2 are swapped and
the EMMC 4.5 IRQ is changed to 44.
New ACPI code is provided to instantiate the LPSS and SCC devices
with the magic HID values from Intel so the kernel drivers can
locate and use them.
The default is still for devices to be in PCI mode so this does
not have any real effect without it being enabled in the mainboard
devicetree.
Note: this needs the updated IASL compiler which is in the CQ now
because it uses the FixedDMA() ACPI operator.
BUG=chrome-os-partner:23505,chrome-os-partner:24380
CQ-DEPEND=CL:179459,CL:179364
BRANCH=none
TEST=manual tests on rambi device:
1) build and boot with devices still in PCI mode and ensure that
nothing is changed
2) enable lpss_acpi_mode and see I2C devices detected by the kernel
in ACPI mode. Note that by itself this breaks trackpad probing so
that will need to be implemented before it is enabled.
3) enable scc_acpi_mode and see EMMC and SDCard devices detected by
the kernel in ACPI mode. Note that this breaks depthcharge use of
the EMMC because it is not longer discoverable as a PCI device.
Change-Id: I2a007f3c4e0b06ace5172a15c696a8eaad41ed73
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179481
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is not complete yet but it compiles and doesn't cause
any issues by itself. It is tied into the EC pretty closely
so that is part of the same commit.
Once we have more of the EC support done it will need some
more work to make use of those new interfaces properly.
BUG=chrome-os-partner:17279
BRANCH=none
TEST=build and boot on rambi, dump DSDT and look over \_SB.DPTF
Change-Id: I4b27e38baae18627a275488d77944208950b98bd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179459
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These need to be set before the kernel will work without
running the VBIOS option rom.
Also necessary is setting the PP_CONTROL register with
the EDP_FORCE_VDD bit.
BUG=chrome-os-partner:24367
BRANCH=none
TEST=boot on rambi in normal mode and see the panel come up
Change-Id: I495f818d581d08b80db11785fe28b601ec956b3b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179364
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Patch 547fbbfe2e introduced an off-by-one error in the offsets of the
PMU register struct, which put both the newly added register and the
PSHOLD that comes after it in the wrong place. This patch corrects the
offsets (5420 had already been correct).
BUG=None
TEST=Boots on Snow.
Change-Id: I1d9d31a6a73ee91890824e94fbd247d5feb4f6ae
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179411
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
