Pull out the common usb setup utmip functions from t124 into tegra usb.h. These
can be reused for t132 as well.
BUG=chrome-os-partner:31293
BRANCH=None
TEST=Compiles successfully for nyan, big and blaze
Change-Id: Idddd40e409b56875436db6918d05f2889d83870b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 12f12cb30a
Original-Change-Id: I83f83bafad0f52ad651fe5989430f41142803f2b
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/211200
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8927
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The gpio_index_to_port() incorrectly was dividing by
GPIO_PORTS_PER_BANK on a value including the bit number. After
masking off the BANK offset just divide by the number of gpios
in a port to get the port offset.
BUG=chrome-os-partner:29981
BRANCH=None
TEST=Built and ran through to depthcharge. Printed bank, port, and
bit numbers for validation.
Change-Id: I3fbbb90f369bace90e787148a58795b7b1b40c1b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 97e1f830b4
Original-Change-Id: I8bb50e922c9fd7c0a1c247ba95394f6deb9f1533
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210909
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8908
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's helpful to be able to track this information. Therefore
dump it in to the console log.
BRANCH=None
BUG=chrome-os-partner:31126
TEST=Built and ran on rush. Revision information is put out on the
console.
Change-Id: I22e7d222259c1179b90edda6d7807559357f6725
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 18d318331b
Original-Change-Id: Ic95382126a6b8929d0998d1c9adfcbd10e90663f
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210903
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8905
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of sprinkling the pad configuration and pinmux
selection throughout the code allow for a data-driven
initialization sequence. Most of the calls in the
original pinmux functions require 12 bytes per pad
plus the support code. This implementation allows for
4 bytes per pad in addition to the support code.
BUG=chrome-os-partner:29981
TEST=Built and booted into depthcharge on rush.
Change-Id: I22c243a5f9891a97e14b78d8c8064e36adaf50b8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9329c17bba
Original-Change-Id: I3a119b4068e880b74a0a1597f143d7c4e108a6c1
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210833
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8875
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are
- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)
This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.
This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.
The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.
Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.
BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.
Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d
Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209673
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c79ef1c545)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8717
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This macro is controversial for arches where the bits are numbered
MSb first, though we don't support such an arch. We've seen this macro
creep into our tree in different places, so provide it in one place.
Change-Id: I86cd8a16420f34ef31b615aec4e0f7bd3191ca35
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8280
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
In the original fix for the 'Lost arb' we were seeing on
Nyan* during reboot stress testing, I had the name of
BC_TERMINATE's bit setting wrong. Fix this to use the
IMMEDIATE (1) setting. The setting didn't change, just
the name. According to Julius this is the optimal
setting for bus clear in this instance. Also widened
the SCLK_THRESHOLD mask to 8 bits as per spec.
BUG=chrome-os-partner:28323
BRANCH=nyan
TEST=Tested on nyan. Built for nyan and nyan_big.
Original-Change-Id: I19588690924b83431d9f4d3d2eb64f4947849a33
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/206409
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 76e08d0cb0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If187ddf53660feaceab96efe44a3aadad60c43ff
Reviewed-on: http://review.coreboot.org/8152
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This serves as supplemental patch to CL:197732. After clearing bus, we
should also redo controller init (because controller has been reset
before bus clear). On the upper layer, upon receiving error return status,
it should just retry instead of simply call cpu_reset().
BUG=chrome-os-partner:28323
BRANCH=nyan
TEST=Built and tested on nyan and nyan_big.
Original-Change-Id: Ib526bc730cb73ffef8696fc2a6a2769d6e71eb9e
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/202784
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 06f8917c70)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I1d8bc43d730b53fe7f2dad8713831311e96e3984
Reviewed-on: http://review.coreboot.org/8145
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Our tests with the I2C bit clear mechanism (recovering from "lost
arbitration" errors) show that the bit clear hardware does not work
correctly in some situations. When a wedged slave device tries to send
more than one 0-to-1-to-0 transition to the host (e.g. leftover bits
from an aborted read), the controller never transitions the BC_ENABLE
bit back to zero.
This patch adds a long timeout to the bit clear code that waits for
register transitions as a safeguard. This way, We will still eventually
exit the function (probably followed by a reboot). Our tests show that
this will recover from all conditions after at most a few reboots.
BRANCH=nyan
BUG=chrome-os-partner:28323
TEST=Ran wedge_ack and wedge_read tests with software_i2c patch, system
recovered as expected in all cases.
Original-Change-Id: I6c37119130e1240e1ef3a5944582abbcd2e39ff0
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200265
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4c8d0af25c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I600d5c9a8e68719cf8795c083c5fac63f626f5bf
Reviewed-on: http://review.coreboot.org/7948
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch adds I2C emulation in software through raw toggling of the
SDA/SCL lines. Platforms need to provide bindings to toggle their
respective I2C busses for this to work (e.g. by pinmuxing them as GPIOs,
currently only enabled for Tegra).
This is mostly useful as a debugging feature, to drive unusual states on
a bus and closely monitor the device output without the need of a bus
analyzer. It provides a few functions to "wedge" an I2C bus by aborting
a transaction at certain points, which can be used to test if a system
can correctly recover from an ill-timed reboot. However, it can also
dynamically replace the existing I2C transfer functions and drive
some/all I2C transfers on the system, which might be useful if a driver
for the actual I2C controller hardware is not (yet) available.
Based on original code by Doug Anderson <dianders@chromium.org> and
Hung-ying Tyan <tyanh@chromium.org> for the ChromeOS embedded
controller project.
BRANCH=None
BUG=chrome-os-partner:28323
TEST=Spread tegra_software_i2c_init()/tegra_software_i2c_disable()
through the code and see that everything still works.
Original-Change-Id: I9ee7ccbd1efb38206669a35d0c3318af16f8be63
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198791
Original-Reviewed-by: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 8f71503dbb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id6c5f75bb5baaabd62b6b1fc26c2c71d9f1ce682
Reviewed-on: http://review.coreboot.org/7947
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is a fix for the 'Lost arb' we're seeing on Nyan* during
reboot stress testing. It occurs when we are slamming the
default PMIC registers with pmic_write_reg().
Currently, I've only captured this a few times, and the bus
clear seemed to work, as the PMIC writes continued (where
they'd hang the system before bus clear) for a couple of regs,
then it hangs hard, no messages, no 2nd lost arb, etc. So
I've added code to the PMIC write function that will reset the
SoC if any I2C error occurs. That seems to recover OK, i.e. on
the next reboot the PMIC writes all go thru, boot is OK, kernel
loads, etc.
BUG=chrome-os-partner:28323
BRANCH=nyan
TEST=Tested on nyan. Built for nyan and nyan_big.
Original-Change-Id: I1ac5e3023ae22c015105b7f0fb7849663b4aa982
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197732
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
(cherry picked from commit f445127e2d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I584d55b99d65f1e278961db6bdde1845cb01f3bc
Reviewed-on: http://review.coreboot.org/7897
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Enable pinmux clamp function to avoid pinmux conflict.
For pins which are configured to tristate enabled, the inputs to the
controller will be clamped to zero. This can be used to avoid pinmux
conflicts since the tristate bit is set to 1 in the power-on-reset
pinmux setting.
With pinmux clamp enabled, we need to configure all the input pins
to tristate disabled.
BUG=chrome-os-partner:27091
BRANCH=None
TEST=built and booted successfully, display worked fine.
Original-Change-Id: Id79a717f2025c812908c7152d439351208aee8d2
Original-Signed-off-by: Ken Chang <kenc@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/194060
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit c95d6fe798)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I1b23df8b90f83ea2b2c08c4364d90fe71533a5a0
Reviewed-on: http://review.coreboot.org/7775
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This patch adds some documentation to the additional PLL divisor
constraints on the intermediary VCO and CF values that we just found out
about. PLLC divisors for some oscillators had to be adjusted
accordingly.
It also adds a new clock_get_pll_input_khz() function to replace
clock_get_osc_khz() in cases where you want to factor in the built-in
predivider for 38.4 and 48 MHz oscillators.
BUG=None
TEST=Still boots.
Original-Change-Id: Ib6e026dbab9fcc50d6d81a884774ad07c7b0dbc3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/194474
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 3f1f565baf)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I091f42bf952a4b58ef2c30586baa5bf7496fa599
Reviewed-on: http://review.coreboot.org/7768
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The new API is in use in depthcharge and is based around the "i2c_transfer"
function instead of i2c_read and i2c_write. The new function takes an array of
i2c_seg structures which represent each portion of the transfer after a start
bit and before the stop bit. If there's more than one segment, they're
seperated by repeated starts.
Some wrapper functions have also been added which make certain common
operations easy. These include reading or writing a byte from a register or
reading or writing a blob of raw data. The i2c device drivers generally use
these wrappers but can call the i2c_transfer function directly if the need
something different.
The tegra i2c driver was very similar to the one in depthcharge and was simple
to convert. The Exynos 5250 and 5420 drivers were ported from depthcharge and
replace the ones in coreboot. The Exynos 5420 driver was ported from the high
speed portion of the one in coreboot and was straightforward to port back. The
low speed portion and the Exynos 5250 drivers had been transplanted from U-Boot
and were replaced with the depthcharge implementation.
BUG=None
TEST=Built and booted on nyan with and without EFS. Built and booted on, pit
and daisy.
BRANCH=None
Original-Change-Id: I1e98c3fa2560be25444ab3d0394bb214b9d56e93
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193561
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 00c423fb2c)
This cherry-pick required additional changes to the following:
src/cpu/allwinner/a10/twi.c
src/drivers/xpowers/axp209/axp209.c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I691959c66308eeeec219b1bec463b8b365a246d7
Reviewed-on: http://review.coreboot.org/7751
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is the only way to clear the error bits in the controller. Without
clearing them, every future transaction will look like it failed.
BUG=chrome-os-partner:27220
TEST=Built and booted on nyan with the TPM frequency turned up to 400 KHz.
BRANCH=None
Original-Change-Id: Ib654e60ec3039ad9f5f96aa7288d3d877e5c843a
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/191811
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 7b19a09565)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I301b6694cc521601b618973de891e4ed44c6a97d
Reviewed-on: http://review.coreboot.org/7460
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The existing display init functions were translated from a script. The new
code will play the same functions but are cleaner and readable and easier to
be ported to new panel.
BUG=none
TEST=build nyan and boot up kernel.
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Change-Id: Ic9983e57684a03e206efe3731968ec62905f4ee8
Original-Reviewed-on: https://chromium-review.googlesource.com/189518
Original-Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 5998f991ea)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Squashed to pass abuild
nyan: Fix the build for big and blaze.
The display code for the tegra124 was cleaned up recently, but only the nyan
device tree was updated to match the new code, not big's or blaze's. This
change copies nyan's device tree over to those other two boards which will get
them building again. The settings may not be correct, but they'll be no less
correct than they were before. I also updated the copyright date for nyan.
BUG=none
TEST=Built for nyan, nyan_big, nyan_blaze. Booted on nyan_big and verified the
panel wasn't damaged by the new display code or settings.
BRANCH=None
Original-Change-Id: I75055a01f9402b3a9de9a787a9d3e737d25bb515
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/191364
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit ea235f23df)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Icdad74bf2d013c3677e1a3373b8f89fad99f616e
Reviewed-on: http://review.coreboot.org/7454
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Once SECURITY_MODE fuse is burned, JTAG is disabled by default.
To reenable JTAG, besides chip unique id and SecureJtagControl need
to be built into BCT, Jtag enable flag is also needed to be set.
BUG=None
TEST=Burn SECURITY_MODE fuse, build chip specific BCT, coreboot
comes up and jtag hooks up fine.
Original-Change-Id: Ic6b61be2c09b15541400f9766d486a4fcef192a8
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/186031
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ff962b81f4)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I14b496932dbc0ed184a2212a5b33d740e1f34a4e
Reviewed-on: http://review.coreboot.org/7403
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Add some defines and structs that describe what the PWM registers look like.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Original-Change-Id: Ie10589e4cbf5292e543d205ac8a1c6b09a0f76d0
Original-Signed-off-by: Andrew Chew <achew@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/185771
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit fbbd2a5e14)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If4dc40c1dcdf1723e05923e2fea42ccc47766699
Reviewed-on: http://review.coreboot.org/7401
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
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).
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>
(cherry picked from commit cef5fa13c3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6905
Tested-by: build bot (Jenkins)
This uses the packet mode of the controller since that allows transfering more
data at a time.
Change-Id: I8329e5f915123cb55464fc28f7df9f9037b0446d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172402
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4444cd626a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6703
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The pins on tegra are controlled by three different units, the pinmux, the
pin group controls, and the GPIO banks. Each of these units controls some
aspect of the pins, and they layer together and interact in interesting ways.
By default, the GPIOs are configured to pass through the special purpose IO
that the pinmux is configured to and so can be ignored unless a GPIO is needed.
The pinmux controls which special purpose signal passes through, along with
pull ups, downs, and whether the output is tristated. The pingroup controls
change the parameters of a group of pins which all have to do with a related
function unit.
The enum which holds constants related to the pinmux is relatively involved
and may not be entirely complete or correct due to slightly inconsistent,
incomplete, or missing documentation related to the pinmux. Considerable
effort has been made to make it as accurate as possible. It includes a
constant which is the index into the pinmux control registers for that pin,
what each of the functions supported by that pin are, and which GPIO it
corresponds to. The GPIO constant is named after the GPIO and is the pinmux
register index for the pin for that GPIO. That way, when you need to turn on
a GPIO, you can use that constant along with the pinmux manipulating functions
to enable its tristate and pull up/down mode in addition to setting up the
GPIO controls.
Also, while in general I prefer not to use macros or the preprocessor when
writing C code, in this case the set of constants in the enums was too large
and cumbersome to manage without them. Since they're being used to construct
a table in a straightforward way, hopefully their negative aspects will be
minimized.
In addition to the low level functions in each driver, the GPIO code also
includes some high level functions to set up input or output GPIOs since that
will probably be a very common thing to want to do.
Old-Change-Id: I48efa58d1b5520c0367043cef76b6d3a7a18530d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171806
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5cd9f17fe0)
tegra124: Add base address for the pinmux and pingroup registers.
There weren't any constants for the pinmux or pingroup registers in the
address map header.
Old-Change-Id: I52b9042c7506cab0bedd7a734f346cc9fe4ac3fe
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172081
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 79b61016bf)
Squashed two related commits.
Change-Id: Ifeb6085128bd53f0ef5f82c930eda66a2b59499b
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6702
Tested-by: build bot (Jenkins)
Furquan Shaikh