[태그:] Linux

[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] 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:Kernel] Linux CPUFreq Core

다솜돌이 Leave a comment

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

  리눅스(TM) 커널안의 CPU 동작속도와 전압 조절 코드 
        L i n u x    C P U F r e q
 C P U F r e q    C o r e
   Dominik Brodowski  <linux@brodo.de>
    David Kimdon <dwhedon@debian.org>
번역 : 양정석 <dasomoli@gmailREMOVETHIS.com>

   클럭 조정은 동작하고 있는 CPU의 클럭 속도를 바꿀 수 있게 합니다. 이 것은

    배터리 파워를 절약할 수 있는 좋은 방법입니다. 왜냐하면 클럭 속도가
   낮을수록 CPU가 소비하는 전력도 낮아지기 때문입니다.

    

차례:

—–

1.  CPUFreq 코어와 인터페이스

2.  CPUFreq 노티파이어(notifires)

1. 일반적인 정보

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

CPUFreq 코어 코드는 drivers/cpufreq/cpufreq.c 안에 있습니다. 이 cpufreq

코드는 CPUFreq 구조 드라이버(실제 주파수 전이를 수행하는 코드 조각)를

위한 표준화된 인터페이스, “노티파이어(notifires)”를 제공합니다. 이들은 정책 변경

(예를 들면, ACPI 같은 온도 모듈), 모든 동작 속도 변화(예를 들면,

타이밍 코드)의 알림을 필요로 하거나, 혹은 일정 속도 제한을 강제할 필요가

있는(예를 들면, ARM 아키텍처의 LCD 드라이버 같은) 디바이스 드라이버거나

혹은 커널의 다른 부분 입니다. 추가적으로, 커널 “상수” loops_per_jiffy는

여기 주파수 변경 상에서 업데이트 됩니다.

레퍼런스 카운트는 cpufreq 프로세서 드라이버가 코어와 함께 정확히

등록되었고, cpufreq_put_cpu가 호출되기 전까지 로딩되지 않을 것임을

확실하게 해주는 cpufreq_get_cpu와 cpufreq_put_cpu에 의해서 수행됩니다.

2. CPUFreq 노티파이어(notifires)

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

CPUFreq 노티파이어는 표준 커널 노티파이어 인터페이스를 따릅니다.

노티파이어에 대한 자세한 사항은 linux/include/linux/notifire.h 를

보세요.

두가지 CPUFreq 노티파이어-정책 노티파이어와 전이 노티파이어-가 있습니다.

2.1 CPUFreq 정책 노티파이어

—————————

새 정책이 셋팅되려고 할 때 이것들이 알려집니다. 각 CPUFreq 정책 노티파이어는

정책의 전이 동안 세 번 호출 됩니다:

1.) CPUFREQ_ADJUST 동안 모든 CPUFreq 노티파이어는 이를 봐야 할 필요가 있다면

   그 제한 사항-온도에 대한 고려나 하드웨어 제한 사항-을 변경할 것입니다. 

2.) CPUFREQ_INCOMPATIBLE 동안 하드웨어 실패를 피하기 위한 변경들만 수행될

   것입니다.

3.) 그리고 CPUFREQ_NOFITY 동안 모든 노티파이어들은 새 정책-만약 두 하드웨어

   드라이버가 이 단계 전에 새 정책에 대해 동의하는데 실패했다면, 그 호환될 수

   없는 하드웨어는 꺼지고 사용자에게 이를 알릴 것입니다-을 알립니다.

이들 단계는 노티파이어의 두번째 인자로 지정됩니다.

세번째 인자, void * 포인터는 다섯 개의 값으로 구성된  cpufreq_policy 구조체를

가리킵니다: cpu, min, max, policy와 max_cpu_freq. min과 max는 새 정책의 

주파수의 상한과 하한 값(kHz) 을, policy는 새 정책, cpu는 영향을 미칠 CPU의

번호, 그리고 max_cpu_freq 는 최고로 지원하는 CPU 주파수입니다. 이 값은

정보 제공 목적으로만 주어집니다.

2.2 CPUFreq 전이 노티파이어

—————————

이 것들은 CPUFreq 드라이버가 CPU 코어 주파수를 바꿀 때와 이 변경이 어떤 외부

영향을 가질 때, 두 번 알려집니다.

두번째 인자는 이들 단계-CPUFREQ_PRECHANGE나 CPUFREQ_POSTCHANGE-를 지정합니다.

세번째 인자는 다음 값들을 가지는 cpufreq_freq 구조체입니다:

cpu – 영향을 미치는 CPU 번호

old – 이전 주파수

new – 새 주파수

시스템이 suspend된 동안 cpufreq 코어가 주파수의 변경을 알아차리면,

이들 노티파이어는 두번째 인자로 CPUFREQ_RESUMECHANGE와 함께 호출됩니다.


 

[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 번호는 맞춰줘야 함!

[Samba] 공유 디렉토리 추가

다솜돌이 Leave a comment

가끔, 아니 매우 자주 공유 디렉토리 만들 일이 생긴다. 이건 사실 쓸 필요없다고 생각해서 그동안 안적어왔는데 귀찮을 때 긁는게 더 낫겠다.

/etc/samba.conf 에 다음 내용을 추가한다.

[Shared]

  comment = Shared directory

  path = /home/public

  writeable = yes

  browseable = no

  guest ok = yes

  read only = no

접근 경로는 위와 같다면 “\\<IP>\Shared” 이다.

물론 설정 후 삼바 서비스는 재시작한다.

sudo service smbd restart

[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).

[Linux Kernel] gpio_request_one

다솜돌이 Leave a comment

초기화 할 때 gpio_request 를 하고 값을 셋팅하는 걸 한방에 할 수 있는 방법!
gpio_request_one 을 쓰시라~

int gpio_request_one(unsigned gpio, unsigned long flags, const char *label);

기존의 GPIOF_ 가 다음과 같으므로

* GPIOF_DIR_IN		- to configure direction as input 
* GPIOF_DIR_OUT		- to configure direction as output


* GPIOF_INIT_LOW	- as output, set initial level to LOW
* GPIOF_INIT_HIGH	- as output, set initial level to HIGH

flags 에는 다음과 같은 값들을 쓸 수 있다. 이름을 보면 대충 뭐하는지 다 알 듯.

* GPIOF_IN		- configure as input
* GPIOF_OUT_INIT_LOW	- configured as output, initial level LOW
* GPIOF_OUT_INIT_HIGH	- configured as output, initial level HIGH

그리고 array 로 만들어서 한방에 할 수도 있다.

static struct gpio leds_gpios[] = { 
	{ 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* default to ON */
	{ 33, GPIOF_OUT_INIT_LOW,  "Green LED" }, /* default to OFF */
	{ 34, GPIOF_OUT_INIT_LOW,  "Red LED"   }, /* default to OFF */
	{ 35, GPIOF_OUT_INIT_LOW,  "Blue LED"  }, /* default to OFF */
	{ ... },
};

err = gpio_request_array(leds_gpios, ARRAY_SIZE(leds_gpios)); 
if (err)
	...

당연히 array 를 free하는 것도 있다.

gpio_free_array(leds_gpios, ARRAY_SIZE(leds_gpios))

request 할 때 맨 뒤의 label 을 만들 때 kasprintf() 를 이용하면 내부에서 kmalloc 해서 잡아준다. 런타임에 label을 정하거나 할 때 유용히 쓸 수 있다.

 char *label = kasprintf(GFP_KERNEL, “LED %d”, i);

 gpio_request_one(32, GPIOF_OUT_INIT_HIGH, label);

 …
 gpio_free(32);
 kfree(label);

이 문서의 라이센스는 GPL을 따른다(This document is released under the GPL license.)

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