On Mon, 2 Dec 2013 19:00:45 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Check that the N and P dividers don't cause a divide by zero.
>
> This shouldn't happen under normal circumstances, but can
> happen eg. under simulation.
>
> Signed-off-by: Ville Syrjälä
> ---
>
I am getting this during suspend with latest Linus' git (HEAD == af91706).
[ cut here ]
WARNING: CPU: 0 PID: 5397 at drivers/gpu/drm/i915/intel_display.c:9948
intel_get_pipe_from_connector+0x4a/0x50 [i915]()
Modules linked in: ctr ccm af_packet tun iptable_mangle xt_DS
We call intel_modeset_setup_hw_state() along two paths, driver
load/resume and after a lid event notification. During initialisation of
the driver, it is imperative that we reset the config state. This
correctly sets up the initial connector statuses and prepares the
hardware for a thorough probing
From: Ville Syrjälä
Check that the N and P dividers don't cause a divide by zero.
This shouldn't happen under normal circumstances, but can
happen eg. under simulation.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --gi
Chris Wilson writes:
> On Mon, Dec 02, 2013 at 04:47:46PM +0200, Mika Kuoppala wrote:
>> Fork and create another filedesc to wait access to already
>> hung GPU and then kill it. This triggers use after free of the
>> request->batch_obj.
>>
>> Signed-off-by: Mika Kuoppala
>> ---
>> +static int _
We used to lean on active_list to handle the references
to batch objects. But there are useful cases when same,
albeit simple, batch can be executing on multiple rings
concurrently. For this case the active_list reference count
handling is just not enough as batch could be freed by
ring A request r
On Mon, Dec 02, 2013 at 04:47:46PM +0200, Mika Kuoppala wrote:
> Fork and create another filedesc to wait access to already
> hung GPU and then kill it. This triggers use after free of the
> request->batch_obj.
>
> Signed-off-by: Mika Kuoppala
> ---
> +static int __test_open_any(void)
> +{
> +
Fork and create another filedesc to wait access to already
hung GPU and then kill it. This triggers use after free of the
request->batch_obj.
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 63 +++
1 file changed, 63 insertions(+)
diff --
On 12/02/2013 02:26 PM, Rodrigo Vivi wrote:
From: Daniel Vetter
So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.
Note that the max fifo value isn't actually
On Mon, Dec 2, 2013 at 10:53 AM, Paul Bolle wrote:
> On Mon, 2013-12-02 at 08:33 +0100, Daniel Vetter wrote:
>> On Sun, Dec 1, 2013 at 5:57 PM, Paul Bolle wrote:
>> > The WARNING is now gone during suspend and resume (having tested that
>> > thoroughly - ie, twice). But I still see it at boot. Is
On Wed, Oct 09, 2013 at 10:47:12AM +0200, Daniel Vetter wrote:
> It's a pain for two reasons:
> - The vga plane redisablign requires actual legacy vgao i/o to pull
> of. The hw engineers really botched this one here :(
> - There seem to be some BIOS out there which send out lid events when
> un
On Mon, Dec 02, 2013 at 11:23:39AM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We don't have clock state readout support for DDI, so skip the pipe
> config clock checks on all DDI platforms.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Damien Lespiau
--
Damien
>
On Thu, Nov 28, 2013 at 04:49:52PM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2013 at 03:29:18PM +, Damien Lespiau wrote:
> > We had some mode_valid() vfuncs returning an int, others the enum. Let's
> > use the latter everywhere.
> >
> > Signed-off-by: Damien Lespiau
>
> Yeah, makes sense
On Thu, Nov 21, 2013 at 1:47 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The code to enable/disable PC8 already takes care of saving and
> restoring all the registers we need to save/restore, so do a put()
> call when we enable PC8 and a get() call when we disable it.
>
> Ideally, in order t
Reviewed-by: Rodrigo Vivi
On Thu, Nov 21, 2013 at 1:47 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The plan is to merge PC8 and D3 into a single feature, and when we're
> in D3 we won't get any hotplug interrupt anyway, so leaving them
> enable doesn't make sense, and it also brings us a p
From: Jani Nikula
Checkpatch tells me
WARNING: __packed is preferred over __attribute__((packed))
so switch over to __packed across the driver before adding new packed
structs.
Signed-off-by: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_bios.h | 48 +++
From: Daniel Vetter
So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.
Note that the max fifo value isn't actually correct for the i830M, but
since we don't fro
From: Jani Nikula
We don't actually do anything with the information yet, but parse and
log what's in the VBT.
Signed-off-by: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_bios.c | 29 +
drivers
From: Adam Jackson
This is, by far, the most common kernel retrace in i915 I'm seeing:
https://retrace.fedoraproject.org/faf/problems/1346879/
There's not enough information in the backtrace to know if something
actually went wrong or if this is just an assertion failure, so it's
pretty useless
From: Chris Wilson
If we force the hw to idle as our first step during unload, we can abort
the unload upon failure. Later we can probe whether the hardware remain
active even after we try to shut it down.
Signed-off-by: Chris Wilson
Reviewed-by: Rodrigo Vivi
Signed-off-by: Rodrigo Vivi
---
From: Chris Wilson
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb->obj is in the display domain, which
incurs a cache flush to ensure no dirt is le
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Asynchronously perform the set-base for a simple modeset -
Reviewed
Patch drm
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> Add a REG_WRITE_FOOTER macro as a counterpart to the REG_WRITE_HEADER.
> The current code has the spin_lock() in the HEADER, but the
> spin_unlock() is open coded, which looks rather confusing on the first
> glance. A bit of addition
On Thu, 2013-11-21 at 13:47 -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This patch adds the initial infrastructure to allow a Runtime PM
> implementation that sets the device to its D3 state. The patch just
> adds the necessary callbacks and the initial infrastructure.
>
> We still don't
From: Ville Syrjälä
Add a REG_WRITE_FOOTER macro as a counterpart to the REG_WRITE_HEADER.
The current code has the spin_lock() in the HEADER, but the
spin_unlock() is open coded, which looks rather confusing on the first
glance. A bit of additional symmetry might help.
Signed-off-by: Ville Syrj
On Mon, Dec 02, 2013 at 11:00:29AM +0100, Paul Bolle wrote:
> On Mon, 2013-12-02 at 11:08 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Some lower level things get angry if we don't have modeset locks
> > during intel_modeset_setup_hw_state(). Actually the resume and
It is useful to assert that if the object is bound, then it must have
its pages pinned to prevent the shrinker from reaping its backing store.
This is even more useful with the introduction of real-ppgtt whereupon
we may have the object bound into several vma, with each instance
pinning the backing
When inspecting reports that boot/suspend/resume times are unusual it
would be useful to clearly identify the time we must spend waiting for
the hardware to complete its task. In this case we have a notification
before we start waiting for the panel to change state, but none
afterwards - which woul
From: Ville Syrjälä
We don't have clock state readout support for DDI, so skip the pipe
config clock checks on all DDI platforms.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel
From: Ville Syrjälä
Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.
Signed-off-by: Ville Syrjälä
---
Totally untested, but loo
30 matches
Mail list logo
