On Fri, Sep 6, 2013 at 2:56 AM, Linus Torvalds
wrote:
> On Thu, Sep 5, 2013 at 4:19 PM, Linus Torvalds
> wrote:
>>
>> So I've decided I'm going to try to bisect this after all. I've done
>> enough pulls for today anyway, I guess. Let's see if I can bisect it
>> by just trying to boot many times e
On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
> I think the parameter "Does the ACPI backlight interface work or not"
> belongs to the ACPI video driver.
That depends on how Windows 8 works. If Windows 8 policy is handled by
the GPU drivers then it belongs in i915. If it's handled by the
On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index f466980..75fba17 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> > On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> >> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> >> b/drivers/gpu/drm/i915/i915_dma.c
> >> index f466980..75fba17 100644
> >> --- a/drivers/gp
On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
> On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
>> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
>>> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
ind
On Tue, 2013-09-10 at 13:16 +0800, Aaron Lu wrote:
> On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
> > On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
> >> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> >>> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> diff --git a/drivers/gpu/drm/i91
On Mon, 2013-09-09 at 16:40 +0800, Aaron Lu wrote:
> The backlight control and event delivery functionality provided by ACPI
> video module is mixed together and registered all during video device
> enumeration time. As a result, the two functionality are also removed
> together on module unload t
On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> According to 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 [8] doesn't use the ACPI inte
On 09/10/2013 01:22 PM, Igor Gnatenko wrote:
> On Tue, 2013-09-10 at 13:16 +0800, Aaron Lu wrote:
>> On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
>>> On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> On Mon, 2013-09-09 at 16:42 +0800, Aaron L
Hi Linus,
Daniel had some fixes queued up, that were delayed, the stolen memory ones
and vga arbiter ones are quite useful, along with his usual bunch of
stuff, nothing for HSW outputs yet,
the one nouveau fix is for a regression I caused with the poweroff stuff.
Dave.
The following changes
On Mon, Sep 09, 2013 at 11:32:10AM +0200, Daniel Vetter wrote:
> Hi Aaaron,
>
> Have we grown any clue meanwhile about which Intel boxes need this and for
> which we still need to keep the acpi backlight around? I've grown _very_
Sorry, no general rule has been found. As Rafael has said, it appea
You can get the driver data from struct device directly, there's no
need to get the PCI device first.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- linux-3.11-
The hwmon sysfs interface allows exposing temperature limits. The "max"
and "min" thresholds will be exposed as a critical high limit and its
hysteresis value, respectively. This gives the user a better idea of how
well cooling is doing and whether it is sufficient.
Signed-off-by: Jean Delvare
Cc
On Tue, 2013-09-10 at 17:21 +0300, Jani Nikula wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
> >
> >> I think the parameter "Does the ACPI backlight interface work or not"
> >> belongs to the ACPI video driver.
> >
> > That depends o
Alex Deucher writes:
> On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf
> wrote:
>
>> IIRC Alex said the sanity checks are expensive and boot-time could be
>> improved by dropping them. Maybe he can chime in?
>
> They shouldn't be necessary with a proper shutdown, but in this
> particular cas
From: Wei Yongjun
In case of error, the function drm_prime_pages_to_sg() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2
From: Wei Yongjun
In case of error, the function drm_prime_pages_to_sg() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 4 ++--
1 file changed, 2 insert
On Tue, Sep 10, 2013 at 09:23:04PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 10, 2013 04:53:40 PM Jani Nikula wrote:
> > On Mon, 09 Sep 2013, "Rafael J. Wysocki" wrote:
> > > On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote:
> > >> On Mon, Sep 09, 2013 at 02:16:12PM +020
On Wed, 11 Sep 2013, Aaron Lu wrote:
> It is possible the i915 driver decides not to register a backlight
> interface for the graphics card for some reason(memory allocation failed
> or it knows the native control does not work on this card or whatever),
> so I would prefer let i915 tell ACPI vide
On 2013.09.10 at 16:40 -0400, Alex Deucher wrote:
> On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman
> wrote:
> > Alex Deucher writes:
> >
> >> On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf
> >> wrote:
> >>
> >>> IIRC Alex said the sanity checks are expensive and boot-time could be
> >>>
On 2013.09.09 at 11:38 +0200, Christian König wrote:
> Am 09.09.2013 11:21, schrieb Markus Trippelsdorf:
> > On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote:
> >> Markus Trippelsdorf writes:
> >>
> >>> Here are a couple of patches that get kexec working with radeon devices.
> >>> I've tested
Am 11.09.2013 11:01, schrieb Markus Trippelsdorf:
On 2013.09.09 at 11:38 +0200, Christian König wrote:
Am 09.09.2013 11:21, schrieb Markus Trippelsdorf:
On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote:
Markus Trippelsdorf writes:
Here are a couple of patches that get kexec working wit
Am 11.09.2013 10:53, schrieb Markus Trippelsdorf:
On 2013.09.10 at 16:40 -0400, Alex Deucher wrote:
On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman
wrote:
Alex Deucher writes:
On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf
wrote:
IIRC Alex said the sanity checks are expensive and
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #14 from Andrew Stubbs ---
More observations:
About 1 time in 3 boots the driver will fail to allocate PPLLs at all, and
Ubuntu 13.10 will not start lightdm login screen.
Having failed, I tend to get a run of failures, but two or thr
Hi Lars-Peter,
On Wednesday 04 September 2013 13:34:30 Lars-Peter Clausen wrote:
> [...]
>
> >> +
> >> +/**
> >> + * enum adv7511_input_color_depth - Selects the input format color depth
> >> + * @ADV7511_INPUT_COLOR_DEPTH_8BIT: Input format color depth is 8 bits
> >> per channel
> >> + * @ADV751
On Wed, 11 Sep 2013, Matthew Garrett wrote:
> On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
>
>> Before plunging forward, have you observed any difference between the
>> boot modes? We have reports [1] that the backlight behaviour is
>> different with UEFI vs. UEFI+CSM or legacy boot. So I
On Wed, Sep 11, 2013 at 7:16 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENOMEM in the refill memory alloc error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Thanks
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/o
Hi Philipp,
On Wednesday 04 September 2013 16:21:38 Philipp Zabel wrote:
> Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> > Extend the notifier with DT node matching support, and add helper
> > functions to build the notifier and link entities based on a graph
> > representati
Hi Linus,
Here's the 3.12 pull request for dma-buf framework updates. Its yet another
small one - dma-buf framework now supports size discovery of the buffer via
llseek.
Could you please pull?
Thanks and best regards,
~Sumit.
The following changes since commit 26b0332e30c7f93e780aaa054bd84e343
Hi Linus.
Sincere apologies for the html post; this request is now in
plain-text. (it has been convenient using the gmail interface, but I
promise this is the last time you'll see a non-plain-text email from
me.
Apologies again!
Best regards,
~Sumit.
On 11 September 2013 17:07, Sumit Semwal wr
Am Mittwoch, den 11.09.2013, 13:33 +0200 schrieb Laurent Pinchart:
> Hi Philipp,
>
> On Wednesday 04 September 2013 16:21:38 Philipp Zabel wrote:
> > Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> > > Extend the notifier with DT node matching support, and add helper
> > > func
https://bugs.freedesktop.org/show_bug.cgi?id=69120
--- Comment #20 from Alex Deucher ---
(In reply to comment #13)
> your possible fix from Comment 10 solve it halfway or maybe fully even on
> my slow Duron 1800, RV730 AGP (4650), if we separate the mosaic into a new
> bug entry.
That's a separ
https://bugs.freedesktop.org/show_bug.cgi?id=69120
Alex Deucher changed:
What|Removed |Added
Product|Mesa|DRI
Version|9.2
On Wed, Sep 11, 2013 at 5:01 AM, Markus Trippelsdorf
wrote:
> On 2013.09.09 at 11:38 +0200, Christian König wrote:
>> Am 09.09.2013 11:21, schrieb Markus Trippelsdorf:
>> > On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote:
>> >> Markus Trippelsdorf writes:
>> >>
>> >>> Here are a couple of p
On Wed, Sep 11, 2013 at 4:53 AM, Markus Trippelsdorf
wrote:
> On 2013.09.10 at 16:40 -0400, Alex Deucher wrote:
>> On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman
>> wrote:
>> > Alex Deucher writes:
>> >
>> >> On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf
>> >> wrote:
>> >>
>> >>> IIRC
On 09/11/2013 01:33 PM, Laurent Pinchart wrote:
> Hi Philipp,
>
> On Wednesday 04 September 2013 16:21:38 Philipp Zabel wrote:
>> Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
>>> Extend the notifier with DT node matching support, and add helper
>>> functions to build the not
https://bugs.freedesktop.org/show_bug.cgi?id=59649
--- Comment #8 from Shawn Starr ---
This is pending close, waiting til end of week, but so far, the fixes work,
those patches listed in the bug are obsolete as the work is being shifted
around but the logic however seems to fix the reset issues.
On Tue, Sep 10, 2013 at 4:30 AM, Jean Delvare wrote:
> You can get the driver data from struct device directly, there's no
> need to get the PCI device first.
>
> Signed-off-by: Jean Delvare
> Cc: David Airlie
> Cc: Alex Deucher
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_p
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #127 from Sergey ---
Thanks, I'll try to check these patches.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #126 from Alex Deucher ---
(In reply to comment #124)
> I've noticed, that while watching youtube videos, sometimes (actually rather
> often) everything freezes. Looks like Xorg crash. It tries to recover but
> screen freezes, though
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #124 from Sergey ---
I've noticed, that while watching youtube videos, sometimes (actually rather
often) everything freezes. Looks like Xorg crash. It tries to recover but
screen freezes, though mouse is working and sound (probably ev
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunately, the call to
"get_scanout_position()" can call functions that use
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #28 from Weber K. ---
Sorry fellows... I my proposal was only a workaround...
Maybe if you have 2 cards, and only the second is radeon, then the callback
will never be scheduled... :(
The solution needs to be adjusted a little more...
On Wed, Sep 11, 2013 at 10:09 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> The dereference to 'pdata' should be moved below the NULL test.
>
> Signed-off-by: Wei Yongjun
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #125 from Sergey ---
Created attachment 85644
--> https://bugs.freedesktop.org/attachment.cgi?id=85644&action=edit
Xorg log
Here is Xorg log, but according to timestamps it is only for Xorg, that tried
to restart. Initial error is
https://bugzilla.kernel.org/show_bug.cgi?id=60857
Alex Deucher changed:
What|Removed |Added
Attachment #107430|0 |1
is obsolete|
Hi Dave,
Radeon drm fixes for 3.12. All over the place (display, dpm, uvd, etc.).
Also adds a couple more berlin pci ids.
The following changes since commit 01172772c7c973debf5b4881fcb9463891ea97ec:
drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53 +1000)
are available i
When we CPU_PREP a bo with NOSYNC flag (for example, to implement
PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE), an -EBUSY return indicates to
userspace that the bo is still busy. Previously it was incorrectly
returning 0 in this case.
And while we're in there throw in an bit of extra sanity checking in
Occasionally we seem to miss an IRQ from the ME (microengine). I'm not
entirely sure the root cause, but for now we can unwedge things by
retiring from the hangcheck timer.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
d
https://bugzilla.kernel.org/show_bug.cgi?id=58121
黄家垚 changed:
What|Removed |Added
CC||huangjiayao_1...@163.com
--- Comment #4 from 黄家垚 -
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #20 from Alexandre Demers ---
Ok, if I apply the whole suggested patch but the following, it hangs:
@@ -4152,14 +4152,14 @@ int ni_dpm_init(struct radeon_device *rdev)
}
ni_pi->mclk_rtt_mode_threshold = eg_pi->mclk_edc_wr_en
This removes two warnings where dma_addr_t variables were printed using
%x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:
drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t'
drivers/gpu/hos
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #21 from Alexandre Demers ---
Adding printk(KERN_DEBUG "DEBUG: about to pass the following value of
module_index to radeon_atom_init_mc_reg_table(): %d", module_index); just
before calling radeon_atom_init_mc_reg_table() returns 2.
-
From: Dave Airlie
When porting from UMS I mistyped this from the wrong place, AST noticed
and pointed it out, so we should fix it to be like the X.org driver.
Reported-by: Y.C. Chen
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ast/ast_drv.h | 2 +-
1 file changed,
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #33 from Jose P. ---
Created attachment 85691
--> https://bugs.freedesktop.org/attachment.cgi?id=85691&action=edit
dmesg+Xorg.0.log
Same bug here...
HP laptop (dv6-6174la), dual GPU:
00:01.0 VGA compatible controller [0300]: Advanc
55 matches
Mail list logo
