[태그:] Kernel

[Linux:Kernel] 지연시간 – 다양한 커널 딜레이(delay) / 슬립(sleep) 메카니즘의 정보

다솜돌이 1 Comment
이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/timers/timers-howto.txt

번역: 양정석(dasomoli@gmailREMOVETHIS.com)

지연시간 – 다양한 커널 딜레이(delay) / 슬립(sleep) 메카니즘의 정보

——————————————————————
이 문서는 공통적인 질문에 대해 답변하려고 합니다: “무엇이 지연 시간을
추가하는 옳은 방법(RightWay (TM)) 인가?”
이 질문은 하드웨어 지연 시간을 처리해야만 하지만, 커널의 내부
동작과는 거의 직접적으로 관련이 없을 드라이버 작성자들에 의해서
거의 제기됩니다.
딜레이 추가하기
—————
먼저, 가장 중요한, 여러분에게 물을 필요가 있는 질문은 “내 코드가
어토믹 컨텍스트(atomic context) 안에 있는가?” 입니다. 이것은 “정말로
어토믹 컨텍스트 안의 딜레이가 필요한가”라는 질문이 따라 붙어야 합니다.
만약 그렇다면…
어토믹 컨텍스트:
여러분은 *delay 계열의 함수를 사용해야만 합니다. 이들 함수는
클럭 속도의 지피(jiffie) 추정하기를 사용하고, 원하는 지연
시간을 채우기 위해서 충분한 루프 사이클을 바쁘게 대기(busy
wait)할 것입니다:
ndelay(unsigned long nsecs)
udelay(unsigned long usecs)
mdelay(unsigned long msecs)
udelay 는 일반적으로 선호되는 API 입니다; ndelay-레벨
정밀도는 많은 PC가 아닌(non-PC) 기기들에서 실제로 존재하지
않을 것입니다.
mdelay 는 udelay에 큰 인자를 주었을 때 가능한 오버 플로우
(overflow)를 세는, 돌고 도는 udelay의 매크로입니다.
일반적으로, mdelay의 사용은 권장되지 않고, 코드는 msleep를
사용할 수 있도록 리팩토링되는 것이 좋습니다.
어토믹이 아닌(NON-ATOMIC) 컨텍스트:
여러분은 *sleep[_range] 계열의 함수를 사용하는 것이 좋습니다.
여기에 몇가지 더 많은 옵션이 있습니다. 여기 있는 어떤 것들도
정확히 동작할 것이긴 하지만, “알맞은” 슬립 함수를 사용하는 것은
스케줄러와 전력 관리를 돕고, 여러분의 드라이버를 더 좋게
만들어줄 것입니다. 🙂
— 바쁜 대기(busy-wait)루프로 뒷받침:
udelay(unsigned long usecs)
— hrtimers로 뒷받침:
usleep_range(unsigned long min, unsigned long max)
— 지피 / 기존 타이머(legacy timer)로 뒷받침:
msleep(unsigned long msecs)
msleep_interruptible(unsigned long msecs)
*dealy 계열과 다르게, 이들 각각의 호출을 수행하는 바닥에 깔린
메카니즘이 다양하기 때문에 여러분이 알고 있어야 할 특성이 있습니다.
적은 USECS ( < ~10us? ) 를 위한 슬립:
* udelay를 사용하세요.
– usleep은 왜 아닌가요?
느린 시스템에서, (임베디드, 또는 아마도 스피드-스텝
PC!) usleep 을 위해서 hrtimers를 셋팅하는 오버헤드
(overhead)가 *아마* 그만큼 가치가 없을 것입니다. 앞과
같은 측정은 명확히 여러분의 재원적 사항에 달려 있습니다만,
알아둘 만 한 것은 아닙니다.
~USECS 나 작은 MSECS ( 10us – 20ms ) 를 위한 슬립:
* usleep_range를 사용하세요.
– (1ms – 20ms)를 위한 msleep은 왜 아닌가요?
원래는 여기서 설명했습니다:
http://lkml.org/lkml/2007/8/3/250
msleep(1~20) 은 호출자가 의도한 것을 하지 않을 수 있고,
종종 더 길게(1~20ms 사이의 어떤 값에 대해서도 실제
~20 ms 슬립) 슬립할 것입니다. 많은 경우에 이것은 원하는
동작이 아닙니다.
– “usleep” 은 왜 없나요 / 좋은 범위는 무엇인가요?
usleep_range 는 hrtimers의 꼭대기에서 빌드되므로, 그
웨이크업(wakeup)은 매우 정밀할 것입니다. 그래서 간단한
usleep 함수는 거의 많은 수의 원치 않는 인터럽트를 일으킵니다.
범위의 도입으로, 스케줄러는 여러분의 웨이크업을 다른 이유로
인해 일어날 수 있는, 혹은, 최악의 경우에 여러분의
상한(upper bound)을 위한 인터럽트를 점화하는 다른
웨이크업과 합치는데 자유롭게 됩니다.
여러분이 범위를 더 넓게 할 수록, 여러분이 인터럽트를
일으키지 않을 기회가 더 커집니다; 이것은 여러분의 코드
경로에서 지연 시간/성능 상의 허락할만한 상한값과
균형을 맞추어야 합니다. 여기에서 정확한 허용값은 매우 상황에
의존적입니다. 그래서 이는 호출자에게 이유가 있는 범위를
결정하도록 남겨둡니다.
더 큰 MSEC ( 10ms+ ) 를 위한 슬립
* msleep 이나 가능하면 msleep_interruptible 을 사용하세요.
– 무슨 차이인가요?
msleep 은 현재 태스크를 TASK_UNINTERRUPTIBLE 로 셋팅하는데
반해, msleep_interruptible 은 현재 태스크를 그 슬립을
스케줄링하기 전에 TASK_INTERRUPTIBLE 로 셋팅합니다.
요약하면, 차이는 슬립이 시그널에 의해 일찍 끝날 수 있는지
입니다. 일반적으로, 여러분이 인터럽트 가능한 파생 형태가
필요하다는 것을 알기 전까지는 그냥 msleep을 사용하세요.

[WinMerge] Linux Kernel 디렉토리 비교를 위한 Filter

다솜돌이 Leave a comment

커널은 빌드하면 .cmd 같은게 나와서 디렉토리로 비교하면 저런거 때문에 더럽다.

그래서 필터에 .cmd 같은거 추가해서 쓰면 된다~

다음을 Linux.flt 같은걸로 저장해서 필터 있는데다 같이 넣어주자~

## This is a directory/file filter template for WinMerge
name: Linux
desc: for Linux kernel
## Select if filter is inclusive or exclusive
## Inclusive (loose) filter lets through all items not matching rules
## Exclusive filter lets through only items that match to rule
## include or exclude
def: include
## Filters for filenames begin with f:
## Filters for directories begin with d:
## (Inline comments begin with ” ##” and extend to the end of the line)
f: \.o$
f: \.lib$
f: \.bak$ ## backup
f: \.cmd$
d: \\cvs$ ## CVS control directory

 

[Linux:Kernel] 레귤레이터 드라이버 인터페이스

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

Documentation/power/regulator/regulator.txt

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

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

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

레귤레이터 드라이버 인터페이스는 비교적 간단하고, 레귤레이터 드라이버가

그들의 서비스들을 코어 프레임워크에 등록하도록 디자인되었습니다.

등록

====

드라이버들은 레귤레이터를 다음 호출로 등록할 수 있습니다 :-

struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
const struct regulator_config *config);

이것은 그 레귤레이터 수용능력과 동작들을 레귤레이터 코어에 등록할 것입니다.

레귤레이터들은 다음 호출로 등록을 해제할 수 있습니다 :-

void regulator_unregister(struct regulator_dev *rdev);

레귤레이터 이벤트

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

레귤레이터들은 이벤트들(예를 들면, 과열, 저전압, 기타)을 컨슈머 드라이버로

다음 호출을 통해 보낼 수 있습니다 :-

int regulator_notifier_call_chain(struct regulator_dev *rdev,
 unsigned long event, void *data);

[Linux:Kernel] 레귤레이터 머신 드라이버 인터페이스

다솜돌이 Leave a comment
이 문서의 저작권은 GPL license를 따릅니다(This document is released under the GPL license).
Documentation/power/regulator/machine.txt
번역: 양정석 <dasomoli@gmailREMOVETHIS.com>
레귤레이터 머신 드라이버 인터페이스
===================================
레귤레이터 머신 드라이버 인터페이스는 보드/머신 의존적인 초기화 코드가
레귤레이터 서브 시스템을 설정하도록 의도되었습니다.
다음 머신을 생각해봅시다 :-
  레귤레이터-1 -+-> 레귤레이터-2 –> [컨슈머 A @ 1.8 – 2.0V]
                |
                +-> [컨슈머 B @ 3.3V]
                
컨슈머 A 와 B 를 위한 드라이버는 그들의 전원 공급 제어에 따라 그에 맞는
레귤레이터에 맵핑되어야만 합니다. 이 맵핑은 각 레귤레이터를 위한
struct regulater_consumer_supply 생성에 의한 머신 초기화 코드 안에 담겨 있을
수 있습니다.
struct regulator_consumer_supply {
        const char *dev_name;   /* consumer dev_name() */
        const char *supply;     /* consumer supply – e.g. “vcc” */
};
예를 들면, 위의 머신을 위해서는
static struct regulator_consumer_supply regulator1_consumers[] = {
{
        .dev_name       = “dev_name(consumer B)”,
        .supply         = “Vcc”,
},};
static struct regulator_consumer_supply regulator2_consumers[] = {
{
        .dev    = “dev_name(consumer A”),
        .supply = “Vcc”,
},};
이 것은 레귤레이터-1을 ‘Vcc’ 공급원으로 컨슈머 B를 위해 맵핑하고,
레귤레이터-2를 ‘Vcc’ 공급원에 컨슈머 A를 위해 맵핑합니다.
각 레귤레이터 파워 도메인을 위한 제약 사항들은 바로 struct regulator_init_data를
정의함으로써 등록될 수 있습니다. 이 구조체는 또한 컨슈머를 그들의 공급
레귤레이터로 맵핑합니다 :-
static struct regulator_init_data regulator1_data = {
        .constraints = {
                .name = “Regulator-1”,
                .min_uV = 3300000,
                .max_uV = 3300000,
                .valid_modes_mask = REGULATOR_MODE_NORMAL,
        },
        .num_consumer_supplies = ARRAY_SIZE(regulator1_consumers),
        .consumer_supplies = regulator1_consumers,
};
그 name 필드는 다른 레귤레이터들을 위한 공급원들의 설정을 위해, 그리고
로그 기록과 다른 분석 출력 결과를 위한 용도를 위해서 그 보드를 실제로
설명하는 것으로 셋팅되어야 합니다. 보통 그 회로도 내의 공급 선로를 위한
이름이 좋습니다. name이 주어지지 않으면 서브 시스템이 하나를 선택할 것입니다.
레귤레이터-1은 레귤레이터-2로 전력을 공급합니다. 레귤레이터-1이 컨슈머 A가
그 공급원(레귤레이터-2)을 켤 때 켜질 수 있도록 이 관계는 그 코어에 반드시
등록되어야 합니다. 그 공급 레귤레이터는 아래의 supply_regulator 필드에 의해
셋팅됩니다:-
static struct regulator_init_data regulator2_data = {
        .supply_regulator = “Regulator-1”,
        .constraints = {
                .min_uV = 1800000,
                .max_uV = 2000000,
                .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
                .valid_modes_mask = REGULATOR_MODE_NORMAL,
        },
        .num_consumer_supplies = ARRAY_SIZE(regulator2_consumers),
        .consumer_supplies = regulator2_consumers,
};
마지막으로, 레귤레이터 디바이스들이 일반적인 관례대로 등록되어야만 합니다.
static struct platform_device regulator_devices[] = {
{
        .name = “regulator”,
        .id = DCDC_1,
        .dev = {
                .platform_data = &regulator1_data,
        },
},
{
        .name = “regulator”,
        .id = DCDC_2,
        .dev = {
                .platform_data = &regulator2_data,
        },
},
};
/* register regulator 1 device */
platform_device_register(&regulator_devices[0]);
/* register regulator 2 device */
platform_device_register(&regulator_devices[1]);

[Linux:Kernel] 레귤레이터 컨슈머 드라이버 인터페이스

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

Documentation/power/regulator/consumer.txt

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

레귤레이터 컨슈머 드라이버 인터페이스
=====================================

이 문서는 컨슈머 디바이스 드라이버를 위한 레귤레이터 인터페이스에 대해
서술하고 있습니다. 이 문서 내에 사용된 용어의 설명은 overview.txt를 봐주세요.
1. 컨슈머 레귤레이터 접근 (정적 & 동적 드라이버)
================================================

컨슈머 드라이버는 그 공급 레귤레이터를 다음 호출로 접근 할 수 있습니다 :-

regulator = regulator_get(dev, “Vcc”);

컨슈머는 그 struct device 포인터와 전원 공급자 ID를 넘깁니다. 코어는 해당하는
레귤레이터를 머신 의존적인 탐색 테이블을 뒤져서 찾습니다. 탐색이 성공하면 이
호출은 이 컨슈머에 전원을 공급하는 struct regulator의 포인터를 반환할 것입니다.

레귤레이터를 컨슈머 드라이버에서 제거하기 위해서는 다음을 호출해야 합니다 :-

regulator_put(regulator);

컨슈머들은 하나 이상의 레귤레이터에 의해 전원이 공급될 수 있습니다. 예를 들면,
아날로그와 디지털 전원 공급을 함께 받는 코덱 컨슈머 :-

digital = regulator_get(dev, “Vcc”);  /* digital core */
analog = regulator_get(dev, “Avdd”);  /* analog */

그 레귤레이터 접근 함수 regulator_get()과 regulator_put() 는 일반적으로
여러분의 디바이스 드라이버의 probe() 와 remove() 함수 안에서 각각 호출됩니다.
2. 레귤레이터 출력 켜고 끄기 (정적 & 동적 드라이버)
===================================================

컨슈머는 그 전원 공급을 다음을 통해 켤 수 있습니다:-

int regulator_enable(regulator);

알림: 그 공급자는 이미 regulator_enabled()가 호출되기 전에 켜져 있을 겁니다.
그 컨슈머가 레귤레이터를 공유하거나 그 레귤레이터가 이전에 부트로더나 커널 보드
초기화 코드에 의해서 켜져 있다만 이렇게 될 수 있습니다.

컨슈머는 다음 호출을 통해 레귤레이터가 켜져 있는지 알아볼 수 있습니다 :-

int regulator_is_enabled(regulator);

이것은 레귤레이터가 켜져 있으면, 0보다 큰 값을 반환할 것입니다.
컨슈머는 그 전원 공급이 더이상 필요없을 때 다음을 통해 끌 수 있습니다 :-

int regulator_disable(regulator);

알림: 이것은 만약 그것을 다른 컨슈머와 공유하고 있으면, 그 전원 공급을 끄지
않을 것입니다. 그 레귤레이터는 켜진 것의 참조 카운트가 0일 때만 끌 것입니다.

마지막으로, 레귤레이터는 긴급한 경우에 강제로 끌 수 있습니다 :-

int regulator_force_disable(regulator);

알림: 이것은 즉시 그리고 강제로 레귤레이터 출력을 끌 겁니다. 모든 컨슈머는
전원이 꺼질 것입니다.

3. 레귤레이터 전압 제어 & 상태(동적 드라이버)
=============================================

어떤 컨슈머 드라이버는 시스템 동작 시점에 맞게 동적으로 그들의 전압 공급을
바꾸고 싶을 수 있습니다. 예를 들면, CPUfreq 드라이버들은 전력을 아끼기 위해서
주파수와 함께 전압을 조정할 수 있고, SD 드라이버들은 해당하는 카드 전압을
선택할 필요가 있을 수 있고, 기타 등등.

컨슈머들은 그들의 전압 공급을 다음을 통해 제어할 수 있습니다 :-

int regulator_set_voltage(regulator, min_uV, max_uV);

여기서 min_uV 와 max_uV 는 최소 그리고 최대 허용가능한 마이크로 볼트 전압입니다.

알림: 이것은 레귤레이터가 켜져있거나 꺼져 있을 때, 호출될 수 있습니다. 켜져
있을 때 호출되면, 전압은 즉시 바뀔 것이고, 아니라면, 전압 설정이 바뀌고
레귤레이터가 다음에 켜질 때 전압이 물리적으로 셋팅됩니다.

설정된 레귤레이터의 출력 전압은 다음을 통해 얻을 수 있습니다 :-

int regulator_get_voltage(regulator);

알림: get_voltage() 는 레귤레이터가 켜져있건 꺼져있건 설정된 전압을 반환합니다.
그리고 레귤레이터 출력 상태를 알아내는데는 사용하지 말아야 합니다. 그러나
그 레귤레이터의 물리적 출력 전압을 알아내기 위해서 이것은 is_enabled() 와의
조합으로 사용할 수 있습니다.
4. 레귤레이터 전류 제한 제어 & 상태(동적 드라이버)
==================================================

어떤 컨슈머 드라이버는 그 공급 전류 제한을 시스템 동작 시점에 맞춰 바꿔야 할
수도 있습니다. 예를 들면, LCD 백라이트 드라이버는 다양한 백라이트 밝기에 맞게
전류 제한을 바꿀 수 있고, USB 드라이버는 전원 공급 때 500mA 로 제한하기를 원할
겁니다.

컨슈머들은 그 공급 전류 제한을 다음으로 제어할 수 있습니다 :-

int regulator_set_current_limit(regulator, min_uA, max_uA);

여기서 min_uA 와 max_uA 는 최소, 최대 허용가능한 마이크로 암페어 전류 제한입니다.

알림: 이것은 레귤레이터가 켜져 있거나 꺼져 있을 때 호출 될 수 있습니다. 만약 켜져
있을 때 호출되면, 그 전류 제한은 즉시 바뀔 것이고, 아니면, 그 전류 제한 설정이
바뀌고 다음에 켜질 때 물리적으로 전류 제한이 셋팅됩니다.

레귤레이터는 전류 제한 값을 다음으로 얻을 수 있습니다 :-

int regulator_get_current_limit(regulator);

알림: get_current_limit() 는 그 레귤레이터가 켜져 있거나 꺼져 있거나 상관없이
전류 제한값을 반환할 것입니다. 그리고 레귤레이터 전류 로드값을 알아내기 위해서는
사용되어서는 안됩니다.
5. 레귤레이터 동작 모드 제어 & 상태(동적 드라이버)
==================================================

어떤 컨슈머들은 컨슈머들의 동작 상태 변경 때 더 효율적이도록 전원 공급
레귤레이터의 동작 모드를 바꿈으로써 더 많은 시스템 전력을 절약할 수 있습니다.
예를 들면, 컨슈머 드라이버는 대기 상태이고 그 후에는 더 적은 전류를 먹습니다.

레귤레이터 동작 모드는 직접 혹은 간접적으로 변경될 수 있습니다.

간접 동작 모드 제어
——————-
컨슈머 드라이버는 그 공급 레귤레이터 동작 모드의 변경을 다음을 통해 요청할 수
있습니다 :-

int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);

이것은 코어가 레귤레이터 상의 (모든 그 컨슈머에 기초해서) 총 부하를 재계산하도록
하는 원인이 될 것이고, 그 전류 동작 부하에 가장 알맞은 동작 모드로 (필요하고
허용된다면) 변경할 것입니다.

load_uA 값은 컨슈머 데이터시트로부터 결정될 수 있습니다. 예를 들면, 대부분의
데이터시트는 특정 상태에서 최대 전류 소모량을 보여주는 표를 가집니다.

대부분의 컨슈머는 그들이 레귤레이터에 대해 모를 때 또는 그 레귤레이터가
다른 컨슈머와 공유되는지 모를 때는 간접 동작 모드 제어를 사용할 것입니다.

직접 동작 모드 제어
——————-
맞추어진 또는 강하게 결합된 드라이버들은 직접 레귤레이터 동작 모드를 그들의
동작 시점에 따라 제어하기를 원할 것입니다. 이것은 다음을 통해 모을 수
있습니다 :-

int regulator_set_mode(struct regulator *regulator, unsigned int mode);
unsigned int regulator_get_mode(struct regulator *regulator);

직접 모드는 그 레귤레이터에 대해서, 그리고 다른 컨슈머들과 공유되지 않음을
*아는* 컨슈머에 의해서만 사용될 것입니다.
6. 레귤레이터 이벤트
====================
레귤레이터들은 컨슈머들에게 외부 이벤트를 알릴 수 있습니다. 이벤트들은 컨슈머에
의해서 레귤레이터 부하 또는 실패 컨디션 하에서 수신될 수 있습니다.

컨슈머들은 다음 호출을 통해 레귤레이터 이벤트에 대한 관심을 등록할 수 있습니다 :-

int regulator_register_notifier(struct regulator *regulator,
     struct notifier_block *nb);

컨슈머들은 다음 호출을 통해 그들의 관심을 해제할 수 있습니다 :-

int regulator_unregister_notifier(struct regulator *regulator,
struct notifier_block *nb);

레귤레이터들은 그들에게 관심있어 하는 컨슈머들에게 이벤트를 보내는데 커널
노티파이어 프레임워크를 사용합니다.

[Linux:Kernel] 레귤레이터 API 디자인 노트

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

Documentation/power/regulator/design.txt

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

레귤레이터 API 디자인 노트

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

이 문서는 부분적으로 구조화된 요약, 레귤레이터 API 디자인에 영향을 준

디자인 고려점들의 개요를 제공합니다.

안전성

——

 – 레귤레이터 설정 내의 에러들은 잠재적으로 영구적인 하드웨어 손상을

   포함하는 시스템에 매우 심각한 결과를 가져올 수 있습니다.

 – 시스템의 전원 설정을 자동으로 결정하는 것은 불가능합니다 – 다른 전력

   요구사항을 가지는 같은 칩의 소프트웨어적으로 동등한 변종들과 전력

   요구사항을 가지는 일부 컴포넌트들은 소프트웨어에 보입니다.

   

  => 그 API 는 이들 변경이 이 특정 시스템 상에서 안전하게 수행될 수 있다는

     것을 알게 되기 전까지는 하드웨어 상태에 변경을 가하지 않습니다.

컨슈머 유즈 케이스

——————

 – 시스템 내의 디바이스들의 압도적인 수의 대부분은 그들의 전원을 켜고 끄는 것을

   넘는 어떤 런타임 설정을 하도록 하는 요구 사항을 갖지는 않을 겁니다.

 – 많은 시스템 내의 전원 공급자는 여러 다른 컨슈머들 사이에 공유될 겁니다.

  => 컨슈머 API는 이들 유즈 케이스가 처리되는데 매우 쉽도록, 그래서 컨슈머가

     공유된 공급원으로 별다른 추가적인 노력없이 동작하도록 구조화되어야

     합니다.

[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] Kernel 너무 일찍 죽을 때 Console Log message

다솜돌이 Leave a comment
1. __log_buf 가 kmsg log buffer. T32 attach 후 다음과 같이 dump 뜰 수 있다(__log_buf가 0xc060eaa4 일 때).

d.save.binary d:\log_ll.log 0xc060eaa4++0x200000

2. console이 Enable 되기 전에 죽는다면, Kernel hacking -> Kernel low-level debugging functions (read help!) (DEBUG_LL [=y]) 를 켜면 메시지를 볼 수 있다. 서브 메뉴의 UART 번호는 맞춰줘야 함!

[Linux Kernel] Minimum defconfig 생성 방법

다솜돌이 Leave a comment

구글의 커널을 받아보면 Full defconfig 를 생성하지 않고 최소한의 것들만 셋팅해서 사용하는데, 난 이제껏 손으로 그냥 수정해서 사용하는 줄 알았다. 알고보니 minimum defconfig 를 만드는 방법이 있었다.

make ARCH=<ARCH 이름> <이름>_defconfig
make ARCH=<ARCH 이름> savedefconfig

이렇게 하면 커널 루트에 defconfig 라는 파일로 Minimum defconfig 가 생성된다. 이를 <이름>_defconfig 로 만들면 되는 것.

몰랐네~ 몰랐어~

[Linux Kernel] 부트로더 cmdline 확장 – CONFIG_CMDLINE_EXTEND

다솜돌이 Leave a comment

CONFIG_CMDLINE_EXTEND 옵션을 켜면 CONFIG_CMDLINE 의 cmdline 뒤에 부트로더에서 넘기는 cmdline 을 덧붙인다.

ARM 의 경우 arch/arm/kernel/setup.c 에 보면 다음과 같은 것들을 볼 수 있다.

…
static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE;
…

static int __init parse_tag_cmdline(const struct tag *tag)
{
#if defined(CONFIG_CMDLINE_EXTEND)
        strlcat(default_command_line, ” “, COMMAND_LINE_SIZE);
        strlcat(default_command_line, tag->u.cmdline.cmdline,
                COMMAND_LINE_SIZE);
#elif defined(CONFIG_CMDLINE_FORCE)
        pr_warning(“Ignoring tag cmdline (using the default kernel command line)\n”);
#else
        strlcpy(default_command_line, tag->u.cmdline.cmdline,
                COMMAND_LINE_SIZE);
#endif
        return 0;
}


참고로 안드로이드의 경우, boot.img 에 쓰이는 cmdline 에 아무것도 없을 것이라고 기대된다. boot.img 안에 있는 cmdline 의 경우 fastboot -c 옵션을 통해 디버깅 목적으로 쓸 때 사용되곤 한다.

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