[태그:] sysfs

[Linux:Kernel] 리눅스 전압과 전류 레귤레이터 프레임워크

다솜돌이 Leave a comment

이 문서의 저작권은 GPL license를 따릅니다(This document is released under the GPL license).


Documentation/power/regulator/overview.txt


리눅스 전압과 전류 레귤레이터 프레임워크

========================================

이것에 관하여

=============

이 프레임워크는 전압과 전류 레귤레이터를 제어하기 위한 표준 커널 인터페이스를

제공하기 위해서 디자인 되었습니다.

그 의도는 시스템으로 하여금 전력을 절약하고 더 긴 배터리 수명을 위해 동적으로

레귤레이터의 전원 출력을 제어할 수 있도록 하는 데 있습니다. 이 것은 (전압 출력을

제어 가능한 곳에서)전압 조절 장치와 (전류 제한이 제어 가능한)전류 제어, 둘 다

적용합니다.

(C) 2008  Wolfson Microelectronics PLC.

저자: Liam Girdwood <lrg@slimlogic.co.uk>

번역: 양정석 <dasomoli@gmailREMOVETHIS.com>

용어

====

이 문서 안에서는 몇몇 용어가 사용됩니다:-

  o 레귤레이터   – 다른 디바이스로 전력을 공급하는 전자 장치.

                   어떤 것들은 그들의 출력 전압과 (또는) 전류를 제어할 수 있는

                   데 반해 대부분의 레귤레이터는 그들의 출력을 켜고 끌 수 있습니다.

                   입력 전압 -> 레귤레이터 -> 출력 전압

                   

  o PMIC         – 전력 관리 칩(Power Management IC). 한 IC는 여러개의 레귤레이터와

                   종종 다른 서브 시스템을 포함합니다.

  o 컨슈머       – 레귤레이터에 의해 전력이 공급되는 전자 장치.

                   컨슈머는 두가지 타입으로 분류할 수 있습니다:-

                   

                   정적: 컨슈머는 그 공급 전압이나 전류 제한을 바꾸지 않습니다.

                   그저 그 전원 공급을 켜거나 끄는 것만을 필요로 합니다. 그 공급

                   전압은 하드웨어, 부트로더, 펌웨어나 커널 보드 초기화 코드에

                   의해서 결정됩니다.

  o 파워 도메인  – 레귤레이터, 스위치의 출력 전원 또는 다른 파워 도메인에 의한

                   그 입력 전원이 공급되는 전자 회로.

                   

                   그 공급 레귤레이터는 스위치(들) 뒤에 있을 것입니다. 예를 들면,

                   

                   레귤레이터 -+-> 스위치-1 -+-> 스위치-2 –> [컨슈머 A]

                               |             |

                               |             +-> [컨슈머 B], [컨슈머 C]

                               |

                               +-> [컨슈머 D], [컨슈머 E]

                

                   저것은 하나의 레귤레이터와 세 개의 파워 도메인입니다:

                   

                   도메인 1: 스위치-1, 컨슈머 D와 E.

                   도메인 2: 스위치-2, 컨슈머 B와 C.

                   도메인 3: 컨슈머 A.

                   

                   그리고 이것은 “공급자들” 관계를 나타냅니다:

                   

                   도메인-1 –> 도메인-2 –> 도메인-3.

                   

                   하나의 파워 도메인은 다른 레귤레이터들에 의해 전원이 공급되는

                   레귤레이터들을 갖을 것입니다. 예를 들면,

                   

                   레귤레이터-1 -+-> 레귤레이터-2 -+-> [컨슈머 A]

                                 |

                                 +-> [컨슈머 B]

                                 

                   이 것은 우리에게 두 개의 레귤레이터와 두 개의 파워 도메인을 줍니다:

                   

                   도메인 1: 레귤레이터-2, 컨슈머 B

                   도메인 2: 컨슈머 A

                   

                   그리고 하나의 “공급자들” 관계:

                   

                   도메인-1 –> 도메인-2

  o 제약 사항    – 제약 사항은 성능과 하드웨어 보호를 위한 전원 레벨을 정의하는데

                   사용되고는 합니다. 제약 사항은 세 개의 레벨이 존재합니다:

                   

                   레귤레이터 레벨: 이것은 레귤레이터 하드웨어 동작 파라미터에

                   의해서 정의되고, 레귤레이터 데이터 시트 내에서 정해집니다.

                   예를 들면,

                   

                     – 전압 출력은 800mV -> 3500mV 범위 안 입니다.

                     – 레귤레이터 전류 출력 제한은 20mA @ 5V 아니면 10mA @10V 입니다.

                     

                   파워 도메인 레벨: 이것은 커널 레벨 보드 초기화 코드에 의해서

                   소프트웨어 내에서 정의됩니다. 그것은 파워 도메인을 특정 전원

                   범위로 제약하는데 사용되곤 합니다. 예를 들면,

                   

                     – 도메인-1 전압은 3300mV

                     – 도메인-2 전압은 1400mV -> 1600mV

                     – 도메인-3 전류 제한은 0mA -> 20mA.

                     

                   컨슈머 레벨: 이것은 컨슈머 드라이버가 동적으로 전압이나 전류 제한

                   레벨을 셋팅함에 의해서 정의됩니다.

                   

                   예를 들면, 컨슈머 백라이트 드라이버가 전류 증가를 위해 5mA 에서

                   10mA 로 LCD 광도 증가를 위해 요청을 합니다. 이 것은 다음과 같은

                   레벨을 통해 진행됩니다 :-

                   

                   컨슈머: LCD 밝기를 증가할 필요가 있다. 밝기 테이블(컨슈머 드라이버는

                   같은 레퍼런스 디바이스 상에서를 기초로 여러 다른 개인 설정을 사용하기도

                   한다) 안에서 살펴보고 다음 전류 mA 값을 요청하라.

                   

                   파워 도메인: 새로운 전류 제한이 이 도메인과 시스템 상태(예를 들면,

                   배터리 전원, USB 전원)를 위한 동작 제한들 내에 있는가

                   

                   레귤레이터 도메인: 새로운 전류 제한이 입력/출력 전압을 위한 레귤레이터

                   동작 파라미터 내에 있는가

                   

                   만약 그 레귤레이터가 모든 제약사항 테스트를 동과하면 새로운 레귤레이터

                   값이 적용됩니다.

디자인

======

프레임워크는 SoC 기반의 디바이스들을 대상으로 하고 디자인되었습니다만, SoC가

아닌 디바이스들과도 관련이 있고, 다음 네가지 인터페이스에 따라 나뉩니다:-

   1. 컨슈머 드라이버 인터페이스

      이것은 컨슈머 드라이버가 레귤레이터를 (클럭 atm으로 할 수 있는 것 같이)

      얻거나 내려 놓을 수 있고, 전류 제한, 모드, 켜고 끄기, 전압을 읽고/셋팅할

      수 있다는 것에서 커널 클럭 인터페이스와 비슷한 API 를 사용합니다. 컨슈머

      에게 그 공급 전압과 전류 제한의 완전한 제어를 허용하여야 합니다. 또한

      사용 중이 아니면 꺼져서 드라이버들이 전원 제어를 위한 레귤레이터 없이

      시스템 안에서 재사용될 수 있도록 합니다.

      

        Documentation/power/regulator/consumer.txt 를 보세요.

        

   2. 레귤레이터 드라이버 인터페이스

      이것은 레귤레이터 드라이버가 그들의 레귤레이터를 등록하고, 그 코어에

      동작을 제공할 수 있도록 합니다. 또한 레귤레이터 이벤트를 클라이언트에게

      퍼뜨리기 위한 노티파이어 호출 체인을 가집니다.

      

        Documentation/power/regulator/regulator.txt 를 보세요.

        

   3. 머신 인터페이스

      이 인터페이스는 머신 의존적인 코드를 위해서 존재하고, 각 레귤레이터를

      위한 전압/전류 도메인의 (제약사항과 함께) 생성을 가능하도록 합니다.

      버그가 있는 클라이언트 드라이버에 의한 과전압 또는 과전류에 따른

      디바이스 손상을 막는 레귤레이터 제약사항을 제공할 수 있습니다. 또한

      어떤 레귤레이터가 다른 것들에 의해 공급되는지를 나타내는 (클럭 트리와

      비슷한) 레귤레이터 트리의 생성을 하도록 합니다.

      

        Documentation/power/regulator/machine.txt 를 보세요.

        

   4. 유저스페이스 ABI.

      그 프레임워크는 또한 많은 유용한 전압/전류/동작모드 데이터를 유저스페이스에

      sysfs를 통해 드러냅니다. 이것은 디바이스 전원 소비와 상태를 들여다 보는데

      사용될 수 있습니다.

      

        Documentation/ABI/testing/sysfs-class-regulator 를 보세요.

[Linux:Kernel] Linux CPUFreq User guide

다솜돌이 Leave a comment

이 문서의 저작권은 GPL을 따릅니다.(This document is released under the GPL license.)

            리눅스(TM) 커널 안의 CPU 주파수와 전압 조정 코드
                         L i n u x    C P U F r e q
                             U S E R   G U I D E
                    Dominik Brodowski  <linux@brodo.de>
                번역 : 양정석 <dasomoli@gmailREMOVETHIS.com>
   Clock scaling allows you to change the clock speed of the CPUs on the
    fly. This is a nice method to save battery power, because the lower
            the clock speed, the less power the CPU consumes.
차례:
—–
1. 지원되는 아키텍처와 프로세서들
1.1 ARM
1.2 x86
1.3 sparc64
1.4 ppc
1.5 SuperH
1.6 Blackfin
2. “정책” / “가버너”?
2.1 정책
2.2 가버너
3. CPU cpufreq 정책과(또는) 속도를 어떻게 바꾸는지
3.1 선호되는 인터페이스: sysfs
1. 지원되는 아키텍처와 프로세서들
=================================
1.1 ARM
——-
다음의 ARM 프로세서들이 cpufreq 에 의해 지원됩니다:
ARM Integrator
ARM-SA1100
ARM-SA1110
Intel PXA
1.2 x86
——-
다음의 x86 아키텍처의 프로세서들이 cpufreq 에 의해 지원됩니다:
AMD Elan – SC400, SC410
AMD mobile K6-2+
AMD mobile K6-3+
AMD mobile Duron
AMD mobile Athlon
AMD Opteron
AMD Athlon 64
Cyrix Media GXm
Intel mobile PIII 와 확실한 칩셋 상의 Intel mobile PIII-M
Intel Pentium 4, Intel Xeon
Intel Pentium M (Centrino)
National Semiconductors Geode GX
Transmeta Crusoe
Transmeta Efficeon
VIA Cyrix 3 / C3
ACPI 2.0 호환 시스템 상의 다양한 프로세서들 [*]
[*] “ACPI 프로세서 성능 상태” 들이 ACPI<->BIOS 인터페이스로 이용
가능한 경우만.
1.3 sparc64
———–
다음의 sparc64 아키텍처의 프로세서들이 cpufreq 에 의해 지원됩니다:
UltraSPARC-III
1.4 ppc
——-
여러 “PowerBook” 과 “iBook2” 노트북들이 지원됩니다.
1.5 SuperH
———-
클럭 프레임워크를 통해 속도 반올림을 지원하는 모든 SuperH 프로세서가 
cpufreq 에 의해 지원됩니다.
1.6 Blackfin
————
다음의 Blackfin 프로세서들이 cpufreq 에 의해 지원됩니다:
BF522, BF523, BF524, BF525, BF526, BF527, Rev 0.1 또는 그 이상
BF531, BF532, BF533, Rev 0.3 또는 그 이상
BF534, BF536, BF537, Rev 0.2 또는 그 이상
BF561, Rev 0.3 또는 그 이상
BF542, BF544, BF547, BF548, BF549, Rev 0.1 또는 그 이상
2. “정책” / “가버너” ?
======================
몇몇 CPU 주파수 조정-가능 프로세서는 다양한 주파수들과 동작 전압 사이를
“실행 중에” 어떤 커널이나 사용자 간섭없이 변환합니다. 이것은 사용자가
필요로 하는 것을 해주기에 충분히 높은, 그러나 전력을 절약하기에 충분한
주파수로의 매우 빠른 변환을 보장합니다.
2.1 정책
——–
이들 시스템 상에서, 여러분이 할 수 있는 모든 것은 여러분이 더 공격적인
전력-절약을 원하는만큼 또는 더 즉각적인 처리 능력을 원하는지에 맞춰
높고 낮은 주파수 제한 사항을 선택하는 것입니다.
2.2 가버너
———-
모든 다른 cpufreq 구현 상에서, 이들 경계는 여전이 셋팅될 필요가 있습니다.
그럼 “가버너”가 반드시 선택되어야 합니다. 앞서 언급한 “가버너”는 프로세서가
어떤 속도를 경계안에서 사용할 것인지를 결정합니다. 이런 “가버너”는
“사용자공간” 가버너입니다. 이것은 사용자 – 또는 아직 구현되지 않은
사용자공간 프로그램이 그 프로세서가 어떤 지정된 속도로 실행할지를
결정하도록 할 수 있습니다.
3. CPU cpufreq 정책과(또는) 속도를 어떻게 바꾸는지
==================================================
3.1 선호되는 인터페이스: sysfs
——————————
선호되는 인터페이스는 sysfs 파일시스템 안에 위치합니다. 여러분이
/sys에 그것을 마운트하였다면, cpufreq 인터페이스는 cpu-device 디렉토리
안의 그 하위 디렉토리 “cpufreq” 에 위치합니다
(예를 들면, 첫번째 CPU를 위해 /sys/devices/system/cpu/cpu0/cpufreq).
cpuinfo_min_freq :              이 파일은 그 프로세서가 실행할 수 있는 최하
                                동작 주파수(hKz)를 보여줍니다.
cpuinfo_max_freq :              이 파일은 그 프로세서가 실행할 수 있는 최고
                                동작 주파수(kHZ)를 보여줍니다.
cpuinfo_transition_latency      이 CPU 상에서 두 주파수 사이에 변환되는데
                                걸리는 나노초 시간. 알려져 있지 않거나,
                                ondemand 가버너로 그 드라이버가 동작하지
                                않는 높은 값으로 알려지면, -1
                                (CPUFREQ_ETERNAL) 이 반환될 것입니다.
                                이 정보를 사용하는 것은 커널 가버너나
                                사용자공간 대몬을 위한 주파수의 폴링을
                                선택하는데 유용합니다. 성능 저하 상 너무
                                잦은 결과치 산출로 주파수를 변환하지 않도록
                                하세요.
                                
scaling_driver :                이 파일은 이 CPU 상의 주파수를 셋팅하는데
                                무슨 cpufreq 드라이버가 사용되는지 보여줍니다.
scaling_available_governors :   이 파일은 이 커널 안의 사용가능한 CPUfreq
                                가버너들을 보여줍니다. 여러분은 현재 활성화된
                                가버너를 볼 수 있습니다.
scaling_governor,               그리고 다른 가버너의 이름을 “echo함”으로써,
                                여러분은 이를 바꿀 수 있습니다. 어떤 가버너는
                                로딩되지 않을 것임을 알아두세요 – 그들은 오직
                                어떤 지정된 아키텍처나 프로세스들 상에서만
                                동작합니다.
cpuinfo_cur_freq :              하드웨어로부터 얻은 그 CPU의 현재 주파수(kHZ).
                                이 것은 CPU가 실제로 실행되는 주파수입니다.
scaling_available_frequencies : 사용가능한 주파수의 목록(KHz)
scaling_min_freq 와
scaling_max_freq                현재의 “정책 제한 사항”을 보여줍니다(kHz).
                                새로운 값들을 이 파일에 echo함으로써,
                                여러분은 이들 제한 사항을 바꿀 수 있습니다.
                                알림: 여러분이 필요로 하는 정책을 셋팅할 때
                                먼저 scaling_max_freq를 셋팅하고, 그 다음
                                scaling_min_freq를 셋팅하세요.
affected_cpus :                 주파수의 소프트웨어 조정이 요구되는 CPU들의 목록
related_cpus :                  소프트웨어든 하드웨어든 일련의 주파수 조정이
                                필요한 CPU들의 목록
scaling_driver :                cpufreq를 위한 하드웨어 드라이버.
scaling_cur_freq :              가버너와 cpufreq 코어에 의해 결정된 그 CPU의
                                현재 주파수(kHz). 이것은 커널이 그 CPU가
                                실행한다고 생각하는 주파수입니다.
bios_limit :                    BIOS가 OS에게 CPU를 더 낮은 주파수로 제한하라고
                                이야기한다면, 사용자는 이 파일로부터 최고
                                사용가능 주파수를 읽을 수 있습니다. 이것은
                                일반적으로 (종종 의도되지 않은) BIOS 셋팅,
                                서비스 프로세서나 다른 BIOS/HW 기준 구현에
                                의해 발생하는 제약으로부터 발생할 수 있습니다. 
                                일반적인 서멀 드라이버로부터 검출될 수 있는
                                서멀 ACPI 제약 사항들을 포함하여 다루지 않습니다.
                                
여러분이 여러분에게 CPU 동작 주파수를 지정된 값으로 셋팅할 수 있는
“userspace” 가버너를 선택했다면, 여러분은 현재 주파수를 다음에서
읽을 수 있습니다.
scaling_setspeed.               새 주파수를 여기로 “echo함”으로써,
                                여러분은 그 CPU의 속도를 바꿀 수 있습니다.
                                그러나 scaling_min_freq와 scaling_max_freq
                                안의 제약사항안에 있어야 합니다.

[Linux] scnprintf()

다솜돌이 Leave a comment

리눅스 커널은 scnprintf 라는 함수를 제공하는데, 이 함수는 snprintf의 일종이라고 볼 수 있다.
snprintf 는 C99 표준에 의해서 버퍼에 실제로 쓰여진 길이를 리턴하지 않고, 쓰여지고자 했던 길이를 리턴하도록 되어 있다. 예를 들어 다음과 같은 소스 코드가 있다면,

#include <stdio.h>

int main(void)
{
        char buffer[10] = { 0, };
        int output = 0;

        output = snprintf(buffer, sizeof(buffer), “%ld”, 1234567890123l);
        printf(“buffer: %s, output: %d\n”, buffer, output);

        return 0;
}

대부분 생각하는 출력은 아마도 “buffer: 123456789, output:9” 와 같을텐데, 이 소스 코드에 해당하는 프로그램은 다음과 같이 output으로 원래 찍으려고 했었던 수의 출력 길이인 13을 출력한다.

dasomoli@dasomoli-ubuntu:~/src/snprintf$ ./a.out
buffer: 123456789, output: 13

그래서 커널은 snprintf 말고도 scnprintf 함수를 제공한다.

요즘은 Device driver의 제어를 위해 ioctl 함수보다는 sysfs 를 이용하는 추세인데, 이를 위한 sysfs의 show 함수에서는 scnprintf를 사용하도록 하고 있다(Documentation/filesystems/sysfs.txt).

참고 : http://lwn.net/Articles/69419/

[Linux] ioctl을 대체하는 unlocked_ioctl

다솜돌이 Leave a comment

기존 device driver를 제어하기 위한 방법 중 하나였던 ioctl이 2.6.36 커널부터 unlocked_ioctl 로 대체되었다.
ioctl과 unlocked_ioctl의 차이점은 ioctl이 BKL(Big Kernel Lock)로 보호되었다면, unlocked_ioctl은 BKL이 없다. 따라서 Preemptible 하게 되었으므로, ioctl의 동시성에 대해서 driver 스스로 보호하여야 한다.
driver의 제어를 위해서 ioctl보다는 sysfs를 이용하는 방향으로 가고 있는 듯 하다(http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-May/001852.html).

compat_ioctl은 64비트 시스템에서 32비트 프로세스가 ioctl을 부를 때를 위해서 만들어졌다.

참고 : http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-May/001851.html