Message ID | s5hvat0ftsf.wl-tiwai@suse.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>>>>> +#define AUD_PORT_EN_B_DBG 0x62F20 >>>>> +#define AUD_PORT_EN_C_DBG 0x62F28 >>>>> +#define AUD_PORT_EN_D_DBG 0x62F2C >>> These match the spec. But to match the standard i915 convention they >>> should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit >>> register. >> Actually they just match one version of the spec I had lying around. >> Another versions says: >> >> AUD_PORT_EN_B_DBG 0x62F20 >> AUD_PORT_EN_C_DBG 0x62F30 >> AUD_PORT_EN_D_DBG 0x62F34 > That's it! Now finally I can hear the audio from DP3 with the > additional patch below. Wow. Thanks Ville for looking into this, we could have lost a lot of time. Do you happen to know if those previous values are due to poor documentation or a different skew we'd need to support, e.g. with a PCI-Id quirk? At any rate, 2 days to get DP audio working is pretty nice, this was a good week.
On Fri, Jan 27, 2017 at 08:55:19AM -0600, Pierre-Louis Bossart wrote: > > > >>>>> +#define AUD_PORT_EN_B_DBG 0x62F20 > >>>>> +#define AUD_PORT_EN_C_DBG 0x62F28 > >>>>> +#define AUD_PORT_EN_D_DBG 0x62F2C > >>> These match the spec. But to match the standard i915 convention they > >>> should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit > >>> register. > >> Actually they just match one version of the spec I had lying around. > >> Another versions says: > >> > >> AUD_PORT_EN_B_DBG 0x62F20 > >> AUD_PORT_EN_C_DBG 0x62F30 > >> AUD_PORT_EN_D_DBG 0x62F34 > > That's it! Now finally I can hear the audio from DP3 with the > > additional patch below. > Wow. Thanks Ville for looking into this, we could have lost a lot of > time. Do you happen to know if those previous values are due to poor > documentation or a different skew we'd need to support, e.g. with a > PCI-Id quirk? No idea really. You should really test this on both CHV and VLV with all possible port/pipe combinations to make sure we got it right. I trust these VLV/CHV docs about as much as I trust most politicians. Alternatively you could just read all those regs on both platforms and see if the values you get from them conform to any visible pattern that could tell us which offsets are the correct ones. They might not, in which case actual testing is the best bet.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ee90f64b89e8..5c577d242078 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2066,8 +2066,8 @@ enum skl_disp_power_wells { #define AMP_UNMUTE (1 << 1) #define AUD_CHICKEN_BIT_REG 0x62F38 #define AUD_PORT_EN_B_DBG 0x62F20 -#define AUD_PORT_EN_C_DBG 0x62F28 -#define AUD_PORT_EN_D_DBG 0x62F2C +#define AUD_PORT_EN_C_DBG 0x62F30 +#define AUD_PORT_EN_D_DBG 0x62F34 #define VLV_AUD_CHICKEN_BIT_REG _MMIO(VLV_DISPLAY_BASE + AUD_CHICKEN_BIT_REG) #define VLV_AUD_PORT_EN_B_DBG _MMIO(VLV_DISPLAY_BASE + AUD_PORT_EN_B_DBG) #define VLV_AUD_PORT_EN_C_DBG _MMIO(VLV_DISPLAY_BASE + AUD_PORT_EN_C_DBG)