coreboot-kgpe-d16/src/soc/rockchip/rk3288/timer.c

48 lines
1.4 KiB
C
Raw Normal View History

/*
* This file is part of the coreboot project.
*
* Copyright 2014 Rockchip Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
rk3288: Change all SoC headers to <soc/headername.h> system 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>
2014-10-20 22:14:55 +02:00
#include <arch/io.h>
#include <delay.h>
rk3288: Change all SoC headers to <soc/headername.h> system 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>
2014-10-20 22:14:55 +02:00
#include <soc/timer.h>
#include <stdint.h>
rk3288: Change all SoC headers to <soc/headername.h> system 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>
2014-10-20 22:14:55 +02:00
#include <timer.h>
static uint64_t timer_raw_value(void)
{
uint64_t value0;
uint64_t value1;
value0 = (uint64_t)read32(&timer7_ptr->timer_curr_value0);
value1 = (uint64_t)read32(&timer7_ptr->timer_curr_value1);
value0 = value0 | value1<<32;
return value0;
}
void timer_monotonic_get(struct mono_time *mt)
{
mono_time_set_usecs(mt, timer_raw_value() / clocks_per_usec);
}
timer: Reestablish init_timer(), consolidate timer initialization calls We have known for a while that the old x86 model of calling init_timer() in ramstage doesn't make sense on other archs (and is questionable in general), and finally removed it with CL:219719. However, now timer initialization is completely buried in the platform code, and it's hard to ensure it is done in time to set up timestamps. For three out of four non-x86 SoC vendors we have brought up for now, the timers need some kind of SoC-specific initialization. This patch reintroduces init_timer() as a weak function that can be overridden by platform code. The call in ramstage is restricted to x86 (and should probably eventually be removed from there as well), and other archs should call them at the earliest reasonable point in their bootblock. (Only changing arm for now since arm64 and mips bootblocks are still in very early state and should sync up to features in arm once their requirements are better understood.) This allows us to move timestamp_init() into arch code, so that we can rely on timestamps being available at a well-defined point and initialize our base value as early as possible. (Platforms who know that their timers start at zero can still safely call timestamp_init(0) again from platform code.) BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit. Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234062 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9606 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-08 22:39:14 +01:00
void init_timer(void)
{
write32(TIMER_LOAD_VAL, &timer7_ptr->timer_load_count0);
write32(TIMER_LOAD_VAL, &timer7_ptr->timer_load_count1);
write32(1, &timer7_ptr->timer_ctrl_reg);
}