summaryrefslogtreecommitdiff
path: root/src/soc/rockchip/rk3288/soc.c
AgeCommit message (Collapse)Author
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-09-04bootmode: add display_init_required()Aaron Durbin
Some of the Chrome OS boards were directly calling vboot called in some form after contorting around #ifdef preprocessor macros. The reasoning is that Chrome OS doesn't always do display initialization during startup. It's runtime dependent. While this is a requirement that doesn't mean vboot functions should be sprinkled around in the mainboard and chipset code. Instead provide one function, display_init_required(), that provides the policy for determining display initialization action. For Chrome OS devices this function honors vboot_skip_display_init() and all other configurations default to initializing display. Change-Id: I403213e22c0e621e148773597a550addfbaf3f7e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11490 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-07-06veyron*: Kill SKIP_DISPLAY_INIT_HACKDavid Hendricks
Now that we have functioning display code for all platforms, we can just get rid of this ugly hack used on non-Chromebook veyrons. BUG=none BRANCH=none TEST=built for Brain, Rialto, Mickey, Romy Change-Id: Ibe248c7cc74940811345c249d66992d74fe85fe5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9c627b087ba9fc07b4ec4a6d55d2e0203bdd4ff5 Original-Change-Id: I946eddb4e8ce1dbaa20212a2bb417e71a31b2ba3 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/282049 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/10785 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-04-17rk3288: detect sdram size at runtimehuang lin
we use Kconfig define sdram size before, but there may use different sdram size in the same overlay, so we must detect sdram size at runtime now. If we use 4G byte sdram, we can use[0x00000000:0xff000000], since the [0xff000000:0xffffffff] is the register space. BUG=chrome-os-partner:35521 TEST=Boot from mighty BRANCH=None Change-Id: I7a167c268483743c3eaed8b71c7ec545a688270c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ad4f27dd08c467888eee87e3d9c4ab3077751898 Original-Change-Id: Ib32aed50c9cae6db495ff3bab28266de91f3e73b Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/243139 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9734 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17rk3288: Handle framebuffer through memlayout, not the resource systemJulius Werner
We've traditionally tucked the framebuffer at the end of memory (above CBMEM) on ARM and declared it reserved through coreboot's resource allocator. This causes depthcharge to mark this area as reserved in the kernel's device tree, which may be necessary to avoid display corruption on handoff but also wastes space that the OS could use instead. Since rk3288 boards now have proper display shutdown code in depthcharge, keeping the framebuffer memory reserved across the handoff (and thus throughout the lifetime of the system) should no longer be necessary. For now let's just switch the rk3288 implementation to define it through memlayout instead, which is not communicated through the coreboot tables and will get treated as normal memory by depthcharge. Note that this causes it to get wiped in developer/recovery mode, which should not be a problem because that is done in response to VbInit() (long before any images are drawn) and 0 is the default value for a corebootfb anyway (a black pixel). Eventually, we might want to think about adding more memory types to coreboot's resource system (e.g. "reserved until kernel handoff", or something specifically for the frame buffer) to model this situation better, and maybe merge it with memlayout somehow. CQ-DEPEND=CL:239470 BRANCH=veyron BUG=chrome-os-partner:34713 TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes than before (curiously not 0x80000 bytes, I guess there's some alignment waste in the kernel somewhere). Made sure the memory map output from coreboot looks as expected, there's no visible display corruption in developer/recovery mode and the 'cbmem' utility still works. Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2 Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240819 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9732 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17rk3288: Add a config variable hack to skip display initDavid Hendricks
The current display init code causes Brain to crash when trying to allocate resources. This just avoids doing display init if a config variable is set. Once code has been implemented to properly setup different types of displays we can get rid of this hack. BUG=none BRANCH=none TEST=built and booted (to depthcharge) on Brain, compiled for pinky with FEATURES=noclean and ensured config variable is 0 Change-Id: I9a7266c6bff5b7a6eb05b2b21fb65797bee392d6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 804632ca67eaaf4174ca597d83b8923cb9abd1b7 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I04c9e8181c58fa0608fd20776fa8c4798a023474 Original-Reviewed-on: https://chromium-review.googlesource.com/235922 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9720 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10rockchip: support displayhuang lin
Implement VOP and eDP drivers, vop and edp clock configuration, framebuffer allocation and display configuration logic. The eDP driver reads panel EDID to determine panel dimensions and the pixel clock used by the VOP. The pixel clock is generating using the NPLL. BUG=chrome-os-partner:31897 TEST=Booted Veyron Pinky and display normal BRANCH=None Change-Id: I01b5c347a3433a108806aec61aa3a875cab8c129 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e4f863b0b57f2f5293ea8015db86cf7f8acc5853 Original-Change-Id: I61214f55e96bc1dcda9b0f700e5db11e49e5e533 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/219050 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9553 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10gpio: Extend common GPIO header, simplify function namesJulius Werner
We've had gpiolib.h which defines a few common GPIO access functions for a while, but it wasn't really complete. This patch adds the missing gpio_output() function, and also renames the unwieldy gpio_get_in_value() and gpio_set_out_value() to the much easier to handle gpio_get() and gpio_set(). The header is renamed to the simpler gpio.h while we're at it (there was never really anything "lib" about it, and it was presumably just chosen due to the IPQ806x include/ conflict problem that is now resolved). It also moves the definition of gpio_t into SoC-specific code, so that different implementations are free to encode their platform-specific GPIO parameters in those 4 bytes in the most convenient way (such as the rk3288 with a bitfield struct). Every SoC intending to use this common API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most 4 bytes in length. Files accessing the API only need to include <gpio.h> which may pull in additional things (like a gpio_t creation macro) from <soc/gpio.h> on its own. For now the API is still only used on non-x86 SoCs. Whether it makes sense to expand it to x86 as well should be separately evaluated at a later point (by someone who understands those systems better). Also, Exynos retains its old, incompatible GPIO API even though it would be a prime candidate, because it's currently just not worth the effort. BUG=None TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and Veyron_Pinky. Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/220975 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9400 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-09soc: Use DEVICE_NOOP macro formalism over static stub funcEdward O'Callaghan
Change-Id: Ice7e27230010ffc48948f952394e849533f94085 Signed-off-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-on: http://review.coreboot.org/8989 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-08rk3288: Change all SoC headers to <soc/headername.h> systemJulius Werner
This patch is the start of a series to change all non-x86 SoC-specific headers to be included as <soc/header.h> instead of the old <soc/vendor/chip/header.h> or "header.h". It will add an include/soc/ directory under every src/soc/vendor/chip/ and append the .../include/ part of that to the global include path. This matches the usage of <arch/header.h> for architecture-specific headers and had already been done for some headers on Tegra. It has the advantage that a source file which does not know the specific SoC used (e.g. Tegra files common for multiple chips, or a global include file) can still include SoC-specific headers and access macros/types defined there. It also makes the includes for mainboard files more readable, and reduces the chance to pull in a wrong header when copying mainboard sources to use a different-related SoC (e.g. using a Tegra124 mainboard as template for a Tegra132 one). For easier maintainability, every SoC family is modified individually. This patch starts out by changing Rk3288. Also alphabetized headers in affected files since we touch them anyway. BUG=None TEST=Whole series: compared binary images for Daisy, Nyan_Blaze, Rush_Ryu, Storm, Urara and Veyron_Pinky. Confirmed that they are byte-for-byte identical except for timestamps, hashes, and __LINE__ macro replacements. Compile-tested individual patches. Change-Id: I4d74a0c56be278e591a9cf43f93e9900e41f4319 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 4ad8b6d2e0280428aa9742f0f7b723c00857334a Original-Change-Id: I415b8dbe735e572d4ae2cb1df62d66bcce386fff Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/222025 Reviewed-on: http://review.coreboot.org/9349 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-24rk3288: add cpu and chiphuang lin
BUG=chrome-os-partner:29778 TEST=Build coreboot Change-Id: I4c1864171e56a81e8eda95a15ca6a6bc1adc7a70 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 814af4b653432295cb6d7222af4a6e5a8d9dfbf6 Original-Change-Id: I1a986fbc8b3737bae655207dd89865dd39aecf87 Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/209467 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Lin Huang <hl@rock-chips.com> Original-Tested-by: Lin Huang <hl@rock-chips.com> Reviewed-on: http://review.coreboot.org/8866 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)