Re: [PATCH 6/6] kselftest/arm64: Fix check_user_mem test
On 10/26/20 5:42 PM, Vincenzo Frascino wrote:
The check_user_mem test reports the error below because the test
plan is not declared correctly:
# Planned tests != run tests (0 != 4)
Fix the test adding the correct test plan declaration.
This change looks fine and got missed earlier.
Acked by: Amit Daniel Kachhap
Fixes: 4dafc08d0ba4 ("kselftest/arm64: Check mte tagged user address in kernel")
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Gabor Kertesz
Cc: Amit Daniel Kachhap
Signed-off-by: Vincenzo Frascino
---
tools/testing/selftests/arm64/mte/check_user_mem.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/arm64/mte/check_user_mem.c
b/tools/testing/selftests/arm64/mte/check_user_mem.c
index 594e98e76880..4bfa80f2a8c3 100644
--- a/tools/testing/selftests/arm64/mte/check_user_mem.c
+++ b/tools/testing/selftests/arm64/mte/check_user_mem.c
@@ -92,9 +92,13 @@ int main(int argc, char *argv[])
err = mte_default_setup();
if (err)
return err;
+
/* Register signal handlers */
mte_register_signal(SIGSEGV, mte_default_handler);
+ /* Set test plan */
+ ksft_set_plan(4);
+
evaluate_test(check_usermem_access_fault(USE_MMAP, MTE_SYNC_ERR,
MAP_PRIVATE),
"Check memory access from kernel in sync mode, private mapping and
mmap memory\n");
evaluate_test(check_usermem_access_fault(USE_MMAP, MTE_SYNC_ERR,
MAP_SHARED),
Re: [PATCH 3/6] kselftest/arm64: Fix check_child_memory test
On 10/26/20 5:42 PM, Vincenzo Frascino wrote:
The check_child_memory test reports the error below because the test
plan is not declared correctly:
# Planned tests != run tests (0 != 12)
Fix the test adding the correct test plan declaration.
This change is required and got missed earlier.
Acked by: Amit Daniel Kachhap
Fixes: dfe537cf4718 ("kselftest/arm64: Check forked child mte memory
accessibility")
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Gabor Kertesz
Cc: Amit Daniel Kachhap
Signed-off-by: Vincenzo Frascino
---
tools/testing/selftests/arm64/mte/check_child_memory.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/arm64/mte/check_child_memory.c
b/tools/testing/selftests/arm64/mte/check_child_memory.c
index 97bebdecd29e..43bd94f853ba 100644
--- a/tools/testing/selftests/arm64/mte/check_child_memory.c
+++ b/tools/testing/selftests/arm64/mte/check_child_memory.c
@@ -163,6 +163,9 @@ int main(int argc, char *argv[])
mte_register_signal(SIGSEGV, mte_default_handler);
mte_register_signal(SIGBUS, mte_default_handler);
+ /* Set test plan */
+ ksft_set_plan(12);
+
evaluate_test(check_child_memory_mapping(USE_MMAP, MTE_SYNC_ERR,
MAP_PRIVATE),
"Check child anonymous memory with private mapping, precise mode and
mmap memory\n");
evaluate_test(check_child_memory_mapping(USE_MMAP, MTE_SYNC_ERR,
MAP_SHARED),
Re: [PATCH 5/6] kselftest/arm64: Fix check_ksm_options test
On 10/26/20 5:42 PM, Vincenzo Frascino wrote:
The check_ksm_options test reports the error below because the test
plan is not declared correctly:
# Planned tests != run tests (0 != 4)
Fix the test adding the correct test plan declaration.
This change makes sense and got missed earlier.
Acked by: Amit Daniel Kachhap
Fixes: f981d8fa2646 ("kselftest/arm64: Verify KSM page merge for MTE pages")
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Gabor Kertesz
Cc: Amit Daniel Kachhap
Signed-off-by: Vincenzo Frascino
---
tools/testing/selftests/arm64/mte/check_ksm_options.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/arm64/mte/check_ksm_options.c
b/tools/testing/selftests/arm64/mte/check_ksm_options.c
index bc41ae630c86..3b23c4d61d38 100644
--- a/tools/testing/selftests/arm64/mte/check_ksm_options.c
+++ b/tools/testing/selftests/arm64/mte/check_ksm_options.c
@@ -140,6 +140,10 @@ int main(int argc, char *argv[])
/* Register signal handlers */
mte_register_signal(SIGBUS, mte_default_handler);
mte_register_signal(SIGSEGV, mte_default_handler);
+
+ /* Set test plan */
+ ksft_set_plan(4);
+
/* Enable KSM */
mte_ksm_setup();
Re: [PATCH 4/6] kselftest/arm64: Fix check_mmap_options test
On 10/26/20 5:42 PM, Vincenzo Frascino wrote:
The check_mmap_options test reports the error below because the test
plan is not declared correctly:
# Planned tests != run tests (0 != 22)
Fix the test adding the correct test plan declaration.
This change is required and got missed earlier.
Acked by: Amit Daniel Kachhap
Fixes: 53ec81d23213 ("kselftest/arm64: Verify all different mmap MTE options")
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Gabor Kertesz
Cc: Amit Daniel Kachhap
Signed-off-by: Vincenzo Frascino
---
tools/testing/selftests/arm64/mte/check_mmap_options.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/arm64/mte/check_mmap_options.c
b/tools/testing/selftests/arm64/mte/check_mmap_options.c
index 33b13b86199b..a04b12c21ac9 100644
--- a/tools/testing/selftests/arm64/mte/check_mmap_options.c
+++ b/tools/testing/selftests/arm64/mte/check_mmap_options.c
@@ -205,7 +205,11 @@ int main(int argc, char *argv[])
mte_register_signal(SIGBUS, mte_default_handler);
mte_register_signal(SIGSEGV, mte_default_handler);
+ /* Set test plan */
+ ksft_set_plan(22);
+
mte_enable_pstate_tco();
+
evaluate_test(check_anonymous_memory_mapping(USE_MMAP, MTE_SYNC_ERR,
MAP_PRIVATE, TAG_CHECK_OFF),
"Check anonymous memory with private mapping, sync error mode, mmap memory
and tag check off\n");
evaluate_test(check_file_memory_mapping(USE_MPROTECT, MTE_SYNC_ERR,
MAP_PRIVATE, TAG_CHECK_OFF),
Re: [PATCH 2/6] kselftest/arm64: Fix check_tags_inclusion test
On 10/26/20 5:42 PM, Vincenzo Frascino wrote:
The check_tags_inclusion test reports the error below because the test
plan is not declared correctly:
# Planned tests != run tests (0 != 4)
Fix the test adding the correct test plan declaration.
This change is required and got missed earlier.
Acked by: Amit Daniel Kachhap
Fixes: f3b2a26ca78d ("kselftest/arm64: Verify mte tag inclusion via prctl")
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Gabor Kertesz
Cc: Amit Daniel Kachhap
Signed-off-by: Vincenzo Frascino
---
tools/testing/selftests/arm64/mte/check_tags_inclusion.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/arm64/mte/check_tags_inclusion.c
b/tools/testing/selftests/arm64/mte/check_tags_inclusion.c
index 94d245a0ed56..deaef1f61076 100644
--- a/tools/testing/selftests/arm64/mte/check_tags_inclusion.c
+++ b/tools/testing/selftests/arm64/mte/check_tags_inclusion.c
@@ -170,6 +170,9 @@ int main(int argc, char *argv[])
/* Register SIGSEGV handler */
mte_register_signal(SIGSEGV, mte_default_handler);
+ /* Set test plan */
+ ksft_set_plan(4);
+
evaluate_test(check_single_included_tags(USE_MMAP, MTE_SYNC_ERR),
"Check an included tag value with sync mode\n");
evaluate_test(check_multiple_included_tags(USE_MMAP, MTE_SYNC_ERR),
Re: [PATCH 1/6] kselftest/arm64: Fix check_buffer_fill test
On 10/26/20 5:42 PM, Vincenzo Frascino wrote:
The check_buffer_fill test reports the error below because the test
plan is not declared correctly:
# Planned tests != run tests (0 != 20)
Fix the test adding the correct test plan declaration.
This change is required and got missed earlier.
Acked by: Amit Daniel Kachhap
Fixes: e9b60476bea0 ("kselftest/arm64: Add utilities and a test to validate mte
memory")
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Gabor Kertesz
Cc: Amit Daniel Kachhap
Signed-off-by: Vincenzo Frascino
---
tools/testing/selftests/arm64/mte/check_buffer_fill.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/arm64/mte/check_buffer_fill.c
b/tools/testing/selftests/arm64/mte/check_buffer_fill.c
index 242635d79035..c9fa141ebdcc 100644
--- a/tools/testing/selftests/arm64/mte/check_buffer_fill.c
+++ b/tools/testing/selftests/arm64/mte/check_buffer_fill.c
@@ -417,6 +417,9 @@ int main(int argc, char *argv[])
/* Register SIGSEGV handler */
mte_register_signal(SIGSEGV, mte_default_handler);
+ /* Set test plan */
+ ksft_set_plan(20);
+
/* Buffer by byte tests */
evaluate_test(check_buffer_by_byte(USE_MMAP, MTE_SYNC_ERR),
"Check buffer correctness by byte with sync err mode and mmap
memory\n");
Re: [PATCH 6/6] kselftest/arm64: Check mte tagged user address in kernel
On 9/22/20 4:11 PM, Catalin Marinas wrote:
On Tue, Sep 01, 2020 at 02:57:19PM +0530, Amit Daniel Kachhap wrote:
Add a testcase to check that user address with valid/invalid
mte tag works in kernel mode. This test verifies the kernel API's
__arch_copy_from_user/__arch_copy_to_user works by considering
if the user pointer has valid/invalid allocation tags.
In MTE sync mode a SIGSEV fault is generated if a user memory
with invalid tag is accessed in kernel. In async mode no such
fault occurs.
We don't generate a SIGSEGV for faults in the uaccess routines. The
kernel simply returns less copied bytes than what was requested or -1
and setting errno.
ok. I will update in the next iteration.
BTW, Qemu has a bug and it reports the wrong exception class (lower
DABT) for a tag check fault while in the uaccess routines, leading to
kernel panic (bad mode in synchronous abort handler).
Yes I am also seeing this.
+static int check_usermem_access_fault(int mem_type, int mode, int mapping)
+{
+ int fd, ret, i, err;
+ char val = 'A';
+ size_t len, read_len;
+ void *ptr, *ptr_next;
+ bool fault;
+
+ len = 2 * page_sz;
+ err = KSFT_FAIL;
+ /*
+* Accessing user memory in kernel with invalid tag should fault in sync
+* mode but may not fault in async mode as per the implemented MTE
+* support in Arm64 kernel.
+*/
+ if (mode == MTE_ASYNC_ERR)
+ fault = false;
+ else
+ fault = true;
+ mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG);
+ fd = create_temp_file();
+ if (fd == -1)
+ return KSFT_FAIL;
+ for (i = 0; i < len; i++)
+ write(fd, , sizeof(val));
+ lseek(fd, 0, 0);
+ ptr = mte_allocate_memory(len, mem_type, mapping, true);
+ if (check_allocated_memory(ptr, len, mem_type, true) != KSFT_PASS) {
+ close(fd);
+ return KSFT_FAIL;
+ }
+ mte_initialize_current_context(mode, (uintptr_t)ptr, len);
+ /* Copy from file into buffer with valid tag */
+ read_len = read(fd, ptr, len);
+ ret = errno;
My reading of the man page is that errno is set only if read() returns
-1.
Yes. The checks should be optimized here.
+ mte_wait_after_trig();
+ if ((cur_mte_cxt.fault_valid == true) || ret == EFAULT || read_len <
len)
+ goto usermem_acc_err;
+ /* Verify same pattern is read */
+ for (i = 0; i < len; i++)
+ if (*(char *)(ptr + i) != val)
+ break;
+ if (i < len)
+ goto usermem_acc_err;
+
+ /* Tag the next half of memory with different value */
+ ptr_next = (void *)((unsigned long)ptr + page_sz);
+ ptr_next = mte_insert_tags(ptr_next, page_sz);
+ if (!ptr_next)
+ goto usermem_acc_err;
+ lseek(fd, 0, 0);
+ /* Copy from file into buffer with invalid tag */
+ read_len = read(fd, ptr, len);
+ ret = errno;
+ mte_wait_after_trig();
+ if ((fault == true) &&
Nitpick: just use "if (fault &&), it's a bool already.
ok.
+ (cur_mte_cxt.fault_valid == true || ret == EFAULT || read_len <
len)) {
+ err = KSFT_PASS;
+ } else if ((fault == false) &&
+ (cur_mte_cxt.fault_valid == false && read_len == len)) {
Same here, !fault, !cur_mte_cxt.fault_valid.
ok.
Re: [PATCH v2 1/4] kselftests/arm64: add a basic Pointer Authentication test
Hi Boyan,
On 8/31/20 4:34 PM, Boyan Karatotev wrote:
PAuth signs and verifies return addresses on the stack. It does so by
inserting a Pointer Authentication code (PAC) into some of the unused top
bits of an address. This is achieved by adding paciasp/autiasp instructions
at the beginning and end of a function.
This feature is partially backwards compatible with earlier versions of the
ARM architecture. To coerce the compiler into emitting fully backwards
compatible code the main file is compiled to target an earlier ARM version.
This allows the tests to check for the feature and print meaningful error
messages instead of crashing.
Add a test to verify that corrupting the return address results in a
SIGSEGV on return.
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Reviewed-by: Vincenzo Frascino
Reviewed-by: Amit Daniel Kachhap
Signed-off-by: Boyan Karatotev
---
tools/testing/selftests/arm64/Makefile| 2 +-
[...]
+
+/* check that a corrupted PAC results in SIGSEGV */
+TEST_SIGNAL(corrupt_pac, SIGSEGV)
+{
+ ASSERT_PAUTH_ENABLED();
+
+ pac_corruptor();
With 8.6-Pauth extension merged in arm tree [1]. It makes sense to
verify PAC corruption for both SIGSEGV and SIGILL signals.
Code something like below handles both the cases.
---
int exec_sign_all(struct signatures *signed_vals, size_t val)
@@ -187,12 +188,29 @@ int exec_sign_all(struct signatures *signed_vals,
size_t val)
return 0;
}
-/* check that a corrupted PAC results in SIGSEGV */
-TEST_SIGNAL(corrupt_pac, SIGSEGV)
+sigjmp_buf jmpbuf;
+void pac_signal_handler(int signum, siginfo_t *si, void *uc)
{
- ASSERT_PAUTH_ENABLED();
+ if (signum == SIGSEGV || signum == SIGILL) {
+ siglongjmp(jmpbuf, 1);
+ }
+}
+
+/* check that a corrupted PAC results in SIGSEGV or SIGILL */
+TEST(corrupt_pac)
+{
+ struct sigaction sa;
- pac_corruptor();
+ ASSERT_PAUTH_ENABLED();
+ if (sigsetjmp(jmpbuf, 1) == 0) {
+ sa.sa_sigaction = pac_signal_handler;
+ sa.sa_flags = SA_SIGINFO;
+ sigemptyset(_mask);
+ sigaction(SIGSEGV, , NULL);
+ sigaction(SIGILL, , NULL);
+ pac_corruptor();
+ ASSERT_TRUE(0) TH_LOG("SIGSEGV/SIGILL signal did not
occur");
+ }
}
/*
@@ -265,7 +283,7 @@ TEST(single_thread_different_keys)
tmp = n_same_single_set(_vals, nkeys);
---
Thanks,
Amit Daniel
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/ptrauth
Regards,
Amit Daniel
+}
+
+TEST_HARNESS_MAIN
[...]
Re: [PATCH 4/4] kselftests/arm64: add PAuth tests for single threaded consistency and key uniqueness
Hi,
On 8/28/20 6:46 PM, Boyan Karatotev wrote:
PAuth adds 5 different keys that can be used to sign addresses.
Add a test that verifies that the kernel initializes them uniquely and
preserves them across context switches.
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Boyan Karatotev
---
tools/testing/selftests/arm64/pauth/pac.c | 116 ++
1 file changed, 116 insertions(+)
diff --git a/tools/testing/selftests/arm64/pauth/pac.c
b/tools/testing/selftests/arm64/pauth/pac.c
index 16dea47b11c7..718f49adc275 100644
--- a/tools/testing/selftests/arm64/pauth/pac.c
+++ b/tools/testing/selftests/arm64/pauth/pac.c
@@ -1,10 +1,13 @@
// SPDX-License-Identifier: GPL-2.0
// Copyright (C) 2020 ARM Limited
+#define _GNU_SOURCE
+
#include
#include
#include
#include
+#include
#include "../../kselftest_harness.h"
#include "helper.h"
@@ -21,6 +24,7 @@
* The VA space size is 48 bits. Bigger is opt-in.
*/
#define PAC_MASK (~0xff80)
+#define ARBITRARY_VALUE (0x1234)
#define ASSERT_PAUTH_ENABLED() \
do { \
unsigned long hwcaps = getauxval(AT_HWCAP); \
@@ -66,13 +70,36 @@ int are_same(struct signatures *old, struct signatures
*new, int nkeys)
return res;
}
+int are_unique(struct signatures *sign, int nkeys)
+{
+ size_t vals[nkeys];
+
+ vals[0] = sign->keyia & PAC_MASK;
+ vals[1] = sign->keyib & PAC_MASK;
+ vals[2] = sign->keyda & PAC_MASK;
+ vals[3] = sign->keydb & PAC_MASK;
+
+ if (nkeys >= 4)
+ vals[4] = sign->keyg & PAC_MASK;
+
+ for (int i = 0; i < nkeys - 1; i++) {
+ for (int j = i + 1; j < nkeys; j++) {
+ if (vals[i] == vals[j])
+ return 0;
+ }
+ }
+ return 1;
+}
+
int exec_sign_all(struct signatures *signed_vals, size_t val)
{
int new_stdin[2];
int new_stdout[2];
int status;
+ int i;
ssize_t ret;
pid_t pid;
+ cpu_set_t mask;
ret = pipe(new_stdin);
if (ret == -1) {
@@ -86,6 +113,20 @@ int exec_sign_all(struct signatures *signed_vals, size_t
val)
return -1;
}
+ /*
+* pin this process and all its children to a single CPU, so it can also
+* guarantee a context switch with its child
+*/
+ sched_getaffinity(0, sizeof(mask), );
+
+ for (i = 0; i < sizeof(cpu_set_t); i++)
+ if (CPU_ISSET(i, ))
+ break;
+
+ CPU_ZERO();
+ CPU_SET(i, );
+ sched_setaffinity(0, sizeof(mask), );
+
pid = fork();
// child
if (pid == 0) {
@@ -192,6 +233,38 @@ TEST(pac_instructions_not_nop_generic)
ASSERT_NE(0, keyg) TH_LOG("keyg instructions did nothing");
}
+TEST(single_thread_unique_keys)
+{
+ int unique = 0;
+ int nkeys = NKEYS;
+ struct signatures signed_vals;
+ unsigned long hwcaps = getauxval(AT_HWCAP);
+
+ /* generic and data key instructions are not in NOP space. This
prevents a SIGILL */
+ ASSERT_NE(0, hwcaps & HWCAP_PACA) TH_LOG("PAUTH not enabled");
+ if (!(hwcaps & HWCAP_PACG)) {
+ TH_LOG("WARNING: Generic PAUTH not enabled. Skipping generic key
checks");
+ nkeys = NKEYS - 1;
+ }
+
+ /*
+* The PAC field is up to 7 bits. Even with unique keys there is about
+* 5% chance for a collision. This chance rapidly increases the fewer
+* bits there are, a comparison of the keys directly will be more
Can you please reframe the above sentence as it is not clear.
The other changes look fine to me so please free to add,
Reviewed-by: Amit Daniel Kachhap
//Amit
+* reliable All signed values need to be unique at least once out of n
+* attempts to be certain that the keys are unique
+*/
+ for (int i = 0; i < PAC_COLLISION_ATTEMPTS; i++) {
+ if (nkeys == NKEYS)
+ sign_all(_vals, i);
+ else
+ sign_specific(_vals, i);
+ unique |= are_unique(_vals, nkeys);
+ }
+
+ ASSERT_EQ(1, unique) TH_LOG("keys clashed every time");
+}
+
/*
* fork() does not change keys. Only exec() does so call a worker program.
* Its only job is to sign a value and report back the resutls
@@ -227,5 +300,48 @@ TEST(exec_unique_keys)
ASSERT_EQ(1, different) TH_LOG("exec() did not change keys");
}
+TEST(context_switch_keep_keys)
+{
+ int ret;
+ struct signatures trash;
+ struct signatures before;
+ struct signatures after;
+
+ ASSERT_PAUTH_ENABLED();
+
+ sign_specific(, ARBITRARY_VALUE);
+
+ /* will context switch with a process with different keys at least once
*/
+ ret = exec_sign_all(, ARBITRARY_VALUE);
+ ASSERT_EQ(0, ret) TH_LOG("failed to run worker");
+
+ sign_specific(,
Re: [PATCH 3/4] kselftests/arm64: add PAuth test for whether exec() changes keys
On 8/28/20 6:46 PM, Boyan Karatotev wrote: Kernel documentation states that it will change PAuth keys on exec() calls. Verify that all keys are correctly switched to new ones. Cc: Shuah Khan Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Boyan Karatotev The changes look fine so, Reviewed-by: Amit Daniel Kachhap --- tools/testing/selftests/arm64/pauth/Makefile | 4 + .../selftests/arm64/pauth/exec_target.c | 35 + tools/testing/selftests/arm64/pauth/helper.h | 10 ++ tools/testing/selftests/arm64/pauth/pac.c | 148 ++ 4 files changed, 197 insertions(+) create mode 100644 tools/testing/selftests/arm64/pauth/exec_target.c diff --git a/tools/testing/selftests/arm64/pauth/Makefile b/tools/testing/selftests/arm64/pauth/Makefile index a017d1c8dd58..2e237b21ccf6 100644 --- a/tools/testing/selftests/arm64/pauth/Makefile +++ b/tools/testing/selftests/arm64/pauth/Makefile @@ -5,6 +5,7 @@ CFLAGS += -mbranch-protection=pac-ret
Re: [PATCH 2/4] kselftests/arm64: add nop checks for PAuth tests
On 8/28/20 6:46 PM, Boyan Karatotev wrote:
PAuth adds sign/verify controls to enable and disable groups of
instructions in hardware for compatibility with libraries that do not
implement PAuth. The kernel always enables them if it detects PAuth.
Add a test that checks that each group of instructions is enabled, if the
kernel reports PAuth as detected.
Note: For groups, for the purpose of this patch, we intend instructions
that use a certain key.
Cc: Shuah Khan
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Boyan Karatotev
The changes look fine so please free to add,
Reviewed-by: Amit Daniel Kachhap
---
.../testing/selftests/arm64/pauth/.gitignore | 1 +
tools/testing/selftests/arm64/pauth/Makefile | 7 ++-
tools/testing/selftests/arm64/pauth/helper.c | 41 +++
tools/testing/selftests/arm64/pauth/helper.h | 10
tools/testing/selftests/arm64/pauth/pac.c | 51 +++
5 files changed, 108 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/arm64/pauth/helper.c
diff --git a/tools/testing/selftests/arm64/pauth/.gitignore
b/tools/testing/selftests/arm64/pauth/.gitignore
index b557c916720a..155137d92722 100644
--- a/tools/testing/selftests/arm64/pauth/.gitignore
+++ b/tools/testing/selftests/arm64/pauth/.gitignore
@@ -1 +1,2 @@
+exec_target
pac
diff --git a/tools/testing/selftests/arm64/pauth/Makefile
b/tools/testing/selftests/arm64/pauth/Makefile
index 785c775e5e41..a017d1c8dd58 100644
--- a/tools/testing/selftests/arm64/pauth/Makefile
+++ b/tools/testing/selftests/arm64/pauth/Makefile
@@ -4,7 +4,7 @@
CFLAGS += -mbranch-protection=pac-ret
TEST_GEN_PROGS := pac
-TEST_GEN_FILES := pac_corruptor.o
+TEST_GEN_FILES := pac_corruptor.o helper.o
include ../../lib.mk
@@ -13,10 +13,13 @@ include ../../lib.mk
$(OUTPUT)/pac_corruptor.o: pac_corruptor.S
$(CC) -c $^ -o $@ $(CFLAGS) -march=armv8.3-a
+$(OUTPUT)/helper.o: helper.c
+ $(CC) -c $^ -o $@ $(CFLAGS) -march=armv8.3-a
+
# when -mbranch-protection is enabled and the target architecture is ARMv8.3
or
# greater, gcc emits pac* instructions which are not in HINT NOP space,
# preventing the tests from occurring at all. Compile for ARMv8.2 so tests can
# run on earlier targets and print a meaningful error messages
-$(OUTPUT)/pac: pac.c $(OUTPUT)/pac_corruptor.o
+$(OUTPUT)/pac: pac.c $(OUTPUT)/pac_corruptor.o $(OUTPUT)/helper.o
$(CC) $^ -o $@ $(CFLAGS) -march=armv8.2-a
diff --git a/tools/testing/selftests/arm64/pauth/helper.c b/tools/testing/selftests/arm64/pauth/helper.c
new file mode 100644
index ..8619afb16124
--- /dev/null
+++ b/tools/testing/selftests/arm64/pauth/helper.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2020 ARM Limited
+
+#include "helper.h"
+
+
+size_t keyia_sign(size_t ptr)
+{
+ asm volatile("paciza %0" : "+r" (ptr));
+ return ptr;
+}
+
+size_t keyib_sign(size_t ptr)
+{
+ asm volatile("pacizb %0" : "+r" (ptr));
+ return ptr;
+}
+
+size_t keyda_sign(size_t ptr)
+{
+ asm volatile("pacdza %0" : "+r" (ptr));
+ return ptr;
+}
+
+size_t keydb_sign(size_t ptr)
+{
+ asm volatile("pacdzb %0" : "+r" (ptr));
+ return ptr;
+}
+
+size_t keyg_sign(size_t ptr)
+{
+ /* output is encoded in the upper 32 bits */
+ size_t dest = 0;
+ size_t modifier = 0;
+
+ asm volatile("pacga %0, %1, %2" : "=r" (dest) : "r" (ptr), "r"
(modifier));
+
+ return dest;
+}
+
diff --git a/tools/testing/selftests/arm64/pauth/helper.h
b/tools/testing/selftests/arm64/pauth/helper.h
index f777f88acf0a..b3cf709e249d 100644
--- a/tools/testing/selftests/arm64/pauth/helper.h
+++ b/tools/testing/selftests/arm64/pauth/helper.h
@@ -4,7 +4,17 @@
#ifndef _HELPER_H_
#define _HELPER_H_
+#include
+
+
void pac_corruptor(void);
+/* PAuth sign a value with key ia and modifier value 0 */
+size_t keyia_sign(size_t val);
+size_t keyib_sign(size_t val);
+size_t keyda_sign(size_t val);
+size_t keydb_sign(size_t val);
+size_t keyg_sign(size_t val);
+
#endif
diff --git a/tools/testing/selftests/arm64/pauth/pac.c b/tools/testing/selftests/arm64/pauth/pac.c
index ed445050f621..cdbffa8bf61e 100644
--- a/tools/testing/selftests/arm64/pauth/pac.c
+++ b/tools/testing/selftests/arm64/pauth/pac.c
@@ -12,12 +12,25 @@
* future version of the arm architecture
*/
+#define PAC_COLLISION_ATTEMPTS 10
+/*
+ * The kernel sets TBID by default. So bits 55 and above should remain
+ * untouched no matter what.
+ * The VA space size is 48 bits. Bigger is opt-in.
+ */
+#define PAC_MASK (~0xff80)
#define ASSERT_PAUTH_ENABLED() \
do { \
unsigned long hwcaps = getauxval(AT_HWCAP); \
/* data key instructions are not in NOP space. This prevents a SIGILL
*/ \
ASSERT_NE(0, hwcaps & HWCAP_PACA) TH_LOG("PAUTH not enabled"); \
} while (0)
+#define ASSERT_GENERIC_PAUTH_ENABLED() \
+do { \
+ unsigned long
Re: [PATCH 1/4] kselftests/arm64: add a basic Pointer Authentication test
Hi Boyan, On 8/28/20 6:46 PM, Boyan Karatotev wrote: PAuth signs and verifies return addresses on the stack. It does so by inserting a Pointer Authentication code (PAC) into some of the unused top bits of an address. This is achieved by adding paciasp/autiasp instructions at the beginning and end of a function. This feature is partially backwards compatible with earlier versions of the ARM architecture. To coerce the compiler into emitting fully backwards compatible code the main file is compiled to target an earlier ARM version. This allows the tests to check for the feature and print meaningful error messages instead of crashing. Add a test to verify that corrupting the return address results in a SIGSEGV on return. Cc: Shuah Khan Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Boyan Karatotev --- tools/testing/selftests/arm64/Makefile| 2 +- .../testing/selftests/arm64/pauth/.gitignore | 1 + tools/testing/selftests/arm64/pauth/Makefile | 22 tools/testing/selftests/arm64/pauth/helper.h | 10 ++ tools/testing/selftests/arm64/pauth/pac.c | 32 + .../selftests/arm64/pauth/pac_corruptor.S | 36 +++ 6 files changed, 102 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/arm64/pauth/.gitignore create mode 100644 tools/testing/selftests/arm64/pauth/Makefile create mode 100644 tools/testing/selftests/arm64/pauth/helper.h create mode 100644 tools/testing/selftests/arm64/pauth/pac.c create mode 100644 tools/testing/selftests/arm64/pauth/pac_corruptor.S diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile index 93b567d23c8b..525506fd97b9 100644 --- a/tools/testing/selftests/arm64/Makefile +++ b/tools/testing/selftests/arm64/Makefile @@ -4,7 +4,7 @@ ARCH ?= $(shell uname -m 2>/dev/null || echo not) ifneq (,$(filter $(ARCH),aarch64 arm64)) -ARM64_SUBTARGETS ?= tags signal +ARM64_SUBTARGETS ?= tags signal pauth else ARM64_SUBTARGETS := endif diff --git a/tools/testing/selftests/arm64/pauth/.gitignore b/tools/testing/selftests/arm64/pauth/.gitignore new file mode 100644 index ..b557c916720a --- /dev/null +++ b/tools/testing/selftests/arm64/pauth/.gitignore @@ -0,0 +1 @@ +pac diff --git a/tools/testing/selftests/arm64/pauth/Makefile b/tools/testing/selftests/arm64/pauth/Makefile new file mode 100644 index ..785c775e5e41 --- /dev/null +++ b/tools/testing/selftests/arm64/pauth/Makefile @@ -0,0 +1,22 @@ +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2020 ARM Limited + +CFLAGS += -mbranch-protection=pac-ret There is no CFLAGS validation present which may give error with non supported compiler. Can you add a check something like, +#check if the compiler works well +pauth_cc_support := $(shell if ($(CC) $(CFLAGS) -march=armv8.3-a -E -x c /dev/null -o /dev/null 2>&1) then echo "1"; fi) + +ifeq ($(pauth_cc_support),1) TEST_GEN_PROGS := pac TEST_GEN_FILES := pac_corruptor.o +endif include ../../lib.mk +ifeq ($(pauth_cc_support),1) # pac* and aut* instructions are not available on architectures berfore # ARMv8.3. Therefore target ARMv8.3 wherever they are used directly $(OUTPUT)/pac_corruptor.o: pac_corruptor.S @@ -19,4 +25,4 @@ $(OUTPUT)/pac_corruptor.o: pac_corruptor.S # run on earlier targets and print a meaningful error messages $(OUTPUT)/pac: pac.c $(OUTPUT)/pac_corruptor.o $(CC) $^ -o $@ $(CFLAGS) -march=armv8.2-a - +endif + +TEST_GEN_PROGS := pac +TEST_GEN_FILES := pac_corruptor.o + +include ../../lib.mk + +# pac* and aut* instructions are not available on architectures berfore +# ARMv8.3. Therefore target ARMv8.3 wherever they are used directly +$(OUTPUT)/pac_corruptor.o: pac_corruptor.S + $(CC) -c $^ -o $@ $(CFLAGS) -march=armv8.3-a + +# when -mbranch-protection is enabled and the target architecture is ARMv8.3 or +# greater, gcc emits pac* instructions which are not in HINT NOP space, +# preventing the tests from occurring at all. Compile for ARMv8.2 so tests can +# run on earlier targets and print a meaningful error messages +$(OUTPUT)/pac: pac.c $(OUTPUT)/pac_corruptor.o + $(CC) $^ -o $@ $(CFLAGS) -march=armv8.2-a + diff --git a/tools/testing/selftests/arm64/pauth/helper.h b/tools/testing/selftests/arm64/pauth/helper.h new file mode 100644 index ..f777f88acf0a --- /dev/null +++ b/tools/testing/selftests/arm64/pauth/helper.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* Copyright (C) 2020 ARM Limited */ + +#ifndef _HELPER_H_ +#define _HELPER_H_ + +void pac_corruptor(void); + +#endif + Please delete extra line at end of file here and other places too. Other changes look fine for me. After the suggested changes please free to add, Reviewed-by: Amit Daniel Kachhap Thanks, Amit Daniel diff --git a/tools/testing/selftests/arm64/pauth/pac.c b/tools/testing/selftests/arm64/pauth/pac.c new file mode 100644 index ..ed445050f621
Re: [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
Hi Bhupesh,
On 5/14/20 12:22 AM, Bhupesh Sharma wrote:
vabits_actual variable on arm64 indicates the actual VA space size,
and allows a single binary to support both 48-bit and 52-bit VA
spaces.
If the ARMv8.2-LVA optional feature is present, and we are running
with a 64KB page size; then it is possible to use 52-bits of address
space for both userspace and kernel addresses. However, any kernel
binary that supports 52-bit must also be able to fall back to 48-bit
at early boot time if the hardware feature is not present.
Since TCR_EL1.T1SZ indicates the size offset of the memory region
addressed by TTBR1_EL1 (and hence can be used for determining the
vabits_actual value) it makes more sense to export the same in
vmcoreinfo rather than vabits_actual variable, as the name of the
variable can change in future kernel versions, but the architectural
constructs like TCR_EL1.T1SZ can be used better to indicate intended
specific fields to user-space.
User-space utilities like makedumpfile and crash-utility, need to
read this value from vmcoreinfo for determining if a virtual
address lies in the linear map range.
While at it also add documentation for TCR_EL1.T1SZ variable being
added to vmcoreinfo.
It indicates the size offset of the memory region addressed by TTBR1_EL1
Cc: James Morse
Cc: Mark Rutland
Cc: Will Deacon
Cc: Steve Capper
Cc: Catalin Marinas
Cc: Ard Biesheuvel
Cc: Dave Anderson
Cc: Kazuhito Hagio
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: ke...@lists.infradead.org
Tested-by: John Donnelly
Signed-off-by: Bhupesh Sharma
I tested this for both 48 and 52 VA. The dump log looks fine with the
crash tool link provided by you so,
Tested-by: Amit Daniel Kachhap
Also the code changes/documentation looks fine to me with a minor
comments below,
Reviewed-by: Amit Daniel Kachhap
---
Documentation/admin-guide/kdump/vmcoreinfo.rst | 11 +++
arch/arm64/include/asm/pgtable-hwdef.h | 1 +
arch/arm64/kernel/crash_core.c | 10 ++
3 files changed, 22 insertions(+)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 2a632020f809..2baad0bfb09d 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -404,6 +404,17 @@ KERNELPACMASK
The mask to extract the Pointer Authentication Code from a kernel virtual
address.
+TCR_EL1.T1SZ
+
+
+Indicates the size offset of the memory region addressed by TTBR1_EL1.
+The region size is 2^(64-T1SZ) bytes.
+
+TTBR1_EL1 is the table base address register specified by ARMv8-A
+architecture which is used to lookup the page-tables for the Virtual
+addresses in the higher VA range (refer to ARMv8 ARM document for
+more details).
+
arm
===
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index 6bf5e650da78..a1861af97ac9 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -216,6 +216,7 @@
#define TCR_TxSZ(x) (TCR_T0SZ(x) | TCR_T1SZ(x))
#define TCR_TxSZ_WIDTH6
#define TCR_T0SZ_MASK (((UL(1) << TCR_TxSZ_WIDTH) - 1) <<
TCR_T0SZ_OFFSET)
+#define TCR_T1SZ_MASK (((UL(1) << TCR_TxSZ_WIDTH) - 1) <<
TCR_T1SZ_OFFSET)
#define TCR_EPD0_SHIFT 7
#define TCR_EPD0_MASK (UL(1) << TCR_EPD0_SHIFT)
diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c
index 1f646b07e3e9..314391a156ee 100644
--- a/arch/arm64/kernel/crash_core.c
+++ b/arch/arm64/kernel/crash_core.c
@@ -7,6 +7,14 @@
#include
#include
#include
+#include
Nit: May be you forgot to include here as suggested by
James in v5.
Cheers,
Amit
+
+static inline u64 get_tcr_el1_t1sz(void);
+
+static inline u64 get_tcr_el1_t1sz(void)
+{
+ return (read_sysreg(tcr_el1) & TCR_T1SZ_MASK) >> TCR_T1SZ_OFFSET;
+}
void arch_crash_save_vmcoreinfo(void)
{
@@ -16,6 +24,8 @@ void arch_crash_save_vmcoreinfo(void)
kimage_voffset);
vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
PHYS_OFFSET);
+ vmcoreinfo_append_str("NUMBER(TCR_EL1_T1SZ)=0x%llx\n",
+ get_tcr_el1_t1sz());
vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());
vmcoreinfo_append_str("NUMBER(KERNELPACMASK)=0x%llx\n",
system_supports_address_auth() ?
Re: [PATCH v2 1/2] arm64/crash_core: Export KERNELPACMASK in vmcoreinfo
Hi, On 5/6/20 6:01 PM, Will Deacon wrote: On Wed, May 06, 2020 at 05:32:56PM +0530, Amit Kachhap wrote: On 5/4/20 10:47 PM, Will Deacon wrote: On Mon, Apr 27, 2020 at 11:55:01AM +0530, Amit Daniel Kachhap wrote: diff --git a/arch/arm64/include/asm/compiler.h b/arch/arm64/include/asm/compiler.h index eece20d..32d5900 100644 --- a/arch/arm64/include/asm/compiler.h +++ b/arch/arm64/include/asm/compiler.h @@ -19,6 +19,9 @@ #define __builtin_return_address(val) \ (void *)(ptrauth_clear_pac((unsigned long)__builtin_return_address(val))) +#else /* !CONFIG_ARM64_PTR_AUTH */ +#defineptrauth_user_pac_mask() 0ULL +#defineptrauth_kernel_pac_mask() 0ULL This doesn't look quite right to me, since you still have to take into account the case where CONFIG_ARM64_PTR_AUTH=y but the feature is not available at runtime: Yes agree with you here. However the config gaurd is saving some extra computation for __builtin_return_address. There are some compiler support being added in __builtin_extract_return_address to mask the PAC. Hopefully that will improve this code. In the meantime let it be like this. Does the extra computation matter? Isn't it just a couple of instructions? ok sure. I will push v3 as you suggested. Thanks, Amit Will
Re: [PATCH v2 2/2] Documentation/vmcoreinfo: Add documentation for 'KERNELPACMASK'
Hi, On 5/4/20 11:04 PM, Will Deacon wrote: On Mon, Apr 27, 2020 at 11:55:02AM +0530, Amit Daniel Kachhap wrote: Add documentation for KERNELPACMASK variable being added to the vmcoreinfo. It indicates the PAC bits mask information of signed kernel pointers if Armv8.3-A Pointer Authentication feature is present. Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: Dave Young Cc: Baoquan He Signed-off-by: Amit Daniel Kachhap --- Documentation/admin-guide/kdump/vmcoreinfo.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 007a6b8..5cc3ee6 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -393,6 +393,12 @@ KERNELOFFSET The kernel randomization offset. Used to compute the page offset. If KASLR is disabled, this value is zero. +KERNELPACMASK +- + +Indicates the PAC bits mask information if Pointer Authentication is +enabled and address authentication feature is present. This is a bit cryptic. How about: The mask to extract the Pointer Authentication Code from a kernel virtual address. Ok sure. I will update like this in the v3 version. Cheers, Amit Daniel Will
Re: [PATCH v2 1/2] arm64/crash_core: Export KERNELPACMASK in vmcoreinfo
Hi Will,
On 5/4/20 10:47 PM, Will Deacon wrote:
On Mon, Apr 27, 2020 at 11:55:01AM +0530, Amit Daniel Kachhap wrote:
Recently arm64 linux kernel added support for Armv8.3-A Pointer
Authentication feature. If this feature is enabled in the kernel and the
hardware supports address authentication then the return addresses are
signed and stored in the stack to prevent ROP kind of attack. Kdump tool
will now dump the kernel with signed lr values in the stack.
Any user analysis tool for this kernel dump may need the kernel pac mask
information in vmcoreinfo to generate the correct return address for
stacktrace purpose as well as to resolve the symbol name.
This patch is similar to commit ec6e822d1a22d0eef ("arm64: expose user PAC
bit positions via ptrace") which exposes pac mask information via ptrace
interfaces.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Signed-off-by: Amit Daniel Kachhap
---
Changes since v1:
* Rebased to kernel 5.7-rc3.
* commit log change.
An implementation of this new KERNELPACMASK vmcoreinfo field used by crash
tool can be found here[1]. This change is accepted by crash utility
maintainer [2].
[1]: https://www.redhat.com/archives/crash-utility/2020-April/msg00095.html
[2]: https://www.redhat.com/archives/crash-utility/2020-April/msg00099.html
arch/arm64/include/asm/compiler.h | 3 +++
arch/arm64/kernel/crash_core.c| 4
2 files changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/compiler.h
b/arch/arm64/include/asm/compiler.h
index eece20d..32d5900 100644
--- a/arch/arm64/include/asm/compiler.h
+++ b/arch/arm64/include/asm/compiler.h
@@ -19,6 +19,9 @@
#define __builtin_return_address(val) \
(void *)(ptrauth_clear_pac((unsigned
long)__builtin_return_address(val)))
+#else /* !CONFIG_ARM64_PTR_AUTH */
+#defineptrauth_user_pac_mask() 0ULL
+#defineptrauth_kernel_pac_mask() 0ULL
This doesn't look quite right to me, since you still have to take into
account the case where CONFIG_ARM64_PTR_AUTH=y but the feature is not
available at runtime:
Yes agree with you here. However the config gaurd is saving some extra
computation for __builtin_return_address. There are some compiler
support being added in __builtin_extract_return_address to mask the PAC.
Hopefully that will improve this code. In the meantime let it be like this.
I can remove this else case and as other users of
ptrauth_{kernel,user}_pac_mask(ptrace.c) protect it with a config gaurd
there.
@@ -16,4 +17,7 @@ void arch_crash_save_vmcoreinfo(void)
vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
PHYS_OFFSET);
vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());
+ vmcoreinfo_append_str("NUMBER(KERNELPACMASK)=0x%llx\n",
+ system_supports_address_auth() ?
+ ptrauth_kernel_pac_mask() : 0);
In which case, would it make more sense to define
ptrauth_{kernel,user}_pac_mask() unconditionally? In fact, I'd probably
just remove the guards completely from asm/compiler.h because I think
they're misleading.
As answered above. Let me know your opinion. Although I don't have
strong reservation in keeping the config gaurd.
Thanks,
Amit Daniel
Will
--->8
diff --git a/arch/arm64/include/asm/compiler.h
b/arch/arm64/include/asm/compiler.h
index eece20d2c55f..51a7ce87cdfe 100644
--- a/arch/arm64/include/asm/compiler.h
+++ b/arch/arm64/include/asm/compiler.h
@@ -2,8 +2,6 @@
#ifndef __ASM_COMPILER_H
#define __ASM_COMPILER_H
-#if defined(CONFIG_ARM64_PTR_AUTH)
-
/*
* The EL0/EL1 pointer bits used by a pointer authentication code.
* This is dependent on TBI0/TBI1 being enabled, or bits 63:56 would also
apply.
@@ -19,6 +17,4 @@
#define __builtin_return_address(val) \
(void *)(ptrauth_clear_pac((unsigned
long)__builtin_return_address(val)))
-#endif /* CONFIG_ARM64_PTR_AUTH */
-
#endif /* __ASM_COMPILER_H */
Re: [PATCH v2 1/2] arm64/crash_core: Export KERNELPACMASK in vmcoreinfo
Hi Will/Catalin,
Sorry: Resending with correct To list.
On 4/27/20 11:55 AM, Amit Daniel Kachhap wrote:
Recently arm64 linux kernel added support for Armv8.3-A Pointer
Authentication feature. If this feature is enabled in the kernel and the
hardware supports address authentication then the return addresses are
signed and stored in the stack to prevent ROP kind of attack. Kdump tool
will now dump the kernel with signed lr values in the stack.
Any user analysis tool for this kernel dump may need the kernel pac mask
information in vmcoreinfo to generate the correct return address for
stacktrace purpose as well as to resolve the symbol name.
This patch is similar to commit ec6e822d1a22d0eef ("arm64: expose user PAC
bit positions via ptrace") which exposes pac mask information via ptrace
interfaces.
This patch user side changes are accepted by crash-utility maintainer [1]
so I think this is in a good shape to go in.
Thanks,
Amit Daniel
[1]: https://www.redhat.com/archives/crash-utility/2020-April/msg00095.html
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Signed-off-by: Amit Daniel Kachhap
---
Changes since v1:
* Rebased to kernel 5.7-rc3.
* commit log change.
An implementation of this new KERNELPACMASK vmcoreinfo field used by crash
tool can be found here[1]. This change is accepted by crash utility
maintainer [2].
[1]: https://www.redhat.com/archives/crash-utility/2020-April/msg00095.html
[2]: https://www.redhat.com/archives/crash-utility/2020-April/msg00099.html
arch/arm64/include/asm/compiler.h | 3 +++
arch/arm64/kernel/crash_core.c| 4
2 files changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/compiler.h
b/arch/arm64/include/asm/compiler.h
index eece20d..32d5900 100644
--- a/arch/arm64/include/asm/compiler.h
+++ b/arch/arm64/include/asm/compiler.h
@@ -19,6 +19,9 @@
#define __builtin_return_address(val) \
(void *)(ptrauth_clear_pac((unsigned
long)__builtin_return_address(val)))
+#else /* !CONFIG_ARM64_PTR_AUTH */
+#defineptrauth_user_pac_mask() 0ULL
+#defineptrauth_kernel_pac_mask() 0ULL
#endif /* CONFIG_ARM64_PTR_AUTH */
#endif /* __ASM_COMPILER_H */
diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c
index ca4c3e1..25cf2ce 100644
--- a/arch/arm64/kernel/crash_core.c
+++ b/arch/arm64/kernel/crash_core.c
@@ -6,6 +6,7 @@
#include
#include
+#include
void arch_crash_save_vmcoreinfo(void)
{
@@ -16,4 +17,7 @@ void arch_crash_save_vmcoreinfo(void)
vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
PHYS_OFFSET);
vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());
+ vmcoreinfo_append_str("NUMBER(KERNELPACMASK)=0x%llx\n",
+ system_supports_address_auth() ?
+ ptrauth_kernel_pac_mask() : 0);
}
Re: [PATCH v2 1/2] arm64/crash_core: Export KERNELPACMASK in vmcoreinfo
Hi Will/Catalin,
On 4/27/20 11:55 AM, Amit Daniel Kachhap wrote:
Recently arm64 linux kernel added support for Armv8.3-A Pointer
Authentication feature. If this feature is enabled in the kernel and the
hardware supports address authentication then the return addresses are
signed and stored in the stack to prevent ROP kind of attack. Kdump tool
will now dump the kernel with signed lr values in the stack.
Any user analysis tool for this kernel dump may need the kernel pac mask
information in vmcoreinfo to generate the correct return address for
stacktrace purpose as well as to resolve the symbol name.
This patch is similar to commit ec6e822d1a22d0eef ("arm64: expose user PAC
bit positions via ptrace") which exposes pac mask information via ptrace
interfaces.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Signed-off-by: Amit Daniel Kachhap
This patch user side changes are accepted by crash-utility maintainer [1]
so I think this is in a good shape to go in.
Thanks,
Amit Daniel
[1]: https://www.redhat.com/archives/crash-utility/2020-April/msg00099.html
---
Changes since v1:
* Rebased to kernel 5.7-rc3.
* commit log change.
An implementation of this new KERNELPACMASK vmcoreinfo field used by crash
tool can be found here[1]. This change is accepted by crash utility
maintainer [2].
[1]: https://www.redhat.com/archives/crash-utility/2020-April/msg00095.html
[2]: https://www.redhat.com/archives/crash-utility/2020-April/msg00099.html
arch/arm64/include/asm/compiler.h | 3 +++
arch/arm64/kernel/crash_core.c| 4
2 files changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/compiler.h
b/arch/arm64/include/asm/compiler.h
index eece20d..32d5900 100644
--- a/arch/arm64/include/asm/compiler.h
+++ b/arch/arm64/include/asm/compiler.h
@@ -19,6 +19,9 @@
#define __builtin_return_address(val) \
(void *)(ptrauth_clear_pac((unsigned
long)__builtin_return_address(val)))
+#else /* !CONFIG_ARM64_PTR_AUTH */
+#defineptrauth_user_pac_mask() 0ULL
+#defineptrauth_kernel_pac_mask() 0ULL
#endif /* CONFIG_ARM64_PTR_AUTH */
#endif /* __ASM_COMPILER_H */
diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c
index ca4c3e1..25cf2ce 100644
--- a/arch/arm64/kernel/crash_core.c
+++ b/arch/arm64/kernel/crash_core.c
@@ -6,6 +6,7 @@
#include
#include
+#include
void arch_crash_save_vmcoreinfo(void)
{
@@ -16,4 +17,7 @@ void arch_crash_save_vmcoreinfo(void)
vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
PHYS_OFFSET);
vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());
+ vmcoreinfo_append_str("NUMBER(KERNELPACMASK)=0x%llx\n",
+ system_supports_address_auth() ?
+ ptrauth_kernel_pac_mask() : 0);
}
Re: [PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
On Wed, Jul 9, 2014 at 8:30 AM, Chanwoo Choi wrote:
> On 07/01/2014 09:33 AM, Chanwoo Choi wrote:
>> This patch add registers, bit fields and compatible strings for Exynos3250
>> TMU
>> (Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
>> a target speed of 1.0 GHz.
>>
>> Signed-off-by: Chanwoo Choi
>> [Add MUX address setting bits by Jonghwa Lee]
>> Signed-off-by: Jonghwa Lee
>> Acked-by: Kyungmin Park
Changes look fine to me.
Reviewed-by: Amit Daniel Kachhap
>> ---
>> .../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
>> drivers/thermal/samsung/exynos_tmu.c | 7 +-
>> drivers/thermal/samsung/exynos_tmu.h | 3 +-
>> drivers/thermal/samsung/exynos_tmu_data.c | 89
>> ++
>> drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
>> 5 files changed, 105 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index c949092..ae738f5 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -3,6 +3,7 @@
>> ** Required properties:
>>
>> - compatible : One of the following:
>> +"samsung,exynos3250-tmu"
>> "samsung,exynos4412-tmu"
>> "samsung,exynos4210-tmu"
>> "samsung,exynos5250-tmu"
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 2412090..97ebc1e 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -501,6 +501,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>>
>> static const struct of_device_id exynos_tmu_match[] = {
>> {
>> + .compatible = "samsung,exynos3250-tmu",
>> + .data = (void *)EXYNOS3250_TMU_DRV_DATA,
>> + },
>> + {
>> .compatible = "samsung,exynos4210-tmu",
>> .data = (void *)EXYNOS4210_TMU_DRV_DATA,
>> },
>> @@ -675,7 +679,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>> goto err_clk_sec;
>> }
>>
>> - if (pdata->type == SOC_ARCH_EXYNOS4210 ||
>> + if (pdata->type == SOC_ARCH_EXYNOS3250 ||
>> + pdata->type == SOC_ARCH_EXYNOS4210 ||
>> pdata->type == SOC_ARCH_EXYNOS4412 ||
>> pdata->type == SOC_ARCH_EXYNOS5250 ||
>> pdata->type == SOC_ARCH_EXYNOS5260 ||
>> diff --git a/drivers/thermal/samsung/exynos_tmu.h
>> b/drivers/thermal/samsung/exynos_tmu.h
>> index edd08cf..1b4a644 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.h
>> +++ b/drivers/thermal/samsung/exynos_tmu.h
>> @@ -40,7 +40,8 @@ enum calibration_mode {
>> };
>>
>> enum soc_type {
>> - SOC_ARCH_EXYNOS4210 = 1,
>> + SOC_ARCH_EXYNOS3250 = 1,
>> + SOC_ARCH_EXYNOS4210,
>> SOC_ARCH_EXYNOS4412,
>> SOC_ARCH_EXYNOS5250,
>> SOC_ARCH_EXYNOS5260,
>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
>> b/drivers/thermal/samsung/exynos_tmu_data.c
>> index c1d81dc..aa8e0de 100644
>> --- a/drivers/thermal/samsung/exynos_tmu_data.c
>> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
>> @@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
>> exynos4210_default_tmu_data = {
>> };
>> #endif
>>
>> +#if defined(CONFIG_SOC_EXYNOS3250)
>> +static const struct exynos_tmu_registers exynos3250_tmu_registers = {
>> + .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
>> + .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
>> + .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
>> + .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
>> + .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
>> + .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
>> + .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
>> + .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
>> + .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
>> + .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
>> + .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
>> + .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
>> + .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
>> + .tmu_status = EXYNOS_TMU_REG_STATUS,
>> + .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
>> + .threshold_th0 = EXYNOS_THD_TEMP_RISE,
>> + .threshold_th1 = EXYNOS_THD_TEMP_FALL,
>> + .tmu_inten = EXYNOS_TMU_REG_INTEN,
>> + .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
>> + .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
>> + .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
>> + .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
>> + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
>> + .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
>> + .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
>> + .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
>> + .intclr_rise_mask =
Re: [PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
On Wed, Jul 9, 2014 at 8:30 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
On 07/01/2014 09:33 AM, Chanwoo Choi wrote:
This patch add registers, bit fields and compatible strings for Exynos3250
TMU
(Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
a target speed of 1.0 GHz.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
[Add MUX address setting bits by Jonghwa Lee]
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Changes look fine to me.
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
---
.../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
drivers/thermal/samsung/exynos_tmu.c | 7 +-
drivers/thermal/samsung/exynos_tmu.h | 3 +-
drivers/thermal/samsung/exynos_tmu_data.c | 89
++
drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
5 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index c949092..ae738f5 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -3,6 +3,7 @@
** Required properties:
- compatible : One of the following:
+samsung,exynos3250-tmu
samsung,exynos4412-tmu
samsung,exynos4210-tmu
samsung,exynos5250-tmu
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 2412090..97ebc1e 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -501,6 +501,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static const struct of_device_id exynos_tmu_match[] = {
{
+ .compatible = samsung,exynos3250-tmu,
+ .data = (void *)EXYNOS3250_TMU_DRV_DATA,
+ },
+ {
.compatible = samsung,exynos4210-tmu,
.data = (void *)EXYNOS4210_TMU_DRV_DATA,
},
@@ -675,7 +679,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
goto err_clk_sec;
}
- if (pdata-type == SOC_ARCH_EXYNOS4210 ||
+ if (pdata-type == SOC_ARCH_EXYNOS3250 ||
+ pdata-type == SOC_ARCH_EXYNOS4210 ||
pdata-type == SOC_ARCH_EXYNOS4412 ||
pdata-type == SOC_ARCH_EXYNOS5250 ||
pdata-type == SOC_ARCH_EXYNOS5260 ||
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index edd08cf..1b4a644 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -40,7 +40,8 @@ enum calibration_mode {
};
enum soc_type {
- SOC_ARCH_EXYNOS4210 = 1,
+ SOC_ARCH_EXYNOS3250 = 1,
+ SOC_ARCH_EXYNOS4210,
SOC_ARCH_EXYNOS4412,
SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5260,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index c1d81dc..aa8e0de 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
exynos4210_default_tmu_data = {
};
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+static const struct exynos_tmu_registers exynos3250_tmu_registers = {
+ .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
+ .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
+ .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
+ .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
+ .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
+ .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
+ .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
+ .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
+ .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
+ .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
+ .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
+ .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
+ .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
+ .tmu_status = EXYNOS_TMU_REG_STATUS,
+ .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
+ .threshold_th0 = EXYNOS_THD_TEMP_RISE,
+ .threshold_th1 = EXYNOS_THD_TEMP_FALL,
+ .tmu_inten = EXYNOS_TMU_REG_INTEN,
+ .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
+ .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
+ .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
+ .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
+ .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
+ .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
+ .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
+ .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
+ .intclr_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
+ .emul_con = EXYNOS_EMUL_CON,
+ .emul_temp_shift =
Re: [PATCH v1 3/6] thermal: thermal-core: Add notifications support for the cooling states
On 5/29/14, Javi Merino wrote:
> Hi Amit,
>
> On Thu, May 29, 2014 at 09:15:31AM +0100, Amit Daniel Kachhap wrote:
>> This patch adds notification infrastructure for any requests related to
>> cooling
>> states. The notifier structure passed is of both Get/Set type. So the
>> receiver
>> of these can sense the new/cur/max cooling state as decided by thermal
>> governor.
>> In addition to that it can also override the cooling state and may do
>> something
>> interesting after receiving these CPU cooling events such as masking some
>> states, enabling some extra conditional states or perform any extra
>> operation
>> for aggressive thermal cooling.
>> The notfications events can be of type,
>>
>> 1. COOLING_SET_STATE_PRE
>> 2. COOLING_SET_STATE_POST
>> 3. COOLING_GET_CUR_STATE
>> 4. COOLING_GET_MAX_STATE
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> Documentation/thermal/sysfs-api.txt | 21 +++
>> drivers/thermal/thermal_core.c | 69
>> ++-
>> include/linux/thermal.h | 21 +++
>> 3 files changed, 109 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt
>> b/Documentation/thermal/sysfs-api.txt
>> index 87519cb..5f45e03 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -92,6 +92,27 @@ temperature) and throttle appropriate devices.
>> It deletes the corresponding entry form /sys/class/thermal folder
>> and
>> unbind itself from all the thermal zone devices using it.
>>
>> +1.2.3 int thermal_cooling_register_notifier(struct notifier_block *nb)
>> +
>> +This interface function registers the client notifier handler. The
>> notifier
>> +handler can use this to monitor or update any cooling state
>> requests.
>> +nb: notifier structure containing client notifier handler.
>> +
>> +1.2.4 int thermal_cooling_unregister_notifier(struct notifier_block *nb)
>> +
>> +This interface function unregisters the client notifier handler.
>> +nb: notifier structure containing client notifier handler.
>> +
>> +1.2.5 int thermal_cooling_notify_states(struct thermal_cooling_status
>> *request,enum cooling_state_ops op)
>> +
>> +This interface function invokes the earlier registered cooling states
>> handler.
>> +request: holds the relevant cooling state value.
>> +.cur_state: current cooling state.
>> +.new_state: new cooling state to be set.
>> +.max_state: max cooling state.
>> +.devdata: driver private data pointer.
>> +op: describes various operation supported.
>> +
>> 1.3 interface for binding a thermal zone device with a thermal cooling
>> device
>> 1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device
>> *tz,
>> int trip, struct thermal_cooling_device *cdev,
>> diff --git a/drivers/thermal/thermal_core.c
>> b/drivers/thermal/thermal_core.c
>> index 71b0ec0..1a60f83 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -52,6 +52,8 @@ static DEFINE_MUTEX(thermal_idr_lock);
>> static LIST_HEAD(thermal_tz_list);
>> static LIST_HEAD(thermal_cdev_list);
>> static LIST_HEAD(thermal_governor_list);
>> +/* Notfier list to validates/updates the cpufreq cooling states */
>> +static BLOCKING_NOTIFIER_HEAD(cooling_state_notifier_list);
>>
>> static DEFINE_MUTEX(thermal_list_lock);
>> static DEFINE_MUTEX(thermal_governor_lock);
>> @@ -1073,8 +1075,71 @@ static struct class thermal_class = {
>> };
>>
>> /**
>> - * __thermal_cooling_device_register() - register a new thermal cooling
>> device
>> - * @np: a pointer to a device tree node.
>> + * thermal_cooling_notify_states - Invoke the necessary cooling states
>> handler.
>> + * @request: holds the relevant cooling state value. say if the cooling
>> state
>> + * operation is of type COOLING_GET_MAX_STATE, then request holds
>> + * the current max cooling state value.
>> + * @op: different operations supported
>> + *
>> + * This API allows the registered user to recieve the different cooling
>> + * notifications like current state, max state and set state.
>> + *
>> + * Return: 0 (success)
>> + */
>> +int thermal_cooling_notify_states(struct thermal_cooling_status
>> *request,
>> +enum cooling_state_ops op)
>> +{
>> +/* Invoke the notifiers which have registered for this state change */
>> +if (op == COOLING_SET_STATE_PRE ||
>> +op == COOLING_SET_STATE_POST ||
>> +op == COOLING_GET_MAX_STATE ||
>> +op == COOLING_GET_CUR_STATE) {
>> +blocking_notifier_call_chain(
>> +_state_notifier_list, op, request);
>> +}
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_cooling_notify_states);
>> +
>> +/**
>> + * thermal_cooling_register_notifier - registers a notifier with thermal
>> cooling.
>> + * @nb: notifier function to register.
>> + *
>> + * Add a driver to receive all cooling
Re: [PATCH v1 2/6] thermal: cpu_cooling: Support passing driver private data.
On 5/29/14, Javi Merino wrote:
> Hi Amit,
>
> One minor comment.
>
> On Thu, May 29, 2014 at 09:15:30AM +0100, Amit Daniel Kachhap wrote:
>> This patch allows the caller of cpufreq cooling APIs to register along
>> with their driver data which will be useful while receiving any cooling
>> states
>> notifications.
>> This patch is in preparation to add notfication support for cpufrequency
>> cooling changes. This change also removes the unnecessary exposing of
>> internal housekeeping structure via thermal_cooling_device->devdata to
>> the
>> users of cpufreq cooling APIs. As part of this implmentation, this private
>> local
>> structure (cpufreq_dev) is now stored in a list and scanned for each call
>> to
>> cpu cooling interfaces.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> Documentation/thermal/cpu-cooling-api.txt |3 +-
>> drivers/thermal/cpu_cooling.c | 89
>>
>> drivers/thermal/db8500_cpufreq_cooling.c |2 +-
>> drivers/thermal/samsung/exynos_thermal_common.c|2 +-
>> drivers/thermal/ti-soc-thermal/ti-thermal-common.c |2 +-
>> include/linux/cpu_cooling.h|5 +-
>> 6 files changed, 80 insertions(+), 23 deletions(-)
>>
>> diff --git a/Documentation/thermal/cpu-cooling-api.txt
>> b/Documentation/thermal/cpu-cooling-api.txt
>> index fca24c9..aaa07c6 100644
>> --- a/Documentation/thermal/cpu-cooling-api.txt
>> +++ b/Documentation/thermal/cpu-cooling-api.txt
>> @@ -17,13 +17,14 @@ the user. The registration APIs returns the cooling
>> device pointer.
>>
>> 1.1 cpufreq registration/unregistration APIs
>> 1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
>> - struct cpumask *clip_cpus)
>> + struct cpumask *clip_cpus, void *devdata)
>>
>> This interface function registers the cpufreq cooling device with the
>> name
>> "thermal-cpufreq-%x". This api can support multiple instances of
>> cpufreq
>> cooling devices.
>>
>> clip_cpus: cpumask of cpus where the frequency constraints will
>> happen.
>> + devdata: driver private data pointer.
>>
>> 1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device
>> *cdev)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c
>> b/drivers/thermal/cpu_cooling.c
>> index 16388b0..6d145d5 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -50,16 +50,18 @@ struct cpufreq_cooling_device {
>> unsigned int cpufreq_state;
>> unsigned int cpufreq_val;
>> struct cpumask allowed_cpus;
>> + struct list_head node;
>> };
>> static DEFINE_IDR(cpufreq_idr);
>> static DEFINE_MUTEX(cooling_cpufreq_lock);
>>
>> -static unsigned int cpufreq_dev_count;
>> -
>> /* notify_table passes value to the CPUFREQ_ADJUST callback function. */
>> #define NOTIFY_INVALID NULL
>> static DEFINE_PER_CPU(struct cpufreq_cooling_device *, notify_device);
>>
>> +/* A list to hold all the cpufreq cooling devices registered */
>> +static LIST_HEAD(cpufreq_cooling_list);
>> +
>> /**
>> * get_idr - function to get a unique id.
>> * @idr: struct idr * handle used to create a id.
>> @@ -98,6 +100,26 @@ static void release_idr(struct idr *idr, int id)
>>
>> /* Below code defines functions to be used for cpufreq as cooling device
>> */
>>
>> +/**
>> + * cpufreq_cooling_get_info - function to cpufreq_dev for the
>> corresponding cdev
>> + * @cdev: pointer of the cooling device
>> + *
>> + * This function will loop through the cpufreq_cooling_device list and
>> + * return the matching device
>> + *
>
> You should add a "Locking:" section here which documents that this
> function must be called with cooling_cpufreq_lock held.
Yes agreed. Will update in the next version.
Thanks,
Amit
>
> Cheers,
> Javi
>
>> + * Return: cpufreq_cooling_device if matched with the cdev or NULL if
>> not
>> + * matched.
>> + */
>> +static inline struct cpufreq_cooling_device *
>> +cpufreq_cooling_get_info(struct thermal_cooling_device *cdev)
>> +{
>> + struct cpufreq_cooling_device *cpufreq_dev = NULL;
>> + list_for_each_entry(cpufreq_dev, _cooling_list, node)
>> + if (cpufreq_dev->cool_dev == cdev)
>> + break;
>> + return cpufreq_dev;
>> +}
>> +
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 6/6] ACPI: thermal: processor: Use the generic cpufreq infrastructure
Hi Javi,
On 5/29/14, Javi Merino wrote:
> Hi Amit,
>
> On Thu, May 29, 2014 at 09:15:34AM +0100, Amit Daniel Kachhap wrote:
>> This patch upgrades the ACPI cpufreq cooling portions to use the generic
>> cpufreq cooling infrastructure. There should not be any functionality
>> related changes as the same behaviour is provided by the generic
>> cpufreq APIs with the notifier mechanism.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> drivers/acpi/processor_driver.c |6 +-
>> drivers/acpi/processor_thermal.c | 235
>> ++
>> include/acpi/processor.h |3 +-
>> 3 files changed, 115 insertions(+), 129 deletions(-)
>>
>> diff --git a/drivers/acpi/processor_driver.c
>> b/drivers/acpi/processor_driver.c
>> index 7f70f31..10aba4a 100644
>> --- a/drivers/acpi/processor_driver.c
>> +++ b/drivers/acpi/processor_driver.c
>> @@ -36,6 +36,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -178,8 +179,7 @@ static int __acpi_processor_start(struct acpi_device
>> *device)
>> if (!cpuidle_get_driver() || cpuidle_get_driver() ==
>> _idle_driver)
>> acpi_processor_power_init(pr);
>>
>> - pr->cdev = thermal_cooling_device_register("Processor", device,
>> -
>> _cooling_ops);
>> + pr->cdev = acpi_processor_cooling_register(device);
>
> With this you have removed the only cooling device whose type was
> "Processor". There's special code for dealing with this cooling
> device in drivers/thermal/thermal_core.c:passive_store():
>
> list_for_each_entry(cdev, _cdev_list, node) {
> if (!strncmp("Processor", cdev->type,
>sizeof("Processor")))
> thermal_zone_bind_cooling_device(tz,
> THERMAL_TRIPS_NONE, cdev,
> THERMAL_NO_LIMIT,
> THERMAL_NO_LIMIT);
> }
> mutex_unlock(_list_lock);
> if (!tz->passive_delay)
>
> With your change, that code is now "dead" as it can't do anything. No
> I don't know what should you do with it, either remove it or make it
> match the cpufreq cooling device. But this patch should deal with
> that code as well.
nice catch. I somehow missed modifying this section.
I think the following changes should fix this,
- if (!strncmp("Processor", cdev->type,
-sizeof("Processor")))
+ if (!strncmp("thermal-cpufreq", cdev->type,
+sizeof("thermal-cpufreq")))
thermal_zone_bind_cooling_device(tz,
>
> Cheers,
> Javi
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 6/6] ACPI: thermal: processor: Use the generic cpufreq infrastructure
Hi Javi,
On 5/29/14, Javi Merino javi.mer...@arm.com wrote:
Hi Amit,
On Thu, May 29, 2014 at 09:15:34AM +0100, Amit Daniel Kachhap wrote:
This patch upgrades the ACPI cpufreq cooling portions to use the generic
cpufreq cooling infrastructure. There should not be any functionality
related changes as the same behaviour is provided by the generic
cpufreq APIs with the notifier mechanism.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/acpi/processor_driver.c |6 +-
drivers/acpi/processor_thermal.c | 235
++
include/acpi/processor.h |3 +-
3 files changed, 115 insertions(+), 129 deletions(-)
diff --git a/drivers/acpi/processor_driver.c
b/drivers/acpi/processor_driver.c
index 7f70f31..10aba4a 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -36,6 +36,7 @@
#include linux/cpuidle.h
#include linux/slab.h
#include linux/acpi.h
+#include linux/cpu_cooling.h
#include acpi/processor.h
@@ -178,8 +179,7 @@ static int __acpi_processor_start(struct acpi_device
*device)
if (!cpuidle_get_driver() || cpuidle_get_driver() ==
acpi_idle_driver)
acpi_processor_power_init(pr);
- pr-cdev = thermal_cooling_device_register(Processor, device,
-
processor_cooling_ops);
+ pr-cdev = acpi_processor_cooling_register(device);
With this you have removed the only cooling device whose type was
Processor. There's special code for dealing with this cooling
device in drivers/thermal/thermal_core.c:passive_store():
list_for_each_entry(cdev, thermal_cdev_list, node) {
if (!strncmp(Processor, cdev-type,
sizeof(Processor)))
thermal_zone_bind_cooling_device(tz,
THERMAL_TRIPS_NONE, cdev,
THERMAL_NO_LIMIT,
THERMAL_NO_LIMIT);
}
mutex_unlock(thermal_list_lock);
if (!tz-passive_delay)
With your change, that code is now dead as it can't do anything. No
I don't know what should you do with it, either remove it or make it
match the cpufreq cooling device. But this patch should deal with
that code as well.
nice catch. I somehow missed modifying this section.
I think the following changes should fix this,
- if (!strncmp(Processor, cdev-type,
-sizeof(Processor)))
+ if (!strncmp(thermal-cpufreq, cdev-type,
+sizeof(thermal-cpufreq)))
thermal_zone_bind_cooling_device(tz,
Cheers,
Javi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/6] thermal: cpu_cooling: Support passing driver private data.
On 5/29/14, Javi Merino javi.mer...@arm.com wrote:
Hi Amit,
One minor comment.
On Thu, May 29, 2014 at 09:15:30AM +0100, Amit Daniel Kachhap wrote:
This patch allows the caller of cpufreq cooling APIs to register along
with their driver data which will be useful while receiving any cooling
states
notifications.
This patch is in preparation to add notfication support for cpufrequency
cooling changes. This change also removes the unnecessary exposing of
internal housekeeping structure via thermal_cooling_device-devdata to
the
users of cpufreq cooling APIs. As part of this implmentation, this private
local
structure (cpufreq_dev) is now stored in a list and scanned for each call
to
cpu cooling interfaces.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Documentation/thermal/cpu-cooling-api.txt |3 +-
drivers/thermal/cpu_cooling.c | 89
drivers/thermal/db8500_cpufreq_cooling.c |2 +-
drivers/thermal/samsung/exynos_thermal_common.c|2 +-
drivers/thermal/ti-soc-thermal/ti-thermal-common.c |2 +-
include/linux/cpu_cooling.h|5 +-
6 files changed, 80 insertions(+), 23 deletions(-)
diff --git a/Documentation/thermal/cpu-cooling-api.txt
b/Documentation/thermal/cpu-cooling-api.txt
index fca24c9..aaa07c6 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -17,13 +17,14 @@ the user. The registration APIs returns the cooling
device pointer.
1.1 cpufreq registration/unregistration APIs
1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
- struct cpumask *clip_cpus)
+ struct cpumask *clip_cpus, void *devdata)
This interface function registers the cpufreq cooling device with the
name
thermal-cpufreq-%x. This api can support multiple instances of
cpufreq
cooling devices.
clip_cpus: cpumask of cpus where the frequency constraints will
happen.
+ devdata: driver private data pointer.
1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device
*cdev)
diff --git a/drivers/thermal/cpu_cooling.c
b/drivers/thermal/cpu_cooling.c
index 16388b0..6d145d5 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -50,16 +50,18 @@ struct cpufreq_cooling_device {
unsigned int cpufreq_state;
unsigned int cpufreq_val;
struct cpumask allowed_cpus;
+ struct list_head node;
};
static DEFINE_IDR(cpufreq_idr);
static DEFINE_MUTEX(cooling_cpufreq_lock);
-static unsigned int cpufreq_dev_count;
-
/* notify_table passes value to the CPUFREQ_ADJUST callback function. */
#define NOTIFY_INVALID NULL
static DEFINE_PER_CPU(struct cpufreq_cooling_device *, notify_device);
+/* A list to hold all the cpufreq cooling devices registered */
+static LIST_HEAD(cpufreq_cooling_list);
+
/**
* get_idr - function to get a unique id.
* @idr: struct idr * handle used to create a id.
@@ -98,6 +100,26 @@ static void release_idr(struct idr *idr, int id)
/* Below code defines functions to be used for cpufreq as cooling device
*/
+/**
+ * cpufreq_cooling_get_info - function to cpufreq_dev for the
corresponding cdev
+ * @cdev: pointer of the cooling device
+ *
+ * This function will loop through the cpufreq_cooling_device list and
+ * return the matching device
+ *
You should add a Locking: section here which documents that this
function must be called with cooling_cpufreq_lock held.
Yes agreed. Will update in the next version.
Thanks,
Amit
Cheers,
Javi
+ * Return: cpufreq_cooling_device if matched with the cdev or NULL if
not
+ * matched.
+ */
+static inline struct cpufreq_cooling_device *
+cpufreq_cooling_get_info(struct thermal_cooling_device *cdev)
+{
+ struct cpufreq_cooling_device *cpufreq_dev = NULL;
+ list_for_each_entry(cpufreq_dev, cpufreq_cooling_list, node)
+ if (cpufreq_dev-cool_dev == cdev)
+ break;
+ return cpufreq_dev;
+}
+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/6] thermal: thermal-core: Add notifications support for the cooling states
On 5/29/14, Javi Merino javi.mer...@arm.com wrote:
Hi Amit,
On Thu, May 29, 2014 at 09:15:31AM +0100, Amit Daniel Kachhap wrote:
This patch adds notification infrastructure for any requests related to
cooling
states. The notifier structure passed is of both Get/Set type. So the
receiver
of these can sense the new/cur/max cooling state as decided by thermal
governor.
In addition to that it can also override the cooling state and may do
something
interesting after receiving these CPU cooling events such as masking some
states, enabling some extra conditional states or perform any extra
operation
for aggressive thermal cooling.
The notfications events can be of type,
1. COOLING_SET_STATE_PRE
2. COOLING_SET_STATE_POST
3. COOLING_GET_CUR_STATE
4. COOLING_GET_MAX_STATE
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Documentation/thermal/sysfs-api.txt | 21 +++
drivers/thermal/thermal_core.c | 69
++-
include/linux/thermal.h | 21 +++
3 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index 87519cb..5f45e03 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -92,6 +92,27 @@ temperature) and throttle appropriate devices.
It deletes the corresponding entry form /sys/class/thermal folder
and
unbind itself from all the thermal zone devices using it.
+1.2.3 int thermal_cooling_register_notifier(struct notifier_block *nb)
+
+This interface function registers the client notifier handler. The
notifier
+handler can use this to monitor or update any cooling state
requests.
+nb: notifier structure containing client notifier handler.
+
+1.2.4 int thermal_cooling_unregister_notifier(struct notifier_block *nb)
+
+This interface function unregisters the client notifier handler.
+nb: notifier structure containing client notifier handler.
+
+1.2.5 int thermal_cooling_notify_states(struct thermal_cooling_status
*request,enum cooling_state_ops op)
+
+This interface function invokes the earlier registered cooling states
handler.
+request: holds the relevant cooling state value.
+.cur_state: current cooling state.
+.new_state: new cooling state to be set.
+.max_state: max cooling state.
+.devdata: driver private data pointer.
+op: describes various operation supported.
+
1.3 interface for binding a thermal zone device with a thermal cooling
device
1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device
*tz,
int trip, struct thermal_cooling_device *cdev,
diff --git a/drivers/thermal/thermal_core.c
b/drivers/thermal/thermal_core.c
index 71b0ec0..1a60f83 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -52,6 +52,8 @@ static DEFINE_MUTEX(thermal_idr_lock);
static LIST_HEAD(thermal_tz_list);
static LIST_HEAD(thermal_cdev_list);
static LIST_HEAD(thermal_governor_list);
+/* Notfier list to validates/updates the cpufreq cooling states */
+static BLOCKING_NOTIFIER_HEAD(cooling_state_notifier_list);
static DEFINE_MUTEX(thermal_list_lock);
static DEFINE_MUTEX(thermal_governor_lock);
@@ -1073,8 +1075,71 @@ static struct class thermal_class = {
};
/**
- * __thermal_cooling_device_register() - register a new thermal cooling
device
- * @np: a pointer to a device tree node.
+ * thermal_cooling_notify_states - Invoke the necessary cooling states
handler.
+ * @request: holds the relevant cooling state value. say if the cooling
state
+ * operation is of type COOLING_GET_MAX_STATE, then request holds
+ * the current max cooling state value.
+ * @op: different operations supported
+ *
+ * This API allows the registered user to recieve the different cooling
+ * notifications like current state, max state and set state.
+ *
+ * Return: 0 (success)
+ */
+int thermal_cooling_notify_states(struct thermal_cooling_status
*request,
+enum cooling_state_ops op)
+{
+/* Invoke the notifiers which have registered for this state change */
+if (op == COOLING_SET_STATE_PRE ||
+op == COOLING_SET_STATE_POST ||
+op == COOLING_GET_MAX_STATE ||
+op == COOLING_GET_CUR_STATE) {
+blocking_notifier_call_chain(
+cooling_state_notifier_list, op, request);
+}
+return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_cooling_notify_states);
+
+/**
+ * thermal_cooling_register_notifier - registers a notifier with thermal
cooling.
+ * @nb: notifier function to register.
+ *
+ * Add a driver to receive all cooling notifications like current state,
+ * max state and set state. The drivers after reading the events can
perform
+ * some mapping like grouping some P states into 1 cooling state.
+ *
+ * Return: 0
Re: [PATCH 00/10] thermal: exynos: various cleanups
On 5/15/14, Zhang Rui wrote: > On 一, 2014-05-05 at 13:15 +0200, Bartlomiej Zolnierkiewicz wrote: >> Hi, >> >> This patch series contains various cleanups for EXYNOS thermal >> driver. Overall it decreases driver's LOC by 13%. It is based >> on next-20140428 kernel. It should not cause any functionality >> changes. >> > Amit, > > what do you think of this patch set? > > thanks, > rui I agreed to many of the cleanups in the patch but tmu controller features should be retained as they will allow adding quick soc support and also avoid unnecessary churning of code in the future. Thanks, Amit >> Best regards, >> -- >> Bartlomiej Zolnierkiewicz >> Samsung R Institute Poland >> Samsung Electronics >> >> >> Bartlomiej Zolnierkiewicz (10): >> thermal: exynos: remove unused struct exynos_tmu_registers entries >> thermal: exynos: remove unused defines >> thermal: exynos: remove dead code for HW_MODE calibration >> thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING >> calibration >> thermal: exynos: remove redundant pdata checks from >> exynos_tmu_initialize() >> thermal: exynos: remove redundant threshold_code checks from >> exynos_tmu_initialize() >> thermal: exynos: simplify temp_to_code() and code_to_temp() >> thermal: exynos: cache non_hw_trigger_levels in pdata >> thermal: exynos: remove redundant pdata checks from >> exynos_tmu_control() >> thermal: exynos: remove identical values from exynos*_tmu_registers >> structures >> >> drivers/thermal/samsung/exynos_thermal_common.h | 1 - >> drivers/thermal/samsung/exynos_tmu.c| 181 >> >> drivers/thermal/samsung/exynos_tmu.h| 86 +-- >> drivers/thermal/samsung/exynos_tmu_data.c | 40 +- >> drivers/thermal/samsung/exynos_tmu_data.h | 32 + >> 5 files changed, 37 insertions(+), 303 deletions(-) >> > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] thermal: exynos: remove identical values from exynos*_tmu_registers structures
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> There is no need for abstracting configuration for registers that
> are identical on all SoC types.
Changes look fine and also that shift and masks may not change in
future socs also.
Reviewed-by: Amit Daniel Kachhap
>
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/thermal/samsung/exynos_tmu.c | 12 ++--
> drivers/thermal/samsung/exynos_tmu.h | 11 ---
> drivers/thermal/samsung/exynos_tmu_data.c | 15 ---
> 3 files changed, 6 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 45d7c6f..d37e755 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -215,11 +215,11 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
> if (pdata->test_mux)
> con |= (pdata->test_mux << reg->test_mux_addr_shift);
>
> - con &= ~(reg->buf_vref_sel_mask << reg->buf_vref_sel_shift);
> - con |= pdata->reference_voltage << reg->buf_vref_sel_shift;
> + con &= ~(EXYNOS_TMU_REF_VOLTAGE_MASK << EXYNOS_TMU_REF_VOLTAGE_SHIFT);
> + con |= pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT;
>
> - con &= ~(reg->buf_slope_sel_mask << reg->buf_slope_sel_shift);
> - con |= (pdata->gain << reg->buf_slope_sel_shift);
> + con &= ~(EXYNOS_TMU_BUF_SLOPE_SEL_MASK <<
> EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT);
> + con |= (pdata->gain << EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT);
>
> if (pdata->noise_cancel_mode) {
> con &= ~(reg->therm_trip_mode_mask <<
> @@ -228,7 +228,7 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
> }
>
> if (on) {
> - con |= (1 << reg->core_en_shift);
> + con |= (1 << EXYNOS_TMU_CORE_EN_SHIFT);
> interrupt_en =
> pdata->trigger_enable[3] << reg->inten_rise3_shift |
> pdata->trigger_enable[2] << reg->inten_rise2_shift |
> @@ -238,7 +238,7 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
> interrupt_en |=
> interrupt_en << reg->inten_fall0_shift;
> } else {
> - con &= ~(1 << reg->core_en_shift);
> + con &= ~(1 << EXYNOS_TMU_CORE_EN_SHIFT);
> interrupt_en = 0; /* Disable all interrupts */
> }
> writel(interrupt_en, data->base + reg->tmu_inten);
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index 4845171..5c25a4b 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -69,15 +69,9 @@ enum soc_type {
> * @triminfo_ctrl: trim info controller register.
> * @tmu_ctrl: TMU main controller register.
> * @test_mux_addr_shift: shift bits of test mux address.
> - * @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl
> register.
> - * @buf_vref_sel_mask: mask bits of reference voltage in tmu_ctrl
> register.
> * @therm_trip_mode_shift: shift bits of tripping mode in tmu_ctrl
> register.
> * @therm_trip_mode_mask: mask bits of tripping mode in tmu_ctrl register.
> * @therm_trip_en_shift: shift bits of tripping enable in tmu_ctrl
> register.
> - * @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
> - register.
> - * @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl
> register.
> - * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
> * @tmu_status: register drescribing the TMU status.
> * @tmu_cur_temp: register containing the current temperature of the TMU.
> * @threshold_temp: register containing the base threshold level.
> @@ -111,14 +105,9 @@ struct exynos_tmu_registers {
>
> u32 tmu_ctrl;
> u32 test_mux_addr_shift;
> - u32 buf_vref_sel_shift;
> - u32 buf_vref_sel_mask;
> u32 therm_trip_mode_shift;
> u32 therm_trip_mode_mask;
> u32 therm_trip_en_shift;
> - u32 buf_slope_sel_shift;
> - u32 buf_slope_sel_mask;
> - u32 core_en_shift;
>
> u32 tmu_status;
>
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index ef7f186..32530dc 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -28,11 +28,6 @@
> static const struct exynos_tmu_registers exynos4210_tmu_registers = {
> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> - .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> - .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
> - .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
> - .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
> - .core_en_shift =
Re: [PATCH 09/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_control()
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> pdata->reference_voltage and pdata->gain are always defined
> to non-zero values so remove the redundant checks from
> exynos_tmu_control().
I prefer to have these checks for the same reason that new soc support
should not add these same code again.
>
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/thermal/samsung/exynos_tmu.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index a8d9524..45d7c6f 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -215,15 +215,11 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
> if (pdata->test_mux)
> con |= (pdata->test_mux << reg->test_mux_addr_shift);
>
> - if (pdata->reference_voltage) {
> - con &= ~(reg->buf_vref_sel_mask << reg->buf_vref_sel_shift);
> - con |= pdata->reference_voltage << reg->buf_vref_sel_shift;
> - }
> + con &= ~(reg->buf_vref_sel_mask << reg->buf_vref_sel_shift);
> + con |= pdata->reference_voltage << reg->buf_vref_sel_shift;
>
> - if (pdata->gain) {
> - con &= ~(reg->buf_slope_sel_mask << reg->buf_slope_sel_shift);
> - con |= (pdata->gain << reg->buf_slope_sel_shift);
> - }
> + con &= ~(reg->buf_slope_sel_mask << reg->buf_slope_sel_shift);
> + con |= (pdata->gain << reg->buf_slope_sel_shift);
>
> if (pdata->noise_cancel_mode) {
> con &= ~(reg->therm_trip_mode_mask <<
> --
> 1.8.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_control()
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
pdata-reference_voltage and pdata-gain are always defined
to non-zero values so remove the redundant checks from
exynos_tmu_control().
I prefer to have these checks for the same reason that new soc support
should not add these same code again.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index a8d9524..45d7c6f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -215,15 +215,11 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (pdata-test_mux)
con |= (pdata-test_mux reg-test_mux_addr_shift);
- if (pdata-reference_voltage) {
- con = ~(reg-buf_vref_sel_mask reg-buf_vref_sel_shift);
- con |= pdata-reference_voltage reg-buf_vref_sel_shift;
- }
+ con = ~(reg-buf_vref_sel_mask reg-buf_vref_sel_shift);
+ con |= pdata-reference_voltage reg-buf_vref_sel_shift;
- if (pdata-gain) {
- con = ~(reg-buf_slope_sel_mask reg-buf_slope_sel_shift);
- con |= (pdata-gain reg-buf_slope_sel_shift);
- }
+ con = ~(reg-buf_slope_sel_mask reg-buf_slope_sel_shift);
+ con |= (pdata-gain reg-buf_slope_sel_shift);
if (pdata-noise_cancel_mode) {
con = ~(reg-therm_trip_mode_mask
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] thermal: exynos: remove identical values from exynos*_tmu_registers structures
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
There is no need for abstracting configuration for registers that
are identical on all SoC types.
Changes look fine and also that shift and masks may not change in
future socs also.
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 12 ++--
drivers/thermal/samsung/exynos_tmu.h | 11 ---
drivers/thermal/samsung/exynos_tmu_data.c | 15 ---
3 files changed, 6 insertions(+), 32 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 45d7c6f..d37e755 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -215,11 +215,11 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (pdata-test_mux)
con |= (pdata-test_mux reg-test_mux_addr_shift);
- con = ~(reg-buf_vref_sel_mask reg-buf_vref_sel_shift);
- con |= pdata-reference_voltage reg-buf_vref_sel_shift;
+ con = ~(EXYNOS_TMU_REF_VOLTAGE_MASK EXYNOS_TMU_REF_VOLTAGE_SHIFT);
+ con |= pdata-reference_voltage EXYNOS_TMU_REF_VOLTAGE_SHIFT;
- con = ~(reg-buf_slope_sel_mask reg-buf_slope_sel_shift);
- con |= (pdata-gain reg-buf_slope_sel_shift);
+ con = ~(EXYNOS_TMU_BUF_SLOPE_SEL_MASK
EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT);
+ con |= (pdata-gain EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT);
if (pdata-noise_cancel_mode) {
con = ~(reg-therm_trip_mode_mask
@@ -228,7 +228,7 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
}
if (on) {
- con |= (1 reg-core_en_shift);
+ con |= (1 EXYNOS_TMU_CORE_EN_SHIFT);
interrupt_en =
pdata-trigger_enable[3] reg-inten_rise3_shift |
pdata-trigger_enable[2] reg-inten_rise2_shift |
@@ -238,7 +238,7 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
interrupt_en |=
interrupt_en reg-inten_fall0_shift;
} else {
- con = ~(1 reg-core_en_shift);
+ con = ~(1 EXYNOS_TMU_CORE_EN_SHIFT);
interrupt_en = 0; /* Disable all interrupts */
}
writel(interrupt_en, data-base + reg-tmu_inten);
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 4845171..5c25a4b 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -69,15 +69,9 @@ enum soc_type {
* @triminfo_ctrl: trim info controller register.
* @tmu_ctrl: TMU main controller register.
* @test_mux_addr_shift: shift bits of test mux address.
- * @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl
register.
- * @buf_vref_sel_mask: mask bits of reference voltage in tmu_ctrl
register.
* @therm_trip_mode_shift: shift bits of tripping mode in tmu_ctrl
register.
* @therm_trip_mode_mask: mask bits of tripping mode in tmu_ctrl register.
* @therm_trip_en_shift: shift bits of tripping enable in tmu_ctrl
register.
- * @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
- register.
- * @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl
register.
- * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
* @tmu_status: register drescribing the TMU status.
* @tmu_cur_temp: register containing the current temperature of the TMU.
* @threshold_temp: register containing the base threshold level.
@@ -111,14 +105,9 @@ struct exynos_tmu_registers {
u32 tmu_ctrl;
u32 test_mux_addr_shift;
- u32 buf_vref_sel_shift;
- u32 buf_vref_sel_mask;
u32 therm_trip_mode_shift;
u32 therm_trip_mode_mask;
u32 therm_trip_en_shift;
- u32 buf_slope_sel_shift;
- u32 buf_slope_sel_mask;
- u32 core_en_shift;
u32 tmu_status;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index ef7f186..32530dc 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -28,11 +28,6 @@
static const struct exynos_tmu_registers exynos4210_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
- .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
- .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
- .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
- .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
- .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
.tmu_status = EXYNOS_TMU_REG_STATUS,
.tmu_cur_temp =
Re: [PATCH 00/10] thermal: exynos: various cleanups
On 5/15/14, Zhang Rui rui.zh...@intel.com wrote: On 一, 2014-05-05 at 13:15 +0200, Bartlomiej Zolnierkiewicz wrote: Hi, This patch series contains various cleanups for EXYNOS thermal driver. Overall it decreases driver's LOC by 13%. It is based on next-20140428 kernel. It should not cause any functionality changes. Amit, what do you think of this patch set? thanks, rui I agreed to many of the cleanups in the patch but tmu controller features should be retained as they will allow adding quick soc support and also avoid unnecessary churning of code in the future. Thanks, Amit Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (10): thermal: exynos: remove unused struct exynos_tmu_registers entries thermal: exynos: remove unused defines thermal: exynos: remove dead code for HW_MODE calibration thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize() thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize() thermal: exynos: simplify temp_to_code() and code_to_temp() thermal: exynos: cache non_hw_trigger_levels in pdata thermal: exynos: remove redundant pdata checks from exynos_tmu_control() thermal: exynos: remove identical values from exynos*_tmu_registers structures drivers/thermal/samsung/exynos_thermal_common.h | 1 - drivers/thermal/samsung/exynos_tmu.c| 181 drivers/thermal/samsung/exynos_tmu.h| 86 +-- drivers/thermal/samsung/exynos_tmu_data.c | 40 +- drivers/thermal/samsung/exynos_tmu_data.h | 32 + 5 files changed, 37 insertions(+), 303 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] thermal: exynos: cache non_hw_trigger_levels in pdata
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> Cache number of non-hardware trigger levels in a new pdata field
> (non_hw_trigger_levels) and convert code in exynos_tmu_initialize()
> accordingly.
Changes looks fine,
Reviewed-by: Amit Daniel Kachhap
>
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/thermal/samsung/exynos_tmu.c | 16 +++-
> drivers/thermal/samsung/exynos_tmu.h | 2 ++
> drivers/thermal/samsung/exynos_tmu_data.c | 3 +++
> 3 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 20379eb..a8d9524 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -90,7 +90,7 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> const struct exynos_tmu_registers *reg = pdata->registers;
> unsigned int status, trim_info = 0, con;
> unsigned int rising_threshold = 0, falling_threshold = 0;
> - int ret = 0, threshold_code, i, trigger_levs = 0;
> + int ret = 0, threshold_code, i;
>
> mutex_lock(>lock);
> clk_enable(data->clk);
> @@ -134,29 +134,19 @@ static int exynos_tmu_initialize(struct
> platform_device *pdev)
> data->temp_error > pdata->max_efuse_value)
> data->temp_error = pdata->efuse_value & EXYNOS_TMU_TEMP_MASK;
>
> - for (i = 0; i < pdata->max_trigger_level; i++) {
> - if (!pdata->trigger_levels[i])
> - continue;
> -
> - /* Count trigger levels except the HW trip*/
> - if (!(pdata->trigger_type[i] == HW_TRIP))
> - trigger_levs++;
> - }
> -
> if (data->soc == SOC_ARCH_EXYNOS4210) {
> /* Write temperature code for threshold */
> threshold_code = temp_to_code(data, pdata->threshold);
> writeb(threshold_code,
> data->base + reg->threshold_temp);
> - for (i = 0; i < trigger_levs; i++)
> + for (i = 0; i < pdata->non_hw_trigger_levels; i++)
> writeb(pdata->trigger_levels[i], data->base +
> reg->threshold_th0 + i * sizeof(reg->threshold_th0));
>
> writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
> } else {
> /* Write temperature code for rising and falling threshold */
> - for (i = 0;
> - i < trigger_levs && i < EXYNOS_MAX_TRIGGER_PER_REG; i++) {
> + for (i = 0; i < pdata->non_hw_trigger_levels; i++) {
> threshold_code = temp_to_code(data,
> pdata->trigger_levels[i]);
> rising_threshold |= threshold_code << 8 * i;
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index 186e39e..4845171 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -183,6 +183,7 @@ struct exynos_tmu_registers {
> * 1 = enable trigger_level[] interrupt,
> * 0 = disable trigger_level[] interrupt
> * @max_trigger_level: max trigger level supported by the TMU
> + * @non_hw_trigger_levels: number of defined non-hardware trigger levels
> * @gain: gain of amplifier in the positive-TC generator block
> * 0 <= gain <= 15
> * @reference_voltage: reference voltage of amplifier
> @@ -213,6 +214,7 @@ struct exynos_tmu_platform_data {
> enum trigger_type trigger_type[MAX_TRIP_COUNT];
> bool trigger_enable[MAX_TRIP_COUNT];
> u8 max_trigger_level;
> + u8 non_hw_trigger_levels;
> u8 gain;
> u8 reference_voltage;
> u8 noise_cancel_mode;
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index c32d186..ef7f186 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -62,6 +62,7 @@ struct exynos_tmu_init_data const
> exynos4210_default_tmu_data = {
> .trigger_type[1] = THROTTLE_ACTIVE,
> .trigger_type[2] = SW_TRIP,
> .max_trigger_level = 4,
> + .non_hw_trigger_levels = 3,
> .gain = 15,
> .reference_voltage = 7,
> .min_efuse_value = 40,
> @@ -135,6 +136,7 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .trigger_type[2] = SW_TRIP, \
> .trigger_type[3] = HW_TRIP, \
> .max_trigger_level = 4, \
> + .non_hw_trigger_levels = 3, \
> .gain = 8, \
> .reference_voltage = 16, \
> .noise_cancel_mode = 4, \
> @@ -225,6 +227,7 @@ static const struct exynos_tmu_registers
> exynos5440_tmu_registers = {
> .trigger_type[0] = SW_TRIP, \
> .trigger_type[4] = HW_TRIP, \
> .max_trigger_level = 5, \
> + .non_hw_trigger_levels = 1, \
>
Re: [PATCH 07/10] thermal: exynos: simplify temp_to_code() and code_to_temp()
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> * Remove dead temp check from temp_to_code() (this function users
> in exynos_tmu_initialize() always pass correct temperatures and
> exynos_tmu_set_emulation() returns early for EXYNOS4210 because
> TMU_SUPPORT_EMULATION flag is not set on this SoC).
>
> * Move temp_code check from code_to_temp() to exynos_tmu_read()
> (code_to_temp() only user).
>
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Changes looks fine.
Reviewed-by: Amit Daniel Kachhap
> ---
> drivers/thermal/samsung/exynos_tmu.c | 38
> +++-
> 1 file changed, 11 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index a415829..20379eb 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -71,19 +71,7 @@ struct exynos_tmu_data {
> */
> static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
> {
> - struct exynos_tmu_platform_data *pdata = data->pdata;
> - int temp_code;
> -
> - if (data->soc == SOC_ARCH_EXYNOS4210)
> - /* temp should range between 25 and 125 */
> - if (temp < 25 || temp > 125) {
> - temp_code = -EINVAL;
> - goto out;
> - }
> -
> - temp_code = temp + data->temp_error - pdata->first_point_trim;
> -out:
> - return temp_code;
> + return temp + data->temp_error - data->pdata->first_point_trim;
> }
>
> /*
> @@ -92,19 +80,7 @@ out:
> */
> static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
> {
> - struct exynos_tmu_platform_data *pdata = data->pdata;
> - int temp;
> -
> - if (data->soc == SOC_ARCH_EXYNOS4210)
> - /* temp_code should range between 75 and 175 */
> - if (temp_code < 75 || temp_code > 175) {
> - temp = -ENODATA;
> - goto out;
> - }
> -
> - temp = temp_code - data->temp_error + pdata->first_point_trim;
> -out:
> - return temp;
> + return temp_code - data->temp_error + data->pdata->first_point_trim;
> }
>
> static int exynos_tmu_initialize(struct platform_device *pdev)
> @@ -297,8 +273,16 @@ static int exynos_tmu_read(struct exynos_tmu_data
> *data)
> clk_enable(data->clk);
>
> temp_code = readb(data->base + reg->tmu_cur_temp);
> - temp = code_to_temp(data, temp_code);
>
> + if (data->soc == SOC_ARCH_EXYNOS4210)
> + /* temp_code should range between 75 and 175 */
> + if (temp_code < 75 || temp_code > 175) {
> + temp = -ENODATA;
> + goto out;
> + }
> +
> + temp = code_to_temp(data, temp_code);
> +out:
> clk_disable(data->clk);
> mutex_unlock(>lock);
>
> --
> 1.8.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10] thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize()
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> Remove runtime checks for negative return values of temp_to_code()
> from exynos_tmu_initialize(). The current level temperature data
> hardcoded in pdata will never cause a negative temp_to_code()
> return values and for the new code potential mistakes should be
> caught during development/review phases.
Your arguments looks fine.
>
> Theres should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/thermal/samsung/exynos_tmu.c | 16 +---
> 1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 789d745..a415829 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -170,10 +170,6 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> if (data->soc == SOC_ARCH_EXYNOS4210) {
> /* Write temperature code for threshold */
> threshold_code = temp_to_code(data, pdata->threshold);
> - if (threshold_code < 0) {
> - ret = threshold_code;
> - goto out;
> - }
> writeb(threshold_code,
> data->base + reg->threshold_temp);
> for (i = 0; i < trigger_levs; i++)
> @@ -187,18 +183,12 @@ static int exynos_tmu_initialize(struct
> platform_device *pdev)
> i < trigger_levs && i < EXYNOS_MAX_TRIGGER_PER_REG; i++) {
> threshold_code = temp_to_code(data,
> pdata->trigger_levels[i]);
> - if (threshold_code < 0) {
> - ret = threshold_code;
> - goto out;
> - }
> rising_threshold |= threshold_code << 8 * i;
> if (pdata->threshold_falling) {
> threshold_code = temp_to_code(data,
> pdata->trigger_levels[i] -
> pdata->threshold_falling);
> - if (threshold_code > 0)
> - falling_threshold |=
> - threshold_code << 8 * i;
> + falling_threshold |= threshold_code << 8 * i;
> }
> }
>
> @@ -217,10 +207,6 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> (pdata->trigger_type[i] == HW_TRIP)) {
> threshold_code = temp_to_code(data,
> pdata->trigger_levels[i]);
> - if (threshold_code < 0) {
> - ret = threshold_code;
> - goto out;
> - }
> if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
> /* 1-4 level to be assigned in th0 reg */
> rising_threshold |= threshold_code << 8 * i;
> --
> 1.8.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize()
On 5/15/14, Bartlomiej Zolnierkiewicz wrote:
> On Thursday, May 15, 2014 10:47:40 AM Eduardo Valentin wrote:
>> Hello Bartlomiej,
>
> Hi,
>
>> On Mon, May 05, 2014 at 01:15:34PM +0200, Bartlomiej Zolnierkiewicz
>> wrote:
>> > Remove runtime checks for pdata sanity from exynos_tmu_initialize().
>> > The current values hardcoded in pdata will never trigger the checks
>> > and for the new code potential mistakes should be caught during
>> > development/review phases.
>> >
>> > There should be no functional changes caused by this patch.
>> >
>> > Signed-off-by: Bartlomiej Zolnierkiewicz
>> > ---
>> > drivers/thermal/samsung/exynos_thermal_common.h | 1 -
>> > drivers/thermal/samsung/exynos_tmu.c| 13 -
>> > 2 files changed, 14 deletions(-)
>> >
>> > diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
>> > b/drivers/thermal/samsung/exynos_thermal_common.h
>> > index 3eb2ed9..cd44719 100644
>> > --- a/drivers/thermal/samsung/exynos_thermal_common.h
>> > +++ b/drivers/thermal/samsung/exynos_thermal_common.h
>> > @@ -27,7 +27,6 @@
>> > #define SENSOR_NAME_LEN 16
>> > #define MAX_TRIP_COUNT8
>> > #define MAX_COOLING_DEVICE 4
>> > -#define MAX_THRESHOLD_LEVS 5
>> >
>> > #define ACTIVE_INTERVAL 500
>> > #define IDLE_INTERVAL 1
>> > diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> > b/drivers/thermal/samsung/exynos_tmu.c
>> > index 903566f..789d745 100644
>> > --- a/drivers/thermal/samsung/exynos_tmu.c
>> > +++ b/drivers/thermal/samsung/exynos_tmu.c
>> > @@ -158,23 +158,10 @@ static int exynos_tmu_initialize(struct
>> > platform_device *pdev)
>> >data->temp_error > pdata->max_efuse_value)
>> >data->temp_error = pdata->efuse_value & EXYNOS_TMU_TEMP_MASK;
>> >
>> > - if (pdata->max_trigger_level > MAX_THRESHOLD_LEVS) {
>> > - dev_err(>dev, "Invalid max trigger level\n");
>> > - ret = -EINVAL;
>> > - goto out;
>> > - }
>> > -
>> >for (i = 0; i < pdata->max_trigger_level; i++) {
>> >if (!pdata->trigger_levels[i])
>> >continue;
>> >
>> > - if ((pdata->trigger_type[i] == HW_TRIP) &&
>> > - (!pdata->trigger_levels[pdata->max_trigger_level - 1])) {
>> > - dev_err(>dev, "Invalid hw trigger level\n");
>> > - ret = -EINVAL;
>> > - goto out;
>> > - }
>> > -
>>
>> Does it mean no new pdata are going to be written? i.e., no new soc is
>> going to be supported by this driver that needs proper pdata checking?
>
> This is not a proper checking. The checks in question are done at runtime
> in a production code for data that is hardcoded inside driver during
> development time and later it doesn't change. Such data should be verified
> during development and review time (i.e. by a script parsing relevant data
> from exynos_tmu_data.c, one can also argue that verification to be done is
> so simple that the review by a maintainer should be enough).
Agreed to your arguments. These changes looks fine.
>
>> >/* Count trigger levels except the HW trip*/
>> >if (!(pdata->trigger_type[i] == HW_TRIP))
>> >trigger_levs++;
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> Only TYPE_ONE_POINT_TRIMMING calibration is used so remove
> the dead code for TYPE_TWO_POINT_TRIMMING calibration.
I prefer to retain this feature as it is provided by the TMU
controller. This will avoid unnecessary churning of code when some new
soc wants to use it. 2 point trimming should ideally give best
compensated thermal values.
>
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/thermal/samsung/exynos_tmu.c | 55
> ++-
> drivers/thermal/samsung/exynos_tmu.h | 20 +--
> drivers/thermal/samsung/exynos_tmu_data.c | 17 +-
> drivers/thermal/samsung/exynos_tmu_data.h | 2 --
> 4 files changed, 12 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 9f2a5ee..903566f 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -47,8 +47,7 @@
> * @irq_work: pointer to the irq work structure.
> * @lock: lock to implement synchronization.
> * @clk: pointer to the clock structure.
> - * @temp_error1: fused value of the first point trim.
> - * @temp_error2: fused value of the second point trim.
> + * @temp_error: fused value of the first point trim.
> * @regulator: pointer to the TMU regulator structure.
> * @reg_conf: pointer to structure to register with core thermal.
> */
> @@ -62,14 +61,13 @@ struct exynos_tmu_data {
> struct work_struct irq_work;
> struct mutex lock;
> struct clk *clk;
> - u8 temp_error1, temp_error2;
> + u8 temp_error;
> struct regulator *regulator;
> struct thermal_sensor_conf *reg_conf;
> };
>
> /*
> * TMU treats temperature as a mapped temperature code.
> - * The temperature is converted differently depending on the calibration
> type.
> */
> static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
> {
> @@ -83,20 +81,7 @@ static int temp_to_code(struct exynos_tmu_data *data, u8
> temp)
> goto out;
> }
>
> - switch (pdata->cal_type) {
> - case TYPE_TWO_POINT_TRIMMING:
> - temp_code = (temp - pdata->first_point_trim) *
> - (data->temp_error2 - data->temp_error1) /
> - (pdata->second_point_trim - pdata->first_point_trim) +
> - data->temp_error1;
> - break;
> - case TYPE_ONE_POINT_TRIMMING:
> - temp_code = temp + data->temp_error1 - pdata->first_point_trim;
> - break;
> - default:
> - temp_code = temp + pdata->default_temp_offset;
> - break;
> - }
> + temp_code = temp + data->temp_error - pdata->first_point_trim;
> out:
> return temp_code;
> }
> @@ -117,20 +102,7 @@ static int code_to_temp(struct exynos_tmu_data *data,
> u8 temp_code)
> goto out;
> }
>
> - switch (pdata->cal_type) {
> - case TYPE_TWO_POINT_TRIMMING:
> - temp = (temp_code - data->temp_error1) *
> - (pdata->second_point_trim - pdata->first_point_trim) /
> - (data->temp_error2 - data->temp_error1) +
> - pdata->first_point_trim;
> - break;
> - case TYPE_ONE_POINT_TRIMMING:
> - temp = temp_code - data->temp_error1 + pdata->first_point_trim;
> - break;
> - default:
> - temp = temp_code - pdata->default_temp_offset;
> - break;
> - }
> + temp = temp_code - data->temp_error + pdata->first_point_trim;
> out:
> return temp;
> }
> @@ -179,19 +151,12 @@ static int exynos_tmu_initialize(struct
> platform_device *pdev)
> } else {
> trim_info = readl(data->base + reg->triminfo_data);
> }
> - data->temp_error1 = trim_info & EXYNOS_TMU_TEMP_MASK;
> - data->temp_error2 = ((trim_info >> reg->triminfo_85_shift) &
> - EXYNOS_TMU_TEMP_MASK);
> -
> - if (!data->temp_error1 ||
> - (pdata->min_efuse_value > data->temp_error1) ||
> - (data->temp_error1 > pdata->max_efuse_value))
> - data->temp_error1 = pdata->efuse_value & EXYNOS_TMU_TEMP_MASK;
> -
> - if (!data->temp_error2)
> - data->temp_error2 =
> - (pdata->efuse_value >> reg->triminfo_85_shift) &
> - EXYNOS_TMU_TEMP_MASK;
> + data->temp_error = trim_info & EXYNOS_TMU_TEMP_MASK;
> +
> + if (!data->temp_error ||
> + pdata->min_efuse_value > data->temp_error ||
> + data->temp_error > pdata->max_efuse_value)
> + data->temp_error = pdata->efuse_value & EXYNOS_TMU_TEMP_MASK;
>
> if (pdata->max_trigger_level > MAX_THRESHOLD_LEVS) {
> dev_err(>dev, "Invalid max trigger level\n");
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
>
Re: [PATCH 03/10] thermal: exynos: remove dead code for HW_MODE calibration
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/thermal/samsung/exynos_tmu.c | 33
> +--
> drivers/thermal/samsung/exynos_tmu.h | 13
> drivers/thermal/samsung/exynos_tmu_data.c | 3 ---
> drivers/thermal/samsung/exynos_tmu_data.h | 2 --
> 4 files changed, 1 insertion(+), 50 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 0d96a51..9f2a5ee 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -76,9 +76,6 @@ static int temp_to_code(struct exynos_tmu_data *data, u8
> temp)
> struct exynos_tmu_platform_data *pdata = data->pdata;
> int temp_code;
>
> - if (pdata->cal_mode == HW_MODE)
> - return temp;
> -
I suggest to retain the hw mode generic feature as it is provided by
the TMU controller. However below unused defines for 5440 might be
removed as the h/w mode relevant values were wrongly fused.
> if (data->soc == SOC_ARCH_EXYNOS4210)
> /* temp should range between 25 and 125 */
> if (temp < 25 || temp > 125) {
> @@ -113,9 +110,6 @@ static int code_to_temp(struct exynos_tmu_data *data, u8
> temp_code)
> struct exynos_tmu_platform_data *pdata = data->pdata;
> int temp;
>
> - if (pdata->cal_mode == HW_MODE)
> - return temp_code;
> -
> if (data->soc == SOC_ARCH_EXYNOS4210)
> /* temp_code should range between 75 and 175 */
> if (temp_code < 75 || temp_code > 175) {
> @@ -164,9 +158,6 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
> __raw_writel(1, data->base + reg->triminfo_ctrl);
>
> - if (pdata->cal_mode == HW_MODE)
> - goto skip_calib_data;
> -
> /* Save trimming info in order to perform calibration */
> if (data->soc == SOC_ARCH_EXYNOS5440) {
> /*
> @@ -202,7 +193,6 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> (pdata->efuse_value >> reg->triminfo_85_shift) &
> EXYNOS_TMU_TEMP_MASK;
>
> -skip_calib_data:
> if (pdata->max_trigger_level > MAX_THRESHOLD_LEVS) {
> dev_err(>dev, "Invalid max trigger level\n");
> ret = -EINVAL;
> @@ -311,7 +301,7 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> struct exynos_tmu_platform_data *pdata = data->pdata;
> const struct exynos_tmu_registers *reg = pdata->registers;
> - unsigned int con, interrupt_en, cal_val;
> + unsigned int con, interrupt_en;
>
> mutex_lock(>lock);
> clk_enable(data->clk);
> @@ -337,27 +327,6 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
> con |= (pdata->noise_cancel_mode << reg->therm_trip_mode_shift);
> }
>
> - if (pdata->cal_mode == HW_MODE) {
> - con &= ~(reg->calib_mode_mask << reg->calib_mode_shift);
> - cal_val = 0;
> - switch (pdata->cal_type) {
> - case TYPE_TWO_POINT_TRIMMING:
> - cal_val = 3;
> - break;
> - case TYPE_ONE_POINT_TRIMMING_85:
> - cal_val = 2;
> - break;
> - case TYPE_ONE_POINT_TRIMMING_25:
> - cal_val = 1;
> - break;
> - case TYPE_NONE:
> - break;
> - default:
> - dev_err(>dev, "Invalid calibration type, using
> none\n");
> - }
> - con |= cal_val << reg->calib_mode_shift;
> - }
> -
> if (on) {
> con |= (1 << reg->core_en_shift);
> interrupt_en =
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index 80dc899..e417af8 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -34,11 +34,6 @@ enum calibration_type {
> TYPE_NONE,
> };
>
> -enum calibration_mode {
> - SW_MODE,
> - HW_MODE,
> -};
> -
> enum soc_type {
> SOC_ARCH_EXYNOS4210 = 1,
> SOC_ARCH_EXYNOS4412,
> @@ -92,10 +87,6 @@ enum soc_type {
> * @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
> register.
> * @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl
> register.
> - * @calib_mode_shift: shift bits of calibration mode value in tmu_ctrl
> - register.
> - * @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
> - register.
> * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
> * @tmu_status: register drescribing the TMU
Re: [PATCH 02/10] thermal: exynos: remove unused defines
Hi Bartlomiej, On 5/5/14, Bartlomiej Zolnierkiewicz wrote: > There should be no functional changes caused by this patch. > > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > drivers/thermal/samsung/exynos_tmu_data.h | 27 +-- > 1 file changed, 1 insertion(+), 26 deletions(-) > > diff --git a/drivers/thermal/samsung/exynos_tmu_data.h > b/drivers/thermal/samsung/exynos_tmu_data.h > index 06c4345..d4eeddb 100644 > --- a/drivers/thermal/samsung/exynos_tmu_data.h > +++ b/drivers/thermal/samsung/exynos_tmu_data.h > @@ -42,20 +42,8 @@ > /* Exynos4210 specific registers */ > #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP0x44 > #define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50 > -#define EXYNOS4210_TMU_REG_TRIG_LEVEL1 0x54 > -#define EXYNOS4210_TMU_REG_TRIG_LEVEL2 0x58 > -#define EXYNOS4210_TMU_REG_TRIG_LEVEL3 0x5C > -#define EXYNOS4210_TMU_REG_PAST_TEMP00x60 > -#define EXYNOS4210_TMU_REG_PAST_TEMP10x64 > -#define EXYNOS4210_TMU_REG_PAST_TEMP20x68 > -#define EXYNOS4210_TMU_REG_PAST_TEMP30x6C > - This removal looks fine as 4210 is an old soc. > -#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK 0x1 > -#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK 0x10 > -#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK 0x100 > -#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK 0x1000 > + > #define EXYNOS4210_TMU_TRIG_LEVEL_MASK 0x > -#define EXYNOS4210_TMU_INTCLEAR_VAL 0x > > /* Exynos5250 and Exynos4412 specific registers */ > #define EXYNOS_TMU_TRIMINFO_CON 0x14 > @@ -69,8 +57,6 @@ > #define EXYNOS_TMU_RISE_INT_SHIFT0 > #define EXYNOS_TMU_FALL_INT_MASK 0x111 > #define EXYNOS_TMU_FALL_INT_SHIFT12 > -#define EXYNOS_TMU_CLEAR_RISE_INT0x111 > -#define EXYNOS_TMU_CLEAR_FALL_INT(0x111 << 12) > #define EXYNOS_TMU_TRIP_MODE_SHIFT 13 > #define EXYNOS_TMU_TRIP_MODE_MASK0x7 > #define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12 > @@ -82,8 +68,6 @@ > #define EXYNOS_TMU_INTEN_RISE2_SHIFT 8 > #define EXYNOS_TMU_INTEN_RISE3_SHIFT 12 > #define EXYNOS_TMU_INTEN_FALL0_SHIFT 16 > -#define EXYNOS_TMU_INTEN_FALL1_SHIFT 20 > -#define EXYNOS_TMU_INTEN_FALL2_SHIFT 24 I suggest to retain this generic soc macros as they might be used in future. > > #define EXYNOS_EMUL_TIME 0x57F0 > #define EXYNOS_EMUL_TIME_MASK0x > @@ -107,13 +91,11 @@ > #define EXYNOS5440_TMU_S0_7_TH0 0x110 > #define EXYNOS5440_TMU_S0_7_TH1 0x130 > #define EXYNOS5440_TMU_S0_7_TH2 0x150 > -#define EXYNOS5440_TMU_S0_7_EVTEN0x1F0 > #define EXYNOS5440_TMU_S0_7_IRQEN0x210 > #define EXYNOS5440_TMU_S0_7_IRQ 0x230 > /* exynos5440 common registers */ > #define EXYNOS5440_TMU_IRQ_STATUS0x000 > #define EXYNOS5440_TMU_PMIN 0x004 > -#define EXYNOS5440_TMU_TEMP 0x008 > > #define EXYNOS5440_TMU_RISE_INT_MASK 0xf > #define EXYNOS5440_TMU_RISE_INT_SHIFT0 > @@ -124,13 +106,6 @@ > #define EXYNOS5440_TMU_INTEN_RISE2_SHIFT 2 > #define EXYNOS5440_TMU_INTEN_RISE3_SHIFT 3 > #define EXYNOS5440_TMU_INTEN_FALL0_SHIFT 4 > -#define EXYNOS5440_TMU_INTEN_FALL1_SHIFT 5 > -#define EXYNOS5440_TMU_INTEN_FALL2_SHIFT 6 > -#define EXYNOS5440_TMU_INTEN_FALL3_SHIFT 7 > -#define EXYNOS5440_TMU_TH_RISE0_SHIFT0 > -#define EXYNOS5440_TMU_TH_RISE1_SHIFT8 > -#define EXYNOS5440_TMU_TH_RISE2_SHIFT16 > -#define EXYNOS5440_TMU_TH_RISE3_SHIFT24 5440 is an old soc so can be removed. > #define EXYNOS5440_TMU_TH_RISE4_SHIFT24 > #define EXYNOS5440_EFUSE_SWAP_OFFSET 8 > > -- > 1.8.2.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] thermal: exynos: remove unused struct exynos_tmu_registers entries
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz wrote:
> There should be no functional changes caused by this patch.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/thermal/samsung/exynos_tmu.h | 40
> ---
> drivers/thermal/samsung/exynos_tmu_data.c | 2 --
> drivers/thermal/samsung/exynos_tmu_data.h | 1 -
> 3 files changed, 43 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index 3fb6554..80dc899 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -82,8 +82,6 @@ enum soc_type {
> * @triminfo_25_shift: shift bit of the 25 C trim value in triminfo_data
> reg.
> * @triminfo_85_shift: shift bit of the 85 C trim value in triminfo_data
> reg.
> * @triminfo_ctrl: trim info controller register.
> - * @triminfo_reload_shift: shift of triminfo reload enable bit in
> triminfo_ctrl
> - reg.
> * @tmu_ctrl: TMU main controller register.
> * @test_mux_addr_shift: shift bits of test mux address.
> * @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl
> register.
> @@ -98,27 +96,13 @@ enum soc_type {
> register.
> * @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
> register.
> - * @therm_trip_tq_en_shift: shift bits of thermal trip enable by TQ pin in
> - tmu_ctrl register.
> * @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
> * @tmu_status: register drescribing the TMU status.
> * @tmu_cur_temp: register containing the current temperature of the TMU.
> - * @tmu_cur_temp_shift: shift bits of current temp value in tmu_cur_temp
> - register.
> * @threshold_temp: register containing the base threshold level.
> * @threshold_th0: Register containing first set of rising levels.
> - * @threshold_th0_l0_shift: shift bits of level0 threshold temperature.
> - * @threshold_th0_l1_shift: shift bits of level1 threshold temperature.
> - * @threshold_th0_l2_shift: shift bits of level2 threshold temperature.
> - * @threshold_th0_l3_shift: shift bits of level3 threshold temperature.
> * @threshold_th1: Register containing second set of rising levels.
> - * @threshold_th1_l0_shift: shift bits of level0 threshold temperature.
> - * @threshold_th1_l1_shift: shift bits of level1 threshold temperature.
> - * @threshold_th1_l2_shift: shift bits of level2 threshold temperature.
> - * @threshold_th1_l3_shift: shift bits of level3 threshold temperature.
> * @threshold_th2: Register containing third set of rising levels.
> - * @threshold_th2_l0_shift: shift bits of level0 threshold temperature.
> - * @threshold_th3: Register containing fourth set of rising levels.
> * @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
> * @tmu_inten: register containing the different threshold interrupt
> enable bits.
> @@ -131,15 +115,11 @@ enum soc_type {
> * @inten_rise2_shift: shift bits of rising 2 interrupt bits.
> * @inten_rise3_shift: shift bits of rising 3 interrupt bits.
> * @inten_fall0_shift: shift bits of falling 0 interrupt bits.
> - * @inten_fall1_shift: shift bits of falling 1 interrupt bits.
> - * @inten_fall2_shift: shift bits of falling 2 interrupt bits.
> - * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
> * @tmu_intstat: Register containing the interrupt status values.
> * @tmu_intclear: Register for clearing the raised interrupt status.
> * @emul_con: TMU emulation controller register.
> * @emul_temp_shift: shift bits of emulation temperature.
> * @emul_time_shift: shift bits of emulation time.
> - * @emul_time_mask: mask bits of emulation time.
> * @tmu_irqstatus: register to find which TMU generated interrupts.
> * @tmu_pmin: register to get/set the Pmin value.
I prefer to have these register description as they describe the h/w
and are used for capturing those parameters. My argument here is that
adding new soc should have minimum changes. However some unused macros
removed below makes sense.
> */
> @@ -149,7 +129,6 @@ struct exynos_tmu_registers {
> u32 triminfo_85_shift;
>
> u32 triminfo_ctrl;
> - u32 triminfo_reload_shift;
>
> u32 tmu_ctrl;
> u32 test_mux_addr_shift;
> @@ -162,32 +141,17 @@ struct exynos_tmu_registers {
> u32 buf_slope_sel_mask;
> u32 calib_mode_shift;
> u32 calib_mode_mask;
> - u32 therm_trip_tq_en_shift;
> u32 core_en_shift;
>
> u32 tmu_status;
>
> u32 tmu_cur_temp;
> - u32 tmu_cur_temp_shift;
>
> u32 threshold_temp;
>
> u32 threshold_th0;
> - u32 threshold_th0_l0_shift;
> - u32 threshold_th0_l1_shift;
> - u32 threshold_th0_l2_shift;
> - u32 threshold_th0_l3_shift;
> -
> u32 threshold_th1;
> - u32 threshold_th1_l0_shift;
> - u32 threshold_th1_l1_shift;
> - u32
Re: [PATCH 01/10] thermal: exynos: remove unused struct exynos_tmu_registers entries
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.h | 40
---
drivers/thermal/samsung/exynos_tmu_data.c | 2 --
drivers/thermal/samsung/exynos_tmu_data.h | 1 -
3 files changed, 43 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..80dc899 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -82,8 +82,6 @@ enum soc_type {
* @triminfo_25_shift: shift bit of the 25 C trim value in triminfo_data
reg.
* @triminfo_85_shift: shift bit of the 85 C trim value in triminfo_data
reg.
* @triminfo_ctrl: trim info controller register.
- * @triminfo_reload_shift: shift of triminfo reload enable bit in
triminfo_ctrl
- reg.
* @tmu_ctrl: TMU main controller register.
* @test_mux_addr_shift: shift bits of test mux address.
* @buf_vref_sel_shift: shift bits of reference voltage in tmu_ctrl
register.
@@ -98,27 +96,13 @@ enum soc_type {
register.
* @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
register.
- * @therm_trip_tq_en_shift: shift bits of thermal trip enable by TQ pin in
- tmu_ctrl register.
* @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
* @tmu_status: register drescribing the TMU status.
* @tmu_cur_temp: register containing the current temperature of the TMU.
- * @tmu_cur_temp_shift: shift bits of current temp value in tmu_cur_temp
- register.
* @threshold_temp: register containing the base threshold level.
* @threshold_th0: Register containing first set of rising levels.
- * @threshold_th0_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th0_l1_shift: shift bits of level1 threshold temperature.
- * @threshold_th0_l2_shift: shift bits of level2 threshold temperature.
- * @threshold_th0_l3_shift: shift bits of level3 threshold temperature.
* @threshold_th1: Register containing second set of rising levels.
- * @threshold_th1_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th1_l1_shift: shift bits of level1 threshold temperature.
- * @threshold_th1_l2_shift: shift bits of level2 threshold temperature.
- * @threshold_th1_l3_shift: shift bits of level3 threshold temperature.
* @threshold_th2: Register containing third set of rising levels.
- * @threshold_th2_l0_shift: shift bits of level0 threshold temperature.
- * @threshold_th3: Register containing fourth set of rising levels.
* @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
* @tmu_inten: register containing the different threshold interrupt
enable bits.
@@ -131,15 +115,11 @@ enum soc_type {
* @inten_rise2_shift: shift bits of rising 2 interrupt bits.
* @inten_rise3_shift: shift bits of rising 3 interrupt bits.
* @inten_fall0_shift: shift bits of falling 0 interrupt bits.
- * @inten_fall1_shift: shift bits of falling 1 interrupt bits.
- * @inten_fall2_shift: shift bits of falling 2 interrupt bits.
- * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
- * @emul_time_mask: mask bits of emulation time.
* @tmu_irqstatus: register to find which TMU generated interrupts.
* @tmu_pmin: register to get/set the Pmin value.
I prefer to have these register description as they describe the h/w
and are used for capturing those parameters. My argument here is that
adding new soc should have minimum changes. However some unused macros
removed below makes sense.
*/
@@ -149,7 +129,6 @@ struct exynos_tmu_registers {
u32 triminfo_85_shift;
u32 triminfo_ctrl;
- u32 triminfo_reload_shift;
u32 tmu_ctrl;
u32 test_mux_addr_shift;
@@ -162,32 +141,17 @@ struct exynos_tmu_registers {
u32 buf_slope_sel_mask;
u32 calib_mode_shift;
u32 calib_mode_mask;
- u32 therm_trip_tq_en_shift;
u32 core_en_shift;
u32 tmu_status;
u32 tmu_cur_temp;
- u32 tmu_cur_temp_shift;
u32 threshold_temp;
u32 threshold_th0;
- u32 threshold_th0_l0_shift;
- u32 threshold_th0_l1_shift;
- u32 threshold_th0_l2_shift;
- u32 threshold_th0_l3_shift;
-
u32 threshold_th1;
- u32 threshold_th1_l0_shift;
- u32 threshold_th1_l1_shift;
- u32 threshold_th1_l2_shift;
- u32 threshold_th1_l3_shift;
-
Re: [PATCH 02/10] thermal: exynos: remove unused defines
Hi Bartlomiej, On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- drivers/thermal/samsung/exynos_tmu_data.h | 27 +-- 1 file changed, 1 insertion(+), 26 deletions(-) diff --git a/drivers/thermal/samsung/exynos_tmu_data.h b/drivers/thermal/samsung/exynos_tmu_data.h index 06c4345..d4eeddb 100644 --- a/drivers/thermal/samsung/exynos_tmu_data.h +++ b/drivers/thermal/samsung/exynos_tmu_data.h @@ -42,20 +42,8 @@ /* Exynos4210 specific registers */ #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP0x44 #define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL1 0x54 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL2 0x58 -#define EXYNOS4210_TMU_REG_TRIG_LEVEL3 0x5C -#define EXYNOS4210_TMU_REG_PAST_TEMP00x60 -#define EXYNOS4210_TMU_REG_PAST_TEMP10x64 -#define EXYNOS4210_TMU_REG_PAST_TEMP20x68 -#define EXYNOS4210_TMU_REG_PAST_TEMP30x6C - This removal looks fine as 4210 is an old soc. -#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK 0x1 -#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK 0x10 -#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK 0x100 -#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK 0x1000 + #define EXYNOS4210_TMU_TRIG_LEVEL_MASK 0x -#define EXYNOS4210_TMU_INTCLEAR_VAL 0x /* Exynos5250 and Exynos4412 specific registers */ #define EXYNOS_TMU_TRIMINFO_CON 0x14 @@ -69,8 +57,6 @@ #define EXYNOS_TMU_RISE_INT_SHIFT0 #define EXYNOS_TMU_FALL_INT_MASK 0x111 #define EXYNOS_TMU_FALL_INT_SHIFT12 -#define EXYNOS_TMU_CLEAR_RISE_INT0x111 -#define EXYNOS_TMU_CLEAR_FALL_INT(0x111 12) #define EXYNOS_TMU_TRIP_MODE_SHIFT 13 #define EXYNOS_TMU_TRIP_MODE_MASK0x7 #define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12 @@ -82,8 +68,6 @@ #define EXYNOS_TMU_INTEN_RISE2_SHIFT 8 #define EXYNOS_TMU_INTEN_RISE3_SHIFT 12 #define EXYNOS_TMU_INTEN_FALL0_SHIFT 16 -#define EXYNOS_TMU_INTEN_FALL1_SHIFT 20 -#define EXYNOS_TMU_INTEN_FALL2_SHIFT 24 I suggest to retain this generic soc macros as they might be used in future. #define EXYNOS_EMUL_TIME 0x57F0 #define EXYNOS_EMUL_TIME_MASK0x @@ -107,13 +91,11 @@ #define EXYNOS5440_TMU_S0_7_TH0 0x110 #define EXYNOS5440_TMU_S0_7_TH1 0x130 #define EXYNOS5440_TMU_S0_7_TH2 0x150 -#define EXYNOS5440_TMU_S0_7_EVTEN0x1F0 #define EXYNOS5440_TMU_S0_7_IRQEN0x210 #define EXYNOS5440_TMU_S0_7_IRQ 0x230 /* exynos5440 common registers */ #define EXYNOS5440_TMU_IRQ_STATUS0x000 #define EXYNOS5440_TMU_PMIN 0x004 -#define EXYNOS5440_TMU_TEMP 0x008 #define EXYNOS5440_TMU_RISE_INT_MASK 0xf #define EXYNOS5440_TMU_RISE_INT_SHIFT0 @@ -124,13 +106,6 @@ #define EXYNOS5440_TMU_INTEN_RISE2_SHIFT 2 #define EXYNOS5440_TMU_INTEN_RISE3_SHIFT 3 #define EXYNOS5440_TMU_INTEN_FALL0_SHIFT 4 -#define EXYNOS5440_TMU_INTEN_FALL1_SHIFT 5 -#define EXYNOS5440_TMU_INTEN_FALL2_SHIFT 6 -#define EXYNOS5440_TMU_INTEN_FALL3_SHIFT 7 -#define EXYNOS5440_TMU_TH_RISE0_SHIFT0 -#define EXYNOS5440_TMU_TH_RISE1_SHIFT8 -#define EXYNOS5440_TMU_TH_RISE2_SHIFT16 -#define EXYNOS5440_TMU_TH_RISE3_SHIFT24 5440 is an old soc so can be removed. #define EXYNOS5440_TMU_TH_RISE4_SHIFT24 #define EXYNOS5440_EFUSE_SWAP_OFFSET 8 -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] thermal: exynos: remove dead code for HW_MODE calibration
Hi Bartlomiej,
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 33
+--
drivers/thermal/samsung/exynos_tmu.h | 13
drivers/thermal/samsung/exynos_tmu_data.c | 3 ---
drivers/thermal/samsung/exynos_tmu_data.h | 2 --
4 files changed, 1 insertion(+), 50 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 0d96a51..9f2a5ee 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -76,9 +76,6 @@ static int temp_to_code(struct exynos_tmu_data *data, u8
temp)
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp_code;
- if (pdata-cal_mode == HW_MODE)
- return temp;
-
I suggest to retain the hw mode generic feature as it is provided by
the TMU controller. However below unused defines for 5440 might be
removed as the h/w mode relevant values were wrongly fused.
if (data-soc == SOC_ARCH_EXYNOS4210)
/* temp should range between 25 and 125 */
if (temp 25 || temp 125) {
@@ -113,9 +110,6 @@ static int code_to_temp(struct exynos_tmu_data *data, u8
temp_code)
struct exynos_tmu_platform_data *pdata = data-pdata;
int temp;
- if (pdata-cal_mode == HW_MODE)
- return temp_code;
-
if (data-soc == SOC_ARCH_EXYNOS4210)
/* temp_code should range between 75 and 175 */
if (temp_code 75 || temp_code 175) {
@@ -164,9 +158,6 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
__raw_writel(1, data-base + reg-triminfo_ctrl);
- if (pdata-cal_mode == HW_MODE)
- goto skip_calib_data;
-
/* Save trimming info in order to perform calibration */
if (data-soc == SOC_ARCH_EXYNOS5440) {
/*
@@ -202,7 +193,6 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
(pdata-efuse_value reg-triminfo_85_shift)
EXYNOS_TMU_TEMP_MASK;
-skip_calib_data:
if (pdata-max_trigger_level MAX_THRESHOLD_LEVS) {
dev_err(pdev-dev, Invalid max trigger level\n);
ret = -EINVAL;
@@ -311,7 +301,7 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
struct exynos_tmu_platform_data *pdata = data-pdata;
const struct exynos_tmu_registers *reg = pdata-registers;
- unsigned int con, interrupt_en, cal_val;
+ unsigned int con, interrupt_en;
mutex_lock(data-lock);
clk_enable(data-clk);
@@ -337,27 +327,6 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
con |= (pdata-noise_cancel_mode reg-therm_trip_mode_shift);
}
- if (pdata-cal_mode == HW_MODE) {
- con = ~(reg-calib_mode_mask reg-calib_mode_shift);
- cal_val = 0;
- switch (pdata-cal_type) {
- case TYPE_TWO_POINT_TRIMMING:
- cal_val = 3;
- break;
- case TYPE_ONE_POINT_TRIMMING_85:
- cal_val = 2;
- break;
- case TYPE_ONE_POINT_TRIMMING_25:
- cal_val = 1;
- break;
- case TYPE_NONE:
- break;
- default:
- dev_err(pdev-dev, Invalid calibration type, using
none\n);
- }
- con |= cal_val reg-calib_mode_shift;
- }
-
if (on) {
con |= (1 reg-core_en_shift);
interrupt_en =
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 80dc899..e417af8 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -34,11 +34,6 @@ enum calibration_type {
TYPE_NONE,
};
-enum calibration_mode {
- SW_MODE,
- HW_MODE,
-};
-
enum soc_type {
SOC_ARCH_EXYNOS4210 = 1,
SOC_ARCH_EXYNOS4412,
@@ -92,10 +87,6 @@ enum soc_type {
* @buf_slope_sel_shift: shift bits of amplifier gain value in tmu_ctrl
register.
* @buf_slope_sel_mask: mask bits of amplifier gain value in tmu_ctrl
register.
- * @calib_mode_shift: shift bits of calibration mode value in tmu_ctrl
- register.
- * @calib_mode_mask: mask bits of calibration mode value in tmu_ctrl
- register.
* @core_en_shift: shift bits of TMU core enable bit in tmu_ctrl register.
* @tmu_status: register drescribing the TMU status.
* @tmu_cur_temp: register containing the current temperature of the TMU.
@@ -139,8 +130,6 @@ struct
Re: [PATCH 04/10] thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Only TYPE_ONE_POINT_TRIMMING calibration is used so remove
the dead code for TYPE_TWO_POINT_TRIMMING calibration.
I prefer to retain this feature as it is provided by the TMU
controller. This will avoid unnecessary churning of code when some new
soc wants to use it. 2 point trimming should ideally give best
compensated thermal values.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 55
++-
drivers/thermal/samsung/exynos_tmu.h | 20 +--
drivers/thermal/samsung/exynos_tmu_data.c | 17 +-
drivers/thermal/samsung/exynos_tmu_data.h | 2 --
4 files changed, 12 insertions(+), 82 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 9f2a5ee..903566f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -47,8 +47,7 @@
* @irq_work: pointer to the irq work structure.
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
- * @temp_error1: fused value of the first point trim.
- * @temp_error2: fused value of the second point trim.
+ * @temp_error: fused value of the first point trim.
* @regulator: pointer to the TMU regulator structure.
* @reg_conf: pointer to structure to register with core thermal.
*/
@@ -62,14 +61,13 @@ struct exynos_tmu_data {
struct work_struct irq_work;
struct mutex lock;
struct clk *clk;
- u8 temp_error1, temp_error2;
+ u8 temp_error;
struct regulator *regulator;
struct thermal_sensor_conf *reg_conf;
};
/*
* TMU treats temperature as a mapped temperature code.
- * The temperature is converted differently depending on the calibration
type.
*/
static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
{
@@ -83,20 +81,7 @@ static int temp_to_code(struct exynos_tmu_data *data, u8
temp)
goto out;
}
- switch (pdata-cal_type) {
- case TYPE_TWO_POINT_TRIMMING:
- temp_code = (temp - pdata-first_point_trim) *
- (data-temp_error2 - data-temp_error1) /
- (pdata-second_point_trim - pdata-first_point_trim) +
- data-temp_error1;
- break;
- case TYPE_ONE_POINT_TRIMMING:
- temp_code = temp + data-temp_error1 - pdata-first_point_trim;
- break;
- default:
- temp_code = temp + pdata-default_temp_offset;
- break;
- }
+ temp_code = temp + data-temp_error - pdata-first_point_trim;
out:
return temp_code;
}
@@ -117,20 +102,7 @@ static int code_to_temp(struct exynos_tmu_data *data,
u8 temp_code)
goto out;
}
- switch (pdata-cal_type) {
- case TYPE_TWO_POINT_TRIMMING:
- temp = (temp_code - data-temp_error1) *
- (pdata-second_point_trim - pdata-first_point_trim) /
- (data-temp_error2 - data-temp_error1) +
- pdata-first_point_trim;
- break;
- case TYPE_ONE_POINT_TRIMMING:
- temp = temp_code - data-temp_error1 + pdata-first_point_trim;
- break;
- default:
- temp = temp_code - pdata-default_temp_offset;
- break;
- }
+ temp = temp_code - data-temp_error + pdata-first_point_trim;
out:
return temp;
}
@@ -179,19 +151,12 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
} else {
trim_info = readl(data-base + reg-triminfo_data);
}
- data-temp_error1 = trim_info EXYNOS_TMU_TEMP_MASK;
- data-temp_error2 = ((trim_info reg-triminfo_85_shift)
- EXYNOS_TMU_TEMP_MASK);
-
- if (!data-temp_error1 ||
- (pdata-min_efuse_value data-temp_error1) ||
- (data-temp_error1 pdata-max_efuse_value))
- data-temp_error1 = pdata-efuse_value EXYNOS_TMU_TEMP_MASK;
-
- if (!data-temp_error2)
- data-temp_error2 =
- (pdata-efuse_value reg-triminfo_85_shift)
- EXYNOS_TMU_TEMP_MASK;
+ data-temp_error = trim_info EXYNOS_TMU_TEMP_MASK;
+
+ if (!data-temp_error ||
+ pdata-min_efuse_value data-temp_error ||
+ data-temp_error pdata-max_efuse_value)
+ data-temp_error = pdata-efuse_value EXYNOS_TMU_TEMP_MASK;
if (pdata-max_trigger_level MAX_THRESHOLD_LEVS) {
dev_err(pdev-dev, Invalid max trigger level\n);
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index e417af8..186e39e 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++
Re: [PATCH 05/10] thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize()
On 5/15/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
On Thursday, May 15, 2014 10:47:40 AM Eduardo Valentin wrote:
Hello Bartlomiej,
Hi,
On Mon, May 05, 2014 at 01:15:34PM +0200, Bartlomiej Zolnierkiewicz
wrote:
Remove runtime checks for pdata sanity from exynos_tmu_initialize().
The current values hardcoded in pdata will never trigger the checks
and for the new code potential mistakes should be caught during
development/review phases.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_thermal_common.h | 1 -
drivers/thermal/samsung/exynos_tmu.c| 13 -
2 files changed, 14 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..cd44719 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -27,7 +27,6 @@
#define SENSOR_NAME_LEN 16
#define MAX_TRIP_COUNT8
#define MAX_COOLING_DEVICE 4
-#define MAX_THRESHOLD_LEVS 5
#define ACTIVE_INTERVAL 500
#define IDLE_INTERVAL 1
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 903566f..789d745 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -158,23 +158,10 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
data-temp_error pdata-max_efuse_value)
data-temp_error = pdata-efuse_value EXYNOS_TMU_TEMP_MASK;
- if (pdata-max_trigger_level MAX_THRESHOLD_LEVS) {
- dev_err(pdev-dev, Invalid max trigger level\n);
- ret = -EINVAL;
- goto out;
- }
-
for (i = 0; i pdata-max_trigger_level; i++) {
if (!pdata-trigger_levels[i])
continue;
- if ((pdata-trigger_type[i] == HW_TRIP)
- (!pdata-trigger_levels[pdata-max_trigger_level - 1])) {
- dev_err(pdev-dev, Invalid hw trigger level\n);
- ret = -EINVAL;
- goto out;
- }
-
Does it mean no new pdata are going to be written? i.e., no new soc is
going to be supported by this driver that needs proper pdata checking?
This is not a proper checking. The checks in question are done at runtime
in a production code for data that is hardcoded inside driver during
development time and later it doesn't change. Such data should be verified
during development and review time (i.e. by a script parsing relevant data
from exynos_tmu_data.c, one can also argue that verification to be done is
so simple that the review by a maintainer should be enough).
Agreed to your arguments. These changes looks fine.
/* Count trigger levels except the HW trip*/
if (!(pdata-trigger_type[i] == HW_TRIP))
trigger_levs++;
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10] thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize()
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Remove runtime checks for negative return values of temp_to_code()
from exynos_tmu_initialize(). The current level temperature data
hardcoded in pdata will never cause a negative temp_to_code()
return values and for the new code potential mistakes should be
caught during development/review phases.
Your arguments looks fine.
Theres should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 789d745..a415829 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -170,10 +170,6 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
- if (threshold_code 0) {
- ret = threshold_code;
- goto out;
- }
writeb(threshold_code,
data-base + reg-threshold_temp);
for (i = 0; i trigger_levs; i++)
@@ -187,18 +183,12 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
i trigger_levs i EXYNOS_MAX_TRIGGER_PER_REG; i++) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
- if (threshold_code 0) {
- ret = threshold_code;
- goto out;
- }
rising_threshold |= threshold_code 8 * i;
if (pdata-threshold_falling) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i] -
pdata-threshold_falling);
- if (threshold_code 0)
- falling_threshold |=
- threshold_code 8 * i;
+ falling_threshold |= threshold_code 8 * i;
}
}
@@ -217,10 +207,6 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
(pdata-trigger_type[i] == HW_TRIP)) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
- if (threshold_code 0) {
- ret = threshold_code;
- goto out;
- }
if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
/* 1-4 level to be assigned in th0 reg */
rising_threshold |= threshold_code 8 * i;
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] thermal: exynos: simplify temp_to_code() and code_to_temp()
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
* Remove dead temp check from temp_to_code() (this function users
in exynos_tmu_initialize() always pass correct temperatures and
exynos_tmu_set_emulation() returns early for EXYNOS4210 because
TMU_SUPPORT_EMULATION flag is not set on this SoC).
* Move temp_code check from code_to_temp() to exynos_tmu_read()
(code_to_temp() only user).
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Changes looks fine.
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 38
+++-
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index a415829..20379eb 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -71,19 +71,7 @@ struct exynos_tmu_data {
*/
static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
{
- struct exynos_tmu_platform_data *pdata = data-pdata;
- int temp_code;
-
- if (data-soc == SOC_ARCH_EXYNOS4210)
- /* temp should range between 25 and 125 */
- if (temp 25 || temp 125) {
- temp_code = -EINVAL;
- goto out;
- }
-
- temp_code = temp + data-temp_error - pdata-first_point_trim;
-out:
- return temp_code;
+ return temp + data-temp_error - data-pdata-first_point_trim;
}
/*
@@ -92,19 +80,7 @@ out:
*/
static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
{
- struct exynos_tmu_platform_data *pdata = data-pdata;
- int temp;
-
- if (data-soc == SOC_ARCH_EXYNOS4210)
- /* temp_code should range between 75 and 175 */
- if (temp_code 75 || temp_code 175) {
- temp = -ENODATA;
- goto out;
- }
-
- temp = temp_code - data-temp_error + pdata-first_point_trim;
-out:
- return temp;
+ return temp_code - data-temp_error + data-pdata-first_point_trim;
}
static int exynos_tmu_initialize(struct platform_device *pdev)
@@ -297,8 +273,16 @@ static int exynos_tmu_read(struct exynos_tmu_data
*data)
clk_enable(data-clk);
temp_code = readb(data-base + reg-tmu_cur_temp);
- temp = code_to_temp(data, temp_code);
+ if (data-soc == SOC_ARCH_EXYNOS4210)
+ /* temp_code should range between 75 and 175 */
+ if (temp_code 75 || temp_code 175) {
+ temp = -ENODATA;
+ goto out;
+ }
+
+ temp = code_to_temp(data, temp_code);
+out:
clk_disable(data-clk);
mutex_unlock(data-lock);
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] thermal: exynos: cache non_hw_trigger_levels in pdata
On 5/5/14, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Cache number of non-hardware trigger levels in a new pdata field
(non_hw_trigger_levels) and convert code in exynos_tmu_initialize()
accordingly.
Changes looks fine,
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 16 +++-
drivers/thermal/samsung/exynos_tmu.h | 2 ++
drivers/thermal/samsung/exynos_tmu_data.c | 3 +++
3 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 20379eb..a8d9524 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -90,7 +90,7 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
const struct exynos_tmu_registers *reg = pdata-registers;
unsigned int status, trim_info = 0, con;
unsigned int rising_threshold = 0, falling_threshold = 0;
- int ret = 0, threshold_code, i, trigger_levs = 0;
+ int ret = 0, threshold_code, i;
mutex_lock(data-lock);
clk_enable(data-clk);
@@ -134,29 +134,19 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
data-temp_error pdata-max_efuse_value)
data-temp_error = pdata-efuse_value EXYNOS_TMU_TEMP_MASK;
- for (i = 0; i pdata-max_trigger_level; i++) {
- if (!pdata-trigger_levels[i])
- continue;
-
- /* Count trigger levels except the HW trip*/
- if (!(pdata-trigger_type[i] == HW_TRIP))
- trigger_levs++;
- }
-
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
writeb(threshold_code,
data-base + reg-threshold_temp);
- for (i = 0; i trigger_levs; i++)
+ for (i = 0; i pdata-non_hw_trigger_levels; i++)
writeb(pdata-trigger_levels[i], data-base +
reg-threshold_th0 + i * sizeof(reg-threshold_th0));
writel(reg-inten_rise_mask, data-base + reg-tmu_intclear);
} else {
/* Write temperature code for rising and falling threshold */
- for (i = 0;
- i trigger_levs i EXYNOS_MAX_TRIGGER_PER_REG; i++) {
+ for (i = 0; i pdata-non_hw_trigger_levels; i++) {
threshold_code = temp_to_code(data,
pdata-trigger_levels[i]);
rising_threshold |= threshold_code 8 * i;
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 186e39e..4845171 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -183,6 +183,7 @@ struct exynos_tmu_registers {
* 1 = enable trigger_level[] interrupt,
* 0 = disable trigger_level[] interrupt
* @max_trigger_level: max trigger level supported by the TMU
+ * @non_hw_trigger_levels: number of defined non-hardware trigger levels
* @gain: gain of amplifier in the positive-TC generator block
* 0 = gain = 15
* @reference_voltage: reference voltage of amplifier
@@ -213,6 +214,7 @@ struct exynos_tmu_platform_data {
enum trigger_type trigger_type[MAX_TRIP_COUNT];
bool trigger_enable[MAX_TRIP_COUNT];
u8 max_trigger_level;
+ u8 non_hw_trigger_levels;
u8 gain;
u8 reference_voltage;
u8 noise_cancel_mode;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index c32d186..ef7f186 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -62,6 +62,7 @@ struct exynos_tmu_init_data const
exynos4210_default_tmu_data = {
.trigger_type[1] = THROTTLE_ACTIVE,
.trigger_type[2] = SW_TRIP,
.max_trigger_level = 4,
+ .non_hw_trigger_levels = 3,
.gain = 15,
.reference_voltage = 7,
.min_efuse_value = 40,
@@ -135,6 +136,7 @@ static const struct exynos_tmu_registers
exynos4412_tmu_registers = {
.trigger_type[2] = SW_TRIP, \
.trigger_type[3] = HW_TRIP, \
.max_trigger_level = 4, \
+ .non_hw_trigger_levels = 3, \
.gain = 8, \
.reference_voltage = 16, \
.noise_cancel_mode = 4, \
@@ -225,6 +227,7 @@ static const struct exynos_tmu_registers
exynos5440_tmu_registers = {
.trigger_type[0] = SW_TRIP, \
.trigger_type[4] = HW_TRIP, \
.max_trigger_level = 5, \
+ .non_hw_trigger_levels = 1, \
.gain = 5, \
.reference_voltage = 16, \
Re: [PATCH] thermal: samsung: Only update available threshold limits
On 4/14/14, Tushar Behera wrote:
> Currently the threshold limits are updated in 2 stages, once for all
> software trigger levels and again for hardware trip point.
I guess the first stage is bootloader as could not find this in this file.
Anyways the changes looks fine to me.
Acked-by: Amit Daniel Kachhap
>
> While updating the software trigger levels, it overwrites the threshold
> limit for hardware trip point thereby forcing the Exynos core to issue
> an emergency shutdown.
>
> Updating only the required fields in threshold register fixes this issue.
>
> Signed-off-by: Tushar Behera
> ---
> Based on v3.15-rc1.
>
> drivers/thermal/samsung/exynos_tmu.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 0d96a51..ffccc89 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -225,6 +225,8 @@ skip_calib_data:
> trigger_levs++;
> }
>
> + rising_threshold = readl(data->base + reg->threshold_th0);
> +
> if (data->soc == SOC_ARCH_EXYNOS4210) {
> /* Write temperature code for threshold */
> threshold_code = temp_to_code(data, pdata->threshold);
> @@ -249,6 +251,7 @@ skip_calib_data:
> ret = threshold_code;
> goto out;
> }
> + rising_threshold &= ~(0xff << 8 * i);
> rising_threshold |= threshold_code << 8 * i;
> if (pdata->threshold_falling) {
> threshold_code = temp_to_code(data,
> @@ -281,6 +284,7 @@ skip_calib_data:
> }
> if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
> /* 1-4 level to be assigned in th0 reg */
> + rising_threshold &= ~(0xff << 8 * i);
> rising_threshold |= threshold_code << 8 * i;
> writel(rising_threshold,
> data->base + reg->threshold_th0);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: samsung: Only update available threshold limits
On 4/14/14, Tushar Behera tushar.beh...@linaro.org wrote:
Currently the threshold limits are updated in 2 stages, once for all
software trigger levels and again for hardware trip point.
I guess the first stage is bootloader as could not find this in this file.
Anyways the changes looks fine to me.
Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com
While updating the software trigger levels, it overwrites the threshold
limit for hardware trip point thereby forcing the Exynos core to issue
an emergency shutdown.
Updating only the required fields in threshold register fixes this issue.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Based on v3.15-rc1.
drivers/thermal/samsung/exynos_tmu.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 0d96a51..ffccc89 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -225,6 +225,8 @@ skip_calib_data:
trigger_levs++;
}
+ rising_threshold = readl(data-base + reg-threshold_th0);
+
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
@@ -249,6 +251,7 @@ skip_calib_data:
ret = threshold_code;
goto out;
}
+ rising_threshold = ~(0xff 8 * i);
rising_threshold |= threshold_code 8 * i;
if (pdata-threshold_falling) {
threshold_code = temp_to_code(data,
@@ -281,6 +284,7 @@ skip_calib_data:
}
if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
/* 1-4 level to be assigned in th0 reg */
+ rising_threshold = ~(0xff 8 * i);
rising_threshold |= threshold_code 8 * i;
writel(rising_threshold,
data-base + reg-threshold_th0);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: EXYNOS: always register TMU driver with core thermal framework
On 11/25/13, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> Could you please also apply this patch?
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
> On Friday, October 04, 2013 02:38:25 PM Bartlomiej Zolnierkiewicz wrote:
>> There is little sense in having separate config option for
>> registering EXYNOS TMU driver with the core thermal framework.
>> Fix it by integrating EXYNOS_THERMAL_CORE config option with
>> EXYNOS_THERMAL one.
>>
Sorry for the late reply but this patch is not needed as in my opinion
as it is just decreasing the flexibility when only sensor hardware
needs to be initialised and all cooling is hw controlled.
Thanks,
Amit D
>> Signed-off-by: Bartlomiej Zolnierkiewicz
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/thermal/samsung/Kconfig | 14 +++---
>> drivers/thermal/samsung/Makefile| 2 +-
>> drivers/thermal/samsung/exynos_thermal_common.h | 12
>> 3 files changed, 4 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/Kconfig
>> b/drivers/thermal/samsung/Kconfig
>> index f760389..04eabee 100644
>> --- a/drivers/thermal/samsung/Kconfig
>> +++ b/drivers/thermal/samsung/Kconfig
>> @@ -5,14 +5,6 @@ config EXYNOS_THERMAL
>>If you say yes here you get support for the TMU (Thermal Management
>>Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver
>> initialises
>>the TMU, reports temperature and handles cooling action if defined.
>> - This driver uses the Exynos core thermal APIs and TMU configuration
>> - data from the supported SoCs.
>> -
>> -config EXYNOS_THERMAL_CORE
>> -bool "Core thermal framework support for EXYNOS SOCs"
>> -depends on EXYNOS_THERMAL
>> -help
>> - If you say yes here you get support for EXYNOS TMU
>> - (Thermal Management Unit) common registration/unregistration
>> - functions to the core thermal layer and also to use the generic
>> - CPU cooling APIs.
>> + This driver uses the Exynos core thermal APIs, TMU configuration data
>> + from the supported SoCs, common registration/unregistration functions
>> + to the core thermal layer and also the generic CPU cooling APIs.
>> diff --git a/drivers/thermal/samsung/Makefile
>> b/drivers/thermal/samsung/Makefile
>> index c09d830..a829107 100644
>> --- a/drivers/thermal/samsung/Makefile
>> +++ b/drivers/thermal/samsung/Makefile
>> @@ -4,4 +4,4 @@
>> obj-$(CONFIG_EXYNOS_THERMAL)+= exynos_thermal.o
>> exynos_thermal-y:= exynos_tmu.o
>> exynos_thermal-y+= exynos_tmu_data.o
>> -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)+=
>> exynos_thermal_common.o
>> +exynos_thermal-y+= exynos_thermal_common.o
>> diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
>> b/drivers/thermal/samsung/exynos_thermal_common.h
>> index 3eb2ed9..8681679 100644
>> --- a/drivers/thermal/samsung/exynos_thermal_common.h
>> +++ b/drivers/thermal/samsung/exynos_thermal_common.h
>> @@ -88,20 +88,8 @@ struct thermal_sensor_conf {
>> struct device *dev;
>> };
>>
>> -/*Functions used exynos based thermal sensor driver*/
>> -#ifdef CONFIG_EXYNOS_THERMAL_CORE
>> void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
>> int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
>> void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
>> -#else
>> -static inline void
>> -exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) {
>> return; }
>>
>> -static inline int
>> -exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return
>> 0; }
>> -
>> -static inline void
>> -exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return;
>> }
>> -
>> -#endif /* CONFIG_EXYNOS_THERMAL_CORE */
>> #endif /* _EXYNOS_THERMAL_COMMON_H */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
On 10/4/13, Bartlomiej Zolnierkiewicz wrote: > Menu for Samsung thermal support is visible on all Samsung > platforms while thermal drivers are currently available only > for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency > with ARCH_EXYNOS one. > > Signed-off-by: Bartlomiej Zolnierkiewicz > Signed-off-by: Kyungmin Park Looks good, so Acked-by: Amit Daniel Kachhap > --- > drivers/thermal/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index a709c63..05cf95c 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -198,7 +198,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig" > endmenu > > menu "Samsung thermal drivers" > -depends on PLAT_SAMSUNG > +depends on ARCH_EXYNOS > source "drivers/thermal/samsung/Kconfig" > endmenu > > -- > 1.8.2.3 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
On 10/4/13, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Menu for Samsung thermal support is visible on all Samsung platforms while thermal drivers are currently available only for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency with ARCH_EXYNOS one. Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Looks good, so Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index a709c63..05cf95c 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -198,7 +198,7 @@ source drivers/thermal/ti-soc-thermal/Kconfig endmenu menu Samsung thermal drivers -depends on PLAT_SAMSUNG +depends on ARCH_EXYNOS source drivers/thermal/samsung/Kconfig endmenu -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: EXYNOS: always register TMU driver with core thermal framework
On 11/25/13, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Hi,
Could you please also apply this patch?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
On Friday, October 04, 2013 02:38:25 PM Bartlomiej Zolnierkiewicz wrote:
There is little sense in having separate config option for
registering EXYNOS TMU driver with the core thermal framework.
Fix it by integrating EXYNOS_THERMAL_CORE config option with
EXYNOS_THERMAL one.
Sorry for the late reply but this patch is not needed as in my opinion
as it is just decreasing the flexibility when only sensor hardware
needs to be initialised and all cooling is hw controlled.
Thanks,
Amit D
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/thermal/samsung/Kconfig | 14 +++---
drivers/thermal/samsung/Makefile| 2 +-
drivers/thermal/samsung/exynos_thermal_common.h | 12
3 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/thermal/samsung/Kconfig
b/drivers/thermal/samsung/Kconfig
index f760389..04eabee 100644
--- a/drivers/thermal/samsung/Kconfig
+++ b/drivers/thermal/samsung/Kconfig
@@ -5,14 +5,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for the TMU (Thermal Management
Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver
initialises
the TMU, reports temperature and handles cooling action if defined.
- This driver uses the Exynos core thermal APIs and TMU configuration
- data from the supported SoCs.
-
-config EXYNOS_THERMAL_CORE
-bool Core thermal framework support for EXYNOS SOCs
-depends on EXYNOS_THERMAL
-help
- If you say yes here you get support for EXYNOS TMU
- (Thermal Management Unit) common registration/unregistration
- functions to the core thermal layer and also to use the generic
- CPU cooling APIs.
+ This driver uses the Exynos core thermal APIs, TMU configuration data
+ from the supported SoCs, common registration/unregistration functions
+ to the core thermal layer and also the generic CPU cooling APIs.
diff --git a/drivers/thermal/samsung/Makefile
b/drivers/thermal/samsung/Makefile
index c09d830..a829107 100644
--- a/drivers/thermal/samsung/Makefile
+++ b/drivers/thermal/samsung/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_EXYNOS_THERMAL)+= exynos_thermal.o
exynos_thermal-y:= exynos_tmu.o
exynos_thermal-y+= exynos_tmu_data.o
-exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)+=
exynos_thermal_common.o
+exynos_thermal-y+= exynos_thermal_common.o
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..8681679 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -88,20 +88,8 @@ struct thermal_sensor_conf {
struct device *dev;
};
-/*Functions used exynos based thermal sensor driver*/
-#ifdef CONFIG_EXYNOS_THERMAL_CORE
void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
-#else
-static inline void
-exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) {
return; }
-static inline int
-exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return
0; }
-
-static inline void
-exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return;
}
-
-#endif /* CONFIG_EXYNOS_THERMAL_CORE */
#endif /* _EXYNOS_THERMAL_COMMON_H */
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/30] thermal: cpu_cooling: fix kernel_doc for cpufreq_cooling_device
On Wed, Apr 17, 2013 at 10:41 PM, Eduardo Valentin wrote: > Simple fixes for making kernel_doc happy about > struct cpufreq_cooling_device. Includes also a minor > spelling fix. > > Cc: Zhang Rui > Cc: linux...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Eduardo Valentin Reviewed-by: Amit Daniel Kachhap Thanks, Amit Daniel > --- > drivers/thermal/cpu_cooling.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > index d0d6a0c..7c0c05b 100644 > --- a/drivers/thermal/cpu_cooling.c > +++ b/drivers/thermal/cpu_cooling.c > @@ -28,11 +28,11 @@ > #include > > /** > - * struct cpufreq_cooling_device > + * struct cpufreq_cooling_device - data for cooling device with cpufreq > * @id: unique integer value corresponding to each cpufreq_cooling_device > * registered. > - * @cool_dev: thermal_cooling_device pointer to keep track of the the > - * egistered cooling device. > + * @cool_dev: thermal_cooling_device pointer to keep track of the > + * registered cooling device. > * @cpufreq_state: integer value representing the current state of cpufreq > * cooling devices. > * @cpufreq_val: integer value representing the absolute value of the clipped > -- > 1.8.2.1.342.gfa7285d > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/30] thermal: cpu_cooling: fix kernel_doc for cpufreq_cooling_device
On Wed, Apr 17, 2013 at 10:41 PM, Eduardo Valentin eduardo.valen...@ti.com wrote: Simple fixes for making kernel_doc happy about struct cpufreq_cooling_device. Includes also a minor spelling fix. Cc: Zhang Rui rui.zh...@intel.com Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com Thanks, Amit Daniel --- drivers/thermal/cpu_cooling.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index d0d6a0c..7c0c05b 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -28,11 +28,11 @@ #include linux/cpu_cooling.h /** - * struct cpufreq_cooling_device + * struct cpufreq_cooling_device - data for cooling device with cpufreq * @id: unique integer value corresponding to each cpufreq_cooling_device * registered. - * @cool_dev: thermal_cooling_device pointer to keep track of the the - * egistered cooling device. + * @cool_dev: thermal_cooling_device pointer to keep track of the + * registered cooling device. * @cpufreq_state: integer value representing the current state of cpufreq * cooling devices. * @cpufreq_val: integer value representing the absolute value of the clipped -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/9] thermal: exynos: Add support for instance based register/unregister
Hi Eduardo,
On Fri, Apr 12, 2013 at 1:39 AM, Eduardo Valentin
wrote:
> Hey Amit,
>
>
> On 26-03-2013 07:33, Amit Daniel Kachhap wrote:
>>
>> This code modifies the thermal driver to have multiple thermal zone
>> support by replacing the global thermal zone varibale with device data
>
>
> s/varibale/variable
ok type mistake :)
>
>
>> member of thermal_zone_device.
>>
>> Signed-off-by: Amit Daniel Kachhap
>
>
> I understand the idea of your patch but I also see that you do at least to
> major changes. One is to set the thermal_device.devdata. The second is to
> split your internal reference private_data into driver_data and pzone_data.
> Is it possible to split this patch into two, one per modification? So it is
> easier to review your changes?
yes agreed..the kind of patch restructuring suggested by you makes sense.
>
>
>>
>> ---
>> drivers/thermal/exynos_thermal.c | 65
>> ++---
>> 1 files changed, 39 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> index 1cd7837..dc9b91b 100644
>> --- a/drivers/thermal/exynos_thermal.c
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -148,7 +148,8 @@ struct thermal_sensor_conf {
>> int (*write_emul_temp)(void *drv_data, unsigned long temp);
>> struct thermal_trip_point_conf trip_data;
>> struct thermal_cooling_conf cooling_data;
>> - void *private_data;
>> + void *driver_data;
>> + void *pzone_data;
>> };
>>
>> struct exynos_thermal_zone {
>> @@ -161,14 +162,14 @@ struct exynos_thermal_zone {
>> bool bind;
>> };
>>
>> -static struct exynos_thermal_zone *th_zone;
>> -static void exynos_unregister_thermal(void);
>> +static void exynos_unregister_thermal(struct thermal_sensor_conf
>> *sensor_conf);
>> static int exynos_register_thermal(struct thermal_sensor_conf
>> *sensor_conf);
>>
>> /* Get mode callback functions for thermal zone */
>> static int exynos_get_mode(struct thermal_zone_device *thermal,
>> enum thermal_device_mode *mode)
>> {
>> + struct exynos_thermal_zone *th_zone = thermal->devdata;
>> if (th_zone)
>> *mode = th_zone->mode;
>> return 0;
>> @@ -178,25 +179,26 @@ static int exynos_get_mode(struct
>> thermal_zone_device *thermal,
>> static int exynos_set_mode(struct thermal_zone_device *thermal,
>> enum thermal_device_mode mode)
>> {
>> - if (!th_zone->therm_dev) {
>> + struct exynos_thermal_zone *th_zone = thermal->devdata;
>> + if (!th_zone) {
>> pr_notice("thermal zone not registered\n");
>> return 0;
>> }
>>
>> - mutex_lock(_zone->therm_dev->lock);
>> + mutex_lock(>lock);
>>
>> if (mode == THERMAL_DEVICE_ENABLED &&
>> !th_zone->sensor_conf->trip_data.trigger_falling)
>> - th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
>> + thermal->polling_delay = IDLE_INTERVAL;
>> else
>> - th_zone->therm_dev->polling_delay = 0;
>> + thermal->polling_delay = 0;
>>
>> - mutex_unlock(_zone->therm_dev->lock);
>> + mutex_unlock(>lock);
>>
>> th_zone->mode = mode;
>> - thermal_zone_device_update(th_zone->therm_dev);
>> + thermal_zone_device_update(thermal);
>> pr_info("thermal polling set for duration=%d msec\n",
>> - th_zone->therm_dev->polling_delay);
>> + thermal->polling_delay);
>> return 0;
>> }
>>
>> @@ -223,6 +225,8 @@ static int exynos_get_trip_type(struct
>> thermal_zone_device *thermal, int trip,
>> static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int
>> trip,
>> unsigned long *temp)
>> {
>> + struct exynos_thermal_zone *th_zone = thermal->devdata;
>> +
>> if (trip < GET_TRIP(MONITOR_ZONE) || trip > GET_TRIP(PANIC_ZONE))
>> return -EINVAL;
>>
>> @@ -269,6 +273,7 @@ static int exynos_bind(struct thermal_zone_device
>> *thermal,
>> {
>> int ret = 0, i, tab_size, level;
>> struct freq_clip_table *tab_ptr, *clip_data;
>> + struct exynos_thermal_zone *th_zone = thermal->devdata;
>> struct thermal_sensor_conf *data = th_zone->sensor_conf;
>>
>> tab_ptr = (struct freq_clip_table *)data->cooling_data.freq_data;
>> @@ -315,6 +320,7 @@ static int exynos_unbind(struct thermal_zone_device
>> *thermal,
>> struct thermal_cooling_device *cdev)
>> {
>> int ret = 0, i, tab_size;
>> + struct exynos_thermal_zone *th_zone = thermal->devdata;
>> struct thermal_sensor_conf *data = th_zone->sensor_conf;
>>
>> if (th_zone->bind == false)
>> @@ -357,13 +363,14 @@ static int exynos_unbind(struct thermal_zone_device
>> *thermal,
>> static int exynos_get_temp(struct thermal_zone_device
Re: [1/9] thermal: exynos: Adapt to temperature emulation core thermal framework
Hi Eduardo,
Thanks for your review comments.
On Fri, Apr 12, 2013 at 1:03 AM, Eduardo Valentin
wrote:
> Hello Amit,
>
> Couple of comments inline.
>
>
> On 26-03-2013 07:33, Amit Daniel Kachhap wrote:
>>
>> This removes the driver specific sysfs support of the temperature
>> emulation and uses the newly added core thermal framework for thermal
>> emulation. An exynos platform specific handler is added to support this.
>>
>> In this patch, the exynos senor(tmu) related code and exynos framework
>> related (thermal zone, cooling devices) code are intentionally kept
>> separate.
>> So an emulated function pointer is passed from sensor to framework. This
>> is
>> beneficial in adding more sensor support using the same framework code
>> which is an ongoing work. The goal is to finally split them totally. Even
>> the existing read_temperature also follows the same execution method.
>>
>> Acked-by: Kukjin Kim
>> Signed-off-by: Amit Daniel Kachhap
>>
>> ---
>> Documentation/thermal/exynos_thermal_emulation |8 +-
>> drivers/thermal/Kconfig|9 --
>> drivers/thermal/exynos_thermal.c | 158
>> ++--
>> 3 files changed, 67 insertions(+), 108 deletions(-)
>>
>> diff --git a/Documentation/thermal/exynos_thermal_emulation
>> b/Documentation/thermal/exynos_thermal_emulation
>> index b73bbfb..36a3e79 100644
>> --- a/Documentation/thermal/exynos_thermal_emulation
>> +++ b/Documentation/thermal/exynos_thermal_emulation
>> @@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for
>> TMU's operation. User can set
>> manually with software code and TMU will read current temperature from
>> user value not from
>> sensor's value.
>>
>> -Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
>> available.
>> -When it's enabled, sysfs node will be created under
>> -/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
>> +Enabling CONFIG_THERMAL_EMULATION option will make this support
>> available.
>> +When it's enabled, sysfs node will be created as
>> +/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
>>
>> -The sysfs node, 'emulation', will contain value 0 for the initial state.
>> When you input any
>> +The sysfs node, 'emul_node', will contain value 0 for the initial state.
>> When you input any
>> temperature you want to update to sysfs node, it automatically enable
>> emulation mode and
>> current temperature will be changed into it.
>> (Exynos also supports user changable delay time which would be used to
>> delay of
>
>
> not part of this patch but:
> s/changable/changeable
Ok
>
>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index a764f16..da4c19e 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -117,15 +117,6 @@ config EXYNOS_THERMAL
>> If you say yes here you get support for TMU (Thermal Management
>> Unit) on SAMSUNG EXYNOS series of SoC.
>>
>> -config EXYNOS_THERMAL_EMUL
>> - bool "EXYNOS TMU emulation mode support"
>> - depends on EXYNOS_THERMAL
>> - help
>> - Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
>> - Enable this option will be make sysfs node in exynos thermal
>> platform
>> - device directory to support emulation mode. With emulation mode
>> sysfs
>> - node, you can manually input temperature to TMU for simulation
>> purpose.
>> -
>> config DOVE_THERMAL
>> tristate "Temperature sensor on Marvell Dove SoCs"
>> depends on ARCH_DOVE
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> index 46568c0..1cd7837 100644
>> --- a/drivers/thermal/exynos_thermal.c
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -100,13 +100,13 @@
>> #define IDLE_INTERVAL 1
>> #define MCELSIUS 1000
>>
>> -#ifdef CONFIG_EXYNOS_THERMAL_EMUL
>> +#ifdef CONFIG_THERMAL_EMULATION
>> #define EXYNOS_EMUL_TIME 0x57F0
>> #define EXYNOS_EMUL_TIME_SHIFT16
>> #define EXYNOS_EMUL_DATA_SHIFT8
>> #define EXYNOS_EMUL_DATA_MASK 0xFF
>> #define EXYNOS_EMUL_ENABLE0x1
>> -#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
>> +#endif /* CONFIG_THERMAL_EMULATION */
>>
>
> As the above is only used in one single function, I suggest moving it to
> same ifdef where the function belongs below. It reduces your ifdefery and
> also makes your code cleaner.
Right makes sense.
>
>
>
>> /* CPU Zone information */
>> #define PANIC_ZONE 4
>> @@ -145,6 +145,7 @@ struct thermal_cooling_conf {
>> struct thermal_sensor_conf {
>> char name[SENSOR_NAME_LEN];
>> int (*read_temperature)(void *data);
>> + int (*write_emul_temp)(void *drv_data, unsigned long temp);
>
>
> I dont get why you need a private callback to do this, assuming you have
> only one sensor_conf for exynos.
Actually It is done in this way to keep sensor related stuffs and
common thermal zone related
Re: [1/9] thermal: exynos: Adapt to temperature emulation core thermal framework
Hi Eduardo,
Thanks for your review comments.
On Fri, Apr 12, 2013 at 1:03 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
Hello Amit,
Couple of comments inline.
On 26-03-2013 07:33, Amit Daniel Kachhap wrote:
This removes the driver specific sysfs support of the temperature
emulation and uses the newly added core thermal framework for thermal
emulation. An exynos platform specific handler is added to support this.
In this patch, the exynos senor(tmu) related code and exynos framework
related (thermal zone, cooling devices) code are intentionally kept
separate.
So an emulated function pointer is passed from sensor to framework. This
is
beneficial in adding more sensor support using the same framework code
which is an ongoing work. The goal is to finally split them totally. Even
the existing read_temperature also follows the same execution method.
Acked-by: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Documentation/thermal/exynos_thermal_emulation |8 +-
drivers/thermal/Kconfig|9 --
drivers/thermal/exynos_thermal.c | 158
++--
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/Documentation/thermal/exynos_thermal_emulation
b/Documentation/thermal/exynos_thermal_emulation
index b73bbfb..36a3e79 100644
--- a/Documentation/thermal/exynos_thermal_emulation
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for
TMU's operation. User can set
manually with software code and TMU will read current temperature from
user value not from
sensor's value.
-Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
available.
-When it's enabled, sysfs node will be created under
-/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
+Enabling CONFIG_THERMAL_EMULATION option will make this support
available.
+When it's enabled, sysfs node will be created as
+/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
-The sysfs node, 'emulation', will contain value 0 for the initial state.
When you input any
+The sysfs node, 'emul_node', will contain value 0 for the initial state.
When you input any
temperature you want to update to sysfs node, it automatically enable
emulation mode and
current temperature will be changed into it.
(Exynos also supports user changable delay time which would be used to
delay of
not part of this patch but:
s/changable/changeable
Ok
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index a764f16..da4c19e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -117,15 +117,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for TMU (Thermal Management
Unit) on SAMSUNG EXYNOS series of SoC.
-config EXYNOS_THERMAL_EMUL
- bool EXYNOS TMU emulation mode support
- depends on EXYNOS_THERMAL
- help
- Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
- Enable this option will be make sysfs node in exynos thermal
platform
- device directory to support emulation mode. With emulation mode
sysfs
- node, you can manually input temperature to TMU for simulation
purpose.
-
config DOVE_THERMAL
tristate Temperature sensor on Marvell Dove SoCs
depends on ARCH_DOVE
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 46568c0..1cd7837 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -100,13 +100,13 @@
#define IDLE_INTERVAL 1
#define MCELSIUS 1000
-#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+#ifdef CONFIG_THERMAL_EMULATION
#define EXYNOS_EMUL_TIME 0x57F0
#define EXYNOS_EMUL_TIME_SHIFT16
#define EXYNOS_EMUL_DATA_SHIFT8
#define EXYNOS_EMUL_DATA_MASK 0xFF
#define EXYNOS_EMUL_ENABLE0x1
-#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
+#endif /* CONFIG_THERMAL_EMULATION */
As the above is only used in one single function, I suggest moving it to
same ifdef where the function belongs below. It reduces your ifdefery and
also makes your code cleaner.
Right makes sense.
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -145,6 +145,7 @@ struct thermal_cooling_conf {
struct thermal_sensor_conf {
char name[SENSOR_NAME_LEN];
int (*read_temperature)(void *data);
+ int (*write_emul_temp)(void *drv_data, unsigned long temp);
I dont get why you need a private callback to do this, assuming you have
only one sensor_conf for exynos.
Actually It is done in this way to keep sensor related stuffs and
common thermal zone related parts. With this it is easy to split this
file in later patches.
struct thermal_trip_point_conf trip_data;
struct thermal_cooling_conf cooling_data;
Re: [2/9] thermal: exynos: Add support for instance based register/unregister
Hi Eduardo,
On Fri, Apr 12, 2013 at 1:39 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
Hey Amit,
On 26-03-2013 07:33, Amit Daniel Kachhap wrote:
This code modifies the thermal driver to have multiple thermal zone
support by replacing the global thermal zone varibale with device data
s/varibale/variable
ok type mistake :)
member of thermal_zone_device.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
I understand the idea of your patch but I also see that you do at least to
major changes. One is to set the thermal_device.devdata. The second is to
split your internal reference private_data into driver_data and pzone_data.
Is it possible to split this patch into two, one per modification? So it is
easier to review your changes?
yes agreed..the kind of patch restructuring suggested by you makes sense.
---
drivers/thermal/exynos_thermal.c | 65
++---
1 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 1cd7837..dc9b91b 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -148,7 +148,8 @@ struct thermal_sensor_conf {
int (*write_emul_temp)(void *drv_data, unsigned long temp);
struct thermal_trip_point_conf trip_data;
struct thermal_cooling_conf cooling_data;
- void *private_data;
+ void *driver_data;
+ void *pzone_data;
};
struct exynos_thermal_zone {
@@ -161,14 +162,14 @@ struct exynos_thermal_zone {
bool bind;
};
-static struct exynos_thermal_zone *th_zone;
-static void exynos_unregister_thermal(void);
+static void exynos_unregister_thermal(struct thermal_sensor_conf
*sensor_conf);
static int exynos_register_thermal(struct thermal_sensor_conf
*sensor_conf);
/* Get mode callback functions for thermal zone */
static int exynos_get_mode(struct thermal_zone_device *thermal,
enum thermal_device_mode *mode)
{
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
if (th_zone)
*mode = th_zone-mode;
return 0;
@@ -178,25 +179,26 @@ static int exynos_get_mode(struct
thermal_zone_device *thermal,
static int exynos_set_mode(struct thermal_zone_device *thermal,
enum thermal_device_mode mode)
{
- if (!th_zone-therm_dev) {
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
+ if (!th_zone) {
pr_notice(thermal zone not registered\n);
return 0;
}
- mutex_lock(th_zone-therm_dev-lock);
+ mutex_lock(thermal-lock);
if (mode == THERMAL_DEVICE_ENABLED
!th_zone-sensor_conf-trip_data.trigger_falling)
- th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
+ thermal-polling_delay = IDLE_INTERVAL;
else
- th_zone-therm_dev-polling_delay = 0;
+ thermal-polling_delay = 0;
- mutex_unlock(th_zone-therm_dev-lock);
+ mutex_unlock(thermal-lock);
th_zone-mode = mode;
- thermal_zone_device_update(th_zone-therm_dev);
+ thermal_zone_device_update(thermal);
pr_info(thermal polling set for duration=%d msec\n,
- th_zone-therm_dev-polling_delay);
+ thermal-polling_delay);
return 0;
}
@@ -223,6 +225,8 @@ static int exynos_get_trip_type(struct
thermal_zone_device *thermal, int trip,
static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int
trip,
unsigned long *temp)
{
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
+
if (trip GET_TRIP(MONITOR_ZONE) || trip GET_TRIP(PANIC_ZONE))
return -EINVAL;
@@ -269,6 +273,7 @@ static int exynos_bind(struct thermal_zone_device
*thermal,
{
int ret = 0, i, tab_size, level;
struct freq_clip_table *tab_ptr, *clip_data;
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
struct thermal_sensor_conf *data = th_zone-sensor_conf;
tab_ptr = (struct freq_clip_table *)data-cooling_data.freq_data;
@@ -315,6 +320,7 @@ static int exynos_unbind(struct thermal_zone_device
*thermal,
struct thermal_cooling_device *cdev)
{
int ret = 0, i, tab_size;
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
struct thermal_sensor_conf *data = th_zone-sensor_conf;
if (th_zone-bind == false)
@@ -357,13 +363,14 @@ static int exynos_unbind(struct thermal_zone_device
*thermal,
static int exynos_get_temp(struct thermal_zone_device *thermal,
unsigned long *temp)
{
+ struct exynos_thermal_zone *th_zone = thermal-devdata;
void *data;
if (!th_zone-sensor_conf) {
Re: [PATCH V4 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
On Tue, Mar 12, 2013 at 4:19 PM, Viresh Kumar wrote:
> This is what Russell told me a long time back:
> "Don't use Adding, Fixing, etc words as this work is not something, which is
> already done."
>
> So your subject should have been: "cpufreq: exynos: Add cpufreq driver
> for exynos5440"
ok right.
>
> Fix it if you need another version, which i believe you do :)
yes no escape now :)
>
> On Tue, Mar 12, 2013 at 5:58 PM, Amit Daniel Kachhap
> wrote:
>> This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
>> they scale at same frequency. The nature of exynos5440 clock controller is
>> different from previous exynos controllers so not using the common exynos
>> cpufreq framework. The major difference being interrupt notfication for
>
> s/notfication/notification
ok
>
>> frequency change. Also, OPP library is used for device tree parsing to get
>> different parameters like frequency, voltage etc. Since the opp library sorts
>> the frequency table in ascending order so they are again re-arranged in
>> descending order. This will have one-to-one mapping with the clock controller
>> state management logic.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> .../bindings/cpufreq/cpufreq-exynos5440.txt| 29 ++
>> drivers/cpufreq/Kconfig.arm|9 +
>> drivers/cpufreq/Makefile |1 +
>> drivers/cpufreq/exynos5440-cpufreq.c | 466
>>
>> 4 files changed, 505 insertions(+), 0 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>> create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>> new file mode 100644
>> index 000..a0dbe0b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>> @@ -0,0 +1,29 @@
>> +
>> +Exynos5440 cpufreq driver
>> +---
>> +
>> +Exynos5440 SoC cpufreq driver for CPU frequency scaling.
>> +
>> +Required properties:
>> +- interrupts: Interrupt to know the completion of cpu frequency change.
>> +- operating-points: Table of frequencies and voltage CPU could be
>> transitioned into,
>> + in the decreasing order. Frequency should be in KHZ units and voltage
>
> s/KHZ/KHz
ok
>
>> + should be in microvolts.
>
> probably s/microvolts/micro-volts ??
>
>> +
>> +Optional properties:
>> +- clock-latency: Clock monitor latency in microsecond.
>> +
>> +All the required listed above must be defined under node cpufreq.
>> +
>> +Example:
>> +
>> + cpufreq@16 {
>> + compatible = "samsung,exynos5440-cpufreq";
>> + reg = <0x16 0x1000>;
>> + interrupts = <0 57 0>;
>> + operating-points = <
>> + 100 975000
>> + 80 925000>;
>> + clock-latency = <10>;
>> + };
>> +
>
>> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
>> b/drivers/cpufreq/exynos5440-cpufreq.c
>> +static void exynos_enable_dvfs(void)
>> +{
>
>> + /* Set initial performance index */
>> + for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
>> + if (freq_table[i].frequency == dvfs_info->cur_frequency)
>> + break;
>> +
>> + if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
>> + dev_crit(dvfs_info->dev, "Boot up frequency not
>> supported\n");
>> + /* Assign the highest frequency */
>> + i = 0;
>> + dvfs_info->cur_frequency = freq_table[i].frequency;
>
> What about:
>
> dvfs_info->cur_frequency = freq_table[0].frequency;
>
> as i don't see i being used again?
No It is used below for frequency setting.
>
>> + }
>
>> +}
>
>> +static int exynos_target(struct cpufreq_policy *policy,
>> + unsigned int target_freq,
>> + unsigned int relation)
>> +{
>
>> + if (cpufreq_frequency_table_target(policy, freq_table,
>> + target_freq, relation, )) {
>> + ret = -EINVAL;
>
> Use the error value returned by called functions, probably i gave this
> comment last time too?
yes my mistake.
>
>> + goto out;
>> + }
>
>> +}
>
>> +static void exynos_sort_descend_freq_table(void)
>> +{
>> + struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
>> + int i = 0, index;
>> + unsigned int tmp_freq;
>> +
>> + /*
>> +* Freq table is already in ascending order as it is created from
>> +* OPP library, so just swap the elements to make it descending.
>
> why??
I explained this requirement in the patch commit. Will explain it here again.
>
>> +*/
>> + for (i = 0; i < dvfs_info->freq_count /
Re: [PATCH V4 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
On Tue, Mar 12, 2013 at 4:19 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
This is what Russell told me a long time back:
Don't use Adding, Fixing, etc words as this work is not something, which is
already done.
So your subject should have been: cpufreq: exynos: Add cpufreq driver
for exynos5440
ok right.
Fix it if you need another version, which i believe you do :)
yes no escape now :)
On Tue, Mar 12, 2013 at 5:58 PM, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they scale at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notfication for
s/notfication/notification
ok
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/cpufreq/cpufreq-exynos5440.txt| 29 ++
drivers/cpufreq/Kconfig.arm|9 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 466
4 files changed, 505 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git
a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..a0dbe0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,29 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be
transitioned into,
+ in the decreasing order. Frequency should be in KHZ units and voltage
s/KHZ/KHz
ok
+ should be in microvolts.
probably s/microvolts/micro-volts ??
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ operating-points =
+ 100 975000
+ 80 925000;
+ clock-latency = 10;
+ };
+
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
+static void exynos_enable_dvfs(void)
+{
+ /* Set initial performance index */
+ for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
+ if (freq_table[i].frequency == dvfs_info-cur_frequency)
+ break;
+
+ if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
+ dev_crit(dvfs_info-dev, Boot up frequency not
supported\n);
+ /* Assign the highest frequency */
+ i = 0;
+ dvfs_info-cur_frequency = freq_table[i].frequency;
What about:
dvfs_info-cur_frequency = freq_table[0].frequency;
as i don't see i being used again?
No It is used below for frequency setting.
+ }
+}
+static int exynos_target(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ if (cpufreq_frequency_table_target(policy, freq_table,
+ target_freq, relation, index)) {
+ ret = -EINVAL;
Use the error value returned by called functions, probably i gave this
comment last time too?
yes my mistake.
+ goto out;
+ }
+}
+static void exynos_sort_descend_freq_table(void)
+{
+ struct cpufreq_frequency_table *freq_tbl = dvfs_info-freq_table;
+ int i = 0, index;
+ unsigned int tmp_freq;
+
+ /*
+* Freq table is already in ascending order as it is created from
+* OPP library, so just swap the elements to make it descending.
why??
I explained this requirement in the patch commit. Will explain it here again.
+*/
+ for (i = 0; i dvfs_info-freq_count / 2; i++) {
+ index = dvfs_info-freq_count - i - 1;
+ tmp_freq = freq_tbl[i].frequency;
+ freq_tbl[i].frequency = freq_tbl[index].frequency;
+
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
On Sat, Mar 9, 2013 at 4:17 PM, Viresh Kumar wrote:
> On 7 March 2013 12:13, Amit Daniel Kachhap wrote:
>> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
>> b/drivers/cpufreq/exynos5440-cpufreq.c
>> +struct exynos_dvfs_data {
>> + void __iomem *base;
>> + struct resource *mem;
>> + int irq;
>> + struct clk *cpu_clk;
>> + unsigned int cur_frequency;
>> + unsigned int latency;
>> + struct cpufreq_frequency_table *freq_table;
>> + unsigned int freq_count;
>> + struct device *dev;
>> + bool dvfs_enable;
>
> s/enable/enabled?
Ok
>
>> +static int exynos_cpufreq_probe(struct platform_device *pdev)
>
>> + dvfs_info->cpu_clk = devm_clk_get(dvfs_info->dev, "armclk");
>> + if (IS_ERR_OR_NULL(dvfs_info->cpu_clk)) {
>
> s/IS_ERR_OR_NULL/IS_ERR
Ok.
>
>> + if (devm_request_irq(dvfs_info->dev, dvfs_info->irq,
>> exynos_cpufreq_irq,
>> + IRQF_TRIGGER_NONE, CPUFREQ_NAME, dvfs_info))
>> {
>> + pr_err("Failed to register IRQ\n");
>> + ret = -ENODEV;
>
> use the value returned from this function rather than creating your
> own.. true for all
> other calls too, unless they return NULL on error.
>
Will integrate your suggestions in the next version.
Thanks,
Amit D
>> +}
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Russell,
On Thu, Mar 7, 2013 at 9:07 PM, Russell King - ARM Linux
wrote:
> On Thu, Mar 07, 2013 at 04:28:00PM +0100, Sylwester Nawrocki wrote:
>> On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
>> > + dvfs_info->cpu_clk = devm_clk_get(dvfs_info->dev, "armclk");
>> > + if (IS_ERR_OR_NULL(dvfs_info->cpu_clk)) {
>>
>> devm_clk_get() return value needs to be checked with IS_ERR(),
>> not IS_ERR_OR_NULL().
>>
>> > + pr_err("Failed to get cpu clock\n");
>> > + ret = PTR_ERR(dvfs_info->cpu_clk);
>> > + goto err_free_table;
>
> Amit, to illustrate why this is wrong, consider this:
> 1. Set cpu_clk to NULL.
> 2. Realise IS_ERR_OR_NULL(NULL) is true.
> 3. What is the value of PTR_ERR(NULL) ?
> 4. What effect does that have when you jump to err_free_table ?
> 5. What value is returned from this function in that case ?
> 6. What does that return value mean to the driver core ?
Thanks for the detailed explaination. Usage of IS_ERR_OR_NULL is not
suitable here.
Thanks,
Amit D
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Sylwester,
Thanks for the review. Will update with your suggestion in the next version,
Thanks,
Amit D
On Thu, Mar 7, 2013 at 8:58 PM, Sylwester Nawrocki
wrote:
> On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
>> +/* Register definations */
>
> s/definations/definitions
ok
>
>> +#define XMU_DVFS_CTRL0x0060
>> +#define XMU_PMU_P0_7 0x0064
>> +#define XMU_C0_3_PSTATE 0x0090
>> +#define XMU_P_LIMIT 0x00A0
>> +#define XMU_P_STATUS 0x00A4
>> +#define XMU_PMUEVTEN 0x00D0
>> +#define XMU_PMUIRQEN 0x00D4
>> +#define XMU_PMUIRQ 0x00D8
>
> Keeping all hex numbers lower case might be a good idea.
Ok
>
>> +
>> +/* PMU mask and shift definations */
>> +#define P_VALUE_MASK 0x7
>> +
>> +#define XMU_DVFS_CTRL_EN_SHIFT 0
>> +
>> +#define P0_7_CPUCLKDEV_SHIFT 21
>> +#define P0_7_CPUCLKDEV_MASK 0x7
>> +#define P0_7_ATBCLKDEV_SHIFT 18
>> +#define P0_7_ATBCLKDEV_MASK 0x7
>> +#define P0_7_CSCLKDEV_SHIFT 15
>> +#define P0_7_CSCLKDEV_MASK 0x7
>> +#define P0_7_CPUEMA_SHIFT28
>> +#define P0_7_CPUEMA_MASK 0xf
>> +#define P0_7_L2EMA_SHIFT 24
>> +#define P0_7_L2EMA_MASK 0xf
> ...
>> +static int exynos_cpufreq_probe(struct platform_device *pdev)
>> +{
>> + int ret = -EINVAL;
>> + struct device_node *np;
>> + struct resource res;
>> +
>> + np = of_find_compatible_node(NULL, NULL,
>> "samsung,exynos5440-cpufreq");
>> + if (!np)
>> + return -ENODEV;
>> +
>> + dvfs_info = devm_kzalloc(>dev, sizeof(*dvfs_info), GFP_KERNEL);
>> + if (!dvfs_info) {
>> + ret = -ENOMEM;
>> + goto err_put_node;
>> + }
>> +
>> + dvfs_info->dev = >dev;
>> + dvfs_info->dev->of_node = np;
>> +
>> + ret = of_address_to_resource(np, 0, );
>> + if (ret)
>> + goto err_put_node;
>> +
>> + dvfs_info->base = devm_ioremap(dvfs_info->dev, res.start,
>
> There is a devm_ioremap_resource() function that has been introduced
> recently. It could simplify this code a bit and is preferred over
> devm_ioremap().
yes right. I somehow missed this api.
>
>> + resource_size());
>> + if (!dvfs_info->base) {
>> + pr_err("No cpufreq memory map found\n");
>> + ret = -ENODEV;
>> + goto err_put_node;
>> + }
>> +
>> + dvfs_info->irq = irq_of_parse_and_map(np, 0);
>> + if (dvfs_info->irq == 0) {
>> + pr_err("No cpufreq irq found\n");
>
> Wouldn't dev_err() be more appropriate here ?
Ok
>
>> + ret = -ENODEV;
>> + goto err_put_node;
>> + }
>> +
>> + ret = of_init_opp_table(dvfs_info->dev);
>> + if (ret) {
>> + pr_err("failed to init OPP table: %d\n", ret);
>> + goto err_put_node;
>> + }
>> +
>> + ret = opp_init_cpufreq_table(dvfs_info->dev, _info->freq_table);
>> + if (ret) {
>> + pr_err("failed to init cpufreq table: %d\n", ret);
>> + goto err_put_node;
>> + }
>> + dvfs_info->freq_count = opp_get_opp_count(dvfs_info->dev);
>> + exynos_sort_descend_freq_table();
>> +
>> + if (of_property_read_u32(np, "clock-latency", _info->latency))
>> + dvfs_info->latency = DEF_TRANS_LATENCY;
>> +
>> + dvfs_info->cpu_clk = devm_clk_get(dvfs_info->dev, "armclk");
>> + if (IS_ERR_OR_NULL(dvfs_info->cpu_clk)) {
>
> devm_clk_get() return value needs to be checked with IS_ERR(),
> not IS_ERR_OR_NULL().
ok
>
>> + pr_err("Failed to get cpu clock\n");
>> + ret = PTR_ERR(dvfs_info->cpu_clk);
>> + goto err_free_table;
>> + }
>> +
>> + dvfs_info->cur_frequency = clk_get_rate(dvfs_info->cpu_clk);
>> + if (!dvfs_info->cur_frequency) {
>> + pr_err("Failed to get clock rate\n");
>> + ret = -EINVAL;
>> + goto err_free_table;
>> + }
>> + dvfs_info->cur_frequency /= 1000;
>> +
>> + INIT_WORK(_info->irq_work, exynos_cpufreq_work);
>> + if (devm_request_irq(dvfs_info->dev, dvfs_info->irq,
>> exynos_cpufreq_irq,
>> + IRQF_TRIGGER_NONE, CPUFREQ_NAME, dvfs_info)) {
>> + pr_err("Failed to register IRQ\n");
>> + ret = -ENODEV;
>> + goto err_free_table;
>> + }
>> +
>> + ret = init_div_table();
>> + if (ret) {
>> + pr_err("Failed to initialise div table\n");
>> + goto err_free_table;
>> + }
>> +
>> + exynos_enable_dvfs();
>> + ret = cpufreq_register_driver(_driver);
>> + if (ret) {
>> + pr_err("%s: failed to register cpufreq driver\n", __func__);
>> + goto err_free_table;
>> + }
>> +
>> + of_node_put(np);
>> + dvfs_info->dvfs_enable = true;
>> + pr_info("exynos5440 DVFS initialized.\n");
>
> dev_info() ?
>
>> + return 0;
>> +
>> +err_free_table:
>> + opp_free_cpufreq_table(dvfs_info->dev, _info->freq_table);
>>
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Sylwester,
Thanks for the review. Will update with your suggestion in the next version,
Thanks,
Amit D
On Thu, Mar 7, 2013 at 8:58 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
+/* Register definations */
s/definations/definitions
ok
+#define XMU_DVFS_CTRL0x0060
+#define XMU_PMU_P0_7 0x0064
+#define XMU_C0_3_PSTATE 0x0090
+#define XMU_P_LIMIT 0x00A0
+#define XMU_P_STATUS 0x00A4
+#define XMU_PMUEVTEN 0x00D0
+#define XMU_PMUIRQEN 0x00D4
+#define XMU_PMUIRQ 0x00D8
Keeping all hex numbers lower case might be a good idea.
Ok
+
+/* PMU mask and shift definations */
+#define P_VALUE_MASK 0x7
+
+#define XMU_DVFS_CTRL_EN_SHIFT 0
+
+#define P0_7_CPUCLKDEV_SHIFT 21
+#define P0_7_CPUCLKDEV_MASK 0x7
+#define P0_7_ATBCLKDEV_SHIFT 18
+#define P0_7_ATBCLKDEV_MASK 0x7
+#define P0_7_CSCLKDEV_SHIFT 15
+#define P0_7_CSCLKDEV_MASK 0x7
+#define P0_7_CPUEMA_SHIFT28
+#define P0_7_CPUEMA_MASK 0xf
+#define P0_7_L2EMA_SHIFT 24
+#define P0_7_L2EMA_MASK 0xf
...
+static int exynos_cpufreq_probe(struct platform_device *pdev)
+{
+ int ret = -EINVAL;
+ struct device_node *np;
+ struct resource res;
+
+ np = of_find_compatible_node(NULL, NULL,
samsung,exynos5440-cpufreq);
+ if (!np)
+ return -ENODEV;
+
+ dvfs_info = devm_kzalloc(pdev-dev, sizeof(*dvfs_info), GFP_KERNEL);
+ if (!dvfs_info) {
+ ret = -ENOMEM;
+ goto err_put_node;
+ }
+
+ dvfs_info-dev = pdev-dev;
+ dvfs_info-dev-of_node = np;
+
+ ret = of_address_to_resource(np, 0, res);
+ if (ret)
+ goto err_put_node;
+
+ dvfs_info-base = devm_ioremap(dvfs_info-dev, res.start,
There is a devm_ioremap_resource() function that has been introduced
recently. It could simplify this code a bit and is preferred over
devm_ioremap().
yes right. I somehow missed this api.
+ resource_size(res));
+ if (!dvfs_info-base) {
+ pr_err(No cpufreq memory map found\n);
+ ret = -ENODEV;
+ goto err_put_node;
+ }
+
+ dvfs_info-irq = irq_of_parse_and_map(np, 0);
+ if (dvfs_info-irq == 0) {
+ pr_err(No cpufreq irq found\n);
Wouldn't dev_err() be more appropriate here ?
Ok
+ ret = -ENODEV;
+ goto err_put_node;
+ }
+
+ ret = of_init_opp_table(dvfs_info-dev);
+ if (ret) {
+ pr_err(failed to init OPP table: %d\n, ret);
+ goto err_put_node;
+ }
+
+ ret = opp_init_cpufreq_table(dvfs_info-dev, dvfs_info-freq_table);
+ if (ret) {
+ pr_err(failed to init cpufreq table: %d\n, ret);
+ goto err_put_node;
+ }
+ dvfs_info-freq_count = opp_get_opp_count(dvfs_info-dev);
+ exynos_sort_descend_freq_table();
+
+ if (of_property_read_u32(np, clock-latency, dvfs_info-latency))
+ dvfs_info-latency = DEF_TRANS_LATENCY;
+
+ dvfs_info-cpu_clk = devm_clk_get(dvfs_info-dev, armclk);
+ if (IS_ERR_OR_NULL(dvfs_info-cpu_clk)) {
devm_clk_get() return value needs to be checked with IS_ERR(),
not IS_ERR_OR_NULL().
ok
+ pr_err(Failed to get cpu clock\n);
+ ret = PTR_ERR(dvfs_info-cpu_clk);
+ goto err_free_table;
+ }
+
+ dvfs_info-cur_frequency = clk_get_rate(dvfs_info-cpu_clk);
+ if (!dvfs_info-cur_frequency) {
+ pr_err(Failed to get clock rate\n);
+ ret = -EINVAL;
+ goto err_free_table;
+ }
+ dvfs_info-cur_frequency /= 1000;
+
+ INIT_WORK(dvfs_info-irq_work, exynos_cpufreq_work);
+ if (devm_request_irq(dvfs_info-dev, dvfs_info-irq,
exynos_cpufreq_irq,
+ IRQF_TRIGGER_NONE, CPUFREQ_NAME, dvfs_info)) {
+ pr_err(Failed to register IRQ\n);
+ ret = -ENODEV;
+ goto err_free_table;
+ }
+
+ ret = init_div_table();
+ if (ret) {
+ pr_err(Failed to initialise div table\n);
+ goto err_free_table;
+ }
+
+ exynos_enable_dvfs();
+ ret = cpufreq_register_driver(exynos_driver);
+ if (ret) {
+ pr_err(%s: failed to register cpufreq driver\n, __func__);
+ goto err_free_table;
+ }
+
+ of_node_put(np);
+ dvfs_info-dvfs_enable = true;
+ pr_info(exynos5440 DVFS initialized.\n);
dev_info() ?
+ return 0;
+
+err_free_table:
+ opp_free_cpufreq_table(dvfs_info-dev, dvfs_info-freq_table);
+err_put_node:
+ of_node_put(np);
+ pr_err(%s: failed initialization\n, __func__);
Is this really needed ? This failure will be logged by the driver core
anyway.
+ return ret;
+
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Russell,
On Thu, Mar 7, 2013 at 9:07 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Mar 07, 2013 at 04:28:00PM +0100, Sylwester Nawrocki wrote:
On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
+ dvfs_info-cpu_clk = devm_clk_get(dvfs_info-dev, armclk);
+ if (IS_ERR_OR_NULL(dvfs_info-cpu_clk)) {
devm_clk_get() return value needs to be checked with IS_ERR(),
not IS_ERR_OR_NULL().
+ pr_err(Failed to get cpu clock\n);
+ ret = PTR_ERR(dvfs_info-cpu_clk);
+ goto err_free_table;
Amit, to illustrate why this is wrong, consider this:
1. Set cpu_clk to NULL.
2. Realise IS_ERR_OR_NULL(NULL) is true.
3. What is the value of PTR_ERR(NULL) ?
4. What effect does that have when you jump to err_free_table ?
5. What value is returned from this function in that case ?
6. What does that return value mean to the driver core ?
Thanks for the detailed explaination. Usage of IS_ERR_OR_NULL is not
suitable here.
Thanks,
Amit D
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
On Sat, Mar 9, 2013 at 4:17 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 7 March 2013 12:13, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
+struct exynos_dvfs_data {
+ void __iomem *base;
+ struct resource *mem;
+ int irq;
+ struct clk *cpu_clk;
+ unsigned int cur_frequency;
+ unsigned int latency;
+ struct cpufreq_frequency_table *freq_table;
+ unsigned int freq_count;
+ struct device *dev;
+ bool dvfs_enable;
s/enable/enabled?
Ok
+static int exynos_cpufreq_probe(struct platform_device *pdev)
+ dvfs_info-cpu_clk = devm_clk_get(dvfs_info-dev, armclk);
+ if (IS_ERR_OR_NULL(dvfs_info-cpu_clk)) {
s/IS_ERR_OR_NULL/IS_ERR
Ok.
+ if (devm_request_irq(dvfs_info-dev, dvfs_info-irq,
exynos_cpufreq_irq,
+ IRQF_TRIGGER_NONE, CPUFREQ_NAME, dvfs_info))
{
+ pr_err(Failed to register IRQ\n);
+ ret = -ENODEV;
use the value returned from this function rather than creating your
own.. true for all
other calls too, unless they return NULL on error.
Will integrate your suggestions in the next version.
Thanks,
Amit D
+}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
Again thanks for your review comments.
On Tue, Mar 5, 2013 at 6:48 AM, Viresh Kumar wrote:
> On 2 March 2013 15:04, Amit Daniel Kachhap wrote:
>> This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
>> they run at same frequency. The nature of exynos5440 clock controller is
>> different from previous exynos controllers so not using the common exynos
>> cpufreq framework. The major difference being interrupt notfication for
>> frequency change. Also, OPP library is used for device tree parsing to get
>> different parameters like frequency, voltage etc. Since the opp library sorts
>> the frequency table in ascending order so they are again re-arranged in
>> descending order. This will have one-to-one mapping with the clock controller
>> state management logic.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> Changes in V2:
>> * Added OPP library support to parse DT parameters.
>> * Removed a hack to handle interrupts in bootup.
>> * Added many review comments from Viresh and Inder.
>
> Added? Thanks :)
typo error :)
>
>>
>> All these patches are dependent on Thomas Abraham common clock patches.
>> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html
>>
>> .../bindings/cpufreq/cpufreq-exynos5440.txt| 32 ++
>> drivers/cpufreq/Kconfig.arm|9 +
>> drivers/cpufreq/Makefile |1 +
>> drivers/cpufreq/exynos5440-cpufreq.c | 450
>>
>> 4 files changed, 492 insertions(+), 0 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>> create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>> new file mode 100644
>> index 000..caa3f8d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
>> @@ -0,0 +1,32 @@
>> +
>> +Exynos5440 cpufreq driver
>> +---
>> +
>> +Exynos5440 SoC cpufreq driver for CPU frequency scaling.
>> +
>> +Required properties:
>> +- interrupts: Interrupt to know the completion of cpu frequency change.
>> +- operating-points: Table of frequencies and voltage CPU could be
>> transitioned into,
>> + in the decreasing order. Frequency should be in KHZ units and voltage
>> + should be in microvolts.
>> +- clocks: phandle of the clock from common clock binding. More description
>> can
>> + be found in
>> Documentation/devicetree/bindings/clock/clock-bindings.txt.
>> +
>> +Optional properties:
>> +- clock-latency: Clock transition latency in microsecond.
>> +
>> +All the required listed above must be defined under node cpufreq.
>> +
>> +Example:
>> +
>> + cpufreq@16 {
>> + compatible = "samsung,exynos5440-cpufreq";
>> + reg = <0x16 0x1000>;
>> + interrupts = <0 57 0>;
>> + operating-points = <
>> + 100 975000
>> + 80 925000>;
>> + clocks = < 2>;
>> + clock-latency = <10>;
>> + };
>> +
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index 030ddf6..7ed9c4a 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -77,6 +77,15 @@ config ARM_EXYNOS5250_CPUFREQ
>> This adds the CPUFreq driver for Samsung EXYNOS5250
>> SoC.
>>
>> +config ARM_EXYNOS5440_CPUFREQ
>> + def_bool SOC_EXYNOS5440
>> + depends on HAVE_CLK && PM_OPP && OF
>> + help
>> + This adds the CPUFreq driver for Samsung EXYNOS5440
>> + SoC. The nature of exynos5440 clock controller is
>> + different than previous exynos controllers so not using
>> + the common exynos framework.
>> +
>> config ARM_KIRKWOOD_CPUFREQ
>> def_bool ARCH_KIRKWOOD && OF
>> help
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index 863fd18..c841438 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
>> obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
>> obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
>> obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
>> +obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
>> obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
>> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
>> obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
>> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
>> b/drivers/cpufreq/exynos5440-cpufreq.c
>> new file mode 100644
>> index 000..2dc43b1
>> --- /dev/null
>> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
>> @@ -0,0 +1,450 @@
>>
Re: [PATCH V2 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
Hi Viresh,
Again thanks for your review comments.
On Tue, Mar 5, 2013 at 6:48 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 2 March 2013 15:04, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they run at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notfication for
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Changes in V2:
* Added OPP library support to parse DT parameters.
* Removed a hack to handle interrupts in bootup.
* Added many review comments from Viresh and Inder.
Added? Thanks :)
typo error :)
All these patches are dependent on Thomas Abraham common clock patches.
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html
.../bindings/cpufreq/cpufreq-exynos5440.txt| 32 ++
drivers/cpufreq/Kconfig.arm|9 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 450
4 files changed, 492 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git
a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..caa3f8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,32 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be
transitioned into,
+ in the decreasing order. Frequency should be in KHZ units and voltage
+ should be in microvolts.
+- clocks: phandle of the clock from common clock binding. More description
can
+ be found in
Documentation/devicetree/bindings/clock/clock-bindings.txt.
+
+Optional properties:
+- clock-latency: Clock transition latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = samsung,exynos5440-cpufreq;
+ reg = 0x16 0x1000;
+ interrupts = 0 57 0;
+ operating-points =
+ 100 975000
+ 80 925000;
+ clocks = clock 2;
+ clock-latency = 10;
+ };
+
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 030ddf6..7ed9c4a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -77,6 +77,15 @@ config ARM_EXYNOS5250_CPUFREQ
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+config ARM_EXYNOS5440_CPUFREQ
+ def_bool SOC_EXYNOS5440
+ depends on HAVE_CLK PM_OPP OF
+ help
+ This adds the CPUFreq driver for Samsung EXYNOS5440
+ SoC. The nature of exynos5440 clock controller is
+ different than previous exynos controllers so not using
+ the common exynos framework.
+
config ARM_KIRKWOOD_CPUFREQ
def_bool ARCH_KIRKWOOD OF
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 863fd18..c841438 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 000..2dc43b1
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,450 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Amit Daniel Kachhap amit.dan...@samsung.com
+ *
+ * EXYNOS5440 -
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
On Thu, Feb 7, 2013 at 7:04 PM, Zhang Rui wrote:
> On Mon, 2013-02-04 at 10:14 +0800, Zhang Rui wrote:
>> On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
>> > This removes the driver specific sysfs support of the temperature
>> > emulation and uses the newly added core thermal framework for thermal
>> > emulation. A platform specific handler is added to support this.
>> >
>> > Signed-off-by: Amit Daniel Kachhap
>> > Acked-by: Kukjin Kim
>> > ---
>> > Changes in V2:
>> > * Added config option CONFIG_THERMAL_EMULATION instead of
>> > CONFIG_EXYNOS_THERMAL_EMUL
>> >
>> > This patchset is based on thermal maintainer next tree.
>> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
>> >
>> > Documentation/thermal/exynos_thermal_emulation |8 +-
>> > drivers/thermal/Kconfig|9 --
>> > drivers/thermal/exynos_thermal.c | 158
>> > ++--
>> > 3 files changed, 67 insertions(+), 108 deletions(-)
>> >
>> > diff --git a/Documentation/thermal/exynos_thermal_emulation
>> > b/Documentation/thermal/exynos_thermal_emulation
>> > index b73bbfb..36a3e79 100644
>> > --- a/Documentation/thermal/exynos_thermal_emulation
>> > +++ b/Documentation/thermal/exynos_thermal_emulation
>> > @@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for
>> > TMU's operation. User can set
>> > manually with software code and TMU will read current temperature from
>> > user value not from
>> > sensor's value.
>> >
>> > -Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
>> > available.
>> > -When it's enabled, sysfs node will be created under
>> > -/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
>> > +Enabling CONFIG_THERMAL_EMULATION option will make this support available.
>> > +When it's enabled, sysfs node will be created as
>> > +/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
>> >
>> > -The sysfs node, 'emulation', will contain value 0 for the initial state.
>> > When you input any
>> > +The sysfs node, 'emul_node', will contain value 0 for the initial state.
>> > When you input any
>> > temperature you want to update to sysfs node, it automatically enable
>> > emulation mode and
>> > current temperature will be changed into it.
>> > (Exynos also supports user changable delay time which would be used to
>> > delay of
>> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> > index e4cf7fb..2a79510 100644
>> > --- a/drivers/thermal/Kconfig
>> > +++ b/drivers/thermal/Kconfig
>> > @@ -109,15 +109,6 @@ config EXYNOS_THERMAL
>> > If you say yes here you get support for TMU (Thermal Management
>> > Unit) on SAMSUNG EXYNOS series of SoC.
>> >
>> > -config EXYNOS_THERMAL_EMUL
>> > - bool "EXYNOS TMU emulation mode support"
>> > - depends on EXYNOS_THERMAL
>> > - help
>> > - Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
>> > - Enable this option will be make sysfs node in exynos thermal platform
>> > - device directory to support emulation mode. With emulation mode sysfs
>> > - node, you can manually input temperature to TMU for simulation
>> > purpose.
>> > -
>> > config DB8500_THERMAL
>> > bool "DB8500 thermal management"
>> > depends on ARCH_U8500
>> > diff --git a/drivers/thermal/exynos_thermal.c
>> > b/drivers/thermal/exynos_thermal.c
>> > index 327102a..afe9c2a 100644
>> > --- a/drivers/thermal/exynos_thermal.c
>> > +++ b/drivers/thermal/exynos_thermal.c
>> > @@ -99,13 +99,13 @@
>> > #define IDLE_INTERVAL 1
>> > #define MCELSIUS 1000
>> >
>> > -#ifdef CONFIG_EXYNOS_THERMAL_EMUL
>> > +#ifdef CONFIG_THERMAL_EMULATION
>> > #define EXYNOS_EMUL_TIME 0x57F0
>> > #define EXYNOS_EMUL_TIME_SHIFT 16
>> > #define EXYNOS_EMUL_DATA_SHIFT 8
>> > #define EXYNOS_EMUL_DATA_MASK 0xFF
>> > #define EXYNOS_EMUL_ENABLE 0x1
>> > -#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
>> > +#endif /* CONFIG_THERMAL_EMULATION */
>> >
>> > /* CPU Zone information */
>> > #define PANIC_ZONE 4
>> > @@ -143,6 +143,7 @@ struct thermal_cooling_conf {
>> > struct thermal_sensor_conf {
>> > char name[SENSOR_NAME_LEN];
>> > int (*read_temperature)(void *data);
>> > + int (*write_emul_temp)(void *data, unsigned long temp);
>> > struct thermal_trip_point_conf trip_data;
>> > struct thermal_cooling_conf cooling_data;
>> > void *private_data;
>> > @@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device
>> > *thermal,
>> > return 0;
>> > }
>> >
>> > +/* Get temperature callback functions for thermal zone */
>> > +static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
>> > + unsigned long temp)
>> > +{
>> > + void *data;
>> > + int ret = -EINVAL;
>> > +
>> > + if (!th_zone->sensor_conf) {
>> > + pr_info("Temperature sensor not initialised\n");
>> > + return -EINVAL;
>> > +
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
Hi Rui,
Please merge this patch also. The 1st series of this patchset is
already accepted by you. This is just a adaptation of the earlier one
and does code cleanup.
Thanks,
Amit Daniel
On Sun, Feb 3, 2013 at 6:14 PM, Zhang Rui wrote:
> On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
>> This removes the driver specific sysfs support of the temperature
>> emulation and uses the newly added core thermal framework for thermal
>> emulation. A platform specific handler is added to support this.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> Acked-by: Kukjin Kim
>> ---
>> Changes in V2:
>> * Added config option CONFIG_THERMAL_EMULATION instead of
>> CONFIG_EXYNOS_THERMAL_EMUL
>>
>> This patchset is based on thermal maintainer next tree.
>> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
>>
>> Documentation/thermal/exynos_thermal_emulation |8 +-
>> drivers/thermal/Kconfig|9 --
>> drivers/thermal/exynos_thermal.c | 158
>> ++--
>> 3 files changed, 67 insertions(+), 108 deletions(-)
>>
>> diff --git a/Documentation/thermal/exynos_thermal_emulation
>> b/Documentation/thermal/exynos_thermal_emulation
>> index b73bbfb..36a3e79 100644
>> --- a/Documentation/thermal/exynos_thermal_emulation
>> +++ b/Documentation/thermal/exynos_thermal_emulation
>> @@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for TMU's
>> operation. User can set
>> manually with software code and TMU will read current temperature from user
>> value not from
>> sensor's value.
>>
>> -Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
>> available.
>> -When it's enabled, sysfs node will be created under
>> -/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
>> +Enabling CONFIG_THERMAL_EMULATION option will make this support available.
>> +When it's enabled, sysfs node will be created as
>> +/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
>>
>> -The sysfs node, 'emulation', will contain value 0 for the initial state.
>> When you input any
>> +The sysfs node, 'emul_node', will contain value 0 for the initial state.
>> When you input any
>> temperature you want to update to sysfs node, it automatically enable
>> emulation mode and
>> current temperature will be changed into it.
>> (Exynos also supports user changable delay time which would be used to
>> delay of
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index e4cf7fb..2a79510 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -109,15 +109,6 @@ config EXYNOS_THERMAL
>> If you say yes here you get support for TMU (Thermal Management
>> Unit) on SAMSUNG EXYNOS series of SoC.
>>
>> -config EXYNOS_THERMAL_EMUL
>> - bool "EXYNOS TMU emulation mode support"
>> - depends on EXYNOS_THERMAL
>> - help
>> - Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
>> - Enable this option will be make sysfs node in exynos thermal platform
>> - device directory to support emulation mode. With emulation mode sysfs
>> - node, you can manually input temperature to TMU for simulation
>> purpose.
>> -
>> config DB8500_THERMAL
>> bool "DB8500 thermal management"
>> depends on ARCH_U8500
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> index 327102a..afe9c2a 100644
>> --- a/drivers/thermal/exynos_thermal.c
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -99,13 +99,13 @@
>> #define IDLE_INTERVAL 1
>> #define MCELSIUS 1000
>>
>> -#ifdef CONFIG_EXYNOS_THERMAL_EMUL
>> +#ifdef CONFIG_THERMAL_EMULATION
>> #define EXYNOS_EMUL_TIME 0x57F0
>> #define EXYNOS_EMUL_TIME_SHIFT 16
>> #define EXYNOS_EMUL_DATA_SHIFT 8
>> #define EXYNOS_EMUL_DATA_MASK0xFF
>> #define EXYNOS_EMUL_ENABLE 0x1
>> -#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
>> +#endif /* CONFIG_THERMAL_EMULATION */
>>
>> /* CPU Zone information */
>> #define PANIC_ZONE 4
>> @@ -143,6 +143,7 @@ structthermal_cooling_conf {
>> struct thermal_sensor_conf {
>> char name[SENSOR_NAME_LEN];
>> int (*read_temperature)(void *data);
>> + int (*write_emul_temp)(void *data, unsigned long temp);
>> struct thermal_trip_point_conf trip_data;
>> struct thermal_cooling_conf cooling_data;
>> void *private_data;
>> @@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device
>> *thermal,
>> return 0;
>> }
>>
>> +/* Get temperature callback functions for thermal zone */
>> +static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
>> + unsigned long temp)
>> +{
>> + void *data;
>> + int ret = -EINVAL;
>> +
>> + if (!th_zone->sensor_conf) {
>> + pr_info("Temperature sensor not initialised\n");
>> + return -EINVAL;
>> + }
>> + data =
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
Hi Rui,
Please merge this patch also. The 1st series of this patchset is
already accepted by you. This is just a adaptation of the earlier one
and does code cleanup.
Thanks,
Amit Daniel
On Sun, Feb 3, 2013 at 6:14 PM, Zhang Rui rui.zh...@intel.com wrote:
On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
This removes the driver specific sysfs support of the temperature
emulation and uses the newly added core thermal framework for thermal
emulation. A platform specific handler is added to support this.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
Changes in V2:
* Added config option CONFIG_THERMAL_EMULATION instead of
CONFIG_EXYNOS_THERMAL_EMUL
This patchset is based on thermal maintainer next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
Documentation/thermal/exynos_thermal_emulation |8 +-
drivers/thermal/Kconfig|9 --
drivers/thermal/exynos_thermal.c | 158
++--
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/Documentation/thermal/exynos_thermal_emulation
b/Documentation/thermal/exynos_thermal_emulation
index b73bbfb..36a3e79 100644
--- a/Documentation/thermal/exynos_thermal_emulation
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for TMU's
operation. User can set
manually with software code and TMU will read current temperature from user
value not from
sensor's value.
-Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
available.
-When it's enabled, sysfs node will be created under
-/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
+Enabling CONFIG_THERMAL_EMULATION option will make this support available.
+When it's enabled, sysfs node will be created as
+/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
-The sysfs node, 'emulation', will contain value 0 for the initial state.
When you input any
+The sysfs node, 'emul_node', will contain value 0 for the initial state.
When you input any
temperature you want to update to sysfs node, it automatically enable
emulation mode and
current temperature will be changed into it.
(Exynos also supports user changable delay time which would be used to
delay of
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e4cf7fb..2a79510 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -109,15 +109,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for TMU (Thermal Management
Unit) on SAMSUNG EXYNOS series of SoC.
-config EXYNOS_THERMAL_EMUL
- bool EXYNOS TMU emulation mode support
- depends on EXYNOS_THERMAL
- help
- Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
- Enable this option will be make sysfs node in exynos thermal platform
- device directory to support emulation mode. With emulation mode sysfs
- node, you can manually input temperature to TMU for simulation
purpose.
-
config DB8500_THERMAL
bool DB8500 thermal management
depends on ARCH_U8500
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 327102a..afe9c2a 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -99,13 +99,13 @@
#define IDLE_INTERVAL 1
#define MCELSIUS 1000
-#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+#ifdef CONFIG_THERMAL_EMULATION
#define EXYNOS_EMUL_TIME 0x57F0
#define EXYNOS_EMUL_TIME_SHIFT 16
#define EXYNOS_EMUL_DATA_SHIFT 8
#define EXYNOS_EMUL_DATA_MASK0xFF
#define EXYNOS_EMUL_ENABLE 0x1
-#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
+#endif /* CONFIG_THERMAL_EMULATION */
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -143,6 +143,7 @@ structthermal_cooling_conf {
struct thermal_sensor_conf {
char name[SENSOR_NAME_LEN];
int (*read_temperature)(void *data);
+ int (*write_emul_temp)(void *data, unsigned long temp);
struct thermal_trip_point_conf trip_data;
struct thermal_cooling_conf cooling_data;
void *private_data;
@@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device
*thermal,
return 0;
}
+/* Get temperature callback functions for thermal zone */
+static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
+ unsigned long temp)
+{
+ void *data;
+ int ret = -EINVAL;
+
+ if (!th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ return -EINVAL;
+ }
+ data = th_zone-sensor_conf-private_data;
+ if (th_zone-sensor_conf-write_emul_temp)
+ ret = th_zone-sensor_conf-write_emul_temp(data, temp);
+ return ret;
+}
+
/* Get
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
On Thu, Feb 7, 2013 at 7:04 PM, Zhang Rui rui.zh...@intel.com wrote:
On Mon, 2013-02-04 at 10:14 +0800, Zhang Rui wrote:
On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
This removes the driver specific sysfs support of the temperature
emulation and uses the newly added core thermal framework for thermal
emulation. A platform specific handler is added to support this.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
Changes in V2:
* Added config option CONFIG_THERMAL_EMULATION instead of
CONFIG_EXYNOS_THERMAL_EMUL
This patchset is based on thermal maintainer next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
Documentation/thermal/exynos_thermal_emulation |8 +-
drivers/thermal/Kconfig|9 --
drivers/thermal/exynos_thermal.c | 158
++--
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/Documentation/thermal/exynos_thermal_emulation
b/Documentation/thermal/exynos_thermal_emulation
index b73bbfb..36a3e79 100644
--- a/Documentation/thermal/exynos_thermal_emulation
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for
TMU's operation. User can set
manually with software code and TMU will read current temperature from
user value not from
sensor's value.
-Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
available.
-When it's enabled, sysfs node will be created under
-/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
+Enabling CONFIG_THERMAL_EMULATION option will make this support available.
+When it's enabled, sysfs node will be created as
+/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
-The sysfs node, 'emulation', will contain value 0 for the initial state.
When you input any
+The sysfs node, 'emul_node', will contain value 0 for the initial state.
When you input any
temperature you want to update to sysfs node, it automatically enable
emulation mode and
current temperature will be changed into it.
(Exynos also supports user changable delay time which would be used to
delay of
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e4cf7fb..2a79510 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -109,15 +109,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for TMU (Thermal Management
Unit) on SAMSUNG EXYNOS series of SoC.
-config EXYNOS_THERMAL_EMUL
- bool EXYNOS TMU emulation mode support
- depends on EXYNOS_THERMAL
- help
- Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
- Enable this option will be make sysfs node in exynos thermal platform
- device directory to support emulation mode. With emulation mode sysfs
- node, you can manually input temperature to TMU for simulation
purpose.
-
config DB8500_THERMAL
bool DB8500 thermal management
depends on ARCH_U8500
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 327102a..afe9c2a 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -99,13 +99,13 @@
#define IDLE_INTERVAL 1
#define MCELSIUS 1000
-#ifdef CONFIG_EXYNOS_THERMAL_EMUL
+#ifdef CONFIG_THERMAL_EMULATION
#define EXYNOS_EMUL_TIME 0x57F0
#define EXYNOS_EMUL_TIME_SHIFT 16
#define EXYNOS_EMUL_DATA_SHIFT 8
#define EXYNOS_EMUL_DATA_MASK 0xFF
#define EXYNOS_EMUL_ENABLE 0x1
-#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
+#endif /* CONFIG_THERMAL_EMULATION */
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -143,6 +143,7 @@ struct thermal_cooling_conf {
struct thermal_sensor_conf {
char name[SENSOR_NAME_LEN];
int (*read_temperature)(void *data);
+ int (*write_emul_temp)(void *data, unsigned long temp);
struct thermal_trip_point_conf trip_data;
struct thermal_cooling_conf cooling_data;
void *private_data;
@@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device
*thermal,
return 0;
}
+/* Get temperature callback functions for thermal zone */
+static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
+ unsigned long temp)
+{
+ void *data;
+ int ret = -EINVAL;
+
+ if (!th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ return -EINVAL;
+ }
+ data = th_zone-sensor_conf-private_data;
+ if (th_zone-sensor_conf-write_emul_temp)
+ ret = th_zone-sensor_conf-write_emul_temp(data, temp);
+ return ret;
+}
+
/* Get the temperature trend */
static int exynos_get_trend(struct thermal_zone_device
Re: [PATCH] Thermal: fix iteration over CPU frequency list
On Thu, Jan 24, 2013 at 7:24 AM, Gu1 wrote:
> In different places in the Thermal code, the CPU frequency list is iterated
> in an incorrect way, leading to endless loops when the frequency list contains
> a CPUFREQ_TABLE_INVALID entry, which is the case by default in the the Exynos
> 4x12 cpufreq driver, for example.
>
> The frequency list is iterated with a while loop, and when a
> CPUFREQ_TABLE_INVALID entry is encountered, the continue; statement is used to
> skip it, but the index is not incremented, causing an endless loop.
>
> A similar bug was fixed by hongbo.zhang in commit:
> Thermal: fix bug of counting cpu frequencies
>
> Signed-off-by: Gu1
This changes looks fine.
Reviewed-by: Amit Daniel Kachhap
Thanks,
Amit Daniel
> ---
> drivers/thermal/cpu_cooling.c| 8 +++-
> drivers/thermal/exynos_thermal.c | 9 +
> 2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 836828e..51acd26 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -123,7 +123,7 @@ static int is_cpufreq_valid(int cpu)
> */
> static unsigned int get_cpu_frequency(unsigned int cpu, unsigned long level)
> {
> - int ret = 0, i = 0;
> + int ret = 0, i;
> unsigned long level_index;
> bool descend = false;
> struct cpufreq_frequency_table *table =
> @@ -131,7 +131,7 @@ static unsigned int get_cpu_frequency(unsigned int cpu,
> unsigned long level)
> if (!table)
> return ret;
>
> - while (table[i].frequency != CPUFREQ_TABLE_END) {
> + for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
> if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> continue;
>
> @@ -145,7 +145,6 @@ static unsigned int get_cpu_frequency(unsigned int cpu,
> unsigned long level)
> /*return if level matched and table in descending order*/
> if (descend && i == level)
> return table[i].frequency;
> - i++;
> }
> i--;
>
> @@ -154,13 +153,12 @@ static unsigned int get_cpu_frequency(unsigned int cpu,
> unsigned long level)
> level_index = i - level;
>
> /*Scan the table in reverse order and match the level*/
> - while (i >= 0) {
> + for (; i >= 0; i--) {
> if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> continue;
> /*return if level matched*/
> if (i == level_index)
> return table[i].frequency;
> - i--;
> }
> return ret;
> }
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index 224751e..fa9e1d7 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -233,7 +233,8 @@ static int exynos_get_crit_temp(struct
> thermal_zone_device *thermal,
>
> static int exynos_get_frequency_level(unsigned int cpu, unsigned int freq)
> {
> - int i = 0, ret = -EINVAL;
> + int i, ret = -EINVAL;
> + unsigned int count = 0;
> struct cpufreq_frequency_table *table = NULL;
> #ifdef CONFIG_CPU_FREQ
> table = cpufreq_frequency_get_table(cpu);
> @@ -241,12 +242,12 @@ static int exynos_get_frequency_level(unsigned int cpu,
> unsigned int freq)
> if (!table)
> return ret;
>
> - while (table[i].frequency != CPUFREQ_TABLE_END) {
> + for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
> if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> continue;
> if (table[i].frequency == freq)
> - return i;
> - i++;
> + return count;
> + count++;
> }
> return ret;
> }
> --
> 1.8.1.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Thermal: fix iteration over CPU frequency list
On Thu, Jan 24, 2013 at 7:24 AM, Gu1 g...@aeroxteam.fr wrote:
In different places in the Thermal code, the CPU frequency list is iterated
in an incorrect way, leading to endless loops when the frequency list contains
a CPUFREQ_TABLE_INVALID entry, which is the case by default in the the Exynos
4x12 cpufreq driver, for example.
The frequency list is iterated with a while loop, and when a
CPUFREQ_TABLE_INVALID entry is encountered, the continue; statement is used to
skip it, but the index is not incremented, causing an endless loop.
A similar bug was fixed by hongbo.zhang in commit:
Thermal: fix bug of counting cpu frequencies
Signed-off-by: Gu1 g...@aeroxteam.fr
This changes looks fine.
Reviewed-by: Amit Daniel Kachhap amit.dan...@samsung.com
Thanks,
Amit Daniel
---
drivers/thermal/cpu_cooling.c| 8 +++-
drivers/thermal/exynos_thermal.c | 9 +
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 836828e..51acd26 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -123,7 +123,7 @@ static int is_cpufreq_valid(int cpu)
*/
static unsigned int get_cpu_frequency(unsigned int cpu, unsigned long level)
{
- int ret = 0, i = 0;
+ int ret = 0, i;
unsigned long level_index;
bool descend = false;
struct cpufreq_frequency_table *table =
@@ -131,7 +131,7 @@ static unsigned int get_cpu_frequency(unsigned int cpu,
unsigned long level)
if (!table)
return ret;
- while (table[i].frequency != CPUFREQ_TABLE_END) {
+ for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
continue;
@@ -145,7 +145,6 @@ static unsigned int get_cpu_frequency(unsigned int cpu,
unsigned long level)
/*return if level matched and table in descending order*/
if (descend i == level)
return table[i].frequency;
- i++;
}
i--;
@@ -154,13 +153,12 @@ static unsigned int get_cpu_frequency(unsigned int cpu,
unsigned long level)
level_index = i - level;
/*Scan the table in reverse order and match the level*/
- while (i = 0) {
+ for (; i = 0; i--) {
if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
continue;
/*return if level matched*/
if (i == level_index)
return table[i].frequency;
- i--;
}
return ret;
}
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 224751e..fa9e1d7 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -233,7 +233,8 @@ static int exynos_get_crit_temp(struct
thermal_zone_device *thermal,
static int exynos_get_frequency_level(unsigned int cpu, unsigned int freq)
{
- int i = 0, ret = -EINVAL;
+ int i, ret = -EINVAL;
+ unsigned int count = 0;
struct cpufreq_frequency_table *table = NULL;
#ifdef CONFIG_CPU_FREQ
table = cpufreq_frequency_get_table(cpu);
@@ -241,12 +242,12 @@ static int exynos_get_frequency_level(unsigned int cpu,
unsigned int freq)
if (!table)
return ret;
- while (table[i].frequency != CPUFREQ_TABLE_END) {
+ for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
continue;
if (table[i].frequency == freq)
- return i;
- i++;
+ return count;
+ count++;
}
return ret;
}
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] thermal: sysfs: Add a new sysfs node emul_temp for thermal emulation
On Fri, Feb 1, 2013 at 12:27 AM, Zhang Rui wrote:
> On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
>> This patch adds support to set the emulated temperature method in
>> thermal zone (sensor). After setting this feature thermal zone may
>> report this temperature and not the actual temperature. The emulation
>> implementation may be based on sensor capability through platform
>> specific handler or pure software emulation if no platform handler defined.
>>
>> This is useful in debugging different temperature threshold and its
>> associated cooling action. Critical threshold's cannot be emulated.
>> Writing 0 on this node should disable emulation.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> Acked-by: Kukjin Kim
>> ---
>>
>> Changes in V2:
>> * Added config option for enabling emulation support.
>> * Added s/w emulation if no platform handler registered.
>> * skip the critical trip point emulation
>>
>> This patchset is based on thermal maintainer next tree.
>> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
>>
>> Documentation/thermal/sysfs-api.txt | 13 ++
>> drivers/thermal/Kconfig |8 +++
>> drivers/thermal/thermal_sys.c | 82
>> ++-
>> include/linux/thermal.h |2 +
>> 4 files changed, 94 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt
>> b/Documentation/thermal/sysfs-api.txt
>> index 526d4b9..6859661 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
>> .get_trip_type: get the type of certain trip point.
>> .get_trip_temp: get the temperature above which the certain trip point
>> will be fired.
>> + .set_emul_temp: set the emulation temperature which helps in debugging
>> + different threshold temperature points.
>>
>> 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
>>
>> @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's
>> registered:
>> |---trip_point_[0-*]_temp: Trip point temperature
>> |---trip_point_[0-*]_type: Trip point type
>> |---trip_point_[0-*]_hyst: Hysteresis value for this trip point
>> +|---emul_temp: Emulated temperature set node
>>
>> Thermal cooling device sys I/F, created once it's registered:
>> /sys/class/thermal/cooling_device[0-*]:
>> @@ -252,6 +255,16 @@ passive
>> Valid values: 0 (disabled) or greater than 1000
>> RW, Optional
>>
>> +emul_temp
>> + Interface to set the emulated temperature method in thermal zone
>> + (sensor). After setting this temperature, the thermal zone may pass
>> + this temperature to platform emulation function if registered or
>> + cache it locally. This is useful in debugging different temperature
>> + threshold and its associated cooling action. This is write only node
>> + and writing 0 on this node should disable emulation.
>> + Unit: millidegree Celsius
>> + WO, Optional
>> +
>> *
>> * Cooling device attributes *
>> *
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index faf38c5..e4cf7fb 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -78,6 +78,14 @@ config CPU_THERMAL
>> and not the ACPI interface.
>> If you want this support, you should say Y here.
>>
>> +config THERMAL_EMULATION
>> + bool "Thermal emulation mode support"
>> + help
>> + Enable this option to make a emul_temp sysfs node in thermal zone
>> + directory to support temperature emulation. With emulation sysfs
>> node,
>> + user can manually input temperature and test the different trip
>> + threshold behaviour for simulation purpose.
>> +
>> config SPEAR_THERMAL
>> bool "SPEAr thermal sensor driver"
>> depends on PLAT_SPEAR
>> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
>> index 0a1bf6b..59ba709 100644
>> --- a/drivers/thermal/thermal_sys.c
>> +++ b/drivers/thermal/thermal_sys.c
>> @@ -378,24 +378,57 @@ static void handle_thermal_trip(struct
>> thermal_zone_device *tz, int trip)
>> monitor_thermal_zone(tz);
>> }
>>
>> +static int thermal_zone_get_temp(struct thermal_zone_device *tz,
>> + unsigned long *temp)
>> +{
>> + int ret = 0, count;
>> + unsigned long crit_temp = -1UL;
>> + enum thermal_trip_type type;
>> +
>> + mutex_lock(>lock);
>> +
>> + if (tz->ops->get_temp)
>> + ret = tz->ops->get_temp(tz, temp);
> we do not need to do this check, .get_temp() should always be available.
>
> #ifdef CONFIG_THERMAL_EMUL
>> + else
>> + ret = -EPERM;
>> +
>> + if (!tz->emul_temperature)
>> + goto skip_emul;
>> +
>
>
>> + for (count
Re: [PATCH V2 1/2] thermal: sysfs: Add a new sysfs node emul_temp for thermal emulation
On Fri, Feb 1, 2013 at 12:27 AM, Zhang Rui rui.zh...@intel.com wrote:
On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
This patch adds support to set the emulated temperature method in
thermal zone (sensor). After setting this feature thermal zone may
report this temperature and not the actual temperature. The emulation
implementation may be based on sensor capability through platform
specific handler or pure software emulation if no platform handler defined.
This is useful in debugging different temperature threshold and its
associated cooling action. Critical threshold's cannot be emulated.
Writing 0 on this node should disable emulation.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
Changes in V2:
* Added config option for enabling emulation support.
* Added s/w emulation if no platform handler registered.
* skip the critical trip point emulation
This patchset is based on thermal maintainer next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
Documentation/thermal/sysfs-api.txt | 13 ++
drivers/thermal/Kconfig |8 +++
drivers/thermal/thermal_sys.c | 82
++-
include/linux/thermal.h |2 +
4 files changed, 94 insertions(+), 11 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index 526d4b9..6859661 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
.get_trip_type: get the type of certain trip point.
.get_trip_temp: get the temperature above which the certain trip point
will be fired.
+ .set_emul_temp: set the emulation temperature which helps in debugging
+ different threshold temperature points.
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
@@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's
registered:
|---trip_point_[0-*]_temp: Trip point temperature
|---trip_point_[0-*]_type: Trip point type
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
+|---emul_temp: Emulated temperature set node
Thermal cooling device sys I/F, created once it's registered:
/sys/class/thermal/cooling_device[0-*]:
@@ -252,6 +255,16 @@ passive
Valid values: 0 (disabled) or greater than 1000
RW, Optional
+emul_temp
+ Interface to set the emulated temperature method in thermal zone
+ (sensor). After setting this temperature, the thermal zone may pass
+ this temperature to platform emulation function if registered or
+ cache it locally. This is useful in debugging different temperature
+ threshold and its associated cooling action. This is write only node
+ and writing 0 on this node should disable emulation.
+ Unit: millidegree Celsius
+ WO, Optional
+
*
* Cooling device attributes *
*
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index faf38c5..e4cf7fb 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -78,6 +78,14 @@ config CPU_THERMAL
and not the ACPI interface.
If you want this support, you should say Y here.
+config THERMAL_EMULATION
+ bool Thermal emulation mode support
+ help
+ Enable this option to make a emul_temp sysfs node in thermal zone
+ directory to support temperature emulation. With emulation sysfs
node,
+ user can manually input temperature and test the different trip
+ threshold behaviour for simulation purpose.
+
config SPEAR_THERMAL
bool SPEAr thermal sensor driver
depends on PLAT_SPEAR
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 0a1bf6b..59ba709 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -378,24 +378,57 @@ static void handle_thermal_trip(struct
thermal_zone_device *tz, int trip)
monitor_thermal_zone(tz);
}
+static int thermal_zone_get_temp(struct thermal_zone_device *tz,
+ unsigned long *temp)
+{
+ int ret = 0, count;
+ unsigned long crit_temp = -1UL;
+ enum thermal_trip_type type;
+
+ mutex_lock(tz-lock);
+
+ if (tz-ops-get_temp)
+ ret = tz-ops-get_temp(tz, temp);
we do not need to do this check, .get_temp() should always be available.
#ifdef CONFIG_THERMAL_EMUL
+ else
+ ret = -EPERM;
+
+ if (!tz-emul_temperature)
+ goto skip_emul;
+
+ for (count = 0; count tz-trips; count++) {
+ ret = tz-ops-get_trip_type(tz, count, type);
+ if (!ret type == THERMAL_TRIP_CRITICAL) {
+ ret =
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
On Mon, Jan 21, 2013 at 7:20 PM, Zhang Rui wrote: > On Wed, 2013-01-16 at 11:30 -0800, amit kachhap wrote: >> Hi Rui, >> >> Thanks for the review comments, >> On Tue, Jan 15, 2013 at 11:33 PM, Zhang Rui wrote: >> > Hi, Amit, >> > >> > On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote: >> >> This patch adds support to set the emulated temperature method in >> >> thermal zone (sensor). After setting this feature thermal zone must >> >> report this temperature and not the actual temperature. The actual >> >> implementation of this emulated temperature is based on sensor >> >> capability or platform specific. This is useful in debugging different >> >> temperature threshold and its associated cooling action. Writing 0 on >> >> this node should disable emulation. >> > >> > Question: >> > will this bring hardware issue? Say, critical temperature reached while >> > in emulation mode? >> No emulation does cause any h/w issue. >> > >> > As this is for debug purpose, I'd prefer to have a seperate Kconfig >> > option for this feature. >> Yes agreed. Will re-submit with kconfig option. >> > >> >> Signed-off-by: Amit Daniel Kachhap >> >> --- >> >> Documentation/thermal/sysfs-api.txt | 14 ++ >> >> drivers/thermal/thermal_sys.c | 26 ++ >> >> include/linux/thermal.h |1 + >> >> 3 files changed, 41 insertions(+), 0 deletions(-) >> >> >> >> diff --git a/Documentation/thermal/sysfs-api.txt >> >> b/Documentation/thermal/sysfs-api.txt >> >> index 88c0233..e8f2ee4 100644 >> >> --- a/Documentation/thermal/sysfs-api.txt >> >> +++ b/Documentation/thermal/sysfs-api.txt >> >> @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices. >> >> .get_trip_type: get the type of certain trip point. >> >> .get_trip_temp: get the temperature above which the certain trip >> >> point >> >> will be fired. >> >> + .set_emul_temp: set the emulation temperature which helps in >> >> debugging >> >> + different threshold temperature points. >> >> >> >> 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz) >> >> >> >> @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's >> >> registered: >> >> |---trip_point_[0-*]_temp: Trip point temperature >> >> |---trip_point_[0-*]_type: Trip point type >> >> |---trip_point_[0-*]_hyst: Hysteresis value for this trip point >> >> +|---emul_temp: Emulated temperature set node >> >> >> >> Thermal cooling device sys I/F, created once it's registered: >> >> /sys/class/thermal/cooling_device[0-*]: >> >> @@ -252,6 +255,17 @@ passive >> >> Valid values: 0 (disabled) or greater than 1000 >> >> RW, Optional >> >> >> >> +emul_temp >> >> + Interface to set the emulated temperature method in thermal zone >> >> + (sensor). After setting this feature thermal zone must report >> >> + this temperature and not the actual temperature. The actual >> >> + implementation of this emulated temperature is platform specific. >> > >> > can we have a pure software temperature emulation method? >> > say, the generic thermal layer caches the emulated temperature value, >> > and hook it in update_temperature()? >> > This is also useful for testing in polling mode, and it does not require >> > platform specific callback support. I mean thermal_ops->set_emul_temp is >> > optional, but thermal emulation is always available for all platforms. >> Yes It makes sense and we can have pure software emulation and use the >> cached temperature when no platform call is registered. In my case I >> needed this in h/w so to have the same sensor trigger interrupts >> behaviour. >> >> So the code flow can be like this, >> >> #ifdef CONFIG_THERMAL_EMULATION >> if (thermal_ops->set_emul_temp) >> then pass emul_temp to platform and use the normal platform >> thermal_ops->get_temp >> else >> Store it locally and use emul_temp instead of calling platform >> thermal_ops->get_temp >> #endif >> > No. > We should not support emulation is
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
On Mon, Jan 21, 2013 at 7:20 PM, Zhang Rui rui.zh...@intel.com wrote: On Wed, 2013-01-16 at 11:30 -0800, amit kachhap wrote: Hi Rui, Thanks for the review comments, On Tue, Jan 15, 2013 at 11:33 PM, Zhang Rui rui.zh...@intel.com wrote: Hi, Amit, On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote: This patch adds support to set the emulated temperature method in thermal zone (sensor). After setting this feature thermal zone must report this temperature and not the actual temperature. The actual implementation of this emulated temperature is based on sensor capability or platform specific. This is useful in debugging different temperature threshold and its associated cooling action. Writing 0 on this node should disable emulation. Question: will this bring hardware issue? Say, critical temperature reached while in emulation mode? No emulation does cause any h/w issue. As this is for debug purpose, I'd prefer to have a seperate Kconfig option for this feature. Yes agreed. Will re-submit with kconfig option. Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/thermal/sysfs-api.txt | 14 ++ drivers/thermal/thermal_sys.c | 26 ++ include/linux/thermal.h |1 + 3 files changed, 41 insertions(+), 0 deletions(-) diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index 88c0233..e8f2ee4 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices. .get_trip_type: get the type of certain trip point. .get_trip_temp: get the temperature above which the certain trip point will be fired. + .set_emul_temp: set the emulation temperature which helps in debugging + different threshold temperature points. 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz) @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's registered: |---trip_point_[0-*]_temp: Trip point temperature |---trip_point_[0-*]_type: Trip point type |---trip_point_[0-*]_hyst: Hysteresis value for this trip point +|---emul_temp: Emulated temperature set node Thermal cooling device sys I/F, created once it's registered: /sys/class/thermal/cooling_device[0-*]: @@ -252,6 +255,17 @@ passive Valid values: 0 (disabled) or greater than 1000 RW, Optional +emul_temp + Interface to set the emulated temperature method in thermal zone + (sensor). After setting this feature thermal zone must report + this temperature and not the actual temperature. The actual + implementation of this emulated temperature is platform specific. can we have a pure software temperature emulation method? say, the generic thermal layer caches the emulated temperature value, and hook it in update_temperature()? This is also useful for testing in polling mode, and it does not require platform specific callback support. I mean thermal_ops-set_emul_temp is optional, but thermal emulation is always available for all platforms. Yes It makes sense and we can have pure software emulation and use the cached temperature when no platform call is registered. In my case I needed this in h/w so to have the same sensor trigger interrupts behaviour. So the code flow can be like this, #ifdef CONFIG_THERMAL_EMULATION if (thermal_ops-set_emul_temp) then pass emul_temp to platform and use the normal platform thermal_ops-get_temp else Store it locally and use emul_temp instead of calling platform thermal_ops-get_temp #endif No. We should not support emulation is CONFIG_THERMAL_EMULATION is cleared. And further more, for pure software emulation, we should check if the real temperature reaches critical trip point. Yes agreed. Submitted the V2 version with your suggestion. Thanks, Amit Daniel thanks, rui I will re-submit with this change. Thanks, Amit thanks, rui + This is useful in debugging different temperature threshold and its + associated cooling action. Writing 0 on this node should disable + emulation. + Unit: millidegree Celsius + WO, Optional + * * Cooling device attributes * * diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 8c8ce80..ecdfc7d 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -700,11 +700,31 @@ policy_show(struct device *dev, struct device_attribute *devattr, char *buf) return sprintf(buf, %s\n, tz-governor-name); } +static ssize_t +emul_temp_store(struct device *dev, struct device_attribute *attr, + const char *buf, size_t
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
Hi Rui,
Thanks for the review comments,
On Tue, Jan 15, 2013 at 11:33 PM, Zhang Rui wrote:
> Hi, Amit,
>
> On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote:
>> This patch adds support to set the emulated temperature method in
>> thermal zone (sensor). After setting this feature thermal zone must
>> report this temperature and not the actual temperature. The actual
>> implementation of this emulated temperature is based on sensor
>> capability or platform specific. This is useful in debugging different
>> temperature threshold and its associated cooling action. Writing 0 on
>> this node should disable emulation.
>
> Question:
> will this bring hardware issue? Say, critical temperature reached while
> in emulation mode?
No emulation does cause any h/w issue.
>
> As this is for debug purpose, I'd prefer to have a seperate Kconfig
> option for this feature.
Yes agreed. Will re-submit with kconfig option.
>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> Documentation/thermal/sysfs-api.txt | 14 ++
>> drivers/thermal/thermal_sys.c | 26 ++
>> include/linux/thermal.h |1 +
>> 3 files changed, 41 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/thermal/sysfs-api.txt
>> b/Documentation/thermal/sysfs-api.txt
>> index 88c0233..e8f2ee4 100644
>> --- a/Documentation/thermal/sysfs-api.txt
>> +++ b/Documentation/thermal/sysfs-api.txt
>> @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
>> .get_trip_type: get the type of certain trip point.
>> .get_trip_temp: get the temperature above which the certain trip point
>> will be fired.
>> + .set_emul_temp: set the emulation temperature which helps in debugging
>> + different threshold temperature points.
>>
>> 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
>>
>> @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's
>> registered:
>> |---trip_point_[0-*]_temp: Trip point temperature
>> |---trip_point_[0-*]_type: Trip point type
>> |---trip_point_[0-*]_hyst: Hysteresis value for this trip point
>> +|---emul_temp: Emulated temperature set node
>>
>> Thermal cooling device sys I/F, created once it's registered:
>> /sys/class/thermal/cooling_device[0-*]:
>> @@ -252,6 +255,17 @@ passive
>> Valid values: 0 (disabled) or greater than 1000
>> RW, Optional
>>
>> +emul_temp
>> + Interface to set the emulated temperature method in thermal zone
>> + (sensor). After setting this feature thermal zone must report
>> + this temperature and not the actual temperature. The actual
>> + implementation of this emulated temperature is platform specific.
>
> can we have a pure software temperature emulation method?
> say, the generic thermal layer caches the emulated temperature value,
> and hook it in update_temperature()?
> This is also useful for testing in polling mode, and it does not require
> platform specific callback support. I mean thermal_ops->set_emul_temp is
> optional, but thermal emulation is always available for all platforms.
Yes It makes sense and we can have pure software emulation and use the
cached temperature when no platform call is registered. In my case I
needed this in h/w so to have the same sensor trigger interrupts
behaviour.
So the code flow can be like this,
#ifdef CONFIG_THERMAL_EMULATION
if (thermal_ops->set_emul_temp)
then pass emul_temp to platform and use the normal platform
thermal_ops->get_temp
else
Store it locally and use emul_temp instead of calling platform
thermal_ops->get_temp
#endif
I will re-submit with this change.
Thanks,
Amit
>
> thanks,
> rui
>> + This is useful in debugging different temperature threshold and its
>> + associated cooling action. Writing 0 on this node should disable
>> + emulation.
>> + Unit: millidegree Celsius
>> + WO, Optional
>> +
>> *
>> * Cooling device attributes *
>> *
>> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
>> index 8c8ce80..ecdfc7d 100644
>> --- a/drivers/thermal/thermal_sys.c
>> +++ b/drivers/thermal/thermal_sys.c
>> @@ -700,11 +700,31 @@ policy_show(struct device *dev, struct
>> device_attribute *devattr, char *buf)
>> return sprintf(buf, "%s\n", tz->governor->name);
>> }
>>
>> +static ssize_t
>> +emul_temp_store(struct device *dev, struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct thermal_zone_device *tz = to_thermal_zone(dev);
>> + int ret;
>> + unsigned long temperature;
>> +
>> + if (!tz->ops->set_emul_temp)
>> + return -EPERM;
>> +
>> + if (kstrtoul(buf, 10, ))
>> + return -EINVAL;
>> +
>> + ret = tz->ops->set_emul_temp(tz, temperature);
>> +
>> + return ret ? ret : count;
>> +}
>> +
>> static
Re: [PATCH 1/2] thermal: sysfs: Add a new sysfs node emul_temp
Hi Rui,
Thanks for the review comments,
On Tue, Jan 15, 2013 at 11:33 PM, Zhang Rui rui.zh...@intel.com wrote:
Hi, Amit,
On Sun, 2013-01-06 at 16:08 -0800, Amit Daniel Kachhap wrote:
This patch adds support to set the emulated temperature method in
thermal zone (sensor). After setting this feature thermal zone must
report this temperature and not the actual temperature. The actual
implementation of this emulated temperature is based on sensor
capability or platform specific. This is useful in debugging different
temperature threshold and its associated cooling action. Writing 0 on
this node should disable emulation.
Question:
will this bring hardware issue? Say, critical temperature reached while
in emulation mode?
No emulation does cause any h/w issue.
As this is for debug purpose, I'd prefer to have a seperate Kconfig
option for this feature.
Yes agreed. Will re-submit with kconfig option.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Documentation/thermal/sysfs-api.txt | 14 ++
drivers/thermal/thermal_sys.c | 26 ++
include/linux/thermal.h |1 +
3 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index 88c0233..e8f2ee4 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
.get_trip_type: get the type of certain trip point.
.get_trip_temp: get the temperature above which the certain trip point
will be fired.
+ .set_emul_temp: set the emulation temperature which helps in debugging
+ different threshold temperature points.
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
@@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's
registered:
|---trip_point_[0-*]_temp: Trip point temperature
|---trip_point_[0-*]_type: Trip point type
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
+|---emul_temp: Emulated temperature set node
Thermal cooling device sys I/F, created once it's registered:
/sys/class/thermal/cooling_device[0-*]:
@@ -252,6 +255,17 @@ passive
Valid values: 0 (disabled) or greater than 1000
RW, Optional
+emul_temp
+ Interface to set the emulated temperature method in thermal zone
+ (sensor). After setting this feature thermal zone must report
+ this temperature and not the actual temperature. The actual
+ implementation of this emulated temperature is platform specific.
can we have a pure software temperature emulation method?
say, the generic thermal layer caches the emulated temperature value,
and hook it in update_temperature()?
This is also useful for testing in polling mode, and it does not require
platform specific callback support. I mean thermal_ops-set_emul_temp is
optional, but thermal emulation is always available for all platforms.
Yes It makes sense and we can have pure software emulation and use the
cached temperature when no platform call is registered. In my case I
needed this in h/w so to have the same sensor trigger interrupts
behaviour.
So the code flow can be like this,
#ifdef CONFIG_THERMAL_EMULATION
if (thermal_ops-set_emul_temp)
then pass emul_temp to platform and use the normal platform
thermal_ops-get_temp
else
Store it locally and use emul_temp instead of calling platform
thermal_ops-get_temp
#endif
I will re-submit with this change.
Thanks,
Amit
thanks,
rui
+ This is useful in debugging different temperature threshold and its
+ associated cooling action. Writing 0 on this node should disable
+ emulation.
+ Unit: millidegree Celsius
+ WO, Optional
+
*
* Cooling device attributes *
*
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 8c8ce80..ecdfc7d 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -700,11 +700,31 @@ policy_show(struct device *dev, struct
device_attribute *devattr, char *buf)
return sprintf(buf, %s\n, tz-governor-name);
}
+static ssize_t
+emul_temp_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct thermal_zone_device *tz = to_thermal_zone(dev);
+ int ret;
+ unsigned long temperature;
+
+ if (!tz-ops-set_emul_temp)
+ return -EPERM;
+
+ if (kstrtoul(buf, 10, temperature))
+ return -EINVAL;
+
+ ret = tz-ops-set_emul_temp(tz, temperature);
+
+ return ret ? ret : count;
+}
+
static DEVICE_ATTR(type, 0444, type_show, NULL);
static DEVICE_ATTR(temp, 0444, temp_show, NULL);
static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
static
Re: [linux-pm] [PATCH] cpufreq: exynos: Show list of available frequencies
On Tue, Jan 8, 2013 at 2:50 AM, Inderpal Singh
wrote:
> Add freq_attr attribute to show list of available frequencies.
>
> Signed-off-by: Donggeun Kim
> Signed-off-by: MyungJoo Ham
> Signed-off-by: KyungMin Park
> Signed-off-by: Inderpal Singh
> ---
> drivers/cpufreq/exynos-cpufreq.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index 7012ea8..bc1e833 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -244,13 +244,26 @@ static int exynos_cpufreq_cpu_init(struct
> cpufreq_policy *policy)
> return cpufreq_frequency_table_cpuinfo(policy,
> exynos_info->freq_table);
> }
>
> +static int exynos_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> +{
> + cpufreq_frequency_table_put_attr(policy->cpu);
> + return 0;
> +}
> +
> +static struct freq_attr *exynos_cpufreq_attr[] = {
> + _freq_attr_scaling_available_freqs,
> + NULL,
> +};
> +
This change looks fine. I guess this was posted before also but could
not go mainline.
Reviewed-by: Amit Daniel Kachhap
Thanks,
Amit Daniel
> static struct cpufreq_driver exynos_driver = {
> .flags = CPUFREQ_STICKY,
> .verify = exynos_verify_speed,
> .target = exynos_target,
> .get= exynos_getspeed,
> .init = exynos_cpufreq_cpu_init,
> + .exit = exynos_cpufreq_cpu_exit,
> .name = "exynos_cpufreq",
> + .attr = exynos_cpufreq_attr,
> #ifdef CONFIG_PM
> .suspend= exynos_cpufreq_suspend,
> .resume = exynos_cpufreq_resume,
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5 RESEND] thermal: exynos: Miscellaneous fixes to support falling threshold interrupt
Hi Joe,
Thanks for the review. Will re-post with your suggestion,
On Sun, Jan 6, 2013 at 3:55 PM, Joe Perches wrote:
> On Sun, 2013-01-06 at 15:50 -0800, Amit Daniel Kachhap wrote:
>> Below fixes are done to support falling threshold interrupt,
>> * Falling interrupt status macro corrected according to exynos5 data sheet.
>> * The get trend function modified to calculate trip temperature correctly.
>> * The clearing of interrupt status in the isr is now done after handling
>> the event that caused the interrupt.
> []
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
> []
>> @@ -373,12 +373,19 @@ static int exynos_get_temp(struct thermal_zone_device
>> *thermal,
>> static int exynos_get_trend(struct thermal_zone_device *thermal,
>> int trip, enum thermal_trend *trend)
>> {
>> - if (thermal->temperature >= trip)
>> + int ret = 0;
Yes agreed. Will modify it.
>
> Unnecessary initialization
>
>> + unsigned long trip_temp;
>> +
>> + ret = exynos_get_trip_temp(thermal, trip, _temp);
>> + if (ret < 0)
>> + return ret;
>> +
>> + if (thermal->temperature >= trip_temp)
>> *trend = THERMAL_TREND_RAISING;
>> else
>> *trend = THERMAL_TREND_DROPPING;
>
> THERMAL_TREND_STABLE ?
Only 2 trend is sufficient. It is stable for some time as the falling
threshold interrupt is some units below the trip temp.
>
>>
>> - return 0;
>> + return ret;
Ok agreed
>
> return 0 is clearer.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5 RESEND] thermal: exynos: Miscellaneous fixes to support falling threshold interrupt
Hi Joe,
Thanks for the review. Will re-post with your suggestion,
On Sun, Jan 6, 2013 at 3:55 PM, Joe Perches j...@perches.com wrote:
On Sun, 2013-01-06 at 15:50 -0800, Amit Daniel Kachhap wrote:
Below fixes are done to support falling threshold interrupt,
* Falling interrupt status macro corrected according to exynos5 data sheet.
* The get trend function modified to calculate trip temperature correctly.
* The clearing of interrupt status in the isr is now done after handling
the event that caused the interrupt.
[]
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
[]
@@ -373,12 +373,19 @@ static int exynos_get_temp(struct thermal_zone_device
*thermal,
static int exynos_get_trend(struct thermal_zone_device *thermal,
int trip, enum thermal_trend *trend)
{
- if (thermal-temperature = trip)
+ int ret = 0;
Yes agreed. Will modify it.
Unnecessary initialization
+ unsigned long trip_temp;
+
+ ret = exynos_get_trip_temp(thermal, trip, trip_temp);
+ if (ret 0)
+ return ret;
+
+ if (thermal-temperature = trip_temp)
*trend = THERMAL_TREND_RAISING;
else
*trend = THERMAL_TREND_DROPPING;
THERMAL_TREND_STABLE ?
Only 2 trend is sufficient. It is stable for some time as the falling
threshold interrupt is some units below the trip temp.
- return 0;
+ return ret;
Ok agreed
return 0 is clearer.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] cpufreq: exynos: Show list of available frequencies
On Tue, Jan 8, 2013 at 2:50 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
Add freq_attr attribute to show list of available frequencies.
Signed-off-by: Donggeun Kim dg77@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: KyungMin Park kyungmin.p...@samsung.com
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
drivers/cpufreq/exynos-cpufreq.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 7012ea8..bc1e833 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -244,13 +244,26 @@ static int exynos_cpufreq_cpu_init(struct
cpufreq_policy *policy)
return cpufreq_frequency_table_cpuinfo(policy,
exynos_info-freq_table);
}
+static int exynos_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+ cpufreq_frequency_table_put_attr(policy-cpu);
+ return 0;
+}
+
+static struct freq_attr *exynos_cpufreq_attr[] = {
+ cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
This change looks fine. I guess this was posted before also but could
not go mainline.
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
Thanks,
Amit Daniel
static struct cpufreq_driver exynos_driver = {
.flags = CPUFREQ_STICKY,
.verify = exynos_verify_speed,
.target = exynos_target,
.get= exynos_getspeed,
.init = exynos_cpufreq_cpu_init,
+ .exit = exynos_cpufreq_cpu_exit,
.name = exynos_cpufreq,
+ .attr = exynos_cpufreq_attr,
#ifdef CONFIG_PM
.suspend= exynos_cpufreq_suspend,
.resume = exynos_cpufreq_resume,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] therma: exynos: Supports thermal tripping
On 26 November 2012 07:01, Jonghwan Choi wrote:
> TMU urgently sends active-high signal (thermal trip) to PMU,
> and thermal tripping by hardware logic i.e PMU is performed.
> Thermal tripping means that PMU cut off the whole power of SoC
> by controlling external voltage regulator.
>
> Signed-off-by: Jonghwan Choi
> ---
> drivers/thermal/exynos_thermal.c | 21 +
> 1 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index 129e827..f0ce099 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -631,6 +631,12 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> goto out;
> }
> rising_threshold |= (threshold_code << 16);
> + threshold_code = temp_to_code(data,
> pdata->trigger_levels[3]);
> + if (threshold_code < 0) {
> + ret = threshold_code;
> + goto out;
> + }
> + rising_threshold |= (threshold_code << 24);
>
> writel(rising_threshold,
> data->base + EXYNOS_THD_TEMP_RISE);
> @@ -669,10 +675,14 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
>
> if (on) {
> con |= EXYNOS_TMU_CORE_ON;
> - interrupt_en = pdata->trigger_level3_en << 12 |
> - pdata->trigger_level2_en << 8 |
> + interrupt_en = pdata->trigger_level2_en << 8 |
> pdata->trigger_level1_en << 4 |
> pdata->trigger_level0_en;
> +
> + if (data->soc == SOC_ARCH_EXYNOS4210)
> + interrupt_en |= pdata->trigger_level3_en << 12;
> + else
> + con |= pdata->trigger_level3_en << 12;
> } else {
> interrupt_en = 0; /* Disable all interrupts */
> }
> @@ -770,6 +780,7 @@ static struct exynos_tmu_platform_data const
> exynos_default_tmu_data = {
> .trigger_levels[0] = 85,
> .trigger_levels[1] = 103,
> .trigger_levels[2] = 110,
> + .trigger_levels[3] = 120,
> .trigger_level0_en = 1,
> .trigger_level1_en = 1,
> .trigger_level2_en = 1,
> @@ -917,8 +928,10 @@ static int __devinit exynos_tmu_probe(struct
> platform_device *pdev)
> /* Register the sensor with thermal management interface */
> (_sensor_conf)->private_data = data;
> exynos_sensor_conf.trip_data.trip_count = pdata->trigger_level0_en +
> - pdata->trigger_level1_en + pdata->trigger_level2_en
> +
> - pdata->trigger_level3_en;
> + pdata->trigger_level1_en + pdata->trigger_level2_en;
> +
> + if (data->soc == SOC_ARCH_EXYNOS4210)
> + exynos_sensor_conf.trip_data.trip_count +=
> pdata->trigger_level3_en;
Hi Choi,
Your changes looks fine but I guess we are changing a common code. I
(Along with jonghwa3@samsung.com ) have submitted a patchset
which will simplify this and now this 4th trip point code addition for
exynos4210 will be mostly platform data addition, So let Zhang Ru
comment on my changes because this will cause merge conflict.
Thanks,
Amit D
>
> for (i = 0; i < exynos_sensor_conf.trip_data.trip_count; i++)
> exynos_sensor_conf.trip_data.trip_val[i] =
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] therma: exynos: Supports thermal tripping
On 26 November 2012 07:01, Jonghwan Choi jhbird.c...@samsung.com wrote:
TMU urgently sends active-high signal (thermal trip) to PMU,
and thermal tripping by hardware logic i.e PMU is performed.
Thermal tripping means that PMU cut off the whole power of SoC
by controlling external voltage regulator.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
drivers/thermal/exynos_thermal.c | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 129e827..f0ce099 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -631,6 +631,12 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
goto out;
}
rising_threshold |= (threshold_code 16);
+ threshold_code = temp_to_code(data,
pdata-trigger_levels[3]);
+ if (threshold_code 0) {
+ ret = threshold_code;
+ goto out;
+ }
+ rising_threshold |= (threshold_code 24);
writel(rising_threshold,
data-base + EXYNOS_THD_TEMP_RISE);
@@ -669,10 +675,14 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (on) {
con |= EXYNOS_TMU_CORE_ON;
- interrupt_en = pdata-trigger_level3_en 12 |
- pdata-trigger_level2_en 8 |
+ interrupt_en = pdata-trigger_level2_en 8 |
pdata-trigger_level1_en 4 |
pdata-trigger_level0_en;
+
+ if (data-soc == SOC_ARCH_EXYNOS4210)
+ interrupt_en |= pdata-trigger_level3_en 12;
+ else
+ con |= pdata-trigger_level3_en 12;
} else {
interrupt_en = 0; /* Disable all interrupts */
}
@@ -770,6 +780,7 @@ static struct exynos_tmu_platform_data const
exynos_default_tmu_data = {
.trigger_levels[0] = 85,
.trigger_levels[1] = 103,
.trigger_levels[2] = 110,
+ .trigger_levels[3] = 120,
.trigger_level0_en = 1,
.trigger_level1_en = 1,
.trigger_level2_en = 1,
@@ -917,8 +928,10 @@ static int __devinit exynos_tmu_probe(struct
platform_device *pdev)
/* Register the sensor with thermal management interface */
(exynos_sensor_conf)-private_data = data;
exynos_sensor_conf.trip_data.trip_count = pdata-trigger_level0_en +
- pdata-trigger_level1_en + pdata-trigger_level2_en
+
- pdata-trigger_level3_en;
+ pdata-trigger_level1_en + pdata-trigger_level2_en;
+
+ if (data-soc == SOC_ARCH_EXYNOS4210)
+ exynos_sensor_conf.trip_data.trip_count +=
pdata-trigger_level3_en;
Hi Choi,
Your changes looks fine but I guess we are changing a common code. I
(Along with jonghwa3@samsung.com ) have submitted a patchset
which will simplify this and now this 4th trip point code addition for
exynos4210 will be mostly platform data addition, So let Zhang Ru
comment on my changes because this will cause merge conflict.
Thanks,
Amit D
for (i = 0; i exynos_sensor_conf.trip_data.trip_count; i++)
exynos_sensor_conf.trip_data.trip_val[i] =
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 13:42, Zhang Rui wrote:
> On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
>> On 22 November 2012 06:52, Zhang Rui wrote:
>> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
>> >> This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
>> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
>> >> jump to the upper or lower cooling level instead of incremental increase
>> >> or decrease. This is needed for temperature sensors which support
>> >> rising/falling
>> >> threshold interrupts and polling can be totally avoided.
>> >>
>> >> Signed-off-by: Amit Daniel Kachhap
>> >> Signed-off-by: Amit Daniel Kachhap
>> >> ---
>> >> drivers/thermal/step_wise.c | 19 +++
>> >> include/linux/thermal.h |2 ++
>> >> 2 files changed, 17 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
>> >> index 1242cff..0d2d8d6 100644
>> >> --- a/drivers/thermal/step_wise.c
>> >> +++ b/drivers/thermal/step_wise.c
>> >> @@ -35,6 +35,10 @@
>> >> * state for this trip point
>> >> *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
>> >> * state for this trip point
>> >> + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
>> >> + * state for this trip point
>> >> + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
>> >> + * state for this trip point
>> >> */
>> >> static unsigned long get_target_state(struct thermal_instance *instance,
>> >> enum thermal_trend trend)
>> >> @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
>> >> thermal_instance *instance,
>> >> } else if (trend == THERMAL_TREND_DROPPING) {
>> >> cur_state = cur_state > instance->lower ?
>> >> (cur_state - 1) : instance->lower;
>> >> - }
>> >> + } else if (trend == THERMAL_TREND_RAISE_FULL)
>> >> + cur_state = instance->upper;
>> >> + else if (trend == THERMAL_TREND_DROP_FULL)
>> >> + cur_state = instance->lower;
>> >>
>> >> return cur_state;
>> >> }
>> >> @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
>> >> thermal_zone_device *tz,
>> >> }
>> >>
>> >> static void update_instance_for_dethrottle(struct thermal_zone_device
>> >> *tz,
>> >> - int trip, enum thermal_trip_type trip_type)
>> >> + int trip, enum thermal_trip_type trip_type,
>> >> + enum thermal_trend trend)
>> >> {
>> >> struct thermal_instance *instance;
>> >> struct thermal_cooling_device *cdev;
>> >> @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
>> >> thermal_zone_device *tz,
>> >> cdev = instance->cdev;
>> >> cdev->ops->get_cur_state(cdev, _state);
>> >>
>> >> - instance->target = cur_state > instance->lower ?
>> >> + if (trend == THERMAL_TREND_DROP_FULL)
>> >> + instance->target = instance->lower;
>> >> + else
>> >> + instance->target = cur_state > instance->lower ?
>> >> (cur_state - 1) : THERMAL_NO_TARGET;
>> >>
>> > what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
>> > this time?
>> >
>> Hi Rui,
>>
>> I suppose this is dethrotle routine and hence this will be called when
>> only drop in temperature happens. Also I did not used get_target_state
>> here because I thought it might cause regression in the other existing
>> thermal drivers(I am not sure) But I guess calling get_target_state is
>> the good way to know next target state and is fine if you agree.
>> Also one suggestion, 2 functions for throttle/dethrottle can be merged
>> as both look same and just get_target_state can be used in that
>> function
>>
> agree.
> patches have been refreshed, please review.
Thanks Rui, Your patches looks nice. I will re-base my patches against
your implementation and submit them shortly.
Thanks,
Amit D
>
> thanks,
> rui
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 06:52, Zhang Rui wrote:
> On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
>> This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
>> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
>> jump to the upper or lower cooling level instead of incremental increase
>> or decrease. This is needed for temperature sensors which support
>> rising/falling
>> threshold interrupts and polling can be totally avoided.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> drivers/thermal/step_wise.c | 19 +++
>> include/linux/thermal.h |2 ++
>> 2 files changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
>> index 1242cff..0d2d8d6 100644
>> --- a/drivers/thermal/step_wise.c
>> +++ b/drivers/thermal/step_wise.c
>> @@ -35,6 +35,10 @@
>> * state for this trip point
>> *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
>> * state for this trip point
>> + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
>> + * state for this trip point
>> + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
>> + * state for this trip point
>> */
>> static unsigned long get_target_state(struct thermal_instance *instance,
>> enum thermal_trend trend)
>> @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
>> thermal_instance *instance,
>> } else if (trend == THERMAL_TREND_DROPPING) {
>> cur_state = cur_state > instance->lower ?
>> (cur_state - 1) : instance->lower;
>> - }
>> + } else if (trend == THERMAL_TREND_RAISE_FULL)
>> + cur_state = instance->upper;
>> + else if (trend == THERMAL_TREND_DROP_FULL)
>> + cur_state = instance->lower;
>>
>> return cur_state;
>> }
>> @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
>> thermal_zone_device *tz,
>> }
>>
>> static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
>> - int trip, enum thermal_trip_type trip_type)
>> + int trip, enum thermal_trip_type trip_type,
>> + enum thermal_trend trend)
>> {
>> struct thermal_instance *instance;
>> struct thermal_cooling_device *cdev;
>> @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
>> thermal_zone_device *tz,
>> cdev = instance->cdev;
>> cdev->ops->get_cur_state(cdev, _state);
>>
>> - instance->target = cur_state > instance->lower ?
>> + if (trend == THERMAL_TREND_DROP_FULL)
>> + instance->target = instance->lower;
>> + else
>> + instance->target = cur_state > instance->lower ?
>> (cur_state - 1) : THERMAL_NO_TARGET;
>>
> what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
> this time?
>
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
Thanks,
Amit Daniel
> thanks,
> rui
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] therma: exynos: Supports thermal tripping
On 22 November 2012 07:48, wrote:
> Hi,
> On 2012년 11월 22일 09:43, Jonghwan Choi wrote:
>> Hi~
>>
>>
> data->base + EXYNOS_THD_TEMP_RISE);
> @@ -665,6 +672,8 @@ static void exynos_tmu_control(struct
>>> platform_device
> *pdev, bool on)
> con &= ~(EXYNOS_TMU_TRIP_MODE_MASK |
> EXYNOS_MUX_ADDR_MASK);
> con |= pdata->noise_cancel_mode <<
> EXYNOS_TMU_TRIP_MODE_SHIFT;
> con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
> + if (pdata->trigger_levels[3])
> + con |= EXYNOS_TMU_TRIP_EN;
> }
>>> Why don't you support trigger_level[3] in exynos4210 either? Even though
>>> 4210 doesn't support
>>> hardware tripping,
>>> I think it can be set in same way. I've done it in my local git with
>>> following codes.
>>>
>>
>> As follows, TRIP_EN is applied SOC_ARCH_EXYNOS(for exynos4412 & exynos5250).
>> (SOC_ARCH_EXYNOS4210 for exynos4210)
>>
>> if (data->soc == SOC_ARCH_EXYNOS) {
>> con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
>> con |= pdata->noise_cancel_mode <<
>> EXYNOS_TMU_TRIP_MODE_SHIFT;
>> con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
>> if (pdata->trigger_levels[3])
>> con |= EXYNOS_TMU_TRIP_EN;
>> }
>> And. Trigger_level3_en is not stored in INTEN(only level0~level2en)
>>
>> Especially when temperature exceeds a extremely high threshold temperature
>> denoted as THRES_LEVEL_RISE3 field of THRESHOLD_TEMP_RISE register, then
>> Exynos5250 should not be damaged by the hot temperature. In this case, TMU
>> urgently sends active-high signal (THERM_TRIP) to PMU, and thermal tripping
>> by hardware logic i.e PMU (Power Management Unit) is performed. (From TMU
>> document.)
>>
>> Trigger_leves[3] is only used for THERM_TRIP. Trigger_levels3_en doesn't
>> effect h/w tripping mode.
>> So i think trigger_levels[3] is better than trigger_level3_en.
>>
>> Thanks~~^^
>>
>
> I think you misunderstood what I purposed to. I meant that it's better to
> support 3rd trigger level
> in exynos4210 either in this modification. As you can see, there isn't
> supporting of 3rd trigger
> level for all SOCs until this moment, and now your code will do this but only
> for 4x12 and 5250.
> I know that differences between thermal trip and lower trigger level
> interrupts. However,
> To satisfy the compatibility, we have to offer same interface regardless of
> SOC's type.
> Maybe 'interface' is not proper word for this situation, anyway what I want
> to tell you is that it
> is proper way to use platform data in same way whatever SOC's type is. So,
> with my former suggestion,
> it can use 3rd thermal trigger level in both SOC group. And it will activate
> as THERMAL TRIP in
> exynos4x12,5250 and as just 3rd Trigger levels in exynos4210. I do not just
> emphasize the use of
> Trigger_level3_en, but I recommend you to support 3rd trigger level in
> exynos4210 either.
Hi Choi/Lee,
It is fine to enable 4th interrupt level in exynos4210 like exynos5
but the zone will be 3 only. I guess the other parts of code should
take care of this.
Choi,
Please change just the platform data of exynos4210 to support this.
Thanks,
Amit Daniel
>
> Thanks,
> Jonghwa.
>
>>
>>
>>> -Original Message-
>>> From: jonghwa3@samsung.com [mailto:jonghwa3@samsung.com]
>>> Sent: Wednesday, November 21, 2012 1:02 PM
>>> To: Kyungmin Park
>>> Cc: Jonghwan Choi; jonghwa3.lee; open list; Amit Daniel Kachhap; Zhang Rui;
>>> Sachin Kamat
>>> Subject: Re: [PATCH v3 2/2] therma: exynos: Supports thermal tripping
>>>
>>> Hi,
>>> On 2012년 11월 20일 10:40, Kyungmin Park wrote:
On 11/20/12, Jonghwan Choi wrote:
> TMU urgently sends active-high signal (thermal trip) to PMU,
> and thermal tripping by hardware logic i.e PMU is performed.
> Thermal tripping means that PMU cut off the whole power of SoC
> by controlling external voltage regulator.
>
> Signed-off-by: Jonghwan Choi
Ackedy-by: Kyungmin Park
> ---
> drivers/thermal/exynos_thermal.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index 129e827..569478d 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -58,6 +58,7 @@
> #define EXYNOS_TMU_CORE_ON BIT(0)
> #define EXYNOS_TMU_CORE_ON_SHIFT 0
> #define EXYNOS_TMU_CORE_ON_MASK(0x1 <<
> EXYNOS_TMU_CORE_ON_SHIFT)
> +#define EXYNOS_TMU_TRIP_EN BIT(12)
> #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
>
> /* Exynos4210 specific registers */
> @@ -631,6 +632,12 @@ static int exynos_tmu_initialize(struct
> platform_device
> *pdev)
Re: [PATCH v3 2/2] therma: exynos: Supports thermal tripping
On 22 November 2012 07:48, jonghwa3@samsung.com wrote:
Hi,
On 2012년 11월 22일 09:43, Jonghwan Choi wrote:
Hi~
data-base + EXYNOS_THD_TEMP_RISE);
@@ -665,6 +672,8 @@ static void exynos_tmu_control(struct
platform_device
*pdev, bool on)
con = ~(EXYNOS_TMU_TRIP_MODE_MASK |
EXYNOS_MUX_ADDR_MASK);
con |= pdata-noise_cancel_mode
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE EXYNOS_MUX_ADDR_SHIFT);
+ if (pdata-trigger_levels[3])
+ con |= EXYNOS_TMU_TRIP_EN;
}
Why don't you support trigger_level[3] in exynos4210 either? Even though
4210 doesn't support
hardware tripping,
I think it can be set in same way. I've done it in my local git with
following codes.
As follows, TRIP_EN is applied SOC_ARCH_EXYNOS(for exynos4412 exynos5250).
(SOC_ARCH_EXYNOS4210 for exynos4210)
if (data-soc == SOC_ARCH_EXYNOS) {
con = ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
con |= pdata-noise_cancel_mode
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE EXYNOS_MUX_ADDR_SHIFT);
if (pdata-trigger_levels[3])
con |= EXYNOS_TMU_TRIP_EN;
}
And. Trigger_level3_en is not stored in INTEN(only level0~level2en)
Especially when temperature exceeds a extremely high threshold temperature
denoted as THRES_LEVEL_RISE3 field of THRESHOLD_TEMP_RISE register, then
Exynos5250 should not be damaged by the hot temperature. In this case, TMU
urgently sends active-high signal (THERM_TRIP) to PMU, and thermal tripping
by hardware logic i.e PMU (Power Management Unit) is performed. (From TMU
document.)
Trigger_leves[3] is only used for THERM_TRIP. Trigger_levels3_en doesn't
effect h/w tripping mode.
So i think trigger_levels[3] is better than trigger_level3_en.
Thanks~~^^
I think you misunderstood what I purposed to. I meant that it's better to
support 3rd trigger level
in exynos4210 either in this modification. As you can see, there isn't
supporting of 3rd trigger
level for all SOCs until this moment, and now your code will do this but only
for 4x12 and 5250.
I know that differences between thermal trip and lower trigger level
interrupts. However,
To satisfy the compatibility, we have to offer same interface regardless of
SOC's type.
Maybe 'interface' is not proper word for this situation, anyway what I want
to tell you is that it
is proper way to use platform data in same way whatever SOC's type is. So,
with my former suggestion,
it can use 3rd thermal trigger level in both SOC group. And it will activate
as THERMAL TRIP in
exynos4x12,5250 and as just 3rd Trigger levels in exynos4210. I do not just
emphasize the use of
Trigger_level3_en, but I recommend you to support 3rd trigger level in
exynos4210 either.
Hi Choi/Lee,
It is fine to enable 4th interrupt level in exynos4210 like exynos5
but the zone will be 3 only. I guess the other parts of code should
take care of this.
Choi,
Please change just the platform data of exynos4210 to support this.
Thanks,
Amit Daniel
Thanks,
Jonghwa.
-Original Message-
From: jonghwa3@samsung.com [mailto:jonghwa3@samsung.com]
Sent: Wednesday, November 21, 2012 1:02 PM
To: Kyungmin Park
Cc: Jonghwan Choi; jonghwa3.lee; open list; Amit Daniel Kachhap; Zhang Rui;
Sachin Kamat
Subject: Re: [PATCH v3 2/2] therma: exynos: Supports thermal tripping
Hi,
On 2012년 11월 20일 10:40, Kyungmin Park wrote:
On 11/20/12, Jonghwan Choi jhbird.c...@samsung.com wrote:
TMU urgently sends active-high signal (thermal trip) to PMU,
and thermal tripping by hardware logic i.e PMU is performed.
Thermal tripping means that PMU cut off the whole power of SoC
by controlling external voltage regulator.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
Ackedy-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/thermal/exynos_thermal.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 129e827..569478d 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -58,6 +58,7 @@
#define EXYNOS_TMU_CORE_ON BIT(0)
#define EXYNOS_TMU_CORE_ON_SHIFT 0
#define EXYNOS_TMU_CORE_ON_MASK(0x1
EXYNOS_TMU_CORE_ON_SHIFT)
+#define EXYNOS_TMU_TRIP_EN BIT(12)
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
/* Exynos4210 specific registers */
@@ -631,6 +632,12 @@ static int exynos_tmu_initialize(struct
platform_device
*pdev)
goto out;
}
rising_threshold |= (threshold_code 16);
+ threshold_code = temp_to_code(data,
pdata-trigger_levels[3]);
+ if (threshold_code 0) {
+ ret =
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
Thanks,
Amit Daniel
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 13:42, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device
*tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
agree.
patches have been refreshed, please review.
Thanks Rui, Your patches looks nice. I will re-base my patches against
your implementation and submit them shortly.
Thanks,
Amit D
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] thermal: exynos: Fix wrong bit to control tmu core
On 20 November 2012 11:23, Zhang Rui wrote:
> On Tue, 2012-11-20 at 10:39 +0900, Kyungmin Park wrote:
>> On 11/20/12, Jonghwan Choi wrote:
>> > [0]bit is used to enable/disable tmu core. [1] bit is a reserved bit.
>> >
>> > Signed-off-by: Jonghwan Choi
>> Acked-by: Kyungmin Park
>
> Amit and Donggeun Kim,
>
> any comments on this patch?
>
> thanks,
> rui
Hi Riu,
This patch is according to the suggestion I made earlier and looks fine.
Acked-by: Amit Daniel Kachhap
Thanks,
Amit Daniel
>
>> > ---
>> > drivers/thermal/exynos_thermal.c | 16
>> > 1 files changed, 12 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/thermal/exynos_thermal.c
>> > b/drivers/thermal/exynos_thermal.c
>> > index 6dd29e4..129e827 100644
>> > --- a/drivers/thermal/exynos_thermal.c
>> > +++ b/drivers/thermal/exynos_thermal.c
>> > @@ -52,9 +52,12 @@
>> >
>> > #define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
>> > #define EXYNOS_TMU_GAIN_SHIFT 8
>> > +#define EXYNOS_TMU_GAIN_MASK (0xF << EXYNOS_TMU_GAIN_SHIFT)
>> > #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
>> > -#define EXYNOS_TMU_CORE_ON 3
>> > -#define EXYNOS_TMU_CORE_OFF2
>> > +#define EXYNOS_TMU_REF_VOLTAGE_MASK(0x1F <<
>> > EXYNOS_TMU_REF_VOLTAGE_SHIFT)
>> > +#define EXYNOS_TMU_CORE_ON BIT(0)
>> > +#define EXYNOS_TMU_CORE_ON_SHIFT 0
>> > +#define EXYNOS_TMU_CORE_ON_MASK(0x1 <<
>> > EXYNOS_TMU_CORE_ON_SHIFT)
>> > #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
>> >
>> > /* Exynos4210 specific registers */
>> > @@ -85,7 +88,9 @@
>> > #define EXYNOS_TMU_CLEAR_FALL_INT (0x111 << 16)
>> > #define EXYNOS_MUX_ADDR_VALUE 6
>> > #define EXYNOS_MUX_ADDR_SHIFT 20
>> > +#define EXYNOS_MUX_ADDR_MASK (0x7 << EXYNOS_MUX_ADDR_SHIFT)
>> > #define EXYNOS_TMU_TRIP_MODE_SHIFT 13
>> > +#define EXYNOS_TMU_TRIP_MODE_MASK (0x7 << EXYNOS_TMU_TRIP_MODE_SHIFT)
>> >
>> > #define EFUSE_MIN_VALUE 40
>> > #define EFUSE_MAX_VALUE 100
>> > @@ -650,10 +655,14 @@ static void exynos_tmu_control(struct platform_device
>> > *pdev, bool on)
>> > mutex_lock(>lock);
>> > clk_enable(data->clk);
>> >
>> > - con = pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
>> > + con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
>> > + con &= ~(EXYNOS_TMU_REF_VOLTAGE_MASK | EXYNOS_TMU_GAIN_MASK |
>> > + EXYNOS_TMU_CORE_ON_MASK);
>> > + con |= pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
>> > pdata->gain << EXYNOS_TMU_GAIN_SHIFT;
>> >
>> > if (data->soc == SOC_ARCH_EXYNOS) {
>> > + con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
>> > con |= pdata->noise_cancel_mode <<
>> > EXYNOS_TMU_TRIP_MODE_SHIFT;
>> > con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
>> > }
>> > @@ -665,7 +674,6 @@ static void exynos_tmu_control(struct platform_device
>> > *pdev, bool on)
>> > pdata->trigger_level1_en << 4 |
>> > pdata->trigger_level0_en;
>> > } else {
>> > - con |= EXYNOS_TMU_CORE_OFF;
>> > interrupt_en = 0; /* Disable all interrupts */
>> > }
>> > writel(interrupt_en, data->base + EXYNOS_TMU_REG_INTEN);
>> > --
>> > 1.7.4.1
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at http://www.tux.org/lkml/
>> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] thermal: exynos: Fix wrong bit to control tmu core
On 20 November 2012 11:23, Zhang Rui rui.zh...@intel.com wrote:
On Tue, 2012-11-20 at 10:39 +0900, Kyungmin Park wrote:
On 11/20/12, Jonghwan Choi jhbird.c...@samsung.com wrote:
[0]bit is used to enable/disable tmu core. [1] bit is a reserved bit.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Amit and Donggeun Kim,
any comments on this patch?
thanks,
rui
Hi Riu,
This patch is according to the suggestion I made earlier and looks fine.
Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com
Thanks,
Amit Daniel
---
drivers/thermal/exynos_thermal.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 6dd29e4..129e827 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -52,9 +52,12 @@
#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
#define EXYNOS_TMU_GAIN_SHIFT 8
+#define EXYNOS_TMU_GAIN_MASK (0xF EXYNOS_TMU_GAIN_SHIFT)
#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
-#define EXYNOS_TMU_CORE_ON 3
-#define EXYNOS_TMU_CORE_OFF2
+#define EXYNOS_TMU_REF_VOLTAGE_MASK(0x1F
EXYNOS_TMU_REF_VOLTAGE_SHIFT)
+#define EXYNOS_TMU_CORE_ON BIT(0)
+#define EXYNOS_TMU_CORE_ON_SHIFT 0
+#define EXYNOS_TMU_CORE_ON_MASK(0x1
EXYNOS_TMU_CORE_ON_SHIFT)
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
/* Exynos4210 specific registers */
@@ -85,7 +88,9 @@
#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 16)
#define EXYNOS_MUX_ADDR_VALUE 6
#define EXYNOS_MUX_ADDR_SHIFT 20
+#define EXYNOS_MUX_ADDR_MASK (0x7 EXYNOS_MUX_ADDR_SHIFT)
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
+#define EXYNOS_TMU_TRIP_MODE_MASK (0x7 EXYNOS_TMU_TRIP_MODE_SHIFT)
#define EFUSE_MIN_VALUE 40
#define EFUSE_MAX_VALUE 100
@@ -650,10 +655,14 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
mutex_lock(data-lock);
clk_enable(data-clk);
- con = pdata-reference_voltage EXYNOS_TMU_REF_VOLTAGE_SHIFT |
+ con = readl(data-base + EXYNOS_TMU_REG_CONTROL);
+ con = ~(EXYNOS_TMU_REF_VOLTAGE_MASK | EXYNOS_TMU_GAIN_MASK |
+ EXYNOS_TMU_CORE_ON_MASK);
+ con |= pdata-reference_voltage EXYNOS_TMU_REF_VOLTAGE_SHIFT |
pdata-gain EXYNOS_TMU_GAIN_SHIFT;
if (data-soc == SOC_ARCH_EXYNOS) {
+ con = ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
con |= pdata-noise_cancel_mode
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE EXYNOS_MUX_ADDR_SHIFT);
}
@@ -665,7 +674,6 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
pdata-trigger_level1_en 4 |
pdata-trigger_level0_en;
} else {
- con |= EXYNOS_TMU_CORE_OFF;
interrupt_en = 0; /* Disable all interrupts */
}
writel(interrupt_en, data-base + EXYNOS_TMU_REG_INTEN);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 9 November 2012 09:21, Zhang Rui wrote:
> On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
>> On 8 November 2012 11:31, Zhang Rui wrote:
>> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
>> >> This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
>> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
>> >> jump to the upper or lower cooling level instead of incremental increase
>> >> or decrease.
>> >
>> > IMO, what we need is a new more aggressive cooling governor which always
>> > uses upper limit when the temperature is raising and lower limit when
>> > the temperature is dropping.
>> Yes I agree that a new aggressive governor is the best approach but
>> then i thought adding a new trend type is a simple solution to achieve
>> this and since most of the governor logic might be same as the
>> step-wise governor. I have no objection in doing it through governor.
>> >
> hmmm,
> I think a more proper way is to set the cooling state to upper limit
> when it overheats and reduce the cooling state step by step when the
> temperature drops.
No actually I was thinking of having a simple governor with a feature
like it only sets to upper level and lower level. Also since the
temperature sensor is capable of interrupting for both increase in
threshold(say 100C) and fall in threshold (say 90C), so polling or
step increments is not needed at all.
Currently stepwise governor governor does that so we might change the
macro name as,
THERMAL_TREND_RAISE_STEP,
THERMAL_TREND_DROP_STEP,
THERMAL_TREND_RAISE_MAX,
THERMAL_TREND_DROP_MAX,
and file step_wise.c can be named as state_wise.c or trend_wise.c.
I am not sure if it is the best way . How do you feel ?
> what do you think?
>
> thanks,
> rui
>
>> > I can write such a governor if you do not have time to.
>> ok. thanks
>> >
>> > thanks,
>> > rui
>> >> This is needed for temperature sensors which support rising/falling
>> >> threshold interrupts and polling can be totally avoided.
>> >>
>> >
>> >
>> >> Signed-off-by: Amit Daniel Kachhap
>> >> Signed-off-by: Amit Daniel Kachhap
>> >> ---
>> >> drivers/thermal/step_wise.c | 19 +++
>> >> include/linux/thermal.h |2 ++
>> >> 2 files changed, 17 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
>> >> index 1242cff..0d2d8d6 100644
>> >> --- a/drivers/thermal/step_wise.c
>> >> +++ b/drivers/thermal/step_wise.c
>> >> @@ -35,6 +35,10 @@
>> >> * state for this trip point
>> >> *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
>> >> * state for this trip point
>> >> + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
>> >> + * state for this trip point
>> >> + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
>> >> + * state for this trip point
>> >> */
>> >> static unsigned long get_target_state(struct thermal_instance *instance,
>> >> enum thermal_trend trend)
>> >> @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
>> >> thermal_instance *instance,
>> >> } else if (trend == THERMAL_TREND_DROPPING) {
>> >> cur_state = cur_state > instance->lower ?
>> >> (cur_state - 1) : instance->lower;
>> >> - }
>> >> + } else if (trend == THERMAL_TREND_RAISE_FULL)
>> >> + cur_state = instance->upper;
>> >> + else if (trend == THERMAL_TREND_DROP_FULL)
>> >> + cur_state = instance->lower;
>> >>
>> >> return cur_state;
>> >> }
>> >> @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
>> >> thermal_zone_device *tz,
>> >> }
>> >>
>> >> static void update_instance_for_dethrottle(struct thermal_zone_device
>> >> *tz,
>> >> - int trip, enum thermal_trip_type trip_type)
>> >> + int trip, enum thermal_trip_type trip_type,
>> >> + enum thermal_trend trend)
>> >> {
>> >> struct thermal_instance *instance;
>> >> struct
Re: [PATCH v2 1/2] thermal: exynos: Fix wrong bit to control tmu core
Hi
On 31 October 2012 12:17, Jonghwan Choi wrote:
> [0]bit is used to enable/disable tmu core. [1] bit is a reserved bit.
>
> Signed-off-by: Jonghwan Choi
> ---
> drivers/thermal/exynos_thermal.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index fd03e85..6ce6667 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -53,8 +53,8 @@
> #define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
> #define EXYNOS_TMU_GAIN_SHIFT 8
> #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
> -#define EXYNOS_TMU_CORE_ON 3
> -#define EXYNOS_TMU_CORE_OFF2
> +#define EXYNOS_TMU_CORE_ON 1
> +#define EXYNOS_TMU_CORE_OFF0
Hi Jonghwan,
Only this much change is not sufficient. Also you need to do like below,
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index eebd4e5..4575144 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -52,9 +52,11 @@
#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
#define EXYNOS_TMU_GAIN_SHIFT 8
+#define EXYNOS_TMU_GAIN_MASK (0xF << 8)
#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
-#define EXYNOS_TMU_CORE_ON 3
-#define EXYNOS_TMU_CORE_OFF2
+#define EXYNOS_TMU_REF_VOLTAGE_MASK(0x1F << 24)
+#define EXYNOS_TMU_CORE_ON 1
+#define EXYNOS_TMU_CORE_OFF0
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
/* Exynos4210 specific registers */
@@ -85,7 +87,9 @@
#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 << 16)
#define EXYNOS_MUX_ADDR_VALUE 6
#define EXYNOS_MUX_ADDR_SHIFT 20
+#define EXYNOS_MUX_ADDR_MASK (0xFF << 16)
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
+#define EXYNOS_TMU_TRIP_MODE_MASK (0x7 << 13)
#define EFUSE_MIN_VALUE 40
#define EFUSE_MAX_VALUE 100
@@ -658,10 +662,13 @@ static void exynos_tmu_control(struct
platform_device *pdev, bool on)
mutex_lock(>lock);
clk_enable(data->clk);
- con = pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
+ con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
+ con &= ~(EXYNOS_TMU_REF_VOLTAGE_MASK | EXYNOS_TMU_GAIN_MASK);
+ con |= pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
pdata->gain << EXYNOS_TMU_GAIN_SHIFT;
if (data->soc == SOC_ARCH_EXYNOS) {
+ con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
con |= pdata->noise_cancel_mode << EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
}
Thanks,
Amit Daniel
> #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
>
> /* Exynos4210 specific registers */
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] therma: exynos: Supports thermal tripping
On 31 October 2012 12:17, Jonghwan Choi wrote:
> TMU urgently sends active-high signal (thermal trip) to PMU,
> and thermal tripping by hardware logic i.e PMU is performed.
> Thermal tripping means that PMU cut off the whole power of SoC
> by controlling external voltage regulator.
>
> Signed-off-by: Jonghwan Choi
> ---
> drivers/thermal/exynos_thermal.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index 6ce6667..5672e95 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -53,6 +53,7 @@
> #define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
> #define EXYNOS_TMU_GAIN_SHIFT 8
> #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
> +#define EXYNOS_TMU_TRIP_EN BIT(12)
> #define EXYNOS_TMU_CORE_ON 1
> #define EXYNOS_TMU_CORE_OFF0
> #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
> @@ -656,6 +657,9 @@ static void exynos_tmu_control(struct platform_device
> *pdev, bool on)
> if (data->soc == SOC_ARCH_EXYNOS) {
> con |= pdata->noise_cancel_mode <<
> EXYNOS_TMU_TRIP_MODE_SHIFT;
> con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
> +
> + if (pdata->trigger_level3_en)
> + con |= EXYNOS_TMU_TRIP_EN;
Hi Jonghwan Choi,
IMO, Also you need to write 4th trigger level, Currently only 3
trigger levels are stored in register THD_TEMP_RISE.
Thanks,
Amit Daniel
> }
>
> if (on) {
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] Thermal: exynos: Add sysfs node supporting exynos's emulation mode.
Hi Jonghwa Lee, I tested this patch and it looks good. I have some minor comments below, Reviewed-by: Amit Daniel Kachhap Thanks, Amit Daniel On 2 November 2012 07:54, Jonghwa Lee wrote: > This patch supports exynos's emulation mode with newly created sysfs node. > Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal > management unit. Thermal emulation mode supports software debug for TMU's > operation. User can set temperature manually with software code and TMU > will read current temperature from user value not from sensor's value. > This patch includes also documentary placed under Documentation/thermal/. > > Signed-off-by: Jonghwa Lee > --- > v4 > - Fix Typo. > - Remove unnecessary codes. > - Add comments about feature of exynos emulation operation to the document. > > v3 > - Remove unnecessay variables. > - Do some code clean in exynos_tmu_emulation_store(). > - Make wrapping function of sysfs node creation function to use >#ifdefs in minimum. > > v2 > exynos_thermal.c > - Fix build error occured by wrong emulation control register name. > - Remove exynos5410 dependent codes. > exynos_thermal_emulation > - Align indentation. > > Documentation/thermal/exynos_thermal_emulation | 56 +++ > drivers/thermal/Kconfig|9 +++ > drivers/thermal/exynos_thermal.c | 91 > > 3 files changed, 156 insertions(+), 0 deletions(-) > create mode 100644 Documentation/thermal/exynos_thermal_emulation > > diff --git a/Documentation/thermal/exynos_thermal_emulation > b/Documentation/thermal/exynos_thermal_emulation > new file mode 100644 > index 000..a6ea06f > --- /dev/null > +++ b/Documentation/thermal/exynos_thermal_emulation > @@ -0,0 +1,56 @@ > +EXYNOS EMULATION MODE > + > + > +Copyright (C) 2012 Samsung Electronics > + > +Written by Jonghwa Lee > + > +Description > +--- > + > +Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal > management unit. > +Thermal emulation mode supports software debug for TMU's operation. User can > set temperature > +manually with software code and TMU will read current temperature from user > value not from > +sensor's value. > + > +Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in > available. > +When it's enabled, sysfs node will be created under > +/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'. > + > +The sysfs node, 'emulation', will contain value 0 for the initial state. > When you input any > +temperature you want to update to sysfs node, it automatically enable > emulation mode and > +current temperature will be changed into it. > +(Exynos also supports user changable delay time which would be used to delay > of > + changing temperature. However, this node only uses same delay of real > sensing time, 938us.) > + > +Exynos emulation mode requires synchronous of value changing and enabling. > It means when you > +want to update the any value of delay or next temperature, then you have to > enable emulation > +mode at the same time. (Or you have to keep the mode enabling.) If you > don't, it fails to > +change the value to updated one and just use last succeessful value > repeatedly. That's why > +this node gives users the right to change termerpature only. Just one > interface makes it more > +simply to use. > + > +Disabling emulation mode only requires writing value 0 to sysfs node. > + > + > +TEMP 120 | > + | > + 100 | > + | > +80 | > + |+--- > +60 || | > + | +-| | > +40 | | | | > + | | | | > +20 | | | +-- > + | | | | | > + 0 |__|_|__|__|_ > + A A A A TIME > + |<->| |<->| |<->| | > + | 938us | | | | | | > +emulation: 0 50 | 70 | 20 | 0 > +current temp : sensor 5070 20sensor > + > + > + > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index e1cb6bd..c02a66c 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -55,3 +55,12 @@ config EXYNOS_THERMAL > help > If you say yes here you get support for TMU (Thermal Managment > Unit) on SAMSUNG EXYNOS series of SoC. > + > +config EXYNOS_THERMAL_EMUL > + bool "EXYNOS TMU emulation mode support" > + depends on !CPU_EXYNOS4210 && EXYNOS_THERMAL Instead of using CPU_EXYNOS4210 here it is better to use data->soc
