도와주세요!!
글 수 15,339
2008.11.05 23:16:03 (*.34.20.202)
20242
Frame Buffer 에 관련된 application 소스에서 ioctl() 함수가 아래와 같이 인자 3개를 사용되어지고 있었습니다.
if ( ioctl( gx_fb.fd, FBIOGET_VSCREENINFO, &fbvar))
{
gx_close();
return GXERR_VSCREEN_INFO;
}
이러한 코드에서 ioctl() 함수를 사용할때 인자 3개를 전달하고 있었습니다.
저는 Frame Buffer 디바이스 드라이버 소스를 분석하기 위해
linux-2.6.21\include\linux\fb.h(622) 에서
struct fb_ops {
struct module *owner;
........
int (*fb_ioctl)(struct fb_info *info, unsigned int cmd, unsigned long arg);
........
};
로 fb_ioctl 함수 포인터변수의 인자는 총 3개의 인자로 구성되어 있습니다.
linux-2.6.21\drivers\video\fbmem.c(1259): 에서 fb_ioctl 를 아래와 같이 ioctl 에 연결하도록 설정되어 있었습니다.
static const struct file_operations fb_fops = {
.owner = THIS_MODULE,
.read = fb_read,
.write = fb_write,
.ioctl = fb_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = fb_compat_ioctl,
#endif
.mmap = fb_mmap,
.open = fb_open,
.release = fb_release,
#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
.get_unmapped_area = get_fb_unmapped_area,
#endif
};
그런데, linux-2.6.21\drivers\video\fbmem.c(868): 에서 ioctl() 함수 정의를 찾아보니깐,
static int fb_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
{
int fbidx = iminor(inode);
.........
}
보신바와 같이 인자 총 4개로 구성된 함수 정의를 찾을수 있었습니다.
Frame Buffer 에 관련된 application 소스에서 ioctl() 함수는 인자 3개를 사용되어지고 있었습니다.
저는 인자 총 3개로 구성된 fb_ioctl() 함수 정의를 커널소스에서 찾으려고 했으나, 끝내 찾지 못했습니다.
혹시 어디를 보면 인자 3개인 fb_ioctl() 함수 정의를 찾을수 있는지 알려주시면 정말 감사하겠습니다.
그리고,
linux-2.6.21\drivers\video\s3c2410fb.c 에서
platform_device 라는 개념으로 구성되어있는 것을 보았습니다.
실제 캐렉터디바이스는 정의되어 있지 않았으며, /dev/fb 를 인자로 받아서, 등록하는거 같은데,
왜 이러한 개념으로 Frame Buffer 디바이스 드라이버를 정의하는지 정말 궁금합니다. 혹시 이부분에 대해서도
알고 계시면 알려주시면 정말 감사하겠습니다.
두번째의 구조체 static const struct file_operations fb_fops 이것은 디비이스 드라이버와 어플을 연결해 주기 위한
파일오퍼레이션 구조체이구요. 이구조체가 실제 어플과 직접 연결되는 구조체입니다.
struct fb_ops 구조체는 minor 번호로 관리되는 프레임버퍼를 관리하는 구조체입니다.
대충 아래와 같은 방식일거에요
static int fb_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
{
fb_ops->fb_ioctl( arg1, arg2, arg3 );
}
하나의 시스템에는 프레임버퍼가 1개만 있는게 아닙니다. 필요에따라 여러개의 프레임버퍼를 만들수 있습니다.
그 각각을 하나의 드라이버로 관리하기 위해 마이너 번호를 이용하고 있습니다.
platform_device 라는 개념은 2.6.x 대에서 등장하기 시작하였으며 간단히 내가 사용하는 보드의 리소스를 커널에서
미리 주소나 인터럽트등을 등록하고 후에 디바이스가 올라갈때 platform 으로 부터 이런 리소스를 받아오면
디바이스 드라이버 소스상에 내 보드만을 위한 주소나 인터럽트를 어지럽게 정의하지 않아도 되는 이점이 있습니다.
커널 2.4 의 드라이버 소스를 보면 #ifdef 문으로 뒤덮인 소스를 많이 보실 수 있을겁니다.
2.6 에서는 arch/arm/mach-xxx 디렉토리에서 이런 리소스들을 등록하도록 하고 있습니다.
이런 개념이 확장되어 프렘임버퍼의 경우 단순히 메모리만이 필요한 것이 아니고 하드웨어를 초기화하기 위해
여러개의 레지스터값이 필요한데 이런 레지스터 값까지 등록하도록 되어있습니다.
동종의 MCU 라면 프레임버퍼 드라이버에서 이 레지스터값을 제어하여 프렘임버퍼 하드웨어를 초기화
할 수 있는 잇점이 있으니까요
/dev/fb 는 케릭터 이긴 하지만 register_chrdev 라는 함수로는 등록하지 않습니다.
register_framebuffer() 함수로 등록하며 이 함수 내부에 create_devcie() 함수에서 major 번호를 등록하고 있습니다.
프레임버퍼를 저도 분석하지는 않아 이이상은 힘드네요 ^^