• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 97 subscribers
  • Views 932 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.

How do I modify decode demo to output VGA (640x480 60Hz) using DM6467 and THS8200?

Helmut Forren
Mastermind 6805 points
Other Parts Discussed in Thread: THS8200, THS7303

I have a custom DM6467 board derived from the EVM, including a THS8200 for output. 

In the past, I've successfully modified the decode demo in order to output NTSC through an ADV7171 video encoder.  It's a greatly simplified program, called splash, that simply displays a full screen in single color.

With this new board, the ADV7171 has been replaced by the THS8200, per DM6467 EVM example.

I find myself again modifying the decode demo source file main.c (starting from my working splash example). 

SHORT QUESTION:

How do I configure things in my high level program to make the THS8200 start generating VGA (640x480 60Hz)?  Will I need to (yet again) modify the DMAI or other source code, or is it already setup for this capability:

LONG QUESTION:

In gory detail...

I've set my video standard to "VideoStd_VGA" and have tried color space of either it's prior unchanged value of "ColorSpace_YUV422PSEMI" or its new intended value of "ColorSpace_RGB565".

With "VideoStd_VGA" and "ColorSpace_RGB565", my console output includes the following.  I'm not sure how much of it is germane.  I believe the red part is important.

Call Enable_Display()
@0x000946c2:[T:0x40bd6490] ti.sdo.dmai - [BufTab] Allocating BufTab for 3 buffers
@0x000947b3:[T:0x40bd6490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 614400 at 0x40e99000 (0x87e6d000 phys)
@0x00094993:[T:0x40bd6490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 614400 at 0x40ffc000 (0x87d0a000 phys)
@0x00094ab3:[T:0x40bd6490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 614400 at 0x4115f000 (0x87ba7000 phys)
@0x0009663c:[T:0x40bd6490] ti.sdo.dmai - [Dmai] VIODIC_QBUF failed (Invalid argument)
Failed to intialize display driver buffers on /dev/video2

Seeing the "invalid argument", I thought it might have been the color space.  But when I changed to "ColorSpace_RGB565", my console output includes the following.  This failure is even earlier than the above, so if the color space was the cause of the above, the error below shows I have multiple places to fix.  Note I believe this error below ends up coming out of the decode demo's file display.c call to function BufferGfx_calcDimensions().

Display thread running
@0x0006e044:[T:0x40bd6490] ti.sdo.dmai - [ColorSpace] Unknown color space format (4)
Error: Failed to calculate dimensions of video standard
Display thread: cleanup

Is it possible that DMAI simply hasn't been coded yet to support 'ColorSpace_RGB565", even though the enumerated value was defined?  Is it possible that DMAI simply hasn't been coded yet to support "VideoStd_VGA", even though the enumerated value was defined?  My file system search does turn up dvsdk_3_10_00_11/dmai_2_10_00_05/packages/ti/sdo/dmai/apps/video_display/linux/main.c that refers to "VideoStd_VGA" as a parameter and would imply that, if that program was ever fully tested, then the lower level support should be there.  But hunting around in that source code directory reveals nothing more.

I'm going to keep searching, but go ahead and post what I have so far here.  Perhaps someone can answer this outright, or at least guide me in a different or more detailed direction, before I stumble into the answer myself!

Thanks very much,

Helmut

  • 0
    Mastermind 6805 points

    ...FYI, prior to all this, I established that "VideoStd_D1_NTSC" with "ColorSpace_YUV422PSEMI" ran through successfully, generating video output that seemed valid when I probed the output with a scope.  (I didn't want to push the wrong signal into a VGA monitor yet.)  So, in general, my code works.  And 'VideoStd_D1_NTSC" works.  I am just having trouble getting "VideoStd_VGA" to work.

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    ...OK, there was a resource snafu causing the prior error seemingly associated with buffer allocation.  I logged off and back in again, and got past that error.

    Now, with "VideoStd_VGA" and "ColorSpace_YUV422PSEMI", I still get the following:

    @0x01ab44ff:[T:0x40bd6490] ti.sdo.dmai - [Display] Display_detectVideoStd() about to loop...
    @0x01ab4542:[T:0x40bd6490] ti.sdo.dmai - [Display] Output being checked: index=0 (seeking=Component)
    @0x01abdf78:[T:0x40bd6490] ti.sdo.dmai - [Display] Output detected found=Composite (seeking=Component)
    @0x01abdfe0:[T:0x40bd6490] ti.sdo.dmai - [Display] Output being checked: index=1 (seeking=Component)
    @0x01ac7e07:[T:0x40bd6490] ti.sdo.dmai - [Display] Output detected found=Component (seeking=Component)
    @0x01acaeef:[T:0x40bd6490] ti.sdo.dmai - [Display] VIDIOC_S_STD failed on /dev/video2 (Invalid argument)
    @0x01acaf55:[T:0x40bd6490] ti.sdo.dmai - [Display] Display_detectVideoStd Failed
    Error: Failed to create display device

    This appears at the same place in the log where the successful run of "VideoStd_D1_NTSC" and "ColorSpace_YUV422PSEMI" produces:

    @0x01ab44ef:[T:0x40bd6490] ti.sdo.dmai - [Display] Display_detectVideoStd() about to loop...
    @0x01ab4531:[T:0x40bd6490] ti.sdo.dmai - [Display] Output being checked: index=0 (seeking=Composite)
    @0x01abdf7b:[T:0x40bd6490] ti.sdo.dmai - [Display] Output detected found=Composite (seeking=Composite)
    @0x01ad1949:[T:0x40bd6490] ti.sdo.dmai - [Display] Display Output set to Composite; Display Standard is set to 5

    Obviously, I have some trace messaged that I believe I put in their many months ago.  This loop is searching.  The working occurrence finds composite (not component) output capability at index 0, then goes with it.  The failing occurrence finds component output capability at index 1, and fails trying to go with it.  I don't recall right now what the index indexes.  I only have one video output chip, the THS8200.  The index must be for something else.  I'll look into that.  Note that the working case DOES produce output on the THS8200 output pins, so it must be [indirectly, I believe] finding that chip properly.  I really need to know what the index is indexing...

     

     

     

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    The error "[Display] VIDIOC_S_STD failed on /dev/video2 (Invalid argument)" above comes from code in dvsdk_3_10_00_11/dmai_2_10_00_05/packages/ti/sdo/dmai/linux/Display_v4l2.c that reads:

    std = stds[attrs->videoStd]
    if(ioctl(fd, VIDIOC_S_STD, &std)) {
    ... 

    where the stds[] array maps the videoStd defined by .../dmai/VideoStd.h into a new mapping, evidently used by v4l2:

    static v4l2_std_id stds[VideoStd_COUNT] = { 0, 0, 0, 0, 0, V4L2_STD_NTSC,
        V4L2_STD_PAL, V4L2_STD_525P_60, V4L2_STD_625P_50, V4L2_STD_720P_60, 
        V4L2_STD_720P_50, 0, V4L2_STD_1080I_60, V4L2_STD_1080I_50, 
        0, 0, 0, V4L2_STD_1080P_60, V4L2_STD_1080P_50 };

    Lo and behold, "VideoStd_VGA" is a 4, which is mapped to 0 in this array.  In essence, "VideoStd_VGA" has not been implemented.  Meanwhile, the "VideoStd_D1_NTSC" that worked is a 5, that this array maps to V4L2_STD_NTSC.
    So now it seems I have to go into V4L2 and see if it's reasonable to modify it to support VGA...
    But HELP, I see other folks referencing that they output VGA.  Did they bypass V4L2?  How did they do it?

     

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    ...in git/drivers/media/video/davinci/vpif_display.c I find the ioctl being handled by function vpif_s_std() which calls vpif_get_std_info() which references array ch_params[].

    The ch_params[] array is hard coded in the same vpif_display.c with entries seeming to match the stds[] mapping array mentioned in my prior post on this thread.  VGA is nowhere to be found.  I'm thinking now that I have to add a new array entry, figure out the values, percolate the change up through stds[] mapping, etc...

    Is there a better way?

    Here's ch_params[]:

    static const struct vpif_channel_config_params ch_params[] = {

    {

    "NTSC", 720, 480, 30, 0, 1, 268, 1440, 1, 23, 263, 266,

    286, 525, 525, 0, 1, 0, V4L2_STD_525_60, 27000000

    },

    {

    "PAL", 720, 576, 25, 0, 1, 280, 1440, 1, 23, 311, 313,

    336, 624, 625, 0, 1, 0, V4L2_STD_625_50, 27000000

    },

    {

    "1080P60", 1920, 1080, 60, 1, 0, 272, 1920, 1, 42, 1122, 0,

    0, 0, 1125, 0, 0, 1, V4L2_STD_1080P_60, 148000000

    },

    {

    "720P-60", 1280, 720, 60, 1, 0, 362, 1280, 1, 26, 746, 0,

    0, 0, 750, 0, 0, 1, V4L2_STD_720P_60, 74250000

    },

    {

    "720P-50", 1280, 720, 50, 1, 0, 692, 1280, 1, 26, 746, 0,

    0, 0, 750, 0, 0, 1, V4L2_STD_720P_50, 74250000

    },

    {

    "1080I-30", 1920, 1080, 30, 0, 0, 272, 1920, 1, 21, 561, 564,

    584, 1124, 1125, 0, 0, 1, V4L2_STD_1080I_60, 74250000

    },

    {

    "1080I-25", 1920, 1080, 25, 0, 0, 712, 1920, 1, 21, 561, 564,

    584, 1124, 1125, 0, 0, 1, V4L2_STD_1080I_50, 74250000

    },

    {

    "480P-60", 720, 480, 60, 1, 0, 130, 720, 1, 43, 525,

    0, 0, 0, 525, 0, 0, 0, V4L2_STD_525P_60, 27000000

    },

    {

    "576P-50", 720, 576, 50, 1, 0, 136, 720, 1, 45, 621,

    0, 0, 0, 625, 0, 0, 0, V4L2_STD_625P_50, 27000000

    }

    };

     

     

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    ...note ch_params[] has values corresponding to vpif_channel_config_params defined in git/drivers/media/video/davinci/vpif.h:

    struct vpif_channel_config_params {

    char name[VPIF_MAX_NAME]; /* Name of the mode */

    u16 width; /* Indicates width of the image */

    u16 height; /* Indicates height of the image */

    u8 fps;

    u8 frm_fmt; /* Indicates whether this is interlaced

    * or progressive format */

    u8 ycmux_mode; /* Indicates whether this mode requires

    * single or two channels */

    u16 eav2sav; /* length of sav 2 eav */

    u16 sav2eav; /* length of sav 2 eav */

    u16 l1, l3, l5, l7, l9, l11; /* Other parameter configurations */

    u16 vsize; /* Vertical size of the image */

    u8 capture_format; /* Indicates whether capture format

    * is in BT or in CCD/CMOS */

    u8  vbi_supported; /* Indicates whether this mode

    * supports capturing vbi or not */

    u8 hd_sd;

    v4l2_std_id stdid;

    u32 clk_rate; /* Pixel clock required for

      this mode */

    };

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    ...meanwhile, from the bottom up, I find git/drivers/media/video/ths8200.c driver with enum ths8200_modes including THS8200_VESA_MASTER and THS8200_VESA_SLAVE.

     Later, struct ths8200_mode_info mode_info[] array decleared, including blocks of config data, which contains as data a reference to ths8200_modes values, but doesn't have entries for THS8200_VESA_MASTER or THS8200_VESA_SLAVE.  In fact, THS8200_VESA* is not reference anywhere else in this driver source file.  It seems like it was envisioned, but never implemented.  (EDIT: MASTER and SLAVE modes taken from THS8200 datasheet)

    I think I may need to implement one, although I don't know the difference in MASTER and SLAVE, and then connect this mode to the higher V4L2 level I was analyzing top down before jumping to bottom up...

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    ...by this point, I find myself updating the drivers for both the THS8200 (to configure VGA, but haven't gotten to it yet because of THS7303) and THS7303 (setting filter off, as previously advised a long time ago on some other thread)

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    Help never came on the forum...  :(

    I got it working on my own, although a few days late: