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.
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 ...
-Daniel
--
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
