On 06/11/2012 12:38 PM, Daniel Vetter wrote:
> On Mon, Jun 11, 2012 at 7:25 AM, Shobhit Kumar<shobhit.kumar at intel.com> wrote:
>> On 06/08/2012 07:20 PM, Eugeni Dodonov wrote:
>>>
>>> On 06/08/2012 09:49 AM, Daniel Vetter wrote:
>>>>
>>>> On Fri, Jun 08, 2012 at 11:44:23AM +0530, Shobhit Kumar wrote:
>>>>>
>>>>> In Haswell while disabling a pipe, we need to disable the DDI control as
>>>>> well along with the PIPECONF. Otherwise we will hit assertions during
>>>>> crtc
>>>>> disable
>>>>
>>>>
>>>> Hm, can you add such an example assert with backtrace please? All these
>>>> asserts encode our current understanding of the hw depency chain, so I'd
>>>> like to check whether we're really doing the right thing and don't just
>>>> stfu some dmesg noise.
>>>>
>>>> Thanks, Daniel
>>>
>>>
>>> This is part of the pipe disabling process starting with Haswell. DDI
>>> pipe function control should be disabled when pipe is being disabled,
>>> otherwise it stays in enabled state and on next enabling we hit the
>>> assert within assert_fdi_tx:
>>>
>>> ...
>>> if (IS_HASWELL(dev_priv->dev)) {
>>> /* On Haswell, DDI is used instead of FDI_TX_CTL */
>>> reg = DDI_FUNC_CTL(pipe);
>>> val = I915_READ(reg);
>>> cur_state = !!(val& PIPE_DDI_FUNC_ENABLE);
>>> ...
>>>
>> Eugeni already explained how and where the assertion will be raised. Please
>> find a sample assertion while loading the driver with HDMI output connected
>
> Yeah, we've discussed this quite a bit, thanks anyway for following
> up. Imo I'm not too stressed out about this backtrace since (as per my
> discussion with Eugeni) our code and asserts around disabling the
> ddi/pch fdi rx stuff is a bit ugly/buggy still for hsw/lpt, so I think
> this can wait a bit.
Its just that the DP enabling does not work properly if the pipe
DDI_FUNC_CTL is not off while I am testing my DP code. In case of HDMI
even if the assertion is there it works when we re-enable it in modeset,
but for DP, DDI_FUNC_CTL already enabled spells doom. Maybe it has got
to do with the fact that HDMI is driver by WRPLL while in my code DP is
over SPLL ?
>
> Imo the ddi disable shouldn't be in the pipe disable function but
> makes more sense in the fdi disable functions. But then it would be
> brutally obviously that that still touches the fdi tx regs on hsw, and
> from there on it's all down the rabbit hole ...
Yeah, I agree
Regards
Shobhit
