Hi,
I'd like to report a bug in the intel_hdmi21 driver as of Quartus Pro 23.2
See: intelFPGA_pro/23.2/ip/altera/altera_hdmi/hw_demo/common/software/software_driver/intel_hdmi21_tx/src/intel_hdmi21_tx_edid.c
Consider the following function:
int intel_hdmi21_tx_edid_get_sink_status(intel_hdmi21_tx_instance_t* instance, uint8_t* edid_header_valid, uint32_t* edid_size)
{
if (instance == NULL)
return intel_hdmi_invalid_instance;
if((edid_header_valid == NULL) || (edid_size == NULL))
return intel_hdmi_invalid_arguments;
uint32_t headerSize = 8;
(*edid_header_valid) = 1;
(*edid_size) = 0;
for(uint32_t i = 0; i < headerSize; i++)
{
uint8_t val = edid_read_sink_reg(i);
(*edid_header_valid) &= (((i == 0 || i == (headerSize - 1)) && val == 0) || (val == 0xFF)) ? 1 : 0;
}
if((*edid_header_valid))
{
const uint32_t numberOfExtensionsOffset = 126;
uint32_t numberOfExtensions = edid_read_sink_reg(numberOfExtensionsOffset);
(*edid_size) = (numberOfExtensions + 1) * INTEL_HDMI_EDID_BLOCK_SIZE;
}
return intel_hdmi_success;
}
The edid_head_valid check on 14 should only pass on a valid on the EDID header pattern of "00 FF FF FF FF FF FF 00". However, but will also pass a pattern of all 0xFF or a 0xFF in the first or last position due to the second logical OR in the expression.
Passing on all 0xFF is especially problematic as reading a I2C bus with an non-responding EDID device returns 0xFF for every byte. The result of the failure is that the header is declared valid and the EDID size is reported as 128 * 255.
The expected behavior is that the valid flag will be set properly.
Please let me know if there is a more appropriate place to report issues against the Intel FPGA BSP drivers.
Thank you,
David
Hi David,
Thank you for your patience.
Based on the discussion with our internal team, I believe that this is a bug and your concern is correct.
I will reported this to our internal team to be fix in future release.
This fix that you suggested is a valid fix/workaround for this issue.
Thank you.
Best Regards,
ZulsyafiqH_Intel
連結已複製
A possible fix would be to change:
(*edid_header_valid) &= (((i == 0 || i == (headerSize - 1)) && val == 0) || (val == 0xFF)) ? 1 : 0;
to
(*edid_header_valid) &= (((i == 0 || i == (headerSize - 1))) ? (val == 0) : (val == 0xFF)) ? 1 : 0;
Hi David,
Thank you for reaching out.
Just to let you know that Intel has received your support request and currently we are confirming the details with our internal team.
I shall come back to you with findings.
Thank you for your patience.
Best Regards,
ZulsyafiqH_Intel
Hi David,
Thank you for your patience.
Based on the discussion with our internal team, I believe that this is a bug and your concern is correct.
I will reported this to our internal team to be fix in future release.
This fix that you suggested is a valid fix/workaround for this issue.
Thank you.
Best Regards,
ZulsyafiqH_Intel
Hi David,
I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread.
Thank you.
Best Regards,
ZulsyafiqH_Intel
