Re: Linux 3.0 DSS support

Re: Linux 3.0 DSS support

[Tomi Valkeinen]

On 10/14/2011 07:52 PM, Ashwin Bihari wrote:
> Greetings,
>
> I'm trying to add support for our custom DM3730 based board to the Linux
> 3.0 Kernel and am having issues with the DSS support. I also have a
> AM3517 and BeagleBoard xM devkit as reference hardware. I've done some
> searching and have found that the AM3517 display support isn't fully
> functioning, so I tried to focus on the BeagleBoard xM which seems to be
> doing something but the LCD never comes to life.

I don't have any of those boards, and I'm totally unfamiliar with DM3730 
and AM3517, so I can't if the mainline works with them or not. But I 
presume DM3730 and AM3517 are using the same DSS hardware than OMAPs? 
 From DSS driver's perspective everything should be there, and if their 
board files contain the definitions for the displays, then they should work.

> I'm currently using the following bootargs:
>
> console=ttyO2,115200n8 mpurate=auto buddy=none vram=12M
> omapfb.mode=dvi:640x480MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
> root=/dev/ram0 rw ramdisk_size=65536 initrd=0x81000000,64M rootfstype=ext2
>
> I have tried different resolutions which all yield the same blank screen
> on the LCD with it going into power-save mode..
>
> I've looked at all the current board-* files that define displays and
> have done the same for my display, and the display portion itself seems
> to run and my LCD gets powered-on and the backlight turned on, but I
> don't see a valid HSYNC or VSYNC signal out there..

So are you using the DVI output or what? If so, is the DVI framer 
enabled? Is pin muxing set up correctly?

> On the BeagleBoard xM, I also see the following debug messages from
> OMAPDSS and OMAPFB
>
> ---Begin OMAPDSS--
> [    1.175659] omapdss DSS: clk ick, rate 50000000
> [    1.175689] omapdss DSS: clk fck, rate 96000000
> [    1.175720] omapdss DSS: clk sys_clk, rate 13000000
> [    1.175750] omapdss DSS: clk tv_clk, rate 54000000
> [    1.175781] omapdss DSS: clk video_clk, rate 96000000
> [    1.175842] omapdss DSS: initial ctx id 0
> [    1.264221] omapdss CORE: bus_match. dev display0/generic_dpi_panel,
> drv venc
> [    1.264953] omapdss CORE: bus_match. dev display1/venc, drv venc
> [    1.265045] omapdss CORE: driver_probe: dev display1/venc, drv venc
> [    1.265045] omapdss VENC: init_display
> [    1.265533] omapdss CORE: probe done for device display1
> [    1.265594] omapdss DSS: save context
> [    1.266479] omapdss CORE: bus_match. dev display0/generic_dpi_panel,
> drv generic_dpi_panel
> [    1.266540] omapdss CORE: driver_probe: dev
> display0/generic_dpi_panel, drv generic_dpi_panel
> [    1.266571] omapdss DPI: init_display
> [    1.266815] omapdss DSS: save context
> [    1.266906] omapdss DSS: save context
> [    1.266967] omapdss DSS: save context
> [    1.267028] omapdss CORE: probe done for device display0
> [    1.267059] omapdss CORE: bus_match. dev display1/venc, drv
> generic_dpi_panel
> [    2.689788] omapdss DPI: dpi_set_timings
> [    2.698883] omapdss MANAGER: omap_dss_mgr_apply(lcd)
> [    2.699157] omapdss MANAGER: configure_manager(0)
> [    2.699218] omapdss MANAGER: configure_manager(1)
> [    2.699279] omapdss DSS: save context
> [    2.715332] omapdss OVERLAY: check_overlay 0: (0,0 640x480 ->
> 640x480) disp (640x480)
> [    2.715362] omapdss MANAGER: omap_dss_mgr_apply(lcd)
> [    2.715423] omapdss OVERLAY: check_overlay 0: (0,0 640x480 ->
> 640x480) disp (640x480)
> [    2.715484] omapdss MANAGER: configure_overlay(0)
> [    2.715515] omapdss DISPC: dispc_setup_plane 0, pa 8f400000, sw 640,
> 0, 0, 640x480 -> 640x480, ilace 0, cmode 40, rot 0, mir 0 chan 0
> [    2.715545] omapdss DISPC: calc_rot(0): scrw 640, 640x480
> [    2.715576] omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
> [    2.715576] omapdss DISPC: 0,0 640x480 -> 640x480
> [    2.715637] omapdss DISPC: fifo(0) low/high old 960/1023, new 960/1023
> [    2.715667] omapdss DISPC: dispc_enable_plane 0, 1
> [    2.715698] omapdss DSS: save context
> [    2.715728] omapdss MANAGER: omap_dss_mgr_apply(tv)
> [    2.715759] omapdss DSS: save context
> [    2.716186] omapdss DISPC: onoff 0 rf 0 ieo 0 ipc 0 ihs 0 ivs 0 acbi
> 0 acb 0
> [    2.716217] omapdss DSS: dpll4_m4 = 864000000
> [    2.716247] omapdss DSS: fck = 48000000 (18)
> [    2.716278] omapdss DISPC: lck = 48000000 (1)
> [    2.716278] omapdss DISPC: pck = 24000000 (2)
> [    2.716339] omapdss DISPC: channel 0 xres 640 yres 480
> [    2.716339] omapdss DISPC: pck 24000
> [    2.716369] omapdss DISPC: hsw 32 hfp 48 hbp 80 vsw 4 vfp 7 vbp 3
> [    2.716369] omapdss DISPC: hsync 30000Hz, vsync 60Hz
> ---End OMAPDSS--
>
> ---Begin OMAPFB--
> [    2.684204] OMAPFB: omapfb_init
> [    2.684478] OMAPFB: omapfb_probe
> [    2.684570] fbcvt: 640x480@60: CVT Name - .307M3-R
> [    2.689849] OMAPFB: fb_infos allocated
> [    2.689880] OMAPFB: allocating 614400 bytes for fb 0
> [    2.693847] OMAPFB: fbmems allocated
> [    2.694030] OMAPFB: check_fb_var 0
> [    2.694091] OMAPFB: set_fb_fix
> [    2.694427] OMAPFB: fb_infos initialized
> [    2.698822] OMAPFB: set_fb_fix
> [    2.698822] OMAPFB: apply_changes, fb 0, ovl 0
> [    2.715209] OMAPFB: apply_changes, fb 0, ovl 0
> [    2.715270] OMAPFB: apply_changes, fb 1, ovl 1
> [    2.715301] OMAPFB: apply_changes, fb 2, ovl 2
> [    2.718109] OMAPFB: create sysfs for fbs
> [    2.718109] OMAPFB: create sysfs for fbs
> ---End OMAPFB--

Everything seems to be ok there as far as I see.

  Tomi

Re: Linux 3.0 DSS support

[Ashwin Bihari]

Sending to the mailing list properly to see if anyone has any other
ideas for me to pursue..darn rich formatting prevented the previous
mails from getting to the list!

On Tue, Oct 18, 2011 at 12:59 PM, Ashwin Bihari <abihari@gmail.com> wrote:
> On Mon, Oct 17, 2011 at 3:19 AM, Tomi Valkeinen <tomi.valkeinen@ti.com>
> wrote:
>>
>> On 10/14/2011 07:52 PM, Ashwin Bihari wrote:
>>>
>>> Greetings,
>>>
>>> I'm trying to add support for our custom DM3730 based board to the Linux
>>> 3.0 Kernel and am having issues with the DSS support. I also have a
>>> AM3517 and BeagleBoard xM devkit as reference hardware. I've done some
>>> searching and have found that the AM3517 display support isn't fully
>>> functioning, so I tried to focus on the BeagleBoard xM which seems to be
>>> doing something but the LCD never comes to life.
>>
>> I don't have any of those boards, and I'm totally unfamiliar with DM3730
>> and AM3517, so I can't if the mainline works with them or not. But I presume
>> DM3730 and AM3517 are using the same DSS hardware than OMAPs? From DSS
>> driver's perspective everything should be there, and if their board files
>> contain the definitions for the displays, then they should work.
>
> The DM3730 is essentially a die-shrink of the OMAP3530, so faster speed but
> same functionality. Heck, virtually all of the same OMAP3530 drivers just
> work on the DM3730, which is why I'm so darn confused as to why this isn't
> working.
>
>>>
>>> I'm currently using the following bootargs:
>>>
>>> console=ttyO2,115200n8 mpurate=auto buddy=none vram=12M
>>> omapfb.mode=dvi:640x480MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
>>> root=/dev/ram0 rw ramdisk_size=65536 initrd=0x81000000,64M
>>> rootfstype=ext2
>>>
>>> I have tried different resolutions which all yield the same blank screen
>>> on the LCD with it going into power-save mode..
>>>
>>> I've looked at all the current board-* files that define displays and
>>> have done the same for my display, and the display portion itself seems
>>> to run and my LCD gets powered-on and the backlight turned on, but I
>>> don't see a valid HSYNC or VSYNC signal out there..
>>
>> So are you using the DVI output or what? If so, is the DVI framer enabled?
>> Is pin muxing set up correctly?
>
> On the BeagleBoardXM, yes I was using the DVI for the output, on my custom
> DM3730 hardware, we're using the LCD as the output. The pin muxing is setup
> correctly as far as I can tell, and I will check on the DVI framer to
> confirm that it's working.
> The pin muxing for all of the DSS pins are set to be MODE0..
>
>>>
>>> On the BeagleBoard xM, I also see the following debug messages from
>>> OMAPDSS and OMAPFB
>>>
>>> ---Begin OMAPDSS--
>>> [    1.175659] omapdss DSS: clk ick, rate 50000000
>>> [    1.175689] omapdss DSS: clk fck, rate 96000000
>>> [    1.175720] omapdss DSS: clk sys_clk, rate 13000000
>>> [    1.175750] omapdss DSS: clk tv_clk, rate 54000000
>>> [    1.175781] omapdss DSS: clk video_clk, rate 96000000
>>> [    1.175842] omapdss DSS: initial ctx id 0
>>> [    1.264221] omapdss CORE: bus_match. dev display0/generic_dpi_panel,
>>> drv venc
>>> [    1.264953] omapdss CORE: bus_match. dev display1/venc, drv venc
>>> [    1.265045] omapdss CORE: driver_probe: dev display1/venc, drv venc
>>> [    1.265045] omapdss VENC: init_display
>>> [    1.265533] omapdss CORE: probe done for device display1
>>> [    1.265594] omapdss DSS: save context
>>> [    1.266479] omapdss CORE: bus_match. dev display0/generic_dpi_panel,
>>> drv generic_dpi_panel
>>> [    1.266540] omapdss CORE: driver_probe: dev
>>> display0/generic_dpi_panel, drv generic_dpi_panel
>>> [    1.266571] omapdss DPI: init_display
>>> [    1.266815] omapdss DSS: save context
>>> [    1.266906] omapdss DSS: save context
>>> [    1.266967] omapdss DSS: save context
>>> [    1.267028] omapdss CORE: probe done for device display0
>>> [    1.267059] omapdss CORE: bus_match. dev display1/venc, drv
>>> generic_dpi_panel
>>> [    2.689788] omapdss DPI: dpi_set_timings
>>> [    2.698883] omapdss MANAGER: omap_dss_mgr_apply(lcd)
>>> [    2.699157] omapdss MANAGER: configure_manager(0)
>>> [    2.699218] omapdss MANAGER: configure_manager(1)
>>> [    2.699279] omapdss DSS: save context
>>> [    2.715332] omapdss OVERLAY: check_overlay 0: (0,0 640x480 ->
>>> 640x480) disp (640x480)
>>> [    2.715362] omapdss MANAGER: omap_dss_mgr_apply(lcd)
>>> [    2.715423] omapdss OVERLAY: check_overlay 0: (0,0 640x480 ->
>>> 640x480) disp (640x480)
>>> [    2.715484] omapdss MANAGER: configure_overlay(0)
>>> [    2.715515] omapdss DISPC: dispc_setup_plane 0, pa 8f400000, sw 640,
>>> 0, 0, 640x480 -> 640x480, ilace 0, cmode 40, rot 0, mir 0 chan 0
>>> [    2.715545] omapdss DISPC: calc_rot(0): scrw 640, 640x480
>>> [    2.715576] omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
>>> [    2.715576] omapdss DISPC: 0,0 640x480 -> 640x480
>>> [    2.715637] omapdss DISPC: fifo(0) low/high old 960/1023, new 960/1023
>>> [    2.715667] omapdss DISPC: dispc_enable_plane 0, 1
>>> [    2.715698] omapdss DSS: save context
>>> [    2.715728] omapdss MANAGER: omap_dss_mgr_apply(tv)
>>> [    2.715759] omapdss DSS: save context
>>> [    2.716186] omapdss DISPC: onoff 0 rf 0 ieo 0 ipc 0 ihs 0 ivs 0 acbi
>>> 0 acb 0
>>> [    2.716217] omapdss DSS: dpll4_m4 = 864000000
>>> [    2.716247] omapdss DSS: fck = 48000000 (18)
>>> [    2.716278] omapdss DISPC: lck = 48000000 (1)
>>> [    2.716278] omapdss DISPC: pck = 24000000 (2)
>>> [    2.716339] omapdss DISPC: channel 0 xres 640 yres 480
>>> [    2.716339] omapdss DISPC: pck 24000
>>> [    2.716369] omapdss DISPC: hsw 32 hfp 48 hbp 80 vsw 4 vfp 7 vbp 3
>>> [    2.716369] omapdss DISPC: hsync 30000Hz, vsync 60Hz
>>> ---End OMAPDSS--
>>>
>>> ---Begin OMAPFB--
>>> [    2.684204] OMAPFB: omapfb_init
>>> [    2.684478] OMAPFB: omapfb_probe
>>> [    2.684570] fbcvt: 640x480@60: CVT Name - .307M3-R
>>> [    2.689849] OMAPFB: fb_infos allocated
>>> [    2.689880] OMAPFB: allocating 614400 bytes for fb 0
>>> [    2.693847] OMAPFB: fbmems allocated
>>> [    2.694030] OMAPFB: check_fb_var 0
>>> [    2.694091] OMAPFB: set_fb_fix
>>> [    2.694427] OMAPFB: fb_infos initialized
>>> [    2.698822] OMAPFB: set_fb_fix
>>> [    2.698822] OMAPFB: apply_changes, fb 0, ovl 0
>>> [    2.715209] OMAPFB: apply_changes, fb 0, ovl 0
>>> [    2.715270] OMAPFB: apply_changes, fb 1, ovl 1
>>> [    2.715301] OMAPFB: apply_changes, fb 2, ovl 2
>>> [    2.718109] OMAPFB: create sysfs for fbs
>>> [    2.718109] OMAPFB: create sysfs for fbs
>>> ---End OMAPFB--
>>
>> Everything seems to be ok there as far as I see.
>>
>>  Tomi
>
>
> -- Ashwin
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux 3.0 DSS support

[Peter Barada]

On 10/17/2011 03:19 AM, Tomi Valkeinen wrote:
> On 10/14/2011 07:52 PM, Ashwin Bihari wrote:
>> Greetings,
>>
>> I'm trying to add support for our custom DM3730 based board to the Linux
>> 3.0 Kernel and am having issues with the DSS support. I also have a
>> AM3517 and BeagleBoard xM devkit as reference hardware. I've done some
>> searching and have found that the AM3517 display support isn't fully
>> functioning, so I tried to focus on the BeagleBoard xM which seems to be
>> doing something but the LCD never comes to life.
> I don't have any of those boards, and I'm totally unfamiliar with DM3730
> and AM3517, so I can't if the mainline works with them or not. But I
> presume DM3730 and AM3517 are using the same DSS hardware than OMAPs?
>   From DSS driver's perspective everything should be there, and if their
> board files contain the definitions for the displays, then they should work.
>
>> I'm currently using the following bootargs:
>>
>> console=ttyO2,115200n8 mpurate=auto buddy=none vram=12M
>> omapfb.mode=dvi:640x480MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
>> root=/dev/ram0 rw ramdisk_size=65536 initrd=0x81000000,64M rootfstype=ext2
>>
>> I have tried different resolutions which all yield the same blank screen
>> on the LCD with it going into power-save mode..
>>
>> I've looked at all the current board-* files that define displays and
>> have done the same for my display, and the display portion itself seems
>> to run and my LCD gets powered-on and the backlight turned on, but I
>> don't see a valid HSYNC or VSYNC signal out there..
> So are you using the DVI output or what? If so, is the DVI framer
> enabled? Is pin muxing set up correctly?
>
>> On the BeagleBoard xM, I also see the following debug messages from
>> OMAPDSS and OMAPFB
>>
>> ---Begin OMAPDSS--
>> [    1.175659] omapdss DSS: clk ick, rate 50000000
>> [    1.175689] omapdss DSS: clk fck, rate 96000000
>> [    1.175720] omapdss DSS: clk sys_clk, rate 13000000
>> [    1.175750] omapdss DSS: clk tv_clk, rate 54000000
>> [    1.175781] omapdss DSS: clk video_clk, rate 96000000
>> [    1.175842] omapdss DSS: initial ctx id 0
>> [    1.264221] omapdss CORE: bus_match. dev display0/generic_dpi_panel,
>> drv venc
>> [    1.264953] omapdss CORE: bus_match. dev display1/venc, drv venc
>> [    1.265045] omapdss CORE: driver_probe: dev display1/venc, drv venc
>> [    1.265045] omapdss VENC: init_display
>> [    1.265533] omapdss CORE: probe done for device display1
>> [    1.265594] omapdss DSS: save context
>> [    1.266479] omapdss CORE: bus_match. dev display0/generic_dpi_panel,
>> drv generic_dpi_panel
>> [    1.266540] omapdss CORE: driver_probe: dev
>> display0/generic_dpi_panel, drv generic_dpi_panel
>> [    1.266571] omapdss DPI: init_display
>> [    1.266815] omapdss DSS: save context
>> [    1.266906] omapdss DSS: save context
>> [    1.266967] omapdss DSS: save context
>> [    1.267028] omapdss CORE: probe done for device display0
>> [    1.267059] omapdss CORE: bus_match. dev display1/venc, drv
>> generic_dpi_panel
>> [    2.689788] omapdss DPI: dpi_set_timings
>> [    2.698883] omapdss MANAGER: omap_dss_mgr_apply(lcd)
>> [    2.699157] omapdss MANAGER: configure_manager(0)
>> [    2.699218] omapdss MANAGER: configure_manager(1)
>> [    2.699279] omapdss DSS: save context
>> [    2.715332] omapdss OVERLAY: check_overlay 0: (0,0 640x480 ->
>> 640x480) disp (640x480)
>> [    2.715362] omapdss MANAGER: omap_dss_mgr_apply(lcd)
>> [    2.715423] omapdss OVERLAY: check_overlay 0: (0,0 640x480 ->
>> 640x480) disp (640x480)
>> [    2.715484] omapdss MANAGER: configure_overlay(0)
>> [    2.715515] omapdss DISPC: dispc_setup_plane 0, pa 8f400000, sw 640,
>> 0, 0, 640x480 ->  640x480, ilace 0, cmode 40, rot 0, mir 0 chan 0
>> [    2.715545] omapdss DISPC: calc_rot(0): scrw 640, 640x480
>> [    2.715576] omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
>> [    2.715576] omapdss DISPC: 0,0 640x480 ->  640x480
>> [    2.715637] omapdss DISPC: fifo(0) low/high old 960/1023, new 960/1023
>> [    2.715667] omapdss DISPC: dispc_enable_plane 0, 1
>> [    2.715698] omapdss DSS: save context
>> [    2.715728] omapdss MANAGER: omap_dss_mgr_apply(tv)
>> [    2.715759] omapdss DSS: save context
>> [    2.716186] omapdss DISPC: onoff 0 rf 0 ieo 0 ipc 0 ihs 0 ivs 0 acbi
>> 0 acb 0
>> [    2.716217] omapdss DSS: dpll4_m4 = 864000000
>> [    2.716247] omapdss DSS: fck = 48000000 (18)
>> [    2.716278] omapdss DISPC: lck = 48000000 (1)
>> [    2.716278] omapdss DISPC: pck = 24000000 (2)
>> [    2.716339] omapdss DISPC: channel 0 xres 640 yres 480
>> [    2.716339] omapdss DISPC: pck 24000
>> [    2.716369] omapdss DISPC: hsw 32 hfp 48 hbp 80 vsw 4 vfp 7 vbp 3
>> [    2.716369] omapdss DISPC: hsync 30000Hz, vsync 60Hz
>> ---End OMAPDSS--
>>
>> ---Begin OMAPFB--
>> [    2.684204] OMAPFB: omapfb_init
>> [    2.684478] OMAPFB: omapfb_probe
>> [    2.684570] fbcvt: 640x480@60: CVT Name - .307M3-R
>> [    2.689849] OMAPFB: fb_infos allocated
>> [    2.689880] OMAPFB: allocating 614400 bytes for fb 0
>> [    2.693847] OMAPFB: fbmems allocated
>> [    2.694030] OMAPFB: check_fb_var 0
>> [    2.694091] OMAPFB: set_fb_fix
>> [    2.694427] OMAPFB: fb_infos initialized
>> [    2.698822] OMAPFB: set_fb_fix
>> [    2.698822] OMAPFB: apply_changes, fb 0, ovl 0
>> [    2.715209] OMAPFB: apply_changes, fb 0, ovl 0
>> [    2.715270] OMAPFB: apply_changes, fb 1, ovl 1
>> [    2.715301] OMAPFB: apply_changes, fb 2, ovl 2
>> [    2.718109] OMAPFB: create sysfs for fbs
>> [    2.718109] OMAPFB: create sysfs for fbs
>> ---End OMAPFB--
> Everything seems to be ok there as far as I see.
Tomi,

After digging into this in linux-3.0 (while adding different LCD code 
into u-boot), I think I stumbled across the problem.  I needed to 
calculate the divisor from the pixel clock (since I want to use the same 
custom display specifier in u-boot as the kernel), and used code from 
DSS in the kernel to do the DISPC_DIVISOR calculation.

In the process of determining DSS_CLKSEL_DSS and DISPC_DIVISOR setting, 
the code in dss.c:dss_calc_clock_div() iterates calling 
dispc_find_clk_divs() after pre-scaling the clock by the divisor by 
fck_div (which will is programmed in CM_CLKSEL_DSS:CLKSEL_DSS1), 
apparently in an attempt to find the closest match using the highest 
CLKSEL_DSS1 value.

In the above case (and my case where I'm looking for a 9Mhz pixel 
clock), fck_div is calculated at higher than 16 - and the video output 
is wrong (i.e. no pixel clock and hsync runs at 32x the requested rate).

If I limit fclk_div_max (and hence CLKSEL_DSS1) to 16 (while preserving 
the factor of two scale for DM3730) the video comes out correctly.  I 
didn't see a mention of this in the errata at 
http://www.ti.com/litv/pdf/sprz319d

The following patch works for me, but I'm not sure its affect on other 
36x/37x parts:

Index: drivers/video/omap2/dss/dss.c
===================================================================
--- drivers/video/omap2/dss/dss.c    (revision 21206)
+++ drivers/video/omap2/dss/dss.c    (working copy)
@@ -503,7 +503,7 @@

      unsigned long fck, max_dss_fck;

-    u16 fck_div, fck_div_max = 16;
+    u16 fck_div, fck_div_max, fck_div_factor;

      int match = 0;
      int min_fck_per_pck;
@@ -552,16 +552,22 @@

          goto found;
      } else {
-        if (cpu_is_omap3630() || cpu_is_omap44xx())
+        if (cpu_is_omap3630() || cpu_is_omap44xx()) {
+            fck_div_factor = 1;
              fck_div_max = 32;
+            if (cpu_is_omap3630()) {
+                /* Limit CM_CLKSEL_DSS:CLKSEL_DSS1 to 16 */
+                fck_div_max = 16;
+            }
+        } else {
+            fck_div_factor = 2;
+            fck_div_max = 16;
+        }

          for (fck_div = fck_div_max; fck_div > 0; --fck_div) {
              struct dispc_clock_info cur_dispc;

-            if (fck_div_max == 32)
-                fck = prate / fck_div;
-            else
-                fck = prate / fck_div * 2;
+            fck = prate / fck_div * fck_div_factor;

              if (fck > max_dss_fck)
                  continue;

-- 
Peter Barada
peter.barada@logicpd.com

Re: Linux 3.0 DSS support

[Tomi Valkeinen]

Hi,

On Mon, 2011-10-24 at 13:55 -0400, Peter Barada wrote:
> 
> In the above case (and my case where I'm looking for a 9Mhz pixel 
> clock), fck_div is calculated at higher than 16 - and the video
> output 
> is wrong (i.e. no pixel clock and hsync runs at 32x the requested
> rate). 

DM37x TRM says:

"DSS1_ALWON_FCLK: Issued from DPLL4. Its frequency can be a division by
1 to 16 of the frequency of the DPLL4 synthesized clock."

I take it that DM37x is detected as cpu_is_3630()?

The DSS driver currently handles only OMAPs, so for other SoCs the
driver may contain lots of bugs like this.

 Tomi

Re: Linux 3.0 DSS support

[Peter Barada]

On 10/25/2011 03:37 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Mon, 2011-10-24 at 13:55 -0400, Peter Barada wrote:
>> In the above case (and my case where I'm looking for a 9Mhz pixel 
>> clock), fck_div is calculated at higher than 16 - and the video
>> output 
>> is wrong (i.e. no pixel clock and hsync runs at 32x the requested
>> rate). 
> DM37x TRM says:
>
> "DSS1_ALWON_FCLK: Issued from DPLL4. Its frequency can be a division by
> 1 to 16 of the frequency of the DPLL4 synthesized clock."
>
> I take it that DM37x is detected as cpu_is_3630()?
>
> The DSS driver currently handles only OMAPs, so for other SoCs the
> driver may contain lots of bugs like this.
Yes, cpu_is_omap3630() returns true on a DM3730.  I'll rework the patch
(I think all that is needed is to drop the "cpu_is_omap3630() ||" from
the test - then fck_div_max will remain at 16 for the DM3730.

-- 
Peter Barada
peter.barada@gmail.com

Re: Linux 3.0 DSS support

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]


Op 25 okt. 2011, om 09:37 heeft Tomi Valkeinen het volgende geschreven:

> Hi,
> 
> On Mon, 2011-10-24 at 13:55 -0400, Peter Barada wrote:
>> 
>> In the above case (and my case where I'm looking for a 9Mhz pixel 
>> clock), fck_div is calculated at higher than 16 - and the video
>> output 
>> is wrong (i.e. no pixel clock and hsync runs at 32x the requested
>> rate). 
> 
> DM37x TRM says:
> 
> "DSS1_ALWON_FCLK: Issued from DPLL4. Its frequency can be a division by
> 1 to 16 of the frequency of the DPLL4 synthesized clock."
> 
> I take it that DM37x is detected as cpu_is_3630()?
> 
> The DSS driver currently handles only OMAPs, so for other SoCs the
> driver may contain lots of bugs like this.

dm3730 is just a different marketing name for omap3630, it should not have any functional changes.

regards,

Koen

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Linux 3.0 DSS support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

On Thu, 2011-11-03 at 10:35 +0100, Koen Kooi wrote:
> Op 25 okt. 2011, om 09:37 heeft Tomi Valkeinen het volgende geschreven:
> 
> > Hi,
> > 
> > On Mon, 2011-10-24 at 13:55 -0400, Peter Barada wrote:
> >> 
> >> In the above case (and my case where I'm looking for a 9Mhz pixel 
> >> clock), fck_div is calculated at higher than 16 - and the video
> >> output 
> >> is wrong (i.e. no pixel clock and hsync runs at 32x the requested
> >> rate). 
> > 
> > DM37x TRM says:
> > 
> > "DSS1_ALWON_FCLK: Issued from DPLL4. Its frequency can be a division by
> > 1 to 16 of the frequency of the DPLL4 synthesized clock."
> > 
> > I take it that DM37x is detected as cpu_is_3630()?
> > 
> > The DSS driver currently handles only OMAPs, so for other SoCs the
> > driver may contain lots of bugs like this.
> 
> dm3730 is just a different marketing name for omap3630, it should not have any functional changes.

According to the TRM and experiments by Peter, it does.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Linux 3.0 DSS support

[Peter Barada]

On 11/03/2011 05:46 AM, Tomi Valkeinen wrote:
> On Thu, 2011-11-03 at 10:35 +0100, Koen Kooi wrote:
>> Op 25 okt. 2011, om 09:37 heeft Tomi Valkeinen het volgende geschreven:
>>
>>> Hi,
>>>
>>> On Mon, 2011-10-24 at 13:55 -0400, Peter Barada wrote:
>>>> In the above case (and my case where I'm looking for a 9Mhz pixel 
>>>> clock), fck_div is calculated at higher than 16 - and the video
>>>> output 
>>>> is wrong (i.e. no pixel clock and hsync runs at 32x the requested
>>>> rate). 
>>> DM37x TRM says:
>>>
>>> "DSS1_ALWON_FCLK: Issued from DPLL4. Its frequency can be a division by
>>> 1 to 16 of the frequency of the DPLL4 synthesized clock."
>>>
>>> I take it that DM37x is detected as cpu_is_3630()?
>>>
>>> The DSS driver currently handles only OMAPs, so for other SoCs the
>>> driver may contain lots of bugs like this.
>> dm3730 is just a different marketing name for omap3630, it should not have any functional changes.
> According to the TRM and experiments by Peter, it does.
Tomi,

I read Koen's comment to mean that functionally a dm3730 is the same as
a omap3630.
What I'm seeing is that the 3630 DSS hardware is more equivalent to the
OMAP3530 DSS hardware in respect to the maximum DSS F-clock divisor.

The code in the DSS clock calculation has multiple instances of:

              if (cpu_is_omap3630() || cpu_is_omap44xx())
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/video/omap2/dss/dss.c;h=3e09726d32c7ae1f5a86e51830191a09d7574955;hb=43672a0784707d795556b1f93925da8b8e797d03#l554>                      
fck_div_max = 32;

I think this should be changed to:

              if (cpu_is_omap44xx())
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/video/omap2/dss/dss.c;h=3e09726d32c7ae1f5a86e51830191a09d7574955;hb=43672a0784707d795556b1f93925da8b8e797d03#l554>                      
fck_div_max = 32;

as the code works as-is on OMAP35xx hardware.  But as I only have a
single 37xx/36xx configuration to test I don't know if other 36xx/37xx
parts allow fck_div_max to be larger than 16...

<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/video/omap2/dss/dss.c;h=3e09726d32c7ae1f5a86e51830191a09d7574955;hb=43672a0784707d795556b1f93925da8b8e797d03#l555>


-- 
Peter Barada
peter.barada@gmail.com