On Fri, Jun 07, 2013 at 04:03:50PM +0300, Jani Nikula wrote:
> drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’:
> drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects
> argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat]
>
> v2: Use
On Sun, Jun 09, 2013 at 11:18:16AM +0200, Daniel Vetter wrote:
> Hi stable maintainers,
>
> Please backport
>
> commit e3de42b68478a8c95dd27520e9adead2af9477a5
> Author: Imre Deak
> Date: Fri May 3 19:44:07 2013 +0200
>
> drm/i915: force full modeset if the connector is in DPMS OFF mode
>
On Mon, Jun 10, 2013 at 9:59 PM, Chris Wilson wrote:
> On Mon, Jun 10, 2013 at 02:19:45PM -0300, Paulo Zanoni wrote:
>> - intel_dp_init_connector(intel_dig_port, dp_connector);
>> + /* May fail if it's an eDP connector that's disconnected. */
>> + if (!intel_dp_init_connector(intel_dig
On Mon, Jun 10, 2013 at 02:19:45PM -0300, Paulo Zanoni wrote:
> - intel_dp_init_connector(intel_dig_port, dp_connector);
> + /* May fail if it's an eDP connector that's disconnected. */
> + if (!intel_dp_init_connector(intel_dig_port, dp_connector)) {
> + intel_ddi_destroy(e
Hi,
It looks like an i915 commit causes problems with frequency scaling to
happen to people.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.--- Begin Message ---
https://bugzilla.kernel.org/show_bug.cgi?id=58971
--- Comment #42 from Alexa
On Mon, Jun 10, 2013 at 02:19:45PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> In case we detect a "ghost eDP", intel_dp_init_connector was freeing
> both the connector and encoder and then returning. On Haswell,
> intel_ddi_init was trying to use the freed encoder on the HDMI
> initializ
On Mon, Jun 10, 2013 at 01:49:25PM +0100, Damien Lespiau wrote:
> In case of intel_sdvo_get_active_outputs() failing, we end up reading a
> value from the stack.
>
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporatio
On Mon, Jun 10, 2013 at 01:28:42PM +0100, Damien Lespiau wrote:
> It's now intel_sdvo_get_capabilities().
>
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
__
On Mon, Jun 10, 2013 at 06:57:23PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 07, 2013 at 08:46:45PM +0300, Ville Syrjälä wrote:
> > I've just gone over patches 01-13.
> >
> > For patches 01,02,04,05,07,09-13
> > Reviewed-by: Ville Syrjälä
> >
> > For patches 03,06,08 I replied with some concerns
On 18:43 Fri 07 Jun , ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The string isn't modified so make it const.
>
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
Applied
Best Regards,
J.
> ---
On Mon, 2013-06-10 at 13:59 +0200, Rafael J. Wysocki wrote:
> I happen to know that alternative solution to this problem is being worked on,
> so I'm going to wait until it is submitted and then we'll decide what to
> merge.
Sure.
> I'm slightly concerned about unregistering ACPI backlight cont
於 日，2013-06-09 於 19:01 -0400，Matthew Garrett 提到：
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's br
Windows 8 introduced new policy for backlight control by pushing it out to
graphics drivers. This appears to have coincided with a range of vendors
adding Windows 8 checks to their backlight control code which trigger either
awkward behaviour (Lenovo) or complete brokenness (some Dells). The simple
From: "Lee, Chun-Yi"
There have some situation we unregister whole acpi/video driver by downstream
driver just want to remove backlight control interface of acpi/video. It caues
we lost other functions of acpi/video, e.g. transfer acpi event to input event.
So, this patch add a new function, fin
Drivers may need to make policy decisions based on the OS that the firmware
believes it's interacting with. ACPI firmware will make a series of _OSI
calls, starting from the oldest OS version they support and ending with the
most recent. Add a function to return the last successful call so that
dri
Windows 8 leaves backlight control up to individual graphics drivers rather
than making ACPI calls itself. There's plenty of evidence to suggest that
the Intel driver for Windows doesn't use the ACPI interface, including the
fact that it's broken on a bunch of machines when the OS claims to support
From: Paulo Zanoni
In case we detect a "ghost eDP", intel_dp_init_connector was freeing
both the connector and encoder and then returning. On Haswell,
intel_ddi_init was trying to use the freed encoder on the HDMI
initialization path since the following commit:
commit 21a8e6a4853b2ed39fa4c5188a7
On Fri, Jun 07, 2013 at 08:46:45PM +0300, Ville Syrjälä wrote:
> I've just gone over patches 01-13.
>
> For patches 01,02,04,05,07,09-13
> Reviewed-by: Ville Syrjälä
>
> For patches 03,06,08 I replied with some concerns/ideas.
You can slap my r-b onto those three as well.
--
Ville Syrjälä
Int
Before I start to make a complete mess out of this, crank up
the paranoia level a bit.
v2: Kill the has_pch_encoder check in put_shared_dpll - it's invalid
as spotted by Ville since we currently only put the dpll when we
already have the new pipe config. So a direct pch port -> cpu edp
transition
We don't (yet) have proper pixel multiplier readout support on pch
split platforms, so the cross check will naturally fail.
v2: Fix spelling in the comment, spotted by Ville.
Reported-by: Chris Wilson
Cc: Chris Wilson
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/in
On Mon, Jun 10, 2013 at 04:03:58PM +0100, Chris Wilson wrote:
> On Mon, Jun 10, 2013 at 03:48:09PM +0100, Damien Lespiau wrote:
> > This makes, arguably, the condition on state easier to read.
> >
> > Suggested-by: Chris Wilson
> > Signed-off-by: Damien Lespiau
> Reviewed-by: Chris Wilson
Queu
On Mon, Jun 10, 2013 at 03:48:09PM +0100, Damien Lespiau wrote:
> This makes, arguably, the condition on state easier to read.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Damien Lespiau
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Mon, Jun 10, 2013 at 4:47 PM, Bloomfield, Jon
wrote:
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the se
This makes, arguably, the condition on state easier to read.
Suggested-by: Chris Wilson
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/intel_fb.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_
On Mon, Jun 10, 2013 at 3:17 PM, Bloomfield, Jon
wrote:
>> -Original Message-
>> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
>> Daniel Vetter
>> Sent: Saturday, June 08, 2013 10:22 PM
>> To: Carsten Emde
>> Cc: Chris Wilson; Jesse Barnes; Intel Graphics Develo
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Monday, June 10, 2013 3:38 PM
> To: Bloomfield, Jon
> Cc: Carsten Emde; Chris Wilson; Jesse Barnes; Intel Graphics Development;
> Steven Rostedt; Christoph Mathys; stable
On Mon, Jun 10, 2013 at 04:34:05PM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 12:11 PM, Ville Syrjälä
> wrote:
> > On Fri, Jun 07, 2013 at 11:13:32PM +0200, Daniel Vetter wrote:
> >> On Fri, Jun 07, 2013 at 11:46:08PM +0300, Ville Syrjälä wrote:
> >> > On Fri, Jun 07, 2013 at 10:03:20PM
On Mon, Jun 10, 2013 at 12:11 PM, Ville Syrjälä
wrote:
> On Fri, Jun 07, 2013 at 11:13:32PM +0200, Daniel Vetter wrote:
>> On Fri, Jun 07, 2013 at 11:46:08PM +0300, Ville Syrjälä wrote:
>> > On Fri, Jun 07, 2013 at 10:03:20PM +0200, Daniel Vetter wrote:
>> > > On Fri, Jun 07, 2013 at 07:32:56PM +0
Radeon probably needs something similar. See attached untested patch.
Alex
On Sun, Jun 9, 2013 at 7:01 PM, Matthew Garrett
wrote:
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel
Chris Wilson writes:
> This is of no value to the developer reading the report, let alone the
> bamboozled user.
>
> Signed-off-by: Chris Wilson
> Acked-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c |8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Saturday, June 08, 2013 10:22 PM
> To: Carsten Emde
> Cc: Chris Wilson; Jesse Barnes; Intel Graphics Development; Bloomfield, Jon;
> Steven Rostedt; Christoph Mathys; sta
In particular, we were reseting our GEM tracking before even attempting
(and failing) to reset the chip. Do it with the other bookkeeping after
successfully reseting. Note that we can simplify the reset to always do
the GPU reinitialisation as for UMS it will simply be redundant in the
case where X
In case of intel_sdvo_get_active_outputs() failing, we end up reading a
value from the stack.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_sdvo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/inte
It's now intel_sdvo_get_capabilities().
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 7068195..221d415 100644
--- a/drivers/gpu/d
Hi Matthew,
On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote:
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger ei
If we detect a ring is in a valid wait for another, just let it be.
Eventually it will either begin to progress again, or the entire system
will come grinding to a halt and then hangcheck will fire as soon as the
deadlock is detected.
This error was foretold by Ben in
commit 05407ff889ceebe383aa59
After kicking a ring, it should be free to make progress again and so
should not be accused of being stuck until hangcheck fires once more. In
order to catch a denial-of-service within a batch or across multiple
batches, we still do increment the hangcheck score - just not as
severely so that it ta
This is of no value to the developer reading the report, let alone the
bamboozled user.
Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/driver
When we reset and restart a ring, we also want to clear any existing
hangcheck.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
inde
On Fri, Jun 07, 2013 at 11:13:32PM +0200, Daniel Vetter wrote:
> On Fri, Jun 07, 2013 at 11:46:08PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 07, 2013 at 10:03:20PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 07, 2013 at 07:32:56PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jun 05, 2013 at 01:
On Mon, Jun 10, 2013 at 09:25:40AM +0200, Daniel Vetter wrote:
> We don't (yet) have proper pixel multiplier readout support on pch
> split platforms, so the cross check will naturally fail.
>
> Reported-by: Chris Wilson
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm
On Mon, Jun 10, 2013 at 09:10:51AM +0100, Chris Wilson wrote:
> On Mon, Jun 10, 2013 at 09:47:58AM +0200, Daniel Vetter wrote:
> > In
> >
> > commit 53d3b4d7778daf15900867336c85d3f8dd70600c
> > Author: Egbert Eich
> > Date: Tue Jun 4 17:13:21 2013 +0200
> >
> > drm/i915/sdvo: Use &intel_sd
From: Ville Syrjälä
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() pro
On Mon, Jun 10, 2013 at 09:47:58AM +0200, Daniel Vetter wrote:
> In
>
> commit 53d3b4d7778daf15900867336c85d3f8dd70600c
> Author: Egbert Eich
> Date: Tue Jun 4 17:13:21 2013 +0200
>
> drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC
>
> Egbert Eich fixed a long-stand
On Sun, Jun 09, 2013 at 04:02:05PM +0100, Chris Wilson wrote:
> The hotplug_mask is no longer used as the hpd interrupt setup is now
> handled in the core.
>
> Signed-off-by: Chris Wilson
First two patches merged to -fixes with the missing regression notes
added, last one merged to dinq. Also cc
After kicking a ring, it should be free to make progress again and so
should not be accused of being stuck until hangcheck fires once more. In
order to catch a denial-of-service within a batch or across multiple
batches, we still do increment the hangcheck score - just not as
severely so that it ta
If we detect a ring is in a valid wait for another, just let it be.
Eventually it will either begin to progress again, or the entire system
will come grinding to a halt and then hangcheck will fire as soon as the
deadlock is detected.
This error was foretold by Ben in
commit 05407ff889ceebe383aa59
In
commit 53d3b4d7778daf15900867336c85d3f8dd70600c
Author: Egbert Eich
Date: Tue Jun 4 17:13:21 2013 +0200
drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC
Egbert Eich fixed a long-standing bug where we simply used a
non-working i2c controller to read the EDID for SD
On Sun, Jun 09, 2013 at 07:01:39PM -0400, Matthew Garrett wrote:
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> f
We don't (yet) have proper pixel multiplier readout support on pch
split platforms, so the cross check will naturally fail.
Reported-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 4
1 file changed, 4 insertions(+)
diff --git a/driv
Chris Wilson writes:
> On Sun, Jun 09, 2013 at 11:28:12PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 9, 2013 at 11:16 PM, Chris Wilson
> > wrote:
> > > On Sun, Jun 09, 2013 at 10:58:38PM +0200, Daniel Vetter wrote:
> > >> In
> > >>
> > >> commit 53d3b4d7778daf15900867336c85d3f8dd70600c
>
51 matches
Mail list logo
