> I've tried to be slightly lazy than in my previous mail and quickly
> tested this on my snb here: Bit 23 in SDEISR (0xc4000) is set when the
> cable is plugged in, and cleared when nothing is plugged in. Afaict it
> works as advertised. Note tha the SDE irq definitions nicely
> differentiates bet
Hi Mark,
[CCing intel-gfx]
On Fri, 12 October 2012 Mark Hounschell wrote:
> Not sure this is the correct place to ask about a possible drm issue. I
> have an intel based PC with an HDMI port that I'm trying to connect to
> an LG TV. I have successfully used this HDMI port connected to an Optim
On Fri, Oct 12, 2012 at 9:03 PM, Stuart Abercrombie
wrote:
>> My docs here say that the SDE_ISR reg contains what we want - high
>> level irq bit when the hpd line is enabled. I admit, I haven't tested
>> this ...
>
> I'm looking at 2.1.1 in this
> http://intellinuxgraphics.org/documentation/SNB/I
> My docs here say that the SDE_ISR reg contains what we want - high
> level irq bit when the hpd line is enabled. I admit, I haven't tested
> this ...
I'm looking at 2.1.1 in this
http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf.
All it has relating to hotplug in SDEIIR are
Jesse Barnes writes:
> On Tue, 09 Oct 2012 13:05:54 -0700
> Eric Anholt wrote:
>
>> On my new MBA with danvet's drm-intel-next-queued, I'm not getting
>> working RPS. vblank_mode=0 glxgears never ups the frequency, and
>> vblank_mode=0 openarena only makes it up to 500mhz. Reverting
>> 1ee9ae3
On Fri, Oct 12, 2012 at 8:40 PM, Stuart Abercrombie
wrote:
>> In the hotplug register, like on g4x. But that moved to to PCH_IIR on pch
>> platforms. I plan to rework the entire hotplug handling for 3.8, hence why
>> I haven't bothered to wire this up yet.
>
> You are saying that the HPD line stat
> In the hotplug register, like on g4x. But that moved to to PCH_IIR on pch
> platforms. I plan to rework the entire hotplug handling for 3.8, hence why
> I haven't bothered to wire this up yet.
You are saying that the HPD line state is available in the register
called SDEIIR in the code? The doc
Hi all,
New -testing cycle. Highlights:
- tons of hsw dp prep patches form Paulo
- round scheduled work items and timers to nearest second (Chris)
- some hw workarounds (Jesse&Damien)
- vlv dp support and related fixups (Vijay et al.)
Not that much, despite the extended review window. We have ton
Somehow this was left out in the refactoring that introduced the pch
handlers. Avoids a hotplug_mask special case in the ilk_irq_handler.
Noticed while hunting down the pch hotplug bits.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 16 ++--
1 file changed, 6
On Fri, Oct 12, 2012 at 10:29:38AM -0700, Stuart Abercrombie wrote:
> > Nope, the real fix is to simply check the status of the hpd line before
> > trying the edid read. We already have that for g4x class chips, check
> > g4x_hdmi_connected. We'd need to add similar checks for all other
> > platfor
> Nope, the real fix is to simply check the status of the hpd line before
> trying the edid read. We already have that for g4x class chips, check
> g4x_hdmi_connected. We'd need to add similar checks for all other
> platforms.
> -Daniel
That would be preferable. Unfortunately we did not find a wa
On Fri, Oct 12, 2012 at 7:17 PM, Paulo Zanoni wrote:
> Ok, so please do a final test: try to write something to those
> "must-be-preserved" bits and check if the values stay or not. If after
> writing 1 to bits 17-18, 20-23 you read 0, then you have my
> Reviewed-by: Paulo Zanoni . I still do plan
Hi
2012/10/12 Daniel Vetter :
> On Fri, Oct 12, 2012 at 03:54:50AM -0400, Dave Airlie wrote:
>> On Thu, Oct 11, 2012 at 7:54 PM, Jesse Barnes
>> wrote:
>> > On Thu, 11 Oct 2012 20:29:47 -0300
>> > Paulo Zanoni wrote:
>> >
>> >> Hi
>> >>
>> >> 2012/10/11 Jesse Barnes :
>> >> > I've only lightly
2012/10/12 Daniel Vetter :
> On Fri, Oct 12, 2012 at 4:47 AM, Paulo Zanoni wrote:
>> 2012/10/11 Daniel Vetter :
>>> ... since they don't apply to pre-pch platforms and could actually be
>>> harmful.
>>>
>>> Signed-off-by: Daniel Vetter
>>
>> Ok, so I checked the specs and yes, these bit definitio
On Fri, Oct 12, 2012 at 11:02 AM, Chris Wilson wrote:
> On Thu, 11 Oct 2012 19:46:27 +0200, Daniel Vetter
> wrote:
>> This piece of neat lore has been ported painstakingly and bug-for-bug
>> compatible from the old crtc helper code.
>>
>> Imo it's utter nonsense.
>>
>> If you have disconnect a c
On Thu, 11 Oct 2012 19:46:07 +0200, Daniel Vetter
wrote:
> Makes more sense to group the entire mode_set stage into one function.
> Noticed while discussion the rather confusing set of function names
> with Paulo Zanoni. Unfortunately I don't have an idea to make the
> function names lesss confus
Hi Dave,
A bit of paranoid-WARNs fallout from modeset, otherwise just small
fixlets:
- some register magic to fix hsw crw (Paulo&Ben)
- fix backlight destruction for cpu edp (Jani)
- fix gen ch7xxx dvo ->get_hw_state
- fixup the plane->pipe fixup code, the broken version massively angers
the mod
On Thu, 11 Oct 2012 19:46:27 +0200, Daniel Vetter
wrote:
> This piece of neat lore has been ported painstakingly and bug-for-bug
> compatible from the old crtc helper code.
>
> Imo it's utter nonsense.
>
> If you have disconnect a cable and before you reconnect it, userspace
> (or the kernel) d
On Thu, 11 Oct 2012 18:10:17 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Libdrm's possible_clones is a mask of encoders. Xorg's possible_clones
> is a mask of outputs, so we just can't do the following:
>
> output->possible_clones = kencoder->possible_clones;
>
> This is a problem on
On Fri, Oct 12, 2012 at 4:47 AM, Paulo Zanoni wrote:
> 2012/10/11 Daniel Vetter :
>> ... since they don't apply to pre-pch platforms and could actually be
>> harmful.
>>
>> Signed-off-by: Daniel Vetter
>
> Ok, so I checked the specs and yes, these bit definitions don't exist.
> The problem here i
On Fri, Oct 12, 2012 at 10:48:20AM +0300, Mika Kuoppala wrote:
> On Fri, 12 Oct 2012 10:33:05 +0300, Jani Nikula wrote:
> > Backlight is initialized for eDP, but cleaned up only for eDP on DP-D
> > port. This leaves behind a dangling backlight interface on module unload on
> > machines that have e
On Thu, Oct 11, 2012 at 04:27:54PM -0700, Stuart Abercrombie wrote:
> Following a hotplug interrupt the driver uses a successful EDID read to
> indicate HDMI sink presence.
>
> This leads to missing HDMI cable unplug events because the DDC lines can
> remain up, allowing an EDID read to complete
On Fri, Oct 12, 2012 at 03:54:50AM -0400, Dave Airlie wrote:
> On Thu, Oct 11, 2012 at 7:54 PM, Jesse Barnes
> wrote:
> > On Thu, 11 Oct 2012 20:29:47 -0300
> > Paulo Zanoni wrote:
> >
> >> Hi
> >>
> >> 2012/10/11 Jesse Barnes :
> >> > I've only lightly tested this so far, but the corruption see
On Thu, Oct 11, 2012 at 7:54 PM, Jesse Barnes wrote:
> On Thu, 11 Oct 2012 20:29:47 -0300
> Paulo Zanoni wrote:
>
>> Hi
>>
>> 2012/10/11 Jesse Barnes :
>> > I've only lightly tested this so far, but the corruption seems to be
>> > gone if I write the GFX_FLSH_CNTL reg after binding an object. Th
On Fri, 2012-10-12 at 10:33 +0300, Jani Nikula wrote:
> Backlight is initialized for eDP, but cleaned up only for eDP on DP-D
> port. This leaves behind a dangling backlight interface on module unload on
> machines that have eDP connected to something other than DP-D, and breaks
> the backlight int
On Fri, 12 Oct 2012 10:33:05 +0300, Jani Nikula wrote:
> Backlight is initialized for eDP, but cleaned up only for eDP on DP-D
> port. This leaves behind a dangling backlight interface on module unload on
> machines that have eDP connected to something other than DP-D, and breaks
> the backlight i
Backlight is initialized for eDP, but cleaned up only for eDP on DP-D
port. This leaves behind a dangling backlight interface on module unload on
machines that have eDP connected to something other than DP-D, and breaks
the backlight interface for subsequent module reloads. Fix the cleanup, and
thu
27 matches
Mail list logo
