Re: [PATCH] drm/radeon: fix AVI infoframe generation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jun 8, 2013 at 7:46 AM, Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
> 2013/6/7  <alexdeucher@xxxxxxxxx>:
>> From: Alex Deucher <alexander.deucher@xxxxxxx>
>>
>> - remove adding 2 to checksum, this breaks certain monitors
>> - properly emit the AVI infoframe version, not emitting
>> the version breaks some monitors.
>>
>> This should fix blank screen when HDMI audio is enabled on
>> certain monitors.
>
> Err, nack. I believe this it actually going to *break* some monitors
> compatibility.

Yeah, it seems to break as many as it fixes :(

>
> For some unknown reason AMD hardware uses 0x81 and 0x01 for type and
> version of infoframe. See this comment (written/published by you):
> /* The following packets and infoframes are required for HDMI:
>  * Packets:
>  * 0x00 - Null packet
>  * 0x01 - Audio clock regen
>  * 0x02 - Audio sample
>  * 0x03 - General Control
>  * Infoframes:
>  * 0x81 0x01 - AVI
>  * 0x83 0x03 - audio
>  */
>
> As you can see, AMD hardware uses 0x81 and 0x01. I've no idea why,
> according to the HDMI standard it should be 0x82 and 0x02. All other
> vendors seems to also use 0x82 and 0x02. In function
> hdmi_avi_infoframe_init type it set to 0x82 and 0x02.


The internal afmt validation code I've seen uses 0x82 and 0x2 (for
DCE4 and newer asics, I'm not sure what we do for older versions), so
I think it may depend on the monitor and the GPU hardware.  We may
need to add some logic to determine what version to send based on the
monitor's caps.

>
> This type and version it's written anywhere, but they are used to
> calculate checksum. Checksum it what we store is frame[0x0]. We
> calculate checksum as 0x100 - sum (see hdmi_infoframe_checksum).
>
> Now... with common drm code we use 0x82 and 0x02 instead of 0x81 and
> 0x01. It means our "sum" is too big by 0x02. It means we have to use
> 0x100 - sum + 0x02 as checksum for AMD hardware.
>

It would probably be cleaner to just adjust the header and version
before calling hdmi_avi_infoframe_pack() so we don't have to add the
hack.

Alex

> This whole hack was introduced in 92db7f6c860b8190571a9dc1fcbc16d003422fe8:
> drm/radeon/kms: workaround invalid AVI infoframe checksum issue
> and I'm pretty sure it was verified to fix somebody's HDMI mode. It
> also seems to be compatible with AMD specs (at least the part of it we
> can see in the quoted comment).
>
> For proof of fglrx doing the same, please see my e-mail where I
> provided dumps from registers when using fglrx:
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017717.html
> (it was tested on 5 different cards!).
>
> When working on that patch I was talking & debugging with few people
> on IRC. That mean I don't have logs anymore, but I'm sure I was
> testing exactly that single value and it was immediately fixing
> selected displays. I mean testing by writing something like:
>
> avivotool regset 0x10884 0x00a85e4f
> vs.
> avivotool regset 0x10884 0x00a85e4d
>
> --
> Rafał
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux