• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 537 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP3530 analog SVGA video out - DSS driver

John F.
Intellectual 830 points


Hello,

I have a custom 3530 board with a video DAC for SVGA out, in place of the LCD found on the EVM.  As a quick experiment, I modified the Linux 2.6.29 file drivers/video/omap2/panel-sharp-ls037v7dw01.c used for the EVM to change resolution and timings and also experimented with the sysfs interface described in linux Documentation/arm/OMAP/DSS.  I did get barely-visible, almost black video out for VGA and SVGA at different refresh rates, but what's the right way to add a new DSS device?  Is hijacking or emulating the LCD driver the wrong approach to take eventough the electrical interface is similar?

 

Thanks!

,

John

  • 0
    TI__Mastermind 41665 points

    John F. said:
    I did get barely-visible, almost black video out for VGA and SVGA at different refresh rates, but what's the right way to add a new DSS device?  Is hijacking or emulating the LCD driver the wrong approach to take eventough the electrical interface is similar?

    This is one way to do it, and it works fine if you are not all too concerned about portability and pushing your code back into the Linux community, though as you imply it is sort of a hack. In general you probably want to make a new C file similar to panel-sharp-ls037v7dw01.c but that is specific to your particular video DAC (i.e. my-particular-video-DAC.c) and than modify the display driver code elsewhere to make your new DAC as an option. I would probably start the way you have using the LCD code as a base but in addition to modifying the panel-sharp-ls037v7dw01.c file I would rename it and leave the original in tact and eventually you will have your own hardware specific C file that fits in well with the rest of the code base.

  • 0 in reply to Bernie Thompson TI
    Intellectual 830 points

    Thanks for the response.

    I agree that we should use a new file for our DAC, but my question was more about if a video DAC was fundamentally different from the LCD panel driver-wise.  For example, the omap_panel .config field for the sharp panel has OMAP_DSS_LCD_TFT  etc. bits set.   Does the OMAP display controller do anything LCD-specific with these settings?  I assume the dispc does not care if the RGB data lines go to a DAC with analog out.  I think I have sensible values for resolution, pixel clock, and the other 6 timing numbers (vert and horizontal front porch, back porch, sync), but was wondering if I was in the wrong area of the kernel from a high level.

     

    Thanks,

    John

     

  • 0 in reply to John F.
    TI__Mastermind 41665 points

    John F. said:
    I agree that we should use a new file for our DAC, but my question was more about if a video DAC was fundamentally different from the LCD panel driver-wise.

    I don't really see them as being that different myself, you have the same dependencies on higher level display controller code and buffers, it uses the same physical interface, and as you have proven with your modification the difference between a LCD and a DAC is not very large from the perspective of the display controller or of the driver.

    John F. said:
    For example, the omap_panel .config field for the sharp panel has OMAP_DSS_LCD_TFT  etc. bits set.   Does the OMAP display controller do anything LCD-specific with these settings? 

    The display controller has modes that are specific to LCDs for various timing needs as discussed in detail in chapter 15 of the OMAP3 TRM, so there are bits in there that are specific to LCDs, however they are part of the same register set/peripheral that you use to display to a generic device like a DAC. Since this is all the same peripheral there are shared structures and code for the display interface subsystem that apply to any video display you would be handling, so it makes sense to me at least to put the code for the DAC in place of the LCD.

    John F. said:
    I think I have sensible values for resolution, pixel clock, and the other 6 timing numbers (vert and horizontal front porch, back porch, sync), but was wondering if I was in the wrong area of the kernel from a high level.

    I think you are in the right place, at least this would be my opinion, where you put it in the end is really up to you, if your concern is getting the code accepted upstream by the Linux kernel community than you may want to consult them for comments on where your new C file should go.