HDMI HPD query and state change notification

Hi,

We agree with the problem, to solve it we are planning following design,

HDMI audio is controlled by ALSA framework, HDMI video is controlled by HDMI driver which is part of VPSS driver. When HPD event happens HDMI video driver re-negotiates with Sink on the HDMI and DVI capabilities and sets the mode accordingly. But for re-negotiation HDMI IP needs to be turned off. This event can’t be notified to ALSA framework since it’s not a part of VPSS driver. So ALSA still keeps on pumping data but since HDMI IP is turned off we get underflow errors.

Solution:

Solution to above problem is to provide blocking ioctl from the HDMI video driver, This ioctl will be unblocked once the HPD event is detected, ioctl parameters will tell whether cable connect or cable disconnect even happened. Once ioctl is un-blocked, application needs to do following.

1. On cable disconnect
   1. Stop Audio play
   2. Turn off HDMI
2. On cable connect
   1. Read EDID
   2. Determine HDMI or DVI based on EDID
   3. Turn on HDMI video
   4. Turn on Audio if HDMI sink is detected else don’t turn on Audio if DVI sink is detected.

Driver will not do anything in case ioctl is not handled in application, It will keep on doing whatever it was doing before HDP.

Regards,

Hardik Shah

Hello Hardik,

Your proposed solution sounds good, especially since it also recognizes that possibility of application control over HDMI/DVI mode, and application analysis of EDID (for adjusting output resolution to the best timing, etc.).  So many thanks.

While I'm fine with a blocking ioctl, but you might consider also supplying a sysfs type of interface too.  (Just HPD state, or state and state change count?)  Then, a C program could use poll() or select() to watch for changes.  It's just a thought, if TI is desirous of encouraging use of sysfs over ioctl().

Can you tell me when we can expect these changes?

Also: we use both 816x and 814x, so I put the same issue in both forums.  Is that okay, or should I stick to just one or the other?

Thanks,

Dan -

Hi,

Yes let me think over providing the current HDP status as sysfs entry. This should be part of next EZSDK release. You can mute other thread on 814x. This will be taken care off  for both.

Regards,

Hardik Shah

Hi Hardik,

When is the next EZSDK coming out? We would like this feature because when I new monitor is plugged in the DM8168 should automatically set the video output to the native resolution.

Thanks,

Ralph

Hi,

This needs to be taken care in application, where application has to do following things.

1. Call GET_HPD_Status ioctl periodically. Refer to ti81xxhdmi.h in include/linux folder

2. If this returns HPD event, application needs to read EDID

3. Find out  native resolution supported by display

4. Stop full chain

5. Reconfigure the chain for new display.

All of the above steps cant be done in driver.

I looked at the HDMI driver and saw there was an interrupt that is registered called "TI81XX_IRQ_HDMIINT".

When is this interrupt triggered? I was hoping it would be triggered upon hot plug detect....

Ralph

Just found out that this interrupt IS called when a new monitor is plugged in.

So TI could, if they wanted, create a suitable way of setting the resolution correctly when a monitor was plugged in. All you would have to do is from kernel space, wait until the interrupt fires, read the EDID and then set the resolution. Easy.

I'll end up doing it myself if TI doesn't. Will TI be implementing this? In a worst case you could have an IOCTL to allow the user to choose if they wanted the output resolution automatically set for them by the driver or not.

Ralph

Hi,

Switching off the display and switching it on again is not in scope of driver. This is because many pipelines may be connected to same encoder like Grpx and Video may be connected to same encoder. Now switching off encoder without stopping data flow from upstream pipelines like Grpx and Video will result in underflow of compositor. Further application knows where each pipeline is connected. So based on HPD detect, application has to take following actions.

1. Stop all upstream pipelines like grpx and video.

2. Stop Venc

3. Read the EDID

4. Find out best resolution.

5. Reconfigure all pipelines for new resolution.

6. Start all pipelines.

Hi Hardik,

Thanks for the tips. If/when I implement this in our driver I'll have a good handle on what I need to do.

Ralph

Hardik,

Is the new HPD blocking ioctl still on track to be included in the next EZSDK, as you said on May 24?

Thanks,

Dan -

Hi,

This is already pushed to arago.

commit

Regards,

Hardik Shah