Dear Alex,
> I think it would be better to add a quirk flag and only do the
> extended probe on specific boards where it is required. E.g.,
>
> if (radeon_connector->requires_extended_probe)
> radeon_ddc_probe_extended();
> else
> radeon_ddc_probe();
>
> Alex
Today, I updated the patch
Dear Alex,
> I think it would be better to add a quirk flag and only do the
> extended probe on specific boards where it is required. E.g.,
>
> if (radeon_connector->requires_extended_probe)
> radeon_ddc_probe_extended();
> else
> radeon_ddc_probe();
>
> Alex
Today, I updated the patch
Dear Alex,
> This is going to enable your quirk on every board with an HDMI port.
> If we need to add a quirk for your board, let's make it board
> specific. It might be better to just disable edid polling for certain
> connectors on certain boards if they cause problems when no monitor is
> det
Hallo Thomas,
On Wed, 22 Jun 2011 03:11:24 +0200, Thomas Reim wrote:
> Salut Jean,
>
> thank you for the detailed reply. If I got you right you rose the
> following main points:
> 1. Root cause leading to flooding problem (you assume i2c bus not
>working correctly, i. e. "stuck bus") not ad
On Wed, Jun 22, 2011 at 11:17 AM, Thomas Reim wrote:
> Dear Alex,
>
>> This is going to enable your quirk on every board with an HDMI port.
>> If we need to add a quirk for your board, let's make it board
>> specific. ?It might be better to just disable edid polling for certain
>> connectors on ce
On Wed, Jun 22, 2011 at 11:17 AM, Thomas Reim wrote:
> Dear Alex,
>
>> This is going to enable your quirk on every board with an HDMI port.
>> If we need to add a quirk for your board, let's make it board
>> specific. ?It might be better to just disable edid polling for certain
>> connectors on ce
On Wed, Jun 22, 2011 at 11:17 AM, Thomas Reim wrote:
> Dear Alex,
>
>> This is going to enable your quirk on every board with an HDMI port.
>> If we need to add a quirk for your board, let's make it board
>> specific. It might be better to just disable edid polling for certain
>> connectors on ce
On Wed, Jun 22, 2011 at 11:17 AM, Thomas Reim wrote:
> Dear Alex,
>
>> This is going to enable your quirk on every board with an HDMI port.
>> If we need to add a quirk for your board, let's make it board
>> specific. It might be better to just disable edid polling for certain
>> connectors on ce
Dear Alex,
> This is going to enable your quirk on every board with an HDMI port.
> If we need to add a quirk for your board, let's make it board
> specific. It might be better to just disable edid polling for certain
> connectors on certain boards if they cause problems when no monitor is
> det
Hallo Thomas,
On Wed, 22 Jun 2011 03:11:24 +0200, Thomas Reim wrote:
> Salut Jean,
>
> thank you for the detailed reply. If I got you right you rose the
> following main points:
> 1. Root cause leading to flooding problem (you assume i2c bus not
>working correctly, i. e. "stuck bus") not ad
From: Thomas Reim
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid() and drm_edid_block_valid()
periodically dump data and kernel errors into system
log files and onto
Salut Jean,
thank you for the detailed reply. If I got you right you rose the
following main points:
1. Root cause leading to flooding problem (you assume i2c bus not
working correctly, i. e. "stuck bus") not adequately addressed by
the fix
2. Alternative proposal: Fix the verbose loggin
On Tue, Jun 21, 2011 at 9:20 PM, wrote:
> From: Thomas Reim
>
> Some integrated ATI Radeon chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid() and drm_edid_block_valid()
> periodically dump
Hi Thomas,
On Tue, 21 Jun 2011 17:31:45 +0200, Thomas Reim wrote:
> Some integrated ATI Radeon chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid and drm_edid_block_valid
> periodically dump
Dear Alex,
yes, the proposed fix should also fix the 'drm/radeon: workaround a hw
bug on some radeon chipsets with all-0 EDIDs.' issue. The trick is, that
we check within the Radeon domain directly on i2c interface level, if an
EDID can be retrieved at all, before we hand over to the main drm edi
On Tue, Jun 21, 2011 at 9:20 PM, wrote:
> From: Thomas Reim
>
> Some integrated ATI Radeon chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid() and drm_edid_block_valid()
> periodically dump
From: Thomas Reim
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid() and drm_edid_block_valid()
periodically dump data and kernel errors into system
log files and onto
Salut Jean,
thank you for the detailed reply. If I got you right you rose the
following main points:
1. Root cause leading to flooding problem (you assume i2c bus not
working correctly, i. e. "stuck bus") not adequately addressed by
the fix
2. Alternative proposal: Fix the verbose loggin
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid and drm_edid_block_valid
periodically dump data and kernel errors into system
log files and onto terminals, which lead t
Hi Thomas,
On Tue, 21 Jun 2011 17:31:45 +0200, Thomas Reim wrote:
> Some integrated ATI Radeon chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid and drm_edid_block_valid
> periodically dump
On Tue, Jun 21, 2011 at 11:31 AM, Thomas Reim wrote:
> Some integrated ATI Radeon ?chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid and drm_edid_block_valid
> periodically dump data and kern
Dear Alex,
yes, the proposed fix should also fix the 'drm/radeon: workaround a hw
bug on some radeon chipsets with all-0 EDIDs.' issue. The trick is, that
we check within the Radeon domain directly on i2c interface level, if an
EDID can be retrieved at all, before we hand over to the main drm edi
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid and drm_edid_block_valid
periodically dump data and kernel errors into system
log files and onto terminals, which lead t
On Tue, Jun 21, 2011 at 11:31 AM, Thomas Reim wrote:
> Some integrated ATI Radeon chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid and drm_edid_block_valid
> periodically dump data and kern
24 matches
Mail list logo
