: Hitachi TX09D70VM1CDA TFT LCD framebuffer driver
PATCH 1/1 : Hitachi TX09D70VM1CDA TFT LCD framebuffer driver
From: Harald Krapfenbauer <[email protected]>
--- drivers/video/Kconfig | 36 ++ drivers/video/Makefile | 1 + drivers/video/hitachi-tx09.c | 794 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 831 insertions(+), 0 deletions(-) create mode 100644 drivers/video/hitachi-tx09.c
drivers/video/Kconfig +36 -0
@@ -600,6 +600,42 @@ config FB_BFIN_T350MCQB It uses PPI[0..7] PPI_FS1, PPI_FS2 and PPI_CLK. +config FB_HITACHI_TX09 + tristate "Hitachi TX09D70VM1CDA TFT LCD" + depends on FB && (BF537 || BF561) + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + help + This is the framebuffer device for a HITACHI TX09D70VM1CDA + TFT LCD attached to a CM-BF537E or CM-BF561 from Bluetechnix. + + To compile this driver as a module, choose M here: the + module will be called hitachi-tx09. + +config FB_HITACHI_TX09_LANDSCAPE + bool "Use Landscape 320x240 instead of Portrait 240x320" + depends on FB_HITACHI_TX09 + default n + help + Use 320x240 instead of native 240x320 Resolution + +config FB_HITACHI_TX09_REFRESHRATE + int "Refresh rate" + depends on FB_HITACHI_TX09 + range 25 70 + default 52 + help + Refresh rate of the LCD in Hz. According to data sheet, must + be in the interval [52...68]. + +config CONFIG_FB_HITACHI_TX09_CURSOR + bool "Enable/Disable cursor" + depends on FB_HITACHI_TX09 + default n + help + Enable the cursor + config FB_STI tristate "HP STI frame buffer device support" depends on FB && PARISC
drivers/video/Makefile +1 -0
@@ -117,6 +117,7 @@ obj-$(CONFIG_FB_SM501) += sm501fb.o obj-$(CONFIG_FB_XILINX) += xilinxfb.o obj-$(CONFIG_FB_OMAP) += omap/ obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o +obj-$(CONFIG_FB_HITACHI_TX09) += hitachi-tx09.o # Platform or fallback drivers go here obj-$(CONFIG_FB_UVESA) += uvesafb.o
drivers/video/hitachi-tx09.c new file +794 -0
794 lines not on this page · raw message
Signature · 8 lines
1.5.5 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
drivers/video/Kconfig config FB_BFIN_T350MCQB · line 631
Quoted 9 lines · Bryan Wu
drivers/video/Kconfig +9
-0+config FB_HITACHI_TX09_REFRESHRATE + int "Refresh rate" + depends on FB_HITACHI_TX09 + range 25 70 + default 52 + help + Refresh rate of the LCD in Hz. According to data sheet, must + be in the interval [52...68]. +
25..70 != 52..68, pick one and stick with it. If there's a reason for the discrepency, then document that, too. ie, "data sheet has no relation to hardware".
Quoted 7 lines
drivers/video/hitachi-tx09.c new file +7
-0+static void stop_timers (void ) +{ +unsigned long flags; +long old_value =0 , new_value =0 ; + +local_irq_save (flags); +
[snip]
drivers/video/hitachi-tx09.c line 185
Quoted 4 lines
drivers/video/hitachi-tx09.c new file +4
-0+while (1 ) { + old_value = new_value; + new_value =BFIN_READ (TIMER_VSYNC ,COUNTER ) (); +if ((old_value - new_value) >45000 ) {
The only way to break out of here is dependent on the timer. You have no timeout in the case of the timer getting stuck.
Quoted 25 lines
drivers/video/hitachi-tx09.c new file +25
-0+static int tx09_fb_open (struct fb_info *info,int user) +{ +unsigned long flags; + +pr_debug ("%s\n" , __FUNCTION__); + +spin_lock_irqsave (&tx09_lock, flags); + tx09_open_cnt++;/* increase counter */ +spin_unlock_irqrestore (&tx09_lock, flags); + +if (tx09_open_cnt <=1 ) {/* opened the first time */ + +/* stop PPI */ +WRITE_PPI_CONTROL (0 ); +SSYNC (); + +/* configure dma stuff */ +config_dma (); + +config_ppi (); + +/* start dma */ +enable_dma (CH_PPI ); +SSYNC (); +
drivers/video/hitachi-tx09.c line 448
Quoted 10 lines
drivers/video/hitachi-tx09.c new file +10
-0+/* start PPI */ +WRITE_PPI_CONTROL (READ_PPI_CONTROL () |PORT_EN ); +SSYNC (); + +if (!t_conf_done) +config_timers (); + +start_timers (); + } +
Presumably this should be done in the probe path, rather than lazily. Though you don't bother doing any error checking, so I suppose it doesn't really matter.
Quoted 10 lines
drivers/video/hitachi-tx09.c new file +10
-0+static int tx09_fb_mmap (struct fb_info *info,struct vm_area_struct *vma) +{ +unsigned long flags; + +pr_debug ("%s\n" , __FUNCTION__); + +if (tx09_mmap) +return -1 ;/* already mmap'ed */ + +spin_lock_irqsave (&tx09_lock, flags);
drivers/video/hitachi-tx09.c line 522
Quoted 10 lines
drivers/video/hitachi-tx09.c new file +10
-0+ tx09_mmap =1 ; +spin_unlock_irqrestore (&tx09_lock, flags); + + vma->vm_start = (unsigned long )fb_buffer; + vma->vm_end = vma->vm_start +320 *240 *2 ; + vma->vm_flags |=VM_MAYSHARE |VM_SHARED ; + +return 0 ; +} +
This is equally bizarre. If you can never support more than one opener of this device, then have your open() reflect that, rather than trying to do these lame hacks in every file op.
Beyond that, the size of the VMA is reflected in info->fix.mmio_len, which the generic fb_mmap() takes care of for you. Other than the questionable VMA flags, it's not obvious why you rolled your own mmap.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone