[태그:] driver

[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/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 를 보세요.

[Android] Android 4.2 Jelly Bean(jb-mr1)

다솜돌이 Leave a comment

번외 – OEM USB 드라이버 : http://developer.android.com/tools/extras/oem-usb.html
          구글 USB 드라이버 : http://developer.android.com/sdk/win-usb.html 

[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

[Linux] Device driver 동시성 관련 함수 – Semaphore & Mutex

다솜돌이 Leave a comment

동시성 관련 함수에 대해서 다시 한번 정리하고 가자. Linux device driver 3판, 5장. “동시성과 경쟁 상태” 를 기준으로 정리한다.

공유 자원 접근을 위한 Lock 을 위해서 다음과 같은 것들을 사용한다.

1. 세마포어와 뮤텍스
Critical Section을 정의하기 위해서 세마포어를 사용한다. 일반적으로 P와 V 함수 쌍을 사용하는데, linux 에서는 P함수는 “down”, V 함수를 “up”이라 부른다. 단일 세마포어(공유 자원 개수를 1개로 정의)로 사용할 때 뮤텍스(Mutual Exclusion)라 부른다.

1.1. 세마포어 초기화
<asm/semaphore.h> 를 포함하여야 한다. 관련 Type은 struct semaphore.
1.1.1. 세마포어로 사용할 때 초기화


void sema_init(struct semaphore *sem, int val);

val 은 세마포어에 할당할 초기값.

1.1.2. Mutex로 사용할 때 초기화
정적 초기화


DECLARE_MUTEX(name); // 1로 초기화.
DECLARE_MUTEX_LOCKED(name); // 0으로 초기화.

실행 중 초기화


void init_MUTEX(struct semaphore *sem); // 1로 초기화.
void init_MUTEX_LOCKED(struct semaphore *sem); // 0으로 초기화


1.2. 세마포어 획득하기
세마포어 값을 감소시키고 필요한 만큼 기다린다.


void down(struct semaphore *sem);


세마포어 값을 감소시키고 필요한 만큼 기다리지만, 인터럽트 가능하다. 인터럽트를 받으면 0이 아닌 값을 반환하고, 세마포어를 쥐고 있지 않는다. 때문에 항상 반환값을 확인하여야 한다.


int down_interuptible(struct semaphore *sem);


세마포어를 획득할 수 없다면 바로 0이 아닌 값을 반환한다.


int down_ttylock(struct semaphore *sem);


1.3. 세마포어 반환


void up(struct semaphore *sem);

2. 읽기/쓰기 세마포어
읽기만 수행하는 스레드라면 여럿이 함께 접근해도 된다. 이럴 때 rwsem 이라는 특수 세마포어를 이용한다.
rwsem 을 사용하면 쓰기 스레드 하나가 잡고 있던가 읽기 스레드 여럿이 잡고 있던가 둘 중에 하나가 되는데 우선순위는 쓰기 스레드에게 있다. 쓰기 스레드가 임계구역에 접근하는 순간, 읽기 스레드는 모든 쓰기 스레드가 작업을 끝낼 때까지 기다려야 한다. 그래서 쓰기 스레드가 많을 경우 읽기 스레드가 오랫동안 접근 권한을 얻지 못할 수 있다. 따라서 쓰기 접근이 매우 드물고, 짧은 시간 동안에만 필요한 경우에 적당하다.

2.1. 읽기/쓰기 세마포어 초기화
<linux/resem.h> 를 포함하여야 한다. 관련 타입은 struct rw_semaphore. 런타임에 명시적으로 초기화되어야 한다.


void init_rwsem(struct rw_semaphore *sem);

2.2. 읽기 전용 세마포어 사용
읽기 전용 접근 권한을 제공한다. 다른 읽기 스레드와 동시 참조가 가능하다. 호출 프로세스를 D 상태(인터럽트가 불가능한 잠자기 상태)로 빠뜨릴 수 있다는 사실에 주의한다.


void_down_read(struct rw_semaphore *sem);

읽기를 수행할 수 없을 경우 기다리지 않는다. 접근이 가능하다면 0 이 아닌 값을, 이외에는 0을 반환한다. 다른 커널 함수는 대부분 성공일 때 0을 반환하지만 down_read_ttylock은 반대다.


int down_read_ttylock(struct rw_semaphore *sem);

읽기 전용 세마포어 해제


void up_read(struct rw_semaphore *sem);


2.2. 쓰기 전용 세마포어 사용
down_read 와 동일


void down_write(struct rw_semaphore *sem);

down_read_ttylock 과 동일


int down_write(struct rw_semaphore *sem);

up_read 와 동일


void up_write(struct rw_semaphore *sem);

잠시만 쓰기 락을 걸어 수정하고 한동안은 읽기 권한만 필요하다면


void downgrade_write(struct rw_semaphore *sem);

 

register_chrdrv()를 리눅스 커널 2.6 버전용으로 바꾸기

다솜돌이 Leave a comment

Linux Device Driver 중 Character device 의 코드를 보면 기존의 2.6 기준으로 수정되지 않은 코드들은 register_chrdrv() 함수를 사용하여 Character device를 등록하도록 되어 있다. register_chrdrv 함수의 원형은 다음과 같다.

int register_chrdev(unsigned int major, const char *name,
      const struct file_operations *fops)

그러나 2.6의 디바이스 드라이버들은 이와 다른 방식을 사용한다. register_chrdrv를 사용하는 방식은 Linux device driver 개정 3판을 보면 3장의 “예전 방식”이라는 부분에서 이를 다룬다. 예전 방식이 아닌 새로운 방식으로 작성하려면 register_chrdev 대신 register_chrdrv_region/alloc_chrdev_region 과 cdev_init, cdev_add 로 작성하면 된다.

register_chrdrv_region 함수는 원하는 디바이스의 번호를 미리 알고 있을 때 사용하고, alloc_chrdev_region 함수는 디바이스의 번호를 동적으로 할당받아 파라미터로 받는 dev_t 구조체 포인터를 이용해 dev_t 구조체에 넣는다.
register_chrdrv 대신 register_chrdrv_region을 사용하는 것으로 혼동할 수 있는데 그게 아닌 cdev_add 함수까지 사용하여야 한다. 실제 커널 소스의 register_chrdrv 함수를 보면 이런 과정이 구현되어 있음을 볼 수 있다.
cdev_add 함수를 사용하기 위해서는 struct cdev 구조체를 사용하여야 하는데 이 구조체를 초기화 시켜주는 함수가 cdev_init 이다. struct cdev 구조체 등을 사용하려면 <linux/cdev.h> 를 include하여야 한다. 다음은 사용 예이다.

#include <linux/kernel.h>
#include <linux/cdev.h>
#include <linux/fs.h>

…

struct file_operations dasom_fops;


static struct cdev dasom_cdev = {
    .owner = THIS_MODULE,
    .ops = &dasom_fops,

};


int _init dasom_init(void)
{
    dev_t dev;
    int err = 0;


    if(major) {
        dev = MKDEV(major, minor);
        err = register_chrdev_region(dev, 1, “dasomoli”);
    } else {
        err = alloc_chrdev_region(&dev, mior, 1, “dasomoli”);
        major = MAJOR(dev); 
    }
    if(err < 0) {
        err = -ENODEV;
        return err;
    }

    …
   
    cdev_init(&dasom_cdev, &dasom_fops);
    dasom_cdev.owner = THIS_MODULE;
    dasom_cdev.ops  = &dasom_fops;


    if(cdev_add(&dasom_cdev, dev, 1)) {
        printk(KERN_INFO”dasom: cdev creation failed.\n”);
        err = -ENODEV;
        goto error_label;
    }
   
    …
   
    return 0;
   
error_label:
    return err;
}