cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
stgateizo
Voyager
Voyager
464 Views
Registered: ‎10-07-2016

DisplayPort Rx Subsystem V2.1: Question about a ceratin interrupt handler...

Jump to solution

Dear colleagues,

in the Microblaze example code for the DisplayPort Rx Subsystem V2.1, there exists the  following interrupt routine:

static void Dprx_InterruptHandlerVideo(void *InstancePtr)

Can anybody tell me which event(s) will cause this interrupt rotuine to be called?

Actually, I'm looking for a interrupt routine, which is called, whenever the DP-source changes any input parmaeters, like the color depth, color format, horizontal and vertical resolution, framerate, etc. I have seen that the interrupt routine above is called, whenever the source chnages the color depth. But to be sure if I can use this interupt function, I need to know all evetns which will trigger this interrupt routine.

Best regards

stgateizo

0 Kudos
1 Solution

Accepted Solutions
florentw
Moderator
Moderator
383 Views
Registered: ‎11-09-2015

Hi @stgateizo 


1) What is meant with the term "valid video frame" (see bit 6 of register 0x040)?

Please refer to the description in register 0x014 (interrupt mask):

dp.PNG

2) According to the documentation, the interrupt routine "Dprx_InterruptHandlerVmChange()" is only called, when the horizontal or vertical resolution is changed, but I neede also to be informed, when the color depth (8,10,12bit), or the color format (RGB, YCbCr), or the when the framerate is changed...

You are right. I cross-checked with the development team and only the horizontal and vertical resolution are checked in the MSA. Thus it would not be the correct interrupt to watch for you.

At the moment I see more a chance to get this implemented by using the interrupt handler "Dprx_InterruptHandlerVideo()", since it is called every time when I change any video parameter, like the color format, color depth, framerate, or resoution, etc. But I'm not 100% sure if this is right way, and it depends what Xilinx means with the term "valid video frame" ?


I guess this is the right way. I do not think sync will change the color format, color depth, framerate, or resolution in a continuous stream. So they will probably stop the stream to change these settings then restart the stream so you will get a video valid interrupt.

This is of course not talking about the adaptive sync that some GPU support but which is not supported by Xilinx (AR#64732). (PS. I do not know exactly how adaptive sync is working in case you ask).

Regards


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**

View solution in original post

3 Replies
florentw
Moderator
Moderator
445 Views
Registered: ‎11-09-2015

HI @stgateizo 

Looking at the KC705 example, the Dprx_InterruptHandlerVideo interrupt handler is associated to the interrupt XDPRXSS_HANDLER_DP_VID_EVENT:

https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/dp12rxss/examples/src/kc/xdprxss_kc705.c#L2414

Which according to this file, is the interrupt related for the valid video event:

https://github.com/Xilinx/embeddedsw/blob/f975a0ea90930587ab55e4d920a31950bd373fa8/XilinxProcessorIPLib/drivers/dp12rxss/src/xdprxss.h#L136 

 This will only be asserted when there is valid video. While the interrupt you are looking at is the Video mode change:

dp2.PNG

While the interrupt you are looking at might be more Dprx_InterruptHandlerVmChange.

With that said, probably the video link is stopped when there is a change. Thus you will also get the Dprx_InterruptHandlerVideo interrupt


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
stgateizo
Voyager
Voyager
436 Views
Registered: ‎10-07-2016

Hello Florent,

thank you for this information. 2 Questions:

1) What is meant with the term "valid video frame" (see bit 6 of register 0x040)?

2) According to the documentation, the interrupt routine "Dprx_InterruptHandlerVmChange()" is only called, when the horizontal or vertical resolution is changed, but I neede also to be informed, when the color depth (8,10,12bit), or the color format (RGB, YCbCr), or the when the framerate is changed...

At the moment I see more a chance to get this implemented by using the interrupt handler "Dprx_InterruptHandlerVideo()", since it is called every time when I change any video parameter, like the color format, color depth, framerate, or resoution, etc. But I'm not 100% sure if this is right way, and it depends what Xilinx means with the term "valid video frame" ?

Regards

stgateizo

 

0 Kudos
florentw
Moderator
Moderator
384 Views
Registered: ‎11-09-2015

Hi @stgateizo 


1) What is meant with the term "valid video frame" (see bit 6 of register 0x040)?

Please refer to the description in register 0x014 (interrupt mask):

dp.PNG

2) According to the documentation, the interrupt routine "Dprx_InterruptHandlerVmChange()" is only called, when the horizontal or vertical resolution is changed, but I neede also to be informed, when the color depth (8,10,12bit), or the color format (RGB, YCbCr), or the when the framerate is changed...

You are right. I cross-checked with the development team and only the horizontal and vertical resolution are checked in the MSA. Thus it would not be the correct interrupt to watch for you.

At the moment I see more a chance to get this implemented by using the interrupt handler "Dprx_InterruptHandlerVideo()", since it is called every time when I change any video parameter, like the color format, color depth, framerate, or resoution, etc. But I'm not 100% sure if this is right way, and it depends what Xilinx means with the term "valid video frame" ?


I guess this is the right way. I do not think sync will change the color format, color depth, framerate, or resolution in a continuous stream. So they will probably stop the stream to change these settings then restart the stream so you will get a video valid interrupt.

This is of course not talking about the adaptive sync that some GPU support but which is not supported by Xilinx (AR#64732). (PS. I do not know exactly how adaptive sync is working in case you ask).

Regards


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**

View solution in original post