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>
The reg_script library has proven to be useful. It's
also shown that many scripts operate on devices. However,
certain code paths run the same script on multiple,
but different, devices. In order to make that easier
introduce reg_script_run_on_dev() which takes a device
as a parameter. That way, chained reg_scripts are not
scrictly needed to run the same script on multiple devices.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I273499af4d303ebd7dc19e9b635ca23cf9bb2225
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179540
Reviewed-by: Duncan Laurie <dlaurie@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 enables the DPTF framework, but it doesn't do much
without some sort of kernel+user components to drive it.
BUG=chrome-os-partner:17279
BRANCH=none
TEST=build and boot on rambi, dump DSDT and look over \_SB.DPTF
Change-Id: Icb632a6e70c3912bbdfa6ef3f5c87cd79d2b8a3a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179480
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 are the values that are seen with VBIOS and
may need tweaked for derivative panels.
BUG=chrome-os-partner:24367
BRANCH=none
TEST=boot on rambi in normal mode and see the panel come up
Change-Id: Ie3120ab3c5298135626e8534d3954acd263dc74b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179365
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>
On Tegra1x4 platforms, certain display-related registers
cannot be accessed unless the VPR registers are correctly
set up first. This allows the kernel graphics driver to
talk to the HW in the same manner on all Tegra SoCs.
Change-Id: I96e0c4075709da51be530a473da8d593ca498722
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/179327
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Now that the SD card controller is limited to the SD card
2.0 spec it's possible to use 20K pulls for the pads.
BUG=chrome-os-partner:24423
BUG=chrome-os-partner:24312
BRANCH=None
TEST=Built and booted. Able to dd to/from /dev/mmcblk1 without
any errors.
Change-Id: Id5396c55330a84bf7a09d227507d2bfcde66a1a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179423
The rambi board can only meet the SD card 2.0 specification.
Therefore, the controller capabilities need to be overridden
to match.
BUG=chrome-os-partner:24423
BRANCH=None
TEST=Built and booted. /sys/kernel/debug/mmc0/ios shows
high speed as maximum timing as well as 3.3V signal voltage.
Change-Id: Ib3824800852376e0f15a70584917d6692087ccfe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179415
The SD card controller can have the capabilities it supports
to be overridden. Add two optional fields to the chip structure
to allow the mainboard to override the SD card controller
capabilities.
BUG=chrome-os-partner:24423
BRANCH=None
TEST=Built and booted. Noted capabilities override console output.
Change-Id: Ibfef8f765b35eeec6da969dd05f5484f8672a7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179414
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The VDAT data was off by 2 bytes when reading it from the
kernel. The reason is that the header did not line up
correctly with actual ACPI code.
BUG=chrome-os-partner:24440
BRANCH=None
TEST=crossystem devsw_cur now returns either 0 or 1 depending
on state.
Change-Id: Ie78599f29cd5daf7da98db5e37fa276d24339f6a
Signed-off-by: Aaron durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179372
Bay Trail has 3 banks of gpios. Therefore, in order to
properly identify a gpio the specific bank number as well
as the GPIO within that bank is needed. The SPI
write-protect GPIO is GPIO 6 within the SUS bank (offset
0x2000).
BUG=chrome-os-partner:24324
BUG=chrome-os-partner:24408
BRANCH=None
TEST=Built and booted. Looked at GPIO sysfs in the
chromeos_acpi directory.
Change-Id: Ic51b5abe3bacf6cf9b6a90cf666f1a63b098a0e3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179195
Install the BL1 and set up the checksum in the Makefile instead of relying on
post processing. Import the exynos checksum script, split it in two and
simplify it significantly. Stop putting the CBFS header in the midst of the
bootblock so that it can be checksummed before CBFS is put together. Stop
saving space for it and leaving an anchor in the bootblock which nobody looks
for.
BUG=None
TEST=Built and booted on pit. Built for snow, but it doesn't boot on ToT so I
couldn't test it more than that.
BRANCH=None
Change-Id: Icbb5a5914ece60b2827433b6dc29d80db996ea6c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179229
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The LPE audio device needs 1MiB of memory for its firmware.
It also has a requirement that the memory needs to be on a
512MiB boundary. Just take 1MiB @ 512MiB for the LPE device.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and analyzed console logs for resources. Also interrogated
registres within the kernel.
Change-Id: I4d9ad5c7b5a2f3eb627b30528d738289278b3a7b
Reviewed-on: https://chromium-review.googlesource.com/179192
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
The Linux kernel driver cannot handle Baytrail legacy GPIOs, so make the
default input GPIO type MMIO.
BUG=chrome-os-partner:24408
TEST=Manual on Rambi. Run "echo 169 > /sys/class/gpio/export; cat
/sys/class/gpio/gpio169/value", verify GPIO value changes based upon mic
jack status.
BRANCH=None
Change-Id: I27870ce8b7ecae9228e06e48c8759409c824c2eb
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179169
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Strengthen PUs on all eMMC pins to fix problems with eMMC not coming up
on certain boards.
BUG=chrome-os-partner:24353
TEST=Manual. Burn FW on board that previously failed to boot eMMC,
verify chromeos can now install + boot from eMMC.
BRANCH=none
Change-Id: I7a9742968b8b8c2c42285ffc21de46aed9c87fb7
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178917
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Rambi 1.5 boards use the native SD card controller on baytrail.
Therefore, enable those signals. The CLK, D*, and CMD pins use
2K pulls as these were shown to not exhibit any errors when
doing reads or writes to a DDR50 sd card.
Note that if a servo is connected on needs to enable the
sd_vref_sel rail to pp1800 as this causes issues with card
detect if it is not set to pp1800.
BUG=chrome-os-partner:24312
BRANCH=None
TEST=Built and booted. Tested sd card read and write works in kernel.
Also noted that write protect detection works as well.
Change-Id: I520e2808acbd8494534fcb710411dbc0e12fc874
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178961
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The enable_resources callback was accidentally populated
with NULL. Make that callback be the generic
pci_dev_enable_resources.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and booted.
Change-Id: I670b51bd9aff6764e9b549287a737b662572cdc7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178960
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The USB VBUS GPIOs on Nyan boards are two-directional: usually the SoC
sets them high or low to enable USB power, but on overcurrent conditions
they get forcefully driven low by the voltage source. To avoid driving
it from two sides, we configure them on the SoC side as tristated input
pins with a pull-up instead.
BUG=None
TEST=Made sure USB devices still get detected.
Change-Id: I423cb312805cbacb651a569ddc1530813b148576
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178914
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
The new IASL is complaining about the PCI memory region not
having consistent base/end/length values because they are
placeholder that are fixed up in the method before returning.
Put in some more valid placeholder values to make it happy.
BUG=chromium:311294
BRANCH=none
TEST=build and boot with IASL 20130117 on rambi
Change-Id: I0e21adcce43deb14d3c2c45787ff8c9efc357c2f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178864
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@google.com>
Rambi has the LPE audio codec connected to PMC_PLT_CLK[0].
Configure it for 25MHz.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and booted. Noted message in console output.
Change-Id: I11297ba951149e5831c65ca70ac7bdbbed113098
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178781
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Add device tree option to determine if the LPE
audio codec has a platform clock signal connected
to it from the SoC. If a frequency is selected the
platform clock number is used to enable the
clock.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and booted rambi with 25MHz option. Probed pin
to audio codec. Noted 25MHz clock.
Change-Id: I67d0d034f30ae1c7ee8269c0aea43e8c92ff868c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178780
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
There are 3 banks of GPIOs that need to be described
with specific _UID and memory/interrupt values.
BUG=chrome-os-partner:24314
BRANCH=none
TEST=build and boot on rambi, check for probed driver:
gpiochip_find_base: found new base at 154
gpiochip_add: registered GPIOs 154 to 255 on device: INT33FC:00
gpiochip_find_base: found new base at 126
gpiochip_add: registered GPIOs 126 to 153 on device: INT33FC:01
gpiochip_find_base: found new base at 82
gpiochip_add: registered GPIOs 82 to 125 on device: INT33FC:02
fed0c000-fed0cfff : INT33FC:00
fed0c000-fed0cfff : INT33FC:00
fed0d000-fed0dfff : INT33FC:01
fed0d000-fed0dfff : INT33FC:01
fed0e000-fed0efff : INT33FC:02
fed0e000-fed0efff : INT33FC:02
Change-Id: I9619e2af4e1ccdf3d7b2e4ae280aadf22e278aeb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178601
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These panel numbers provided by the OEM.
The old display will stop working.
BUG=None
TEST=builds. I'll test when I get a unit.
BRANCH=None
Change-Id: I6020f0c725d44c4b69d5806e0dfc8da125686baf
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177958
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
With microcode 31E MWAIT 0x51 is now C6NS and 0x52 is now C6FS.
BUG=chrome-os-partner:23505
BRANCH=none
TEST=build and boot on rambi, check that C1/C2/C3 are all used now
Change-Id: I8528d808f4082c85d90e2b57747d9f2e2d982b85
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178461
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Some 1.5 boards have a single channel ram configuration.
Accomodate such configs.
BUG=chrome-os-partner:22865
BRANCH=None
TEST=Built and booted ChromeOS.
Change-Id: I513327e47b9211d2dd1ea960d7da671a3773cb91
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178340
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
BUG=chrome-os-partner:24258
TEST=built/booted on Norrin/Nyan1 OK, loaded 3.10 kernel, and
did a shutdown -r. Next boot was OK.
Note that if other regs in the PMIC need to be (re)initialized,
it's a simple matter of adding more entries to the init_reg table.
Change-Id: I8cb4721da90673216f0a771d72c6d81590532837
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/178226
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This adds some delay to allow for the SPI controller to copy data
from the Rx register to the FIFO.
This is intended to complement a similar patch in Depthcharge.
BUG=chrome-os-partner:24215
BRANCH=none
TEST=built and booted on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Idc12f8a835e7e6529724254948684bd05cafdac1
Reviewed-on: https://chromium-review.googlesource.com/177832
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This pin is active low and resets the SOC and TPM. It leaves the memory alone
so that panic info can be discovered by the kernel once the reboot is
complete.
BUG=chrome-os-partner:24098
TEST=With a corresponding change in depthcharge, verified that depthcharge can
reboot the SOC using this GPIO.
BRANCH=None
Change-Id: I101dbb712c458b88213e2254fd1893a1284d1491
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177965
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This print isn't really useful and consumes a lot of time (~13ms)
during copying phases.
BUG=none
BRANCH=none
TEST=Built and booted on Nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I2f32dc097dd3d2b53edd739124f4317f2f91ad71
Reviewed-on: https://chromium-review.googlesource.com/177833
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The AHB burst length was being set to an invalid value. Apparently
this didn't hurt anything, but we may as well set it correctly.
Also, we don't need to explicitly set AHB_SEQ_WRAP since it defaults
to the value we want.
BUG=none
BRANCH=none
TEST=built and booted on Nyan rev. 0 and 1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Iffb9edeb178ab48876f891d0822a24daae93aa8e
Reviewed-on: https://chromium-review.googlesource.com/177564
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch activates -ffunction-sections and -fdata-sections for the
compiler and --gc-sections for the linker. This will strip out all
unused functions and static/global variables from the final binaries and
reduce the amount of data we need to read over SPI.
A quick test with ToT images shows a 2.5k (13%) / 10k (29%) / 12k (28%)
reduction on Nyan and 3k (38%) / 23k (50%) / 13k (29%) on Pit,
respectively for bootblock / romstage / ramstage.
BUG=None
TEST=Made sure Nyan and Pit still boot to kernel.
Change-Id: I052411d4ad190d0395921ac4d4677341fb91568a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177111
This doesn't seem to be truly necessary, but it matches what other drivers do
and might be a good idea for safety's sake.
BUG=chrome-os-partner:24138
TEST=Built and booted on norrin.
BRANCH=None
Change-Id: Ie7c2717e81b2a5dcb831e608eb56347709dc1483
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177638
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
On nyan boards, the hardware flow control pins for the UART aren't used or
connected to anything, but the reset pinmux settings still have them routed
out some of the SOC pins. That can break input over the serial console if the
pin is pulled in the wrong direction.
Also, if the RX line isn't connected to anything, ie if no servo is connected,
then we don't want it to float around and potentially draw power through the
input pin buffering logic. We add a pull up to it so it will go somewhere in
particular if otherwise unattached.
This is generally not a great place to put pinmux configuration because it's
specific to a particular board but this is shared by everything with a
tegra124 in it. It's a good idea to have serial output as soon as possible,
though, and the other serial related pinmux settings were probably put here
before we really understood the complexities and flexibility of the tegra
pinmux. We might want to factor out this part of the serial console config and
delegate it to a hook in the mainboard specific code, or just wait until we
call bootblock_mainboard_init.
BUG=chrome-os-partner:24138
TEST=Built and booted on a peppy based nyan. Before this change serial input
was ignored. After this change, serial input was accepted by both the firmware
and the kernel.
BRANCH=None
Change-Id: Ie5428500aa525a600eb1ff4a81b5cc2805d5cc92
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177637
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Instead of choosing between SDRAM configurations for rev0 nyans and everything
else (currently only rev1), we should create a kconfig for each possible config
and put them inside a "choice" block. That way we can have an arbitrarily large
number of choices without them getting to be hard to manage or accidentally not
being mutually exclusive. This also makes the choice of SDRAM config more
explicit instead of it being implied by what rev you're compiled for.
One tradeoff of this approach is that you need to know which config goes with
which rev. Unfortunately we can't decide using the board ID like we can for
most other things because the BCT is consumed by code we don't control before
any of our own code runs.
We default to the slower config for safety's sake, because it will work on
both boards, and because it's the right config for the norrin which we were
going to transition to soon anyway.
Also, we can eliminate the NYAN_IN_A_PIXEL kconfig variable. Alas, we hardly
knew ye.
BUG=None
TEST=Built and booted on both types of nyan.
BRANCH=None
Change-Id: I9a630189e001e95c740c6741057511bf5939fdbb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177580
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Use the board ID to figure out how to initialize the PMIC instead of using a
config option.
BUG=None
TEST=Built and booted on both types of nyan.
BRANCH=None
Change-Id: I26f735f3c7ba910fd237a1d00d616d3d89b9fbd9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177489
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
We can use that to figure out which revision of nyan we're running on and make
some small adjustments for the differences in hardware.
BUG=None
TEST=Built and booted on both versions of nyan.
BRANCH=None
Change-Id: Iaedbc36dcc8e27b95b1e1ec5687bd9592c49d775
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177488
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This sets the sclk:hclk:pclk ratio to 1:2:2 which allows faster
transfers from peripherals to memory.
Performance-wise this currently decreases ramstage loading time
by about 20ms and payload loading time by 35ms.
BUG=chrome-os-partner:24182
BRANCH=none
TEST=Built and booted on Nyan rev 1 and 0. No longer see long
delays in between bytes when transferring >64 bytes via SPI.
CQ-DEPEND=CL:177578
Change-Id: I5812122bf6312a1ab490945c6e52fa3372e86fc9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177563
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
NCORE pad addresses were wildly wrong due to documentation bugs.
BUG=chrome-os-partner:24179
TEST=Manual on Rambi. Verify display isn't always on. Verify brightness
control now works in Chrome OS.
BRANCH=None.
Change-Id: I464436a58baa4957329c11231c5a866dafd97ce8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177597
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The memory clock set up for the pixel based nyan boards is too fast for the
peppy based boards. We want to use the right config for the right board, so
that needs to be configurable based on what board your targeting.
This CL makes the SDRAM BCT config configurable based on whether your nyan is
in a pixel case, and also adds a slower config for us on norrin.
BUG=None
TEST=Built with settings for each board. Used bct_dump to verify that the
settings matched the current config.
BRANCH=None
Change-Id: Ibf1335ac3c9eb488d3753e41c5c9c40c9eda3d56
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177487
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
It turns out that kconfig will silently ignore settings to a variable that
doesn't have a prompt, meaning that this variable was always off no matter
what the config said.
BUG=None
TEST=Before this change, saw that CONFIG_NYAN_IN_A_PIXEL was always off no
matter how it was set in the config. Afterwards, saw that the value followed
the setting in the config.
BRANCH=None
Change-Id: I6f003c4bc2fbaea013a3f1e328280e64fbe7479d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/177486
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The level shifting between 3.3V and 1.8V for the SERIRQ
signal is not working. Instead use the SERIRQ pad as
a gpio which is used as a direct IRQ signal for the
keyboard interupt.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi. Keyboard works with associated EC change.
CQ-DEPEND=CL:177189
Change-Id: Ifc270ca38207828a6d4711551d4bde9121559cca
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177223
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Some boards need to override which IRQ the i8042 keyboard
controller has its interrupt on instead of the default
IRQ#1. The SIO_EC_PS2K_IRQ macro provides the mainboard
an ability to override the interrupt location.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi using this option. New IRQ is correctly
picked up by kernel allowing keyboard support.
Change-Id: Ic2b222018dfc3aa30e24a31009e832ae0fb7e9cf
Reviewed-on: https://chromium-review.googlesource.com/177222
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(panther port of Ib980100c648ae7472eac6f97e47f8ef3cbe72c7e)
BUG=none
BRANCH=none
TEST=boot tested on Panther
Change-Id: Iedcc107a43be170762d42d515c7e2a16ec395452
Reviewed-on: https://chromium-review.googlesource.com/177474
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@google.com>
Tested-by: Mohammed Habibulla <moch@google.com>
This writes the default value to the register, but it gets rid of
the error that disturbs some of our tests:
ERROR: PNP: 002e.4 70 irq size: 0x0000000001 not assigned
(panther port of Ieab1c776b553c996a7d06e4059110943aaf41338)
BRANCH=none
BUG=chrome-os-partner:23945
TEST=boot test on Panther
Change-Id: Id45c3bdc0d2feaf6f75d984c41d1f6ffef592d4d
Reviewed-on: https://chromium-review.googlesource.com/177468
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@google.com>
Tested-by: Mohammed Habibulla <moch@google.com>
