>>> 'xset dpms force off; sleep 1; xset dpms force on' does indeed trigger
>>> the error. I've attached my Xorg.0.log.old which includes the
>>> segfault backtrace. I'm like a newborn baby when it comes to
>>> compiling and Gentoo doesn't have a debug USE flag for
>>> xf86-video-intel or xorg-ser
On Fri, 31 Aug 2012 14:31:51 +0300, Imre Deak wrote:
> Calling drmModeRmFB is only allowed in DRM master mode. Since leaving
> the VT also drops master mode we need to remove the FB before calling
> I830LeaveVT.
>
> This is only a real leak in case of a server reset, otherwise the server
> proces
On Wed, 2012-09-05 at 08:43 +0200, Luca Ellero wrote:
> Hi Adam,
> thank you for your quick reply.
> Anyway, if you don't mind I would like to ask you two more questions then:
>
> 1) does this mean that I can't use Open Source Graphics Drivers for GMA3150?
Incorrect. The GMA3150 is supported by
On 05/09/2012 15.28, Adam Jackson wrote:
On Wed, 2012-09-05 at 08:43 +0200, Luca Ellero wrote:
Hi Adam,
thank you for your quick reply.
Anyway, if you don't mind I would like to ask you two more questions then:
1) does this mean that I can't use Open Source Graphics Drivers for GMA3150?
Inco
On Sun, 19 Aug 2012 21:12:47 +0200
Daniel Vetter wrote:
> +static void
> +intel_connector_break_all_links(struct intel_connector *connector)
> +{
> + connector->base.dpms = DRM_MODE_DPMS_OFF;
> + connector->base.encoder = NULL;
> + connector->encoder->connectors_active = false;
> +
On Sun, 19 Aug 2012 21:12:48 +0200
Daniel Vetter wrote:
> Atm we can only check the connector state after a dpms call - while
> doing modeset with the copy&pasted crtc helper code things are too
> ill-defined for proper checking. But the idea is very much to call
> this check from the modeset cod
On Sun, 19 Aug 2012 21:12:49 +0200
Daniel Vetter wrote:
> Afaict this has been used for two things:
> - To prevent the crtc enable code from being run twice. We have now
> intel_crtc->active to track this in a more precise way.
> - To ensure the code copes correctly with the unknown hw state af
On Sun, 19 Aug 2012 21:12:50 +0200
Daniel Vetter wrote:
> We now track the connector state in encoder->connectors_active, and
> because the DP output can't be cloned, that is sufficient to track the
> link state. Hence use this instead of adding yet another modeset state
> variable with dubious s
On Sun, 19 Aug 2012 21:12:51 +0200
Daniel Vetter wrote:
> Many BIOSen forget to turn on the pipe A after resume (because they
> actually don't turn on anything), so we have to do that ourselves when
> sanitizing the hw state.
>
> I've discovered this due to the recent addition of a pipe WARN tha
On Sun, 19 Aug 2012 21:12:53 +0200
Daniel Vetter wrote:
> At the end this won't be of much use to us, but meanwhile just extract
> it to get a better overview of what exactly set_config does.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 127
> +++
On Sun, 19 Aug 2012 21:12:54 +0200
Daniel Vetter wrote:
> This computes what exactly changed in the modeset configuration, i.e.
> whether a full modeset is required or only an update of the
> framebuffer base address or no change at all.
>
> In the future we might add more checks for e.g. when o
On Sun, 19 Aug 2012 21:12:55 +0200
Daniel Vetter wrote:
> Note that this function already clobbers the mode config state,
> so we have to clean things up if something fails.
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
_
On Sun, 19 Aug 2012 21:12:56 +0200
Daniel Vetter wrote:
> Yikes!
>
> But yeah, we have to do this until someone volunteers to clean up the
> fb helper and rid it of its incetious relationship with the crtc
> helper code.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_disp
On Sun, 19 Aug 2012 21:12:57 +0200
Daniel Vetter wrote:
> Otherwise we'll set_fb complains pretty loudly if we the crtc is off
> and userspace moves the NULL fb around a bit. Yeah, this actually
> happens in the wild ...
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_displ
On Sun, 19 Aug 2012 21:12:58 +0200
Daniel Vetter wrote:
> Because they all are, the ioctl command never calls us with any of
> these violated. Also drop a equally pointless empty debug message (and
> also in set_cursor, while we're at it).
>
> With all these changes, intel_crtc_set_config is nea
On Sun, 19 Aug 2012 21:12:59 +0200
Daniel Vetter wrote:
> We actually only touch the connector -> encoder and encoder -> crtc
> linking. So it's enough to just save/restore that.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 28 +++-
>
On Sun, 19 Aug 2012 21:12:52 +0200
Daniel Vetter wrote:
> intel_crtc_set_config is an unwidly beast and is in serious need of
> some function extraction. To facilitate that, introduce a struct to
> keep track of all the state involved. Atm it doesn't do much more than
> keep track of all the allo
On Tue, 4 Sep 2012 21:33:22 +0200
Daniel Vetter wrote:
> Passing in the old fb, having overwritten the current fb, leads to
> some neatly convoluted code. It's much simpler if we defer the
> crtc->fb update to the place that updates the hw, in pipe_set_base.
> This way we also don't need to rest
On Sun, 19 Aug 2012 21:13:02 +0200
Daniel Vetter wrote:
> Originally this has been introduced in
>
> commit 6eebd6bb5f1ea04f04019e5c39f87a0f17ffb472
> Author: Chris Wilson
> Date: Mon Nov 28 21:10:05 2011 +
>
> drm: Fix lack of CRTC disable for drm_crtc_helper_set_config(.fb=NULL)
>
On Sun, 19 Aug 2012 21:13:03 +0200
Daniel Vetter wrote:
> It's rather pointless to compute crtc->enabled twice right away ;-)
>
> The only thing we really have to be careful about is that we frob the
> dpms state only after a successful modeset and when we've actually
> haven't just disabled the
On Sun, 19 Aug 2012 21:13:04 +0200
Daniel Vetter wrote:
> While at it, adjust a few things:
> - Only assigng the new mode to crtc->mode right before calling the
> mode_set callbacks - none of the previous callbacks depend upon
> this, they all use the mode argument (as they should).
> - Check
On Sun, 19 Aug 2012 21:13:06 +0200
Daniel Vetter wrote:
> - Use the check_cloned helper from the previous patch.
> - Use encoder->new_crtc to check crtc properties.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_lvds.c | 13 +++--
> 1 file changed, 3 insertions(+),
On Sun, 19 Aug 2012 21:13:07 +0200
Daniel Vetter wrote:
> This is definetely a bit more generic than currently required, but
> if we keep track of all crtcs that need to be disabled/enable (because
> they loose an encoder or something similar), crtcs that get completely
> disabled and those that
On Wed, 29 Aug 2012 12:34:04 +0200
Daniel Vetter wrote:
> This is definetely a bit more generic than currently required, but
> if we keep track of all crtcs that need to be disabled/enable (because
> they loose an encoder or something similar), crtcs that get completely
> disabled and those that
On Sun, 19 Aug 2012 21:13:08 +0200
Daniel Vetter wrote:
> ... using the pipe masks from the previous patch.
>
> Well, not quite:
> - We still need to call the disable_unused_functions helper, until
> we've moved the call to commit_output_state further down and
> adjusted intel_crtc_disable a
On Sun, 19 Aug 2012 21:13:09 +0200
Daniel Vetter wrote:
> This requires a few changes
> - We still need a noop function for crtc->disable, becuase the fb
> helper is a bit too intimate with the crtc helper.
> - We need to clear crtc->fb ourselves in intel_crtc_disable now that
> we no longer
On Sun, 19 Aug 2012 21:13:11 +0200
Daniel Vetter wrote:
> This seems to be the symptom of a few neat bugs, hence be more
> obnoxious when this fails.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> d
On Sun, 19 Aug 2012 21:13:12 +0200
Daniel Vetter wrote:
> Now that set_mode also disables crtcs and expects it's new
> configuration in the staged output links we need to adjust the load
> detect code a bit.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 13 +++
On Tue, 4 Sep 2012 21:32:28 +0200
Daniel Vetter wrote:
> With this change we can (finally!) rip out a few of the temporary hacks
> and clean up a few other things:
> - Kill intel_crtc_prepare_encoders, now unused.
> - Kill the hacks in the crtc_disable/enable functions to always call the
> enc
On Wed, 29 Aug 2012 23:13:29 +0200
Daniel Vetter wrote:
> Since this only calls crtc helper functions, of which a shocking
> amount are NULL.
>
> Now the curious thing is how the new modeset code worked with this
> function call still present:
>
> Thanks to the hw state readout and the suspend
On Fri, 31 Aug 2012 20:12:55 +0200
Daniel Vetter wrote:
> Now that we have solid modeset state tracking and checking code in
> place, we can do the Full Monty also after dpms calls.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_crt.c | 2 +-
> drivers/gpu/drm/i915/int
On Wed, Sep 5, 2012 at 6:26 PM, Jesse Barnes wrote:
> On Sun, 19 Aug 2012 21:12:48 +0200
> Daniel Vetter wrote:
>
>> Atm we can only check the connector state after a dpms call - while
>> doing modeset with the copy&pasted crtc helper code things are too
>> ill-defined for proper checking. But th
On Wed, Sep 5, 2012 at 6:32 PM, Jesse Barnes wrote:
> On Sun, 19 Aug 2012 21:12:51 +0200
> Daniel Vetter wrote:
>
>> Many BIOSen forget to turn on the pipe A after resume (because they
>> actually don't turn on anything), so we have to do that ourselves when
>> sanitizing the hw state.
>>
>> I've
On Wed, Sep 5, 2012 at 6:45 PM, Jesse Barnes wrote:
> On Sun, 19 Aug 2012 21:12:56 +0200
> Daniel Vetter wrote:
>
>> Yikes!
>>
>> But yeah, we have to do this until someone volunteers to clean up the
>> fb helper and rid it of its incetious relationship with the crtc
>> helper code.
>>
>> Signed-
On Wed, Sep 5, 2012 at 6:50 PM, Jesse Barnes wrote:
>> @@ -6919,16 +6917,9 @@ static int intel_crtc_set_config(struct drm_mode_set
>> *set)
>> int ret;
>> int i;
>>
>> - DRM_DEBUG_KMS("\n");
>> -
>> - if (!set)
>> - return -EINVAL;
>> -
>> - if (!set->crtc)
>>
On Wed, Sep 5, 2012 at 6:52 PM, Jesse Barnes wrote:
> Sneaky that you moved to kcalloc too :)
Commit message is now less sneaky, thanks for spotting this.
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
On Sun, 19 Aug 2012 21:13:00 +0200
Daniel Vetter wrote:
> This is the core of the new modeset logic.
>
> The current code which is based upon the crtc helper code first
> updates all the link of the new display pipeline and then calls the
> lower-level set_mode function to execute the required c
On Sun, 19 Aug 2012 21:13:01 +0200
Daniel Vetter wrote:
> Passing in the old fb, having overwritten the current fb, leads to
> some neatly convoluted code. It's much simpler if we defer the
> crtc->fb update to the place that updates the hw, in pipe_set_base.
> This way we also don't need to rest
On Wed, Sep 5, 2012 at 6:34 PM, Jesse Barnes wrote:
> if (!config)
> return;
> ?
>
> My eyes always hurt a little when I see if blocks that take up the
> whole function. :) Just a nit pick though.
Yeah, looks better. Bikeshed applied locally since it resulted in some
conf
On Wed, Sep 5, 2012 at 8:00 PM, Jesse Barnes wrote:
> Fancy, using ERR_PTR even. :)
Consider this a tell-tale of the shape of things to come ;-) I.e. I
plan to extend this adjusted_mode computation to a full up-front
resource allocation step to decide about pipe bpp, dithering,
bandwidth allocati
On Sun, 19 Aug 2012 21:13:05 +0200
Daniel Vetter wrote:
> The "is this encoder cloned" check will be reused by the lvds encoder,
> hence exract it.
>
> v2: Be a bit more careful about that we need to check the new, staged
> ouput configuration in the check_non_cloned helper ...
>
> Signed-off-b
On Wed, Sep 5, 2012 at 8:09 PM, Jesse Barnes wrote:
> On Wed, 29 Aug 2012 12:34:04 +0200
> Daniel Vetter wrote:
>
>> This is definetely a bit more generic than currently required, but
>> if we keep track of all crtcs that need to be disabled/enable (because
>> they loose an encoder or something s
On Wed, Sep 5, 2012 at 8:14 PM, Jesse Barnes wrote:
> An ugly intermediate step... also did you check whether moving the
> crtc->x/y assignment up is safe? We're passing it around, but some
> places might check for crtc->x/y looking for old values (or did that
> already change in the previous pat
On Wed, Sep 5, 2012 at 8:28 PM, Jesse Barnes wrote:
>
> The variables have me confused a little... I would have expected
> update_state to take modeset_pipes rather than prepare_pipes. Could
> you use either? Or will that not catch cases where we updated a pipe
> that was already on?
The abstra
On Wed, 5 Sep 2012 21:43:30 +0200
Daniel Vetter wrote:
> On Wed, Sep 5, 2012 at 8:14 PM, Jesse Barnes wrote:
> > An ugly intermediate step... also did you check whether moving the
> > crtc->x/y assignment up is safe? We're passing it around, but some
> > places might check for crtc->x/y looking
On Sun, 19 Aug 2012 21:13:10 +0200
Daniel Vetter wrote:
> Because that's what it is. Unfortunately we can't rip this out because
> the fb helper has an incetious relationship with the crtc helper - it
> likes to call disable_unused_functions, among other things.
>
> Signed-Off-by: Daniel Vetter
On Wed, Sep 5, 2012 at 8:31 PM, Jesse Barnes wrote:
> On Wed, 29 Aug 2012 23:13:29 +0200
> Daniel Vetter wrote:
>
>> Since this only calls crtc helper functions, of which a shocking
>> amount are NULL.
>>
>> Now the curious thing is how the new modeset code worked with this
>> function call still
On Wed, Sep 5, 2012 at 7:55 PM, Jesse Barnes wrote:
> Ok obviously missed the leak.
Oops, just noticed that I'm still saving the crtc state. Will fix this.
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
__
Passing in the old fb, having overwritten the current fb, leads to
some neatly convoluted code. It's much simpler if we defer the
crtc->fb update to the place that updates the hw, in pipe_set_base.
This way we also don't need to restore anything in case something
fails - we only update crtc->fb onc
On Wed, 5 Sep 2012 21:56:08 +0200
Daniel Vetter wrote:
> On Wed, Sep 5, 2012 at 8:31 PM, Jesse Barnes wrote:
> > On Wed, 29 Aug 2012 23:13:29 +0200
> > Daniel Vetter wrote:
> >
> >> Since this only calls crtc helper functions, of which a shocking
> >> amount are NULL.
> >>
> >> Now the curious
On Sun, 19 Aug 2012 21:13:14 +0200
Daniel Vetter wrote:
> We need this to avoid confusing the hw state readout code with the cpt
> pch plls at resume time: We'd read the new pipe state (which is
> disabled), but still believe that we have a life pll connected to that
> pipe (from before the suspe
On Fri, 31 Aug 2012 20:12:54 +0200
Daniel Vetter wrote:
> ... let's see whether this catches anything earlier and I can track
> down a few bugs.
>
> v2: Add more checks and also add DRM_DEBUG_KMS output so that it's
> clear which connector/encoder/crtc is being checked atm. Which proved
> rather
The gmbus interrupt generation is rather fiddly: We can only ever
enable one interrupt source (but we always want to check for NAK
in addition to the real bit). And the bits in the gmbus status
register don't map at all to the bis in the irq register.
To prepare for this mess, start by extracting
Only enables the interrupt and puts a irq handler into place, doesn't
do anything yet.
Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
pnv, but there the irq is marked as "Test mode").
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
hand-roll the wait_event_timeout code so that we wake up every
jiffie and can c
On Wed, 5 Sep 2012 21:24:39 +0200, Daniel Vetter
wrote:
> The gmbus interrupt generation is rather fiddly: We can only ever
> enable one interrupt source (but we always want to check for NAK
> in addition to the real bit). And the bits in the gmbus status
> register don't map at all to the bis i
On Sun, Sep 02, 2012 at 12:24:40AM -0700, Ben Widawsky wrote:
> The original patch was actually incorrect in stubbing out the sysfs for
> l3 parity.
> commit 5ab3633d6907018b0b830a720e877c3884d679c3
> Author: Hunt Xu
> Date: Sun Jul 1 03:45:07 2012 +
>
> drm/i915: make rc6 in sysfs func
On Wed, 5 Sep 2012 21:24:40 +0200, Daniel Vetter
wrote:
> Only enables the interrupt and puts a irq handler into place, doesn't
> do anything yet.
>
> Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
> pnv, but there the irq is marked as "Test mode").
The basics look good,
On Wed, Sep 5, 2012 at 11:25 PM, Chris Wilson wrote:
> On Wed, 5 Sep 2012 21:24:39 +0200, Daniel Vetter
> wrote:
>> The gmbus interrupt generation is rather fiddly: We can only ever
>> enable one interrupt source (but we always want to check for NAK
>> in addition to the real bit). And the bits
On Wed, 5 Sep 2012 21:24:41 +0200, Daniel Vetter
wrote:
> We need two special things to properly wire this up:
> - Add another argument to gmbus_wait_hw_status to pass in the
> correct interrupt bit in gmbus4.
> - Since we can only get an irq for one of the two events we want,
> hand-roll th
On Wed, Sep 5, 2012 at 11:29 PM, Chris Wilson wrote:
> On Wed, 5 Sep 2012 21:24:40 +0200, Daniel Vetter
> wrote:
>> Only enables the interrupt and puts a irq handler into place, doesn't
>> do anything yet.
>>
>> Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
>> pnv, but t
On Wed, 5 Sep 2012 23:36:46 +0200, Daniel Vetter wrote:
> On Wed, Sep 5, 2012 at 11:29 PM, Chris Wilson
> wrote:
> > On Wed, 5 Sep 2012 21:24:40 +0200, Daniel Vetter
> > wrote:
> >> Only enables the interrupt and puts a irq handler into place, doesn't
> >> do anything yet.
> >>
> >> Unfortuna
On Wed, 5 Sep 2012 21:38:27 +0200
Daniel Vetter wrote:
> On Wed, Sep 5, 2012 at 8:09 PM, Jesse Barnes wrote:
> > On Wed, 29 Aug 2012 12:34:04 +0200
> > Daniel Vetter wrote:
> >
> >> This is definetely a bit more generic than currently required, but
> >> if we keep track of all crtcs that need t
On Wed, 5 Sep 2012 21:48:52 +0200
Daniel Vetter wrote:
> On Wed, Sep 5, 2012 at 8:28 PM, Jesse Barnes wrote:
> >
> > The variables have me confused a little... I would have expected
> > update_state to take modeset_pipes rather than prepare_pipes. Could
> > you use either? Or will that not cat
Who wrote wait_for()? It is a deadly booby trap!
On Wed, 5 Sep 2012 21:24:39 +0200, Daniel Vetter
wrote:
> - if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
> - 10)) {
> + if (gmbus_wait_hw_status(dev_priv, GMBUS_ACTIVE)) {
This is reversing the stat
On Sun, 19 Aug 2012 21:12:17 +0200
Daniel Vetter wrote:
> Hi all,
>
> Changes since last time around:
> - The prep patches are all merged now.
> - I've left out the actual DP fixes/cleanups, I think we should merge those
> in a
> separte step.
> - A few bugfixes (thanks to Paulo, Jani and Chr
On Wed, Sep 05, 2012 at 04:23:55PM -0700, Jesse Barnes wrote:
> On Sun, 19 Aug 2012 21:12:17 +0200
> Daniel Vetter wrote:
>
> > Hi all,
> >
> > Changes since last time around:
> > - The prep patches are all merged now.
> > - I've left out the actual DP fixes/cleanups, I think we should merge tho
67 matches
Mail list logo
