| Submitter | chaithrika@ti.com |
|---|---|
| Date | 2009-10-16 11:05:27 |
| Message ID | <1255691127-31438-1-git-send-email-chaithrika@ti.com> |
| Download | mbox | patch |
| Permalink | /patch/54234/ |
| State | New |
| Headers | show |
Comments
Chaithrika U S <chaithrika@ti.com> writes: > The clock divider value can be calculated from the pixel clock > value for the panel. This gives more flexiblity to the driver > to change the divider value on the fly as in the case of cpufreq > feature- support for which will be added shortly. > > Signed-off-by: Chaithrika U S <chaithrika@ti.com> > --- > This patch applies on Linus' kernel tree. Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Temporarily adding to davinci git while waiting for merge to mainline. Kevin > drivers/video/da8xx-fb.c | 28 ++++++++++++++++++++-------- > 1 files changed, 20 insertions(+), 8 deletions(-) > > diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c > index d065894..d9ab839 100644 > --- a/drivers/video/da8xx-fb.c > +++ b/drivers/video/da8xx-fb.c > @@ -113,6 +113,7 @@ struct da8xx_fb_par { > unsigned short pseudo_palette[16]; > unsigned int databuf_sz; > unsigned int palette_sz; > + unsigned int pxl_clk; > }; > > /* Variable Screen Information */ > @@ -155,7 +156,7 @@ struct da8xx_panel { > int vfp; /* Vertical front porch */ > int vbp; /* Vertical back porch */ > int vsw; /* Vertical Sync Pulse Width */ > - int pxl_clk; /* Pixel clock */ > + unsigned int pxl_clk; /* Pixel clock */ > unsigned char invert_pxl_clk; /* Invert Pixel clock */ > }; > > @@ -171,7 +172,7 @@ static struct da8xx_panel known_lcd_panels[] = { > .vfp = 2, > .vbp = 2, > .vsw = 0, > - .pxl_clk = 0x10, > + .pxl_clk = 4608000, > .invert_pxl_clk = 1, > }, > /* Sharp LK043T1DG01 */ > @@ -185,7 +186,7 @@ static struct da8xx_panel known_lcd_panels[] = { > .vfp = 2, > .vbp = 2, > .vsw = 10, > - .pxl_clk = 0x12, > + .pxl_clk = 7833600, > .invert_pxl_clk = 0, > }, > }; > @@ -451,6 +452,18 @@ static void lcd_reset(struct da8xx_fb_par *par) > lcdc_write(0, LCD_RASTER_CTRL_REG); > } > > +static void lcd_calc_clk_divider(struct da8xx_fb_par *par) > +{ > + unsigned int lcd_clk, div; > + > + lcd_clk = clk_get_rate(par->lcdc_clk); > + div = lcd_clk / par->pxl_clk; > + > + /* Configure the LCD clock divisor. */ > + lcdc_write(LCD_CLK_DIVISOR(div) | > + (LCD_RASTER_MODE & 0x1), LCD_CTRL_REG); > +} > + > static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg, > struct da8xx_panel *panel) > { > @@ -459,9 +472,8 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg, > > lcd_reset(par); > > - /* Configure the LCD clock divisor. */ > - lcdc_write(LCD_CLK_DIVISOR(panel->pxl_clk) | > - (LCD_RASTER_MODE & 0x1), LCD_CTRL_REG); > + /* Calculate the divider */ > + lcd_calc_clk_divider(par); > > if (panel->invert_pxl_clk) > lcdc_write((lcdc_read(LCD_RASTER_TIMING_2_REG) | > @@ -721,6 +733,8 @@ static int __init fb_probe(struct platform_device *device) > } > > par = da8xx_fb_info->par; > + par->lcdc_clk = fb_clk; > + par->pxl_clk = lcdc_info->pxl_clk; > > if (lcd_init(par, lcd_cfg, lcdc_info) < 0) { > dev_err(&device->dev, "lcd_init failed\n"); > @@ -753,8 +767,6 @@ static int __init fb_probe(struct platform_device *device) > da8xx_fb_fix.smem_len = par->databuf_sz - par->palette_sz; > da8xx_fb_fix.line_length = (lcdc_info->width * lcd_cfg->bpp) / 8; > > - par->lcdc_clk = fb_clk; > - > par->irq = platform_get_irq(device, 0); > if (par->irq < 0) { > ret = -ENOENT; > -- > 1.5.6 > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of 10ms.. For DM6467, and other ARM Davinci linux implementations, 2.6.10 based specifically, how does one get the jiffies to 1ms, instead of what appears to be 10ms? I believe I have HIGHRES timers enabled... Anything else one needs to do to get usleep resolution 1ms instead of 10ms? Scheduler config? Regards, Randy Roberts
On Fri, 2009-10-16 at 10:15 -0700, Roberts, Randy wrote: > Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of > 10ms.. > > For DM6467, and other ARM Davinci linux implementations, 2.6.10 based > specifically, how does one get the jiffies to 1ms, instead of what > appears to be 10ms? > > I believe I have HIGHRES timers enabled... > > Anything else one needs to do to get usleep resolution 1ms instead of > 10ms? > > Scheduler config? > What is the patch level? DM6467 HRT was not working correct. There was a patch that fixed the problem. Regards, Steve
We're seeing the same thing on our DM355-based system with the 2.6.10 kernel. Steve, can you point us to the patch you mentioned below?
Hi Steve, I haven't applied any additional patches to the stock MV 2.6.10 release [root@flir ~]# cat /proc/version Linux version 2.6.10_mvl401-davinci_evm-PSP_01_30_00_082 (gcc version 3.4.3 (MontaVista 3.4.3-25.0.104.0600975 2006-07-06)) #1 Fri Oct 16 10:29:49 PDT 2009 I noticed a CONFIG_PREEMPT_RT patch on the linux wiki...is that what you're referring to? How can I start using the CONFIG_PREEMPT_RT patch? Please see the RT PREEMPT HOWTO for a detailed description. The short version is to get the latest -rt patch from http://www.kernel.org/pub/linux/kernel/projects/rt/, then get the related vanilla kernel from http://kernel.org, apply the patch to the kernel, configure, and compile the kernel. Has this patch been successfully applied to MVs Davinci 2.6.10? From http://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch#Platforms_Te sted_and_in_Use_with_CONFIG_PREEMPT_RT It looks like it has been applied to OMAP 5912 and DM6446 Davinci, but it does mention 2.6.23rt specifically... Thanks for the assist, Randy -----Original Message----- From: Steve Chen [mailto:schen@mvista.com] Sent: Friday, October 16, 2009 10:55 AM To: Roberts, Randy Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: jiffie resolution and usleep accuracy On Fri, 2009-10-16 at 10:15 -0700, Roberts, Randy wrote: > Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of > 10ms.. > > For DM6467, and other ARM Davinci linux implementations, 2.6.10 based > specifically, how does one get the jiffies to 1ms, instead of what > appears to be 10ms? > > I believe I have HIGHRES timers enabled... > > Anything else one needs to do to get usleep resolution 1ms instead of > 10ms? > > Scheduler config? > What is the patch level? DM6467 HRT was not working correct. There was a patch that fixed the problem. Regards, Steve
Oooh...it gets worse... I hadn't previously had CONFIG_PREEMPT_RT defined in kernel config...tried it, rebuilt...but, I get this message when I try to rebuild dsp/bios link drv_pmgr.c:146:2: #error Realtime preemption is not supported with this version of DSP/BIOS Link Is that CONFIG_PREEMPT_RT necessary (default is CONFIG_PREEMPT_DESKTOP) to get sub 10ms resolution for usleep and select blocks, etc.??? Randy -----Original Message----- From: Roberts, Randy Sent: Friday, October 16, 2009 11:04 AM To: 'Steve Chen' Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: jiffie resolution and usleep accuracy Hi Steve, I haven't applied any additional patches to the stock MV 2.6.10 release [root@flir ~]# cat /proc/version Linux version 2.6.10_mvl401-davinci_evm-PSP_01_30_00_082 (gcc version 3.4.3 (MontaVista 3.4.3-25.0.104.0600975 2006-07-06)) #1 Fri Oct 16 10:29:49 PDT 2009 I noticed a CONFIG_PREEMPT_RT patch on the linux wiki...is that what you're referring to? How can I start using the CONFIG_PREEMPT_RT patch? Please see the RT PREEMPT HOWTO for a detailed description. The short version is to get the latest -rt patch from http://www.kernel.org/pub/linux/kernel/projects/rt/, then get the related vanilla kernel from http://kernel.org, apply the patch to the kernel, configure, and compile the kernel. Has this patch been successfully applied to MVs Davinci 2.6.10? From http://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch#Platforms_Te sted_and_in_Use_with_CONFIG_PREEMPT_RT It looks like it has been applied to OMAP 5912 and DM6446 Davinci, but it does mention 2.6.23rt specifically... Thanks for the assist, Randy -----Original Message----- From: Steve Chen [mailto:schen@mvista.com] Sent: Friday, October 16, 2009 10:55 AM To: Roberts, Randy Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: jiffie resolution and usleep accuracy On Fri, 2009-10-16 at 10:15 -0700, Roberts, Randy wrote: > Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of > 10ms.. > > For DM6467, and other ARM Davinci linux implementations, 2.6.10 based > specifically, how does one get the jiffies to 1ms, instead of what > appears to be 10ms? > > I believe I have HIGHRES timers enabled... > > Anything else one needs to do to get usleep resolution 1ms instead of > 10ms? > > Scheduler config? > What is the patch level? DM6467 HRT was not working correct. There was a patch that fixed the problem. Regards, Steve
Hello. Steve Chen wrote: >>Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of >>10ms.. I'm not seeing this function in either recent kernels or MV's 2.6.10. Perhaps you meant msleep()? >>For DM6467, and other ARM Davinci linux implementations, 2.6.10 based >>specifically, how does one get the jiffies to 1ms, instead of what >>appears to be 10ms? >>I believe I have HIGHRES timers enabled... >>Anything else one needs to do to get usleep resolution 1ms instead of >>10ms? Try adding this to in include/asm-arm/arch-davinci/param.h: #define HZ 1000 >>Scheduler config? > What is the patch level? DM6467 HRT was not working correct. There was > a patch that fixed the problem. I highly doubt that usleep() or msleep() uses clock_nanosleep(), so whether HRT works or not shouldn't matter. > Regards, > Steve WBR, Sergei
Roberts, Randy wrote: > Oooh...it gets worse... > > I hadn't previously had CONFIG_PREEMPT_RT defined in kernel > config...tried it, rebuilt...but, I get this message when I try to > rebuild dsp/bios link > > drv_pmgr.c:146:2: #error Realtime preemption is not supported with this > version of DSP/BIOS Link > > Is that CONFIG_PREEMPT_RT necessary (default is CONFIG_PREEMPT_DESKTOP) > to get sub 10ms resolution for usleep and select blocks, etc.??? set the scheduler interval to 1ms instead of 10ms
On Fri, 2009-10-16 at 22:07 +0400, Sergei Shtylyov wrote: > Hello. > > Steve Chen wrote: > > >>Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of > >>10ms.. > > I'm not seeing this function in either recent kernels or MV's 2.6.10. > Perhaps you meant msleep()? > > >>For DM6467, and other ARM Davinci linux implementations, 2.6.10 based > >>specifically, how does one get the jiffies to 1ms, instead of what > >>appears to be 10ms? > > >>I believe I have HIGHRES timers enabled... > > >>Anything else one needs to do to get usleep resolution 1ms instead of > >>10ms? > > Try adding this to in include/asm-arm/arch-davinci/param.h: > > #define HZ 1000 > > >>Scheduler config? > > What is the patch level? DM6467 HRT was not working correct. There was > > a patch that fixed the problem. > > I highly doubt that usleep() or msleep() uses clock_nanosleep(), so > whether HRT works or not shouldn't matter. I was thinking about mdelay/udelay/ndelay perhaps I misunderstood. Regardless, in the original release of dm6467 with 2.6.10 kernel, HRT uses the same timer as the WDT which did not work too well. There may be other things that needs to be addressed as well. Steve
The #define HZ 1000 did the trick! (with no further changes required...original CONFIG_PREEMPT_DESKTOP, etc.) Thanks! Randy -----Original Message----- From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com] Sent: Friday, October 16, 2009 11:08 AM To: Roberts, Randy Cc: Steve Chen; davinci-linux-open-source@linux.davincidsp.com Subject: Re: jiffie resolution and usleep accuracy Hello. Steve Chen wrote: >>Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of >>10ms.. I'm not seeing this function in either recent kernels or MV's 2.6.10. Perhaps you meant msleep()? >>For DM6467, and other ARM Davinci linux implementations, 2.6.10 based >>specifically, how does one get the jiffies to 1ms, instead of what >>appears to be 10ms? >>I believe I have HIGHRES timers enabled... >>Anything else one needs to do to get usleep resolution 1ms instead of >>10ms? Try adding this to in include/asm-arm/arch-davinci/param.h: #define HZ 1000 >>Scheduler config? > What is the patch level? DM6467 HRT was not working correct. There was > a patch that fixed the problem. I highly doubt that usleep() or msleep() uses clock_nanosleep(), so whether HRT works or not shouldn't matter. > Regards, > Steve WBR, Sergei
Andrew Morton <akpm@linux-foundation.org> writes: > On Fri, 16 Oct 2009 09:48:50 -0700 > Kevin Hilman <khilman@deeprootsystems.com> wrote: > >> Chaithrika U S <chaithrika@ti.com> writes: >> >> > The clock divider value can be calculated from the pixel clock >> > value for the panel. This gives more flexiblity to the driver >> > to change the divider value on the fly as in the case of cpufreq >> > feature- support for which will be added shortly. >> > >> > Signed-off-by: Chaithrika U S <chaithrika@ti.com> >> > --- >> > This patch applies on Linus' kernel tree. >> >> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> >> >> Temporarily adding to davinci git while waiting for merge to mainline. > > What is "davinci git"? > DaVinci git[1] is the tree I maintain where I queue upcoming changes for the core DaVinci platform (arch/arm/mach-davinci/*) as well as maintain a branch (davinci-next) which is pulled into linux-next. Also, for wider testing, I temporarily add davinci driver updates that are headed upstream until they are merged. This tree provides a single place where all the latest davinci code that is headed upstream can be tested. Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary
Andrew Morton <akpm@linux-foundation.org> writes: > On Mon, 02 Nov 2009 16:25:10 -0800 > Kevin Hilman <khilman@deeprootsystems.com> wrote: > >> Andrew Morton <akpm@linux-foundation.org> writes: >> >> > On Fri, 16 Oct 2009 09:48:50 -0700 >> > Kevin Hilman <khilman@deeprootsystems.com> wrote: >> > >> >> Chaithrika U S <chaithrika@ti.com> writes: >> >> >> >> > The clock divider value can be calculated from the pixel clock >> >> > value for the panel. This gives more flexiblity to the driver >> >> > to change the divider value on the fly as in the case of cpufreq >> >> > feature- support for which will be added shortly. >> >> > >> >> > Signed-off-by: Chaithrika U S <chaithrika@ti.com> >> >> > --- >> >> > This patch applies on Linus' kernel tree. >> >> >> >> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> >> >> >> >> Temporarily adding to davinci git while waiting for merge to mainline. >> > >> > What is "davinci git"? >> > >> >> DaVinci git[1] is the tree I maintain where I queue upcoming changes >> for the core DaVinci platform (arch/arm/mach-davinci/*) as well as >> maintain a branch (davinci-next) which is pulled into linux-next. >> >> Also, for wider testing, I temporarily add davinci driver updates that >> are headed upstream until they are merged. >> >> This tree provides a single place where all the latest davinci code >> that is headed upstream can be tested. >> >> Kevin >> >> [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary > > It's been two weeks and this patch still isn't in linux-next. Did > something go wrong? Sorry for the confusion.... I only push arch/arm/mach-davinci/* changes to linux-next. Since this is a framebuffer patch, it was intended to go via the proper subsystem route, and it seems that fb patches have been merging through you, including the original version of this driver, so I was expecting the fix to merge through you as well. Kevin
Hi Sergei, et al.,
I have found that setting #define HZ 1000 in param.h breaks udelay()
calls...not sure why...anyone seen same? Fix?
Specifically, the udelay() returns without waiting at all...
HZ is used in the __udelay assembly code, but I'm not well enough versed
in arm assembly to figure out how this code may have gotten broken just
because HZ changed from 100 to 1000...
.globl __udelay
__udelay:
save %sp, -STACKFRAME_SZ, %sp
mov %i0, %o0
sethi %hi(0x10c6), %o1
call .umul
or %o1, %lo(0x10c6), %o1 ! 2**32 / 1 000 000
call .umul
mov %i1, %o1 ! udelay_val
call .umul
mov HZ, %o0 ! >>32 earlier for wider range
delay_continue:
cmp %o0, 0x0
1:
bne 1b
subcc %o0, 1, %o0
ret
restore
Regards,
Randy
-----Original Message-----
From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com]
Sent: Friday, October 16, 2009 11:08 AM
To: Roberts, Randy
Cc: Steve Chen; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: jiffie resolution and usleep accuracy
Hello.
Steve Chen wrote:
>>Running 2.6.10 on a DM6467 I see usleep having a minimum resolution of
>>10ms..
I'm not seeing this function in either recent kernels or MV's
2.6.10.
Perhaps you meant msleep()?
>>For DM6467, and other ARM Davinci linux implementations, 2.6.10 based
>>specifically, how does one get the jiffies to 1ms, instead of what
>>appears to be 10ms?
>>I believe I have HIGHRES timers enabled...
>>Anything else one needs to do to get usleep resolution 1ms instead of
>>10ms?
Try adding this to in include/asm-arm/arch-davinci/param.h:
#define HZ 1000
>>Scheduler config?
> What is the patch level? DM6467 HRT was not working correct. There
was
> a patch that fixed the problem.
I highly doubt that usleep() or msleep() uses clock_nanosleep(), so
whether HRT works or not shouldn't matter.
> Regards,
> Steve
WBR, Sergei
In case it matters, I'm calling udelay(25)...which waits close to zero... If I use 100, I get a 100us delay...if I use 75, 8us... Is function below now somehow limited to minimum of 100 because of the change from HZ 100 to HZ 1000? Regards, Randy
Apologies...the snippet I sent earlier was for Sparc... the code from linux/arch/arm/lib/delay.S is where __udelay() and __const_udelay() are found. They do not seem to be based upon the HZ value directly...but, are based upon loops_per_jiffy... Still searching for why udelay() behaves differently... Randy
There is new code (linux/arch/arm/lib.delay.S) in GIT that works for HZ 1000! Sorry, for any noise...
Patch
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index d065894..d9ab839 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -113,6 +113,7 @@ struct da8xx_fb_par { unsigned short pseudo_palette[16]; unsigned int databuf_sz; unsigned int palette_sz; + unsigned int pxl_clk; }; /* Variable Screen Information */ @@ -155,7 +156,7 @@ struct da8xx_panel { int vfp; /* Vertical front porch */ int vbp; /* Vertical back porch */ int vsw; /* Vertical Sync Pulse Width */ - int pxl_clk; /* Pixel clock */ + unsigned int pxl_clk; /* Pixel clock */ unsigned char invert_pxl_clk; /* Invert Pixel clock */ }; @@ -171,7 +172,7 @@ static struct da8xx_panel known_lcd_panels[] = { .vfp = 2, .vbp = 2, .vsw = 0, - .pxl_clk = 0x10, + .pxl_clk = 4608000, .invert_pxl_clk = 1, }, /* Sharp LK043T1DG01 */ @@ -185,7 +186,7 @@ static struct da8xx_panel known_lcd_panels[] = { .vfp = 2, .vbp = 2, .vsw = 10, - .pxl_clk = 0x12, + .pxl_clk = 7833600, .invert_pxl_clk = 0, }, }; @@ -451,6 +452,18 @@ static void lcd_reset(struct da8xx_fb_par *par) lcdc_write(0, LCD_RASTER_CTRL_REG); } +static void lcd_calc_clk_divider(struct da8xx_fb_par *par) +{ + unsigned int lcd_clk, div; + + lcd_clk = clk_get_rate(par->lcdc_clk); + div = lcd_clk / par->pxl_clk; + + /* Configure the LCD clock divisor. */ + lcdc_write(LCD_CLK_DIVISOR(div) | + (LCD_RASTER_MODE & 0x1), LCD_CTRL_REG); +} + static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg, struct da8xx_panel *panel) { @@ -459,9 +472,8 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg, lcd_reset(par); - /* Configure the LCD clock divisor. */ - lcdc_write(LCD_CLK_DIVISOR(panel->pxl_clk) | - (LCD_RASTER_MODE & 0x1), LCD_CTRL_REG); + /* Calculate the divider */ + lcd_calc_clk_divider(par); if (panel->invert_pxl_clk) lcdc_write((lcdc_read(LCD_RASTER_TIMING_2_REG) | @@ -721,6 +733,8 @@ static int __init fb_probe(struct platform_device *device) } par = da8xx_fb_info->par; + par->lcdc_clk = fb_clk; + par->pxl_clk = lcdc_info->pxl_clk; if (lcd_init(par, lcd_cfg, lcdc_info) < 0) { dev_err(&device->dev, "lcd_init failed\n"); @@ -753,8 +767,6 @@ static int __init fb_probe(struct platform_device *device) da8xx_fb_fix.smem_len = par->databuf_sz - par->palette_sz; da8xx_fb_fix.line_length = (lcdc_info->width * lcd_cfg->bpp) / 8; - par->lcdc_clk = fb_clk; - par->irq = platform_get_irq(device, 0); if (par->irq < 0) { ret = -ENOENT;
The clock divider value can be calculated from the pixel clock value for the panel. This gives more flexiblity to the driver to change the divider value on the fly as in the case of cpufreq feature- support for which will be added shortly. Signed-off-by: Chaithrika U S <chaithrika@ti.com> --- This patch applies on Linus' kernel tree. drivers/video/da8xx-fb.c | 28 ++++++++++++++++++++-------- 1 files changed, 20 insertions(+), 8 deletions(-)