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

media controller in 2.6.37 kernel on DM365

Jan Pohanka
Expert 1310 points

Hello,

I'm working with kernel mentioned in the subject and I discovered that the current implementation lacks support for B channel of the resizer and in the driver code there are only TODO marks. (http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=4e8cff0882489f26483891857aab9fe0f38b8b82)

We need to use channel B in our application so I implemented an ugly hack which places the second resizer output to a hardcoded offset after the channel A, but this is really nasty and just for our development phase.

I have tried to contact Nagabhushana Netagunte because according to the git log he is author of the majority of the mc implementation for dm365 to discuss the correct implementation, but it seems that his mail is not available anymore.

Is here please anybody who is aware of the resizer driver implementation and could propose the "right way" how to handle channel B output? Is it planned to add a new entity representing rsz B? Even there is some function prepared I can't deduce the proper architecture from the current source code.


with best regards
Jan Pohanka 

  • 0
    Guru 11260 points

    Hi Jan,

    Yes the resizer -b support for 2.6.37 release is missing.

    This branch here it has the resizer-b support working http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/shortlog/refs/heads/vpfe_3.7_pull

    This is my working branch I have been changing lots of stuff  and is very much different from 2.6.37. This branch is based on 3.7 kernel.

    I am in final stages to code freeze hopefully by next week it should be done, Once done I'll inform you.

    Regards,

    --Prabhakar Lad

  • 0 in reply to Prabhakar Lad
    Expert 1310 points

    Hi Prabhakar,

    please take a look at this thread http://e2e.ti.com/support/embedded/linux/f/354/t/223215.aspx

    Renjith helped me a lot when fighting with the issue described there and I believe, that the source of all evil is in incorrect settings of INTSEL2 register, which is hardcoded in vpfe driver (vpss.c). I have checked your sources and the situation is the same. Could you fix it, please? If you need, I can send you a patch.

    regards
    Jan

  • 0 in reply to Jan Pohanka
    Guru 11260 points

    Hi Jan,

    You mean by setting the INTSEL1 register from 0x0b1f0100 to 0x0e1f0100 fixed the issue ?

    Can attach the changes ?

    Regards,

    --Prabhakar Lad

  • 0 in reply to Prabhakar Lad
    Expert 1310 points

    I'm talking about INTSEL2[12:8]

    Change of INTSEL2 from 0x1f0a0f1f to 0x1f0a0e1f helped. It should be confirmed from somebody from TI but 0x0f is marked as a reserved value in the datasheet.

    regards
    Jan

     

     

  • 0 in reply to Jan Pohanka
    Guru 11260 points

    Hi Jan,

    Change of INTSEL2 from 0x1f0a0f1f to 0x1f0a0e1f helped. It should be confirmed from somebody from TI but 0x0f is marked as a reserved value in the datasheet.

    0x0f--> I believe it is RSZ_INT_DMA :

    is issued when the RSZ SDRAM (both resize-A and resize-B) transfer is done. On this
    timing, RSZ_EOF is sent to BL.

    Regards,

    --Prabhakar Lad

  • 0 in reply to Prabhakar Lad
    Expert 1310 points

    Prabhakar Lad said:
    0x0f--> I believe it is RSZ_INT_DMA :

    Then the the table in register description in the userguide is wrong and should be updated. On the other hand driver using RSZ_INT_DMA does not work well on my site but RSZ_INT_LAST_PIX make it better.

     

  • 0 in reply to Jan Pohanka
    Guru 11260 points

    Hi Jan,

    Then the the table in register description in the userguide is wrong and should be updated.

    Yes the document needs to be updated.

    On the other hand driver using RSZ_INT_DMA does not work well on my site but RSZ_INT_LAST_PIX make it better.

    RSZ_INT_DMA is actually the completion interrupt that is triggered when the complete

    output frame is written to DDR. This is not really related to the actual VSYNC of pixel clock.

    BTW have you done any modification to code apart from this ? which evm are you using dm365/368 ?

    what is the ARM and DDR frequency?

    Regards,

    --Prabhakar Lad


  • 0 in reply to Prabhakar Lad
    Expert 1310 points

    Prabhakar Lad said:
    BTW have you done any modification to code apart from this ? which evm are you using dm365/368 ?

    I have done a lot of modification as I work on custom hardware with DM365, the design is based on evm but there is a lot of changes. All evm examples used bayer raw sensor, we use YUV.

    Prabhakar Lad said:
    what is the ARM and DDR frequency?

    core: 297Mhz, DDR: 270Mhz, peripherals: 135MHz